Snowflake は、検証可能な修復を共有クラウド責任の試金石とした

概要

• Mandiant は、直接対応したすべての Snowflake キャンペーンインシデントが侵害された顧客認証情報に起因しており、不正アクセスが Snowflake の企業環境への侵害に由来する証拠は見つからなかったと報告している。同社のキャンペーンレポートはhttps://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortionを参照。
• 本キャンペーンはプロバイダ責任をも試した。Snowflake が認証面、製品デフォルト、セキュリティガイダンス、アカウントテレメトリ、ネットワークポリシーツール、Trust Center チェック、および単一の顧客では構築できないキャンペーン後の変更を管理していたからである。
• 検証可能な修復とは、測定可能な変化を意味する。新規アカウントにおけるヒューマンユーザーへのデフォルト MFA 適用、より強力なパスワードルール、漏洩パスワードの自動無効化、顧客向け証拠パッケージ、ネットワーク起点制御、そして導入ベース全体でのリスク低減を示す採用指標である。
• 顧客の説明責任は依然として大きい。顧客はユーザー作成、ロール付与、パスワードローテーション、既存アカウントの MFA 登録、コントラクターアクセス、ネットワーク許可リスト、データ最小化、エクスポート権限、調査準備を管理していた。

プラットフォーム侵害は示されず、許容的なベースラインが明らかになった

第一の規律は、キャンペーンの境界を正確に保つことである。Mandiant の2024年6月の報告書は、同社が対応したインシデントにおける不正アクセスは侵害された顧客認証情報に起因し、Snowflake の企業環境への侵害の証拠は見つからなかったと述べている。Snowflake の顧客ガイダンスは、CISA によってhttps://www.cisa.gov/news-events/alerts/2024/06/03/snowflake-recommends-customers-take-steps-prevent-unauthorized-accessで増幅され、同様に顧客に対して不正なユーザーアクセスの調査と、ID およびネットワーク制御の強化を指示した。検討された記録では、Snowflake のプラットフォームエクスプロイト、クロステナントエスケープ、またはプロバイダのマスター認証情報の窃取は確認されていない。

この否定的な調査結果は重要である。なぜなら、それが即時対応を形作るからだ。顧客は、有効だが MFA がなく、ネットワーク許可リストもなく、広範なロール権限を持つ認証情報が問題である場合、プロバイダのパッチを待つべきではない。顧客は認証情報のローテーション、アカウントの無効化、ログイン履歴とクエリ履歴の調査、起点ネットワークの制限、ロールの見直し、ログの保存、そして必要に応じて影響を受ける個人や規制当局への通知を行う必要がある。

逆の誤りは、最初のシークレットが顧客に属していたからといって、プロバイダに説明責任はないと言うことだ。Snowflake はそれらのパスワードを受け付ける認証エンドポイントを運用し、MFA 機能を提供し、デフォルト動作をいつ変更するかを選択した。テレメトリフィールドを公開または非公開にし、ネットワークポリシー制御と Trust Center の調査結果を提供した。単一のテナントでは見えないクロスカスタマーシグナルを見ることができ、後に漏洩パスワード保護をサービスに組み込むこともできた。顧客がアカウントを所有していても、これらは真の制御である。

Snowflake の2025会計年度の年次報告書（https://www.sec.gov/Archives/edgar/data/1640147/000164014725000052/snow-20250131.htm）は、同社の共有責任の立場を述べ、2024年の活動に伴う法的、規制上、および風評上の影響を説明している。提出書類は会社の表明であり、裁定ではない。それでもなお、Snowflake 自身が、本キャンペーンがいずれか一つの顧客テナントを超えてビジネスリスクに影響を与えたことを開示しているため、関連性がある。共有責任は公開企業の問題となった。

したがって、本稿の視点は「Snowflake が侵害された」でも「顧客だけが失敗した」でもない。検証可能な修復である。キャンペーンが、パスワードのみのアクセス、古い情報窃取型マルウェアによる認証情報、欠如したネットワーク制限という予見可能なパターンを悪用した後、プロバイダと顧客は、次の同様のキャンペーンでは有効な認証情報が減り、パスワードのみのセッションが減り、無制限の起点が減り、より良いアラートと迅速な証拠提供がなされるという証拠を必要とする。

キャンペーンの経路は、敵対的な ID 下で通常機能を利用した

Mandiant は実践的な連鎖を説明した。認証情報は、一部では個人利用にも使われたコントラクターマシンを含む、Snowflake が所有していないシステムから情報窃取型マルウェアによって窃取されていた。それらの認証情報は、場合によっては何年も有効なままだった。アカウントには MFA がなかった。顧客インスタンスにはネットワーク許可リストがなかった。攻撃者は標準的なクライアントとツールで接続し、偵察を行い、データを選別し、結果をステージングし、ファイルを圧縮して持ち出した。このパターンは、不正な ID の下でサポートされているデータベース機能を利用したものだ。

この区別は修復の中心である。保存時の暗号化は決定的な障壁ではなかった。Snowflake のエンドツーエンド暗号化ドキュメント（https://docs.snowflake.com/en/user-guide/security-encryption-end-to-end）は、保存時および転送時の暗号化を説明しているが、データはテーブル操作中に使用されなければならず、許可されたユーザーによってアンロードおよびダウンロードされうることも説明している。アカウントの認証を満たし、ロールを継承する攻撃者は、読み取り可能な結果をサービスに要求できる。暗号化は、ID 保証、ロール設計、エクスポート制御、検出の代替にはならない。

アクセス制御はログイン後の影響範囲を決定した。Snowflake のアクセス制御概要（https://docs.snowflake.com/en/user-guide/security-access-control-overview）は、ロール、権限、所有権、階層を説明している。狭いアクセスが割り当てられた窃取された認証情報は、広範な読み取り権限やアカウント管理権限が割り当てられたものとは異なる。パイプライン用に構築されたサービスアカウントは、コントラクター管理者とは異なる。最小権限はスローガンではない。それは、敵対的なセッションが一つのビューを返すか、主要な顧客テーブルを歩き回るかの違いである。

データ分類とマスキングは影響を軽減できる。Snowflake の機密データ分類ドキュメント（https://docs.snowflake.com/en/user-guide/classify-intro）は、機密カラムの発見とマスキングおよび行アクセスポリシーを結びつけている。これにより、影響を受けた顧客がそのような制御を備えていたことが証明されるわけではない。修復パスを示している：顧客は個人情報や規制対象フィールドを特定し、可能な限り生テーブルではなくビューを公開し、エクスポートロールを通常の読み取りロールから分離すべきである。

観測されたデータ持ち出し経路は、エクスポートそれ自体を制御ポイントとする。データプラットフォームにおいてバルクアンロードは正当である。それらは分析、バックアップ、下流処理、モデルワークフローを支える。しかし、一時的なステージを作成し、大規模な結果をエクスポートし、未知の起点からダウンロードする異常なセッションは、単なる「クエリ」ではない。それはデータ移動イベントである。修復では、こうしたイベントを測定可能で、帰属可能にし、高リスクデータセットの場合は中断可能にすべきである。

MFA の利用可能性が MFA の成果となった

MFA はキャンペーン以前から利用可能だった。Mandiant のレポートで成功したアカウントにはそれが欠けていた。このギャップが共有責任をめぐる論争の核心である。顧客管理者は MFA を有効にできたが、多くはそうしなかった。プロバイダは、その制御が利用可能だったと正直に言える。しかし、パスワードだけで依然としてアクセス可能な多くの高価値アカウントを目の当たりにしながら、セキュリティ成果を達成したとは言えず、単に設定を利用可能にしたに過ぎない。

Snowflake の2024年9月の発表（https://www.snowflake.com/en/blog/multi-factor-identification-default/）は製品姿勢を変えた。2024年10月以降に作成されるアカウントでは、ヒューマンユーザーに対して MFA がデフォルトで強制され、サービスユーザーはその特定要件の対象外とされた。また、新規作成および変更されるユーザーパスワードに対して、より強力なパスワード要件が発表された。これは、将来のアカウントに対するデフォルトパスを変えるため、意味のある修復である。

新規アカウントと既存アカウントの区別も同様に重要である。将来のアカウントに対するデフォルトが、導入ベースにあるすべてのパスワードのみの経路を自動的に除去するわけではない。既存顧客には、レガシーユーザー、サービスアカウント、コントラクター、緊急用アカウント、古いクライアントが存在する可能性がある。したがって、検証可能な修復記録は、レガシーリスクを直接測定すべきである：MFA のないヒューマンユーザーの数と割合、MFA のない特権ヒューマンユーザー、最終ログイン日が古いパスワードユーザー、既知の露出認証情報を持つユーザー、より強力なワークロード認証ではなくパスワードを使用するサービスアカウント、およびビジネス所有者と有効期限付きの例外など。

Snowflake の認証ポリシードキュメント（https://docs.snowflake.com/en/user-guide/authentication-policies）は、管理者に認証方法、クライアント、ID プロバイダ、MFA 登録に対する制御を提供する。キーペア認証ドキュメント（https://docs.snowflake.com/en/user-guide/key-pair-auth）は、サービスアカウントに静的パスワードの代替手段を提供する。これらの制御は顧客に義務を課すが、プロバイダの修復面を定義するものでもある。製品は、良いパターンを容易にし、悪い例外を見えるようにし、移行のリスクを低減すべきである。

NIST のデジタル ID ガイダンス（https://pages.nist.gov/800-63-4/sp800-63b.html）は、成果を明示する助けとなる。パスワードはリプレイ耐性がない。フィッシング耐性または暗号的に結合された方法は、盗まれたパスワードの価値を下げる。Snowflake の顧客にとって、それはヒューマン管理者がフェデレーテッド ID または強力な MFA を介して接続し、サービスユーザーはローテーション可能で、個人を偽装することなく無効化できるスコープ付きワークロード認証情報を使用すべきことを意味する。

漏洩パスワードブロッキングが共有責任を測定可能にした

認証情報窃取キャンペーン後の最も直接的なプロバイダの修復は、パスワード再利用に関する説教ではない。既知の盗まれたパスワードを機能させなくすることだ。Snowflake の2024年12月の発表（https://www.snowflake.com/en/blog/leaked-password-protection/）は、ダークウェブで検出されたパスワードを、漏洩が確認され有効である場合に、プライバシー保護プロセスを通じて自動的に無効化すると述べた。この制御はキャンペーンの中心的な利点に対処する：2024年よりずっと前に盗まれた認証情報がサービスに受け入れられ続けていたことだ。

漏洩パスワード保護は顧客の義務を取り除くものではない。顧客は依然としてエンドポイントセキュリティ、コントラクターガバナンス、パスワードローテーション、フェデレーション、サービスユーザー設計、最小権限を必要とする。しかし、それは分業を変える。個々の顧客は多くの場合、クラウドプロバイダほどにはグローバルな情報窃取マルウェア市場を見渡せない。プロバイダは脅威インテリジェンスを購入または受信し、制御された方法で露出した認証情報を照合し、各顧客が独自に発見する前にパスワードを無効化できる。これこそ、共有責任を条項からシステム動作に変えるプロバイダレベルの制御である。

証拠の問題は導入状況とパフォーマンスである。有効な漏洩パスワードはいくつ見つかったか？どれだけ迅速に無効化されたか？特権ユーザーに属していたものはいくつか？パスワードからキーペアまたはフェデレーテッドアクセスに移行したアカウントはいくつか？無効化されたパスワードイベントがサポートの摩擦や安全でない回避策を引き起こしたか？依然として例外を抱える顧客はいくつか？指標がなければ、漏洩パスワード保護は良いアナウンスに過ぎない。指標があれば、それは検証可能な修復となる。

CISA の Secure by Design 誓約（https://www.cisa.gov/sites/default/files/2024-05/CISA%20Secure%20by%20Design%20Pledge_508c.pdf）は、この区別を枠付けている。製造業者に対し、オプションの制御を超えて、デフォルト MFA や採用指標といった測定可能な成果へと移行するよう求めている。Snowflake の2024年7月の誓約発表（https://www.snowflake.com/en/blog/snowflake-cybersecurity-cisa-secure-by-design/）は、同社をその公約の枠内に位置づけた。この誓約は任意であり、キャンペーンに対する法的判断ではない。しかし、それが関連性を持つのは、顧客が事後に期待すべき証拠の種類を特定しているからだ。

ネットワークポリシーは第二の関門だった

Mandiant は、ネットワーク許可リストの欠如を繰り返し見られる要因の一つとして特定した。Snowflake のネットワークポリシードキュメント（https://docs.snowflake.com/en/user-guide/network-policies）は実質的なデフォルトを明記している：ポリシーがない場合、ユーザーは任意のコンピューターまたはデバイスから接続できる。顧客は許可またはブロックするネットワークロケーションによってアクセスを制限し、より強固な境界のためにプライベート接続パターンを使用できる。

正当な起点を知るのに最適な立場にあるのは顧客である：オフィス、VPN、クラウドワークロード、管理されたコントラクターデスクトップ、承認された統合プロバイダなど。Snowflake はサービスを中断せずにあらゆる有効な経路を推測することはできない。しかし、Snowflake は無制限のパブリックアクセスを沈黙させるか可視化するかを制御する。検証可能な修復プログラムは、どのアカウントにネットワークポリシーが欠けているか、どの特権ユーザーがそれを迂回しているか、内部ステージアクセスが対象に含まれているか、ポリシーが実際にビジネス承認済みの起点と一致しているかを報告すべきである。

ネットワーク制御だけでは十分ではない。攻撃者は承認済みの VPN を使用したり、既に許可リストに含まれているコントラクターマシンを侵害したり、認証後にトークンを盗んだりする可能性がある。しかし、防御は多層的であるべきである。盗まれたパスワード、MFA なし、ネットワーク制限なし、広範なロール、監視されないエクスポートは連鎖である。どれか一つのリンクを断つことが重要となりうる。修復とは、すべてのリンクが同時に開いたままである顧客環境の数を減らすプロセスである。

プロバイダはまた、ロックアウト管理を安全にすべきである。管理者は、ビジネスユーザーやサービスジョブをブロックすることを恐れてネットワークポリシーを避けるかもしれない。シミュレーション、段階的展開、緊急連絡先、一時的例外、明確なログがその恐れを軽減する。移行経路が優れているほど、ポリシー欠如を通常扱いすることが難しくなる。

テレメトリは証拠の境界である

データ窃取キャンペーンの後、顧客が必要とするのは一般的な安心感だけではない。誰が、どこから、どの要素で、どのクライアントを使用し、どのロールでログインし、どのクエリが実行され、どのオブジェクトが触れられ、どのデータがアンロードされ、どのステージが使用され、どれだけのデータが移動したかを知る必要がある。Snowflake の現在のドキュメントは、そのような作業を支援できる複数のビューを説明している。

LOGIN_HISTORY（https://docs.snowflake.com/en/sql-reference/account-usage/login_history）は、ソース IP、クライアント、成功、要素情報付きでログイン試行を提供する。QUERY_HISTORY（https://docs.snowflake.com/en/sql-reference/account-usage/query_history）は、クエリアクティビティ、ユーザー、ロール、クエリテキスト、結果サイズ、アンロード行数、ネットワーク経由で送信されたバイト数を提供する。ACCESS_HISTORY（https://docs.snowflake.com/en/sql-reference/account-usage/access_history）は、対象エディションにおけるオブジェクトおよびカラムアクセスの再構築に役立つ。Trust Center ドキュメント（https://docs.snowflake.com/en/user-guide/trust-center/overview）は、MFA やネットワークポリシー、危険なサインイン、異常な IP アドレス、大規模転送に関するポスチャーチェックと検出を説明している。

これらは能力である。能力は調査準備の証明ではない。顧客は、ビューをクエリする権利を持ち、それらを耐久性のあるセキュリティストレージにエクスポートし、レイテンシと保持期間を理解し、ID プロバイダ、エンドポイント、チケットデータと相関させる必要がある。エディションの違いはフィールドレベルのスコープ精度を変えうる。プロバイダのビューには、アクティブな封じ込めに影響する遅延があるかもしれない。クエリテキストだけでは、顧客がデータマップを持っていない限り、どの個人が含まれていたかをプライバシーチームに伝えられない。

したがって、検証可能な修復には証拠パッケージを含めるべきである。Snowflake が潜在的に露出した顧客に通知する際、顧客はアカウント識別子、ユーザー、タイムスタンプ、起点ネットワーク、第一および第二要素の状態、クライアント識別子、セッションおよびクエリ識別子、ロール、触れられたオブジェクト、ステージ名、アンロード量、信頼度、推奨される封じ込め措置を受け取るべきである。「潜在的に露出」といったラベルは入口として許容されるが、顧客が個人情報が関与したかどうかを判断するのに十分なデータが続かなければならない。

プロバイダ介入には事前の権限も必要である。クラウドプロバイダは顧客より早く不審なアクティビティを察知するかもしれないが、セッションを自動的にブロックすると本番を中断させる可能性がある。行動しなければ窃取を許すことになる。修復では、一時停止の閾値、緊急顧客連絡先、証拠保存、上書き手順を定義すべきである。顧客はいつでも対応できるセキュリティ連絡先を指名すべきである。Snowflake は、クロスカスタマーシグナルから顧客通知までの時間、および通知から封じ込めまでの時間を測定すべきである。

データのローカリティはアクセスで止まった

Snowflake のリージョン選択は、レイテンシ、レジリエンス、プライバシー、調達に影響しうる。サポート対象リージョンのドキュメント（https://docs.snowflake.com/en/user-guide/intro-regions）は、アカウントが一つのリージョンでホストされ、ユーザーが明示的にコピー、移動、またはレプリケーションしない限りデータはそこに留まると述べている。また重要な制限も述べている：リージョン選択は Snowflake へのユーザーアクセスを制限しない。

本キャンペーンはその制限を主権問題に変えた。顧客のテーブルは承認されたリージョンに保存されていたかもしれない。有効な ID は依然として別の場所から接続し、データをクエリし、ステージにアンロードし、コピーをダウンロードできた。ソースアカウントの配置はリモートアクセスやエクスポートを防がなかった。公開されたキャンペーン記録は、すべての被害者のソース国と宛先国を確定していないため、普遍的な越境の法的結論は支持できない。アーキテクチャ上の教訓は変わらない：ストレージのローカリティはアクセスのローカリティではない。

Snowflake のクロスリージョン共有ガイダンス（https://docs.snowflake.com/en/user-guide/secure-data-sharing-across-regions-plaforms.html）は、データを別のリージョンや国にレプリケーションする前に、法的および規制上の制限を確認するよう顧客に警告している。このガイダンスは承認された移動に関するものだ。認証情報に駆動されたエクスポートは異なる。なぜなら、ソースアカウントのリージョンを変更することなく、選択されたリージョン外に制御されないコピーを作成しうるからだ。ソースリージョンのみを記録するデータインベントリは、正確でもエクスポート後には不完全になりうる。

したがって、データ主権の修復には4つの層が必要である：信頼できるデータがどこにホストされているか、どの ID がどのデバイスと管轄区域から接続できるか、どの移動機能がコピーを作成しうるか、インシデント後にどのような証拠が存在するか。Snowflake はリージョン提供、認証、ネットワークツール、エクスポートメカニズム、テレメトリを制御する。顧客は法的根拠、データフィールド、ロール付与、移動承認、通知分析を制御する。両者は境界において証拠を必要とする。

顧客事例は影響を示すが、単一の全体数ではない

本キャンペーンの公的な形状は、影響を受けた企業による開示によって影響された。各記録はそれ自身の事実の範囲内に留まらなければならない。

Live Nation の2024年5月の提出書類（https://www.sec.gov/Archives/edgar/data/1335258/000133525824000081/lyv-20240520.htm）は、同社が主に Ticketmaster データを含むサードパーティのクラウドデータベース環境における不正なアクティビティを特定し、後に犯罪者が会社のユーザーデータと称するものを売りに出したと述べた。提出書類は Snowflake の名前を出さず、確認された影響を受けた個人の人数も提供しなかった。

Ticketmaster Canada のインシデントページ（https://help.ticketmaster.ca/hc/en-us/articles/26420491205009-Ticketmaster-Data-Security-Incident）は、隔離されたサードパーティのクラウドデータベース、一部の北米チケット購入者に関する可能性のあるフィールド、そして Ticketmaster の顧客アカウントは影響を受けなかったという境界を説明した。カナダのプライバシーコミッショナーは、後に議会ブリーフィング（https://www.priv.gc.ca/en/privacy-and-transparency-at-the-opc/proactive-disclosure/opc-parl-bp/ethi_20251006/is_20251006/）において Snowflake を Ticketmaster のプロバイダとして特定し、同時に調査が継続中であり、Ticketmaster Canada が審査対象の管理者であるままであると示した。

AT&T の2024年7月の提出書類（https://www.sec.gov/Archives/edgar/data/732717/000073271724000046/t-20240506.htm）は、サードパーティのクラウドプラットフォーム上の AT&T ワークスペースへの不正アクセスと、通話およびテキストのインタラクション記録の持ち出しを説明した。提出書類は Snowflake の名前を出さなかった。これは、開示された一つのサードパーティクラウドワークスペースインシデントとそのフィールド境界を理解するのに有用だが、独立した属性付与のためではない。

これらの例は、キャンペーン全体の個人人数を生み出さない。Mandiant の約165の潜在的に露出した組織は通知対象母数であり、確定した被害者数、レコード数、影響を受けた個人の人数ではない。各顧客は異なるデータ、ロール、保持期間、リージョン、通知義務を抱えていた。検証可能な修復は、各顧客が自分自身の事実を特定できるよう支援すべきであり、単一のプラットフォームレベルの数字にすべてを委ねるべきではない。

証拠パッケージのためのタイポグラフィに関する注意

顧客が重大度の高いクラウドセキュリティ証拠を受け取った際、レイアウトが適切な人物の迅速な行動を左右しうる。セッション、要素、ロール、オブジェクト、転送の表は、プレッシャーの中で読みやすくなければならない。以下のタイポグラフィブロックが公開本文に含まれるのは、証拠設計が修復の一部だからである。

タイポグラフィとは、文字を配置して言語を判読可能、読みやすく、視覚的に魅力的にする芸術および技術である。書体の選択、ポイントサイズ、行長、行間、文字間隔が含まれる。

• タイポグラフィは、15世紀にヨハネス・グーテンベルクによって発明された活版印刷に端を発する。
• 主要な要素には、フォント選択、カーニング、トラッキング、リーディングがある。
• 優れたタイポグラフィは可読性を高め、デザインにおける雰囲気やトーンを伝える。

Snowflake の顧客にとって、読みやすい証拠とは、単一の時間基準によるタイムスタンプ、明確なユーザーとロールのラベル、確認されたアクティビティと疑惑の分離、可視化された MFA 状態、クエリ、ステージ、転送量、影響を受けたデータストア間の直接的なリンクを意味する。ログの高密度なエクスポートは完全かもしれないが使えない。簡潔な証拠パックが、迅速な封じ込め決定と遅延するプライバシー分析の分かれ目になりうる。

実践的管理による説明責任

攻撃者は犯罪行為を管理していた：盗まれた認証情報を使用し、顧客環境に侵入し、データをステージングし、それを持ち出し、販売または恐喝を試みた。彼らはその行為に責任がある。

顧客は多くの失敗したゲートを管理していた。ユーザーを作成し、ロールを割り当て、ヒューマンユーザーがパスワードだけでサインインできるかどうかを選択し、古くなった認証情報を保持し、コントラクターアクセスを許可し、一部のアカウントをネットワークポリシーなしのままにし、データアクセスを付与し、エクスポートを管理していた。高価値なウェアハウスが、MFA も狭いロールもなく、未知の起点からの古いパスワードを受け入れた顧客は、すべての責任をプロバイダに転嫁できない。

Snowflake はベースラインと修復ツールを管理していた。新しいヒューマンユーザーがデフォルトで MFA を持つかどうか、漏洩パスワードがプロバイダ側で無効化されるかどうか、危険な設定が Trust Center に表示されるかどうか、どのテレメトリフィールドが利用可能か、顧客にどのように通知されるか、ガイダンスがどのように書かれるか、キャンペーン後の制御がどれだけ迅速に出荷されるかを管理していた。テナント全体で同じパターンを見るプロバイダには、そのパターンを大規模に低減する義務があり、各顧客にマニュアルを読むよう伝えるだけでは不十分である。

ID プロバイダ、コントラクター、エンドポイント所有者は隣接する条件を管理していた。クライアント間で使用されるコントラクターデバイスは、一つの情報窃取インシデントを複数のクラウドテナントに拡散させる可能性がある。ID プロバイダはより強力な要素及び条件付きアクセスを強制できる。管理されたエンドポイントは認証情報を個人のマシンから遠ざけることができる。これらのアクターは重要だが、Snowflake アカウント自体に対する顧客とプロバイダの義務を消し去るものではない。

規制当局、保険会社、調達チームはインセンティブを管理している。NIST のサプライチェーンガイダンス（https://csrc.nist.gov/pubs/sp/1305/final）は、重要度に比例したサプライヤ要件の定義を支持している。データウェアハウスにとって、それは契約と更新で、MFA 採用指標、漏洩パスワード対応、証拠パッケージフィールド、保持保証、通知タイミング、サポートエスカレーション、リージョナル移動制御を要求すべきことを意味する。MFA の有無だけを尋ねるセキュリティ質問票は、本キャンペーン後では浅すぎる。

持続的な修復を証明するもの

修復記録は少なくとも十の成果を含むべきである。

第一に、すべての新しいヒューマンユーザーがデフォルトで MFA またはより強力なフェデレーテッドアクセスになり、導入ベースでは保護されたヒューマンおよび特権ヒューマンアカウントの割合が上昇していること。第二に、サービスユーザーが静的パスワードからキーペア、OAuth、またはローテーションを備えた他のスコープ付きワークロード認証情報へ移行すること。第三に、漏洩パスワード保護が確認された無効化イベントと無効化までの平均時間を報告すること。第四に、ネットワークポリシーのカバレッジが、特に特権アカウントと内部ステージに対して向上すること。

第五に、Trust Center の検出事項が表示されるだけでなく、例外所有者と有効期限付きで改善されること。第六に、テレメトリの保持とエクスポートが、遅延発見とプライバシースコープ設定に十分であること。第七に、大規模アンロードと異常な起点の検出が調整され、対応できる人々にルーティングされること。第八に、プロバイダ通知に具体的なセッション、クエリ、ロール、オブジェクト、転送の証拠が含まれること。第九に、影響を受けた顧客がクエリを個人および規制データカテゴリにマッピングできること。第十に、顧客契約と更新レビューが共有責任の文言に依存せず、証拠を組み込むこと。

訴訟は記録に影響を与えうるが、制御の証拠に取って代わるべきではない。Snowflake の複数地区訴訟における訴答段階の命令（https://www.govinfo.gov/content/pkg/USCOURTS-mtd-2_24-md-03126/pdf/USCOURTS-mtd-2_24-md-03126-34.pdf）は、特定の申し立てを手続き基準の下で進行させることを認めた。それは責任の最終判断ではない。裁判所が、公的な話が顧客認証情報から始まる場合でも、プロバイダのデフォルト、予見可能性、因果関係を検討し得ることを示している。

導入ベースの問題

安全なデフォルトは作成時に最も効果的である。顧客が既に自動化、サービスユーザー、コントラクター、ID プロバイダ、古いクライアント、緊急アカウントを抱える導入ベースではより困難である。Snowflake の新規アカウントに対するデフォルト MFA 変更は重要な一歩だったが、キャンペーンのリスクは既存の習慣を持つ既存アカウントに大きく存在していた。したがって、検証可能な修復には、新規アカウントの話だけでなく、導入ベース向けの移行ストーリーが必要である。

導入ベースの問題にはいくつかの層がある。第一に、古いヒューマンユーザーは、フェデレーションが完了しなかったために依然としてパスワードで直接認証する可能性がある。第二に、特権ユーザーは、管理者がロックアウトを恐れて例外を抱えているかもしれない。第三に、サービスユーザーが誤って人間に分類されていたり、人間がサービス形式の認証情報を使用している可能性がある。第四に、コントラクターはプロジェクト終了後もアクセスを保持しているかもしれない。第五に、休眠アカウントが依然として機密データに到達するロールを持っているかもしれない。第六に、パスワードルールやネットワークポリシーが突然変更されると統合が失敗するかもしれない。

プロバイダは、顧客のテナントを乗っ取ることなく、この摩擦を軽減できる。管理者に、特権とデータ到達範囲で分けられたリスクの高い ID の優先順位付きリストを表示できる。MFA やネットワーク制限によって誰がブロックされるかを示すドライランポリシーを提供できる。例外所有者と有効期限の設定を要求できる。緊急用アカウントを通常のレガシーアカウントから区別できる。サービスユーザー向けにキーペアや OAuth パターンへの移行支援を提供できる。一般的なバナーではなく、実際のリスクに紐付いた繰り返しの製品ナッジを送ることができる。

そして顧客は行動しなければならない。特権パスワードのみのユーザーを示すダッシュボードを受け取り、何ヶ月も変更せずに放置する顧客は、その残余リスクを所有する。コントラクターアカウントがまだ必要かどうか判断できない顧客は、ID ガバナンスの失敗を所有する。「以前パイプラインで必要だったから」という理由でサービスアカウントに生テーブル全体の読み取りを許可する顧客は、過剰なロール範囲を所有する。プロバイダが証拠を示し、顧客がそれを改善するか、責任ある例外として記録することで、共有責任は具体化する。

修復記録は三つの状態を区別すべきである：改善済み、例外、不明。改善済みはリスク状態が解消されたことを意味する。例外は、ビジネス所有者が補償的制御とレビュー日付付きで受け入れたことを意味する。不明は誰も責任を負っていないことを意味する。成熟したプログラムは不明の数をゼロに向かわせる。公的な安心材料はしばしばこの区別を省略するが、検証可能な修復はそれに依存する。

顧客の証拠は技術ログを人々に結びつけなければならない

Snowflake は豊富な技術テレメトリを公開できるが、プライバシーと法的対応には、技術的オブジェクトから人々と義務への橋渡しが必要である。クエリ識別子、ロール名、ステージパスは出発点に過ぎない。顧客は、どのテーブルがどの個人フィールドを保持していたか、どのデータ主体が含まれていたか、どの国や州の規制が適用されるか、どの契約上の通知義務が存在するか、どの下流システムがコピーを受け取ったかを知らなければならない。この橋渡しがなければ、顧客はバイトが去ったことは知っていても、誰に通知すべきかはわからないかもしれない。

その橋渡しはインシデント前に準備されるべきである。データ所有者は、規制対象データ、ビジネス目的、保持期間、マスキングポリシー、承認されたエクスポートルートのフィールド目録を維持すべきである。セキュリティチームは、Snowflake のログがプラットフォーム外のどこに、どのくらいの期間保持されるかを把握すべきである。プライバシーチームは、影響を受けたテーブルのリストを要求し、人々とフィールドのカテゴリへのマッピングを受け取れるべきである。法務チームは、それらの記録にどの地域と顧客契約が付随しているかを把握すべきである。

プロバイダの証拠はこれを容易にすることができる。通知に正確なロール、オブジェクト、ステージ、ボリュームが含まれていれば、顧客は広くて遅い調査を回避できる。プロバイダがさらに、MFA の有無、ソースが異常だったかどうか、漏洩パスワード保護が後に認証情報を無効化したかどうかをラベル付けすれば、顧客は原因と封じ込めを理解できる。プロバイダが一般的なアドバイスしか提供しない場合、顧客は通知と恐喝対応のタイムリミットが既に進行している中で証拠を再構築しなければならない。

本キャンペーンはまた、テレメトリ自体に関する保持の問題を露呈した。ネイティブ履歴は1年間をカバーするかもしれないが、法的紛争、発見の遅れ、規制当局の問い合わせはより長期に及ぶ可能性がある。高リスクの顧客は、ログを自らの義務に合わせた保持期間を持つ独立したセキュリティストアにストリーミングすべきである。プロバイダはそのようなエクスポートを実用的かつ文書化すべきである。顧客は、定期的にログインからクエリ、データカテゴリに至るサンプルアクセス経路を再構築することで、それが機能することを証明すべきである。

修復は顧客の羞恥心に頼ることはできない

認証情報キャンペーンの後、MFA を持たない顧客を話の教訓として扱いたくなる。それは部分的には真実だが、それでも不十分である。顧客を公然と非難しても、漏洩パスワードは無効化されず、デフォルトは再設計されず、証拠パッケージも届かない。それは顧客に、インシデントが開示を強いるまで脆弱な設定を隠させることにもなりかねない。

より良いモデルは段階的な強化である。プロバイダは可視化から始め、次により強力なデフォルト、次に的を絞った警告、次に例外のガバナンス、そして結果が正当化するリスクカテゴリに対して強制を行う。顧客は移行時間とツールを受け取るが、高リスクのギャップを見えないままにする能力も失う。すると調達チームは機能リストだけでなく、採用指標と例外件数を要求するようになる。

このアプローチは、クラウドプラットフォームがビジネスデータのための共有オペレーティングシステムであることを認識している。より安全なデフォルトを作るプロバイダは、短期的には顧客の摩擦を増やすかもしれないが、犯罪グループが利用できる標的の母集団も減らす。強制を受け入れる顧客は、スクリプトや ID を更新する必要が生じるかもしれないが、規制当局、保険会社、データ主体に対してより強力なストーリーを得る。修復は、両者が変わったメッセージではなく、変わった状況を指摘できるときに機能する。

調達は修復テレメトリを要求すべきである

高価値データプラットフォームの購入者は、キャンペーン後のテレメトリを調達要件として扱うべきである。問われるのは、プロバイダが現在 MFA、ネットワークポリシー、漏洩パスワード制御、Trust Center の検出事項を提供しているかどうかだけではない。問われるのは、購入者が自身のアカウントにおいて、それらの制御がアクティブで、完全で、テスト済みであるという証拠を受け取れるかどうかである。機能の有無はサプライヤの言葉である。制御のカバレッジは運用の言葉である。

調達記録は、ヒューマンユーザー、特権ユーザー、サービスユーザー、休眠アカウント、外部コントラクター、フェデレーション状況、MFA 状況、パスワード例外を含む ID カバレッジレポートを求めるべきである。アカウント別、ユーザークラス別、内部ステージ別、プライベートエンドポイント別のネットワークカバレッジを求めるべきである。漏洩パスワード保護が有効かどうか、どのようなイベント通知を生成するか、無効化されたパスワードが監査記録にどのように反映されるかを尋ねるべきである。契約ティアで利用可能な Trust Center の検出事項と、関連履歴がどれだけ保持されるかを尋ねるべきである。

インシデント条件も同様に具体的であるべきである。一般的な通知条項はこのキャンペーンの後では弱い。顧客は、高重大度通知のタイムライン、含まれる証拠フィールド、緊急連絡先、サポートエスカレーション、ログの保存、データ主体スコープ設定における協力を必要とする。規制対象の個人データを保持する顧客は、窃取後ではなく更新前にサンプル証拠パケットを要求すべきである。机上訓練により、プロバイダと顧客が不審なログインから影響フィールド分析までを必要な時間枠内で進められるかをテストできる。

これによりすべての作業が Snowflake に移るわけではない。顧客は自らのマップを維持し、ログを保持し、プライバシー義務を把握しなければならない。しかし、プロバイダはそのマップが利用可能になるために必要な多くの事実を管理している。証明書だけを求める調達プロセスは、運用上の課題を見逃す。修復テレメトリを求めるプロセスは、共有責任が次のキャンペーンに備えているかどうかを明らかにする。

同じ証拠が更新時にも現れるべきである。キャンペーンの1年後も顧客がパスワード主体のアクセスにとどまっている場合、更新では名前付き例外または資金提供された移行を強制すべきである。エディションのために ACCESS_HISTORY レベルの詳細を受け取れない場合、更新ではその制限が保存データにとって許容可能かどうかを文書化すべきである。ネットワークポリシーが欠如している場合、更新では運用上のブロッカーを明確に特定すべきである。修復は、テコが別の契約期間に消える前にレビューされるべきである。

更新証拠はまた、プラットフォームの変更とテナントの変更を区別すべきである。Snowflake はより強力なデフォルトを出荷できるが、顧客のアカウントには依然としてパスワードのみのユーザー、広範なロール、古いコントラクター、未レビューのステージが含まれている可能性がある。購入者は、プロバイダの製品ロードマップだけでなく、アカウント自身の例外台帳を求めるべきである。この区別は、よくあるインシデント後の漂流を防ぐ：プロバイダが制御を発表し、顧客はリスクが移ったと想定し、導入ベースは実質的に露出したままになる。

取締役会やプライバシーチームにとって、そのテナントレベルの記録は技術的修復と法的確信の間の橋渡しである。「MFA は利用可能」という主張は、影響を受けたアカウントがそれを使っていたかどうかには答えない。「ネットワークポリシーは存在する」という主張は、盗まれた認証情報が異常な起点からデータに到達できたかどうかには答えない。「テレメトリは保持されている」という主張は、組織がクエリを規制対象フィールドにマッピングできるかどうかには答えない。検証可能な修復は、そうしたアカウント固有の回答の中に存在する。

推論すべきでないこと

抑制的な記述は四つの飛躍を避けるべきである。第一に、本キャンペーンは Snowflake の本番プラットフォームが侵害されたことを証明しない。第二に、通知されたすべての組織がデータを失ったことを証明しない。第三に、影響を受けたすべての顧客が同じフィールド、人々、法的義務を抱えていたことを証明しない。第四に、キャンペーン後の製品変更それ自体は、変更前の過失を証明するものではない。セキュリティ製品は、より優れた脅威インテリジェンスや変化した基準を含む多くの理由でインシデント後に進化する。

同時に、抑制はプロバイダの義務について沈黙することを要求しない。プロバイダはプラットフォーム侵害の認定を免れつつも、デフォルト設計、テレメトリの品質、クロスカスタマー警告について説明責任を負いうる。顧客は弱い ID 管理に過失がありつつも、調査のためにプロバイダのデータを必要としうる。訴訟命令は最終的でなくとも、デフォルト MFA と予見可能性が精査されることを示しうる。バランスのとれた説明責任は、こうしたすべての命題を同時に生かし続ける。

最終評価は高い影響と高い信頼性である。確認された証拠は、Snowflake のプラットフォーム侵害ではなく、顧客認証情報キャンペーンを裏付ける。しかし証拠はまた、プロバイダのデフォルト、テレメトリ、クロスカスタマーセキュリティ自動化が説明責任の一部である理由も示している。共有責任は、両者が閉じたゲートを示すことができて初めて信頼に足るものとなる。このキャンペーンの後、Snowflake の試金石は、MFA が存在したと言えるかどうかではない。より少ない盗まれたパスワードがセッションになり、より少ないセッションが広範なデータに到達し、より多くの顧客がデータが去る前に何が起こったかを正確に証明できるかどうかである。