Types d'identité pour les utilisateurs, les services et les charges de travail
IBM Cloud prend en charge plusieurs types d'identité, notamment les utilisateurs fédérés, les identifiants de service, les profils de confiance et les clés API pour l'authentification sécurisée de la charge de travail.
Le concept d'identité comprend des identités d'utilisateur, des identités de service et d'application, des clés d'API pour les utilisateurs et les ID de service, des profils sécurisés et des identités de ressource. Les utilisateurs sont identifiés par leurs attributs IBMid, ID SoftLayer, ID utilisateur App ID ou utilisateur fédéré.
IBM Cloud L'IAM accorde l'accès à des identités individuelles ou à un groupe d'identités en utilisant des politiques. Les politiques permettent aux utilisateurs d'accorder l'accès tout en adhérant au principe du moindre privilège en utilisant des rôles et des ressources délimitées. À l'exception des propriétaires de comptes, les identités des utilisateurs ne bénéficient d'aucune autorisation d'accès par défaut. Chaque autorisation d'accès est indépendante des autres autorisations d'accès, et les utilisateurs autorisés peuvent accéder aux ressources en utilisant la console et les API. Les actions autorisées peuvent concerner une seule API ou un groupe d'API, en fonction des besoins du client. L'accès peut être accordé à un niveau élevé pour un groupe de ressources ou limité à une seule ressource en fonction des besoins du client.
La suppression de l'accès pour les identités inactives peut réduire le risque d'accès non autorisé à votre ressource IBM Cloud et vous aider à gérer l'accès plus efficacement. Pour plus d'informations, voir Identifying inactive identities.
Utilisateurs
Les ID utilisateur sont mieux utilisés lorsqu'une personne a besoin d'une identité numérique dans un compte. Les utilisateurs sont invités dans le compte et se voient accorder l'accès aux ressources du compte. Les utilisateurs se connectent à l'aide de leur IBMid, leur ID SoftLayer, leur ID utilisateur App ID ou leur ID utilisateur fédéré. Chaque utilisateur est également identifié par un ID généré appelé ID IAM.
Les ID IAM incluent toujours un domaine permettant d'identifier le fournisseur de l'utilisateur, tel qu'IBMid ou un fournisseur d'identité externe. Dans l'ID IAM, le domaine est suivi d'une série de nombres qui constituent un identificateur
unique. Par exemple, l'ID IAM d'un utilisateur doté d'un IBMid ressemble à IBMid-20000AB1C.
Les ID IAM sont généralement utilisés lorsque vous affectez l'accès à d'autres utilisateurs à l'aide de l'API. Ils permettent d'identifier un utilisateur, un ID service, un profil sécurisé ou une ressource. L'ID IAM est inclus dans le jeton lorsqu'il est utilisé dans la console, l'interface de ligne de commande ou l'API. Les règles d'accès sont définies à l'aide des ID IAM puisque c'est l'identité qui peut être vérifiée dans le jeton IAM.
Pour rechercher votre ID IAM, accédez à Gérer > Accès (IAM). Vous pouvez voir votre ID IAM dans la section My user details. Pour afficher les ID IAM d'autres utilisateurs, accédez à Gérer > Accès (IAM) > Utilisateurs, puis sélectionnez le nom d'un utilisateur dans la liste et cliquez sur Détails.
Clés d'API d'utilisateur
Les clés de l'API IBM Cloud sont des données d'identification associées à l'identité d'un utilisateur. L'accès affecté à l'utilisateur peut provenir de règles de plusieurs comptes dont l'utilisateur est membre. Les données d'identification de clé de l'API utilisateur peuvent être utilisées pour effectuer des appels d'API et de CLI. La clé d'API d'utilisateur peut être utilisée directement ou être utilisée pour générer un jeton.
Pour plus d'informations sur l'utilisation d'une clé d'API associée à votre identité utilisateur, voirGestion des clés d'API d'utilisateur.
Fédération des utilisateurs dans IBM Cloud
IBM Cloud offre deux options de fédération qui permettent à vos employés d'accéder à IBM Cloud avec les informations d'identification de leur entreprise : se fédérer avec IBMid ou créer une instance de service IBM Cloud App ID. Pour plus d'informations, voir Activation de l'authentification à partir d'un fournisseur d'identité externe.
Dans les deux cas, les utilisateurs doivent être membres d'un compte ou avoir accès à un profil de confiance. Avec la fédération IBMid, les propriétaires de comptes ou les administrateurs doivent inviter des utilisateurs, qui deviennent des membres actifs après avoir accepté. Avec App ID, les utilisateurs sont automatiquement intégrés sans invitation. Dans les deux cas, les utilisateurs fédérés peuvent accéder aux ressources activées par IAM et à l'infrastructure classique en fonction de l'accès qui leur a été attribué.
Les profils de confiance gèrent différemment les utilisateurs fédérés. SAML Les attributs IdP des utilisateurs sont évalués lors de la connexion et, s'ils remplissent les conditions du profil de confiance, les utilisateurs sont invités à appliquer un ou plusieurs profils. Les profils de confiance accordent un accès limité dans le temps (généralement de 1 à 4 heures) pour des tâches spécialisées, ce qui permet des contrôles d'authentification fréquents pour réduire les risques de sécurité. Les utilisateurs sont automatiquement ajoutés grâce à la relation de confiance, sans qu'il soit nécessaire de les intégrer. Lorsqu'un utilisateur quitte votre entreprise, la suppression de son identité dans votre annuaire révoque l'accès à IBM Cloud.
ID fonctionnels
Les identifiants fonctionnels sont le plus souvent utilisés lorsqu'une application ou un service a besoin d'une identité numérique et d'un accès aux ressources IAM ou aux ressources de l'infrastructure classique. Certains services nécessitent un ID fonctionnel lorsque vous créez des instances de service, par exemple Kubernetes Service.
Un ID fonctionnel est un type d'ID utilisateur qui existe dans le répertoire utilisateur de votre fournisseur d'identité (IdP), mais qui n'est pas lié à un utilisateur spécifique. Pour créer un ID fonctionnel, vous devez créer un nouvel utilisateur dans le répertoire utilisateur et l'inviter sur votre compte IBM Cloud.
L'ID fonctionnel est utilisé pour créer des instances de service, comme des clusters Kubernetes Service. De cette façon, les instances ne sont pas liées à une personne spécifique qui pourrait quitter l'entreprise, ce qui laisserait l'instance sans propriétaire. En règle générale, les ID fonctionnels peuvent faire plus dans IBM Cloud qu'un ID de service. Par exemple, les ID fonctionnels, tels que les ID utilisateur, peuvent se voir accorder l'accès aux services et aux applications via des règles d'accès.
Les clés d'API IBM Cloud pour les utilisateurs peuvent être créées et associées à un ID fonctionnel. Si un service nécessite une clé d'API utilisateur pour interagir avec d'autres services ou applications, utilisez la clé d'API d'ID fonctionnel. En utilisant la clé d'API associée à l'ID fonctionnel, vous pouvez fournir uniquement l'accès nécessaire pour ce service.
Si vous utilisez un identifiant fonctionnel comme propriétaire du compte, envisagez plutôt de définir un autre propriétaire de compte. Cette option n'est disponible que pour les comptes d'infrastructure classiques.
ID de service
Les ID de service sont un autre type d'identité utilisé dans un compte. Les ID de service sont utilisés pour fournir une identité distincte aux services et aux applications. Les ID de service sont mieux utilisés lorsqu'une application ou un service a besoin d'une identité numérique et n'a besoin d'accéder qu'aux ressources compatibles IAM. Vous pouvez créer un ID de service à utiliser par une application qui a besoin d'accéder à vos services IBM Cloud afin que les données d'identification des utilisateurs individuels n'aient pas besoin d'être utilisées.
Clés d'API d'ID de service
Vous pouvez également créer des clés API associées à des identifiants de service afin d'authentifier les applications en tant qu'identifiant de service particulier. De cette manière, les applications peuvent accéder aux ressources attribuées à cet identifiant de service spécifique. Les données d'identification de clé d'API d'ID de service peuvent être utilisées pour effectuer des appels d'API et de CLI. Pour plus d'informations sur la création de clés d'API associées à un ID de service, voir Gestion des clés d'API d'ID de service.
Profils sécurisés
Comme pour les autres identités dans IAM, les profils sécurisés sont traités comme un sujet auquel l'accès est accordé dans les règles IAM.
Généralement, pour qu'un utilisateur intervienne sur une ressource dans un compte, cette identité doit explicitement être ajoutée au compte. Avec des profils sécurisés, un utilisateur peut effectuer les actions sans être invité sur un compte. Au lieu de cela, l'accès aux ressources lui est automatiquement octroyé lorsqu'il applique l'identité de profil sécurisé lors de la connexion. Seuls les utilisateurs fédérés par un fournisseur d'identité externe peuvent être mappés à des profils sécurisés lors de la connexion en évaluant les attributs basés sur SAML pour déterminer les profils auxquels leur identité peut s'appliquer.
De même, au lieu de créer un ID de service, de générer une clé d'API et de faire en sorte que l'application stocke et valide cette clé, vous pouvez créer des profils sécurisés pour les ressources de traitement pour définir une autorisation à granularité fine pour toutes les applications qui s'exécutent dans une ressource de traitement. Les ressources de traitement deviennent des identités lorsqu'elles sont utilisées dans le cadre d'un profil sécurisé. La confiance dans les ressources de traitement est établie par des conditions basées sur des attributs de ressource ou par la création d'un lien direct vers une ressource spécifique.
Vous pouvez également établir une relation de confiance avec les services IBM Cloud qui doivent effectuer une opération sur votre compte. Vous pouvez également utiliser des profils de confiance pour donner à un identifiant de service d'un autre compte l'accès à votre compte.
Identités des ressources
Le dernier élément du concept d'identité dans l'IAM est IBM Cloud ressources, qui sont identifiées par leurs noms de ressources en nuageIdentificateur global unique pour une ressource de cloud spécifique. La valeur est segmentée hiérarchiquement par version, instance, type, emplacement et portée, séparés par le signe deux-points. (CRN). Toutes les ressources créées à partir du catalogue sont identifiées par leur CRN. Ces CRN sont utilisés pour les autorisations de service à service dans IAM. En outre, vous utilisez un CRN pour affecter l'accès à des ressources spécifiques lorsque vous utilisez l'API. Pour plus d'informations, voir Noms des ressources cloud et Utiliser les autorisations pour accorder l'accès entre les services.