製造業のランサムウェア対策について、Illumioが2026年10月9日に公開した記事「How Manufacturers Can Keep One Breach From Stopping the Plant」を読んだ。Coca-Cola傘下の乳製品事業Fairlifeが7月にランサムウェア攻撃を受けて米国内の生産を止めた件を入口に、IT側が侵害されても工場を止めないための備えを整理した記事である。ここでは、受託開発で業務システムを作っている立場から、IT/OT分離を「ネットワークに線を引く話」ではなく「切り離した後に工場の何が動くかを決めておく設計の話」として読み替える。
先に断っておくと、私は制御系ネットワーク (OT) のセキュリティを専門にしているわけではない。評価できるのは、工場とつながる業務システムを作る側の論点までである。
要点 (出典の事実のみ)
- 記事によると、7月にランサムウェア攻撃を受け、Coca-ColaのFairlife乳製品事業は米国内の生産を停止した。Coca-Colaは、製品の安全性と品質に影響はなかったと説明している。その後ランサムウェアグループのAnubisが犯行を主張し、1テラバイトのデータを盗んだとして、身代金が支払われなければ公開すると脅した。
- Coca-Colaが攻撃を公表してから11日後の時点で、Fairlifeは米国内4工場で生産の大部分を再開していた。
- Black Kiteは、2026年1月1日から7月29日までに公表された製造業のランサムウェア被害を世界で1,183件追跡した。2025年の同じ期間より約40%多く、2024年の通年件数も上回っている。
- Illumioで重要インフラ向けソリューションのディレクターを務めるTrevor Dearing氏は、最初の作業として、設備の一覧ではなく「生産がどう動いているか」と、それを支えるシステムの依存関係を地図にすることを挙げる。そのうえで、接続の一つひとつに目的を持たせ、ITとOTの間と工場の内部の両方でセグメンテーションを行うよう勧めている。保守を担う外部の業者には担当する設備だけにアクセスさせ、その遠隔接続は製造業者自身が持つID管理を通すべきだとしている。
- 同氏は、事業側の侵害から生産を切り離す準備済みの手段を「big red button」と呼ぶ。計画には、何を切断するか、誰が承認するか、どのサービスを動かし続けるかを明記し、実際にテストする必要があるという。共有のログインサービス、遠隔サポート、外部データに依存する工程があるため、テストでは、継続できる工程、安全に止めるべき工程、最初に復旧するものを確認する。
IT/OT分離は「線を引く」より「切った後に何が動くか」
Fairlifeで何が起きたかの詳細は、記事には書かれていない。侵入の経路も、生産を止めた理由も、再開までに11日かかった内訳も分からない。したがって以下は同社の対応の評価ではなく、記事の提言を自分の仕事に引きつけた読み方である。
記事の中で実務に一番効くと私が考えるのは、切り離しの計画に「どのサービスを動かし続けるか」を書け、という部分だ。ネットワークを分けること自体は、機器と設定の作業として進められる。難しいのは、切った瞬間に工場側で何が使えなくなるかを、事前に言える状態にしておくことである。
記事は依存先の例として、共有のログインサービス、遠隔サポート、外部データを挙げている。業務システムを作る側から見ると、これはそのまま設計の話になる。現場の端末のログインが本社側の認証基盤に依存していれば、ネットワークを切った時点で現場は端末に入れなくなる。生産指示や品目のマスタを上位のシステムへ都度取りに行く作りなら、切り離した後は指示が出せない。設備が無事でも、「何を、いくつ、どの順で作るか」が現場に届かなければ生産は続かない。
つまりIT/OT分離は、セキュリティの要件であると同時に、上位のシステムが使えない間、工場がどこまで自力で動けるかという縮退運転の要件である。これは非機能要件のうち発注側が決めるべき可用性・セキュリティの項目と同じ種類の問いだ。決めないまま作ると、切り離しのボタンは「押せるが、押すと工場も止まるボタン」になる。
自社で作るとしたら、どこが難所か
記事は、遠隔保守やデータ共有が効率を上げる一方で、工場への新しい経路を開くと指摘している。同業として、この指摘は他人事ではない。製造業のDXやAIの案件で開発会社が作っているのは、まさにその「新しい接続」だからだ。設備のデータを集めて可視化する。基幹システムの計画を現場に流す。検査AIの判定をPLCに返して不良品の排除まで実行する。どれも価値の源泉はITとOTをつなぐことにあり、つなぐほど、切り離したときに失うものも増える。
作る側から見た難所は3つある。
- 依存関係の地図は、作った側にしか正確に書けない。 記事が求めているのは設備の一覧ではなく依存関係の地図である。あるシステムがどの認証基盤、どのマスタ、どの外部サービスに依存しているかは、ネットワーク機器の設定だけからは読み切れない。開発会社が設計書として残すべき情報だ。
- 切れている間の挙動は、後から足しにくい。 上位と切れている間に現場で入力された実績をどこに溜め、復帰後にどう突き合わせるか。これはデータ整合性の設計であり、通信が常につながっている前提で作った画面と処理を、後から直すことになる。最初の設計で決めておくほうが安い。
- 「テストした」と言える環境が要る。 記事は、誰も実行したことのない計画は推測にすぎないと書いている。業務システムの側も、上位を遮断した状態で主要な操作が通るかどうかを、検証環境で確かめられるようにしておく必要がある。
開発会社・SIerの事業判断にどう効くか
同業の意思決定者にとって、この記事は3つの点で実務に関わる。
1つ目は、要件定義と見積りに「切り離し時の挙動」を入れることである。製造業向けの提案で接続を1本足すたびに、「この接続が切れたら何が止まり、代わりの手順は何か」を1行書く。工数は増えるが、発注側の経営層がいずれ説明を求められる部分であり、提案の差になる。
2つ目は、自社の保守経路の点検である。記事は、外部の業者のアクセスを担当設備に限り、遠隔接続は製造業者自身のID管理を通すべきだとしている。受託で保守を請けている開発会社は、ここで言う「外部の業者」に当たる。自社の保守用の接続が顧客のID管理を通っているか、不要な範囲まで届いていないかは、顧客に指摘される前に自分で確かめられる。
3つ目は、体制である。記事は、ITのセキュリティ担当は脅威を理解していても生産を知らず、工場側は設備を知っていても新しい接続のリスクを把握しきれないことがあり、どちらか一方では解決できないと述べている。開発会社は、要件を聞くために両方と話す立場にいる。依存関係の地図づくりに最初から加われば、納品物はシステムだけでなく「止まったときの手順」まで広がる。
私は、AIで実装が速くなるほど、エンジニアの価値はコードを書く量から、本番環境を動いている状態に保つ能力へ移ると考えている。工場はその最たる例で、止まれば出荷が止まる。攻撃の手口の変化は2026年のサイバーセキュリティ動向を整理した記事でも扱ったが、製造業の場合は侵入を防ぐ話と同じ重さで、侵入された後に何を動かし続けるかを設計に入れる必要がある。
数字と出典の読み方について
1,183件は、Black Kiteが追跡した「公表された」被害の件数である。公表されていない被害は含まれない。前年同期より約40%多いという比較も、被害そのものの増加に加えて、公表される割合の変化を含んでいる可能性がある (これは私の推測で、記事には書かれていない)。
11日という数字は、攻撃の公表から「生産の大部分」の再開までの日数で、全面復旧までの日数ではない。何に時間がかかったのかも記事からは分からないため、この数字を自社の復旧目標の基準にすることはできない。
出典はIllumioの自社ブログで、語り手も同社の担当者である。提言がセグメンテーションを中心に組まれている点は、その前提で読むのがよい。ただし、依存関係の地図、切断の承認者、テストという3点は、どの製品を使うかに関係なく成り立つ。
また、記事はOTへのゼロトラスト適用に関する米国政府の共同ガイダンスと、英国National Cyber Security Centreの8月のアラートを引いているが、私は原文までは確認していない。人や設備の物理的な安全に関わる制御系の設計は専門家の領分であり、ここで述べたのは業務システム側の論点に限る。
出典: How Manufacturers Can Keep One Breach From Stopping the Plant (Illumio, 2026年10月9日)
