冷蔵設備へのサイバー攻撃｜仏スーパー数百店の食品廃棄から読む、更新が止まった接続機器を誰が管理するか

フランスの大手スーパー数百店で、冷蔵設備がサイバー攻撃を受けて温度が上がり、生鮮品や冷凍品の廃棄に追い込まれた。AFPが2026年10月12日に配信した記事「French supermarkets suffer refrigerator shutdown after 'unprecedented' cyberattack」が伝えた件である。情報漏えいではなく、攻撃がそのまま物理的な損失になったOTセキュリティの事例だ。ここでは、受託開発で業務システムを作っている立場から、更新が止まったまま外部とつながっている機器を、誰がどう管理するのかという問いとして読む。

先に断っておくと、私は冷凍・冷蔵設備の制御や、制御系ネットワーク (OT) のセキュリティを専門にしているわけではない。評価できるのは、現場の設備とつながる業務システムや監視の仕組みを作る側の論点までである。

要点 (出典の事実のみ)

E.Leclerc、Intermarché、Coopérative Uが、サイバー攻撃で冷蔵設備の温度が上がったことを確認した。Intermarchéと傘下のNettoで少なくとも300店、Coopérative Uで100店超、E.Leclercでも複数店が標的になった。Intermarchéは、影響を受けた店舗では生鮮品・冷凍品をすべて廃棄せざるを得ないとした。
Coopérative UのDominique Schelcher CEOは、攻撃を「前例のない」ものと表現し、日曜夜から冷蔵設備に影響が出ていると述べた。BFM TVは、攻撃者が遠隔操作で多くの店舗の冷蔵設備を強制的に霜取り (解凍) させたと報じている。
E.Leclercは、攻撃が冷蔵設備の納入業者の1社を狙ったものだと説明した。情報筋によると標的はデンマークのDanfossの冷蔵制御システムで、同社は、影響を受けた機器の大半はソフトウェアやセキュリティの更新をもう受けていない「レガシー」製品だとしている。対象は冷蔵用コントローラーのAK-SM800とAK-SC355で、AK-SM800の一部は古いファームウェアのままだった。同社は以前からこれらの機種の更新を勧めていたという。
フランスのサイバーセキュリティ機関は同社ソフトウェアの脆弱性を特定してベンダーに連絡し、欧州の関係機関と連携して影響を受けた他の企業の特定と警告を進めている。パリ検察庁は捜査を開始し、攻撃が火災も引き起こしたとしている。
セキュリティ企業AlmondのAntoine Hautin氏は、冷蔵設備のような産業機器が長く外部から隔離されていたのに対し、いまはセンサーや遠隔監視を通じてネットにつながっていると指摘した。

問題は「古い機器」より「古いままつながっている機器」

記事には、侵入の経路や、どの設定が悪用されたかは書かれていない。したがって以下は今回の事案の原因分析ではなく、記事にある事実を自分の仕事に引きつけた読み方である。

私が一番重く見たのは、Danfossの説明にある「更新をもう受けていない」という部分だ。機器が古いこと自体は珍しくない。冷蔵設備のような設備は、業務システムよりずっと長く使われる。問題は、作られた当時は外部につながる前提ではなかった機器が、遠隔監視の仕組みを通じてネットに出ていき、その後もファームウェアが古いまま残っていることにある。Hautin氏の指摘も同じ構図を指している。

ここで効いてくるのは、更新を誰がやる契約になっているかである。ベンダーは更新を勧めていたと言う。店舗側は設備を運用している。遠隔監視の仕組みを入れた業者や、データを集めて本部の業務システムにつないだ開発会社もいるかもしれない。関係者が多いほど、「更新を勧めた」と「実際に更新した」の間が誰の仕事でもなくなる。私はこれを技術の問題というより、責任の分担が書かれていない問題だと考えている。

監視の仕組みを作る側から見た難所

設備のデータを集めて見える化する、温度の異常を本部や保守業者に通知する。製造業や小売のDX案件で開発会社が作っているのは、まさにこの「設備と外をつなぐ線」である。今回の件を作る側として読むと、難所は3つある。

監視の線は、操作の線にもなり得る。 温度を読むために入れた接続が、設定を書き換えられる経路にもなっていないか。BFM TVの報道どおり遠隔で霜取りを起動されたのだとすれば、読むだけで足りる用途に、書き込みまで許す接続が残っていた可能性がある (これは私の推測で、記事には書かれていない)。読むだけの用途なら、最初から書き込めない構成にしておくほうが安全で、後から絞るより安い。
異常の検知を、攻撃された機器そのものに頼らない。 制御機器が乗っ取られれば、その機器が出すアラームも当てにならない。食品の廃棄を減らせるかどうかは、温度の上昇にどれだけ早く人が気づけるかで決まる。独立した温度センサーや、現場の人が見回る手順のように、制御系とは別の経路で異常に気づける仕組みを残しておくべきだと私は考えている。
接続している機器の一覧と、それぞれの更新状況を持っておく。 どの店舗のどの機器が、どのファームウェアで、どの経路から外とつながっているか。これが分からなければ、ベンダーから更新の勧告が来ても、どこを直せばよいか判断できない。作った側が設計書として残せる情報であり、残すべき情報だ。

先日、Fairlifeの生産停止を扱った記事で、IT/OT分離は「切り離した後に工場の何が動くか」を決める設計の話だと書いた。あちらはIT側の侵害で工場を止めた例で、今回は設備側が直接操作されて損失が出た例である。方向は違うが、設備とつながる仕組みを作る側が、つながった後の挙動まで設計に入れる必要がある点は同じだ。

開発会社・SIerの事業判断にどう効くか

同業の意思決定者にとって、この件は3つの点で実務に関わる。

1つ目は、提案と見積りに機器の保守期間を入れることである。設備とつながるシステムを提案するとき、つなぐ相手の機器がいつまで更新を受けられるのかを確認し、更新が止まっている機器を外につなぐなら、その前提とリスクを提案書に書く。発注側の経営層がいずれ説明を求められる部分であり、書いてある提案と書いていない提案では信頼の差が出る。

2つ目は、保守契約の範囲を言葉にすることである。開発会社が保守を請けていても、つないだ先の設備のファームウェア更新まで含むのか、含まないなら誰がやるのか。ここを曖昧にしたまま運用に入ると、事故の後に責任の押し付け合いになる。ニチレイの事案で高畑が整理した委託先依存のBCPと同じく、自社が「委託先」として相手の事業継続に組み込まれていることを前提に契約を書くべきだ。

3つ目は、守るべき土台への投資を削らないことである。私は普段から、作って試して捨てる開発を進める一方で、セキュリティや本番運用は守るべき土台だと考えている。監視や見える化の案件は、画面ができた時点で価値が見えるため、接続の権限設計や更新の運用は後回しにされやすい。今回のように損失が物理的に出る領域では、その後回しがそのまま事業の損失になる。