Snowflakeの多層防御について

はじめに

この記事では多層防御という観点で、Snowflakeのセキュリティについて概要をまとめています。
※今年10月に弊社主催のオンラインイベントで発表した内容がベースになっています。

また、Snowflake初心者の方でも理解しやすいよう、なるべく平易な言葉を心掛けました。不正アクセス防止の観点では、ネットワークレイヤと認証レイヤが重要であると考えており、特にネットワークレイヤの解説を厚めにしています。

2024年11月時点での記載である点と、企業ごとにセキュリティポリシー等が異なるので実際の実装方法のべスプラまで深く語れていない点にはご留意ください。基本的にはAWSを前提とした記載にしていますが、基本的な考え方自体はどのクラウドサービスプロバイダでも同じです。

多層防御の概要

まずは導入として、Snowflakeに限らないデータベース一般の多層防御について触れておきます。かなり簡略化していますが、以下のようにユーザーがデータベース内のデータにアクセスするためには、ネットワーク→認証→アクセス権限のように、いくつかのステップを踏む必要があります。



例えば、データベースインスタンスにアクセスできるネットワーク経路が無ければそもそもログインの手前ではじかれますし、ネットワーク的にアクセス可能であっても認証情報が間違えていれば認証エラーとなってログインできない、といった具合です。
これは外部から不正アクセスを試みるユーザーでも同じことあり、何らかの手段でネットワーク的にアクセスできてしまったとしても、それが即時データ漏洩につながるのではなく、認証など他の階層で不正ログインを防ぐという対策が可能になるのです。

上記ではネットワーク、認証、アクセス制御の3レイヤでしたが、ここにデータ暗号化のレイヤを追加して4レイヤとすると、多層防御は以下のようなイメージになります。



つまりは各レイヤで多層的にセキュリティ防御策を施しましょう、という話です。

この考え方をSnowflakeに当てはめると、以下のような考え方になります。
（下図の各レイヤに記載されている機能について、本記事で触れていきます。）



※以下のSnowflakeコミュニティの記事では、「Network Security」「IAM」「Data Encryption」の3レイヤですが、「IAM」のレイヤを「ユーザー認証」と「アクセス制御」に分割しただけで、基本的な考え方は同じです。
https://community.snowflake.com/s/article/Snowflake-Security-Overview-and-Best-Practices


ここで重要なのが、「Snowflakeのアカウント、データを安全に保つことはユーザーとSnowflakeの共同作業である」という考え方です。ユーザー側で適切にSnowflakeのセキュリティ設定を行わなければ、大切なデータを守ることができません。

ということで、導入が長くなりましたが各レイヤの解説に入ります。
ネットワーク→認証→アクセス制御→データ暗号化の順番で述べていきます。

ネットワーク経路とセキュリティ対策

まずは、Snowflakeのネットワーク経路のお話からです。

具体的な話に入る前に、Snowflakeへのプライベート接続とそうでない接続について整理しておきます。

• プライベート接続
  • AWSのPrivateLink等、クラウドサービスプロバイダー（CSP）が提供するプライベート接続サービスを使用した接続
  • 企業のセキュリティポリシーなどで閉域接続の要件がある場合に使用
  • Business Criticalエディションが必要（簡単に言えばコンピュートの単価が高くなる）
• プライベート接続でない場合
  • Snowflakeに対しては、パブリックインターネット経由、もしくはCSP内のバックボーン通信での接続になる
  • 通信はHTTPSで暗号化されているため基本的にはこちらも安全な通信と言える

後者の通信が安全でない、というわけではありません。プライベート接続は「Snowflakeに格納するデータのセキュリティレベルが高く、企業のセキュリティポリシーとして閉域接続が必須である」など、特別な要件がある場合に使用するものと考えるのが良いと思います。
プライベート接続（以下AWS PrivateLinkを前提とします）ではVPCエンドポイント経由でSnowflakeにアクセスする形となり、通信経路が変わるので初めに整理しておきました。しかし基本的に守るべきポイントはどちらのパターンでも同じです。それぞれのパターンにおける、ネットワークレイヤの防御策を見ていきましょう。

🌐プライベート接続でない場合

まずは、プライベート接続でない場合です。下図はオンプレミスの社内ネットワークからパブリックインターネット経由でSnowflakeにアクセスするイメージです。（システム構成によってはパブリックインターネット経由ではなく、CSPのバックボーン通信になることも多いかと思います。）



この例では、社内ネットワークにあるBI/ETLツールからのドライバ経由でのアクセスや、ローカルPCからのWebUIアクセスなどを想定しています。社内ネットワークからFWなどを経由して外のインターネットに出て、HTTPS通信でSnowflakeにアクセスする、という経路です。

Snowflakeとしては、主に2か所で防御策を施すことができます。

• ネットワークポリシーとネットワークルール
  図の右側にあるネットワークポリシーとネットワークルールという機能では、Snowflakeアカウントへのインバウンド通信を接続元IPアドレスで制御することができます。プロキシサーバのグローバルIPアドレスや、クラウドBIツールのグローバルIPアドレスなどを接続元として指定することで、意図しない外部からの接続を防ぐことができるようになります。ネットワークルールはIPアドレスなどの識別子をルール化してひとまとめにしたもので、これをネットワークポリシーにアタッチすることによって通信を制御できます。
  https://docs.snowflake.com/ja/user-guide/network-policies
  ※SCIM・Snowflake OAuthを使用している場合は、セキュリティ統合レベルでのネットワークポリシーが必要になることもあります。
• 社内ネットワークからのアウトバウンド通信制御
  図の左下にあるように、社内ネットワークからのアウトバウンド通信を制御することも可能です。Snowflakeアカウントが使用する通信のエンドポイント（ホスト名・ポート番号）を、Snowflake側のSQL（SYSTEM$ALLOWLIST関数）で取得し、それらをプロキシサーバ等のアウトバウンド許可リストに追加することで、アウトバウンドの制御ができるようになります。
  https://docs.snowflake.com/ja/sql-reference/functions/system_allowlist

つまりは、社内ネットワークから出ていくアウトバウンド通信と、Snowflakeに入ってくるインバウンド通信の2か所でしっかり制限をかけましょう、ということですね。

🔒プライベート接続の場合

次に、プライベート接続の場合も考えてみます。



こちらでも、先ほどのインターネット経由の場合と同じく、社内ネットワークから出ていくアウトバウンド通信と、Snowflakeに入ってくるインバウンド通信がポイントになります。

• ネットワークポリシーとネットワークルール
  ネットワークポリシーとネットワークルールを使用することによって、Snowflakeへのインバウンド通信を制御できるのは先ほどと同じです。PrivateLink構成の場合、制御の内容が微妙に異なり、以下のいずれかのパターンを選択する形になります。

  • ※こちらが推奨※　PrivateLinkに使用されるVPCエンドポイントID自体を接続元としたネットワークルールを作成して制御します。
  • IPアドレスでの制御とする場合、ネットワークルールで指定するVPCエンドポイントからの通信は、プライベートIPで制御する形になります。

• 社内ネットワークからのアウトバウンド通信制御
  こちらもPrivateLinkでないパターンとほぼ一緒ですが、Snowflake側のエンドポイントを取得するSQLだけ異なり、SYSTEM$ALLOWLIST_PRIVATELINK関数を使用します。
  https://docs.snowflake.com/ja/sql-reference/functions/system_allowlist_privatelink

また、PrivateLinkに関わる設定はAWS側での作業が必要で、DNSによる名前解決を行う部分では、社内ネットワーク担当者との調整も必須になります。

内部ステージへのプライベート接続については、内部ステージを明示的に使わない場合であっても、PrivateLink for S3は必要となります。これは、暗黙的に内部ステージを経由してクエリの結果セットを取得することがあるためです^[1]。

内部ステージへのPrivateLink for S3については、S3_STAGE_VPCE_DNS_NAMEというパラメータを使ってVPCエンドポイントのDNS名に紐づけられるようになっています。
このオプションを選択すると、ユーザー側でPrivateLink for S3用の名前解決のことは考えずに済みます^[2]。

構成イメージ

実際の構成イメージを以下の図で示します。（パブリックインターネット経由）



この例では、社内ネットワークからのJDBCドライバアクセスとWeb UIアクセス（いずれもプロキシサーバ経由）、そしてクラウドBIツールからのODBCドライバアクセスをネットワークポリシーとネットワークルールで制御しています。
また、社内ネットワークからのアウトバウンド通信も制御しており、Snowflakeが利用するホスト名・ポート番号の許可リストをプロキシサーバに設定しています。なお、SnowflakeではHTTPSで使用する証明書確認のためにOCSPというプロトコルを使用しており、この例ではOCSPサーバへの通信も許可しています（このOCSPサーバのホスト名もSYSTEM$ALLOWLIST関数で取得可能）。

いずれにせよ、ネットワークレイヤでの防御策としては、ネットワークポリシー・ネットワークルールによるインバウンド通信の制御、社内ネットワークからのアウトバウンド通信の制御が重要なポイントとなります。

Snowflakeでサポートされる認証方式

つづいて、認証レイヤの話です。

と、ここで認証レイヤについて書こうと思っていましたが、実は認証については解説記事を以前書いているので、詳細はそちらを参照という形にします。
↓の記事にて、Snowsight（Web UI）アクセスとサービスアクセスのそれぞれで、適切な認証方式を取りましょう、ということを書いています。
https://zenn.dev/rshimajiri/articles/7eb766522fb0b1

2024年11月現在の情報として付け加えるとすれば、特にユーザー・パスワード認証を利用している場合に注意が必要です。

今後Snowflakeでは、TYPEプロパティがPERSONに設定されているユーザー（つまりSnowsightアクセスユーザー）で、かつパスワード認証を使用している場合にはMFAを強制適用することが予定されています。認証ポリシーでMFA_ENROLLMENTをOPTIONALにすることで一時的に回避することはできるようですが、恒久的な解決策にはならないと思われます。そのため、Snowsightアクセスユーザーについては、パスワード＋MFAにするか、もしくはSAML SSOでの認証を考える必要があります。
参考：https://community.snowflake.com/s/article/FAQ-Snowflake-will-require-Multi-Factor-Authentication-by-default-for-new-Snowflake-accounts

また、サードパーティツールでSnowflakeにアクセスをするためのいわゆるサービスユーザーについても、同様に注意が必要です。サービス側（BI・ETLツール等）がキーペア認証等に対応しておらず、ユーザー・パスワード認証で接続しているというケースがあるかもしれません。しかし、上記のMFA強制のアップデートに伴って、サービスアクセスユーザーはTYPEプロパティをSERVICEに設定することになりますが、この場合パスワード認証はできなくなります。そのため、キーペア認証などに切り替える必要があるのです。TYPEプロパティをLEGACY_SERVICEにするという一時的な回避策があるものの、こちらも恒久的な解決策ではないため、認証方式を切り替えるという対応が必要です。

上記のMFA強制に関連するSnowflakeのバンドルは、2025年2月に適用される予定です（2024年11月現在）^[3]。適用時期が変更される可能性はあり、一時的な回避策もあるのは事実ですが、将来のことを考えると現時点での対応を行うのがベストだと思われます。

2024/12/4追記
TYPEがPERSONかつパスワード認証のみのユーザーに対するMFA強制は、2025年4月に行われるという発表がありました。その後、2025年8月・11月のアップデートを通じて、一時的な回避策も撤廃される予定のようです。詳細は以下URLをご確認ください。

公式ブログ記事：https://www.snowflake.com/en/blog/blocking-single-factor-password-authentification/
コミュニティFAQ：https://community.snowflake.com/s/article/FAQ-Snowflake-to-block-password-only-logins

今まで、ユーザー側でオプションとしてセキュアな認証方式を選ぶことができるという扱いでしたが、上記アップデートを経て、Snowflake側が安全な認証方式を強制するようになります。これは、Snowflakeというサービスを安全に使い、重要なデータを守るうえでは非常に良い動きであると、個人的には思っています。

システム定義ロールとロール設計例

つづいてはアクセス制御の話です。

Snowflakeでは、任意アクセス制御（DAC）とロールベースアクセス制御（RBAC）を組み合わせた権限制御の仕組みとなっていますが、本記事ではRBACにフォーカスして記述します。

ロール設計では、言わずもがな最小権限の原則に従うことが大事ですが、Snowflakeには元々用意されているロールがいくつかあります。
この元々用意されているロールは「システム定義ロール」と呼ばれ、下図の通り4種類（ORGADMINを除く）のシステム定義ロールがあります。それぞれ名前の通り何かしらの管理者ロールという位置づけになっています。
デフォルトでは存在しない、ユーザー側で作成するロールは「カスタムロール」と呼ばれます。



また、ロール階層の中では、下位のロールが持っている権限はその上位も継承して持っており、例えばUSERADMINはユーザー・ロールの作成権限を持ちますが、この権限はSECURITYADMIN、ACCOUNTADMINにも継承されています。

1つ注意点があり、Snowflakeのロール階層で最上位に位置するACCOUNTADMINは、いわゆるスーパーユーザーという扱いではなく、あくまでもロール階層で最上位というだけです。そのため、例えばあるカスタムロールAを作成して、どのシステム定義ロールにも紐づけなかった場合、そのロールAが作成したオブジェクトなどはACCOUNTADMINからも見れないという状態になります。そのため、カスタムロールはSYSADMINに紐づけて、上位のシステム定義ロールによってきちんと管理できるように構成することが推奨されています。

このカスタムロールを設計する際のベストプラクティスについては、すでに色々な解説記事などが出ているため、ここで詳細に解説することはしません。
イメージだけ簡単に記載すると、カスタムロールの中で2階層にロールを分けることで柔軟に権限管理ができるようになります。

営業担当に見せたくないデータがある場合のカスタムロール構成イメージ（仮想ウェアハウス除く）
機能ロール階層がビジネス上の役割を表したロールで、この機能ロールをユーザーに紐づけます。アクセスロールの階層で実際のオブジェクトに対するアクセス権限（USAGE、SELECT、ALLなど）を付与し、アクセスロールを機能ロールにアタッチするというイメージです。

また、ロールから少し派生すると、マスキングポリシーや行アクセスポリシーなどのトピックにもつながってきます。この辺りは本記事の範疇を超えるため、参考イメージの共有に留めます。

マスキングポリシー：クエリ実行時のロールに応じて機密データなどの列項目へのマスキングが可能

行アクセスポリシー：マッピングテーブルを使い、クエリ実行時に返す行をロールに応じて変更

透過的なデータ暗号化

最後はデータ暗号化の話です。

データ暗号化のレイヤについては、正直あまりユーザー側で意識することはありません。
Snowflake内に保存されているデータは、階層キーモデルによってすべてデフォルトで暗号化されているためです。また、Snowflakeとの間で転送されるデータもTLSによって暗号化されており、エンドツーエンドの暗号化を実現しています。
https://docs.snowflake.com/ja/user-guide/security-encryption-manage
https://docs.snowflake.com/ja/user-guide/security-encryption-end-to-end

少しだけ暗号化キーについて補足すると、暗号化キー階層の最上位にあたるルートキーは、ハードウェアセキュリティモジュール（HSM）によって厳重に管理されており、その下にアカウントマスターキー、テーブルマスターキー、ファイルキーが存在するという構成になっています。

Snowflakeのサービス側でキーは自動的にローテーションされるため、データの暗号化からキー管理まで完全に透過的であり、ユーザー側での構成や管理は不要です（もちろん追加費用も不要！）。そして、この暗号化キー階層をユーザーが意識することもほとんどないでしょう。

なお、暗号化キーについては以下のオプションもあるため、企業のセキュリティポリシーなどに応じて選択はできるようになっています。

• 定期的な暗号化キー更新（Enterpriseエディション以上）
  https://docs.snowflake.com/ja/user-guide/security-encryption-manage#periodic-rekeying
• Tri-Secret Secure（Business Criticalエディション以上）
  https://docs.snowflake.com/ja/user-guide/security-encryption-manage#tri-secret-secure

Tri-Secret Secureでは下図のように、Snowflakeが管理するキーと顧客側で管理するキーを組み合わせた複合マスターキーを、アカウントマスターキーとして利用することができます。

おわりに

多層防御の考え方を踏まえ、各レイヤで提供されるSnowflakeのセキュリティ関連の機能の概観を見てきました。

この記事で伝えたかったことは以下の2つです。

• Snowflakeの各レイヤごとに提供されている機能で多層的なセキュリティ防御を！
• データを安全に保つためには、ユーザーとSnowflakeの共同作業が必要！

今回紹介したような多層防御の考え方については、SnowflakeのようなSaaSのサービスを扱う上でも非常に重要です。Snowflakeは進化が早く、セキュリティ防御策の具体的な実装方法は変化していく可能性が高いですが、こうした基本的な考え方を頭に入れたうえで、設計を考えていくことが大事だと思っています。

脚注

1. https://stackoverflow.com/questions/75463582/snowflake-jdbc-resultset-with-more-than-1000-rows-not-reaching-client

2. https://docs.snowflake.com/ja/user-guide/private-internal-stages-aws#accessing-internal-stages-with-dedicated-interface-endpoints

3. https://docs.snowflake.com/en/release-notes/bcr-bundles/2024_08_bundle