--- title: "アイリスオーヤマ情報漏洩：アイリスプラザ770万人分の対象項目と本物の連絡の見分け方" url: "https://www.issoh.co.jp/tech/details/19402/" published: 2026-11-06 updated: 2026-11-06 categories: ["セキュリティ"] publisher: "株式会社一創" --- # アイリスオーヤマ情報漏洩：アイリスプラザ770万人分の対象項目と本物の連絡の見分け方 アイリスオーヤマの公式通販サイト「アイリスプラザ」で、外部クラウドサービスへの不正アクセスにより、最大で約770万人分の個人情報が漏えいした可能性があると、運営する株式会社アイリスプラザが2026年11月5日に公表しました。会員は氏名・住所・電話番号・メールアドレス・性別・パスワード・生年月日など、非会員は氏名・住所・電話番号・メールアドレスが対象です。クレジットカード情報は当該クラウドに保存されておらず、同社の説明では不正アクセスの影響を受けていないとのことです。前半では、自分が対象か、パスワードをどうするか、本物の窓口と連絡はどれかを公式発表から整理します。後半は開発者向けに、クラウドに置いた会員データの大量読み出しをログから見つけるコードを、実行結果つきで示します。 ## まとめ：アイリスプラザの情報漏洩で対象となる項目と、利用者が今日やること [アイリスオーヤマが掲載した第2報](https://www.irisohyama.co.jp/news/2026/?date=1105)によると、10月28日に外部クラウドサービスで不審なファイルを見つけ、サイトと関連システムを止めて調べたところ、第三者の不正アクセスを確認しました。クラウドに保存されていた個人情報は約770万人分で、閲覧または取得された可能性があります。実際に漏れた件数と人数は調査中です。11月5日時点で、不正利用や金銭被害の報告は確認されていません。 利用者が今日やることは2つです。アイリスプラザと同じパスワードをほかのサービスで使っていれば、そちらを変えること。そして、アイリスプラザを名乗るメール・SMS・電話のリンクを開かず、パスワードや認証コードを答えないことです。 | 項目 | 公表内容（2026年11月5日時点） | | --------- | ------------------- | | 対象サイト | 公式通販サイト「アイリスプラザ」 | | 侵入された場所 | 同社が使う外部クラウドサービス | | 保存されていた人数 | 約770万人分 | | 会員の内訳 | 約580万人（退会者を含む） | | 非会員の内訳 | 約190万人 | | カード情報 | 保存なし・影響なし | | サイトの再開 | 未定 | | 正規の窓口 | 0120-108-824（平日・土曜） | ## アイリスプラザ利用者が最初に確かめること：対象の項目、パスワード、正規の窓口 ### 会員約580万人と非会員約190万人で異なる、漏えいの可能性がある項目 第2報は対象を2つに分けています。会員データは退会した人の情報を含む約580万人分で、氏名・住所・電話番号・メールアドレス・性別・パスワード・生年月日などです。退会した人の分にパスワードは含まれません。非会員データは約190万人分で、会員登録をせずに商品を買った人や、キャンペーンに応募した人の氏名・住所・電話番号・メールアドレスです。 全員について全項目が漏れたわけではなく、登録の状況によって項目は異なると同社は書いています。何年も前に一度だけ買った人や、キャンペーンに応募しただけの人も対象に入り得ます。心当たりがある人は、自分が対象だと考えて動くほうが安全です。対象かどうかを自分で調べるページは、11月6日時点で用意されていません。 ### パスワードは暗号化済みでも、同じパスワードの他サービスを先に変える理由 第2報は「パスワードを含む一部の項目は暗号化」していると書いています。ただ、どの方式で暗号化していたかは公表されていません。元に戻せる方式で、鍵も一緒に盗まれていれば、パスワードは読み出せてしまいます。 同社が求めているのは、ほかのサービスで同じパスワードを使っている場合の変更です。漏れたメールアドレスとパスワードの組は、別のECサイトや銀行で順に試されます。メールアドレスと氏名と電話番号がそろって漏れた以上、まず使い回しを断つのが確実です。アイリスプラザ自体はサイトが止まっているので、パスワードは再開後に公式の画面から変えてください。漏れたIDとパスワードを別のサービスで試す手口は[パスワードリスト攻撃の検知の指標と漏えい照合](https://www.issoh.co.jp/tech/details/18730/)で解説しています。 ### 個別メールに紛れる偽の連絡と、0120-108-824など公式が示す問い合わせ窓口 同社は11月5日から、対象の可能性がある人へメールなどで順に連絡するとしています。そのうえで、案内の中でパスワード・暗証番号・認証コードを尋ねることも、メールやSMSのリンク先で入力を求めることもないと明言しました。これを求めてくる連絡は偽物です。同社を装った偽サイトや偽のSNSアカウントが作られるおそれにも触れています。 問い合わせ先は株式会社アイリスプラザ コンタクトセンターの0120-108-824で、受付は平日と土曜の9時30分から17時までです。届いた連絡に書かれた番号ではなく、公式発表の番号に自分からかけてください。チャットボットは24時間受け付けています。流出した個人情報を使って偽の連絡を本物らしく見せる仕組みは[フィッシング詐欺の成立の仕組みと技術的対策](https://www.issoh.co.jp/tech/details/13548/)にまとめました。同じ時期には、メール配信基盤を持つ事業者でも大規模な持ち出しが公表されています（[アララの不正アクセスとメール約7,700万件の持ち出し](https://www.issoh.co.jp/tech/details/19213/)）。 ### 停止中の注文とキャンセル、楽天市場店など影響のない外部モールの店舗 アイリスプラザは原因の特定と再発防止策を済ませてから再開するとしており、時期は決まっていません。止まっているのはアイリスプラザだけではありません。同社のホームファッション専門店「SIMPLE STYLE」と、グループのアイリステックサービスが運営する家電サブスクリプションや配送設置サービスのサイトも、10月28日から止めています。この2つで不正アクセスや漏えいは確認されていないとしています。 アイリスプラザ側のFAQによると、注文済みの商品は順に出荷の準備を進めていて、一部は発送が遅れる場合があります。キャンセルの受け付け窓口は、同社のコンタクトセンターです。楽天市場店・Yahoo!店・auPAYマーケット店など、外部モールの店舗は影響がなく使えると案内しています。 ## 公式発表で追う経過：10月28日の不審なファイル発見から11月5日の第2報まで 同社の発表を日付順に並べると、次のとおりです。 1. 10月28日：利用する外部クラウドサービスで不審なファイルを発見。アイリスプラザと関連システム、SIMPLE STYLEなどのサイトを停止し、侵入経路を遮断 2. 10月29日：警察と個人情報保護委員会へ報告。第1報でサイトの一時停止と不正アクセスの確認を公表 3. 11月5日：第2報で、約770万人分のデータが漏えいした可能性と対象の項目を公表。個別の連絡を開始 ### 第1報と第2報の文言の違いと、まだ公表されていない原因と侵入経路 [10月29日の第1報](https://www.irisohyama.co.jp/news/2026/?date=1029)は、ECサイトで不正アクセスを確認したことと、カード情報の漏えいは確認されていないことだけを伝えていました。侵入先がクラウドであることも、件数も書かれていません。7日後の第2報で、侵入先が「外部クラウドサービス」であること、保存されていた人数、項目の内訳が加わりました。カード情報については「確認されていない」から「保存されておらず、影響を受けていない」へ、言い方が強くなっています。 まだ出ていない情報もあります。どのクラウドサービスか、どうやって入られたか、見つかった不審なファイルは何か、実際に持ち出された件数は何件か。いずれも11月6日時点で公表されていません。第2報の「約770万人」は保存されていた総数で、漏れたと確定した数ではない点に注意してください。 ### 個人情報保護委員会への報告期限から見た、原因と確定件数の続報が出る時期 [個人情報保護委員会の漏えい等の対応ページ](https://www.ppc.go.jp/personalinfo/legal/leakAction/)は、発覚したらまず速やかに報告し、不正の目的で行われたおそれがある場合は発覚日から60日以内に報告するよう求めています。本人の数が1,000人を超える漏えいや、そのおそれがある場合も報告の対象です。発覚日の10月28日を起点にすると、60日後は12月27日です。原因や確定件数は、遅くともそのころまでの続報で出る見込みがあります。速報と確報に書く内容は[個人情報保護委員会への報告義務の実務](https://www.issoh.co.jp/column/details/17840/)で整理しました。 ## 開発側の作業：外部クラウドに置いた会員データの大量読み出しをログで見つける手順 ### 「外部クラウドサービスに保管」の意味と、会員データの写しが残りやすい置き場所 ここからはアイリスプラザの事案を離れた一般論です。同社はクラウドの事業者名も侵入経路も公表していないので、以下は同社の原因を示すものではありません。 ECの会員データは本番のデータベースだけにあるとは限りません。分析用の書き出し、移行作業の途中のCSV、バックアップが、オブジェクトストレージやファイル共有サービスに残ることがよくあります。こうした写しは本番より見られる回数が少なく、権限も緩くなりがちです。バケットが外から読める設定のまま残った事例は[トラスト・ログイン情報漏洩と公開ストレージを防ぐ実装](https://www.issoh.co.jp/tech/details/19247/)で扱いました。点検は「どこに写しがあるか」「誰が読めるか」「読んだ記録が残るか」の3点です。 ### CloudTrailのS3データイベントから許可外の読み出しと大量取得を拾うコード ここで説明に用いるクラウドサービスの例はAWSです。S3のオブジェクトを読んだ記録（GetObject）は、CloudTrailの「データイベント」として残せます。ただし[CloudTrailのデータイベントの説明](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html)のとおり、証跡は初期状態ではデータイベントを記録せず、記録すると追加の料金がかかります。記録が無ければ、何件読まれたかを後から数えられません。 次のコードは標準ライブラリだけで動きます。CloudTrailのログと同じ形のJSONを読み、許可していない主体や送信元からの操作、5分の間に4件以上のオブジェクトを読んだ主体、見慣れないファイルの書き込みを出します。ログに残す項目は[OWASPのLogging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging%5FCheat%5FSheet.html)が挙げる「いつ・どこから・誰が・何に」に合わせました。 ``` # CloudTrailのS3データイベントから「許可外の主体による読み出し」と「短時間の大量読み出し」を拾う（Python 3.8以上・標準ライブラリのみ） # 使い方: python s3_bulk_scan.py import json from collections import defaultdict from datetime import datetime, timedelta # CloudTrailのログファイルと同じ形（Records配列）。実運用ではS3に出力されたログを読む TRAIL = """ {"Records":[ {"eventTime":"2026-11-02T10:00:00Z","eventName":"GetObject","sourceIPAddress":"198.51.100.20","userIdentity":{"arn":"arn:aws:sts::111122223333:assumed-role/app-web/i-0abc"},"requestParameters":{"bucketName":"example-member-data","key":"members/000123.json"}}, {"eventTime":"2026-11-02T23:41:05Z","eventName":"ListObjects","sourceIPAddress":"203.0.113.77","userIdentity":{"arn":"arn:aws:iam::111122223333:user/batch-export"},"requestParameters":{"bucketName":"example-member-data","prefix":"export/"}}, {"eventTime":"2026-11-02T23:41:09Z","eventName":"GetObject","sourceIPAddress":"203.0.113.77","userIdentity":{"arn":"arn:aws:iam::111122223333:user/batch-export"},"requestParameters":{"bucketName":"example-member-data","key":"export/members_part01.csv"}}, {"eventTime":"2026-11-02T23:41:12Z","eventName":"GetObject","sourceIPAddress":"203.0.113.77","userIdentity":{"arn":"arn:aws:iam::111122223333:user/batch-export"},"requestParameters":{"bucketName":"example-member-data","key":"export/members_part02.csv"}}, {"eventTime":"2026-11-02T23:41:15Z","eventName":"GetObject","sourceIPAddress":"203.0.113.77","userIdentity":{"arn":"arn:aws:iam::111122223333:user/batch-export"},"requestParameters":{"bucketName":"example-member-data","key":"export/members_part03.csv"}}, {"eventTime":"2026-11-02T23:41:18Z","eventName":"GetObject","sourceIPAddress":"203.0.113.77","userIdentity":{"arn":"arn:aws:iam::111122223333:user/batch-export"},"requestParameters":{"bucketName":"example-member-data","key":"export/guests_part01.csv"}}, {"eventTime":"2026-11-03T09:12:30Z","eventName":"PutObject","sourceIPAddress":"203.0.113.77","userIdentity":{"arn":"arn:aws:iam::111122223333:user/batch-export"},"requestParameters":{"bucketName":"example-member-data","key":"README_RESTORE.txt"}} ]} """ # 本番で読み出しを許す主体（ロール名）と送信元の範囲 ALLOWED_ROLES = {"app-web"} ALLOWED_NET = "198.51.100." WINDOW = timedelta(minutes=5) # 数える時間幅 LIMIT = 3 # 時間幅の中で読んでよいオブジェクト数 def role_of(arn): # assumed-role/<ロール名>/<セッション名> と user/<ユーザー名> の両方からIAM側の名前を取り出す parts = arn.split(":", 5)[5].split("/") return parts[1] if parts[0] == "assumed-role" else parts[-1] reads = defaultdict(list) # 主体ごとの (時刻, キー) for r in json.loads(TRAIL)["Records"]: ts = datetime.fromisoformat(r["eventTime"].replace("Z", "+00:00")) who = role_of(r["userIdentity"]["arn"]) src = r["sourceIPAddress"] key = r["requestParameters"].get("key") or r["requestParameters"].get("prefix") # 1) 許可していない主体・送信元からの操作 if who not in ALLOWED_ROLES or not src.startswith(ALLOWED_NET): print("[ALIEN]", r["eventTime"], r["eventName"], who, src, key) # 2) 読み出しの件数を時間幅で数える if r["eventName"] == "GetObject": reads[who].append((ts, key)) recent = [k for t, k in reads[who] if ts - t <= WINDOW] if len(recent) > LIMIT: print("[BULK ]", r["eventTime"], who, "objects", len(recent), "-> alert") # 3) 見慣れないファイルの書き込み（脅迫文・置き土産の典型） if r["eventName"] == "PutObject" and who not in ALLOWED_ROLES: print("[DROP ]", r["eventTime"], who, "put", key) print("[total]", {w: len(v) for w, v in reads.items()}) ``` Python 3.14.10（Windows）で実行した結果です。 ``` $ python s3_bulk_scan.py [ALIEN] 2026-11-02T23:41:05Z ListObjects batch-export 203.0.113.77 export/ [ALIEN] 2026-11-02T23:41:09Z GetObject batch-export 203.0.113.77 export/members_part01.csv [ALIEN] 2026-11-02T23:41:12Z GetObject batch-export 203.0.113.77 export/members_part02.csv [ALIEN] 2026-11-02T23:41:15Z GetObject batch-export 203.0.113.77 export/members_part03.csv [ALIEN] 2026-11-02T23:41:18Z GetObject batch-export 203.0.113.77 export/guests_part01.csv [BULK ] 2026-11-02T23:41:18Z batch-export objects 4 -> alert [ALIEN] 2026-11-03T09:12:30Z PutObject batch-export 203.0.113.77 README_RESTORE.txt [DROP ] 2026-11-03T09:12:30Z batch-export put README_RESTORE.txt [total] {'app-web': 1, 'batch-export': 4} ``` Webアプリのロール（app-web）が自社の範囲から1件読んだだけの行は、何も出ません。batch-exportという書き出し用のユーザーは、許可外の送信元から一覧を取り、13秒で会員と非会員のファイル4件を読んでいます。翌朝には見慣れないファイルを置きました。書き出し用に作った長期のアクセスキーが漏れると、この形になります。 本番では、ALIENの行は1件でも調べる対象にしてください。件数の上限は、夜間の集計バッチなど正規の大量読み出しを先に洗い出してから決めます。M365など別のクラウドでファイルの大量ダウンロードを監査ログから追う手順は[サントリーの不正アクセスとM365の監査ログで調べる手順](https://www.issoh.co.jp/tech/details/19215/)で、サーバー側の痕跡の追い方は[不正アクセスの調べ方とログの確認方法](https://www.issoh.co.jp/tech/details/2788/)で扱っています。 ### 公開設定とデータイベントの記録を確かめる、AWS CLIの4つのコマンド 検知の前に、読める範囲と記録の有無を確かめます。[S3のブロックパブリックアクセス](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html)には4つの設定があり、アカウント全体・バケット・アクセスポイントの単位で掛けられます。会員データを置くバケットは、4つともtrueが前提です。 ``` # アカウント全体と対象バケットのブロックパブリックアクセスを確かめる（4項目すべて true が前提） aws s3control get-public-access-block --account-id 111122223333 aws s3api get-public-access-block --bucket example-member-data # 証跡がS3のデータイベント（GetObject など）を記録しているかを確かめる aws cloudtrail get-event-selectors --trail-name management-trail # 記録していなければ、管理イベントを残したまま対象バケットのデータイベントを足す aws cloudtrail put-event-selectors --trail-name management-trail --advanced-event-selectors '[{"Name":"Management events","FieldSelectors":[{"Field":"eventCategory","Equals":["Management"]}]},{"Name":"Member bucket data events","FieldSelectors":[{"Field":"eventCategory","Equals":["Data"]},{"Field":"resources.type","Equals":["AWS::S3::Object"]},{"Field":"resources.ARN","StartsWith":["arn:aws:s3:::example-member-data/"]}]}]' ``` put-event-selectorsは、証跡にある既存のセレクタを上書きします。管理イベントの行を書き忘れると、それまで残っていた管理イベントの記録が止まるので、先にget-event-selectorsで現状を控えてください。バケット名の末尾の「/」もARNの値に含める、とドキュメントは注記しています。証跡の設計と料金の実額は[CloudTrailの証跡設計と料金実額](https://www.issoh.co.jp/tech/details/17649/)にまとめました。 ### パスワードは暗号化ではなくハッシュで保存する、OWASPが示すArgon2idの設定値 [OWASPのPassword Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password%5FStorage%5FCheat%5FSheet.html)は、パスワードを暗号化ではなくハッシュで保存するよう求めています。暗号化は鍵があれば元に戻せる双方向の処理で、ハッシュは元に戻せない一方向の処理だからです。推奨はArgon2idで、最低でもメモリ19MiB・反復2回・並列度1。古いシステムでbcryptを使うなら、作業係数を10以上にし、入力が72バイトで切れる制限に注意します。SHA-256のような高速なハッシュは、総当たりを速く回せるため保存には向きません。 自社の会員DBで確かめるのは、保存列の中身の形です。「$argon2id$」や「$2b$」で始まる値ならハッシュ、同じパスワードの利用者どうしで同じ値が並ぶならソルトが無い、復号の処理がアプリにあるなら暗号化です。後の2つなら、次回のログイン時にArgon2idへ置き換える移行を組みます。 ## 事業者の判断：会員データの写しをクラウドに置くECが診断を入れる条件 ### 書き出し用の鍵と写しの置き場所を把握していないなら、年1回の点検を入れる 今回の事案で目を引くのは、退会した会員と、会員登録をしていない購入者・キャンペーン応募者まで同じ場所に入っていた点です。使い終わった人の情報を残すほど、漏れたときの人数は膨らみます。 次の3つのどれかに当てはまるなら、外部の脆弱性診断と、クラウドの設定の点検を年1回入れるべきです。会員データの写しがどのストレージに何本あるかを一覧にできないこと。書き出しや連携のために作った長期のアクセスキーが、作った人の異動後も残っていること。ストレージの読み出しの記録を取っておらず、何件読まれたかを後から数えられないことです。逆に、会員情報を持たず決済も外部に任せている小さなECなら、まず管理画面の公開範囲とアカウントの棚卸しを済ませれば足ります。APIの認可とレート制限の実装は[API不正アクセス対策の実装手順](https://www.issoh.co.jp/tech/details/18346/)、診断の種類と費用の考え方は[脆弱性診断の種類・費用相場と外注の判断基準](https://www.issoh.co.jp/column/details/13101/)、企業として点検する範囲は[不正アクセス対策の点検手順](https://www.issoh.co.jp/column/details/18313/)で解説しています。 ECサイトや会員基盤、クラウドに置いたデータの読める範囲を第三者に確かめてもらいたいなら、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で相談できます。 ## よくある質問 アイリスプラザの情報漏洩について、利用者から出やすい質問をまとめました。 ### アイリスプラザの情報漏洩で、自分が対象か確かめる方法はありますか？ 11月6日時点で、対象かどうかを自分で調べるページはありません。同社は調査結果を踏まえて、対象の可能性がある人へ順にメールなどで連絡するとしています。保存されていたのは会員（退会者を含む）約580万人分と非会員約190万人分なので、過去に一度でも購入やキャンペーン応募をした人は対象と考えて備えてください。 ### アイリスプラザのパスワードは変えたほうがいいですか？ 同社が求めているのは、ほかのサービスで同じパスワードを使っている場合の変更です。アイリスプラザのパスワードは一部の項目とともに暗号化されていましたが、方式は公表されていません。使い回しているサービスがあれば、そちらを先に変えてください。アイリスプラザ自体は停止中なので、再開後に公式の画面から変えます。 ### クレジットカードの情報は漏れていませんか？ 第2報によると、クレジットカードの情報は侵入された外部クラウドサービスに保存されておらず、不正アクセスの影響を受けていないことを確認したとしています。カードの再発行を求める案内も出ていません。ただし、カード会社を名乗って番号を聞き出す偽の連絡が来るおそれはあるので、明細は普段どおり確かめてください。 ### アイリスプラザはいつ再開しますか？注文した商品はどうなりますか？ 再開の時期は未定で、原因の特定と再発防止策を済ませてから知らせるとしています。注文済みの商品は順に出荷の準備を進めていて、一部は発送が遅れる場合があるという案内です。キャンセルは0120-108-824のコンタクトセンターで受け付けています。楽天市場店などの外部モールの店舗は、影響がなく使えると案内されています。 ### アイリスオーヤマを名乗るメールやSMSが本物か見分けるにはどうすればいいですか？ 同社は、案内の中でパスワード・暗証番号・認証コードを尋ねたり、メールやSMSのリンク先で入力を求めたりすることはないとしています。これを求める連絡は偽物です。迷ったらリンクを開かず、公式発表にある0120-108-824（平日・土曜の9時30分から17時）へ自分からかけて確かめてください。 ## 関連記事 - [トラスト・ログイン情報漏洩：2,492社・45,030人の原因と利用企業の確認点、公開ストレージを防ぐ実装](https://www.issoh.co.jp/tech/details/19247/)：クラウドストレージの公開設定が原因になった事案と防ぎ方 - [アララの不正アクセス：メール約7,700万件の持ち出しと契約企業が行うAPIキー再設定・代替送信・連名報告](https://www.issoh.co.jp/tech/details/19213/)：同じ時期に公表された大規模な持ち出しと二次被害メール - [パスワードリスト攻撃とは？検知の指標と漏えい照合・レート制限の実装](https://www.issoh.co.jp/tech/details/18730/)：漏れたパスワードを別のサービスで試す手口と防ぎ方 - [個人情報保護委員会への報告義務｜対象4類型・速報3〜5日と確報30日の実務](https://www.issoh.co.jp/column/details/17840/)：漏えい時に事業者が報告する内容と期限 - [CloudTrailとは？証跡設計と料金実額・Lake新規受付終了後の構成をCLIで解説](https://www.issoh.co.jp/tech/details/17649/)：データイベントを記録する証跡の設計と費用 --- 出典: [アイリスオーヤマ情報漏洩：アイリスプラザ770万人分の対象項目と本物の連絡の見分け方]()（株式会社一創）