Approfondimenti su Cloud Key Management Service

Questi contenuti sono stati aggiornati l'ultima volta a luglio 2023 e rappresentano lo status quo al momento in cui sono stati redatti. Criteri e sistemi di sicurezza di Google possono variare in futuro, grazie al costante miglioramento della protezione per i nostri clienti.

Google Cloud si basa sul presupposto che i clienti di Google Cloud possiedono i propri dati e ne devono controllare l'utilizzo.

Una volta archiviati con Google Cloud, i dati vengono criptati quando sono inattivi per impostazione predefinita. Quando utilizzi la piattaforma Cloud Key Management Service (Cloud KMS), puoi ottenere un maggiore controllo sul modo in cui i dati at-rest sono criptati e su come vengono gestite le chiavi di crittografia.

La tabella seguente descrive i diversi tipi di chiavi Google Cloud.

Tipo di token Gestione delle chiavi Condivisione della chiave Rotazione automatica Prezzi
Chiave di crittografia predefinita Queste chiavi vengono gestite esclusivamente da Google. I dati di più clienti potrebbero utilizzare la stessa chiave di crittografia della chiave (KEK). Sì, vedi Crittografia at-rest predefinita. Gratuito.
Chiavi Cloud KMS Queste chiavi sono controllate dal cliente. Essere univoca per cliente. Sì per la crittografia simmetrica, no per le chiavi asimmetriche. Consulta Rotazione della chiave. Vedi i prezzi di Cloud Key Management Service.

Questo documento si concentra sui meccanismi interni della piattaforma Cloud KMS. Queste opzioni ti aiutano a proteggere le chiavi e altri dati riservati archiviati in Google Cloud. Questo documento è destinato ai responsabili delle decisioni tecniche che hanno bisogno di dettagli sull'architettura, sull'infrastruttura e sulle funzionalità di Cloud KMS. Questo documento presuppone che tu abbia una conoscenza di base dei concetti di crittografia e delle architetture cloud.

Punti chiave di progettazione di Cloud KMS

L'obiettivo di Google è fornire una soluzione scalabile, affidabile e dalle prestazioni elevate, con la più ampia gamma di opzioni che puoi controllare, con Cloud KMS. Cloud KMS si basa sui seguenti cinque pilastri di progettazione:

  • Controllo da parte dei clienti: Cloud KMS ti consente di controllare le tue chiavi software e hardware per la crittografia e la firma. Questo pilastro include il supporto per i dispositivi BYOK (Bring Your Own Key) e HYOK (HYOK).
  • Controllo e monitoraggio dell'accesso: con Cloud KMS, puoi gestire le autorizzazioni per le singole chiavi e monitorarne l'utilizzo.
  • Regioni: Cloud KMS offre subito la regionalizzazione. Il servizio è configurato per creare, archiviare ed elaborare le chiavi solo nella località Google Cloud selezionata.
  • Backup: per proteggerti dal danneggiamento dei dati e per verificare che i dati possano essere decriptati correttamente, Cloud KMS analizza periodicamente ed esegue il backup di tutti i materiali e i metadati delle chiavi.
  • Sicurezza: Cloud KMS offre una solida protezione contro gli accessi non autorizzati alle chiavi ed è completamente integrato con i controlli di Identity and Access Management (IAM) e Cloud Audit Logs.

Fonti e opzioni di gestione per i materiali chiave

La piattaforma Cloud KMS consente di gestire le chiavi di crittografia in un servizio cloud centrale per l'utilizzo diretto o da parte di altre risorse e applicazioni cloud.

Il seguente diagramma mostra il portafoglio di chiavi Google Cloud, organizzato dal materiale delle chiavi controllato da Google a quello delle chiavi controllate dal cliente.

Portafoglio di Google Cloud per le chiavi.

Le opzioni mostrate nel diagramma precedente sono le seguenti:

  • Crittografia predefinita: tutti i dati archiviati da Google vengono criptati a livello di archiviazione utilizzando l'algoritmo Advanced Encryption Standard (AES), AES-256. Generiamo e gestiamo le chiavi per la crittografia predefinita e i clienti non hanno accesso alle chiavi o al controllo della rotazione e della gestione delle chiavi. Le chiavi di crittografia predefinite potrebbero essere condivise tra i clienti. Per saperne di più, consulta Crittografia predefinita dei dati inattivi.

  • Cloud KMS con chiavi generate dal software: utilizzando Cloud KMS, puoi controllare le chiavi generate da Google. Il backend software di Cloud KMS ti offre la flessibilità di criptare o firmare i tuoi dati con una chiave simmetrica o asimmetrica che puoi controllare.

  • Cloud KMS con chiavi generate dall'hardware (Cloud HSM): utilizzando Cloud KMS con il backend Cloud HSM, puoi possedere le chiavi generate e archiviate in moduli di sicurezza hardware (HSM) di proprietà e gestiti da Google. Se hai bisogno di una chiave protetta da hardware, puoi utilizzare il backend Cloud HSM per garantire che le tue chiavi simmetriche e asimmetriche vengano utilizzate solo in HSM convalidati FIPS 140-2 livello 3.

  • Cloud KMS con importazione delle chiavi: per soddisfare i requisiti BYOK, puoi importare le tue chiavi di crittografia che hai generato autonomamente. Puoi utilizzare e gestire queste chiavi al di fuori di Google Cloud e utilizzare il materiale della chiave in Cloud KMS per criptare o firmare i dati archiviati in Google Cloud.

  • Cloud KMS con un gestore di chiavi esterno (Cloud EKM): per soddisfare i requisiti HYOK, puoi creare e controllare le chiavi archiviate in un gestore di chiavi esterno a Google Cloud. Successivamente, configurerai la piattaforma Cloud KMS per utilizzare le chiavi esterne al fine di proteggere i dati at-rest. Puoi utilizzare queste chiavi di crittografia con una chiave Cloud EKM. Per maggiori informazioni sulla gestione delle chiavi esterne e su Cloud EKM, consulta Architetture di riferimento per un deployment affidabile dei servizi Cloud EKM.

Puoi scegliere di utilizzare le chiavi generate da Cloud KMS con altri servizi Google Cloud. Queste chiavi sono note come chiavi di crittografia gestite dal cliente (CMEK). La funzionalità CMEK consente di generare, utilizzare, ruotare ed eliminare le chiavi di crittografia che aiutano a proteggere i dati in altri servizi Google Cloud.

Concetti di crittografia e gestione delle chiavi in Google

Questa sezione definisce alcuni termini per la gestione delle chiavi nel contesto dell'infrastruttura di gestione delle chiavi a più livelli di Google.

Keyring, chiavi e versioni delle chiavi

Il seguente diagramma illustra i raggruppamenti delle chiavi e mostra keyring e chiavi con una singola versione primaria e più versioni precedenti.

Diagramma dei raggruppamenti di chiavi.

I concetti chiave mostrati nel diagramma precedente sono i seguenti:

  • Chiave: un oggetto denominato che rappresenta una chiave crittografica utilizzata per uno scopo specifico. Il materiale della chiave (i bit effettivi utilizzati per le operazioni crittografiche) può cambiare nel tempo man mano che crei nuove versioni della chiave. Puoi assegnare criteri di autorizzazione IAM a livello di chiave nella gerarchia delle risorse.

    Lo scopo della chiave e altri attributi della chiave vengono connessi e gestiti tramite la chiave. Pertanto, la chiave è l'oggetto più importante per comprendere l'utilizzo di KMS.

    Cloud KMS supporta le chiavi sia simmetriche che asimmetriche. Una chiave simmetrica viene utilizzata per creare o convalidare le firme MAC o per la crittografia simmetrica al fine di proteggere un corpus di dati. Ad esempio, puoi utilizzare AES-256 in modalità GCM per criptare un blocco di testo non crittografato. Una chiave asimmetrica può essere utilizzata per la crittografia asimmetrica o la firma asimmetrica. Per scoprire di più, consulta la sezione Scopi e algoritmi supportati.

  • Keyring: si tratta di un raggruppamento di chiavi a fini organizzativi. Un keyring appartiene a un progetto Google Cloud e si trova in una località specifica. Le chiavi ereditano i criteri di autorizzazione dal loro keyring. Il raggruppamento di chiavi con autorizzazioni correlate in un keyring consente di concedere, revocare o modificare le autorizzazioni per tali chiavi a livello di keyring senza che tu debba intervenire su ogni chiave singolarmente. I keyring offrono praticità e categorizzazione, ma se il raggruppamento dei keyring non è utile per te, puoi gestire le autorizzazioni direttamente sulle chiavi. I tag ti consentono o negano in modo condizionale i criteri a seconda che una risorsa abbia un tag specifico. Puoi applicare tag a livello di keyring nella gerarchia delle risorse.

    Per evitare conflitti tra i nomi delle risorse, non puoi eliminare un keyring o una chiave. I keyring e le chiavi non hanno costi fatturabili o limitazioni di quota, quindi la loro esistenza non influisce sui costi o sui limiti di produzione.

  • Metadati delle chiavi: nomi delle risorse, proprietà delle risorse KMS (ad esempio criteri di autorizzazione, tipo di chiave, dimensione della chiave, stato della chiave) e qualsiasi dato derivato da chiavi e keyring.

  • Versione della chiave: il materiale della chiave associato a una chiave in un determinato momento. La versione della chiave è la risorsa che contiene il materiale effettivo della chiave. Le versioni sono numerate in sequenza, a partire dalla versione 1. Quando una chiave viene ruotata, viene creata una nuova versione con nuovo materiale. La stessa chiave logica può avere più versioni nel tempo, il che significa che i tuoi dati sono criptati utilizzando versioni della chiave diverse. Le chiavi simmetriche hanno una versione principale. Per impostazione predefinita, viene utilizzata la versione principale per la crittografia. Quando Cloud KMS esegue la decrittografia utilizzando chiavi simmetriche, identifica automaticamente la versione della chiave necessaria per eseguire la decrittografia.

Gerarchia delle chiavi software

Il seguente diagramma illustra la gerarchia delle chiavi per Cloud KMS e per l'archivio chiavi interno di Google. Cloud KMS utilizza l'archivio chiavi, il Key Management Service interno di Google, per eseguire il wrapping delle chiavi criptate di Cloud KMS. Il wrapping di chiavi è il processo di crittografia di una chiave utilizzando un'altra chiave, per archiviarla in modo sicuro o trasmetterla su un canale non attendibile. Cloud KMS utilizza la stessa radice di attendibilità dell'archivio chiavi.

Diagramma della gerarchia delle chiavi interne.

La gerarchia delle chiavi mostrata nel diagramma precedente è la seguente:

  1. Una chiave di crittografia dei dati (DEK) cripta i blocchi di dati.
  2. Per criptare o sottoporre a wrapping la DEK, viene utilizzata una chiave di crittografia della chiave (KEK). Tutte le opzioni della piattaforma Cloud KMS (software, hardware e backend esterni) consentono di controllare la KEK. Le KEK sono archiviate in Cloud KMS.
  3. Una chiave master KMS cripta la KEK. La chiave master KMS è archiviata nell'archivio chiavi. Nell'archivio chiavi esiste una chiave master KMS separata per ogni località Cloud KMS. Le KEK in Cloud KMS sono protette dalla chiave master KMS della località. Ogni server Cloud KMS recupera una copia della chiave master KMS durante l'avvio come dipendenza rigida e una nuova copia della chiave master KMS viene recuperata ogni giorno. La chiave master KMS viene ricriptata periodicamente.
  4. La chiave master KMS è protetta dalla chiave master dell'archivio chiavi nell'archivio chiavi.
  5. La chiave master dell'archivio chiavi è protetta dalla chiave principale dell'archivio chiavi principale.

Per ulteriori informazioni sull'archivio chiavi, consulta Gestione delle chiavi nell'articolo Crittografia at-rest.

Vincoli operativi principali

Cloud KMS opera rispettando i seguenti vincoli:

  • Progetto: le risorse Cloud KMS appartengono a un progetto Google Cloud, proprio come tutte le altre risorse Google Cloud. Puoi ospitare dati in un progetto diverso da quello in cui risiedono le chiavi Cloud KMS. Per supportare la best practice di separazione dei doveri tra gli amministratori delle chiavi e quelli dei dati, puoi rimuovere il ruolo di proprietario dal progetto chiave.
  • Località: all'interno di un progetto, le risorse Cloud KMS vengono create in una località. Per ulteriori informazioni sulle posizioni, consulta Area geografica e regioni.
  • Coerenza: Cloud KMS propaga le operazioni su chiavi, keyring e versioni delle chiavi utilizzando un'elevata coerenza o coerenza finale. Per ulteriori informazioni, consulta Coerenza delle risorse di Cloud KMS.

Panoramica della piattaforma Cloud KMS

La piattaforma Cloud KMS supporta diversi algoritmi crittografici e fornisce metodi per criptare e firmare digitalmente utilizzando chiavi esterne, hardware e software. La piattaforma Cloud KMS è integrata con Identity and Access Management (IAM) e Cloud Audit Logs per consentirti di gestire le autorizzazioni per le singole chiavi e controllarne l'utilizzo.

Diagramma dell'architettura di Cloud KMS.

Il diagramma precedente mostra i seguenti componenti principali della piattaforma Cloud KMS:

  • Gli amministratori accedono ai servizi di gestione delle chiavi utilizzando la console Google Cloud o Google Cloud CLI.
  • Le applicazioni accedono ai servizi di gestione delle chiavi implementando l'API REST, gRPC o le librerie client. Le applicazioni possono utilizzare i servizi Google abilitati per l'uso di CMEK. A sua volta, CMEK utilizza l'API Cloud Key Management Service. Se l'applicazione utilizza PKCS #11, puoi integrarla con Cloud KMS utilizzando la libreria per PKCS #11.

  • L'API Cloud KMS consente di utilizzare software, hardware o chiavi esterne. Sia le chiavi basate su software che quelle basate su hardware utilizzano le protezioni di backup ridondanti di Google.

  • Se utilizzi chiavi hardware, i moduli HSM certificati FIPS 140-2 di livello 3 in Google Cloud le archiviano. Per ulteriori informazioni sulla nostra certificazione, consulta il Certificato n. 4399.

  • Cloud KMS utilizza il datastore interno di Google per archiviare il materiale criptato della chiave del cliente. Questo datastore è ad alta disponibilità e supporta molti dei sistemi critici di Google. Consulta Protezione del datastore.

  • A intervalli regolari, il sistema di backup indipendente esegue il backup dell'intero datastore sull'archiviazione sia online che di archiviazione. Questo backup consente a Cloud KMS di raggiungere i propri obiettivi di durabilità. Consulta Protezione del datastore.

Convalida FIPS 140-2

Le operazioni crittografiche di Cloud KMS vengono eseguite dai nostri moduli convalidati FIPS 140-2. Le chiavi con livello di protezione SOFTWARE e le operazioni di crittografia eseguite con questo livello sono conformi allo standard FIPS 140-2 livello 1. Queste operazioni di crittografia utilizzano BoringCrypto, una libreria crittografica open source gestita da Google. Le chiavi con il livello di protezione HSM e le operazioni crittografiche che eseguono sono conformi allo standard FIPS 140-2 livello 3.

Dipendenze dell'infrastruttura Google

Gli elementi della piattaforma Cloud KMS vengono eseguiti come job Borg di produzione. Borg è il gestore di cluster su larga scala di Google per la gestione dei job di servizio delle API e dei job batch.

Per informazioni sulla sicurezza della nostra infrastruttura fisica e di produzione, consulta la panoramica sulla progettazione della sicurezza dell'infrastruttura di Google.

Job di servizio dell'API Cloud KMS

I job di servizio dell'API Cloud KMS sono job Borg di produzione che soddisfano le richieste dei clienti di gestire e utilizzare le proprie chiavi. I job di servizio dell'API Cloud KMS elaborano anche le azioni differite delle richieste dei clienti, come la rotazione delle chiavi in base alla pianificazione, la creazione di chiavi asimmetriche e l'importazione di chiavi. Questi job di servizio vengono eseguiti in ogni regione di Google Cloud in cui è disponibile Cloud KMS. Ogni job è associato a una singola regione ed è configurato per accedere ai dati solo da sistemi situati geograficamente all'interno della regione Google Cloud associata.

Job batch di Cloud KMS

La piattaforma Cloud KMS offre anche una serie di job batch che vengono eseguiti come job Borg di produzione in varie pianificazioni. I job batch sono specifici per una regione e aggregano solo i dati provenienti dalla regione Google Cloud associata e vengono eseguiti al suo interno. Le attività eseguite da questi job includono quanto segue.

  • Conteggia le chiavi attive per la fatturazione dei clienti.
  • Aggrega le risorse dall'API pubblica del buffer di protocollo per Cloud KMS e inoltra i metadati a Cloud Asset Inventory. Le risorse in questo contesto sono quelle gestite da Cloud KMS, ad esempio chiavi e keyring.
  • Aggrega tutte le risorse e le informazioni dei report per le analisi dell'attività.
  • Dati degli snapshot per l'alta disponibilità.
  • Convalida che tutti i dati archiviati nel datastore sottostante non siano danneggiati.
  • Ricripta il materiale della chiave del cliente durante la rotazione della chiave master KMS.

Servizio di snapshot delle chiavi Cloud KMS

Per mantenere l'alta disponibilità, la piattaforma Cloud KMS gestisce un datastore ridondante in ogni istanza del servizio condiviso che ospita le attività del server dell'API Cloud KMS. Ogni servizio condiviso esegue il deployment della propria istanza del servizio di snapshot. Questa ridondanza rende i servizi estremamente indipendenti, in modo che un eventuale errore in una zona abbia un effetto limitato su altre zone. Quando il job dell'API Cloud KMS deve eseguire un'operazione crittografica, esegue in parallelo una query sul datastore principale e sui job dello snapshot locale. Se il datastore principale è lento o non disponibile, la risposta può essere fornita da uno snapshot, se lo snapshot non ha più di due ore. Gli snapshot vengono creati come output di un job batch eseguito continuamente per ogni area geografica. Gli snapshot si trovano nell'area geografica Cloud associata al materiale della chiave.

Comunicazioni client-server

Google utilizza Application Layer Transport Security (ALTS) per garantire la sicurezza delle comunicazioni client-server che utilizzano il meccanismo di chiamata di procedura remota (RPC) di Google.

Per maggiori informazioni, consulta Autenticazione, integrità e crittografia da un servizio all'altro.

Architettura della piattaforma Cloud KMS

Questa sezione descrive i dettagli dell'architettura relativa alla sicurezza dei materiali chiave e alla protezione del datastore.

Sicurezza dei materiali delle chiavi

In Cloud KMS, il materiale delle chiavi è sempre criptato, sia in stato inattivo che in transito. Il materiale delle chiavi viene decriptato solo nei seguenti casi:

  • Quando il cliente utilizza la chiave.
  • Quando la chiave interna di Google utilizzata per proteggere il materiale della chiave del cliente viene ruotata o verificata per verificarne l'integrità.

Le richieste dei clienti a Cloud KMS vengono criptate in transito tramite TLS tra il cliente e Google Front End (GFE).

L'autenticazione avviene tra tutti i job Cloud KMS, sia all'interno che tra i data center di Google.

Le norme di Google garantiscono che i job utilizzino solo il codice sorgente creato, testato e rivisto in modo verificabile. Autorizzazione binaria per Borg (BAB) applica questo criterio a livello operativo.

I job dell'API Cloud KMS possono accedere ai metadati delle chiavi (ad esempio, il criterio di autorizzazione o il periodo di rotazione). Anche un dipendente Google con una giustificazione aziendale valida e documentata (ad esempio un bug o un problema del cliente) può accedere ai metadati della chiave. Questi eventi di accesso vengono registrati internamente e i log relativi ai dati coperti da Access Transparency sono disponibili anche per i clienti qualificati.

Il materiale della chiave decriptato non può essere esportato o visualizzato tramite l'interfaccia API o un'altra interfaccia utente. Nessun dipendente Google ha accesso al materiale non criptato delle chiavi cliente. Inoltre, il materiale della chiave viene criptato con una chiave master nell'archivio chiavi, a cui nessuno può accedere direttamente. Su un HSM, i job dell'API Cloud KMS non accedono al materiale della chiave in uno stato decriptato.

Protezione del datastore

Il datastore per Cloud KMS è ad alta disponibilità, durevole e protetto.

Disponibilità. Cloud KMS utilizza il datastore interno ad alta disponibilità di Google, che supporta una serie di sistemi critici di Google.

Durabilità. Cloud KMS utilizza la crittografia autenticata per archiviare il materiale delle chiavi dei clienti nel datastore. Inoltre, tutti i metadati vengono autenticati utilizzando un codice HMAC (Hash-based Message Authentication Code) per garantire che non siano stati alterati o danneggiati a riposo. Ogni ora, un job batch scansiona tutti i materiali e i metadati delle chiavi e verifica che gli HMAC siano validi e che il materiale della chiave sia in grado di decriptare. Se i dati sono danneggiati, i tecnici di Cloud KMS vengono immediatamente avvisati in modo che possano intervenire.

Cloud KMS utilizza diversi tipi di backup per il datastore:

  • Per impostazione predefinita, il datastore conserva una cronologia delle modifiche per ogni riga per quattro giorni. In caso di emergenza, questa durata può essere estesa in modo da avere più tempo per risolvere i problemi.
  • Il datastore memorizza ogni ora uno snapshot Lo snapshot può essere convalidato e utilizzato per il ripristino, se necessario. Questi snapshot vengono conservati per quattro giorni.
  • Ogni giorno, un backup completo viene copiato su disco e nello archiviazione dei dati ad accesso sporadico.

Il team di Cloud KMS ha procedure documentate per ripristinare i backup al fine di attenuare la perdita di dati in caso di emergenza lato servizio.

Backup. I backup del datastore Cloud KMS si trovano nella regione Google Cloud associata. Questi backup vengono tutti criptati quando sono inattivi. L'accesso ai dati nei backup è limitato in base alle motivazioni dell'accesso (ad esempio un numero di ticket presentato all'Assistenza Google) e l'accesso da parte di una persona viene registrato nei log di Access Transparency.

Protezione. A livello dell'applicazione Cloud KMS, il materiale della chiave viene criptato prima di essere archiviato. Gli ingegneri con accesso al datastore non hanno accesso al materiale delle chiavi dei clienti in testo non crittografato. Inoltre, il datastore cripta tutti i dati che gestisce prima di essere scritti nello spazio di archiviazione permanente. Pertanto, l'accesso ai livelli di archiviazione sottostanti, inclusi dischi o archiviazione dei dati ad accesso sporadico, non consente di accedere neanche ai dati criptati di Cloud KMS senza accedere alle chiavi di crittografia del datastore, che sono archiviate nell'archivio chiavi.

Criterio di rotazione. La rotazione delle chiavi fa parte delle best practice accettate generalmente per la gestione del materiale delle chiavi. Esiste un criterio di rotazione per le chiavi utilizzate per proteggere i datastore di Cloud KMS. Un criterio di rotazione della chiave viene applicato anche alle chiavi master dell'archivio chiavi che eseguono il wrapping delle chiavi master di Cloud KMS. La chiave master dell'archivio chiavi ha un'età massima pianificata per il testo crittografato di 90 giorni e una durata massima per la chiave memorizzata nella cache del client di un giorno. Cloud KMS aggiorna le chiavi master KMS nelle attività KMS ogni 24 ore e cripta nuovamente tutte le chiavi del cliente su base mensile.

Residenza dei dati. I dati alla base di ogni datastore Cloud KMS rimangono esclusivamente all'interno della regione Google Cloud a cui sono associati i dati. Questo si applica anche alle località in più regioni, ad esempio us.

Disponibilità delle chiavi dopo la creazione

Cloud KMS consente di utilizzare una chiave subito dopo che il datastore Cloud KMS esegue il commit della transazione che crea la chiave e dopo che il livello di archiviazione ne conferma la creazione.

Backend della chiave

Quando crei una chiave con Cloud KMS, puoi scegliere un livello di protezione per determinare quale backend della chiave crea la chiave ed esegue tutte le future operazioni crittografiche su quella chiave. I backend sono esposti nell'API Cloud KMS come i seguenti livelli di protezione:

  • SOFTWARE: si applica alle chiavi il cui wrapping potrebbe essere eseguito da un modulo di sicurezza del software per eseguire operazioni crittografiche.
  • HSM: si applica alle chiavi il cui wrapping può essere eseguito solo dai moduli HSM che eseguono tutte le operazioni crittografiche con le chiavi.
  • EXTERNAL o EXTERNAL-VPC: applica al gestore di chiavi esterno (EKM). EXTERNAL-VPC consente di connettere l'EKM a Google Cloud tramite una rete VPC.

Backend software di Cloud KMS: livello di protezione SOFTWARE

Il livello di protezione SOFTWARE si applica alle chiavi le cui operazioni di crittografia vengono eseguite nel software. Questa sezione descrive i dettagli relativi all'implementazione di questo livello.

Implementazioni algoritmiche

Per le chiavi software, Cloud KMS utilizza il modulo BoringCrypto (BCM) all'interno dell'implementazione BoringSSL di Google per tutte le operazioni crittografiche correlate. Il BCM è convalidato FIPS 140-2. Il dati binari di Cloud KMS sono creati sulla base delle primitive crittografiche di questo modulo, convalidate secondo lo standard FIPS 140-2 livello 1. Gli algoritmi più attuali trattati in questo modulo sono elencati nella sezione Scopi e algoritmi delle chiavi e includono operazioni di crittografia, decriptazione e firma con chiavi di crittografia simmetriche AES256-GCM e asimmetriche RSA 2048, RSA 3072, RSA 4096, EC P256 ed EC P384.

Generazione di numeri casuali ed entropia

Cloud KMS utilizza BoringSSL per generare le chiavi di crittografia. FIPS 140-2 richiede l'utilizzo di generatori interni di numeri pseudocasuali (PRNG), chiamati anche generatori interni di numeri casuali deterministici (DRBG). In BoringCrypto, Cloud KMS utilizza esclusivamente CTR-DRBG con AES-256. Questo fornisce output per RAND_bytes, l'interfaccia principale tramite la quale il resto del sistema riceve dati casuali. Questo PRNG ha origine dall'RNG del kernel Linux, che a sua volta deriva da più origini entropiche indipendenti. Questa seeding include eventi entropici provenienti dall'ambiente del data center, tra cui misurazioni granulari delle ricerche su disco e dei tempi di arrivo tra pacchetti, nonché l'istruzione RDRAND di Intel, se disponibile. Per ulteriori informazioni sul comportamento del generatore di numeri casuali per BoringSSL (modalità conforme a FIPS), consulta la progettazione RG.

Backend di Cloud HSM: livello di protezione HARDWARE

Cloud HSM fornisce chiavi basate su hardware a Cloud KMS. Consente di utilizzare chiavi di crittografia protette da moduli HSM certificati FIPS 140-2 di livello 3 completamente gestiti nei data center di Google. Cloud HSM è ad alta disponibilità e fornisce scalabilità elastica, proprio come Cloud KMS. I clienti Cloud KMS esistenti non devono apportare modifiche all'applicazione, in quanto possono accedere al backend Cloud HSM utilizzando le stesse API e librerie client di Cloud KMS. Per ulteriori informazioni sul backend di Cloud HSM, consulta Architettura di Cloud HSM.

Cloud EKM: livello di protezione ESTERNO

Cloud EKM ti consente di criptare i dati utilizzando chiavi di crittografia off-cloud che rimangono sotto il tuo controllo.

Le chiavi con i livelli di protezione EXTERNAL e EXTERNAL_VPC vengono archiviate e gestite in un sistema di gestione delle chiavi esterno. Per maggiori informazioni, consulta Architetture di riferimento per un deployment affidabile dei servizi Cloud EKM.

Importazione di una chiave

Potresti voler importare nel tuo ambiente cloud le chiavi che hai creato on-premise o in un EKM. Ad esempio, potrebbe esistere un requisito normativo che prevede che le chiavi utilizzate per criptare i dati cloud vengano generate in un modo o in un ambiente specifici. L'importazione delle chiavi ti consente di importarle e di rispettare gli obblighi normativi. Per estendere le tue funzionalità di firma al cloud, puoi anche importare chiavi asimmetriche.

Nell'ambito dell'importazione delle chiavi, Cloud KMS genera una chiave di wrapping pubblica, ovvero una coppia di chiave pubblica/privata, utilizzando uno dei metodi di importazione supportati. La crittografia del materiale della chiave con questa chiave di wrapping protegge il materiale della chiave in transito.

Utilizza la chiave di wrapping pubblica per criptare la chiave da importare sul client. La chiave privata che corrisponde alla chiave pubblica viene archiviata in Google Cloud e viene utilizzata per annullare il wrapping della chiave pubblica dopo che raggiunge il progetto Google Cloud. Il metodo di importazione scelto determina l'algoritmo utilizzato per creare la chiave di wrapping. Dopo aver eseguito il wrapping del materiale della chiave, puoi importarlo in una nuova chiave o versione della chiave su Cloud KMS.

Puoi usare le chiavi importate con il livello di protezione HSM o SOFTWARE. Per Cloud HSM, la parte della chiave privata della chiave di wrapping è disponibile solo in Cloud HSM. La limitazione della parte della chiave privata a Cloud HSM impedisce a Google di eseguire l'unwrapping del materiale della chiave al di fuori di Cloud HSM.

Chiavi di crittografia gestite dal cliente (CMEK)

Per impostazione predefinita, Google Cloud cripta tutti i dati dei clienti archiviati at-rest e Google gestisce le chiavi utilizzate per la crittografia. Per alcuni prodotti Google Cloud, puoi utilizzare Cloud KMS per gestire le chiavi utilizzate per la crittografia. La CMEK può essere utilizzata per chiavi esterne, software e hardware. Cloud KMS consente di controllare molti aspetti delle chiavi (come la creazione, l'abilitazione, la disattivazione, la rotazione e l'eliminazione delle chiavi) e di gestire le autorizzazioni IAM appropriate. Per applicare una separazione consigliata dei compiti, Cloud KMS include diversi ruoli IAM predefiniti con privilegi e limitazioni specifici che possono essere concessi a utenti e account di servizio specifici.

La rotazione della chiave Cloud KMS non cripta nuovamente i dati nel servizio CMEK associato. Le risorse appena create vengono criptate usando la nuova versione della chiave, il che significa che versioni diverse di una chiave proteggono diversi sottoinsiemi di dati. Ad esempio, BigQuery non ruota automaticamente una chiave di crittografia della tabella quando la chiave Cloud KMS associata alla tabella ruota. Le tabelle BigQuery esistenti continuano a utilizzare la versione della chiave con cui sono state create. Le nuove tabelle BigQuery utilizzano la versione della chiave corrente. Per ulteriori informazioni, consulta la documentazione di ciascun prodotto.

I criteri dell'organizzazione CMEK forniscono un maggiore controllo su come viene utilizzata la CMEK all'interno dei tuoi progetti. Questi criteri consentono di controllare sia i servizi che i progetti che contengono le chiavi consentite per CMEK.

Google Cloud supporta CMEK per molti servizi, tra cui Cloud Storage, BigQuery e Compute Engine. Consulta le integrazioni CMEK per l'elenco completo delle integrazioni e dei servizi conformi a CMEK. Google continua a investire nell'integrazione CMEK per altri prodotti Google Cloud.

Ciclo di vita di una richiesta Cloud KMS

Questa sezione descrive il ciclo di vita di una richiesta Cloud KMS, inclusa una discussione sull'eliminazione del materiale delle chiavi. Il seguente diagramma mostra un client che richiede l'accesso alle istanze di servizio Cloud KMS in us-east1 e us-west1 e il modo in cui le richieste vengono instradate utilizzando Google Front End (GFE).

Diagramma del ciclo di vita di una richiesta KMS.

I passaggi di questo ciclo di vita sono i seguenti:

  1. Un cliente, o un job in esecuzione per conto di un cliente, scrive una richiesta al servizio Cloud KMS, https://cloudkms.googleapis.com. Il DNS risolve questo indirizzo in un indirizzo IP anycast del GFE.
  2. GFE offre l'hosting degli IP pubblici per il nome DNS pubblico, la protezione DoS (Denial of Service) e la terminazione TLS. Quando il cliente invia la sua richiesta, in genere questa viene instradata a un GFE vicino al cliente, indipendentemente dalla località a cui viene indirizzata la richiesta del cliente. I GFE gestiscono la negoziazione TLS e, utilizzando l'URL e i parametri della richiesta, determinano quale bilanciatore del carico globale (GSLB) instrada la richiesta.
  3. Esiste un bilanciatore del carico software globale di destinazione separato per ogni area geografica Cloud KMS. Se la richiesta arriva a Google in us-east1 ed è destinata a us-west1, viene instradata tra i data center us-east1 e us-west1. Tutte le comunicazioni tra i data center sono criptate in transito tramite ALTS, che esegue l'autenticazione reciproca dei job GFE e Cloud KMS.
  4. Quando la richiesta raggiunge il job Cloud KMS, viene prima elaborata da un framework che gestisce gran parte del lavoro comune a tutti i servizi Google Cloud. Questo framework autentica l'utente ed esegue una serie di controlli per verificare quanto segue:
    • Il cliente dispone di una credenziale valida e può essere autenticato.
    • Il progetto ha l'API Cloud KMS abilitata e ha un account di fatturazione valido.
    • La quota è sufficiente per eseguire la richiesta.
    • Il cliente è nella lista consentita per utilizzare la regione Google Cloud pertinente.
    • La richiesta non viene rifiutata dai Controlli di servizio VPC.
  5. Una volta superati questi controlli, il framework inoltra la richiesta e le credenziali a Cloud KMS. Cloud KMS analizza la richiesta per determinare le risorse a cui viene eseguito l'accesso, quindi verifica con IAM se il chiamante è autorizzato a effettuare la richiesta. IAM indica inoltre a Cloud KMS se la richiesta deve essere scritta negli audit log.
  6. Dopo l'autenticazione e l'autorizzazione della richiesta, Cloud KMS chiama i backend del datastore nella regione per recuperare la risorsa richiesta. Una volta recuperata la risorsa, il materiale della chiave del cliente viene decriptato per essere utilizzato.
  7. Con il materiale della chiave, Cloud KMS esegue quindi l'operazione di crittografia, inoltrando la versione con wrapping della chiave al backend software Cloud KMS, al backend Cloud HSM o al backend Cloud EKM, a seconda del livello di protezione della chiave.
  8. Al termine dell'operazione crittografica, la risposta viene inviata al cliente lungo lo stesso tipo di canale da GFE a KMS della richiesta.
  9. Quando viene restituita la risposta, Cloud KMS attiva anche alcuni eventi in modo asincrono:
    • Gli audit log e i log della richiesta vengono compilati e inseriti in una coda di scrittura.
    • I rapporti vengono inviati per la fatturazione e la gestione delle quote.
    • Se la richiesta ha aggiornato i metadati di una risorsa, la modifica viene inviata a Cloud Asset Inventory tramite aggiornamenti di job batch.

Integrità dei dati end-to-end

Cloud KMS consente di calcolare checksum per chiavi e materiali delle chiavi per garantire che non siano danneggiati. Questi checksum contribuiscono a proteggerti dalla perdita di dati che potrebbe essere causata da danni dell'hardware o del software. Le librerie di supporto consentono di verificare l'integrità della chiave. Puoi utilizzare le librerie helper per verificare l'integrità della chiave fornendo checksum a Cloud KMS, verificati dal server. Inoltre, queste librerie consentono di ricevere checksum per verificare i dati di risposta sul client.

L'integrità dei dati end-to-end aiuta a proteggere l'ambiente da minacce come le seguenti:

  • Danneggiamento durante il transito, ad esempio nello stack tra il momento in cui i dati vengono inviati e il momento in cui vengono protetti da TLS.
  • Problemi in eventuali proxy intermedi tra l'endpoint e KMS (ad esempio, per le richieste in entrata).
  • Operazioni di crittografia non corrette, danneggiamento della memoria delle macchine o dei moduli HSM nell'architettura di Cloud KMS.
  • Danneggiamento durante la comunicazione con un EKM esterno.

Per maggiori informazioni, consulta Verificare l'integrità dei dati end-to-end.

Eliminazione del materiale delle chiavi

Il materiale della chiave è considerato come dati dei clienti, per cui l'approccio descritto in Eliminazione dei dati su Google Cloud si applica anche a Cloud KMS. Il materiale della chiave viene eliminato su richiesta, quando il periodo pianificata per l'eliminazione è completo e i backup scadono. Il materiale della chiave ancora presente nei backup (al termine del periodo pianificato per l'eliminazione) può essere utilizzato solo per il ripristino di emergenza a livello di regione e non per il ripristino di singole chiavi. Questo processo non è garantito per le copie di chiavi importate che esistono al di fuori del controllo di Cloud KMS.

Per impostazione predefinita, le chiavi in Cloud KMS rimangono nello stato Pianificata per l'eliminazione (eliminata temporaneamente) per 24 ore prima che il materiale della chiave venga eliminato logicamente dal sistema. Puoi modificare questa durata. Per maggiori informazioni, consulta Durata variabile dello stato di eliminazione pianificata.

Anche se il materiale della chiave viene eliminato, le chiavi e i keyring non possono essere eliminati. Anche le versioni della chiave non possono essere eliminate, ma il materiale delle versioni della chiave può essere eliminato in modo che le risorse non possano più essere utilizzate. I keyring e le chiavi non hanno costi fatturabili o limitazioni di quota, quindi la loro esistenza non influisce sui costi o sui limiti di produzione.

Dopo aver pianificato l'eliminazione di una versione della chiave, la versione della chiave non è disponibile per le operazioni crittografiche. Durante il periodo di eliminazione in attesa, puoi ripristinare la versione della chiave in modo che non venga eliminata.

Se elimini per sbaglio una chiave importata, puoi reimportarla. Per ulteriori informazioni, consulta Reimportazione di una chiave eliminata.

Per evitare di eliminare accidentalmente una chiave, prendi in considerazione le seguenti best practice:

  • Crea un ruolo KMS personalizzato che non includa l'autorizzazione cloudkms.cryptoKeyVersions.destroy.
  • Modifica il campo destroy_scheduled_duration impostando un periodo di tempo più lungo.
  • Monitora e aggiungi avvisi per eventi di distruzione delle chiavi. Ad esempio, crea il seguente filtro Cloud Logging:

      resource.type="cloudkms_cryptokeyversion"
      protoPayload.methodName="DestroyCryptoKeyVersion"
    
  • Crea processi che disabilitano la chiave per un paio di giorni prima che venga eliminata.

Ambiente operativo della piattaforma Cloud KMS

L'ambiente operativo per la piattaforma Cloud KMS include criteri di archiviazione e sicurezza dei dati, limitazioni degli accessi e strategie di riduzione dei rischi che permettono di ottimizzare l'affidabilità, la durabilità e la disponibilità, proteggendo al contempo il materiale delle chiavi. Questa sezione descrive la struttura operativa del servizio, le responsabilità dei membri del team operativo, i meccanismi di autenticazione e i protocolli di controllo e logging. Questa sezione riguarda le funzionalità delle chiavi basate su software e hardware.

Tecnici software, SRE e operatori di sistema

I tecnici del software sono responsabili della collaborazione con altri stakeholder, ad esempio product manager e SRE (Site Reliability Engineer), per progettare il sistema e scrivere gran parte del codice e dei test per il servizio Cloud KMS. Il codice include il job principale che gestisce le richieste dei clienti, nonché job secondari per attività come la replica e la fatturazione dei dati. Anche gli SRE possono scrivere codice. Tuttavia, i compiti dei software engineer e degli SRE sono separati; gli SRE sono principalmente responsabili della gestione dell'ambiente di produzione per i job Cloud KMS. Gli SRE misurano e garantiscono l'affidabilità tramite attività di progettazione e operative.

Gli operatori di sistema sono responsabili del processo di build e rilascio, monitoraggio, gestione degli avvisi e pianificazione delle capacità per Cloud KMS. Sono i primi a rispondere ai problemi dei clienti e in caso di interruzioni di Cloud KMS. Ad esempio, gli operatori di sistema sfruttano vari strumenti e meccanismi di automazione per ridurre al minimo l'intervento manuale sui sistemi, in modo da concentrarsi su attività che generano valore a lungo termine.

I compiti per gli operatori di sistema sono definiti nelle procedure operative standard. Gli operatori di sistema non accedono al materiale delle chiavi dei clienti durante le loro mansioni.

Aree geografiche delle risorse Cloud KMS

Per soddisfare qualsiasi requisito di residenza delle chiavi, puoi creare risorse Cloud KMS in uno dei quattro tipi di località Google Cloud:

  • Una località geografica è composta dalle zone di una posizione geografica specifica, ad esempio l'Iowa.
  • Una località a due regioni è composta da zone in due luoghi geografici specifici, ad esempio Iowa e Carolina del Sud.
  • Una località con più regioni è composta da zone distribuite in un'area geografica generale, ad esempio gli Stati Uniti.
  • La località globale è composta da zone distribuite in tutto il mondo. Quando crei le tue risorse Cloud KMS nella località globale, sono disponibili nelle zone di tutto il mondo.

Le località rappresentano le aree geografiche in cui vengono gestite le richieste a Cloud KMS per una determinata risorsa e dove vengono archiviate le chiavi di crittografia corrispondenti.

Per ulteriori informazioni sulle località di Cloud KMS disponibili, consulta Località di Cloud KMS.

Aree geografiche e data center Cloud

Una regione Google Cloud contiene uno specifico data center o un set specifico di data center, determinato dalla sua designazione come singola regione, doppia regione, più regioni o globale. Per maggiori informazioni sulle regioni di Google Cloud, consulta Località di Google Cloud.

Ogni data center contiene rack di macchine per computing, networking o archiviazione dei dati. Queste macchine utilizzano l'infrastruttura Borg di Google.

I requisiti di sicurezza fisica dei data center Google sono molto rigorosi. Qualsiasi spazio fisico che potrebbe contenere dati degli utenti richiede ingressi con lettori di badge e scanner dell'iride utilizzati per autenticare i partecipanti. Le porte non sono aperte a più persone, ognuno deve autenticarsi individualmente. Non è consentito portare bagagli all'interno o all'esterno di queste aree, a meno che non si tratti di bagagli trasparenti autorizzati esplicitamente dopo l'ispezione del personale di sicurezza. È necessaria un'autorizzazione speciale per portare all'interno o all'esterno di queste aree qualsiasi dispositivo elettronico che possa trasmettere o registrare dati.

Localizzazione delle chiavi

Alcuni settori richiedono che le chiavi crittografiche si trovino in una località specifica. Cloud KMS dispone di termini per la località dei dati con garanzie sulla residenza dei dati. Come introdotto nella sezione Aree geografiche delle risorse Cloud KMS, Cloud KMS offre quattro tipi di località a livello di regione per aiutarti a soddisfare questi requisiti.

Per località con una, due o più regioni, Cloud KMS crea, archivia ed elabora le chiavi software e hardware e il materiale delle chiavi solo in quella località. I sistemi di archiviazione ed elaborazione dei dati utilizzati da Cloud KMS sono configurati per utilizzare solo le risorse all'interno della regione di Google Cloud associate al materiale della chiave. Il materiale delle chiavi creato in località con due o più regioni non lascia i confini delle località selezionate.

Per la regione globale, non sono state specificate garanzie di regione.

Cloud KMS non garantisce la residenza per i metadati delle chiavi, i log di utilizzo o per il materiale delle chiavi in transito. I metadati delle chiavi includono nomi delle risorse, proprietà delle risorse Cloud KMS come tipo, dimensione della chiave e stato della chiave, criteri IAM e tutti i dati derivati dai metadati.

Quando utilizzi CMEK, le seguenti limitazioni geografiche di Cloud KMS si applicano alle tue chiavi indipendentemente dalle località personalizzate, a due regioni o a più regioni che scegli in altri prodotti Google Cloud che supportano CMEK:

  • Per una regione specifica: poiché la regione di una chiave KMS gestita dal cliente deve sempre essere correlata alla regione della risorsa che protegge in un determinato servizio Google Cloud, viene garantita la compatibilità e l'applicazione delle limitazioni di residenza per chiavi e risorse a livello di singola regione.
  • Per località con due o più regioni: gli utenti possono selezionare località multiregionali definite da Google per le chiavi e le risorse Google Cloud per garantire la conformità della residenza. Per garantire questa localizzazione geografica, assicurati che le regioni degli altri prodotti siano in linea con la località regionale di Cloud KMS scelta.

La seguente tabella riassume la residenza del materiale delle chiavi per Cloud KMS.

Tipo di regione A riposo, in uso
Area geografica singola Residente
Due regioni o più regioni Residente nelle regioni con due o più regioni

Monitoraggio delle aree geografiche

I servizi interni di monitoraggio dei dati di Google controllano attivamente la localizzazione delle chiavi. Cloud KMS invia avvisi ai membri del team SRE se rileva errori di configurazione accidentali o se il materiale delle chiavi esce dai confini dell'area geografica configurata oppure se viene archiviato o utilizzato nell'area geografica errata.

Alta disponibilità

Cloud KMS può aiutarti a semplificare i requisiti di disponibilità in base alle regioni selezionate. Più la località è granulare, più ridondanza devi creare. Per le applicazioni con livelli di disponibilità più elevati, utilizza località su più regioni anziché provare a creare il tuo sistema di replica di chiavi. Devi bilanciare le funzionalità di ridondanza integrate con le tue esigenze di regionalizzazione dei dati.

autentica e autorizza

Cloud KMS accetta vari meccanismi di autenticazione, ad esempio OAuth2, JWT e ALTS. A prescindere dal meccanismo, Cloud KMS risolve la credenziale fornita per identificare l'entità (l'entità che è autenticata e che autorizza la richiesta) e chiama IAM per verificare se l'entità è autorizzata a effettuare la richiesta e se un audit log è scritto.

Cloud KMS utilizza una versione interna dell'API Service Control pubblica per molti aspetti della gestione dei servizi. Prima di gestire una richiesta, un job Cloud KMS invia una richiesta di controllo all'API Service Control, che applica molti controlli comuni a tutti i servizi Google Cloud, tra cui:

  • È in corso la verifica dell'attivazione dell'API Cloud KMS e della disponibilità di un account di fatturazione attivo.
  • Verifica di non aver superato la quota e report sull'utilizzo della quota.
  • Applicazione dei Controlli di servizio VPC.
  • È in corso la verifica della tua presenza nella lista consentita per le aree geografiche del cloud privato applicabili.

Gestione delle quote

Cloud KMS prevede limiti di utilizzo, denominati quotas, per le richieste inviate al servizio. Cloud KMS contiene le seguenti quote:

  • Quote per le richieste crittografiche per operazioni come crittografia, decriptazione o firma.
  • Quote delle richieste di lettura per operazioni quali il recupero di metadati delle chiavi o il recupero di un criterio IAM.
  • Quote di richieste di scrittura per operazioni quali la creazione di una chiave o l'impostazione di un criterio IAM.

Queste quote vengono addebitate al progetto associato al chiamante. Inoltre, queste quote sono globali, il che significa che vengono applicate per l'utilizzo di KMS del chiamante in tutte le regioni e in tutte le aree geografiche. Queste quote vengono valutate per tutti i livelli di protezione.

Cloud HSM e Cloud EKM prevedono quote aggiuntive per le operazioni di crittografia. Queste quote devono essere soddisfatte oltre alla quota per le richieste crittografiche. Le quote di Cloud HSM e Cloud EKM vengono addebitate al progetto in cui si trova la chiave e le quote vengono applicate per ogni località.

Considera i seguenti esempi:

  • Le chiamate per la decriptazione con una chiave software in asia-northeast1 richiedono un'unità di richieste crittografiche (globali).
  • La creazione di una chiave HSM in us-central1 richiede un'unità di quota per le richieste di scrittura e nessuna quota HSM.
  • Le chiamate di crittografia con una chiave EKM in europe richiedono un'unità di quota di richieste crittografiche (globali) e un'unità di quota di richieste KMS esterne in europe.

Per ulteriori informazioni sul tipo di quote disponibili, consulta Quote sull'utilizzo delle risorse di Cloud KMS. Puoi visualizzare il limite di quota nella console Cloud. I limiti di quota iniziali sono limiti flessibili che puoi richiedere regolare in base alle esigenze del tuo carico di lavoro.

Logging

A Cloud KMS sono associati tre tipi di log: Cloud Audit Logs, Access Transparency e i log interni delle richieste.

Cloud Audit Logs

Cloud KMS registra le attività in Cloud Audit Logs. Puoi visualizzare questi log nella console Cloud. Tutte le attività di amministrazione, ad esempio la creazione o l'eliminazione di una chiave, vengono registrate nei log. Puoi anche scegliere di abilitare il logging per tutte le altre azioni che utilizzano una chiave, ad esempio l'utilizzo di una chiave per criptare o decriptare i dati. Puoi stabilire per quanto tempo conservare i log e chi può visualizzarli.

Log di trasparenza degli accessi

I clienti idonei possono scegliere di attivare i log di Access Transparency, che forniscono loro i log delle azioni che i dipendenti di Google eseguono nella tua organizzazione Google Cloud. I log di Access Transparency, insieme ai log di Cloud Audit Logs, possono aiutarti a rispondere a domande su chi ha fatto cosa, dove e quando.

Puoi integrare i log di Access Transparency con i tuoi strumenti di gestione degli eventi e delle informazioni di sicurezza (SIEM) esistenti per automatizzare i controlli di queste azioni. Questi log sono disponibili nella console Cloud insieme a Cloud Audit Logs.

Le voci dei log di Access Transparency includono i seguenti tipi di dettagli:

  • La risorsa e l'azione interessate.
  • L'ora dell'azione.
  • I motivi dell'azione. Questi includono, ad esempio, assistenza richiesta dal cliente (con un numero di richiesta), assistenza offerta da Google, richieste di dati di terze parti e richieste di revisione avviate da Google.
  • Dati su chi agisce sui dati (ad esempio, la posizione del membro del personale Google).

Log interni delle richieste

I log delle richieste archiviano un record per ogni richiesta inviata alla piattaforma Cloud KMS. Questo record contiene dettagli sul tipo di richiesta (ad esempio metodo o protocollo API) e sulla risorsa a cui viene eseguito l'accesso (ad esempio nome della risorsa, algoritmo della chiave o livello di protezione della chiave). Questi log non archiviano il testo non crittografato, il testo crittografato o il materiale delle chiavi dei clienti. Prima che nuovi tipi di dati vengano aggiunti a questi log, un team specializzato nelle revisioni della privacy deve approvare le modifiche ai dati registrati.

Le voci dei log vengono eliminate definitivamente quando scade la durata (TTL) configurata.

I tecnici e gli SRE di Cloud KMS che si occupano delle richieste di assistenza possono accedere ai log delle richieste. L'accesso ai log da parte di una persona e qualsiasi accesso che restituisce i dati dei clienti richiedono una giustificazione lavorativa valida e documentata. Con alcune eccezioni specifiche, l'accesso da parte di persone fisiche viene registrato e accessibile ai clienti idonei nei log di Access Transparency.

Monitoraggio

Cloud KMS si integra con Cloud Monitoring. Questa integrazione consente di monitorare, creare dashboard e creare avvisi su molte operazioni di Cloud KMS. Ad esempio, puoi monitorare quando viene pianificata l'eliminazione delle chiavi o monitorare e modificare le quote di Cloud KMS quando le operazioni crittografiche superano una soglia da te definita. Per ulteriori informazioni sulle metriche di Cloud KMS disponibili, consulta Utilizzo di Cloud Monitoring con Cloud KMS.

Inoltre, Security Command Center dispone di rilevatori di vulnerabilità KMS integrati. Questi rilevatori contribuiscono a garantire che i progetti che includono chiavi seguano le nostre best practice consigliate. Per ulteriori informazioni sul rilevamento di vulnerabilità di KMS, consulta Risultati di vulnerabilità per Cloud KMS.

Passaggi successivi