Beneficios de seguridad de diferentes usuarios de MySQL

Navega tus respuestas
12

Cualquier persona con una célula cerebral sabe que usar un usuario que no sea root / dbo / etc agrega mucho a la seguridad y la eficacia de los ataques de inyección SQL. Me pregunto si llevar esa idea un paso más allá es una buena idea.

La idea básica es simple. Para las acciones de tipo invitado (visualización), use un usuario 'invitado' en la base de datos que solo tiene permisos para select things. Para acciones similares a usuarios (agregar / editar), tenga un usuario 'usuario', que solo tiene permisos para ejecutar las consultas insert y update . Además de eso, también incluye un tercer usuario con acciones similares a "admin", para delete skills.

NB: Esto se ha simplificado para cubrir solo las habilidades básicas de CRUD

Pros:

  • Teóricamente se agregó seguridad a través de límites de permisos.
  • Hace que el CMS esté seguro para evitar ataques de suplantación / reproducción.

Cons:

  • Código complicado dentro de un CMS (que es en lo que estoy pensando en usar esta función).
  • Obliga a que el CMS sea seguro (lo que no siempre será posible)

Mi pregunta es la siguiente:
¿Existe algún beneficio de seguridad al separar los roles y permisos de esta manera? En caso afirmativo, los beneficios de hacerlo justifican un código más complicado para forzar a un usuario a cambiar dependiendo de un acción?

Por ejemplo, digamos que la comprobación para ver si cambio de usuarios es solo una instrucción if, y si esa declaración falla, entonces el usuario no puede hacer ninguna acción, por lo que el interruptor no lo hace. En primer lugar, sucederá.

    
pregunta Mike S 27.04.2011 - 20:50
fuente

3 respuestas

6

En teoría, este tipo de cosas siempre debería ayudar (principio de privilegio mínimo) y realmente no puede hacer daño, pero si en la práctica terminas con un nivel intermedio de CMS con todas las credenciales de todos modos, entonces puede que no ayude mucho o en absoluto.

Una campana de alarma es que estás pensando solo en términos de inyección SQL. El principio de privilegio mínimo es tan fundamental que debería comprar mucha más protección que eso, debería estar cubriendo vías de ataque completas y clases de vulnerabilidad completas, no solo una.

Si existe o no un beneficio real, creo que depende de si también puede (por ejemplo) apuntar a una máquina y decir "esta máquina solo tiene privilegio de 'invitado', etc. En otras palabras, cuando mira Más allá de la base de datos, ¿es el argumento para la contribución de esto a la seguridad del sistema whole igualmente simple?

Si el resultado es solo una complejidad adicional del CMS, entonces podría ser contraproducente (es decir, la introducción de complejidad, tiende a generar más errores, algunos de los cuales tenderán a ser agujeros de seguridad por sí solos, especialmente si el error es en permisos de malabares). Otra campana de alarma es que pareces prever una maraña de códigos en el CMS. Esto puede o no ser necesario, sin embargo, ¿puedes hacerlo de manera más simple?

    
respondido por el frankodwyer 27.04.2011 - 21:58
fuente
1

Hacer algo más complejo nunca es bueno para la seguridad, pero por otro lado, otorgarle a alguien más privilegios de lo que necesita también puede comprometer la seguridad. Por lo tanto, es un equilibrio entre la complejidad de las características de seguridad adicionales o la simplicidad de las características adicionales. Lo que estás sugiriendo suena interesante. Sin embargo, mi sugerencia es centrar su atención en la creación de un filtro de desinfección de datos sólido. Impedir que la inyección de SQL llegue incluso a la base de datos.

    
respondido por el KilledKenny 27.04.2011 - 21:21
fuente
0

Use certificados de cliente SSL / TLS para una instancia de MySQL habilitada para SSL / TLS para cada aplicación. Hay un millón de cosas que hacer con la seguridad de MySQL y merece un conjunto de respuestas por separado.

Quizás esta pregunta sea el lugar correcto: MySQL Server Hardening .

    
respondido por el atdre 28.04.2011 - 01:44
fuente

Lea otras preguntas en las etiquetas

¿Hay alguna organización que revise / apruebe las implementaciones criptográficas? ¿Razón para prohibir dígitos como primer carácter en las contraseñas?