❄️

Snowflakeセキュリティベストプラクティス-ネットワーク編

2023/08/02に公開

Security

Snowflakeでセキュリティ機能に特化したSecurity Field CTO Officeロールを担当しているMasayaです

今回はSnowflakeが提供しているセキュリティ機能を使用したベストプラクティスの英文記事をわかりやすくまとめました

記事：

ベストプラクティスの中身及び構成については随時変更される可能性があるため、こちらの本文と英文記事とに差異があった場合は英文記事側を正としてください。こちらのブログはオリジナルの英訳及び追記という位置付けになります。

Snowflakeセキュリティ機能を使用した多層防御

Snowflakeはお客様のデータを保護するために様々なセキュリティ機能を提供しています。

一般的なセキュリティの世界でもセキュリティソリューションを何層にも積み重ねて、攻撃者が狙うであろう重要情報や重要資産を保護する「多層防御」を行うことが一般的ですが、Snowflakeが提供しているセキュリティ機能を使用してSnowflakeアカウントを多層防御することでリスクを軽減することができます

主には

ネットワークセキュリティ
IAM : Identity and Access Management (RBACや認証など)
データ保護（暗号やマスキングなど）
が提供されています

本記事ではネットワークセキュリティに特化したベストプラクティスをご紹介します

ネットワークセキュリティ

ネットワークセキュリティはSnowflakeにおけるセキュリティ機能で最も最初に作用するセキュリティ機能です

ネットワークセキュリティのベストプラクティス

ネットワークセキュリティのベストプラクティスは以下の通りです

ネットワークポリシーを使用する
プライベート接続を使用する
Snowflakeへアクセスするクライアント通信をFiwewallなどで保護する
外部ステージとして利用するユーザ側クラウドストレージのアクセスをSnowflakeと利用ユーザのみに制限する

ネットワークポリシーを使用する

通信元をIPv4レベルで制御することができるネットワークポリシーを使用して、不必要なIPアドレスからのアクセスを遮断し、セキュリティ強度を向上させます

例えば、Snowflakeには特定のIPアドレス(1.1.1.1)のクライアントしかアクセスしないのであれば、そのIPアドレス(1.1.1.1)のみアクセスを許可するネットワークポリシーを設定することで、その他のIPアドレス(2.2.2.2など)を暗黙的にブロックすることができます

ネットワークポリシーの設定できる箇所は3つ存在し

アカウントレベル
ユーザレベル
インテグレーションレベル
にそれぞれ異なる設定を行うことができます

アカウントレベル

アカウントレベルは、該当アカウントすべてに適用できるネットワークポリシーで、例えばA,B,C,DというユーザがSnowflakeアカウントに設定されていた場合、A,B,C,Dユーザすべてに同じネットワークポリシーを適用することができます

ユーザレベル

ユーザレベルネットワークポリシーは、該当ユーザのみに適用することができるネットワークポリシーです。もしアカウントレベルネットワークポリシーも同時に存在していた場合は、ユーザレベルネットワークポリシーが設定しているユーザに対しては、ユーザレベルネットワークポリシーのみが評価対象となります。

例えば、先ほどのA,B,C,Dユーザが設定されており、アカウントレベルネットワークポリシーと、ユーザDにのみユーザレベルネットワークポリシーが設定された場合

ユーザA：アカウントレベルネットワークポリシー
ユーザB：アカウントレベルネットワークポリシー
ユーザC：アカウントレベルネットワークポリシー
ユーザD：ユーザレベルネットワークポリシー
でそれぞれ評価されます

インテグレーションレベル

インテグレーションレベルネットワークポリシーは、SCIM及びSnowflake OAuthのインテグレーション設定に組み込むことができます

プライベート接続を使用する

Snowflakeは各CSPが提供する下記プライベート接続サービスの利用をサポートしています

AWS : AWS Privatelink
Azure : Azure Privatelink
GCP : Private service connect

プライベート接続経由でSnowflakeにアクセスすることでインターネットを経由せずにクライアントはSnowflakeにプライベートIPアドレスを使ってアクセスすることができます

インターネット接続を必要としないため、インターネットへのアクセスが制限されている環境下でもSnowflakeを利用することができます。（完全にインターネットが遮断されている環境下の場合は、Snowflakeの内部ステージへのトラフィックも確保しておく必要があります）

ただ、プライベート接続を設定しただけでは、インターネットからSnowflakeへのアクセスが自動的に遮断されるわけではありませんので、前述のネットワークポリシーとの併用もご検討ください

Snowflakeへアクセスするクライアント通信をFiwewallなどで保護する

データセンターなどに設置してあるFirewallやProxyなどでクライアントからのインターネットアクセスが制限されている場合は、Snowflakeのアクセスを許可するようにしてください

Snowflakeへのアクセス先はSYSTEM$ALLOWLISTもしくはSYSTEM$ALLOWLIST_PRIVATELINKで確認することができます

SYSTEM $ALLOWLIST、SYSTEM$ ALLOWLIST_PRIVATELINKを実行するとJSON形式で表記されるため、下記コードにて構造化データで表示すると見やすくなります

//ALLOWLIST
select t.value:type::varchar as type,
       t.value:host::varchar as host,
       t.value:port as port
from table(flatten(input => parse_json(system$allowlist()))) as t;


//ALLOWLIST_PRIVATELINK
select t.value:type::varchar as type,
       t.value:host::varchar as host,
       t.value:port as port
from table(flatten(input => parse_json(SYSTEM$ALLOWLIST_PRIVATELINK()))) as t;

外部ステージとして利用するユーザ側クラウドストレージのアクセスをSnowflakeと利用ユーザのみに制限する

エンドユーザ様のS3やBlobストレージからデータを読み込む際に、外部ステージとしてSnowflakeに登録することができますが、アクセス元をSnowflakeのみに制限することで、エンドユーザ様のS3やBlobストレージへのセキュリティを向上させることができます。

残りのセキュリティベストプラクティスについては別途解説していきます。