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は自動的に新しい暗号化キーを作成し、新しいキーを使用して廃止されたキーによって以前に保護されたすべてのデータを再暗号化します。新しいキーは、今後のテーブルデータの復号化に使用されます。

次の図は、単一のテーブルに対する TMK の定期的なキー更新を示しています。

定期的なキー更新は次のように機能します。

• 翌年の4月、TMK v1が1年間廃止された後、完全に新しいランダムキーを使用してキーが更新されます（第2世代）。

  TMK v1の第1世代で保護されたデータファイルは、TMK v1の第2世代を使用して復号化および再暗号化されます。それ以上の目的がないため、TMK v1の第1世代は破棄されます。

• 5月に、SnowflakeはTMK v2で保護されたテーブルデータに対して同じキー更新プロセスを実行するという

• このようになります。

この例では、キーのライフサイクルは1年間の合計期間に制限されています。

キー更新は、NIST の推奨事項に従って、受信者の使用にキーが使用される合計期間を制限します。さらに、Snowflakeはデータのキー更新時に、暗号化キーのサイズを増やし、以前のキー生成が行われてから標準化された可能性のあるより良い暗号化アルゴリズムを利用できます。

そのため、キー更新により、新旧のすべての顧客データが最新のセキュリティテクノロジーで暗号化されます。

Snowflakeは、現在実行中の顧客のワークロードに影響を与えることなく、バックグラウンドでオンラインによりデータファイルのキーを更新します。キー更新中のデータは常に利用可能です。データのキーを更新するためにサービスのダウンタイムは必要ありません。また、ワークロードにパフォーマンスの影響はありません。この利点は、Snowflakeのストレージとコンピューティングリソースを分離するアーキテクチャの直接的な結果によるものです。

ハードウェアセキュリティモジュール¶

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、アカウントマスターキー、テーブルマスターキー、およびファイルキーの関係を示しています。

顧客管理キーの利点¶

顧客管理キーの利点は次のとおりです。

データアクセスの制御:

キー管理サービスのマスターキー、つまりSnowflakeのデータを包括的に制御できます。このキーをリリースしないと、Snowflakeアカウントに保存されているデータを復号化することはできません。

データ侵害のためにアクセスを無効化する:

セキュリティ侵害が発生した場合は、キーへのアクセスを無効にして、Snowflakeアカウントで実行されているすべてのデータ操作を停止できます。

データライフサイクルの所有権:

顧客が管理するキーを使用して、データ保護要件をビジネスプロセスと整合させることができます。キーを明示的に制御することにより、作成から削除まで、データのライフサイクル全体で保護が提供されます。

顧客管理キーの重要な要件¶

顧客が管理するキーには、セキュリティ上の大きな利点がありますが、マスターキーを保護するために、 継続的に 従わなければならない重要で基本的な要件もあります。

守秘義務:

常にキーの安全性と機密性を保つ必要があります。

整合性:

キーが不適切な変更または削除から保護されていることを確認する必要があります。

可用性:

クエリを実行してデータにアクセスするには、Snowflakeでキーを継続的に利用できるようにする必要があります。

設計上、無効なキーまたは使用できないキーがあると、Snowflakeで有効なキーが再び使用可能になるまで、Snowflakeデータ操作が中断されます。

ただし、Snowflakeは、ネットワーク通信障害などの一般的な問題に起因する一時的な可用性の問題（最大10分）を処理するように設計されています。10分後、キーが使用できない場合、Snowflakeアカウントのすべてのデータ操作が完全に停止します。キーへのアクセスが復元されると、データ操作を再度開始できます。

これらの要件を順守しないと、データに 一時的にアクセスできない から、 永続的に無効 になるまで、データの整合性が著しく危険にさらされる可能性があります。加えて、Snowflakeでは、発生するサードパーティの問題や、キーを維持する過程で組織によって引き起こされる管理上の問題について責任を負いません。

例えば、キー管理サービスの問題が原因でキーが使用できなくなった場合、データ操作が影響を受けます。このような問題は、お客様とキー管理サービスのこのサポートチームとの間で解決する必要があります。同様に、キーが改ざんまたは破壊された場合は、キーが復元されるまで、Snowflakeアカウント内のすべての既存データが読み取り不能になります。

機能の互換性¶

次の機能はTri-Secret Secureには対応していません。

• イメージレジストリ。

• ハイブリッドテーブル:

  Snowflakeアカウントで Tri-Secret Secure の使用が有効になっている場合、 ハイブリッドテーブル は使用できません。ハイブリッドテーブルを使用する前に Snowflake Support に連絡して、SnowflakeアカウントでTri-Secret Secureが有効になっているかどうかを確認してください。

Tri-Secret Secureの有効化¶

Business Critical（またはそれ以上）アカウントでSnowflake Tri-Secret Secureを有効にするには、 Snowflakeサポート にお問い合わせください。