À quoi sert ABAC ? AWS

Le contrôle d’accès basé sur les attributs (ABAC) est une politique d’autorisation qui définit des autorisations en fonction des attributs. Dans AWS, ces attributs sont appelés balises. Vous pouvez associer des balises aux ressources IAM, notamment aux entités IAM (utilisateurs ou rôles) et aux AWS ressources. Vous pouvez créer une seule politique ABAC ou un petit nombre de politiques pour vos principaux IAM. Ces politiques ABAC sont conçues pour autoriser des opérations lorsque la balise du principal correspond à celle de la ressource. L'ABAC est utile dans les environnements qui connaissent une croissance rapide et pour les cas où la gestion des politiques devient fastidieuse.

Par exemple, vous pouvez créer trois rôles avec la clé de balise access-project. Définissez la valeur de la balise du premier rôle sur Heart, celle du deuxième sur Star, et celle du troisième sur Lightning. Vous pouvez alors utiliser une seule politique qui autorise l'accès lorsque le rôle et la ressource sont balisés avec la même valeur pour access-project. Pour un didacticiel détaillé expliquant comment utiliser ABAC dans AWS, voirDidacticiel IAM : définir les autorisations d'accès aux ressources AWS en fonction des balises. Pour en savoir plus sur les services qui prennent en charge ABAC, consultez AWS services qui fonctionnent avec IAM.

Comparaison du contrôle ABAC et du modèle RBAC traditionnel

Le modèle d'autorisation traditionnel utilisé dans IAM est appelé contrôle d'accès basé sur les rôles (RBAC). Le RBAC accorde des droits aux utilisateurs en fonction de leur activité professionnelle, appelée rôle en dehors d' AWS . Au sein AWS d'un rôle, on entend généralement un rôle IAM, qui est une identité que vous pouvez assumer dans IAM. IAM inclut des politiques gérées pour des fonctions de tâches, qui alignent les autorisations sur une fonction de tâche dans un modèle RBAC.

Dans IAM, vous implémentez le RBAC en créant différentes politiques pour différentes activités professionnelles. Vous attachez ensuite les politiques à des identités (utilisateurs IAM, groupes d'utilisateurs ou rôles IAM). Les bonnes pratiques consistent à n'octroyer que les autorisations minimales nécessaires pour la tâche à accomplir. C'est ce qu'on appelle le principe de moindre privilège. Pour ce faire, dressez la liste des ressources spécifiques auxquelles l'activité professionnelle peut accéder. Le modèle RBAC traditionnel a pour inconvénient de nécessiter la mise à jour des politiques pour autoriser l'accès aux nouvelles ressources ajoutées par les employés.

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

L'ABAC offre les avantages suivants par rapport au modèle RBAC traditionnel

• Les autorisations de l'ABAC sont évolutives. L'administrateur n'a plus besoin de mettre à jour les politiques existantes pour autoriser l'accès aux nouvelles ressources. Par exemple, supposons que vous ayez conçu votre stratégie ABAC avec la balise access-project Un développeur utilise le rôle avec la balise access-project = Heart. Lorsque des membres du projet Heart ont besoin de ressources Amazon EC2 supplémentaires, le développeur peut créer des instances Amazon EC2 avec la balise Heart = access-project. N'importe quel membre du projet Heart peut alors démarrer et arrêter ces instances, car leurs valeurs de balise correspondent.

• L'ABAC exige 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 à l'ABAC, les équipes peuvent évoluer et se développer rapidement. En effet, les autorisations d'accès aux nouvelles ressources sont automatiquement accordées en fonction des attributs. Par exemple, si votre entreprise prend déjà en charge les projets Heart et Star avec l'ABAC, il est facile d'ajouter un nouveau projet Lightning. Un administrateur IAM crée un rôle avec la balise access-project = Lightning. Il n'est pas nécessaire de modifier la politique pour prendre en charge un nouveau projet. Toute personne autorisée à endosser le rôle peut créer et afficher des instances balisées avec access-project = Lightning. En outre, un membre de l'équipe peut passer du projet Heart au projet Lightning. L'administrateur IAM attribue à l'utilisateur un rôle IAM différent. Il n'est pas nécessaire de modifier les politiques d'autorisations.

• Les autorisations détaillées sont possibles avec l'ABAC. Lorsque vous créez des politiques, la bonne pratique consiste à accorder un moindre privilège. Avec le modèle RBAC traditionnel, vous devez écrire une politique qui autorise l'accès à des ressources spécifiques uniquement. Avec l'ABAC, vous pouvez autoriser des actions sur toutes les ressources, mais uniquement si les balises de la ressource et du principal correspondent.

• Utilisez les attributs des employés figurant dans l'annuaire de votre entreprise avec l'ABAC. Vous pouvez configurer votre fournisseur SAML ou OIDC pour qu'il transmette des balises de session à. AWS Lorsque vos employés se fédérent dans AWS, leurs attributs sont appliqués au principal qui en résulte dans AWS. Vous pouvez ensuite utiliser l'ABAC pour autoriser ou refuser des autorisations sur la base de ces attributs.

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