キーの管理 - Amazon Simple Queue Service

キーの管理

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

AWS KMS アクセス許可の設定

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

カスタマー管理の CMK の場合、キーポリシーを設定して、各キュープロデューサーとコンシューマーのアクセス許可を追加する必要があります。これを行うには、CMK キーポリシーでプロデューサーとコンシューマーにユーザーとして名前を付けます。AWS KMS アクセス許可の詳細については、AWS Key Management Service Developer Guideの「AWS KMS リソースとオペレーション」または「AWS KMS API アクセス許可のリファレンス」を参照してください。

または、必要なアクセス許可を IAM ポリシーで指定して、暗号化されたメッセージを作成および消費するプリンシパルにこのポリシーを割り当てます。詳細については、AWS Key Management Service Developer Guideの「AWS KMS での IAM ポリシーの使用」を参照してください。

注記

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

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

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

  1. カスタマー管理の CMK を作成します。詳細については、『AWS Key Management Service Developer Guide』の「キーの作成」を参照してください。

  2. AWS サービスイベントソースが kms:GenerateDataKey および kms:Decrypt API メソッドを使用できるようにするには、CMK キーポリシーに次のステートメントを追加します。

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

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

    イベントソース サービス名
    Amazon CloudWatch Events events.amazonaws.com
    Amazon S3 イベント通知 s3.amazonaws.com
    Amazon SNS トピックのサブスクリプション sns.amazonaws.com
  3. 新しい SSE キューを作成するか、CMK の ARN を使用して既存の SSE キューを設定します。

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

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

データキー再利用期間が終了した場合、プロデューサーによる次回の SendMessage または SendMessageBatch の呼び出しでは、kms:GenerateDataKeykms:Decrypt の呼び出しもトリガーされます。kms:Decrypt の呼び出しでは、新しいデータキーを使用する前に整合性を検証します。したがって、プロデューサーには、カスタマーマスターキー (CMK) に対する 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 アクセス許可の設定

データキー再利用期間が終了した場合、コンシューマーが次回に ReceiveMesssage を呼び出すと、それを使用する前に新しいデータキーの整合性を検証するために、kms:Decrypt の呼び出しもトリガーされます。したがって、コンシューマーには、指定されたキュー内でメッセージを暗号化するために使用されるカスタマーマスターキー (CMK) に対する kms:Decrypt アクセス許可が必要です。キューをデッドレターキューとして使用する場合、コンシューマーには、ソースキュー内でメッセージの暗号化に使用される CMK に対する 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" }] }

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

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

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

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

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

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

AWS KMS コストの見積もり

AWS のコストを予測し、請求内容をより正確に把握するには、Amazon SQS でカスタマーマスターキー (CMK) が使用される頻度を調べることをお勧めします。

注記

コストは下の計算式でかなり正確に予測できますが、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 KMS API コール数の計算 (2 プリンシパル、1 キュー)

この例では、次のように想定しています。

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

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

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

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

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

例 2: AWS KMS API コール数の計算 (複数のプロデューサーとコンシューマー、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 を使用する場合、エラーが発生することがあります。次のリファレンスでは、エラーおよび考えられるトラブルシューティング方法について説明します。