Remarques :

Sécurisez vos applications à l'aide d'OCI Network Firewall et d'OCI WAF Edge avec Chiffrons les certificats

Introduction

Dans un paysage dominé par une transformation numérique omniprésente, assurer la sécurité de vos applications n'est pas seulement une considération, c'est une priorité sans compromis. Au fur et à mesure que les entreprises migrent leurs charges de travail vers Oracle Cloud Infrastructure (OCI), une stratégie de défense robuste contre les cybermenaces devient indispensable. OCI fournit une suite complète d'outils pour fortifier vos applications. Dans ce tutoriel, nous vous guiderons tout au long du processus de sécurisation de vos ressources numériques à l'aide d'OCI Network Firewall et de la périphérie OCI Web Application Firewall (WAF).

Pourquoi ce tutoriel est-il essentiel ?

Au fur et à mesure que vos applications communiquent avec le monde extérieur, elles font face au défi omniprésent des menaces de cybersécurité. Ce tutoriel vous aide à créer une défense multicouche, en protégeant vos applications contre les menaces connues et émergentes en tirant parti de la puissance d'OCI Network Firewall et de la périphérie OCI WAF. Nous explorerons des concepts importants, notamment le support multi-domaine et la génération ou le renouvellement de certificats X.509 à l'aide d'outils standard. De plus, nous allons découvrir l'utilisation du service gratuit et largement reconnu Let's Encrypt. Grâce à cela, vous acquerrez une compréhension complète des pratiques essentielles pour sécuriser vos applications.

A qui s'adresse ce tutoriel ?

Ce tutoriel est destiné aux architectes cloud, aux professionnels de la sécurité et aux développeurs qui recherchent une compréhension complète des fonctionnalités de sécurité d'Oracle Cloud Infrastructure. Que vous soyez un praticien chevronné du cloud ou que vous commenciez tout juste votre parcours dans la sécurité du cloud, ce tutoriel vous dotera des compétences nécessaires pour construire une défense robuste autour de vos applications.

Qu'est-ce qu'OCI Network Firewall ?

Oracle Cloud Infrastructure Network Firewall représente un service de pare-feu géré de pointe conçu à l'aide de Palo Alto Networks. Il s'agit d'une technologie de pare-feu nouvelle génération (NGFW). Il offre des fonctionnalités de pare-feu basées sur le machine learning pour protéger vos workloads OCI et est facile à utiliser sur OCI. En tant qu'offre de pare-feu natif OCI en tant que service, OCI Network Firewall vous permet de tirer parti des fonctionnalités de pare-feu sans avoir à configurer et à gérer une infrastructure de sécurité supplémentaire. L'instance OCI Network Firewall est hautement évolutive avec une haute disponibilité intégrée et peut être créée dans un réseau cloud virtuel (VCN) et un sous-réseau de votre choix.

Le service OCI Network Firewall fournit des informations approfondies sur le flux de données entrant dans vos environnements cloud, en abordant la communication entrante et inter-sous-réseau ou inter-VCN. En substance, il offre une visibilité sur le trafic réseau Nord-Sud et le trafic réseau Est-Ouest. Pour plus d'informations, reportez-vous à OCI Network Firewall.

Qu'est-ce qu'OCI Web Application Firewall Edge ?

La périphérie OCI WAF est un service Web Application Firewall basé sur le cloud. Il protège les applications Web contre les menaces en ligne telles que l'injection SQL et les attaques DDoS en filtrant le trafic malveillant à la périphérie du réseau, ce qui améliore la sécurité. Pour plus d'informations, reportez-vous à OCI Web Application Firewall.

Architecture

Architecture

Cette architecture proposée inclura une protection totale pour les charges globales de location à l'aide des composants suivants.

Diagramme de flux de données

Le flux de données réseau est facilement visible dans le diagramme de réseau suivant, les demandes entrantes en pointillés verts, les réponses en pointillés rouges.

Architecture

Ce diagramme respecte les meilleures pratiques de déploiement du pare-feu réseau OCI pour le trafic Nord-Sud. Au cours de la phase initiale, le trafic entrant (indiqué en vert et fonctionnant à la couche 7) est dirigé via le pare-feu de couche 7 en périphérie OCI WAF. La périphérie OCI WAF effectue la terminaison et la réponse pour les connexions TLS/SSL, puis lance une connexion TLS/SSL secondaire vers OCI, agissant en tant qu'agent utilisateur dos à dos.

Suite au flux réseau, le trafic passe à la passerelle Internet OCI à partir de la périphérie OCI WAF. Au sein de la passerelle Internet, une table de routage a été configurée pour rediriger le trafic vers une adresse IP privée où se trouve le pare-feu réseau OCI. Il est à noter que le pare-feu réseau OCI reçoit le trafic de manière transparente sans mettre fin à la connexion TLS/SSL. OCI Network Firewall applique des profils de décryptage pour décrypter le trafic TLS, ce qui permet une inspection approfondie des paquets. Pour plus d'informations, reportez-vous à Utilisation d'OCI Network Firewall pour le décryptage SSL.

Une fois qu'OCI Network Firewall a inspecté le trafic de manière approfondie, il passe à l'équilibreur de charge OCI. L'équilibreur prend la responsabilité de mettre fin à la connexion TLS/SSL et d'y répondre. Il exécute le routage d'équilibrage de charge et lance ensuite une connexion secondaire vers le serveur back-end sélectionné.

Pour le trafic de retour des serveurs back-end, les serveurs back-end répondent initialement à l'équilibreur de charge OCI (illustré en rouge et fonctionnant à la couche 7). Une fois que vous avez atteint les équilibreurs de charge, une table de routage du sous-réseau de l'équilibreur de charge redirige le trafic vers une adresse IP privée où se trouve le pare-feu de réseau OCI. Cela permet au pare-feu réseau OCI d'inspecter les réponses de manière complète. Une fois que le pare-feu réseau OCI a terminé l'inspection, il revient à la passerelle Internet en fonction des commandes de table de routage associées au sous-réseau de pare-feu nouvelle génération (NGFW).

Par la suite, le trafic de retour atteint la périphérie OCI WAF pour l'inspection finale des réponses. Une fois que la périphérie OCI WAF a terminé l'inspection, elle remet le trafic en toute sécurité à l'utilisateur sur Internet.

Objectifs

L'objectif principal de ce tutoriel est de permettre aux utilisateurs de fortifier leurs workloads cloud en configurant efficacement la périphérie OCI WAF en conjonction avec OCI Network Firewall. En intégrant des certificats X.509 signés de Let's Encrypt pour le front-end en périphérie OCI WAF, les utilisateurs peuvent garantir une connexion sécurisée et validée. Ce tutoriel guide les utilisateurs dans l'implémentation des meilleures pratiques OCI Network Firewall pour le trafic Nord-Sud, en déployant un équilibreur de charge OCI d'application. Notamment, cette configuration désigne stratégiquement la périphérie OCI WAF comme le seul composant utilisant un certificat non auto-signé - Chiffrons le certificat, tandis que d'autres éléments utilisant Transport Layer Security (TLS) utilisent des certificats auto-signés sans tracas, plus faciles à gérer.

De plus, nous allons démontrer l'utilisation de plusieurs sous-domaines dans OCI WAF edge et OCI Network Firewall, configurer OCI WAF edge pour accepter les domaines avec caractères génériques et utiliser des domaines avec caractères génériques dans les certificats X.509.

Prérequis

Tâche 1 : déployer OCI Web Application Firewall (WAF) en périphérie

Le premier composant que nous allons déployer est la périphérie WAF.

  1. Connectez-vous à la console OCI et cliquez sur Web Application Firewall.

    WAF - Menu 1

  2. Dans Stratégies, cliquez sur Créer une stratégie WAF et entrez les informations suivantes.

    WAF - Créer une stratégie

    Pour créer une périphérie OCI WAF, cliquez sur Utiliser le workflow hérité ici si vous devez sécuriser vos applications Web autres qu'OCI. Par défaut, une stratégie WAF locale est créée et utile pour être attachée aux équilibreurs de charge. Ce tutoriel se concentre sur la périphérie OCI WAF (connue sous le nom de workflow hérité WAF) qui est un élément externe à OCI qui permettra de protéger les origines OCI et non OCI (serveurs IP publics). Notez que la périphérie OCI WAF est un produit différent de la stratégie locale OCI WAF avec des fonctionnalités telles que la gestion des bots (question de vérification Captcha, question de vérification JavaScript, question de vérification Human Interaction, etc.) et les règles de mise en cache (semblables au mécanisme de mise en cache CDN).

  3. Dans Créer une stratégie en périphérie, entrez les informations requises.

    Créer une stratégie en périphérie

    À ce stade, deux concepts essentiels nécessitent une clarification.

    • Domaines : l'arête WAF Domaine indique le domaine Internet accessible au public pour accéder à votre service Web (par exemple : www.myexamplewebshop.com). Ce domaine sert de point de connexion principal pour tous les utilisateurs, y compris ceux qui utilisent des appareils mobiles et des ordinateurs portables. Ce domaine prend uniquement en charge les ports TCP http 80 https 443 par défaut.

      Dans Domaines, vous pouvez ajouter le domaine principal de votre site Web (par exemple : www.example.com) et continuer à ajouter d'autres domaines supplémentaires (app1.example.com, customer1.example.com, etc.). Si vous souhaitez ajouter un domaine à caractère générique, vous devez utiliser l'interface de ligne de commande OCI pour l'ajouter manuellement. Le moyen le plus rapide d'accéder à l'interface de ligne de commande OCI consiste à utiliser les outils des développeurs OCI, Cloud Shell, où vous aurez accès à un terminal basé sur un navigateur Web à partir de la console OCI, avec un shell Linux préconfiguré avec la dernière version de l'interface de ligne de commande OCI et un certain nombre d'outils utiles. Pour plus d'informations, reportez-vous à Interface de ligne de commande OCI et à OCI Cloud Shell.

      Pour ajouter un domaine à caractère générique en tant que domaine supplémentaire, ouvrez OCI Cloud Shell et exécutez-le.

      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 )

      En utilisant des domaines avec caractères génériques, votre stratégie WAF pourra recevoir des demandes HTTP, y compris tout sous-domaine, tel que \*.example.com. Par exemple : myapp1.example.com, mycustomer2.example.com, etc.

    • Origine WAF : nous disposons de l'origine en périphérie WAF. L'origine fait référence au(x) serveur(s) Web réel(s) situé(s) derrière le WAF. Dans la terminologie WAF, l'origine signifie que les serveurs de destination finaux sont protégés. Ces origines doivent communiquer exclusivement avec les serveurs en périphérie WAF responsables de leur protection. Il est impératif de s'assurer que cette protection est assurée par les serveurs d'origine, généralement réalisée dans OCI via des listes de sécurité ou des groupes de sécurité réseau qui autorisent exclusivement l'accès à partir des adresses IP de source en périphérie OCI WAF désignées. Pour plus d'informations, reportez-vous à Sécurisation de WAF. En règle générale, vous entrez ici les adresses IP publiques ou les noms de domaine qualifiés complets de vos serveurs Web ou origines réels. Toutefois, dans ce tutoriel, nous utiliserons l'adresse IP publique de l'équilibreur de charge flexible. Si un équilibreur de charge a déjà été créé, vous pouvez utiliser son adresse IP publique comme origine WAF. Si ce n'est pas le cas, vous pouvez initialement ajouter n'importe quelle adresse IP et la mettre à jour ultérieurement une fois que vous avez créé l'équilibreur de charge public.

      Vous pourrez créer différents groupes d'origines avec plusieurs origines par groupe et effectuer un équilibrage de charge entre eux (IP_Hash, Round_robin, Sticky_Cookie), y compris des vérifications d'état périodiques. Pour plus d'informations, reportez-vous à Origin Management. En outre, sous les options d'origine avancées, vous pourrez modifier les ports TCP http 80 https 443 par défaut (uniquement pour les origines, pas pour les domaines).

  4. Cliquez sur Créer une stratégie en périphérie. Cela prendra environ 2 minutes et nous verrons la création. Après cela, nous obtiendrons ACTIVE, ce qui nous permettra de continuer à configurer OCI WAF.

Tâche 2 : configurer le DNS pour OCI WAF en périphérie

Désormais, nous disposons d'une configuration de base de la périphérie OCI WAF opérationnelle. Afin de nous assurer que les domaines principaux et supplémentaires (y compris les caractères génériques) sont redirigés vers les serveurs en périphérie OCI WAF, nous devons configurer le serveur DNS hébergeant le domaine avec le CNAME correspondant affiché dans la console.

NOM C DNS

Dans ce tutoriel, nous utilisons le serveur DNS public OCI, en ajoutant CNAME pour la valeur proposée, comme indiqué dans l'image suivante.

Configuration DNS OCI

Une fois configurée et publiée, toute tentative de connexion à \*.example.com sera redirigée vers les serveurs en périphérie OCI WAF pour l'inspection de couche 7 à l'adresse www-example-com.o.waas.oci.oraclecloud.net. Une fois l'inspection terminée, la périphérie OCI WAF équilibrera la charge vers les origines configurées avec un trafic propre après l'inspection WAF.

Tâche 3 : activer la prise en charge HTTPS pour OCI WAF Edge

Dans cette tâche, nous activerons la prise en charge HTTPS sur notre périphérie OCI WAF. De nos jours, presque tous les services Web nécessitent une implémentation HTTP ou HTTPS sécurisée, en s'appuyant sur des connexions SSL/TLS. Il est essentiel d'avoir une solide compréhension des concepts TLS/SSL, y compris la gestion X.509, pour activer efficacement la prise en charge HTTPS non seulement en périphérie OCI WAF, mais également sur les composants logiciels à venir abordés dans ce tutoriel.

  1. Accédez à la console OCI et, sous Stratégie en périphérie, cliquez sur Paramètres.

    Paramètres de stratégie en périphérie

  2. Pour activer HTTPS, cliquez sur Activer la prise en charge de HTTPS.

    Activation HTTPS

Ici, vous devez télécharger le certificat de serveur avec sa clé privée. Ce certificat représentera le domaine principal et les domaines supplémentaires que vous choisissez lors de la création de la périphérie OCI WAF. Par conséquent, il est essentiel que les champs de nom commun et de nom alternatif de sujet (SAN) du certificat incluent ces domaines. Pour plus d'informations, reportez-vous à Quel est le nom alternatif du sujet du certificat SSL ?.

Si vous utilisez un certificat autosigné, qui n'est pas signé par une autorité de certification publique, sélectionnez Certificat autosigné. Lorsque vous téléchargez un certificat signé par une autorité de certification publique, il est important de vous assurer que vous téléchargez l'intégralité du certificat de la chaîne. Un certificat de chaîne se compose d'une liste de certificats, commençant généralement par un certificat d'entité finale, votre certificat de serveur et sa clé publique, suivie d'un ou plusieurs certificats d'autorité de certification (intermédiaires), et se terminant éventuellement par un certificat d'autorité de certification racine (autosigné).

Tâche 4 : signature d'un certificat de serveur à l'aide du cryptage

Dans ce tutoriel, nous utiliserons un service CA public gratuit appelé Let's Encrypt pour signer notre certificat de serveur. Par conséquent, le certificat de chaîne apparaîtra comme suit :

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

Donc, avant d'utiliser Let's Encrypt, nous devons installer certains logiciels qui nous aideront à créer notre certificat Let's Encrypt ou à signer une CSR à signer. Pour plus d'informations, reportez-vous à Cryptage.

Pour signer, nous allons utiliser certbot de Let's Encrypt. Pour plus d'informations sur les instructions de configuration, reportez-vous à la section Set up Instructions. Pour l'installer sur Oracle Linux, reportez-vous à Cryptage - Certificats gratuits sur Oracle Linux (CertBot).

Une fois que vous avez installé certbot, vous pouvez facilement créer un certificat x.509 signé en exécutant la commande suivante.

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

Etant donné que nous utilisons un domaine générique (_.example.com), certbot nécessite un défi de vérification pour confirmer la propriété de _.example.com. Nous choisissons la question de vérification DNS à l'aide de l'option -preferred-challenges=dns. Lors de l'exécution de certbot, nous recevrons un message sur le défi DNS comme indiqué dans l'image suivante.

Défi DNS Certbot

Etant donné que nous utilisons un service DNS OCI, nous créons simplement un enregistrement txt dans la zone example.com.

Défi TXT DNS OCI

Maintenant, certbot doit terminer le processus, ce qui vous permet d'obtenir le certificat de l'utilisateur final, avec la chaîne d'autorité de certification complète et sa clé privée correspondante. Vous pouvez ensuite les télécharger vers le menu HTTPS OCI WAF de la tâche 3.

Une fois que vous avez téléchargé les certificats juste signés dans la tâche 3, un message Vous avez 1 modification non publiée s'affiche. Cliquez sur Tout publier, cela peut prendre environ 20 à 30 minutes.

A ce stade, votre périphérie OCI WAF est configurée pour recevoir le trafic HTTPS. Plus tard, lors de la création de l'équilibreur de charge OCI, vous devrez obtenir l'adresse IP publique de l'équilibreur de charge et la définir dans l'origine en périphérie OCI WAF.

Adresse IP publique d'origine en périphérie WAF

Tâche 5 : configurer l'équilibreur de charge OCI

Une fois la configuration de la périphérie OCI WAF terminée, notre prochain objectif est de déployer l'équilibreur de charge OCI de couche 4 à 7, également appelé équilibreur de charge flexible OCI, afin de servir d'origine de service publique pour la périphérie OCI WAF. Il est important de noter que l'équilibreur de charge OCI offre la possibilité d'activer et d'attacher un OCI WAF interne ou régional, en fournissant des fonctionnalités WAF. Cependant, il convient de noter que cette région OCI WAF est un produit distinct avec son propre ensemble unique de fonctionnalités. Ce tutoriel se concentre spécifiquement sur l'implémentation en périphérie d'OCI WAF.

  1. Ouvrez la console OCI, cliquez sur Fonctions de réseau et sur Equilibreur de charge.

    équilibreur de charge 1

  2. Cliquez sur Créer un équilibreur de charge, entrez les informations suivantes et cliquez sur Suivant.

    • Nom de l'équilibreur de charge : saisissez le nom de l'équilibreur de charge.
    • Choisir un type de visibilité : sélectionnez l'équilibreur de charge public, n'oubliez pas qu'OCI WAF edge protège uniquement les origines d'adresse IP publique.
    • Bande passante : sélectionnez la forme de l'équilibreur de charge et d'autres détails de configuration.
    • Choisir la mise en réseau : sélectionnez un VCN avec au moins deux sous-réseaux publics, l'un pour OCI Load Balancer et l'autre pour OCI Network Firewall.

    Comme décrit dans Architecture, assurez-vous que l'équilibreur de charge accepte uniquement le trafic provenant de la plage de serveurs en périphérie OCI WAF. Reportez-vous à Plages CIDR.

    Pour ce faire, vous pouvez appliquer des règles de pare-feu dans le groupe de sécurité réseau, cliquer sur Utiliser des groupes de sécurité réseau pour contrôler le trafic et utiliser un groupe de sécurité réseau ou configurer la liste de sécurité de sous-réseau de l'équilibreur de charge.

    Equilibreur de charge - Menu principal

  3. Ignorez la section Choisir des back-ends, car nous ajouterons des serveurs back-end ultérieurement une fois l'équilibreur de charge créé, puis cliquez sur Suivant.

  4. Dans Configurer le processus d'écoute, entrez les informations suivantes et cliquez sur Suivant.

    Menu du processus d'écoute d'équilibreur de charge

    Nous allons configurer les processus d'écoute d'équilibreur de charge des demandes entrantes, qui sont essentiellement le point d'entrée principal de l'équilibreur de charge où nous recevons toutes les connexions du monde extérieur. Nous devrons configurer HTTPS pour HTTP sécurisé sur le port par défaut 443, ce qui nécessite inévitablement l'utilisation de certificats X.509 (certificats SSL). En utilisant HTTPS, nous veillerons à ce que toutes les connexions soient cryptées de manière sécurisée.

    Dans un scénario classique où l'équilibreur de charge public sert de point d'entrée principal pour les utilisateurs finaux sur Internet, il est impératif de télécharger des certificats SSL signés par une autorité de certification publique réputée, telle que Digicert, Global Sign, Let's Encrypt, etc. En outre, ces certificats exposés à Internet doivent être renouvelés près de leur date d'expiration pour s'assurer que les clients ne rencontrent pas de messages inutiles tels que Votre connexion n'est pas privée. ERR_CERT_DATE_INVALID.

    Dans ce tutoriel, nous utilisons la périphérie OCI WAF comme point d'entrée principal pour les utilisateurs accédant aux services Web sur Internet. Les équilibreurs de charge publics, qui sont à l'origine de nos services, seront positionnés derrière la périphérie OCI WAF, ce qui signifie qu'ils ne recevront que le trafic des noeuds en périphérie OCI WAF. Grâce à cette configuration, il n'est pas nécessaire de télécharger un certificat SSL d'une autorité de certification publique vers l'équilibreur de charge. Au lieu de cela, nous pouvons facilement installer un certificat SSL autosigné sans date d'expiration ou très long, ce qui simplifie la gestion.

    Il est important de noter qu'OCI WAF edge n'inspecte pas les détails des certificats SSL reçus de l'équilibreur de charge, tels que le nom commun ou le nom alternatif du sujet, ni la signature du certificat. Néanmoins, il établira toujours une connexion sécurisée et cryptée entre la périphérie OCI WAF et l'origine cible de l'équilibreur de charge OCI.

    Nous avons créé un certificat autosigné à l'aide de n'importe quel outil externe tel que openssl ou XCA. Vous pouvez également utiliser le service géré Oracle Certificates intégré à l'équilibreur de charge OCI. Dans ce tutoriel, nous avons utilisé XCA pour créer le certificat auto-signé et l'avons téléchargé manuellement dans OCI Load Balancer, ainsi que sa clé privée. Le certificat auto-signé téléchargé utilise n'importe quel nom commun ou SAN et a un délai d'expiration de 50 ans. OCI WAF n'inspectera pas ces informations.

  5. La gestion de la journalisation est une configuration facultative qui ne fait pas partie de la portée de ce tutoriel. Cliquez sur Soumettre.

  6. Au bout d'un certain temps, votre équilibreur de charge sera créé. Maintenant, nous devons configurer les serveurs back-end. Comme SSL sera utilisé pour les serveurs back-end, nous devons d'abord créer au moins un certificat dans la section de certificat de l'équilibreur de charge qui sera utilisé pour configurer la connexion SSL vers les serveurs back-end. Comme décrit ci-dessus, ce groupe de certificats peut être créé manuellement avec des outils tiers ou vous pouvez utiliser le service de gestion des certificats OCI. Pour ce tutoriel, nous allons utiliser l'outil XCA.

    Accédez à Networking, Load Balancers, Load Balancer, Détails de l'équilibreur de charge et Certificats.

  7. Dans la section Certificat, sélectionnez ressource de certificat en tant que certificat de gestion d'équilibreur de charge, puis cliquez sur Ajouter un certificat.

    Source de certificat d'équilibreur de charge

    Ajoutez le certificat CA racine ou CA intermédiaire public que vous avez utilisé pour signer les certificats SSL du serveur back-end. Pour rappel, nous avons utilisé des certificats autosignés avec n'importe quel nom commun et SAN, et sans date d'expiration. Vous n'avez pas besoin d'installer de certificats de serveur ici, car l'équilibreur de charge utilisera uniquement l'autorité de certification racine pour la validation du certificat de serveur back-end.

    Equilibreur de charge en ajoutant un certificat

  8. Pour créer les serveurs back-end, sélectionnez Ensembles de BackEnd et cliquez sur Créer un ensemble de back-ends.

    Ensemble de back-ends d'équilibreur de charge 1

  9. Dans Créer un ensemble de back-ends, saisissez les informations suivantes :

    • Nom d'ensemble de serveurs : entrez le nom de l'ensemble de serveurs.
    • Sélectionnez SSL.
    • Sélectionnez Certificat de gestion d'équilibreur de charge.
    • Ajoutez le certificat que vous avez créé à l'étape 7. Pour vous assurer que l'équilibreur de charge vérifie la signature de certificat SSL reçue, cliquez sur Vérifier le certificat homologue.
    • Vérifications de l'état :
      • Protocole : sélectionnez HTTP.
      • Port : sélectionnez 443 port.
      • Intervalles et délai d'expiration : conservez l'intervalle et le délai d'expiration par défaut (10000 et 3000 ms).
      • Pour la réponse de vérification de l'état, sélectionnez 200.
      • Chemin d'URL (URI) : ajoutez toute ressource de l'URL qui existe sur le serveur Web. Par exemple : index.html, mainpage.html, etc.

    Ensemble de back-ends d'équilibreur de charge 1

Tâche 6 : configurer le pare-feu réseau OCI

Une fois l'équilibreur de charge OCI configuré, notre objectif est de configurer un pare-feu réseau OCI pour protéger le trafic Nord-Sud. Le pare-feu sera positionné entre le nouvel équilibreur de charge configuré et la passerelle Internet. Pour poursuivre la configuration du pare-feu de réseau OCI, reportez-vous à Utilisation du pare-feu de réseau OCI pour le proxy de transfert SSL et l'inspection entrante à l'aide de la règle de décryptage et effectuez les opérations suivantes.

Tâche 7 : configurer le routage OCI

Le pare-feu réseau OCI a été déployé. Nous devons nous assurer que le trafic Nord-Sud le traverse dans les deux sens. La première chose à faire est de créer une table de routage dédiée pour la passerelle Internet associée au VCN où se trouve le pare-feu réseau OCI.

  1. Créez la table de routage dans le VCN et ajoutez une entrée de type de cible en tant que private IP, destination en tant que bloc CIDR, en introduisant le bloc CIDR de sous-réseau d'équilibreur de charge, pour ce tutoriel 192.168.6.0/24 et cible en tant qu'adresse IP privée affectée au pare-feu de réseau OCI déployé dans la tâche 6.

    Internet GW - Table de routage

  2. Associez la table de routage à la passerelle Internet, cliquez sur trois points, puis sur Associer la table de routage et sélectionnez la table de routage.

    Internet GW - Table de routage

  3. Une fois cette table de routage associée à la passerelle Internet, tout le trafic dirigé vers l'équilibreur de charge public 192.168.6.0/24 sera initialement redirigé vers l'adresse IP privée 192.168.5.78, où réside le pare-feu de réseau OCI.

    A partir de l'adresse IP privée 192.168.5.78 d'OCI Network Firewall, après l'inspection des paquets à partir d'OCI Network Firewall, le paquet poursuit son parcours vers OCI Load Balancer. A partir de là, ils sont dirigés vers leur destination finale parmi les serveurs back-end sélectionnés, déterminés par la configuration de routage de l'équilibreur de charge.

    Désormais, il est essentiel de s'assurer que les paquets retournant aux utilisateurs Internet suivent le même chemin dans l'ordre inverse, en parcourant également le pare-feu réseau OCI pour l'inspection des réponses. Nous devons créer une table de routage pour le sous-réseau public de l'équilibreur de charge afin d'acheminer les réponses des serveurs back-end via l'adresse IP privée 192.168.5.78 d'OCI Network Firewall, comme indiqué dans l'image suivante.

    table de routage d'équilibreur de charge

A partir du sous-réseau OCI Network Firewall, nous devons nous assurer que les réponses sont acheminées vers la passerelle Internet, en ajoutant un routage 0.0.0.0/0 vers la passerelle Internet.

Table de routage de pare-feu réseau

Après avoir atteint la passerelle Internet, les packages sont acheminés vers leur source, la périphérie OCI WAF, pour l'inspection finale des réponses, avant d'être dirigés vers les utilisateurs Internet.

Remerciements

Ressources de formation supplémentaires

Parcourez d'autres ateliers sur docs.oracle.com/learn ou accédez à davantage de contenus de formation gratuits sur le canal Oracle Learning YouTube. De plus, rendez-vous sur education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir de la documentation sur le produit, visitez Oracle Help Center.