Utilisation des balises pour gérer l'accès
Cette rubrique explique comment utiliser les balises dans une stratégie pour déterminer la portée de l'accès en fonction des balises appliquées au demandeur ou à la cible d'un appel d'autorisation.
A propos du contrôle d'accès basé sur les balises
A l'aide de conditions et d'un ensemble de variables de balise, vous pouvez écrire une stratégie pour déterminer la portée de l'accès en fonction des balises appliquées à une ressource. L'accès peut être contrôlé en fonction d'une balise qui existe sur la ressource demandeuse (groupe, groupe dynamique ou compartiment) ou sur la cible de la demande (ressource ou compartiment). Le contrôle d'accès basé sur les balises offre une plus grande flexibilité à vos stratégies en vous permettant de définir des stratégies d'accès avec des balises qui couvrent des compartiments, des groupes et des ressources.
Si votre organisation choisit de créer des stratégies qui utilisent des balises pour gérer l'accès, veillez à disposer de contrôles appropriés afin d'encadrer les personnes habilitées à appliquer des balises. Par ailleurs, une fois les stratégies en place, n'oubliez pas que l'application de balises à un groupe, à un utilisateur ou à une ressource peut potentiellement accorder l'accès aux ressources.
Avant de créer une stratégie indiquant une balise sur une cible ou un demandeur, vérifiez que vous connaissez les éléments suivants :
- Tous les demandeurs potentiels (utilisateurs, groupes, groupes dynamiques) qui comportent la balise
- Toutes les ressources qui comportent la balise
Avant d'appliquer une balise à une ressource, vérifiez que vous avez connaissance des stratégies en place qui incluent la balise et qui peuvent avoir une incidence sur les personnes ayant accès à la ressource.
Gestion de l'accès à l'aide de balises appliquées à la ressource demandeuse
Vous pouvez contrôler l'accès en fonction de la valeur d'une balise appliquée aux éléments suivants :
- Un groupe (d'utilisateurs) demandant l'accès
- Un groupe dynamique (d'instances) demandant l'accès
- Un compartiment dans lequel réside une ressource dans un groupe dynamique
En utilisant des balises dans vos instructions de stratégie pour déterminer la portée de l'accès, vous pouvez définir l'accès de plusieurs groupes au moyen d'une seule instruction de stratégie. Vous pouvez également accorder et révoquer l'accès pour les groupes en appliquant ou en enlevant des balises, sans modifier les stratégies d'origine.
La syntaxe de base de chaque variable est indiquée dans le tableau suivant. La syntaxe est la même pour un groupe et pour un groupe dynamique, mais chacune est présentée sur une ligne différente. Pour obtenir davantage d'exemples d'utilisation, reportez-vous à Opérateurs pris en charge.
| Balise appliquée au demandeur | Syntaxe de variable | Description |
|---|---|---|
|
groupe |
request.principal.group.tag.{tagNamespace}.{tagKeyDefinition}= '<value>'
Exemple de stratégie pour un groupe d'utilisateurs :
Tout utilisateur qui appartient à un groupe balisé avec Operations.Project='Prod' peut gérer des instances dans le compartiment HR. |
Les balises appliquées aux groupes auxquels l'utilisateur appartient sont évaluées pour une recherche de correspondance. |
|
groupe dynamique |
request.principal.group.tag.{tagNamespace}.{tagKeyDefinition}= '<value>'
Exemple de stratégie pour un groupe dynamique :
Les instances membres du groupe dynamique InstancesA et également membres d'un groupe dynamique balisé avec Operations.Project='Prod' peuvent gérer des instances dans le compartiment HR. |
Les balises appliquées aux groupes dynamiques auxquels l'instance appartient sont évaluées pour une recherche de correspondance. |
|
compartiment |
request.principal.compartment.tag.{tagNamespace}.{tagKeyDefinition}= '<value>'
Exemple de stratégie :
Les instances membres du groupe dynamique InstancesA et résidant également dans un compartiment balisé avec Operations.Project='Prod' peuvent gérer des instances dans la location. |
Les balises appliquées au compartiment auquel appartient la ressource demandeuse sont évaluées. |
Etant donné que les utilisateurs résident dans le compartiment racine de votre location, les balises doivent être appliquées au compartiment racine pour que ces instructions de stratégie puissent fonctionner.
Gestion de l'accès à l'aide de balises appliquées à la ressource cible
Vous pouvez contrôler l'accès en fonction de la valeur d'une balise appliquée aux éléments suivants :
- Une ressource
- Un compartiment dans lequel réside la ressource cible
La syntaxe de base de ces variables est indiquée dans le tableau suivant. Pour obtenir davantage d'exemples d'utilisation, reportez-vous à Opérateurs pris en charge.
| Balise appliquée à la cible | Syntaxe de variable | Description |
|---|---|---|
|
ressource |
target.resource.tag.{tagNamespace}.{tagKeyDefinition}='<value>'
Exemple de stratégie :
|
La balise appliquée à la ressource cible de la demande est évaluée. Il existe des restrictions concernant les droits d'accès pouvant être accordés dans ce type de stratégie. Pour plus d'informations, reportez-vous aux sections ci-après dans cette rubrique. |
|
compartiment |
target.resource.compartment.tag.{tagNamespace}.{tagKeyDefinition}='<value>'
Exemple de stratégie :
|
La balise appliquée au compartiment cible de la demande est évaluée. Pour plus d'informations sur l'octroi d'accès dans les compartiments imbriqués, reportez-vous à Hiérarchies de compartiments. |
Octroi distinct des droits d'accès permettant de répertorier une ressource
Les stratégies qui déterminent la portée de l'accès en fonction de la balise appliquée à la ressource cible ne peuvent pas autoriser les droits d'accès qui vous permettent de renvoyer une liste de ressources. Par conséquent, les droits d'accès permettant de répertorier une ressource doivent être accordés via une instruction de stratégie supplémentaire. Cela signifie que si vous avez défini une stratégie comme suit :
allow group GroupA to manage all-resources in compartment Operations where target.resource.tag.Operations.Project= 'Prod'
GroupA ne peut pas répertorier les ressources qu'il est autorisé à gérer par ailleurs. Les membres de GroupA ne peuvent pas utiliser la console pour interagir avec ces ressources. Les utilisateurs doivent connaître l'OCID de la ressource qu'ils tentent de gérer, ce qui rend également le recours au kit SDK et à la CLI fastidieux.
Pour permettre à GroupA de répertorier ces ressources, vous devez ajouter une autre instruction de stratégie, comme suit :
allow group GroupA to inspect all-resources in compartment Operations
Cette approche améliore la stratégie basée sur les balises car elle permet aux utilisateurs d'employer la console plus facilement (en leur permettant de visualiser la ressource à gérer), mais elle limite tout de même les droits d'accès à l'inspection uniquement. Les membres de GroupA ne peuvent effectuer aucune action sur ces ressources, sauf en cas de balisage approprié. Lorsque vous utilisez le contrôle d'accès basé sur les balises, gardez à l'esprit que le gain de flexibilité nécessite cette expansion potentielle d'accès.
L'autre approche que vous pouvez adopter pour éviter cette limitation est de baliser les compartiments qui contiennent les ressources à lesquelles vous souhaitez accorder l'accès. Exemple de stratégie :
allow group GroupA to manage all-resources in tenancy where target.resource.compartment.tag.Operations.Project= 'Prod'Cette stratégie permet aux membres de GroupA de gérer toutes les ressources de la location qui se trouvent dans des compartiments balisés avec Operations.Project='Prod'.
Impossibilité d'octroyer des droits de création via des stratégies exigeant une balise sur la ressource cible
Lorsque vous écrivez une stratégie pour déterminer la portée de l'accès en fonction de la valeur d'une balise sur la ressource, n'oubliez pas qu'elle ne peut pas octroyer de droits de création. Une demande de création d'instance échouerait car la ressource cible n'a pas encore été créée, et ne comporte donc pas la balise appropriée pour évaluation. Ainsi, une stratégie semblable à la suivante :
allow group GroupA to manage instances in compartment Operations where target.resource.tag.Operations.Project='Prod'
permet aux membres de GroupA d'utiliser et de supprimer des instances qui sont balisées avec Operations.Project='Prod', mais pas de créer des instances.
Opérateurs pris en charge
La stratégie qui utilise ces variables de balise peut inclure les opérateurs et les types de correspondance suivants :
| Opérateur | Type | Exemple | Description |
|---|---|---|---|
| = | Chaîne | request.principal.group.tag.MyTagNamespace.MyTag='sample'
|
Renvoie la valeur True si l'un des groupes auxquels appartient le demandeur est balisé avec la valeur correspondante "sample" pour MyTagNamespace.MyTag. (La valeur ne distingue pas les majuscules des minuscules.) |
| Modèle | request.principal.group.tag.MyTagNamespace.MyTag=/*sample/
|
Renvoie la valeur True si l'une des valeurs de MyTagNamespace.MyTag se termine par "sample". (Correspondance de modèle simple sans distinction majuscules/minuscules). | |
| Variable de stratégie | request.principal.group.tag.mytagnamespace.mytag = target.resource.tag.mytagnamespace.mytag |
Renvoie la valeur True lorsque la ressource indiquée mytagnamespace.mytag possède une valeur qui correspond à la cible spécifiée mytagnamespace.tag. | |
| != | Chaîne | request.principal.group.tag.MyTagNamespace.MyTag !='sample'
|
Renvoie la valeur True si aucune des valeurs de chaîne de la variable de stratégie n'est égale à "sample". (Comparaison de chaînes simple sans distinction majuscules/minuscules). |
| Modèle | request.principal.group.tag.MyTagNamespace.MyTag !=/*sample/
|
Renvoie la valeur True si aucune des valeurs de MyTagNamespace.MyTag se termine par "sample". (Correspondance de modèle simple sans distinction majuscules/minuscules). | |
| Variable de stratégie | request.principal.group.tag.mytagnamespace.mytag != target.resource.tag.mytagnamespace.mytag |
Renvoie la valeur True si aucune portion n'est un sous-ensemble de l'autre. |
In/Not In
| Opérateur | Type | Exemple | Description |
|---|---|---|---|
| in | Chaîne | request.principal.group.tag.MyTagNamespace.MyTag in ('sample', 'sample1')
|
La clause renvoie la valeur True si l'une des valeurs de MyTagNamespace.MyTag pour tout groupe du principal demandeur en cours est égale à "sample" ou à "sample1". |
| Modèle | request.principal.group.tag.MyTagNamespace.MyTag in (/*sample/, /sample1*/)
|
La clause renvoie la valeur True si l'une des valeurs de MyTagNamespace.MyTag pour tout groupe du principal demandeur en cours se termine par "sample" ou commence par "sample1". | |
| Variable de stratégie | request.principal.group.tag.MyTagNamespace.MyTag in (target.resource.tag.mytagnamespace.mytag, 'sample') |
La clause renvoie la valeur True si l'une des conditions suivantes est remplie : 1 request.principal.group.tag.MyTagNamespace.MyTag ou target.resource.tag.mytagnamespace.mytag est un sous-ensemble de l'autre. 2. L'une des valeurs de chaîne de request.principal.group.tag.MyTagNamespace.MyTag est égale à "sample". |
|
| not in | Chaîne | request.principal.group.tag.MyTagNamespace.MyTag not in ('sample', 'sample1')
|
La clause renvoie la valeur True si aucune des valeurs de MyTagNamespace.MyTag pour tout groupe du principal demandeur en cours est égale à "sample" ou à "sample1". |
| Modèle | request.principal.group.tag.MyTagNamespace.MyTag not in (/*sample/, /sample1*/)
|
La clause renvoie la valeur True si aucune des valeurs de MyTagNamespace.MyTag pour tout groupe du principal demandeur en cours se termine par "sample" ou commence par "sample1". | |
| Variable de stratégie | request.principal.group.tag.MyTagNamespace.MyTag not in (target.resource.tag.mytagnamespace.mytag, 'sample')
|
La clause renvoie la valeur True si toutes les conditions suivantes sont remplies : 1. Ni request.principal.group.tag.MyTagNamespace.MyTag ni target.resource.tag.mytagnamespace.mytag n'est un sous-ensemble de l'autre. 2. Aucune des valeurs de chaîne de request.principal.group.tag.MyTagNamespace.MyTag n'est égale à "sample". |
Prise en charge des caractères génériques
Vous pouvez utiliser le caractère * pour mettre en correspondance toutes les occurrences de {tagNamespace}.{tagKeyDefinition}, quelle que soit la valeur. Dans la stratégie, vous pouvez placer le caractère * entre apostrophes '*' ou entre barres obliques /*/. Par exemple :
allow group GroupA to use all-resources in compartment HR where target.resource.tag.HR.Project= '*'
Dans cet exemple, GroupA peut utiliser toutes les ressources du compartiment HR balisées avec l'espace de noms de balise et la clé de balise HR.Project avec n'importe quelle valeur.
Limites relatives aux caractères dans les espaces de noms de balise et les définitions de clé de balise utilisés dans les variables de stratégie
Les espaces de noms de balise et les définitions de clé de balise prennent en charge un plus grand ensemble de caractères que les variables de stratégie. Par conséquent, pour utiliser des espaces de noms de balise et des définitions de clé de balise dans des variables, assurez-vous qu'ils comprennent uniquement les caractères pris en charge également par les variables de stratégie. Les caractères pris en charge sont les suivants :
a-z, A-Z, 0-9, _, @, -, :
Si vos espaces de noms de balise ou clés de balise contiennent des caractères autres que ceux-ci, vous ne pouvez pas les utiliser dans les variables de stratégie. Vous ne pouvez pas renommer les espaces de noms de balise et les clés de balise. Par conséquent, vous devrez en créer d'autres.
Remarques concernant la casse
Lorsque vous utilisez des balises dans des stratégies, sachez que les valeurs de balise ne respectent pas la casse. Par exemple :
request.principal.group.tag.MyTagNamespace.MyTag='sample'
est identique à
request.principal.group.tag.MyTagNamespace.MyTag='Sample'
Hiérarchies de compartiments
Lorsque vous écrivez une condition pour autoriser l'accès en fonction de la balise appliquée à un compartiment cible, n'oubliez pas que cette stratégie autorise également l'accès à tous les compartiments imbriqués dans le compartiment balisé. Tous les sous-compartiments du compartiment balisé sont des ressources de ce dernier, c'est pourquoi la stratégie y accorde l'accès.
Par exemple, dans ce scénario :
la stratégie :
allow group GroupA to use all-resources in tenancy where target.resource.compartment.Operations.Project='ProjectA'permet à GroupA d'utiliser toutes les ressources dans CompartmentA, CompartmentA1 et CompartmentA1.1, même si la balise est appliquée uniquement au CompartmentA.
Services pris en charge
Tous les services Oracle Cloud Infrastructure prennent en charge les variables de stratégie request.principal.compartment, request.principal.group et target.resource.compartment.tag.
Tous les services ne prennent pas en charge la variable de stratégie target.resource.tag. Le tableau suivant répertorie les services pris en charge. Si le service n'est pas présent dans le tableau, cela signifie qu'il n'est pas pris en charge actuellement.
Certains services sont soumis à des limites. Reportez-vous au lien approprié dans le tableau.
| Services pris en charge | Informations supplémentaires |
|---|---|
| Passerelle d'API | Reportez-vous à Limites relatives au service API Gateway. |
| Big Data Service | Reportez-vous à Limites relatives au service Big Data. |
| Blockchain Platform | Prise en charge totale, aucune limite. |
| Block Volume | Reportez-vous à Limites relatives au service Block Volume. |
| Certificates | Prise en charge totale, aucune limite. |
| Calculer | Reportez-vous à Limites relatives au service Compute. |
| Compute Management | Reportez-vous à Limites relatives à Compute Management. |
| Content Management | Reportez-vous à Limites relatives à Content Management. |
| Catalogue de données | Reportez-vous à Limites relatives au service Data Catalog. |
| Data Flow | Prise en charge totale, aucune limite. |
| Data Science | Reportez-vous à Limites relatives au service Data Science. |
| Database | Reportez-vous à Limites relatives au service Database. |
| Digital Assistant | Reportez-vous à Limites relatives à Digital Assistant. |
| DNS | Reportez-vous à Limites relatives aux DNS publics. |
| Email Delivery | Prise en charge totale, aucune limite. |
| FastConnect | Prise en charge totale, aucune limite. |
| Fonctions | Prise en charge totale, aucune limite. |
| Health Checks | Prise en charge totale, aucune limite. |
| IAM | Les ressources prises en charge sont : users, groups, policies, dynamic-groups, network-sources et identity-providers |
| Load Balancer | Reportez-vous à Limites relatives au service Load Balancing. |
| MySQL HeatWave | Prise en charge totale, aucune limite. |
| Networking | Reportez-vous à Limites relatives au service Networking. |
| NoSQL Database Cloud | Reportez-vous à Limites relatives au service Networking. |
| Notifications | Prise en charge totale, aucune limite. |
| Object Storage | Reportez-vous à Limites relatives au service Object Storage. |
| Service Quotas | Prise en charge totale, aucune limite. |
| Espace de noms Tagging | Reportez-vous à Limites relatives à un espace de noms Tagging. |
| Vault | Cryptage non pris en charge. |
| WAF | Reportez-vous à Limites relatives à WAF. |
Limites et stratégies supplémentaires nécessaires pour des scénarios Target.Resource.Tag spécifiques
Pour certains services, tous les types de ressource ou droits d'accès ne sont pas pris en charge. Lorsqu'un droit d'accès n'est pas pris en charge, cela signifie que même si la ressource est balisée et que le droit est inclus dans le verbe octroyant l'accès, ce droit n'est pas permis et l'autorisation échoue pour l'opération régie par celui-ci. Par exemple, la ressource de service Block Volume volume-backups ne prend pas en charge le contrôle d'accès basé sur les balises pour le droit d'accès VOLUME_BACKUP_COPY. Par conséquent, cette stratégie :
allow group TestGroup to manage volume-backups in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'n'autorise pas les membres du groupe TestGroup à effectuer l'opération CopyVolumeBackup. Pour accorder ce droit d'accès à TestGroup, vous devez ajouter une autre instruction de stratégie qui le couvre.
En outre, certains scénarios opérationnels exigent une autorisation pour accéder à plusieurs ressources. Lors de la détermination de la portée de l'accès aux balises appliquées à la ressource cible, vous devez inclure une stratégie distincte pour chaque ressource impliquée dans l'opération. De plus, en raison des limites sur l'établissement de la liste des ressources et d'autres droits d'accès propres au service, des stratégies supplémentaires (portée non définie par une balise) sont requises.
Limites relatives au service API Gateway
En plus de la stratégie de contrôle d'accès basé sur les balises attendue pour les ressources API Gateway, vous aurez besoin d'une stratégie octroyant des droits de gestion pour api-workrequests.
Voici un exemple de stratégie avec les droits d'accès supplémentaires :
allow group TestGroup to manage api-workrequests in compartment Compartment1Limites relatives au service Big Data
En plus de la stratégie de contrôle d'accès basé sur les balises attendue pour les ressources Big Data Service, vous aurez besoin d'une stratégie octroyant des droits de gestion pour cluster-work-requests.
Voici un exemple de stratégie avec les droits d'accès supplémentaires :
allow group TestGroup to manage cluster-work-requests in compartment Compartment1Limites relatives au service Block Volume
| Service | Type de ressource avec limites | Droits d'accès non pris en charge avec la variable de stratégie target.resource.tag |
|---|---|---|
| Block Volume | backup-policy-assignments
|
BACKUP_POLICY_ASSIGNMENT_DELETE |
volume-backups
|
VOLUME_BACKUP_COPY |
Scénarios nécessitant une stratégie supplémentaire :
Attachement d'un volume de blocs à une instance de calcul :
Pour attacher un volume de blocs à une instance de calcul, en plus de la stratégie de contrôle d'accès basé sur les balises permettant d'autoriser le verbe use sur les volumes et les instances, vous aurez besoin de droits d'accès supplémentaires.
Par exemple :
allow group TestGroup to use volumes in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to use instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'Ces deux stratégies permettent aux membres de TestGroup d'utiliser des volumes et des instances de Compartment1, lorsque les ressources possèdent la balise appropriée. Pour permettre aux membres d'attacher un volume de blocs à une instance, vous aurez également besoin de stratégies autorisant les droits d'accès indiqués dans les instructions suivantes :
allow group TestGroup to read instances in compartment Compartment1
allow group TestGroup to manage volume-attachments in compartment Compartment1 where any {request.permission='VOLUME_ATTACHMENT_CREATE', request.permission='VOLUME_ATTACHMENT_DELETE'}Limites relatives au service Compute
| Service | Type de ressource | Droits d'accès non pris en charge avec la variable de stratégie target.resource.tag |
|---|---|---|
| Compute | instance-console-connection
|
INSTANCE_CONSOLE_CONNECTION_DELETE |
instances
|
INSTANCE_POWER_ACTIONS |
Scénarios nécessitant une stratégie supplémentaire :
Attachement d'une instance de calcul à un sous-réseau :
Afin de gérer l'attachement d'un sous-réseau d'une instance de calcul, en plus de la stratégie de contrôle d'accès basé sur les balises attendue pour instances et subnets présentée ici :
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to manage instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'vous aurez besoin de droits d'accès supplémentaires sur vnics :
allow group TestGroup to use vnics in compartment Compartment1 where ANY{request.permission='VNIC_ATTACH', request.permission='VNIC_CREATE'}Suppression d'une carte d'interface réseau virtuelle d'une instance de calcul :
Afin de supprimer une carte d'interface réseau virtuelle d'une instance de calcul, en plus de la stratégie de contrôle d'accès basé sur les balises attendue pour instances et subnets présentée ici :
allow group TestGroup to manage instances in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'vous aurez besoin d'une stratégie vous octroyant des droits d'accès sur vnics :
allow group TestGroup to use vnics in compartment Compartment1 where ANY {request.permission='VNIC_DELETE', request.permission='VNIC_DETACH'}Limites relatives à Compute Management
| Service | Type de ressource | Droits d'accès non pris en charge avec la variable de stratégie target.resource.tag | Remarques |
|---|---|---|---|
| Compute Management | instance-pools
|
Tous les droits d'accès | Le type de ressource instance-pools n'est pas pris en charge. |
auto-scaling-configurations
|
AUTO_SCALING_CONFIGURATION_UPDATE | . |
Limites de Content Management
En plus de la stratégie de contrôle d'accès basé sur les balises attendue pour les ressources de gestion de contenu, vous aurez besoin d'une stratégie autorisant les droits de gestion pour oce-work-requests.
Voici un exemple de stratégie avec les droits d'accès supplémentaires :
allow group TestGroup to manage oce-requests in compartment Compartment1Limites relatives au service Database
| Service | Type de ressource | Droits d'accès non pris en charge avec la variable de stratégie target.resource.tag |
|---|---|---|
| Database | all
|
DATABASE_DELETE |
Mise à jour de balises pour l'infrastructure Exadata :
Non prise en charge actuellement avec les stratégies de contrôle d'accès basé sur les balises.
Scénarios nécessitant une stratégie supplémentaire :
Suppression d'un système de base de données :
Afin de supprimer ou de mettre à jour un système de base de données, en plus de la stratégie de contrôle d'accès basé sur les balises attendue pour db-systems présentée ici :
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'vous aurez besoin d'une stratégie vous octroyant des droits d'accès pour db-backups, db-homes, vnics, subnets et databases. Voici un exemple de stratégie avec les droits d'accès supplémentaires :
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_DELETE', request.permission='DB_BACKUP_INSPECT'}
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permission='DB_HOME_DELETE'
allow group TestGroup to manage vnics in compartment Compartment1 where ANY {request.permission='VNIC_DELETE', request.permission='VNIC_DETACH'}
allow group TestGroup to manage subnets in compartment Compartment1 where request.permission='SUBNET_DETACH'
allow group TestGroup to manage databases in compartment compartment1Déplacement d'un système de base de données vers un autre compartiment :
Afin de déplacer un système de base de données vers un autre compartiment, en plus de la stratégie de contrôle d'accès basé sur les balises attendue pour db-systems présentée ici :
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'vous aurez besoin d'une stratégie vous octroyant des droits d'accès pour databases, db-homes et db-backups. Voici un exemple de stratégie avec les droits d'accès supplémentaires :
allow group TestGroup to use databases in compartment Compartment1 where request.permission='DATABASE_UPDATE'
allow group TestGroup to manage db-backups in compartment Compartment1 where request.permission='DB_BACKUP_INSPECT'
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permission='DB_HOME_UPDATE'Suppression d'une base de données pour un système de base de données Exadata :
Afin de supprimer une ressource de base de données pour un système de base de données Exadata, vous aurez besoin de la stratégie de contrôle d'accès basé sur les balises attendue pour db-systems et databases présentée ici :
allow group TestGroup to manage db-systems in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Vous aurez également besoin de droits d'accès pour db-homes et db-backups. Voici un exemple de stratégie avec les droits d'accès supplémentaires :
allow group TestGroup to manage db-homes in compartment Compartment1 where request.permision='DB_HOME_UPDATE'
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_DELETE', request.permission='DB_BACKUP_INSPECT'}Suppression d'une base de données :
La suppression d'une base de données pour un système de base de données de machine virtuelle ou Bare Metal n'est pas prise en charge via des stratégies basées sur les balises sur la ressource cible.
Création d'une sauvegarde de base de données :
Afin de créer une sauvegarde de base de données, vous aurez besoin de la stratégie de contrôle d'accès basé sur les balises attendue pour databases :
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Vous aurez également besoin de droits d'accès pour db-backups. Voici un exemple de stratégie avec les droits d'accès supplémentaires :
allow group TestGroup to manage db-backups in compartment Compartment1 where request.permission='DB_BACKUP_CREATE'Restauration d'une base de données :
Afin de restaurer une sauvegarde de base de données, vous aurez besoin de la stratégie de contrôle d'accès basé sur les balises attendue pour databases :
allow group TestGroup to manage databases in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Vous aurez également besoin de droits d'accès pour backups, sur le modèle suivant :
allow group TestGroup to manage db-backups in compartment Compartment1 where ANY {request.permission='DB_BACKUP_INSPECT', request.permission='DB_BACKUP_CONTENT_READ'}Création d'associations Data Guard :
La création d'une association Data Guard n'est pas prise en charge via des stratégies basées sur les balises sur la ressource cible.
Limites relatives au service Data Catalog
En plus de la stratégie de contrôle d'accès basé sur les balises attendue pour les ressources Data Catalog, vous aurez besoin des stratégies supplémentaires suivantes pour data-catalog-family :
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'GetWorkRequest'
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'ListWorkRequestErrors'
allow group resource_managers to read data-catalog-family in tenancy where request.operation = 'listworkrequestlogs'Limites relatives au service Data Science
En plus de la stratégie de contrôle d'accès basé sur les balises attendue pour les ressources Data Science, vous aurez besoin d'une stratégie octroyant des droits de gestion pour data-science-work-requests.
Voici un exemple de stratégie avec les droits d'accès supplémentaires :
allow group TestGroup to manage data-science-work-requests in compartment Compartment1Limites relatives à Digital Assistant
| Service | Type de ressource | Droits d'accès non pris en charge avec la variable de stratégie target.resource.tag |
|---|---|---|
| Digital Assistant | oda-design
|
Tous les droits d'accès |
oda-insights
|
Tous les droits d'accès |
En plus de la stratégie de contrôle d'accès basé sur les balises attendue pour les ressources Oracle Digital Assistant, vous aurez besoin des stratégies supplémentaires suivantes pour oda-instances :
allow group TestGroup to inspect oda-instances in compartment Compartment1
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'GetWorkRequest'
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'ListWorkRequestErrors'
allow group TestGroup to read oda-instances in compartment Compartment1 request.operation = 'listworkrequestlogs'Limites relatives au service Load Balancing
Scénarios nécessitant une stratégie supplémentaire :
Mise à jour d'un équilibreur de charge :
Afin d'effectuer une mise à jour des équilibreurs de charge, en plus de la stratégie de contrôle d'accès basé sur les balises attendue pour load-balancers :
allow group TestGroup to manage load-balancers in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'vous aurez besoin d'une stratégie qui autorise l'opération d'API GetWorkRequest. Voici un exemple de stratégie avec le droit d'accès supplémentaire :
allow group TestGroup to read load-balancers in compartment Compartment1 where request.operation = 'GetWorkRequest'
network-security-groupSuppression d'un équilibreur de charge :
Afin de supprimer un équilibreur de charge, en plus de la stratégie de contrôle d'accès basée sur les balises attendue pour load-balancers, subnets et network-security-group :
allow group TestGroup to manage load-balancers in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to use subnets in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'
allow group TestGroup to use network-security-group in compartment Compartment1 where target.resource.tag.TagNS.TagKey= 'test'Vous aurez besoin des droits d'accès supplémentaires suivants pour vnics :
allow group TestGroup to use vnics in compartment Compartment1 where ANY {request.permission = 'VNIC_DETACH', request.permission = 'VNIC_DELETE', request.permission='VNIC_DISASSOCIATE_NETWORK_SECURITY_GROUP'}Limites relatives au service Networking
| Service | Type de ressource | Droits d'accès non pris en charge avec la variable de stratégie target.resource.tag | Remarques |
|---|---|---|---|
| Networking | private-ips
|
PRIVATE_IP_UPDATE PRIVATE_IP_DELETE VNIC_UNASSIGN SUBNET_DETACH |
|
route-tables
|
UPDATE (INTERNET_GATEWAY_DETACH) | La suppression d'une règle de routage n'est pas prise en charge. | |
vnics
|
VNIC_UPDATE VNIC_DELETE |
Attachement d'une passerelle de service ou d'une passerelle NAT à une table de routage :
L'attachement d'une passerelle de service ou d'une passerelle NAT à une table de routage n'est pas pris en charge via des stratégies basées sur les balises sur la ressource cible.
Scénarios nécessitant une stratégie supplémentaire :
Attachement d'une passerelle de routage dynamique à un réseau cloud virtuel :
Afin d'attacher une passerelle de routage dynamique à un réseau cloud virtuel, en plus de la stratégie de contrôle d'accès basé sur les balises attendue suivante pour virtual-network-family etvcns :
allow group TestGroup to use virtual-network-family in compartment Compartment1 where target.resource.tag.TagNS.TagKey = 'test'
vous aurez besoin d'une stratégie vous octroyant des droits d'accès manage pour drgs. Voici un exemple de stratégie avec les droits d'accès supplémentaires :
allow group TestGroup to manage drgs in compartment Compartment1
Limites relatives au service NoSQL Database Cloud
Les ressources prises en charge sont : nosql-tables, nosql-rows et nosql-indexes.
En plus de la stratégie de contrôle d'accès basé sur les balises attendue pour les ressources NoSQL Database Cloud, vous aurez besoin des stratégies supplémentaires suivantes :
allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequests'allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequestErrors'allow group TestGroup to read nosql-tables in compartment Compartment1 where request.operation='ListWorkRequestLogs'Les stratégies précédentes sont requises pour parcourir les ressources NoSQL Database Cloud de la console.
Limites relatives au service Object Storage
| Service | Type de ressource | Droits d'accès non pris en charge avec la variable de stratégie target.resource.tag | Remarques |
|---|---|---|---|
| Object Storage | objects
|
Tous les droits d'accès relatifs à l'accès à objects |
Les objets ne peuvent pas être balisés. |
Vous pouvez gérer l'accès aux objets à l'aide des balises du bucket auquel les objets appartiennent. Utilisez la variable de stratégie
target.bucket.tag. Reportez-vous à Autoriser les utilisateurs à écrire des objets dans des buckets Object Storage.Limites relatives aux DNS publics
En plus de la stratégie de contrôle d'accès basé sur les balises attendue pour les ressources dns, vous aurez besoin d'une stratégie vous octroyant des droits d'accès manage pour dns-records. Voici un exemple de stratégie avec les droits d'accès supplémentaires :
allow group TestGroup to manage dns-records in compartment Compartment1Limites relatives à un espace de noms Tagging
La stratégie qui accorde à un utilisateur un accès à un espace de noms de balise en fonction d'une balise sur l'espace de noms ne lui permet pas de créer ou de supprimer des définitions de clé de balise dans cet espace de noms de balise.
Par exemple, la stratégie :
allow group TestGroup to manage tag-namespaces in compartment Compartment1 where target.resource.tag.TagNS.TagKey='test'ne permet pas aux utilisateurs du groupe TestGroup de créer ou de supprimer des définitions de clé de balise dans les espaces de noms de balise balisés avec TagNS.TagKey='test'.
Limites relatives à WAF
En plus de la stratégie de contrôle d'accès basé sur les balises attendue pour les ressources WAF, vous aurez besoin d'une stratégie vous octroyant des droits de gestion pour waas-work-request. Voici un exemple de stratégie avec les droits d'accès supplémentaires :
allow group TestGroup to manage waas-work-request in compartment Compartment1Exemples illustrés
Exemple d'utilisation de balises appliquées à un groupe
L'exemple suivant montre comment utiliser les balises appliquées aux groupes d'utilisateurs pour gérer l'accès aux ressources dans un compartiment.
Supposons que vous disposez de trois compartiments : ProjectA, ProjectB et ProjectC.
Pour chaque compartiment, un groupe d'administrateurs est configuré : A-Admins, B-Admins et C-Admins.
Chaque groupe d'administrateurs dispose d'un accès complet sur son compartiment via les stratégies suivantes :
allow group A-Admins to manage all-resources in compartment ProjectAallow group B-Admins to manage all-resources in compartment ProjectBallow group C-Admins to manage all-resources in compartment ProjectC
Votre organisation a configuré l'espace de noms et la clé de balise suivants pour baliser chaque groupe selon son rôle :
- EmployeeGroup.Role
Pour cette balise, 'Admin', 'Developer' et 'Test-Engineer' sont des valeurs possibles.
Tous vos groupes d'administrateurs sont balisés avec EmployeeGroup.Role='Admin'
Vous voulez désormais configurer un compartiment Test que les membres des trois projets vont partager. Vous voulez accorder un accès Admin aux trois groupes d'administrateurs existants. Pour ce faire, vous pouvez écrire la stratégie suivante :
allow any-user to manage all-resources in compartment Test where request.principal.group.tag.EmployeeGroup.Role='Admin'
Avec cette stratégie, tous les groupes d'administrateurs existants comportant la balise auront accès au compartiment Test. De plus, tous les groupes, nouveaux ou existants, que vous baliserez avec EmployeeGroup.Role='Admin' à l'avenir auront accès au compartiment Test sans devoir mettre à jour les instructions de stratégie.
Exemple d'utilisation de balises appliquées à une ressource cible
Dans cet exemple, chaque compartiment de projet de votre organisation contient deux compartiments enfant : Test et Prod. Vous voulez accorder à vos ingénieurs de test un accès aux compartiments de test sur les trois projets. Pour ce faire, vous créez une balise :
ResourceGroup.Role='Test'
Vous l'appliquez ensuite aux compartiments Test dans chacun de vos compartiments de projet.
Vous pouvez ensuite utiliser une stratégie comme suit :
allow group Testers to use all-resources in tenancy where target.resource.compartment.tag.ResourceGroup.Role='Test'
pour permettre au groupe Testers d'accéder aux ressources des trois compartiments de test.