Questa sezione descrive il processo che puoi utilizzare per eseguire il deployment del progetto base, convenzioni di denominazione e alternative ai suggerimenti relativi ai progetti.
Riepilogo
Per eseguire il deployment degli elementi di base aziendali 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, il deployment automatizzato terraform-example-foundation su GitHub e passaggi aggiuntivi che devono essere configurati manualmente dopo il il deployment di base iniziale sia completato.
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 seguenti:
|
Passaggi per eseguire il deployment di terraform-example-foundation da GitHub |
Segui le indicazioni 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 offre controlli amministrativi aggiuntivi che possono aiutarti a di sicurezza e conformità. Tuttavia, alcuni controlli comportano ulteriori a compromessi in termini di costi o operativi che potrebbero non essere appropriati per tutti i clienti. Questi controlli richiedono anche input personalizzati per le tue esigenze specifiche che non possono essere completamente automatizzati nel progetto, con un valore predefinito per clienti.
Questa sezione introduce i controlli di sicurezza che applichi centralmente ai tuoi base. Questa sezione non intende essere esaustiva di tutte le funzionalità di sicurezza controlli che puoi applicare a carichi di lavoro specifici. Per ulteriori informazioni sulle per prodotti e soluzioni per la sicurezza, consulta il Centro best practice per la sicurezza di Google Cloud.
Valuta se i seguenti controlli sono appropriati per la tua base in base ai 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 accesso ai servizi gestiti da Google al di fuori di un perimetro attendibile, bloccare l'accesso ai dati da località non attendibili e mitigare i rischi di esfiltrazione di dati. Tuttavia, I Controlli di servizio VPC possono causare l'interruzione dei servizi esistenti finché non definisci eccezioni per consentire i pattern di accesso previsti. Valuta se il valore della riduzione dei rischi di esfiltrazione giustifica la maggiore complessità e overhead operativo derivante dall'adozione dei Controlli di servizio VPC. Lo schema prepara reti con restrizioni e variabili facoltative da configurare Controlli di servizio VPC, ma il perimetro non è abilitato finché non prendi passaggi aggiuntivi per progettarla e abilitarla. |
|
Potrebbero essere previsti requisiti normativi secondo cui le risorse cloud devono di cui è stato eseguito il deployment in località geografiche approvate. Questo vincolo dei criteri dell'organizzazione richiede che sia possibile eseguire il deployment delle risorse solo nell'elenco di località definire. |
|
Assured Workloads fornisce controlli di conformità aggiuntivi che aiutano a rispettare specifici regimi normativi. Il progetto fornisce facoltativi nella pipeline di deployment per l'abilitazione. |
|
Potrebbe essere necessario registrare tutti gli accessi a determinati dati sensibili o risorse. Valuta dove i carichi di lavoro gestiscono i dati sensibili che richiede i log di accesso ai dati e abilita i log per ciascun servizio e ambiente lavorando con dati sensibili. |
|
Access Approval garantisce che assistenza clienti Google Cloud e richiedono la tua approvazione esplicita ogni volta che devono accedere ai tuoi i contenuti dei clienti. Valutare il processo operativo necessario per esaminare le richieste di Access Approval per ridurre i possibili ritardi la risoluzione degli incidenti di assistenza. |
|
Key Access Justifications ti consente di controllare in modo programmatico se Google può accedere alle tue chiavi di crittografia, ad esempio per operazioni automatizzate e per Assistenza clienti per accedere ai contenuti dei clienti. Valuta il costo e l'overhead operativo associato a Key Access Justifications, nonché ai suoi su Cloud External Key Manager (Cloud EKM). |
|
Cloud Shell è una di sviluppo online. Questa shell è ospitata su un server gestito da Google al di fuori del tuo ambiente. Pertanto, non è soggetta ai controlli che definisci che potresti aver implementato sulle tue workstation di sviluppo. Se vuoi controllare rigorosamente le workstation che uno sviluppatore può utilizzare per accedere al cloud e le risorse, disabilita Cloud Shell. Potresti anche valutare Cloud Workstations per un un'opzione di workstation configurabile nel proprio ambiente. |
|
Google Cloud ti consente di limitare l'accesso alla console Google Cloud in base all'accesso attributi di livello come appartenenza ai gruppi, intervalli di indirizzi IP attendibili e 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, come parte di un percorso zero il deployment attendibile. |
Convenzioni di denominazione
Ti consigliamo di utilizzare una convenzione di denominazione standardizzata per dell'accesso a specifiche risorse Google Cloud. La seguente tabella descrive le tradizionali per i nomi delle risorse nel progetto.
Risorsa | Convenzione di denominazione |
---|---|
Cartella |
Ad esempio:
|
ID progetto |
Ad esempio: |
Rete VPC |
Ad esempio: |
Subnet |
Ad esempio: |
Criteri firewall |
Per 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: |
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 i suggerimenti per soddisfare le tue esigenze specifiche. La tabella seguente introduce alcune delle varianti comuni che potreste aver bisogno in base alla vostra lo stack tecnologico e i modi di lavorare esistenti.
Area decisionale | Possibili alternative |
---|---|
Organizzazione: il progetto utilizza una singola organizzazione come nodo radice per tutte le risorse. |
Decidi una gerarchia delle risorse per la zona di destinazione di Google Cloud scenari in cui potresti preferire l'uso di più organizzazioni, ad esempio:
|
Struttura delle cartelle: il progetto ha una semplice cartella
con carichi di lavoro suddivisi in |
Decidi una gerarchia delle risorse per la zona di destinazione di Google Cloud per strutturare le cartelle in base a come vuoi gestirle, risorse ed ereditare criteri come:
|
Criteri dell'organizzazione: il progetto applica tutti vincoli dei criteri dell'organizzazione a livello del nodo organizzazione. |
Potrebbero esserci diversi criteri di sicurezza o modalità di lavoro per diversi settori dell'attività. In questo scenario, applica il criterio dell'organizzazione a un nodo inferiore della gerarchia delle risorse. Esamina l'elenco completo di organizzazione vincoli previsti dalle norme 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 direzioni 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, ad esempio GitLab, GitHub o Bitbucket. Se utilizzi una connessione privata per un repository privato ospitato nel tuo ambiente on-premise, percorso di rete dal repository a Google Cloud completamente gestito di Google Cloud. |
Provider di identità: il progetto presuppone un deployment on-premise Active Directory e federa le identità a Cloud Identity utilizzando Google Cloud Directory Sync. |
Se usi già Google Workspace, puoi utilizzare le identità Google che sono già gestiti in Google Workspace. Se non disponi di un di identità esistente, puoi creare e gestire direttamente le identità degli utenti in Cloud Identity. Se hai già un provider di identità, ad esempio come Okta, Ping, o Azure Entra ID, potresti gestire gli account utente nel tuo provider di identità esistente. e la sincronizzazione con Cloud Identity. Se disponi della sovranità dei dati ai requisiti di conformità che ti impediscono di utilizzare Cloud Identity se non sono necessarie identità degli utenti Google gestite per altri servizi Google come Google Ads o Google Marketing Platform, allora preferisci la forza lavoro la federazione delle identità. In questo scenario, tieni presente le limitazioni previste dalle app supportate Google Cloud. |
Più regioni: il progetto esegue il deployment a livello di regione in due diverse regioni Google Cloud per consentire l'abilitazione di progettazione con requisiti di alta disponibilità e ripristino di emergenza mente. |
Se hai utenti finali in più località geografiche, puoi configurare regioni Google Cloud in più per creare risorse più vicine all'utente finale con una minore latenza. Se hai vincoli di sovranità dei dati o le esigenze di disponibilità in una singola regione, puoi configurarne regione Google Cloud. |
Allocazione degli indirizzi IP: il progetto fornisce un insieme di di indirizzi IP esterni. |
Potresti dover modificare gli intervalli di indirizzi IP specifici utilizzati in base Disponibilità degli indirizzi IP nel tuo ambiente ibrido esistente. Se modifichi di indirizzi IP, utilizza il progetto come guida per il numero e le dimensioni intervalli obbligatori ed esamina l'indirizzo IP valido di archiviazione per Google Cloud. |
Networking ibrido: il progetto utilizza Dedicated Interconnect su più siti fisici e Regioni di Google Cloud per ottenere la massima disponibilità e larghezza di banda. |
A seconda dei tuoi requisiti di costo, larghezza di banda e affidabilità aggiuntivi, puoi configurare Partner Interconnect o Cloud VPN . Se devi iniziare a eseguire il deployment delle risorse con prima di poter completare una connessione Dedicated Interconnect potresti iniziare con Cloud VPN e passare all'uso Dedicated Interconnect più tardi. Se non disponi di un on-premise, potresti non aver bisogno del networking ibrido. |
Perimetro Controlli di servizio VPC: il progetto consiglia un unico perimetro che include tutti i progetti di servizio associati in una rete VPC limitata. I progetti associati a una rete VPC di base non incluse all'interno del perimetro. |
Potresti avere un caso d'uso che richiede perimetri per un'organizzazione oppure puoi decidere di non usare 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 aver utilizzato Secret Manager nella cartella |
Se hai un solo team responsabile della gestione e del controllo segreti sensibili all'interno dell'organizzazione, potresti preferire utilizzarne uno progetto per la gestione dell'accesso ai secret. Se consenti ai team dei carichi di lavoro di gestire e i loro segreti, potresti non usare un progetto centralizzato per gestire l'accesso ai secret e lascia che i team utilizzino le proprie istanze Secret Manager nei progetti dei carichi di lavoro. |
Cloud KMS: il progetto esegue il deployment di un progetto per
utilizzando Cloud KMS nella cartella |
Se hai un solo team responsabile della gestione e del controllo di crittografia delle chiavi di crittografia in tutta l'organizzazione, potresti preferire utilizzarne una progetto per la gestione dell'accesso alle chiavi. Un approccio centralizzato può aiutare a di conformità come i custodi delle chiavi PCI. Se consenti ai team dei carichi di lavoro gestire le proprie chiavi, potreste non usare un progetto centralizzato per la l'accesso alle chiavi, ma consente ai team di utilizzare le proprie Cloud KMS nei progetti dei carichi di lavoro. |
Sink di log aggregati: il progetto configura un insieme di sink di log a livello di nodo organizzazione per consentire a un team di sicurezza centrale di esaminarli e gli audit log di controllo dell'intera organizzazione. |
Potrebbero esserci diversi team responsabili dell'auditing parti dell'azienda e questi team potrebbero richiedere log diversi per eseguire le di lavoro. In questo scenario, progetta più sink aggregati nel modo appropriato cartelle e progetti e creare filtri in modo che ogni team riceva solo i log necessari o i log di progettazione viste per un controllo granulare degli accessi a un bucket di log comune. |
Granularità delle pipeline dell'infrastruttura: il progetto base 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 sistema se hai un team centrale responsabile del deployment di tutti i progetti dell'infrastruttura. Questo team centrale può accettare richieste di pull dal carico di lavoro team da rivedere e approvare prima della creazione del progetto oppure il team può creare il pull richiedersi in risposta a un sistema basato su ticket. Potresti preferire pipeline più granulari se i singoli clienti team dei carichi di lavoro hanno la possibilità di personalizzare le proprie pipeline progettare account di servizio con privilegi più granulari per le pipeline. |
Esportazioni SIEM: il progetto gestisce tutta la sicurezza in Security Command Center. |
Decidi se esportare i risultati sulla sicurezza da Security Command Center a come Google Security Operations o il tuo SIEM esistente, o se i team puoi usare la console per visualizzare e gestire i risultati sulla sicurezza. Potresti configurare più esportazioni con filtri unici per team diversi con ambiti diversi e responsabilità. |
Ricerche DNS per i servizi Google Cloud dall'ambiente on-premise: Il progetto configura un endpoint Private Service Connect univoco per per ogni VPC condiviso, per agevolare le progettazioni con perimetri Controlli di servizio VPC. |
Potresti non richiedere il routing da un ambiente on-premise gli endpoint Private Service Connect a questo livello di granularità non sono necessari più perimetri Controlli di servizio VPC. Invece di
mappatura degli host on-premise agli endpoint Private Service Connect
dell'ambiente, potresti semplificare la progettazione in modo da utilizzare
l'endpoint Private Service Connect con il bundle API appropriato,
o 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 raccolta dei progetti 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 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.