Gestione della crittografia in Event Streams

Per impostazione predefinita, i dati del payload del messaggio in IBM® Event Streams for IBM Cloud® sono crittografati a riposo utilizzando una chiave generata in modo casuale. Anche se questo modello di crittografia predefinito fornisce la sicurezza sui dati inattivi, potresti aver bisogno di un livello di controllo superiore. Per questi casi di utilizzo, Event Streams supporta la crittografia gestita dai clienti con i seguenti servizi di gestione delle chiavi IBM Cloud®:

  • IBM® Key Protect for IBM Cloud® (Bring Your Own Key - BYOK) ti aiuta a eseguire il provisioning delle chiavi crittografate per le applicazioni nei servizi IBM Cloud. Nella gestione del ciclo di vita delle chiavi, il cliente ha il vantaggio di sapere che le chiavi sono protette da moduli di sicurezza hardware (HSM) basati su cloud e certificati FIPS 140-2 di livello tre, che proteggono dal furto di informazioni. Per ulteriori informazioni sull'utilizzo di Key Protect, consultare Esercitazione introduttiva.
  • Hyper Protect Crypto Services (Keep Your Own Key - KYOK) è un HSM dedicato, single-tenant, controllato dall'utente. Il servizio è sviluppato su hardware con certificazione FIPS 140-2 Livello 4, il più elevato offerto da qualsiasi provider cloud del settore. Si noti che Hyper Protect Crypto Services è deprecato.

IBM Cloud® sta trasferendo i servizi di gestione delle chiavi dedicate da Hyper Protect Crypto Services a IBM® Key Protect Dedicated. Migrare le chiavi root esistenti di Hyper Protect Crypto Services (HPCS) a IBM® Key Protect Dedicated (Single Tenant) prima della fine del ciclo di vita di HPCS (EOL) il 20 marzo 2027 per garantire la disponibilità del servizio. Dopo tale data, tutte le istanze rimanenti saranno chiuse. Per garantire la disponibilità e il supporto del servizio, è necessario migrare tutte le chiavi root HPCS esistenti a IBM Key Protect Dedicated (Single Tenant) prima della data di EOL. Scoprite come migrare le chiavi di root.

Questi servizi consentono l'utilizzo di una chiave fornita dal cliente per controllare la crittografia. Disabilitando o cancellando questa chiave, è possibile impedire l'accesso ai dati memorizzati dal servizio, in quanto non è più possibile decifrarli.

Considerate l'utilizzo di chiavi gestite dal cliente, se avete bisogno delle seguenti caratteristiche:

  • Crittografia dei dati a riposo controllata dalla propria chiave.
  • Controllo esplicito del ciclo di vita dei dati memorizzati a riposo.

Le chiavi gestite dal cliente sono disponibili sul piano Enterprise e solo sui cluster creati dopo ottobre 2019.

L'eliminazione della chiave gestita dal cliente non è recuperabile e comporta la perdita di tutti i dati memorizzati nell'istanza Event Streams.

Crittografia a livello di messaggio per la conformità

Alcuni standard normativi, come il PCI DSS, richiedono che i dati sensibili dei messaggi (come le informazioni dei titolari di carta) siano crittografati durante tutto il loro ciclo di vita: a riposo, in movimento e in uso.

I file system utilizzati da Event Streams per archiviare i dati dei messaggi sono crittografati, per evitare accessi non autorizzati. Tuttavia, quando i messaggi passano attraverso il livello di trasporto, Event Streams deve decifrare questi file system per elaborare i messaggi. Sebbene ciò significhi che i payload dei messaggi non sono crittografati end-to-end, la crittografia in transito e a riposo garantisce una forte protezione durante l'intero ciclo di vita dei messaggi, in linea con le best practice del settore.

Per garantire che i dati sensibili rimangano illeggibili a chiunque non sia il destinatario, i client devono crittografare il messaggio stesso a livello di applicazione prima di inviarlo a Event Streams, una pratica nota come crittografia a livello di messaggio.

Cosa non è coperto dalla crittografia gestita dal cliente

Se la funzione di crittografia gestita dal cliente è selezionata, tieni presente che solo i dati del payload del messaggio sono coperti da questa crittografia. Event Streams crittografa altri dati inattivi correlati all'utilizzo del servizio. Tuttavia, anche se crittografati, i dati di payload non di messaggi non sono crittografati con la crittografia gestita dal cliente. Esempi sono i metadati del client come i nomi argomento, i dati di configurazione argomento, gli schemi memorizzati nel registro dello schema e i metadati memorizzati in relazione alla configurazione dell'istanza Enterprise.

Pertanto, non utilizzare informazioni riservate in tali metadati del client.

Come funziona la crittografia gestita dal cliente

Event Streams utilizza un concetto chiamato crittografia a busta per implementare chiavi gestite dal cliente.

La crittografia envelope è la procedura di crittografare una chiave di crittografia con un'altra chiave di crittografia. La chiave utilizzata per crittografare i dati effettivi è nota come DEK (data encryption key). Il DEK stesso non viene mai memorizzato, ma viene avvolto da una seconda chiave, nota come chiave di crittografia (KEK), per creare un DEK avvolto.

Per decrittografare i dati, la DEK impacchettata deve prima essere spacchettata per ottenere la DEK. Questo processo è possibile solo accedendo alla KEK, che in questo caso è la tua chiave root memorizzata in Key Protect o Hyper Protect Crypto Services.

L'utente è il proprietario della KEK, che viene creata come chiave principale nel servizio Hyper Protect Crypto Services o Key Protect. Il servizio Event Streams non visualizza mai la chiave (KEK) root. L'archiviazione, la gestione e l'utilizzo per avvolgere e scartare il DEK avvengono interamente all'interno del servizio di gestione delle chiavi. Se si disabilita o si elimina la chiave, i dati non possono più essere decodificati.

Abilitazione di una chiave gestita dal cliente per Event Streams

Completate i seguenti passaggi per eseguire il provisioning dell'istanza Event Streams in modo da utilizzare una chiave gestita dal cliente:

  1. Provisioning di un'istanza di Key Protect o Hyper Protect Crypto Services.
  2. Crea una politica di autorizzazione per consentire al servizio Event Streams di accedere all'istanza del servizio di gestione delle chiavi come un lettore. Per ulteriori informazioni, vedere Uso delle autorizzazioni per garantire l'accesso tra i servizi.
  3. Crea o importa una chiave root nella tua istanza del servizio di gestione delle chiavi.
  4. Recuperare il Cloud Resource Name (CRN) della chiave utilizzando l'opzione View CRN nella GUI dell'istanza del servizio di gestione delle chiavi.
  5. Esegui il provisioning di un'istanza di Event Streams. Questa funzione è supportata solo sul piano Enterprise.

Se il provisioning avviene tramite la console IBM Cloud®, seleziona un'istanza del servizio di gestione delle chiavi e quindi seleziona una chiave root dall'istanza.

Se si esegue il provisioning tramite la CLI, utilizzare il seguente comando:

ibmcloud resource service-instance-create EVENT-STREAMS-INSTANCE-NAME messagehub ibm.message.hub.enterprise.3nodes.2tb REGION -p '{"kms_key_crn":"KMS_KEY_CRN"}'

Un cluster esistente senza una chiave gestita dal cliente non può essere aggiornato perché si tratta di un'operazione distruttiva che comporterà la perdita di tutte le definizioni di messaggi e argomenti. È necessario eliminare e ricreare l'istanza con una chiave di crittografia.

Utilizzo della chiave gestita dal cliente

Dopo aver fornito un'istanza di Event Streams con una chiave gestita dal cliente, funziona con le seguenti funzionalità aggiuntive.

Prevenzione dell'accesso ai dati

Per impedire temporaneamente l'accesso, disabilitare la chiave root. Di conseguenza, Event Streams non può più accedere ai dati perché non può più accedere alla chiave.

Per eliminare definitivamente l'accesso, cancellare la chiave. Tuttavia, devi prestare molta attenzione perché questa operazione non è ripristinabile. Perdi l'accesso a tutti i dati memorizzati nella tua istanza Event Streams. Non è possibile recuperare questi dati.

In entrambi i casi, l'istanza di Event Streams si spegne e non accetta o elabora più connessioni. Viene generato un evento Activity Tracker per segnalare l'azione. Per ulteriori informazioni, vedi Eventi di Activity Tracker.

L'autorizzazione deve essere sempre mantenuta tra Event Streams e l'istanza del servizio di gestione delle chiavi, anche dopo l'eliminazione dell'istanza del servizio. Event Streams continuerà ad avere bisogno del criterio service to service per cancellare la chiave. Per determinare quando è sicuro rimuovere la politica service - to - service, controllare le risorse associate sulla chiave root KMS. Se la chiave principale è ancora associata all'istanza Event Streams, lasciare il criterio in vigore. Mentre la rimozione di questa autorizzazione impedisce a Event Streams di accedere in futuro ai vostri dati, i dati già in uso continuano a essere disponibili per un certo periodo di tempo.

L'istanza di Event Streams viene addebitata fino a quando non viene disattivata tramite la console IBM Cloud o la CLI. Questi addebiti sono ancora applicati anche se hai scelto di impedire l'accesso ai tuoi dati.

Ripristino dell'accesso ai dati

L'accesso può essere ripristinato solo se la chiave non è stata eliminata. Per ripristinare l'accesso, riabilita la tua chiave root. Dopo un breve periodo di inizializzazione, l'istanza di Event Streams viene riavviata e ricomincia ad accettare le connessioni. Tutti i dati vengono conservati, in base ai limiti di conservazione normali configurati nella tua istanza.

Un evento del programma di traccia dell'attività viene generato per segnalare l'azione. Per ulteriori informazioni, vedi Eventi di Activity Tracker.

Rotazione della chiave

Key Protect e Hyper Protect Crypto Services supportano la rotazione delle chiavi di root, sia su richiesta che in base a una pianificazione. Durante la rotazione della chiave, Event Streams adotta la nuova chiave riavvolgendo la DEK come descritto in precedenza in come funziona la crittografia gestita dal cliente.

Un evento del programma di traccia dell'attività viene generato per segnalare l'azione. Per ulteriori informazioni, vedi Eventi di Activity Tracker.

Disabilitazione della crittografia gestita dal cliente

Dopo aver attivato la crittografia gestita dal cliente, non è possibile disattivarla. Devi invece eliminare l'istanza del servizio e crearne una nuova.

Migrazione da Hyper Protect Crypto Services (HPCS) a Key Protect Dedicato (KP-ST)

Durante la migrazione da Hyper Protect Crypto Services (HPCS) a Key Protect Dedicated (KP-ST), si verifica quanto segue:

  • Ogni istanza KMS mantiene le proprie chiavi radice uniche. La migrazione comporta la riassociazione del servizio con una nuova chiave root IBM® Key Protect Dedicated.
  • Le chiavi di crittografia dei dati (DEK) esistenti vengono reimpacchettate in modo sicuro.
  • Durante la transizione, le politiche di accesso Hyper Protect Crypto Services to Service e Key Protect to Service devono rimanere in vigore.
  • I dati crittografati non vengono nuovamente crittografati o spostati.
  • La disponibilità del servizio viene mantenuta.

Prerequisiti

Prima di avviare la migrazione, assicurarsi di disporre di:

  • Un'istanza Key Protect Dedicated (Single Tenant).
  • Una chiave principale creata nell'istanza Key Protect Dedicated (KP-ST).
  • Autorizzazioni per la gestione delle chiavi e dei criteri di accesso ai servizi.

Passi di migrazione

  1. Identificare la chiave principale Hyper Protect Crypto Services in uso. La chiave deve esistere in un'istanza di Hyper Protect Crypto Services e il servizio deve già avervi accesso.
  2. Creare o selezionare una chiave root dedicata a Key Protect. La chiave deve trovarsi nell'istanza Key Protect Dedicated (Single Tenant) appropriata e accessibile al servizio.
  3. Creare un intento di migrazione che colleghi le due chiavi. L'intento di migrazione mappa la chiave Hyper Protect Crypto Services corrente (sorgente) nella nuova chiave Key Protect dedicata (destinazione). Per ulteriori informazioni sulla migrazione di Key Protect, vedere Migrazione da Hyper Protect Crypto Services(HPCS)a Key Protect Dedicated.
  4. L'esecuzione della migrazione richiede 1-2 giorni lavorativi. Event Streams riassocia e avvolge nuovamente i DEK in modo sicuro, ove applicabile, senza crittografare nuovamente o spostare i dati.
  5. Verificare il completamento della migrazione. Il servizio deve ora fare riferimento alla chiave radice Key Protect ST. Key Protect La chiave radice ST deve essere visibile e attiva e l'associazione Hyper Protect Crypto Services deve essere rimossa.