Approfondimenti su Cloud Key Management Service

Questi contenuti sono stati aggiornati l'ultima volta a luglio 2023 e rappresentano lo status quo alla data dall'ora in cui è stato scritto. Le norme e i sistemi di sicurezza di Google potrebbero cambiare nel miglioramento continuo della protezione dei 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 la piattaforma Cloud Key Management Service (Cloud KMS), puoi ottenere un maggiore controllo sulla crittografia at-rest dei dati e su come vengono le chiavi di crittografia gestito.

La seguente tabella 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 sono gestite esclusivamente da Google.	I dati di più clienti potrebbero utilizzare la stessa crittografia della chiave chiave (KEK).	Sì, vedi Crittografia at-rest predefinita.	Gratuito.
Chiavi Cloud KMS	Queste chiavi sono controllate dal cliente.	Univoco per un cliente.	Sì per la crittografia simmetrica, no per le chiavi asimmetriche. Vedi Rotazione della chiave.	Consulta 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 che di archiviazione in Google Cloud. Questo documento è destinato a prendere decisioni tecniche maker che necessitano di dettagli sull'architettura, l'infrastruttura e funzionalità di machine learning. Questo documento presuppone che tu abbia una conoscenza di base concetti di crittografia e architetture cloud.

Punti di forza della progettazione di Cloud KMS

Con Cloud KMS, l'obiettivo di Google è fornire un servizio di gestione più efficiente, con la più ampia gamma di opzioni che puoi controllare. Cloud KMS è supportato dai seguenti cinque pilastri di progettazione:

• Controllo dei clienti: Cloud KMS consente di controllare e chiavi hardware e software per la crittografia e la firma. Questo pilastro comprende supporto per il modello BYOK (Bring Your Own Key) e per la modalità hold-your-own-key (HYOK).
• Controllo e monitoraggio dell'accesso: con Cloud KMS, puoi: gestire le autorizzazioni per le singole chiavi e monitorarne l'utilizzo.
• Area geografica: Cloud KMS offre la regionalizzazione . Il servizio è configurato per creare, archiviare ed elaborare le chiavi solo alla località Google Cloud che hai selezionato.
• Backup: per contribuire a evitare il danneggiamento dei dati e per verificare che i dati possono essere decriptati correttamente, Cloud KMS analizza periodicamente ed esegue il backup di tutto il materiale e dei metadati della chiave.
• Sicurezza: Cloud KMS offre una protezione efficace contro l'accesso non autorizzato alle chiavi ed è completamente integrato con 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 ambiente per l'uso diretto o per altre risorse cloud e diverse applicazioni.

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

Le opzioni mostrate nel diagramma precedente sono le seguenti:

• Crittografia predefinita: tutti i dati archiviati da Google sono criptati a livello di archiviazione usando l'algoritmo AES (Advanced Encryption Standard) algoritmo AES-256. Generiamo e gestiamo le chiavi per la crittografia predefinita, e i clienti non hanno accesso alle chiavi o controllo della rotazione della chiave gestione dei dispositivi. Le chiavi di crittografia predefinite potrebbero essere condivise tra i clienti. Per ulteriori informazioni, vedi Crittografia at-rest predefinita.

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

• Cloud KMS con chiavi generate dall'hardware (Cloud HSM): Utilizzando Cloud KMS con il backend Cloud HSM, puoi gestire le chiavi generati e archiviati in hardware di proprietà e gestito da Google moduli di sicurezza (HSM). Se hai bisogno di una chiave protetta da hardware, puoi puoi utilizzare il backend Cloud HSM per garantire che le tue macchine simmetriche le chiavi asimmetriche vengono utilizzate solo FIPS 140-2 Livello 3: convalidato HSM.

• Cloud KMS con importazione delle chiavi: per soddisfare i requisiti BYOK, puoi importare le tue chiavi di crittografia generate da te. Puoi utilizzare e gestire queste chiavi al di fuori Google Cloud e utilizzare il materiale delle chiavi in Cloud KMS crittografare o firmare i dati archiviati in Google Cloud.

• Cloud KMS con il gestore di chiavi esterno (Cloud EKM): Per soddisfare i requisiti di HYOK, puoi creare e controllare chiavi che in un gestore di chiavi esterno a Google Cloud. Poi configura la piattaforma Cloud KMS in modo che utilizzi le chiavi esterne per e proteggere i dati at-rest. Puoi utilizzare queste chiavi di crittografia con un Chiave Cloud EKM. Per ulteriori informazioni sulla gestione delle chiavi esterne e Cloud EKM, consulta Architetture di riferimento per un deployment affidabile dei servizi Cloud EKM.

Puoi scegliere di utilizzare chiavi generate da Cloud KMS insieme ad 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 delle un'infrastruttura di gestione delle chiavi multilivello.

Keyring, chiavi e versioni delle chiavi

Il seguente diagramma illustra i raggruppamenti di chiavi e mostra i keyring e le chiavi con un'unica versione principale e più versioni precedenti.

I concetti chiave mostrati nel diagramma precedente sono i seguenti:

• Chiave:un oggetto denominato che rappresenta una chiave di crittografia utilizzata per uno scopo specifico. Il materiale della chiave: le bit effettivamente utilizzate per le operazioni crittografiche, possono cambiare nel tempo man mano che crei una nuova chiave. e versioni successive. Puoi assegnare criteri di autorizzazione IAM a livello di chiave nella nella gerarchia delle risorse.

  Lo scopo e altri attributi della chiave sono collegati gestiti con la chiave. Di conseguenza, la chiave è l'oggetto più importante sull'utilizzo di KMS.

  Cloud KMS supporta le chiavi sia simmetriche che asimmetriche. R la chiave simmetrica viene utilizzata per creare o convalidare le firme MAC o per la crittografia simmetrica per proteggere alcuni corpus di dati. Ad esempio, puoi Utilizzare AES-256 in modalità GCM per crittografare un blocco di testo non crittografato. Una chiave asimmetrica può essere utilizzata per la crittografia o la firma asimmetrica. Per maggiori informazioni le informazioni, vedi Scopi e algoritmi supportati.

• Keyring: si tratta di un raggruppamento di chiavi a fini organizzativi. R key ring appartiene a un progetto Google Cloud e si trova in una località specifica. Chiavi i criteri di autorizzazione dal proprio keyring. Raggruppamento di chiavi con funzioni autorizzazioni in un keyring consente di concedere, revocare o modificare le autorizzazioni i tasti a livello di keyring senza dover intervenire su ciascun tasto singolarmente. I keyring offrono convenienza e categorizzazione, ma se il raggruppamento di keyring non ti è utile, puoi gestire le autorizzazioni direttamente sui tasti. Tag puoi consentire o negare in modo condizionale i criteri a seconda che una risorsa ha un tag specifico. Puoi applicare i tag a livello di keyring nella nella gerarchia delle risorse.

  Per evitare collisioni di nomi delle risorse, non puoi eliminare un keyring o chiave. I keyring e le chiavi non hanno costi fatturabili o limitazioni di quota, quindi il loro proseguimento non influisce sui costi o sui limiti di produzione.

• Metadati delle chiavi: nomi delle risorse, proprietà delle risorse KMS come di autorizzazione, il tipo di chiave, le dimensioni e lo stato della chiave, oltre a tutti i dati derivanti e i keyring.

• Versione chiave: il materiale della chiave associato a una chiave in un determinato momento nel tempo. La versione chiave è la risorsa che contiene il materiale effettivo della chiave. Le versioni sono numerati in sequenza, a partire dalla versione 1. Quando una chiave viene ruotata, viene creata una nuova versione della chiave con un nuovo materiale della chiave. La stessa chiave logica può avere più versioni nel tempo, il che significa che i dati sono criptati usando versioni diverse della chiave. Le chiavi simmetriche hanno una versione principale. Di per impostazione predefinita, per la crittografia viene utilizzata la versione primaria. Quando Cloud KMS esegue la decriptazione mediante 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 l'archivio chiavi interno di Google. Cloud KMS utilizza l'archivio chiavi, che è lo strumento per il wrapping delle chiavi criptate su Cloud KMS. Crittografia della busta è il processo di crittografia di una chiave con un'altra chiave, per garantire memorizzarli o trasmetterli su un canale non attendibile. Cloud KMS utilizza la stessa radice di attendibilità dell'archivio chiavi.

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

1. Una chiave di crittografia dei dati (DEK, Data Encryption Key) cripta i blocchi di dati.
2. Una chiave di crittografia della chiave (KEK) viene utilizzata per criptare o sottoporre a wrapping la DEK. Tutti Opzioni della piattaforma Cloud KMS (software, hardware ed ) ti consentono di controllare la KEK. Le KEK vengono archiviate in Cloud KMS.
3. Una chiave master del KMS cripta la KEK. La chiave master KMS è archiviata in Archivio chiavi. Nell'archivio chiavi è presente una chiave master KMS separata per ogni Località Cloud KMS. Le KEK in Cloud KMS sono protette dalla chiave master KMS della località. Ciascun server Cloud KMS recupera una copia della chiave master KMS durante come dipendenza rigida e viene creata una nuova copia recuperate ogni giorno. La chiave master del KMS viene ricriptata periodicamente.
4. La chiave master del KMS è protetta dalla chiave master dell'archivio chiavi nell'archivio chiavi.
5. La chiave master dell'archivio chiavi è protetta dalla chiave master dell'archivio chiavi principale.

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

Principali vincoli operativi

Cloud KMS opera all'interno dei seguenti vincoli:

• Progetto: le risorse Cloud KMS appartengono a un progetto Google Cloud, proprio come tutte le altre risorse Google Cloud. Puoi ospitare i dati in un diverso da quello in cui Cloud KMS le chiavi esistenti. Per supportare la best practice separazione dei compiti tra gli amministratori delle chiavi e degli amministratori dei dati, puoi rimuovere del progetto chiave.
• Località: all'interno di un progetto, le risorse Cloud KMS vengono creato in un località. Per ulteriori informazioni sulle sedi, vedi Area geografica e regioni.
• Coerenza: Cloud KMS propaga le operazioni su chiavi, chiave e versioni delle chiavi usando elevata coerenza o coerenza finale. Per ulteriori informazioni, vedi Coerenza delle risorse di Cloud KMS.

Panoramica della piattaforma Cloud KMS

La piattaforma Cloud KMS supporta più algoritmi crittografici e fornisce metodi per criptare e firmare in modo digitale utilizzando basate su software. La piattaforma Cloud KMS è integrata con Identity and Access Management (IAM) e Audit log di Cloud in modo da poter gestire le autorizzazioni per le singole chiavi e controllarne in uso.

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

• Gli amministratori accedono ai servizi di gestione delle chiavi utilizzando la console Cloud o Google Cloud CLI.

• Le applicazioni accedono ai servizi di gestione delle chiavi implementando API REST, gRPC, o librerie client. Le applicazioni possono utilizzare i servizi Google abilitati per l'utilizzo di CMEK. CMEK in utilizza l'API Cloud Key Management Service. Se la tua applicazione utilizza PKCS #11, puoi integrarlo con Cloud KMS utilizzando raccolta 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 il backup ridondante di Google e protezioni di sicurezza.

• Se si utilizzano chiavi hardware, gli HSM certificati FIPS 140-2 di livello 3 in e Google Cloud archivia le chiavi. Per ulteriori informazioni sulle nostre certificazione, consulta Certificato n. 4399.

• Cloud KMS utilizza il datastore interno di Google per archiviare contenuti crittografati materiale 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 archiviazione sia online che in archiviazione dei dati ad accesso sporadico. Questo backup consente a Cloud KMS per raggiungere i suoi obiettivi di durabilità. Consulta: Protezione del datastore.

Convalida FIPS 140-2

Le operazioni crittografiche di Cloud KMS vengono eseguite dal nostro sistema FIPS 140-2 moduli convalidati. I token con il livello di protezione SOFTWARE e il le operazioni crittografiche eseguite sono conformi allo standard FIPS 140-2 Livello 1. Queste operazioni di crittografia utilizzano BoringCrypto una libreria crittografica open source gestita da Google. I tasti con il livello di protezione di HSM e le operazioni crittografiche eseguite con il livello 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 di job di servizi API e batch di lavoro.

Per informazioni sulla sicurezza dei nostri sistemi fisici e infrastruttura, consulta Panoramica sulla progettazione della sicurezza dell'infrastruttura Google.

Job di servizio dell'API Cloud KMS

I job di gestione dell'API Cloud KMS sono job Borg di produzione che servono i clienti richiede di gestire e utilizzare le proprie chiavi. Anche i job di gestione dell'API Cloud KMS elaborare azioni differite dalle richieste dei clienti, come la rotazione delle chiavi in base a una pianificazione, creazione di chiavi asimmetriche e importazione di chiavi. Questi job di gestione vengono eseguiti della regione Google Cloud Cloud KMS è disponibile. Ogni job è associato a una singola regione ed è configurato per accedere solo provenienti da sistemi che si trovano geograficamente all'interno regione Google Cloud.

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 regione aggregare solo i dati e li esegue al suo interno regione. Le attività eseguite da questi job includono quanto segue.

• Conta chiavi attive per fatturazione del cliente.
• Aggrega le risorse API buffer protocollo pubblico per Cloud KMS e l'inoltro dei metadati 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 aziendali.
• Dati di snapshot per l'alta disponibilità.
• Verifica che tutti i dati archiviati nel datastore sottostante siano danneggiati.
• Ricripta il materiale della chiave del cliente quando la chiave master KMS viene ruotata.

Servizio di snapshot delle chiavi Cloud KMS

Per mantenere l'alta disponibilità, la piattaforma Cloud KMS mantiene un datastore ridondante in ogni istanza del servizio condiviso che ospita Attività server dell'API Cloud KMS. Ogni servizio condiviso esegue il deployment della propria istanza servizio snapshotter. 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 API Cloud KMS deve eseguire un'operazione crittografica, quindi esegue una query principale insieme ai job di snapshot locale in parallelo. Se datastore primario è lento o non disponibile, la risposta può essere fornita da un snapshot, se non è stato creato più di due ore prima. 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 lo standard meccanismo di chiamata di procedura remota (RPC).

Per ulteriori informazioni, vedi Autenticazione, integrità e crittografia da un servizio all'altro.

Architettura della piattaforma Cloud KMS

In questa sezione vengono descritti i dettagli dell'architettura sicurezza dei materiali delle chiavi e 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.
• Se la chiave interna di Google utilizzata per proteggere il materiale della chiave del cliente viene ruotato o controllato per verificarne l'integrità.

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

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

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) consente di applicare questi criteri a livello operativo.

I job API Cloud KMS possono accedere ai metadati delle chiavi, ad esempio il criterio di autorizzazione periodo di rotazione). Un dipendente Google con un'attività valida e documentata alla giustificazione (come un bug o un problema del cliente) possono accedere anche ai metadati della chiave. Questi eventi di accesso vengono registrati internamente e i log relativi ai dati coperti Trasparenza degli accessi disponibili anche per clienti qualificati.

Il materiale della chiave decriptata non può essere esportato o visualizzato tramite l'interfaccia API o un'altra interfaccia utente. Nessun dipendente Google ha accesso a un cliente non criptato materiale della chiave. Inoltre, il materiale della chiave è criptato con una chiave master in Archivio chiavi, non accessibile direttamente a nessuno. Su un HSM, la chiave non è mai possibile accedere al materiale in stato decriptato dai job dell'API Cloud KMS.

Protezione del datastore

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

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 utilizzando un codice HMAC (Hash-based Message Authentication Code) per garantirne l'autenticazione. che non sia stato alterato o danneggiato quando è inattivo. Ogni ora, un job batch analizza tutte le chiavi materiali e metadati e verifica che gli HMAC siano validi e che la chiave il materiale può decriptare correttamente. 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 di 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 convalidate e utilizzate per il ripristino, se necessario. Questi snapshot vengono conservati quattro giorni.
• Ogni giorno, un backup completo viene copiato su disco e negli archiviazione dei dati ad accesso sporadico.

Il team di Cloud KMS dispone di procedure documentate per ripristinare i backup a mitigare la perdita di dati in caso di emergenza lato servizio.

Backup. I backup del datastore Cloud KMS si trovano regione Google Cloud associata. Questi backup vengono tutti criptati quando sono inattivi. L'accesso ai dati nei backup è limitato in base alle giustificazioni dell'accesso (come un numero del ticket che hai presentato all'Assistenza Google) e che l'accesso da parte di persone fisiche sia connesso Log di Access Transparency.

Protezione. A livello di applicazione Cloud KMS, il materiale della chiave viene criptato prima di essere archiviato. Gli ingegneri con accesso al datastore avere accesso a materiale in chiaro delle chiavi del cliente. Inoltre, il datastore cripta tutti i dati che gestisce prima di scriverli nello spazio di archiviazione permanente. Pertanto, accesso ai livelli di archiviazione sottostanti, inclusi dischi o archiviazione dei dati ad accesso sporadico, non consente l'accesso nemmeno ai dati criptati di Cloud KMS senza 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 Chiavi master dell'archivio chiavi che eseguono il wrapping delle chiavi master di Cloud KMS. Archivio chiavi la chiave master ha una durata massima di 90 giorni del testo crittografato con un client durata massima della chiave memorizzata nella cache di un giorno. Cloud KMS aggiorna il master KMS nelle attività KMS ogni 24 ore e cripta di nuovo tutte le chiavi del cliente base.

Residenza dei dati. I dati sottostanti di ciascun datastore Cloud KMS rimangono esclusivamente nella regione Google Cloud a cui sono associati i dati. Questo si applica anche alle località che hanno più regioni, ad esempio l'us in più regioni.

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 una livello di protezione per determinare quale backend della chiave crea la chiave ed esegue tutte le operazioni future le operazioni crittografiche su quella chiave. I backend sono esposti l'API Cloud KMS con i seguenti livelli di protezione:

• SOFTWARE: si applica alle chiavi che potrebbero essere sottoposte a unwrapping da un software modulo di sicurezza per eseguire operazioni crittografiche.
• HSM: si applica alle chiavi di cui l'unwrapping può essere annullato solo da HSM che eseguono tutte le operazioni crittografiche con le chiavi.
• EXTERNAL o EXTERNAL-VPC: applica al gestore di chiavi esterno (EKM). EXTERNAL-VPC ti consente di connettere l'EKM a Google Cloud tramite un VPC in ogni rete.

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 di Google BoringSSL per tutte le attività crittografiche correlate. Il BCM è Certificato FIPS 140-2. Il programma binario di Cloud KMS viene creato FIPS 140-2 Livello 1: primitive crittografiche convalidate di questo modulo. Il più recente gli algoritmi trattati in questo modulo sono elencati Scopi e algoritmi chiave, e includono operazioni di crittografia, decriptazione e firma con le operazioni simmetriche AES256-GCM Crittografia asimmetrica RSA 2048, RSA 3072, RSA 4096, EC P256 ed EC P384 chiave.

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. In questo modo viene fornito per RAND_bytes, l'interfaccia principale con cui il resto del sistema dati casuali. Questo PRNG ha origine dall'RNG del kernel Linux, che a sua volta deriva da più origini entropiche indipendenti. Questo seeding include l'entropico eventi dall'ambiente del data center, come misurazioni granulari dei ricerche del disco, tempi di arrivo tra pacchetti e Istruzioni RDRAND di Intel ove disponibili. Per ulteriori informazioni sul comportamento del numero casuale, generatore per BoringSSL (modalità conforme a FIPS), consulta Progettazione dell'RNG.

Backend Cloud HSM: livello di protezione HARDWARE

Cloud HSM fornisce chiavi basate su hardware a Cloud KMS. it consente di utilizzare chiavi di crittografia protette certificati HSM certificati FIPS 140-2 di livello 3 nei data center di Google. Cloud HSM è ad alta disponibilità e offre scalabilità elastica, proprio come di Cloud KMS. Non sono necessarie modifiche all'applicazione per gli account esistenti I clienti di Cloud KMS mentre possono accedere al backend di Cloud HSM usando le stesse API e librerie client di Cloud KMS. Per maggiori informazioni informazioni sul backend 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 in tuo controllo.

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

Importazione di una chiave

Potresti voler importare le tue chiavi che hai creato on-premise o in un EKM nel tuo ambiente cloud. Ad esempio, potresti avere una che le chiavi utilizzate per criptare i dati cloud vengano generate in un in un modo specifico o in un ambiente specifico. Importazione chiavi consente di importare queste chiavi e soddisfare gli obblighi normativi. Per estendere le tue le funzionalità di firma sul cloud, puoi anche importare chiavi asimmetriche.

Nell'ambito dell'importazione delle chiavi, Cloud KMS genera una chiave di wrapping pubblica che è 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 trasporto pubblico.

Puoi utilizzare la chiave di wrapping pubblica per criptare la chiave da importare sul client. La chiave privata che corrisponde alla chiave pubblica è archiviata in Google Cloud e viene utilizzato per annullare il wrapping della chiave pubblica dopo che ha raggiunto progetto Google Cloud. Il metodo di importazione scelto determina utilizzato per creare la chiave di wrapping. Una volta che il materiale della chiave con wrapping, puoi importarla 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 all'interno di Cloud HSM. Limitazione della parte della chiave privata a Cloud HSM impedisce a Google di eseguire l'unwrapping del materiale della chiave al di fuori di per la risoluzione dei problemi di Google Cloud HSM.

Chiavi di crittografia gestite dal cliente (CMEK)

Per impostazione predefinita, Google Cloud cripta tutti i dati inattivi dei clienti, con Google che gestisce le chiavi utilizzate per la crittografia. Per alcuni utenti di Google Cloud puoi utilizzare Cloud KMS per gestire le chiavi utilizzate la crittografia. È possibile utilizzare CMEK per chiavi esterne, software e hardware. Cloud KMS consente di controllare molti aspetti delle chiavi (come la creazione, attivazione, disattivazione, rotazione ed eliminazione di chiavi) e gestire le opzioni IAM appropriate le relative autorizzazioni. Per applicare una separazione consigliata dei compiti, Cloud KMS include diversi ruoli IAM predefiniti con privilegi e limitazioni specifici e che possono essere concessi a specifici e account di servizio.

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

Criteri dell'organizzazione CMEK per avere un maggiore controllo sulle modalità di utilizzo di CMEK all'interno dei tuoi progetti. Questi I 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: Integrazioni CMEK per consultare 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, tra cui una discussione sull'eliminazione del materiale delle chiavi. Il seguente diagramma mostra un che richiede l'accesso alle istanze di servizio Cloud KMS in us-east1 e us-west1 e come vengono instradate le richieste tramite Google Front End (GFE).

I passaggi di questo ciclo di vita sono i seguenti:

1. Un cliente, o un job in esecuzione per conto di un cliente, crea un'istanza una richiesta al servizio Cloud KMS, https://cloudkms.googleapis.com. Il DNS risolve questo indirizzo in un indirizzo IP anycast del GFE.
2. GFE fornisce l'hosting IP pubblico del suo nome DNS pubblico, dalla protezione dei servizi (DoS) e dalla terminazione TLS. Quando il cliente invia la loro richiesta, in genere viene indirizzata a un GFE vicino al cliente, indipendentemente da quale località viene indirizzata la richiesta del cliente. GFE gestire la negoziazione TLS e, utilizzando l'URL e i parametri della richiesta, determinare quale Global Software Load Balancer (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 per us-west1, la richiesta viene inoltrata tra us-east1 e us-west1 data center on-premise. Tutte le comunicazioni tra data center sono criptate per il transito con mezzi di terze parti, che autenticano reciprocamente i GFE e dei job Cloud KMS.
4. Quando la richiesta raggiunge il job Cloud KMS, viene prima elaborati da un framework che gestisce gran parte del lavoro comune a tutti servizi Google Cloud. Questo framework autentica l'utente e esegue una serie di controlli per verificare quanto segue:
   • Il cliente dispone di una credenziale valida e può essere autenticato.
   • Nel progetto è abilitata l'API Cloud KMS e dispone di un account di fatturazione valido.
   • La quota è sufficiente per eseguire la richiesta.
   • Il cliente si trova nella lista consentita per utilizzare regione Google Cloud.
   • La richiesta non viene rifiutata dai Controlli di servizio VPC.
5. Una volta superati questi controlli, il framework inoltra la richiesta e la credenziale a Cloud KMS. Cloud KMS analizza la richiesta determinare a quali risorse si accede e poi eseguire i controlli con IAM per vedere se il chiamante è autorizzato a effettuare la richiesta. IAM indica inoltre Cloud KMS indica se l'occorrenza della richiesta deve essere scritta in e gli audit log.
6. Dopo che la richiesta è stata autenticata e autorizzata, 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. Insieme al materiale delle chiavi, Cloud KMS esegue quindi un'operazione crittografica, inoltrando la versione con wrapping della chiave il backend software Cloud KMS, il backend Cloud HSM o il backend Cloud EKM, a seconda del livello di protezione della chiave.
8. Completata l'operazione crittografica, la risposta viene inviata al cliente utilizzando lo stesso tipo di canale GFE-KMS della richiesta.
9. Quando la risposta viene restituita, Cloud KMS attiva anche 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 aggiorna i metadati di una risorsa, la modifica inviati a Cloud Asset Inventory tramite aggiornamenti job batch.

Integrità dei dati end-to-end

Cloud KMS consente di calcolare i checksum per le chiavi e i materiali delle chiavi per assicurarti che non siano danneggiati. Questi checksum ti aiutano a proteggerti Perdita di dati che potrebbe essere causata da danni dell'hardware o del software. Le librerie helper consentono di verificare l'integrità della chiave. Puoi utilizzare le librerie helper l'integrità della chiave fornendo checksum a Cloud KMS, che sono verificati dal server. Inoltre, queste librerie consentono di ricevere checksum 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 trasporto. ad esempio nello stack tra quando i dati quando viene inviato e quando viene protetto da TLS.
• Problemi nei proxy intermedi tra l'endpoint e KMS (ad per le richieste in entrata).
• Operazioni di crittografia errate, danneggiamento della memoria della macchina o danneggiamento dei moduli HSM nell'architettura di Cloud KMS.
• Danneggiamento durante la comunicazione con un EKM esterno.

Per ulteriori informazioni, vedi Verificare l'integrità dei dati end-to-end.

Eliminazione del materiale delle chiavi

I materiali chiave sono considerati dati dei clienti, perciò l'approccio descritto in Eliminazione di dati su Google Cloud si applica anche a Cloud KMS. Il materiale delle chiavi viene eliminato su richiesta, il periodo in cui è prevista l'eliminazione pianificata è terminato e i backup scadono. La chiave ancora presente nei backup (dopo l'eliminazione pianificata periodo è terminato) può essere utilizzato solo per il ripristino di emergenza a livello di regione e non per ripristinare singole chiavi. Questo processo non è garantito per le copie dei file esistenti al di fuori del controllo di Cloud KMS.

Per impostazione predefinita, le chiavi in Cloud KMS trascorrono 30 giorni nel campo Pianificato per distruzione (eliminato temporaneamente) prima che il materiale della chiave eliminato logicamente dal sistema. Puoi modificare questa durata. Per ulteriori informazioni, vedi Durata variabile dello stato Programmata per l'eliminazione.

Sebbene il materiale delle chiavi venga eliminato, le chiavi e i keyring non possono essere eliminati. Legenda non possono essere eliminate, ma il materiale della versione della chiave può essere eliminato che le risorse non possono più essere usate. I keyring e le chiavi non sono fatturabili o limiti di quota, quindi la loro prosecuzione non influisce sui costi o limiti di produzione.

Dopo aver pianificato l'eliminazione della versione della chiave, quest'ultima non viene disponibili per le operazioni crittografiche. Durante il periodo di attesa di eliminazione, può ripristinare la versione della chiave in modo che non venga eliminata.

Se elimini una chiave importata per errore, puoi reimportarla. Per maggiori informazioni le informazioni, vedi Reimportare 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 il parametro Autorizzazione cloudkms.cryptoKeyVersions.destroy.
• Modifica il campo destroy_scheduled_duration impostandolo su un periodo di tempo più lungo.

• Monitora e aggiungi avvisi per gli eventi di eliminazione delle chiavi. Ad esempio, crea il seguente filtro di Cloud Logging:

    resource.type="cloudkms_cryptokeyversion"
    protoPayload.methodName="DestroyCryptoKeyVersion"
  

• Creare processi disabilita la chiave per un paio di giorni prima che la chiave 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 si applica alle funzionalità chiave sia software che hardware.

Tecnici software, SRE e operatori di sistema

Gli ingegneri informatici sono responsabili della collaborazione con altri stakeholder, come in qualità di product manager e tecnici della Site Reliability Engineering (SRE) per progettare il sistema e scrivere gran parte del codice e testare il servizio Cloud KMS. La include il job principale che gestisce le richieste dei clienti, nonché per attività come replica e fatturazione dei dati. Gli SRE potrebbero anche scrivere le API nel tuo codice. Tuttavia, i compiti dei tecnici del software e dell'SRE sono separati; Gli SRE principalmente responsabile della manutenzione dell'ambiente di produzione dei 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 degli operatori di sistema sono definiti nelle procedure operative standard. Gli operatori di sistema non accedono al materiale delle chiavi dei clienti mentre eseguono le loro doveri.

Aree geografiche delle risorse Cloud KMS

Per aiutarti a soddisfare eventuali requisiti di residenza delle chiavi, puoi creare delle risorse Cloud KMS in uno dei quattro tipi Località di Google Cloud:

• Una località in una regione è composta da zone in un'area geografica specifica, ad esempio l'Iowa.
• Una località con due regioni è composta da in due aree geografiche specifiche, ad esempio Iowa e Carolina del Sud.
• Una località multiregionale è composta da dislocati in un'area geografica generale, come gli Stati Uniti.
• La località globale è composta da zone distribuite in tutto il mondo. Quando crei le risorse Cloud KMS nella a livello globale, sono disponibili in 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 saperne di più sulle località Cloud KMS disponibili, consulta Località di Cloud KMS.

Aree geografiche e data center Cloud

Una regione Google Cloud contiene un data center specifico o un insieme specifico di data center, in base alla loro designazione come regione singola, doppia regione in più regioni o globali. Per saperne di più 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 utente richiede l'ingresso con un badge lettori e scanner dell'iride utilizzati per autenticare i partecipanti. Le porte non sono aperto per più persone; ogni persona deve autenticarsi singolarmente. È vietato portare sacchetti all'interno o all'esterno di queste aree, a meno che non si tratti di borse sgouse e esplicitamente autorizzate dopo l'ispezione effettuata il personale addetto alla sicurezza. È necessaria un'autorizzazione speciale per portare all'interno o all'esterno di queste aree qualsiasi dispositivo elettronico che possa trasmettere o registrare dati.

Residenza della chiave

Alcuni settori richiedono che le chiavi crittografiche si trovino in una località specifica. Cloud KMS ha termini relativi alla posizione dei dati con garanzie sulla residenza dei dati. Come illustrato in Aree geografiche delle risorse Cloud KMS, Cloud KMS offre quattro tipi di località regionali per aiutarti a a questi requisiti.

Per località a singola, doppia o più regioni, Cloud KMS crea, archivia ed elabora le chiavi sia software che hardware e il materiale delle chiavi solo in quella posizione. Sistemi di archiviazione ed elaborazione dati utilizzati da Cloud KMS sono configurate per utilizzare solo le risorse all'interno della regione Google Cloud che è associato al materiale della chiave. Materiale della chiave creato in due regioni o località multiregionali non escono dai confini dell'area luoghi.

Per la regione globale, non sono specificate garanzie di regionalità.

Cloud KMS non garantisce la residenza per metadati delle chiavi, log di utilizzo o per il materiale delle chiavi in transito. I metadati della chiave includono i nomi delle risorse; proprietà di le risorse di Cloud KMS, come tipo di chiave, dimensioni e stato della chiave; IAM norme; e qualsiasi dato derivato dai metadati.

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

• Per una regione specifica: poiché la regione di un KMS gestito dal cliente la chiave deve sempre essere correlata alla regione della risorsa che protegge in base al servizio Google Cloud, le limitazioni di residenza per una singola regione le chiavi e le risorse sono garantite che siano compatibili e applicate.
• Per località con due o più regioni: gli utenti possono selezionare Aree multiregionali definite da Google per le loro chiavi e Google Cloud per garantire la conformità della residenza. Per garantire che l'implementazione la residenza, assicurati che le regioni in altri prodotti siano in linea con i tuoi della località regionale di Cloud KMS scelta.

La seguente tabella riassume la residenza del materiale della chiave per di Cloud KMS.

Tipo di regione	At-rest, in uso
Regione singola	Residente
Due regioni o più regioni	Residente nelle regioni che costituiscono il duplice 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ò aiutare a semplificare i requisiti di disponibilità in base a le regioni selezionate. Più dettagliata è la località, più la ridondanza che devi creare. Per applicazioni con livelli la disponibilità, usa località multiregionali anziché provare a creare di replicazione delle chiavi. Devi bilanciare la ridondanza integrata per soddisfare le tue esigenze di regionalizzazione dei dati.

Autenticazione e autorizzazione

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

Cloud KMS utilizza una versione interna dell'ambiente pubblico API Service Control per molti aspetti della gestione dei servizi. Prima che un job Cloud KMS gestisca una richiesta, prima invia una richiesta di controllo all'API Service Control, applica molti controlli comuni a tutti i servizi Google Cloud, come seguenti:

• È in corso la verifica di aver attivato l'API Cloud KMS e di avere un account account di fatturazione.
• Controllo di non aver superato la quota e generazione di report sull'utilizzo della quota.
• Applicazione Controlli di servizio VPC.
• Controllo dell'inclusione nella lista consentita per il cloud privato applicabile in corso... regioni.

Gestione delle quote

Cloud KMS prevede limiti di utilizzo, denominati quote, per le richieste inviate completamente gestito di Google Cloud. Cloud KMS contiene le seguenti quote:

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

Queste quote vengono addebitate al progetto associato al chiamante. Anche queste quote sono globali, il che significa che vengono applicate Utilizzo di KMS in tutte le regioni e in più regioni. Queste quote vengono valutate per tutti i livelli di protezione.

Cloud HSM e Cloud EKM prevedono quote aggiuntive le operazioni crittografiche. Queste quote devono essere soddisfatte in aggiunta al la quota per le richieste crittografiche. 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:

• Per chiamare la decrittografia con una chiave software in asia-northeast1 è necessaria una unità della quota di richieste crittografiche (globali).
• La creazione di una chiave HSM in us-central1 richiede un'unità di richieste di scrittura e nessuna quota HSM.
• La chiamata con crittografia con una chiave EKM in europe richiede un'unità di quota di richieste crittografiche (globale) e un'unità di KMS esterno di richieste di accesso in europe.

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

Logging

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

Cloud Audit Logs

Cloud KMS record la tua attività in Audit log di Cloud. Puoi visualizzare questi log nella console Cloud. Tutte le attività amministrative per esempio la creazione o l'eliminazione di una chiave, viene registrata in questi log. Puoi anche attivare il logging per tutte le altre azioni che utilizzano una chiave, ad esempio l'uso una chiave per criptare o decriptare i dati. Sei tu a decidere per quanto tempo conservare i log e chi li può visualizzare.

Log di trasparenza degli accessi

I clienti idonei possono scegliere di attivare Trasparenza degli accessi log delle azioni che i dipendenti Google eseguono nei tuoi dell'organizzazione Google Cloud. I log di Access Transparency, insieme ai log da Cloud Audit Logs, può aiutarti a rispondere a domande su chi ha fatto cosa, dove e quando.

Puoi integrare i log di Access Transparency con i dati di sicurezza esistenti strumenti di gestione delle informazioni e degli eventi (SIEM) per automatizzare il controllo di questi azioni. Questi log sono disponibili nella console Cloud insieme al tuo 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.
• La motivi per l'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, il personale Google la località del membro).

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 API metodo o protocollo) e la risorsa a cui si accede (ad esempio nome, chiave algoritmo o livello di protezione della chiave). Questi log non memorizzano il testo non crittografato dei clienti, testo crittografato o materiale delle chiavi. Prima di aggiungere nuovi tipi di dati a questi log, viene eseguita una un team specializzato in revisioni della privacy deve approvare le modifiche ai dati dei dati nel log.

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, l'accesso umano è registrato ed è accessibile a clienti idonei nei Log di Access Transparency.

Monitoraggio

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

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

Passaggi successivi

• Per saperne di più su Cloud KMS, esplora le seguenti risorse:
  • Documentazione di Cloud KMS
  • Documentazione di Cloud HSM
• Per informazioni sull'utilizzo delle tue chiavi di crittografia in per Google Cloud, consulta Chiavi di crittografia gestite dal cliente (CMEK).
• Scopri in che modo Google si sta preparando a un mondo post-quantistico.
• Per scoprire di più sulla sicurezza dell'infrastruttura Google, vedi Panoramica sulla progettazione della sicurezza dell'infrastruttura Google.
• Per informazioni generali sulla sicurezza di Google Cloud, consulta la sezione sulla sicurezza del sito web di Google Cloud.