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

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 creare applicazioni per un'ampia gamma di servizi.

Questo documento fornisce indicazioni utili per DevOps Engineer, Security Architect e sviluppatori di applicazioni su come proteggere le applicazioni serverless che utilizzano Cloud Run Functions (2ª generazione). Il documento fa parte di un progetto di sicurezza costituito da quanto segue:

  • Un repository GitHub che contiene un insieme di configurazioni e script Terraform.
  • Una guida all'architettura, alla progettazione e ai controlli di sicurezza che implementi con il progetto (questo documento).

Anche se puoi eseguire il deployment di questo blueprint senza prima eseguire il deployment del Google Cloud blueprint delle basi aziendali, questo documento presuppone che tu abbia già configurato un insieme di base di controlli di sicurezza, come descritto nel blueprint delle basi aziendali Google Cloud . L'architettura descritta in questo documento ti aiuta ad aggiungere controlli aggiuntivi alla tua base per proteggere le tue applicazioni serverless.

Per contribuire a definire i controlli di sicurezza chiave correlati alle applicazioni serverless, la Cloud Security Alliance (CSA) ha pubblicato Top 12 Critical Risks for Serverless Applications. I controlli di sicurezza utilizzati in questo progetto sono progettati per affrontare i rischi pertinenti ai vari casi d'uso descritti in questo documento.

Casi d'uso serverless

Il progetto supporta i seguenti casi d'uso:

Le differenze tra le funzioni Cloud Run e Cloud Run includono quanto segue:

  • Le funzioni Cloud Run vengono attivate da eventi, ad esempio 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.
  • Cloud Run Functions gestisce i container e l'infrastruttura che controllano il server web o il runtime del linguaggio, in modo che tu possa concentrarti sul codice. Cloud Run ti offre la flessibilità di eseguire autonomamente questi servizi, in modo da avere il controllo della configurazione del container.

Per saperne di più sulle differenze tra Cloud Run e Cloud Run Functions, consulta la sezione Scelta di un'opzione di calcolo. Google Cloud

Architettura

Questo blueprint utilizza un'architettura VPC condivisa, in cui le funzioni Cloud Run vengono implementate in un progetto di servizio e possono accedere alle risorse che si trovano in altre reti VPC.

Il seguente diagramma mostra un'architettura di alto livello, descritta in modo più dettagliato negli esempi di architetture che seguono.

L'architettura del progetto serverless che utilizza Cloud Run Functions.

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

  • Cloud Run Functions ti consente di eseguire funzioni come servizio e gestisce l'infrastruttura per tuo conto. Per impostazione predefinita, questa architettura esegue il deployment delle funzioni Cloud Run 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 memorizza i container di origine per l'applicazione Cloud Run Functions.
  • VPC condivisa consente di connettere un connettore di accesso VPC serverless nel progetto di servizio al progetto host. Per ogni ambiente (produzione, non di produzione e sviluppo), viene implementata una rete VPC condiviso separata. Questo progetto di rete fornisce l'isolamento della rete tra i diversi ambienti. Una rete VPC condiviso consente di gestire centralmente le risorse di rete in una rete comune delegando le responsabilità amministrative per il progetto di servizio.

  • Il connettore di accesso VPC serverless connette l'applicazione serverless alla rete VPC utilizzando 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 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 di rete. Per ulteriori informazioni, consulta la sezione Confronto tra i metodi di configurazione.

  • I Controlli di servizio VPC creano un perimetro di sicurezza che isola i servizi e le risorse delle funzioni Cloud Run configurando autorizzazione, controlli dell'accesso e scambio sicuro di dati. Questo perimetro è progettato per isolare l'applicazione e i servizi gestiti configurando controlli degli accessi e monitoraggio aggiuntivi e per separare la governance di Google Cloud dall'applicazione. La tua 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 subnet, 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 basati su identità cloud e applicazioni web. Questo blueprint utilizza Secure Web Proxy per criteri di accesso granulari al traffico web in uscita durante la fase di build delle funzioni Cloud Run. Il blueprint aggiunge un elenco consentito di URL alla regola dei criteri 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 destinazione (DNAT). Puoi disattivare Cloud NAT se Cloud Run 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) memorizza le chiavi di crittografia gestite dal cliente (CMEK) utilizzate dai servizi in questo progetto, inclusi l'applicazione serverless, Artifact Registry e le funzioni Cloud Run.

  • Secret Manager memorizza i secret di Cloud Run Functions. 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 consentono di limitare l'accesso e isolare le risorse. I controlli di 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 le informazioni sul rendimento e le metriche 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 evento specifico 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 genera 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 accoda gli eventi utilizzati come input e trigger per le funzioni Cloud Run.
  • Le regole firewall di Virtual Private Cloud (VPC) controllano il flusso di dati nella subnet che ospita le tue risorse, ad esempio un server interno.
  • Il server interno viene eseguito su Compute Engine o Google Kubernetes Engine e ospita l'applicazione interna. Se esegui il deployment di Secure Cloud Run functions with Internal Server Example, 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 Cloud SQL a intervalli regolari definiti 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 eseguire un'applicazione serverless che viene attivata quando si verifica un evento in BigQuery (ad esempio, vengono aggiunti dati o viene creata una tabella).

Architettura serverless di esempio 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 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, common, produzione, non di produzione (o test) e sviluppo. Questa gerarchia delle risorse si basa su quella descritta nel progetto di fondazione di un'azienda. Esegui il deployment dei progetti specificati dal progetto base nelle seguenti cartelle: Common, Production, Non-production e Dev.

La struttura dell'organizzazione per il progetto serverless.

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

Cartelle

Utilizzi le cartelle per isolare l'ambiente di produzione e i servizi di governance dagli ambienti di test e non di produzione. La seguente tabella descrive le cartelle del blueprint delle fondamenta dell'impresa utilizzate da questo blueprint.

Cartella Descrizione
Bootstrap Contiene le risorse necessarie per il deployment del blueprint delle fondamenta dell'impresa.
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 cartella Production contiene il progetto di servizio e il progetto host.
Non-production Contiene progetti con risorse cloud attualmente in fase di test e preparazione per il rilascio. In questo blueprint, 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 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, vedi Scegliere una gerarchia delle risorse per la tua Google Cloud landing zone.

Progetti

Isola le risorse nel tuo ambiente utilizzando i progetti. La tabella seguente 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 tutte le risorse con indirizzi IP interni (come descritto in Connettersi a una rete VPC). Quando utilizzi un VPC condiviso, designi un progetto come progetto host e colleghi uno o più altri progetti di servizio.

Quando applichi il codice Terraform, specifichi 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 del VPC condiviso

Questo progetto include l'applicazione serverless, le funzioni Cloud Run e il connettore di accesso VPC serverless. Collega 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 blueprint esegue il deployment di funzioni e servizi Cloud Run necessari per il tuo caso d'uso, come 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 progetto iniziale serverless per le funzioni Cloud Run, viene eseguito il deployment anche 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 è prj-bu1-p-sec. Se esegui il deployment di questo blueprint dopo aver eseguito il deployment del blueprint delle basi della sicurezza, il progetto di sicurezza viene creato in aggiunta al progetto dei secret del blueprint delle basi dell'impresa (prj-bu1-p-env-secrets). Per maggiori informazioni sui progetti del blueprint delle basi dell'impresa, consulta Progetti.

Se implementi più istanze di questo blueprint senza il blueprint delle fondamenta aziendali, 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 tabella seguente descrive i consigli per i gruppi di utenti e le assegnazioni di 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 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 del VPC condiviso

Controlli di sicurezza

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

  • Accesso sicuro in base al principio del privilegio minimo, che concede alle entità solo i privilegi necessari per svolgere le attività.
  • Proteggi le connessioni di rete tramite la progettazione del perimetro di attendibilità, che include la segmentazione della rete, le policy dell'organizzazione e le policy firewall.
  • Configurazione sicura per ciascun servizio.
  • 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 una registrazione 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 file binari. Artifact Registry supporta CMEK, in modo che tu possa 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 firewall che negano tutto il traffico in uscita, ad eccezione di connessioni specifiche alla porta TCP 443 da nomi di dominio speciali restricted.googleapis.com. L'utilizzo del dominio restricted.googleapis.com presenta i seguenti vantaggi:

  • Consente di ridurre la superficie di attacco della rete utilizzando l'accesso privato Google quando i workload comunicano con le API e i servizi Google.
  • Assicura che utilizzi solo i servizi che supportano i Controlli di servizio VPC.

Inoltre, crei un record DNS per risolvere *.googleapis.com in restricted.googleapis.com.

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

Controlli perimetrali

Come mostrato nella sezione Architettura, inserisci le risorse per l'applicazione serverless in un perimetro di sicurezza Controlli di servizio VPC separato. Questo perimetro contribuisce a ridurre l'impatto ampio di una compromissione di sistemi o servizi. Tuttavia, questo perimetro di sicurezza non si applica al processo di build di Cloud Run Functions quando Cloud Build crea automaticamente il codice in un'immagine container ed esegue il push di questa immagine in Artifact Registry. In questo scenario, crea una regola di ingresso per il account di servizio Cloud Build nel perimetro di servizio.

Policy di accesso

Per contribuire a garantire che solo determinati principal (utenti o servizi) possano accedere a risorse e dati, devi attivare i gruppi e i ruoli IAM.

Per garantire che solo risorse specifiche possano accedere ai progetti, devi attivare un criterio di accesso per la tua organizzazione Google. Per saperne di più, consulta Attributi del livello di accesso.

Service account e controlli dell'accesso

I service account sono account per applicazioni o workload di computing anziché per singoli utenti finali. Per implementare il principio del privilegio minimo e il principio della separazione dei compiti, crea service account con autorizzazioni granulari e accesso limitato alle risorse. I service account sono i seguenti:

Gestione delle chiavi

Per convalidare l'integrità e contribuire a proteggere i dati at-rest, utilizzi le CMEK con Artifact Registry, le funzioni Cloud Run, Cloud Storage ed Eventarc. Le chiavi CMEK ti offrono un maggiore controllo sulla tua chiave di crittografia. Vengono utilizzate le seguenti chiavi 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 viene eseguito il deployment da Cloud Run Functions.
  • Una chiave di crittografia per gli eventi Eventarc che cripta il canale di messaggistica a riposo.
  • Una chiave di crittografia per proteggere i dati in Cloud Storage.

Quando applichi la configurazione Terraform, specifichi la posizione CMEK, che determina la posizione geografica in cui vengono archiviate le chiavi. Devi assicurarti che i CMEK si trovino nella stessa regione delle risorse. Per impostazione predefinita, le chiavi CMEK vengono ruotate ogni 30 giorni.

Gestione di secret

Cloud Run Functions supporta 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 secret come volume montato, utilizza le variabili dell'oggetto service_configs nel modulo principale.

Quando esegui il deployment di questo blueprint con il blueprint delle fondamenta aziendali, devi aggiungere i tuoi secret al progetto dei secret prima di applicare il codice Terraform. Il blueprint concederà il ruolo Secret Manager Secret Assessor (roles/secretmanager.secretAccessor) aaccount di serviziont Cloud Run Functions. Per saperne di più, consulta la sezione Utilizzo dei secret.

Criteri dell'organizzazione

Questo progetto aggiunge vincoli ai vincoli dei criteri dell'organizzazione utilizzati dal progetto di fondazione di un'azienda. Per saperne di più sui vincoli utilizzati dal progetto delle fondamenta aziendali, consulta la pagina Vincoli delle policy dell'organizzazione.

La tabella seguente descrive i vincoli aggiuntivi dei criteri dell'organizzazione definiti nel modulo Sicurezza di Cloud Run Functions protette di questo blueprint.

Vincolo dei criteri Descrizione Valore consigliato
Impostazioni di traffico in entrata consentite (Cloud Run 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_ALL.

 ALLOW_INTERNAL_ONLY
Richiede Connettore VPC (Cloud Run Functions) constraints/cloudfunctions.requireVPCConnector

Richiedi la specifica di 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 (Cloud Run Functions) 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 la registrazione e le funzionalità del livello Premium di Security Command Center, come l'analisi dello stato della sicurezza e il rilevamento delle minacce. Questi controlli ti aiutano a eseguire le seguenti operazioni:

  • Monitorare l'accesso ai dati.
  • Assicurati che sia in atto 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 dettagliate sui tuoi progetti, puoi configurare Google Cloud Observability 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 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 sulle scritture di dati e sull'accesso amministrativo. Per saperne di più sulle best practice per la registrazione, consulta Controlli di rilevamento.

Monitoraggio e avvisi

Dopo aver eseguito il deployment del blueprint, puoi configurare gli avvisi per comunicare al tuo Centro operativo di sicurezza che si è verificato un evento di sicurezza. Ad esempio, puoi utilizzare gli avvisi per comunicare ai tuoi analisti della sicurezza quando un'autorizzazione è stata modificata in un ruolo IAM. Per ulteriori informazioni sulla configurazione degli avvisi di Security Command Center, vedi Configurare le notifiche dei risultati.

La dashboard di monitoraggio di Cloud Run Functions consente di monitorare le prestazioni e l'integrità delle tue Cloud Run Functions. 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 tue funzioni, ad esempio la possibilità di impostare avvisi e quote.

Per ulteriori informazioni, consulta Monitoraggio di Cloud Run Functions.

Per esportare gli avvisi, consulta i seguenti documenti:

Debug e risoluzione dei problemi

Puoi eseguire i test di connettività per eseguire il debug dei problemi di configurazione di rete tra le funzioni Cloud Run e le risorse all'interno della subnet. Connectivity Tests simula il percorso previsto di un pacchetto e fornisce dettagli sulla connettività, inclusa l'analisi della connettività da risorsa a risorsa.

Connectivity Tests non è abilitato dal codice Terraform. Devi configurarlo separatamente. Per saperne di più, vedi 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 quali moduli Terraform si applicano a ciascuna 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 fondazioni aziendali. Per ulteriori informazioni, consulta Come personalizzare Foundation v3.0.0 per il deployment sicuro di Cloud Run Functions.

Questa opzione utilizza anche il progetto dei secret che hai creato quando hai eseguito il deployment del blueprint delle fondamenta dell'impresa.

 Utilizza questi moduli Terraform:

Installa questo progetto senza installare il progetto delle piattaforme di sicurezza.

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 progetto 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 di architettura descritti in Architettura. Nell'ambito del processo di test, valuta la possibilità 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) e segui uno scenario di deployment tipico.
    3. Collabora con i team di ingegneria e operazioni 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