--- title: "オズモールの不正アクセスと最大44万件のメールアドレス｜海外からの大量アクセスを止める設計" url: "https://www.issoh.co.jp/tech/details/18140/" published: 2026-10-06 updated: 2026-10-06 categories: ["セキュリティ"] publisher: "株式会社一創" --- # オズモールの不正アクセスと最大44万件のメールアドレス｜海外からの大量アクセスを止める設計 スターツ出版は2026年9月27日、同社が運営するWebサイト「オズモール（OZmall）」で海外からの大量の不正アクセスを検知し、会員のメールアドレスなどが第三者に閲覧された可能性があると公表しました。10月1日の第2報では対象が最大442,779名分に精査され、一部の退会者が含まれることも明らかになりました。本記事では2本の公式発表をもとに経過と対象を整理し、会員が今日やる点検をまとめます。後半では、会員ページやAPIへの大量アクセスを止めるレート制限と、アクセスログから兆候を拾う集計を、そのまま試せる設定とコマンドで示します。 ## まとめ：オズモールの不正アクセスで確定した事実と利用者・開発者が今やること 公式発表で確定しているのは、2026年9月26日に海外からの大量の不正アクセスを検知したこと、閲覧された可能性があるのはメールアドレスと一部利用者の氏名・住所の都道府県までであること、対象が最大442,779名分であることです。電話番号と番地以降の住所には閲覧の形跡がなく、クレジットカード情報は外部の決済システムを使っているため対象外とされています。一方、どのページのどの脆弱性が使われたのかは公表されていません。 会員がまず備えるのは、オズモールやスターツ出版を装う不審なメールへの対応です。開発者の側で見るべき論点は、大量のアクセスが来たときに会員情報を返すページがどこまで応じてしまうかという点です。一度に返す件数や、同じ送信元からの要求回数に上限があるかを、自社のサイトに引き寄せて点検できます。 | 項目 | 公表されている内容 | | ------ | ----------------- | | 検知日 | 2026年9月26日 | | 公表日 | 第1報9月27日・第2報10月1日 | | 件数 | 最大442,779名分 | | 閲覧の可能性 | メールアドレス等 | | 一部の利用者 | 氏名・都道府県 | | 対象外 | 電話番号・番地・カード情報 | | 侵入の手口 | 未公表 | ## 公表内容を時系列で確認する｜9月26日の検知から10月1日の第2報まで ### 海外からの大量の不正アクセスを検知して該当ページを止めるまでの経過 [スターツ出版の第1報（2026年9月27日）](https://starts-pub.jp/info20260927)によると、同社のシステム部門が9月26日、オズモールに対して海外から大量の不正アクセスが発生していることを検知しました。同社は該当ページへのアクセスを一時停止し、調査の結果、会員の個人情報が閲覧された可能性があると判断しています。原因を特定して不正アクセスを遮断するシステム修正を行い、プログラムの改ざんなどの被害がないことも確かめたうえでサービスを再開したと説明しています。 第1報の時点で示された件数は、メールアドレス最大447,610名分でした。検知から公表までは1日です。大量のアクセスという量の異常から侵害に気付き、ページ単位で止めた流れは、監視の仕組みが働いた例として読めます。ログのどこを見て侵害を確かめるかは[不正アクセスのログ確認・解析方法](https://www.issoh.co.jp/tech/details/2788/)で整理しています。 ### 10月1日の第2報で精査された件数と退会者が含まれていた理由 [10月1日の第2報](https://starts-pub.jp/info20261001)では、対象がオズモール会員と一部の退会者を合わせた最大442,779名分に精査されました。退会者の情報は、取引上の履歴管理のため一定期間保存していたものと説明されています。9月28日には個人情報保護委員会へ報告したとしています。 第2報には、不正アクセスの原因を特定したうえで「当該脆弱性」への対策を実施したという記述が加わりました。原因が何らかの脆弱性であったことは読み取れますが、その中身は示されていません。今後は外部の専門機関と連携し、セキュリティ対策と監視体制を強化するとしています。 ### 手口が未公表の段階で公式発表から読み取れる構図と書けないこと 2本の公表文が示すのは、海外からの大量のアクセス、該当ページの停止、脆弱性への対策、閲覧の可能性という事実です。どのページが狙われたのか、認証を経ずに見られたのか、一度に何件ずつ取得されたのかには触れていません。 そのため本記事では、特定の脆弱性の種類に結び付けた推測はしません。読み取れるのは、多数の要求に応じて会員情報を返し続けたページがあったという構図です。後半で扱う設計の話は、この構図を前提に、どのサイトにも当てはまる点検項目として書いています。 ## 閲覧された可能性がある情報｜メールアドレスと氏名・都道府県で起きる悪用 ### 電話番号と番地以降の住所やカード情報が対象外とされた公表文の根拠 公表文は、電話番号と番地を含む詳しい住所について閲覧された形跡は確認されていないとしています。クレジットカード情報は外部の決済システムを使っており、オズモール側には保存していないため漏えいの可能性はないという説明です。決済を外部に任せる構成が、侵害時の到達範囲を狭めた形です。 ただし、対象外とされた項目が今後の調査で変わる可能性は残ります。第1報から第2報で件数と対象の範囲が見直されたように、続報で内容が更新されることがあります。最新の内容は公式サイトのお知らせで確かめてください。 ### 氏名と都道府県が付いたメールアドレスの一覧に攻撃者が見出す価値 メールアドレスだけの一覧と比べ、氏名と都道府県が付いた一覧は偽メールの説得力を上げます。宛名に本名を入れ、居住地域に合わせた店舗やイベントの話題を添えれば、無差別に送るメールより開かれやすくなります。オズモールの会員として登録されていたこと自体も、差出人を偽装するときに材料となる情報です。 想定される悪用は、偽のログイン画面に誘導するフィッシング、予約やポイントを名目にした詐欺、他サービスでの使い回しパスワードを狙った不正ログインの足掛かりです。パスワードが閲覧されたとは公表されていないため、オズモールのアカウントがそのまま乗っ取られる状況ではありません。手口の全体像は[フィッシング詐欺とは](https://www.issoh.co.jp/tech/details/13548/)で解説しています。 | 想定される悪用 | きっかけ | 利用者側の防ぎ方 | | ------- | ----------- | ------------ | | 偽ログイン画面 | オズモールを装うメール | メールのリンクを使わない | | 予約名目の詐欺 | 宛名入りの連絡 | 公式サイトで確認する | | 不正ログイン | パスワードの使い回し | 他サービスを変更する | | 迷惑メール増加 | 名簿の転売 | 受信設定で振り分ける | ## オズモール会員が今日やる点検手順｜不審なメールの見分け方と問い合わせ先 ### スターツ出版から対象会員への連絡方法と公表文が呼びかけている注意点 スターツ出版は、対象者には会員登録時のメールアドレス宛てに順次連絡するとしています。メールが届かない場合は、第2報の公表をもって通知に代えるという説明です。退会してアドレスを使っていない人は、連絡が届かないまま対象になっている可能性があります。 第2報は、同社や実在する企業・団体を装った不審なメールが届く可能性に触れ、添付ファイルの開封やリンクのクリックをしないよう呼びかけています。判断は、メールの中のリンクや電話番号を使わず、自分でオズモールやスターツ出版の公式サイトを開いて確かめる、の一点に絞ると迷いません。問い合わせ窓口は同社管理部の電話（03-6202-0390・平日10時から17時）とサイトの問い合わせフォームです。不審なメールは[フィッシング対策協議会](https://www.antiphishing.jp/)のサイトで同じ文面の事例を探せます。 ### 同じメールアドレスで登録した他サービスを優先度に沿って確認する順番 メールアドレスや氏名が知られても、それだけで他サービスに入られることはありません。危ないのは、同じアドレスと同じパスワードの組み合わせを複数のサービスで使っている場合です。過去に別のサービスから漏れたパスワードと今回の一覧が突き合わされると、不正ログインを試される材料になります。 変更の優先度は、パスワード再設定の受け口になるメールアカウント、決済や送金に関わるサービス、予約やポイント系のサービスの順です。あわせて二要素認証を有効にしておくと、パスワードが知られても単独では入れなくなります。自分のアドレスが過去の流出に含まれていないかを調べる方法は、[流出チェックの方法](https://www.issoh.co.jp/column/details/3085/)でまとめています。 ## 大量アクセスで会員情報が抜かれる構図｜回数と件数に上限のないページ ### OWASP API Security Top 10が挙げる上限の欠落と認可の欠陥 今回の手口は公表されていませんが、大量の要求で会員情報が取得される事故には典型的な型があります。[OWASPのAPI4:2023](https://api-security.owasp.org/editions/2023/en/0xa4-unrestricted-resource-consumption/)は、1回の要求で返すレコード数や、クライアントがAPIを呼べる頻度に上限がない状態をリスクに挙げ、クライアントごとのレート制限と、1人の利用者が同じ操作を実行できる回数の制限を対策に示しています。 もう一つの型が、[API1:2023のオブジェクトレベル認可の不備](https://api-security.owasp.org/editions/2023/en/0xa1-broken-object-level-authorization/)です。URLやパラメータの会員番号を書き換えると他人の情報が返る状態で、番号を順に変えながら大量に要求すれば一覧が作れます。認可の不備は本来サーバ側の判定で止めるもので、仕組みと実装は[認可バイパスとは（IDORと権限昇格）](https://www.issoh.co.jp/tech/details/16399/)で詳しく扱っています。10項目の全体像は[OWASP API Security Top 10 2023の全10項目](https://www.issoh.co.jp/tech/details/4704/)を参照してください。 ### 認可を直してもレート制限を重ねて置く理由と被害の上限の考え方 認可の判定に穴がなければ、他人の情報は1件も返りません。それでもレート制限を重ねる理由は、穴が見つかったときの被害の上限を決められるからです。1つの送信元が1分間に取得できる件数に上限があれば、仮に認可の不備が残っていても、数十万件を短時間で持ち出す攻撃は成立しにくくなります。 オズモールの件でも、対処の起点となったのは、大量のアクセスに気付いて該当ページを止めたことです。量の異常を自動で抑える仕組みと、量の異常を人が知る仕組みの両方があれば、止めるまでの時間を短くできます。レート制限の方式ごとの違いは[APIレート制限とは（5方式の比較と429設計）](https://www.issoh.co.jp/tech/details/16179/)で比べています。 ## 会員ページにレート制限を置く｜nginxとAWS WAFで大量アクセスを止める設定 ### nginxのlimit\_reqで会員APIへの要求をIPごとに絞る設定例 アプリの前段にnginxを置いている場合、[ngx\_http\_limit\_req\_module](https://nginx.org/en/docs/http/ngx%5Fhttp%5Flimit%5Freq%5Fmodule.html)でIPアドレスごとの要求頻度を制限できます。次は会員情報を返すパスだけに制限をかける例です。 ``` # 会員情報を返すパスだけ、IPごとに毎秒2件まで（nginx） http { # 状態の保存に10MBを確保する（1MBで約1万6千件の状態を保持できる） limit_req_zone $binary_remote_addr zone=member_api:10m rate=2r/s; limit_req_status 429; server { location /api/member/ { # 短い連続アクセスは10件まで受け、それを超えたら拒否する limit_req zone=member_api burst=10 nodelay; proxy_pass http://app_backend; } } } ``` 公式ドキュメントでは、制限を超えた要求に返すステータスコードの既定値は503です。上の例では`limit_req_status`で429に変えています。503のままだと障害と区別しにくく、監視の集計で攻撃と気付きにくくなるためです。 IPごとの制限は、送信元を大量に入れ替える攻撃には効きにくい点に注意が必要です。ログイン後のページなら、IPではなく会員IDやセッション単位で数える制限をアプリ側に足すと、送信元を変えても同じアカウントからの大量取得を抑えられます。 ### AWS WAFのレートベースルールで会員ページへの要求を数えるJSON AWSのCloudFrontやALBの前段で守る場合は、[AWS WAFのレートベースルール](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)が使えます。[公式ガイドの設定項目](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based-high-level-settings.html)によると、評価期間は60・120・300・600秒から選び、既定は300秒、制限値の下限は10です。次は、[ログインページを対象にした公式の例](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rate-based-example-limit-login-page.html)を会員APIのパスとIP単位の集計に置き換えた設定です。 ``` { "Name": "member-api-rate-limit", "Priority": 10, "Action": { "Count": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "member-api-rate-limit" }, "Statement": { "RateBasedStatement": { "Limit": 100, "EvaluationWindowSec": 60, "AggregateKeyType": "IP", "ScopeDownStatement": { "ByteMatchStatement": { "FieldToMatch": { "UriPath": {} }, "PositionalConstraint": "STARTS_WITH", "SearchString": "/api/member/", "TextTransformations": [ { "Type": "NONE", "Priority": 0 } ] } } } } } ``` 最初は`Count`で入れ、CloudWatchのメトリクスで正規の利用者がどの程度引っかかるかを数日見てから、`Block`に切り替えます。公式ガイドは、WAFは設定した値の近くで制限をかけるものの、ぴったりの値で止まることは保証しないと注意しています。制限値は余裕を持たせて決めてください。WAFそのものの役割は[WAFとは](https://www.issoh.co.jp/tech/details/13275/)で、ボットによる機械的なアクセスの見分け方は[機械生成トラフィックとは](https://www.issoh.co.jp/column/details/8122/)で整理しています。 ### アクセスログからIPごとの件数と異なるURLの数を集計するコマンド 制限を入れる前に、今のアクセスにどの程度の偏りがあるかを測っておくと、制限値を決めやすくなります。次はnginxの標準形式（combined）のログから、会員APIへの要求をIPごとに数え、件数と異なるURLの数が多い順に並べるコマンドです。 ``` # 会員APIへの要求をIPごとに集計する（件数・異なるURL数・IPの順に出力） awk 'index($7, "/api/member/") == 1 { n[$1]++ k = $1 " " $7 if (!(k in seen)) { seen[k] = 1; u[$1]++ } } END { for (ip in n) print n[ip], u[ip], ip }' /var/log/nginx/access.log \ | sort -rn | head -20 ``` 件数が多いだけなら、アプリの自動更新や社内の監視の可能性もあります。注目したいのは、件数とほぼ同じだけ異なるURLを要求しているIPです。会員番号を順に変えて取得している場合、この形になります。こうした送信元が海外のIPに偏っていないかを、別途IPの地域情報と突き合わせて確かめます。 ## 退会者のデータを持ち続けない｜保存期間を決めて侵害時の到達範囲を減らす ### 個人情報保護法22条とガイドライン3-4-1が求める不要データの消去 第2報で、退会者の情報が取引上の履歴管理のため一定期間保存されていたことが示されました。履歴を残す理由そのものは多くの事業者に共通します。一方で[個人情報保護委員会のガイドライン（通則編）](https://www.ppc.go.jp/personalinfo/legal/guidelines%5Ftsusoku/)3-4-1は、法22条に基づき、利用する必要がなくなった個人データは遅滞なく消去するよう努めることを求めています。 保存を続けるなら、何のために、いつまで持つかをあらかじめ決めておく必要があるのです。履歴管理が目的なら、照合に要る取引番号や日時は残しつつ、メールアドレスや氏名は期限を過ぎた時点で消すか、本人を特定できない形に置き換える方法が取れます。退会者の本人確認書類まで残っていた[タイムズカーの不正アクセス](https://www.issoh.co.jp/tech/details/17925/)や、送れないアドレスの一覧が狙われた[東京メトロ（メトポ）の不正アクセス](https://www.issoh.co.jp/tech/details/18095/)とも、消さずに残した情報が被害を広げた点で共通しています。 ### 保存期間の短縮とレート制限を採用する条件と後回しにしてよい場面 会員数が数万を超える、会員情報を返すAPIやマイページを外部に公開している、退会者の情報を期限を決めずに保存している、の三つのうち一つでも当てはまる場合は、レート制限と保存期間の見直しを同時に進める価値があります。どちらも、侵害が起きたときに持ち出される件数の上限を下げる対策だからです。 反対に、会員情報を返す画面が管理者向けの社内システムに限られ、外部から到達できない構成であれば、レート制限の優先度は下がります。その場合でも、退会者データの保存期間は事故の規模を左右するため先に決めておくべきです。スマホアプリのAPIまで含めた認可の点検手順は[セイコーマートの不正アクセス](https://www.issoh.co.jp/tech/details/18093/)の解説が参考になります。 ## 漏えい時の報告と次の侵害への備え｜速報・確報の期限と第三者による点検 ### 不正アクセスによる漏えいで報告対象になる事態と速報・確報の提出期限 [個人情報保護委員会の案内](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、報告の対象は要配慮個人情報の漏えい等、財産的被害のおそれがある個人データの漏えい等、不正の目的をもって行われたおそれがある行為による漏えい等、本人の数が1,000人を超える漏えい等（民間事業者）の四類型です。速報は発覚から3〜5日以内、確報は30日以内、不正目的の場合は60日以内とされています。 オズモールの件は、9月26日の検知から2日後の9月28日に報告したと公表されており、件数と不正アクセスの両面で対象に当たる事案です。類型の見分け方と速報の書き方は[個人情報保護委員会への報告義務](https://www.issoh.co.jp/column/details/17840/)で詳しく解説しています。 ### 次の侵害に備えて自社の会員サイトを点検する順番と依頼先の選び方 点検は三つの順で進めます。最初に、会員情報を返すページとAPIを洗い出し、1回の要求で返す件数と、他人の番号を指定したときの応答を確かめます。次の確認対象は、それらのパスにIPと会員単位のレート制限があるか、超えたときに監視へ通知が飛ぶかという点です。最後に、退会者を含めて保存している会員情報の項目と期限を棚卸しします。会員を装うなりすましメールへの備えとしては、[DMARCの設定](https://www.issoh.co.jp/tech/details/12267/)で自社ドメインの偽装を受信側に拒否させる方法もあります。 外部からの入口と、破られた後に何が読めるかを第三者の目で確かめたい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で、会員ページやAPIの認可とレート制限の有無を含めて点検できます。 ## よくある質問 オズモールの不正アクセスについて、利用者と開発者から出やすい質問をまとめました。 ### オズモール会員のどの情報が閲覧された可能性がありますか？ 公表文によると、閲覧された可能性があるのはメールアドレスと、一部の利用者の氏名・住所の都道府県までで、対象は最大442,779名分です。電話番号と番地以降の住所には閲覧の形跡がなく、クレジットカード情報は外部の決済システムを使っているため対象外とされています。 ### 退会済みでも対象になることはありますか？ あります。第2報で、取引上の履歴管理のため一定期間保存していた一部の退会者の情報も対象に含まれると説明されました。連絡は会員登録時のメールアドレス宛てに順次送られ、送れない場合は公表をもって通知に代えるとされています。気になる場合は、公式の問い合わせ窓口で確認してください。 ### オズモールのパスワードは変更したほうがよいですか？ パスワードが閲覧されたとは公表されていません。ただし、同じメールアドレスとパスワードの組み合わせを他のサービスでも使っている場合は、不正ログインの材料になりえます。使い回しがあるなら、他サービス側を先に変更し、二要素認証を有効にしてください。 ### 不審なメールが届いたらどうすればよいですか？ 添付ファイルを開かず、リンクもクリックしないでください。スターツ出版も第2報でその旨を呼びかけています。内容を確かめたいときは、メールの中の連絡先ではなく、自分で開いた公式サイトの問い合わせ窓口を使います。宛名に本名が入っていても、本物と判断する根拠にはなりません。 ### 自社の会員サイトは何から見直せばよいですか？ 最初に、会員情報を返すページとAPIで、他人の会員番号を指定したときに情報が返らないかを確かめてください。次に、同じ送信元や同じ会員からの要求回数に上限を設け、超えたときに通知が届くようにします。あわせて、退会者の情報をいつまで保存するかを決めておくと、侵害時の被害を小さくできます。 ## 関連記事 - [東京メトロ（メトポ）の不正アクセスと約5.9万件のメールアドレス｜配信停止リストを残さない設計](https://www.issoh.co.jp/tech/details/18095/)：同じ9月27日に公表されたメールアドレスの流出事例 - [タイムズカーの不正アクセスと免許証画像160万件の流出｜退会者まで残さない保管設計](https://www.issoh.co.jp/tech/details/17925/)：退会者のデータが残っていた事例 - [セイコーマートの不正アクセスと57万人の会員情報｜アプリAPIの認可を点検する手順](https://www.issoh.co.jp/tech/details/18093/)：会員APIの認可を点検する手順 - [APIレート制限（レートリミット）とは？5方式の比較と429設計・分散実装【2026年版】](https://www.issoh.co.jp/tech/details/16179/)：レート制限の方式と実装の比較 - [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：漏えい時の報告の段取り --- 出典: [オズモールの不正アクセスと最大44万件のメールアドレス｜海外からの大量アクセスを止める設計]()（株式会社一創）