速報

Firefoxが不正な証明書への対策を追加!OneCRL配信が届かない端末も更新を確認

CATEGORY

阪急阪神百貨店で約126万件の個人情報の一部が漏えい|共通IDとサービス停止の確認点

※本ページのリンクにはプロモーションが含まれています。

予約と通販の接続停止、顧客情報の調査、公式案内の確認を表すグレー背景のフラットな概念イラスト

この記事のポイント

対象
阪急百貨店・阪神百貨店予約サイト、HANKYU HANSHIN E-STORES、Remo Order、H2O ID
影響
不正アクセスによりH2O ID約126万件の個人情報の一部の漏えいが判明。通販・Remo Order側の注文履歴等の漏えい可能性は調査中。ログインパスワードの漏えい、不正利用・二次被害は公表時点で確認されていない。原因・脆弱性詳細は調査中で、特定CVEの悪用は未確定。
推奨対応
利用者は公式の案内を確認し、なりすまし連絡に注意する。Web運営者は共通IDへの接続権限、サービスを停止する単位、データ項目ごとの調査状態、利用者通知と再開条件を点検する。後半は本サイトの実務提案。
公表日

目次

スポンサーリンク

10月19日の公表で判明したこと

エイチ・ツー・オー リテイリングと阪急阪神百貨店は2026年10月19日、予約サイトなどへの不正アクセスを公表しました。顧客管理システムのH2O ID約126万件について、個人情報の一部の漏えいが判明したとしています。約126万件のすべての項目が漏れた、あるいは重複のない126万人と確定した、という意味へ広げないことが重要です。

本記事の公表日・情報確認日は10月19日です。会社側が不正アクセスを確認した日は16日と17日であり、攻撃が始まった日時まで確定したものではありません。確認できた時系列と、Web運営者向けの本サイトの提案を分けて整理します。

出典:エイチ・ツー・オー リテイリング・阪急阪神百貨店|2026年10月19日の公式発表(PDF)

停止したサービスと調査の範囲を分ける

公式発表によると、16日に予約サイト経由の顧客管理システムへの不正アクセスを確認し、通信遮断と同サイトの停止を実施しました。17日にはHANKYU HANSHIN E-STORESとRemo Orderでも不正アクセスを確認し、両サイトを停止しています。

対象として示された情報には氏名、連絡先、住所、生年月日などがあります。一方、通販・Remo Order側の注文履歴、カード情報の一部、アドレス帳などの漏えい可能性は調査中です。ログインパスワードの漏えいと、本件に起因する不正利用・二次被害は確認されていないと説明されています。

カード番号全桁とセキュリティコードは保持していないという説明もあります。ただし、これを個人情報の二次利用まで含めて危険がないという意味にはしません。原因や脆弱性の詳細も調査中であり、特定のCVE、攻撃者、ランサムウェア、AI悪用を本記事で断定する根拠はありません。

出典:エイチ・ツー・オー リテイリング・阪急阪神百貨店|2026年10月19日の公式発表(PDF)

スポンサーリンク

共通IDの便利さと接続権限は別の設計課題

ここからは、本事案の内部構成を断定する説明ではなく、共通IDを扱うWeb運営者への本サイトの提案です。一つの会員基盤を複数サービスから使える仕組みでは、ログインの利便性だけでなく、どのサービスがどのデータへ到達できるかを管理する必要があります。

仮想例として、予約サイト、通販、問い合わせサイトが同じ顧客情報を参照する構成を考えます。予約の確認に必要なのは会員の識別子と連絡先の一部なのに、実装上は広いプロフィールへアクセスできる状態なら、必要な業務と与えた権限の間に差があります。これは今回の原因として判明したことではなく、自社を点検するための例です。

接続元のサービスごとに、利用するAPI、認証情報、参照・更新する項目、管理担当を一覧化します。人の管理者アカウントだけでなく、サービス間の接続アカウントも対象です。使わなくなった接続や検証環境の権限が残っていないかも確認してください。

共通IDで認証できることと、顧客情報を一括取得してよいことは同じではありません。個別サービスに必要な操作へ権限を絞り、一つの接続の停止や認証情報の更新を、他のサービスから切り離して実施できるかを検討します。障害時に何を止められるかという観点も、安全性の設計に含まれます。

サービス停止では入口だけでなく裏側の通信も確認する

本サイトが提案する初動の確認は、トップページを閉じたかという一点だけではありません。Web画面、API、バックグラウンド処理、外部事業者からの通知などを分け、それぞれ現在も通信するかを確認します。利用者向けの画面が停止中でも、裏側の連携が動いている構成はあり得ます。

ただし、すべてを一律に遮断すればよいとは限りません。例えば決済の結果通知や、処理中の注文を確定する通信を止めると、業務上の不整合が生じる可能性があります。何を遮断し、何を監視下で維持するかを、システム担当だけでなく注文・決済担当と合わせて判断します。

作業票には、止めた接続、止めた時刻、判断者、影響する業務を残します。「サイトを止めた」という一文だけでは、後から調査範囲や利用者への案内を組み立てられません。確認できていない通信は未確認として残し、停止済みの一覧へ混ぜないことが大切です。

今回の会社発表が示す停止順序は、公表された対応の時系列です。そこから、同じ認証情報を使っていた、横展開で侵入された、といった内部の手口を推定して確定事項にしないでください。防御の点検に活用することと、他社の未公表の原因を断定することは別です。

スポンサーリンク

調査結果はデータ項目ごとの状態で管理する

本サイトの提案として、影響調査は会員数だけでなく、データの項目とサービスを単位に整理します。「保持していた」「アクセス可能だった」「取得を確認した」「調査中」を同じ状態として扱わないようにします。保持しているという事実だけで漏えいを確定できず、取得記録がないというだけで漏えいを否定できるとも限りません。

例えば、調査担当が確認した内容を広報へ渡す際は、対象のシステム、項目、期間、確認に使った記録、判断時点をセットにします。単に「会員情報」と伝えるより、後から情報が増えたときに何を更新すべきかが明確になります。これは公表を遅らせるためではなく、確認した範囲を正確に伝えるための整理です。

ログ、データベースの監査記録、構成変更、連携先のアクセス記録は、時刻の基準も合わせて保全します。外部サービスがUTC、自社の業務記録が日本時間の場合は、原記録を残したうえで対応関係を整理します。時差を攻撃の前後関係と取り違えないようにしてください。

問い合わせ対応に新たな個人情報が集まることも想定します。本人確認の名目で必要以上の情報やカード情報を受け取らないよう、窓口へ渡す質問項目と保存先を決めておきます。調査資料を共有する際も、閲覧できる担当と保管期間を管理する必要があります。

利用者向け通知では新しい詐欺の入口を作らない

会社側は、同社を装う不審なメール、SMS、電話やURLに注意するよう呼びかけています。利用者は届いた連絡だけを根拠に操作せず、普段使う公式サイトや保存済みの正規の入口から案内を確認する方法が安全です。送信者名や表示されたメールアドレスが一致することだけで、正当な連絡とは判断しないでください。

出典:阪急阪神百貨店|お客様向けのお知らせ(PDF)

自社の通知とアカウント対策を点検する

ここからは通知する側への本サイトの提案です。通知には、分かったこと、分かっていないこと、利用者に求める操作、正規の問い合わせ方法を分けて記載します。調査中の項目を無理に言い切らず、更新日を付け、過去の案内と何が変わったかを追えるようにします。

パスワード変更や認証操作を案内する必要がある場合は、その理由と対象を明確にします。単に不安をあおってメール内のボタンから急いで入力させる案内は、フィッシングとの区別を難しくします。正規のサービス画面から手続きへ進める導線と、利用者が疑問を確認できる窓口を用意します。

一般的な不正ログイン対策として、IPAはパスワードの使い回しを避けることと、多要素認証の設定を勧めています。これは本件でパスワード流出が確認されたという意味ではなく、独立したアカウント保護の対策です。利用するサービスが提供する方法を、公式の説明で確認してください。

Web運営者は、利用者へ対応を求めるだけでなく、問い合わせを受ける担当にも同じ説明を共有します。窓口によって漏えいの確定範囲や再開見込みの説明が異なると、利用者はどの情報を信じればよいか分からなくなります。案内の原稿と更新履歴を一本化する運用が役立ちます。

出典:IPA|不正ログイン対策特集ページ

再開条件は画面の復旧より広く定める

以下は本サイトが提案する再開前の確認です。接続経路の見直し、必要な修正の反映、認証情報の扱い、監視の準備、業務データの整合性を、それぞれ誰が確認するか決めます。保守会社から復旧完了という報告を受けても、対象に何が含まれるのかを具体化してください。

予約や通販では、停止前に処理中だった注文、通知できなかった連絡、外部決済側の結果などを照合します。画面が表示され、テスト注文が一件通ったことだけでは、停止期間をまたぐ業務の整合性まで保証できません。必要な試験を、機密情報を含まない検証データと承認された方法で行います。

再開後は、エラーや異常なアクセス、問い合わせの増加を確認する担当を置きます。問題が見つかったときの再停止条件と連絡先も決めておけば、公開を急いで判断の責任が曖昧になることを避けられます。過去のデータの調査と、再開後の監視も別の作業として継続します。

スポンサーリンク

原因を補わず次の公式更新を確認する

本事案の原因や詳細な手口は調査中です。現時点の公表内容から、自社にも同じ欠陥があるとは断定できません。一方、共通IDを使うサービスの接続権限、停止できる単位、データ項目ごとの調査、利用者への案内は、今から点検できる実務上の論点です。

本記事は10月19日に確認できた発表に基づきます。利用者向けの最新案内は公式資料と公式サイトで確認してください。新たな調査結果や再開情報を、初回発表時点で分かっていた事実のように混ぜず、日付と確認範囲を分けて判断することが重要です。

出典・一次情報

本記事は以下の公開情報をもとに作成しています。最新の状況は各リンク先で確認してください。

この記事を書いた人

Ryohei

Webエンジニア / アプリ開発者 / 技術ブログ運営者

福岡のWeb制作会社に勤務するWebエンジニアです。10年以上にわたりWeb制作・開発に携わり、これまでに100以上のWordPressサイトの構築・保守を担当してきました。Webサイト制作に加え、アプリ開発やAIを活用した開発にも取り組み、近年はWebセキュリティにも注力しています。

2015年から技術メディア「Into the Program」を運営し、実務や開発で得た知識をもとに、プログラミングの実装方法やWebサイトの運用・セキュリティ情報を発信しています。

主な分野
WordPress / PHP / JavaScript / アプリ開発 / Webサイトの運用・セキュリティ対策
資格・試験合格
情報セキュリティマネジメント試験
基本情報技術者試験
AWS認定ソリューションアーキテクト アソシエイト
PHP8技術者認定ウィザード
メディア運営
2015年〜

記事の作成・更新について

セキュリティ記事は、ベンダーの公式アドバイザリやCVE・JVNなどの一次情報を参照し、出典と情報確認日を記載します。実環境での検証を行った場合は、その環境と確認範囲を明示します。重要な追加情報や誤りを把握した場合は、内容を確認して追記・訂正します。

あわせて確認したい対策・解説

スポンサーリンク

関連する記事

おすすめの書籍

キーワードから探す