¿Debo encriptar datos en la base de datos?

Tengo un cliente, para lo cual voy a hacer una aplicación web sobre atención al paciente, manejo de pacientes, consultas, historial, calendarios, básicamente todo sobre eso.

El problema es que se trata de datos confidenciales, historial del paciente y demás.

El cliente insiste en cifrar los datos a nivel de la base de datos, pero creo que esto va a deteriorar el rendimiento de la aplicación web. (Pero tal vez no debería estar preocupado por esto)

He leído las leyes sobre protección de datos en temas de salud (Portugal), pero no soy muy específico al respecto (solo les pregunté sobre esto, estoy esperando su respuesta).

He leído el siguiente enlace , pero mi pregunta es diferente, ¿debería cifrar los datos en la base de datos o no?

Un problema que preveo al cifrar datos es que necesitaré una clave, esta podría ser la contraseña del usuario, pero todos sabemos cómo son las contraseñas de los usuarios (12345, etc., etc.) y generar una clave que tendría que almacenar en algún lugar, esto significa que el programador, dba, lo que sea que tenga acceso a él, ¿tiene alguna idea al respecto?

Incluso agregar una sal aleatoria a la contraseña del usuario no va a resolver el problema, ya que siempre puedo acceder a ella y, por lo tanto, descifrar los datos.

Yo personalmente verificaría las leyes sobre esto. Si los datos necesitan ser encriptados, entonces deben estar encriptados.

Sin embargo, si no recibe ninguna orientación, trataría de proteger el vínculo entre el paciente y sus datos. Es decir, lo más probable es que tenga un PatientIDque se utiliza en tablas en toda la base de datos. PatientIDno identifica a un paciente, solo el historial médico del paciente, etc. Sin embargo, para identificarlo PatientIDcomo Joe Bloggs que vive en la Rua de São Bernardo de Lisboa, lo mantendría en una base de datos separada si pudiera. Use TDE para los datos personales del paciente y considere encriptarlo además de usar claves en su aplicación web.

Si bien el robo de esos datos médicos sin los medios para identificar a los pacientes será extremadamente vergonzoso, es poco probable que haya algo más allá de eso. Literalmente, hay concursos en línea que utilizan estos datos médicos anónimos.

Con la separación de los datos médicos de los datos personales del paciente. Use un conjunto robusto de roles para limitar el personal solo a lo que necesitan. Con la excepción del personal médico que requiere tratar al paciente directamente (enfermeras y médicos de primera línea), nadie debe tener acceso a ambos. Los recepcionistas solo necesitan los datos personales del paciente, el personal del laboratorio solo necesita el registro médico y la identificación del paciente, las enfermeras quirúrgicas solo la condición médica actual y el nombre.

Cuando haya identificado cada conjunto de roles, procure no solo implementarlos en su aplicación web, sino también en la base de datos, así como una capa adicional de seguridad.

Sí, debes encriptar la base de datos.

El cifrado básico para los datos almacenados ("datos en reposo") es un principio de seguridad generalmente aceptado, y probablemente es obligatorio por ley si su país tiene leyes que protejan la información personal o de salud.

Estamos usando SQL Server 2008, así que usamos el TDE de Microsoft; puede haber alguna solución de terceros para MySQL o tal vez solo funcionaría un enfoque de cifrado de volumen general (como TrueCrypt) (aunque me gustaría tener algo que haya sido certificado para su uso con una base de datos).

Si se hace correctamente, el rendimiento debe ser pequeño.

Por cierto, el enlace que mencionó (con respecto a la separación de información confidencial) es algo que debe considerar además del cifrado básico de la base de datos.

EDITAR: el cifrado mencionado anteriormente cifraría el volumen. Si alguien robara el disco duro, encontrarían los datos cifrados. Sin embargo, si alguien ejecutara consultas en la base de datos, vería los datos no cifrados (es por eso que mencioné la separación de información, a pesar de que el OP no quería discutir esto).

Tenga en cuenta que esta recomendación se entiende como el mínimo que debe hacer. Si desea asesoramiento legal, entonces, por supuesto, tendrá que buscar en otro lado. Si desea una discusión más exhaustiva sobre la escritura de código seguro, comenzaría con el libro Writing Secure Code .

Antes de decidir sobre tales asuntos de seguridad, debe evaluar el modelo de amenaza. Sin una idea de lo que estás defendiendo, cualquier medida que tomes probablemente sea de poco valor.

Ahora, hay algunas cosas de las que podría preocuparse en este contexto:

• Los atacantes obtienen acceso físico a sus datos (por ejemplo, irrumpir en el centro de datos, robar cintas de respaldo, etc.)
• Los atacantes obtienen acceso de lectura a su base de datos sin procesar
• Atacantes que comprometen su aplicación, por ejemplo, mediante inyección SQL, desbordamiento de búfer, etc.

Para el primer escenario, el almacenamiento de la base de datos y todas las copias de seguridad en volúmenes cifrados debería funcionar, siempre que el servidor no tenga cabeza; robar el servidor o las cintas requeriría romper el cifrado a nivel de disco.

Para el segundo escenario, encriptar los datos de la base de datos ayuda, pero solo si no almacena las claves o frases de acceso requeridas en ningún lado.

En el tercer escenario, todo depende del contexto en el que ocurre el ataque: si es, por ejemplo, un ataque XSS o CSRF, entonces un atacante puede hacer cualquier cosa que el usuario legítimo pueda hacer, y el cifrado de sus datos no ayuda en absoluto .

Su modelo de amenaza, por lo tanto, es un atacante que obtiene acceso de lectura a la base de datos sin procesar, ya sea encontrando las credenciales de inicio de sesión y logrando iniciar sesión en el servidor de la base de datos desde afuera, o obteniendo acceso raíz al servidor de la base de datos. Una ruta típica es obtener primero acceso de shell en el servidor web; a partir de ahí, un atacante puede leer las credenciales de acceso del archivo de configuración y conectarse a la base de datos.

Una consideración adicional es donde guarda las claves y las frases de contraseña, especialmente si está utilizando una plataforma con un modelo de ejecución sin estado como PHP. Idealmente, debe hacer que el cliente escriba su frase de contraseña cuando sea necesario y que la guarde solo en la memoria, o incluso mejor, realice el descifrado del lado del cliente (pero esto no suele ser factible). En una plataforma sin estado, el estado generalmente se transmite mediante sesiones, memcache, bases de datos o archivos planos; pero todos estos son mucho más vulnerables que mantener el estado en la memoria de una aplicación web con estado. Evitar esto es un problema de huevo y gallina, porque si encriptas el estado antes de persistirlo, acabas de crear otro secreto que debes recordar con seguridad. Recordar la frase de contraseña en el cliente y enviarla junto con cada solicitud que la necesite puede ser la solución menos horrible entonces;

Ignorando por un momento lo que el cliente está pidiendo, y cualesquiera que sean las leyes ...

No, probablemente no debería cifrar los datos. Si lo hace, no podrá buscarlo fácilmente. Por ejemplo, ¿cómo buscaría un apellido like 'Smith%'si cada entrada de nombre está encriptada? ¿Cómo graficaría la presión arterial de un paciente con el tiempo si no puede select .... from.... where patient_id = N?

Obviamente, debe asegurarse de que el servidor esté bien protegido, la conexión de red y la interfaz de usuario estén debidamente protegidas (incluidos los tiempos de espera de sesión para que los usuarios no puedan abandonar el acceso a cualquiera que use su computadora). También es posible que desee cifrar las copias de seguridad de la base de datos. Y asegure físicamente la sala en la que se encuentra el servidor. Pero no cifraría los datos en vivo.

Aclaración: Esto supone que lo que preguntaba el OP es en realidad cifrar los datos en la base de datos. No es el sistema de archivos en el que reside la base de datos.

Si desarrolla la aplicación web con cuidado utilizando un marco MVC efectivo como CakePHP. Zend o Rails, entonces debería poder habilitar / deshabilitar el cifrado en el nivel modal de datos.

CakePHP, por ejemplo, tiene algunos ejemplos de Comportamientos para los modos que encriptan datos. Hacer el proceso transparente para los Controladores y Vistas.

Ignorando problemas sobre indexación y otros problemas técnicos de la base de datos al hacer esto. Debería ser posible tener esto como una opción configurable.

Además, activaría el cifrado más adelante o solo en el servidor de producción. Los datos cifrados son difíciles de depurar y trabajar durante el desarrollo, y solo se pueden hacer en ciertas columnas.

Sí, debes encriptar la base de datos.

Como se trata de información personal y confidencial, definitivamente creo que debería.

A partir de la contraseña, puede derivar una clave de cifrado que solo almacena para la sesión. De esa manera, no se almacena en ningún lado y nadie (incluidos los DBA) puede saberlo, ya que nadie puede saber la contraseña tampoco. Cualquiera que intente ver la base de datos directamente estará viendo galimatías. La única forma de corromper esto es a través del secuestro de sesión, pero supongo que las sesiones también son seguras.

Me pregunto por qué el cliente le pide que cifre la base de datos. Si él le pidiera que proteja los datos, estaría de acuerdo, pero ya tiene una implementación implícita en mente. Entonces, mientras no sepa exactamente de qué está hablando, solo está lanzando palabras de moda desde mi punto de vista.

También me parece muy inútil cifrar el DB, porque estoy convencido de que, literalmente, todos los DBMS principales tienen en cuenta la seguridad de manera adecuada y probablemente mejor de lo que usted podría hacerlo. Para acceder al DB a través del DBMS necesitaría credenciales. En el caso de una base de datos cifrada, también necesitaría esas credenciales, y para descifrar los datos, necesitaría las credenciales que ya parece tener.

Siguiendo esta mentalidad, propongo dejar que el DBMS maneje la seguridad y poner esfuerzos para proteger las credenciales desde la entrada del usuario hasta el acceso a la base de datos, también puede forzar contraseñas seguras y cambios periódicos.