Decidere la sicurezza per la tua zona di destinazione Google Cloud

Last reviewed 2023-08-31 UTC

Questo documento introduce importanti decisioni in materia di sicurezza e le opzioni consigliate da considerare durante la progettazione di una zona di destinazione di Google Cloud. Fa parte della serie sulle zone di destinazione ed è rivolto a specialisti della sicurezza, CISO e architetti che vogliono comprendere le decisioni che devono prendere quando si progetta una zona di destinazione in Google Cloud.

In questo documento si presume che un team centrale, come il team di sicurezza o quello della piattaforma, applichi i controlli di sicurezza della zona di destinazione. Poiché l'obiettivo di questo documento è la progettazione di ambienti di scala aziendale, alcune strategie descritte nel documento potrebbero essere meno pertinenti per i team di piccole dimensioni.

Punti decisionali per proteggere la tua zona di destinazione di Google Cloud

Per scegliere il design migliore per la sicurezza della tua organizzazione, devi prendere le seguenti decisioni:

Diagramma dell'architettura

L'architettura di esempio descritta in questo documento utilizza pattern di progettazione di sicurezza comuni. I controlli specifici possono variare in base a fattori quali il settore della tua organizzazione, i carichi di lavoro target o i requisiti di conformità aggiuntivi. Il seguente diagramma mostra l'architettura dei controlli di sicurezza che applichi nella zona di destinazione quando segui i suggerimenti in questo documento.

Esempio di architettura dei controlli di sicurezza.

Il diagramma precedente mostra quanto segue:

  • La gestione delle chiavi degli account di servizio aiuta a mitigare il rischio derivante dalle credenziali degli account di servizio di lunga durata.
  • Controlli di servizio VPC definisce un perimetro intorno alle risorse sensibili che consente di limitare l'accesso dall'esterno del perimetro.
  • Security Command Center monitora l'ambiente per individuare configurazioni non sicure e minacce.
  • Un sink di log centralizzato raccoglie gli audit log di tutti i progetti.
  • La crittografia at-rest predefinita di Google cripta tutti i dati persistenti sul disco.
  • La crittografia predefinita di Google in transito si applica ai percorsi di rete di livello 3 e 4.
  • Access Transparency ti offre visibilità e controllo sul modo in cui Google può accedere al tuo ambiente.

Decidi come limitare le credenziali permanenti per gli account di servizio

Gli account di servizio sono identità macchina che utilizzi per concedere ruoli IAM ai carichi di lavoro e consentire al carico di lavoro di accedere alle API Google Cloud. Una chiave dell'account di servizio è una credenziale permanente. Le credenziali permanenti sono potenzialmente ad alto rischio. Sconsigliamo di consentire agli sviluppatori di creare chiavi degli account di servizio liberamente.

Ad esempio, se uno sviluppatore esegue accidentalmente il commit della chiave dell'account di servizio in un repository Git pubblico, un utente malintenzionato esterno può eseguire l'autenticazione utilizzando queste credenziali. Per fare un altro esempio, se la chiave dell'account di servizio viene archiviata in un repository interno, un utente malintenzionato interno che può leggere la chiave potrebbe utilizzare le credenziali per aumentare i propri privilegi di Google Cloud.

Per definire una strategia per la gestione di queste credenziali permanenti, devi fornire alternative valide, limitare la proliferazione di credenziali permanenti e gestire il modo in cui vengono utilizzate. Per informazioni sulle alternative alle chiavi degli account di servizio, vedi Scegliere il metodo di autenticazione migliore per il proprio caso d'uso.

Le sezioni seguenti descrivono le opzioni per limitare le credenziali permanenti. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. Le altre opzioni descritte nelle sezioni seguenti sono alternative che puoi prendere in considerazione se l'opzione 1 non si applica alla tua organizzazione specifica.

Opzione 1: limita l'utilizzo delle chiavi degli account di servizio permanenti

Consigliamo di non consentire agli utenti di scaricare le chiavi degli account di servizio, poiché le chiavi esposte sono un comune vettore di attacco. La limitazione dell'uso di chiavi degli account di servizio permanenti è un'opzione che può aiutare a ridurre il rischio e l'overhead associato alla gestione manuale delle chiavi degli account di servizio.

Per implementare questa opzione, considera quanto segue:

Evita questa opzione se disponi già di strumenti per generare credenziali API di breve durata per gli account di servizio.

Per ulteriori informazioni, consulta le seguenti risorse:

Opzione 2: utilizza strumenti di gestione degli accessi aggiuntivi per generare credenziali di breve durata

In alternativa alla limitazione dell'utilizzo delle chiavi degli account di servizio permanenti, puoi generare credenziali di breve durata per gli account di servizio. Le credenziali di breve durata creano meno rischi rispetto alle credenziali permanenti, come le chiavi degli account di servizio. Puoi sviluppare i tuoi strumenti o utilizzare soluzioni di terze parti come Hashicorp Vault per generare credenziali di accesso di breve durata.

Utilizza questa opzione se hai già investito in uno strumento di terze parti per generare credenziali di breve durata per controllo dell'accesso o se disponi di budget e capacità sufficienti per sviluppare la tua soluzione.

Evita di utilizzare questa opzione se non disponi di strumenti esistenti per concedere credenziali di breve durata o se non hai la capacità di creare una soluzione personalizzata.

Per maggiori informazioni, consulta Creazione di credenziali dell'account di servizio di breve durata.

Decidere come mitigare l'esfiltrazione di dati tramite le API di Google

Le API di Google dispongono di endpoint pubblici disponibili per tutti i clienti. Sebbene ogni risorsa API nel tuo ambiente Google Cloud sia soggetta a controlli di accesso IAM, c'è il rischio che i dati possano essere accessibili utilizzando credenziali rubate, esfiltrati da utenti malintenzionati interni al dominio o codice compromesso oppure esposti tramite un criterio IAM configurato in modo errato.

Controlli di servizio VPC è una soluzione che risolve questi rischi. Tuttavia, i Controlli di servizio VPC introducono anche complessità nel modello di accesso, per cui è necessario progettare Controlli di servizio VPC per soddisfare le esigenze dell'ambiente e del caso d'uso specifici.

Le seguenti sezioni descrivono le opzioni per mitigare l'esfiltrazione di dati tramite le API di Google. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. Le altre opzioni esaminate nelle sezioni seguenti sono alternative che puoi prendere in considerazione se l'opzione 1 non si applica al tuo caso d'uso specifico.

Opzione 1: configura i Controlli di servizio VPC in modo ampio nel tuo ambiente

Ti consigliamo di progettare l'ambiente all'interno di uno o più perimetri Controlli di servizio VPC che limitano tutte le API supportate. Configurare le eccezioni al perimetro con livelli di accesso o criteri in entrata in modo che gli sviluppatori possano accedere ai servizi di cui hanno bisogno, incluso l'accesso alla console, ove necessario.

Utilizza questa opzione quando si verifica quanto segue:

  • I servizi che intendi utilizzare supportano Controlli di servizio VPC e i carichi di lavoro non richiedono l'accesso a internet senza restrizioni.
  • Archiviamo dati sensibili in Google Cloud che potrebbero rappresentare una perdita significativa se esfiltrati.
  • Disponi di attributi coerenti per l'accesso degli sviluppatori che possono essere configurati come eccezioni al perimetro, consentendo agli utenti di accedere ai dati di cui hanno bisogno.

Evita questa opzione quando i carichi di lavoro richiedono accesso a internet senza restrizioni o servizi non supportati dai Controlli di servizio VPC.

Per ulteriori informazioni, consulta le seguenti risorse:

Opzione 2: configura i Controlli di servizio VPC per un sottoinsieme del tuo ambiente

Anziché configurare i Controlli di servizio VPC in modo ampio nel tuo ambiente, puoi configurarli solo nel sottoinsieme di progetti che contengono dati sensibili e carichi di lavoro solo interni. Questa opzione ti consente di utilizzare una progettazione e un'operazione più semplici per la maggior parte dei progetti, dando al contempo la priorità alla protezione dei dati per i progetti con dati sensibili.

Ad esempio, puoi prendere in considerazione questa alternativa quando un numero limitato di progetti contiene set di dati BigQuery con dati sensibili. Puoi definire un perimetro di servizio attorno a questi progetti e definire regole in entrata e in uscita per consentire eccezioni limitate per gli analisti che devono utilizzare questi set di dati.

Per un altro esempio, in un'applicazione con architettura a tre livelli, alcuni componenti potrebbero trovarsi al di fuori del perimetro. Il livello di presentazione che consente il traffico in entrata dal traffico degli utenti potrebbe essere un progetto esterno al perimetro, mentre il livello di applicazione e il livello dati che contengono dati sensibili potrebbero essere progetti separati all'interno del perimetro di servizio. Devi definire le regole di traffico in entrata e in uscita verso il perimetro, in modo che i livelli possano comunicare attraverso il perimetro con accesso granulare.

Utilizza questa opzione quando si verifica quanto segue:

  • Solo i progetti limitati e ben definiti contengono dati sensibili. Altri progetti contengono dati a rischio inferiore.
  • Alcuni carichi di lavoro sono solo interni, ma richiedono l'accesso a internet pubblico o hanno dipendenze su servizi che non sono supportati da Controlli di servizio VPC.
  • La configurazione dei Controlli di servizio VPC in tutti i progetti comporta un overhead eccessivo

Evita questa opzione quando molti progetti potrebbero contenere dati sensibili.

Per ulteriori informazioni, consulta le best practice per l'abilitazione dei Controlli di servizio VPC.

Opzione 3: non configurare i Controlli di servizio VPC

In alternativa alla configurazione dei Controlli di servizio VPC in modo ampio nel tuo ambiente, puoi scegliere di non utilizzare i Controlli di servizio VPC, in particolare se l'overhead operativo supera il valore dei Controlli di servizio VPC.

Ad esempio, la tua organizzazione potrebbe non avere un pattern di accesso sviluppatore coerente che potrebbe costituire la base di un criterio in entrata. Magari le tue operazioni IT sono esternalizzate a più terze parti, in modo che gli sviluppatori non abbiano dispositivi gestiti o accesso da indirizzi IP coerenti. In questo scenario, potresti non essere in grado di definire regole in entrata per consentire le eccezioni al perimetro di cui gli sviluppatori hanno bisogno per completare le loro operazioni quotidiane.

Utilizza questa opzione quando:

  • Utilizzi servizi che non supportano i Controlli di servizio VPC.
  • I carichi di lavoro sono per internet e non contengono dati sensibili.
  • Non hai attributi coerenti per l'accesso sviluppatore, come i dispositivi gestiti o gli intervalli IP noti.

Evita questa opzione se hai dati sensibili nel tuo ambiente Google Cloud.

Decidere come monitorare continuamente le configurazioni e le minacce non sicure

L'adozione dei servizi cloud introduce nuove sfide e minacce rispetto all'uso di servizi situati on-premise. Gli strumenti esistenti che monitorano i server di lunga durata potrebbero non essere appropriati per la scalabilità automatica o i servizi temporanei e potrebbero non monitorare le risorse serverless. Ti consigliamo quindi di valutare strumenti di sicurezza compatibili con l'intera gamma di servizi cloud che potresti adottare. Devi inoltre monitorare costantemente la sicurezza degli standard del cloud, come i CIS Benchmarks per Google Cloud.

Le seguenti sezioni descrivono le opzioni disponibili per il monitoraggio continuo. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. Le altre opzioni discusse nelle sezioni seguenti sono alternative che puoi prendere in considerazione se l'opzione 1 non si applica al tuo caso d'uso specifico.

Opzione 1: utilizza Security Command Center Premium

Ti consigliamo di attivare il livello Premium di Security Command Center a livello di organizzazione, per rafforzare la tua security posture con le seguenti operazioni:

  • Valutazione della superficie di attacco per dati e sicurezza
  • Fornire un inventario e una visibilità degli asset
  • Identificazione di errori di configurazione, vulnerabilità e minacce
  • Aiuta a mitigare e risolvere i rischi

Quando abiliti Security Command Center all'inizio della creazione della zona di destinazione, il team di sicurezza della tua organizzazione ha una visibilità quasi in tempo reale su configurazioni non sicure, minacce e opzioni di correzione. Questa visibilità aiuta il team di sicurezza a valutare se la zona di destinazione soddisfa i requisiti ed è pronta per consentire agli sviluppatori di iniziare a eseguire il deployment delle applicazioni.

Utilizza questa opzione quando si verifica quanto segue:

  • Vuoi uno strumento per la gestione della postura di sicurezza e il rilevamento delle minacce che sia integrato con tutti i servizi Google Cloud senza ulteriori interventi di integrazione.
  • Vuoi utilizzare la stessa intelligence sulle minacce, lo stesso machine learning e altri metodi avanzati che Google usa per proteggere i propri servizi.
  • Il tuo attuale centro operativo di sicurezza (SOC) non ha le competenze o la capacità per generare insight sulle minacce da un grande volume di log del cloud.

Evita questa opzione quando gli strumenti di sicurezza esistenti possono gestire completamente le risorse cloud temporanee o serverless, monitorare le configurazioni non sicure e identificare le minacce su larga fare lo scale in un ambiente cloud.

Opzione 2: utilizza i tuoi strumenti di sicurezza esistenti per la gestione della security posture nel cloud e il rilevamento delle minacce

Come opzione alternativa all'utilizzo del livello Premium di Security Command Center, puoi prendere in considerazione altri strumenti di gestione della postura di sicurezza cloud. Esistono vari strumenti di terze parti che hanno funzioni simili a Security Command Center e potresti aver già investito in strumenti cloud-native incentrati su ambienti multi-cloud.

Puoi anche utilizzare Security Command Center insieme a strumenti di terze parti. Ad esempio, potresti importare le notifiche di ricerca da Security Command Center a un altro strumento oppure aggiungere un servizio di sicurezza di terze parti alla dashboard di Security Command Center. Come ulteriore esempio, potresti avere la necessità di archiviare i log in un sistema SIEM esistente per consentire al team del SOC di analizzare le minacce. Potresti configurare il SIEM esistente in modo da importare solo le notifiche di rilevamento prodotte da Security Command Center, invece di importare un grande volume di log e aspettarti che un team SOC analizzi i log non elaborati per ottenere insight.

Utilizza questa opzione quando gli strumenti di sicurezza esistenti possono gestire completamente le risorse cloud temporanee o serverless, monitorare le configurazioni non sicure e identificare le minacce su larga fare lo scale in un ambiente cloud.

Evita questa opzione se si verifica quanto segue:

  • Il tuo SOC esistente non ha le competenze o le capacità per generare insight sulle minacce dall'enorme volume di log cloud.
  • L'integrazione di più strumenti di terze parti con più servizi Google Cloud introduce più complessità che valore.

Per ulteriori informazioni, consulta le seguenti risorse:

Decidi come aggregare centralmente i log necessari

La maggior parte degli audit log viene archiviata nel progetto Google Cloud che li ha generati. Man mano che il tuo ambiente cresce, per un revisore potrebbe non essere possibile controllare i log di ogni singolo progetto. Pertanto, devi decidere in che modo i log verranno centralizzati e aggregati per facilitare le operazioni interne di controllo e sicurezza.

Le seguenti sezioni descrivono le opzioni per l'aggregazione dei log. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. Le altre opzioni discusse nelle sezioni seguenti sono alternative che puoi prendere in considerazione se l'opzione 1 non si applica al tuo caso d'uso specifico.

Opzione 1: conserva i log in Google Cloud utilizzando sink di log aggregati

Ti consigliamo di configurare un sink di log centralizzato a livello di organizzazione per gli audit log e gli altri log richiesti dal tuo team di sicurezza. Puoi fare riferimento allo strumento di definizione dell'ambito dei log per identificare i log richiesti dal team di sicurezza e se questi tipi di log richiedono un'abilitazione esplicita.

Ad esempio, il team di sicurezza si aspetta un record centrale di tutte le risorse create dagli utenti, in modo che possa monitorare ed esaminare le modifiche sospette. Il team responsabile della sicurezza richiede anche un record immutabile dell'accesso ai dati per determinati carichi di lavoro altamente sensibili. Di conseguenza, il team per la sicurezza configura un sink di log per aggregare gli audit log delle attività di amministrazione di tutti i progetti in un bucket di analisi dei log in un progetto centrale, visualizzabile per indagini estemporanee. Quindi configura un secondo sink di log per gli audit log di accesso ai dati di progetti con carichi di lavoro sensibili in un bucket Cloud Storage per la conservazione a lungo termine.

Utilizza questa opzione quando si verifica quanto segue:

  • Il team di sicurezza si aspetta un record centrale di tutti gli audit log o di altri tipi di log specifici.
  • Il team di sicurezza deve archiviare i log in un ambiente con accesso limitato, al di fuori del controllo del carico di lavoro o dei team che hanno generato il log.

Evita questa opzione se si verifica quanto segue: - La tua organizzazione non ha un requisito centrale per la coerenza degli audit log tra i carichi di lavoro. - I singoli proprietari del progetto hanno la piena responsabilità della gestione dei propri audit log.

Per ulteriori informazioni, consulta le seguenti risorse:

Opzione 2: esporta gli audit log richiesti nello spazio di archiviazione al di fuori di Google Cloud

In alternativa all'archiviazione dei log solo in Google Cloud, valuta la possibilità di esportare gli audit log al di fuori di Google Cloud. Dopo aver centralizzato i tipi di log necessari in un sink di log aggregato in Google Cloud, importa i contenuti del sink in un'altra piattaforma esterna a Google Cloud per l'archiviazione e l'analisi dei log.

Ad esempio, potresti utilizzare un SIEM di terze parti per aggregare e analizzare gli audit log di più cloud provider. Questo strumento ha funzionalità sufficienti per lavorare con le risorse cloud serverless e il team del tuo SOC ha le competenze e le capacità per generare insight da questo grande volume di log.

Questa opzione può essere potenzialmente molto costosa a causa dei costi del traffico di rete in uscita in Google Cloud, nonché del costo e della capacità di archiviazione nell'altro ambiente. Invece di esportare ogni log disponibile, ti consigliamo di selezionare con attenzione i log richiesti nell'ambiente esterno.

Utilizza questa opzione quando hai la necessità di archiviare i log di tutti gli ambienti e i provider di servizi cloud in un'unica posizione centrale.

Evita questa opzione se si verifica quanto segue:

  • I tuoi sistemi esistenti non hanno la capacità o il budget per importare un grande volume di log cloud aggiuntivi.
  • I sistemi esistenti richiedono attività di integrazione per ogni tipo e formato di log.
  • Stai raccogliendo i log senza un obiettivo chiaro su come verranno utilizzati.

Per ulteriori informazioni, consulta le seguenti risorse:

Decidere come soddisfare i requisiti di conformità per la crittografia at-rest

Google Cloud cripta automaticamente tutti i contenuti archiviati inattivi utilizzando uno o più meccanismi di crittografia. A seconda dei requisiti di conformità, potresti avere l'obbligo di gestire personalmente le chiavi di crittografia.

Le seguenti sezioni descrivono le opzioni per la crittografia at-rest. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. Le altre opzioni discusse nelle sezioni seguenti sono alternative che puoi prendere in considerazione se l'opzione 1 non si applica al tuo caso d'uso specifico.

Opzione 1: accetta l'utilizzo della crittografia at-rest predefinita

La crittografia at-rest predefinita è sufficiente per molti casi d'uso che non hanno requisiti di conformità specifici in merito alla gestione delle chiavi di crittografia.

Ad esempio, il team di sicurezza di un'azienda di giochi online richiede che tutti i dati dei clienti siano criptati at-rest. Non hanno requisiti normativi sulla gestione delle chiavi e, dopo aver esaminato la crittografia at-rest predefinita di Google, ritengo che sia un controllo sufficiente per le loro esigenze.

Utilizza questa opzione quando si verifica quanto segue:

  • Non hai requisiti specifici su come criptare i dati o su come vengono gestite le chiavi di crittografia.
  • Preferisci un servizio gestito al costo e all'overhead operativo della gestione delle tue chiavi di crittografia.

Evita questa opzione se hai requisiti di conformità per gestire le tue chiavi di crittografia.

Per ulteriori informazioni, consulta Crittografia at-rest in Google Cloud.

Opzione 2: gestisci le chiavi di crittografia utilizzando Cloud KMS

Oltre alla crittografia at-rest predefinita, potresti richiedere un maggiore controllo sulle chiavi utilizzate per criptare i dati at-rest all'interno di un progetto Google Cloud. Cloud Key Management Service (Cloud KMS) offre la possibilità di proteggere i dati utilizzando chiavi di crittografia gestite dal cliente (CMEK). Nel settore dei servizi finanziari, ad esempio, potresti avere l'obbligo di riferire ai revisori esterni come gestisci le tue chiavi di crittografia per i dati sensibili.

Per ulteriori livelli di controllo, puoi configurare moduli di sicurezza hardware (HSM) o gestione delle chiavi esterne (EKM) con CMEK. Le chiavi di crittografia fornite dal cliente (CSEK) non sono consigliate. Gli scenari che storicamente erano affrontati da CSEK ora vengono affrontati meglio da Cloud External Key Manager (Cloud EKM), in quanto Cloud EKM supporta un numero maggiore di servizi e una maggiore disponibilità.

Questa opzione trasferisce agli sviluppatori di applicazioni una certa responsabilità di seguire la gestione delle chiavi richiesta dal tuo team di sicurezza. Il team di sicurezza può applicare il requisito bloccando la creazione di risorse non conformi con i criteri dell'organizzazione CMEK.

Utilizza questa opzione quando una o più delle seguenti condizioni sono vere:

  • Hai un requisito per gestire il ciclo di vita delle tue chiavi.
  • Devi generare materiale per le chiavi di crittografia con un HSM certificato FIPS 140-2 livello 3.
  • Hai un requisito per archiviare il materiale delle chiavi di crittografia al di fuori di Google Cloud utilizzando Cloud EKM.

Evita questa opzione se si verifica quanto segue:

  • Non hai requisiti specifici su come criptare i dati o gestire le chiavi di crittografia.
  • Preferisci un servizio gestito al costo e all'overhead operativo della gestione delle tue chiavi di crittografia.

Per ulteriori informazioni, consulta le seguenti risorse:

Opzione 3: tokenizza i dati a livello di applicazione prima che siano conservati nello spazio di archiviazione

Oltre alla crittografia predefinita fornita da Google, puoi anche sviluppare la tua soluzione per tokenizzare i dati prima di archiviarli in Google Cloud.

Ad esempio, un data scientist deve analizzare un set di dati con informazioni PII, ma non deve avere accesso per leggere i dati non elaborati di alcuni campi sensibili. Per limitare l'accesso del controllo ai dati non elaborati, potresti sviluppare una pipeline di importazione con Sensitive Data Protection per importare e tokenizzare i dati sensibili e quindi rendere persistenti i dati tokenizzati in BigQuery.

La tokenizzazione dei dati non è un controllo che puoi applicare centralmente nella zona di destinazione. Questa opzione trasferisce invece la responsabilità agli sviluppatori di applicazioni di configurare la propria crittografia o a un team della piattaforma che sviluppa una pipeline di crittografia come servizio condiviso che gli sviluppatori di applicazioni possono utilizzare.

Utilizza questa opzione quando determinati carichi di lavoro contengono dati altamente sensibili che non devono essere utilizzati in forma non elaborata.

Evita questa opzione quando Cloud KMS è sufficiente per soddisfare i tuoi requisiti, come descritto in Gestire le chiavi di crittografia utilizzando Cloud KMS. Lo spostamento dei dati attraverso pipeline di crittografia e decriptazione aggiuntive aumenta i costi, la latenza e la complessità delle applicazioni.

Per ulteriori informazioni, consulta quanto segue :

Decidi come soddisfare i requisiti di conformità per la crittografia dei dati in transito

Google Cloud adotta diverse misure di sicurezza per garantire l'autenticità, l'integrità e la privacy dei dati in transito. A seconda dei requisiti di sicurezza e conformità, puoi anche configurare la crittografia a livello di applicazione.

Le seguenti sezioni descrivono le opzioni per la crittografia dei dati in transito. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. L'altra opzione discussa nelle sezioni seguenti è una funzionalità aggiuntiva che puoi prendere in considerazione se l'opzione 1 non è sufficiente per il tuo caso d'uso specifico.

Opzione 1: valuta se la crittografia predefinita in transito è sufficiente

Molti pattern di traffico traggono vantaggio dalla crittografia predefinita di Google in transito senza richiedere una configurazione aggiuntiva. Tutto il traffico da VM a VM all'interno di una rete VPC e delle reti VPC connesse viene criptato al livello 3 o 4. Il traffico da internet ai servizi Google termina al Google Front End (GFE). GFE esegue inoltre le seguenti operazioni:

  • Termina il traffico per il traffico proxy HTTP(S), TCP e TLS in entrata
  • Fornisce contromisure per gli attacchi DDoS
  • Route e bilancia il carico del traffico verso i servizi Google Cloud

Ad esempio, se stai progettando un'applicazione serverless interna utilizzando le API di Google, i percorsi di rete dei servizi utilizzeranno automaticamente la crittografia predefinita dei dati in transito. Non è necessario configurare crittografia aggiuntiva nei controlli di transito per criptare il traffico.

Utilizza questa opzione quando la crittografia predefinita di Google in transito è sufficiente per i tuoi carichi di lavoro interni.

Evita questa opzione se si verifica quanto segue:

  • Hai bisogno della crittografia per tutto il traffico su Cloud Interconnect.
  • Consenti il traffico internet in entrata nella tua rete VPC.
  • È necessaria la crittografia di livello 7 in transito tra tutte le risorse di calcolo interne.

In questi casi, devi configurare controlli aggiuntivi, come descritto in Opzione 2: richiedere alle applicazioni di configurare la crittografia di livello 7 in transito. Per ulteriori informazioni, vedi Crittografia dei dati in transito in Google Cloud.

Opzione 2: richiedi alle applicazioni di configurare la crittografia di livello 7 in transito

Oltre alla crittografia predefinita in transito, puoi configurare la crittografia di livello 7 per il traffico delle applicazioni. Google Cloud fornisce servizi gestiti per supportare le applicazioni che richiedono la crittografia a livello di applicazione in transito, inclusi certificati gestiti, Cloud Service Mesh e Cloud Service Mesh.

Ad esempio, uno sviluppatore sta creando una nuova applicazione che accetta il traffico in entrata da internet. Utilizzano un bilanciatore del carico delle applicazioni esterno con certificati SSL gestiti da Google per eseguire e scalare i servizi dietro un singolo indirizzo IP.

La crittografia a livello di applicazione non è un controllo che puoi applicare centralmente nella zona di destinazione. Questa opzione trasferisce invece una certa responsabilità agli sviluppatori di applicazioni nella configurazione della crittografia in transito.

Utilizza questa opzione quando le applicazioni richiedono traffico HTTPS o SSL tra i componenti.

Valuta la possibilità di consentire un'eccezione limitata a questa opzione quando esegui la migrazione di carichi di lavoro di computing al cloud che in precedenza non richiedevano la crittografia in transito per il traffico interno quando le applicazioni erano on-premise. Durante una migrazione su larga scala, la modernizzazione delle applicazioni legacy prima della migrazione potrebbe causare un ritardo inaccettabile al programma.

Per ulteriori informazioni, consulta le seguenti risorse:

Decidere quali controlli aggiuntivi sono necessari per gestire l'accesso del provider di servizi cloud

La necessità di controllare l'accesso del fornitore di servizi cloud (CSP) può essere un problema durante l'adozione del cloud. Google Cloud fornisce più livelli di controllo per abilitare la verifica dell'accesso del cloud provider.

Le seguenti sezioni descrivono le opzioni per la gestione dell'accesso CSP. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. L'altra opzione discussa nelle sezioni seguenti è una funzionalità aggiuntiva che puoi prendere in considerazione se l'opzione 1 non è sufficiente per il tuo caso d'uso specifico.

Opzione 1: abilita i log di Access Transparency

I log di Access Transparency registrano le azioni intraprese dal personale Google Cloud nel tuo ambiente, ad esempio quando risolve i problemi di una richiesta di assistenza.

Ad esempio, lo sviluppatore segnala un problema per la risoluzione dei problemi all'assistenza clienti Google Cloud e chiede all'addetto all'assistenza di aiutarti a risolvere i problemi dell'ambiente. Viene generato un log di Access Transparency per mostrare le azioni intraprese dal personale di assistenza, incluso il numero della richiesta di assistenza che lo ha giustificato.

Utilizza questa opzione quando si verifica quanto segue:

  • Hai l'obbligo di verificare che il personale Google Cloud acceda ai tuoi contenuti solo per motivi aziendali validi, ad esempio per risolvere un'interruzione del servizio o per rispondere alle tue richieste di assistenza.
  • Devi soddisfare un requisito di conformità per monitorare l'accesso ai dati sensibili.

Opzione 2: attiva i log di Access Transparency e la gestione dell'accesso del provider

Se la tua azienda ha il requisito di conformità che prevede la concessione di un'approvazione esplicita prima che un CSP possa accedere al tuo ambiente, oltre all'opzione 1, puoi utilizzare Access Transparency con altri controlli che ti consentono di approvare o negare esplicitamente l'accesso ai tuoi dati.

Access Approval è una soluzione manuale che garantisce che l'assistenza clienti e il team tecnico di Google richiedano la tua approvazione esplicita (tramite email o tramite webhook) ogni volta che devono accedere ai tuoi contenuti.

Key Access Justifications è una soluzione programmatica che aggiunge un campo di giustificazione a tutte le richieste di chiavi di crittografia configurate con Cloud EKM.

Utilizza questa opzione quando si verifica quanto segue:

  • Vuoi che un team centrale gestisca direttamente l'accesso ai tuoi contenuti da parte del personale di Google.
  • Per Access Approval, puoi accettare il rischio che la capacità centrale di approvare o rifiutare ogni richiesta di accesso sia più importante del compromesso operativo, che potrebbe comportare una risoluzione più lenta delle richieste di assistenza.
  • Per Key Access Justifications, la tua azienda utilizza già Cloud External Key Manager come parte della tua strategia di crittografia e vuole il controllo programmatico su tutti i tipi di accesso ai dati criptati (non solo sull'accesso da parte del personale Google ai dati).

Evita questa opzione se si verifica quanto segue:

  • Il ritardo operativo che può verificarsi quando un team centrale con l'autorità Access Approval deve rispondere è un rischio inaccettabile per i carichi di lavoro che richiedono un'alta disponibilità e una risposta rapida dall'assistenza clienti.

Per ulteriori informazioni, consulta le seguenti risorse:

Best practice per la sicurezza delle zone di destinazione di Google Cloud

Oltre alle decisioni introdotte in questo documento, considera le seguenti best practice per la sicurezza:

Passaggi successivi