Didacticiel IAM : utilisation de balises de session SAML pour le contrôle ABAC - AWS Identity and Access Management

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.

Didacticiel IAM : utilisation de balises de session SAML pour le contrôle ABAC

Le contrôle d’accès par attributs (ABAC) est une stratégie 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. Lorsque les entités sont utilisées pour envoyer des demandes AWS, elles deviennent des entités principales et ces entités incluent des balises.

Vous pouvez également transmettre des balises de session lorsque vous endossez un rôle ou fédérez un utilisateur. Vous pouvez ensuite définir des politiques qui utilisent des clés de condition de balise pour accorder des autorisations à vos principaux en fonction de leurs balises. Lorsque vous utilisez des balises pour contrôler l'accès à vos ressources AWS , vous autorisez vos équipes et vos ressources à se développer en modifiant moins les politiques AWS . Les politiques ABAC sont plus flexibles que AWS les politiques traditionnelles, qui vous obligent à répertorier chaque ressource individuelle. Pour de plus amples informations sur l'ABAC et ses avantages par rapport aux politiques traditionnelles, veuillez consulter À quoi sert ABAC ? AWS.

Si votre entreprise utilise un fournisseur d'identité (IdP, identity provider) basé sur SAML pour gérer les identités des utilisateurs de l'entreprise, vous pouvez utiliser les attributs SAML pour un contrôle d'accès affiné dans l’interface AWS. Les attributs peuvent inclure des identifiants de centre de coûts, des adresses e-mail d'utilisateurs, des classifications de services et des affectations de projet. Lorsque vous transmettez ces attributs en tant qu’étiquettes de session, vous pouvez ensuite contrôler l'accès à l’interface AWS en fonction de ces étiquettes de session.

Pour réaliser le didacticiel de l'ABAC en transmettant les attributs SAML à votre principal de session, effectuez les tâches de la section Tutoriel IAM : définir les autorisations d'accès aux AWS ressources en fonction des balises avec les modifications citées dans cette rubrique.

Prérequis

Pour réaliser les étapes d'utilisation des étiquettes de session SAML pour l'ABAC, vous devez déjà disposer des éléments suivants :

  • Un accès à un fournisseur d'identité basé sur SAML vous permettant de créer des utilisateurs test avec des attributs spécifiques.

  • La possibilité de se connecter en tant qu'utilisateur disposant d'autorisations d'administrateur.

  • Une expérience dans la création et la modification d'utilisateurs, de rôles et de politiques IAM dans AWS Management Console. Toutefois, si vous avez besoin d'aide pour vous souvenir d'un processus de gestion IAM, le didacticiel ABAC fournit des liens vers lesquels vous pouvez consulter step-by-step les instructions.

  • Une expérience dans la configuration d'un fournisseur d'identité SAML dans IAM. Pour afficher de plus amples informations et des liens vers la documentation détaillée IAM, veuillez consulter Transmission de balises de session à l'aide de AssumeRoleWith SAML.

Étape 1 : Créer des utilisateurs test

Ignorez les instructions de la section Étape 1 : Créer des utilisateurs test. Étant donné que vos identités sont définies dans votre fournisseur, il n'est pas nécessaire que vous ajoutiez des utilisateurs IAM pour vos employés.

Étape 2 : Créer la politique ABAC

Suivez les instructions de la section Étape 2 : Créer la politique ABAC pour créer la politique gérée spécifiée dans IAM.

Étape 3 : Créer et configurer le rôle SAML

Lorsque vous utilisez le didacticiel ABAC pour SAML, vous devez effectuer des étapes supplémentaires pour créer le rôle, configurer l'IdP SAML et activer l'accès. AWS Management Console Pour plus d’informations, consultez Étape 3 : Créer les rôles.

Étape 3A : Créer le rôle SAML

Créez un rôle unique qui approuve votre fournisseur d'identité SAML et l'utilisateur test-session-tags que vous avez créé à l'étape 1. Le didacticiel de l'ABAC utilise des rôles distincts avec des balises de rôle différentes. Étant donné que vous transmettez des balises de session à partir de votre fournisseur d'identité SAML, vous n'avez besoin que d'un seul rôle. Pour savoir comment créer un rôle basé sur SAML, veuillez consulter Création d'un rôle pour la fédération SAML 2.0 (console).

Nommez le rôle access-session-tags. Attachez la politique d'autorisation access-same-project-team au rôle. Modifiez la politique d'approbation de rôle pour utiliser la politique suivante. Pour obtenir des instructions détaillées sur la modification de la relation d'approbation d'un rôle, veuillez consulter Modification d'un rôle (console).

La politique d'approbation de rôle suivante permet à votre fournisseur d'identité SAML et à l'utilisateur test-session-tags d'endosser le rôle. Lorsqu'ils endossent le rôle, ils doivent transmettre les trois balises de session spécifiées. L'action sts:TagSession est requise pour autoriser la transmission des balises de session.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowSamlIdentityAssumeRole", "Effect": "Allow", "Action": [ "sts:AssumeRoleWithSAML", "sts:TagSession" ], "Principal": {"Federated":"arn:aws:iam::123456789012:saml-provider/ExampleCorpProvider"}, "Condition": { "StringLike": { "aws:RequestTag/cost-center": "*", "aws:RequestTag/access-project": "*", "aws:RequestTag/access-team": [ "eng", "qas" ] }, "StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"} } } ] }

La AllowSamlIdentityAssumeRole déclaration permet aux membres des équipes d'ingénierie et d'assurance qualité d'assumer ce rôle lorsqu'ils se fédérent avec l'IdP AWS d'Example Corporation. Le fournisseur SAML ExampleCorpProvider est défini dans IAM. L'administrateur a déjà configuré l'assertion SAML pour transmettre les trois balises de session requises. L'assertion peut transmettre des balises supplémentaires, mais ces trois balises doivent être présentes. Les attributs de l'identité peuvent avoir n'importe quelle valeur pour les balises cost-center et access-project. Toutefois, la valeur de l'attribut access-team doit correspondre à eng ou qas pour indiquer que l'identité se trouve dans l'équipe d'ingénierie ou d'assurance qualité.

Étape 3B : Configurer le fournisseur d'identité SAML

Configurez votre fournisseur d'identité SAML pour qu'il transmette les attributs cost-center, access-project et access-team en tant que balises de session. Pour de plus amples informations, veuillez consulter Transmission de balises de session à l'aide de AssumeRoleWith SAML.

Pour transmettre ces attributs en tant que balises de session, incluez les éléments suivants dans votre assertion SAML.

<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:cost-center"> <AttributeValue>987654</AttributeValue> </Attribute> <Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:access-project"> <AttributeValue>peg</AttributeValue> </Attribute> <Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:access-team"> <AttributeValue>eng</AttributeValue> </Attribute>

Étape 3C : Activer l'accès à la console

Activez l'accès à la console pour vos utilisateurs SAML fédérés. Pour de plus amples informations, veuillez consulter Permettre aux utilisateurs fédérés SAML 2.0 d'accéder au AWS Management Console.

Étape 4 : Tester la création de secrets

Fédérez-vous pour AWS Management Console utiliser le access-session-tags rôle. Pour plus d’informations, consultez Permettre aux utilisateurs fédérés SAML 2.0 d'accéder au AWS Management Console. Puis, suivez les instructions de la section Étape 4 : Tester la création de secrets pour créer des secrets. Utilisez différentes identités SAML avec des attributs pour correspondre aux balises indiquées dans le didacticiel de l'ABAC. Pour plus d’informations, veuillez consulter Étape 4 : Tester la création de secrets.

Étape 5 : Tester l'affichage des secrets

Suivez les instructions de la section Étape 5 : Tester l'affichage des secrets pour afficher les secrets que vous avez créés à l'étape précédente. Utilisez différentes identités SAML avec des attributs pour correspondre aux balises indiquées dans le didacticiel de l'ABAC.

Étape 6 : Tester l'adaptabilité

Suivez les instructions de la section Étape 6 : Tester l'adaptabilité pour tester l'évolutivité. Pour ce faire, ajoutez une nouvelle identité à votre fournisseur d'identité basé sur SAML avec les attributs suivants :

  • cost-center = 101010

  • access-project = cen

  • access-team = eng

Étape 7 : Tester la mise à jour et la suppression des secrets

Suivez les instructions de l'étape Étape 7 : Tester la mise à jour et la suppression des secrets pour mettre à jour et supprimer des secrets. Utilisez différentes identités SAML avec des attributs pour correspondre aux balises indiquées dans le didacticiel de l'ABAC.

Important

Supprimez tous les secrets que vous avez créés pour éviter les frais de facturation. Pour de plus amples informations sur la tarification de Secrets Manager, veuillez consulter Tarification AWS Secrets Manager.

Récapitulatif

Vous avez maintenant terminé avec succès toutes les étapes nécessaires pour utiliser les balises de session SAML et les balises de ressources pour la gestion des autorisations.

Note

Vous avez ajouté des politiques qui autorisent les actions uniquement dans des conditions spécifiques. Si vous appliquez une politique différente à vos utilisateurs ou rôles disposant d'autorisations plus larges, il se peut que les actions ne soient pas limitées pour demander le balisage. Par exemple, si vous accordez à un utilisateur des autorisations administratives complètes à l'aide de la politique AdministratorAccess AWS gérée, ces politiques ne limitent pas cet accès. Pour plus d'informations sur la façon dont les autorisations sont déterminées lorsque plusieurs politiques sont impliquées, veuillez consulter Identification d'une demande autorisée ou refusée dans un compte.