はじめに:Snowflakeではパスワードだけのログインから強力な認証へ
Snowflakeでは、セキュリティ強化のためにパスワードだけでログインする単一要素認証から、MFA・SSO・キーペア認証・OAuth・Workload Identity Federationなどの強力な認証方式へ移行する流れが進んでいます。特に人間ユーザーがパスワードでログインする場合はMFAが重要になり、アプリケーションやETLツールで使うサービスユーザーではパスワード以外の認証方式を検討する必要があります。
2026年時点では、Snowflakeは単一要素パスワードログインの段階的な廃止を進めています。具体的な適用時期や挙動は、契約形態・リージョン・Behavior Change Bundleの適用状況によって差があるため、最新情報はSnowflake公式ドキュメントと組織のアカウントマネージャーで確認してください。
本記事では、Snowflake初心者の方に向けて、MFA・SSO・Authentication Policy・サービスユーザー認証の全体像と、実務でそのまま使えるSQL例を整理します。
MFA・SSO・強力な認証方式の全体像
Snowflakeの認証は、大きく次の要素に分けて考えると整理しやすくなります。
- MFA:パスワード + 追加要素(認証アプリ・OTPなど)で人間ユーザーのログインを強化
- SSO(SAML2):Okta、Microsoft Entra ID、Google WorkspaceなどのIdPで認証を集約
- キーペア認証:公開鍵・秘密鍵を使ったサービスユーザー向け認証
- OAuth:BIツールや外部アプリ連携で使いやすい認証
- Programmatic Access Token:短期間・スコープ付きでプログラム接続に使うトークン
- Workload Identity Federation(WIF):長期シークレットを持たずに、クラウドワークロードから接続する仕組み
- Authentication Policy:認証方式やMFA要件をアカウント・ユーザー単位で制御するポリシー
これらを人間ユーザーとサービスユーザーに分けて使い分けるのが基本方針です。
人間ユーザーとサービスユーザーの違い
Snowflakeでは、ユーザーを大きく「人間ユーザー」と「サービスユーザー」に分けて考えます。両者は使い方も推奨される認証方式も異なるため、設計時に分けておくことが重要です。
- 人間ユーザー:実際の利用者がSnowsightやクライアントツールからログインするユーザー。
TYPE = PERSONを指定します。TYPEを明示しない場合やNULLの場合も、人間ユーザー扱いになります。 - サービスユーザー:アプリケーション、ETL、BIツール、CI/CDなどが使う非対話型ユーザー。
TYPE = SERVICEを指定します。MFAのような対話型認証ではなく、キーペア認証・OAuth・Programmatic Access Token・Workload Identity Federationなどを検討します。
-- 人間ユーザーの例
CREATE USER taro_yamada
TYPE = PERSON
LOGIN_NAME = 'taro@example.com'
EMAIL = 'taro@example.com';
-- サービスユーザーの例
CREATE USER svc_etl_loader
TYPE = SERVICE
LOGIN_NAME = 'svc_etl_loader';サービスユーザーにMFAを要求しても、対話的にOTPを入力できないため運用が回りません。設計段階から「このユーザーは人間か、サービスか」を意識して作成しましょう。
MFAとは?
MFA(Multi-Factor Authentication、多要素認証)は、パスワードに加えてもう一つの認証要素を要求する仕組みです。Snowflakeでは、Duo Mobile などの認証アプリで生成するワンタイムコードを使うのが代表的なパターンです。
パスワードが漏えいしても、認証アプリの承認やOTP入力がなければログインできないため、不正ログインのリスクを大きく下げられます。Snowflakeで人間ユーザーがパスワード認証を使う場合、MFAは事実上必須と考えてよい設定です。
SSOとは?
SSO(Single Sign-On)は、企業の認証基盤(IdP:Identity Provider)に一度ログインすれば、各サービスに個別のパスワードを入力せずにログインできる仕組みです。Snowflakeでは主にSAML2を使ったSSOがサポートされており、Okta・Microsoft Entra ID(旧Azure AD)・Google Workspaceなどと連携できます。
SSOを導入すると、退職者のアカウント無効化・パスワードポリシー・MFA要件などをIdP側で一元管理できるため、運用負荷とリスクを減らせます。
MFAとSSOの違い
MFAとSSOはどちらも認証強化に使われますが、役割は別物です。次の表で整理しておきましょう。
| 項目 | MFA | SSO |
|---|---|---|
| 目的 | パスワード漏えい時の不正ログインを防ぐ | 企業の認証基盤にログインを統一する |
| 主な対象 | 人間ユーザー | 人間ユーザー |
| 代表例 | パスワード + Duo Mobile / OTP | Okta / Microsoft Entra ID / Google Workspace |
| Snowflake側の設定 | MFA登録、Authentication Policy | SAML2 Security Integration |
| 注意点 | サービスユーザーには向かない | IdP側でMFAを強制する設計が重要 |
実務では、SSOで認証を集約しつつ、IdP側でMFAを強制するのが標準的なゴールです。Snowflake側でも追加でMFAを要求したい場合は、Authentication Policyを使います。
SnowsightでMFAを登録する方法
人間ユーザーがパスワード認証を使う場合、Snowsightから自分でMFAを登録します。手順の概要は次の通りです。
- Snowsightにログインし、右上のユーザーアイコンから My Profile を開く
- Multi-factor authentication の項目で Enroll を選択する
- スマートフォンに Duo Mobile などの認証アプリをインストールし、QRコードを読み取る
- 表示された確認コードを入力し、登録を完了する
MFAを登録できるようにするには、Authentication Policyで CLIENT_TYPES に SNOWFLAKE_UI を含めておく必要があります。デバイス紛失時のリセット手順も、運用ルールとして事前に決めておきましょう。
Authentication PolicyでMFAを必須化する方法
Authentication Policyを使うと、MFA登録の必須化、認証方式、SSOユーザーへのMFA要求、利用できるクライアント種別をまとめて制御できます。アカウント単位・ユーザー単位の両方で設定可能です。
パスワードユーザーにMFAを必須化する例:
USE ROLE ACCOUNTADMIN;
CREATE AUTHENTICATION POLICY require_mfa_for_password_users
MFA_ENROLLMENT = 'REQUIRED'
MFA_POLICY = (
ENFORCE_MFA_ON_EXTERNAL_AUTHENTICATION = 'NONE'
);
ALTER ACCOUNT SET AUTHENTICATION POLICY require_mfa_for_password_users;SSOユーザーにもSnowflake側のMFAを要求する例:
USE ROLE ACCOUNTADMIN;
CREATE AUTHENTICATION POLICY require_mfa_for_all_auth
MFA_ENROLLMENT = 'REQUIRED'
MFA_POLICY = (
ENFORCE_MFA_ON_EXTERNAL_AUTHENTICATION = 'ALL'
);
ALTER ACCOUNT SET AUTHENTICATION POLICY require_mfa_for_all_auth;- SSOユーザーのMFAは通常IdP側で制御することが多いです。
- Snowflake側でも追加でMFAを求めたい場合に
ENFORCE_MFA_ON_EXTERNAL_AUTHENTICATION = 'ALL'を検討します。 MFA_ENROLLMENTを使う場合、ユーザーがMFA登録できるようにCLIENT_TYPESにSNOWFLAKE_UIを含める必要があります。- オプションの厳密な名前・挙動はSnowflake側の仕様変更で更新される可能性があるため、最新情報は公式ドキュメントを確認してください。
SSOを設定する方法
SSOは、SnowflakeにSAML2の Security Integration を作成し、IdP側にSnowflakeをアプリケーションとして登録することで設定します。証明書を直接貼り付ける方法もありますが、METADATA_URL を使うとIdP側のメタデータを参照でき、証明書更新時の管理がしやすくなります。
USE ROLE ACCOUNTADMIN;
CREATE SECURITY INTEGRATION my_okta_sso
TYPE = SAML2
ENABLED = TRUE
METADATA_URL = 'https://your-company.okta.com/app/xxxx/sso/saml/metadata'
SAML2_SNOWFLAKE_ISSUER_URL = 'https://<orgname>-<account_name>.snowflakecomputing.com'
SAML2_SNOWFLAKE_ACS_URL = 'https://<orgname>-<account_name>.snowflakecomputing.com/fed/login';METADATA_URLを使うとIdP側のメタデータを参照でき、証明書ローテーション時の更新が楽になります。SAML2_SNOWFLAKE_ISSUER_URLとSAML2_SNOWFLAKE_ACS_URLは、IdP側に設定したSnowflake URLと一致させます。- ACS URLには通常
/fed/loginが付きます。 SAML2_ENABLE_SP_INITIATEDを有効にすると、Snowflakeのログイン画面からSSOボタンを表示できます。
SP initiated loginを有効化する例:
ALTER SECURITY INTEGRATION my_okta_sso
SET SAML2_ENABLE_SP_INITIATED = TRUE;
ALTER SECURITY INTEGRATION my_okta_sso
SET SAML2_SP_INITIATED_LOGIN_PAGE_LABEL = 'Okta';続いて、SSO対象ユーザーの LOGIN_NAME や EMAIL をIdP側のメールアドレスやNameIDに合わせます。
ALTER USER taro_yamada SET
LOGIN_NAME = 'taro@example.com'
EMAIL = 'taro@example.com'
DISABLED = FALSE;- IdP側のNameIDまたはユーザー識別子と、Snowflake側の
LOGIN_NAME/EMAILの対応を必ず確認します。 - ユーザー名の不一致は、SSOログイントラブルでもっとも多い原因です。
- 本番適用前に、少人数のテストユーザーでログイン挙動を確認しましょう。
Authentication PolicyでSSOのみを許可する例も紹介します。
CREATE AUTHENTICATION POLICY sso_only_policy
AUTHENTICATION_METHODS = ('SAML')
SECURITY_INTEGRATIONS = ('MY_OKTA_SSO');
ALTER ACCOUNT SET AUTHENTICATION POLICY sso_only_policy;- いきなり全アカウントに適用すると、管理者を含む全員がログインできなくなるリスクがあります。
- まずはテストユーザーまたは一部ユーザーに適用し、挙動を確認してください。
- 管理者用には、後述のBreak-glassアカウント向けの例外ポリシーを必ず用意してください。
SSOユーザーにもMFAを要求する場合
基本的にSSOユーザーのMFAは、IdP側のポリシーで強制するのが王道です。一方で、規制要件や監査対応などで「Snowflake側でも明示的にMFAを要求したい」というケースもあります。その場合は、前述の ENFORCE_MFA_ON_EXTERNAL_AUTHENTICATION = 'ALL' を含むAuthentication Policyを使います。
ただし、IdP側とSnowflake側の二重MFAになるため、ユーザー体験への影響を事前に共有しておきましょう。
サービスユーザーはMFAではなくキーペア・OAuth・WIFを使う
人間が画面でログインするユーザーにはMFAが向いています。一方で、ETLツール、BIツール、Python、dbt、Airflow、Databricks、CI/CDなどで使うサービスユーザーには、MFAのような対話型認証は向いていません。サービスユーザーでは、パスワード認証ではなく、キーペア認証、OAuth、Programmatic Access Token、Workload Identity Federationなどを検討します。
| 認証方式 | 主な用途 | 特徴 |
|---|---|---|
| キーペア認証 | Python、SnowSQL、CLI、ETL | パスワードを使わず公開鍵・秘密鍵で認証 |
| OAuth | BIツール、外部アプリ連携 | IdPや認可サーバーと連携しやすい |
| Programmatic Access Token | 一部のプログラム接続 | 短期間・スコープ付きの認証に使える |
| Workload Identity Federation | CI/CD、クラウドワークロード | 長期シークレットを持たない認証に向く |
サービスユーザー一覧と認証状況は、次のSQLで確認できます。
SHOW USERS;
SELECT
"name",
"type",
"has_password",
"has_rsa_public_key",
"disabled"
FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
ORDER BY "type", "name";TYPE = SERVICEのユーザーにパスワード認証が残っていないか確認します。has_rsa_public_keyなどを見て、キーペア認証へ移行できているかを確認します。- 実際の列名は環境やSnowflakeの仕様変更で異なる可能性があるため、
SHOW USERSの結果列を確認してください。
キーペア認証への移行例(概要):
ALTER USER svc_etl_loader SET
RSA_PUBLIC_KEY = '<PUBLIC_KEY_WITHOUT_HEADER_AND_FOOTER>';- 秘密鍵はSnowflakeに登録しません。
- Snowflakeに登録するのは公開鍵だけです。
- 秘密鍵はアプリケーション側で安全に管理します(Secret Manager、KMSなど)。
- 鍵ローテーションのために
RSA_PUBLIC_KEY_2も活用できます。
キーペア認証の具体的な手順や鍵ローテーションの設計は、別記事「Snowflakeキーペア認証」で詳しく解説しているのでそちらもご覧ください。
管理者ロックアウトを防ぐBreak-glassアカウント
SSOやAuthentication Policyを強化していくと、IdP障害や設定ミスで管理者まで含めて誰もログインできなくなる「ロックアウト」のリスクが出てきます。これを防ぐのがBreak-glassアカウント(緊急時のみ使う管理者アカウント)の考え方です。
- IdP障害時に備えて、緊急用のBreak-glass管理者アカウントを用意します。
- Break-glassアカウントは少人数(2〜3名程度)に限定します。
- 強力なパスワード + MFAを必須にします。
- 通常業務では使わず、緊急時のみ使用します。
- 使用時はLOGIN_HISTORYやQUERY_HISTORYで監査します。
- ユーザー単位のAuthentication Policyで、全体ポリシーより緩い管理者用ポリシーを設定できます。
CREATE AUTHENTICATION POLICY admin_break_glass_policy
AUTHENTICATION_METHODS = ('SAML', 'PASSWORD')
CLIENT_TYPES = ('SNOWFLAKE_UI', 'SNOWFLAKE_CLI', 'SNOWSQL', 'DRIVERS');
ALTER USER break_glass_admin
SET AUTHENTICATION POLICY admin_break_glass_policy;SSOのみを許可する強力なポリシーをアカウントに適用しても、Break-glassアカウントだけは PASSWORD 認証を残しておくことで、いざというときの復旧経路を確保できます。
認証設定の確認SQL
設定後は、認証ポリシーやログイン履歴を定期的に確認します。
Authentication Policy一覧の確認:
SHOW AUTHENTICATION POLICIES;アカウントに紐づくポリシー参照の確認:
SELECT *
FROM TABLE(
INFORMATION_SCHEMA.POLICY_REFERENCES(
REF_ENTITY_DOMAIN => 'ACCOUNT',
REF_ENTITY_NAME => CURRENT_ACCOUNT()
)
);ユーザーのログイン履歴と認証方式の確認:
SELECT
EVENT_TIMESTAMP,
USER_NAME,
IS_SUCCESS,
ERROR_CODE,
ERROR_MESSAGE,
FIRST_AUTHENTICATION_FACTOR,
SECOND_AUTHENTICATION_FACTOR,
CLIENT_TYPE
FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
WHERE EVENT_TIMESTAMP >= DATEADD('day', -7, CURRENT_TIMESTAMP())
ORDER BY EVENT_TIMESTAMP DESC;失敗ログイン、想定外の認証方式、サービスユーザーからのパスワードログインなどを、このSQLで定期的に棚卸ししておくと、認証関連のインシデントを早期に検知できます。
よくあるトラブルと確認ポイント
| 症状 | 主な原因 | 確認ポイント |
|---|---|---|
| SSOボタンが表示されない | SP initiated login未設定 | SAML2_ENABLE_SP_INITIATED、Authentication Policy |
| SSO後にログインできない | NameIDとLOGIN_NAME不一致 | IdP側NameID、Snowflake側LOGIN_NAME |
| MFA登録画面に進めない | SNOWFLAKE_UIが許可されていない | Authentication PolicyのCLIENT_TYPES |
| BIツールが接続できない | パスワード認証廃止/MFA必須化の影響 | サービスユーザー、OAuth、キーペア |
| 管理者がログインできない | SSO設定ミス・IdP障害 | Break-glassアカウント |
| MFAデバイスを紛失した | MFAリセットが必要 | 管理者によるMFAリセット手順 |
| SnowSQLやPythonが接続できない | 認証方式未対応 | KEYPAIR/OAUTH/PATの利用可否 |
トラブルシューティングの第一歩は、SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY でエラーコード・エラーメッセージ・認証要素を確認することです。詳細はSnowflakeログインできない時の対処法も参考にしてください。
運用時のベストプラクティス
- 人間ユーザーはSSO + MFAを基本にする
- SSOのMFAは、原則としてIdP側で強制する
- 必要に応じてSnowflake側でもMFAを要求する(
ENFORCE_MFA_ON_EXTERNAL_AUTHENTICATION) - サービスユーザーはパスワードではなくキーペア / OAuth / WIFを使う
- サービスユーザーには最小権限ロールだけを付与する
- 管理者用のBreak-glassアカウントを必ず用意する
- いきなり全社適用せず、テストユーザーから段階的に適用する
LOGIN_HISTORYでログイン失敗や認証方式を定期的に確認する- Network Policy、RBAC、Session Policyと組み合わせて多層防御を構成する
実際の本番環境では、社内のセキュリティポリシーやIdP管理者と連携して設計・適用する必要があります。Snowflake側の設定だけで完結せず、IdP側のMFAポリシーやプロビジョニング(SCIM)も含めて全体設計するのがおすすめです。
ネットワーク制限やロール設計については、Snowflakeネットワークポリシー入門、Snowflake RBAC入門、Snowflakeカスタムロール設計もあわせてご覧ください。
まとめ
Snowflakeの認証設定は、MFAとSSOだけを個別に覚えるよりも、人間ユーザーとサービスユーザーを分けて考えると理解しやすくなります。人間ユーザーはSSO + MFA、サービスユーザーはキーペア認証・OAuth・WIFなどの非対話型認証を使うのが基本です。さらにAuthentication Policyを使えば、認証方式やMFA要件をアカウント単位・ユーザー単位で制御できます。まずはテストユーザーで検証し、管理者ロックアウト対策(Break-glassアカウント)を用意したうえで段階的に本番適用しましょう。
仕様や挙動の細部は時期によって変わるため、本記事を起点にしつつ、最新情報はSnowflake公式ドキュメントで必ず確認してください。
参考リンク
- Snowflake公式:Multi-factor authentication (MFA)
- Snowflake公式:Federated authentication & SSO
- Snowflake公式:Authentication policies
- Snowflake公式:Key-pair authentication and key-pair rotation
- Snowflake公式:OAuth overview
- Snowflake公式:Workload Identity Federation
※リンク先のパスはSnowflake公式の構成変更で変わる可能性があります。最新のURL構成は公式ドキュメントトップから検索してください。
