Best practice per le operazioni

Last reviewed 2023-12-20 UTC

Questa sezione illustra le operazioni che devi prendere in considerazione durante il deployment e il funzionamento di carichi di lavoro aggiuntivi nel tuo ambiente Google Cloud. Questa sezione non è pensata per essere esaustiva di tutte le operazioni nel tuo ambiente cloud, ma introduce le decisioni relative ai consigli e alle risorse di architettura di cui è stato eseguito il deployment dal blueprint.

Aggiorna le risorse di base

Sebbene il blueprint fornisca un punto di partenza per l'ambiente di base, i requisiti di base potrebbero aumentare nel tempo. Dopo 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. Consulta la strategia di branching per un'introduzione al flusso di scrittura del codice, all'unione e all'attivazione delle pipeline di deployment.

Decidere gli attributi per i nuovi progetti di carichi di lavoro

Quando crei nuovi progetti tramite il modulo Project Factory della pipeline di automazione, devi configurare vari attributi. La procedura per progettare e creare progetti per nuovi carichi di lavoro deve includere decisioni relative a quanto segue:

  • Quali API Google Cloud abilitare
  • Quale VPC condiviso utilizzare o se creare una nuova rete VPC
  • Quali ruoli IAM creare per l'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
  • 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.

Gestire le autorizzazioni su larga scala

Quando esegui il deployment di progetti di carichi di lavoro sulla tua base, devi considerare come concederai l'accesso agli sviluppatori e ai consumatori previsti di questi progetti. Ti consigliamo di aggiungere 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 di workload eseguono il deployment dell'infrastruttura, devono creare regole firewall per consentire i percorsi di accesso previsti tra i componenti del loro workload, ma non hanno l'autorizzazione per modificare i criteri firewall di rete.

Pianifica in che modo i team lavoreranno insieme per coordinare le modifiche alle risorse di rete centralizzate necessarie per il deployment delle applicazioni. Ad esempio, 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 dei carichi di lavoro.

Ottimizza il tuo ambiente con la gamma Active Assist

Oltre al Recommender IAM, Google Cloud fornisce il portafoglio di servizi Active Assist per fornire suggerimenti su come ottimizzare il tuo ambiente. Ad esempio, 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. Decidi quali consigli devono essere gestiti da un team centrale e quali sono responsabilità dei proprietari dei carichi di lavoro, quindi applica i ruoli IAM per accedere ai consigli di conseguenza.

Concedi eccezioni ai criteri dell'organizzazione

Il blueprint applica un insieme 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 in modo generale.

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 che possono autenticarsi solo con una chiave dell'account di servizio, ad esempio un server on-premise che richiede l'accesso ai servizi Google Cloud e non può utilizzare la federazione delle identità per i carichi di lavoro. In questo scenario, puoi decidere di consentire un'eccezione al criterio, a condizione che controlli compensativi aggiuntivi come le best practice per la gestione delle chiavi degli account di servizio siano applicati.

Pertanto, devi progettare una procedura per i carichi di lavoro per richiedere un'eccezione ai criteri e assicurarti che i responsabili decisionali che sono responsabili della concessione delle eccezioni dispongano delle conoscenze tecniche per convalidare il caso d'uso e consultare se devono essere implementati controlli aggiuntivi per compensare. Quando concedi un'eccezione a un carico di lavoro, modifica il vincolo dei criteri dell'organizzazione nel modo più specifico possibile. Puoi anche aggiungere 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 blueprint ti aiuta a preparare il tuo ambiente per i Controlli di servizio VPC separando le reti di base e limitate. Tuttavia, per impostazione predefinita, il codice Terraform non abilita Controlli di servizio VPC perché questa abilitazione può potrebbe essere un processo dirompente.

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

Un perimetro di Controlli di servizio VPC è destinato ai controlli di esfiltrazione tra la tua organizzazione Google Cloud e le origini esterne. Il perimetro non è inteso a sostituire o duplicare i criteri di autorizzazione per il controllo granulare dell'accesso a singoli progetti o risorse. Quando progetti e 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 chiaramente le minacce affrontate da una struttura di perimetro più complessa e i percorsi di accesso tra i perimetri necessari per le operazioni previste.

Per adottare Controlli di servizio VPC, valuta quanto segue:

Dopo aver attivato il perimetro, ti consigliamo di progettare un processo per aggiungere costantemente nuovi progetti al perimetro corretto e un processo per progettare eccezioni quando gli sviluppatori hanno un nuovo caso d'uso 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 per lo sviluppo, non di produzione e di produzione. Tuttavia, alcune risorse dell'organizzazione non dispongono di ambienti separati per facilitare i test.

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

Controlla l'accesso remoto alle macchine virtuali

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

Per 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. L'utente può eseguire codice sulla VM con i privilegi dell'account di servizio associato o eseguire query sul server di metadati per visualizzare il token di accesso utilizzato per autenticare le richieste API. Questo accesso può quindi essere un'escalation dei privilegi se non avevi intenzionalmente previsto che l'utente potesse operare con i privilegi dell'account di servizio.

Riduci la spesa eccessiva pianificando avvisi sul budget

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

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

  • Assegna a ogni progetto un'billingcodeetichetta dei metadati che viene 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 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 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, puoi impostare un budget basato sul costo di un'intera cartella dell'ambiente o di tutti i progetti relativi a un determinato centro di costo, anziché impostare budget granulari per ogni progetto. Ti consigliamo inoltre di delegare l'impostazione del budget e degli avvisi ai proprietari dei carichi di lavoro, che potrebbero definire un livello più granulare per il monitoraggio giornaliero.

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

Allocare i costi tra i centri di costo interni

La console ti consente di visualizzare i report di fatturazione per visualizzare e prevedere i costi in più dimensioni. Oltre ai report predefiniti, ti consigliamo di esportare i dati di fatturazione in un set di dati BigQuery nel progetto prj-c-billing-export. I record di fatturazione esportati 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 è un esempio di query per comprendere i costi di tutti i progetti agrupati per etichetta di progetto billingcode.

#standardSQL
SELECT
   (SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
   service.description AS description,
   SUM(cost) AS charges,
   SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC

Per configurare questa esportazione, consulta Esportare i dati di fatturazione Cloud in BigQuery.

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

Importa i risultati dei controlli di rilevamento 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 devi aggregare i log di tutti gli ambienti cloud e on-premise in un SIEM esistente, decidi come importare i log del progetto prj-c-logging e i risultati di Security Command Center negli strumenti e nelle procedure esistenti. Puoi creare una singola esportazione per tutti i log e i risultati se un singolo team è responsabile del monitoraggio della sicurezza nell'intero ambiente oppure puoi creare più esportazioni filtrate in base all'insieme di log e risultati necessari per più team con responsabilità diverse.

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

  • Per gli audit log, progetta viste dei log per concedere ai singoli team l'accesso a un sottoinsieme di log nel bucket di log centralizzato, anziché duplicare i log in più bucket, il che aumenta il costo di archiviazione dei log.
  • Per i risultati sulla sicurezza, concedi ruoli a livello di cartella e di progetto per Security Command Center in modo che i team possano visualizzare e gestire i risultati sulla sicurezza solo per i progetti di cui sono responsabili, direttamente nella console.

Sviluppare continuamente la raccolta di controlli

Il blueprint inizia con una linea di base di controlli per rilevare e prevenire le minacce. Ti consigliamo di rivedere questi controlli e di aggiungerne altri in base alle tue esigenze. La seguente tabella riassume i meccanismi per applicare i criteri di governance e come estenderli per i tuoi requisiti aggiuntivi:

Controlli dei criteri applicati dal blueprint Indicazioni per estendere questi controlli

Security Command Center rileva vulnerabilità e minacce 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 verificare la presenza di 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 query aggiuntive per creare risultati per gli eventi di sicurezza che vuoi monitorare, utilizzando come riferimento l'analisi dei log di sicurezza.

Una soluzione personalizzata per rispondere alle modifiche delle risorse crea risultati di Security Command Center e può automatizzare le azioni di correzione.

Creare feed aggiuntivi di Cloud Asset Inventory per monitorare modifiche per particolari tipi di asset e scrivere funzioni Cloud Run 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 offre la crittografia predefinita dei dati inattivi per tutti i contenuti dei clienti, ma fornisce anche Cloud Key Management Service (Cloud KMS) per offrirti un maggiore controllo sulle chiavi di crittografia per i dati inattivi. Ti consigliamo di valutare se la crittografia predefinita è sufficiente o se hai un requisito di conformità che ti impone di utilizzare Cloud KMS per gestire autonomamente le chiavi. Per ulteriori informazioni, consulta Decidere come soddisfare i requisiti di conformità per la crittografia at-rest.

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

A seconda del modello operativo, potresti preferire un'unica 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. Ti consigliamo di concedere il ruolo IAM a un singolo segreto, non a tutti i segreti del 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 blueprint fornisce un singolo progetto prj-c-secrets nella cartella comune e un progetto prj-c-secrets in ogni cartella dell'ambiente per gestire i secret in modo centralizzato. Questo approccio consente a un team centrale di controllare e gestire i secret utilizzati dalle applicazioni per soddisfare i requisiti normativi e di conformità.

A seconda del modello operativo, potresti preferire un'unica 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 di esempio in base alle tue esigenze per adattarlo al tuo modello operativo.

Pianifica l'accesso di emergenza ad account con privilegi elevati

Sebbene consigliamo di gestire le modifiche alle risorse di base tramite IaC con controllo della versione di cui è stato eseguito il deployment dalla pipeline di base, potresti avere scenari eccezionali o di emergenza che richiedono l'accesso privilegiato per modificare direttamente il tuo ambiente. Ti consigliamo di pianificare 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.

La seguente tabella descrive alcuni esempi di finalità degli account 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.

Amministratore della pipeline fundamenta

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 con privilegi per aggiungere temporaneamente un utente a un gruppo predefinito con ruoli IAM ad alto privilegio o utilizza le credenziali di un account ad alto privilegio.
  • Account preconfigurati destinati solo all'utilizzo da parte dell'amministratore. Ad esempio: la sviluppatrice Dana potrebbe avere l'identità Daniela@example.com per l'uso quotidiano e admin-dana@example.com per l'accesso del deployment di emergenza.
  • Utilizza un'applicazione come l'accesso privilegiato just-in-time che consente a uno sviluppatore di eseguire la riassegnazione a ruoli più privilegiati.

Indipendentemente dal meccanismo utilizzato, 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 emergenza diverso per unità aziendali diverse per assicurarti che non possano interferire tra loro.
  • 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 controlli e avvisi sull'accesso di emergenza? Ad esempio, potresti configurare un modulo Event Threat Detection personalizzato per creare un rilevamento di sicurezza quando viene utilizzato un account di emergenza predefinito.
  • Come faccio a rimuovere l'accesso di emergenza e a riprendere le normali operazioni al termine dell'incidente?

Per le attività comuni di escalation dei privilegi e 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ò contribuire a ridurre gli 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