Decidere la sicurezza per la tua zona di destinazione Google Cloud

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

In questo documento, si presuppone che un team centrale, come il team di sicurezza o il team della piattaforma, applichi questi controlli di sicurezza della landing zone. Poiché questo documento si concentra sulla progettazione di ambienti di livello aziendale, alcune strategie descritte potrebbero essere meno pertinenti per i piccoli team.

Punti decisionali per proteggere la tua Google Cloud zona di destinazione

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

Diagramma dell'architettura

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

Esempio di architettura dei controlli di sicurezza.

Il diagramma precedente mostra quanto segue:

  • La gestione delle chiavi del service account contribuisce a mitigare il rischio derivante dalle credenziali del account di servizio di lunga durata.
  • I Controlli di servizio VPC definiscono un perimetro intorno alle risorse sensibili che contribuisce a limitare l'accesso dall'esterno del perimetro.
  • Security Command Center monitora l'ambiente per rilevare configurazioni non sicure e minacce.
  • Un sink di log centralizzato raccoglie i log di controllo di tutti i progetti.
  • La crittografia at-rest predefinita di Google cripta tutti i dati che vengono salvati sul disco.
  • La crittografia in transito predefinita di Google si applica ai percorsi di rete di livello 3 e livello 4.
  • Access Transparency ti offre visibilità e controllo sulla modalità di accesso di Google al tuo ambiente.

Decidi come limitare le credenziali permanenti per i service account

I service account 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 persistente e tutte le credenziali persistenti sono potenzialmente ad alto rischio. Ti sconsigliamo di consentire agli sviluppatori di creare liberamente chiavi dell'account di servizio.

Ad esempio, se uno sviluppatore esegue accidentalmente il commit della chiave del account di servizio in un repository Git pubblico, un malintenzionato esterno può eseguire l'autenticazione 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 aumentare i propri privilegi. Google Cloud

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

Tutte le organizzazioni create dopo il 23 maggio 2024 hanno Google Cloud vincoli di base di sicurezza applicati al momento della creazione della risorsa dell'organizzazione. Questa modifica imposta l'opzione 1 come predefinita.

Opzione 1: limita l'utilizzo delle chiavi del account di servizio persistenti

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. Limitare l'utilizzo delle chiavi dei account di servizio persistenti è un'opzione che può contribuire a ridurre il rischio e il sovraccarico della gestione manuale delle chiavi deaccount di serviziont.

Per implementare questa opzione, tieni presente quanto segue:

  • Per impedire agli sviluppatori di creare e scaricare credenziali persistenti, configura il vincolo di policy dell'organizzazione constraints/iam.disableServiceAccountKeyCreation.
  • Insegna ai tuoi team le alternative più sicure alle account di servizio account. Ad esempio, quando utenti e applicazioni esterni al tuo ambienteGoogle Cloud devono utilizzare un account di servizio, possono eseguire l'autenticazione con l'imitazione del service account o la federazione delle identità per i workload anziché con una chiave del account di servizio.
  • Progetta una procedura per consentire ai team di richiedere un'eccezione a questa policy quando il download di una chiave delaccount di serviziot è l'unica opzione praticabile. Ad esempio, un prodotto SaaS di terze parti potrebbe richiedere una chiave dell'account di servizio per leggere i log dal tuo ambiente Google Cloud .

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

Per ulteriori informazioni, consulta le seguenti risorse:

Opzione 2: utilizza strumenti di gestione dell'accesso aggiuntivi per generare credenziali temporanee

In alternativa a Limitare l'utilizzo di chiavi del account di servizio persistenti, puoi generare credenziali di breve durata per i service account. Le credenziali di breve durata creano meno rischi rispetto a quelle 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 ilcontrollo dell'accessoo o se disponi di budget e capacità sufficienti per sviluppare una soluzione personalizzata.

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

Per maggiori informazioni, vedi Creare credenziali del 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. Sebbene ogni risorsa API nel tuo ambiente Google Cloud sia soggetta ai controlli dell'accesso IAM, esiste il rischio che i dati possano essere accessibili utilizzando credenziali rubate, esfiltrati da insider malintenzionati o codice compromesso o esposti tramite un criterio IAM configurato in modo errato.

Controlli di servizio VPC è una soluzione che affronta questi rischi. Tuttavia, i Controlli di servizio VPC introducono anche complessità nel modello di accesso, pertanto devi progettarli in modo che soddisfino il tuo ambiente e il tuo caso d'uso unici.

Le sezioni seguenti 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 descritte 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 nel tuo ambiente

Ti consigliamo di progettare il tuo ambiente all'interno di uno o più perimetri dei Controlli di servizio VPC che limitano tutte le API supportate. Configura eccezioni al perimetro con livelli di accesso o policy 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 i Controlli di servizio VPC e i tuoi workload non richiedono l'accesso a internet senza limitazioni.
  • Archivi dati sensibili su 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 tuoi carichi di lavoro richiedono l'accesso a internet senza limitazioni 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 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, potresti 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 intorno a questi progetti e definire regole di ingresso e 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 l'ingresso dal traffico utente potrebbe essere un progetto al di fuori del perimetro, mentre il livello applicazione e il livello dati che contengono dati sensibili potrebbero essere progetti separati all'interno del perimetro di servizio. Definisci le regole in entrata e in uscita per il perimetro in modo che i livelli possano comunicare tra loro con un accesso granulare.

Utilizza questa opzione quando si verifica quanto segue:

  • 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 quando molti progetti potrebbero contenere dati sensibili.

Per saperne di più, consulta 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 il sovraccarico operativo supera il valore dei Controlli di servizio VPC.

Ad esempio, la tua organizzazione potrebbe non avere un pattern coerente di accesso degli sviluppatori che potrebbe costituire la base di una policy di ingresso. Forse le tue operazioni IT sono esternalizzate a più terze parti, quindi gli sviluppatori non hanno dispositivi gestiti o accesso da indirizzi IP coerenti. In questo scenario, potresti non essere in grado di definire regole in entrata 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 quando hai dati sensibili nel tuo ambiente Google Cloud.

Decidere come monitorare continuamente le configurazioni non sicure e le minacce

L'adozione di servizi cloud introduce nuove sfide e minacce rispetto all'utilizzo di servizi on-premise. Gli strumenti esistenti che monitorano i server a lunga durata potrebbero non essere adatti ai servizi di scalabilità automatica o effimeri 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 gli standard cloud, come il CIS Benchmark 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 descritte 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

Ti consigliamo di attivare Security Command Center a livello di organizzazione, il che ti aiuta a rafforzare la tua postura di sicurezza facendo quanto segue:

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

Quando abiliti Security Command Center all'inizio della creazione 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 tuo team responsabile della sicurezza a valutare se la landing zone soddisfa i requisiti e se è pronta per consentire agli sviluppatori di iniziare a eseguire il deployment delle applicazioni.

Utilizza questa opzione quando si verifica quanto segue:

  • Vuoi uno strumento di gestione della postura di sicurezza e di rilevamento delle minacce integrato con tutti i servizi Google Cloud senza ulteriore impegno di integrazione.
  • Vuoi utilizzare la stessa intelligence sulle minacce, lo stesso machine learning e gli stessi metodi avanzati che Google utilizza per proteggere i propri servizi.
  • Il tuo Security Operations Center (SOC) esistente non dispone delle competenze o della capacità di generare approfondimenti sulle minacce da un volume elevato di log cloud.

Evita questa opzione quando i tuoi 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

In alternativa all'utilizzo di Security Command Center, puoi prendere in considerazione altri strumenti di gestione della postura di sicurezza del cloud. Esistono vari strumenti di terze parti con funzioni simili a Security Command Center e potresti aver già investito in strumenti nativi del cloud incentrati su ambienti multicloud.

Puoi anche utilizzare Security Command Center e strumenti di terze parti insieme. Ad esempio, puoi importare le notifiche dei risultati da Security Command Center in un altro strumento oppure puoi aggiungere un servizio di sicurezza di terze parti alla dashboard di Security Command Center. Un altro esempio è il requisito di archiviare i log in un sistema SIEM esistente affinché il team SOC possa analizzarli per rilevare minacce. Puoi configurare il tuo SIEM esistente per 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 i tuoi 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 quando si verifica quanto segue:

  • Il tuo SOC esistente non dispone delle competenze o della capacità di generare informazioni sulle minacce dall'enorme volume di log cloud.
  • L'integrazione di più strumenti di terze parti con più servizi Google Cloud introduce una complessità maggiore rispetto al valore.

Per ulteriori informazioni, consulta le seguenti risorse:

Decidi come aggregare centralmente i log necessari

La maggior parte dei log di controllo viene archiviata nel progetto Google Cloud che li ha generati. Man mano che il tuo ambiente cresce, può diventare insostenibile per un revisore controllare i log in ogni singolo progetto. Pertanto, devi decidere come centralizzare e aggregare i log per facilitare le operazioni di controllo e sicurezza interni.

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 descritte 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 i sink di log aggregati

Ti consigliamo di configurare un sink di log centralizzato a livello di organizzazione per i log di controllo e 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 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 che i tuoi utenti creano in modo che possa monitorare e analizzare modifiche sospette. Il team di sicurezza richiede anche un record immutabile dell'accesso ai dati per determinati carichi di lavoro altamente sensibili. Pertanto, il team di sicurezza configura un sink di log per aggregare gli audit log dell'attività dell'amministratore di tutti i progetti in un bucket Log Analytics in un progetto centrale che può visualizzare per indagini improvvisate. Quindi, configurano un secondo sink di log per gli audit log di accesso ai dati dai 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 tuo team di sicurezza si aspetta un record centrale di tutti gli audit log o di altri tipi di log specifici.
  • Il tuo team di sicurezza deve archiviare i log in un ambiente con accesso limitato, al di fuori del controllo del workload o dei team che hanno prodotto il log.

Evita questa opzione quando si verifica quanto segue:

  • La tua organizzazione non ha un requisito centrale per audit log coerenti tra i carichi di lavoro.
  • I singoli proprietari del progetto 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 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 di questo sink in un'altra piattaforma al di fuori diGoogle Cloud per archiviare e analizzare i log.

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

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

Utilizza questa opzione quando devi archiviare i log di tutti gli ambienti e dei provider cloud in un'unica posizione centrale.

Evita questa opzione quando si verifica quanto segue:

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

Per saperne di più, consulta la sezione 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 tuoi contenuti archiviati inattivi utilizzando uno o più meccanismi di crittografia. A seconda dei tuoi requisiti di conformità, potresti avere l'obbligo di gestire personalmente 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 descritte 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 dei dati inattivi predefinita è sufficiente per molti casi d'uso che non hanno particolari requisiti di conformità 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 vengano criptati quando sono inattivi. Non hanno requisiti normativi in merito alla gestione delle chiavi e, dopo aver esaminato crittografia at-rest dei dati inattivi predefinita di Google, sono soddisfatti del fatto che sia un controllo sufficiente per le loro esigenze.

Utilizza questa opzione quando si verifica quanto segue:

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

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

Per saperne di più, consulta Crittografia at-rest 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 at-rest all'interno di un progetto Google Cloud . Cloud Key Management Service (Cloud KMS) offre la possibilità di proteggere i tuoi dati utilizzando le chiavi di crittografia gestite dal cliente (CMEK). Ad esempio, nel settore dei servizi finanziari, potresti avere l'obbligo di comunicare ai tuoi 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 la 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 da CSEK ora vengono gestiti meglio da Cloud External Key Manager (Cloud EKM) perché Cloud EKM supporta più servizi e ha una disponibilità maggiore.

Questa opzione trasferisce parte della responsabilità agli sviluppatori di applicazioni 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 le policy 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 quando si verifica quanto segue:

  • Non hai requisiti particolari per la modalità di crittografia dei dati o per la gestione delle chiavi di crittografia.
  • Preferisci un servizio gestito rispetto al costo e al sovraccarico operativo della gestione delle tue chiavi di crittografia.

Per ulteriori informazioni, consulta le seguenti risorse:

Opzione 3: tokenizzare i dati a livello di applicazione prima di renderli persistenti 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 l'accesso ai dati non elaborati, puoi sviluppare una pipeline di importazione con Sensitive Data Protection per importare e tokenizzare i dati sensibili, quindi archiviare i dati tokenizzati in BigQuery.

La tokenizzazione dei dati non è un controllo che puoi applicare centralmente nella landing zone. Questa opzione sposta invece la responsabilità sugli sviluppatori di applicazioni per configurare la propria crittografia o su 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 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 decrittografia aggiuntive aumenta i costi, la latenza e la complessità delle applicazioni.

Per ulteriori informazioni, consulta la panoramica di Sensitive Data Protection.

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

Google Cloud adotta diverse misure di sicurezza volte a garantire l'autenticità, l'integrità e la privacy dei dati in transito. A seconda dei tuoi 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. Le altre opzioni descritte nelle sezioni seguenti sono funzionalità aggiuntive che puoi prendere in considerazione se l'opzione 1 non è sufficiente per il tuo caso d'uso specifico.

Opzione 1: valuta se la Google Cloud crittografia dei dati in transito è sufficiente

Molti pattern di traffico nella tua zona di destinazione traggono vantaggio dalla crittografia dei dati in transito predefinita. Google Cloud

  • Le connessioni da VM a VM all'interno delle reti VPC e delle reti VPC in peering che si trovano all'interno della rete di produzione di Google sono protette dall'integrità e criptate.

  • Il traffico da internet ai servizi Google e il traffico dalla tua rete VPC ai servizi Google terminano nel Google Front End (GFE). GFE esegue anche le seguenti operazioni:

    • Fornisce contromisure contro gli attacchi DDoS
    • Instrada e bilancia il carico del traffico ai servizi Google Cloud

  • L'infrastruttura di Google utilizza ALTS per l'autenticazione, l'integrità e la crittografia delle connessioni dal GFE a un servizio Google Cloud e da un servizioGoogle Cloud a un altro Google Cloud .

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

Aggiungi una protezione aggiuntiva quando si verifica quanto segue:

  • Consenti il traffico in entrata da internet nella tua rete VPC.
  • Ti stai connettendo al tuo ambiente on-premise.

In questi casi, devi configurare controlli aggiuntivi, come descritto in Opzione 2: richiedi alle applicazioni di configurare la crittografia di livello 7 in transito e Opzione 3: configura la crittografia aggiuntiva per l'ambiente on-premise.

Per saperne di più sulla crittografia in transito predefinita di Google Cloud , consulta Crittografia in transito inGoogle Cloud.

Opzione 2: configura la crittografia aggiuntiva per il traffico da o verso le applicazioni dei clienti

Oltre alla crittografia predefinita in transito, puoi configurare la crittografia di livello 7 per il traffico delle applicazioni verso le tue applicazioni cliente. Google Cloud fornisce servizi gestiti per supportare le applicazioni che richiedono la crittografia in transito a livello di applicazione, inclusi i certificati gestiti 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 unico indirizzo IP.

La crittografia a livello di applicazione non è un controllo che puoi applicare centralmente nella landing zone. Questa opzione, invece, sposta parte della responsabilità della configurazione della crittografia dei dati in transito sugli sviluppatori di applicazioni.

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:

Opzione 3: configura la crittografia aggiuntiva per l'ambiente on-premise

Se hai bisogno di una connessione da Google Cloud al tuo ambiente on-premise, puoi configurare Cloud Interconnect, che configura una connessione fisica diretta tra Google Cloud e i tuoi data center. Quando utilizzi Cloud Interconnect, il traffico dal tuo ambiente on-premise a Google Cloud non viene criptato in transito per impostazione predefinita. Pertanto, se utilizzi Cloud Interconnect, ti consigliamo di abilitare MACsec per Cloud Interconnect come parte della tua landing zone.

Se utilizzi la VPN ad alta disponibilità per connettere il traffico privato tra Google Cloud e i tuoi data center, il traffico utilizza la crittografia IPsec per impostazione predefinita.

Per saperne di più, consulta la sezione Scegliere un prodotto Network Connectivity Center.

Decidi quali controlli aggiuntivi sono necessari per gestire l'accesso del fornitore di servizi cloud

La necessità di controllare l'accesso del cloud service provider (CSP) può essere 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 la gestione dell'accesso CSP. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. L'altra opzione descritta 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 Google Cloud nel tuo ambiente, ad esempio quando risolve un problema relativo a 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 i problemi del suo 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 le ha giustificate.

Utilizza questa opzione quando si verifica quanto segue:

  • Devi verificare che il personale acceda ai tuoi contenuti solo per motivi aziendali validi, ad esempio per risolvere un'interruzione o rispondere alle tue richieste di assistenza. Google Cloud
  • Devi rispettare 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 fornitore

Se la tua attività ha un 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 i tecnici di Google richiedano la tua approvazione esplicita (tramite email o 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 quando si verifica quanto segue:

  • Vuoi che un team centrale gestisca direttamente l'accesso ai tuoi contenuti da parte del personale di Google.
  • Per l'approvazione dell'accesso, puoi accettare il rischio che la funzionalità 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 le giustificazioni dell'accesso alle chiavi, la tua attività utilizza già Cloud External Key Manager nell'ambito della strategia di crittografia e vuole un controllo programmatico su tutti i tipi di accesso ai dati criptati (non solo l'accesso del personale Google ai dati).

Evita questa opzione quando si verifica quanto segue:

  • Il ritardo operativo che può verificarsi quando un team centrale con l'autorità di approvazione dell'accesso deve rispondere è un rischio inaccettabile per i workload che richiedono un'alta disponibilità e una risposta rapida da parte dell'assistenza clienti.

Per ulteriori informazioni, consulta le seguenti risorse:

Best practice per la sicurezza per le Google Cloud landing zone

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

Passaggi successivi