キーの管理 - Amazon Simple Queue Service

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

キーの管理

Amazon SQS は、AWS Key Management Service (KMS) と統合してサーバー側の暗号化 (SSE) 用に KMS キーを管理します。SSE 情報およびキー管理の定義については、「保管中の暗号化」をご参照ください。Amazon SQS は KMS キーでメッセージを暗号化および復号するデータキーを検証および保護します。以下のセクションは Amazon SQS サービスの KMS キーとデータキーの操作について説明します。

AWS KMS 許可を設定する

すべての KMS キーにはキーポリシーが必要です。Amazon SQS の AWS マネージド KMS キーにおけるキーポリシーを変更することはできないことにご留意ください。この KMS キーのポリシーには、暗号化されたキューを使用するためのアカウント内 (Amazon SQS の使用が承認されているもの) にあるすべてのプリンシパルのアクセス許可が含まれています。

カスタマーマネージド KMS キーの場合、各キュープロデューサーおよびコンシューマーの許可を追加するため、キーポリシーを設定する必要があります。これを行うため、KMS キーポリシー内にプロデューサーおよびコンシューマーをユーザーとして名前を付けます。AWS KMS 許可の詳しい情報については、AWS Key Management Service デベロッパーガイドAWS KMS リソースおよび運用または AWS KMS API 許可リファレンスを参照してください。

または、必要な許可をIAM ポリシーで指定して、暗号化されたメッセージを作成および使用するプリンシパルにこのポリシーを割り当てます。詳しい情報については、AWS Key Management Service デベロッパーガイドAWS KMS で IAM ポリシーの使用をご参照ください。

注記

Amazon SQS と送受信するためにグローバル許可が設定可能ですが、AWS KMS は IAM ポリシー Resource セクションの特定リージョンで KMS キーの完全 ARN を明示的に指定することが求められます。

AWS のサービスのKMSアクセス許可の設定

いくつかの AWS サービスは、Amazon SQS キューにイベントを送信できるイベントソースとして機能します。これらのイベントソースが暗号化キューと動作できるようにする場合、カスタマーマネージド KMS キーを作成して、サービスで必要な AWS KMS API メソッドを使用するためにキーポリシーに許可を追加する必要があります。アクセス許可を設定するには、次の手順を実行します。

  1. カスタマーマネージド KMS キーを作成。詳細については、AWS Key Management Service デベロッパーガイドの「キーの作成」を参照してください。

  2. にを許可するにはAWSサービスイベントソースを使用してkms:GenerateDataKeyそしてkms:DecryptAPI メソッドで、KMS キーポリシーに次のポリシーステートメントを追加します。

    { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Service": "service.amazonaws.com" }, "Action": [ "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": "*" }] }

    上記の例の「Service」をイベント出典のサービス名に置き換えます。イベントソースには、次のサービスが含まれます。

    イベントソース サービス名
    アマゾン CloudWatch イベント events.amazonaws.com
    Amazon S3イベント通知について s3.amazonaws.com
    Amazon SNS トピックのサブスクリプション sns.amazonaws.com
  3. 既存の SSE キューを構成するKMS キーの ARN を使用します。

  4. 暗号化されたキューのARNをイベント出典に追加します。

プロデューサーのKMSアクセス許可の設定

データキー再利用期間が終了した場合、プロデューサーによる次回のSendMessageまたはSendMessageBatchの呼び出しでは、kms:GenerateDataKeykms:Decryptの呼び出しもトリガーされます。kms:Decryptの呼び出しでは、新しいデータキーを使用する前に整合性を検証します。したがって、プロデューサーは KMS キーの kms:GenerateDataKey および kms:Decrypt 許可が必要です。

次のステートメントをプロデューサーの IAMポリシーに追加します。キーリソースとキューリソースには正しい ARN値を使用してください。

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": "arn:aws:kms:us-east-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab" }, { "Effect": "Allow", "Action": [ "sqs:SendMessage" ], "Resource": "arn:aws:sqs:*:123456789012:MyQueue" }] }

コンシューマーのKMSアクセス許可の設定

データキー再利用期間が終了した場合、コンシューマーが次回に ReceiveMessage を呼び出すと、それを使用する前に新しいデータキーの整合性を検証するために、kms:Decrypt の呼び出しもトリガーされます。したがって、コンシューマーは指定されたキューのメッセージの暗号化に使用される KMS キーへの kms:Decrypt 許可が必要です。キューがデッドレターキューとして機能する場合、コンシューマーはソースキューのメッセージの暗号化に使用される KMS キーへの kms:Decrypt 許可も必要です。次のステートメントをコンシューマーの IAM ポリシーに追加します。キーリソースとキューリソースには正しい ARN値を使用してください。

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Resource": "arn:aws:kms:us-east-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab" }, { "Effect": "Allow", "Action": [ "sqs:ReceiveMessage" ], "Resource": "arn:aws:sqs:*:123456789012:MyQueue" }] }

混乱した使節の保護で KMS 許可を設定

キーポリシーステートメントのプリンシパルが AWS サービスプリンシパルの場合、aws:SourceArn または aws:SourceAccount のグローバル条件キーを使用して混乱した使節問題から保護できます。これらの条件キーを使用する場合、暗号化されているリソースの Amazon リソースネーム (ARN) の値を設定します。リソースの ARN が不明の場合は、代わりに aws:SourceAccount を使用してください。

この KMS キーポリシーでは、アカウント 111122223333 が保有されたサービスの特定リソースは、Decrypt および GenerateDataKey アクションにおいて KMS を呼び出すことが許可されます。これは Amazon SQS の SSE 使用中に発生します。

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Service": "<replaceable>service</replaceable>.amazonaws.com" }, "Action": [ "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": "*", "Condition": { "ArnEquals": { "aws:SourceArn": [ "arn:aws:service::111122223333:resource" ] } } }] }

SSE を有効にした Amazon SQS キューを使用する場合、以下のサービスが aws:SourceArn をサポートします:

  • Amazon SNS

  • Amazon S3

  • CloudWatch イベント

  • AWS Lambda

  • CodeBuild

  • Amazon Connect Customer Profiles

  • AWS オートスケーリング

  • Amazon Chime

データキー再利用期間について

データキー再利用期間は、Amazon SQSが同じデータキーを再利用するための最大期間を定義します。データキー再利用期間が終了すると、Amazon SQSは新しいデータキーを生成します。再利用期間については、次のガイドラインに注意してください。

  • 再利用期間を短くする方がセキュリティを強化できますが、結果としてAWS KMSへの呼び出しが多くなり、無料利用枠を超える料金が発生することがあります。

  • データキーは暗号化用と復号化用に別々にキャッシュされますが、再利用期間はデータキーの両方のコピーに適用されます。

  • データキー再利用期間が終了すると、SendMessageまたはSendMessageBatchの次の呼び出しでは、通常AWS KMSGenerateDataKeyメソッドへの呼び出しをトリガーして新しいデータキーを取得します。また、次にSendMessage およびReceiveMessageを呼び出すと、データキーを使用する前にAWS KMSDecryptの呼び出しがトリガーされ、データキーの整合性が検証されます。

  • プリンシパル (AWS アカウントまたはIAM ユーザー) は、データキーを共有しません (固有のプリンシパルから送信されたメッセージには、常に固有のデータキーが設定されます)。このため、AWS KMSへの呼び出しのボリュームは、データキー再利用期間中に使用されている一意のプリンシパル数の倍数になります。

AWS KMSコストの見積もり

コストを予測して AWS の請求内容をより正確に把握するため、Amazon SQS が KMS キーを使用する頻度を調べることをお勧めします。

注記

以下の計算式によってかなり正確にコストを予測できますが、Amazon SQS の分散性によって実際のコストが高くなる可能性があります。

APIリクエスト(R) キューごとの数を計算する場合は、次の式を使用します。

R = B / D * (2 * P + C)

B は請求期間(秒)です。

D は、データキー再利用期間(秒)です。

Pメインの生産数は Amazon SQS キューに送信されます。

C は、Amazon SQSキューから受信する、コンシューマー側のプリンシパル数です。

重要

一般的に、プロデューサー側プリンシパルで発生するコストはコンシューマー側プリンシパルの倍程度になります。詳細については、「データキー再利用期間について」を参照してください。

プロデューサーとコンシューマーのIAMユーザーが異なる場合、コストは増加します。

以下は計算の例です。正確な料金については、「AWS Key Management Service 料金表」を参照してください。

例 1: 数を計算するAWS KMSAPI コールで 2 プリンシパル、1 キュー

この例では、以下を想定しています。

  • 請求期間は1月1日から31日(2,678,400秒)です。

  • データキー再利用期間は5分(300秒)に設定されています。

  • キューの数は 1 つです。

  • プロデューサー側プリンシパルが1つ、コンシューマー側プリンシパルが1つあります。

2,678,400 / 300 * (2 * 1 + 1) = 26,784

例 2: 数を計算するAWS KMSAPI コールは、複数のプロデューサーとコンシューマー、2 キュー

この例では、以下を想定しています。

  • 請求期間は2月1日から28日(2,419,200秒) です。

  • データキー再利用期間は24時間(86,400秒)に設定されています。

  • キューの数は2つです。

  • 1つ目のキューのプロデューサー側プリンシパルは3つ、コンシューマー側プリンシパルは1つです。

  • 2つ目のキューのプロデューサー側プリンシパルは5つ、コンシューマー側プリンシパルは2つです。

(2,419,200 / 86,400 * (2 * 3 + 1)) + (2,419,200 / 86,400 * (2 * 5 + 2)) = 532

AWS KMS エラー

Amazon SQSおよびAWS KMSを使用する際、エラーが発生することがあります。次のリファレンスでは、エラーおよび考えられるトラブルシューティング方法について説明します。