Gérez une équipe avec des groupes IAM

Introduction

Deux analystes ont besoin du même accès aux rapports. Vous gérerez une politique partagée, transférerez la responsabilité des rapports d'Alice à Bob et vérifierez qu'un ancien membre perd cet accès.

Terminez d'abord Accordez le moindre privilège à un lecteur de rapports pour les politiques d'identité et les requêtes autorisées ou refusées. Cette nouvelle VM fournit default pour l'administration et alice, bob et outsider pour les tests. Utilisez /home/labex/project et AWS View pour comparer l'appartenance aux groupes avec les lectures réelles.

Lien avec les certifications

Vue d’ensemble du lab

Créez une équipe et une politique partagée

Dans cette étape, vous créerez un groupe vide et attacherez une politique intégrée. Un groupe est un objet de gestion des autorisations, pas une nouvelle identité pour les requêtes. Confirmez d'abord l'opérateur et Alice avec STS ; leurs ARN devraient se terminer respectivement par user/iam02-operator et user/alice.

L’équipe a besoin de l’autorisation de lecture que vous avez accordée à un utilisateur. Attachez-la une fois à un groupe, puis modifiez ses membres lors du transfert de responsabilité entre analystes. Le rapport et la politique restent identiques ; l’utilisateur qui hérite de l’autorisation change.

Un groupe IAM rassemble des utilisateurs pour qu'ils héritent de ses autorisations. Il n'a pas d'identifiants et ne peut pas se connecter ni assumer un rôle lui-même. Cet exercice pratique une organisation existante d'utilisateurs IAM ; l'accès humain en production utilise couramment la fédération et les rôles temporaires.

cd /home/labex/project

aws sts get-caller-identity --query Arn --output text

aws sts get-caller-identity --profile alice --query Arn --output text

Alice n'a initialement aucune autorisation de lire le rapport existant. L'opérateur est responsable de sa préparation. Testez avant d'accorder l'accès :

aws s3api get-object --profile alice --bucket labex-iam02-reports --key reports/today.txt before.txt || true

Attendez-vous à AccessDenied. || true permet à une commande volontairement en échec de se terminer dans une séquence collée ; il ne transforme pas une erreur de connexion en preuve d'autorisation.

Créez ReportTeam. Cela ne crée aucun membre et n'accorde encore aucune autorisation.

aws iam create-group --group-name ReportTeam

Rédigez une politique qui autorise uniquement GetObject dans le préfixe des rapports de ce compartiment. Un ARN d'objet comprend sa clé ; le caractère générique après reports/ ne correspond pas à la paie ni à un autre compartiment. Un Allow correspondant autorise une requête, sauf si un Deny explicite applicable l'emporte.

cat > team-policy.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam02-reports/reports/*"}]}
JSON

put-group-policy stocke cette politique intégrée directement sur le groupe. Elle s'applique aux membres du groupe ; modifier le fichier local seul n'a aucun effet.

aws iam put-group-policy \
  --group-name ReportTeam \
  --policy-name ReportRead \
  --policy-document file://team-policy.json

aws iam get-group --group-name ReportTeam --query 'Users[].UserName'

aws iam get-group-policy \
  --group-name ReportTeam \
  --policy-name ReportRead \
  --query PolicyDocument

La liste des membres est vide. Alice est toujours refusée, car aucune appartenance ne la relie à la politique.

aws s3api get-object --profile alice --bucket labex-iam02-reports --key reports/today.txt still-denied.txt || true

Ajoutez Alice et testez la limite des autorisations

Dans cette étape, vous relierez Alice à l'autorisation du groupe et comparerez ses requêtes réelles avec celles de Bob et du non-membre outsider. add-user-to-group modifie l'appartenance ; il ne crée ni n'affiche d'identifiants.

aws iam add-user-to-group --group-name ReportTeam --user-name alice

aws iam get-group --group-name ReportTeam --query 'Users[].UserName'

aws iam list-groups-for-user --user-name alice --query 'Groups[].GroupName'

Attendez-vous à voir Alice dans ReportTeam et ReportTeam dans la liste des groupes d'Alice. Utilisez maintenant les identifiants d'Alice pour demander les octets du rapport.

aws s3api get-object \
  --profile alice \
  --bucket labex-iam02-reports \
  --key reports/today.txt alice-report.txt

cat alice-report.txt

Attendez-vous à Daily orders: 145. La même requête de rapport par Bob et outsider doit échouer, car ils ne sont pas membres.

aws s3api get-object --profile bob --bucket labex-iam02-reports --key reports/today.txt bob-denied.txt || true

aws s3api get-object --profile outsider --bucket labex-iam02-reports --key reports/today.txt outsider-denied.txt || true

Alice reste aussi refusée en dehors du périmètre de ressources du groupe. Ces objets existants permettent de diagnostiquer l'autorisation plutôt qu'une clé manquante.

aws s3api get-object --profile alice --bucket labex-iam02-reports --key private/payroll.txt private-denied.txt || true

aws s3api get-object --profile alice --bucket labex-iam02-reference --key reference.txt reference-denied.txt || true

Attendez-vous à AccessDenied pour les quatre requêtes négatives. AWS View affiche l'appartenance et émet de véritables requêtes GetObject pour chaque utilisateur ; développez le rapport d'aujourd'hui pour examiner les octets reçus par Alice.

Transférez l'appartenance et revérifiez l'ancien accès

Dans cette étape, vous transférerez la responsabilité des rapports à Bob et vérifierez qu'Alice perd l'autorisation héritée. Retirer un utilisateur d'un groupe retire les autorisations héritées de ce groupe. Cela ne révoque pas d'autres autorisations qu'il pourrait posséder ; ces utilisateurs préparés n'en ont aucune.

Ajoutez d'abord Bob, puis retirez Alice. Les deux utilisateurs partagent la même politique de groupe tant qu'ils sont tous deux membres ; après le retrait, seul Bob devrait en hériter.

aws iam add-user-to-group --group-name ReportTeam --user-name bob

aws iam remove-user-from-group --group-name ReportTeam --user-name alice

aws iam get-group --group-name ReportTeam --query 'Users[].UserName'

Attendez-vous à voir uniquement Bob. Lisez le rapport comme Bob, puis répétez la requête identique comme Alice.

aws s3api get-object \
  --profile bob \
  --bucket labex-iam02-reports \
  --key reports/today.txt bob-report.txt

cat bob-report.txt

aws s3api get-object --profile alice --bucket labex-iam02-reports --key reports/today.txt former-member.txt || true

aws s3api get-object --profile outsider --bucket labex-iam02-reports --key reports/today.txt outsider-denied.txt || true

Bob reçoit 145 ; Alice et outsider reçoivent AccessDenied. Les identifiants sélectionnent l'appelant, tandis que les autorisations effectives actuelles déterminent si sa requête réussit.

Le groupe accorde la lecture, pas l'écriture. Essayez le remplacement fourni comme Bob et confirmez que le rapport d'origine existe toujours.

aws s3api put-object --profile bob --bucket labex-iam02-reports --key reports/today.txt --body upload.txt || true

aws s3api get-object \
  --profile bob \
  --bucket labex-iam02-reports \
  --key reports/today.txt bob-report.txt

cat bob-report.txt

Attendez-vous à PutObject AccessDenied suivi de Daily orders: 145 inchangé. AWS View affiche maintenant Bob comme membre et Alice refusée ; la politique du groupe elle-même n'a pas changé.

Supprimez l'équipe et nettoyez ses données

Dans cette étape, vous révoquerez l'accès hérité de Bob avant de supprimer le groupe et les données de rapports de l'exercice. IAM exige qu'un groupe n'ait ni membres ni politiques attachées avant sa suppression. Laissez le groupe indépendant ReferenceTeam et son membre outsider intacts.

aws iam remove-user-from-group --group-name ReportTeam --user-name bob

aws s3api get-object --profile bob --bucket labex-iam02-reports --key reports/today.txt revoked.txt || true

Attendez-vous à AccessDenied pendant que le rapport existe encore. Retirez la politique intégrée, puis le groupe vide.

aws iam delete-group-policy --group-name ReportTeam --policy-name ReportRead

aws iam delete-group --group-name ReportTeam

aws iam list-groups --query 'Groups[].GroupName'

aws iam get-group --group-name ReferenceTeam --query 'Users[].UserName'

Seul ReferenceTeam reste, contenant toujours outsider. Supprimez exactement les deux clés d'objet de l'exercice et vérifiez que le compartiment de rapports est vide avant de le supprimer.

aws s3api delete-object --bucket labex-iam02-reports --key reports/today.txt

aws s3api delete-object --bucket labex-iam02-reports --key private/payroll.txt

aws s3api list-objects-v2 --bucket labex-iam02-reports

Vérifiez que KeyCount vaut 0 et qu'aucune entrée d'objet ne reste dans Contents.

aws s3api delete-bucket --bucket labex-iam02-reports

aws s3api list-buckets --query 'Buckets[].Name'

aws s3api get-object --bucket labex-iam02-reference --key reference.txt reference.txt

cat reference.txt

Seul le compartiment de référence reste, avec Platform reference: keep. Les requêtes API réussies établissent le nettoyage ; les erreurs réseau ne le prouvent pas. AWS View affiche Group removed et Reports bucket removed. Les utilisateurs et les ressources fournies préparés sont récupérés à la fin de l'environnement jetable ; le groupe et les autorisations créés par l'apprenant ont disparu.

Résumé

Vous avez attribué une politique à un groupe, prouvé que l'appartenance accorde l'accès aux rapports, transféré cet accès et confirmé que l'ancienne membre et le non-membre restaient refusés. L'appartenance à un groupe est une source d'autorisations ; examinez toutes les politiques applicables lorsqu'une identité reste autorisée de manière inattendue. Vous avez révoqué l'accès avant le nettoyage ciblé et conservé le groupe et les données sans rapport avec la tâche.

Pour approfondir ce sujet, consultez la documentation AWS : Groupes d’utilisateurs et autorisations héritées IAM.