近年、産業機械・プラント設備の制御系は、電子部品、ソフトウェア、ネットワーク、IoT化といった技術と強く結びついています。
昔ながらの「故障しないようにする」「信頼性を高める」といった観点だけで語られてきた機能安全も、今やサイバー攻撃のリスクを前提として設計・運用する時代に入っています。
制御ネットワークがサイバー攻撃を受け、誤動作を引き起こすことは、現実に物理的安全事故・停止事故につながり得ます。
したがって、機能安全（Safety） と OT／制御系セキュリティ（Security） を統合的に扱う設計思想が、今、産業界で不可欠になりつつあります。
- 機能安全規格・セキュリティ規格の基礎と最近の動き
- 安全とセキュリティ統合設計の考え方と技法
- 最新の法制度動向・国際規格改訂・実証事例
- 実際に設計者／エンジニアが押さえるべきチェックポイント
機能安全の再整理：IEC 61508 とその位置づけ
IEC 61508 の基本とその限界
IEC 61508 は、電気／電子／プログラム可能電子（E/E/PE）システムにおける「安全機能（Safety-related system）」を対象とし、そのライフサイクルや信頼性評価手法を定めた基本規格です。
その中心的な考え方には以下があります：
- 安全ライフサイクル：概念設計 → 危険源分析 → 要求仕様 → 詳細設計 → 実装 → 検証 → 運用・保守 → 廃止 という一連のプロセスを通じて、設計ミスや抜け漏れを抑える枠組み。
- 安全度水準（SIL）：SIL1～SIL4 の区分で、目標とすべき故障確率やリスク低減度合いを定量的／半定量的に定義する。
- 故障モデルの扱い：設計上の体系的故障（設計ミス、ソフトウェア欠陥など）と、偶発的故障（ハードウェアの偶発故障）を分けて扱う。
- ALARP（“as low as reasonably practicable”）原則：ゼロリスクは実現不可能と考え、リスクを「できるだけ低く、そして合理的に実現可能な範囲で」抑えるという考え方。
ただし、IEC 61508 は主に「安全」という観点に焦点をあてた標準であり、意図的な攻撃や悪意ある操作（サイバーセキュリティ）の視点は、従来はあまり強くは組み込まれていません。
このため、制御系環境がネットワーク化・IoT化する現在、IEC 61508 単独では不十分な側面を持つようになってきています。
たとえば、IEC 61508 規格本文そのものにはセキュリティ関連要件（暗号化、認証、攻撃耐性など）を詳細に規定する部分は存在しないと言われています。
ただし、機能安全の分野では “安全-セキュリティ共保証（co-assurance）” の考え方を取り込もうという動きや、規格解釈・補助ガイド（技術ガイド）において、サイバーセキュリティ要素を組み込む方向性が議論されています。
加えて、IEC 61508 の適用を前提とした特殊用途・対象機器向けの派生規格（例：IEC 61511、IEC 61513、IEC 62061、ISO 26262 など）が、各業界での機能安全の具体的枠組みを補完しています。
IEC 61508 とサイバーセキュリティ統合
機能安全とセキュリティ（特に OT セキュリティ）との統合を図る議論は、技術ガイドや実務界隈で徐々に広がっています。特に、以下のような考察・指針が注目を集めています：
- 技術ガイド：“Considerations for Cybersecurity during the Safety Lifecycle”
IEC 61508 に関する非公式技術ガイド文書では、安全ライフサイクルとサイバーセキュリティライフサイクルをどう接続させるかという指針が示されています。具体的には、各安全ライフサイクルフェーズでのサイバー脅威の識別・対策・検証・監視の流れと、安全設計とのインタフェース設計の重要性などです。 - 共保証モデルの研究：SSAF（Safety-Security Assurance Framework）
安全とセキュリティの評価を統合するために、Bayesian モデルなどを用いる手法が提案されています。これは、相互作用やトレードオフを定量化・見える化して、統合的判断を支援するものです。 - プロセス整合性・組織統合
機能安全担当者（OT寄り）と情報セキュリティ担当者（IT寄り）が共に設計・運用に関与する体制整備、異なる開発・運用プロセス（安全プロセスとセキュリティプロセス）の統合・調整、責任分担明確化といったテーマが、ガイドラインレベルで議論されています。 - 安全システムにおけるセキュリティ機能併設
たとえば安全インタロック系システムにおいて、通信保護（暗号、認証）、改ざん検知、ログ記録、フェイルセーフ動作の設計などを追加することで、安全機能そのものをセキュリティ脅威から保護するというアプローチがあります。これは「セキュリティ更新可能な安全機能」設計という視点にもなります。
IEC 62443：産業制御系セキュリティ規格の最前線
制御系／OT 環境に特化したセキュリティ標準群として、IEC 62443（旧称 ISA/IEC 62443）が最も広く参照される規格体系です。以下、その概要と最近の改訂を押さえておきましょう。
規格体系と主要構成
IEC 62443 は、IACS（Industrial Automation and Control Systems：産業制御システム）を対象とし、組織・設計者・機器ベンダーそれぞれに求められるセキュリティ要件を定義した多層的な規格群です。(pilz.com)
代表的な構成を簡単に整理すると：
- IEC 62443-1s ：基本理念、用語、モデル
- IEC 62443-2-1：資産所有者（アセットオーナー）向けのセキュリティ・プログラム要件
- IEC 62443-2-4：システムインテグレータ／サービス提供者向け要求
- IEC 62443-3-3：システムレベルのセキュリティ要件
- IEC 62443-4-1：安全な製品開発ライフサイクル（SDL: Secure Development Lifecycle）
- IEC 62443-4-2：製品コンポーネント（ハードウェア／ソフトウェア部品）に対する技術要件
- IEC 62443-6-1 など：適合性評価や試験方式の補助規格
各レイヤーは、システム設計、実装、構成、運用保守までをカバーし、相互に前提関係や責任範囲を定めています。
最近の改訂と動向
最近の IEC 62443 における主な改訂・拡張動向には、以下のようなものがあります：
| 規格 / 規格改訂 | 主な更新・追加点 | 解説 |
|---|---|---|
| IEC 62443-2-1 | 資産所有者向けセキュリティ・プログラム（SP: Security Program）要求の見直しと強化 | アセット所有者のセキュリティガバナンス、運用ポリシー、サプライチェーン管理、脆弱性管理体制などをより明確に位置づけた形。 |
| IEC 62443-2-4 | システムインテグレータ／サービス提供者の責務強化 | 組込みセキュリティ設計、構成管理、責任分界、試験・検証といった段階での要件が更新。 |
| IEC TS 62443-1-5 | セキュリティプロファイル（Security Profiles）の定義方式を示す技術仕様 | コンポーネント／システムに対するプロファイルベース適用手法を明示。 |
| IEC 62443-6-1 | 2-4 規格適合性評価（アセスメント）の手法定義 | システムインテグレータやサービス提供者が、自らや他者を適合性評価できる指針を提供。 |
これらの改訂は、「セキュリティプロファイル適用」「責任分界・サプライチェーン管理強化」「適合性評価方式の標準化」などに重きを置いたものです。
また、IEC 62443 を基盤とした枠組みは、欧州の新たな法制度動向（後節に述べる）とも強く整合性を持つよう設計されつつあります。
IEC 62443 と他制度との関係性
近年、欧州を中心に制御系セキュリティを法制度として強化する動きが顕著になっています。IEC 62443 は、これらの法制度要件を具体的に実現する枠組みとして、実務的なレバレッジが期待されています：
- EU 機械規則（EU Machinery Regulation 2023/1230）
この新規則では、2027年1月から機械装置に対してサイバー攻撃耐性を設計要件として義務付け、従来の機械指令を置き換えます。
具体的には、「制御系ネットワークや接続機能がある機械は、接続によって危険状況を引き起こしてはならない」「不正な操作や改ざんを検出・ログ・追跡可能にする」「ライフサイクル全体でサイバー防御を維持する」などが求められます。
IEC 62443 は、このような要求を技術レベルで満たすための設計枠組みとして、注目されており、これに対応できる製品・システム設計能力は今後、競争力の要件になり得ます。 - EU サイバー・レジリエンス法（Cyber Resilience Act, CRA）
CRA は、デジタル要素を持つ製品（ソフトウェア・組込みシステム含む）に対して、サプライチェーンの脆弱性管理、脆弱性対応期間の義務化、安全設計義務などを課す規則です。
exida の解説によれば、既に IEC 62443 を導入している組織・製品では、CRA 遵守のハードルを下げられる可能性があるとされています。
ただし、CRA はセキュリティ製品そのものに対する義務であり、機械装置（ハード＋ソフト）における安全設計義務との整合性をどうとるかが、これからの課題となります。
このように、IEC 62443 は単なる技術標準にとどまらず、将来の法制度、製品設計要件、国際競争力と密接に結びつく枠組みとなっています。
安全 × セキュリティ統合設計の考え方と実践手法
統合設計を行うには、「安全とセキュリティの関係性を理解し、矛盾を避けつつ、整合的に設計する」ことが必要です。ここでは、主要な考え方と実践のヒントを整理します。
共保証設計（Safety-Security Co-assurance）
安全とセキュリティを別々に設計すると、トレードオフや相互干渉を見落とす危険があります。共保証設計の考え方は、両者を「一体的に設計・評価する」ことを目指します。
- 相互作用の可視化
たとえば、セキュリティ強化のためにフェールセーフ機構を抑制したり、アクセス制御で安全機能へのアクセスを制限したりという設計ミスは、安全性を低下させる恐れがあります。こうした干渉をあらかじめモデル化・可視化しておく必要があります。 - 統合評価手法の適用
前出の SSAF（Bayesian モデルを使った共保証フレームワーク）などを活用し、安全・セキュリティ双方のリスクや信頼度を統合評価し、最適な設計選択を導き出す手法が研究されています。 - セキュリティ要件の段階的導入
設計初期段階から全セキュリティ要件を入れてしまうと、技術的複雑性や設計の過剰化につながりかねません。リスクレベルやシステム構成に応じて、必要最小限のセキュリティ設計から始め、将来的な拡張性を担保する方法が現実的です。
寿命・ライフサイクル観点の統合
安全設計では故障モード・保守設計・予防保守などが重要視されますが、セキュリティ設計では脆弱性の発見・修正、パッチ適用、サポート終了（End-of-Life）管理などが重要です。
これらを統合するには、例えば：
- セキュリティ更新可能な安全機能の設計
安全系ソフトウェアに対しても、脆弱性発見時にパッチ適用可能な仕組みやフェイルバック（安全モードへの切り替え）を設けておく - 変更管理体制
安全設計変更とセキュリティ設計変更は切り離せないため、統合的な変更管理プロセスを導入 - モニタリング・検知体制
運用中の侵入検知・異常ログ監視・脆弱性スキャン等を組み込む - 退役設計
装置寿命末期にはソフトウェア更新できなくなる可能性を見越した設計（最終パッチ供給、隔離モードなど）
こうした統合アプローチを取り入れることで、運用中のセキュリティ維持性と安全性を両立できます。
技術設計の視点：具体的考慮事項
以下は、設計者／ソフトウェア／ハードウエア技術者が具体的に意識すべき視点です：
| 項目 | 内容 |
|---|---|
| アクセス制御・認証・認可 | 最小権限運用、ロールベースアクセス、認証方式、セッション管理 |
| 暗号化・通信保護 | 内部通信・制御ネットワーク通信の暗号化、TLS／IPsec、鍵管理方式 |
| ファームウェア／ソフトウェア更新保護 | 電子署名、改ざん検出、ローリング更新、バックアウト機構 |
| 不正検知・監査ログ | 変更ログ、通信ログ、イベントログ、侵入検知、異常検出 |
| 境界防御・ネットワーク分離 | DMZ、ファイアウォール、ゾーニング、フィルタリング、プロキシ |
| 侵入耐性・フェイルセーフ制御 | 攻撃を受けた際に安全状態に移行できる冗長構成、トラスト境界設計 |
| 耐障害性・冗長化 | 冗長構成やフェイルオーバー設計が、セキュリティ機能と競合しないよう配慮 |
| セキュリティ設計のトラストバウンダリ | 安全側と安全外部分とのインタフェース設計の明確化 |
| ソフトウェア開発プロセス統合 | 安全設計レビュー、脆弱性評価、コード解析、ペネトレーション試験などを組み込む |
| 形式手法の適用 | PLC や制御ロジックに対する形式検証など、システムの数学的正当性を補強する技術が実運用でも注目され始めている。例として、CERN による PLC の形式検証サービス事例。(arXiv) |
実際には、制限されたリソース（処理能力、通信帯域、リアルタイム性制約など）でも動作可能な軽量セキュリティ設計が求められるため、技術的トレードオフや最適化設計が鍵になります。
最新の制度・規格・事例動向
ここでは、近年の制度・規格動向や、実際の適用例をいくつか紹介します。
EU 機械規則（EU Machinery Regulation 2023/1230）
2023年6月に採択された新しい機械規則（Regulation）は、従来の機械指令（Directive）を置き換え、2027年1月から適用されます。
主な変更点：
- サイバー攻撃耐性設計義務
安全関連制御装置やソフトウェアは、意図的攻撃（不正入力、改ざん、通信妨害など）によって危険状態を引き起こしてはならないという要求。 - 変更ログと追跡可能性要求
構成変更、ソフトウェア更新、アクセス操作などをログ記録し、不正操作を追跡可能にすることが義務化。 - ライフサイクルセキュリティ義務
設計・製造から運用・保守・廃棄に至るまで、セキュリティ維持策を講じることを要求。 - AI 制御機能への特別要件
自律制御・適応制御・AI 要素搭載機械については、無人起動禁止、パラメータ改変制御、ログ記録、監督機構確保などの追加要件が検討されています。 - 適合性評価・市場監視強化
市場に出回る機械のサイバー要件適合性を審査・監視する体制が強化されます。
このように、EU 内で機械を提供する企業は、2027年までに機械安全だけでなくセキュリティ設計能力も整備する必要があり、これを見据えた準備は急務といえます。
CRA（Cyber Resilience Act）との関係
EU の CRA は、デジタル製品そのものに対してセキュリティ設計義務を課す法令で、2027年12月から適用見込みとされています。
- CRA は “製品（ハードウェア＋ソフトウェア）” に対する義務を対象とするため、機械装置に内蔵される制御系ソフトウェアも対象となる可能性があります。
- IEC 62443 適用済みの設計・製品は、CRA 要件（脆弱性管理、セキュリティ更新、サプライチェーン対策など）との整合性がとりやすいという解説が出ています。
- ただし、機械安全義務（機械規則）と CRA 義務を同一製品でどう両立させるかは、設計上・責任分界上の課題が残る領域です。
認証制度と適合評価：ISASecure、その他
- ISASecure は IEC 62443 規格に基づく製品および開発プロセス認証制度を運営しています。
- 将来的には「拠点レベルのセキュリティ評価制度（Site Assessment／ACSSA）」の導入構想もあります。
- 認証を取得することにより、設計者／製品ベンダーは顧客信頼性を高め、市場アクセスの証明力を持つ可能性があります。
実証・研究事例
- 形式検証（Formal Verification）を PLC に適用
CERN／GSI による PLC の安全クリティカル制御ソフトウェアに対する形式検証サービス事例などが報告されており、安全系制御ロジックに対しても高信頼性設計手法が現場適用されつつあります。 - Secure-by-Design 通信構成
IEC 61499（産業制御用分散制御アーキテクチャ規格）を対象に、通信リンク部分にセキュア設計を埋め込む手法 (“secure links”) が研究されており、制御アプリケーション設計時点でセキュリティ要件を組み込むアプローチも注目されています。
こうした先端技術適用事例は、将来の適用拡大が期待される分野です。
実務者向けチェックリスト （設計・評価・運用フェーズ別）
以下は、機能安全とセキュリティを統合設計／運用する際に、設計者・エンジニアが現実的に押さえておきたいチェック項目です。
| フェーズ | 主なチェック項目 | 解説および注意点 |
|---|---|---|
| 概念設計・要件定義 | – 安全機能・制御機能に対する脅威モデリング（攻撃モデルの設計） – セキュリティ要件の初期導入（暗号化、認証、ログ記録など） – 安全とセキュリティ間のインタフェース仕様設計 | 脅威モデリング（例：STRIDE、Attack Trees など）を早期に導入。安全要件とのトレードオフを整理すべき。 |
| 危険源分析・リスク評価 | – セキュリティ起因リスクを安全分析に組み込む – 攻撃シナリオごとの影響評価と頻度見積もり – 安全リスク低減策とセキュリティ対策の統合検討 | 通常のハザード分析（HAZOP、FTA、LOPA 等）に加え、攻撃対象型リスク分析も併用。 |
| 要求仕様設計 | – 安全要件とセキュリティ要件の整合性確認 – 最小権限、認証・認可、鍵管理、通信保護要件明記 – フェイルセーフ機構、異常時隔離機構設計 | 要求仕様書にセキュリティ要件を明示的に含めること。両者を分離せず一体化させた設計を推奨。 |
| 詳細設計・アーキテクチャ | – モジュール分離・ゾーニング設計 – 安全／制御系とセキュリティ系の信頼境界設計 – 冗長化、フェイルオーバー、異常遮断設計のセキュリティ影響考慮 | セキュリティ強化がリアルタイム性やリソース制約と競合しないよう設計バランスが重要。 |
| 実装・コーディング | – 安全性・セキュリティコーディング規約適用（例：MISRA、CERT、SEI-CWE 等） – コード静的解析、脆弱性スキャン、動的テスト（ペネトレーションテスト） – ソフトウェアモジュール署名、改ざん検出機構 | 安全向け設計ルールとセキュリティ設計ルールは重複・矛盾することもあり、統合的なガイドラインが望ましい。 |
| 検証・認証試験 | – 安全要件検証（テスト、シミュレーション、FMEA など） – セキュリティ要件検証（侵入テスト、脆弱性評価、通信試験） – 安全／セキュリティ干渉試験 | たとえば、セキュリティ機能導入によって安全タイミング性能が劣化しないかをチェック。 |
| 立ち上げ・運用 | – ログ監視・異常検知体制構築 – パッチ適用管理・脆弱性対応体制整備 – 運用変更管理（ソフトウェア更新、構成変更） – 操作・保守手順書へのセキュリティ運用記述 | 運用者・保守者に対するセキュリティ意識教育も重要。更新時の安全影響を評価できる体制も必要。 |
| 改修・更新・退役 | – 互換性考慮、安全性維持の改修設計 – サポート終了後の隔離設計・フェイルバック機能 – 退役時データ消去、アクセス遮断設計 | 製品寿命後もセキュリティリスクを残さないよう、最終更新設計を想定しておくべき。 |
このチェックリストは、単なる一覧ではなく、実プロジェクトで設計・開発時に逐次参照していく「設計ガイドマップ」として使うのが望ましいでしょう。
まとめ
- 機能安全（IEC 61508 等）と OT セキュリティ（IEC 62443 等）は、かつて別分野だったものが、現代の制御システム設計の中で統合すべき主要テーマになっています。
- IEC 62443 の最新版（例：2-1:2024、2-4:2023、1-5:2023、6-1 等）では、よりプロファイル化・適合性評価強化された方式が取り入れられており、技術設計やガバナンス面での適用性が高まっています。
- 認証制度（ISASecure 等）や国・地域での法制度（EU 機械規則、CRA など）採用が進んでおり、設計者・機械メーカーにとっては無視できない外圧になりつつあります。
- 将来的には、機械安全規格（例：ISO 13849、IEC 62061 等）そのものに、セキュリティ要件を組み込む動き、またはそれを前提とした改訂が起きる可能性もあります。
- 実務的には、設計段階から脅威モデリングを導入し、安全設計とセキュリティ設計を統合する共保証アプローチを採り、ライフサイクル全体でのセキュリティ対応力と保守性を備えた設計を行うことが成功鍵となります。
コメント