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

こんにちは、洲崎です。
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で異なるカスタマーマネージドキーを利用していても対応可能です。

参考

最後に

Amazon Connect→Kinesis Data Streams→S3で、KMSのカスタマーマネージドキーを利用した場合に気をつけるポイントを記載しました。
KMSの権限周りに慣れてない方がいましたら参考にいただけますと幸いです。

ではまた！コンサルティング部の洲崎でした。