IAM-Benutzer können sich entweder mittels IAM-Datenbankkennwortverifizierung oder mit einem IAM-Token bei der Datenbankinstanz anmelden.

Die IAM-Datenbankkennwortverifizierung erfolgt ähnlich wie die Datenbankkennwortauthentifizierung. Der Unterschied ist, dass die Kennwortverifizierung (verschlüsselter Hash des Kennworts) nicht in der Datenbank gespeichert wird, sondern im OCI-IAM-Benutzerprofil.

Die zweite Verbindungsmethode, bei der ein IAM-Token für die Datenbank verwendet wird, ist moderner. Ein tokenbasierter Zugriff ist für Cloud-Ressourcen wie Oracle-Datenbanken in Exadata Cloud Infrastructure besser geeignet. Das Token basiert auf der Stärke, die der IAM-Endpunkt durchsetzen kann. Dies kann eine Multifaktor-Authentifizierung sein, die stärker ist als die alleinige Verwendung von Kennwörtern. Ein weiterer Vorteil der Verwendung von Token besteht darin, dass die Kennwortverifizierung (die als sensibel gilt) nie gespeichert wird oder im Arbeitsspeicher verfügbar ist.

Die Integration von Oracle Cloud Infrastructure IAM mit Oracle Exadata Database Service on Dedicated Infrastructure unterstützt Folgendes:

• Oracle Cloud Infrastructure-(OCI-)Identity and Access Management-(IAM-)Authentifizierung mittels Datenbankkennwortverifizierung
• Oracle Cloud Infrastructure-(OCI-)Identity and Access Management-(IAM-)Authentifizierung mit SSO-Token

Ausführliche Informationen über die Architektur zur Verwendung von IAM-Benutzern in Oracle Exadata Database Service on Dedicated Infrastructure finden Sie unter IAM-Benutzer für Oracle DBaaS-Datenbanken authentifizieren und autorisieren im Oracle Database 19c - Sicherheitshandbuch und im Oracle Database 23ai - Sicherheitshandbuch.

Sie können in einer Oracle Database-Instanz Benutzern Zugriff mithilfe eines Oracle Cloud Infrastructure-IAM-Datenbankkennworts (mittels Kennwortverifizierung) erteilen.

Mit einem Oracle Cloud Infrastructure IAM-Datenbankkennwort kann sich ein IAM-Benutzer bei einer Oracle Database-Instanz anmelden, da sich Oracle Database-Benutzer normalerweise mit einem Benutzernamen und einem Kennwort anmelden. Der Benutzer gibt seinen IAM-Benutzernamen und sein IAM-Datenbankkennwort ein. Ein IAM-Datenbankkennwort unterscheidet sich vom Kennwort für die Oracle Cloud Infrastructure-Konsole. Wenn Sie einen IAM-Benutzer mit einer Kennwortprüfung verwenden, können Sie sich bei Oracle Database mit einem beliebigen unterstützten Datenbankclient anmelden.

Für den Datenbankzugriff auf die Kennwortverifizierung erstellen Sie die Zuordnungen für IAM-Benutzer und OCI-Anwendungen zur Oracle Database-Instanz. Die IAM-Benutzeraccounts selbst werden in IAM verwaltet. Die Benutzerkonten und Benutzergruppen können sich entweder in der Standarddomain oder in einer benutzerdefinierten, nicht standardmäßigen Domain befinden.

Weitere Informationen zum Verwalten des IAM-Datenbankkennworts finden Sie unter Benutzerzugangsdaten verwalten.

Für den IAM-Tokenzugriff auf die Datenbank fordert die Clientanwendung oder das Clienttool von IAM ein Datenbanktoken für den IAM-Benutzer an.

Die Clientanwendung übergibt das Datenbanktoken über die Datenbankclient-API direkt an den Datenbankclient.

Wenn die Anwendung oder das Tool nicht zur Anforderung eines IAM-Tokens aktualisiert wurde, kann der IAM-Benutzer das Datenbanktoken über die OCI-Befehlszeilenschnittstelle (CLI) anfordern und speichern. Sie können ein Datenbankzugriffstoken (db-token) mit den folgenden Zugangsdaten anfordern:

• Sicherheitstoken (mit IAM-Authentifizierung), Delegationstoken (in der OCI Cloud Shell) und API-keys. Hierbei handelt es sich um Zugangsdaten, die den IAM-Benutzer darstellen, um die Authentifizierung zu aktivieren.
• Instanz-Principal-Token, mit denen Instanzen zu autorisierten Akteuren (oder Principals) werden, um nach der Authentifizierung Aktionen für OCI-Ressourcen auszuführen
• Resource-Principal-Token. Hierbei handelt es sich um Zugangsdaten, mit denen sich die Anwendung bei anderen OCI-Services authentifizieren kann.
• IAM-Benutzername und IAM-Datenbankkennwort (kann nur vom Datenbankclient angefordert werden)

Wenn sich der IAM-Benutzer mit einer Schrägstrichanmeldung / beim Client anmeldet und der Parameter OCI_IAM konfiguriert ist (sqlnet.ora, tnsnames.ora oder als Teil einer Verbindungszeichenfolge), ruft der Datenbankclient das Datenbanktoken aus einer Datei ab. Wenn der IAM-Benutzer einen Benutzernamen und ein Kennwort übermittelt, verwendet die Verbindung den für Clientverbindungen mit IAM-Datenbankkennwortverifizierung beschriebenen IAM-Datenbankverifizierungszugriff. Wenn der Parameter PASSWORD_AUTH=OCI_TOKEN lautet, verwendet der Datenbanktreiber stattdessen den Benutzernamen und das Kennwort, um eine direkte Verbindung zu IAM herzustellen und ein Datenbanktoken anzufordern. Die Anweisungen in dieser Dokumentation zeigen, wie Sie die OCI-CLI als Helper für das Datenbanktoken verwenden. Wenn die Anwendung oder das Tool für den Einsatz mit IAM aktualisiert wurde, befolgen Sie die Anweisungen zu der Anwendung oder dem Tool. Zu den allgemeinen Anwendungsfällen gehören SQL*Plus On Premise, SQLcl On Premise, SQL*Plus in der Cloud Shell oder Anwendungen, die SEP-Wallets verwenden.

Wenn ein Benutzer einen Benutzernamen oder ein Kennwort für die Anmeldung eingeben, verwendet der Datenbanktreiber für den Zugriff auf die Datenbank die Kennwortverifizierungsmethode. Wenn der Parameter PASSWORD_AUTH=OCI_TOKEN lautet, verwendet der Datenbanktreiber stattdessen den Benutzernamen und das Kennwort, um eine direkte Verbindung zu IAM herzustellen und ein Datenbanktoken anzufordern.

Bevor Sie die IAM-Authentifizierung für Datenbanken in Exadata Cloud Infrastructure verwenden, müssen Sie mit dem Networking-Service ein Servicegateway, eine Routingregel und eine Egress-Sicherheitsregel zum virtuellen Cloud-Netzwerk (VCN) und den Subnetzen hinzufügen, in denen sich Ihre Datenbankressourcen befinden.

1. Erstellen Sie ein Servicegateway in dem VCN, in dem sich Ihre Datenbankressourcen befinden, indem Sie die Anweisungen unter Aufgabe 1: Servicegateway erstellen in der OCI-Dokumentation befolgen.
2. Nachdem Sie das Servicegateway erstellt haben, fügen Sie eine Routingregel und eine Egress-Sicherheitsregel zu jedem Subnetz (im VCN) hinzu, in dem sich Datenbankressourcen befinden, damit diese Ressourcen die IAM-Authentifizierung über das Gateway verwenden können:
   1. Gehen Sie zur Seite Subnetzdetails für das Subnetz.
   2. Klicken Sie auf der Registerkarte Informationen zum Subnetz auf den Namen der Routentabelle des Subnetzes, um die Seite Routentabellendetails anzuzeigen.
   3. Prüfen Sie in der Tabelle der vorhandenen Routingregeln, ob bereits eine Regel mit den folgenden Eigenschaften vorhanden ist:
      • Ziel: Alle IAD-Services in Oracle Services Network
      • Zieltyp: Servicegateway
      • Ziel: Der Name des Servicegateways, das Sie gerade im VCN erstellt haben

      Wenn keine derartige Regel vorhanden ist, klicken Sie auf Routingregeln hinzufügen, und fügen Sie eine Routingregel mit diesen Eigenschaften hinzu.

   4. Kehren Sie zur Seite Subnetzdetails für das Subnetz zurück.
   5. Klicken Sie in der Tabelle Sicherheitslisten des Subnetzes auf den Namen der Sicherheitsliste des Subnetzes, um die Seite Sicherheitslistendetails anzuzeigen.
   6. Klicken Sie im Seitenmenü unter Ressourcen auf Egress-Regeln.
   7. Prüfen Sie in der Tabelle der vorhandenen Egress-Regeln, ob bereits eine Regel mit den folgenden Eigenschaften vorhanden ist:
      • Zustandslos: Nein
      • Ziel: Alle IAD-Services in Oracle Services Network
      • IP-Protokoll: TCP
      • Quellportbereich: Alle
      • Zielportbereich: 443
   8. Wenn keine derartige Regel vorhanden ist, klicken Sie auf Egress-Regeln hinzufügen, und fügen Sie eine Egress-Regel mit diesen Eigenschaften hinzu.

Prüfen Sie die Voraussetzungen für die Aktivierung des IAM-Benutzerzugriffs auf Oracle Database.

Wenn die Datenbank für ein anderes externes Authentifizierungsschema aktiviert ist, prüfen Sie, ob Sie IAM in der Oracle Database-Instanz verwenden möchten. Nur ein externes Authentifizierungsschema kann jeweils aktiviert sein.

Wenn Sie IAM verwenden möchten, jedoch ein anderes externes Authentifizierungsschema aktiviert ist, müssen Sie das andere externe Authentifizierungsschema zunächst deaktivieren.

Wenn IAM-Token vom Datenbankclient an den Datenbankserver gesendet werden sollen, muss eine TLS-Verbindung bestehen. Das TLS-Wallet mit dem Datenbankzertifikat für die ExaDB-D-Serviceinstanz muss im Speicherort WALLET_ROOT gespeichert sein. Erstellen Sie ein tls-Verzeichnis mit folgender Struktur: WALLET_ROOT/<PDB GUID>/tls.

Für die Konfiguration von TLS zwischen Datenbankclient und Server sind mehrere Optionen verfügbar.

• Verwenden eines selbstsignierten Datenbankserverzertifikats oder eines Datenbankserverzertifikats, das von einer allgemein bekannten Certificate Authority signiert ist
• Einseitige TLS (TLS) oder gegenseitige bzw. wechselseitige TLS (mTLS)
• Client mit oder ohne Wallet

Selbstsigniertes Zertifikat

Selbstsignierte Zertifikate werden in der Regel für intern bereitgestellte IT-Ressourcen verwendet, da Sie diese selbst erstellen können und die Bereitstellung kostenlos ist. Die Ressource (in unserem Fall der Datenbankserver) verfügt über ein selbstsigniertes Zertifikat, um sich beim Datenbankclient zu authentifizieren. Das selbstsignierte Zertifikat und das Root-Zertifikat werden im Datenbankserver-Wallet gespeichert. Damit der Datenbankclient das Datenbankserverzertifikat erkennen kann, ist auf dem Client auch eine Kopie des Root-Zertifikats erforderlich. Dieses selbst erstellte Root-Zertifikat kann in einem clientseitigen Wallet gespeichert oder im Standardzertifikatspeicher des Clientsystems (nur Windows und Linux) installiert werden. Wenn die Session eingerichtet wurde, prüft der Datenbankclient, ob das vom Datenbankserver übermittelte Zertifikat von demselben Root-Zertifikat signiert wurde.

Eine bekannte Certificate Authority

Die Verwendung einer allgemein bekannten Root Certificate Authority hat einige Vorteile, da das Root-Zertifikat wahrscheinlich bereits im Standardzertifikatspeicher des Clientsystems gespeichert ist. Der Client muss das Root-Zertifikat nicht in einem zusätzlichen Schritt speichern, wenn es sich um ein allgemeines Root-Zertifikat handelt. Der Nachteil besteht darin, dass mit dieser Option normalerweise Kosten verbunden sind.

Einseitige TLS

In einer TLS-Standardsession übergibt nur der Server ein Zertifikat an den Client, um sich zu authentifizieren. Der Client benötigt kein separates Clientzertifikat, um sich beim Server zu authentifizieren (ähnlich wie bei der Einrichtung von HTTPS-Sessions). Während für die Datenbank ein Wallet zum Speichern des Serverzertifikats erforderlich ist, benötigt der Client nur das Root-Zertifikat, mit dem das Serverzertifikat signiert ist.

Wechselseitige TLS (auch als gegenseitige TLS oder mTLS bezeichnet)

Bei mTLS verfügen sowohl der Client als auch der Server über Identitätszertifikate, die an den jeweils anderen übergeben werden. In den meisten Fällen werden diese beiden Zertifikate von demselben Root-Zertifikat signiert, sodass dasselbe Root-Zertifikat für den Datenbankserver und den Client zur Authentifizierung des jeweils anderen Zertifikats verwendet werden kann. Für die Authentifizierung des Benutzers wird manchmal mTLS verwendet, weil die Benutzeridentität vom Datenbankserver über das Zertifikat authentifiziert wird. Dieser Vorgang ist für das Übergeben von IAM-Token nicht erforderlich, kann aber beim Übergeben von IAM-Token verwendet werden.

Client mit einem Wallet

Ein Client-Wallet ist obligatorisch, wenn das Clientzertifikat mit mTLS gespeichert wird. Das Root-Zertifikat kann jedoch entweder in demselben Wallet oder im Standardzertifikatspeicher des Systems gespeichert werden.

Client ohne Wallet

Bei Verwendung von TLS können Clients unter den folgenden Bedingungen ohne Wallet konfiguriert werden: 1) Einseitige TLS wird konfiguriert, wenn der Client kein eigenes Zertifikat besitzt, und 2) das Root-Zertifikat, mit dem das Datenbankserverzertifikat signiert wurde, wird im Standardzertifikatspeicher des Systems gespeichert. Das Root-Zertifikat befindet sich wahrscheinlich bereits dort, wenn das Serverzertifikat von einer allgemeinen Certificate Authority signiert wird. Wenn es sich um ein selbstsigniertes Zertifikat handelt, muss das Root-Zertifikat im Standardzertifikatspeicher des Systems installiert werden, damit kein Client-Wallet verwendet wird.

Einzelheiten zur Konfiguration von TLS zwischen dem Datenbankclient und dem Datenbankserver, einschließlich der oben beschriebenen Optionen, finden Sie in der Oracle Database-Sicherheitsdokumentation unter Transport Layer Security-Authentifizierung konfigurieren.

Informationen zur Verwendung selbstsignierter Zertifikate und zu weiteren walletbezogenen Aufgaben finden Sie in der Oracle Database-Sicherheitsdokumentation unter Public Key Infrastructure-(PKI-)Elemente verwalten.