Crittografia - AWS Guida prescrittiva

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Crittografia

Quando si tratta di crittografia, ci sono due aree di interesse:

  • Crittografia in transito

  • Crittografia a riposo

La crittografia nativa Db2 è integrata in Db2 per proteggere i dati inattivi crittografando i dati quando vengono scritti su disco. La crittografia nativa Db2 utilizza un modello standard a due livelli. I dati effettivi vengono crittografati con una chiave di crittografia dei dati Db2 (DEK) e il DEK viene crittografato con una chiave master Db2 (MK). Il DEK è gestito all'interno del database mentre il MK è archiviato esternamente in un archivio di chiavi.

Per ottenere la crittografia a riposo, la crittografia del volume Amazon Elastic Block Store (Amazon EBS) è preferita rispetto alla crittografia nativa Db2, perché è possibile utilizzare soluzioni native del cloud per la configurazione e la scalabilità. AWS La crittografia dei volumi EBS aiuta anche a eliminare i costi operativi non necessari e il tempo impiegato per configurare la crittografia nativa durante la migrazione di più server di database. Per ulteriori informazioni, consulta il post sul blog Architecting for database encryption on. AWS

La crittografia in transito è importante per le seguenti comunicazioni di dati:

  • Tra il client e il server

  • Tra server primari e server HADR (High Availability Disaster Recovery) in standby

  • Tra il server di database e i servizi esterni

I dati trasmessi vengono crittografati utilizzando TLS. Inoltre, Db2 supporta la crittografia interna dell'ID utente e della password utilizzando il parametro lato server. AUTHENTICATION

TLS utilizza le librerie dell'IBM Global Security Kit (GSKit), che fornisce un tunnel sicuro per i dati inviati e archivia i certificati in modo sicuro all'interno dell'archivio delle chiavi.

Il diagramma seguente mostra l'handshake TLS tra il client e il server.

""
  1. Il client richiede una connessione TLS ed elenca le suite di crittografia supportate.

  2. Il server risponde con una suite di crittografia selezionata e una copia del relativo certificato digitale, che include una chiave pubblica.

  3. Il client verifica la validità del certificato. Se il certificato è valido, una chiave di sessione e un codice di autenticazione dei messaggi (MAC) vengono crittografati con la chiave pubblica e rispediti al server.

  4. Il server decripta la chiave di sessione e il MAC. Quindi il server invia una conferma per avviare una sessione crittografata con il client.

  5. Il server e il client si scambiano dati in modo sicuro utilizzando la chiave di sessione e il MAC.

Quando i certificati scadono, è necessario rinnovarli e aggiornarli nell'archivio delle chiavi.

A partire dalla versione 11.5.6 di Db2, è possibile includere la convalida del nome host durante la configurazione di TLS. La convalida del nome host aiuta la connessione del client a verificare che il nome host nel certificato del server corrisponda al nome host nel client. Questa convalida può aiutare a prevenire gli attacchi. person-in-the-middle Inoltre, è possibile configurare il TLSVersion parametro sul client. A partire dalla versione 11.5.8 di Db2, è supportato TLS 1.3.