Oracle Cloud Infrastructure-Dokumentation

Microsoft Entra ID-(MS-EI-)Benutzer für Oracle-Datenbanken auf Oracle Exadata Database Service on Dedicated Infrastructure authentifizieren und autorisieren

Eine Oracle Database kann für Microsoft Azure-Benutzer von Microsoft Entra ID konfiguriert werden, um eine Verbindung mit der Single Sign-On-Authentifizierung herzustellen.

Übergeordnetes Thema: Anleitungen

Microsoft Entra ID-(MS-EI-)Benutzer für Oracle-Datenbanken auf Oracle Exadata Database Service on Dedicated Infrastructure autorisieren

Benutzer für Oracle Exadata Database Service on Dedicated Infrastructure können zentral in einem MS-EI-Service verwaltet werden.

Die Oracle Database-Integration mit MS-EI wird für On-Premise-Datenbanken und die meisten Oracle OCI DBaaS-Plattformen unterstützt.

Die Anweisungen zur Konfiguration von MS-EI verwenden den Begriff "Oracle Database", um diese Umgebungen zu umfassen.

Mit diesem Integrationstyp kann der MS-EI-Benutzer auf eine Oracle Exadata Database Service on Dedicated Infrastructure-Instanz zugreifen. MS-EI-Benutzer und -Anwendungen können sich mit MS-EI Single Sign-On-(SSO-)Zugangsdaten anmelden, um ein MS-EI OAuth2-Zugriffstoken zum Senden an die Datenbank zu erhalten.

Der Administrator erstellt und konfiguriert die Anwendungsregistrierung (App-Registrierung) der Oracle Exadata Database Service on Dedicated Infrastructure-Instanz bei MS-EI. Der Administrator erstellt auch Anwendungsrollen (App) für die Registrierung der Datenbankanwendung in MS-EI und weist diese Rollen MS-EI-Benutzern, -Gruppen und -Anwendungen zu. Diese Anwendungsrollen werden den globalen Schemas und globalen Rollen der Datenbank zugeordnet. Ein MS-EI- Principal, der einer Anwendungsrolle zugewiesen ist, wird entweder einem globalen Datenbankschema oder einer globalen Datenbankrolle zugeordnet. Außerdem kann ein globales Oracle-Schema einem MS-EI-Benutzer exklusiv zugeordnet werden. Wenn der Principal ein Gastbenutzer oder Service-Principal ist, kann er nur über eine MS-EI-Anwendungsrolle dem Datenbankschema zugeordnet werden. Eine globale Oracle-Rolle kann nur einer MS-EI-Anwendungsrolle zugeordnet werden.

Tools und Anwendungen, die zur Unterstützung von MS-EI-Token aktualisiert werden, können Benutzer direkt mit MS-EI authentifizieren und das Datenbankzugriffstoken an die Oracle Exadata Database Service on Dedicated Infrastructure-Instanz übergeben. Sie können vorhandene Datenbanktools wie SQL*Plus so konfigurieren, dass ein MS-EI-Token aus einem Dateispeicherort verwendet wird oder das Token direkt aus MS-EI abgerufen wird. Wenn Sie ein Utility verwenden, mit dem das Token über einen Dateispeicherort an den Datenbankclienttreiber übergeben wird, können MS-EI-Token mit Tools wie Microsoft PowerShell oder Azure CLI abgerufen und an einem Dateispeicherort abgelegt werden. Ein MS-EI-OAuth2-Datenbankzugriffstoken ist ein Bearer-Token mit einer Ablaufzeit. Der Oracle Database-Clienttreiber stellt sicher, dass das Token ein gültiges Format aufweist und nicht abgelaufen ist, bevor es an die Datenbank übergeben wird. Als Geltungsbereich des Tokens ist die Datenbank festgelegt. Zugewiesene Anwendungsrollen für den Azure AD-Principal sind als Teil des Zugriffstokens enthalten. Das Verzeichnis für das MS-EI-Token darf nur über ausreichende Berechtigungen verfügen, damit der Benutzer die Tokendatei in den Speicherort schreiben und der Datenbankclient diese Dateien abrufen kann (z.B. nur Lese- und Schreibberechtigung für den Prozessbenutzer). Da das Token Zugriff auf die Datenbank gewährt, muss es im Dateisystem geschützt werden.

MS-EI-Benutzer können ein Token als Client anfordern, der bei der MS-EI-App-Registrierung registriert ist, indem sie Methoden wie die folgenden verwenden:

  • Eingabe der MS-EI-Zugangsdaten in einen MS-EI-Authentifizierungsbildschirm mit oder ohne Multifaktor-Authentifizierung

Oracle Exadata Database Service on Dedicated Infrastructure unterstützt die folgenden MS-EI-Authentifizierungsabläufe:

  • Interaktiver Ablauf (Autorisierungscode): Wird verwendet, wenn ein Browser zur Eingabe von Zugangsdaten für den Benutzer verwendet werden kann
  • Clientzugangsdaten: Werden für Anwendungen verwendet, die eigenständig (nicht als Endbenutzer) eine Verbindung herstellen
  • OBO (On-Behalf-Of): Hierbei fordert eine Anwendung ein Zugriffstoken im Namen eines angemeldeten Benutzers an, um es an die Datenbank zu senden
  • ROPC wird auch für Test- und Entwicklungsumgebungen unterstützt

Oracle Exadata Database Service on Dedicated Infrastructure akzeptiert Token, die folgende MS-EI-Prinzipale darstellen:

  • MS-EI-Benutzer, der im MS-EI-Mandanten registriert ist
  • Gastbenutzer, der im MS-EI-Mandanten als Gastbenutzer registriert ist
  • Service: Hierbei handelt es sich um die registrierte Anwendung, die eigenständig mit dem Clientzugangsdatenfluss eine Verbindung zur Datenbank herstellt (Anwendungsfall für Verbindungspool)

Integration von Oracle Database for Microsoft Entra ID (MS-EI) konfigurieren

Für die MS-EI-Integration mit der Oracle Database-Instanz muss die Datenbank bei MS-EI registriert sein, damit die Datenbank den MS-EI-Public Key anfordern kann.

Informationen zum Konfigurieren von MS-EI, zum Konfigurieren der Datenbank und zum Konfigurieren des Datenbankclients finden Sie unter:

Übergeordnetes Thema: Microsoft Entra ID-(MS-EI-)Benutzer für Oracle-Datenbanken auf Oracle Exadata Database Service on Dedicated Infrastructure authentifizieren und autorisieren

Voraussetzungen für die Microsoft Entra ID-(MS-EI-)Authentifizierung

Prüfen Sie die Voraussetzungen für die Integration von Oracle Database mit MS-EI.

Die MS-EI-Integration mit Oracle Database on Oracle Exadata Database Service on Dedicated Infrastructure erfordert:

  1. Oracle Database mit Version 19.18 oder höher.
  2. Konnektivität zur Datenbank auf TLS-Port 2484. Nicht-TLS-Verbindungen werden nicht unterstützt.
  3. Ausgehende Netzwerkkonnektivität zu MS-EI, damit die Datenbank den öffentlichen MS-EI-Schlüssel anfordern kann.
  4. Die Oracle Database, die bei MS-EI registriert werden soll.
  5. Benutzer und Anwendungen, die ein MS-EI-Token anfordern müssen, müssen auch über eine Netzwerkverbindung zu MS-EI verfügen. Möglicherweise müssen Sie eine Proxyeinstellung für die Verbindung konfigurieren.
  6. Bei Oracle Exadata Database Service on Dedicated Infrastructure-Deployments müssen die HTTP-Proxyeinstellungen in Ihrer Umgebung die Verwendung von MS-EI durch die Datenbank zulassen.

    Diese Einstellungen werden vom Flottenadministrator beim Erstellen der Oracle Exadata Database Service on Dedicated Infrastructure-Infrastruktur definiert, wie unter So erstellen Sie eine Cloud-Exadata-Infrastrukturressource beschrieben.

    Hinweis

    Die Netzwerkkonfiguration einschließlich des HTTP-Proxys kann nur bearbeitet werden, bis die Exadata-Infrastruktur den Status "Aktivierung erforderlich" aufweist. Sobald sie aktiviert ist, können Sie diese Einstellungen nicht mehr bearbeiten.

    Für die Einrichtung eines HTTP-Proxys für eine bereits bereitgestellte Exadata-Infrastruktur ist eine Serviceanfrage (SR) in My Oracle Support erforderlich. Weitere Informationen finden Sie unter Serviceanfrage in My Oracle Support erstellen.

Netzwerkvoraussetzungen für die Microsoft Entra ID-(MS-EI-)Authentifizierung

Bevor Sie die Azure AD-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. Nur so können diese Ressourcen die Azure AD-Authentifizierung über das Gateway verwenden.
    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: 0.0.0.0/0
      • Zieltyp: NAT-Gateway
      • Ziel: Der Name des NAT-Gateways, 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:
      • Zieltyp: CIDR
      • Ziel: 0.0.0.0/0
      • IP-Protokoll: TCP
      • Quellportbereich: 443
      • Zielportbereich: Alle
    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.

TLS für die Verwendung von Microsoft Entra ID-(MS-EI-)Token konfigurieren

Wenn MS-EI-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, sodass es wie folgt aussieht: 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 unter:

Informationen zum Verwenden selbstsignierter Zertifikate und für zusätzliche Wallet-bezogene Aufgaben finden Sie unter: