翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon SQSでの Identity and Access Management
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。IAM 管理者は、誰を*認証* (サインインを許可) し、誰に Amazon SQS リソースの使用を*承認する* (アクセス許可を付与する) かを制御します。IAM は、追加料金なしで AWS のサービス 使用できる です。
## オーディエンス
AWS Identity and Access Management (IAM) の使用方法は、ロールによって異なります。
+ **サービスユーザー** - 機能にアクセスできない場合は、管理者にアクセス許可をリクエストします (「[Amazon Simple Queue Service アイデンティティとアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照)。
+ **サービス管理者** - ユーザーアクセスを決定し、アクセス許可リクエストを送信します (「[Amazon Simple Queue Service で IAM を使用する方法](security_iam_service-with-iam.md)」を参照)
+ **IAM 管理者** - アクセスを管理するためのポリシーを作成します (「[ポリシーに関するベストプラクティス](sqs-basic-examples-of-iam-policies.md#security_iam_id-based-policy-examples)」を参照)
## アイデンティティを使用した認証
認証とは、ID 認証情報 AWS を使用して にサインインする方法です。、IAM ユーザー AWS アカウントのルートユーザー、または IAM ロールを引き受けることで認証される必要があります。
( AWS IAM アイデンティティセンター IAM Identity Center)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーティッド ID としてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。
プログラムによるアクセスの場合、 は SDK と CLI AWS を提供してリクエストを暗号化して署名します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対するAWS 署名バージョン 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。
### AWS アカウント ルートユーザー
を作成するときは AWS アカウント、まず、すべての AWS のサービス および リソースへの完全なアクセス権を持つ AWS アカウント *root ユーザー*と呼ばれる 1 つのサインインアイデンティティから始めます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### フェデレーテッドアイデンティティ
ベストプラクティスとして、人間のユーザーが一時的な認証情報 AWS のサービス を使用して にアクセスするには、ID プロバイダーとのフェデレーションを使用する必要があります。
*フェデレーティッド ID* は、エンタープライズディレクトリ、ウェブ ID プロバイダー、または ID Directory Service ソースの認証情報 AWS のサービス を使用して にアクセスするユーザーです。フェデレーテッドアイデンティティは、一時的な認証情報を提供するロールを引き受けます。
アクセスを一元管理する場合は、 AWS IAM アイデンティティセンターをお勧めします。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[IAM アイデンティティセンターとは](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。
### IAM ユーザーとグループ
*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、特定の個人やアプリケーションに対する特定のアクセス許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細については、*IAM ユーザーガイド*の[「ID プロバイダーとのフェデレーションを使用して にアクセスする必要がある AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーの集合を指定し、大量のユーザーに対するアクセス許可の管理を容易にします。詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーに関するユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)」を参照してください。
### IAM ロール
*[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定のアクセス許可を持つアイデンティであり、一時的な認証情報を提供します。ユーザー[から IAM ロール (コンソール) に切り替えるか、 または API オペレーションを呼び出すことで、ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)を引き受けることができます。 AWS CLI AWS 詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。
IAM ロールは、フェデレーションユーザーアクセス、一時的な IAM ユーザーのアクセス許可、クロスアカウントアクセス、クロスサービスアクセス、および Amazon EC2 で実行するアプリケーションに役立ちます。詳細については、*IAM ユーザーガイド* の [IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
## ポリシーを使用したアクセスの管理
でアクセスを制御する AWS には、ポリシーを作成し、ID AWS またはリソースにアタッチします。ポリシーは、アイデンティティまたはリソースに関連付けられたときにアクセス許可を定義します。 は、プリンシパルがリクエストを行うときにこれらのポリシー AWS を評価します。ほとんどのポリシーは JSON ドキュメント AWS として に保存されます。JSON ポリシードキュメントの詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。
管理者は、ポリシーを使用して、どの**プリンシパル**がどの**リソース**に対して、どのような**条件**で**アクション**を実行できるかを定義することで、誰が何にアクセスできるかを指定します。
デフォルトでは、ユーザーやロールにアクセス許可はありません。IAM 管理者は IAM ポリシーを作成してロールに追加し、このロールをユーザーが引き受けられるようにします。IAM ポリシーは、オペレーションの実行方法を問わず、アクセス許可を定義します。
### アイデンティティベースのポリシー
アイデンティティベースのポリシーは、アイデンティティ (ユーザー、グループ、またはロール) にアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、アイデンティティがどのリソースに対してどのような条件下でどのようなアクションを実行できるかを制御します。アイデンティティベースポリシーの作成方法については、*IAM ユーザーガイド* の [カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) を参照してください。
アイデンティティベースのポリシーは、*インラインポリシー* (単一の ID に直接埋め込む) または*管理ポリシー* (複数の ID にアタッチされたスタンドアロンポリシー) にすることができます。管理ポリシーとインラインポリシーのいずれかを選択する方法については、「*IAM ユーザーガイド*」の「[管理ポリシーとインラインポリシーのいずれかを選択する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)」を参照してください。
### リソースベースのポリシー
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。例としては、IAM *ロール信頼ポリシー*や Amazon S3 *バケットポリシー*などがあります。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。リソースベースのポリシーでは、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。
リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーでは、IAM の AWS マネージドポリシーを使用できません。
### その他のポリシータイプ
AWS は、より一般的なポリシータイプによって付与されるアクセス許可の最大数を設定できる追加のポリシータイプをサポートしています。
+ **アクセス許可の境界** – アイデンティティベースのポリシーで IAM エンティティに付与することのできるアクセス許可の数の上限を設定します。詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **サービスコントロールポリシー (SCP)** - AWS Organizations内の組織または組織単位の最大のアクセス許可を指定します。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
+ **リソースコントロールポリシー (RCP)** – は、アカウント内のリソースで利用できる最大数のアクセス許可を定義します。詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)」を参照してください。
+ **セッションポリシー** – ロールまたはフェデレーションユーザーの一時セッションを作成する際にパラメータとして渡される高度なポリシーです。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。
### 複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。が複数のポリシータイプが関与する場合にリクエストを許可するかどうか AWS を決定する方法については、*「IAM ユーザーガイド*」の[「ポリシー評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)」を参照してください。
# Amazon SQS でのアクセス管理の概要
すべての AWS リソースは によって所有され AWS アカウント、リソースを作成またはアクセスするアクセス許可はアクセス許可ポリシーによって管理されます。アカウント管理者は、IAMアクセス権限ポリシーをアイデンティティ (ユーザー、グループ、ロール) にアタッチできます。一部のサービス ( Amazon SQS など) では、アクセス権限ポリシーをリソースにアタッチすることもできます。
**注記**
*アカウント管理者* (または管理者ユーザー) は、管理者権限を持つユーザーです。詳細については、「*IAM ユーザーガイド*」の「[IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)」を参照してください。
アクセス権限を付与する場合、アクセス権限を取得するユーザー、取得するアクセス権限の対象となるリソース、およびリソースに対して許可される特定のアクションを指定します。
## Amazon Simpleキューサービス リソースと操作
Amazon SQS では、唯一のリソースは*キュー*です。ポリシーで Amazon リソースネーム (ARN)を使用して、ポリシーを適用するリソースを識別します。次のリソースには、関連付けられた一意のARN があります。
| リソースタイプ | ARN 形式 |
| --- | --- |
| [キュー] | arn:aws:sqs:region:account\$1id:queue\$1name |
キューの ARN 形式の例を以下に示します。
+ AWS アカウント 123456789012 に属する、米国東部 (オハイオ) リージョン`my_queue`の という名前のキューの ARN。
```
arn:aws:sqs:us-east-2:123456789012:my_queue
```
+ Amazon SQSがサポートする異なるリージョンごとの`my_queue`というキューのARN。
```
arn:aws:sqs:*:123456789012:my_queue
```
+ キュー名に対して`*`または`?`をワイルドカードとして使用する ARN。次の例で、ARN はプレフィックス `my_prefix_` が付いたすべてのキューに一致します。
```
arn:aws:sqs:*:123456789012:my_prefix_*
```
[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_GetQueueAttributes.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_GetQueueAttributes.html) アクションを呼び出して既存のキューの ARN 値を取得できます。`QueueArn` 属性の値は、キューの ARN です。ARNの詳細については、*IAM ユーザーガイド*の「[IAM ARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns)」を参照してください。
Amazon SQSには、キューリソースを操作するための一連の アクションが用意されています。詳細については、「[Amazon SQS (Amazon SQS)、 API のアクセス権限: アクションとリソースのリファレンスについて](sqs-api-permissions-reference.md)」を参照してください。
## リソース所有権についての理解
は、リソースを作成したユーザーに関係なく、アカウントで作成されたリソース AWS アカウント を所有します。具体的には、リソース所有者は、リソースの作成リクエストを認証するプリンシパルエンティティ** (ルートアカウント、ユーザー、または IAM ロール) の AWS アカウント です。次の例は、この仕組みを示しています。
+ のルートアカウントの認証情報を使用して Amazon SQS キュー AWS アカウント を作成する場合、 AWS アカウント はリソースの所有者です (Amazon SQS では、リソースは Amazon SQS キューです）。
+ でユーザーを作成し AWS アカウント 、キューを作成するアクセス許可をユーザーに付与すると、そのユーザーはキューを作成できます。ただし、(ユーザーが属する) AWS アカウント アカウントはキューリソースを所有しています。
+ Amazon SQS キューを作成するアクセス許可 AWS アカウント を持つ で IAM ロールを作成する場合、ロールを引き受けることのできるすべてのユーザーがキューを作成できます。(ロールが属 AWS アカウント する) がキューリソースを所有します。
## リソースへのアクセスの管理
*アクセス許可ポリシー* では、誰が何にアクセスできるかを記述します。以下のセクションで、アクセス権限のポリシーを作成するために使用可能なオプションについて説明します。
**注記**
このセクションでは、Amazon SQSのコンテキストでの IAM の使用について説明します。これは、IAMサービスに関する詳細情報を取得できません。IAM に関する詳細なドキュメントについては、「*IAM ユーザーガイド*」の「[What is IAM?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)」(IAM とは？) を参照してください。IAM ポリシーの構文と説明については、「*IAM ユーザーガイド*」の「[AWS IAM ポリシーリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)」を参照してください。
IAM ID にアタッチされたポリシーは ID ベースのポリシー (IAM ポリシー) と呼ばれ、リソースにアタッチされたポリシーはリソースベースのポリシーと呼ばれます。
### アイデンティティベースのポリシー
ユーザーにAmazon SQSキューのアクセス権限を付与する方法は、 ポリシーシステムを使用する方法とIAMポリシーシステムを使用する方法の 2 つです。いずれかのシステムまたは両方を使用して、ユーザーまたはロールにポリシーをアタッチできます。ほとんどの場合、どちらのシステムを使用しても同じ結果が得られます。例えば、次の操作を実行できます:
+ アカウントのユーザーまたはグループに**許可ポリシーをアタッチする**–Amazon SQS キューを作成する許可を付与するために、ユーザーまたはユーザーが所属するグループに許可ポリシーをアタッチできます。
+ **別の のユーザーに許可ポリシーを AWS アカウント**アタッチする – 別の のユーザーに許可ポリシーをアタッチ AWS アカウント して、ユーザーが Amazon SQS キューとやり取りできるようにします。ただし、クロスアカウントアクセス許可は、次のアクションには適用されません。
クロスアカウント権限は、次のアクションには適用されません。
+ `[AddPermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html)`
+ `[CancelMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CancelMessageMoveTask.html)`
+ `[CreateQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CreateQueue.html)`
+ `[DeleteQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteQueue.html)`
+ `[ListMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html)`
+ `[ListQueues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueues.html)`
+ `[ListQueueTags](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html)`
+ `[RemovePermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_RemovePermission.html)`
+ `[SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)`
+ `[StartMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_StartMessageMoveTask.html)`
+ `[TagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_TagQueue.html)`
+ `[UntagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_UntagQueue.html)`
これらのアクションに対してアクセスを付与するには、ユーザーが Amazon SQS キューを所有するのと同じ AWS アカウント に属している必要があります。
+ **アクセス許可ポリシーをロールにアタッチする (クロスアカウントアクセス許可を付与する)** – SQS キューにクロスアカウントアクセス許可を付与するには、IAM ポリシーとリソースベースのポリシーの両方を組み合わせる必要があります。
1. **アカウント A** (キューを所有) で、
+ **リソースベースのポリシー**を SQS キューにアタッチします。このポリシーは、**アカウント B** (IAM ロールなど) のプリンシパルに必要なアクセス許可 ([https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)、[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) など) を明示的に付与する必要があります。
1. **アカウント A** で IAM ロールを作成します。
+ **アカウント B** または AWS のサービス がロールを引き受けるのを許可する**信頼ポリシー**。
**注記**
(Lambda や EventBridge AWS のサービス など) がロールを引き受けるようにする場合は、信頼ポリシーでサービスプリンシパル ( などlambda.amazonaws.com) を指定します。
+ キューとやり取りするアクセス許可を引き受けたロールに付与する**アイデンティティベースのポリシー**。
1. **アカウント B** で、**アカウント A** でのロールを引き受けるアクセス許可を付与します。
クロスアカウントプリンシパルを許可するようにキューのアクセスポリシーを設定する必要があります。IAM のアイデンティティベースのポリシーだけでは、SQS キューへのクロスアカウントアクセスには不十分です。
IAM を使用した許可の委任の詳細については、「IAM ユーザーガイド」の「[アクセス管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html)」を参照してください。
Amazon SQS はIAMポリシーを使用して作業する一方で、独自のポリシーインフラストラクチャがあります。キューで Amazon SQS ポリシーを使用して、キューにアクセスできる AWS アカウントを指定できます。アクセスタイプと条件を指定できます (たとえば、リクエストが 2010年12月31日より前の場合は`SendMessage`、`ReceiveMessage`を使用するアクセス権限を付与する条件)。アクセス許可を付与できる特定のアクションは、Amazon SQS アクションリスト全体のサブセットです。Amazon SQS ポリシーを記述して、`*`「すべての アクションを許可」を意味するを指定した場合、ユーザーがこのサブセット内のすべてのアクション実行できることを意味します。
次の図は、これらのベーシックなAmazon SQS ポリシーのうち1つの概念を表しており、アクションのサブセットを取り上げています。ポリシーは 用であり`queue_xyz`、 AWS アカウント 1 と AWS アカウント 2 に、指定されたキューで許可されたアクションのいずれかを使用するアクセス許可を付与します。
**注記**
ポリシーのリソースは として指定されます。ここで`123456789012/queue_xyz`、 `123456789012` はキューを所有するアカウントのアカウント AWS ID です。
![\[アクションのサブセットをカバーする Amazon SQS ポリシー\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/SQS_BasicPolicy.png)
IAMと、*ユーザー*および* Amazon リソースネーム（ARN)*の概念の導入により、SQSポリシーに関するいくつかの点が変わりました。次の図と表は、その変更を示しています。
![\[Amazon SQS ポリシーに追加された IAM および Amazon リソースネーム。\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/SQS_PolicyWithNewFeatures.png)
![\[Number one in the diagram.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-1-red.png) 異なるアカウントのユーザーにアクセス許可を付与する方法については、IAM *ユーザーガイド*の[「チュートリアル: IAM ロールを使用した AWS アカウント間のアクセスの委任](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)」を参照してください。
![\[Number two in the diagram.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-2-red.png) `*`に含まれるアクションのサブセットが拡大されました。可能なアクションの一覧については、[Amazon SQS (Amazon SQS)、 API のアクセス権限: アクションとリソースのリファレンスについて](sqs-api-permissions-reference.md)を参照してください。
![\[Number three in the diagram.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-3-red.png)Amazon リソースネーム (ARN)を使用してリソースを指定できます。これは、IAMポリシーでリソースを指定するためのスタンダードな方法です。Amazon SQSキューのARN形式については、「[Amazon Simpleキューサービス リソースと操作](#sqs-resource-and-operations)」を参照してください。
例えば、前の図の Amazon SQS ポリシーによると、 AWS アカウント 1 または AWS アカウント 2 のセキュリティ認証情報を所有するユーザーは誰でも にアクセスできます`queue_xyz`。さらに、自身の AWS アカウント (ID `123456789012`)内のユーザー Bobおよび Susanもキューにアクセスできます。
IAMの導入前は、 Amazon SQSによりキューの作成者に、キューに対する完全なコントロールが付与されていました (そのキューで使用できるすべての Amazon SQ アクションへのアクセス)。これは、作成者が AWS セキュリティ認証情報を使用している場合以外は当てはまらなくなりました。キューを作成するアクセス権限を持つユーザーは、作成されたキューで何らかの操作を実行するには、他のAmazon SQSアクションを使用するアクセス権限も持っている必要があります。
以下に、ユーザーにすべてのAmazon SQSアクションを許可するが、対象を名前にリテラル文字列というプレフィックスがついているキューに限るポリシーの例を示します`bob_queue_`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sqs:*",
"Resource": "arn:aws:sqs:*:123456789012:bob_queue_*"
}]
}
```
------
詳細については、*IAMユーザーガイド*[Amazon SQS でのポリシーの使用](sqs-using-identity-based-policies.md)「[ID (ユーザー、グループ、ロール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)」とのIAM ポリシーの概要」を参照してください。
## ポリシー要素の指定:アクション、効果、リソース、プリンシパル
[Amazon Simple キューサービス リソース](#sqs-resource-and-operations)の種類ごとに、このサービスは、一連の[アクション](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_Operations.html)を定義します。これらの アクションを実行するためのアクセス権限を付与するために、Amazon SQSではポリシーに一連のアクションを定義できます。
**注記**
1つの アクションの実行で、複数のアクションのアクセス権限が必要になる場合があります。特定のアクションのアクセス権限を付与した場合は、アクションを許可または拒否するリソースを識別します。
最も基本的なポリシーの要素を次に示します。
+ **リソース**–ポリシーで Amazon リソースネーム (ARN)を使用して、ポリシーを適用するリソースを識別します。
+ **アクション**–アクションのキーワードを使用して、許可または拒否するリソースアクションを識別します。たとえば、`sqs:CreateQueue`権限は、Amazon Simple キューサービス`CreateQueue`アクション の実行をユーザーに許可します。
+ **効果**–ユーザーが特定のアクションを要求する際の効果を指定します。許可または拒否のいずれかになります。リソースへのアクセスを明示的に許可していない場合、アクセスは暗黙的に拒否されます。また、明示的にリソースへのアクセスを拒否すると、別のポリシーによってアクセスが許可されている場合でも、ユーザーはそのリソースにアクセスできなくなります。
+ **プリンシパル**-アイデンティティベースのポリシー（IAMポリシー）で、ポリシーが添付されているユーザーが黙示的なプリンシパルとなります。リソースベースのポリシーでは、アクセス許可 (リソースベースのポリシーにのみ適用) を受け取りたいユーザー、アカウント、サービス、またはその他のエンティティを指定します。
Amazon SQS ポリシーの構文と記述の詳細については、*IAM ユーザーガイド*の[AWS IAM ポリシーリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)を参照してください。
すべてのAmazon Simpleキューサービスアクションおよびそれに適用されるリソースを示す表については、「[Amazon SQS (Amazon SQS)、 API のアクセス権限: アクションとリソースのリファレンスについて](sqs-api-permissions-reference.md)」を参照してください。
# Amazon Simple Queue Service で IAM を使用する方法
IAM を使用して Amazon SQS へのアクセスを管理する前に、Amazon SQS で利用できる IAM 機能について理解しておく必要があります。
**Amazon Simple Queue Service で使用できる IAM の機能**
| IAM 機能 | Amazon SQS サポート |
| --- | --- |
| [アイデンティティベースのポリシー](#security_iam_service-with-iam-id-based-policies) | あり |
| [リソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies) | はい |
| [ポリシーアクション](#security_iam_service-with-iam-id-based-policies-actions) | あり |
| [ポリシーリソース](#security_iam_service-with-iam-id-based-policies-resources) | はい |
| [ポリシー条件キー (サービス固有)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | はい |
| [ACL](#security_iam_service-with-iam-acls) | なし |
| [ABAC (ポリシー内のタグ)](#security_iam_service-with-iam-tags) | 部分的 |
| [一時認証情報](#security_iam_service-with-iam-roles-tempcreds) | あり |
| [転送アクセスセッション (FAS)](#security_iam_service-with-iam-principal-permissions) | あり |
| [サービスロール](#security_iam_service-with-iam-roles-service) | あり |
| [サービスリンクロール](#security_iam_service-with-iam-roles-service-linked) | いいえ |
Amazon SQS およびその他の AWS のサービスがほとんどの IAM 機能と連携する方法の概要については、IAM *ユーザーガイド*の[AWS 「IAM と連携する のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## アクセスコントロール
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
Amazon S3、および Amazon VPC は AWS WAF、ACLs。ACL の詳細については、*Amazon Simple Storage Service デベロッパーガイド* の [アクセスコントロールリスト (ACL) の概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) を参照してください。
**注記**
すべての が自分のアカウントのユーザーに権限を委任 AWS アカウント できることを理解することが重要です。クロスアカウントアクセスを使用すると、追加のユーザーを管理することなく、 AWS リソースへのアクセスを共有できます。クロスアカウントのアクセスの詳細については、*IAM ユーザーガイド*の「[クロスアカウントアクセスの有効化](https://docs.aws.amazon.com/IAM/latest/UserGuide/Delegation.html)」を参照してください。
Amazon SQS カスタムポリシー内のコンテンツ間のアクセス許可と条件キーの詳細については、「[Amazon SQS カスタムポリシーの制限](sqs-limitations-of-custom-policies.md)」を参照してください。
## Amazon SQS のアイデンティティベースのポリシー
**ID ベースのポリシーのサポート:** あり
アイデンティティベースポリシーは、IAM ユーザー、ユーザーグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースポリシーの作成方法については、「*IAM ユーザーガイド*」の「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
IAM アイデンティティベースのポリシーでは、許可または拒否するアクションとリソース、およびアクションを許可または拒否する条件を指定できます。JSON ポリシーで使用できるすべての要素について学ぶには、「*IAM ユーザーガイド*」の「[IAM JSON ポリシーの要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。
### Amazon SQS のアイデンティティベースのポリシー例
Amazon SQS のアイデンティティベースのポリシー例を確認するには、「[ポリシーに関するベストプラクティス](sqs-basic-examples-of-iam-policies.md#security_iam_id-based-policy-examples)」を参照してください。
## Amazon SQS 内のリソースベースのポリシー
**リソースベースのポリシーのサポート:** あり
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または を含めることができます AWS のサービス。
クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。詳細については、IAM ユーザーガイド**の[IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)を参照してください。
## Amazon SQS のポリシーアクション
**ポリシーアクションのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
Amazon SQS アクションの一覧については、「*サービス認可リファレンス*」の「[Amazon Simple Queue Service で定義されるリソース](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html#amazonsqs-resources-for-iam-policies)」を参照してください。
Amazon SQS のポリシーアクションは、アクションの前に次のプレフィックスを使用します。
```
sqs
```
単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。
```
"Action": [
"sqs:action1",
"sqs:action2"
]
```
Amazon SQS のアイデンティティベースのポリシー例を確認するには、「[ポリシーに関するベストプラクティス](sqs-basic-examples-of-iam-policies.md#security_iam_id-based-policy-examples)」を参照してください。
## Amazon SQS のポリシーリソース
**ポリシーリソースのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
Amazon SQS のリソースタイプとその ARN の一覧については、「*サービス認可リファレンス*」の「[Amazon Simple Queue Service で定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html#amazonsqs-actions-as-permissions)」を参照してください。どのアクションで各リソースの ARN を指定できるかについては、「[Amazon Simple Queue Service で定義されるリソース](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html#amazonsqs-resources-for-iam-policies)」を参照してください。
Amazon SQS のアイデンティティベースのポリシー例を確認するには、「[ポリシーに関するベストプラクティス](sqs-basic-examples-of-iam-policies.md#security_iam_id-based-policy-examples)」を参照してください。
## Amazon SQS のポリシー条件キー
**サービス固有のポリシー条件キーのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
`Condition` 要素は、定義された基準に基づいてステートメントが実行される時期を指定します。イコールや未満などの[条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。すべての AWS グローバル条件キーを確認するには、*「IAM ユーザーガイド*」の[AWS 「グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
Amazon SQS の条件キーの一覧については、「*サービス認可リファレンス*」の「[Amazon Simple Queue Service の条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html#amazonsqs-policy-keys)」を参照してください。条件キーを使用できるアクションとリソースについては、「[Amazon Simple Queue Service で定義されるリソース](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html#amazonsqs-resources-for-iam-policies)」を参照してください。
Amazon SQS のアイデンティティベースのポリシー例を確認するには、「[ポリシーに関するベストプラクティス](sqs-basic-examples-of-iam-policies.md#security_iam_id-based-policy-examples)」を参照してください。
## Amazon SQS での ACL
**ACL のサポート:** なし
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
## Amazon SQS での ABAC
**ABAC (ポリシー内のタグ) のサポート:** 一部
属性ベースのアクセスコントロール (ABAC) は、タグと呼ばれる属性に基づいてアクセス許可を定義する認可戦略です。IAM エンティティと AWS リソースにタグをアタッチし、プリンシパルのタグがリソースのタグと一致するときにオペレーションを許可するように ABAC ポリシーを設計できます。
タグに基づいてアクセスを管理するには、`aws:ResourceTag/key-name`、`aws:RequestTag/key-name`、または `aws:TagKeys` の条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。
サービスがすべてのリソースタイプに対して 3 つの条件キーすべてをサポートする場合、そのサービスの値は**あり**です。サービスが一部のリソースタイプに対してのみ 3 つの条件キーのすべてをサポートする場合、値は「**部分的**」になります。
ABAC の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可でアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。ABAC をセットアップする手順を説明するチュートリアルについては、「*IAM ユーザーガイド*」の「[属性ベースのアクセスコントロール (ABAC) を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)」を参照してください。
## Amazon SQS での一時的な認証情報の使用
**一時的な認証情報のサポート:** あり
一時的な認証情報は AWS 、リソースへの短期的なアクセスを提供し、フェデレーションまたはスイッチロールの使用時に自動的に作成されます。長期的なアクセスキーを使用する代わりに、一時的な認証情報を動的に生成 AWS することをお勧めします。詳細については、「*IAM ユーザーガイド*」の「[IAM の一時的な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)」および「[AWS のサービス と IAM との連携](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## Amazon SQS の転送アクセスセッション
**転送アクセスセッション (FAS) のサポート:** あり
転送アクセスセッション (FAS) は、 を呼び出すプリンシパルのアクセス許可と AWS のサービス、ダウンストリームサービス AWS のサービス へのリクエストをリクエストする を使用します。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
## Amazon SQS のサービスロール
**サービスロールのサポート:** あり
サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、IAM ユーザーガイド**の [AWS のサービスに許可を委任するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)を参照してください。
**警告**
サービスロールの許可を変更すると、Amazon SQS の機能が破損する可能性があります。Amazon SQS が指示するときにのみ、サービスロールを編集してください。
## Amazon SQS のサービスリンクロール
**サービスにリンクされたロールのサポート:** なし
サービスにリンクされたロールは、 にリンクされたサービスロールの一種です AWS のサービス。サービスは、ユーザーに代わってアクションを実行するロールを引き受けることができます。サービスにリンクされたロールは に表示され AWS アカウント 、サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールのアクセス許可を表示できますが、編集することはできません。
サービスにリンクされたロールの作成または管理の詳細については、「[IAM と提携するAWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。表の「**サービスリンクロール**」列に `Yes` と記載されたサービスを見つけます。サービスにリンクされたロールに関するドキュメントをサービスで表示するには、**[はい]** リンクを選択します。
# AWS マネージドポリシーに対する Amazon SQS の更新
ユーザー、グループ、ロールにアクセス許可を追加するには自分でポリシーを作成するよりも、 AWS マネージドポリシーを使用する方が簡単です。チームに必要な権限のみを提供する [IAM カスタマーマネージドポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)には時間と専門知識が必要です。すぐに使用を開始するために、 AWS マネージドポリシーを使用できます。これらのポリシーは一般的なユースケースを対象範囲に含めており、 AWS アカウントで利用できます。 AWS 管理ポリシーの詳細については、*IAM ユーザーガイド*の「 [AWS 管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
AWS サービスは、 AWS 管理ポリシーを維持および更新します。 AWS 管理ポリシーのアクセス許可は変更できません。サービスは、新機能をサポートするために、 AWS 管理ポリシーに追加のアクセス許可を追加することがあります。この種類の更新はポリシーがアタッチされている、すべてのアイデンティティ (ユーザー、グループおよびロール) に影響を与えます。サービスは、新機能が起動されたとき、または新しいオペレーションが利用可能になったときに、 AWS マネージドポリシーを更新する可能性が最も高いです。サービスは AWS 管理ポリシーからアクセス許可を削除しないため、ポリシーの更新によって既存のアクセス許可が損なわれることはありません。
さらに、 は、複数のサービスにまたがるジョブ関数の マネージドポリシー AWS をサポートしています。例えば、**ReadOnlyAccess** AWS マネージドポリシーではすべての AWS のサービスおよびリソースへの読み取り専用アクセスを許可します。サービスが新機能を起動すると、 は新しいオペレーションとリソースの読み取り専用アクセス許可 AWS を追加します。ジョブ機能のポリシーの一覧および詳細については、「*IAM ユーザーガイド*」の「[AWS のジョブ機能のマネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)」を参照してください。
## AWS マネージドポリシー: AmazonSQSFullAccess
`AmazonSQSFullAccess` ポリシーは Amazon SQS ID に添付できます。このポリシーは、Amazon SQS への完全なアクセスを可能にする許可を付与します。
このポリシーのアクセス許可を確認するには、「AWS マネージドポリシーリファレンス**」の「[AmazonSESReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSQSFullAccess.html)」を参照してください。
## AWS マネージドポリシー: AmazonSQSReadOnlyAccess
`AmazonSQSReadOnlyAccess` ポリシーは Amazon SQS ID にアタッチできます。このポリシーは、Amazon SQS への読み取り専用アクセスを可能にする許可を付与します。
このポリシーのアクセス許可を確認するには、「AWS マネージドポリシーリファレンス**」の「[AmazonSQSReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSQSReadOnlyAccess.html)」を参照してください。
## AWS マネージドポリシー: SQSUnlockQueuePolicy
Amazon SQS キューへのすべてのユーザーのアクセスを拒否するようにメンバーアカウントのキューポリシーを誤って設定した場合は、 `SQSUnlockQueuePolicy` AWS 管理ポリシーを使用してキューのロックを解除できます。
すべてのプリンシパルが Amazon SQS キューにアクセスすることを拒否する誤って設定されたキューポリシーを削除する方法の詳細については、*IAM* [ユーザーガイドの AWS Organizations 「メンバーアカウントで特権タスクを実行する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user-privileged-task.html)」を参照してください。
## AWS マネージドポリシーに対する Amazon SQS の更新
このサービスがこれらの変更の追跡を開始してからの Amazon SQS の AWS マネージドポリシーの更新に関する詳細を表示します。このページへの変更に関する自動アラートを受け取るには、Amazon SQS の[ドキュメント履歴](sqs-release-notes.md)ページで RSS フィードにサブスクライブしてください。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| [SQSUnlockQueuePolicy](https://docs.aws.amazon.com/IAM/latest/UserGuide/security-iam-awsmanpol.html#security-iam-awsmanpol-SQSUnlockQueuePolicy) | Amazon SQS は、 という新しい AWS管理ポリシーを追加してキューを`SQSUnlockQueuePolicy`ロック解除し、すべてのプリンシパルが Amazon SQS キューにアクセスすることを拒否する誤って設定されたキューポリシーを削除しました。 | 2024 年 11 月 15 日 |
| [AmazonSQSReadOnlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonSQSReadOnlyAccess) | Amazon SQS は、指定した Amazon SQS キューに関連付けられたすべてのタグを取得する [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html) アクションを追加しました。これにより、組織またはメタデータの目的でキューに割り当てられたキーと値のペアを表示できます。このアクションは `ListQueueTags` API 演算に関連付けられています。 | 2024 年 6 月 20 日 |
| [AmazonSQSReadOnlyAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AmazonSQSReadOnlyAccess) | Amazon SQS には、特定のソースキューにある最新のメッセージ移動タスク (最大 10 個) を一覧表示できる新しいアクションが追加されました。このアクションは [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html) API 演算に関連付けられています。 | 2023 年 6 月 9 日 |
# Amazon Simple Queue Service アイデンティティとアクセスのトラブルシューティング
Amazon SQS と IAM の使用に伴って発生する可能性がある一般的な問題の診断や修復には、次の情報を利用してください。
## Amazon SQS でアクションを実行する認可がありません
アクションを実行する権限がないというエラーが表示された場合は、そのアクションを実行できるようにポリシーを更新する必要があります。
以下のエラー例は、`mateojackson` ユーザーがコンソールを使用して架空の `my-example-widget` リソースに関する詳細情報を表示しようとしているが、架空の `sqs:GetWidget` 許可がないという場合に発生します。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: sqs:GetWidget on resource: my-example-widget
```
この場合、Mateo のポリシーでは、`my-example-widget` アクションを使用して `sqs:GetWidget` リソースへのアクセスを許可するように更新する必要があります。
サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン認証情報を提供した担当者が管理者です。
## iam:PassRole を実行する権限がありません
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して Amazon SQS にロールを渡せるようにする必要があります。
一部の AWS のサービス では、新しいサービスロールまたはサービスにリンクされたロールを作成する代わりに、既存のロールをそのサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
次の例のエラーは、`marymajor` という IAM ユーザーがコンソールを使用して Amazon SQS でアクションを実行しようとする場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与されたアクセス許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。
サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン資格情報を提供した担当者が管理者です。
## 自分の 以外のユーザーに Amazon SQS リソース AWS アカウント へのアクセスを許可したい
他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください:
+ Amazon SQS がこれらの機能をサポートしているかどうかを確認するには、「[Amazon Simple Queue Service で IAM を使用する方法](security_iam_service-with-iam.md)」を参照してください。
+ 所有 AWS アカウント している のリソースへのアクセスを提供する方法については、[「IAM ユーザーガイド」の「所有 AWS アカウント している別の の IAM ユーザーへのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)」を参照してください。 **
+ リソースへのアクセスをサードパーティーに提供する方法については AWS アカウント、*IAM ユーザーガイド*の[「サードパーティー AWS アカウント が所有する へのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。
+ ID フェデレーションを介してアクセスを提供する方法については、*IAM ユーザーガイド* の [外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) を参照してください。
+ クロスアカウントアクセスにおけるロールとリソースベースのポリシーの使用方法の違いについては、*IAM ユーザーガイド* の [IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
## キューのロックを解除したい
が組織に 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.html)」を参照してください。
さらに、Amazon SQS キューへのすべてのユーザーのアクセスを拒否するようにメンバーアカウントのキューポリシーを誤って設定した場合、IAM でメンバーアカウントの特権セッションを立ち上げることでキューをロック解除できます。特権セッションを立ち上げると、誤って設定したキューポリシーを削除して、キューへのアクセスを再開できます。詳細については、*IAM* [ユーザーガイドの AWS Organizations 「メンバーアカウントで特権タスクを実行する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user-privileged-task.html)」を参照してください。
# Amazon SQS でのポリシーの使用
このトピックでは、アカウント管理者がIAMアイデンティティ (ユーザー、グループ、ロール) へのアクセス権限ポリシーをアタッチする、アイデンティティベースのポリシーの例を示します。
**重要**
初めに Amazon Simpleキューサ－ビスリソースへのアクセスを管理するための基本概念と使用できるオプションについて説明する概要トピックをご覧になることをお勧めします。詳細については、「[Amazon SQS でのアクセス管理の概要](sqs-overview-of-managing-access.md)」を参照してください。
ただし、`ListQueues`では、すべての Amazon SQSアクションがリソース-レベルのアクセス許可をサポートします。詳細については、「[Amazon SQS (Amazon SQS)、 API のアクセス権限: アクションとリソースのリファレンスについて](sqs-api-permissions-reference.md)」を参照してください。
## Amazon SQS ポリシーとIAMポリシーの使用
Amazon SQS リソースへのアクセス許可をユーザーに付与するには、Amazon SQS ポリシーシステム (リソースベースのポリシー) を使用する方法と IAMポリシーシステム (アイデンティティベースのポリシー) を使用する方法の 2 つがあります。１ つまたは両方の方法を使用できます。ただし、`ListQueues` アクションについては、IAM ポリシーでのみ設定できるリージョンアクセス許可であるため、これを除きます。
例えば、以下の図は、IAMポリシーとそれに相当する Amazon SQS ポリシーを示しています。IAM ポリシーは、 AWS アカウント`queue_xyz`で呼び出されたキューの Amazon SQS `ReceiveMessage`および `SendMessage` アクションに対する権限を付与し、ポリシーは Bob と Susan という名前のユーザーにアタッチされます (Bob と Susan にはポリシーに記載されているアクセス許可があります）。この Amazon SQS ポリシーは、Bob と Susan に、同じキューの `ReceiveMessage` と `SendMessage` アクションへの権限も付与します。
**注記**
この例は、条件のないシンプルなポリシーを示しています。どちらのポリシーでも特定の条件を指定して、同じ結果を得ることができます。
![\[IAM ポリシーおよび同等の Amazon SQS ポリシーを比較する図。IAM ポリシーは、 AWS アカウントqueue_xyzで呼び出されたキューの Amazon SQS ReceiveMessageおよび SendMessage アクションに対する権限を付与し、ポリシーは Bob と Susan という名前のユーザーにアタッチされます (Bob と Susan にはポリシーに記載されているアクセス許可があります）。この Amazon SQS ポリシーは、Bob と Susan に、同じキューの ReceiveMessage と SendMessage アクションへの権限も付与します。\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-iam-policies-equivalent.png)
IAM ポリシーと Amazon SQS ポリシーには大きな違いが 1 つあります。Amazon SQS ポリシーシステムでは、他の AWS アカウントにアクセス許可を付与できますが、IAM では付与されません。
両方のシステムを同時に使用してどのようにアクセス許可を管理するかは、ご自身で決めてください。以下の例では、2つのポリシーシステムがどのように連携するかを示しています。
+ 最初の例では、BobのアカウントにIAMポリシーとAmazon SQS ポリシーの両方が適用されています。`ReceiveMessage`IAMポリシーは、Amazon SQSでの`queue_xyz`アクションについて、Bob のアカウントにアクセス許可を付与しAmazon SQS 、 ポリシーは、同じキューの`SendMessage`アクションのアクセス許可をBobのアカウントに付与します。以下の図に、そのコンセプトを示します。
![\[IAM ポリシーと Amazon SQS ポリシーのコンポーネントを比較する図。最初の例では、BobのアカウントにIAMポリシーとAmazon SQS ポリシーの両方が適用されています。ReceiveMessageIAMポリシーは、Amazon SQSでのqueue_xyzアクションについて、Bob のアカウントにアクセス許可を付与しAmazon SQS 、 ポリシーは、同じキューのSendMessageアクションのアクセス許可をBobのアカウントに付与します。\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-iam-policies-union.png)
Bob が`ReceiveMessage`リクエストを`queue_xyz`に送信すると、IAMポリシーでそのアクションが許可されます。Bobが`SendMessage`リクエストを`queue_xyz` に送信すると Amazon SQSポリシーでそのアクションが許可されます。
+ 2 番目の例では、Bob が`queue_xyz`に対するアクセス許可を不正に使用したため、このキューへのBobのアクセス許可をすべて削除する必要があります。最も簡単な方法は、そのキューに対するBobのアクションをすべて拒否するようなポリシーを追加することです。明示的な `deny`は常に`allow`をオーバーライドするため、このポリシーは他の 2 つのポリシーをオーバーライドします。ポリシーの評価ロジックの詳細については、「[Amazon SQSアクセスポリシー言語を使用したカスタムポリシーの使用](sqs-creating-custom-policies.md)」を参照してください。以下の図に、そのコンセプトを示します。
![\[Amazon SQS ポリシーによる IAM ポリシーのオーバーライドを示す図。Bob は queue_xyz へのアクセスを不正に使用しているため、Bob によるキューへのアクセス全体を削除する必要があります。最も簡単な方法は、そのキューに対するBobのアクションをすべて拒否するようなポリシーを追加することです。明示的な denyは常にallowをオーバーライドするため、このポリシーは他の 2 つのポリシーをオーバーライドします。\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-iam-policies-deny-override.png)
また、そのキューに対する Bob からのアクセスをすべて拒否するようなステートメントを Amazon SQSポリシーに追加することもできます。これは、そのキューに対する Bobのアクセスを拒否するIAMポリシーを追加するのと同じ効果を持ちます。Amazon SQSアクションおよびリソースに対応するポリシーの例については、「[ベーシックAmazon SQSポリシーの例](sqs-basic-examples-of-sqs-policies.md)」を参照してください。AmazonSQS記載 ポリシーの詳細については、「[Amazon SQSアクセスポリシー言語を使用したカスタムポリシーの使用](sqs-creating-custom-policies.md)」を参照してください。
## Amazon SQSコンソールの使用に必要なアクセス許可
Amazon SQSコンソールを使用して作業するユーザーには、ユーザーの AWS アカウントアカウントのAmazon SQSキューを使用するための最小限のアクセス権限が必要です。たとえば、ユーザーにはキューをリスト表示するための `ListQueues` アクションを呼び出すアクセス権限、またはキューを作成するための `CreateQueue` アクションを呼び出すアクセス権限が必要です。Amazon SQSキューを Amazon SNSトピックに登録する Amazon SQS アクセス権限に加えて、コンソールには Amazon SNSアクション用のアクセス権限が必要です。
これらの最小限必要なアクセス権限よりも制限された IAMポリシーを作成している場合、そのIAMポリシーを使用するユーザーに対してコンソールは意図したとおりには機能しない場合があります。
AWS CLI または Amazon SQS アクションのみを呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。
# Amazon SQS のアイデンティティベースのポリシー例
デフォルトでは、ユーザーとロールには Amazon SQS リソースを作成または変更するアクセス許可がありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。
これらのサンプルの JSON ポリシードキュメントを使用して IAM アイデンティティベースのポリシーを作成する方法については、「*IAM ユーザーガイド*」の「[IAM ポリシーを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)」を参照してください。
Amazon SQS が定義するアクションとリソースタイプ (リソースタイプごとの ARN の形式を含む) の詳細については、「*サービス認可リファレンス*」の「[Amazon Simple Queue Service のアクション、リソース、および条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonsqs.html)」を参照してください。
**注記**
Amazon EC2 Auto Scaling のライフサイクルフックを構成する場合、メッセージをAmazon SQSキューに送信するためのポリシーを作成する必要はありません。詳細については、「*Amazon EC2 ユーザーガイド*」の「[Amazon EC2 Auto Scaling のライフサイクルフック](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)」を参照してください。
## ポリシーに関するベストプラクティス
アイデンティティベースのポリシーは、誰がユーザーのアカウントの Amazon SQS リソースを作成、アクセス、削除できるどうかを決定します。これらのアクションでは、 AWS アカウントに費用が発生する場合があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:
+ ** AWS 管理ポリシーを開始し、最小特権のアクセス許可に移行する** – ユーザーとワークロードにアクセス許可の付与を開始するには、多くの一般的なユースケースにアクセス許可を付与する*AWS 管理ポリシー*を使用します。これらは で使用できます AWS アカウント。ユースケースに固有の AWS カスタマー管理ポリシーを定義することで、アクセス許可をさらに減らすことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能のAWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。
+ **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。
+ **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。条件を使用して、サービスアクションが などの特定の を通じて使用されている場合に AWS のサービス、サービスアクションへのアクセスを許可することもできます CloudFormation。詳細については、*IAM ユーザーガイド* の [IAM JSON ポリシー要素:条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。
+ **IAM アクセスアナライザー を使用して IAM ポリシーを検証し、安全で機能的な権限を確保する** - IAM アクセスアナライザー は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド* の [IAM Access Analyzer でポリシーを検証する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) を参照してください。
+ **多要素認証 (MFA) を要求する** – で IAM ユーザーまたはルートユーザーを必要とするシナリオがある場合は AWS アカウント、MFA をオンにしてセキュリティを強化します。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド* の [MFA を使用した安全な API アクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) を参照してください。
IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド* の [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) を参照してください。
## Amazon SQS コンソールの使用
Amazon Simple Queue Service コンソールにアクセスするには、最小限のアクセス許可のセットが必要です。これらのアクセス許可により、 内の Amazon SQS リソースの詳細を一覧表示および表示できます AWS アカウント。最小限必要な許可よりも制限が厳しいアイデンティティベースのポリシーを作成すると、そのポリシーを持つエンティティ (ユーザーまたはロール) に対してコンソールが意図したとおりに機能しません。
AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスが許可されます。
ユーザーとロールが引き続き Amazon SQS コンソールを使用できるようにするには、エンティティに Amazon SQS `AmazonSQSReadOnlyAccess` AWS 管理ポリシーもアタッチします。詳細については、「*IAM ユーザーガイド*」の「[ユーザーへのアクセス許可の追加](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)」を参照してください。
## 自分の権限の表示をユーザーに許可する
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI または AWS API を使用してプログラムでこのアクションを実行するアクセス許可が含まれています。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## キューの作成をユーザーに許可する
次の例では、すべてのAmazon SQSアクションへのアクセスを Bobに許可するBob用のポリシーを作成しますが、名前のプレフィックスがリテラル文字列 `alice_queue_` になっているキューしか含まれていません。
Amazon SQSでは、キューの作成者に、そのキューを使用するアクセス権限が自動的に付与されません。したがって、IAM ポリシーの `CreateQueue` アクションに加えて、すべての Amazon SQS アクションを使用するアクセス権限を Bob に明示的に付与する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sqs:*",
"Resource": "arn:aws:sqs:*:123456789012:alice_queue_*"
}]
}
```
------
## 共有キューにメッセージを書き込むことを開発者に許可する
次の例では、デベロッパー用のグループを作成し、グループが Amazon SQS `SendMessage`アクションを使用できるようにするポリシーをアタッチしますが、指定された に属 AWS アカウント し、 という名前のキューでのみ使用します`MyCompanyQueue`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:*:123456789012:MyCompanyQueue"
}]
}
```
------
`*` の代わりに`SendMessage`を使用してアクション `ChangeMessageVisibility`、`DeleteMessage`、`GetQueueAttributes`、`GetQueueUrl`、`ReceiveMessage`、および`SendMessage`を共有キューのプリンシパルに許可できます。
**注記**
`*`には、他のアクセス許可タイプにより提供されるアクセスが含まれています、Amazon SQS はアクセス許可を個別に考慮します。たとえば、`*` により許可されるアクセスが`SendMessage`に含まれている場合でも、`*`と`SendMessage`の両方のアクセス許可をユーザーに付与できます。
このコンセプトは、アクセス許可を削除するときも適用されます。プリンシパルに`*`アクセス許可しかない場合は、`SendMessage`アクセス許可の削除をリクエストしても、プリンシパルは「*everything-but*」アクセス許可を持つことには*なりません*。プリンシパルは明示的な`SendMessage`アクセス許可を持っていないため、リクエストに効果はありません。プリンシパルが`ReceiveMessage`アクセス許可だけを持つようにする場合、まず `ReceiveMessage` アクセス許可を追加してから`*`アクセス許可を削除します。
## キューの一般的なサイズを取得することをマネージャーに許可する
次の例では、マネージャー用のグループを作成し、グループが指定された AWS アカウントに属するすべてのキューで Amazon SQS `GetQueueAttributes`アクションを使用できるようにするポリシーをアタッチします。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sqs:GetQueueAttributes",
"Resource": "*"
}]
}
```
------
## 特定のキューにメッセージを送信することをパートナーに許可する
このタスクは、Amazon SQSポリシーまたはIAMポリシーを使用して完了できます。パートナーに がある場合は AWS アカウント、Amazon SQS ポリシーを使用する方が簡単な場合があります。ただし、 AWS セキュリティ認証情報を所有するパートナーの会社のユーザーは、キューにメッセージを送信できます。特定のユーザーまたはアプリケーションにアクセスを制限する場合は、パートナーを自社内のユーザーと同様に扱い、IAMポリシーではなく Amazon SQSポリシーを使用する必要があります。
この例は以下のアクションを実行します。
1. パートナー企業を表すためにWidgetCoというグループを作成します。
1. アクセスを必要としているパートナー会社の特定のユーザーまたはアプリケーション用のユーザーを作成します。
1. ユーザーを グループに追加します。
1. `SendMessage`というキューのみの`WidgetPartnerQueue`アクションのみへのグループのアクセス権限を付与するポリシーを添付します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:*:123456789012:WidgetPartnerQueue"
}]
}
```
------
# ベーシックAmazon SQSポリシーの例
このセクションでは、一般的なAmazon SQSユースケースのサンプルポリシーを示します。
コンソールを使用して、ユーザーにポリシーをアタッチしながら各ポリシーの効果を検証できます。最初は、ユーザーにアクセス権限が付与されてないため、コンソールを使用して何もできません。ユーザーにポリシーをアタッチすることで、ユーザーがコンソールで多様なアクションを実行できることを確認できます。
**注記**
2 つのブラウザウィンドウを使用することをお勧めします。1 つはアクセス許可を付与し、もう 1 つはユーザーの認証情報 AWS マネジメントコンソール を使用して にサインインし、ユーザーに付与するアクセス許可を検証します。
## 例 1: 1 つのアクセス許可を 1 つに付与する AWS アカウント
次のポリシー例では`111122223333`、米国東部 (オハイオ) リージョン`444455556666/queue1`で という名前のキューの`SendMessage`アクセス許可を AWS アカウント 番号に付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_SendMessage",
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333"
]
},
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:us-east-2:444455556666:queue1"
}]
}
```
------
## 例 2: 1 つの に 2 つのアクセス許可を付与する AWS アカウント
次のポリシー例では、 という名前のキューの `SendMessage`と `111122223333`の両方の`ReceiveMessage`アクセス許可を AWS アカウント 番号に付与します`444455556666/queue1`。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_Send_Receive",
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333"
]
},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:*:444455556666:queue1"
}]
}
```
------
## 例 3: 2 つの にすべてのアクセス許可を付与する AWS アカウント
次のポリシー例では、Amazon SQS が米国東部 (`111122223333`オハイオ`444455556666`) リージョン`123456789012/queue1`で という名前のキューの共有アクセスを許可するすべてのアクションを使用するための 2 つの異なる AWS アカウント 番号 ( と ) のアクセス許可を付与します。 Amazon SQS
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_AllActions",
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333",
"444455556666"
]
},
"Action": "sqs:*",
"Resource": "arn:aws:sqs:us-east-2:123456789012:queue1"
}]
}
```
------
## 例4: ロールおよびユーザー名にクロスアカウントのアクセス許可を付与する
次のポリシー例では`role1`、Amazon SQS が米国東部 (オハイオ) リージョン`123456789012/queue1`で という名前のキューの共有アクセスを許可するすべてのアクションを使用するための`111122223333`クロスアカウントアクセス許可を および `username1` AWS アカウント に付与します。
クロスアカウント権限は、次のアクションには適用されません。
+ `[AddPermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html)`
+ `[CancelMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CancelMessageMoveTask.html)`
+ `[CreateQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CreateQueue.html)`
+ `[DeleteQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteQueue.html)`
+ `[ListMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html)`
+ `[ListQueues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueues.html)`
+ `[ListQueueTags](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html)`
+ `[RemovePermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_RemovePermission.html)`
+ `[SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)`
+ `[StartMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_StartMessageMoveTask.html)`
+ `[TagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_TagQueue.html)`
+ `[UntagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_UntagQueue.html)`
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_AllActions",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/role1",
"arn:aws:iam::111122223333:user/username1"
]
},
"Action": "sqs:*",
"Resource": "arn:aws:sqs:us-east-2:123456789012:queue1"
}]
}
```
------
## 例5:すべてのユーザーにアクセス権限を付与する
以下のサンプルポリシーは、すべてのユーザー (匿名ユーザー) に、`111122223333/queue1` という名前のキューに対する `ReceiveMessage` アクセス権限を付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_AnonymousAccess_ReceiveMessage",
"Effect": "Allow",
"Principal": "*",
"Action": "sqs:ReceiveMessage",
"Resource": "arn:aws:sqs:*:111122223333:queue1"
}]
}
```
------
## 例6:すべてのユーザーに時間制限付きのアクセス権限を付与する
以下のサンプルポリシーは、すべてのユーザー (匿名ユーザー) に、`ReceiveMessage`という名前のキューに対する`111122223333/queue1`アクセス権限を 2009 年 1 月 31 日の午後 12:00 (正午) から 午後 3:00 の間のみ付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_AnonymousAccess_ReceiveMessage_TimeLimit",
"Effect": "Allow",
"Principal": "*",
"Action": "sqs:ReceiveMessage",
"Resource": "arn:aws:sqs:*:111122223333:queue1",
"Condition" : {
"DateGreaterThan" : {
"aws:CurrentTime":"2009-01-31T12:00Z"
},
"DateLessThan" : {
"aws:CurrentTime":"2009-01-31T15:00Z"
}
}
}]
}
```
------
## 例7:CIDR範囲のすべてのユーザーにすべてのアクセス権限を付与する
以下のサンプルポリシーは、すべてのユーザー (匿名ユーザー) に、 `111122223333/queue1`という名前のキューで共有できるすべてのAmazon SQS アクションを使用するアクセス権限を、リクエストが`192.0.2.0/24` CIDRの範囲から生成された場合のみ付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_AnonymousAccess_AllActions_AllowlistIP",
"Effect": "Allow",
"Principal": "*",
"Action": "sqs:*",
"Resource": "arn:aws:sqs:*:111122223333:queue1",
"Condition" : {
"IpAddress" : {
"aws:SourceIp":"192.0.2.0/24"
}
}
}]
}
```
------
## 例8:異なる CIDR 範囲のユーザーの許可リストとブロックリストのアクセス権限
以下のサンプルポリシーには、2つのステートメントが含まれています。
+ 最初のステートメントは、`192.0.2.0/24`CIDR の範囲 (`192.0.2.188` を除く) に存在するすべてのユーザー (匿名ユーザー) に、`SendMessage`/queue1 という名前のキューに対する`111122223333`アクションを使用するアクセス権限を付与します。
+ 2 番目のステートメントは、`12.148.72.0/23`CIDR の範囲に存在するすべてのユーザー (匿名ユーザー) のキュー使用をブロックます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [{
"Sid":"Queue1_AnonymousAccess_SendMessage_IPLimit",
"Effect": "Allow",
"Principal": "*",
"Action": "sqs:SendMessage",
"Resource": "arn:aws:sqs:*:111122223333:queue1",
"Condition" : {
"IpAddress" : {
"aws:SourceIp":"192.0.2.0/24"
},
"NotIpAddress" : {
"aws:SourceIp":"192.0.2.188/32"
}
}
}, {
"Sid":"Queue1_AnonymousAccess_AllActions_IPLimit_Deny",
"Effect": "Deny",
"Principal": "*",
"Action": "sqs:*",
"Resource": "arn:aws:sqs:*:111122223333:queue1",
"Condition" : {
"IpAddress" : {
"aws:SourceIp":"12.148.72.0/23"
}
}
}]
}
```
------
# Amazon SQSアクセスポリシー言語を使用したカスタムポリシーの使用
AWS アカウント ID のみに基づいて基本的なアクセス許可 ( [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)や など[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)) を付与するには、カスタムポリシーを記述する必要はありません。代わりに、Amazon SQS [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html) アクションを使用します。
リクエスト時間やリクエスタの IP アドレスなどの特定の条件に基づいてアクセスを許可または拒否するには、カスタム Amazon SQS ポリシーを作成し、[SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html) アクションを使用してアップロードする必要があります。
**Topics**
+ [アクセスコントロールアーキテクチャ](sqs-creating-custom-policies-architecture.md)
+ [アクセスコントロールプロセスのワークフロー](sqs-creating-custom-policies-process-workflow.md)
+ [アクセスポリシー言語の主要概念](sqs-creating-custom-policies-key-concepts.md)
+ [アクセスポリシー言語の評価ロジック](sqs-creating-custom-policies-evaluation-logic.md)
+ [明示的な拒否とデフォルトで拒否の関係](sqs-creating-custom-policies-relationships-between-explicit-default-denials.md)
+ [カスタムポリシーの制限](sqs-limitations-of-custom-policies.md)
+ [カスタムアクセスポリシー言語の例](sqs-creating-custom-policies-access-policy-examples.md)
# Amazon SQSのアクセスコントロールアーキテクチャ
以下の図は、Amazon SQSリソースのアクセスコントロールの説明です。
![\[Amazon SQS リソースのアクセスコントロールを示します。\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/AccessPolicyLanguage_Arch_Overview.png)
![\[In the previous diagram, section number one.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-1-red.png)リソース所有者。
![\[In the previous diagram, section number two.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-2-red.png) AWS サービスに含まれるリソース (Amazon SQS キューなど）。
![\[In the previous diagram, section number three.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-3-red.png)ポリシー。1 つのリソースごとに 1 つのポリシーを適用することをお勧めします。この AWS サービスには、ポリシーのアップロードと管理に使用する API が用意されています。
![\[In the previous diagram, section number four.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-4-red.png)リクエスタ、および AWS サービスに対する受信リクエスト。
![\[In the previous diagram, section number five.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-5-red.png)アクセスポリシー言語の評価コード。これは、受信リクエストを該当するポリシーと照らし合わせて評価し、リクエスタがリソースへのアクセスを許可するかどうかを決定する AWS サービス内のコードのセットです。
# Amazon SQSアクセスコントロールプロセスのワークフロー
以下の図は、 Amazon SQSアクセスポリシー言語と アクセスコントロールの全般的なワークフローを表しています。
![\[Amazon SQS アクセスポリシー言語を使用したアクセスコントロールの全般的なワークフロー。\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/AccessPolicyLanguage_Basic_Flow.png)
![\[Figure one in the previous diagram.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-1-red.png)キューの Amazon SQSポリシーを記述します。
![\[Figure two in the previous diagram.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-2-red.png) ポリシーを にアップロードします AWS。この AWS サービスは、ポリシーのアップロードに使用する API を提供します。たとえば、特定の Amazon SQSキュー用のポリシーをアップロードするために Amazon SQS`SetQueueAttributes`アクションを使用します。
![\[Figure three in the previous diagram.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-3-red.png)ある人物から、Amazon SQSキューの使用を求めるリクエストが送信されます。
![\[Figure four in the previous diagram.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-4-red.png)Amazon SQS はすべての利用可能な Amazon SQSポリシーを分析し、該当するものを判断します。
![\[Figure five in the previous diagram.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-5-red.png)Amazon SQSがポリシーを評価し、キューの使用許可をリクエスタに付与するかどうかを決定します。
![\[Figure six in the previous diagram.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-6-red.png)ポリシーの評価結果に基づいて、Amazon SQSはリクエスタに `Access denied` エラーを返すか、リクエストの処理を続行します。
# Amazon SQSアクセスポリシー言語の主要な概念
独自のポリシーを作成するには、[JSON](http://json.org/) およびいくつかの重要な概念を理解している必要があります。
**許可**
[Statement](#statement)が[[Effect] (効果)](#effect)に設定された`allow`の結果。
**アクション**
[プリンシパル](#principal)が実行アクセス権限を持っているアクティビティ。通常は AWSへのリクエスト。
**Default-deny**
[Statement](#statement)または[許可](#allow)設定を持たない[Explicit-deny](#explicit-deny)の結果。
**条件**
[アクセス権限](#permission)に関する制限または詳細。よく使用される条件は日時とIP アドレスに関連しています。
**[Effect]** (効果)
[Statement](#statement)の[Policy](#policy)で評価時に返される結果。ポリシーステートメントを作成するときに、`deny`または`allow`の値を指定します。ポリシーの評価時に、[Default-deny](#default-deny)、[許可](#allow)、または[Explicit-deny](#explicit-deny)の 3 つの結果が得られます。
**Explicit-deny**
[Statement](#statement)が[[Effect] (効果)](#effect)に設定された`deny`の結果。
**評価**
Amazon SQSが使用するプロセスでは、受信したリクエストを拒否または許可するかを、[Policy](#policy)に基づいて判断します。
**Issuer**
ユーザーは[Policy](#policy)を記述して、リソースへのアクセス権限を付与します。定義上、発行者は常にリソース所有者です。Amazon SQS AWS ユーザーは、所有していないリソースのポリシーを作成できません。
**キー**
アクセス制限に使用される基本項目です。
**アクセス権限**
[条件](#condition)および[キー](#key)を使用して、特定のリソースへのある種のアクセスに対し、許可または拒否をするというコンセプトです。
**Policy**
1つ以上の**[ステートメント](#statement)**のコンテナの役目を果たすドキュメントです。
![\[ステートメント 1 とステートメント 2 を含むポリシー A は、ステートメント 1 を含むポリシー A と、ステートメント 2 を含むポリシー B と同等です。\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/AccessPolicyLanguage_Statement_and_Policy.png)
Amazon SQSはポリシーを使用して、リソースに関してユーザーにアクセス権限を付与するかどうかを決定します。
**プリンシパル**
[アクセス権限](#permission)で[Policy](#policy)を受け取るユーザー。
**[リソース]**
[プリンシパル](#principal) によるリクエストがアクセスするオブジェクト。
**Statement**
より広範なドキュメントの一部として[Policy](#policy)で作成された1つのアクセス権限の正式な説明。
**リクエスタ**
[[リソース]](#resource) にアクセスするためにリクエストを送信するユーザー。
# Amazon SQSアクセスポリシー言語評価ロジック
Amazon SQSは評価時に、リソース所有者以外の別の人物から与えられたリクエストに対し、許可するか拒否するかを決定します。評価論理は、以下の複数の基本ルールに従っています。
+ デフォルトでは、リソースの使用許可を求めるリクエストについては、リクエスタが自分自身である場合を除いて、拒否を適用する。
+ *[許可](sqs-creating-custom-policies-key-concepts.md#allow)* はすべての*[Default-deny](sqs-creating-custom-policies-key-concepts.md#default-deny)*をオーバーライドする。
+ *[Explicit-deny](sqs-creating-custom-policies-key-concepts.md#explicit-deny)* はすべての**allow**をオーバーライドする。
+ ポリシー評価の順序は重要ではない。
次の図は、アクセス権限に関する決定事項をAmazon SQSがどのように評価するかに関する詳細を示しています。
![\[Amazon SQS がアクセス許可に関する決定をどのように評価するかを示すフローチャート。\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/AccessPolicyLanguage_Evaluation_Flow.png)
![\[In the previous diagram, number one.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-1-red.png) 決定は**default-deny**から始まります。
![\[In the previous diagram, number two.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-2-red.png)エンフォースメントコードは、リクエストに適用可能なポリシーすべてを、リソース、プリンシパル、アクション、および条件に基づいて評価します。エンフォースメントコードによるポリシー評価の順序は重要ではありません。
![\[In the previous diagram, number three.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-3-red.png) エンフォースメントコードは、リクエストに適用できる **explicit-deny** インストラクションを探します。仮に1つでも見つかった場合、エンフォースメントコードは**拒否**の決定を返し、プロセスは終了します。
![\[In the previous diagram, number four.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-4-red.png) **explicit-deny** が見つからなかった場合、リクエストに適応できる**allow**インストラクションがエンフォースメントコードによって検索されます。仮に1つでも見つかった場合、エンフォースメントコードは**許可**の決定を返し、プロセスは完了します (サービスはリクエストのプロセスを継続します)。
![\[In the previous diagram, number five.\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/number-5-red.png)**allow**インストラクションが見つからなかった場合、最終決定は **deny**となります(**explicit-deny**または**allow**が見つからない場合、**default-deny**として見なされるためです)。
# Amazon SQSアクセスポリシー言語の明示的な拒否とデフォルトの拒否の関係
Amazon SQS ポリシーがリクエストに直接適用されない場合、リクエストの結果は、*[Default-deny](sqs-creating-custom-policies-key-concepts.md#default-deny)* となります。たとえば、ユーザーが Amazon SQSを使用するアクセス権限をリクエストしたが、そのユーザーに適用される唯一のポリシーではDynamoDBを使用できる場合、リクエストの結果は** default-deny**となります。
ステートメントの条件が満たされない場合、リクエストの結果は **default-deny**になります。ステートメントのすべての条件が満たされている場合、ポリシーの *[[Effect] (効果)](sqs-creating-custom-policies-key-concepts.md#effect)* エレメントの値に基づいて、リクエストの結果は *[許可](sqs-creating-custom-policies-key-concepts.md#allow)* または *[Explicit-deny](sqs-creating-custom-policies-key-concepts.md#explicit-deny)* のいずれかになります。条件が満たされていない際にポリシーが行為を特定していない場合、デフォルトの結果として **default-deny** となります。たとえば、南極大陸から来るリクエストを防ぐとします。その場合、南極大陸から来ていないリクエストにのみ許可を与えるポリシー A1を記述します。以下の図はAmazon SQSポリシーについて解説しています。
![\[ポリシー A1 では、[効果] が [許可] に等しく、[条件] が [リクエストが南極大陸から来ていない場合] に等しくなっています。\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-security-custom-policy-allow-request-if-not-from-antarctica.png)
ユーザーがアメリカからリクエストを送信すると、条件が満たされ (リクエストは南極大陸から来ていない)、リクエストの結果は **allow** になります。ただし、ユーザーが南極からリクエストを送信した場合、条件は満たされず、リクエストはデフォルトで **default-deny** になります。南極大陸から来たリクエストを明示的に拒否するポリシー A2を作成して、結果を **explicit-deny** に変更することができます。以下の図はポリシーについて解説しています。
![\[ポリシー A2 では、[効果] が [拒否] に等しく、[条件] が [リクエストが南極大陸から来ている場合] に等しくなっています。\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-security-custom-policy-explicitly-deny-request-if-from-antarctica.png)
ユーザーが南極大陸からリクエストを送信すると、条件は満たされ、リクエストの結果は**explicit-deny**となります。
**default-deny** と **explicit-deny** の違いは重要です。**allow** は前者を上書きできますが、後者を上書きすることはできないためです。たとえば、ポリシー Bは、2010年6月1日に届いたリクエストを許可します。以下の図は、このポリシーをポリシー A1およびポリシー A2と組み合わせた場合を比較しています。
![\[シナリオ 1 とシナリオ 2 を並べた比較。\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-security-custom-policy-compare-allow-request-deny-request-policies-override.png)
シナリオ 1では、ポリシー A1の結果は**default-deny**になり、ポリシー Bの結果は**allow**になります。これは、ポリシーで 2010年6月1日に来るリクエストが許可されるためです。ポリシー Bによる**allow**は、ポリシー A1の **default-deny**で拒否に優先するため、結果としてリクエストは許可されます。
シナリオ 2 で、ポリシー B2の結果は **explicit-deny** になり、ポリシー Bの結果は **allow** になります。ポリシー A2 による**explicit-deny**は、ポリシー Bの**allow** に優先するため、結果としてリクエストは拒否されます。
# Amazon SQS カスタムポリシーの制限
## クロスアカウントアクセス
クロスアカウント権限は、次のアクションには適用されません。
+ `[AddPermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html)`
+ `[CancelMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CancelMessageMoveTask.html)`
+ `[CreateQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_CreateQueue.html)`
+ `[DeleteQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteQueue.html)`
+ `[ListMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListMessageMoveTasks.html)`
+ `[ListQueues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueues.html)`
+ `[ListQueueTags](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueueTags.html)`
+ `[RemovePermission](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_RemovePermission.html)`
+ `[SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)`
+ `[StartMessageMoveTask](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_StartMessageMoveTask.html)`
+ `[TagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_TagQueue.html)`
+ `[UntagQueue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_UntagQueue.html)`
## 条件キー
現在、Amazon SQS は[IAMで使用可能な条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys)の制限されたサブセットのみをサポートしています。詳細については、「[Amazon SQS (Amazon SQS)、 API のアクセス権限: アクションとリソースのリファレンスについて](sqs-api-permissions-reference.md)」を参照してください。
# カスタムの Amazon SQSアクセスポリシー言語の例
一般的な Amazon SQSアクセスポリシーの例を次に示します。
## 例1:1つのアカウントにアクセス権限を与える
次のAmazon SQSポリシー例では、 AWS アカウント 444455556666で所有される`queue2`から送受信するアクセス権限を AWS アカウント 111122223333に与えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "UseCase1",
"Statement" : [{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333"
]
},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:us-east-2:444455556666:queue2"
}]
}
```
------
## 例2:1つ以上のアカウントにアクセス権限を与える
次の Amazon SQS ポリシーの例では、特定の期間にアカウントが所有するキューへの 1 つ以上の AWS アカウント アクセスを許可します。このポリシーを作成し、Amazon SQSにアップロードするには、[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)のためアクション[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html)アクションでは、キューへのアクセスを許可するときに時間制限を指定することはできません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "UseCase2",
"Statement" : [{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333",
"444455556666"
]
},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:us-east-2:444455556666:queue2",
"Condition": {
"DateLessThan": {
"AWS:CurrentTime": "2009-06-30T12:00Z"
}
}
}]
}
```
------
## 例3:Amazon EC2インスタンスからのリクエストに許可を与える
次の例では、Amazon SQSポリシーはAmazon EC2 インスタンスから来るリクエストへのアクセスを許可します。この例では、"[例2:1つ以上のアカウントにアクセス権限を与える](#two-accounts)" の例を作成します。2009年6月30日正午 (UTC) 以前のアクセスを制限し、IP 範囲`203.0.113.0/24`へのアクセスを制限します。このポリシーを作成し、Amazon SQS にアップロードするには、[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)のためにアクション[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html)アクションでは、キューへのアクセスを許可するときに IP アドレス制限を指定することはできません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "UseCase3",
"Statement" : [{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333"
]
},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:us-east-2:444455556666:queue2",
"Condition": {
"DateLessThan": {
"AWS:CurrentTime": "2009-06-30T12:00Z"
},
"IpAddress": {
"AWS:SourceIp": "203.0.113.0/24"
}
}
}]
}
```
------
## 例4:特定のアカウントへのアクセスを拒否する
次の Amazon SQS ポリシーの例では、キューへの特定の AWS アカウント アクセスを拒否します。この例では、[例1:1つのアカウントにアクセス権限を与える](#one-account)「」の例に基づいて構築されています。指定された へのアクセスを拒否します AWS アカウント。このポリシーを作成し、Amazon SQS にアップロードするには、[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)のためにアクション[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_AddPermission.html)アクションは、キューへのアクセスを拒否することを許可しません（キューへのアクセスのみを許可します）。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "UseCase4",
"Statement" : [{
"Sid": "1",
"Effect": "Deny",
"Principal": {
"AWS": [
"111122223333"
]
},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:us-east-2:444455556666:queue2"
}]
}
```
------
## 例5:VPC エンドポイントからではない場合はアクセスを拒否する
次の Amazon SQS ポリシーの例では、`queue1` へのアクセスを制限します。111122223333 が [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html) および [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html) アクションを実行できるのは、VPC エンドポイント ID `vpce-1a2b3c4d` (`aws:sourceVpce` 条件を使用して指定) からのみです。詳細については、「[Amazon SQSのAmazon Virtual Private Cloud エンドポイント](sqs-internetwork-traffic-privacy.md#sqs-vpc-endpoints)」を参照してください。
**注記**
`aws:sourceVpce` 条件では、VPC エンドポイントID のみが必要で、VPC エンドポイントリソースのARNは必要ありません。
次の例を変更し、2番目のステートメントですべてのアクション (`sqs:*`) を拒否して、特定の VPC エンドポイントにすべての Amazon SQS アクションを制限できます。ただし、このようなポリシーステートメントにより、すべてのアクション (キューのアクセス権限を変更するために必要な管理アクションを含む) が、ポリシーで定義された特定の VPC エンドポイントを通じて行われる必要があることが規定されます。この場合、ユーザーは今後キューのアクセス権限を変更できなくなる可能性があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "UseCase5",
"Statement": [{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": [
"111122223333"
]
},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:us-east-2:111122223333:queue1"
},
{
"Sid": "2",
"Effect": "Deny",
"Principal": "*",
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": "arn:aws:sqs:us-east-2:111122223333:queue1",
"Condition": {
"StringNotEquals": {
"aws:sourceVpce": "vpce-1a2b3c4d"
}
}
}
]
}
```
------
# Amazon SQSで一時的なセキュリティ認証情報を使用する
IAM では、独自のセキュリティ認証情報を使用してユーザーを作成するだけでなく、任意のユーザーに一時的なセキュリティ認証情報を付与できるため、ユーザーは AWS サービスとリソースにアクセスできます。 AWS アカウントを持つユーザーを管理できます。また、 を持たないシステムのユーザー AWS アカウント (フェデレーティッドユーザー) を管理することもできます。さらに、 AWS リソースにアクセスするために作成したアプリケーションは、「ユーザー」と見なされることもあります。
Amazon SQSに対するリクエストを作成するときに、これらの一時的なセキュリティ認証情報を使用できます。APIライブラリによって、これらの認証情報を使用して必要な署名値が計算されて、リクエストが認証されます。失効した証明書を使用してリクエストを送信した場合、Amazon SQS はリクエストを拒否します。
**注記**
一時的な認証情報に基づいてポリシーを設定することはできません。
## 前提条件
1. 一時的なセキュリティ認証情報を作成するには、IAMを使用します。
+ セキュリティトークン
+ アクセスキー ID
+ シークレットアクセスキー
1. 一時アクセスキー IDとセキュリティトークンで署名対象のリクエスト文字列を準備します。
1. 独自のシークレットアクセスキーの代わりに一時シークレットアクセスキーを使用して、クエリAPI リクエストに署名します。
**注記**
署名付きのクエリAPI リクエストを送信するときは、独自のアクセスキー ID の代わりに一時アクセスキー IDを使用して、セキュリティトークンを含めます。一時的なセキュリティ認証情報の IAM サポートの詳細については、*IAM ユーザーガイド*の[AWS 「リソースへの一時的なアクセスの付与](https://docs.aws.amazon.com/IAM/latest/UserGuide/TokenBasedAuth.html)」を参照してください。
## 一時的なセキュリティ認証情報を使用して Amazon SQSクエリ API アクションを呼び出すには
1. を使用して一時的なセキュリティトークンをリクエストします AWS Identity and Access Management。詳細については、*IAM ユーザーガイド*の[「一時的なセキュリティ認証情報を使用して、IAMユーザーのアクセスを可能にする」](https://docs.aws.amazon.com/IAM/latest/UserGuide/CreatingSessionTokens.html) を参照してください。
IAMにより、セキュリティトークン、アクセスキー ID、シークレットアクセスキーが返信されます。
1. クエリは、独自のアクセスキー IDの代わりに一時アクセスキー IDを使用し、セキュリティトークンを含めて準備します。独自のシークレットアクセスキーの代わりに一時シークレットアクセスキーを使用してリクエストに署名します。
1. 一時アクセスキー IDとセキュリティトークンを含む署名付きクエリ文字列を送信します。
以下の例は、一時的なセキュリティ認証情報を使用してAmazon SQS リクエストを認証する方法を示しています。*`AUTHPARAMS`*の構造はAPIリクエストの署名によって異なります。詳細については、*Amazon Web Services 全般のリファレンス*[の AWS API リクエストの署名](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html)を参照してください。
```
https://sqs.us-east-2.amazonaws.com/
?Action=CreateQueue
&DefaultVisibilityTimeout=40
&QueueName=MyQueue
&Attribute.1.Name=VisibilityTimeout
&Attribute.1.Value=40
&Expires=2020-12-18T22%3A52%3A43PST
&SecurityToken=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
&AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE
&Version=2012-11-05
&AUTHPARAMS
```
以下の例は、一時的なセキュリティ認証情報を使用し、`SendMessageBatch` アクションで 2 つのメッセージを送信する方法を示しています。
```
https://sqs.us-east-2.amazonaws.com/
?Action=SendMessageBatch
&SendMessageBatchRequestEntry.1.Id=test_msg_001
&SendMessageBatchRequestEntry.1.MessageBody=test%20message%20body%201
&SendMessageBatchRequestEntry.2.Id=test_msg_002
&SendMessageBatchRequestEntry.2.MessageBody=test%20message%20body%202
&SendMessageBatchRequestEntry.2.DelaySeconds=60
&Expires=2020-12-18T22%3A52%3A43PST
&SecurityToken=je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY
&AWSAccessKeyId=AKIAI44QH8DHBEXAMPLE
&Version=2012-11-05
&AUTHPARAMS
```
# 最小特権ポリシーによる暗号化された Amazon SQS キューのアクセス管理
Amazon SQS では、[AWS Key Management Service (KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) と統合されたサーバー側の暗号化 (SSE) を使用して、アプリケーション間で機密データを交換できます。Amazon SQS と の統合により AWS KMS、Amazon SQS を保護するキーと、他の AWS リソースを保護するキーを一元管理できます。
複数の AWS サービスは、Amazon SQS にイベントを送信するイベントソースとして機能します。イベントソースが暗号化された Amazon SQS キューにアクセスできるようにするには、[カスタマーマネージド](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) AWS KMS キーを使用してキューを設定する必要があります。次に、 キーポリシーを使用して、サービスに必要な AWS KMS API メソッドの使用を許可します。サービスには、キューがイベントを送信できるようにするためのアクセス認証のアクセス権限も必要です。これを実現するには、Amazon SQS ポリシーを使用します。Amazon SQS ポリシーは、Amazon SQS キューとそのデータへのアクセスを制御するために使用できるリソースベースのポリシーです。
以下のセクションでは、Amazon SQS ポリシーと AWS KMS キーポリシーを使用して、暗号化された Amazon SQS キューへのアクセスを制御する方法について説明します。このガイドのポリシーは、[最小特権](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)を達成するのに役立ちます。
また、このガイドでは、[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)、[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)、および [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) グローバル IAM 条件コンテキストキーを使用して、リソースベースのポリシーで[混乱による代理問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)に対処する方法についても説明します。
**Topics**
+ [
## 概要:
](#sqs-least-privilege-overview)
+ [
## Amazon SQS の最小特権キーポリシー
](#sqs-least-privilege-use-case)
+ [
## デッドレターキューの Amazon SQS ポリシーステートメント
](#sqs-policy-dlq)
+ [
## サービス間での混乱した使節問題を防止する
](#sqs-confused-deputy-prevention)
+ [
## IAM Access Analyzer を使用して、クロスアカウントアクセスを確認します。
](#sqs-cross-account-findings)
## 概要:
このトピックでは、一般的なユースケースを順を追って説明し、キーポリシーと Amazon SQS キューポリシーを構築する方法について説明します。このユースケースは次の画像に示されています。
![\[Amazon SNS メッセージの Amazon SQS への発行。\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/images/sqs-least-privilege.png)
この例では、メッセージプロデューサーは [Amazon Simple Notification Service (SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) トピックで、暗号化された Amazon SQS キューにメッセージをファンアウトするように設定されています。メッセージコンシューマーは、[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) 関数、[Amazon Elastic Compute Cloud (EC2)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html) インスタンス、[AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) コンテナなどのコンピューティングサービスです。Amazon SQS キューは、失敗したメッセージを[デッドレターキュー (DLQ)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) に送信するように設定されます。DLQ は、未使用のメッセージを分離して、処理が成功しない理由を調べることができるため、アプリケーションやメッセージングシステムのデバッグに役立ちます。このトピックで定義されているソリューションでは、Lambda 関数などのコンピューティングサービスを使用して Amazon SQS キューに保存されたメッセージを処理します。メッセージコンシューマーが仮想プライベートクラウド (VPC) に配置されている場合、このガイドに含まれる [`DenyReceivingIfNotThroughVPCE`](#sqs-restrict-message-to-endpoint) ポリシーステートメントにより、メッセージの受信をその特定の VPC に制限できます。
**注記**
このガイドには、必要な IAM アクセス許可のみがポリシーステートメントの形式で記載されています。ポリシーを作成するには、Amazon SQS ポリシーまたは AWS KMS キーポリシーにステートメントを追加する必要があります。このガイドでは、Amazon SQS キューまたは AWS KMS キーを作成する方法については説明していません。これらのリソースの作成方法については、「[Amazon SQS キューを作成する](creating-sqs-standard-queues.md#step-create-standard-queue)」および「[キーの作成](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)」を参照してください。
このガイドで定義されている Amazon SQS ポリシーでは、メッセージを同じ Amazon SQS キューまたは別の Amazon SQS キューに直接リドライブすることはサポートされません。
## Amazon SQS の最小特権キーポリシー
このセクションでは、Amazon SQS キューの暗号化に使用するカスタマーマネージドキー AWS KMS の で必要な最小特権のアクセス許可について説明します。これらのアクセス許可により、最小特権を実装しながら、アクセスを目的のエンティティのみに制限できます。キーポリシーは、以下のポリシーステートメントで構成されている必要があります。詳細については以下で説明します。
+ [AWS KMS キーに管理者権限を付与する](#sqs-use-case-kms-admin-permissions)
+ [キーメタデータへの読み取り専用アクセスを付与する](#sqs-use-case-read-only-permissions)
+ [キューにメッセージを発行するために、Amazon SNS KMS のアクセス許可を Amazon SNS に付与する](#sqs-use-case-publish-messages-permissions)
+ [コンシューマーがキューからのメッセージを復号化することを許可する](#sqs-use-case-decrypt-messages-permissions)
### AWS KMS キーに管理者権限を付与する
AWS KMS キーを作成するには、 AWS KMS キーのデプロイに使用する IAM ロールに AWS KMS 管理者権限を付与する必要があります。これらの管理者権限は、以下の `AllowKeyAdminPermissions` ポリシーステートメントで定義されています。このステートメントを AWS KMS キーポリシーに追加するときは、** を、 AWS KMS キーのデプロイ、 AWS KMS キーの管理、またはその両方に使用される IAM ロールの Amazon リソースネーム (ARN) に置き換えてください。これは、デプロイパイプラインの IAM ロールでも、[AWS Organizations](https://aws.amazon.com/organizations/) 内の[組織の管理者ロール](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_access.html)でもかまいません。
```
{
"Sid": "AllowKeyAdminPermissions",
"Effect": "Allow",
"Principal": {
"AWS": [
""
]
},
"Action": [
"kms:Create*",
"kms:Describe*",
"kms:Enable*",
"kms:List*",
"kms:Put*",
"kms:Update*",
"kms:Revoke*",
"kms:Disable*",
"kms:Get*",
"kms:Delete*",
"kms:TagResource",
"kms:UntagResource",
"kms:ScheduleKeyDeletion",
"kms:CancelKeyDeletion"
],
"Resource": "*"
}
```
**注記**
AWS KMS キーポリシーでは、 `Resource`要素の値は である必要があります。これは`*`「この AWS KMS キー」を意味します。アスタリスク (`*`) は、 AWS KMS キーポリシーがアタッチされているキーを識別します。
### キーメタデータへの読み取り専用アクセスを付与する
他の IAM ロールにキーメタデータへの読み取り専用アクセス権を付与するには、その `AllowReadAccessToKeyMetaData` ステートメントをキーポリシーに追加します。たとえば、次のステートメントでは、監査目的でアカウント内のすべての AWS KMS キーを一覧表示できます。このステートメントは、 AWS ルートユーザーにキーメタデータへの読み取り専用アクセスを許可します。したがって、アカウント内の IAM プリンシパルは、その ID ベースのポリシーに次のステートメント (`kms:Describe*`、`kms:Get*`、`kms:List*`) に記載されているアクセス権限が付与されていれば、キーメタデータにアクセスできます。** をユーザー自身の情報に必ず置き換えます。
```
{
"Sid": "AllowReadAcesssToKeyMetaData",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam:::root"
]
},
"Action": [
"kms:Describe*",
"kms:Get*",
"kms:List*"
],
"Resource": "*"
}
```
### キューにメッセージを発行するために、Amazon SNS KMS のアクセス許可を Amazon SNS に付与する
Amazon SNS トピックが、暗号化された Amazon SQS キューにメッセージを発行できるようにするには、`AllowSNSToSendToSQS` ポリシーステートメントをキーポリシーに追加します。このステートメントは、 AWS KMS キーを使用して Amazon SNSAmazon SQSに付与します。** をユーザー自身の情報に必ず置き換えます。
**注記**
ステートメント`Condition`の は、同じ AWS アカウントの Amazon SNS サービスのみへのアクセスを制限します。
```
{
"Sid": "AllowSNSToSendToSQS",
"Effect": "Allow",
"Principal": {
"Service": [
"sns.amazonaws.com"
]
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:SourceAccount": ""
}
}
}
```
### コンシューマーがキューからのメッセージを復号化することを許可する
次の `AllowConsumersToReceiveFromTheQueue` ステートメントは、暗号化された Amazon SQS キューから受信したメッセージを復号化するために必要なアクセス許可を Amazon SQS メッセージコンシューマーに付与します。ポリシーステートメントを添付するときは、** をメッセージコンシューマーの IAM ランタイムロール ARN に置き換えます。
```
{
"Sid": "AllowConsumersToReceiveFromTheQueue",
"Effect": "Allow",
"Principal": {
"AWS": [
""
]
},
"Action": [
"kms:Decrypt"
],
"Resource": "*"
}
```
### Amazon SQS の最小特権ポリシー
このセクションでは、このガイドの対象となるユースケース (例えば Amazon SNS から Amazon SQS へ) の最小特権の Amazon SQS キューポリシーについて説明します。定義されたポリシーは、`Deny` および `Allow` ステートメントの両方を組み合わせて使用することで、意図しないアクセスを防ぐように設計されています。`Allow` ステートメントは、目的の 1 つ以上のエンティティへのアクセスを許可します。`Deny` ステートメントは、ポリシー条件の範囲内で目的のエンティティを除外しながら、意図しない他のエンティティが Amazon SQS キューにアクセスするのを防ぎます。
Amazon SQS ポリシーには以下のステートメントが含まれています。詳細については以下で説明します。
+ [Amazon SQS の管理権限を制限する](#sqs-use-case-restrict-permissions)
+ [指定された組織からの Amazon SQS キューアクションを制限する](#sqs-use-case-restrict-permissions-from-org)
+ [Amazon SQS のアクセス許可をコンシューマーに付与する](#sqs-use-grant-consumer-permissions)
+ [転送時の暗号化を強制する](#sqs-encryption-in-transit)
+ [メッセージ送信を特定の Amazon SNS トピックに制限する](#sqs-restrict-transmission-to-topic)
+ [(オプション) 特定の VPC エンドポイントに対するメッセージの受信を制限する](#sqs-restrict-message-to-endpoint)
### Amazon SQS の管理権限を制限する
次の `RestrictAdminQueueActions` ポリシーステートメントは、Amazon SQS の管理権限を、キューのデプロイ、キューの管理、またはその両方に使用する 1 つまたは複数の IAM ロールのみに制限します。** をユーザー自身の情報に必ず置き換えます。Amazon SQS キューのデプロイに使用する IAM ロールの ARN と、Amazon SQS 管理権限が必要なすべての管理者ロールの ARN を指定します。
```
{
"Sid": "RestrictAdminQueueActions",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": [
"sqs:AddPermission",
"sqs:DeleteQueue",
"sqs:RemovePermission",
"sqs:SetQueueAttributes"
],
"Resource": "",
"Condition": {
"StringNotLike": {
"aws:PrincipalARN": [
"arn:aws:iam:::role/",
""
]
}
}
}
```
### 指定された組織からの Amazon SQS キューアクションを制限する
Amazon SQS リソースを外部アクセス ([AWS 組織](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)外のエンティティによるアクセス) から保護するには、次のステートメントを使用します。このステートメントは、Amazon SQS キューアクセスを `Condition` で指定した組織に制限します。必ず ** Amazon SQS キューのデプロイに使用した IAM ロールの ARN に、** を組織 ID に置き換えてください。
```
{
"Sid": "DenyQueueActionsOutsideOrg",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": [
"sqs:AddPermission",
"sqs:ChangeMessageVisibility",
"sqs:DeleteQueue",
"sqs:RemovePermission",
"sqs:SetQueueAttributes",
"sqs:ReceiveMessage"
],
"Resource": "",
"Condition": {
"StringNotEquals": {
"aws:PrincipalOrgID": [
""
]
}
}
}
```
### Amazon SQS のアクセス許可をコンシューマーに付与する
Amazon SQS キューからメッセージを受信するには、メッセージコンシューマーに必要なアクセス許可を与える必要があります。次のポリシーステートメントは、Amazon SQS キューからのメッセージを消費するために必要なアクセス許可を、指定したコンシューマーに付与します。Amazon SQS ポリシーにステートメントを追加する際は、必ず ** をコンシューマーが使用する IAM ランタイムロールの ARN に置き換え、** をAmazon SQS キューをデプロイするために使用される IAM ロールの ARN に置き換えてください。
```
{
"Sid": "AllowConsumersToReceiveFromTheQueue",
"Effect": "Allow",
"Principal": {
"AWS": ""
},
"Action": [
"sqs:ChangeMessageVisibility",
"sqs:DeleteMessage",
"sqs:GetQueueAttributes",
"sqs:ReceiveMessage"
],
"Resource": ""
}
```
他のエンティティが Amazon SQS キューからメッセージを受信しないようにするには、Amazon SQS キューポリシーに `DenyOtherConsumersFromReceiving` ステートメントを追加します。このステートメントは、メッセージの消費を指定したコンシューマーに制限します。つまり、そのコンシューマーの ID アクセス許可によってアクセスが許可される場合でも、他のコンシューマーにはアクセスできなくなります。** と ** をユーザー自身の情報に必ず置き換えてください。
```
{
"Sid": "DenyOtherConsumersFromReceiving",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": [
"sqs:ChangeMessageVisibility",
"sqs:DeleteMessage",
"sqs:ReceiveMessage"
],
"Resource": "",
"Condition": {
"StringNotLike": {
"aws:PrincipalARN": ""
}
}
}
```
### 転送時の暗号化を強制する
以下の `DenyUnsecureTransport` ポリシーステートメントは、コンシューマーとプロデューサーが安全なチャネル (TLS 接続) を使用して Amazon SQS キューからメッセージを送受信することを強制します。** を Amazon SQS キューのデプロイに使用した IAM ロールの ARN に必ず置き換えてください。
```
{
"Sid": "DenyUnsecureTransport",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": [
"sqs:ReceiveMessage",
"sqs:SendMessage"
],
"Resource": "",
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
```
### メッセージ送信を特定の Amazon SNS トピックに制限する
以下の `AllowSNSToSendToTheQueue` ポリシーステートメントは、Amazon SNS トピックが指定された Amazon SQS キューへメッセージを送信できるようにします。** を Amazon SQS キューのデプロイに使用した IAM ロールの ARN に、** を Amazon SNS トピック ARN に必ず置き換えてください。
```
{
"Sid": "AllowSNSToSendToTheQueue",
"Effect": "Allow",
"Principal": {
"Service": "sns.amazonaws.com"
},
"Action": "sqs:SendMessage",
"Resource": "",
"Condition": {
"ArnLike": {
"aws:SourceArn": ""
}
}
}
```
次の `DenyAllProducersExceptSNSFromSending` ポリシーステートメントは、他のプロデューサーがキューにメッセージを送信できないようにします。** と** をユーザー自身の情報に置き換えてください。
```
{
"Sid": "DenyAllProducersExceptSNSFromSending",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "sqs:SendMessage",
"Resource": "",
"Condition": {
"ArnNotLike": {
"aws:SourceArn": ""
}
}
}
```
### (オプション) 特定の VPC エンドポイントに対するメッセージの受信を制限する
メッセージの受信を特定の [VPC エンドポイント](https://aws.amazon.com/about-aws/whats-new/2018/12/amazon-sqs-vpc-endpoints-aws-privatelink/)のみに制限するには、以下のポリシーステートメントを Amazon SQS キューポリシーに追加します。このステートメントは、メッセージが目的の VPC エンドポイントからのものでない限り、メッセージコンシューマーがキューからメッセージを受信することを防ぎます。** を Amazon SQS キューのデプロイに使用した IAM ロールの ARN に、および** を VPC エンドポイントの ID に置き換えてください。
```
{
"Sid": "DenyReceivingIfNotThroughVPCE",
"Effect": "Deny",
"Principal": "*",
"Action": [
"sqs:ReceiveMessage"
],
"Resource": "",
"Condition": {
"StringNotEquals": {
"aws:sourceVpce": ""
}
}
}
```
## デッドレターキューの Amazon SQS ポリシーステートメント
ステートメント ID で識別される以下のポリシーステートメントを DLQ アクセスポリシーに追加します。
+ `RestrictAdminQueueActions`
+ `DenyQueueActionsOutsideOrg`
+ `AllowConsumersToReceiveFromTheQueue`
+ `DenyOtherConsumersFromReceiving`
+ `DenyUnsecureTransport`
前述のポリシーステートメントを DLQ アクセスポリシーに追加することに加えて、次のセクションで説明するように、Amazon SQS キューへのメッセージ送信を制限するステートメントも追加する必要があります。
### Amazon SQS キューへのメッセージの送信を制限する
同じアカウントの Amazon SQS キューのみへのアクセスを制限するには、DLQ キューポリシーに次の `DenyAnyProducersExceptSQS` ポリシーステートメントを追加します。DLQ はメインキューを作成する前にデプロイする必要があるため、このステートメントでは特定のキューへのメッセージ送信を制限しません。DLQ の作成時に Amazon SQS ARN を知ることができないためです。1 つの Amazon SQS キューのみにアクセスを制限する必要がある場合、`Condition` 内の `aws:SourceArn` を Amazon SQS ソースキューの ARN で変更します。
```
{
"Sid": "DenyAnyProducersExceptSQS",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "sqs:SendMessage",
"Resource": "",
"Condition": {
"ArnNotLike": {
"aws:SourceArn": "arn:aws:sqs:::*"
}
}
}
```
**重要**
このガイドで定義されている Amazon SQS キューポリシーは、`sqs:PurgeQueue` アクションを特定の IAM ロールに制限しません。`sqs:PurgeQueue` アクションにより、Amazon SQS キューからのすべてのメッセージの削除が可能になります。このアクションを使用して、Amazon SQS キューを置き換えずにメッセージ形式を変更することもできます。アプリケーションをデバッグするときに、Amazon SQS キューをクリアして、エラーの可能性のあるメッセージを削除できます。アプリケーションをテストするときは、Amazon SQS キューに大量のメッセージを送り、本番環境に入る前にキューを消去して最初からやり直すことができます。このアクションを特定のロールに制限しない理由は、Amazon SQS キューをデプロイする際にこのロールがわからない可能性があるためです。キューを削除するには、このアクセス許可をロールの ID ベースのポリシーに追加する必要があります。
## サービス間での混乱した使節問題を防止する
[「混乱した代理」問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)は、アクションを実行するためのアクセス許可を持たないエンティティが、より特権のあるエンティティにアクションの実行を強制できてしまう場合に生じる、セキュリティ上の問題です。これを防ぐために、 は、アカウント内のリソースへのアクセスをサードパーティー (クロスアカウントと呼ばれる) または他の AWS サービス (クロスサービスと呼ばれる) に許可する場合に、アカウントを保護するのに役立つツール AWS を提供します。このセクションのポリシーステートメントは、サービス間の混乱した使節の問題を防止するのに役立ちます。
サービス間でのなりすましは、1 つのサービス (呼び出し元サービス) が、別のサービス (呼び出し対象サービス) を呼び出すときに発生する可能性があります。呼び出し元サービスが操作され、それ自体のアクセス許可を通じて、別の顧客のリソースに対して本来アクセス許可が付与されるべきではない形で働きかけが行われることがあります。この問題を防ぐため、この記事で定義されているリソースベースのポリシーでは、[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)、[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)、[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-principalorgid) およびグローバル IAM 条件コンテキストキーを使用しています。これにより、サービスが持つアクセス許可が、 AWS Organizations の特定のリソース、特定のアカウント、または特定の組織に制限されます。
## IAM Access Analyzer を使用して、クロスアカウントアクセスを確認します。
[AWS IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) を使用して Amazon SQS キューポリシーと AWS KMS キーポリシーを確認し、Amazon SQS キューまたは AWS KMS キーが外部エンティティへのアクセスを許可すると警告できます。IAM Access Analyzer の機能は、信頼ゾーン外のエンティティと共有されている組織とアカウントの[リソース](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-resources.html)を識別するのに役立ちます。この信頼ゾーンは、IAM Access Analyzer を有効にするときに指定する AWS アカウントまたは AWS Organizations 内の組織です。
IAM Access Analyzer は、ロジックベースの推論を使用して AWS 環境内のリソースベースのポリシーを分析することで、外部プリンシパルと共有されているリソースを識別します。信頼ゾーン外で共有されているリソースのインスタンスごとに、Access Analyzer は結果を生成します。[結果](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-findings.html)には、アクセスと付与される外部プリンシパルに関する情報が含まれます。結果を確認して、アクセスが意図的で安全なものであるか、またはアクセスが意図しないものであるか、セキュリティ上のリスクであるかを判断します。意図しないアクセスについては、影響を受けるポリシーを確認して修正します。 AWS IAM Access Analyzer が AWS リソースへの意図しないアクセスを識別する方法の詳細については、この[ブログ記事](https://aws.amazon.com/blogs/aws/identify-unintended-resource-access-with-aws-identity-and-access-management-iam-access-analyzer/)を参照してください。
AWS IAM Access Analyzer の詳細については、[AWS IAM Access Analyzer のドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)を参照してください。
# Amazon SQS (Amazon SQS)、 API のアクセス権限: アクションとリソースのリファレンスについて
[アクセスコントロール](security_iam_service-with-iam.md#access-control) をセットアップし、IAMアイデンティティにアタッチできるアクセス権限ポリシーを作成するときは、以下の表をリファレンスとして使用できます。テーブルリスト、各 Amazon Simple Queue Service アクション、アクションを実行するためのアクセス許可を付与できる対応するアクション、およびアクセス許可を付与できる AWS リソースが含まれます。
ポリシーの`Action`フィールドでアクションを指定し、ポリシーの`Resource`フィールドでリソースの値を指定します。アクションを指定するには、`sqs:`プレフィックスに続けて アクション名を使用します (例:`sqs:CreateQueue`)。
現在、Amazon SQS は [IAM で使用可能なグローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)をサポートしています。
スクロールバーを使用して、テーブルの残りの部分を確認します。
**Amazon Simple キューサービス API とアクションで必要なアクセス許可**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-api-permissions-reference.html)