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.