翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Amazon S3 でのアクセス拒否エラーのトラブルシューティング
<a name="troubleshooting-access-denied"></a>

以下のトピックでは、Amazon SQS API コールの `AccessDenied` エラーや `AccessDeniedException` エラーの最も一般的な原因について説明します。これらのエラーのトラブルシューティング方法の詳細については、「*AWS 情報センターガイド*」の「[Amazon SQS API コールでの AccessDenied エラーや AccessDeniedException エラーのトラブルシューティングを行うにはどうすればよいですか?](https://repost.aws/knowledge-center/sqs-accessdenied-errors)」を参照してください。

**エラーメッセージの例:**

```
An error occurred (AccessDenied) when calling the SendMessage operation: Access to
        the resource https://sqs.us-east-1.amazonaws.com/ is denied.
```

**- または -**

```
An error occurred (KMS.AccessDeniedException) when calling the SendMessage
        operation: User: arn:aws:iam::xxxxx:user/xxxx is not authorized to perform:
        kms:GenerateDataKey on resource: arn:aws:kms:us-east-1:xxxx:key/xxxx with an explicit
        deny.
```

## Amazon SQS キューポリシーと IAM ポリシー
<a name="sqs-queue-policy-iam-policy"></a>

リクエスタが Amazon S3 オペレーションを実行するための適切なアクセス許可を持っているかどうかを確認するには、次の手順を実行します。
+ Amazon SQS API コールを実行している IAM プリンシパルを特定します。IAM プリンシパルが同じアカウントに属している場合、Amazon SQS キューポリシーまたは AWS Identity and Access Management (IAM) ポリシーのいずれかに、アクションへのアクセスを明示的に許可するアクセス許可が含まれている必要があります。
+ プリンシパルが IAM エンティティの場合:
  + IAM ユーザーまたはロールを特定するには、 AWS マネジメントコンソールの右上隅を確認するか、[`aws sts get-caller-identity`](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/get-caller-identity.html) コマンドを使用できます。
  + IAM ユーザーまたはロールに関連する IAM ポリシーを確認します。次のいずれかの方法を使用します。
    + [IAM ポリシーシミュレーター](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html)を使用して IAM ポリシーをテストします。
    + さまざまな [IAM ポリシータイプ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policy-types)を確認します。
  + 必要に応じて、[IAM ユーザーポリシーを編集します](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html)。
  + キューポリシーを確認し、必要に応じて[編集](sqs-configure-add-permissions.md)します。
+ プリンシパルが AWS サービスの場合、Amazon SQS キューポリシーは明示的にアクセスを許可する必要があります。
+ プリンシパルがクロスアカウントプリンシパルである場合、Amazon SQS キューポリシーと IAM ポリシーの両方がアクセスを明示的に許可する必要があります。
+ ポリシーで条件要素を使用している場合は、条件がアクセスを制限していることを確認します。

**重要**  
いずれかのポリシー内の明示的な拒否は、明示的な許可に優先します。[Amazon SQS ポリシー](sqs-basic-examples-of-sqs-policies.md)の基本的な例をいくつか示します。

## AWS Key Management Service アクセス許可
<a name="kms-permissions"></a>

Amazon SQS キューで、カスタマー管理の[サーバー側の暗号化 (SSE)](sqs-server-side-encryption.md) が有効になっている場合は AWS KMS key、プロデューサーとコンシューマーの両方にアクセス許可を付与する必要があります。キューが暗号化されているかどうかを確認するには、[`GetQueueAttributes`](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_GetQueueAttributes.html) API の `KmsMasterKeyId` 属性を使用するか、キューコンソールの **[暗号化]** を使用します。
+ [プロデューサーに必要なアクセス許可:](sqs-key-management.md#send-to-encrypted-queue)

  ```
  {
  "Effect": "Allow",
  "Action": [
      "kms:Decrypt",
      "kms:GenerateDataKey"
  ],
  "Resource": "<Key ARN>"
  }
  ```
+ [コンシューマーに必要なアクセス許可:](sqs-key-management.md#receive-from-encrypted-queue)

  ```
  {
  "Effect": "Allow",
  "Action": [
      "kms:Decrypt"
  ],
  "Resource": "<Key ARN>"
  }
  ```
+ [クロスアカウントアクセスに必要なアクセス許可](sqs-key-management.md):

  ```
  {
  "Effect": "Allow",
  "Action": [         
      "kms:DescribeKey",
      "kms:Decrypt",
      "kms:ReEncrypt",
      "kms:GenerateDataKey"
  ],
  "Resource": "<Key ARN>"
  }
  ```

次のいずれかのオプションを選択し、Amazon SQS に対して暗号化を有効にします。
+ [SSE-Amazon SQS](sqs-server-side-encryption.md) (Amazon SQS サービスで作成および管理する暗号化キー）
+ [AWS マネージドデフォルトキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) (alias/aws/sqs)
+ [カスタマーマネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)

ただし、 AWSマネージド [KMS キー](sqs-key-management.md)を使用している場合、デフォルトのキーポリシーを変更することはできません。したがって、他のサービスやクロスアカウントへのアクセスを提供するには、カスタマーマネージドキーを使用します。これにより、キーポリシーを編集できます。

## VPC エンドポイントポリシー
<a name="vpc-endpoint-policy"></a>

[Amazon Virtual Private Cloud (Amazon VPC) エンドポイントを介して Amazon SQS](sqs-internetwork-traffic-privacy.md#sqs-vpc-endpoints) にアクセスする場合、Amazon SQS の VPC エンドポイントポリシーでアクセスを許可する必要があります。Amazon SQS 用の Amazon VPC エンドポイントのポリシーを作成して、以下を指定できます。

1. アクションを実行できるプリンシパル。

1. 実行可能なアクション。

1. アクションを実行できるリソース。

次の例で、VPC エンドポイントポリシーは、Amazon SQS キュー {{MyQueue}} にメッセージを送信することを IAM ユーザー {{MyUser}} に許可するよう指定しています。その他のアクション、IAM ユーザー、Amazon SQS リソースは、VPC エンドポイント経由のアクセスが拒否されます。

```
{
   "Statement": [{
      "Action": ["sqs:SendMessage"],
      "Effect": "Allow",
      "Resource": "arn:aws:sqs:us-east-2:123456789012:{{MyQueue}}",
      "Principal": {
        "AWS": "arn:aws:iam:123456789012:user/{{MyUser}}"
      }
   }]
}
```

## 組織のサービスコントロールポリシー
<a name="organization-control-policy"></a>

が組織に AWS アカウント 属している場合、 AWS Organizations ポリシーによって Amazon SQS キューへのアクセスがブロックされる可能性があります。デフォルトでは、 AWS Organizations ポリシーは Amazon SQS へのリクエストをブロックしません。ただし、 AWS Organizations ポリシーが Amazon SQS キューへのアクセスをブロックするように設定されていないことを確認してください。 AWS Organizations ポリシーを確認する方法については、「 *AWS Organizations ユーザーガイド*[」の「すべてのポリシーの一覧表示](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_info-operations.html#list-all-pols-in-org)」を参照してください。