¿Hay alguna razón para crear un usuario de base de datos sin privilegios de esquema?

No estoy seguro de que esto siempre se haga por seguridad de usuarios externos. Por ejemplo, es posible que tenga un DBA que desee que los desarrolladores puedan seleccionar / actualizar / eliminar registros, pero que no comiencen a implementar sus propios cambios de esquema. Así que configuran una cuenta para que la usen los desarrolladores, a la vez que mantienen las cuentas más poderosas para ellos mismos.

En el caso de que un usuario externo obtenga acceso a su base de datos a través de SQLi o algo así, estoy de acuerdo en que pueden causar estragos en las operaciones básicas de selección / actualización / eliminación, pero hay otras cosas que podrían hacer si tienen La capacidad de decir tablas de caída. Por ejemplo, si la página principal de una aplicación consulta una tabla específica y esa tabla se ha eliminado, el atacante esencialmente puede evitar que el sitio se active. Concedido: si su db ha sido comprometida, es probable que desee desconectar el sitio, pero lo ideal es que decida cuándo sucederá eso y no el atacante.

Esto podría ser muy inverosímil, pero un atacante también podría comenzar a rastrear la información que podría encontrar útil al registrar la información en una tabla que haya creado usando desencadenantes o algo así. Si la base de datos no recibe mucha atención, esto podría pasar desapercibido y podrían revisar y usar esta información para ataques más sofisticados.

Esos son algunos escenarios específicos que vienen a la mente. No estoy de acuerdo con su afirmación de que crear cuentas con los privilegios mínimos que necesitan para funcionar es un "escape". Dependiendo de lo creativo que sea un atacante, estoy seguro de que hay otras formas en que podrían explotar estos privilegios adicionales para sus propios fines nefarios. Además, no puedo pensar en una razón para dar a las cuentas más poder del que necesitan.

La capacidad de cambiar el esquema es una de las más potentes que puede obtener en una base de datos. Seleccionar / Insertar / Actualizar / Eliminar solo le permite cambiar los datos. El esquema de actualización le permite cambiar todos los objetos. Esto incluye cosas extremadamente poderosas como:

• Cambio de procedimientos almacenados
• Agregar desencadenantes
• (posiblemente) Cambie las tareas programadas (dependiendo de cómo esté configurada su base de datos)

Los dos primeros permiten el acceso a nivel de código, que es mucho más que simplemente poder ver los datos. Un atacante podría obtener fácilmente más control sobre su aplicación con acceso a nivel de código.

En cualquier caso, la capacidad de cambiar el esquema es extremadamente poderosa y no se puede ignorar. También es esencialmente gratis porque pocas aplicaciones, si es que alguna, necesitan este nivel de acceso una vez que se ejecutan.

Si necesita este nivel de acceso para CI, sugeriría diseñar para el escenario donde se necesita un mayor nivel de acceso para implementar la aplicación que para simplemente ejecutarla.

A menudo no tiene que dar permisos DELETE. Dependiendo de la aplicación, probablemente encontrará que la mayoría de las tablas nunca obtendrán un BORRADO (especialmente el seguimiento de auditoría y las transacciones financieras). Probablemente haya otro subconjunto de la tabla que tampoco necesita ACTUALIZAR, donde puede limitar las actualizaciones a un subconjunto de columnas. También puede tener algunas tablas en el mismo esquema que no están disponibles para una aplicación, pero se pueden mantener desde una aplicación separada que podría tener un acceso más seguro (por ejemplo, VPN a una intranet de la compañía).

Algunos DBMS tienen capacidades para limitar o auditar actividades excepcionales incluso del propietario de la tabla, pero la separación a través de los derechos de acceso es bastante universal.