top of page

工場のリモート保守(VPN/踏み台)が一番危ない:VPNを“残すなら締める”、やめるなら“ゼロトラスト化”で止血する

製造業のサイバー事故は、情報漏えい以前に 「ラインが止まる」 という形で直撃します。そして、工場の現場で“入口”になりやすいのが リモート保守(VPN/踏み台/RDP) です。

最近は、ユーザー操作を誘導して侵入するタイプ(偽認証・偽CAPTCHA等)や、侵入後に生成AIで不正コードを都度生成する方向性も語られ、「検知をすり抜ける前提」での設計が必要になってきました。結論はシンプルです。

  • VPNを残すなら:接続範囲・時間・権限・端末・ログを“絞り切る”

  • VPNを減らす/やめるなら:ゼロトラスト型のアクセス(アプリ単位)へ寄せる

  • どちらでも:踏み台(ジャンプ)を公開しない/一時開放(JIT)/証跡を残す

以下、SE目線で「Microsoftの公式仕様を前提」に締め方を整理します。

1. ありがちな「危険な現状」チェック(工場のVPN/踏み台)

工場の現場で、次が残っていると“いつか刺さる”確率が跳ね上がります。

  • VPNが 常時接続(いつでも入れる、切れない、棚卸しできない)

  • ベンダー用IDが 共用(誰が入ったか追えない)

  • 踏み台サーバーに パブリックIP が付いている(“見つけたら殴れる”)

  • RDP/SSH等の管理ポートが 常時開放(開いていること自体がリスク)

  • MFAが例外だらけ(あるいは未導入)

  • 工場OT側の端末・機器が「資産として見えてない」(監視外)

  • ログはあるが、保管先・保持期間・誰が見るかが曖昧(監査・事故対応で詰む)

この状態を、設計と運用と契約で“締める”のが今回のテーマです。

2. 目標状態:リモート保守は「短時間・最小範囲・個人特定・全記録」

工場リモート保守のゴールは、きれいに言うと次の4つです。

  1. 最小経路:直接OTに入れず、必ず“踏み台(中継)”経由

  2. 最小時間:必要な時間だけ開く(JIT)

  3. 最小権限:必要な作業だけ権限を上げる(PIM)

  4. 説明可能:誰が・いつ・どこに・何をしたかをログで出せる

3. VPNを「残す」場合の現実解:Azure VPN Gateway+踏み台を“非公開化”する

(A) VPNは「暗号化トンネル」だが、設計を誤ると“侵入路”になる

Azure VPN Gatewayは、オンプレミスとAzure仮想ネットワーク間を IPsec/IKE 等で接続し、サイト間(S2S)/ポイント対サイト(P2S)/VNet間などのシナリオが整理されています。 しかし「VPNで中に入れた」瞬間に、横展開できる設計だと危険です。だから次の3点セットで締めます。

(B) 締めポイント1:踏み台を“公開しない”=Azure BastionでパブリックIPを消す

Azure Bastionは、仮想ネットワークに直接デプロイされ、VMにパブリックIPを付けずに、Azure portal(TLS)やネイティブRDP/SSHクライアントで安全に接続できるPaaSです。エージェント不要という整理も明記されています。

工場リモート保守の鉄板はこれです:

  • 「VPNで工場ネットワークへ」ではなく

  • 「VPNでDMZへ」→「Bastion経由で踏み台へ」→「踏み台からOTへ(許可した範囲だけ)」

踏み台がインターネットに露出している状態(RDP公開など)を消すだけで、事故率は一段落ちます。

(C) 締めポイント2:管理ポートは“常時開放しない”=Just-In-Time(JIT)

Defender for CloudのJIT VMアクセスは、RDP/SSHなどの管理ポートを狙う脅威に対し、受信トラフィックをロックダウンし、必要時だけ一時的に許可する考え方が整理されています。 またJITはNSGやAzure Firewall規則を前提に動作する点も明記されています。

(D) 締めポイント3:ネットワークは「NSG+Firewall」で“通す通信だけ”にする

  • NSG:仮想ネットワーク内の送受信トラフィックを許可/拒否する規則(基本の交通整理)

  • Azure Firewall:クラウドネイティブなマネージドFWとして、東西/南北トラフィック検査や高可用性・スケールを含めて整理されています。

工場のリモート保守は「とりあえず通す」が最悪です。“目的の通信だけ通す”設計へ必ず戻します。

4. IDと権限で締める:条件付きアクセス(CA)+PIMで「入れる人/時間/操作」を絞る

(A) 条件付きアクセス(CA)はゼロトラストの“ポリシーエンジン”

Microsoft Entra 条件付きアクセスは、複数シグナルをまとめてポリシーを適用する ゼロトラストのポリシーエンジンとして説明されています。

工場の保守で効く「最低限」の考え方は例えば:

  • MFA必須(例外は監査対象)

  • 準拠端末(Intune等)前提、または“限定端末”からのみ許可

  • ベンダーは“アプリ単位/範囲限定”で許可

  • ログインリスク等を見てブロック(必要に応じて)

(B) 特権は常時付けない:PIMで“必要な時だけ上げる”

PIMは、Entra IDのサービスとして、Entra/Azure/M365等の重要リソースへのアクセスを管理・制御・監視し、Just-In-Timeの特権アクセスを付与できると説明されています。

リモート保守で効くのは、

  • 「普段は一般権限」

  • 「作業時だけ昇格(承認・理由・時間制限)」

  • 「監査ログが残る」という“運用に落ちる”形です。

5. VPNを減らす/やめる選択肢:Entra Private Access(VPN置き換え)と、外部保守者の“仮想デスクトップ化”

(A) VPN置き換え:Microsoft Entra Private Access

Microsoft Entra Private Accessは、内部扱いのFQDNやIPアドレスへのアクセスを管理し、Global Secure Accessクライアントがあれば VPNなしでプライベートリソースへシームレス接続できる、という整理があります。

工場での使いどころ(現実的な順)は:

  • まずIT寄り(保守チケット、設計ドキュメント、監視ポータル等)からVPNを減らす

  • OTの深部は、段階的に(DMZ経由を維持しつつ)適用範囲を検討

(B) 外部保守者には“仮想デスクトップ”が強い:Azure Virtual Desktop

Azure Virtual Desktopは、Reverse Connect等により 受信ポートを開けずにリモートデスクトップへアクセスするリスクを下げられる旨が説明され、MFAや条件付きアクセスとも連携できる点が整理されています。

「ベンダーPCを信頼できない」「データ持ち出しが怖い」現場ほど、外部保守者はAVDに入れて、そこから踏み台へが効きます。

6. OTが“見えてない”問題:Defender for IoTで資産と通信を把握する

工場のOTは、エージェントを入れられない機器も多く、ITチームから見えないことが最大の弱点です。Defender for IoTは、IoT/OT環境向けの脅威検出を持ち、複数のデプロイオプションがあることが整理されています。 またOT向けには、エージェントレス監視でネットワーク全体の可視性・セキュリティを提供し、OT特有のプロトコルやM2M動作も識別する、という説明があります。

「VPNを締めたつもり」でも、OT側が見えていないと、侵入後の不審通信に気づけません。**“見える化→優先順位づけ→封じ込め”**までを設計に含めます。

7. ログと初動を“自動化”する:Sentinelのプレイブックで止血を速くする

Microsoft Sentinelでは、Azure Logic Appsと連携した**プレイブック(自動化)**が整理されており、従量課金/Standardの違いや注意点も明記されています。

工場のリモート保守で現実的な自動化(例)は:

  • 「不審なサインイン」→保守アカウント停止/条件付きアクセスで遮断

  • 「踏み台で異常」→JITの申請を止める/管理ポートを閉じる

  • 「OTで異常通信」→即時エスカレーション(夜間の初動遅れを潰す)

※実装の深掘りは環境依存なので、ここでは“方針”として示します。

8. 技術だけで終わらせない:リモート保守は「契約と規程」で“守れる状態”に固定する

工場の保守は、委託先・装置メーカー・SIer・SOCが絡み、事故時の論点が必ず出ます。ここは行政書士として、交渉代理ではなく、企業内の統制文書・契約条項・証跡設計を“運用に落ちる形”で整えます。

リモート保守の契約条項(たたき台に入れる観点)

  • 接続方式の指定:VPN/踏み台/AVD等(勝手な迂回を禁止)

  • 本人性:共用ID禁止、個人ID+MFA必須

  • 端末要件:準拠端末、EDR、パッチ水準、私物端末の扱い

  • 作業申請:作業理由・時間・対象範囲(JIT運用と一致させる)

  • ログ提供:アクセスログ・作業ログの保存と提出、保持期間

  • 再委託:再委託先も同等の統制を要求

  • 事故時通知:一次報告の期限、連絡経路、暫定対処の分担

  • アクセス剥奪:担当者変更・退職時の即時削除(誰が責任者か)

「契約では約束しているのに、運用でできてない」が一番危険です。運用と条項を“同じ言葉”に揃えるのがコツです。

【広告】山崎行政書士事務所:クラウド法務×Azureセキュリティで「VPN/踏み台統制」を“構成と証跡”で固めます

山崎行政書士事務所では、クラウド法務×Azureセキュリティとして、設計・実装・運用・監査・契約までを一気通貫で整理する方針を明記しています。 ページ内でも、Azure実装(Policy/Bicep/Terraform/Defender)と、規程・契約・記録(RoPA等)を同時に整備し、“根拠の一本道”を作る、という考え方が示されています。

また、実装面の例として Hub-Spoke/vWAN、Azure Firewall、Private DNS、NSG等の要素や、条件付きアクセス(MFA必須・レガシー認証遮断・デバイス準拠)まで含めた整理も掲載されています。


工場のリモート保守(VPN/踏み台)で、当事務所が特に強い領域

  • 委託先・SIer・SOCを含む 責任分界と証跡提出の整理(技術前提で崩れない形に)

  • 「設定しただけ」で終わらせない運用設計(Key Vault等でも“説明不能”を事故要因として整理しています)

  • 退職・異動等のアカウント管理が形骸化して起きる事故パターンの整理(規程・契約と運用の不一致を潰す)

免責(重要)

本記事は一般的な情報提供を目的としたもので、個別案件への法的助言を行うものではありません。紛争性がある案件(交渉・訴訟等)については弁護士領域となります。※個別の環境(工場ネットワーク構成、委託形態、規制要求)により最適解は変わります。

 
 
 

最新記事

すべて表示
【ISMS特化】Teams / SharePoint の「Owner権限」を“監査で説明できる統制”にする

〜棚卸し+逸脱検知+証跡(提出物)まで、Microsoft 365で回す実務〜 ※本記事は、ISMS(ISO/IEC 27001 等)運用のための一般的な情報提供です。個別案件の法的助言ではありません。※行政書士としては、規程・台帳・運用設計・証跡設計など「ガバナンス文書と運用の型」を整える支援が中心です(個別紛争対応等は別領域)。 1. ISMSで“Owner”が必ず論点になる理由 ISMSは、

 
 
 

コメント


Instagram​​

Microsoft、Azure、Microsoft 365、Entra は米国 Microsoft Corporation の商標または登録商標です。
本ページは一般的な情報提供を目的とし、個別案件は状況に応じて整理手順が異なります。

※本ページに登場するイラストはイメージです。
Microsoft および Azure 公式キャラクターではありません。

Microsoft, Azure, and Microsoft 365 are trademarks of Microsoft Corporation.
We are an independent service provider.

​所在地:静岡市

©2024 山崎行政書士事務所。Wix.com で作成されました。

bottom of page