Access Denied を診断する

AWSBeginner
オンラインで実践に進む

はじめに

ポリシーの移行後、レポートの読み取り役が AccessDenied を返しています。呼び出し元、要求する操作、リソース、拒否のステートメントを確認し、読み取り役の限定された範囲を保持しながら、不一致を一つずつ修復します。

最初に レポートの読み取り役に最小権限を与える を完了し、ポリシーのフィールドと明示的な Deny について学んでください。この新しい VM には、管理用の default と処理用の reader が準備されています。/home/labex/project で作業し、AWS View で保存されたポリシーと実際の読み取りを比較します。

認定試験との関連

認定資格 試験タスク 演習内容
Solutions Architect – Associate (SAA-C03) タスク 1.1 認可の診断とアクセス境界の検証。
Developer – Associate (DVA-C02) タスク 2.1 認可の診断とアクセス境界の検証。
CloudOps Engineer – Associate (SOA-C03) タスク 4.1 認可の診断とアクセス境界の検証。
Security – Specialty (SCS-C03) タスク 4.2 基礎演習:認可の診断とアクセス境界の検証。
Data Engineer – Associate (DEA-C01) タスク 4.2 基礎演習:認可の診断とアクセス境界の検証。

ラボの概要

概念図:呼び出し元、アクション、完全なオブジェクト ARN、一致する Deny を確認し、必要な S3 読み取りだけを修復して再テストします。

呼び出し元を確認し、要求された操作を修正する

このステップでは、アイデンティティの間違いとポリシーの不一致を分け、Allow の操作を修正します。同じコマンドでも、認証情報が異なると認可の結果が異なる場合があります。

移行されたポリシーには複数の不一致があります。一つのフィールドを修正しても、別のフィールドや明示的な Deny がリクエストを拒否することがあります。変更のたびに保存済み文書を確認し、同じ reader のリクエストを繰り返します。AccessDenied が変わらないという結果だけでは、その修正が正しかったかは判断できません。

この実験のレポート失敗を調べる順序。

cd /home/labex/project
aws sts get-caller-identity --query Arn --output text
aws sts get-caller-identity --profile reader --query Arn --output text

user/iam05-operator と user/report-reader を想定します。レポート処理は、操作担当者ではなく読み取り役を使います。操作担当者でオブジェクトの存在を確認し、読み取り役として処理の失敗を再現します。

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

操作担当者は Daily orders: 145、読み取り役は AccessDenied を受け取ります。キーがない状態や接続エラーなら、別の調査が必要です。|| true は、貼り付けたコマンド列でこの想定された失敗のリクエストを完了できるようにします。

読み取り役のポリシーを一覧表示し、保存された文書を読み取ります。これは処理用アイデンティティについての操作担当者の問い合わせであり、処理に操作担当者のアクセスを貸す試みではありません。

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

Allow は s3:ListBucket を指定していますが、エラーは GetObject を示しています。ListBucket はオブジェクト名を一覧表示し、バケット ARN を使います。オブジェクトのバイト列はダウンロードしません。次の不一致を別に診断できるよう、現在の Resource と Deny を保持し、Allow の Action だけを GetObject に変更します。

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

まだ AccessDenied を返します。Action は正しくなりましたが、一つのフィールドの修正だけで、適用されるすべてのチェックに合格するとは限りません。

完全なオブジェクト ARN に一致させる

このステップでは、拒否のステートメントを保持しながら Resource を修復します。GetObject は、キーを含むオブジェクト ARN に適用されます。バケット ARN arn:aws:s3:::labex-iam05-reports は、arn:aws:s3:::labex-iam05-reports/reports/today.txt に一致しません。

Allow の Resource を、今日の正確なオブジェクト ARN に置き換えます。バケットやキー全体に * を使わないでください。処理に必要な入力は一つです。

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

再び AccessDenied を想定します。今度は Allow が Action と Resource の両方に一致するため、残ったステートメントを確認します。その Deny も、今日を含む reports/* の GetObject に一致します。一致する明示的な Deny は Allow より優先されます。文書内で Allow を後ろに移しても上書きできません。

アクセスを広げずに Deny を修復する

このステップでは、移行された Deny の範囲を修正し、最小限の修復を確認します。意図した保護は非公開データを守るもので、レポート処理の入力を拒否すべきではありません。正確な読み取り Allow を保持し、保護を除去したり広い許可を追加したりする代わりに、Deny を private/* に限定します。

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

Daily orders: 145 を想定します。同じ読み取り役として、近くのリソースをテストします。完了した修復が範囲を広げてはいけません。

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

三つすべてが AccessDenied を返す必要があります。必要な読み取り許可は、書き込みも認可してはいけません。提供された置き換えファイルを試し、元のレポートのバイト列が変わっていないことを確認します。

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

PutObject の AccessDenied と、変更されていない Daily orders: 145 を想定します。AWS View は今日を Readable、他のリソースを Denied と表示します。ポリシーの確認は修復の理由を説明し、実際のリクエストは効果を示します。

最小限のポリシー修復は必要な読み取りだけを回復する. 例:今日は元のバイト列で読み取れ、昨日、非公開データ、参照用リソースは拒否されたままです。保存されたポリシーは、private の Deny と正確なレポートの Allow を保持しています。

修復した許可を取り消し、演習用データを削除する

このステップでは、LabReport を削除し、レポートがまだ存在する間に、アクセスが取り消されたことを証明します。その後、演習用のレポートバケットと三つのキーだけを削除します。

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

空のポリシー一覧と AccessDenied を想定します。ポリシーの取り消しとデータの削除は、別のチェックです。参照用バケットは変更せずに残してください。

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

認証された正常な応答で KeyCount: 0 を確認し、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

Platform reference: keep を持つ参照用バケットだけが残ります。サービス障害は削除を証明しません。準備済みアイデンティティは、環境の終了時に回収されます。処理用のポリシーと演習用データは削除されました。

まとめ

呼び出し元を確認し、失敗した操作と Allow の Action を比較して、完全なオブジェクト ARN に一致させ、重複していた明示的な Deny を修正しました。途中の失敗によって、残る問題を特定できました。最終的に読み取り役は、必要なレポートだけを読み取れ、書き込みや無関係なデータの読み取りはできませんでした。修復した許可を取り消し、範囲を限定した削除を完了しました。アクセスの診断では、同じアイデンティティを使い、成功するリクエストと禁止されたリクエストの両方をテストしてください。

詳しくは、AWS 公式ドキュメントを参照してください:IAM のアクセス拒否エラーの診断.