---
title: "プレステージ・インターナショナル不正アクセス：最大550万件の対象確認と認証失効の設計"
url: "https://www.issoh.co.jp/tech/details/19219/"
published: 2026-11-02
updated: 2026-11-03
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# プレステージ・インターナショナル不正アクセス：最大550万件の対象確認と認証失効の設計

プレステージ・インターナショナルは2026年11月2日、グループの業務システムが不正アクセスを受け、ロードサービスを利用した人の個人情報が最大約550万件、外部に持ち出されたと公表しました。対象は、グループ会社のプレステージ・コアソリューションが損害保険会社や自動車メーカーなどから受託している受付・手配業務のシステムです。本記事では、ロードサービスを使ったことがある人が知りたい「自分は対象か」「保険会社を名乗る連絡は本物か」に公式発表の文言で先に答えます。後半では業務システムを持つ事業者に向けて、認証情報を無効化しても侵入が続いた点に着目し、セッションの一括失効と大量読み取りの検知を実行できるPythonのコードで示します。

## まとめ：プレステージ・インターナショナル不正アクセスの判明事実と利用者・委託元の対応

確定しているのは次の事実です。同社は10月29日に不正アクセスを検知し、不正に利用された認証情報の無効化などの措置を取りました。その後も不正アクセスが続いたため、10月30日にシステムを止めています。侵入の経路と原因は、外部の専門機関と調査中です。

利用者が今日やることは、保険会社やロードサービスの窓口を名乗る電話・SMSで、口座の暗証番号やパスワードを答えないことです。業務を委託している企業は、自社の顧客のうち何件が含まれるかを委託先から受け取り、本人への案内の方法を決めることになります。

| 項目      | 公表されている内容（11月2日時点）        |
| ------- | ------------------------- |
| 検知日     | 2026年10月29日               |
| システム停止  | 2026年10月30日（不正アクセス継続のため）  |
| 件数      | 最大約550万件（重複を含む・人数は精査中）    |
| 漏えいした項目 | 氏名・住所・電話番号・メールアドレス・車両情報など |
| 含まれない情報 | クレジットカード情報（漏えいは確認されていない）  |
| 原因・侵入経路 | 調査中（外部の専門機関と連携）           |
| 本人への案内  | 取引先企業と協議のうえ対応             |

問い合わせ窓口は同社の広報・IR部で、電話03-5213-0826（平日10時〜18時）と案内されています。二次被害は11月2日時点で確認されていません。

## ロードサービス利用者が対象か確かめる手順｜委託元経由の案内と偽の連絡の見分け方

### 損保・自動車メーカー・ディーラー経由で使ったロードサービスが対象になる仕組み

[同社の11月2日の公表](https://www.prestigein.com/Portals/0/pdf/NEWS/news%5F20261102%5F01.pdf)によると、対象のシステムはプレステージ・コアソリューションが取引先企業から受託している「ロードサービス等の受付・手配業務」に使うものです。[同社の事業内容](https://www.prestigein.com/pcs/solutions/)には、損害保険会社・自動車メーカー・ディーラーなどを取引先とするロードサービスの提供が挙げられています。

利用者は、自動車保険の付帯サービスや新車購入時のサポートとしてロードサービスを呼んでおり、プレステージの名前を知らないことがほとんどです。電話をかけた先が保険会社やメーカーの窓口でも、受付と手配の裏側で同社のシステムに記録されていた可能性があります。11月2日時点で、委託元の企業名は公表されていません。

対象者への案内は「お取引先企業と協議のうえ、適切に対応」とされています。案内は、契約している保険会社や購入したメーカー・ディーラーから届く形になると考えられます。自分から問い合わせる前に、契約先の公式サイトのお知らせ欄を確かめてください。

### 保険会社をかたる電話・SMSと口座の暗証番号を尋ねる連絡を見分ける基準

公表文は、同社とグループ会社、保険会社などの関係先をかたる不審な電話・メール・SMSへの注意を呼びかけています。判断の基準は次の2点です。

- 電話やメールで、パスワードや口座の暗証番号を尋ねていないか
- SMSやメールのURLから、ログインや口座情報の入力に誘導していないか

同社は、本件に関連して電話やメールでパスワードや暗証番号を尋ねることはないと明記しています。どちらかに当てはまる連絡は、正規の案内ではありません。保険証券に書かれた番号へ自分でかけ直して確かめます。差出人アドレスの確かめ方は[SpeeCAN RAIDEN不正アクセスの偽メールの見分け方](https://www.issoh.co.jp/tech/details/18363/)、偽サイトへ誘導する手口は[フィッシング詐欺とは](https://www.issoh.co.jp/tech/details/13548/)で解説しています。

### 車台番号と事故・故障の受付内容が名簿に含まれた場合に利用者が警戒する連絡

漏えいした項目は、氏名、住所、電話番号、メールアドレス、車両に関する情報（登録番号・車台番号など）、事故・故障の受付に関する情報、金融機関の口座に関する情報（一部）です。口座情報が誰の分まで含まれるかは公表されていません。

この名簿の厄介な点は、事故や故障の受付内容が氏名・車両と結び付いていることです。「先日のレッカー搬送の費用精算で返金があります」のように、本人しか知らないはずの出来事を文面に入れた連絡は信じやすくなります。返金や保険金の支払いを口実に口座の確認を求められたら、その場で答えず、契約先の窓口へ自分でかけ直してください。口座の明細に心当たりのない引き落としがあれば、金融機関に連絡します。

## 委託先BPOの業務システム漏えいで委託元の企業が負う報告と本人通知の範囲

### 個人情報保護法26条1項ただし書きで委託先から委託元へ通知した場合の報告義務

今回の漏えいは、業務を受託した側（委託先）のシステムで起きました。[個人情報保護法](https://laws.e-gov.go.jp/law/415AC0000000057)26条1項は、漏えいなどが起きた個人情報取扱事業者に個人情報保護委員会への報告を義務付けています。ただし書きで、委託を受けた事業者が規則に従って委託元へ事態を通知したときは、委託先の報告義務は外れると定めています。

公表文は、同社として個人情報保護委員会への報告を進めているとしています。委託元の損保やメーカーにとっては、自社の顧客の個人データが漏えいした当事者として、自ら報告と本人通知を行う立場です。委託先から届く通知で、自社分の件数と項目を特定できるかが最初の作業になります。報告対象の判断は[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)で整理しています。

### 速報3〜5日・確報60日の期限と重複を含む最大550万件という件数の扱い

[個人情報保護委員会の「漏えい等の対応とお役立ち資料」](https://www.ppc.go.jp/personalinfo/legal/leakAction/)は、速報を発覚日から3〜5日以内、確報を30日以内とし、不正な目的で行われたおそれがある場合は60日以内としています。不正アクセスは60日の側です。10月29日の検知を起点にすると、確報の期限は12月下旬になります。

公表された約550万件は重複を含む最大値で、重複を除いた人数は精査中です。同じ人の受付記録が複数含まれ得るため、委託元が本人通知の宛先数を見積もるには、委託先から受付単位ではなく人単位の名寄せ結果を受け取る必要があります。協力会社の情報の一部も含まれる可能性があり、こちらも精査中とされています。

### 委託元が委託先管理の契約で事前に決めておく受付データの保存期間と通知期限

個人情報保護法25条は、個人データの取扱いを委託した事業者に、委託先への必要かつ適切な監督を求めています。今回のような受付・手配の業務では、事故の受付記録を何年分、委託先のシステムに残すかが漏えい件数を左右します。

契約で決めておく項目は、受付データの保存期間と期間後の削除方法、委託元への事故通知の期限、件数を人単位で報告する義務の3点が中心です。保存期間が決まっていない委託では、過去の受付記録が積み上がり、1回の侵入で出る件数が数百万件に達します。点検表と契約条項の例は[委託先管理とは](https://www.issoh.co.jp/column/details/18778/)、委託先の正規アカウントが悪用された事例は[NEC委託先の不正アクセス](https://www.issoh.co.jp/tech/details/18699/)で扱いました。

## 認証情報を無効化しても続く不正アクセスへの備え｜セッション一括失効をPythonで書く

### パスワード変更だけでは既存セッションとAPIトークンが残る理由とOWASPの記述

公表文によると、同社は不正に利用された認証情報を無効化した後も、不正アクセスの継続を確認しています。侵入経路は公表されていないため、今回の原因を特定することはできません。ここでは一般論として、認証情報を無効化しても侵入が止まらない典型を整理します。

多くの業務システムは、ログイン時にセッションやAPIトークンを発行し、以後はそれで本人を判定します。パスワードを変えても、すでに発行済みのセッションやトークンは有効なまま残る実装が珍しくありません。[OWASPのSession Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session%5FManagement%5FCheat%5FSheet.html)は、パスワード変更などの権限レベルの変化の後にセッションIDを作り直し、古いセッションIDを破棄するよう求めています。攻撃者が別の協力会社アカウントや別の認証情報も握っていれば、1つを止めても侵入は続きます。

### 失効時刻より前に発行したセッションを一括失効し失効後の新規発行を検出するコード

次のコードは、アカウントごとに「この時刻より前に発行したものは全部無効」という境界を持たせる最小の例です。Python標準の[sqlite3モジュール](https://docs.python.org/3/library/sqlite3.html)だけで動きます。session\_revoke.pyとして保存します。

```
import sqlite3
from statistics import median

# 認証情報を無効化した時刻を境に、それより前の発行物を全部無効にし、
# 無効化の後に同じアカウントで発行されたセッションと大量読み取りを洗い出す
db = sqlite3.connect(":memory:")
db.executescript("""
CREATE TABLE account(name TEXT PRIMARY KEY, valid_after TEXT);
CREATE TABLE session(sid TEXT PRIMARY KEY, name TEXT, issued_at TEXT, kind TEXT);
CREATE TABLE access_log(name TEXT, hour TEXT, rows_read INTEGER);
""")
db.executemany("INSERT INTO account VALUES (?, ?)", [
    ("op-tokyo-01", None),
    ("partner-kanto-07", None),
])
db.executemany("INSERT INTO session VALUES (?, ?, ?, ?)", [
    ("s1", "partner-kanto-07", "2026-10-28T22:10", "web"),
    ("s2", "partner-kanto-07", "2026-10-29T02:40", "api-token"),
    ("s3", "op-tokyo-01", "2026-10-29T09:00", "web"),
    ("s4", "partner-kanto-07", "2026-10-29T15:30", "web"),
])
db.executemany("INSERT INTO access_log VALUES (?, ?, ?)", [
    ("op-tokyo-01", "2026-10-29T09", 180), ("op-tokyo-01", "2026-10-29T10", 210),
    ("op-tokyo-01", "2026-10-29T11", 195),
    ("partner-kanto-07", "2026-10-28T21", 40), ("partner-kanto-07", "2026-10-28T22", 35),
    ("partner-kanto-07", "2026-10-29T01", 30), ("partner-kanto-07", "2026-10-29T03", 9200),
    ("partner-kanto-07", "2026-10-29T16", 8800),
])

def revoke_all(name, at):
    # パスワードの変更とは別に「この時刻より前に発行したものは全部無効」を記録する
    db.execute("UPDATE account SET valid_after=? WHERE name=?", (at, name))
    cur = db.execute("""DELETE FROM session WHERE name=? AND issued_at < ?
                        RETURNING sid, issued_at, kind""", (name, at))
    return cur.fetchall()

def issued_after_revoke():
    # 無効化した後に同じアカウントで新しく発行されたセッション＝侵入が続いている疑い
    return db.execute("""SELECT s.sid, s.name, s.issued_at FROM session s
        JOIN account a ON a.name = s.name
        WHERE a.valid_after IS NOT NULL AND s.issued_at >= a.valid_after""").fetchall()

def bulk_reads(factor=20):
    alerts = []
    for (name,) in db.execute("SELECT name FROM account").fetchall():
        rows = db.execute("SELECT hour, rows_read FROM access_log WHERE name=?", (name,)).fetchall()
        base = median(r for _, r in rows)
        alerts += [(name, h, r, round(r / base)) for h, r in rows if r >= base * factor]
    return alerts

print("無効化で消したセッション:", revoke_all("partner-kanto-07", "2026-10-29T15:00"))
print("無効化の後に発行されたセッション:", issued_after_revoke())
print("中央値の20倍以上を読んだ時間帯:")
for name, hour, n, x in bulk_reads():
    print(f"  {name} {hour}時台 {n}件（中央値の約{x}倍）")
```

2026年11月2日に、Python 3.14.7で実行した結果です。アカウント名と件数は架空で、同社のシステムの構造ではありません。DELETEのRETURNING句はSQLite 3.35以降で使えます。

```
$ python session_revoke.py
無効化で消したセッション: [('s1', '2026-10-28T22:10', 'web'), ('s2', '2026-10-29T02:40', 'api-token')]
無効化の後に発行されたセッション: [('s4', 'partner-kanto-07', '2026-10-29T15:30')]
中央値の20倍以上を読んだ時間帯:
  partner-kanto-07 2026-10-29T03時台 9200件（中央値の約230倍）
  partner-kanto-07 2026-10-29T16時台 8800件（中央値の約220倍）
```

revoke\_all関数は、15時を境にそれ以前のWebセッションs1とAPIトークンs2を消しました。パスワードを変えるだけでは、この2つは生き残ります。issued\_after\_revoke関数は、無効化の30分後に同じアカウントで発行されたs4を拾いました。無効化の後に新しいセッションが出ていれば、攻撃者が新しい認証情報か別の経路を持っている疑いがあり、アカウント単位ではなくシステム単位で止める判断材料になります。

### 1アカウントが中央値の20倍を超える受付記録を読んだ時間帯で止める検知の閾値

bulk\_reads関数は、アカウントごとに1時間あたりの読み取り件数の中央値を取り、その20倍以上の時間帯を出します。実行例では、普段1時間に30〜40件しか読まない協力会社のアカウントが、深夜3時台に9,200件を読んだ時点で検出されました。手配の現場では、1人の担当者が1時間に数百件の受付記録を開くことはまずありません。

20倍という値は例で、業務の繁閑に合わせて決め直します。台風や大雪の日はロードサービスの受付が急増するため、全体の件数ではなくアカウント単位で見るのが要点です。検知した時点で自動的にそのアカウントのセッションを失効させれば、検知からシステム停止の判断までに時間がかかっても、その間の持ち出し量を抑えられます。Microsoft 365の監査ログで同じ考え方を使う手順は[サントリーの不正アクセス](https://www.issoh.co.jp/tech/details/19215/)で解説しています。

### この実装で防げない侵入とMFA・APIの件数上限を本番で組み合わせる理由

このコードは考え方を示す最小の例で、攻撃者がサーバーの管理者権限を握った場合や、正規の担当者の端末を乗っ取った場合は防げません。本番では次の3つを組み合わせます。

1. 協力会社を含む全アカウントに多要素認証を必須にし、パスワードだけではログインできないようにする
2. 受付記録を読むAPIに、1回・1時間あたりの取得件数の上限を設ける
3. 失効の境界時刻をアプリのサーバーだけでなく、APIゲートウェイやキャッシュ層にも伝える

1つ目が抜けると、漏れたパスワードで何度でも新しいセッションを作られます。方式の選び方は[多要素認証（MFA）とは](https://www.issoh.co.jp/tech/details/13314/)、APIの件数上限とトークン失効は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)で解説しています。

3つを揃えても、名簿が一度外へ出たあとの悪用までは止められません。保管先ごとに架空のおとり会員を仕込み、流出した名簿が使われた時点と流出元を早く知る実装は、[クラブツーリズム不正アクセス：約432万件の対象確認と偽メールの見分け方・流出検知の設計](https://www.issoh.co.jp/tech/details/19221/)でPythonのコード付きで示しています。

## 受付・手配の業務システムを今月点検する事業者と次の改修でよい事業者の判断基準

### 外部の協力会社が自社の業務システムへログインする受付・手配型の事業者

レッカー会社や修理業者など、外部の協力会社に業務システムのアカウントを発行している事業者は、今月中に2点を確かめてください。1点目は、パスワードを変えたときに発行済みのセッションとAPIトークンが失効するか。2点目は、1つのアカウントで受付記録をまとめて大量に読めないかです。発行済みのものが失効しない、または大量に読める、のどちらかに当てはまれば、今回と同じく認証情報を止めても侵入が続く構造です。

協力会社のアカウントは人の出入りが多く、退職者のIDや共有IDが残りやすい領域でもあります。外から到達できる画面とAPI、アカウントの権限設定まで第三者の目で洗い出したいときは、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で点検できます。

### 受付データを委託先に預けずに照会用のAPIだけを開いている委託元の事業者

顧客データを自社に置き、委託先には照会用のAPIだけを開いている事業者は、テーブル構造の改修は次の機能追加のときで足ります。先に済ませるべきは、委託先が1日に照会できる件数の上限と、照会ログを自社で保管しているかの確認です。委託先にデータの写しを渡している場合は、保存期間と削除の証跡を契約で求めます。問い合わせ管理の委託先に口座番号を残さない設計は[大和証券の情報漏洩・不正アクセス](https://www.issoh.co.jp/tech/details/18132/)で扱いました。

## よくある質問

プレステージ・インターナショナルの不正アクセスについて、ロードサービスの利用者と、業務を委託している事業者から出やすい質問をまとめました。

### プレステージ・インターナショナルのロードサービスを使った覚えがなくても対象になりますか？

対象に含まれる可能性があるため、確認が必要です。同社グループは損害保険会社や自動車メーカー、ディーラーなどからロードサービスの受付・手配を受託しており、利用者は保険会社や販売店の名前で窓口に電話しています。自分がプレステージの名前を知らなくても、受付の記録が同社のシステムに残っていれば、対象に含まれ得ます。案内は取引先企業と協議して行うとされているため、契約先からの連絡を待ってください。

### 漏えいした約550万件は550万人分という意味ですか？

同じ意味ではありません。約550万件は重複を含む最大値で、重複を除いた人数は11月2日時点で精査中です。ロードサービスを何度か利用した人は、その回数分の受付記録が含まれている可能性があります。同社は、公表すべき新たな事実が判明した場合は速やかに知らせるとしています。

### クレジットカードや銀行口座の不正利用は確認されていますか？

クレジットカード情報の漏えいは11月2日時点で確認されていません。金融機関の口座に関する情報は一部が含まれていますが、誰の分かは公表されていません。不正利用などの二次被害も確認されていないとしています。口座の明細に心当たりのない引き落としがあれば、金融機関に連絡してください。暗証番号を電話で尋ねる連絡には応じないでください。

### 保険会社を名乗って口座番号を確認する電話がかかってきたらどうすればよいですか？

その場で答えずに電話を切り、保険証券や公式サイトに書かれた番号へ自分でかけ直してください。同社が明記している方針は、本件に関連して電話やメールでパスワードや口座の暗証番号を尋ねることはない、というものです。保険会社などの関係先をかたる不審な電話・メール・SMSにも注意を呼びかけています。身に覚えのないURLは開かないようにします。

### 不正アクセスの原因や侵入経路は公表されていますか？

11月2日時点では公表されていません。公表されているのは、10月29日に検知して不正に利用された認証情報を無効化したこと、その後も不正アクセスが続いたため10月30日にシステムを止めたことです。外部の専門機関と原因と影響範囲を調べており、システムの改修と監視体制の強化を進めるとしています。続報は同社のニュース欄で確かめてください。

## 関連記事

- [NEC委託先の不正アクセス・情報漏洩｜委託先はどこか、大阪公立大学と大阪大学7.8万人の被害、委託元の点検手順](https://www.issoh.co.jp/tech/details/18699/)：委託先の正規アカウントが悪用された事例と委託元の点検
- [委託先管理とは？個人情報保護法25条の監督義務とチェックリスト・契約条項の実務](https://www.issoh.co.jp/column/details/18778/)：受付データの保存期間と事故通知を契約で決める手順
- [API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策](https://www.issoh.co.jp/tech/details/18346/)：取得件数の上限とトークン失効の実装
- [多要素認証（MFA）とは？3要素と実装方式・耐フィッシングMFAをコード付きで解説](https://www.issoh.co.jp/tech/details/13314/)：協力会社アカウントに必須にする認証方式
- [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：委託元が行う報告の判断と期限

---

出典: [プレステージ・インターナショナル不正アクセス：最大550万件の対象確認と認証失効の設計](<https://www.issoh.co.jp/tech/details/19219/>)（株式会社一創）