タグ: 情報漏洩

投稿日:

お名前.com デスクトップクラウドに不正アクセス ―情報流出の影響・補償内容と利用者の対応

Share
お名前.com デスクトップクラウドに不正アクセス ―情報流出の影響・補償内容と利用者の対応アイキャッチ画像

GMOインターネット株式会社は2026年10月24日、「お名前.com デスクトップクラウド」への不正アクセスに関する続報を公表し、情報流出への対応や不正取引による損失の補償方針を明らかにしました。全プランの停止に加え、利用者には取引口座の認証情報や取引履歴の確認が求められています。今回の事案では、今回の事案では、クラウド環境に保存された認証情報と、接続先の取引口座の確認が欠かせません。本記事では公式発表を基に判明した事実と利用者・企業が取るべき対応を整理します。

※本記事は2026年10月26日時点で公表されている情報を基に作成しています。

問い合わせから調査が始まり全プランの停止へ

調査のきっかけは10月19日の利用者からの問い合わせでした。翌20日に一部サーバーで不正なプログラムが見つかり、新規申し込みの受け付けとコントロールパネルが停止されました。19日は公表された調査開始日であり、攻撃が始まった日を示すものではありません。21日午前4時からは全プランのサーバーが順次停止されました。

初報では個人情報の流出や悪用は確認されていないと説明されていました*1が、その後、21日以降に利用者から身に覚えのない取引などの報告が寄せられました。第2報によると、同社は22日に警察へ相談しています*2。古い発表だけで安全性を判断せず、更新後の内容まで確認する必要があります。

影響の可能性があるサーバー数と確定被害を区別する

公表された26,739件は、影響を受ける可能性があるサーバーの数です。すべてのサーバーへの侵入や情報流出が確認されたわけではなく、被害を受けた利用者の人数を示す数字でもありません。その後の発表では、利用者情報の外部流出が確認され、不正取引による損失の補償方針も示されました。一部の利用者からは身に覚えのない取引の報告も寄せられています。ただし、個々の利用者の被害状況や不正取引と本件との因果関係については、引き続き確認が必要です。

また、同社が決済情報をサービスのサーバーに保持していないことと、利用者自身が保存した認証情報の安全性は別の問題です。取引ツールやブラウザに保存した情報も確認対象となります。利用者のパソコンなどへの影響についても調査中であり、端末への感染が一律に確認されたわけではありません。

図1：お名前.com デスクトップクラウドの公表内容と対応の経緯

お名前.com デスクトップクラウドの公表内容と対応の経緯
出典：GMOインターネット株式会社「お名前.com デスクトップクラウドへの不正アクセスに関するお詫びとお知らせ（第3報）」「お客様へのお見舞金のお支払いと不正取引による損失の補償について（第4報）」、GMOインターネットグループ株式会社・GMOインターネット株式会社「不正アクセスに関するお詫びとお知らせ（第2報）」、熊谷正寿氏の公式ブログ「今こそ官民連携で日本を守ろう――『能動的サイバー防御』を具申した理由」を基に作成。
※各資料に記載された出来事の日付と公表日を整理したもので、攻撃の開始日を示す図ではありません。

パスワード変更と全セッションの切断を進める

利用者は、取引口座などのパスワードを変更するとともに、認証済みの全セッションを切断する必要があります。同社は、FX取引に使用していないスマートフォンや別のパソコンから変更するよう案内しています。すでにパスワードを変更した場合も、セッションの切断が必要です。パスワードを変更しても、すでに成立している接続が終了するとは限りません。また、遠隔デスクトップの画面を閉じただけでは、取引口座への接続がすべて終了したとは判断できません。切断方法が分からない場合は、利用している金融事業者に確認してください。

図2：利用者が優先すべき3つの対応

認証情報の変更、全セッションの切断、取引履歴・残高の確認という、目的の異なる3つの対応を整理
出典：GMOインターネット株式会社「お名前.com デスクトップクラウドへの不正アクセスに関するお詫びとお知らせ（第3報）」「『お名前.com デスクトップクラウド』ご利用のお客様へ改めてのお願い（第5報）」を基に作成。

口座の履歴と端末を確認し不審な連絡に応じない

第5報は、口座の履歴と残高を確認し、身に覚えのない取引があれば金融事業者に連絡するよう求めています*3。提供されている場合は二要素認証を設定し、保存済みの認証情報や使い回していたパスワードも見直す必要があります。口座ごとに確認した日時と結果を整理し、異常があれば取引日時や内容を確認できる記録を確保しておきましょう。

パソコンやスマートフォンのフルスキャン、データのバックアップも案内されています。これは二次被害を防ぐための予防的な対応です。バックアップしたファイルの取り扱いにも注意が求められています。攻撃者を名乗る連絡には返信せず、届いたURLやファイルを開かないようにしてください。

FX自動売買の停止後は注文・保有ポジションも確認する

「お名前.com デスクトップクラウド」は、MT4・MT5を用いたFX自動売買向けの仮想専用サーバー（VPS）サービスです。手元のパソコンを起動し続けなくても、クラウド上で取引ツールや自動売買プログラム（EA）を稼働させられます。

VPSの停止により、そこで稼働していたEAも動作を継続できなくなります。ただし、取引業者側に登録済みの注文と、VPS上で実行される処理は区別する必要があります。例えばMetaTrader 4では、トレーリングストップの追随処理は取引端末側で動作するため、端末が停止すると更新も止まります。一方、すでに設定されたストップロスは取引サーバー側で処理されます。[10]利用者は、取引業者の公式画面から注文・保有ポジション・取引履歴を確認し、必要に応じて金融事業者に相談してください。

見舞金と損失補償 代替サービスの条件を確認する

見舞金は発表時点の全利用者に5,000円で、損失補償とは別枠です。補償対象は、同社が本件に起因すると認めた不正取引の実現損失で、市場変動による損失、逸失利益、間接損害は含まれません。現行基盤をそのまま再開せず、契約中で継続利用を希望する利用者には、独立した基盤の代替サービスを案内する方針です。乗り換え後6か月無料で、同意のない移行は行わないとしています。見舞金の手続き・支払時期や代替サービスの開始時期などは10月30日23時59分まで、損失補償の申請方法や支払時期などは11月6日までに案内予定です。

これらは案内期限であり、支払日やサービス開始日ではありません。補償手続きの詳細は公式案内をご確認ください。調査で閲覧専用パスワード等を求める例外がありますが、通常のパスワードや暗証番号は求めないとしています。

事前に指摘されていたセキュリティ対策上の課題

GMOインターネットグループ代表の熊谷正寿氏は10月25日の公式ブログで、社内のセキュリティ専門家から事前に改善課題が指摘され、現場でも対応が進められていたと説明しました*4。一方、サービスの可用性への影響や他案件との優先順位などから、必要な対策を十分かつ迅速に実施できなかったとしています。この説明は、技術的な侵入経路の特定とは別に、セキュリティ上のリスクを把握した後の対応判断や、対策の優先順位付けという組織的な課題を示すものです。

企業は認証情報とログの所在を把握する

企業が外部のクラウドサービスを利用する際は、どの部署が、どの業務で利用し、どのような情報や認証情報を保存しているかを把握しておくことが重要です。サービス名や契約担当者だけでなく、利用アカウントや接続先まで整理することで、インシデント発生時に確認すべき範囲を特定しやすくなります。

IPAは2026年10月9日に出した注意喚起「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」で、部署単位で利用する外部サービスも含めた把握と、ログやアカウントの異常確認を求めています。企業は、ログの保存期間や事業者・利用者それぞれが確認できる範囲を把握し、不審なログインやアカウント変更などの異常を確認できる体制を整えておく必要があります。

クラウドの停止を前提に業務継続の手順を整える

クラウドサービスが停止した場合、企業は影響を受ける業務と、停止中も継続できる業務を把握する必要があります。復旧を待つだけでなく、代替環境への移行や一時的な業務停止について、あらかじめ判断基準と対応手順を定めておくことが重要です。IPAの「中小企業のためのクラウドサービス安全利用の手引き」では、サービス停止時の業務への影響、サービス水準、データの保管・取り出し、サポート体制などの確認を促しています。バックアップの有無だけでなく、必要なデータや設定を取り出し、代替環境で利用できるかを確認しておくことが、業務継続に向けた備えとなります。

調査と業務復旧の判断を専門家と進める

クラウドサービスや端末への侵害が疑われる場合、被害範囲の特定や証拠保全を進めながら、業務復旧に向けた対応を検討する必要があります。ブロードバンドセキュリティ（BBSec）では、デジタルフォレンジック調査を通じて、インシデントの原因や影響範囲の調査、証拠保全、再発防止に向けた支援を提供しています。不正アクセスや情報漏洩が懸念される場合は、確認済みの事実や対象システム、取得可能なログを整理したうえでご相談ください。

BBSec緊急対応支援サービスページリンクバナー

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

Apache Tomcatに8件の脆弱性 ―認証回避と情報漏洩の条件と対策

Share
Apache Tomcatに8件の脆弱性 ―認証回避と情報漏洩の条件と対策アイキャッチ画像

Apache Tomcatに、認証回避や利用者間のデータ混線などを引き起こす計8件の脆弱性が公表されました。対策となるバージョンは、Tomcat 9.0.123、10.1.61、11.0.27です。利用中の系統を確認し、該当する修正版への更新を進める必要があります。今回、特に確認したいのは、認証に使うJNDIRealmの設定、HTTP/2と非同期処理の利用、AJP接続の有無です。影響する機能や条件がそれぞれ異なるため、バージョン情報と実際の構成を照らし合わせることが対応の出発点になります。

修正版の公開は10月12日 脆弱性の詳細公表は10月20日

The Apache Software Foundationは、2026年10月12日に今回の問題を修正したTomcatを公開し、10月20日に脆弱性の詳細を公表しました。国内ではJVNが10月21日に8件のアドバイザリを案内しています。更新プログラムの公開日と、脆弱性情報の公表日には違いがあります。8件は、Tomcat 9、10.1、11の各系統を合わせた件数です。AJPの問題はTomcat 11、APR/Nativeコネクターに関する問題はTomcat 9が対象であり、すべての系統に同じ8件が存在するわけではありません。

図1：Tomcatの系統別修正版

Tomcat 9.0.xは9.0.123、10.1.xは10.1.61、11.0.xは11.0.27で今回の脆弱性を修正
出典：The Apache Software FoundationのTomcat 9・10・11脆弱性情報を基に作成。
影響を受けるバージョンは脆弱性（CVE）ごとに異なります。

認証回避の対象はJNDIRealmの特定設定

CVE-2026-101296は、JNDIRealmでGSSAPI以外のSASL認証方式を使用している場合に、正しいパスワードを提示せず認証を通過できる問題です。JNDIRealmは、Tomcatがディレクトリサービスと連携して利用者を認証するための機能です。今回の確認では、まずこの機能を使用しているかを調べ、使用している場合に認証方式まで確認します。サポート中の系統では、9.0.0.M1～9.0.122、10.1.0-M1～10.1.60、11.0.0-M1～11.0.26が影響範囲です。認証を別の仕組みで実装している場合には、その構成を踏まえて影響を判断します。自社の認証処理がJNDIRealmに依存しているかどうかが確認の分かれ目です。

HTTP/2の非同期処理で別の利用者の情報が漏洩する可能性

CVE-2026-101356は、HTTP/2で非同期Servletを処理する際に、内部オブジェクトが適切に再利用されない問題です。非同期処理中にエラーが発生した後、異なる利用者のリクエストや応答が混在し、別の利用者に情報が漏洩するおそれがあります。影響範囲は、9.0.118～9.0.122、10.1.55～10.1.60、11.0.22～11.0.26です。直近のバージョンも含まれるため、以前に更新したという記録だけでは今回の対策状況を判断できません。実際に稼働しているTomcatのバージョンと、非同期Servletの利用状況を確認する必要があります。

Tomcat 11のAJPで前の応答データが後続の応答に混入

CVE-2026-103119は、WebサーバーとTomcatの連携に使うAJPの処理に関する問題です。大きな非ブロッキング書き込みを行うと、応答本文が同じ接続上の現在のリクエストと次のリクエストに分かれて渡されることがあります。Apacheは、後続リクエストの失敗が起こりやすく、前の応答データが後の応答に漏れる可能性もあると説明しています。対象はTomcat 11.0.0-M25～11.0.26で、11.0.27で修正されています。AJPを使用する構成では、コネクターとアプリケーションの書き込み処理を確認します。

図2：重要な3件で異なる成立条件と影響

JNDIRealmの特定SASL認証による認証回避、HTTP/2非同期処理の混線、AJPの大きな非ブロッキング書き込みによる応答混線の条件と影響を比較
出典：The Apache Software Foundationの脆弱性情報を基に作成。
※各脆弱性の主な成立条件と影響を示したものであり、実際の影響は対象バージョンや利用環境によって異なります。

残る5件も使用機能に応じた確認が必要

今回公表された8件のうち、残る5件はTLS 1.3、HTTP/2、JSP、FIPSモード、APR/Nativeコネクターに関する問題です。それぞれ影響する機能や条件が異なるため、自社の利用環境と照らし合わせて確認する必要があります。

表：その他5件の脆弱性と主な影響

CVE番号主な対象・問題
CVE-2026-93446TLS 1.3接続が断続的に失敗する可能性
CVE-2026-88041HTTP/2のトレーラー情報が後続リクエストに混入
CVE-2026-74049JSTLのリダイレクト後もページ処理が継続
CVE-2026-74048FIPSモードの有効化失敗後も非FIPSモードで動作を継続
CVE-2026-80353APR/NativeコネクターのUnixドメインソケットに権限のないローカル利用者がアクセスできる可能性
出典： The Apache Software Foundation「Apache Tomcat 9・10・11 vulnerabilities」および各CVEのセキュリティアドバイザリを基に作成

深刻度の数値と実際の構成を併せて判断する

ASF独自の評価は、認証回避、HTTP/2の混線、AJPの混線の3件がImportant、残る5件がLowです。CVSSの区分とは異なります。例えばCVE-2026-101356について、Red Hatの公式ページはCVE.orgのCVSS 3.1評価を9.1、自社の評価を5.3と掲載しています。同社は、製品の提供形態やプラットフォームなどによって評価が異なると説明しています。

対応の優先順位を決める際は、こうした評価に加え、自社で問題の機能を使用しているか、誰が対象サービスへアクセスできるかを確認します。該当する認証設定や通信処理を使用している場合は、外部からのアクセス可否や想定される影響を踏まえ、修正版の適用を優先的に検討してください。更新までに時間を要する場合は、脆弱性ごとに有効な緩和策の実施も検討する必要があります。

更新までの緩和策と更新後の確認

今回の基本対策は、利用している系統の修正版への更新です。商用製品などに組み込まれたTomcatを利用している場合は、製品ベンダーに今回のCVEへの対応状況と更新方法を確認してください。Red Hatのように修正を旧版へ取り込む提供元もあるため、パッケージの見かけのバージョンだけで未修正と判断できない場合があります。

Red HatはCVE-2026-101356に対する緩和策として、HTTP/2の利用を停止するための設定変更や、影響を受ける非同期Servletを同期処理へ変更する方法を案内しています。HTTP/2の無効化にあたっては、コネクターの設定や通信方式を確認する必要があります。いずれも個別の問題に対する措置であり、業務への影響を確認したうえで判断する必要があります。

更新後は、稼働中のプロセスが修正版に切り替わったことを確かめ、認証や主要な画面・APIの動作を確認します。複数台で構成している場合は、更新対象を一覧にして適用状況を残すと、対応漏れを確認しやすくなります。緩和策を実施した環境では、更新後に設定を戻すかどうかも含めて管理してください。

Apache Tomcatでは、2025年にもリモートコード実行につながる脆弱性（CVE-2025-24813）が公表されています。今回とは異なる問題ですが、継続的なバージョン管理と適切な設定の重要性を示す事例です。
関連記事：「Apache Tomcatの脆弱性 CVE-2025-24813 ― PoC公開と攻撃事例、必要な対策」

サポート終了版への影響とTomcat 9.0の移行計画

古いTomcatも確認対象です。CVE-2026-101296とCVE-2026-74049について、Apacheはサポート終了済みの8.5.0～8.5.100、7.0.0～7.0.109も影響すると明記しています。さらに、ほかのサポート終了版も影響する可能性があるとしています。現在サポートされている系統の表に載っていないことを、安全性の根拠にはできません。

Tomcat 9.0.xのサポート終了日は2027年3月31日です。一方、Apacheは終了前に9.1.xを提供し、2030年12月31日までリリースを継続する計画を示しています。9.1.xではHTTP・HTTPS・AJP向けのAPR/nativeコネクターが利用できなくなり、Tomcat Native 1.3.xのサポートも終了する予定です。一方、Tomcat Native 2.0.xのサポートは継続されます。現在の脆弱性への更新を進めながら、自社のコネクター構成に合わせて移行準備を進めることが必要です。

BBSecの脆弱性診断でシステム全体の安全性を点検

Apache Tomcatの脆弱性への対応では、修正版の適用に加え、公開サーバーやWebアプリケーションにほかの脆弱性や設定上の問題がないかを確認することも重要です。株式会社ブロードバンドセキュリティ（BBSec）では、サーバーやネットワーク機器を対象とした「ネットワーク脆弱性診断」、WebアプリケーションやAPIを対象とした「Webアプリケーション・API脆弱性診断」を提供しています。SQAT®脆弱性診断サービスでは、ツール診断とエンジニアによる手動診断を組み合わせ、検出した問題の分析と推奨対策を報告します。Tomcat本体の更新と併せて、公開システムやWebアプリケーション全体のセキュリティ対策を見直したい場合は、BBSecにご相談ください。

お問い合わせページリンクボタン

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

IDCFクラウドへのランサムウェア攻撃がJR東日本グループにも影響 ―情報漏洩の調査結果と事業継続の課題

Share
IDCFクラウドへのランサムウェア攻撃がJR東日本グループにも影響アイキャッチ画像

クラウドへのサイバー攻撃は、サーバーの停止にとどまらず、サービスを利用する企業の顧客対応や情報管理にも影響します。2026年10月9日、JR東日本とビューカードは、IDCフロンティアへの不正アクセスに伴うメール配信への影響と、個人情報が漏洩した可能性を公表しました。その後、10月15日には、両社とも個人情報の漏洩はなかったと判断した旨の報告を受けたと発表しています。一方、クラウド基盤の障害は多くの利用企業に影響し、バックアップや復旧体制の重要性を浮き彫りにしました。本記事では、各社の公表資料をもとに、クラウド利用企業が点検したい情報保護と事業継続の課題を整理します。

※本記事は2026年10月19日時点で公表されている情報をもとに作成しています。

IDCFクラウドの障害と 利用企業への影響

IDCフロンティアは10月8日の第3報で、10月7日未明から発生した障害の原因を、第三者によるランサムウェア攻撃と説明しました。対象はIDCFクラウド東日本リージョン1の一部で、仮想サーバーの停止や再起動できない事象が発生し、利用する495の企業・自治体に影響したとしています。同社は対象環境の顧客データについて取り出しや復元が困難との見通しを示していました。しかし、10月14日の第5報では、スナップショット機能を利用していた194顧客について、バックアップデータの取り出しが可能であることを確認したと発表しました。対象となる495の企業・自治体のうち、これらの顧客には復元の可否やデータの提供方法について個別に連絡しています。

また、第5報では、障害の影響を受けた仮想サーバー内のデータについて、外部への持ち出しを示す痕跡などは確認されず、データ流出はなかったと判断したことを公表しました。一方、IDCFクラウドポータルでは48社の登録情報に対する不正な照会が確認されています。ただし、これらの情報が外部へ持ち出された痕跡は確認されていません。

10月9日の第4報では、親会社のソフトバンクと連携した対応体制を公表しています。さらに、10月18日の第6報では、安全性を確認した「IDCFクラウド バックアップ」の提供再開を発表しました。なお、スナップショット機能は引き続き提供を停止しています。IDCFクラウド TypeSとIDCFプライベートクラウドは、本事象の対象外とされています。

えきねっと・大人の休日倶楽部・VIEW’s NETへの影響と調査結果

JR東日本は10月9日、えきねっと会員約167万件、大人の休日倶楽部会員約39万件を対象に、個人情報が漏洩した可能性を公表しました。メール配信用外部サービスが一部利用できなくなり、メールアドレスを含む電子メールログデータなどが閲覧・取得された可能性を否定できないとしていました。対象情報は、えきねっとではメールアドレス、大人の休日倶楽部ではメールアドレス、会員番号、クレジットカード有効期限、生年月日です。ただし、10月15日には、メール配信用外部サービス会社から、これらの個人情報の漏洩はなかったと判断した旨の報告を受けたと発表しています。

またビューカードも10月9日、VIEW’s NET登録者向けメール配信への影響と、約403万件のメールアドレスが漏洩した可能性を公表しました。その後、10月15日には、メールアドレスの漏洩はなかったと判断した旨の報告を受けたと発表しています。

図：JR東日本・ビューカードが当初公表した漏洩可能性の対象件数

えきねっと約167万件、大人の休日倶楽部約39万件、VIEW’s NET約403万件の対象情報の違い。単純合計は延べ約609万件でいずれも漏えい可能性。
出典：JR東日本・ビューカードの2026年10月9日および10月15日の公表資料をもとに弊社作成
※件数は2026年10月9日時点で漏洩の可能性があると公表された情報の単純合計であり、実際の漏洩件数や重複を除いた人数ではありません。
※2026年10月15日、JR東日本およびビューカードは、個人情報の漏洩はなかったと判断した旨の報告を受けたと発表しています。

メールログも 保護すべき顧客情報として扱う

今回、JR東日本は当初、電子メールログデータなどが閲覧・取得された可能性を公表しました。その後、個人情報の漏洩はなかったと判断した旨の報告を受けたと発表していますが、顧客情報の保護を考えるうえでは、会員データベースだけでなく、メール配信に利用する外部サービスやログも確認対象となります。NCSCのクラウドセキュリティ原則でも、認証情報や設定情報に加え、ログや派生するメタデータを保護する重要性が示されています。

自社で見直す際には、どのログに個人情報が入るのか、誰が閲覧できるのか、どの目的でどれだけ保存するのかを整理します。業務記録として残す情報と、事故調査のために必要な監査記録を把握し、漫然と蓄積しない運用へつなげることが実務上のポイントです。同時に、調査に必要な記録まで消してよいわけではありません。NCSCは、監査情報の入手方法や保存期間を確認し、改ざん・削除から保護することを求めています。ログは情報資産であり、事故を調べる証拠でもあるため、保存と保護の両方を設計する必要があります。

バックアップは 使えない状況を想定して確かめる

IDCフロンティアは当初、対象環境の顧客データの取り出しや復元は困難との見通しを示していましたが、10月14日の第5報では、一部顧客のバックアップデータを取り出せることが確認されました。さらに、10月18日には「IDCFクラウド バックアップ」の提供再開が公表されています。この経過は、バックアップの有無だけでなく、障害発生時に実際に利用できるかを確認する重要性を示しています。自社の備えを点検する際は、元の環境が停止した状態でもバックアップを取り出し、復元できるかを確かめる必要があります。

NCSCのSaaS利用ガイダンスでは、重要データの保護されたバックアップを持つことに加え、元のデータを襲った事故が全バックアップにも及ばない構成を求めています。自社のクラウド運用へ応用するなら、保管先の分離だけでなく、バックアップを操作できる権限や認証への依存も点検対象です。復旧の手順には、別環境を誰が準備するか、どの時点のデータへ戻すか、業務再開を誰が承認するかまで含めます。実際に取り出して復元し、業務が動くところまで確認して初めて、計画の不足が見えてきます。サイバー攻撃では原因調査や封じ込めと復旧を調整する必要があるため、通常の機器故障と同じ手順でよいかも見直したい点です。

配信停止時の顧客対応と 漏洩調査を並行する

メール配信ができない場合、案内する内容だけでなく、伝える手段の確保が課題になります。企業の対応計画では、顧客向けメールの停止と情報漏洩の疑いが同時に起きる場面を想定し、公式サイトなどの代替窓口と、問い合わせを受ける担当を定めておきます。

利用者への案内では、確定した情報と調査中の事項を区別することが重要です。今回、JR東日本とビューカードは当初、個人情報の漏洩の可能性を公表しましたが、その後の調査結果を受けて、漏洩はなかったと判断した旨を追加公表しています。このように、調査の進展によって公表内容が変わる場合もあるため、利用者に最新の状況を正確に伝える体制が必要です。また、対象者への通知では、正規の案内かどうかを確認できる方法を示すことも大切です。クラウド事業者の復旧報告を待つだけでなく、自社の顧客対応をどの条件で進めるか決めておく必要があります。

BBSecのIT-BCP策定支援で 復旧できる計画へ

クラウド利用を前提にした事業継続計画では、利用環境の停止、データの復元、顧客への連絡を一緒に検討します。ブロードバンドセキュリティ（BBSec）の「ランサムウェアに対応したIT-BCP策定支援」は、サイバー攻撃を想定したIT-BCPの策定・見直しを支援するサービスです。現状のシステム分析を踏まえた計画策定支援や、企業主体の取り組みにコンサルタントが伴走するメニューを提供しています。また、復旧段階を中心とした「IT-BCP発動演習ワークショップ」もあります。[8] 自社の計画にクラウド停止を織り込めているか、バックアップからどの手順で業務を戻すかを具体化したい場合は、BBSecへご相談ください。平時の計画と演習を通じて、判断や作業が止まる箇所を明らかにしておくことが、事業継続への備えになります。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

Commune不正アクセスで約30.7万人の情報漏洩 ―利用企業が見直すべきSaaS管理

Share
Commune不正アクセスで約30.7万人の情報漏洩アイキャッチ画像

顧客や会員との交流を支えるコミュニティサービスで、個人情報の漏洩が発生しました。コミュニティサービス「Commune」「Commune for Work」を提供するコミューン株式会社は2026年10月9日、両サービスへの不正アクセスにより、推計約30.7万人の会員情報が漏洩したと公表しています*5。利用企業からも影響が公表されていますが、対象情報や漏洩の確認状況は各社で異なります。本記事では公表情報をもとに、事件の概要と、企業がSaaSを使う際に見直したい管理のポイントを整理します。

Communeで何が起きたのか

コミューンの発表では、非公開コミュニティの招待リンクが不正に取得され、一般会員としての登録が行われたほか、管理者へのなりすましによって会員情報の閲覧・取得やデータの上書きが行われました。今回の事案では、コミュニティへの参加方法と管理者権限の両方が確認すべきポイントとなります。約30.7万人は、コミューンの従業員・テスト用デモアカウントも含む推計です。また利用企業の設定や運用が原因ではないと説明しています。個々の利用者への影響は、参加するコミュニティと登録情報によって異なります。

なお同社は、10月13日、10月9日の公表以降に新たな不正アクセスや情報漏洩は確認されていないものの、引き続き調査と対応を進めていると発表しています。悪用された脆弱性の種類や認証の仕組みについて、詳細は明らかにされていません。

LINEヤフーとSansanで異なる情報漏洩の確認状況

LINEヤフーは、「DS.INSIGHT」内のコミュニティ機能「DS.LAB」の利用者1,750人について、情報が閲覧・取得された可能性を公表しました*2。対象には氏名、メールアドレス、自己紹介、所属グループなどが含まれます。同社のシステムへの不正アクセスは確認されておらず、コミューンが運営するサーバーで起きた事案と説明しています。

Sansanは「Sansan User Forum」について、漏洩を確認した1,325人と、漏洩の可能性がある8,687人を分けて公表しました*3。前者の対象情報にはメールアドレス、アカウント名、自己紹介、プロフィール画像、グループ所属情報が含まれ、後者はメールアドレスを除くこれらの情報が対象です。また、営業AXサービス「Sansan」など、同社の各サービスやそこで預かる情報への影響はないと説明しています。

今回の事案では、利用企業ごとに対象情報や漏洩の確認状況が異なります。情報漏洩の影響を判断する際には、対象となったサービスや情報の種類、漏洩が確認されているかどうかを区別することが重要です。

図：Commune事案の影響をサービスごとに確認

Commune全体の推計約30.7万人と、DS.LABの1,750人の漏えい可能性、Sansan User Forumの1,325人の漏えい確認および8,687人の漏えい可能性を区別した図
出典： コミューン株式会社、LINEヤフー株式会社、Sansan株式会社の2026年10月9日公表資料、およびコミューン株式会社の2026年10月13日公表資料をもとに弊社作成
※各社の対象人数は全体推計に加算していません。対象情報・漏洩の確認状況は各社の公表内容に基づきます。コミューンは10月13日、10月9日の公表以降、新たな不正アクセスや情報漏洩は確認されていないと発表しています。

SaaSの権限管理ではアクセスと操作の範囲を分けて考える

ここからは、今回の事案を踏まえて見直したい一般的なSaaSセキュリティ対策です。英国国家サイバーセキュリティセンター（NCSC）は、クラウドの安全性を評価する観点として、顧客間の分離、安全な利用者管理、認証、管理機能の保護を挙げています。ログインができることと、会員情報の一括取得や権限変更が許されることは、別々に制御しなければなりません。利用企業は、管理者を必要な担当者に限定し、退職や担当変更に応じてアクセス権を見直します。提供事業者に対しては、一般会員と管理者の境界や、顧客ごとのデータの境界を、どのように検証しているか確認することが重要です。

なお、今回の事案でテナント間の分離が破られたと確認されたわけではありません。多要素認証も有効な基本対策ですが、認証を強めればあらゆる権限の問題が解決するわけではありません。NCSCのSaaS利用ガイダンスを参考に、認証と権限設定をあわせて確認し、不要な機能や不要になった利用者のアクセスを残さない運用を整えましょう。

SaaSで扱う情報と事故調査に必要なログを把握する

SaaSを導入した部署が、登録項目や連携先を追加することもあります。契約時の評価だけで終えず、現在どの情報を扱っているのかを確認することが出発点です。会員登録の必須項目だけでなく、自由記述の自己紹介、追加プロフィール、画像に何が含まれ得るかまで運営担当者と整理します。事故への備えでは、監査ログを「保存しているか」だけで判断できません。NCSCは、利用企業が調査に必要な監査情報を入手できること、その提供方法や保存期間を把握していること、記録が改ざん・削除から保護されることを重視しています。会員情報へのアクセスや設定変更の履歴を、誰がどの手順で取り出せるのか、導入時から確認しておく必要があります。

連絡の受け手も決めておきたいところです。通知が契約担当者だけに届いても、運営の停止や会員への案内を判断する部署へ伝わらなければ対応が遅れます。SaaS事業者からの通知を、情報システム部門と実際の運営部門の双方が受け取り、対象者と対象情報の確定状況を同じ記録で追えるようにします。NCSCも、サービス全体の障害を含めた対応手順と、有効な連絡先の準備を求めています。

利用者には確認済みの情報を正確に伝える

利用者には、自分が参加するコミュニティの運営企業の公式発表を確認してもらうことが基本です。LINEヤフーは、本件に便乗する不審なメールやメッセージへの注意を呼びかけ、心当たりのないリンクを開いたり個人情報を入力したりしないよう案内しています。お詫びメールを装う連絡も想定し、正規の問い合わせ先と確認方法を明示すると、利用者が判断しやすくなります。一方で、漏洩項目に含まれない情報まで「流出した」と知らせるべきではありません。今回のSansanの発表でも、パスワードは対象外と明記されています。調査中の事項は調査中と伝え、対象範囲が変わった場合に更新する運用が必要です。

クラウド利用の管理体制を BBSecと見直す

SaaSの安全な利用には、技術的な設定と、委託先との役割分担・社内規程を結び付ける作業が欠かせません。ブロードバンドセキュリティ（BBSec）が提供している「ISO/IEC 27017 クラウドセキュリティ認証取得支援」は、クラウドの提供事業者と利用事業者を対象とし、現状のアセスメント、規格とのギャップ把握、規程文書の整備、社員教育を支援します。クラウドサービスの管理状況を把握し、権限管理や事故対応のルールを含めた管理体制の整備を検討される際は、BBSecへご相談ください。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

skyticketで約1,464万件の情報流出 ―3つの不正アクセス経路から考えるWebサービスのセキュリティ対策

Share
skyticketで約1,464万件の情報流出アイキャッチ画像

旅行比較予約サイト「skyticket」を運営するアドベンチャーは2026年10月9日、顧客情報の流出に関する3件の不正アクセスを公表しました。さらに10月16日には、第2報として一部利用者のクレジットカード情報等の流出を発表しています。 発生した場所も、対象情報も一様ではありません。企業の対策に生かすには、個々の事案を分けて理解し、管理機能と利用者向け機能の双方で、アクセス制御が適切かを確認する必要があります。

※本記事は2026年10月16日時点までで確認できる公表資料に基づき作成しています。

約1,464万件の情報流出と3つの不正アクセス事案

10月16日の第2報では、サーバーへの不正アクセスにより、最大6,140名分のクレジットカード情報等が流出したことも判明しました。公式発表が整理した3つの経路と対象件数は下図の通りです。

図：skyticketの3つの不正アクセス経路と情報流出の概要

skyticketの3つの不正アクセス経路と情報流出の概要
出典：株式会社アドベンチャーの2026年10月9日および10月16日公表資料をもとに弊社作成
※約413万件は約1,464万件の内数です。第2報で判明したクレジットカード情報（最大6,140名分）はサーバー事案に関する追加情報です。3事案では件数の単位や調査状況が異なるため、合計を被害人数として扱うことはできません。

自社への教訓を考える際も、これらを一つの原因で説明しないことが重要です。管理機能からアクセスできる範囲と、利用者へ個人情報を返す機能のアクセス制御は、それぞれの担当者と仕様を確認する必要があります。

利用者が確認したい流出情報と注意点

同社は10月9日の発表でクレジットカード番号の流出を否定していましたが、10月16日の第2報で内容を訂正しました。2017年2月から2018年6月までに「skyticketプレミアム」の会費支払いに利用されたクレジットカード情報が、最大6,140名分流出したことが判明しています。対象にはカード番号、名義人名、有効期限が含まれますが、セキュリティコードは含まれていません。また、会員特典である「ベネフィット・ステーション」の会員ID、氏名、パスワードの流出も確認されています。同社は対象者にクレジットカードの利用明細の確認を求めるとともに、会員には公式サイト・アプリでのパスワード変更と、同じパスワードを使う他サービスでの変更を呼びかけています。

企業側の通知でも、どの情報が対象で、利用者に何をしてほしいのかを結び付けて伝える必要があります。氏名や連絡先、予約内容が対象であれば、単に「不審なメールに注意」とするだけでなく、問い合わせ先と確認方法を案内する方が、利用者は行動に移しやすくなります。

ハッシュ化されたパスワードも 流出後の対応が必要

パスワードのハッシュ化は、入力された文字列を一定の処理でハッシュ値に変換して保存し、元のパスワードをそのまま持たないための仕組みです。ただし、ハッシュ値が外部へ出た場合に、パスワードが絶対に判明しないことを意味するわけではありません。攻撃者がパスワードの候補からハッシュ値を計算して照合する攻撃に対し、解析を困難にする仕組みが重要です。

OWASPは、パスワード保存に適した方式や処理コストの設定、利用者ごとに異なるソルトの使用などを説明しています。ソルトとは、同じパスワードでも同じハッシュ値になりにくくするために加える値です。本件の発表では方式や具体的な設定までは示されていないため、解析の容易さを断定することはできません。企業が保管方法を点検する際は、「ハッシュ化しているか」という確認だけで終えないことが大切です。方式、設定値、ソルトの扱いを確認し、漏えい時に利用者へ変更を求める手順まで整えておきます。パスワードの安全な保存方法と、流出時の対応手順を併せて整備することが重要です。

認証と認可を分けて 予約情報へのアクセスを確認する

今回のバス予約ページの問題から、Webサービスの担当者が再確認したいのが認証と認可の違いです。認証は「誰であるか」を確認する処理、認可は「その情報や操作を許可してよいか」を判断する処理です。ログインできた利用者であっても、他人の予約情報を閲覧できていいわけではありません。

OWASPは、必要最小限の権限、原則としてアクセスを拒否する設計、リクエストごとの権限確認を推奨しています。URLが推測しにくいことや、画面にリンクが表示されないことだけを、アクセス制御の代わりにはできません。利用者と対象データの関係を、サーバー側で判断する設計が必要です。自社サービスの点検では、予約完了画面、マイページ、明細のダウンロード、APIなど、個人情報を返す機能を対象にします。未ログインの状態だけでなく、別の利用者として操作した場合や、権限を変更した後の状態も確認します。これは本件でAPIや別利用者の権限に問題があったと断定するものではなく、認可の確認を自社へ広げるための観点です。

管理機能の先にあるデータも 守る範囲に含める

今回の発表は、管理機能に使われた製品や具体的な操作方法を明らかにしていません。公表されていない製品や攻撃手法を、原因として推測することは適切ではありません。[1]企業側は、自社の管理機能からアクセスできるデータを確認するとよいでしょう。業務担当者に必要な操作、アプリケーションが必要とする接続権限、運用保守のための権限を区別し、それぞれが目的を超えて広がっていないかを点検します。必要最小限の権限は、画面の利用者にも、バックエンドの接続にも適用すべき考え方です。

第2報では、2018年7月にクレジットカード情報を自社サーバーで保管しない方式へ移行した際、会費支払いに関する記録（ログ）が削除されずに残っていたことが明らかになりました。このログは今回の不正アクセスで取得され、暗号化されたカード情報とともに、暗号化に用いる情報も不正に取得されていたため、情報が読み取られるおそれがあるとされています。この事案は、システム変更時に不要となったデータの削除状況や、ログに含まれる機密情報の管理を確認する重要性も示しています。

弊社が2026年10月8日に公表した提言でも、公開Webサービスの脆弱性修正、設定の適正化、認証・権限管理の徹底に加え、対策の実効性を継続的に確認することの重要性を指摘しています。新機能のリリース前だけでなく、運用中の変更がアクセス範囲を広げていないかを確かめることが重要です。

ブロードバンドセキュリティ（BBSec）「国内で相次ぐ不正アクセスを受け、
BBSecが公開Webサービスの基本対策の再点検を提言」（2026年10月8日）（https://www.bbsec.co.jp/news/20261008.html）

Webアプリケーション・APIの脆弱性を診断で確認

自社でログインできることは確認していても、許可されない操作が拒否されることまで十分に検証できているでしょうか。BBSecの「Webアプリケーション脆弱性診断」は、外部から動的に検証し、攻撃の入口になり得る問題の検出を支援します。開発時の確認に加えて、運用中のシステムにも定期的に活用できます。診断を検討する際は、顧客向けの画面だけでなく、業務管理機能、個人情報を返すAPI、利用者の役割ごとのアクセス範囲を伝えることが大切です。どの機能と権限の組み合わせを検証するかは、個別の対象や業務要件に合わせて調整します。さらに設計段階から見直したい場合には、要件定義・設計のレビューや開発標準の整備を支援する「Shift Leftコンサルティング」もご活用いただけます。

個人情報の収集・管理・提供に関わる各機能を横断的に確認することが、セキュリティ対策の抜け漏れを防ぐ第一歩です。自社のWebサービスでどこまで点検できているかを整理し、重要な情報を扱う範囲から具体的な検証につなげていきましょう。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

国内で相次ぐ情報漏洩・不正アクセス｜焼肉きんぐなど14事例とAI時代の対策

Share
【続】国内で相次ぐ情報漏洩・不正アクセスアイキャッチ画像

国内企業や公的機関で、情報漏洩や不正アクセスに関する公表が相次いでいます。「なぜこれほど被害が続くのか」「生成AIが攻撃に使われているのか」と疑問に感じる方もいるでしょう。ただし、公表の集中が攻撃件数の増加を意味するとは限らず、今回の国内事例でもAIの関与は確認されていません。本記事では、直近1か月に公表・続報があった国内14事例を紹介するとともに、海外で報告されたAI悪用の動向を踏まえ、企業が見直すべきセキュリティ対策を解説します。

※本記事は2026年10月7日時点までで確認できる公表資料に基づき作成しています。

図1：国内で公表された情報漏洩・不正アクセス14事例（2026年9月～10月）

国内で公表された情報漏洩・不正アクセス14事例アイキャッチ画像
出典：各社・各機関の公表資料を基に弊社作成
※日付は公表・掲載日です。漏洩の確認状況や数値の単位・対象は事例によって異なり、単純比較・合算はできません。i-ask関連の3社は1項目に集約しています。

会員アプリ・ECサイトへの不正アクセス

焼肉きんぐ｜会員情報約1,079万件が漏洩

物語コーポレーションは10月5日、焼肉きんぐ公式アプリの会員管理システムへの不正アクセスを公表しました。10月2日に不正アクセスを確認し、翌3日に会員情報の漏洩が判明しています。漏洩したのは10,788,963件で、会員番号、氏名として登録された名称、メールアドレス、電話番号が含まれます。一方、ログインパスワード、生年月日、店舗利用履歴などは漏洩しておらず、決済情報は同社が保持していないと説明しています。流出した情報と含まれない情報を区別し、不審な連絡に備えることが重要です。

ミスターマックス｜最大約173万人に情報流出の可能性

ミスターマックスは10月6日、MrMaxアプリとオンラインストアのサーバーへの不正アクセスにより、会員情報の一部が流出したと発表しました。流出の可能性がある対象は最大1,735,154人で、会員ID、氏名、メールアドレス、電話番号が挙げられています。最大人数全員の流出が確認されたわけではありません。同社は、ソフトウェアの機能を不正利用した侵入と説明しています。住所、生年月日、クレジットカード情報、パスワード、購入履歴は流出していないとしています。具体的な脆弱性や他社との攻撃手法の共通性は、公表内容からは断定できません。

GMOリサーチ＆AI「infoQ」｜情報漏洩とポイント不正交換

GMOリサーチ＆AIは10月5日、アンケートサイト「infoQ」への不正アクセスにより、会員の個人情報が外部に持ち出されたと発表しました。対象は最大948,498件で、氏名、住所、メールアドレス、暗号化されたパスワードなどが含まれます。侵入にはサイトで使用していたソフトウェアの脆弱性が悪用されました。また、611件、計2,869,500円分のポイントが本人の意思によらずAmazonギフトコードに交換され、同社は全額補填するとしています。個人情報の保護だけでなく、ポイント交換など価値の移転を伴う処理の監視も重要です。

ホワイトエッセンス｜約105万アカウントの情報を持ち出し

ホワイトエッセンスは10月5日、予約サイトと基幹システムへの不正アクセスについて、個人情報の外部持ち出しを確認したと公表しました。対象は約105万アカウントで、顧客のほか加盟院関係者や本部社員なども含まれます。対象情報は氏名、住所、連絡先、勤務先、暗号化されたパスワード、サービス利用・対応に関する情報などで、登録内容によって異なります。不正アクセスを確認したのは8月5日で、8月12日にシステムの一時停止を公表していました。10月5日の発表は調査の続報にあたります。

アバハウス｜個人情報漏洩の可能性と不審な返金メール

アバハウスインターナショナルは10月3日、会員情報・EC受注情報への不正アクセスの痕跡と、個人情報漏えいの可能性を公表しました。調査のきっかけは、実際の注文情報と一致する不審な返金案内メールを受け取った顧客からの連絡です。対象顧客には10月2日に個別通知しています。取得された情報の範囲は完全には特定できていません。同社は取引記録を保存しているため、退会者にも通知しています。注文商品や金額が一致していても正規の連絡とは限らず、返金案内は公式サイトから確認することが重要です。

Gポイント｜会員識別子最大約7万件が漏洩した可能性

ジー・プランは9月30日、Gポイントのシステムへの不正アクセスを公表しました。9月25日に異常を検知してサービスを停止し、外部からのアクセスを遮断しています。漏えいの可能性がある情報は最大約7万件の「会員識別子」であり、氏名や住所などの流出が確認されたわけではありません。9月30日時点で原因と影響範囲を調査中としています。

ニッポンレンタカー｜異なる手法による2件の不正アクセスが判明

ニッポンレンタカーサービスは9月26日、アプリへの不正アクセスにより41人の会員情報が閲覧されたおそれがあると公表しました。10月1日には、調査中に異なる手法による別の不正アクセスが判明し、55人の情報が閲覧されたおそれがあると説明しています。対象情報は氏名、連絡先、利用履歴などで、登録状況によっては免許証番号、住所、生年月日、クレジットカード番号下4桁、名義人名も含まれます。2件の対象者の重複は確認できないため、単純に96人とは合算できません。

日本郵政・日本郵便｜郵便局アプリで19人分の情報を不正取得

日本郵政と日本郵便は9月29日、郵便局アプリへの不正アクセスにより、ゆうIDとアプリに関連する顧客情報69件・19人分が不正取得されたと公表しました。対象者によっては会員情報のほか、住所録や送り状の差出人・受取人情報も含まれます。9月26日には調査と対策を実施したうえでサービスを再開しています。利用者本人だけでなく、サービスを通じて預かる第三者の情報も保護対象となります。

委託先・クラウドへの不正アクセス

スカラコミュニケーションズ「i-ask」｜大和証券・シチズン時計にも影響

スカラコミュニケーションズは10月6日、FAQシステム「i-ask」への不正アクセスを公表しました。管理サイトへの不正ログインと不正プログラムの設置により、同一サーバーで稼働する最大5社の問い合わせ情報が取得された可能性があります。対象は最大713,126件ですが、問い合わせ単位の延べ件数であり、実人数ではありません。大和証券は10月5日、約11万人分の氏名、メールアドレス、口座番号など、シチズン時計は10月6日、約10万人分の氏名、住所、連絡先などに漏洩の可能性があると公表しました。両社とも自社システムへの不正アクセスは確認されていません。シチズン時計では、問い合わせ内容に銀行口座情報やクレジットカード情報が記載されていた場合、それらも対象となる可能性があります。

図2：委託先のFAQシステム「i-ask」への不正アクセスと利用企業への影響

委託先のFAQシステム「i-ask」への不正アクセスと利用企業への影響アイキャッチ画像
出典：株式会社スカラコミュニケーションズ、大和証券株式会社、シチズン時計株式会社の公表資料をもとに弊社作成
※最大713,126件は問い合わせ情報の延べ件数であり、実人数ではありません。各社の対象人数との合算はできません。また、図は各社の自社システムへの侵入を示すものではありません。

IDCフロンティア｜クラウドサービスに障害

IDCフロンティアは10月7日、IDCFクラウドの一部システムへの不正アクセスにより、東日本第1リージョンでサービス障害が発生したと公表しました。同日時点で障害解消に向けた調査対応と、その他の領域の安全性確認を進めています。確認した公表資料からは、個人情報漏洩やランサムウェア被害が確定したとはいえません。情報の機密性だけでなく、サービスの可用性も重要な論点です。

GMOインターネット「ConoHa WING」｜426アカウントに影響

GMOインターネットは9月20日、「ConoHa WING」の一部顧客Webサーバー領域への不正アクセスと、不正プログラムの設置を公表しました。影響対象は426アカウントです。不正アクセスは9月3日に始まり、9月16日に検知、9月18日に原因・影響範囲の特定と不正プログラムの排除を完了したとしています。同社が別環境で管理する会員情報、契約情報、支払い情報の漏洩はないと説明しています。ただし、顧客がWebサーバー領域に保存したデータまで影響がなかったと判断することはできません。

ユニリタ｜社内文書管理システムから情報窃取

ユニリタは9月29日、特定の社内文書管理システムへの不正アクセスと情報窃取を確認したと公表しました。9月28日に情報を窃取したとするWeb上の公表を確認し、外部専門家と調査を進めています。事業上の機密事項や顧客情報を含む影響範囲は調査中で、公表時点ではシステム障害や業務上の支障は生じていないとしています。サービスが正常に稼働していても、情報の安全性が確保されているとは限りません。

公的機関への不正アクセス

日本原子力研究開発機構（JAEA）｜175人分の個人情報が漏洩

日本原子力研究開発機構（JAEA）は10月1日、クラウド基盤上の研究支援サイトへの不正アクセスによる情報漏洩を公表しました。不正にダウンロードされた2,419ファイルのうち、個人情報を含むものは367ファイル・175人分です。運転免許証やマイナンバーカードなどの画像、放射線業務の特殊健康診断結果、放射線業務従事者証明書が含まれ、6人分ではマイナンバーも確認されています。研究支援サイトは機構内の業務ネットワークから独立しており、他のシステムへの影響はないと説明しています。漏洩の影響は人数だけでなく、情報の内容からも評価する必要があります。

エネルギー・金属鉱物資源機構（JOGMEC）｜メールアドレス漏洩の可能性

エネルギー・金属鉱物資源機構（JOGMEC）は10月2日、不正アクセスによる個人情報漏えいの可能性を公表しました。9月9日に可能性が判明し、アクセス制限や通信制御などを実施しています。対象は役職員のメールアドレス約1,100件と、機構外のメールアドレス約7,400件です。公表時点で不特定多数への公開や不正利用は確認されていません。

相次ぐ情報漏洩をどう読み解くか

公表日と発生日の違い

情報漏洩の公表が相次ぐ理由と、攻撃が成立した原因は分けて考える必要があります。ホワイトエッセンスでは8月の不正アクセスについて10月に続報が出され、ConoHa WINGでも攻撃開始日、検知日、公表日は異なります。今回の14項目は国内被害の全件統計ではなく、同一原因による攻撃を集計したものでもありません。公表の集中だけから攻撃件数の増加やAIの影響を判断することはできません。

脆弱性と管理者アカウントのリスク

infoQではソフトウェアの脆弱性悪用、i-askでは管理サイトへの不正ログインと不正プログラムの設置が確認されています。侵入を防ぐには、脆弱性への対応と管理者アカウントの保護をそれぞれ点検する必要があります。ただし、原因が公表されていない事例まで同じ弱点に分類することはできません。企業は公開WebサイトやAPI、管理画面を把握し、修正プログラムの適用状況、管理者権限、多要素認証、接続制限などを確認することが重要です。開発時だけでなく、システムや委託先の変更時にも点検できる運用が求められます。

委託先と保存データの管理

i-askの事例では、一つの委託先への侵害が複数の利用企業に影響する可能性が示されました。シチズン時計は別システムへの移行中で、旧システムを継続対応のために限定利用していたと説明しています。また、アバハウスでは退会者の取引記録も調査対象となりました。企業には、現行システムだけでなく、移行中・停止予定の環境や保存済みデータまで含めた管理が必要です。委託先との間では、データの保存場所、削除条件、異常時の連絡方法、調査用ログの確認範囲を把握し、業務や法令上必要な保存との整合も図る必要があります。

AIの悪用とサイバー攻撃の変化

AIによる攻撃工程の効率化

英国国家サイバーセキュリティセンター（NCSC）は2025年5月7日の評価で、AIが標的調査、脆弱性調査、ソーシャルエンジニアリング、窃取データの処理など、既存の攻撃工程を効率化すると指摘しました。また、2027年に向けて既知の脆弱性を狙う攻撃が増え、脆弱性の公表から悪用までの時間もさらに短くなると予測しています。これは将来の脅威評価であり、今回の国内事例の発生原因や被害件数の増減を示すものではありません。

Anthropicが報告したAIエージェントの悪用

Anthropicは2025年11月13日、同年9月に検知した活動について、Claude Codeを悪用して約30の標的への侵入を試み、少数で成功したと報告しました。同社によると、偵察や脆弱性調査、取得データの分析などにAIが利用されました。一方、人間による指示や重要局面での判断は残っており、AIが使用できない認証情報を生成するなどの誤りも報告されています。これはAI提供企業による観測報告であり、すべての攻撃工程が自動化されたことを意味するものではありません。

図3：AIによるサイバー攻撃の変化と国内事例で確認された事実

AIによるサイバー攻撃の変化と国内事例で確認された事実アイキャッチ画像
出典：英国国家サイバーセキュリティセンター（NCSC）、Anthropicおよび各社公表資料を基に弊社作成

国内事例と区別して考える対策

NCSCの評価とAnthropicの報告からは、AIによって攻撃者の調査・分析が効率化され、防御側が脆弱性の修正や異常への対応に使える時間が短くなる可能性が読み取れます。ただし、今回の国内事例にAIが関与したと判断する根拠にはなりません。企業に必要なのは、AIの利用有無にかかわらず、不審な挙動を早期に把握し、対応できる体制です。i-askではデータベースの監視アラート、infoQでは会員からの問い合わせが調査の契機となりました。機器のアラートと顧客からの連絡を、調査・判断を担う担当者につなぐ仕組みが重要です。

企業が見直したいセキュリティ対策

今回の事例では、Webサイトや会員管理システムへの侵入に加え、委託先やクラウド環境を通じた被害も確認されています。企業には、自社の公開システムだけでなく、外部サービスや保存データも含めた継続的な点検が求められます。BBSecは2026年10月8日、国内で相次ぐ不正アクセスを受け、企業が見直すべきセキュリティ対策についてプレスリリースを発表しました。侵入の入口を減らす対策、異常の早期発見、被害発生後の対応について紹介しています。

関連情報：国内で相次ぐ不正アクセスを受け、BBSecが公開Webサービスの基本対策の再点検を提言

まとめ

今回の国内14事例からは、会員アプリやWebサイトだけでなく、委託先や社内システム、保存済みデータまで含めた対策の重要性が見えてきます。AIの関与の有無にかかわらず、企業には脆弱性や設定不備の継続的な点検と、異常の早期発見から初動対応までを実行できる体制づくりが求められます。

BBSecのセキュリティ対策支援

BBSecでは、公開システムの脆弱性診断から、ログ分析・監視、インシデント発生時の対応まで、企業のセキュリティ対策を支援しています。

関連サービス

国内インシデントの関連記事

国内で発生した不正アクセスや情報漏洩について、過去の事例もご紹介しています。ぜひあわせてご覧ください。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

国内の個人情報漏洩・不正アクセス事例まとめ ―セイコーマート・OZmallなど12事例

Share
国内の個人情報漏洩・不正アクセス事例まとめアイキャッチ画像

セイコーマートはアプリ登録会員57万2,022人分の情報が不正に閲覧されたことを公表し、OZmallは個人情報が閲覧された可能性のある対象範囲を最大44万2,779名分に更新しました。吉野家・はなまるの旧委託先での個人情報漏洩や、ヤマト運輸の「クロネコ代金後払いサービス」での情報漏洩の可能性が公表されるなど、9月末から10月初めにかけて、身近な企業・サービスに関する発表が相次いでいます。本記事では、国内で公表・更新された12事例について、対象規模や公表時点での状況を整理します。

※本記事は2026年10月5日時点までで確認できる公表資料に基づき作成しています。

今回取り上げる12事例について、公表された対象規模と、公表時点での情報漏洩・不正閲覧等の状況を一覧にまとめました。詳細は各事例で紹介します。

図：国内の個人情報漏洩・不正アクセス事例

出典：各社の公式発表をもとに弊社作成（2026年10月2日時点）
※「確認」は情報の漏えい・不正閲覧・誤送付等が確認された事例、「可能性」は情報が閲覧・取得・漏えいした可能性がある事例です。対象規模は各社の公表単位に基づき、重複を含む場合があります。

OZmall（スターツ出版）｜最大44万2,779名の情報が閲覧された可能性

スターツ出版は10月1日、OZmall（オズモール）への不正アクセスに関する第2報を公表しました。個人情報が閲覧された可能性のある範囲は、会員と一部の退会者の最大44万2,779名分です。9月27日の初報で示した最大44万7,610名分から修正されています。対象はメールアドレスと、一部の方の氏名・住所（都道府県まで）です。9月26日に大量の不正アクセスを検知し、同社は原因を特定して脆弱性への対策と遮断を実施したと説明しています。脆弱性の詳細は公表していません。サービスは再開済みで、対象者には登録メールアドレスを通じて順次連絡しています。

らしんばん｜本人確認情報や銀行口座情報に漏洩の可能性

らしんばんは10月1日、9月14日から16日に受けた不正アクセスにより、顧客情報や配送先情報の一部が漏洩した可能性を公表しました。対象件数は未公表です。氏名や連絡先のほか、本人確認書類の種別・番号等、買取・注文の明細、買取申込時の銀行口座情報、買取にかかわる同意書画像などが含まれます。対象項目は利用状況によって異なります。同社はクレジットカード情報とパスワードの漏えいはないと説明しています。システム改修と不正アクセスの遮断を行い、警察への相談と個人情報保護委員会への報告を実施しました。影響を受けた可能性がある利用者への個別案内も進めています。

セイコーマート｜57万4,647人分の会員情報を不正閲覧

セイコーマートは10月5日の第四報で、アプリに登録したことがあるセイコーマートクラブ会員のうち57万4,647人分が、不正アクセスによる個人情報閲覧の対象になったと発表しました。9月30日の第三報で公表した57万2,022人分から対象人数が更新されています。9月24日までにセイコーマートクラブカードを退会した方は対象に含まれていません。同社は、すべてのアプリ会員に対し、個人情報閲覧の対象となったかどうかをアプリのお知らせで通知しています。また、アプリ・Web上での新規入会、会員情報の閲覧・変更、登録カードの変更機能を終了し、店舗またはフォームで受け付けたうえで同社が変更する運用としています。

ベネフィット・ワン｜1万3,460名の従業員情報が漏洩

ベネフィット・ワンは9月30日、企業・団体の担当者向け「ベネワン・プラットフォーム」のアンケート結果ダウンロード機能で、他企業・団体の従業員情報が表示される不具合を公表しました。対象は2,322企業・団体の1万3,460名で、氏名、社員・職員番号、生年月日、所属・役職などです。原因は2025年6月の改修に伴う条件設定の不備で、同年10月に認知していたものの解消作業が適切に行われていなかったと説明しています。2026年7月30日の利用企業からの連絡で本件が判明し、取得した担当者は1社1名でした。同社は第三者への提供がなく、連絡後にデータが削除されたことを確認しています。

VOISING｜約17万件の個人情報が漏洩

VOISINGは9月30日、8月に公表したBIツールへの不正アクセスについて、最終調査の完了を第四報で公表しました。漏えいが確認された対象は約17万件です。氏名・連絡先に加え、購買履歴や応援するタレントの選択情報などが含まれます。クレジットカード番号やログインパスワードに相当する情報は対象外です。同社は、BIツールの既知の脆弱性に対する修正の適用が、攻撃までに間に合わなかったと説明しています。侵害された環境を廃棄し、認証情報の失効・更新や権限の最小化を実施しました。今後は脆弱性対応の期限・責任者の明確化や監視の強化などに取り組む方針です。

吉野家・はなまる｜旧委託先から応募者情報が漏洩

吉野家ホールディングス、吉野家、はなまるは9月30日、旧委託先ApplyNowの採用管理プラットフォームへの不正アクセスによる個人情報漏えいを公表しました。応募者情報は吉野家4,998件、はなまる368件の計5,366件です。このほか採用担当者の情報418件も対象で、こちらは重複を含むアカウント数のため人数とは一致しません。発表によると、データ分析ツールの脆弱性が悪用されました。契約終了に伴い消去されると認識していた応募者情報が、旧委託先のデータベースに残っていたと説明しています。侵入経路の遮断と脆弱性の修正は完了しており、吉野家側のシステムへの不正アクセスは確認されていません。

損保ジャパン・TOPPAN｜17万7,426名の情報を誤送付

損保ジャパンとTOPPANは9月29日、保険料控除証明書発行サービスの委託業務で、契約者情報を別の損害保険会社1社へ誤送付したと公表しました。対象は17万7,426名ですが、同一契約者の重複を含む可能性があります。情報項目はカナ氏名、保険料控除用証券番号、業務IDです。9月1日、TOPPANの担当者がZIPファイルを操作した際に、損保ジャパンのデータを他社向けファイルへ混入させ、送付前の再確認も行っていなかったとしています。誤送付先での完全削除を確認し、発表時点で二次流出や不正利用は確認されていません。TOPPANは作業上の不備が原因で、サイバー攻撃によるものではないと説明しています。

イープラス｜払戻し情報1,463件が漏洩

イープラスは9月29日、電子チケット「スマチケ」の払戻し情報を管理するシステムへの不正アクセスで、1,463件の情報が漏えいしたと発表しました。不正アクセスは9月11日から12日にかけて発生しています。対象は2022年6月30日から2026年9月11日までに払戻しを申請した一部の利用者です。メールアドレスやカナ氏名、公演情報のほか、銀行振込751件には振込先口座情報、郵便振替払出証書68件には送付先住所などが含まれます。クレジットカード情報やパスワードは対象外です。同社は9月15日にアクセスを遮断し、9月29日から対象者への個別連絡を開始しました。具体的な侵入手法は公表されていません。

集英社｜ブロガー2,835名の情報が漏洩

集英社は9月28日、ファッション誌メディアで活動するブロガーの情報管理・連絡用システム「HAPPY PLUS COMMUNITY（ハピコミュ）」で、個人情報漏洩が発生したと公表しました。登録ブロガー2,835名の氏名や連絡先、プロフィール、SNSアカウントなどが対象です。登録内容によっては結婚状況や子の有無なども含まれ、項目は個人や媒体によって異なります。同社は、CMSの設定不備に起因するAPI認証情報への攻撃を受け、不正に作られた特権アカウントからAPIリクエストが繰り返されたことが、情報漏えいにつながったと考えています。不正アカウントの削除と設定変更を行い、9月25日に対象者へ通知しました。

手間いらず｜宿泊者情報が閲覧・取得された可能性

手間いらずは9月28日、宿泊予約管理サービス「TEMAIRAZUシリーズ」への不正アクセスを公表しました。9月21日深夜頃から、予約者に予約確認やカード情報の再入力、緊急支払いを求める不審なメッセージが届くとの連絡を受け、調査で不正アクセスを確認しています。宿泊者情報の一部が第三者に閲覧・取得された可能性を否定できず、件数や情報項目の詳細は未公表です。不審なメッセージとの関係も調査中としています。同社は原因への対策とアクセス制御・監視強化を実施し、停止機能を再開しました。予約者にはリンクを開かず、予約先などの公式窓口へ確認するよう案内しています。

東京メトロ｜約5万9,000件のメールアドレスが閲覧・取得された可能性

東京メトロは9月27日、メトロポイントクラブ「メトポ」の会員向けサービスが不正アクセスを受け、メールアドレス約5万9,000件が閲覧または取得された可能性があると公表しました。9月20日のメール配信サービスの不具合を調べる中、25日に通常と異なる利用記録を発見したとしています。対象は、送信不能のため配信を停止していたメールアドレスです。当該サーバーには、それ以外の会員情報は含まれていないと説明しています。防御措置は実施済みですが、影響範囲や原因の詳細は調査中です。対象者への案内で別途手続きや外部サイトへの移動を求めることはないとして、不審なメールへの注意を呼びかけています。

ヤマト運輸｜利用者情報が漏洩した可能性

ヤマト運輸は9月29日、「クロネコ代金後払いサービス」が第三者による不正アクセスを受けたことを公表しました。その後、10月2日の第2報で、情報の一部が漏洩した可能性があることを明らかにしています。漏洩した可能性があるのは、同サービスを利用した一部の顧客の氏名、住所、電話番号、メールアドレス、与信番号、請求金額、債権残高、商品明細のほか、一部の加盟店情報や担当社員の氏名です。クレジットカード情報やパスワード情報は含まれていません。対象範囲については引き続き調査中です。同社は9月28日に不正アクセスを確認し、外部からのアクセス制限などを実施したうえで、同日22時28分にサービスを停止しました。情報の漏洩が確認された利用者には個別に連絡するとしています。宅急便を含む他のサービスは通常どおり利用できます。

利用者が確認したいポイント

同じ「個人情報流出」という見出しでも、対象はメールアドレスだけの場合から、銀行口座、本人確認情報、購買履歴まで異なります。また、退会者や、過去の採用応募者が対象に含まれる事例もあります。利用中のサービスだけでなく、過去に登録・応募したサービスの公式発表や個別通知も確認してください。また、事故の通知を装った連絡への対応も大切です。手間いらずや東京メトロの案内では、不審なメッセージのリンクや外部サイトへの誘導に注意するよう呼びかけています。支払いや認証情報の入力を急がせる連絡を受けたときは、その本文から操作を進めず、公式サイトに掲載された窓口から確認してください。

企業が見直したい個人情報漏洩・不正アクセス対策

今回の事例では、外部からの不正アクセスだけでなく、脆弱性の悪用、システムの設定不備、委託先に残っていたデータ、ファイルの誤送付など、さまざまな要因で個人情報が影響を受けています。企業では、個別の対策だけでなく、システムの弱点を把握・改善し、異常を継続的に監視・検知し、インシデント発生時に適切に対応できる体制を整えておくことが重要です。

脆弱性を把握・改善する

Webサービスの技術的なリスクを確認するには、「Webアプリケーション脆弱性診断」があります。自動ツールとエンジニアによる手動診断を組み合わせ、認証やアクセス制御を含むWebアプリケーションの脆弱性を確認し、改善につなげます。

継続的に監視・検知する

脆弱性対策を行っても、サイバー攻撃を完全に防ぐことはできません。「G-MDR®」では、各種セキュリティ対策を統合的に監視・相関分析し、専門エンジニアが24時間365日体制で監視・運用します。脅威の検知から遮断・封じ込め、被害調査・対応支援まで、継続的なセキュリティ運用を支援します。

インシデントに備える

インシデント発生時に迅速に動くためには、平時から対応体制を整えておくことも重要です。「インシデント初動対応準備支援」では、既存の体制や文書を確認し、初動対応フローやガイドラインの策定を支援します。

ブロードバンドセキュリティ（BBSec）では、脆弱性の把握・改善から、継続的な監視・検知、インシデント発生への備えまで、企業のセキュリティ対策を支援しています。自社のシステムや運用体制に応じて必要な対策を検討したい場合は、お気軽にご相談ください。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

ニチレイへのサイバー攻撃で何が起きた？ RansomHouseの主張と情報漏えいの可能性・供給網への影響

Share
「ニチレイへのサイバー攻撃で何が起きた？RansomHouseの主張と情報漏えいの可能性・供給網への影響」アイキャッチ画像

2026年7月13日、ニチレイは不正アクセスによるシステム障害を公表しました。影響は冷蔵倉庫の入出庫や冷凍食品の出荷に及び、7月24日に全拠点が通常稼働へ移行しました。その後、RansomHouseを名乗るグループによる犯行声明や、20万件以上のファイル公開が報じられています。本記事では、その後に明らかになった情報を踏まえ、公式発表で確認できる事実と攻撃者側の主張、第三者の観測を分けて整理し、食品・物流サプライチェーンへの影響と企業に求められる備えを解説します。

ニチレイが公式に確認したのは、サーバーへのサイバー攻撃、システム障害に伴う入出庫・出荷業務への影響、被害サーバーの一部に個人情報が保管されていたことです。一方、RansomHouseの関与、ランサムウェアによる暗号化、公開ファイルの真正性、情報漏えいの対象人数と範囲、侵入経路は、2026年8月13日時点で公式に確定していません。

→【続報】2026年9月18日、ニチレイは第7報で個人情報の漏えいを確認し、対象区分と件数を公表しました。最新の公表内容はこちらの記事で解説しています。
「ニチレイが個人情報漏洩を確認 ―第7報で判明した被害と企業が備えるべきこと」

※本記事は2026年8月13日時点で確認できる公表資料に基づき作成しています。RansomHouseの主張と20万件報道は、公式発表と混同しないよう補足情報として区分しています。

7月31日時点の公式発表に基づく経緯や、業務再開までの対応、BCPの観点はこちらの記事で解説しています。
前回記事（速報版）　：「ニチレイへのサイバー攻撃で食品物流に影響―業務再開までの経緯と企業が見直すべきBCP」

ニチレイへのサイバー攻撃で何が起きたのか

今回のニチレイへのサイバー攻撃は、情報システムだけの障害ではありませんでした。冷蔵倉庫の入出庫や冷凍食品の出荷が止まり、モノの流れそのものに影響が及んだ点が特徴です。食品物流は、保管温度や納品時間が厳しく管理される業務です。受発注や在庫、倉庫作業を支えるシステムが使えなくなれば、倉庫に商品があっても通常どおりに動かせない状況が起こり得ます。

ニチレイは障害発生当日に緊急対策本部を設置し、個人情報や顧客データの保護を優先してグループ内システムを遮断しました。遮断は被害拡大を防ぐために重要な措置ですが、その判断によって業務への影響が表面化することもあります。サイバーインシデントでは、「止めないこと」と「安全を確認できない状態で動かさないこと」の間で、経営判断が求められます。

ニチレイのサイバー攻撃を時系列で整理

7月13日～24日：サイバー攻撃の確認から通常稼働への移行

ニチレイは7月13日、不正アクセスによるシステム障害が発生したと発表しました。7月15日には自社サーバーへのサイバー攻撃を確認し、被害サーバーの一部に個人情報が保管されていたことから、個人情報保護委員会へ漏えいの可能性がある事案として速報しています。その後、7月17日から一部制限のもとで業務を順次再開し、7月24日には受発注制限を解除。影響を受けた全拠点が平常時の通常稼働へ移行しました。

※発生から業務再開までの詳しい経緯は、前回の速報版で解説しています。

8月7日：業績への影響を公表

8月7日の2026年12月期第1四半期決算説明資料（決算期変更に伴う変則決算）で、ニチレイはシステム障害による売上面のマイナス影響を最大50億円、営業利益への影響を8億円と見込み、緊急対応で発生したコストや今後見込まれる損失として特別損失10億円を織り込みました。金額の意味が異なるため、これらを単純に合算して「被害総額」とみなすことはできません。

8月10日：「20万件以上」のファイル公開が報じられる

8月10日、テレビ朝日ANNニュースはS&Jの観測として、RansomHouseを名乗るグループが少なくとも20万件以上のファイルを公開し、個人情報も含まれているとみられると報じました*4。ニチレイは追加で情報が公開されていることを把握しているものの、コメントを差し控えると回答したとされています。なお、8月13日時点で、ニチレイの公式サイトには第5報以降、漏えい範囲や対象人数を確定する追加発表は掲載されていません。

ニチレイから個人情報は漏えいしたのか

結論からいえば、ニチレイは「個人情報の漏えいの可能性」を公表していますが、実際に社外へ流出した情報の項目や対象人数、件数は明らかにしていません。公式に確認できるのは、被害サーバーの一部に個人情報が保管されていたこと、個人情報保護委員会へ報告したこと、対象者へ通知したことまでです。この対象者への通知が行われたこと自体も、個人情報の社外流出が確定したことを意味するものではありません。

個人情報保護法では、不正アクセスなどによる個人データの漏えいが発生した場合だけでなく、発生したおそれがある場合にも、一定の要件のもとで個人情報保護委員会への報告と本人通知が必要になります*2。したがって、「個人情報保護委員会へ報告した」という事実だけで、漏えいが確定したとは判断できません。調査が進むにつれて公表内容が更新されることもあるため、初報だけで結論づけず、続報を追う必要があります。

「20万件以上」は20万人分の個人情報ではない

報道で使われた「20万件以上」は、文書や画像、フォルダー内のデータなどを含むファイル数です。1人に複数のファイルがひもづく場合もあれば、個人情報を含まない業務資料が数えられている可能性もあります。反対に、1つのファイルに複数人の情報が含まれる可能性もあります。そのため、ファイル数から被害人数を換算することはできません。さらに、公開されたとされるファイルのすべてがニチレイから窃取された真正なデータなのか、S&Jがどの範囲を確認したのかについて、ニチレイによる公式な検証結果は出ていません。

RansomHouseとは？ニチレイへの犯行は確認されたのか

RansomHouseは、被害組織からデータを窃取し、公開をちらつかせて金銭を要求する恐喝活動で知られるグループです。パロアルトネットワークスのUnit 42は、RansomHouseをRansomware as a Service（RaaS）として分析し、データ窃取と暗号化を組み合わせる二重脅迫、ESXi環境を狙う管理ツール「MrAgent」と暗号化ツール「Mario」の利用を報告しています*3。

ただし、これはRansomHouse一般の活動に関する技術分析です。ニチレイの環境でMrAgentやMarioが使われたこと、サーバーやファイルが暗号化されたことを示すものではありません。RansomHouseを名乗るグループは犯行を主張していますが、ニチレイは攻撃主体を公式に特定しておらず、侵入経路や攻撃手法も公表していません。

サイバー攻撃は食品・物流サプライチェーンへどう波及したか

ニチレイの事例で見落とせないのは、被害が自社のサーバー内にとどまらず、商品の保管と配送を待つ取引先や、その先の店舗運営へ波及し得ることです。食品物流は、多数の荷主、倉庫、輸配送会社、小売・外食企業をつなぐ共通基盤です。中核となる事業者の機能が止まれば、取引先自身のシステムが侵害されていなくても、商品を受け取れないという形で事業が止まります。

同時期、日本ケンタッキー・フライド・チキン株式会社（以降KFC）も、食材配送を委託する物流会社で発生した不正アクセス起因のシステム障害により、商品の一部品切れ、販売メニューの制限、営業時間の短縮などが生じたと公表しました*4。7月22日には全店舗への食材納品体制が整い、通常営業へ戻っています。KFCは物流委託先の社名を公表していないため、ニチレイの事案との関係を公式情報だけで断定することはできません。一方、この事例は、物流委託先のシステム障害が消費者向けサービスにまで波及し得る構造を示しています。

「サプライチェーン攻撃」と「サプライチェーンへの影響」は別物

ここで用語を分けて考える必要があります。サプライチェーン攻撃は一般に、取引先や委託先、利用するソフトウェアやサービスを足がかりとして標的へ侵入する攻撃を指します。今回、ニチレイへの侵入経路は公表されていないため、攻撃経路という意味でサプライチェーン攻撃だったとは断定できません。

一方で、サイバー攻撃による業務停止が供給網の先へ広がる「サプライチェーンリスク」は明確に表面化しました。侵入経路の問題と、事業依存関係による影響の連鎖は別の論点です。この二つを混同しないことが、ニュースを正確に読み、自社の対策へ落とし込む第一歩になります。

ニチレイが公表した業績への影響

ニチレイの2026年12月期第1四半期決算説明資料では、事業停止に伴う売上面のマイナス影響を最大50億円と見込んでいます。内訳は食品事業が20億円、低温物流事業が30億円です。営業利益への影響は8億円で、食品事業2億円、低温物流事業4億円、持株会社のシステム対応費用2億円とされています。さらに、緊急対応で発生したコストと今後発生が見込まれる損失として、10億円の特別損失を織り込みました。

※ニチレイが公表した売上への影響、営業利益への影響、特別損失は、それぞれ意味の異なる数字です。これらを単純に合算して「サイバー攻撃による被害総額」とみなすことはできません。

親会社株主に帰属する当期純利益の予想は252億円から204億円へ48億円下方修正されましたが、この48億円すべてがサイバー攻撃による損失ではありません。中東情勢によるコスト増や食品・物流事業の進捗など、複数の要因が含まれています。なお、連結売上高の通期予想自体は海外事業の伸長を反映して上方修正されています。

企業が学ぶべきサイバー攻撃対策

重要業務と外部依存を、システム単位ではなく事業単位で洗い出す

まず必要なのは、どのシステムが止まると、どの業務、取引先、商品、売上に影響するのかを平時に把握することです。自社システムの一覧だけでは足りません。物流、決済、クラウド、保守会社、受発注先など、重要業務を支える外部依存まで含め、許容停止時間と代替手段を整理します。委託先が止まった場合の連絡順序、手作業へ切り替えられる範囲、代替事業者の有無も、BCPとインシデント対応計画の両方で確認しておく必要があります。

また、インシデント対応訓練では自社がサイバー攻撃を受けるケースだけでなく、物流会社やクラウドサービス、主要な仕入先など、重要な委託先・取引先のシステムが停止するケースも想定することが重要です。自社システムが正常でも外部サービスが利用できない状況で、どこまで業務を継続できるのかを確認しておく必要があります。

「業務復旧」と「情報漏えい対応」を別の時計で管理する

ニチレイは7月24日に通常稼働へ移行しましたが、その後もダークウェブ上でのデータ公開が報じられました。ここから分かるのは、システム復旧の完了と、情報漏えい調査の完了は一致しないということです。前者は業務を安全に再開できるかという可用性の問題、後者は何が持ち出され、誰にどのような影響があるかという機密性と法令対応の問題です。復旧宣言後も、フォレンジック調査、漏えい範囲の特定、本人通知、二次被害の監視、対外説明を継続できる体制が欠かせません。

遮断・復旧・証拠保全を同時に進められる初動体制をつくる

攻撃を疑った場合は、インシデント対応責任者や専門家の判断のもと、必要に応じて感染が疑われる端末やサーバーをネットワークから隔離し、被害拡大を抑える必要があります。一方、電源断や安易な初期化によって調査に必要な証拠を失うおそれもあります。誰が遮断を判断し、どのログを保存し、外部の専門会社や警察、監督機関へいつ連絡するのかを事前に決め、机上訓練で確かめておくことが重要です。

経済産業省・独立行政法人情報処理推進機構（IPA）の「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集 第4版」でも、インシデント発生に備えた体制構築とサプライチェーン全体での対策を経営課題として位置づけています。

バックアップは取得だけでなく、隔離と復旧テストまで行う

ランサムウェアを含む破壊的な攻撃に備えるには、バックアップを本番環境と同じ認証基盤やネットワークに置き続けないことが重要です。実際に戻せるかを定期的に試し、復旧に必要な時間が事業側の許容範囲に収まるかまで確認して、初めてBCPとして機能します。

よくある質問

▼ ニチレイへの攻撃はランサムウェアだったのですか？
▼ 20万件とは20万人分の個人情報ですか？
▼ 個人情報の漏えいは確定していますか？
▼ ニチレイのシステムと業務は復旧していますか？
▼ 今回の事案はサプライチェーン攻撃ですか？

まとめ―復旧の速さだけでは測れないサイバー攻撃の損失

ニチレイへのサイバー攻撃は、冷蔵倉庫と冷凍食品出荷の停止、取引先への影響、個人情報漏えいの可能性、財務損失という複数の問題を同時に突きつけました。全拠点が通常稼働へ戻った後にデータ公開が報じられた経緯は、事業継続と情報保護を別々に備える必要性を示しています。

企業が見るべきなのは、自社への侵入を防げるかだけではありません。重要な委託先が止まったときに業務を続けられるか、攻撃を検知した直後に安全に遮断できるか、バックアップから所定時間内に戻せるか、漏えい調査と対外説明を長期にわたって続けられるかまでが、現在のサイバー攻撃対策です。平時のうちに外部専門会社との連絡経路や調査体制を整え、実際のシナリオで検証しておくことが、被害の大きさを左右します。漏えい調査と対外説明を長期にわたって続けられるかまでを想定することが、現在のサイバーリスク対策には求められます。

参考情報

公開日：2026年8月13日
更新日：2026年10月6日

編集責任：木下

BBSecの脆弱性診断・セキュリティ対策支援サービス

BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

ウェビナー開催のお知らせ

  • 2026年8月19日（水）14:00～15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―」
  • 2026年8月26日（水）「AI時代に見直すセキュリティ対策 ～ASMの考え方で始める攻撃対象領域の可視化とリスク対策～」

    • 最新情報はこちら

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    投稿日:

    ニチレイへのサイバー攻撃で食品物流に影響―業務再開までの経緯と企業が見直すべきBCP

    Share
    ニチレイへのサイバー攻撃で食品物流に影響アイキャッチ画像

    2026年7月、ニチレイがサイバー攻撃を受け、冷蔵倉庫の入出庫業務や冷凍食品の出荷業務に影響が生じました。同社は被害拡大を防ぐためグループのシステムを遮断し、一部制限のもとで業務を順次再開。7月24日には、影響を受けた業務が通常稼働へ移行しました。本事案は、サイバー攻撃が情報漏えいだけでなく、物流や取引先を含む事業継続にも影響を及ぼすことを示しています。本記事では、公式発表に基づいて対応の経緯を整理し、企業が見直すべきBCPについて解説します。

    ※本記事は2026年7月31日時点で確認できる公表資料に基づき作成しています。公表されていない製品名、CVE番号、攻撃者、侵入手法の詳細については推測を加えずに構成しています。

    【続報】2026年9月18日、ニチレイは個人情報の漏えいを確認したと発表しました。最新の公表内容はこちらの記事で解説しています。
    「ニチレイが個人情報漏洩を確認 ―第7報で判明した被害と企業が備えるべきこと」

    ニチレイへのサイバー攻撃とは

    2026年7月13日、株式会社ニチレイは不正アクセスによるシステム障害が発生したと公表しました*5。影響が出たのは、ニチレイロジグループ各社の冷蔵倉庫における入出庫業務と、ニチレイフーズの冷凍食品出荷業務です。同社は発生当日に緊急対策本部を立ち上げるとともに、お客さまや取引先の個人情報・顧客データなどの保護を最優先し、グループで使用するシステムの遮断措置を講じたことを、2日後の第2報*2で明らかにしています。その後、7月17日から一部制限のもとで業務を順次再開し、7月24日には、影響を受けた入出庫業務と冷凍食品出荷業務の受発注制限を解除して、全拠点を平常時の通常稼働へ移行しています。

    この事案が示したのは、サイバー攻撃の被害が情報漏えいだけにとどまらないことです。攻撃を受けた疑いが生じれば、被害拡大を防ぐためにシステムを止める判断が必要になる場合があります。受発注、在庫管理、倉庫の入出庫、出荷といった業務がITでつながる現在、封じ込め措置そのものが事業停止リスクを伴います。本件からは、侵入を防ぐ対策だけでなく、システムを遮断した後も業務を継続し、段階的に復旧する計画が欠かせないことが分かります。サイバーセキュリティ対策とBCPは、一体で検討すべき課題です。

    7月13日から24日まで―公式発表で追う対応と復旧

    7月13日：不正アクセスによるシステム障害を公表

    ニチレイは7月13日、不正アクセスによるシステム障害が同日に発生したと発表しました。第1報の時点では、個人情報や顧客データが社外へ流出した事実は確認されていないとしていました。一方、冷蔵倉庫の入出庫業務と冷凍食品の出荷業務にはすでに影響が生じており、障害の範囲は公表時点で日本国内に限られると説明しています。

    ここで注意したいのは、7月13日が「攻撃者の侵入日」と確認されたわけではない点です。公式発表から断定できるのは、不正アクセスによるシステム障害が7月13日に発生し、同日公表されたことまでです。攻撃者が最初に侵入した日時や、不正アクセスを検知した正確な時刻・契機は明らかにされていません。

    7月15日：サイバー攻撃を確認、個人情報漏えいの可能性を報告

    7月15日の第2報で、ニチレイは調査の結果、自社サーバがサイバー攻撃を受けたことを確認したと発表しました。さらなる被害拡大を防ぐため、攻撃の詳細は非開示としています。また、被害を受けたサーバの一部に個人情報が保管されていたため、個人情報保護委員会へ「漏えいの可能性がある事案」として第一報を行いました。

    同社は発生当日の7月13日にグループで使用するシステムを遮断しており、この遮断措置に伴って冷蔵倉庫の入出庫と冷凍食品出荷に影響が生じたと説明しています。なお、7月16日付のIR情報では、連結業績への影響は精査中とされ、重要な影響が判明した場合は速やかに開示すると説明しています。

    7月17日：受発注を制限しながら部分稼働

    7月17日、ニチレイは外部のセキュリティ専門会社の支援のもと、影響を受けた業務を順次再開しました。ただし、直ちに平常運転へ戻ったわけではなく、顧客や取引先からの受発注を一部制限し、冷蔵倉庫と食品工場を部分稼働させる形での再開でした。この段階でも、原因と影響範囲は調査中とされていました。

    7月22日から24日：対象者への通知と通常稼働への移行

    7月22日の第4報*3では、外部のセキュリティ専門会社に加え、警察および関係機関と連携して対応していることが公表されました。被害サーバの一部に個人情報が保管されていたため、対象者へ別途通知を行っていることも明らかにされています。

    7月24日、ニチレイは受発注制限を解除し、影響を受けていた入出庫業務と冷凍食品出荷業務について、全拠点が平常時の通常稼働へ移行したと発表しました。ただし、これは影響業務の通常稼働への移行を示すものであり、原因調査や影響範囲の特定まで完了したことを意味するものではありません。

    なぜ食品サプライチェーンへの影響が注目されたのか

    ニチレイが2026年5月12日に公開した「事業概要説明資料」によると、同社の低温物流事業は全国75カ所に冷蔵倉庫を保有し、冷蔵倉庫の保管能力で国内1位です。さらに、ニチレイグループ外の取扱比率が90％を超えるとされています。今回、75カ所すべてに同じ程度の支障が生じたと公表されているわけではありません。ただし、この事業構造から、低温物流業務の中断がニチレイグループ以外の荷主にも波及し得ることが分かります。

    実際、ミールキット宅配サービスのヨシケイは7月27日、ニチレイグループのシステム障害により倉庫からの商品出庫に支障が生じ、一部エリアで代替品や代替食材を届ける場合があると公表しました*4。ニチレイは7月24日に影響業務の通常稼働への移行を発表していますが、自社の業務が再開しても、取引先側では在庫調整や代替品の手配などが続く場合があります。ヨシケイの発表は、障害の影響が取引先の商品供給にまで波及したことを示す事例といえます。

    なお、サイバー攻撃の影響が取引先へ波及したことと、取引先などを侵入経路とする「サプライチェーン攻撃」は区別する必要があります。ニチレイは侵入経路を公表していないため、本件をサプライチェーン攻撃と分類することはできません。一方、業務停止の影響が取引関係を通じて広がるリスクは、物流や食品製造だけでなく、決済、医療、クラウドサービスなどにも共通します。

    個人情報は漏えいしたのか

    2026年7月31日時点で、ニチレイは個人情報の漏えいを確定したとは発表していません。公表されているのは、被害サーバの一部に個人情報が保管されていたこと、漏えいの可能性がある事案として個人情報保護委員会へ第一報を行ったこと、対象者へ別途通知したことです。

    個人情報保護委員会は、不正の目的をもって行われたおそれがある個人データの漏えい等について、実際の漏えいが確定した場合だけでなく、それがある段階も報告対象になると示しています*5。このため、個人情報保護委員会への報告が行われたことだけをもって、外部流出が確定したとは判断できません。

    対象人数、顧客・従業員などの属性、情報項目、持ち出しの有無、不正利用の有無も公表されていません。したがって、現段階で「顧客情報が流出した」「大規模な個人情報漏えいが起きた」と書くのは不正確です。新たな公式発表が出た場合は、漏えいの事実、対象範囲、二次被害の有無を分けて確認する必要があります。

    ※その後、9月18日の第7報で個人情報の漏えいが確認されました。最新情報はこちら。

    ランサムウェア攻撃だったのか

    ニチレイは、攻撃手法、侵入経路、悪用された脆弱性、マルウェアの種類、データ暗号化や身代金要求の有無、攻撃者について公表していません。このため、本件をランサムウェア攻撃、ゼロデイ攻撃、あるいは特定の攻撃グループによる犯行と断定できる公式情報はありません。

    攻撃者を名乗る第三者の主張が報じられた場合でも、それだけで攻撃手法や犯行主体が確定するわけではありません。本記事では、ニチレイまたは捜査機関が確認した情報と、外部からの未検証の主張を区別して扱います。

    ニチレイの事例から企業が見直すべきサイバー攻撃対策

    重要業務とシステムの依存関係を可視化する

    対策の出発点となるのは、止まると事業や顧客に大きな影響が出る業務を特定し、それを支えるシステム、データ、拠点、委託先を対応付けることです。受発注システムだけを復旧しても、在庫情報、倉庫作業、輸配送との連携が戻らなければ商品は届きません。業務影響分析（BIA）を用いて復旧の優先順位を整理し、目標復旧時間（RTO）や目標復旧時点（RPO）に加え、システム停止中も最低限維持すべき業務とその水準を、IT部門と現場部門で共有しておくことが有効です。

    多層防御によって被害範囲を限定する

    ニチレイは侵入経路や攻撃手法を公表していないため、本件の原因に特定の対策不足を結び付けることはできません。以下は、同種の業務停止に備えるための一般的な対策です。

    サイバー攻撃への備えでは、侵入を防ぐだけでなく、侵入された場合にも被害を広げない対策が必要です。重要システムやネットワークの分離、特権アカウントの適切な管理、多要素認証、ログの保全・監視などを組み合わせ、攻撃者による内部での移動や権限拡大を抑制します。

    経済産業省・独立行政法人情報処理推進機構（IPA）の「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集 第4版」も、侵入を防ぐ入口対策に加え、内部での活動拡大を防ぐネットワーク対策、外部への不正通信を防ぐ出口対策、重要データを守る対策を組み合わせる多層防御を示しています。

    「システムを止めた状態」で続ける手順を用意する

    不正アクセスの疑いがある状況では、ネットワークの遮断や機器の隔離、サービス停止が必要になることがあります。IPAの「中小企業のためのセキュリティインシデント対応の手引き」でも、被害拡大の可能性がある場合の初動対応として、ネットワーク遮断や対象機器の隔離、システム・サービスの停止を挙げています。

    だからこそ、BCPはバックアップからシステムを戻す手順だけでは不十分です。システムを遮断した際に利用する代替手順を、業務内容に応じて事前に設計しておく必要があります。例えば、受発注や入出庫を電話、メール、紙の帳票などへ一時的に切り替える場合も、処理可能な件数、誤処理を防ぐ照合方法、記録の保全、平常系へ戻す際のデータ反映まで検証しなければなりません。机上演習に加え、主要システムを利用できない状況を想定し、代替手順が実際に機能するか確認することが重要です。

    復旧可能なバックアップと復旧手順を検証する

    バックアップは、データを保存しているだけでは事業復旧を保証できません。本番環境と同時に暗号化・削除されないよう、ネットワークから分離した媒体や異なる環境にも保管し、バックアップデータの完全性を定期的に確認する必要があります。

    さらに、復元テストを実施し、重要なシステムやデータを想定した時間内に復旧できるかを検証します。復旧の順序、必要な担当者、利用する機器や認証情報、システム間の依存関係も事前に整理しておくことが重要です。

    サイバー攻撃を受けた環境を安全確認なしに復元すると、侵害された設定やマルウェアまで戻してしまうおそれがあります。原因調査や安全性の確認と並行して、どの時点のデータを、どの環境へ、どの順番で戻すかを判断できる復旧手順を整備しておく必要があります。

    初動対応をIT部門だけに背負わせない

    インシデント発生時には、封じ込め、証拠保全、原因調査、復旧に加え、顧客や取引先への連絡、個人情報保護委員会などへの報告、警察との連携、経営判断が並行して進みます。ニチレイも緊急対策本部を設置し、外部のセキュリティ専門会社、警察、関係機関と連携しました。

    平時から、経営、情報システム、事業部門、法務、広報、個人情報保護担当の役割と連絡順序を決め、フォレンジック調査や復旧を依頼する外部専門家の連絡先を整えておくべきです。対応手順は、社内システムが利用できない状況でも参照できる場所に保管します。また、調査に必要なログやデータを不用意に消去しないよう、対象機器の隔離方法や外部専門家へ連絡する判断基準を訓練しておくことが重要です。

    取引先を含めて復旧情報を共有する

    自社が通常稼働へ戻っても、取引先側では在庫不足、納品遅延、代替商品の手配、顧客への案内が続く可能性があります。サプライチェーン全体の復旧を早めるには、「何が止まっているか」「どの業務をいつ再開するか」「制限が残るか」を、攻撃者に利する情報を避けながら継続的に共有することが重要です。

    公表文のひな型だけでなく、重要取引先への連絡経路、問い合わせ窓口、更新頻度、技術情報と事業影響を分けて説明するルールまで準備しておくと、混乱を抑えやすくなります。セキュリティ部門が把握する復旧状況を、物流、営業、調達、顧客対応の言葉へ変換する役割も必要です。

    よくある質問

    ▼ ニチレイのシステム障害はいつ発生しましたか
    ▼ どの業務に影響が出ましたか
    ▼ 個人情報は漏えいしましたか
    ▼ ランサムウェア攻撃だったのでしょうか

    まとめ―サイバー攻撃対策は業務復旧まで設計する

    ニチレイへのサイバー攻撃では、冷蔵倉庫の入出庫と冷凍食品出荷に支障が生じ、制限付きの再開を経て通常運用へ戻りました。一方、2026年7月31日時点では、攻撃手法や侵入経路、個人情報の外部流出の有無、最終的な影響範囲は公表されていません。

    今回の事例から企業が学ぶべきなのは、侵入防止策だけではありません。被害拡大を防ぐためにシステムを遮断しても重要業務を続けられるか、安全性を確認しながらどの順番で復旧するか、取引先へ何を伝えるかまで含めて設計する必要があります。サイバー攻撃をIT障害として閉じず、経営と現場を巻き込んだサイバーBCPとして準備することが、事業とサプライチェーンの強靱性を左右します。

    【参考情報】

    公開日：2026年8月5日
    更新日：2026年10月6日

    編集責任：木下

    BBSecの脆弱性診断・セキュリティ対策支援サービス

    BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

    ウェビナー開催のお知らせ

  • 2026年8月19日（水）14:00～15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―」
  • 2026年8月26日（水）「AI時代に見直すセキュリティ対策 ～ASMの考え方で始める攻撃対象領域の可視化とリスク対策～」

    • 最新情報はこちら

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    投稿日:

    タイムズカーで約660万アカウントの情報漏洩 ―本人確認書類の保管とWebセキュリティを考える

    Share
    タイムズカーで約660万アカウントの情報漏洩アイキャッチ画像

    2026年9月、タイムズカーのWebシステムが不正アクセスを受け、約660万アカウントの情報漏洩が確認されました。続報では、運転免許証画像などの本人確認書類が漏洩したアカウント数が約160万件と公表されています。本記事では、公式発表をもとに被害の範囲と利用者への案内を整理し、会員情報を扱う企業が見直したいデータ管理とWebセキュリティについて考えます。

    ※本記事は2026年10月5日時点までで確認できる公表資料に基づき作成しています。

    2026年9月にタイムズカーで何が起きたのか

    タイムズカーは9月25日9時07分に不正アクセスを検知し、同日の第1報で個人情報漏洩の可能性を発表しました。翌26日7時25分までに侵入経路と攻撃元からの通信を遮断し、遮断後にアクセスできないことを確認したとしています。その後、28日の第2報で第三者による情報取得を確認したと公表し、調査の進展に伴って発表内容を更新しました。公式発表では、具体的な侵入手法や悪用された脆弱性の詳細は示されていません。同社は外部専門機関による原因・影響範囲の調査を進め、再発防止策は続報で公表する方針です。また、サービス提供への影響は確認されず、通常どおり継続していると説明しています。サービスの稼働状況と個人情報への影響は、それぞれ確認する必要があります。

    約660万件と約160万件、それぞれの対象範囲

    第2報の約660万件は、漏洩したアカウントの数です。対象にはタイムズカーの会員と退会者、入会手続きが完了していない申込者のほか、タイムズビジネスサービスの会員と退会者も含まれます。現在利用している会員だけの人数として受け取らないことが大切です。漏洩した情報の項目については、公式FAQでも詳細が示されています。氏名、住所、生年月日、電話番号、メールアドレスに加え、法人会員の所属部署名、運転免許情報、本人確認書類情報、パスワード、連携サービスIDが挙げられています。一方、クレジットカード情報は保有しておらず、今回の対象には含まれないと説明しています。

    9月29日の第3報で示された約160万件は、運転免許証画像などの本人確認書類が漏洩したアカウント数です。書類には現住所確認書類、学生プランの学生証、家族プランの家族確認書類の画像も含まれます。約660万件と約160万件は数えている情報の範囲が異なるため、単純に足して被害規模を示すことはできません。同社はパスワードを復元できない形式で保存していたと説明し、パスワードそのものが第三者に認識できる状態で漏えいした事実は確認していないとしています。不特定多数への情報公開や、本件に起因する不正利用も公表時点では未確認です。これらは同社が示した調査状況として読み、今後の更新も確認する必要があります。

    図：タイムズカーで確認された情報漏洩の範囲

    タイムズカーで確認された情報漏洩の範囲
    出典：タイムズモビリティ株式会社 第2報（2026年9月28日）・第3報（2026年9月29日）をもとに作成
    ※約160万件は約660万件に含まれます。いずれもアカウント数で、対象となる情報は利用者によって異なります。

    利用者は個別通知と公式窓口を確認する

    本人確認書類の漏えいが確認された会員への個別メールは9月29日から始まりました。第3報では、詳細について外部専門機関の調査結果を踏まえ、2週間程度を目途に改めて案内する方針を示しています。その後、10月1日にはFAQと退会者向けの問い合わせ案内が追加され、退会者への通知も同日から順次開始されたと説明されています。

    同社は、会社を装ったメールやSMS、電話への警戒を求めています。心当たりのない連絡に含まれるリンクや添付ファイルを開かず、パスワード、認証コード、クレジットカード情報を入力しないことが基本です。通知の内容や対象かどうかに疑問がある場合は、公式発表から問い合わせ先を確認してください。同社がメール、SMS、電話でパスワードやカード情報を尋ねることはないと案内しています。

    本人確認書類は保有目的とアクセス権限を一緒に見直す

    ここからは本件の原因を推定するものではなく、今回の事例を踏まえて、個人情報を扱う企業が確認したい一般的な対策を整理します。本人確認のために受け取る画像についても、会員台帳と同様に、何を、どこで、何のために保有しているかを把握することが出発点になります。退会や申込中断を含む業務の各段階とデータの保管場所を対応させ、取扱責任者や閲覧できる担当者まで確認すると、見直す対象が具体的になります。

    10月1日の公式FAQでは、タイムズカーは氏名・住所・生年月日を税法等に基づき7年間、運転免許情報と画像をなりすまし対策や問い合わせ対応のため7年間保管すると説明しています。保有データを点検する際は、このように項目ごとに保管の理由を確認する視点が必要です。退会情報があることだけで、個別企業の保管の適否や漏えい原因を判断することはできません。

    一方、個人情報の保存期間について、個人情報保護委員会のFAQでは、個人情報保護法が一律の保存期間や廃棄時期を定めているわけではないと説明しています。そのうえで、利用する必要がなくなった個人データは遅滞なく消去するよう努める必要があるとしています。自社では、保存の根拠と業務上の必要性を確かめ、期限を決めるだけで終わらせず、削除の対象を抽出して処理できる運用になっているか確認したいところです。

    保管が必要なデータには、業務に応じたアクセス制御が欠かせません。個人情報保護委員会の通則編ガイドラインも、担当者や取り扱うデータの範囲を限定すること、正当なアクセス権を持つ従業者を識別・認証することを求めています。本人確認担当、問い合わせ担当、システム管理担当で必要な権限を整理し、画像を閲覧・取得できる範囲が過大になっていないか点検することが、企業向けの具体的な確認例になります。

    個人情報を扱うWeb機能を継続して点検する

    保存ルールや社内権限の確認に加え、利用者からデータへ至る機能も検証する必要があります。会員登録、ログイン、登録情報の変更、書類のアップロードなど、個人情報を扱う処理を洗い出し、どの処理を点検済みか整理します。APIを利用している場合は、その通信や処理も対象に含めます。本件でAPIが悪用されたと確認されたわけではなく、ここで挙げるのは自社システムを点検する際の観点です。

    たとえば、本人がログインできることと、その本人に許可された情報だけを閲覧できることは、確認すべき内容が異なります。ログイン時の認証、ログイン状態を維持するセッション、ユーザー権限、重要情報の取り扱いを関連づけて確認することで、画面の通常操作だけでは見えにくい問題の検証につながります。本人確認画像を扱う機能を追加・変更したときにも、その機能を含めて診断範囲を見直すことが考えられます。

    点検は新規公開時だけで完了するものではありません。個人情報保護委員会のガイドラインは、システムの設計段階で安全性を確保し、継続して見直すことを対策の例に挙げています。自社の改修予定と診断計画を合わせ、見つかった課題の担当者と修正予定を決め、修正後の確認まで行う運用に結びつけることが重要です。

    個人情報の管理とWebの安全性をあわせて見直す

    ここまで挙げたWeb側の確認を自社だけで行うことが難しい場合は、外部の脆弱性診断を活用する方法もあります。ブロードバンドセキュリティ（BBSec）では、「Webアプリケーション脆弱性診断」を提供しています。同サービスは、自動診断と技術者による手動診断を組み合わせ、検出した問題の深刻度と推奨対策を報告するサービスです。Webアプリケーションに加え、APIもオプションとして診断できます。会員登録やログイン、登録情報の変更、書類のアップロードなど、個人情報を扱う機能を含め、どこまでを診断対象とするかについてサービスページから相談できます。

    個人情報を扱う体制や運用から整理したい企業には、「自己問診型 個人情報に関わる情報セキュリティアセスメント」も用意されています。オンラインの自己問診をもとにコンサルタントが評価し、課題や優先順位、対策案を示すサービスです。データを保有する理由と扱い方を整理する作業を、Web機能の技術的な点検と併せて進めることで、自社で優先すべき改善を具体化できるでしょう。

    【参考情報】

    個人情報を扱うWebサイトのセキュリティや、情報管理の体制・運用に課題を感じている場合は、現在の対策状況に応じた確認方法をご案内します。まずはお気軽にご相談ください。

    編集責任：木下

    ウェビナー開催のお知らせ

    最新情報はこちら

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る