Snowflake アカウント全体に MFA 設定を強制できるように

情報窃取被害にあわないために

ここ最近、不正アクセスによる個人情報の流出がしばしば話題になっていますね。弊社もデータを取り扱う身として決して他人事ではありませんので、今一度セキュリティについて見直さなければいけません。

2024年7月10日に Snowflake から「アカウント全体に MFA を強制できるようになった」という記事が公開されていました。セキュリティレベルをあげるための新機能の紹介と、ベストプラクティスの改めてのアナウンスです。せっかくなのでこの機にポリシーを見直すことにします。

発表された新機能

MFA 設定を促すポップアップ

MFA を設定していないユーザが Snowsight にログインした際に、MFA 設定を促すポップアップが表示されるようになりました。一瞬 MFA を外して試してみたところ、たしかにログイン時に表示され MFA 設定手順の案内までありました 🔐 Untitled

実際に確認はしていませんが、どうやら Not now を選択しても 3 日後に再表示してくれるみたいです。

アカウント内の全ユーザに MFA 設定の強制

MFA を設定していないユーザにリマインドするだけでなく、アカウント全体に MFA 設定を強制するというポリシーを適用できるようになりました。MFA 未設定の運用者に「MFA 設定してください 🤬」としつこく言わなくていいので大助かりの機能です 🎉

情報漏洩リスクを低減するためのベストプラクティス

前述の新機能も盛り込まれているベストプラクティスを記載したホワイトペーパーが Snowflake から出されていますので、しっかり読んでこの通りに設定していきます。

サービスユーザのポリシー

まずはサービスユーザ向けの認証ポリシーを作成します。

サービスユーザは Snowsight にログインする必要もありませんし、外部との接続でパスワード認証を必要とするサービスがない限りは OAuth またはキーによる認証のみに絞ってしまってよいでしょう。

CREATE OR REPLACE AUTHENTICATION POLICY service_user_auth_policy  
	CLIENT_TYPES = ('ALL')  
	AUTHENTICATION_METHODS = ('OAUTH', 'KEYPAIR')  
	SECURITY_INTEGRATIONS = ('ALL');

ちなみに、デフォルトでは ACCOUNTADMIN, ORGADMIN, SECURITYADMIN のロールでは OAuth 認証ができませんので、あんまりないと思いますが認証したくなった時には OAUTH_ADD_PRIVILEGED_ROLES_TO_BLOCKED_LIST を false にしてあげると OAuth 認証できるようになります。

ALTER ACCOUNT SET OAUTH_ADD_PRIVILEGED_ROLES_TO_BLOCKED_LIST = false;

認証ポリシーの次はネットワークポリシーです。

AWS や Azure から接続する場合には設定しておいた方がよいですね。

CREATE OR REPLACE NETWORK RULE aws_private_link_rule
	TYPE = AWSVPCEID
	VALUE_LIST = ( ['hogehoge', ... ] )
	MODE = INGRESS;
   
CREATE OR REPLACE NETWORK POLICY service_user_network_policy
	ALLOWED_NETWORK_RULE_LIST = ('aws_private_link_rule');

サービスユーザ以外のポリシー

こちらは人間による操作となるのでパスワード認証を避けられません。パスワード認証が残ってしまう以上は MFA 設定はマストになりますので、新機能を利用していきます。

CREATE OR REPLACE AUTHENTICATION POLICY mfa_enforcement_auth_policy
	CLIENT_TYPES = ('ALL')  
	MFA_ENROLLMENT = ('REQUIRED')
	MFA_AUTHENTICATION_METHODS = ('PASSWORD');

そして MFA 設定をマストにしているとはいえ、パスワードの強度も弱くてはいけません。パスワードポリシーも作成しておきましょう。

CREATE OR REPLACE PASSWORD POLICY account_password_policy
	PASSWORD_MIN_LENGTH = 32  -- 32文字以上
	PASSWORD_MAX_AGE_DAYS = 30  -- 30日ごとに更新
	PASSWORD_MIN_UPPER_CASE_CHARS = 6  -- 大文字を6文字以上
	PASSWORD_MIN_LOWER_CASE_CHARS = 6  -- 小文字を6文字以上
	PASSWORD_MIN_NUMERIC_CHARS = 4  -- 数字を4文字以上
	PASSWORD_MIN_SPECIAL_CHARS = 8  -- 記号を8文字以上
	PASSWORD_MAX_RETRIES = 3  -- 間違いは３回まで
	PASSWORD_LOCKOUT_TIME_MINS = 30 -- LOCKされると30分待機
	PASSWORD_HISTORY = 24;  -- 過去24回と同じパスワードは使用できない

ここではホワイトペーパーの通りに記載していますが、ここまで厳しいと「パスワードリセットの回数が増えて運用しづらい」なんて声もあがるかもしれません 😅

続いてネットワークポリシーです。リモートワークが多いなど難しい場面もあるかもしれませんが、社内からのアクセスに限定しておくと安心です。

CREATE OR REPLACE NETWORK RULE allow_src_ip_rule
	TYPE = IPV4
	VALUE_LIST = ( ['xx.xx.xx.xx/24', ... ] )
	MODE = INGRESS;
   
CREATE OR REPLACE NETWORK POLICY account_network_policy
	ALLOWED_NETWORK_RULE_LIST = ('allow_src_ip_rule');

ポリシーの適用

いよいよポリシーを適用したいところですが、その前にセッションポリシーも作成しておきましょう。

CREATE OR REPLACE SESSION POLICY account_session_policy
	SESSION_IDLE_TIMEOUT_MINS = 240 -- システム連携の場合
	SESSION_UI_IDLE_TIMEOUT_MINS = 20 -- Snowsightアクセスの場合

これで準備が整いました。

Snowflake ではポリシーをアカウント単位でもユーザ単位でも作成できます。ただしユーザ単位の設定がある場合はアカウント単位のポリシーよりもそちらが優先されます。

サービスユーザは接続先や利用シーンによってベストな設定が異なることが想定されるため、

サービスユーザ以外に向けて作成したポリシーをアカウント全体に適用
サービスユーザにはユーザ単位で適用

としてあげるのがよさそうです。

ALTER USER {service_user} SET
	AUTHENTICATION POLICY = service_user_auth_policy
	NETWORK_POLICY = service_user_network_policy;

ALTER ACCOUNT SET
	AUTHENTICATION POLICY = mfa_enforcement_auth_policy
	SESSION POLICY = account_session_policy
	PASSWORD POLICY = account_password_policy
	NETWORK_POLICY = account_network_policy;

パスワード認証が必要なくなったサービスアカウントはパスワードをなくしてしまってもよいかもしれませんね。

ALTER USER {service_user_name} UNSET password

ただし、Snowflake OAuth を利用する場合は認証時に Snowflake のパスワードでの認証を前提としているようですので、OAuth 認証だからといって必ずしもパスワードをなくせるわけではないことには注意が必要です ⚠️

Trust Center によるモニタリング

いつのまにか Snowsight にこんな機能が追加されていました。 Untitled

セキュリティリスクを評価 & 指摘してくれるみたいです。

Trust Center のチェックは今後の運用にとりいれたいと思います。

サービスユーザの識別

ここまで、 ”サービスユーザ” と ”サービスユーザ以外” を区別し記載してきましたが、現状 Snowflake 上ではこれらは区別されているわけではありません。明示されていればいいなと思っていたところ、 coming soon ( ※ 2024年8月27日リリース予定のようです) でユーザに TYPE=SERVICE という属性が追加されるとホワイトペーパーに記載されていました👏

TYPE=SERVICE を設定すると、自動でパスワードや SAML SSO による認証ができなくなり、当然ながら MFA 設定も対象外となるため、MFA 設定強制ポリシーから除外してくれるようです。これでわざわざサービスユーザ向けの認証ポリシーを設定しなくてもよくなるので管理が簡潔になります。

しかも、OAuth やキーを用いた認証に対応していないレガシーなシステムとの接続にサービスユーザを利用する場合にも考慮して、TYPE=LEGACY_SERVICEという MFA 設定強制ポリシーからは除外しつつも引き続きパスワード認証できるタイプも用意してくれるようです。

おわりに

今回は Snowflake アカウントの見直しを行いました。

セキュリティとユーザビリティはトレードオフの関係にあるとされていますが、おざなりのまま運用していざ情報漏洩してしまうと、その後片付けの方が圧倒的に面倒です。

なので、運用とのバランスを鑑みながら「守るところは守りつつもできるだけ簡潔に」をモットーにポリシーを定め、かつ新機能のリリースに合わせて定期的なポリシーの見直しを続けていかなければいけません 💪