Usa autenticazione Azure Active Directory con Base Database Service

È possibile configurare Oracle 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.

Argomenti correlati

Informazioni sull'integrazione di Azure AD con Base Database Service

È possibile configurare un Oracle Database in un'istanza di Base Database Service per consentire agli utenti di Microsoft Azure Active Directory (Azure AD) di connettersi utilizzando i token di accesso OAuth2 di Azure.

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 Introduzione all'autorizzazione degli utenti di Microsoft Azure AD per un Oracle Database del manuale Oracle Database Security Guide.

Prerequisiti

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

Ciascuno 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 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. Eseguire i passi riportati di seguito per configurare la connettività in uscita in 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 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 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:
      • Data: 0.0.0.0/0
      • Tipo di destinazione: gateway NAT
      • Destinazione: il nome del gateway di servizi 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
    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.

Configurazione TLS

Quando si inviano token Azure AD dal client del database al server del database, è 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 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 portafoglio.

Certificato con firma automatica: l'utilizzo di un certificato con firma automatica è una pratica comune per le risorse IT interne, in quanto è possibile crearle personalmente 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 (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 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. Ciò non è necessario per il passaggio dei token di Azure AD, ma può essere utilizzato quando si passano i token di Azure AD.

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 client senza un wallet: i client possono essere configurati senza un wallet quando si utilizza TLS nelle condizioni riportate di seguito.
  1. È in corso la configurazione di TLS unidirezionale in cui il client non dispone del 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 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 in precedenza, vedere Configurazione dell'autenticazione TLS (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 all'interfaccia della riga di comando (CLI, Command Line Interface) orapki nel manuale Database Security Guide. Vedere Managing Public Key Infrastructure (PKI) Elements.

Configurare Base Database Service per l'integrazione con Azure AD

L'integrazione di Base Database Service con Azure AD richiede che il database venga 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, è innanzitutto necessario completare i prerequisiti nella sezione Prerequisiti, quindi seguire le istruzioni riportate nella sezione Configuring the Oracle Database for Microsoft Azure AD Integration della Guida per la sicurezza di Oracle Database.

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.

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

Configurare le connessioni client agli AD di Azure

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

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

Test dell'accessibilità dell'endpoint di Azure

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

Per ulteriori informazioni sul test della connessione, vedere la sezione Test dell'accessibilità dell'endpoint di Azure nel manuale Oracle 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 Database Security Guide.