L'accès inter-locations à une instance DBaaS Oracle Cloud Infrastructure (OCI) est similaire à un scénario de location unique, à ceci près 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 cet accès aux ressources de base de données inter-locations.

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 Accès inter-location à une instance OCI DBaaS

Le processus inter-locations est le suivant :

1. La stratégie est requise dans les deux locations pour approuver et admettre l'accès inter-location.
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 est 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.

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-locations.

• Configuration de la location d'utilisateur source
  Deux stratégies sont requises pour autoriser l'accès inter-location dans la location d'utilisateur.
• Configuration de 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 d'utilisateur, ainsi que pour autoriser ses propres bases de données à interroger les informations de groupe dans la location d'utilisateur
• Exemples de stratégie pour l'accès inter-location
  Les exemples incluent l'utilisation d'une clause WHERE pour affiner la configuration inter-location, ainsi que d'autres méthodes d'exécution de ce type de configuration.

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.

• Pour utiliser l'instruction CREATE USER afin d'effectuer la mise en correspondance, procédez comme suit :
  Les exemples suivants présentent un mappage de schéma exclusif et partagé avec des principaux et 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 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 afin d'effectuer la mise en correspondance, procédez comme suit :
  Les exemples suivants illustrent le mappage des rôles globaux avec des groupes dans des 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';

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 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).

Vous devez ajouter le paramètre --scope à la commande d'interface de ligne de commande Oracle Cloud Infrastructure (OCI) afin d'obtenir un db-token pour une demande inter-locations. 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 d'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 à la section Optional Parameters.

Vous pouvez la définir sur l'ensemble de la location ou la définir sur 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 inter-location, 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 à la documentation relative à la définition des paramètres pour obtenir les jetons d'accès MSEI OAuth2.