Amazon QuickSight で SPICE データセットの暗号化に KMS のカスタマーマネージドキーが指定出来るようになりました

いわさです。

本日の QuickSight アップデートで SPICE のデータ保存時の暗号化で KMS のカスタマーマネージドキーを指定出来るようになりました。

従来は AWS のマネージドキーを使って SPICE も SPICE 外のデータも暗号化されていましたが、SPICE に関してカスタマーマネージドキーという選択が出来るようになった形です。
これによって、キーの無効化によるアクセス停止、CloudTrail での監査などを行うことが出来るようになります。

設定方法

QuickSight の管理画面に新たに「KMS キー」というメニューが追加されています。

管理ボタンを押すと QuickSight に関連付けられている KMS キーの管理画面へ遷移します。
ここで既存 KMS キーの選択を行うことで QuickSight への関連付け（CreateGrant）を行います。

「キーを作成」ボタンを押すと KMS コンソールへ移動し新規カスタマーマネージドキーを作成することが出来ます。

ちなみに作成キーは QuickSight で利用するために少し条件があります。

詳細は上記ドキュメントに記載されていますが抜粋すると以下です。

• 非対称キータイプはサポートされていない
• QuickSight データセットと同じ AWS アカウント、リージョンである必要がある

作成できたら QuickSight のキー管理画面に戻り、「キー選択」を行いましょう。

選択したキーが一覧に表示されました。
のちほど実際に試しますが、SPICE での使い方としては CMK を明示的に指定するというものはありません。
SPICE 作成時にここで指定したデフォルトキーが使われるという形になります。

本日時点ではカラムサイズを変更出来ないのでウインドウサイズによっては表示されなくなるのですがデフォルト指定したキーには以下のような表示がされます。

データセット作成してみる

さて、デフォルトキーを指定したのでデータセットを作成してみましょう。
お手軽に以下のような CSV アップロードから SPICE を作成しました。

ちなみに公式ドキュメントには以下の記述がありましたが説明書を読まないタイプの私はこれに気づかずファイルアップロードから SPICE を作成して検証しておりました。

• Some features always use QuickSight's default encryption instead of applying SPICE CMK settings:
  • Direct file uploads

ただ、どうやらその場合でもこのあとの挙動を見る限りではカスタマーマネージドキー使われてそうです。
この後の検証は結果はファイルアップロードによって作成された SPICE によるものという点をご承知おきください。

データセットを作成しそのまま適当な分析まで作成しました。

この時点での CloudTrail で以下のような証跡が確認出来ました。

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "AWSService",
        "invokedBy": "quicksight.amazonaws.com"
    },
    "eventTime": "2022-10-27T21:38:26Z",
    "eventSource": "kms.amazonaws.com",
    "eventName": "Decrypt",
    "awsRegion": "ap-northeast-1",
    "sourceIPAddress": "quicksight.amazonaws.com",
    "userAgent": "quicksight.amazonaws.com",
    "requestParameters": {
        "keyId": "arn:aws:kms:ap-northeast-1:123456789012:key/b985da64-421a-42ff-a0c1-090ae543c130",
        "encryptionContext": {
            "aws:quicksight:arn": "arn:aws:quicksight:ap-northeast-1:123456789012:dataset/ec199baa-4496-45e7-98ed-382e3081e25a"
        },
        "encryptionAlgorithm": "SYMMETRIC_DEFAULT"
    },
    "responseElements": null,
    "requestID": "e853ad00-057a-451e-9bf6-2b19fa558b8b",
    "eventID": "9a6ca495-24cd-438b-9321-daf2225a7500",
    "readOnly": true,
    "resources": [
        {
            "accountId": "123456789012",
            "type": "AWS::KMS::Key",
            "ARN": "arn:aws:kms:ap-northeast-1:123456789012:key/b985da64-421a-42ff-a0c1-090ae543c130"
        }
    ],
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "123456789012",
    "sharedEventID": "8ab0e886-6863-4a19-9b67-9f479a0a6c86",
    "vpcEndpointId": "vpce-025c10a9d173babbb",
    "eventCategory": "Management"
}

ポイントとしては QuickSight ユーザーではなく QuickSight サービスから実行されている点と、コンテキストとして対象のデータセット ARN が含まれている点でしょうか。

ちなみに CloudTrail からは上記のように証跡確認が出来るようになりましたが、データセットの管理画面を見ても特にキーに関する情報は見当たりません。

また、ここ数日の AWS CLI のアップデート情報を見る限りでは AWS CLI からデータセットあるいはデータソースから暗号化キー情報を確認出来るコマンドは見当たりませんでした。

既存データセットで見てみる

先程は新規データセットでした。
この KMS デフォルトキー設定は既存のデータセット (SPICE) へは影響しません。
ただし、「フル更新」した場合は新しいキーで暗号化されます。なんと！

以下はカスタマーマネージドキー設定前に作成されていた SPICE モードのデータセットです。
データソースは Athena です。

このデータセットを使った分析を確認したりしましたが、CloudTrail にキー関係の証跡は確認出来ませんでした。
ドキュメントのとおりカスタマーマネージドキーが使われていないと考えて良さそうです。

ここで以下のようにフル更新してみましょう。

その後分析へアクセスしてみると先程のデータセットと同様に証跡を確認することが出来るようになりました。
SPICE のフル更新によってデフォルトキー設定したカスタマーマネージドキーが使われるようになったことが確認出来ます。

{
    "eventVersion": "1.08",
    "userIdentity": {
        "type": "AWSService",
        "invokedBy": "quicksight.amazonaws.com"
    },
    "eventTime": "2022-10-27T22:01:03Z",
    "eventSource": "kms.amazonaws.com",
    "eventName": "GenerateDataKey",
    "awsRegion": "ap-northeast-1",
    "sourceIPAddress": "quicksight.amazonaws.com",
    "userAgent": "quicksight.amazonaws.com",
    "requestParameters": {
        "keyId": "arn:aws:kms:ap-northeast-1:123456789012:key/b985da64-421a-42ff-a0c1-090ae543c130",
        "encryptionContext": {
            "aws:quicksight:arn": "arn:aws:quicksight:ap-northeast-1:123456789012:dataset/5006d23b-4e1a-4123-a950-80bfa7c758f7"
        },
        "numberOfBytes": 32
    },
    "responseElements": null,
    "requestID": "4311cf71-c066-4b4d-8205-6bd376e0b8cd",
    "eventID": "2c38d400-f748-48c5-b957-0406b10fabbf",
    "readOnly": true,
    "resources": [
        {
            "accountId": "123456789012",
            "type": "AWS::KMS::Key",
            "ARN": "arn:aws:kms:ap-northeast-1:123456789012:key/b985da64-421a-42ff-a0c1-090ae543c130"
        }
    ],
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "123456789012",
    "sharedEventID": "aaaa4faf-6b8b-4508-b9aa-db705475dcd7",
    "vpcEndpointId": "vpce-025c10a9d173babbb",
    "eventCategory": "Management"
}

キーの無効化

キーを無効化することで暗号化された SPICE へアクセス出来なくすることが出来ます。

分析へアクセスしてみると以下のような表示となりました。

The customer managed key associated with this data could not be accessed.

キーを QuickSight から解除

先程は KMS コンソールからキーの無効化を行いました。
キーを有効化したままで QuickSight のキー管理画面から関連付けを解除するとどうなるか試してみましょう。

以下のように対象キーを削除します。

「このキーで現在暗号化されている SPICE データセットは、このキーによって暗号化されたままになります」

なるほど。

暗号化後に分析へアクセスしてみましたがアクセス可能なままでした。

SPICE 自動更新でもカレントのデフォルトキーが毎度使われるので注意

KMS キーを無効化あるいは削除することで SPICE へのアクセスが出来なく事が先程確認出来ました。
一点注意点ですが、SPICE を更新するとその時点のデフォルトキーで暗号化されて新しく作成されるような動きになります。

そのため、以下のように KMS キーを無効化してよしよしと思っていても、有効な KMS キーがデフォルトキーに指定し直されている状態で SPICE の自動更新が走ると、再びアクセス出来る状態になります。

以下で SPICE 自動更新が実行されています。

アクセス出来ました！

逆にいうとキーを無効化・削除しても SPICE が更新可能であれば再び分析やデータセットにアクセス出来るようになるということです。
アクセス出来ないようにしたいという用途であれば、SPICE の自動更新停止やデータセット削除まで併せて行ったほうが良さそうですね。

料金

QuickSight としての追加料金は発生しませんが KMS の利用料金が発生します。

さいごに

本日は Amazon QuickSight で SPICE データセットの暗号化に KMS のカスタマーマネージドキーが指定出来るようになったので使ってみました。

今までコンプライアンス要件としてキーの管理やデータ破棄の問題で QuickSight の利用を見送らざるをえなかった場合などは今回のアップデートで利用出来るようになるケースが出るかもしれませんので確認してみてください。

ドキュメントに記載のとおり、今回のアップデートは SPICE に対するものでその他のメタデータやクエリキャッシュなどは従来と同様です。その点もご注意ください。

また、重要な点として KMS へのアクセスは IAM ユーザーではなく QuickSight サービスプリンシパルで行われます。そのため特定のリーダーのみを許可させるような用途での使い方も出来ませんので、その点もご注意ください。