Esegui il deployment di un'architettura serverless sicura utilizzando Cloud Run

Last reviewed 2023-03-10 UTC

Questi contenuti sono stati aggiornati per l'ultima volta a marzo 2023 e rappresentano lo status quo al momento della redazione. I criteri e i sistemi di sicurezza di Google potranno variare in futuro, in virtù del costante miglioramento della protezione per i nostri clienti.

Le architetture serverless ti consentono di sviluppare software e servizi senza eseguire il provisioning o la manutenzione dei server. Puoi utilizzare le architetture serverless per creare applicazioni per un'ampia gamma di servizi.

Questo documento fornisce indicazioni utili per DevOps Engineer, Security Architect e sviluppatori di applicazioni su come proteggere le applicazioni serverless che utilizzano Cloud Run. Il documento fa parte di un progetto di sicurezza costituito da quanto segue:

Un repository GitHub che contiene un insieme di configurazioni e script Terraform.
Una guida all'architettura, alla progettazione e ai controlli di sicurezza che implementi con il progetto (questo documento).

Anche se puoi eseguire il deployment di questo blueprint senza prima eseguire il deployment del Google Cloud blueprint delle basi aziendali, questo documento presuppone che tu abbia già configurato un insieme di base di controlli di sicurezza, come descritto nel blueprint delle basi aziendali Google Cloud . L'architettura descritta in questo documento ti aiuta ad aggiungere controlli aggiuntivi alla tua base per proteggere le tue applicazioni serverless.

Per contribuire a definire i controlli di sicurezza chiave correlati alle applicazioni serverless, la Cloud Security Alliance (CSA) ha pubblicato 12 principali rischi critici per le applicazioni serverless. I controlli di sicurezza utilizzati in questo blueprint sono progettati per affrontare i rischi pertinenti ai vari casi d'uso descritti in questo documento.

Casi d'uso serverless

Il progetto supporta i seguenti casi d'uso:

Deployment di un'architettura serverless utilizzando Cloud Run (questo documento)
Deployment di un'architettura serverless utilizzando Cloud Run Functions

Le differenze tra Cloud Run Functions e Cloud Run includono quanto segue:

Le funzioni Cloud Run vengono attivate da eventi, ad esempio modifiche ai dati in un database o la ricezione di un messaggio da un sistema di messaggistica come Pub/Sub. Cloud Run viene attivato da richieste, ad esempio richieste HTTP.
Cloud Run Functions è limitato a un insieme di runtime supportati. Puoi utilizzare Cloud Run con qualsiasi linguaggio di programmazione.
Cloud Run Functions gestisce i container e l'infrastruttura che controllano il web server o il runtime del linguaggio, in modo che tu possa concentrarti sul codice. Cloud Run ti offre la flessibilità di eseguire autonomamente questi servizi, in modo da avere il controllo della configurazione del container.

Per saperne di più sulle differenze tra Cloud Run e Cloud Run Functions, consulta Scelta di un'opzione di calcolo. Google Cloud

Architettura

Questo blueprint ti consente di eseguire applicazioni serverless su Cloud Run con VPC condiviso. Ti consigliamo di utilizzare il VPC condiviso perché centralizza i criteri di rete e il controllo di tutte le risorse di rete. Inoltre, il VPC condiviso viene implementato nel blueprint di fondazione di un'azienda.

Architettura consigliata: Cloud Run con una rete VPC condivisa

L'immagine seguente mostra come puoi eseguire le tue applicazioni serverless in una rete VPC condivisa.

L'architettura per il progetto serverless.

L'architettura mostrata nel diagramma precedente utilizza una combinazione dei seguenti servizi e funzionalità: Google Cloud

Un bilanciatore del carico delle applicazioni esterno riceve da internet i dati richiesti dalle applicazioni serverless e li inoltra a Cloud Run. Il bilanciatore del carico delle applicazioni esterno è un bilanciatore del carico di livello 7.
Google Cloud Armor funge da web application firewall per proteggere le tue applicazioni serverless da attacchi denial of service (DoS) e web.
Cloud Run ti consente di eseguire il codice dell'applicazione nei container e gestisce l'infrastruttura per tuo conto. In questo progetto, l'impostazione in entrata Internal and Cloud Load Balancing limita l'accesso a Cloud Run in modo che Cloud Run accetti richieste solo dal bilanciatore del carico delle applicazioni esterno.
Il connettore di accesso VPC serverless connette la tua applicazione serverless alla tua rete VPC utilizzando l'accesso VPC serverless. L'accesso VPC serverless contribuisce a garantire che le richieste dalla tua applicazione serverless alla rete VPC non siano esposte a internet. L'accesso VPC serverless consente a Cloud Run di comunicare con altri servizi, sistemi di archiviazione e risorse che supportano i Controlli di servizio VPC.

Per impostazione predefinita, crei il connettore di accesso VPC serverless nel progetto di servizio. Puoi creare il connettore di accesso VPC serverless nel progetto host specificando true per la variabile di input connector_on_host_project quando esegui il modulo Secure Cloud Run Network. Per saperne di più, consulta Confronto tra i metodi di configurazione.
Le regole firewall di Virtual Private Cloud (VPC) controllano il flusso di dati nella subnet che ospita le tue risorse, ad esempio un server aziendale ospitato su Compute Engine o dati aziendali archiviati in Cloud Storage.
I Controlli di servizio VPC creano un perimetro di sicurezza che isola i servizi e le risorse Cloud Run configurando l'autorizzazione, i controlli dell'accesso e lo scambio sicuro di dati. Questo perimetro è progettato per proteggere i contenuti in entrata, isolare l'applicazione configurando controlli dell'accesso e monitoraggio aggiuntivi e separare la governance di Google Cloud dall'applicazione. La tua governance include la gestione delle chiavi e la registrazione.
La VPC condivisa ti consente di connettere il connettore di accesso VPC serverless nel tuo progetto di servizio al progetto host.
Cloud Key Management Service (Cloud KMS) archivia le chiavi di crittografia gestite dal cliente (CMEK) utilizzate dai servizi in questo progetto, tra cui l'applicazione serverless, Artifact Registry e Cloud Run.
Identity and Access Management (IAM) e Resource Manager consentono di limitare l'accesso e isolare le risorse. I controlli di accesso e la gerarchia delle risorse seguono il principio del privilegio minimo.

Architettura alternativa: Cloud Run senza una rete VPC condivisa

Se non utilizzi una rete VPC condivisa, puoi eseguire il deployment di Cloud Run e della tua applicazione serverless in un perimetro di controllo del servizio VPC senza una rete VPC condivisa. Potresti implementare questa architettura alternativa se utilizzi una topologia hub-and-spoke.

L'immagine seguente mostra come puoi eseguire le tue applicazioni serverless senza il VPC condiviso.

Un'architettura alternativa per il progetto serverless.

L'architettura mostrata nel diagramma precedente utilizza una combinazione di servizi e funzionalitàGoogle Cloud simili a quelli descritti nella sezione precedente, Architettura consigliata: Cloud Run con un VPC condiviso.

Struttura dell'organizzazione

Raggruppi le risorse in modo da poterle gestire e separare gli ambienti di sviluppo e test dall'ambiente di produzione. Resource Manager consente di raggruppare logicamente le risorse per progetto, cartella e organizzazione.

Il seguente diagramma mostra una gerarchia di risorse con cartelle che rappresentano diversi ambienti, ad esempio bootstrap, common, produzione, non di produzione (o test) e sviluppo. Questa gerarchia delle risorse si basa su quella descritta nel progetto di fondazione di un'azienda. Esegui il deployment dei progetti specificati dal progetto base nelle seguenti cartelle: Common, Production, Non-production e Dev.

La struttura organizzativa per il progetto serverless.

Le sezioni seguenti descrivono questo diagramma in modo più dettagliato.

Cartelle

Utilizzi le cartelle per isolare l'ambiente di produzione e i servizi di governance dagli ambienti di test e non di produzione. La seguente tabella descrive le cartelle del blueprint delle fondamenta dell'impresa utilizzate da questo blueprint.

Cartella	Descrizione
`Bootstrap`	Contiene le risorse necessarie per il deployment del blueprint delle fondamenta dell'impresa.
`Common`	Contiene servizi centralizzati per l'organizzazione, ad esempio il progetto di sicurezza.
`Production`	Contiene progetti con risorse cloud testate e pronte per l'uso da parte dei clienti. In questo blueprint, la cartella `Production` contiene il progetto di servizio e il progetto host.
`Non-production`	Contiene progetti con risorse cloud attualmente in fase di test e preparazione per il rilascio. In questo blueprint, la cartella `Non-production` contiene il progetto di servizio e il progetto host.
`Dev`	Contiene progetti con risorse cloud attualmente in fase di sviluppo. In questo blueprint, la cartella `Dev` contiene il progetto di servizio e il progetto host.

Puoi modificare i nomi di queste cartelle in modo che corrispondano alla struttura delle cartelle della tua organizzazione, ma ti consigliamo di mantenere una struttura simile. Per maggiori informazioni, consulta Struttura dell'organizzazione. Per altre strutture di cartelle, vedi Scegliere una gerarchia delle risorse per la tua Google Cloud landing zone.

Progetti

Isola le risorse nel tuo ambiente utilizzando i progetti. La tabella seguente descrive i progetti necessari all'interno dell'organizzazione. Puoi modificare i nomi di questi progetti, ma ti consigliamo di mantenere una struttura simile.

Progetto	Descrizione
Progetto host	Questo progetto include le regole in entrata del firewall e tutte le risorse che hanno indirizzi IP interni (come descritto in Connettersi a una rete VPC). Quando utilizzi un VPC condiviso, designi un progetto come progetto host, a cui colleghi uno o più altri progetti di servizio. Quando applichi il codice Terraform, specifichi il nome di questo progetto e il blueprint esegue il deployment dei servizi.
Progetto di servizio	Questo progetto include l'applicazione serverless, Cloud Run e il connettore di accesso VPC serverless. Collega il progetto di servizio al progetto host in modo che possa partecipare alla rete VPC condiviso. Quando applichi il codice Terraform, specifichi il nome di questo progetto. Il blueprint esegue il deployment di Cloud Run, Cloud Armor, del connettore di accesso VPC serverless e del bilanciamento del carico.
Progetto di sicurezza	Questo progetto include i tuoi servizi specifici per la sicurezza, come Cloud KMS e Secret Manager. Quando applichi il codice Terraform, specifichi il nome di questo progetto e il blueprint esegue il deployment di Cloud KMS. Se utilizzi il modulo Secure Cloud Run Harness, viene eseguito il deployment anche di Artifact Registry. Se esegui il deployment di questo blueprint dopo aver eseguito il deployment del blueprint delle basi di sicurezza, questo progetto è il progetto dei secret creato dal blueprint delle basi aziendali. Per saperne di più sui progetti del progetto della piattaforma di base per le aziende, consulta la sezione Progetti. Se esegui il deployment di più istanze di questo blueprint senza il blueprint delle fondamenta aziendali, ogni istanza ha il proprio progetto di sicurezza.

Mappatura di ruoli e gruppi ai progetti

Devi concedere a diversi gruppi di utenti della tua organizzazione l'accesso ai progetti che compongono l'architettura serverless. La tabella seguente descrive i consigli per i gruppi di utenti e l'assegnazione dei ruoli nei progetti che crei. Puoi personalizzare i gruppi in modo che corrispondano alla struttura esistente della tua organizzazione, ma ti consigliamo di mantenere una separazione simile dei compiti e dell'assegnazione dei ruoli.

Gruppo	Progetto	Ruoli
Amministratore serverless grp-gcp-serverless-admin@example.com	Progetto di servizio	`roles/run.admin` `roles/compute.networkViewer` `compute.networkUser`
Amministratore della sicurezza serverless grp-gcp-serverless-security-admin@example.com	Progetto di sicurezza	`roles/run.viewer` `roles/cloudkms.viewer` `roles/artifactregistry.reader`
Sviluppatore Cloud Run grp-gcp-secure-cloud-run-developer@example.com	Progetto di sicurezza	`roles/run.developer` `roles/artifactregistry.writer` `roles/cloudkms.cryptoKeyEncrypter`
Utente Cloud Run grp-gcp-secure-cloud-run-user@example.com	Progetto di servizio	`roles/run.invoker`

Controlli di sicurezza

Questa sezione descrive i controlli di sicurezza in Google Cloud che utilizzi per proteggere l'architettura serverless. I principi di sicurezza fondamentali da considerare sono i seguenti:

Accesso sicuro in base al principio del privilegio minimo, che concede alle entità solo i privilegi necessari per svolgere le proprie attività.
Proteggi le connessioni di rete tramite la progettazione della segmentazione, le policy dell'organizzazione e le policy firewall.
Configurazione sicura per ciascun servizio.
Comprendi i livelli di rischio e i requisiti di sicurezza per l'ambiente che ospita i tuoi carichi di lavoro serverless.
Configura monitoraggio e logging sufficienti per consentire il rilevamento, l'investigazione e la risposta.

Controlli di sicurezza per applicazioni serverless

Puoi contribuire a proteggere le tue applicazioni serverless utilizzando controlli che proteggono il traffico sulla rete, controllano l'accesso e criptano i dati.

Controlli del sistema di compilazione

Quando esegui il deployment dell'applicazione serverless, utilizzi Artifact Registry per archiviare le immagini container e i file binari. Artifact Registry supporta CMEK, in modo che tu possa criptare il repository utilizzando le tue chiavi di crittografia.

Traffico SSL

Per supportare il traffico HTTPS verso la tua applicazione serverless, configura un certificato SSL per il tuo bilanciatore del carico delle applicazioni esterno. Per impostazione predefinita, utilizzi un certificato autofirmato che puoi sostituire con un certificato gestito dopo aver applicato il codice Terraform. Per saperne di più sull'installazione e l'utilizzo dei certificati gestiti, consulta Utilizzo di certificati SSL gestiti da Google.

Regole di rete e firewall

Le regole firewall VPC (Virtual Private Cloud) controllano il flusso di dati nei perimetri. Crea regole firewall che negano tutto il traffico in uscita, ad eccezione di connessioni specifiche alla porta TCP 443 dai nomi di dominio speciali restricted.googleapis.com. L'utilizzo del dominio restricted.googleapis.com offre i seguenti vantaggi:

Consente di ridurre la superficie di attacco della rete utilizzando l'accesso privato Google quando i workload comunicano con le API e i servizi Google.
Garantisce che utilizzi solo i servizi che supportano i Controlli di servizio VPC.

Per ulteriori informazioni, vedi Configurazione dell'accesso privato Google.

Controlli perimetrali

Come mostrato nel diagramma dell'architettura consigliata, posiziona le risorse per l'applicazione serverless in un perimetro separato. Questo perimetro contribuisce a proteggere l'applicazione serverless da accessi indesiderati e dall'esfiltrazione di dati.

Policy di accesso

Per garantire che solo identità specifiche (utenti o servizi) possano accedere a risorse e dati, attiva i gruppi e i ruoli IAM.

Per garantire che solo risorse specifiche possano accedere ai progetti, devi attivare un criterio di accesso per la tua organizzazione Google. Per saperne di più, consulta Attributi del livello di accesso.

Proxy di identità e accesso

Se il tuo ambiente include già Identity-Aware Proxy (IAP), puoi configurare il bilanciatore del carico delle applicazioni esterno in modo che utilizzi IAP per autorizzare il traffico per la tua applicazione serverless. IAP consente di definire un livello di autorizzazione centrale per l'applicazione serverless, in modo da poter utilizzare i controlli dell'accesso a livello di applicazione anziché fare affidamento sui firewall a livello di rete.

Per abilitare IAP per la tua applicazione, nel file loadbalancer.tf, imposta iap_config.enable su true.

Per saperne di più su IAP, consulta la panoramica di Identity-Aware Proxy.

Service account e controlli dell'accesso

I service account sono identità che Google Cloud possono utilizzare per eseguire richieste API per tuo conto. Per implementare la separazione dei compiti, crea service account con ruoli diversi per scopi specifici. I service account sono i seguenti:

Un service account Cloud Run (cloud_run_sa) con i seguenti ruoli:
- roles/run.invoker
- roles/secretmanager.secretAccessor
Per saperne di più, consulta Consentire a Cloud Run di accedere a un secret.
Un account connettore di accesso VPC serverless (gcp_sa_vpcaccess) con il ruolo roles/compute.networkUser.
Un secondo account connettore di accesso VPC serverless (cloud_services) con il ruolo roles/compute.networkUser.

Questi service account per il connettore di accesso VPC serverless sono necessari per consentire al connettore di creare le regole di entrata e uscita del firewall nel progetto host. Per saperne di più, consulta Concedi le autorizzazioni ai service account nei tuoi progetti di servizio.
Un'identità di servizio per eseguire Cloud Run (run_identity_services) con il ruolo roles/vpcaccess.user.
Un service agent per le API di Google (cloud_services_sa) con il ruolo roles/editor. Questo service account consente a Cloud Run di comunicare con il connettore di accesso VPC serverless.
Un'identità di servizio per Cloud Run (serverless_sa) con il ruolo roles/artifactregistry.reader. Questo service account fornisce l'accesso ad Artifact Registry e alle chiavi di crittografia e decrittografia CMEK.

Gestione delle chiavi

Utilizzi le chiavi CMEK per proteggere i tuoi dati in Artifact Registry e in Cloud Run. Utilizzi le seguenti chiavi di crittografia:

Una chiave software per Artifact Registry che attesta il codice della tua applicazione serverless.
Una chiave di crittografia per criptare le immagini container di cui Cloud Run esegue il deployment.

Quando applichi la configurazione Terraform, specifichi la posizione CMEK, che determina la posizione geografica in cui vengono archiviate le chiavi. Devi assicurarti che le chiavi CMEK si trovino nella stessa regione delle tue risorse. Per impostazione predefinita, le chiavi CMEK vengono ruotate ogni 30 giorni.

Gestione di secret

Cloud Run supporta Secret Manager per archiviare i secret che la tua applicazione serverless potrebbe richiedere. Questi secret possono includere chiavi API e nomi utente e password del database. Per esporre il secret come volume montato, utilizza le variabili volume_mounts e volumes nel modulo principale.

Quando esegui il deployment di questo blueprint con il blueprint delle fondamenta aziendali, devi aggiungere i tuoi secret al progetto dei secret prima di applicare il codice Terraform. Il blueprint concederà il ruolo Secret Manager Secret Accessor al service account Cloud Run. Per saperne di più, consulta Utilizzare i secret.

Criteri dell'organizzazione

Questo blueprint aggiunge vincoli ai vincoli dei criteri dell'organizzazione. Per saperne di più sui vincoli utilizzati dal blueprint delle fondamenta aziendali, consulta Vincoli delle policy dell'organizzazione.

La tabella seguente descrive i vincoli aggiuntivi dei criteri dell'organizzazione definiti nel modulo Secure Cloud Run Security di questo blueprint.

Vincolo dei criteri	Descrizione	Valore consigliato
`constraints/run.allowedIngress`	Consenti il traffico in entrata solo dai servizi interni o dal bilanciatore del carico delle applicazioni esterno.	`internal-and-cloud-load-balancing`
`constraints/run.allowedVPCEgress`	Richiedi che le revisioni di un servizio Cloud Run utilizzino un connettore di accesso VPC serverless e assicurati che le impostazioni del traffico VPC in uscita delle revisioni siano impostate in modo da consentire solo intervalli privati.	`private-ranges-only`

Controlli operativi

Puoi attivare la registrazione e le funzionalità del livello Security Command Center Premium, come l'analisi dello stato della sicurezza e il rilevamento delle minacce. Questi controlli ti aiutano a eseguire le seguenti operazioni:

Monitora chi accede ai tuoi dati.
Assicurati che sia in atto un controllo adeguato.
Supportare la capacità dei team di gestione degli incidenti e delle operazioni di rispondere ai problemi che potrebbero verificarsi.

Logging

Per aiutarti a soddisfare i requisiti di controllo e ottenere informazioni dettagliate sui tuoi progetti, puoi configurare Google Cloud Observability con i log di dati per i servizi che vuoi monitorare. Esegui il deployment di Cloud Logging nei progetti prima di applicare il codice Terraform per assicurarti che il blueprint possa configurare la registrazione per il firewall, il bilanciatore del carico e la rete VPC.

Dopo aver eseguito il deployment del blueprint, ti consigliamo di configurare quanto segue:

Crea un sink di log aggregato in tutti i progetti.
Seleziona la regione appropriata in cui archiviare i log.
Aggiungi le chiavi CMEK al sink di logging.

Per tutti i servizi all'interno dei progetti, assicurati che i log includano informazioni sulle letture e scritture dei dati e che includano informazioni su ciò a cui accedono gli amministratori. Per saperne di più sulle best practice per la registrazione, consulta la sezione Controlli di rilevamento.

Monitoraggio e avvisi

Dopo aver eseguito il deployment del blueprint, puoi configurare gli avvisi per comunicare al tuo Security Operations Center (SOC) che potrebbe verificarsi un incidente di sicurezza. Ad esempio, puoi utilizzare gli avvisi per comunicare agli analisti della sicurezza quando un'autorizzazione è stata modificata in un ruolo IAM. Per saperne di più sulla configurazione degli avvisi di Security Command Center, consulta Configurare le notifiche sui risultati.

La dashboard di monitoraggio di Cloud Run, che fa parte della libreria di dashboard di esempio, fornisce le seguenti informazioni:

Conteggio delle richieste
Latenza di richiesta
Tempo di istanza fatturabile
Allocazione CPU container
Allocazione memoria container
Utilizzo CPU del container
Utilizzo della memoria del container

Per istruzioni sull'importazione della dashboard, consulta Installazione di dashboard di esempio. Per esportare gli avvisi, consulta i seguenti documenti:

Debug e risoluzione dei problemi

Puoi eseguire Connectivity Tests per eseguire il debug dei problemi di configurazione di rete tra Cloud Run e le risorse all'interno della subnet. Connectivity Tests simula il percorso previsto di un pacchetto e fornisce dettagli sulla connettività, inclusa l'analisi della connettività da risorsa a risorsa.

Connectivity Tests non è abilitato dal codice Terraform, ma devi configurarlo separatamente. Per saperne di più, consulta Crea ed esegui Connectivity Tests.

Controlli di rilevamento

Questa sezione descrive i controlli investigativi inclusi nel blueprint.

Cloud Armor e WAF

Utilizzi un bilanciatore del carico delle applicazioni esterno e Cloud Armor per fornire protezione DDoS (Distributed Denial of Service) per la tua applicazione serverless. Cloud Armor è il web application firewall (WAF) incluso in Google Cloud.

Configura le regole Cloud Armor descritte nella tabella seguente per proteggere l'applicazione serverless. Le regole sono progettate per contribuire a mitigare i rischi OWASP Top 10.

Nome regola Cloud Armor	Nome della regola ModSecurity
Remote Code Execution (RCE)	`rce-v33-stable`
Inclusione di file locali	`lfi-v33-stable`
Attacco di protocollo	`protocolattack-v33-stable`
Remote File Inclusion (RFI)	`rfi-v33-stable`
Rilevamento di scanner	`scannerdetection-v33-stable`
Attacco di session fixation	`sessionfixation-v33-stable`
SQL injection	`sqli-v33-stable`
Cross-site scripting (XSS)	`xss-v33-stable`

Quando queste regole sono attive, Cloud Armor nega automaticamente qualsiasi traffico che corrisponde alla regola.

Per saperne di più su queste regole, consulta Ottimizza le regole WAF preconfigurate di Google Cloud Armor.

Rilevamento di problemi di sicurezza in Cloud Run

Puoi rilevare potenziali problemi di sicurezza in Cloud Run utilizzando Recommender. Recommender può rilevare problemi di sicurezza come i seguenti:

Chiavi API o password archiviate nelle variabili di ambiente anziché in Secret Manager.
Contenitori che includono credenziali hardcoded anziché utilizzare identità di servizio.

Circa un giorno dopo il deployment di Cloud Run, Recommender inizia a fornire i risultati e i suggerimenti. Recommender mostra i risultati e le azioni correttive consigliate nell'elenco dei servizi Cloud Run o in Active Assist.

Modalità di deployment di Terraform

La tabella seguente descrive i modi in cui puoi eseguire il deployment di questo progetto e quali moduli Terraform si applicano a ciascuna modalità di deployment.

Modalità di deployment Moduli Terraform

Modalità di deployment	Moduli Terraform
Esegui il deployment di questo progetto dopo aver eseguito il deployment del progetto di fondazione di un'azienda (opzione consigliata). Questa opzione esegue il deployment delle risorse per questo blueprint nello stesso perimetro dei Controlli di servizio VPC utilizzato dal blueprint delle fondamenta dell'impresa. Per saperne di più, consulta Come personalizzare Foundation v2.3.1 per il deployment serverless protetto. Questa opzione utilizza anche il progetto dei segreti che hai creato quando hai eseguito il deployment del blueprint delle fondamenta dell'impresa.	Utilizza questi moduli Terraform: `secure-cloud-run-core` `secure-serverless-net` `secure-cloud-run-security` `secure-cloud-run`
Installa questo progetto senza installare il progetto di base per le aziende. Questa opzione richiede la creazione di un perimetro dei Controlli di servizio VPC.	Utilizza questi moduli Terraform: `secure-cloud-run-core` `secure-serverless-harness` `secure-serverless-net` `secure-cloud-run-security` `secure-cloud-run`

Esegui il deployment di questo progetto dopo aver eseguito il deployment del progetto di fondazione di un'azienda (opzione consigliata).

Questa opzione esegue il deployment delle risorse per questo blueprint nello stesso perimetro dei Controlli di servizio VPC utilizzato dal blueprint delle fondamenta dell'impresa. Per saperne di più, consulta Come personalizzare Foundation v2.3.1 per il deployment serverless protetto.

Questa opzione utilizza anche il progetto dei segreti che hai creato quando hai eseguito il deployment del blueprint delle fondamenta dell'impresa.

Utilizza questi moduli Terraform:

Installa questo progetto senza installare il progetto di base per le aziende.

Questa opzione richiede la creazione di un perimetro dei Controlli di servizio VPC.