Fonctionnalités de stratégie avancées

Dans le cadre d'une instruction de stratégie, vous pouvez spécifier des conditions qui doivent être remplies pour que l'accès soit accordé.

Chaque condition se compose d'au moins une variable prédéfinie pour laquelle vous indiquez des valeurs dans l'instruction de stratégie. Par la suite, lorsqu'une personne demande l'accès à la ressource en question, si la condition de la stratégie est remplie, elle renvoie la valeur True et la demande est autorisée. Si la condition n'est pas remplie, elle renvoie la valeur False 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 portant sur la ressource faisant l'objet d'une action dans la demande, également connue sous le nom de cible. Le préfixe request ou target est ajouté au nom de la variable en conséquence, suivi d'un point. Par exemple, il existe une variable de demande appelée request.operation pour représenter l'opération d'API demandée. Cette variable vous permet d'écrire une instruction de stratégie générale, mais d'ajouter une condition basée sur l'opération d'API spécifique. Pour obtenir un exemple, reportez-vous à Autoriser les utilisateurs à écrire des objets dans des buckets Object Storage.

Les droits d'accès sont des unités d'autorisation atomiques qui contrôlent la capacité d'un utilisateur à effectuer des opérations sur des ressources. Oracle définit tous les droits d'accès dans le langage de stratégie. Lorsque vous écrivez une stratégie donnant à un groupe l'accès à un verbe et à un type de ressource particuliers, vous lui donnez en fait accès à des droits d'accès prédéfinis. L'objectif des verbes est de simplifier le processus d'octroi de plusieurs droits d'accès associés qui couvrent un large ensemble d'accès ou un scénario opérationnel spécifique. Les sections suivantes donnent des exemples et plus de détails.

Dans une instruction de stratégie, vous pouvez utiliser des conditions en association avec des droits d'accès ou des opérations d'API pour réduire la portée des accès octroyés par un verbe particulier.

Par exemple, supposons que vous souhaitez que le groupe XYZ puisse répertorier, obtenir, créer ou mettre à jour des groupes (c'est-à-dire modifier leur description) sans avoir le droit de les supprimer. Pour répertorier, obtenir, créer et mettre à jour des groupes, vous avez besoin d'une stratégie avec le verbe manage groups et le type de ressource. Comme indiqué par le tableau dans Détails des combinaisons de verbe et de type de ressource, les droits d'accès couverts sont les suivants :

• GROUP_INSPECT
• GROUP_UPDATE
• GROUP_CREATE
• GROUP_DELETE

Pour restreindre l'accès uniquement aux droits souhaités, vous pouvez ajouter une condition qui indique explicitement les droits d'accès à autoriser :

Allow group XYZ to manage groups in tenancy

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

Vous pouvez également opter pour une stratégie qui autorise tous les droits d'accès à l'exception de GROUP_DELETE :

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

Cependant, avec cette approche, sachez que les nouveaux droits d'accès que le service pourrait ajouter à l'avenir sont automatiquement accordés au groupe XYZ. Seul GROUP_DELETE est omis.

Une autre alternative consiste à écrire une condition basée sur des opérations d'API spécifiques. En fonction du tableau dans Droits d'accès requis pour chaque opération d'API, ListGroups et GetGroup ne nécessitent que le droit d'accès GROUP_INSPECT. La stratégie est la suivante :

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 utile d'utiliser des droits d'accès plutôt que des opérations d'API dans des conditions. A l'avenir, si une nouvelle opération d'API est ajoutée et qu'elle nécessite l'un des droits d'accès répertoriés dans la stratégie basée sur des droits d'accès ci-dessus, cette stratégie contrôlera déjà l'accès du groupe XYZ à cette nouvelle opération d'API.

Cependant, vous pouvez définir davantage la portée de l'accès d'un utilisateur à un droit en indiquant également une condition basée sur une opération d'API. Par exemple, vous pouvez donner à un utilisateur l'accès à GROUP_INSPECT, mais uniquement à ListGroups.

Allow group XYZ to manage groups in tenancy

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

Vous pouvez attribuer l'accès à un ensemble d'adresses IP autorisées uniquement. Par exemple, vous pouvez écrire une stratégie autorisant uniquement les demandes d'une plage d'adresses IP publiques donnée à accéder à un bucket Object Storage spécifique. Vous pouvez également n'autoriser que des sous-réseaux précis d'un réseau cloud virtuel spécifique à effectuer des demandes via une passerelle de service.

Pour restreindre l'accès à un ensemble d'adresses IP, procédez comme suit :

1. Créez un objet de source réseau qui spécifie les adresses IP autorisées. Pour plus d'informations, reportez-vous à Gestion des sources réseau.
2. Ecrivez une stratégie qui utilise l'objet de source réseau dans une condition.

Utilisez la variable suivante dans la stratégie :

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 temporelles dans vos stratégies pour limiter l'accès accordé dans la stratégie à certaines périodes uniquement. Cette fonctionnalité permet de limiter les actions sur les ressources à des moments particuliers. Par exemple, vous pouvez créer une stratégie autorisant l'accès uniquement à une date donnée. Une telle stratégie est utile si votre société recourt à des sous-traitants et que vous voulez vous assurer que l'accès n'est pas autorisé après 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 9h à 17h). Cette restriction peut réduire le risque qu'un acteur malveillant effectue des modifications lorsqu'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'