Utiliser l'authentification du service de gestion des identités et des accès avec le service de base de données de base

Vous pouvez configurer Oracle Database dans le service de base de données de base afin d'utiliser l'authentification et l'autorisation du service de gestion des identités et des accès (GIA) pour Oracle Cloud Infrastructure pour permettre aux utilisateurs GIA d'accéder à la base de données à l'aide des données d'identification GIA.

Note :

Oracle Database prend en charge l'intégration du service de base de données de base pour le service IAM pour OCI avec des domaines d'identité, ainsi que le service IAM existant, qui n'inclut pas les domaines d'identité. Les utilisateurs et les groupes de domaines par défaut et non par défaut sont pris en charge lors de l'utilisation du service IAM avec des domaines d'identité.

La prise en charge des domaines personnalisés autres que ceux par défaut n'est disponible qu'avec Oracle Database version 19c, version 19.21 et versions ultérieures (mais pas avec Oracle Database version 21c).

À propos de l'authentification GIA

L'intégration du service GIA pour OCI au service de base de données de base prend en charge l'authentification au moyen du vérificateur de mot de passe de base de données et l'authentification par jeton. Pour plus d'informations sur l'architecture permettant d'utiliser des utilisateurs GIA dans le service de base de données de base, voir Authentification et autorisation des utilisateurs GIA pour les bases de données Oracle DBaaS.

Authentification par mot de passe de base de données GIA

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 IAM OCI (à l'aide d'un vérificateur de mot de passe).

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.

Note :

Tout client de base de données 12c et supérieur pris en charge peut être utilisé pour l'accès par mot de passe de base de données IAM à Oracle Database.

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

Authentification basée sur un jeton d'authentification unique GIA

Vous pouvez activer une instance Oracle Database pour utiliser des jetons d'authentification unique IAM pour OCI.

Pour l'accès à la base de données de jeton, 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.

Il existe plusieurs façons pour un client de base de données d'obtenir un jeton de base de données GIA :

  • Une application ou un outil client peut demander le jeton de base de données à GIA pour l'utilisateur et le transmettre au moyen de l'API client. L'utilisation de l'API pour envoyer le jeton remplace les autres paramètres du client de base de données. L'utilisation du jeton de base de données GIA nécessite le client Oracle Database 19.16 et version supérieure (et non 21c). Des capacités limitées (non complètes) de jeton de base de données GIA sont disponibles avec certains clients Oracle Database 21.5 et versions ultérieures.
  • Si l'application ou l'outil ne prend pas en charge la demande de jeton de base de données GIA et l'envoi à la base de données au moyen de l'API client, l'utilisateur GIA peut d'abord utiliser l'interface de ligne de commande OCI pour extraire le jeton de base de données GIA et l'enregistrer dans un fichier. Par exemple, pour utiliser SQL*Plus et d'autres applications et outils à l'aide de cette méthode de connexion, vous devez d'abord obtenir le jeton de base de données à l'aide de l'interface de ligne de commande OCI. Si le client de base de données est configuré pour les jetons de base de données GIA, lorsqu'un utilisateur se connecte avec une barre oblique, le pilote de base de données utilise le jeton de base de données GIA qui a été enregistré dans un fichier par défaut ou spécifié.
  • Une application ou un outil client peut utiliser un principal d'instance ou un principal de ressource GIA OCI pour obtenir un jeton de base de données GIA et utiliser ce jeton pour s'authentifier auprès d'une instance de base de données.
  • Les utilisateurs GIA et les applications OCI peuvent demander un jeton de base de données à GIA à l'aide de plusieurs méthodes, notamment une clé d'API.

    Pour plus d'informations sur la configuration de la connexion client, voir Configurer la connexion de client pour SQL*Plus utilisant un jeton GIA. Pour plus d'informations sur d'autres méthodes, telles que l'utilisation d'un jeton de délégation dans OCI Cloud Shell, voir Authentification et autorisation des utilisateurs GIA pour les bases de données Oracle DBaaS.

Si un utilisateur entre un nom d'utilisateur et un 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 en tant que méthode par défaut.

Conditions requises

Les préalables suivants sont requis pour l'authentification GIA dans le service de base de données de base.

Paramètres de réseau

Avant d'utiliser l'authentification GIA dans des bases de données, 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 (VCN) et aux sous-réseaux où résident vos ressources de base de données.

  1. Créez une passerelle de service dans le VCN où résident vos ressources de base de données en suivant les instructions sous Créer la passerelle de service.
  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.

Paramètres d'environnement

Vérifiez si WALLET_ROOT est configuré ou non :

show parameters wallet_root;
NAME               TYPE        VALUE
------------------ ----------- --------
wallet_root        string     

Si un emplacement de répertoire ne s'affiche pas pour WALLET_ROOT, vous ne pourrez pas configurer cette base de données avec le service GIA. WALLET_ROOT doit être défini lors de la prochaine application de correctifs à votre base de données. Les nouvelles bases de données seront fournies avec le jeu WALLET_ROOT.

Configuration TLS

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 du service de base de données de base 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.

TLS unidirectionnel : 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.

TLS bidirectionnel (également appelé TLS mutuel, 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.

Si vous choisissez d'utiliser des certificats auto-signés et pour d'autres tâches liées au portefeuille, consultez le guide de référence de l'interface de ligne de commande orapki dans le Guide de sécurité d'Oracle Database. Voir Gestion des éléments d'infrastructure à clé publique.

Modifier les fournisseurs d'identités externes

Cette rubrique décrit les étapes pour remplacer le fournisseur d'identités externe CMU (utilisateurs gérés de manière centralisée) par GIA OCI (authentification et autorisation), et vice-versa, dans le service de base de données de base.

L'authentification et l'autorisation du service GIA pour OCI pour les utilisateurs ne sont pas activées pour les nouvelles bases de données provisionnées, par défaut. Une autre option pour l'authentification externe consiste à recourir à des utilisateurs gérés de manière centralisée avec Active Directory (CMU-AD). Un seul modèle d'authentification externe peut être activé à la fois.

Activer l'authentification et l'autorisation GIA pour OCI

Effectuez les étapes suivantes pour activer l'authentification et l'autorisation GIA pour OCI.

  1. Activez l'authentification et l'autorisation GIA pour OCI à l'aide de la commande ALTER SYSTEM.
    ALTER SYSTEM SET IDENTITY_PROVIDER_TYPE=OCI_IAM SCOPE=BOTH;
  2. Vérifiez la valeur du paramètre de système IDENTITY_PROVIDER_TYPE.
    SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME='identity_provider_type';
    NAME                   VALUE   
    ---------------------- ------- 
    identity_provider_type OCI_IAM 
  3. Vérifiez si le paramètre IDENTITY_PROVIDER_CONFIG a été défini.
    SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME='identity_provider_config';
  4. Si le paramètre IDENTITY_PROVIDER_CONFIG a été défini, réinitialisez ce paramètre.
    ALTER SYSTEM RESET IDENTITY_PROVIDER_CONFIG SCOPE=BOTH;

Désactiver l'authentification et l'autorisation GIA pour OCI

Effectuez l'étape suivante pour désactiver l'authentification et l'autorisation GIA pour OCI.

  1. Désactivez l'intégration à GIA pour OCI à l'aide de la commande ALTER SYSTEM.
    ALTER SYSTEM RESET IDENTITY_PROVIDER_TYPE SCOPE=BOTH;

Activer CMU-AD

Effectuez les étapes suivantes pour permettre aux utilisateurs d'Active Directory (AD) de se connecter à la base de données à l'aide de CMU :

  1. Désactivez l'intégration GIA comme décrit dans Désactiver l'authentification et l'autorisation GIA pour OCI.
  2. Configurez CMU-AD comme décrit dans Configuration d'utilisateurs gérés de façon centralisée avec Microsoft Active Directory.

Désactiver CMU-AD

Effectuez l'étape suivante pour désactiver CMU-AD :

  1. Désactivez CMU-AD à l'aide de la commande ALTER SYSTEM.
    ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = 'NONE';

Réactiver l'authentification et l'autorisation GIA pour OCI

Effectuez les étapes suivantes pour réactiver les utilisateurs GIA pour leur permettre de se connecter à la base de données à l'aide de l'authentification et de l'autorisation GIA pour OCI :

  1. Désactivez CMU-AD comme décrit dans Désactiver CMU-AD.
  2. Activez l'authentification et l'autorisation GIA pour OCI, comme décrit sous Activer l'authentification et l'autorisation GIA pour OCI.

Créer des groupes GIA et des politiques pour les utilisateurs GIA

Cette rubrique décrit les étapes pour écrire des énoncés de politique pour un groupe GIA afin de permettre aux utilisateurs GIA d'accéder aux ressources OCI, en particulier aux instances de base de données.

Une politique est un groupe d'énoncés spécifiant qui peut accéder à quelles ressources, et comment. L'accès peut être accordé pour l'ensemble de la location, des bases de données dans un compartiment ou des bases de données individuelles. Autrement dit, vous écrivez un énoncé de politique qui donne à un groupe spécifique un type d'accès spécifique à un type de ressource spécifique dans un compartiment spécifique.

Note :

La définition d'une politique est requise pour utiliser des jetons IAM pour accéder à la base de données. Aucune politique n'est requise lorsque vous utilisez des mots de passe de base de données GIA pour accéder à la base de données.

Pour que la base de données autorise les utilisateurs GIA à se connecter à la base de données à l'aide de jetons GIA :

  1. Effectuez les préalables du service GIA pour OCI en créant un groupe et en ajoutant des utilisateurs au groupe.

    Par exemple, créez le groupe sales_dbusers.

    Pour plus d'informations, voir Gestion des groupes.

  2. Écrivez des énoncés de politique pour permettre l'accès aux ressources OCI.

    1. Dans la console OCI, cliquez sur Identité et sécurité, puis cliquez sur Politiques.
    2. Pour écrire une politique, cliquez sur Créer une politique et complétez les champs Nom et Description.
    3. Utilisez le générateur de politiques pour créer une politique.

      Par exemple, pour créer une politique autorisant les utilisateurs du groupe GIA DBUsers à accéder à toute base de données de leur location :

      Allow group DBUsers to use database-connections in tenancy

      Par exemple, pour créer une politique qui autorise les membres du groupe DBUsers à accéder uniquement aux bases de données du compartiment testing_compartment :

      allow group DBUsers to use database-connections in compartment testing_compartment

      Par exemple, pour créer une politique qui restreint l'accès d'un groupe à une seule base de données d'un compartiment :

      allow group DBUsers to use database-connections in compartment testing_compartment 
          where target.database.id = 'ocid1.database.oc1.iad.aabbcc' 
    4. Cliquez sur Créer.

      Pour plus d'informations sur les politiques, voir Gestion des politiques.

Note :

Les éléments suivants sont requis pour créer des politiques à utiliser avec les utilisateurs GIA dans la base de données du service de base de données de base.

  • Les politiques peuvent autoriser les utilisateurs GIA à accéder aux instances de base de données dans toute la location ou dans un compartiment, ou elles peuvent limiter l'accès à une seule instance de base de données.

  • Vous pouvez utiliser un principal d'instance ou de ressource pour extraire des jetons de base de données afin d'établir une connexion entre votre application et une instance de base de données. Si vous utilisez un principal d'instance ou de ressource, vous devez mapper un groupe dynamique. Ainsi, vous ne pouvez pas mapper exclusivement des principaux d'instance et de ressource; vous pouvez uniquement les mapper au moyen d'un mappage partagé et placer le principal d'instance ou de ressource dans un groupe dynamique GIA.

    Vous pouvez créer des groupes dynamiques et les référencer dans les politiques que vous créez pour accéder à OCI.

    Pour plus d'informations, voir Gestion des groupes dynamiques.

Ajouter des utilisateurs GIA

Pour ajouter des utilisateurs GIA afin d'autoriser l'accès à la base de données, mappez des utilisateurs de base de données globaux à des groupes ou des utilisateurs GIA à l'aide des énoncés CREATE USER ou ALTER USER (avec la clause IDENTIFIED GLOBALLY AS).

L'autorisation des utilisateurs GIA dans une instance de base de données fonctionne en mappant les utilisateurs globaux (schémas) de la base de données à des utilisateurs GIA (mappage exclusif) ou à des groupes GIA (mappage de schéma partagé).

Pour autoriser des utilisateurs GIA pour une instance de base de données :

Effectuez les étapes suivantes pour autoriser des utilisateurs GIA sur une instance de base de données.

  1. Connectez-vous en tant qu'utilisateur ADMIN à la base de données configurée pour utiliser GIA (l'utilisateur ADMIN dispose des privilèges système CREATE USER et ALTER USER requis pour ces étapes).
  2. Créez un mappage entre les utilisateurs de base de données (schéma) à l'aide des énoncés CREATE USER ou ALTER USER et incluez la clause IDENTIFIED GLOBALLY AS, en spécifiant le nom du groupe GIA.

    Utilisez la syntaxe suivante pour mapper un utilisateur global à un groupe GIA :

    CREATE USER global_user IDENTIFIED GLOBALLY AS 'IAM_GROUP_NAME=IAM_GROUP_NAME';

    Par exemple, pour mapper un groupe GIA nommé db_sales_group à un utilisateur global de base de données partagé nommé sales_group :

    CREATE USER sales_group IDENTIFIED GLOBALLY AS 'IAM_GROUP_NAME=db_sales_group';

    Un mappage d'utilisateur global partagé est créé. Le mappage avec l'utilisateur global sales_group est effectif pour tous les utilisateurs du groupe GIA. Ainsi, tout membre de db_sales_group peut se connecter à la base de données à l'aide de ses données d'identification GIA (au moyen du mappage partagé de l'utilisateur global sales_group).

    L'exemple suivant montre comment effectuer cette opération pour un domaine autre que celui par défaut, sales_domain :

    CREATE USER shared_sales_schema IDENTIFIED GLOBALLY AS 
        'IAM_GROUP_NAME=sales_domain/db_sales_group';
  3. Pour créer des mappages d'utilisateurs globaux supplémentaires pour d'autres groupes ou utilisateurs GIA, suivez ces étapes pour chaque groupe ou utilisateur GIA.

Note :

Les utilisateurs de base de données qui ne sont pas IDENTIFIED GLOBALLY peuvent continuer à se connecter comme précédemment, même lorsque la base de données est activée pour l'authentification IAM.

Pour mapper de manière exclusive un utilisateur GIA local à un utilisateur global Oracle Database :

Effectuez les étapes suivantes pour mapper de manière extensible un utilisateur GIA local à un utilisateur global Oracle Database.

  1. Connectez-vous en tant qu'utilisateur ADMIN à la base de données configurée pour utiliser GIA (l'utilisateur ADMIN dispose des privilèges système CREATE USER et ALTER USER requis pour ces étapes).
  2. Créez un mappage entre les utilisateurs de la base de données (schéma) à l'aide des énoncés CREATE USER ou ALTER USER et incluez la clause IDENTIFIED GLOBALLY AS, en spécifiant le nom de l'utilisateur GIA local.

    Par exemple, pour créer un utilisateur global de base de données nommé peter_fitch et mapper cet utilisateur à un utilisateur GIA local existant nommé peterfitch :

    CREATE USER peter_fitch IDENTIFIED GLOBALLY AS 'IAM_PRINCIPAL_NAME=peterfitch'

    L'exemple suivant montre comment créer l'utilisateur en spécifiant un domaine non par défaut, sales_domain :

    CREATE USER peter_fitch2 IDENTIFIED GLOBALLY AS 
        'IAM_PRINCIPAL_NAME=sales_domain/peterfitch';

Ajouter des rôles GIA

Vous pouvez créer des rôles globaux pour fournir des rôles et des privilèges de base de données supplémentaires aux utilisateurs GIA lorsque plusieurs utilisateurs GIA sont mappés au même utilisateur global partagé.

La création de rôles globaux est facultative pour un utilisateur GIA ayant un mappage GIA exclusif à un utilisateur de base de données (schéma). Avec un mappage GIA à un schéma partagé, la création d'un rôle global est également facultative. Par exemple, tous les privilèges et rôles peuvent être accordés au schéma partagé; tous les utilisateurs GIA mappés au schéma partagé se voient alors accorder les privilèges et les rôles affectés à ce schéma.

Éventuellement, utilisez un rôle global pour différencier les utilisateurs qui utilisent le même schéma partagé. Par exemple, plusieurs utilisateurs peuvent avoir le même schéma partagé et celui-ci peut disposer du privilège CREATE SESSION. Des rôles globaux peuvent alors être utilisés pour fournir des privilèges et des rôles différenciés à différents groupes d'utilisateurs qui utilisent tous le même schéma partagé.

Pour accorder des rôles supplémentaires aux utilisateurs GIA, il faut mapper les rôles globaux de la base de données à des groupes GIA.

Mapper les rôles globaux de base de données aux groupes GIA :

Effectuez les étapes suivantes pour mapper les rôles globaux de base de données aux groupes GIA.

  1. Connectez-vous en tant qu'utilisateur ADMIN à la base de données configurée pour utiliser GIA (l'utilisateur ADMIN dispose des privilèges système CREATE USER et ALTER USER requis pour ces étapes).
  2. Définissez l'autorisation de base de données pour les rôles de base de données à l'aide des énoncés CREATE ROLE ou ALTER ROLE et incluez la clause IDENTIFIED GLOBALLY AS, en spécifiant le nom du groupe GIA.

    Utilisez la syntaxe suivante pour mapper un rôle global à un groupe GIA :

    CREATE ROLE global_role IDENTIFIED GLOBALLY AS 
        'IAM_GROUP_NAME=IAM_GROUP_of_WHICH_the_IAM_USER_IS_a_MEMBER';

    Par exemple, pour mapper un groupe GIA nommé ExporterGroup à un rôle global de base de données partagé nommé export_role :

    CREATE ROLE export_role IDENTIFIED GLOBALLY AS 'IAM_GROUP_NAME=ExporterGroup';

    L'exemple suivant montre comment créer le rôle en spécifiant un domaine non par défaut, sales_domain :

    CREATE ROLE export_role IDENTIFIED GLOBALLY AS 
        'IAM_GROUP_NAME=sales_domain/ExporterGroup';

    Tous les membres de ExporterGroup dans le domaine sales_domain seront autorisés avec le rôle global de base de données export_role lorsqu'ils se connecteront à la base de données.

  3. Utilisez des énoncés GRANT pour accorder les privilèges requis ou d'autres rôles au rôle global.
    GRANT CREATE SESSION TO export_role;
    GRANT DWROLE TO export_role;
  4. Pour associer un rôle de base de données existant à un groupe GIA, utilisez l'énoncé ALTER ROLE pour modifier le rôle de base de données existant afin de le mapper à un groupe GIA. Utilisez la syntaxe suivante pour modifier un rôle de base de données existant afin de le mapper à un groupe GIA :
    ALTER ROLE existing_database_role 
       IDENTIFIED GLOBALLY AS 'IAM_GROUP_NAME=IAM_Group_Name';

Pour ajouter des mappages de rôle globaux supplémentaires pour d'autres groupes GIA, suivez les étapes ci-dessus pour chaque groupe GIA.

Créer un mot de passe de base de données GIA pour les utilisateurs GIA

Pour ajouter un utilisateur GIA et lui permettre de se connecter à la base de données en fournissant un nom d'utilisateur et un mot de passe, vous devez créer un mot de passe de base de données GIA. Un nom d'utilisateur GIA et un mot de passe de base de données GIA peuvent être utilisés de l'une des deux façons suivantes.

  1. L'utilisateur GIA peut entrer le nom d'utilisateur GIA et le mot de passe de base de données GIA lorsqu'il accède à la base de données. Par défaut, le client de la base de données suivra le mécanisme d'authentification de mot de passe normal avec la base de données. La base de données extraira le vérificateur de mot de passe de base de données GIA du service GIA.
  2. Le client de base de données peut être configuré pour obtenir un jeton de base de données GIA à l'aide du nom d'utilisateur GIA et du mot de passe de base de données GIA. Le client de base de données enverra ce jeton de base de données à la base de données pour l'accès de l'utilisateur.

Pour plus d'informations sur l'obtention d'un jeton de base de données GIA à l'aide du nom d'utilisateur GIA et du mot de passe de base de données GIA, voir Configuration du service GIA pour Oracle DBaaS.

Pour plus d'informations sur les mots de passe de base de données GIA, voir Utilisation des noms d'utilisateur et des mots de passe de base de données GIA dans Gestion des données d'identification d'utilisateur.

Se connecter à la base de données à l'aide de l'authentification GIA

Après que l'utilisateur de base de données ADMIN a mappé les utilisateurs et les rôles globaux aux utilisateurs et aux groupes GIA, les utilisateurs se connectent à l'instance de base de données à l'aide de leurs données d'identification ou accèdent à la base de données au moyen d'un jeton de base de données GIA pour OCI.

Vous pouvez toujours vous connecter à la base de données à l'aide du nom d'utilisateur et du mot de passe de votre compte de base de données local (compte d'utilisateur de base de données non global).

Vous pouvez utiliser un client de base de données pour accéder à une instance de base de données en tant qu'utilisateur GIA pour OCI. Pour utiliser un client avec les données d'identification de nom d'utilisateur et de mot de passe GIA pour OCI et un vérificateur de mot de passe, le client de base de données doit avoir la version 12c ou une version plus récente.

L'utilisation du jeton de base de données GIA nécessite le client Oracle Database 19.16 et version supérieure (et non 21c). Des capacités limitées (non complètes) de jeton de base de données GIA sont disponibles avec certains clients Oracle Database 21.5 et versions ultérieures.

Note :

Si votre instance de base de données est en mode restreint, seuls les utilisateurs dotés du privilège RESTRICTED SESSION, par exemple ADMIN, peuvent se connecter à la base de données.

À propos de la connexion à une instance de base de données à l'aide du service GIA

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 utilise un jeton GIA pour la base de données. 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 le service de base de données de base. 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. Une connexion TCPS (TLS) est requise lors de l'utilisation de jetons pour l'accès à la base de données.

Note :

Vous ne pouvez pas configurer le chiffrement réseau natif lors de la transmission d'un jeton IAM. Seul le protocole TLS (Transport Layer Security) est pris en charge, et non le chiffrement réseau natif ou le chiffrement réseau natif avec TLS.

Connexions de clients qui utilisent un vérificateur de mot de passe de base de données GIA

Après que vous avez configuré l'autorisation requise pour l'utilisateur GIA, celui-ci peut se connecter à l'aide d'une application client existante, telle que SQL*Plus ou SQLcl, sans configuration supplémentaire.

L'utilisateur GIA entre le nom d'utilisateur et le mot de passe de base de données GIA (et non le mot de passe de la console OCI) à l'aide d'un client de base de données actuellement pris en charge. La seule contrainte est que la version du client de base de données soit Oracle Database version 12.1.0.2 ou ultérieure pour utiliser les mots de passe Oracle Database 12c. Le client de base de données doit pouvoir utiliser le vérificateur de mot de passe 12c. L'utilisation du chiffrement du vérificateur 11g n'est pas prise en charge avec GIA. Aucune configuration de client ou d'outil spéciale n'est nécessaire pour que l'utilisateur GIA puisse se connecter à la base de données.

Le client de base de données peut également demander un jeton directement à partir du service IAM à l'aide du nom d'utilisateur IAM et du mot de passe de base de données IAM. Pour plus d'informations sur la configuration du client pour obtenir un jeton, voir Connexions de client qui utilisent un jeton demandé par un nom d'utilisateur IAM et un mot de passe de base de données.

Connexions de clients utilisant un jeton

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).
  • Nom d'utilisateur GIA et mot de passe de base de données GIA, qui peuvent être utilisés par le client de base de données pour extraire un jeton de base de données GIA directement lorsqu'il est configuré pour ce faire.
  • Jetons de principal d'instance, qui permettent aux instances d'être des acteurs (ou principaux) autorisés à effectuer des actions sur les ressources de service 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).
  • Utilisation d'un nom d'utilisateur IAM et d'un mot de passe de base de données IAM (qui ne peut être demandé que 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 utilisera l'accès au vérificateur de base de données GIA décrit pour les connexions de client qui utilisent des vérificateurs de mot de passe de base de données GIA, sauf si le client de base de données est configuré pour extraire un jeton de base de données de GIA avec le nom d'utilisateur GIA et le mot de passe de base de données GIA. Les instructions de cette rubrique 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.

Les rubriques suivantes expliquent comment :

Configurer une connexion de client pour SQL*Plus utilisant un mot de passe de base de données GIA

Vous pouvez configurer SQL*Plus pour l'utilisation d'un mot de passe de base de données GIA.

En tant qu'utilisateur GIA, connectez-vous à la base de données à l'aide de la syntaxe suivante :

CONNECT user_name@db_connect_string
Enter password: password

Dans cette spécification, user_name est le nom d'utilisateur GIA. La combinaison de domain_name/user_name est limitée à 128 octets.

L'exemple suivant montre comment l'utilisateur GIA peter_fitch peut se connecter à une instance de base de données.

sqlplus /nolog
connect peter_fitch@db_connect_string
Enter password: password

Certains caractères spéciaux nécessitent que les paramètres user_name et password soient encadrés par des guillemets doubles. Par exemple :

"peter_fitch@example.com"@db_connect_string

"IAM database password"

Configurer une connexion de client pour SQL*Plus utilisant un jeton GIA

Effectuez les étapes suivantes pour configurer une connexion de client pour SQL*Plus utilisant un jeton GIA.

  1. Assurez-vous de disposer d'un compte d'utilisateur GIA.
  2. Vérifiez auprès d'un administrateur GIA et de l'administrateur de base de données que vous disposez d'une politique vous permettant d'accéder à la base de données dans le compartiment ou votre location, et que vous êtes mappé à un schéma global de la base de données.
  3. Si votre application ou votre outil ne prend pas en charge l'intégration GIA directe, téléchargez, installez et configurez l'interface de ligne de commande OCI. Pour plus d'informations sur l'installation et la configuration de l'interface de ligne de commande OCI, voir Démarrage rapide.
  4. Configurez une clé d'API dans le cadre de la configuration de l'interface de ligne de commande OCI et sélectionnez les valeurs par défaut.
    1. Configurez l'accès à la clé d'API pour l'utilisateur GIA.
    2. Extrayez db-token. Par exemple :
      • Extraction d'un db-token avec API-key à l'aide de l'interface de ligne de commande OCI :
        oci iam db-token get
      • Extraction de db-token avec un jeton de sécurité (ou de session) :
        oci iam db-token get --auth security_token

        Si le jeton de sécurité a expiré, une fenêtre s'affiche pour que l'utilisateur puisse se reconnecter à OCI. Cela génère le jeton de sécurité pour l'utilisateur. L'interface de ligne de commande OCI utilisera ce jeton actualisé pour obtenir db-token.

      • Extraction de db-token avec un jeton de délégation : Lorsque vous vous connectez à Cloud Shell, le jeton de délégation est généré automatiquement et placé dans le répertoire /etc. Pour obtenir ce jeton, exécutez la commande suivante dans l'interface de ligne de commande OCI :
        oci iam db-token get
      • Extraction d'un jeton d'instance à l'aide de l'interface de ligne de commande OCI :
        oci iam db-token get --auth instance_principal

    Pour plus d'informations, voir Clés et OCID requis.

  5. Cette configuration fonctionne uniquement avec le client Oracle Database 19c. Assurez-vous d'utiliser les dernières mises à jour de version pour ce client.

    Note :

    La version de client Oracle Database 21c offre des fonctions limitées de jeton IAM.
  6. Suivez le processus existant pour télécharger le portefeuille à partir de la base de données, puis suivez les instructions pour le configurer et l'utiliser avec SQL*Plus.
    1. Vérifiez que la mise en correspondance de nom distinctif est activée en recherchant SSL_SERVER_DN_MATCH=ON dans sqlnet.ora.
    2. Configurez le client de base de données pour l'utilisation du jeton GIA en ajoutant TOKEN_AUTH=OCI_TOKEN au fichier sqlnet.ora. Comme vous utiliserez l'emplacement par défaut pour le fichier de jeton de base de données, vous n'avez pas besoin d'inclure l'emplacement du jeton.
    Les valeurs TOKEN_AUTH et TOKEN_LOCATION des chaînes de connexion dans tnsnames.ora ont priorité sur les paramètres de sqlnet.ora pour la connexion. Par exemple, pour la chaîne de connexion, en supposant que le jeton se trouve dans l'emplacement par défaut (~/.oci/db-token pour Linux) :
    (description= 
      (retry_count=20)(retry_delay=3)
      (address=(protocol=tcps)(port=1522)
      (host=example.us-phoenix-1.oraclecloud.com))
      (connect_data=(service_name=aaabbbccc_exampledb_high.example.oraclecloud.com))
      (security=(ssl_server_cert_dn="CN=example.uscom-east-1.oraclecloud.com, 
         OU=Oracle BMCS US, O=Example Corporation, 
         L=Redwood City, ST=California, C=US")
      (TOKEN_AUTH=OCI_TOKEN)))

Une fois la chaîne de connexion mise à jour avec le paramètre TOKEN_AUTH, l'utilisateur GIA peut se connecter à l'instance de base de données en exécutant la commande suivante pour démarrer SQL*Plus. Vous pouvez inclure le descripteur de connexion lui-même ou utiliser le nom du descripteur figurant dans le fichier tnsnames.ora.

connect /@exampledb_high

ou :

connect /@(description= 
  (retry_count=20)(retry_delay=3)
  (address=(protocol=tcps)(port=1522)
  (host=example.us-phoenix-1.oraclecloud.com))
  (connect_data=(service_name=aaabbbccc_exampledb_high.example.oraclecloud.com))
  (security=(ssl_server_cert_dn="CN=example.uscom-east-1.oraclecloud.com, 
     OU=Oracle BMCS US, O=Example Corporation, 
     L=Redwood City, ST=California, C=US")
  (TOKEN_AUTH=OCI_TOKEN)))

Le client de base de données est déjà configuré pour obtenir db-token, car TOKEN_AUTH a déjà été défini, au moyen du fichier sqlnet.ora ou dans une chaîne de connexion. Le client de base de données obtient db-token et le signe à l'aide de la clé privée, puis envoie le jeton à la base de données. Si un nom d'utilisateur GIA et un mot de passe de base de données GIA sont spécifiés au lieu de la barre oblique /, le client de base de données se connecte à l'aide du mot de passe au lieu d'utiliser db-token, sauf si un autre paramètre est spécifié : PASSWORD_AUTH = OCI_TOKEN. Le client de base de données doit ainsi obtenir le jeton à partir du service GIA à l'aide du nom d'utilisateur GIA et du mot de passe de base de données GIA. En plus de définir PASSWORD_AUTH, vous devez également définir OCI_IAM_URL, OCI_TENANCY et, facultativement, OCI_COMPARTMENT et OCI_DATABASE.

Utiliser un principal d'instance pour accéder à une base de données à l'aide de l'authentification GIA

Une fois que l'utilisateur ADMIN a activé le service GIA pour OCI dans la base de données, une application peut accéder à celle-ci au moyen d'un jeton de base de données GIA pour OCI à l'aide d'un principal d'instance.

Pour plus d'informations, voir Accès à l'API Oracle Cloud Infrastructure au moyen de principaux d'instance.

Configurer l'authentification par mandataire

L'authentification par mandataire permet à un utilisateur GIA de mandater un schéma de base de données pour des tâches telles que la maintenance d'une application.

L'authentification par mandataire est généralement utilisée pour authentifier l'utilisateur réel, puis l'autoriser à utiliser un schéma de base de données avec les privilèges et les rôles du schéma pour gérer une application. Les alternatives telles que le partage du mot de passe du schéma d'application sont considérées comme non sécurisées, ne permettant pas de vérifier quel utilisateur réel a effectué une action.

Un cas d'utilisation peut être un environnement dans lequel un utilisateur GIA nommé, administrateur de base de données d'application, peut s'authentifier à l'aide de ses données d'identification, puis mandater un utilisateur de schéma de base de données (par exemple, hrapp). Cette authentification permet à l'administrateur GIA d'utiliser les privilèges et rôles de hrapp en tant qu'utilisateur hrapp pour effectuer la maintenance de l'application, tout en continuant à utiliser ses données d'identification GIA pour l'authentification. Un administrateur de base de données d'application peut se connecter à la base de données, puis mandater un schéma d'application pour gérer ce schéma.

Vous pouvez configurer l'authentification par mandataire pour les méthodes d'authentification par mot de passe et par jeton.

Configuration de l'authentification par mandataire pour l'utilisateur GIA

Pour configurer l'authentification par mandataire pour un utilisateur GIA, celui-ci doit déjà disposer d'un mappage à un schéma global (mappage exclusif ou partagé). Un schéma de base de données distinct pour l'utilisateur GIA à mandater doit également être disponible.

Après avoir vérifié que vous disposez de ce type d'utilisateur, modifiez l'utilisateur de base de données pour autoriser l'utilisateur GIA à l'utiliser comme mandataire.

  1. Connectez-vous à l'instance de base de données en tant qu'utilisateur disposant des privilèges de système ALTER USER.
  2. Accordez à l'utilisateur GIA l'autorisation d'utiliser comme mandataire le compte d'utilisateur de base de données local. Un utilisateur GIA ne peut pas être référencé dans la commande, donc le mandataire doit être créé entre l'utilisateur global de base de données (mappé à l'utilisateur GIA) et l'utilisateur de base de données cible. Dans l'exemple suivant, hrapp est le schéma de base de données à mandater et peterfitch_schema est l'utilisateur global de base de données mappé exclusivement à l'utilisateur peterfitch.
    ALTER USER hrapp GRANT CONNECT THROUGH peterfitch_schema;

À ce stade, l'utilisateur GIA peut se connecter à l'instance de base de données à l'aide du mandataire. Par exemple :

Pour vous connecter à l'aide d'un vérificateur de mot de passe :

CONNECT peterfitch[hrapp]@connect_string
Enter password: password

Pour vous connecter à l'aide d'un jeton :

CONNECT [hrapp]/@connect_string

Validation de l'authentification par mandataire de l'utilisateur GIA

Vous pouvez valider la configuration du mandataire de l'utilisateur GIA pour les méthodes d'authentification par mot de passe et par jeton.

  1. Connectez-vous à l'instance de base de données en tant qu'utilisateur disposant des privilèges de système CREATE USER et ALTER USER.
  2. Connectez-vous à l'utilisateur GIA et exécutez les commandes SHOW USER et SELECT SYS_CONTEXT. Par exemple, supposons que vous vouliez vérifier l'authentification par mandataire de l'utilisateur GIA peterfitch lorsqu'il mandate l'utilisateur de base de données hrapp. Vous devez vous connecter à la base de données à l'aide des différents types de méthode d'authentification présentés ici, mais la sortie des commandes que vous exécutez est la même pour tous les types.
    • Pour l'authentification par mot de passe, supposons que l'utilisateur IAM se trouve dans le domaine par défaut :
      CONNECT peterfitch[hrapp]/password\!@connect_string
      SHOW USER;
      --The output should be USER is "HRAPP"
      SELECT SYS_CONTEXT('USERENV','AUTHENTICATION_METHOD') FROM DUAL;
      --The output should be "PASSWORD_GLOBAL_PROXY"
      SELECT SYS_CONTEXT('USERENV','PROXY_USER') FROM DUAL;
      --The output should be "PETERFITCH_SCHEMA"
      SELECT SYS_CONTEXT('USERENV','CURRENT_USER') FROM DUAL;
      --The output should be "HRAPP"
    • Pour l'authentification par jeton, pour un utilisateur qui se trouve dans un domaine non par défaut, sales_domain :
      CONNECT [hrapp]/@connect_string
      SHOW USER;
      --The output should be USER is "HRAPP "
      SELECT SYS_CONTEXT('USERENV','AUTHENTICATION_METHOD') FROM DUAL;
      --The output should be "TOKEN_GLOBAL_PROXY"
      SELECT SYS_CONTEXT('USERENV','PROXY_USER') FROM DUAL;
      --The output should be "PETERFITCH_SCHEMA"
      SELECT SYS_CONTEXT('USERENV','CURRENT_USER') FROM DUAL;
      --The output should be "HRAPP"

Utiliser un lien de base de données avec les utilisateurs authentifiés par GIA

Vous pouvez utiliser un lien de base de données pour vous connecter d'une instance de base de données à une autre en tant qu'utilisateur GIA pour OCI.

Vous pouvez utiliser un lien de base de données d'utilisateur connecté ou fixe pour vous connecter à une base de données en tant qu'utilisateur GIA pour OCI.

Note :

Le lien de base de données de l'utilisateur courant n'est pas pris en charge pour la connexion à une base de données du service de base de données de base en tant qu'utilisateur IAM OCI.
  • Lien de base de données d'utilisateur connecté : Pour un lien de base de données d'utilisateur connecté, un utilisateur GIA doit être mappé à un schéma dans les bases de données source et cible connectées par un lien de base de données. Vous pouvez utiliser un vérificateur de mot de passe de base de données ou un jeton de base de données GIA pour utiliser un lien de base de données d'utilisateur connecté.

  • Lien de base de données d'utilisateur fixe : Un lien de base de données d'utilisateur fixe peut être créé à l'aide d'un utilisateur de base de données ou GIA. Lors de l'utilisation d'un utilisateur GIA en tant que lien de base de données d'utilisateur fixe, l'utilisateur GIA doit disposer d'un mappage de schéma dans la base de données cible. L'utilisateur GIA d'un lien de base de données ne peut être configuré qu'avec un vérificateur de mot de passe.

Désactiver l'authentification GIA

Vous pouvez désactiver l'accès d'un utilisateur GIA à votre instance de base de données à l'aide de la commande ALTER SYSTEM comme indiqué ci-dessous :

ALTER SYSTEM RESET IDENTITY_PROVIDER_TYPE SCOPE=BOTH;

Si vous voulez également mettre à jour l'accès au service GIA à partir de la ressource, vous devrez peut-être supprimer ou modifier le groupe GIA et les politiques que vous avez configurées pour autoriser l'accès au service GIA à partir de ces ressources.