Best practice per le operazioni

Last reviewed 2025-05-15 UTC

Questa sezione introduce le operazioni da considerare durante il deployment e l'utilizzo di carichi di lavoro aggiuntivi nell'ambiente Google Cloud . Questa sezione non ha lo scopo di essere esaustiva di tutte le operazioni nel tuo ambiente cloud, ma introduce decisioni relative ai consigli e alle risorse architetturali di cui è stato eseguito il deployment dal blueprint.

Aggiornare le risorse di base

Sebbene il blueprint fornisca un punto di partenza basato su opinioni 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 da utilizzare in tutti i workload.

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

Decidere gli attributi per i nuovi progetti di workload

Quando crei nuovi progetti tramite il modulo di fabbrica dei progetti della pipeline di automazione, devi configurare vari attributi. Il processo di progettazione e creazione di progetti per nuovi workload deve includere decisioni per 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
  • Quale account di fatturazione utilizzare
  • Se aggiungere il progetto a un perimetro dei Controlli di servizio VPC
  • Se configurare una soglia di budget e avviso di fatturazione per il progetto

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

Gestire le autorizzazioni su larga scala

Quando esegui il deployment dei progetti di workload sopra la tua base, devi considerare come concedere l'accesso agli sviluppatori e ai consumatori previsti di questi progetti. Ti consigliamo di aggiungere gli utenti a un gruppo gestito dal tuo provider 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 IAM Recommender per identificare le policy di autorizzazione che concedono ruoli con privilegi eccessivi. Progetta una procedura per rivedere periodicamente i consigli o applicarli automaticamente alle pipeline di deployment.

Coordinare le modifiche tra il team di networking e il team dell'applicazione

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 implementano l'infrastruttura, devono creare regole firewall per consentire i percorsi di accesso previsti tra i componenti del workload, ma non hanno l'autorizzazione per modificare le policy firewall di rete.

Pianifica il modo in cui i team collaboreranno 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 workload richiede tag per le proprie applicazioni. Il team di networking crea quindi i tag e aggiunge regole alla policy firewall di rete che consentono il flusso di traffico tra le risorse con i tag e delega i ruoli IAM per utilizzare i tag al team dei workload.

Ottimizza il tuo ambiente con il portafoglio Active Assist

Oltre al motore per suggerimenti IAM, Google Cloud fornisce il portafoglio di servizi Active Assist per formulare suggerimenti su come ottimizzare il tuo ambiente. Ad esempio, gli approfondimenti sul firewall o il motore per suggerimenti per i progetti incustoditi forniscono consigli pratici 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 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.

Concedere eccezioni ai criteri dell'organizzazione

Il blueprint applica un insieme di vincoli delle policy dell'organizzazione consigliati alla maggior parte dei clienti nella maggior parte degli scenari, ma potresti avere casi d'uso legittimi che richiedono eccezioni limitate alle policy dell'organizzazione che applichi in modo generale.

Ad esempio, il blueprint applica il vincolo iam.disableServiceAccountKeyCreation. Questo vincolo è un importante controllo di sicurezza perché una chiave del account di servizio compromessa può avere un impatto negativo significativo e la maggior parte degli scenari dovrebbe utilizzare alternative più sicure alle account di servizio account per l'autenticazione. Tuttavia, potrebbero esistere casi d'uso che possono essere autenticati solo con una chiave del account di servizio, ad esempio un server on-premise che richiede l'accesso ai serviziGoogle Cloud e non può utilizzare la federazione delle identità per i workload. In questo scenario, potresti decidere di consentire un'eccezione alla policy, a condizione che vengano applicati controlli compensativi aggiuntivi, come le best practice per la gestione delle chiavi dei service account.

Pertanto, devi progettare una procedura per consentire ai workload di richiedere un'eccezione alle norme e assicurarti che i responsabili delle decisioni che hanno il compito di concedere le eccezioni dispongano delle conoscenze tecniche per convalidare il caso d'uso e fornire consulenza in merito alla necessità di implementare controlli aggiuntivi per compensare. Quando concedi un'eccezione a un workload, modifica il vincolo dei criteri dell'organizzazione nel modo più restrittivo possibile. Puoi anche aggiungere vincoli in modo condizionale a una policy dell'organizzazione definendo un tag che concede un'eccezione o l'applicazione della policy, quindi applicando il tag a progetti e cartelle.

Proteggi le risorse con i Controlli di servizio VPC

Il blueprint consente di preparare l'ambiente per i Controlli di servizio VPC applicando configurazioni prerequisito come il VIP con limitazioni. Tuttavia, il blueprint inizialmente esegue il deployment dei Controlli di servizio VPC solo in modalità dry run perché il passaggio alla modalità applicata può essere un processo di interruzione che richiede una pianificazione specifica per la tua organizzazione.

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

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 ha lo scopo di sostituire o duplicare i criteri di autorizzazione per il controllo dell'accesso granulare a singoli progetti o risorse. Quando progetti e crei 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 di servizio all'interno della tua Google Cloud organizzazione, 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:

Dopo aver modificato il perimetro dalla modalità dry run a quella applicata, ti consigliamo di progettare una procedura per aggiungere in modo coerente nuovi progetti al perimetro corretto e una procedura per progettare eccezioni quando gli sviluppatori hanno un nuovo caso d'uso negato dalla configurazione del perimetro corrente.

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 workload, 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 provider di identità e Cloud Identity, valuta la possibilità di creare un'organizzazione separata per i test.

Controllare l'accesso remoto alle macchine virtuali

Poiché ti 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 gli scenari che richiedono l'accesso remoto, ti consigliamo di gestire l'accesso degli utenti utilizzando OS Login, se possibile. Questo approccio utilizza servizi Google Cloud gestiti per applicare controllo dell'accesso dell'accesso, la gestione del ciclo di vita dell'account, la verifica in due passaggi e la registrazione degli audit. 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 qualsiasi scenario, un utente con accesso SSH o RDP a una VM può rappresentare un rischio di escalation dei privilegi, pertanto devi progettare il tuo modello di accesso tenendo presente questo aspetto. L'utente può eseguire codice sulla VM con i privilegi del service account associato o interrogare il 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 hai intenzionalmente voluto che l'utente operasse con i privilegi del account di servizio.

Ridurre la spesa eccessiva pianificando gli avvisi relativi al budget

Il progetto implementa le best practice introdotte in Google Cloud Well-Architected Framework: Cost Optimization per la gestione dei costi, tra cui:

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

  • Assegna a ogni progetto un'etichetta di metadati billingcode utilizzata per distribuire 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 del workload quando si prevede che la spesa raggiungerà il 120% del budget. Questo approccio consente a un team centrale di identificare e mitigare gli incidenti di spesa eccessiva significativa. Aumenti imprevisti e significativi della spesa senza una causa chiara possono essere un indicatore di un incidente di sicurezza e devono essere esaminati 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 dell'ambiente o di 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 monitoraggio quotidiano.

Per indicazioni sull'ottimizzazione dei costi, consulta Ottimizzare i costi con l'hub FinOps.

Allocare i costi tra i centri di costo interni

La console ti consente di visualizzare i report sulla 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 i costi in base a dimensioni personalizzate, come i tuoi centri di costo interni, in base ai metadati delle etichette del progetto, ad esempio 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, consulta 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 tuo SIEM esistente

Sebbene le risorse di base ti aiutino a configurare le destinazioni aggregate per i log di controllo e i risultati di sicurezza, è tua responsabilità decidere come utilizzare questi indicatori.

Se devi aggregare i log in tutti gli ambienti cloud e on-premise in un SIEM esistente, decidi come importare i log dal progetto prj-c-logging e i risultati di Security Command Center negli strumenti e nei processi esistenti. Puoi creare una singola esportazione per tutti i log e i risultati se un unico team è responsabile del monitoraggio della sicurezza in tutto l'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 Google Cloud solo inGoogle Cloud. In questo scenario, assicurati che i team esistenti dispongano dell'accesso e della formazione giusti per lavorare con log e risultati direttamente inGoogle Cloud.

  • Per gli audit log, progetta viste dei 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, il che aumenta il costo di archiviazione dei log.
  • Per i risultati di sicurezza, concedi ruoli a livello di cartella e progetto per consentire ai team di visualizzare e gestire i risultati di sicurezza solo per i progetti di cui sono responsabili, direttamente nella console.

Sviluppa continuamente la tua raccolta di controlli

Il progetto inizia con una base di controlli per rilevare e prevenire le minacce. Ti consigliamo di esaminare questi controlli e di aggiungerne altri in base ai tuoi requisiti. La seguente tabella riassume i meccanismi per applicare le policy 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 da più fonti di sicurezza.

Definisci moduli personalizzati per Security Health Analytics e moduli personalizzati per Event Threat Detection.

Il servizio Policy dell'organizzazione applica un insieme consigliato di vincoli dei criteri dell'organizzazione ai serviziGoogle Cloud .

Applica vincoli aggiuntivi dall'elenco predefinito di vincoli disponibili o crea vincoli personalizzati.

La policy Open Policy Agent (OPA) convalida il codice nella pipeline di base per configurazioni accettabili prima del deployment.

Sviluppa ulteriori vincoli in base alle indicazioni riportate in GoogleCloudPlatform/policy-library.

Avvisi su metriche basate su log e metriche di rendimento configura le metriche basate su log in modo che generino avvisi in caso di modifiche alle policy IAM e alle configurazioni di alcune risorse sensibili.

Progetta metriche basate su log e criteri di avviso aggiuntivi per gli eventi di log che prevedi 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 Analisi dei log di sicurezza come riferimento.

Una soluzione personalizzata per rispondere alle modifiche degli 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 particolari tipi di asset e scrivere funzioni Cloud Run aggiuntive con logica personalizzata per rispondere alle violazioni delle norme.

Questi controlli potrebbero evolversi man mano che cambiano i tuoi requisiti e la tua maturità in merito a Google Cloud .

Gestire le chiavi di crittografia con Cloud Key Management Service

Google Cloud fornisce la crittografia predefinita dei dati inattivi 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 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 saperne di più, consulta la sezione 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 di ambiente per gestire centralmente le 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, al fine di soddisfare i requisiti normativi e di conformità.

A seconda del modello operativo, potresti preferire una singola istanza di progetto centralizzata di Cloud KMS sotto il controllo di un unico team, potresti preferire gestire le chiavi di crittografia separatamente in ogni ambiente o potresti preferire più istanze distribuite in modo che la responsabilità delle chiavi di crittografia possa essere delegata ai team appropriati. Modifica il esempio di codice di Terraform in base alle tue esigenze per adattarlo al tuo modello operativo.

Se vuoi, puoi applicare policy dell'organizzazione per le 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 chiavi CMEK provenienti da un elenco consentito 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 Secret Manager Secret Accessor all'utente o al account di servizio che deve accedere al secret. Ti consigliamo di concedere il ruolo IAM a un singolo secret, non a tutti i secret del progetto.

Quando 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 utenti o gruppi.

Il blueprint fornisce un singolo progetto prj-c-secrets nella cartella comune e un progetto prj-{env}-secrets in ogni cartella di 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 una singola istanza centralizzata di Secret Manager sotto il controllo di un unico team oppure potresti preferire gestire i secret separatamente in ogni ambiente o più istanze distribuite di Secret Manager in modo che ogni team di workload possa gestire i propri secret. Modifica il campione di codice Terraform in base alle tue esigenze per adattarlo al tuo modello operativo.

Pianifica l'accesso di emergenza agli account con privilegi elevati

Sebbene consigliamo di gestire le modifiche alle risorse di base tramite l'infrastruttura come codice (IaC) con controllo delle versioni distribuita dalla pipeline di base, potresti trovarti in scenari eccezionali o di emergenza che richiedono l'accesso con privilegi per modificare direttamente il tuo ambiente. Ti consigliamo di pianificare account di emergenza (a volte chiamati account di emergenza) con accesso altamente privilegiato 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 di emergenza.

Scopo del deployment di emergenza Descrizione

Super amministratore

Accesso di emergenza al ruolo Super amministratore utilizzato con Cloud Identity, ad esempio per risolvere 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 dell'organizzazione.

Amministratore della pipeline di base

Accesso di emergenza per modificare le risorse nel progetto CICD suGoogle Cloud e nel repository Git esterno nel caso in cui l'automazione della pipeline di base non funzioni.

Operazioni o SRE

Un team di operazioni o SRE ha bisogno dell'accesso con privilegi 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 emergenza dipende dagli strumenti e dalle procedure esistenti, ma alcuni esempi 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.
  • Esegui il provisioning preliminare degli account 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 l'escalation automatica a ruoli con più privilegi.

Indipendentemente dal meccanismo utilizzato, valuta come rispondere operativamente alle seguenti domande:

  • Come si progettano l'ambito e la granularità dell'accesso di emergenza? Ad esempio, potresti progettare un meccanismo di breakglass diverso per le diverse unità aziendali per assicurarti che non possano interrompersi a vicenda.
  • In che modo il tuo meccanismo previene gli abusi? Richiedi approvazioni? Ad esempio, potresti avere operazioni suddivise in cui una persona detiene le credenziali e una persona detiene il token MFA.
  • In che modo esegui l'audit e invii avvisi in caso di accesso di emergenza? Ad esempio, potresti configurare un modulo personalizzato di Event Threat Detection per creare un risultato di sicurezza quando viene utilizzato un account di emergenza predefinito.
  • Come si rimuove l'accesso di emergenza e si riprendono le normali operazioni dopo la fine dell'incidente?

Per le attività comuni di escalation dei privilegi e il rollback delle modifiche, ti 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ò contribuire a ridurre l'errore umano e 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 alla produzione utilizzando l'automazione, i proxy sicuri o il breakglass sottoposto a audit. Google fornisce i libri sulla SRE per i clienti che vogliono adottare l'approccio SRE di Google.

Passaggi successivi