Questa sezione illustra le operazioni che devi prendere in considerazione durante il deployment e il funzionamento di carichi di lavoro aggiuntivi nel tuo ambiente Google Cloud. 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-accountiniziale 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 Controlli di servizio VPC
- 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, poi delega i ruoli IAM per l'utilizzo dei tag al team di lavoro.
Ottimizza il tuo ambiente con il portafoglio Active Assist
Oltre al Recommender 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.
Concedere 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 dell'account di servizio, ad esempio un server on-premise che richiede l'accesso ai servizi Google Cloud e non può utilizzare la federazione delle identità per i workload. 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 condizioni ai vincoli di un criterio dell'organizzazione definendo un tag che concede un'eccezione o l'applicazione forzata del criterio, quindi applicandolo ai progetti e alle 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 limitazioni al 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 organizzazione Google Cloud 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 dei servizi all'interno della tua organizzazione Google Cloud, 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 servizi Google Cloud richiesti supportano 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 controllo dell'accesso'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 framework dell'architettura di Google Cloud: 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'
billingcodeetichetta 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 negli strumenti e nelle procedure 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 log e i risultati di Google Cloud solo in Google 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 in Google 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 i criteri di governance e come estenderli per i tuoi requisiti aggiuntivi:
| Controlli dei criteri applicati dal blueprint | Indicazioni per estendere questi controlli |
|---|---|
Security Command Center rileva vulnerabilità e minacce provenienti da più fonti di sicurezza. |
Definisci moduli personalizzati per Security Health Analytics e moduli personalizzati per Event Threat Detection. |
Il servizio Norme dell'organizzazione applica un insieme consigliato di vincoli dei criteri dell'organizzazione ai servizi Google Cloud. |
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 Cloud Asset Inventory 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 requisiti e al livello di maturità su Google 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, vedi 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 segreto in Secret Manager e concedi il ruolo IAM Accesso ai segreti di Secret Manager all'utente o all'account di servizio che deve accedere al segreto. 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-{env}-secrets in ogni cartella dell'ambiente per gestire i secret in modo centralizzato. 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 nel progetto CI/CD su Google Cloud e nel repository Git esterno nel caso in cui si verifichi un guasto nell'automazione della pipeline di base. |
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, 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 escalation 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 escalation 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).