Esegui il deployment di un'architettura serverless sicura utilizzando le funzioni Cloud Run

Last reviewed 2023-08-06 UTC

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:

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 del blueprint serverless che utilizza le funzioni Cloud Run.

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.

Esempio di architettura serverless con 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.

Esempio di architettura serverless con Cloud SQL.

Oltre ai servizi descritti in Architettura, questa architettura di esempio utilizza una combinazione dei seguenti servizi e funzionalità: Google Cloud

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).

Esempio di architettura serverless con BigQuery.

Oltre ai servizi descritti in Architettura, questa architettura di esempio utilizza una combinazione dei seguenti servizi e funzionalità: Google Cloud

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.

La struttura organizzativa del blueprint serverless.

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 è prj-bu1-p-sec. Se esegui il deployment di questo progetto dopo il progetto della piattaforma di sicurezza, il progetto di sicurezza viene creato oltre al progetto dei segreti del progetto della piattaforma di base Enterprise (prj-bu1-p-env-secrets). Per ulteriori informazioni sui progetti della piattaforma di base Enterprise, consulta Progetti.

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:

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_ALL.

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 è false.

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 è PRIVATE_RANGES_ONLY.

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:

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:

  1. Esamina il README del blueprint per assicurarti di soddisfare tutti i prerequisiti.
  2. 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:
    1. Utilizza Security Command Center per eseguire la scansione dei progetti in base ai requisiti di conformità comuni.
    2. Sostituisci l'applicazione di esempio con un'applicazione reale (ad esempio 1) ed esegui uno scenario di deployment tipico.
    3. 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.
  3. Esegui il deployment del progetto nel tuo ambiente.

Passaggi successivi