DDoS-Schutz für Oracle Cloud Infrastructure entwerfen
Während es viele Designoptionen gibt, aus denen ausgewählt werden kann, sind die häufigsten Faktoren für die meisten Designs:
- Auf Geschäftssicherheitsstandards abgestimmt
- Sicheres Ende-zu-Ende
- Folgen Sie einem detaillierten Verteidigungsmodell
- Einfach verwalten
- Skalierbar
Das Hauptziel des OCI DDoS-Schutzservice ist es, eine sichere und skalierbare Lösung bereitzustellen, die den DDoS-Anforderungen eines Unternehmens entspricht und gleichzeitig mehrere Umgebungsebenen unterstützt, einschließlich Produktion, Staging, Entwicklung, Qualitätssicherung und Disaster Recovery. OCI DDoS-Schutzservices unterstützen ein Unternehmen auch bei der Einrichtung einer hochverfügbaren und skalierbaren Architektur mit einem umfassenden Sicherheitsmodell, das native OCI-Komponenten wie Web Application Firewalls (WAF) nutzt, Network Load Balancer (NLB), Flexible Load Balancer (FLB), Drittanbieter-Firewalls der nächsten Generation (NGFWs) mit aktivierten DDoS- und TLS/SSL-Zertifikaten sowie die damit verbundenen Vorteile und Überlegungen für jedes Design.
Evaluieren und wählen Sie eine Architekturdesignoption für DDoS Prävention auf OCI
Es gibt verschiedene Architekturdesignoptionen, die Sie auswählen können, je nachdem, wie Ihre DDoS-Prävention skaliert werden soll.
Entwurfsoption 1: Webanwendungs-Firewalls und Single Network Load Balancer
In diesem Design werden TLS-Zertifikate auf WAF, NGFW, den privaten FLBs und den Backend-Servern für HTTP/S-Flows verwendet. Der HTTP/S-Ablauf wird immer von der OCI-WAF-Edge ingressiv und arbeitet schrittweise durch eine NLB, gefolgt von NGFWs und schließlich durch die private FLB. Für diesen Ansatz sind mehrere WAF-Policys für jede Umgebungsebene (z.B. Produktion, QA und DR) erforderlich, und der HTTP/S-Traffic wird an ein einzelnes NLB, ein einzelnes FLB und die entsprechenden Backend-Sets weitergeleitet.
Hinweis:
Bei allen Nicht-HTTP/S-Flows wird der Ablauf immer über die NLB ingress, um die OCI WAF, die NGFWs und schließlich die private NLB zu umgehen. So können Sie die Firewall DDoS auf einer zonenbasierten Ebene oder auf einer globalen Ebene implementieren, um sich auf Layer-3- und Layer-4-Angriffe zu konzentrieren.Im folgenden Diagramm wird diese Architektur dargestellt.
Einzelnetzwerk-lb-ngfw-architecture.zip
Wenn Datenverkehr über die OCI-Edge eingeht, führen OCI-WAF-Edge-Policys eine TLS/SSL-Beendigung durch. Das Paket wird dann entschlüsselt, damit es auf böswillige WAF-Schicht-7-Payloads geprüft werden kann, bevor der Traffic an einen bestimmten Port gesendet wird. Standardmäßig ist dies 443/TCP, das für die Weiterleitung auf bestimmten Ports konfiguriert werden kann.
Der Ursprung von OCI WAF ist so konfiguriert, dass Traffic an ein einzelnes NLB weitergeleitet wird, das den Traffic dann an NGFW-Compute-Instanzen von Drittanbietern für einen bestimmten TCP-Port weiterleitet. Beispiel: Im obigen Diagramm wird der grüne und blaue Trafficfluss von der OCI WAF-Edge an den Ursprung (die NLB-Listener-IP-Adresse) auf bestimmten Ports, 4443/TCP bzw. 4444/TCP gesendet. Im Gegenzug ist die NLB so konfiguriert, dass der Datenverkehr an die Backend-Sets (die NGFWs) auf denselben TCP-Ports weitergeleitet wird.
Die NLB arbeitet in Schicht 3 und 4 und befindet sich in einem öffentlichen Subnetz. Die NLB wird in der Regel so konfiguriert, dass die Quell-IP-Adresse des Clients beibehalten wird. Traffic, der über OCI WAF eingeht, wird mit dokumentierten OCI-WAF-CIDRs, die für den OCI-WAF-Service dediziert sind, als Proxy verwendet. Da der Traffic aus einer Liste dokumentierter OCI-WAF-CIDRs als Proxy verwendet wird, können wir eine zusätzliche Sicherheitsebene hinzufügen, indem wir Sicherheitslisten und/oder NSGs nutzen, um die Konnektivität zu einer Liste gültiger und vertrauenswürdiger OCI-WAF-CIDRs einzuschränken. Dies bedeutet auch, dass die NLB-Subnetzflusslogs und die NGFW-Trafficlogs anderer Hersteller nur die IP-Adressen aus den OCI WAF-CIDR-Bereichen als Quell-IP anzeigen.
Da dieses Design aktive/aktive Firewalls mit einem NLB nutzt, muss die Drittanbieterfirewall Source-NAT vor der Weiterleitung des Traffics an das private FLB ausführen, um einen symmetrischen Pfad für den Rückgabeverkehr beizubehalten. Die NGFW wird auch Ziel-NAT ausführen müssen, da das Ziel ein privates FLB ist.
Wenn die NGFW Entschlüsselung und Prüfung unterstützt, können wir den Datenverkehr entschlüsseln, um IDS/IPS für unverschlüsselte Payloads auf der NGFW auszuführen, bevor der Datenverkehr an eine bestimmte FLB weitergeleitet wird.
Unter Berücksichtigung der oben beschriebenen Anforderungen und der Designoption können wir die folgenden Best Practices für dieses Deployment abschließen:
- Separate WAF-Richtlinien für jede Umgebungsebene (Produktion, Entwicklung und Qualitätssicherung).
- Verwenden Sie einen einzelnen Network Load Balancer (NLB).
- Verwenden Sie dieselben Backend-NGFWs für mehrere Umgebungsebenen wieder.
- Entwerfen Sie eine Defense-in-Depth-Architektur.
- Sichern Sie die Umgebung durchgängig.
- Mindern und kontrollieren Sie Angriffe von On-Premise-Anwendungen in Oracle Cloud.
- Erhalten Sie den Schutz der Schicht 3 und 4 DDoS mit Organisationskontrolle.
- Konfigurieren Sie DDoS in der Firewallschicht mit der Benutzersteuerung, um die Angebote von Oracle zu ergänzen.
Entwurfsoption 2: Webanwendungs-Firewalls und mehrere Netzwerk-Load Balancer
Bei diesem Design bleiben Technologie, Komponenten und Datenfluss gleich wie bei unserem vorherigen Design. Nachdem der Traffic durch die OCI-Edge eingeht, wird er von den OCI-WAF-Edge-Policys für böswillige WAF-Layer-7-Payloads verarbeitet und geprüft, bevor er an NLB, NGFW und schließlich eine private ALB gesendet wird. Ebenso werden alle Nicht-HTTP/S-Abläufe immer über das NLB ingressiert, wobei OCI WAF und die NGFWs umgangen werden und schließlich das private NLB. So können Sie die Firewall DDoS auf einer zonenbasierten Ebene oder auf einer globalen Ebene implementieren, um sich auf Layer-3- und Layer-4-Angriffe zu konzentrieren.
Der wesentliche Unterschied beim Design von Option 2 besteht darin, mehrere NLBs auf einer Ebene pro Umgebung (Produktion, Entwicklung und Qualitätssicherung) zu nutzen, um den Umgebungsdatenverkehr zu trennen. In Option 2 verwendet jede NLB eine eindeutige sekundäre IP-Adresse für die NGFW als Backend-Set zur Weiterleitung von Datenverkehr. Der Traffic geht letztlich zum angegebenen FLB für die angegebene Anwendung oder den angegebenen Service über. Dieses Design bietet auch die Möglichkeit, über die 50 Listener-Beschränkung mithilfe einer einzelnen NLB zu skalieren. Durch dieses Design können auch NLB-Listener-Ports wieder verwendet werden, um die Verkehrswerte für die einzelnen Umgebungsebenen (Produktion, Entwicklung und Qualitätssicherung) zu standardisieren.
Im folgenden Diagramm wird diese Architektur dargestellt.
