Snowflake侵害の実行犯が有罪答弁——“パスワードのみ”という土台の脆さが、司法の場で立証されました

今日の深掘りポイント

• 手口は「最新」ではなく「基本の綻び」——MFA無効＋流出パスワードの再利用で1億人超規模の漏えいに直結しました。
• 司法フェーズへの移行は、認証・鍵管理のベーシックコントロールを怠った場合のリスクを、技術面にとどまらずレピュテーションと法的責任にまで拡張します。
• Data Warehouseは「Tier-0データ資産」——検知はネットワーク周辺ではなくSQLレイヤの出庫（egress）行動にフォーカスすべきです。
• 被害最小化の真打ちは「パスワード廃止」＋「外部ステージ／トークンの棚卸しと強制ローテーション」＋「アクセスポリシーの強制適用」です。
• 越境捜査の現実（米加協力）から、データ主権・ログ保全・通知義務を見直す必要があります。法務・コンプラとSOCの同期が不可欠です。

はじめに

2024年に発生したSnowflakeの顧客アカウント侵害について、関与を認めた被告が連邦裁判所で有罪答弁に至りました。報道によれば、この侵害は少なくとも165組織に波及し、1億人以上の個人情報が漏えい、被告は身代金やデータ販売で約49.5万ドルを得たとされています。判決は10月27日予定です。侵害の起点は「数年前にマルウェアで窃取された古いパスワードの再利用」と「MFA無効アカウント」という、クラウド時代でも色あせない基本の綻びでした。Snowflakeはその後、新規アカウントのMFAをデフォルト有効化しましたが、パスワードのみのサインイン経路は依然として存在します、と報じられています。

このニュースは、華美なゼロデイでも巧妙なサプライチェーン侵害でもありません。企業が日々の運用で後回しにしがちな「認証・鍵管理の当たり前」に穴が空けば、どれほど高機能なクラウド基盤でも、データの“出口”は容易に開いてしまうことを示しています。以下、事実関係を押さえつつ、何を改め、どこを強化すべきかを掘り下げます。

参考：有罪答弁を報じた記事（一次情報は米司法省の資料ですが、本稿では報道を参照しています） The Hacker News

深掘り詳細

事実関係（報道と公開情報の整理）

• 2024年のSnowflake顧客アカウント侵害に関与した被告が、米シアトルの連邦裁判所でコンピュータ詐欺、ワイヤー詐欺、加重身元盗難などの罪を認めたと報じられています。影響は少なくとも165組織、1億人以上の個人情報漏えい規模です。被告は約49.5万ドルを不正に得たとされています。被害の実損は950万ドル以上に上るとの記載もあります（いずれも報道が引用する司法文書に基づく数値）です。
• 侵害は「古いパスワード（マルウェアで窃取）を用いたサインイン＋MFA無効」の組み合わせを起点に成立したと報じられています。Snowflakeは2024年以降、新規アカウントでのMFAデフォルト有効化を進めていますが、パスワードのみのサインイン経路自体は残っています、という点が重要です。
• 当時の技術分析では、攻撃者は窃取済み認証情報を流用し、データベース内のテーブル列挙と大量抽出、外部ストレージ（攻撃者管理）へのコピーを繰り返し、恐喝・販売へ展開していたと報告されていました。これらは新奇というより「基本の徹底」で破れる類の攻撃です。
• 背景として、Snowflake側の公開情報（Trust Centerやセキュリティ更新）では、MFA適用・ネットワークポリシー・アクセス監査（Access History / Query History）などの強化策が継続的に案内されています。

出典：

• 報道（有罪答弁・被害規模・金額・手口の骨子） The Hacker News
• Snowflakeのセキュリティと更新（製品側の一般的な措置） Snowflake Trust Center

インサイト（IDの「設計ミス」を直す）

• パスワードは「資格情報の単一障害点」です。特にクラウドDWH上のPII・給与・通話記録・パスポート番号等を扱う場合、パスワード認証の温存は「高価な城壁に開けた通用門」に等しいです。理想は「パスワード廃止（Passwordless）」で、少なくとも「SSO強制＋フィッシング耐性MFA（FIDO2/WebAuthn）」へ移行することが、今回の型の攻撃に対して最もコスト効率が高い防御になります。
• データ保護は「入口」よりも「出口」が壊れやすいです。クラウドDWHでは、ネットワーク境界の検知ではなく、SQLレイヤのegress（例：COPY INTO @外部ステージ、巨大なSELECT→エクスポート、見慣れないSTAGE/INTEGRATIONの新設）を日次で監視する運用への転換が不可欠です。
• サービスアカウント・外部ステージ・ストレージ統合の「鍵・トークン在庫管理」は、IAMや端末より遅れがちです。可視化・タグ付け・ローテーション基準（例：90日／イベント駆動）を定義し、強制する仕組みを用意すべきです。
• 司法フェーズの意味：有罪答弁は「技術的事実関係が法廷水準で認定された」ことを意味します。すなわち、MFA無効や流出パスワード再利用といった“運用上の怠慢”が、訴訟・過料・規制当局の関心（と企業の説明責任）に直結する段階に来た、ということです。CISOはセキュリティ投資の正当化において、技術的ROIのみならず「法的・評判リスクの低減」を明確に織り込むべきです。
• 仮説：越境捜査協力（米加など）が奏功した点は、ログ保持・保存場所・可視性の設計にも示唆します。管轄（リージョン）と保持期間、暗号化鍵の管理主体（クラウド事業者／顧客）を、捜査協力や開示義務と衝突しない形で見直すことが、今後のインシデント対応の現実解になり得ます。

脅威シナリオと影響

以下は、本件で観測・報道された事実に、一般的なクラウドDWH環境の攻撃常道を重ねた仮説シナリオです。MITRE ATT&CKのテクニックは参考リンク先を併記します（すべての組織に当てはまるとは限らない点に留意ください）。

• シナリオA：流出認証情報の再利用による即時侵入とデータ持ち出し（仮説）

  • 初期アクセス: 正規アカウントの悪用 T1078 Valid Accounts
  • 防御回避: プロキシ／リレーの悪用（居場所隠し） T1090 Proxy
  • 発見・権限操作: アカウント／ロール列挙と権限変更 T1087 Account Discovery, T1098 Account Manipulation
  • 収集・準備: 大量SELECT、外部ステージの作成・確認（CREATE STAGE/INTEGRATION）
  • 流出: Webサービス／クラウドストレージへの転送 T1567.002 Exfiltration to Cloud Storage
  • 作用: 恐喝・販売（暗号化や破壊ではなく、流出と強要が中心）

• シナリオB：BI/ETL連携に埋もれた外部ステージ経由の静穏な出庫（仮説）

  • 正規連携（ETL、ノートブック、SaaS BI）がもつ永続トークンや外部ステージを悪用
  • 既存の「業務フロー」に擬態したCOPY INTOで、検知を回避（低帯域・長期）
  • 検知は「新規ステージ作成」「権限の異常な委譲」「通常外リージョンのストレージ宛」の三点が鍵です

• シナリオC：端末マルウェア→IdP／ブラウザのセッション奪取→SSO経由でDWHへ（仮説）

  • MFA自体は有効でも、セッショントークンのリプレイやトークン継続時間の長さで迂回
  • IdP側のリスクベース認証と併せて、DWH側でも短命セッション＋再認証の強制が必要です

日本企業への影響は、クラウドDWHが横断データ（国内外の個人データ・従業員データ・サプライヤデータ）を集約する性質ゆえ、単発侵害でも一次・二次被害が長期に及ぶことです。越境捜査・規制当局への報告・関係先通知のオペレーション負荷は、技術的復旧より長く重くのしかかります。技術対策と同時に、法務・広報・顧客対応の動線を平時から擦り合わせることが組織レジリエンスの差になります。

セキュリティ担当者のアクション

優先度（上から順に着手）で整理します。パスワード依存を絶つこと、外部出庫の可視化、鍵・トークンの棚卸しと強制ローテーションを核に据えます。

• 入口を閉じる（Identityファースト）

  • パスワードサインインの段階的廃止を計画する（SSO強制＋FIDO2/WebAuthn）。暫定措置としても、全ローカルユーザーにMFA強制とIPベースのNetwork Policyを適用します。
  • サービスアカウントは「キーペア認証」か「短命トークン（OAuth/外部IdP）」へ。共有・長寿命パスワードの撲滅を宣言します。
  • 「緊急用（Break-glass）」アカウントは最小限にし、オフライン保管＋利用時の即時ローテーションを運用に組み込みます。

• 出口を監視・制御する（SQL/Egress・データ中心）

  • SnowflakeのAccess History / Query History / Login HistoryをSIEMに常時送出し、以下の検知ルールを設定します。
    • 直近7日で初観測のIP/ASN/国からの成功ログイン（ユーザー別の初見IPを抽出）
    • 「CREATE STAGE / CREATE STORAGE INTEGRATION / ALTER STAGE」で外部URL（s3://, gcs://, azure://）を含むもの（新設・変更を日次レビュー）
    • 「COPY INTO @外部ステージ FROM …」や、ROWS_PRODUCED/ BYTES_SCANNEDが異常に大きいSELECTの連続実行
    • 短時間に多ロールへ付与・剥奪が発生したユーザー（権限操作のスパイク）
  • PIIや機微データのテーブルにタグ付けし、タグベースでアクセス監査・DLPルールを適用します（マスキング／ロール制約／時間帯制限）。

• 鍵・トークン・統合の棚卸しと強制ローテーション

  • 外部ステージ（STAGE）／ストレージ統合（INTEGRATION）の一覧を出し、資格情報の埋め込み有無・有効期限・所有者・接続先リージョンを棚卸し。不要なものを即時削除、有効なものは一斉ローテーションを実施します。
  • BI/ETL/SaaS連携（Airflow、dbt、Fivetran、Tableau等）に保存されたシークレットも含めて、保管場所と発行元（誰が、いつ、何に使う）を記録し、90日ローテーションを標準にします。

• 強制と例外管理（ポリシーは「勧告」ではなく「強制」に）

  • アカウントレベルでNetwork Policyを適用（社内・拠点・踏み台・ZTNA経路のみに限定）。一時的な例外は期限付き申請で管理し、期限切れ自動失効を徹底します。
  • セッション管理を強化（短命アクセストークン、機微操作時のステップアップ認証）。特に「CREATE STAGE/INTEGRATION」「権限変更」は再認証を必須にします。

• インシデント前提運用（卓上演習と即応）

  • テーブルトップ演習のテーマに「流出認証情報の再利用→DWH大量出庫→恐喝連絡」を追加し、法務・広報・顧客対応・経営を含めた48時間の初動を固めます。
  • ログ保持と可視性：Login/Query/Access Historyの保持期間を規制・捜査要請に耐える期間へ延長。保全・開示の手順書を法務と合意しておきます。

• 検知のためのクエリ例（環境に合わせて調整してください）

  • 新規外部ステージ作成の検知
    • Query Historyで「CREATE STAGE」かつURLを含むものを抽出（例：'s3://', 'gcs://', 'azure://')
  • 異常なエクスポートの検知
    • Query Historyで「COPY INTO @% FROM %」を検索し、ROWS_PRODUCEDやBYTES_SCANNEDが過去90日分位相から外れたものをフラグ
  • 初見IPからの成功ログイン
    • Login Historyでユーザー×IPの初回観測を日次で差分抽出、業務上の妥当性を確認

• ガバナンスと法令対応

  • データ所在（リージョン／クラウド）と越境移転の実態を最新化し、通知義務・監督官庁・捜査協力の窓口を一枚絵にします。暗号鍵の管理主体（事業者／顧客）も明示し、鍵分離（顧客管理鍵）を原則に検討します。

本件の性質上、メトリクス的には「驚き」より「確度と即応性」を重視すべき局面です。新奇性は高くありませんが、影響半径と再現性が高く、かつコントロール可能な領域（認証・鍵・監査）に直撃しています。現場の優先順位は「設計の是正（パスワード廃止・MFA強制）→出庫監視→トークン在庫の健全化」の順で固めるのが合理的です。

参考情報

• Snowflakeハッカーの有罪答弁を報じた記事（事件の最新動向）: The Hacker News
• MITRE ATT&CK（技術参照）: T1078 Valid Accounts, T1090 Proxy, T1087 Account Discovery, T1098 Account Manipulation, T1567.002 Exfiltration to Cloud Storage
• Snowflake Trust Center（セキュリティ関連の公式情報・更新の入口）: https://trust.snowflake.com/
• Google Cloud Threat Intelligence（クラウド上の脅威解説の総合リソース）: https://cloud.google.com/blog/topics/threat-intelligence

（注：本稿の司法手続・被害規模・金額等の数値は、上記報道が引用する公的文書に基づく記載を参照しています。技術的背景の一般論は公開情報に基づく筆者の分析であり、個別組織の状況により適用可能性が異なります。）