執筆者: Ido Shlomo（Token Security 共同創業者兼CTO）
Connor Moucka容疑者はSnowflakeの脆弱性を突いたわけではありませんでした。同容疑者と共犯者たちは、何年も前から使われていた有効な顧客の認証情報を使ってログインし、165を超えるSnowflake顧客組織に侵入しました。
彼らは数十億件のレコードを盗み出し、その中にはAT&Tのほぼ全ワイヤレス顧客の通話・テキスト記録も含まれていました。Moucka容疑者は8月5日、コンピュータ詐欺、電信詐欺、加重身元窃盗、共謀の罪について有罪を認めました。
今回の攻撃キャンペーンは、見慣れたIDに関する失敗を露呈させました。漏洩後も長期間有効なままの認証情報、多要素認証が設定されていなかった対象アカウント、そしてしばしば存在しないネットワーク制限です。
Snowflakeは今、非人間アイデンティティに焦点を当てることで、顧客にこの「アイデンティティ負債」への対応を迫っています。
認証移行のフェーズ3において、SnowflakeはレガシーなサービスユーザーをSERVICEタイプへ移行させ、パスワードベースの認証をブロックします。パスワードを置き換えること自体は機械的な作業に過ぎません。
本当に難しいのは、各アカウントが何に使われているかを特定し、責任者を割り当て、そのアカウントに今もどれだけのアクセス権限が必要かを判断することです。
今もパスワードが残っているアカウントたち
間もなく、すべてのサービスアカウントはパスワードでの認証をブロックされます。LEGACY_SERVICEユーザータイプは完全に廃止され、既存のレガシーアカウントはパスワードを保存できないSERVICEタイプへ移行されます。
Snowflakeはこの廃止措置を3段階に分けて進めており、最初の2段階ですでに大半の抜け道は塞がれています。
- 2025年9月～2026年1月: 人間のユーザーはSnowsightで第二要素の提示が必須になりました。サービスユーザーは対象外でした。
- 2026年5月～2026年7月: 新規に作成される非人間ユーザーはすべてSERVICEタイプでなければならず、パスワードを使用できなくなりました。
- 2026年8月～2026年10月: 対象となるSnowflakeアカウント内のレガシーサービスアカウントは、それぞれのアカウント別フェーズ3適用日までにパスワード認証から移行しなければなりません。
残っているアカウントほど古参です。それだけ認証情報が漏洩し、ローテーションされないまま放置される期間が長く、担当者が異動して所有者が分からなくなり、依存関係の記録も失われている可能性が高くなります。
混沌としたエージェントに一日を台無しにさせない
エージェントを最初から安全に保つ鍵は、アイデンティティにあります。
Token Securityはあらゆるエージェントを検出し、リスクの高いアクセスをマッピングし、意図ベースのポリシーを自動的に適用します。アイデンティティを起点に、コントロールやイノベーションのスピードを損なうことなく、AIを安全にスケールさせましょう。
ステップ1: 10月ではなく、今すぐ棚卸しを行う
プラットフォーム上のすべてのサービスアカウントについて、次の3つの問いに答える必要があります。
- どのアカウントがSnowflakeに対して認証を行っているか
- それぞれの所有者は誰か
- パスワードが使えなくなったとき、何が壊れるか
1つ目の問いにはSnowflake自身が答えてくれます。ACCOUNT_USAGEスキーマには各アカウントのタイプ別ユーザー一覧が保存されており、ログイン履歴には過去365日分、各認証試行のクライアントと送信元IPが記録されています。
この2つを組み合わせれば、今もパスワードでサインインしているアカウントの集合と、それぞれが最後にいつ、どこからログインしたかが分かります。
2つ目と3つ目の問いはより厄介です。誰がそのサービスアカウントの作成を依頼したのか、どのシステムがそれに依存しているのか、動かなくなったとき誰に連絡すべきなのか――こうした情報をSnowflakeは教えてくれません。それは設定した本人の記憶の中か、2022年に起票されたチケットの中か、あるいは(往々にして)どこにも残っていません。
期限に追い立てられて10月にまとめて作った棚卸しは、ガバナンスとは呼べません。それはある一瞬を切り取ったスナップショットにすぎず、次に誰かがアカウントをプロビジョニングした瞬間から陳腐化が始まります。
ステップ2: 各アカウントに担当者を紐づける
次のサービスアカウントを何年も放置させないために欠かせないのが、所有者の記録です。ただし、所有権は単にスプレッドシートの一行に名前を書くだけで済むものではありません。
そのアカウントの認証が午前2時に失敗したとき、アラートを受け取って対応するのは誰でしょうか。答えが「誰もいない」であれば、そのアカウントには所有者がいないということです。そうなると問題は「どう移行するか」ではなく、「そもそもそのアカウントは存在すべきか」に変わります。
所有権とは、稼働を維持する責任と同じくらい、廃止する責任も含みます。
所有者が明確でない場合は、削除する前に管理された無効化期間を設けましょう。
失敗がないか監視し、必要であればアカウントを復旧させ、依存関係を検証したうえで初めて廃止してください。
ステップ3: 全体で一つの方式に統一せず、アカウントごとに方式を選ぶ
SnowflakeはSERVICEユーザー向けに、パスワードを使わない4つの認証方式を用意しており、それぞれ運用コストが異なります。
|
方式 |
コスト |
|
ワークロードアイデンティティフェデレーション |
Snowflakeが推奨する選択肢です。シークレットレスなので、保存やローテーションが必要なものは何もありません。ただし、ワークロードがフェデレーション可能なアイデンティティを提示できる環境で稼働している必要があります。 |
|
外部OAuth |
強固な方式ですが、サードパーティのIdPを認可サーバーとして構成できる専門知識が必要です。 |
|
キーペア認証 |
リクエスト時にはパスワード不要ですが、実態としては依然として長期間有効なシークレットであり、4方式の中で唯一ガードレールが付随していません。Snowflakeはネットワークポリシーとローテーション戦略の導入を推奨していますが、どちらも必須ではなく、トークンのような強制的な有効期限もありません。 |
|
プログラマティックアクセストークン |
パスワードの最も直接的な代替手段です。SERVICEユーザーの場合、Snowflakeはデフォルトでネットワークポリシーとロール制限を要求しますが、認証ポリシーによってどちらも緩和できます。ローテーション時にこれらの前提条件が再チェックされるわけではないため、各ローテーションのたびにネットワークポリシー、ロール付与、有効期限、所有者を検証する必要があります。 |
一つの方式だけに絞ろうとしないでください。
ワークロードがSnowflakeにアイデンティティを提示できるプラットフォーム上で稼働している場合は、フェデレーションを標準の選択肢とすべきです。
それが使えない場合の代替手段がキーペア、あるいはロールを絞り込んだトークンであり、その際はネットワークポリシーとローテーションのスケジュールを、後回しの作業としてではなく同じ変更の中で確定させてください。
どちらも伴わずに移行された長期有効なシークレットは、何の指摘もなくフェーズ3の期限を通過してしまうかもしれませんが、それは形を変えただけの同じ制御不備にすぎません。
ステップ4: 置き換えたパスワードは「漏洩済み」として扱う
これから置き換えようとしている認証情報は、すでにインフォスティーラーのログに載っていると想定してください。
MandiantとSnowflakeの調査によれば、UNC5537キャンペーンで使われたアカウントのうち、少なくとも79.7%が過去に認証情報の漏洩歴を持っていました。
そうした認証情報の一つに紐づく最も古いインフォスティーラー感染は2020年11月にまで遡り、そのパスワードは盗まれてからおよそ3年半経っても有効なままだったことになります。
切り替えを行えばSnowflake上のパスワードは無効化されますが、シークレットストア、CI変数、運用手順書、エンドポイントなどにコピーされたり使い回されたりした認証情報までは削除されません。
使い回しがないか検索し、依存している認証情報があれば失効させ、同じ変更作業の中でそのアカウントのロールの範囲も縮小してください。
AIエージェントが同じアイデンティティ管理の課題を圧縮する
Snowflakeの今回の期限は、AIエージェントがさらに大きく膨らませることになるガバナンス課題の予告編にすぎません。Snowflakeはすでに、自律的に動くAIエージェントをSERVICE_AGENTという独立したアイデンティティタイプとして認識しています。
ラベルは新しくても、問うべき制御上の問いは変わりません。そのエージェントの所有者は誰か。どのアイデンティティを使っているのか。何にアクセスできるのか。そのアクセスはいつ終了させるべきか。
次のプラットフォームの期限が問題を突きつけてくる前に、Token Securityが所有者不在のアイデンティティを特定し、隠れた依存関係をマッピングし、ライフサイクル管理を確立する方法を知るには、技術デモを予約してください。
