Decidere la sicurezza per la tua zona di destinazione Google Cloud

Last reviewed 2023-08-31 UTC

Questo documento illustra le decisioni di sicurezza importanti e le opzioni consigliate da considerare durante la progettazione di una zona di destinazione Google Cloud. Fa parte di una serie di post sulle zone di destinazione ed è rivolto a esperti di sicurezza, CISO e architetti che vogliono comprendere le decisioni che devono prendere durante la progettazione di una zona di destinazione in Google Cloud.

In questo documento si presume che un team centrale, come il team di sicurezza o il team della piattaforma, applichi questi controlli di sicurezza delle zone di destinazione. Poiché l'obiettivo di questo documento è la progettazione di ambienti su larga scala, alcune strategie descritte potrebbero essere meno pertinenti per i piccoli team.

Punti decisionali per la protezione della tua zona di destinazione Google Cloud

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

Diagramma dell'architettura

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

Esempio di architettura dei controlli di sicurezza.

Il diagramma precedente mostra quanto segue:

  • La gestione delle chiavi degli account di servizio contribuisce a ridurre il rischio derivante dalle credenziali degli account di servizio a vita lunga.
  • I Controlli di servizio VPC definiscono un perimetro attorno alle risorse sensibili che contribuisce a limitare l'accesso dall'esterno del perimetro.
  • Security Command Center monitora l'ambiente alla ricerca di configurazioni e minacce non sicure.
  • Un sink di log centralizzato raccoglie i log di controllo da tutti i progetti.
  • La crittografia at-rest predefinita di Google cripta tutti i dati persistenti sul disco.
  • La crittografia predefinita di Google per i dati in transito si applica ai percorsi di rete di livello 3 e 4.
  • Access Transparency ti offre visibilità e controllo su come Google può accedere al tuo ambiente.

Decidere come limitare le credenziali permanenti per gli account di servizio

Gli account di servizio sono identità macchina che utilizzi per concedere i 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 e tutte le credenziali permanenti sono potenzialmente ad alto rischio. Ti sconsigliamo di consentire agli sviluppatori di creare liberamente chiavi degli account di servizio.

Ad esempio, se uno sviluppatore esegue commit accidentalmente della chiave dell'account di servizio in un repository Git pubblico, un malintenzionato esterno può autenticarsi utilizzando queste credenziali. Un altro esempio: se la chiave dell'account di servizio è memorizzata in un repository interno, un insider malintenzionato che può leggere la chiave potrebbe utilizzare le credenziali per eseguire la riassegnazione dei propri privilegi Google Cloud.

Per definire una strategia per gestire queste credenziali permanenti, devi fornire alternative valide, limitare la proliferazione delle credenziali permanenti e gestire il loro utilizzo. Per informazioni sulle alternative alle chiavi degli account di servizio, vedi Scegliere il metodo di autenticazione migliore per il tuo 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 discusse nelle seguenti sezioni sono alternative che puoi prendere in considerazione se l'opzione 1 non si applica alla tua organizzazione specifica.

Per tutte le organizzazioni create dopo il 23 maggio 2024 vengono applicati criteri dell'organizzazione sicuri per impostazione predefinita al momento della prima creazione della risorsa organizzazione. Questa modifica rende l'opzione 1 l'opzione predefinita.

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

Ti consigliamo di non consentire a nessun utente di scaricare le chiavi degli account di servizio perché le chiavi esposte sono un vettore di attacco comune. La limitazione dell'utilizzo delle chiavi degli account di servizio permanenti è un'opzione che può contribuire a ridurre il rischio e il sovraccarico della gestione manuale delle chiavi degli account di servizio.

Per implementare questa opzione, tieni presente quanto segue:

Evita questa opzione se hai già implementato gli 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 dell'accesso aggiuntivi per generare credenziali di breve durata

In alternativa a Limita l'utilizzo delle chiavi degli account di servizio permanenti, puoi generare credenziali di breve durata per gli account di servizio. Le credenziali di breve durata presentano 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 la generazione di 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 non hai la capacità di creare la tua soluzione.

Per saperne di più, consulta la sezione Creare credenziali di account di servizio di breve durata.

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

Le API di Google hanno endpoint pubblici disponibili per tutti i clienti. Anche se ogni risorsa API nel tuo ambiente Google Cloud è soggetta ai controlli di accesso IAM, esiste il rischio che i dati possano essere accessibili utilizzando credenziali rubate, esfiltrate da addetti ai lavori malintenzionati o codice compromesso oppure esposti tramite un criterio IAM configurato in modo errato.

Controlli di servizio VPC è una soluzione che affronta questi rischi. Tuttavia, Controlli di servizio VPC introduce anche complessità nel modello di accesso, pertanto devi progettarlo in modo che soddisfi il tuo ambiente e il tuo caso d'uso specifici.

Le sezioni seguenti descrivono le opzioni per ridurre l'esfiltrazione di dati tramite le API di Google. 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: configura i Controlli di servizio VPC in modo generale nell'ambiente

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

Utilizza questa opzione se si verificano le seguenti condizioni:

  • I servizi che intendi utilizzare supportano i Controlli di servizio VPC e i tuoi workload non richiedono l'accesso a internet senza restrizioni.
  • Archivi su Google Cloud dati sensibili che potrebbero rappresentare una perdita significativa se vengono trafugati.
  • 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 se i tuoi carichi di lavoro richiedono l'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 generale nell'ambiente, puoi configurarli solo nel sottoinsieme di progetti che contengono dati sensibili e carichi di lavoro solo interni. Questa opzione ti consente di utilizzare un design e un funzionamento più semplici per la maggior parte dei progetti, dando comunque 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 solo per questi progetti e definire regole di ingresso e uscita per consentire eccezioni limitate agli analisti che devono utilizzare questi set di dati.

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 l'ingresso dal traffico utente potrebbe essere un progetto esterno al perimetro, mentre il livello di applicazione e il livello di dati che contengono dati sensibili potrebbero essere progetti distinti all'interno del perimetro di servizio. Definisci le regole per il traffico in entrata e in uscita per il perimetro in modo che i livelli possano comunicare all'interno del perimetro con accesso granulare.

Utilizza questa opzione se si verificano le seguenti condizioni:

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

Evita questa opzione se molti progetti potrebbero contenere dati sensibili.

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

Opzione 3: non configurare i Controlli di servizio VPC

Come alternativa alla configurazione dei Controlli di servizio VPC in tutto l'ambiente, puoi scegliere di non utilizzarli, in particolare se il sovraccarico operativo supera il valore dei Controlli di servizio VPC.

Ad esempio, la tua organizzazione potrebbe non avere uno schema coerente di accesso sviluppatori che possa costituire la base di un criterio di ingresso. È possibile che le operazioni IT siano esternalizzate a più terze parti, pertanto gli sviluppatori non dispongono di dispositivi gestiti o di accesso da indirizzi IP coerenti. In questo scenario, potresti non essere in grado di definire regole di ingresso per consentire 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 rivolti a internet e non contengono dati sensibili.
  • Non disponi di attributi coerenti di accesso sviluppatore, come dispositivi gestiti o intervalli IP noti.

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

Decidere come monitorare continuamente la presenza di configurazioni e minacce non sicure

L'adozione di servizi cloud introduce nuove sfide e minacce rispetto all'utilizzo di servizi 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 affatto le risorse serverless. Pertanto, devi valutare gli strumenti di sicurezza che funzionano con l'intera gamma di servizi cloud che potresti adottare. Devi anche monitorare continuamente la presenza di standard cloud, come i benchmark CIS per Google Cloud.

Le sezioni seguenti descrivono le opzioni per il monitoraggio continuo. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. Le altre opzioni discusse nelle seguenti sezioni 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

Ti consigliamo di attivare Security Command Center a livello di organizzazione, in modo da rafforzare la tua security posture svolgendo le seguenti operazioni:

  • Valutazione della superficie di attacco per dati e sicurezza
  • Fornire inventario e rilevamento degli asset
  • Identificazione di errori di configurazione, vulnerabilità e minacce
  • Aiutare a mitigare e correggere i rischi

Quando attivi Security Command Center all'inizio della compilazione della landing zone, il team di sicurezza della tua organizzazione ha 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 landing zone soddisfa i suoi requisiti ed è pronta per l'inizio del deployment delle applicazioni da parte degli sviluppatori.

Utilizza questa opzione se si verificano le seguenti condizioni:

  • Vuoi uno strumento di gestione della postura di sicurezza e di rilevamento delle minacce integrato con tutti i servizi Google Cloud senza ulteriori operazioni di integrazione.
  • Vuoi utilizzare le stesse informazioni sulle minacce, il machine learning e gli altri metodi avanzati che Google utilizza per proteggere i propri servizi.
  • Il tuo attuale centro operativo di sicurezza (SOC) non dispone delle competenze o della capacità di generare approfondimenti sulle minacce da un volume elevato di log cloud.

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

Opzione 2: utilizza gli strumenti di sicurezza esistenti per la gestione della strategia di sicurezza del cloud e il rilevamento delle minacce

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

Puoi anche utilizzare Security Command Center e strumenti di terze parti insieme. Ad esempio, potresti importare le notifiche relative ai risultati da Security Command Center in un altro strumento oppure aggiungere un servizio di sicurezza di terze parti alla dashboard di Security Command Center. Come altro esempio, potresti avere la necessità di memorizzare i log su un sistema SIEM esistente per consentire al team SOC di analizzarli per rilevare eventuali minacce. Potresti configurare il tuo SIEM esistente in modo da importare solo le notifiche dei risultati prodotte da Security Command Center, anziché importare un volume elevato di log e aspettarti che un team SOC analizzi i log non elaborati per ottenere informazioni.

Utilizza questa opzione quando gli strumenti di sicurezza esistenti possono gestire completamente le risorse cloud effimere 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 verificano le seguenti condizioni:

  • Il tuo SOC esistente non ha le competenze o la capacità di generare informazioni sulle minacce dal vasto 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, può essere insostenibile per un revisore controllare i log in ogni singolo progetto. Pertanto, devi decidere in che modo i log verranno centralizzati e aggregati per supportare le operazioni di controllo e sicurezza interne.

Le sezioni seguenti 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 seguenti sezioni 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 i sink dei log aggregati

Ti consigliamo di configurare un'sink di log centralizzata per tutta l'organizzazione per gli audit log e altri log richiesti dal team di sicurezza. Puoi consultare lo strumento di definizione dell'ambito dei log per identificare i log richiesti dal tuo team di sicurezza e se questi tipi di log richiedono l'attivazione esplicita.

Ad esempio, il team di sicurezza si aspetta un record centrale di tutte le risorse create dagli utenti in modo da poter monitorare e esaminare le modifiche sospette. Il team di sicurezza richiede inoltre un record immutabile dell'accesso ai dati per determinati carichi di lavoro altamente sensibili. Di conseguenza, il team di sicurezza configura unsink 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 che può visualizzare per indagini estemporanee. Poi configurano un secondo sink di log per gli audit log di accesso ai dati da progetti con carichi di lavoro sensibili in un bucket Cloud Storage per la conservazione a lungo termine.

Utilizza questa opzione se si verificano le seguenti condizioni:

  • Il team di sicurezza si aspetta un record centrale di tutti i log di controllo 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 verificano le seguenti condizioni:

  • La tua organizzazione non ha un requisito centrale per log di controllo coerenti tra i carichi di lavoro.
  • I singoli proprietari dei progetti sono pienamente responsabili della gestione dei propri log di controllo.

Per ulteriori informazioni, consulta le seguenti risorse:

Opzione 2: esporta i log di controllo richiesti in uno spazio di archiviazione esterno a Google Cloud

In alternativa all'archiviazione dei log solo in Google Cloud, valuta la possibilità di esportare i log di controllo 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 di questo sink in un'altra piattaforma esterna a Google Cloud per archiviare e analizzare i log.

Ad esempio, puoi utilizzare un SIEM di terze parti per aggregare e analizzare i log di controllo su più fornitori di cloud. Questo strumento ha funzionalità sufficienti per lavorare con le risorse cloud serverless e il tuo team SOC ha le competenze e la capacità di generare informazioni da questo grande volume di log.

Questa opzione può essere potenzialmente molto costosa a causa del costo di uscita della rete in Google Cloud, nonché del costo e della capacità dello spazio di archiviazione nell'altro ambiente. Anziché esportare tutti i log disponibili, ti consigliamo di essere selettivo sui log richiesti nell'ambiente esterno.

Utilizza questa opzione se devi archiviare i log di tutti gli ambienti e i fornitori di servizi cloud in un'unica posizione centrale.

Evita questa opzione se si verificano le seguenti condizioni:

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

Per ulteriori informazioni, consulta Controlli di rilevamento nel progetto della piattaforma di base per le aziende.

Decidi 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 autonomamente le chiavi di crittografia.

Le sezioni seguenti descrivono le opzioni per crittografia at-rest. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. Le altre opzioni discusse nelle seguenti sezioni 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 dei dati inattivi predefinita è sufficiente per molti casi d'uso che non hanno requisiti di conformità particolari per la gestione delle chiavi di crittografia.

Ad esempio, il team di sicurezza di una società di giochi online richiede che tutti i dati dei clienti vengano criptati a riposo. Non hanno requisiti normativi sulla gestione delle chiavi e, dopo aver esaminato la crittografia at-rest lato client predefinita di Google, ritengono che sia un controllo sufficiente per le loro esigenze.

Utilizza questa opzione se si verificano le seguenti condizioni:

  • Non hai requisiti particolari 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 dei dati inattivi in Google Cloud.

Opzione 2: gestisci le chiavi di crittografia utilizzando Cloud KMS

Oltre alla crittografia at-rest predefinita, potresti aver bisogno di un maggiore controllo sulle chiavi utilizzate per criptare i dati inattivi all'interno di un progetto Google Cloud. Cloud Key Management Service (Cloud KMS) offre la possibilità di proteggere i dati utilizzando le chiavi di crittografia gestite dal cliente (CMEK). Ad esempio, nel settore dei servizi finanziari potresti dover comunicare ai tuoi revisori esterni come gestisci le tue chiavi di crittografia per i dati sensibili.

Per livelli di controllo aggiuntivi, puoi configurare moduli di sicurezza hardware (HSM) o gestione delle chiavi esterna (EKM) con CMEK. Le chiavi di crittografia fornite dal cliente (CSEK) non sono consigliate. Gli scenari che in passato venivano gestiti con le CSEK ora sono gestiti meglio da Cloud External Key Manager (Cloud EKM) perché Cloud EKM supporta più servizi e ha una maggiore disponibilità.

Questa opzione trasferisce parte della responsabilità agli sviluppatori di applicazioni per quanto riguarda la gestione delle chiavi impostata dal 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 se una o più delle seguenti condizioni sono vere:

  • Devi gestire il ciclo di vita delle tue chiavi.
  • Devi generare materiale della chiave crittografica con un HSM certificato FIPS 140-2 di livello 3.
  • Devi archiviare il materiale delle chiavi crittografiche al di fuori di Google Cloud utilizzando Cloud EKM.

Evita questa opzione se si verificano le seguenti condizioni:

  • Non hai requisiti particolari per la crittografia dei dati o per la gestione delle 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 livello di applicazione prima di mantenerli nello spazio di archiviazione

Oltre alla crittografia predefinita fornita da Google, puoi anche sviluppare una 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 alla lettura dei dati non elaborati di alcuni campi sensibili. Per limitare il controllo dell'accesso ai dati non elaborati, puoi sviluppare una pipeline di importazione con Sensitive Data Protection per importare e tokenizzare i dati sensibili, quindi mantenere i dati tokenizzati in BigQuery.

La tokenizzazione dei dati non è un controllo che puoi applicare in modo centralizzato 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 da utilizzare per gli sviluppatori di applicazioni.

Utilizza questa opzione quando determinati workload contengono dati altamente sensibili che non devono essere utilizzati nella loro forma non elaborata.

Evita questa opzione se Cloud KMS è sufficiente per soddisfare i tuoi requisiti, come descritto in Gestire le chiavi di crittografia utilizzando Cloud KMS. Il trasferimento dei dati attraverso pipeline di crittografia e decrittografia aggiuntive aggiunge costi, latenza e complessità alle applicazioni.

Per ulteriori informazioni, consulta quanto segue :

Decidere come soddisfare i requisiti di conformità per la crittografia in transito

Google Cloud dispone di diverse misure di sicurezza volte a 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 sezioni seguenti 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 dei dati in transito è sufficiente

Molti pattern di traffico nella tua zona di destinazione beneficiano della crittografia in transito predefinita di Google.

  • Tutto il traffico da VM a VM all'interno di una rete VPC e delle reti VPC collegate viene criptato a livello 3 o 4.

  • Il traffico da internet ai servizi Google termina in Google Front End (GFE). GFE esegue inoltre le seguenti operazioni:

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

Un modello di traffico che richiede configurazione è Cloud Interconnect, perché il traffico dal tuo ambiente on-premise a Google Cloud non è criptato in transito per impostazione predefinita. Se utilizzi Cloud Interconnect, ti consigliamo di attivare MACsec per Cloud Interconnect all'interno della tua landing zone.

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

Evita questa opzione se si verificano le seguenti condizioni:

  • Consenti il traffico in entrata da internet nella tua rete VPC.
  • Richiedi 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, consulta Crittografia dei dati in transito in Google Cloud.

Opzione 2: richiedere alle applicazioni di configurare la crittografia dei dati in transito a livello 7

Oltre alla crittografia dei dati in transito predefinita, 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 i 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 in modo centralizzato nella zona di destinazione. Questa opzione trasferisce invece parte della responsabilità agli sviluppatori di applicazioni per la 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 dei carichi di lavoro di calcolo 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, l'obbligo di modernizzare le applicazioni legacy prima della migrazione potrebbe causare un ritardo inaccettabile per il programma.

Per ulteriori informazioni, consulta le seguenti risorse:

Decidi quali controlli aggiuntivi sono necessari per gestire l'accesso dei fornitori di servizi cloud

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

Le sezioni seguenti descrivono le opzioni per gestire l'accesso al fornitore di servizi cloud. 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: attiva i log di Access Transparency

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

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

Utilizza questa opzione se si verificano le seguenti condizioni:

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

Opzione 2: attiva i log di Access Transparency e la gestione dell'accesso dei fornitori

Se la tua attività ha un requisito di conformità che prevede la concessione dell'approvazione esplicita prima che un fornitore di servizi cloud 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 di ingegneria di Google richiedano la tua approvazione esplicita (tramite email o tramite un webhook) ogni volta che devono accedere ai tuoi contenuti.

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

Utilizza questa opzione se si verificano le seguenti condizioni:

  • Vuoi che un team centrale gestisca direttamente l'accesso al personale di Google ai tuoi contenuti.
  • Per l'approvazione dell'accesso, puoi accettare il rischio che la funzionalità centrale di approvazione o rifiuto di ogni richiesta di accesso sia più importante del compromesso operativo, che potrebbe comportare una risoluzione più lenta delle richieste di assistenza.
  • Per le giustificazioni dell'accesso alle chiavi, la tua azienda utilizza già Cloud External Key Manager nell'ambito della propria strategia di crittografia e vuole avere il controllo programmatico su tutti i tipi di accesso ai dati criptati (non solo sull'accesso dei dipendenti di Google ai dati).

Evita questa opzione se si verificano le seguenti condizioni:

  • Il ritardo operativo che può verificarsi quando un team centrale con autorità di Approvazione dell'accesso 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 Google Cloud

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

Passaggi successivi