②OT/IT 統合を進める欧州拠点での NIS2 対応事例
- 山崎行政書士事務所
- 1 時間前
- 読了時間: 10分
1. 企業・拠点の前提
1-1. 想定する企業像
業種：日系製造業（産業機械・部品メーカー）
拠点：
本社（日本）：開発・生産計画・グローバル IT / セキュリティ
欧州製造拠点：ドイツに大型工場（組立＋一部加工）、他に小規模工場が 2〜3 箇所
EU 売上：グループ全体売上の 30〜40% 程度
1-2. OT / IT の現状
OT 側
工場ごとにバラバラに導入された PLC、SCADA、DCS
ベンダ：Siemens、Rockwell、Schneider など混在
Windows XP/7 の HMI がまだ残っているラインもある
一部ラインで、リモート保守用に VPN が開いている（ベンダ管理）
IT 側
本社主導で Azure・M365 を導入済み
工場も M365（メール・Teams）や一部 Azure 上の製造ダッシュボードを利用
工場 LAN とオフィス LAN のセグメントは一応分かれているが、ファイル共有・リモート監視等で「よくわからない例外ルール」が多数
2. NIS2 適用の可能性が浮上
2-1. 規制・市場からのプレッシャー
欧州の顧客（大手自動車メーカーやエネルギー関連）が、サプライヤに対し
「NIS2 を考慮した OT セキュリティ態勢の説明」を求め始める
EU 域内の法律事務所・コンサルから、
「製造業・産業セクターも NIS2 の対象になり得る」
「国によっては“重要・必須事業者”に指定される可能性がある」
2-2. NIS2 の基本的なポイント（ざっくり）
NIS2 は 2023年1月に発効し、2024年10月17日までに各加盟国が国内法へトランスポーズすることが義務付け。
2024年10月18日以降は NIS1 が廃止され、各国の NIS2 ベースの法律が順次施行。
対象セクターが大幅に拡大し、製造業・化学・廃棄物等の産業分野も含まれうる。
Essential / Important entities に対し、
リスク管理（技術・組織対策）
サプライチェーン管理
重大インシデントの報告義務
経営層の責任・制裁（最大 1,000万ユーロ or 2% 売上など）を課す方向性。
この企業の欧州工場は、現時点で各国法上「対象かどうか」はグレーだが：
重要顧客のサプライチェーンとしてセキュリティ要求が上がっていること
万が一操業停止すれば EU での供給に重大な影響を与え得ること
から、**「早めに NIS2 水準を意識した OT/IT セキュリティ基盤を整えよう」**という方向に。
3. プロジェクトの目的・スコープ
3-1. プロジェクト目的（上位）
欧州工場の OT/IT 環境について「NIS2 を意識した最低限のサイバー・レジリエンス水準」を実現すること。
顧客からの NIS2 関連監査・質問に対し、一貫した説明ができるストーリーと証跡を用意すること。
将来、各国当局から Essential／Important entity に指定されても「ゼロからの対応」にならないベースラインを作ること。
3-2. スコープ
対象工場：欧州の主要工場 1 拠点（パイロット）＋関連する小工場
対象システム：
OT：製造ラインの PLC / SCADA / HMI / historian など
IT：工場内オフィス LAN、工場から Azure / M365 への接続
セキュリティ：現行の Firewall / AV / SOC / ログ管理など
4. ガバナンス・体制づくり
4-1. 関係者構成
プロジェクトオーナー：欧州事業統括役員（EU での P/L 責任者）
コアメンバー：
工場長
工場 OT リーダー（設備・保全）
欧州 IT マネージャー
グローバル CISO オフィス
法務（欧州担当・日本本社）
外部 OT セキュリティコンサル（ローカル）
4-2. 初期の摩擦
OT：「ライン止まるとかマジで勘弁」「セキュリティより稼働が命」
IT：「パッチ当てないとか信じられない」「認証もログもないなんて…」
法務：「NIS2 違反で罰金・行政処分とかあると、会社として困る」
→ 最初のフェーズでやったこと：
共通言語づくりワークショップ
NIS2 の要件
OT へのサイバー攻撃事例（製造停止・安全リスク）SANS Institute+2Industrial Cyber+2
OT/IT 両視点でのリスクを共有し、「敵はお互いではなくリスク」という認識合わせ。
優先順位の合意
「安全（Safety）＞稼働（Availability）＞品質＞セキュリティ」という現場感覚を尊重しつつ、
セキュリティを上げないと「安全と稼働そのものが危うくなる」ことを腹落ちさせる。
5. 現状把握フェーズ（As-Is）
5-1. 資産棚卸し（Asset Inventory）
OT 資産：
PLC・RTU の型番／ファームウェア
HMI・エンジニアリング端末の OS・パッチレベル
使用しているプロトコル（Modbus, Profinet, OPC 等）
ネットワーク：
OT ネットワークのセグメント
FW ルール（どこからどこへ、どのポート）
リモートアクセス（VPN, リモートデスクトップ etc.）
IT 資産：
ドメイン参加端末
AD / Entra ID 接続状況
Azure / M365 との接点（データ連携ダッシュボードなど）
→ ここで初めて可視化されたこと：
OT セグメントから直接インターネットに出られる「謎ルート」が複数
リモート保守用の VPN が、いつ誰が使っているのかログがほぼない
一部 HMI はローカル管理者パスワード共通＆記録なし
NIS2 は OT 含めた資産・リスクの把握を要求しており、資産管理・ネットワーク可視化は「最低限の前提」となる。
5-2. コントロール評価（Gap 分析）
NIS2 の要求（リスク管理、インシデント報告、BCP、サプライチェーン等）をベースに、現状 OT/IT のコントロールをマッピング。
例：アクセス制御
IT：AD ベースで MFA・ログあり
OT：共有アカウント・物理鍵のみ、ログほぼなし → 大きなギャップ
例：パッチ・脆弱性管理
IT：月次パッチ／脆弱性スキャン
OT：
「止められない」「ベンダが保証しない」として放置
ICS CERT のアドバイザリ等も見ていない → プロセス不在
例：インシデント対応
IT：インシデント対応手順・CIRT あり
OT：
機械故障インシデント手順はあるが、「サイバーインシデント」としての定義・プロセスなし
6. NIS2 に基づく「目標像」の整理
NIS2 は細かい技術仕様を定める法律ではなく、「リスク管理」「インシデント報告」「BCP」「サプライチェーン」「経営責任」など、**いわば“何をやるべきかのフレーム”**を示す指令。￥
この企業では、NIS2＋OT 向けベストプラクティス（IEC 62443 など）を参考に、次の 7 つを「工場として達成すべき状態」と定義しました：
OT 資産とネットワークが把握されている
OT ネットワークが IT／インターネットから適切に分離されている
OT へのアクセス（ローカル・リモート）が認証・ログ付きで管理されている
OT の変更・パッチがリスクベースで管理されている
OT を含むサイバーインシデント対応プロセスが整備されている
サプライチェーン（設備ベンダ・保守業者）に対するセキュリティ要求が定義されている
工場長・経営層が OT サイバーリスクを理解し、定期的にモニタリングしている
7. 実装フェーズの具体策
ここが一番「どうやったか」が気になる部分だと思うので、NIS2 の柱ごとに何をしたかを書きます。
7-1. リスク管理・技術的対策
(1) ネットワークセグメンテーション
工場ネットワークを 3 層で再設計：
レベル 0〜1：PLC・フィールド機器（極力、IT とは論理的に隔離）
レベル 2：HMI・SCADA サーバ（OT DMZ）
レベル 3：工場オフィス LAN（IT 側）
OT DMZ にファイアウォールを設置し、
SCADA ↔ historian ↔ Azure へのデータ送出は限定的なポートに絞る
IT 側からの RDP や SMB 等は原則禁止、必要なもののみジャンプサーバ経由
→ 攻撃が IT から侵入しても、OT への水平移動を防ぐ設計。
(2) リモートアクセス管理
旧来：
ベンダごとに VPN アカウントを渡しっぱなし
いつ・誰が入ったかログがない
新：
中央の「リモートアクセスゲートウェイ」を経由
MFA＋時間制限付きアカウント付与
重要作業は**「セッション録画」**を有効化し、証跡として保管
これにより、
インシデント発生時の「誰がいつ何をしたか」が追える
ベンダ契約に「セッション録画への同意」「ログ保管」を明記
(3) OT 脆弱性・パッチ管理
全てを最新化するのは非現実的なので、リスクベースに整理：
高リスク系：
インターネット露出、リモートアクセスがあるシステム
公開されたクリティカルな脆弱性（CVSS 高）→ パッチ適用 or 代替コントロール（FW 制御、アカウント削除、ジャンプサーバ化）
低リスク系：
物理的に隔離されているライン、かつ稼働停止許容度が低い→ パッチは年次シャットダウン時にまとめて検討→ その代わりに監視強化・アクセス制御強化
OT 脆弱性情報は、ICS-CERT / ベンダ情報を定期購読し、四半期ごとに OT/IT/セキュリティが集まって「対応要否」をレビュー。
7-2. インシデント対応・報告体制
NIS2 は「重大インシデント」の早期報告・詳細報告を要求するため、
そもそも何が「重大」か
どこからが「OT サイバーインシデント」かを定義する必要がある。￥
(1) インシデント分類ルール
OT サイバーインシデント定義の例：
サイバー攻撃・マルウェアにより、
生産ラインの停止
安全機能の無効化／誤動作
品質記録の改ざんが発生、または発生の現実的な恐れがあるもの。
重大度レベル（例）：
L1：工場内で完結する小規模なもの
L2：複数ラインに影響、1日以上の影響可能性
L3：顧客供給・安全に影響し得るレベル（NIS2 報告候補）
(2) フローの統合
既存の IT インシデント対応フローに、「OT サイバーインシデント」の特別分岐を追加。
OT で異常が起きた際、
工場保全が「機械故障」とみなす前に、
「サイバー原因の可能性チェックリスト」を確認し、セキュリティチームへエスカレーション。
演習（テーブルトップ・エクササイズ）：-「ランサムウェアで工場が半分止まった」という想定でOT・IT・法務・広報・経営を巻き込んで机上訓練を実施。
7-3. BCP / レジリエンス
NIS2 は事業継続・レジリエンスも要求するため、OT 停止時のリカバリを明文化。
具体的には：
重要 PLC プログラム・HMI 設定のバックアップとリストア手順
SCADA・historian のバックアップ頻度・保管場所
ランサム攻撃時の「どの順番で復旧するか」の優先度リスト
→ 従来「ベテラン保全担当の頭の中」にあったノウハウを文書化して共有・訓練。
7-4. サプライチェーン管理
設備ベンダ・保守会社との契約を見直し：
リモートアクセスに関する要件
MFA 必須、ゲートウェイ経由、ログ取得・保管
セキュリティインシデント時の協力義務
迅速な脆弱性情報提供
フォレンジックへの協力
サイバーセキュリティ教育の実施（ベンダ担当者）
新規設備調達の RFP テンプレに、
「NIS2 を踏まえたセキュリティ要件（ネットワーク分離、ログ出力能力等）」を項目として追加。
8. 法務・コンプライアンスのアウトプット
8-1. NIS2 ギャップ分析レポート
各国の NIS2 実施法（草案含む）をレビューし、
対象セクター該当性（現時点の見立て）
必要なガバナンス・技術対策
インシデント報告ライン（どの当局へ）
OT/IT のギャップと、ロードマップを整理した文書。
8-2. 経営層向けブリーフィング資料
「もし NIS2 の Essential/Important に指定されたら何が起こるか」
罰則・監査・個人責任の可能性など
OT サイバーインシデントの事例（自社業界付近のもの）
今回のプロジェクトで何をしているか（投資対効果を含む）
8-3. 顧客向け説明資料
「当社欧州工場の OT/IT セキュリティと NIS2 対応状況」
ネットワーク分離・リモートアクセス管理・インシデント対応フロー等を図解したスライド。
顧客監査の際に提示できる「標準回答集」として活用。
9. 結果と “まだ道半ば” なポイント
9-1. 得られた成果
可視化されたことが最大の収穫
何がどこに繋がっているか、誰が触れるかが明確になった
顧客監査の場で“話が通じる”ようになった
「NIS2 の○○条に対応するため、こういう OT セグメンテーションをしています」と説明できる
OT と IT の心理的な距離が縮まった
共同ワークショップ・演習を通じて「相互理解」が進んだ
9-2. まだ課題として残るもの
旧式設備の更新問題：
「パッチも入らない、ベンダもサポート終了」な機器をどうするか
将来の設備投資計画と結びついた長期課題
グローバル標準化：
今回は欧州工場 1 拠点がパイロット
他地域（アジア・北米）への展開は今後の話
ローカル法の変化：
各国の NIS2 実施法の差異（監督当局・報告要件）が徐々に出てきており、継続的なモニタリングが必要。
10. このケースを自社に重ねるための「問い」
最後に、自社の状況に当てはめるためのチェック的な問いを並べます。
自社の欧州拠点は、各国の NIS2 実施法上、対象セクター・規模に該当する可能性はないか？
工場の OT ネットワーク構成図・資産リストは、最新・正確なものが存在するか？
OT へのリモートアクセス（ベンダ含む）は、
誰が
いつ
どの端末から入っているか、ログで説明できるか？
OT に関するサイバーインシデントを想定したインシデント対応フローと訓練は存在するか？
設備ベンダ・保守会社との契約に**サイバーセキュリティ条項（アクセス・通知・協力義務等）**は入っているか？
経営層は「工場サイバーリスク」を定期的に報告され、意思決定に組み込んでいるか？
コメント