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 Functions (2a generazione). 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:
- Deployment di un'architettura serverless utilizzando Cloud Functions (questo documento)
- Deployment di un'architettura serverless tramite Cloud Run
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 utilizza un'architettura VPC condiviso, in cui viene eseguito il deployment di Cloud Functions in un progetto di servizio e può accedere a risorse che si trovano in altre reti VPC.
Il seguente diagramma mostra un'architettura di alto livello, ulteriormente descritta nelle architetture di esempio che la seguono.
L'architettura mostrata nel diagramma precedente utilizza una combinazione dei seguenti servizi e funzionalità di Google Cloud:
- Cloud Functions consente di eseguire Functions as a Service e gestire l'infrastruttura per conto tuo. Per impostazione predefinita, questa architettura esegue il deployment di Cloud Functions solo con un indirizzo IP interno e senza accesso alla rete internet pubblica.
- L'evento di trigger è l'evento che attiva le funzioni Cloud Functions. Come descritto in maggiore dettaglio nelle architetture di esempio, può trattarsi di un evento di Cloud Storage, di un intervallo pianificato o di una modifica in BigQuery.
- Artifact Registry archivia i container di origine per la tua applicazione Cloud Functions.
- Un VPC condiviso ti consente di connettere un connettore di accesso VPC serverless nel progetto di servizio al progetto host. Esegui il deployment di una rete VPC condiviso separata per ogni ambiente (produzione, non produzione e sviluppo). Questa progettazione di rete fornisce l'isolamento di rete tra i diversi ambienti. Una rete VPC condiviso consente di gestire centralmente le risorse di rete in una rete comune delega le responsabilità amministrative per il progetto di servizio.
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 Functions di comunicare con altri servizi, sistemi di archiviazione e risorse che supportano i Controlli di servizio VPC.
Puoi configurare l'accesso VPC serverless nel progetto host del VPC condiviso o in un progetto di servizio. Per impostazione predefinita, questo progetto esegue il deployment dell'accesso VPC serverless nel progetto host del VPC condiviso per allinearsi al modello VPC condiviso che centralizza le risorse di configurazione di rete. Per maggiori informazioni, consulta la pagina sul confronto dei metodi di configurazione.
Controlli di servizio VPC crea un perimetro di sicurezza che isola i servizi e le risorse Cloud Functions configurando le autorizzazioni, i controlli dell'accesso e lo scambio sicuro dei dati. Questo perimetro è progettato per isolare le applicazioni e i servizi gestiti impostando controlli e monitoraggio dell'accesso aggiuntivi e per separare la governance di Google Cloud dall'applicazione. La governance include la gestione delle chiavi e il logging.
Il servizio consumer è l'applicazione su cui si basa Cloud Functions. Il servizio consumer può essere un server interno o un altro servizio Google Cloud come Cloud SQL. A seconda del caso d'uso, questo servizio potrebbe essere protetto da Cloud Next Generation Firewall, in un'altra subnet, nello stesso progetto di servizio di Cloud Functions o in un altro progetto di servizio.
Secure Web Proxy è progettato per proteggere il traffico web in uscita, se necessario. Garantisce criteri flessibili e granulari basati su identità cloud e applicazioni web. Questo progetto utilizza Secure Web Proxy per criteri di accesso granulari al traffico web in uscita durante la fase di creazione di Cloud Functions. Il progetto aggiunge un elenco consentito di URL alla regola del criterio di sicurezza del gateway.
Cloud NAT fornisce la connessione in uscita a internet, se necessario. Cloud NAT supporta la traduzione SNAT (Network Address Translation) di origine per le risorse di calcolo senza indirizzi IP pubblici. I pacchetti di risposta in entrata utilizzano DNAT (Network Address Translation). Puoi disabilitare Cloud NAT se Cloud Functions non richiede l'accesso a internet. Cloud NAT implementa il criterio di rete in uscita collegato a Secure Web Proxy.
Cloud Key Management Service (Cloud KMS) archivia le chiavi di crittografia gestite dal cliente (CMEK) utilizzate dai servizi in questo progetto base, tra cui la tua applicazione serverless, Artifact Registry e Cloud Functions.
Secret Manager archivia i secret di Cloud Functions. Il progetto monta i secrets come volume per fornire un livello di sicurezza maggiore rispetto al passaggio dei secret come variabili di ambiente.
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.
Cloud Logging raccoglie tutti i log dai servizi Google Cloud per l'archiviazione e il recupero da parte degli strumenti di analisi e indagine.
Cloud Monitoring raccoglie e archivia informazioni e metriche sulle prestazioni dei servizi Google Cloud.
Architettura di esempio con un'applicazione serverless che utilizza Cloud Storage
Il seguente diagramma mostra come eseguire un'applicazione serverless che accede a un server interno quando si verifica un particolare evento in Cloud Storage.
Oltre ai servizi descritti in Architettura, questa architettura di esempio utilizza una combinazione dei seguenti servizi e funzionalità Google Cloud:
- Cloud Storage emette un evento quando una risorsa cloud, un'applicazione o un utente crea un oggetto web in un bucket.
- Eventarc instrada gli eventi da risorse diverse. Eventarc cripta gli eventi in transito e at-rest.
- Pub/Sub mette in coda gli eventi utilizzati come input e come trigger per Cloud Functions.
- Le regole firewall VPC (Virtual Private Cloud) controllano il flusso di dati nella subnet che ospita le risorse, ad esempio un server interno.
- Il server interno viene eseguito su Compute Engine o Google Kubernetes Engine e ospita la tua applicazione interna. Se esegui il deployment dell'esempio di protezione di Cloud Functions con il server interno, esegui il deployment di un server Apache con una pagina HTML Hello World. Questo esempio simula l'accesso a un'applicazione interna che esegue VM o container.
Architettura di esempio con Cloud SQL
Il seguente diagramma mostra come eseguire un'applicazione serverless che accede a un servizio in hosting su Cloud SQL a un intervallo regolare definito in Cloud Scheduler. Puoi usare questa architettura quando devi raccogliere log, aggregare dati e così via.
Oltre ai servizi descritti in Architettura, questa architettura di esempio utilizza una combinazione dei seguenti servizi e funzionalità Google Cloud:
- Cloud Scheduler emette eventi su base regolare.
- Pub/Sub mette in coda gli eventi utilizzati come input e come trigger per Cloud Functions.
- Le regole firewall VPC (Virtual Private Cloud) controllano il flusso di dati nella subnet che ospita le tue risorse, ad esempio i dati aziendali archiviati in Cloud SQL.
- Il proxy di autenticazione Cloud SQL controlla l'accesso a Cloud SQL.
- Cloud SQL ospita un servizio in peering con la rete VPC e a cui può accedere l'applicazione serverless. Se esegui il deployment dell'esempio di protezione di Cloud Functions con Cloud SQL, esegui il deployment di un database MySQL con un database di esempio.
Architettura di esempio con data warehouse BigQuery
Il seguente diagramma mostra come eseguire un'applicazione serverless che viene attivata quando si verifica un evento in BigQuery (ad esempio quando vengono aggiunti dati o viene creata una tabella).
Oltre ai servizi descritti in Architettura, questa architettura di esempio utilizza una combinazione dei seguenti servizi e funzionalità Google Cloud:
- BigQuery ospita un data warehouse. Se esegui il deployment dell'esempio di funzioni Cloud Functions sicure attivate da BigQuery, esegui il deployment di un set di dati e di una tabella BigQuery di esempio.
- Eventarc attiva Cloud Functions quando si verifica un evento specifico in BigQuery.
Struttura organizzativa
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.
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 essere utilizzate dai 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 base, la cartella Non-production contiene il progetto di servizio e il progetto host. |
Development
|
Contiene progetti con risorse cloud in fase di sviluppo. In questo progetto, la cartella Development 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 VPC condiviso | Questo progetto include le regole in entrata del firewall e le eventuali 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 a questo progetto uno o più altri progetti di servizio. Quando applichi il codice Terraform, specifichi il nome di questo progetto e il progetto esegue il deployment del connettore di accesso VPC serverless, di Cloud NAT e del proxy web sicuro di Cloud. |
| Progetto di servizio VPC condiviso | Questo progetto include la tua applicazione serverless, Cloud Functions 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, specifichi il nome di questo progetto. Il progetto esegue il deployment di Cloud Functions e dei servizi necessari per il tuo caso d'uso, ad esempio Cloud SQL, Cloud Scheduler, Cloud Storage o BigQuery. Quando applichi il codice Terraform, specifichi il nome di questo progetto e il progetto esegue il deployment di Cloud KMS. Se utilizzi il modulo Secure Serverless Harness nel progetto serverless per Cloud Functions, viene eseguito anche il deployment di Artifact Registry. |
| Progetto di sicurezza | Questo progetto include i tuoi servizi specifici per la sicurezza, come Cloud KMS e Secret Manager.
Il nome predefinito del progetto di sicurezza è Se esegui il deployment di più istanze di questo progetto senza il progetto di base della piattaforma aziendale, 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 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 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 Functions grp-gcp-secure-cloud-run-developer@example.com |
Progetto di sicurezza | |
| utente Cloud Functions grp-gcp-secure-cloud-run-user@example.com |
Progetto di servizio VPC condiviso |
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:
- Proteggi l'accesso in base al principio del privilegio minimo, fornendo alle entità solo i privilegi necessari per eseguire le attività.
- Proteggere le connessioni di rete tramite la progettazione dei confini di attendibilità, che include segmentazione della rete, criteri dell'organizzazione e criteri firewall.
- Configurazione sicura per ogni servizio.
- Identifica eventuali requisiti di conformità o normativi per l'infrastruttura che ospita carichi di lavoro serverless e assegna un livello di rischio.
- Configurare monitoraggio e logging sufficienti per supportare audit trail per le operazioni di sicurezza e la gestione degli incidenti.
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.
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.
Inoltre, devi creare un record DNS per risolvere *.googleapis.com a restricted.googleapis.com.
Per ulteriori informazioni, consulta Configurazione dell'accesso privato Google.
Controlli del perimetro
Come mostrato nella sezione Architettura, le risorse per l'applicazione serverless vengono posizionate in un perimetro di sicurezza separato di Controlli di servizio VPC. Questo perimetro aiuta a ridurre l'impatto generale di una compromissione di sistemi o servizi. Tuttavia, questo perimetro di sicurezza non si applica al processo di compilazione di Cloud Functions quando Cloud Build crea automaticamente il codice in un'immagine container e invia l'immagine ad Artifact Registry. In questo scenario, crea una regola in entrata per l'account di servizio Cloud Build nel perimetro di servizio.
Criterio di accesso
Per garantire che solo entità 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 maggiori informazioni, consulta la sezione Attributi dei livelli di accesso.
Account di servizio e controlli dell'accesso
Gli account di servizio sono account per applicazioni o carichi di lavoro di computing anziché per singoli utenti finali. Per implementare il principio del privilegio minimo e il principio della separazione dei compiti, devi creare account di servizio con autorizzazioni granulari e accesso limitato alle risorse. Gli account di servizio sono i seguenti:
Un account di servizio Cloud Functions (
cloudfunction_sa) che include i ruoli seguenti:- Visualizzatore rete Compute (
roles/compute.networkViewer) - Ricevitore evento Eventarc (
roles/eventarc.eventReceiver) - Invoker di Cloud Run (
roles/run.invoker) - Secret Manager Secret Assessor (
roles/secretmanager.secretAccessor)
Per maggiori informazioni, consulta Consentire a Cloud Functions di accedere a un secret.
Cloud Functions utilizza questo account di servizio per concedere l'autorizzazione solo a specifici argomenti Pub/Sub e per limitare il sistema di eventi Eventarc dalle risorse di calcolo di Cloud Functions in Architettura di esempio con un'applicazione serverless che utilizza Cloud Storage e Architettura di esempio con data warehouse BigQuery.
- Visualizzatore rete Compute (
Un account del connettore di accesso VPC serverless (
gcp_sa_vpcaccess) con il ruolo Utente di rete Compute (roles/compute.networkUser).Un secondo account del connettore di accesso VPC serverless (
cloud_services) con il ruolo Utente di rete Compute (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 Functions (
cloudfunction_sa) in cui sono assegnati i ruoli [Utente accesso VPC serverless (roles/vpcaccess.user)](/iam/docs/understanding-roles#vpcaccess.user)e Utente account di servizio (roles/iam.serviceAccountUser)).Un account di servizio per le API di Google (
cloud_services_sa) che dispone del ruolo Utente di rete Compute (roles/compute.networkUser) per eseguire processi interni di Google per tuo conto.Un'identità di servizio per Cloud Functions (
cloud_serverless_sa) con il ruolo di lettore Artifact Registry (roles/artifactregistry.reader). Questo account di servizio fornisce accesso ad Artifact Registry e CMEK.Un'identità di servizio per Eventarc (
eventarc_sa) con i ruoli Autore crittografia CryptoKey Cloud KMS (roles/cloudkms.cryptoKeyDecrypter) e i ruoli Autore crittografia CryptoKey Cloud KMS (roles/cloudkms.cryptoKeyEncrypter).Un'identità di servizio per Artifact Registry (
artifact_sa) con i ruoli Autore crittografia CryptoKey (roles/cloudkms.cryptoKeyDecrypter) e Autore crittografia CryptoKey Cloud KMS (roles/cloudkms.cryptoKeyEncrypter).
Gestione delle chiavi
Per convalidare l'integrità e proteggere i dati at-rest, utilizzi CMEK con Artifact Registry, Cloud Functions, Cloud Storage ed Eventarc. Le CMEK offrono un maggiore controllo sulla chiave di crittografia. Vengono utilizzate le seguenti CMEK:
- 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 Functions.
- Una chiave di crittografia per gli eventi Eventarc che cripta il canale di messaggistica at-rest.
- Una chiave di crittografia per contribuire a proteggere i dati in Cloud Storage.
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 CMEK si trovino nella stessa regione delle risorse. Per impostazione predefinita, le CMEK vengono ruotate ogni 30 giorni.
Gestione di secret
Cloud Functions 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 dell'oggetto service_configs 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 roles/secretmanager.secretAccessor Secret Manager Assessor all'account di servizio Cloud Functions. Per maggiori informazioni, consulta
Utilizzo dei secret.
Criteri dell'organizzazione
Questo progetto aggiunge vincoli ai vincoli dei criteri dell'organizzazione utilizzati dal progetto di base della piattaforma aziendale. Per ulteriori informazioni sui vincoli utilizzati dal progetto di base della piattaforma aziendale, consulta Vincoli dei criteri dell'organizzazione.
La seguente tabella descrive i vincoli aggiuntivi dei criteri dell'organizzazione definiti nel modulo Sicurezza di Secure Cloud Functions di questo progetto base.
| Vincolo del criterio | Descrizione | Valore consigliato |
|---|---|---|
Impostazioni di traffico in entrata consentite
(Cloud Functions)
constraints/cloudfunctions.allowedIngressSettings |
Consenti il traffico in entrata solo da servizi interni o dal bilanciatore del carico HTTP(S) esterno.
Il valore predefinito è |
ALLOW_INTERNAL_ONLY
|
Richiedi il connettore VPC (Cloud Functions)
constraints/cloudfunctions.requireVPCConnector |
È necessario specificare un connettore di accesso VPC serverlesss per eseguire il deployment di una funzione. Quando questo vincolo viene applicato, le funzioni devono specificare un connettore di accesso VPC serverless.
Il valore predefinito è |
true
|
Impostazioni di traffico in uscita del connettore VPC consentite
(Cloud Functions)
cloudfunctions.allowedVpcConnectorEgressSettings |
Richiedono tutto il traffico in uscita per consentire a Cloud Functions di utilizzare un connettore di accesso VPC serverless.
Il valore predefinito è |
ALL_TRAFFIC
|
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 l'accesso ai dati.
- Assicurati che sia attivo il controllo corretto.
- Supporta le operazioni di sicurezza e le funzionalità di gestione degli incidenti della tua organizzazione.
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.
- Aggiungi CMEK al sink di logging.
Per tutti i servizi all'interno dei progetti, assicurati che i log includano informazioni sulle scritture di dati e sull'accesso amministrativo. Per ulteriori informazioni sulle best practice di logging, consulta Controlli di rilevamento.
Monitoraggio e avvisi
Dopo aver eseguito il deployment del progetto base, puoi configurare avvisi per notificare al Centro operativo di sicurezza (SOC) che si è verificato un evento di sicurezza. Ad esempio, puoi utilizzare gli avvisi per far sapere agli analisti della sicurezza quando è stata modificata un'autorizzazione per 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 Functions consente di monitorare le prestazioni e l'integrità delle tue funzioni Cloud Functions. Fornisce una varietà di metriche e log che puoi utilizzare per identificare e risolvere i problemi. La dashboard include anche una serie di funzionalità che possono aiutarti a migliorare le prestazioni delle tue funzioni, come la possibilità di impostare avvisi e quote.
Per ulteriori informazioni, consulta Monitoraggio delle funzioni Cloud Functions.
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 Functions e le risorse all'interno della subnet. Connectivity Tests simula il percorso previsto di un pacchetto e fornisce dettagli sulla connettività, tra cui l'analisi della connettività risorsa-risorsa.
Connectivity Tests non è abilitato dal codice Terraform; devi configurarlo separatamente. Per maggiori informazioni, consulta Creare ed eseguire Connectivity Tests.
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 maggiori informazioni, consulta Come personalizzare Foundation v3.0.0 per il deployment di Secure Cloud Functions. Questa opzione utilizza anche il progetto secret che hai creato quando hai eseguito il deployment del progetto di base della piattaforma aziendale. |
Utilizza questi moduli Terraform: |
Installa questo progetto senza installare il progetto di base per la sicurezza. 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:
- Esamina il file README relativo al progetto base per assicurarti di soddisfare tutti i prerequisiti.
- Nel tuo ambiente di test, per vedere il progetto base in azione, esegui il deployment di uno degli esempi.
Questi esempi corrispondono agli esempi di architettura descritti in Architettura.
Nell'ambito del processo di test, valuta la possibilità di:
- Utilizza Security Command Center per analizzare i progetti in base a requisiti di conformità comuni.
- Sostituisci l'applicazione di esempio con un'applicazione reale (ad esempio 1) ed esegui uno scenario di deployment tipico.
- 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.
- Esegui il deployment del progetto base nel tuo ambiente.
Passaggi successivi
- Esamina il progetto di base per le basi aziendali di Google Cloud per un ambiente sicuro di base.
- Per visualizzare i dettagli del progetto base, leggi il documento README di configurazione Terraform.
- Per eseguire il deployment di un'applicazione serverless utilizzando Cloud Run, consulta Eseguire il deployment di un'architettura serverless protetta utilizzando Cloud Run.