Decidere la sicurezza per la tua zona di destinazione Google Cloud

Last reviewed 2023-08-31 UTC

Questo documento introduce importanti decisioni sulla sicurezza e opzioni consigliate per devi considerare quando progetti una zona di destinazione di 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, applica queste zone di destinazione i controlli di sicurezza. Questo documento è incentrato sulla progettazione ambienti di livello enterprise, alcune strategie che descrivono potrebbero essere meno pertinente 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 aiuta a mitigare i rischi di lunga durata le credenziali dell'account di servizio.
  • 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 per rilevare configurazioni e minacce non sicure.
  • 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 per i dati in transito si applica ai percorsi di rete di livello 3 e 4.
  • Access Transparency ti offre visibilità e controllo sulle modalità di accesso a Google del tuo ambiente.

Decidi 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 accidentalmente il commit della chiave dell'account di servizio in un repository Git pubblico, un utente malintenzionato esterno può eseguire l'autenticazione usando e 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 attuabili alternative, limitare la proliferazione delle credenziali persistenti e e gestire il modo in cui vengono utilizzati. 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. Me consiglia l'opzione 1 per la maggior parte dei casi d'uso. Le altre opzioni illustrate nel le sezioni seguenti sono alternative che puoi prendere in considerazione se l'opzione 1 non si applicano alla tua organizzazione specifica.

Opzione 1: limita l'utilizzo delle chiavi dei service account 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. Limitazione dell'uso di etichette le chiavi dell'account di servizio sono un'opzione che può aiutare a ridurre il rischio e l'overhead la gestione manuale delle chiavi degli account di servizio.

Per implementare questa opzione, considera quanto segue:

Evita questa opzione quando hai già strumenti per generare le 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 strumenti personalizzati o utilizzare 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 il controllo degli accessi o se disponi di budget e capacità sufficienti per sviluppare la tua soluzione.

Evita di utilizzare questa opzione quando non disponi di strumenti esistenti per concedere credenziali di breve durata o che non hanno la capacità di crearne di proprie soluzione.

Per ulteriori informazioni, vedi 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, 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, anche i Controlli di servizio VPC introduce la complessità del modello di accesso, quindi è necessario progettare Controlli di servizio VPC per soddisfare le esigenze di ambiente e caso d'uso unici.

Le sezioni seguenti descrivono le opzioni per ridurre l'esfiltrazione dei 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 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 il tuo ambiente in 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 carichi di lavoro non richiedono l'accesso a internet senza restrizioni.
  • Archivi su Google Cloud dati sensibili che potrebbero rappresentare una perdita significativa se vengono trafugati.
  • Hai attributi coerenti per l'accesso sviluppatore che possono essere configurate come eccezioni al perimetro, consentendo agli utenti di accedere i 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 I progetti contengono 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, potrebbero trovarsi al di fuori del perimetro. Il livello di presentazione che consente in entrata dal traffico degli utenti potrebbe essere un progetto al di fuori del perimetro il livello di applicazione e il livello dati che contengono dati sensibili potrebbero essere separati 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 quando si verifica quanto segue:

  • Solo i progetti limitati e ben definiti contengono dati sensibili. Altro i progetti contengono dati a rischio inferiore.
  • Alcuni carichi di lavoro sono solo interni, ma altri richiedono accesso a internet pubblico o hanno dipendenze da servizi non supportati da VPC Service Controls.
  • 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 contenuti sensibili e i dati di Google Cloud.

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. Magari il tuo reparto IT operazioni sono affidate a più terze parti, per cui gli sviluppatori non devono dispositivi gestiti o 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 hai dati sensibili in Google Cloud completamente gestito di Google Cloud.

Decidere come monitorare continuamente le configurazioni e le 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. Inoltre, devi monitorare continuamente la presenza di standard cloud sicuri, come i benchmark CIS 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 illustrate nel le sezioni seguenti sono alternative che puoi prendere in considerazione se l'opzione 1 non si applicano 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, in modo da rafforzare la tua strategia di sicurezza svolgendo 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
  • Aiutarti a mitigare e risolvere i rischi

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

Utilizza questa opzione se si verificano le seguenti condizioni:

  • Vuoi uno strumento di gestione della security posture e rilevamento delle minacce che sia integrati con tutti i servizi Google Cloud senza ulteriori delle attività di integrazione.
  • Vuoi usare le stesse informazioni sulle minacce, lo stesso machine learning e altri metodi avanzati utilizzati da Google per proteggere i propri servizi.
  • Il tuo attuale centro operativo di sicurezza (SOC) non dispone delle competenze necessarie o capacità di generare insight sulle minacce da un grande volume di log del cloud.

Evita questa opzione quando i tuoi strumenti di sicurezza esistenti possono gestire completamente le attività temporanee o serverless, monitorare le configurazioni non sicure e identificare 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 a Utilizza il livello Premium di Security Command Center. puoi prendere in considerazione altri strumenti di gestione della security posture 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 insieme a strumenti di terze parti. 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. Per fare un altro esempio, potresti avere un requisito per memorizzare i log su un sistema SIEM esistente in modo che il team SOC possa analizzarli in modo proattivo. 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 scala in un ambiente cloud.

Evita questa opzione quando si verifica quanto segue:

  • Il tuo SOC esistente non ha le competenze o la capacità di generare informazioni sulle minacce dal vasto volume di log cloud.
  • Integrazione di più strumenti di terze parti con più strumenti Google Cloud e 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. Devi quindi decidere le modalità di archiviazione dei log centralizzate e aggregate per facilitare i processi di controllo e sicurezza interni operazioni aziendali.

Le sezioni seguenti descrivono le opzioni per l'aggregazione dei log. I nostri suggerimenti l'opzione 1 per la maggior parte dei casi d'uso. Le altre opzioni illustrate di seguito sono alternative che puoi prendere in considerazione se l'opzione 1 non si applica per il tuo caso d'uso specifico.

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

Ti consigliamo di configurare un'area di destinazione dei log centralizzata per tutta l'organizzazione per gli audit log e altri log richiesti dal team di sicurezza. Puoi fare riferimento al strumento di definizione dell'ambito dei log per identificare i log richiesti dal team di sicurezza e se tali log che richiedono l'abilitazione esplicita.

Ad esempio, il team di sicurezza si aspetta un registro centrale di tutte le risorse creati dai tuoi utenti, in modo che il team di sicurezza possa monitorare e analizzare 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 un'area di destinazione dei 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 punto di destinazione 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 quando si verifica quanto segue:

  • Il team di sicurezza si aspetta un record centrale di tutti gli audit log o di altre 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 hanno la piena responsabilità di gestire e gli audit log.

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 a l'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 esterna a Google Cloud per archiviare e analizzare i log.

Ad esempio, potresti utilizzare una piattaforma SIEM di terze parti per aggregare e analizzare i dati tra più cloud provider. 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 traffico di rete in uscita costo in Google Cloud, nonché il costo e la capacità di archiviazione in un altro ambiente. Anziché esportare ogni log disponibile, è consigliabile devi selezionare con cura i log richiesti nell'ambiente esterno.

Utilizza questa opzione quando hai la necessità di archiviare i log di tutti gli ambienti e cloud provider 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, vedi Controlli di rilevamento. nel progetto delle basi aziendali.

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

Le sezioni seguenti descrivono le opzioni per la crittografia dei dati inattivi. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. Le altre opzioni illustrate nel le sezioni seguenti sono alternative che puoi prendere in considerazione se l'opzione 1 non si applicano 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 lato client predefinita di Google, ritengono 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 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 quando devi gestire requisiti di conformità 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 a crittografia at-rest predefinita, potresti aver bisogno di un maggiore controllo sulle chiavi utilizzate per criptare i dati at-rest 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 avere la necessità di segnalare dai revisori esterni in che modo gestisci le tue chiavi di crittografia per dati sensibili e i dati di Google Cloud.

Per ulteriori livelli di controllo, puoi configurare i moduli di sicurezza hardware (HSM) o gestione delle chiavi esterne (EKM) con CMEK. Crittografia fornita dal cliente (CSEK) non sono consigliate; di scenari che storicamente sono stati affrontati Le CSEK ora vengono gestite meglio da Cloud External Key Manager (Cloud EKM) perché Cloud EKM supporta più servizi e una maggiore disponibilità.

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

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

  • Hai un requisito per 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 della chiave di crittografia al di fuori Google Cloud con 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 applicazione prima di conservarli nello spazio di archiviazione

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

Ad esempio, un data scientist deve analizzare un set di dati con informazioni PII, data scientist non deve avere accesso per leggere i dati non elaborati di campi. Per limitare l'accesso del controllo ai dati non elaborati, puoi sviluppare un'importazione pipeline con Sensitive Data Protection 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 destinazione zona di destinazione. Questa opzione trasferisce invece la responsabilità agli sviluppatori di applicazioni per configurare la propria crittografia o a un team della piattaforma che sviluppa una la pipeline di crittografia come servizio condiviso per gli sviluppatori di applicazioni.

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

Evita questa opzione quando Cloud KMS è sufficiente per soddisfare le tue 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, 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. In base di sicurezza e conformità, potresti anche configurare il livello dell'applicazione la crittografia.

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 nel le sezioni seguenti sono 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 ulteriori configurazioni. Tutto il traffico da VM a VM all'interno di un VPC e le reti VPC connesse sono criptate a livello 3 o 4. Il traffico proveniente da internet e diretto ai servizi Google termina nel 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
  • 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 per i servizi utilizzeranno automaticamente la crittografia in transito. Non è necessario configurare crittografia aggiuntiva in transito per la crittografia del traffico.

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

Evita questa opzione se si verifica quanto segue:

  • Richiedi la crittografia per tutto il traffico su Cloud Interconnect.
  • Consenti il traffico internet in entrata nella tua rete VPC.
  • Hai bisogno della crittografia di livello 7 in transito tra tutte le risorse di elaborazione interna Google Cloud.

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 a crittografia predefinita in transito, puoi configurare la crittografia di livello 7 per il traffico delle applicazioni. Google Cloud fornisce per supportare le applicazioni che necessitano della 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. Usano un bilanciatore del carico delle applicazioni esterno con certificati SSL gestiti da Google per eseguire e scalare servizi dietro con un singolo indirizzo IP.

La crittografia a livello di applicazione non è un controllo che puoi applicare centralmente la 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 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, la modernizzazione delle applicazioni legacy prima della migrazione potrebbe ritardo non accettabile 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 provider di servizi cloud (CSP) può rappresentare un problema durante l'adozione del cloud. Google Cloud fornisce più livelli di controllo per abilitare verifica dell'accesso del provider cloud.

Le seguenti sezioni descrivono le opzioni per la gestione dell'accesso CSP. Me consiglia 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

Trasparenza degli accessi log registrano le azioni intraprese dal personale Google Cloud nel tuo ambiente, come quando risolvono una richiesta di assistenza.

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

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.
  • 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 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.

Motivazioni per l'accesso alle chiavi è una soluzione programmatica che aggiunge un campo di giustificazione a qualsiasi richiesta che sono configurate con Cloud EKM.

Utilizza questa opzione quando si verifica quanto segue:

  • Vuoi che un team centrale gestisca direttamente l'accesso al personale di Google ai tuoi contenuti.
  • Per Access Approval, puoi accettare il rischio che è più importante poter approvare o rifiutare ogni richiesta di accesso. rispetto al compromesso operativo, il che potrebbe comportare una risoluzione più lenta 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 verifica quanto segue:

  • Il ritardo operativo che può verificarsi quando un team centrale L'autorità di Access Approval deve rispondere è una risposta inaccettabile a carichi di lavoro che richiedono un'alta disponibilità e una risposta rapida 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