Amazon S3 から 403: Access Denied エラーをトラブルシューティングする方法

最終更新日: 2021 年 6 月 25 日

ユーザーが 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 バケットからオブジェクトを読み取る問題を診断するのに役立ちます。

解決方法

バケットとオブジェクトの所有権

デフォルトでは、S3 オブジェクトの所有者はそれをアップロードした AWS アカウントになります。これは、バケットの所有者が他のアカウントである場合にも当てはまります。他のアカウントが自分のバケットにオブジェクトをアップロードできる場合は、自分のユーザーがアクセスできないオブジェクトを所有するアカウントを確認します。

1. list-buckets AWS コマンドラインインターフェイス (AWS CLI) コマンドを実行して、アカウントの 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 を使用して、オブジェクトのアップロード先となるバケットでポリシーを設定します。その後で、S3 Object Ownership を有効化します。所有権が有効化されることにより、bucket-owner-full-control ACL を使用してオブジェクトがアップロードされると、オブジェクトの所有者がバケット所有者に自動的に変更されます。

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

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

アクセスを誤って拒否する可能性のあるすべての記述について、バケットポリシー、またはそれを関連付けられた IAM ユーザーポリシーを見直します。ポリシーで適切でない拒否ステートメント、欠けているアクション、適切でないスペーシングなどを確認します。

1. 拒否ステートメントについては、Multi-Factor Authentication (MFA) をもとにしたアクセス許可を拒否する任意の条件、暗号化キー、固有の IP アドレス、固有の VPC エンドポイントなどを確認してください。自分のバケットへのリクエストがバケットポリシーまたは IAM ポリシーの全条件に一致することを確認します。そうでない場合、アクセスは拒否されることが想定されます。

注: MFA が必要で、ユーザーが AWS CLI を使ってリクエストを送信するのであれば、ユーザーが MFA を使用して AWS CLI を構成するようにします。

たとえば、次のバケットポリシーの Statement1 は、DOC-EXAMPLE-BUCKET からオブジェクト (s3:GetObject) をダウンロードするためのパブリックアクセスを許可しています。しかし、Statement2 では、リクエストが VPC エンドポイントの vpce-1a2b3c4d からでない限り、DOC-EXAMPLE-BUCKET からオブジェクトをダウンロードしようとするすべてのアクセスを明示的に拒否します。この場合、拒否ステートメントが優先されます。つまり、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. バケットポリシーまたは IAM ポリシーを確認して、ユーザーが必要とする Amazon S3 のアクションが許可されるようにします。たとえば、次のバケットポリシーには 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 ユーザーポリシーに余分なスペースがないことを確認してください。たとえば、次の 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 パブリックアクセスのブロック設定を確認します。これらの設定は、パブリックな読み取りアクセスを許可するアクセス許可を上書きできます。Amazon S3 ブロックパブリックアクセスは個々のバケットまたは AWS アカウントに適用できます。

Amazon S3 にアクセスするための認証情報

Amazon S3 にアクセスするためにユーザーが設定した認証情報を見直します。AWS SDK および AWS CLI は、IAM ユーザーの認証情報、またはバケットへのアクセス許可のあるロールを使用するように設定されている必要があります。

設定された認証情報を確認するために AWS CLI で configure コマンドを実行します。

aws configure list

ユーザーが Amazon EC2 インスタンスを通して、バケットにアクセスする場合は、インスタンスが正しいロールを使用していることを確認してください。インスタンスに接続し、get-caller-identity コマンドを実行します。

aws sts get-caller-identity

一時的なセキュリティ認証情報

AWS Security Token Service (AWS STS) を使用して付与された一時的なセキュリティ認証情報から、ユーザーに対し Access Denied エラーが返される場合は、関連付けられたポリシーを確認します。

管理者が、AssumeRole API 呼び出し、または assume-role コマンドを使用して一時的なセキュリティ認証情報を作成している場合は、必要に応じてセッション固有のポリシーを渡すことができます。

Amazon S3 からの Access Denied エラーに関連付けられたセッションポリシーを検索するには、AWS CloudTrail イベント履歴で AssumeRole イベントを探します。Amazon S3 にアクセスするための失敗したリクエストと同じ時間枠で 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": "{\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 エラーが表示されるようになります。

head-object AWS CLI コマンドを実行して、オブジェクトがバケットに存在するかどうかを確認します。

aws s3api head-object --bucket DOC-EXAMPLE-BUCKET --key exampleobject.jpg

バケットにオブジェクトが存在していれば、Access Denied エラーが 404 Not Found エラーを隠すことはありません。アクセス拒否エラーを解決するには、他の設定要件を確認してください。

オブジェクトがバケット内にない場合は、アクセス拒否エラーは「404 Not Found」エラーを隠します。存在しないオブジェクトに関連する問題を解決します。

AWS KMS 暗号化

AWS KMS 暗号化については、次の点にご注意ください。

IAM ユーザーが完全なアクセス許可のあるオブジェクトにアクセスできない場合は、オブジェクトが AWS KMS で暗号化されているかどうかを確認します。Amazon S3 コンソールを使用してオブジェクトのプロパティを表示すると、オブジェクトの暗号化に関する情報を確認できます。
オブジェクトが KMS 暗号化されている場合は、KMS キーポリシーが IAM ユーザーに必要最低限なアクセス許可を付与していることを確認します。たとえば、IAM ユーザーが S3 オブジェクトのダウンロードのみにキーを使用している場合、 (少なくとも) KMS: Decrypt アクションのアクセス許可を持っている必要があります。詳細については、AWS アカウントへのアクセス許可とIAM ポリシの有効化をご参照ください。
IAM アイデンティティとキーが同じアカウントにある場合、 KMS: Decrypt アクセス許可はキーポリシーを使用して付与する必要があります。キーポリシーは、IAM ポリシーと同じ IAM アイデンティティを参照する必要があります。
IAM ユーザーが AWS KMS キーとは異なるアカウントに属している場合、これらのアクセス許可は、 IAM ポリシーでも付与されている必要があります。たとえば、KMS: Decrypt アクセス許可は、キーポリシーと IAM ポリシーの両方で指定する必要があります。 IAM ユーザーと KMS キー間のクロスアカウントアクセスの詳細については、他のアカウントのユーザーへの CMK の使用許可ご参照ください。
S3 バケットキーを有効にした後に403レスポンスとなる場合は、呼び出しプリンシパルの KMS: Decrypt アクセス許可を含む CMK キーポリシーを確認します。呼び出しプリンシパルが CMK と異なるアカウントにある場合は、IAM ポリシーにも KMS: Decrypt アクセス許可を含める必要があります。問題を特定し、Access Denied エラーが S3 バケットキーに関連しているかどうかを確認するには、S3 バケットキー機能を一時的に無効にします。

バケットで有効化されているリクエスタ支払い

バケットでリクエスタ支払いが有効化されているのであれば、他のアカウントのユーザーは自分のバケットにリクエストを送信するとき、リクエスタ支払者 パラメータを指定する必要があります。それ以外の場合は、それらのユーザーには、アクセス拒否エラーが表示されます。リクエスタ支払いが有効になっているかどうかを確認するには、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 の機能の詳細については、組織内のすべての機能の有効化を参照してください。