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 le funzioni Cloud Run (2ª generazione.). 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:
- Eseguire il deployment di un'architettura serverless utilizzando le funzioni Cloud Run (questo documento)
- Eseguire il deployment di un'architettura serverless utilizzando Cloud Run
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 utilizza un'architettura VPC condiviso in cui le funzioni Cloud Run vengono implementate in un progetto di servizio e possono accedere alle risorse situate in altre reti VPC.
Il seguente diagramma mostra un'architettura di alto livello, che viene ulteriormente descritta nelle architetture di esempio che seguono.
L'architettura mostrata nel diagramma precedente utilizza una combinazione di Google Cloud funzionalità e servizi:
- Le funzioni Cloud Run ti consentono di eseguire funzioni come servizio e gestiscono l'infrastruttura per tuo conto. Per impostazione predefinita, questa architettura esegue il deployment delle funzioni Cloud Run solo con un indirizzo IP interno e senza accesso a internet pubblico.
- L'evento di attivazione è l'evento che attiva le funzioni Cloud Run. Come descritto ulteriormente nelle architetture di esempio, può trattarsi di un evento Cloud Storage, di un intervallo pianificato o di una modifica in BigQuery.
- Artifact Registry archivia i container di origine per l'applicazione Cloud Run Functions.
- La VPC condivisa ti consente di collegare un connettore di accesso VPC serverless nel progetto di servizio al progetto host. Esegui il deployment di una rete VPC condivisa distinta per ogni ambiente (di produzione, non di produzione e di sviluppo). Questo design di rete fornisce l'isolamento della rete tra i diversi ambienti. Una rete VPC condivisa ti consente di gestire centralmente le risorse di rete in una rete comune, delegando al contempo le responsabilità amministrative per il progetto di servizio.
Il connettore di accesso VPC serverless connette la tua 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 alle funzioni Cloud Run 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 VPC condiviso o in un progetto di servizio. Per impostazione predefinita, questo blueprint esegue il deployment dell'accesso VPC serverless nel progetto host VPC condiviso per allinearsi al modello VPC condiviso di centralizzazione delle risorse di configurazione della rete. Per ulteriori informazioni, consulta Confronto dei metodi di configurazione.
Controlli di servizio VPC crea un perimetro di sicurezza che isola le risorse e i servizi delle funzioni Cloud Run impostando l'autorizzazione, i controlli di accesso e il scambio di dati protetti. Questo perimetro è progettato per isolare l'applicazione e i servizi gestiti impostando controlli degli accessi e monitoraggio aggiuntivi e per separare la governance di Google Cloud dall'applicazione. La governance include la gestione delle chiavi e la registrazione.
Il servizio consumer è l'applicazione su cui agiscono le funzioni Cloud Run. Il servizio consumer può essere un server interno o un altro Google Cloud servizio come Cloud SQL. A seconda del tuo caso d'uso, questo servizio potrebbe trovarsi dietro Cloud Next Generation Firewall, in un'altra sottorete, nello stesso progetto di servizio delle funzioni Cloud Run o in un altro progetto di servizio.
Secure Web Proxy è progettato per proteggere il traffico web in uscita, se necessario. Consente di definire criteri flessibili e granulari in base a identità cloud e applicazioni web. Questo blueprint utilizza Secure Web Proxy per i criteri di accesso granulari al traffico web in uscita durante la fase di compilazione delle funzioni Cloud Run. Il blueprint aggiunge un elenco di URL consentiti alla regola del criterio di sicurezza del gateway.
Cloud NAT fornisce la connessione in uscita a internet, se necessario. Cloud NAT supporta la Network Address Translation dell'origine (SNAT) per le risorse di calcolo senza indirizzi IP pubblici. I pacchetti di risposta in entrata utilizzano Network Address Translation di rete (DNAT) di destinazione. Puoi disattivare Cloud NAT se le funzioni Cloud Run non richiedono l'accesso a internet. Cloud NAT implementa il criterio di rete in uscita associato a Secure Web Proxy.
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 le funzioni Cloud Run.
Secret Manager memorizza i secret delle funzioni Cloud Run. Il blueprint monta i secret come volume per fornire un livello di sicurezza superiore rispetto al passaggio dei secret come variabili di ambiente.
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.
Cloud Logging raccoglie tutti i log dei servizi per archiviarli e recuperarli tramite gli strumenti di analisi e indagine. Google Cloud
Cloud Monitoring raccoglie e archivia informazioni e metriche sul rendimento dei serviziGoogle Cloud .
Architettura di esempio con un'applicazione serverless che utilizza Cloud Storage
Il seguente diagramma mostra come puoi eseguire un'applicazione serverless che accede a un server interno quando si verifica un determinato 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 emessa quando qualsiasi risorsa, applicazione o utente cloud 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 inserisce in coda gli eventi che vengono utilizzati come input e attivatore per le funzioni Cloud Run.
- Le regole del firewall Virtual Private Cloud (VPC) controllano il flusso di dati nella sottorete che ospita le tue 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 delle funzioni Cloud Run sicure con esempio di 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 puoi eseguire un'applicazione serverless che accede a un servizio ospitato su Cloud SQL a un intervallo regolare definito in Cloud Scheduler. Puoi utilizzare 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 emessa eventi regolarmente.
- Pub/Sub inserisce in coda gli eventi che vengono utilizzati come input e attivatore per le funzioni Cloud Run.
- Le regole del firewall Virtual Private Cloud (VPC) controllano il flusso di dati nella sottorete 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 a cui l'applicazione serverless può accedere. Se esegui il deployment delle funzioni Cloud Run sicure con l'esempio Cloud SQL, esegui il deployment di un database MySQL con un database di esempio.
Architettura di esempio con il data warehouse BigQuery
Il seguente diagramma mostra come puoi eseguire un'applicazione serverless che viene attivata quando si verifica un evento in BigQuery (ad esempio, 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 Run sicure attivate da BigQuery, esegui il deployment di un set di dati e una tabella BigQuery di esempio.
- Eventarc attiva le funzioni Cloud Run quando si verifica un determinato evento in BigQuery.
Struttura dell'organizzazione
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
.
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. |
Development
|
Contiene progetti con risorse cloud attualmente in fase di sviluppo. In questo blueprint, la cartella Development 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 VPC condiviso | Questo progetto include le regole di ingresso del firewall e eventuali 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, specifica il nome di questo progetto e il blueprint esegue il deployment del connettore di accesso VPC serverless, di Cloud NAT e di Cloud Secure Web Proxy. |
Progetto di servizio VPC condiviso | Questo progetto include l'applicazione serverless, le funzioni 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 delle funzioni e dei servizi Cloud Run 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 blueprint esegue il deployment di Cloud KMS. Se utilizzi il modulo Secure Serverless Harness nel blueprint serverless per le funzioni Cloud Run, viene eseguito il deployment anche di Artifact Registry. |
Progetto di sicurezza | Questo progetto include i 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 blueprint senza il blueprint delle basi dell'enterprise, 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 di funzioni Cloud Run grp-gcp-secure-cloud-run-developer@example.com |
Progetto di sicurezza | |
Utente delle funzioni Cloud Run 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 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 ai principali solo i privilegi necessari per eseguire le attività.
- Connetti le reti in modo sicuro tramite la progettazione di un confine di attendibilità, che include la segmentazione della rete, i criteri dell'organizzazione e i criteri firewall.
- Configurazione sicura per ciascuno dei servizi.
- Identifica eventuali requisiti di conformità o normativi per l'infrastruttura che ospita i carichi di lavoro serverless e assegna un livello di rischio.
- Configura un monitoraggio e un logging sufficienti per supportare gli audit trail per le operazioni di sicurezza e la gestione degli incidenti.
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.
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 l'area 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.
Inoltre, devi creare un record DNS per risolvere *.googleapis.com in restricted.googleapis.com.
Per ulteriori informazioni, consulta Configurare l'accesso privato Google.
Controlli del perimetro
Come mostrato nella sezione Architettura, posiziona le risorse per l'applicazione serverless in un perimetro di sicurezza Controlli di servizio VPC separato. Questo perimetro contribuisce a ridurre l'impatto di un compromesso di sistemi o servizi. Tuttavia, questo perimetro di sicurezza non si applica al processo di compilazione delle funzioni Cloud Run quando Cloud Build crea automaticamente il codice in un'immagine container e esegue il push dell'immagine in Artifact Registry. In questo scenario, crea una regola di ingresso per l'account di servizio Cloud Build nel perimetro del servizio.
Policy di accesso
Per garantire che solo entità (utenti o servizi) specifiche possano accedere alle risorse e ai dati, attiva 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 saperne di più, consulta Attributi del livello di accesso.
Account di servizio e controlli di accesso
Gli account di servizio sono account per applicazioni o carichi di lavoro di calcolo anziché per singoli utenti finali. Per implementare il principio del privilegio minimo e il principio della separazione dei compiti, crea account di servizio con autorizzazioni granulari e accesso limitato alle risorse. Gli account di servizio sono i seguenti:
Un account di servizio Cloud Run Functions (
cloudfunction_sa
) con i seguenti ruoli:- Visualizzatore reti Compute (
roles/compute.networkViewer
) - Eventarc Event Receiver (
roles/eventarc.eventReceiver
) - Cloud Run Invoker (
roles/run.invoker
) - Valutatore dei segreti di Secret Manager (
roles/secretmanager.secretAccessor
)
Per saperne di più, consulta Consentire alle funzioni Cloud Run di accedere a un segreto.
Le funzioni Cloud Run utilizzano questo account di servizio per concedere l'autorizzazione solo a temi Pub/Sub specifici e per limitare il sistema di eventi Eventarc dalle risorse di calcolo delle funzioni Cloud Run nell'architettura di esempio con un'applicazione serverless che utilizza Cloud Storage e nell'architettura di esempio con il data warehouse BigQuery.
- Visualizzatore reti Compute (
Un account connettore di accesso VPC serverless (
gcp_sa_vpcaccess
) con il ruolo Utente della rete di calcolo (roles/compute.networkUser
).Un secondo account connettore di accesso VPC serverless (
cloud_services
) che ha il ruolo Utente della rete Compute (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 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 funzioni Cloud Run (
cloudfunction_sa
) che dispone dei ruoli [Utente con 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 della rete Compute (roles/compute.networkUser
) per eseguire per tuo conto i processi interni di Google.Un'identità di servizio per le funzioni Cloud Run (
cloud_serverless_sa
) con il ruolo Lettura registry degli elementi (roles/artifactregistry.reader
). Questo account di servizio fornisce l'accesso ad Artifact Registry e ai CMEK.Un'identità di servizio per Eventarc (
eventarc_sa
) con i ruoli Cloud KMS CryptoKey Decrypter (roles/cloudkms.cryptoKeyDecrypter) e Cloud KMS CryptoKey Encrypter (roles/cloudkms.cryptoKeyEncrypter
).Un'identità di servizio per Artifact Registry (
artifact_sa
) con i ruoli Autore decrittografia CryptoKey (roles/cloudkms.cryptoKeyDecrypter
) e Autore crittografia CryptoKey Cloud KMS (roles/cloudkms.cryptoKeyEncrypter
).
Gestione delle chiavi
Per convalidare l'integrità e contribuire a proteggere i dati at-rest, utilizza le chiavi CMEK con Artifact Registry, le funzioni Cloud Run, Cloud Storage e Eventarc. Le chiavi CMEK ti offrono un maggiore controllo sulla chiave di crittografia. Vengono utilizzati i seguenti CMEK:
- 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 eseguono il deployment le funzioni Cloud Run.
- Una chiave di crittografia per gli eventi Eventarc che cripta il canale di messaggistica in stato di riposo.
- Una chiave di crittografia per contribuire a proteggere i dati in Cloud Storage.
Quando applichi la configurazione Terraform, specifica la posizione del CMK, che determina la posizione geografica in cui vengono archiviate le chiavi. Devi assicurarti che i tuoi CMEK si trovino nella stessa regione delle risorse. Per impostazione predefinita, i CMEK vengono ruotati ogni 30 giorni.
Gestione di secret
Le funzioni Cloud Run supportano 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 oggetto service_configs
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 di valutatore dei secret di Secret Manager (roles/secretmanager.secretAccessor
) all'account di servizio delle funzioni Cloud Run. Per ulteriori informazioni, consulta la sezione Utilizzare i secret.
Criteri dell'organizzazione
Questo progetto di fondazione aggiunge vincoli ai vincoli dei criteri dell'organizzazione utilizzati dal progetto di fondazione di un'azienda. 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 che sono definiti nel modulo Sicurezza delle funzioni Cloud Run di questo blueprint.
Vincolo delle norme | Descrizione | Valore consigliato |
---|---|---|
Impostazioni di traffico in entrata consentite
(funzioni Cloud Run)
constraints/cloudfunctions.allowedIngressSettings |
Consenti il traffico in entrata solo dai servizi interni o dal bilanciatore del carico HTTP(S) esterno.
Il valore predefinito è |
ALLOW_INTERNAL_ONLY
|
Richiedi Connettore VPC (funzioni Cloud Run)
constraints/cloudfunctions.requireVPCConnector |
Richiedi di specificare un connettore di accesso VPC serverless durante 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
(funzioni Cloud Run)
cloudfunctions.allowedVpcConnectorEgressSettings |
Richiedi che tutto il traffico in uscita per le funzioni Cloud Run utilizzi un connettore di accesso VPC serverless.
Il valore predefinito è |
ALL_TRAFFIC
|
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 l'accesso ai dati.
- Assicurati che sia stato implementato un controllo adeguato.
- Supportare le operazioni di sicurezza e le funzionalità di gestione degli incidenti della tua organizzazione.
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.
- Aggiungi i CMEK al tuo sink di logging.
Per tutti i servizi all'interno dei progetti, assicurati che i log includano informazioni su scrittura dei dati e accesso amministrativo. Per ulteriori informazioni sulle best practice per la registrazione, consulta la sezione Controlli di rilevamento.
Monitoraggio e avvisi
Dopo aver implementato il blueprint, puoi configurare avvisi per notificare al tuo Centro operativo di sicurezza (SOC) che si è verificato un evento 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 delle funzioni Cloud Run ti aiuta a monitorare le prestazioni e l'integrità delle funzioni Cloud Run. Fornisce una serie 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 il rendimento delle funzioni, ad esempio la possibilità di impostare avvisi e quote.
Per ulteriori informazioni, consulta Monitoraggio delle funzioni Cloud Run.
Per esportare gli avvisi, consulta i seguenti documenti:
Debug e risoluzione dei problemi
Puoi eseguire test di connettività per aiutarti a eseguire il debug dei problemi di configurazione di rete tra le funzioni 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, consulta Creare ed eseguire test di connettività.
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 v3.0.0 per il deployment di funzioni Cloud Run sicure. Questa opzione utilizza anche il progetto di 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 sicurezza di base. 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:
- Esamina il README del blueprint per assicurarti di soddisfare tutti i prerequisiti.
- Nell'ambiente di test, per vedere il blueprint in azione, esegui il deployment di uno degli esempi.
Questi esempi corrispondono a quelli descritti nella sezione Architettura.
Nell'ambito della procedura di test, ti consigliamo di procedere nel seguente modo:
- Utilizza Security Command Center per eseguire la scansione dei progetti in base ai 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 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.
- Esegui il deployment del progetto nel tuo ambiente.
Passaggi successivi
- Esamina il Google Cloud progetto di fondazione di un'azienda per un ambiente sicuro di riferimento.
- Per visualizzare i dettagli del blueprint, leggi il file README della configurazione di Terraform.
- Per eseguire il deployment di un'applicazione serverless utilizzando Cloud Run, consulta Eseguire il deployment di un'architettura serverless sicura utilizzando Cloud Run.