レイズクロス Tech Blog

サイバー攻撃事件簿：「快活CLUB」 サイバー攻撃

投稿更新日: 2025/12/7

#セキュリティ
サムネイル

このブログで、不定期連載で、「サイバー攻撃事件簿」と題し、サイバー攻撃に関するニュースを取り上げ、事件の内容と、どんな対策有効なのかを啓発していきます。大阪の高校生（17歳）を警視庁が逮捕としたとの報道が衝撃的な 「快活CLUB」サイバー攻撃について深堀りします。

1) 何が起きたのか（タイムライン）

2025年1月18日（土）夕刻

  • 快活フロンティアのサーバーで不正アクセスを検知。ネットワークから切り離し等の初動対応を実施。

2025年1月20日（月）

  • 会社として対策本部を設置、会員アプリの一部機能を停止。

2025年1月21日（火）〜

  • 親会社AOKI HDからも「不正アクセスと個人情報流出の可能性」を公表。個人情報保護委員会へ報告。以後、断続的に続報を公表。

2025年2月中旬

  • 外部専門機関の調査結果を受領。会員アプリは2/19〜2/28にかけて順次再開。

2025年3月17日（月）

  • 調査完了の報告。最大7,290,087件の会員情報が「漏えいの可能性」。ただしクレジットカード、身分証画像、メールアドレス、会員アプリのパスワードは含まれず。二次被害も当時は未確認。

2025年12月4日（木）

  • 大阪の高校生（17歳）を警視庁が逮捕との報道。独自プログラムを作成し、アプリのサーバーに1月18〜20日にかけて繰り返し不正コマンドを送信し、約725万件の会員情報を取得した疑い。生成AI（ChatGPT）を使って作成したプログラムと報じられた。

（プレスリリース）

2) 被害状況（公表ベースの確定情報）

対象者

  • 2015/10/1〜2025/1/20に来店実績のある快活CLUB会員の一部、2019/3/25〜2025/1/20の仮会員の一部、FiT24/インドアゴルフの会員の一部。

流出の可能性がある項目

  • 氏名（カナ含む）、性別、郵便番号・住所、電話番号、生年月日、会員番号、会員種別/ステータス、保有ポイントと有効期限、店舗コード、最終会計日時、バーコード、プッシュ通知希望、クーポンメッセージ。件数：7,290,087件。

流出していない項目

  • 身分証情報、クレジットカード情報、メールアドレス、会員アプリのパスワードは対象外。

二次被害

  • 3/17時点の同社公表では「確認されず」。

3) 報道から読み取れる技術的な示唆（公表されていない可能性のある課題）

※以下は公式に技術詳細が開示されていないため推測を含む。逮捕報道の「繰り返し送信」「プログラム作成」「会員情報の大量取得」というキーワードから、次の課題があり得ると考えられます。

1.API/BFFのアクセス制御の粗さ（BOLA/IDOR）

  • 認証済みでも本来アクセス権のない他人の会員レコードに到達できる欠陥（Broken Object Level Authorization）。通し番号や会員IDを総当たりで引ける設計だと、スクリプトで大量取得が成立しやすい。

2.レートリミット/行動検知の不足

  • 短時間に数十万〜数百万回の同一操作が成立したなら、IP/トークン単位のレート制限や振る舞い分析（UEBA）、WAFのアノマリ検知が弱かった可能性。報道は「繰り返し送信」に言及。

3.過大なデータ露出（Excessive Data Exposure）

  • 1 API呼び出しで氏名・住所・生年月日・ポイント等がまとめて返ってしまう設計だと、漏えいの“価値/密度”が高くなる。

4.監視は働いたが封じ込めに時間

  • 1/18の検知→切断→調査→2/下旬にサービス再開の流れから、検知自体はできたが、根絶と影響範囲の特定に時間がかかったことがうかがえる。

5.データ最小化/匿名化の不足

  • ポイントや最終会計日時など、業務には必要でも個人特定リスクを上げる属性がAPIレスポンスに含まれていた可能性。

4) このニュースから私たちが学ぶべきこと（実務チェックリスト）

API設計 & アプリ層の防御

BOLA/IDOR対策

  • オブジェクト参照ごとに権限チェック（ユーザー/テナント境界）をミドルウェアで強制。

最小権限 & データ最小化

  • APIレスポンスは業務に必須の属性だけに削る。PIIはマスキング/トークン化。

レート制限とスロットリング

  • IP・ユーザー・アクセストークン・デバイス指紋の多次元レート制限。急増時は段階的に403/429やCAPTCHA/追加認証へ。

アプリ層の振る舞い検知

  • 短時間の高頻度アクセスやID連番スキャン、異常な検索パターンを検知→自動遮断。

過大レスポンス禁止

  • GraphQL/RESTともフィールド選択をサーバー側で制御、不要フィールドは返さない。

運用 & 監視

攻撃面の観測性

  • WAF/CDNログ、APM、アプリ監査ログを相関可視化。集約ダッシュボードで“1ユーザーからのGET/POST急増”を即検知。

プレイブック整備

  • 検知→封じ込め→根絶→復旧→対外説明のRACI/連絡線を事前に合意。個人情報保護委員会報告の要否判断フローもテンプレ化。

データ保全と絞り込み

  • 全面停止の前に高リスクAPIだけを一時停止できるスイッチ（Feature Flag/ルーティング）を用意。

段階的停止

  • 「誰に・どのAPIで・何件返したか」**を問い合わせ単位で追跡できる監査ログの整備。

設計・ガバナンス

攻PIIの棚卸し

  • どの属性がどのAPIで露出するかを台帳化し、外部提供・内部利用を区分。

DevSecOps：APIセキュリティテスト（DAST/SAST/IAST）と権限テスト

  • （ABAC/RBAC/E2E）をCIに組込む。

生成AI時代の前提変更

  • スクリプト作成の参入障壁が下がり攻撃自動化が加速。**「高度なスキルがないと攻撃できない」**という前提は捨てる。逮捕報道も、AI支援でのプログラム作成に言及。

5) 経営・現場別の示唆

経営層

  • 個情委報告・警察連携・顧客通知までのリーガル/広報ラインを定例訓練。損失最小化より信頼維持をKPIに。

情報システム部門

  • API台帳と危険度マッピング（認証要・不要/返却PII量/書込権限）を四半期更新。

開発チーム

  • 権限テストの自動化と負荷試験×挙動検知をスプリント定例に。

店舗/CS

  • 顧客からの問い合わせに備えFAQ/スクリプトを常備。ポイント/会計履歴の問い合わせへの標準回答を整備。

6) 事例が示す“守るべきユースケース”

  • 連番IDを総当たりされても他人の情報が見えない（BOLA対策）。
  • 短時間の大量アクセスで自動遮断＋段階的追加認証。
  • APIレスポンスのデータ最小化で、漏えい時の実害を極小化。
  • 検知から復旧までのプレイブックが回る（社外公表・当局報告・顧客連絡まで一気通貫）。

7) 参考URL

この記事をシェアする

← 記事一覧に戻る

合同会社raisexでは一緒に働く仲間を募集中です。

ご興味のある方は以下の採用情報をご確認ください。

最新記事

タグ

LLM生成AIPythonRAGGit/GitHubブラウザセキュリティVPNTerraformCMSNext.jsAWSDatabaseTutorial設計DockerBackendDynamoDBFrontendReactクラウドInfo