Verbindungen zu Autonomous Database werden entweder über das öffentliche Internet, optional mit definierten Zugriffskontrollregeln (ACLs) oder über einen privaten Endpunkt in einem virtuellen Cloud-Netzwerk (VCN) in Ihrem Mandanten hergestellt.

Wenn Sie eine Konfiguration für einen privaten Endpunkt angeben, ist nur Traffic aus dem angegebenen virtuellen Cloud-Netzwerk zulässig, und der Zugriff auf die Datenbank von allen öffentlichen IPs oder VCNs wird blockiert. Durch die Konfiguration eines privaten Endpunkts können Sie den gesamten Traffic zu und von der Datenbank aus dem öffentlichen Internet abhalten. Wenn bei einem privaten Endpunkt der öffentliche Zugriff mit Öffentlichen Zugriff zulassen aktiviert ist, hat die Instanz sowohl einen privaten als auch einen öffentlichen Endpunkt:

• Mit dem privaten Hostnamen, der Endpunkt-URL und der privaten IP-Adresse können Sie eine Verbindung zur Datenbank vom VCN herstellen, in dem sich die Datenbank befindet.

• Mit dem öffentlichen Hostnamen können Sie eine Verbindung zur Datenbank von bestimmten öffentlichen IP-Adressen oder von bestimmten VCNs herstellen, wenn diese VCNs für eine private Verbindung zu Autonomous Database mit einem Servicegateway konfiguriert sind.

Viele Anwendungen unterstützen mehrere Verbindungstypen. Jeder Verbindungstyp für Autonomous Database verwendet jedoch die Zertifikatauthentifizierung und die TCPS-(Secure TCP-)Datenbankverbindung mit dem Standard TLS 1.2. Dadurch wird sichergestellt, dass kein nicht autorisierter Zugriff auf Autonomous Database möglich ist und dass die Kommunikation zwischen Client und Server vollständig verschlüsselt ist und nicht abgefangen oder geändert werden kann.

Autonomous Database unterstützt standardmäßig gegenseitige TLS-(mTLS-)Verbindungen (verwenden Sie Port 1522, um eine Verbindung mit mTLS herzustellen). Sie können eine Autonomous Database-Instanz so konfigurieren, dass sowohl mTLS- als auch TLS-Verbindungen unterstützt werden (mithilfe von Port 1521 oder 1522 können Sie eine Verbindung zu TLS herstellen).

Clients, die TLS-Authentifizierung mit Autonomous Database verwenden, bieten folgende Vorteile:

• Es ist nicht erforderlich, dass Sie ein Wallet herunterladen. Bei TLS-Verbindungen, die den JDBC Thin-Treiber mit JDK8 oder höher verwenden, ist kein Wallet erforderlich. Dazu gehören Verbindungen von Clients wie SQL Developer und SQL Command Line (SQLcl).

• Clients, die sich mit TLS verbinden, müssen sich nicht um die Wallet-Rotation kümmern. Die Wallet-Rotation erfolgt bei mTLS-Verbindungen in der Regel.

• TLS-Verbindungen können schneller sein (und weniger Verbindungslatenz bieten). Die TLS-Authentifizierung bietet im Vergleich zu mTLS eine geringere Verbindungslatenz.

• TLS- und mTLS-Verbindungen schließen sich nicht gegenseitig aus. Die mTLS-Authentifizierung ist standardmäßig aktiviert und immer verfügbar. Wenn Sie die TLS-Authentifizierung aktivieren, können Sie entweder die mTLS- oder die TLS-Authentifizierung verwenden.

• Die Verwendung von TLS-Authentifizierung beeinträchtigt nicht die vollständig verschlüsselte End-to-End-Kommunikation zwischen einem Client und Autonomous Database.

Weitere Informationen zum Abrufen der mTLS-Verbindungszeichenfolgen für Ihre Autonomous Database-Instanz finden Sie unter TNS-Namen und Verbindungszeichenfolgen für eine Autonomous Database-Instanz anzeigen.

Gegenseitige TLS-Authentifizierung (mTLS)

Mit Mutual Transport Layer Security (mTLS) stellen Clients Verbindungen über eine TCPS-(Secure TCP-)Datenbankverbindung mit dem Standard TLS 1.2 und einem vertrauenswürdigen Client-Certificate-Authority-(CA-)Zertifikat her.

Bei der gegenseitigen Authentifizierung authentifizieren sich die Clientanwendung und Autonomous Database gegenseitig. Autonomous Database verwendet standardmäßig die mTLS-Authentifizierung. Verwenden Sie Port 1522, um eine Verbindung zu einer Autonomous Database-Instanz mit mTLS herzustellen (die Zuweisung des 1522-Ports kann nicht geändert werden).

Für die gegenseitige TLS-Authentifizierung muss der Client ein vertrauenswürdiges Client-CA-Zertifikat herunterladen oder abrufen, um eine Verbindung zu einer Autonomous Database-Instanz herzustellen. Autonomous Database verwendet dann das Zertifikat zur Authentifizierung des Clients. Dadurch wird die Sicherheit erhöht, und gibt die Clients an, die mit einer Autonomous Database-Instanz kommunizieren können.

Die Zertifizierungsauthentifizierung mit gegenseitigem TLS verwendet einen verschlüsselten Schlüssel, der in einem Wallet sowohl auf dem Client (auf dem die Anwendung ausgeführt wird) als auch auf dem Server (auf dem der Datenbankservice in Autonomous Database ausgeführt wird) gespeichert ist. Der Schlüssel auf dem Client muss mit dem Schlüssel auf dem Server übereinstimmen, damit eine Verbindung hergestellt werden kann. Ein Wallet enthält eine Sammlung von Dateien, einschließlich des Schlüssels und anderer Informationen, die für die Verbindung zur Autonomous Database-Instanz erforderlich sind. Die gesamte Kommunikation zwischen Client und Server wird verschlüsselt.

Um die Verbindung zur Autonomous Database-Instanz zu sichern, lädt ein Serviceadministrator die Clientzugangsdaten (wallet-Dateien) aus Autonomous Database herunter. Wenn Sie kein Autonomous Database-Serviceadministrator sind, stellt der Administrator Ihnen die Clientzugangsdaten bereit. Weitere Informationen finden Sie unter Clientzugangsdaten (Wallets) herunterladen.

Die folgende Abbildung zeigt sichere Clientverbindungen zu Oracle Autonomous Database über das öffentliche Internet mit mTLS-Verbindungen. Wenn Sie die Datenbank für die Verwendung privater Endpunkte konfigurieren, wird das öffentliche Internet nicht verwendet, und die Verbindung verwendet einen privaten Endpunkt in einem virtuellen Cloud-Netzwerk (VCN) in Ihrem Mandanten.

Beschreibung der Abbildung autonome-database.eps

Weitere Informationen zum Abrufen der mTLS-Verbindungszeichenfolgen für Ihre Autonomous Database-Instanz finden Sie unter TNS-Namen und Verbindungszeichenfolgen für eine Autonomous Database-Instanz anzeigen.

Die meisten Unternehmen schützen Netzwerke und Geräte in einem Netzwerk mit einer Firewall. Eine Firewall steuert eingehenden und ausgehenden Netzwerkverkehr mit Regeln, die die Verwendung bestimmter Ports und den Zugriff auf bestimmte Computer (oder insbesondere IP-Adressen oder Hostnamen) ermöglichen. Eine wichtige Funktion einer Firewall ist die Trennung zwischen internen Netzwerken und dem öffentlichen Internet.

Wenn Autonomous Database für den Zugriff über das öffentliche Internet konfiguriert ist, müssen Sie die Firewall konfigurieren, um den Zugriff auf Autonomous Database-Server zuzulassen.

Um von einer Firewall aus auf Autonomous Database zuzugreifen, muss die Firewall die Verwendung des in der Datenbankverbindung angegebenen Ports zulassen, wenn eine Verbindung zu den Servern in der Verbindung hergestellt wird. Verwenden Sie Port 1522 für Autonomous Database-mTLS-Verbindungen (Sie können die Portnummer in der Verbindungszeichenfolge aus der tnsnames.ora-Datei in der credentials ZIP-Datei anzeigen). Beispiel: Beachten Sie den port-Wert in der folgenden tnsnames.ora-Datei:

db2022adb_high = (description = ( 
                address=(protocol=tcps)
                (port=1522)
                (host=adb.example.oraclecloud.com))
                (connect_data=(service_name=example_high.adb.oraclecloud.com))
                (security=(ssl_server_dn_match=yes)))

Die Firewall muss den Zugriff auf Server innerhalb der Domain .oraclecloud.com über Port 1522 zulassen. Um eine Verbindung zu Autonomous Database herzustellen, müssen Sie je nach Netzwerkkonfiguration Ihrer Organisation möglicherweise einen Proxyserver für den Zugriff auf diesen Port verwenden, oder Sie müssen möglicherweise den Netzwerkadministrator bitten, diesen Port zu öffnen.

Informationen zu den öffentlichen IP-Adressbereichen in Oracle Cloud Infrastructure finden Sie unter IP-Adressbereiche. Sie müssen Traffic zu diesen CIDR-Blöcken zulassen, um den Zugriff auf eine Autonomous Database-Instanz auf einem öffentlichen Endpunkt sicherzustellen.

Application Continuity verbirgt Ausfälle vor Endbenutzern und Anwendungen, indem die aktiven Vorgänge für betroffene Datenbanksessions nach Ausfällen wiederhergestellt werden. Application Continuity führt dieses Recovery im Hintergrund der Anwendung durch, so dass der Ausfall in der Anwendung leicht verzögert auftritt.

Weitere Informationen zu Application Continuity finden Sie unter Application Continuity in Autonomous Database verwenden.