Memorizzazione di informazioni sensibili nel DB con chiavi asimmetriche pubbliche / private

L'uso di PKI (Public Key Infrastructure) per questo non ha molto senso se i tuoi utenti sono utenti reali del tuo sito web / servizio. HTTPS sta già eseguendo la crittografia del livello di trasporto per te.

Quello che dovresti fare è la tokenizzazione dei dati + crittografia + compartimentazione.

Una possibile soluzione sarebbe quella di impostare un database e un server dedicati che siano separati dal resto dell'ecosistema delle applicazioni e utilizzare la crittografia data-at-rest per il proprio database. Oltre a questo, puoi anche usare la crittografia a livello di applicazione per essere più sicuro. (Tutto questo fatto usando AES).

Questo database sarebbe il solo responsabile per l'archiviazione di queste PII (SSN nel tuo caso) e pertanto assocerebbe ogni SSN a un UUID casuale che può essere utilizzato nel "database delle applicazioni principali" in base ai dati crittografati effettivi. Questo UUID casuale è essenzialmente la tua chiave esterna per i dati sensibili memorizzati nel database crittografato sicuro.

Ciò consente di mettere in atto ACL e policy di autorizzazione più rigidi che regolano l'accesso al database crittografato. Per la lettura e la scrittura è possibile avere politiche di accesso separate, con chiavi di accesso separate per la lettura e la scrittura.

Per questo non è necessaria la crittografia a chiave pubblica. L'AES standard dovrebbe andare bene.

Ottieni un HSM (Yubico ne fa uno abbastanza ragionevole). Questo fa per te la crittografia e la decrittografia. La chiave non lascia mai il dispositivo.

Dovresti eseguire la crittografia / decrittografia sul server delle applicazioni

Se quello che stai descrivendo è un progetto che coinvolge informazioni private di persone reali, ti consiglio di andare per soluzioni di crittografia di DB professionali / commerciali invece di tentare di implementare la crittografia per conto tuo.

Conosci il detto comune che non dovresti eseguire il rollover . Per parafrasare un commento che ho letto da qualche parte, "A meno che tu non abbia scritto un dottorato di ricerca sull'argomento, non sei qualificato per scrivere il tuo algoritmo crittografico."

Ma anche se usi un algoritmo provato come RSA, AES, ecc. ci sono molte cose che possono andare storte durante l'implementazione.

Questo è particolarmente vero quando si tratta di crittografia del database.

Si desidera assicurarsi di utilizzare l'algoritmo più sicuro ma anche di implementarlo in modo da non compromettere le prestazioni del database.

Devi sapere che sei utilizzando la corretta modalità di cifratura a blocchi o applicando correttamente il vettore iniziale. È necessario sapere che la crittografia non sabota i modelli di dati, le relazioni o i formati esistenti. Scegli le soluzioni con la tecnologia Format Preserving Encryption.

È necessario assicurarsi che l'implementazione si prenda cura del ciclo di vita della chiave di crittografia e applichi audit appropriati su ciascuna colonna codificata.

Ti sto dicendo come qualcuno che è stato lì. A meno che non sia solo un progetto per animali domestici, vai su soluzioni comprovate e testate su quel mercato che si adattano alle tue particolari esigenze. Non ci dite molto su quale DBMS state usando (potrebbe importare molto), ma quello che immagino è che si tratta di un DB relazionale. Dal momento che non è necessario crittografare tutto nel DB, raccomanderei di utilizzare la crittografia basata su colonne. In questo modo sarai in grado di impostare criteri di crittografia e controllo di accesso / chiavi specifici per ciascuna colonna. Può anche aumentare le prestazioni complessive post-crittografia.

Se utilizzi il RDBMS Open Source questo potrebbe essere una buona soluzione per il tuo caso. Per gli RDBMS commerciali, i fornitori di solito hanno una crittografia basata su colonne corrispondente o si consiglia di controllare questo o questo o questo .

Spero che la risposta aiuti.