Usa autenticazione Azure Active Directory con Base Database Service

È possibile configurare Oracle AI Database in Base Database Service in modo che utilizzi l'autenticazione e l'autorizzazione di Microsoft Azure Active Database per consentire agli utenti di Azure AD di accedere al database con le credenziali di Azure AD.

Informazioni sull'integrazione di Azure AD con Base Database Service

È possibile configurare un'istanza di Oracle AI Database in un'istanza di Base Database Service affinché gli utenti di Microsoft Azure Active Directory (Azure AD) possano connettersi utilizzando i token di accesso di Azure OAuth2.

Per ulteriori informazioni sull'autorizzazione degli utenti di Azure AD, sull'architettura, sui mapping degli utenti, sui casi d'uso e sul processo di integrazione, vedere la sezione Authenticating and Authorizing Microsoft Azure Users for Oracle AI Databases del manuale Oracle AI Database Security Guide.

Prerequisiti

Per l'autenticazione di Azure AD su Base Database Service sono necessari i prerequisiti riportati di seguito.

Ognuno di questi argomenti è descritto in dettaglio nei seguenti argomenti.

Impostazioni di rete

Prima di utilizzare l'autenticazione Azure AD nei database, è necessario utilizzare il servizio Networking per aggiungere un gateway di servizio, una regola di instradamento e una regola di sicurezza di uscita alla rete cloud virtuale (VCN) e alle subnet in cui risiedono le risorse del database. Eseguire i passi riportati di seguito per configurare la connettività in uscita ad Azure AD utilizzando un gateway NAT.

  1. Creare un gateway NAT nella VCN in cui risiedono le risorse del database seguendo le istruzioni riportate in Creare il gateway del servizio.

  2. Dopo aver creato il gateway di servizi, aggiungere una regola di instradamento e una regola di sicurezza in uscita a ogni subnet (nella VCN) in cui risiedono le risorse del database in modo che queste risorse possano utilizzare il gateway per ottenere una chiave pubblica dall'istanza di Azure AD per utilizzare l'autenticazione Azure AD:

    1. Andare alla pagina Dettagli subnet per la subnet.
    2. Nella scheda Informazioni subnet fare clic sul nome della tabella di instradamento della subnet per visualizzare la relativa pagina Dettagli tabella di instradamento.

    3. Nella tabella delle regole di instradamento esistenti, verificare se esiste già una regola con le seguenti caratteristiche:

      • Destinazione: 0.0.0.0/0
      • Tipo di destinazione: gateway NAT
      • Destinazione: il nome del gateway di servizi appena creato nella VCN

      Se tale regola non esiste, selezionare Aggiungi regole di instradamento e aggiungere una regola di instradamento con queste caratteristiche.

    4. Tornare alla pagina Dettagli subnet per la subnet.
    5. Nella tabella Elenchi sicurezza della subnet fare clic sul nome della lista di sicurezza della subnet per visualizzare la relativa pagina Dettagli elenco di sicurezza.
    6. Nel menu laterale, in Risorse, selezionare Regole di uscita.

    7. Nella tabella delle regole di uscita esistenti, verificare se esiste già una regola con le seguenti caratteristiche:

      • Tipo di destinazione: CIDR
      • Destinazione: 0.0.0.0/0
      • Protocollo IP: TCP
      • Intervallo porte di origine: 443
      • Intervallo delle porte di destinazione: Tutto
    8. Se una regola di questo tipo non esiste, selezionare Aggiungi regole di uscita e aggiungere una regola di uscita con queste caratteristiche.

Configurazione TLS

Quando si inviano i token di Azure AD dal client del database al database server, è necessario stabilire una connessione TLS. Il wallet TLS con il certificato di database per l'istanza di Base Database Service deve essere memorizzato nella posizione WALLET_ROOT. Creare una directory tls in modo che sia simile a: WALLET_ROOT/<PDB GUID>/tls

Quando si configura TLS tra il client del database e il server, sono disponibili diverse opzioni da considerare.

Certificato autofirmato: l'uso di un certificato autofirmato è una pratica comune per le risorse IT interne poiché è possibile crearle autonomamente ed è gratuito. La risorsa (nel nostro caso, il database server) avrà un certificato autofirmato per autenticarsi presso il client del database. Il certificato con firma automatica e il certificato radice verranno memorizzati nel wallet del database server. Affinché il client del database possa riconoscere il certificato del server del database, sul client sarà necessaria anche una copia del certificato root. Questo certificato root auto-creato può essere memorizzato in un wallet lato client o installato nell'area di memorizzazione dei certificati predefinita del sistema client (solo Windows e Linux). Una volta stabilita la sessione, il client del database controllerà che il certificato inviato dal database server sia stato firmato dallo stesso certificato radice.

Un'autorità di certificazione root ben nota: l'utilizzo di un'autorità di certificazione root comunemente nota presenta alcuni vantaggi in quanto, molto probabilmente, il certificato root è già memorizzato nell'area di memorizzazione dei certificati predefinita del sistema client. Non vi è alcun passo aggiuntivo per il client per memorizzare il certificato root se si tratta di un certificato root comune. Lo svantaggio è che questo di solito ha un costo associato ad esso.

TLS unidirezionale: nella sessione TLS standard, solo il server fornisce un certificato al client per l'autenticazione. Non è necessario che il client disponga di un certificato client separato per autenticarsi presso il server (simile alla modalità di creazione delle sessioni HTTPS). Mentre il database richiede un wallet per memorizzare il certificato server, l'unica cosa che il client deve avere è il certificato root utilizzato per firmare il certificato server.

TLS a due vie (denominato anche Mutual TLS, mTLS): in mTLS, sia il client che il server dispongono di certificati di identità presentati tra loro. Nella maggior parte dei casi, lo stesso certificato root avrà firmato entrambi questi certificati in modo che lo stesso certificato root possa essere utilizzato con il database server e il client per autenticare l'altro certificato. mTLS viene talvolta utilizzato per autenticare l'utente poiché l'identità utente viene autenticata dal database server tramite il certificato. Questo non è necessario per passare i token di Azure AD, ma può essere utilizzato quando si passano i token di Azure AD.

Client con wallet: un wallet client è obbligatorio quando si utilizza mTLS per memorizzare il certificato client. Tuttavia, il certificato radice può essere memorizzato nello stesso wallet o nell'area di memorizzazione dei certificati predefinita del sistema.

Un client senza wallet: i client possono essere configurati senza un wallet quando si utilizza TLS nelle seguenti condizioni:

  1. TLS unidirezionale è in fase di configurazione in cui il client non dispone di un proprio certificato e

  2. il certificato root che ha firmato il certificato del database server viene memorizzato nell'area di memorizzazione dei certificati predefinita del sistema. Molto probabilmente il certificato root esiste già se il certificato del server è firmato da un'autorità di certificazione comune. Se si tratta di un certificato autofirmato, è necessario installare il certificato root nell'area di memorizzazione dei certificati predefinita del sistema per evitare l'uso di un wallet client.

Per informazioni su come configurare TLS tra il client del database e il database server, incluse le opzioni descritte in precedenza, vedere Configuring Transport Layer Security Authentication.

Se si sceglie di utilizzare i certificati autofirmati e per task aggiuntivi correlati al wallet, fare riferimento alla guida di riferimento dell'interfaccia della riga di comando (CLI, Command Line Interface) orapki nel manuale Database Security Guide. Vedere Gestione degli elementi PKI (Public Key Infrastructure).

Configurare Base Database Service per l'integrazione con Azure AD

L'integrazione di Base Database Service con Azure AD richiede che il database sia registrato con Azure AD in modo che il database possa richiedere la chiave pubblica di Azure AD.

Per configurare Base Database Service per l'integrazione con Azure AD, è necessario prima completare i prerequisiti nella sezione Prerequisiti, quindi seguire le istruzioni nella sezione Configuring the Oracle AI Database for Microsoft Azure AD Integration di Oracle AI Database Security Guide.

Mappa schemi e ruoli di Oracle AI Database

Gli utenti di Azure AD verranno mappati a uno schema di database e, facoltativamente, a uno o più ruoli di database.

Per ulteriori informazioni sulle opzioni per il mapping degli schemi e dei ruoli di Oracle AI Database agli utenti di Azure AD, vedere la sezione Mapping di schemi e ruoli di Oracle AI Database nel manuale Oracle AI Database Security Guide.

Configurare le connessioni client agli AD di Azure

Esistono numerosi modi in cui è possibile configurare un client per connettersi a un'istanza di Base Database Service utilizzando i token di Azure AD.

Per ulteriori informazioni sulla configurazione delle connessioni client Azure AD, vedere la sezione Configuring Azure AD Client Connections to the Oracle AI Databases del manuale Oracle AI Database Security Guide.

Test dell'accesso facilitato dell'endpoint di Azure

È possibile assicurarsi che l'istanza di Base Database possa accedere all'endpoint di Azure AD eseguendo un test di connessione.

Per ulteriori informazioni sul test della connessione, vedere la sezione Test dell'accesso facilitato dell'endpoint di Azure nel manuale Oracle AI Database Security Guide.

File di trace utilizzati per la risoluzione dei problemi delle connessioni

È possibile utilizzare i file di trace per risolvere i problemi relativi alle connessioni client di Base Database Service con le connessioni Azure AD.

Per ulteriori informazioni sui file di trace e sull'impostazione del trace client per l'autenticazione dei token, vedere la sezione Trace Files for Troubleshooting Oracle Database Client Connections with Azure AD nel manuale Oracle AI Database Security Guide.