Définissez les autorisations en fonction des attributs avec ABAC autorisation - AWS Gestion de l’identité et des accès

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Définissez les autorisations en fonction des attributs avec ABAC autorisation

Le contrôle d'accès basé sur les attributs (ABAC) est une stratégie d'autorisation qui définit les autorisations en fonction des attributs. AWS appelle ces balises d'attributs. Vous pouvez associer des balises aux IAM ressources, y compris aux IAM entités (IAMutilisateurs ou IAM rôles) et aux AWS ressources. Vous pouvez créer une ABAC politique unique ou un petit ensemble de politiques pour vos IAM mandants. Vous pouvez concevoir ABAC des politiques qui autorisent les opérations lorsque la balise du principal correspond à la balise de ressource. ABAC, système d'attributs qui fournit à la fois un contexte utilisateur élevé et un contrôle d'accès granulaire. Comme il ABAC est basé sur des attributs, il peut effectuer une autorisation dynamique pour les données ou les applications qui accordent ou révoquent l'accès en temps réel. ABACest utile dans les environnements évolutifs et dans les situations où la gestion des identités ou des politiques de ressources est devenue complexe.

Par exemple, vous pouvez créer trois IAM rôles à l'aide de la clé access-project tag. Définissez la valeur de balise du premier IAM rôle surHeart, du deuxième sur Star et du troisième surLightning. Vous pouvez ensuite utiliser une politique unique qui autorise l'accès lorsque le IAM rôle et la AWS ressource ont la valeur de baliseaccess-project. Pour un didacticiel détaillé expliquant comment l'utiliser ABAC dans AWS, voirIAMtutoriel : Définir les autorisations d'accès aux AWS ressources en fonction des balises. Pour en savoir plus sur les services qui prennent en chargeABAC, consultezAWS des services qui fonctionnent avec IAM.

Ce schéma montre que les balises appliquées à un principal doivent correspondre aux balises appliquées à une ressource pour que l'utilisateur obtienne des autorisations sur la ressource. Les balises doivent être appliquées aux groupes d'utilisateurs, aux groupes de ressources, aux utilisateurs individuels et aux ressources individuelles.

Comparaison avec ABAC le RBAC modèle traditionnel

Le modèle d'autorisation traditionnel utilisé IAM est le contrôle d'accès basé sur les rôles ()RBAC. RBACdéfinit les autorisations en fonction du poste, de la fonction ou du rôle d'une personne, qui est distinct d'un IAM rôle. IAMinclut des politiques gérées pour les fonctions de travail qui alignent les autorisations sur une fonction de travail dans un RBAC modèle.

DansIAM, vous implémentez en RBAC créant différentes politiques pour différentes fonctions professionnelles. Vous associez ensuite les politiques aux identités (IAMutilisateurs, IAM groupes ou IAM rôles). Les bonnes pratiques consistent à n'octroyer que les autorisations minimales nécessaires pour la tâche à accomplir. Cela se traduit par un accès avec le moindre privilège. Chaque politique de fonction de travail répertorie les ressources spécifiques auxquelles les identités assignées à cette politique peuvent accéder. L'inconvénient du RBAC modèle traditionnel est que lorsque vous ou vos utilisateurs ajoutez de nouvelles ressources à votre environnement, vous devez mettre à jour les politiques pour autoriser l'accès à ces ressources.

Par exemple, supposons que vous ayez trois projets, nommés Heart, Star et Lightning, sur lesquels travaillent vos employés. Vous créez un IAM rôle pour chaque projet. Vous associez ensuite des politiques à chaque IAM rôle afin de définir les ressources auxquelles toute personne autorisée à assumer le IAM rôle peut accéder. Si un employé change de poste au sein de votre entreprise, vous lui attribuez un autre IAM rôle. Vous pouvez attribuer plusieurs IAM rôles à des personnes ou à des programmes. Cependant, le Star projet peut nécessiter des ressources supplémentaires, telles qu'un nouveau EC2 conteneur Amazon. Dans ce cas, vous devez mettre à jour la politique attachée au Star IAM rôle pour spécifier la nouvelle ressource de conteneur. Sinon, les membres du projet Star ne seront pas autorisés à accéder au nouveau conteneur.

Ce schéma montre que le contrôle d'accès basé sur les rôles nécessite l'attribution à chaque identité d'une politique spécifique basée sur les tâches et les fonctions pour accéder aux différentes ressources.
ABACoffre les avantages suivants par rapport au RBAC modèle traditionnel :
  • ABACles autorisations évoluent en fonction de l'innovation. L'administrateur n'a plus besoin de mettre à jour les politiques existantes pour autoriser l'accès aux nouvelles ressources. Supposons, par exemple, que vous ayez conçu votre ABAC stratégie avec le access-project tag. Un développeur utilise le IAM rôle avec la Heart balise access-project =. Lorsque les personnes participant au Heart projet ont besoin de EC2 ressources Amazon supplémentaires, le développeur peut créer de nouvelles EC2 instances Amazon avec le Heart tag access-project =. N'importe quel membre du projet Heart peut alors démarrer et arrêter ces instances, car leurs valeurs de balise correspondent.

  • ABACnécessite moins de politiques. Comme vous n'avez pas besoin de créer une politique pour chaque activité professionnelle, vous créez moins de politiques. Leur gestion s'en trouve simplifiée.

  • Grâce à ABAC cette méthode, les équipes peuvent réagir de manière dynamique au changement et à la croissance. Comme les autorisations pour les nouvelles ressources sont automatiquement accordées en fonction des attributs, il n'est pas nécessaire d'attribuer manuellement des politiques aux identités. Par exemple, si votre entreprise prend déjà en charge les Star projets Heart et les utiliseABAC, il est facile d'ajouter un nouveau Lightning projet. Un IAM administrateur crée un nouveau IAM rôle avec la Lightning balise access-project =. Il n'est pas nécessaire de modifier la politique pour prendre en charge un nouveau projet. Toute personne autorisée à assumer ce IAM rôle peut créer et afficher des instances étiquetées avec access-project =Lightning. Un autre scénario est celui où un membre de l'équipe passe Heart du projet au Lightning projet. Pour permettre aux membres de l'équipe d'accéder au Lightning projet, l'IAMadministrateur leur assigne un IAM rôle différent. Il n'est pas nécessaire de modifier les politiques d'autorisations.

  • Des autorisations granulaires sont possibles en utilisantABAC. Lorsque vous créez des politiques, la bonne pratique consiste à accorder un moindre privilège. En utilisant la RBAC méthode traditionnelle, vous rédigez une politique qui autorise l'accès à des ressources spécifiques. Toutefois, lors de l'utilisationABAC, vous pouvez autoriser des actions sur toutes les ressources si le tag de la ressource correspond au tag du principal.

  • Utilisez les attributs des employés de votre annuaire d'entreprise avecABAC. Vous pouvez configurer votre OIDC fournisseur SAML ou celui de votre fournisseur pour qu'il transmette des balises de session àIAM. Lorsque vos employés se fédérent dans AWS, IAM applique leurs attributs au capital qui en résulte. Vous pouvez ensuite utiliser ABAC pour autoriser ou refuser des autorisations en fonction de ces attributs.

Pour un didacticiel détaillé expliquant comment l'utiliser ABAC dans AWS, voirIAMtutoriel : Définir les autorisations d'accès aux AWS ressources en fonction des balises.