要約
- 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 がこちらで増幅しており、同様に顧客に不正ユーザーアクセスの調査と 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）は、ロール、権限、所有権、階層を説明している。狭いアクセス権が割り当てられた盗まれた認証情報は、広範な読み取り権限やアカウント管理権限が割り当てられたものとは異なる。パイプライン用に構築されたサービスアカウントは、請負業者の管理者とは異なる。最小権限はスローガンではない。それは、敵対的なセッションが1つのビューを返すことと、主要な顧客テーブルを歩き回ることの違いである。
データ分類とマスキングは結果を軽減できる。Snowflake の機密データ分類ドキュメント（https://docs.snowflake.com/en/user-guide/classify-intro）は、機密カラムの発見をマスキングおよび行アクセスポリシーに接続する。これは影響を受けた顧客がそのような制御を持っていたことを証明するものではない。これは修復の経路を示している：顧客は個人および規制対象フィールドを特定し、可能な場合は生のテーブルではなくビューを公開し、エクスポートロールを通常の読み取りロールから分離すべきである。
観察された流出経路は、エクスポートをそれ自体の制御にもしている。一括アンロードはデータプラットフォームでは正当である。それらは分析、バックアップ、ダウンストリーム処理、モデルワークフローをサポートする。しかし、一時的なステージを作成し、大規模な結果をエクスポートし、未知の発信元からダウンロードする異常なセッションは、単なる「クエリ」ではない。それはデータ移動イベントである。修復は、そのようなイベントを測定可能で、属性可能にし、高リスクデータセットについては中断可能にするべきである。
MFA の可用性が MFA の成果になった
MFA はキャンペーンの前に利用可能であった。Mandiant の報告書で成功したアカウントには MFA がなかった。このギャップは共有責任の紛争の核心である。顧客管理者は 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 はネットワーク許可リストの欠如を繰り返し発生する要因の1つとして特定した。Snowflake のネットワークポリシードキュメント（https://docs.snowflake.com/en/user-guide/network-policies）は、実用的なデフォルトを述べている：ポリシーがない場合、ユーザーは任意のコンピュータまたはデバイスから接続できる。顧客は許可またはブロックされたネットワークロケーションによってアクセスを制限し、より強力な境界のためにプライベート接続パターンを使用できる。
顧客は正当な発信元（オフィス、VPN、クラウドワークロード、管理された請負業者デスクトップ、承認された統合プロバイダ）を最もよく知っている立場にある。Snowflake はサービスを中断せずにすべての有効なパスを推測することはできない。しかし、Snowflake は無制限のパブリックアクセスがサイレントか可視化かを制御する。検証可能な修復プログラムは、どのアカウントにネットワークポリシーが欠如しているか、どの特権ユーザーがそれらを迂回しているか、内部ステージへのアクセスがカバーされているか、ポリシーが実際にビジネス承認された発信元と一致しているかを報告するべきである。
ネットワーク制御だけでは十分ではない。攻撃者は承認された VPN を使用したり、許可リスト内の請負業者のマシンを侵害したり、認証後にトークンを盗んだりする可能性がある。しかし、防御は階層的であるべきである。盗まれたパスワード、MFA なし、ネットワーク制限なし、広範なロール、監視されていないエクスポートは連鎖である。1つのリンクを断つことが重要であり得る。修復とは、すべてのリンクが同時に開いたままの顧客環境の数を減らすプロセスである。
プロバイダはまた、ロックアウト管理を安全にするべきである。管理者は、ビジネスユーザーやサービスジョブをブロックすることを恐れて、ネットワークポリシーを避けることがある。シミュレーション、段階的展開、緊急連絡先、一時的な例外、明確なログはその恐れを減らす。移行パスが良ければ良いほど、欠落したポリシーを普通として扱うことが難しくなる。
テレメトリは証拠の境界である
データ盗難キャンペーンの後、顧客は一般的な安心以上のものを必要とする。誰が、どこから、どの要素で、どのクライアントを使用して、どのロールの下でログインしたか、どのクエリが実行されたか、どのオブジェクトが触れられたか、どのデータがアンロードされたか、どのステージが使用されたか、どれだけのデータが移動したかを知る必要がある。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 が潜在的に露出した顧客に通知する場合、顧客はアカウント識別子、ユーザー、タイムスタンプ、発信元ネットワーク、第1および第2要素のステータス、クライアント識別子、セッションおよびクエリ識別子、ロール、触れられたオブジェクト、ステージ名、アンロードボリューム、信頼度、推奨される封じ込めを受け取るべきである。「潜在的に露出」などのラベルは開始としては許容されるが、個人情報が関与していたかどうかを顧客が判断するのに十分なデータが続かなければならない。
プロバイダの介入には事前の権限も必要である。クラウドプロバイダは顧客よりも先に不審なアクティビティを見るかもしれないが、セッションを自動的にブロックすると本番環境を中断する可能性がある。行動しないと盗難を許す可能性がある。修復は、一時的な停止、緊急顧客連絡先、証拠保存、およびオーバーライドのしきい値を定義するべきである。顧客はいつでも行動できるセキュリティ連絡先を指名すべきである。Snowflake は、顧客間のシグナルから顧客通知までの時間、および通知から封じ込めまでの時間を測定すべきである。
データローカリティはアクセスで止まった
Snowflake のリージョン選択は、レイテンシ、復元力、プライバシー、調達にとって重要であり得る。サポートされるリージョンドキュメント（https://docs.snowflake.com/en/user-guide/intro-regions）は、アカウントが1つのリージョンでホストされ、ユーザーが明示的にコピー、移動、または複製しない限りデータはそこに留まると述べている。また、重要な制限も述べている：リージョンの選択は 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 に言及していない。これは、開示された1つのサードパーティクラウドワークスペースインシデントとそのフィールド境界を理解するのに有用であり、単独の属性としてではない。
これらの例は、キャンペーン全体の人物数を作り出さない。Mandiant の約165の潜在的に露出した組織は通知人口であり、確認された被害者数、記録数、または影響を受けた個人数ではない。各顧客は異なるデータ、ロール、保持、リージョン、および通知義務を持っていた。検証可能な修復は、単一のプラットフォームレベルの数値ですべての作業を行うのではなく、各顧客が自らの事実を範囲設定するのに役立たなければならない。
エビデンスパッケージのためのタイポグラフィノート
顧客が高重大性のクラウドセキュリティ証拠を受け取るとき、レイアウトは適切な人物が迅速に行動するかどうかを決定できる。セッション、要素、ロール、オブジェクト、転送のテーブルは、プレッシャーの下で読みやすくなければならない。以下のタイポグラフィブロックは、証拠設計が修復の一部であるため、公開本文に属する。
Snowflake 顧客にとって、読みやすい証拠とは、単一のタイムベースのタイムスタンプ、明確なユーザーおよびロールラベル、確認されたアクティビティと疑惑の分離、可視の MFA ステータス、およびクエリ、ステージ、転送量、影響を受けるデータストア間の直接リンクを意味する。ログの高密度なエクスポートは完全かもしれないが、使用できない。簡潔なエビデンスパックは、迅速な封じ込め決定と遅れたプライバシー分析の違いかもしれない。
実践的制御による説明責任
攻撃者は犯罪活動を制御した：盗まれた認証情報を使用し、顧客環境に侵入し、データをステージングし、取得し、販売または恐喝を試みた。彼らはその行為に対して責任がある。
顧客は多くの失敗したゲートを制御した。彼らはユーザーを作成し、ロールを割り当て、人間ユーザーがパスワードだけでサインインできるかどうかを選択し、古い認証情報を保持し、請負業者のアクセスを許可し、一部のアカウントをネットワークポリシーなしのままにし、データアクセスを許可し、エクスポートを管理した。MFA なし、狭いロールなし、未知の発信元からの古いパスワードを高価値ウェアハウスが受け入れた顧客は、すべての責任をプロバイダに移すことはできない。
Snowflake はベースラインと修復ツールを制御した。同社は、新しい人間ユーザーがデフォルトで MFA を持つかどうか、漏洩したパスワードがプロバイダ側で無効化されるかどうか、リスクのある設定が Trust Center に表示されるかどうか、どのテレメトリフィールドが利用可能か、顧客にどのように通知されるか、ガイダンスがどのように書かれるか、キャンペーン後の制御がどのくらい迅速に出荷されるかを制御した。テナント間で同じパターンを見るプロバイダは、各顧客にマニュアルを読むように伝えるだけでなく、そのパターンを規模で削減する義務がある。
アイデンティティプロバイダ、請負業者、エンドポイント所有者は隣接条件を制御した。クライアント間で使用される請負業者のデバイスは、1つの情報窃取インシデントを複数のクラウドテナントに広げる可能性がある。アイデンティティプロバイダは、より強力な要素と条件付きアクセスを強制できる。管理されたエンドポイントは、認証情報を個人用マシンから遠ざけることができる。これらのアクターは重要であるが、Snowflake アカウント自体に対する顧客およびプロバイダの義務を消去しない。
規制当局、保険会社、調達チームはインセンティブを制御する。NIST のサプライチェーンガイダンス（https://csrc.nist.gov/pubs/sp/1305/final）は、重要度に比例したサプライヤ要件の定義をサポートする。データウェアハウスの場合、それは契約と更新において、MFA 導入指標、漏洩パスワード対応、エビデンスパッケージフィールド、保持保証、通知タイミング、サポートエスカレーション、および地域移動制御を求めるべきであることを意味する。MFA が存在するかどうかのみを尋ねるセキュリティアンケートは、このキャンペーンの後では浅すぎる。
耐久性のある修復を証明するもの
修復記録には少なくとも10の成果を含めるべきである。
第一に、すべての新しい人間ユーザーはデフォルトで 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）は、特定の申し立てを手続き上の基準の下で処理しながら進行を許可した。それは最終的な責任の認定ではない。それは、公的な話が顧客認証情報から始まる場合でも、裁判所がプロバイダのデフォルト、予見可能性、因果関係を調査する可能性があることを示している。
インストールベースの問題
安全なデフォルトは作成時に最も効果的である。顧客がすでに自動化、サービスユーザー、請負業者、アイデンティティプロバイダ、古いクライアント、緊急用アカウントを持っているインストールベースではより難しい。Snowflake の新規アカウントに対するデフォルト MFA 変更は重要なステップであったが、キャンペーンのリスクは既存の習慣を持つ既存のアカウントに大きく存在していた。したがって、検証可能な修復には、新規アカウントの話だけでなく、インストールベースの移行ストーリーが必要である。
インストールベースの問題にはいくつかの層がある。第一に、古い人間ユーザーはフェデレーションが完了しなかったため、まだパスワードで直接認証する可能性がある。第二に、特権ユーザーは管理者がロックアウトを恐れるため例外を持つ可能性がある。第三に、サービスユーザーが人間として誤分類されるか、人間がサービススタイルの認証情報を使用する可能性がある。第四に、請負業者がプロジェクト終了後もアクセスを保持する可能性がある。第五に、休止状態のアカウントが依然として機密データに到達するロールを持つ可能性がある。第六に、パスワードルールやネットワークポリシーが突然変更されると統合が失敗する可能性がある。
プロバイダは顧客のテナントを引き継がずにこの摩擦を減らすことができる。管理者に特権とデータリーチで分割されたリスクのあるアイデンティティの優先順位リストを表示できる。MFA やネットワーク制限によって誰がブロックされるかを示すドライランポリシーを提供できる。例外オーナーと有効期限を要求できる。緊急用アカウントを通常のレガシーアカウントから区別できる。キーペアまたは OAuth パターンに移行するサービスユーザーのための移行支援を提供できる。一般的なバナーではなく実際のリスクに結びついた製品内ナッジを繰り返し送信できる。
その後、顧客は行動しなければならない。特権パスワードのみのユーザーを示すダッシュボードを受け取り、何ヶ月も変更しないままにする顧客は、その残存リスクを所有する。請負業者のアカウントがまだ必要かどうかを判断できない顧客は、アイデンティティガバナンスの失敗を所有する。「パイプラインが以前必要としていた」という理由でサービスアカウントに生のテーブル全体を読み取らせる顧客は、過剰なロールスコープを所有する。プロバイダが証拠を示し、顧客が是正するか記録可能な例外を記録するとき、共有責任は具体的になる。
修復記録は3つの状態を分離するべきである：是正済み、例外、不明。是正済みはリスクのある状態がなくなったことを意味する。例外はビジネスオーナーが補完制御とレビュー日付付きで受け入れたことを意味する。不明は誰も責任を取っていないことを意味する。成熟したプログラムは不明カウントをゼロに近づける。公的な安心はしばしばこの区別をスキップする；検証可能な修復はそれに依存する。
顧客証拠は技術的ログを人に接続しなければならない
Snowflake は豊富な技術的テレメトリを公開できるが、プライバシーと法的対応には、技術的オブジェクトから人と義務へのブリッジが必要である。クエリ識別子、ロール名、ステージパスは始まりに過ぎない。顧客は、どのテーブルがどの個人フィールドを保持していたか、どのデータ主体が表されていたか、どの国または州のルールが適用されるか、どの契約上の通知義務が存在するか、どのダウンストリームシステムがコピーを受け取ったかを知らなければならない。そのブリッジがなければ、顧客はバイトが去ったことを知るかもしれないが、誰に通知すべきかを知らない。
そのブリッジはインシデント前に準備されるべきである。データ所有者は、規制対象データ、ビジネス目的、保持期間、マスキングポリシー、承認されたエクスポートルートのフィールドインベントリを維持すべきである。セキュリティチームは、Snowflake ログがプラットフォーム外のどこに保持され、どのくらいの期間か知っているべきである。プライバシーチームは、影響を受けるテーブルのリストを要求し、人とフィールドのカテゴリへのマッピングを受け取れるべきである。法務チームは、どのリージョンと顧客契約がそれらの記録に付随するかを知っているべきである。
プロバイダの証拠はこれを容易にできる。通知に正確なロール、オブジェクト、ステージ、ボリュームが含まれている場合、顧客は広範で遅い検索を避けることができる。プロバイダが MFA が存在したかどうか、発信元が異常であったかどうか、漏洩パスワード保護が後に認証情報を無効化したかどうかもラベル付けする場合、顧客は原因と封じ込めを理解できる。プロバイダが一般的なアドバイスのみを与える場合、顧客は通知と恐喝対応の時計がすでに動いている間に証拠を再構築しなければならない。
キャンペーンはテレメトリ自体の保持問題も露呈した。ネイティブ履歴は1年をカバーするかもしれないが、法的紛争、遅れた発見、規制当局の問い合わせはより長く延びる可能性がある。高リスク顧客は、自らの義務に合わせた保持で独立したセキュリティストアにログをストリーミングすべきである。プロバイダはそのようなエクスポートを実用的で文書化されたものにするべきである。顧客は、ログインからクエリ、データカテゴリまでのサンプルアクセスパスを定期的に再構築することで、それが機能することを証明すべきである。
修復は顧客の恥辱に依存できない
認証情報キャンペーンの後、MFA のない顧客を物語の教訓として扱うことは魅力的である。それは部分的に真実であり、依然として不十分である。顧客を公的に辱めることは、漏洩したパスワードを無効化したり、デフォルトを再設計したり、エビデンスパッケージを提供したりしない。それは、インシデントが開示を強制するまで、顧客が弱い構成を隠すことさえあり得る。
より良いモデルは段階的な強化である。プロバイダは可視性から始め、次により強力なデフォルト、次に対象を絞った警告、次に例外ガバナンス、次に結果が正当化するリスクカテゴリに対する執行を行う。顧客は移行時間とツールを受け取るが、高リスクのギャップを不可視のままにする能力も失う。調達チームはその後、機能リストだけでなく導入指標と例外カウントを求める。
このアプローチは、クラウドプラットフォームがビジネスデータの共有オペレーティングシステムであることを認識する。より安全なデフォルトを作るプロバイダは一時的に顧客の摩擦を増やすかもしれないが、犯罪グループが利用可能なターゲットのプールも減らす。執行を受け入れる顧客は、スクリプトやアイデンティティを更新する必要があるかもしれないが、規制当局、保険会社、データ主体に対してより強いストーリーを得る。修復は、両側が変更された条件を指し示すことができるときに機能する。
調達は修復テレメトリを要求すべきである
高価値データプラットフォームの買い手は、キャンペーン後のテレメトリを調達要件として扱うべきである。問題は、プロバイダが現在 MFA、ネットワークポリシー、漏洩パスワード制御、Trust Center の調査結果を提供しているかどうかだけではない。問題は、買い手が自らのアカウントでそれらの制御がアクティブで、完全で、テストされているという証拠を受け取れるかどうかである。機能の可用性はサプライヤーの言葉である。制御カバレッジは運用言語である。
調達記録は、人間ユーザー、特権ユーザー、サービスユーザー、休止アカウント、外部請負業者、フェデレーションステータス、MFA ステータス、パスワード例外を含むアイデンティティカバレッジレポートを要求すべきである。アカウント、ユーザークラス、内部ステージ、プライベートエンドポイント別のネットワークカバレッジを要求すべきである。漏洩パスワード保護が有効かどうか、どのようなイベント通知を生成するか、無効化されたパスワードが監査記録にどのように反映されるかを尋ねるべきである。契約したティアでどの Trust Center の調査結果が利用可能か、関連する履歴がどのくらい保持されるかを尋ねるべきである。
インシデント条項も同様に具体的であるべきである。一般的な通知条項はこのキャンペーンの後では弱い。顧客は高重大性通知のタイムライン、含まれる証拠フィールド、緊急連絡先、サポートエスカレーション、ログの保存、データ主体スコーピングにおける協力を必要とする。規制された個人データを保持する顧客は、盗難の前ではなく、更新前にサンプルエビデンスパケットを要求すべきである。机上演習は、プロバイダと顧客が不審なログインから影響を受けるフィールド分析まで必要なウィンドウ内に移動できるかどうかをテストできる。
これはすべての作業を Snowflake に移すものではない。顧客は自らのマップを維持し、ログを保持し、プライバシー義務を知らなければならない。しかし、プロバイダはマップを使用可能にするために必要な多くの事実を制御する。証明のみを求める調達プロセスは運用上の問題を見逃す。修復テレメトリを求めるプロセスは、共有責任が次のキャンペーンの準備ができているかどうかを明らかにする。
同じ証拠が更新に現れるべきである。顧客がキャンペーンの1年後もパスワード主体のアクセスに留まっている場合、更新は名前付き例外または資金提供された移行を強制すべきである。顧客がエディションのために ACCESS_HISTORY レベルの詳細を受け取れない場合、更新はその制限が保存されたデータに対して許容可能かどうかを文書化すべきである。ネットワークポリシーがない場合、更新は運用上のブロッカーを明確に特定すべきである。修復は、レバレッジが別の契約期間に消える前にレビューされるべきである。
更新証拠はまた、プラットフォームの変更とテナントの変更を分離すべきである。Snowflake はより強力なデフォルトを出荷できるが、顧客のアカウントにはまだパスワードのみのユーザー、広範なロール、古い請負業者、未レビューのステージが含まれている可能性がある。買い手は、プロバイダの製品ロードマップだけでなく、アカウント自体の例外台帳を尋ねるべきである。その区別は、よくあるインシデント後の漂流を防ぐ：プロバイダが制御を発表し、顧客はリスクが移動したと想定し、インストールベースは実質的に露出したままである。
取締役会とプライバシーチームにとって、そのテナントレベルの記録は、技術的修復と法的確信の間の橋渡しである。「MFA が利用可能である」という主張は、影響を受けたアカウントがそれを使用したかどうかに答えない。「ネットワークポリシーが存在する」という主張は、盗まれた認証情報が異常な発信元からデータに到達できたかどうかに答えない。「テレメトリが保持されている」という主張は、組織がクエリを規制されたフィールドにマッピングできるかどうかに答えない。検証可能な修復は、それらのアカウント固有の回答に存在する。
推測すべきでないこと
抑制された説明は4つの飛躍を避けるべきである。第一に、キャンペーンは Snowflake の本番プラットフォームが侵害されたことを証明しない。第二に、通知されたすべての組織がデータを失ったことを証明しない。第三に、影響を受けたすべての顧客が同じフィールド、人、法的義務を持っていたことを証明しない。第四に、キャンペーン後の製品変更は、それ自体で変更前の過失を証明しない。セキュリティ製品は、より優れた脅威インテリジェンスや変更された基準を含む多くの理由でインシデント後に進化する。
同時に、抑制はプロバイダの義務についての沈黙を必要としない。プロバイダはプラットフォーム侵害の発見がなくても、デフォルト設計、テレメトリ品質、顧客間警告について説明責任を負うことができる。顧客は弱い ID 制御について責任を負うことができ、同時に調査のためにプロバイダのデータを必要とすることができる。訴訟命令は最終的でなくても、デフォルト MFA と予見可能性が精査されることを示すことができる。バランスの取れた説明責任は、それらの命題すべてを同時に生かし続ける。
最終的な評価は、高い影響と高い信頼性である。確認された証拠は、Snowflake プラットフォームの侵害ではなく、顧客認証情報のキャンペーンを支持する。しかし、証拠はまた、プロバイダのデフォルト、テレメトリ、および顧客間のセキュリティ自動化がなぜ説明責任の一部であるかを示している。共有責任は、両側が閉じたゲートを示すことができる場合にのみ信頼できる。このキャンペーンの後、Snowflake のテストは、MFA が存在したと言えるかどうかではない。それは、盗まれたパスワードがセッションになることが少なくなり、より少ないセッションが広範なデータに到達でき、より多くの顧客がデータが去る前に正確に何が起こったかを証明できるかどうかである。