Azure Active Directory-Authentifizierung mit Base Database Service verwenden

Sie können die Oracle-Datenbank in Base Database Service so konfigurieren, dass die Authentifizierung und Autorisierung von Microsoft Azure Active Database verwendet wird, damit Azure AD-Benutzer mit Azure AD-Zugangsdaten auf die Datenbank zugreifen können.

Verwandte Themen

Azure AD mit Base Database Service integrieren

Eine Oracle Database in einer Base Database Service-Instanz kann konfiguriert werden, damit Microsoft Azure Active Directory-(Azure AD-)Benutzer mit Azure OAuth2-Zugriffstoken eine Verbindung herstellen können.

Weitere Informationen zur Autorisierung von Azure AD-Benutzern, Architekturen, Benutzerzuordnungen, Anwendungsfällen und zum Integrationsprozess finden Sie unter Einführung in die Autorisierung von Microsoft Azure AD-Benutzern für eine Oracle-Datenbank in der Sicherheitsdokumentation zu Oracle Database.

Voraussetzungen

Die folgenden Voraussetzungen gelten für die Azure AD-Authentifizierung in Base Database Service.

Jede dieser Voraussetzungen wird in den folgenden Themen ausführlich beschrieben.

Netzwerkeinstellungen

Bevor Sie die Azure AD-Authentifizierung für Datenbanken 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. Führen Sie die folgenden Schritte aus, um ausgehende Konnektivität zu Azure AD mit einem NAT-Gateway zu konfigurieren.

  1. Erstellen Sie ein NAT-Gateway in dem VCN, in dem sich Ihre Datenbankressourcen befinden, nach den Anweisungen unter Servicegateway erstellen.
  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 können diese Ressourcen über das Gateway einen öffentlichen Schlüssel von Ihrer Azure AD-Instanz für die Azure AD-Authentifizierung abrufen:
    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:
      • Zielort: 0.0.0.0/0
      • Zieltyp: NAT-Gateway
      • 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:
      • Zieltyp: CIDR
      • Zielort: 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-Konfiguration

Wenn Azure AD-Token vom Datenbankclient an den Datenbankserver gesendet werden, muss eine TLS-Verbindung hergestellt werden. Das TLS-Wallet mit dem Datenbankzertifikat für die Base Database Service-Instanz 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.

Zweiseitige TLS (auch als gegenseitige TLS, mTLS bezeichnet): In mTLS verfügen sowohl der Client als auch der Server über Identitätszertifikate, die sie sich gegenseitig anzeigen. 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. Dies ist für die Übergabe von Azure AD-Token nicht erforderlich, kann dabei aber verwendet werden.

Client mit 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: Clients können ohne Wallet konfiguriert werden, wenn TLS unter den folgenden Bedingungen verwendet wird:
  1. Einseitige TLS wird konfiguriert, wenn der Client kein eigenes Zertifikat besitzt, und
  2. das Root-Zertifikat, das das Datenbankserverzertifikat signiert hat, 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 Transport Layer Security-Authentifizierung konfigurieren.

Informationen zur Verwendung selbstsignierter Zertifikate und zu zusätzlichen Wallet-bezogenen Aufgaben finden Sie in den Referenzinformationen zur orapki-Befehlszeilenschnittstelle (CLI) in der Database-Sicherheitsdokumentation. Weitere Informationen finden Sie unter Public Key Infrastructure-(PKI-)Elemente verwalten

Base Database Service für Integration mit Azure AD konfigurieren

Für die Integration von Base Database Service mit Azure AD muss die Datenbank bei Azure AD registriert sein, damit die Datenbank den Public Key von Azure AD anfordern kann.

Um Base Database Service für die Integration mit Azure AD zu konfigurieren, müssen Sie zuerst die Voraussetzungen im Abschnitt Voraussetzungen erfüllen und dann die Anweisungen im Abschnitt Oracle Database für Microsoft Azure AD-Integration konfigurieren in der Sicherheitsdokumentation zu Oracle Database befolgen.

Oracle Database-Schemas und -Rollen zuordnen

Azure AD-Benutzer werden einem Datenbankschema und optional einer oder mehreren Datenbankrollen zugeordnet.

Weitere Informationen zu den Optionen für die Zuordnung von Oracle Database-Schemas und -Rollen zu Azure AD-Benutzern finden Sie im Abschnitt Oracle Database-Schemas und -Rollen zuordnen in der Sicherheitsdokumentation zu Oracle Database.

Clientverbindungen zu Azure ADs konfigurieren

Es gibt zahlreiche Möglichkeiten, wie Sie einen Client für die Verbindung mit einer Base Database Service-Instanz mit Azure AD-Token konfigurieren können.

Weitere Informationen zum Konfigurieren von Azure AD-Clientverbindungen finden Sie im Abschnitt Azure AD-Clientverbindungen zu Oracle Database konfigurieren in der Sicherheitsdokumentation zu Oracle Database.

Testen der Barrierefreiheit des Azure-Endpunkts

Sie können sicherstellen, dass Ihre Basisdatenbankinstanz auf den Azure AD-Endpunkt zugreifen kann, indem Sie einen Verbindungstest ausführen.

Weitere Informationen zum Testen der Verbindung finden Sie im Abschnitt Testen der Barrierefreiheit des Azure-Endpunkts im Oracle Database Security Guide.

Tracedateien für die Fehlerbehebung bei Verbindungen

Mit Tracedateien können Sie Fehler bei Base Database Service-Clientverbindungen mit Azure AD-Verbindungen beheben.

Weitere Informationen zu Tracedateien und zum Einrichten von Clienttracing für die Tokenauthentifizierung finden Sie im Abschnitt Tracedateien für die Fehlerbehebung bei Oracle Database-Clientverbindungen mit Azure AD in der Sicherheitsdokumentation zu Oracle Database.