Aperçu du service de gestion des identités et des accès

Le service GIA utilise les composants décrits dans cette section. Pour mieux comprendre la correspondance entre les composants, voir Exemple de scénario.

RESSOURCE

Objets en nuage que les employés de votre société créent et utilisent pour interagir avec Oracle Cloud Infrastructure. Par exemple : instances de calcul, volumes de stockage par blocs, réseaux en nuage virtuels, sous-réseaux, tables de routage, etc.

UTILISATEUR

Employé ou système individuel devant gérer ou utiliser les ressources Oracle Cloud Infrastructure de votre société. Les utilisateurs peuvent avoir besoin de lancer des instances, de gérer des disques distants, de travailler avec votre réseau en nuage virtuel, etc. En général, les utilisateurs finaux de votre application ne sont pas des utilisateurs du service GIA. Les utilisateurs ont une ou plusieurs données d'identification GIA (voir Données d'identification d'utilisateur).

GROUPE

Ensemble d'utilisateurs qui ont tous besoin du même type d'accès à un jeu de ressources ou un compartiment particulier.

GROUPE DYNAMIQUE

Type spécial de groupe contenant des ressources (telles que des instances de calcul) qui correspondent à des règles que vous avez définies (et qui peuvent donc changer de manière dynamique lorsque des ressources correspondantes sont créées ou supprimées). Ces instances agissent en tant qu'acteurs principaux et peuvent faire des appels d'API aux services selon les politiques que vous écrivez pour le groupe dynamique.

SOURCE DE RÉSEAU

Groupe d'adresses IP autorisées à accéder aux ressources de votre location. Les adresses IP peuvent être des adresses IP publiques ou des adresses IP d'un réseau en nuage virtuel dans votre location. Après avoir créé la source du réseau, vous utilisez une politique pour limiter l'accès aux demandes provenant des adresses IP de la source du réseau.

COMPARTIMENT

Collection de ressources connexes. Les compartiments sont des composants essentiels d'Oracle Cloud Infrastructure qui permettent d'organiser et d'isoler les ressources en nuage. Vous les utilisez pour séparer clairement les ressources en vue de la mesure de l'utilisation et de la facturation, de la gestion des accès (à l'aide de politiques) et de l'isolement (en séparant les ressources pour un projet ou une unité d'affaires). Une approche courante consiste à créer un compartiment pour chaque entité principale de l'organisation. Pour plus d'informations, voir Découvrir les meilleures pratiques pour la configuration de votre location.

LOCATION

Compartiment racine qui contient toutes les ressources Oracle Cloud Infrastructure de votre organisation. Oracle crée automatiquement la location de votre société pour vous. Directement dans la location se trouvent vos entités GIA (utilisateurs, groupes, compartiments et politiques). Vous pouvez également insérer des politiques dans des compartiments au sein de la location. Vous placez les autres types de ressource en nuage (instances, réseaux virtuels, volumes de stockage par blocs, etc.) dans les compartiments que vous créez.

POLITIQUE

Document spécifiant qui peut accéder à quelles ressources et comment. L'accès est accordé au niveau du groupe et du compartiment, ce qui signifie que vous pouvez écrire une politique qui donne à un groupe un type d'accès spécifique dans un compartiment spécifique ou à la location elle-même. Si vous accordez à un groupe l'accès à la location, celui-ci obtient automatiquement le même type d'accès à tous les compartiments de la location. Pour plus d'informations, voir Exemple de scénario et Fonctionnement des politiques. Le terme "politique" est utilisé de différentes façons : pour définir un énoncé individuel écrit dans le langage de politique, pour définir un ensemble d'énoncés dans un seul document, nommé "politique" (auquel un ID Oracle Cloud (OCID) est affecté) ou pour définir le corps global des politiques que votre organisation utilise pour contrôler l'accès aux ressources.

Lorsque vous appliquez une politique, il peut y avoir un léger délai avant l'entrée en vigueur de la politique.

RÉGION PRINCIPALE

Région où sont hébergées vos ressources GIA. Toutes les ressources GIA sont globales et disponibles dans toutes les régions, mais le jeu principal de définitions se trouve dans une seule région, la région principale. Vous devez modifier vos ressources GIA dans votre région principale. Les modifications sont propagées automatiquement dans toutes les régions. Pour plus d'informations, voir Gestion des régions.

FÉDÉRATION

Relation qu'un administrateur configure entre un fournisseur d'identités et un fournisseur de services. Lorsque vous procédez à une fédération entre Oracle Cloud Infrastructure et un fournisseur d'identités, vous gérez les utilisateurs et les groupes dans le fournisseur d'identités. Vous gérez l'autorisation dans le service IAM d'Oracle Cloud Infrastructure. Les locations Oracle Cloud Infrastructure sont fédérées avec Oracle Identity Cloud Service par défaut.

Vous pouvez écrire des politiques pour contrôler l'accès à tous les services dans Oracle Cloud Infrastructure.

Lorsque votre société s'inscrit à un compte Oracle et à un domaine d'identité, Oracle configure un administrateur par défaut pour le compte. Cette personne est le premier utilisateur du service GIA pour votre société. Il est responsable de la configuration initiale des autres administrateurs. Votre location est fournie avec un groupe appelé Administrateurs et l'administrateur par défaut appartient automatiquement à ce groupe. Vous ne pouvez pas supprimer ce groupe; il doit toujours comprendre au moins un utilisateur.

Votre location comporte également une politique qui donne au groupe Administrateurs un accès à toutes les opérations d'API pour Oracle Cloud Infrastructure et à toutes les ressources en nuage de votre location. Vous ne pouvez ni modifier ni supprimer cette politique. Tous les autres utilisateurs que vous affectez au groupe Administrateurs ont un accès complet à tous les services. Cela signifie qu'ils peuvent créer et gérer des ressources GIA, telles que des groupes, des politiques et des compartiments. Ils peuvent aussi créer et gérer des ressources en nuage, telles que des réseaux en nuage virtuels, des instances, des volumes de stockage par blocs, ainsi que d'autres types de ressource Oracle Cloud Infrastructure qui seront disponibles à l'avenir.

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 Utilisation des groupes. Pour savoir comment créer des utilisateurs et les placer dans des groupes, voir Utilisation des utilisateurs.

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 Utilisation 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 Pour créer une politique.

Important

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 tenancy

Notez 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 : Allow group Administrators to manage all-resources in tenancy 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 (en anglais seulement) Allow group A-Admins to manage all-resources in compartment Project-A Allow group B-Admins to manage all-resources in compartment Project-B 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 tenancy

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 : Allow group Administrators to manage all-resources in tenancy 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 (en anglais seulement) Allow group A-Admins to manage all-resources in compartment Project-A Allow group B-Admins to manage all-resources in compartment Project-B 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 tenancy

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.

Important

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 : Allow group Administrators to manage all-resources in tenancy 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 (en anglais seulement) Allow group A-Admins to manage all-resources in compartment Project-A Allow group B-Admins to manage all-resources in compartment Project-B 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 tenancy
	Politique jointe et gérée par Jorge : 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 use virtual-network-family in compartment Project-A
	Politique jointe et gérée par Cheri : 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 use virtual-network-family in compartment Project-B

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.

Dans la console, vous visualisez les ressources en nuage par compartiment. Autrement dit, après vous être connecté à la console, vous pouvez choisir le compartiment à utiliser (une liste des compartiments auxquels vous avez accès se trouve sur le côté gauche de la page). Notez que les compartiments peuvent être imbriqués les uns dans les autres. La page sera actualisée pour montrer les ressources du compartiment qui se trouvent dans la région courante. S'il n'y en a pas, ou si vous n'avez pas accès à la ressource dans ce compartiment, un message est affiché.

Cette expérience est différente selon que vous consultez les listes d'utilisateurs, de groupes, de groupes dynamiques ou de fournisseurs de fédération. Ces données se trouvent dans la location elle-même (le compartiment racine) et non dans un compartiment individuel.

Quant aux politiques, elles peuvent se trouver dans la location ou dans un compartiment, selon l'endroit où la politique est associée. L'endroit où elle est associée contrôle qui y a accès pour la modifier ou la supprimer. Pour plus d'informations, voir Association de politique.

Oracle Cloud Infrastructure utilise les concepts de régions et de domaines de disponibilité (voir Régions et domaines de disponibilité). Certaines ressources sont disponibles dans des régions, tandis que d'autres ne le sont que dans un domaine de disponibilité particulier. Les ressources GIA (utilisateurs, groupes, groupes dynamiques, compartiments, espaces de noms de marqueur, fournisseurs de fédération et politiques) sont globales et disponibles dans toutes les régions. Voir Gestion des régions.

Vous pouvez créer une automatisation en fonction des modifications d'état de vos ressources Oracle Cloud Infrastructure en utilisant des types d'événement, des règles et des actions. Pour plus d'informations, voir Aperçu des événements.

Les ressources GIA suivantes génèrent des événements :

• Politiques d'authentification
• Données d'identification
• Groupes dynamiques
• Groupes
• Fournisseurs d'identités
• Appareils TOTP pour l'authentification multifacteur
• Politiques
• Utilisateurs

La plupart des types de ressource Oracle Cloud Infrastructure ont un identificateur unique affecté par Oracle, appelé identificateur Oracle Cloud (OCID). Pour des informations sur le format des OCID et sur les autres moyens d'identifier vos ressources, voir Identificateurs de ressource.

Pour des informations générales sur l'utilisation de l'API, voir API REST.

Pour une liste des limites applicables et des instructions pour demander l'augmentation d'une limite, voir Limites de service. Pour définir des limites propres à un compartiment pour une ressource ou une famille de ressources, les administrateurs peuvent utiliser des quotas de compartiment.