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

所要時間4分
0

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

解決策

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

AWS Systems Manager では、AWSSupport-TroubleshootS3PublicRead オートメーションドキュメントを使用します。このオートメーションドキュメントは、指定したパブリック S3 バケットからのオブジェクトの読み取り問題を診断するために役立ちます。

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

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

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

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

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

1.    list-buckets AWS コマンドラインインターフェイス (AWS CLI) コマンドを実行し、所有者 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 を使用してオブジェクトがアップロードされると、オブジェクトの所有者がバケット所有者に自動的に更新されます。

バケットに対する権限がある 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) を使用して付与された一時的なセキュリティ認証情報から、ユーザーにアクセス拒否エラーが返される場合は、関連付けられたセッションポリシーを確認します。管理者は、AssumeRole API コールまたは assume-role コマンドを使用して一時的なセキュリティ認証情報を作成している場合は、セッション固有のポリシーを渡すことができます。

Amazon S3 によるアクセス拒否エラーに関連付けられたセッションポリシーを検索するには、AWS CloudTrail イベント履歴内の AssumeRole イベントを探します。失敗した Amazon S3 へのアクセスリクエストと同じ時間枠内にある AssumeRole イベントを探すようにしてください。次に、policy パラメーターまたは policyArns パラメーターについて、関連する CloudTrail ログの requestParameters フィールドを見直します。関連付けられたポリシーまたはポリシー ARN が、必要な Amazon S3 許可を付与することを確認してください。

例えば、以下の CloudTrail ログのスニペットは、DOC-EXAMPLE-BUCKETs3: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 エラーを隠すことはありません。アクセス拒否エラーを解決するには、他の設定要件を確認してください。

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

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

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

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

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

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

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

関連情報

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

AWS サポートの Amazon S3 リクエスト ID の取得

AWS公式
AWS公式更新しました 2年前
コメントはありません

関連するコンテンツ