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;