2026年11月4日 公表 設定・運用ミス 調査中 影響度:中

電通総研「FACERE」、アクセス権限の設定不備で利用企業の保管データが閲覧可能な状態に

対象組織:株式会社電通総研(「FACERE」) / 規模:特定の利用企業1社の環境の保管データ(件数は未公表)
// WHAT HAPPENED

電通総研が開発・提供する「FACERE」を利用する特定企業の環境で、同社のアクセス権限の設定不備により保管データが第三者に閲覧可能な状態にあり、2026年9月10日に不正アクセスが行われ個人情報が流出した可能性があると公表されました。他の利用企業の環境では設定不備は見つかっていないとしています。

事案の概要データ

公表日2026年11月4日
不正アクセスが行われた日2026年9月10日
対象「FACERE」を利用する特定企業の環境に保管されていたデータ
原因電通総研のアクセス権限の設定不備により、保管データが第三者に閲覧可能な状態にあった
他の利用企業設定不備は見つかっていない
件数公表されていない
分類設定・運用ミス(不正アクセスを伴う)
公表までの期間不正アクセスの日から約2か月

図解:この事故の構造

図:提供元のアクセス権限の設定不備により、利用企業の保管データが閲覧可能な状態になっていた。
本来の想定
「FACERE」の利用企業ごとの環境は、アクセス権限によって分離され、その企業の関係者だけが保管データを参照できる状態であるべきだった。
実際に起きたこと
提供元のアクセス権限の設定に不備があり、特定の利用企業の環境の保管データが第三者から閲覧可能な状態にあった。2026年9月10日に不正アクセスが行われ、個人情報が流出した可能性がある。

何が起きたのか

株式会社電通総研は2026年11月4日、同社が開発・提供する「FACERE」を利用する特定企業の環境で、同社のアクセス権限の設定不備により保管データが第三者に閲覧可能な状態にあり、2026年9月10日に不正アクセスが行われ個人情報が流出した可能性があると公表しました。

他の利用企業の環境では設定不備は見つかっていないとしています。件数は公表されていません。

本件は「攻撃者が鍵を破った」事案ではありません。鍵がかかっていなかった事案です。

設定ミスは「攻撃を受けなくても」事故になる

脆弱性を突かれる事故と、設定ミスの事故は、性質が違います。

脆弱性は、ソフトの作りに欠陥があり、提供元が修正版を出します。利用する側は、それを適用すれば直ります。

設定ミスは、ソフトに欠陥はありません。使う側(または提供する側)が、権限の設定を間違えたのです。修正版を待っても直りません。

そして怖いのは、誰にも攻撃されなくても、すでに事故が成立していることです。「閲覧可能な状態にあった」期間は、誰かが気づけばいつでも見られた状態です。

本サイトでは2026年11月の1週間だけで、この種の事案を複数扱っています。オシロ「OSIRO」(会員ID・表示名・アイコン画像URLがログインせずに利用できる設定、最大12,661人)、資さんうどん(委託先サーバーの設定不備で従業員・退職者の賃金履歴が閲覧可能)、愛知県「あいこんナビ」(無関係の個人情報599人分を8年間掲載)。原因はすべて設定です。

中小企業がいま確認できることを挙げます。

1. クラウドストレージの共有リンクを棚卸しする。 「リンクを知っている全員が閲覧可」で発行したファイルは、検索で見つかることがあります。

2. 自社サイトのフォルダに、一覧表示(ディレクトリリスティング)が有効になっていないか。 「○○○.jp/files/」でファイルの一覧が出る状態は危険です。

3. 業務システムの権限を、役職ではなく「見る必要があるか」で見直す。 全社員が全顧客データを見られる設定になっていませんか。

4. 外部の業者に作業用アカウントを渡したまま放置していないか。 作業が終わったら削除してください。

「提供する側の設定ミス」だった——利用企業は何をすべきか

本件で注目したいのは、設定を間違えたのが利用企業ではなく、提供元の電通総研だったことです。

利用企業から見ると、これは防ぎにくい事故です。自社のシステムではないので、権限設定の中身を見ることができません。

では何ができるか。3つあります。

①契約時に「権限設定の責任はどちらか」を確認する。 クラウドサービスでは、提供側と利用側で責任が分かれます(責任共有モデルと呼ばれます)。「どこまでが提供元の責任か」を書面で確認しておくと、事故のときに判断が速くなります。

②第三者の認証や監査報告を確認する。 ISMS(ISO 27001)やSOC2の報告書があるか。中小企業が自分で監査することはできませんが、「第三者が見ているか」は聞けます。

③預ける範囲を限定する。 結局これに戻ります。提供元の設定ミスは防げませんが、預けていない情報は漏れません。

そして、事故が起きたときに「自社の環境は対象か」を文書で求めること。本件では「特定企業の環境」と「他の利用企業」が区別されています。この区別を自社宛に書面でもらってください。口頭の「大丈夫です」では、個人情報保護委員会への報告判断ができません。

時系列で見る経過

中小企業が学ぶべきポイント

  1. 鍵を破られたのではなく、鍵がかかっていなかった。設定ミスは誰にも攻撃されなくても事故が成立している。
  2. 脆弱性は修正版の適用で直るが、設定ミスは修正版を待っても直らない。
  3. 2026年11月の1週間でも、設定が原因の事案が複数出ている(OSIRO、資さんうどん、あいこんナビ)。
  4. クラウドストレージの共有リンクを棚卸しする。「リンクを知っている全員が閲覧可」は検索で見つかることがある。
  5. 自社サイトのフォルダでファイル一覧が表示される状態(ディレクトリリスティング)になっていないか確認する。
  6. 権限は役職ではなく「見る必要があるか」で見直す。外部業者の作業用アカウントは作業後に削除する。
  7. クラウドサービスは提供側と利用側で責任が分かれる。権限設定の責任範囲を契約時に書面で確認する。
  8. 事故時は「自社の環境は対象か」を文書でもらう。口頭の「大丈夫です」では報告判断ができない。

出典・参考

ご注意
本記事は、各組織の公表資料および報道をもとに、要点をわかりやすく整理したものです。 被害件数は「漏えいした可能性のある最大件数」として公表されている場合があり、実際に漏えいが確定した件数とは異なることがあります。 また、調査の進展により内容が変わる場合があります。正確な情報は必ず出典元の公式発表をご確認ください。

同じ分類の事故

← 新しい記事:不動産サイト「ウチコミ!」ランサムウェア被害で1… 古い記事:ほっともっと(プレナス)、メールマガジン配信の委… →

もっと深く学びたい方へ

過去の代表的な事件の解説や、セキュリティ用語の基礎知識もまとめています。