Snowflakeの認証戦略について
はじめに
先日、SnowVillageのイベント「SnowVillage Unconference #2」に参加し、Snowflakeの認証周りの話をしました。
本記事はその時に発表した内容を元にブログ化したものです。
ここで言っている「認証戦略」とは、ユーザー認証のレイヤで提供されている様々な機能を組み合わせて、Snowflakeのアカウントセキュリティを守るための対策を考える、ということを指しています。
なお、本記事の内容は個人の見解に基づくものであり、所属企業を代表するものではありません。
導入①：AT&Tの情報漏洩事件について
アメリカ最大の電気通信事業者であるAT&Tにて、Snowflake環境が不正にアクセスされ、情報漏洩につながったという事件がありました。
これはSnowflakeを標的とした脅威キャンペーンの一環であり、攻撃者は情報を窃取するマルウェアを通じて認証情報を不正に入手し、Snowflake環境に不正アクセスしたと見られています。
この事件は、Snowflakeプラットフォーム自体の脆弱性や設定ミスなどによって引き起こされたものではなく、ユーザー側のセキュリティコントロールの欠落によるものだとされており、特にMFAが設定されていれば確実に防げていた事故です。
またとある報告によれば、Snowflakeアカウントへの攻撃を受けた企業のうち、以下のようなケースで情報漏洩につながっているとのことです。
- ユーザー名/パスワードのみの弱い認証でMFAが設定されていなかった。
- 古い資格情報が数年間有効なままだった。
- ネットワークポリシーによるIP制限が行われていなかった。
「流石にアンチパターンが過ぎるぞ」とも思える構成ですが、結局データを守るのはユーザーの責任範囲なので、利用ユーザー側でSnowflakeアカウントのセキュリティ対策を考えなければならない、ということですね。
導入②：ネットワークポリシーの限界
流石にネットワークポリシーは最低限設定している、という環境も多いのではないでしょうか。では、ネットワークポリシーだけ設定すればアカウントは安全かというと、そうとは言い切れないのでは？というのが最近の私の見解です。（AWSのPrivateLink等でプライベート接続を構成している場合を除きます）
ネットワークポリシーについて、かなりざっくりと図に起こすと以下のようなイメージになります。
この時、マルウェアに感染した社内ホストからの不正アクセスや、IPスプーフィング（なりすまし）による不正アクセスは、ネットワークポリシーで防ぐことはできません。接続元のIPアドレス自体は、ネットワークポリシーで許可されているものだからです。
マルウェア感染端末からの不正アクセスの例
では、ネットワークポリシーの制御をくぐり抜けてアクセスされたら即座に情報漏洩につながるのでしょうか？いえ、そうではありません。
ここで、Snowflakeの階層型セキュリティの考え方を導入すると、ネットワーク経路の次の「ユーザー認証」の層でブロックできればそれ以降の階層には侵入されないと考えることができます。
そのため、ネットワークアクセスのレイヤが万が一突破されてしまったことを想定して、ユーザー認証のレイヤでしっかりとブロックできるような仕組みを考える必要があります。
本題：認証戦略とその実装方法
ということで、前段が長くなりましたが、Snowflakeアカウントをセキュアに守るための認証戦略について、具体的に掘り下げてみようと思います。
今回は以下で示されているベストプラクティスも参考にしながらまとめてみました。
Snowflakeで用意されている認証方式は、大きく分けると以下の5つになります。
| 認証方法 | 使用できるアクセス方式 Snowsight / サービスアクセス |
|---|---|
| ユーザー名・パスワードのみ ※セキュリティ強度が最も弱い |
Snowsight、サービスアクセス |
| ユーザー名・パスワード ＋MFA |
Snowsight、サービスアクセス |
| SAML SSO | Snowsight |
| キーペア | サービスアクセス |
| OAuth | サービスアクセス |
参考：https://www.snowflake.com/en/resources/pattern/snowflake-pattern-security-authentication/
最もセキュリティ強度が弱い「ユーザー名・パスワードのみ」の認証方式では、ユーザー名とパスワードが漏れると簡単に不正アクセスを許してしまいます。そのため、「ユーザー名・パスワードのみ」を採用することは避けるとして、認証戦略を以下のように考えることができます。
-
Snowsight：
- （基本方針）ユーザー名・パスワードのみの認証方式を採用せず、SAML SSO認証を使用する。
- どうしてもユーザー名・パスワード認証を使わざるを得ない場合は、MFA必須とする。
※IdP停止時のことを考えて、アカウント管理者はあえて「ユーザー名・パスワード+MFA」としておく、という考えもある
-
サービスアクセス（BIツール、ETLツールなど）
- ユーザー名・パスワード以外の認証方式（キーペア、OAuth）を使用する。
2つ目のサービスアクセスで「ユーザー名・パスワード＋MFA」という認証方式を取らないのは、アクセスのたびにMFA認証を求めるのは現実的ではないためです。
では、上記の認証方式を実現する方法を具体的に見ていきましょう。
認証ポリシーの設定
認証ポリシーで以下の設定を行います。
- アカウント全体でMFA必須の認証ポリシーを適用する。
- ユーザーの用途に応じた
AUTHENTICATION_METHODS、CLIENT_TYPESの設定を行う。
これによってSnowsightにアクセスするユーザーにMFAを強制しつつ、用途に応じた適切な認証方式を制御することができるようになります。
まずは、MFA必須の認証ポリシーからです。サンプルSQLのイメージは以下の通りです。
CREATE AUTHENTICATION POLICY require_mfa_authentication_policy
AUTHENTICATION_METHODS = ('SAML', 'PASSWORD')
SECURITY_INTEGRATIONS = (‘<SAMLセキュリティ統合>’)
MFA_AUTHENTICATION_METHODS = ('PASSWORD') -- パスワード認証の場合にMFAを強制
MFA_ENROLLMENT = REQUIRED;
ALTER ACCOUNT SET AUTHENTICATION POLICY require_mfa_authentication_policy;
（注）SAML SSO認証の場合は、IdP側のMFAの仕組みを使いましょう。
IdP側でMFAの仕組みがない場合や、IdP側とSnowflake側でダブルでMFAを
設定したい場合は、MFA_AUTHENTICATION_METHODSに'SAML'を追加します
上記SQLを実行した後に、MFAを設定していないパスワード認証のユーザーでSnowsightにログインしようとすると、以下のような画面になりMFA設定が強制されます。
次にユーザー単位の認証ポリシーで、適切なAUTHENTICATION_METHODS、CLIENT_TYPESの設定が必要な場合は追加で認証ポリシーを作成して適用します。
例えば、Snowsightにログインできないユーザーを作りたい場合、以下のようなSQLになります。
CREATE AUTHENTICATION POLICY programmatic_access_user_auth
AUTHENTICATION_METHODS = ('OAUTH', 'KEYPAIR')
CLIENT_TYPES = ('DRIVERS', 'SNOWSQL')
SECURITY_INTEGRATIONS = (‘<OAuth セキュリティ統合>’);
ALTER USER user_a SET AUTHENTICATION POLICY programmatic_access_user_auth;
参考：https://docs.snowflake.com/en/user-guide/authentication-policies
https://zenn.dev/y_matsubara/articles/snowflake-authentication_policies-20240308
この状態で、user_a でSnowsightにログインしようとすると、以下のようにしっかりブロックしてくれます。
パスワードポリシーの設定
パスワードポリシーを設定することで、最低文字数の設定や特殊文字や大文字小文字の混在など、強力なパスワードルールを定義することができます。さらに、パスワードの有効期限を設けることもできます。
これにより、万が一（操作ミスなどで）ユーザー名・パスワード認証のみになってしまった場合に、認証が突破されるリスクを少しでも抑えることができます。
パスワードポリシーのSQL例は以下の通りです。
CREATE PASSWORD POLICY PASSWORD_POLICY_PROD_1
PASSWORD_MIN_LENGTH = 12
PASSWORD_MAX_LENGTH = 24
PASSWORD_MIN_UPPER_CASE_CHARS = 2
PASSWORD_MIN_LOWER_CASE_CHARS = 2
PASSWORD_MIN_NUMERIC_CHARS = 2
PASSWORD_MIN_SPECIAL_CHARS = 2
PASSWORD_MIN_AGE_DAYS = 1
PASSWORD_MAX_AGE_DAYS = 30
PASSWORD_MAX_RETRIES = 3
PASSWORD_LOCKOUT_TIME_MINS = 30
PASSWORD_HISTORY = 5
COMMENT = 'production account password policy';
参考：https://docs.snowflake.com/ja/sql-reference/sql/create-password-policy
Snowflakeのベストプラクティスに関するホワイトペーパーでは、より厳しいパスワードポリシーになっていますが、他の認証戦略の方が大事なので、運用の煩雑さとトレードオフで考えるのが良いと思います。
ユーザー「TYPE」プロパティの活用
こちらは最近リリースされた機能で、SnowflakeのユーザーオブジェクトにTYPEというプロパティが追加されました。
サービスアクセスのために作成するユーザーはTYPE='SERVICE'と設定することで、以下のような特性を持つユーザーとなります。
- パスワード、SAML SSOを使用してログインできない
- MFA登録ができない
- MFA強制の認証ポリシーの適用外になる
- 以下のプロパティを持たない
- FIRST_NAME
- MIDDLE_NAME
- LAST_NAME
- PASSWORD
- MUST_CHANGE_PASSWORD
- MINS_TO_BYPASS_MFA
- 次のコマンドは使用できない
- ALTER USER RESET PASSWORD
- ALTER USER SET DISABLE_MFA = TRUE
ここで重要なのは、TYPE='SERVICE'のユーザーは前述したMFA強制の認証ポリシーの適用外になるということです。今回の認証戦略とも上手くマッチしてくれます。
参考：https://docs.snowflake.com/en/sql-reference/sql/create-user#label-user-type-property
https://dev.classmethod.jp/articles/snowflake-user-type-property/
TYPE='SERVICE'のユーザーを使う場合、キーペア、もしくはOAuthでの認証を採用しなければいけないため、クライアントアプリケーション側でサポートされている認証方式や必要な設定も確認した上で、戦略を検討するようにしましょう。
ちなみにTYPE='SERVICE'のユーザーを使って、Snowsightにパスワード認証方式でログインしようとすると、以下のようなエラーになります。
「間違ったユーザー名またはパスワードが指定されました。」だとエラー内容が分かりにくいので、TYPEによってはじかれたことが分かるようなメッセージになると有難いですね。
認証戦略サマリ
ここまでの内容をサマリすると以下の通りです。
-
認証ポリシー
- アカウント全体でMFA必須の認証ポリシーを適用する
- ユーザーの用途に応じた
AUTHENTICATION_METHODS、CLIENT_TYPESの設定を行う
-
パスワードポリシー
- ○○文字以上にする、特殊文字や大文字小文字の混在など、強力なパスワードを設定する
- パスワードの有効期限を設ける
-
ユーザー「TYPE」プロパティ
- サービスアクセスユーザーのプロパティにて
TYPE='SERVICE'とする。
- サービスアクセスユーザーのプロパティにて
補足：Trust Centerで検知できる内容抜粋
Trust CenterはSnowflakeアカウントのセキュリティリスクを評価、モニタリングする機能です。 すでにGAとなっている、「CIS Benchmarks scanner package」で検知できる内容をいくつかピックアップしてみます。
| スキャナー名 | 説明サマリ |
|---|---|
| Ensure single sign-on (SSO) is configured for your account / organization | SAML SSOが適用されている。 |
| Ensure multi-factor authentication (MFA) is turned on for all human users with password-based authentication | パスワード認証の全ユーザーに対してMFAが有効になっている。 ※ACCOUNTADMIN、SECURITYADMIN、MANAGE GRANTS権限を持つロールが紐づいている場合、「CRITICAL」な違反と見なされる。 |
| Ensure minimum password length is set to 14 characters or more | パスワードポリシーを作成して、14文字以上のパスワードを強制する。 |
| Ensure that service accounts use key pair authentication | サービスアクセスユーザーでキーペア認証が適用されている。 |
| Ensure authentication key pairs are rotated every 180 days | 少なくとも180日に一回、キーペアをローテーションして置き換える。 |
| Ensure that users who did not log in for 90 days are disabled | 90日以上ログインの無いユーザーは無効化させる。 |
| Ensure that an account-level network policy has been configured to only allow access from trusted IP addresses | アカウントレベルのネットワークポリシーが信頼できるIPからのアクセスのみを許可している。 ※内容のチェックまではできない。 |
| Ensure that user-level network policies have been configured for service accounts | ユーザーレベルのネットワークポリシーがサービスアクセスユーザーに適用されている。 |
このように、今回紹介した認証戦略に関連する検知項目が用意されているため、各設定が実装できた後はTrust Centerも有効化して監視していくのが良いと思います。
まとめ
今回ご紹介した内容のまとめです。
-
ネットワークポリシーを設定しよう
（Snowsightでのネットワークポリシー、ネットワークルールも最近GAになりましたね） -
適切な認証戦略を立てよう
- Snowsight接続ユーザーの認証方式はSAML SSOを推奨！
※どうしてもユーザー名・パスワード認証を使いたい場合はMFAを必須に！ - サービスアクセスユーザーではキーペア認証かOAuth認証を使おう！
- Snowsight接続ユーザーの認証方式はSAML SSOを推奨！
- Trust Centerを有効化してアカウントの脆弱性をチェックしよう！
ということで、認証周りのアップデートが最近多かったので、現時点での情報を元に認証戦略をまとめてみました。
今後もアップデートが続くかもしれないので、最新情報は要チェックですね！Snowflakeの機能を活用して、定期的にセキュリティポリシーを見直していきましょう。
Discussion