Azure Active Directory-Authentifizierung mit Base Database Service verwenden

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

Azure AD mit Base Database Service integrieren

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

Weitere Informationen zur Autorisierung von Azure AD-Benutzern, Architektur, Benutzerzuordnungen, Anwendungsfällen und dem Integrationsprozess finden Sie im Abschnitt Authentifizierung und Autorisierung von Microsoft Azure-Benutzern für Oracle AI-Datenbanken im Oracle AI Database Security Guide.

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. Fügen Sie nach dem Erstellen des Servicegateway eine Routingregel und eine Egress-Sicherheitsregel zu jedem Subnetz (im VCN) hinzu, in dem sich die 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 Subnetzs, um die Seite Routentabellendetails anzuzeigen.

    3. Überprü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 Servicegateways, das Sie gerade im VCN erstellt

      Wenn keine derartige Regel vorhanden ist, wählen Sie Routingregeln hinzufügen aus, und fügen Sie eine Routingregel mit diesen Merkmalen hinzu.

    4. Kehren Sie zur Seite Subnetzdetails für das Subnetz erneut zurück.
    5. Klicken Sie in der Tabelle Sicherheitslisten des Subnetzes auf den Namen der Sicherheitsliste des Subnetzes, um das Register Sicherheitslistendetails anzuzeigen.
    6. Wählen Sie im Seitenmenü unter Ressourcen die Option Egress-Regeln aus.

    7. Überprü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, wählen Sie Egress-Regeln hinzufügen aus, und fügen Sie eine Egress-Regel mit diesen Merkmalen 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.

Selbstsigniertes Zertifikat: Selbstsigniertes Zertifikat ist eine gängige Praxis für intern bereitgestellten IT-Ressourcen, da Sie diese selbst erstellen können und die Freigabe 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, weil 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 in der Regel Kosten verbunden sind.

Einseitige TLS: In der TLS-Standardsession gibt nur der Server dem Client 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 jeweils über Identitätszertifikate, die sie einander 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 ist. 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 folgenden Bedingungen verwendet werden:

  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 zuvor beschriebenen Optionen, finden Sie unter Transport Layer Security -Authentifizierung konfigurieren.

Informationen zur Verwendung selbstsignierter Zertifikate und zu zusätzlichen Wallet-bezogenen Aufgaben findest du 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üllt sein und dann die Anweisungen im Abschnitt Oracle AI Database für Microsoft Azure AD-Integration konfigurieren in der Sicherheitsdokumentation zu Oracle AI Database befolgen.

Schemas und Rollen von Oracle AI Database zuordnen

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

Weitere Informationen dazu, wie Oracle AI Database-Schemas und -Rollen Azure AD-Benutzern zugeordnet werden können, finden Sie im Abschnitt Oracle AI Database-Schemas und -Rollen zuordnen in der Sicherheitsdokumentation für Oracle AI 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 den Oracle AI-Datenbanken konfigurieren in der Sicherheitsdokumentation zu Oracle AI Database.

Testen der Barrierefreiheit des Azure-Endpunkts

Sie können sicherstellen, dass Ihre Base Database-Instanz 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 AI Database-Sicherheitshandbuch.

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 dem Festlegen 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 AI Database.