Nota

Proteggi le tue applicazioni utilizzando OCI Network Firewall e OCI WAF Edge con Let's Encrypt Certificates

Introduzione

In uno scenario dominato dalla trasformazione digitale pervasiva, garantire la sicurezza delle tue applicazioni non è solo una considerazione, ma una priorità senza compromessi. Man mano che le organizzazioni migrano i propri carichi di lavoro su Oracle Cloud Infrastructure (OCI), diventa indispensabile una solida strategia di difesa contro le minacce informatiche. OCI fornisce una suite completa di strumenti per rafforzare le tue applicazioni e in questa esercitazione ti guideremo attraverso il processo di protezione degli asset digitali utilizzando OCI Network Firewall e OCI Web Application Firewall (WAF).

Perché questo tutorial è essenziale?

Mentre le tue applicazioni comunicano con il mondo esterno, affrontano la sfida sempre presente delle minacce alla sicurezza informatica. Questa esercitazione consente di creare una difesa su più livelli, proteggendo le applicazioni dalle minacce note ed emergenti sfruttando la potenza di OCI Network Firewall e OCI WAF edge. Esploreremo concetti importanti, tra cui il supporto multi-dominio e la generazione o il rinnovo di certificati X.509 utilizzando strumenti standard. Inoltre, analizzeremo l'uso del servizio gratuito e ampiamente riconosciuto Let's Encrypt. Attraverso questo, otterrai una comprensione completa delle pratiche essenziali per proteggere le tue applicazioni.

Per chi è questo tutorial?

Questa esercitazione è stata progettata per architetti cloud, professionisti della sicurezza e sviluppatori che desiderano una comprensione completa delle funzioni di sicurezza di Oracle Cloud Infrastructure. Che tu sia un professionista del cloud esperto o che tu stia appena iniziando il tuo viaggio verso la sicurezza del cloud, questo tutorial ti fornirà le competenze per costruire una solida difesa intorno alle tue applicazioni.

Che cos'è OCI Network Firewall

Oracle Cloud Infrastructure Network Firewall rappresenta un servizio firewall gestito all'avanguardia creato utilizzando Palo Alto Networks. È una tecnologia di firewall di nuova generazione (NGFW). Offre funzionalità firewall basate sul machine learning per proteggere i carichi di lavoro OCI ed è facile da utilizzare su OCI. In qualità di offerta firewall-as-a-service nativa OCI, OCI Network Firewall consente di sfruttare le funzioni del firewall senza dover configurare e gestire un'infrastruttura di sicurezza aggiuntiva. L'istanza di OCI Network Firewall è altamente scalabile con alta disponibilità integrata e può essere creata in una rete cloud virtuale (VCN) e in una subnet di tua scelta.

Il servizio OCI Network Firewall fornisce insight approfonditi sul flusso di dati che entrano nei tuoi ambienti cloud, affrontando sia la comunicazione in entrata che quella tra subnet o tra VCN. In sostanza, offre visibilità sul traffico di rete Nord-Sud e sul traffico di rete Est-Ovest. Per ulteriori informazioni, vedere Firewall di rete OCI.

Che cos'è OCI Web Application Firewall Edge

L'edge WAF OCI è un servizio Web Application Firewall basato su cloud. Protegge le applicazioni Web da minacce online come SQL injection e attacchi DDoS filtrando il traffico dannoso sul bordo della rete, migliorando la sicurezza. Per ulteriori informazioni, vedere OCI Web Application Firewall.

Architettura

Architettura

Questa architettura proposta includerà la protezione totale per i carichi di lavoro della tenancy utilizzando i componenti riportati di seguito.

Diagramma flusso dati

Il flusso di dati di rete può essere facilmente visto nel seguente diagramma di rete, richieste in entrata in linee di punti verdi, risposte in linee di punti rossi.

Architettura

Questo diagramma fa riferimento alle best practice per distribuire il firewall di rete OCI per il traffico Nord-Sud. Nella fase iniziale, il traffico in entrata (descritto in verde e operante a livello 7) viene indirizzato tramite il firewall edge Layer 7 WAF OCI. L'edge WAF OCI esegue l'interruzione e la risposta per le connessioni TLS/SSL, avviando successivamente una connessione TLS/SSL secondaria verso OCI, agendo come user agent senza soluzione di continuità.

Dopo il flusso di rete, il traffico passa al gateway Internet OCI dall'edge WAF OCI. All'interno del gateway Internet, una tabella di instradamento è stata configurata per reindirizzare il traffico verso un indirizzo IP privato in cui si trova il firewall di rete OCI. È interessante notare che OCI Network Firewall riceve senza problemi il traffico senza interrompere la connessione TLS/SSL. OCI Network Firewall applica i profili di decifrazione per decifrare il traffico TLS, consentendo un'ispezione approfondita dei pacchetti. Per ulteriori informazioni, vedere Uso di OCI Network Firewall per la decifrazione SSL.

Una volta ispezionato a fondo il traffico, OCI Network Firewall passa a OCI Load Balancer. Il balancer si assume la responsabilità di interrompere e rispondere alla connessione TLS/SSL. Esegue l'instradamento del bilanciamento del carico e avvia successivamente una connessione secondaria verso il server backend selezionato.

Per il traffico di ritorno dai server backend, i server backend rispondono inizialmente al load balancer OCI (illustrato in rosso e operante al livello 7). Una volta raggiunti i load balancer, una tabella di instradamento all'interno della subnet del load balancer reindirizza il traffico a un IP privato in cui si trova il firewall di rete OCI. Ciò consente a OCI Network Firewall di ispezionare le risposte in modo completo. Una volta completata l'ispezione, OCI Network Firewall torna al gateway Internet in base ai comandi della tabella di instradamento associati alla subnet GNFW (Next-Generation Firewall).

Successivamente, il traffico di ritorno raggiunge l'edge WAF OCI per l'ispezione finale delle risposte. Una volta che l'edge WAF OCI ha completato l'ispezione, fornisce in modo sicuro il traffico all'utente su Internet.

Obiettivi

L'obiettivo principale di questa esercitazione è quello di consentire agli utenti di rafforzare i propri carichi di lavoro cloud impostando in modo efficace l'edge WAF OCI insieme a OCI Network Firewall. Incorporando i certificati X.509 firmati da Let's Encrypt per il front-end edge WAF OCI, gli utenti possono garantire una connessione sicura e convalidata. L'esercitazione guida ulteriormente gli utenti nell'implementazione delle best practice OCI Network Firewall per il traffico Nord-Sud, distribuendo un'applicazione OCI Load Balancer. In particolare, questa configurazione designa strategicamente l'edge WAF OCI come unico componente utilizzando un certificato non autofirmato: Let's Encrypt, mentre altri elementi che utilizzano Transport Layer Security (TLS) utilizzano certificati autofirmati senza problemi, più facili da gestire.

Inoltre, dimostreremo l'uso di più sottodomini nell'edge WAF OCI e nel firewall di rete OCI, imposteremo l'edge WAF OCI per accettare domini con caratteri jolly e utilizzare i domini con caratteri jolly nei certificati X.509.

Prerequisiti

Task 1: Distribuzione dell'edge WAF (Web Application Firewall) OCI

Il primo componente che verrà distribuito è l'edge WAF.

  1. Eseguire il login a OCI Console e fare clic su Web Application Firewall.

    Menu WAF 1

  2. In Criteri, fare clic su Crea criterio WAF e immettere le informazioni riportate di seguito.

    Creazione criterio WAF

    Per creare un perimetro WAF OCI, fare clic su Usa workflow precedente qui se è necessario proteggere le applicazioni Web non OCI. Per impostazione predefinita, viene creato un criterio WAF locale utile da collegare ai load balancer. L'obiettivo di questa esercitazione riguarda l'edge WAF OCI (noto come workflow legacy WAF) che è un elemento esterno a OCI che consentirà di proteggere le origini OCI e non OCI (server IP pubblici). Si noti che l'edge WAF OCI è un prodotto diverso rispetto al criterio locale WAF OCI con funzioni quali Gestione bot (procedura Captcha, richiesta di verifica JavaScript, richiesta di verifica interazione umana e così via) e Regole di inserimento nella cache (simile al meccanismo di inserimento nella cache CDN).

  3. Nella schermata Crea criterio perimetrale, immettere le informazioni richieste.

    Creare criterio perimetrale

    A questo punto, due concetti cruciali richiedono chiarimenti.

    • Domini: il dominio perimetrale WAF indica il dominio Internet accessibile al pubblico per l'accesso al servizio Web (ad esempio: www.myexamplewebshop.com). Questo dominio funge da punto di connessione principale per tutti gli utenti, compresi quelli che utilizzano dispositivi mobili e laptop. Questo dominio supporta solo le porte TCP http 80 https 443 predefinite.

      In Domini è possibile aggiungere il dominio principale del sito Web (ad esempio, www.example.com) e continuare ad aggiungere altri domini aggiuntivi (app1.example.com, customer1.example.com e così via). Se si desidera aggiungere un dominio con caratteri jolly, sarà necessario utilizzare l'interfaccia CLI OCI per aggiungerlo manualmente. Il modo più rapido per accedere all'interfaccia CLI OCI è tramite gli strumenti degli sviluppatori OCI, Cloud Shell, in cui avrai accesso a un terminale basato su browser Web dalla console OCI, con una shell Linux preconfigurata con l'ultima versione dell'interfaccia CLI OCI e una serie di strumenti utili. Per ulteriori informazioni, vedere OCI Command Line Interface (CLI) e OCI Cloud Shell

      Per aggiungere un dominio con caratteri jolly come dominio aggiuntivo, aprire OCI Cloud Shell ed eseguirlo.

      oci waas waas-policy update --additional-domains '["*.yourmaindomain.xxx"]' --waas-policy-id your-WAF-policy-ID

( You can get your policy ID from OCI Web Console->Web application firewall->Policies->Policy details -> Policy Information Tab -> OCID )

      Utilizzando i domini con caratteri jolly, il criterio WAF sarà in grado di ricevere le richieste http(s), incluso qualsiasi sottodominio, ad esempio \*.example.com. Ad esempio: myapp1.example.com, mycustomer2.example.com e così via.

    • Origine WAF: è disponibile l'origine perimetrale WAF. Le origini si riferiscono ai server Web effettivi situati dietro il WAF. Nella terminologia WAF, l'origine indica i server di destinazione finali da proteggere. Queste origini devono comunicare esclusivamente con gli edge server WAF responsabili della loro protezione. Garantire che questa protezione venga garantita dai server di origine è fondamentale, in genere ottenuto in OCI tramite liste di sicurezza o gruppi di sicurezza di rete (NSG) che consentono esclusivamente l'accesso dagli IP di origine perimetrale WAF OCI designati. Per ulteriori informazioni, vedere Protezione del WAF. In genere, inserisci qui gli indirizzi IP pubblici o i nomi FQDN dei tuoi webserver o delle tue origini. Tuttavia, in questa esercitazione verrà utilizzato l'indirizzo IP pubblico del load balancer flessibile. Se un load balancer è già stato creato, puoi utilizzarne l'indirizzo IP pubblico come origine WAF. In caso contrario, puoi aggiungere inizialmente qualsiasi indirizzo IP e aggiornarlo in un secondo momento dopo aver creato il load balancer pubblico.

      Sarà possibile creare diversi gruppi di origini con più origini per gruppo ed eseguire il bilanciamento del carico tra di essi (IP_Hash, Round_robin, Sticky_Cookie), inclusi i controlli periodici dello stato. Per ulteriori informazioni, vedere Gestione origine. Inoltre, nelle opzioni di origine avanzate, sarà possibile modificare le porte TCP http 80 https 443 predefinite (solo per le origini e non per i domini).

  4. Fare clic su Create Edge Policy. Ci vorranno circa 2 minuti e vedremo Creazione. Successivamente, otterremo ACTIVE, in modo da poter continuare a impostare OCI WAF.

Task 2: configurare il DNS per l'edge WAF OCI

Ora abbiamo una configurazione di base dell'edge WAF OCI attivo e in esecuzione. Per assicurarci che i domini primari e aggiuntivi (incluso il carattere jolly) vengano reindirizzati verso gli edge server OCI WAF, dobbiamo configurare il server DNS che ospita il dominio con il CNAME corrispondente mostrato nella console.

NOME CDNS DNS

In questa esercitazione viene utilizzato il server DNS pubblico OCI, aggiungendo CNAME per il valore proposto, come mostrato nella seguente immagine.

Configurazione DNS OCI

Una volta configurato e pubblicato, qualsiasi tentativo di connessione a \*.example.com verrà reindirizzato agli edge server WAF OCI per l'ispezione di livello 7 all'indirizzo www-example-com.o.waas.oci.oraclecloud.net. Una volta completata l'ispezione, l'asse WAF OCI eseguirà il bilanciamento del carico verso le origini configurate con traffico pulito dopo l'ispezione WAF.

Task 3: Abilita supporto HTTPS per OCI WAF Edge

In questo task abiliteremo il supporto HTTPS sull'edge WAF OCI. Al giorno d'oggi, quasi tutti i servizi Web richiedono un'implementazione HTTP o HTTPS sicura, basandosi sulle connessioni SSL/TLS. È fondamentale avere una solida conoscenza dei concetti TLS/SSL, inclusa la gestione X.509, per abilitare in modo efficace il supporto HTTPS non solo sull'edge WAF OCI, ma anche sui componenti software imminenti discussi in questo tutorial.

  1. Andare a OCI Console e in Criterio edge, fare clic su Impostazioni.

    Impostazioni dei criteri perimetrali

  2. Per abilitare HTTPS, fare clic su Abilita supporto HTTPS.

    Abilitazione HTTPS

Qui, è necessario caricare il certificato del server con la relativa chiave privata. Questo certificato rappresenterà il dominio primario e i domini aggiuntivi, scelti durante la creazione dell'edge WAF OCI, pertanto è fondamentale che i campi SAN (Nome alternativo comune e Oggetto) del certificato includano questi domini. Per ulteriori informazioni, vedere Che cos'è il nome alternativo dell'oggetto del certificato SSL?.

Se si utilizza un certificato autofirmato, non firmato da una CA pubblica, selezionare Self-Signed Certificate. Quando si carica un certificato firmato da un'autorità di certificazione pubblica, è importante assicurarsi di caricare l'intero certificato catena. Un certificato catena è costituito da un elenco di certificati, in genere a partire da un certificato entità finale, dal certificato server e dalla relativa chiave pubblica, seguito da uno o più certificati CA (intermedi) e, facoltativamente, da un certificato CA radice (autofirmato).

Task 4: Firma del certificato del server con Let's Encrypt

In questo tutorial, utilizzeremo un servizio CA pubblico gratuito chiamato Let's Encrypt per firmare il nostro certificato server. Pertanto, il certificato catena verrà visualizzato come segue:

1.-End-user Certificate - Issued to: *.example.com; Issued By: Let’s Encrypt R3
2.-Intermediate Certificate 1 - Issued to: Let’s Encrypt R3 (RSA 2048, O = Let's Encrypt, CN = R3); Issued By: Signed by ISRG Root X1:ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1)
3.-Root certificate - Issued by and to: ISRG Root X1 (RSA 4096, O = Internet Security Research Group, CN = ISRG Root X1) , Selfsigned

In PEM format:

-----BEGIN CERTIFICATE-----
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yNDAxMTUxNjAyMTNaFw0yNDA0MTQxNjAyMTJaMBgxFjAUBgNVBAMM
DSouZnd0ZXN0LnNpdGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1
3NkuEB3r0m/cIWjYBvXEg8QAcib3QjkGO2YwDRu9IwjyxTYTqiWp0F8ZYh2hM1zP
...xxxx
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
oIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5Dt....XXXX
-----BEGIN CERTIFICATE-----
oOFTJOwT2e4ZvxCzSow/iaNhUd6shweU9GNx7C7ib1uYgeGJXDR5
bHbvO5BieebbpJovJsXQEOEO3tkQjhb7t/eo98flAgeYjzYIlefiN5YNNnWe+w5y
sR2bvAP5SQXYgd0FtCrWQemsAXaVCg/Y39W9Eh81LygXbNKYwagJZHduRze6zqxZ
Xmidf3LWicUGQSk+WT7dJvUsWqNMQB9GoZm1pzpRboY7nn1ypxIFeFntPlF4
FQsDj43QLwWyPntKHEtzBRL8xurgUBN8Q5N0s8p0544fAQjQMNRbcTa0B7rBMDBc
SLeCO5imfWCKoqMpgsy6vYMEG6KDA0Gh1gXxG8K28Kh8hjtGqEgqiNx2mna/H2ql
PRmP6zjzZN7IKw0KKP/32+IVQtQi0Cdd4Xn+GOd....xxx
-----END CERTIFICATE-----

Quindi, prima di utilizzare Let's Encrypt dobbiamo installare alcuni software che ci aiuteranno a creare il nostro certificato Let's Encrypt o firmare un CSR da firmare. Per maggiori informazioni, vedere Let's Encrypt.

Per la firma, useremo certbot di Let's Encrypt. Per ulteriori informazioni sull'impostazione delle istruzioni, vedere Impostazione delle istruzioni. Per installarlo su Oracle Linux, vedere Let's Encrypt - Free Certificates on Oracle Linux (CertBot).

Una volta installato certbot, puoi facilmente creare un certificato x.509 firmato eseguendo il seguente comando.

sudo certbot certonly --manual --preferred-challenges=dns --email YOUR EMAIL ADDRESS --server https://acme-v02.api.letsencrypt.org/directory --agree-tos -d *.example.com --key-type rsa

Poiché si sta utilizzando un dominio con caratteri jolly (_.example.com), certbot richiede una verifica per confermare la proprietà di _.example.com. Per scegliere la richiesta di verifica DNS si utilizza l'opzione -preferred-challenges=dns. Durante l'esecuzione di certbot, verrà visualizzato un messaggio sulla richiesta di verifica DNS come mostrato nella seguente immagine.

Richiesta di verifica DNS Certbot

Poiché stiamo utilizzando un servizio DNS OCI, creiamo solo un record txt nella zona example.com.

Richiesta di verifica TXT DNS OCI

Ora, certbot dovrebbe terminare il processo, consentendo di ottenere il certificato dell'utente finale, completo della catena CA completa e della chiave privata corrispondente. È quindi possibile caricarli nel menu HTTPS WAF OCI nel task 3.

Una volta caricati i certificati appena firmati nel task 3, verrà visualizzato il messaggio Hai 1 modifica non pubblicata. Fare clic su Pubblica tutto. Questa operazione può richiedere circa 20-30 minuti.

A questo punto, l'edge WAF OCI è configurato per ricevere traffico HTTPS. Successivamente, quando viene creato il load balancer OCI, dovrai ottenere l'IP pubblico del load balancer e impostarlo nell'origine edge WAF OCI.

IP pubblico di origine perimetrale WAF

Task 5: configurare il load balancer OCI

Dopo aver completato l'impostazione per l'edge WAF OCI, il nostro prossimo obiettivo è distribuire il load balancer OCI nei livelli da 4 a 7, noto anche come load balancer flessibile OCI, per fungere da origine del servizio rivolto al pubblico per l'edge WAF OCI. È importante notare che OCI Load Balancer offre la capacità di abilitare e collegare un WAF OCI interno o regionale, fornendo funzionalità WAF. Tuttavia, vale la pena ricordare che questa region WAF OCI è un prodotto distinto con un proprio set unico di funzioni. Questa esercitazione si concentra in modo specifico sull'implementazione edge di OCI WAF.

  1. Aprire la console OCI, fare clic su Networking e Load balancer.

    Load Balancer 1

  2. Fare clic su Crea load balancer, immettere le informazioni riportate di seguito, quindi fare clic su Successivo.

    • Nome load balancer: immettere il nome del load balancer.
    • Scegliere il tipo di visibilità: selezionare il load balancer Pubblico, tenere presente che l'edge WAF OCI protegge solo le origini IP pubbliche.
    • Larghezza di banda: selezionare la forma del load balancer e altri dettagli di configurazione.
    • Scegli networking: selezionare una VCN con almeno due subnet pubbliche, una per OCI Load Balancer e un'altra per OCI Network Firewall.

    Come descritto in Architettura, assicurarsi che il load balancer accetti solo il traffico proveniente dall'intervallo degli edge server WAF OCI. Vedere Intervalli CIDR.

    Per ottenere questo risultato, applicare le regole del firewall nel gruppo di sicurezza di rete (NSG), fare clic su Usa gruppi di sicurezza di rete per controllare il traffico e utilizzare un gruppo NSG o configurando la lista di sicurezza della subnet del load balancer.

    Menu principale del load balancer

  3. Saltare la sezione Scegli backend, poiché l'aggiunta dei server backend avverrà in seguito alla creazione del load balancer e fare clic su Successivo.

  4. In Configura listener, immettere le informazioni riportate di seguito e fare clic su Successivo.

    Menu listener del load balancer

    Configureremo i listener del load balancer delle richieste in entrata, essenzialmente il punto di accesso principale per il load balancer in cui riceviamo tutte le connessioni dal mondo esterno. Sarà necessario impostare HTTPS per il protocollo HTTPS sicuro sulla porta predefinita 443, che inevitabilmente richiede l'uso dei certificati X.509 (certificati SSL). Usando HTTPS ci assicureremo che tutte le connessioni siano criptate in modo sicuro.

    In uno scenario tipico in cui il load balancer pubblico funge da punto di accesso primario per gli utenti finali su Internet, è imperativo caricare certificati SSL firmati da un'autorità di certificazione pubblica affidabile (CA), come Digicert, Global Sign, Let's Encrypt e altri. Inoltre, questi certificati esposti a Internet devono essere rinnovati in prossimità delle relative date di scadenza per garantire che i clienti non ricevano messaggi non necessari come La connessione non è privata!! ERR_CERT_DATE_INVALID.

    In questa esercitazione viene utilizzato l'edge WAF OCI come punto di accesso principale per gli utenti che accedono ai servizi Web su Internet. I load balancer pubblici, dove hanno origine i nostri servizi, verranno posizionati dietro l'edge WAF OCI, il che significa che riceveranno solo il traffico dai nodi edge WAF OCI. A causa di questa impostazione, non è necessario caricare un certificato SSL da una CA pubblica nel load balancer. Invece, possiamo facilmente installare un certificato SSL autofirmato senza data di scadenza o molto lunga, semplificando la gestione.

    È importante notare che l'edge WAF OCI non ispezionerà i dettagli dei certificati SSL ricevuti dal load balancer, ad esempio il nome comune o il nome alternativo dell'oggetto, né ispezionerà la firma del certificato. Tuttavia, stabilirà comunque una connessione sicura e cifrata tra l'edge WAF OCI e l'origine di destinazione del load balancer OCI.

    È stato creato un certificato autofirmato utilizzando uno strumento esterno quale openssl o XCA. In alternativa, puoi utilizzare il servizio gestito da Oracle Certificates integrato con OCI Load Balancer. In questa esercitazione è stato utilizzato XCA per creare il certificato con firma automatica e caricarlo manualmente in OCI Load Balancer, insieme alla relativa chiave privata. Il certificato autofirmato caricato utilizza qualsiasi nome comune o SAN e ha una scadenza di 50 anni. OCI WAF non analizzerà tali informazioni.

  5. La configurazione Gestisci log è facoltativa e non rientra nell'ambito di questa esercitazione. Fare clic su Sottometti.

  6. Dopo un po' di tempo il load balancer verrà creato. Ora dobbiamo configurare i server backend. Poiché SSL verrà utilizzato per i server backend, è necessario in primo luogo creare almeno un certificato nella sezione dei certificati del load balancer che verrà utilizzato per impostare la connessione SSL ai server backend. Come descritto in precedenza, questo bundle di certificati può essere creato manualmente con strumenti di terze parti oppure è possibile utilizzare il servizio di gestione dei certificati OCI. Per questo tutorial, useremo lo strumento XCA.

    Vai a Networking, Load balancer, Load balancer, Dettagli del load balancer e Certificati.

  7. Nella sezione Certificato, selezionare Risorsa certificato come Gestisci certificato load balancer e fare clic su Aggiungi certificato.

    Origine certificato del load balancer

    Aggiungere il certificato CA root o CA intermedio pubblico utilizzato per firmare i certificati SSL del server backend. Come promemoria, abbiamo utilizzato certificati autofirmati con qualsiasi nome comune e SAN, e senza una data di scadenza. Non è necessario installare qui alcun certificato server, poiché il load balancer utilizzerà esclusivamente la CA root per la convalida del certificato del server backend.

    Load balancer che aggiunge un certificato

  8. Per creare i server backend, selezionare BackEnd set e fare clic su Crea set backend.

    Set backend load balancer 1

  9. In Crea set backend, immettere le informazioni riportate di seguito.

    • Nome set backend: immettere il nome del set backend.
    • Selezionare SSL.
    • Selezionare Gestisci certificato load balancer.
    • Aggiungere il certificato creato al passo 7. Se si desidera assicurarsi che il load balancer controlli la firma del certificato SSL ricevuto, fare clic su Verifica certificato peer.
    • Controlli stato:
      • Protocollo: selezionare HTTP.
      • Porta: selezionare la porta 443.
      • Intervalli e timeout: mantenere l'intervallo e il timeout predefiniti (10000 e 3000 msec).
      • Per la risposta dello stato dal controllo dello stato, selezionare 200.
      • Percorso URL (URI): aggiunge qualsiasi risorsa dall'URL esistente nel server Web. Ad esempio: index.html, mainpage.html e così via.

    Set backend load balancer 1

Task 6: configurare OCI Network Firewall

Dopo l'impostazione di OCI Load Balancer, il nostro obiettivo è configurare un firewall di rete OCI per salvaguardare il traffico Nord-Sud. Il firewall verrà posizionato tra il load balancer appena configurato e il gateway Internet. Per procedere con l'impostazione del firewall di rete OCI, vedere Utilizzare il firewall di rete OCI per il proxy di inoltro SSL e l'ispezione in entrata utilizzando la regola di decifrazione e completare quanto segue.

Task 7: Configura instradamento OCI

OCI Network Firewall è stato distribuito, dobbiamo assicurarci che il traffico Nord-Sud lo attraversa in entrambe le direzioni. La prima cosa da fare è creare una tabella di instradamento dedicata per il gateway Internet associato alla VCN in cui si trova il firewall di rete OCI.

  1. Creare la tabella di instradamento nella VCN e aggiungere una voce del tipo di destinazione come private IP, della destinazione come blocco CIDR, introducendo il blocco CIDR della subnet del load balancer, per questa esercitazione 192.168.6.0/24 e della destinazione come IP privato assegnato al firewall di rete OCI distribuito nel task 6.

    Tabella di instradamento GW Internet

  2. Associare la tabella di instradamento al gateway Internet, fare clic su tre punti e su Associa tabella di instradamento, quindi selezionare la tabella di instradamento.

    Tabella di instradamento GW Internet

  3. Una volta associata a questa tabella di instradamento al gateway Internet, tutto il traffico diretto verso il load balancer pubblico 192.168.6.0/24 verrà inizialmente reindirizzato all'IP privato 192.168.5.78, dove risiede il firewall di rete OCI.

    Dall'IP privato 192.168.5.78 del firewall di rete OCI, dopo l'ispezione dei pacchetti da OCI Network Firewall, il pacchetto manterrà il percorso verso OCI Load Balancer. Da lì, vengono indirizzati alla destinazione finale tra i server backend selezionati, determinata dalla configurazione di instradamento del load balancer.

    Ora, è essenziale garantire che i pacchetti che ritornano agli utenti Internet seguano lo stesso percorso in ordine inverso, attraversando il firewall di rete OCI per l'ispezione delle risposte. È necessario creare una tabella di instradamento per la subnet pubblica del load balancer per instradare le risposte dai server backend tramite l'IP privato 192.168.5.78 del firewall di rete OCI, come mostrato nell'immagine riportata di seguito.

    tabella di instradamento del load balancer

Dalla subnet del firewall di rete OCI, dobbiamo assicurarci che le risposte vengano instradate al gateway Internet, aggiungendo un instradamento 0.0.0.0/0 al gateway Internet.

Tabella di instradamento firewall di rete

Dopo aver raggiunto il gateway Internet, i package vengono instradati di nuovo all'origine, l'edge WAF OCI, per l'ispezione finale delle risposte, prima di essere indirizzati agli utenti Internet.

Conferme

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o accedi a più contenuti gratuiti sulla formazione su Oracle Learning YouTube channel. Inoltre, visita education.oracle.com/learning-explorer per diventare un Oracle Learning Explorer.

Per la documentazione del prodotto, visita l'Oracle Help Center.