tripla、インドネシア子会社のサーバが攻撃を受け予約管理システムが侵害 — 宿泊者の氏名・宿泊日・予約IDなどが流出
| 項目 | 内容 |
|---|---|
| 発生日 | 公表されていない。2025年12月6日に侵害を発覚 |
| 公表日 | 2025年12月8日 |
| 対象組織・業界 | tripla(宿泊施設向けDXサービス/情報通信・IT)。侵害を受けたのはインドネシア子会社の tripla BookandLink Indonesia |
| 影響件数 | 公表されていない。流出したのは宿泊者の氏名、宿泊日、予約ID、宿泊施設名など |
| 攻撃手法 | インドネシア子会社のサーバが外部からのサイバー攻撃を受け、予約情報を管理するシステムに侵害された形跡が確認された。原因は特定済みとされるが詳細は非公表 |
| 情報源 | Security NEXT(2025年12月8日) |
宿泊施設向けのDXサービスを提供するtriplaは2025年12月8日、インドネシアの子会社「tripla BookandLink Indonesia」のサーバが外部からのサイバー攻撃を受けたと公表しました。
予約情報を管理する同社システムに侵害された形跡があり、顧客の一部個人情報が外部へ流出しています。流出したのは宿泊者の氏名、宿泊日、予約ID、宿泊施設名などで、件数は公表されていません。
侵害は2025年12月6日に発覚し、同社は当該サーバをネットワークから切り離して調査を実施しました。すでに原因を特定しており、被害の拡大を防止する対策については実施済みとしています。
日本法人と台湾法人での同様の被害は否定されており、グループ内の他の子会社についても調査中で、現時点で同様の被害は確認されていないとしています。
- 侵入の開始時期: 公表されていない
- 2025年12月6日: インドネシア子会社のサーバへの侵害が発覚
- 発覚後: 当該サーバをネットワークから切り離して調査を実施。原因を特定し、被害拡大防止の対策を実施
- 2025年12月8日: triplaが公表。日本法人・台湾法人での被害を否定し、他の子会社は調査中とする
判明している事実: インドネシア子会社のサーバが外部からのサイバー攻撃を受け、予約情報を管理するシステムに侵害された形跡が確認されています。同社は原因を特定したとしていますが、侵入経路や悪用された脆弱性の内容は公表されていません。
考えられる原因(推測)
Section titled “考えられる原因(推測)”侵害されたのが海外子会社のサーバであり、日本法人と台湾法人では同様の被害が確認されていない点は、グループ各社のシステムが独立して運用されていたことを示唆します。子会社名に「BookandLink」が含まれることから、買収または統合によってグループに加わった事業の基盤である可能性が考えられます。
この構成では、グループ全体で統一された標準がシステムに適用されているとは限りません。買収前から動いている基盤は、更新の担当者、適用済みのパッチ、認証の方式が本社側と異なることが珍しくありません。他の子会社についても調査中とされている点は、同種の構成が複数存在し得ることを示しています。
流出項目が氏名・宿泊日・予約ID・宿泊施設名という構成である点は、参照されたのが予約レコードそのものであったことを示唆します。決済情報が挙げられていないことから、決済は別基盤で扱われていた可能性が考えられます。
組織が学ぶべきこと
Section titled “組織が学ぶべきこと”1. 買収・統合で加わった基盤は、グループ標準の適用状況を個別に確認する
Section titled “1. 買収・統合で加わった基盤は、グループ標準の適用状況を個別に確認する”グループ会社のシステムは、同じ会社名を掲げていても同じ管理下にあるとは限りません。本社が定めた標準が適用されているかどうかは、会社ごとに確認しなければ分かりません。外部から到達できるサーバの一覧とその管理責任者を、グループ全体で一つの台帳にまとめる必要があります。
2. 一社での侵害は、同じ構成を持つ他社の点検の号砲として扱う
Section titled “2. 一社での侵害は、同じ構成を持つ他社の点検の号砲として扱う”今回、triplaは日本法人・台湾法人での被害を否定するとともに、他の子会社の調査を進めています。同じ経路で侵入され得る構成が他にもあるという前提で動くことが、被害の横展開を止める唯一の方法です。
3. 予約レコードは、決済情報を含まなくても悪用され得る
Section titled “3. 予約レコードは、決済情報を含まなくても悪用され得る”流出したのは氏名・宿泊日・予約ID・宿泊施設名です。決済情報が含まれていないことは被害を抑える方向に働きますが、「いつどの施設に泊まるか」が分かる情報は、予約確認を装った連絡の材料になります。保存する予約履歴の期間を業務上必要な範囲に限ることが、影響を構造的に小さくします。
ヤグラの視点 — 影響範囲の特定:件数を出せない状態で、調査の網をグループ全体に広げている
Section titled “ヤグラの視点 — 影響範囲の特定:件数を出せない状態で、調査の網をグループ全体に広げている”この公表内容で目を引くのは、流出件数が示されていない一方で、日本法人と台湾法人での被害を明示的に否定し、他の子会社の調査を進めていると述べている点です。縦(何件出たか)は答えられず、横(どこまで広がっているか)は答えようとしている——影響範囲の特定作業が、まだ途中にあることが読み取れます。
海外子会社を含むグループでは、この二つの問いの難しさが違います。件数の確定は、侵害されたシステムのログを読み解く作業であり、時間をかければ収束します。一方で「グループの他社は無事か」は、各社の構成を把握していなければ、そもそも調べる対象を列挙できません。発覚から2日で日本法人・台湾法人の否定まで到達している点は、グループ内の主要な基盤については把握できていたことを示しています。
侵害の直後に問われるのは、防御の強度ではなく、この二つに答えられる状態にあるかどうかです。どのログがどこに残っていて、どの会社にどのシステムがあるか——それは事故が起きてから調べ始めるものではありません。技術的な侵入の痕跡は複数の機器のログに分散して現れ、人手で読み切ることは現実的ではないため、横断的に集約して機械的に拾う仕組みが必要になります(→ ヤグラ AI SOC)。グループ会社が増えるほど、その仕組みを本社と同じ水準で各社に届けているかが問われます。
- 流出した件数と対象者の確定
- 侵入経路と特定された原因の内容
- グループ内の他の子会社に対する調査結果
- 再発防止策の公表内容
| 日時 | 内容 |
|---|---|
| 2026-08-12 | 2025年12月8日の公表内容をもとにアーカイブ記事として作成 |