速報

CROSS POINTで正規APIキーを悪用し会員情報取得|全導入企業のキーを再発行

CATEGORY

CROSS POINTで正規APIキーを悪用し会員情報取得|全導入企業のキーを再発行

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

店舗とECの会員情報連携で古いAPI認証キーを交換する概念イラスト

この記事のポイント

対象
CROSS POINT
影響
導入企業1社の一部会員情報を第三者がAPI経由で取得。対象人数とキー流出経路は未公表。
推奨対応
全導入企業のAPIキーは再発行済み。利用企業は公式案内と連携状態を確認する。
公表日

目次

アイルは2026年11月10日、ポイント・顧客情報管理サービス「CROSS POINT」の導入企業1社で、会員情報取得を通じて第三者が一部会員情報を取得したと公表しました。外部に流出した企業専用の正規APIキーが使われたとしています。全導入企業のは11月9日22時15分に無効化・再発行済みです。

利用企業とPOS・ECなどの連携システム担当者は、まず提供元から届く正式な案内と自社の接続状態を確認する必要があります。被害企業名や対象件数は今回の発表では示されていません。すべての導入企業で漏えいが起きたという発表ではなく、アイルは他社で情報漏えいの痕跡は確認していないと説明しています。

スポンサーリンク

検知は11月7日未明 公表と発生を分けて読む

アイルの公式発表によると、不正アクセスの検知は11月7日未明です。調査の結果、会員情報取得APIを使った情報取得を確認しました。11月10日は公表日であり、不正アクセスが始まった日や全情報が取得された日として扱うことはできません。

同社は内部への直接侵入や改ざん、プログラムのに起因するものではないと説明し、当該企業専用の正規キーの悪用を原因として挙げています。一方、キーが外部へ流出した経路は発表されていません。公開、委託先、端末感染などの具体的経路を推定する根拠はありません。

対象情報にはポイントと購買統計も含まれる

公表された対象項目は、氏名、生年月日、性別、郵便番号、住所、電話番号、携帯電話番号、メールアドレスと携帯メールアドレスです。会員番号、会員ランク、保有ポイント、実店舗カード番号、ネットショップ会員IDも含まれます。購買統計では累計購入金額、購入回数、初回・最終購入日などが挙げられています。

これらは発表された対象情報の種類であり、全会員について全項目が取得されたという意味ではありません。対象人数や各人の取得項目は、今後の影響範囲の調査と利用先企業の案内を待つ必要があります。保有ポイントが対象に含まれることと、ポイントの不正利用が確認されたことも別です。

クレジットカード情報とログインパスワードは、当該システムが保持しておらず流出対象外とアイルは確認しています。この事件だけを根拠にカード情報やパスワードの流出を断定したり、すべての利用者へ一律の再発行を求めたりする内容ではありません。

スポンサーリンク

全社のキーを交換した対応と残る確認

アイルは判明後、問題となったキーを直ちに無効化・再発行し、不正アクセス元を遮断しました。の詳細調査と監視強化も進めています。さらに同じ手口への対策として、被害が確認されていない利用企業を含め、全社のAPIキーを交換しました。

再発防止策には、APIの管理体制強化、定期的な、APIの最小化を挙げています。同社は事象への対策は完了したとする一方、当該企業と原因究明・影響範囲の調査を継続するとしています。遮断の完了と調査の完了を同じ意味で受け取らないことが重要です。

連携担当者と会員が確認すること

以下は公式発表の追加指示ではなく、本サイトの運用上の提案です。連携担当者は、新しいキーを受け取る正規の連絡経路と担当者を確認し、POS、EC、会員アプリ、定期バッチなどの接続先を棚卸しします。認証エラーがないことに加え、会員照会やポイント連携の業務結果を確認し、停止中の処理が残っていないかを調べます。

再実行が必要な場合、認証失敗の処理と、応答が不明でも実行済みかもしれない処理を分けてください。連携の回復を急いで更新操作を一括再送すると、二重処理の原因になり得ます。実際の再送可否は各システムの仕様と処理履歴で判断し、APIキーの値を調査用チケットや共有ログへ貼り付けない運用が必要です。

会員側では、利用先企業の公式サイトやアプリで通知を確認することを提案します。氏名やポイント残高を知っている相手からの連絡でも、それだけで正規と判断せず、普段の公式窓口から内容を照合してください。これは二次被害を避けるための一般的な提案で、今回、偽通知やポイント不正使用が発生したと確認されたという意味ではありません。

現時点で未公表なのは、被害企業名、対象件数、キーの流出経路、個別会員の具体的な影響です。新しい案内が出た際は、この四点と必要な利用者対応が変わったかを確認します。導入企業全体へのキー交換を、全社での漏えい確認と取り違えないことが今回の判断の要点です。

出典・一次情報

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

この記事を書いた人

Ryohei

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

福岡のWeb制作会社に勤務するWebエンジニアです。10年以上にわたりWeb制作・開発に携わり、ヒアリングや進行管理から、コーディング、CMSの構築、システム開発、サーバーの構築・保守・運用まで、Webサイト制作の工程を幅広く担当しています。Webサイトは、これまでに100以上の構築・保守を手がけてきました。

個人でもWebサイトの制作・改修やWebアプリの開発・運用を行い、AIを活用した開発にも取り組んでいます。近年はWebセキュリティにも注力しています。

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

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

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

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

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

関連する記事

おすすめの書籍

キーワードから探す

スポンサーリンク

アクセス権

ユーザーやプログラムが、ファイル・データ・機能などに対して何をしてよいかを定めた権限。読み取り・書き込み・実行などに分けて設定する。

詳しく見る

ローテーション

パスワードやAPIキー、鍵などを定期的または必要に応じて新しいものに作り直し、古いものを無効にすること。

詳しく見る

認証情報

本人であることを証明するための情報。IDとパスワード、APIキー、アクセストークン、秘密鍵など。

詳しく見る

アクセスログ

Webサーバーなどが、受け付けたリクエストを1件ずつ記録したログ。日時・接続元IPアドレス・URL・応答の状態などが残る。

詳しく見る

リポジトリ

ソースコードなどのファイルと、その変更の履歴をまとめて保管する場所。Gitで管理し、GitHubなどで共有する。

詳しく見る

脆弱性

ソフトウェアや設定の不備のうち、攻撃者に悪用されると情報漏えいや不正操作などにつながる弱点。

詳しく見る

データベース

データを決まった形式で整理して保存し、検索や更新をしやすくした仕組み。WordPressではMySQLやMariaDBを使う。

詳しく見る

APIキー

APIを利用するときに、利用者やアプリケーションを識別・認証するための文字列。漏えいすると不正利用につながる。

詳しく見る

認証

アクセスしてきた相手が本人であることを確かめる仕組み。パスワードや生体情報、電子証明書などを使う。

詳しく見る

API

ソフトウェアやサービスの機能を、ほかのプログラムから決まった方法で呼び出して使えるようにした窓口。

詳しく見る