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

# Amazon SQSのセキュリティベストプラクティス
<a name="sqs-security-best-practices"></a>

AWS には Amazon SQS 用の多くのセキュリティ機能が用意されています。これは、独自のセキュリティポリシーのコンテキストで確認する必要があります。以下に、Amazon SQSの予防的なセキュリティに関するベストプラクティスを示します。

**注記**  
提供される特定の実装ガイダンスは、一般的なユースケースと実装用です。特定のユースケース、アーキテクチャ、脅威モデルのコンテキストで、これらのベストプラクティスを確認することをお勧めします。

## キューがパブリックアクセス可能でないことの確認
<a name="ensure-queues-not-publicly-accessible"></a>

インターネット上のユーザーが Amazon SQS キューを読み書きできるように明示的に要求しない限り、キューにパブリックにアクセスできない (世界中のすべてのユーザーまたは認証された AWS ユーザーがアクセス可能) ことを確認する必要があります。
+ `Principal`を`""`に設定してポリシーを作成しないでください。
+ ワイルドカード (`*`) を使用しないでください。代わりに、特定のユーザーに名前を付けます。

## 最小特権アクセスの実装
<a name="implement-least-privilege-access"></a>

アクセス許可を付与する場合、アクセス許可を受け取るユーザー、アクセス許可の対象となるキュー、およびこれらのキューに対して許可する特定の APIアクションを決定します。最小権限を実装することは、セキュリティリスクを軽減し、エラーや悪意のあるインテントの影響を軽減するために重要です。

最小特権を付与するスタンダードのセキュリティアドバイスに従ってください。つまり、特定のタスクの実行に必要なアクセス権限のみを付与します。これで、セキュリティポリシーの組み合わせを使用して実装できます。

Amazon SQSはプロデューサー-コンシューマーモデルを使用し、次の3種類のユーザーアカウントアクセスを使用します。
+ **管理者**-キューの作成、変更、削除にアクセスします。管理者は、キューポリシーも制御します。
+ **プロデューサー**-キューへのメッセージの送信にアクセスします。
+ **コンシューマー**-キューからのメッセージの受信および削除にアクセスします。

詳細については、次のセクションを参照してください。
+ [Amazon SQSでの Identity and Access Management](security-iam.md)
+ [Amazon SQS (Amazon SQS)、 API のアクセス権限: アクションとリソースのリファレンスについて](sqs-api-permissions-reference.md)
+ [Amazon SQSアクセスポリシー言語を使用したカスタムポリシーの使用](sqs-creating-custom-policies.md)

## Amazon SQS アクセスを必要とするアプリケーションと AWS サービスに IAM ロールを使用する Amazon SQS
<a name="use-iam-roles-for-applications-aws-services-which-require-access"></a>

Amazon EC2 などのアプリケーションや AWS サービスが Amazon SQS キューにアクセスするには、 AWS API リクエストで有効な AWS 認証情報を使用する必要があります。これらの認証情報は自動的にローテーションされないため、 AWS 認証情報をアプリケーションまたは EC2 インスタンスに直接保存しないでください。

IAM ロールを使用して、Amazon SQSにアクセスする必要があるアプリケーションまたはサービスの一時的な認証情報を管理することをおすすめします。ロールを使用する場合、長期的な認証情報 (ユーザー名、パスワード、アクセスキーなど) を EC2 インスタンスや などの AWS サービスに配布する必要はありません AWS Lambda。代わりに、ロールは、アプリケーションが他の AWS リソースを呼び出すときに使用できる一時的なアクセス許可を提供します。

詳細については、「*IAM ユーザーガイド*」の「[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)」および「[ロールの一般的なシナリオ: ユーザー、アプリケーション、およびサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios.html)」を参照してください。

## サーバー側の暗号化を実装する
<a name="implement-server-side-encryption"></a>

データ漏洩の問題を軽減するには、保存時の暗号化を使用して、メッセージを保存する場所とは別の場所に保存されているキーを使用してメッセージを暗号化します。サーバー側の暗号化(SSE)は、保存時のデータ暗号化を提供します。Amazon SQSは、データを保存するときにメッセージレベルで暗号化し、アクセスする際にメッセージを復号します。SSE は で管理されるキーを使用します AWS Key Management Service。リクエストが認証され、お客様がアクセス許可を持っていれば、キューが暗号化されているかどうかに関係なく同じ方法でアクセスできます。

詳細については、「[Amazon SQS での保管中の暗号化](sqs-server-side-encryption.md)」および「[Amazon SQS のキー管理](sqs-key-management.md)」を参照してください。

## 送信時のデータの暗号化を強制する
<a name="enforce-encryption-data-in-transit"></a>

HTTPS(TLS)を使用しない場合、ネットワークベースの攻撃者は、中間者などの攻撃を使用して、ネットワークトラフィックを傍受したり操作することができます。キューポリシーの [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_Boolean](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_Boolean) 条件を使用して、HTTPS(TLS) 経由の暗号化された接続のみを許可し、リクエストに SSL の使用を強制します。

## VPC エンドポイントを使用して Amazon SQSにアクセスすることを検討する場合には
<a name="consider-using-vpc-endpoints-access-sqs"></a>

操作できる必要があるが、インターネットに絶対に公開してはならないキューがある場合は、VPC エンドポイントを使用して、特定の VPC 内のホストへのアクセスのみをキューに入れます。キューポリシーを使用して、特定のAmazon VPC エンドポイントまたは特定のVPCからのキューへのアクセスを制御できます。

Amazon SQS VPC エンドポイントには、メッセージへのアクセスを制御するために、2通りの方法が用意されています。
+ 特定の VPC エンドポイントを通じて許可されるリクエスト、ユーザー、またはグループを管理できます。
+ キューポリシーを使用して、どのVPCまたは VPC エンドポイントがキューにアクセスできるかを制御できます。

詳細については、「[Amazon SQSのAmazon Virtual Private Cloud エンドポイント](sqs-internetwork-traffic-privacy.md#sqs-vpc-endpoints)」および「[Amazon SQS用のAmazon VPCエンドポイントポリシーを作成する](sqs-internetwork-traffic-privacy.md#sqs-vpc-endpoint-policy)」を参照してください。