Best practice per le operazioni

Questa sezione illustra le operazioni che devi prendere in considerazione durante il deployment e l'esecuzione di carichi di lavoro aggiuntivi nel tuo ambiente Google Cloud. Questa sezione non intende essere esaustiva di tutte le operazioni nel tuo ambiente cloud, ma introduce le decisioni relative ai suggerimenti dell'architettura e alle risorse di cui è stato eseguito il deployment mediante il progetto base.

Aggiorna le risorse di base

Sebbene il progetto fornisca un buon punto di partenza per l'ambiente di base, i requisiti di base potrebbero aumentare nel tempo. Dopo il deployment iniziale, potresti modificare le impostazioni di configurazione o creare nuovi servizi condivisi per l'utilizzo da parte di 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, dell'unione e dell'attivazione delle pipeline di deployment.

Decidi gli attributi per i nuovi progetti dei carichi di lavoro

Quando crei nuovi progetti tramite il modulo Project Fab della pipeline di automazione, devi configurare vari attributi. Il processo di progettazione e creazione di progetti per nuovi carichi di lavoro deve includere decisioni relative a quanto segue:

• Quali API Google Cloud abilitare
• Quale VPC condiviso utilizzare o se creare una nuova rete VPC
• Quali ruoli IAM creare per il project-service-account iniziale creato dalla pipeline
• Quali etichette di progetto applicare
• La cartella in cui viene eseguito il deployment del progetto
• Account di fatturazione da utilizzare
• Indica se aggiungere il progetto a un perimetro dei Controlli di servizio VPC
• Indica se configurare una soglia di avviso per il budget e la fatturazione per il progetto

Per un riferimento completo degli attributi configurabili per ciascun progetto, consulta le variabili di input per la fabbrica del progetto nella pipeline di automazione.

Gestisci le autorizzazioni su larga scala

Quando esegui il deployment dei progetti dei carichi di lavoro sugli elementi di base, devi valutare come concederai l'accesso agli sviluppatori e ai consumatori che utilizzano questi progetti. Ti consigliamo di aggiungere utenti a un gruppo gestito dal tuo provider di identità esistente, di sincronizzare i gruppi con Cloud Identity e quindi di 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 in eccesso. Progetta un processo per rivedere periodicamente i suggerimenti o applicarli automaticamente nelle pipeline di deployment.

Coordina le modifiche tra il team di networking e il team delle applicazioni

Le topologie di rete di cui viene eseguito il deployment dal progetto presuppongono che tu abbia un team responsabile della gestione delle risorse di rete e team separati responsabili del deployment delle risorse dell'infrastruttura dei carichi di lavoro. Quando i team dei carichi di lavoro eseguono il deployment dell'infrastruttura, devono creare regole firewall per consentire i percorsi di accesso previsti tra i componenti del carico di lavoro, ma non hanno l'autorizzazione per modificare i criteri firewall di rete stessi.

Pianificare in che modo i team collaboreranno per coordinare le modifiche alle risorse di networking centralizzate necessarie per il deployment delle applicazioni. Ad esempio, potresti progettare un processo in cui un team dei carichi di lavoro richiede i tag per le proprie applicazioni. Il team di networking crea quindi i tag e aggiunge regole al criterio firewall di rete per consentire il flusso del traffico da una risorsa all'altra con i tag. Inoltre, delega i ruoli IAM per l'utilizzo dei tag al team per il carico di lavoro.

Ottimizza il tuo ambiente con la gamma Active Assist

Oltre al motore per suggerimenti IAM, Google Cloud fornisce il portafoglio di servizi Active Assist per fornire suggerimenti su come ottimizzare l'ambiente. Ad esempio, gli insight del firewall o il motore per suggerimenti sui progetti inattivi forniscono suggerimenti strategici che possono aiutare a rafforzare la strategia di sicurezza.

Progetta un processo per rivedere periodicamente i suggerimenti o applicarli automaticamente nelle pipeline di deployment. Decidi quali suggerimenti devono essere gestiti da un team centrale e quali devono essere responsabilità dei proprietari dei carichi di lavoro e applica i ruoli IAM per accedere ai suggerimenti di conseguenza.

Concedi eccezioni ai criteri dell'organizzazione

Il progetto applica una serie di vincoli dei criteri dell'organizzazione consigliati alla maggior parte dei clienti nella maggior parte degli scenari, ma potresti avere casi d'uso legittimi che richiedono eccezioni limitate ai criteri dell'organizzazione che applichi su larga scala.

Ad esempio, il progetto applica il vincolo iam.disableServiceAccountKeyCreation. Questo vincolo è un importante controllo di sicurezza perché una chiave dell'account di servizio divulgata può avere un impatto negativo significativo e la maggior parte degli scenari dovrebbe utilizzare alternative più sicure alle chiavi degli account di servizio per l'autenticazione. Tuttavia, potrebbero verificarsi casi d'uso in cui è possibile eseguire l'autenticazione 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 carichi di lavoro. In questo scenario, potresti decidere di consentire un'eccezione al criterio, a condizione che vengano applicati controlli di compensazione aggiuntivi come le best practice per la gestione delle chiavi degli account di servizio.

Pertanto, è necessario progettare un processo per i carichi di lavoro per richiedere un'eccezione ai criteri e garantire che i responsabili delle decisioni responsabili della concessione delle eccezioni dispongano delle conoscenze tecniche per convalidare il caso d'uso e consultare la necessità di implementare controlli aggiuntivi per compensare. Quando concedi un'eccezione a un carico di lavoro, modifica il vincolo del criterio dell'organizzazione nel modo più limitato possibile. Puoi anche aggiungere vincoli a un criterio dell'organizzazione definendo un tag che concede un'eccezione o un'applicazione del criterio e quindi applicando il tag a progetti e cartelle.

Proteggi le tue risorse con i Controlli di servizio VPC

Il progetto aiuta a preparare l'ambiente per i Controlli di servizio VPC separando le reti di base e quelle limitate. Tuttavia, per impostazione predefinita, il codice Terraform non abilita i Controlli di servizio VPC perché questa abilitazione può rappresentare un processo invasivo.

Un perimetro nega l'accesso ai servizi Google Cloud limitati dal traffico che ha origine al di fuori del perimetro, che include la console, le workstation degli sviluppatori e la pipeline di base utilizzata per il deployment delle risorse. Se utilizzi Controlli di servizio VPC, devi progettare eccezioni al perimetro che consentano i percorsi di accesso desiderati.

Un perimetro dei Controlli di servizio VPC è destinato ai controlli di esfiltrazione tra l'organizzazione Google Cloud e le origini esterne. Il perimetro non è pensato per sostituire o duplicare i criteri di autorizzazione per un controllo granulare degli accessi a singoli progetti o risorse. Quando progetti e progetti un perimetro, ti consigliamo di utilizzare un perimetro unificato comune per ridurre i costi 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 perimetrale più complessa e i percorsi di accesso tra i perimetri necessari per le operazioni previste.

Per adottare i 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 i Controlli di servizio VPC.

• Come configurare l'accesso del deployment di emergenza per modificare il perimetro in caso di interruzione delle pipeline di automazione.

• Scopri come utilizzare le best practice per l'abilitazione dei Controlli di servizio VPC per progettare e implementare il perimetro.

Una volta abilitato il perimetro, ti consigliamo di progettare un processo per aggiungere in modo coerente nuovi progetti al perimetro corretto e un processo per progettare le eccezioni quando gli sviluppatori hanno un nuovo caso d'uso negato 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 eseguire test. Per le risorse dei carichi di lavoro, questo approccio è facilitato da ambienti separati relativi a sviluppo, non produzione e produzione. Tuttavia, alcune risorse dell'organizzazione non dispongono di ambienti separati per facilitare i test.

Per le modifiche a livello di organizzazione o per altre modifiche che possono influire sugli ambienti di produzione, come la configurazione tra il provider di identità e Cloud Identity, valuta la possibilità di creare un'organizzazione separata a scopo di test.

Controlla l'accesso remoto alle macchine virtuali

Poiché consigliamo di eseguire il deployment dell'infrastruttura immutabile tramite la pipeline di base, la pipeline dell'infrastruttura e la pipeline dell'applicazione, ti consigliamo anche di concedere agli sviluppatori l'accesso diretto a una macchina virtuale tramite SSH o RDP solo per casi d'uso limitati o eccezionali.

Per scenari che richiedono l'accesso remoto, ti consigliamo di gestire l'accesso degli utenti utilizzando OS Login, ove possibile. Questo approccio utilizza i servizi gestiti di Google Cloud per applicare controllo dell'accesso#39;accesso, la gestione del ciclo di vita degli account, la verifica in due passaggi e l'audit logging. 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 archiviare le credenziali in modo sicuro al di fuori di Google Cloud.

In qualsiasi scenario, un utente con accesso SSH o RDP a una VM può rappresentare un rischio di escalation dei privilegi, quindi dovresti progettare il tuo modello di accesso tenendo presente questo aspetto. L'utente può eseguire il codice su quella VM con i privilegi dell'account di servizio associato o eseguire una query sul server dei metadati per visualizzare il token di accesso utilizzato per autenticare le richieste API. Questo accesso può quindi essere un'escalation dei privilegi se non intendevi deliberatamente che l'utente operi con i privilegi dell'account di servizio.

Riduci la spesa eccessiva pianificando avvisi sul budget

Il progetto implementa le best practice introdotte nel framework dell'architettura Google Cloud: ottimizzazione dei costi per la gestione dei costi, tra cui:

• Utilizza un unico account di fatturazione per tutti i progetti nella piattaforma aziendale.

• Assegna a ogni progetto un'etichetta di metadati billingcode 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 progetto crea avvisi relativi al budget per i progetti dei carichi di lavoro quando la spesa prevista è in linea con il raggiungimento del 120% del budget. Questo approccio consente a un team centrale di identificare e mitigare gli incidenti di spesa eccessiva significativa. Aumenti significativi inaspettati della spesa senza una causa chiara possono essere un indicatore di un incidente di sicurezza e devono essere analizzati dal punto di vista del controllo dei costi e della sicurezza.

A seconda del caso d'uso, potresti impostare un budget basato sul costo di un'intera cartella di ambiente o di tutti i progetti correlati a un determinato centro di costo, anziché impostare budget granulari per ogni progetto. 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 sulla creazione di funzionalità FinOps, inclusa la previsione dei budget per i carichi di lavoro, consulta la guida introduttiva a FinOps su Google Cloud.

Allocare i costi tra i centri di costo interni

La console consente di visualizzare i report di fatturazione per vedere 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 dati di fatturazione esportati consentono di allocare i costi per le dimensioni personalizzate, ad esempio i centri di costo interni, in base ai metadati delle etichette di progetto come billingcode.

La seguente query SQL è una query di esempio per comprendere i costi di tutti i progetti raggruppati in base all'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, vedi Esportare i dati di fatturazione Cloud in BigQuery.

Se hai bisogno di una contabilità interna o di uno storno di addebito tra i centri di costo, è tua responsabilità incorporare i dati ottenuti da questa query nei tuoi processi interni.

Importa i risultati dei controlli di rilevamento nel SIEM esistente

Anche se le risorse di base consentono di configurare le destinazioni aggregate per gli audit log e i risultati sulla sicurezza, è tua responsabilità decidere come assumere e utilizzare questi indicatori.

Se hai la necessità di 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. Potresti creare un'unica esportazione per tutti i log e i risultati se un singolo team è responsabile del monitoraggio della sicurezza in tutto l'ambiente oppure creare più esportazioni filtrate in base all'insieme di log e risultati necessari per più team con responsabilità diverse.

In alternativa, se il volume dei log e i costi sono proibitivi, puoi evitare i duplicati conservando i log e i risultati di Google Cloud solo in Google Cloud. In questo scenario, assicurati che i team esistenti dispongano dell'accesso e della formazione adeguati per lavorare con log e risultati direttamente in Google Cloud.

• Per gli audit log, progetta visualizzazioni dei log in modo da concedere ai singoli team l'accesso a un sottoinsieme di log nel bucket di log centralizzato, anziché duplicare i log in più bucket, aumentando i costi di archiviazione dei log.
• Per i risultati relativi alla sicurezza, concedi a Security Command Center ruoli a livello di cartella e di progetto per consentire ai team di visualizzare e gestire i risultati relativi alla sicurezza solo per i progetti di cui sono responsabili, direttamente nella console.

Sviluppa costantemente la tua libreria di controlli

Il progetto parte da una base di controlli per rilevare e prevenire le minacce. Ti consigliamo di rivedere questi controlli e aggiungerne altri in base ai tuoi requisiti. La tabella seguente riassume i meccanismi per applicare le norme di governance e come estenderli per requisiti aggiuntivi:

Controlli dei criteri applicati dal progetto	Indicazioni per estendere questi controlli
Security Command Center rileva vulnerabilità e minacce da diverse origini 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 sui 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 configurazioni accettabili prima del deployment.	Sviluppa vincoli aggiuntivi in base alle indicazioni riportate in GoogleCloudPlatform/policy-library.
L'opzione Avvisi per metriche basate su log e metriche di prestazioni consente di configurare le metriche basate su log per inviare avvisi in caso di modifiche ai criteri e alle configurazioni IAM di alcune risorse sensibili.	Progetta metriche e criteri di avviso aggiuntivi basati su log per gli eventi dei log che prevedi non dovrebbero verificarsi nel tuo ambiente.
Una soluzione personalizzata per l'analisi automatizzata dei log interroga regolarmente i log per rilevare attività sospette e crea risultati di Security Command Center.	Scrivi ulteriori query per creare risultati per gli eventi di sicurezza che vuoi monitorare, utilizzando l'analisi dei log di sicurezza come riferimento.
Una soluzione personalizzata per rispondere alle modifiche agli asset crea risultati di Security Command Center e può automatizzare le azioni di correzione.	Creare feed aggiuntivi di Cloud Asset Inventory per monitorare le modifiche per particolari tipi di asset e scrivere altre funzioni Cloud Functions con logica personalizzata per rispondere alle violazioni delle norme.

Questi controlli possono evolversi con l'evolversi dei tuoi requisiti e della tua maturità su Google Cloud.

Gestisci le chiavi di crittografia con Cloud Key Management Service

Google Cloud fornisce la crittografia predefinita at-rest per tutti i contenuti dei clienti, ma fornisce anche Cloud Key Management Service (Cloud KMS) per offrirti un controllo aggiuntivo sulle chiavi di crittografia per i dati at-rest. Ti consigliamo di valutare se la crittografia predefinita è sufficiente o se hai un requisito di conformità che prevede l'utilizzo di Cloud KMS per gestire le chiavi autonomamente. Per ulteriori informazioni, consulta Decidere come soddisfare i requisiti di conformità per la crittografia at-rest.

Il progetto fornisce un progetto prj-c-kms nella cartella comune e un progetto prj-{env}-kms in ogni cartella di ambiente per la gestione centralizzata delle chiavi di crittografia. Questo approccio consente a un team centrale di controllare e gestire le chiavi di crittografia utilizzate dalle risorse nei progetti dei carichi di lavoro, per soddisfare i requisiti normativi e di conformità.

A seconda del modello operativo, potresti preferire un'unica istanza di progetto centralizzata di Cloud KMS sotto il controllo di un singolo team, gestire le chiavi di crittografia separatamente in ogni ambiente oppure più istanze distribuite in modo che la responsabilità delle chiavi di crittografia possa essere delegata ai team appropriati. Modifica l'esempio di codice Terraform in base alle esigenze del tuo modello operativo.

Facoltativamente, puoi applicare i criteri dell'organizzazione delle chiavi di crittografia gestite dal cliente (CMEK) per far sì che determinati tipi di risorse richiedano sempre una chiave CMEK e che possano essere utilizzate solo chiavi CMEK di una lista consentita di progetti attendibili.

Archivia e controlla le credenziali dell'applicazione 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. Esegui invece il commit del secret in Secret Manager e concedi il ruolo IAM Funzione di accesso a secret di Secret Manager all'account utente o di servizio che deve accedere al secret. Ti consigliamo di concedere il ruolo IAM a un singolo secret, non a tutti i secret nel progetto.

Se possibile, devi generare automaticamente i secret di produzione all'interno delle pipeline CI/CD e mantenerli inaccessibili agli utenti umani, tranne che in situazioni di deployment di emergenza. In questo scenario, assicurati di non concedere ruoli IAM per visualizzare questi secret a nessun utente o gruppo.

Il progetto fornisce un singolo progetto prj-c-secrets nella cartella comune e un progetto prj-{env}-secrets in ogni cartella di ambiente per la gestione centralizzata dei secret. Questo approccio consente a un team centrale di verificare 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 oppure più istanze distribuite di Secret Manager in modo che ogni team del carico di lavoro possa gestire i propri secret. Modifica l'esempio di codice Terraform in base alle esigenze del tuo modello operativo.

Pianificare l'accesso di emergenza agli account con privilegi elevati

Anche se consigliamo di gestire le modifiche alle risorse di base tramite IaC con controllo della versione di cui viene eseguito il deployment dalla pipeline di base, potresti avere scenari eccezionali o di emergenza che richiedono un accesso privilegiato per modificare direttamente l'ambiente. Ti consigliamo di pianificare gli account di deployment di emergenza (a volte chiamati account di emergenza o chiamate antincendio) che hanno accesso con privilegi elevati al tuo ambiente in caso di emergenza o quando i processi di automazione subiscono un guasto.

Nella tabella seguente vengono descritti alcuni scopi esemplificativi degli account di deployment di emergenza.

Scopo del deployment di emergenza	Descrizione
Super amministratore	Accesso di emergenza al ruolo di super amministratore 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 potrà quindi concedere l'accesso a qualsiasi altro ruolo IAM nell'organizzazione.
Amministratore pipeline di base	Accesso di emergenza per modificare le risorse nel tuo progetto CICD su Google Cloud e nel repository Git esterno in caso di problemi di automazione della pipeline di base.
Suite operativa o SRE	Un team operativo o SRE ha bisogno di un accesso privilegiato per rispondere a interruzioni o incidenti. Possono includere attività come il riavvio delle VM o il ripristino dei dati.

Il meccanismo per consentire l'accesso del deployment di emergenza dipende dagli strumenti e dalle procedure esistenti, ma alcuni meccanismi di esempio includono:

• Usa i tuoi strumenti esistenti per la gestione degli accessi con privilegi per aggiungere temporaneamente un utente a un gruppo predefinito con ruoli IAM con privilegi elevati o per utilizzare le credenziali di un account con privilegi elevati.
• Account di pre-provisioning destinati esclusivamente all'utilizzo da parte degli amministratori. Ad esempio, la sviluppatore Dana potrebbe avere l'identità dana@example.com per l'uso quotidiano e admin-dana@example.com per l'accesso del deployment di emergenza.
• Utilizza un'applicazione come l'accesso con privilegi just-in-time che consente a uno sviluppatore di eseguire autonomamente l'escalation a ruoli con più privilegi.

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 deployment di emergenza diverso per unità aziendali diverse per assicurarti che non possano interrompersi a vicenda.
• In che modo il tuo meccanismo previene gli abusi? Hai bisogno di approvazioni? Ad esempio, potresti avere operazioni di ripartizione in cui una persona detiene le credenziali e un'altra detiene il token MFA.
• Come esegui il controllo e gli avvisi sull'accesso del deployment di emergenza? Ad esempio, puoi configurare un modulo personalizzato Event Threat Detection per creare un risultato di sicurezza quando viene utilizzato un account di deployment di emergenza predefinito.
• Come si rimuove l'accesso del deployment di emergenza e si riprende il normale funzionamento al termine dell'incidente?

Per le attività comuni di escalation dei privilegi e il rollback delle modifiche, consigliamo di progettare flussi di lavoro automatizzati in cui un utente possa eseguire l'operazione senza richiedere l'escalation dei privilegi per la propria identità utente. Questo approccio può aiutare a ridurre l'errore umano e migliorare la sicurezza.

Per i sistemi che richiedono un intervento regolare, automatizzare la correzione potrebbe essere la soluzione migliore. Google incoraggia i clienti ad adottare un approccio di produzione zero-touch per apportare tutte le modifiche alla produzione utilizzando l'automazione, i proxy sicuri o un deployment di emergenza controllato. Google fornisce i libri sull'SRE ai clienti che vogliono adottare l'approccio SRE di Google.

Passaggi successivi

• Leggi Eseguire il deployment del progetto (documento successivo di questa serie).