SEC02-BP06 Utiliser des groupes d’utilisateurs et des attributs
La définition des autorisations en fonction des groupes d’utilisateurs et des attributs contribue à réduire le nombre et la complexité des politiques, ce qui simplifie la mise en œuvre du principe du moindre privilège. Vous pouvez utiliser des groupes d’utilisateurs pour gérer les autorisations de nombreuses personnes en un seul endroit selon la fonction qu’elles occupent au sein de votre organisation. Les attributs, tels que le service ou le lieu, peuvent fournir une couche supplémentaire de portée des autorisations lorsque des personnes occupent une fonction similaire, mais pour des sous-ensembles de ressources différents.
Résultat souhaité : vous pouvez appliquer des modifications aux autorisations selon la fonction, pour tous les utilisateurs qui exécutent cette même fonction. L’appartenance aux groupes et les attributs régissent les autorisations des utilisateurs, ce qui réduit la nécessité de gérer les autorisations au niveau de chaque utilisateur. Les groupes et les attributs que vous définissez dans votre fournisseur d’identité (IdP) sont propagés automatiquement à vos environnements AWS.
Anti-modèles courants :
-
Gestion des autorisations pour les utilisateurs individuels et duplication entre de nombreux utilisateurs.
-
Définition de groupes à un niveau trop élevé, autorisations trop étendues accordées.
-
Définition de groupes à un niveau trop détaillé, ce qui crée des duplications et de la confusion quant à l’appartenance.
-
Utilisation de groupes avec des autorisations dupliquées sur des sous-ensembles de ressources lorsque des attributs peuvent être utilisés à la place.
-
Aucune gestion de groupes, d’attributs et d’appartenances par le biais d’un fournisseur d’identité standardisé intégré à vos environnements AWS.
Niveau d’exposition au risque si cette bonne pratique n’est pas établie : moyen
Directives d’implémentation
Les autorisations AWS sont définies dans des documents appelés politiques qui sont associés à un principal, tel qu’un utilisateur, un groupe, un rôle ou une ressource. En ce qui concerne le personnel, cela vous permet de définir des groupes selon la fonction occupée par les utilisateurs au sein de votre organisation, plutôt que selon les ressources auxquelles ils accèdent. Par exemple, un groupe WebAppDeveloper
peut avoir une politique associée pour la configuration d’un service tel qu’Amazon CloudFront dans un compte de développement. Un groupe AutomationDeveloper
peut avoir certaines autorisations CloudFront en commun avec le groupe WebAppDeveloper
. Ces autorisations peuvent être capturées dans une politique distincte et associées aux deux groupes, au lieu d’avoir les utilisateurs des deux fonctions qui appartiennent à un groupe CloudFrontAccess
.
Outre les groupes, vous pouvez utiliser des attributs pour délimiter encore davantage l’accès. Par exemple, vous pouvez disposer d’un attribut Project
pour les utilisateurs de votre groupe WebAppDeveloper
afin de définir l’accès aux ressources spécifiques à leur projet. L’utilisation de cette technique élimine la nécessité de créer différents groupes pour les développeurs d’applications travaillant sur différents projets si leurs autorisations sont par ailleurs les mêmes. La façon dont vous faites référence aux attributs dans les politiques d’autorisation dépend de leur source, qu’ils soient définis dans le cadre de votre protocole de fédération (tel que SAML, OIDC ou SCIM), en tant qu’assertions SAML personnalisées ou définis dans le cadre d’IAM Identity Center.
Étapes d’implémentation
-
Déterminez où vous allez définir les groupes et les attributs.
-
En suivant les instructions fournies dans SEC02-BP04 S'appuyer sur un fournisseur d'identité centralisé, vous pouvez déterminer si vous devez définir des groupes et des attributs au sein de votre fournisseur d’identité, d’IAM Identity Center ou en utilisant des groupes IAM user dans un compte spécifique.
-
-
Définissez des groupes.
-
Déterminez vos groupes selon la fonction et la portée de l’accès requis.
-
Si vous optez pour une définition au sein d’IAM Identity Center, créez des groupes et associez le niveau d’accès souhaité à l’aide d’ensembles d’autorisations.
-
Si vous optez pour une définition au sein d’un fournisseur d’identité externe, déterminez si le fournisseur prend en charge le protocole SCIM et envisagez d’activer le provisionnement automatique au sein d’IAM Identity Center. Cette capacité synchronise la création, l’appartenance et la suppression de groupes entre votre fournisseur et IAM Identity Center.
-
-
Définissez des attributs.
-
Si vous utilisez un fournisseur d’identité externe, les protocoles SCIM et SAML 2.0 fournissent certains attributs par défaut. Des attributs supplémentaires peuvent être définis et transmis à l’aide d’assertions SAML en utilisant le nom d’attribut
https://aws.amazon.com/SAML/Attributes/PrincipalTag
. -
Si vous optez pour une définition au sein d’IAM Identity Center, activez la fonctionnalité de contrôle d’accès basé sur les attributs (ABAC) et définissez les attributs comme vous le souhaitez.
-
-
Déterminez la portée des autorisations en fonction des groupes et des attributs.
-
Envisagez d’inclure dans vos politiques d’autorisation des conditions qui comparent les attributs de votre principal à ceux des ressources auxquelles vous accédez. Par exemple, vous pouvez définir une condition de façon à autoriser l’accès à une ressource uniquement si la valeur d’une clé de condition
PrincipalTag
correspond à la valeur d’une cléResourceTag
du même nom.
-
Ressources
Bonnes pratiques associées :
Documents connexes :
Vidéos connexes :