チューリッヒ保険会社「Z-Dash」への不正アクセス（最大1,668名の個人情報漏えいの可能性）
公表日
チューリッヒ保険会社のドライブレコーダー用システム「Z-Dash」に第三者が不正にアクセスし、最大1,668名の氏名やメールアドレスなどが漏れた可能性があります。流出が確認された人数はまだ発表されていません。
対象者は？
Z-Dashにドライブレコーダーのデータをアップロードした顧客のうち、最大1,668名（2026年8月27日時点）です。漏れた可能性がある情報は、事案管理番号、氏名、メールアドレスです。ドライブレコーダーの映像、クレジットカード情報、口座情報は含まれないと説明されています。
詳細が分かり次第、該当する顧客に郵送で通知されると発表されています。調査の状況は同社のウェブサイトで報告される予定です。
いますぐできること
- 郵送で届く通知を待ちましょう。
- 心当たりのないメールやメッセージには注意し、記載のリンクを開かないようにしましょう。
- 同社のウェブサイトのお知らせで、調査の状況を確認しましょう。
何が起きたのか
2026年8月18日、同社の社内調査で、ドライブレコーダーのデータをアップロードするためのシステム「Z-Dash」に弱点（脆弱性）があることが分かりました。過去のアクセスの記録を調べると、2026年4月1日と4月6日に第三者による不正なアクセスがあったことが確認されました。同社は8月27日にこの内容を公表しました。Z-Dashの利用は停止され、監督当局にも報告されています。
なぜ起きたのか・なぜ広がったのか
弱点の具体的な内容や、攻撃の手口は発表されていません。そのため、なぜ起きたのか、なぜ4月の不正アクセス使う権限のない人が、他人のIDやパスワード、システムの弱点を使って、サービスやサーバーに入り込むことです。日本では「不正アクセス禁止法」で禁止されている犯罪です。が8月まで分からなかったのかも、まだ分かっていません。同社は根本原因を調査しているとしています。
いまの状況2026-10-14 時点続報待ち
2026年10月14日時点で、本資料で確認できた範囲では、発表は8月27日の第1報だけです。実際に取得された情報の範囲や、氏名とメールアドレスの組み合わせは調査中で、続報はまだ発表されていません。対象情報を悪用した二次被害が出たという発表もありません。
企業として考えたいこと
自社に、お客様がデータをアップロードする仕組みはありますか。その仕組みで見つかった弱点について、過去のアクセス記録をさかのぼって調べられる状態になっていますか。
技術的な要約
チューリッヒ保険会社は2026年8月27日、ドライブレコーダーのデータをアップロードするためのシステム「Z-Dash」に第三者による不正アクセスがあり、最大1,668名の個人情報が漏えいした可能性があると公表した。2026年8月18日の社内調査でZ-Dashの脆弱性が判明し、過去のアクセス状況を調べた結果、2026年4月1日と4月6日に不正アクセスがあったことを確認した。漏えいの可能性がある情報は事案管理番号、氏名、メールアドレスで、組み合わせは調査中である。ドライブレコーダーの映像、クレジットカード情報、口座情報は含まれていない。同社はZ-Dashの利用を停止し、対象者の特定と根本原因の調査を進め、監督当局へ報告した。具体的な脆弱性の内容、CVE番号、攻撃手法、実際に取得された情報の範囲は公表されていない。
公開情報が限られている点について
攻撃の分類
- 侵入口
- 不明公式発表は「Z-Dashに脆弱性が認められた」とし、2026年4月1日と4月6日に第三者による不正アクセスがあったと説明している。具体的な脆弱性の内容、攻撃手法は公表されていない。
- 脆弱性
- CVE 非公表公表で確認Z-Dash（ドライブレコーダーのデータをアップロードするための同社システム）2026年8月18日の社内調査で脆弱性が判明。具体的な内容、CVE番号は公表されていない。
- 攻撃者
- 特定・主張なし
- ATT&CK
影響
- 業務停止
- あり 同社はZ-Dashの利用を停止した。他業務の停止は公表されていない。
- データ
- おそれ上限 1,668確定 —人その他氏名メール対象はZ-Dashにドライブレコーダーのデータをアップロードした顧客で最大1,668名（2026年8月27日時点）。情報は事案管理番号（損害調査業務の事案ごとに割り当てる8桁の番号。「その他」に該当）、氏名、メールアドレスで、組み合わせは調査中。ドライブレコーダーの映像、クレジットカード情報、口座情報は含まれない。第三者が実際に取得した情報の範囲は公表されていない。
- 波及先
- —
- 金銭影響
- —
- サプライチェーン
- 委託先や取引先を経由した事案との公表はない。
時系列
技術解説
公表された経緯と対象の範囲 事実
チューリッヒ保険会社は2026年8月27日、ドライブレコーダーのデータをアップロードするためのシステム「Z-Dash」に第三者による不正アクセスがあり、最大1,668名の個人情報が漏えいした可能性があると公表した。2026年8月18日の社内調査でZ-Dashの脆弱性が判明し、過去のアクセス状況を調べた結果、2026年4月1日と4月6日に第三者による不正アクセスがあったことを確認した。対象はZ-Dashにドライブレコーダーのデータをアップロードした顧客で、1,668名は2026年8月27日時点の最大値として示されている。
対象情報と公表されていない事項 事実
漏えいの可能性がある情報は、事案管理番号、氏名、メールアドレスである。各情報の組み合わせは調査中とされている。ドライブレコーダーの映像、クレジットカード情報、口座情報は含まれないと説明されている。事案管理番号は損害調査業務で事案ごとに割り当てる8桁の番号で、番号自体から顧客情報を類推できるものは含まれないとされる。一方、具体的な脆弱性の内容、CVE番号、攻撃手法、第三者が実際に取得した情報の範囲は公表されていない。二次被害が発生したとの公表もない。
同社の対応と今後の予定 事実
同社は、本事案を確認後にZ-Dashの利用を停止し、対象となった顧客の特定と根本原因の調査を進めていると説明している。監督当局への報告も実施済みだが、公表資料では報告先の機関名は明らかにされていない。個人情報保護委員会への報告の有無も、公開情報からは確認できない。詳細が判明した時点で、該当する顧客へ郵送で通知する。調査の進捗は同社のウェブサイトで報告するとしている。公式発表は2026年8月27日付の第1報のみである。
発覚の流れから読み取れること 解釈
公表内容を並べると、不正アクセスは4月に確認され、脆弱性の判明は8月18日である。社内調査で脆弱性を見つけ、その後に過去のアクセス記録を遡って調べたことで、4月の不正アクセスが確認されたという順序と読める。脆弱性の判明から公表までは9日である。ただし、4月の時点で異常を把握できなかった理由や、記録がどの期間まで残っていたかは公表されていない。そのため、検知の仕組みの良否は現時点では評価できない。
公表内容の評価と注意点 解釈
この公表には、読者が判断しやすい点がある。件数を最大値として示していること、含まれない情報を明記していること、通知方法を示していることである。一方で、1,668名は「可能性」の上限であり、実際に流出した人数は確定していない。氏名とメールアドレスの組み合わせが未確定のため、利用者への影響の大きさも現時点では見通せない。確定数や取得範囲は続報を待つ必要があり、現段階で原因や影響を断定することは避けるべきである。
対応
- 封じ込め
- 本事案を確認後、速やかにZ-Dashの利用を停止し、対象顧客の特定と根本原因の調査を実施している。
- 公表の仕方
- 2026年8月27日付でお知らせを公表。詳細が判明次第、該当する顧客へ郵送で通知し、調査状況を同社ウェブサイトで報告するとしている。
- 当局対応
- 監督当局へ報告済み（機関名は非公表。個人情報保護委員会への報告の有無は公開情報から確認できない）
教訓と対策
| 教訓 | 具体的な対策 |
|---|---|
| 脆弱性が見つかった時点で、過去のアクセス記録を遡って調べる手順が必要である。今回は脆弱性の判明後の遡及調査で、4月の不正アクセスが確認された。 | 脆弱性の判明を起点に、遡及調査を行う手順書を用意する。Webサーバ、アプリ、ストレージのアクセスログを最低でも1年保管し、検索可能な形で集約する。調査では、異常なリクエストや大量取得を抽出するクエリをあらかじめ準備する。 |
| 業務の周辺に置かれた小さなアップロード用システムも、本体と同じ水準で管理する必要がある。 | 外部公開しているシステムを資産台帳に登録し、所有者を決める。定期的な脆弱性診断と、公開範囲の棚卸しを四半期ごとに実施する。新規システムは公開前に診断を通すことをリリース条件にする。 |
| 保持する個人情報は必要最小限にし、保持期間を決めておくと、漏えいの可能性がある範囲を狭められる。 | アップロード用システムに保存する項目を見直し、不要な項目は保存しない。保存期間を定め、期限が来たデータを自動削除する。ストレージには最小権限のアクセス制御を設定し、署名付きURLの有効期限を短くする。 |
| 漏えいの可能性を公表する際は、上限と確定を分け、含まれる情報と含まれない情報を明確にする必要がある。 | インシデント対応の文書に、件数を「最大」と「確定」に分けて記載する欄を設ける。項目別に、含まれる、含まれない、調査中を表で整理するテンプレートを用意する。続報の公表条件も事前に決めておく。 |
| 取得された情報の範囲を後から確定できるよう、取得の記録を残しておく必要がある。 | オブジェクトストレージやAPIのアクセスログを有効にし、誰がどのデータを取得したかを追跡できるようにする。ログを改ざんできない別の場所に転送し、保管期間を定める。大量取得のアラートも設定する。 |
自組織などでの確認項目
- 自組織で、顧客が書類やデータをアップロードする仕組みをすべて挙げられるか。それぞれの所有者、公開範囲、最終診断日を確認できるか。
- 新しい脆弱性が見つかったとき、過去何か月分のアクセスログを遡って調べられるか。ログは検索できる状態で保管されているか。
- 漏えいの可能性があるとき、件数の上限、確定数、含まれない情報を分けて説明する書式が、自組織の対応手順に用意されているか。
- アップロード用システムに保存している個人情報の項目と保存期間は、業務上必要な範囲に収まっているか。不要になったデータは自動で削除されているか。
未解明点
- Z-Dashの脆弱性の具体的な内容と、4月1日・4月6日に使われた攻撃手法は何か。
- 第三者が実際に取得した情報の範囲と件数はどれだけか。
- 事案管理番号、氏名、メールアドレスの組み合わせはどうなっているか。
- 監督当局への報告先はどの機関か。個人情報保護委員会への報告は行われたか。
- 4月の不正アクセスを8月18日まで把握できなかった理由と、再発防止策は何か。
出典
- 1セキュリティ対策Lab（合同会社ロケットボーイズ）2026-08-28報道本文確認済
- 2ScanNetSecurity2026-09-01報道本文確認済
- 3チューリッヒ保険会社2026-09-30公式本文確認済
- 4チューリッヒ保険会社2026-08-27公式本文確認済