Questi contenuti sono stati aggiornati l'ultima volta a dicembre 2023 e rappresentano lo status quo al momento della loro redazione. I criteri e i sistemi di sicurezza di Google potranno variare in futuro, in virtù del costante miglioramento della protezione per i nostri clienti.
Questo documento descrive le best practice che ti consentono di eseguire il deployment di un insieme di risorse di base in Google Cloud. Una base cloud è la linea di base di risorse, configurazioni e funzionalità che consentono alle aziende di adottareGoogle Cloud per le proprie esigenze aziendali. Una base ben progettata consente una governance, controlli di sicurezza, scalabilità, visibilità e accesso coerenti ai servizi condivisi su tutti i carichi di lavoro del tuo Google Cloud ambiente. Dopo aver eseguito il deployment dei controlli e della governance descritti in questo documento, puoi eseguire il deployment dei carichi di lavoro in Google Cloud.
Il blueprint delle basi per le aziende (in precedenza blueprint delle basi per la sicurezza) è destinato ad architetti, professionisti della sicurezza e team di ingegneria della piattaforma che si occupano della progettazione di un ambiente adatto alle aziende su Google Cloud. Questo blueprint è costituito da quanto segue:
- Un repository GitHub terraform-example-foundation che contiene gli asset Terraform di cui è possibile eseguire il deployment.
- Una guida che descrive l'architettura, il design e i controlli che implementi con il progetto (questo documento).
Puoi utilizzare questa guida in due modi:
- Per creare una base completa in base alle best practice di Google. Puoi eseguire il deployment di tutti i consigli di questa guida come punto di partenza, quindi personalizzare l'ambiente in base alle esigenze specifiche della tua attività.
- Per esaminare un ambiente esistente su Google Cloud. Puoi confrontare componenti specifici del tuo design con le best practice consigliate da Google.
Casi d'uso supportati
Il progetto della piattaforma aziendale fornisce un livello di base di risorse e configurazioni che consente di attivare tutti i tipi di carichi di lavoro su Google Cloud. Che tu stia eseguendo la migrazione di carichi di lavoro di calcolo esistenti a Google Cloud, sviluppando applicazioni web containerizzate o creando carichi di lavoro di big data e machine learning, il blueprint di base enterprise ti aiuta a creare il tuo ambiente per supportare i carichi di lavoro aziendali su larga scala.
Dopo aver eseguito il deployment del progetto della piattaforma aziendale, puoi eseguire il deployment dei carichi di lavoro direttamente o di altri progetti per supportare carichi di lavoro complessi che richiedono funzionalità aggiuntive.
Un modello di sicurezza di difesa in profondità
Google Cloud trarrà vantaggio dalla progettazione della sicurezza dell'infrastruttura Google di base. È tua responsabilità progettare la sicurezza nei sistemi che crei su Google Cloud. Il blueprint Enterprise Foundation ti aiuta a implementare un modello di sicurezza di difesa in profondità per i tuoi servizi e carichi di lavoro. Google Cloud
Il seguente diagramma mostra un modello di sicurezza di difesa in profondità per la tuaGoogle Cloud organizzazione che combina controlli dell'architettura, controlli dei criteri e controlli di rilevamento.
Il diagramma descrive i seguenti controlli:
- I controlli delle norme sono vincoli programmatici che applicano configurazioni delle risorse accettabili e impediscono configurazioni rischiose. Il blueprint utilizza una combinazione di controlli delle norme, inclusa la convalida IaC (Infrastructure as Code) nella pipeline e i vincoli delle norme dell'organizzazione.
- I controlli dell'architettura sono la configurazione di Google Cloud risorse come reti e gerarchia delle risorse. L'architettura del progetto si basa sulle best practice per la sicurezza.
- I controlli di rilevamento ti consentono di rilevare comportamenti anomali o dannosi all'interno dell'organizzazione. Il blueprint utilizza funzionalità della piattaforma come Security Command Center, si integra con i controlli di rilevamento esistenti e i flussi di lavoro come un Security Operations Center (SOC) e fornisce funzionalità per applicare controlli di rilevamento personalizzati.
Decisioni chiave
Questa sezione riassume le decisioni di architettura di alto livello del progetto.
Il diagramma descrive in che modo i Google Cloud servizi contribuiscono alle decisioni di architettura chiave:
- Cloud Build:le risorse di infrastruttura vengono gestite utilizzando un modello GitOps. L'IaC dichiarativa è scritta in Terraform e gestita in un sistema di controllo della versione per la revisione e l'approvazione. Le risorse vengono implementate utilizzando Cloud Build come strumento di automazione di integrazione e distribuzione continua (CI/CD). La pipeline inoltre applica controlli di policy as code per verificare che le risorse soddisfino le configurazioni previste prima del deployment.
- Cloud Identity: gli utenti e l'appartenenza ai gruppi vengono sincronizzati dal tuo provider di identità esistente. I controlli per la gestione del ciclo di vita degli account utente e il Single Sign-On (SSO) si basano sui controlli e sulle procedure esistenti del tuo provider di identità.
- Identity and Access Management (IAM): i criteri di autorizzazione (in precedenza noti come criteri IAM) consentono l'accesso alle risorse e vengono applicati ai gruppi in base alla funzione del job. Gli utenti vengono aggiunti ai gruppi appropriati per ricevere accesso di sola visualizzazione alle risorse di base. Tutte le modifiche alle risorse di base vengono implementate tramite la pipeline CI/CD che utilizza le identità degli account di servizio con privilegi.
- Resource Manager:tutte le risorse sono gestite in un'unica organizzazione, con una gerarchia di risorse di cartelle che organizza i progetti in base agli ambienti. I progetti sono etichettati con metadati per la governance, tra cui l'attribuzione dei costi.
- Networking: le topologie di rete utilizzano il VPC condiviso per fornire risorse di rete per i carichi di lavoro in più regioni e zone, separate per ambiente e gestite centralmente. Tutti i percorsi di rete tra gli host on-premise, le risorse nelle reti VPC e i servizi sono privati. Google Cloud Google Cloud Per impostazione predefinita, non è consentito alcun traffico in uscita o in entrata dalla rete internet pubblica.
- Cloud Logging: i canali di log aggregati sono configurati per raccogliere i log pertinenti per la sicurezza e il controllo in un progetto centralizzato per la conservazione, l'analisi e l'esportazione a lungo termine in sistemi esterni.
- Servizio di criteri dell'organizzazione:i vincoli dei criteri dell'organizzazione sono configurati per impedire varie configurazioni ad alto rischio.
- Secret Manager:i progetti centralizzati vengono creati per un team responsabile della gestione e del controllo dell'utilizzo di secret di applicazioni sensibili per contribuire a soddisfare i requisiti di conformità.
- Cloud Key Management Service (Cloud KMS): i progetti centralizzati vengono creati per un team responsabile della gestione e del controllo delle chiavi di crittografia per contribuire a soddisfare i requisiti di conformità.
- Security Command Center: le funzionalità di monitoraggio e rilevamento delle minacce vengono offerte utilizzando una combinazione di controlli di sicurezza integrati di Security Command Center e soluzioni personalizzate che ti consentono di rilevare e rispondere agli eventi di sicurezza.
Per le alternative a queste decisioni chiave, vedi Alternative.
Passaggi successivi
- Scopri di più su autenticazione e autorizzazione (documento successivo di questa serie).
Autenticazione e autorizzazione
Questa sezione illustra come utilizzare Cloud Identity per gestire le identità utilizzate dai dipendenti per accedere ai servizi Google Cloud.
Provider di identità esterno come fonte attendibile
Ti consigliamo di federare il tuo account Cloud Identity con il tuo provider di identità esistente. La federazione ti consente di assicurarti che le procedure di gestione dell'account esistenti si applichino a Google Cloud e ad altri servizi Google.
Se non hai un provider di identità esistente, puoi creare account utente direttamente in Cloud Identity.
Il seguente diagramma mostra una visione di alto livello della federazione delle identità e del singolo accesso (SSO). Utilizza Microsoft Active Directory, situato nell'ambiente on-premise, come provider di identità di esempio.
Questo diagramma descrive le seguenti best practice:
- Le identità utente vengono gestite in un dominio Active Directory situato nell'ambiente on-premise e federato a Cloud Identity. Active Directory utilizza Google Cloud Directory Sync per eseguire il provisioning delle identità in Cloud Identity.
- Gli utenti che tentano di accedere ai servizi Google vengono reindirizzati al provider di identità esterno per il Single Sign-On con SAML, utilizzando le proprie credenziali esistenti per l'autenticazione. Nessuna password viene sincronizzata con Cloud Identity.
La tabella seguente fornisce i link alle indicazioni per la configurazione dei provider di identità.
Provider di identità | Consulenza |
---|---|
Active Directory | |
Microsoft Entra ID (in precedenza Azure AD) | |
Altri provider di identità esterni (ad esempio Ping o Okta) |
Ti consigliamo vivamente di applicare l'autenticazione a più fattori al tuo fornitore di servizi di identità con un meccanismo resistente al phishing, come un token di sicurezza Titan.
Le impostazioni consigliate per Cloud Identity non sono automatizzate tramite il codice Terraform in questo blueprint. Consulta i controlli amministrativi per Cloud Identity per le impostazioni di sicurezza consigliate da configurare oltre al deployment del codice Terraform.
Gruppi per il controllo dell'accesso
Un'entità è un'identità a cui è possibile concedere l'accesso a una risorsa. I principali includono Account Google per gli utenti, gruppi Google, account Google Workspace, domini Cloud Identity e account di servizio. Alcuni servizi ti consentono anche di concedere l'accesso a tutti gli utenti che si autenticano con un Account Google o a tutti gli utenti su internet. Affinché un'entità possa interagire con i servizi Google Cloud , devi concederle i ruoli in Identity and Access Management (IAM).
Per gestire i ruoli IAM su larga scala, ti consigliamo di assegnare gli utenti ai gruppi in base alle loro funzioni lavorative e ai requisiti di accesso, quindi di concedere i ruoli IAM a questi gruppi. Devi aggiungere gli utenti ai gruppi utilizzando le procedure del tuo provider di identità esistente per la creazione e l'appartenenza ai gruppi.
Sconsigliamo di concedere ruoli IAM ai singoli utenti perché le singole assegnazioni possono aumentare la complessità della gestione e del controllo dei ruoli.
Il blueprint configura gruppi e ruoli per l'accesso di sola visualizzazione alle risorse di base. Ti consigliamo di eseguire il deployment di tutte le risorse nel blueprint tramite la pipeline di base e di non concedere ruoli agli utenti dei gruppi per modificare le risorse di base al di fuori della pipeline.
La tabella seguente mostra i gruppi configurati dal blueprint per visualizzare le risorse della Fondazione.
Nome | Descrizione | Ruoli | Ambito |
---|---|---|---|
grp-gcp-org-admin@example.com |
Amministratori con privilegi elevati che possono concedere ruoli IAM a livello di organizzazione. Possono accedere a qualsiasi altro ruolo. Questo privilegio non è consigliato per l'uso quotidiano. | Amministratore dell'organizzazione | organizzazione |
grp-gcp-billing-admin@example.com |
Amministratori con privilegi elevati che possono modificare l'account Cloud Billing. Questo privilegio non è consigliato per l'uso quotidiano. | Amministratore account di fatturazione | organizzazione |
grp-gcp-billing-viewer@example.com |
Il team responsabile della visualizzazione e dell'analisi della spesa in tutti i progetti. | Visualizzatore account di fatturazione | organizzazione |
Utente BigQuery | progetto di fatturazione | ||
grp-gcp-audit-viewer@example.com |
Il team responsabile del controllo dei log correlati alla sicurezza. | progetto di logging | |
grp-gcp-security-reviewer@example.com |
Il team responsabile della revisione della sicurezza nel cloud. | Security Reviewer | organizzazione |
grp-gcp-network-viewer@example.com |
Il team responsabile della visualizzazione e della manutenzione delle configurazioni di rete. | Compute Network Viewer | organizzazione |
grp-gcp-scc-admin@example.com |
Il team responsabile della configurazione di Security Command Center. | Security Center Admin Editor | organizzazione |
grp-gcp-secrets-admin@example.com |
Il team responsabile della gestione, dell'archiviazione e del controllo delle credenziali e di altri secret utilizzati dalle applicazioni. | Amministratore di Secret Manager | progetti secrets |
grp-gcp-kms-admin@example.com |
Il team responsabile dell'applicazione della gestione delle chiavi di crittografia per soddisfare i requisiti di conformità. | Cloud KMS Viewer | Progetti kms |
Quando crei i tuoi carichi di lavoro sulla base, crei gruppi aggiuntivi e concedi ruoli IAM in base ai requisiti di accesso per ogni carico di lavoro.
Ti consigliamo vivamente di evitare i ruoli di base (come Proprietario, Editor o Visualizzatore) e di utilizzare invece i ruoli predefiniti. I ruoli di base sono eccessivamente permissivi e rappresentano un potenziale rischio per la sicurezza. I ruoli Proprietario e Editor possono comportare l'aumento dei privilegi e il movimento laterale, mentre il ruolo Visualizzatore include l'accesso in lettura a tutti i dati. Per le best practice sui ruoli IAM, consulta Utilizzare IAM in modo sicuro.
Account super amministratore
Gli utenti di Cloud Identity con l'account super amministratore aggirano le impostazioni SSO dell'organizzazione e si autenticano direttamente in Cloud Identity. Questa eccezione è prevista per impostazione predefinita, in modo che il super amministratore possa ancora accedere alla console Cloud Identity in caso di mancata configurazione o interruzione del servizio SSO. Tuttavia, significa che devi prendere in considerazione una protezione aggiuntiva per gli account super amministratore.
Per proteggere i tuoi account super amministratore, ti consigliamo di applicare sempre la verifica in due passaggi con i token di sicurezza in Cloud Identity. Per ulteriori informazioni, consulta le best practice per la sicurezza degli account amministratore.
Problemi con gli account utente consumer
Se non utilizzavi Cloud Identity o Google Workspace prima di eseguire l'onboarding in Google Cloud, è possibile che i dipendenti della tua organizzazione stiano già utilizzando account consumer associati alle loro identità email aziendali per accedere ad altri servizi Google come Google Marketing Platform o YouTube. Gli account consumer sono account interamente di proprietà e gestiti dalle persone che li hanno creati. Poiché questi account non sono sotto il controllo della tua organizzazione e potrebbero includere dati personali e aziendali, devi decidere come consolidarli con altri account aziendali.
Ti consigliamo di consolidare gli account utente consumer esistenti nell'ambito dell'onboarding in Google Cloud. Se non utilizzi già Google Workspace per tutti i tuoi account utente, ti consigliamo di bloccare la creazione di nuovi account consumer.
Controlli amministrativi per Cloud Identity
Cloud Identity dispone di vari controlli amministrativi che non sono automatizzati dal codice Terraform nel blueprint. Ti consigliamo di applicare ciascuno di questi controlli di sicurezza delle best practice all'inizio del processo di creazione della tua base.
Controllo | Descrizione |
---|---|
Implementare la verifica in due passaggi | Gli account utente potrebbero essere compromessi tramite phishing, social engineering, password spraying o varie altre minacce. La verifica in due passaggi contribuisce a mitigare queste minacce. Ti consigliamo di applicare la verifica in due passaggi a tutti gli account utente della tua organizzazione con un meccanismo anti-phishing, come i token di sicurezza Titan o altri token basati sugli standard FIDO U2F (CTAP1) anti-phishing. |
Impostare la durata della sessione per i Google Cloud servizi | I token OAuth permanenti sulle postazioni di lavoro degli sviluppatori possono rappresentare un rischio per la sicurezza se esposti. Ti consigliamo di impostare un criterio di riautenticazione per richiedere l'autenticazione ogni 16 ore utilizzando un token di sicurezza. |
Impostare la durata della sessione per i servizi Google | (solo clienti Google Workspace)
Le sessioni web permanenti su altri servizi Google possono rappresentare un rischio per la sicurezza se esposte. Ti consigliamo di applicare una durata massima della sessione web e di allinearla ai controlli della durata della sessione nel tuo provider SSO. |
Condividere i dati di Cloud Identity con Google Cloud servizi | I log di controllo delle attività amministrative di Google Workspace o Cloud Identity vengono in genere gestiti e visualizzati nella Console di amministrazione, separatamente dai log nel tuo Google Cloud ambiente. Questi log contengono informazioni pertinenti per il tuo Google Cloud ambiente, ad esempio gli eventi di accesso degli utenti. Ti consigliamo di condividere gli audit log di Cloud Identity con il tuo Google Cloud ambiente per gestire centralmente i log di tutte le fonti. |
Configurare la verifica post-SSO | Il blueprint presuppone che tu abbia configurato l'accessoSSO con il tuo provider di identità esterno. Ti consigliamo di attivare un ulteriore livello di controllo in base all'analisi dei rischi di accesso di Google. Dopo aver applicato questa impostazione, gli utenti potrebbero dover sostenere ulteriori verifiche dell'accesso basate sul rischio al momento dell'accesso se Google ritiene che l'accesso di un utente sia sospetto. |
Risolvere i problemi relativi agli account degli utenti consumer | Gli utenti con un indirizzo email valido nel tuo dominio, ma senza Account Google, possono registrarsi per gli account consumer non gestiti. Questi account potrebbero contenere dati aziendali, ma non sono controllati dalle procedure di gestione del ciclo di vita dell'account. Ti consigliamo di adottare misure per assicurarti che tutti gli account utente siano account gestiti. |
Disattivare il recupero dell'account per gli account super amministratore | Il recupero autonomo dell'account super amministratore è disattivato per impostazione predefinita per tutti i nuovi clienti (i clienti esistenti potrebbero avere questa impostazione attivata). La disattivazione di questa impostazione contribuisce a ridurre il rischio che un attacco di ingegneria sociale o un telefono o un'email compromessi possano consentire a un malintenzionato di ottenere privilegi di super amministratore nel tuo ambiente. Pianifica una procedura interna che consenta a un super amministratore di contattare un altro super amministratore della tua organizzazione se ha perso l'accesso al proprio account e assicurati che tutti i super amministratori conoscano la procedura per il recupero con l'assistenza dell'Assistenza Google. |
Applicare e monitorare i requisiti per le password degli utenti | Nella maggior parte dei casi, le password utente vengono gestite tramite il tuo provider di identità esterno, ma gli account super amministratore aggirano il SSO e devono utilizzare una password per accedere a Cloud Identity. Disattiva il riutilizzo delle password e monitora l'efficacia delle password per tutti gli utenti che utilizzano una password per accedere a Cloud Identity, in particolare per gli account super amministratore. |
Impostare criteri a livello di organizzazione per l'utilizzo dei gruppi | Per impostazione predefinita, gli account utente esterni possono essere aggiunti ai gruppi in Cloud Identity. Ti consigliamo di configurare le impostazioni di condivisione in modo che i proprietari dei gruppi non possano aggiungere membri esterni. Tieni presente che questa limitazione non si applica all'account super amministratore o ad altri amministratori delegati con autorizzazioni di amministratore di Gruppi. Poiché la federazione dal tuo provider di identità viene eseguita con i privilegi di amministratore, le impostazioni di condivisione dei gruppi non si applicano a questa sincronizzazione dei gruppi. Ti consigliamo di esaminare i controlli nel fornitore di identità e nel meccanismo di sincronizzazione per assicurarti che i membri non del dominio non vengano aggiunti ai gruppi o di applicare le limitazioni dei gruppi. |
Passaggi successivi
- Leggi l'articolo sulla struttura organizzativa (documento successivo di questa serie).
Struttura dell'organizzazione
Il nodo radice per la gestione delle risorse in Google Cloud è la organizzazione. L' Google Cloud organizzazione fornisce una gerarchia delle risorse che offre una struttura di proprietà per le risorse e punti di collegamento per criteri dell'organizzazione e controlli dell'accesso. La gerarchia delle risorse è composta da cartelle, progetti e risorse e definisce la struttura e l'utilizzo dei Google Cloud servizi all'interno di un'organizzazione.
Le risorse più in basso nella gerarchia ereditano criteri come i criteri di autorizzazione IAM e quelli dell'organizzazione. Per impostazione predefinita, tutte le autorizzazioni di accesso vengono negate finché non applichi i criteri di autorizzazione direttamente a una risorsa o la risorsa non eredita i criteri di autorizzazione da un livello superiore nella gerarchia delle risorse.
Il seguente diagramma mostra le cartelle e i progetti di cui viene eseguito il deployment dal blueprint.
Le sezioni seguenti descrivono le cartelle e i progetti nel diagramma.
Cartelle
Il blueprint utilizza cartelle per raggruppare i progetti in base al loro ambiente. Questo raggruppamento logico viene utilizzato per applicare configurazioni come i criteri di autorizzazione e i criteri dell'organizzazione a livello di cartella, in modo che tutte le risorse all'interno della cartella ereditino i criteri. La tabella seguente descrive le cartelle che fanno parte del blueprint.
Cartella | Descrizione |
---|---|
bootstrap |
Contiene i progetti utilizzati per il deployment dei componenti di base. |
common |
Contiene progetti con risorse condivise da tutti gli ambienti. |
production |
Contiene progetti con risorse di produzione. |
nonproduction |
Contiene una copia dell'ambiente di produzione per consentirti di testare i carichi di lavoro prima di promuoverli in produzione. |
development |
Contiene le risorse cloud utilizzate per lo sviluppo. |
networking |
Contiene le risorse di rete condivise da tutti gli ambienti. |
Progetti
Il blueprint utilizza progetti per raggruppare le singole risorse in base alla loro funzionalità e ai confini previsti per il controllo dell'accesso. La tabella seguente descrive i progetti inclusi nel blueprint.
Cartella | Progetto | Descrizione |
---|---|---|
bootstrap |
prj-b-cicd |
Contiene la pipeline di deployment utilizzata per creare i componenti di base dell'organizzazione. Per ulteriori informazioni, consulta la metodologia di implementazione. |
prj-b-seed |
Contiene lo stato Terraform della tua infrastruttura e l'account di servizio Terraform necessario per eseguire la pipeline. Per maggiori informazioni, consulta la metodologia di implementazione. | |
common |
prj-c-secrets |
Contiene secret a livello di organizzazione. Per ulteriori informazioni, consulta la sezione su come archiviare le credenziali dell'applicazione con Secret Manager. |
prj-c-logging |
Contiene le origini log aggregate per gli audit log. Per maggiori informazioni, consulta la sezione relativa al logging centralizzato per la sicurezza e il controllo. | |
prj-c-scc |
Contiene risorse per aiutarti a configurare gli avvisi di Security Command Center e altro monitoraggio della sicurezza personalizzato. Per ulteriori informazioni, consulta la sezione sul monitoraggio delle minacce con Security Command Center. | |
prj-c-billing-export |
Contiene un set di dati BigQuery con le esportazioni della fatturazione dell'organizzazione. Per ulteriori informazioni, consulta la sezione su come allocare i costi tra i centri di costo interni. | |
prj-c-infra-pipeline |
Contiene una pipeline di infrastruttura per il deployment di risorse come VM e database da utilizzare dai workload. Per saperne di più, consulta la sezione Livelli della pipeline. | |
prj-c-kms |
Contiene chiavi di crittografia a livello di organizzazione. Per saperne di più, consulta la pagina relativa alla gestione delle chiavi di crittografia. | |
networking |
prj-net-{env}-shared-base |
Contiene il progetto host per una rete VPC condivisa per i carichi di lavoro che non richiedono i Controlli di servizio VPC. Per ulteriori informazioni, consulta la topologia della rete. |
prj-net-{env}-shared-restricted |
Contiene il progetto host per una rete VPC condivisa per i carichi di lavoro che richiedono i Controlli di servizio VPC. Per ulteriori informazioni, consulta la topologia della rete. | |
prj-net-interconnect |
Contiene le connessioni Cloud Interconnect che forniscono connettività tra il tuo ambiente on-premise eGoogle Cloud. Per ulteriori informazioni, consulta la sezione sulla connettività ibrida. | |
prj-net-dns-hub |
Contiene risorse per un punto di comunicazione centrale tra il sistema DNS on-premise e Cloud DNS. Per ulteriori informazioni, consulta la configurazione DNS centralizzata. | |
prj-{env}-secrets |
Contiene secret a livello di cartella. Per ulteriori informazioni, consulta Archiviare e controllare le credenziali delle applicazioni con Secret Manager. | |
prj-{env}-kms |
Contiene chiavi di crittografia a livello di cartella. Per saperne di più, consulta la pagina relativa alla gestione delle chiavi di crittografia. | |
progetti di applicazione | Contiene vari progetti in cui crei risorse per le applicazioni. Per saperne di più, consulta i pattern di deployment dei progetti e i livelli della pipeline. |
Governance per la proprietà delle risorse
Ti consigliamo di applicare le etichette in modo coerente ai tuoi progetti per facilitare la gestione e l'allocazione dei costi. La tabella seguente descrive le etichette dei progetti che vengono aggiunte a ogni progetto per la governance nel blueprint.
Etichetta | Descrizione |
---|---|
application |
Il nome leggibile dell'applicazione o del workload associato al progetto. |
businesscode |
Un codice breve che descrive l'unità aziendale proprietaria del progetto. Il codice shared viene utilizzato per i progetti comuni
che non sono legati esplicitamente a un'unità aziendale. |
billingcode |
Un codice utilizzato per fornire informazioni sul riaccredito. |
primarycontact |
Il nome utente del contatto principale responsabile del progetto. Poiché le etichette dei progetti non possono includere caratteri speciali come la e commerciale (@), viene impostato il nome utente senza il suffisso @example.com. |
secondarycontact |
Il nome utente del contatto secondario responsabile del progetto. Poiché le etichette dei progetti non possono includere caratteri speciali come @, imposta solo il nome utente senza il suffisso @example.com. |
environment |
Un valore che identifica il tipo di ambiente, ad esempio
bootstrap , common , production ,
non-production,development o network. |
envcode |
Un valore che identifica il tipo di ambiente, abbreviato in
b , c , p , n ,
d o net . |
vpc |
L'ID della rete VPC che questo progetto dovrebbe utilizzare. |
Occasionalmente, Google potrebbe inviare notifiche importanti, ad esempio sospensioni dell'account o aggiornamenti dei termini del prodotto. Il blueprint utilizza Contatti necessari per inviare queste notifiche ai gruppi che configuri durante il deployment. I contatti essenziali vengono configurati nel nodo dell'organizzazione e ereditati da tutti i progetti dell'organizzazione. Ti consigliamo di esaminare questi gruppi e di assicurarti che le email vengano monitorate in modo affidabile.
Contatti necessari viene utilizzato per uno scopo diverso rispetto ai campi primarycontact
e secondarycontact
configurati nelle etichette del progetto. I contatti nelle etichette dei progetti sono destinati alla governance interna. Ad esempio, se identifichi risorse non conformi in un progetto di carico di lavoro e devi contattare i proprietari, puoi utilizzare il campo primarycontact
per trovare la persona o il team responsabile del carico di lavoro.
Passaggi successivi
- Scopri di più sul networking (documento successivo di questa serie).
Networking
La rete è necessaria per consentire alle risorse di comunicare all'interno della tua Google Cloud organizzazione e tra il tuo ambiente cloud e quello on-premise. Questa sezione descrive la struttura del blueprint per le reti VPC, lo spazio indirizzi IP, DNS, i criteri di firewall e la connettività all'ambiente on-premise.
Topologia di rete
Il repository di blueprint fornisce le seguenti opzioni per la topologia della rete:
- Utilizza reti VPC condivise separate per ogni ambiente, senza traffico di rete consentito direttamente tra gli ambienti.
- Utilizza un modello hub-and-spoke che aggiunge una rete hub per connettere ogni ambiente in Google Cloud, con il traffico di rete tra gli ambienti controllato da un'appliance virtuale di rete (NVA).
Scegli la topologia di rete VPC condivisa doppia quando non vuoi la connettività di rete diretta tra gli ambienti. Scegli la topologia di rete hub-and-spoke quando vuoi consentire la connettività di rete tra ambienti filtrata da un NVA, ad esempio quando ti affidi a strumenti esistenti che richiedono un percorso di rete diretto a ogni server nel tuo ambiente.
Entrambe le topologie utilizzano VPC condiviso come principale elemento di rete perché consente una chiara separazione delle responsabilità. Gli amministratori di rete gestiscono le risorse di rete in un progetto host centralizzato, mentre i team dei carichi di lavoro eseguono il deployment delle proprie risorse di applicazione e utilizzano le risorse di rete nei progetti di servizio collegati al progetto host.
Entrambe le topologia includono una versione di base e una limitata di ogni rete VPC. La rete VPC di base viene utilizzata per le risorse che contengono dati non sensibili, mentre la rete VPC con limitazioni viene utilizzata per le risorse con dati sensibili che richiedono i Controlli di servizio VPC. Per ulteriori informazioni sull'implementazione dei Controlli di servizio VPC, consulta Proteggere le risorse con i Controlli di servizio VPC.
Topologia di rete VPC condivisa doppia
Se hai bisogno di isolamento della rete tra le reti di sviluppo, non di produzione e di produzione su Google Cloud, ti consigliamo la topologia di rete VPC condivisa doppia. Questa topologia utilizza reti VPC condivise separate per ogni ambiente, con ogni ambiente suddiviso ulteriormente in una rete VPC condivisa di base e una rete VPC condivisa con limitazioni.
Il seguente diagramma mostra la topologia della rete VPC condivisa doppia.
Il diagramma descrive i seguenti concetti chiave della topologia VPC condivisa doppia:
- Ogni ambiente (di produzione, non di produzione e di sviluppo) ha una rete VPC condivisa per la rete di base e una rete VPC condivisa per la rete con limitazioni. Questo diagramma mostra solo l'ambiente di produzione, ma lo stesso schema viene ripetuto per ogni ambiente.
- Ogni rete VPC condivisa ha due subnet, ciascuna in una distinta regione.
- La connettività con le risorse on-premise è abilitata tramite quattro VLAN collegamenti all'istanza di interconnessione dedicata per ogni rete VPC condivisa, utilizzando quattro servizi Cloud Router (due in ogni regione per la ridondanza). Per saperne di più, consulta Connettività ibrida tra l'ambiente on-premise e Google Cloud.
Per impostazione predefinita, questa topologia non consente il flusso diretto del traffico di rete tra gli ambienti. Se vuoi che il traffico di rete fluisca direttamente tra gli ambienti, devi eseguire ulteriori passaggi per consentire questo percorso di rete. Ad esempio, potresti configurare gli endpoint Private Service Connect per esporre un servizio da una rete VPC a un'altra rete VPC. In alternativa, puoi configurare la rete on-premise in modo che il traffico fluisca da un ambienteGoogle Cloud all'ambiente on-premise e poi a un altro Google Cloud .
Topologia di rete hub and spoke
Se esegui il deployment di risorse in Google Cloud che richiedono un percorso di rete diretto alle risorse in più ambienti, ti consigliamo la topologia di rete hub and spoke.
La topologia hub-and-spoke utilizza diversi concetti che fanno parte della doppia topologia VPC condivisa, ma la modifica per aggiungere una rete hub. Il seguente diagramma mostra la topologia hub-and-spoke.
Il diagramma descrive i seguenti concetti chiave della topologia di rete hub-and-spoke:
- Questo modello aggiunge una rete hub e ciascuna delle reti di sviluppo, non di produzione e di produzione (spoke) è collegata alla rete hub tramite il peering di rete VPC. In alternativa, se prevedi di superare il limite di quota, puoi utilizzare un gateway VPN ad alta disponibilità.
- La connettività alle reti on-premise è consentita solo tramite la rete dell'hub. Tutte le reti spoke possono comunicare con le risorse condivise nella rete hub e utilizzare questo percorso per connettersi alle reti on-premise.
- Le reti hub includono un NVA per ogni regione, di cui è stato eseguito il deployment in modo ridondante dietro le istanze del bilanciatore del carico di rete interno. Questa NVA funge da gateway per consentire o negare la comunicazione tra le reti spoke.
- La rete hub ospita anche strumenti che richiedono la connettività a tutte le altre reti. Ad esempio, potresti eseguire il deployment di strumenti sulle istanze VM per la gestione della configurazione nell'ambiente comune.
- Il modello hub-and-spoke viene duplicato per una versione di base e una versione limitata di ogni rete.
Per abilitare il traffico da spoke a spoke, il blueprint esegue il deployment di NVA sulla rete VPC condivisa dell'hub che fungono da gateway tra le reti. Le route vengono scambiate tra le reti VPC hub-to-spoke tramite lo scambio di route personalizzate. In questo scenario, la connettività tra gli spoke deve essere instradata tramite l'NVA perché il peering di rete VPC non è transitivo e, pertanto, le reti VPC spoke non possono scambiarsi dati direttamente. Devi configurare le appliance virtuali per consentire in modo selettivo il traffico tra gli spoke.
Pattern di deployment dei progetti
Quando crei nuovi progetti per i carichi di lavoro, devi decidere in che modo le risorse di questo progetto si connettono alla tua rete esistente. La tabella seguente descrive i pattern di implementazione dei progetti utilizzati nel blueprint.
Pattern | Descrizione | Esempio di utilizzo |
---|---|---|
Progetti di base condivisi | Questi progetti sono configurati come progetti di servizio per un progetto host VPC condiviso di base. Utilizza questo pattern quando le risorse del progetto soddisfano i seguenti criteri:
|
example_base_shared_vpc_project.tf |
Progetti condivisi con limitazioni | Questi progetti sono configurati come progetti di servizio per un progetto host VPC condiviso limitato. Utilizza questo pattern quando le risorse del progetto soddisfano i seguenti criteri:
|
example_restricted_shared_vpc_project.tf |
Progetti inutilizzati | I progetti mobili non sono connessi ad altre reti VPC nella tua topologia. Utilizza questo pattern quando le risorse del progetto soddisfano i seguenti criteri:
Potresti trovarti in uno scenario in cui vuoi mantenere la rete VPC di un progetto mobile separata dalla topologia della rete VPC principale, ma anche esporre un numero limitato di endpoint tra le reti. In questo caso, pubblica i servizi utilizzando Private Service Connect per condividere l'accesso alla rete a un singolo endpoint tra le reti VPC senza esporre l'intera rete. |
example_floating_project.tf |
Progetti di peering | I progetti di peering creano le proprie reti VPC e si connettono in peering ad altre reti VPC nella tua topologia. Utilizza questo pattern quando le risorse del progetto soddisfano i seguenti criteri:
Se crei progetti di peering, è tua responsabilità allocare intervalli di indirizzi IP non in conflitto e pianificare la quota del gruppo di peering. |
example_peering_project.tf |
Allocazione degli indirizzi IP
Questa sezione illustra in che modo l'architettura del blueprint alloca gli intervalli di indirizzi IP. Potresti dover modificare gli intervalli di indirizzi IP specifici utilizzati in base alla disponibilità degli indirizzi IP nel tuo ambiente ibrido esistente.
La tabella seguente fornisce un'analisi dello spazio degli indirizzi IP allocato per il blueprint. L'ambiente hub si applica solo alla topologia hub and spoke.
Finalità | Tipo di VPC | Regione | Ambiente hub | Ambiente di sviluppo | Ambiente non di produzione | Ambiente di produzione |
---|---|---|---|---|---|---|
Intervalli di subnet principali | Livelli | Regione 1 | 10.0.0.0/18 | 10.0.64.0/18 | 10.0.128.0/18 | 10.0.192.0/18 |
Regione 2 | 10.1.0.0/18 | 10.1.64.0/18 | 10.1.128.0/18 | 10.1.192.0/18 | ||
Risorse non allocate | 10.{2-7}.0.0/18 | 10.{2-7}.64.0/18 | 10.{2-7}.128.0/18 | 10.{2-7}.192.0/18 | ||
Con restrizioni | Regione 1 | 10.8.0.0/18 | 10.8.64.0/18 | 10.8.128.0/18 | 10.8.192.0/18 | |
Regione 2 | 10.9.0.0/18 | 10.9.64.0/18 | 10.9.128.0/18 | 10.9.192.0/18 | ||
Risorse non allocate | 10.{10-15}.0.0/18 | 10.{10-15}.64.0/18 | 10.{10-15}.128.0/18 | 10.{10-15}.192.0/18 | ||
Accesso privato ai servizi | Livelli | Globale | 10.16.0.0/21 | 10.16.8.0/21 | 10.16.16.0/21 | 10.16.24.0/21 |
Con restrizioni | Globale | 10.16.32.0/21 | 10.16.40.0/21 | 10.16.48.0/21 | 10.16.56.0/21 | |
Endpoint di Private Service Connect | Livelli | Globale | 10.17.0.1/32 | 10.17.0.2/32 | 10.17.0.3/32 | 10.17.0.4/32 |
Con restrizioni | Globale | 10.17.0.5/32 | 10.17.0.6/32 | 10.17.0.7/32 | 10.17.0.8/32 | |
Subnet solo proxy | Livelli | Regione 1 | 10.18.0.0/23 | 10.18.2.0/23 | 10.18.4.0/23 | 10.18.6.0/23 |
Regione 2 | 10.19.0.0/23 | 10.19.2.0/23 | 10.19.4.0/23 | 10.19.6.0/23 | ||
Risorse non allocate | 10.{20-25}.0.0/23 | 10.{20-25}.2.0/23 | 10.{20-25}.4.0/23 | 10.{20-25}.6.0/23 | ||
Con restrizioni | Regione 1 | 10.26.0.0/23 | 10.26.2.0/23 | 10.26.4.0/23 | 10.26.6.0/23 | |
Regione 2 | 10.27.0.0/23 | 10.27.2.0/23 | 10.27.4.0/23 | 10.27.6.0/23 | ||
Risorse non allocate | 10.{28-33}.0.0/23 | 10.{28-33}.2.0/23 | 10.{28-33}.4.0/23 | 10.{28-33}.6.0/23 | ||
Intervalli di subnet secondari | Livelli | Regione 1 | 100.64.0.0/18 | 100.64.64.0/18 | 100.64.128.0/18 | 100.64.192.0/18 |
Regione 2 | 100.65.0.0/18 | 100.65.64.0/18 | 100.65.128.0/18 | 100.65.192.0/18 | ||
Risorse non allocate | 100.{66-71}.0.0/18 | 100.{66-71}.64.0/18 | 100.{66-71}.128.0/18 | 100.{66-71}.192.0/18 | ||
Con restrizioni | Regione 1 | 100.72.0.0/18 | 100.72.64.0/18 | 100.72.128.0/18 | 100.72.192.0/18 | |
Regione 2 | 100.73.0.0/18 | 100.73.64.0/18 | 100.73.128.0/18 | 100.73.192.0/18 | ||
Risorse non allocate | 100.{74-79}.0.0/18 | 100.{74-79}.64.0/18 | 100.{74-79}.128.0/18 | 100.{74-79}.192.0/18 |
La tabella precedente illustra questi concetti per l'allocazione di intervalli di indirizzi IP:
- L'allocazione degli indirizzi IP è suddivisa in intervalli per ogni combinazione di VPC condiviso di base, VPC condiviso limitato, regione e ambiente.
- Alcune risorse sono globali e non richiedono suddivisioni per ogni regione.
- Per impostazione predefinita, per le risorse di regione il blueprint viene implementato in due regioni. Inoltre, sono disponibili intervalli di indirizzi IP inutilizzati che ti consentono di espandere la tua attività in altre sei regioni.
- La rete hub viene utilizzata solo nella topologia di rete hub-and-spoke, mentre gli ambienti di sviluppo, non di produzione e di produzione vengono utilizzati in entrambe le topologie di rete.
La seguente tabella illustra la modalità di utilizzo di ciascun tipo di intervallo di indirizzi IP.
Finalità | Descrizione |
---|---|
Intervalli di subnet principali | Le risorse di cui esegui il deployment nella rete VPC, ad esempio le istanze di macchine virtuali, utilizzano gli indirizzi IP interni di questi intervalli. |
Accesso privato ai servizi | Alcuni Google Cloud servizi come Cloud SQL richiedono di preallocare un intervallo di subnet per l'accesso privato ai servizi. Il blueprint riserva un intervallo /21 a livello globale per ciascuna delle reti VPC condivise per allocare indirizzi IP per i servizi che richiedono l'accesso ai servizi privati. Quando crei un servizio che dipende dall'accesso privato ai servizi, alloca una subnet regionale /24 dall'intervallo /21 riservato. |
Private Service Connect | Il blueprint esegue il provisioning di ogni rete VPC con un endpoint Private Service Connect per comunicare con le API Google Cloud. Questo endpoint consente alle risorse nella rete VPC di raggiungere le API di Google Cloud senza fare affidamento sul traffico in uscita verso internet o su intervalli internet pubblicizzati. |
Bilanciatori del carico basati su proxy | Alcuni tipi di bilanciatori del carico delle applicazioni richiedono di preallocare subnet solo proxy. Anche se il blueprint non esegue il deployment di bilanciatori del carico delle applicazioni che richiedono questo intervallo, l'allocazione degli intervalli in anticipo contribuisce a ridurre le difficoltà per i carichi di lavoro quando devono richiedere un nuovo intervallo di sottorete per attivare determinate risorse del bilanciatore del carico. |
Intervalli di subnet secondari | Alcuni casi d'uso, come i carichi di lavoro basati su container, richiedono intervalli secondari. Il blueprint alloca intervalli dallo spazio di indirizzi IP RFC 6598 per gli intervalli secondari. |
Configurazione DNS centralizzata
Per la risoluzione DNS tra Google Cloud e gli ambienti on-premise, consigliamo di utilizzare un approccio ibrido con due sistemi DNS autorevoli. In questo approccio, Cloud DNS gestisce la risoluzione DNS autorevole per il tuo ambiente e i tuoi server DNS on-premise esistenti gestiscono la risoluzione DNS autorevole per le risorse on-premise.Google Cloud L'ambiente on-premise e l'ambiente Google Cloud eseguono ricerche DNS tra gli ambienti tramite le richieste di inoltro.
Il seguente diagramma mostra la topologia DNS nelle varie reti VPC utilizzate nel progetto.
Il diagramma descrive i seguenti componenti del design DNS di cui viene eseguito il deployment dal blueprint:
- Il progetto DNS hub nella cartella comune è il punto centrale dello scambio DNS tra l'ambiente on-premise e l'ambiente Google Cloud. Il forwarding DNS utilizza le stesse istanze di interconnessione dedicata e gli stessi router Cloud già configurati nella topologia di rete.
- Nella topologia VPC condiviso doppia, l'hub DNS utilizza la rete VPC condiviso di produzione di base.
- Nella topologia hub e spoke, l'hub DNS utilizza la rete VPC condivisa dell'hub di base.
- I server di ogni rete VPC condivisa possono risolvere i record DNS di altre reti VPC condivise tramite l'inoltro DNS, che viene configurato tra Cloud DNS in ogni progetto host VPC condiviso e l'hub DNS.
- I server on-premise possono risolvere i record DNS negli Google Cloud ambienti utilizzando criteri dei server DNS che consentono le query dai server on-premise. Il blueprint configura un criterio del server in entrata nell'hub DNS per allocare gli indirizzi IP e i server DNS on-premise inoltrano le richieste a questi indirizzi. Tutte le richieste DNS devono Google Cloud prima raggiungere l'hub DNS, che poi risolve i record dei peer DNS.
- I server in Google Cloud possono risolvere i record DNS nell'ambiente on-premise utilizzando zone di inoltro che eseguono query sui server on-premise. Tutte le richieste DNS all'ambiente on-premise provengono dall'hub DNS. L'origine della richiesta DNS è 35.199.192.0/19.
Criteri firewall
Google Cloud ha più tipi di criteri firewall. I criteri firewall gerarchici vengono applicati a livello di organizzazione o cartella per ereditare le regole dei criteri firewall in modo coerente in tutte le risorse della gerarchia. Inoltre, puoi configurare le policy firewall di rete per ogni rete VPC. Il blueprint combina questi criteri firewall per applicare configurazioni comuni a tutti gli ambienti utilizzando i criteri firewall gerarchici e per applicare configurazioni più specifiche a ogni singola rete VPC utilizzando i criteri firewall di rete.
Il blueprint non utilizza regole firewall VPC legacy. Ti consigliamo di utilizzare solo i criteri firewall ed evitare di combinarli con le regole firewall VPC legacy.
Criteri firewall gerarchici
Il blueprint definisce un singolo criterio firewall gerarchico e lo associa a ciascuna delle cartelle di produzione, non di produzione, sviluppo, bootstrap e comuni. Questo criterio firewall gerarchico contiene le regole che devono essere applicate in modo generale a tutti gli ambienti e delega la valutazione di regole più granulari al criterio firewall di rete per ogni singolo ambiente.
La tabella seguente descrive le regole delle policy firewall gerarchiche implementate dal blueprint.
Descrizione regola | Direzione del traffico | Filtro (intervallo IPv4) | Protocolli e porte | Azione |
---|---|---|---|---|
Delega la valutazione del traffico in entrata da RFC 1918 ai livelli inferiori della gerarchia. | Ingress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
Delega la valutazione del traffico in uscita a RFC 1918 per i livelli inferiori della gerarchia. | Egress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
IAP per inoltro TCP | Ingress |
35.235.240.0/20 |
tcp:22,3389 |
Allow |
Attivazione di Windows Server | Egress |
35.190.247.13/32 |
tcp:1688 |
Allow |
Controlli di integrità per Cloud Load Balancing | Ingress |
130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22 |
tcp:80,443 |
Allow |
Criteri firewall di rete
Il blueprint configura un criterio firewall di rete per ogni rete. Ogni criterio del firewall di rete inizia con un insieme minimo di regole che consentono l'accesso ai servizi e negano l'uscita a tutti gli altri indirizzi IP. Google Cloud
Nel modello hub and spoke, i criteri del firewall di rete contengono regole aggiuntive per consentire la comunicazione tra gli spoke. Il criterio del firewall di rete consente il traffico in uscita da uno spoke all'hub o a un altro spoke e consente il traffico in entrata dall'NVA nella rete dell'hub.
La tabella seguente descrive le regole nel criterio del firewall di rete globale impiegato per ogni rete VPC nel blueprint.
Descrizione regola | Direzione del traffico | Filtro | Protocolli e porte |
---|---|---|---|
Consenti il traffico in uscita verso le API Google Cloud. | Egress |
L'endpoint Private Service Connect configurato per ogni singola rete. Consulta Accesso privato alle API di Google. | tcp:443 |
Rifiuta il traffico in uscita non corrispondente ad altre regole. | Egress |
tutte | all |
Consenti il traffico in uscita da uno spoke a un altro spoke (solo per il modello hub and spoke). |
Egress |
L'insieme di tutti gli indirizzi IP utilizzati nella topology hub-and-spoke. Il traffico che esce da un VPC spoke viene instradato prima all'NVA nella rete hub. | all |
Consenti il traffico in entrata a uno spoke dall'NVA nella rete hub (solo per il modello hub and spoke). |
Ingress |
Traffico proveniente dalle NVA nella rete hub. | all |
Al primo dispiegamento del blueprint, un'istanza VM in una rete VPC può comunicare con i servizi Google Cloud , ma non con altre risorse di infrastruttura nella stessa rete VPC. Per consentire alle istanze VM di comunicare, devi aggiungere regole aggiuntive al criterio del firewall di rete e ai tag che consentano esplicitamente alle istanze VM di comunicare. I tag vengono aggiunti alle istanze VM e il traffico viene valutato in base a questi tag. Inoltre, i tag dispongono di controlli IAM per consentirti di definirli in modo centralizzato e di delegare il loro utilizzo ad altri team.
Il seguente diagramma mostra un esempio di come puoi aggiungere tag personalizzati e regole dei criteri del firewall di rete per consentire ai carichi di lavoro di comunicare all'interno di una rete VPC.
Il diagramma mostra i seguenti concetti di questo esempio:
- Il criterio firewall di rete contiene la regola 1 che nega il traffico in uscita da tutte le origini con priorità 65530.
- Il criterio firewall di rete contiene la regola 2 che consente il traffico in entrata dalle istanze con il tag
service=frontend
alle istanze con il tagservice=backend
con priorità 999. - La VM istanza-2 può ricevere traffico dall'istanza-1 perché il traffico corrisponde ai tag consentiti dalla regola 2. La regola 2 viene associata prima della valutazione della regola 1, in base al valore della priorità.
- La VM instance-3 non riceve traffico. L'unica regola del criterio firewall che corrisponde a questo traffico è la Regola 1, pertanto il traffico in uscita dall'istanza 1 viene negato.
Accesso privato alle API Google Cloud
Per consentire alle risorse nelle tue reti VPC o nel tuo ambiente on-premise di raggiungere i serviziGoogle Cloud , consigliamo di utilizzare la connettività privata anziché il traffico internet in uscita verso gli endpoint API pubblici. Il blueprint configura Accesso privato Google su ogni sottorete e crea endpoint interni con Private Service Connect per comunicare con i servizi Google Cloud . Se usati insieme, questi controlli consentono un percorso privato ai servizi Google Cloud , senza fare affidamento sul traffico in uscita di internet o su intervalli di internet pubblicizzati.
Il blueprint configura gli endpoint Private Service Connect con bundle di API per distinguere i servizi a cui è possibile accedere in ciascuna rete. La rete di base utilizza il bundle all-apis
e può raggiungere qualsiasi servizio Google, mentre la rete con limitazioni utilizza il bundle vpcsc
che consente l'accesso a un insieme limitato di servizi che supportano Controlli di servizio VPC.
Per l'accesso da host in un ambiente on-premise, ti consigliamo di utilizzare una convenzione di FQDN personalizzati per ogni endpoint, come descritto nella tabella seguente. Il blueprint utilizza un endpoint Private Service Connect unico per ogni rete VPC, configurato per l'accesso a un insieme diverso di bundle di API. Pertanto, devi considerare come instradare il traffico di servizio dall'ambiente on-premise alla rete VPC con l'endpoint API corretto e, se utilizzi i Controlli di servizio VPC, assicurarti che il traffico verso i servizi raggiunga l'endpoint all'interno del perimetro previsto. Google Cloud Configura i controlli on-premise per DNS, firewall e router in modo da consentire l'accesso a questi endpoint e configura gli host on-premise in modo che utilizzino l'endpoint appropriato. Per saperne di più, consulta accedere alle API di Google tramite endpoint.
La tabella seguente descrive gli endpoint Private Service Connect creati per ogni rete.
VPC | Ambiente | Pacchetto di API | Indirizzo IP dell'endpoint Private Service Connect | FQDN personalizzato | ||||
---|---|---|---|---|---|---|---|---|
Livelli | Comune | all-apis |
10.17.0.1/32 | c.private.googleapis.com |
||||
Sviluppo | all-apis |
10.17.0.2/32 | d.private.googleapis.com |
|||||
Non di produzione | all-apis |
10.17.0.3/32 | n.private.googleapis.com |
|||||
Produzione | all-apis |
10.17.0.4/32 | p.private.googleapis.com |
|||||
Con restrizioni | Comune | vpcsc |
10.17.0.5/32 | c.restricted.googleapis.com |
||||
Sviluppo | vpcsc |
10.17.0.6/32 | d.restricted.googleapis.com |
|||||
Non di produzione | vpcsc |
10.17.0.7/32 | n.restricted.googleapis.com |
|||||
Produzione | vpcsc |
10.17.0.8/32 | p.restricted.googleapis.com |
Per garantire che il traffico per i Google Cloud servizi abbia una ricerca DNS per l'endpoint corretto, il blueprint configura zone DNS private per ogni rete VPC. La tabella seguente descrive queste zone DNS private.
Nome zona privata | Nome DNS | Tipo di record | Dati |
---|---|---|---|
googleapis.com. |
*.googleapis.com. |
CNAME |
private.googleapis.com. (per le reti di base) o restricted.googleapis.com. (per le reti con limitazioni) |
private.googleapis.com (per le reti di base) o restricted.googleapis.com (per le reti con limitazioni) |
A |
L'indirizzo IP dell'endpoint Private Service Connect per la rete VPC. | |
gcr.io. |
*.gcr.io |
CNAME |
gcr.io. |
gcr.io |
A |
L'indirizzo IP dell'endpoint Private Service Connect per la rete VPC. | |
pkg.dev. |
*.pkg.dev. |
CNAME |
pkg.dev. |
pkg.dev. |
A |
L'indirizzo IP dell'endpoint Private Service Connect per la rete VPC. |
Il blueprint contiene configurazioni aggiuntive per garantire che questi endpoint Private Service Connect vengano utilizzati in modo coerente. Ogni rete VPC condivisa applica inoltre quanto segue:
- Una regola del criterio del firewall di rete che consente il traffico in uscita da tutte le fonti all'indirizzo IP dell'endpoint Private Service Connect su TCP:443.
- Una regola del criterio del firewall di rete che nega il traffico in uscita a 0.0.0.0/0, inclusi i domini predefiniti che vengono utilizzati per accedere ai Google Cloud servizi.
Connettività internet
Il blueprint non consente il traffico in entrata o in uscita tra le sue reti VPC e internet. Per i carichi di lavoro che richiedono la connettività a internet, devi eseguire ulteriori passaggi per progettare i percorsi di accesso richiesti.
Per i workload che richiedono traffico in uscita verso internet, ti consigliamo di gestire il traffico in uscita tramite Cloud NAT per consentire il traffico in uscita senza connessioni in entrata non richieste oppure tramite Secure Web Proxy per un controllo più granulare in modo da consentire il traffico in uscita solo per i servizi web attendibili.
Per i carichi di lavoro che richiedono traffico in entrata da internet, ti consigliamo di progettarli con Cloud Load Balancing e Google Cloud Armor per usufruire delle protezioni DDoS e WAF.
Sconsigliamo di progettare carichi di lavoro che consentano la connettività diretta tra internet e una VM utilizzando un indirizzo IP esterno sulla VM.
Connettività ibrida tra un ambiente on-premise e Google Cloud
Per stabilire la connettività tra l'ambiente on-premise e Google Cloud, ti consigliamo di utilizzare Dedicated Interconnect per massimizzare la sicurezza e l'affidabilità. Una connessione di Dedicated Interconnect è un collegamento diretto tra la tua rete on-premise eGoogle Cloud.
Il seguente diagramma mostra la connettività ibrida tra l'ambiente on-premise e una rete Google Virtual Private Cloud.
Il diagramma descrive i seguenti componenti del pattern per la disponibilità del 99,99% per Dedicated Interconnect:
- Quattro connessioni Dedicated Interconnect, con due connessioni in un'area metropolitana (metro) e due connessioni in un'altra area metropolitana. All'interno di ogni area metropolitana, la struttura di colocation ha due zone distinte.
- Le connessioni sono suddivise in due coppie, ciascuna connessa a un data center on-premise separato.
- I collegamenti VLAN vengono utilizzati per connettere ogni istanza Dedicated Interconnect ai router cloud collegati alla topologia VPC condivisa.
- Ogni rete VPC condivisa ha quattro router Cloud, due in ogni regione, con la modalità di routing dinamico impostata su
global
in modo che ogni router Cloud possa annunciare tutte le subnet, indipendentemente dalla regione.
Con il routing dinamico globale, Cloud Router pubblicizza le route per tutte le reti sottoreti della rete VPC. Cloud Router annuncia le route alle subnet remote (subnet al di fuori della regione del router Cloud) con una priorità inferiore rispetto alle subnet locali (subnet nella regione del router Cloud). Se vuoi, puoi modificare prefi e priorità pubblicizzati quando configuri la sessione BGP per un router Cloud.
Il traffico da Google Cloud a un ambiente on-premise utilizza il router Cloud più vicino alle risorse cloud. All'interno di un'unica regione, più route per le reti on-premise hanno lo stesso valore del discriminatore di più uscite (MED) e Google Cloud utilizzano il routing ECMP (Equal-cost multipath) per distribuire il traffico in uscita tra tutti i route possibili.
Modifiche alla configurazione on-premise
Per configurare la connettività tra l'ambiente on-premise eGoogle Cloud, devi apportare ulteriori modifiche nell'ambiente on-premise. Il codice Terraform nel blueprint configura automaticamente le risorseGoogle Cloud , ma non modifica le risorse di rete on-premise.
Alcuni dei componenti per la connettività ibrida dal tuo ambiente on-premise a Google Cloud vengono attivati automaticamente dal blueprint, tra cui:
- Cloud DNS è configurato con l'inoltro DNS tra tutte le reti VPC condivise a un singolo hub, come descritto nella configurazione DNS. Un criterio del server Cloud DNS è configurato con indirizzi IP dei forwarder in entrata.
- Cloud Router è configurato per esportare route per tutte le subnet e route personalizzate per gli indirizzi IP utilizzati dagli endpoint Private Service Connect.
Per attivare la connettività ibrida, devi svolgere i seguenti passaggi aggiuntivi:
- Ordina una connessione Dedicated Interconnect.
- Configura i router e i firewall on-premise per consentire il traffico in uscita allo spazio degli indirizzi IP interno definito nell'allocazione dello spazio degli indirizzi IP.
- Configura i server DNS on-premise in modo che inoltrino le ricerche DNS destinate aGoogle Cloud agli indirizzi IP dei forwarder in entrata già configurati dal blueprint.
- Configura i server DNS, i firewall e i router on-premise in modo che accettino le query DNS dalla zona di inoltro Cloud DNS (35.199.192.0/19).
- Configura i server DNS on-premise in modo che rispondano alle query degli host on-premise ai Google Cloud servizi con gli indirizzi IP definiti in accesso privato alle API Cloud.
- Per la crittografia in transito tramite la connessione Dedicated Interconnect, configura MACsec per Cloud Interconnect o VPN ad alta disponibilità su Cloud Interconnect per la crittografia IPsec.
Per saperne di più, consulta Accesso privato Google per gli host on-premise.
Passaggi successivi
- Scopri di più sui controlli di rilevamento (documento successivo di questa serie).
Controlli di rilevamento
Le funzionalità di rilevamento e monitoraggio delle minacce vengono fornite utilizzando una combinazione di controlli di sicurezza integrati di Security Command Center e soluzioni personalizzate che ti consentono di rilevare e rispondere agli eventi di sicurezza.
Logging centralizzato per sicurezza e controllo
Il blueprint configura le funzionalità di logging per monitorare e analizzare le modifiche apportate alle Google Cloud risorse con log aggregati in un unico progetto.
Il seguente diagramma mostra come il blueprint aggrega i log di più fonti in più progetti in un'area di destinazione dei log centralizzata.
Il diagramma descrive quanto segue:
- I sink di log vengono configurati nel nodo dell'organizzazione per aggregare i log di tutti i progetti nella gerarchia delle risorse.
- Sono configurati più destinazioni dei log per inviare i log corrispondenti a un filtro a diverse destinazioni per l'archiviazione e l'analisi.
- Il progetto
prj-c-logging
contiene tutte le risorse per lo stoccaggio e l'analisi dei log. - Se vuoi, puoi configurare strumenti aggiuntivi per esportare i log in un SIEM.
Il blueprint utilizza origini log diverse e include questi log nel filtro del sink di log in modo che possano essere esportati in una destinazione centralizzata. La tabella seguente descrive le origini log.
Sorgente log |
Descrizione |
---|---|
Non puoi configurare, disattivare o escludere gli audit log per le attività di amministrazione. |
|
Non puoi configurare, disattivare o escludere gli audit log degli eventi di sistema. |
|
Non puoi configurare o disattivare gli audit log relativi ai rifiuti ai sensi delle norme, ma puoi eventualmente escluderli con i filtri di esclusione. |
|
Per impostazione predefinita, il blueprint non attiva i log di accesso ai dati perché il volume e il costo di questi log possono essere elevati. Per determinare se devi attivare i log di accesso ai dati, valuta dove i tuoi carichi di lavoro gestiscono dati sensibili e valuta se hai la necessità di attivare i log di accesso ai dati per ogni servizio e ambiente che utilizza dati sensibili. |
|
Il blueprint attiva i log di flusso VPC per ogni subnet. Il blueprint configura il campionamento dei log per campionare il 50% dei log al fine di ridurre i costi. Se crei subnet aggiuntive, devi assicurarti che i log di flusso VPC siano abilitati per ogni subnet. |
|
Il blueprint attiva il logging delle regole firewall per ogni regola del criterio firewall. Se crei regole di policy firewall aggiuntive per i carichi di lavoro, devi assicurarti che il logging delle regole firewall sia abilitato per ogni nuova regola. |
|
Il blueprint attiva i log di Cloud DNS per le zone gestite. Se crei altre zone gestite, devi attivare questi log DNS. |
|
Richiede un passaggio di abilitazione una tantum che non è automatizzato dal blueprint. Per ulteriori informazioni, consulta Condividere i dati con iGoogle Cloud servizi. |
|
Richiede un passaggio di abilitazione una tantum che non è automatizzato dal blueprint. Per ulteriori informazioni, vedi Attivare Access Transparency. |
La tabella seguente descrive i canali di log e il loro utilizzo con le destinazioni supportate nel blueprint.
Sink |
Destinazione |
Finalità |
---|---|---|
|
Log indirizzati ai bucket Cloud Logging con Log Analytics e un set di dati BigQuery collegato abilitato |
Analizza attivamente i log. Esegui indagini ad hoc utilizzando Logs Explorer nella console o scrivi query, report e visualizzazioni SQL utilizzando il set di dati BigQuery collegato. |
|
Archivia i log a lungo termine per scopi di conformità, controllo e monitoraggio degli incidenti. Se hai requisiti di conformità per la conservazione obbligatoria dei dati, ti consigliamo di configurare anche Blocco benne. |
|
|
Esportare i log in una piattaforma esterna, ad esempio il tuo SIEM esistente. Ciò richiede un lavoro aggiuntivo per l'integrazione con il tuo SIEM, ad esempio i seguenti meccanismi:
|
Per indicazioni su come attivare tipi di log aggiuntivi e scrivere filtri per i sink dei log, consulta lo strumento di definizione dell'ambito dei log.
Monitoraggio delle minacce con Security Command Center
Ti consigliamo di attivare Security Command Center Premium per consentire alla tua organizzazione di rilevare automaticamente minacce, vulnerabilità ed errori di configurazione nelle tue risorse Google Cloud . Security Command Center crea risultati relativi alla sicurezza da più origini, tra cui:
- Security Health Analytics: rileva vulnerabilità e configurazioni errate comuni nelle Google Cloud risorse.
- Esposizione al percorso di attacco: mostra un percorso simulato di come un utente malintenzionato potrebbe sfruttare le tue risorse di alto valore, in base alle vulnerabilità e alle configurazioni errate rilevate da altre origini di Security Command Center.
- Event Threat Detection: applica la logica di rilevamento e l'intelligence sulle minacce proprietaria ai tuoi log per identificare le minacce quasi in tempo reale.
- Container Threat Detection: rileva gli attacchi comuni a runtime dei container.
- Virtual Machine Threat Detection: rileva le applicazioni potenzialmente dannose in esecuzione sulle macchine virtuali.
- Web Security Scanner: esegue la scansione delle vulnerabilità OWASP Top Ten nelle applicazioni rivolte al web su Compute Engine, App Engine o Google Kubernetes Engine.
Per ulteriori informazioni sulle vulnerabilità e sulle minacce affrontate da Security Command Center, consulta le origini di Security Command Center.
Devi attivare Security Command Center dopo aver eseguito il deployment del blueprint. Per istruzioni, consulta Attivare Security Command Center per un'organizzazione.
Dopo aver attivato Security Command Center, ti consigliamo di esportare i risultati prodotti da Security Command Center nei tuoi strumenti o processi esistenti per la valutazione e la risposta alle minacce. Il blueprint crea il progetto prj-c-scc
con un
argomento Pub/Sub da utilizzare per questa integrazione. A seconda degli strumenti
esistenti, utilizza uno dei seguenti metodi per esportare i risultati:
- Se utilizzi la console per gestire i risultati di sicurezza direttamente in Security Command Center, configura ruoli a livello di cartella e di progetto per Security Command Center in modo che i team possano visualizzare e gestire i risultati di sicurezza solo per i progetti di cui sono responsabili.
Se utilizzi Google SecOps come SIEM, importa Google Cloud i dati in Google SecOps.
Se utilizzi uno strumento SIEM o SOAR con integrazioni in Security Command Center, condividi i dati con Cortex XSOAR, Elastic Stack, ServiceNow, Splunk o QRadar.
Se utilizzi uno strumento esterno che può importare i risultati da Pub/Sub, configura le esportazioni continue in Pub/Sub e configura gli strumenti esistenti per importare i risultati dall'argomento Pub/Sub.
Soluzione personalizzata per l'analisi automatica dei log
Potresti avere requisiti per creare avvisi per eventi di sicurezza basati su query personalizzate sui log. Le query personalizzate possono contribuire a integrare le funzionalità del tuo SIEM analizzando i log su Google Cloud e esportando solo gli eventi che meritano di essere esaminati, soprattutto se non hai la capacità di esportare tutti i log cloud nel tuo SIEM.
Il blueprint consente di attivare questa analisi dei log impostando un'origine centralizzata
di log su cui puoi eseguire query utilizzando un set di dati BigQuery collegato. Per
automatizzare questa funzionalità, devi implementare l'esempio di codice in
bq-log-alerting
e estendere le funzionalità di base. Il codice di esempio ti consente di eseguire regolarmente query su un'origine log e di inviare un risultato personalizzato a Security Command Center.
Il seguente diagramma illustra il flusso di alto livello dell'analisi automatica dei log.
Il diagramma mostra i seguenti concetti di analisi automatica dei log:
- I log di varie origini vengono aggregati in un bucket di log centralizzato con analisi dei log e un set di dati BigQuery collegato.
- Le viste BigQuery sono configurate per eseguire query sui log relativi all'evento di sicurezza che vuoi monitorare.
- Cloud Scheduler invia un evento a un argomento Pub/Sub ogni 15 minuti e attiva le funzioni Cloud Run.
- Le funzioni Cloud Run eseguono query sulle visualizzazioni per trovare nuovi eventi. Se trova eventi, li invia a Security Command Center come risultati personalizzati.
- Security Command Center pubblica notifiche sui nuovi risultati in un altro argomento Pub/Sub.
- Uno strumento esterno come un SIEM si iscrive all'argomento Pub/Sub per importare i nuovi risultati.
Il sample ha diversi casi di utilizzo per eseguire query in cerca di comportamenti potenzialmente sospetti. Alcuni esempi sono un accesso da un elenco di super amministratori o altri account con privilegi elevati specificati da te, modifiche alle impostazioni di registrazione o modifiche alle route di rete. Puoi estendere i casi d'uso scrivendo nuove visualizzazioni query per i tuoi requisiti. Scrivi le tue query o fai riferimento all'analisi dei log di sicurezza per una libreria di query SQL che ti aiuti ad analizzare i log Google Cloud .
Soluzione personalizzata per rispondere alle modifiche delle risorse
Per rispondere agli eventi in tempo reale, ti consigliamo di utilizzare l'inventario asset di Cloud per monitorare le modifiche agli asset. In questa soluzione personalizzata, un feed di asset è configurato per attivare notifiche su Pub/Sub relative alle modifiche alle risorse in tempo reale e poi le funzioni Cloud Run eseguono codice personalizzato per applicare la tua logica aziendale in base a se la modifica deve essere consentita.
Il blueprint contiene un esempio di questa soluzione di governance personalizzata che monitora le modifiche IAM che aggiungono ruoli altamente sensibili, tra cui Amministratore dell'organizzazione, Proprietario ed Editor. Il seguente diagramma descrive questa soluzione.
Il diagramma precedente mostra i seguenti concetti:
- Vengono apportate modifiche a un criterio di autorizzazione.
- Il feed di inventario degli asset cloud invia una notifica in tempo reale relativa alla modifica del criterio di autorizzazione a Pub/Sub.
- Pub/Sub attiva una funzione.
- Le funzioni Cloud Run eseguono codice personalizzato per applicare le norme. La funzione example ha una logica per valutare se la modifica ha aggiunto i ruoli Amministratore dell'organizzazione, Proprietario o Editor a un criterio di autorizzazione. In questo caso, la funzione crea un risultato di sicurezza personalizzato e lo invia a Security Command Center.
- Se vuoi, puoi utilizzare questo modello per automatizzare le attività di correzione. Scrivi logica di business aggiuntiva nelle funzioni Cloud Run per intervenire automaticamente sul ritrovato, ad esempio ripristinando il criterio di autorizzazione allo stato precedente.
Inoltre, puoi estendere l'infrastruttura e la logica utilizzata da questa soluzione di esempio per aggiungere risposte personalizzate ad altri eventi importanti per la tua attività.
Passaggi successivi
- Scopri di più sui controlli preventivi (documento successivo di questa serie).
Controlli preventivi per configurazioni delle risorse accettabili
Ti consigliamo di definire vincoli dei criteri che impongano configurazioni delle risorse accettabili e impediscano configurazioni rischiose. Il blueprint utilizza una combinazione di vincoli dei criteri dell'organizzazione e convalida dell'infrastruttura come codice (IaC) nella pipeline. Questi controlli impediscono la creazione di risorse che non rispettano le linee guida dei tuoi criteri. L'applicazione di questi controlli all'inizio della progettazione e della creazione dei carichi di lavoro ti aiuta a evitare di dover eseguire in un secondo momento attività di correzione.
Vincoli dei criteri dell'organizzazione
Il servizio Criteri dell'organizzazione applica vincoli per garantire che determinate configurazioni delle risorse non possano essere create nella tua Google Cloud organizzazione, anche da un utente con un ruolo IAM sufficientemente privilegiato.
Il blueprint applica i criteri al nodo dell'organizzazione in modo che questi controlli vengano ereditati da tutte le cartelle e da tutti i progetti all'interno dell'organizzazione. Questo insieme di criteri è progettato per impedire determinate configurazioni ad alto rischio, come l'esposizione di una VM alla rete internet pubblica o la concessione dell'accesso pubblico ai bucket di archiviazione, a meno che non consenta deliberatamente un'eccezione al criterio.
La tabella seguente illustra i limiti dei criteri dell'organizzazione implementati nel blueprint:
Vincolo delle policy dell'organizzazione | Descrizione |
---|---|
| La virtualizzazione nidificata sulle VM di Compute Engine può aggirare il monitoraggio e altri strumenti di sicurezza per le VM se non è configurata correttamente. Questo vincolo impedisce la creazione di virtualizzazione nidificata. |
| I ruoli IAM come |
| Le subnet IPv6 esterne possono essere esposte ad accessi internet non autorizzati se sono configurate in modo errato. Questo vincolo impedisce la creazione di subnet IPv6 esterne. |
| Il comportamento predefinito di impostazione delle chiavi SSH nei metadati può consentire l'accesso remoto non autorizzato alle VM se le chiavi sono esposte. Questo vincolo impone l'utilizzo di OS Login anziché di chiavi SSH basate su metadati. |
|
L'inoltro del protocollo VM per gli indirizzi IP esterni può comportare un'uscita non autorizzata su internet se l'inoltro non è configurato correttamente. Questo vincolo consente di inoltrare il protocollo VM solo per gli indirizzi interni. |
|
L'eliminazione di un progetto host VPC condiviso può causare interruzioni in tutti i progetti di servizio che utilizzano risorse di rete. Questo vincolo impedisce l'eliminazione accidentale o dannosa dei progetti host con VPC condivise impedendo la rimozione del blocco su questi progetti. |
|
Un'impostazione precedente per il DNS interno globale (a livello di progetto) non è consigliata perché riduce la disponibilità del servizio. Questo vincolo impedisce l'utilizzo dell'impostazione precedente. |
| In ogni nuovo progetto che attiva l'API Compute Engine vengono create una rete VPC predefinita e regole firewall VPC predefinite eccessivamente permissive. Questo vincolo ignora la creazione della rete predefinita e delle regole firewall VPC predefinite. |
| Per impostazione predefinita, viene creata una VM con un indirizzo IPv4 esterno che può comportare l'accesso non autorizzato a internet. Questo vincolo configura una lista consentita vuota di indirizzi IP esterni che la VM può utilizzare e nega tutti gli altri. |
|
Per impostazione predefinita, Contatti necessari può essere configurato per inviare notifiche sul tuo dominio a qualsiasi altro dominio. Questo vincolo impone che solo gli indirizzi email dei domini approvati possano essere impostati come destinatari per i Contatti necessari. |
| Per impostazione predefinita, i criteri di autorizzazione possono essere concessi a qualsiasi Account Google, inclusi gli account non gestiti e quelli appartenenti a organizzazioni esterne. Questo vincolo garantisce che i criteri di autorizzazione nella tua organizzazione possano essere concessi solo agli account gestiti del tuo dominio. Se vuoi, puoi consentire domini aggiuntivi. |
|
Per impostazione predefinita, ai service account predefiniti vengono concessi automaticamente ruoli eccessivamente permissivi. Questo vincolo impedisce le concessioni automatiche dei ruoli IAM agli account di servizio predefiniti. |
|
Le chiavi dei service account sono credenziali permanenti ad alto rischio e, nella maggior parte dei casi, è possibile utilizzare un'alternativa più sicura alle chiavi dei service account. Questo vincolo impedisce la creazione di chiavi dell'account di servizio. |
|
Il caricamento del materiale delle chiavi dell'account di servizio può aumentare il rischio se il materiale delle chiavi viene esposto. Questo vincolo impedisce il caricamento delle chiavi degli account di servizio. |
|
Le istanze Cloud SQL possono essere esposte all'accesso non autenticato a internet se sono configurate per utilizzare reti autorizzate senza un proxy di autenticazione Cloud SQL. Questa norma impedisce la configurazione delle reti autorizzate per l'accesso al database e forza l'utilizzo del proxy di autenticazione Cloud SQL. |
| Le istanze Cloud SQL possono essere esposte all'accesso a internet non autenticato se vengono create con indirizzi IP pubblici. Questo vincolo impedisce l'utilizzo di indirizzi IP pubblici nelle istanze Cloud SQL. |
| Per impostazione predefinita, è possibile accedere agli oggetti in Cloud Storage tramite gli elenchi di controllo dell'accesso (ACL) legacy anziché tramite IAM, il che può comportare controlli di accesso incoerenti ed esposizione accidentale in caso di configurazione errata. L'accesso ACL precedente non è
interessato dal vincolo |
|
I bucket Cloud Storage possono essere esposti all'accesso a internet non autenticato se sono configurati in modo errato. Questo vincolo impedisce gli ACL e le autorizzazioni IAM che consentono di accedere a |
Queste norme sono un punto di partenza consigliato per la maggior parte dei clienti e per la maggior parte degli scenari, ma potrebbe essere necessario modificare i vincoli delle norme dell'organizzazione per supportare determinati tipi di carichi di lavoro. Ad esempio, un carico di lavoro che utilizza un
bucket Cloud Storage come backend per Cloud CDN per ospitare
risorse pubbliche è bloccato da storage.publicAccessPrevention
o un'app Cloud Run rivolta al pubblico che non richiede autenticazione è bloccata da iam.allowedPolicyMemberDomains
. In questi casi, modifica il criterio dell'organizzazione a livello di cartella o progetto per consentire un'eccezione specifica.
Puoi anche aggiungere vincoli ai criteri dell'organizzazione in modo condizionale
definendo un tag che concede un'eccezione o l'applicazione dei criteri, quindi
applicandolo ai progetti e alle cartelle.
Per vincoli aggiuntivi, consulta i vincoli disponibili e i vincoli personalizzati.
Convalida pre-deployment dell'infrastruttura come codice
Il blueprint utilizza un approccio GitOps per gestire l'infrastruttura, il che significa che tutte le modifiche dell'infrastruttura vengono implementate tramite l'infrastruttura come codice (IaC) con controllo della versione e possono essere convalidate prima del deployment.
I criteri applicati nel blueprint definiscono le configurazioni delle risorse accettabili che possono essere implementate dalla pipeline. Se il codice inviato al tuo repository GitHub non supera i controlli dei criteri, non viene dispiegato nessuna risorsa.
Per informazioni su come vengono utilizzate le pipeline e su come vengono applicati i controlli tramite l'automazione CI/CD, consulta la metodologia di deployment.
Passaggi successivi
- Leggi la sezione sulla metodologia di implementazione (documento successivo di questa serie)
Metodologia di deployment
Ti consigliamo di utilizzare l'infrastruttura dichiarativa per eseguire il deployment della base in modo coerente e controllabile. Questo approccio consente di attivare una governance coerente applicando controlli dei criteri sulle configurazioni delle risorse accettabili nelle pipeline. Il blueprint viene implementato utilizzando un flusso GitOps, con Terraform utilizzato per definire l'infrastruttura come codice (IaC), un repository Git per il controllo della versione e l'approvazione del codice e Cloud Build per l'automazione CI/CD nella pipeline di deployment. Per un'introduzione a questo concetto, consulta la sezione Gestione dell'infrastruttura come codice con Terraform, Cloud Build e GitOps.
Le sezioni seguenti descrivono come viene utilizzata la pipeline di deployment per gestire le risorse della tua organizzazione.
Livelli della pipeline
Per separare i team e lo stack tecnologico responsabili della gestione di diversi livelli del tuo ambiente, consigliamo un modello che utilizzi pipeline e persone diverse responsabili di ogni livello dello stack.
Il seguente diagramma illustra il nostro modello consigliato per separare una pipeline di base, una pipeline di infrastruttura e una pipeline di applicazione.
Il diagramma mostra gli strati della pipeline in questo modello:
- La pipeline di base esegue il deployment delle risorse di base utilizzate nella piattaforma. Consigliamo di affidare a un unico team centrale la gestione delle risorse di base utilizzate da più unità aziendali e carichi di lavoro.
- La pipeline di infrastruttura esegue il deployment di progetti e infrastrutture utilizzati dai carichi di lavoro, ad esempio istanze VM o database. Il blueprint configura una pipeline di infrastruttura separata per ogni unità aziendale oppure puoi optare per una sola pipeline di infrastruttura utilizzata da più team.
- La pipeline di applicazioni esegue il deployment degli elementi per ogni carico di lavoro, ad esempio container o immagini. Potresti avere molti team di applicazioni diversi con singole pipeline di applicazioni.
Le sezioni seguenti illustrano l'utilizzo di ogni livello della pipeline.
La pipeline di base
La pipeline di base esegue il deployment delle risorse di base. Configura inoltre la pipeline di infrastruttura utilizzata per eseguire il deployment dell'infrastruttura utilizzata dai carichi di lavoro.
Per creare la pipeline di base, devi prima clonare o eseguire il fork di terraform-example-foundation nel tuo repository Git. Segui i passaggi descritti nel
file README di 0-bootstrap
per configurare la cartella e le risorse di bootstrap.
Fase | Descrizione |
---|---|
Esegue il bootstrap di un' Google Cloud organizzazione. Questo passaggio configura anche una pipeline CI/CD per il codice del blueprint nelle fasi successive.
|
Dopo aver creato la pipeline di base nella fase 0-bootstrap
, le fasi seguenti eseguono il deployment delle risorse nella pipeline di base. Esamina le istruzioni del file README per ogni fase e implementale in sequenza.
Fase | Descrizione |
---|---|
Configura cartelle condivise di primo livello, progetti per servizi condivisi, logging a livello di organizzazione e impostazioni di sicurezza di base tramite i criteri dell'organizzazione. |
|
Configura gli ambienti di sviluppo, non di produzione e di produzione all'interno Google Cloud dell'organizzazione che hai creato. |
|
o |
Configura le VPC condivise nella topologia scelta e le risorse di rete associate. |
La pipeline dell'infrastruttura
La pipeline di infrastruttura esegue il deployment dei progetti e dell'infrastruttura (ad esempio le istanze VM e i database) utilizzati dai carichi di lavoro. La pipeline di base esegue il deployment di più pipeline di infrastruttura. Questa separazione tra la pipeline di base e la pipeline di infrastruttura consente di distinguere le risorse a livello di piattaforma da quelle specifiche del carico di lavoro.
Il seguente diagramma descrive come il blueprint configura più pipeline di infrastruttura destinate all'utilizzo da parte di team distinti.
Il diagramma descrive i seguenti concetti chiave:
- Ogni pipeline di infrastruttura viene utilizzata per gestire le risorse dell'infrastruttura indipendente dalle risorse di base.
- Ogni unità aziendale ha la propria pipeline di infrastruttura, gestita in un progetto dedicato nella cartella
common
. - Ognuna delle pipeline di infrastruttura ha un account di servizio con l'autorizzazione per eseguire il deployment delle risorse solo nei progetti associati a quell'unità aziendale. Questa strategia crea una separazione dei compiti tra gli account di servizio con privilegi utilizzati per la pipeline di base e quelli utilizzati da ogni pipeline di infrastruttura
Questo approccio con più pipeline di infrastruttura è consigliato quando hai più entità all'interno della tua organizzazione che dispongono delle competenze e della volontà di gestire la propria infrastruttura separatamente, in particolare se hanno requisiti diversi, ad esempio i tipi di criteri di convalida della pipeline che vogliono applicare. In alternativa, potresti preferire avere una singola pipeline di infrastruttura gestita da un unico team con criteri di convalida coerenti.
In terraform-example-foundation, la fase 4 configura una pipeline di infrastruttura e la fase 5 mostra un esempio di utilizzo della pipeline per eseguire il deployment delle risorse di infrastruttura.
Fase | Descrizione |
---|---|
Configura una struttura di cartelle, progetti e una pipeline di infrastruttura. |
|
|
Esegue il deployment di progetti di carichi di lavoro con un'istanza Compute Engine utilizzando la pipeline di infrastruttura come esempio. |
La pipeline di applicazione
La pipeline di applicazioni è responsabile del deployment degli artefatti dell'applicazione per ogni singolo carico di lavoro, ad esempio immagini o container Kubernetes che eseguono la logica di business dell'applicazione. Questi elementi vengono di cui vengono eseguiti i deployment nelle risorse dell'infrastruttura di cui è stato eseguito il deployment dalla pipeline dell'infrastruttura.
Il progetto della piattaforma aziendale configura la pipeline di base e la pipeline di infrastruttura, ma non esegue il deployment di una pipeline di applicazioni. Per un esempio di pipeline di applicazioni, consulta il blueprint dell'applicazione aziendale.
Automatizzare la pipeline con Cloud Build
Il blueprint utilizza Cloud Build per automatizzare i processi CI/CD. La tabella seguente descrive i controlli integrati nella pipeline di base e nella pipeline di infrastruttura di cui viene eseguito il deployment dal repository terraform-example-foundation. Se stai sviluppando le tue pipeline utilizzando altri strumenti di automazione CI/CD, ti consigliamo di applicare controlli simili.
Controllo | Descrizione |
---|---|
Configurazioni di compilazione separate per convalidare il codice prima del deployment |
Il blueprint utilizza due file di configurazione della build di Cloud Build per tutta la pipeline e ogni repository associato a una fase ha due trigger di Cloud Build associati a questi file di configurazione della build. Quando il codice viene inviato a un ramo del repository, i file di configurazione di compilazione vengono attivati per eseguire prima |
Controlli dei criteri di Terraform | Il blueprint include un insieme di vincoli di Open Policy Agent che vengono applicati dalla convalida dei criteri in Google Cloud CLI. Questi vincoli definiscono le configurazioni delle risorse accettabili che possono essere implementate dalla pipeline. Se una build non soddisfa i criteri nella prima configurazione della build, la seconda configurazione della build non esegue il deployment di alcuna risorsa. I criteri
applicati nel progetto base sono derivati da |
Principio del privilegio minimo | La pipeline di base ha un account di servizio diverso per ogni fase con un criterio di autorizzazione che concede solo i ruoli IAM minimi per quella fase. Ogni trigger Cloud Build viene eseguito come account di servizio specifico per la fase in questione. L'utilizzo di account diversi consente di ridurre il rischio che la modifica di un repository possa influire sulle risorse gestite da un altro repository. Per comprendere i ruoli IAM specifici applicati a ciascun
service account, consulta il |
Pool privati di Cloud Build | Il blueprint utilizza i pool privati di Cloud Build. I pool privati ti consentono, facoltativamente, di applicare controlli aggiuntivi, ad esempio limitare l'accesso ai repository pubblici o eseguire Cloud Build all'interno di un perimetro dei Controlli di servizio VPC. |
Costruttori personalizzati Cloud Build | Il blueprint crea il proprio compilatore personalizzato per eseguire Terraform. Per ulteriori informazioni, vedi |
Approvazione del deployment | Se vuoi, puoi aggiungere una fase di approvazione manuale a Cloud Build. Questa approvazione aggiunge un ulteriore punto di controllo dopo l'attivazione della build, ma prima dell'esecuzione, in modo che un utente con privilegi possa approvare manualmente la build. |
Strategia di ramificazione
Ti consigliamo una strategia di ramo permanente per inviare il codice al tuo sistema Git e implementare le risorse tramite la pipeline di base. Il seguente diagramma descrive la strategia di ramoscello permanente.
Il diagramma descrive tre branch permanenti in Git (sviluppo, non di produzione e di produzione) che riflettono gli ambientiGoogle Cloud corrispondenti. Esistono anche più ramificazioni di funzionalità temporanee che non corrispondono alle risorse di cui è stato eseguito il deployment nei tuoi ambientiGoogle Cloud .
Ti consigliamo di applicare una procedura di pull request (PR) al tuo sistema Git in modo che qualsiasi codice unito a un ramo permanente abbia una PR approvata.
Per sviluppare il codice con questa strategia di ramo persistente, segui questi passaggi di alto livello:
- Quando sviluppi nuove funzionalità o stai lavorando a una correzione di bug, crea un nuovo ramo basato sul ramo di sviluppo. Utilizza una convenzione di denominazione per il tuo ramoscello che includa il tipo di modifica, un numero di ticket o un altro identificatore e una descrizione leggibile, ad esempio
feature/123456-org-policies
. - Quando completi il lavoro nel ramo di funzionalità, apri una PR che abbia come target il ramo di sviluppo.
- Quando invii la PR, questa attiva la pipeline di base per eseguire
terraform plan
eterraform validate
per eseguire il commit e verificare le modifiche. - Dopo aver convalidato le modifiche al codice, unisci la funzionalità o la correzione del bug al ramo di sviluppo.
- Il processo di unione attiva l'esecuzione della pipeline di base
terraform apply
per eseguire il deployment delle ultime modifiche nel ramo di sviluppo nell'ambiente di sviluppo. - Esamina le modifiche nell'ambiente di sviluppo utilizzando revisioni manuali, test funzionali o test end-to-end pertinenti al tuo caso d'uso. Quindi, promuovi le modifiche nell'ambiente non di produzione aprendo una PR che abbia come target il ramo non di produzione e unisci le modifiche.
- Per eseguire il deployment delle risorse nell'ambiente di produzione, ripeti la stessa procedura del passaggio 6: esamina e convalida le risorse di cui è stato eseguito il deployment, apri una PR nel ramo di produzione e esegui l'unione.
Passaggi successivi
- Leggi le best practice per le operazioni (documento successivo di questa serie).
Best practice per le operazioni
Questa sezione illustra le operazioni da considerare durante il deployment e il funzionamento di carichi di lavoro aggiuntivi nel tuo Google Cloud ambiente. Questa sezione non è pensata per essere esaustiva di tutte le operazioni nel tuo ambiente cloud, ma introduce le decisioni relative ai consigli e alle risorse di architettura di cui è stato eseguito il deployment dal blueprint.
Aggiorna le risorse di base
Sebbene il blueprint fornisca un punto di partenza per l'ambiente di base, i requisiti di base potrebbero aumentare nel tempo. Dopo il deployment iniziale, puoi modificare le impostazioni di configurazione o creare nuovi servizi condivisi da utilizzare per tutti i carichi di lavoro.
Per modificare le risorse di base, ti consigliamo di apportare tutte le modifiche tramite la pipeline di base. Consulta la strategia di branching per un'introduzione al flusso di scrittura del codice, all'unione e all'attivazione delle pipeline di deployment.
Decidere gli attributi per i nuovi progetti di carichi di lavoro
Quando crei nuovi progetti tramite il modulo Project Factory della pipeline di automazione, devi configurare vari attributi. La procedura per progettare e creare progetti per nuovi carichi di lavoro deve includere decisioni relative a quanto segue:
- Quali API Google Cloud abilitare
- Il VPC condiviso da utilizzare o se creare una nuova rete VPC
- Quali ruoli IAM creare per l'
project-service-account
iniziale creato dalla pipeline - Quali etichette del progetto applicare
- La cartella in cui viene eseguito il deployment del progetto
- Quale account di fatturazione utilizzare
- Se aggiungere il progetto a un perimetro di VPC Service Controls
- Se configurare una soglia di avviso per budget e fatturazione per il progetto
Per un riferimento completo degli attributi configurabili per ogni progetto, consulta le variabili di input per la factory del progetto nella pipeline di automazione.
Gestire le autorizzazioni su larga scala
Quando esegui il deployment di progetti di carichi di lavoro sulla tua base, devi considerare come concederai l'accesso agli sviluppatori e ai consumatori previsti di questi progetti. Ti consigliamo di aggiungere gli utenti a un gruppo gestito dal tuo fornitore di servizi di identità esistente, sincronizzare i gruppi con Cloud Identity e poi applicare i ruoli IAM ai gruppi. Tieni sempre presente il principio del privilegio minimo.
Ti consigliamo inoltre di utilizzare il motore per suggerimenti IAM per identificare i criteri di autorizzazione che concedono ruoli con privilegi eccessivi. Progetta una procedura per esaminare periodicamente i consigli o applicarli automaticamente alle pipeline di deployment.
Coordinare le modifiche tra il team di networking e il team di applicazioni
Le topologie di rete di cui viene eseguito il deployment dal blueprint presuppongono che tu abbia un team responsabile della gestione delle risorse di rete e team separati responsabili del deployment delle risorse di infrastruttura del carico di lavoro. Quando i team di workload eseguono il deployment dell'infrastruttura, devono creare regole firewall per consentire i percorsi di accesso previsti tra i componenti del loro workload, ma non hanno l'autorizzazione per modificare i criteri firewall di rete.
Pianifica in che modo i team lavoreranno insieme per coordinare le modifiche alle risorse di rete centralizzate necessarie per il deployment delle applicazioni. Ad esempio, potresti progettare un processo in cui un team di carichi di lavoro richiede tag per le proprie applicazioni. Il team di networking crea quindi i tag e aggiunge regole al criterio firewall di rete che consentono il flusso del traffico tra le risorse con i tag e delega i ruoli IAM per l'utilizzo dei tag al team di lavoro.
Ottimizza il tuo ambiente con il portafoglio Active Assist
Oltre al motore per suggerimenti IAM, Google Cloud fornisce il portafoglio di servizi Active Assist per fornire suggerimenti su come ottimizzare il tuo ambiente. Ad esempio, gli approfondimenti sul firewall o il motore per suggerimenti di progetti non previsti forniscono suggerimenti strategici che possono aiutarti a rafforzare la tua security posture.
Progetta una procedura per rivedere periodicamente i consigli o applicarli automaticamente alle pipeline di deployment. Decidi quali consigli devono essere gestiti da un team centrale e quali sono responsabilità dei proprietari dei carichi di lavoro, quindi applica i ruoli IAM per accedere ai consigli di conseguenza.
Concedi eccezioni ai criteri dell'organizzazione
Il blueprint applica un insieme di vincoli delle norme dell'organizzazione consigliati per la maggior parte dei clienti nella maggior parte degli scenari, ma potresti avere casi d'uso legittimi che richiedono eccezioni limitate alle norme dell'organizzazione che applichi in modo generale.
Ad esempio, il blueprint applica il vincolo iam.disableServiceAccountKeyCreation. Questo vincolo è un controllo di sicurezza importante perché una chiave dell'account di servizio compromessa può avere un impatto negativo significativo e la maggior parte degli scenari dovrebbe utilizzare alternative più sicure alle chiavi dell'account di servizio per l'autenticazione. Tuttavia, potrebbero esserci casi d'uso che possono autenticarsi solo con una chiave del service account, ad esempio un server on-premise che richiede l'accesso ai serviziGoogle Cloud e non può utilizzare la federazione delle identità per i carichi di lavoro. In questo scenario, puoi decidere di consentire un'eccezione al criterio, a condizione che controlli compensativi aggiuntivi come le best practice per la gestione delle chiavi degli account di servizio siano applicati.
Pertanto, devi progettare una procedura per consentire ai workload di richiedere un'eccezione alle norme e assicurarti che i responsabili decisionali che si occupano di concedere le eccezioni dispongano delle conoscenze tecniche per convalidare il caso d'uso e consultare se devono essere implementati controlli aggiuntivi per compensare. Quando concedi un'eccezione a un carico di lavoro, modifica il vincolo dei criteri dell'organizzazione nel modo più specifico possibile. Puoi anche aggiungere vincoli a una norma dell'organizzazione in modo condizionale definendo un tag che concede un'eccezione o l'applicazione della norma, quindi applicandolo a progetti e cartelle.
Proteggere le risorse con i Controlli di servizio VPC
Il blueprint ti aiuta a preparare il tuo ambiente per i Controlli di servizio VPC separando le reti di base e limitate. Tuttavia, per impostazione predefinita, il codice Terraform non attiva i Controlli di servizio VPC perché questa attivazione può essere un processo che causa interruzioni.
Un perimetro nega l'accesso ai servizi Google Cloud con restrizioni da parte del traffico proveniente dall'esterno del perimetro, che include la console, le stazioni di lavoro degli sviluppatori e la pipeline di base utilizzata per il deployment delle risorse. Se utilizzi Controlli di servizio VPC, devi progettare delle eccezioni al perimetro che consentano i percorsi di accesso che intendi.
Un perimetro di Controlli di servizio VPC è destinato ai controlli di esfiltrazione tra la tua Google Cloud organizzazione e le origini esterne. Il perimetro non è inteso a sostituire o duplicare i criteri di autorizzazione per il controllo granulare dell'accesso a singoli progetti o risorse. Quando progetti e architetti un perimetro, ti consigliamo di utilizzare un perimetro unificato comune per ridurre l'overhead di gestione.
Se devi progettare più perimetri per controllare in modo granulare il traffico di servizio all'interno della tua Google Cloud organizzazione, ti consigliamo di definire chiaramente le minacce affrontate da una struttura di perimetro più complessa e i percorsi di accesso tra i perimetri necessari per le operazioni previste.
Per adottare Controlli di servizio VPC, valuta quanto segue:
- Quali dei tuoi casi d'uso richiedono i Controlli di servizio VPC.
Se i Google Cloud servizi richiesti supportano i Controlli di servizio VPC.
Come configurare l'accesso di emergenza per modificare il perimetro nel caso in cui interrompa le pipeline di automazione.
Come utilizzare le best practice per attivare i Controlli di servizio VPC per progettare e implementare il perimetro.
Dopo aver attivato il perimetro, ti consigliamo di progettare un processo per aggiungere costantemente nuovi progetti al perimetro corretto e un processo per progettare eccezioni quando gli sviluppatori hanno un nuovo caso d'uso che non è consentito dalla configurazione attuale del perimetro.
Testare le modifiche a livello di organizzazione in un'organizzazione separata
Ti consigliamo di non eseguire mai il deployment delle modifiche in produzione senza testarle. Per le risorse dei carichi di lavoro, questo approccio è facilitato da ambienti separati per lo sviluppo, non di produzione e di produzione. Tuttavia, alcune risorse dell'organizzazione non dispongono di ambienti separati per facilitare i test.
Per le modifiche a livello di organizzazione o altre modifiche che possono influire sugli ambienti di produzione, come la configurazione tra il tuo provider di identità e Cloud Identity, ti consigliamo di creare un'organizzazione separata a scopo di test.
Controllare l'accesso remoto alle macchine virtuali
Poiché ti consigliamo di eseguire il deployment di un'infrastruttura immutabile tramite la pipeline di base, la pipeline di infrastruttura e la pipeline di applicazione, ti consigliamo inoltre di concedere agli sviluppatori l'accesso diretto a una macchina virtuale solo tramite SSH o RDP per casi d'uso limitati o eccezionali.
Per gli scenari che richiedono l'accesso remoto, ti consigliamo di gestire l'accesso degli utenti utilizzando Accesso al sistema operativo, se possibile. Questo approccio utilizza i servizi Google Cloud gestiti per applicare il controllo dell'accesso, la gestione del ciclo di vita dell'account, la verifica in due passaggi e il logging di controllo. In alternativa, se devi consentire l'accesso tramite chiavi SSH nei metadati o credenziali RDP, è tua responsabilità gestire il ciclo di vita delle credenziali e archiviarle in modo sicuro al di fuori di Google Cloud.
In ogni caso, un utente con accesso SSH o RDP a una VM può rappresentare un rischio di riassegnazione dei privilegi, pertanto devi progettare il tuo modello di accesso tenendo presente questo aspetto. L'utente può eseguire codice sulla VM con i privilegi dell'account di servizio associato o eseguire query sul server di metadati per visualizzare il token di accesso utilizzato per autenticare le richieste API. Questo accesso può quindi essere un'escalation dei privilegi se non avevi intenzionalmente previsto che l'utente potesse operare con i privilegi dell'account di servizio.
Riduci la spesa eccessiva pianificando gli avvisi relativi al budget
Il blueprint implementa le best practice introdotte nel Google Cloud Framework dell'architettura: ottimizzazione dei costi per la gestione dei costi, tra cui:
Utilizza un unico account di fatturazione per tutti i progetti della base di dati aziendale.
Assegna a ogni progetto un'
billingcode
etichetta dei metadati utilizzata per allocare i costi tra i centri di costo.Imposta budget e soglie di avviso.
È tua responsabilità pianificare i budget e configurare gli avvisi di fatturazione. Il blueprint crea avvisi relativi al budget per i progetti di carichi di lavoro quando la spesa prevista è in procinto di raggiungere il 120% del budget. Questo approccio consente a un team centrale di identificare e mitigare gli incidenti di spesa eccessiva significativa. Aumenti imprevisti significativi della spesa senza una causa chiara possono essere un indicatore di un incidente di sicurezza e devono essere esaminati sia dal punto di vista del controllo dei costi sia da quello della sicurezza.
A seconda del caso d'uso, puoi impostare un budget basato sul costo di un'intera cartella dell'ambiente o di tutti i progetti relativi a un determinato centro di costo, anziché impostare budget granulari per ogni progetto. Ti consigliamo inoltre di delegare l'impostazione del budget e degli avvisi ai proprietari dei carichi di lavoro, che potrebbero impostare una soglia di avviso più granulare per il monitoraggio giornaliero.
Per indicazioni su come creare funzionalità FinOps, inclusa la previsione dei budget per i carichi di lavoro, consulta Introduzione a FinOps su Google Cloud.
Allocazione dei costi tra i centri di costo interni
La console ti consente di visualizzare i report di fatturazione per visualizzare e
prevedere i costi in più dimensioni. Oltre ai report predefiniti, ti consigliamo di esportare i dati di fatturazione in un set di dati BigQuery nel progetto prj-c-billing-export
. I record di fatturazione esportati ti consentono di allocare il costo in base a dimensioni personalizzate, come i centri di costo interni, in base ai metadati delle etichette del progetto, come billingcode
.
La seguente query SQL è un esempio di query per comprendere i costi di tutti i progetti agrupati per etichetta di progetto billingcode
.
#standardSQL
SELECT
(SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
service.description AS description,
SUM(cost) AS charges,
SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC
Per configurare questa esportazione, consulta Esportare i dati di fatturazione Cloud in BigQuery.
Se hai bisogno di contabilità interna o di addebiti inversi tra centri di costo, è tua responsabilità incorporare i dati ottenuti da questa query nei tuoi processi interni.
Importa i risultati dei controlli di rilevamento nella tua piattaforma SIEM esistente
Sebbene le risorse di base ti aiutino a configurare destinazioni aggregate per i log di controllo e i risultati di sicurezza, è tua responsabilità decidere come consumare e utilizzare questi indicatori.
Se devi aggregare i log di tutti gli ambienti cloud e on-premise in un SIEM esistente, decidi come importare i log del progetto prj-c-logging
e i risultati di Security Command Center nei tuoi strumenti e processi esistenti. Puoi creare una singola esportazione per tutti i log e i risultati se un singolo team è responsabile del monitoraggio della sicurezza nell'intero ambiente oppure puoi creare più esportazioni filtrate in base all'insieme di log e risultati necessari per più team con responsabilità diverse.
In alternativa, se il volume e il costo dei log sono proibitivi, puoi evitare la duplicazione conservando i Google Cloud log e i risultati solo inGoogle Cloud. In questo scenario, assicurati che i tuoi team esistenti dispongano dell'accesso e della formazione giusti per lavorare con i log e i risultati direttamente inGoogle Cloud.
- Per gli audit log, progetta viste dei log per concedere ai singoli team l'accesso a un sottoinsieme di log nel bucket di log centralizzato, anziché duplicare i log in più bucket, il che aumenta il costo di archiviazione dei log.
- Per i risultati sulla sicurezza, concedi ruoli a livello di cartella e di progetto per Security Command Center in modo che i team possano visualizzare e gestire i risultati sulla sicurezza solo per i progetti di cui sono responsabili, direttamente nella console.
Sviluppare continuamente la raccolta di controlli
Il blueprint inizia con una linea di base di controlli per rilevare e prevenire le minacce. Ti consigliamo di rivedere questi controlli e di aggiungerne altri in base alle tue esigenze. La seguente tabella riassume i meccanismi per applicare le norme di governance e come estenderle per i tuoi requisiti aggiuntivi:
Controlli dei criteri applicati dal blueprint | Informazioni per estendere questi controlli |
---|---|
Security Command Center rileva vulnerabilità e minacce da più fonti di sicurezza. |
Definisci moduli personalizzati per Security Health Analytics e moduli personalizzati per Event Threat Detection. |
Il servizio Criteri dell'organizzazione applica un insieme consigliato di vincoli dei criteri dell'organizzazione ai Google Cloud servizi. |
Applica vincoli aggiuntivi dall'elenco predefinito dei vincoli disponibili o crea vincoli personalizzati. |
Il criterio Open Policy Agent (OPA) convalida il codice nella pipeline di base per verificare la presenza di configurazioni accettabili prima del deployment. |
Sviluppare vincoli aggiuntivi in base alle indicazioni riportate in GoogleCloudPlatform/policy-library. |
La funzionalità Avvisi sulle metriche basate su log e sulle metriche relative al rendimento configura le metriche basate su log per generare avvisi in caso di modifiche ai criteri IAM e alle configurazioni di alcune risorse sensibili. |
Progetta metriche e criteri di avviso basati su log aggiuntivi per gli eventi dei log che ritieni non debbano verificarsi nel tuo ambiente. |
Una soluzione personalizzata per l'analisi automatica dei log esegue regolarmente query sui log per rilevare attività sospette e crea risultati di Security Command Center. |
Scrivi query aggiuntive per creare risultati per gli eventi di sicurezza che vuoi monitorare, utilizzando come riferimento l'analisi dei log di sicurezza. |
Una soluzione personalizzata per rispondere alle modifiche delle risorse crea risultati di Security Command Center e può automatizzare le azioni di correzione. |
Crea altri feed di inventario asset di Cloud per monitorare le modifiche per determinati tipi di asset e scrivi altre funzioni Cloud Run con logica personalizzata per rispondere alle violazioni dei criteri. |
Questi controlli potrebbero evolversi in base ai tuoi requisiti e al livello di maturità diGoogle Cloud .
Gestire le chiavi di crittografia con Cloud Key Management Service
Google Cloud offre la crittografia predefinita dei dati inattivi per tutti i contenuti dei clienti, ma fornisce anche Cloud Key Management Service (Cloud KMS) per offrire un maggiore controllo sulle chiavi di crittografia per i dati inattivi. Ti consigliamo di valutare se la crittografia predefinita è sufficiente o se hai un requisito di conformità che ti impone di utilizzare Cloud KMS per gestire autonomamente le chiavi. Per ulteriori informazioni, consulta la sezione Decidere come soddisfare i requisiti di conformità per la crittografia at-rest.
Il blueprint fornisce un progetto prj-c-kms
nella cartella comune e un progetto prj-{env}-kms
in ogni cartella dell'ambiente per gestire le chiavi di crittografia in modo centralizzato. Questo approccio consente a un team centrale di controllare e gestire le chiavi di crittografia utilizzate dalle risorse nei progetti dei carichi di lavoro, al fine di soddisfare i requisiti normativi e di conformità.
A seconda del modello operativo, potresti preferire un'unica istanza di progetto Cloud KMS centralizzata sotto il controllo di un singolo team, gestire le chiavi di crittografia separatamente in ogni ambiente o scegliere più istanze distribuite in modo che la responsabilità per le chiavi di crittografia possa essere delegata ai team appropriati. Modifica il codice Terraform di esempio in base alle esigenze del tuo modello operativo.
Se vuoi, puoi applicare i criteri dell'organizzazione per le chiavi di crittografia gestite dal cliente (CMEK) per imporre che determinati tipi di risorse richiedano sempre una chiave CMEK e che sia possibile utilizzare solo le chiavi CMEK di una lista consentita di progetti attendibili.
Archivia e controlla le credenziali delle applicazioni con Secret Manager
Ti consigliamo di non eseguire mai il commit di secret sensibili (come chiavi API, password e certificati privati) nei repository di codice sorgente. Al contrario, committa il secret in Secret Manager e concedi il ruolo IAM Accesso ai secret di Secret Manager all'utente o all'account di servizio che deve accedere al secret. Ti consigliamo di concedere il ruolo IAM a un singolo segreto, non a tutti i segreti del progetto.
Se possibile, devi generare automaticamente i secret di produzione all'interno delle pipeline CI/CD e mantenerli inaccessibili agli utenti umani, tranne in situazioni di emergenza. In questo scenario, assicurati di non concedere ruoli IAM per visualizzare questi secret a nessun utente o gruppo.
Il blueprint fornisce un singolo progetto prj-c-secrets
nella cartella comune e un progetto prj-c-secrets
in ogni cartella dell'ambiente per gestire i secret in modo centralizzato.prj-{env}-secrets
Questo approccio consente a un team centrale di controllare e gestire i secret utilizzati dalle applicazioni per soddisfare i requisiti normativi e di conformità.
A seconda del modello operativo, potresti preferire un'unica istanza centralizzata di Secret Manager sotto il controllo di un singolo team, gestire i secret separatamente in ogni ambiente o scegliere più istanze distribuite di Secret Manager in modo che ogni team di workload possa gestire i propri secret. Modifica il codice Terraform di esempio in base alle tue esigenze per adattarlo al tuo modello operativo.
Pianifica l'accesso di emergenza ad account con privilegi elevati
Sebbene consigliamo di gestire le modifiche alle risorse di base tramite IaC con controllo della versione di cui è stato eseguito il deployment dalla pipeline di base, potresti avere scenari eccezionali o di emergenza che richiedono l'accesso privilegiato per modificare direttamente il tuo ambiente. Ti consigliamo di pianificare account di emergenza (a volte chiamati account di chiamata di emergenza o di emergenza) con accesso altamente privilegiato al tuo ambiente in caso di emergenza o quando i processi di automazione si interrompono.
La seguente tabella descrive alcuni esempi di finalità degli account di emergenza.
Scopo del deployment di emergenza | Descrizione |
---|---|
Super amministratore | Accesso di emergenza al ruolo Superamministratore utilizzato con Cloud Identity, ad esempio per risolvere i problemi relativi alla federazione delle identità o all'autenticazione a più fattori (MFA). |
Amministratore dell'organizzazione |
Accesso di emergenza al ruolo Amministratore organizzazione, che può concedere l'accesso a qualsiasi altro ruolo IAM nell'organizzazione. |
Amministratore della pipeline fundamenta | Accesso di emergenza per modificare le risorse del progetto CI/CD suGoogle Cloud e nel repository Git esterno nel caso in cui l'automazione della pipeline di base si arresti in modo anomalo. |
Operations o SRE |
Un team operativo o SRE ha bisogno di accesso privilegiato per rispondere a interruzioni o incidenti. ad esempio il riavvio delle VM o il ripristino dei dati. |
Il meccanismo per consentire l'accesso di emergenza dipende dagli strumenti e dalle procedure esistenti che hai implementato, ma alcuni esempi di meccanismi includono quanto segue:
- Utilizza gli strumenti esistenti per la gestione degli accessi con privilegi per aggiungere temporaneamente un utente a un gruppo predefinito con ruoli IAM ad alto privilegio o utilizza le credenziali di un account ad alto privilegio.
- Account preconfigurati destinati solo all'utilizzo da parte dell'amministratore. Ad esempio, lo sviluppatore Dana potrebbe avere un'identità dana@example.com per l'uso quotidiano e admin-dana@example.com per l'accesso di emergenza.
- Utilizza un'applicazione come l'accesso privilegiato just-in-time che consente a uno sviluppatore di eseguire la riassegnazione a ruoli più privilegiati.
Indipendentemente dal meccanismo utilizzato, valuta come rispondere operativamente alle seguenti domande:
- Come progetti l'ambito e la granularità dell'accesso di emergenza? Ad esempio, potresti progettare un meccanismo di emergenza diverso per unità aziendali diverse per assicurarti che non possano interferire tra loro.
- In che modo il tuo meccanismo previene gli abusi? Sono necessarie approvazioni? Ad esempio, potresti avere operazioni suddivise in cui una persona detiene le credenziali e un'altra la persona detiene il token MFA.
- Come esegui controlli e avvisi sull'accesso di emergenza? Ad esempio, potresti configurare un modulo Event Threat Detection personalizzato per creare un rilevamento di sicurezza quando viene utilizzato un account breakglass predefinito.
- Come faccio a rimuovere l'accesso di emergenza e a riprendere le normali operazioni al termine dell'incidente?
Per le attività comuni di riassegnazione dei privilegi e per il rollback delle modifiche, consigliamo di progettare flussi di lavoro automatici in cui un utente possa eseguire l'operazione senza richiedere la riassegnazione dei privilegi per la propria identità utente. Questo approccio può contribuire a ridurre gli errori umani e migliorare la sicurezza.
Per i sistemi che richiedono interventi regolari, l'automazione della correzione potrebbe essere la migliore soluzione. Google incoraggia i clienti ad adottare un approccio di produzione zero-touch per apportare tutte le modifiche di produzione utilizzando l'automazione, i proxy sicuri o le procedure di emergenza sottoposte a controllo. Google fornisce i libri SRE per i clienti che vogliono adottare l'approccio SRE di Google.
Passaggi successivi
- Leggi Esegui il deployment del progetto (documento successivo di questa serie).
Esegui il deployment del progetto base
Questa sezione descrive la procedura che puoi utilizzare per eseguire il deployment del blueprint, le relative convenzioni di denominazione e le alternative ai consigli per i blueprint.
Riepilogo
Per eseguire il deployment della tua base di dati aziendale in linea con le best practice e i consigli di questo blueprint, segui le attività di alto livello riepilogate in questa sezione. Il deployment richiede una combinazione di passaggi di configurazione preliminari, deployment automatico tramite terraform-example-foundation su GitHub e passaggi aggiuntivi che devono essere configurati manualmente al termine del deployment iniziale della base.
Processo | Passaggi |
---|---|
Prerequisiti prima di eseguire il deployment delle risorse della pipeline di base |
Completa i seguenti passaggi prima di eseguire il deployment della pipeline di base:
Per connetterti a un ambiente on-premise esistente, prepara quanto segue:
|
Passaggi per eseguire il deployment di terraform-example-foundation da GitHub |
Segui le istruzioni del file readme per ogni fase per eseguire il deployment di terraform-example-foundation da GitHub:
|
Passaggi aggiuntivi dopo il deployment IaC |
Dopo aver eseguito il deployment del codice Terraform, completa quanto segue:
|
Controlli amministrativi aggiuntivi per i clienti con carichi di lavoro sensibili
Google Cloud offre controlli amministrativi aggiuntivi che possono aiutarti a soddisfare i requisiti di sicurezza e conformità. Tuttavia, alcuni controlli comportano costi aggiuntivi o compromessi operativi che potrebbero non essere appropriati per ogni cliente. Questi controlli richiedono inoltre input personalizzati per i tuoi requisiti specifici che non possono essere completamente automatizzati nel blueprint con un valore predefinito per tutti i clienti.
Questa sezione illustra i controlli di sicurezza che puoi applicare in modo centralizzato alla base. Questa sezione non intende essere esaustiva di tutti i controlli di sicurezza che puoi applicare a carichi di lavoro specifici. Per ulteriori informazioni su prodotti e soluzioni di sicurezza di Google, visita il Google Cloud Centro best practice per la sicurezza.
Valuta se i seguenti controlli sono appropriati per la tua fondazione in base ai tuoi requisiti di conformità, alla tua propensione al rischio e alla sensibilità dei dati.
Controllo | Descrizione |
---|---|
I Controlli di servizio VPC ti consentono di definire criteri di sicurezza che impediscono l'accesso ai servizi gestiti da Google al di fuori di un perimetro attendibile, bloccano l'accesso ai dati da posizioni non attendibili e mitigano i rischi di esfiltrazione di dati. Tuttavia, Controlli di servizio VPC può causare l'interruzione dei servizi esistenti finché non definisci le eccezioni per consentire i pattern di accesso previsti. Valuta se il valore della mitigazione dei rischi di esfiltrazione giustifica la maggiore complessità e il carico operativo dell'adozione dei Controlli di servizio VPC. Il blueprint prepara le reti con limitazioni e le variabili facoltative per configurare i Controlli di servizio VPC, ma il perimetro non viene attivato finché non esegui passaggi aggiuntivi per progettarlo e attivarlo. |
|
Potresti avere requisiti normativi che richiedono di implementare le risorse cloud solo in località geografiche approvate. Questo vincolo dei criteri dell'organizzazione impone che le risorse possano essere implementate solo nell'elenco di località che definisce. |
|
Assured Workloads fornisce controlli di conformità aggiuntivi che ti aiutano a rispettare regimi normativi specifici. Il progetto fornisce variabili facoltative nella pipeline di deployment per l'attivazione. |
|
Potresti avere l'obbligo di registrare tutto l'accesso a determinati dati o risorse sensibili. Valuta dove i tuoi carichi di lavoro gestiscono dati sensibili che richiedono log di accesso ai dati e attiva i log per ogni servizio e ambiente che lavora con dati sensibili. |
|
Access Approval garantisce che l'assistenza clienti e il team di ingegneria di Cloud richiedano la tua approvazione esplicita ogni volta che devono accedere ai contenuti dei tuoi clienti. Valuta la procedura operativa richiesta per esaminare le richieste di approvazione dell'accesso per ridurre al minimo i possibili ritardi nella risoluzione degli incidenti relativi all'assistenza. |
|
Le giustificazioni per l'accesso alle chiavi ti consentono di controllare in modo programmatico se Google può accedere alle tue chiavi di crittografia, ad esempio per le operazioni automatiche e per consentire all'assistenza clienti di accedere ai contenuti dei clienti. Valuta il costo e il sovraccarico operativo associati a Key Access Justifications, nonché la sua dipendenza da Cloud External Key Manager (Cloud EKM). |
|
Cloud Shell è un ambiente di sviluppo online. Questa shell è ospitata su un server gestito da Google al di fuori del tuo ambiente e, pertanto, non è soggetta ai controlli che potresti aver implementato sulle tue stazioni di lavoro per sviluppatori. Se vuoi controllare rigorosamente le workstation che uno sviluppatore può utilizzare per accedere alle risorse cloud, disattiva Cloud Shell. Puoi anche valutare le workstation cloud per un'opzione di workstation configurabile nel tuo ambiente. |
|
Google Cloud ti consente di limitare l'accesso alla console Google Cloud in base agli attributi di livello di accesso, come l'appartenenza al gruppo, gli intervalli di indirizzi IP attendibili e la verifica del dispositivo. Alcuni attributi richiedono un abbonamento aggiuntivo a Chrome Enterprise Premium. Valuta i pattern di accesso che ritieni attendibili per l'accesso degli utenti alle applicazioni basate sul web, come la console, nell'ambito di un implementazione in modalità zero trust più ampia. |
Convenzioni di denominazione
Ti consigliamo di adottare una convenzione di denominazione standardizzata per le tue Google Cloud risorse. La tabella seguente descrive le convenzioni consigliate per i nomi delle risorse nel blueprint.
Risorsa | Convenzione di denominazione |
---|---|
Cartella |
Ad esempio:
|
ID progetto |
Ad esempio: |
Rete VPC |
Ad esempio: |
Subnet |
Ad esempio: |
Criteri firewall |
Ad esempio:
|
Router Cloud |
Ad esempio: |
Connessione Cloud Interconnect |
Ad esempio: |
Collegamento VLAN Cloud Interconnect |
Ad esempio:
|
Gruppo |
dove
Ad esempio:
|
Ruolo personalizzato |
Dove Ad esempio: |
Service account |
Dove:
Ad esempio:
|
Bucket di archiviazione |
Dove:
Ad esempio:
|
Alternative ai consigli predefiniti
Le best practice consigliate nel blueprint potrebbero non funzionare per tutti i clienti. Puoi personalizzare qualsiasi suggerimento per soddisfare i tuoi requisiti specifici. La tabella seguente illustra alcune delle varianti comuni che potresti richiedere in base al tuo stack tecnologico esistente e alle tue modalità di lavoro.
Area decisionale | Possibili alternative |
---|---|
Organizzazione:il blueprint utilizza una singola organizzazione come nodo radice per tutte le risorse. |
Decidere una gerarchia delle risorse per la tua Google Cloud area di destinazione introduce scenari in cui potresti preferire più organizzazioni, ad esempio:
|
Struttura delle cartelle: il blueprint ha una struttura di cartelle semplice, con i carichi di lavoro suddivisi in cartelle |
Decidere una gerarchia delle risorse per la tua Google Cloud
|
Criteri dell'organizzazione:il blueprint applica tutti i vincoli dei criteri dell'organizzazione al nodo dell'organizzazione. |
Potresti avere criteri di sicurezza o modalità di lavoro diversi per diverse parti dell'attività. In questo scenario, applica le limitazioni dei criteri dell'organizzazione a un nodo inferiore nella gerarchia delle risorse. Esamina l'elenco completo di limitazioni dei criteri dell'organizzazione che ti aiutano a soddisfare i tuoi requisiti. |
Strumenti della pipeline di deployment: il blueprint utilizza Cloud Build per eseguire la pipeline di automazione. |
Potresti preferire altri prodotti per la tua pipeline di deployment, come Terraform Enterprise, GitLab Runners, GitHub Actions o Jenkins. Il blueprint include indicazioni alternative per ogni prodotto. |
Repository di codice per il deployment: il blueprint utilizza Cloud Source Repositories come repository Git privato gestito. |
Utilizza il sistema di controllo della versione che preferisci per gestire i repository di codice, come GitLab, GitHub o Bitbucket. Se utilizzi un repository privato ospitato nel tuo ambiente on-premise, configura un percorso di rete privato dal repository all'ambiente Google Cloud. |
Provider di identità: il blueprint presuppone un Active Directory on-premise e federa le identità con Cloud Identity utilizzando Google Cloud Directory Sync. |
Se utilizzi già Google Workspace, puoi utilizzare le identità Google già gestite in Google Workspace. Se non hai un provider di identità esistente, puoi creare e gestire le identità utente direttamente in Cloud Identity. Se hai già un provider di identità, come Okta, Ping o Azure Enter, puoi gestire gli account utente nel tuo provider di identità esistente e sincronizzarli con Cloud Identity. Se hai requisiti di sovranità dei dati o di conformità che ti impediscono di utilizzare Cloud Identity e se non hai bisogno di identità utente Google gestite per altri servizi Google come Google Ads o Google Marketing Platform, potresti preferire la federazione delle identità del personale. In questo caso, tieni presente le limitazioni dei servizi supportati. |
Più regioni: il blueprint esegue il deployment delle risorse regionali in due regioni Google Cloud diverse per contribuire a abilitare il design del carico di lavoro tenendo conto dei requisiti di alta disponibilità e di ripristino di emergenza. |
Se hai utenti finali in più località geografiche, puoi configurare altre Google Cloud regioni per creare risorse più vicine all'utente finale con una latenza inferiore. Se hai vincoli di sovranità dei dati o se le tue esigenze di disponibilità possono essere soddisfatte in una singola regione, puoi configurare una sola regioneGoogle Cloud . |
Allocazione degli indirizzi IP:il blueprint fornisce un insieme di intervalli di indirizzi IP. |
Potresti dover modificare gli intervalli di indirizzi IP specifici utilizzati in base alla disponibilità degli indirizzi IP nel tuo ambiente ibrido esistente. Se modifichi gli intervalli di indirizzi IP, utilizza il blueprint come guida per il numero e le dimensioni degli intervalli richiesti e controlla gli intervalli di indirizzi IP validi per Google Cloud. |
Networking ibrido:il blueprint utilizza Interconnect dedicato su più siti fisici e regioniGoogle Cloud per la massima larghezza di banda e disponibilità. |
A seconda dei requisiti relativi a costi, larghezza di banda e affidabilità, potresti configurare Partner Interconnect o Cloud VPN. Se devi iniziare a eseguire il deployment delle risorse con connettività privata prima che sia possibile completare un'interconnessione dedicata, potresti iniziare con Cloud VPN e passare in un secondo momento all'utilizzo di Dedicated Interconnect. Se non hai già un ambiente on-premise, potresti non avere bisogno di una rete ibrida. |
Perimetro di Controlli di servizio VPC:il blueprint consiglia un singolo perimetro che includa tutti i progetti di servizio associati a una rete VPC limitata. I progetti associati a una rete VPC di base non sono inclusi nel perimetro. |
Potresti avere un caso d'uso che richiede più perimetri per un'organizzazione o potresti decidere di non utilizzare affatto Controlli di servizio VPC. Per informazioni, consulta scegliere come mitigare l'esfiltrazione dei dati tramite le API di Google. |
Secret Manager:il blueprint esegue il deployment di un progetto per l'utilizzo di Secret Manager nella cartella |
Se hai un unico team responsabile della gestione e del controllo dei secret sensibili nell'intera organizzazione, potresti preferire utilizzare un solo progetto per gestire l'accesso ai secret. Se consenti ai team dei carichi di lavoro di gestire i propri segreti, potresti non utilizzare un progetto centralizzato per gestire l'accesso ai segreti e lasciare che i team utilizzino le proprie istanze di Secret Manager nei progetti dei carichi di lavoro. |
Cloud KMS: il blueprint esegue il deployment di un progetto per l'utilizzo di Cloud KMS nella cartella |
Se hai un unico team responsabile della gestione e del controllo delle chiavi di crittografia dell'intera organizzazione, potresti preferire utilizzare un solo progetto per gestire l'accesso alle chiavi. Un approccio centralizzato può contribuire a soddisfare i requisiti di conformità, come i custodi delle chiavi PCI. Se consenti ai team di gestire le proprie chiavi, potresti non utilizzare un progetto centralizzato per gestire l'accesso alle chiavi e lasciare che i team utilizzino le proprie istanze di Cloud KMS nei progetti di workload. |
Sink dei log aggregati:il blueprint configura un insieme di sink dei log nel nodo dell'organizzazione in modo che un team di sicurezza centrale possa esaminare gli audit log dell'intera organizzazione. |
Potresti avere diversi team responsabili del controllo di diverse parti dell'attività e questi team potrebbero richiedere log diversi per svolgere il proprio lavoro. In questo scenario, progetta più sink aggregati nelle cartelle e nei progetti appropriati e crea filtri in modo che ogni team riceva solo i log necessari oppure progetta visualizzazioni log per il controllo granulare dell'accesso a un bucket di log comune. |
Granularità delle pipeline di infrastruttura: il blueprint utilizza un modello in cui ogni unità aziendale ha una pipeline di infrastruttura separata per gestire i progetti di carichi di lavoro. |
Se hai un team centrale responsabile del deployment di tutti i progetti e dell'infrastruttura, potresti preferire una singola pipeline di infrastruttura gestita da un team centrale. Questo team centrale può accettare le richieste pull dai team di workload per esaminarle e approvarle prima della creazione del progetto oppure il team può creare la richiesta pull autonomamente in risposta a un sistema di ticket. Potresti preferire pipeline più granulari se i singoli team di workload hanno la possibilità di personalizzare le proprie pipeline e vuoi progettare account di servizio con privilegi più granulari per le pipeline. |
Esportazioni SIEM:il blueprint gestisce tutti i risultati relativi alla sicurezza in Security Command Center. |
Decidi se esportare i risultati di sicurezza da Security Command Center in strumenti come Google Security Operations o nel tuo SIEM esistente oppure se i team utilizzeranno la console per visualizzare e gestire i risultati di sicurezza. Potresti configurare più esportazioni con filtri univoci per team diversi con ambiti e responsabilità diversi. |
Ricerca DNS per i Google Cloud servizi on-premise: il blueprint configura un endpoint Private Service Connect univoco per ogni VPC condiviso, il che può contribuire ad attivare progetti con più perimetri VPC Service Controls. |
Potresti non richiedere il routing da un ambiente on-premise agli endpoint Private Service Connect a questo livello di granularità se non hai bisogno di più perimetri di Controlli di servizio VPC. Anziché mappare gli host on-premise agli endpoint Private Service Connect in base all'ambiente, puoi semplificare questo design utilizzando un singolo endpoint Private Service Connect con il bundle API appropriato oppure gli endpoint generici per |
Passaggi successivi
- Implementa il blueprint utilizzando la base di esempio Terraform su GitHub.
- Scopri di più sui principi di progettazione delle best practice con il Google Cloud Framework dell'architettura.
Consulta la libreria di blueprint per accelerare la progettazione e la creazione di carichi di lavoro aziendali comuni, tra cui:
Importa i dati da Google Cloud in un data warehouse BigQuery protetto
Importare i dati da una rete esterna in un data warehouse BigQuery protetto
Esegui il deployment di un'architettura serverless protetta utilizzando le funzioni Cloud Run
Esegui il deployment di un'architettura serverless sicura utilizzando Cloud Run
Consulta le soluzioni correlate da eseguire nel tuo ambiente di base.
Per accedere a un ambiente di dimostrazione, contattaci all'indirizzo security-foundations-blueprint-support@google.com.