サイバーレジリエンス法では、「製品（ハード／ソフト）に関するサプライチェーン可視化」「ソフトウェア部品表（SBOM）」「脆弱性対応の体制化」「報告（ENISAの単一報告プラットフォーム経由）」などが求められます。工場・プラント・IT/OT環境で使う機器を管理する資産一覧表（アセットインベントリ）は、文書要求に直結する重要ドキュメントです。
なぜ「資産一覧表」が必須なのか
報告義務（脆弱性・重大インシデント）や技術文書保持、サポート／アップデート期間の明示は CRA の主要な要件で、資産一覧表はこの情報を収集・管理する実務的基礎となります。
CRA は「製品（products with digital elements）」の設計→生産→流通→使用→廃棄までのライフサイクル全体に対するセキュリティ要件を定めます。製品に関する情報（技術文書、SBOM、脆弱性対応情報など）は市場監視当局やENISAの調査で求められるようになります。
資産一覧表とは？
- 目的：工場・プラント・オフィスに存在する「重要な機器、ソフトウェア、ネットワーク要素、IoT」などを一覧化し、CRA 遵守・脆弱性管理・市場監視対応・インシデント対応の基盤にすること。
- 役割：
- どんな機器があるかを可視化する
- 依存関係（ネットワーク接続・データの流れ）を把握する
- リスク分析・セキュリティ対策の土台になる
👉 「棚卸し表」や「資産台帳」と考えるとイメージしやすいです。
作成手順（ステップごと）
ステップ①：範囲を決める
- 対象範囲を明確に：例）OT 制御系 / IT（事務系） / 両方 / 全社 / 特定工場。
- オーナーを決定：セキュリティ責任者（CISO）または工場長、データ保有責任者など。
- 期限設定：初版更新サイクル（四半期 or 半年）を決める。
CRA視点：対象に含まれる「製品」が CRA の「products with digital elements」に該当するかを判定（接続性や機能から判断）
ステップ②：資産の洗い出し（インベントリ収集）
- 収集方法：既存設備台帳、購買履歴、ネットワークスキャン、現地目視、ベンダーへの問い合わせ。
- カテゴリ分け（推奨）：情報系 / 制御系 / ネットワーク / フィールド（センサ／アクチュエータ）
ステップ③：基本情報の収集
- 必須情報（CRA と市場監視で要求されやすい）：製品名 / 型番 / バージョン / ベンダー / 製造国 / 製造者の連絡先 / 出荷日・導入日 / サポート終了日（EOL） / SBOM 有無 / 脆弱性連絡先（メール） / 技術文書所在。
- 追加情報（運用的価値）：接続先（IP、VLAN、ネットワーク名）、管理ポート有無（USB/シリアル/Wi-Fi）、更新方式（OTA／手動）、暗号機能の有無、ログ取得可否、リスク評価（初期スコア）、重要性ランク。
ステップ④：表形式で整理する
- Excel/CSV/CMDBに格納。
- アクセス制御：技術情報は機密性が高いため閲覧権限を限定。
- 変更履歴を残す（誰がいつ何を更新したか）
CRA視点：技術文書（技術ファイル）や SBOM 等は「市場監視当局が求めたら提示できるよう」原単位で保管・保持（最低10年などの要求あり）。
CRA に即した 項目一覧
以下は Excel 列（カラム）としてそのまま使える一例。
- No（連番）
- 製品名（Product name）
- 型番／モデル（Model）
- ソフトウェア版（Version / FW）
- 製造業者（Manufacturer name） + 連絡先（メール/住所）
- 販売者/輸入者（if applicable：Importer / Distributor）
- 製造国／出荷日（Manufacture date / Ship date）
- 製品分類（CRA Annex 判定） — Class 1 / Class 2 / Critical（参照：Annex III / Annex IV） 。
- SBOM（有/無） + フォーマット（SPDX / CycloneDX / その他） — SBOM がある場合はファイルパス/URL を記載。推奨フォーマット：SPDX / CycloneDX。
- SBOM（最終更新日）
- 技術文書（Technical file）所在（社内パス or クラウド URL） — 参照：Annex VII の要件。
- ソフトウェア構成（主要コンポーネント / 主要OSS名） — トップレベルのみで良い（詳細はSBOM）
- 脆弱性窓口（Vulnerability disclosure contact：メール/URL） — 外部研究者用（CRA 要求） 。
- サポート期間（Security updates provide until / End-of-support date） — CRA要件に合わせて明記（例：最短5年、製品の想定寿命に応じて設定）。
- 自動更新の有無（OTA） + 更新署名の有無（Yes/No）
- 管理ポート/USB/シリアル/Wi-Fi の有無（Yes/No）
- 暗号化実装（TLS/secure element/secure boot）簡記
- ロギング/テレメトリの送信先（IP/URL）
- 依存関係（上位下位依存：どのシステムに影響するか）
- 重要度ランク（High/Medium/Low） — ビジネス影響を簡易評価
- 市場向け表示（CE マークの有無、EU宣言の有無とURL）
- 技術文書保持期間（例：10 年）／改訂履歴参照
- 備考（購入履歴、保守契約、ライセンス情報等）
例：Excelで作成（簡易サンプル）
| No | 資産名 | 資産種別 | 設置場所 | 接続先NW | OS/バージョン | 通信プロトコル | 機能 | 無線/USB有無 |
|---|---|---|---|---|---|---|---|---|
| 1 | 監視端末 | 情報系資産 | 執務室 | 情報NW | Windows 10 | TCP/UDP | 入出力 | USBあり |
| 2 | ファイアウォール | ネットワーク資産 | サーバ室 | 情報NW/DMZ | 独自OS | TCP/UDP | ゲート | USBなし |
| 3 | コントローラ | 制御系資産 | フィールド | 制御NW | 独自OS | Modbus/TCP | コマンド発行 | USBなし |
👉 このように 一目でシステム構成が見える化 されるのがゴールです。
運用・更新ルールと保持期間
- 更新頻度：少なくとも四半期ごと（重要インシデントがあれば即更新）。
- 保持期間：CRA は「技術文書の提示・保持」を義務化（市場監視で提示が必要）。技術文書・適合性情報等は 10 年間の保管が実務上要求されています（EUR-Lex 規定）。
- 脆弱性対応：CRA の報告義務では、早期警報（severe incident / actively exploited vulnerability）に対する初期報告が 24 時間以内、続報が 72 時間以内などのタイムラインが定められています（条文参照）。ENISA が管理する単一報告プラットフォームを通じた通報が前提です。※正確なタイムラインは条項で確認のこと。
資産一覧表は「負担」ではなく「武器」
資産一覧表は「規制対応のための追加書類」と思えるかもしれません。
しかし実際には、これを適切に整備することで、次のようなメリットが得られます。
- 市場からの信頼獲得（「この会社の製品は安全だ」という証拠）
- インシデント時のリスク最小化（誰が責任者か、どの手順で通知するかが即時把握できる）
- グローバル競争力の強化（EUだけでなく他地域でも「セキュリティに強い企業」と認識される）
つまり、資産一覧表は「規制対応の負担」ではなく「企業の資産」として活用できるのです。
MSDコンサルタント
コメント