JC-STARはどこまで認証すべきなのか？
― 太陽光発電システムにおける「信頼境界」という根本問題

導入

事実近年、JC-STAR（セキュリティ要件適合評価及びラベリング制度）をはじめとするIoTセキュリティ認証・ラベリングの枠組みが整備されつつあります。独立行政法人情報処理推進機構（IPA）は、同制度がIoT機器のセキュリティ要件適合を評価し、ラベル表示により調達時の確認を支援することを目的とすると説明しています。

事実また、系統連系に関する議論のなかでは、パワーコンディショナ（PCS）等の分散型電源設備に対するサイバーセキュリティ要件化が検討されており、JC-STAR等の適合評価を参照する方向性が示されています（時点・対象設備は今後の制度設計により具体化される見込みです）。

考察最低限のセキュリティ水準を市場全体に普及させるという考え方には、調達コストの低減と責任分界の明確化という点で大きな意義があります。しかし、太陽光発電のようなエネルギーシステムでは、制度導入と並行して、次の根本的な疑問が残ります。

認証の境界は、どこなのだろうか。

第1章 — 太陽光発電システムは一つの機械ではない

考察発電所を「PCS1台＝システム1個」と見なすと、認証制度の適用範囲は単純に見えます。しかし現場の実態は、複数のネットワーク機器・制御機器・通信経路が積み上がったシステム・オブ・システムズです。

flowchart TB
  INET["Internet"]
  INET --> LTE["LTE Router"]
  LTE --> VPN["VPN"]
  VPN --> LOG["Logger / Gateway"]
  LOG --> EMS["EMS / ローカル制御"]
  EMS --> SW["L2 Switch"]
  SW --> PCS["PCS / インバータ"]
  PCS --> RS["RS485 / Modbus"]
  RS --> OPT["Power Optimizer / センサ"]
  style INET fill:#f0f4ff,stroke:#0071e3
  style PCS fill:#fff8e6,stroke:#c9a227
  style OPT fill:#eaf7ef,stroke:#2f7a4d
          

Internetから見えない閉域LANの奥に、Logger・EMS・スイッチ・PCSが連なり、さらにRS485配下にオプティマイザや計測機器が接続されます。メガソーラーでは監視カメラ、気象センサ、追加のゲートウェイ、保守用Wi-Fi、NAS、IoTゲートウェイが後から増設されることも珍しくありません。

考察つまり、認証制度が「1製品」にラベルを付与する設計である限り、そのラベルが「システム全体」のどの範囲をカバーするのかは、別途定義されなければなりません。

第2章 — 認証対象はどこまで広がるのか

問い制度設計において、次の各要素を個別に検討する必要があります。

• PCSは認証対象か。系統連系点に最も近い制御機器として要件化の議論があるが、RS485配下まで含むのか。
• Logger / データロガーは。クラウド監視の入口であり、現場LANのハブでもある。
• EMSは。出力制御・需給調整・VPP連携の論理が集中する層。
• LTEルーターは。遠隔監視の常時接続点。
• VPN装置は。閉域とInternetの接続点そのもの。
• L2/L3 Switchは。セグメント分割の要否と認証の関係。
• Wi-Fi APは。保守・設定用に後付けされることが多い。
• 保守PCは。LAN内端末として扱うのか、境界外の持ち込み資産か。
• USB Ethernetアダプタは。1本で閉域を貫通し得る。
• 将来追加されるIoT機器は。竣工時点の認証でカバーできるのか。

第3章 — 信頼境界（Trust Boundary）という考え方

事実産業制御システム（ICS）やエネルギー設備のセキュリティガイドライン（例: IEC 62443、NIST SP 800-82）では、ネットワークを信頼できる領域とそうでない領域に分け、その境界でアクセス制御・監視・分離を行う考え方が一般的です。

考察重要なのは、個々の機器すべてを同一水準で「認証済み」にすることではなく、どの境界を越える通信を厳格に扱うかを設計することです。これを信頼境界（Trust Boundary）と呼びます。

flowchart TB
  INET2["Internet"] --> FW["Firewall"]
  FW --> VPNR["VPN Router"]
  VPNR --> TB[" "]
  TB --> CN["Closed Network（閉域LAN）"]
  CN --> LOG2["Logger"]
  LOG2 --> PCS2["PCS"]
  PCS2 --> RS2["RS485"]
  RS2 --> PO["Power Optimizer"]
  style TB fill:#0071e3,color:#fff,stroke:#0071e3
  style CN fill:#eaf7ef,stroke:#2f7a4d
          

考察閉域LANの内部（Logger → PCS → RS485 → オプティマイザ）は、物理的アクセス制御・施工品質・運用規程によって保護されることが多く、境界の内側と外側で求めるセキュリティ統制の強度を分けるのが実務的です。認証制度がこの産業慣行とどう接続するかが、制度設計の核心です。

第4章 — 本当に下流機器まで管理できるのか

考察本稿の最大の論点は、竣工時点の認証と、運用期間中の構成変化のギャップです。

発電所が完成した翌日から、現場は静かに変化し続けます。

問いこれらの変化を、誰が把握するのでしょうか。

• 発電事業者（オーナー）か、O&M事業者か、EPCか、監視SaaS事業者か。
• 保守会社が新しい機器を接続した事実を、制度上どのように確認するのか。
• 「認証されていないIP機器を接続してはならない」という規範がある場合、その継続的なコンプライアンスを誰が、どの頻度で、どの証跡で示すのか。

flowchart LR
  A["竣工時
認証スナップショット"] --> B["運用1年目"]
  B --> C["機器交換・増設"]
  C --> D["誰が記録する？"]
  D --> E["制度上の
継続確認"]
  style A fill:#eaf7ef,stroke:#2f7a4d
  style E fill:#f0f4ff,stroke:#0071e3
          

第5章 — 正規機器になりすますことは防げるのか

事実JC-STAR等の制度は、製品の設計・実装におけるセキュリティ要件適合を評価します。IPAも、ラベルが想定外の脅威や個別の運用環境における全リスクを保証するものではない旨を説明しています。

考察「認証済み機器のみを接続する」という方針を徹底しても、次の類型のリスクはラベルの有無だけでは排除できません（本稿では具体的な攻撃手順や悪用可能な技法は記載しません）。

• 通信の一方が正規機器を装い、相手側の信頼を利用する。
• 正規機器に保存された認証情報が、運用・設定ミスにより漏えいする。
• 正規機器のソフトウェアが、更新経路やサプライチェーンを通じて改ざんされる。
• 正規機器そのものが侵害され、正規の振る舞いを装って制御系に影響を与える。

したがって、「認証済み機器のみ」という考え方単独では、システム全体の安全性を保証することはできません。認証は必要条件になり得るが、十分条件ではない——これは制度批判ではなく、制度設計者と現場が共有すべき前提です。

第6章 — 認証ではなくアーキテクチャ

考察エネルギーシステムの安全性を議論するとき、Certified Secure（認証によって安全であるとみなす）から、Resilient by Architecture（アーキテクチャによって障害を局所化し、運用を継続する）へ視点を移すことが有用です。

詳細は ホワイトペーパー「認証済みなら本当に安全なのか？」 および Resilient by Architecture 実務編 を参照してください。

関連記事・シリーズ