はじめに
Snowflakeでネットワークアクセスの制御をする際
ネットワークポリシーのみ使用していたところネットワークルールが登場したので使ってみようという内容です。
やりたいこと
ネットワークルールを使用したアクセス制御をしたい
ネットワークルールとは/ネットワークポリシーとは
ネットワークルール
・ネットワーク識別子を論理単位にグループ化するスキーマレベルのオブジェクト
・ネットワークルール作成によってアクセスの許可/拒否は設定されない （ただの箱）
→論理的な分割ができるので、あるとIPアドレスの管理がしやすい（色々用途はありそうだが一旦この理解で十分なはず）
ネットワークポリシー
・Snowflakeサービスおよび内部ステージへのインバウンドアクセスを制御できる
・ネットワークポリシーの許可リストは、Snowflakeサービスまたは内部ステージへのアクセスを許可するアクセスを制御し、 ブロックリストは明示的にブロックするリクエストを制御する
Snowflakeへのインバウンドアクセスの制限は、ネットワークポリシーで適用されますが、管理者はスキーマレベルのオブジェクトであるネットワークルールを使用してこれらの制限を整理できます。
→つまり、ネットワークルールでIPアドレスのリストを論理分割し、それらをネットワークポリシーに追加しインバウンドアクセスの制御する
ネットワークルールとネットワークポリシーのイメージ↓
参考：
ネットワークルール https://docs.snowflake.com/ja/user-guide/network-rules
ネットワークポリシー https://docs.snowflake.com/ja/user-guide/network-policies
ネットワークルールを使わないとどうなる？
・ネットワークポリシーのみを使用した制御はIPアドレスの羅列となるためどれが何の接続かわかりづらい
イメージ
ネットワークルールを併用するのがよさそう！
ネットワークルールを使ってみよう
構成案
以下の考え方と組み合わせて使うとよさそう
・セキュリティ管理用にデータベースを一つ作成（データ蓄積用DBと役割を分ける）
・スキーマを切ってネットワークルールを管理
・このDBには基本的にセキュリティ管理者や基盤管理者のみがアクセスできるようにする（例外あり、後述）
イメージ↓
この構成を軸に活用例について考えました。
活用例その１ IPリストを論理的に整理できる！
前述の構成をベースに、例えば、
snowflakeに蓄積されたデータを利用した分析やダッシュボード開発を外部ベンダーに依頼したい場合
以下のように社内用の接続情報とそれ以外をネットワークルールで区別しておく。
外部ベンダーの作業が不要になったら、ネットワークポリシーXのリストから不要なネットワークルールを外せばOKでとてもシンプル。
このように論理分割することで楽に判別/制御できる！
サンプルコードはこちら
--ウェアハウスを選択
USE ROLE SECURITYADMIN;
GRANT USAGE ON WAREHOUSE XXX TO ROLE SECURITYADMIN;
GRANT USAGE ON WAREHOUSE XXX TO ROLE SYSADMIN;
--セキュリティ管理用データベースを作成
USE ROLE SYSADMIN;
CREATE DATABASE DB_SECURITYMANAGEMENT;
--SECURITYADMINへセキュリティ管理用データベースのUSAGE権限（触るだけみたいな）を付与
GRANT USAGE ON DATABASE DB_SECURITYMANAGEMENT TO ROLE SECURITYADMIN;
--SECURITYADMINへ今後作成されるスキーマの所有権を譲渡（ネットワークルールが紐づくスキーマの所有権を所持していないとCREATE NETWORK RULEの実行ができないため）
USE ROLE SECURITYADMIN;
GRANT OWNERSHIP ON FUTURE SCHEMAS IN DATABASE DB_SECURITYMANEGEMENT TO ROLE SECURITYADMIN;
--スキーマを作成
USE ROLE SYSADMIN;
CREATE SCHEMA DB_SECURITYMANEGEMENT.SC_NETWORK_RULE_ACCOUNT;
--ネットワークルールを紐づけるデータベース、スキーマを指定
USE ROLE SECURITYADMIN;
USE DATABASE DB_SECURITYMANEGEMENT;
USE SCHEMA DB_SECURITYMANEGEMENT.SC_NETWORK_RULE_ACCOUNT;
--ネットワークルールの作成
CREATE NETWORK RULE 'ネットワークルール_社内'
MODE = INGRESS
TYPE = IPV4
VALUE_LIST =('xxx.xx.xx.xx' --端末IP
,...
,...
);
CREATE NETWORK RULE 'ネットワークルール_x社'
MODE = INGRESS
TYPE = IPV4
VALUE_LIST =('xxx.xxx.xx.xx/xx' --端末IP
,...
,...
);
--上記のネットワークルールを許可リストに追加するネットワークポリシーを作成
CREATE NETWORK POLICY ALLOWIP
ALLOWED_NETWORK_RULE_LIST=('ネットワークルール_社内'
,'ネットワークルール_x社'
);
--作成したネットワークポリシーをアカウント全体へ適用（ここで有効になる）
ALTER ACCOUNT SET NETWORK_POLICY = ALLOWIP;
活用例その2 管理者でなくてもIPリストの管理ができる！
（一見危なそうに見えますが、読んでみてください↓）
言わずもがなですが、ネットワークセキュリティは超重要なので
セキュリティ管理者的にはそう簡単にネットワークポリシーを操作する権限は他者に付与したくないはず。
となるとIPリストの管理（追加/削除）セキュリティ管理者が都度対応しないとならない。
ですが、ネットワークルールはスキーマオブジェクトなので
権限を適切に付与すれば基盤管理者やセキュリティ管理者でなくてもネットワークルールの管理が可能！
セキュリティ管理用DBや配下のスキーマへの閲覧/操作権限は適切に付与されている前提
例えば、
データ基盤の利用が社内にどんどん広がって、事業部ごとに管理する領域ができたとする。
A事業部は基盤上のデータを使用したダッシュボード開発を外部ベンダー１に依頼するので外部ベンダー１のアクセスを許可したい場合
次のようにA事業部用のスキーマをセキュリティ管理者が準備してあげれば全体のネットワーク管理から切り離せる。
さらに、適切に権限を付与していればIPに変更が生じてもA事業部の管理者がルールにIPを追加/削除できる。
→安全に素早くユーザー側で整理ができる！
ネットワークルールを作成するだけでは適用されないので、肝心のネットワークポリシーによる有効化/無効化はセキュリティ管理者が行い、その中身は事業部側で整理するということが実現可能！効率的に運用できそうです。
（10/18 他のケースも思いついたので追記）
データ基盤、ダッシュボード、など分野ごとに管理者が異なることもあると思います。そんなときは事業部ごとではなく、その分野ごとにスキーマを準備しルールを作成することもありです。
SaaSを使っているとIPアドレスが変更になることは少なくないです。上記のような構成にしておけば、例えばBIツール（SaaS）を使用していても、アップデートに応じてダッシュボード分野の人がネットワークルールを変更するということもできます！
まとめ・所感
・ネットワークルールで論理分割できる
・ネットワークルールはユーザーも編集できる
・ネットワークルールは便利！
ネットワークルールをユーザー側で制御できるようにしようとすると、適切なロール設計を考えるほうに時間がかかりました。
例えば、
・セキュリティ管理用DBはデータが蓄積されるDBと同じようにロール設計（RBAC）したほうがいいのか？
・スキーマ作成は管理者orユーザー側？
・ネットワークルールの変更はもちろんユーザー側だが、ネットワークルール自体の作成や削除は管理者orユーザー側？
などなど。
個人的にはセキュリティ管理用DBとデータ用のDBは扱いが異なると思うので同じロール設計でなくてよいかなと思います。この辺りは組織ごとに運用に対する考え方の違いが出てくるのだと思いました。
ネットワークアクセスについて考えていたのに、
ロール設計って深い～そして難しい～～～という結論に至りました。
ロール設計（RBAC）についてもそのうちまとめようと思います。