Una de las cosas que siempre me ha molestado sobre el cifrado simple de datos de la base de datos: si el servidor está comprometido, la base de datos está comprometida efectivamente. El atacante puede usar el mismo código que la aplicación para consultar los datos como desee. Una simple revisión del código de la aplicación mostrará dónde / cómo se almacena la clave y cuáles son los parámetros de conexión de la base de datos.
Por supuesto, el cifrado de los datos puede ser útil cuando se almacenan copias de seguridad fuera del servidor, etc., pero para este fin, los archivos de la copia de seguridad podrían cifrarse completamente, en lugar de los campos, ahorrando algunos dolores de cabeza con consultas, etc.
En general, asegurarse de que el servidor esté seguro es la mejor práctica. Pero, ¿qué pasa si los datos deben protegerse de todos, incluidos los administradores de sistemas (de manera similar a como tratamos las contraseñas de los usuarios, a través de hashing)?
En última instancia, me pregunto cómo puede protegerse una clave de cifrado, de modo que nadie pueda acceder a ella sin el secreto, ni siquiera el código de la aplicación. El único enfoque que se me ocurre es que el usuario debe proporcionar la clave en tiempo de ejecución (no se conserva en el equipo host, punto).
Me imagino que el primer problema es que si un usuario tiene acceso al servidor, probablemente haya una forma de que el secreto pueda ser detectado en el punto de entrada, o si la clave está almacenada en la memoria por la aplicación (por ejemplo, en una variable de sesión) esto también podría ser explotado.
¿Cuáles son los otros problemas (probablemente evidentes) con este enfoque? ¿Esto es solo reinventar la rueda? Si es así, ¿cuál es la mejor práctica cuando la seguridad de los datos es crítica, incluso para los roles de superusuario?
Esta pregunta puede ser algo similar a: Cómo iniciar sesión y cifrar datos con la misma contraseña / clave , excepto que estoy preguntando si el concepto es incluso bueno, no cómo implementar.