¿Cuáles son los privilegios razonables para otorgar a los usuarios típicos? [cerrado]

Encuentro que la lista de privilegios proporcionados por MySQL es un poco abrumadora. No estoy seguro de quién debería tener qué privilegios. En mi opinión, hay tres usuarios típicos para mi situación:

1. root
2. developer
3. application

rootSe explica por sí mismo. Para developereste usuario necesita poder acceder fácilmente a cualquier base de datos, hacer ajustes a ella, etc. Para empezar, estoy configurando a este usuario con este conjunto de privilegios:

SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON

applicationtiene un conjunto aún más limitado. Debería limitarse a manipular una base de datos específica.

No estoy seguro de qué conjunto de privilegios razonable es otorgar. ¿Cuáles son un conjunto razonable de privilegios para otorgar un desarrollador y una aplicación y por qué?

Un usuario típico debería tener:

SELECT, INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES, EXECUTE

Los primeros cuatro son bastante obvios, aunque también puede configurar usuarios con "solo lectura" SELECT.

CREATE TEMPORARYTambién es útil y generalmente inofensivo: las tablas temporales pueden ayudar a optimizar las consultas, dividiéndolas en partes más pequeñas y más rápidas. Se limitan a la conexión en ejecución y se eliminan automáticamente cuando se cierra.

EXECUTEDepende de su tipo de sistema. ¿Tienes rutinas almacenadas? ¿Desea que sus usuarios accedan a ellos? Asegúrese de conocer también la SECURITY=DEFINER/INVOKERdefinición de las rutinas almacenadas.

En cualquier caso, asegúrese de aplicar todo lo anterior en esquemas específicos . Evite usar:

GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'some_user'@'some_host';

como lo anterior también otorga privilegios en las mysqltablas del sistema, lo que efectivamente permite a cualquier usuario crear nuevas cuentas o actualizar su propio conjunto de privilegios. En cambio, haz:

GRANT SELECT, INSERT, UPDATE, DELETE ON some_schema.* TO 'some_user'@'some_host';
GRANT SELECT, INSERT, UPDATE, DELETE ON another_schema.* TO 'some_user'@'some_host';

En cualquier sistema de escala real (es decir, no un proyecto personal), esos tipos de usuarios variarán según el entorno, por lo que no es tan simple.

En todos los entornos, la aplicación debe tener lo que necesita y no más (generalmente esto es "seleccionar / insertar / actualizar en todas las tablas" y "exec en todos los procedimientos". Para sistemas más grandes donde puede tener usuarios de aplicaciones separados para diferentes tareas (para una aplicación es responsable de alimentar los datos del censor y otra de generar informes) debe separar sus privilegios para que tengan lo menos que necesitan (el usuario que informa probablemente no necesita y tiene derechos de escritura). Asegúrese de replicar esto en su prueba entornos si los tiene: he visto caer el código cuando se promocionó a Live que funcionó en la prueba porque todo en el entorno de prueba estaba accediendo a la base de datos como sa(equivalente a MSSQL root).Idealmente, un usuario de la aplicación generalmente no debería tener privilegios que le permitan alterar su esquema (CREATE, DROP...) - hay excepciones a esto pero son pocas y distantes entre sí.

rootes, bueno root,. En producción, este es solo su DBA y debe usarse raramente, solo para el mantenimiento del sistema (actualizaciones del diseño de la base de datos, etc.) y monitoreo. Para un sistema grande, especialmente en entornos regulados donde debe mantener un control estricto de las personas con fines de responsabilidad, es posible que no permita un solo rootusuario y trate de separar los privilegios en rollos más pequeños (no estoy seguro de cuán lejos puede llegar con esto en mysql, pero puede ser bastante fino en MSSQL, Oracle, etc.).

Para usuarios desarrolladores: no deberían tener acceso a sus entornos en vivo. Esta es una de las razones por las cuales los usuarios de la aplicación no deberían tener derechos que afecten el esquema: alguien con acceso a una cuenta de desarrollador podría eludir su bloqueo de esta manera. En los entornos de prueba tampoco suelen tener acceso: enviarían parches a QA y el DBA (probablemente usando un rootusuario) para QA aplicaría las actualizaciones al entorno de prueba (de hecho, esto a menudo se automatiza en grandes organizaciones, por lo que el DBA de QA en realidad es un conjunto de scripts que controla la reconstrucción del entorno de prueba para cada ciclo). En entornos de desarrollo, especialmente si los desarrolladores tienen sus propias copias locales del servicio en ejecución, estos usuarios, por supuesto, deben tener acceso completo a todo para poder experimentar.

Sin embargo, lo anterior son todas notas generales: para hacer recomendaciones específicas, necesitaríamos saber mucho más sobre sus aplicaciones y los entornos en los que operan. El entorno de destino a veces es más importante de lo que podría pensar: dependiendo de su entorno empresarial los derechos de sus usuarios podrían incluso dictarse de manera bastante directa como regulaciones legales, incluso en desarrollo si sus clientes alguna vez le dan acceso a datos reales con fines de diagnóstico.