Snowflakeネットワークセキュリティ：Network Policy と AWS PrivateLink

Snowflake はデフォルトでインターネット越しの公開エンドポイントに到達できます。つまり認証情報さえ漏れれば、世界中のどこからでもログインを試行できてしまう。ここを本気で守るには「誰が入れるか（認証）」だけでなく「どこから、どの経路で入るか（ネットワーク）」まで設計する必要があります。本稿では Snowflake の Network Policy と AWS PrivateLink を軸に、公開エンドポイントを塞ぎながら SSO・内部ステージ・外部連携までプライベートに寄せる設計を、AWS の実装と紐づけて整理します。数値や機能の挙動は Snowflake / AWS の公式ドキュメントで確認したうえで記載しています。

01設計の起点は「公開エンドポイントを塞ぐ」こと

Snowflake アカウントは、初期状態では公開エンドポイント（*.snowflakecomputing.com）でインターネットに開いています。IAM の外に置かれた SaaS であるため、AWS のセキュリティグループや NACL だけでは接続元を絞れません。そこで多層防御の考え方に立ち、ネットワーク層で「接続元 IP やプライベートエンドポイントを許可制にする Network Policy」と「経路そのものを AWS 内部網へ閉じる AWS PrivateLink」を柱にし、認証層で SSO・MFA を重ねます。最終的なゴールは、公開経路を塞ぎ、自社の VPC からの正規経路以外では到達すらできない状態を作ることです。

02Network Policy の基本と適用階層

Network Policy は接続元を許可・拒否リストで制御する仕組みで、アカウント / ユーザー / セキュリティ統合の 3 レベルに適用できます。従来の ALLOWED_IP_LIST と BLOCKED_IP_LIST は IPv4 の CIDR を並べる方式で、同一 IP が両方にある場合はブロックリストが先に評価されます。適用の優先順位は「より具体的なものが勝つ」——セキュリティ統合がユーザーを、ユーザーがアカウントを上書きします。アカウントレベルのポリシーを有効化する際は、自分の現在の接続元 IP（または後述のプライベートエンドポイント識別子）を許可リストに含めていないとエラーになり、これがロックアウトの防止弁になっています。

03Network Rules への移行（INGRESS 制御）

新規に組むなら、Snowflake は生の IP リストではなく Network Rule の利用を推奨しています。Network Rule はスキーマレベルの名前付きオブジェクトで、ALLOWED_NETWORK_RULE_LIST / BLOCKED_NETWORK_RULE_LIST としてポリシーに束ねます。受信制御では MODE = INGRESS を指定し、TYPE に IPV4 のほか、AWS のエンドポイント ID を直接扱う AWSVPCEID を選べます。重要なのは、AWSVPCEID による指定が IPV4 よりも優先して評価される点です。名前付きで再利用でき、監査時に「どのルールで誰を許可しているか」が追いやすいため、IP の羅列を運用し続けるより保守性が高くなります。

04AWS PrivateLink でプライベート接続を敷く

AWS PrivateLink を使うと、お客様の VPC 内にインターフェース型 VPC エンドポイント（ENI とプライベート IP）を作り、そこから AWS のバックボーン網を経由して Snowflake へ到達できます。インターネットゲートウェイや NAT を通らず、トラフィックが公開インターネットに出ないのが本質です。手順の要点は、ACCOUNTADMIN ロールで SYSTEM$AUTHORIZE_PRIVATELINK に 12 桁の AWS アカウント ID とフェデレーショントークンを渡して認可し、SYSTEM$GET_PRIVATELINK_CONFIG から privatelink-vpce-id や privatelink-account-url を取得すること。AWS 側ではその VPCE ID を指す VPC エンドポイントを作成し、セキュリティグループでポート 443 と 80 の通信を許可します。最後に Route 53 のプライベートホストゾーンで、<account_identifier>.privatelink.snowflakecomputing.com を VPC エンドポイントの DNS 名へ CNAME 解決させます。なお、この機能は Business Critical エディション以上が前提です。

05公開エンドポイントを塞ぐ「合わせ技」

ここで多くの現場が誤解しがちなのが、「PrivateLink を敷けば公開経路は閉じる」という思い込みです。実際には、PrivateLink を有効化してもアカウントの公開エンドポイントは開いたまま残ります。つまり認証情報が漏れれば、依然として公開経路から普通にログインできてしまう。仕上げは Network Policy です。Network Rule で TYPE = IPV4 の 0.0.0.0/0 をブロックリストに、TYPE = AWSVPCEID の自社エンドポイント ID を許可リストに置くことで、「自社 VPC エンドポイント経由のトラフィックだけを通し、それ以外の公開 IP はすべて拒否する」状態になります。PrivateLink（経路の限定）と Network Policy（接続元の限定）は役割が違い、両方そろって初めて公開エンドポイントが実質的に塞がる、という理解が肝心です。

06SSO / フェデレーションで認証層を重ねる

ネットワークを絞っても、認証が弱ければ守りは片肺です。Snowflake は CREATE SECURITY INTEGRATION（SAML2）で IdP と連携し、フェデレーション認証・SSO を実現します。Okta や Microsoft Entra ID（旧 Azure AD）はネイティブ対応があり、ユーザーごとに異なる IdP を割り当てることも可能です。さらに認証ポリシー（Authentication Policy）を使えば、ユーザー単位で許可する認証方式やクライアント種別を制御でき、パスワード認証を廃してキーペア認証や MFA を強制する、といった締め方ができます。ネットワーク層（どこから）と認証層（誰が・どう）は独立した防御線であり、両方を通らなければ入れない設計にするのが要点です。

07内部ステージと外部連携もプライベートへ寄せる

クライアント接続を PrivateLink 化しても、データの入出力経路が公開網を通っていては片手落ちです。Snowflake の内部ステージ（データのロード / アンロード）は背後で S3 を使うため、AWS PrivateLink for S3 と VPC インターフェースエンドポイントを組み合わせ、SYSTEM$GET_PRIVATELINK_CONFIG が返す privatelink-internal-stage の経路でプライベートに寄せられます。ここで注意したいのは、S3 のインターフェースエンドポイントはクロスリージョンに対応しないため、VPC エンドポイントは Snowflake アカウントと同一リージョンに置く必要がある点です。逆向きの通信、たとえば Cortex や UDF から Amazon Bedrock を呼び出すようなアウトバウンドも、External Access Integration に MODE = EGRESS かつ TYPE = PRIVATE_HOST_PORT の Network Rule を紐づければプライベート接続にできます（こちらも Business Critical 以上）。インバウンド・内部ステージ・アウトバウンドの全方位を AWS 内部網へ寄せて、初めて経路の穴がなくなります。

08検証で先に踏み抜いた落とし穴と導入順序

この種の締め込みは、順序を誤ると自分たちが締め出されます。私たちは検証環境で、アカウントレベルの Network Policy を許可リスト不備のまま有効化して即ロックアウトに至る挙動を先に再現し、本番ではまずユーザーレベルで先行検証したうえで、緊急復旧用の許可経路を確保してから段階適用する手順に落としました。DNS も落とし穴でした。検証時に Route 53 の CNAME 設定が抜けていると、名前が従来の公開 URL に解決され「公開経路を塞いだつもりで実は残っている」状態になり得ると分かったため、本番では解決先が PrivateLink URL であることを確認してから公開遮断に踏み切っています。内部ステージについても、S3 エンドポイント未整備でロードが公開経路を通っていた状態を検証で捕まえ、本番では内部ステージまで PrivateLink 化しました。推奨する導入順序は、(1) PrivateLink 敷設と疎通確認、(2) SSO・認証強化、(3) 内部ステージと外部連携のプライベート化、(4) 最後に公開エンドポイントの遮断です。事故は検証で先に踏み抜き、本番では未然に防ぐ——この積み重ねで、EMW は重大障害ゼロを継続しています。