Snowflakeの暗号化キー管理を理解する¶
このトピックでは、Snowflakeが管理するキー、顧客が管理するキーに関連する概念について説明します。
このトピックの内容:
概要¶
Snowflakeは、顧客データを保護するためにデータ暗号化キーを管理します。この管理は、顧客が介入することなく自動的に行われます。
お客様は、Snowflakeアカウントをホストするクラウドプラットフォームのキー管理サービスを使用して、独自の追加暗号化キーを管理することもできます。
有効にすると、Snowflakeが管理するキーと顧客が管理するキーの組み合わせにより、Snowflakeの顧客データを保護するための 複合マスターキー が作成されます。これは Tri-Secret Secure と呼ばれます。
Snowflakeが管理するキー¶
Snowflakeの顧客データは、デフォルトですべて暗号化されています。Snowflakeは、クラウドプロバイダーがホストするハードウェア セキュリティ モジュールに根ざした階層キーモデルによる強力な AES 暗号化を使用しています。
キーはSnowflakeサービスによって定期的に自動的にローテーションされ、顧客データは定期的に自動的に再暗号化（「キー更新」）されます。顧客データの暗号化とキー管理は構成も管理も不要です。
階層キーモデル¶
階層キーモデルは、Snowflakeの暗号化キー管理のフレームワークを提供します。階層はキーの複数のレイヤーで構成され、キーの上位レイヤー（親キー）はそれぞれ下のレイヤー（子キー）を暗号化します。セキュリティ用語では、すべての子キーを暗号化する親キーは「ラップ」と呼ばれます。
Snowflakeの階層キーモデルは、4つのレベルのキーで構成されています。
ルートキー
アカウントマスターキー
テーブルマスターキー
ファイルキー
次の図に示すように、各顧客アカウントには、アカウントレベル、テーブルレベル、およびファイルレベルのキーにおいて個別のキー階層があります。
Snowflakeのようなマルチテナントクラウドサービスでは、階層キーモデルにより、個別のアカウントマスターキーを使用してすべてのアカウントが分離されます。顧客データのストレージを分離する アクセス制御モデル に加えて、階層キーモデルはアカウント分離の別の層を提供します。
階層キーモデルは、キーの各層の範囲を縮小します。例えば、テーブルマスターキーは単一のテーブルを暗号化します。ファイルキーは、単一のファイルを暗号化します。階層キーモデリングは、各キーが保護する顧客データの量と使用可能な期間を制限します。
暗号化キーのローテーション¶
Snowflakeが管理するキー階層内のキーは、30日以上経過するとSnowflakeによって自動的にローテーションされます。アクティブなキーは廃止され、新しいキーが作成されます。廃止されたキーが不要になったとSnowflakeが判断すると、キーは自動的に破棄されます。アクティビティ化されると、キーは顧客データの暗号化に使用され、顧客が使用できるようになります。引退した場合、キーは顧客データの復号化にのみ使用され、データへのアクセスにのみ利用可能となります。
キー階層で子キーをラップする場合、または顧客データをテーブルに挿入する場合、データの暗号化には現在のアクティブなキーのみが使用されます。キーが破棄されると、暗号化または復号化には使用されません。定期的なキーローテーションは、キーのライフサイクルを限られた期間に制限します。
次の画像は、3か月間における1つのテーブルマスターキー（TMK）のキーローテーションを示しています。
TMK ローテーションは次のように機能します。
TMK のバージョン1は4月にアクティブになります。4月にこのテーブルに挿入された顧客データは、 TMK v1で保護されています。
5月にこの TMK はローテートされます。 TMK v1は廃止され、完全にランダムな新しいキー、 TMK v2が作成されます。TMK v1は現在、4月からの顧客データの復号化にのみ使用されています。テーブルに挿入された新しい顧客データは、 TMK v2 を使用して暗号化されます。
6月に TMK は再びローテートされます。TMK v2は廃止され、新しい TMK v3が作成されます。TMK v1は4月の顧客データの暗号化解除に、 TMK v2は5月の顧客データの暗号化解除に、 TMK v3は6月にテーブルに挿入された新しい顧客データの暗号化および暗号化解除に使用されます。
前述のとおり、キー・ローテーションは、顧客データの暗号化にキーがアクティブに使用される期間を制限します。階層的なデータ・モデリングとともに、キー・ローテーションは、キー・バージョンが保護する顧客データの量をさらに制限します。キーの有効期間の制限は、セキュリティを強化するためにアメリカ国立標準技術研究所（NIST） の推奨事項です。
定期的なキー更新¶
このセクションでは、アカウント鍵およびテーブル・マスター鍵のライフサイクルについて説明します。 暗号化キー・ローテーション では、期間ごとにアクティブなキーを新しいキーに置き換え、古いキーを破棄するキー・ローテーションについて説明します。定期的なデータのキー更新により、ライフサイクルが完了します。
キーのローテーションにより、キーはアクティブな状態から廃止状態に確実に転送されますが、キー更新により、キーは廃止状態から破棄状態になります。
定期的なキー更新が有効になっている場合、テーブルの暗号化キーが1年以上経過すると、Snowflakeは自動的に新しい暗号化キーを作成し、新しいキーを使用して、以前に暗号化キーで保護されていたすべての顧客データを再暗号化します。新しいキーは、今後のテーブルデータの復号化に使用されます。
注釈
Enterprise Editionアカウントの場合、ユーザーは ACCOUNTADMIN ロール（つまり、アカウント管理者）を持っている場合、 ALTER ACCOUNT および PERIODIC_DATA_REKEYING パラメーターを使用してキー更新を有効化できます。
ALTER ACCOUNT SET ENABLE_TRI_SECRET_AND_REKEY_OPT_OUT_FOR_IMAGE_REPOSITORY=True; ALTER ACCOUNT SET PERIODIC_DATA_REKEYING = true;
これにより、 Tri-Secret Secure が有効になりますが、Snowparkの画像リポジトリに保存されている画像に追加のセキュリティは適用されません。
次の図は、単一のテーブルに対する TMK の定期的なキー更新を示しています。
定期的なキー更新は次のように機能します。
翌年の4月、TMK v1が1年間廃止された後、完全に新しいランダムキーを使用してキーが更新されます（第2世代）。
TMK v1 generation 1 で保護された顧客データファイルは、 TMK v1 generation 2 で復号化され、再暗号化されます。それ以上の目的がないため、TMK v1の第1世代は破棄されます。
5月に、SnowflakeはTMK v2で保護されたテーブルデータに対して同じキー更新プロセスを実行するという
このようになります。
この例では、キーのライフサイクルは1年間の合計期間に制限されています。
キー更新は、NIST の推奨事項に従って、受信者の使用にキーが使用される合計期間を制限します。さらに、顧客データをキー更新する際、Snowflakeは暗号化キーサイズを大きくし、前回のキー生成以降に標準化された可能性のある、より優れた暗号化アルゴリズムを利用することができます。
Snowflakeは、現在実行中の顧客のワークロードに影響を与えることなく、顧客のデータファイルをオンラインでバックグラウンドでキー更新します。キー更新された顧客データは、いつでも利用可能です。データ更新のためにサービスを停止する必要はなく、ワークロードのパフォーマンスにも影響はありません。この利点は、Snowflakeのストレージとコンピューティングリソースを分離するアーキテクチャの直接的な結果によるものです。
注釈
Snowflakeアカウントで 定期的なキー更新 の使用が有効になっている場合は、 ハイブリッドテーブル は使用できません。アカウントで定期的なキー更新が有効になっており、ハイブリッドテーブルを使用する場合は、 ALTER ACCOUNT コマンドを使用して PERIODIC_DATA_REKEYING パラメーターを FALSE に設定する必要があります。
キー更新がTime TravelとFail-safeに与える影響¶
Time Travel および Fail-safe の保持期間は、キー更新の影響を受けません。ただし、Fail-safeでの顧客データのキー更新には、追加ストレージ料金が発生します（次項参照）。
キー更新のストレージ使用率への影響¶
Snowflake のお客様は、キー更新されたお客様のデータファイルを Fail-safe で保護するための追加ストレージをに請求 されます。これらのファイルについては、7日間のFail-safe保護が課金されます。
つまり、例えば、Amazon S3上の古いキーの顧客データファイルは既にFail-safeで保護されており、Amazon S3上の新しいキーの顧客データファイルもFail-safeに追加され、2回目のチャージが発生しますが、これは7日間のみです。
ハードウェアセキュリティモジュール¶
Snowflakeは、クラウドホスティングされたハードウェア セキュリティ モジュール (HSMs) を利用して、キーのストレージと使用の安全性を確保しています。各クラウドプラットフォームには異なる HSM サービスがあり、それがSnowflakeが各プラットフォームで HSM サービスを使用する方法に影響を与えます。
AWS とAzureでは、Snowflakeは HSM を使用してルートキーを作成し、格納します。
Google Cloudでは、 HSM サービスはGoogle Cloud KMS （キー管理サービス） API を通じて利用できます。SnowflakeはGoogle Cloud KMS を使用して、マルチテナント HSM パーティションのルートキーを作成し、格納します。
すべてのクラウドプラットフォームとキー階層内にあるすべてのキーの場合、 HSM に格納されているキーは、階層内のキーをラップ解除するために使用されます。たとえば、テーブルマスターキーを復号するには、 HSM にあるキーがアカウントマスターキーをラップ解除します。このプロセスは HSM で発生します。このプロセスが完了すると、ソフトウェア操作によってテーブルマスターキーとアカウントマスターキーが復号化されます。
次の図は、 HSM と、アカウント・マスター・キー、テーブル・マスター・キー、ファイル・キーの関係を示しています。
顧客が管理するキー¶
顧客マネージドキー (CMK) は、顧客が、顧客のSnowflakeアカウントをホストするクラウドプロバイダーのキー管理サービスに保持するマスター暗号化キーです。各プラットフォームの主要な管理サービスは次のとおりです。
AWS: AWS キー管理サービス（KMS）
Google Cloud： クラウドキー管理サービス（クラウド KMS）
Microsoft Azure: Azure Key Vault
その後、 CMK をSnowflakeが管理するキーと組み合わせて、複合マスターキーを作成できます。これが発生すると、Snowflakeはこれを Tri-Secret Secure と呼びます。
Snowflakeアカウントでこれらのシステム関数を呼び出して、キーに関する情報を取得できます。
Microsoft Azure: SYSTEM$GET_CMK_AKV_CONSENT_URL
Google Cloud: SYSTEM$GET_GCP_KMS_CMK_GRANT_ACCESS_CMD
重要
Snowflakeは、顧客管理キーのキーローテーションをサポートしておらず、顧客管理キーに自動キーローテーションポリシーを実装することを推奨していません。
この推奨の理由は、キーのローテーションにより、ローテーションされたキーが削除された場合、Snowflakeはデータを復号化できないため、顧客データの損失につながる可能性があるためです。詳細情報については、 Tri-Secret Secure を参照してください。
Snowflakeは、次をサポートしています。
クラウドサービスプロバイダーで自動キーローテーションを構成する。 キーローテーションを構成すると、更新された暗号化マテリアルを含む同じ CMK の新しいバージョンが作成されます。Snowflakeでアクションを行わなくても、クラウドプロバイダー固有のキーローテーション機能を使用して、自動キーローテーションを有効にすることができます。CMK のローテーション後、Snowflakeは既存のキーバージョンを使用して既存のデータを保護します。
重要
クラウドプロバイダーが何であろうと、古いバージョンの CMK に対して権限を 削除 したり、変更または取り消したりしないでください。ローテーションしたキーを削除すると、データが失われる可能性があります。Snowflakeは、削除されたキーで暗号化されたデータを復号化することはできません。
Snowflakeアカウントがサポートされるクラウドプラットフォームで、顧客が管理するキーの自動キーローテーションを構成することについては、以下をご参照ください：
Tri-Secret Secure （TSS） で使用される CMK を手動で変更する。 TSSの CMK を変更するには、新しい CMK を作成して自己登録し、 TSS を更新して使用する必要があります。 Tri-Secret Secure の自己登録手順に従い、 Snowflake Support に問い合わせて、キー変更を調整してください。
重要
Snowflakeサポート担当者が安全であると確認するまで、現在の CMK へのアクセスを取り消したり、削除したりしないでください。
顧客管理キーの利点¶
顧客管理キーの利点は次のとおりです。
- 顧客データアクセスの制御:
キー管理サービスではマスターキーを完全に管理することができ、Snowflakeでは顧客データを管理することができます。Snowflakeアカウントに保存されたデータを復号化するには、このキーをリリースする必要があります。
- 顧客データ流出によるアクセス不能:
セキュリティ侵害が発生した場合は、キーへのアクセスを無効にして、Snowflakeアカウントで実行されているすべてのデータ操作を停止できます。
- 顧客データライフサイクルのオーナーシップ:
顧客が管理するキーを使用して、データ保護要件をビジネスプロセスと整合させることができます。キーを明示的に管理することで、作成から削除まで、顧客データのライフサイクル全体にわたって安全策を講じることができます。
顧客管理キーの重要な要件¶
顧客が管理するキーには、セキュリティ上の大きな利点がありますが、マスターキーを保護するために、 継続的に 従わなければならない重要で基本的な要件もあります。
- 守秘義務:
常にキーの安全性と機密性を保つ必要があります。
- 整合性:
キーが不適切な変更または削除から保護されていることを確認する必要があります。
- 可用性:
クエリを実行してデータにアクセスするには、Snowflakeでキーを継続的に利用できるようにする必要があります。
設計上、無効なキーまたは使用できないキーがあると、Snowflakeで有効なキーが再び使用可能になるまで、Snowflakeデータ操作が中断されます。
Snowflakeは、ネットワーク通信障害などの一般的な問題に起因する一時的な可用性問題（最大10分）に対処できるように設計されています。10分後、キーが使用できない場合、Snowflakeアカウントのすべてのデータ操作が完全に停止します。キーへのアクセスが復元されると、データ操作を再度開始できます。
これらの要件を順守しないと、データに 一時的にアクセスできない から、 永続的に無効 になるまで、データの整合性が著しく危険にさらされる可能性があります。加えて、Snowflakeでは、発生するサードパーティの問題や、キーを維持する過程で組織によって引き起こされる管理上の問題について責任を負いません。
例えば、キー管理サービスの問題が原因でキーが使用できなくなった場合、データ操作が影響を受けます。このような問題は、お客様とキー管理サービスのこのサポートチームとの間で解決する必要があります。同様に、キーが改ざんまたは破壊された場合は、キーが復元されるまで、Snowflakeアカウント内のすべての既存データが読み取り不能になります。