Cifrado de base de datos o cifrado de nivel de aplicación?

Question

Cuando necesite almacenar datos sensibles, tales como los PC o los números de seguro social, trata de:

1) construir su propia rutina de cifrado dentro de la aplicación, defina una clave secreta en algún lugar de un archivo de configuración, y luego manualmente cifrar/descifrar datos yendo a la base de datos

2) Llevar todo el problema a la base de datos, usando las capacidades integradas de DB (creo que la mayoría de los proveedores lo llaman Cifrado transparente de la base de datos).

¿Qué concesiones ha encontrado para su solución? ¿La escritura de su propia rutina funciona mal cuando se compara con TDE? ¿Es el mantenimiento del código o, por el contrario, el bloqueo del proveedor de DB un problema?

Answer 1

He utilizado una variedad de técnicas de cifrado y creo que es más fácil y más seguro cifrar en el lado de la aplicación utilizando una rutina de cifrado comprobada (es decir, bibliotecas .NET).

Si cifra en la base de datos, eso significa que los datos se envían desde y hacia la base de datos en forma no encriptada. Esto potencialmente permite el espionaje/alteración entre la aplicación y las rutinas de encriptación en la base de datos. Incluso si almacena la clave en el lado de la aplicación, todavía se requiere en el lado de la base de datos para realizar el cifrado. Si la base de datos se ve comprometida, sus datos corren un serio riesgo (imagínense a alguien ejecutando el generador de perfiles mientras se ejecuta su aplicación).

Si cifra/descifra en la aplicación, los datos confidenciales (incluida la clave) nunca se revelan fuera del servidor de aplicaciones. Alguien tendría que comprometer tanto el servidor web como el servidor de la base de datos para acceder a todos sus datos.

Además, le recomiendo encarecidamente que no desarrolle su propia rutina de cifrado. Es probable que cometa un error que reduzca la seguridad general de su solución.

EDIT:

también quería añadir otro factor que influirá en su decisión. ¿Necesita consultar de esos datos encriptados? Si encriptas en el nivel de aplicación, necesitarás traer los datos a la aplicación, descifrarlos y trabajar desde allí. Esto se vuelve prohibitivo a medida que el conjunto de datos crece, mientras que con el cifrado de la base de datos puede filtrar los datos antes de enviarlos a la aplicación.

Answer 2

Estoy de acuerdo con Mayo, pero el cifrado en la base de datos podría simplificar el mantenimiento de todo el sistema.

El cifrado al nivel de aplicación necesita que administre las claves, la fase de autenticación y autorización para las claves y la visualización de los datos (de acuerdo con lo que Mayo haya escrito).

Si elige el Cifrado de la aplicación, debe preocuparse por la corrección del algoritmo, no solo en la fase de desarrollo, sino también en la fase de mantenimiento. Debe implementar la prueba unitaria para no regresión. Tienes que gestionar el cambio del algoritmo de cifrado porque tal vez quieras un algoritmo diferente y mejor.

Y debe asegurarse de que los datos encriptados siempre se descifrarán. No es algo obvio, porque el software tiene errores, etc. Los datos perdidos son peores que los datos claros ;-)

Seguro que puede utilizar una biblioteca de encriptación bien conocida, pero todas las demás cosas son un gran trabajo para usted.

El cifrado en el DB solo protege en la base de datos, pero puede considerar el uso de algún tipo de comunicación SSL con la base de datos. Creo (pero no estoy seguro) que TDE implemente este tipo de comunicación segura.

La aplicación se usa por parte del usuario, una entidad que no es de confianza. Debe tener en cuenta que los datos en la aplicación se pierden. ¿Por qué? Si quiero robar datos de un sistema que implementa Cifrado de los datos en el Nivel de la aplicación o el nivel de la base de datos, ¡podría usar una cámara fotográfica para obtener los datos! ¡Muy simple!

Debe tener en cuenta la seguridad del sistema, pero también la funcionalidad. Más es la Seguridad, menos es la Funcionalidad. Espero que mis consideraciones te sean útiles.

Answer 3

Cuando cifra datos confidenciales, básicamente está restringiendo el acceso a aquellos que tienen acceso a una clave. El problema se convierte entonces en uno de gestión de claves: garantizar que solo las personas/sistemas autorizados tengan acceso a la clave necesaria para descifrar los datos.

Por supuesto, debe utilizar un algoritmo de encriptación estándar, lo suficientemente fácil en estos días, pero lo que necesita pensar es sobre qué amenazas está protegiendo, cómo va a controlar el acceso a la (s) clave (s) y cómo controlas el acceso físico a los servidores.

El uso de TDE garantiza que los contenidos de una base de datos y sus copias de seguridad estén encriptados, con un impacto mínimo para los usuarios autorizados de la base de datos. Por lo tanto, cualquiera que pueda acceder al servidor de la base de datos con credenciales válidas podrá ver los datos no encriptados. Además, cualquier DBA generalmente tendrá acceso a la clave y podrá ver los datos no encriptados. Pero un tercero que, por ejemplo, se haga con una copia de seguridad externa no podrá acceder a los datos, lo que puede ser importante para el cumplimiento de los requisitos reglamentarios.

Por otro lado, si encripta en el nivel de aplicación, puede usar una clave a la que solo pueden acceder los administradores del servidor de aplicaciones. Esto potencialmente le brinda más seguridad, si, por ejemplo, el servidor de la base de datos y los administradores del servidor de aplicaciones se mantienen separados (por ejemplo, miembros de diferentes organizaciones). Los DBA que no tienen acceso a la clave del servidor de aplicaciones no podrán ver los datos.

En su publicación original, habla de ocultar una clave secreta en un archivo de configuración en el servidor de aplicaciones. En vista de esto, suena como el equivalente de seguridad de ocultar la llave de la puerta de entrada debajo del felpudo. Si hace esto, debe pensar en cómo se asegurará de que las personas no autorizadas no puedan acceder a la clave.

Answer 4

Ser PCI-DSS no elimina su responsabilidad legal ...

Actualmente sólo hay dos estados que proporcionan una exención de este tipo: Washington & Minnesota ... TDE Promover

de DBA como Solución PCI-DSS ¡TEN CUIDADO!

TDE sólo protege los datos en reposo, no los datos en tránsito o de datos en la memoria ... Cualquier persona a quien tenga acceso de lectura puede leer los todos los datos con cualquier herramienta ...

mi humilde opinión TDE es bueno cuando se combina con una sólida solución de encriptación de nivel de aplicación ... Como una solución independiente que utiliza TDE solo, es una bomba de tiempo que el PCI QSA está comprando como PCI-DSS obediente no ha tenido miserablemente en cuenta ... Espere a que los abogados entiendan este defecto fundamental ...

Cualquier gurú de seguridad le dirá capas de seguridad es el mejor enfoque ....