セキュリティ対策に、終わりはあるのか。──SASE導入を止めた工場長と、五人の証言【藪の中】

ある製造業で、全社的なSASE導入プロジェクトが進められていた。

本社では導入方針が承認され、情シスは製品選定を終え、展開計画も作成していた。

ところが、工場への展開を目前にして、一人の工場長が待ったをかけた。

「このままでは、うちの工場には入れられません」

セキュリティ強化に反対する工場長。

最初は、そう見えた。

しかし、関係者の話を聞いていくと、別の問題が浮かび上がってくる。

いったい、誰が導入を止めたのだろうか。

そして、そもそも何をもって「導入完了」とするつもりだったのだろうか。

※本記事は、製造業のセキュリティ導入で検討すべき論点を整理するための架空のケーススタディである。登場人物、発言、会議記録、出来事は創作であり、特定の企業や実際の事故を描いたものではない。

この記事はこんな人へ

• 製造業でSASEやゼロトラストの導入を検討している人

• 情シスと工場現場の意見が合わず、対策が進まない人

• セキュリティ対策をどこまで実施すべきか、判断に迷っている人

第一の証言｜情シス責任者「工場だけが、最後まで了承しなかった」

情シス責任者は、少し困った表情で説明した。

「現在のVPNについても、認証方式や接続可能な範囲、脆弱性管理、監視体制を見直す必要があります。今回は、利用者ごとに接続先を制限し、多要素認証を徹底する計画でした」

本社の一般業務端末では、すでに試験導入を終えていた。

試験対象の範囲では、大きな問題は確認されていない。

残るのは工場と、設備保守を担当する外部業者の接続だった。

「ところが工場長から、導入を延期してほしいと言われたんです」

ここまで聞けば、工場側がセキュリティ対策に消極的だったようにも見える。

しかし、工場長の証言は違っていた。

第二の証言｜工場長「セキュリティ強化には賛成です。ただ、止まったときは誰が戻すんですか」

「私は反対していません。むしろ、工場を守るための対策なら進めたいと思っています」

工場長が問題にしていたのは、導入そのものではなかった。

一部の製造設備は、外部の保守会社による遠隔支援を受けている。

設備に異常が発生した場合、現場担当者だけでは復旧できないこともある。

「新しい仕組みに変えたあと、夜間に設備が止まったらどうするのか。認証できない、接続できないというとき、誰に連絡すればよいのか。その確認ができていなかったんです」

情シスの試験は、本社の一般業務端末を中心に行われていた。

工場長が求めていたのは、工場特有の運用条件を含む検証だった。

最初の印象が少し変わる。

導入を止めていたのは、現場の抵抗だけではなかったのかもしれない。

第三の証言｜設備保守会社「接続方法が変わるとは聞いていました。でも、どう変わるのかは知りませんでした」

さらに、設備保守会社の担当者から別の話が出てきた。

「遠隔保守の接続方法が変わるとは聞いていました。ただ、具体的な認証方式や、緊急時の手順までは共有されていませんでした」

保守会社は、いつでも自由に工場へ接続できる状態を維持したいわけではない。

必要な設備へ、必要な時間だけ、安全に接続できればよい。

しかし、新しい接続方式で保守作業が成立するかは、まだ検証されていなかった。

ここで一つ、見落とされていた当事者が現れた。

セキュリティを強化する側と、工場を動かす側。

その二者だけで決められる問題ではなかったのである。

第四の証言｜経営層「対策を進めるように指示した。止めてよいとは言っていない」

経営層にも事情があった。

サイバー攻撃によって生産が止まれば、顧客への供給責任に影響する。

技術情報が流出すれば、企業の競争力にも関わる。

だからこそ、対策を先送りにはできなかった。

「ただ、現場を止めてまで導入しろと指示したつもりはありません」

では、導入スケジュールと生産継続が衝突した場合、誰が判断することになっていたのだろうか。

その問いに対する答えは、まだ決まっていなかった。

第五の証言｜プロジェクト担当者「計画書には、導入完了日がありました」

最後に、プロジェクト担当者が計画書を持ってきた。

そこには、拠点ごとの展開予定、端末への設定、既存VPNからの移行、利用者への案内が整理されていた。

一見すると、よくできた計画である。

しかし、確認してみると、工場について次の項目が未確定だった。

• 保守会社の遠隔接続が新方式でも成立するか

• 障害時に従来方式へ戻す判断を誰が行うか

• 工場の操業条件を踏まえた切り替え時間帯

• 緊急時の連絡先と責任分界

• 工場に影響が出た場合の復旧確認方法

導入完了日を決める仕組みはあった。

だが、工場を安全に切り替えられたと判断する条件が、十分に定義されていなかった。

ここで、事件の見え方が変わった。

工場長が導入を止めたことは、この物語の中で確認できた事実である。

しかし、それを単純に「セキュリティへの理解不足」と片づけることはできない。

一方で、工場側がすべて正しかったとも限らない。

既存の接続方式を維持することにも、管理すべきリスクはある。

工場側には、必要な保守条件を具体的に示し、代替案の検証に協力する責任がある。

問題は、誰か一人が正しいかどうかではなかった。

導入するか、しないか。その二択の前に、何を確認できれば導入してよいのかが決まっていなかった。

セキュリティは、どこまでやれば十分なのか

ここで、最初の問いに戻りたい。

セキュリティ対策は、どこまで実施すれば十分なのだろうか。

ランサムウェアへの対策を入れる。

多要素認証を導入する。

SASEを導入する。

端末を監視する。

バックアップを取得する。

対策を並べ始めれば、終わりが見えなくなる。

攻撃者の手口も変わるため、「これさえ導入すれば、もう安全です」とは言えない。

しかし、だからといって、完成条件を決められないわけではない。

大切なのは、製品の数ではなく、事業として何を守るのかを決めることである。

私は、実務上の整理として、次の四つの問いを考えたい。

守る。

重要な情報や設備に、誰が、どのような条件でアクセスできるのか。

広げない。

一つの端末やアカウントが侵害された場合、被害が他の設備や工場へ拡大するリスクを、どこまで低減できているか。

気づく・対応する。

異常が発生したとき、誰が検知するのか。

そして、誰が接続遮断や操業継続・停止を判断し、誰に報告するのか。

戻せる。

業務が停止した場合、何を、どの順番で、どの程度の時間を目標に復旧するのか。

もちろん、これらだけですべてのリスクが解消するわけではない。

それでも、対策の必要性を議論するための共通言語にはなる。

なお、この四つは本記事独自の実務整理である。NIST Cybersecurity Framework 2.0では、サイバーセキュリティリスクの管理を「統治・識別・防御・検知・対応・復旧」の六つの機能で整理している。

SASEは、工場を守るための一部である

SASEは、ネットワーク機能とセキュリティ機能を組み合わせ、利用者や拠点から業務システムへのアクセスを安全に管理するための有力な選択肢である。

例えば、ZTNAを活用し、外部保守会社に対して工場ネットワーク全体への広範な接続を許すのではなく、認証・認可された利用者に必要な接続先だけを許可する設計を検討できる。

ただし、ZTNAを導入すれば、そのまま制御設備への安全な接続が完成するわけではない。

外部保守会社から制御設備への接続には、設備の仕様や保守契約を踏まえ、産業用DMZ、踏み台環境、アクセス承認、操作ログなどを組み合わせた個別設計が必要になる場合がある。

また、工場内のすべての制御通信をSASEに置き換えればよい、という話でもない。

一般的なIT環境と、PLCなどを含むOT環境では、求められる条件が異なる。

設備の安全性、通信の特性、保守方法、停止できる時間帯。

それらを確認せずに製品の展開範囲だけを広げると、セキュリティ強化のための変更が、別の事業リスクを生みかねない。

だからこそ、SASEの導入範囲と、工場OTの保護対策は、共通のリスク評価に基づきながらも、それぞれの特性に応じて設計する必要がある。

これは、NISTのOTセキュリティガイドや、2026年に公開されたOTの安全な接続に関する国際共同ガイダンスの考え方とも整合する。

解決への階段｜製品を選ぶ前に、七つのことを決める

今回のケースを踏まえると、製造業のセキュリティ強化は、次の順番で考えたい。

第一段階｜守るべき事業と重要資産を決める。

何が止まると、事業に重大な影響が出るのか。

工場、製造設備、生産管理システム、設計情報など、守る対象を明らかにする。

第二段階｜接続経路を可視化する。

本社・工場・クラウド・保守会社が、どのようにつながっているのかを確認する。

例外的な接続や、担当者しか知らない保守経路も対象にする。

第三段階｜リスクと事業影響を評価する。

侵入される可能性だけでなく、侵入された場合に何が起きるかを考える。

情報流出なのか。

生産停止なのか。

復旧に時間がかかることなのか。

影響の大きさによって、対策の優先順位は変わる。

第四段階｜基本対策を点検する。

多要素認証、権限管理、端末保護、ネットワーク分離、脆弱性管理、バックアップなどを確認する。

新しい製品の導入前に、既存対策が適切に機能しているかを見る。

第五段階｜SASEの適用範囲を決める。

一般IT端末、クラウド利用、拠点間通信、外部保守接続などを整理し、SASEで対応する範囲と、OT側で個別設計すべき範囲を分ける。

第六段階｜切り替え条件と復旧条件を検証する。

新方式で業務が成立するか。

緊急保守が必要になったとき、誰が対応するのか。

問題が起きた場合、どの条件で切り戻すのか。

工場への影響を含めて確認する。

第七段階｜導入後も機能を確かめ続ける。

監視、インシデント対応訓練、復旧試験、接続権限の棚卸しを継続する。

導入したことではなく、必要なときに機能することを確認する。

この順番なら、セキュリティ製品の導入が目的化しにくくなる。

今日、五分だけ考えてみる

自社のセキュリティ対策について、次の問いを書き出してみてほしい。

「もし明日、最も重要な業務システムが使えなくなったら、誰が、何を基準に、復旧の優先順位を決めるのだろうか」

次に、その判断に必要な情報を誰が持っているかを考える。

経営だろうか。

情シスだろうか。

工場責任者だろうか。

保守会社だろうか。

一人で答えを出す必要はない。

答えを探すために、誰と話す必要があるかが分かるだけでも、一歩前に進める。

セキュリティ対策は、攻撃者がいる限り、見直し続けなければならない。

けれど、際限なく製品を増やすことが、守ることではない。

必要なのは、何を守り、どのリスクを減らし、残るリスクを誰が引き受けるのかを決めること。

そして、決めたことが実際に機能するか、確かめ続けることである。

セキュリティに、永遠の完成はない。だが、今日の事業を守るための判断は、今日できる。

あわせて読みたい｜セキュリティを、現場で機能する仕組みに変える

今回の記事では、SASEの導入完了条件と、工場の安全な切り替えについて考えた。

さらに理解を深めたい方へ、関連する四つの記事を紹介したい。

1．セキュリティを強くしたのに、なぜ現場は抜け道を探し始めるのか——安全な方法を、自然に選ばれる業務へ変える

https://note.com/quiet_emu2080/n/n3d125192488e

対策を強化したのに、現場が別の方法を使い始める。安全な方法を、無理なく選べる業務として設計するための記事である。

2．ゼロトラスト移行で見落とされる4つの罠——「美しい構成図」の裏にある、現場のリアル

https://note.com/quiet_emu2080/n/n3475a5041bf3

構成図では見えにくい、通信経路や例外設計の問題を扱う。SASE導入を具体的な技術設計へ進める際に読んでほしい。

3．セキュリティ対策で現場が止まる理由——「安全」と「スピード」を対立させない判断構造

https://note.com/quiet_emu2080/n/n18c9b5e1be24

セキュリティと現場の要求が衝突したとき、影響度・緊急度・判断条件をどう整理するか。組織として判断を進めるための記事である。

4．セキュリティ対策で現場が止まる理由——経営・IT・現場の「正しさ」が衝突するとき

https://note.com/quiet_emu2080/n/nf7cc9795d19d

経営・IT・現場では、同じ問題でも見ているものが異なる。関係者の認識をそろえるための入り口として読んでほしい。

参考資料

本記事の物語は架空のケーススタディである。技術的な考察にあたっては、以下の公開資料を参考にした。

NIST SP 800-82 Rev.3「Guide to Operational Technology (OT) Security」

米国国立標準技術研究所（NIST）、2023年9月。

OT固有の安全性・信頼性・性能要件を踏まえたセキュリティ対策に関する指針。

https://csrc.nist.gov/pubs/sp/800/82/r3/final

Secure connectivity principles for Operational Technology (OT)

英国NCSCなどによる国際共同ガイダンス、2026年1月15日。

OTへの接続に関するリスク評価、接続範囲の制限、監視、管理などを扱う。

https://www.cyber.gov.au/publication/secure-connectivity-principles-for-operational-technology

NIST Cybersecurity Framework 2.0

米国国立標準技術研究所（NIST）、2024年。

サイバーセキュリティリスクを、統治・識別・防御・検知・対応・復旧の六つの機能で整理する枠組み。

https://www.nist.gov/cyberframework

人を責めるより、構造を見る。

自分を責めるより、構造を見る。

優しいまま、壊れない。