Diagnostiquez un refus d'accès

Introduction

Un lecteur de rapports renvoie AccessDenied après une migration de politique. Vous examinerez l'appelant, l'action demandée, la ressource et l'instruction de refus, en corrigeant une incohérence à la fois tout en conservant le périmètre limité du lecteur.

Terminez d'abord Accordez le moindre privilège à un lecteur de rapports pour les champs des politiques et le Deny explicite. Cette nouvelle VM prépare default pour l'administration et reader pour le traitement. Travaillez dans /home/labex/project et comparez la politique stockée aux lectures réelles dans AWS View.

Lien avec les certifications

Vue d’ensemble du lab

Confirmez l'appelant et corrigez l'action demandée

Dans cette étape, vous distinguerez une erreur d'identité d'une incohérence de politique, puis corrigerez l'action du Allow. La même commande avec des identifiants différents peut produire un résultat d'autorisation différent.

La politique migrée comporte plusieurs incohérences. Corriger un champ peut laisser la requête refusée par un autre champ ou par le Deny explicite. Après chaque modification, inspectez le document enregistré et répétez la même requête du lecteur ; une réponse AccessDenied inchangée ne prouve pas à elle seule si cette correction était juste.

cd /home/labex/project

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

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

Attendez-vous à user/iam05-operator et user/report-reader. Le traitement de rapports utilise le lecteur, pas l'opérateur. Confirmez que l'objet existe avec l'opérateur, puis reproduisez l'échec du traitement comme lecteur.

aws s3api get-object \
  --bucket labex-iam05-reports \
  --key reports/today.txt operator-report.txt

cat operator-report.txt

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

L'opérateur reçoit Daily orders: 145 ; le lecteur reçoit AccessDenied. Une clé manquante ou une erreur de connexion nécessiterait une autre investigation. || true permet à cette requête échouée attendue de se terminer dans une séquence collée.

Listez les politiques du lecteur et lisez le document stocké. Ce sont des requêtes de l'opérateur sur l'identité du traitement, pas des tentatives de prêter l'accès de l'opérateur au traitement.

aws iam list-user-policies --user-name report-reader

aws iam get-user-policy \
  --user-name report-reader \
  --policy-name LabReport \
  --query PolicyDocument

Le Allow nomme s3:ListBucket, tandis que l'erreur nomme GetObject. ListBucket liste les noms d'objets et utilise un ARN de compartiment ; il ne télécharge pas les octets des objets. Modifiez uniquement l'Action du Allow en GetObject, en conservant Resource et Deny actuels pour diagnostiquer séparément l'incohérence suivante.

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

aws iam put-user-policy \
  --user-name report-reader \
  --policy-name LabReport \
  --policy-document file://repair-policy.json

aws iam get-user-policy \
  --user-name report-reader \
  --policy-name LabReport \
  --query PolicyDocument

aws s3api get-object --profile reader --bucket labex-iam05-reports --key reports/today.txt reader-action-fix.txt || true

La requête renvoie toujours AccessDenied. L'Action est maintenant correcte, mais corriger un champ ne garantit pas que chaque contrôle applicable réussisse.

Faites correspondre l'ARN d'objet complet

Dans cette étape, vous corrigerez Resource en conservant l'instruction de refus. GetObject s'applique à un ARN d'objet, qui comprend sa clé. L'ARN de compartiment arn:aws:s3:::labex-iam05-reports ne correspond pas à arn:aws:s3:::labex-iam05-reports/reports/today.txt.

Remplacez Resource du Allow par l'ARN exact de l'objet d'aujourd'hui. N'utilisez pas * sur plusieurs compartiments ou clés ; le traitement possède une seule entrée requise.

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

aws iam put-user-policy \
  --user-name report-reader \
  --policy-name LabReport \
  --policy-document file://repair-policy.json

aws iam get-user-policy \
  --user-name report-reader \
  --policy-name LabReport \
  --query PolicyDocument

aws s3api get-object --profile reader --bucket labex-iam05-reports --key reports/today.txt reader-resource-fix.txt || true

Attendez-vous encore à AccessDenied. Le Allow correspond maintenant à Action et Resource ; examinez donc l'instruction restante. Son Deny correspond aussi à GetObject sur reports/*, y compris aujourd'hui. Un Deny explicite correspondant prévaut sur le Allow ; déplacer le Allow plus bas dans le document ne peut pas l'emporter.

Corrigez le Deny sans élargir l'accès

Dans cette étape, vous corrigerez le périmètre du Deny migré et confirmerez la réparation minimale. La protection prévue concerne les données privées ; elle ne doit pas refuser l'entrée du traitement de rapports. Gardez le Allow de lecture exact et limitez le Deny à private/* plutôt que de supprimer la protection ou d'ajouter des autorisations plus larges.

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

aws iam put-user-policy \
  --user-name report-reader \
  --policy-name LabReport \
  --policy-document file://repair-policy.json

aws s3api get-object \
  --profile reader \
  --bucket labex-iam05-reports \
  --key reports/today.txt today.txt

cat today.txt

Attendez-vous à Daily orders: 145. Testez les ressources voisines comme ce même lecteur ; la réparation terminée ne doit pas élargir son périmètre.

aws s3api get-object --profile reader --bucket labex-iam05-reports --key reports/yesterday.txt yesterday-denied.txt || true

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

aws s3api get-object --profile reader --bucket labex-iam05-reference --key reference.txt reference-denied.txt || true

Les trois doivent renvoyer AccessDenied. Une autorisation de lecture requise ne doit pas non plus autoriser les écritures. Essayez le remplacement fourni, puis vérifiez que les octets du rapport d'origine restent inchangés.

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

aws s3api get-object \
  --profile reader \
  --bucket labex-iam05-reports \
  --key reports/today.txt today.txt

cat today.txt

aws iam get-user-policy \
  --user-name report-reader \
  --policy-name LabReport \
  --query PolicyDocument

Attendez-vous à PutObject AccessDenied et à Daily orders: 145 inchangé. AWS View affiche maintenant aujourd'hui Readable et les autres ressources Denied. L'examen de la politique explique la réparation ; les requêtes réelles démontrent son effet.

Révoquez la réparation et nettoyez les données de l'exercice

Dans cette étape, vous retirerez LabReport et prouverez que l'accès est révoqué pendant que le rapport existe encore. Supprimez ensuite uniquement le compartiment de rapports de l'exercice et ses trois clés.

aws iam delete-user-policy --user-name report-reader --policy-name LabReport

aws iam list-user-policies --user-name report-reader

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

Attendez-vous à une liste de politiques vide et à AccessDenied. La révocation de politique et la suppression des données sont des vérifications distinctes. Gardez le compartiment de référence inchangé.

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

aws s3api delete-object --bucket labex-iam05-reports --key reports/yesterday.txt

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

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

Vérifiez KeyCount: 0 dans une réponse authentifiée réussie, sans entrée d'objet restante dans Contents.

aws s3api delete-bucket --bucket labex-iam05-reports

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

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

cat reference.txt

Seul le compartiment de référence reste avec Platform reference: keep. Les erreurs de service ne prouvent pas la suppression. Les identités préparées sont récupérées à la fin de l'environnement ; la politique du traitement et les données de l'exercice sont supprimées.

Résumé

Vous avez confirmé l'appelant, comparé l'opération échouée à l'Action du Allow, fait correspondre l'ARN d'objet complet et corrigé un Deny explicite qui chevauchait l'autorisation. Les échecs intermédiaires ont aidé à identifier les obstacles restants. Le lecteur final pouvait lire uniquement son rapport requis et ne pouvait ni l'écrire ni lire les données sans rapport avec la tâche. Vous avez révoqué l'autorisation réparée et terminé le nettoyage ciblé. Utilisez la même identité et testez les requêtes réussies et interdites lorsque vous diagnostiquez l'accès.

Pour approfondir ce sujet, consultez la documentation AWS : Diagnostic des erreurs d’accès refusé IAM.