Questo documento introduce importanti decisioni sulla sicurezza e le opzioni consigliate da considerare durante la progettazione di una zona di destinazione Google Cloud. Fa parte di una serie sulle zone di destinazione ed è rivolta agli esperti della sicurezza, ai CISO e agli architetti che vogliono comprendere le decisioni da prendere quando progettano 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 della zona di destinazione. Poiché l'argomento principale di questo documento è la progettazione di ambienti su scala aziendale, alcune strategie che descrive potrebbero essere meno rilevanti per i piccoli team.
Punti decisionali per la protezione della tua zona di destinazione Google Cloud
Per scegliere la migliore progettazione di sicurezza per la tua organizzazione, devi prendere le seguenti decisioni:
Come limitare le credenziali permanenti per gli account di servizio
Come mitigare l'esfiltrazione di dati tramite le API di Google
Come monitorare continuamente configurazioni e minacce non sicure
Come soddisfare i requisiti di conformità per la crittografia at-rest
Come soddisfare i requisiti di conformità per la crittografia dei dati in transito
Quali controlli aggiuntivi sono necessari per gestire l'accesso del provider di servizi cloud
Diagramma dell'architettura
L'architettura di esempio descritta in questo documento utilizza pattern di progettazione di sicurezza comuni. I controlli specifici possono variare in base a fattori come il settore dell'organizzazione, i carichi di lavoro target o ulteriori requisiti di conformità. Il seguente diagramma mostra l'architettura dei controlli di sicurezza che applichi nella tua zona di destinazione quando segui i suggerimenti contenuti in questo documento.
Il diagramma precedente mostra quanto segue:
- La gestione delle chiavi dell'account di servizio aiuta a ridurre il rischio derivante dalle credenziali degli account di servizio di lunga durata.
- 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 individuare 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 su disco.
- La crittografia predefinita di Google in transito si applica ai percorsi di rete di livello 3 e 4.
- Access Transparency ti offre visibilità e controllo sulle modalità di accesso di Google al tuo ambiente.
Decidi come limitare le credenziali permanenti per gli account di servizio
Gli account di servizio sono identità macchina che utilizzi per concedere ruoli IAM ai carichi di lavoro e consentire al carico di lavoro di accedere alle API Google Cloud. Una chiave dell'account di servizio è una credenziale permanente e qualsiasi credenziale permanente è potenzialmente ad alto rischio. Sconsigliamo di consentire agli sviluppatori di creare liberamente chiavi degli account di servizio.
Ad esempio, se uno sviluppatore esegue il commit accidentale della chiave dell'account di servizio in un repository Git pubblico, un utente malintenzionato esterno può eseguire l'autenticazione utilizzando quelle credenziali. Per fare un altro esempio, se la chiave dell'account di servizio è archiviata in un repository interno, un utente malintenzionato interno al dominio che può leggerla potrebbe utilizzare le credenziali per riassegnare i propri privilegi Google Cloud.
Per definire una strategia per la gestione di queste credenziali permanenti, devi fornire alternative valide, limitare la proliferazione delle credenziali permanenti e gestirne l'utilizzo. Per informazioni sulle alternative alle chiavi degli account di servizio, consulta Scegliere il metodo di autenticazione ottimale per il caso d'uso.
Le seguenti sezioni descrivono le opzioni per limitare le credenziali permanenti. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. Le altre opzioni illustrate nelle seguenti sezioni sono alternative che puoi prendere in considerazione se l'opzione 1 non si applica alla tua organizzazione specifica.
Opzione 1: limita l'utilizzo di chiavi degli account di servizio permanenti
Ti consigliamo di non consentire ad alcun utente di scaricare le chiavi degli account di servizio perché le chiavi compromesse sono un vettore di attacco comune. La limitazione dell'uso delle chiavi degli account di servizio permanenti è un'opzione che può aiutare a ridurre i rischi e l'overhead associati alla gestione manuale delle chiavi degli account di servizio.
Per implementare questa opzione, considera quanto segue:
- Per impedire agli sviluppatori di creare e scaricare credenziali permanenti, configura il vincolo dei criteri dell'organizzazione
constraints/iam.disableServiceAccountKeyCreation. - Forma i tuoi team su alternative più sicure alle chiavi degli account di servizio. Ad esempio, quando gli utenti e le applicazioni al di fuori del tuo ambiente Google Cloud devono utilizzare un account di servizio, possono eseguire l'autenticazione con l'impersonificazione degli account di servizio o con la federazione delle identità per i carichi di lavoro anziché con una chiave dell'account di servizio.
- Progetta un processo per consentire ai team di richiedere un'eccezione a questo criterio quando il download di una chiave dell'account di servizio è l'unica opzione valida. Ad esempio, un prodotto SaaS di terze parti potrebbe richiedere una chiave dell'account di servizio per leggere i log del tuo ambiente Google Cloud.
Evita questa opzione quando disponi già di strumenti per generare credenziali API di breve durata per gli account di servizio.
Per ulteriori informazioni, consulta le seguenti risorse:
- Vincoli dei criteri dell'organizzazione nel progetto delle basi aziendali di Google Cloud
- Best practice per lavorare con gli account di servizio
Opzione 2: utilizza strumenti di gestione degli accessi aggiuntivi per generare credenziali di breve durata
In alternativa a Limitare l'utilizzo di chiavi degli account di servizio permanenti, puoi generare credenziali di breve durata per gli account di servizio. Le credenziali di breve durata creano meno rischi rispetto alle credenziali permanenti, come le chiavi degli account di servizio. Puoi sviluppare i tuoi strumenti o utilizzare soluzioni di terze parti come Hashicorp Vault per generare credenziali di accesso a breve durata.
Utilizza questa opzione se hai già investito in uno strumento di terze parti per generare credenziali di breve durata per controllo dell'accesso o se disponi di budget e capacità sufficienti per sviluppare la tua soluzione.
Evita di utilizzare questa opzione se non disponi di strumenti esistenti per concedere credenziali di breve durata o se non hai la capacità di creare una soluzione personalizzata.
Per ulteriori informazioni, consulta la sezione Creazione di credenziali per gli account di servizio di breve durata.
Decidi come ridurre 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 ai controlli di accesso IAM, esiste il rischio che i dati siano accessibili utilizzando credenziali rubate, esfiltrate da addetti ai lavori malintenzionati o codice compromesso, o esposte tramite un criterio IAM configurato in modo errato.
Controlli di servizio VPC è una soluzione che risolve questi rischi. Tuttavia, i Controlli di servizio VPC introducono anche complessità nel tuo modello di accesso, per cui devi progettarli per soddisfare il tuo ambiente e il tuo caso d'uso specifici.
Le seguenti sezioni descrivono le opzioni per mitigare l'esfiltrazione di dati tramite le API di Google. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. Le altre opzioni 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 ampio in tutto l'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 livelli di accesso o criteri in entrata in modo che gli sviluppatori possano accedere ai servizi di cui hanno bisogno, incluso l'accesso alla console se necessario.
Utilizza questa opzione quando si verifica quanto segue:
- I servizi che intendi utilizzare supportano i Controlli di servizio VPC e i tuoi carichi di lavoro non richiedono un accesso a internet senza restrizioni.
- Hai archiviato 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, in modo che gli utenti possano accedere ai dati di cui hanno bisogno.
Evita questa opzione quando i tuoi carichi di lavoro richiedono un accesso a internet senza restrizioni o servizi non supportati dai Controlli di servizio VPC.
Per ulteriori informazioni, consulta le seguenti risorse:
- Best practice per abilitare i Controlli di servizio VPC
- Prodotti supportati e limitazioni per i Controlli di servizio VPC
- Progetta e progetta i perimetri di servizio
Opzione 2: configura i Controlli di servizio VPC per un sottoinsieme del tuo ambiente
Anziché configurare i Controlli di servizio VPC in modo ampio nell'ambiente, puoi configurarli solo nel sottoinsieme di progetti che contengono dati sensibili e carichi di lavoro esclusivamente 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 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 fare un altro esempio, in un'applicazione con architettura a tre livelli alcuni componenti potrebbero essere al di fuori del perimetro. Il livello di presentazione che consente il traffico in entrata dal traffico degli utenti potrebbe essere un progetto all'esterno del perimetro, mentre il livello di applicazione e il livello dati che contengono dati sensibili potrebbero essere progetti separati all'interno del perimetro di servizio. Puoi definire le regole per il traffico in entrata e in uscita verso il perimetro, in modo che i livelli possano comunicare attraverso il perimetro con un accesso granulare.
Utilizza questa opzione quando si verifica quanto segue:
- Solo i progetti limitati e ben definiti contengono dati sensibili. Altri progetti contengono dati a basso rischio.
- Alcuni carichi di lavoro sono solo per uso interno, ma alcuni richiedono l'accesso a internet pubblico o hanno dipendenze da servizi non supportati dai Controlli di servizio VPC.
- La configurazione dei Controlli di servizio VPC su tutti i progetti crea un sovraccarico o richiede troppe soluzioni alternative
Evita questa opzione quando 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 ulteriore alternativa alla configurazione dei Controlli di servizio VPC in tutto l'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 modello coerente di accesso degli sviluppatori che potrebbe costituire la base di un criterio in entrata. È possibile che le tue operazioni IT siano affidate in outsourcing 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 necessario agli sviluppatori per completare le operazioni quotidiane.
Utilizza questa opzione quando:
- Utilizzi servizi che non supportano i Controlli di servizio VPC.
- I carichi di lavoro sono per internet e non contengono dati sensibili.
- Non hai attributi coerenti di accesso degli sviluppatori, come dispositivi gestiti o intervalli IP noti.
Evita questa opzione se nel tuo ambiente Google Cloud sono presenti dati sensibili.
Decidi come monitorare continuamente configurazioni e minacce non sicure
L'adozione di servizi cloud introduce nuove sfide e minacce rispetto all'uso 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 le risorse serverless. Dovresti quindi valutare gli strumenti di sicurezza che funzionano con l'intera gamma di servizi cloud che potresti adottare. Dovresti anche monitorare costantemente gli standard del cloud sicuro, come i CIS Benchmarks per Google Cloud.
Le seguenti sezioni descrivono le opzioni disponibili per il monitoraggio continuo. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. Le altre opzioni illustrate 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 Premium
Ti consigliamo di attivare il livello Premium di Security Command Center a livello di organizzazione, per rafforzare la tua strategia di sicurezza seguendo questi passaggi:
- Valutare la superficie di attacco per dati e sicurezza
- Fornire inventario e scoperta degli asset
- Identificazione di errori di configurazione, vulnerabilità e minacce
- Aiutandoti a ridurre e risolvere i rischi
Quando abiliti Security Command Center all'inizio della build della zona di destinazione, il team di sicurezza della tua organizzazione ha una visibilità quasi in tempo reale su configurazioni non sicure, minacce e opzioni di correzione. Questa visibilità aiuta il tuo team di sicurezza a valutare se la zona di destinazione soddisfa i loro requisiti ed è pronta per gli sviluppatori per 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 ulteriori sforzi di integrazione.
- Vuoi usare la stessa intelligence sulle minacce, il machine learning e altri metodi avanzati che Google usa per proteggere i suoi servizi.
- Il tuo Security Operations Center (SOC) esistente non ha le competenze o la capacità per generare insight sulle minacce da un grande volume di log cloud.
Evita questa opzione quando gli strumenti di sicurezza esistenti sono in grado di gestire completamente le risorse cloud temporanee o serverless, monitorare le configurazioni non sicure e identificare le minacce su larga fare lo scale in un ambiente cloud.
Opzione 2: utilizza i tuoi strumenti di sicurezza esistenti per la gestione della postura di sicurezza nel cloud e il rilevamento delle minacce
In alternativa all'utilizzo del livello Premium di Security Command Center, puoi prendere in considerazione altri strumenti di gestione della strategia di sicurezza cloud. Esistono vari strumenti di terze parti che hanno funzioni simili a Security Command Center e potresti aver già investito in strumenti cloud-native incentrati su ambienti multi-cloud.
Puoi anche utilizzare Security Command Center e strumenti di terze parti insieme. Ad esempio, potresti importare le notifiche di rilevamento da Security Command Center a 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 il requisito di archiviare i log su un sistema SIEM esistente affinché il team SOC possa analizzare le minacce. Potresti configurare il tuo SIEM esistente per importare solo le notifiche di rilevamento generate da Security Command Center, anziché importare un grande volume di log e aspettare che un team SOC analizzi i log non elaborati per ricavarne insight.
Utilizza questa opzione quando gli strumenti di sicurezza esistenti sono in grado di gestire completamente le risorse cloud temporanee o serverless, monitorare le configurazioni non sicure e identificare le minacce su larga fare lo scale in un ambiente cloud.
Evita questa opzione se si verifica quanto segue:
- Il tuo SOC esistente non ha le competenze o la capacità per generare insight sulle minacce dall'enorme volume di log cloud.
- L'integrazione di più strumenti di terze parti con più servizi Google Cloud introduce più complessità che valore.
Per ulteriori informazioni, consulta le seguenti risorse:
Decidi come aggregare centralmente i log necessari
La maggior parte degli audit log è archiviata nel progetto Google Cloud che li ha generati. Man mano che l'ambiente cresce, potrebbe essere impossibile per un revisore controllare i log di ogni singolo progetto. Pertanto, devi prendere una decisione su come i log verranno centralizzati e aggregati per agevolare le operazioni di controllo e sicurezza interne.
Le seguenti sezioni descrivono le opzioni per l'aggregazione dei log. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. Le altre opzioni illustrate 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 sink di log aggregati
Ti consigliamo di configurare un sink di log centralizzato a livello di organizzazione per i log di controllo e gli altri log richiesti dal team di sicurezza. Puoi fare riferimento allo strumento di definizione dell'ambito dei log per identificare i log richiesti dal team di sicurezza e se questi tipi di log richiedono l'abilitazione esplicita.
Ad esempio, il team di sicurezza si aspetta un record centrale di tutte le risorse create dagli utenti, in modo che possa monitorare ed esaminare eventuali 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 per la sicurezza configura un sink di log per aggregare gli audit log delle attività di amministrazione di tutti i progetti in un bucket di analisi dei log in un progetto centrale che può visualizzare per indagini estemporanee. Quindi configura un secondo sink di log per gli audit log degli accessi ai dati provenienti 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 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 prodotto il log.
Evita questa opzione se si verifica quanto segue: - La tua organizzazione non ha un requisito centrale di audit log coerenti tra carichi di lavoro. - I singoli proprietari del progetto hanno la piena responsabilità della gestione dei propri audit log.
Per ulteriori informazioni, consulta le seguenti risorse:
- Controlli di rilevamento nel progetto delle fondamenta aziendali
- Best practice per Cloud Audit Logs
- Configura i sink aggregati
- Strumento di definizione dell'ambito dei log
- Criteri di conservazione e blocchi dei criteri di conservazione
Opzione 2: esporta gli audit log richiesti in uno spazio di archiviazione all'esterno di Google Cloud
In alternativa all'archiviazione dei log solo in Google Cloud, valuta la possibilità di esportare gli audit log al di fuori di Google Cloud. Dopo aver centralizzato i tipi di log necessari in un sink di log aggregato in Google Cloud, importa i contenuti di quel sink in un'altra piattaforma esterna a Google Cloud per l'archiviazione e l'analisi dei log.
Ad esempio, potresti utilizzare una piattaforma SIEM di terze parti per aggregare e analizzare gli audit log di più provider cloud. Questo strumento ha capacità sufficienti per lavorare con risorse cloud serverless e il tuo team SOC ha le competenze e la capacità per generare insight da questo grande volume di log.
Questa opzione può essere potenzialmente molto costosa a causa del costo del traffico di rete in uscita in Google Cloud, nonché del costo e della capacità di archiviazione nell'altro ambiente. Anziché esportare ogni log disponibile, ti consigliamo di selezionare con attenzione i log richiesti nell'ambiente esterno.
Utilizza questa opzione quando hai l'esigenza di archiviare i log di tutti gli ambienti e dei cloud provider in un'unica posizione centrale.
Evita questa opzione se si verifica quanto segue:
- I sistemi esistenti non hanno la capacità o il budget per importare un volume elevato di log cloud aggiuntivi.
- I sistemi esistenti richiedono sforzi di integrazione per ogni tipo e formato di log.
- Stai raccogliendo i log senza un obiettivo chiaro di come verranno utilizzati.
Per ulteriori informazioni, consulta le seguenti risorse:
- Controlli di rilevamento nel progetto delle fondamenta aziendali
- Scenari per l'esportazione da Logging: requisiti di conformità
Decidi come soddisfare i requisiti di conformità per la crittografia at-rest
Google Cloud cripta automaticamente tutti i contenuti archiviati a riposo, utilizzando uno o più meccanismi di crittografia. A seconda dei requisiti di conformità, potresti avere l'obbligo di gestire personalmente le chiavi di crittografia.
Le seguenti sezioni descrivono le opzioni per crittografia at-rest. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. Le altre opzioni illustrate 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 at-rest predefinita è sufficiente per molti casi d'uso che non prevedono requisiti di conformità specifici relativi alla gestione delle chiavi di crittografia.
Ad esempio, il team di sicurezza di un'azienda di giochi online richiede che tutti i dati dei clienti siano criptati at-rest. Non hanno requisiti normativi per la gestione delle chiavi e, dopo aver esaminato la crittografia at-rest 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 sulla crittografia dei dati o sulla gestione delle chiavi di crittografia.
- Preferisci un servizio gestito rispetto ai costi e all'overhead operativo della gestione delle tue chiavi di crittografia.
Evita questa opzione se disponi di requisiti di conformità per gestire le tue chiavi di crittografia.
Per ulteriori informazioni, consulta Crittografia at-rest in Google Cloud.
Opzione 2: gestisci le chiavi di crittografia con Cloud KMS
Oltre alla crittografia at-rest predefinita, potresti richiedere un maggiore controllo sulle chiavi utilizzate per criptare i dati at-rest all'interno di un progetto Google Cloud. Cloud Key Management Service (Cloud KMS) offre la possibilità di proteggere i dati utilizzando chiavi di crittografia gestite dal cliente (CMEK). Ad esempio, nel settore dei servizi finanziari, potresti avere l'obbligo di segnalare ai revisori esterni come gestisci le tue chiavi di crittografia per i dati sensibili.
Per ulteriori livelli di controllo, puoi configurare i moduli di sicurezza hardware (HSM) o la gestione delle chiavi esterne (EKM) con CMEK. Le chiavi di crittografia fornite dal cliente (CSEK) non sono consigliate. Gli scenari precedentemente gestiti da CSEK vengono ora gestiti meglio da Cloud External Key Manager (Cloud EKM), in quanto Cloud EKM supporta più servizi e una maggiore disponibilità.
Questa opzione sposta in parte gli sviluppatori di applicazioni di seguire la gestione delle chiavi imposta dal tuo team di sicurezza. Il team di sicurezza può applicare il requisito bloccando la creazione di risorse non conformi con i criteri dell'organizzazione CMEK.
Utilizza questa opzione quando una o più delle seguenti condizioni sono vere:
- Hai un requisito per gestire il ciclo di vita delle tue chiavi.
- Hai un requisito per generare il materiale delle chiavi di crittografia con un HSM certificato FIPS 140-2 livello 3.
- Hai il requisito di archiviare il materiale delle chiavi di crittografia al di fuori di Google Cloud utilizzando Cloud EKM.
Evita questa opzione se si verifica quanto segue:
- Non hai requisiti specifici per la crittografia dei dati o per la gestione delle chiavi di crittografia.
- Preferisci un servizio gestito rispetto ai costi e all'overhead operativo della gestione delle tue chiavi di crittografia.
Per ulteriori informazioni, consulta le seguenti risorse:
- Gestisci le chiavi di crittografia con Cloud Key Management Service nel progetto di base dell'azienda
Opzione 3: tokenizza i dati a livello di applicazione prima che rimangano nello spazio di archiviazione
Oltre alla crittografia predefinita fornita da Google, puoi 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 per leggere i dati non elaborati di alcuni campi sensibili. Per limitare l'accesso di controllo ai dati non elaborati, potresti sviluppare una pipeline di importazione con Sensitive Data Protection per importare e tokenizzare i dati sensibili e poi rendere i dati tokenizzati in modo permanente in BigQuery.
La tokenizzazione dei dati non è un controllo che puoi applicare a livello centrale nella zona di destinazione. Questa opzione sposta invece la responsabilità degli sviluppatori di applicazioni di configurare la propria crittografia o di un team della piattaforma che sviluppa una pipeline di crittografia come servizio condiviso che gli sviluppatori di applicazioni possono utilizzare.
Utilizza questa opzione quando carichi di lavoro specifici 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 con Cloud KMS. Lo spostamento dei dati attraverso pipeline di crittografia e decriptazione aggiuntive aggiunge costi, latenza e complessità alle applicazioni.
Per ulteriori informazioni, consulta le seguenti risorse :
- Panoramica di Sensitive Data Protection
- Assumi il controllo dei tuoi dati: in che modo la tokenizzazione rende i dati utilizzabili senza sacrificare la privacy
Decidi come soddisfare i requisiti di conformità per la crittografia dei dati in transito
Google Cloud dispone di diverse misure di sicurezza per garantire l'autenticità, l'integrità e la privacy dei dati in transito. A seconda dei requisiti di sicurezza e conformità, puoi anche configurare la crittografia a livello di applicazione.
Le seguenti sezioni descrivono le opzioni disponibili per la crittografia dei dati in transito. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. L'altra opzione discussa nelle seguenti sezioni è una funzionalità aggiuntiva che puoi prendere in considerazione se l'opzione 1 è insufficiente per il tuo caso d'uso specifico.
Opzione 1: valuta se la crittografia predefinita dei dati in transito è sufficiente
Molti modelli di traffico beneficiano della crittografia predefinita di Google in transito senza richiedere una configurazione aggiuntiva. Tutto il traffico da VM a VM all'interno di una rete VPC e delle reti VPC connesse viene criptato al livello 3 o 4. Il traffico da internet verso i servizi Google termina al Google Front End (GFE). Inoltre, GFE effettua le seguenti operazioni:
- Termina il traffico in entrata HTTP(S), TCP e proxy TLS
- Offre contromisure agli attacchi DDoS
- Instrada 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 predefinita dei dati in transito. Non è necessario configurare controlli aggiuntivi di crittografia in transito per il traffico da criptare.
Utilizza questa opzione quando la crittografia predefinita di Google dei dati in transito è sufficiente 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 calcolo interne.
In questi casi, devi configurare controlli aggiuntivi, come descritto in Opzione 2: richiedi 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: richiedi alle applicazioni di configurare la crittografia di livello 7 in transito
Oltre alla crittografia predefinita dei dati in transito, puoi configurare la crittografia di livello 7 per il traffico delle applicazioni. Google Cloud fornisce servizi gestiti per supportare le applicazioni che richiedono la crittografia a livello di applicazione in transito, inclusi i certificati gestiti, Anthos Service Mesh e Traffic Director.
Ad esempio, uno sviluppatore sta creando una nuova applicazione che accetta il traffico in entrata da internet. Utilizzano un bilanciatore del carico delle applicazioni esterno con certificati SSL gestiti da Google per eseguire e scalare i servizi dietro un singolo indirizzo IP.
La crittografia a livello di applicazione non è un controllo che puoi applicare centralmente nella zona di destinazione. Questa opzione sposta invece una certa responsabilità per gli sviluppatori di applicazioni nella configurazione della crittografia in transito.
Utilizza questa opzione quando le applicazioni richiedono il traffico HTTPS o SSL tra i componenti.
Valuta la possibilità di consentire un'eccezione limitata a questa opzione quando esegui la migrazione al cloud di carichi di lavoro di computing 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, forzare la modernizzazione delle applicazioni legacy prima della migrazione potrebbe causare un ritardo inaccettabile nell'esecuzione del 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ò essere una preoccupazione durante l'adozione del cloud. Google Cloud offre più livelli di controllo che consentono di verificare l'accesso del cloud provider.
Le seguenti sezioni descrivono le opzioni per la gestione dell'accesso CSP. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. L'altra opzione discussa nelle seguenti sezioni è una funzionalità aggiuntiva che puoi prendere in considerazione se l'opzione 1 è insufficiente 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 durante la risoluzione dei problemi di una richiesta di assistenza.
Ad esempio, lo sviluppatore solleva un problema per la risoluzione dei problemi all'assistenza clienti Google Cloud e chiede all'addetto all'assistenza di aiutarti 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 lo giustifica.
Utilizza questa opzione quando si verifica quanto segue:
- Hai l'obbligo di verificare che il personale Google Cloud acceda ai tuoi contenuti solo per validi motivi aziendali, ad esempio per risolvere un'interruzione del servizio o per partecipare 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 degli accessi del provider
Se la tua azienda ha il requisito di conformità che prevede l'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 l'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 tutte le richieste di chiavi di crittografia configurate con Cloud EKM.
Utilizza questa opzione quando si verifica quanto segue:
- Vuoi che un team centrale gestisca direttamente l'accesso ai tuoi contenuti da parte del personale di Google.
- Per Access Approval, puoi accettare il rischio che la capacità centrale di approvare o rifiutare ogni richiesta di accesso sia più importante del compromesso operativo, che potrebbe essere una risoluzione più lenta delle richieste di assistenza.
- Per Key Access Justifications, la tua azienda utilizza già Cloud External Key Manager nella strategia di crittografia e vuole il controllo programmatico su tutti i tipi di accesso ai dati criptati (non solo l'accesso ai dati da parte del personale Google).
Evita questa opzione se si verifica quanto segue:
- Il ritardo operativo che può verificarsi quando un team centrale con l'autorità di Access Approval deve rispondere è un rischio inaccettabile per i carichi di lavoro 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 zone di destinazione di Google Cloud
Oltre alle decisioni introdotte in questo documento, prendi in considerazione le seguenti best practice per la sicurezza:
- Esegui il provisioning delle identità nel tuo ambiente. Per ulteriori informazioni, consulta Decidere come eseguire l'onboarding delle identità in Google Cloud.
- Progetta una rete che soddisfi i casi d'uso della tua organizzazione. Per ulteriori informazioni, consulta Decidere la progettazione della rete per la zona di destinazione Google Cloud.
- Implementa i vincoli dei criteri dell'organizzazione definiti nel progetto della piattaforma aziendale. Questi vincoli aiutano a prevenire problemi di sicurezza comuni come la creazione di indirizzi IP esterni non necessari o la concessione del ruolo Editor a tutti gli account di servizio.
- Esamina l'elenco completo dei vincoli dei criteri dell'organizzazione per valutare se altri controlli sono pertinenti per i tuoi requisiti.
Passaggi successivi
- Esamina il progetto delle fondazioni aziendali.
- Leggi altre best practice per la sicurezza nel framework dell'architettura di Google Cloud.
- Leggi i progetti e i documenti tecnici disponibili nel Centro best practice per la sicurezza di Google Cloud.