Sichere Kommunikation mit TLS- und mTLS-Unterstützung (Daten im Transit)

Oracle GoldenGate schützt Daten während der Übertragung oder während der Übertragung mit den folgenden Features:

Streaming-Protokolle mit nativer HTTP-Autorisierung werden unterstützt. Sie enthält einen Header in der anfänglichen WebSocket-Einrichtungsanforderung, bei der es sich um das Secure Web Socket-(WSS-)Protokoll handelt. Der Oracle GoldenGate-Server prüft den Autorisierungsheader, um die Anforderung zu genehmigen oder abzulehnen, je nachdem, ob die dem anfordernden Benutzer zugeordnete Rolle der für Web-Socket-Einrichtungsanforderungen zugewiesenen Rolle entspricht oder größer ist. Oracle GoldenGate unterstützt die TLS 1.2- und TLS 1.3-Authentifizierung. Sie können zwischen verschiedenen TLS-Verschlüsselungsoptionen wählen und die entsprechenden Cipher Suites anwenden.
Zielinitiierte Pfade unterstützen den Datenübergang bei der Arbeit in Demilitarized Zones (DMZ).

Siehe auch Distribution Path Streaming Protocols.

Sichere Kommunikation mit TLS- und mTLS-Unterstützung

Das Transport Layer Security-(TLS-)Protokoll ermöglicht eine sichere Kommunikation über ein Netzwerk, indem eine sichere Datenübertragung sichergestellt wird. Der Datenaustausch zwischen dem Server (GoldenGate-Instanz) und den Clients, einschließlich der GoldenGate-Weboberfläche, AdminClient und anderen Anwendungen, wird authentifiziert und verschlüsselt. Es verwendet kryptografische Algorithmen, um Daten zu verschlüsseln und zu verhindern, dass unbefugte Personen auf die übertragenen Informationen zugreifen oder diese ändern.

TLS überprüft die Identität des Servers, um sicherzustellen, dass die Kommunikation mit der beabsichtigten Partei und nicht mit einem böswilligen Akteur erfolgt. HTTPS und WSS verwenden das TLS-Protokoll. HTTPS-Anforderungen werden über REST-API-Aufrufe ausgeführt, und WSS wird für das sichere Routing von Traildateien über den Verteilungspfad verwendet.

Mutual TLS (mTLS) ist eine Erweiterung des TLS-Protokolls, das eine zusätzliche Sicherheitsebene hinzufügt, indem sowohl der Client als auch der Server in einer Kommunikationssitzung authentifiziert werden. Es ist eine Erweiterung der traditionellen TLS, die ein wechselseitiges Vertrauen bietet, und ist eine zusätzliche Verteidigung gegen imitierte Angriffe. Während des Client-Server-Handshakes präsentiert der Server sein digitales Zertifikat, um seine Identität dem Client nachzuweisen, sodass der Client die Identität des Servers überprüft. Der Client stellt außerdem sein digitales Zertifikat vor, um seine Identität dem Server zu beweisen, sodass der Server die Client-Identität prüft.

In einem sicheren Deployment wird mTLS vom Verteilungspfadprozess verwendet, um Traildateien mit dem WSS-Protokoll in einem der folgenden Fälle zu senden:

Traildaten vom Verteilungsdienst an den Empfängerdienst senden
Senden von Traildaten über den Zielverteilungspfad, bei dem der Empfangsservice den Verteilungsdienst anfordert, Traildateien über das Netzwerk zu senden.

Wenn Sie die Distribution Client-(DistClient-)Authentifizierung verwenden, indem Sie das digitale Zertifikat DistClient präsentieren, wird eine sichere Netzwerkkommunikation mit mTLS ermöglicht.

Für Oracle GoldenGate wird ein sicheres Deployment empfohlen. Es erfordert das Zertifikat des Servers, den Private Key und das Signaturzertifikat von der Certificate Authority (CA-Zertifikat). Das Zertifikat DistClient, der Private Key und das Signaturzertifikat der Certificate Authority (CA-Zertifikat) können jederzeit angewendet werden.

NGINX könnte jedoch mit einem unsicheren Deployment verwendet werden, um weiterhin TLS-Unterstützung für den Verteilungspfad bereitzustellen. Die TLS wird bei NGINX beendet. Das NGINX-Zertifikat wird vom Client geprüft. Das Clientzertifikat ist jedoch von der Oracle GoldenGate-Standardkonfiguration für NGINX optional.

Weitere Informationen finden Sie unter Zielinitiierter Pfad und Oracle GoldenGate-Reverse Proxy-Unterstützung. Hinweis: mTLS wird nicht unterstützt, wenn ein Reverse Proxy verwendet wird.

Funktionsweise von Transport Layer Security in einer Oracle-Umgebung: TLS-Handshake

Wenn eine Netzwerkverbindung über Transport Layer Security initiiert wird, führen Client und Server vor der Authentifizierung einen TLS-Handshake aus.

Der Handshake-Prozess ist wie folgt:

Der Client und die Oracle GoldenGate-Instanz legen die Cipher Suites und die Verschlüsselungsalgorithmen fest, die für Datenübertragungen verwendet werden.
Die Oracle GoldenGate-Instanz sendet das Zertifikat an den Client, und der Client prüft, ob das Zertifikat der Oracle GoldenGate-Instanz von einer vertrauenswürdigen CA signiert wurde. Dieser Schritt prüft die Identität der Oracle GoldenGate-Instanz.
Wenn eine Clientauthentifizierung erforderlich ist, sendet der Client sein Zertifikat an die Oracle GoldenGate-Instanz. Die Oracle GoldenGate-Instanz prüft, ob das Zertifikat des Clients von einer vertrauenswürdigen CA signiert wurde.
Der Client und die Oracle GoldenGate-Instanz tauschen Schlüsselinformationen mit Public-Key-Kryptografie aus. Basierend auf diesen Informationen generiert jeder einen Sitzungsschlüssel. Ein Schlüssel wird von mindestens zwei Parteien gemeinsam verwendet (in der Regel ein Client und eine Oracle GoldenGate-Instanz), die für die Datenverschlüsselung für die Dauer einer einzelnen Kommunikationssession verwendet werden. Sessionschlüssel werden normalerweise zur Verschlüsselung des Netzwerkverkehrs verwendet. Ein Client und eine Oracle GoldenGate-Instanz können einen Sessionschlüssel zu Beginn einer Session aushandeln. Dieser Schlüssel wird verwendet, um den gesamten Netzwerkverkehr zwischen den Parteien für diese Session zu verschlüsseln. Wenn der Client und die Oracle GoldenGate-Instanz in einer neuen Session erneut kommunizieren, verhandeln sie einen neuen Sessionschlüssel. Die gesamte nachfolgende Kommunikation zwischen dem Client und der Oracle GoldenGate-Instanz wird mit diesem Sessionschlüssel und der ausgehandelten Cipher Suite verschlüsselt und entschlüsselt.

Der Authentifizierungsprozess ist wie folgt: 1. Auf einem Client initiiert der Benutzer eine Netzwerkverbindung zu Oracle GoldenGate mit TLS.

TLS führt den Handshake zwischen dem Client und Oracle GoldenGate aus.
Wenn der Handshake erfolgreich ist, prüft die Instanz GoldenGate, ob der Benutzer über die entsprechende Autorisierung für den Zugriff auf die Oracle GoldenGate-Instanz verfügt.

Verwendung von Transport Layer Security in Oracle GoldenGate für die Authentifizierung

Wenn Sie die Oracle GoldenGate-TLS-Funktionalität zum Sichern der Kommunikation zwischen Oracle GoldenGate-Instanzen und -Clients verwenden, können Sie Folgendes tun:

Mit TLS die Verbindung zwischen Oracle GoldenGate-Instanzen und -Clients verschlüsseln
Authentifizieren Sie jeden Client oder jede andere Oracle GoldenGate-Instanz bei jeder anderen Oracle GoldenGate-Instanz, die für die Kommunikation über TLS konfiguriert ist.

Nachdem TLS eingerichtet wurde, muss die Oracle GoldenGate-Instanz den Client authentifizieren, um sicherzustellen, dass er über die richtigen Berechtigungen zum Senden von Trails verfügt. Folgende Authentifizierungsmodi werden verwendet:

Die Oracle GoldenGate-Instanz authentifiziert den Client mit der Benutzer-ID und dem Kennwort, die mindestens die Rolle Operator auf der Zielseite aufweisen. Die Benutzer-ID und das Kennwort werden als Alias auf der Clientseite gespeichert. Der Alias wird beim Erstellen des Verteilungspfads verwendet.

Unter Zwei Deployments mit externem RootCA-Zertifikat verbinden erfahren Sie, wie Sie einen Operatorrollenbenutzer einrichten und dann diese Benutzer-ID und diesen Kennwortalias beim Erstellen einer Verteilungspfadverbindung zwischen Remote-Deployments verwenden.
Die Oracle GoldenGate-Instanz verwendet das Clientzertifikat, um die Clientanforderung zu authentifizieren, vorausgesetzt, auf der Zielseite wurde ein entsprechender Zertifikatsbenutzer erstellt. Die Schritte zum Erstellen von Zertifikaten auf Client- und Serverseite finden Sie unter Zertifikate für sichere Deployments erstellen.
Die Oracle GoldenGate-Instanz authentifiziert den Client mit OAuth, wenn sie einen externen Identifizierungsprovider (IdP) wie IAM verwendet. Siehe Benutzerverwaltung an einen externen Identitätsprovider delegieren.

TLS-Cipher-Suites

Eine Cipher Suite gibt einen Algorithmus für jede der folgenden Aufgaben an:

Schlüsselaustausch
Massenverschlüsselung
Nachrichtenauthentifizierungscode (MAC)

Die Standard-Cipher Suites für TLS 1.2 und 1.3 werden mit Ausnahme der schwachen Cipher unterstützt.

Oracle empfiehlt dringend, dass Sie TLS 1.3 verwenden, um Ihre Sicherheitsanforderungen zu erfüllen.

Die Standard-Cipher Suites für TLS 1.2 werden mit Ausnahme der schwachen Cipher unterstützt.

Zielinitiierter Pfad

Mit vom Ziel initiierten Pfaden für Microservices kann der Empfängerservice einen Pfad zum Verteilungsservice im Ziel-Deployment initiieren und Traildateien abrufen. Mit dieser Funktion kann der Receiver-Service einen vom Ziel initiierten Pfad für Umgebungen wie Demilitarized Zone Paths (DMZ) oder Cloud-to-On-Premise erstellen, bei denen der Verteilungsservice im Oracle GoldenGate-Quell-Deployment keine Netzwerkverbindungen in der Zielumgebung für den Receiver-Service öffnen kann, weil Netzwerksicherheits-Policys erforderlich sind.

Wenn der Verteilungsdienst keine Verbindungen zum Empfangsservice initiieren kann, aber der Empfangsservice eine Verbindung zu dem Host initiieren kann, auf dem der Verteilungsservice ausgeführt wird, erstellt der Empfangsservice einen sicheren oder nicht sicheren vom Ziel initiierten Pfad zum Verteilungsservice über eine Firewall oder eine DMZ-Zone (Demilitarized) mit Oracle GoldenGate, um die angeforderten Traildateien abzurufen. Die Receiver Service-Endpunkte zeigen an, dass der Abruf der Traildateien vom Receiver Service initiiert wurde.

Ein Pfad (schreibgeschützt) wird aus dem Empfangsservice des Ziel-Deployments erstellt und weist die Eigenschaft TARGET_INITIATED auf. Auf diesen Pfad kann auch über den Verteilungsdienst zugegriffen werden. Die Pfadinformationen werden auf dem Zielsystem gespeichert. Wenn die Kommunikation unterbrochen wird, benötigt der Empfangsservice auf dem Zielhost die Pfaddefinition, um die Verbindung neu zu starten. Diese Informationen werden gemeinsam mit dem Verteilungsdienst verwendet, wenn der Pfad ausgeführt wird. Der Pfad im Quell-Deployment ist ephemer. Ephemere Pfade helfen bei der Konsolidierung der Pfadkonfiguration und bei der Verstärkung der Initiierung von Ziel-zu-Quelle-Verbindungen.

Wenn der Pfad gestoppt oder getrennt wird, entfernt der Verteilungsdienst alle Pfadinformationen einschließlich der Pfaddefinition. Die Checkpoint-Datei wird jedoch beibehalten, da der Checkpoint verwendet wird, um zu entscheiden, ob alte Trails gelöscht werden können. Es wird empfohlen, alte Trails nicht zu löschen, es sei denn, der Pfad wird absichtlich gelöscht.

Verwandte Themen:

Oracle GoldenGate Reverse Proxy-Unterstützung

Reverse Proxy ermöglicht den Zugriff auf Microservices über einen einzelnen Port (443) in einem Deployment. Dadurch wird die URL für Microservices über ein unsicheres Deployment gekapselt. Hinweis: Reverse-Proxy ist optional. Oracle empfiehlt jedoch, dass Sie einen einfachen Zugriff auf Microservices sicherstellen und eine verbesserte Sicherheit bieten.

Sie können Microservices in einem unsicheren Deployment an einer Loopback-Adresse ausführen und mit der Nginx-Installation mit einem HTTP-Reverse-Proxy versehen.

Oracle GoldenGate MA enthält ein Skript namens ReverseProxySettings, das nur die Konfigurationsdatei für den Nginx-Reverse-Proxy-Server generiert.

Beispiel: Der Administrationsservice ist unter http://goldengate.example.com:9001 und der Distributionsservice unter http://goldengate.example.com:9002 verfügbar. Mit Reverse-Proxy können Sie einfach von der einzelnen Adresse aus auf jeden der Microservices zugreifen. Beispiel: http://goldengate.example.com/distsrvr für den Verteilungsservice. Die URL unterscheidet sich für jeden Service und ist nach Name und nicht nach Port.

Diese Werte werden bei der Verbindung mit dem Service Manager verwendet und sind erforderlich, wenn die Authentifizierung aktiviert ist.

Informationen zur Implementierung von NGINX-Reverse-Proxy mit Oracle GoldenGate finden Sie unter Oracle GoldenGate-Reverse-Proxy mit NGINX konfigurieren.