¿Qué es una buena estrategia de cifrado de datos para un recurso compartido (texto)?

Alguien que irrumpa en su servidor se irá con el software y las bases de datos. Teniendo todos sus factores, entonces podrán ejecutar la estrategia de descifrado a la inversa para recuperar toda la PII.

En la autenticación multifactor, los factores adicionales no cuentan si se los robarían al mismo tiempo que un factor existente. Por ejemplo, un token de hardware es un factor diferente de una contraseña, ya que un registrador de claves (la forma típica de robar la contraseña), al ser software, no podría robar el token de hardware al mismo tiempo.

Si he entendido correctamente tu pregunta, estás intentando reforzar los datos contra un atacante que podría tomar un control parcial de tu centro de datos. No olvide que una vez que se comprometa una parte de un centro de datos, se asume que la zona completa accesible desde el punto de vista administrativo está comprometida. Eso significa que no es suficiente separar la información en 3 servidores diferentes, sino que 3 servidores deben estar en 3 zonas diferentes con un firewall estricto entre ellos para garantizar que solo se pueda intercambiar la información requerida. O al menos, la base de datos segura y la base de datos normal no deben estar en la misma zona.

En particular, la aplicación solo debe poder obtener la clave de cifrado / descifrado a través de un servicio web y presentando las credenciales que demuestren que lo hace en nombre de un usuario autorizado. Eso significa que tendrá que configurar un sólido sistema de autenticación y autorización y examinar a fondo todas las implicaciones de seguridad. Y también debe configurar auditorías de código para controlar que la aplicación no mantenga esa clave por más tiempo del necesario

Lo que quiero decir es que es necesario usar un sistema de cifrado sólido, pero es solo la parte visible de lo que se debe hacer para aumentar la seguridad. La parte esencial no será solo técnica, sino que incluirá la organización y una definición precisa de qué privilegios se otorgan a quién y a qué servidor se le permite comunicarse con el otro. También debe considerar cómo se realizan las copias de seguridad porque son una parte esencial en un sistema seguro porque deben ser robustas pero no demasiado accesibles. En mi humilde opinión, también debe analizar el valor de los datos y los riesgos a los que está expuesto. Porque configurar un sistema seguro no vendrá sin un costo.

TL / DR: no hay fallas evidentes en lo que describe, pero lo que falta es la definición de la segregación entre las diferentes partes, porque el diablo se esconderá en tales detalles.

Sé que mencionó que tiene las dos bases de datos segregadas, sin embargo, obviamente se comunican de alguna manera, por lo que consideraría que ambas están en riesgo si su red está comprometida, lo que significa que podrían considerarse solo como un factor.

Tener un token físico separado sigue siendo una buena idea, obviamente, pero mi mensaje es que usar 2 bases de datos puede no ser mucho mejor que usar 1.

Tal vez una forma de mejorar la seguridad no sea codificar la "clave maestra" en el software, sino obtener el tiempo de ejecución de otro servidor. Al menos de esa manera, el atacante no puede simplemente alejarse con software y bases de datos, sino que debe crear un volcado de memoria para obtener la clave maestra o incluso atacar al servidor de claves.

Si lo que está haciendo es un proyecto a gran escala como mencionó, mi recomendación es ir con soluciones comerciales que aborden precisamente eso.

Usted conoce el consejo habitual: no haga rodar los suyos cuando se trata de criptografía / cifrado. Hay muchas maneras en que su estrategia puede salir mal. Es mejor revisar una solución probada y hay algunas que creo que se adaptarían exactamente a sus requisitos.

En pocas palabras, desea una solución que tenga cifrado a nivel de columna, que proporcione diferentes claves de cifrado / descifrado para cada columna y que le permita definir políticas de control de acceso por columna.

La solución también debería ayudarlo a almacenar y administrar sus claves en un servidor separado (preferiblemente HSM) y garantizar una transmisión segura de las claves entre los servidores.

Como revelación, he trabajado como consultor de cifrado de bases de datos durante bastante tiempo, pero nuevamente, esto me pone en una posición para darle un consejo de "He estado allí, he hecho eso". / p >

He consultado para muchos clientes que tienen requisitos muy estrictos de seguridad y rendimiento. No estoy seguro de qué DBMS está utilizando, pero si está utilizando una base de datos de código abierto, puede encontrar mydiamo para tener todo lo que está buscando. Si está utilizando DBMS comerciales, este compañero y o esto tiene soluciones bastante bien probadas.

HSMs

Una práctica bastante común en tales contextos es tener la "clave maestra" de su escenario para que resida en un módulo de seguridad de hardware, por lo que nunca la abandona y puede descifrar las claves específicas de los datos cuando sea necesario.

Como se describe actualmente, su software parece ser un punto único de falla: una vulnerabilidad en su aplicación tendría acceso a la clave maestra y probablemente también acceso de lectura a ambas bases de datos. Si realmente desea una "defensa en capas", entonces debería asegurarse de que el sistema que tiene acceso a todos los datos no pueda descifrarlos, y el sistema que puede descifrar los datos no puede acceder a todos los datos.