Introduction aux stratégies
Déterminez en premier lieu si vous devez vous lancer avec les stratégies et, le cas échéant, de quelle façon, puis familiarisez-vous avec les questions courantes sur les stratégies.
Si vous ne connaissez pas encore les stratégies IAM, cette rubrique vous indique comment procéder.
Si vous réalisez une étude de faisabilité
Créez un projet validation de concept avec des ressources d'infrastructure.
Si vous essayez simplement Oracle Cloud Infrastructure ou si vous réalisez un projet d'étude de faisabilité avec des ressources d'infrastructure, quelques administrateurs avec un accès total peuvent suffire. Dans ce cas, vous pouvez simplement créer les utilisateurs dont vous avez besoin et les ajouter au groupe d'administrateurs. Les utilisateurs pourront effectuer toutes les opérations sur tout type de ressource. Vous pouvez également créer toutes vos ressources directement dans la location (compartiment racine). Vous n'avez pas encore besoin de créer de compartiments, ni d'autres stratégies à part la stratégie d'administration de locataires, qui est fournie automatiquement avec votre location et ne peut pas être modifiée.
N'oubliez pas d'ajouter vos nouveaux utilisateurs au groupe d'administrateurs ; il est facile d'oublier de le faire après les avoir créés.
Si vous avez passé la phase d'étude de faisabilité
Restreindre l'accès aux ressources après la phase de validation de concept.
Si vous avez passé la phase d'étude de faisabilité et souhaitez limiter l'accès à vos ressources, commencez par effectuer les actions suivantes :
- Assurez-vous que vous connaissez les composants de base d'IAM et lisez l'exemple de scénario : Exemple de scénario.
- Réfléchissez à l'organisation de vos ressources en compartiments : En savoir plus sur les meilleures pratiques pour configurer votre location.
- Découvrez les bases du fonctionnement des stratégies : Fonctionnement des stratégies.
- Etudiez certaines stratégies standard : Stratégies courantes.
- Pour plus d'informations, reportez-vous à la section suivante.
Informations complémentaires sur les stratégies
Informations complémentaires sur les stratégies.
Tous les services, y compris IAM. Vous trouverez des détails spécifiques sur l'écriture des stratégies pour chaque service dans la référence de stratégie.
Oui. Tous les utilisateurs peuvent automatiquement effectuer les opérations suivantes sans stratégie explicite :
- Modifier ou réinitialiser leur propre mot de passe de console.
- Gérer leurs propres clés de signature d'API et d'autres informations d'identification.
Vous pouvez placer toutes vos ressources dans un seul compartiment et utiliser des stratégies pour contrôler l'accès, mais vous perdrez les avantages de la mesure de l'utilisation et de la facturation par compartiment, de l'administration simplifiée des stratégies au niveau du compartiment et de la séparation claire des ressources en fonction des projets ou des unités opérationnelles.
Oui. Cependant, vous devez d'abord connaître quelques éléments :
- Les sociétés disposent généralement de plusieurs utilisateurs qui ont besoin de droits d'accès similaires : les stratégies sont donc conçues pour donner accès à des groupes d'utilisateurs et non à des utilisateurs individuels. Un utilisateur obtient un accès parce qu'il appartient à un groupe.
- Les stratégies sont conçues pour autoriser l'accès et il n'existe aucun refus explicite lorsque vous les écrivez.
Si vous devez accorder l'accès à un utilisateur en particulier, vous pouvez ajouter à la stratégie une condition spécifiant l'OCID de l'utilisateur dans une variable. Cette construction restreint l'accès octroyé par la stratégie à l'utilisateur indiqué dans la condition. Par exemple :
allow any-group to read object-family in compartment ObjectStorage where request.user.id ='ocid1.user.oc1..<user_OCID>'Pour plus d'informations sur l'utilisation des conditions et des variables dans les stratégies, reportez-vous à Conditions.
Si vous avez besoin de limiter l'accès d'un utilisateur particulier, vous pouvez :
- retirer l'utilisateur du groupe en question,
- supprimer entièrement l'utilisateur d'IAM (vous devez d'abord enlever l'utilisateur de tous les groupes).
Assurez-vous d'abord que l'utilisateur ne fait partie d'aucun groupe. Ce n'est qu'ensuite qu'il peut être supprimé.
Reportez-vous à Suppression d'un compartiment.
Vous devez examiner les instructions individuelles de toutes vos stratégies pour connaître celles qui s'appliquent à chaque groupe. Il n'existe actuellement aucun moyen simple d'obtenir ces informations.
Vous devez examiner les instructions individuelles dans toutes les stratégies de la location pour voir si certaines s'appliquent au compartiment en question. Vous devez également examiner les stratégies du compartiment. Les stratégies dans les compartiments semblables ne peuvent pas faire référence au compartiment en question, vous n'avez donc pas besoin de les vérifier.
Présentation des stratégies
IAM utilise des stratégies pour restreindre l'accès aux ressources.
Par défaut, les stratégies existent au niveau de la location et peuvent être appliquées aux domaines d'identité. Vous pouvez également créer des stratégies avec une portée plus petite, par exemple, en limitant l'accès à une ressource spécifique. Reportez-vous à Fonctionnement des stratégies.
Exemple de scénario
Exemples illustrant comment différents composants IAM fonctionnent ensemble.
L'objectif de ce scénario est de montrer comment les différents composants d'IAM fonctionnent ensemble, et de présenter les fonctionnalités de base des stratégies.
Dans ce scénario, la société Acme a deux équipes qui utiliseront des ressources Oracle Cloud Infrastructure pour l'infrastructure : le projet A et le projet B. En réalité, il se peut que votre société en ait davantage.
La société Acme prévoit d'utiliser un seul réseau cloud virtuel pour les deux équipes et souhaite un administrateur réseau pour le gérer.
La société Acme souhaite également que l'équipe du projet A et celle du projet B disposent chacune de son propre ensemble d'instances et de volumes de stockage de blocs. L'équipe du projet A et celle du projet B ne doivent pas pouvoir utiliser les instances de l'autre équipe. Ces deux équipes ne doivent pas non plus être autorisées à modifier tout élément du réseau cloud virtuel configuré par l'administrateur réseau. La société Acme souhaite que chaque équipe possède des administrateurs pour ses propres ressources. Les administrateurs de l'équipe du projet A peuvent déterminer qui peut utiliser les ressources cloud du projet A et de quelle manière. Il en va de même pour l'équipe du projet B.
Introduction à Oracle Cloud Infrastructure pour la société Acme
La société Acme s'inscrit à Oracle Cloud Infrastructure et indique à Oracle qu'une employée nommée Wenpei sera l'administrateur par défaut. En réponse, Oracle :
- crée une location pour la société Acme (reportez-vous au diagramme suivant),
- crée un compte utilisateur IAM pour Wenpei dans la location,
- crée le groupe Administrators dans la location et place Wenpei dans ce groupe,
- crée une stratégie dans la location de la société Acme qui donne au groupe Administrators les droits d'accès pour gérer toutes les ressources de la location. Voici cette stratégie :
Allow group Administrators to manage all-resources in tenancy
Création de groupes et d'un autre administrateur par l'administrateur par défaut
Wenpei crée ensuite plusieurs groupes et utilisateurs (reportez-vous au diagramme suivant). Elle :
- crée des groupes appelés NetworkAdmins, A-Admins et B-Admins (ces deux derniers sont respectivement pour le projet A et le projet B dans la société),
- crée un utilisateur appelé Alex et le place dans le groupe Administrators,
- laisse les nouveaux groupes vides.
Pour plus d'informations sur la création de groupes, reportez-vous à Gestion des groupes. Pour apprendre à créer des utilisateurs et à les placer dans des groupes, reportez-vous à Gestion des utilisateurs.
Création de compartiments et de stratégies par l'administrateur par défaut
Wenpei crée ensuite des compartiments pour regrouper les ressources (reportez-vous au diagramme suivant). Elle :
- crée un compartiment appelé Networks pour contrôler l'accès au réseau cloud virtuel, aux sous-réseaux, au VPN site à site et aux autres composants de la société Acme à partir de Networking,
- crée un compartiment nommé Project-A pour organiser les ressources cloud de l'équipe du projet A et contrôler l'accès à ces dernières,
- crée un compartiment nommé Project-B pour organiser les ressources cloud de l'équipe du projet B et contrôler l'accès à ces dernières.
Pour découvrir comment gérer des compartiments, reportez-vous à Gestion des compartiments.
Wenpei crée ensuite une stratégie qui donne aux administrateurs de chaque compartiment le niveau d'accès requis. Elle attache la stratégie à la location, ce qui signifie que seuls les utilisateurs autorisés à gérer des stratégies dans la location peuvent la mettre à jour ou la supprimer ultérieurement. Dans ce scénario, il s'agit uniquement du groupe Administrators. La stratégie comprend plusieurs instructions qui :
- permettent au groupe NetworkAdmins de gérer les réseaux et les instances (afin de tester facilement le réseau) dans le compartiment Networks,
- permettent aux groupes A-Admins et B-Admins d'utiliser les réseaux du compartiment Networks (afin qu'ils puissent créer des instances dans le réseau),
- permettent au groupe A-Admins de gérer toutes les ressources dans le compartiment Project-A,
- permettent au groupe B-Admins de gérer toutes les ressources dans le compartiment Project-B.
Voici à quoi ressemble cette stratégie (elle contient plusieurs instructions) :
Allow group NetworkAdmins to manage virtual-network-family in compartment Networks
Allow group NetworkAdmins to manage instance-family in compartment Networks
Allow group A-Admins,B-Admins to use virtual-network-family in compartment Networks
Allow group A-Admins to manage all-resources in compartment Project-A
Allow group B-Admins to manage all-resources in compartment Project-B
Prêtez attention à la différence entre les verbes (manage, use) et les ressources (virtual-network-family, instance-family, all-resources). Pour plus d'informations sur ces éléments, reportez-vous à Verbes et à Types de ressource. Pour savoir comment créer des stratégies, reportez-vous à Création d'une stratégie.
A-Admins et B-Admins peuvent utiliser virtual-network-family dans le compartiment Networks. Cependant, ils ne peuvent pas créer d'instances dans ce compartiment. Ils peuvent en créer uniquement dans le compartiment Project-A ou Project-B. N'oubliez pas qu'un compartiment est un regroupement logique, et non physique. Ainsi, les ressources qui composent le réseau cloud virtuel ou qui résident sur le même réseau cloud virtuel peuvent appartenir à des compartiments différents.
La société Acme souhaite autoriser les administrateurs des compartiments Project-A et Project-B à déterminer quels utilisateurs peuvent utiliser les ressources contenues. Wenpei crée donc deux groupes supplémentaires : A-Users et B-Users. Elle ajoute alors six instructions supplémentaires qui donnent aux administrateurs de compartiment l'accès requis pour ajouter des utilisateurs à ces groupes ou en supprimer :
Allow group A-Admins to use users in tenancy where target.group.name='A-Users'
Allow group A-Admins to use groups in tenancy where target.group.name='A-Users'
Allow group B-Admins to use users in tenancy where target.group.name='B-Users'
Allow group B-Admins to use groups in tenancy where target.group.name='B-Users'
Allow group A-Admins,B-Admins to inspect users in tenancy
Allow group A-Admins,B-Admins to inspect groups in tenancyCette stratégie ne permet pas aux administrateurs de projet de créer des utilisateurs ou de gérer les informations d'identification de ces derniers. Elle leur permet de choisir parmi les utilisateurs existants ceux qui peuvent appartenir au groupe A-Users et ceux qui peuvent appartenir au groupe B-Users. Les deux dernières instructions sont nécessaires pour que les groupes A-Admins et B-Admins puissent répertorier tous les utilisateurs et les groupes, et vérifier quels utilisateurs appartiennent à quels groupes.
| Elément | Description |
|---|---|
 |
Stratégies attachées à la location :
|
Création d'utilisateurs par un administrateur
A ce stade, Alex appartient au groupe Administrators et peut désormais créer des utilisateurs. Il provisionne les utilisateurs nommés Leslie, Jorge et Cheri, et les place respectivement dans les groupes NetworkAdmins, A-Admins et B-Admins. Alex crée également d'autres utilisateurs qui seront ensuite placés dans les groupes A-Users et B-Users par les administrateurs du projet A et du projet B.
| Elément | Description |
|---|---|
|
Stratégies attachées à la location :
|
Configuration du réseau par l'administrateur réseau
Leslie (dans le groupe NetworkAdmins) peut gérer virtual-network-family et instance-family dans le compartiment Networks. Elle crée un réseau cloud virtuel avec un seul sous-réseau dans ce compartiment. Elle configure également une passerelle Internet pour le réseau cloud virtuel et met à jour la table de routage de ce dernier afin d'autoriser le trafic via cette passerelle. Pour tester la connectivité du réseau cloud virtuel au réseau sur site, elle lance une instance dans le sous-réseau du réseau cloud virtuel. Dans le cadre de la demande de lancement, elle doit indiquer le compartiment dans lequel l'instance doit résider. Elle indique le compartiment Networks, le seul auquel elle a accès. Elle vérifie ensuite la connectivité entre le réseau sur site et le réseau cloud virtuel en se connectant à l'instance via SSH à partir du réseau sur site.
Leslie met fin à son instance de test, et informe Jorge et Cheri du fait que le réseau cloud virtuel fonctionne et qu'il peut être utilisé. Elle indique à chacun le nom de son compartiment : Project-A et Project-B, respectivement. Pour plus d'informations sur la configuration d'un réseau cloud, reportez-vous à Networking. Pour plus d'informations sur le lancement d'instances dans le réseau, reportez-vous à Compute.
Configuration des compartiments par les administrateurs de compartiment
Jorge et Cheri doivent désormais configurer leur compartiment respectif. Chaque administrateur doit effectuer les opérations suivantes :
- Lancer des instances dans son propre compartiment
- Placer les utilisateurs dans son groupe d'utilisateurs (par exemple, A-Users)
- Déterminer le type d'accès à accorder à ces utilisateurs et attacher une stratégie à son compartiment en conséquence
Jorge et Cheri lancent les instances dans le sous-réseau du réseau cloud virtuel, dans le compartiment de leur équipe respective. Ils créent et attachent des volumes de blocs aux instances. Seuls les administrateurs de compartiment peuvent lancer des instances ou y mettre fin, ou attacher/détacher des volumes de blocs dans le compartiment de leur équipe respective.
La topologie réseau et l'accès au compartiment sont des concepts différents
Il est important de comprendre la différence entre la topologie réseau du réseau cloud virtuel et le contrôle d'accès fourni par les compartiments. Du point de vue de la topologie réseau, les instances lancées par Jorge résident dans le réseau cloud virtuel. Cependant, du point de vue de l'accès, elles se trouvent dans le compartiment Project-A, et non dans le compartiment Networks dans lequel réside le réseau cloud virtuel. Leslie (l'administrateur du compartiment Networks) ne peut pas mettre fin aux instances de Jorge ou les redémarrer, ni en lancer de nouvelles dans le compartiment Project-A. Toutefois, elle contrôle le réseau des instances, et par conséquent également le trafic qui leur sera acheminé. Si Jorge avait indiqué le compartiment Networks au lieu du compartiment Project-A lors du lancement de ses instances, sa demande aurait été refusée. Il en va de même pour Cheri et le compartiment Project-B.
Toutefois, il est également important de noter que Wenpei et Alex dans le groupe Administrators ont accès aux ressources contenues dans les compartiments, car ils disposent des droits d'accès pour gérer tous les types de ressource dans la location. Les compartiments héritent de toutes les stratégies attachées à leur compartiment parent (location) : les administrateurs peuvent donc également accéder à tous les compartiments contenus dans la location.
Ensuite, Jorge place plusieurs utilisateurs créés par Alex dans le groupe A-Users. Cheri effectue les mêmes opérations pour B-Users.
Ensuite, Jorge écrit une stratégie qui donne aux utilisateurs le niveau d'accès dont ils ont besoin dans le compartiment Project-A.
Allow group A-Users to use instance-family in compartment Project-A
Allow group A-Users to use volume-family in compartment Project-A
Allow group A-Users to inspect virtual-network-family in compartment Networks
Cela leur permet d'utiliser des instances existantes (avec des volumes de blocs attachés) que les administrateurs de compartiment ont déjà lancées dans le compartiment, et de les arrêter/démarrer/redémarrer. Elle ne permet pas aux utilisateurs du groupe A-Users de créer, de supprimer, d'attacher ou de détacher des volumes. Pour cela, la stratégie doit inclure manage volume-family.
Jorge attache cette stratégie au compartiment Project-A. Toute personne pouvant gérer les stratégies dans le compartiment peut désormais modifier ou supprimer cette stratégie. Actuellement, il s'agit uniquement du groupe A-Admins (et du groupe Administrators, qui peut effectuer toutes les opérations dans l'ensemble de la location).
Cheri crée et attache sa propre stratégie, semblable à celle de Jorge, au compartiment Project-B :
Allow group B-Users to use instance-family in compartment Project-B
Allow group B-Users to use volume-family in compartment Project-B
Allow group B-Users to inspect virtual-network-family in compartment Networks
Les utilisateurs des groupes A-Users et B-Users peuvent désormais utiliser les instances et les volumes attachés existants dans les compartiments Project-A et Project-B, respectivement. Voici comment se présente la disposition :
| Elément | Description |
|---|---|
|
Stratégies attachées à la location :
|
 |
Stratégie attachée et gérée par Jorge :
|
 |
Stratégie attachée et gérée par Cheri :
|
Pour plus d'informations sur les fonctionnalités de base et avancées des stratégies, reportez-vous à Fonctionnement des stratégies. Pour consulter des exemples d'autres stratégies standard que votre organisation peut utiliser, reportez-vous à Stratégies courantes.
Autoriser les administrateurs de sauvegarde à gérer uniquement des sauvegardes.
Type d'accès : permet de tout faire avec les sauvegardes de volume mais pas de créer ni de gérer les volumes eux-mêmes. Cette stratégie est utile si vous souhaitez qu'un seul ensemble d'administrateurs de sauvegarde de volume gère toutes les sauvegardes de volume dans tous les compartiments. La première instruction donne l'accès requis au volume en cours de sauvegarde. La deuxième permet de créer la sauvegarde (et donne la possibilité de supprimer des sauvegardes). La troisième instruction permet de créer et de gérer des stratégies de sauvegarde définies par l'utilisateur. La quatrième permet d'affecter et d'enlever l'affectation des stratégies de sauvegarde.
Emplacement de création de la stratégie : dans la location, pour que l'accès soit facilement accordé à tous les compartiments par le biais de l'héritage de stratégies. Pour limiter la portée de l'accès uniquement aux volumes et aux sauvegardes d'un compartiment particulier, indiquez ce compartiment au lieu de la location.
Allow group VolumeBackupAdmins to use volumes in tenancy
Allow group VolumeBackupAdmins to manage volume-backups in tenancy
Allow group VolumeBackupAdmins to manage backup-policies in tenancy
Allow group VolumeBackupAdmins to manage backup-policy-assignments in tenancySi le groupe doit utiliser la console, la stratégie suivante offre une meilleure expérience utilisateur :
Allow group VolumeBackupAdmins to use volumes in tenancy
Allow group VolumeBackupAdmins to manage volume-backups in tenancy
Allow group VolumeBackupAdmins to inspect volume-attachments in tenancy
Allow group VolumeBackupAdmins to inspect instances in tenancy
Allow group VolumeBackupAdmins to manage backup-policies in tenancy
Allow group VolumeBackupAdmins to manage backup-policy-assignments in tenancyLes deux dernières instructions ne sont pas nécessaires pour gérer des sauvegardes de volume. Toutefois, elles permettent à la console d'afficher toutes les informations sur un volume particulier et les stratégies de sauvegarde disponibles.
Attachement de stratégie
Attachements 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). Le compartiment auquel vous l'attachez détermine les personnes pouvant la modifier ou la supprimer. Si vous l'attachez à la location (en d'autres termes, 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 (à savoir, 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. (Rappelez-vous que, en raison de l'héritage de stratégie, les utilisateurs autorisés à gérer les stratégies dans la location peuvent automatiquement gérer celles des 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 compartiment souhaité lors de la création de la stratégie. Si vous utilisez l'API, vous indiquez l'OCID du compartiment souhaité (la location ou un autre compartiment) dans le cadre de la demande de création de la stratégie.
Lorsque vous attachez une stratégie à un compartiment, vous devez vous trouver dans ce compartiment et indiquer directement dans l'instruction à quel compartiment elle s'applique. Si vous n'êtes pas dans le compartiment, vous obtiendrez une erreur lorsque vous essayerez d'attacher la stratégie à un autre compartiment. L'attachement a lieu lors de la création de la stratégie, ce qui signifie qu'une stratégie ne peut être attachée qu'à un seul compartiment. Pour savoir comment associer une stratégie à un compartiment, reportez-vous à Création d'une stratégie.