remoto - Proporcionar a los usuarios de MySQL solo los privilegios mínimos

roles y privilegios en mysql (3)

Para una aplicación web, al crear el usuario que se conectará a la base de datos MySQL, tiene la opción de privilegios. Suponiendo que las únicas acciones que pretende realizar ese usuario sean SELECCIONAR / INSERTAR / ACTUALIZAR / ELIMINAR, parece lógico que solo proporcione esos privilegios; sin embargo, nunca he visto que se recomiende en ningún lado. ¿Cuáles son las razones a favor y en contra de esto? ¿método?

Existen otros privilegios que un usuario podría necesitar durante una aplicación ordinaria, por ejemplo:

CREAR TABLA TEMPORAL
EJECUTAR (procedimientos almacenados)
FILE (para SELECT INTO y LOAD DATA)
TABLAS DE BLOQUEO

También existe la posibilidad de que privilegios mínimos solo signifiquen SELECCIONAR en ciertas tablas, y solo SELECCIONAR y ACTUALIZAR en otras tablas, etc. Esto está sujeto a cambios cada vez que se mejore la funcionalidad de la aplicación. Y hay casos extraños, como la necesidad de tener el privilegio SELECT en una tabla que nunca consultas, porque las claves foráneas hacen referencia a ellas en una tabla que ACTUALIZAS. Así que el seguimiento de los privilegios mínimos es un dolor real.

¿Qué estás tratando de restringir mediante el uso de privilegios de SQL? Usted es quien escribió todo el código, por lo que no debería ser necesario administrar los privilegios de SQL en una granularidad fina. Francamente, si los usuarios pueden subir y ejecutar sentencias de SQL que no ha examinado, tiene mayores problemas:

SELECT * FROM mytable, mytable, mytable, mytable, mytable ORDER BY 1;

Las tareas reales que desea controlar no están en el nivel de la base de datos, sino en el nivel empresarial de la aplicación. Por ejemplo, un CMS tiene operaciones como crear una página, editar una página, administrar comentarios, etc. Estas tareas son de nivel superior a los privilegios de SQL. Podría imitarlos con roles SQL (que son grupos de privilegios), pero los roles SQL no son ampliamente compatibles.

No conozco a nadie que asigne los usuarios de sus aplicaciones a distintos usuarios de MySQL. Son usuarios a los que se autentica en su aplicación, después de que la aplicación se haya conectado a la base de datos (los usuarios son solo filas de datos en la base de datos).

Así que probablemente sea mejor que su aplicación web use un único usuario de MySQL con todos los privilegios.

Una aplicación web generalmente usa solo un usuario para acceder a la base de datos, en lugar de un usuario por cuenta de usuario real. La aplicación de privilegios mínimos es una buena práctica. El nombre de usuario y la contraseña se codificarán en su secuencia de comandos (¿alguien ofusca esto?) Por lo que hay margen de compromiso si sus scripts no se administran correctamente.

En mi experiencia, muy, muy rara vez elimino las filas de la aplicación; es mucho mejor marcar una fila como eliminada, ya que luego se realiza una auditoría de lo que hay, en lugar de no saber qué hay allí. Este enfoque también ayuda a mantener tablas e índices optimizados.

Por lo tanto, sugeriría permitir solo INSERTAR, ACTUALIZAR y SELECCIONAR: ¡rápidamente se hará evidente si partes de su aplicación necesitan relajarse un poco!

Permitir más privilegios solo puede ampliar la posibilidad de ataques DoS al emitir comandos intensivos en recursos o permitir ataques de datos maliciosos.

No estoy de acuerdo con Bill aquí y la línea de pensamiento de Atomix es más adecuada. A menos que se demuestre lo contrario, la respuesta de Bill aumenta mucho el riesgo de que la base de datos se vea comprometida.

Quizás para los desarrolladores con mucha experiencia existe otra seguridad, pero para otros desarrolladores que proporcionan una secuencia de comandos completa, el acceso sin restricciones para hacer ~ cualquier cosa ~ a una base de datos es un problema, cuando no es necesario.

El principio de privilegio mínimo debería usarse aquí. Para MySQL, tenga un súper usuario con todos los privilegios que se usa para crear tablas, soltar bases de datos, etc. Idealmente, este nombre de usuario y contraseña nunca se ven en ningún archivo PHP o cualquier archivo en el servidor web. (Estoy usando PHP como ejemplo, pero se aplica a otras aplicaciones web). Solo usaría este nombre de usuario y contraseña con algo como PHPMyAdmin o MySQL Workbench.

Luego, para los scripts PHP, tenga uno con el mínimo requerido, como INSERTAR, SELECCIONAR, ACTUALIZAR, tal vez ni siquiera ELIMINAR, dependiendo de su script PHP. Esto estaría en los archivos PHP, es decir, en realidad, SOLO UN archivo FUERA de la raíz del documento, como es recomendado por la mayoría.

La razón es la siguiente: sí, no necesita un usuario de MySQL para cada usuario de la aplicación web. Pero debe aplicarse el principio de privilegio mínimo ( http://en.wikipedia.org/wiki/Principle_of_least_privilege ). Si de alguna manera su súper usuario de MySQL está en peligro porque accidentalmente llamó a su secuencia de comandos MySQL connect como .txt en lugar de .php, o alguien obtuvo acceso a los archivos del servidor web, al menos lo "peor" que pueden hacer es SELECCIONAR, ACTUALIZAR e INSERTAR. .. Que si bien puede causar grandes problemas de todos modos, no es tan malo como darles DROP DATABASE, DROP TABLES y cosas mucho peores.

Además, en mi proyecto actual debido a las prácticas de desarrollo ágiles (no trabajo, pero recomiendo http://www.agilealliance.org/ ), uno o dos miembros del equipo "sin tecnología" están utilizando directamente PHPMyAdmin para realizar cambios directos a la base de datos MySQL Esto se debe a que no es necesario crear un CMS para la entrada de datos directa simple. En este caso, un tercer usuario de MySQL con privilegios razonables pero de nuevo "suficientes" es adecuado para ellos. No queremos paralizar al miembro del equipo con privilegios muy pequeños, pero, por supuesto, no deberían poder borrar o cambiar cosas accidentalmente.

Como MySQL no tiene ROLES (desde el momento en que se formuló la pregunta original y según Bill), permitir que cualquier script web simplemente acceda a MySQL con solo un Super Usuario es muy arriesgado.