Meilleures pratiques pour l'organisation des ressources et l'affectation d'accès

Après avoir configuré votre compte IBM Cloud®, vous êtes prêt à planifier l'organisation des ressources Une instance physique ou logique qui peut être provisionnée ou réservée.Les ressources peuvent inclure, par exemple, le stockage, les processeurs, la mémoire, les bases de données, les clusters et les machines virtuelles. et l'attribution des accès aux identités dans votre compte. Les meilleures pratiques décrites ci-après sont les éléments de base qui vous permettront de développer en toute sécurité des applications dans IBM Cloud.

Les meilleures pratiques décrites ci-après concernent essentiellement les ressources qui sont activées pour IBM Cloud Identity and Access Management (IAM) et qui sont affectées à des groupes de ressources. Les services d'infrastructure classiques ne sont pas activés par IAM, ce qui signifie qu'ils ne peuvent pas être affectés à des groupes de ressources.

Qu'est-ce qu'une bonne stratégie de groupe de ressources ?

Utilisez des groupes de ressources pour organiser vos ressources de compte à des fins de contrôle d'accès et de facturation.

Les administrateurs peuvent avoir un meilleur contrôle de l'utilisation des ressources au niveau de l'environnement de projet si un groupe de ressources par environnement de projet est utilisé. Par exemple, un projet typique comprend des environnements de développement, de test et de production. Un projet nommé CustApp pourrait comporter les groupes de ressources suivants :

CustApp-Dev
CustApp-Test
CustApp-Prod

Dans ce scénario, vous pouvez attribuer à un développeur un accès étendu au groupe de ressources de développement et un accès beaucoup plus restreint, voire inexistant, au groupe de ressources de production.

Organisation des ressources dans des groupes de ressources

Toutes les ressources gérées à l'aide du contrôle d'accès IAM appartiennent à un groupe de ressources. Vous affectez une ressource à son groupe de ressources lorsque vous le créez à partir du catalogue. Il est important de créer vos groupes de ressources en premier car vous ne pouvez pas modifier l'affection des ressources une fois que vous l'avez définie. Si vous affectez par erreur une ressource au groupe de ressources incorrect, supprimez la ressource et créez-en une nouvelle.

Un groupe de ressources par défaut est créé pour votre compte. Si vous possédez un compte Lite, vous ne pouvez utiliser qu'un seul groupe de ressources. Si vous souhaitez créer plusieurs groupes de ressources, effectuez une mise à niveau vers un compte Paiement à la carte ou Abonnement.

Recherche de ressources

Vous pouvez utiliser des étiquettes utilisateur pour faciliter l'organisation et la recherche des ressources dans votre compte. Vous pouvez également utiliser des étiquettes d'utilisateur pour vous aider à identifier l'utilisation d'une équipe spécifique ou la répartition des coûts lorsque vous consultez vos Exportation de vos détails d'utilisation vers un fichier CSV.

Pour plus d'informations, voir Utilisation d'étiquettes.

Fonctionnement de l'accès IAM

Une fois que vous avez configuré et organisé des groupes de ressources dans votre compte, vous pouvez tirer parti de deux stratégies pour rationaliser le processus de gestion des accès :

Groupes d'accès: Vous pouvez gérer au minimum le nombre de règles affectées en donnant le même accès à toutes les identités dans un groupe d'accès au lieu d'attribuer le même accès plusieurs fois par utilisateur, par ID de service ou par profil sécurisé. Les utilisateurs doivent être invités dans votre compte pour que vous puissiez les ajouter à un groupe d'accès. Si un utilisateur est qualifié pour un profil de confiance qui est membre du groupe d'accès, vous n'avez pas besoin de l'inviter à votre compte.
Profils sécurisés: Si votre organisation possède un annuaire d'entreprise, les profils sécurisés peuvent accélérer et faciliter la gestion des accès. Cela simplifie le processus de connexion à votre compte IBM Cloud pour les utilisateurs fédérés de votre entreprise. Vous pouvez automatiquement octroyer aux utilisateurs fédérés ou aux ressources de calcul l'accès à votre compte en créant des profils sécurisés. Pour les utilisateurs fédérés, ajoutez des conditions en fonction d'attributs SAML pour définir les utilisateurs fédérés qui peuvent appliquer un profil. Pour les ressources de calcul, spécifiez des ressources spécifiques ou ajoutez des conditions en fonction d'attributs de ressource pour définir les ressources de calcul qui peuvent appliquer un profil. Pour les deux types d'entité, le niveau d'accès accordé est déterminé par les règles d'accès qui sont spécifiées dans chaque profil sécurisé, ou par les groupes d'accès dont le profil sécurisé est membre. Toutefois, avec les profils sécurisés, il n'est pas nécessaire d'inviter les utilisateurs fédérés à rejoindre un compte et seuls les utilisateurs fédérés par un fournisseur d'identité externe peuvent appliquer un profil sécurisé.

Si vous êtes membre de plusieurs groupes d'accès, toutes les règles s'appliquent en même temps lorsque vous accédez à un compte. En tant qu'utilisateur fédéré, vous avez la possibilité d'appliquer différents profils sécurisés, mais vous ne sélectionnez qu'un seul profil à appliquer lorsque vous vous connectez. Par exemple, si vous souhaitez effectuer des tâches liées au développement, sélectionnez le profil Developer lorsque vous vous connectez. Si vous souhaitez effectuer une tâche liée à l'administrateur, sélectionnez le profil Admin disposant de droits d'accès privilégiés. De cette manière, vous réduisez le risque d'effectuer des actions privilégiées par erreur.

Une règle est composée d'un sujet, d'une cible et d'un rôle. Le sujet de ce scénario est le groupe d'accès ou le profil sécurisé. La cible est ce à quoi le sujet doit pouvoir accéder, par exemple, un ensemble de ressources d'un groupe de ressources, une instance de service, tous les services du compte ou toutes les instances d'un service. Le rôle définit le niveau d'accès qui est octroyé.

Le diagramme suivant illustre le fonctionnement d'une stratégie d'accès:

Les rôles les plus fréquemment utilisés sont les rôles de plateforme Afficheur, Editeur, Opérateur et Administrateur.

Le rôle Afficheur fournit l'accès minimum et permet d'afficher des instances et des groupes de ressources dans un compte.
Le rôle d'opérateur comprend des actions telles que la possibilité de visualiser les instances et de gérer les informations d'identification.
Le rôle Editeur inclut les mêmes actions que celle du rôle Opérateur, mais également d'autres actions permettant de créer, d'éditer, de supprimer et de lier des instances de service.
Le rôle Administrateur comprend tout ce qui permet de gérer une instance de service et d'affecter un accès aux autres utilisateurs pour le service ou l'instance auxquels la règle s'applique.

Bien qu'il s'agisse des rôles les plus populaires permettant d'affecter un accès dans la plateforme, il existe un deuxième ensemble de rôles à prendre en compte, appelés rôles de service. Les actions mappées à ces rôles sont définies par chaque service. Généralement, les actions mappées à ces rôles font spécifiquement référence à la possibilité de gérer les API et l'interface utilisateur d'un service.

Pour plus d'informations sur les rôles pouvant être affectés, voir Rôles IAM.

Réduction du temps et des efforts dédiés à la gestion des accès

Le nombre total de règles autorisées sur un compte est limité. Vous pouvez utiliser quelques stratégies pour éviter d'atteindre la limite et pour réduire le temps passé à gérer les accès pour les identités dans votre compte (utilisateurs, ID de service ou profils sécurisés) :

Utilisez le principe du moindre privilège et affectez uniquement l'accès qui est nécessaire. Ainsi, vous garantissez que les identités dans votre compte ne peuvent effectuer que les actions que vous autorisez. Par exemple, les conditions basées sur le temps pour les règles d'accès n'accordent l'accès que pendant le délai que vous spécifiez, ce qui réduit les possibilités d'attaque en cas de violation de la sécurité. Pour plus d'informations, voir Limitation de l'accès avec des conditions temporelles.
Ajoutez des ressources à un groupe de ressources pour réduire davantage le nombre de règles requises. Par exemple, une équipe peut travailler sur un projet qui utilise des ressources spécifiques dans votre compte. Ajoutez les membres de l'équipe à un groupe d'accès ou un profil sécurisé avec une règle qui n'octroie l'accès qu'aux ressources d'un groupe de ressources spécifique. Ainsi, il n'est pas nécessaire d'affecter une règle à chaque ressource pour chaque membre d'équipe.
Utilisez des groupes d'accès afin de simplifier la gestion des accès pour les identités qui nécessitent le même niveau d'accès. Vous pouvez configurer un groupe d'accès pour lequel une règle spécifique est définie, puis ajouter ces identités au groupe. Si les membres du groupe nécessitent un accès supplémentaire ultérieurement, il suffit de définir une nouvelle règle pour le groupe d'accès.
Utilisez des balises de gestion d'accès pour contrôler l'accès aux ressources et aux identifiants de service de votre compte à l'échelle. En n'attribuant l'accès qu'aux ressources et aux identifiants de service auxquels sont attachées des étiquettes spécifiques, vous pouvez éviter de multiples mises à jour de vos politiques définies. Pour plus d'informations, voir Contrôle de l'accès aux ressources à l'aide d'étiquettes.
Utilisez des profils sécurisés pour octroyer automatiquement aux utilisateurs fédérés et ressources de calcul l'accès à votre compte. Ainsi, les utilisateurs fédérés peuvent être mappés à un ou plusieurs profils sécurisés lors de la connexion en évaluant les attributs basés sur SAML pour déterminer les profils auxquels ils peuvent s'appliquer. L'utilisation de profils sécurisés pour les ressources de calcul permet d'éviter le stockage des données d'identification pour exécuter des applications, ainsi que la gestion et la rotation des données d'identification. Vous pouvez également ajouter des profils sécurisés aux groupes d'accès afin de tirer parti de l'ensemble de règles que vous avez déjà créées.

Affectez l'accès à l'aide d'un groupe de services de sorte que vous n'ayez besoin que d'une seule règle pour affecter l'accès à plusieurs services. Ainsi, vous réduisez le nombre de règles dans votre compte et réduisez le temps et l'effort de gestion de l'accès.

 * **All Identity and Access enabled services**: All catalog services that use IAM for access management.
 * **All Account Management services**: Platform services, such as billing and usage, license and entitlements, enterprises, and more. For more information, see [Assigning access to account management services](/docs/iam?topic=iam-account-services).
 * **All IAM Account Management services**: A subset of account management services that includes the IAM platform services IAM Identity, IAM Access Management, IAM Users, IAM Groups, and future IAM services.

La suppression de l'accès aux identités et aux politiques inactives peut réduire le risque d'accès non autorisé à vos ressources IBM Cloud et vous aider à gérer l'accès plus efficacement. Pour plus d'informations, voir Identification des identités inactives et Audit des règles d'accès.

Qu'est-ce qu'une bonne stratégie de groupe d'accès ?

Un groupe d'accès est une organisation d'utilisateurs, d'ID de service et de profils sécurisés dans un groupe auquel vous pouvez accorder le même accès IAM. Toutes les identités d'un groupe d'accès héritent du même accès.

Vous pouvez logiquement affecter un accès à vos groupes de ressources et aux ressources incluses en créant un groupe d'accès par niveau d'accès requis. Ensuite, vous pouvez mapper chaque groupe d'accès aux groupes de ressources précédemment créés. Par exemple, pour contrôler l'accès au projet CustApp, vous pouvez créer les groupes d'accès suivants :

Auditor-Group
Developer-Group
Admin-Group

Pour Auditor-Group, affectez deux règles d'accès qui octroient les droits d'accès Afficheur aux ressources et aux groupes de ressources CustApp-Test et CustApp-Prod. Pour Developer-Group, affectez deux règles d'accès qui octroient les droits d'accès Editeur aux ressources et aux groupes de ressources CustApp-Dev et CustApp-Test. Pour Admin-Group, affectez trois règles d'accès qui octroient les droits d'accès Administrateur aux ressources et aux groupes de ressources CustApp.

Vous pouvez accorder les droits d'accès Administrateur sur tout ce que contient un compte en créant un groupe d'accès et en lui affectant deux règles. Pour créer la première politique, sélectionnez Tous les services d'identité et d'accès activés avec le rôle de plate-forme Administrateur et le rôle de service Gestionnaire. Pour créer la deuxième politique, sélectionnez Tous les services de gestion des comptes avec le rôle d'administrateur. Les utilisateurs ayant le rôle d'administrateur peuvent modifier l'accès et supprimer des groupes d'accès et ajouter et supprimer des utilisateurs d'un groupe d'accès, y compris d'autres utilisateurs ayant le rôle d'administrateur.

Les utilisateurs ayant le rôle d'administrateur sur les groupes d'accès peuvent accorder ou révoquer l'accès en ajoutant ou en supprimant des utilisateurs d'un groupe d'accès. En créant un groupe d'accès avec un accès administrateur, vous déléguez l'octroi et la révocation de l'accès administrateur du compte aux administrateurs ajoutés du groupe d'accès. L'accès administrateur à tout ce qui se trouve dans le compte inclut la possibilité de révoquer l'accès pour les autres utilisateurs ayant le rôle d'administrateur.

Le diagramme suivant montre comment l'accès est affecté aux groupes de ressources:

Attribution de l'accès aux groupes de ressources

Pour plus de bonnes pratiques sur IBM Garage for Cloud, voir Gérer l'accès aux ressources sur IBM Cloud.

Exemples de règle d'accès

Consultez les exemples de règle d'accès suivants pour déterminer plus facilement comment affecter l'accès à un groupe d'accès pour des ressources organisées en groupes de ressources.

Une règle qui octroie au groupe d'accès un rôle de plateforme Administrateur pour le compte IBM Cloud Kubernetes Service dans l'ensemble du compte. Les utilisateurs présents dans le groupe d'accès peuvent accéder à toutes les instances de ce service et créer des instances du service dans tout groupe de ressources pour lequel les utilisateurs disposent au moins du rôle Afficheur. Les membres du groupe d'accès ayant le rôle Administrateur sur les ressources peuvent également accorder l'accès à ces dernières.
Une règle qui octroie au groupe d'accès un rôle de plateforme Afficheur pour un groupe de ressources mais non pour ses ressources membre. Les utilisateurs présents dans le groupe d'accès ont une visibilité sur le groupe de ressources, ce qui est nécessaire pour créer des instances de n'importe quel service dans ce groupe de ressources.
Une règle qui octroie au groupe d'accès un rôle de plateforme Editeur pour toutes les ressources du groupe de ressources. Les utilisateurs présents dans le groupe d'accès peuvent éditer ou supprimer cette ressource.
Une règle qui octroie au groupe d'accès le rôle de plateforme Administrateur pour l'ensemble du compte (tous les services avec IAM activé). Les utilisateurs présents dans le groupe d'accès peuvent effectuer n'importe quelle action de plateforme sur n'importe quelle ressource dans l'ensemble du compte, ainsi que des actions de gestion, telles que la gestion des groupes de ressources dans le compte.

Qu'est-ce qu'une bonne stratégie de profils sécurisés ?

Un profil sécurisé est un regroupement d'utilisateurs fédérés ou de ressources de calcul auquel le même accès IAM peut être accordé. Toutes les identités autorisées à appliquer un même profil héritent du même accès. Pour réduire le nombre de règles dans un compte, vous pouvez ajouter des ressources de calcul et des utilisateurs fédérés au même profil sécurisé si leurs besoins d'accès sont identiques.

La création d'un profil de confiance est un moyen logique d'attribuer un accès à vos groupes de ressources et aux ressources qu'ils contiennent. Pour plus d'informations, voir Profils de confiance pour les utilisateurs fédérés et les charges de travail par niveau d'accès requis. Ensuite, vous pouvez mapper chaque profil sécurisé aux groupes de ressources précédemment créés. Par exemple, pour contrôler l'accès au projet CustApp, vous pouvez créer les profils sécurisés suivants :

Auditor-Profile
Developer-Profile
Admin-Profile

Pour Auditor-Profile, spécifiez les conditions en fonction d'attributs SAML pour les utilisateurs fédérés auxquels vous souhaitez pouvoir appliquer ce profil. Ces attributs SAML sont définis dans votre annuaire d'utilisateurs. Ainsi, la gestion des utilisateurs fédérés, l'octroi des accès et la révocation des accès sont essentiellement réalisés dans cet annuaire. Affectez ensuite deux règles d'accès qui octroient les droits d'accès Afficheur aux ressources et groupes de ressources CustApp-Test et CustApp-Prod.

Pour Developer-Profile, spécifiez les conditions en fonction d'attributs SAML pour les utilisateurs fédérés auxquels vous souhaitez pouvoir appliquer ce profil. Affectez deux règles d'accès qu octroient les droits d'accès Editeur aux ressources et aux groupes de ressources CustApp-Dev et CustApp-Test. Pour Admin-Profile, spécifiez les conditions en fonction d'attributs SAML pour les utilisateurs fédérés auxquels vous souhaitez pouvoir appliquer ce profil. Affectez trois règles d'accès qui octroient les droits d'accès Administrateur aux ressources et aux groupes de ressources CustApp.

Un profil sécurisé, comme d'autres identités IAM, peut se voir accorder l'accès à l'aide d'une règle ou en l'ajoutant à un groupe d'accès. Si vous disposez de groupes d'accès ayant le même niveau d'accès que celui dont un profil sécurisé a besoin, le profil sécurisé peut être ajouté à ce groupe d'accès.

Le diagramme suivant montre comment l'accès est affecté aux profils sécurisés:

Attribution de l'accès aux profils de confiance

Vous ne pouvez sélectionner qu'un seul type d'entité sécurisée lorsque vous créez un profil sécurisé. Vous pouvez commencer par mettre à jour les profils de confiance en utilisant la console à tout moment pour ajouter des relations de confiance avec les ressources informatiques.

Vous pouvez octroyer les droits d'accès Administrateur sur tout ce que contient un compte en créant un profil sécurisé et en lui affectant deux règles. Pour créer la première politique, sélectionnez Tous les services d'identité et d'accès activés avec le rôle de plate-forme Administrateur et le rôle de service Gestionnaire. Pour la deuxième politique, sélectionnez Tous les services de gestion de compte avec le rôle d'administrateur attribué. Les utilisateurs ayant le rôle d'administrateur peuvent mettre à jour et supprimer l'accès du profil sécurisé et ajouter et supprimer des utilisateurs du profil sécurisé, y compris d'autres utilisateurs ayant le rôle d'administrateur.

Les utilisateurs ayant le rôle d'administrateur sur les profils sécurisés peuvent accorder ou révoquer l'accès en ajoutant ou en supprimant des règles dans les profils sécurisés. En créant un profil sécurisé avec un accès administrateur, vous déléguez l'octroi et la révocation de l'accès administrateur du compte aux administrateurs ajoutés du profil sécurisé. L'accès administrateur à tout ce qui se trouve dans le compte inclut la possibilité de révoquer l'accès pour les autres utilisateurs ayant le rôle d'administrateur.

Exemples de règle d'accès

Consultez les exemples de règle d'accès suivants pour déterminer plus facilement comment affecter l'accès via des profils sécurisés à des ressources organisées en groupes de ressources.

Une règle qui octroie aux utilisateurs fédérés un rôle de plateforme Administrateur pour le compte IBM Cloud Kubernetes Service dans l'ensemble du compte. Les utilisateurs fédérés sont autorisés à appliquer ce profil lorsque les attributs de fournisseur d'identité externe de l'utilisateur fédéré remplissent les conditions de la relation de confiance. Par exemple, si votre annuaire d'utilisateurs possède un attribut jobrole qui identifie les administrateurs par la valeur admin, vous pouvez créer une condition qui ajoute dynamiquement des utilisateurs fédérés possédant cet attribut au profil sécurisé, ainsi que d'autres conditions. Les utilisateurs fédérés autorisés à appliquer le profil sécurisé peuvent accéder à toutes les instances de ce service et créer des instances du service dans tout groupe de ressources pour lequel les utilisateurs disposent au moins du rôle Afficheur. Les profils sécurisés possédant un rôle d'administrateur pour une ressource peuvent également octroyer l'accès à cette ressource. Des conditions peuvent être spécifiées pour que seuls les utilisateurs fédérés nécessitant les droits les plus élevés puissent appliquer ce profil sécurisé. Tous les autres utilisateurs fédérés peuvent être filtrés en fonction de leurs attributs SAML.
Une règle qui octroie aux ressources de calcul les rôles Reader et Writer dans un groupe de ressources. Lorsque les ressources de calcul s'authentifient et remplissent les conditions spécifiées dans le profil sécurisé (par exemple, location ou resource type), le profil sécurisé est automatiquement appliqué. Ainsi, toutes les ressources existantes ou futures qui remplissent ces conditions peuvent avoir le profil qui est automatiquement appliqué lors de l'authentification.
Vous pouvez également établir une relation de confiance avec des ressources de calcul spécifiques, comme un cluster Kubernetes unique. Par exemple, une application peut être exécutée sur Kubernetes Service, devoir lire et écrire depuis IBM Cloudant et devoir lire et écrire dans un compartiment Cloud Object Storage Dedicated IBM Managed. Les instances IBM Cloudant et Cloud Object Storage Dedicated IBM Managed se trouvent alors dans le même groupe de ressources et le profil sécurisé bénéficie du rôle Reader ou Writer.

L'utilisation de profils sécurisés est recommandée pour les applications exécutées sur des ressources de calcul IBM Cloud pour accéder à des ressources compatibles avec IAM.

Comparer les groupes d'accès et les profils sécurisés

Les groupes d'accès sont mieux utilisés pour accorder l'accès au travail quotidien d'un utilisateur, tandis que les profils de confiance conviennent pour accorder aux utilisateurs fédérés le niveau d'accès dont ils ont besoin pour accomplir un ensemble de tâches spécialisées et spécifiques dans une période de temps limitée. Il s'agit généralement de tâches critiques que vous aimeriez ne pas avoir à effectuer involontairement lors de votre travail quotidien. Avec les profils sécurisés, les utilisateurs fédérés n'ont pas besoin d'être intégrés à IBM Cloud ; ils peuvent accéder aux ressources IBM Cloud d'un compte par le biais d'une relation de confiance. Si un utilisateur fédéré quitte votre société, vous pouvez simplement supprimer son identité d'entreprise dans votre annuaire et révoquer ainsi son accès à IBM Cloud. L'accès temporel avec des profils sécurisés permet d'effectuer fréquemment des vérifications d'authentification pour réduire les risques de sécurité.

Utilisez le tableau ci-après pour comprendre les différences entre les groupes d'accès et les profils sécurisés et prendre la meilleure décision pour votre cas d'utilisation.

Comparer les groupes d'accès et les profils sécurisés
Fonction	Groupe d'accès	Profil sécurisé
Contrôle d'accès IAM	Oui	Oui
Invitation d'utilisateurs à rejoindre le compte IBM Cloud requise	Oui	Non
L'accès peut être défini avant que l'utilisateur ne soit ajouté au compte	Oui, à l'aide de règles dynamiques	Oui
Utilisateurs fédérés	Oui	Oui
Utilisateurs non fédérés	Oui	Oui
ID de service	Oui	Oui
Identités de ressource de calcul	Non	Oui
La gestion des utilisateurs est principalement effectuée dans	Compte IBM Cloud	Annuaire d'utilisateurs

Les groupes d'accès et les profils sécurisés peuvent être utilisés séparément ou ensemble pour la gestion des utilisateurs et des accès, en fonction des besoins de votre organisation.

Par exemple, pour le projet CustApp, vous pouvez choisir de créer un profil sécurisé IAM Admin avec les règles suivantes :

Administrator pour les groupes d'accès CustApp-Dev/Test/Prod. De cette manière, l'administrateur peut octroyer et révoquer l'accès aux utilisateurs en les ajoutant à des groupes d'accès ou en les en supprimant.
Administrator pour le service de gestion des comptes IAM Identity. De cette manière, l'administrateur peut gérer les ID de service, les profils sécurisés, les règles, etc.
Editor pour le service de gestion des comptes Gestion des utilisateurs. De cette manière, l'administrateur peut inviter des utilisateurs dans le compte, afficher les utilisateurs dans le compte, etc.

Avec ce profil sécurisé, l'administrateur peut ajouter des développeurs à un groupe d'accès avec des règles d'accès assez vastes pour effectuer des actions et des tâches quotidiennes dans les environnements de développement et de test. L'accès aux opérations sur l'environnement de production peut être configuré dans un profil sécurisé nommé Operator-Profile. Ainsi, le développeur peut changer de rôle en se connectant et en appliquant Operator-Profile s'il doit agir sur CustApp en production.

Cas d'utilisation pour l'organisation des ressources et l'affectation d'accès

Passez en revue les cas d'utilisation ci-après pour vous aider à préparer un plan qui fonctionne pour votre organisation. Pour chaque cas d'utilisation, il est recommandé d'utiliser des groupes d'accès ou des profils sécurisés dans le but de fournir un accès à un groupe d'utilisateurs tout en gérant un nombre minimal de règles d'accès. A l'aide des groupes d'accès, vous pouvez simplement ajouter ou retirer des utilisateurs de votre compte des groupes d'accès pour affecter ou révoquer des accès si nécessaire. A l'aide de profils sécurisés, vous pouvez facilement mettre à jour les conditions selon lesquelles les utilisateurs fédérés de votre annuaire d'utilisateurs sont autorisés à appliquer des profils sécurisés sans avoir à les inviter dans le compte ou à affecter un accès individuel à chaque utilisateur.

Plusieurs utilisateurs travaillant ensemble sur un même projet à l'aide de groupes d'accès

Certains des utilisateurs de votre compte doivent gérer le compte et affecter l'accès à d'autres utilisateurs. Certains utilisateurs ont besoin de créer des instances de service qui entraînent des dépenses. Les autres utilisateurs sont des développeurs d'application qui ont uniquement besoin d'utiliser les instances de service de leurs composants d'application.

Vous souhaitez accorder à tous les utilisateurs différents rôles dans le compte et le groupe de ressources par défaut. Vous n'avez pas besoin de créer d'autres groupes de ressources pour séparer des ressources ou restreindre l'accès à certaines ressources pour certains utilisateurs. Vous pouvez accorder aux utilisateurs les rôles qui conviennent à leurs besoins en créant un groupe d'accès pour chaque groupe d'utilisateurs :

Créez un groupe d'accès et affectez-lui des utilisateurs qui doivent gérer le compte et accorder aux autres utilisateurs un accès. Ensuite, affectez une règle dotée d'un rôle Administrateur sur tous les services avec IAM activé et tous les services de gestion des comptes.
Créez un groupe d'accès et affectez-lui des utilisateurs qui doivent créer des instances de service. Ensuite, affectez une règle dotée d'un rôle Editeur sur le groupe de ressources par défaut et une règle dotée du rôle Editeur pour n'importe quel service qui doit être créé par les utilisateurs.
Créez un groupe d'accès et affectez-lui des utilisateurs qui doivent utiliser les instances de service d'un groupe de ressources. Ensuite, affectez une règle dotée d'un rôle Auteur ou Lecteur sur les instances de service qui existent dans le groupe de ressources.

Plusieurs utilisateurs travaillant ensemble sur un même projet à l'aide de profils sécurisés

Dans une organisation, lorsque vous souhaitez gérer l'accès à l'échelle, certains membres de votre organisation doivent gérer le compte IBM Cloud et attribuer l'accès à d'autres utilisateurs. Certains membres ont besoin de créer des instances de service qui entraînent des dépenses. Les autres membres sont des développeurs d'application qui ont uniquement besoin d'utiliser les instances de service de leurs composants d'application.

Vous souhaitez accorder à tous les utilisateurs différents rôles dans le compte et le groupe de ressources par défaut. Vous n'avez pas besoin de créer d'autres groupes de ressources pour séparer des ressources ou restreindre l'accès à certaines ressources pour certains utilisateurs. Vous pouvez accorder aux utilisateurs les rôles qui conviennent à leurs besoins en créant des profils sécurisés pour chaque type d'utilisateur et en les mappant au profil approprié en fonction des attributs du fournisseur d'identité externe.

Créez un profil sécurisé pour les utilisateurs qui doivent gérer le compte et accorder aux autres utilisateurs un accès. Etablissez une relation de confiance avec votre fournisseur d'identité externe et définissez les attributs qui permettent aux membres appropriés de votre organisation d'appliquer le profil. Ensuite, affectez une règle dotée d'un rôle Administrateur sur tous les services avec IAM activé et tous les services de gestion des comptes.
Créez un profil sécurisé pour les utilisateurs qui doivent créer des instances de service. Etablissez une relation de confiance avec votre fournisseur d'identité externe et définissez les attributs qui permettent aux membres appropriés de votre organisation d'appliquer le profil. Ensuite, affectez une règle dotée d'un rôle Editeur sur le groupe de ressources par défaut et une règle dotée du rôle Editeur pour n'importe quel service qui doit être créé par les utilisateurs.
Créez un profil sécurisé pour les utilisateurs qui doivent utiliser les instances de service dans un groupe de ressources. Etablissez une relation de confiance avec votre fournisseur d'identité externe et définissez les attributs qui permettent aux membres appropriés de votre organisation d'appliquer le profil. Ensuite, affectez une règle dotée d'un rôle Auteur ou Lecteur sur les instances de service qui existent dans le groupe de ressources.

Deux équipes travaillant sur deux projets connexes

Deux projets sont fonctionnels dans votre compte. Les développeurs qui travaillent sur un projet ont besoin d'accéder à toutes ses ressources. En tant qu'administrateur de compte, vous pouvez octroyer l'accès en créant des groupes d'accès pour chaque projet et en incorporant des étiquettes de gestion des accès dans les règles d'accès de chaque groupe.

La flexibilité est importante et avec IAM, vous pouvez partager des ressources entre différents groupes. Supposons que vous constatiez qu'une ressource peut convenir aux deux projets. Vous pouvez partager une ressource entre les deux projets en l'étiquetant et en vous appuyant sur les droits existants pour octroyer l'accès aux développeurs. Si un projet n'a plus besoin d'une ressource, vous pouvez simplement révoquer l'accès des développeurs en déconnectant l'étiquette appropriée de l'instance de service. Regardez la vidéo ci-après pour mieux comprendre la manière dont vous pouvez utiliser les étiquettes de gestion des accès pour gérer l'accès aux ressources de votre compte.

Transcription vidéo

En tant qu'administrateur de compte, vous pouvez utiliser des étiquettes pour gérer l'accès aux ressources de votre compte de manière centralisée, en fonction des besoins.

Par exemple, deux projets sont fonctionnels : l'un s'intitule soulmate et est utilisé pour le stockage et les services linguistique de Watson, tandis que l'autre s'intitule Soul-FAQ et sert de support au projet soulmate. Il utilise Watson Assistant et Cloud Object Storage.

Pour créer des étiquettes de gestion des accès en tant qu'administrateur de compte, cliquez sur Gérer, puis sur Compte dans la console IBM Cloud. Sur la page Etiquettes, cliquez sur Etiquettes de gestion des accès. Pour créer des étiquettes, entrez les noms d'étiquette, en les séparant par une virgule. Nous créons deux étiquettes : une pour le projet soulmate et l'autre pour le projet soul-faq.

En accédant à la liste des ressources, vous pouvez voir toutes les ressources du compte. Vous pouvez étiqueter ici les ressources liées au projet, puis les afficher dans votre compte, en filtrant par étiquettes.

A ce stade, le développeur ne peut pas voir les ressources car les droits appropriés ne leur ont pas encore été octroyés.

Un administrateur de compte peut autoriser les développeurs à accéder aux ressources de leur projet à l'aide d'une combinaison de groupes d'accès et d'étiquettes.

En tant qu'administrateur de compte, cliquez sur Gérer, puis sur Accès et sélectionnez Groupes d'accès. Deux groupes d'accès sont configurés : un pour le projet soulmate et l'autre pour la foire aux questions.

Le groupe des développeurs du projet soulmate comporte un développeur. Aucune règle n'ayant été configurée, l'administrateur de compte doit affecter les accès. Pour cela, sélectionnez tous les services du compte en fonction d'attributs spécifiques. Sélectionnez Etiquettes de gestion des accès pour afficher toutes les étiquettes disponibles dans le compte. Comme vous créez une règle pour le projet soulmate, sélectionnez l'étiquette correspondante. La console indique que l'étiquette soulmate du projet est mappée à trois ressources distinctes.

Ensuite, sélectionnez certains rôles. Octroyez à l'ensemble du groupe le rôle Afficheur pour que tous puissent afficher les ressources de la liste et tous les accès fonctionnels à ces services. Cliquez sur Affecter pour créer la règle.

Trois services sont maintenant disponibles pour le développeur. Ces derniers ont accès aux trois ressources et aux éventuelles sous-ressources.

La flexibilité étant importante, nous avons facilité le partage des ressources entre les différents groupes. Supposons qu'un administrateur de compte constate qu'IBM Cloud Object Storage convient parfaitement aux sauvegardes et fonctionne bien avec le projet FAQ. Il souhaite utiliser IBM Cloud Object Storage dans le projet soulmate.

Editez simplement les étiquettes de gestion des accès. Ajoutez l'étiquette du projet soulmate et cliquez sur Sauvegarder.

Dans la liste des ressources, vous pouvez confirmer que deux étiquettes de gestion des accès sont associées à l'instance Cloud Object Storage.

Outre les ressources d'origine, le développeur peut désormais voir la ressource Cloud Object Storage. L'instance est disponible pour toute personne ayant accès au projet soulmate ou FAQ.

Supposons que vous ne souhaitiez plus le service Tone Analyzer pour le projet soulmate. Le fait de dissocier l'étiquette du projet soulmate du service Tone Analyzer révoque l'accès du développeur à cette instance de service. Un administrateur de compte peut dissocier l'étiquette en cliquant sur Editer des étiquettes, puis en supprimant l'étiquette de la liste.

L'instance de service Tone Analyzer n'est plus incluse dans la liste des ressources du développeur.

Si vous utilisez des étiquettes de gestion des accès pour contrôler l'accès, les projets de votre équipe peuvent se développer sans qu'une mise à jour des règles IAM ne soit nécessaire.

Trois équipes travaillant sur trois projets

Une poignée d'utilisateurs de mon compte sont administrateurs. Ils doivent pouvoir créer de nouveaux groupes de ressources et affecter aux utilisateurs un accès à ces groupes de ressources. J'affecte ces utilisateurs à un groupe d'accès avec une règle pour laquelle le rôle Administrateur est affecté sur tous les services avec IAM activé.

Les autres utilisateurs ont uniquement besoin d'accéder au groupe de ressources associé à leur projet. J'utilise des groupes d'accès et j'affecte différents rôles sur le groupe de ressources et ses membres qui sont associés à leur projet : un rôle Editeur sur le groupe de ressources pour les utilisateurs qui ont besoin de créer des instances, plus un rôle Lecteur ou Auteur sur les membres de groupe de ressource pour les utilisateurs qui ont besoin d'utiliser ces instances.

Plusieurs groupes de ressources dans mon compte

Certains des utilisateurs de mon compte sont administrateurs d'un service, Service A, et ils ont besoin d'accéder à toutes les instances de ce service ainsi que de créer des instances. Ces utilisateurs n'ont pas besoin d'accéder à d'autres ressources du compte. Je crée un groupe d'accès et j'affecte un rôle Administrateur sur le service A au niveau du compte et une règle avec le rôle Afficheur pour tous les groupes de ressources du compte dans lequel il doit être possible de créer des instances. Vous pouvez le faire en sélectionnant Groupe de ressources uniquement, puis en sélectionnant le groupe de ressources et au moins le rôle de spectateur pour ce groupe de ressources. Répétez ensuite l'opération pour chaque groupe de ressources pour lequel un accès est nécessaire.

Un utilisateur ayant besoin d'accéder à une ressource spécifique

Mon compte comprend un utilisateur qui a uniquement besoin d'accéder à une ressource spécifique d'un service, par exemple, il doit disposer de droits en écriture dans un compartiment, Bucket A, dans IBM Cloud Object Storage. Cet utilisateur n'a pas besoin de voir les groupes de ressources de mon compte ou accéder à d'autres services ou à d'autres compartiments de Object Storage.

J'affecte à l'utilisateur un rôle Auteur sur le compartiment A dans l'instance spécifique de Object Storage. Je peux choisir d'utiliser l'interface utilisateur IAM ou l'interface utilisateur Object Storage pour affecter le rôle. J'utilise l'interface utilisateur propre au service car elle me permet d'effectuer une sélection parmi une liste de ressources. L'interface utilisateur IAM n'affiche pas les ressources inférieures au niveau d'instance de service et je dois entrer manuellement le nom de ressource de cloud pour affecter une règle à ces ressources.

Etapes suivantes

Maintenant que vous savez comment configurer vos groupes de ressources, organiser vos ressources et créer des groupes d'accès dans votre compte, vous pouvez commencer à inviter des utilisateurs à rejoindre votre compte et à leur affecter l'accès à vos groupes d'accès. Si vous avez déjà invité des utilisateurs sur votre compte, vous pouvez vous rendre sur votre page Utilisateurs et commencer à attribuer des accès dans la console.

Si vous décidez que votre organisation souhaite gérer l'accès des utilisateurs sur la base de l'annuaire des utilisateurs de votre entreprise, vous pouvez commencer par créer un profil de confiance. Pour plus d'informations, voir Profils de confiance pour les utilisateurs et charges de travail fédérés.