Cookie の設定を選択する

当社は、当社のサイトおよびサービスを提供するために必要な必須 Cookie および類似のツールを使用しています。当社は、パフォーマンス Cookie を使用して匿名の統計情報を収集することで、お客様が当社のサイトをどのように利用しているかを把握し、改善に役立てています。必須 Cookie は無効化できませんが、[カスタマイズ] または [拒否] をクリックしてパフォーマンス Cookie を拒否することはできます。

お客様が同意した場合、AWS および承認された第三者は、Cookie を使用して便利なサイト機能を提供したり、お客様の選択を記憶したり、関連する広告を含む関連コンテンツを表示したりします。すべての必須ではない Cookie を受け入れるか拒否するには、[受け入れる] または [拒否] をクリックしてください。より詳細な選択を行うには、[カスタマイズ] をクリックしてください。

Amazon S3 でのアクセス拒否 (403 Forbidden) エラーのトラブルシューティング

フォーカスモード
Amazon S3 でのアクセス拒否 (403 Forbidden) エラーのトラブルシューティング - Amazon Simple Storage Service

アクセス拒否 (HTTP 403 Forbidden) エラーは、AWS が認可リクエストを明示的または暗黙的に拒否した場合に表示されます。

  • 明示的な拒否は、特定の AWS アクションに対する Deny ステートメントがポリシーに含まれている場合に発生します。

  • 該当する Deny ステートメントがなく、該当する Allow ステートメントもない場合に、暗黙的な拒否が発生します。

AWS Identity and Access Management (IAM) ポリシーはデフォルトで IAM プリンシパルを暗黙的に拒否するため、ポリシーではプリンシパルのアクションの実行を明示的に許可する必要があります。それ以外の場合、ポリシーは暗黙的にアクセスを拒否します。詳細については、「IAM ユーザーガイド」の「明示的な拒否と暗黙的な拒否の違い」を参照してください。アクセスリクエストを許可または拒否するかを決定するポリシー評価ロジックの詳細については、「IAM ユーザーガイド」の「ポリシーの評価ロジック」を参照してください。

S3 リソースタイプ別の S3 API オペレーションへのアクセス許可の詳細については、「Amazon S3 API オペレーションに必要なアクセス許可」を参照してください。

以降のトピックでは、Amazon S3 でのアクセス拒否 (403 Forbidden) エラーの最も一般的な原因について説明します。

注記

アクセス拒否 (HTTP 403 Forbidden) エラーの場合、バケット所有者の個別の AWS アカウントまたはバケット所有者の AWS 組織の外部でリクエストが開始された場合、バケット所有者に対する Amazon S3 の料金は発生しません。

注記

アクセス許可の問題をトラブルシューティングする場合は、アクセス拒否メッセージの例とトラブルシューティング方法 セクションから始めて、バケットポリシーと IAM ポリシー セクションに移動します。「アクセス許可を確認するためのヒント」のガイダンスに従う必要もあります。

アクセス拒否メッセージの例とトラブルシューティング方法

Amazon S3 は、同じ AWS アカウント内のリソースに対して行われたリクエストのアクセス拒否 (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)action はポリシーが拒否するサービスアクション、resource-arn はポリシーが対象とするリソースの ARN です。context フィールドには、ポリシータイプについての追加のコンテキストが表示され、ポリシーがアクセスを拒否した理由が説明されます。

ポリシー内の Deny ステートメントで明示的にポリシーがアクセスを拒否した場合、アクセス拒否エラーメッセージには、with an explicit deny in a type policy というフレーズが含まれます。ポリシーがアクセスを暗黙的に拒否する場合、アクセス拒否エラーメッセージには、because no type policy allows the action action というフレーズが含まれます。

重要
  • 拡張アクセス拒否メッセージは、同じアカウントリクエストに対してのみ返されます。クロスアカウントリクエストの場合は、汎用の Access Denied メッセージが返されます。

    クロスアカウントアクセスリクエストを許可または拒否するかを決定するポリシー評価ロジックの詳細については、「IAM ユーザーガイド」の「クロスアカウントのポリシーの評価ロジック」を参照してください。クロスアカウントアクセスを許可する方法を説明するチュートリアルについては、「例 2: バケット所有者がクロスアカウントのバケットのアクセス許可を付与する」を参照してください。

  • ディレクトリバケットに対するリクエストに関しては、拡張アクセス拒否エラーメッセージは返されません。ディレクトリバケットリクエストの場合は、汎用の Access Denied メッセージが返されます。

  • ポリシータイプが同じである複数のポリシーが認可リクエストを拒否した場合、アクセスは拒否され、エラーメッセージではポリシーの番号が特定されません。

  • 複数のポリシータイプで認可リクエストが拒否された場合、エラーメッセージには、これらのポリシータイプのうち 1 つだけが含まれます。

  • 複数の理由でアクセスリクエストが拒否された場合でも、エラーメッセージに含まれるのは、いずれか 1 つの拒否理由のみです。

次の例では、さまざまなタイプのアクセス拒否エラーメッセージの形式と、各タイプのメッセージに関するトラブルシューティング方法を説明しています。

サービスコントロールポリシーによるアクセスの拒否 - 暗黙的な拒否

  1. サービスコントロールポリシー (SCP) のアクションで、Allow ステートメントが欠けていないかを確認します。次の例では、s3:GetObject がアクションです。

  2. Allow ステートメントを追加して、ポリシーを更新してください。詳細については、「AWS Organizations ユーザーガイド」の「SCP の更新」を参照してください。

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 がアクションです。

  2. Deny ステートメントを変更して SCP を更新し、必要なアクセスをユーザーに許可します。これを行う方法の例については、「AWS Organizations ユーザーガイド」の「特定の管理者ロールを除いて、IAM ユーザーとロールが特定の変更を行わないようにする」を参照してください。SCP の更新に関する詳細については、「AWS Organizations ユーザーガイド」の「SCP の更新」を参照してください。

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 がアクションです。

  2. Allow ステートメントを追加して、VPC エンドポイントポリシーを更新します。詳細については、「AWS PrivateLink ガイド」の「VPC エンドポイントポリシーを更新する」を参照してください。

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 がアクションです。

  2. Deny ステートメントを変更して VPC エンドポイントポリシーを更新し、ユーザーに必要なアクセスを許可します。例えば、Deny ステートメントを更新して、aws:PrincipalAccount 条件キーと StringNotEquals 条件演算子を使用し、例 7: Deny ステートメントから特定のプリンシパルを除外する に示すように、特定のプリンシパルアクセスを許可できます。VPC エンドポイントポリシーの更新の詳細については、「AWS PrivateLink ガイド」の「VPC エンドポイントポリシーの更新」を参照してください。

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 がアクションです。

  2. IAM ポリシーに Allow ステートメントを追加して、アクセス許可の境界を更新してください。詳細については、「IAM ユーザーガイド」の「IAM エンティティのアクセス許可の境界」と「IAM ポリシーの編集」を参照してください。

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 がアクションです。

  2. IAM ポリシーの Deny ステートメントを変更してアクセス許可の境界を更新し、ユーザーに必要なアクセスを許可します。例えば、「IAM ユーザーガイド」の aws:PrincipalAccount に示すように、aws:PrincipalAccount 条件キーと StringNotEquals 条件演算子を使用して、特定のプリンシパルアクセスを許可するように Deny ステートメントを更新できます。詳細については、「IAM ユーザーガイド」の「IAM エンティティのアクセス許可の境界」と「IAM ポリシーの編集」を参照してください。

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 がアクションです。

  2. Allow ステートメントを追加して、セッションポリシーを更新してください。詳細については、「IAM ユーザーガイド」の「セッションポリシー」と「IAM ポリシーの編集」を参照してください。

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 がアクションです。

  2. Deny ステートメントを変更してセッションポリシーを更新し、ユーザーに必要なアクセスを許可します。例えば、Deny ステートメントを更新して、aws:PrincipalAccount 条件キーと StringNotEquals 条件演算子を使用し、例 7: Deny ステートメントから特定のプリンシパルを除外する に示すように、特定のプリンシパルアクセスを許可できます。セッションポリシーの更新の詳細については、「IAM ユーザーガイド」の「セッションポリシー」および「IAM ポリシーの編集」を参照してください。

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 がアクションです。

  2. Allow ステートメントを追加して、ポリシーを更新してください。詳細については、「IAM ユーザーガイド」の「リソースベースのポリシー」と「IAM ポリシーの編集」を参照してください。

    バケット、アクセスポイント、またはアカウントの IgnorePublicAcls ブロックパブリックアクセス設定を調整する必要がある場合もあります。詳細については、ブロックパブリックアクセス設定によるアクセス拒否およびS3 バケットへのパブリックアクセスブロック設定の構成を参照してください。

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 がアクションです。

  2. Deny ステートメントを変更してポリシーを更新し、ユーザーに必要なアクセスを許可します。例えば、Deny ステートメントを更新して、aws:PrincipalAccount 条件キーと StringNotEquals 条件演算子を使用し、例 7: Deny ステートメントから特定のプリンシパルを除外する に示すように、特定のプリンシパルアクセスを許可できます。リソースベースのポリシーの更新に関する詳細については、「IAM ユーザーガイド」の「リソースベースのポリシー」および「IAM ポリシーの編集」を参照してください。

    バケット、アクセスポイント、またはアカウントの RestrictPublicBuckets ブロックパブリックアクセス設定を調整する必要がある場合もあります。詳細については、ブロックパブリックアクセス設定によるアクセス拒否およびS3 バケットへのパブリックアクセスブロック設定の構成を参照してください。

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 です。

  2. Allow ステートメントを追加して、ポリシーを更新してください。詳細については、「IAM ユーザーガイド」の「アイデンティティベースのポリシー」と「IAM ポリシーの編集」を参照してください。

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 です。

  2. Deny ステートメントを変更してポリシーを更新し、ユーザーに必要なアクセスを許可します。例えば、「IAM ユーザーガイド」の aws:PrincipalAccount に示すように、aws:PrincipalAccount 条件キーと StringNotEquals 条件演算子を使用して、特定のプリンシパルアクセスを許可するように Deny ステートメントを更新できます。詳細については、「IAM ユーザーガイド」の「アイデンティティベースのポリシー」と「IAM ポリシーの編集」を参照してください。

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 が「パブリック」を定義する方法の詳細については、「「パブリック」の意味」を参照してください。

デフォルトでは、新しいバケット、アクセスポイント、およびオブジェクトはパブリックアクセスを許可しません。ただし、ユーザーはバケットポリシー、アクセスポイントポリシー、IAM ユーザーポリシー、オブジェクトのアクセス許可、またはアクセスコントロールリスト (ACL) を変更することで、パブリックアクセスを許可できます。S3 ブロックパブリックアクセス設定は、このようなポリシー、アクセス許可、ACL を上書きします。2023 年 4 月以降、すべてのブロックパブリックアクセス設定がデフォルトで新しいバケットに対して有効になります。

Amazon S3 はバケットやオブジェクトへのアクセスのリクエストを受け取ると、バケットやバケット所有者のアカウントに適用されているパブリックアクセスブロック設定があるかどうかを確認します。リクエストがアクセスポイントを経由している場合、Amazon S3 はアクセスポイントのパブリックアクセスブロック設定も確認します。リクエストされたアクセスを禁止する既存のパブリックアクセスブロック設定がある場合、Amazon S3 はそのリクエストを拒否します。

Amazon S3 のパブリックアクセスブロックには、4 つの設定があります。これらの設定は、独立しており、任意の組み合わせで使用できます。各設定は、アクセスポイント、バケット、または AWS アカウント全体に適用できます。アクセスポイント、バケット、アカウントのパブリックアクセスブロック設定が異なる場合、Amazon S3 は、アクセスポイント、バケット、アカウントの設定の組み合わせで最も制限が厳しいものを適用します。

Amazon S3 は、パブリックアクセスブロック設定でオペレーションが禁止されているかどうかを評価し、アクセスポイント、バケット、アカウントの設定に違反しているすべてのリクエストを拒否します。

Amazon S3 ブロックパブリックアクセスが提供する 4 つの設定:

  • BlockPublicAcls – この設定は、PutBucketAclPutObjectAclPutObjectCreateBucketCopyObjectPOST Object のリクエストに適用されます。BlockPublicAcls の設定により、次のように動作します。

    • 指定されたアクセスコントロールリスト (ACL) がパブリックである場合、PutBucketAclPutObjectAcl の呼び出しは失敗します。

    • リクエストにパブリック 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 access control lists (ACLs) are blocked by the BlockPublicAcls block public access setting.
  • IgnorePublicAclsIgnorePublicAcls 設定を使用すると、Amazon S3 はバケットとバケット内のすべてのオブジェクトのパブリック ACL を無視します。リクエストの許可がパブリック ACL によってのみ付与されている場合は、IgnorePublicAcls 設定によってリクエストが拒否されます。

    IgnorePublicAcls 設定による拒否は、すべて暗黙的です。例えば、パブリック ACL により、IgnorePublicAclsGetObject リクエストを拒否すると、次のとおりのメッセージが返されます。

    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 – この設定は、PutBucketPolicyPutAccessPointPolicy のリクエストに適用されます。

    バケットに対して 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 blocked by the BlockPublicPolicy block public access setting.
  • RestrictPublicBucketsRestrictPublicBuckets 設定は、パブリックポリシーを持つアクセスポイントまたはバケットへのアクセスを、バケット所有者のアカウントとアクセスポイント所有者のアカウント内の 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

これらの設定の詳細については、「パブリックアクセスブロック設定」をご参照ください。これらの設定を確認して更新するには、「パブリックアクセスブロックの設定」を参照してください。

バケットポリシーと IAM ポリシー

バケットレベルの操作

バケットポリシーが設定されていない場合、バケットはバケット所有者のアカウントの任意の AWS Identity and Access Management (IAM) アイデンティティからのリクエストを暗黙的に許可します。また、バケットは、他の任意のアカウントからの他の IAM ID からのリクエストや、匿名の (署名されていない) リクエストを暗黙的に拒否します。ただし、IAM ユーザーポリシーが設定されていない場合、リクエスタのすべてのリクエストは (AWS アカウントのルートユーザーでない限り) 暗黙的に拒否されます。詳細については、IAM ユーザーガイドの「アカウント内でのリクエストの許可または拒否の決定」を参照してください。

オブジェクトレベルの操作

バケット所有アカウントがオブジェクトを所有している場合、バケットポリシーと IAM ユーザーポリシーは、オブジェクトレベルの操作でもバケットレベルの操作と同じように機能します。例えば、バケットポリシーが設定されていない場合、バケットはバケット所有者のアカウントの任意の IAM アイデンティティからのオブジェクトリクエストを暗黙的に許可します。また、バケットは、他の任意のアカウントの他の IAM ID からのオブジェクトリクエストや、匿名 (署名なし) リクエストを暗黙的に拒否します。ただし、IAM ユーザーポリシーが設定されていない場合、リクエスタのすべてのオブジェクトリクエストは (AWS アカウントのルートユーザーでない限り) 暗黙的に拒否されます。

オブジェクトが外部アカウントによって所有されている場合、オブジェクトへのアクセスはオブジェクトアクセスコントロールリスト (ACL) を通じてのみ許可されます。バケットポリシーと IAM ユーザーポリシーは、引き続きオブジェクトリクエストを拒否するために使用できます。

したがって、バケットポリシーまたは IAM ユーザーポリシーによりアクセス拒否 (403 Forbidden) エラーが発生しないことを確認するには、次の要件が満たされていることを確認します。

  • 同じアカウントでアクセスする場合、バケットポリシーまたは IAM ユーザーポリシーのいずれにも、アクセス権限を付与するリクエスタに対する明示的な Deny 記述があってはなりません。バケットポリシーと IAM ユーザーポリシーのみを使用してアクセス権限を付与する場合は、これらのポリシーの 1 つに少なくとも 1 つの明示的な Allow ステートメントが必要です。

  • クロスアカウントアクセスの場合、バケットポリシーまたは IAM ユーザーポリシーのいずれにも、アクセス許可を付与するリクエスタに対する明示的な Deny ステートメントを含めることはできません。バケットポリシーと IAM ユーザーポリシーのみを使用してクロスアカウントアクセス許可を付与する場合は、リクエスタのバケットポリシーと IAM ユーザーポリシーの両方に明示的な Allow ステートメントが含まれていることを確認します。

注記

バケットポリシーの Allow ステートメントは、同じバケット所有アカウントが所有するオブジェクトにのみ適用されます。ただし、バケットポリシーの Deny ステートメントは、オブジェクトの所有権に関係なくすべてのオブジェクトに適用されます。

バケットポリシーを確認または編集する方法
注記

バケットポリシーを表示または編集するには、s3:GetBucketPolicy アクセス許可が必要です。

  1. AWS Management Console にサインインし、Amazon S3 コンソール (https://console.aws.amazon.com/s3/) を開きます。

  2. 左側のナビゲーションペインで、[バケット] を選択します。

  3. [バケット] リストで、バケットポリシーを表示または編集するバケットの名前を選択します。

  4. [アクセス許可] タブを選択します。

  5. [バケットポリシー][編集] を選択します。[バケットポリシーを編集] ページが表示されます。

AWS Command Line Interface (AWS CLI) を使用してバケットポリシーを確認または編集するには、get-bucket-policy コマンドを使用します。

注記

バケットポリシーが適正でないためにバケットからロックアウトされた場合は、AWS アカウントのルートユーザー認証情報を使用してAWS Management Consoleにサインインします。バケットへのアクセスを回復するには、必ず AWS アカウントのルートユーザーの認証情報を使用してバケットポリシーを削除します。

アクセス許可を確認するためのヒント

リクエスタが Amazon S3 オペレーションを実行するための適切な権限を持っているかどうかを確認するには、以下を試してください。

Amazon S3 ACL 設定

ACL 設定を確認するときは、まずオブジェクト所有権の設定を確認して、バケットで ACL が有効になっているかどうかを確認してください。ACL アクセス許可を使用できるのは、アクセス許可を付与するためのみであり、リクエストを拒否するためには使用できないことに注意が必要です。ACL は、バケットポリシーや IAM ユーザーポリシーでの明示的拒否によって拒否されたリクエスタにアクセス権を付与する目的でも使用できません。

オブジェクト所有権設定にバケット所有者強制を設定

バケット所有者強制設定が有効になっている場合、この設定によってバケットとオブジェクトに適用されるすべての ACL が無効になるため、ACL 設定によってアクセス拒否 (403 Forbidden) エラーが発生する可能性はほとんどありません。Amazon S3 バケットのデフォルト (および推奨) 設定は、バケット所有者強制です。

オブジェクト所有権設定にバケット所有者優先またはオブジェクト作成者を設定

ACL 権限は、バケット所有者優先設定またはオブジェクト作成者設定でも引き続き有効です。ACL には、バケット ACL とオブジェクト ACL の 2 種類があります。この 2 種類の ACL の違いについては、「ACL アクセス許可とアクセスポリシーのアクセス許可のマッピング」を参照してください。

拒否されたリクエストのアクションに応じて、以下のようにバケットまたはオブジェクトの ACL 権限を確認してください

  • Amazon S3 が LISTPUT オブジェクト、GetBucketAcl、または PutBucketAcl リクエストを拒否した場合は、バケットの ACL 権限を確認してください。

    注記

    バケット ACL 設定では、GET オブジェクトのアクセス許可を付与することはできません。

  • Amazon S3 が S3 オブジェクトの GET リクエスト、または PutObjectAcl リクエストを拒否した場合は、そのオブジェクトの ACL 権限を確認してください

    重要

    オブジェクトを所有するアカウントがバケットを所有するアカウントと異なる場合、オブジェクトへのアクセスはバケットポリシーによって制御されません。

クロスアカウントによるオブジェクト所有権である場合の、GET オブジェクトリクエストによるアクセス拒否 (403 Forbidden) エラーのトラブルシューティング

バケットのオブジェクト所有権設定を確認して、オブジェクト所有者を判断します。オブジェクト ACL へのアクセス権限がある場合は、オブジェクト所有者のアカウントを確認することもできます。(オブジェクト所有者のアカウントを表示するには、Amazon S3 コンソールでオブジェクト ACL 設定を確認します)。または、GetObjectAcl リクエストを実行してオブジェクト所有者の正規 ID を検索し、オブジェクト所有者のアカウントを確認することもできます。デフォルトでは、ACL はオブジェクト所有者のアカウントへの GET リクエストに対する明示的な許可権限を付与します。

オブジェクト所有者がバケット所有者と異なることを確認してから、ユースケースとアクセスレベルに応じて、次のいずれかの方法を選択してアクセス拒否 (403 Forbidden) エラーに対処します。

  • ACL を無効にする (推奨) - この方法はすべてのオブジェクトに適用され、バケット所有者が実行できます。この方法では、バケット所有者に所有権が自動的に与えられ、バケット内のすべてのオブジェクトを完全に制御できます。この方法を実行する前に、ACL を無効にする前提条件を確認します。バケット所有者強制 (推奨) モードにバケットを設定する方法については、「既存のバケットでのオブジェクトの所有権の設定」を参照してください。

    重要

    アクセス拒否 (403 Forbidden) エラーを防ぐには、ACL を無効にする前に、必ず ACL 権限をバケットポリシーに移行してください。詳細については、「ACL 権限からの移行に関するバケットポリシーの例」を参照してください。

  • オブジェクト所有者をバケット所有者に変更 - この方法は個々のオブジェクトに適用できますが、オブジェクトの所有権を変更できるのはオブジェクト所有者 (または適切な権限を持つユーザー) のみです。追加の PUT コストが適用される場合があります。(詳細については、「Amazon S3 の料金」を参照してください)。この方法では、バケット所有者にオブジェクトの完全な所有権が付与され、バケット所有者はバケットポリシーを通じてオブジェクトへのアクセスを制御できます。

    オブジェクトの所有権を変更するには、以下のいずれかを実行します。

    • バケット所有者はオブジェクトをコピーしてバケットに戻すことができます。

    • バケットのオブジェクト所有権設定を「バケット所有者優先」に変更できます。バージョニングを無効にすると、バケット内のオブジェクトは上書きされます。バージョニングが有効になっている場合、同じオブジェクトの重複バージョンがバケットに表示され、バケット所有者はライフサイクルルールを期限切れに設定できます。オブジェクト所有権設定を変更する方法については、「既存のバケットでのオブジェクトの所有権の設定」を参照してください。

      注記

      オブジェクト所有権の設定をバケット所有者優先に更新すると、その設定はバケットにアップロードされた新しいオブジェクトにのみ適用されます。

    • bucket-owner-full-control 既定オブジェクト ACL を使用して、オブジェクト所有者にオブジェクトを再度アップロードさせることができます。

    注記

    クロスアカウントアップロードの場合、バケットポリシーで bucket-owner-full-control 既定オブジェクト ACL を要求することもできます。バケットポリシーの例については、バケット所有者はフルコントロール権限を持ちながら、オブジェクトをアップロードするためのクロスアカウントアクセス許可を付与するを参照してください。

  • オブジェクト作成者をオブジェクト所有者のままにする - この方法ではオブジェクトの所有者は変更されませんが、オブジェクトへのアクセス権限を個別に付与できます。オブジェクトへのアクセス権限を付与するには、そのオブジェクトに対する PutObjectAcl 権限が必要です。次に、アクセス拒否 (403 Forbidden) エラーを修正するために、リクエスタをオブジェクトの ACL 内のオブジェクトへのアクセス権限付与者として追加します。詳細については、「ACL の設定」を参照してください。

S3 ブロックパブリックアクセス設定

失敗したリクエストがパブリックアクセスまたはパブリックポリシーに関連している場合は、アカウント、バケット、または S3 アクセスポイントの S3 ブロックパブリックアクセス設定を確認します。S3 パブリックアクセスブロック設定に関連するアクセス拒否エラーのトラブルシューティングの詳細については、「ブロックパブリックアクセス設定によるアクセス拒否」を参照してください。

Amazon S3 の暗号化設定

Amazon S3 はバケットのサーバー側暗号化をサポートしています。サーバー側の暗号化とは、データを受信するアプリケーションまたはサービスによって、送信先でデータを暗号化することです。Amazon S3 は、AWS データセンターのディスクに書き込まれるときにデータをオブジェクトレベルで暗号化し、お客様がデータにアクセスするときに復号します。

デフォルトで、Amazon S3 では、Amazon S3 のすべてのバケットに対する基本レベルの暗号化として、Amazon S3 マネージドキーによるサーバー側の暗号化 (SSE-S3) が適用されるようになりました。Amazon S3 では、オブジェクトをアップロードするときにサーバー側を暗号化する方法も指定できます。

バケットのサーバー側暗号化ステータスと暗号化設定を確認する方法
  1. AWS Management Console にサインインし、Amazon S3 コンソール (https://console.aws.amazon.com/s3/) を開きます。

  2. 左側のナビゲーションペインで、[バケット] を選択します。

  3. [バケット] リストで、暗号化設定を確認するバケットを選択します。

  4. [プロパティ] タブを選択します。

  5. [デフォルトの暗号化] セクションまでスクロールして、[暗号化タイプ] 設定を表示します。

AWS CLI を使用して暗号化設定を確認するには、get-bucket-encryption コマンドを使用します。

オブジェクトの暗号化状態を確認する方法
  1. AWS Management Console にサインインし、Amazon S3 コンソール (https://console.aws.amazon.com/s3/) を開きます。

  2. 左側のナビゲーションペインで、[バケット] を選択します。

  3. [バケット] リストで、オブジェクトが含まれるバケットの名前を選択します。

  4. [オブジェクト] リストで、暗号化を追加または変更するオブジェクトの名前を選択します。

    オブジェクトの詳細ページが表示されます。

  5. [サーバー側の暗号化設定] セクションまでスクロールすると、オブジェクトのサーバー側暗号化設定が表示されます。

AWS CLI を使用してオブジェクト暗号化ステータスを確認するには、head-object コマンドを使用します。

暗号化とアクセス許可の要件

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 (お客様提供のキーを使用) - 追加の権限は必要ありません。バケットポリシーを設定すると、バケットのオブジェクトに対してお客様が用意した暗号化キーでサーバー側の暗号化をリクエストおよび制限できます

オブジェクトがカスタマーマネージドキーで暗号化されている場合は、KMS キーポリシーによって kms:GenerateDataKey または kms:Decrypt アクションの実行が許可されていることを確認してください。KMS キーポリシーを確認する手順については、AWS Key Management Service デベロッパーガイドの「キーポリシーの表示」を参照してください。

S3 オブジェクトロック設定

バケットで S3 オブジェクトロックが有効で、オブジェクトが保持期間またはリーガルホールドで保護されている場合、オブジェクトを削除しようとすると Amazon S3 はアクセス拒否 (403 Forbidden) エラーを返します。

バケットでオブジェクトロックが有効になっているかどうかを確認する方法
  1. AWS Management Console にサインインし、Amazon S3 コンソール (https://console.aws.amazon.com/s3/) を開きます。

  2. 左側のナビゲーションペインで、[バケット] を選択します。

  3. [バケット] リストで、確認するバケットの名前を選択します。

  4. [プロパティ] タブを選択します。

  5. [オブジェクトロック] セクションまでスクロールします。[オブジェクトロック] 設定が [有効] または [無効] であるかを確認します。

オブジェクトが保持期間またはリーガルホールドで保護されているかを判断するには、オブジェクトのロック情報を参照します。

オブジェクトが保持期間またはリーガルホールドで保護されている場合は、次の点を確認します。

  • オブジェクトバージョンがコンプライアンス保存モードで保護されている場合、それを完全に削除する方法はありません。AWS アカウントのルートユーザーを含む、すべてのリクエスタからの永続的な DELETE リクエストは、アクセス拒否 (403 Forbidden) エラーになります。また、コンプライアンス保持モードで保護されているオブジェクトの DELETE リクエストを送信すると、Amazon S3 はそのオブジェクトの削除マーカーを作成することに注意してください。

  • オブジェクトバージョンがガバナンス保持モードで保護されていて s3:BypassGovernanceRetention 権限がある場合は、保護をバイパスしてバージョンを完全に削除できます。詳細については、「ガバナンスモードのバイパス」を参照してください。

  • オブジェクトバージョンがリーガルホールドで保護されている場合は、永久 DELETE リクエストを実行するとアクセス拒否 (403 Forbidden) エラーが発生する可能性があります。オブジェクトバージョンを永久に削除するには、オブジェクトバージョンのリーガルホールドを解除する必要があります。リーガルホールドを解除するには、s3:PutObjectLegalHold 許可が必要です。リーガルホールドの解除の詳細については、「オブジェクトロックの設定」を参照してください。

VPC エンドポイントポリシー

仮想プライベートクラウド (VPC) エンドポイントを使用して Amazon S3 にアクセスする場合は、VPC エンドポイントポリシーによって Amazon S3 リソースへのアクセスがブロックされていないことを確認します。デフォルトでは、VPC エンドポイントポリシーは Amazon S3 へのすべてのリクエストを許可します。特定のリクエストを制限するように VPC エンドポイントポリシーを設定することもできます。VPC エンドポイントポリシーを確認する方法については、次のリソースを参照してください。

AWS Organizations ポリシー

あなたの AWS アカウント が組織に所属している場合、AWS Organizations ポリシーによって Amazon S3 リソースへのアクセスがブロックされる場合があります。デフォルトでは、AWS Organizations ポリシーは Amazon S3 へのいずれのリクエストもブロックしません。ただし、AWS Organizations ポリシーが S3 バケットへのアクセスをブロックするように設定されていないことを確認してください。AWS Organizations ポリシーを確認する方法については、以下のリソースを参照してください。

アクセスポイント設定

Amazon S3 Access Points 経由でリクエストを行っているときにアクセス拒否 (403 Forbidden) エラーが表示される場合は、次の点を確認する必要がある場合があります。

  • アクセスポイントの設定

  • アクセスポイントに使用される IAM ユーザーポリシー

  • クロスアカウントアクセスポイントの管理または設定に使用されるバケットポリシー

アクセスポイントの設定とポリシー
  • アクセスポイントを作成するときに、インターネットまたは VPC をネットワークオリジンとして指定できます。ネットワークオリジンが VPC のみに設定されている場合、Amazon S3 は指定 VPC 以外のアクセスポイントへのリクエストをすべて拒否します。アクセスポイントのネットワークオリジンを確認するには、Virtual Private Cloud に制限されたアクセスポイントの作成 を参照してください。

  • アクセスポイントでは、カスタムのブロックパブリックアクセス設定を構成することもできます。これは、バケットレベルまたはアカウントレベルのブロックパブリックアクセス設定と同様に機能します。カスタムのブロックパブリックアクセス設定を確認する方法は、「アクセスポイントへのパブリックアクセスの管理」を参照してください。

  • アクセスポイントを使用して Amazon S3 へのリクエストを正常に行うには、リクエスタが必要な IAM 権限を持っていることを確認します。詳細については、「アクセスポイントを使用するための IAM ポリシーの設定」を参照してください。

  • リクエストにクロスアカウントアクセスポイントが含まれる場合、バケット所有者がアクセスポイントからのリクエストを許可するようにバケットポリシーを更新済みであることを確認します。詳細については、「クロスアカウントアクセスポイントへのアクセス許可の付与」を参照してください。

このトピックのすべての項目を確認してもアクセス拒否 (403 Forbidden) エラーが解決しない場合は、Amazon S3 リクエスト ID を取得して、追加ガイダンスについて AWS Support まで問い合わせてください。

プライバシーサイト規約Cookie の設定
© 2024, Amazon Web Services, Inc. or its affiliates.All rights reserved.