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

Question

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 son SELECCIONAR / INSERTAR / ACTUALIZAR / BORRAR, parece tener sentido proporcionar solo esos privilegios, sin embargo, nunca he visto eso recomendado en ninguna parte: cuáles son las razones a favor y en contra de esto método?

Answer 1

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

• CREAR TABLA TEMPORAL
• EJECUTAR (procedimientos almacenados)
• ARCHIVO (para SELECCIONAR EN Y CARGAR DATOS)
• TABLAS DE BLOQUEO

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

¿Qué intenta 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 con una granularidad fina. Francamente, si sus usuarios pueden cargar y ejecutar declaraciones SQL que no han examinado, tienen mayores problemas:

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

Las tareas reales que desea gobernar no están en el nivel de la base de datos, están 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 tienen un nivel superior a los privilegios de SQL. Puede imitarlos con roles SQL (que son grupos de privilegios), pero los roles SQL no son ampliamente compatibles.

No conozco a nadie que asigne a sus usuarios de aplicaciones a distintos usuarios de MySQL. Son usuarios que 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).

Entonces, probablemente sea mejor que su aplicación web use un solo usuario de MySQL con todos los privilegios.

Answer 2

No estoy de acuerdo con Bill aquí y la línea de pensamiento de Atomix es más adecuada. A menos que se pueda demostrar 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, dar un script completo y sin restricciones para hacer ~ cualquier cosa ~ a una base de datos es pedir problemas, cuando no es necesario.

El principio de privilegio mínimo debería estar en uso aquí. Para MySQL, tenga un súper usuario con todos los privilegios que se utiliza para crear tablas, descartar bases de datos, etc. Idealmente, este nombre de usuario y contraseña nunca se ven en ningún archivo PHP ni en ningún archivo del 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 lo recomiendan 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 el principio del privilegio mínimo ( http://en.wikipedia.org/wiki/Principle_of_least_privilege ) debería aplicar. Si de alguna manera su súper usuario de MySQL se ve comprometido porque accidentalmente nombró su script de conexión de MySQL como .txt en lugar de .php, o alguien obtuvo acceso a los archivos del servidor web, al menos lo peor. lo que pueden hacer es SELECCIONAR, ACTUALIZAR e INSERTAR ... Lo que si bien puede causar grandes problemas de todos modos, no es tan malo como darles BASE DE DATOS, TABLAS DE GOTAS y cosas mucho peores.

Además, en mi proyecto actual debido a prácticas de desarrollo ágiles (no trabajo pero recomiendo http: // www. agilealliance.org/ ), uno o dos "no tecnológicos" Los miembros del equipo utilizan directamente PHPMyAdmin para realizar cambios directos en la base de datos MySQL. Esto se debe a que no es necesario crear un CMS para la entrada directa de datos simple. En este caso, un tercer usuario de MySQL con una cantidad razonable pero, nuevamente, "suficiente" Los privilegios son adecuados para ellos. No queremos mutilar al miembro del equipo con muy pocos privilegios, pero, por supuesto, no deberían poder eliminar o cambiar cosas accidentalmente.

Dado que MySQL no tiene ROLES (en el momento en que se hizo la pregunta original, y según Bill), permitir cualquier script web para acceder a MySQL con un solo Super Usuario es muy riesgoso.

Answer 3

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. Aplicar 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 lo ofusca?), Por lo que hay margen de compromiso si sus secuencias de comandos no se administran correctamente.

En mi experiencia, muy raramente tengo la aplicación para eliminar filas, ¡mucho mejor marcar una fila como eliminada ya que luego tienes una auditoría de lo que está allí en lugar de no saber qué estaba allí! Este enfoque también ayuda a mantener las tablas e índices optimizados.

Por lo tanto, sugeriría permitir solo INSERTAR, ACTUALIZAR y SELECCIONAR: ¡se hará evidente rápidamente si algunas 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.