Gestion de l'accès aux tables Oracle NoSQL Database Cloud Service

Découvrez l'écriture de politiques et la consultation d'énoncés de politique types que vous pouvez utiliser pour autoriser l'accès aux tables Oracle NoSQL Database Cloud Service.

Cet article contient les informations suivantes :

Accès aux tables NoSQL entre locations

Cette rubrique décrit comment écrire des politiques qui permettent à votre location d'accéder aux tables NoSQL dans d'autres locations.

Pour en connaître davantage sur les politiques, voir Introduction aux politiques.

Politiques interlocations

Votre organisation peut partager des ressources avec une autre organisation ayant sa propre location. Il se peut qu'il s'agisse d'une autre unité d'affaires de votre société, d'un client de celle-ci, d'une société qui fournit des services à celle-ci, etc. Dans ces cas, vous devez disposer de politiques interlocations en plus des politiques d'utilisateur et de service requises décrites précédemment.

Pour accéder et partager des ressources, les administrateurs des deux locations doivent créer des énoncés de politique spéciaux indiquant explicitement les ressources accessibles et pouvant être partagées. Ces énoncés spéciaux utilisent les verbes Définir, Endorer et Admettre.

Relevés d'approbation, d'admission et de définition

Voici un aperçu des verbes spéciaux utilisés dans les énoncés interlocations :

Endorse : Indique le jeu général de fonctions qu'un groupe de votre propre location peut exécuter dans d'autres locations. L'énoncé Endorse se trouve toujours dans la location dont le groupe d'utilisateurs franchit les limites de l'autre location pour en utiliser les ressources. Dans les exemples, cette location est la location source.

Admit : Indique le type de fonction dans votre propre location que vous voulez accorder à un groupe de l'autre location. L'instruction Admit se trouve dans la location qui accorde " l'entrée " à la location. L'instruction Admit identifie le groupe d'utilisateurs qui demande l'accès aux ressources de la location source et qui est identifié par un énoncé Endorse correspondant. Dans les exemples, cette location est la location de destination.

Define : affecte un alias à un OCID de location pour les énoncés de politique Endorse et Admit. Un énoncé Define est également requis dans la location de destination pour affecter un alias à l'OCID du groupe IAM source pour les énoncés Admit.

Les énoncés Définir doivent être inclus dans la même entité de politique que l'énoncé Endorse ou Admit. Les instructions Endorse et Admit fonctionnent ensemble, mais se trouvent dans des politiques distinctes, un dans chaque location. Sans une instruction correspondante qui spécifie l'accès, une instruction Endorse ou Admit particulière n'octroie aucun accès. Vous avez besoin d'un accord des deux locations.

Note :

En plus des énoncés de politique, vous devez également vous inscrire à une région pour partager des ressources entre les régions.

États de politique de location source

L'administrateur source crée des énoncés de politique qui endossent un groupe IAM source autorisé à gérer les ressources dans la location de destination.

Note :

Les politiques interlocation peuvent également être écrites avec d'autres sujets de politique. Pour plus de détails sur les sujets de politique, voir Syntaxe d'une politique dans la documentation sur Oracle Cloud Infrastructure.
Voici un exemple d'énoncé de politique général qui endosse le groupe IAM NoSQLAdmins pour tout faire avec toutes les tables NoSQL de n'importe quelle location :
Endorse group NoSQLAdmins to manage nosql-family in any-tenancy
Pour écrire une politique qui réduit la portée de l'accès de la location, l'administrateur de la destination doit fournir l'OCID de la location de destination. Voici un exemple d'énoncés de politique qui endossent le groupe IAM NoSQLAdmins pour gérer les tables NoSQL uniquement dans DestinationTenancy :
Define tenancy DestinationTenancy as ocid1.tenancy.oc1..<destination_tenancy_OCID>
Endorse group NoSQLAdmins to manage nosql-family in tenancy DestinationTenancy

États de politique de location de destination

L'administrateur de la destination crée des énoncés de politique qui :
  • Définit la location source et le groupe IAM autorisés à accéder aux ressources de votre location. L'administrateur de la source doit fournir ces informations.
  • Permet à ces sources définies d'accéder aux tables NoSQL auxquelles vous voulez autoriser l'accès dans votre location.
Voici un exemple d'énoncés de politique qui endossent le groupe IAM NoSQLAdmins dans la location source pour effectuer des opérations sur toutes les tables NoSQL de votre location :
Define tenancy SourceTenancy as ocid1.tenancy.oc1..<source_tenancy_OCID>
Define group NoSQLAdmins as ocid1.group.oc1..<group_OCID>
Admit group NoSQLAdmins of tenancy SourceTenancy to manage nosql-family in tenancy
Voici un exemple d'énoncés de politique qui endossent le groupe IAM NoSQLAdmins dans la location source pour gérer les tables NoSQL uniquement dans le compartiment Développer :
Define tenancy SourceTenancy as ocid1.tenancy.oc1..<source_tenancy_OCID>
Define group NoSQLAdmins as ocid1.group.oc1..<group_OCID>
Admit group NoSQLAdmins of tenancy SourceTenancy to manage nosql-family in compartment Develop

Obtention de l'autorisation de gestion des tables NoSQL par un autre utilisateur

Lorsque vous activez votre commande pour Oracle NoSQL Database Cloud Service, vous (le premier utilisateur) faites partie du groupe Administrateurs par défaut. Le fait de faire partie du groupe Administrateurs vous donne des privilèges d'administration complète dans Oracle Cloud Infrastructure afin que vous puissiez gérer les tables Oracle NoSQL Database Cloud Service et bien plus encore. Il n'est pas nécessaire de déléguer cette responsabilité, mais si vous le souhaitez, vous pouvez accorder à quelqu'un d'autre des privilèges pour créer et gérer des tables Oracle NoSQL Database Cloud Service au moyen de l'autorisation manage nosql-tables.

Dans Oracle Cloud Infrastructure, vous utilisez des politiques de sécurité IAM pour accorder des autorisations. Tout d'abord, vous devez ajouter l'utilisateur à un groupe, puis créer une politique de sécurité qui octroie à ce groupe l'autorisation manage nosql-tables sur un compartiment spécifique ou sur la location (tout compartiment de la location). Par exemple, vous pouvez créer un énoncé de politique semblable à l'un des suivants :

allow group MyAdminGroup to manage nosql-tables in tenancy
allow group MyAdminGroup to manage nosql-tables in compartment MyOracleNoSQL

Pour savoir comment créer des énoncés de politique de sécurité spécifiquement pour Oracle NoSQL Database Cloud Service, voir Configuration d'utilisateurs, de groupes et de politiques à l'aide de la gestion des identités et des accès.

Éléments de politique types pour gérer les tables

Voici des énoncés de politique types que vous pouvez utiliser pour autoriser l'accès aux tables Oracle NoSQL Database Cloud Service.

Lorsque vous créez une politique pour votre location, vous autorisez les utilisateurs à accéder à tous les compartiments au moyen de l'héritage de politique. Vous pouvez également restreindre l'accès à des tables ou des compartiments Oracle NoSQL Database Cloud Service individuels.

Exemple - Pour permettre aux administrateurs de groupe de gérer entièrement une table Oracle NoSQL Database Cloud Service

allow group Administrators to manage nosql-tables in tenancy
allow group Administrators to manage nosql-rows in tenancy
allow group Administrators to manage nosql-indexes in tenancy

Exemple - Pour permettre au groupe Admins d'effectuer toute opération sur les tables NoSQL du compartiment Dev, utilisez le type de ressource family.

allow group Admins to manage nosql-family in compartment Dev

Exemple - Pour permettre aux analyses de groupe d'effectuer des opérations en lecture seule sur les tables NoSQL du compartiment Dev

allow group Analytics to read nosql-rows in compartment Dev

Exemple - Pour permettre seulement à Joe du groupe Developer de créer, obtenir et supprimer des index de tables NoSQL dans le compartiment Dev

allow group Developer to manage nosql-indexes in compartment Dev 
where request.user.id = '<OCID of Joe>'

Exemple - Pour autoriser le groupe Admins à créer, supprimer et déplacer des tables NoSQL dans le compartiment Dev.

allow group Admins to manage nosql-tables in compartment Dev 
where any {request.permission = 'NOSQL_TABLE_CREATE', 
           request.permission = 'NOSQL_TABLE_DROP', 
           request.permission = 'NOSQL_TABLE_MOVE'}

Exemple - Pour autoriser le groupe Developer à lire, mettre à jour et supprimer des rangées de la table "customer" dans le compartiment Dev, mais pas d'autres tables.

allow group Developer to manage nosql-rows in compartment Dev 
where target.nosql-table.name = 'customer'