Database Support Blog

  • Snowflake
2025.01.27

Snowflakeのセキュリティ対策!~ 多層防御の考え方を分かりやすく解説 ~

Snowflakeのセキュリティ対策!

Snowflakeは、データウェアハウス(DWH)をはじめとした様々な機能を提供するクラウドプラットフォームです。 クラウドDWHのセキュリティ対策という側面から、Snowflakeにおける多層防御の考え方を初心者の方にも分かりやすく解説します。AWSを前提とした記載にしていますが、基本的な考え方自体はAzureなどどのクラウドサービスプロバイダでも同様です。


本ブログの内容について、動画で視聴ができます。
本ブログの内容を動画で視聴」からご視聴ください。
資料のダウンロードもしていただけます。

多層防御とは

データベース一般における多層防御

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

図1:データベースへのアクセスステップ


例えば、データベースインスタンスにアクセスできるネットワーク経路が無ければ、そもそもログインの手前でネットワークエラーとなり接続に失敗します。また、ネットワーク経路が確立されていても、誤った認証情報を入力すれば認証エラーが発生してログインできません。

これは外部から不正アクセスを試みるユーザーでも同様で、何らかの手段でネットワーク的にアクセスができてしまったとしても、それが即時データ漏洩につながるのではなく、認証など他の階層で不正ログインを防ぐという対策が可能なのです。


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


図2:データベース一般における多層防御の概要

つまりは、各レイヤで多層的にセキュリティ防御策を施しましょう、というのが多層防御の基本的な考え方となります。こうした多層防御で考慮すべき観点は、データベースがオンプレミスであっても、Snowflakeのようなクラウド環境であってもほとんど変わりません。

Snowflakeにおける多層防御

上記で説明した考え方をSnowflakeに当てはめると、以下のような考え方になります。

(図3の各レイヤに記載されている機能について、本記事で触れていきます。)
   

図3:Snowflakeにおける多層防御の概要

参考までに、以下のSnowflakeコミュニティの記事では「Network Security」「IAM」「Data Encryption」の3レイヤで説明されています。本記事では「IAM」のレイヤを「ユーザー認証」と「アクセス制御」に分割しただけであり、基本的な考え方は同じです。


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

2024年、アメリカ最大の電気通信事業者であるAT&T社にて、Snowflake環境に不正にアクセスされ、情報漏洩につながったという事件がありました。攻撃者はマルウェアを通じて不正に認証情報を入手してSnowflake環境にアクセスしたと言われています。 AT&T以外にも不正にアクセスされたSnowflake環境があったとのことでした。

しかしこの情報漏洩事件は、Snowflakeプラットフォーム自体の脆弱性、設定ミスなどによって引き起こされたわけではなく、ユーザー側のセキュリティコントロールができていなかったことが原因とされています。実際、攻撃を受けた中で、以下のようなケースで情報漏洩につながっていました。


  • ユーザー名/パスワードのみの弱い認証でMFAが設定されていなかった
  • 古い資格情報が数年間有効なままだった
  • ネットワークポリシーによるIP制限が行われていなかった

ということで、データ保護をサービス側に任せてしまうのではなく、Snowflake側で用意されている各種機能を用いながら、ユーザー側で適切なセキュリティ対策を行うことが重要となります。

Snowflakeの多層防御をレイヤ別に解説

少し導入が長くなりましたが、Snowflakeにおける多層防御について、以下の順番で解説していきます。

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

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


図4:多層防御における「ネットワーク経路」

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

● プライベート接続

  • AWSのPrivateLink等、クラウドサービスプロバイダー(CSP)が提供するプライベート接続サービスを使用した接続
  • 企業のセキュリティポリシーなどで閉域接続の要件がある場合に使用
  • Business Criticalエディションが必要(簡単に言えばコンピュートの単価が高くなる)

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

  • Snowflakeに対しては、パブリックインターネット経由、もしくはCSP内のバックボーン通信での接続になる
  • 通信はHTTPSで暗号化されているため、基本的にはこちらも安全な通信と言える

なお、後者の通信が安全でない、というわけではありません。プライベート接続は「Snowflakeに格納するデータのセキュリティレベルが高く、企業のセキュリティポリシーとして閉域接続が必須である」など、特別な要件がある場合に使用するものと考えるのが良いと思います。

プライベート接続(以下AWS PrivateLinkを前提とします)ではVPCエンドポイント経由でSnowflakeにアクセスする形となり、通信経路が変わるので初めに整理しました。しかし基本的に守るべきポイントはどちらのパターンでも同じです。それぞれのパターンにおける、ネットワークレイヤの防御策を見ていきましょう。


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

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



図5:プライベート接続でない場合の構成イメージ

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


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

  • ネットワークポリシーとネットワークルール

図5の右側にあるネットワークポリシーとネットワークルールという機能では、Snowflakeアカウントへのインバウンド通信を接続元IPアドレスで制御することができます。プロキシサーバのグローバルIPアドレスや、クラウドBIツールのグローバルIPアドレスなどを接続元として指定することで、意図しない外部からの接続を防ぐことができるようになります。ネットワークルールはIPアドレスなどの識別子をルール化してひとまとめにしたもので、これをネットワークポリシーにアタッチすることによって通信を制御できます。

  • 参考:ネットワークポリシーを使用したネットワークトラフィックの制御
    https://docs.snowflake.com/ja/user-guide/network-policies
    ※SCIM・Snowflake OAuthを使用している場合は、セキュリティ統合レベルでのネットワークポリシーが必要になることもあります。
  • 社内ネットワークからのアウトバウンド通信制御

図5の左下にあるように、社内ネットワークからのアウトバウンド通信を制御することも可能です。Snowflakeアカウントが使用する通信のエンドポイント(ホスト名・ポート番号)を、Snowflake側のSQL(SYSTEM$ALLOWLIST関数)で取得し、それらをプロキシサーバ等のアウトバウンド許可リストに追加することで、アウトバウンドの制御ができるようになります。

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



プライベート接続の場合

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


図6:プライベート接続の場合の構成イメージ

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


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

●社内ネットワークからのアウトバウンド通信制御
こちらもPrivateLinkでないパターンとほぼ一緒ですが、Snowflake側のエンドポイントを取得するSQLが異なります。 SYSTEM$ALLOWLIST_PRIVATELINKという関数を使用します。


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

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

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

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

構成イメージ

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

図7:パブリックインターネット経由の実際の接続構成イメージ


この例では、社内ネットワークからのJDBCドライバアクセスとWeb UIアクセス(いずれもプロキシサーバ経由)、そしてクラウドBIツールからのODBCドライバアクセスをネットワークポリシーとネットワークルールで制御しています。

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


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

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

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


図8:多層防御におけるユーザー認証

認証レイヤについては、それだけで記事一本分になってしまうため、詳細は以下の私の記事を参照ください。

記事URL:https://zenn.dev/rshimajiri/articles/7eb766522fb0b1


2024年12月時点の情報として補足するとすれば、特にユーザー・パスワード認証に関して注意が必要です。簡単に要約すると、Snowflakeでは今後パスワードのみの認証が使用できなくなるため、他の認証方法を考える必要があります。

  • 以下の内容はSnowflakeの詳細な機能に触れる内容となるため、上記URLの記事内容をご確認の上、お読みください。

今後Snowflakeでは、TYPEプロパティがPERSONに設定されているユーザー(つまりSnowsightアクセスユーザー)で、かつパスワード認証を使用している場合にはMFAを強制適用することが予定されています。認証ポリシーでMFA_ENROLLMENTをOPTIONALにすることで一時的に回避することはできますが、後述するように恒久的な解決策にはなりません。そのため、Snowsightアクセスユーザーについては、パスワード+MFAにするか、もしくはSAML SSOでの認証を考える必要があります。


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


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

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

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

続いてアクセス制御の話です。

図9:多層防御におけるアクセス制御


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

ロール設計では、言わずもがな最小権限の原則に従うことが大事です。Snowflakeには元々用意されているロールがいくつかあります。

この元々用意されているロールは「システム定義ロール」と呼ばれ、図10 のように4種類(ORGADMINを除く)のシステム定義ロールがあります。それぞれ名前の通り、何かしらの管理者ロールという位置づけになっています。

デフォルトでは存在しない、ユーザー側で作成するロールは「カスタムロール」と呼ばれます。

図10:Snowflakeのロール階層

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

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

このカスタムロールを設計する際のベストプラクティスについては、すでに色々な解説記事などがWeb上に出ているため、ここで詳細に解説することはしません。

イメージだけ簡単に記載すると、カスタムロールの中で2階層にロールを分けることで柔軟に権限管理ができるようになります。


図11:カスタムロール設計例

機能ロール階層がビジネス上の役割を表したロールで、この機能ロールをユーザーに紐づけます。アクセスロールの階層で実際のオブジェクトに対するアクセス権限(USAGE、SELECT、ALLなど)を付与し、アクセスロールを機能ロールにアタッチするというイメージです。


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


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

図12:マスキングポリシー

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

図13:行アクセスポリシー

透過的なデータ暗号化

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

図14:多層防御におけるデータ暗号化

データ暗号化のレイヤについては、正直なところユーザー側で意識することはほとんどありません。Snowflake内に保存されているデータは、階層キーモデルによってすべてデフォルトで暗号化されているためです。また、Snowflakeとの間で転送されるデータもTLSによって暗号化されており、エンドツーエンドの暗号化を実現しています。

Snowflakeの暗号化キー管理について
https://docs.snowflake.com/ja/user-guide/security-encryption-manage

Snowflakeのエンドツーエンド暗号化について
https://docs.snowflake.com/ja/user-guide/security-encryption-end-to-end

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



図15:Snowflakeの階層キーモデル

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

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

●定期的な暗号化キー更新(Enterpriseエディション以上)
https://docs.snowflake.com/ja/user-guide/security-encryption-manage

●Tri-Secret Secure(Business Criticalエディション以上)
https://docs.snowflake.com/ja/user-guide/security-encryption-end-to-end

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

図16:Tri-Secret Secure

おわりに

本記事では、データベースにおける多層防御の考え方を踏まえ、各レイヤで提供されるSnowflakeのセキュリティ関連の機能の概観を確認しました。



図17:Snowflakeにおける多層防御の概要(再掲)


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

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

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



本ブログの内容を動画で視聴

本ブログの内容を動画で説明しています。
視聴後に資料のご提供をしています。
動画で視聴されたい方、資料を手に入れたい方はこちらからどうぞ。

Snowflakeのセキュリティ対策!

Snowflakeのセキュリティ対策! を 動画 で確認する




弊社ではお客様のご要件や目指したいゴールに合わせて、Snowflakeの最適な活用方法をご支援し、伴走いたします。Snowflakeの導入をお考えのお客様は、ぜひ弊社までお気軽にご相談ください。以下のページより30日間の無料トライアルを開始いただけます。





また弊社では、データ活用業務を担うユーザー部門向けにSQLの入門講座を用意しています。多くの練習問題を通して実用的なSELECT文を学べるため、ユーザー部門の方はもちろん、SQLを一から学びたいIT担当者の方にもおすすめの講座です。DWHからのデータ抽出について学びたい方は、ぜひお申し込みください。

執筆者情報

2019年新卒入社。DataSpiderをはじめとしたETL/EAI製品のフィールド技術・サポート技術を担当した後、2023年からSnowflake担当技術として活動している。かな書道が趣味で、月2回の稽古を欠かさず、各展覧会への出品も毎年行っている。...show more


■本記事の内容について
 本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。

■商標に関して
 ・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
 ・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
  文中の社名、商品名等は各社の商標または登録商標である場合があります。

関連している記事

  • Snowflake
2024.09.05

Snowflakeとは?何がすごいの?~アーキテクチャと特長をわかりやすく解説!~

【初心者向けの解説記事】Snowflakeは何がすごいのか、Snowflake Squadの認定スペシャリストが特長やアーキテクチャをわかりやすく説明します。

ページの先頭へ戻る