Alguien que ingrese a su servidor se llevará el software y las bases de datos. Teniendo todos sus factores, 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 serían robados en el al mismo tiempo que un factor existente. Por ejemplo, un token de hardware es un factor diferente de una contraseña, porque 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 su pregunta, está intentando proteger los datos contra un atacante que podría tomar un control parcial de su centro de datos. No olvide que una vez que una parte de un centro de datos se ve comprometida, se asume que la zona completa accesible administrativamente desde allí está comprometida. Eso significa que no es suficiente segregar la información en 3 servidores diferentes, sino que 3 servidores deben estar en 3 zonas diferentes con un cortafuegos 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 deberían estar en la misma zona.

En particular, la aplicación solo debería poder obtener la clave de cifrado / descifrado a través de un servicio web y presentando la 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 más tiempo del requerido

Lo que quiero decir es que es necesario usar un sistema de cifrado fuerte, 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 implicará la organización y una definición precisa de qué privilegios se otorgan a quién y qué servidor puede comunicarse con qué 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 sólidas 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án expuestos. Porque configurar un sistema seguro no vendrá sin 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 ha mencionado que tiene las dos bases de datos segregadas, sin embargo, obviamente se comunican de alguna manera, por lo que las consideraría a ambas en riesgo si su red se ve comprometida, lo que significa que podrían considerarse como un solo 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.

Quizás una forma de mejorar la seguridad no es codificar la 'clave maestra' en el software, sino recuperarla en tiempo de ejecución desde otro servidor. Al menos de esa manera, el atacante no puede simplemente irse con el software y las bases de datos, sino que tiene que crear un volcado de memoria para obtener la clave maestra o incluso atacar el servidor de claves.

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

Ya conoce el consejo habitual: no haga el suyo cuando se trata de criptografía / cifrado. Hay muchas formas en las que su estrategia puede salir mal. Es mejor comprobar una solución probada y hay algunas que creo que se ajustan 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 le da la capacidad de 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 divulgació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 "He-estado-allí-hecho -eso "consejo.

He consultado a muchos clientes que tienen requisitos de seguridad y rendimiento muy estrictos. 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 utiliza DBMS comercial, esta empresa o esta tienen soluciones bastante probadas.

HSM

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

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