CRA必須要件(Annex I)に基づく具体対策

サイバーリスク評価の結果をもとに、Annex I(付属書 I)に定められた「設計・実装時に満たすべき要件」を各機器で具体的に落とし込みます。

  1. PC:安全な設定と更新管理
    1. 不要な通信ポート・サービスを停止する(最小権限原則)
      1. なぜ必要?
      2. 何をするのか?
    2. OS・ソフトウェアは自動セキュリティ更新を有効化
      1. なぜ必要?
      2. 何をするのか?
    3. 管理者権限を分離し、多要素認証を導入
      1. なぜ必要?
      2. 何をするのか?
    4. 既知の脆弱性(CVE・KEVリスト)を定期チェックし、リリース前にスキャン
      1. なぜ必要?
      2. 何をするのか?
    5. まとめ:4つのステップで「安全なシステム」を作る
  2. PLC:制御系の安全強化
    1. 不正コマンドを防ぐ「署名付き通信(TLS/証明書認証)」
      1. なぜ必要?
      2. 何をするのか?
    2. ファームウェア更新時の「署名検証を必須化」
      1. なぜ必要?
      2. 何をするのか?
    3. 物理アクセスを制限して「ハード的な防御」を強化
      1. なぜ必要?
      2. 何をするのか?
    4. プログラム変更ログを自動記録し、改ざんを検知
      1. なぜ必要?
      2. 何をするのか?
    5. まとめ:PLCのセキュリティは「多層防御」で守る
  3. スイッチングハブ:ネットワーク境界防御
    1. 管理画面(Web GUI)のHTTPS/TLS化
      1. 何をするか?
      2. なぜ必要?
    2. VLANで制御系と情報系ネットワークを分ける
      1. 何をするか?
      2. なぜ必要?
    3. 未使用ポートを無効化
      1. 何をするか?
      2. なぜ必要?
    4. 監査ログを上位に転送(SNMP Trap、Syslog)
      1. 何をするか?
      2. なぜ必要?
    5. 不正コマンド防止のための署名付き通信(TLS/証明書認証)
      1. 何をするか?
      2. なぜ必要?
    6. ファームウェア更新時の署名検証
      1. 何をするか?
      2. なぜ必要?
    7. 物理アクセスの制限
      1. 何をするか?
      2. なぜ必要?
    8. プログラム変更ログの自動記録と改ざん検知
      1. 何をするか?
      2. なぜ必要?
    9. まとめ
  4. HMI:人と機械の接点を守る
    1. OS・アプリを最小構成で稼働(Secure by Design)
      1. 何をするか?
      2. なぜ必要?
    2. USB経由のマルウェア対策(自動実行禁止・検査ルール)
      1. 何をするか?
      2. なぜ必要?
    3. 権限別UI設計(運転・設定・保守を分離)
      1. 何をするか?
      2. なぜ必要?
    4. エラーメッセージに機密情報を表示しない設計
      1. 何をするか?
      2. なぜ必要?
    5. まとめ:HMIは“入口”を守る最後の砦

PC:安全な設定と更新管理

不要な通信ポート・サービスを停止する(最小権限原則)

なぜ必要?

パソコンやPLC、ルータには「通信ポート」と呼ばれる“出入口”があります。
この出入口が多いほど、ハッカーが侵入できるチャンスが増えます。
使わないポートやサービスを止めることで、攻撃の入り口を減らせます。
これを「最小権限原則(Principle of Least Privilege)」といいます。

何をするのか?

  • Windowsの場合:「サービス」設定画面で不要なサービス(例:リモートデスクトップ、FTPなど)を「無効」にする。
  • Linuxの場合systemctl disable サービス名 で停止。
  • PLCやHMIの場合:設定画面で「未使用通信ポート(例:Modbus/TCP, FTP, Telnetなど)」をオフにする。
  • ルータの場合:管理画面で「ポートフォワーディング」や「UPnP」を無効化する。

👉 つまり、「使わない通信機能は全部オフにする」のが第一歩です。


OS・ソフトウェアは自動セキュリティ更新を有効化

なぜ必要?

ソフトウェアには「脆弱性(ぜいじゃくせい)」と呼ばれる、悪用される可能性のあるバグがあります。
メーカーは見つけ次第、それを修正する「セキュリティアップデート」を配布します。
これを自動で受け取るようにしておけば、古いまま放置されて攻撃されるリスクを減らせます。

何をするのか?

  • Windows:「設定 → 更新とセキュリティ → Windows Update → 自動更新を有効」にする。
  • Linuxunattended-upgrades を有効化。
  • PLCやHMI:メーカーサイトで定期的に「ファームウェア更新」を確認。
  • Wi-Fiルータ:管理画面の「自動更新」設定をONにする。

👉 ポイントは、「放っておいても最新になる設定」にしておくこと。


管理者権限を分離し、多要素認証を導入

なぜ必要?

「管理者権限(Admin)」は、すべての設定を変えられる特別な力を持っています。
この権限を誰でも使えるようにしておくと、ミスや不正アクセスが発生します。
また、パスワードだけの認証は簡単に破られることがあります。
そこで、「権限の分離」と「多要素認証(MFA)」を使って安全にします。

何をするのか?

  • アカウント分離
    • 日常作業用 → 権限の低いユーザーアカウント
    • 設定変更用 → 管理者アカウント(普段は使わない)
  • 多要素認証(MFA)
    • ログイン時に「パスワード+スマホ認証」など2段階で確認。
    • Microsoft AuthenticatorやGoogle Authenticatorを利用。
  • PLCやHMIでも、新しいモデルでは「ユーザーごとのアクセスレベル設定」や「認証トークン対応」があるため、積極的に設定する。

👉 要は、「強い鍵を少人数だけが使い、ログインには2段階確認をつける」ということです。


既知の脆弱性(CVE・KEVリスト)を定期チェックし、リリース前にスキャン

なぜ必要?

「CVE(Common Vulnerabilities and Exposures)」とは、世界中で見つかった脆弱性のデータベースです。
「KEV(Known Exploited Vulnerabilities)」は、その中でも実際に攻撃に使われた危険な脆弱性をまとめたリストです。
これらを定期的に確認して、使っているソフトや機器が危険な状態でないかチェックするのが基本です。

何をするのか?

👉 要は、「自分の機器が危険リストに載っていないかを定期的に確認しよう」ということです。


まとめ:4つのステップで「安全なシステム」を作る

ステップ内容目的
1不要な通信ポートを停止攻撃の入口を減らす
2自動更新を有効化脆弱性を放置しない
3管理者権限とMFAアクセスを厳重にする
4脆弱性チェックとスキャン最新のリスクを把握する

👉 CRA Annex I(2)(a)(b)(e)「既知の脆弱性除去」「安全なデフォルト設定」「セキュアアップデート」に対応。


PLC:制御系の安全強化

不正コマンドを防ぐ「署名付き通信(TLS/証明書認証)」

なぜ必要?

外部からPLCに不正な命令が送られることを防ぐ。

たとえば誰かがネットワーク経由で「モーターを止めろ」という偽コマンドを送った場合、
PLCがそれを信じて動作を停止してしまうと大問題です。
これを防ぐのが「署名付き通信」と「TLS(暗号化通信)」です。

何をするのか?

  • PLCと上位PCの間でTLS通信を有効化(暗号化通信)
  • 双方に電子証明書(デジタルID)を設定して、正規機器だけが接続できるようにする
  • コマンド送信時に電子署名(デジタル署名)を付与し、PLC側で検証する

不正な機器や攻撃者が送信した命令は署名が一致しないため、PLCが自動的に拒否します。
つまり、「信頼できる通信」だけを通す仕組みです。


ファームウェア更新時の「署名検証を必須化」

なぜ必要?

不正に改ざんされたファームウェアをインストールさせない。

もし攻撃者が、見た目は正しいけれど内部が改ざんされたPLCプログラムを流し込んだら、
制御システムが乗っ取られる危険があります。

何をするのか?

  • PLCメーカーが提供する正規のファームウェアに署名を付ける
  • 更新時にPLCが電子署名を検証し、本物かどうかを確認してからインストール
  • 署名が一致しない(改ざんされた)場合は更新を拒否する

偽のアップデートを防ぎ、PLCのプログラム integrity(完全性)を維持します。
つまり、「誰かにすり替えられても気づかない」というリスクをゼロにします。


物理アクセスを制限して「ハード的な防御」を強化

なぜ必要?

外部の人が直接PLCに触って設定を変えたり、USBで攻撃コードを入れるのを防ぐ。

どんなに通信を守っても、直接触られたら終わりです。
そのため、「物理的に近づけないようにする」ことが基本の防御になります。

何をするのか?

  • PLCを鍵付き制御盤に収納し、アクセスできるのは管理者のみ
  • LANポート・USBポートにロックカバーを取り付け
  • 制御盤の開閉履歴を記録(誰が・いつ開けたか)
  • 監視カメラや入退室管理システムと連動して管理

不審者が現場でPLCに直接触ることができなくなり、
内部からの攻撃や設定ミスも大幅に減らせます。


プログラム変更ログを自動記録し、改ざんを検知

なぜ必要?

誰がいつPLCの設定を変更したのかを記録し、不正変更を見逃さない。

学生の出席簿のように、「誰が触ったのか」が記録されていれば、
後から不正や誤操作を追跡できます。

何をするのか?

  • PLCの変更履歴記録機能(ログ)を有効化
  • 記録には変更日時・ユーザー名・内容を自動保存
  • ハッシュ値(改ざん防止の指紋)を付与し、改ざんされていないかを定期検証
  • 管理PCにログを定期転送し、変更差分を自動チェック

不正変更や設定ミスを早期に発見でき、問題発生時の原因追跡も容易になります。
これにより、PLCの可視性(見える化)と信頼性が大幅に向上します。


まとめ:PLCのセキュリティは「多層防御」で守る

対策防御の層主な目的
署名付き通信(TLS)ネットワーク層不正コマンド防止
署名付き更新ソフトウェア層改ざん防止
物理アクセス制限ハードウェア層不正操作防止
変更ログ管理運用層改ざん検知・追跡

PLCを守るには、通信・ソフト・ハード・運用の4層で防御を構築することが重要です。
これが、Cyber Resilience Act(CRA)が求める「リスクに基づく安全強化」の実践です。


👉 Annex I(2)(f)(j)「通信の完全性」「アクセス制御」「改ざん検出」に対応。


スイッチングハブ:ネットワーク境界防御

管理画面(Web GUI)のHTTPS/TLS化

何をするか?

スイッチングハブには、設定用の「Web管理画面」があります。
古い機器では「HTTP(暗号化なし)」でアクセスすることがありますが、これは危険です。

そこで、設定で「HTTPSを有効化」し、通信を暗号化します。
TLS証明書を設定することで、ブラウザとハブの間のデータ(パスワードなど)が盗まれなくなります。

なぜ必要?

  • パスワードや設定情報が盗まれないようにするため
  • 攻撃者が設定画面を偽装できないようにするため

VLANで制御系と情報系ネットワークを分ける

何をするか?

VLAN(仮想LAN)を使うと、1台のスイッチの中でネットワークを仮想的に分離できます。
たとえば:

  • VLAN10 → 制御機器(PLCやHMI)
  • VLAN20 → 事務用PCやWi-Fi

これにより、制御機器と一般ネットワークを分離できます。

なぜ必要?

  • 事務用PCがウイルスに感染しても、制御系に侵入できない
  • 通信経路を分けることで被害を最小化できる

未使用ポートを無効化

何をするか?

スイッチには多くのLANポートがありますが、使っていないポートをOFF(disable)に設定します。

設定画面やCLIで「admin down」などのコマンドを使います。

なぜ必要?

  • 空いているポートから不正な機器を接続されるのを防ぐ
  • 内部からの不正接続(USB-LAN変換など)を防止できる

監査ログを上位に転送(SNMP Trap、Syslog)

何をするか?

スイッチは「いつ誰が設定したか」「どんな通信があったか」をログとして記録しています。
これをSyslogサーバーSNMP監視ツールに送信して集中管理します。

設定例:

  • Syslog送信先:192.168.10.100
  • SNMP Trap先:192.168.10.200

なぜ必要?

  • 不正アクセスや設定変更をすぐに検知できる
  • 監査の証拠として残せる

👉 Annex I(2)(h)(i)の「データ保護」「監査性」に対応します。


不正コマンド防止のための署名付き通信(TLS/証明書認証)

何をするか?

管理ソフトや上位システムからスイッチにコマンドを送るとき、通信に「電子署名」や「証明書認証」を使います。
これにより、「正しい相手からの命令かどうか」を確認できます。

なぜ必要?

  • 攻撃者が偽の命令(例:通信遮断)を送るのを防ぐ
  • 管理者本人の操作だけを許可できる

ファームウェア更新時の署名検証

何をするか?

スイッチのソフト(ファームウェア)を更新するとき、メーカーの署名付きファイルのみを受け付ける設定にします。
更新時に「署名が一致しない場合は拒否する」ようにしておきます。

なぜ必要?

  • 攻撃者が改ざんしたファームウェアを入れられないようにする
  • 正規品であることを保証できる

物理アクセスの制限

何をするか?

ハブが設置されている盤やラックに「鍵付きドア」「ロックカバー」を取り付けます。
簡単にLANケーブルを抜いたり差し替えたりできないようにします。

なぜ必要?

  • 外部者や悪意のある内部者がケーブルを抜き差しできないようにする
  • 物理的な不正操作を防ぐ

プログラム変更ログの自動記録と改ざん検知

何をするか?

スイッチの設定変更履歴を自動でログ保存し、ハッシュ値(データの指紋)で改ざんを検知します。
外部サーバーにバックアップをとっておくとより安全です。

なぜ必要?

  • 誰がいつ設定を変えたか追跡できる
  • 攻撃や誤操作をすぐに発見できる

まとめ

対策内容目的関連CRA要件
HTTPS/TLS化データ保護Annex I(2)(h)
VLAN分離ネットワーク境界防御Annex I(2)(h)
未使用ポート無効化不正接続防止Annex I(2)(h)
ログ転送(Syslog)監査性確保Annex I(2)(i)
署名付き通信不正命令防止Annex I(2)(h)
署名付き更新ファームウェア保護Annex I(2)(h)
物理アクセス制限改ざん防止Annex I(2)(h)
改ざん検知ログ監査証跡Annex I(2)(i)

👉 Annex I(2)(h)(i)「データ保護」「監査性」に対応。


HMI:人と機械の接点を守る

HMI(Human Machine Interface)は、オペレーターがタッチパネルや画面を使って機械やラインを操作する装置です。
つまり、人と機械の橋渡し役
もしHMIが乗っ取られたら、機械を誤動作させたり、生産データを盗まれたりする可能性があります。

そこで、Cyber Resilience Act Annex I(2)(g)(l)が求める
「ユーザーアクセス管理」・「データ漏えい防止」
に対応するための具体策を紹介します。


OS・アプリを最小構成で稼働(Secure by Design)

何をするか?

HMIの中にはOS(Windows、Linuxなど)や制御アプリが入っています。
これらを「必要最小限だけ動かす」ように設計します。

  • 使わないアプリやサービスを削除
  • 外部接続機能(Bluetooth、無線LANなど)は無効化
  • 自動更新やリモート接続も不要なら停止

なぜ必要?

  • 無駄な機能が多いほど、攻撃の入り口が増える
  • 攻撃者は不用意に残された機能を悪用しやすい

👉 これが「Secure by Design(設計段階から安全に)」という考え方です。


USB経由のマルウェア対策(自動実行禁止・検査ルール)

何をするか?

保守員がUSBメモリでプログラム更新をする場面では、ウイルス感染の危険があります。
そのため、次の設定を行います:

  • USBメモリを差し込んでも自動で実行しない(AutoRun無効)
  • 接続時に自動ウイルススキャン(専用ソフトやルール設定)
  • ファイル形式(例:.exe)や署名のチェック

なぜ必要?

  • USB経由のウイルス感染を防ぐ
  • 不正なプログラムが勝手に起動しないようにする

👉 これはマルウェア感染防止データ保護の基本です。


権限別UI設計(運転・設定・保守を分離)

何をするか?

HMI画面にアクセスする人は、「現場作業員」「保守員」「管理者」など役割が違います。
そこで、ユーザーの権限に応じて操作できる範囲を分けるようにします。

権限主な操作内容セキュリティ制限
運転モードスタート/ストップなど基本操作設定変更は不可
設定モード閾値変更やパラメータ設定パスワード必須
保守モードプログラム更新や診断管理者認証必須

なぜ必要?

  • 間違った操作や悪意ある変更を防ぐ
  • 不要な人がシステム設定をいじれないようにする

👉 Annex I(2)(g)「ユーザーアクセス管理」に対応。


エラーメッセージに機密情報を表示しない設計

何をするか?

HMIがエラーを出すときに、システム内部情報(パスやIPアドレス、認証情報)をそのまま表示しないようにします。

例:
❌ 「Error: Cannot connect to 192.168.1.10/admin」
⭕ 「Error: Unable to connect. Contact your administrator」

なぜ必要?

  • 攻撃者に内部構成や設定情報を知られないようにする
  • エラー情報から侵入経路を推測されるのを防ぐ

👉 Annex I(2)(l)「データ漏えい防止」に対応。


まとめ:HMIは“入口”を守る最後の砦

対策内容目的対応するCRA要件
OS・アプリの最小構成攻撃面の削減Annex I(2)(g)
USB経由のマルウェア対策外部感染防止Annex I(2)(l)
権限別UI設計不正操作防止Annex I(2)(g)
エラーメッセージ制御データ漏えい防止Annex I(2)(l)

👉 Annex I(2)(g)(l)「ユーザーアクセス管理」「データ漏えい防止」に対応。


Cyber Resilience Act - Read the annexes to enhance cybersecurity
Check out the annexes to the Proposal for a Regulation of the European Parliament and of the Council on horizontal cyber...

コメント