Fonctions avancées liées aux politiques
Cette section décrit les fonctions du langage de politique qui permettent d'accorder des droits d'accès plus précis.
Conditions
Dans le cadre d'un énoncé de politique, vous pouvez spécifier une ou plusieurs conditions à remplir pour que l'accès soit accordé.
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.
La correspondance des conditions n'est pas sensible à la casse. Il est important de s'en rappeler lors de l'écriture de conditions pour des types de ressource qui permettent une attribution de nom sensible à la casse. Par exemple, le service Stockage d'objets permet de créer à la fois un seau nommé "BucketA" et un seau nommé "bucketA" dans le même compartiment. Si vous écrivez une condition qui spécifie "BucketA", elle s'appliquera également à "bucketA" car la correspondance de condition n'est pas sensible à la casse.
Variables qui ne sont pas applicables à un résultat de demande dans une demande refusée
Si la variable n'est pas applicable à la demande entrante, la condition est évaluée à Faux et la demande est refusée. Par exemple, voici les énoncés de base qui permettent d'ajouter ou de supprimer des utilisateurs dans n'importe quel groupe à l'exception du groupe Administrators :
Allow group GroupAdmins to use users in tenancy
where target.group.name != 'Administrators'
Allow group GroupAdmins to use groups in tenancy
where target.group.name != 'Administrators'
Compte tenu de la politique ci-dessus, si GroupAdmins tente d'appeler une opération d'API générale pour des utilisateurs, telle que ListUsers
ou UpdateUser
(qui permet de modifier la description de l'utilisateur), la demande est refusée, même si ces opérations d'API sont couvertes par use users
. En effet, l'énoncé de politique ci-dessus pour use users
inclut également la variable target.group.name
mais la demande ListUsers
ou UpdateUser
n'implique pas de spécifier un groupe. Comme il n'y a pas de target.group.name
pour ces demandes, la demande est refusée.
Si vous voulez également accorder l'accès aux opérations d'API d'utilisateur générales qui n'impliquent pas un groupe particulier, vous avez besoin d'un énoncé supplémentaire qui donne le niveau d'accès que vous voulez accorder, mais sans la condition. Par exemple, si vous voulez accorder l'accès à ListUsers
, vous devez spécifier l'énoncé supplémentaire suivant :
Allow group GroupAdmins to inspect users in tenancy
Si vous voulez accorder l'accès à UpdateUser
, vous avez besoin de cet énoncé supplémentaire (qui couvre également ListUsers
car le verbe use
inclut les capacités du verbe inspect
) :
Allow group GroupAdmins to use users in tenancy
Ce concept général s'applique également aux groupes (par exemple, ListGroups
et UpdateGroup
), ainsi qu'à tout autre type de ressource avec des variables cibles.
Pour plus d'informations sur la syntaxe des conditions, voir Conditions. Pour une liste de toutes les variables que vous pouvez utiliser dans des politiques, voir les tableaux sous Informations de référence sur les politiques.
Contrôle d'accès basé sur des marqueurs
À l'aide de conditions et d'un jeu de variables de marqueur, vous pouvez écrire une politique pour définir la portée de l'accès en fonction des marqueurs qui ont été appliqués à une ressource. L'accès peut être contrôlé en fonction d'un marqueur qui existe sur la ressource à l'origine de la demande (groupe ou groupe dynamique de la politique) ou sur la cible de la demande (ressource ou compartiment). Le contrôle d'accès basé sur des marqueurs offre une flexibilité supplémentaire à vos politiques, en vous permettant de définir un accès qui couvre des compartiments, des groupes et des ressources. Pour plus de détails sur l'écriture de politiques permettant de définir la portée de l'accès en fonction de marqueurs, voir Utilisation de marqueurs pour gérer l'accès.
Autorisations
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.
Relation avec les verbes
Pour comprendre la relation entre les autorisations et les verbes, prenons un exemple. Un énoncé qui permet à un groupe d'inspecter les volumes (inspect volumes
) permet en fait à ce groupe d'accéder à une autorisation nommée VOLUME_INSPECT (les autorisations sont toujours écrites en lettres majuscules avec des traits de soulignement). En général, cette autorisation permet à l'utilisateur d'obtenir des informations sur les volumes par blocs.
Lorsque vous passez de inspect
> read
> use
> manage
, le niveau d'accès augmente généralement et les autorisations accordées sont cumulatives. Le tableau suivant présente les autorisations incluses avec chaque verbe pour le type de ressource volumes
. Notez qu'aucune autorisation supplémentaire n'est accordée lors du passage de inspect
à read
.
Inspecter les volumes | Lire les volumes | Utiliser les volumes | Gérer les volumes |
---|---|---|---|
VOLUME_INSPECT | VOLUME_INSPECT |
VOLUME_INSPECT VOLUME_UPDATE VOLUME_WRITE |
VOLUME_INSPECT VOLUME_UPDATE VOLUME_WRITE VOLUME_CREATE VOLUME_DELETE |
La rubrique Informations de référence sur les politiques répertorie les autorisations couvertes par chaque verbe pour chaque type de ressource indiqué. Par exemple, pour les volumes par blocs et les autres ressources couvertes par les services de base, voir les tableaux sous Informations détaillées sur les combinaisons Verbe + Type de ressource. La colonne de gauche de chaque tableau répertorie les autorisations couvertes par chaque verbe. Les autres sections de la rubrique Informations de référence sur les politiques présentent le même type d'informations pour les autres services.
Relation avec les opérations d'API
Chaque opération d'API nécessite que le programme d'appel ait accès à une ou plusieurs autorisations. Par exemple, pour utiliser ListVolumes
ou GetVolume
, vous devez avoir accès à une seule autorisation : VOLUME_INSPECT. Pour attacher un volume à une instance, vous devez avoir accès à plusieurs autorisations, dont certaines sont liées au type de ressource volumes
, d'autres au type de ressource volume-attachments
et d'autres au type de ressource instances
:
- VOLUME_WRITE
- VOLUME_ATTACHMENT_CREATE
- INSTANCE_ATTACH_VOLUME
La rubrique Informations de référence sur les politiques répertorie les autorisations requises pour chaque opération d'API. Par exemple, pour les opérations d'API des services de base, voir le tableau sous Autorisations requises pour chaque opération d'API.
Présentation de l'accès d'un utilisateur
Le langage de politique permet d'écrire des énoncés simples impliquant uniquement des verbes et des types de ressource, sans avoir à indiquer les autorisations souhaitées dans l'énoncé. Cela dit, il arrive parfois qu'un membre ou un vérificateur de l'équipe de sécurité souhaite en savoir plus sur les autorisations spécifiques dont dispose un utilisateur. Les tableaux figurant sous Informations de référence sur les politiques présentent chaque verbe et les autorisations associées. Vous pouvez consulter les groupes dans lesquels figure l'utilisateur et les politiques qui s'appliquent à ces groupes, et compiler à partir de là une liste des autorisations accordées. En revanche, il ne suffit pas de disposer d'une liste des autorisations pour avoir une vision complète. Les conditions incluses dans un énoncé de politique peuvent cibler l'accès d'un utilisateur au-delà des autorisations individuelles (voir la section suivante). En outre, chaque énoncé de politique spécifie un compartiment particulier et peut comporter des conditions qui limitent encore l'accès à certaines ressources de ce compartiment.
Définition de la portée de l'accès avec des autorisations ou des opérations d'API
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'}
Définition de la portée d'une politique en fonction de l'adresse IP du demandeur
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 restreindre l'accès à un jeu d'adresses IP, procédez de la façon suivante :
- Créez un objet de source de réseau qui spécifie les adresses IP autorisées. Voir Gestion des sources de réseau pour plus de détails.
- É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'
Restriction de l'accès aux ressources par période
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 :
request.utc-timestamp
request.utc-timestamp.month-of-year
request.utc-timestamp.day-of-month
request.utc-timestamp.day-of-week
request.utc-timestamp.time-of-day
L'utilisation de ces variables est décrite plus en détail dans les sections suivantes.
Informations sur l'utilisation de variables basées sur le temps
Vous devez spécifier les variables basées sur le temps à l'aide du format ISO 8601 : AAAA-MM-JJThh:mm:ssZ. Exemples de ce format :
- Date et heure avec secondes : '2020-04-01T15 :00:00Z'
- Date et heure avec minutes : '2020-04-01T05 :00Z'
- Date seulement : '2020-04-01Z'
- Heure seulement : '05:00:00'
Même si vous pouvez réduire le temps à quelques secondes, vous devez autoriser un écart de temps de 5 minutes entre l'horodatage spécifié dans la demande et l'heure à laquelle celle-ci est évaluée par le service GIA. Cet écart de temps peut être causé par plusieurs facteurs, par conséquent, vous devez en tenir compte lorsque vous planifiez et mettez en oeuvre vos politiques basées sur le temps.
L'heure que vous indiquez est évaluée en temps universel coordonné (UTC). Cela signifie que vous devez calculer l'heure UTC appropriée pour le fuseau horaire dans lequel la politique est évaluée. Par exemple, pour spécifier 9:00 AM (Heure normale du Pacifique) pour la valeur d'une variable, entrez '17:00:00'. Si l'heure avancée est mise en oeuvre par vos paramètres régionaux, vous devez mettre à jour toutes les politiques qui font référence à une heure spécifique lorsque le changement d'heure entre en vigueur.
Informations détaillées sur chaque variable basée sur le temps
L'utilisation de chaque variable est décrite dans les sections suivantes :
Description : Heure à laquelle la demande d'autorisation est reçue. Vous pouvez écrire une politique qui autorise l'accès uniquement avant ou après un horodatage de date et d'heure spécifique. L'horodatage doit respecter le format ISO 8601 : AAAA-MM-JJThh:mm:ssZ et être en temps universel coordonné (UTC).
Opérateurs pris en charge : before | after
Valeurs autorisées : Horodatage en temps universel coordonné (UTC) au format ISO 8601 format: AAAA-MM-JJThh:mm:ssZ
- '2020-04-01T00:00:00Z'
- '2020-04-01T00:00Z'
Exemple de politique : Autoriser le groupe Contractors à accéder aux ressources instance-family
uniquement jusqu'à une certaine date :
Allow group Contractors to manage instance-family in tenancy where request.utc-timestamp before '2022-01-01T00:00Z'
L'accès accordé par la politique au groupe Contractors expire le 1er janvier 2022, 12:00 AM, UTC.
Description : Mois de l'année où la demande d'autorisation est reçue. Vous pouvez écrire une politique qui autorise l'accès pendant certains mois uniquement.
Opérateurs pris en charge : = |!= | in
Valeurs autorisées : Numéro du mois (selon ISO 8601)
Exemples de valeurs : '1', '2', '3', ... '12'
Exemple de politique : Autoriser le groupe SummerInterns à accéder aux ressources instance-family
uniquement en juin, juillet et août :
Allow group SummerInterns to manage instance-family in tenancy where ANY {request.utc-timestamp.month-of-year in ('6', '7', '8')}
L'accès accordé par la politique au groupe SummerInterns n'est valide qu'en juin, juillet et août pour une année donnée.
Description : Jour du mois où la demande d'autorisation est reçue. Vous pouvez écrire une politique qui autorise l'accès uniquement certains jours du mois. Sachez que la durée de la journée est calculée en fonction du temps UTC. Par exemple, supposons que vous êtes à Miami, en Floride, États-Unis et que vous entrez '1' pour indiquer le premier jour du mois. Pour le mois de février, la politique est en vigueur de 12:00 AM à 11:59 PM UTC le 1er février, et, à Miami, de 7:00 PM le 31 janvier à 6:59 PM le 1er février.
Opérateurs pris en charge : = |!= | in
Valeurs autorisées : Numéro du jour dans le mois
Exemples de valeurs : '1', '2', '3', ... '31'
Exemple de politique : Autoriser le groupe ComplianceAuditors à lire all-resources
uniquement le premier jour du mois.
Allow group ComplianceAuditors to read all-resources in tenancy where request.utc-timestamp.day-of-month = '1'
L'accès accordé par la politique au groupe ComplianceAuditors est valide uniquement le premier jour de chaque mois (le jour est défini en fonction du temps UTC).
Description : Jour de la semaine où la demande d'autorisation est reçue. Vous pouvez écrire une politique qui autorise l'accès certains jours de la semaine uniquement. Notez que la durée de la journée est calculée en fonction du temps UTC. Par exemple, supposons que vous êtes à Miami, en Floride, États-Unis, et que vous entrez 'monday'. La politique est en vigueur de 12:00 AM à 11:59 PM UTC le lundi, et, à Miami, de 7:00 PM (EST) le dimanche à 6:59 PM le lundi.
Opérateurs pris en charge : = |!= | in
Valeurs autorisées : Nom du jour de la semaine en anglais
Exemples de valeurs : Lundi, mardi, mercredi, etc.
Exemple de politique : Autoriser le groupe WorkWeek à gérer instance-family
uniquement pendant la semaine de travail de la société.
Allow group WorkWeek to manage instance-family where ANY {request.utc-timestamp.day-of-week in ('monday', 'tuesday', 'wednesday', 'thursday', 'friday')}
L'accès accordé par la politique au groupe WorkWeek est valide uniquement les jours spécifiés (le jour est défini en fonction du temps UTC).
Description : Heure du jour où la demande d'autorisation est reçue. Vous pouvez écrire une politique qui autorise l'accès uniquement pendant un laps de temps spécifique au cours de la journée. Notez que l'heure de la journée est calculée en fonction du temps UTC. Si votre fuseau horaire met en oeuvre l'heure avancée, vous devez mettre à jour la politique lorsque le changement d'heure entre en vigueur.
Opérateurs pris en charge : between
Valeurs autorisées : Intervalle de temps UTC au format ISO 8601 : hh:mm:ssZ
Exemples de valeurs : '01:00:00Z' AND '2:01:00Z'
Exemples de politiques : Autoriser le groupe DayShift à gérer les instances et les ressources connexes entre 9:00 AM et 5:00 PM (Heure normale du Pacifique, PST).
Notez que les heures sont converties en UTC :
Allow group DayShift to manage instance-family where request.utc-timestamp.time-of-day between '17:00:00Z' and '01:00:00Z'
Je veux autoriser le groupe NightShift à gérer les instances et les ressources connexes entre 5:00 PM et 9:00 AM PST.
Allow group NightShift to manage instance-family where request.utc-timestamp.time-of-day between '01:00:00Z' and '17:00:00Z'
Dans ces deux exemples, l'heure courante est calculée et testée pour voir si elle se situe ou non dans l'intervalle fourni (en ignorant le jour où elle tombe).