Les utilisateurs GIA peuvent se connecter à l'instance de base de données à l'aide d'un vérificateur de mot de passe de base de données GIA ou d'un jeton GIA.

L'utilisation du vérificateur de mot de passe de base de données GIA est similaire au processus d'authentification par mot de passe de base de données. Toutefois, au lieu d'être stocké dans la base de données, le vérificateur de mot de passe (hachage chiffré du mot de passe) est stocké dans le profil d'utilisateur GIA pour OCI.

La seconde méthode de connexion, l'utilisation d'un jeton GIA pour la base de données, est plus moderne. L'utilisation de l'accès basé sur un jeton est plus adaptée aux ressources en nuage telles que les bases de données Oracle dans une infrastructure Exadata en nuage. Le jeton est basé sur la force que le point d'extrémité GIA peut appliquer. Il peut s'agir d'une authentification multifacteur, qui est plus forte que l'utilisation de mots de passe seuls. Un autre avantage de l'utilisation de jetons est que le vérificateur de mot de passe (qui est considéré comme sensible) n'est jamais stocké ni disponible en mémoire.

L'intégration du service GIA pour Oracle Cloud Infrastructure avec le service Oracle Exadata Database sur une infrastructure dédiée prend en charge les éléments suivants :

• Authentification au moyen du vérificateur de mot de passe de base de données du service de gestion des identités et des accès (GIA) pour Oracle Cloud Infrastructure (OCI)
• Authentification basée sur un jeton d'authentification unique du service de gestion des identités et des accès (GIA) pour Oracle Cloud Infrastructure (OCI)

Pour obtenir des détails complets sur l'architecture d'utilisation des utilisateurs IAM dans le service Oracle Exadata Database Service on Dedicated Infrastructure, voir Authentification et autorisation des utilisateurs IAM pour les bases de données Oracle DBaaS dans le guide de sécurité d'Oracle Database 19c et le guide de sécurité d'Oracle Database 23ai.

Vous pouvez activer une instance Oracle Database pour autoriser l'accès des utilisateurs à l'aide d'un mot de passe de base de données GIA pour Oracle Cloud Infrastructure (au moyen d'un vérificateur de mot de passe).

Un mot de passe de base de données IAM pour Oracle Cloud Infrastructure permet à un utilisateur IAM de se connecter à une instance Oracle Database, car les utilisateurs d'Oracle Database se connectent généralement avec un nom d'utilisateur et un mot de passe. L'utilisateur entre son nom d'utilisateur IAM et son mot de passe de base de données IAM. Le mot de passe de base de données GIA est différent du mot de passe de la console Oracle Cloud Infrastructure. À l'aide d'un utilisateur IAM avec un vérificateur de mot de passe, vous pouvez vous connecter à Oracle Database avec n'importe quel client de base de données pris en charge.

Pour l'accès à la base de données du vérificateur de mot de passe, vous créez les mappages pour les utilisateurs IAM et les applications OCI à l'instance Oracle Database. Les comptes d'utilisateur IAM eux-mêmes sont gérés dans le service IAM. Les comptes d'utilisateur et les groupes d'utilisateurs peuvent se trouver dans le domaine par défaut ou dans un domaine personnalisé autre que celui par défaut.

Pour plus d'informations sur la gestion de mot de passe de base de données GIA, voir Gestion des données d'identification des utilisateurs.

Pour l'accès par jeton GIA à la base de données, l'application ou l'outil client demande un jeton de base de données à GIA pour l'utilisateur GIA.

L'application client transmet le jeton de base de données directement au client de base de données au moyen de l'API du client de base de données.

Si l'application ou l'outil n'a pas été mis à jour pour demander un jeton GIA, l'utilisateur GIA peut utiliser l'interface de ligne de commande OCI pour demander et stocker le jeton de base de données. Vous pouvez demander un jeton d'accès à la base de données (db-token) à l'aide des données d'identification suivantes :

• Jetons de sécurité (avec authentification GIA), jetons de délégation (dans OCI Cloud Shell) et API-keys (données d'identification qui représentent l'utilisateur GIA pour activer l'authentification)
• Jetons de principal d'instance, qui permettent aux instances d'être des acteurs (ou principaux) autorisés à effectuer des actions sur les ressources OCI après l'authentification
• Jeton de principal de ressource (données d'identification permettant à l'application de s'authentifier auprès d'autres services OCI)
• Nom d'utilisateur GIA et mot de passe de base de données GIA (peuvent uniquement être demandés par le client de base de données)

Lorsque les utilisateurs GIA se connectent au client avec une barre oblique / et que le paramètre OCI_IAM est configuré (sqlnet.ora, tnsnames.ora ou dans une chaîne de connexion), le client de base de données extrait le jeton de base de données d'un fichier. Si l'utilisateur GIA soumet un nom d'utilisateur et un mot de passe, la connexion utilise l'accès au vérificateur de base de données GIA décrit pour les connexions de clients qui utilisent des vérificateurs de mot de passe de base de données GIA. Avec le paramètre PASSWORD_AUTH=OCI_TOKEN, le pilote de base de données utilise à la place le nom d'utilisateur et le mot de passe pour se connecter directement à GIA et demander un jeton de base de données. Les instructions de ce guide montrent comment utiliser l'interface de ligne de commande OCI comme aide pour le jeton de base de données. Si l'application ou l'outil a été mis à jour pour fonctionner avec GIA, suivez les instructions pour l'application ou l'outil. Voici certains cas d'utilisation courants : SQL*Plus sur place, SQLcl sur place, SQL*Plus dans Cloud Shell ou applications qui utilisent des portefeuilles SEP.

Si un utilisateur entre un nom d'utilisateur/mot de passe pour se connecter, le pilote de base de données utilise la méthode de vérification du mot de passe pour accéder à la base de données. Avec le paramètre PASSWORD_AUTH=OCI_TOKEN, le pilote de base de données utilise à la place le nom d'utilisateur et le mot de passe pour se connecter directement à GIA et demander un jeton de base de données.

Avant d'utiliser l'authentification GIA dans les bases de données de l'infrastructure Exadata en nuage, vous devez utiliser le service de réseau pour ajouter une passerelle de service, une règle de routage et une règle de sécurité de trafic sortant au réseau en nuage virtuel et aux sous-réseaux où résident vos ressources de base de données.

1. Créez une passerelle de service dans le réseau en nuage virtuel où résident vos ressources de base de données autonome en suivant les instructions sous Tâche 1 : Créer la passerelle de service dans la documentation sur OCI.
2. Après avoir créé la passerelle de service, ajoutez une règle de routage et une règle de sécurité de trafic sortant à chaque sous-réseau (dans le VCN) où résident des ressources de base de données afin que ces ressources puissent utiliser la passerelle pour utiliser l'authentification GIA :
   1. Allez à la page Détails du sous-réseau associée au sous-réseau.
   2. Dans l'onglet Informations sur le sous-réseau, cliquez sur le nom de la table de routage du sous-réseau pour afficher la page Détails de la table de routage.
   3. Dans la table des règles de routage existantes, vérifiez s'il existe déjà une règle présentant les caractéristiques suivantes :
      • Destination : Tous les services IAD dans Oracle Services Network
      • Type de cible : Passerelle de service
      • Cible : Nom de la passerelle de service que vous venez de créer dans le VCN

      Si une telle règle n'existe pas, cliquez sur Ajouter des règles de routage et ajoutez une règle de routage avec ces caractéristiques.

   4. Retournez à la page Détails du sous-réseau.
   5. Dans la table Listes de sécurité du sous-réseau, cliquez sur le nom de la liste de sécurité du sous-réseau pour afficher la page Détails de la liste de sécurité.
   6. Dans le menu latéral, sous Ressources, cliquez sur Règles de trafic sortant.
   7. Dans la table des règles de trafic sortant existantes, vérifiez s'il existe déjà une règle présentant les caractéristiques suivantes :
      • Sans état : Non
      • Destination : Tous les services IAD dans Oracle Services Network
      • Protocole IP : TCP
      • Intervalle de ports sources : Tous
      • Intervalle de ports de destination : 443
   8. Si une telle règle n'existe pas, cliquez sur Ajouter des règles de trafic sortant et ajoutez une règle de trafic sortant avec ces caractéristiques.

Vérifiez les préalables à l'activation de l'accès des utilisateurs GIA à Oracle Database.

Si la base de données est activée pour un autre modèle d'authentification externe, vérifiez que vous souhaitez utiliser GIA pour l'instance Oracle Database. Un seul modèle d'authentification externe peut être activé à la fois.

Si vous voulez utiliser GIA et qu'un autre modèle d'authentification externe est activé, vous devez d'abord désactiver celui-ci.

Lors de l'envoi de jetons GIA du client de base de données au serveur de base de données, une connexion TLS doit être établie. Le portefeuille TLS doté du certificat de base de données pour l'instance de service ExaDB-D doit être stocké dans l'emplacement WALLET_ROOT. Créez un répertoire tls qui ressemble à : WALLET_ROOT/<PDB GUID>/tls.

Lors de la configuration de TLS entre le client et le serveur de base de données, plusieurs options sont à prendre en compte.

• Utilisation d'un certificat de serveur de base de données auto-signé ou d'un certificat de serveur de base de données signé par une autorité de certification connue
• Authentification TLS unidirectionnelle (TLS) ou authentification TLS mutuelle ou bidirectionnelle (mTLS)
• Client avec ou sans portefeuille

Certificat auto-signé

L'utilisation d'un certificat auto-signé est une pratique commune pour les ressources informatiques en interne, car vous pouvez les créer vous-même et gratuitement. La ressource (ici, le serveur de base de données) aura un certificat auto-signé pour s'authentifier auprès du client de base de données. Le certificat auto-signé et le certificat racine seront stockés dans le portefeuille du serveur de base de données. Pour que le client de base de données puisse reconnaître le certificat du serveur de base de données, une copie du certificat racine sera également nécessaire sur le client. Ce certificat racine créé automatiquement peut être stocké dans un portefeuille côté client ou installé dans le magasin de certificats par défaut du système client (Windows et Linux uniquement). Lorsque la session est établie, le client de base de données vérifie que le certificat envoyé par le serveur de base de données a été signé par le même certificat racine.

Autorité de certification bien connue

L'utilisation d'une autorité de certification racine connue présente certains avantages dans la mesure où le certificat racine est probablement déjà stocké dans le magasin de certificats par défaut du système client. Aucune étape supplémentaire n'est requise pour le client pour le stockage du certificat racine si celui-ci est un certificat racine commun. L'inconvénient est que généralement, cela représente un coût.

Authentification TLS unidirectionnelle

Dans la session TLS standard, seul le serveur fournit un certificat au client pour lui permettre de s'authentifier. Le client n'a pas besoin de disposer d'un certificat client distinct pour s'authentifier auprès du serveur (comme pour l'établissement des sessions HTTPS). Alors que la base de données nécessite un portefeuille pour stocker le certificat du serveur, la seule chose dont le client a besoin est le certificat racine utilisé pour signer le certificat du serveur.

Authentification TLS bidirectionnelle (également appelée authentification TLS mutuelle, mTLS)

Dans mTLS, le client et le serveur disposent tous deux de certificats d'identité qui sont présentés l'un à l'autre. Dans la plupart des cas, le même certificat racine aura signé ces deux certificats de sorte que le même certificat racine puisse être utilisé avec le serveur et le client de base de données pour authentifier l'autre certificat. mTLS est parfois utilisé pour authentifier l'utilisateur puisque l'identité de l'utilisateur est authentifiée par le serveur de base de données au moyen du certificat. Bien que non nécessaire, cela peut être utilisé lors de la transmission de jetons GIA.

Client avec un portefeuille

Un portefeuille de client est obligatoire lors de l'utilisation de mTLS pour stocker le certificat de client. Toutefois, le certificat racine peut être stocké dans le même portefeuille ou dans le magasin de certificats par défaut du système.

Client sans portefeuille

Les clients peuvent être configurés sans portefeuille lors de l'utilisation de TLS dans les conditions suivantes : 1) L'authentification TLS unidirectionnelle est configurée lorsque le client ne dispose pas de son propre certificat et 2) Le certificat racine qui a signé le certificat du serveur de base de données est stocké dans le magasin de certificats par défaut du système. Le certificat racine est probablement déjà présent si le certificat du serveur est signé par une autorité de certification commune. S'il s'agit d'un certificat auto-signé, le certificat racine doit être installé dans le magasin de certificats par défaut du système pour éviter l'utilisation d'un portefeuille de client.

Pour plus de détails sur la configuration de TLS entre le client de base de données et le serveur de base de données, notamment les options décrites ci-dessus, voir Configuration de l'authentification TLS dans le guide sur la sécurité d'Oracle Database.

Si vous choisissez d'utiliser des certificats auto-signés et pour d'autres tâches liées au portefeuille, voir Gestion des éléments d'infrastructure à clé publique dans le guide sur la sécurité d'Oracle Database.