コンテンツにスキップ
← インシデント一覧に戻る

コープいしかわ、委託先ランサム被害でギフト注文の組合員情報最大約6,020件流出の可能性

項目内容
発生日2026年4月10日にコープいしかわが認知
対象組織・業界生活協同組合コープいしかわ(生活協同組合/小売・流通)
攻撃手法委託先へのランサムウェア攻撃、委託先サーバ内ファイルの暗号化
情報源Security NEXT(2026年5月14日)

生活協同組合コープいしかわの委託先がランサムウェア攻撃を受け、組合員のギフト注文情報1,756件(氏名・住所・電話番号・注文履歴)と届け先情報4,264件が保管されていたサーバ内ファイルが暗号化されたと2026年5月14日に公表しました。流出の痕跡は現時点で確認されていないものの、可能性ありとして通知等の対応が進められています。

  • 2026年4月10日: コープいしかわが委託先でのランサム被害を認知
  • 2026年4月17日: 個人情報保護委員会に報告
  • 2026年5月14日: 事案を公表

同組合の公表によれば、委託先がランサムウェアによるサイバー攻撃を受け、コープいしかわの組合員情報が保管されていたサーバ内ファイルが暗号化されたとされています。委託先での侵入経路・攻撃手法の詳細は現時点で公表されていません。

以下は公表事実から考えられる仮説であり、同組合が公表したものではありません。

  1. 委託先での侵入経路は独立している: 委託先がランサム攻撃を受けた形であり、コープいしかわ本体のシステム侵害ではないと考えられます
  2. ギフト注文情報が「同じ委託先サーバに集約されていた」構造: 注文者側の情報(1,756件)と、届け先側の情報(4,264件)が同一サーバに保管されていたことで、単一の攻撃で両方が影響範囲に入ったと考えられます
  3. 流出痕跡が未確認ながら「可能性あり」として通知に進む点: 暗号化型で外部流出のログが取れない状態でも、影響範囲の確定と説明責任を優先する対応方針を採っていると考えられます

1. 委託先に預けたデータの「保管範囲」を平時から棚卸ししておく: 本件では、注文者側と届け先側という2種類のデータセットが同じ委託先サーバに存在していました。委託先が事故を起こした際、自社の影響範囲を即座に説明できるかは、「何を、どの単位で、いつから預けているか」を平時から把握できているかどうかで決まります。

2. 委託契約に「侵害時の影響範囲調査プロセス」を明示する: 委託先のインシデント時、自社側の影響件数の算定は、委託先の調査結果を待ってから始まる場合が多く、公表・通知のタイムラインが長期化しがちです。契約段階で「侵害検知から◯日以内に影響範囲を報告」「調査ログの共有形式」を定めておくと、自社側の意思決定が早まります。

3. 流出痕跡が確認できない場合も「可能性ベース」で通知する運用: 暗号化型ランサムでは、窃取ログが確認できないケースがあります。それでも保守的に「可能性あり」として通知する運用は、組合員・顧客への説明責任の観点から今後の標準になっていく可能性があります。

ヤグラの視点 — 影響範囲の自動調査、同じデータが誰の分まで含まれていたか

Section titled “ヤグラの視点 — 影響範囲の自動調査、同じデータが誰の分まで含まれていたか”

委託先が攻撃を受けた本件では、注文者1,756件と届け先4,264件が同じサーバに保管されていました。この事実自体は事後の調査で明らかになったものですが、「同じデータの塊が誰の分まで含まれていたか」を語れるかどうかは、通知の精度と信頼を分けます。委託先での侵害を自社が直接検知することはできませんが、自社側でも「どのデータを、どの単位で、いつから預けているか」を継続的に管理し、報告を受けた瞬間に影響件数と対象者を即座に切り出せる状態を持つことは可能です。委託先事故に対する初動の質は、「事後にお願いして調べてもらう」ではなく、「自社側でも影響範囲の骨格を掴めている」に近づけていく方向で改善します。同時に、自社が委託先である場合は、預かったデータの範囲と対象顧客をAIが即応的に絞り込める体制が、報告先である委託元組織の初動を助けます。

自組織が委託を受けたメールデータ等の影響範囲を、報告後にAIが即応で分析する仕組みは、二次被害を断つ実務の基礎になります。→ PhishAI

委託先の侵入経路、リークサイトへの掲載有無、対象組合員への通知進捗を注視し、判明次第本記事に追記します。

日時内容
2026-05-14第一報を公開