この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
いわさです。
Amazon SQSではキューとの通信時はデフォルトで暗号化されていますが、保管時の暗号化はオプションです。
この度、AWS Key Management Service(KMS)ではなくSQSが管理する暗号化キーを使う、SSE-SQSが利用出来るようになりました。
従来はサーバーサイド暗号化(SSE)としてAWS Key Management Service(KMS)を使った暗号化のみを選択することが出来ていました。
SSE-SQSを使うとKMSを利用しないため、従来のKMS利用に伴う追加料金が不要になります。
また、鍵の管理も不要になります。
従来はデフォルトキー(SQSマネージドCMK)の場合はキューをクロスアカウントで利用する際に不都合があり個別のCMK管理が必要でしたが、SSE-SQSの場合だともう少しライトに、暗号化しつつアクセスポリシーのみで制御が可能です。
設定方法
マネジメントコンソールからの設定方法
サーバー側の暗号化を有効にすると、SSE-SQSかSSE-KMSからを選択します。
SSE-SQSの場合は選択するのみで良いですが、SSE-KMSの場合はカスタマーマスターキー(CMK)およびデータキー再利用期間を設定します。
CMKはSQSデフォルトのCMKも選択可能で、これらは従来と同様です。
AWS-CLIからの設定方法
キューの作成・更新時にattribute
を指定しますが、その際にSqsManagedSseEnabled
やKmsMasterKeyId
を指定します。
- SSE-SQSの場合
"attribute": {
...
"SqsManagedSseEnabled": "true",
"KmsMasterKeyId": "",
...
}
- SSE-KMSの場合
"attribute": {
...
"SqsManagedSseEnabled": "false",
"KmsMasterKeyId": "alias/aws/sqs",
"KmsDataKeyReusePeriodSeconds": "300",
...
}
アクセスポリシーを設定してクロスアカウントでアクセス
SSE-SQSの場合
キューのアクセスポリシーでクロスアカウントを許可するだけですぐに利用できました。
SSEなSQSキューで、従来はアクセスポリシーとKMSのポリシーとどちらもクロスアカウント設定が必要だったと思いますが、アクセスポリシーのみでよくなりますね。
iwasa.takahito@hoge ~ % aws sqs receive-message --queue-url https://sqs.ap-northeast-1.amazonaws.com/123456789012/hoge-sse-sqs --profile hoge --region ap-northeast-1
{
"Messages": [
{
"MessageId": "900980ce-623a-4f7a-bcd9-d6e7150ef860",
"ReceiptHandle": "AQEB9TcUajOUjEF8F86Ojt...Avzh4GD1tV659BcOnsHlSGt2Ax0==",
"MD5OfBody": "47bce5c74f589f4867dbd57e9ca9f808",
"Body": "aaa"
}
]
}
SSE-KMSの場合
キューのアクセスポリシーのみだと復号化できずに失敗します。
iwasa.takahito@hoge ~ % aws sqs receive-message --queue-url https://sqs.ap-northeast-1.amazonaws.com/123456789012/hoge-sse-customer --profile hoge --region ap-northeast-1
An error occurred (KMS.AccessDeniedException) when calling the ReceiveMessage operation: The ciphertext refers to a customer master key that does not exist, does not exist in this region, or you are not allowed to access. (Service: AWSKMS; Status Code: 400; Error Code: AccessDeniedException; Request ID: d21277c4-c443-4b90-82e5-fe15ea5446ed; Proxy: null)
CMKでクロスアカウントの設定を行ってやる必要があります。
iwasa.takahito@hoge ~ % aws sqs receive-message --queue-url https://sqs.ap-northeast-1.amazonaws.com/123456789012/hoge-sse-customer --profile hoge --region ap-northeast-1
{
"Messages": [
{
"MessageId": "1d956102-c661-4265-87d5-5434e8ffe060",
"ReceiptHandle": "AQEB9TcUajOUjEF8F86Ojt...Avzh4GD1tV659BcOnsHlSGt2Ax0==",
"MD5OfBody": "74b87337454200d4d33f80c4663dc5e5",
"Body": "aaaa"
}
]
}
デメリット
注意点としては、KMSを利用しないのでCloudTrailで復号化の証跡が管理できなくなります。
KMSを利用している場合は誰がいつ復号化したのかを管理することが出来ます。
{
"userIdentity": {
"type": "AWSAccount",
"principalId": "hogehoge",
"accountId": "111111111111",
"invokedBy": "sqs.amazonaws.com"
},
"eventTime": "2021-11-24T20:48:49Z",
"eventSource": "kms.amazonaws.com",
"eventName": "Decrypt",
"awsRegion": "ap-northeast-1",
"sourceIPAddress": "sqs.amazonaws.com",
"userAgent": "sqs.amazonaws.com",
"requestParameters": {
"encryptionContext": {
"aws:sqs:arn": "arn:aws:sqs:ap-northeast-1:222222222222:hoge-sse-customer"
},
"encryptionAlgorithm": "SYMMETRIC_DEFAULT"
},
...
"resources": [
{
"accountId": "222222222222",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:ap-northeast-1:222222222222:key/e9856727-9b12-4924-aeec-1bc42cfb4cf4"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
...
}
また、前述のようにKMSを利用している場合だと、鍵とキューで二段の外部公開制御が出来ていましたが、一段で制御する形になります。
このあたりはS3と同じですが、SQSの場合はキューのアクセスログが無いのでその点も注意が必要です。
SQSのCloudTrailでもSendMessageとReceiveMessageはサポートされていません。
さいごに
本日はSQSの保管時の暗号化における新しいオプションSSE-SQSを紹介しました。
SSE-S3と似たような使い方が出来そうです。
従来までKMSの敷居が少し高くて暗号化を見送っていた方には、嬉しいニュースではないでしょうか。
そういったケースではSSE-SQSを使うシーンが増えてきそうです。追加料金もかからないですし。
一方で、セキュリティ要件・コンプライアンス面からSSE-SQSかSSE-KMSどちらを利用すべきシーンかは見極めて選択する必要があります。