¿Por qué usaría el cifrado en reposo sobre el cifrado basado en clave de un DB?

Question

¿Por qué usaría el cifrado en reposo sobre el cifrado basado en clave de un DB?

Navega tus respuestas

#1 de Jonah Benton (2 votos)

8

Objetivo

Quiero almacenar datos cifrados en una base de datos.

Restricciones

El cifrado a nivel de la aplicación (cifrar antes de enviar a la base de datos) no es una opción razonable para mi caso de uso.
Los proveedores de DB que estoy considerando no me permiten crear múltiples usuarios / administrar permisos al precio que pagaré. Esto significa que separar los permisos para los registros frente a las lecturas y escrituras no es una opción.

Opciones

Permitir que MySQL maneje el cifrado AES (a través de aes_encrypt/decrypt ) para mí (soy consciente del problema del bloque ECB y del hecho de que MySQL registra datos confidenciales en texto sin formato si no se configura correctamente)
Utilice un proveedor de bases de datos que ofrezca cifrado en reposo (el tipo que ocurre de forma transparente: encripte automáticamente en SET y descifre en SELECT )

Preguntas

Pregunta 1

¿Por qué alguna vez elegiría este tipo de cifrado en reposo sobre aes_encrypt ? (Como nota, no estoy almacenando información de la tarjeta de crédito o cualquier otra cosa que me aliente legalmente a cifrar en silencio).

Tal como lo entiendo, el punto de cifrar los datos en la base de datos es confrontar la realidad de que se producen violaciones de la base de datos. Teniendo eso en cuenta, si alguien obtiene acceso a mi base de datos (lo que significa que puede ejecutar consultas), ¿este tipo de cifrado en reposo no les ayudaría realmente porque simplemente descifraría los datos cuando SELECT ? Me parece que está ralentizando las consultas sin agregar seguridad.

aes_decrypt , por otro lado, requiere que el intruso tenga acceso a una clave almacenada en una máquina diferente detrás de credenciales diferentes. ¿No es eso más seguro?

Pregunta 2

En el escenario que describí en la pregunta 1, un atacante obtuvo acceso de consulta a una base de datos. Si ese es el caso, ¿no podrían simplemente habilitar el registro y recuperar la clave AES de texto sin formato, lo que también hace que aes_encrypt sea inútil?

(Recuerde la restricción número 2 aquí.)

Pregunta 3

Excluyendo la inyección de sql, ¿hay otros escenarios en los que un atacante podría ver lo que hay en mi base de datos sin ejecutar un SELECT y, por lo tanto, sin activar un descifrado transparente en reposo?

¿Recomendaciones?

Si tiene alguna recomendación que se ajuste a mis limitaciones, hágamelo saber. ¡Gracias!

encryption aes databases mysql

pregunta jpodwys 12.05.2016 - 21:27

fuente

1 respuesta

Lea otras preguntas en las etiquetas encryption aes databases mysql

Problemas al construir una cadena ROP Conexión a la memoria de Firefox

score 2 · Answer 1

Encriptación transparente vs manual

El cifrado transparente puede ser más fácil y seguro, ya que el proveedor es responsable de la administración de claves. Para ellos, esto es solo otra tarea operativa, junto con las copias de seguridad, la supervisión y la replicación, etc.

Es muy fácil arruinar la administración de claves, desde recoger las claves incorrectas hasta perderlas y exponerlas a no rotarlas correctamente, al igual que es fácil arruinar otras actividades operativas. Y al igual que con las copias de seguridad, si las claves se pierden, entonces se pierden los datos. ¿Qué problemas quiere uno gastar su tiempo resolviendo?

En cuanto a los escenarios de ataque, hay muchos que considerar: los atacantes podrían tener la capacidad de monitorear pasivamente el tráfico en la red entre la aplicación y la base de datos; podría tener la capacidad de leer datos de sistemas de archivos de aplicaciones o bases de datos; Podrían tener acceso a discos físicos; podría tener acceso a las credenciales de la cuenta; Podría tener un webshell operando en la aplicación. En la mayoría de los escenarios, el cifrado transparente y manual son igualmente vulnerables.

Sin duda, es posible que un atacante tenga acceso a las credenciales de la base de datos pero no a la aplicación, por lo que es posible que haya un obstáculo adicional que deben superar en el caso de cifrado manual. Pero alguien que realiza el cifrado manual tiene que haber hecho muchas cosas bien, y un atacante determinado con acceso a datos cifrados tiene muchos caminos potenciales para avanzar. La cantidad de violaciones de datos en las que se informa que los datos se han cifrado o hash, pero luego se exponen, es incontable.
Acceso de consultas y registro de consultas

El acceso de consulta a una base de datos no es lo mismo que el acceso administrativo, que generalmente se requiere para habilitar el registro. Sin embargo, al hablar específicamente sobre las ofertas de los proveedores, las credenciales para el acceso a las consultas también pueden usarse para configurar algún panel de control del proveedor, lo que probablemente permitiría habilitar algún tipo de registro de consultas.

Pero retroceda un paso: en el caso común, el impacto de un atacante que logra acceder a la base de datos, especialmente el acceso de escritura, no cambia según si los datos están encriptados o no. Tomando una página de los ataques de ransomware, podrían ejecutar su propia "UPDATE $ table SET $ encrypted_column = aes_encrypt (encrypted_column, 'attacker-key');" y requiere que la clave de descifrado de la víctima, o solo dinero, devuelva la custodia de los datos cifrados.
Acceso a datos fuera de la inyección de SQL o el motor de consulta

Como se mencionó anteriormente, hay muchos escenarios en los que un atacante puede ver lo que hay en la base de datos sin pasar por el motor de consultas. Alguien puede tener visibilidad en la red. Alguien puede ver los archivos de datos que usa la base de datos. Alguien puede llegar a los discos físicos a medida que se hacen girar fuera de servicio. Alguien puede llegar a las copias de seguridad. Todas estas cosas pasan todos los días.

Recomendación: a falta de un requisito de cifrado en reposo y escenarios específicos que deben ser defendidos y que requieren un tratamiento o consideración especial, simplemente deje que el proveedor ejecute el programa.