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. Le norme e i sistemi di sicurezza di Google potrebbero variare in futuro, in virtù del costante miglioramento della protezione per i nostri clienti.

Le architetture serverless consentono di sviluppare software e servizi senza per eseguire il provisioning o la gestione 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 progetto di sicurezza che consiste in 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 implementare con il progetto (questo documento).

Sebbene tu possa implementare questo progetto base senza prima implementare il progetto base di Google Cloud Enterprise, questo documento presuppone che tu abbia già configurato un insieme di controlli di sicurezza di base come descritto nel progetto base di Google Cloud Enterprise. L'architettura descritta in questo documento ti aiuta a controlli aggiuntivi sugli elementi di base per aiutarti a proteggere i tuoi server diverse applicazioni.

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 progetto sono progettati per far fronte ai rischi che riguardano i vari casi d'uso descritti in questo documento.

Casi d'uso serverless

Il progetto 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 le modifiche ai dati in un database o la ricezione di un messaggio da un sistema di messaggistica come in Pub/Sub. Cloud Run viene attivato da richieste, ad esempio richieste HTTP.
  • Le funzioni Cloud Run sono limitate a insieme di runtime supportati. Puoi utilizzare Cloud Run con qualsiasi linguaggio di programmazione.
  • Le funzioni Cloud Run gestiscono i container e l'infrastruttura che controlla il server web o il runtime del linguaggio, in modo che tu possa concentrarti le API nel tuo 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 calcolo Google Cloud.

Architettura

Questo progetto ti consente di eseguire applicazioni serverless su Cloud Run con un VPC condiviso. Ti consigliamo di utilizzare il VPC condiviso perché centralizza i criteri e il controllo della rete per tutte le risorse di networking. 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 condivisa.

L'architettura del blueprint serverless.

L'architettura mostrata nel diagramma precedente utilizza una combinazione di i seguenti servizi e funzionalità di 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 agisce come firewall per le applicazioni web per proteggere le tue applicazioni serverless da attacchi web e denial of service (DoS).
  • Cloud Run consente di eseguire il codice dell'applicazione nei container e di gestire l'infrastruttura per tuo conto. In questo blueprint, l'impostazione di ingresso per il bilanciamento del carico interno 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 supportano i Controlli di servizio VPC.

    Per impostazione predefinita, crei il connettore di accesso VPC serverless progetto di servizio. Puoi creare l'accesso VPC serverless nel progetto host specificando true per il quando esegui il comando gcloud e la variabile di input connector_on_host_project. Rete Cloud Run sicura in maggior dettaglio più avanti in questo modulo. Per ulteriori informazioni, vedi Confronto dei metodi di configurazione.

  • Regole firewall Virtual Private Cloud (VPC) controllare il flusso di dati nella subnet che ospita le tue risorse, un server aziendale ospitato su Compute Engine o i dati aziendali archiviati di archiviazione ideale in Cloud Storage.

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

  • VPC condiviso consente di connettere il connettore di accesso VPC serverless progetto di servizio al progetto host.

  • Cloud Key Management Service (Cloud KMS) archivia chiavi di crittografia gestite dal cliente (CMEK) utilizzate dai servizi in questo progetto, incluse le applicazioni dell'applicazione, Artifact Registry e Cloud Run.

  • Identity and Access Management (IAM) e Gestione delle risorse per 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 condiviso, puoi eseguire il deployment Cloud Run e la tua applicazione serverless in un VPC Perimetro Service Control senza una rete VPC condiviso. Potresti a implementare questa architettura alternativa topologia hub e spoke.

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

Un'architettura alternativa per il progetto serverless.

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

Struttura dell'organizzazione

Le risorse vengono raggruppate in modo da poterle gestire e separare ambienti di sviluppo e test dal tuo ambiente di produzione. Resource Manager consente di raggruppare logicamente le risorse per progetto, cartella dell'organizzazione.

Il seguente diagramma mostra una gerarchia di risorse con cartelle che rappresentano per diversi ambienti, come bootstrap, comune, di produzione, non di produzione (o test) e sviluppo. Questa gerarchia di risorse si basa sulla gerarchia descritto nel progetto base aziendale. Esegui il deployment dei progetti specificati dal progetto 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

Puoi utilizzare le cartelle per isolare l'ambiente di produzione e i servizi di governance dagli ambienti non di produzione e di test. La tabella seguente descrive le cartelle del progetto delle basi aziendali utilizzate progetto.

Cartella Descrizione
Bootstrap Contiene le risorse necessarie per il deployment degli elementi di base aziendali progetto.
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 progetto, La cartella Non-production contiene il progetto di servizio e l'host progetto.
Dev Contiene progetti con risorse cloud attualmente in corso lo sviluppo di applicazioni. In questo progetto, la cartella Dev contiene progetto di servizio e progetto host.

Puoi modificare i nomi di queste cartelle per allinearli a quelli della tua organizzazione struttura delle cartelle, ma ti consigliamo di mantenerne una simile. Per ulteriori informazioni, vedi Struttura organizzativa. Per altre strutture di cartelle, vedi Decidi una gerarchia delle risorse per la tua zona di destinazione di Google Cloud.

Progetti

Puoi isolare le risorse nel tuo ambiente utilizzando projects. 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 di progetto simile.

Progetto Descrizione
Progetto host Questo progetto include le regole firewall in entrata e le eventuali risorse che hanno indirizzi IP interni (come descritto in Connettersi a una rete VPC). Quando utilizzi una rete VPC condivisa, 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 condivisa.

Quando applichi il codice Terraform, specifichi il nome progetto. Il progetto esegue il deployment di Cloud Run, Google Cloud Armor, connettore di accesso VPC serverless, e il 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 e il progetto esegue il deployment di Cloud KMS. Se utilizzi Sicuro modulo Harness di Cloud Run, Artifact Registry e il deployment.

Se esegui il deployment di questo progetto dopo aver eseguito il deployment della il progetto base, questo è il progetto secret creato il progetto delle basi aziendali. Per ulteriori informazioni sui progetti di base per le fondazioni aziendali, consulta Progetti.

Se esegui il deployment di più istanze di questo blueprint senza il blueprint Enterprise Foundations, ogni istanza avrà il proprio progetto di sicurezza.

Mappatura di ruoli e gruppi ai progetti

Devi concedere a diversi gruppi di utenti dell'organizzazione l'accesso ai progetti che compongono l'architettura serverless. Nella tabella seguente vengono descritti i suggerimenti sui progetti 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 di 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, i criteri 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.
  • Configura un monitoraggio e un logging sufficienti per consentire il rilevamento, l'indagine 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.

Crea controlli di sistema

Quando esegui il deployment della tua applicazione serverless, utilizzi Artifact Registry per archiviare le immagini container e i file 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 una connessione per il tuo Application Load Balancer esterno Per impostazione predefinita, utilizzi un certificato autofirmato che puoi sostituire con un certificato gestito dopo aver applicato il codice Terraform. Per ulteriori informazioni l'installazione e l'utilizzo di certificati gestiti, consulta Utilizzo dei certificati SSL gestiti da Google.

Regole di rete e firewall

Regole firewall Virtual Private Cloud (VPC) per controllare il flusso di dati nei perimetri. Puoi creare regole firewall che per negare tutto il traffico in uscita, ad eccezione di connessioni TCP 443 specifiche dalla porta Nomi di dominio speciali restricted.googleapis.com. L'utilizzo del Il dominio restricted.googleapis.com offre i seguenti vantaggi:

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

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

Controlli del perimetro

Come mostrato in diagramma dell'architettura consigliata, collocare 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.

Criterio di accesso

Per assicurarti che solo identità specifiche (utenti o servizi) possano accedere alle risorse e ai dati, abiliti 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 stabilire un livello di autorizzazione centrale serverless, per permetterti di usare controlli dell'accesso a livello di applicazione anziché fare affidamento su firewall a livello di rete.

Per attivare gli acquisti in-app per la tua applicazione, imposta iap_config.enable su true nel file loadbalancer.tf.

Per ulteriori informazioni su IAP, consulta Panoramica di Identity-Aware Proxy.

Account di servizio e controlli dell'accesso

Gli account di servizio sono identità che Google Cloud può 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 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) che ha il ruolo roles/compute.networkUser.

    Questi account di servizio per l'accesso VPC serverless sono necessari in modo che il connettore possa creare il traffico in entrata del firewall e le regole di traffico in uscita nel progetto host. Per ulteriori informazioni, vedi Concedi le autorizzazioni agli account di servizio nei tuoi progetti di servizio.

  • Un'identità di servizio per eseguire Cloud Run (run_identity_services) che ha 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 Connettore di accesso VPC serverless.

  • Un'identità 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 decriptazione CMEK.

Gestione delle chiavi

Puoi utilizzare 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, specifichi Posizione CMEK, che determina la posizione geografica in cui sono 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 richiesti dalla tua applicazione serverless. Questi possono includere chiavi API, nomi utente e password dei 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 secret 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 progetto aggiunge vincoli vincoli dei criteri dell'organizzazione. Per ulteriori informazioni sui i vincoli utilizzati dal progetto di base aziendale, vedi Vincoli dei criteri dell'organizzazione.

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

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

Controlli operativi

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

  • Monitora chi accede ai tuoi dati.
  • Assicurarsi che sia in atto un adeguato controllo.
  • Supporta la capacità dei team operativi e di gestione degli incidenti di risolvere i 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 Cloud Logging nei progetti prima di applicare il codice Terraform per garantire che il progetto configurare il logging per il firewall, il bilanciatore del carico e la rete VPC.

Dopo aver eseguito il deployment del progetto base, ti consigliamo di configurare seguenti:

  • Crea un sink di 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 relative alle letture e scritture di dati e assicurati che includano informazioni su accesso degli 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: Installa 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à tra risorse.

Connectivity Tests non è abilitato dal codice Terraform; devi configurarlo separatamente. Per saperne di più, vedi Creare ed eseguire Connectivity Tests.

Controlli di rilevamento

Questa sezione descrive i controlli di rilevamento inclusi nei 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 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 regola Google Cloud Armor Nome regola ModSecurity
Esecuzione di codice remota rce-v33-stable
Inclusione file locale lfi-v33-stable
Attacco al protocollo protocolattack-v33-stable
Inclusione di file remoti rfi-v33-stable
Rilevamento 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 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 Motore per suggerimenti. Il Recommender può rilevare problemi di sicurezza come:

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

Circa un giorno dopo il deployment di Cloud Run, Il motore per suggerimenti inizia a fornire risultati e raccomandazioni. 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 Terraform

La tabella seguente descrive i modi in cui puoi eseguire il deployment di questo blueprint e i moduli Terraform applicabili 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 progetto nello stesso Perimetro dei Controlli di servizio VPC utilizzato dall'azienda del progetto di base. Per ulteriori informazioni, vedi 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 Controlli di servizio VPC perimetrale.		 Utilizza questi moduli Terraform:

Riepilogo

Per implementare l'architettura descritta in questo documento, segui questi passaggi:

  1. Esamina il file 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 alla tua applicazione serverless.
  3. Nell'ambiente di test, esegui il deployment Esempio di Secure Cloud Run per vedere il progetto in azione. Nell'ambito del processo di test, considera nel seguente modo:
    1. Usa Security Command Center per analizzare i progetti rispetto requisiti di conformità.
    2. Sostituisci l'applicazione di esempio con un'applicazione reale ed esegui un tipico scenario di deployment.
    3. Lavora con i team di Application Engineering e Operations la tua azienda per testare il proprio accesso ai progetti e se possono interagire con la soluzione come si aspettano.
  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 Guida di Google Cloud Armor e dei bilanciatori del carico delle applicazioni esterni proteggiti da OWASP Top 10, come descritto in OWASP Top 10 2021 mitigation options - Opzioni di mitigazione OWASP Top 10 2021 su Google Cloud Pratiche di programmazione sicura, ad esempio la gestione delle eccezioni, come descritto in il software OWASP Secure Pratiche di programmazione e catena di fornitura Livelli per gli artefatti software (SLSA)
2. Autenticazione non funzionante 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 predefinito) (account di servizio Compute Engine)
  • Ruoli IAM con ambito ristretto Account di servizio Cloud Run
  • Controlli di servizio VPC per limitare l'ambito dell'API Google Cloud (fornito utilizzando il progetto base aziendale di Google Cloud)
 Nessuno
5. Monitoraggio e logging delle funzioni inadeguati Cloud Logging Dashboard e struttura di avviso di Cloud Monitoring
6. Dipendenze di terze parti non sicure 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'accesso alle API Google Cloud (fornito utilizzando il blueprint Enterprise Foundations) Nessuno
10. Gestione inappropriata delle eccezioni e messaggi di errore dettagliati Nessuno Best practice per la programmazione sicura
11. Funzioni obsolete, risorse cloud e trigger di eventi Utilizza le revisioni 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. Inoltre, le revisioni è utile per testare la strategia di sicurezza di una nuova revisione utilizzando i test A/B e il monitoraggio e logging.
  • Infrastructure as Code (IaC) per gestire le risorse cloud
  • Monitoraggio delle risorse cloud con Security Command Center
  • Monitoraggio della fatturazione Cloud
  • Pulizia delle risorse cloud inutilizzate per ridurre al minimo la superficie di attacco
12. Persistenza dei dati di esecuzione incrociata Nessuno Nessuno

Passaggi successivi