SEC02-BP06 Utiliser des groupes d’utilisateurs et des attributs - AWS Framework Well-Architected
Directives d’implémentationRessources

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.

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, le projet ou l’emplacement, 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 escompté : vous pouvez appliquer des modifications aux autorisations selon la fonction de tous les utilisateurs qui exécutent cette 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.

  • Utilisation du chaînage des rôles lors de l’utilisation de sessions AWS IAM Identity Center

Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : 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. Vous pouvez mettre à l’échelle la gestion des autorisations en organisant les attributions d’autorisations (groupe, autorisations, compte) en fonction de la fonction, de la charge de travail et de l’environnement SDLC. 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 être associé à une politique pour configurer des services tels qu’Amazon CloudFront au sein d’un compte de développement. Un groupe AutomationDeveloper peut avoir des autorisations qui se chevauchent avec le groupe WebAppDeveloper. Ces autorisations communes peuvent être saisies dans une politique distincte et associées aux deux groupes, au lieu de faire en sorte que les utilisateurs des deux fonctions appartiennent à un groupe CloudFrontAccess.

Outre les groupes, vous pouvez utiliser des attributs pour élargir l’accès. Par exemple, vous pouvez avoir un attribut de projet permettant aux utilisateurs de votre groupe WebAppDeveloper 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 qui travaillent 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

  1. Déterminez où vous allez définir les groupes et les attributs :

    1. 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é, dans IAM Identity Center ou utiliser des groupes d’utilisateurs IAM dans un compte spécifique.

  2. Définissez des groupes :

    1. Déterminez vos groupes selon la fonction et la portée de l’accès requis. Envisagez d’utiliser une structure hiérarchique ou des conventions de dénomination pour organiser efficacement les groupes.

    2. 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.

    3. 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.

  3. Définissez des attributs :

    1. 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 utilisant le nom de l’attribut https://aws.amazon.com/SAML/Attributes/PrincipalTag. Consultez la documentation de votre fournisseur d’identité pour obtenir des recommandations quant à la définition et la configuration d’attributs personnalisés.

    2. Si vous définissez des rôles dans IAM Identity Center, activez la fonctionnalité de contrôle d’accès par attributs (ABAC) et définissez les attributs comme vous le souhaitez. Tenez compte des attributs qui correspondent à la stratégie de balisage des ressources ou à la structure de votre organisation.

Si vous avez besoin d’un chaînage des rôles IAM à partir des rôles IAM assumés via IAM Identity Center, les valeurs telles que source-identity et principal-tags ne se propagent pas. Pour plus de détails, consultez Activer et configurer les attributs pour le contrôle d’accès.

  1. Déterminez la portée des autorisations en fonction des groupes et des attributs :

    1. 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 pour 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.

    2. Lorsque vous définissez des politiques ABAC, suivez les instructions figurant dans les bonnes pratiques et les exemples relatifs à l’autorisation ABAC.

    3. Passez régulièrement en revue et mettez à jour la structure de votre groupe et de vos attributs au fur et à mesure de l’évolution des besoins de votre organisation afin de garantir une gestion optimale des autorisations.

Ressources

Bonnes pratiques associées :

Documents connexes :

Vidéos connexes :