Hinweis:

Sichern Sie Ihre Anwendungen mit OCI Network Firewall und OCI WAF Edge mit Let's Encrypt-Zertifikaten

Einführung

In einer Landschaft, die von der allgegenwärtigen digitalen Transformation dominiert wird, ist die Sicherstellung der Sicherheit Ihrer Anwendungen nicht nur eine Überlegung, sondern steht als kompromisslose Priorität. Während Unternehmen ihre Workloads zu Oracle Cloud Infrastructure (OCI) migrieren, ist eine robuste Verteidigungsstrategie gegen Cyberbedrohungen unerlässlich. OCI bietet eine umfassende Suite von Tools zur Stärkung Ihrer Anwendungen. In diesem Tutorial führen wir Sie durch den Prozess der Sicherung Ihrer digitalen Assets mit OCI Network Firewall und OCI Web Application Firewall (WAF)-Edge.

Warum ist dieses Tutorial wichtig?

Während Ihre Anwendungen mit der Außenwelt kommunizieren, stehen sie vor der allgegenwärtigen Herausforderung von Cyber-Sicherheitsbedrohungen. In diesem Tutorial können Sie eine mehrschichtige Verteidigung erstellen und Ihre Anwendungen vor bekannten und neuen Bedrohungen schützen, indem Sie die Leistungsfähigkeit der OCI Network Firewall und der OCI WAF-Edge nutzen. Wir werden wichtige Konzepte untersuchen, einschließlich Multi-Domain-Support und die Generierung oder Erneuerung von X.509-Zertifikaten mit Standardwerkzeugen. Darüber hinaus werden wir den weithin anerkannten und kostenlosen Service Let's Encrypt kennenlernen. Dadurch erhalten Sie ein umfassendes Verständnis der wichtigsten Vorgehensweisen zur Sicherung Ihrer Anwendungen.

Für wen ist dieses Tutorial geeignet?

Dieses Tutorial richtet sich an Cloud-Architekten, Sicherheitsexperten und Entwickler, die ein umfassendes Verständnis der Sicherheitsfeatures von Oracle Cloud Infrastructure suchen. Unabhängig davon, ob Sie ein erfahrener Cloud-Praktiker sind oder gerade erst mit dem Einstieg in die Cloud-Sicherheit beginnen, dieses Tutorial vermittelt Ihnen die Fähigkeiten, eine robuste Verteidigung rund um Ihre Anwendungen aufzubauen.

Was ist OCI Network Firewall

Oracle Cloud Infrastructure Network Firewall ist ein hochmoderner verwalteter Firewall-Service, der mit Palo Alto Networks erstellt wird. Es ist eine Firewall-Technologie der nächsten Generation (NGFW). Sie bietet auf maschinellem Lernen basierende Firewallfunktionen zum Schutz Ihrer OCI-Workloads und ist auf OCI einfach zu nutzen. Als natives OCI-Firewall-as-a-Service-Angebot ermöglicht OCI Network Firewall die Nutzung der Firewallfunktionen, ohne dass zusätzliche Sicherheitsinfrastruktur konfiguriert und verwaltet werden muss. Die OCI Network Firewall-Instanz ist mit integrierter High Availability hoch skalierbar und kann in einem virtuellen Cloud-Netzwerk (VCN) und Subnetz Ihrer Wahl erstellt werden.

Der OCI Network Firewall-Service bietet tiefe Einblicke in den Datenfluss, der in Ihre Cloud-Umgebungen eintritt, und adressiert sowohl eingehende als auch die Kommunikation zwischen Subnetzen oder VCN. Im Wesentlichen bietet es einen Einblick in den Nord-Süd-Netzwerkverkehr und den Ost-West-Netzwerkverkehr. Weitere Informationen finden Sie unter OCI-Netzwerkfirewall.

Was ist OCI Web Application Firewall Edge

OCI WAF-Edge ist ein cloud-basierter Web Application Firewall-Service. Es schützt Webanwendungen vor Online-Bedrohungen wie SQL-Injection- und DDoS-Angriffen, indem es böswilligen Datenverkehr an der Netzwerk-Edge filtert und die Sicherheit erhöht. Weitere Informationen finden Sie unter OCI Web Application Firewall.

Architektur

Architektur

Diese vorgeschlagene Architektur umfasst den vollständigen Schutz für Mandanten-Workloads, indem die folgenden Komponenten verwendet werden.

Datenflussdiagramm

Der Netzwerkdatenfluss lässt sich leicht im folgenden Netzwerkdiagramm erkennen, eingehende Anfragen in grünen Punktlinien, Antworten in roten Punktlinien.

Architektur

Dieses Diagramm entspricht den Best Practices für das Deployment der OCI Network Firewall für Nord-Süd-Traffic. In der Anfangsphase wird eingehender Traffic (grün dargestellt und auf Layer 7 ausgeführt) durch die OCI-WAF-Edge-Layer-7-Firewall geleitet. Die OCI WAF-Edge führt die Beendigung und Antwort für TLS/SSL-Verbindungen aus und initiiert anschließend eine sekundäre TLS/SSL-Verbindung zu OCI, die als Back-to-Back-Benutzer-Agent fungiert.

Nach dem Netzwerkfluss wird der Traffic von der OCI-WAF-Edge zum OCI-Internetgateway weitergeleitet. Innerhalb des Internetgateways wurde eine Routingtabelle konfiguriert, um den Traffic zu einer privaten IP-Adresse umzuleiten, in der sich die OCI-Netzwerkfirewall befindet. Es ist bemerkenswert, dass die OCI Network Firewall den Datenverkehr nahtlos empfängt, ohne die TLS/SSL-Verbindung zu beenden. Die OCI-Netzwerkfirewall wendet Entschlüsselungsprofile an, um den TLS-Traffic zu entschlüsseln, was eine tiefe Paketprüfung ermöglicht. Weitere Informationen finden Sie unter OCI Network Firewall für SSL-Entschlüsselung verwenden.

Nachdem die OCI Network Firewall den Traffic gründlich geprüft hat, wird er zum OCI Load Balancer weitergeleitet. Der Balancer übernimmt die Verantwortung für die Beendigung und Reaktion auf die TLS/SSL-Verbindung. Es führt Load Balancing Routing aus und initiiert anschließend eine sekundäre Verbindung zum ausgewählten Backend-Server.

Für den Return Traffic von Backend-Servern reagieren die Backend-Server zunächst auf den OCI Load Balancer (rot dargestellt und auf Layer 7 ausgeführt). Beim Erreichen der Load Balancer leitet eine Routingtabelle im Load-Balancer-Subnetz den Traffic zurück an eine private IP, in der sich die OCI Network Firewall befindet. Dadurch kann die OCI Network Firewall die Antworten umfassend prüfen. Nachdem die OCI-Netzwerkfirewall die Prüfung abgeschlossen hat, wird sie basierend auf den Routingtabellenbefehlen, die mit dem Subnetz der Next-Generation Firewall (NGFW) verknüpft sind, wieder zum Internetgateway weitergeleitet.

Anschließend erreicht der zurückgebende Traffic die OCI WAF-Edge für die abschließende Prüfung der Antworten. Nachdem die OCI WAF-Edge die Prüfung abgeschlossen hat, stellt sie den Traffic sicher an den Benutzer im Internet zurück.

Ziele

Das Hauptziel dieses Tutorials besteht darin, Benutzern die Möglichkeit zu geben, ihre Cloud-Workloads zu stärken, indem sie die OCI WAF-Edge in Verbindung mit der OCI Network Firewall effektiv einrichten. Durch die Integration signierter X.509-Zertifikate aus Let's Encrypt für das OCI WAF-Edge-Frontend können Benutzer eine sichere und validierte Verbindung sicherstellen. Das Tutorial führt Benutzer weiter bei der Implementierung der Best Practices der OCI Network Firewall für Nord-Süd-Traffic und beim Deployment eines OCI Load Balancers für eine Anwendung an. Insbesondere bezeichnet diese Konfiguration die OCI WAF-Edge strategisch als einzige Komponente mit einem nicht selbstsignierten Zertifikat - Let's Encrypt-Zertifikat, während andere Elemente, die Transport Layer Security (TLS) verwenden, mühelose selbstsignierte Zertifikate verwenden, die einfacher zu verwalten sind.

Darüber hinaus werden wir die Verwendung mehrerer Subdomains in OCI WAF-Edge und OCI Network Firewall demonstrieren, die OCI WAF-Edge so einrichten, dass sie Platzhalterdomains akzeptiert und Platzhalterdomains in X.509-Zertifikaten verwendet.

Voraussetzungen

Aufgabe 1: OCI Web Application Firewall-(WAF-)Edge bereitstellen

Die erste Komponente, die wir bereitstellen werden, ist die WAF-Edge.

  1. Melden Sie sich bei der OCI-Konsole an, und klicken Sie auf Web Application Firewall.

    WAF-Menü 1

  2. Klicken Sie unter Policys auf WAF-Policy erstellen, und geben Sie die folgenden Informationen ein.

    WAF-Policy erstellen

    Um eine OCI-WAF-Edge zu erstellen, klicken Sie hier auf Legacy-Workflow verwenden, wenn Sie Nicht-OCI-Webanwendungen sichern müssen. Standardmäßig wird eine lokale WAF-Policy erstellt, die für das Anhängen an Load Balancer nützlich ist. Der Schwerpunkt dieses Tutorials liegt auf der OCI WAF-Edge (als Legacy-Workflow-WAF bezeichnet), die ein externes Element zu OCI ist, mit dem OCI- und Nicht-OCI-Ursprünge (öffentliche IP-Server) geschützt werden können. Beachten Sie, dass die OCI WAF-Edge ein anderes Produkt ist als die lokale OCI WAF-Policy mit Features wie Botmanagement (Captcha-Herausforderung, JavaScript-Challenge, Human Interaction-Herausforderung usw.) und Caching-Regeln (ähnlich dem CDN-Caching-Mechanismus).

  3. Geben Sie unter Edge-Policy erstellen die erforderlichen Informationen ein.

    Edge Policy erstellen

    An dieser Stelle sind zwei entscheidende Konzepte zu klären.

    • Domains: Die Domain der WAF-Edge gibt die für die Öffentlichkeit zugängliche Internetdomain für den Zugriff auf Ihren Webservice an (Beispiel: www.myexamplewebshop.com). Diese Domain dient als primärer Verbindungspunkt für alle Benutzer, einschließlich derer, die mobile Geräte und Laptops verwenden. Diese Domain unterstützt nur die standardmäßigen TCP-Ports http 80 https 443.

      Unter Domains können Sie die Primäre Domain Ihrer Website hinzufügen (Beispiel: www.example.com) und weitere zusätzliche Domains (app1.example.com, customer1.example.com usw.) hinzufügen. Wenn Sie eine Platzhalterdomain hinzufügen möchten, müssen Sie sie manuell mit der OCI-CLI hinzufügen. Der schnellste Zugriff auf die OCI-CLI erfolgt über OCI-Entwicklertools, Cloud Shell, wo Sie über die OCI-Konsole Zugriff auf ein webbrowserbasiertes Terminal mit einer vorkonfigurierten Linux-Shell mit der neuesten Version der OCI-CLI und einer Reihe nützlicher Tools haben. Weitere Informationen finden Sie unter OCI-Befehlszeilenschnittstelle (CLI) und OCI Cloud Shell

      Um eine Platzhalterdomain als zusätzliche Domain hinzuzufügen, öffnen Sie OCI Cloud Shell, und führen Sie sie aus.

      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 )

      Wenn Sie Platzhalterdomains verwenden, kann Ihre WAF-Policy HTTP(s)-Anforderungen einschließlich aller Subdomains empfangen, wie \*.example.com. Beispiel: myapp1.example.com, mycustomer2.example.com usw.

    • WAF-Ursprung: Die WAF-Edge Origin ist vorhanden. Die Ursprünge beziehen sich auf die eigentlichen Webserver, die sich hinter der WAF befinden. In der WAF-Terminologie bezeichnet der Ursprung die ultimativen Zielserver, die geschützt werden. Diese Ursprünge sollten ausschließlich mit den WAF-Edge-Servern kommunizieren, die für ihren Schutz verantwortlich sind. Die Gewährleistung dieses Schutzes durch die Ursprungsserver ist unerlässlich. Dies wird in der Regel in OCI über Sicherheitslisten oder Netzwerksicherheitsgruppen (NSG) erreicht, die ausschließlich Zugriff von angegebenen OCI-WAF-Edge-Quell-IPs zulassen. Weitere Informationen finden Sie unter WAF sichern. In der Regel geben Sie hier die öffentlichen IP-Adressen oder FQDNs Ihrer tatsächlichen Webserver oder Ursprünge ein. In diesem Tutorial verwenden wir jedoch die öffentliche IP-Adresse des flexiblen Load Balancers. Wenn bereits ein Load Balancer erstellt wurde, können Sie seine öffentliche IP-Adresse als WAF-Ursprung verwenden. Andernfalls können Sie zunächst eine beliebige IP-Adresse hinzufügen und später aktualisieren, nachdem Sie den öffentlichen Load Balancer erstellt haben.

      Sie können verschiedene Ursprungsgruppen mit mehreren Ursprüngen pro Gruppe erstellen und Load Balancing zwischen ihnen ausführen (IP_Hash, Round_robin, Sticky_Cookie), einschließlich periodischer Health Checks. Weitere Informationen finden Sie unter Herkunftsverwaltung. Darüber hinaus können Sie unter erweiterten Ursprungsoptionen die standardmäßigen TCP-Ports für HTTP 80 https 443 ändern (nur für Ursprünge, nicht für Domains).

  4. Klicken Sie auf Edge Policy erstellen. Der Vorgang dauert etwa 2 Minuten und Wird erstellt wird angezeigt. Danach erhalten wir ACTIVE, damit wir OCI WAF weiter einrichten können.

Aufgabe 2: DNS für OCI WAF-Edge konfigurieren

Jetzt ist eine grundlegende Konfiguration der OCI WAF-Edge hochgefahren und gestartet. Um sicherzustellen, dass primäre und zusätzliche Domains (einschließlich Platzhalter) zu OCI WAF-Edge-Servern umgeleitet werden, müssen wir den DNS-Server, der die Domain hostet, mit dem entsprechenden CNAME konfigurieren, der in der Konsole angezeigt wird.

DNS-NAME

In diesem Tutorial verwenden wir den öffentlichen OCI-DNS-Server und fügen CNAME für den vorgeschlagenen Wert hinzu, wie in der folgenden Abbildung dargestellt.

OCI-DNS-Konfiguration

Nach der Konfiguration und Veröffentlichung wird jeder Versuch, eine Verbindung zu \*.example.com herzustellen, zu OCI WAF-Edge-Servern für die Layer-7-Prüfung unter www-example-com.o.waas.oci.oraclecloud.net umgeleitet. Sobald die Prüfung abgeschlossen ist, wird die OCI WAF-Edge nach der WAF-Prüfung mit sauberem Traffic auf die konfigurierten Ursprünge ausgerichtet.

Aufgabe 3: HTTPS-Unterstützung für OCI WAF-Edge aktivieren

In dieser Aufgabe aktivieren wir HTTPS-Unterstützung auf unserer OCI WAF-Edge. Heutzutage erfordern fast alle Webservices eine sichere HTTP- oder HTTPS-Implementierung, die auf SSL-/TLS-Verbindungen basiert. Es ist wichtig, ein solides Verständnis von TLS/SSL-Konzepten, einschließlich X.509-Management, zu haben, um HTTPS-Unterstützung nicht nur auf der OCI WAF-Edge, sondern auch auf bevorstehenden Softwarekomponenten, die in diesem Tutorial behandelt werden, effektiv zu ermöglichen.

  1. Gehen Sie zur OCI-Konsole, und klicken Sie unter Edge-Policy auf Einstellungen.

    Edge Policy-Einstellungen

  2. Um HTTPS zu aktivieren, klicken Sie auf HTTPS-Unterstützung aktivieren.

    HTTPS aktivieren

Hier müssen Sie das Serverzertifikat mit seinem Private Key hochladen. Dieses Zertifikat stellt die Primäre Domain und die zusätzlichen Domains dar, die Sie beim Erstellen der OCI-WAF-Edge auswählen. Daher ist es wichtig, dass die Felder für den allgemeinen Namen und den alternativen Subject-Namen (SAN) des Zertifikats diese Domains enthalten. Weitere Informationen finden Sie unter Was ist der alternative Name des SSL-Zertifikatsbetreffs?.

Wenn Sie ein selbstsigniertes Zertifikat verwenden, das nicht von einer öffentlichen CA signiert wurde, wählen Sie Selbstsigniertes Zertifikat aus. Wenn Sie ein von einer öffentlichen CA signiertes Zertifikat hochladen, müssen Sie unbedingt das gesamte Kettenzertifikat hochladen. Ein Kettenzertifikat besteht aus einer Liste von Zertifikaten, in der Regel beginnend mit einem End-Entity-Zertifikat, Ihrem Serverzertifikat und dem zugehörigen Public Key, gefolgt von einem oder mehreren CA-Zertifikaten (Intermediates) und optional abschließend mit einem Root-CA-Zertifikat (selbstsigniert).

Aufgabe 4: Serverzertifikat mit Let's Encrypt signieren

In diesem Tutorial verwenden wir einen kostenlosen öffentlichen CA-Service namens Let's Encrypt, um unser Serverzertifikat zu signieren. Daher wird das Kettenzertifikat wie folgt angezeigt:

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

Vor der Verwendung von Let's Encrypt müssen wir also bestimmte Software installieren, die uns hilft, unser Let's Encrypt-Zertifikat zu erstellen oder einen CSR zu signieren, der signiert werden soll. Weitere Informationen finden Sie unter Verschlüsseln zulassen.

Für die Signierung verwenden wir certbot von Let's Encrypt. Weitere Informationen zum Einrichten von Anweisungen finden Sie unter Anweisungen einrichten. Informationen zur Installation auf Oracle Linux finden Sie unter Let's Encrypt - Free Certificates on Oracle Linux (CertBot).

Nachdem Sie certbot installiert haben, können Sie einfach ein signiertes x.509-Zertifikat erstellen, indem Sie den folgenden Befehl ausführen.

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

Da wir eine Platzhalterdomain (_.example.com) verwenden, erfordert certbot eine Verifizierungsherausforderung, um die Eigentümerschaft von _.example.com zu bestätigen. Wir wählen die DNS-Challenge mit der Option -preferred-challenges=DNS. Während der Ausführung von certbot erhalten wir eine Meldung zur DNS-Challenge, wie im folgenden Bild dargestellt.

Certbot DNS-Herausforderung

Da wir einen OCI-DNS-Service verwenden, erstellen wir nur einen TXT-Datensatz in der Zone example.com.

OCI-DNS-TXT-Challenge

Jetzt sollte certbot den Prozess abschließen, sodass Sie das Endbenutzerzertifikat mit der vollständigen CA-Kette und dem entsprechenden Private Key erhalten können. Sie können diese dann in Aufgabe 3 in das OCI-WAF-HTTPS-Menü hochladen.

Nachdem Sie die genau signierten Zertifikate in Aufgabe 3 hochgeladen haben, wird die Meldung Sie haben 1 unveröffentlichte Änderung angezeigt. Klicken Sie auf Alle veröffentlichen. Dieser Vorgang kann ungefähr 20-30 Minuten dauern.

Zu diesem Zeitpunkt ist Ihre OCI WAF-Edge so konfiguriert, dass sie HTTPS-Traffic empfängt. Später, wenn OCI Load Balancer erstellt wird, müssen Sie die öffentliche IP des Load Balancers abrufen und im OCI-WAF-Edge-Ursprung festlegen.

Öffentliche IP für WAF-Edge-Ursprung

Aufgabe 5: OCI Load Balancer konfigurieren

Nach Abschluss des Setups für die OCI WAF-Edge ist unser nächstes Ziel das Deployment des OCI Load Balancers in Layer 4 bis 7, auch als OCI Flexible Load Balancer bezeichnet, um als öffentlich zugänglicher Serviceursprung für die OCI WAF-Edge zu dienen. Beachten Sie, dass der OCI Load Balancer die Möglichkeit bietet, eine interne oder regionale OCI WAF zu aktivieren und anzuhängen, und dabei WAF-Features bereitstellt. Es ist jedoch zu erwähnen, dass diese OCI WAF-Region ein eindeutiges Produkt mit einem eigenen einzigartigen Set von Features ist. Dieses Tutorial konzentriert sich speziell auf die OCI-WAF-Edge-Implementierung.

  1. Öffnen Sie die OCI-Konsole, und klicken Sie auf Networking und Load Balancer.

    Load Balancer 1

  2. Klicken Sie auf Load Balancer erstellen, geben Sie die folgenden Informationen ein, und klicken Sie auf Weiter.

    • Load-Balancer-Name: Geben Sie den Namen des Load Balancers ein.
    • Sichtbarkeitstyp auswählen: Wählen Sie den öffentlichen Load Balancer aus. Denken Sie daran, dass die OCI WAF-Edge nur öffentliche IP-Ursprünge schützt.
    • Bandbreite: Wählen Sie die Load-Balancer-Ausprägung und andere Konfigurationsdetails aus.
    • Networking auswählen: Wählen Sie ein VCN mit mindestens zwei öffentlichen Subnetzen aus. Eines für OCI Load Balancer und eines für OCI Network Firewall.

    Wie unter Architektur beschrieben, stellen Sie sicher, dass der Load Balancer nur Traffic vom OCI-WAF-Edge-Serverbereich akzeptiert. Informationen hierzu finden Sie unter CIDR-Bereiche.

    Sie können dies erreichen, indem Sie Firewallregeln in der Netzwerksicherheitsgruppe (NSG) anwenden, auf Netzwerksicherheitsgruppen zur Kontrolle des Traffics verwenden klicken und eine NSG verwenden oder die Load-Balancer-Subnetzsicherheitsliste konfigurieren.

    Hauptmenü für Load Balancer

  3. Überspringen Sie den Abschnitt Backends auswählen, da wir später Backend-Server hinzufügen werden, nachdem der Load Balancer erstellt wurde, und klicken Sie auf Weiter.

  4. Geben Sie im Feld Listener konfigurieren die folgenden Informationen ein, und klicken Sie auf Weiter.

    Menü "Load Balancer Listener"

    Wir konfigurieren die Load Balancer Listener für eingehende Anforderungen, im Wesentlichen den Haupteinstiegspunkt für den Load Balancer, an dem wir alle Verbindungen von außen empfangen. Wir müssen HTTPS für sicheres HTTP auf dem Standardport 443 einrichten, was zwangsläufig die Verwendung von X.509-Zertifikaten (SSL-Zertifikaten) erfordert. Durch die Verwendung von HTTPS stellen wir sicher, dass alle Verbindungen sicher verschlüsselt werden.

    In einem typischen Szenario, in dem der öffentliche Load Balancer als primärer Einstiegspunkt für Endbenutzer im Internet dient, müssen SSL-Zertifikate hochgeladen werden, die von einer seriösen öffentlichen Certificate Authority (CA) signiert wurden, wie Digicert, Global Sign, Let's Encrypt und andere. Darüber hinaus müssen diese Zertifikate, die dem Internet ausgesetzt sind, in der Nähe ihres Ablaufdatums erneuert werden, um sicherzustellen, dass Kunden keine unnötigen Nachrichten wie Ihre Verbindung ist nicht privat!! ERR_CERT_DATE_INVALID.

    In diesem Tutorial verwenden wir die OCI WAF-Edge als Haupteinstiegspunkt für Benutzer, die auf die Webservices im Internet zugreifen. Die öffentlichen Load Balancer, von denen unsere Services stammen, werden hinter der OCI-WAF-Edge positioniert, was bedeutet, dass sie nur Traffic von OCI-WAF-Edge-Knoten empfangen. Aufgrund dieses Setups ist es nicht erforderlich, ein SSL-Zertifikat von einer öffentlichen CA in den Load Balancer hochzuladen. Stattdessen können wir einfach ein selbstsigniertes SSL-Zertifikat ohne Ablaufdatum oder ein sehr langes installieren, was die Verwaltung vereinfacht.

    Beachten Sie, dass die OCI WAF-Edge weder die Details der vom Load Balancer empfangenen SSL-Zertifikate wie den allgemeinen Namen oder den alternativen Subject-Namen prüft, noch die Zertifikatsignatur prüft. Dennoch wird eine sichere und verschlüsselte Verbindung zwischen der OCI WAF-Edge und dem Zielursprung des OCI Load Balancers hergestellt.

    Wir haben ein selbstsigniertes Zertifikat mit einem beliebigen externen Tool wie openssl oder XCA erstellt. Alternativ können Sie den verwalteten Oracle Certificates-Service verwenden, der in OCI Load Balancer integriert ist. In diesem Tutorial haben wir XCA verwendet, um das selbstsignierte Zertifikat zu erstellen und es manuell in OCI Load Balancer zusammen mit dem Private Key hochgeladen. Das hochgeladene selbstsignierte Zertifikat verwendet einen beliebigen allgemeinen Namen oder SAN und hat eine Ablaufzeit von 50 Jahren. OCI WAF prüft diese Informationen nicht.

  5. Die Option Logging verwalten ist eine optionale Konfiguration und nicht im Geltungsbereich für dieses Tutorial. Klicken Sie auf Weiterleiten.

  6. Nach einer Weile wird der Load Balancer erstellt. Jetzt müssen wir die Backend-Server konfigurieren. Da SSL für die Backend-Server verwendet wird, müssen wir zuerst mindestens ein Zertifikat im Zertifikatsabschnitt des Load Balancers erstellen, mit dem die SSL-Verbindung zu Backend-Servern eingerichtet wird. Wie oben beschrieben, kann dieses Zertifikats-Bundle manuell mit Tools von Drittanbietern erstellt werden, oder Sie können den OCI Certificates-Managementservice verwenden. Für dieses Tutorial verwenden wir das XCA-Tool.

    Gehen Sie zu Networking, Load Balancer, Load Balancer, Load-Balancer-Details und Zertifikate.

  7. Wählen Sie im Abschnitt Zertifikat als Load-Balancer-Zertifikat verwalten die Option Zertifikatsressource aus, und klicken Sie auf Zertifikat hinzufügen.

    Load Balancer-Zertifikatsquelle

    Fügen Sie das öffentliche CA-Root- oder Zwischen-CA-Zertifikat hinzu, mit dem Sie die SSL-Zertifikate des Backend-Servers signiert haben. Zur Erinnerung: Wir haben selbstsignierte Zertifikate mit einem beliebigen gemeinsamen Namen und SAN und ohne Ablaufdatum verwendet. Sie müssen hier keine Serverzertifikate installieren, da der Load Balancer ausschließlich die Root-CA für die Validierung des Backend-Serverzertifikats verwendet.

    Load Balancer - Zertifikat wird hinzugefügt

  8. Um die Backend-Server zu erstellen, wählen Sie BackEnd-Sets aus, und klicken Sie auf Backend-Set erstellen.

    Backend-Set 1 für Load Balancer

  9. Geben Sie unter Backend-Set erstellen die folgenden Informationen ein.

    • Backend-Setname: Geben Sie den Namen des Backend-Sets ein.
    • Wählen Sie SSL aus.
    • Wählen Sie Load Balancer-Zertifikat verwalten aus.
    • Fügen Sie das Zertifikat hinzu, das Sie in Schritt 7 erstellt haben. Wenn Sie sicherstellen möchten, dass der Load Balancer die empfangene SSL-Zertifikatsignatur prüft, klicken Sie auf Peerzertifikat prüfen.
    • Health Checks:
      • Protokoll: Wählen Sie HTTP aus.
      • Port: Wählen Sie den Port 443 aus.
      • Intervalle und Timeout: Standardintervall und -timeout (10000 und 3000 ms) beibehalten.
      • Wählen Sie für die Health Check-Antwort 200 aus.
      • URL-Pfad (URI): Fügen Sie eine Ressource aus einer URL hinzu, die auf dem Webserver vorhanden ist. Beispiel: index.html, mainpage.html usw.

    Backend-Set 1 für Load Balancer

Aufgabe 6: OCI Network Firewall konfigurieren

Nachdem OCI Load Balancer eingerichtet wurde, ist es unser Ziel, eine OCI Network Firewall zu konfigurieren, um den Nord-Süd-Traffic zu schützen. Die Firewall wird zwischen dem neu konfigurierten Load Balancer und dem Internetgateway positioniert. Informationen zum Einrichten der OCI-Netzwerkfirewall finden Sie unter OCI-Netzwerkfirewall für SSL-Weiterleitungsproxy und eingehende Prüfung mit Entschlüsselungsregel verwenden, und führen Sie die folgenden Schritte aus.

Aufgabe 7: OCI-Routing konfigurieren

Die OCI Network Firewall wurde bereitgestellt. Wir müssen sicherstellen, dass der Nord-Süd-Traffic sie in beide Richtungen durchläuft. Als Erstes müssen Sie eine dedizierte Routing-Tabelle für das Internetgateway erstellen, das mit dem VCN verknüpft ist, in dem sich die OCI-Netzwerkfirewall befindet.

  1. Erstellen Sie die Routing-Tabelle im VCN, und fügen Sie einen Eintrag mit dem Zieltyp als private IP, Ziel als CIDR-Block hinzu. Dabei wird der CIDR-Block des Load-Balancer-Subnetzes für dieses Tutorial 192.168.6.0/24 und Ziel als private IP-Adresse eingeführt, die der OCI-Netzwerkfirewall zugewiesen ist, die in Aufgabe 6 bereitgestellt wird.

    Internet-GW-Routentabelle

  2. Verknüpfen Sie die Routingtabelle mit dem Internetgateway, klicken Sie auf drei Punkte, und wählen Sie die Routentabelle verknüpfen und dann die Routingtabelle aus.

    Internet-GW-Routentabelle

  3. Nachdem diese Routingtabelle mit dem Internetgateway verknüpft wurde, wird der gesamte Traffic, der an den öffentlichen Load Balancer 192.168.6.0/24 geleitet wird, zunächst an die private IP 192.168.5.78 umgeleitet, in der sich die OCI-Netzwerkfirewall befindet.

    Von der privaten IP 192.168.5.78 der OCI Network Firewall aus wird das Paket nach der Paketprüfung von der OCI Network Firewall seinen Weg zum OCI Load Balancer fortsetzen. Von dort werden sie zu ihrem endgültigen Ziel zwischen den ausgewählten Backend-Servern weitergeleitet, die von der Routingkonfiguration des Load Balancers bestimmt werden.

    Jetzt ist es wichtig, sicherzustellen, dass Pakete, die an Internetbenutzer zurückgegeben werden, in umgekehrter Reihenfolge denselben Pfad befolgen und die OCI Network Firewall zur Prüfung von Antworten durchlaufen. Wir müssen eine Routingtabelle für das öffentliche Load-Balancer-Subnetz erstellen, um die Antworten von Backend-Servern über die private IP 192.168.5.78 der OCI Network Firewall weiterzuleiten, wie in der folgenden Abbildung dargestellt.

    Load Balancer-Routentabelle

Vom OCI-Netzwerkfirewallsubnetz aus müssen wir sicherstellen, dass die Antworten an das Internetgateway weitergeleitet werden, indem wir eine 0.0.0.0/0-Route zum Internetgateway hinzufügen.

Routentabelle für Netzwerkfirewall

Nachdem das Internetgateway erreicht wurde, werden die Packages zur abschließenden Prüfung der Antworten an ihre Quelle, die OCI-WAF-Edge, zurückgeleitet, bevor sie an Internetbenutzer weitergeleitet werden.

Danksagungen

Weitere Lernressourcen

Lernen Sie andere Übungen auf docs.oracle.com/learn kennen, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning YouTube Channel zu. Außerdem können Sie education.oracle.com/learning-explorer besuchen, um Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.