Protégez un compartiment avec une politique de ressource

Introduction

Le propriétaire d'un compartiment souhaite accorder l'accès à un rôle de rapports et protéger les données privées. Vous attacherez une politique de compartiment, la comparerez à la politique propre au rôle et testerez comment un Deny correspondant affecte l'accès.

Terminez d'abord Utilisez des identifiants temporaires avec un rôle IAM et Accordez le moindre privilège à un lecteur de rapports. Cette nouvelle VM fournit default, report-role et other-role ; les profils de rôle obtiennent déjà des sessions temporaires. Utilisez /home/labex/project et AWS View. Gardez les identifiants et les caches privés.

Lien avec les certifications

Vue d’ensemble du lab

Accordez l'accès à un rôle depuis le compartiment

Dans cette étape, vous attacherez une politique de ressource accordant à ReportReader l'accès au préfixe des rapports. Contrairement à une politique d'identité, la politique de compartiment doit préciser Principal. Utilisez l'ARN du rôle IAM, qui identifie le rôle ; l'ARN de session assumed-role identifie une utilisation de ce rôle.

Vous avez accordé l’accès depuis une identité ; le propriétaire du bucket va maintenant l’accorder depuis la ressource. Les deux profils de rôle sont prêts : conservez leur confiance et concentrez-vous sur l’effet de la politique du bucket et de celle du rôle sur les mêmes requêtes.

Une politique de ressource est stockée sur la ressource. Une politique de compartiment S3 en est un exemple : son Principal identifie les personnes ou identités dont les requêtes sont couvertes par l'instruction. Comparez-la à une politique d'identité stockée sur un utilisateur ou un rôle.

Confirmez les deux identités de session actives et la liste initialement vide des politiques d'autorisations du rôle de rapports.

cd /home/labex/project

aws sts get-caller-identity --profile report-role --query Arn --output text

aws sts get-caller-identity --profile other-role --query Arn --output text

aws iam list-role-policies --role-name ReportReader

Attendez-vous à assumed-role/ReportReader/report-run et assumed-role/OtherReader/other-run, et à une liste PolicyNames vide. L'authentification comme rôle n'autorise pas à elle seule l'accès S3. Testez la lecture actuelle :

aws s3api get-object --profile report-role --bucket labex-iam04-reports --key reports/today.txt before.txt || true

Attendez-vous à AccessDenied. || true empêche un échec attendu d'interrompre une séquence collée. Les erreurs de connexion ne prouvent pas un refus.

Rédigez la politique de compartiment. GetObject accorde la lecture des objets ; Resource la limite à reports/ dans ce seul compartiment. Le Principal de rôle exclut OtherReader et n'accorde aucun accès public.

cat > bucket-policy.json <<'JSON'
{
  "Version":"2012-10-17",
  "Statement":[
    {"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/reports/*"}
  ]
}
JSON

aws s3api put-bucket-policy \
  --bucket labex-iam04-reports \
  --policy file://bucket-policy.json

aws s3api get-bucket-policy --bucket labex-iam04-reports --query Policy --output text

La politique de compartiment est maintenant stockée sur le compartiment, et non attachée au rôle. Dans le même compte, ce Allow de ressource applicable peut accorder l'accès au rôle sans Allow d'identité de rôle distinct, à condition qu'aucun Deny pertinent ne le bloque.

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

cat today.txt

aws s3api get-object --profile other-role --bucket labex-iam04-reports --key reports/today.txt other-denied.txt || true

aws s3api get-object --profile report-role --bucket labex-iam04-reports --key private/payroll.txt private-denied.txt || true

aws s3api get-object --profile report-role --bucket labex-iam04-reference --key reference.txt reference-denied.txt || true

ReportReader reçoit Daily orders: 145 ; les trois autres requêtes reçoivent AccessDenied. L'autorisation du compartiment ne couvre ni un autre rôle, ni un autre préfixe, ni un autre compartiment. AWS View émet les mêmes lectures réelles de rôle.

Protégez les données privées contre un Allow d'identité supplémentaire

Dans cette étape, vous observerez comment une autorisation d'identité de rôle se combine avec une autorisation de compartiment, puis utiliserez un Deny de compartiment pour protéger les données privées. Pour ces requêtes du même compte, les Allow applicables se combinent ; les deux sources de politiques ne sont pas automatiquement intersectées. Un Deny explicite dans l'une ou l'autre source applicable l'emporte sur un Allow.

Élargissez temporairement le périmètre de lecture d'identité de ReportReader aux objets de ce compartiment de l'exercice. Cette comparaison contrôlée concerne des données fictives et n'accorde aucun accès à un autre compartiment.

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

aws iam put-role-policy \
  --role-name ReportReader \
  --policy-name ReadAllOwned \
  --policy-document file://role-read.json

aws s3api get-object \
  --profile report-role \
  --bucket labex-iam04-reports \
  --key private/payroll.txt private-before-deny.txt

cat private-before-deny.txt

Attendez-vous à Synthetic payroll: restricted. Le Allow d'identité s'applique même si le Allow du compartiment couvre uniquement reports/. Ajoutez un Deny de compartiment limité à ce rôle et au préfixe privé, en conservant le Allow des rapports.

cat > bucket-policy.json <<'JSON'
{
  "Version":"2012-10-17",
  "Statement":[
    {"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/reports/*"},
    {"Effect":"Deny","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/private/*"}
  ]
}
JSON

aws s3api put-bucket-policy \
  --bucket labex-iam04-reports \
  --policy file://bucket-policy.json

aws s3api get-object --profile report-role --bucket labex-iam04-reports --key private/payroll.txt private-denied.txt || true

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

cat today.txt

Le privé renvoie maintenant AccessDenied malgré le Allow d'identité ; le rapport renvoie toujours 145. Le Deny nomme ReportReader ; l'opérateur peut donc toujours examiner et conserver l'objet fourni. L'ordre des instructions ne permet pas à un Allow de remplacer un Deny correspondant.

Confirmez qu'un Deny d'identité l'emporte sur un Allow de compartiment

Dans cette étape, vous testerez le sens inverse : un Deny d'identité de rôle l'emporte sur un Allow de compartiment. Conservez l'autorisation de lecture actuelle et ajoutez un Deny pour les écritures vers le préfixe des rapports.

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

aws iam put-role-policy \
  --role-name ReportReader \
  --policy-name ReadAllOwned \
  --policy-document file://role-read.json

Pour un test contrôlé de priorité, ajoutez temporairement un Allow de compartiment pour le même rôle et le même préfixe d'écriture. Appliquez d'abord le Deny d'identité pour que le rapport reste protégé.

cat > bucket-write-test.json <<'JSON'
{
  "Version":"2012-10-17",
  "Statement":[
    {"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/reports/*"},
    {"Effect":"Deny","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/private/*"},
    {"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:PutObject","Resource":"arn:aws:s3:::labex-iam04-reports/reports/*"}
  ]
}
JSON

aws s3api put-bucket-policy \
  --bucket labex-iam04-reports \
  --policy file://bucket-write-test.json

aws s3api put-object --profile report-role --bucket labex-iam04-reports --key reports/today.txt --body upload.txt || true

Attendez-vous à PutObject AccessDenied même si le compartiment l'autorise. Le Deny d'identité l'emporte. Retirez immédiatement le Allow d'écriture temporaire en rétablissant la politique à deux instructions enregistrée à l'étape précédente.

aws s3api put-bucket-policy \
  --bucket labex-iam04-reports \
  --policy file://bucket-policy.json

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

cat today.txt

aws s3api get-object --profile other-role --bucket labex-iam04-reports --key reports/today.txt other-denied.txt || true

Le rapport doit rester Daily orders: 145, et OtherReader reste refusé. L'autorisation d'écriture temporaire a disparu. AWS View affiche la politique du compartiment et la politique d'identité du rôle à côté des résultats de lecture réels.

Retirez les deux sources d'autorisations et nettoyez

Dans cette étape, vous retirerez les deux sources de politiques avant de supprimer les données de l'exercice. Retirer un Allow ne suffit pas lorsqu'une autre politique accorde toujours la même action.

Supprimez la politique du compartiment, puis répétez la lecture du rapport. ReadAllOwned accorde toujours cette lecture via la politique d'identité du rôle.

aws s3api delete-bucket-policy --bucket labex-iam04-reports

aws s3api get-object \
  --profile report-role \
  --bucket labex-iam04-reports \
  --key reports/today.txt remaining-grant.txt

cat remaining-grant.txt

Attendez-vous à Daily orders: 145. Supprimez maintenant ReadAllOwned et testez à nouveau pendant que le rapport existe encore.

aws iam delete-role-policy --role-name ReportReader --policy-name ReadAllOwned

aws s3api get-object --profile report-role --bucket labex-iam04-reports --key reports/today.txt revoked.txt || true

aws iam list-role-policies --role-name ReportReader

Attendez-vous à AccessDenied et à une liste de politiques vide. Les rôles préparés et leur confiance envers les appelants restent intacts ; vous retirez les autorisations S3 créées pendant cet exercice.

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

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

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

Vérifiez KeyCount: 0 dans cette réponse réussie, puis supprimez le compartiment de rapports vide et confirmez les octets de référence.

aws s3api delete-bucket --bucket labex-iam04-reports

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

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

cat reference.txt

Seul le compartiment de référence reste avec Platform reference: keep. Les erreurs réseau ne prouvent pas la suppression. AWS View affiche maintenant l'absence de politique de compartiment ou d'autorisations de rôle et Reports bucket removed. Les identités préparées, les ressources fournies et les caches temporaires locaux sont récupérés à la fin de l'environnement jetable.

Résumé

Vous avez utilisé Principal pour accorder l'accès à un rôle par une politique de compartiment, observé comment les Allow d'identité et de ressource se combinent et testé la priorité du Deny explicite dans les deux sens. L'écriture interdite n'a pas modifié les octets du rapport. Vous avez retiré les deux sources d'autorisations avant le nettoyage ciblé et conservé les identités préparées et les données sans rapport avec la tâche. Examinez toutes les sources de politiques applicables lorsqu'une requête reste autorisée ou est refusée de manière inattendue.

Pour approfondir ce sujet, consultez la documentation AWS : Évaluation des politiques d’identité et de ressources.