Gli utenti IAM possono connettersi all'istanza di database utilizzando un verificatore password del database IAM o un token IAM.

L'uso del verificatore password del database IAM è simile al processo di autenticazione della password del database. Tuttavia, invece di memorizzare nel database il verificatore delle password (hash cifrato della password), il verificatore viene invece memorizzato come parte del profilo utente IAM OCI.

Il secondo metodo di connessione, l'uso di un token IAM per il database, è più moderno. L'uso dell'accesso basato su token si adatta meglio alle risorse cloud come i database Oracle nell'infrastruttura Exadata Cloud. Il token si basa sulla forza che l'endpoint IAM può applicare. Questo può essere l'autenticazione a più fattori, che è più forte dell'uso delle sole password. Un altro vantaggio dell'utilizzo dei token è che il verificatore di password (che è considerato sensibile) non viene mai memorizzato o disponibile in memoria.

L'integrazione di Oracle Cloud Infrastructure IAM con Oracle Exadata Database Service on Dedicated Infrastructure supporta i seguenti:

• Autenticazione del verificatore password del database Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM)
• Autenticazione basata su token SSO di Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM)

Per informazioni dettagliate complete sull'architettura per l'uso degli utenti IAM su Oracle Exadata Database Service on Dedicated Infrastructure, vedere Authenticating and Authorizing IAM Users for Oracle DBaaS Databases nel manuale Oracle Database 19c Security Guide e Oracle Database 23ai Security Guide.

È possibile abilitare un'istanza di Oracle Database per consentire l'accesso utente con una password del database IAM di Oracle Cloud Infrastructure (utilizzando un verificatore delle password).

Una password del database IAM di Oracle Cloud Infrastructure consente a un utente IAM di eseguire il login a un'istanza di Oracle Database quando gli utenti di Oracle Database in genere eseguono il login con un nome utente e una password. L'utente immette il nome utente IAM e la password del database IAM. Una password del database IAM è diversa dalla password della console di Oracle Cloud Infrastructure. L'uso di un utente IAM con un verificatore password consente di eseguire il login a Oracle Database con qualsiasi client di database supportato.

Per l'accesso al database del verificatore password, è possibile creare i mapping per gli utenti IAM e le applicazioni OCI all'istanza di Oracle Database. Gli account utente IAM vengono gestiti in IAM. Gli account utente e i gruppi di utenti possono trovarsi nel dominio predefinito o in un dominio personalizzato non predefinito.

Per ulteriori informazioni sulla gestione della password del database IAM, vedere Gestione delle credenziali utente.

Per l'accesso al database tramite token IAM, l'applicazione o lo strumento client richiede un token di database da IAM per l'utente IAM.

L'applicazione client passerà il token del database direttamente al client del database tramite l'API client del database.

Se l'applicazione o lo strumento non è stato aggiornato per richiedere un token IAM, l'utente IAM può utilizzare l'interfaccia CLI OCI per richiedere e memorizzare il token del database. È possibile richiedere un token di accesso al database (db-token) utilizzando le seguenti credenziali:

• Token di sicurezza (con autenticazione IAM), token di delega (nella cloud shell OCI) e API-keys, ovvero credenziali che rappresentano l'utente IAM per abilitare l'autenticazione
• Token di principal dell'istanza, che consentono alle istanze di essere attori (o principal) autorizzati a eseguire azioni sulle risorse OCI dopo l'autenticazione
• Token di principal risorsa, una credenziale che consente all'applicazione di autenticarsi in altri servizi OCI
• Uso di un nome utente IAM e di una password del database IAM (può essere richiesto solo dal client del database)

Quando gli utenti IAM eseguono il login al client con una barra di login / e il parametro OCI_IAM è configurato (sqlnet.ora, tnsnames.ora o come parte di una stringa di connessione), il client del database recupera il token di database da un file. Se l'utente IAM sottomette un nome utente e una password, la connessione utilizzerà l'accesso al verificatore del database IAM descritto per le connessioni client che utilizzano verificatori delle password del database IAM. Se il parametro PASSWORD_AUTH=OCI_TOKEN, il driver del database utilizzerà invece il nome utente e la password per connettersi direttamente a IAM e richiedere un token di database. Le istruzioni riportate in questa guida mostrano come utilizzare l'interfaccia CLI OCI come applicazione di supporto per il token di database. Se l'applicazione o lo strumento è stato aggiornato per funzionare con IAM, seguire le istruzioni per l'applicazione o lo strumento. Alcuni casi d'uso comuni includono: SQL*Plus on premise, SQLcl on premise, SQL*Plus in Cloud Shell o applicazioni che utilizzano i wallet SEP.

Se un utente immette un nome utente o una password per eseguire il login, il driver del database utilizza il metodo di verifica della password per accedere al database. Se il parametro PASSWORD_AUTH=OCI_TOKEN, il driver del database utilizzerà invece il nome utente e la password per connettersi direttamente a IAM e richiedere un token del database.

Prima di utilizzare l'autenticazione IAM nei database nell'infrastruttura Exadata Cloud, è 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 IAM:
   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.
      • Destinazione: tutti i servizi IAD in Oracle Services Network
      • Tipo di destinazione: gateway del servizio
      • Destinazione: il nome del gateway di servizi 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 dei dettagli della 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:
      • Senza stato: No
      • Destinazione: tutti i servizi IAD in Oracle Services Network
      • Protocollo IP: TCP
      • Intervallo porte di origine: tutto
      • Intervallo di porte di destinazione: 443
   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.

Rivedere i prerequisiti per abilitare l'accesso utente IAM a Oracle Database.

Se il database è abilitato per un altro schema di autenticazione esterno, verificare che si desidera utilizzare IAM nell'istanza di Oracle Database. Può essere abilitato un solo schema di autenticazione esterna alla volta.

Se si desidera utilizzare IAM ed è abilitato un altro schema di autenticazione esterno, è necessario prima disabilitare l'altro schema di autenticazione esterno.

Quando si inviano i token IAM 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 in precedenza, vedere Configuring Transport Layer Security Authentication nel manuale Oracle Database Security Guide.

Se si sceglie di utilizzare i certificati con firma automatica e per task aggiuntivi correlati al wallet, vedere Managing Public Key Infrastructure (PKI) Elements in Oracle Database Security Guide.