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

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

このトピックの内容:

概要

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

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

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

Snowflakeが管理するキー

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

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

階層キーモデル

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

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

  • ルートキー

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

  • テーブルマスターキー

  • ファイルキー

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

Snowflake's hierarchical key model

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

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

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

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

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

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

Key rotation of one table master key (TMK) over a time period of three months.

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)の推奨事項です http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf

定期的なキー更新

このセクションでは、アカウントおよびテーブルマスターキーのライフサイクルの説明を続けます。 暗号化キーローテーション では、定期的にアクティブなキーを新しいキーに置き換え、古いキーを廃止するキーローテーションについて説明しました。定期的なデータのキー更新により、ライフサイクルが完了します。

キーのローテーションにより、キーはアクティブな状態から廃止状態に確実に転送されますが、キー更新により、キーは廃止状態から破棄状態になります。

定期的なキー更新が有効化されている場合には、テーブルの廃止された暗号化キーが1年以上経過すると、Snowflakeは自動的に新しい暗号化キーを作成し、新しいキーを使用して廃止されたキーによって以前に保護されたすべてのデータを再暗号化します。新しいキーは、今後のテーブルデータの復号化に使用されます。

注釈

Enterprise Editionアカウントの場合、 ACCOUNTADMIN ロールのユーザー(つまり、アカウント管理者)は、 ALTER ACCOUNT および PERIODIC_DATA_REKEYING パラメーターを使用してキー更新を有効化できます。

ALTER ACCOUNT SET PERIODIC_DATA_REKEYING = true;

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

Rekeying one table master key (TMK) after one year

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

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

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

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

  • ようになります。

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

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

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

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

キー更新が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は、キー階層のルートキーを生成、保存、および使用するための改ざん防止、高セキュリティの方法として、複数のオンラインハードウェアセキュリティモジュール(HSM)サービスの内の1つに依存しています。HSM の使用には、次のセキュリティ上の利点があります。

  • HSM は、キーが HSM を離れないようにし、すべての暗号化操作が HSM 内で実行されるように設計されています。

  • キー階層内のすべてのキーは、 HSM をアンラップする必要があります。

  • 新しいアカウントとテーブルを作成するときに新しい暗号化キーを生成することに加えて、 HSM はキーのローテーションとキー更新中に安全でランダムな暗号化キーを生成します。

    この動作は、 AWS とMicrosoft Azureには当てはまりますが、Google Cloud Platformには当てはまら ない ことに注意してください。

Snowflakeは、バックアップを備えた HSM の高可用性構成を使用して、暗号化キーが利用できないことによるサービス停止の可能性を低減し、階層内の最も重要なキーを紛失しないようにします。

次の画像は、 HSM、アカウントマスターキー、テーブルマスターキー、およびファイルキーの関係を示しています。

Key hierarchy rooted in Hardware Security Module

顧客が管理するキー

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

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

重要

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の有効化

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

最上部に戻る