Esegui il deployment di un'architettura serverless protetta con Cloud Run

Last reviewed 2023-03-10 UTC

Questi contenuti sono stati aggiornati a marzo 2023 e rappresentano lo status quo al momento in cui sono stati redatti. Le norme e i sistemi di sicurezza di Google possono variare in futuro, grazie al costante miglioramento della protezione per i nostri clienti.

Le architetture serverless ti consentono di sviluppare software e servizi senza eseguire il provisioning o la gestione dei server. puoi usare architetture serverless per creare applicazioni per un'ampia gamma di servizi.

Questo documento fornisce indicazioni utili a 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 set di configurazioni e script Terraform.
  • Una guida all'architettura, alla progettazione e ai controlli di sicurezza che implementi con il progetto base (questo documento).

Anche se puoi eseguire il deployment di questo progetto senza prima eseguire il deployment del progetto di base per la piattaforma aziendale di Google Cloud, questo documento presuppone che tu abbia già configurato un set di controlli di sicurezza di base come descritto nel progetto di base per la piattaforma aziendale di Google Cloud. L'architettura descritta in questo documento consente di aggiungere controlli aggiuntivi agli elementi di base per proteggere le applicazioni serverless.

Per definire i controlli di sicurezza chiave relativi alle applicazioni serverless, 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 risolvere i rischi pertinenti ai vari casi d'uso descritti in questo documento.

Casi d'uso serverless

Il progetto supporta i seguenti casi d'uso:

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

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

Per ulteriori informazioni sulle differenze tra Cloud Run e Cloud Functions, consulta Scelta di un'opzione di computing di Google Cloud.

Architettura

Questo progetto consente di eseguire applicazioni serverless su Cloud Run con un VPC condiviso. Ti consigliamo di usare il VPC condiviso perché centralizza i criteri e il controllo di rete per tutte le risorse di networking. Inoltre, viene eseguito il deployment del VPC condiviso nel progetto di base aziendale.

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

L'architettura per il progetto serverless serverless.

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

  • Un bilanciatore del carico delle applicazioni esterno riceve i dati richiesti dalle applicazioni serverless da internet e li inoltra a Cloud Run. L'Application Load Balancer esterno è un bilanciatore del carico di livello 7.
  • Google Cloud Armor funge da web application firewall per proteggere le tue applicazioni serverless dagli attacchi web e denial of service (DoS).
  • Cloud Run ti consente di eseguire il codice dell'applicazione in container e di gestire l'infrastruttura per tuo conto. In questo progetto, l'impostazione per il traffico in entrata di Cloud Load Balancing interno e di Cloud limita l'accesso a Cloud Run in modo che Cloud Run accetti le richieste solo dall'Application Load Balancer esterno.

  • Il connettore di accesso VPC serverless connette la tua applicazione serverless alla rete VPC tramite 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 Protezione della rete Cloud Run. Per maggiori informazioni, consulta la pagina sul confronto dei metodi di configurazione.

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

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

  • Un VPC condiviso ti 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, tra cui la tua 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 dell'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 Service Control VPC senza una rete VPC condiviso. Puoi implementare questa architettura alternativa se utilizzi una topologia hub e spoke.

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

Un'architettura alternativa per il progetto serverless serverless.

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

Struttura organizzativa

Puoi raggruppare le risorse in modo da gestirle 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 ambienti diversi, come bootstrap, comune, produzione, non di produzione (o test) e sviluppo. Questa gerarchia delle risorse si basa sulla gerarchia descritta nel progetto di base aziendale. Puoi eseguire il deployment dei progetti specificati nel progetto nelle seguenti cartelle: Common, Production, Non-production e Dev.

La struttura organizzativa del progetto serverless serverless.

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

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 seguente tabella descrive le cartelle del progetto di base aziendali utilizzate da questo progetto.

Cartella Descrizione
Bootstrap Contiene le risorse necessarie per il deployment del progetto di base aziendale.
Common Contiene servizi centralizzati per l'organizzazione, come il progetto di sicurezza.
Production Contiene progetti con risorse cloud testate e pronte per l'uso da parte dei clienti. In questo progetto, 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 implementazione graduale. In questo progetto, la cartella Non-production contiene il progetto di servizio e il progetto host.
Dev Contiene progetti con risorse cloud in fase di sviluppo. In questo progetto base, la cartella Dev contiene il progetto di servizio e il progetto host.

Puoi modificare i nomi di queste cartelle per allinearle alla struttura delle cartelle della tua organizzazione, ma ti consigliamo di mantenere una struttura simile. Per saperne di più, consulta Struttura organizzativa. Per altre strutture di cartelle, consulta Decidere una gerarchia di risorse per la zona di destinazione Google Cloud.

Progetti

Puoi isolare 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 in entrata del firewall e le eventuali risorse con indirizzi IP interni (come descritto in Connettersi a una rete VPC). Quando utilizzi un VPC condiviso, designi un progetto come progetto host e colleghi a questo progetto uno o più altri progetti di servizio.

Quando applichi il codice Terraform, devi specificare il nome del progetto e il progetto di deployment esegue il deployment dei servizi.
Progetto di servizio Questo progetto include la tua applicazione serverless, Cloud Run e il connettore di accesso VPC serverless. Devi collegare il progetto di servizio al progetto host in modo che possa partecipare alla rete VPC condiviso.

Quando applichi il codice Terraform, devi specificare il nome del progetto. Il progetto 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 tuoi servizi specifici per la sicurezza, come Cloud KMS e Secret Manager.

Quando applichi il codice Terraform, specifichi il nome del progetto e il progetto esegue il deployment di Cloud KMS. Se utilizzi il modulo Secure Cloud Run Harness, viene eseguito anche il deployment di Artifact Registry.

Se esegui il deployment di questo progetto dopo aver eseguito il deployment del progetto di base per la sicurezza, questo è il progetto secret creato dal progetto di base della piattaforma aziendale. Per ulteriori informazioni sui progetti di progetto delle fondazioni aziendali, consulta Progetti.

Se esegui il deployment di più istanze di questo progetto senza il progetto di base della piattaforma aziendale, ogni istanza ha un 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 seguente tabella descrive i suggerimenti dei progetti per i gruppi di utenti e le assegnazioni 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

[email protected]		 Progetto di servizio
Amministratore della sicurezza serverless

[email protected]		 Progetto di sicurezza
Sviluppatore Cloud Run

[email protected]		 Progetto di sicurezza
Utente Cloud Run

[email protected]		 Progetto di servizio

Controlli di sicurezza

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

  • Proteggere l'accesso in base al principio del privilegio minimo, offrendo alle persone solo i privilegi necessari per svolgere le proprie attività.
  • Proteggere le connessioni di rete con la progettazione della segmentazione, i criteri dell'organizzazione e i criteri firewall.
  • Configurazione sicura per ogni 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'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 i file binari e le immagini dei container. Artifact Registry supporta CMEK, per consentirti di criptare il repository usando le tue chiavi di crittografia.

Traffico SSL

Per supportare il traffico HTTPS verso la tua applicazione serverless, devi configurare un certificato SSL per il bilanciatore del carico delle applicazioni esterno. Per impostazione predefinita, viene utilizzato 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 Utilizzo dei certificati SSL gestiti da Google.

Regole di rete e firewall

Le regole firewall virtual private cloud (VPC) controllano il flusso di dati nei perimetri. Puoi creare regole firewall che negano tutto il traffico in uscita, ad eccezione di connessioni specifiche per la porta TCP 443 da 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 di rete utilizzando l'accesso privato Google quando i carichi di lavoro comunicano con le API e i servizi Google.
  • Garantisce di utilizzare solo servizi che supportano i Controlli di servizio VPC.

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

Controlli del perimetro

Come mostrato nel diagramma dell'architettura consigliata, le risorse per l'applicazione serverless vengono posizionate in un perimetro separato. Questo perimetro aiuta a proteggere l'applicazione serverless da accessi ed esfiltrazione di dati non intenzionali.

Criterio di accesso

Per garantire 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, abilita un criterio di accesso per la tua organizzazione Google. Per ulteriori informazioni, consulta Attributi dei livelli di accesso.

Proxy di identità e accesso

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 per la tua applicazione serverless, in modo da poter utilizzare i controlli dell'accesso a livello di applicazione invece di dover fare affidamento su firewall a livello di rete.

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

Per ulteriori informazioni su IAP, consulta la 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 dei compiti, crea 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) che include i ruoli seguenti:

    • roles/run.invoker
    • roles/secretmanager.secretAccessor

    Per maggiori informazioni, consulta Consentire a Cloud Run di accedere a un secret.

  • Un account del connettore di accesso VPC serverless (gcp_sa_vpcaccess) con il ruolo roles/compute.networkUser.

  • Un secondo account del connettore di accesso VPC serverless (cloud_services) con il ruolo roles/compute.networkUser.

    Questi account di servizio per il connettore di accesso VPC serverless sono necessari per consentire al connettore di creare le regole firewall in entrata e in uscita nel progetto host. Per maggiori informazioni, consulta Concedere le autorizzazioni agli account di servizio 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 accesso alle chiavi di crittografia e decriptazione Artifact Registry e CMEK.

Gestione delle chiavi

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

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

Quando applichi la configurazione Terraform, specifichi la località CMEK, che determina la posizione geografica in cui sono archiviate le chiavi. Devi assicurarti che le tue 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 l'archiviazione dei secret che la tua applicazione serverless potrebbe richiedere. Questi secret possono includere chiavi API, nomi utente e password dei database. Per esporre il secret come volume montato, utilizza le variabili volume_mounts e volumes nel modulo principale.

Quando esegui il deployment di questo progetto con il progetto di base della piattaforma aziendale, devi aggiungere i tuoi secret al progetto dei secret prima di applicare il codice Terraform. Il progetto base concederà il ruolo di Secret Manager alla funzione di accesso ai secret di Secret Manager all'account di servizio Cloud Run. Per maggiori informazioni, consulta Utilizzare i secret.

Criteri dell'organizzazione

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

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

Vincolo del criterio 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 le revisioni di un servizio Cloud Run per l'utilizzo di un connettore di accesso VPC serverless e assicurati che le impostazioni in uscita VPC delle revisioni siano impostate in modo da consentire solo intervalli privati. private-ranges-only

Controlli operativi

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

  • Monitora chi accede ai tuoi dati.
  • Assicurati che sia attivo il controllo corretto.
  • Supporta la capacità dei tuoi team operativi e di gestione degli incidenti di rispondere a problemi che potrebbero verificarsi.

Logging

Per soddisfare i requisiti di controllo e ottenere insight sui tuoi progetti, devi configurare l'osservabilità di Google Cloud 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 progetto base possa 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 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 assicurati che includano informazioni su ciò a cui gli amministratori accedono. Per ulteriori informazioni sulle best practice di logging, consulta Controlli del rilevamento.

Monitoraggio e avvisi

Dopo aver eseguito il deployment del progetto base, puoi configurare avvisi per notificare al Centro operativo di sicurezza (SOC) che potrebbe essersi verificato un incidente di sicurezza. Ad esempio, puoi utilizzare gli avvisi per far sapere agli analisti della sicurezza quando è stata modificata un'autorizzazione 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 Installare dashboard di esempio. Per esportare gli avvisi, consulta i seguenti documenti:

Debug e risoluzione dei problemi

Puoi eseguire test di connettività per eseguire il debug dei problemi di configurazione della 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à risorsa-risorsa.

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

Controlli di rilevamento

Questa sezione descrive i controlli di rilevamento inclusi nel progetto.

Google Cloud Armor e WAF

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

Puoi configurare le regole Google Cloud Armor descritte nella seguente tabella per proteggere l'applicazione serverless. Le regole sono pensate per ridurre i 10 rischi principali di OWASP.

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

Quando queste regole sono abilitate, Google Cloud Armor nega automaticamente qualsiasi traffico corrispondente alla regola.

Per ulteriori informazioni su queste regole, consulta Ottimizzare le regole WAF preconfigurate di Google Cloud Armor.

Rilevamento dei problemi di sicurezza in Cloud Run

Puoi rilevare potenziali problemi di sicurezza in Cloud Run utilizzando il motore per suggerimenti. Il motore per suggerimenti è in grado di rilevare problemi di sicurezza quali:

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

Circa un giorno dopo il deployment di Cloud Run, il motore per suggerimenti inizia a fornire risultati e suggerimenti. Il motore per suggerimenti visualizza i risultati e le azioni correttive consigliate nell'elenco di servizi di Cloud Run o nell'hub dei suggerimenti.

Modalità di deployment di Terraform

La tabella seguente descrive come eseguire il deployment di questo progetto e quali moduli Terraform si applicano a ogni modalità di deployment.

Modalità di deployment Moduli Terraform
Esegui il deployment di questo progetto dopo il deployment del progetto di base dell'azienda (consigliato).

Questa opzione esegue il deployment delle risorse per questo progetto nello stesso perimetro dei Controlli di servizio VPC utilizzato dal progetto di base dell'azienda. Per ulteriori informazioni, consulta Come personalizzare Foundation v2.3.1 per il deployment serverless sicuro.

Questa opzione utilizza anche il progetto secret che hai creato quando hai eseguito il deployment del progetto di base dell'azienda.		 Utilizza questi moduli Terraform:
Installa questo progetto senza installare il progetto di base dell'azienda.

Questa opzione richiede la creazione di un perimetro di Controlli di servizio VPC.		 Utilizza questi moduli Terraform:

Riepilogo

Per implementare l'architettura descritta in questo documento:

  1. Esamina il file README per il progetto base e assicurati di soddisfare tutti i prerequisiti.
  2. Crea un certificato SSL da utilizzare con l'Application Load Balancer esterno.
    Se non completi questo passaggio, il progetto utilizza un certificato autofirmato per il deployment del bilanciatore del carico e il browser mostrerà avvisi sulle connessioni non sicure quando tenti di accedere alla tua applicazione serverless.
  3. Nel tuo ambiente di test, esegui il deployment dell'esempio sicuro di Cloud Run per vedere il progetto base in azione. Nell'ambito del processo di test, valuta la possibilità di eseguire le seguenti operazioni:
    1. Utilizza Security Command Center per analizzare i progetti in base a requisiti di conformità comuni.
    2. Sostituisci l'applicazione di esempio con un'applicazione reale ed eseguila in uno scenario di deployment tipico.
    3. Collabora con i team operativi e di progettazione 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 base nel tuo ambiente.

Mappature di conformità

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

Rischio Mitigazione dei progetti Responsabilità dell'Utente
1. Iniezione di dati su eventi della funzione Google Cloud Armor e i bilanciatori del carico delle applicazioni esterni contribuiscono alla protezione dai top 10 OWASP, come descritto in Le migliori 10 opzioni di mitigazione 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 inaccessibile Nessuna IAP e Identity Platform per autenticare gli utenti al servizio
3. Configurazione del deployment serverless non sicuro CMEK con Cloud KMS
 Gestione delle tue chiavi di crittografia
4. Autorizzazioni e ruoli delle funzioni con privilegi in eccesso
  • Account di servizio personalizzato per l'autenticazione del servizio (non l'account di servizio predefinito di Compute Engine)
  • Ruoli IAM con ambito ristretto nell'account di servizio Cloud Run
  • Controlli di servizio VPC per limitare l'ambito di accesso all'API Google Cloud (fornito utilizzando il progetto di base di Google Cloud Enterprise)
 Nessuna
5. Monitoraggio e logging delle funzioni inadeguati Cloud Logging Dashboard e struttura degli avvisi di Cloud Monitoring
6. Dipendenze di terze parti non sicure Nessuna Proteggi la pipeline CI/CD utilizzando la scansione del codice e l'analisi pre-deployment
7. Archiviazione non sicura dei secret dell'applicazione Secret Manager Gestione dei secret nel codice dell'applicazione
8. denial of service ed esaurimento di risorse finanziarie
  • Google Cloud Armor
  • Timeout del servizio Cloud Run (il valore predefinito è 120 secondi)
 Nessuna
9. Manipolazione della logica di business serverless Controlli di servizio VPC per limitare l'ambito di accesso all'API Google Cloud (fornito utilizzando il progetto di base aziendale) Nessuna
10. Gestione errata delle eccezioni e messaggi di errore dettagliati Nessuna Best practice per la programmazione sicura
11. Funzioni obsolete, risorse cloud e trigger di eventi Utilizza le revisioni per ridurre al minimo la superficie di attacco. Le revisioni aiutano a ridurre le probabilità di abilitare accidentalmente un'iterazione precedente e obsoleta di un servizio. Le revisioni consentono inoltre di testare la strategia di sicurezza di una nuova revisione utilizzando i test A/B e gli strumenti di monitoraggio e logging.
  • Infrastructure as Code (IaC) per la gestione delle 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 tra esecuzioni Nessuna Nessuna

Passaggi successivi