コンテキスト: よくある AWS AccessDenied エラー
AWS で S3 バケットのリスト表示、Lambda 関数の呼び出し、DynamoDB テーブルへのアクセスなど、何らかの操作を行おうとしていると、突然壁にぶつかります。ターミナルには An error occurred (AccessDenied) when calling the operation: Access Denied と表示されます。イライラしますよね？
このメッセージは、AWS が「その操作を行う権限がありません」と伝えているものです。これはバグではなくセキュリティ機能ですが、解決策を探し始める場所が分からない場合、大きな障害に感じられることは間違いありません。
根本原因は、ほとんどの場合、AWS Identity and Access Management (IAM) に遡ります。これは、IAM ユーザー、IAM ロール、あるいはリソースベースのポリシー（S3 バケットポリシーなど）の問題が、あなたの操作をブロックしていることに起因している可能性があります。ここでは、これらの一般的な権限の問題を効果的にトラブルシューティングし、解決するための支援を目的としています。
デバッグプロセス: 権限問題の特定
AccessDenied エラーが表示されたとき、むやみに権限を追加したい衝動に抵抗してください。それは重大なセキュリティリスクです。代わりに、不足している正確な権限を特定するために、体系的なデバッグアプローチを採用しましょう。
1. プリンシパルとリソースの特定
深く掘り下げる前に、3つの基本的な質問を明確にしてください。誰が、何を、どのリソースに対して実行しようとしているのか？これは簡単なことのように思えるかもしれませんが、重要な最初のステップです。
- プリンシパル: リクエストは IAM ユーザー、IAM ロール（EC2 インスタンス、Lambda 関数にアタッチされているもの、または AWS SSO 経由で取得したものなど）、あるいは一時的な認証情報から来ていますか？
- アクション: 実行しようとしていた特定の AWS API コールは何ですか？一般的な例としては、
s3:ListBucket、s3:GetObject、lambda:InvokeFunction、またはdynamodb:GetItemがあります。多くの場合、エラーメッセージ自体が失敗した操作に関する手がかりを提供します。 - リソース: アクセスしようとしている特定のリソースの Amazon リソースネーム (ARN) は何ですか？例えば、S3 バケットの場合は
arn:aws:s3:::my-unique-bucket、Lambda 関数の場合はarn:aws:lambda:REGION:ACCOUNT_ID:function:my-functionなどです。
2. CloudTrail ログの確認
AccessDenied エラーのトラブルシューティングには、CloudTrail は不可欠なツールです。AWS アカウント内で行われたほぼすべての API コールを詳細に記録します。トレイルが適切に設定されていれば、詳細な洞察への最も迅速な経路を提供することがよくあります。
- AWS マネジメントコンソールにアクセスし、CloudTrail サービスに移動します。
- イベント履歴を選択します。
- 「イベント名」（試行した API コール）または「ユーザー名」（失敗したリクエストを開始した IAM ユーザーまたはロール）でイベントをフィルタリングします。
- 「イベントレコード」内で
"errorCode": "AccessDenied"を明示的に示すイベントを検索します。
CloudTrail のイベントレコードは、以下を含む重要な詳細を明らかにすることができます。
userIdentity.arn: リクエストを行ったプリンシパルの Amazon リソースネーム (ARN)。eventName: 拒否された特定の API アクション。requestParameters: ターゲットリソースなど、リクエストに関する追加情報。errorMessage: より正確なメッセージであり、不足している権限を直接特定することもあります。例えば、「User: arn:aws:iam::ACCOUNT_ID:user/myuser is not authorized to perform: s3:ListBucket on resource: arn:aws:s3:::my-unique-bucket」。
3. アイデンティティベースのポリシー (IAM ユーザー/ロール) の確認
プリンシパルと拒否されたアクションが特定されたら、次のステップは、その特定の IAM ユーザーまたはロールにリンクされているポリシーを調査することです。
- AWS マネジメントコンソール内で IAM サービスに移動します。
- ユーザーまたはロールに移動し、関連するプリンシパルを見つけます。
- インラインポリシーとマネージドポリシーの両方を含む、アタッチされているすべてのポリシーを確認します。特に、拒否されたアクション（例:
s3:ListBucket）を検索します。
常に Deny ステートメントを探すことを優先してください。明示的な Deny は常に Allow ステートメントよりも優先されることを忘れないでください。Deny が存在しない場合、問題は特定のアクションとリソースに対する Allow ステートメントの欠如である可能性が高いです。
4. リソースベースのポリシーの確認
S3 バケット、SQS キュー、KMS キーなど、特定の AWS サービスでは、ポリシーをリソース自体に直接アタッチできます。これらはリソースベースのポリシーとして知られています。重要なことに、例えば S3 バケットポリシーは、IAM ユーザーやロールが必要な権限を持っていてもアクセスを拒否する可能性があります。
この S3 の例を考えてみましょう。
- AWS コンソールで S3 サービスに移動します。
- 問題に関連する特定のバケットを選択します。
- アクセス許可タブに進み、バケットポリシーを確認します。
プリンシパルまたは試行しているアクションに影響を与える可能性のある Deny ステートメントを探します。場合によっては、暗号化されていない接続や一般的なプリンシパルに対する広範な Deny が、アクセス問題の根本原因となることがあります。
5. サービスコントロールポリシー (SCP) の検討
AWS Organization 内では、サービスコントロールポリシー (SCP) が個々のアカウントの権限を制限することで重要な役割を果たします。SCP はガードレールと考えてください。アカウントが持つことができる最大利用可能権限を定義します。SCP がアクションを明示的に拒否する場合、その設定に関わらず、IAM ポリシーはその権限を付与することはできません。SCP がアクセスに影響している疑いがある場合は、AWS Organization 管理者に相談してください。
解決策: 適切な権限の付与
デバッグ作業によって特定の権限のギャップが特定されたら、IAM ポリシーまたはリソースポリシーを調整する必要があります。これらの変更を行う際は、常に最小権限の原則に厳密に従い、タスクに絶対的に必要な権限のみを付与してください。
シナリオ 1: 不足している IAM ポリシー権限
例えば、CloudTrail が、IAM ユーザー myuser がバケット my-unique-bucket にアクセスしようとしたときに s3:ListBucket アクションが拒否されたと報告したとします。
提案される IAM ポリシーのスニペット:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowS3ListSpecificBucket",
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": "arn:aws:s3:::my-unique-bucket"
},
{
"Sid": "AllowS3GetObjectsInSpecificBucket",
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::my-unique-bucket/*"
}
]
}
このポリシーのスニペットを、アクセスを必要とする IAM ユーザーまたはロールに直接アタッチします。GetObject のようなオブジェクトレベルのアクションでは、バケット内のすべてのオブジェクトに対する権限を正しく指定するために、/* を含めることが重要であることに注意してください。
シナリオ 2: 制限的な S3 バケットポリシー
IAM ユーザーが s3:GetObject 権限を持っているにもかかわらず、S3 バケットポリシーが特定の VPC エンドポイント外のプリンシパルからのアクセスを明示的に拒否していると想像してください。このシナリオでは、IAM ユーザーの Allow ステートメントが事実上オーバーライドされます。
問題のある S3 バケットポリシーの例:
{
"Version": "2012-10-17",
"Id": "Policy1684344555",
"Statement": [
{
"Sid": "DenyAllExceptVPCEndpoint",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::my-unique-bucket",
"arn:aws:s3:::my-unique-bucket/*"
],
"Condition": {
"StringNotEquals": {
"aws:SourceVpce": "vpce-0a1b2c3d"
}
}
}
]
}
このようなポリシーから AccessDenied エラーが発生した場合、一般的に2つの主要な対応策があります。
- バケットポリシーの変更: セキュリティ体制と一致する場合、バケットポリシーにプリンシパル専用の明示的な
Allowステートメントを追加するか、既存のDeny条件を緩和します。 - 許可されたソースからのアクセス:
Denyが意図的であり、厳格に適用されている場合（例えば、VPC エンドポイントからのアクセスのみを許可する場合）、その承認された環境内からリソースにアクセスする必要があります。
よくある解決策は、バケットポリシーに明示的な Allow ステートメントを追加することです。これにより、他の Deny 条件がプリンシパルに直接一致しない場合でも、特定の IAM ロールまたはユーザーがバケットにアクセスできるようになります。
{
"Version": "2012-10-17",
"Id": "Policy1684344555",
"Statement": [
{
"Sid": "AllowMySpecificRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::ACCOUNT_ID:role/my-trusted-role"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-unique-bucket/*"
},
{
"Sid": "DenyAllExceptVPCEndpoint",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::my-unique-bucket",
"arn:aws:s3:::my-unique-bucket/*"
],
"Condition": {
"StringNotEquals": {
"aws:SourceVpce": "vpce-0a1b2c3d"
}
}
}
]
}
IAM ポリシーとリソースポリシーは独立して評価されることを覚えておくことが重要です。いずれかのポリシーが明示的に拒否する場合、アクセスは拒否されます。逆に、どちらも明示的に拒否せず、少なくとも一方が許可する場合は、アクセスが許可されます。
確認手順: 修正の確認
変更を実装したら、常に修正を徹底的に確認してください。
1. 失敗したコマンド/操作の再実行
AWS CLI を使用していた場合、以前に失敗したコマンドを再実行するだけです。例えば、S3 バケットをリスト表示するには、次のようにします。
aws s3 ls my-unique-bucket
または、オブジェクトを取得するには、次のようにします。
aws s3 cp s3://my-unique-bucket/my-file.txt ./my-file.txt
エラーがアプリケーションまたは SDK 呼び出し内で発生した場合、アプリケーションを再起動するか、特定の関数を再トリガーします。
2. CloudTrail の再確認
検証を試みた後、CloudTrail を再確認します。実行したばかりのアクションに対して、成功イベント ("errorCode": null または errorCode フィールドの欠如で示される) が表示されるはずです。これにより、権限の問題が解決されたことが確認されます。
3. IAM ポリシーシミュレーターの使用
より複雑な状況や事前テストには、AWS コンソールにある IAM ポリシーシミュレーターが非常に役立ちます。IAM ユーザーまたはロールを選択し、AWS アクションとリソースを指定して、既存のポリシー（リソースベースのポリシーや SCP を含む）が結果にどのように影響するかをプレビューできます。
学んだ教訓: 将来の AccessDenied エラーを回避する
- 最小権限の原則: 常に必要最小限の権限から付与を開始し、厳密に必要な場合にのみ追加してください。過剰な権限付与は重大なセキュリティ脆弱性となります。
- IAM ロールの使用: EC2 インスタンス、Lambda 関数などの AWS サービスでは、自動化されたプロセスに対して、認証情報をハードコーディングしたり、ユーザーに直接ポリシーをアタッチしたりする代わりに、一貫して IAM ロールを使用してください。
- リソースのタグ付け: タグを利用してリソースを効果的に整理します。これらのタグは、IAM ポリシーで参照され、リソースグループへのアクセスを許可できます。例えば、
Tag:Environment = Productionのリソースに対する S3 アクションを許可するなどです。 - ポリシー評価ロジックの理解: 明示的な
Denyステートメントは常にAllowを上書きすることを忘れないでください。IAM ポリシーとリソースポリシーは異なる方法で評価されるため、それらの相互作用を明確に理解することが重要です。 - CloudTrail と AWS Config で監視: 包括的なロギングのために、すべてのリージョンで CloudTrail が有効になっていることを確認してください。さらに、AWS Config は非準拠のリソースポリシーを監視するのに役立ちます。
- IAM ポリシーシミュレーターでのポリシーテスト: 新しいポリシーをデプロイしたり、大幅な変更を行う前に、ポリシーシミュレーターを活用してその影響を正確に予測してください。
AccessDenied エラーに対処することは、AWS を扱う人にとって共通の経験です。体系的なデバッグ、ポリシー評価の徹底的な理解、そしてベストプラクティスへの diligent な準拠により、これらの問題をより迅速に解決し、より安全なクラウド環境の構築に貢献できるでしょう。