データ暗号化¶
顧客データの保護は、Snowflakeの最優先事項の1つです。Snowflakeは、デフォルトですべての顧客データを最新のセキュリティ標準を使用して追加費用なしで暗号化します。Snowflakeは、顧客に対して完全に透過的な、クラス最高のキー管理を提供します。そのため、Snowflakeは最も使いやすく最も安全なデータプラットフォームの1つになります。
このトピックの内容：
エンドツーエンド暗号化¶
エンドツーエンド暗号化（E2EE）は、エンドユーザー以外は誰もデータを読み取れない通信形式です。Snowflakeでは、これは顧客とランタイムコンポーネントのみがデータを読み取ることができることを意味します。Snowflakeのクラウドコンピューティングプラットフォームや ISP を含むサードパーティは、暗号化されていないデータを見ることができません。
E2EE はアタックサーフェスを最小限にします。クラウドプラットフォームのセキュリティ違反が発生した場合、データは常に暗号化されているため、内部または外部の攻撃者によるアクセス認証情報の間接的な公開やデータファイルの直接的な公開に関係なく、データは保護されます。
この図は、Snowflakeの E2EE システムを示しています。システムには次のコンポーネントが含まれます。
企業ネットワーク内のSnowflakeの顧客
データファイルステージ
安全な仮想プライベートクラウドで実行中のSnowflake（VPC）
Snowflakeは、データファイルの内部ステージと外部ステージの両方をサポートしています。Snowflakeには、データをテーブルにロードする前にデータファイルをアップロードおよびグループ化できる内部ステージが用意されています（オプションB）。顧客が提供するステージは、顧客が所有し管理するサポートされたクラウドストレージプラットフォーム（Amazon S3）のコンテナまたはディレクトリです（オプションA）。顧客が提供するステージは、これらのプラットフォームに既にデータが保存されており、Snowflakeにコピーしたい顧客にとって魅力的なオプションです。Snowflakeは、両方のタイプのステージで E2EE をサポートしています。
Snowflakeは、クラウドプラットフォーム上の単一の安全な VPC で実行されます。
Snowflakeでの E2EE のフローは次のとおりです（このセクションの図をご参照ください）。
ユーザーが1つ以上のデータファイルをステージにアップロードします。ステージがクラウドストレージサービスの顧客管理コンテナである場合（オプションA）、ユーザーはオプションでクライアント側の暗号化を使用してデータファイルを暗号化できます（詳細については、 クライアント側の暗号化 をご参照ください）。Snowflakeの外部でステージングされるデータファイルには、クライアント側の暗号化をお勧めします。ただし、データが暗号化されていない場合、Snowflakeはテーブルにロードされるとすぐにデータを暗号化します。
ステージが内部（つまり、Snowflake）ステージ（オプションB）の場合、データファイルはローカルマシン上のクライアントによって自動的に暗号化されてから、内部ステージに送信されます。
ユーザーは、ステージからテーブルにデータをロードします。データは、Snowflake独自のファイル形式に変換され、クラウドストレージコンテナに格納されます（「保存データ」）。Snowflakeでは、すべての保存データは常に暗号化されます。
クエリ結果はステージにアンロードできます。結果は、顧客が管理するステージにアンロードするときにクライアント側の暗号化を使用してオプションで暗号化され、Snowflakeが提供するステージにアンロードするときに自動的に暗号化されます。
ユーザーはステージからデータファイルをダウンロードし、クライアント側でデータを復号化します。
これらのすべての手順で、すべてのデータファイルが暗号化されます。ユーザーとSnowflakeランタイムコンポーネントのみがデータを読み取ることができます。ランタイムコンポーネントは、クエリ処理のためにメモリ内のデータを復号化します。サードパーティのサービスでは暗号化されていないデータを見ることができません。
クライアント側の暗号化¶
クライアント側の暗号化によって、クラウドストレージ内のデータを管理するための安全なシステムを提供します。クライアント側の暗号化とは、ユーザーが格納されたデータをSnowflakeに読み込む前に暗号化することを意味します。クラウドストレージサービスは、暗号化されたバージョンのデータのみを格納し、暗号化されていないデータが含まれることはありません。
クライアント側の暗号化は、クラウドストレージサービスによって定義された特定のプロトコルに従います。サービス SDK およびサードパーティツールは、このプロトコルを実装しています。クライアント側の暗号化プロトコルは次のように機能します（このセクションの図をご参照ください）。
Snowflakeの顧客は、秘密のマスターキーを作成しますが、これは顧客に残ります。
クライアント（クラウドストレージサービスによって提供される）は、ランダムな暗号化キーを生成し、クラウドストレージにアップロードする前にファイルを暗号化します。ランダム暗号化キーは、順次、顧客のマスターキーで暗号化されます。
暗号化されたファイルと暗号化されたランダムキーの両方がクラウドストレージサービスにアップロードされます。暗号化されたランダムキーは、ファイルのメタデータとともに格納されます。
データをダウンロードするとき、クライアントは暗号化されたファイルと暗号化されたランダムキーの両方をダウンロードします。クライアントは、顧客のマスターキーを使用して暗号化されたランダムキーを復号化します。次に、クライアントは、現在復号化されているランダムキーを使用して、暗号化されたファイルを復号化します。暗号化と復号化はすべてクライアント側で行われます。クラウドストレージサービスや他のサードパーティ（ISP など）が暗号化されていないデータを見ることはありません。顧客は、クライアント側の暗号化をサポートするクライアントまたはツールを使用して、クライアント側の暗号化されたデータをアップロードできます。
クライアント側で暗号化されたデータのSnowflakeへの取り込み¶
Snowflakeは、クラウドストレージサービスステージとSnowflakeの間でデータを読み書きする際に、クライアント側のマスターキーを使用してクライアント側の暗号化プロトコルをサポートします。
顧客提供のステージからクライアント側の暗号化されたデータをロードするには、 CREATE STAGE を使用して追加の MASTER_KEY パラメーターで名前付きステージオブジェクトを作成し、ステージからSnowflakeテーブルにデータをロードします。MASTER_KEY パラメーターには、Base64でエンコードされた256ビットAdvanced Encryption Standard（AES）キーが必要です。
名前付きステージオブジェクトは、ステージに関連する設定を保存し、Snowflakeとクラウドストレージ内の特定のコンテナの間でデータをロードまたはアンロードする便利な方法を提供します。次の SQL スニペットは、クライアント側の暗号化をサポートするSnowflakeのサンプルAmazon S3ステージオブジェクトを作成します。
-- create encrypted stage
create stage encrypted_customer_stage
url='s3://customer-bucket/data/'
credentials=(AWS _KEY_ID='ABCDEFGH' AWS_SECRET_KEY='12345678')
encryption=(MASTER_KEY='eSxX0jzYfIamtnBKOEOxq80Au6NbSgPH5r4BDDwOaO8=');
この SQL コマンドで指定されたマスターキーは、顧客の秘密マスターキーのBase64エンコードされた文字列です。他のすべての認証情報と同様に、このマスターキーはTransport Layer Security（HTTPS）を介してSnowflakeに送信され、メタデータストレージに暗号化されて格納されます。Snowflakeの顧客とクエリ処理コンポーネントのみがマスターキーに公開されているため、ステージに格納されているデータを復号化できます。
名前付きステージオブジェクトの利点は、アクセス認証情報またはクライアント側の暗号化キーをユーザーに公開することなく、Snowflakeアカウント内の他のユーザーに付与できることです。適切なアクセス制御権限のあるユーザーは、データのロードまたはアンロード時に名前付きステージオブジェクトを参照するだけです。
次の SQL コマンドは、USERS という名前のテーブルを作成し、暗号化されたステージから USERS テーブルにデータをコピーします。
-- create table and ingest data from stage
CREATE TABLE users (id bigint, name varchar(500), purchases int);
COPY INTO users FROM @encrypted_customer_stage/users;
これで、Snowflakeを使用してデータを分析する準備が整いました。
ステージにデータをアンロードすることもできます。次の SQL コマンドは、MOST_PURCHASES テーブルを作成し、最も購入数の多い上位10ユーザーを検索するクエリの結果を設定して、テーブルデータをステージにアンロードします。
-- find top 10 users by purchases, unload into stage
CREATE TABLE most_purchases as select * FROM users ORDER BY purchases desc LIMIT 10;
COPY INTO @encrypted_customer_stage/most_purchases FROM most_purchases;
Snowflakeは、ステージオブジェクトに格納されているマスターキーを使用して、顧客のステージにコピーされたデータファイルを暗号化します。Snowflakeは、クラウドストレージサービスのクライアント側の暗号化プロトコルを順守しています。顧客は、クライアント側の暗号化をサポートするクライアントまたはツールを使用して、暗号化されたデータファイルをダウンロードできます。
暗号化キー管理¶
Snowflakeのすべての顧客データは、最新のセキュリティ標準とベストプラクティスを使用してデフォルトで暗号化されます。Snowflakeは、ハードウェアセキュリティモジュールをルートとする階層キーモデルをともなった、強力な AES 256ビット暗号化を使用します。キーは定期的にSnowflakeサービスによって自動的にローテーションされ、データの定期的な再暗号化（「キー更新」）が自動的にできます。データの暗号化とキー管理は完全に透過的であり、構成や管理は不要です。
Snowflake暗号化の詳細については、セキュリティホワイトペーパー http://www.snowflake.com/resource/industrial-strength-security-by-default/ をご参照ください。
階層キーモデル¶
階層キーモデルは、Snowflakeの暗号化キー管理のフレームワークを提供します。階層はキーの複数のレイヤーで構成され、キーの上位レイヤー（親キー）はそれぞれ下のレイヤー（子キー）を暗号化します。セキュリティ用語では、すべての子キーを暗号化する親キーは「ラップ」と呼ばれます。
Snowflakeの階層キーモデルは、4つのレベルのキーで構成されています。
ルートキー
アカウントマスターキー
テーブルマスターキー
ファイルキー
各顧客アカウントには、アカウントレベル、テーブルレベル、およびファイルレベルキーの個別のキー階層があります。
Snowflakeのようなマルチテナントクラウドサービスでは、階層キーモデルにより、個別のアカウントマスターキーを使用してすべてのアカウントが分離されます。顧客データのストレージを分離する アクセス制御モデル に加えて、階層キーモデルはアカウント分離の別の層を提供します。
階層キーモデルは、キーの各層の範囲を縮小します。例えば、テーブルマスターキーは単一のテーブルを暗号化します。ファイルキーは、単一のファイルを暗号化します。階層キーモデルは、各キーが保護するデータの量と、使用可能な期間を制限します。
暗号化キーのローテーション¶
アカウントとテーブルのマスターキーは、30日以上経過するとSnowflakeによって自動的にローテーションされます。アクティブなキーは廃止され、新しいキーが作成されます。廃止されたキーが不要になったとSnowflakeが判断すると、キーは自動的に破棄されます。アクティブな場合、キーはデータの暗号化に使用され、発信者が使用できます。廃止されると、キーはデータの復号化のみに使用され、受信者のみが使用できます。キー階層で子キーをラップするとき、またはテーブルにデータを挿入するとき、現在アクティブなキーのみがデータの暗号化に使用されます。キーが破棄されると、暗号化または復号化には使用されません。定期的なキーローテーションは、キーのライフサイクルを限られた期間に制限します。
次の図は、1つのテーブルマスターキー（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。
定期的なキー更新¶
定期的なキー更新にはエンタープライズ版が必要です。アップグレードについては、 Snowflakeサポート にお問い合わせください。
このセクションでは、アカウントおよびテーブルマスターキーのライフサイクルの説明を続けます。 暗号化キーローテーション では、定期的にアクティブなキーを新しいキーに置き換え、古いキーを廃止するキーローテーションについて説明しました。定期的なデータのキー更新により、ライフサイクルが完了します。定期的なキー更新が有効化されている場合、テーブルの廃止された暗号化キーが1年以上経過すると、Snowflakeは自動的に新しい暗号化キーを作成し、新しいキーを使用して廃止されたキーによって以前に保護されたすべてのデータを再暗号化します。新しいキーは、今後のテーブルデータの復号化に使用されます。
注釈
エンタープライズ版アカウントの場合、ACCOUNTADMIN ロールのユーザー（アカウント管理者）は、 ALTER ACCOUNT および PERIODIC_DATA_REKEYING パラメーターを使用してキー更新を有効化できます。
ALTER ACCOUNT SET PERIODIC_DATA_REKEYING = true;
キーのローテーションにより、キーはアクティブな状態（発信者の使用）から廃止状態（受信者の使用）に確実に転送されますが、キー更新により、キーは廃止状態から破棄状態になります。
この図では、1つのテーブルのテーブルマスターキー（TMK）が毎月ローテーションされます。図は、4月、5月、6月のキーローテーションを示しています（TMK v1、v2、v3）：
翌年の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保護が課金されます。つまり、S3の古いキーを持つデータファイルは既にFail-safeで保護されており、S3の新しいキーを持つデータファイルもFail-safeに追加され、2回目の請求につながります。ただし、これは7日間のみです。
ハードウェアセキュリティモジュール¶
Snowflakeは、キー階層のルートキーを生成、保存、および使用するための改ざん防止、高セキュリティの方法として、複数のオンラインハードウェアセキュリティモジュール（HSM）サービスの内の1つに依存しています。 HSM の使用には、次のセキュリティ上の利点があります。
キー階層の最上位のキーが HSM を離れることはありません。すべての暗号操作は、セキュリティモジュール内で実行されます。
キー階層でラップされた低レベルキーは、HSM デバイスへの許可されたアクセスなしではアンラップできません。
新しいアカウントとテーブルを作成するときに新しい暗号化キーを生成することに加えて、 HSM はキーのローテーションとキー更新中に安全でランダムな暗号化キーを生成します。
この動作は、 AWS とMicrosoft Azureには当てはまりますが、Google Cloud Platformには当てはまらないことに注意してください。
Snowflakeは、バックアップを備えた HSM の高可用性構成を使用して、サービス停止の可能性を低減し、階層内の最も重要なキーを紛失しないようにします。
Tri-Secret Secureおよび顧客管理キー¶
Business Critical Edition（またはそれ以上）が必要です。アップグレードについては、 Snowflakeサポート にお問い合わせください。
Tri-Secret Secureでは、Snowflakeアカウントをホストするクラウドプロバイダーのキー管理サービスで管理するマスター暗号化キーを使用して、データへのアクセスを制御できます。
AWS： AWSキー管理サービス（KMS）
Google Cloud： クラウドキー管理サービス（クラウド KMS）
Microsoft Azure： Azure Key Vault
アカウントでTri-Secret Secureを有効化すると、SnowflakeはキーとSnowflakeが保持するキーを組み合わせて複合マスターキーを作成します。この複合マスターキーは、アカウント内のすべてのデータを暗号化するために使用されます。複合マスターキーのいずれかのキーが取り消されると、データを復号化できなくなり、Snowflakeの標準暗号化よりも高いレベルのセキュリティと制御が提供されます。このデュアルキー暗号化モデルは、Snowflakeの組み込みユーザー認証とともに、Tri-Secret Secureが提供する3つのレベルのデータ保護を可能にします。
顧客管理キーの実装の詳細については、この ブログ投稿 （AWS を参照していますが、クラウドサービスに関係なく一般的な原則が適用されます）をご参照ください。
顧客管理キーの利点¶
顧客管理キーの利点は次のとおりです。
データアクセスの制御： キー管理サービスのマスターキー、つまりSnowflakeのデータを完全に制御できます。このキーをリリースしないと、Snowflakeアカウントに格納されているデータを復号化することはできません。
データ侵害が発生した場合にアクセスを無効にする機能： セキュリティ侵害が発生した場合、キーへのアクセスを無効にして、Snowflakeアカウントで実行されているすべてのデータ操作を停止できます。
データライフサイクルの所有権： 顧客管理キーを使用して、データ保護要件をビジネスプロセスと整合させることができます。キーを明示的に制御することにより、作成から削除まで、データのライフサイクル全体で保護が提供されます。
顧客管理キーの重要な要件¶
顧客管理キーには、セキュリティ上の大きな利点がありますが、マスターキーを保護するために、 継続的に 従わなければならない重要で基本的な要件もあります。
機密保持： キーは常に安全性と機密性を保つ必要があります。
整合性： キーが不適切な変更または削除から保護されていることを確認する必要があります。
可用性： クエリを実行してデータにアクセスするには、Snowflakeでキーを継続的に利用できるようにする必要があります。
設計上、無効なキーまたは使用できないキーがあると、Snowflakeで有効なキーが再び使用可能になるまで、Snowflakeデータ操作が中断されます。
ただし、Snowflakeは、ネットワーク通信障害などの一般的な問題に起因する一時的な可用性の問題（最大10分）を処理するように設計されています。10分後、キーが使用できない場合、Snowflakeアカウントのすべてのデータ操作が完全に停止します。キーへのアクセスが復元されると、データ操作を再度開始できます。
これらの要件を順守しないと、データに 一時的にアクセスできない から、 永続的に無効 になるまで、データの整合性が著しく危険にさらされる可能性があります。加えて、Snowflakeでは、発生するサードパーティの問題や、キーを維持する過程で組織によって引き起こされる管理上の問題について責任を負いません。
例えば、キー管理サービスの問題が原因でキーが使用できなくなった場合、データ操作が影響を受けます。このような問題は、お客様とキー管理サービスのこのサポートチームとの間で解決する必要があります。同様に、キーが改ざんまたは破壊された場合、キーが復元されるまで、Snowflakeアカウント内のすべての既存データは読み取り不能になります。
注意
Snowflakeを使用してアカウントでTri-Secret Secureを有効にする前に、キーを保護する責任を慎重に検討する必要があります。ご質問や懸念がある方は、お気軽にお問い合わせください。
Snowflakeは、当社が維持するキーに対しても同じ責任を負います。サービスのセキュリティ関連のすべての側面と同様に、当社では細心の注意を払いこの責任に取り組んでいます。すべてのキーは、SOC 2 Type II、PCI-DSS、HIPAAおよび HITRUST CSF など、最高のセキュリティ認定を取得できるようにする厳格なポリシーの下で維持されています。
Tri-Secret Secureの有効化¶
Business CriticalアカウントでSnowflake Tri-Secret Secureを有効にするには、 Snowflakeサポート にお問い合わせください。