# Amazon S3 アイデンティティとアクセスのトラブルシューティング
以下の情報を使用して、Amazon S3 と IAM の使用時に発生する可能性がある一般的な問題の診断と修正に役立てます。
**Topics**
+ [アクセス拒否エラーが表示された](#access_denied_403)
+ [Amazon S3 でアクションを実行する権限がありません](#security_iam_troubleshoot-no-permissions)
+ [iam:PassRole を実行する権限がありません](#security_iam_troubleshoot-passrole)
+ [自分の AWS アカウント 以外のユーザーに Amazon S3 リソースへのアクセスを許可したい](#security_iam_troubleshoot-cross-account-access)
+ [Amazon S3 でのアクセス拒否 (403 Forbidden) エラーのトラブルシューティング](troubleshoot-403-errors.md)
## アクセス拒否エラーが表示された
バケットポリシーまたはアイデンティティベースポリシーのいずれにも、アクセス許可を付与するリクエスタに対する明示的な `Deny` ステートメントがないことを確認します。
アクセス拒否エラーのトラブルシューティングの詳細については、「[Amazon S3 でのアクセス拒否 (403 Forbidden) エラーのトラブルシューティング](troubleshoot-403-errors.md)」を参照してください。
## Amazon S3 でアクションを実行する権限がありません
アクションを実行する権限がないというエラーが表示された場合は、そのアクションを実行できるようにポリシーを更新する必要があります。
次のエラー例は、`mateojackson` IAM ユーザーがコンソールを使用して、ある `my-example-widget` リソースに関する詳細情報を表示しようとしたことを想定して、その際に必要な `s3:GetWidget` アクセス許可を持っていない場合に発生するものです。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: s3:GetWidget on resource: my-example-widget
```
この場合、`s3:GetWidget` アクションを使用して `my-example-widget` リソースへのアクセスを許可するように、`mateojackson` ユーザーのポリシーを更新する必要があります。
サポートが必要な場合は、AWS 管理者に問い合わせてください。サインイン認証情報を提供した担当者が管理者です。
## iam:PassRole を実行する権限がありません
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して Amazon S3 にロールを渡せるようにする必要があります。
一部の AWS のサービス では、新しいサービスロールやサービスリンクロールを作成せずに、既存のロールをサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
次のエラー例は、`marymajor` という IAM ユーザーがコンソールを使用して Amazon S3 でアクションを実行しようとする場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与されたアクセス許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。
サポートが必要な場合は、AWS 管理者に問い合わせてください。サインイン認証情報を提供した担当者が管理者です。
## 自分の AWS アカウント 以外のユーザーに Amazon S3 リソースへのアクセスを許可したい
他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください。
+ Amazon S3 がこれらの機能をサポートしているかどうかを確認するには、「[Amazon S3 での IAM の機能](security_iam_service-with-iam.md)」を参照してください。
+ 所有している AWS アカウント 全体のリソースへのアクセス権を提供する方法については、*IAM ユーザーガイド* の [所有している別の AWS アカウント へのアクセス権を IAM ユーザーに提供](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) を参照してください。
+ サードパーティの AWS アカウント にリソースへのアクセス権を提供する方法については、「*IAM ユーザーガイド*」の「[サードパーティが所有する AWS アカウント へのアクセス権を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。
+ ID フェデレーションを介してアクセスを提供する方法については、*IAM ユーザーガイド* の [外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) を参照してください。
+ クロスアカウントアクセスにおけるロールとリソースベースのポリシーの使用方法の違いについては、*IAM ユーザーガイド* の [IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
# Amazon S3 でのアクセス拒否 (403 Forbidden) エラーのトラブルシューティング
アクセス拒否 (HTTP `403 Forbidden`) エラーは、AWS が認可リクエストを明示的または暗黙的に拒否した場合に表示されます。
+ *明示的な拒否*は、特定の AWS アクションに対する `Deny` ステートメントがポリシーに含まれている場合に発生します。
+ 該当する `Deny` ステートメントがなく、該当する `Allow` ステートメントもない場合に、*暗黙的な拒否*が発生します。
AWS Identity and Access Management (IAM) ポリシーはデフォルトで IAM プリンシパルを暗黙的に拒否するため、ポリシーではプリンシパルのアクションの実行を明示的に許可する必要があります。それ以外の場合、ポリシーは暗黙的にアクセスを拒否します。詳細については、「**IAM ユーザーガイド」の「[明示的な拒否と暗黙的な拒否の違い](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#AccessPolicyLanguage_Interplay)」を参照してください。アクセスリクエストを許可または拒否するかを決定するポリシー評価ロジックの詳細については、「IAM ユーザーガイド」の「[ポリシーの評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)」を参照してください。**
S3 リソースタイプ別の S3 API オペレーションへのアクセス許可の詳細については、「[Amazon S3 API オペレーションに必要なアクセス許可](using-with-s3-policy-actions.md)」を参照してください。
以降のトピックでは、Amazon S3 でのアクセス拒否 (403 Forbidden) エラーの最も一般的な原因について説明します。
**注記**
アクセス拒否 (HTTP `403 Forbidden`) エラーの場合、バケット所有者の個別の AWS アカウントまたはバケット所有者の AWS 組織の外部でリクエストが開始された場合、バケット所有者に対する Amazon S3 の料金は発生しません。
**Topics**
+ [アクセス拒否メッセージの例とトラブルシューティング方法](#access-denied-message-examples)
+ [リクエスタ支払いの設定によるアクセス拒否](#access-denied-requester-pays)
+ [バケットポリシーと IAM ポリシー](#bucket-iam-policies)
+ [Amazon S3 ACL 設定](#troubleshoot-403-acl-settings)
+ [S3 ブロックパブリックアクセス設定](#troubleshoot-403-bpa)
+ [Amazon S3 の暗号化設定](#troubleshoot-403-encryption)
+ [S3 オブジェクトロック設定](#troubleshoot-403-object-lock)
+ [VPC エンドポイントポリシー](#troubleshoot-403-vpc)
+ [AWS Organizations ポリシー](#troubleshoot-403-orgs)
+ [CloudFront ディストリビューションアクセス](#troubleshoot-403-cloudfront)
+ [アクセスポイント設定](#troubleshoot-403-access-points)
+ [その他のリソース](#troubleshoot-403-additional-resources)
**注記**
アクセス許可の問題をトラブルシューティングする場合は、[アクセス拒否メッセージの例とトラブルシューティング方法](#access-denied-message-examples) セクションから始めて、[バケットポリシーと IAM ポリシー](#bucket-iam-policies) セクションに移動します。「[アクセス許可を確認するためのヒント](#troubleshoot-403-tips)」のガイダンスに従う必要もあります。
## アクセス拒否メッセージの例とトラブルシューティング方法
Amazon S3 は、同じ AWS アカウント、または同じ AWS Organizations の組織のリソースに対して行われたリクエストのアクセス拒否 (HTTP `403 Forbidden`) エラーに追加コンテキストを含めるようになりました。この新しいコンテキストには、アクセスを拒否したポリシーのタイプ、拒否の理由、リソースへのアクセスをリクエストした IAM ユーザーまたはロールに関する情報が含まれます。
この追加のコンテキストは、アクセス問題のトラブルシューティング、アクセス拒否エラーの根本原因の特定、関連するポリシーの更新による誤ったアクセスコントロールの修正に役立ちます。この追加のコンテキストは、AWS CloudTrail ログでも使用できます。AWS GovCloud (US) Regions および中国リージョンを含むすべての AWS リージョンで、同じアカウントまたは同じ組織のリクエストに対する拡張アクセス拒否エラーメッセージが利用可能になりました。
ほとんどのアクセス拒否のエラーメッセージは、`User user-arn is not authorized to perform action on "resource-arn" because context` の形式です。この例では、*`user-arn`* は、アクセス権がないユーザーの [Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns)、*`action`* はポリシーが拒否するサービスアクション、*`resource-arn`* はポリシーが対象とするリソースの ARN です。*`context`* フィールドには、ポリシータイプについての追加のコンテキストが表示され、ポリシーがアクセスを拒否した理由が説明されます。
ポリシー内の `Deny` ステートメントで明示的にポリシーがアクセスを拒否した場合、アクセス拒否エラーメッセージには、`with an explicit deny in a type policy` というフレーズが含まれます。ポリシーがアクセスを暗黙的に拒否する場合、アクセス拒否エラーメッセージには、`because no type policy allows the action action` というフレーズが含まれます。
**重要**
拡張アクセス拒否メッセージは、同じアカウントリクエストまたは AWS Organizations の同じ組織のリクエストに対してのみ返されます。同じ組織の外のクロスアカウントリクエストは、汎用 `Access Denied` メッセージを返します。
クロスアカウントアクセスリクエストを許可または拒否するかを決定するポリシー評価ロジックの詳細については、「IAM ユーザーガイド」の「[クロスアカウントのポリシーの評価ロジック](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)」を参照してください。**クロスアカウントアクセスを許可する方法を説明するチュートリアルについては、「[例 2: バケット所有者がクロスアカウントのバケットのアクセス許可を付与する](example-walkthroughs-managing-access-example2.md)」を参照してください。
AWS Organizations の同じ組織内のリクエストの場合。
仮想プライベートクラウド (VPC) エンドポイントポリシーが原因で拒否が発生した場合、拡張アクセス拒否メッセージは返されません。
拡張アクセス拒否メッセージは、バケット所有者と発信者アカウントの両方が AWS Organizations の同じ組織に属している場合に提供されます。S3 オブジェクト所有者の **[希望するバケット所有者]** または **[オブジェクトライター]** 設定で設定されたバケットには、異なるアカウントが所有するオブジェクトが含まれる場合がありますが、オブジェクトの所有者は、拡張アクセス拒否メッセージには影響しません。バケット所有者と呼び出し元が同じ組織にある限り、拡張アクセス拒否メッセージは、特定のオブジェクトの所有者に関係なく、すべてのオブジェクトリクエストに対して返されます。オブジェクト所有者の設定と設定に関する情報については、「[オブジェクトの所有権の制御とバケットの ACL の無効化。](about-object-ownership.md)」を参照してください。
ディレクトリバケットに対するリクエストに関しては、拡張アクセス拒否エラーメッセージは返されません。ディレクトリバケットリクエストの場合は、汎用の `Access Denied` メッセージが返されます。
ポリシータイプが同じである複数のポリシーが認可リクエストを拒否した場合、アクセスは拒否され、エラーメッセージではポリシーの番号が特定されません。
複数のポリシータイプで認可リクエストが拒否された場合、エラーメッセージには、これらのポリシータイプのうち 1 つだけが含まれます。
複数の理由でアクセスリクエストが拒否された場合でも、エラーメッセージに含まれるのは、いずれか 1 つの拒否理由のみです。
次の例では、さまざまなタイプのアクセス拒否エラーメッセージの形式と、各タイプのメッセージに関するトラブルシューティング方法を説明しています。
### ブロックされた暗号化タイプによりアクセスが拒否されました
汎用バケットで使用できるサーバー側の暗号化タイプを制限するには、バケットのデフォルトの暗号化設定を更新して SSE-C 書き込みリクエストをブロックすることを選択できます。このバケットレベルの設定は、SSE-C を指定するオブジェクトをアップロードするリクエストをブロックします。バケットに対して SSE-C がブロックされている場合、SSE-C 暗号化を指定する `PutObject`、`CopyObject`、`PostObject`、またはマルチパートアップロードまたはレプリケーションリクエストは、HTTP 403 `AccessDenied` エラーで拒否されます。
この設定は `PutBucketEncryption` API のパラメータであり、`s3:PutEncryptionConfiguration` アクセス許可がある場合は S3 コンソール、AWS CLI、および AWS SDK を使用して更新することもできます。有効な値は、汎用バケットの SSE-C 暗号化をブロックする `SSE-C` と、バケットへの書き込みに SSE-C を使用できるようにする `NONE` です。
例えば、`BlockedEncryptionTypes` の設定により SSE-C を指定する書き込みリクエストがブロックされるため、`PutObject` リクエストへのアクセスが拒否された場合、次のメッセージが表示されます。
```
An error occurred (AccessDenied) when calling the PutObject operation:
User: arn:aws:iam::123456789012:user/MaryMajor is not
authorized to perform: s3:PutObject on resource:
"arn:aws:s3:::amzn-s3-demo-bucket1/object-name" because this
bucket has blocked upload requests that specify
Server Side Encryption with Customer provided keys (SSE-C).
Please specify a different server-side encryption type
```
この設定の詳細については「[汎用バケットの SSE-C のブロックまたはブロック解除](blocking-unblocking-s3-c-encryption-gpb.md)」を参照してください。
### リソースコントロールポリシーによるアクセスの拒否 - 明示的な拒否
1. リソースコントロールポリシー (RCP) 内のアクションの `Deny` ステートメントを確認します。次の例では、`s3:GetObject` がアクションです。
1. `Deny` ステートメントを削除して、RCP を更新してください。詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCP) の更新](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_update.html#update_policy-rcp)」を参照してください。
```
An error occurred (AccessDenied) when calling the GetObject operation:
User: arn:aws:iam::777788889999:user/MaryMajor is not authorized to perform:
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name"
with an explicit deny in a resource control policy
```
### サービスコントロールポリシーによるアクセスの拒否 - 暗黙的な拒否
1. サービスコントロールポリシー (SCP) のアクションで、`Allow` ステートメントが欠けていないかを確認します。次の例では、`s3:GetObject` がアクションです。
1. `Allow` ステートメントを追加して、ポリシーを更新してください。詳細については、「*AWS Organizations ユーザーガイド*」の「[SCP の更新](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_create.html#update_policy)」を参照してください。
```
User: arn:aws:iam::777788889999:user/MaryMajor is not authorized to perform:
s3:GetObject because no service control policy allows the s3:GetObject action
```
### サービスコントロールポリシーによるアクセスの拒否 - 明示的な拒否
1. サービスコントロールポリシー (SCP) のアクションで、`Deny` ステートメントを確認します。次の例では、`s3:GetObject` がアクションです。
1. `Deny` ステートメントを変更して SCP を更新し、必要なアクセスをユーザーに許可します。これを行う方法の例については、「AWS Organizations ユーザーガイド」の「[特定の管理者ロールを除いて、IAM ユーザーとロールが特定の変更を行わないようにする](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_general.html#example-scp-restricts-with-exception)」を参照してください。**SCP の更新に関する詳細については、「AWS Organizations ユーザーガイド」の「[SCP の更新](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_create.html#update_policy)」を参照してください。**
```
User: arn:aws:iam::777788889999:user/MaryMajor is not authorized to perform:
s3:GetObject with an explicit deny in a service control policy
```
### VPC エンドポイントポリシーによるアクセスの拒否 – 暗黙的な拒否
1. 仮想プライベートクラウド (VPC) エンドポイントポリシーのアクションで、`Allow` ステートメントが欠落していないかを確認します。次の例では、`s3:GetObject` がアクションです。
1. `Allow` ステートメントを追加して、VPC エンドポイントポリシーを更新します。詳細については、「*AWS PrivateLink ガイド*」の「[Update a VPC endpoint policy](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html#update-vpc-endpoint-policy)」を参照してください。
```
User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform:
s3:GetObject because no VPC endpoint policy allows the s3:GetObject action
```
### VPC エンドポイントポリシーによるアクセスの拒否 – 明示的拒否
1. 仮想プライベートクラウド (VPC) エンドポイントポリシーのアクションに、明示的な `Deny` ステートメントがあるかを確認します。次の例では、`s3:GetObject` がアクションです。
1. `Deny` ステートメントを変更して VPC エンドポイントポリシーを更新し、ユーザーに必要なアクセスを許可します。例えば、`Deny` ステートメントを更新して、`aws:PrincipalAccount` 条件キーと `StringNotEquals` 条件演算子を使用し、[例 7: `Deny` ステートメントから特定のプリンシパルを除外する](amazon-s3-policy-keys.md#example-exclude-principal-from-deny-statement) に示すように、特定のプリンシパルアクセスを許可できます。VPC エンドポイントポリシーの更新の詳細については、「AWS PrivateLink ガイド」の「[VPC エンドポイントポリシーの更新](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html#update-vpc-endpoint-policy)」を参照してください。**
```
User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform:
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with
an explicit deny in a VPC endpoint policy
```
### アクセス許可の境界によりアクセスの拒否 – 暗黙的な拒否
1. アクセス許可の境界にあるアクションで、`Allow` ステートメントが欠落してないかを確認してください。次の例では、`s3:GetObject` がアクションです。
1. IAM ポリシーに `Allow` ステートメントを追加して、アクセス許可の境界を更新してください。詳細については、「IAM ユーザーガイド」の「[IAM エンティティのアクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」と「[IAM ポリシーの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)」を参照してください。**
```
User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform:
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name"
because no permissions boundary allows the s3:GetObject action
```
### アクセス許可の境界によりアクセスの拒否 – 明示的拒否
1. アクセス許可の境界にあるアクションで、明示的な `Deny` ステートメントを確認してください。次の例では、`s3:GetObject` がアクションです。
1. IAM ポリシーの `Deny` ステートメントを変更してアクセス許可の境界を更新し、ユーザーに必要なアクセスを許可します。例えば、「IAM ユーザーガイド」の [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalaccount) に示すように、`aws:PrincipalAccount` 条件キーと `StringNotEquals` 条件演算子を使用して、特定のプリンシパルアクセスを許可するように `Deny` ステートメントを更新できます。**詳細については、「IAM ユーザーガイド」の「[IAM エンティティのアクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」と「[IAM ポリシーの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)」を参照してください。**
```
User: arn:aws:iam::777788889999:user/MaryMajor is not authorized to perform:
s3:GetObject with an explicit deny in a permissions boundary
```
### セッションポリシーによるアクセスの拒否 – 暗黙的な拒否
1. セッションポリシーにあるアクションで、`Allow` ステートメントが欠落していないかを確認してください。次の例では、`s3:GetObject` がアクションです。
1. `Allow` ステートメントを追加して、セッションポリシーを更新してください。詳細については、「IAM ユーザーガイド」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」と「[IAM ポリシーの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)」を参照してください。**
```
User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform:
s3:GetObject because no session policy allows the s3:GetObject action
```
### セッションポリシーによるアクセスの拒否 – 明示的拒否
1. セッションポリシーにあるアクションで、明示的な `Deny` ステートメントがあるのかを確認してください。次の例では、`s3:GetObject` がアクションです。
1. `Deny` ステートメントを変更してセッションポリシーを更新し、ユーザーに必要なアクセスを許可します。例えば、`Deny` ステートメントを更新して、`aws:PrincipalAccount` 条件キーと `StringNotEquals` 条件演算子を使用し、[例 7: `Deny` ステートメントから特定のプリンシパルを除外する](amazon-s3-policy-keys.md#example-exclude-principal-from-deny-statement) に示すように、特定のプリンシパルアクセスを許可できます。セッションポリシーの更新の詳細については、「IAM ユーザーガイド」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」および「[IAM ポリシーの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)」を参照してください。**
```
User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform:
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with
an explicit deny in a session policy
```
### リソースベースのポリシーによるアクセスの拒否 – 暗黙的な拒否
**注記**
リソースベースのポリシーとは、バケットポリシーやアクセスポイントポリシーなどのポリシーを指します。**
1. リソースベースのポリシーにあるアクションで、`Allow` ステートメントが欠落してないかを確認してください。`IgnorePublicAcls` S3 ブロックパブリックアクセス設定が、バケット、アクセスポイント、またはアカウントレベルに適用されているかどうかも確認します。次の例では、`s3:GetObject` がアクションです。
1. `Allow` ステートメントを追加して、ポリシーを更新してください。詳細については、「IAM ユーザーガイド」の「[リソースベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based)」と「[IAM ポリシーの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)」を参照してください。**
バケット、アクセスポイント、またはアカウントの `IgnorePublicAcls` ブロックパブリックアクセス設定を調整する必要がある場合もあります。詳細については、「[ブロックパブリックアクセス設定によるアクセス拒否](#access-denied-bpa-examples)」および「[S3 バケットへのパブリックアクセスブロック設定の構成](configuring-block-public-access-bucket.md)」を参照してください。
```
User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform:
s3:GetObject because no resource-based policy allows the s3:GetObject action
```
### リソースベースのポリシーによるアクセスの拒否 – 明示的拒否
**注記**
リソースベースのポリシーとは、バケットポリシーやアクセスポイントポリシーなどのポリシーを指します。**
1. リソースベースのポリシーにあるアクションで、明示的な `Deny` ステートメントがあるのかを確認してください。`RestrictPublicBuckets` S3 ブロックパブリックアクセス設定が、バケット、アクセスポイント、またはアカウントレベルに適用されているかどうかも確認します。次の例では、`s3:GetObject` がアクションです。
1. `Deny` ステートメントを変更してポリシーを更新し、ユーザーに必要なアクセスを許可します。例えば、`Deny` ステートメントを更新して、`aws:PrincipalAccount` 条件キーと `StringNotEquals` 条件演算子を使用し、[例 7: `Deny` ステートメントから特定のプリンシパルを除外する](amazon-s3-policy-keys.md#example-exclude-principal-from-deny-statement) に示すように、特定のプリンシパルアクセスを許可できます。リソースベースのポリシーの更新に関する詳細については、「IAM ユーザーガイド」の「[リソースベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_resource-based)」および「[IAM ポリシーの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)」を参照してください。**
バケット、アクセスポイント、またはアカウントの `RestrictPublicBuckets` ブロックパブリックアクセス設定を調整する必要がある場合もあります。詳細については、「[ブロックパブリックアクセス設定によるアクセス拒否](#access-denied-bpa-examples)」および「[S3 バケットへのパブリックアクセスブロック設定の構成](configuring-block-public-access-bucket.md)」を参照してください。
```
User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform:
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with
an explicit deny in a resource-based policy
```
### ID ベースのポリシーによるアクセスの拒否 – 暗黙的な拒否
1. ID にアタッチされた ID ベースのポリシーにあるアクションに対して、`Allow` ステートメントが欠落していないかを確認してください。次の例のアクションは、ユーザー `MaryMajor` にアタッチされた `s3:GetObject` です。
1. `Allow` ステートメントを追加して、ポリシーを更新してください。詳細については、「IAM ユーザーガイド」の「[アイデンティティベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_id-based)」と「[IAM ポリシーの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)」を参照してください。**
```
User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform:
s3:GetObject because no identity-based policy allows the s3:GetObject action
```
### ID ベースのポリシーによるアクセスの拒否 – 明示的拒否
1. ID にアタッチされた ID ベースのポリシーにあるアクションに対して、明示的な `Deny` ステートメントがあるのかを確認してください。次の例のアクションは、ユーザー `MaryMajor` にアタッチされた `s3:GetObject` です。
1. `Deny` ステートメントを変更してポリシーを更新し、ユーザーに必要なアクセスを許可します。例えば、「IAM ユーザーガイド」の [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalaccount) に示すように、`aws:PrincipalAccount` 条件キーと `StringNotEquals` 条件演算子を使用して、特定のプリンシパルアクセスを許可するように `Deny` ステートメントを更新できます。**詳細については、「IAM ユーザーガイド」の「[アイデンティティベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_id-based)」と「[IAM ポリシーの編集](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)」を参照してください。**
```
User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform:
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with
an explicit deny in an identity-based policy
```
### ブロックパブリックアクセス設定によるアクセス拒否
Amazon S3 のパブリックアクセスブロック機能は、Amazon S3 のリソースへのパブリックアクセスの管理に役立つ、アクセスポイント、バケット、アカウントの設定を提供します。Amazon S3 が「パブリック」を定義する方法の詳細については、「[「パブリック」の意味](access-control-block-public-access.md#access-control-block-public-access-policy-status)」を参照してください。
デフォルトでは、新しいバケット、アクセスポイント、およびオブジェクトはパブリックアクセスを許可しません。ただし、ユーザーはバケットポリシー、アクセスポイントポリシー、IAM ユーザーポリシー、オブジェクトのアクセス許可、またはアクセスコントロールリスト (ACL) を変更することで、パブリックアクセスを許可できます。S3 ブロックパブリックアクセス設定は、このようなポリシー、アクセス許可、ACL を上書きします。2023 年 4 月以降、すべてのブロックパブリックアクセス設定がデフォルトで新しいバケットに対して有効になります。
Amazon S3 はバケットやオブジェクトへのアクセスのリクエストを受け取ると、バケットやバケット所有者のアカウントに適用されているパブリックアクセスブロック設定があるかどうかを確認します。リクエストがアクセスポイントを経由している場合、Amazon S3 はアクセスポイントのパブリックアクセスブロック設定も確認します。リクエストされたアクセスを禁止する既存のパブリックアクセスブロック設定がある場合、Amazon S3 はそのリクエストを拒否します。
Amazon S3 のパブリックアクセスブロックには、4 つの設定があります。これらの設定は、独立しており、任意の組み合わせで使用できます。各設定は、アクセスポイント、バケット、または AWS アカウント全体に適用できます。アクセスポイント、バケット、アカウントのパブリックアクセスブロック設定が異なる場合、Amazon S3 は、アクセスポイント、バケット、アカウントの設定の組み合わせで最も制限が厳しいものを適用します。
Amazon S3 は、パブリックアクセスブロック設定でオペレーションが禁止されているかどうかを評価し、アクセスポイント、バケット、アカウントの設定に違反しているすべてのリクエストを拒否します。
Amazon S3 ブロックパブリックアクセスが提供する 4 つの設定:
+ `BlockPublicAcls` – この設定は、`PutBucketAcl`、`PutObjectAcl`、`PutObject`、`CreateBucket`、`CopyObject`、`POST Object` のリクエストに適用されます。`BlockPublicAcls` の設定により、次のように動作します。
+ 指定されたアクセスコントロールリスト (ACL) がパブリックである場合、`PutBucketAcl` と `PutObjectAcl` の呼び出しは失敗します。
+ リクエストにパブリック ACL が含まれている場合、`PutObject` の呼び出しは失敗します。
+ この設定がアカウントに適用されている場合、リクエストにパブリック ACL が含まれていると、`CreateBucket` の呼び出しは失敗し、HTTP `400` (`Bad Request`) レスポンスが返されます。
例えば、`BlockPublicAcls` の設定により `CopyObject` リクエストのアクセスが拒否されると、次のとおりのメッセージが表示されます。
```
An error occurred (AccessDenied) when calling the CopyObject operation:
User: arn:aws:sts::123456789012:user/MaryMajor is not authorized to
perform: s3:CopyObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name"
because public ACLs are prevented by the BlockPublicAcls setting in S3 Block Public Access.
```
+ `IgnorePublicAcls` – `IgnorePublicAcls` 設定を使用すると、Amazon S3 はバケットとバケット内のすべてのオブジェクトのパブリック ACL を無視します。リクエストの許可がパブリック ACL によってのみ付与されている場合は、`IgnorePublicAcls` 設定によってリクエストが拒否されます。
`IgnorePublicAcls` 設定による拒否は、すべて暗黙的です。例えば、パブリック ACL により、`IgnorePublicAcls` が `GetObject` リクエストを拒否すると、次のとおりのメッセージが返されます。
```
User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform:
s3:GetObject because no resource-based policy allows the s3:GetObject action
```
+ `BlockPublicPolicy` – この設定は、`PutBucketPolicy` と `PutAccessPointPolicy` のリクエストに適用されます。
バケットに対して `BlockPublicPolicy` を設定すると、指定されたバケットポリシーでパブリックアクセスが許可されている場合、Amazon S3 は `PutBucketPolicy` への呼び出しを拒否します。この設定により、指定されたポリシーでパブリックアクセスが許可されている場合、Amazon S3 はバケットの同じアカウントのすべてのアクセスポイントに対する `PutAccessPointPolicy` への呼び出しも拒否します。
アクセスポイントで `BlockPublicPolicy` を設定すると、指定されたポリシー (アクセスポイントまたは基盤となるバケットのいずれか) でパブリックアクセスが許可されている場合、Amazon S3 はアクセスポイント経由で行われる `PutAccessPointPolicy` および `PutBucketPolicy` への呼び出しを拒否します。
例えば、`BlockPublicPolicy` の設定が原因で `PutBucketPolicy` リクエストのアクセスが拒否されると、次のとおりのメッセージが表示されます。
```
An error occurred (AccessDenied) when calling the PutBucketPolicy operation:
User: arn:aws:sts::123456789012:user/MaryMajor is not authorized to
perform: s3:PutBucketPolicy on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name"
because public policies are prevented by the BlockPublicPolicy setting in S3 Block Public Access.
```
+ `RestrictPublicBuckets` – `RestrictPublicBuckets` 設定は、パブリックポリシーを持つアクセスポイントまたはバケットへのアクセスを、バケット所有者のアカウントとアクセスポイント所有者のアカウント内の AWS のサービスのプリンシパルと承認済みのユーザーのみに制限します。この設定により、アクセスポイントまたはバケットへのすべてのクロスアカウントアクセスがブロックされます (AWS のサービスのプリンシパルによるアクセスを除く)。ただし、アカウント内のユーザーは引き続きアクセスポイントまたはバケットを管理できます。この設定では、匿名 (または署名なし) のコールもすべて拒否されます。
`RestrictPublicBuckets` 設定による拒否は、すべて暗黙的です。例えば、`RestrictPublicBuckets` がパブリックバケットまたはアクセスポイントポリシーにより `GetObject` リクエストを拒否した場合、次のメッセージが表示されます。
```
User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform:
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with
an explicit deny in a resource-based policy
```
これらの設定の詳細については、「[パブリックアクセスブロック設定](access-control-block-public-access.md#access-control-block-public-access-options)」をご参照ください。これらの設定を確認して更新するには、「[パブリックアクセスブロックの設定](access-control-block-public-access.md#configuring-block-public-access)」を参照してください。
## リクエスタ支払いの設定によるアクセス拒否
アクセスしようとしている Amazon S3 バケットでリクエスタ支払い機能が有効になっている場合は、そのバケットにリクエストを行うときに正しいリクエストパラメータを渡す必要があります。Amazon S3 のリクエスタ支払い機能を使用すると、バケット所有者の代わりにリクエスタがバケット内のオブジェクトにアクセスするためのデータ転送とリクエストのコストを支払うことができます。リクエスタ支払いがバケットに対して有効になっている場合、バケット所有者は他の AWS アカウントによって行われたリクエストに対して課金されません。
必要なパラメータを渡さずにリクエスタ支払い対応バケットにリクエストを行うと、アクセス拒否 (403 Forbidden) エラーが発生します。リクエスタ支払いが有効なバケット内のオブジェクトにアクセスするには、以下を実行する必要があります。
1. AWS CLI を使用してリクエストを行う場合は、`--request-payer requester` パラメータを含める必要があります。例えば、`s3://amzn-s3-demo-bucket/` S3 バケットにある `object.txt` キーを持つオブジェクトをローカルマシン上の場所にコピーするには、このバケットでリクエスタ支払いが有効になっている場合も `--request-payer requester` パラメータを渡す必要があります。
```
aws s3 cp s3://amzn-s3-demo-bucket/object.txt /local/path \
--request-payer requester
```
1. AWS SDK を使用してプログラムによるリクエストを行う場合は、`x-amz-request-payer` ヘッダーを値 `requester` に設定します。例については、[リクエスタ支払いバケットからのオブジェクトのダウンロード](ObjectsinRequesterPaysBuckets.md)を参照してください。
1. リクエストを行う IAM ユーザーまたはロールに、`s3:GetObject` や `s3:ListBucket` のアクセス許可など、リクエスタ支払いバケットにアクセスするために必要なアクセス許可があることを確認します。
`--request-payer requester` パラメータを含めるか、`x-amz-request-payer` ヘッダーを設定することで、リクエスタ支払いが有効なバケット内のオブジェクトへのアクセスに関連するコストをリクエスタが支払うことを Amazon S3 に通知します。これにより、アクセス拒否 (403 Forbidden) エラーを防ぐことができます。
## バケットポリシーと IAM ポリシー
### バケットレベルの操作
バケットポリシーが設定されていない場合、バケットはバケット所有者のアカウントの任意の AWS Identity and Access Management (IAM) アイデンティティからのリクエストを暗黙的に許可します。また、バケットは、他の任意のアカウントからの他の IAM ID からのリクエストや、匿名の (署名されていない) リクエストを暗黙的に拒否します。ただし、IAM ユーザーポリシーが設定されていない場合、リクエスタのすべてのリクエストは (AWS アカウントのルートユーザーでない限り) 暗黙的に拒否されます。詳細については、*IAM ユーザーガイド*の「[アカウント内でのリクエストの許可または拒否の決定](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#policy-eval-denyallow)」を参照してください。
### オブジェクトレベルの操作
バケット所有アカウントがオブジェクトを所有している場合、バケットポリシーと IAM ユーザーポリシーは、オブジェクトレベルの操作でもバケットレベルの操作と同じように機能します。例えば、バケットポリシーが設定されていない場合、バケットはバケット所有者のアカウントの任意の IAM アイデンティティからのオブジェクトリクエストを暗黙的に許可します。また、バケットは、他の任意のアカウントの他の IAM ID からのオブジェクトリクエストや、匿名 (署名なし) リクエストを暗黙的に拒否します。ただし、IAM ユーザーポリシーが設定されていない場合、リクエスタのすべてのオブジェクトリクエストは (AWS アカウントのルートユーザーでない限り) 暗黙的に拒否されます。
オブジェクトが外部アカウントによって所有されている場合、オブジェクトへのアクセスはオブジェクトアクセスコントロールリスト (ACL) を通じてのみ許可されます。バケットポリシーと IAM ユーザーポリシーは、引き続きオブジェクトリクエストを拒否するために使用できます。
したがって、バケットポリシーまたは IAM ユーザーポリシーによりアクセス拒否 (403 Forbidden) エラーが発生しないことを確認するには、次の要件が満たされていることを確認します。
+ 同じアカウントでアクセスする場合、バケットポリシーまたは IAM ユーザーポリシーのいずれにも、アクセス権限を付与するリクエスタに対する明示的な `Deny` 記述があってはなりません。バケットポリシーと IAM ユーザーポリシーのみを使用してアクセス権限を付与する場合は、これらのポリシーの 1 つに少なくとも 1 つの明示的な `Allow` ステートメントが必要です。
+ クロスアカウントアクセスの場合、バケットポリシーまたは IAM ユーザーポリシーのいずれにも、アクセス許可を付与するリクエスタに対する明示的な `Deny` ステートメントを含めることはできません。バケットポリシーと IAM ユーザーポリシーのみを使用してクロスアカウントアクセス許可を付与する場合は、リクエスタのバケットポリシーと IAM ユーザーポリシーの両方に明示的な `Allow` ステートメントが含まれていることを確認します。
**注記**
バケットポリシーの `Allow` ステートメントは、[同じバケット所有アカウントが所有する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html)オブジェクトにのみ適用されます。ただし、バケットポリシーの `Deny` ステートメントは、オブジェクトの所有権に関係なくすべてのオブジェクトに適用されます。
**バケットポリシーを確認または編集する方法**
**注記**
バケットポリシーを表示または編集するには、`s3:GetBucketPolicy` アクセス許可が必要です。
1. AWS マネジメントコンソール にサインインし、Amazon S3 コンソール [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) を開きます。
1. 左側のナビゲーションペインで、**[バケット]** を選択します。
1. **[バケット]** リストで、バケットポリシーを表示または編集するバケットの名前を選択します。
1. **[アクセス許可]** タブを選択します。
1. **[バケットポリシー]** で **[編集]** を選択します。**[バケットポリシーを編集]** ページが表示されます。
AWS Command Line Interface (AWS CLI) を使用してバケットポリシーを確認または編集するには、[https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/get-bucket-policy.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/get-bucket-policy.html) コマンドを使用します。
**注記**
バケットポリシーが適正でないためにバケットからロックアウトされた場合は、[AWS アカウントのルートユーザー認証情報を使用してAWS マネジメントコンソールにサインイン](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html)します。バケットへのアクセスを回復するには、必ず AWS アカウントのルートユーザーの認証情報を使用してバケットポリシーを削除します。
### アクセス許可を確認するためのヒント
リクエスタが Amazon S3 オペレーションを実行するための適切な権限を持っているかどうかを確認するには、以下を試してください。
+ リクエスタを特定します。署名なしのリクエストの場合、IAM ユーザーポリシーのない匿名リクエストです。署名済み URL を使用したリクエストの場合、ユーザーポリシーは、リクエストに署名した IAM ユーザーまたはロールのポリシーと同じになります。
+ 正しい IAM ユーザーまたはロールを使用していることを確認します。IAM ユーザーまたはロールを確認するには、AWS マネジメントコンソール の右上隅を確認するか、[https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html](https://docs.aws.amazon.com/cli/latest/reference/sts/get-caller-identity.html) コマンドを使用することができます。
+ IAM ユーザーまたはロールに関連付けられている IAM ポリシーを確認します。次のいずれかの方法を使用します。
+ [IAM ポリシーシミュレーターを使用して IAM ポリシーをテストします](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html)。
+ さまざまな [IAM ポリシータイプ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)を確認します。
+ 必要に応じて、[IAM ユーザーポリシーを編集します](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)。
+ アクセスを明示的に拒否または許可するポリシーについては、以下の例を確認してください。
+ IAM ユーザーポリシーの明示的な許可: [IAM: 複数のサービスへのアクセスをプログラムおよびコンソールで許可および拒否](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam_multiple-services-console.html)
+ バケットポリシーの明示的許可: [オブジェクトをアップロードしたり、パブリックアクセス用のオブジェクト ACL を設定したりする権限を複数のアカウントに付与](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html#example-bucket-policies-acl-1)
+ IAM ユーザーポリシーの明示的拒否: [AWS: リクエストされた AWS リージョン に基づいてAWS へのアクセスを拒否](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_aws_deny-requested-region.html)
+ バケットポリシーの明示的拒否: [バケットに書き込まれるすべてのオブジェクトに SSE-KMS が必要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html#example-bucket-policies-encryption-1)
## Amazon S3 ACL 設定
ACL 設定を確認するときは、まず[オブジェクト所有権の設定を確認](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-ownership-retrieving.html)して、バケットで ACL が有効になっているかどうかを確認してください。ACL アクセス許可を使用できるのは、アクセス許可を付与するためのみであり、リクエストを拒否するためには使用できないことに注意が必要です。ACL は、バケットポリシーや IAM ユーザーポリシーでの明示的拒否によって拒否されたリクエスタにアクセス権を付与する目的でも使用できません。
### オブジェクト所有者の設定にバケット所有者の強制を設定する
**[バケット所有者の強制]** 設定が有効になっている場合、この設定によってバケットとオブジェクトに適用されるすべての ACL が無効になるため、ACL 設定によってアクセス拒否 (403 Forbidden) エラーが発生する可能性はほとんどありません。Amazon S3 バケットのデフォルト (および推奨) 設定は、**[バケット所有者の強制]** です。
### オブジェクト所有者設定に希望するバケット所有者またはオブジェクトライターを設定する
ACL 権限は、**[希望するバケット所有者]** 設定または **[オブジェクト作成者]** 設定でも引き続き有効です。ACL には、バケット ACL とオブジェクト ACL の 2 種類があります。この 2 種類の ACL の違いについては、「[ACL アクセス許可とアクセスポリシーのアクセス許可のマッピング](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html#acl-access-policy-permission-mapping)」を参照してください。
拒否されたリクエストのアクションに応じて、以下のように[バケットまたはオブジェクトの ACL 権限を確認してください](https://docs.aws.amazon.com/AmazonS3/latest/userguide/managing-acls.html)。
+ Amazon S3 が `LIST`、`PUT` オブジェクト、`GetBucketAcl`、または `PutBucketAcl` リクエストを拒否した場合は、[バケットの ACL 権限を確認](https://docs.aws.amazon.com/AmazonS3/latest/userguide/managing-acls.html)してください。
**注記**
バケット ACL 設定では、`GET` オブジェクトのアクセス許可を付与することはできません。
+ Amazon S3 が S3 オブジェクトの `GET` リクエスト、または [https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObjectAcl.html](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObjectAcl.html) リクエストを拒否した場合は、[そのオブジェクトの ACL 権限を確認してください](https://docs.aws.amazon.com/AmazonS3/latest/userguide/managing-acls.html)。
**重要**
オブジェクトを所有するアカウントがバケットを所有するアカウントと異なる場合、オブジェクトへのアクセスはバケットポリシーによって制御されません。
### クロスアカウントによるオブジェクト所有権である場合の、`GET` オブジェクトリクエストによるアクセス拒否 (403 Forbidden) エラーのトラブルシューティング
バケットの[オブジェクト所有権設定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/about-object-ownership.html#object-ownership-overview)を確認して、オブジェクト所有者を判断します。[オブジェクト ACL](https://docs.aws.amazon.com/AmazonS3/latest/userguide/managing-acls.html) へのアクセス権限がある場合は、オブジェクト所有者のアカウントを確認することもできます。(オブジェクト所有者のアカウントを表示するには、Amazon S3 コンソールでオブジェクト ACL 設定を確認します)。または、`GetObjectAcl` リクエストを実行してオブジェクト所有者の[正規 ID](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObjectAcl.html) を検索し、オブジェクト所有者のアカウントを確認することもできます。デフォルトでは、ACL はオブジェクト所有者のアカウントへの `GET` リクエストに対する明示的な許可権限を付与します。
オブジェクト所有者がバケット所有者と異なることを確認してから、ユースケースとアクセスレベルに応じて、次のいずれかの方法を選択してアクセス拒否 (403 Forbidden) エラーに対処します。
+ **ACL を無効にする (推奨)** - この方法はすべてのオブジェクトに適用され、バケット所有者が実行できます。この方法では、バケット所有者に所有権が自動的に与えられ、バケット内のすべてのオブジェクトを完全に制御できます。この方法を実行する前に、[ACL を無効にする前提条件](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-ownership-migrating-acls-prerequisites.html)を確認します。**[バケット所有者の強制]** (推奨) モードにバケットを設定する方法については、「[既存のバケットでのオブジェクトの所有権の設定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-ownership-existing-bucket.html)」を参照してください。
**重要**
アクセス拒否 (403 Forbidden) エラーを防ぐには、ACL を無効にする前に、必ず ACL 権限をバケットポリシーに移行してください。詳細については、「[ACL 権限からの移行に関するバケットポリシーの例](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-ownership-migrating-acls-prerequisites.html#migrate-acl-permissions-bucket-policies)」を参照してください。
+ **オブジェクト所有者をバケット所有者に変更** - この方法は個々のオブジェクトに適用できますが、オブジェクトの所有権を変更できるのはオブジェクト所有者 (または適切な権限を持つユーザー) のみです。追加の `PUT` コストが適用される場合があります。(詳細については、「[Amazon S3 の料金](https://aws.amazon.com/s3/pricing/)」を参照してください)。この方法では、バケット所有者にオブジェクトの完全な所有権が付与され、バケット所有者はバケットポリシーを通じてオブジェクトへのアクセスを制御できます。
オブジェクトの所有権を変更するには、以下のいずれかを実行します。
+ バケット所有者は[オブジェクトをコピーして](https://docs.aws.amazon.com/AmazonS3/latest/userguide/copy-object.html#CopyingObjectsExamples)バケットに戻すことができます。
+ バケットのオブジェクト所有者設定を **[希望するバケット所有者]** に変更できます。バージョニングを無効にすると、バケット内のオブジェクトは上書きされます。バージョニングが有効になっている場合、同じオブジェクトの重複バージョンがバケットに表示され、バケット所有者は[ライフサイクルルールを期限切れに設定](https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html)できます。オブジェクト所有権設定を変更する方法については、「[既存のバケットでのオブジェクトの所有権の設定](object-ownership-existing-bucket.md)」を参照してください。
**注記**
オブジェクト所有者の設定を **[希望するバケット所有者]** に更新すると、その設定はバケットにアップロードされた新しいオブジェクトにのみ適用されます。
+ `bucket-owner-full-control` 既定オブジェクト ACL を使用して、オブジェクト所有者にオブジェクトを再度アップロードさせることができます。
**注記**
クロスアカウントアップロードの場合、バケットポリシーで `bucket-owner-full-control` 既定オブジェクト ACL を要求することもできます。バケットポリシーの例については、[バケット所有者はフルコントロール権限を持ちながら、オブジェクトをアップロードするためのクロスアカウントアクセス許可を付与する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html#example-bucket-policies-acl-2)を参照してください。
+ **オブジェクト作成者をオブジェクト所有者のままにする** - この方法ではオブジェクトの所有者は変更されませんが、オブジェクトへのアクセス権限を個別に付与できます。オブジェクトへのアクセス権限を付与するには、そのオブジェクトに対する `PutObjectAcl` 権限が必要です。次に、アクセス拒否 (403 Forbidden) エラーを修正するために、リクエスタをオブジェクトの ACL 内のオブジェクトへのアクセス権限[付与者](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html#specifying-grantee)として追加します。詳細については、「[ACL の設定](managing-acls.md)」を参照してください。
## S3 ブロックパブリックアクセス設定
失敗したリクエストがパブリックアクセスまたはパブリックポリシーに関連している場合は、アカウント、バケット、または S3 アクセスポイントの S3 ブロックパブリックアクセス設定を確認します。S3 パブリックアクセスブロック設定に関連するアクセス拒否エラーのトラブルシューティングの詳細については、「[ブロックパブリックアクセス設定によるアクセス拒否](#access-denied-bpa-examples)」を参照してください。
## Amazon S3 の暗号化設定
Amazon S3 はバケットのサーバー側暗号化をサポートしています。サーバー側の暗号化とは、データを受信するアプリケーションまたはサービスによって、送信先でデータを暗号化することです。Amazon S3 は、AWS データセンターのディスクに書き込まれるときにデータをオブジェクトレベルで暗号化し、お客様がデータにアクセスするときに復号します。
デフォルトで、Amazon S3 では、Amazon S3 のすべてのバケットに対する基本レベルの暗号化として、Amazon S3 マネージドキーによるサーバー側の暗号化 (SSE-S3) が適用されるようになりました。Amazon S3 では、オブジェクトをアップロードするときにサーバー側を暗号化する方法も指定できます。
**バケットのサーバー側暗号化ステータスと暗号化設定を確認する方法**
1. AWS マネジメントコンソール にサインインし、Amazon S3 コンソール [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) を開きます。
1. 左側のナビゲーションペインで、**[バケット]** を選択します。
1. **[バケット]** リストで、暗号化設定を確認するバケットを選択します。
1. **[プロパティ]** タブを選択します。
1. **[デフォルトの暗号化]** セクションまでスクロールして、**[暗号化タイプ]** 設定を表示します。
AWS CLI を使用して暗号化設定を確認するには、[https://docs.aws.amazon.com/cli/latest/reference/s3api/get-bucket-encryption.html](https://docs.aws.amazon.com/cli/latest/reference/s3api/get-bucket-encryption.html) コマンドを使用します。
**オブジェクトの暗号化状態を確認する方法**
1. AWS マネジメントコンソール にサインインし、Amazon S3 コンソール [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) を開きます。
1. 左側のナビゲーションペインで、**[バケット]** を選択します。
1. **[バケット]** リストで、オブジェクトが含まれるバケットの名前を選択します。
1. **[オブジェクト]** リストで、暗号化を追加または変更するオブジェクトの名前を選択します。
オブジェクトの詳細ページが表示されます。
1. **[サーバー側の暗号化設定]** セクションまでスクロールすると、オブジェクトのサーバー側暗号化設定が表示されます。
AWS CLI を使用してオブジェクト暗号化ステータスを確認するには、[https://docs.aws.amazon.com/cli/latest/reference/s3api/head-object.html#examples](https://docs.aws.amazon.com/cli/latest/reference/s3api/head-object.html#examples) コマンドを使用します。
### 暗号化とアクセス許可の要件
Amazon S3 では 3 種類のサーバー側暗号化がサポートされます。
+ Amazon S3 マネージドキーを用いたサーバー側の暗号化 (SSE-S3)
+ AWS Key Management Service (AWS KMS) キー (SSE-KMS) によるサーバー側の暗号化
+ お客様が用意したキーを使用したサーバー側の暗号化 (SSE-C)
暗号化設定に基づいて、以下のアクセス許可要件が満たされていることを確認します。
+ **SSE-S3** - 追加の権限は必要ありません。
+ **SSE-KMS (カスタマー管理キーを使用)** - オブジェクトをアップロードするには、AWS KMS key に `kms:GenerateDataKey` 権限が必要です。オブジェクトをダウンロードしてオブジェクトのマルチパートアップロードを実行するには、KMS キーに `kms:Decrypt` 権限が必要です。
+ **SSE-KMS (AWS マネージドキー を使用)** - リクエスタは `aws/s3` KMS キーを所有しているのと同じアカウントに属している必要があります。また、リクエスタはオブジェクトにアクセスするための正しい Amazon S3 権限を持っている必要があります。
+ **SSE-C (お客様提供のキーを使用)** - 追加の権限は必要ありません。バケットポリシーを設定すると、バケットのオブジェクトに対して[お客様が用意した暗号化キーでサーバー側の暗号化をリクエストおよび制限できます](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html#ssec-require-condition-key)。
オブジェクトがカスタマーマネージドキーで暗号化されている場合は、KMS キーポリシーによって `kms:GenerateDataKey` または `kms:Decrypt` アクションの実行が許可されていることを確認してください。KMS キーポリシーを確認する手順については、*AWS Key Management Service デベロッパーガイド*の「[キーポリシーの表示](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-viewing.html)」を参照してください。
## S3 オブジェクトロック設定
バケットで [S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html) が有効になっていて、オブジェクトが[保持期間](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-overview.html#object-lock-retention-periods)または[リーガルホールド](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-overview.html#object-lock-legal-holds)によって保護されている場合、オブジェクトを削除しようとすると、Amazon S3 はオブジェクトの削除方法に応じて次のいずれかのレスポンスを返します。
+ **永続的 `DELETE` なリクエスト** – 永続的な `DELETE` リクエスト (バージョン ID を指定するリクエスト) を発行した場合、オブジェクトを削除しようとすると、Amazon S3 はアクセス拒否 (`403 Forbidden`) エラーを返します。
+ **シンプルな `DELETE` リクエスト** – シンプルな `DELETE` リクエスト (バージョン ID を指定しないリクエスト) を発行した場合、Amazon S3 は `200 OK` レスポンスを返し、バケットに[削除マーカー](DeleteMarker.md)を挿入します。そのマーカーは、新しい ID を持つオブジェクトの最新バージョンになります。
**バケットでオブジェクトロックが有効になっているかどうかを確認する方法**
1. AWS マネジメントコンソール にサインインし、Amazon S3 コンソール [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) を開きます。
1. 左側のナビゲーションペインで、**[バケット]** を選択します。
1. **[バケット]** リストで、確認するバケットの名前を選択します。
1. **[プロパティ]** タブを選択します。
1. **[オブジェクトロック]** セクションまでスクロールします。**[オブジェクトロック]** 設定が **[有効]** または **[無効]** であるかを確認します。
オブジェクトが保持期間またはリーガルホールドで保護されているかを判断するには、オブジェクトの[ロック情報を参照](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-managing.html#object-lock-managing-view)します。
オブジェクトが保持期間またはリーガルホールドで保護されている場合は、次の点を確認します。
+ オブジェクトバージョンがコンプライアンス保存モードで保護されている場合、それを完全に削除する方法はありません。AWS アカウントのルートユーザーを含む、すべてのリクエスタからの永続的な `DELETE` リクエストは、アクセス拒否 (403 Forbidden) エラーになります。また、コンプライアンス保持モードで保護されているオブジェクトの `DELETE` リクエストを送信すると、Amazon S3 はそのオブジェクトの[削除マーカー](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeleteMarker.html)を作成することに注意してください。
+ オブジェクトバージョンがガバナンス保持モードで保護されていて `s3:BypassGovernanceRetention` 権限がある場合は、保護をバイパスしてバージョンを完全に削除できます。詳細については、「[ガバナンスモードのバイパス](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-managing.html#object-lock-managing-bypass)」を参照してください。
+ オブジェクトバージョンがリーガルホールドで保護されている場合は、永久 `DELETE` リクエストを実行するとアクセス拒否 (403 Forbidden) エラーが発生する可能性があります。オブジェクトバージョンを永久に削除するには、オブジェクトバージョンのリーガルホールドを解除する必要があります。リーガルホールドを解除するには、`s3:PutObjectLegalHold` 許可が必要です。リーガルホールドの解除の詳細については、「[オブジェクトロックの設定](object-lock-configure.md)」を参照してください。
## VPC エンドポイントポリシー
仮想プライベートクラウド (VPC) エンドポイントを使用して Amazon S3 にアクセスする場合は、VPC エンドポイントポリシーによって Amazon S3 リソースへのアクセスがブロックされていないことを確認します。デフォルトでは、VPC エンドポイントポリシーは Amazon S3 へのすべてのリクエストを許可します。特定のリクエストを制限するように VPC エンドポイントポリシーを設定することもできます。VPC エンドポイントポリシーを確認する方法については、次のリソースを参照してください。
+ [VPC エンドポイントポリシーによるアクセスの拒否 – 暗黙的な拒否](#access-denied-vpc-endpoint-examples-implicit)
+ [VPC エンドポイントポリシーによるアクセスの拒否 – 明示的拒否](#access-denied-vpc-endpoint-examples-explicit)
+ 「AWS PrivateLink ガイド」の「[エンドポイントポリシーを使用して VPC エンドポイントへのアクセスを制御する](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)」**
## AWS Organizations ポリシー
あなたの AWS アカウント が組織に所属している場合、AWS Organizations ポリシーによって Amazon S3 リソースへのアクセスがブロックされる場合があります。デフォルトでは、AWS Organizations ポリシーは Amazon S3 へのいずれのリクエストもブロックしません。ただし、AWS Organizations ポリシーが S3 バケットへのアクセスをブロックするように設定されていないことを確認してください。AWS Organizations ポリシーを確認する方法については、以下のリソースを参照してください。
+ [サービスコントロールポリシーによるアクセスの拒否 - 暗黙的な拒否](#access-denied-scp-examples-implicit)
+ [サービスコントロールポリシーによるアクセスの拒否 - 明示的な拒否](#access-denied-scp-examples-explicit)
+ [リソースコントロールポリシーによるアクセスの拒否 - 明示的な拒否](#access-denied-rcp-examples-explicit)
+ 「AWS Organizations ユーザーガイド」の「[すべてのポリシーの一覧表示](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_info-operations.html#list-all-pols-in-org)」**
さらに、S3 バケットへのすべてのユーザーのアクセスを拒否するようにメンバーアカウントのバケットポリシーを誤って設定した場合は、IAM でメンバーアカウントの特権セッションを起動することでバケットをロック解除できます。特権セッションを起動した後、誤って設定したバケットポリシーを削除して、バケットへのアクセスを再開できます。詳細については、「*AWS Identity and Access Management ユーザーガイド*」の「[AWS Organizations メンバーアカウントで特権タスクを実行する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user-privileged-task.html)」を参照してください
## CloudFront ディストリビューションアクセス
CloudFront 経由で S3 静的ウェブサイトにアクセスしようとしたときに「アクセス拒否 (403 Forbidden)」エラーが発生した場合は、次の一般的な問題を確認してください。
+ **オリジンドメイン名の形式は正しいですか**
+ REST API エンドポイントではなく S3 ウェブサイトエンドポイント形式 (bucket-name.s3-website-region.amazonaws.com) を使用していることを確認
+ バケットで静的ウェブサイトホスティングが有効になっていることを確認
+ **バケットポリシーで CloudFront アクセスが許可されていますか**
+ バケットポリシーに CloudFront ディストリビューションのオリジンアクセスアイデンティティ (OAI) またはオリジンアクセスコントロール (OAC) のアクセス許可が含まれていることを確認
+ ポリシーに必要な s3:GetObject アクセス許可が含まれていることを確認
エラーページの設定やプロトコル設定など、その他のトラブルシューティング手順や設定については、AWS re:Post 情報センターの「[Amazon S3 ウェブサイトのエンドポイントを CloudFront ディストリビューションのオリジンとして使用すると、"403 access denied" エラーが発生する理由を知りたいです](https://repost.aws/knowledge-center/s3-website-cloudfront-error-403)」を参照してください。
**注記**
このエラーは、S3 に直接アクセスしたときに発生する可能性のある 403 エラーとは異なります。CloudFront 固有の問題については、CloudFront のディストリビューション設定と S3 の設定の両方を確認してください。
## アクセスポイント設定
Amazon S3 Access Points 経由でリクエストを行っているときにアクセス拒否 (403 Forbidden) エラーが表示される場合は、次の点を確認する必要がある場合があります。
+ アクセスポイントの設定
+ アクセスポイントに使用される IAM ユーザーポリシー
+ クロスアカウントアクセスポイントの管理または設定に使用されるバケットポリシー
**アクセスポイントの設定とポリシー**
+ アクセスポイントを作成するときに、**インターネット**または **VPC** をネットワークオリジンとして指定できます。ネットワークオリジンが VPC のみに設定されている場合、Amazon S3 は指定 VPC 以外のアクセスポイントへのリクエストをすべて拒否します。アクセスポイントのネットワークオリジンを確認するには、[Virtual Private Cloud に制限されたアクセスポイントの作成](access-points-vpc.md) を参照してください。
+ アクセスポイントでは、カスタムのブロックパブリックアクセス設定を構成することもできます。これは、バケットレベルまたはアカウントレベルのブロックパブリックアクセス設定と同様に機能します。カスタムのブロックパブリックアクセス設定を確認する方法は、「[汎用バケットのアクセスポイントへのパブリックアクセスの管理](access-points-bpa-settings.md)」を参照してください。
+ アクセスポイントを使用して Amazon S3 へのリクエストを正常に行うには、リクエスタが必要な IAM 権限を持っていることを確認します。詳細については、「[アクセスポイントを使用するための IAM ポリシーの設定](access-points-policies.md)」を参照してください。
+ リクエストにクロスアカウントアクセスポイントが含まれる場合、バケット所有者がアクセスポイントからのリクエストを許可するようにバケットポリシーを更新済みであることを確認します。詳細については、「[クロスアカウントアクセスポイントへのアクセス許可の付与](access-points-policies.md#access-points-cross-account)」を参照してください。
このトピックのすべての項目を確認してもアクセス拒否 (403 Forbidden) エラーが解決しない場合は、[Amazon S3 リクエスト ID を取得](https://docs.aws.amazon.com/AmazonS3/latest/userguide/get-request-ids.html)して、追加ガイダンスについて サポート まで問い合わせてください。
## その他のリソース
アクセス拒否 (403 Forbidden) エラーに関する詳細なガイダンスについては、次のリソースを確認できます。
+ AWS re:Post 情報センターの「[Amazon S3 での、403 Access Denied エラーをトラブルシューティングする方法を教えてください](https://repost.aws/knowledge-center/s3-troubleshoot-403)」。
+ AWS re:Post 情報センターの、「[Amazon S3 にファイルをアップロードしようとすると「403 禁止」エラーが表示されるのはなぜですか](https://repost.aws/knowledge-center/s3-403-forbidden-error)」。
+ AWS re:Post 情報センターの、「[すべてのリソースが同じ AWS アカウントからのものである場合、Amazon S3 バケットからの 403 アクセス拒否エラーをトラブルシューティングする方法を教えてください](https://repost.aws/knowledge-center/s3-troubleshoot-403-resource-same-account)」。
+ AWS re:Post 情報センターの、「[パブリック読み取りアクセス権を持つ Amazon S3 バケットからの 403 アクセス拒否エラーをトラブルシューティングする方法を教えてください](https://repost.aws/knowledge-center/s3-troubleshoot-403-public-read)」。
+ AWS re:Post 情報センターの、「[Amazon S3 の署名済み URL でリクエストを行う際の、SignatureDoesNotMatch または 403 Forbidden エラーをトラブルシューティングする方法を教えてください](https://repost.aws/knowledge-center/s3-presigned-url-signature-mismatch)」。
+ AWS re:Post 情報センターの、「[Amazon S3 バケットで同期コマンドを実行すると、ListObjectsV2 のアクセス拒否エラーが表示されるのはなぜですか](https://repost.aws/knowledge-center/s3-access-denied-listobjects-sync)」。
+ AWS re:Post 情報センターの、「[Amazon S3 ウェブサイトのエンドポイントを CloudFront ディストリビューションのオリジンとして使用すると、"403 access denied" エラーが発生する理由を知りたいです](https://repost.aws/knowledge-center/s3-website-cloudfront-error-403)」。