Antes de decidir sobre estos asuntos de seguridad, debe evaluar el modelo de amenaza. Sin una idea de contra qué te defiendes, cualquier medida que tomes tendrá 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, ingresando al centro de datos, robando cintas de respaldo, etc.)
- Los atacantes que obtienen acceso de lectura a su base de datos sin procesar
- atacantes que comprometen su aplicación, por ejemplo, a través de inyección SQL, saturación 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 acceso a la cabeza: robar el servidor o las cintas requeriría romper el cifrado a nivel de disco.
Para el segundo escenario, el cifrado de datos de la base de datos ayuda, pero solo si no almacena las claves o frases de contraseña necesarias en cualquier lugar.
En el tercer escenario, todo depende del contexto en el que ocurra el ataque: si es, por ejemplo, un ataque XSS o CSRF, entonces un atacante puede hacer todo lo que pueda hacer el usuario legítimo y no puede cifrar sus datos. ayuda en absoluto.
Su modelo de amenazas, 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 el exterior, o obteniendo acceso de root al servidor de la base de datos. Una ruta típica es obtener primero acceso de shell en el servidor web; desde allí, 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 dónde guardas las claves y las frases de contraseña, especialmente si estás utilizando una plataforma con un modelo de ejecución sin estado como PHP. Lo ideal es que el cliente escriba su contraseña cuando sea necesario, y la guarde solo en la memoria, o incluso mejor, realice el descifrado del lado del cliente (pero esto no suele ser posible). En una plataforma sin estado, el estado generalmente se realiza mediante sesiones, memcache, bases de datos o archivos sin formato; pero todos estos son mucho más vulnerables que mantener el estado en la propia memoria de una aplicación web con estado. Evitar esto es un problema de la gallina y el huevo, porque si encripta el estado antes de persistir, simplemente creó otro secreto que debe recordar de manera segura. Recordar la contraseña en el cliente y enviarla junto con cada solicitud que lo necesite puede ser la solución menos horrible en ese momento; el cliente sigue siendo vulnerable si tiene alguna fuga de XSS y necesita tomar las precauciones habituales (servir solo https, configurar todas las cookies como httponly y seguras, etc.), pero esos son problemas que tiene de todos modos.