--- title: "リゾートトラスト不正アクセス：会員2.6万件・カハラ横浜3.6万件の対象確認と窓口" url: "https://www.issoh.co.jp/tech/details/18350/" published: 2026-10-15 updated: 2026-10-15 categories: ["セキュリティ"] publisher: "株式会社一創" --- # リゾートトラスト不正アクセス：会員2.6万件・カハラ横浜3.6万件の対象確認と窓口 会員制ホテル「エクシブ」などを運営するリゾートトラスト株式会社は2026年10月9日、同社が管理するウェブサイトが外部の第三者から不正アクセスを受け、サーバに保管されていた顧客の個人情報の一部が外部に漏洩したと公表しました。対象はグループ会員の一部約2万6千件と、ザ・カハラ・ホテル＆リゾート 横浜の予約者約3万6千件です。本記事の前半は、自分は対象か、どこに問い合わせるか、何が漏れたのかという利用者の疑問への、公式発表に沿った回答です。後半では、3時間の異常な作動を翌日に認知したという経過から、開発・運用の担当者が自社サイトで同じ異常を当日中に拾うためのログ監視と接続元の制限をコードで示します。 ## まとめ：リゾートトラスト不正アクセスで公表された事実と利用者・事業者の対応 公表されているのは、ウェブサイトのシステムが10月5日夜に約3時間にわたって異常に作動し、翌6日に同社が認知し、7日に不正アクセスによる情報漏洩と確認したという経過です。不正アクセスはすでに遮断され、外部のセキュリティ専門機関と詳しい調査を進めています。全国のホテルや施設の運営に直接の影響はなく、予約や滞在にも支障は無いとしています。 利用者がまずやることは、同社からの個別の案内を待ちつつ、心当たりのない連絡に記載されたURLや電話番号を使わないことです。問い合わせは公式発表に載った窓口へ自分でかけます。開発者が受け取る教訓は、会員や予約者の情報を持つサイトでは、夜間の数時間の異常を翌朝まで誰も見ていない状態そのものが弱点になるという点です。 | 項目 | 公表されている内容（2026年10月15日時点） | | ------- | ------------------------ | | 異常な作動 | 10月5日20時30分頃〜23時30分頃 | | 認知と確認 | 10月6日に認知、7日に漏洩を確認 | | グループ会員 | 一部の会員の情報 約2万6千件 | | カハラ横浜 | 予約者の情報 約3万6千件 | | 含まれない情報 | カード・銀行口座・メールアドレス等 | | 個別連絡 | 対象と確認できた人へ順次案内 | | 問い合わせ先 | 0120-350-132（RIC） | | 未公表 | 漏洩した項目・侵入の手口・脆弱性 | ## 利用者が最初に確かめること：対象かどうか、問い合わせ窓口と漏洩した項目 ### 自分が対象かを知る方法と、リゾートトラストから届く個別の案内 [リゾートトラストの10月9日の発表](https://www.resorttrust.co.jp/wp%5Fapi/wp-content/uploads/2026/10/20261009.pdf)によると、調査を続けたうえで、情報漏洩の対象と確認できた顧客には順次、個別にお詫びと状況の案内を送る予定です。発表の時点で、対象者が自分で照会できる専用ページは設けられていません。案内の手段（郵送か電話かなど）も書かれていないため、届いた連絡が本物かどうかは中身だけで判断せず、後述の窓口へ自分で確かめるのが確実です。 対象は2つに分かれています。1つはリゾートトラストグループの会員の一部で、エクシブなどの会員制ホテルの会員がすべて含まれるわけではありません。もう1つはザ・カハラ・ホテル＆リゾート 横浜の予約者です。こちらは会員でなくても、カハラ横浜を予約したことがあれば対象になり得ます。カハラ横浜の公式サイトのお知らせ欄にも同じ発表が掲載されています。 ### リゾートトラストインフォメーションセンター0120-350-132の受付時間 本件の問い合わせ先は、発表資料の2ページ目に記載されたリゾートトラストインフォメーションセンター（RIC）です。電話番号は0120-350-132で、受付時間は10月10日〜12日と平日の9時〜17時と書かれています。1ページ目の会社情報欄と報道関係者向けの窓口に載っている052-933-6519は、IR・広報課の番号で、受付は平日10時〜17時です。会員や予約者の相談はRICへかけます。 電話をかけるときは、検索結果や届いたメッセージに書かれた番号ではなく、発表資料そのものに載った番号を使ってください。メッセージに書かれた番号が本物の窓口と一致する保証は無いからです。漏洩後に届く連絡の真偽を確かめた別の事例は[タイムズカーの情報漏洩と0120-25-8924の真偽](https://www.issoh.co.jp/tech/details/17925/)で整理しています。 ### 漏洩した項目は未公表で、公式発表には含まれない情報だけが示されている点 発表は、漏洩した情報の種類（氏名・住所・電話番号など）を具体的に挙げていません。示されているのは、当該システムに含まれていない情報の一覧です。利用履歴、医療情報、クレジットカード情報、銀行口座情報、メールアドレス、本人確認書類等は含まれていないとしています。 報道や解説記事の中には漏洩項目を列挙したものもありますが、10月15日時点の公式発表に項目の記載はありません。本記事も項目を推測で補わない方針です。カード情報と口座情報が含まれていないため、カードをすぐ止める必要があるとは公表されていません。一方で、会員であることや予約の事実そのものが知られると、それを前提にした連絡に本物らしさが加わります。 ## 不審な連絡への備え：会員制ホテルを名乗る電話や郵便物を見分ける手順 ### 発表が求める確認方法と、公式サイトから正しい連絡先を引き直す習慣 リゾートトラストは発表の中で、心当たりのない不審な連絡やメッセージが届く可能性があるとし、少しでも不審に感じたら、届いたメッセージに書かれたURLや電話番号にはアクセスせず、相手が名乗る企業や機関の公式ホームページなどから正しい連絡先を確かめるよう求めています。 会員制ホテルの会員は、会費の支払いや施設の予約で運営会社とのやり取りを日常的に行っています。「会員権の名義変更手続き」「年会費の未納」「予約の確認のための本人確認」など、会員なら自然に受け取りそうな名目は警戒の対象です。支払いや個人情報の入力を急がせる連絡を受けたら、その場で応じず、自分で調べたRICの番号へかけ直します。手口と見分け方の考え方は[フィッシング詐欺の仕組みと技術的対策](https://www.issoh.co.jp/tech/details/13548/)で解説しています。 ### 10月13日の統合予約サイト休止告知と、電話予約への切り替え 10月13日には、[リゾートトラストのお知らせ欄](https://www.resorttrust.co.jp/topics/20261013/3378/)に、統合予約サイト、法人会員専用予約サイト、RTTGアプリ内の一部機能（マイページ、スマートチェックイン・チェックアウトなど）をメンテナンスのため休止するという告知が出ています。再開は改めて案内するとされ、会員制ホテルのWeb専用プランは再開まで電話で予約を受け付けます。 この休止が10月9日の不正アクセスと関係するかどうかは、告知の中で触れられていません。本記事も関係を推測しません。利用者にとっての実務上の影響は、当面のWeb予約ができないことと、予約の電話が増える時期に予約確認を装う連絡が紛れやすくなることです。予約サイトの再開を知らせるメールやSMSが届いても、リンクではなくリゾートトラストの公式サイトから確かめてください。宿泊予約の領域で施設や予約者を狙った手口は[手間いらずの不正アクセスと宿泊予約フィッシング](https://www.issoh.co.jp/tech/details/18193/)でも扱っています。 ## 公式発表で追う経過：10月5日夜の3時間の異常な作動から公表までの4日間 ### 異常な作動を翌10月6日に認知し、10月7日に情報漏洩と確認した時系列 1. 10月5日20時30分頃〜23時30分頃：ウェブサイトのシステムが異常に作動 2. 10月6日：異常な作動を認知 3. 10月7日：調査の結果、不正アクセスによる情報漏洩を確認し、不正アクセスを遮断 4. 10月9日：「当社ウェブサイトへの一部不正アクセスによる個人情報漏洩に関するお詫びとご報告」を公表 5. 10月13日：統合予約サイト等のメンテナンスによる休止を告知（本件との関係は記載なし） 異常な作動が始まってから認知まではおよそ1日、漏洩の確認までは2日です。どのシステムのどの脆弱性が使われたか、異常な作動とは具体的に何か（大量のデータ取得か、改ざんか）は公表されていません。発表は、外部の専門機関の調査結果を踏まえて、対象システムの脆弱性の改修、監視体制の強化、ネットワークアクセス権限の厳格な見直しを行うとしています。業績に重要な影響が出ることが明らかになった場合は速やかに開示するとしています。 ### 会員情報と予約者情報が1つのウェブサイトのサーバに保管されていた構造 発表は「当社が管理するウェブサイト」に不正アクセスがあり、「サーバに保管されていたお客様の個人情報の一部」が漏洩したと説明しています。会員の情報とカハラ横浜の予約者の情報という、利用者の層が違う2種類のデータが同じ事故で出ていることから、少なくとも攻撃者が届いた範囲に両方のデータがあったことがわかります。カード情報や口座情報、医療情報が別のシステムにあったことは、被害を限る結果につながりました。 ホテルの予約サイトは、空室検索や会員ログイン、予約変更のために会員データベースへ常時つながっている構成になりがちです。予約システムの機能と、外部連携をどこまで自社で持つかの考え方は[ホテル予約システムの機能と自社開発の判断基準](https://www.issoh.co.jp/column/details/15277/)で解説しています。 ## 自社サイトで同じ異常を当日中に拾う手順：送信元ごとの急増検知と接続元の制限 ### nginxのログをJSONで残し、送信元・時刻・送信バイトを後から集計できる形にする 夜間の3時間の異常を翌日ではなく当日中に拾うには、まず「誰が・いつ・どれだけのデータを受け取ったか」を後から集計できるログが要ります。[nginxのlog\_format](https://nginx.org/en/docs/http/ngx%5Fhttp%5Flog%5Fmodule.html)は`escape=json`を指定すると、変数の値をJSONの文字列として安全な形でエスケープします（1.11.8以上）。`$msec`はログを書いた時刻（ミリ秒精度の秒）、`$bytes_sent`はクライアントへ送ったバイト数です。 ``` # 会員データを返すAPIと管理画面のログを、送信元・時刻・送信バイトつきのJSONで残す（nginx 1.11.8以上） log_format member_json escape=json '{"msec":"$msec","remote_addr":"$remote_addr",' '"request_uri":"$request_uri","status":$status,' '"bytes_sent":$bytes_sent,"request_time":"$request_time"}'; server { # 管理画面は社内とVPNの範囲だけに絞る（記述順に評価され、最初の一致で決まる） location /admin/ { allow 10.0.0.0/8; deny all; access_log /var/log/nginx/admin.json.log member_json; } # 会員情報を返すAPIは別ファイルに分けて監視しやすくする location /api/members/ { access_log /var/log/nginx/members.json.log member_json; } } ``` 管理画面の`allow`と`deny`は、[nginxのアクセス制御モジュール](https://nginx.org/en/docs/http/ngx%5Fhttp%5Faccess%5Fmodule.html)のとおり記述した順に評価され、最初に一致したルールで決まります。`deny all`を先に書くと全員が拒否されるため、順番を守ります。リゾートトラストが再発防止策に挙げた「ネットワークアクセス権限の厳格な見直し」は、こうした接続元の制限を、管理画面だけでなくデータベースやサーバ間の通信にも当てはめる作業です。上の設定は本記事の環境では実行しておらず、構文はnginxの公式ドキュメントの記述に基づきます。 ### 10分ごとに送信元別の件数を集計し、中央値の20倍を超えた窓を指摘するPython ログが残ったら、送信元ごとの件数を短い窓で区切って集計し、全体の傾向から外れた送信元を指摘します。[OWASPのLogging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging%5FCheat%5FSheet.html)も、記録を検討すべき事象としてデータのエクスポートや「Excessive use（過度な利用）」を挙げています。 ``` # nginxのJSON形式アクセスログから「短時間に大量の応答を受け取った送信元」を洗い出す（Python 3.9以上・標準ライブラリのみ） # 使い方: python burst_check.py members.json.log import json, sys from collections import defaultdict from datetime import datetime, timezone from statistics import median WINDOW = 600 # 集計の窓（秒）。10分ごとに区切る MIN_REQUESTS = 60 # 1窓でこの件数を超え、かつ RATIO = 20 # 送信元全体の中央値のこの倍数を超えたら指摘する buckets = defaultdict(lambda: [0, 0]) # (窓の開始, 送信元) -> [件数, 送信バイト] for line in open(sys.argv[1], encoding="utf-8"): try: e = json.loads(line) except json.JSONDecodeError: continue # 壊れた行は飛ばす（件数は別途確認する） start = int(float(e["msec"])) // WINDOW * WINDOW b = buckets[(start, e["remote_addr"])] b[0] += 1 b[1] += int(e["bytes_sent"]) base = median(n for n, _ in buckets.values()) for (start, addr), (n, sent) in sorted(buckets.items()): if n > MIN_REQUESTS and n > base * RATIO: t = datetime.fromtimestamp(start, timezone.utc).astimezone() print(f"{t:%m-%d %H:%M} {addr} 件数{n} 送信{sent / 1e6:.1f}MB（中央値{base:g}件）") ``` ### 試験用ログでの実行結果と、検知を当日中の対応へつなげる通知の運用 通常の閲覧者50人分のアクセスに、1つの送信元が20時30分から3時間、6秒おきに会員APIを呼ぶ架空のデータを混ぜた試験用ログ（3,809行・アドレスは文書用の範囲）を作り、Python 3.14.6（Windows）で実行した結果の先頭3行です。これはリゾートトラストの事案の再現ではなく、公表されていない手口を仮定したものでもありません。夜間の数時間に続く異常を検知できるかを確かめるための例です。 ``` 10-05 20:30 203.0.113.45 件数100 送信5.2MB（中央値1件） 10-05 20:40 203.0.113.45 件数100 送信5.2MB（中央値1件） 10-05 20:50 203.0.113.45 件数100 送信5.2MB（中央値1件） ``` 同じ送信元が23時20分の窓まで18回続けて指摘され、通常の閲覧者は1件も出ませんでした。60件と20倍は目安なので、サイトの規模に合わせて変えてください。このスクリプトを10分ごとに定期実行し、指摘が出たら担当者の携帯に通知する仕組みにすれば、深夜の異常を翌朝ではなく発生中に知ることができます。ログを長く保管して改ざんされないようにする設計は[Fluentdで作る監査ログ基盤](https://www.issoh.co.jp/tech/details/10505/)、送信元の遮断を手前で行う仕組みは[WAFの仕組みと選び方](https://www.issoh.co.jp/tech/details/13275/)で解説しています。ログに残す項目からは、OWASPが除外を求めるパスワードやセッションIDを外しておくのが前提です。 ## 事業者の判断：会員情報を持つサイトが見直す範囲と報告義務の確認点 ### 漏洩時の個人情報保護委員会への報告の流れと、委託先を含めた責任の所在 今回の件で個人情報保護委員会へ報告する立場にあるのはリゾートトラストです。[個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、不正の目的によるおそれがある漏洩は件数にかかわらず報告の対象となり、速報は事態を知ってから3〜5日以内、確報は60日以内です。自社が同じ立場になったとき、予約システムや会員サイトの運用を外部に委託していても、本人への通知と委員会への報告の責任は個人情報を扱う事業者に残ります。報告の要否を判断する手順は[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)で解説しています。 ### 見直しを急ぐべき事業者と、第三者の脆弱性診断に頼る場面の線引き 判断は言い切れます。見直しを急ぐべきなのは、会員や予約者の情報をウェブサイトと同じサーバか、ウェブサイトから直接つながるデータベースに置いている事業者です。点検は3点に絞れます。会員情報を返すAPIや管理画面に送信元の制限をかけているか、夜間に異常が起きたときに誰かへ通知が届くか、カードや医療など特に守るべき情報をウェブサイトから届かない別のシステムに分けているか、です。3点目は今回の事案で被害を限った要素でもあります。 サイトの作り自体に脆弱性が残っていないかは、運用担当者が自分で確かめるには限りがあります。[IPAの「安全なウェブサイトの作り方」](https://www.ipa.go.jp/security/vuln/websecurity/about.html)で自社サイトの実装を一通り照らし合わせたうえで、会員情報を扱う画面とAPIは第三者の診断で確かめるのが現実的です。診断の種類と進め方は[脆弱性診断の種類・費用相場と外注の判断基準](https://www.issoh.co.jp/column/details/13101/)にまとめています。会員サイトや予約サイトを外部の目で点検するなら、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で相談できます。 ## よくある質問 リゾートトラストの不正アクセスについて、会員・予約者と事業者の担当者から出やすい質問をまとめました。 ### リゾートトラストの不正アクセスで漏洩した情報は何ですか？ 10月9日の発表では、グループ会員の一部約2万6千件と、ザ・カハラ・ホテル＆リゾート 横浜の予約者約3万6千件の情報が漏洩したとされています。漏洩した項目（氏名や住所など）は具体的に公表されていません。利用履歴、医療情報、クレジットカード情報、銀行口座情報、メールアドレス、本人確認書類等は当該システムに含まれていないとしています。 ### 自分が対象かどうかはどうすればわかりますか？ リゾートトラストは、対象と確認できた顧客へ順次、個別にお詫びと状況の案内を送る予定です。自分で照会できる専用ページは10月15日時点で設けられていません。不安な場合は、発表資料に記載されたリゾートトラストインフォメーションセンター（0120-350-132）へ問い合わせます。 ### 0120-350-132はリゾートトラストの正式な窓口ですか？ リゾートトラストが10月9日に公表した資料の2ページ目に、本件の問い合わせ先として記載されている番号です。受付時間は10月10日〜12日と平日の9時〜17時です。番号は届いたメッセージや検索結果からではなく、発表資料そのものから確かめてかけてください。 ### クレジットカードは止めたほうがよいですか？ 発表では、クレジットカード情報と銀行口座情報は当該システムに含まれていないとされています。すぐに止める必要があるとは公表されていません。ただし、本件を口実にカード番号や暗証番号を尋ねる連絡には応じず、利用明細に覚えのない請求が無いかは確かめておくと安心です。 ### エクシブなどのホテルの予約や宿泊に影響はありますか？ 発表では、全国のホテルと各施設の運営に本件による直接の影響はなく、予約や滞在にも支障は無いとしています。ただし10月13日から、統合予約サイトや法人会員専用予約サイト、アプリの一部機能がメンテナンスのため休止しており、会員制ホテルのWeb専用プランは電話で予約を受け付けています。 ## 関連記事 - [不正アクセス対策とは：IPA・JPCERTの2026年10月注意喚起に沿った企業の点検手順](https://www.issoh.co.jp/column/details/18313/)：企業として点検する範囲の全体像 - [手間いらずの不正アクセスと宿泊予約フィッシング｜施設・予約者・接続先の点検手順](https://www.issoh.co.jp/tech/details/18193/)：宿泊予約の領域で起きた別の事例と予約者の備え - [skyticket不正アクセス：1,464万件流出の対象確認と本物メールの見分け方](https://www.issoh.co.jp/tech/details/18322/)：旅行予約サービスの漏洩で対象を確かめる手順 - [タイムズカー情報漏洩・流出：対象の確認と補償、0120-25-8924は本物か、免許証画像への備え](https://www.issoh.co.jp/tech/details/17925/)：漏洩後に届く連絡の真偽を確かめる手順 - [フィッシング詐欺とは？成立の仕組みと実装者向けの技術的対策を解説](https://www.issoh.co.jp/tech/details/13548/)：漏洩後に増える偽の連絡を見分ける考え方 --- 出典: [リゾートトラスト不正アクセス：会員2.6万件・カハラ横浜3.6万件の対象確認と窓口]()（株式会社一創）