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

Apprenez-en davantage sur 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 rubriques 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 peut s'agir d'une autre unité d'affaires de votre société, d'un client de votre société, d'une société qui fournit des services à votre société, 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 aux ressources et les partager, 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 mots Define, Endorse et Admit.

Énoncés Endorse, Admit et Define

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'énoncé d'admission se trouve dans la location qui accorde "l'entrée" à la location. L'énoncé 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 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 Define doivent être inclus dans la même entité de politique que l'énoncé Endorse ou Admit. Les énoncés Endorse et Admit fonctionnent ensemble, mais se trouvent dans des politiques distinctes, un dans chaque location. Sans un énoncé correspondant indiquant l'accès, un énoncé Endorse ou Admit particulier n'accorde aucun accès. Vous avez besoin d'une entente des deux locations.

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

Énoncés 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 effectuer toutes les opérations sur toutes les tables NoSQL d'une 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 dans DestinationTenancy uniquement :

Define tenancy DestinationTenancy as ocid1.tenancy.oc1..<destination_tenancy_OCID>
Endorse group NoSQLAdmins to manage nosql-family in tenancy DestinationTenancy

Énoncés de politique de location de destination

L'administrateur de la destination crée des énoncés de politique qui :

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

Permettre à un autre utilisateur de gérer les tables NoSQL

Lorsque vous activez votre commande pour Oracle NoSQL Database Cloud Service, vous (le premier utilisateur) faites partie du groupe Administrateurs par défaut. Être dans le groupe Administrateurs vous donne des privilèges d'administration complètement dans Oracle Cloud Infrastructure pour vous permettre de 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 voulez, vous pouvez accorder à un autre utilisateur les privilèges de création et de gestion de 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 accorde à ce groupe l'autorisation manage nosql-tables sur un compartiment spécifique ou sur la location (tous les compartiments 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 le service Oracle NoSQL Database Cloud Service, voir Configuration d'utilisateurs, de groupes et de politiques au moyen du service de gestion des identités et des accès.

Énoncés de politique types pour gérer les tables

Découvrez les énoncés de politique courants que vous pouvez utiliser pour autoriser l'accès aux tables du service Oracle NoSQL Database Cloud.

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 individuels du service Oracle NoSQL Database Cloud Service.

Exemple - Pour permettre aux administrateurs de groupe de gérer entièrement n'importe quelle 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 au groupe Analytics 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, mais pas de les modifier.

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'

Rubriques connexes