IAMtutoriel : Définir les autorisations d'accès aux AWS ressources en fonction des balises

Le contrôle d'accès basé sur les attributs (ABAC) est une stratégie d'autorisation qui définit les autorisations en fonction des attributs. Dans AWS, ces attributs sont appelés balises. Vous pouvez associer des balises aux IAM ressources, y compris aux IAM entités (utilisateurs ou rôles) et aux AWS ressources. Vous pouvez 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 AWS ressources, vous permettez à vos équipes et à vos ressources de se développer en modifiant moins les AWS politiques. ABACles politiques sont plus flexibles que AWS les politiques traditionnelles, qui vous obligent à répertorier chaque ressource individuelle. Pour plus d'informations sur les politiques traditionnelles ABAC et leurs avantages par rapport aux politiques traditionnelles, consultezDéfinissez les autorisations en fonction des attributs avec ABAC autorisation.

Note

Vous devez transmettre une valeur unique pour chaque balise de session. AWS Security Token Service ne prend pas en charge les balises de session à valeurs multiples.

Rubriques

• Présentation du didacticiel
• Prérequis
• Étape 1 : Créer des utilisateurs test
• Étape 2 : Création de la ABAC politique
• Étape 3 : Créer les rôles
• Étape 4 : Tester la création de secrets
• Étape 5 : Tester l'affichage des secrets
• Étape 6 : Tester l'adaptabilité
• Étape 7 : Tester la mise à jour et la suppression des secrets
• Récapitulatif
• Ressources connexes
• IAMtutoriel : Utiliser les balises de SAML session pour ABAC

Présentation du didacticiel

Ce didacticiel explique comment créer et tester une politique qui permet aux IAM rôles dotés de balises principales d'accéder aux ressources dont les balises correspondent. Lorsqu'un principal fait une demande à AWS, les autorisations lui sont accordées si sa balise correspond à celle des ressources. Cette stratégie permet aux individus de consulter ou de modifier uniquement les AWS ressources nécessaires à leur travail.

Scénario

Supposons que vous soyez développeur principal dans une grande entreprise nommée Example Corporation et que vous soyez un IAM administrateur expérimenté. Vous êtes habitué à créer et à gérer des IAM utilisateurs, des rôles et des politiques. Vous voulez vous assurer que vos ingénieurs en développement et les membres de l'équipe d'assurance qualité peuvent accéder aux ressources dont ils ont besoin. Vous avez également besoin d'une stratégie qui évolue en même temps que votre entreprise.

Vous choisissez d'utiliser les balises de AWS ressources et les balises principales de IAM rôle pour mettre en œuvre une ABAC stratégie pour les services qui la prennent en charge, en commençant par AWS Secrets Manager. Pour connaître les services prenant en charge l'autorisation basée sur des balises, veuillez consulter AWS des services qui fonctionnent avec IAM. Pour savoir quelles clés de condition de balisage vous pouvez utiliser dans une politique concernant les actions et les ressources de chaque service, consultez la section Actions, ressources et clés de condition pour les AWS services. Vous pouvez configurer votre fournisseur d'identité SAML basé ou Web pour qu'il transmette les balises de session à AWS. Lorsque vos employés se fédérent dans AWS, leurs attributs sont appliqués au principal qui en résulte dans AWS. Vous pouvez ensuite utiliser ABAC pour autoriser ou refuser des autorisations en fonction de ces attributs. Pour savoir en quoi l'utilisation de balises de session avec une identité SAML fédérée diffère de ce didacticiel, consultezIAMtutoriel : Utiliser les balises de SAML session pour ABAC.

Les membres de votre équipe d'ingénierie et d'assurance qualité sont sur le projet Pegasus ou le projet Unicorn. Vous sélectionnez les valeurs de balise de 3 caractères ci-dessous pour les projets et l'équipe :

• access-project = peg pour le projet Pegasus

• access-project = uni pour le projet Unicorn

• access-team = eng pour l'équipe d'ingénierie

• access-team = qas pour l'équipe d'assurance qualité

En outre, vous choisissez d'exiger l'étiquette de répartition des cost-center coûts pour activer les rapports AWS de facturation personnalisés. Pour plus d'informations, consultez Utilisation des balises d'allocation des coûts dans le Guide de l'utilisateur AWS Billing and Cost Management .

Résumé des décisions clés

• Les employés se connectent à IAM l'aide des informations d'identification utilisateur, puis assument le IAM rôle de leur équipe et de leur projet. Si votre entreprise possède son propre système d'identité, vous pouvez configurer la fédération pour permettre aux employés d'assumer un rôle sans IAM utilisateurs. Pour plus d’informations, consultez IAMtutoriel : Utiliser les balises de SAML session pour ABAC.

• La même politique est attachée à tous les rôles. Les actions sont autorisées ou refusées en fonction des balises.

• Les employés peuvent créer des ressources, mais uniquement s'ils attachent à la ressource les balises qui sont appliquées à leur rôle. Ils peuvent ainsi afficher la ressource après l'avoir créée. Les administrateurs ne sont plus tenus de mettre à jour les politiques avec ARN les nouvelles ressources.

• Les employés peuvent lire les ressources appartenant à leur équipe, quel que soit le projet.

• Les employés peuvent mettre à jour et supprimer des ressources appartenant à leur équipe et à leur projet.

• IAMles administrateurs peuvent ajouter un nouveau rôle pour les nouveaux projets. Ils peuvent créer et étiqueter un nouvel IAM utilisateur pour lui permettre d'accéder au rôle approprié. Les administrateurs ne sont pas tenus de modifier une politique pour prendre en charge un nouveau projet ou membre de l'équipe.

Dans ce didacticiel, vous allez baliser chaque ressource, baliser les rôles de votre projet et ajouter des politiques aux rôles afin d'autoriser le comportement décrit précédemment. La politique qui en résulte autorise les rôles Create, Read, Update et Delete à accéder aux ressources qui ont les mêmes balises que le projet et l'équipe. La politique autorise également l'accès Read interprojet pour les ressources qui ont les mêmes balises que l'équipe.

Prérequis

Pour exécuter les étapes de ce didacticiel, vous devez déjà disposer des éléments suivants :

• Et Compte AWS auquel vous pouvez vous connecter en tant qu'utilisateur disposant d'autorisations administratives.

• Votre ID de compte à 12 chiffres, que vous utilisez pour créer les rôles à l'étape 3.

  Pour trouver le numéro d'identification de votre AWS compte à l'aide du AWS Management Console, choisissez Support dans la barre de navigation en haut à droite, puis sélectionnez Support Center. Le numéro de compte (ID) apparaît dans le panneau de navigation à gauche.

  

• Expérience en matière de création et de modification d'IAMutilisateurs, de rôles et de politiques dans le AWS Management Console. Toutefois, si vous avez besoin d'aide pour vous souvenir d'un processus de IAM gestion, ce didacticiel fournit des liens permettant de consulter step-by-step les instructions.

Étape 1 : Créer des utilisateurs test

Pour les tests, créez quatre IAM utilisateurs autorisés à assumer des rôles avec les mêmes balises. Cela facilite l'ajout d'utilisateurs à vos équipes. Lorsque vous balisez les utilisateurs, ces derniers bénéficient d'un automatiquement d'un accès pour endosser le rôle. Vous n'avez pas à ajouter les utilisateurs à la politique d'approbation du rôle s'ils travaillent sur un seul projet et dans une seule équipe.

1. Créez la politique gérée par le client ci-dessous et nommez-la access-assume-role. Pour plus d'informations sur la création d'une JSON politique, consultezCréation de politiques IAM.

   ABACpolitique : assumez n'importe quel ABAC rôle, mais uniquement lorsque les balises utilisateur et rôle correspondent

   La politique suivante autorise un utilisateur à endosser n'importe quel rôle de votre compte avec le préfixe de nom access-. Le rôle doit également être balisé avec les mêmes balises de projet, d'équipe et de centre de coûts que l'utilisateur.

   Pour utiliser cette politique, remplacez le texte en italique de l'espace réservé dans l'exemple de politique par vos propres informations de compte.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "TutorialAssumeRole",
               "Effect": "Allow",
               "Action": "sts:AssumeRole",
               "Resource": "arn:aws:iam::account-ID-without-hyphens:role/access-*",
               "Condition": {
                   "StringEquals": {
                       "iam:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
                       "iam:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
                       "iam:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
                   }
               }
           }
       ]
   }

   Pour étendre ce didacticiel à un plus grand nombre d'utilisateurs, vous pouvez attacher la politique à un groupe et ajouter chaque utilisateur au groupe. Pour plus d’informations, consultez Création de groupes d'utilisateurs IAM et Ajout et suppression d'utilisateurs dans un groupe IAM.

2. Créez les IAM utilisateurs suivants, joignez la politique access-assume-role d'autorisation. Assurez-vous de sélectionner Fournir un accès utilisateur à la AWS Management Console, puis d'ajouter les balises suivantes. Pour de plus amples informations sur la création et le balisage d'un utilisateur, veuillez consulter Création d'utilisateurs IAM (console).

   Nom utilisateur	Clé de balise utilisateur	Valeur de balise utilisateur
   Accès-A rnav-peg-eng	access-project access-team cost-center	peg eng 987654
   Accès-m ary-peg-qas	access-project access-team cost-center	peg qas 987654
   Accès-S aanvi-uni-eng	access-project access-team cost-center	uni eng 123456
   Accès-C arlos-uni-qas	access-project access-team cost-center	uni qas 123456

Étape 2 : Création de la ABAC politique

Créez la politique suivante et nommez-la access-same-project-team. Vous allez ajouter cette politique aux rôles ultérieurement. Pour plus d'informations sur la création d'une JSON politique, consultezCréation de politiques IAM.

Pour accéder à des politiques supplémentaires que vous pouvez adapter pour ce didacticiel, veuillez consulter les pages suivantes :

• Contrôle de l'accès pour les principaux IAM

• Amazon EC2 : autorise le démarrage ou l'arrêt des instances EC2 balisées par un utilisateur, par programmation et dans la console

• EC2 : démarrer ou arrêter les instances en fonction des balises de ressources et de principaux correspondantes

• EC2 : démarrer ou arrêter les instances en fonction des balises

• IAM : endosser des rôles qui ont une balise spécifique

ABACPolitique : Accédez aux ressources de Secrets Manager uniquement lorsque les balises principale et ressource correspondent

La politique suivante autorise les principaux à créer, lire, modifier et supprimer des ressources, mais uniquement lorsque ces ressources sont balisées avec les mêmes paires clé-valeur que le principal. Lorsqu'un principal crée une ressource, il doit ajouter les balises access-project, access-team et cost-center avec des valeurs qui correspondent aux balises du principal. La politique autorise également l'ajout de balises Name ou OwnedBy facultatives.

{
 "Version": "2012-10-17",
 "Statement": [
     {
         "Sid": "AllActionsSecretsManagerSameProjectSameTeam",
         "Effect": "Allow",
         "Action": "secretsmanager:*",
         "Resource": "*",
         "Condition": {
             "StringEquals": {
                 "aws:ResourceTag/access-project": "${aws:PrincipalTag/access-project}",
                 "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}",
                 "aws:ResourceTag/cost-center": "${aws:PrincipalTag/cost-center}"
             },
             "ForAllValues:StringEquals": {
                 "aws:TagKeys": [
                     "access-project",
                     "access-team",
                     "cost-center",
                     "Name",
                     "OwnedBy"
                 ]
             },
             "StringEqualsIfExists": {
                 "aws:RequestTag/access-project": "${aws:PrincipalTag/access-project}",
                 "aws:RequestTag/access-team": "${aws:PrincipalTag/access-team}",
                 "aws:RequestTag/cost-center": "${aws:PrincipalTag/cost-center}"
             }
         }
     },
     {
         "Sid": "AllResourcesSecretsManagerNoTags",
         "Effect": "Allow",
         "Action": [
             "secretsmanager:GetRandomPassword",
             "secretsmanager:ListSecrets"
         ],
         "Resource": "*"
     },
     {
         "Sid": "ReadSecretsManagerSameTeam",
         "Effect": "Allow",
         "Action": [
             "secretsmanager:Describe*",
             "secretsmanager:Get*",
             "secretsmanager:List*"
         ],
         "Resource": "*",
         "Condition": {
             "StringEquals": {
                 "aws:ResourceTag/access-team": "${aws:PrincipalTag/access-team}"
             }
         }
     },
     {
         "Sid": "DenyUntagSecretsManagerReservedTags",
         "Effect": "Deny",
         "Action": "secretsmanager:UntagResource",
         "Resource": "*",
         "Condition": {
             "ForAnyValue:StringLike": {
                 "aws:TagKeys": "access-*"
             }
         }
     },
     {
         "Sid": "DenyPermissionsManagement",
         "Effect": "Deny",
         "Action": "secretsmanager:*Policy",
         "Resource": "*"
     }
 ]
}

À quoi sert cette politique ?

• La instruction AllActionsSecretsManagerSameProjectSameTeam autorise toutes les actions de ce service sur toutes les ressources associées, mais uniquement si les balises des ressources correspondent aux balises du principal. En ajoutant "Action": "secretsmanager:*" à la politique, cette dernière évolue en même temps que Secrets Manager. Si Secrets Manager ajoute une nouvelle API opération, vous n'êtes pas obligé de l'ajouter à l'instruction. L'instruction est implémentée ABAC à l'aide de trois blocs de conditions. La demande n'est autorisée que si les trois blocs renvoient la valeur « true » (vrai).

  • Le premier bloc de condition de cette instruction renvoie la valeur true si les clés de balise spécifiées sont présentes sur la ressource et que leurs valeurs correspondent aux balises du principal. Ce bloc renvoie la valeur « false » (faux) pour les étiquettes qui ne correspondent pas, ou pour les actions qui ne prennent pas en charge l’étiquettage des ressources. Pour savoir quelles actions ne sont pas autorisées par ce bloc, voir Actions, ressources et clés de condition pour AWS Secrets Manager. Cette page montre que les actions effectuées sur le type de ressource Secret prennent en charge la clé de condition secretsmanager:ResourceTag/tag-key. Certaines actions Secrets Manager ne prennent pas en charge ce type de ressource, y compris GetRandomPassword et ListSecrets. Vous devez créer des instructions supplémentaires pour autoriser ces actions.

  • Le deuxième bloc de condition renvoie la valeur « true » (vrai) si chaque clé d’identification transmise dans la demande figure dans la liste spécifiée. Cette opération est effectuée en utilisant ForAllValues avec l'opérateur de condition StringEquals. Si aucune clé ni sous-ensemble de l'ensemble de clés n'est transmis, la condition renvoie la valeur « true » (vrai). Cela permet les opérations Get* qui n'autorisent pas l’inclusion des étiquettes dans la demande. Si le demandeur inclut une clé d’identification qui ne figure pas dans la liste, la condition renvoie la valeur « false » (faux) Chaque clé de balise transmise dans la demande doit correspondre à un membre de cette liste. Pour plus d’informations, consultez Clés de contexte à valeurs multiples.

  • Le troisième bloc de condition renvoie la valeur « true » (vrai) si la demande prend en charge la transmission des étiquettes, si les trois étiquettes sont présentes et si elles correspondent aux valeurs de l’étiquette principale. Ce bloc renvoie également la valeur « true » (vrai) si la demande ne prend pas en charge la transmission des étiquettes. C'est grâce à ...IfExists dans l'opérateur de condition. Le bloc renvoie la valeur « false » (faux) si aucune étiquette n'est transmise pendant une action qui la prend en charge, ou si les clés et les valeurs d’étiquette ne correspondent pas.

• La instruction AllResourcesSecretsManagerNoTags autorise les actions GetRandomPassword et ListSecrets qui ne sont pas autorisées par la première instruction.

• La instruction ReadSecretsManagerSameTeam autorise les opérations en lecture seule si le principal est balisé avec la même balise access-team que la ressource. Ceci est autorisé indépendamment de l’étiquette du projet ou du centre de coûts.

• La instruction DenyUntagSecretsManagerReservedTags refuse les demandes de suppression de balises avec des clés commençant par « access- » de Secrets Manager. Ces balises servent à contrôler l'accès aux ressources. Leur suppression pourrait supprimer des autorisations.

• La déclaration DenyPermissionsManagement refuse l'accès à la création, à la modification ou à la suppression de politiques basées sur les ressources de Secrets Manager. Ces politiques peuvent être utilisées pour modifier les autorisations du secret.

Important

Cette politique utilise une stratégie qui autorise toutes les actions d'un service, mais refuse explicitement les actions de modification des autorisations. Le refus d'une action remplace toute autre politique autorisant le principal à effectuer cette action. Ce refus peut entraîner des résultats imprévus. La bonne pratique consiste à utiliser uniquement le refus explicite lorsqu'aucune circonstance ne doit autoriser cette action. Sinon, dressez la liste des actions autorisées. Les actions indésirables seront refusées par défaut.

Étape 3 : Créer les rôles

Créez les IAM rôles suivants et associez la access-same-project-team politique que vous avez créée à l'étape précédente. Pour plus d'informations sur la création de IAM rôles, consultezCréation d'un rôle pour déléguer des autorisations à un IAM utilisateur. Si vous choisissez d'utiliser la fédération plutôt que les IAM utilisateurs et les rôles, consultezIAMtutoriel : Utiliser les balises de SAML session pour ABAC.

Fonction de tâche	Nom du rôle	Balises de rôle	Description du rôle
Ingénierie du projet Pegasus	access-peg-engineering	projet d'accès = peg équipe d'accès = eng centre de coûts = 987654	Autorise les ingénieurs à lire toutes les ressources d'ingénierie et à créer et gérer les ressources d'ingénierie du projet Pegasus.
Assurance qualité du projet Pegasus	access-peg-quality-assurance	projet d'accès = peg équipe d'accès = qas centre de coûts = 987654	Autorise l'équipe d'assurance qualité à lire toutes les ressources d'assurance qualité et à créer et gérer toutes les ressources d'assurance qualité du projet Pegasus.
Ingénierie du projet Unicorn	access-uni-engineering	access-project= uni équipe d'accès = eng centre de coûts = 123456	Autorise les ingénieurs à lire toutes les ressources d'ingénierie et à créer et gérer les ressources d'ingénierie du projet Unicorn.
Assurance qualité du projet Unicorn	access-uni-quality-assurance	projet d'accès = uni équipe d'accès = qas centre de coûts = 123456	Autorise l'équipe d'assurance qualité à lire toutes les ressources d'assurance qualité et à créer et gérer toutes les ressources d'assurance qualité du projet Unicorn.

Étape 4 : Tester la création de secrets

La politique d'autorisation attachée aux rôles autorise les employés à créer des secrets. Ceci n'est autorisé que si le secret est labelisé au niveau du projet, de l’équipe et du centre de coûts. Vérifiez que vos autorisations fonctionnent comme prévu en vous connectant comme vos utilisateurs, en endossant le bon rôle et en testant l'activité dans Secrets Manager.

Pour tester la création d'un secret avec et sans les balises requises

1. Dans la fenêtre principale de votre navigateur, restez connecté en tant qu'utilisateur administrateur afin de pouvoir consulter les utilisateurs, les rôles et les politiquesIAM. Utilisez une fenêtre de navigation privée ou un navigateur séparé pour votre test. Ensuite, connectez-vous en tant qu'access-Arnav-peg-engIAMutilisateur et ouvrez la console Secrets Manager à l'adresse https://console.aws.amazon.com/secretsmanager/.

2. Tentez de basculer vers le rôle access-uni-engineering.

   Cette opération échoue, car les valeurs de balise access-project et cost-center ne correspondent pas à l'utilisateur access-Arnav-peg-eng et au rôle access-uni-engineering.

   Pour plus d'informations sur le changement de rôle dans le AWS Management Console, voir Basculer vers un rôle (console)

3. Basculez vers le rôle access-peg-engineering.

4. Enregistrez un nouveau secret en utilisant les informations suivantes. Pour savoir comment enregistrer un secret, veuillez consulter Création d'un secret basique dans le Guide de l'utilisateur AWS Secrets Manager .

   Important

   Secrets Manager affiche des alertes indiquant que vous ne disposez pas d'autorisations pour des services AWS supplémentaires qui fonctionnent avec Secrets Manager. Par exemple, pour créer des informations d'identification pour une RDS base de données Amazon, vous devez être autorisé à décrire RDS les instances, les RDS clusters et les clusters Amazon Redshift. Vous pouvez ignorer ces alertes car vous n'utilisez pas ces AWS services spécifiques dans ce didacticiel.

   1. Dans la section Sélectionner un type de secret sélectionnez Autre type de secrets. Dans les deux zones de texte, saisissez test-access-key et test-access-secret.

   2. Saisissez test-access-peg-eng dans le champ Nom du secret .

   3. Ajoutez différentes combinaisons de balises du tableau suivant et visualisez le comportement attendu.

   4. Choisissez Stocker pour tenter de créer le secret. Si le stockage échoue, revenez aux pages précédentes de la console Secrets Manager et utilisez l'ensemble de balises suivant dans le tableau ci-dessous. Le dernier ensemble de balises est autorisé et crée le secret avec succès.

   Le tableau suivant présente les combinaisons de ABAC balises associées au test-access-peg-eng rôle.

   access-project Valeur de l’étiquette	access-team Valeur de l’étiquette	cost-center Valeur de l’étiquette	Balises supplémentaires	Comportement attendu
   (aucun)	(aucun)	(aucun)	(aucun)	Refusé, car la valeur de la balise access-project ne correspond pas à la valeur peg du rôle.
   uni	eng	987654	(aucun)	Refusé, car la valeur de la balise access-project ne correspond pas à la valeur peg du rôle.
   peg	qas	987654	(aucun)	Refusé, car la valeur de la balise access-team ne correspond pas à la valeur eng du rôle.
   peg	eng	123456	(aucun)	Refusé, car la valeur de la balise cost-center ne correspond pas à la valeur 987654 du rôle.
   peg	eng	987654	Propriétaire = Jane	Refusé, car la balise owner supplémentaire n'est pas autorisée par la politique, même si les trois balises requises sont présentes et que leurs valeurs correspondent à celles du rôle.
   peg	eng	987654	Nom = Jane	Autorisé, car les trois balises obligatoires sont présentes et leurs valeurs correspondent aux valeurs du rôle. Vous êtes également autorisé à inclure la balise Name facultative.

5. Déconnectez-vous et répétez les trois premières étapes de cette procédure pour chaque rôle et chaque valeur de balise ci-dessous. À la quatrième étape de cette procédure, testez tous les ensembles de balises manquantes, de balises facultatives, de balises non autorisées et de valeurs de balises non valides de votre choix. Puis, utilisez les balises requises pour créer un secret avec les balises et le nom suivants.

   Nom utilisateur	Nom du rôle	Nom du secret	Balises du secret
   Accès-m ary-peg-qas	access-peg-quality-assurance	test-access-peg-qas	projet d'accès = peg équipe d'accès = qas centre de coûts = 987654
   Accès-S aanvi-uni-eng	access-uni-engineering	test-access-uni-eng	projet d'accès = uni équipe d'accès = eng centre de coûts = 123456
   Accès-C arlos-uni-qas	access-uni-quality-assurance	test-access-uni-qas	projet d'accès = uni équipe d'accès = qas centre de coûts = 123456

Étape 5 : Tester l'affichage des secrets

La politique que vous avez attachée à chaque rôle autorise les employés à afficher tous les secrets labelisés avec leur nom d'équipe, quel que soit leur projet. Vérifiez que vos autorisations fonctionnent comme prévu en testant vos rôles dans Secrets Manager.

Pour tester l'affichage d'un secret avec et sans les balises requises

1. Connectez-vous en tant que l'un des IAM utilisateurs suivants :

   • access-Arnav-peg-eng

   • access-Mary-peg-qas

   • access-Saanvi-uni-eng

   • access-Carlos-uni-qas

2. Basculez vers le rôle correspondant :

   • access-peg-engineering

   • access-peg-quality-assurance

   • access-uni-engineering

   • access-uni-quality-assurance

   Pour plus d'informations sur le changement de rôle dans le AWS Management Console, consultezBasculer vers un rôle (console).

3. Dans le panneau de navigation de gauche, sélectionnez l'icône de menu permettant de développer le menu, puis sélectionnez Secrets.

4. Vous devriez voir les quatre secrets du tableau, quel que soit votre rôle actuel. C'est le comportement attendu, car la politique nommée access-same-project-team autorise l'action secretsmanager:ListSecrets pour toutes les ressources.

5. Choisissez l'un des secrets.

6. Sur la page détaillée du secret, les étiquettes de votre rôle déterminent si vous pouvez afficher le contenu de la page. Comparez le nom de votre rôle avec celui de votre secret. S'ils ont le même nom d'équipe, alors les balises access-team correspondent. Si elles ne correspondent pas, l'accès est refusé.

   Le tableau suivant indique le comportement d'affichage ABAC secret pour chaque rôle.

   Nom du rôle	Nom du secret	Comportement attendu
   access-peg-engineering	test-access-peg-eng	Autorisé
   	test-access-peg-qas	Refusé
   	test-access-uni-eng	Autorisé
   	test-access-uni-qas	Refusé
   access-peg-quality-assurance	test-access-peg-eng	Refusé
   	test-access-peg-qas	Autorisé
   	test-access-uni-eng	Refusé
   	test-access-uni-qas	Autorisé
   access-uni-engineering	test-access-peg-eng	Autorisé
   	test-access-peg-qas	Refusé
   	test-access-uni-eng	Autorisé
   	test-access-uni-qas	Refusé
   access-uni-quality-assurance	test-access-peg-eng	Refusé
   	test-access-peg-qas	Autorisé
   	test-access-uni-eng	Refusé
   	test-access-uni-qas	Autorisé

7. Dans les miniatures en haut de la page, sélectionnez Secrets pour revenir à la liste des secrets. Répétez les étapes de cette procédure en utilisant différents rôles pour vérifier si vous pouvez afficher chacun des secrets.

Étape 6 : Tester l'adaptabilité

L'évolutivité est l'une des principales raisons d'utiliser le contrôle d'accès basé sur les attributs (ABAC) plutôt que le contrôle d'accès basé sur les rôles (RBAC). Au fur et à mesure que votre entreprise ajoute de nouveaux projets, équipes ou personnes AWS, vous n'avez pas besoin de mettre à jour vos politiques ABAC définies. Par exemple, supposons que la société Exemple finance un nouveau projet, dont le nom de code est Centaur. Un ingénieur nommé Saanvi Sarkar sera l'ingénieur principal du projet Centaur tout en continuant à travailler sur le projet Unicorn . Saanvi passera également en revue les travaux du projet Pegasus. Plusieurs ingénieurs embauchés récemment, dont Nikhil Jayashankar, travailleront exclusivement sur le projet Centaur .

Pour ajouter le nouveau projet à AWS

1. Connectez-vous en tant qu'utilisateur IAM administrateur et ouvrez la IAM console à l'adresse https://console.aws.amazon.com/iam/.

2. Dans le volet de navigation de gauche, choisissez Rôles et ajoutez un IAM rôle nomméaccess-cen-engineering. Attachez la politique d'autorisation access-same-project-team au rôle et ajoutez les balises de rôle suivantes :

   • access-project = cen

   • access-team = eng

   • cost-center = 101010

3. Dans le panneau de navigation de gauche, sélectionnez Users (Utilisateurs).

4. Ajoutez un nouvel utilisateur nommé access-Nikhil-cen-eng, attachez la politique nommée access-assume-role, et ajoutez les balises utilisateur suivantes.

   • access-project = cen

   • access-team = eng

   • cost-center = 101010

5. Utilisez les procédures des sections Étape 4 : Tester la création de secrets et Étape 5 : Tester l'affichage des secrets. Dans une autre fenêtre de navigateur, vérifiez que Nikhil ne peut créer que des secrets d'ingénierie pour le projet Centaur et qu'il peut afficher tous les secrets d'ingénierie.

6. Dans la fenêtre principale du navigateur à partir de laquelle vous vous êtes connecté en tant qu'administrateur, sélectionnez l'utilisateur access-Saanvi-uni-eng.

7. Dans l'onglet Autorisations, supprimez la politique access-assume-roled'autorisations.

8. Ajoutez la politique en ligne ci-dessous et nommez-la access-assume-specific-roles. Pour de plus amples informations sur l'intégration d'une politique en ligne pour un utilisateur, veuillez consulter Pour intégrer une politique en ligne pour un utilisateur ou un rôle (console).

   ABACpolitique : assumer uniquement des rôles spécifiques

   Cette politique autorise Saanvi à assumer les rôles d'ingénierie pour les projets Pegasus et Centaure. Il est nécessaire de créer cette politique personnalisée car elle IAM ne prend pas en charge les balises à valeurs multiples. Vous ne pouvez pas baliser l'utilisateur Saanvi avec access-project = peg et access-project = cen. De plus, le modèle AWS d'autorisation ne peut pas correspondre aux deux valeurs. Pour plus d’informations, consultez Règles de balisage dans IAM et AWS STS. Vous devez spécifier manuellement les deux rôles qu'elle peut endosser.

   Pour utiliser cette politique, remplacez le texte en italique de l'espace réservé dans l'exemple de politique par vos propres informations de compte.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "TutorialAssumeSpecificRoles",
               "Effect": "Allow",
               "Action": "sts:AssumeRole",
               "Resource": [
                   "arn:aws:iam::account-ID-without-hyphens:role/access-peg-engineering",
                   "arn:aws:iam::account-ID-without-hyphens:role/access-cen-engineering"
               ]
           }
       ]
   }

9. Utilisez les procédures des sections Étape 4 : Tester la création de secrets et Étape 5 : Tester l'affichage des secrets. Dans une autre fenêtre du navigateur, vérifiez que Saanvi peut endosser les deux rôles. Vérifiez qu'elle peut créer des secrets uniquement pour son projet, son équipe et son centre de coûts, en fonction des balises du rôle. Vérifiez également qu'elle peut afficher les détails de tous les secrets appartenant à l'équipe d'ingénierie, y compris ceux qu'elle vient de créer.

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

La politique access-same-project-team attachée aux rôles autorise les employés à mettre à jour et à supprimer tous les secrets possédant les mêmes balises que leur projet, leur équipe et leur centre de coûts. Vérifiez que vos autorisations fonctionnent comme prévu en testant vos rôles dans Secrets Manager.

Pour tester la mise à jour et la suppression d'un secret avec et sans les balises requises

1. Connectez-vous en tant que l'un des IAM utilisateurs suivants :

   • access-Arnav-peg-eng

   • access-Mary-peg-qas

   • access-Saanvi-uni-eng

   • access-Carlos-uni-qas

   • access-Nikhil-cen-eng

2. Basculez vers le rôle correspondant :

   • access-peg-engineering

   • access-peg-quality-assurance

   • access-uni-engineering

   • access-peg-quality-assurance

   • access-cen-engineering

   Pour plus d'informations sur le changement de rôle dans le AWS Management Console, consultezBasculer vers un rôle (console).

3. Pour chaque rôle, mettez à jour la description du secret, puis supprimez les secrets suivants. Pour de plus amples informations, veuillez consulter Modification d'un secret et Suppression et restauration d'un secret dans le Guide de l'utilisateur AWS Secrets Manager .

   Le tableau suivant montre le comportement de mise à jour et de suppression ABAC secrètes pour chaque rôle.

   Nom du rôle	Nom du secret	Comportement attendu
   access-peg-engineering	test-access-peg-eng	Autorisé
   	test-access-uni-eng	Refusé
   	test-access-uni-qas	Refusé
   access-peg-quality-assurance	test-access-peg-qas	Autorisé
   	test-access-uni-eng	Refusé
   access-uni-engineering	test-access-uni-eng	Autorisé
   	test-access-uni-qas	Refusé
   access-peg-quality-assurance	test-access-uni-qas	Autorisé

Récapitulatif

Vous avez maintenant effectué avec succès toutes les étapes nécessaires à l'utilisation des balises pour le contrôle d'accès basé sur les attributs ()ABAC. Vous avez appris à définir une stratégie de balisage. Vous avez appliqué cette stratégie à vos principaux et à vos ressources. Vous avez créé et appliqué une politique qui met exécute la stratégie pour Secrets Manager. Vous avez également appris qu'il ABAC évolue facilement lorsque vous ajoutez de nouveaux projets et de nouveaux membres à l'équipe. Par conséquent, vous pouvez vous connecter à la IAM console avec vos rôles de test et découvrir comment utiliser des balises pour ABAC entrer AWS.

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.

Ressources connexes

Pour plus d'informations, consultez les ressources suivantes :

• Définissez les autorisations en fonction des attributs avec ABAC autorisation

• AWS clés contextuelles de condition globale

• Création d'utilisateurs IAM (console)

• Création d'un rôle pour déléguer des autorisations à un IAM utilisateur

• Balisage des ressources IAM

• Contrôle de l'accès aux AWS ressources à l'aide de balises

• Basculer vers un rôle (console)

• IAMtutoriel : Utiliser les balises de SAML session pour ABAC

Pour savoir comment surveiller les balises de votre compte, consultez Surveiller les modifications des balises sur les AWS ressources avec des flux de travail sans serveur et Amazon CloudWatch Events.