Fonctionnement des stratégies
Pour disposer des connaissances nécessaires avant d'écrire vos propres stratégies, consultez une présentation des stratégies, de leurs composants et de leurs fonctionnalités de base.
Cette rubrique décrit le fonctionnement des stratégies, les fonctionnalités ayant une incidence sur leur utilisation, et l'intégration de ces fonctionnalités à d'autres ressources et fonctionnalités Oracle Cloud Infrastructure de base.
Présentation des stratégies
Une stratégie est un document précisant les personnes pouvant accéder à telle ou telle ressource Oracle Cloud Infrastructure dont dispose votre entreprise, ainsi que la méthode d'accès. Une stratégie permet simplement à un groupe d'utiliser de certaines façons des types spécifiques de ressource dans un compartiment donné. Si les concepts d'utilisateurs, de groupes ou de compartiments ne vous sont pas familiers, reportez-vous à Présentation d'IAM.
En général, voici le processus qu'un administrateur IAM de votre organisation doit suivre :
- Définir des utilisateurs, des groupes et des compartiments pour stocker les ressources cloud de votre organisation.
- Créer des stratégies, chacune écrite dans le langage de stratégie. Reportez-vous à Stratégies courantes.
- Placer les utilisateurs dans les groupes appropriés en fonction des compartiments et des ressources qu'ils doivent utiliser.
- 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, reportez-vous à Informations d'identification utilisateur.
Une fois que l'administrateur a effectué ces étapes, les utilisateurs peuvent accéder à la console, modifier leur mot de passe à usage unique et utiliser des ressources cloud spécifiques comme indiqué dans les stratégies.
Données de base des stratégies
Pour régir le contrôle de vos ressources, votre société aura au moins une stratégie. Chaque stratégie se compose d'au moins une instruction qui suit 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'instruction de stratégie est évaluée comme si le groupe appartenait au domaine d'identité par défaut.
Les instructions commencent toujours par le mot Allow
. Les stratégies ne font qu'autoriser l'accès ; elles ne peuvent pas le refuser. A la place, il existe un refus implicite, ce qui signifie que, par défaut, les utilisateurs ne peuvent rien faire et doivent disposer d'un accès via des stratégies. (Il existe une exception à cette règle : reportez-vous à Les utilisateurs peuvent-ils réaliser des opérations sans qu'un administrateur écrive une stratégie pour eux ?)
Un administrateur de votre organisation définit les groupes et les compartiments dans votre location. Oracle définit les verbes et les types de ressource que vous pouvez utiliser dans les stratégies (reportez-vous à Verbe et à Types de ressource).
Dans certains cas, vous souhaiterez appliquer la stratégie à la location et non à un compartiment dans la location. Dans ce cas, modifiez la fin de l'instruction de stratégie comme suit :
Allow group <identity_domain_name>/<group_name> to <verb> <resource-type> in tenancy
Pour plus de détails sur la syntaxe, reportez-vous à Syntaxe de stratégie.
Pour plus d'informations sur le nombre de stratégies dont vous pouvez disposer, reportez-vous à Limites de service.
Exemples
Admettons que l'administrateur crée un groupe appelé HelpDesk (dans le domaine d'identité par défaut) dont le travail consiste à gérer les utilisateurs et leurs informations d'identification. Voici une stratégie qui permet cela :
Allow group default/HelpDesk to manage users in tenancy
Dans la mesure où les utilisateurs résident dans la location (compartiment racine), la stratégie indique simplement le mot tenancy
, sans le mot compartment
devant lui.
Ensuite, supposons que vous disposez d'un compartiment appelé Project-A et d'un groupe (dans le domaine d'identité par défaut) appelé A-Admins dont le travail consiste à gérer toutes les ressources Oracle Cloud Infrastructure du compartiment. Voici un exemple de stratégie qui permet cela :
Allow group default/A-Admins to manage all-resources in compartment Project-A
Sachez que la stratégie ci-dessus offre la possibilité d'écrire des stratégies pour ce compartiment, ce qui signifie que le groupe A-Admins peut contrôler l'accès aux ressources du compartiment. Pour plus d'informations, reportez-vous à Attachement de stratégie.
Si vous souhaitez limiter l'accès d'A-Admins au lancement et à la gestion des instances de calcul et des volumes de stockage de blocs (volumes et leurs sauvegardes) dans le compartiment Project-A, mais que le réseau lui-même réside dans le compartiment Networks, la stratégie peut être la suivante :
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
La troisième instruction avec le type de ressource virtual-network-family
active le processus de lancement de l'instance car le réseau cloud est impliqué. Plus précisément, le processus de lancement crée une carte d'interface réseau virtuelle et l'attache au sous-réseau dans lequel réside l'instance.
Pour obtenir d'autres exemples, reportez-vous à Stratégies courantes.
Détails concernant la spécification des groupes et des compartiments
En général, vous indiquez un groupe ou un compartiment en utilisant son nom dans la stratégie. Cependant, vous pouvez utiliser l'OCID à la place. Veillez simplement à ajouter "id
" avant l'OCID. Par exemple :
Allow group
id ocid1.group.oc1..aaaaaaaaqjihfhvxmumrl3isyrjw3n6c4rzwskaawuc7i5xwe6s7qmnsbc6a
to manage instance-family in compartment Project-A
Vous pouvez indiquer plusieurs groupes en les séparant par une virgule 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 stratégie, la stratégie est mise en correspondance avec l'OCID du groupe, du groupe dynamique ou du compartiment lors de la création de la stratégie. Si l'OCID du groupe, du groupe dynamique ou du compartiment change, vous devez recompiler l'une des stratégies qui s'applique au groupe ou au compartiment pour mettre à jour l'OCID dans toutes les stratégies.
Pour recompiler la stratégie, ouvrez-en une et effectuez une petite modification. Enregistrer la stratégie.
Verbes
Oracle définit les verbes que vous pouvez utiliser dans vos stratégies. Voici un récapitulatif des verbes, de celui qui octroie le moins d'accès à celui qui en octroie le plus :
Verbe | Types d'accès couverts | Utilisateur cible |
---|---|---|
inspect
|
Possibilité de répertorier des ressources sans accéder aux informations confidentielles ou aux métadonnées spécifiées par l'utilisateur pouvant appartenir à ces ressources. Important : l'opération permettant de répertorier les stratégies inclut le contenu des stratégies elles-mêmes. Les opérations de liste des types de ressource Networking renvoient toutes les informations (par exemple, le contenu des listes de sécurité et des tables de routage). | Auditeurs tiers |
read
|
Inclut les mêmes droits d'accès que le verbe inspect ainsi que la possibilité d'obtenir les métadonnées spécifiées par l'utilisateur et la ressource elle-même. |
Auditeurs internes |
use
|
Inclut les mêmes droits d'accès que le verbe read ainsi que la possibilité d'utiliser les 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 dans lesquels l'opération "update" a le même impact effectif que l'opération "create" (par exemple, UpdatePolicy , UpdateSecurityList , etc.), auquel cas le droit de mise à jour est uniquement disponible avec le verbe manage . En général, ce verbe n'inclut pas la possibilité de créer ou de supprimer ce type de ressource. |
Utilisateurs finals quotidiens des ressources |
manage
|
Inclut tous les droits d'accès pour la ressource. | Administrateurs |
Le verbe fournit un certain type d'accès général (par exemple, inspect
vous permet de répertorier et d'obtenir des ressources). Lorsque vous associez ensuite un type d'accès à un type de ressource particulier dans une stratégie (par exemple, Allow group XYZ to inspect compartments in the tenancy
), vous octroyez à ce groupe l'accès à un ensemble spécifique de droits d'accès et d'opérations d'API (par exemple, ListCompartments
, GetCompartment
). Pour obtenir d'autres exemples, reportez-vous à Détails des combinaisons de verbe et de type de ressource. La référence de stratégie comprend un tableau similaire pour chaque service, vous donnant la liste des opérations d'API couvertes pour chaque combinaison de verbe et de type de ressource.
Il existe des exceptions ou des nuances spéciales pour certains types de ressource.
Utilisateurs : l'accès à manage users
et à manage groups
vous permet d'effectuer n'importe quelle opération sur les utilisateurs et les groupes, y compris créer et supprimer des utilisateurs et des groupes, et ajouter des utilisateurs à des groupes ou en enlever. Pour ajouter des utilisateurs à des groupes ou en enlever sans disposer des droits d'accès de création ou de suppression d'utilisateurs et de groupes, vous avez seulement besoin de use users
et use groups
. Reportez-vous à Stratégies courantes.
Stratégies : la possibilité de mettre à jour une stratégie n'est disponible que par le biais de manage policies
, et non de use policies
, car l'effet de la mise à jour est semblable à celui de la création d'une stratégie (vous pouvez écraser les instructions de stratégie existantes). En outre, inspect policies
permet d'obtenir tout le contenu des stratégies.
Objets Object Storage : inspect objects
vous permet de répertorier tous les objets d'un bucket ainsi que d'effectuer une opération HEAD pour un objet particulier. En comparaison, read objects
vous permet de télécharger l'objet lui-même.
Ressources Load Balancer : inspect load-balancers
vous permet d'obtenir toutes les informations concernant vos équilibreurs de charge et les composants associés (ensembles de back-ends, etc.).
Ressources Networking :
Gardez à l'esprit que le verbe inspect
ne renvoie pas uniquement des informations générales sur les composants du réseau cloud (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 routages de la table de routage, etc.).
En outre, les types d'action suivants ne sont disponibles qu'avec le verbe manage
, et non avec le verbe use
:
- Mettre à jour (activer/désactiver) les passerelles Internet (
internet-gateways
) - Mettre à jour les listes de sécurité (
security-lists
) - Mettre à jour les tables de routage (
route-tables
) - Mettre à jour les options DHCP (
dhcp-options
) - Attacher une passerelle de routage dynamique à un réseau cloud virtuel
- Créer une connexion IPSec entre une passerelle de routage dynamique et un CPE (Customer-Premises Equipment)
- Appairer des réseaux cloud virtuels
Chaque réseau cloud virtuel dispose de divers composants qui influent directement 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 cloud virtuel, ce qui signifie qu'une stratégie doit vous autoriser à créer le composant et à gérer le réseau cloud virtuel. Toutefois, la possibilité de mettre à jour ce composant (pour modifier les règles de routage, les règles de liste de sécurité, etc.) ne nécessite pas de droit de gestion pour le réseau cloud virtuel, même si la modification de ce composant peut influer directement sur le comportement du réseau. Cette différence est conçue pour vous permettre d'accorder moins de privilèges aux utilisateurs. Vous n'avez ainsi pas besoin d'accorder des accès excessifs au réseau cloud virtuel uniquement pour que l'utilisateur puisse gérer d'autres composants du réseau. Gardez à l'esprit qu'en donnant à un utilisateur la possibilité de mettre à jour un type de composant particulier, vous lui faites implicitement confiance pour contrôler le comportement du réseau.
Types de ressource
Oracle définit également les types de ressource que vous pouvez utiliser dans les stratégies. D'abord, il existe des types individuels. Chaque type individuel représente un type spécifique de ressource. Par exemple, le type de ressource vcns
concerne spécifiquement les réseaux cloud virtuels.
Pour faciliter l'écriture des stratégies, il existe des types de famille incluant plusieurs types individuels de ressource qui sont souvent gérés ensemble. Par exemple, le type virtual-network-family
regroupe différents types liés à la gestion des réseaux cloud virtuels (par exemple, vcns
, subnets
, route-tables
, security-lists
, etc.). Si vous devez écrire une stratégie plus granulaire qui donne accès à un seul type individuel de ressource, vous pouvez le faire. Vous pouvez aussi facilement écrire une stratégie pour accorder l'accès à un vaste éventail de ressources.
Dans un autre exemple, Block Volume contient des éléments volumes
, volume-attachments
et volume-backups
. Si vous devez accorder l'accès uniquement à la création de sauvegardes de volumes, vous pouvez spécifier le type de ressource volume-backups
dans votre stratégie. Toutefois, si vous devez accorder un accès étendu à toutes les ressources Block Volume, vous pouvez spécifier le type de famille volume-family
. Pour obtenir la liste complète des types de ressource de famille, reportez-vous à Types de ressource.
Si un service introduit de nouveaux types individuels de ressource, ceux-ci sont généralement inclus dans le type de famille de ce service. Par exemple, si Networking introduit un nouveau type individuel de ressource, celui-ci sera automatiquement inclus dans la définition du type de ressource
virtual-network-family
. Pour plus d'informations sur les modifications apportées ultérieurement aux définitions de type de ressource, reportez-vous à Stratégies et mises à jour de service.Il existe d'autres méthodes pour définir des stratégies plus précises, comme indiquer des conditions sous lesquelles l'accès est accordé. Pour plus d'informations, reportez-vous à Fonctionnalités de stratégie avancées.
Si un service introduit de nouveaux droits d'accès pour un type de ressource existant, vous devez mettre à jour l'instruction de stratégie pour ce type de ressource afin que les nouveaux droits d'accès prennent effet. Pour plus d'informations, reportez-vous à ces nouveaux droits d'accès dans les types de ressource ne sont pas propagés.
Accès nécessitant plusieurs types de ressource
Certaines opérations d'API nécessitent l'accès à plusieurs types de ressource. Par exemple, LaunchInstance
nécessite de pouvoir créer des instances et d'utiliser un réseau cloud. L'opération CreateVolumeBackup
nécessite un accès au volume et à la sauvegarde de volume. Autrement dit, vous disposerez d'instructions distinctes pour donner accès à chaque type de ressource (pour consulter un exemple, reportez-vous à Autoriser les administrateurs de sauvegarde de volume à gérer uniquement des sauvegardes). Ces instructions individuelles n'ont pas besoin de se trouver dans la même stratégie. De plus, un utilisateur peut obtenir l'accès requis en étant dans différents groupes. Par exemple, George peut se trouver dans un groupe accordant le niveau d'accès requis au type de ressource volumes
et dans un autre donnant l'accès requis au type de ressource volume-backups
. La somme des instructions individuelles, quel que soit leur emplacement dans l'ensemble global des stratégies, donne à George l'accès à CreateVolumeBackup
.
Hérité de stratégie
Le concept d'héritage est une fonctionnalité de base des stratégies : les compartiments héritent de toutes les stratégies de leur compartiment parent. L'exemple le plus simple est le groupe d'administrateurs, qui est automatiquement fourni avec votre location (reportez-vous à Groupe d'administrateurs, stratégie et rôles d'administrateur). Il existe une stratégie intégrée permettant au groupe d'administrateurs (dans le domaine d'identité par défaut) d'effectuer n'importe quelle action dans la location :
Allow group Administrators to manage all-resources in tenancy
En raison de l'héritage de stratégie, le groupe d'administrateurs peut également effectuer n'importe quelle action dans tous les compartiments de la location.
Pour illustrer plus précisément ce concept, imaginez une location avec trois niveaux de compartiments : CompartmentA, CompartmentB et ComparmentC, représentés ci-dessous :
Les stratégies qui s'appliquent aux ressources dans CompartmentA s'appliquent également à celles dans CompartmentB et CompartmentC. La stratégie suivante :
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 cloud virtuels dans CompartmentA, CompartmentB et CompartmentC.
Attachement de stratégie
Le concept d'attachement est une autre fonctionnalité de base des stratégies. Lorsque vous créez une stratégie, vous devez l'attacher à un compartiment (ou à la location, qui est le compartiment racine). L'emplacement d'association détermine les personnes pouvant la modifier ou la supprimer. Si vous l'associez à la location (par exemple, si la stratégie se trouve dans le compartiment racine), tout utilisateur autorisé à gérer les stratégies dans la location peut la modifier ou la supprimer. En règle générale, il s'agit du groupe d'administrateurs ou de tout autre groupe similaire que vous créez et auquel vous accordez un accès étendu. Toute personne ayant uniquement accès à un compartiment enfant ne peut pas modifier ni supprimer cette stratégie.
En revanche, si vous attachez la stratégie à un compartiment enfant, tout utilisateur disposant d'un accès permettant de gérer les stratégies dans ce compartiment peut la modifier ou la supprimer. Dans la pratique, cela signifie qu'il est simple d'accorder des droits d'accès aux administrateurs de compartiment (par exemple, un groupe ayant accès à manage all-resources
dans le compartiment) pour qu'ils puissent gérer les stratégies de leur propre compartiment, sans pour autant les autoriser à gérer les stratégies comprises dans le compte. Pour obtenir un exemple qui utilise ce type de conception administrateur de compartiment, reportez-vous à Exemple de scénario. (N'oubliez pas que, en raison de l'héritage de stratégie, les utilisateurs autorisés à gérer automatiquement les stratégies dans la location peuvent les gérer dans les compartiments à l'intérieur de la location.)
Le processus d'attachement de la stratégie est simple (que vous l'attachiez à un compartiment ou à la location) : si vous utilisez la console, lorsque vous ajoutez la stratégie à IAM, assurez-vous que vous êtes dans le bon compartiment lors de la création de la stratégie. Si vous utilisez l'API, vous indiquez l'OCID du compartiment approprié (la location ou d'autres compartiments) dans le cadre de la demande de création de la stratégie.
Stratégies et hiérarchies de compartiments
Comme décrit dans la section précédente, une instruction de stratégie doit indiquer le compartiment (ou la location) pour lequel l'accès est accordé. L'emplacement de création de la stratégie détermine les utilisateurs qui peuvent la mettre à jour. Si vous attachez la stratégie au compartiment ou à son parent, vous pouvez simplement indiquer le nom du compartiment. Si vous attachez la stratégie plus haut dans la hiérarchie, vous devez indiquer le chemin. Le format du chemin correspond au nom (ou à l'OCID) de chaque compartiment dans le chemin, séparés par le signe deux-points :
<compartment_level_1>:<compartment_level_2>: . . . <compartment_level_n>
Par exemple, supposons que vous disposez d'une hiérarchie de compartiment à trois niveaux, présentée ici :
Vous souhaitez créer une stratégie permettant à NetworkAdmins (dans le domaine d'identité par défaut) de gérer des réseaux cloud virtuels dans CompartmentC. Si vous voulez attacher cette stratégie à CompartmentC ou à son parent, CompartmentB, écrivez l'instruction de stratégie suivante :
Allow group default/NetworkAdmins to manage virtual-network-family in compartment CompartmentC
Cependant, si vous souhaitez attacher cette stratégie à CompartmentA (afin que seuls les administrateurs de CompartmentA puissent la modifier), écrivez l'instruction de stratégie suivante qui indique le chemin :
Allow group default/NetworkAdmins to manage virtual-network-family in compartment CompartmentB:CompartmentC
Pour attacher cette stratégie à la location, écrivez l'instruction de stratégie ci-dessous, qui indique le chemin de CompartmentA vers CompartmentC :
Allow group default/NetworkAdmins to manage virtual-network-family in compartment CompartmentA:CompartmentB:CompartmentC
Stratégies et mises à jour de service
Il est possible que la définition d'un verbe ou d'un type de ressource puisse être modifiée ultérieurement. Par exemple, imaginons que le type de ressource virtual-network-family
change afin d'inclure un nouveau type de ressource qui a été ajouté au service Networking. Par défaut, vos stratégies restent automatiquement à jour en tenant compte des modifications apportées à la définition de service. Ainsi, toute stratégie autorisant l'accès à virtual-network-family
inclura automatiquement l'accès à la nouvelle ressource.
Si un service introduit de nouveaux droits d'accès pour un type de ressource existant, vous devez mettre à jour l'instruction de stratégie pour ce type de ressource afin que les nouveaux droits d'accès prennent effet. Pour plus d'informations, reportez-vous à ces nouveaux droits d'accès dans les types de ressource ne sont pas propagés.
Ecriture de stratégies pour chaque service
La référence de stratégie inclut les détails des types spécifiques de ressource pour chaque service, ainsi que les combinaisons de verbe et de type de ressource donnant accès à chaque opération d'API.