Documentation Oracle Cloud Infrastructure

Accès à une location croisée 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 DBaaS d'une autre location si les stratégies des deux locations le permettent.

Rubrique parent : Utilisation de l'authentification Identity and Access Management (IAM) avec Autonomous Database

A propos de l'accès inter-location pour les utilisateurs IAM aux instances DBaaS

L'accès inter-location à 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 mises en correspondance et les demandes de jeton, et qu'une stratégie est requise dans les deux locations pour autoriser l'accès à cette ressource de base de données inter-location.

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

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

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

Le processus de location croisée est le suivant :

  1. La stratégie est requise dans les deux locations pour approuver et admettre l'accès entre les locations.
  2. Le principal IAM (utilisateur ou application) demande un jeton de base de données pour une ressource inter-location.
  3. db-token est renvoyé et utilisé pour accéder à la base de données dans une autre location.
  4. La base de données effectue une requête de groupe inter-locations pour les groupes de l'utilisateur et met en correspondance le principal avec le schéma global et les rôles globaux facultatifs.

Vous devez abonner la location utilisateur aux régions dans lesquelles se trouvent 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 utilisateur à ces régions. Il ne s'agit pas de la région d'origine, mais uniquement des régions abonnées supplémentaires dans la location utilisateur.

Configurer des stratégies

Vous devez créer des stratégies à la fois dans la location utilisateur et dans la location de ressource de base de données pour autoriser l'accès à la base de données inter-location.

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

Configurer la location de l'utilisateur source

Deux stratégies sont requises pour autoriser l'accès inter-location dans la location utilisateur.

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

Rubrique parent : Configuration des stratégies

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

La location de base de données aura besoin de stratégies de mise en correspondance pour permettre l'accès aux utilisateurs à partir de la location utilisateur, ainsi que pour autoriser ses propres bases de données à interroger les informations de groupe dans la location utilisateur

  1. Dans la console OCI, sélectionnez Identité et sécurité.
  2. Sous Identité, sélectionnez Stratégies.
  3. Cliquez sur Créer une stratégie et, dans le générateur de stratégies, sélectionnez Afficher l'éditeur manuel.
  4. Utilisez DEFINE pour faciliter le dépannage et la lecture des stratégies.
    DEFINE tenancy user_tenancy as ocid1.tenancy.OCID
DEFINE group xt_db_users as ocid1.group.defg
  5. Utilisez ADMIT pour créer une stratégie d'admission dans la location afin qu'elle corresponde à la stratégie d'approbation de la location utilisateur.
    La stratégie d'admission doit correspondre à la stratégie ENDORSE dans la location utilisateur afin qu'elle puisse 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 stratégie d'approbation, qui correspondra à la stratégie d'admission créée dans la location User.
    La stratégie d'approbation 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 stratégies requises, Oracle recommande d'utiliser des contraintes plus fortes en plus de l'utilisation de any-user ou au lieu de l'utiliser. L'option any-user permet à tout principal ou ressource d'interroger des groupes d'utilisateurs dans user_tenancy. Dans l'idéal, limitez cette limite pour autoriser uniquement les ressources de base de données (principaux de ressources) à effectuer les requêtes de groupe. Pour ce faire, vous pouvez ajouter une clause WHERE aux stratégies ou ajouter un groupe dynamique qui le limite aux membres du groupe dynamique. La définition de tous les moyens possibles pour spécifier des groupes et des stratégies dynamiques est en dehors de la portée de cette rubrique. Vous trouverez plus d'informations à partir des sources suivantes :

Rubrique parent : Configuration des stratégies

Exemples de stratégie pour l'accès inter-location

Par exemple, vous pouvez utiliser une clause WHERE pour affiner la configuration inter-locations, ainsi que 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 la requête de groupe inter-location : 

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

Cette stratégie d'admission permet à tout service Base Database (type de ressource : dbsystem) dans db_tenancy d'interroger les informations de groupe d'un utilisateur à partir de la location utilisateur. Les noms des types de ressource figurent dans le tableau ci-dessous.

Une méthode similaire peut être effectuée en plaçant le même type de ressource dans un groupe dynamique :

dynamic group: db_principals
any {resource.type = 'dbsystem', resource.type = 'vmcluster', resource.type = 'cloudvmcluster'}

Le groupe dynamique de l'exemple précédent inclut des instances de base de données pour Oracle Base Database Service (dbsystem), Oracle Exadata Cloud@Customer (vmcluster) et Oracle Exadata Database Service (cloudvmcluster).

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-base de données d'effectuer la requête de groupe inter-location. Le tableau suivant fournit un mapping des différents types de ressource avec le nom de plate-forme DBaaS :

DBaaS Nom de plate-forme Nom du type de ressource

ADB-S

autonomousdatabase

ADB-D (OPC)

cloudautonomousvmcluster*

DBS de base

dbsystem

ExaCS

cloudvmcluster

ExaCC

vmcluster

* Les anciennes instances ADBD peuvent toujours utiliser le type de ressource autonomousexainfrastructure.

Rubrique parent : Configuration des stratégies

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

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

Utilisez un signe deux-points complet pour séparer l'OCID de location lorsque vous utilisez les instructions CREATE USER et CREATE ROLE dans SQL*Plus.
  • Pour utiliser l'instruction CREATE USER pour effectuer le mapping, procédez comme suit :
    Les exemples suivants montrent un mappage de schéma exclusif et partagé avec des principaux et des groupes dans les domaines par défaut et autres. 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'instruction CREATE ROLE pour effectuer le mapping, procédez comme suit :
    Les exemples suivants illustrent le mappage global des rôles avec des groupes dans les domaines par défaut et autres. 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';

Configurer des clients de base de données pour l'accès inter-location

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

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 d'OCI IAM. Consultez la documentation propre au client pour connaître les valeurs de paramètre spécifiques (JDBC-thin, ODP.NET-core, managed).

Demande de jetons inter-location à 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 inter-location. Si la base de données à laquelle vous accédez se trouve dans une région différente de la région d'origine de la location 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.

Pour plus d'informations sur l'utilisation des paramètres facultatifs de la commande oci get, reportez-vous à Paramètres facultatifs.

Vous pouvez en définir la portée pour l'ensemble de la location ou la définir sur un compartiment ou une base de données dans la location. Lors de la définition de la portée pour un compartiment ou une base de données inter-locations, vous n'avez pas besoin d'ajouter également les informations de location car les OCID de compartiment et de base de données sont uniques dans OCI.

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