Best practice per Cloud HSM per Google Workspace

Questo documento descrive le best practice per configurare Cloud HSM per Google Workspace per proteggere il materiale delle chiavi da distruzione ed eliminazione accidentali o non autorizzate, garantire alta disponibilità e durabilità per le chiavi crittografiche critiche e soddisfare i requisiti normativi e di conformità.

Questo documento è destinato agli architetti cloud, ai team di sicurezza e agli amministratori di Google Workspace responsabili della sicurezza e della resilienza operativa delle chiavi di crittografia utilizzate nella crittografia lato client (CSE) per Google Workspace. Presuppone che tu abbia già familiarità con Cloud HSM per Google Workspace e che tu abbia completato la procedura di onboarding.

Mitigare la perdita di materiale delle chiavi

I rischi per la sicurezza possono sorgere quando un'entità ha un ruolo che concede l'autorizzazione a completare azioni distruttive, soprattutto quelle al di fuori del normale ambito di lavoro dell'entità. Ad esempio, un utente con un ruolo Proprietario progetto (roles/owner) eccessivamente ampio potrebbe distruggere il materiale della chiave utilizzato per la crittografia lato client di Google Workspace, rendendo i dati criptati inaccessibili in modo permanente.

Le sezioni seguenti descrivono le pratiche che contribuiscono a mitigare il rischio di distruzione ed eliminazione accidentale e dannosa delle chiavi rimuovendo le autorizzazioni per distruggere o eliminare il materiale delle chiavi Cloud KMS utilizzato dalla crittografia lato client (CSE) di Google Workspace e limitando la distruzione delle chiavi.

Applica i criteri di negazione IAM a livello di cartella

Le policy di negazione IAM consentono di negare le autorizzazioni alle entità, anche se l'autorizzazione viene altrimenti concessa da un ruolo detenuto dall'entità. Ad esempio, anche se un utente ha il ruolo Proprietario progetto (roles/owner), una policy di negazione IAM a livello di cartella può impedirgli di distruggere o eliminare le chiavi. Se inserisci il progetto Cloud HSM in una cartella e applichi un criterio di negazione a livello di cartella, crei una protezione che impedisce la distruzione e l'eliminazione delle chiavi durante l'applicazione del criterio. I criteri di negazione applicati non possono essere annullati senza un ruolo come Amministratore di negazione (roles/iam.denyAdmin) nella cartella.

Assicurati che i ruoli di amministrazione delle cartelle come Amministratore cartelle (roles/resourcemanager.folderAdmin) e Deny Admin (roles/iam.denyAdmin) vengano concessi solo alle entità che non dispongono anche del ruolo Cloud KMS Admin (roles/cloudkms.admin) nel progetto in cui si trovano le chiavi Cloud HSM. Questa separazione dei compiti garantisce che nessun singolo principal possa gestire ed eliminare le chiavi.

Imposta una policy di negazione in base alla seguente configurazione di esempio:

displayName: Deny KMS key destruction and deletion
rules:
- description: "Denies destroy and delete permissions on Cloud KMS keys for all principals."
  denyRule:
    deniedPrincipals:
    - "principalSet://goog/public:all"
    deniedPermissions:
    - "cloudkms.googleapis.com/cryptoKeyVersions.destroy"
    - "cloudkms.googleapis.com/cryptoKeys.delete"

Per saperne di più sui criteri di negazione IAM, consulta la Panoramica dei criteri di negazione IAM.

Applica i vincoli dei criteri dell'organizzazione per l'eliminazione delle chiavi

Oltre a IAM, puoi applicare misure di salvaguardia della sicurezza a livello di organizzazione o cartella utilizzando i vincoli dei criteri dell'organizzazione. Questi vincoli fungono da requisiti rigidi che limitano i tipi di risorse che possono essere create e il modo in cui possono essere configurate. I vincoli dei criteri dell'organizzazione applicati non possono essere aggirati, nemmeno dai principal che dispongono delle autorizzazioni richieste per completare l'azione vietata. I vincoli dei criteri dell'organizzazione applicati forzatamente non possono essere annullati senza un ruolo come Amministratore criteri organizzazione (roles/orgpolicy.policyAdmin) nell'organizzazione.

  • Durata minima di eliminazione (constraints/cloudkms.minimumDestroyScheduledDuration): impone una durata minima pianificata per l'eliminazione (ad esempio, 90 o 120 giorni) per tutte le chiavi dell'organizzazione o della risorsa in cui è attivata la norma. Questo vincolo impedisce a qualsiasi utente di ridurre la finestra di recupero al di sotto del valore minimo configurato.
  • Disabilita prima dell'eliminazione (constraints/cloudkms.disableBeforeDestroy): richiede che una versione della chiave sia in stato DISABLED prima di poter essere pianificata per l'eliminazione. Questo vincolo aggiunge un passaggio obbligatorio al workflow di eliminazione, aumentando la visibilità dell'azione nei log di controllo.

Per saperne di più, consulta Controllare l'eliminazione della versione della chiave.

Ingrandisci la finestra di distruzione delle chiavi

Quando una versione della chiave viene pianificata per l'eliminazione, entra in un periodo di "eliminazione temporanea". Mentre una versione della chiave è in stato pianificata per l'eliminazione, puoi ripristinare la chiave per annullare l'eliminazione. L'impostazione di questo periodo configurabile alla durata massima di 120 giorni contribuisce a garantire di avere tempo sufficiente per ripristinare una versione della chiave che è stata pianificata per la distruzione per errore o in modo dannoso. Puoi impostare questo valore solo quando crei la chiave.

Quando ripristini una versione della chiave la cui eliminazione era pianificata, lo stato della versione della chiave viene impostato su DISABLED. Dopodiché, devi riattivare la versione della chiave per ripristinare l'accesso ai tuoi dati di Google Workspace criptati.

Il seguente comando gcloud CLI crea una chiave supportata da HSM con una durata di eliminazione pianificata di 120 giorni:

gcloud kms keys create KEY_NAME \
    --location LOCATION \
    --keyring KEY_RING \
    --purpose encryption \
    --protection-level hsm \
    --destroy-scheduled-duration 120d

Sostituisci quanto segue:

  • KEY_NAME: il nome della chiave.
  • LOCATION: la posizione di Cloud KMS delle chiavi automatizzate.
  • KEY_RING: il nome delle chiavi automatizzate che contengono la chiave.

Per applicare questa durata a tutte le chiavi della tua organizzazione anziché impostarla su ogni chiave, puoi definire e applicare un vincolo personalizzato della policy dell'organizzazione. Il seguente vincolo di esempio consente agli utenti di creare una chiave solo se la durata pianificata dell'eliminazione è compresa tra 90 e 120 giorni:

name: organizations/ORGANIZATION_ID/customConstraints/custom.limitScheduledDestruction
resourceTypes:
- cloudkms.googleapis.com/CryptoKey
methodTypes:
- CREATE
condition: "resource.destroyScheduledDuration >= duration('7776000s') && resource.destroyScheduledDuration <= duration('10368000s')"
actionType: ALLOW
displayName: Require scheduled destruction duration between 90 and 120 days
description: Allows key creation only if the destroyScheduledDuration is between 90 and 120 days.

Sostituisci ORGANIZATION_ID con l'ID numerico della tua organizzazione.

Per ulteriori informazioni sulla configurazione della durata dell'eliminazione pianificata, vedi Eliminare e ripristinare le versioni delle chiavi. Per saperne di più sull'utilizzo di vincoli delle policy dell'organizzazione personalizzati con Cloud KMS, consulta Creare vincoli delle policy dell'organizzazione personalizzati per Cloud KMS.

Proteggere l'infrastruttura e il progetto

Le misure di protezione descritte in precedenza in questo documento si concentrano sulla prevenzione della distruzione e dell'eliminazione delle chiavi. Tuttavia, hai bisogno anche di misure di salvaguardia per impedire l'eliminazione del progetto chiave. Utilizza le seguenti misure di protezione per proteggere l'ambiente del progetto che ospita le chiavi Google Workspace.

Applica i blocchi di progetto

Un blocco del progetto impedisce l'eliminazione di un progetto. Anche un utente con il ruolo Proprietario progetto (roles/owner) non può chiudere il progetto mentre è attivo un vincolo. Questo è il modo più efficace per impedire l'eliminazione accidentale o non autorizzata del progetto in cui si trovano le chiavi Google Workspace.

Per saperne di più sui blocchi di progetto, consulta Proteggere i progetti con blocchi.

Informazioni sulla finestra di recupero del progetto

Se un progetto viene eliminato correttamente, ad esempio dopo la rimozione di un blocco del progetto (anteprima), entra nel periodo di recupero di 30 giorni. Durante questo periodo, un utente con il ruolo Proprietario progetto (roles/owner) o Amministratore organizzazione (roles/resourcemanager.organizationAdmin) può ripristinare il progetto. Dopo 30 giorni, il progetto e tutte le relative chiavi vengono eliminati definitivamente.

Ti consigliamo di mantenere i privilegi sul progetto e di fare affidamento sulla finestra di recupero solo come ultima risorsa.

Per saperne di più sul recupero dei progetti, vedi Ripristinare un progetto eliminato.

Utilizza i Controlli di servizio VPC

I Controlli di servizio VPC ti consentono di definire un perimetro di sicurezza intorno al tuo progetto Cloud HSM. In questo modo, l'API Cloud KMS può essere accessibile solo da reti attendibili o identità specifiche, riducendo il rischio di azioni amministrative non autorizzate al di fuori dell'ambiente aziendale.

Garantire la sovranità del materiale chiave con le chiavi importate (BYOK)

Per la maggior parte delle organizzazioni, consigliamo di lasciare che Cloud HSM generi e gestisca il materiale della chiave.

Tuttavia, se hai bisogno delle funzionalità "Bring Your Own Key (BYOK)", puoi generare il materiale della chiave on-premise e importarlo in Cloud HSM. Questo approccio BYOK ti consente di soddisfare requisiti quali il mantenimento di una copia indipendente e on-premise del materiale delle chiavi, ad esempio per soddisfare i mandati di sovranità dei dati o per eseguire il ripristino in caso di perdita catastrofica del materiale delle chiavi. Questo approccio ti offre una copia indipendente del materiale della chiave che puoi reimportare se la versione della chiave in Cloud KMS viene eliminata.

Reimporta nella stessa versione

Cloud KMS consente di reimportare materiale della chiave identico nella versione della chiave eliminata, in modo che l'identificatore e l'URI della risorsa siano gli stessi della versione della chiave importata originale. In questo modo puoi continuare a utilizzare le stesse configurazioni di Google Workspace. Quando reimporti una versione della chiave utilizzata in una configurazione di Google Workspace, l'accesso ai dati viene ripristinato non appena l'importazione della versione della chiave viene completata.

Per saperne di più sul reimportazione di una versione della chiave eliminata, vedi Reimportazione di una versione della chiave eliminata.

Protezione avanzata con Cloud HSM single-tenant

Per i clienti che richiedono il massimo livello di isolamento, Cloud HSM single-tenant fornisce partizioni HSM dedicate. L'istanza Single-tenant Cloud HSM viene creata e gestita utilizzando l'autenticazione quorum, che richiede l'approvazione di un numero minimo configurato di membri del quorum prima di operazioni critiche, come l'eliminazione dell'istanza Single-tenant Cloud HSM. In questo modo, un singolo account compromesso non potrà distruggere l'istanza Cloud HSM a tenant singolo. Le seguenti pratiche si applicano quando utilizzi Cloud HSM single-tenant. Per saperne di più, consulta Autenticazione basata sul quorum.

Infrastruttura e chiavi separate tra i progetti

Crea l'istanza Single-tenant Cloud HSM e le chiavi Google Workspace in progetti separati. La separazione dei progetti di risorse contribuisce a garantire che un utente con ruoli amministrativi nel progetto di chiavi non abbia autorità sull'istanza Cloud HSM single-tenant sottostante. Questa separazione dei compiti tra la gestione dell'infrastruttura e la gestione delle chiavi riduce il rischio di azioni non autorizzate a livello di infrastruttura.

Per saperne di più su Cloud HSM a tenant singolo, consulta Panoramica di Cloud HSM a tenant singolo.

Riepilogo delle best practice

La tabella seguente riassume le best practice consigliate in questo documento:

Argomento Attività
Criteri di negazione IAM Applica criteri di negazione a livello di cartella per bloccare la distruzione e l'eliminazione delle chiavi, anche per gli utenti con privilegi elevati.
Vincoli delle policy dell'organizzazione Applica vincoli per imporre un periodo di recupero minimo e richiedere che le chiavi vengano disattivate prima di poter essere distrutte.
Periodo di eliminazione pianificata
  • Crea la chiave con il valore Pianificata per l'eliminazione impostato sul massimo di 120 giorni. In alternativa, puoi scegliere una durata più breve, ma assicurati che sia sufficiente a garantire il recupero delle chiavi se ne è prevista l'eliminazione.
  • Puoi utilizzare un vincolo dei criteri dell'organizzazione personalizzato per assicurarti che tutte le chiavi vengano create con una durata appropriata per le tue esigenze.
Privilegi sul progetto Applica i blocchi del progetto per impedire l'eliminazione del progetto che contiene le chiavi di crittografia.
Perimetro dei controlli di servizio VPC Definisci un perimetro dei Controlli di servizio VPC per limitare l'accesso all'API Cloud KMS a reti e identità attendibili.
Reimportazione di BYOK Genera materiale della chiave on-premise e utilizza la reimportazione per recuperare le versioni della chiave eliminate senza modificare i nomi delle risorse.
Architettura tra progetti Se utilizzi Cloud HSM a tenant singolo, separa l'istanza e le chiavi di Cloud HSM a tenant singolo in progetti diversi per applicare la separazione dei compiti.

Passaggi successivi