Architetture di riferimento per Cloud External Key Manager

Quando abiliti 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 proteggere i dati in Google Cloud. Questo documento descrive le architetture per i Google Cloud clienti che vogliono eseguire il deployment di un servizio di gestione delle chiavi esterno (EKM) a disponibilità elevata con Cloud KMS e Cloud EKM.

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

Panoramica

Cloud EKM ti consente di utilizzare materiale delle chiavi che rimane al di fuori di Google Cloud per controllare l'accesso ai tuoi dati archiviati nei servizi supportati Google Cloud. Le chiavi Cloud EKM sono chiavi di crittografia gestite dal cliente (CMEK). Cloud EKM consente di creare e gestire risorse chiave Cloud KMS utilizzando i livelli di protezione EXTERNAL e EXTERNAL_VPC. Quando abiliti Cloud EKM, ogni richiesta di operazione crittografica comporta un'operazione crittografica sulla chiave esterna. L'esito dell'operazione di richiesta iniziale dipende in modo critico dal risultato dell'operazione crittografica 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 si riferisce a un servizio che fornisce questa API come servizio EKM.

Se un servizio EKM non è più disponibile, le letture e le scritture dai data plane per i servizi Google Cloud integrati potrebbero non riuscire. Questi errori vengono visualizzati in modo simile a quando la chiave Cloud KMS dipendente si trova in uno stato inutilizzabile, ad esempio quando è disabilitata. Il messaggio di errore descrive l'origine dell'errore e un corso di azione. Inoltre, gli audit log di accesso ai dati di Cloud KMS includono un record di questi messaggi di errore insieme a tipi di errore descrittivi. Per saperne di più, consulta il riferimento agli errori di Cloud EKM.

Best practice per le architetture Cloud EKM

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

  • Configurare una connettività di rete affidabile a bassa latenza
  • Abilita alta affidabilità
  • Rilevare e mitigare rapidamente gli errori

Configurare una connettività di rete affidabile a bassa latenza

Cloud KMS si connette ai servizi EKM utilizzando una rete Virtual Private Cloud (VPC) o internet. Le soluzioni VPC spesso utilizzano 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 ininterrotta e di una risoluzione DNS rapida e affidabile. Dal punto di vista di Google Cloud, qualsiasi interruzione può comportare l'indisponibilità del servizio EKM e la potenziale impossibilità di accedere ai dati protetti da EKM.

Quando il data plane 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 Google Cloud della chiave Cloud KMS. Se la posizioneGoogle Cloud è una multiregione, il timeout inizia nella regione in cui Cloud KMS riceve la richiesta, ovvero in genere dove si è verificata l'operazione sulla risorsa di dati protetta da CMEK. Questo timeout è adeguato per consentire a un servizio EKM di gestire le richieste in una regioneGoogle Cloud vicina da cui provengono le richieste.

Il timeout aiuta a prevenire errori a cascata nei servizi downstream che dipendono dalla chiave esterna. I problemi di latenza finale che normalmente causano un'esperienza utente scadente nelle applicazioni di livello superiore possono manifestarsi come accessi non riusciti alla chiave esterna, con conseguente errore dell'operazione logica di livello superiore.

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

  • Ridurre al minimo la latenza della comunicazione round trip con Cloud KMS: configura il servizio EKM in modo che gestisca le richieste il più vicino possibile alle Google Cloud posizioni che corrispondono alle chiavi Cloud KMS configurate per utilizzare il servizio EKM. Per saperne di più, consulta Best practice per la scelta delle regioni di Compute Engine e Regioni e zone.
  • Utilizza Cloud Interconnect quando 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 contribuisce a eliminare le dipendenze da internet.
  • Se necessario, implementa Google Cloud soluzioni di rete nella regione più vicina al servizio EKM: idealmente, le chiavi Cloud KMS vengono archiviate 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 soluzioni di Google Cloud networking, come Cloud VPN, nella regione più vicina al servizio EKM. Questa opzione contribuisce a garantire che il traffico di rete utilizzi l'infrastruttura di Google quando possibile, riducendo la dipendenza da internet.
  • Utilizza le reti di livello Premium quando il traffico EKM transita su internet: Il livello Premium instrada il traffico su internet utilizzando l'infrastruttura di Google, ove possibile, per migliorare l'affidabilità e ridurre la latenza.
  • Utilizza una scadenza client appropriata:se chiami direttamente l'API Cloud KMS per le chiavi Cloud EKM, configura una scadenza client di almeno 10 secondi per consentire il completamento delle operazioni con chiavi esterne.

Abilita alta affidabilità

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

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

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

  • Limita l'area interessata dai problemi del control plane: configura il control plane (ad esempio, la creazione o l'eliminazione delle chiavi) del servizio EKM in modo da 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 influire sull'intero sistema. Alcune strategie per ridurre l'impatto dei problemi includono quanto segue:

    • Controlla la velocità di propagazione:per impostazione predefinita, assicurati che le modifiche si propaghino lentamente quanto è accettabile per usabilità e sicurezza. Configura le eccezioni se necessario, ad esempio quando consenti l'accesso a una chiave per propagarla rapidamente per consentire a un utente di annullare un errore.
    • Partiziona il sistema in shard:se molti utenti condividono EKM, partizionali in shard logici completamente indipendenti, in modo che i problemi attivati da un utente in uno shard non possano influire sugli utenti di 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 una policy di accesso alle chiavi, l'EKM potrebbe confermare il numero di richieste recenti che sarebbero state rifiutate in base alla nuova policy.
    • Implementa il canarying dei dati:invia i dati solo a un piccolo sottoinsieme del sistema. Se il sottoinsieme rimane integro, trasferisci i dati al resto del sistema.
  • Implementa controlli di integrità olistici:crea controlli di integrità che misurino se l'intero sistema funziona. Ad esempio, i controlli di integrità che convalidano solo la connettività di rete non sono utili per rispondere a molti problemi a livello di applicazione. Idealmente, il controllo di integrità rispecchia da vicino 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 scarichi attivamente il traffico dalle repliche non integre ed esegua il failover in modo sicuro alle repliche integre.

  • Includi meccanismi di sicurezza per gestire il sovraccarico ed evitare errori a cascata: I sistemi potrebbero sovraccaricarsi per diversi motivi. Ad esempio, quando alcune repliche diventano non integre, il traffico reindirizzato alle repliche integre potrebbe sovraccaricarle. Quando riceve più richieste di quelle che può gestire, il sistema deve tentare di gestire quelle che può in modo sicuro e rapido, rifiutando il traffico in eccesso.

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

Rilevare e mitigare rapidamente gli errori

Per ogni minuto di interruzione del servizio EKM, le risorse dipendenti Google Cloud potrebbero essere inaccessibili, 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 minacciano l'affidabilità: configura metriche come i tassi di errore di risposta e le latenze di risposta per rilevare rapidamente i problemi.
  • Configura pratiche operative per la notifica e la mitigazione tempestive degli incidenti: quantifica l'efficacia delle pratiche operative monitorando il tempo medio di rilevamento (MTTD) e il tempo medio di ripristino (MTTR) e definisci gli obiettivi misurati da queste metriche. Utilizzando queste metriche, puoi trovare modelli e carenze nei processi e nei sistemi 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 rete e bilanciamento del caricoGoogle 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 alto throughput su Google Cloud e il servizio EKM viene eseguito in un unico 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 che si trova in un data center on-premise tramite la 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 a singola regione. La configurazione con disponibilità del 99,99% richiede l'utilizzo di Cloud Interconnect in più Google Cloudregioni, 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 affidabilità anziché Cloud Interconnect.

Il vantaggio principale di questa architettura è che non ci sono hop intermedi in Google Cloud, il che riduce la latenza e i potenziali colli di bottiglia. Se vuoi configurare una connessione diretta quando il tuo servizio EKM è ospitato in 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 alla sola disponibilità delle route.

Se configuri una rete VPC, le chiavi esterne a cui si accede tramite la rete VPC devono utilizzare una località regionale in Cloud KMS. Le chiavi non possono utilizzare una posizione multiregionale. Per saperne di più, consulta Gestori di chiavi esterni e regioni.

Bilanciamento del carico da internet in Google Cloud

L'utilizzo di un bilanciatore del carico in Google Cloud con una connessione a internet è consigliato quando sono necessarie chiavi Cloud KMS multiregionali. Il seguente diagramma mostra questa architettura.

Architettura per una connessione con bilanciamento del carico da internet.

In questa architettura, EKM ha repliche in due siti on-premise. Ogni backend è rappresentato in Google Cloud utilizzando un gruppo di endpoint di rete con 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 sul networking 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 alle 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 integra più vicina, il che lo rende adatto alle chiavi Cloud KMS multiregionali. Tuttavia, il bilanciatore del carico non consente la configurazione dei backend principali e di failover. Il traffico viene distribuito in modo uniforme in più backend di 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 viene eseguito il deployment di EKM. Il seguente diagramma mostra questa architettura.

Architettura per una connessione con bilanciamento del carico da una rete VPC.

In questa architettura, Cloud EKM accede al servizio EKM replicato tra due data center on-premise tramite la 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 VPN ad alta affidabilità anziché Cloud Interconnect.

Il bilanciatore del carico di rete passthrough interno fornisce un singolo indirizzo IP che le risorse possono utilizzare per inviare traffico utilizzando il networking virtuale. Il bilanciatore del carico esegue il failover al data center di backup in base all'integrità dei backend.

Il gruppo di istanze VM è necessario per il proxy del traffico, perché il bilanciatore del carico interno non può instradare il traffico direttamente ai backend on-premise. Puoi eseguire il deployment dei proxy del bilanciatore del carico per eseguire le immagini Docker Nginx da Cloud Marketplace nei 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 Google Cloud bilanciatori del carico possono connettersi direttamente alle istanze del servizio EKM e bilanciare il carico tra queste. L'eliminazione del bilanciatore del carico on-premise comporta una configurazione più semplice, 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 si accede tramite la rete VPC devono utilizzare una località regionale in Cloud KMS. Le chiavi non possono utilizzare una posizione multiregionale. Per saperne di più, consulta Gestori di chiavi esterni e regioni.

Confronto tra architetture di riferimento

La tabella seguente confronta 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 dell'implementazione e della gestione di EKM e fornisce EKM come servizio ai clienti.

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

Internet o rete VPC

VPC

Internet

VPC

Internet

Bilanciatore del carico in Google Cloud

No

Sì

Sì

No

Bilanciatore del carico on-premise obbligatorio

Sì

No

No

Sì (gestite dal partner)

Supporta le località Cloud KMS multiregionali

No

Sì

No

Sì

Consigliato per

Applicazioni con throughput elevato 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