Amazon S3 からの 403 Access Denied エラーをトラブルシューティングするにはどうすればよいですか?

解決方法

AWS Systems Manager Automation のドキュメントを使用する

AWS Systems Manager では、AWSSupport-TroubleshootS3PublicRead オートメーションドキュメントを使用します。このオートメーションドキュメントは、指定したパブリック S3 バケットからのオブジェクトの読み取り問題を診断するために役立ちます。AWS Systems Manager の AWSSupport-TroubleshootS3AccessSameAccount オートメーションドキュメントを使用して、S3 バケットからのアクセス拒否の診断に役立てることもできます。AWSSupport-TroubleshootS3AccessSameAccount では、クロスアカウントリソースの許可は評価されません。

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

GetObject または HeadObject リクエストによる AccessDenied エラーの場合は、そのオブジェクトがバケット所有者にも所有されているかどうかを確認します。また、バケット所有者がアクセスコントロールリスト (ACL) の読み取り権限またはフルコントロールアクセスコントロールリスト (ACL) アクセス許可を持っているかどうかを確認します。

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

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

注: AWS CLI コマンドの実行時にエラーが発生した場合は、AWS CLI の最新バージョンを使用していることを確認してください。

1.    AWS Command Line Interface (AWS CLI) コマンド list-buckets を実行して、所有者 ID をクエリしてアカウントの Amazon S3 正規 ID を取得します。

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

2.    list-objects コマンドを実行して、ユーザーがアクセスできないオブジェクトを所有するアカウントの Amazon S3 正規 ID を取得します。DOC-EXAMPLE-BUCKET をバケットの名前に置き換え、exampleprefix をプレフィックス値に置き換えます。

aws s3api list-objects --bucket DOC-EXAMPLE-BUCKET --prefix exampleprefix

ヒント: 複数のオブジェクトをチェックするには、list-objects コマンドを使用します。

3.    正規 ID が一致しない場合は、そのオブジェクトを所有していません。オブジェクトの所有者は、put-object-acl コマンドを実行して、オブジェクトの完全な制御を許可できます。DOC-EXAMPLE-BUCKET は、オブジェクトを含むバケットの名前に置き換えます。exampleobject.jpg をお使いのキー名に置き換えます。

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 コマンドを実行して、オブジェクトをそれ自体にコピーします。

すべての新しいオブジェクトを別のアカウントのバケットにコピーする

1.    bucket-owner-full-control ACL を使用してオブジェクトをアップロードするバケットポリシーを設定します。

2.    AWS マネジメントコンソールで S3 オブジェクト所有権をアクティブ化して希望のバケット所有者に設定します。

その後、bucket-owner-full-control ACL を使用してオブジェクトがアップロードされると、オブジェクトの所有者がバケット所有者に自動的に更新されます。

バケットに対する許可を持つ AWS Identity and Access Management (IAM) ロールを作成する

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

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

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

拒否ステートメントの条件

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

• 多要素認証 (MFA)
• 暗号化キー
• 特定の IP アドレス
• 特定の VPC または VPC エンドポイント
• 特定の 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": "*"
    }
  ]
}

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

ユーザーが必要とする 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"
        ]
      }
    }
  ]
}

その他のポリシーエラー

バケットポリシーまたは IAM ユーザーポリシーに余分なスペースまたは間違った ARN がないことを確認してください。

例えば、IAM ポリシーに、次のように、Amazon リソースネーム (ARN) に余分なスペースがある場合: arn:aws:s3::: DOC-EXAMPLE-BUCKET/*。この場合、ARN は arn:aws:s3:::%20DOC-EXAMPLE-BUCKET/ として誤って評価され、IAM ユーザーにアクセス拒否エラーが表示されます。

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

バケットにアクセスを試みている IAM ID に設定されている IAM アクセス許可の境界を確認します。IAM アクセス許可の境界が Amazon S3 へのアクセスを許可していることを確認します。

バケットの Amazon S3 ブロックパブリックアクセス設定を確認する

許可されているパブリック読み取りリクエストで「Access Denied」(アクセス拒否) エラーが表示される場合は、バケットの Amazon S3 ブロックパブリックアクセスの設定をチェックします。

アカウントレベルとバケットレベルの両方で S3 のブロックパブリックアクセスの設定を確認します。これらの設定は、パブリック読み取りアクセスを可能にする許可を上書きできます。Amazon S3 ブロックパブリックアクセスは個々のバケットまたは AWS アカウントに適用できます。

ユーザー認証情報を確認する

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

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": "{
    "Version": "2012-10-17",
    "Statement": [{
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"]
        }
    }
]
}
"
}

Amazon VPC エンドポイントポリシーに、自分の S3 バケットとオブジェクトにアクセスするための正しいアクセス許可が含まれていることを確認します。

ユーザーが 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 エラーが発生します。

特殊文字 (スペースなど) が含まれているオブジェクトでは、そのオブジェクトを取得するために特別な処理が必要です。

head-object AWS CLI コマンドを実行して、オブジェクトがバケットに存在するかどうかを確認します。DOC-EXAMPLE-BUCKET は、確認するバケットの名前に置き換えます。

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

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

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

AWS Key Management Service (KMS) の暗号化設定を確認する

AWS KMS (SSE-KMS) 暗号化については、次の点に留意してください。

• IAM ユーザーが完全なアクセス許可のあるオブジェクトにアクセスできない場合は、オブジェクトが SSE-KMS で暗号化されているかどうかを確認します。Amazon S3 コンソールを使用してオブジェクトのプロパティを表示すると、オブジェクトのサーバー側の暗号化に関する情報を確認できます。
• オブジェクトが SSE-KMS 暗号化されている場合は、AWS KMS キーポリシーが、キーを使用するために必要な最小限の許可を IAM ユーザーに付与することを確認します。例えば、IAM ユーザーが S3 オブジェクトのダウンロードのみにキーを使用している場合、この IAM ユーザーは kms:Decrypt の許可を持っている必要があります。詳細については、「AWS アカウントへのアクセスを許可し、IAM ポリシーを有効にする」を参照してください。
• IAM アイデンティティとキーが同じアカウントにある場合は、キーポリシーを使用して kms:Decrypt 許可を付与する必要があります。キーポリシーは、IAM ポリシーと同じ IAM アイデンティティを参照する必要があります。
• IAM ユーザーが AWS KMS キーとは異なるアカウントに属している場合は、これらの許可が IAM ポリシーでも付与されている必要があります。例えば、SSE-KMS 暗号化オブジェクトをダウンロードするには、キーポリシーと IAM ポリシーの両方でkms:Decrypt 許可を指定する必要があります。IAM ユーザーと AWS KMS キー間のクロスアカウントアクセスの詳細については、「他のアカウントのユーザーに AWS 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 のサービスコントロールポリシーを確認する

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

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

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

---

関連情報

Troubleshooting Amazon S3 (Amazon S3 のトラブルシューティング)

Getting S3 request IDs for AWS Support (AWS サポートの S3 リクエスト ID の取得)