Documentazione di Oracle Cloud Infrastructure

Autenticazione e autorizzazione degli utenti ID Microsoft Entra (MS-EI) per i database Oracle su Oracle Exadata Database Service on Dedicated Infrastructure

È possibile configurare un Oracle Database per gli utenti Microsoft Azure di Microsoft Entra ID per connettersi utilizzando l'autenticazione Single Sign-On.

Argomento padre: guide esplicative

Informazioni sull'autorizzazione degli utenti ID Microsoft Entra (MS-EI) per i database Oracle su Oracle Exadata Database Service on Dedicated Infrastructure

Gli utenti di Oracle Exadata Database Service on Dedicated Infrastructure possono essere gestiti centralmente in un servizio MS-EI.

L'integrazione di Oracle Database con MS-EI è supportata per i database on-premise e la maggior parte delle piattaforme DBaaS OCI Oracle.

Le istruzioni per la configurazione di MS-EI utilizzano il termine "Oracle Database" per comprendere questi ambienti.

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

L'amministratore crea e configura la registrazione dell'applicazione (registrazione dell'applicazione) dell'istanza di Oracle Exadata Database Service on Dedicated Infrastructure con MS-EI. L'amministratore crea inoltre ruoli applicazione (app) per la registrazione dell'applicazione di database in MS-EI e assegna tali ruoli agli utenti, ai gruppi e alle applicazioni MS-EI. Questi ruoli applicazione verranno mappati agli schemi globali del database e ai ruoli globali. Un principal MS-EI assegnato a un ruolo applicazione verrà mappato a uno schema globale del database o a un ruolo globale del database. Uno schema globale Oracle può anche essere mappato esclusivamente a un utente MS-EI. Quando il principal è un utente guest o un principal servizio, può essere mappato allo schema di database solo tramite un ruolo applicazione MS-EI. Un ruolo globale Oracle può essere mappato solo a un ruolo applicazione MS-EI.

Gli strumenti e le applicazioni aggiornati per supportare i token MS-EI possono autenticare gli utenti direttamente con MS-EI e passare il token di accesso al database all'istanza di Oracle Exadata Database Service on Dedicated Infrastructure. È possibile configurare gli strumenti di database esistenti, ad esempio SQL*Plus, per utilizzare un token MS-EI da una posizione file o per ottenere il token direttamente da MS-EI. Quando si utilizza un'utility per ottenere il token da passare al driver client del database attraverso una posizione di file, i token MS-EI possono essere recuperati utilizzando strumenti come Microsoft PowerShell o Azure CLI e inseriti in una posizione di file. Un token di accesso al database MS-EI OAuth2 è un token di servizio 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 è definito per il database. I ruoli applicazione assegnati per il principal di Azure AD sono inclusi come parte del token di accesso. La posizione della directory per il token MS-EI 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 del processo). Poiché il token consente l'accesso al database, è necessario proteggerlo all'interno del file system.

Gli utenti MS-EI possono richiedere un token come client registrato con la registrazione dell'app MS-EI utilizzando metodi come i seguenti:

  • Inserimento delle credenziali MS-EI in una schermata di autenticazione MS-EI con o senza autenticazione a più fattori

Oracle Exadata Database Service on Dedicated Infrastructure supporta i seguenti flussi di autenticazione MS-EI:

  • Flusso interattivo (codice di autorizzazione), utilizzato quando un browser può essere utilizzato per immettere le credenziali per l'utente
  • Credenziali client, per le applicazioni che si connettono come se stesse (e non come l'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
  • ROPC è supportato anche per gli ambienti di test e sviluppo

Oracle Exadata Database Service on Dedicated Infrastructure accetta i token che rappresentano i seguenti principal MS-EI:

  • Utente MS-EI, utente registrato nella tenancy MS-EI
  • Utente guest, registrato come utente guest nella tenancy MS-EI
  • 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)

Configurazione dell'integrazione di Oracle Database for Microsoft Entra ID (MS-EI)

L'integrazione MS-EI con l'istanza di Oracle Database richiede che il database venga registrato con MS-EI in modo che il database possa richiedere la chiave pubblica MS-EI.

Per informazioni sulla configurazione di MS-EI, sulla configurazione del database e sulla configurazione del client del database, vedere:

Argomento padre: autenticazione e autorizzazione degli utenti ID Microsoft Entra (MS-EI) per i database Oracle su Oracle Exadata Database Service on Dedicated Infrastructure

Prerequisiti per l'autenticazione ID Microsoft Entra (MS-EI)

Rivedere i prerequisiti per l'integrazione di Oracle Database con MS-EI.

L'integrazione MS-EI con Oracle Database on Oracle Exadata Database Service on Dedicated Infrastructure richiede:

  1. Oracle Database deve essere 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 a MS-EI in modo che il database possa richiedere la chiave pubblica MS-EI.
  4. Oracle Database da registrare con MS-EI.
  5. Gli utenti e le applicazioni che devono richiedere un token MS-EI devono anche essere in grado di avere la connettività di rete a MS-EI. Potrebbe essere necessario configurare un'impostazione proxy per la connessione.
  6. Per le distribuzioni di Oracle Exadata Database Service on Dedicated Infrastructure, le impostazioni del proxy HTTP nell'ambiente devono consentire al database di utilizzare MS-EI.

    Queste impostazioni vengono definite dall'amministratore della flotta durante la creazione dell'infrastruttura Oracle Exadata Database Service on Dedicated Infrastructure come descritto nella sezione Per creare una risorsa dell'infrastruttura Exadata Cloud.

    Nota

    La configurazione di rete, incluso il proxy HTTP, può essere modificata solo fino a quando lo stato dell'infrastruttura Exadata non richiede l'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.

Prerequisiti di networking per l'autenticazione ID Microsoft Entra (MS-EI)

Prima di utilizzare l'autenticazione Azure AD sui database nell'infrastruttura cloud Exadata, è necessario utilizzare il servizio di networking per aggiungere un gateway di servizi, 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.

  1. Creare un gateway di servizi nella VCN in cui risiedono le risorse del database seguendo le istruzioni riportate nel task 1: creare il gateway di servizi della documentazione OCI.
  2. Dopo aver creato il gateway del servizio, aggiungere una regola di instradamento e una regola di sicurezza di uscita a ogni subnet (nella VCN) in cui risiedono le risorse del database in modo che queste risorse possano utilizzare il gateway per utilizzare l'autenticazione Azure AD.
    1. Passare alla pagina Dettagli subnet per la subnet.
    2. Nella scheda Informazioni sulla 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 caratteristiche riportate di seguito.
      • Obiettivo: 0.0.0.0/0
      • Tipo di destinazione: gateway NAT
      • Destinazione: il nome del gateway NAT appena creato nella VCN

      Se tale 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 Liste 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
      • Obiettivo: 0.0.0.0/0
      • Protocollo IP: TCP
      • Intervallo porte di origine: 443
      • Intervallo di porte di destinazione: tutto
    8. Se una regola di questo tipo non esiste, fare clic su Aggiungi regole di uscita e aggiungere una regola di uscita con queste caratteristiche.

Configurare TLS per l'uso dei token ID Microsoft Entra (MS-EI)

Quando si inviano token MS-EI dal client del database al server del database, è necessario stabilire una connessione TLS.

Il wallet TLS con il certificato di database per l'istanza del servizio ExaDB-D deve essere memorizzato nella posizione WALLET_ROOT. Creare una directory tls con l'aspetto seguente: WALLET_ROOT/<PDB GUID>/tls.

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

  • Utilizzo di un certificato server database autofirmato rispetto a un certificato server database firmato da un'autorità di certificazione comunemente nota
  • TLS unidirezionale (TLS) vs TLS mutuo o bidirezionale (mTLS)
  • Client con o senza wallet

Certificato con firma automatica

L'utilizzo 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 al 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 creato automaticamente 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 verificherà che il certificato inviato dal server del database sia stato firmato dallo stesso certificato radice.

Un'autorità di certificazione ben nota

L'uso di un'autorità di certificazione root comunemente nota presenta alcuni vantaggi in quanto il certificato root è probabilmente già memorizzato nell'area di memorizzazione dei certificati predefinita del sistema client. Non è necessario eseguire altre operazioni per il client per memorizzare il certificato root se si tratta di un certificato root comune. Lo svantaggio è che questo ha normalmente un costo associato ad esso.

TLS unidirezionale

Nella sessione TLS standard, solo il server fornisce un certificato al client per l'autenticazione. Il client non deve disporre di un certificato client separato per autenticarsi sul server (simile al modo in cui vengono stabilite le sessioni HTTPS). Mentre il database richiede un wallet per memorizzare il certificato del server, l'unica cosa che il client deve avere è il certificato root utilizzato per firmare il certificato del server.

TLS a due vie (chiamato 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 server di database e il client per autenticare l'altro certificato. mTLS viene talvolta utilizzato per autenticare l'utente poiché l'identità utente viene autenticata dal server di database tramite il certificato. Questa operazione non è necessaria per il passaggio dei token IAM, ma può essere utilizzata quando si passano i token IAM.

Client con un 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 cliente senza portafoglio

I client possono essere configurati senza un wallet quando si utilizza TLS nelle seguenti condizioni: 1) È in corso la configurazione di TLS unidirezionale in cui il client non dispone di un proprio certificato e 2) il certificato radice che ha firmato il certificato del database server viene memorizzato nell'area di memorizzazione dei certificati predefinita del sistema. È molto probabile che il certificato root sia già presente se il certificato del server è firmato da un'autorità di certificazione comune. Se si tratta di un certificato con firma automatica, è necessario installare il certificato radice nell'area di memorizzazione dei certificati predefinita del sistema per evitare di utilizzare un wallet client.

Per informazioni dettagliate su come configurare TLS tra il client del database e il server del database, incluse le opzioni descritte sopra, vedere:

Se si sceglie di utilizzare i certificati con firma automatica e per task aggiuntivi correlati al wallet, vedere: