記事一覧に戻る
security-news2026年9月21日14分で読めます

同じ入口、違う結末 — ApplyNow事案が見せた「検知」「削除」「公表」の差

録画面接SaaS「ApplyNow」への不正アクセスで、所沢市など8市が受験者情報の漏えいを公表した。入口はデータ分析ツール。8月6日のMetabase修正版公開から3日後に始まった侵入を、VOISING・LEAN BODYと並べて読み、結末を分けた「検知」「削除」「公表」の三つの差と、民間企業の被害が外から見えない理由を整理する。

ApplyNow情報漏えいMetabaseBIツールSaaS委託先管理自治体個人情報保護法ガバナンス

同じ入口、違う結末 — ApplyNow事案が見せた「検知」「削除」「公表」の差

受験者に届いた、数年越しの通知

9月19日、所沢市は職員採用試験の受験者情報1,701件の漏えいを公表した。対象は令和4〜7年度に動画投稿型面接へエントリーした人の氏名・メールアドレス・電話番号。原因は市のシステムではない。録画面接サービス「ApplyNow」を提供する株式会社ApplyNow(きちりホールディングス子会社)への不正アクセスである。

同じ事案として、福山市、富士市、島田市、入間市、一宮市、橿原市でも公表が続いている。大阪市も、事業者名こそ公表していないものの、不正アクセス期間や原因が一致する録画面接システムの事案を公表している。公表された対象者ベースでは、8市で5千人規模になる。

入口は「本体」ではなく、横に置かれた分析ツール

ApplyNowの9月9日付の告知によれば、悪用されたのは同社が業務で使っていたデータ分析ツールの脆弱性である。不正アクセス期間は8月9日〜9月7日。対策として「修正版のセキュリティパッチ適用」を挙げており、少なくとも公表時点では修正版が存在する脆弱性だった。製品名は公表されていない。

ここで日付が気になる。

8月6日、Metabaseは深刻な脆弱性への修正版を公開した。攻撃者はMetabaseを奪った後、接続されたデータベースの資格情報を取得し、その接続先からデータを読み出せる。しかもこれは机上の話ではなく、修正前から実際の攻撃に使われていたゼロデイだった。

その3日後、8月9日。ApplyNowで不正アクセスが始まる。

さらに8月10日にはVOISINGのBIツールへの不正アクセスが始まり、8月11日にはLEAN BODYのMetabaseにも侵入されている。

ApplyNowが公表した被害の形も似ている。入口は「データ分析ツール」。そこからデータベース内のテキストデータにアクセスされる一方、画像、PDF、面接動画などファイル実体は別領域にあり、今回の対象外だった。

製品名は出ていない。したがってApplyNowで悪用されたものがMetabase、ましてCVE-2026-72898だったとは断定できない。

ただ、

  • 8月6日 Metabase修正版公開
  • 8月9日 ApplyNow侵入開始
  • 8月10日 VOISINGのBIツール侵入開始
  • 8月11日 LEAN BODYのMetabase侵入

という時系列と、「分析ツールを入口にして接続先のデータを取る」という被害の形は重なる。同じ攻撃キャンペーンだった可能性、少なくとも同じ時期に狙われていたMetabaseだった可能性は、考えておいてよいと思う。

製品が何であれ、3社とも、顧客向けサービスそのものではなく、分析・BI系のツールがデータへの侵入経路になった点は共通する。分析ツールは業務上、本番系または分析用データベースへの読み取り権限や接続情報を持つことがあり、侵害されれば大量取得の足場になり得る。

もしApplyNowの分析ツールがMetabaseだったなら、話はさらに変わる。侵入開始の3日前には修正版が公開されていたことになる。

だからこの事案で見るべきなのは、「パッチを当てればよかった」で終わらない。修正版が出てから攻撃まで、数日しかない世界である。パッチ適用だけに依存すると、公開から適用までの空白が残る。その数日を埋められなかったとき、次に差をつけるのは、分析ツールからの異常な読み出しをどれだけ早く見つけられるかである。

差その1:検知 — 6日と1か月

VOISINGは8月10日に侵入され、16日にデータを持ち出された。検知はその当日で、約2時間後には遮断している。ApplyNowは侵入から検知まで約1か月。告知には「異常なアクセスログを検知」とあるだけで、何が捉えたのかは書かれていない。

入口が同じ型でも、結果は同じにならない。1日違いで始まった二つの侵入が、6日と1か月に分かれた。

差その2:削除 — 残っていたから漏れた

橿原市の対象は2020年度の試験。島田市がこのサービスを使ったのは2022年度の一度きり。それでもデータは残っていた。一宮市は、契約上は期間終了後に廃棄・削除することになっていたが、履行が不十分だったと公表している。

侵入を許したのは脆弱性だが、被害の大きさを決めたのは保存期間である。消してあれば、漏れようがなかった。そして削除は、契約書に書くだけでは起きない。委託元が削除の証跡を求めていたか、事業者側に削除の仕組みがあったか。どちらも、事故が起きて初めて問われている。

差その3:公表 — 見えているのは自治体だけ

ここまでに名前が出た被害組織は、すべて自治体である。だがApplyNowの主な顧客は、飲食や小売など採用数の多い民間企業だ。しかも電子雇用契約サービス「ApplyNow Sign」の対象項目には、個人番号、基礎年金番号、金融機関口座情報が含まれる。氏名と電話番号が中心の自治体分より、はるかに重い。

にもかかわらず、確認できる範囲では、顧客企業名での公表は見当たらない。

これは民間企業が義務を怠っているという話ではない。個人情報保護法では、一定の重大な漏えい等について、個人情報保護委員会への報告と本人への通知が義務になる。一方、事案そのものを広く一般に公表することは原則として義務ではない。個人情報保護委員会も、二次被害や類似事案の防止という観点から、内容に応じた公表が望ましいとしている。

そのため、本人への通知は行われていても、外から検索できる公表資料が残らないケースはあり得る。自治体では住民や議会への説明もあり、公表資料が残りやすい。その差が、今回「自治体だけが見える」状態を作っている可能性がある。

結果として、事案の全体像は誰にも見えない。被害の総数も、マイナンバーを含む件数も、事業者の続報を待つしかない。その続報は、9月9日の第一報以降、まだ確認できていない。公表された8市は、全体像のうち、外から公表資料として確認できる部分である。

セキュリティページは、何に答えていたか

ApplyNowの製品サイトには「安心のセキュリティ」という欄があり、4項目が並ぶ。通信のSSL/TLS暗号化、24時間ごとの自動バックアップ、機器の多重化とSLA99.99%の国内データセンター、そしてプライバシーマークとISO 27001(ISMS)の取得である。

プライバシーマークは、2026年9月1日現在の付与事業者一覧で確認できる(登録番号17003644(04)、有効期限2027年7月1日)。ISMSは、2019年の取得公表と同社サイトの表示までは確認できたが、現在の認証の有効性と適用範囲は独立には確認できていない。

情報セキュリティの三要素に当てはめてみる。バックアップと多重化は可用性、つまり「失わない・止まらない」の話だ。機密性に関わるのは暗号化通信だけで、それも応募者の端末とサーバの間の経路に限られる。

今回起きたのは、保存されているデータが社内の分析ツール経由で読まれた事故である。4項目のどれも、そこには触れていない。保存データの暗号化、社内ツールから本番データベースへの接続管理、パッチ適用の期限、監視と検知、保存期間と削除。事故で問われた点は、すべて書かれていない側にある。

皮肉なことに、ISO 27001の管理策には、技術的脆弱性の管理も、情報の削除も、監視活動も含まれている。認証の枠組みの中に、今回問われた項目は入っていた。ただし認証が示すのは、仕組みを定めて回していると審査で確認されたことであって、8月に出たパッチが社内の分析ツールに当たっていることではない。加えてISMSは、適用範囲を組織が決める。分析ツールや削除の運用がその範囲に入っていたかどうかは、外からは分からない。

なぜこういうページになるのか。調達の確認票が、そう聞くからである。通信は暗号化されているか。バックアップはあるか。認証は持っているか。売る側は聞かれたことに答え、買う側は答えが返ってきたことで確認を終える。ページに嘘は書かれていない。聞く側の問いが、脅威の形と合っていなかった。

事業者の告知に残る空白

続報で確認したい点を挙げておく。

  • 企業ユーザーにパスワード変更を促しているが、漏えい項目にパスワードが無い。項目は「〜を含む」という書き方で、列挙が網羅かどうか分からない
  • Interview Cloudの「外部連携情報」とは何か。連携用のトークン類であれば、顧客企業側で失効と再発行が要る
  • 検知2日後に「技術的措置の完了」とあるが、内容は遮断とパッチ。分析ツールが持っていたデータベース接続資格情報を入れ替えたかどうかは書かれていない
  • 調査は「弁護士と連携」とあるのみで、外部の調査会社への言及が無い

親会社の開示窓口と、子会社の代表が同じ人

きちりホールディングスの9月9日の適時開示で、問合せ先になっているのは常務取締役CFOの葛原昭氏である。

一方、ApplyNow自身の2026年3月の公表でも、代表取締役社長は葛原昭氏となっている。

つまり、親会社側の事故開示の窓口と、事故を起こした子会社の代表が同じ人物である。適時開示の結びには「グループ企業に対してセキュリティの向上と個人情報を含むデータ管理の徹底を促してまいります」とあるが、促す側と促される側に同じ人がいる。

兼務そのものは珍しくない。小さな子会社の代表を親会社の役員が兼ねるのは、ごく普通の形だ。ただ、少なくとも9月9日の開示からは、子会社側の説明を親会社のどの独立した監督機能が検証したのかは分からない。

ApplyNowが預かっているのは、マイナンバーと口座情報を含む、他社の従業員と応募者の情報だ。外食グループの一事業という位置づけと、預かっているデータの重さが釣り合っていたか。これは同社だけの問いではなく、本業の横でSaaSを営むすべての企業に当てはまる。

預ける側が今日できること

  • 利用中のSaaSに、自社のどの個人情報が、いつの分から残っているかを棚卸しする
  • 契約に削除条項があるなら、削除の証跡を求める。無いなら入れる
  • 事故時の通知期限と通知内容を契約で決めておく。今回も、9月7日の検知後、自治体側で影響が判明した時期には数日の幅があった
  • 委託先への確認票に、可用性と認証の有無だけでなく、保存データの暗号化、社内ツールから本番データベースへの接続管理、パッチ適用の期限を入れる
  • 自社の分析・監視・連携ツールを、本番データベースと同じ水準の管理対象に入れる

入口は同じだった。違ったのは、気づくまでの時間と、消していたかどうかと、外から見えるかどうかである。

技術が同じでも、この三つは組織の決めごとで差がつく。

出典

キーワード

  • ApplyNow
  • 情報漏えい
  • Metabase
  • BIツール
  • SaaS
  • 委託先管理
  • 自治体
  • 個人情報保護法
  • ガバナンス
A

Aikido Community Japan

公開日: 2026/9/21

最終更新: 2026/9/21

シェア:

ニュースを購読

セキュリティの最新情報をお届けします。

Aikido Community Japan からのお知らせの受信に同意します。詳しくはプライバシーポリシーをご確認ください。