¿Cuál es la mejor manera de cifrar datos confidenciales almacenados en una base de datos?

Luché con la misma pregunta. Esto es a lo que llegué, lo que implementamos y con lo que estamos contentos.

Ciframos y desciframos todo en la aplicación, Java.

Razones:

• Usamos la base de datos como servicio. Si utilizamos el cifrado integrado en la base de datos, la empresa que proporciona la base de datos puede potencialmente descifrar los datos. Si nos ciframos, es un vector de ataque menos.
• Separación de inquietudes que nos gustan. El DB lee y escribe datos. El módulo de cifrado hace cifrado. Imho cómo debería ser el código. Mejor legibilidad, facilidad de mantenimiento y más fácil de probar.
• Es probable que almacene datos en más lugares que la base de datos principal. Por ejemplo, en la base de datos de memoria, una base de datos de valores clave, registros, etc. Con el cifrado separado, la adición de almacenamiento de datos se vuelve más fácil. Y solo un sistema de encriptación para comprender y mantenerse seguro.

Una cosa que hicimos y que estoy muy contento son los prefijos de versión de cifrado. Por ejemplo, v11_thisisencrypteddata. Es decir, cada cifrado (algo + clave (s)) tiene su propio prefijo de versión.

Esto nos permite

• Usar diferentes cifrados para diferentes conjuntos de datos. Incluso varias claves dentro del mismo conjunto de datos.
• Actualización de cifrados a medida que cambian los requisitos de seguridad. DES fue considerado seguro hace unos años.
• Sustitución de llaves que pueden haber tenido fugas o sospecharse que se han roto.
• Reemplazar gradualmente un tiempo de ejecución de cifrado.

Depende de cuán sensibles sean los datos.

Tener claves de descifrado (ya sea clave simétrica o clave privada) en el mismo host con DB es una mala llamada. En caso de que el host se vea comprometido, toda su base de datos es tan buena como el texto sin formato. Incluso si usa el cifrado de la capa de aplicación, no será difícil realizar ingeniería inversa sobre los algoritmos exactos que se usaron, y su base de datos es tan buena como el texto sin formato nuevamente.

Lo que haría es generar un par de claves fuerte. Mantenga la clave pública con la aplicación, lo que permitirá escrituras cifradas en su base de datos. Luego, dividiría la clave privada usando Shamir’s Secret Sharing [1] en múltiples recursos compartidos, y requeriría un grupo de hosts con seguridad (bastión) para recuperar dicha información, posiblemente a través de un protocolo de chismes [2] de algún tipo.

Rota tus llaves periódicamente.

De esa manera:

• comprometer su DB produce solo texto cifrado
• comprometer su aplicación solo produce claves públicas, que no permiten el descifrado
• comprometer un número suficiente de recursos compartidos de clave privada requerirá violar múltiples hosts de bastión

Notas al pie

[1] El intercambio secreto de Shamir – Wikipedia

[2] Protocolo de chismes – Wikipedia