Concevoir la protection DDoS pour Oracle Cloud Infrastructure
Bien qu'il existe de nombreuses options de conception à sélectionner, les facteurs communs pour la plupart des conceptions sont les suivants :
- Respect des normes de sécurité de l'entreprise
- Sécurisé de bout en bout
- Suivre un modèle de défense en profondeur
- Gestion facile
- Evolutif
L'objectif principal du service de protection OCI DDoS est de fournir une solution sécurisée et évolutive qui répond aux exigences DDoS d'une entreprise, tout en prenant en charge plusieurs niveaux d'environnement, notamment la production, la préparation, le développement, l'assurance qualité et la récupération après sinistre. Les services de protection OCI DDoS aident également une entreprise à mettre en place une architecture hautement disponible et évolutive avec un modèle de sécurité en profondeur, tirant parti des composants cloud natifs OCI, tels que les pare-feu d'applications Web (WAF), Equilibreurs de charge réseau (NLB), équilibreurs de charge flexibles (FLB), pare-feu de nouvelle génération (NGFW) tiers avec les certificats DDoS activés et TLS/SSL, ainsi que les avantages et considérations associés pour chaque conception.
Evaluer et choisir une option de conception d'architecture pour la prévention DDoS sur OCI
Il existe différentes options de conception d'architecture que vous pouvez choisir, selon la façon dont vous souhaitez que votre prévention DDoS évolue.
Option de conception 1 : pare-feu d'applications Web et équilibreur de charge réseau unique
Dans cette conception, les certificats TLS sont utilisés sur les flux WAF, NGFW, les FLB privés et les serveurs back-end pour les flux HTTP/S. Le flux HTTP/S est toujours entrant à partir de la périphérie OCI WAF et passe progressivement par un NLB, suivi de NGFW et enfin du FLB privé. Cette approche nécessite plusieurs stratégies WAF pour chaque niveau d'environnement (par exemple, production, assurance qualité et récupération après sinistre) et le transfert du trafic HTTP/S vers un seul NLB, un seul FLB et ses ensembles back-end correspondants.
Remarque :
Pour tous les flux non-HTTP/S, le flux sera toujours entrant via le NLB, en contournant OCI WAF, par les NGFW et enfin le NLB privé. Cela permet d'implémenter le pare-feu DDoS sur un niveau basé sur une zone ou sur un niveau global pour se concentrer sur les attaques de couche 3 et de couche 4.Le diagramme suivant illustre cette architecture.
réseau unique-lb-ngfw-architecture.zip
A mesure que le trafic entre en périphérie OCI, les stratégies en périphérie OCI WAF effectuent un arrêt TLS/SSL. Le paquet est ensuite déchiffré afin qu'il puisse être inspecté pour détecter toute charge utile de couche 7 WAF malveillante avant d'envoyer le trafic vers l'origine sur un port spécifique. Par défaut, il s'agit de 443/TCP, qui peuvent être configurés pour être transférés sur des ports spécifiques.
L'origine d'OCI WAF est configurée pour transférer le trafic vers un seul NLB, qui transfère ensuite le trafic vers des instances de calcul NGFW tierces pour un port TCP donné. Par exemple, dans le diagramme ci-dessus, le trafic vert et bleu de la bordure OCI WAF est envoyé à l'origine (adresse IP du processus d'écoute NLB) sur des ports spécifiques, 4443/TCP et 4444/TCP respectivement. A son tour, le NLB est configuré pour transférer le trafic vers les ensembles de back-ends (NGFW) sur les mêmes ports TCP.
Le NLB fonctionne dans les couches 3 et 4 et est placé dans un sous-réseau public. Le NLB est généralement configuré pour conserver l'adresse IP source du client. Le trafic entrant via OCI WAF fera l'objet d'un proxy à l'aide des CIDR OCI WAF documentés dédiés au service OCI WAF. Etant donné que le trafic provient d'un proxy à partir d'une liste des CIDR OCI WAF documentés, nous pouvons ajouter une couche de sécurité supplémentaire en tirant parti des listes de sécurité et/ou des groupes de sécurité réseau pour limiter la connectivité à une liste de CIDR OCI WAF valides et sécurisés. Cela implique également que les journaux de flux de sous-réseau NLB et les journaux de trafic NGFW tiers voient uniquement les adresses IP des plages CIDR OCI WAF comme adresse IP source.
Etant donné que cette conception exploite des pare-feu actifs/actifs à l'aide d'un NLB, le pare-feu tiers doit effectuer une opération source-NAT avant de transmettre le trafic au FLB privé pour maintenir un chemin symétrique pour le trafic de retour. Le NGFW devra également effectuer le NAT de destination car la destination est un FLB privé.
En supposant que la NGFW prend en charge le décryptage et l'inspection, nous pouvons décrypter le trafic pour effectuer des IDS/IPS sur les charges utiles non chiffrées sur la NGFW, avant de transmettre le trafic à un FLB donné.
Compte tenu des exigences fournies et de l'option de conception décrite ci-dessus, nous pouvons conclure les meilleures pratiques suivantes pour ce déploiement :
- Des stratégies WAF distinctes pour chaque niveau d'environnement (production, développement et assurance qualité).
- Utilisez un équilibreur de charge réseau unique.
- Réutilisez les mêmes NGFW back-end pour plusieurs niveaux d'environnement.
- Concevez une architecture de défense en profondeur.
- Sécurisez l'environnement de bout en bout.
- Minimiser et contrôler les attaques lancées sur site via Oracle Cloud.
- Bénéficiez d'une protection des couches 3 et 4 DDoS avec un contrôle organisationnel.
- Configurez DDoS dans la couche de pare-feu avec le contrôle utilisateur pour compléter les offres Oracle.
Option de conception 2 : pare-feu d'applications Web et équilibreurs de charge réseau multiples
Dans cette conception, la technologie, les composants et le flux de données restent les mêmes que dans notre conception précédente. Une fois le trafic entrant via la périphérie OCI, il est traité et inspecté par les stratégies en périphérie OCI WAF pour toutes les charges utiles de couche 7 WAF malveillantes avant d'être envoyé au NLB, au NGFW, et finalement à une ALB privée. De même, tous les flux non-HTTP/S entreront toujours via le NLB, en contournant OCI WAF et les NGFW, et enfin le NLB privé. Cela permet d'implémenter le pare-feu DDoS sur un niveau basé sur une zone ou sur un niveau global pour se concentrer sur les attaques de couche 3 et de couche 4.
La principale différence dans la conception de l'option 2 est de tirer parti de plusieurs NLB par niveau d'environnement (production, développement et assurance qualité) pour séparer le trafic d'environnement. Dans l'option 2, chaque NLB utilise une adresse IP secondaire unique sur la NGFW en tant qu'ensemble de back-ends pour transférer le trafic. Le trafic se dirige finalement vers le FLB désigné pour l'application ou le service donné. Cette conception introduit également la possibilité d'évoluer au-delà de la limite de 50 processus d'écoute à l'aide d'un seul NLB. Cette conception permettra également de réutiliser les ports d'écoute NLB pour normaliser les flux de trafic pour chaque niveau d'environnement (production, développement et assurance qualité).
Le diagramme suivant illustre cette architecture.
