Autentica e autorizza utenti Microsoft Azure Active Directory per Autonomous Database

Un'istanza di Oracle Autonomous Database on Dedicated Exadata Infrastructure può essere configurata per consentire agli utenti Microsoft Azure AD di connettersi utilizzando i token di accesso di Azure OAuth2.

Informazioni sull'integrazione di Oracle Autonomous Database on Dedicated Exadata Infrastructure con Microsoft Azure AD

Oracle Autonomous Database on Dedicated Exadata Infrastructure e Microsoft Azure AD possono essere configurati per consentire agli utenti e alle applicazioni di connettersi al database utilizzando le proprie credenziali Azure AD.

Gli utenti e le applicazioni di Azure AD possono eseguire il login con le credenziali SSO (Single Sign On) di Azure AD per accedere al database. Questo viene fatto con un token di accesso OAuth2 di Azure AD che l'utente o l'applicazione richiede prima da Azure AD. Questo token di accesso OAuth2 contiene le informazioni sull'identità utente e l'accesso al database e viene quindi inviato al database. Per informazioni sulla configurazione dell'autenticazione con più fattori e senza password, fare riferimento all'articolo Microsoft Opzioni di autenticazione senza password per Azure Active Directory.

È possibile eseguire questa integrazione nei seguenti ambienti Oracle Database:

  • Oracle Database in locale release 19.18 e successive
  • Oracle Autonomous Database on Shared Exadata Infrastructure
  • Oracle Autonomous Database on Dedicated Exadata Infrastructure
  • Oracle Base Database Service
  • Oracle Exadata Cloud Service (Oracle ExaCS)

Le istruzioni per configurare Azure AD utilizzano il termine "Oracle Database" per comprendere questi ambienti.

Questo tipo di integrazione consente all'utente di Azure AD di accedere a un'istanza di Oracle Autonomous Database on Dedicated Exadata Infrastructure. Gli utenti e le applicazioni di Azure AD possono eseguire il login con le credenziali SSO (Single Sign On) di Azure AD per ottenere un token di accesso OAuth2 di Azure AD da inviare al database.

L'amministratore di Azure AD crea e registra Oracle Autonomous Database on Dedicated Exadata Infrastructure con Azure AD. All'interno di Azure AD, questa è chiamata registrazione dell'applicazione, che è breve per la registrazione dell'applicazione. Queste sono le informazioni digitali che Azure AD deve conoscere sul software che utilizza Azure AD. L'amministratore di Azure AD crea anche ruoli di applicazione (app) per la registrazione dell'applicazione del database in Azure AD. I ruoli applicazione connettono utenti, gruppi e applicazioni di Azure agli schemi e ai ruoli del database. L'amministratore di Azure AD assegna utenti, gruppi o applicazioni di Azure AD ai ruoli applicazione. Questi ruoli applicazione vengono mappati a uno schema globale del database o a un ruolo globale oppure a uno schema e a un ruolo. Un utente, un gruppo o un'applicazione Azure AD assegnato a un ruolo applicazione verrà mappato a uno schema globale del database, a un ruolo globale o a uno schema e a un ruolo. Uno schema globale Oracle può anche essere mappato esclusivamente a un utente di Azure AD. Un utente guest di Azure AD (utente non organizzazione) o un principal di servizio di Azure AD (applicazione) può essere mappato a uno schema globale del database solo tramite un ruolo applicazione di Azure AD. Un ruolo globale Oracle può essere mappato solo da un ruolo applicazione Azure e non può essere mappato da un utente Azure.

Gli strumenti di Oracle Autonomous Database on Dedicated Exadata Infrastructure, inclusi Oracle APEX, Database Actions, Oracle Graph Studio e Oracle Database API for MongoDB, non sono compatibili con l'uso dei token Azure AD per connettersi al database.

Gli strumenti e le applicazioni aggiornati per supportare i token Azure AD possono autenticare gli utenti direttamente con Azure AD e passare il token di accesso al database all'istanza di Oracle Autonomous Database on Dedicated Exadata Infrastructure. È possibile configurare gli strumenti di database esistenti, ad esempio SQL*Plus, per utilizzare un token Azure AD da una posizione file. In questi casi, i token di Azure AD possono essere recuperati utilizzando strumenti come Microsoft PowerShell o Azure CLI e inseriti in una posizione file. I token di accesso al database OAuth2 di Azure AD vengono emessi con un'ora di scadenza. Il driver client Oracle Database verificherà che il token sia in un formato valido e che non sia scaduto prima di passarlo al database. Il token viene definito per il database, il che significa che nel token sono presenti informazioni sul database in cui verrà utilizzato il token. I ruoli applicazione a cui è stato assegnato il principal di Azure AD nella registrazione dell'applicazione Azure AD del database sono inclusi come parte del token di accesso. La posizione della directory per il token Azure AD deve disporre solo dell'autorizzazione sufficiente per consentire all'utente di scrivere il file del token nella posizione e al client del database per recuperare questi file (ad esempio, solo lettura e scrittura da parte dell'utente). Poiché il token consente l'accesso al database, è necessario proteggerlo all'interno del file system.

Gli utenti di Azure AD possono richiedere un token da Azure AD utilizzando una serie di metodi per aprire una finestra di login di Azure per immettere le credenziali di Azure AD.

Oracle Autonomous Database on Dedicated Exadata Infrastructure accetta i token che rappresentano i seguenti principal di Azure AD:

  • Utente Azure AD, registrato nella tenancy Azure AD
  • Utente guest, registrato come utente guest nella tenancy di Azure AD
  • Servizio, ovvero l'applicazione registrata che si connette al database come se stessa con il flusso di credenziali client (caso d'uso del connection pool)

Oracle Autonomous Database on Dedicated Exadata Infrastructure supporta i seguenti flussi di autenticazione Azure AD:

  • Codice di autorizzazione, più comunemente utilizzato per gli utenti umani (non per le applicazioni) per l'autenticazione ad Azure AD in un ambiente client con un browser
  • Credenziali client, che si riferiscono alle applicazioni di database che si connettono come se stesse (e non all'utente finale)
  • Operazioni di base (OBO), in cui un'applicazione richiede un token di accesso per conto di un utente collegato da inviare al database
  • Credenziale della password del proprietario della risorsa (ROPC), che non è consigliata per l'uso in produzione, ma può essere utilizzata in ambienti di test in cui l'autenticazione utente di un browser popup sarebbe difficile da incorporare. ROPC richiede che il nome utente e la password di Azure AD facciano parte della chiamata di richiesta del token.

Architettura dell'integrazione di Microsoft Azure AD con un Autonomous Database

I token Microsoft Azure Active Directory seguono lo standard OAuth2 con le estensioni. L'uso di un token Azure AD per accedere a un database Oracle è simile all'uso dei token IAM OCI. Per una spiegazione dettagliata, vedere Architecture of the Microsoft Azure AD Integration with an Oracle Database in Security Guide.

Mapping degli utenti di Azure AD all'Autonomous Database

Gli utenti Microsoft Azure devono essere mappati a uno schema di Autonomous Database e disporre dei privilegi necessari (tramite i ruoli) prima di poter eseguire l'autenticazione nell'istanza di Autonomous Database. Per informazioni sui diversi modi di mappatura di utenti, gruppi e applicazioni in Microsoft Azure, vedere Azure AD Users Mapping to the Oracle Database nel manuale Security Guide.

Casi d'uso per la connessione a un Autonomous Database mediante Azure AD

Oracle Database supporta tre tipi di casi d'uso per la connessione a un'istanza di Autonomous Database utilizzando Microsoft Azure Active Directory. Per ulteriori dettagli, vedere Casi d'uso per la connessione a un Oracle Database mediante Azure AD.

Processo generale di autenticazione delle identità di Microsoft Azure AD con Oracle Autonomous Database on Dedicated Exadata Infrastructure

L'amministratore di Oracle Database e l'amministratore di Microsoft Azure AD svolgono ruoli per consentire agli utenti di Azure AD di connettersi al database utilizzando i token di accesso OAuth2 di Azure AD.

Di seguito viene descritto il processo generale.

  1. L'amministratore di Oracle Database garantisce che l'ambiente Oracle Database soddisfi i requisiti per l'integrazione con Microsoft Azure AD. Vedere Requisiti di Oracle Database per l'integrazione di Microsoft Azure AD.
  2. L'amministratore di Azure AD crea una registrazione dell'applicazione Azure AD per il database e l'amministratore di Oracle Database consente al database di utilizzare i token Azure AD per l'accesso al database.

    Nell'ambito del processo di registrazione dell'applicazione, l'amministratore di Azure AD crea i ruoli dell'applicazione Azure da utilizzare per i mapping tra utenti, gruppi e applicazioni di Azure agli schemi e ai ruoli di Oracle Database.

  3. L'amministratore di Oracle Database crea e mappa gli schemi globali a un utente di Azure AD (mapping di schema esclusivo) o a un ruolo applicazione di Azure (mapping di schema condiviso). L'utente o l'applicazione Azure AD deve essere mappato a uno schema.
  4. Facoltativamente, l'amministratore Oracle crea e mappa i ruoli globali di Oracle Database ai ruoli applicazione di Azure.
  5. L'utente finale di Azure AD che desidera connettersi con l'istanza di Oracle Autonomous Database on Dedicated Exadata Infrastructure registra l'applicazione client come client Azure AD (in modo simile alla registrazione del database Oracle).

    Il client Azure AD avrà un'identificazione client e un segreto client, a meno che il client applicazione non sia pubblico. Se il client dell'applicazione è pubblico, è necessaria solo l'identificazione del client dell'applicazione.

  6. L'utente finale di Azure AD (che può essere un amministratore di database) si connette utilizzando un'utility come PowerShell o l'interfaccia della riga di comando di Azure per recuperare il token di accesso al database OAuth2 e memorizzarlo in una directory di file locale. Un'applicazione può anche richiedere un token di accesso Azure AD OAuth2 direttamente da Azure AD e passarlo tramite un'API client del database. Per informazioni sul passaggio dei token OAuth2 di Azure AD, consultare la seguente documentazione del client Oracle Database:
  7. Una volta connesso all'istanza di Oracle Autonomous Database on Dedicated Exadata Infrastructure, l'utente finale di Azure AD esegue le operazioni del database in base alle esigenze.

Abilita autenticazione Azure AD su Autonomous Database

Un amministratore di Azure AD e un amministratore di Autonomous Database eseguono i passi per configurare l'autenticazione di Azure AD su Autonomous Database.

Prerequisiti

L'integrazione di Microsoft Azure AD con Oracle Autonomous Database on Dedicated Exadata Infrastructure richiede:
  1. Autonomous Database da versione 19.18 o successiva.

  2. Connettività al database sulla porta TLS 2484. Le connessioni non TLS non sono supportate.

  3. Connettività di rete in uscita ad Azure AD in modo che il database possa richiedere la chiave pubblica di Azure AD.

  4. Autonomous Database da registrare con Azure AD.

  5. Per le distribuzioni Exadata Cloud@Customer, le impostazioni del proxy HTTP nell'ambiente devono consentire al database di utilizzare Azure AD.

    Queste impostazioni vengono definite dall'amministratore della flotta durante la creazione dell'infrastruttura Exadata Cloud@Customer, come descritto in Uso della console per eseguire il provisioning di Exadata Database Service su Cloud@Customer.

    Nota

    La configurazione di rete, incluso il proxy HTTP, può essere modificata solo fino a quando lo stato dell'infrastruttura Exadata non è Richiede attivazione. Una volta attivato, non è possibile modificare tali impostazioni.

    L'impostazione di un proxy HTTP per un'infrastruttura Exadata già fornita richiede una richiesta di servizio (SR) in My Oracle Support. Per informazioni dettagliate, vedere Create a Service Request in My Oracle Support.

Procedura

Implementa i task riportati di seguito per configurare l'integrazione di Autonomous Database per Microsoft Azure AD.

  1. Registrare l'istanza di Autonomous Database con una tenancy Microsoft Azure AD: un utente con privilegi di amministratore di Azure AD utilizza Microsoft Azure AD per registrare l'istanza di Oracle Database con la tenancy Microsoft Azure AD. Consultare Registrare l'istanza di Oracle Autonomous Database con una tenancy AD Microsoft Azure nel manuale Security Guide.

  2. Abilita token di accesso Microsoft Azure AD v2: se l'organizzazione utilizza il token di accesso Microsoft Azure AD v2 (anziché i token v1), potrebbe essere necessario apportare ulteriori modifiche in Azure AD per supportare la richiesta upn: nel token. Vedere Abilitazione dei token di accesso di Microsoft Azure AD v2 e Controllo della versione del token di accesso di Azure AD nel manuale Security Guide.

  3. Gestire i ruoli applicazione in Microsoft Azure AD: in Azure AD è possibile creare e gestire i ruoli applicazione che verranno assegnati agli utenti e ai gruppi di Azure AD e che verranno inoltre mappati agli schemi e ai ruoli globali di Oracle Database. Fare riferimento a Gestisci ruoli applicazione in Microsoft Azure AD nel manuale Security Guide.

  4. Configura la connettività in uscita a Microsoft Azure AD utilizzando un gateway NAT:

    Crea un gateway NAT nella rete cloud virtuale (VCN) in cui risiedono le tue risorse di Autonomous Database seguendo le istruzioni riportate in Crea un gateway NAT nella documentazione di Oracle Cloud Infrastructure.

    Dopo aver creato il gateway NAT, aggiungere una regola di instradamento e una regola di sicurezza di uscita a ogni subnet (nella VCN) in cui risiedono le risorse di Autonomous Database in modo che queste risorse possano utilizzare il gateway per ottenere una chiave pubblica dall'istanza di 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:

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

      Se la regola non esiste, fare clic su 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 di sicurezza della subnet, fare clic sul nome della lista di sicurezza della subnet per visualizzare la relativa pagina Dettagli lista di sicurezza.

    6. Nel menu laterale, in Risorse, fare clic su 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
      • Data: 0.0.0.0/0
      • Protocollo IP: TCP
      • Intervallo porte di origine: 443
      • Intervallo di porte di destinazione: tutte

      Se una regola di questo tipo non esiste, fare clic su Aggiungi regole di uscita e aggiungere una regola di uscita con queste caratteristiche.

  5. Test dell'accessibilità dell'endpoint ID Entra

    Assicurarsi che l'istanza di Oracle Database possa accedere all'endpoint Entra ID seguendo i passi descritti in Test dell'accessibilità dell'endpoint di Azure nel manuale Security Guide.

    Se il database non è in grado di connettersi all'endpoint ID Microsoft Entra, anche dopo aver impostato il criterio ACL, controllare i prerequisiti elencati sopra per confermare di aver configurato correttamente la rete in base ai prerequisiti. Se il problema persiste, rivedere la rete per assicurarsi che l'istanza di database possa connettersi all'endpoint ID MS Entra.

  6. Configurare Azure AD come provider di identità esterno per Autonomous Database:

    Per impostazione predefinita, gli Autonomous Database e gli Autonomous Container Database sono configurati per connettere gli utenti con l'autenticazione e l'autorizzazione Oracle Cloud Infrastructure (IAM). Un DBA dell'applicazione può anche modificare questa impostazione in un altro schema di autenticazione esterno, AD esempio Utenti gestiti centralmente con Active Directory (CMU-AD) o Kerberos. Tuttavia, un Autonomous Database può abilitare un solo schema di autenticazione esterna alla volta.

    Per abilitare Azure AD come provider di identità esterno in un'istanza di Autonomous Database, effettuare le operazioni riportate di seguito.

    1. Eseguire il login all'istanza di Autonomous Database come utente che dispone del privilegio EXECUTE sul package PL/SQL DBMS_CLOUD_ADMIN. L'utente ADMIN dispone di questo privilegio.
    2. Poiché può essere abilitato un solo schema di autenticazione esterna per un Autonomous Database alla volta, eseguire la procedura DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION per disabilitare qualsiasi schema di autenticazione esterna già abilitato per il database.
      Per eseguire la procedura, è necessario aver eseguito il login come utente ADMIN o disporre del privilegio EXECUTE su DBMS_CLOUD_ADMIN.
      BEGIN
          DBMS_CLOUD_ADMIN.DISABLE_EXTERNAL_AUTHENTICATION;
      END;
      /
    3. Eseguire la procedura DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION con i parametri richiesti da Azure AD.
      BEGIN
        DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(
            type   =>'AZURE_AD',
            params => JSON_OBJECT('tenant_id' VALUE 'tenant_id',
                                  'application_id' VALUE 'application_id',
                                  'application_id_uri' VALUE 'application_id_uri'),
            force => TRUE
        );
      END;

      In questa procedura i parametri di Azure AD sono:

      • type: specifica il provider di autenticazione esterno. Per Azure AD, come mostrato, utilizzare 'AZURE_AD'.
      • params: i valori per i parametri obbligatori di Azure AD sono disponibili nel portale di Azure nel riquadro Panoramica registrazione applicazione per Azure Active Directory. Il file params richiesto per Azure AD è:
        • tenant_id: ID tenant dell'account Azure. ID tenant specifica la registrazione dell'applicazione Azure AD dell'istanza di Autonomous Database.
        • application_id: ID applicazione Azure creato in Azure AD per assegnare ruoli/mapping di schema per l'autenticazione esterna nell'istanza di Autonomous Database.
        • application_id_uri: URI univoco assegnato all'applicazione Azure.

          Si tratta dell'identificativo dell'istanza di Autonomous Database. Il nome deve essere qualificato per il dominio (supporta l'accesso alle risorse tra tenancy).

          La lunghezza massima per questo parametro è di 256 caratteri.

      • force: impostare questo parametro su TRUE se per l'istanza di Autonomous Database è configurato un altro metodo EXTERNAL AUTHENTICATION e si desidera disabilitarlo.
      Ad esempio:
      BEGIN
        DBMS_CLOUD_ADMIN.ENABLE_EXTERNAL_AUTHENTICATION(
            type   =>'AZURE_AD',
            params => JSON_OBJECT('tenant_id' VALUE '29981886-6fb3-44e3-82',
                                  'application_id' VALUE '11aa1a11-aaa',
                                  'application_id_uri' VALUE 'https://example.com/111aa1aa'),
            force  => TRUE
        );
      END;

      Imposta il parametro di sistema IDENTITY_PROVIDER_TYPE.

      Ad esempio, è possibile utilizzare quanto segue per verificare IDENTITY_PROVIDER_TYPE:
      SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME='identity_provider_type';
       
      NAME                   VALUE   
      ---------------------- -------- 
      identity_provider_type AZURE_AD
    Per ulteriori informazioni, vedere ENABLE_EXTERNAL_AUTHENTICATION Procedura.

Mappa schemi e ruoli di Oracle Database

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

Sono disponibili le opzioni riportate di seguito per il mapping degli schemi e dei ruoli del database Oracle agli utenti AD Microsoft Azure.

Configurare le connessioni client agli AD di Azure

Esistono numerosi modi per configurare un client per connettersi a un'istanza di Oracle Autonomous Database on Dedicated Exadata Infrastructure utilizzando i token Azure AD.

Scegliere il metodo di connessione client più adatto all'ambiente in uso. Questa guida fornisce esempi di connessione di SQL*Plus con diversi metodi per ottenere un token di accesso Azure AD OAuth2. Tutti i client 19c della release di Oracle Database possono accettare un token passato come file. Anche i driver JDBC-thin, Instant Client e ODP.net accettano il token tramite l'API client del database da un'applicazione. Gli strumenti di Oracle Database, ad esempio SQL*Plus, non sono in grado di recuperare direttamente i token, pertanto è necessario utilizzare strumenti quali PowerShell o Azure CLI per recuperare il token di accesso OAuth2 di Azure AD. Per recuperare un token Azure AD, il client deve essere registrato tramite il processo di registrazione dell'app Azure AD. La registrazione del client è simile alla registrazione del server Oracle Autonomous Database on Dedicated Exadata Infrastructure con Azure AD utilizzando la registrazione dell'applicazione. Sia il database che il client devono essere registrati con Azure AD.

Il database deve essere registrato in modo che il client possa ottenere l'autorizzazione per ottenere un token di accesso per il database. Il client deve essere registrato in modo che Azure AD possa riconoscere che un client sicuro richiede un token di accesso.

Nota

Sul client, è necessario impostare i parametri TOKEN_AUTH e TOKEN_LOCATION nel file sqlnet.ora per recuperare il token di accesso al database di Azure AD da una posizione e utilizzarlo quando si utilizza il login alla barra /. I dettagli esatti vengono descritti nella sezione Configura token di accesso a SQL*Plus per Azure AD.

Per ulteriori informazioni sulla connessione dei client ad Azure AD, vedere i seguenti articoli di Microsoft Azure:

Flusso operativo per la connessione client SQL*Plus in PowerShell ad Autonomous Database

La connessione tra l'utente Azure, Azure AD e l'istanza di Autonomous Database si basa sul passaggio del token OAuth2 in tutti questi componenti.

Fare riferimento a Operational Flow for SQL*Plus Client Connection in PowerShell to Oracle Database nel manuale Security Guide per un esempio che mostra l'uso del flusso ROPC (Resource Owner Password Credential) con un client pubblico.

Registrazione di un client con la registrazione dell'applicazione Azure AD

Questo tipo di registrazione è simile alla registrazione di Autonomous Database con la registrazione dell'applicazione Azure AD. Per ulteriori dettagli, vedere le sezioni riportate di seguito.

Esempi di recupero dei token OAuth2 di Azure AD

Per esempi che illustrano i diversi modi in cui è possibile recuperare i token OAuth2 di Azure AD, fare riferimento a Esempi di recupero dei token OAuth2 di Azure AD nel manuale Security Guide.

Configurare SQL*Plus per i token di accesso di Azure AD

È necessario configurare SQL*Plus per recuperare il token di accesso al database Azure AD da una posizione e utilizzarlo quando si utilizza il login / barra. Per istruzioni dettagliate, fare riferimento alla sezione Configuring SQL*Plus for Azure AD Access Token nel manuale Security Guide.

Risoluzione dei problemi relativi alle connessioni ID Microsoft Entra

È possibile utilizzare i file di trace per diagnosticare i problemi con le connessioni Microsoft Entra ID. È inoltre possibile correggere facilmente gli errori ORA-12599 e ORA-03114.

  • È possibile utilizzare i file di trace per risolvere i problemi relativi all'integrazione di Oracle Database con Microsoft Azure AD. Per ulteriori informazioni, vedere Trace Files for Troubleshooting Oracle Database Client Connections with Azure AD in Database Security Guide.

  • Gli errori ORA-12599: TNS: cryptographic checksum mismatch e ORA-03114: not connected to ORACLE indicano che il database a cui si sta tentando di connettersi è protetto dalla cifratura di rete nativa.

    Quando si utilizzano i token per accedere a un database Oracle, è necessario stabilire una connessione TLS (Transport Layer Security) e non una cifratura nativa della rete. Per correggere questi errori, assicurarsi che TLS sia configurato correttamente per il database. È necessario eseguire il test della configurazione con un nome utente e una password del database locale e controllare i seguenti parametri SYSCONTEXT USERENV:

    • NETWORK_PROTOCOL
    • TLS_VERSION
  • È possibile controllare la versione del token di accesso Microsoft Azure AD utilizzato dal sito Web utilizzando il sito Web Token Web JSON. Per ulteriori informazioni, vedere Controllo della versione del token di accesso di Azure AD nel manuale Database Security Guide.