Best practice per le operazioni

Last reviewed 2023-12-20 UTC

Questa sezione illustra le operazioni che devi considerare quando esegui il deployment e l'utilizzo 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 decisioni relative ai suggerimenti sull'architettura e alle risorse di cui il progetto esegue il deployment.

Aggiorna le risorse di base

Sebbene il progetto costituisca un punto di partenza "guidato" per l'ambiente di base, i requisiti della base potrebbero aumentare nel tempo. Dopo il deployment iniziale, puoi regolare le impostazioni di configurazione o creare nuovi servizi condivisi utilizzabili da tutti i carichi di lavoro.

Per modificare le risorse di base, ti consigliamo di apportare tutte le modifiche tramite la pipeline di base. Esamina la strategia di branching per un'introduzione al flusso di scrittura del codice, unione e attivazione delle pipeline di deployment.

Decidi gli attributi per i nuovi progetti dei carichi di lavoro

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

API Google Cloud da 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
Etichette di progetto da applicare
La cartella in cui viene eseguito il deployment del progetto
Account di fatturazione da utilizzare
Se aggiungere il progetto a un perimetro dei Controlli di servizio VPC
Se configurare un budget e una soglia di avviso di fatturazione per il progetto

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

Gestisci le autorizzazioni su larga scala

Quando esegui il deployment di progetti dei carichi di lavoro sulla base dell'infrastruttura di base, devi valutare come concedere l'accesso agli sviluppatori e ai consumatori previsti per tali progetti. Ti consigliamo di aggiungere gli utenti a un gruppo gestito dal tuo provider di identità esistente, sincronizzare i gruppi con Cloud Identity e quindi 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 esaminare periodicamente i suggerimenti o applicarli automaticamente alle pipeline di deployment.

Coordina le modifiche tra il team di networking e il team addetto alle 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.

Pianifica la collaborazione tra i team 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 dei 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 consente il flusso del traffico tra le risorse con i tag e delega i ruoli IAM per l'utilizzo dei tag al team del carico di lavoro.

Ottimizza il tuo ambiente con la gamma Active Assist

Oltre al motore per suggerimenti IAM, Google Cloud offre 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 inattivi forniscono suggerimenti utili che possono aiutare a rafforzare la strategia di sicurezza.

Progetta un processo per rivedere periodicamente i suggerimenti o applicarli automaticamente alle pipeline di deployment. Decidi quali suggerimenti devono essere gestiti da un team centrale e quali dovrebbero 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 prevede 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 applicati su larga scala.

Ad esempio, il progetto applica il vincolo iam.disableServiceAccountKeyCreation. Questo vincolo è un controllo di sicurezza importante, 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 esserci casi d'uso che possono 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 aggiuntivi di compensazione come le best practice per la gestione delle chiavi degli account di servizio.

Pertanto, devi progettare un processo per i carichi di lavoro al fine di richiedere un'eccezione alle norme e assicurarti che i responsabili delle decisioni responsabili della concessione delle eccezioni abbiano le conoscenze tecniche necessarie per convalidare il caso d'uso e consultare l'esistenza di ulteriori controlli per compensare. Quando concedi un'eccezione a un carico di lavoro, modifica il vincolo del criterio dell'organizzazione nel modo più restrittivo possibile. Puoi anche aggiungere vincoli a un criterio dell'organizzazione in modo condizionale definendo un tag che concede un'eccezione o applicazione del criterio e poi 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 la rete di base da quella limitata. 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 dello sviluppatore 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 previsti.

Un perimetro dei Controlli di servizio VPC è destinato ai controlli di esfiltrazione tra la tua organizzazione Google Cloud e le origini esterne. Il perimetro non è destinato a sostituire o duplicare i criteri di autorizzazione per un controllo granulare dell'accesso a singoli progetti o risorse. Quando progetti e progetti un perimetro, ti consigliamo di utilizzare un perimetro unificato comune per ridurre l'overhead associato alla 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?
Indica se i servizi Google Cloud richiesti supportano i Controlli di servizio VPC.
Come configurare l'accesso di deployment di emergenza per modificare il perimetro in caso di interruzione delle pipeline di automazione.
Come utilizzare le best practice per abilitare i Controlli di servizio VPC al fine di progettare e implementare il tuo perimetro.

Dopo aver abilitato il perimetro, ti consigliamo di progettare un processo per aggiungere in modo coerente nuovi progetti al perimetro corretto e un processo per progettare eccezioni nel caso in cui gli sviluppatori abbiano un nuovo caso d'uso negato dalla tua attuale configurazione 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 con carico di lavoro, questo approccio è facilitato da ambienti separati per lo sviluppo, non la produzione e la produzione. Tuttavia, alcune risorse dell'organizzazione non hanno ambienti separati per facilitare i test.

Per modifiche a livello di organizzazione o 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 per scopi di test.

Controlla l'accesso remoto alle macchine virtuali

Poiché consigliamo di eseguire il deployment di un'infrastruttura immutabile tramite la pipeline di base, la pipeline dell'infrastruttura e la pipeline dell'applicazione, 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 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, 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 le chiavi SSH nei metadati o le 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 devi 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 in eccesso pianificando avvisi relativi al 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 esaminati dal punto di controllo dei costi e della sicurezza.

A seconda del tuo caso d'uso, potresti impostare un budget basato sul costo di un'intera cartella di ambiente o su tutti i progetti correlati 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 loro monitoraggio quotidiano.

Per indicazioni sulla creazione di funzionalità FinOps, inclusa la previsione dei budget per i carichi di lavoro, consulta Introduzione a FinOps su Google Cloud.

Distribuisci i costi tra i centri di costo interni

La console ti consente di visualizzare i report di fatturazione per vedere e prevedere il costo 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-logs. I record di fatturazione esportati consentono di allocare i costi per 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 del 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 centri di costo, è tua responsabilità incorporare i dati ottenuti da questa query nei tuoi processi interni.

Importa i risultati dai controlli del rilevamento nel tuo SIEM esistente

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

Se hai l'obbligo 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 dei risultati da Security Command Center negli strumenti e nei processi esistenti. Potresti creare un'unica esportazione per tutti i log e i risultati se un singolo team è responsabile del monitoraggio della sicurezza nell'intero ambiente oppure potresti creare più esportazioni filtrate nell'insieme di log e risultati necessari per più team con responsabilità diverse.

In alternativa, se il volume e i costi dei log sono proibitivi, potresti evitare 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 giusti per lavorare con log e risultati direttamente in Google Cloud.

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

Sviluppa continuamente la libreria di controlli

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

Controlli dei criteri applicati dal progetto base	Guida 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 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 le configurazioni accettabili prima del deployment.	Sviluppa vincoli aggiuntivi in base alle indicazioni disponibili in GoogleCloudPlatform/policy-library.
Gli avvisi sulle metriche basate su log e sulle metriche delle prestazioni configurano le metriche basate su log per avvisare in caso di modifiche ai criteri e alle configurazioni IAM di alcune risorse sensibili.	Progetta ulteriori metriche basate su log e criteri di avviso per gli eventi dei log che non dovrebbero verificarsi nel tuo ambiente.
Una soluzione personalizzata per l'analisi automatica dei log esegue regolarmente query sui log per individuare attività sospette e crea risultati di Security Command Center.	Scrivi query aggiuntive 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.	Crea feed Cloud Asset Inventory aggiuntivi per monitorare le modifiche per determinati tipi di asset e scrivi funzioni Cloud Functions aggiuntive 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 offre crittografia at-rest predefinita per tutti i contenuti dei clienti, ma offre anche Cloud Key Management Service (Cloud KMS) per offrirti un controllo aggiuntivo 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 devi utilizzare Cloud KMS per gestire le chiavi autonomamente. Per saperne di più, vedi Decidere come soddisfare i requisiti di conformità per la crittografia dei dati inattivi.

Il progetto fornisce un progetto prj-c-kms nella cartella comune e un progetto prj-{env}-kms in ogni cartella dell'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 tuo modello operativo, preferisci che un'unica istanza di progetto centralizzata di Cloud KMS sia sotto il controllo di un singolo team, che preferisca gestire le chiavi di crittografia separatamente in ogni ambiente oppure che più istanze distribuite, in modo che la responsabilizzazione delle chiavi di crittografia possa essere delegata ai team appropriati. Modifica l'esempio di codice Terraform secondo necessità per adattarlo al tuo modello operativo.

Facoltativamente, puoi applicare i criteri dell'organizzazione relativi alle chiavi di crittografia gestite dal cliente (CMEK) per fare in modo che determinati tipi di risorse richiedano sempre una chiave CMEK e che possano essere utilizzate solo le 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 Accessore dei 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.

Quando possibile, devi generare automaticamente secret di produzione all'interno delle pipeline CI/CD e mantenerli inaccessibili agli utenti umani, ad eccezione di casi di deployment di emergenza. In questo scenario, assicurati di non concedere ruoli IAM per visualizzare questi secret ad alcun utente o gruppo.

Il progetto fornisce un singolo progetto prj-c-secrets nella cartella comune e un progetto prj-{env}-secrets in ogni cartella dell'ambiente per la gestione centralizzata dei secret. 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 tuo modello operativo, potresti preferire un'unica istanza centralizzata di Secret Manager sotto il controllo di un singolo team oppure gestire i secret separatamente in ogni ambiente oppure potresti preferire più istanze distribuite di Secret Manager in modo che ogni team dei carichi di lavoro possa gestire i propri secret. Modifica l'esempio di codice Terraform in base alle esigenze del tuo modello operativo.

Pianifica l'accesso per il deployment di emergenza ad 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 accesso privilegiato per modificare direttamente il tuo ambiente. Ti consigliamo di pianificare account di emergenza (a volte chiamati account Firecall o account di emergenza) che abbiano accesso con privilegi elevati al tuo ambiente in caso di emergenza o quando i processi di automazione si interrompono.

La tabella seguente descrive alcuni scopi di esempio degli account per deployment di emergenza.

Scopo del deployment di emergenza	Descrizione
Super amministratore	Accesso di emergenza al ruolo Super amministratore utilizzato con Cloud Identity, per risolvere, ad esempio, 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ò 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 interruzione dell'automazione della pipeline di base.
Operations o SRE	Un team Operations o SRE ha bisogno di accesso privilegiato per rispondere a interruzioni o incidenti. Ciò può includere attività come il riavvio delle VM o il ripristino dei dati.

Il meccanismo per consentire l'accesso di deployment di emergenza dipende dagli strumenti e dalle procedure esistenti, ma alcuni meccanismi di esempio 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 con privilegi elevati o utilizza le credenziali di un account con privilegi elevati.
Account di provisioning preliminare destinati esclusivamente all'utilizzo da parte degli amministratori. Ad esempio, lo sviluppatore Dana potrebbe avere un'identità dana@example.com per l'uso quotidiano e admin-dana@example.com per l'accesso al deployment di emergenza.
Utilizza un'applicazione come l'accesso con privilegi just-in-time, che consente a uno sviluppatore di passare a ruoli con più privilegi.

Indipendentemente dal meccanismo utilizzato, valuta come rispondere a livello operativo alle seguenti domande:

Come si progetta l'ambito e la granularità dell'accesso del deployment di emergenza? Ad esempio, potresti progettare un meccanismo di deployment di emergenza diverso per unità aziendali diverse, al fine di garantire che non possano interferire a vicenda.
In che modo il tuo meccanismo impedisce i comportamenti illeciti? Hai bisogno di approvazioni? Ad esempio, potresti avere operazioni suddivise in cui una persona conserva le credenziali e una persona detiene il token MFA.
Come si eseguono controlli e avvisi relativi all'accesso di deployment di emergenza? Ad esempio, potresti configurare un modulo Event Threat Detection personalizzato 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 le normali operazioni al termine dell'incidente?

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

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

Passaggi successivi

Leggi Deployment del progetto (prossimo documento di questa serie).