コンプライアンス · IEC 62443

IEC 62443準拠を証明・維持するために

IEC 62443-4-1認証取得・IEC 62443-4-2準拠のSecomeaを活用した準拠証明のアプローチ。監査対応・証跡提示・継続的改善の観点から解説します。

規制対応の観点と技術実装の観点

IEC 62443 は、規制が求める"何を"を、OT現場で実装できる"どう"に翻訳する層です。本ページは規制対応・監査の観点を、技術実装の詳細は技術実装ページを扱います。

このページ

規制対応・監査の観点

お客様がIEC 62443準拠を達成・証明するための方法。監査証跡の取得・準拠証明の強化・継続的改善の実証。

  • 監査証跡の取得・提示方法
  • 準拠証明を強化する製品選択
  • 継続的改善の記録・実証
  • 監査当局への説明責任
関連ページ

技術実装の観点

Secomeaがどのようにネットワークセグメンテーション・アクセス制御・暗号化等をIEC 62443に準拠した形で実装しているか。

技術実装ページを見る

フレームワークを並べて比べると、同じ概念が言葉を変えて何度も現れます。代表的な3つの要件で、各規格が IEC 62443 でどう1つの実装に束ねられるかを示します。

アクセス制御

NIS2 サイバーリスク管理措置の一部としてのアクセス制御
CRA 製品ライフサイクル全体での安全なアクセス制御・不正利用からの保護
NIST CSF PR.AC(防御 ― アクセス制御)
ゼロトラスト 最小権限の徹底・全アクセス要求でのID検証
IEC 62443 識別・認証制御(FR1)/使用制御(FR2)
実務ではこうなる 役割ベースのアクセス制御/強力な認証(ユーザ+サービス)/OT全体での最小権限の強制/ゾーン・コンジット単位でのアクセス範囲の限定。

ネットワークセグメンテーション

NIS2 インシデントの影響を局限するリスク管理・封じ込め措置
CRA 安全なシステム設計・不正なデータフローからの保護
NIST CSF PR.PT(防御技術)+ PR.AC
ゼロトラスト 横方向の移動(ラテラルムーブメント)の阻止・システム隔離
IEC 62443 ゾーンとコンジット/制限されたデータフロー(FR5)
実務ではこうなる OTシステムをリスクに応じたゾーンに分割/厳格に制御された通信経路/横展開の抑止/サイバーインシデントの封じ込め。

脆弱性管理

NIS2 リスク管理・インシデント対応・脆弱性管理プロセス
CRA 脆弱性ハンドリング・報告・製品ライフサイクルにわたる責任
NIST CSF 識別(ID)・対応(RS)機能
ゼロトラスト 継続的な監視と改善
IEC 62443 セキュア開発ライフサイクル(4-1)/コンポーネント・システム要件(4-2)
実務ではこうなる セキュア開発プロセス/継続的な脆弱性管理/事業者とベンダー間の協調的な対応/コンポーネント・依存関係の可視化。

同じ要件でも、規格ごとに言葉が違うだけ。IEC 62443 を共通言語にすれば、一度の実装で得た証跡を、各規格の準拠を示す根拠として再利用できます。

IEC 62443 に基づく責任分担——どこまでが Secomea、どこからがお客様か

IEC 62443 では、OTシステムの安全は1社だけでは成り立ちません。製品を提供する側(Secomea)と、システムを設計・運用する側(お客様・SI)が、それぞれの責任を分担します。しかもその境界はくっきり割れるのではなく、Secomea が濃く担う領域から、お客様・SI が担う領域へ連続して移り変わります。

役割は活動ベース。1組織が複数役割を兼ね、1役割が複数組織に分かれ得ます。帯の位置は典型的な分担の重心を表します。

Secomea が中核的に担う領域

製品サプライヤ

  • 多要素認証・SSO・RBAC・x509
  • きめ細かい権限・最小権限・JITアクセス
  • TLS1.3・AES256暗号化・署名済みFW
  • 監査ログ・セッション記録・SIEM連携
  • クラウド運用部分(Secomea Cloud / GateManager / Prime)では保守事業者としての責任も担う

共同で担う領域

構成・契約により分担

  • ゾーン/コンジット境界の設計支援
  • セグメンテーション・産業用DMZ配置支援
  • IdP・SIEM 連携
  • インシデント対応連携(NIS2 24時間/72時間)

資産所有者・SI が担う領域

資産所有者・統合事業者

  • プラント全体のゾーン設計
  • ファイアウォール・IDS/IPS・物理保護
  • バックアップ・復旧・事業継続(FR7)
  • システム全体の最終的な説明責任
製品機能で実現 設定・運用・連携で実現 システム設計・運用で実現

説明責任(accountability)

分担がどう動いても、システム全体の説明責任は全幅にわたって資産所有者に固定されます。製品の導入では委譲できません。

↑ 上の帯(移り変わる責任分担)と対比:このバーは全幅で動かない=説明責任の固定

本マップは概略です。実際の適合判断には、対象環境・ゾーン/コンジット構成・目標セキュリティレベル(SL-T)・運用証跡・契約範囲の確認が必要です。

基本要件(FR)ごとの責任マップ

IEC 62443 は、要求の「宛先」ごとに分かれた規格群です。製品をつくる工程に対する 4-1、製品(コンポーネント)の技術要件に対する 4-2、システム全体に対する 3-3——。Secomea は IEC 62443-4-1 認証取得(TÜV)IEC 62443-4-2(コンポーネント要件)について第三者監査により準拠を実証しています。つまり、製品の開発工程と技術仕様が第三者に裏付けられた「確かな部品」です。

一方 3-3 はシステム規格で、ゾーン設計・他機器・運用まで含めたシステム全体が満たすべき要件です。個々の製品が単独で「3-3 を取得」することはできず、「3-3 認証済みの製品です」という説明は本来成り立ちません。確かな部品(4-1/4-2)を使ってシステム全体で 3-3 を満たすのは、資産所有者・統合事業者の領域です。下表は、3-3 が定める7つの基本要件(Foundational Requirements=FR)ごとに、Secomea が機能として提供する範囲と、お客様が担う範囲を整理したものです。

セキュリティレベル(SL)の達成は、構成・統合・運用手順・補完的制御を含むシステム全体(SuC)に依存します。製品が提示できるのは能力としてのセキュリティレベル(SL-C)です。目標SL(SL-T)の設定・達成SL(SL-A)の実現は、対象システム全体で決まります。
基本要件(FR)
Secomea の機能(製品サプライヤ領域)
お客様の責任範囲
基本要件1(FR1)識別と認証の制御認可されたユーザ・機器・プロセスだけが産業資産にアクセスできるようにする
多要素認証・SSO・RBAC・x509証明書・アカウント管理・パスワード制御・機器認証・GateManager のID基盤・JITアクセス
IDガバナンスの定義、MFAポリシーの強制、ユーザのライフサイクル管理、特権アクセス付与の棚卸し
基本要件2(FR2)使用制御認証済みユーザを、認可された資産・機能の範囲に限定する
きめ細かい権限・RBAC・ユーザグループ・JITアクセス・アクセス申請ワークフロー・セッションロック/終了・承認フロー・監査可能な操作
ロール・承認プロセス・アクセスポリシー・最小権限モデルの定義
基本要件3(FR3)システム完全性システム・ソフト・通信・運用機能を改ざんや不正変更から保護する
TLS1.3・AES256暗号化・署名済みファームウェア更新・セキュアブート・ソフト完全性検証・セッション完全性・マルウェアスキャン付き安全なファイル転送・堅牢化されたアプライアンス
サポート対象バージョンの維持、更新の適用、変更の運用影響評価、必要に応じた補完的制御の実装
基本要件4(FR4)データ機密性運用・構成・認証データを不正な開示から保護する
TLS暗号化・証明書検証・暗号化トンネル・認証済み通信・安全な資格情報の取り扱い・x509信頼基盤
エンドポイント保護、データ分類、エクスポートしたデータの安全な保管、運用データのガバナンス
基本要件5(FR5)制限されたデータフロー通信を承認された経路に限定し攻撃面を縮小する
アウトバウンドのみのアーキテクチャ・仲介型リモートアクセス・資産単位の権限・サービス制限・セグメンテーション支援・ゾーン境界支援・Purdue準拠配置支援
ネットワークセグメンテーション・産業用DMZ・ファイアウォール規則・IEC 62443のゾーン/コンジット設計の実装(お客様・統合事業者)
基本要件6(FR6)イベントへの適時対応セキュリティ関連の活動を検知・監視・調査・対応する
監査ログ・セッション記録・リアルタイム監視・活動追跡・アラート・SIEM連携・否認防止支援・Prime/GateManager による一元可視化
ログのレビュー、異常の調査、セキュリティ監視の統合、インシデント対応手順の運用。IDS/IPS は必要に応じ外部の補完的制御として残る
基本要件7(FR7)リソース可用性リモートアクセス基盤の可用性・回復性・復旧・ライフサイクル可視性を維持する
リソース管理・バックアップ支援・復旧/再構成機能・一元管理・構成管理・資産インベントリ・ファームウェア/脆弱性の可視化・最小機能アーキテクチャ
基盤レベルのDoS対策、機器の物理保護、事業継続計画、UPS配置、運用回復性(一部は共同責任)

線引きの先も、ひとりにしない。

どこまでが製品で、どこからが運用か——その線引きは、対象システムごとに変わります。自社の責任分担を整理する第一歩として、Secomea の機能が IEC 62443 のどの要件に応えるのかを、デモを交えてご説明します。その先のゾーン設計やシステム統合は、70以上のパートナー網とともに支援します。

監査対応

IEC 62443準拠を証明する4つのアプローチ

Secomeaを活用してIEC 62443準拠を証明・維持するための実践的なアプローチです。

01

アクセス管理の証跡提示

IEC 62443は誰がいつどのシステムにアクセスしたかの完全な記録を求めます。Secomeaの操作ログ・セッション録画により、監査時に即座に証跡を提示できます。

02

ゾーニングの実装証明

IEC 62443はOT環境をゾーンとコンジットに分割することを求めます。Secomeaの装置単位アクセス制御により、ネットワークセグメンテーションの実装を証明できます。

03

認証済み製品の採用

IEC 62443-4-1認証取得済みのSecomeaを採用することで、お客様側の準拠証明を強化できます。第三者認証済みの製品採用は監査での客観的な根拠となります。

04

継続的なセキュリティ改善

IEC 62443は継続的なセキュリティ改善を求めます。Secomeaの脆弱性ハブによりSiteManagerの脆弱性スコア・EoL/EoS状態を継続管理し、改善サイクルを実証できます。

よくある質問

IEC 62443準拠とIEC 62443認証の違いは何ですか?
IEC 62443認証は第三者機関が製品・プロセスを審査して発行するものです。IEC 62443準拠は規格の要件を満たしていることを指しますが、必ずしも第三者認証を伴いません。Secomeaはプロセス規格のIEC 62443-4-1の認証を取得し、コンポーネント要件のIEC 62443-4-2について第三者監査により準拠を実証しています。なお、IEC 62443-3-3はシステム全体に対する規格であり、お客様のシステム側で達成される領域です(Secomeaはその達成に寄与します)。
SecomeaはIEC 62443準拠を証明するために何を提供できますか?
IEC 62443-4-1認証証明書、IEC 62443-4-2(コンポーネント要件)準拠を示す技術文書、操作ログ・セッション録画による監査証跡、脆弱性ハブによる継続的改善の記録を提供できます。
お客様自身がIEC 62443準拠を達成するためにSecomeaはどう役立ちますか?
Secomeaはリモートアクセス・アクセス制御・監査証跡の観点でIEC 62443の要件を支援します。ただし、IEC 62443準拠はシステム全体の設計・運用・組織的な取り組みを含む包括的な対応が必要です。Secomeaはその重要な構成要素として機能します。
IEC 62443の技術的な実装の詳細はどこで確認できますか?
Secomeaがどのようにネットワークセグメンテーション・アクセス制御・暗号化等をIEC 62443に準拠した形で実装しているかの詳細は、セキュリティページのIEC 62443技術実装ページをご覧ください。
Secomeaを導入すればNIS2やCRAに対応できますか?
Secomeaは対応を支援しますが、導入だけで完了するわけではありません。IEC 62443は責任分担を前提とし、システム全体の説明責任は資産所有者にあります。NIS2は経営層の責任・インシデント報告・サプライチェーン管理を、CRAは適合性評価・技術文書・サポート期間を含み、製品機能だけでは完結しません。自社で担う範囲とベンダー・SIに任せる範囲を線引きすることが第一歩です。
Secomea製品でセキュリティレベルSL3を達成できますか?
製品が提示できるのは能力としてのセキュリティレベル(SL-C)です。実際に達成されるSL(SL-A)は、ゾーン設計・補完的制御・運用を含むシステム全体で決まります。目標とするSL(SL-T)はお客様のリスクアセスメントに基づいて設定されます。

IEC 62443準拠の対応を相談する

自社のIEC 62443準拠状況の確認と、Secomeaを活用した対応アプローチをご提案します。