Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

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

Mode de mise au point
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.

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.

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 attacher des balises aux ressources IAM, y compris aux entités IAM (utilisateurs ou rôles) et aux ressources AWS. Lorsque les entités sont utilisées pour soumettre des requêtes à AWS, elles deviennent des principaux et ces principaux 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 souples que les politiques AWS traditionnelles, ce qui vous oblige à répertorier chaque ressource. Pour de plus amples informations sur l'ABAC et ses avantages par rapport aux politiques traditionnelles, veuillez consulter Définition des autorisations en fonction des attributs avec autorisation ABAC.

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 Didacticiel IAM : définir les autorisations d'accès aux ressources AWS 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 mémoriser un processus de gestion IAM, le didacticiel de l'ABAC fournit des liens vers les instructions étape par étape.

  • 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 avec AssumeRoleWithSAML.

É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 réaliser des étapes supplémentaires pour créer le rôle, configurer le fournisseur d'identité SAML et activer l'accès à l’interface AWS Management Console. Pour de plus amples informations, veuillez consulter É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 Mise à jour d’une politique d’approbation de rôle .

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"} } } ] }

Cette instruction AllowSamlIdentityAssumeRole autorise les membres des équipes d'ingénierie et d'assurance qualité à endosser ce rôle lorsqu'ils se fédèrent dans AWS à partir du fournisseur d'identité 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 avec AssumeRoleWithSAML.

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 dans la AWS Management Console à l'aide du rôle access-session-tags. Pour plus d’informations, veuillez consulter 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 gérée par AWS, ces politiques ne restreignent 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 Comment la logique du code d’application AWS évalue les demandes d’autorisation ou de refus d’accès.

ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.