Diseño de bases de datos
El primer paso es siempre crear una base de datos, a menos que se quiera utilizar
una de un tercero. Cuando se crea una base de datos, esta es
asignada a un propietario, aquel que ejecutó la sentencia de creación. Usualmente, sólo
el propietario (o un superusuario) puede hacer cualquier cosa con los objetos de esa
base de datos. Para que otros usuarios puedan utilizarla, se les deben conceder
privilegios.
Las aplicaciones nunca deberían conectarse a la base de datos como su propietario o como
un superusuario, porque estos usuarios pueden ejecutar cualquier consulta a su antojo; por
ejemplo, modificar el esquema (p.ej., eliminar tablas) o borrar su contenido
por completo.
Se pueden crear distintos usuarios de una base de datos para cada aspecto de la
aplicación con permisos muy limitados a los objetos de dicha base de datos. Solamente
deberían otorgarse los privilegios necesarios, evitando así que el mismo usuario
pueda interactuar con la base de datos en diferentes casos y uso. Esto significa que si
un intruso obtiene acceso a una base de datos utilizando las credenciales de la aplicación,
solamente puede efectuar los cambios que la aplicación permita.
Se recomienda no implementar toda la lógica de negocio en la aplicación
web (esto es, en los scripts); se ha de hacer en su lugar en el esquema de la base de datos
utilizando vistas, disparadores o reglas. Si el sistema evoluciona, se tendrá por objeto
abrir nuevos puertos a la base de datos, teniendo así que reimplementar la lógica
en cada cliente de la base de datos por separado. Además, los disparadores se pueden utilizar
para manejar campos de forma transparente y automática, lo que a menudo ayuda en
la depuración de problemas con la aplicación o en el seguimiento de
transacciones.
Anonymous ¶8 months ago
"You are encouraged not to implement all the business logic in the web application (i.e. your script), instead do it in the database schema using views, triggers or rules. If the system evolves, new ports will be intended to open to the database, and you have to re-implement the logic in each separate database client."
This doesn't make sense to me. I might be misreading it, but I can't see how this adds to security. It sounds like implementing business logic in the database just increases the amount of work you have to do if you ever want to upgrade or change your SQL database.