チューリッヒ保険会社、ドライブレコーダーのデータをアップロードするシステム「Z-Dash」に不正アクセス — 4月の侵害を8月の脆弱性調査で発見

項目	内容
発生日	2026年4月1日および4月6日（第三者による不正アクセスがあった日）。脆弱性の判明は8月18日、漏えいの可能性の確認は8月27日
公表日	2026年8月27日（報道は2026年8月28日）
対象組織・業界	チューリッヒ保険会社（損害保険／金融・保険）。対象はドライブレコーダーのデータをアップロードするシステム「Z-Dash」
影響件数	最大1,668件。氏名、メールアドレス、事案管理番号。ドライブレコーダーの映像やクレジットカード番号は含まれない
攻撃手法	「Z-Dash」の脆弱性を突いた第三者による不正アクセス。脆弱性の内容は公表されていない
情報源	チューリッヒ保険会社「当社システムに対する不正アクセスおよび個人情報漏えいの可能性について」（2026年8月27日）、Security NEXT（2026年8月28日）、ITmedia NEWS（2026年8月28日）

概要

チューリッヒ保険会社は2026年8月27日、同社が損害調査の業務で利用しているシステム「Z-Dash」が不正アクセスを受け、顧客の個人情報が漏えいした可能性があると公表しました。Z-Dashは、ドライブレコーダーのデータをアップロードするために利用しているシステムです。

きっかけは2026年8月18日の社内調査でした。この調査でZ-Dashに脆弱性が確認され、続く調査によって、2026年4月1日および4月6日に第三者による不正アクセスがあったことが判明します。漏えいの可能性が確認されたのは8月27日です。

対象となるのは、同システムにドライブレコーダーのデータをアップロードした顧客の最大1,668件で、含まれるのは氏名、メールアドレス、事案管理番号です。ドライブレコーダーの映像やクレジットカード番号は含まれないとしています。

同社は事案の確認後にシステムを停止し、対象者の特定と根本原因の調査を進めています。監督当局への報告は完了しており、詳細が判明し次第、該当する顧客へ郵送で通知するとしています。調査の進捗は同社Webサイトで報告する予定です。

経緯

• 2026年4月1日・4月6日: 「Z-Dash」に対して第三者による不正アクセスが行われる
• 2026年8月18日: 社内調査により「Z-Dash」の脆弱性が判明
• その後: 調査により4月1日・4月6日の不正アクセスを確認
• 2026年8月27日: 個人情報が漏えいした可能性を確認し公表。システムを停止し、監督当局への報告を完了
• 2026年8月28日: 報道により広く伝えられる
• 以降: 対象者の特定と根本原因の調査を継続。判明次第、該当顧客へ郵送で通知

原因

判明している事実: 「Z-Dash」に脆弱性があり、それが第三者による不正アクセスに使われたことです。脆弱性の具体的な内容、不正アクセスの手口、4月1日と4月6日という2日だけであった理由、8月18日の社内調査が何を契機に行われたのかは、いずれも公表されていません。

考えられる原因（推測）

発見の順序が通常と逆になっています。先に脆弱性が見つかり、そこから遡って4か月半前の不正アクセスが判明したという流れです。裏を返せば、4月1日と4月6日の時点では、このアクセスは異常として拾われていなかったことになります。

対象が「アップロードした顧客」であり、項目が氏名・メールアドレス・事案管理番号にとどまっている点も、システムの性格を表しています。Z-Dashはデータの受け渡しのために置かれたシステムで、そこに残っていたのは誰が何番の案件でアップロードしたかという受付の記録でした。映像そのものが含まれないという説明は、映像の保管先が別にあることを示していると考えられます。

不正アクセスが4月1日と4月6日の2日に限られている点については、公表内容からは判断できません。攻撃者が2回しか来なかったのか、記録から確認できたのがこの2日だったのかは区別されていません。

対策

組織が学ぶべきこと

1. 脆弱性が見つかったら、修正だけで終わらせず「使われていないか」を遡って調べる

今回、4月の不正アクセスは脆弱性の発見をきっかけに見つかりました。脆弱性を塞いだ時点で作業を終えていれば、この2日間のアクセスは誰にも知られないままでした。見つかった脆弱性について、いつから存在していたのか、その期間に不審なアクセスがなかったかを確認する工程を、修正とセットにしておく必要があります。

2. データの受け渡し用システムを、業務システムと同じ管理下に置く

Z-Dashはドライブレコーダーのデータを受け取るために置かれたシステムでした。この種の「渡すため」「受け取るため」のシステムは、業務の本体ではないぶん、脆弱性管理や監視の対象から外れやすい部分です。今回の脆弱性が8月18日の社内調査で初めて見つかっていることからも、定期的な確認の対象に入っていたかどうかは読み取れません。外部から到達できる以上、更新の対象にも監視の対象にも入れておく必要があります。

3. 受け渡し用のシステムに、必要以上のデータを残さない

今回対象になったのは氏名・メールアドレス・事案管理番号で、ドライブレコーダーの映像は含まれていません。映像の保管先が別にあったためと考えられます。受け渡しのためのシステムは、渡し終えたデータをそのまま置き場所として使ってしまいがちですが、受け付けの記録だけを残して中身を別の場所へ移す設計にしておけば、侵害されたときに出るものが減ります。

ヤグラの視点 — 発見までの時間：4月に入られたシステムが、8月まで動き続けていた

この事案でまず見るべきは、4月1日と4月6日に不正アクセスを受けたシステムが、8月18日まで侵入された事実を知られないまま動いていたことです。約4か月半あります。今回対象になったのは氏名・メールアドレス・事案管理番号で、映像もクレジットカード番号も含まれていません。ただしそれは、そのシステムに置かれていたデータがたまたまその範囲だったからであって、4か月半という時間の長さとは関係がありません。

侵入されている時間が長いほど、攻撃者にできることは増えます。同じ入口から別のシステムへ移る、認証情報を集める、気づかれない量ずつ持ち出す——いずれも時間さえあれば選べる手です。4月の時点で気づけていれば、その日のうちに閉じられました。被害が今回の範囲で収まったことと、4か月半気づかなかったことは、分けて見る必要があります。次に同じ長さの時間を与えたとき、置かれているデータが同じとは限りません。

では、なぜ4月に気づけなかったのか。アラートが上がらない侵入は、探しに行かなければ見つかりません。今回それが可能になったのは、8月に脆弱性という手がかりを得て、そこから遡る問いを立てられたからです。手がかりがない状態で毎日ログを読み続けるのは、人員の問題として無理があります。24時間分のログをすべて読む担当は置けず、実際にはアラートが上がったものを業務時間内に順番に確認する形になる。この構造がある限り、静かな侵入は長く残ります。各所に散らばるログを1か所に集めてAIが常時見る、検知から初動までを数時間〜数日ではなく数分の単位に引き下げる——人手の限界を前提に置いたこの組み方が、現実解になりつつあります（→ ヤグラ AI SOC）。

今後の対応

• 脆弱性の具体的な内容と、存在していた期間
• 根本原因の調査結果
• 対象者の確定と、郵送による通知の実施状況
• 4月1日・4月6日以外の期間についての確認結果

判明次第、本記事に追記します。

更新履歴

日時	内容
2026-08-31	2026年8月27日の公表内容および2026年8月28日の報道をもとに記事を公開