Documentation sur Oracle Cloud Infrastructure

Accès à une interconnexion de base de données à l'aide d'une intégration IAM

Les utilisateurs et les groupes d'une location peuvent accéder aux instances de base de données du service d'intelligence artificielle autonome d'une autre location si les politiques des deux locations le permettent.

Rubrique parent : Utiliser l'authentification du service de gestion des identités et des accès (IAM) avec la base de données d'intelligence artificielle autonome

À propos de l'accès interlocation pour les utilisateurs IAM aux instances DBaaS

L'accès interlocation à une instance Oracle Cloud Infrastructure (OCI) DBaaS est similaire à un scénario de location unique, sauf que les informations de location sont requises pour les mappages et les demandes de jeton et qu'une politique est requise dans les deux locations pour permettre l'accès aux ressources de base de données interlocation.

La figure suivante illustre le processus d'accès interlocation à une instance OCI DBaaS.

Figure 3-1 Accès interlocation à une instance OCI DBaaS

Description de la figure 3-1 :
Description de "Figure 3-1 - Accès interlocation à une instance OCI DBaaS"

Le processus interlocation est le suivant :

  1. La politique est requise dans les deux locations pour endosser et admettre l'accès interlocation.
  2. Le principal IAM (utilisateur ou application) demande un jeton de base de données pour une ressource interlocation.
  3. db-token est retourné et est utilisé pour accéder à la base de données dans une autre location
  4. La base de données effectuera une interrogation de groupe interlocation pour les groupes de l'utilisateur et mappera le principal au schéma global et les rôles globaux facultatifs.

Vous devez abonner la location d'utilisateur aux mêmes régions que les bases de données. Par exemple, si les bases de données de la location de base de données se trouvent dans les régions PHX et IAD, vous devez abonner la location d'utilisateur à ces régions. Il ne s'agit pas de la région principale, mais uniquement des régions abonnées supplémentaires dans la location de l'utilisateur.

Configuration de politiques

Vous devez créer des politiques à la fois dans la location d'utilisateur et dans la location de ressource de base de données pour autoriser l'accès à la base de données interlocation.

Rubrique parent : Accès à une interlocation de base de données à l'aide d'une intégration IAM

Configuration de la location de l'utilisateur source

Deux politiques sont requises pour permettre l'accès interlocation dans la location utilisateur.

La première politique consiste à autoriser un groupe de location d'utilisateur à accéder à une base de données d'une autre location. La deuxième politique permet à une base de données de la location de base de données d'interroger les informations de groupe dans la location d'utilisateur.
  1. Dans la console OCI, sélectionnez Identité et sécurité.
  2. Sous Identité, sélectionnez Politiques.
  3. Cliquez sur Créer une politique et, dans le générateur de politiques, sélectionnez Afficher l'éditeur manuel.
  4. Utilisez l'énoncé DEFINE pour faciliter la lecture des politiques réelles.
    Exemple :
    DEFINE tenancy database_tenancy as ocid1.tenancy.OCID
  5. Endossez le groupe de location domainA/xt_db_users pour utiliser database_connections dans la location database_tenancy.
    Cela permet aux utilisateurs du groupe xt_db_users dans domainA d'accéder à n'importe quelle base de données de la location database_tenancy.
    ENDORSE group domainA/xt_db_users to use database-connections in tenancy database_tenancy
  6. Utilisez l'énoncé ADMIT pour créer une politique d'admission afin d'autoriser toute base de données de la location de base de données à interroger les informations de groupe pour des utilisateurs IAM spécifiques de la location d'utilisateur.
    ADMIT any-user of tenancy database_tenancy to {GROUP_MEMBERSHIP_INSPECT, AUTHENTICATION_INSPECT} in tenancy

Rubrique parent : Configuration de politiques

Configuration de la location de la ressource de base de données cible

La location de base de données aura besoin de politiques de mise en correspondance pour permettre l'accès aux utilisateurs à partir de la location d'utilisateur et pour permettre à ses propres bases de données d'interroger les informations de groupe dans la location d'utilisateur

  1. Dans la console OCI, sélectionnez Identité et sécurité.
  2. Sous Identité, sélectionnez Politiques.
  3. Cliquez sur Créer une politique et, dans le générateur de politiques, sélectionnez Afficher l'éditeur manuel.
  4. Utilisez DEFINE pour faciliter le dépannage et la lecture des politiques.
    DEFINE tenancy user_tenancy as ocid1.tenancy.OCID
DEFINE group xt_db_users as ocid1.group.defg
  5. Utilisez ADMIT pour créer une politique d'admission dans la location afin qu'elle corresponde à la politique Endorse de la location utilisateur.
    La politique d'admission doit correspondre à la politique ENDORSE dans la location d'utilisateur afin de permettre aux utilisateurs de user_tenancy d'accéder aux bases de données de cette location.
    ADMIT group xt_db_users of tenancy user_tenancy to use database-connections in tenancy
  6. Créez une politique Endorse qui correspondra à la politique Admit créée dans la location de l'utilisateur.
    La politique Endorse permet aux bases de données de la location de base de données d'interroger les informations de groupe à partir de user_tenancy.
    ENDORSE any-user to {GROUP_MEMBERSHIP_INSPECT, AUTHENTICATION_INSPECT} in tenancy user_tenancy
Bien que l'utilisation de any-user facilite la compréhension des politiques requises, Oracle recommande d'utiliser des contraintes plus fortes en plus ou au lieu d'utiliser any-user. L'option any-user permettra à tout principal ou ressource d'interroger des groupes d'utilisateurs dans user_tenancy. Dans l'idéal, vous devriez limiter cette opération à autoriser uniquement les ressources de base de données (principaux de ressource) à effectuer les interrogations de groupe. Pour ce faire, vous pouvez ajouter une clause WHERE aux politiques ou ajouter un groupe dynamique qui la limite aux membres du groupe dynamique. La définition de tous les moyens possibles de spécifier des groupes et des politiques dynamiques n'est pas incluse dans cette rubrique. Vous trouverez plus d'informations à partir de ces sources :

Rubrique parent : Configuration de politiques

Exemples de politiques pour l'accès interlocation

Par exemple, utilisez une clause WHERE pour affiner la configuration interlocation et d'autres méthodes pour effectuer ce type de configuration.

Vous pouvez ajouter une clause WHERE pour limiter les ressources de base de données autorisées à effectuer l'interrogation de groupe interlocation : 

ADMIT any-user of tenancy db_tenancy to {GROUP_MEMBERSHIP_INSPECT, AUTHENTICATION_INSPECT} in tenancy where request.principal.type = 'dbsystem'

Cette politique d'admission permet à tout service de base de données de base (type de ressource : dbsystem) dans db_tenancy d'interroger les informations de groupe d'un utilisateur à partir de la location de l'utilisateur. Les noms de type de ressource se trouvent dans le tableau ci-dessous.

Une méthode similaire pour créer une politique consiste à ajouter le type de ressource pour Autonomous Database à un groupe dynamique :

dynamic group: db_principals any {resource.type = ‘autonomousdatabase’}

Cet exemple utilise un groupe dynamique au lieu de any-user : 

ADMIT dynamic group db_principals of tenancy db_tenancy to {GROUP_MEMBERSHIP_INSPECT, AUTHENTICATION_INSPECT} in tenancy

Vous pouvez également ajouter tous les principaux de ressource dans un compartiment à l'aide de resource.compartment.id. Toutefois, cela peut également permettre à d'autres principaux de ressource non de base de données d'effectuer l'interrogation de groupe interlocation.

Rubrique parent : Configuration de politiques

Mappage des schémas et des rôles de base de données avec des utilisateurs et des groupes dans une autre location

Lorsque vous effectuez ce type de mappage, vous devez ajouter l'OCID de la location aux informations de mappage afin que la base de données sache qu'il s'agit d'un accès interlocation.

Utilisez un deux-points complet pour séparer l'OCID de la location lorsque vous utilisez les énoncés CREATE USER et CREATE ROLE dans SQL*Plus.
  • Pour utiliser l'énoncé CREATE USER pour effectuer le mappage :
    Les exemples suivants montrent le mappage de schéma exclusif et partagé avec les principaux et les groupes dans les domaines par défaut et non par défaut. Lorsque vous utilisez des domaines par défaut, vous n'avez pas besoin d'inclure de nom de domaine.
    CREATE USER schema1 IDENTIFIED GLOBALLY 
AS 'IAM_PRINCIPAL_NAME=ocid1.tenancy.OCID:example_domain/peter.fitch@oracle.com';

CREATE USER schema2 IDENTIFIED GLOBALLY 
AS 'IAM_PRINCIPAL_NAME=ocid1.tenancy.OCID:peter.fitch@oracle.com';

CREATE USER qa_db_user_group IDENTIFIED GLOBALLY 
AS 'IAM_GROUP_NAME=ocid1.tenancy.OCID:example_domain/xt_db_users';

CREATE USER qa_sales_user_group IDENTIFIED GLOBALLY 
AS 'IAM_GROUP_NAME=ocid1.tenancy.OCID:sales_users';

CREATE USER xt_ip_user IDENTIFIED GLOBALLY 
AS 'IAM_PRINCIPAL_OCID=ocid1.instance.region1.sea.OCID';
GRANT CREATE SESSION TO xt_ip_user;

CREATE USER xt_iam_dg IDENTIFIED GLOBALLY 
AS 'IAM_GROUP_NAME=ocid1.tenancy.region1.OCID:sales_principals';
GRANT CREATE SESSION TO xt_iam_dg;
  • Pour utiliser l'énoncé CREATE ROLE pour effectuer le mappage :
    Les exemples suivants montrent le mappage global des rôles avec des groupes dans les domaines par défaut et non par défaut. Lorsque vous utilisez des domaines par défaut, vous n'avez pas besoin d'inclure de nom de domaine. 
    CREATE ROLE globalrole1 IDENTIFIED GLOBALLY 
AS 'IAM_GROUP_NAME=ocid1.tenancy.abcdef:example_domain/xt_db_users';

CREATE ROLE globalrole2 IDENTIFIED GLOBALLY 
AS 'IAM_GROUP_NAME=ocid1.tenancy.abcdef:sales_users';

Configuration des clients de base de données pour l'accès interlocation

Vous pouvez configurer directement certains clients de base de données.

La location de base de données doit être identifiée dans la chaîne de connexion ou dans sqlnet.ora si le client est configuré pour obtenir directement le jeton d'accès à partir de l'OCI IAM. Consultez la documentation propre au client pour connaître les valeurs de paramètre spécifiques (JDBC-thin, ODP.NET-core, géré).

Demande de jetons interlocation à l'aide de l'interface de ligne de commande OCI

Vous devez ajouter le paramètre --scope à la commande d'interface de ligne de commande Oracle Cloud Infrastructure (OCI) pour obtenir une valeur db-token pour une demande interlocation. Si la base de données à laquelle vous accédez se trouve dans une région différente de la région principale de la location de l'utilisateur, la région doit également être ajoutée à la commande de l'interface de ligne de commande OCI à l'aide du paramètre --region.

Voir Paramètres facultatifs pour plus de détails sur l'utilisation des paramètres facultatifs de la commande oci get.

Vous pouvez l'étendre à l'ensemble de la location ou à un compartiment ou à une base de données de la location. Lors de la définition de la portée pour un compartiment ou une base de données interlocation, vous n'avez pas besoin d'ajouter les informations de location, car les OCID du compartiment et de la base de données sont uniques dans OCI.

Certains clients peuvent demander les jetons directement auprès de MSEI. Reportez-vous à la documentation sur la définition des paramètres pour obtenir les jetons d'accès MSEI OAuth2.