Best practice per le operazioni

Last reviewed 2023-12-20 UTC

Questa sezione introduce le operazioni che devi prendere in considerazione durante il deployment per gestire carichi di lavoro aggiuntivi nel tuo ambiente Google Cloud. Questa sezione non è da considerarsi esaustivo di tutte le operazioni eseguite nel tuo ambiente cloud, introduce decisioni relative ai suggerimenti e alle risorse relativi all'architettura di cui è stato eseguito il deployment dal progetto.

Aggiorna le risorse di base

Sebbene il progetto fornisca un valido punto di partenza per la creazione dell'ambiente, i tuoi requisiti di base potrebbero crescere nel tempo. Dopo del deployment iniziale, puoi regolare le impostazioni di configurazione o creare nuovi utilizzabili da tutti i carichi di lavoro.

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

Decidi gli attributi per i nuovi progetti dei carichi di lavoro

Durante la creazione di nuovi progetti tramite il modulo Project Fab dell'automazione devi configurare vari attributi. Il processo di progettazione creare progetti per i nuovi carichi di lavoro devono includere decisioni su 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 da la 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, vedi 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 del carico di lavoro sugli elementi di base, devi considerare le modalità con cui concederai l'accesso agli sviluppatori e ai consumatori che in modo programmatico a gestire i progetti. Ti consigliamo di aggiungere utenti in un gruppo gestito dalla tua il provider di identità, sincronizza i gruppi con Cloud Identity e applica 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 consigli o applicarli automaticamente delle tue 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 responsabili della gestione delle risorse di rete e team separati responsabili il deployment delle risorse dell'infrastruttura dei carichi di lavoro. Quando i team dei carichi di lavoro eseguono il deployment nell'infrastruttura, devono creare regole firewall per consentire tra i componenti del carico di lavoro, ma non hanno l'autorizzazione necessaria per modificare i criteri firewall di rete stessi.

Pianificare la collaborazione tra i team per coordinare le modifiche alla e le risorse di networking necessarie per il deployment delle applicazioni. Ad esempio, Progettare un processo in cui un team del carico di lavoro richiede tag per diverse applicazioni. Il team di networking crea quindi i tag e aggiunge regole criterio firewall di rete che consente il flusso del traffico tra le risorse con e delega i ruoli IAM per l'utilizzo dei tag alla del carico di lavoro.

Ottimizza il tuo ambiente con la gamma Active Assist

Oltre al motore per suggerimenti IAM, Google Cloud fornisce Assistente attivo di servizi per dare suggerimenti su come ottimizzare completamente gestito di Google Cloud. Ad esempio, approfondimenti firewall o il motore per suggerimenti di progetti inattivi fornire suggerimenti attuabili che possono aiutarti a rafforzare la tua strategia di sicurezza.

Progetta una procedura per rivedere periodicamente i consigli o applicarli automaticamente i tuoi suggerimenti nelle pipeline di deployment. Decidere quali consigli deve essere gestita da un team centrale e dovrebbe essere responsabilità del proprietari dei carichi di lavoro e applicare ruoli IAM per accedere ai suggerimenti di conseguenza.

Concedi eccezioni ai criteri dell'organizzazione

Il progetto applica un insieme di vincoli dei criteri dell'organizzazione consigliato alla maggior parte dei clienti, ma potresti avere che richiedono eccezioni limitate ai criteri dell'organizzazione che hai applicazioni su larga scala.

Ad esempio, il progetto applica il vincolo iam.disableServiceAccountKeyCreation. Questo vincolo è un importante controllo di sicurezza perché un servizio è trapelato chiave dell'account può avere un impatto negativo significativo e la maggior parte degli scenari dovrebbe usare alternative più sicure alle chiavi degli account di servizio per: autenticarsi. Tuttavia, potrebbero esserci casi d'uso in cui è possibile eseguire l'autenticazione solo con chiave dell'account di servizio, ad esempio un server on-premise che richiede l'accesso Google Cloud e non possono utilizzare la federazione delle identità per i carichi di lavoro. In questo scenario, puoi decidere di consentire un'eccezione alle norme, a condizione che Controlli di compensazione aggiuntivi come le best practice per la gestione delle chiavi degli account di servizio in modo forzato.

Devi quindi progettare un processo che consenta ai carichi di lavoro di richiedere un'eccezione e garantire che i responsabili delle decisioni responsabili di concedere le eccezioni hanno le conoscenze tecniche necessarie per convalidare il caso d'uso e consultare sia necessario implementare controlli aggiuntivi per compensare il problema. Quando concedi un a un carico di lavoro, modifica il vincolo del criterio dell'organizzazione il più possibile. Puoi anche aggiungere vincoli a un criterio dell'organizzazione in modo condizionale definendo un tag che concede un'eccezione o un'applicazione per le norme, 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 con restrizioni. Tuttavia, per impostazione predefinita, il codice Terraform non abilita Controlli di servizio VPC perché questa abilitazione può potrebbe essere un processo dirompente.

Un perimetro nega l'accesso ai servizi Google Cloud con restrizioni dal traffico che ha origine al di fuori del perimetro, che include console, workstation 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 che vuoi.

Un perimetro dei Controlli di servizio VPC è destinato ai controlli di esfiltrazione tra l'organizzazione Google Cloud e fonti esterne. Il perimetro non è destinata a sostituire o duplicare i criteri di autorizzazione per un accesso granulare controllo a livello di singoli progetti o risorse. Quando progetti e progetti un perimetro, 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 le minacce affrontate da una struttura perimetrale più complessa; i percorsi di accesso tra i perimetri necessari per le operazioni previste.

Per adottare i Controlli di servizio VPC, valuta quanto segue:

Una volta abilitato 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 negato dal tuo attuale caso d'uso 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 per risorse dei carichi di lavoro, questo approccio è facilitato da ambienti separati di sviluppo, non di produzione e di produzione. Tuttavia, alcune risorse organizzazione non dispone di ambienti separati per facilitare i test.

Per le modifiche a livello di organizzazione o per altre modifiche che possono interessare in ambienti di produzione come la configurazione e Cloud Identity, valuta la possibilità di creare un'organizzazione separata per i test scopi.

Controlla l'accesso remoto alle macchine virtuali

Poiché consigliamo di eseguire il deployment dell'infrastruttura immutabile tramite pipeline di base, dell'infrastruttura e dell'applicazione, è consigliabile concedere agli sviluppatori solo l'accesso diretto mediante SSH o RDP per casi d'uso limitati o eccezionali.

Per scenari che richiedono l'accesso remoto, ti consigliamo di gestire gli utenti utilizzando OS Login, dove possibile. Questo approccio utilizza i servizi Google Cloud gestiti per applicare controllo dell'accesso, gestione del ciclo di vita degli account, verifica in due passaggi e audit log. In alternativa, se devi consentire l'accesso tramite le chiavi SSH nei metadati o credenziali RDP, è tua responsabilità gestire il ciclo di vita delle credenziali e archiviare al sicuro all'esterno di Google Cloud.

In qualsiasi scenario, un utente con accesso SSH o RDP a una VM può essere un privilegio e il rischio di escalation, per cui dovresti progettare il modello di accesso tenendo presente questo aspetto. La l'utente può eseguire il codice su quella VM con i privilegi del servizio associato account o eseguire una query sul server metadati per visualizzare il token di accesso utilizzato per autenticare le richieste API. Questo accesso può quindi un'escalation dei privilegi se non intendevi deliberatamente che l'utente operare 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. La il progetto crea avvisi relativi al budget per il carico di lavoro progetti in cui la spesa prevista è in procinto di raggiungere il 120% del budget. Questo consente a un team centrale di identificare e mitigare spesa in eccesso. Aumenti significativi inaspettati della spesa senza una causa chiara può essere un indicatore di un incidente di sicurezza e deve essere esaminato dal 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 l'intera cartella dell'ambiente o 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 definire un livello più granulare soglia di avviso per il monitoraggio quotidiano.

Per indicazioni sullo sviluppo di funzionalità FinOps, inclusa la previsione dei budget per vedi Introduzione a FinOps su Google Cloud.

Allocare i costi tra i centri di costo interni

La console ti consente di visualizzare i report sulla fatturazione per vedere e prevedere il costo in più dimensioni. Oltre ai report predefiniti, di esportare i dati di fatturazione in un set di dati BigQuery Progetto prj-c-billing-export. I record di fatturazione esportati consentono di allocare costo su dimensioni personalizzate, ad esempio i centri di costo interni, in base al progetto metadati di etichetta come billingcode.

La seguente query SQL è una query di esempio per comprendere i costi di tutti i progetti raggruppate 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, la responsabilità di incorporare i dati ottenuti da questa query i processi interni di Google.

Importa i risultati dei controlli di rilevamento nel SIEM esistente

Sebbene le risorse di base consentano di configurare destinazioni aggregate log di controllo e risultati sulla sicurezza, è tua responsabilità decidere come consumare e utilizzare questi indicatori.

Se hai la necessità di aggregare i log su tutto il cloud e on-premise in un SIEM esistente, decidi come importare i log Progetto prj-c-logging e risultati di Security Command Center negli strumenti esistenti e processi. Potresti creare un'unica esportazione per tutti i log e i risultati se Il singolo team è responsabile del monitoraggio della sicurezza in tutta oppure creare più esportazioni filtrate in base all'insieme di log e i risultati necessari per più team con responsabilità diverse.

In alternativa, se il volume dei log e i costi sono proibitivi, potresti evitare duplicazione conservando i log e i risultati di Google Cloud solo in in Google Cloud. In questo scenario, assicurati che i team esistenti dispongano l'accesso adeguato e la formazione per lavorare con log e risultati direttamente in Google Cloud.

  • Per gli audit log, progetta le visualizzazioni dei log da concedere l'accesso a un sottoinsieme di log nel bucket dei log centralizzati a singole i team, invece di duplicare i log in più bucket, dei costi di archiviazione.
  • Per risultati sulla sicurezza, concedi ruoli a livello di cartella e di progetto di Security Command Center per consentire ai team di visualizzare e gestire i risultati sulla sicurezza solo ai 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 di aggiungerne altri in base i tuoi requisiti. La tabella seguente riassume i meccanismi per applicare criteri 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 varie soluzioni di di origine.

Definisci le opzioni personalizzate moduli per Security Health Analytics e 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 delle disponibili vincoli o crea vincoli personalizzati.

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

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

Avvisi su metriche basate su log e metriche sulle prestazioni configura le metriche basate su log per creare avvisi in caso di modifiche a IAM i criteri e le configurazioni di alcune risorse sensibili.

Progetta metriche e criteri di avviso aggiuntivi basati su log per gli eventi dei log che prevedi non devono verificarsi in del tuo ambiente.

Una soluzione personalizzata per i log automatizzati di analisi esegue regolarmente delle query nei log per rilevare attività sospette e crea Risultati di Security Command Center.

Scrivi altre query per creare risultati per gli eventi di sicurezza che vuoi da monitorare, usando analisi dei log come riferimento.

Una soluzione personalizzata per modifiche agli asset crea risultati di Security Command Center e può automatizzare la correzione azioni.

Creare feed aggiuntivi di Cloud Asset Inventory per monitorare modifiche per particolari tipi di asset e scrivere funzioni Cloud Functions aggiuntive con logica personalizzata alle violazioni delle norme.

Questi controlli possono evolversi man mano che i tuoi requisiti e la maturità modifica in Google Cloud.

Gestisci le chiavi di crittografia con Cloud Key Management Service

Google Cloud fornisce la crittografia predefinita riposa per 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 at-rest. Me ti consigliamo di valutare se la crittografia predefinita è sufficiente oppure se hai un requisito di conformità che prevede l'uso di Cloud KMS per gestire autonomamente le chiavi. 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 prj-{env}-kms progetto in ogni cartella di ambiente per la gestione delle chiavi di crittografia a livello centrale. Questo approccio consente a un team centralizzato di controllare e gestire le chiavi di crittografia utilizzate dalle risorse nei progetti dei carichi di lavoro, per soddisfare le normative di conformità.

A seconda del modello operativo, potresti preferire un'unica soluzione di Cloud KMS sotto il controllo di un singolo team, potrebbe preferire gestire le chiavi di crittografia separatamente in ogni ambiente oppure potrebbero preferire più istanze distribuite in modo che le chiavi di crittografia possono essere delegate ai team appropriati. Modifica il modulo dell'esempio di codice in base alle esigenze per adattarlo al tuo modello operativo.

Facoltativamente, puoi applicare i criteri dell'organizzazione delle chiavi di crittografia gestite dal cliente (CMEK) per imporre che determinati tipi di risorse richiedano sempre una chiave CMEK e che solo CMEK è possibile usare chiavi 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, ad esempio chiavi API, password e certificati privati) ai repository di codice sorgente. Invece, esegui il commit del secret Secret Manager e concedi la funzione di accesso ai secret di Secret Manager ruolo IAM per l'account utente o di servizio che deve accedere al secret. Me di concedere il ruolo IAM a un singolo secret, non a tutti i secret nel progetto.

Se possibile, dovresti generare automaticamente i secret di produzione all'interno pipeline CI/CD e mantienile inaccessibili agli utenti umani, tranne che nel deployment di emergenza in situazioni diverse. In questo scenario, assicurati di non concedere ruoli IAM per la visualizzazione a tutti gli utenti o gruppi.

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 dei secret a livello centrale. Questo approccio consente a un team centralizzato di controllare e gestire i secret utilizzati per soddisfare i requisiti normativi e di conformità.

A seconda del modello operativo, potresti preferire un'unica soluzione un'istanza di Secret Manager sotto il controllo di un singolo team, potresti preferire gestire i secret separatamente in ogni ambiente preferiscono più istanze distribuite di Secret Manager ogni team dei carichi di lavoro può gestire i propri secret. Modifica il codice Terraform campione necessario per adattarlo al modello operativo.

Pianificare l'accesso di emergenza agli account con privilegi elevati

Anche se consigliamo di gestire le modifiche alle risorse di base di un IaC con controllo delle versioni di cui viene eseguito il deployment dalla pipeline di base, potresti aver scenari eccezionali o di emergenza che richiedono un accesso privilegiato per dell'ambiente di rete. Ti consigliamo di pianificare gli account di deployment di emergenza (talvolta chiamati account di emergenza o chiamate antincendio) che dispongono di privilegi elevati al tuo ambiente in caso di emergenza o quando l'automazione vengono scomposti.

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 Super Amministratore utilizzato con Cloud Identity, per, ad esempio, correggere Problemi relativi alla federazione delle identità o all'autenticazione a più fattori autenticazione (MFA).

Amministratore dell'organizzazione

Accesso di emergenza all'organizzazione Amministratore, che potrà quindi concedere l'accesso a qualsiasi altro ruolo IAM nel dell'organizzazione.

Pipeline di base amministratore

Accesso di emergenza per modificare le risorse in progetto CICD attivato Google Cloud e il repository Git esterno nel caso in cui l'automazione la pipeline di base si suddivide.

Suite operativa o SRE

Un team operativo o SRE ha bisogno di un accesso privilegiato per rispondere alle interruzioni o incidenti. Possono essere incluse attività come il riavvio delle VM o il ripristino e i dati di Google Cloud.

Il meccanismo per consentire l'accesso del deployment di emergenza dipende dagli strumenti esistenti e delle procedure configurate, ma alcuni meccanismi esemplificativi includono i seguenti:

  • Utilizza gli strumenti esistenti per la gestione degli accessi privilegiati per aggiungere temporaneamente un l'utente a un gruppo predefinito con ruoli IAM con privilegi elevati oppure utilizza le credenziali di un account con privilegi elevati.
  • Account di pre-provisioning destinati esclusivamente all'utilizzo da parte degli amministratori. Ad esempio: la sviluppatrice Dana potrebbe avere l'identità dana@example.com per uso quotidiano e admin-dana@example.com per l'accesso del deployment di emergenza.
  • Utilizzare un'applicazione, come l'accesso privilegiato just-in-time che consente allo sviluppatore di riassegnare autonomamente i ruoli con maggiori privilegi.

Indipendentemente dal meccanismo utilizzato, considera il modo in cui gestisci operativamente le 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 evitare possibili interruzioni reciproche.
  • In che modo il tuo meccanismo previene gli abusi? Hai bisogno di approvazioni? Ad esempio: potresti avere operazioni di suddivisione in cui una persona contiene le credenziali e una persona in possesso del token MFA.
  • Come esegui il controllo e gli avvisi sull'accesso del deployment di emergenza? Ad esempio, configurare un modulo personalizzato Event Threat Detection per creare un risultato di sicurezza quando viene utilizzato un account di deployment di emergenza predefinito.
  • Come rimuovere l'accesso del deployment di emergenza e riprendere le normali operazioni dopo il l'incidente è finito?

Per le attività comuni di escalation dei privilegi e il rollback delle modifiche, è consigliabile progettando flussi di lavoro automatizzati in cui un utente possa eseguire l'operazione senza richiedere l'escalation dei privilegi per l'identità utente. Questo approccio può aiutare a ridurre errori umani 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 una produzione zero-touch per apportare tutte le modifiche alla produzione utilizzando automazione, proxy sicuri o deployment di emergenza controllati. Google offre i libri sulla SRE per i clienti che vogliono adottare l'approccio SRE di Google.

Passaggi successivi