¿Cuáles son los beneficios de seguridad para una base de datos de usuarios separada?

Question

¿Cuáles son los beneficios de seguridad para una base de datos de usuarios separada?

#1 de George Bailey (15 votos)
#2 de robob (3 votos)
#3 de Ian Ringrose (1 votos)

13

En la aplicación que estoy escribiendo, separé el usuario y las bases de datos principales hace mucho tiempo por "razones de seguridad". Sin embargo, cada vez es más difícil justificar la sobrecarga y la dificultad de administrar dicha configuración.

Para algunos detalles rápidos, esta es una aplicación web PHP. Hay 2 conexiones mysqli separadas, una para cada base de datos. Cada base de datos tiene su propio usuario con sus propias credenciales. Esto significa que no puede acceder a la base de datos principal con las credenciales de la base de datos del usuario

En teoría, esto evita daños por inyección de SQL, separación de preocupaciones, seguridad a través de la oscuridad, etc. Sin embargo, en una relación costos / recompensas, pierdo la interoperabilidad fácil con la tabla de usuario y el resto de la base de datos, por ejemplo, las uniones.

¿Existen razones más concretas para que una configuración de base de datos de este tipo tenga sentido? ¿Es esto incluso común?

databases

pregunta TheLQ 02.01.2012 - 21:02

fuente

3 respuestas

Lea otras preguntas en las etiquetas databases

¿Puedo especificar un archivo de clave pública en lugar de un destinatario al cifrar con GPG? ¿La redirección abierta es un problema de seguridad?

score 15 · Answer 1

En lugar de dos conexiones separadas trabajando juntas, puede usar cuentas de usuario separadas con acceso a columnas específicas. La mayoría de sus estados de cuenta pueden usar la cuenta de usuario que tiene acceso solo a la columna de nombre de usuario (no a la contraseña) de la tabla de usuarios, y los datos menos importantes de su base de datos principal.

En MySQL, puedes hacer esto con buena granularidad. Esto le permitirá mostrar los nombres de usuario de todos, y solo acceder a las contraseñas en las páginas de inicio de sesión, y solo acceder a las sesiones en la administración de sesiones, solo acceder a las direcciones de correo electrónico en los notificadores, etc.

Con este modelo, las inyecciones de SQL generalmente se limitarán a la información pública, o la única sección a la que llegan.

Por supuesto, lo que es público, cómo están configurados sus usuarios, cuántos, lo que obtienen es específico para su caso de uso.

Consulte la GRANT documentation para su versión de MySQL.

Descargo de responsabilidad: esta no es una solución a la inyección SQL, solo un esfuerzo para ayudar a minimizar el impacto.

score 3 · Answer 2

si la aplicación que accede a las dos bases de datos diferentes es la misma, la separación de las bases de datos no es tan útil. Complican CADA fase de programación y pregunta relacionada con DATOS. Preferiría una separación lógica en lugar de una separación física de los datos.

Es lo mismo con dos cajas fuertes: si tiene las 2 teclas en el mismo lugar, ¿cuánta seguridad hay para las dos cajas fuertes?

El balance de "usabilidad frente a seguridad" aquí pierde mucha más facilidad de uso con respecto a la seguridad.

score 1 · Answer 3

Depende .....

Por ejemplo, los PIN de los bancos en su propia base de datos, en su propio servidor. El servidor también elimina automáticamente los datos si alguien intenta eliminarlos del rack.

Una buena razón para una base de datos independiente es si desea que sus clientes le envíen una base de datos cuando se encuentren con un error. Si la base de datos no contiene ninguna contraseña, puede haber menos problemas.

Creo que una base de datos separada solo tiene sentido si te permite administrar las dos bases de datos de una manera diferente.