Fonctionnement des politiques
Afin d'établir un cadre de compréhension avant d'écrire vos propres politiques, obtenez un aperçu de la nature des politiques, de leurs composants et de leurs fonctions de base.
Cette rubrique décrit le fonctionnement des politiques, les fonctions qui ont une incidence sur leur utilisation, et l'intégration de ces fonctions à d'autres fonctions et ressources Oracle Cloud Infrastructure de base.
Aperçu des politiques
Une politique est un document précisant les personnes pouvant accéder aux ressources Oracle Cloud Infrastructure dont dispose votre société, ainsi que la méthode d'accès. Une politique permet simplement à un groupe d'utiliser de façons particulières des types spécifiques de ressources dans un compartiment précis. Si vous ne connaissez pas les concepts relatifs aux utilisateurs, aux groupes ou aux compartiments, voir Aperçu du service GIA.
En général, voici le processus qu'un administrateur du service GIA dans votre organisation doit suivre :
- Définir les utilisateurs, les groupes et un ou plusieurs compartiments pour contenir les ressources en nuage de votre organisation.
- Créer une ou plusieurs politiques, chacune écrite dans le langage de politique. Voir Politiques communes.
- Placer des utilisateurs dans les groupes appropriés en fonction des compartiments et des ressources avec lesquels ils doivent travailler.
- Fournir aux utilisateurs les mots de passe à usage unique dont ils ont besoin pour accéder à la console et utiliser les compartiments. Pour plus d'informations, voir Données d'identification d'utilisateur.
Une fois ces étapes terminées par l'administrateur, les utilisateurs peuvent accéder à la console, modifier leurs mots de passe ponctuels et utiliser des ressources en nuage spécifiques, comme indiqué dans les politiques.
Données de base sur les politiques
Pour régir le contrôle de vos ressources, votre société aura au moins une politique. Chaque politique est constituée d'au moins un énoncé qui respecte la syntaxe de base suivante :
Allow group <identity_domain_name>/<group_name> to <verb> <resource-type> in compartment <compartment_name>
Si vous n'incluez pas <identity_domain_name> avant <group_name>, l'énoncé de politique est évalué comme si le groupe appartenait au domaine d'identité par défaut.
Remarquez que les énoncés commencent toujours par le mot Allow
(Permettre). Les politiques permettent uniquement l'accès; elles ne peuvent pas le refuser. Il existe plutôt un refus implicite qui signifie par défaut que les utilisateurs ne peuvent rien faire et que des droits d'accès doivent leur être accordés au moyen de politiques. (Il y a une exception à cette règle. Voir Les utilisateurs peuvent-ils effectuer des opérations sans qu'un administrateur écrive une politique pour eux?)
Un administrateur de votre organisation définit les groupes et les compartiments de votre location. Oracle définit les verbes et les types de ressource possibles que vous pouvez utiliser dans les politiques (voir Verbe et Types de ressource).
Dans certains cas, vous pouvez souhaiter que la politique s'applique à toute la location et pas seulement à un compartiment de la location. Dans ce cas, modifiez la fin de l'énoncé de la politique comme suit :
Allow group <identity_domain_name>/<group_name> to <verb> <resource-type> in tenancy
Pour plus de détails sur la syntaxe, voir Syntaxe de politique.
Pour plus d'informations sur le nombre de politiques auxquelles vous pouvez avoir accès, voir Limites de service.
Quelques exemples
Supposons que votre administrateur crée un groupe appelé HelpDesk (dans le domaine d'identité par défaut) dont la tâche est de gérer les utilisateurs et leurs données d'identification. Voici une politique qui le lui permet :
Allow group default/HelpDesk to manage users in tenancy
Notez que comme les utilisateurs se trouvent dans la location (compartiment racine), la politique énonce simplement le mot tenancy
, sans le mot compartment
devant.
Ensuite, supposons que vous ayez un compartiment appelé Project-A, et un groupe (dans le domaine d'identité par défaut) appelé A-Admins dont la tâche est de gérer toutes les ressources Oracle Cloud Infrastructure du compartiment. Voici un exemple de politique qui le permet :
Allow group default/A-Admins to manage all-resources in compartment Project-A
N'oubliez pas que la politique ci-dessus inclut la possibilité d'écrire des politiques pour ce compartiment, ce qui signifie que A-Admins peut contrôler l'accès aux ressources du compartiment. Pour plus d'informations, voir Association de politique.
Si vous vouliez limiter l'accès d'A-Admins au lancement et à la gestion des instances de calcul et des volumes de stockage par blocs (volumes et sauvegardes) dans le compartiment Project-A, alors que le réseau lui-même se trouve dans le compartiment Networks, la politique se présenterait plutôt comme suit :
Allow group default/A-Admins to manage instance-family in compartment Project-A
Allow group default/A-Admins to manage volume-family in compartment Project-A
Allow group default/A-Admins to use virtual-network-family in compartment Networks
Le troisième énoncé avec le type de ressource virtual-network-family
permet le processus de lancement d'instance, car le réseau en nuage est concerné. Concrètement, le processus de lancement crée une nouvelle carte d'interface réseau virtuelle (vNIC) et l'associe au sous-réseau dans lequel se trouve l'instance.
Pour d'autres exemples, voir Politiques communes.
Informations détaillées sur la spécification des groupes et des compartiments
En général, pour spécifier un groupe ou un compartiment, vous indiquez son nom dans la politique. Vous pouvez également utiliser l'OCID. Veillez à ajouter "id
" avant l'OCID. Par exemple :
Allow group
id ocid1.group.oc1..aaaaaaaaqjihfhvxmumrl3isyrjw3n6c4rzwskaawuc7i5xwe6s7qmnsbc6a
to manage instance-family in compartment Project-A
Vous pouvez spécifier plusieurs groupes en les séparant par des virgules IAM :
Allow group default/A-Admins, default/B-Admins to manage instance-family in compartment Projects-A-and-B
Si vous utilisez le nom d'un groupe, d'un groupe dynamique ou d'un compartiment dans une politique, la politique est mappée à l'OCID du groupe, du groupe dynamique ou du compartiment lors de la création de la politique. Si l'OCID du groupe, du groupe dynamique ou du compartiment change, vous devez recompiler l'une des politiques qui s'applique au groupe ou au compartiment pour mettre à jour l'OCID dans toutes les politiques.
Pour recompiler la stratégie, ouvrez-la et effectuez une petite modification. Enregistrez la stratégie.
Verbes
Oracle définit les verbes que vous pouvez utiliser dans vos politiques. Voici un sommaire des verbes, de l'accès le plus restreint au plus large :
Verbe | Types d'accès couverts | Utilisateur cible |
---|---|---|
inspect
|
Capacité de lister les ressources, sans accès aux informations confidentielles ou aux métadonnées spécifiées par l'utilisateur qui peuvent faire partie de cette ressource. Important : L'opération permettant de lister les politiques inclut le contenu des politiques elles-mêmes et les opérations pour lister les types de ressource du service Réseau retournent toutes les informations (par exemple, le contenu des listes de sécurité et des tables de routage). | Vérificateurs tiers |
read
|
Inclut inspect plus la possibilité d'obtenir des métadonnées spécifiées par l'utilisateur et la ressource réelle proprement dite. |
Vérificateurs internes |
use
|
Inclut read plus la possibilité d'utiliser des ressources existantes (les actions varient en fonction du type de ressource). Inclut la possibilité de mettre à jour la ressource, sauf pour les types de ressource pour lesquels l'opération de mise à jour ("update") a la même incidence que l'opération de création ("create") (par exemple, UpdatePolicy , UpdateSecurityList , etc.), auquel cas la possibilité de mise à jour n'est disponible qu'avec le verbe manage . En général, ce verbe ne permet pas de créer ou de supprimer ce type de ressource. |
Utilisateurs quotidiens de ressources |
manage
|
Inclut toutes les autorisations pour la ressource. | Administrateurs |
Le verbe fournit un certain type d'accès général (par exemple, inspect
vous permet de lister et d'obtenir les ressources). Lorsque vous associez ensuite ce type d'accès à un type de ressource particulier dans une politique (par exemple, Allow group XYZ to inspect compartments in the tenancy
), vous accordez à ce groupe l'accès à un jeu spécifique d'autorisations et d'opérations d'API (par exemple, ListCompartments
, GetCompartment
). Pour d'autres exemples, voir Informations détaillées sur les combinaisons Verbe + Type de ressource. La rubrique Informations de référence sur les politiques présente un tableau similaire pour chaque service, qui vous fournit une liste des opérations d'API couvertes pour chaque combinaison de verbe et de type de ressource.
Des exceptions spéciales ou des nuances s'appliquent à certains types de ressource.
Utilisateurs : L'accès à manage users
et manage groups
vous permet d'effectuer toutes les opérations liées aux utilisateurs et groupes, notamment de créer et de supprimer des utilisateurs et des groupes, et d'ajouter des utilisateurs à des groupes ou d'en retirer. Pour ajouter des utilisateurs à des groupes ou en retirer sans accès à la création et à la suppression d'utilisateurs et de groupes, seuls use users
et use groups
sont requis. Voir Politiques communes.
Politiques : La possibilité de mettre à jour une politique est disponible uniquement avec manage policies
, et non avec use policies
, car la mise à jour d'une politique est similaire à celle permettant la création d'une nouvelle politique (vous pouvez remplacer les énoncés existants). De plus, inspect policies
vous permet d'obtenir tout le contenu des politiques.
Objets de stockage d'objets : inspect objects
vous permet de répertorier tous les objets d'un seau et d'effectuer une opération HEAD sur un objet particulier. En comparaison, read objects
vous permet de télécharger l'objet lui-même.
Ressources d'équilibreur de charge : Gardez à l'esprit que inspect load-balancers
vous permet d'obtenir toutes les informations sur vos équilibreurs de charge et composants connexes ( jeux dorsaux, etc.).
Ressources de réseau :
Par exemple, le verbe inspect
ne retourne pas seulement les informations générales sur les composants du réseau en nuage (par exemple, le nom et l'OCID d'une liste de sécurité ou d'une table de routage). Il inclut également le contenu du composant (par exemple, les règles réelles dans la liste de sécurité, les routes dans la table de routage, etc.).
De plus, les types de fonction suivants sont disponibles uniquement avec le verbe manage
et ne le sont pas avec le verbe use
:
- Mettre à jour (activer/désactiver)
internet-gateways
- Mettre à jour
security-lists
- Mettre à jour
route-tables
- Mettre à jour
dhcp-options
- Attacher une passerelle de routage dynamique (DRG) à un réseau en nuage virtuel (VCN)
- Créer une connexion IPSec entre une passerelle de routage dynamique (DRG) et un équipement local d'abonné (CPE)
- Appairer des réseaux en nuage virtuels (VCN)
Chaque VCN comprend différents composants qui ont une incidence directe sur le comportement du réseau (tables de routage, listes de sécurité, options DHCP, passerelle Internet, etc.). Lorsque vous créez l'un de ces composants, vous établissez une relation entre celui-ci et le réseau VCN. La politique doit donc vous autoriser à créer le composant et à gérer le réseau VCN. En revanche, la possibilité de mettre à jour ce composant (pour modifier les règles de routage, les règles de liste de sécurité, etc.) ne requiert pas d'autorisation pour gérer le VCN lui-même, même si la modification de ce composant peut avoir une incidence directe sur le comportement du réseau. Vous disposez ainsi de la flexibilité nécessaire pour octroyer un privilège minimal aux utilisateurs sans avoir à accorder d'accès excessif au VCN pour que l'utilisateur puisse gérer d'autres composants du réseau. En accordant à un utilisateur la capacité de mettre à jour un type de composant particulier, vous lui confiez implicitement le contrôle du comportement du réseau.
Types de ressource
Oracle définit également les types de ressource que vous pouvez utiliser dans vos politiques. Tout d'abord, ce sont des types individuels. Chaque type individuel représente un type de ressource particulier. Par exemple, le type de ressource vcns
s'applique spécifiquement aux réseaux en nuage virtuels (VCN).
Pour faciliter l'écriture de politiques, les types famille contiennent plusieurs types de ressource individuels qui sont souvent gérés ensemble. Par exemple, le type virtual-network-family
regroupe divers types relatifs à la gestion des réseaux en nuage virtuels (notamment, vcns
, subnets
, route-tables
, security-lists
, etc.). Si vous devez écrire une politique plus granulaire qui ne permet d'accéder qu'à un seul type de ressource individuel, vous pouvez le faire. Il est également possible d'écrire une politique pour accorder l'accès à un ensemble de ressources plus large.
Autre exemple : Un volume par blocs a des volumes
, volume-attachments
et volume-backups
. Si vous devez donner accès à des sauvegardes de volumes uniquement, vous pouvez spécifier le type de ressource volume-backups
dans votre politique. Toutefois, si vous devez permettre un accès étendu à toutes les ressources de volume par blocs, vous pouvez spécifier le type de famille appelé volume-family
. Pour une liste complète des types de ressource de famille, voir Types de ressource.
Si un service introduit de nouveaux types de ressource individuels, ces types seront généralement inclus dans le type de famille de ce service. Par exemple, si le service Réseau introduit un nouveau type de ressource individuel, ce dernier sera automatiquement inclus dans la définition du type de ressource
virtual-network-family
. Pour plus d'informations sur les modifications futures apportées aux définitions des types de ressource, voir Politiques et mises à jour de service.Notez qu'il existe d'autres moyens de rendre les politiques plus granulaires, notamment la possibilité de spécifier des conditions en fonction desquelles l'accès est accordé. Pour plus d'informations, voir Fonctions avancées liées aux politiques.
Si un service introduit de nouvelles autorisations pour un type de ressource existant, vous devez mettre à jour l'énoncé de politique pour ce dernier afin que les nouvelles autorisations prennent effet. Pour plus d'informations, voir Les nouvelles autorisations des types de ressource ne sont pas propagées.
Accès nécessitant plusieurs types de ressource
Certaines opérations d'API requièrent un accès à plusieurs types de ressource. Par exemple, LaunchInstance
nécessite de pouvoir créer des instances et d'utiliser un réseau en nuage. L'opération CreateVolumeBackup
nécessite l'accès au volume et à la sauvegarde du volume. Autrement dit, vous aurez des énoncés distincts qui permettent d'accéder à chaque type de ressource (pour un exemple, voir Permettre aux administrateurs de sauvegardes de volume de ne gérer que les sauvegardes). Il n'est pas nécessaire que ces énoncés individuels figurent dans la même politique. En outre, un utilisateur peut obtenir l'accès requis en faisant partie de différents groupes. Par exemple, George pourrait figurer dans un groupe offrant le niveau d'accès requis au type de ressource volumes
et dans un autre groupe lui donnant l'accès requis au type de ressource volume-backups
. La somme des énoncés individuels, quel que soit leur emplacement dans le jeu général de politiques, donne à George l'accès à CreateVolumeBackup
.
Héritage des politiques
Une fonction de base des politiques est le concept d'héritage : les compartiments héritent des politiques du compartiment parent. L'exemple le plus simple est le groupe Administrateurs, qui est fourni automatiquement avec votre location (voir Groupe Administrateurs, politique et rôles d'administrateur). Il existe une politique intégrée qui permet au groupe Administrateurs (dans le domaine d'identité par défaut) d'effectuer toutes les opérations dans la location :
Allow group Administrators to manage all-resources in tenancy
Grâce à l'héritage des politiques, le groupe Administrateurs peut également effectuer toutes les opérations dans tout compartiment de la location.
Pour donner un exemple concret, prenons une location avec trois niveaux de compartiments : CompartmentA, CompartmentB et ComparmentC, présentés ici :
Les politiques qui s'appliquent aux ressources de CompartmentA s'appliquent également aux ressources de CompartmentB et CompartmentC. Ainsi, cette politique :
Allow group default/NetworkAdmins to manage virtual-network-family in compartment CompartmentA
permet au groupe NetworkAdmins (dans le domaine d'identité par défaut) de gérer les réseaux en nuage virtuels (VCN) dans CompartmentA, CompartmentB et CompartmentC.
Association de politique
Une autre fonction de base des politiques est le concept d'association. Lorsque vous créez une politique, vous devez l'associer à un compartiment (ou à la location, qui est le compartiment racine). L'emplacement auquel vous associez détermine qui peut la modifier ou la supprimer. Si vous l'assignez à la location (par exemple, si la politique se trouve dans le compartiment racine, toute personne ayant accès à la gestion des politiques dans la location peut la modifier ou la supprimer. En général, il s'agit du groupe Administrateurs ou d'un groupe similaire que vous créez et auquel vous donnez un accès étendu. Les personnes qui n'ont accès qu'à un compartiment enfant ne peuvent pas modifier ni supprimer cette politique.
Si vous associez la politique à un compartiment enfant, toute personne ayant accès à la gestion des politiques dans ce compartiment peut la modifier ou la supprimer. En pratique, cela signifie qu'il est facile d'autoriser les administrateurs du compartiment (par exemple, un groupe autorisé à gérer manage all-resources
dans le compartiment) à gérer les politiques de leur propre compartiment, sans pour autant les autoriser à gérer les politiques qui se trouvent dans la location. Pour un exemple de ce type de conception d'administrateur de compartiment, voir Exemple de scénario. (Notez qu'en raison de l'héritage des politiques, les utilisateurs qui ont accès à la gestion des politiques de la location peuvent automatiquement gérer les politiques des compartiments de la location.)
Le processus d'attachement de la politique est facile (que ce soit à un compartiment ou à la location) : Si vous utilisez la console, lorsque vous ajoutez la politique à IAM, assurez-vous d'être dans le bon compartiment lorsque vous créez la politique. Si vous utilisez l'API, vous spécifiez l'OCID du compartiment correct (la location ou un autre compartiment) dans le cadre de la demande pour créer la politique.
Politiques et hiérarchies de compartiments
Tel qu'il est décrit dans la section précédente, un énoncé de politique doit spécifier le compartiment (ou la location) pour lequel l'accès est accordé. L'emplacement où vous créez la politique détermine qui peut mettre à jour cette politique. Si vous associez la politique au compartiment ou à son parent, il vous suffit de spécifier le nom du compartiment. Si vous associez la politique à un autre emplacement plus haut dans la hiérarchie, vous devez spécifier le chemin d'accès. Le format du chemin d'accès se compose de chaque nom de compartiment (ou OCID) dans le chemin, séparé par un deux-points :
<niveau_compartiment_1> :<niveau_compartiment_2> : . . . <niveau_compartiment_n>
Par exemple, supposons que vous disposiez d'une hiérarchie de compartiments à trois niveaux, comme présentée ci-dessous :
Vous souhaitez créer une politique pour permettre à NetworkAdmins (dans le domaine d'identité par défaut) de gérer les réseaux en nuage virtuels dans CompartmentC. Si vous voulez associer cette politique à CompartmentC ou à son parent CompartmentB, écrivez l'énoncé de politique suivant :
Allow group default/NetworkAdmins to manage virtual-network-family in compartment CompartmentC
Toutefois, si vous voulez associer cette politique à CompartmentA (afin que seuls les administrateurs de CompartmentA puissent la modifier), écrivez l'énoncé suivant qui spécifie le chemin d'accès :
Allow group default/NetworkAdmins to manage virtual-network-family in compartment CompartmentB:CompartmentC
Pour associer cette politique à la location, écrivez l'énoncé suivant qui spécifie le chemin d'accès de CompartmentA à CompartmentC :
Allow group default/NetworkAdmins to manage virtual-network-family in compartment CompartmentA:CompartmentB:CompartmentC
Politiques et mises à jour de service
Il est possible que la définition d'un verbe ou d'un type de ressource change à l'avenir. Par exemple, supposons que le type de ressource virtual-network-family
change pour inclure un nouveau type de ressource ajouté au service de réseau. Par défaut, vos politiques restent automatiquement en phase avec tout changement dans la définition du service. Ainsi, toute politique dont vous disposez qui donne accès à virtual-network-family
inclut automatiquement l'accès à la nouvelle ressource ajoutée.
Si un service introduit de nouvelles autorisations pour un type de ressource existant, vous devez mettre à jour l'énoncé de politique pour ce dernier afin que les nouvelles autorisations prennent effet. Pour plus d'informations, voir Les nouvelles autorisations des types de ressource ne sont pas propagées.
Écriture de politiques pour chaque service
La rubrique Informations de référence sur les politiques contient les détails des types de ressource spécifiques pour chaque service, et indique quelle combinaison de verbe + type de ressource donne accès aux opérations d'API.