Le architetture serverless consentono di sviluppare software e servizi senza per eseguire il provisioning o la gestione dei server. Puoi utilizzare le architetture serverless e creare applicazioni per una vasta gamma di servizi.
Questo documento fornisce indicazioni basate su "guida" per i DevOps Engineer, la sicurezza architect e sviluppatori di applicazioni su come proteggere di applicazioni che utilizzano Funzioni di Cloud Run (2ª generazione). Il documento fa parte di un progetto di sicurezza che consiste in quanto segue:
- R Repository GitHub che contiene un set di configurazioni e script Terraform.
- Una guida all'architettura, alla progettazione e ai controlli di sicurezza implementare con il progetto (questo documento).
Anche se puoi eseguire il deployment di questo progetto senza eseguire il deployment Progetto della piattaforma aziendale di Google Cloud questo documento presuppone che tu abbia già configurato un set di base dei controlli di sicurezza, come descritto nei concetti di base aziendali di Google Cloud progetto. L'architettura descritta in questo documento ti aiuta a controlli aggiuntivi sugli elementi di base per aiutarti a proteggere i tuoi server diverse applicazioni.
Aiuta a definire i controlli di sicurezza chiave relativi al serverless applicazioni, Cloud Security Alliance (CSA) pubblicato Principali 12 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:
- Il deployment di un'architettura serverless utilizzando le funzioni di Cloud Run (questo non web)
- Deployment di un'architettura serverless utilizzando Cloud Run
Differenze tra le funzioni di Cloud Run e Cloud Run include:
- 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 come 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à necessaria per eseguire personalmente questi servizi, in modo da avere il controllo del container configurazione.
Per ulteriori informazioni sulle differenze tra Cloud Run e le funzioni di Cloud Run, consulta Scelta di un'opzione di computing Google Cloud.
Architettura
Questo progetto utilizza una VPC condiviso in cui viene eseguito il deployment delle funzioni Cloud Run in un progetto di servizio e possono accedere alle risorse che si trovano in altre reti VPC.
Il seguente diagramma mostra un'architettura generale, che è ulteriormente descritti nelle architetture di esempio che seguono.
L'architettura mostrata nel diagramma precedente utilizza una combinazione di i seguenti servizi e funzionalità di Google Cloud:
- Funzioni di Cloud Run di eseguire Functions as a Service e gestire l'infrastruttura per conto tuo. Per impostazione predefinita, questa architettura esegue il deployment delle funzioni Cloud Run solo un indirizzo IP interno e senza accesso alla rete internet pubblica.
- L'evento di trigger è l'evento che attiva le funzioni di Cloud Run. Come descritto ulteriormente nelle architetture di esempio, un evento di Cloud Storage, un intervallo pianificato o una modifica in BigQuery.
- Artifact Registry e archivia i container di origine per l'applicazione Cloud Run Functions.
- VPC condiviso consente di connettere un connettore di accesso VPC serverless nel tuo servizio al progetto host. Esegui il deployment di un VPC condiviso separato rete per ogni ambiente (di produzione, non di produzione e di sviluppo). Questo progettazione di networking consente di isolare la rete tra i diversi ambienti. R Una rete VPC condiviso consente di gestire centralmente le risorse di rete in rete comune e delega responsabilità amministrative per progetto di servizio.
Il connettore di accesso VPC serverless connette un'applicazione serverless alla tua rete VPC Accesso VPC serverless. L'accesso VPC serverless aiuta a garantire che le richieste la tua applicazione serverless alla rete VPC non è esposta internet. L'accesso VPC serverless consente a Cloud Run di funzionare di comunicare con altri servizi, sistemi di archiviazione e risorse supportano i Controlli di servizio VPC.
Puoi configurare l'accesso VPC serverless un progetto host del VPC condiviso o un progetto di servizio. Per impostazione predefinita, il progetto esegue il deployment dell'accesso VPC serverless nell'host del VPC condiviso per allinearsi al modello VPC condiviso di centralizzazione della rete di configurazione delle risorse. Per ulteriori informazioni, vedi Confronto dei metodi di configurazione.
Controlli di servizio VPC crea un perimetro di sicurezza che isola le funzioni di Cloud Run e risorse mediante la configurazione di autorizzazioni, controlli dell'accesso scambio sicuro di dati. Questo perimetro è progettato per isolare l'applicazione e i servizi gestiti mediante la configurazione di controlli e monitoraggio aggiuntivi dell'accesso e di separare la governance di Google Cloud dall'applicazione. La tua governance include la gestione delle chiavi e il logging.
Il servizio consumer è l'applicazione su cui viene agito le funzioni di Cloud Run. Il servizio consumer può essere un server interno un altro servizio Google Cloud come Cloud SQL. In base per il caso d'uso, questo servizio potrebbe essere protetto da Cloud Next Generation Firewall, in un una subnet, nello stesso progetto di servizio delle funzioni Cloud Run o in in un altro progetto di servizio.
Proxy web sicuro è progettato per proteggere il traffico web in uscita, se necessario. Consente criteri flessibili e granulari basati sulle identità cloud e sul Web diverse applicazioni. Questo progetto utilizza Secure Web Proxy per i criteri di accesso granulari al traffico web in uscita durante la fase di creazione delle funzioni di Cloud Run. Il progetto 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 Network Address Translation (SNAT) di origine per le risorse di computing senza indirizzi IP pubblici. I pacchetti di risposta in entrata utilizzano la destinazione Network Address Translation (DNAT). Puoi disabilitare Cloud NAT se Le funzioni di Cloud Run non richiedono l'accesso a internet. Cloud NAT implementa il criterio di rete in uscita collegato Secure Web Proxy.
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.
Secret Manager e archivia i secret delle funzioni Cloud Run. Lo schema monta segreti come volume per fornire un livello di sicurezza più elevato rispetto alla trasmissione di secret variabili di ambiente.
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 segue il principio del privilegio minimo.
Cloud Logging raccoglie tutti i log dei servizi Google Cloud per l'archiviazione il recupero da parte degli strumenti di analisi e indagine.
Cloud Monitoring raccoglie e archivia le informazioni sulle prestazioni e le metriche relative 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 di archiviazione ideale in Cloud Storage.
Oltre ai servizi descritti in Architettura, questa architettura di esempio utilizza una combinazione dei seguenti Google Cloud di Google Cloud:
- Cloud Storage emette un evento quando qualsiasi risorsa, applicazione o utente cloud crea un in un bucket.
- Eventarc instrada gli eventi da risorse diverse. Eventarc cripta gli eventi in transito e a riposo.
- Pub/Sub accoda gli eventi utilizzati come input e trigger per le funzioni di Cloud Run.
- Regole firewall Virtual Private Cloud (VPC) controllare il flusso di dati nella subnet che ospita le tue risorse, un server interno.
- Il server interno viene eseguito su Compute Engine o Google Kubernetes Engine e che ospita l'applicazione interna. Se esegui il deployment Proteggere le funzioni di Cloud Run con esempio del 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 ospitato da Cloud SQL a intervalli regolari che definita 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 Google Cloud di Google Cloud:
- Cloud Scheduler emette regolarmente eventi.
- Pub/Sub accoda gli eventi utilizzati come input e trigger per le funzioni di Cloud Run.
- Regole firewall Virtual Private Cloud (VPC) controllare il flusso di dati nella subnet che ospita le tue risorse, aziendali archiviati in Cloud SQL.
- Proxy di autenticazione Cloud SQL controlla l'accesso a Cloud SQL.
- Cloud SQL ospita un servizio connesso in peering alla rete VPC e che l'applicazione può accedere. Se esegui il deployment Esempio di protezione delle funzioni di Cloud Run con 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 eseguire un'applicazione serverless attivata quando si verifica un evento in BigQuery (ad esempio, i dati vengono o se viene creata una tabella).
Oltre ai servizi descritti in Architettura, questa architettura di esempio utilizza una combinazione dei seguenti Google Cloud di Google Cloud:
- BigQuery un data warehouse. Se esegui il deployment Esempio di funzioni sicure di Cloud Run attivate da BigQuery, esegui il deployment di un set di dati e di una tabella BigQuery di esempio.
- Eventarc attiva le funzioni Cloud Run quando si verifica un determinato evento in BigQuery.
Struttura organizzativa
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.
Questo diagramma viene descritto in maggiore dettaglio nelle sezioni seguenti.
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, come in un progetto di sicurezza. |
Production
|
Contiene progetti con risorse cloud che sono state
testate e sono pronte per essere
utilizzate dai clienti. In questo progetto,
La cartella Production contiene il progetto di servizio e l'host
progetto. |
Non-production
|
Contiene progetti che dispongono di risorse cloud attualmente
in fase di test e in fase di implementazione graduale per il rilascio. In questo progetto,
La cartella Non-production contiene il progetto di servizio
progetto host. |
Development
|
Contiene progetti che dispongono di risorse cloud attualmente
in fase di sviluppo. In questo progetto, Development
contenente il progetto di servizio e il 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 manterrai una struttura di progetti simile.
| Progetto | Descrizione |
|---|---|
| Progetto host VPC condiviso | Questo progetto include le regole firewall in entrata e qualsiasi 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 di collegare uno o più altri progetti di servizio. Quando applichi il codice Terraform, specifichi il nome che esegue il deployment Connettore di accesso VPC serverless, Cloud NAT e Cloud Secure Web Proxy. |
| Progetto di servizio VPC condiviso | Questo progetto include la tua applicazione serverless, Funzioni di Cloud Run e accesso VPC serverless di rete. Collega il progetto di servizio progetto host in modo che il progetto di servizio possa partecipare Rete VPC condiviso. Quando applichi il codice Terraform, specifichi il nome progetto. Il progetto esegue il deployment di funzioni e servizi Cloud Run necessari per il tuo caso d'uso, come Cloud SQL, Cloud Scheduler, Cloud Storage o in BigQuery. Quando applichi il codice Terraform, specifichi il nome e il progetto esegue il deployment di Cloud KMS. Se utilizzi Sicuro Serverless Harness nel progetto serverless per Viene eseguito anche il deployment di Artifact Registry delle funzioni Cloud Run. |
| 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 progetto senza del modello di base aziendale, ogni istanza ha una propria sicurezza progetto. |
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 modo che corrispondano a quelli della tua organizzazione struttura esistente, ma ti consigliamo di mantenere una separazione simile delle le mansioni e l'assegnazione del ruolo.
| 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 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 aiutarti a proteggere la tua architettura serverless. I principi di sicurezza fondamentali per sono i seguenti:
- Proteggere l'accesso secondo il principio del privilegio minimo, offrendo a cui applicassero solo i privilegi necessari per eseguire le attività.
- Proteggi le connessioni di rete mediante la progettazione di confini di attendibilità, che include segmentazione della rete, criteri dell'organizzazione e criteri firewall.
- Configurazione sicura per ogni servizio.
- Identificare eventuali requisiti normativi o di conformità per che ospita 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.
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 può criptare il repository usando le tue chiavi di crittografia.
Regole firewall e di rete
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.
- Garantisce di utilizzare solo i servizi che supportano i Controlli di servizio VPC.
Inoltre, devi creare un record DNS per risolvere Da*.googleapis.com a restricted.googleapis.com.
Per ulteriori informazioni, vedi Configurazione dell'accesso privato Google.
Controlli del perimetro
Come mostrato in Architettura inserisci le risorse per l'applicazione serverless in una sezione Perimetro di sicurezza Controlli di servizio VPC. Questo perimetro aiuta a ridurre un grande impatto derivante da una compromissione di sistemi o servizi. Tuttavia, questo token di sicurezza non si applica Processo di compilazione di Cloud Run Functions quando Cloud Build crea automaticamente il codice in un'immagine container esegue il push dell'immagine in Artifact Registry. In questo scenario, crea un'istanza 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 le risorse e i dati, abilita i gruppi e i ruoli IAM.
Per assicurarti che solo risorse specifiche possano accedere ai progetti, puoi abilitare un criteri di accesso della tua organizzazione Google. Per ulteriori informazioni, vedi Attributi del livello di accesso.
Account di servizio e controlli dell'accesso
Gli account di servizio sono account per applicazioni o carichi di lavoro di computing per i singoli utenti finali. Per implementare il principio del privilegio minimo e il principio della separazione dei compiti, crei account di servizio con autorizzazioni e accesso limitato alle risorse. Gli account di servizio sono che segue:
Un account di servizio Cloud Run Functions (
cloudfunction_sa) che ricopre i seguenti ruoli:- Visualizzatore di rete Compute (
roles/compute.networkViewer) - Ricevitore eventi Eventarc (
roles/eventarc.eventReceiver) - Invoker di Cloud Run (
roles/run.invoker) - Secret Manager Secret Manager (
roles/secretmanager.secretAccessor)
Per ulteriori informazioni, vedi Consenti alle funzioni di Cloud Run di accedere a un secret.
Le funzioni di Cloud Run utilizzano questo account di servizio per concedere l'autorizzazione a solo argomenti Pub/Sub specifici e di limitare Sistema di eventi Eventarc dal computing di Cloud Run di risorse in Architettura di esempio con un'applicazione serverless che utilizza Cloud Storage e Esempio di architettura con il data warehouse BigQuery.
- Visualizzatore di rete Compute (
Un account connettore di accesso VPC serverless (
gcp_sa_vpcaccess) con Utente di rete Compute (roles/compute.networkUser) ruolo.Un secondo account connettore di accesso VPC serverless (
cloud_services) che ha il ruolo Utente di rete Compute (roles/compute.networkUser).Questi account di servizio per l'accesso VPC serverless in modo che possa creare il firewall. regole in entrata e 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 le funzioni di Cloud Run (
cloudfunction_sa) che ha [Utente accesso VPC serverless (roles/vpcaccess.user)](/iam/docs/understanding-roles#vpcaccess.user)e ai Utente account di servizio (roles/iam.serviceAccountUser) ruoli.R account di servizio per le API di Google (
cloud_services_sa) che contiene l'utente di rete Compute (roles/compute.networkUser) per eseguire processi interni di Google sul tuo per conto tuo.R identità del servizio per le funzioni Cloud Run (
cloud_serverless_sa) con Ruolo Lettore Artifact Registry (roles/artifactregistry.reader). Questo L'account di servizio fornisce accesso ad Artifact Registry e CMEK.Un'identità di servizio per Eventarc (
eventarc_sa) con Decrittografia CryptoKey Cloud KMS (roles/cloudkms.cryptoKeyDecrypter) e il Criptatore CryptoKey Cloud KMS (roles/cloudkms.cryptoKeyEncrypter).Un'identità di servizio per Artifact Registry (
artifact_sa) con 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, funzioni Cloud Run, Cloud Storage e Eventarc. Le CMEK offrono un maggiore controllo sulle chiave di crittografia. Vengono utilizzate le seguenti CMEK:
- Una chiave software per Artifact Registry che attesti il codice per il tuo in un'applicazione serverless.
- Un chiave di crittografia per criptare le immagini container di cui Cloud Run esegue il deployment.
- Un chiave di crittografia per gli eventi Eventarc che criptano il canale di messaggistica a riposo.
- Un chiave di crittografia per proteggere i dati in Cloud Storage.
Quando applichi la configurazione Terraform, specifichi Posizione CMEK, che determina la posizione geografica in cui sono archiviate le chiavi. Devi assicurati che le CMEK si trovino nella stessa regione delle risorse. Per impostazione predefinita, Le CMEK vengono ruotate ogni 30 giorni.
Gestione di secret
Le funzioni di Cloud Run supportano
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
come volume montato, utilizza le variabili di oggetto service_configs nell'
modulo principale.
Quando esegui il deployment di questo progetto con il progetto delle basi aziendali, devi
aggiungi i tuoi secret al progetto secret prima di applicare il codice Terraform. La
il progetto concederà a Secret Manager Secret Assessor
(roles/secretmanager.secretAccessor) alle funzioni Cloud Run
l'account di servizio. Per ulteriori informazioni, vedi
Utilizzo dei secret.
Criteri dell'organizzazione
Questo progetto aggiunge vincoli vincoli dei criteri dell'organizzazione usati dal progetto base aziendale. 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 definiti Sicurezza delle funzioni di Cloud Run Sicurezza di questo progetto.
| Vincolo del criterio | 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 dalla il bilanciatore del carico HTTP(S) esterno.
Il valore predefinito è |
ALLOW_INTERNAL_ONLY
|
Richiedi il connettore VPC (funzioni Cloud Run)
constraints/cloudfunctions.requireVPCConnector |
Richiedono la specifica di un accesso VPC serverless durante il deployment di una funzione. Quando questo vincolo viene applicate, le funzioni devono specificare Connettore di accesso VPC serverless.
Il valore predefinito è |
true
|
Impostazioni di traffico in uscita del Connettore VPC consentite
(Funzioni Cloud Run)
cloudfunctions.allowedVpcConnectorEgressSettings |
Richiedi tutto il traffico in uscita per le funzioni Cloud Run per utilizzare un'istanza Connettore di accesso VPC serverless.
Il valore predefinito è |
ALL_TRAFFIC
|
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 aiutano per effettuare le seguenti operazioni:
- Monitorare l'accesso ai dati.
- Assicurarsi che sia in atto un adeguato controllo.
- Supporta le operazioni di sicurezza e le funzionalità di gestione degli incidenti del tuo dell'organizzazione.
Logging
Per aiutarti a soddisfare i requisiti di controllo e ottenere informazioni sui tuoi progetti, per configurare Osservabilità di Google Cloud con i log di 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 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 la scrittura dei dati e l'accesso amministrativo. Per ulteriori informazioni sul logging best practice, vedi Controlli di rilevamento.
Monitoraggio e avvisi
Dopo aver eseguito il deployment del progetto base, puoi configurare degli avvisi per informare il team operativo (SOC) che si è verificato un evento di sicurezza. Ad esempio, puoi usa gli avvisi per comunicare agli analisti della sicurezza quando un'autorizzazione è stata modificata un ruolo IAM. Per saperne di più sulla configurazione degli avvisi di Security Command Center, consulta Configurazione delle notifiche sui risultati.
La Dashboard di monitoraggio di Cloud Run Functions e ti aiuta a monitorare le prestazioni e l'integrità delle funzioni Cloud Run. Fornisce una varietà di metriche e log, che puoi utilizzare per identificare e risolvere eventuali problemi. La dashboard include inoltre una serie di funzionalità che migliorare le prestazioni delle funzioni, ad esempio la capacità di e impostare avvisi e quote.
Per ulteriori informazioni, vedi Monitoraggio delle funzioni di 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 di Cloud Run e le risorse all'interno della subnet. Connectivity Tests simula percorso previsto di un pacchetto e fornisce dettagli sulla connettività, tra cui la connettività tra risorse.
Connectivity Tests non è abilitato dal codice Terraform; devi impostare separatamente. Per ulteriori informazioni, vedi Crea ed esegui Connectivity Tests.
Modalità di deployment di Terraform
La tabella seguente descrive i modi in cui puoi 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 aver eseguito il deployment degli elementi di base aziendali progetto (consigliato). 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 Personalizzazione di Foundation v3.0.0 per le funzioni di Secure Cloud Run deployment. Questa opzione utilizza anche il progetto secret che hai creato al momento hai eseguito il deployment del progetto delle basi aziendali. |
Utilizza questi moduli Terraform: |
Installa questo progetto senza installare la sicurezza del progetto di base. 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:
- Esamina il README del progetto per assicurarti di soddisfare tutti i prerequisiti.
- Nel tuo ambiente di test, per vedere il progetto in azione, esegui il deployment
del
esempi.
Questi esempi corrispondono agli esempi di architettura descritti in
Architettura.
Come parte del processo di test, ti consigliamo di procedere come segue:
- Usa Security Command Center per analizzare i progetti rispetto requisiti di conformità.
- Sostituisci l'applicazione di esempio con un'applicazione reale (ad esempio 1) ed esaminare uno scenario di deployment tipico.
- 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.
- Esegui il deployment del progetto nel tuo ambiente.
Passaggi successivi
- Esamina il Progetto della piattaforma aziendale di Google Cloud per un ambiente sicuro di base.
- Per vedere i dettagli del progetto, leggi l'articolo README della configurazione Terraform.
- Per eseguire il deployment di un'applicazione serverless utilizzando Cloud Run, consulta Esegui il deployment di un'architettura serverless sicura utilizzando Cloud Run.