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 zone di destinazione, ed è destinata a specialisti della sicurezza, CISO e architect che Vuoi capire le decisioni che devono prendere quando progettano una pagina 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 di scalabilità aziendale, alcune strategie che descrivono potrebbero essere meno pertinente per i piccoli team.
Punti decisionali per proteggere la tua zona di destinazione di Google Cloud
Per scegliere il design migliore per la sicurezza della tua organizzazione, devi prendere le seguenti decisioni:
Come limitare le credenziali permanenti per gli account di servizio
Come mitigare l'esfiltrazione di dati tramite le API di Google
Come monitorare continuamente le configurazioni non sicure e le minacce
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 una progettazione di sicurezza comune pattern. I controlli specifici possono variare in base a fattori quali il settore, i carichi di lavoro target o la conformità aggiuntiva i tuoi requisiti. Il seguente diagramma mostra l'architettura dei controlli di sicurezza che applichi nella zona di destinazione quando segui i consigli riportati in documento.
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.
- Controlli di servizio VPC definisce un perimetro intorno alle risorse sensibili consente di limitare l'accesso dall'esterno del perimetro.
- Security Command Center monitora l'ambiente alla ricerca di configurazioni non sicure e in modo proattivo.
- Un sink di log centralizzato raccoglie gli audit log di tutti i progetti.
- La crittografia at-rest predefinita di Google cripta tutti i dati persistenti sul disco.
- La crittografia predefinita di Google in transito si applica al livello 3 e al livello 4 percorsi di rete.
- 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
Account di servizio sono identità macchina utilizzate per concedere ruoli IAM carichi di lavoro e consentire loro di accedere alle API Google Cloud. Un servizio dell'account è una credenziale permanente; tutte le credenziali permanenti rischio potenzialmente elevato. Consigliamo di non permettere agli sviluppatori di creare 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. Per fare un altro esempio, se la chiave dell'account di servizio viene archiviata in repository interno, un utente malintenzionato interno in grado di leggere la chiave potrebbe utilizzare e credenziali per riassegnare i suoi privilegi di 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 all'account di servizio consulta Scegliere il metodo di autenticazione più adatto al 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 degli account di servizio permanenti
Ti consigliamo di non consentire agli utenti di scaricare le chiavi degli account di servizio perché le chiavi esposte sono un comune vettore d'attacco. 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:
- Per impedire agli sviluppatori di creare e scaricare
le credenziali, configura
vincolo dei criteri dell'organizzazione
constraints/iam.disableServiceAccountKeyCreation. - Educa i tuoi team sulle alternative più sicure alle chiavi degli account di servizio. Ad esempio, quando utenti e applicazioni che si trovano al di fuori del tuo Google Cloud deve utilizzare un account di servizio, Autenticare con la rappresentazione degli account di servizio o la federazione delle identità per i carichi di lavoro anziché una chiave dell'account di servizio.
- Progetta una procedura per consentire ai team di richiedere un'eccezione a queste norme quando il download della chiave dell'account di servizio è l'unica opzione possibile. Ad esempio, un 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 quando hai già strumenti per generare le 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 l'utilizzo degli account di servizio
Opzione 2: utilizza strumenti di gestione degli accessi aggiuntivi per generare credenziali di breve durata
In alternativa a Limita l'uso 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 e gestire le chiavi account di servizioo. 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 generare credenziali di breve durata per il controllo dell'accesso o disporre di un budget sufficiente e capacità di 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. Mentre ogni risorsa API nel tuo ambiente Google Cloud è soggetta Controlli dell'accesso IAM, c'è il rischio che i dati possano essere utilizzando credenziali rubate, esfiltrate da utenti malintenzionati interni al dominio o codice compromesso, o 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 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 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 livelli di accesso o criteri in entrata, gli sviluppatori possono accedere ai servizi di cui hanno bisogno, incluso l'accesso alla console ove necessario.
Utilizza questa opzione quando si verifica quanto segue:
- I servizi che intendi utilizzare supportano Controlli di servizio VPC, e i tuoi carichi di lavoro non richiedono l'accesso illimitato a internet.
- Archivia su Google Cloud dati sensibili che potrebbero essere una perdita significativa in caso di esfiltrazione.
- 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 quando i 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:
- Best practice per l'abilitazione dei Controlli di servizio VPC
- Prodotti supportati e limitazioni per i Controlli di servizio VPC
- Progetta e progetta perimetri di servizio
Opzione 2: configura i Controlli di servizio VPC per un sottoinsieme del tuo ambiente
Invece di configurando i Controlli di servizio VPC in modo ampio nel tuo ambiente, è possibile configurare Controlli di servizio VPC solo su un sottoinsieme di progetti che contengono dati sensibili e carichi di lavoro solo interni. Questa opzione ti consente di utilizzare una progettazione e un funzionamento più semplici per la maggior parte dei progetti, pur dando priorità ai 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. Devi definire le regole di traffico in entrata nel perimetro in modo che i livelli possano comunicare attraverso il perimetro un 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, mentre altri richiedono un carico pubblico l'accesso a internet o che hanno dipendenze in servizi non supportati Controlli di servizio VPC.
- Configurazione dei Controlli di servizio VPC anche in tutte le creazioni di progetti overhead o richiede troppe soluzioni
Evita questa opzione quando molti progetti potrebbero contenere contenuti sensibili e i dati di Google Cloud.
Per ulteriori informazioni, vedi Best practice per l'abilitazione dei Controlli di servizio VPC.
Opzione 3: non configurare i Controlli di servizio VPC
Come ulteriore alternativa a configurando i Controlli di servizio VPC in modo ampio nel tuo ambiente, puoi scegliere di non utilizzare i Controlli di servizio VPC, in particolare se l'overhead operativo supera il valore dei Controlli di servizio VPC.
Ad esempio, la tua organizzazione potrebbe non avere un modello coerente di sviluppo che potrebbe costituire la base di un criterio in entrata. 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, potrebbe non essere in grado di definire le 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 per internet e non contengono dati sensibili.
- Non hai attributi coerenti per l'accesso sviluppatore, ad esempio l'accesso gestito tra dispositivi mobili 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 dei servizi cloud introduce nuove sfide e minacce rispetto all'uso di servizi situati on-premise. I tuoi strumenti esistenti che monitorano i server di lunga durata potrebbero non essere appropriati per la scalabilità automatica o i servizi temporanei e potrebbero non per monitorare le risorse serverless. Pertanto, dovresti valutare la sicurezza in grado di funzionare con l'intera gamma di servizi cloud che potresti adottare. Tu devono anche monitorare costantemente gli standard del cloud sicuri, come Benchmark CIS per Google Cloud.
Le seguenti sezioni descrivono le opzioni disponibili per il monitoraggio continuo. 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 al tuo caso d'uso specifico.
Opzione 1: utilizza Security Command Center Premium
Ti consigliamo di attivare il livello Premium di Security Command Center nel organizzazione, il che ti aiuta a rafforzare il livello di sicurezza le seguenti:
- Valutazione della superficie di attacco per dati e sicurezza
- Fornire un inventario e una visibilità degli asset
- Identificazione di errori di configurazione, vulnerabilità e minacce
- Aiuta a mitigare e risolvere i rischi
Quando abiliti Security Command Center all'inizio della 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 quando si verifica quanto segue:
- 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. Vari esistono strumenti di terze parti che hanno funzioni simili a Security Command Center, potrebbe aver già investito in strumenti cloud-native incentrati ambienti multi-cloud.
Puoi anche utilizzare Security Command Center insieme a strumenti di terze parti. Ad esempio, potrebbe importare trovare le notifiche da Security Command Center a un altro strumento, oppure aggiungi 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 la tua piattaforma SIEM esistente per importare solo trovare le notifiche prodotto da Security Command Center, invece di importare un grande volume di log e ci aspettiamo che un team SOC analizzi i log non elaborati per ottenere insight.
Utilizza 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.
Evita questa opzione se si verifica quanto segue:
- Il tuo SOC esistente non ha le competenze o le capacità per generare insight sulle minacce derivanti dall'enorme volume di log del 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. Come tuo potrebbe non essere possibile per un revisore controllare i log in ogni progetto individuale. Devi quindi decidere le modalità di archiviazione dei log centralizzati e aggregati per facilitare i processi di controllo e sicurezza interni operazioni.
Le seguenti sezioni 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 sink di log aggregati
Ti consigliamo di configurare un sink di log centralizzato a livello di organizzazione per e gli altri log richiesti dal team responsabile della 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 anche un registro immutabile dei dati per alcuni carichi di lavoro altamente sensibili. Pertanto, il team di sicurezza configura un sink di log per aggregare gli audit log delle attività di amministrazione di tutti i progetti in un'analisi dei log in un progetto centrale che possono visualizzare per indagini estemporanee. Quindi configura un secondo sink di log per gli audit log di accesso ai dati da progetti con carichi di lavoro sensibili in un bucket Cloud Storage per fidelizzazione 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 restrizioni senza il controllo del carico di lavoro o dei team che hanno generato il log.
Evita questa opzione quando si verifica quanto segue: - La tua organizzazione non ha un requisito centrale per e la coerenza degli audit log tra i vari 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:
- Controlli di rilevamento nel progetto delle basi aziendali
- Best practice per Cloud Audit Logs
- Configura 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 nello spazio di archiviazione al di fuori di 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 centralizzare i tipi di log necessari in un sink di log aggregato in Google Cloud, importare i contenuti del sink in un'altra piattaforma al di fuori Google Cloud per l'archiviazione e l'analisi dei log.
Ad esempio, potresti utilizzare una piattaforma SIEM di terze parti per aggregare e analizzare i dati tra più cloud provider. Questo strumento ha capacità sufficienti lavorare con risorse cloud serverless e il team SOC ha le competenze per generare insight 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 verifica quanto segue:
- I sistemi esistenti non hanno la capacità o il budget per importare un di log cloud aggiuntivi.
- I sistemi esistenti richiedono attività di integrazione per ogni tipo di log e formato.
- Stai raccogliendo i log senza un obiettivo chiaro su come verranno utilizzati.
Per ulteriori informazioni, consulta le seguenti risorse:
- Controlli di rilevamento nel progetto delle basi aziendali
- Scenari per l'esportazione da Logging: requisiti di conformità
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. In base alla tua conformità requisiti, potresti avere l'obbligo di gestire le chiavi di crittografia per te.
Le seguenti sezioni descrivono le opzioni per la crittografia at-rest. 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 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 dispongono di requisiti di conformità specifici per la gestione delle chiavi di crittografia.
Ad esempio, il team di sicurezza di un'azienda di giochi online richiede la crittografia at-rest dei dati dei clienti. Non hanno requisiti normativi sulla gestione delle chiavi. Dopo avere esaminato la crittografia at-rest predefinita di Google, si ritiene che offra 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 di per la gestione delle tue chiavi di crittografia.
Evita questa opzione quando devi gestire requisiti di conformità le tue chiavi di crittografia.
Per ulteriori informazioni, vedi Crittografia at-rest 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à per proteggere i tuoi dati utilizzando 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 quando 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 di crittografia con un FIPS 140-2 Livello 3 HSM certificato.
- Devi archiviare il materiale della chiave di crittografia al di fuori Google Cloud con Cloud EKM.
Evita questa opzione quando si verifica quanto segue:
- Non hai requisiti specifici su come criptare i dati e le chiavi di crittografia.
- Preferisci un servizio gestito al costo e all'overhead operativo di per la 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 delle basi aziendali
Opzione 3: tokenizza i dati a livello di applicazione prima che siano conservati 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 devono non possono essere utilizzati nel formato non elaborato.
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 :
- 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 adotta diverse misure di sicurezza per 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 seguenti sezioni descrivono le opzioni per la crittografia dei dati in transito. Me consiglia 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 sufficienti 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. Traffico da internet ai servizi Google termina sul Google Front End (GFE). GFE esegue inoltre le seguenti operazioni:
- Termina il traffico per il traffico proxy HTTP(S), TCP e TLS in entrata
- Fornisce contromisure per gli attacchi DDoS
- Route e bilancia il carico del traffico verso i servizi Google Cloud
Ad esempio, se stai progettando un'applicazione serverless interna utilizzando le API di Google, i percorsi di rete 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:
- Hai bisogno della 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 illustrato in Opzione 2: richiedi 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 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 alcune responsabilità all'applicazione agli sviluppatori di configurare la 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 durante la migrazione carichi di lavoro di computing verso il cloud che in precedenza non richiedevano la crittografia 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ò essere un problema durante l'adozione del cloud. Google Cloud fornisce più livelli di controllo per abilitare verifica dell'accesso del cloud provider.
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 nel le sezioni seguenti sono una funzionalità aggiuntiva che puoi prendere in considerazione se l'opzione 1 è non sufficienti per il tuo caso d'uso specifico.
Opzione 1: abilita 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, il tuo sviluppatore segnala un problema per la risoluzione dei problemi all'assistenza clienti Google Cloud, e chiede all'addetto all'assistenza di aiutarlo a risolvere i problemi dell'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 quando si verifica quanto segue:
- Hai un requisito per verificare che il personale Google Cloud acceda i tuoi contenuti solo per motivi aziendali validi, come la riparazione di un'interruzione del servizio 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 richiede di concedere l'approvazione esplicita prima un CSP può accedere al tuo ambiente, oltre all'opzione 1, puoi usare Access Transparency con altri controlli che ti consentono di approvare o rifiutare esplicitamente gli accessi l'accesso ai dati.
Access Approval è una soluzione manuale che garantisce che l'assistenza clienti e Google richiedono la tua approvazione esplicita (tramite email o 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 ai tuoi contenuti personale di Google.
- 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 Key Access Justifications la tua azienda utilizza già Gestore di chiavi esterne Cloud nell'ambito della tua strategia di crittografia e vuole avere il controllo programmatico tutti i tipi di accesso ai dati criptati (non solo l'accesso del personale Google a dati).
Evita questa opzione quando 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 di Google Cloud
Oltre alle decisioni introdotte in questo documento, considera gli best practice per la sicurezza.
- Esegui il provisioning delle identità nel tuo ambiente. Per ulteriori informazioni, vedi Decidere come eseguire l'onboarding delle identità in Google Cloud.
- Progetta una rete che soddisfi i casi d'uso della tua organizzazione. Per maggiori informazioni per informazioni, consulta Decidere la progettazione della rete per la zona di destinazione di Google Cloud.
- Implementa il vincoli dei criteri dell'organizzazione definiti nel progetto delle basi aziendali. Questi vincoli aiutano a evitare problemi di sicurezza comuni, come la creazione di indirizzi IP esterni o di concedere il ruolo Editor a tutti gli account di servizio.
- Consulta l'elenco completo vincoli dei criteri dell'organizzazione per valutare se altri controlli sono pertinenti ai requisiti.
Passaggi successivi
- Esamina il progetto base aziendale.
- Leggi altre best practice per la sicurezza nella framework dell'architettura Google Cloud.
- Leggi i progetti e i documenti tecnici disponibili in Centro best practice per la sicurezza di Google Cloud.