Questa sezione descrive la procedura che puoi utilizzare per eseguire il deployment del progetto base, le relative convenzioni di denominazione e le alternative ai suggerimenti relativi ai progetti.
Riepilogo
Per eseguire il deployment della tua base aziendale in linea con le best practice e i suggerimenti di questo progetto, segui le attività di alto livello riassunte in questa sezione. Il deployment richiede una combinazione di passaggi di configurazione dei prerequisiti, deployment automatico tramite terraform-example-foundation su GitHub e passaggi aggiuntivi che devono essere configurati manualmente al termine del deployment di base iniziale.
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:
|
I passaggi per eseguire il deployment di terraform-example-foundation da GitHub |
Segui le indicazioni README per ogni fase per il deployment di terraform-example-foundation da GitHub:
|
Passaggi aggiuntivi dopo il deployment di 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 fornisce 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 tutti i clienti. Questi controlli richiedono anche input personalizzati per i tuoi requisiti specifici che non possono essere completamente automatizzati nel progetto base con un valore predefinito per tutti i clienti.
Questa sezione introduce i controlli di sicurezza che applichi centralmente agli elementi di base. Questa sezione non intende essere esaustiva di tutti i controlli di sicurezza che puoi applicare a carichi di lavoro specifici. Per ulteriori informazioni sui prodotti e sulle soluzioni per la sicurezza di Google, vedi Centro best practice per la sicurezza di Google Cloud.
Valuta se i seguenti controlli sono appropriati per gli elementi di base in base ai tuoi requisiti di conformità, alla propensione al rischio e alla sensibilità dei dati.
Controllo | Descrizione |
---|---|
Controlli di servizio VPC consente 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 località non attendibili e riducono i rischi di esfiltrazione di dati. Tuttavia, i Controlli di servizio VPC possono interrompere i 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 l'overhead operativo associato all'adozione dei Controlli di servizio VPC. Il progetto prepara le reti limitate e le variabili facoltative per configurare i Controlli di servizio VPC, ma il perimetro non è abilitato finché non vengono eseguiti ulteriori passaggi per la progettazione e l'abilitazione. |
|
I requisiti normativi potrebbero indicare che il deployment delle risorse cloud deve essere eseguito solo in località geografiche approvate. Questo vincolo del criterio dell'organizzazione impone che il deployment delle risorse possa essere eseguito solo nell'elenco delle località che definisci. |
|
Assured Workloads fornisce controlli di conformità aggiuntivi per soddisfare regimi normativi specifici. Il progetto fornisce variabili facoltative nella pipeline di deployment per l'abilitazione. |
|
Potrebbe essere necessario registrare tutti gli accessi a determinati dati o risorse sensibili. Valuta dove i tuoi carichi di lavoro gestiscono dati sensibili che richiedono log di accesso ai dati e abilita i log per ogni servizio e ambiente che utilizza dati sensibili. |
|
Access Approval garantisce che l'assistenza clienti e i tecnici Google Cloud richiedano la tua approvazione esplicita ogni volta che devono accedere ai contenuti dei tuoi clienti. Valuta il processo operativo necessario per esaminare le richieste Access Approval al fine di mitigare i possibili ritardi nella risoluzione di incidenti relativi all'assistenza. |
|
Key Access Justifications ti consente di controllare in modo programmatico se Google può accedere alle tue chiavi di crittografia, anche per le operazioni automatizzate e l'assistenza clienti per accedere ai contenuti dei tuoi clienti. Valuta il costo e l'overhead operativo associato a Key Access Justifications e 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, pertanto non è soggetta ai controlli che potresti aver implementato sulle tue workstation di sviluppo. Se vuoi controllare rigorosamente le workstation che uno sviluppatore può utilizzare per accedere alle risorse cloud, disabilita Cloud Shell. Potresti anche valutare Cloud Workstations per un'opzione di workstation configurabile nel tuo ambiente. |
|
Google Cloud consente di limitare l'accesso alla console Google Cloud in base ad attributi del livello di accesso come l'iscrizione ai gruppi, 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 deployment Zero Trust più ampio. |
Convenzioni di denominazione
Ti consigliamo di utilizzare una convenzione di denominazione standardizzata per le risorse Google Cloud. La seguente tabella descrive le convenzioni consigliate per i nomi delle risorse nel progetto base.
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 progetto potrebbero non funzionare per tutti i clienti. Puoi personalizzare qualsiasi consiglio per soddisfare i tuoi requisiti specifici. La seguente tabella introduce alcune delle varianti comuni che potrebbero essere necessarie in base allo stack tecnologico e ai modi di lavoro esistenti.
Area decisionale | Possibili alternative |
---|---|
Organizzazione: il progetto utilizza una singola organizzazione come nodo radice per tutte le risorse. |
Definisci una gerarchia delle risorse per la zona di destinazione di Google Cloud introduce scenari in cui potresti preferire più organizzazioni, ad esempio:
|
Struttura delle cartelle: il progetto ha una struttura di cartelle semplice, con carichi di lavoro suddivisi in cartelle |
Decidi una gerarchia delle risorse per la tua zona di destinazione di Google Cloud introduce altri approcci per la strutturazione delle cartelle in base a come vuoi gestire le risorse ed ereditare i criteri, ad esempio:
|
Criteri dell'organizzazione: il progetto applica tutti i vincoli dei criteri dell'organizzazione a livello di nodo organizzazione. |
Possono esistere diversi criteri di sicurezza o diversi modi di lavorare per diversi ambiti dell'azienda. In questo scenario, applica i vincoli dei criteri dell'organizzazione a un nodo inferiore della gerarchia delle risorse. Esamina l'elenco completo dei vincoli dei criteri dell'organizzazione che aiutano a soddisfare i tuoi requisiti. |
Strumenti per la pipeline di deployment: il progetto utilizza Cloud Build per eseguire la pipeline di automazione. |
Potresti preferire altri prodotti per la pipeline di deployment, ad esempio Terraform Enterprise, GitLab Runners, GitHub Actions o Jenkins. Il progetto include indicazioni alternative per ciascun prodotto. |
Repository di codice per il deployment: il progetto utilizza Cloud Source Repositories come repository Git privato gestito. |
Utilizza il tuo sistema di controllo della versione preferito 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 progetto parte da una Active Directory on-premise e federa le identità in Cloud Identity utilizzando Google Cloud Directory Sync. |
Se usi 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 un provider di identità esistente, come Okta, Ping o Azure Entra ID, puoi gestire gli account utente nel tuo provider di identità esistente e sincronizzarli con Cloud Identity. Se hai requisiti di sovranità dei dati o conformità che ti impediscono di utilizzare Cloud Identity, ma non ti occorrono identità utente Google gestite per altri servizi Google come Google Ads o Google Marketing Platform, potresti preferire la federazione delle identità per la forza lavoro. In questo scenario, tieni presente le limitazioni dei servizi supportati. |
Più regioni: il progetto esegue il deployment di risorse di regione in due diverse regioni Google Cloud per consentire la progettazione dei carichi di lavoro tenendo presenti requisiti di alta disponibilità e ripristino di emergenza. |
Se hai utenti finali in più località geografiche, potresti configurare più regioni Google Cloud per creare risorse più vicino all'utente finale con meno latenza. 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 regione Google Cloud. |
Allocazione degli indirizzi IP: il progetto fornisce una serie 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 progetto come guida per il numero e la dimensione degli intervalli richiesti ed esamina gli intervalli di indirizzi IP validi per Google Cloud. |
Networking ibrido: il progetto utilizza Dedicated Interconnect in più siti fisici e regioni di Google Cloud per ottenere la massima larghezza di banda e la massima disponibilità. |
A seconda dei tuoi requisiti di costo, larghezza di banda e affidabilità, puoi configurare Partner Interconnect o Cloud VPN. Se devi iniziare a eseguire il deployment delle risorse con connettività privata prima di poter completare una connessione Dedicated Interconnect, puoi iniziare con Cloud VPN e passare all'utilizzo di Dedicated Interconnect in un secondo momento. Se non hai un ambiente on-premise esistente, potresti non aver bisogno del networking ibrido. |
Perimetro Controlli di servizio VPC: il progetto 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. |
È possibile che un caso d'uso richieda più perimetri per un'organizzazione o che tu possa decidere di non utilizzare affatto i Controlli di servizio VPC. Per informazioni, consulta Decidere come mitigare l'esfiltrazione di dati tramite le API di Google. |
Secret Manager: il progetto 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 in tutta l'organizzazione, potresti preferire utilizzare un solo progetto per la gestione dell'accesso ai secret. Se consenti ai team dei carichi di lavoro di gestire i propri secret, potresti non utilizzare un progetto centralizzato per la gestione dell'accesso ai secret e consentire invece ai team di utilizzare le proprie istanze di Secret Manager nei progetti dei carichi di lavoro. |
Cloud KMS: il progetto 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 in tutta l'organizzazione, potresti preferire utilizzare un solo progetto per la gestione dell'accesso alle chiavi. Un approccio centralizzato può aiutare a soddisfare i requisiti di conformità come i custodi delle chiavi PCI. Se consenti ai team dei carichi di lavoro di gestire le proprie chiavi, potresti non utilizzare un progetto centralizzato per la gestione dell'accesso alle chiavi e consentire ai team di utilizzare le proprie istanze di Cloud KMS nei progetti dei carichi di lavoro. |
Sink di log aggregati:il progetto configura un insieme di sink di log nel nodo dell'organizzazione, in modo che un team centrale di sicurezza possa esaminare gli audit log dell'intera organizzazione. |
Potresti avere team diversi 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 i filtri in modo che ogni team riceva solo i log necessari oppure progetta visualizzazioni di log per un controllo dell'accesso granulare dell'accesso a un bucket di log comune. |
Granularità delle pipeline dell'infrastruttura: il progetto utilizza un modello in cui ogni unità aziendale ha una pipeline di infrastruttura separata per gestire i progetti dei carichi di lavoro. |
Potresti preferire una singola pipeline dell'infrastruttura gestita da un team centrale se ne hai uno centrale responsabile del deployment di tutti i progetti e dell'infrastruttura. Questo team centrale può accettare richieste di pull dai team dei carichi di lavoro da esaminare e approvare prima della creazione del progetto oppure può creare personalmente la richiesta di pull in risposta a un sistema basato su ticket. Potresti preferire pipeline più granulari se singoli team dei carichi di lavoro hanno la possibilità di personalizzare le proprie pipeline e vuoi progettare account di servizio con privilegi più granulari per le pipeline. |
Esportazioni SIEM: il progetto gestisce tutti i risultati di sicurezza in Security Command Center. |
Decidi se esporterai i risultati sulla sicurezza da Security Command Center a strumenti come Google Security Operations o al tuo SIEM esistente o se i team utilizzeranno la console per visualizzare e gestire i risultati sulla sicurezza. Puoi configurare più esportazioni con filtri univoci per team diversi con ambiti e responsabilità diversi. |
Ricerche DNS per i servizi Google Cloud da on-premise: il progetto configura un endpoint Private Service Connect univoco per ogni VPC condiviso, in modo da consentire le progettazioni con più perimetri Controlli di servizio VPC. |
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 Controlli di servizio VPC. Invece di
mappare gli host on-premise agli endpoint Private Service Connect in base
all'ambiente, potresti semplificare questa progettazione in modo da utilizzare un singolo
endpoint Private Service Connect con il bundle API appropriato
oppure utilizzare gli endpoint generici per |
Passaggi successivi
- Implementare il progetto base utilizzando la base di esempio Terraform su GitHub.
- Scopri di più sui principi di progettazione delle best practice con il framework dell'architettura Google Cloud.
Consulta la libreria dei progetti per aiutarti ad 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 sicuro
Importare dati da una rete esterna in un data warehouse BigQuery sicuro
Esegui il deployment di un'architettura serverless sicura utilizzando Cloud Functions
Esegui il deployment di un'architettura serverless sicura utilizzando Cloud Run
Scopri le soluzioni correlate di cui eseguire il deployment nell'ambiente di base.
Per accedere a un ambiente dimostrativo, contattaci all'indirizzo security-foundations-blueprint-support@google.com.