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

Last reviewed 2023-03-10 UTC

Questi contenuti sono stati aggiornati a marzo 2023 e rappresentano lo status quo al momento della loro 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 sviluppare applicazioni per una vasta gamma di servizi.

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

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

Sebbene tu possa implementare questo blueprint senza prima implementare il Google Cloud blueprint Enterprise Foundations, questo documento presuppone che tu abbia già configurato un insieme di controlli di sicurezza di base come descritto nel blueprint Google Cloud Enterprise Foundations. L'architettura descritta in questo documento ti consente di applicare controlli aggiuntivi alla tua base per proteggere le tue applicazioni serverless.

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

Casi d'uso serverless

Il blueprint supporta i seguenti casi d'uso:

Le differenze tra le funzioni Cloud Run e Cloud Run includeno quanto segue:

  • Le funzioni Cloud Run vengono attivate da eventi, come 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.
  • Le funzioni Cloud Run gestiscono i contenitori e l'infrastruttura che controlla il server web o il runtime del linguaggio, in modo che tu possa concentrarti sul codice. Cloud Run ti offre la flessibilità di eseguire personalmente questi servizi, in modo da avere il controllo della configurazione del contenitore.

Per saperne di più sulle differenze tra Cloud Run e Cloud Run Functions, consulta Scegliere 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 i criteri e il controllo della rete per tutte le risorse di rete. Inoltre, il VPC condiviso viene implementato nel blueprint Enterprise Foundations.

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

L'architettura del blueprint serverless.

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

  • 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 agisce come 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 in container e gestisce l'infrastruttura per tuo conto. In questo blueprint, l'impostazione di ingresso per Cloud Load Balancing e di Cloud limita l'accesso a Cloud Run in modo che Cloud Run accetti le richieste solo dal bilanciatore del carico delle applicazioni esterno.
  • Il connettore di accesso VPC serverless connette l'applicazione serverless alla rete VPC utilizzando Accesso VPC serverless. L'accesso VPC serverless contribuisce ad assicurare che le richieste della 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 Rete Cloud Run sicura. Per ulteriori informazioni, consulta Confronto dei metodi di configurazione.

  • Le regole del firewall Virtual Private Cloud (VPC) controllano il flusso di dati nella sottorete che ospita le tue risorse, ad esempio un server aziendale ospitato su Compute Engine o i dati aziendali archiviati in Cloud Storage.

  • Controlli di servizio VPC crea un perimetro di sicurezza che isola i servizi e le risorse Cloud Run impostando l'autorizzazione, i controlli di accesso e il scambio di dati protetti. Questo perimetro è progettato per proteggere i contenuti in arrivo, isolare l'applicazione impostando controlli dell'accesso e monitoraggio aggiuntivi e separare la governance di Google Cloud dall'applicazione. La gestione include la gestione delle chiavi e la registrazione.

  • La VPC condivisa ti consente di collegare il connettore di accesso VPC serverless nel progetto di servizio al progetto host.

  • Cloud Key Management Service (Cloud KMS) memorizza le chiavi di crittografia gestite dal cliente (CMEK) utilizzate dai servizi in questo blueprint, tra cui l'applicazione serverless, Artifact Registry e Cloud Run.

  • Identity and Access Management (IAM) e Resource Manager aiutano a limitare l'accesso e a 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 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.

Un'architettura alternativa per il progetto serverless.

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

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 ti 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, comuni, di produzione, non di produzione (o di test) e di sviluppo. Questa gerarchia delle risorse si basa sulla gerarchia описана nel blueprint Enterprise Foundations. Esegui il deployment dei progetti specificati dal progetto base nelle seguenti cartelle: Common, Production, Non-production e Dev.

La struttura organizzativa del blueprint serverless.

Le sezioni seguenti descrivono questo diagramma in maggiore dettaglio.

Cartelle

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

Cartella Descrizione
Bootstrap Contiene le risorse necessarie per eseguire il deployment del blueprint Nuclei dell'azienda.
Common Contiene servizi centralizzati per l'organizzazione, ad esempio il progetto di sicurezza.
Production Contiene progetti con risorse cloud che sono state testate e sono pronte per essere utilizzate dai clienti. In questo blueprint, la Production contiene il progetto di servizio e il progetto host.
Non-production Contiene progetti con risorse cloud attualmente in fase di test e di organizzazione per il rilascio. In questo blueprint, la 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 organizzativa. Per altre strutture di cartelle, consulta Decidere una gerarchia delle risorse per la Google Cloud landing zone.

Progetti

Puoi isolare le risorse nel tuo ambiente utilizzando 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 con indirizzi IP interni (come descritto in Connettersi a una rete VPC). Quando utilizzi una rete 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. Colleghi il progetto di servizio al progetto host in modo che possa partecipare alla rete VPC condiviso.

Quando applichi il codice Terraform, specifica il nome di questo progetto. Il blueprint esegue il deployment di Cloud Run, Google Cloud Armor, del connettore di accesso VPC serverless e del bilanciatore del carico.
Progetto di sicurezza Questo progetto include i 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 per le basi della sicurezza, questo progetto è il progetto dei segreti creato dal blueprint per le basi dell'azienda. Per saperne di più sui progetti della piattaforma di base per le aziende, consulta Progetti.

Se esegui il deployment di più istanze di questo blueprint senza il blueprint delle basi dell'azienda, ogni istanza avrà 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 costituiscono l'architettura serverless. La tabella seguente descrive i consigli per i blueprint per i gruppi di utenti e le assegnazioni dei ruoli nei progetti che crei. Puoi personalizzare i gruppi in base 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
Amministratore della sicurezza serverless

grp-gcp-serverless-security-admin@example.com
Progetto di sicurezza
Sviluppatore Cloud Run

grp-gcp-secure-cloud-run-developer@example.com
Progetto di sicurezza
Utente Cloud Run

grp-gcp-secure-cloud-run-user@example.com
Progetto di servizio

Controlli di sicurezza

Questa sezione illustra i controlli di sicurezza in Google Cloud che utilizzi per proteggere la tua architettura serverless. I principi di sicurezza principali da considerare sono i seguenti:

  • Garantire l'accesso in base al principio del privilegio minimo, assegnando alle persone solo i privilegi necessari per svolgere le loro attività.
  • Proteggi le connessioni di rete tramite la progettazione della segmentazione, le norme dell'organizzazione e i criteri firewall.
  • Configurazione sicura per ciascuno dei servizi.
  • Comprendi i livelli di rischio e i requisiti di sicurezza per l'ambiente che ospita i tuoi carichi di lavoro serverless.
  • Configurare un monitoraggio e un logging sufficienti per consentire il rilevamento, la verifica e la risposta.

Controlli di sicurezza per le 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 binari. Artifact Registry supporta CMEK per consentirti di criptare il repository utilizzando le tue chiavi di crittografia.

Traffico SSL

Per supportare il traffico HTTPS verso la tua applicazione serverless, devi configurare un certificato SSL per il tuo bilanciatore del carico delle applicazioni esterno. Per impostazione predefinita, utilizzi un certificato autofirmato che puoi modificare in un certificato gestito dopo aver applicato il codice Terraform. Per saperne di più sull'installazione e sull'utilizzo dei certificati gestiti, consulta Utilizzare i 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 del firewall che proibiscano tutte le uscite, ad eccezione di connessioni specifiche sulla porta TCP 443 da nomi di dominio speciali restricted.googleapis.com. L'utilizzo del dominio restricted.googleapis.com presenta i seguenti vantaggi:

  • Contribuisce a ridurre la superficie di attacco della rete utilizzando Accesso privato Google quando i carichi di lavoro comunicano con le API e i servizi Google.
  • Ti assicura di utilizzare solo servizi che supportano i Controlli di servizio VPC.

Per ulteriori informazioni, consulta Configurare l'accesso privato Google.

Controlli del perimetro

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 dei dati.

Policy di accesso

Per assicurarti che solo identità specifiche (utenti o servizi) possano accedere alle risorse e ai dati, abilita i gruppi e i ruoli IAM.

Per garantire che solo risorse specifiche possano accedere ai tuoi progetti, attiva un criterio di accesso per la tua organizzazione Google. Per ulteriori informazioni, consulta Attributi del livello di accesso.

Identity and Access Proxy

Se il tuo ambiente include già Identity and Access 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 la tua applicazione serverless, in modo da poter utilizzare i controlli dell'accesso a livello di applicazione anziché fare affidamento su firewall a livello di rete.

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

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

Account di servizio e controlli di accesso

Gli account di servizio sono identità che Google Cloud puoi utilizzare per eseguire richieste API per tuo conto. Per implementare la separazione delle responsabilità, crei account di servizio con ruoli diversi per scopi specifici. Gli account di servizio 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 segreto.

  • 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 affinché il connettore possa creare le regole di ingresso e in uscita del firewall nel progetto host. Per ulteriori informazioni, consulta Concedere autorizzazioni agli account di servizio nei progetti di servizi.

  • 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à servizio per Cloud Run (serverless_sa) con il ruolo roles/artifactregistry.reader. Questo account di servizio fornisce accesso alle chiavi di crittografia e decrittografia di Artifact Registry e CMEK.

Gestione delle chiavi

Utilizzi le chiavi CMEK per proteggere i tuoi dati in Artifact Registry e in Cloud Run. Utilizza 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, specifica la posizione del CMK, che determina la posizione geografica in cui vengono archiviate le chiavi. Devi assicurarti che le chiavi CMEK si trovino nella stessa regione delle 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 segreto come volume montato, utilizza le variabili volume_mounts e volumes nel modulo principale.

Quando esegui il deployment di questo blueprint con il blueprint Enterprise Foundations, devi aggiungere i tuoi secret al progetto secrets prima di applicare il codice Terraform. Il blueprint concederà il ruolo Accesso ai secret di Secret Manager all'account di servizio Cloud Run. Per ulteriori informazioni, consulta la sezione Utilizzare i secret.

Criteri dell'organizzazione

Questo blueprint aggiunge vincoli ai vincoli dei criteri dell'organizzazione. Per ulteriori informazioni sui vincoli utilizzati dal progetto della piattaforma di base aziendale, consulta Vincoli delle norme dell'organizzazione.

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

Vincolo delle norme Descrizione Valore consigliato
constraints/run.allowedIngress Consenti il traffico in entrata solo dai servizi interni o dall'Application Load Balancer 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 di traffico VPC in uscita delle revisioni siano impostate per consentire solo intervalli privati. private-ranges-only

Controlli operativi

Puoi attivare il logging e le funzionalità del livello Premium di Security Command Center, come le analisi dello stato della sicurezza e il rilevamento delle minacce. Questi controlli ti consentono di:

  • Monitora chi accede ai tuoi dati.
  • Assicurati che sia stato implementato un controllo adeguato.
  • Supporta 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 sui tuoi progetti, configura Google Cloud Observability con i log dei 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 dei log aggregato in tutti i progetti.
  • Seleziona la regione appropriata per archiviare i log.
  • Aggiungi le chiavi CMEK all'apposita destinazione di logging.

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

Monitoraggio e avvisi

Dopo aver implementato il blueprint, puoi configurare avvisi per notificare al tuo Centro operativo di sicurezza (SOC) la possibile presenza di 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 ulteriori informazioni sulla configurazione degli avvisi di Security Command Center, consulta 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, consulta Installare dashboard di esempio. Per esportare gli avvisi, consulta i seguenti documenti:

Debug e risoluzione dei problemi

Puoi eseguire test di connettività per aiutarti a risolvere i problemi di configurazione di rete tra Cloud Run e le risorse all'interno della tua sottorete. Connectivity Tests simula il percorso previsto di un pacchetto e fornisce dettagli sulla connettività, inclusa l'analisi della connettività tra risorse.

Connectivity Tests non è abilitato dal codice Terraform; devi configurarlo separatamente. Per ulteriori informazioni, vedi Creare ed eseguire test di connettività.

Controlli di rilevamento

Questa sezione descrive i controlli di rilevamento inclusi nel progetto.

Google Cloud Armor e WAF

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

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

Nome della regola Google Cloud Armor Nome della regola ModSecurity
Esecuzione di codice da remoto rce-v33-stable
File locale incluso lfi-v33-stable
Attacco di protocollo protocolattack-v33-stable
Inclusione di file remoti rfi-v33-stable
Rilevamento dello scanner scannerdetection-v33-stable
Attacco di fissazione della sessione sessionfixation-v33-stable
SQL injection sqli-v33-stable
Cross-site scripting (XSS) xss-v33-stable

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

Per ulteriori informazioni su queste regole, consulta Ottimizzare 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. Il Recommender può rilevare problemi di sicurezza come:

  • Chiavi API o password memorizzate nelle variabili di ambiente invece che in Secret Manager.
  • Contenuti dei contenitori che includono credenziali hardcoded anziché utilizzare identità di servizio.

Circa un giorno dopo il deployment di Cloud Run, Recommender inizia a fornire i suoi risultati e consigli. Lo strumento di raccomandazione mostra i risultati e le azioni correttive consigliate nell'elenco dei servizi Cloud Run o nell'hub di suggerimenti.

Modalità di deployment di Terraform

La tabella seguente descrive i modi in cui puoi eseguire il deployment di questo blueprint e i moduli Terraform da applicare per ogni 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 basi aziendali. Per ulteriori informazioni, consulta Come personalizzare Foundation v2.3.1 per il deployment serverless sicuro.

Questa opzione utilizza anche il progetto dei segreti che hai creato quando hai eseguito il deployment del blueprint Enterprise Foundations.
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.
Utilizza questi moduli Terraform:

Riepilogo

Per implementare l'architettura descritta in questo documento:

  1. Esamina il README del blueprint 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 eseguire il deployment del bilanciatore del carico e il browser mostrerà avvisi relativi a connessioni non sicure quando tenterai di accedere all'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 la possibilità di svolgere le seguenti operazioni:
    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 un tipico scenario di deployment.
    3. Collabora con i team di operazioni e di ingegneria 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.

Mappature di conformità

Per contribuire a definire i controlli di sicurezza principali relativi alle applicazioni serverless, la Cloud Security Alliance (CSA) ha pubblicato i 12 principali rischi critici per le applicazioni serverless. I controlli di sicurezza utilizzati in questo blueprint ti aiutano ad affrontare la maggior parte di questi rischi, come descritto nella tabella seguente.

Rischio Mitigazione del progetto Tua responsabilità
1. Iniezione di dati sugli eventi della funzione Google Cloud Armor e i bilanciatori del carico delle applicazioni esterni contribuiscono a difendere dalle prime 10 minacce OWASP, come descritto in Opzioni di mitigazione delle prime 10 minacce OWASP 2021 su Google Cloud Pratiche di codifica sicura come la gestione delle eccezioni, come descritto nelle OWASP Secure Coding Practices e nei Supply Chain Levels for Software Artifacts (SLSA)
2. Autenticazione non funzionante Nessuno IAP e Identity Platform per autenticare gli utenti al servizio
3. Configurazione di 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 l'account di servizio Compute Engine predefinito)
  • Ruoli IAM con ambito limitato nell'account di servizio Cloud Run
  • Controlli di servizio VPC per limitare l'ambito dell' Google Cloud accesso Google Cloud alle API (come fornito utilizzando il blueprint Google Cloud Enterprise Foundations)
Nessuno
5. Monitoraggio e logging delle funzioni inadeguati Cloud Logging Dashboard e struttura di avviso di Cloud Monitoring
6. Dipendenze non sicure di terze parti Nessuno Proteggi la pipeline CI/CD utilizzando la scansione del codice e l'analisi di pre-deployment
7. Archiviazione non sicura dei secret delle applicazioni Secret Manager Gestione dei secret nel codice dell'applicazione
8. Denial of Service e esaurimento delle risorse finanziarie
  • Google 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' Google Cloud accesso alle API (fornito utilizzando il blueprint Enterprise Foundations) Nessuno
10. Gestione delle eccezioni non corretta e messaggi di errore dettagliati Nessuno Best practice per la programmazione sicura
11. Funzioni, risorse cloud e trigger di eventi obsoleti Utilizza le revisions per ridurre al minimo l'area 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 posizione di sicurezza di una nuova revisione utilizzando i test A/B, nonché gli strumenti di monitoraggio e registrazione.
  • Infrastructure as Code (IaC) per gestire le risorse cloud
  • Monitoraggio delle risorse cloud tramite 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