¿Qué tan confiable puede ser el cifrado de datos sin volver a ingresar la contraseña en el inicio?

1

He publicado un comentario de vez en cuando , y pensé que lo convertiría en una pregunta.

Ejemplo: hay una característica en el Microsoft SQL Server para el cifrado completo de la base de datos , que parece tener una opción que no requiere una contraseña al reiniciar. Entiendo que puede usar DPAPI o EKM, pero todavía no estoy seguro de las limitaciones reales de dicho sistema.

En realidad no estoy interesado en la característica de Microsoft SQL Server específicamente, solo en las limitaciones de un esquema de cifrado teórico.

Pregunta: Dado que un servidor requiere que la clave de cifrado se pueda recrear sin requerir que un usuario ingrese un secreto, ¿Qué parte de la barrera se puede colocar contra el atacante?

Soy consciente de lo siguiente

  • Complejidad (el atacante puede no saber cómo descifrar sin mirar el código de mi programa)
  • Barreras de acceso del usuario (el sistema operativo puede almacenar la información de manera que las cuentas de usuario no puedan acceder sin la raíz)

Más allá de eso, Me faltan ideas concretas:

Si el atacante pudiera leer el disco, parece que no tendría protección. (a menos que haya utilizado un hardware de cifrado especial)

Finalmente, para que la clave se almacene en una computadora diferente, de nuevo, no veo cómo (suponiendo que se supere la Complejidad y la Seguridad a través de la Oscuridad) podría evitar que esa computadora diferente proporcione la clave necesaria al atacante que tiene acceso al servidor que normalmente está permitido.

Por lo tanto, cualquier orientación sobre un esquema de cifrado típico sería apreciada, y cuáles serían las limitaciones normalmente.

    
pregunta George Bailey 24.07.2012 - 18:46
fuente

1 respuesta

2

Las preguntas reales aquí son: ¿Qué parte de la barrera puede colocarse contra el QUÉ ? Si el sistema no necesita una contraseña en el arranque, entonces si un atacante tiene acceso físico, entonces es trivial evitarlo. Eso es bastante literario, no es una medida de seguridad y un ataque como el ataque de arranque en frío no es necesario.

Entonces, ¿qué pasa con MS-SQL? Bueno, este sistema de encriptación está impidiendo un ATENADOR REMOTO posiblemente con un error de inyección de sql a los datos confidenciales. Tenga en cuenta que si el atacante tiene una falla como SQL Injeciton, entonces el atacante NO DEBE tener acceso completo al disco, a menos que, por supuesto, tenga una aplicación web que use una cuenta sin restricciones como sa , que sería un problema mucho más grande .

Mover solo la clave a otra máquina realmente no ayuda, si la máquina comprometida puede acceder a la clave, entonces el atacante puede acceder a la clave. Lo que puede ayudar es crear un almacén de información confidencial. Así que en este modelo una aplicación web tiene dos bases de datos. Una base de datos para el almacenamiento de información no muy confidencial y otra base de datos solo para el almacenamiento de datos cifrados. La base de datos cifrada está diseñada para ser la más restrictiva, solo se accede a ella mediante una lista blanca de máquinas y la cantidad de consultas contra esta máquina se mantiene al mínimo. Las posibilidades de una falla de inyección de sql en esta base de datos son mucho menores.

    
respondido por el rook 24.07.2012 - 19:42
fuente

Lea otras preguntas en las etiquetas