ZARA・7-Eleven・Udemyが流出した経路 ― SaaSは「設定」で破られる
Salesforce Experience Cloud のゲストユーザープロファイル設定の不備を突いた脅威アクター ShinyHunters が、ZARA・7-Eleven・Udemy を含む複数企業の顧客データをリークサイトに公開した。プラットフォーム自体の脆弱性ではなく、「誰でも読める」設定のまま本番公開された API エンドポイントが侵入口となった点が、今回の事案の核心である。
背景
2026年に入り、ShinyHunters は Salesforce Experience Cloud（旧 Community Cloud）を使って構築された企業向け公開ポータルを大規模にスキャンし始めた。同グループが悪用した技術的な起点は、Salesforce のゲストユーザープロファイルに付与された過剰なオブジェクト・フィールドレベルの読み取り権限である。Experience Cloud では、未認証の外部ユーザーがアクセスできる「ゲストプロファイル」が既定で存在し、管理者が意図せず顧客オブジェクトや注文オブジェクトへの参照権限を付与したままにしていたケースが多数確認された。攻撃者はサイトの /services/data/ 配下の REST API エンドポイントに対して認証なしでクエリを送信し、Udemy では 140 万件超・2.3 GB 相当のユーザーデータを窃取したと主張。ZARA・7-Eleven のデータも同様の手口でリークサイト「BreachForums」に掲載された。Salesforce 社はプラットフォームの欠陥ではなく顧客側の設定誤りであるとの立場を示している。
リスクの全体像
今回の脅威モデルは三層で整理できる。①初期侵入：ゲストプロファイルに付いた不要な CRUD 権限と、公開 Experience サイトの API エンドポイントが組み合わさることで、認証を一切必要とせずデータ取得が成立する。攻撃者は Salesforce インスタンス URL のパターン（*.my.salesforce.com / *.force.com）を自動スキャンするだけでよく、特殊なゼロデイは不要である。②データ活用：窃取した氏名・メール・電話番号・購入履歴は vishing（音声フィッシング）の台本として再構成され、「Udemy のサポートです」「ZARA のポイント失効通知です」等の高精度な標的型攻撃に転用されている。③連鎖リスク：Experience Cloud が Slack・MuleSoft・外部 OAuth アプリと連携している場合、ゲストセッションを踏み台にしたトークン横断の可能性も否定できない。責任共有モデルの「クラウドベンダーが守る」という誤解が、設定レビューを後回しにする組織文化と合わさって被害を拡大させた。
チェックリスト
- ゲストユーザープロファイルの権限監査：Salesforce Setup → Profiles → Guest User Profile で、Account・Contact・Order・Case オブジェクトへの Read 権限が本当に必要か一行ずつ確認する。不要な権限はただちに削除する。
- Experience Cloud サイトの API アクセス制御：
/services/data/エンドポイントへのゲストアクセスを許可している設定（「Allow guest users to access public APIs」）が有効になっていないか確認し、不要であれば無効化する。 - SOQL インジェクション・過剰クエリの検知：Event Monitoring または Shield を導入している場合、ゲストユーザーによる大量レコード参照（例：1リクエストで 1,000 件超の SOQL 実行）をアラート閾値に設定し、異常なバルク取得を検知できる体制を整える。
- OAuth 接続アプリの棚卸し：Experience Cloud に連携している外部 OAuth アプリ（Slack・MuleSoft・サードパーティポータル等）のスコープと有効期限を確認し、過剰スコープのトークンは失効させる。
- 公開ポータルのデータ最小化設計の見直し：Udemy 事案を参考に、公開ポータルで表示・取得できるフィールドを「業務上最低限」に絞る設計方針（フィールドレベルセキュリティ）を再定義し、氏名・電話番号・購入履歴の不用意な公開を排除する。
打ち手
優先度の高い順に三つ挙げる。第一に、ゲストユーザープロファイルの権限をただちに最小権限へ絞り込む。これは設定変更のみで完結し、コストゼロで最大のリスク低減効果を得られる。第二に、Salesforce Health Check（Security Center）を実行し、スコアが 80 点未満の項目を洗い出して優先修正する。第三に、Event Monitoring ログを過去 90 日分遡及してゲストユーザーによる大量 API コールが既に発生していないか確認する。既に発生していた場合はインシデントレスポンスフローへ移行する。
「設定ミスは脆弱性より静かに、より深く刺さる」
あわせて読みたい
- 生成AI搭載SaaSのトークン漏洩 ― JWT・OAuthの落とし穴
- AI ベンダー DD（デューデリジェンス）— SaaS と モデル提供者を選ぶ前に聞く 7 質問
- サプライチェーン攻撃 完全ガイド ― ソフトウェアの「部品汚染」はどこから来て、どう防ぐか
- 23万件が漏えいしたECサイト不正アクセス ― パスワードのハッシュ化では守れないもの
Omamori AI の結論
- 事実: ShinyHunters は Salesforce Experience Cloud のゲストユーザープロファイルに残存していた過剰な API 読み取り権限を悪用し、ZARA・7-Eleven・Udemy 等の公開ポータルから認証なしでデータを大量取得した。Udemy では 140 万件超・2.3 GB の漏えいが主張されている。
- 判断軸: 今回の根本原因は Salesforce プラットフォームのゼロデイではなく、「責任共有モデルの顧客側」に属するゲスト権限・API 公開設定の管理不備である。自社の Experience Cloud サイトに同様の設定が残っていれば、同一手口で被害を受けるリスクは現在進行形で存在する。
- 打ち手: ゲストユーザープロファイル権限の即時監査・不要 API アクセスの無効化・Event Monitoring による遡及調査を三点セットで実施する。外部公開ポータルを持つ組織は四半期ごとの設定レビューをセキュリティポリシーに明文化することを推奨する。
経営者視点で考えるべきこと
今回のインシデントが示す経営上の論点は「SaaS を導入すればベンダーが守ってくれる」という前提の誤りである。Salesforce は責任共有モデルに基づき設定・権限管理を顧客責任と明示しており、今回のような設定誤りによる漏えいに対してベンダーへの法的追及は困難である。個人情報保護法の観点では、委託先ではなく自社が安全管理措置義務（20条）を負う主体であり、漏えいが確認された場合は個人情報保護委員会への報告義務（26条）が生じる。取締役会としては、①SaaS の設定管理を IT 部門任せにせず統制設計として位置づけること、②公開ポータルの設計変更に変更管理プロセスを適用すること、③漏えいデータが vishing に転用される二次被害まで含めた事業影響を BCP に織り込むこと、の三点を意思決定の軸とすべきである。ZARA・Udemy 規模の企業でも同様の設定ミスが発生した事実は、組織規模ではなくガバナンス設計の質が防御力を決めることを示している。
