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

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 eseguire prima il deployment del Google Cloud blueprint delle fondamenta aziendali, questo documento presuppone che tu abbia già configurato un insieme di base di controlli di sicurezza, come descritto nel blueprint delle fondamenta 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 Top 12 Critical Risks for Serverless Applications. I controlli di sicurezza utilizzati in questo progetto 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 le funzioni Cloud Run

Le differenze tra le funzioni Cloud Run 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.
• Le funzioni Cloud Run sono limitate 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 server web 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 la sezione Scelta di un'opzione di Google Cloud calcolo.

Architettura

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

Architettura consigliata: Cloud Run con una rete VPC condiviso

L'immagine seguente mostra come eseguire le applicazioni serverless in una rete VPC condiviso.

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 web e denial of service (DoS).
• Cloud Run ti consente di eseguire il codice dell'applicazione nei container e gestisce l'infrastruttura per tuo conto. In questo progetto, l'impostazione Ingress di Cloud Load Balancing e Cloud 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 l'applicazione serverless alla 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 ulteriori informazioni, consulta la sezione 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.

• VPC condivisa consente di connettere il connettore di accesso VPC serverless nel 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, inclusi 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 condiviso

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

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

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 una VPC condivisa.

Struttura dell'organizzazione

Raggruppa 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, come 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.

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, vedi Struttura organizzativa. 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 seguente tabella 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 di ingresso 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 e 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 bilanciatore 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 anche eseguito il deployment di Artifact Registry. Se esegui il deployment di questo blueprint dopo aver eseguito il deployment del blueprint delle basi della 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 i criteri firewall.
• Configurazione sicura per ciascun servizio.
• Comprendere 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 ulteriori informazioni 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 da nomi di dominio speciali restricted.googleapis.com. L'utilizzo del dominio restricted.googleapis.com presenta 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.
• Assicura 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 contribuire a garantire che solo identità specifiche (utenti o servizi) possano accedere a risorse e dati, devi attivare 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 maggiori informazioni, vedi 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 per utilizzare 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

Gli account di servizio 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 account di servizio 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 ingresso e uscita del firewall nel progetto host. Per ulteriori informazioni, consulta Concedere autorizzazioni ai service account nei progetti di servizio.

• Un'identità di servizio per eseguire Cloud Run (run_identity_services) con il ruolo roles/vpcaccess.user.

• Un agente di servizio per le API di Google (cloud_services_sa) con il ruolo roles/editor. Questo account di servizio 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 account di servizio 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 all'account di servizio Cloud Run. Per maggiori informazioni, consulta la sezione Utilizzare i secret.

Criteri dell'organizzazione

Questo blueprint aggiunge vincoli ai vincoli dei criteri dell'organizzazione. Per saperne di più sui vincoli utilizzati dal progetto della piattaforma aziendale, 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 da 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 Premium di Security Command Center, 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.
• Supporta la capacità dei team di gestione e operazioni degli incidenti 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 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 Centro operativo di sicurezza 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, vedi Configurare le notifiche dei 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, vedi Installazione di dashboard di esempio. Per esportare gli avvisi, consulta i seguenti documenti:

• Introduzione agli avvisi

• Esportazione delle metriche di Cloud Monitoring

Debug e risoluzione dei problemi

Puoi eseguire i test di connettività 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ù, vedi Creare ed eseguire test di connettività.

Controlli di rilevamento

Questa sezione descrive i controlli di rilevamento 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 della regola Cloud Armor	Nome della regola ModSecurity
Esecuzione di codice da remoto	rce-v33-stable
Inclusione di file locale	lfi-v33-stable
Attacco al protocollo	protocolattack-v33-stable
Inclusione di file remoti	rfi-v33-stable
Rilevamento dello scanner	scannerdetection-v33-stable
Attacco di sessione fissa	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 corrispondente alla regola.

Per saperne di più su queste regole, consulta Ottimizzazione delle 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 nell'hub dei suggerimenti.

Modalità di deployment di Terraform

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

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 di Controlli di servizio VPC utilizzato dal blueprint delle fondazioni aziendali. Per saperne di più, consulta Come personalizzare Foundation v2.3.1 per il deployment serverless protetto. Questa opzione utilizza anche il progetto dei secret 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

Riepilogo

Per implementare l'architettura descritta in questo documento:

1. Consulta il file README per il progetto e assicurati di soddisfare tutti i prerequisiti.
2. Crea un certificato SSL da utilizzare con il bilanciatore del carico delle applicazioni esterno.
   Se non completi questo passaggio, il blueprint utilizza un certificato autofirmato per il deployment del bilanciatore del carico e il browser visualizzerà avvisi relativi a connessioni non sicure quando tenti di accedere alla tua applicazione serverless.
3. Nell'ambiente di test, esegui il deployment dell'esempio di Cloud Run sicuro per vedere il blueprint in azione. Nell'ambito della procedura di test, valuta di fare quanto segue:
   1. Utilizza Security Command Center per eseguire la scansione dei progetti in base ai requisiti di conformità comuni.
   2. Sostituisci l'applicazione di esempio con un'applicazione reale ed esegui uno scenario di deployment tipico.
   3. Collabora con i team di ingegneria e operazioni delle applicazioni della tua azienda per testare il loro accesso ai progetti e verificare se possono interagire con la soluzione nel modo previsto.
4. Esegui il deployment del progetto nel tuo ambiente.

Mapping di conformità

Per contribuire a definire i controlli di sicurezza chiave correlati alle applicazioni serverless, la Cloud Security Alliance (CSA) ha pubblicato Top 12 Critical Risks for Serverless Applications. I controlli di sicurezza utilizzati in questo progetto ti aiutano a gestire la maggior parte di questi rischi, come descritto nella tabella seguente.

Rischio	Mitigazione del progetto	Tua responsabilità
1. Inserimento di dati sugli eventi della funzione	Cloud Armor e i bilanciatori del carico delle applicazioni esterni contribuiscono a proteggere dalle 10 principali minacce OWASP, come descritto in Opzioni di mitigazione delle 10 principali minacce OWASP del 2021 su Google Cloud	Pratiche di codifica sicure come la gestione delle eccezioni, come descritto in OWASP Secure Coding Practices e Supply chain Levels for Software Artifacts (SLSA)
2. Autenticazione compromessa	Nessuno	IAP e Identity Platform per autenticare gli utenti al servizio
3. Configurazione del deployment serverless non sicura	CMEK con Cloud KMS	Gestione delle tue chiavi di crittografia
4. Ruoli e autorizzazioni delle funzioni con privilegi in eccesso	Account di servizio personalizzato per l'autenticazione del servizio (non il account di servizio Compute Engine predefinito) Ruoli IAM con ambito ristretto nell'account di servizio Cloud Run Controlli di servizio VPC per limitare l'ambito dell'accesso all'API Google Cloud (come fornito utilizzando il blueprint delle fondamenta aziendali) Google Cloud	Nessuno
5. Monitoraggio e logging delle funzioni inadeguati	Cloud Logging	Struttura di avvisi e dashboard di Cloud Monitoring
6. Dipendenze di terze parti non sicure	Nessuno	Proteggi la pipeline CI/CD utilizzando la scansione del codice e l'analisi pre-deployment
7. Archiviazione non sicura dei secret delle applicazioni	Secret Manager	Gestione dei secret nel codice dell'applicazione
8. Denial of service ed esaurimento delle risorse finanziarie	Cloud Armor Timeout del servizio Cloud Run (il valore predefinito è 120 secondi)	Nessuno
9. Manipolazione della logica di business serverless	Controlli di servizio VPC per limitare l'ambito dell'accesso all'API Google Cloud (fornito utilizzando il blueprint delle fondazioni aziendali)	Nessuno
10. Gestione impropria delle eccezioni e messaggi di errore dettagliati	Nessuno	Best practice per la programmazione sicura
11. Funzioni, risorse cloud e trigger di eventi obsoleti	Utilizza le revisioni per ridurre al minimo la superficie di attacco. Le revisioni contribuiscono a ridurre la probabilità di attivare accidentalmente un'iterazione precedente e obsoleta di un servizio. Le revisioni ti aiutano anche a testare la postura di sicurezza di una nuova revisione utilizzando i test A/B, nonché gli strumenti di monitoraggio e logging.	Infrastructure as Code (IaC) per gestire le risorse cloud Monitoraggio delle risorse cloud utilizzando Security Command Center Monitoraggio della fatturazione Cloud Pulizia delle risorse cloud inutilizzate per ridurre al minimo la superficie di attacco
12. Persistenza dei dati tra le esecuzioni	Nessuno	Nessuno

Passaggi successivi

• Per un ambiente sicuro di base, consulta il Google Cloud progetto della piattaforma aziendale.
• Per visualizzare i dettagli del progetto base descritto in questo documento, leggi il file README di configurazione di Terraform.

• Per informazioni sulle best practice per la sicurezza e la conformità, consulta Google Cloud Well-Architected Framework: sicurezza, privacy e conformità.

• Per ulteriori best practice e blueprint, consulta il Centro best practice per la sicurezza.