Configurare la crittografia dei messaggi

Per impostazione predefinita, Pub/Sub cripta i contenuti inattivi dei clienti at rest. Pub/Sub gestisce la crittografia senza che tu debba eseguire ulteriori azioni. Questa opzione è denominata crittografia predefinita di Google.

Se vuoi controllare le chiavi di crittografia, puoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK) in Cloud KMS con i servizi integrati con CMEK, incluso Pub/Sub. L'utilizzo delle chiavi Cloud KMS ti consente di controllare il livello di protezione , la località, la pianificazione della rotazione, le autorizzazioni di utilizzo e di accesso e i limiti crittografici. Con Cloud KMS puoi inoltre visualizzare gli audit log e controllare i cicli di vita delle chiavi. Invece di Google, sei tu ad avere la proprietà e la gestione delle chiavi di crittografia della chiave (KEK) simmetriche che proteggono i tuoi dati. Puoi controllare e gestire queste chiavi in Cloud KMS.

Dopo aver configurato le risorse con le CMEK, l'esperienza di accesso alle risorse Pub/Sub è simile a quella della crittografia predefinita di Google. Per saperne di più sulle opzioni di crittografia, consulta Chiavi di crittografia gestite dal cliente (CMEK).

Come funziona CMEK con Pub/Sub

Quando configuri Pub/Sub con CMEK, il servizio cripta automaticamente tutti i dati utilizzando la chiave specificata. L'utilizzo di Cloud KMS per CMEK potrebbe comportare costi aggiuntivi a seconda dei pattern di utilizzo.

Ogni messaggio viene criptato nei seguenti stati e livelli:

  • A riposo

    • Livello hardware
    • Livello dell'infrastruttura
    • Livello di applicazione
  • In transito

A livello di applicazione, Pub/Sub cripta singolarmente i messaggi in entrata non appena vengono ricevuti. Questa implementazione aggiunge le seguenti funzionalità:

Pattern di crittografia envelope

Pub/Sub utilizza il pattern di crittografia envelope con CMEK. Con questo approccio, i messaggi non vengono criptati da Cloud KMS. Cloud KMS viene invece utilizzato per criptare le chiavi di crittografia dei dati (DEK) create da Pub/Sub per ogni argomento. Queste DEK vengono archiviate solo in formato criptato o wrapped da Pub/Sub. Prima di archiviare una DEK, il servizio la invia a Cloud KMS per criptarla con la chiave di crittografia della chiave (KEK) specificata nell'argomento. Viene generata una nuova DEK per ogni argomento all'incirca ogni sei ore.

Prima che Pub/Sub pubblichi i messaggi in una sottoscrizione, li cripta utilizzando la DEK più recente generata per l'argomento. Pub/Sub decripta i messaggi poco prima che vengano consegnati ai sottoscrittori.

Configurare CMEK con Pub/Sub

Puoi configurare CMEK manualmente o utilizzando Autokey.

Prima di iniziare

Puoi configurare CMEK per Pub/Sub utilizzando la Cloud de Confiance console o Google Cloud CLI.

Completa le seguenti attività:

  • Abilita l'API Cloud KMS.

  • Crea un keyring e una chiave in Cloud KMS. Le chiavi e i keyring non possono essere eliminati.

Per istruzioni su come eseguire queste attività, consulta Creare un key ring e Creare una chiave.

Ruoli e autorizzazioni richiesti

Pub/Sub utilizza un Cloud de Confiance agente di servizio per accedere a Cloud KMS. L'agente di servizio viene gestito internamente da Pub/Sub per ogni progetto e non è visibile per impostazione predefinita nella pagina Service account della Cloud de Confiance console.

Il service agent Pub/Sub ha il formato service-${PROJECT_NUMBER}@gcp-sa-pubsub.s3ns-system.iam.gserviceaccount.com.

Pub/Sub richiede autorizzazioni specifiche per criptare e decriptare i dati utilizzando CMEK.

Completa i seguenti passaggi per configurare l'accesso richiesto:

  • Concedi al service agent Pub/Sub il ruolo Autore crittografia/decrittografia CryptoKey Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter).

    gcloud kms keys add-iam-policy-binding CLOUD_KMS_KEY_NAME \
        --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-pubsub.s3ns-system.iam.gserviceaccount.com \
        --role=roles/cloudkms.cryptoKeyEncrypterDecrypter
    

    Sostituisci quanto segue:

    • CLOUD_KMS_KEY_NAME: il nome della chiave Cloud KMS.

      La chiave ha il formato projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/CRYPTO_KEY.

      Un esempio è projects/test-project/locations/us-central1/keyRings/test-keyring/cryptoKeys/test-key.

    • PROJECT_NUMBER: il numero di progetto del progetto Pub/Sub.

Per saperne di più sulla concessione dei ruoli Identity and Access Management, consulta Concedere ruoli a una risorsa.

Configurare manualmente un argomento con CMEK

Puoi configurare manualmente CMEK per un argomento utilizzando la Cloud de Confiance console o gcloud CLI.

Console

Per creare un argomento con CMEK, segui questi passaggi:

  1. Nella Cloud de Confiance console, vai alla pagina Argomenti di Pub/Sub.

    Vai ad Argomenti

  2. Fai clic su Crea argomento.

  3. Nel campo ID argomento, inserisci un ID per l'argomento.

    Per saperne di più sulla denominazione degli argomenti, consulta le linee guida per la denominazione.

  4. Per Crittografia, fai clic su Chiave Cloud KMS.

  5. Seleziona il tipo di chiave. Se non vedi il menu a discesa Seleziona una chiave gestita dal cliente, assicurati di aver abilitato l'API Cloud KMS per il progetto.

  6. Fai clic su Crea argomento.

gcloud

Per creare un argomento con CMEK, esegui il gcloud pubsub topics create comando:

    gcloud pubsub topics create TOPIC_ID --topic-encryption-key=ENCRYPTION_KEY
    

Sostituisci quanto segue:

Aggiornare manualmente un argomento CMEK

Puoi aggiungere, modificare o rimuovere la CMEK collegata a un argomento Pub/Sub. Puoi utilizzare gcloud CLI per aggiornare la CMEK. Tuttavia, questa modifica non viene applicata in modo retroattivo.

I messaggi pubblicati nell'argomento prima delle modifiche della chiave rimangono criptati con la chiave originale, indipendentemente dal fatto che si tratti di una CMEK o Google Cloud-powered encryption key. La modifica della CMEK di un argomento non cripta nuovamente i messaggi pubblicati in precedenza. Questi messaggi rimangono protetti con la chiave con cui sono stati criptati originariamente, pertanto i dati dei messaggi all'interno di un argomento potrebbero comunque dipendere dalla chiave precedente per un massimo di 31 giorni, a seconda della durata di conservazione dei messaggi specificata nell'argomento o in una delle relative sottoscrizioni.

Pub/Sub ha un meccanismo di memorizzazione nella cache delle chiavi che dura circa 30 minuti. Potrebbe essere necessario questo periodo di tempo prima che Pub/Sub riconosca e inizi a utilizzare una nuova chiave modificata manualmente nella configurazione dell'argomento.

Rotazione della chiave Cloud KMS in Pub/Sub

Le modifiche alla configurazione delle chiavi, come rotazione della chiave in Cloud KMS, non attivano direttamente la creazione di chiavi di crittografia dei dati in Pub/Sub. Potrebbero essere necessarie fino a 12 ore prima che Pub/Sub inizi a utilizzare le nuove versioni delle chiavi per criptare i dati dei messaggi.

Come per le modifiche manuali alla configurazione delle impostazioni di crittografia in Pub/Sub, queste modifiche non vengono applicate in modo retroattivo ai messaggi pubblicati in precedenza. I messaggi esistenti continuano a essere protetti con le versioni precedenti della chiave di crittografia. Questi messaggi rimangono protetti con la chiave con cui sono stati criptati originariamente, pertanto i dati dei messaggi all'interno di un argomento potrebbero comunque dipendere dalla versione della chiave precedente per un massimo di 31 giorni, a seconda della durata di conservazione dei messaggi specificata nell'argomento o in una delle relative sottoscrizioni.

Configurare un argomento con Cloud KMS Autokey

Per saperne di più sull'utilizzo di Cloud KMS Autokey con Pub/Sub, consulta Cloud KMS con Autokey.

Audit log

Cloud KMS genera audit log quando le chiavi vengono abilitate, disabilitate o utilizzate da Pub/Sub per criptare e decriptare i messaggi. È utile per il debug dei problemi relativi alla disponibilità di pubblicazione o consegna.

Le chiavi Cloud KMS sono collegate agli audit log per le risorse degli argomenti Pub/Sub. Pub/Sub non include altre informazioni relative a Cloud KMS.

Monitoraggio e risoluzione dei problemi

I problemi di accesso alle chiavi possono avere i seguenti effetti:

  • Ritardi nella consegna dei messaggi

  • Errori di pubblicazione

Monitora gli errori di pubblicazione e delle richieste di pull utilizzando le seguenti metriche, raggruppate per response_class e response_code:

  • topic/send_request_count
  • subscription/pull_request_count
  • subscription/streaming_pull_response_count

La risposta StreamingPull ha una percentuale di errore del 100% . Ciò indica che lo stream è terminato, non che le richieste non sono riuscite. Per monitorare StreamingPull, cerca il codice di risposta FAILED_PRECONDITION.

La pubblicazione e la consegna dei messaggi possono non riuscire con errori FAILED_PRECONDITION per diversi motivi.

Per le sottoscrizioni push, non è possibile rilevare direttamente i problemi di consegna specifici di CMEK. Invece:

  • Monitora le dimensioni e l'età del backlog di una sottoscrizione push utilizzando subscription/num_unacked_messages.

  • Monitora subscription/oldest_unacked_message_age per eventuali picchi insoliti.

  • Utilizza gli errori di pubblicazione e gli audit log CMEK per individuare i problemi.

Disabilitare e riabilitare le chiavi

Esistono due modi per impedire a Pub/Sub di decriptare i dati dei messaggi:

  • Consigliato: Disabilita la chiave Cloud KMS che hai associato all'argomento utilizzando Pub/Sub. Questo approccio interessa solo gli argomenti e le sottoscrizioni Pub/Sub associati a quella chiave specifica.

  • Revoca il ruolo Autore crittografia/decrittografia CryptoKey Pub/Sub dal account di servizio Pub/Sub (service-$PROJECT_NUMBER@gcp-sa-pubsub.s3ns-system.iam.gserviceaccount.com) utilizzando IAM. Questo approccio interessa tutti gli argomenti Pub/Sub del progetto e le sottoscrizioni che contengono messaggi criptati utilizzando CMEK.

Sebbene nessuna delle due operazioni confermi la revoca immediata dell'accesso, in genere le modifiche IAM vengono propagate più rapidamente. Per saperne di più, consulta Coerenza delle risorse Cloud KMS e Propagazione della modifica di accesso.

Quando Pub/Sub non riesce ad accedere a una chiave Cloud KMS, la pubblicazione e la consegna dei messaggi con StreamingPull o pull non riesce con errori FAILED_PRECONDITION. La consegna dei messaggi agli endpoint push verrà interrotta. Per riprendere la consegna e la pubblicazione, ripristina l'accesso alla chiave Cloud KMS.

Una volta che la chiave Cloud KMS è accessibile a Pub/Sub, la pubblicazione è disponibile entro 12 ore e la consegna dei messaggi riprende entro 2 ore.

Sebbene sia improbabile che interruzioni intermittenti di Cloud KMS di durata inferiore a un minuto interrompano in modo significativo la pubblicazione e la consegna, la mancata disponibilità prolungata di Cloud KMS ha lo stesso effetto della revoca della chiave.