Snowflakeの暗号化キー管理を理解する

このトピックでは、Snowflakeが管理するキー、顧客が管理するキー、およびTri-Secret Secureに関連する概念について説明します。

このトピックの内容:

概要

Snowflakeは、顧客データを保護するためにデータ暗号化キーを管理します。この管理は、顧客の介入を必要とせずに自動的に行われます。

顧客は、Snowflakeアカウントをホストするクラウドプラットフォームのキー管理サービスを使用して、独自の追加の暗号化キーを維持できます。

有効にすると、Snowflakeが管理するキーと顧客が管理するキーの組み合わせにより、Snowflakeデータを保護するための複合 マスターキー が作成されます。これはTri-Secret Secureと呼ばれます。

Snowflakeが管理するキー

Snowflakeのすべての顧客データは、最新のセキュリティ標準とベストプラクティスを使用してデフォルトで暗号化されます。Snowflakeは、ハードウェアセキュリティモジュールをルートとする階層キーモデルをともなった、強力な AES 256ビット暗号化を使用します。

キーは定期的にSnowflakeサービスによって自動的にローテーションされ、データの定期的な再暗号化(「キー更新」)が自動的にできます。データの暗号化とキー管理は完全に透過的であり、構成や管理は不要です。

階層キーモデル

階層キーモデルは、Snowflakeの暗号化キー管理のフレームワークを提供します。階層はキーの複数のレイヤーで構成され、キーの上位レイヤー(親キー)はそれぞれ下のレイヤー(子キー)を暗号化します。セキュリティ用語では、すべての子キーを暗号化する親キーは「ラップ」と呼ばれます。

Snowflakeの階層キーモデルは、4つのレベルのキーで構成されています。

  • ルートキー

  • アカウントマスターキー

  • テーブルマスターキー

  • ファイルキー

次の図に示すように、各顧客アカウントには、アカウントレベル、テーブルレベル、およびファイルレベルのキーにおいて個別のキー階層があります。

Snowflakeの階層キーモデル

Snowflakeのようなマルチテナントクラウドサービスでは、階層キーモデルにより、個別のアカウントマスターキーを使用してすべてのアカウントが分離されます。顧客データのストレージを分離する アクセス制御モデル に加えて、階層キーモデルはアカウント分離の別の層を提供します。

階層キーモデルは、キーの各層の範囲を縮小します。例えば、テーブルマスターキーは単一のテーブルを暗号化します。ファイルキーは、単一のファイルを暗号化します。階層キーモデルは、各キーが保護するデータの量と、使用可能な期間を制限します。

暗号化キーのローテーション

Snowflakeが管理するキーすべては、30日以上経過するとSnowflakeによって自動的にローテーションされます。アクティブなキーは廃止され、新しいキーが作成されます。廃止されたキーが不要になったとSnowflakeが判断すると、キーは自動的に破棄されます。アクティブな場合、キーはデータの暗号化に使用され、顧客による使用が可能です。廃止されると、キーはデータの復号化のみに使用され、データへのアクセスのみに使用できます。

キー階層で子キーをラップするとき、またはテーブルにデータを挿入するとき、現在アクティブなキーのみがデータの暗号化に使用されます。キーが破棄されると、暗号化または復号化には使用されません。定期的なキーローテーションは、キーのライフサイクルを限られた期間に制限します。

次の画像は、3か月間における1つのテーブルマスターキー(TMK)のキーローテーションを示しています。

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 PERIODIC_DATA_REKEYING = true;
Copy

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

1年後に1つのテーブルマスターキー(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アカウントで 定期的なキー更新 の使用が有効になっている場合は、 ハイブリッドテーブル は使用できません。アカウントで定期的なキー更新が有効になっており、ハイブリッドテーブルを使用する場合は、 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、アカウントマスターキー、テーブルマスターキー、およびファイルキーの関係を示しています。

ハードウェアセキュリティモジュールに基づくキー階層

顧客が管理するキー

顧客が管理するキーは、Snowflakeアカウントをホストするクラウドプロバイダーのキー管理サービスで顧客が維持するマスター暗号化キーです。各プラットフォームの主要な管理サービスは次のとおりです。

次に、顧客が管理するキーをSnowflakeが管理するキーと組み合わせて、複合マスターキーを作成できます。これが発生すると、Snowflakeはこれを Tri-Secret Secure (このトピック内)と呼びます。

Snowflakeアカウントでこれらのシステム関数を呼び出して、キーに関する情報を取得できます。

重要

Snowflakeは、顧客管理キーのキーローテーションをサポートしておらず、顧客管理キーに自動キーローテーションポリシーを実装することを推奨していません。

この推奨の理由は、Snowflakeがデータを復号化できないため、ローテーションされたキーが削除された場合、キーのローテーションによってデータが失われる可能性があるためです。詳細については、 Tri-Secret Secure (このトピック内)をご参照ください。

顧客管理キーの利点

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

データアクセスの制御:

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

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

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

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

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

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

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

守秘義務:

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

整合性:

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

可用性:

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

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

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

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

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

Tri-Secret Secure

Tri-Secret Secureは、Snowflakeアカウントをホストするクラウドプロバイダープラットフォームで、Snowflakeが管理するキーと顧客が管理するキーを組み合わせて、Snowflakeデータを保護するための複合マスターキーを作成します。複合マスターキーはアカウントマスターキーとして動作し、階層内のすべてのキーをラップします。ただし、複合マスターキーが生データを暗号化することはありません。

複合マスターキー階層内にある、顧客が管理するキーが取り消されると、データをSnowflakeで復号化できなくなり、Snowflakeの標準暗号化よりも高いレベルのセキュリティと制御が提供されます。このデュアルキー暗号化モデルは、Snowflakeの組み込みユーザー認証とともに、Tri-Secret Secureが提供する3つのレベルのデータ保護を可能にします。

注意

Snowflakeを使用してアカウントでTri-Secret Secureを有効にする前に、 顧客管理キー セクション(このトピック内)にあるとおり、キーを保護する責任を慎重に検討する必要があります。ご質問や懸念がある方は、お気軽にお問い合わせください。

Snowflakeは、当社が維持するキーに対しても同じ責任を負います。サービスのセキュリティ関連のすべての側面と同様に、当社では細心の注意を払いこの責任に取り組んでいます。

すべてのキーは、SOC 2 Type II、PCI-DSS、HIPAAおよび HITRUST CSF など、最高のセキュリティ認定を取得できるようにする厳格なポリシーの下で維持されています。

機能の互換性

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

Tri-Secret Secureの有効化

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