第2章アカウント管理とデータガバナンス / 想定学習時間:30〜40分 / 最終確認:2026年8月

2-3. 認証とネットワークセキュリティ

🎯 この節の学習目標

MFAの仕組みと推奨事項(誰が登録するか・誰に強く推奨されるか)を説明できる
フェデレーテッド認証/SSO・OAuth・キーペア認証・SCIMの役割とユースケースを使い分けられる
ネットワークポリシー(IPの許可/ブロック)とプライベート接続の概要・必要エディションを説明できる

1. パスワード認証とMFA(多要素認証)

最も基本的な認証はユーザー名+パスワードですが、パスワードだけに頼るのは危険です。Snowflake はMFA(Multi-Factor Authentication:多要素認証)をすべてのエディションで追加費用なしに提供しています。

MFA の方式として、パスキー(推奨)、TOTP対応の認証アプリ、Duo がサポートされています。別途外部サービスのアカウントや契約を用意する必要はありません
MFA への登録(enroll)はユーザー自身がSnowsightのプロフィールから行うのが基本です(管理者が一括で登録する仕組みではありません)
とくにACCOUNTADMINロールを持つすべてのユーザーにはMFAの利用が強く推奨されます
管理者は認証ポリシー(authentication policy)をアカウントやユーザーに適用し、許可する認証方式やMFAの要求を統制できます。また、ユーザーが端末を紛失した場合などには、管理者が一時的にMFAをバイパス(無効化)する設定も可能です
さらに Snowflake は、すべてのユーザーに強力な認証を求める方針(単要素のパスワード認証の廃止)を段階的に展開中です(2026年時点)。人が使うアカウントにはMFAやSSOを、プログラム用のアカウントにはキーペア認証やOAuthを使うことが前提になりつつあります

📝 試験のポイント

MFAは「全エディションで利用可能」「パスキー(推奨)・TOTP認証アプリ・Duoの3方式で追加契約不要」「ユーザー自身が登録」「ACCOUNTADMINには強く推奨」の4点セットで覚えましょう。「Enterprise以上でのみ利用可能」「管理者だけが登録できる」といった選択肢は誤りです。単要素パスワードの段階的な廃止という近年の動向も押さえておくと安心です。

2. フェデレーテッド認証/SSO・OAuth・キーペア・SCIM

パスワード+MFA以外にも、Snowflake は用途に応じた複数の認証・連携方式をサポートしています。

方式	仕組み	主なユースケース
フェデレーテッド認証/SSO	SAML 2.0準拠の外部IdP(Identity Provider)が認証を担い、Snowflakeはその結果を信頼してシングルサインオンを実現する	社内の統合ID基盤で人のログインを一元化したい場合
OAuth	OAuth 2.0 により、パスワードを共有せずにアクセストークンで接続を委任する。Snowflake OAuth(Snowflake自身が認可サーバー)とExternal OAuth(外部の認可サーバー)の2種類がある	BIツールやアプリケーションからの接続。パスワードを保存させたくない場合
キーペア認証	RSA公開鍵/秘密鍵ペアを使う。公開鍵をSnowflakeのユーザーに登録し、クライアントは秘密鍵で署名したJWTで認証する。鍵のローテーションのためユーザーごとに2つまで公開鍵を登録可能	プログラム・バッチ・サービスアカウントからの自動接続(対話的なMFAが使えない場面)
SCIM	認証方式ではなくプロビジョニングの標準規格。IdP上のユーザー・グループの作成・変更・無効化をSnowflakeのユーザー・ロールへ自動同期する	入退社にあわせたアカウント管理の自動化

💡 具体例:キーペア認証の設定

-- 生成したRSA公開鍵をユーザーに登録する(ヘッダー・フッター行は除いて指定)
ALTER USER batch_loader SET RSA_PUBLIC_KEY = 'MIIBIjANBgkqh...';

-- ローテーション用に2つ目の公開鍵も登録できる
ALTER USER batch_loader SET RSA_PUBLIC_KEY_2 = 'MIIBIjANBgkqh...';

-- 登録状況を確認する
DESCRIBE USER batch_loader;

秘密鍵はクライアント側で厳重に保管し、Snowflakeには公開鍵のみを登録します。2つのキーを登録できるため、新しい鍵に切り替えてから古い鍵を削除する無停止のローテーションが可能です。

📝 試験のポイント

「プログラムやサービスからの自動接続に適した認証方式は?」と問われたら、答えはキーペア認証またはOAuthです。対話的な操作(MFAのプッシュ承認やIdPのログイン画面)を伴う方式はバッチ処理に不向きです。逆に「人のログインを社内IdPで一元化」ならSAML 2.0によるフェデレーテッド認証/SSO、「ユーザーやグループの自動プロビジョニング」ならSCIM、と目的で切り分けます。

3. ネットワークポリシー:接続元IPの制御

認証(誰であるか)とは別の軸で、どこから接続してよいかを制御するのがネットワークポリシー(network policy)です。

-- 社内ネットワークからのみ許可し、特定IPをブロックするポリシー
CREATE NETWORK POLICY corp_only
  ALLOWED_IP_LIST = ('192.0.2.0/24', '198.51.100.0/24')
  BLOCKED_IP_LIST = ('192.0.2.99');

-- アカウント全体に適用する(SECURITYADMIN以上などが実行)
ALTER ACCOUNT SET NETWORK_POLICY = corp_only;

-- 特定ユーザーだけに別ポリシーを適用することもできる
ALTER USER batch_loader SET NETWORK_POLICY = corp_only;

ALLOWED_IP_LIST:接続を許可するIPアドレス/CIDR範囲のリスト。指定するとリスト外からの接続はすべて拒否されます
BLOCKED_IP_LIST:許可範囲の中からさらに除外(ブロック)したいIPを指定します。ブロックが許可より優先されます
適用レベルはアカウントレベルとユーザーレベルがあり、両方が設定されている場合はユーザーレベルのポリシーが優先されます
アカウントレベルのポリシーを設定する際、自分自身のIPが許可リストに含まれていないと締め出されるため、Snowflakeは現在の接続元を含めることを検証します

4. プライベート接続(Business Critical)

ネットワークポリシーはパブリックインターネット経由の接続をIPで絞る仕組みですが、より強い要件として「そもそもパブリックインターネットを経由させたくない」場合があります。これに応えるのがプライベート接続です。

AWS PrivateLink、Azure Private Link、Google Cloud Private Service Connect などのクラウド事業者のプライベート接続サービスを利用し、顧客のVPC/VNetとSnowflakeを閉域で接続します
プライベート接続はBusiness Criticalエディション以上の機能です
金融・医療など、規制要件でインターネット経由の通信を避けたい組織が主な利用者です

「IPで絞る=ネットワークポリシー(Standardから可)」「閉域接続=PrivateLink等(Business Critical)」という対比で押さえてください。

5. 接続からSnowflake到達までの流れ

この節で学んだ要素を、接続の流れとして1枚にまとめます。

接続元人(ブラウザ/Snowsight) / BIツール / バッチプログラム

↓経路の選択:パブリックインターネット or プライベート接続(Business Critical)

認証方式の分岐人:パスワード+MFA / SSO(SAML 2.0)
アプリ・バッチ:OAuth / キーペア認証

↓認証ポリシーで許可される方式・MFA要求を統制

ネットワークポリシーの評価ユーザーレベル → なければアカウントレベル。BLOCKEDがALLOWEDに優先

↓許可されたIPのみ通過

Snowflakeセッション確立ロールコンテキスト(2-1)にもとづいてアクセス制御

図:接続経路の全体像。「経路」「認証」「ネットワークポリシー」の3つの関門を経てセッションが確立する

✅ この節のまとめ

MFAは全エディションで利用可能。方式はパスキー(推奨)・TOTP認証アプリ・Duoで追加契約不要、ユーザー自身が登録し、ACCOUNTADMINには強く推奨。認証ポリシーで方式やMFA要求を統制できる。単要素パスワード認証は段階的に廃止されつつある。
フェデレーテッド認証/SSOはSAML 2.0準拠の外部IdPで人のログインを一元化。OAuthはトークンによる委任(Snowflake OAuth / External OAuth)。キーペア認証はRSA鍵によるプログラム向け認証(公開鍵2つで無停止ローテーション)。SCIMはユーザー・グループの自動プロビジョニング。
プログラムからの接続にはキーペア認証またはOAuthが適する。
ネットワークポリシーはALLOWED_IP_LIST / BLOCKED_IP_LISTで接続元を制御。ブロックが許可に優先し、ユーザーレベルがアカウントレベルに優先する。
プライベート接続(AWS PrivateLink等)はパブリックインターネットを経由しない閉域接続で、Business Critical以上が必要。

練習問題

問1. SnowflakeのMFAに関する説明として正しいものはどれか。

MFAはEnterpriseエディション以上でのみ利用できる
MFAを使うには組織が別途Duo Securityと契約する必要がある
MFAはすべてのエディションで利用でき、ユーザー自身が登録する。ACCOUNTADMINを持つユーザーには利用が強く推奨される
MFAはACCOUNTADMINが全ユーザーに代わって一括登録するのが標準的な手順である

解答と解説を見る

正解:C

MFAは全エディション共通の標準機能で、パスキー(推奨)・TOTP認証アプリ・Duoの各方式をサポートし、追加契約は不要です。登録はユーザー自身が行い、とくにACCOUNTADMIN保持者には強く推奨されます。Aはエディション制限の誤り、Bは追加契約が不要である点の誤り、Dは登録主体の誤りです(管理者はポリシーによる強制やバイパス設定はできますが、本人に代わっての登録が標準手順ではありません)。

問2. 夜間バッチプログラムからSnowflakeへ自動接続する認証方式として適切なものを2つ選べ。

キーペア認証(RSA公開鍵/秘密鍵)
OAuth
パスワード+MFA(プッシュ通知承認)
SCIM

解答と解説を見る

正解:A、B

プログラムからの自動接続には、対話操作なしで完結するキーペア認証(A)やOAuthのトークン(B)が適しています。CのMFAプッシュ承認は人がスマートフォンで承認する対話的な仕組みであり、無人のバッチには不向きです。DのSCIMは認証方式ではなく、IdPからユーザー・グループを自動プロビジョニングする規格なので、接続の認証には使えません。

問3. ネットワークポリシーに関する説明として正しいものはどれか。

ALLOWED_IP_LISTとBLOCKED_IP_LISTの両方に該当するIPからの接続は許可される
ネットワークポリシーはアカウントレベルとユーザーレベルに適用でき、両方ある場合はユーザーレベルが優先される
ネットワークポリシーはBusiness Criticalエディション以上でのみ利用できる
ネットワークポリシーは接続元のIPではなく、使用する認証方式を制限する機能である

解答と解説を見る

正解:B

ネットワークポリシーはアカウント/ユーザーの両レベルに適用でき、ユーザーレベルの設定が優先されます。Aは誤りで、ブロックリストは許可リストより優先されるため接続は拒否されます。Cは誤りで、ネットワークポリシー自体は特定の上位エディション限定機能ではありません(Business Criticalが必要なのはPrivateLink等のプライベート接続です)。Dは誤りで、認証方式を統制するのは認証ポリシーであり、ネットワークポリシーは接続元IPの制御です。

問4. 「社員のSnowflakeログインを社内のIdPに一元化し、入退社にあわせてSnowflakeのユーザー作成・無効化も自動化したい」。この要件に対応する機能の組み合わせとして最も適切なものはどれか。

ログインの一元化=SAML 2.0によるフェデレーテッド認証/SSO、自動プロビジョニング=SCIM
ログインの一元化=キーペア認証、自動プロビジョニング=OAuth
ログインの一元化=ネットワークポリシー、自動プロビジョニング=認証ポリシー
ログインの一元化=SCIM、自動プロビジョニング=SAML 2.0

解答と解説を見る

正解:A

人のログインを外部IdPに委ねるのがSAML 2.0ベースのフェデレーテッド認証/SSO、IdP上のユーザー・グループの変更をSnowflakeへ自動同期するのがSCIMです。Bのキーペア認証はプログラム向けで人のSSOには不適切、OAuthはプロビジョニング機能ではありません。Cはどちらも別目的の機能(IP制御と認証方式の統制)です。DはSSOとSCIMの役割が逆になっています。