Amazon S3 から 403: Access Denied エラーをトラブルシューティングする方法とは?
最終更新日: 2021年11月19日
ユーザーが Amazon Simple Storage Service (Amazon S3) バケットのオブジェクトにアクセスしようとしていますが、Amazon S3 が 403: Access Denied というエラーを返します。このエラーのトラブルシューティングを行う方法を教えてください。
簡単な説明
Amazon S3 からの Access Denied エラーをトラブルシューティングするには、以下の点について確認してください。
- バケットとオブジェクトの所有権
- バケットポリシーまたは AWS Identity and Access Management (IAM) ユーザーポリシー
- IAM アクセス許可の境界
- Amazon S3 ブロックパブリックアクセス設定
- Amazon S3 にアクセスするための認証情報
- 一時的なセキュリティ認証情報
- Amazon Virtual Private Cloud (Amazon VPC) エンドポイントポリシー
- Amazon S3 アクセスポイントポリシー
- オブジェクトまたは特殊文字を含むオブジェクトが見つかりません
- AWS Key Management Service (AWS KMS) による暗号化
- バケットで有効化されているリクエスタ支払い
- AWS Organizations のサービスコントロールポリシー
注意: AWS Systems Manager では、AWSSupport-TroubleshootS3PublicRead オートメーションドキュメントを使用することもできます。このオートメーションドキュメントは、指定したパブリック S3 バケットからのオブジェクトの読み取り問題を診断するために役立ちます。
解決方法
バケットとオブジェクトの所有権
GetObject または HeadObject リクエストによる AccessDenied エラーの場合は、そのオブジェクトがバケット所有者にも所有されているかどうかを確認します。また、バケット所有者がアクセスコントロールリスト (ACL) の読み取り権限またはフルコントロールアクセスコントロールリスト (ACL) 権限を持っているかどうかを確認します。
デフォルトでは、S3 オブジェクトの所有者はそれをアップロードした AWS アカウントになります。これは、バケットの所有者が他のアカウントである場合にも当てはまります。他のアカウントが自分のバケットにオブジェクトをアップロードできる場合は、自分のユーザーがアクセスできないオブジェクトを所有するアカウントを確認します。
1. AWS Command Line Interface (AWS CLI) コマンド list-buckets を実行して、アカウントの Amazon S3 正規 ID を取得します。
aws s3api list-buckets --query Owner.ID
注意: AWS CLI コマンドの実行時にエラーが発生する場合は、AWS CLI の最新バージョンを使用していることを確認してください。
2. list-objects コマンドを実行して、ユーザーがアクセスできないオブジェクトを所有するアカウントの Amazon S3 正規 ID を取得します。
aws s3api list-objects --bucket DOC-EXAMPLE-BUCKET --prefix exampleprefix
ヒント: list-objects コマンドを使用することで、複数のオブジェクトをチェックできます。
3. 正規 ID が一致しない場合、ユーザー (バケット所有者) はオブジェクトを所有していません。オブジェクトの所有者は、put-object-acl コマンドを実行して、オブジェクトの完全な制御を許可できます。
aws s3api put-object-acl --bucket DOC-EXAMPLE-BUCKET --key exampleobject.jpg --acl bucket-owner-full-control
4. オブジェクト所有者がオブジェクトの ACL を bucket-owner-full-control に変更すると、バケット所有者はオブジェクトにアクセスできます。ただし、ACL の変更だけでは、オブジェクトの所有権は変更されません。オブジェクト所有者をバケットのアカウントに変更するには、バケットのアカウントから cp コマンドを実行して、オブジェクトをそれ自体にコピーします。
すべての新しいオブジェクトを別のアカウントのバケットにコピーするには、bucket-owner-full-control ACL を使用して、オブジェクトのアップロードを要求するバケットポリシーを設定します。次に、AWS マネジメントコンソールで [S3 オブジェクト所有権] を有効にして [バケット所有者] を優先に設定します。bucket-owner-full-control ACL を使用してオブジェクトがアップロードされると、オブジェクトの所有者がバケット所有者に自動的に変更されます。
継続的なクロスアカウントのアクセス許可については、バケットへのアクセス許可を持つ IAM ロールをアカウント内に作成します。次に、別の AWS アカウントに、その IAM ロールを引き受けるアクセス許可を付与します。詳細については、チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任を参照してください。
バケットポリシーまたは IAM ユーザーポリシー
アクセスを誤って拒否する可能性のあるすべての記述について、バケットポリシー、またはそれを関連付けられた IAM ユーザーポリシーを見直します。ポリシーで適切でない拒否ステートメント、欠けているアクション、適切でないスペーシングなどを確認します。
1. 拒否ステートメントをチェックして、次の条件に基づいてアクセスをブロックする条件がないか確認します。
多要素認証 (MFA)
暗号化キー
特定の IP アドレス
特定の VPC または VPC エンドポイント
特定の IAM ユーザーまたはロール
自分のバケットへのリクエストがバケットポリシーまたは IAM ポリシーの全条件に一致することを確認します。そうしないと、アクセスが拒否されます。
注: MFA が必要で、ユーザーが AWS CLI を使ってリクエストを送信するのであれば、ユーザーが MFA を使用して AWS CLI を設定するようにします。
例えば、以下のバケットポリシーの Statement1 は、DOC-EXAMPLE-BUCKET からオブジェクト (s3:GetObject) をダウンロードするためのパブリックアクセスを許可しますが、Statement2 は、リクエストが VPC エンドポイント vpce-1a2b3c4d からのものである場合を除き、すべてのユーザーに対して DOC-EXAMPLE-BUCKET からオブジェクトをダウンロードするためのアクセスを明示的に拒否します。この場合は、Deny ステートメントが優先されます。つまり、vpce-1a2b3c4d 外からオブジェクトのダウンロードを試みるユーザーはアクセスが拒否されます。
{
"Id": "Policy1234567890123",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Action": [
"s3:GetObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
"Principal": "*"
},
{
"Sid": "Statement2",
"Action": [
"s3:GetObject"
],
"Effect": "Deny",
"Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
"Condition": {
"StringNotEquals": {
"aws:SourceVpce": "vpce-1a2b3c4d"
}
},
"Principal": "*"
}
]
}
2. ユーザーが必要とする Amazon S3 アクションを許可するバケットポリシーまたは IAM ポリシーをチェックします。たとえば、次のバケットポリシーには s3:PutObjectAcl アクションへのアクセス許可が含まれません。IAM ユーザーがオブジェクトのアクセスコントロールリスト (ACL) の変更を試みると、ユーザーに Access Denied エラーが表示されます。
{
"Id": "Policy1234567890123",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1234567890123",
"Action": [
"s3:PutObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:user/Dave"
]
}
}
]
}
3. バケットポリシーまたは IAM ユーザーポリシーに余分なスペースまたは間違った ARN がないことを確認してください。たとえば、次の IAM ポリシーでは、Amazon リソースネーム (ARN) の arn:aws:s3::: DOC-EXAMPLE-BUCKET/* に余分なスペースがあります。このスペースが原因で、ARN は arn:aws:s3:::%20DOC-EXAMPLE-BUCKET/* と誤って評価されます。つまり、IAM ユーザーに適切なオブジェクトへのアクセス許可がないことを意味します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1234567890123",
"Action": [
"s3:GetObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3::: DOC-EXAMPLE-BUCKET/*"
}
]
}
IAM アクセス許可の境界
バケットにアクセスを試みている IAM ID に設定されている IAM アクセス許可の境界を確認します。IAM アクセス許可の境界が Amazon S3 へのアクセスを許可していることを確認します。
Amazon S3 ブロックパブリックアクセス設定
許可されているパブリック読み取りリクエストで Access Denied エラーが表示される場合は、バケットの Amazon S3 ブロックパブリックアクセスの設定をチェックします。アカウントレベルとバケットレベルの両方で S3 のブロックパブリックアクセスの設定を確認します。これらの設定は、パブリック読み取りアクセスを可能にする許可を上書きできます。Amazon S3 ブロックパブリックアクセスは個々のバケットまたは AWS アカウントに適用できます。
Amazon S3 にアクセスするための認証情報
Amazon S3 にアクセスするためにユーザーが設定した認証情報を見直します。AWS SDK および AWS CLI は、IAM ユーザーの認証情報、またはバケットへのアクセス許可のあるロールを使用するように設定されている必要があります。
設定された認証情報を確認するために AWS CLI で configure コマンドを実行します。
aws configure list
ユーザーが Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを通してバケットにアクセスする場合は、インスタンスが正しいロールを使用していることを確認してください。インスタンスに接続し、get-caller-identity コマンドを実行します。
aws sts get-caller-identity
一時的なセキュリティ認証情報
AWS Security Token Service (AWS STS) を使用して付与された一時的なセキュリティ認証情報から、ユーザーに対し Access Denied エラーが返される場合は、関連付けられたセッションポリシーを確認します。
管理者が、AssumeRole API コール、または assume-role コマンドを使用して一時的なセキュリティ認証情報を作成している場合は、必要に応じてセッション固有のポリシーを渡すことができます。セッションのアクセス許可は、セッションの作成に使用される IAM エンティティ (ユーザーまたはロール) のセッションポリシーと ID ベースのポリシーが交差する部分です。セッションポリシーの詳細については、「ポリシーの種類」を参照してください。
Amazon S3 からの Access Denied エラーに関連付けられたセッションポリシーを検索するには、AWS CloudTrail イベント履歴で AssumeRole イベントを探します。失敗した Amazon S3 へのアクセスリクエストと同じ時間枠内にある AssumeRole イベントを探すようにしてください。次に、policy または policyArns のパラメータについて、関連する CloudTrail ログの requestParameters フィールドを確認します。関連付けられたポリシーまたはポリシー ARN が、必要な Amazon S3 許可を付与することを確認してください。
例えば、以下の CloudTrail ログのスニペットは、DOC-EXAMPLE-BUCKET に s3:GetObject 許可を付与するインラインセッションポリシーが、一時的な認証情報に含まれていることを示しています。
"requestParameters": {
"roleArn": "arn:aws:iam::123412341234:role/S3AdminAccess",
"roleSessionName": "s3rolesession",
"policy": "{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Effect\": \"Allow\",\n
\"Action\": [\n \"s3:GetObject\"\n ],\n \"Resource\": [\n \"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*\"\n ]\n } }\n ]\n}\n"
}
Amazon VPC エンドポイントポリシー
ユーザーが VPC エンドポイントを経由してルーティングされる EC2 インスタンスでバケットへアクセスする場合は、VPC エンドポイントポリシーをチェックします。VPC エンドポイントポリシーに、自分の S3 バケットとオブジェクトにアクセスするための正しいアクセス許可が含まれていることを確認します。
例えば、次の VPC エンドポイントポリシーは、DOC-EXAMPLE-BUCKET へのアクセスのみを許可しています。この VPC エンドポイントを介してリクエストを送信するユーザーは、他のバケットにアクセスすることはできません。
{
"Id": "Policy1234567890123",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1234567890123",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::DOC-EXAMPLE-BUCKET",
"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
],
"Principal": "*"
}
]
}
Amazon S3 アクセスポイントポリシー
Amazon S3 アクセスポイントを使用してバケットへのアクセスを管理する場合は、アクセスポイントの IAM ポリシーを確認します。アクセスポイントポリシーで付与されたアクセス許可は、基盤となるバケットポリシーで同じアクセスが許可されている場合にのみ有効です。バケットポリシーとアクセスポイントポリシーが正しいアクセス許可を付与していることを確認します。
オブジェクトまたは特殊文字を含むオブジェクトが見つかりません
リクエストされたオブジェクトがバケット内に存在することを確認します。また、特殊文字 (スペースなど) が含まれているオブジェクトでは、そのオブジェクトを取得するために特別な処理が必要であることにも注意してください。この処理が行われない場合、リクエストはそのオブジェクトを見つけられないので、Amazon S3 はオブジェクトが存在しないと想定します。その結果、適切な s3:ListBucket 許可がない場合、404 Not Found エラーの代わりに Access Denied エラーが発生します。
AWS CLI コマンド head-object を実行して、オブジェクトがバケットに存在するかどうかをチェックします。
aws s3api head-object --bucket DOC-EXAMPLE-BUCKET --key exampleobject.jpg
バケットにオブジェクトが存在していれば、Access Denied エラーが 404 Not Found エラーを隠すことはありません。アクセス拒否エラーを解決するには、他の設定要件を確認してください。
オブジェクトがバケット内にない場合は、アクセス拒否エラーは「404 Not Found」エラーを隠します。存在しないオブジェクトに関連する問題を解決します。
AWS KMS 暗号化
AWS KMS (SSE-KMS) 暗号化については、次の点にご注意ください。
- IAM ユーザーが完全なアクセス許可のあるオブジェクトにアクセスできない場合は、オブジェクトが SSE-KMS で暗号化されているかどうかを確認します。Amazon S3 コンソールを使用してオブジェクトのプロパティを表示すると、オブジェクトのサーバー側の暗号化に関する情報を確認できます。
- オブジェクトが SSE-KMS 暗号化されている場合は、KMS キーポリシーが、キーを使用するために必要な最小限の許可を IAM ユーザーに付与することを確認します。例えば、IAM ユーザーが S3 オブジェクトのダウンロードのみにキーを使用している場合、この IAM ユーザーは kms:Decrypt の許可を持っている必要があります。詳細については、AWS アカウントへのアクセス許可と IAM ポリシーの有効化をご参照ください。
- IAM アイデンティティとキーが同じアカウントにある場合は、キーポリシーを使用して kms:Decrypt 許可を付与する必要があります。キーポリシーは、IAM ポリシーと同じ IAM アイデンティティを参照する必要があります。
- IAM ユーザーが AWS KMS キーとは異なるアカウントに属している場合は、これらの許可が IAM ポリシーでも付与されている必要があります。例えば、SSE-KMS 暗号化オブジェクトをダウンロードするには、キーポリシーと IAM ポリシーの両方でkms:Decrypt アクセス許可を指定する必要があります。IAM ユーザーと KMS キー間のクロスアカウントアクセスの詳細については、他のアカウントのユーザーへの KMS の使用許可ご参照ください。
バケットで有効化されているリクエスタ支払い
ご自身のバケットでリクエスタ支払いが有効化されているのであれば、そのバケットにリクエストを送信する他のアカウントのユーザーでは、request-payer パラメータが指定されている必要があります。それ以外の場合は、それらのユーザーに、アクセス拒否エラーが表示されます。リクエスタ支払いが有効になっているかどうかを確認するには、Amazon S3 コンソールを使用してバケットのプロパティを表示します。
次の例の AWS CLI コマンドには、リクエスタ支払いを使用してクロスアカウントバケットにアクセスするための適切なパラメータが含まれています。
aws s3 cp exampleobject.jpg s3://DOC-EXAMPLE-BUCKET/exampleobject.jpg --request-payer requester
AWS Organizations のサービスコントロールポリシー
AWS Organizations を使用している場合は、サービスコントロールポリシーをチェックして、Amazon S3 へのアクセスが許可されていることを確認します。サービスコントロールポリシーでは、影響を受けるアカウントの最大権限を指定します。例えば、次のポリシーは、Amazon S3 へのアクセスを明示的に拒否して、Access Denied エラーを表示します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": "*"
}
]
}
AWS Organizations の機能の詳細については、組織内のすべての機能の有効化を参照してください。