Architetture di riferimento per Cloud External Key Manager

Quando attivi Cloud Key Management Service (Cloud KMS) con Cloud External Key Manager (Cloud EKM), puoi utilizzare le chiavi che gestisci con un partner di gestione delle chiavi esterne per contribuire a proteggere i dati in Google Cloud. Questo documento descrive le architetture per i clienti di Google Cloud che vogliono eseguire il deployment di un servizio di gestione delle chiavi esterne (EKM) altamente disponibile con Cloud KMS e Cloud EKM.

L'utilizzo di Cloud EKM con il tuo servizio EKM comporta un compromesso esplicito tra il rischio e l'affidabilità del carico di lavoro cloud e i controlli per la protezione dei dati. La crittografia dei dati at-rest nel cloud con chiavi di crittografia off-cloud aggiunge nuovi rischi di errore che potrebbero comportare l'impossibilità di accedere ai dati dei servizi Google Cloud . Per affrontare questi rischi, devi incorporare l'alta disponibilità e la tolleranza ai guasti nell'architettura EKM di Cloud.

Panoramica

Cloud EKM ti consente di utilizzare materiale per le chiavi che rimane al di fuori di Google Cloud per controllare l'accesso ai tuoi dati memorizzati in servizi Google Cloudsupportati. Le chiavi EKM Cloud sono chiavi di crittografia gestite dal cliente (CMEK). Cloud EKM ti consente di creare e gestire le risorse chiave Cloud KMS utilizzando i livelli di protezione EXTERNAL e EXTERNAL_VPC. Quando attivi Cloud EKM, ogni richiesta di operazione di crittografia genera un'operazione di crittografia sulla chiave esterna. Il buon esito dell'operazione di richiesta iniziale dipende in modo critico dal risultato dell'operazione di crittografia sulla chiave esterna.

Cloud KMS richiede operazioni sulle chiavi esterne utilizzando un'API per scopi speciali che si integra con il tuo sistema di gestione delle chiavi esterno. Questo documento fa riferimento a un servizio che fornisce questa API come servizio EKM.

Se un servizio EKM non è disponibile, le letture e le scritture dai piani dati per i servizi integrati di Google Cloud potrebbero non riuscire. Questi errori si verificano in modo simile agli errori che si verificano quando la chiave Cloud KMS dipendente è in uno stato inutilizzabile, ad esempio quando è disabilitata. Il messaggio di errore descrive la fonte dell'errore e un'azione da intraprendere. Inoltre, gli audit log di accesso ai dati di Cloud KMS includono un record di questi messaggi di errore insieme a tipi di errori descrittivi. Per ulteriori informazioni, consulta il riferimento ai messaggi di errore Cloud EKM.

Best practice per le architetture Cloud EKM

Il libro di Google Site Reliability Engineering descrive le best practice per guidare lo sviluppo e la manutenzione di sistemi affidabili. Questa sezione descrive alcune di queste pratiche nel contesto dell'integrazione del servizio EKM con Google Cloud. Le seguenti best practice si applicano alle architetture di riferimento EKM di Cloud:

  • Configura una connettività di rete affidabile e a bassa latenza
  • Abilita alta disponibilità
  • Rileva e mitiga rapidamente i guasti

Configura una connettività di rete affidabile e a bassa latenza

Cloud KMS si connette ai servizi EKM utilizzando una rete VPC (Virtual Private Cloud) o internet. Le soluzioni VPC utilizzano spesso la connettività ibrida per ospitare il servizio EKM in un data center on-premise. La connessione tra Google Cloud e il data center deve essere veloce e affidabile. Quando utilizzi internet, hai bisogno di una raggiungibilità stabile e senza interruzioni e di una risoluzione DNS rapida e affidabile. Dal punto di vista di Google Cloud, qualsiasi interruzione può comportare la mancata disponibilità del servizio EKM e la potenziale impossibilità di accedere ai dati protetti da EKM.

Quando il piano dati di un servizio Google Cloud comunica con il servizio EKM, ogni chiamata associata al servizio EKM ha un periodo di timeout definito (150 millisecondi). Il timeout viene misurato dal servizio Cloud KMS nella posizione della chiave Cloud KMS in Google Cloud . Se la localitàGoogle Cloud è multiregione, il timeout inizia nella regione in cui Cloud KMS riceve la richiesta, in genere dove si è verificata l'operazione sulla risorsa di dati protetta da CMEK. Questo timeout è sufficiente per consentire a un servizio EKM di gestire le richieste in una regioneGoogle Cloud nelle vicinanze da cui provengono le richieste.

Il timeout aiuta a evitare errori a cascata nei servizi a valle che dipendono dalla chiave esterna. I problemi di latenza finale che in genere potrebbero causare un'esperienza utente scadente nelle applicazioni di livello superiore possono manifestarsi come accessi non riusciti alla chiave esterna, con conseguente fallimento dell'operazione logica di livello superiore.

Per ridurre al minimo la latenza e creare reti affidabili, tieni presente quanto segue:

  • Minimizza la latenza della comunicazione di andata e ritorno con Cloud KMS: configura il servizio EKM in modo da soddisfare le richieste il più possibile geograficamente vicine alle località Google Cloud che corrispondono alle chiavi Cloud KMS configurate per utilizzare il servizio EKM. Per maggiori informazioni, consulta Best practice per la scelta delle regioni Compute Engine e Regioni e zone.
  • Utilizza Cloud Interconnect, se possibile: Cloud Interconnect crea una connessione a bassa latenza e ad alta disponibilità tra Google Cloud e il tuo data center utilizzando una rete VPC e aiuta a rimuovere le dipendenze da internet.
  • Esegui il deployment delle soluzioni di rete Google Cloud nella regione più vicina al servizio EKM, se necessario: idealmente, le chiavi Cloud KMS vengono memorizzate nella regione più vicina al servizio EKM. Se esiste una regioneGoogle Cloud più vicina al servizio EKM rispetto alla regione che contiene le chiavi Cloud KMS, utilizza le soluzioni di networking Google Cloud , come Cloud VPN, nella regione più vicina al servizio EKM. Questa opzione contribuisce ad assicurare che il traffico di rete utilizzi l'infrastruttura di Google, se possibile, il che riduce la dipendenza da internet.
  • Utilizza le reti di livello Premium quando il traffico EKM transita attraverso internet: livello Premium instrada il traffico tramite internet utilizzando l'infrastruttura di Google, ove possibile, per migliorare l'affidabilità e ridurre la latenza.

Abilita alta disponibilità

L'esistenza di un singolo punto di défaillance nel servizio EKM riduce la disponibilità delle risorse di Google Cloud dipendenti a quella del singolo punto di défaillance. Questi punti di errore potrebbero trovarsi nelle dipendenze critiche del servizio EKM, nonché nell'infrastruttura di rete e di calcolo di base.

Per abilitare l'alta disponibilità, tieni presente quanto segue:

  • Esegui il deployment delle repliche in domini in errore indipendenti:esegui il deployment di almeno due repliche del servizio EKM. Se utilizzi località multiregionali Google Cloud, esegui il deployment di EKM in almeno due località geografiche separate con almeno due repliche ciascuna. Assicurati che ogni replica non representi solo un piano di dati replicato del servizio EKM riducendo al minimo e rafforzando i vettori di errore tra le repliche. Considera gli esempi seguenti:
    • Configura le modifiche in produzione, inclusi i push di configurazione e del codice binario del server, per modificare una sola replica alla volta. Verifica che tutte le modifiche vengano eseguite sotto supervisione, con rollback testati e immediatamente disponibili.
    • Comprendi e riduci al minimo i modi di errore delle repliche incrociate dell'infrastruttura di base. Ad esempio, assicurati che le repliche dipendano da alimentazioni indipendenti e ridondanti.
  • Rendi le repliche resilienti alle interruzioni di singole macchine:verifica che ogni replica del servizio sia composta da almeno tre appliance, macchine o host VM. Questa configurazione consente al sistema di gestire il traffico mentre una macchina è inattiva per gli aggiornamenti o durante un'interruzione imprevista (provisioning N+2).

  • Limita l'area interessata dai problemi del piano di controllo: configura il piano di controllo (ad esempio la creazione o l'eliminazione di chiavi) del servizio EKM per replicare la configurazione o i dati tra le repliche. Queste operazioni sono in genere più complesse perché richiedono la sincronizzazione e interessano tutte le repliche. I problemi possono propagarsi rapidamente e interessare l'intero sistema. Ecco alcune strategie per ridurre l'impatto dei problemi:

    • Controlla la velocità di propagazione:per impostazione predefinita, assicurati che le modifiche si propaghino con la minima lentezza accettabile per usabilità e sicurezza. Configura le eccezioni ove necessario, ad esempio quando consenti la propagazione rapida dell'accesso a una chiave per consentire a un utente di annullare un errore.
    • Suddividi il sistema in shard: se molti utenti condividono l'EKM, suddividili in shard logici completamente indipendenti, in modo che i problemi attivati da un utente in uno shard non possano interessare gli utenti in un altro.
    • Visualizza l'anteprima dell'effetto delle modifiche: se possibile, consenti agli utenti di vedere l'effetto delle modifiche prima di applicarle. Ad esempio, quando modifichi un criterio di accesso alle chiavi, l'EKM potrebbe confermare il numero di richieste recenti che sarebbero state rifiutate in base al nuovo criterio.
    • Implementa il canarying dei dati:invia prima i dati solo a un piccolo sottoinsieme del sistema. Se il sottoinsieme rimane in stato normale, invia i dati al resto del sistema.
  • Implementa controlli di integrità olistici:crea controlli di integrità che misurano se l'intero sistema funziona. Ad esempio, i controlli di integrità che solo convalidano la connettività di rete non sono utili per rispondere a molti problemi a livello di applicazione. Idealmente, il controllo di integrità rispecchia fedelmente le dipendenze per il traffico reale.

  • Configura il failover tra le repliche:configura il bilanciamento del carico nei componenti del servizio EKM in modo che utilizzi i controlli di integrità e sposti attivamente il traffico dalle repliche non integre e trasferisca in sicurezza il failover alle repliche integre.

  • Includi meccanismi di sicurezza per gestire il sovraccarico ed evitare errori a cascata: i sistemi potrebbero essere sovraccaricati per diversi motivi. Ad esempio, quando alcune repliche non sono più in stato di integrità, il traffico reindirizzato alle repliche integre potrebbe sovraccaricarle. Quando deve gestire più richieste di quante possa soddisfare, il sistema deve tentare di soddisfare quelle che può in modo sicuro e rapido, rifiutando al contempo il traffico in eccesso.

  • Garantire una solida strategia di durabilità: i dati in Google Cloud che sono criptati con una chiave esterna nel servizio EKM non sono recuperabili senza la chiave esterna. Pertanto, la durata della chiave è uno dei requisiti di progettazione centrali del servizio EKM. Configura il servizio EKM per eseguire il backup in modo sicuro di copie ridondanti del materiale delle chiavi in più sedi fisiche. Configura misure di protezione aggiuntive, come i backup offline, per le chiavi di alto valore. Assicurati che i meccanismi di eliminazione consentano il tempo necessario per il recupero in caso di incidenti e bug.

Rileva e mitiga rapidamente i guasti

Per ogni minuto di interruzione del servizio EKM, le risorse Google Cloud dipendenti potrebbero non essere accessibili, il che può aumentare ulteriormente la probabilità di un errore a cascata di altri componenti dipendenti della tua infrastruttura.

Per rilevare e mitigare rapidamente gli errori, tieni presente quanto segue:

  • Configura il servizio EKM per generare report sulle metriche che segnalano incidenti che minano l'affidabilità: imposta metriche come le percentuali di errori di risposta e le latenze di risposta per rilevare rapidamente i problemi.
  • Configura pratiche operative per la notifica e la mitigazione tempestiva degli incidenti: quantifica l'efficacia delle pratiche operative monitorando le metriche relative al tempo medio di rilevamento (MTTD) e al tempo medio di ripristino (MTTR) e definisci gli obiettivi misurati da queste metriche. Utilizzando queste metriche, puoi trovare modelli e carenze nei sistemi e nei processi attuali, in modo da poter rispondere rapidamente agli incidenti.

Architetture di riferimento per Cloud EKM

Le seguenti architetture descrivono alcuni modi per eseguire il deployment del servizio EKM utilizzando i prodotti di networking e bilanciamento del carico diGoogle Cloud .

Connessione diretta tramite Cloud VPN o Cloud Interconnect

È consigliabile una connessione diretta tra Google Cloud e il tuo data center on-premise quando esegui applicazioni ad alta produttività suGoogle Cloud e il servizio EKM viene eseguito in un singolo data center. Il seguente diagramma mostra questa architettura.

Architettura per una connessione diretta tramite Cloud VPN o Cloud Interconnect.

In questa architettura, Cloud EKM accede al servizio EKM in un data center on-premise tramite connettività ibrida nella regione senza alcun bilanciamento del carico intermedio in Google Cloud.

Se possibile, esegui il deployment della connessione del servizio Cloud EKM a EKM utilizzando la configurazione con disponibilità del 99,9% per le applicazioni di una singola regione. La configurazione con disponibilità del 99,99% richiede l'utilizzo di Cloud Interconnect in più regioni Google Cloud, il che potrebbe non soddisfare le tue esigenze se la tua attività richiede l'isolamento regionale. Se la connessione al data center on-premise utilizza internet, utilizza VPN ad alta disponibilità instead of Cloud Interconnect.

Il vantaggio principale di questa architettura è che non sono presenti hop intermedi in Google Cloud, il che riduce la latenza e i potenziali colli di bottiglia. Se vuoi configurare una connessione diretta quando il servizio EKM è ospitato su più data center, devi configurare i bilanciatori del carico in tutti i data center che utilizzano lo stesso indirizzo IP (anycast). Se utilizzi questa configurazione, il bilanciamento del carico e il failover tra i data center sono limitati solo alla disponibilità dei percorsi.

Se configuri una rete VPC, le chiavi esterne a cui accedi tramite la rete VPC devono utilizzare una località regionale in Cloud KMS. Le chiavi non possono utilizzare una località con più regioni. Per ulteriori informazioni, consulta Regioni e gestori di chiavi esterni.

Bilanciamento del carico da internet in Google Cloud

Ti consigliamo di utilizzare un bilanciatore del carico in Google Cloud con una connessione a internet se hai bisogno di chiavi Cloud KMS multiregionali. Il seguente diagramma mostra questa architettura.

Architettura per una connessione bilanciata del carico da internet.

In questa architettura, l'EKM ha repliche in due siti on-premise. Ogni backend è rappresentato in Google Cloud utilizzando un gruppo di endpoint di rete per la connettività ibrida (NEG). Il deployment utilizza un bilanciatore del carico di rete proxy esterno per inoltrare il traffico direttamente a una delle repliche. A differenza degli altri approcci, che si basano sulla rete VPC, il bilanciatore del carico di rete proxy esterno ha un indirizzo IP esterno e il traffico proviene da internet.

Ogni NEG di connettività ibrida può contenere più indirizzi IP, il che consente al bilanciatore del carico di rete proxy esterno di bilanciare il traffico direttamente verso le istanze del servizio EKM. Non è necessario un bilanciatore del carico aggiuntivo nel data center on-premise.

Il bilanciatore del carico di rete proxy esterno non è vincolato a una regione specifica. Può indirizzare il traffico in entrata alla regione funzionante più vicina, il che lo rende adatto per le chiavi Cloud KMS multiregionali. Tuttavia, il bilanciatore del carico non consente la configurazione di backend principali e di failover. Il traffico viene distribuito in modo uniforme su più backend in una regione.

Bilanciamento del carico in una rete VPC in Google Cloud

L'utilizzo di un bilanciatore del carico in Google Cloud con una rete VPC è consigliato per la maggior parte dei servizi EKM in cui esegui il deployment dell'EKM. Il seguente diagramma mostra questa architettura.

Architettura per una connessione bilanciata del carico da una rete VPC.

In questa architettura, Cloud EKM accede al servizio EKM che viene replicato tra due data center on-premise tramite connettività ibrida con livelli di bilanciamento del carico intermedio nella regione Google Cloud . Se la connessione al data center on-premise utilizza internet, puoi utilizzare la VPN ad alta disponibilità anziché Cloud Interconnect.

Il bilanciatore del carico di rete passthrough interno fornisce un unico indirizzo IP che le risorse possono utilizzare per inviare traffico utilizzando la virtualizzazione della rete. Il bilanciatore del carico esegue il trasferimento al data center di backup in base allo stato di salute dei backend.

Il gruppo di istanze VM è necessario per eseguire il proxy del traffico, perché il bilanciatore del carico interno non può instradare il traffico direttamente ai backend on-premise. Puoi eseguire il deployment di proxy di bilanciamento del carico per eseguire immagini Docker Nginx da Cloud Marketplace in gruppi di istanze. Puoi utilizzare Nginx come bilanciatore del carico TCP.

Poiché questo approccio utilizza i bilanciatori del carico in Google Cloud, non è necessario un bilanciatore del carico on-premise. I bilanciatori del carico Google Cloud possono collegarsi direttamente alle istanze del servizio EKM e bilanciare il carico tra di loro. L'eliminazione del bilanciatore del carico on-premise semplifica la configurazione, ma riduce la flessibilità disponibile nel servizio EKM. Ad esempio, un bilanciatore del carico L7 on-premise potrebbe riprovare automaticamente le richieste se un'istanza EKM restituisce un errore.

Se configuri una rete VPC, le chiavi esterne a cui accedi tramite la rete VPC devono utilizzare una località regionale in Cloud KMS. Le chiavi non possono utilizzare una località con più regioni. Per ulteriori informazioni, consulta Regioni e gestori di chiavi esterni.

Confronto delle architetture di riferimento

La tabella seguente mette a confronto le opzioni di architettura di riferimento per Cloud EKM. La tabella include anche una colonna per l'architettura EKM gestita dal partner. In questo scenario, il partner è responsabile del deployment e della gestione dell'EKM e lo fornisce come servizio ai clienti.

Opzione Connessione diretta Bilanciamento del carico da internet Bilanciamento del carico in una rete VPC EKM completamente gestito fornito dal partner

Rete internet o VPC

VPC

Internet

VPC

Internet

Load balancer in Google Cloud

No

No

È necessario un bilanciatore del carico on-premise

No

No

Sì (gestite dal partner)

Supporta località Cloud KMS multiregionali

No

No

Consigliato per

Applicazioni con elevato throughput in cui il servizio EKM viene eseguito in un singolo sito.

Quando sono necessarie chiavi Cloud KMS multiregionali.

La maggior parte dei servizi EKM in cui esegui il deployment del tuo EKM.

Puoi utilizzare l'EKM di un partner anziché implementare il tuo.

Passaggi successivi