Introduction aux politiques
Pour commencer, déterminez si vous devez vous familiariser avec les politiques et les questions courantes relatives aux politiques, et comment procéder.
Si vous débutez avec les politiques GIA, lisez cette rubrique qui décrit leur fonctionnement.
Si vous effectuez une démonstration de faisabilité
Créez un projet de démonstration de faisabilité avec des ressources d'infrastructure.
Si vous faites juste un essai d'Oracle Cloud Infrastructure ou si vous réalisez un projet de démonstration de faisabilité avec des ressources d'infrastructure, vous n'avez sans doute besoin que de quelques administrateurs disposant d'un accès complet à toutes les fonctions. Dans ce cas, vous pouvez simplement créer les nouveaux utilisateurs dont vous avez besoin et les ajouter au groupe Administrateurs. Les utilisateurs pourront effectuer toutes les opérations sur tous les types de ressource. Vous pouvez également créer toutes vos ressources directement dans la location (compartiment racine). Vous n'avez pas besoin de créer des compartiments pour le moment ou d'autres politiques au-delà de la politique d'administration du locataire, qui est automatiquement fournie avec votre location et ne peut pas être modifiée.
N'oubliez pas d'ajouter vos nouveaux utilisateurs au groupe Administrateurs, après les avoir créés.
Si vous avez passé la phase de démonstration de faisabilité
Restriction de l'accès aux ressources après la phase de démonstration de faisabilité.
Si vous avez passé la phase de démonstration de faisabilité et que vous voulez restreindre l'accès à vos ressources, tout d'abord :
- Assurez-vous de connaître les composants GIA de base, et lisez l'exemple de scénario : Exemple de scénario
- Réfléchissez à la manière d'organiser vos ressources dans des compartiments : Découvrir les meilleures pratiques pour la configuration de votre location
- Apprenez les bases du fonctionnement des politiques : Fonctionnement des politiques
- Passez en revue certaines politiques types : Politiques communes
- Lire la section suivante pour plus de détails.
Informations supplémentaires sur les politiques
Plus d'informations sur les politiques.
De tous, y compris le service GIA lui-même. Vous pouvez trouver des informations détaillées sur l'écriture de politiques pour chaque service dans Informations de référence sur les politiques.
Oui. Tous les utilisateurs peuvent effectuer automatiquement les opérations suivantes sans disposer d'une politique explicite :
- Modifier ou réinitialiser leur propre mot de passe pour la console.
- Gérer leurs propres clés de signature d'API et d'autres données d'identification.
Vous pouvez placer toutes vos ressources dans un compartiment unique et utiliser des politiques pour en contrôler l'accès. Toutefois, vous ne pourrez pas bénéficier des avantages liés à la mesure de l'utilisation et de la facturation par compartiment, à l'administration simplifiée des politiques au niveau du compartiment et à la séparation des ressources entre des projets ou des unités d'affaires.
Oui. Cependant, quelques points à savoir en premier :
- En général, les entreprises comptent plusieurs utilisateurs nécessitant des autorisations similaires, de sorte que les politiques sont conçues pour donner accès à des groupes d'utilisateurs, et non à des utilisateurs individuels. Un utilisateur obtient un accès en faisant partie d'un groupe.
- Les politiques sont conçues pour permettre l'accès, et il n'y a pas de refus explicite lors de l'écriture d'une politique.
Si vous devez accorder l'accès à un utilisateur particulier, vous pouvez ajouter à la politique une condition qui spécifie l'OCID de l'utilisateur dans une variable. Cette construction restreint l'accès accordé dans la politique aux utilisateurs indiqués 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 de conditions et de variables dans les politiques, voir Conditions.
Si vous devez restreindre l'accès d'un utilisateur particulier, vous pouvez :
- Retirer l'utilisateur du groupe qui vous intéresse
- Supprimer entièrement l'utilisateur du service IAM (vous devez d'abord le supprimer de tous les groupes)
Assurez-vous d'abord que l'utilisateur ne fait partie d'aucun groupe. Une fois cette vérification effectuée, vous pouvez supprimer l'utilisateur.
Vous devez consulter les énoncés individuels de toutes vos politiques pour voir quels énoncés s'appliquent à quel groupe. Actuellement, il n'existe pas de moyen plus facile d'obtenir ces informations.
Vous devez consulter les énoncés individuels de toutes les politiques de la location pour voir si l'un d'entre eux s'applique au compartiment. Vous devez également consulter toutes les politiques dans le compartiment lui-même. Les politiques d'un compartiment apparenté ne peuvent pas référencer le compartiment qui vous intéresse. Ainsi, vous n'avez pas besoin de vérifier ces politiques.
Présentation des politiques
Le service GIA utilise des politiques pour limiter l'accès aux ressources.
Par défaut, des politiques existent au niveau de la location et peuvent être appliquées aux domaines d'identité. Vous pouvez également créer des politiques avec une portée plus réduite, par exemple, en limitant l'accès à une ressource spécifique. Voir Fonctionnement des politiques.
Exemple de scénario
Exemples illustrant comment différents composants GIA fonctionnent ensemble.
Ce scénario présente le fonctionnement des différents composants GIA et les fonctions de base des politiques.
Dans ce scénario, la société Acme compte deux équipes qui utiliseront les ressources Oracle Cloud Infrastructure pour l'infrastructure : Project A et Project B. En pratique, votre société peut en avoir beaucoup plus.
La société Acme envisage d'utiliser un seul réseau en nuage virtuel (VCN) pour les deux équipes, et veut qu'il soit géré par un administrateur de réseau.
La société Acme veut également que l'équipe Project A et l'équipe Project B ait chacune leurs propres jeux d'instances et volumes de stockage par blocs. L'équipe Project A et l'équipe Project B ne doivent pas pouvoir utiliser les instances de l'autre équipe. En outre, ces deux équipes ne doivent pas être autorisées à modifier le réseau en nuage virtuel configuré par l'administrateur de réseau. La société Acme veut que chaque équipe ait ses administrateurs pour les ressources. Les administrateurs de l'équipe Project A peuvent décider qui peut utiliser les ressources en nuage de Project A et comment. Il en va de même pour l'équipe Project B.
La société Acme démarre avec Oracle Cloud Infrastructure
La société Acme s'inscrit pour utiliser 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 (voir le diagramme suivant).
- Crée un compte d'utilisateur GIA pour Wenpei dans la location.
- Crée le groupe Administrators dans la location et place Wenpei dans ce groupe.
- Crée une politique dans la location de la société Acme qui donne au groupe Administrators l'accès requis pour gérer toutes les ressources de la location. Voici cette politique :
Allow group Administrators to manage all-resources in tenancy
L'administrateur par défaut crée certains groupes et un autre administrateur.
Puis, Wenpei crée plusieurs groupes et utilisateurs (voir le diagramme suivant). Elle :
- Crée des groupes nommés NetworkAdmins, A-Admins et B-Admins (ces deux derniers sont pour Project A et Project B dans la société).
- Crée un utilisateur appelé Alex et le place dans le groupe Administrators.
- Laisse les nouveaux groupes vides.
Pour savoir comment créer des groupes, voir Gestion des groupes. Pour savoir comment créer des utilisateurs et les placer dans des groupes, voir Gestion des groupes.
L'administrateur par défaut crée des compartiments et des politiques
Wenpei crée ensuite des compartiments pour regrouper des ressources (voir le diagramme suivant). Elle :
- Crée un compartiment appelé Networks pour contrôler l'accès au VCN, aux sous-réseaux, au RPV site-à-site et aux autres composants du service Réseau de la société Acme.
- Crée un compartiment appelé Project-A pour organiser les ressources en nuage de l'équipe Project A et contrôler l'accès à ces ressources.
- Crée un compartiment appelé Project-B pour organiser les ressources en nuage de l'équipe Project B et contrôler l'accès à ces ressources.
Pour savoir comment gérer les compartiments, voir Gestion des compartiments.
Wenpei crée ensuite une politique pour donner aux administrateurs de chaque compartiment le niveau d'accès requis. Elle associe la politique à la location, ce qui signifie que seuls les utilisateurs disposant d'un accès pour gérer les politiques de la location pourront mettre à jour ou supprimer la politique. Dans ce scénario, il s'agit uniquement du groupe Administrators. La politique comporte plusieurs énoncés pour :
- Donner au groupe NetworkAdmins l'accès permettant de gérer les réseaux et les instances (à des fins de test du réseau) dans le compartiment Networks.
- Donner aux groupes A-Admins et B-Admins l'accès permettant d'utiliser les réseaux du compartiment Networks (afin qu'ils puissent créer des instances dans le réseau).
- Donner au groupe A-Admins l'accès permettant de gérer toutes les ressources dans le compartiment Project-A.
- Donner au groupe B-Admins l'accès permettant de gérer toutes les ressources dans le compartiment Project-B.
Voici à quoi ressemble la politique (notez qu'elle contient plusieurs énoncés) :
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
Notez la différence dans les verbes (manage, use) et les ressources (virtual-network-family, instance-family, all-resources). Pour plus d'informations, voir Verbes et Types de ressource. Pour savoir comment créer des politiques, voir Création d'une politique.
A-Admins et B-Admins peuvent utiliser la famille du réseau virtuel (virtual-network-family) du compartiment Networks. Toutefois, ils ne peuvent pas créer d'instances dans ce compartiment. Ils peuvent uniquement créer des instances dans le compartiment Project-A ou Project-B. Gardez à l'esprit qu'un compartiment est un regroupement logique, et non physique, de sorte que les ressources qui composent ou résident sur le même VCN peuvent appartenir à des compartiments différents.
La société Acme veut permettre aux administrateurs des compartiments Project-A et Project-B de décider quels utilisateurs peuvent utiliser les ressources de ces compartiments. Par conséquent, Wenpei crée deux groupes : A-Users et B-Users. Elle ajoute alors six énoncés supplémentaires qui donnent aux administrateurs de compartiments l'accès nécessaire pour ajouter et supprimer des utilisateurs de ces groupes :
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 tenancyNotez que cette politique ne permet pas aux administrateurs de projets de créer des utilisateurs ou de gérer les données d'identification des utilisateurs. Elle leur permet de choisir quels utilisateurs existants peuvent faire partie des groupes A-Users et B-Users. Les deux derniers énoncés sont nécessaires pour que A-Admins et B-Admins puissent lister tous les utilisateurs et groupes et confirmer quels utilisateurs font partie de quels groupes.
| Élément | Description |
|---|---|
 |
Politiques associées à la location :
|
Un administrateur crée de nouveaux utilisateurs
À ce stade, Alex est dans le groupe Administrators et peut maintenant créer de nouveaux utilisateurs. Il provisionne donc les utilisateurs nommés Leslie, Jorge et Cheri, et les place dans NetworkAdmins, A-Admins et B-Admins, respectivement. Alex crée également d'autres utilisateurs qui seront ultérieurement placés dans les groupes A-Users et B-Users par les administrateurs de Project A et Project B.
| Élément | Description |
|---|---|
|
Politiques associées à la location :
|
L'administrateur de réseau configure le 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 en nuage virtuel (VCN) avec un sous-réseau unique dans ce compartiment. Elle configure également une passerelle Internet pour le VCN et met à jour la table de routage du VCN pour permettre le trafic au moyen de cette passerelle. Pour tester la connectivité du VCN au réseau sur place, elle lance une instance du sous-réseau dans le VCN. Dans le cadre de la demande de lancement, elle doit spécifier dans quel compartiment doit résider l'instance. Elle indique le compartiment Networks, qui est le seul auquel elle ait accès. Elle vérifie ensuite la connectivité du réseau sur place au VCN en se connectant à l'instance au moyen de SSH à partir du réseau sur place.
Leslie met fin à son instance de test et indique à Jorge et Cheri que le VCN fonctionne et qu'il est prêt pour utilisation. Elle leur indique que leurs compartiments sont nommés Project-A et Project-B, respectivement. Pour plus d'informations sur la configuration d'un réseau en nuage, voir Service de réseau. Pour plus d'informations sur le lancement d'instances dans le réseau, voir Service de calcul.
Les administrateurs de compartiments configurent leurs compartiments
Jorge et Cheri doivent maintenant configurer leurs compartiments respectifs. Chaque administrateur doit effectuer les opérations suivantes :
- Lancer les instances dans son compartiment
- Placer des utilisateurs dans son groupe d'utilisateurs (par exemple, A-Users)
- Décider du type d'accès à octroyer à ces utilisateurs et associer en conséquence une politique à son compartiment
Jorge et Cheri lancent tous les deux des instances dans le sous-réseau du VCN, dans les compartiments respectifs de leur équipe. Ils créent et attachent des volumes par blocs aux instances. Seuls les administrateurs de compartiments peuvent lancer ou mettre fin à des instances ou attacher/détacher des volumes par blocs dans les compartiments de leur équipe.
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 VCN et le contrôle d'accès fourni par les compartiments. Du point de vue de la topologie réseau, les instances que Jorge a lancées se trouvent dans le VCN. Du point de vue de l'accès, elles se trouvent dans le compartiment Project-A, et non dans le compartiment Networks où se trouve le VCN. Leslie (l'administrateur de Networks) ne peut pas mettre fin aux instances de Jorge ni les redémarrer ou lancer de nouvelles instances dans le compartiment Project-A. Toutefois, Leslie contrôle le réseau des instances, de sorte qu'elle contrôle le trafic qui sera acheminé vers ces instances. Si Jorge avait spécifié le compartiment Networks au lieu du compartiment Project-A lors du lancement de ses instances, sa demande aurait été refusée. Le scénario est similaire pour Cheri et le compartiment Project-B.
Il convient également de noter que Wenpei et Alex du groupe Administrators ont accès aux ressources des compartiments, car ils ont accès à tous les types de ressource de la location. Les compartiments héritent de toutes les politiques associées à leur compartiment parent (la location). En conséquence, l'accès des administrateurs s'applique également à tous les compartiments de la location.
Jorge place ensuite plusieurs des utilisateurs qu'Alex a créés dans le groupe A-Users. Cheri fait de même pour B-Users.
Jorge écrit ensuite une politique 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
Ils peuvent ainsi utiliser des instances existantes (avec des volumes par blocs attachés) que les administrateurs de compartiments ont déjà lancées dans le compartiment, et les arrêter, les démarrer ou les redémarrer. Cela ne permet pas aux utilisateurs de A-Users de créer, de supprimer, d'attacher ou de détacher des volumes. Pour que cela soit possible, la politique devrait inclure manage volume-family.
Jorge associe cette politique au compartiment Project-A. Toute personne pouvant gérer les politiques dans le compartiment peut maintenant modifier ou supprimer cette politique. Actuellement, seul le groupe A-Admins peut le faire (et le groupe Administrators qui peut tout faire dans toute la location).
Cheri crée et associe sa propre politique au compartiment Project-B, similaire à celle de Jorge :
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
Maintenant, les groupes A-Users et B-Users peuvent utiliser les instances existantes et les volumes attachés dans les compartiments Project-A et Project-B, respectivement. Voici à quoi ressemble la présentation :
| Élément | Description |
|---|---|
|
Politiques associées à la location :
|
 |
Politique jointe et gérée par Jorge :
|
 |
Politique jointe et gérée par Cheri :
|
Pour plus d'informations sur les fonctions de base et avancées liées aux politiques, voir Fonctionnement des politiques. Pour obtenir des exemples d'autres politiques types que votre organisation pourrait utiliser, voir Politiques communes.
Autoriser les administrateurs de sauvegardes à gérer uniquement les sauvegardes.
Type d'accès : Permet d'effectuer toutes les opérations liées aux sauvegardes de volume, mais pas de créer et de gérer les volumes eux-mêmes. Ce type d'accès est adapté si vous voulez qu'un seul ensemble d'administrateurs de sauvegardes de volume gère toutes les sauvegardes de volume dans tous les compartiments. Le premier énoncé donne l'accès requis au volume en cours de sauvegarde; le deuxième énoncé permet la création de la sauvegarde (et la possibilité de supprimer des sauvegardes). Le troisième énoncé permet la création et la gestion des politiques de sauvegarde définies par l'utilisateur; le quatrième énoncé permet l'affectation et la suppression des politiques de sauvegarde.
Où créer la politique : Dans la location, de sorte que l'accès soit facilement accordé à tous les compartiments au moyen de l'héritage des politiques. Pour réduire la portée de l'accès aux volumes et 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 politique suivante assure 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 derniers énoncés ne sont pas nécessaires pour gérer les sauvegardes de volume. Toutefois, ils permettent à la console d'afficher toutes les informations sur un volume particulier, ainsi que les politiques de sauvegarde disponibles.
Association de politique
Attachements 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 l'associez détermine qui peut la modifier ou la supprimer. Si vous l'associez à la location (autrement dit, 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. Un utilisateur qui ne peut accéder qu'à un compartiment enfant ne peut 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'accorder aux administrateurs du compartiment (c'est-à-dire un groupe autorisé à gérer toutes les resources (manage all-resources) du compartiment) un accès pour qu'ils puissent 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. (Gardez à l'esprit 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'association de politique est facile (que la politique soit associée à un compartiment ou à la location) : Si vous utilisez la console, lorsque vous ajoutez la politique au service GIA, assurez-vous de vous trouver dans le compartiment voulu lorsque vous créez la politique. Si vous utilisez l'API, vous spécifiez l'OCID du compartiment souhaité (la location ou un autre compartiment) dans le cadre de la demande pour créer la politique.
Lorsque vous associez une politique à un compartiment, vous devez vous trouver dans ce compartiment et vous devez indiquer directement dans l'énoncé à quel compartiment elle s'applique. Si vous n'êtes pas dans le compartiment, vous verrez s'afficher un message d'erreur si vous tentez d'associer la politique à un autre compartiment. Notez que l'association se produit lors de la création de la politique, ce qui signifie qu'une politique ne peut être associée qu'à un seul compartiment. Pour apprendre à associer une politique à un compartiment, voir Création d'une politique.