Architettura di archiviazione BLOB conforme a HIPAA

Esiste un compito di progettare un sistema per archiviare i dati sensibili in modo sicuro (dovrebbe essere compatibile con HIPAA in futuro). È solo una bozza - questo non sarà usato in produzione in un futuro prevedibile. Ho un prototipo ispirato da TrueVault e voglio sapere se c'è qualche mancanza di sicurezza semantica o violazioni di concetti di sicurezza in esso.

Quindi il sistema è composto da 4 sottosistemi:

Encryptor / Decryptor (Cryptor) è responsabile della generazione casuale di chiavi / iv, crittografia e decrittografia dei dati binari con algoritmo AES-256-GCM (implementazione OpenSSL). Questo server esegue solo le operazioni in memoria e memorizza il risultato in altri 3 sottosistemi ed è connesso con loro tramite IPSEC o SSL VPN. Altri tre sottosistemi non hanno collegamenti diretti tra loro. Il client esterno utilizza solo l'interfaccia pubblica di crittografia / decrittografia e non è direttamente connesso ad altri sottosistemi.

Interfaccia pubblica:

• dump (client_binary_data) - > external_uuid
• carica (external_uuid) - > client_binary_data

Il deposito dati memorizza la tripletta [data_store_uuid, encrypted_data, auth_tag].

• dump (encrypted_data, auth_tag) - > data_store_uuid
• carica (data_store_uuid) - > [encrypted_data, auth_tag]

Il keyStore memorizza [key_store_uuid, key, iv] triplet.

• dump (chiave, iv) - > key_store_uuid
• carica (key_store_uuid) - > [chiave, iv]

MapsStore memorizza la mappa tra terzina DataStore, terzina KeyStore e external_uuid: [external_uuid, data_store_uuid, key_store_uuid].

• dump (external_uuid, data_store_uuid, key_store_uuid)
• carica (external_uuid) - > [data_store_uuid, key_store_uuid]

Flusso di lavoro:

• Cryptor.dump (binario)
  
  1. genera external_uuid
  2. genera una chiave casuale
  3. genera un iv casuale
  4. usa external_uuid come AAD per AES-256-GCM
  5. crittografare client_binary_data - > encrypted_data
  6. deriva auth_tag
  7. KeyStore.dump (chiave, iv) - > key_store_uuid
  8. DataStore.dump (encrypted_data, auth_tag) - > data_store_uuid
  9. MapStore.dump (external_uuid, data_store_uuid, key_store_uuid)
  10. Restituisce external_uuid al client
• Cryptor.load (external_uuid)
  1. MapStore.load (external_uuid) - > [data_store_uuid, key_store_uuid]
  2. KeyStore.load (key_store_uuid) - > [chiave, iv]
  3. DataStore.load (data_store_uuid) - > [encrypted_data, auth_tag]
  4. Decrittografare i dati e restituirli al client

Domande principali Sono già in dubbio con:

1. c'è un modo migliore / più comune / affidabile per crittografare e archiviare i dati. Dovrebbe essere il più veloce possibile. Ci si aspetta che il massimo di 50 MB di blob funzionino con.
2. deve essere memorizzato nel sottosistema KeyStore o nel sottosistema DataStore. C'è qualche differenza tra questi due approcci? Il NIST dice qui (pagina 16) che iv è parte del messaggio. Penso che il termine "messaggio" sia più vicino alle informazioni memorizzate all'interno del DataStore anziché al KeyStore.
3. è sicuro usare external_uuid come AAD in questo schema? O dovrei aggiungere un altro uuid casuale a tale scopo a MapVault
4. dovrei cifrare le chiavi in KeyStore con la chiave pubblica del cliente o con qualche chiave principale? Sembra questo approccio utilizzato nello schema TDE di Oracle. Penso che la crittografia con la chiave pubblica del client renderà impossibile ripristinare i dati anche se tutti e tre i sottosistemi sono stati rubati.