Fonctions avancées liées aux politiques

Dans le cadre d'un énoncé de politique, vous pouvez spécifier une ou plusieurs conditions à remplir pour que l'accès soit accordé. Pour un exemple simple, voir Permettre aux administrateurs de groupes de gérer l'appartenance à des groupes.

Chaque condition comprend une ou plusieurs variables prédéfinies pour lesquelles vous spécifiez des valeurs dans l'énoncé de politique. Plus tard, lorsque quelqu'un demande l'accès à la ressource en question, si la condition dans la politique est satisfaite, elle est évaluée à Vrai et la demande est autorisée. Si la condition n'est pas satisfaite, elle est évaluée à Faux et la demande n'est pas autorisée.

Il existe deux types de variable : celles qui sont pertinentes pour la demande elle-même, et celles qui sont pertinentes pour la ressource visée par la demande, également appelée cible. Un préfixe est apposé avant le nom de la variable en conséquence, soit request, soit target, suivi d'un point. Par exemple, il existe une variable de demande nommée request.operation pour représenter l'opération d'API demandée. Cette variable permet d'écrire un énoncé de politique étendu et d'ajouter une condition sur cette opération d'API spécifique. Pour un exemple, voir Permettre aux utilisateurs d'écrire des objets dans les seaux de stockage d'objets.

Les autorisations sont les unités atomiques de permission qui contrôlent la capacité d'un utilisateur à exécuter des opérations sur les ressources. Oracle définit toutes les autorisations dans le langage de politique. Lorsque vous écrivez une politique permettant à un groupe d'accéder à un verbe et à un type de ressource particuliers, vous donnez à ce groupe l'accès à une ou à plusieurs autorisations prédéfinies. Les verbes visent à simplifier le processus d'octroi de plusieurs autorisations connexes couvrant un large éventail d'accès ou un scénario opérationnel particulier. Les sections suivantes offrent davantage de détails et d'exemples.

Dans un énoncé de politique, vous pouvez utiliser des conditions combinées à des autorisations ou à des opérations d'API pour réduire la portée de l'accès accordé par un verbe particulier.

Par exemple, supposons que vous vouliez que le groupe XYZ puisse lister, obtenir, créer ou mettre à jour des groupes (c'est-à-dire, modifier leur description), mais ne puisse pas les supprimer. Pour lister, obtenir, créer et mettre à jour des groupes, la politique doit contenir le verbe et le type de ressource manage groups. Selon le tableau de la section Informations détaillées sur les combinaisons Verbes + Type de ressource, les autorisations couvertes sont les suivantes :

• GROUP_INSPECT
• GROUP_UPDATE
• GROUP_CREATE
• GROUP_DELETE

Pour limiter l'accès aux autorisations souhaitées uniquement, vous pouvez ajouter une condition qui énonce explicitement les autorisations que vous voulez accorder :

Allow group XYZ to manage groups in tenancy

 where any {request.permission='GROUP_INSPECT',
            request.permission='GROUP_CREATE',
            request.permission='GROUP_UPDATE'}

Une autre solution pourrait être une politique qui accorde toutes les autorisations sauf GROUP_DELETE :

Allow group XYZ to manage groups in tenancy where request.permission != 'GROUP_DELETE'

Avec cette approche, gardez toutefois à l'esprit que toutes les nouvelles autorisations que le service pourrait ajouter à l'avenir seraient automatiquement accordées au groupe XYZ. Seule l'autorisation GROUP_DELETE serait omise.

Il est aussi possible d'écrire une condition basée sur les opérations d'API spécifiques. Notez que, selon le tableau figurant sous Autorisations requises pour chaque opération d'API, ListGroups et GetGroup nécessitent uniquement l'autorisation GROUP_INSPECT. Voici la politique :

Allow group XYZ to manage groups in tenancy

 where any {request.operation='ListGroups',  
            request.operation='GetGroup',
            request.operation='CreateGroup',
            request.operation='UpdateGroup'}

Il peut être avantageux d'utiliser des autorisations au lieu d'opérations API dans des conditions. Si une nouvelle opération d'API nécessitant une des autorisations énumérées dans la politique basée sur les autorisations ci-dessus est ajoutée plus tard, cette politique contrôlera déjà l'accès du groupe XYZ à cette nouvelle opération d'API.

Notez qu'il est possible de préciser davantage la portée de l'accès d'un utilisateur à une autorisation en indiquant également une condition basée sur une opération d'API. Par exemple, vous pouvez permettre à un utilisateur d'accéder à GROUP_INSPECT, puis uniquement à ListGroups.

Allow group XYZ to manage groups in tenancy

 where all {request.permission='GROUP_INSPECT',  
            request.operation='ListGroups'}

Vous ne pouvez définir la portée de l'accès que pour un jeu d'adresses IP autorisées. Par exemple, vous pouvez écrire une politique pour autoriser uniquement les demandes provenant d'un intervalle d'adresses IP publiques particulier à accéder à un seau de stockage d'objets spécifique, ou vous pouvez autoriser uniquement des sous-réseaux spécifiques d'un VCN particulier à effectuer des demandes sur une passerelle de service. Pour obtenir la liste des services pris en charge, voir Prise en charge des sources de réseau.

Pour restreindre l'accès à un jeu d'adresses IP, procédez de la façon suivante :

1. Créez un objet de source de réseau qui spécifie les adresses IP autorisées. Voir Aperçu des sources de réseau pour plus de détails.
2. Écrivez une politique utilisant l'objet de source de réseau dans une condition.

Utilisez la variable suivante dans votre politique :

request.networkSource.name='<network_source_name>'

Par exemple :

allow group GroupA to manage object-family in tenancy where request.networkSource.name='corpnet'

Vous pouvez utiliser des variables basées sur le temps dans vos politiques pour limiter l'accès accordé dans la politique à certaines périodes seulement. Cette fonction vous permet de limiter les actions sur les ressources à des moments particuliers. Par exemple, vous pouvez créer une politique qui autorise l'accès uniquement à une date spécifiée. Ce type de politique est utile si votre société embauche des sous-traitants et vous voulez vous assurer que l'accès n'est pas autorisé au-delà de la date de fin du contrat. Vous pouvez également autoriser l'accès aux ressources uniquement pendant les heures de bureau (par exemple, du lundi au vendredi de 9h00 à 17h00). Cette restriction peut réduire le risque qu'une personne malveillante effectue des modifications à un moment où elles sont plus susceptibles de passer inaperçues.

Les variables que vous pouvez utiliser pour définir la portée de l'accès en fonction du temps sont les suivantes :

L'utilisation de ces variables est décrite plus en détail dans les sections suivantes.

Allow group Contractors to manage instance-family in tenancy where request.utc-timestamp before '2022-01-01T00:00Z'

Allow group SummerInterns to manage instance-family in tenancy where ANY {request.utc-timestamp.month-of-year in ('6', '7', '8')}

Allow group ComplianceAuditors to read all-resources in tenancy where request.utc-timestamp.day-of-month = '1'

Allow group WorkWeek to manage instance-family where ANY {request.utc-timestamp.day-of-week in ('monday', 'tuesday', 'wednesday', 'thursday', 'friday')}

Allow group DayShift to manage instance-family where request.utc-timestamp.time-of-day between '17:00:00Z' and '01:00:00Z'

Allow group NightShift to manage instance-family where request.utc-timestamp.time-of-day between '01:00:00Z' and '17:00:00Z'