Hinweis:

OCI Network Firewall für SSL-Weiterleitungsproxy und eingehende Prüfung mit Entschlüsselungsregel verwenden

Einführung

Der Oracle Cloud Infrastructure (OCI) Network Firewall Service ist eine cloud-basierte verwaltete Firewalllösung, die mit der Firewalltechnologie der nächsten Generation (NGFW) von Palo Alto Networks arbeitet. Mit seinen hochmodernen Firewallfunktionen auf Basis des maschinellen Lernens bietet der OCI Network Firewall-Service erstklassigen Schutz für Ihre OCI-Workloads, während er gleichzeitig mühelos im OCI-Ökosystem verwendet werden kann.

Die OCI Network Firewall prüft alle Anforderungen, einschließlich TLS-(Transport Layer Security-)verschlüsselter Traffic, während sie die Firewall durchläuft. Basierend auf Ihren benutzerdefinierten Firewall-Policy-Regeln kann der Service eine Vielzahl von Aktionen ausführen, darunter Zulassen, Ablehnen, Löschen, Erkennen von Angriffen oder Verhinderung. Mit diesen robusten Features ist OCI Network Firewall ein leistungsstarkes Tool zum Schutz Ihrer OCI-Workloads vor einer Vielzahl von Sicherheitsbedrohungen.

Ziele

Dieses Tutorial enthält einen umfassenden Leitfaden zur Implementierung von SSL-Forward-Proxy und eingehender Prüfung mit Entschlüsselungsregeln in der Firewall der nächsten Generation in OCI Cloud.

Durch die Befolgung dieses Tutorials haben Sie ein umfassendes Verständnis des SSL-Forward-Proxys und der eingehenden Prüfung anhand von Entschlüsselungsregeln und können dieses Wissen anwenden, um Ihre Netzwerkinfrastruktur in OCI Cloud zu sichern.

Voraussetzungen

Hinweis: Es wird empfohlen, dass Sie eine Testumgebung in OCI für das Experimentieren mit Firewallkonfigurationen und Entschlüsselungsregeln eingerichtet haben, bevor Sie sie in einer Produktionsumgebung implementieren.

Architektur

Architektur

OCI Network-Firewall-Policy besteht aus Listen, die Folgendes enthalten:

Testfall

Für dieses Tutorial haben wir eine SSH-Verbindung zum Linux-Rechner (in öffentlichem Subnetz: 129.146.201.118) über das Internet hergestellt, indem eine Sicherheitsregel in der Firewallrichtlinie vorhanden ist.

Jetzt haben Sie eine Vorstellung davon, wie Listen zum Erstellen von Sicherheitsregeln für Ihre Firewall verwendet werden können. Mit dieser Regel haben wir eine SSH-Verbindung zum Linux-Rechner hergestellt.

TLS-/SSL-Verschlüsselungstechnologie verstehen

Hinweis:

TLS ist ein kryptografisches Protokoll, das End-to-End-Sicherheit für Daten bietet, die zwischen Anwendungen über das Internet gesendet werden. Die häufigsten Szenarios sind sicheres Surfen im Internet. Sie kann und sollte jedoch auch für andere Anwendungen wie E-Mail, Dateiübertragungen, Video-/Audiokonferenzen, Instant Messaging und Voice-over-IP usw. verwendet werden.

Es ist wichtig zu verstehen, dass TLS keine Daten auf Endsystemen sichert. Sie gewährleistet die sichere Übermittlung von Daten über das Internet, um ein mögliches Löschen und/oder Ändern des gesendeten Inhalts (in Übertragung) zu vermeiden. TLS wird normalerweise über TCP implementiert, um Protokolle der Anwendungsschicht wie HTTP, FTP, SMTP und IMAP zu verschlüsseln, obwohl sie auch in UDP, DCCP und SCTP implementiert werden können.

Zum Schutz der Daten nutzt TLS die Kryptografietechnologie, um die über das Internet gesendeten Daten während der Übertragung zu verschlüsseln/zu entschlüsseln. Dabei werden Begriffe und Konzepte wie symmetrische und asymmetrische Kryptographie, Public Key-Infrastruktur (PKI) und digitale X.509 Zertifikate behandelt.

Um eine Firewall der nächsten Generation für Ihr Netzwerk einzurichten, zu konfigurieren und anzuwenden, müssen Sie verstehen, wie TLS-Verbindungen (wie https) funktionieren, einschließlich der Konfiguration und Bereitstellung von digitalen X.509-Zertifikaten.

Verschlüsselung und Typen

Die Idee hinter Verschlüsselung besteht gerade darin, die Informationen, die wir von A nach B senden möchten, in einem "unsicheren Kanal" zu verbergen oder zu verbergen (verschlüsseln). Ein unsicherer Kanal ist ein Kanal oder ein Pfad, in dem wir nicht garantieren können, dass niemand die von A nach B übertragenen Informationen abfangen, stehlen oder modifizieren wird.

Die Kryptographie ermöglicht es uns, die Informationen, die durch einen unsicheren Kanal reisen, zu sichern, indem wir die ursprünglichen Daten zu ihrem Ziel verschlüsseln (koncealing). Nach Empfang durch den Empfänger kann der Empfänger die empfangenen verschlüsselten Daten auf seinen ursprünglichen Wert entschlüsseln.

Es gibt zwei Arten von Verschlüsselung: Symmetrisch und Asymmetrisch.

Symmetrische Verschlüsselung

Um einen Datenblock zu verschlüsseln/entschlüsseln, verwenden symmetrische Verschlüsselungs-Engines genau denselben Schlüssel, um die Daten zu verschlüsseln und zu entschlüsseln. Dies wird normalerweise als Masterschlüssel oder gemeinsam verwendetes Secret bezeichnet.

Masterschlüsselung

Obwohl die Verschlüsselung ganz einfach zu erreichen klingt, besteht das Hauptproblem in der Verteilung des Masterschlüssels zwischen den beiden Parteien über einen unsicheren Kanal. Dieser Master Key Exchange-Prozess wird in diesem Tutorial mit verschiedenen Techniken behandelt, einschließlich einer im folgenden Abschnitt erläuterten Technik: Asymmetrische Verschlüsselung.

Einige der häufigsten symmetrischen Verschlüsselungsalgorithmen sind: AES128, AES256, Serpent, Camelia usw.

Asymmetrische Verschlüsselung

Asymmetrische Verschlüsselung/Kryptographie verwendet ein Paar zusammengehöriger Schlüssel mit einer speziellen Beziehung: Alle Daten, die Sie mit einem der Paartasten verschlüsseln, können nur von dem anderen Paarschlüssel verschlüsselt werden.

Asymmetrische Verschlüsselung

Normalerweise wird dieser Paarschlüssel als Public Key und Private Key bezeichnet. Der Public Key kann für alle Benutzer freigegeben werden, während der Private Key geheim gehalten werden muss.

Asymmetrische Verschlüsselung löst das Problem der Schlüsselverteilung, indem Public Keys für Verschlüsselung und Private Keys für die Entschlüsselung (oder umgekehrt) verwendet werden. Der Kompromiss besteht jedoch darin, dass asymmetrische Verschlüsselungssysteme im Vergleich zu symmetrischen Systemen sehr langsam sind und aufgrund ihrer extrem längeren Schlüssellängen viel mehr Rechenleistung erfordern.

Symmetrische Verschlüsselungsalgorithmen sind viel schneller und erfordern weniger Rechenleistung. Ihre Hauptschwäche ist jedoch die Schlüsselverteilung, da derselbe Schlüssel zum Verschlüsseln und Entschlüsseln von Informationen verwendet wird. Dieser Schlüssel muss an jeden weitergegeben werden, der auf die Daten zugreifen muss.

TLS verwendet asymmetrische und symmetrische Verschlüsselung und dient nicht nur zur Verschlüsselung von Daten, sondern auch zur Authentifizierung der an der Verbindung beteiligten Parteien. Hier ergreifen X.509-Zertifikate die Aktion.

X.509-Zertifikate

Ein X.509-Zertifikat ist ein digitales Zertifikat, das auf dem allgemein anerkannten X.509-Standard der Internationalen Telekommunikationsunion (ITU) basiert und das Format von PublicKey-Infrastrukturzertifikaten (PKI ) definiert. Ein X.509-Zertifikat wird mit einem Schlüsselpaar entworfen, das aus einem zugehörigen Public Key und einem Private Key besteht. Wie bereits erwähnt, ist dieses Schlüsselpaar genau das Schlüsselpaar, das bei der asymmetrischen Verschlüsselung verwendet wird, wobei wir wählen, dass eines öffentlich und das andere privat sein soll. Denken Sie daran, dass alles, was Sie mit einem der Schlüssel verschlüsseln, nur vom anderen Schlüssel und umgekehrt entschlüsselt werden kann.

Wie Sie sich vorstellen können, ist der öffentliche Teil des Schlüsselpaars, wie sein Name schon sagt, öffentlich und kann frei verteilt werden. Der Private Key muss sicher beibehalten und oft mit einem Masterschlüssel im symmetrischen Verschlüsselungsmodus verschlüsselt sein, sodass niemand ihn auch verwenden kann, wenn er gestohlen wird.

Neben dem Public Key enthält das X.509-Zertifikat weitere Informationen, die eine Identität (einen Hostnamen, eine Organisation oder eine Person) darstellen. Daher bindet das x.509-Zertifikat diese Identität an den enthaltenen Public Key.

Das digitale Zertifikat X.509 v3 ist wie folgt aufgebaut:

Zertifikat

Versionsnummer

Seriennummer

Algorithmus-ID für Signatur

Ausstellername

Gültigkeitszeitraum

Nicht vor

Nicht nach

Betreffname

Info zu Public Key von Betreff

Public-Key-Algorithmus

Betreff-Public KEY Erlaubnis Dies ist der öffentliche Schlüssel

Eindeutige ID des Ausstellers (optional)

Eindeutige Subject-ID (optional)

Erweiterungen (optional)

…

Zertifikatsunterzeichnungs-Algorithmus

Zertifikatsunterschrift

Der Public Key ist an eine im Subject-Namen dargestellte Identität gebunden, bei der es sich um eine Zeichenfolge mit dem folgenden Format handelt:

Hierbei gilt: C = US, ST = Kalifornien, L = Mountain View, O = Google LLC, CN = *.google.com

Diese Identität gehört also zu Google, in US-Land, State California und einem allgemeinen Namen als *.google.com.

Dieses Zertifikat dient zwei Zwecken: Verteilen Sie unseren Public Key UND Authentifizieren Sie unsere Identität an andere. In diesem Sinne, jeder Computer/Mobil/Gerät da draußen, wenn er unser Zertifikat erhält, wird er unseren öffentlichen Schlüssel und unsere Identität besitzen, daher kann er verschlüsselte Informationen mit dem öffentlichen Schlüssel senden, und nur wir werden es (mit dem privaten Schlüssel) entschlüsseln können. Darüber hinaus hat das Zertifikat unsere Identität im Inneren, sodass das Gerät, das es empfängt, dieser Identität vertrauen kann und sicher sein kann, dass es Informationen mit der richtigen Identität austauscht.

Wie bereits erwähnt, ist die asymmetrische Verschlüsselung über Public/Private Keys viel langsamer als die symmetrische Verschlüsselung (x4 oder mehr), sodass sie nicht praktikabel ist. Darüber hinaus haben wir nicht erklärt, wie das Gerät, das das Zertifikat erhält, der Identität innerhalb des Zertifikats wirklich vertrauen kann. Am Ende ist das X.509-Zertifikat nur ein Text, der über einen unsicheren Kanal empfangen wird. Um einem empfangenen Zertifikat vertrauen/authentifizieren zu können, benötigen wir eine Certificate Authority, eine Organisation, die vertraut ist, um digitale Zertifikate signieren. Eine Certificate Authority überprüft die Identität und Legitimität eines Unternehmens oder einer Person, das ein Zertifikat angefordert hat. Wenn die Prüfung erfolgreich ist, gibt CA ein signiertes Zertifikat aus. Beispiele für CA-Organisationen sind Oracle, VeriSign, D-Trust, DigiCert unter anderem.

Wie funktioniert dieser Signaturprozess aus kryptografischer Sicht? Auch hier wird die Leistung asymmetrischer Verschlüsselung wie folgt genutzt:

Jetzt, da wir unser X.509-Zertifikat bereit haben, Maßnahmen zu ergreifen. Wie kann ein Computer/Mobil/Gerät, der dieses Zertifikat während einer TLS-Verbindung empfängt, überprüfen, ob es sich um ein gültiges X.509-Zertifikat handelt? Auch hier wird die Leistung der asymmetrischen Verschlüsselung wie folgt genutzt:

Da wir jetzt wissen, dass wir ein gültiges Zertifikat mit dem Domainnamen haben, zu dem wir versuchen, eine Verbindung herzustellen, z.B. www.mycompanycomain.com (im allgemeinen Namen enthalten oder im Feld "Subject Alternative name" aus dem Zertifikat), stellt der Computer/Mobil/Browser sicher, dass wir tatsächlich eine Verbindung zu diesem DNS-Domainnamen (www.mycompanycomain.com) und nicht zu einem anderen herstellen. Dies ist eine obligatorische Validierung, da jeder das X.509-Zertifikat stehlen und versuchen kann, es von einem anderen DNS-Domainserver (www.myfakecompany.com usw.) zu verwenden und den Validierungsprozess der CA-Signatur durchlaufen würde.

Also können jetzt alle Computer/Mobilgeräte/Geräte da draußen den öffentlichen Schlüssel unseres Zertifikats herunterladen und verschlüsselte Daten senden, damit wir ihn nur entschlüsseln können. Da die asymmetrische Verschlüsselung wesentlich langsamer ist als die symmetrische Verschlüsselung (x4 oder mehr), ist sie nicht realisierbar. In dieser Lösung sollen beide verwendet werden. Hier ist SSL/TLS erforderlich.

TLS-Grundlagen

TLS ist ein kryptografisches Protokoll, das eine End-to-End-Sicherheit der Daten bietet, die zwischen Anwendungen über das Internet gesendet werden. Es ist den Benutzern hauptsächlich durch die Verwendung im sicheren Surfen vertraut, insbesondere durch das Vorhängeschloss-Symbol, das bei der Einrichtung einer sicheren Sitzung in Webbrowsern angezeigt wird.

TLS verwendet eine Kombination aus symmetrischer und asymmetrischer Kryptografie, da dies einen guten Kompromiss zwischen Performance und Sicherheit bei der sicheren Datenübertragung darstellt. Denken Sie daran, dass asymmetrische Kryptographie 4x oder mehr Rechenleistung erfordert als symmetrische Kryptographie. Für die symmetrische Kryptografie muss jedoch auf beiden Seiten der Kommunikation derselbe Masterschlüssel verwendet werden, um die Nachricht verschlüsseln/entschlüsseln zu können. Daher ist es das Ziel für die Verwendung der symmetrischen Verschlüsselung, um die Nachricht austauschen zu können. Master-Schlüssel (oder Shared Secret) zwischen den beiden Parteien zuerst über einen unsicheren Kanal und dann mit diesem Masterschlüssel beginnen, um die Kommunikation zu sichern und jede Nachricht zu verschlüsseln/zu entschlüsseln, die mit der gewählten symmetrischen Engine gesendet/empfangen wird.

TLS, Hacker-Grafik

Um einen Masterschlüssel über einen unsicheren Kanal auszutauschen, verwendet TLS zwei verschiedene Techniken, die demselben Ziel folgen. Dies ist der sichere Austausch des Masterschlüssels/gemeinsam genutzten Secrets in einem unsicheren Kanal:

Die RSA-Methodik setzt voraus, dass die asymmetrische Verschlüsselung (Private und Public Key) zum Austauschen des Masterschlüssels über einen unsicheren Kanal genutzt wird.

DHE/ECDHE nutzt mathematische Berechnungen, um denselben Masterschlüssel zwischen zwei Parteien über einen unsicheren Kanal generieren zu können. Beide Parteien werden bestimmte gutartige Informationen austauschen, die mit ihren privilegierten Informationen gemischt werden, wenn sie über einen unsicheren Kanal reisen und ohne Risiko erfasst werden können. Am Ende der Verhandlungen werden beide mathematische Berechnungen der beiden Parteien auf dem gleichen gemeinsamen Geheim- oder Masterschlüssel enden. Weitere Informationen https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Diese beiden Schlüsselaustauschmethoden finden während eines Prozesses namens TLS-Handshake statt.

TLS-Handshake ohne Maskierung

Ein SSL/TLS-Handshake ist eine Verhandlung zwischen zwei Parteien in einem Netzwerk - wie einem Browser und einem Webserver -, um die Details ihrer Verbindung herzustellen. Während dieser Verhandlung werden sich die beiden Parteien authentifizieren (mit X509-Zertifikaten), eine Cipher Suite gründen (wie der Masterschlüssel ausgetauscht wird und welche Verschlüsselungs-Engines verwendet werden, wie AES256, 128, Hashing wie SHA1, 2 usw.) und schließlich, wenn die Authentifizierung erfolgt (gültiges Zertifikat empfangen) und die Vereinbarung über die Einrichtung eines sicheren Kanals erfolgt, haben wir einen sicheren Kanal von beiden Parteien. Dies sind die tatsächlichen Schritte:

TLS-Handshake

Beachten Sie, dass wir im obigen Diagramm RSA (Private/Public Key) verwenden, um den Master-Schlüssel (oder Shared Secret) auszutauschen, der in der vereinbarten symmetrischen Verschlüsselungs-Engine (d.h. AES256 ) während der Cipher-Suite-Aushandlung verwendet werden soll. Wenn DHE/ECDHE zum Austausch des Masterschlüssels verwendet wurde, würden beide Parteien DHE-Berechnungen verwenden, um benigne Materialien auszutauschen, um das gleiche Ergebnis auf beiden Seiten zu berechnen. Dieses Ergebnis wird zum Masterschlüssel (Shared Secret), der für die symmetrische Verschlüsselung verwendet werden soll.

Aufgabe 1: OCI Network Firewall für SSL-Weiterleitungsproxy und eingehende Prüfung mit Entschlüsselungsregel verwenden

  1. Erstellen Sie zwei selbstsignierte Zertifikate mit opensl für ausgehenden Traffic und eingehende Prüfung mit Open SSL auf dem Linux-Rechner. Aktualisieren Sie den Linux-Rechner, um dem Zertifikat zu vertrauen.

    selbstsignierte Zertifikate erstellen

  2. Erstellen Sie einen Vault in OCI.

    Springen

  3. Nachdem der Vault erstellt wurde, Erstellen Sie einen Schlüssel. Der Secret-Inhalt muss das folgende Format aufweisen.

    {

"caCertOrderedList":

[

"-----BEGIN CERTIFICATE

-----END CERTIFICATE-----\n"

],

"certKeyPair":

{

"cert" : "-----BEGIN CERTIFICATE

-----END CERTIFICATE----\n",

"key": "-----BEGIN RSA PRIVATE KEY

-----END RSA PRIVATE KEY----\n"

}

}

  4. Fügen Sie in der Netzwerkfirewall-Policy das zugeordnete Secret hinzu.

    1. Wählen Sie den zugeordneten Secret-Typ als SSL-Forward-Proxy oder eingehende SSL-Prüfung aus.

    2. Wählen Sie den erstellten Vault aus.

    3. Wählen Sie das Secret aus.

    4. Fügen Sie das zugeordnete Secret hinzu.

      Zugeordnetes Secret

  5. Erstellen Sie ein Entschlüsselungsprofil.

    1. Wählen Sie "SSL Forward Proxy", und prüfen Sie die Serverzertifikatverifizierungsoptionen, oder wählen Sie die eingehende SSL-Prüfung aus, und prüfen Sie die nicht unterstützten Modusprüfungen, die für Ihren Datenverkehr erforderlich sind.

      Entschlüsselungsprofil vorwärts

      Entschlüsselungsprofil eingehend

    2. Entschlüsselungsprofil hinzufügen.

      Entschlüsselungsprofil wird hinzugefügt

  6. Entschlüsselungsregel erstellen.

    1. Wählen Sie Quell-IP-Adressen aus der IP-Adressliste, die Sie in der Policy erstellt haben, oder wählen Sie eine beliebige Adresse aus.

    2. Wählen Sie die Ziel-IP-Adressen aus der IP-Adressliste aus, die Sie in der Policy erstellt haben, oder wählen Sie eine beliebige Adresse aus.

      Ziel-IP-Adresse

    3. Wählen Sie "Aktion", um Traffic mit SSL-Weiterleitungsproxy, SSL-eingehend oder ohne Entschlüsselung zu entschlüsseln.

    4. Wählen Sie das Entschlüsselungsprofil und das zugeordnete Secret aus.

      Entschlüsselungsprofil wählen

Sobald die Policy mit der Entschlüsselungsregel aktualisiert wurde, kann sie an die Firewall angehängt werden.

Aufgabe 2: Policy an die Firewall anhängen

Wenn Sie die Netzwerkfirewall erstellen, können Sie die Policy auswählen, die an die Firewall angehängt werden soll.

NetworkFirewall-Anhang

Wir haben eine Entschlüsselungsregel erstellt, um den Traffic über den SSL-Weiterleitungsproxy und eine für die eingehende SSL-Prüfung zu entschlüsseln. Wie für die ausgehende SSL-Verbindung erwähnt, wird der gesamte Traffic von unserem öffentlichen Subnetz zu OCI Network Firewall und über OCI Network Firewall geleitet und nimmt einen Pfad von Internetgateway zu Internet an.

Für die eingehende Prüfung durchläuft das Internetgateway den nächsten HOP als Firewall und greift dann auf den Linux-Rechner im öffentlichen Subnetz zu.

Gemäß der Entschlüsselungsregel muss für die Quell-IP-Adresse der Hub-Linux-Machine und für jede Ziel-IP-Adresse der Traffic vom SSL-Forward-Proxy entschlüsselt werden. Für eingehende Verbindungen für die Quelle als beliebige und das Ziel als Hub-Linux-Machine muss der Traffic mit der eingehenden SSL-Prüfung entschlüsselt werden.

Verschlüsselungsregeln

Hinweis: Für jeden Datenverkehr, der auf die Firewall trifft, werden zuerst die Entschlüsselungsregeln und dann die Sicherheitsregeln geprüft.

Frage: Wie kann ich ermitteln, ob die Entschlüsselungsregel für Datenverkehr vorhanden ist, der auf die Firewall trifft?

Antwort: Dies wird in den Metriken mit dem Namen "Anzahl Entschlüsselungsregel-Treffer" angezeigt, der an die Firewall angehängt ist.

Jedes Mal, wenn der Linux-Rechner versucht, HTTP-Websites im Internet oder eingehende Verbindungen zum Linux-Rechner auf HTTPS zu erreichen, erhöht sich die Anzahl der Entschlüsselungsregel-Treffer.

Netzwerkfirewallmetrik

Aufgabe 3: Entschlüsselungsregel mit einer Sicherheitsregel verwenden, um Traffic zuzulassen oder abzulehnen

Wenn Sie den obigen Anwendungsfall hinzufügen, sehen Sie, wie die Entschlüsselungsregel mit einer Sicherheitsregel verwendet werden kann, um Traffic zuzulassen oder abzulehnen. Wie am Anfang des Testfalls erwähnt, können wir Listen verwenden, um den Verkehr zuzulassen oder abzulehnen.

Hier haben wir bereits eine Entschlüsselungsregel für SSL-Forward-Proxy und eingehende SSL-Prüfung erstellt. Zu Testzwecken haben wir eine Sicherheitsregel für ausgehende Verbindungen vom Hub-Linux-Rechner zum Internet erstellt, um Zugriff auf *.oracle.com zu ermöglichen.

Hinweis: Standardmäßig wird dem gesamten Traffic der Zugriff auf die OCI-Netzwerkfirewall verweigert. Für den zuzulassenden Traffic muss eine Regel erstellt werden.

URL-Liste:

URL-Liste

Sicherheitsregel:

Sicherheitsregel

Was geschieht, wenn der Linux-Rechner versucht, auf *.oracle.com im Internet über die OCI Network Firewall zuzugreifen.

Frage: Wie kann ich sehen, welche Regel für den Traffic stattfindet?

Antwort: Sie wird in den OCI Network Firewall-Logs angezeigt.

Für oracle.com

Netzwerkfirewalllogs 1

Für jede andere URL:

Netzwerkfirewalllogs 2

Bestätigungen

Autoren - Luis Catalán Hernández (OCI Cloud Network Specialist und Multi Cloud), Sachin Sharma (OCI Senior Cloud Specialist)

Weitere Lernressourcen

Sehen Sie sich andere Übungen zu docs.oracle.com/learn an, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning YouTube-Kanal zu. Besuchen Sie außerdem die Website education.oracle.com/learning-explorer, um Oracle Learning Explorer zu werden.

Produktdokumentation finden Sie im Oracle Help Center.