Almacenamiento de información confidencial en DB con claves asimétricas públicas / privadas

El uso de PKI (Infraestructura de clave pública) para esto no tiene mucho sentido si sus usuarios son usuarios reales de su sitio web / servicio. HTTPS ya está haciendo el cifrado de la capa de transporte para usted.

Lo que debes hacer es la tokenización de datos + cifrado + compartimentación.

Una posible solución sería configurar una base de datos y un servidor dedicados que estén separados del resto del ecosistema de su aplicación y utilizar el cifrado de datos en reposo para su base de datos. Además de esto, también puede usar el cifrado de nivel de aplicación para ser más seguro. (Todo esto hecho utilizando AES).

Esta base de datos sería la única responsable de almacenar esta PII (SSN en su caso) y, por lo tanto, asociaría cada SSN con un UUID aleatorio que puede usarse en su "base de datos de la aplicación principal" en función de los datos cifrados reales. Este UUID aleatorio es esencialmente su clave externa para los datos confidenciales almacenados en la base de datos cifrada segura.

Esto le permite implementar políticas de ACL y permisos más estrictos que rigen el acceso a la base de datos cifrada. Para leer y escribir puede tener políticas de acceso separadas, con claves de acceso separadas para leer y escribir.

No necesita criptografía de clave pública para esto. El estándar AES debería estar bien.

Obtenga un HSM (Yubico hace uno razonablemente barato). Esto hace el cifrado y descifrado por usted. La llave nunca abandona el dispositivo.

Debería realizar el cifrado / descifrado en el servidor de aplicaciones

Si lo que está describiendo es un proyecto que involucra información privada de personas reales, recomiendo buscar soluciones de cifrado de DB profesionales / comerciales en lugar de intentar implementar el cifrado por su cuenta.

Ya sabes el dicho común de que no deberías hacer tu propio . Parafraseando un comentario, leí una vez en alguna parte: "A menos que haya escrito un doctorado sobre el tema, no está calificado para escribir su propio algoritmo de cifrado".

Pero incluso si utiliza un algoritmo probado como RSA, AES, etc., hay muchas cosas que pueden salir mal durante la implementación.

Esto es especialmente cierto cuando se trata de cifrado de base de datos.

Desea asegurarse de estar usando el algoritmo más seguro, pero también lo está implementando de una manera que no comprometa el rendimiento de su base de datos.

Debe saber que es usando el modo de cifrado de bloque adecuado o aplicando el vector inicial correctamente. Debe saber que su cifrado no sabotea sus modelos de datos, relaciones o formatos existentes. Vaya a soluciones con tecnología de cifrado de preservación de formato.

Debe asegurarse de que su implementación cuida el ciclo de vida de la clave de cifrado y aplique las auditorías adecuadas en cada una de las columnas cifradas.

Te lo digo como alguien que ha estado allí. A menos que sea solo un proyecto favorito, opte por soluciones probadas y comprobadas en ese mercado que se ajusten a sus necesidades particulares. No nos dice mucho acerca de qué DBMS está utilizando (puede que sea muy importante), pero me imagino que es un DB relacional. Dado que no tendrá que cifrar todo en la base de datos, le recomendaría utilizar el cifrado basado en columnas. De esa manera, podrá establecer políticas / claves de cifrado y control de acceso específicas para cada una de las columnas. También puede aumentar el rendimiento general posterior al cifrado.

Si está utilizando RDBMS de código abierto esta puede ser una buena solución para su caso. Para RDBMS comerciales, los proveedores generalmente tienen el cifrado basado en columnas correspondiente o puede consultar this o this o esto .

Espero que la respuesta ayude.