--- title: "ショップサーブ情報漏えいの最終報：Eストアー約2,335万人・7,858店の対象確認とお詫びメールの見分け方" url: "https://www.issoh.co.jp/tech/details/16098/" published: 2026-08-03 updated: 2026-10-27 categories: ["脆弱性・インシデント"] publisher: "株式会社一創" --- # ショップサーブ情報漏えいの最終報：Eストアー約2,335万人・7,858店の対象確認とお詫びメールの見分け方 株式会社Eストアーは2026年10月16日、同社のECサイト構築サービス「ショップサーブ」への不正アクセスによる情報漏えいについて[最終報](https://estore.jp/press/20261016/)を公表しました。外部の専門機関によるフォレンジック調査を終え、漏えい対象者は約2,335万6,000人（名寄せ後の概数）、このうちカード情報の一部を含む人は約209万6,900人、対象店舗は7,858店と確定しています。原因は、サーバー上で動くアプリケーションの脆弱性を悪用されたことでした。8月の[第2報](https://estore.jp/press/20260802/)で示された延べ885万3839件は、調査途中の数字だったことになります。検索で多い問いは「どの店舗（ショップ・サイト）が対象なのか」と「Eストアーや店舗から届いたお詫びメールは本物か」の2つです。 先に答えると、最終報でも対象店舗の名前は公表されていません（2026年10月27日時点）。対象かどうかは、Eストアーからの個別連絡、出店企業が自社サイトで出した公表、そしてEストアーの問い合わせ窓口で確かめます。最終報の案内では、利用した店舗名の確認を希望する人も窓口への連絡が必要です。本記事では、最終報で確定した事実と第2報からの変更点、公表済みの出店企業7社の一覧、届いたメールを公式文言で見分ける手順を先に示し、後半でアプリケーションの脆弱性を突いた不正実行と外部送信を検知する技術対策、事業者が負う報告義務と基盤の継続判断を扱います。 ## まとめ：Eストアー（ショップサーブ）情報漏えいの最終報で購入者と店舗が確かめる要点 - **確定した規模**：2026年10月16日の最終報で、漏えい対象者は約2,335万6,000人、カード情報の一部（名義・先頭6桁・下4桁・有効期限）を含む人は約209万6,900人、対象店舗は7,858店。購入者・会員、店舗運営者、アフィリエイターを名寄せして集計した概数です。 - **原因**：2026年5月21日から8月1日まで、第三者がアプリケーションの脆弱性を悪用して不正なプログラムを実行し、データベースの情報を外部へ送信していました。ほかの経路での侵害やバックドアの設置は認められていません。 - **対象店舗**：店舗名の一覧は公表されていません（2026年10月27日時点）。対象店舗には現在の利用店舗と、過去に利用していた店舗の両方が含まれます。デザインフィル、ハリマ食品、日本製紙クレシア、キングジム、PFU、絵具屋三吉、マガジンハウスなどが自社サイトで個別に公表しています。 - **お詫びメール**：対象者への個別連絡は完了したとEストアーは書いています。同社は「クレジットカード情報の再入力や再決済をお願いすることはございません」「メールやSMS等でパスワードをお尋ねすることもございません」と明記しました。入力を求めるメールは、差出人名が何であっても応じないのが原則です。 - **対象から外れた項目**：第2報で挙がっていた店舗メールシステムのID・パスワード、FTPのID・パスワード、Eストアーからの振込先口座情報は、調査の結果、漏えい対象から除外されました。セキュリティコードと完全なカード番号は非保持で含まれません。 - **技術的な本質**：認可ロジックの欠陥ではなく、アプリケーションの脆弱性からサーバー上でコードを実行され、DBのデータを持ち出された事案。バックドアを残さない型だったため、実行の瞬間の検知と外向き通信の統制が防御の主戦場です。 - **事業者の対応**：管理画面の認証情報の入れ替えと二段階認証、購入者への告知、委託元としての個人情報保護委員会への報告判断を並行して進めます。基盤の移行は条件付きで判断します。 ## Eストアー最終報で確定した約2,335万人・7,858店・原因と第2報から外れた項目 最終報は「一連の調査が完了し、本件の攻撃手法、攻撃の期間、攻撃者の行動および漏えいの対象範囲が確定いたしました」と書き、本件の最終報告と位置づけています。第2報からの変化を先に表で示します。 | 項目 | 第2報（8月2日） | 最終報（10月16日） | | --------- | ----------- | ------------- | | 件数 | 延べ885万3839件 | 約2,335万6,000人 | | カード情報の一部 | 件数の記載なし | 約209万6,900人 | | 対象店舗 | 記載なし | 7,858店（店名非公表） | | 原因 | 外部からの不正アクセス | アプリの脆弱性の悪用 | | 店舗メール・FTP | 漏えい対象 | 対象から除外 | | 振込先口座 | 漏えい対象 | 対象から除外 | | 対象期間 | 5月21日〜8月1日 | 同左で確定 | ### 原因はアプリケーションの脆弱性悪用でバックドアの設置は無かったという調査結果 最終報によると、2026年5月21日から8月1日までの期間に、外部の第三者が「当社サーバー上で稼働するアプリケーションの脆弱性を悪用して不正なプログラムを実行し、データベースに格納された情報を外部へ送信していた」と確認されました。Eストアーが本件を認知した8月1日に攻撃元からの通信を遮断し、それ以降は攻撃が成立していないとしています。 技術的に注目したいのは、「上記の経路以外の侵害は認められず、バックドア等の不正なプログラムの設置も認められませんでした」という一文です。攻撃者は侵入口に居座るファイルを置かず、脆弱性を突くたびにプログラムを動かしてデータを持ち出していたと読めます。どのアプリケーションのどの脆弱性だったかは、最終報でも明かされていません。悪用された脆弱性は修正済みとされています。調査の進め方や、外部へ依頼するときの費用感は[フォレンジック調査の流れと依頼先の選び方](https://www.issoh.co.jp/column/details/2812/)で整理しています。 ### 約2,335万人と約209万人という最終報の件数を第2報の延べ885万件と比べる読み方 最終報の件数は、購入者・会員、店舗運営者、アフィリエイターを合算した人数です。複数項目の一致を基準に名寄せし、重複を可能な限り除いていますが、一致の基準に満たない重複は除けないため概数とされています。第2報の延べ885万3839件とは数え方も調査の進み具合も違うため、「人数が2.6倍に増えた」と単純には比べられません。確かなのは、第2報の数字は調査途中の値で、最終報の約2,335万6,000人が現時点で確定した規模だという点です。 カード情報の一部を含む約209万6,900人については、最終報が「今回漏えいした情報のみでは、クレジットカード決済を行うことはできません」と明記しました。会員の暗号化パスワードも、調査の結果「パスワードが特定される可能性は低い」と判断され、ログイン先の店舗を紐付ける情報も含まれていないことから、マイページへの不正アクセスの可能性は低いとされています。 ### 最終報で漏えい対象から外れた店舗メール・FTP・振込先口座と新たに加わった項目 店舗運営者にとって大きい変更は、第2報で挙がっていた「店舗メールシステムのログインID・パスワード、FTPのID・パスワード、当社からのお振込先口座情報」が、調査の結果、漏えい対象から除外されたことです。一方で、店舗側の情報として次の項目は対象に残りました。 - ショップサーブの管理画面のログインID・パスワード - コンビニ払込票に記載された店舗情報（販売責任者の氏名、店舗名、郵便番号、住所、電話番号、FAX番号） - アフィリエイトプログラム登録者のメールアドレスとパスワード 購入者・会員側では、氏名・住所・電話番号・FAX番号・メールアドレス・勤務先などの購入者情報（配送先を含む）、会員IDと暗号化パスワード（メールマガジン会員を含む）、カード情報の一部が対象です。販売責任者の氏名や店舗の住所・電話番号が漏れた以上、店舗や取引先を装った連絡への警戒は、口座情報が外れたあとも続けてください。 ### 二次被害とダークウェブ流出の確認結果・関係機関への報告と再発防止策 最終報の公表時点で、本件に起因する具体的な二次被害の報告は確認されていません。外部の専門機関の調査で、ダークウェブ上への流出も確認されていないとしています。関係機関については、個人情報保護委員会と関東総合通信局へ報告書を提出し、所轄警察署への相談等を行ったと書かれています。 再発防止策として挙げられたのは4つです。悪用された脆弱性の修正と攻撃経路の遮断、残存脅威の調査、アプリケーションとサーバーに対する脆弱性診断の実施と検出事項の是正、管理画面等の認証の追加強化（二要素認証または二段階認証を含む）。いずれも実施済みとされています。 ## Eストアー情報漏えいでどの店舗が対象かを確かめる経路と公表済み7社の一覧 「株式会社Eストアー 情報漏えい 対象店舗」「どのショップ」「どこの会社」と調べても、一覧が見つからない理由から説明します。 ### Eストアー公式に対象店舗の一覧が無い現状と最終報で示された7,858店の範囲 Eストアーの[プレスルーム](https://estore.jp/press/)に掲載されている本件のリリースは、2026年8月1日の第1報、8月2日の第2報、10月16日の最終報の3本です（2026年10月27日時点）。最終報で対象店舗が7,858店と確定しましたが、店舗の名前や一覧は出ていません。対象店舗には、現在ショップサーブを使っている店舗と、過去に使っていた店舗の両方が含まれると書かれています。 そのかわり最終報は、「ご利用店舗名の確認等をご希望されるお客様」も問い合わせ窓口へ連絡するよう案内しました。本件の調査結果や漏えいした情報の問い合わせは、店舗ではなくEストアーが確認・対応するとしています。自分の情報がどの店舗経由で対象になったかを知りたい人は、窓口で尋ねるのが確実な経路です。 出店企業の公表からは、Eストアーが店舗ごとに対象かどうかを調べて順に連絡していた経緯も読み取れます。絵具屋三吉は、第1報の時点では「漏えいの対象が確認された店舗には改めて連絡する旨の案内」があり、9月25日に対象と確認された連絡を受けたと書いています。8月初めに公表した店舗もあれば、9月下旬に連絡を受けた店舗もあり、判明時期はばらついていました。 ### 出店企業が自社サイトで公表した7社の公表日と公式ページの一覧表 2026年10月10日時点で、各社の公式サイト上で200応答を確認できた公表を、公表日順に並べます（2026年10月27日に再確認）。7,858店のごく一部で、網羅的な一覧ではありません。ここに無い店舗が対象外という意味ではない点に注意してください。 | 社名（店舗） | 公表日 | 公式ページ | | -------- | ---------- | --------------------------------------------------------------------------------------------------------------- | | デザインフィル | 2026年8月3日 | [お知らせとお詫び](https://www.designphil.co.jp/information/news/entry-8739/) | | ハリマ食品 | 8月3日・8月7日 | [第1報](https://www.harimafoods.co.jp/news/cat1/525.html)・[第2報](https://www.harimafoods.co.jp/news/cat1/561.html) | | 日本製紙クレシア | 2026年8月19日 | [お知らせ（PDF）](https://www.crecia.co.jp/whatsnew/2026/pdf/260819%5Fnews.pdf) | | キングジム | 2026年9月4日 | [お詫びとお知らせ](https://www.kingjim.co.jp/news/detail/858.html) | | PFU | 2026年9月18日 | [重要なお知らせ](https://www.pfu.ricoh.com/news/2026/news260918-2.html) | | 絵具屋三吉 | 2026年9月26日 | [お詫びとお知らせ](https://www.sankichi.com/hpgen/HPB/entries/21.html) | | マガジンハウス | 10月5日時点の内容 | [お詫びとお知らせ](https://magazineworld.jp/news/news-260871/) | 店舗ごとに漏れた項目は異なります。デザインフィルとハリマ食品はカード情報の一部まで含むと公表し、キングジムとマガジンハウスはEストアーからの報告としてカード情報とログインパスワードの漏えいは確認されていないと書いています。自分が使った店舗の項目は、その店舗の公表で確かめてください。なお各社の公表は最終報より前のものが多く、店舗メールやFTP、振込先口座に触れた記述は、最終報で対象外とされた点を踏まえて読む必要があります。キングジムとPFUのように、すでにショップサーブから移行していた企業の旧顧客データが含まれた経緯と、委託元が取るべき消去の手順は[PFUダイレクト本店の情報漏洩と移行済みEC基盤に残る旧データ](https://www.issoh.co.jp/tech/details/18176/)で詳しく扱っています。 ### Eストアーの個別連絡と店舗の公表・窓口で対象かどうかを確かめる3つの経路 購入者の立場で使える経路は3つです。 1. **Eストアーからの個別連絡を確認する**：最終報によれば、漏えいの対象となった購入者・店舗・アフィリエイターへの個別の連絡は完了しています。絵具屋三吉の告知は「株式会社Eストアーから届く案内には、ご利用店舗名が記載されていない場合があります」とも書いており、店舗名が無いことだけで偽物とは決められません。 2. **買い物をした店舗の公式サイトのお知らせを見る**：上の表のように、影響を受けた店舗は自社サイトで個別に公表しています。過去にショップサーブで構築されたサイトで買い物をしたか分からない場合は、注文確認メールの送信元や、サイト下部の表記を手がかりにします。 3. **Eストアーの窓口へ問い合わせる**：最終報には購入者・会員とアフィリエイター向けの窓口（お問い合わせフォームとsupport@estore.co.jp）と、店舗向けの電話（03-6434-0946・平日10時から18時）・メール窓口が記載されています。よくある質問と回答はフォームの冒頭に載っています。窓口のアドレスはメール本文からではなく、Eストアーの公式ページから自分で確かめて送ってください。 メールが届いていないことは、対象外の証明になりません。最終報は、連絡先が確認できず個別に案内できない人については、最終報の公表と窓口の設置をもって代替するとしています。古い住所やメールアドレスで買い物をしていた人には、連絡が届いていない可能性があります。絵具屋三吉も「現時点で同社からメールが届いていない場合でも、直ちに漏えい対象外であることを意味するものではありません」と書きました。逆に、店舗から届いた案内は、その人の情報が漏れたことを示すとは限りません。 ## Eストアーや出店店舗から届いたお詫びメールが本物かを公式文言で見分ける手順 「eストアー 情報漏えい メール」「迷惑メール」で調べる人は、届いたメールを開いてよいか迷っているはずです。真偽の判定材料は、Eストアーと出店企業が公式ページに書いた文言にあります。 ### 第1報と最終報が示す「再決済やカード情報の入力を求めない」という公式文言での判定 Eストアーは[第1報](https://estore.jp/press/20260801/)で、漏えいした氏名・住所・メールアドレス等を使い、同社や利用店舗を装ったメール、SMS、電話、郵便物が届く可能性があると注意を促しました。そのうえで「再決済、本人確認、返金、アカウント確認等を理由に、リンク先でクレジットカード情報やパスワード等を入力するよう求められても、応じないでください」と書き、「本通知自体が、再決済やクレジットカード情報の入力を求めることはありません」と明記しています。最終報でも「当社や金融機関を装った不審なメール、SMS、電話等にご注意ください」と呼びかけ、カード情報の再入力や再決済を求めないこと、メールやSMSでパスワードを尋ねないことを改めて書きました。 出店企業も同じ線を引いています。ハリマ食品の第1報は「当社または株式会社Eストアーが、メール等でクレジットカード情報やパスワードの入力をお願いすることはありません」と書きました。判定の基準は1つで足ります。 **カード番号・セキュリティコード・パスワード・認証コードの入力を求めてきたら、差出人名や件名が本物らしく見えても応じない。** この基準は「本物かどうか」を断定するものではありません。お詫びの案内そのものは本物でも、その後に来る便乗メールが偽物という組み合わせが起こりうるためです。Eストアーの公式ページは、案内メールの件名や送信元アドレスを公表していません（2026年10月27日時点）。件名や差出人表示だけで真偽を決めず、求められている操作で判断してください。個別連絡は完了したと最終報が書いている点も手がかりになります。最終報のあとに「初めてのお知らせ」として届き、リンク先での操作を促すメールは、まず疑ってかかってください。手口の型と見分け方は[フィッシングの手口の種類と見分け方](https://www.issoh.co.jp/column/details/13262/)にまとめています。 ### Eストアーの個別メールと店舗からの一斉案内を取り違えないための見方 本件では、性質の違う2種類のメールが同じ時期に届きました。1つはEストアーが漏えい対象と確認した人へ送る個別の案内、もう1つは出店企業が自社の利用者全体へ送る一斉の案内です。絵具屋三吉は、自店からの案内は個別に確認された人だけでなく利用者へ広く送るもので、届いたことが漏えいを示すわけではないと説明しています。日本製紙クレシアも、8月7日から順次、漏えいの可能性がある人へ自社から案内メールを送ったと公表しました。 受け取った側は、次の順で整理すると混乱しません。 - 差出人がEストアーの場合：自分が対象と確認された可能性が高い案内。ただし店舗名が書かれていないことがある - 差出人が買い物をした店舗の場合：その店舗の利用者全体への周知である可能性がある。店舗の公式サイトのお知らせと内容を照合する - カード会社や配送業者を名乗り、本件に触れて入力を求める場合：Eストアーと店舗が注意を促している便乗の型に当たる ### 迷惑メールに見えたときに公式サイトと窓口へ自分で照合する3つの手順 届いたメールが迷惑メールに見える場合でも、削除する前に次の手順で照合できます。 1. メール内のリンクは開かず、ブラウザで「estore.jp」を直接入力して[プレスルーム](https://estore.jp/press/)を開き、最終報の内容とメールの記載（期間・漏えい項目・窓口）が一致するかを見る 2. メールに店舗名があれば、その店舗の公式サイトを検索から開き、お知らせ欄に本件の公表があるかを確かめる 3. 判断がつかなければ、公式ページに載っている購入者向け窓口（お問い合わせフォームまたはsupport@estore.co.jp）へ、届いたメールの差出人と件名を添えて問い合わせる すでにリンク先でカード情報を入力してしまった場合は、Eストアーの第1報のとおり、カード裏面に記載されたカード会社へ速やかに連絡してください。パスワードを入力した場合は、そのパスワードを使っている全サービスでの変更が必要です。なお、絵具屋三吉はEストアーから「本件を理由として直ちにクレジットカードの停止・再発行を行う必要はない」との案内があったと伝えています。最終報も、漏えいした情報のみではカード決済を行えないとしています。 ## 第1報から最終報までの経緯で読む滞留期間・件数の推移・カード情報の範囲 ここからは公表事実を推測と分けて確定させます。根拠はEストアーの[第1報（2026年8月1日）](https://estore.jp/press/20260801/)、[第2報（8月2日14時時点）](https://estore.jp/press/20260802/)、[最終報（10月16日）](https://estore.jp/press/20261016/)と、ショップサーブのお知らせです。 | 日付 | 発表主体 | 内容 | | ----------- | ------- | --------------- | | 2026年8月1日 | Eストアー | 第1報・最大延べ885万件 | | 2026年8月2日 | Eストアー | 第2報・期間とカード等追加 | | 2026年8月6日 | ショップサーブ | マイページ認証を強化 | | 8月3日から10月 | 出店企業各社 | 店舗ごとの個別公表 | | 2026年10月16日 | Eストアー | 最終報・約2,335万人で確定 | 第1報は発生を「2026年8月1日9:09〜11:06頃」としていましたが、第2報で発生期間を5月21日から8月1日に改め、会員情報・カード情報・店舗関連情報を漏えい項目に加えました。第1報には、個人情報保護委員会へ報告し、所轄警察署への届け出も検討していると書かれています。8月6日にはショップサーブのお知らせで[購入者向けマイページのログイン認証システム変更](https://shopserve.estore.jp/sps-news/20260806/)が告知され、店舗から購入者へ一律にパスワード変更を案内する必要はないこと、過去に仮パスワードのまま使っていた一部の購入者はログイン時に認証エラーとなる場合があることが案内されました。最終報は、期間を5月21日から8月1日で確定させたうえで、件数・原因・対象店舗数を示し、店舗メール・FTP・振込先口座を対象から外しています。 | 項目 | 最終報時点の公表内容 | | ------ | --------------- | | 対象期間 | 2026年5月21日〜8月1日 | | 対象者数 | 約2,335万6,000人 | | 購入者の情報 | 氏名・住所・電話・メール等 | | 会員情報 | 会員ID・暗号化パスワード | | カード情報 | 名義・先頭6桁・下4桁・期限 | | 店舗の情報 | 管理画面・払込票の店舗情報 | | 対象外 | セキュリティコード・全桁番号 | | 原因 | アプリの脆弱性の悪用 | 第2報の段階では、原因は「サーバーに対する外部からの不正アクセス」とまでしか書かれていませんでした。最終報で、アプリケーションの脆弱性の悪用と、DBの情報の外部送信という経路が確定しています。ただし、どのソフトウェアのどの脆弱性かは公表されていません。以下の技術解説は、公表文の記述から言える範囲と、一般的な侵害の型から言える範囲を分けて書いています。 ### 2026年5月21日から8月1日まで2か月半に及んだ滞留期間の意味 公表された対象期間は2026年5月21日から8月1日です。この2か月半は被害範囲であると同時に、検知までにかかった時間そのものを示します。最終報によれば、Eストアーが本件を認知したのは8月1日で、その日に攻撃元からの通信を遮断しました。5月21日に攻撃が始まり、認知の当日まで実行と送信が続いていたのなら、その間に発火した警報は無かったか、あっても運用側で処理されなかったことになります。 攻撃者にとって、この期間はDBの構造を把握し、価値のあるテーブルを見極め、転送量を分散させながら持ち出すための時間でもありました。守る側から見れば、滞留期間の長さは「侵入を止められなかったこと」よりも「侵入後の挙動を見ていなかったこと」を示す指標になります。脆弱性の修正だけを再発防止策に据えると、次の未知の脆弱性で同じ長さの滞留を許すでしょう。 ### 延べ885万3839件から約2,335万人への公表値の変化と店舗側に及んだ情報の内訳 第2報の885万3839件は購入者の人数ではなく、データの件数でした。Eストアーは同一顧客の複数データを含む可能性を明示しており、調査継続中のため上振れも残っていました。最終報の約2,335万6,000人は、購入者・会員に加えて店舗運営者とアフィリエイターを含め、名寄せをしたあとの人数です。第2報の数字を確定値として扱わないよう注意を促してきた本記事の立場からいえば、上振れの側に確定したことになります。 店舗側の情報は、最終報で範囲が絞られました。店舗メールシステムのID・パスワード、FTPログイン情報、振込先口座情報は対象外となり、残ったのは管理画面のログインID・パスワードと、コンビニ払込票に記載された店舗情報です。それでも管理画面の認証情報は、そのまま次の攻撃の入り口になります。管理画面に入られれば、注文情報の閲覧だけでなく決済ページの改ざんによるカード情報の直接窃取まで射程に入るでしょう。Eストアーは認証情報のリセットを実施済みとしていますが、同じパスワードを他のサービスで使い回している店舗は、そちらも変更が要ります。 ### カード番号先頭6桁と下4桁・有効期限の漏えいで起きうる悪用の範囲 カード情報については、名義・番号の先頭6桁と下4桁・有効期限が対象で、完全なカード番号とセキュリティコードは非保持のため含まれません。先頭6桁はBIN（発行会社識別番号）にあたり、これ単体でカード決済を通すことはできません。最終報も「今回漏えいした情報のみでは、クレジットカード決済を行うことはできません」と書いています。番号の中間6桁が欠けているため、この情報だけで不正利用が成立する構図ではないという点は、店舗が購入者へ告知する際に正確に伝えるべき部分です。 ただし無害でもありません。BINからは発行会社とカードブランド、券種が判別できます。氏名・住所・勤務先とセットになれば、発行会社を騙るフィッシングの精度が跳ね上がります。「お使いの○○カード、下4桁××××について」と書かれたメールは、受け手にとって本物と区別しにくい。前章のお詫びメールの見分け方が必要になるのは、この組み合わせがあるためです。約209万6,900人という規模は、便乗する側から見れば十分に大きな母集団です。 ## 認可制御不備の事案とは異なるサーバー侵害という攻撃レイヤの特徴 ここからは開発・情報システムの担当者向けです。同じ「情報漏えい」でも打ち手はレイヤで変わります。この違いを押さえず対策を横展開しても、今回の型は止まりません。なお、同一グループ内で短期間に侵害が再発し、是正の水平展開が論点になった事例は[イエローハット情報漏洩の第二報｜179万人の流出確定](https://www.issoh.co.jp/tech/details/17203/)で扱っています。 ### 不正プログラムの実行と購入者情報の外部送信に分かれる2段階の構造 最終報にある「アプリケーションの脆弱性を悪用して不正なプログラムを実行し、データベースに格納された情報を外部へ送信していた」という記述は、2つのフェーズを含みます。第1がコード実行の成立、第2がデータの持ち出しです。 第1フェーズの入り口として典型的なのは、Webアプリケーションやミドルウェアの既知・未知の脆弱性を突いたリモートコード実行、ファイルアップロード機能の検証不足、管理系の認証情報の窃取でした。最終報で確定したのは「アプリケーションの脆弱性の悪用」までで、種類は公表されていません。本件で目を引くのは、Webシェルのようなバックドアを置かずに実行を繰り返していた点です。ファイルを残す型との違いは[Webシェルの設置手口と検知・除去の手順](https://www.issoh.co.jp/tech/details/18314/)と比べると分かりやすく、置かれたファイルを探す検知だけでは本件の型を捕まえられません。第2フェーズでは、取得したデータを外部の受信サーバーへHTTPSやDNSで送り出します。押さえるべきは、この2つが別の検知手段で捕まる構造だという点です。[WAFやIPS](https://www.issoh.co.jp/tech/details/13275/)は第1フェーズの入り口を狭めますが、脆弱性が未知であれば素通りし、いったんホスト上でコードが動き出せば射程外になります。 ### タカラトミー・生保協会の2事案と本件で防御の打ち手が変わる理由 直近の国内事案と並べると輪郭がはっきりします。[生命保険協会の契約照会システムの事案](https://www.issoh.co.jp/tech/details/15878/)は、2026年9月14日の[調査結果](https://www.seiho.or.jp/info/news/shared/mt-item/20260914.pdf)で、ログインしていないゲストユーザーに他の利用者の個人情報を参照できる権限が誤って付与されていた設定不備と確定しました。[タカラトミーのデュエマアプリの事案](https://www.issoh.co.jp/tech/details/15978/)は「ユーザー認証機能の設計・実装の脆弱性」と公表されただけで、認可の抜けか認証の欠陥かは明らかにされていません。どちらもホストを掌握された事案ではなく、「誰に何を見せてよいか」の判定や設定が誤っていた側の型です。具体的な打ち手は、未認証・他人参照のアクセス検査と権限設定の点検です。これに対し[PeakManagerの事案](https://www.issoh.co.jp/tech/details/16101/)は、データベースそのものへ到達され保存データを削除された型で、DBアカウントの権限分離と監査ログが打ち手になります。さらに、ホスティング事業者の管理基盤を経由して顧客環境へ到達した型は[さくらインターネットの不正アクセス](https://www.issoh.co.jp/tech/details/17201/)で扱っており、預けた側に残る点検手順まで整理しています。 本件は構造が違います。攻撃者はアプリケーションの脆弱性を足がかりにロジックを迂回し、サーバー上でプログラムを動かしてDBへ到達しました。所有者チェックを何重に書いてもこの層は止まりません。必要なのは脆弱性を早く見つけて塞ぐ仕組み、ホスト上の挙動監視、外向き通信の統制、認証情報の分離と失効の速さです。3事案を「認可」で一括りにして同じ再発防止策を配ると片方は的外れになるため、自社のどのシステムがどちらの型に近いかをまず切り分けてください。認可でもホスト侵害でもなく、正規の認証情報を握られて正規の経路で入られた型は、[講談社の個人情報流出の技術解説](https://www.issoh.co.jp/tech/details/16099/)で扱っています。 ## アプリ脆弱性経由の不正実行と外部送信をauditd・出口監視・ログ相関で検知する手順 滞留を短縮するには、どの層で何を捕まえるかを事前に割り振る必要があります。この章の設定例は、ECサイトを自社のLinuxサーバーで運用している開発者・インフラ担当者向けです。ショップサーブのようなテナント型サービスの店舗側ではサーバーに触れないため、次章の認証情報と管理画面の対応へ進んでください。 ### 脆弱性を突いたスクリプト実行をプロセス起動の親子関係で捕まえる方法 アプリケーションの脆弱性からコマンドが実行されるとき、プロセスツリーには不自然な親子関係が現れます。Webサーバーやアプリケーションサーバーのプロセスが、シェルやスクリプト実行系のプロセスを直接起動する形です。Webシェル経由でも、本件のようにバックドアを置かずに脆弱性を毎回突く型でも、この親子関係は同じように出ます。正常な運用ではまず発生せず、検知ルールとして書きやすい部類に入ります。 この親子関係を継続的に見るのが[EDR（Endpoint Detection and Response）](https://www.issoh.co.jp/tech/details/13303/)の役割です。導入時に効いてくるのは、検知エンジンの性能よりも配備範囲でした。Webサーバーには入れたがバッチサーバーには入れていない、本番には入れたが検証環境には入れていない、という穴が実際の侵害では突かれます。EC基盤のように公開面と管理面が分かれる構成では、管理面のホストこそ配備対象から漏れやすいため、配備率を資産管理台帳と突き合わせて確認してください。ただしEDRは実行を捕まえる道具で、正規プロセスを経由した外部送信までは守備範囲に入りません。後述の出口監視と組み合わせて初めて滞留を縮められます。 EDRをすぐ入れられない環境でも、Linux標準の監査機構auditdで最低限の記録は取れます。[auditctl(8)](https://man7.org/linux/man-pages/man8/auditctl.8.html)と[audit.rules(7)](https://man7.org/linux/man-pages/man7/audit.rules.7.html)の書式に沿って、Webサーバーの実行ユーザーがプログラムを起動した記録と、公開ディレクトリへの書き込みを残すルールの例を示します。 ``` # /etc/audit/rules.d/web-exec.rules # Webサーバー実行ユーザーのUIDは環境ごとに確認する（例: id -u www-data で 33） # そのユーザーが execve でプログラムを起動したら web_exec のキーで記録する -a always,exit -F arch=b64 -S execve -F euid=33 -k web_exec -a always,exit -F arch=b32 -S execve -F euid=33 -k web_exec # 公開ディレクトリへの書き込み・属性変更を webroot_write のキーで記録する -w /var/www/html -p wa -k webroot_write ``` ルールを読み込み、当日分の記録をキーで引くコマンドは次の通りです。 ``` # ルールファイルを読み込んで反映する sudo augenrules --load # 反映されたルールを確認する sudo auditctl -l # 当日の web_exec の記録を、UIDやsyscall名を読める形で表示する sudo ausearch -k web_exec -i --start today ``` execveの監査は、プロセス起動の多い高負荷のサーバーでは監査ログの量が増え、ディスクとログ転送の負荷になります。導入前に検証環境で1日あたりの記録件数を測ってから本番へ入れてください。運用に乗せる際のもう1つの注意点は誤検知です。画像変換や外部コマンドを呼ぶ正規の処理も同じユーザーで動くため、最初の1〜2週間は記録だけを取り、正規の起動パターンを洗い出してから通知条件を絞ってください。いきなり全件を通知すると、本件のように警報が処理されない状態を自分で作ることになります。 ### 外向き通信の宛先と転送量にしきい値を置く出口監視の具体的な設計手順 持ち出しフェーズを捕まえる設計に移ります。EC基盤のサーバーが自発的に通信する先は限られています。決済代行、配送業者API、メール配信、監視SaaS、パッケージリポジトリ。洗い出して許可リストを作れば、未知の宛先への通信を例外として扱えます。最終報が「攻撃元からの通信を遮断」したと書いているとおり、止める段階で効くのも外向き通信の制御です。 宛先の統制と組み合わせるのが転送量のベースラインです。平常時の外向き転送量を曜日・時間帯別に取っておき、そこから外れた増加をアラートにします。攻撃者が転送を分散させても、2か月半にわたって送り続ければ累積では平常値を超えるため、日次だけでなく週次・月次の累積にもしきい値を置いてください。DNSクエリ数の異常もあわせて見ておくと、DNSトンネリングによる持ち出しを取りこぼしにくくなります。 ### 侵害の痕跡を残すログの外部保存とファイル整合性監視を併用する構成 ホストを掌握された時点で、そのホスト上のログは信用できません。攻撃者が消せるためです。ログを別ネットワークのストレージへ即時転送し、書き込み後は変更できない設定にしておけば、事後の範囲確定と報告義務の判断に必要な材料が残ります。今回のように対象期間を日単位で確定させ、「ほかの経路での侵害は無い」と言い切るには、この保全が前提です。 あわせて置きたいのがファイル整合性監視です。公開ディレクトリに実行可能なファイルが増えた、設定ファイルが更新された、という変化が検知の対象です。本件のようにバックドアを置かない型には効きませんが、侵入後に居座る型を捕まえる層として残しておく価値があります。専用ツールを入れる前の一次調査なら、更新日時で絞り込むだけでも不審なファイルの当たりは付けられます。 ``` # 直近7日以内に公開ディレクトリで追加・更新されたPHPファイルを、更新日時・所有者付きで一覧にする find /var/www/html -type f -name '*.php' -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %u %p\n' | sort # アップロード用ディレクトリに置かれたPHPファイルは原則として不審とみなす find /var/www/html -path '*upload*' -type f -name '*.php' ``` 更新日時は攻撃者が書き換えられるため、この確認は「無いことの証明」にはなりません。継続監視はハッシュ値を外部に保存して突き合わせる方式で組んでください。[SOCとSIEMで各層のログを相関させる](https://www.issoh.co.jp/tech/details/13310/)と、ファイル追加とプロセス起動と外向き通信が同一ホストで時系列に並びます。各層の分担は次の通りです。 | 層 | 捕まえる事象 | 本件で効く場面 | 単独での限界 | | ---------- | ---------- | ---------- | ----------- | | WAF・IPS | 侵入試行・攻撃通信 | 初期侵入の抑止 | 未知の脆弱性は素通り | | EDR・auditd | プロセス起動・実行 | 不正プログラムの実行 | 持ち出しは見えにくい | | 出口通信監視 | 宛先・転送量の異常 | データの外部送信 | 暗号化で中身は不明 | | ファイル整合性監視 | ファイル追加・改ざん | 居座る型の発見 | ファイル無しの型は不可 | | SIEM | 層をまたぐ相関 | 滞留期間の短縮 | 元ログが無いと機能せず | どれか1つを買えば済む構成はありません。EDRと出口監視のどちらかが欠けるだけで滞留は長期化します。 ## 管理画面・FTP・カード情報の3経路をMFAとSFTP鍵認証でふさぐ実装手順 漏えい項目から逆算すると、手を入れる箇所は3つです。最終報で残った項目と外れた項目を踏まえ、優先順位は二次被害の起こりやすさで決めます。 ### 店舗管理画面へのMFA導入とIP制限を後付けする際の実務上の制約 最終報でも漏えい対象に残ったのが、店舗の管理画面のログインIDとパスワードです。Eストアーは認証情報のリセットを実施済みとしていますが、変更だけでは足りません。同じパスワードを他サービスで使い回す店舗が一定数いるためです。[多要素認証（MFA）](https://www.issoh.co.jp/tech/details/13314/)の必須化が本筋で、Eストアーも第2報で店舗向けに二段階認証の設定を推奨し、最終報では管理画面等の認証の追加強化（二要素認証または二段階認証を含む）を再発防止策として実施済みとしました。 後付けする際の制約は技術面より運用面に出ます。管理画面を1つのアカウントで複数人が共有している店舗、スマートフォンを業務で持たないスタッフ、認証アプリの引き継ぎができずロックアウトする利用者。テナント型サービスでMFAを必須化すると、この種の問い合わせが一斉に発生します。IP制限は固定回線の店舗には有効な一方、在宅や店頭からの接続がある業態では現実的でない場合が多い。MFAを既定にし、IP制限は希望する店舗のオプションとする形が落としどころです。 ### 第2報で挙がったFTP認証情報を前提にSFTPと鍵認証へ切り替える判断 FTPのID・パスワードは、最終報で漏えい対象から除外されました。ただ、第2報で漏えい項目に挙がった事実は、2026年時点でもFTPが現役の環境が残っていることを示します。FTPは認証情報を平文で流すうえ、漏れれば公開ディレクトリへの書き込みがそのまま可能になる。Webシェル設置の最短経路です。今回は外れたから安心、ではなく、次の事案で漏れたときに被害を広げない構成へ移しておく判断材料として読んでください。 切り替え先はSFTPで、パスワード認証ではなく公開鍵認証に倒してください。鍵は店舗ごとに分離し、退店・契約終了時に失効させる運用まで設計します。OpenSSHであれば、[sshd\_configの公式マニュアル](https://man.openbsd.org/sshd%5Fconfig)にあるMatch・ChrootDirectory・ForceCommandの組み合わせで、SFTP専用・鍵認証のみのグループを作れます。 ``` # /etc/ssh/sshd_config の末尾に追記する（sftponly グループの利用者だけに適用） Match Group sftponly ChrootDirectory /srv/sftp/%u ForceCommand internal-sftp PasswordAuthentication no AuthenticationMethods publickey AllowTcpForwarding no X11Forwarding no ``` ``` # 設定の文法を検査してから再読み込みする（検査で失敗したら再読み込みしない） sudo sshd -t && sudo systemctl reload sshd ``` ChrootDirectoryに指定するディレクトリは、root所有かつroot以外が書き込めない権限にしておく必要があります。利用者が書き込む先はその配下に別ディレクトリを作って割り当ててください。ディストリビューションによってはサービス名がsshになる点にも注意が要ります。 詰まりやすいのは、社外の制作会社が握る接続情報の把握でした。移行前に「誰が今この経路を使っているか」を棚卸しする。この工程を飛ばすと、切り替え当日に業務が止まります。 ### カード情報の非保持化とPCI DSS v4.0.1が問う管理範囲の線引き 本件で完全なカード番号とセキュリティコードが対象外だったのは、非保持だったためです。非保持化が効いた実例にあたります。一方でカード名義・先頭6桁・下4桁・有効期限は約209万6,900人分が漏れました。これらは決済管理や照合のために保持されることが多く、「非保持化しているから安全」が成り立たない領域です。自社で決済を扱うなら、どの項目をどのテーブルに何日間残しているかを棚卸ししてください。 基準面では[PCI DSS v4.0.1](https://www.issoh.co.jp/column/details/13185/)（2024年6月公開。原文は[PCI SSCのドキュメントライブラリ](https://www.pcisecuritystandards.org/document%5Flibrary/)で入手できます）が現行で、2025年3月31日をもってベストプラクティス扱いだった要件も義務化済みです。決済ページのスクリプト管理（要件6.4.3）と改ざん検知（要件11.6.1）は、サーバー側を掌握された場合の決済ページ改ざんに直接対応します。カード情報を保持しない構成でも、決済ページを自社で配信するならこの2要件は守備範囲に含まれるものです。決済画面に不正プログラムを置かれた実例と、CSP・SRI・差分監視の設定例は[PhotoGoodsの不正アクセスとカード情報漏えい](https://www.issoh.co.jp/tech/details/18205/)で解説しています。 ## 個人情報保護法の報告義務と店舗側が72時間で着手する二次被害対策 ここからは事業者の備えです。技術対応と並行して走るのが法対応と顧客対応で、順番を誤ると後から範囲を確定できません。 ### 速報3〜5日・確報30日（不正目的は60日）に間に合わせる社内の段取り 個人情報保護法では、個人データの漏えい等が発生した場合、個人情報保護委員会への報告と本人への通知が義務づけられています。[個人情報保護委員会の漏えい等の対応ページ](https://www.ppc.go.jp/personalinfo/legal/leakAction/)では、報告対象を要配慮個人情報、財産的被害のおそれ（クレジットカード番号やログイン認証情報など）、不正の目的による行為（不正アクセスなど）、1,000人超の4つの事態に整理しています。本件が当てはまるのは、少なくとも後ろの3つの事態です。 期限は速報が発覚日から概ね3〜5日以内、確報は原則30日以内ですが、不正の目的による行為の場合は60日以内となります（2026年10月時点）。同ページでは、ランサムウェア事案は令和7年（2025年）10月1日以降、ランサムウェア以外の「その他サイバー攻撃等事案」も令和8年（2026年）10月1日以降、関係省庁申合せに基づく共通様式で報告できると案内されています（2026年10月27日確認）。本件はEストアーの公表でランサムウェア事案とはされていないため、該当するのは後者の様式です。Eストアーは最終報で、個人情報保護委員会に加えて関東総合通信局へも報告書を提出したと書いています。改正を含む実務の変化は[個人情報保護法改正の解説](https://www.issoh.co.jp/column/details/13787/)にまとめています。 速報の段階で全容が判明していることは、まずありません。「分かっている範囲を期限内に出す」のが実務です。段取りは次の順で組みます。 1. 事態を知った日時を記録する（起算点になるため、口頭連絡でも時刻を残す） 2. ログの保全を最優先で実施し、調査より先に証跡を凍結する 3. 対象となる個人データの項目と概数を暫定値で確定させる 4. 速報を提出し、調査継続中である旨と判明予定時期を添える 5. 本人通知の文面を並行して作成し、二次被害防止に必要な情報を先に出す Eストアーが第1報の翌日に件数と項目を出し、約2か月半後の最終報で範囲を確定させたのは、この段取りに沿った動きでした。件数が未確定でも、項目が分かれば本人が取れる対策は伝えられます。一方で、第2報で挙げた項目のうち店舗メール・FTP・振込口座が最終報で外れたように、暫定値は後から動きます。速報で広めに出し、確報で絞る順序を取れば、本人への注意喚起が遅れることはありません。なお、ショップサーブを使う店舗にとっても自店の顧客の個人データであるため、委託元としての報告や本人通知の要否は、Eストアーの対応と切り離して自社で判断が要ります。 ### ID・パスワード流出を前提にしたリスト型攻撃と取引先なりすましへの備え ショップサーブでECを運営している事業者が72時間以内に着手すべきことを整理します。最終報は会員パスワードが特定される可能性は低いとしていますが、管理画面の認証情報は対象に残っています。暗号化されているとはいえ、パスワードは時間経過とともに解読される前提で動いてください。 - 管理画面の認証情報を変更し、同じ認証情報を使っている他サービスも同時に変更する。第2報の時点で店舗メール・FTPも変更していれば、そのままでかまわない - 管理画面の二段階認証を設定し、退職者や取引終了した制作会社のアカウントを削除する - 購入者へ告知し、パスワードの使い回しがある場合の変更と、自社を騙るフィッシングへの注意を同時に伝える。Eストアーの個別メールと自店の一斉案内の違いも書き添える - コンビニ払込票の店舗情報（販売責任者名・住所・電話番号）が漏れたことを前提に、取引先からの「口座変更のお知らせ」を電話で照合する運用へ切り替える 4番目を軽く見ないでください。振込先口座情報は最終報で対象外になりましたが、販売責任者の氏名と店舗の住所・電話番号は漏れています。取引先や自社を装って口座変更を通知するビジネスメール詐欺の材料としては、これで足ります。メールでの口座変更依頼は既知の電話番号で必ず確認する運用を、全社に周知するところまでが今回の範囲です。 ## ショップサーブを使い続ける条件と自社基盤へ移すべき条件の線引き 侵害を受けたサービスを使い続けるべきか。条件付きで言い切ります。 ### そのまま継続してよい店舗の条件と、基盤移行を検討すべき店舗の条件 継続してよいのは、次の条件に当てはまる店舗です。会員数が数千規模までで、決済は代行会社に寄せてカード情報を自社で持たず、管理画面の操作者が数人に限られる。この場合、認証情報の総入れ替えとMFA設定、購入者への告知で足ります。最終報で脆弱性の修正、残存脅威の調査、脆弱性診断と是正が実施済みとされたことも、継続を選ぶ判断材料になります。基盤を移す作業自体がリスクと工数を生み、割に合いません。 移行を検討すべきなのは、次のいずれかに当てはまる場合です。第1に、会員基盤や購買履歴を自社の他システムと連携させており、EC基盤の侵害が社内へ波及する構造にある店舗。第2に、決済ページを自社ドメインで配信し、PCI DSSの要件6.4.3・11.6.1を自社の責任範囲として説明する必要がある店舗。第3に、取引先や親会社から監査要求を受けており、基盤側の再発防止策を第三者へ開示できないと契約継続に支障が出る店舗です。最終報は再発防止策の項目を示しましたが、悪用された脆弱性の種類や診断の範囲までは公表していません。第3の条件に当たる店舗は、Eストアーへ個別に開示を求め、得られなければ移行を検討してください。この3つに当てはまらないなら、移行は見送ってかまいません。Shopifyなどへ移しても、決済・在庫・配送の連携部分、アプリの権限設定、管理者アカウントの管理は自社に残ります。「移せば安全」ではなく、この3条件で決めてください。 ### 移行や内製化に踏み切る場面で見落とされがちな運用コストの実態と体制 移行を決めた場合に見落とされるのは、構築費用ではなく移行後の運用体制です。旧基盤に残る過去データの消去も同じく抜けやすく、2025年10月に移行済みだったPFUダイレクト本店でも、2008年12月の導入時からの注文データが今回の対象になりました。最終報が、対象の7,858店に過去の利用店舗を含むと明記したのも同じ構図です。経緯と消去の依頼項目は[PFUの事例を扱った解説](https://www.issoh.co.jp/tech/details/18176/)で整理しています。自社サーバーで内製するなら、EDR配備・出口通信監視・ログ外部保存・ファイル整合性監視を全て自前で回すことになり、監視の当番体制まで人員が必要です。 判断材料として、まず自社の年間EC売上に対して情報セキュリティ運用にいくら割けるかを出してください。ここが年間数百万円に届かないなら、内製ではなくプラットフォーム側に守らせる構成のほうが合理的でしょう。基盤の選定から移行、決済・在庫連携まで含めた設計は[ECサイト制作・Shopify構築](https://www.issoh.co.jp/service/web/shopify/)で受託しています。 ### SaaS解約時にデータ削除の確認を取る契約条項とエクスポート後の手順 解約済みの店舗の旧顧客まで対象になった本件の盲点は、EC基盤に限らずSaaS全般の解約手続きに当てはまります。解約時に確認しておく事項を挙げます。 - 解約後に顧客データを何日間保持し、いつ削除するかが利用規約や契約書に書かれているか - 削除完了を書面やログで確認できるか（削除証明の発行可否） - バックアップやログに残ったデータの扱い（本番DBから消しても複製が残る場合がある） - 移行先へエクスポートしたデータの持ち出し記録を自社側に残したか 移行先の構築では、旧基盤から引き継ぐデータを必要な項目に絞ることも効きます。設計段階からの作り込みは[Webサイトのセキュリティ構築の基本](https://www.issoh.co.jp/tech/details/5147/)で整理しています。 ### 原因調査の完了前に環境を丸ごと作り直す対応を見送るべき理由と代替手順 侵害の報を受けて即座にサーバーを再構築する対応は見送ってください。侵入経路が未確定のまま作り直せば、同じ脆弱性を抱えたアプリケーションを載せ直すことになり、同じ経路で再度侵入されます。それ以上に問題なのは、報告義務の判断に必要な証跡が消えることです。対象期間と項目を確定できなければ、確報を出せません。Eストアーが最終報で「確定した侵入経路以外の経路による侵害、およびバックドア等の不正なプログラムの設置がない」と言い切れたのも、調査の材料が残っていたからです。 代替手順は、隔離と保全を先に置く形です。当該ホストをネットワークから切り離し、ディスクイメージとメモリダンプを取得してから調査に入ります。サービス継続が必要なら、別環境に新規構築し旧環境は調査用に凍結しておく。外部事業者へ委託する場合も、この保全の有無で判明する範囲が変わります。本件の原因がアプリケーションの脆弱性だった以上、事後に[脆弱性診断](https://www.issoh.co.jp/column/details/13101/)で残存する穴を洗い出す工程は省けません。自社のEC基盤や業務システムのWebアプリケーションを第三者の目で点検したい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で、診断から検出事項の改修までを受託しています。 ## よくある質問 Eストアー（ショップサーブ）の情報漏えいについて、検索で多い問いに答えます。 ### 株式会社Eストアーの情報漏えいはどのショップ・どのサイトが対象ですか？ 対象店舗は7,858店と最終報で確定しましたが、店舗名の一覧は公表されていません（2026年10月27日時点）。対象には現在の利用店舗と過去の利用店舗の両方が含まれます。デザインフィル、ハリマ食品、日本製紙クレシア、キングジム、PFU、絵具屋三吉、マガジンハウスなどは自社サイトで公表しています。自分が使った店舗名を確かめたい場合は、最終報の案内どおりEストアーの購入者向け窓口（お問い合わせフォームまたはsupport@estore.co.jp）へ問い合わせてください。 ### Eストアーから届いた情報漏えいのお詫びメールは迷惑メールですか？ 最終報によれば、漏えい対象者への個別連絡は完了しており、店舗名が書かれていない場合もあります。届いただけで迷惑メールとは言えません。判定の基準は、カード情報やパスワードの入力を求めているかどうかです。Eストアーは最終報で、カード情報の再入力や再決済を求めないこと、メールやSMSでパスワードを尋ねないことを明記しています。入力を求めるメールには応じず、estore.jpのプレスルームを自分で開いて内容を照合してください。 ### Eストアーからメールが届いていなければ自分は対象外ですか？ 対象外とは言い切れません。最終報は、連絡先が確認できず個別に案内できない人については、公表と窓口の設置で代替するとしています。古いメールアドレスで買い物をしていた人や、数年前に一度だけ利用した店舗の旧サイトのデータが含まれた人は、連絡が届いていない可能性があります。心当たりがあれば窓口で確かめ、パスワードを使い回しているサービスがあれば先に変更しておくのが安全です。 ### ショップサーブの店舗で買い物をしただけの購入者は何をすべきですか？ 優先順位は3つです。第1に、同じパスワードを他サイトで使い回しているなら変更します。最終報は会員パスワードが特定される可能性は低いとしていますが、使い回しの解消は損になりません。第2に、カード明細を数か月確認します。漏れたのは番号の先頭6桁と下4桁・有効期限で、最終報も、漏えいした情報のみでは決済を行えないとしています。第3に、カード会社や店舗を騙るメール・SMSを疑ってください。氏名・住所・カード下4桁が揃ったフィッシングは見分けが難しくなります。 ### 店舗の管理画面パスワードを変えれば対応は完了しますか？ 完了しません。管理画面のパスワード変更は最初の一手にすぎず、同じ認証情報を使い回している他のサービスも同時に変更する必要があります。加えて二段階認証の設定、退職者や取引終了した制作会社アカウントの削除、購入者への告知までが1セットです。店舗メール・FTP・振込先口座は最終報で対象外になりましたが、コンビニ払込票に載る販売責任者名や店舗の住所・電話番号は漏れています。取引先からの口座変更連絡を電話で照合する運用へ切り替えてください。 ## 関連記事 - [PFUダイレクト本店の情報漏洩：第2報で漏えい対象データ78,873件。対象期間・確認先と移行済みEC基盤に残る旧データ](https://www.issoh.co.jp/tech/details/18176/)：本件で旧顧客データが対象になった委託元側の事例。 - [タカラトミーのデュエマアプリ個人情報漏えい｜認証・認可実装の何が抜けたのか](https://www.issoh.co.jp/tech/details/15978/)：モバイルAPI認可という別レイヤの事案。 - [生命保険協会の情報漏洩｜原因はゲストユーザー権限の誤付与、2.7万件の対象と現在の状況](https://www.issoh.co.jp/tech/details/15878/)：未認証のゲストに参照権限が付いていた設定不備の型との比較用。 - [Webシェルとは？Tomcatへの設置手口と検知・除去の手順をコマンド例で解説](https://www.issoh.co.jp/tech/details/18314/)：バックドアを置く型の侵害との対比。 - [EDRとは？EPP・XDRとの違いと検知の仕組み・導入判断を実装者向けに解説](https://www.issoh.co.jp/tech/details/13303/)：実行フェーズを捕まえる仕組みの詳細。 - [SOCとは？SIEM・SOARとの違いと監視運用の仕組み・内製とアウトソースの判断を実装者向けに解説](https://www.issoh.co.jp/tech/details/13310/)：層をまたぐログ相関と監視運用の設計。 - [フォレンジック調査とは？流れ・費用・調査項目と依頼先の選び方、報告期限まで解説](https://www.issoh.co.jp/column/details/2812/)：侵入経路と対象範囲を確定させる調査の進め方。 - [Webサイトのセキュリティ構築｜設計段階から作り込む安全なサイトの基本](https://www.issoh.co.jp/tech/details/5147/)：移行先を設計段階から固める考え方。 - [脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説](https://www.issoh.co.jp/column/details/13101/)：侵入経路の洗い出しを外注する判断材料。 --- 出典: [ショップサーブ情報漏えいの最終報：Eストアー約2,335万人・7,858店の対象確認とお詫びメールの見分け方]()（株式会社一創）