Amazon Connect→Kinesis Data Streams→S3構成におけるカスタマーマネージドキーを用いた暗号化について

Amazon Connect→Kinesis Data Streams→S3で、KMSのカスタマーマネージドキーを利用する際に気をつけるポイント

#Amazon Connect

#Amazon Data Firehose

#Kinesis Data Streams

#AWS Key Management Service（KMS）

#Amazon S3

洲崎義人

2023.02.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、洲崎です。
Amazon Connect→Kinesis Data Streams→S3で、KMSのカスタマーマネージドキーを利用した際にハマるポイントがあったので紹介します。

Amazon Connectのログ分析

Amazon Connectのログ分析を行う際、データストリーミングを有効化することでCTR(問い合わせ追跡レコード)やエージェントイベントを出力することができます。
CTRは1通話毎に作成され、対応したエージェント・顧客電話番号・通話開始時間・通話終了時間等の情報が出力されます。
エージェントイベントはエージェントのログイン・ログアウト・ステータスの変更等の情報がリアルタイムで出力されます。
どちらもKinesis Data Streams(CTRの場合はFirehoseも)経由で出力することができます。
これらの情報は個人情報が含まる為、会社によっては独自のカスタマーマネージドキーで暗号化したいといったケースもあるかと思います。

検証構成

今回はCTRに絞って、以下の構成で暗号化の流れを検証します。

いきなりまとめ

Kinesis Data Streamsをカスタマーマネージドキーで暗号化する場合、Amazon Connectの通話記録 or エクスポートされたレポートの暗号化キーと合わせる必要がある
Kinesis Data StreamsとS3でカスタマーマネージドキーが異なる場合、S3側のKMSのキーポリシーで許可する必要がある

Amazon ConnectとKinesis Data Streamsの暗号化

Amazon ConnectからKinesis Data Streamsを連携する際、下の流れで行います。

Kinesis Data Streamsの作成・暗号化
Amazon ConnectのデータストリーミングからKinesis Data Streamsを指定

Kinesis Data Streamsでカスタマーマネージドキーを利用する場合、そのままだとAmazon Connect側でkms:GenerateDataKeyを呼び出せず、Amazon ConnectはKinesis Data Streamsにデータを流すことができません。
対応策として、データストレージにある通話記録・またはエクスポートされたレポートにKinesis Data Streamsと同じキーを指定する必要があります。

NG例

Kinesis Data Streams側
Kinesis Data Streamsのカスタマーマネージドキーをkms-data-streamsにします。

Amazon Connect側
Amazon Connectのデータストレージの暗号化を通話記録・エクスポートされたレポート共に、test-20230220にします。

この場合、Amazon Connectがtest-20230220の暗号化キーしか解決をすることができず、kms-data-streamsが分からない為、Data Streamsに流すことができません。

OK例

Amazon Connect側で片方でもいいので、カスタマーマネージドキーをData Streamsのキー(今回はkms-data-streams)と合わせます。
例えば、通話記録のキーをkms-data-streamsに変更することで、Data Streamsにデータを流すことができます。

もしくは、Data Streams側のカスタマーマネージドキーをAmazon Connectの通話記録・エクスポートに合わせる形でも暗号化キーを解決できます。

参考

Kinesis Data StreamsとS3で暗号化キーが異なるケース

Kinesis Data StreamsとS3で暗号化キーが異なるケースです。
Amazon Connectに設定できるデータストリーミングは1つのみの為、データ出力の宛先が複数ある場合、FirehoseやLambdaを利用して振り分ける必要があります。
その際、赤枠で囲っているKinesis Data Streamsと、保存するS3で異なるキーを利用するケースが発生する可能性があります。

この件は、Amazon Connectに限った話ではないですが、備忘録までに記載します。

Kinesis Data Firehose IAMロールのポリシー

Kinesis Data FirehoseのIAMロールのポリシーを確認します。
"Statement"の中にKinesis Data Streamsにアタッチしているキーのkms:Decrypt権限が必要です。
※デフォルトでFirehoseのIAMロールを作成した際には権限付与されています。

        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "kms:Decrypt",
            "Resource": [
                "<Kinesis Data StreamsにアタッチしているKMS カスタマーマネージドキーのARN>"
            ],
            "Condition": {
                "StringEquals": {
                    "kms:ViaService": "kinesis.ap-northeast-1.amazonaws.com"
                },
                "StringLike": {
                    "kms:EncryptionContext:aws:kinesis:arn": "<Kinesis Data StreamsのARN>"
                }
            }
        }

KMSのキーポリシー追記

先ほどの図で、Kinesis Data StreamsとS3でキーが異なる場合、S3にアタッチしているカスタマーマネージドキーのキーポリシーの修正が必要になります。

        {
            "Sid": "Allow Kinesis Data Firehose to use the key",
            "Effect": "Allow",
            "Principal": {
                "AWS": "<Kinesis Data Firehose IAMロールのARN>"
            },
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "kms:DescribeKey"
            ],
            "Resource": "<S3にアタッチしているKMS カスタマーマネージドキーのARN>"
        }
    ]
}

これで、Kinesis Data StreamsとS3で異なるカスタマーマネージドキーを利用していても対応可能です。

参考