Amazon S3 での、403 Access Denied エラーをトラブルシューティングする方法を教えてください。

所要時間4分

ユーザーが Amazon Simple Storage Service (Amazon S3) バケットのオブジェクトにアクセスしようとしたところ、Amazon S3 が 403 Access Denied (アクセス拒否) エラーを返します。

解決策

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI で発生したエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

AWS Systems Manager のオートメーションドキュメントを使用する

指定されたパブリック S3 バケットからオブジェクトを読み取る際の問題を特定するには、AWS Systems Manager の AWSSupport-TroubleshootS3PublicRead オートメーションドキュメントを使用します。

バケットとオブジェクトの所有権設定を確認する

GetObject または HeadObject リクエストでの AccessDenied エラーの場合、そのオブジェクトとバケットの所有者が同一かどうかを確認します。また、バケット所有者に、読み取りまたはフルコントロールのアクセスコントロールリスト (ACL) アクセス許可があるかどうかを確認します。

注: 新しいバケットの作成時に、ACL はデフォルトでは無効になります。S3 リソースへのアクセスを制御するには、ACL ではなく、AWS Identity and Access Management (IAM) ポリシーを使用するのがベストプラクティスです。

オブジェクトを所有しているアカウントを確認する

デフォルトでは、オブジェクトが保存されているバケットを所有する AWS アカウントがオブジェクトも所有します。他のアカウントから、お使いのバケットにオブジェクトをアップロードできる場合は、ユーザーがアクセスできないオブジェクトのアクセス許可を確認してください。

バケットとオブジェクトの所有者が同じかどうかを確認するには、次の手順を実行します。

AWS CLI コマンド list-buckets を実行して、アカウントの Amazon S3 正規 ID を取得します。

aws s3api list-buckets --query "Owner.ID"

list-objects コマンドを実行して、ユーザーがアクセスできないオブジェクトを所有しているアカウントの Amazon S3 正規 ID を取得します。
```
aws s3api list-objects --bucket DOC-EXAMPLE-BUCKET --prefix exampleprefix
```
注: DOC-EXAMPLE-BUCKET をバケットの名前に置き換え、exampleprefix をプレフィックス値に置き換えます。list-objects コマンドを使用すると、複数のオブジェクトを同時にチェックできます。
正規 ID が一致しない場合は、そのオブジェクトを所有していないことを示します。オブジェクトの所有者が put-object-acl コマンドを実行すると、オブジェクトのフルコントロールを付与できます。
```
aws s3api put-object-acl --bucket DOC-EXAMPLE-BUCKET --key exampleobject.jpg --acl bucket-owner-full-control
```
注: DOC-EXAMPLE-BUCKET をオブジェクトを含むバケットの名前に置き換え、exampleobject.jpg をキー名に置き換えます。
オブジェクト所有者がオブジェクトの ACL を bucket-owner-full-control に変更すると、バケット所有者はオブジェクトにアクセスできるようになります。さらに、オブジェクト所有者をバケットのアカウントに変更するには、バケットのアカウントから cp コマンドを実行して、オブジェクトをそれ自体にコピーします。

バケットへのアクセス許可がある IAM ロールを作成する

IAM ロールとバケット所有者が同じアカウントに所属している場合、IAM ロールまたはバケットのどちらかにアクセス許可が必要です。アクセス許可が、IAM ロールとバケットの両方にある必要はありません。

複数アカウントにアクセス許可を追加するには、バケットへのアクセス許可を持つ IAM ロールをアカウント内に作成します。その後、別の AWS アカウントに、その IAM ロールを引き受けるためのアクセス許可を付与します。詳細については、「IAM チュートリアル: IAM ロールを使用して AWS アカウント間でアクセス許可を委任する」を参照してください。

バケットポリシーまたは IAM ユーザーポリシーを確認する

アクセスを拒否している可能性のあるステートメントについて、バケットポリシーまたは関連する IAM ユーザーポリシーを見直します。バケットに対するリクエストが、バケットポリシーまたは IAM ポリシーの条件を満たしていることを確認します。ポリシーに Deny ステートメントの誤り、アクションの欠落、タイプミスがないか確認します。

Deny ステートメントの条件

Deny ステートメントで、次の条件に基づいてアクセスをブロックする条件がないか確認します。

多要素認証 (MFA)
暗号化キー
特定の IP アドレス
特定の仮想プライベートクラウド (VPC) または VPC エンドポイント
特定の IAM ユーザーまたはロール

注: MFA が必須であり、ユーザーがリクエストの送信に AWS CLI を使用する場合は、そのユーザーは AWS CLI が MFA を使用するように設定する必要があります。

例えば、以下のバケットポリシーの Statement1 は、DOC-EXAMPLE-BUCKET からオブジェクト (s3:GetObject) をダウンロードするためのパブリックアクセスを許可します。Statement2 は、リクエストが VPC エンドポイント vpce-1a2b3c4d からのものである場合を除き、すべてのユーザーに対して DOC-EXAMPLE-BUCKET からオブジェクトをダウンロードするためのアクセスを明示的に拒否します。Deny ステートメントは Allow ステートメントよりも優先されるため、ユーザーが 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": "*"  
    }  
  ]  
}

バケットポリシーまたは IAM ポリシー

バケットポリシーまたは IAM ポリシーが、ユーザーが実行する必要のある Amazon S3 アクションを許可していることを確認します。たとえば、次のバケットポリシーには s3:PutObjectAcl アクションへのアクセス許可が含まれていません。

{  
  "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"  
        ]  
      }  
    }  
  ]  
}

IAM ユーザーがオブジェクトの ACL を変更しようとすると、Access Denied エラーが発生します。

その他のポリシーエラー

バケットポリシーや IAM ユーザーポリシーに、余分なスペース、誤った ARN、タイプミスなどがないか確認します。

IAM ポリシーの ARN に余分なスペースがある場合、ARN は正しく評価されず、ユーザーには Access Denied エラーが表示されます。たとえば、IAM ポリシーの ARN に余分なスペースがある場合 (arn:aws:s3::: DOC-EXAMPLE-BUCKET/*)、arn:aws:s3:::%20DOC-EXAMPLE-BUCKET/ として評価されます。

IAM アクセス許可の境界が Amazon S3 へのアクセスを許可していることを確認する

IAM エンティティに設定されている IAM アクセス許可の境界が、Amazon S3 へのアクセスを許可していることを確認します。

バケットの Amazon S3 Block Public Access 設定を確認する

許可されているパブリック読み取りリクエストで Access Denied エラーが発生した場合は、バケットで、アカウントとバケットのバケットに対する Amazon S3 Block Public Access 設定を確認します。これらの設定により、パブリック読み取りアクセスを許可するアクセス許可が上書きされることがあります。

ユーザー認証情報を見直す

Amazon S3 にアクセスするためにユーザーが設定した認証情報を見直します。ユーザーは、バケットにアクセスできる IAM ID の認証情報を使用するように AWS SDK と AWS CLI を設定する必要があります。

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 コマンドを使用して一時的なセキュリティ認証情報を作成するときに、セッション固有のポリシーを渡すことができます。

関連するセッションポリシーを特定するには、失敗したアクセスリクエストと同じ期間内の AWS CloudTrail イベント履歴で AssumeRole イベントを検索します。次に、CloudTrail ログの requestParameters フィールドで、policy または policyArns パラメータを確認します。関連するポリシーまたはポリシー ARN が、必要な Amazon S3 許可を付与するいることを確認します。

たとえば、次の CloudTrail ログのスニペットは、一時的な認証情報には、DOC-EXAMPLE-BUCKET に s3:GetObject アクセス許可を付与するインラインセッションポリシーがあることを示しています。

"requestParameters": {  
    "roleArn": "arn:aws:iam::123412341234:role/S3AdminAccess",  
    "roleSessionName": "s3rolesession",  
    "policy": "{  
    "Version": "2012-10-17",  
    "Statement": [{  
            "Effect": "Allow",  
            "Action": [  
                "s3:GetObject"  
            ],  
            "Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"]  
    }]  
    }"  
}

Amazon VPC エンドポイントのポリシーに、S3 リソースにアクセスするための正しいアクセス許可があることを確認する

ユーザーがバケットへのアクセスに、Amazon Virtual Private Cloud (Amazon VPC) エンドポイント経由でルーティングされた EC2 インスタンスを使用している場合は、VPC エンドポイントのポリシーを確認してください。

たとえば、次の 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 アクセスポイントの IAM ポリシーを確認する

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

注: DOC-EXAMPLE-BUCKET は、実際の S3 バケットの名前に置き換えます。

オブジェクトがバケット内にある場合、Access Denied エラーにより 404 Not Found エラーがマスキングされることはありません。Access Denied エラーを解決するには、他の設定要件を確認します。

オブジェクトがバケット内にない場合は、Access Denied エラーにより 404 Not Found エラーがマスキングされます。欠落しているオブジェクトに関連する問題を解決します。

AWS KMS 暗号化設定を確認する

IAM ユーザーがオブジェクトに対する完全なアクセス許可を持っているが、そのオブジェクトにアクセスできない場合は、オブジェクトに AWS Key Management Service (AWS KMS) 暗号化 (SSE-KMS) があるかどうかを確認します。Amazon S3 コンソールを使用すると、オブジェクトのプロパティを表示し、オブジェクトの SSE-KMS 情報を確認できます。

オブジェクトがカスタマーマネージドキーで暗号化されている場合、KMS キーポリシーが kms:GenerateDataKey および kms:Decrypt アクションの実行を許可している必要があります。詳細については、「AWS アカウントへのアクセス許可と IAM ポリシーの有効化」を参照してください。

IAM ユーザーが AWS KMS キー以外のアカウントに属している場合は、IAM ポリシーを変更し、Kms:Decrypt アクセス許可を付与します。たとえば、 SSE-KMS オブジェクトをダウンロードするには、キーポリシーと IAM ポリシーの両方で kms: Decrypt アクセス許可を指定する必要があります。IAM ユーザーと KMS キー間のクロスアカウントアクセスの詳細については、「他のアカウントのユーザーが KMS キーを使用できるようにする」を参照してください。

リクエスタ支払いが有効になっているバケットの場合、ユーザーが request-payer パラメータを指定済みであることを確認します

バケットでリクエスタ支払いを有効にした場合、他のアカウントのユーザーがそのバケットにリクエストを送信するときには、request-payer パラメータが指定されている必要があります。リクエスタ支払いを有効にしたかどうかを確認するには、Amazon S3 コンソールを使用してバケットのプロパティを確認します。

次の例の AWS CLI コマンドには、リクエスタ支払いがあるクロスアカウントバケットにアクセスするための適切なパラメータが含まれています。

aws s3 cp exampleobject.jpg s3://DOC-EXAMPLE-BUCKET/exampleobject.jpg --request-payer requester

AWS Organizations のSCPを確認する

AWS Organizations を使用している場合は、サービスコントロールポリシー (SCP)を確認し、Amazon S3 へのアクセスが許可されていることを確認します。SCP は、影響を受けるアカウントに最大限のアクセス許可を指定します。たとえば、次の SCP は Amazon S3 へのアクセスを明示的に拒否しているため、Access Denied エラーが発生します。

{  
  "Version": "2012-10-17",  
  "Statement": [  
    {  
      "Effect": "Deny",  
      "Action": "s3:*",  
      "Resource": "*"  
    }  
  ]  
}

AWS Organizations の機能の詳細については、「AWS Organizations で、組織用のすべての機能を有効にする」を参照してください。