Questa sezione descrive il processo che puoi utilizzare per eseguire il deployment del progetto, le sue convenzioni di denominazione e le alternative ai suggerimenti del progetto.
Riepilogo
Per eseguire il deployment della tua piattaforma 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 prerequisiti, deployment automatico tramite terraform-example-foundation su GitHub e passaggi aggiuntivi che devono essere configurati manualmente dopo il completamento del deployment iniziale di base.
Processo | Procedura |
---|---|
Prerequisiti per 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 il deployment di terraform-example-foundation da GitHub |
Segui le istruzioni README per ogni fase per eseguire 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 illustra i controlli di sicurezza da applicare a livello centrale. 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, visita il Centro best practice per la sicurezza di Google Cloud.
Valuta se i seguenti controlli sono appropriati per la tua base in base ai tuoi requisiti di conformità, alla propensione al rischio e alla sensibilità dei dati.
Controllo | Descrizione |
---|---|
I Controlli di servizio VPC 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 località 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 delle 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 derivante dall'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. |
|
Potresti avere requisiti normativi che richiedono il deployment delle risorse cloud 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à definite da te. |
|
Assured Workloads fornisce controlli di conformità aggiuntivi che aiutano a rispettare 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 i dati sensibili che richiedono log di accesso ai dati e abilita i log per ogni servizio e ambiente che utilizzano dati sensibili. |
|
Access Approval garantisce che l'assistenza clienti Google Cloud e l'ingegneria di Google Cloud richiedano la tua approvazione esplicita ogni volta che hanno bisogno di accedere ai contenuti dei tuoi clienti. Valuta il processo operativo necessario per esaminare le richieste di Access Approval al fine di ridurre i possibili ritardi nella risoluzione degli incidenti di 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 per consentire all'assistenza clienti di accedere ai contenuti dei tuoi clienti. Valuta il costo e l'overhead operativo associato 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 all'esterno 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. Puoi anche valutare Cloud Workstations per un'opzione di workstation configurabile nel tuo ambiente. |
|
Google Cloud ti consente di limitare l'accesso alla console Google Cloud in base ad attributi del livello di accesso come iscrizione ai gruppi, intervalli di indirizzi IP attendibili e verifica dei dispositivi. Alcuni attributi richiedono un abbonamento aggiuntivo a BeyondCorp Enterprise. Valuta i pattern di accesso che ritieni affidabili per l'accesso degli utenti ad applicazioni basate sul web come la console nell'ambito di un deployment Zero Trust più ampio. |
Convenzioni di denominazione
Ti consigliamo di adottare una convenzione di denominazione standardizzata per le risorse Google Cloud. La tabella seguente 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 di Cloud Interconnect |
Ad esempio:
|
Gruppo. |
Dove Ad esempio:
|
Ruolo personalizzato |
Dove Ad esempio: |
Account di servizio |
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 suggerimento in base alle tue esigenze specifiche. La seguente tabella presenta alcune delle varianti comuni di cui potresti aver bisogno in base allo stack tecnologico e alle modalità di lavoro esistenti.
Area decisionale | Possibili alternative |
---|---|
Organizzazione: il progetto utilizza una singola organizzazione come nodo radice per tutte le risorse. |
Decidi una gerarchia di risorse per la tua zona di destinazione Google Cloud presenta scenari in cui potresti preferire più organizzazioni, ad esempio:
|
Struttura delle cartelle: il progetto ha una struttura di cartelle semplice, con i carichi di lavoro suddivisi in cartelle |
Decidere una gerarchia di risorse per la tua zona di destinazione Google Cloud introduce altri approcci per la strutturazione delle cartelle in base a come vuoi gestire le risorse ed ereditare criteri, ad esempio:
|
Criteri dell'organizzazione: il progetto base applica tutti i vincoli dei criteri dell'organizzazione a livello di nodo organizzazione. |
Potresti avere criteri di sicurezza o modi di lavorare diversi per parti diverse dell'azienda. In questo scenario, applica i vincoli dei criteri dell'organizzazione a un nodo inferiore nella gerarchia delle risorse. Consulta l'elenco completo dei vincoli relativi ai criteri dell'organizzazione che contribuiscono a soddisfare i tuoi requisiti. |
Strumenti della pipeline di deployment: il progetto utilizza Cloud Build per eseguire la pipeline di automazione. |
Potresti preferire altri prodotti per la tua pipeline di deployment, ad esempio Terraform Enterprise, GitLab Runners, GitHub Actions o Jenkins. Il progetto include indicazioni alternative per ogni prodotto. |
Repository di codice per il deployment: il progetto utilizzato utilizza Cloud Source Repositories come repository Git privato gestito. |
Utilizza il tuo sistema di controllo della versione preferito per gestire i repository di codice, ad esempio GitLab, GitHub o Bitbucket. Se utilizzi un repository privato ospitato nel tuo ambiente on-premise, configura un percorso di rete privata dal repository al tuo ambiente Google Cloud. |
Provider di identità: il progetto base presuppone un'Active Directory on-premise e federa le identità a 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 ancora un provider di identità, puoi creare e gestire le identità degli utenti direttamente in Cloud Identity. Se hai già un provider di identità, ad esempio Okta, Ping o ID voce Azure, puoi gestire gli account utente nel provider di identità esistente e sincronizzarlo con Cloud Identity. Se hai requisiti di sovranità dei dati o di conformità che ti impediscono l'utilizzo di Cloud Identity e se non richiedi le identità degli utenti Google gestiti per altri servizi Google come Google Ads o Google Marketing Platform, potresti preferire la federazione delle identità per la forza lavoro. In questo scenario, presta attenzione alle limitazioni dei servizi supportati. |
Più regioni: il progetto prevede il deployment di risorse a livello di regione in due diverse regioni Google Cloud per facilitare la progettazione dei carichi di lavoro tenendo conto dei requisiti di alta disponibilità e ripristino di emergenza. |
Se gli utenti finali si trovano in più località geografiche, potresti configurare più regioni Google Cloud per creare risorse più vicine all'utente finale con minore 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. |
Assegnazione degli indirizzi IP: il progetto base fornisce un insieme di intervalli di indirizzi IP. |
Potresti dover modificare gli intervalli specifici di indirizzi IP utilizzati in base alla disponibilità degli indirizzi IP nell'ambiente ibrido esistente. Se modifichi gli intervalli di indirizzi IP, utilizza il progetto base 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 su più siti fisici e regioni di Google Cloud per la massima larghezza di banda e disponibilità. |
A seconda dei 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 a Dedicated Interconnect in un secondo momento. Se non hai un ambiente on-premise, potresti non aver bisogno del networking ibrido. |
Perimetro dei Controlli di servizio VPC: il progetto consiglia un singolo perimetro che include tutti i progetti di servizio associati a una rete VPC limitata. I progetti associati a una rete VPC di base non sono inclusi all'interno del perimetro. |
Potresti avere un caso d'uso che richiede più perimetri per un'organizzazione o potresti decidere di non utilizzare 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 l'utilizzo di 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 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 l'utilizzo di un unico progetto per la gestione dell'accesso alle chiavi. Un approccio centralizzato può aiutare a soddisfare requisiti di conformità come i depositari 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 base configura un insieme di sink di log nel nodo organizzazione, in modo che un team di sicurezza centrale possa esaminare gli audit log dell'intera organizzazione. |
Potresti avere team diversi che sono responsabili della verifica di diverse parti dell'azienda, i quali potrebbero richiedere log diversi per 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 dei log per un controllo dell'accesso granulare dell'accesso a un bucket di log comune. |
Progetti di definizione dell'ambito di monitoraggio: il progetto base configura un singolo progetto di definizione dell'ambito di monitoraggio per ogni ambiente. |
Potresti configurare progetti di ambito più granulari gestiti da team diversi, con un ambito basato su un insieme di progetti contenenti le applicazioni gestite da ogni team. |
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 un'unica pipeline di infrastruttura gestita da un team centrale se hai un team centrale responsabile del deployment di tutti i progetti e dell'infrastruttura. Questo team centrale può accettare le richieste di pull dai team dei carichi di lavoro per esaminarle e approvarle prima della creazione del progetto oppure il team può creare autonomamente le richieste pull in risposta a un sistema basato su ticket. Potresti preferire pipeline più granulari se i 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 sulla sicurezza in Security Command Center. |
Decidi se esportare i risultati sulla sicurezza da Security Command Center a strumenti come Google Security Operations o SIEM esistente oppure 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 on-premise: il progetto configura un endpoint Private Service Connect univoco per ogni VPC condiviso, utile per abilitare la progettazione con più perimetri Controlli di servizio VPC. |
Se non hai bisogno di più perimetri Controlli di servizio VPC, potrebbe non essere necessario eseguire il routing da un ambiente on-premise agli endpoint Private Service Connect a questo livello di granularità. Anziché 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
- Implementa 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.
Esamina la libreria dei progetti per accelerare la progettazione e la creazione di carichi di lavoro aziendali comuni, tra cui:
Consulta le soluzioni correlate per il deployment nel tuo ambiente di base.
Per accedere a un ambiente dimostrativo, contattaci all'indirizzo security-foundations-blueprint-support@google.com.