認証済みなら本当に安全なのか？
太陽光発電システムとサイバーセキュリティの根本問題

1. なぜIoTセキュリティ認証が必要とされるのか

太陽光PCS、データロガー、EMS、EV充電器は、RS485やModbusで現場を結び、LTEやVPNでクラウドへ上がり、APIで他システムと連携します。こうした機器が量産・長期設置されるとき、次の問題が繰り返し観測されてきました。

• 固定パスワード — 出荷時の初期値が現場で変更されない。
• アップデート不能 — 脆弱性が公開されても、保守終了・通信経路なし・更新手順不明で修正できない。
• 責任主体不明 — メーカー、EPC、O&M、クラウド事業者、需要家のどれが「この構成の安全性」を見ているか曖昧。

JC-STARのようなラベリング制度は、こうした最低限の品質を底上げし、調達時の確認コストを下げるうえで意義があります。IPAも、ラベルは完全な安全保証ではなく、想定外の脅威や個別運用環境までは包含しないと説明しています。

本稿は「認証不要論」ではありません。むしろ、認証制度が成功するために、何を認証の外側に置き、何を運用で補うべきかを整理する試みです。

2. 認証済み＝安全ではない

認証は、ある時点・ある構成・あるテスト条件における適合を示します。しかしエネルギーIoTの安全性は静的な状態ではなく、接続・更新・運用とともに変化する動的な性質です。

認証後も残るリスクの例

• クラウド障害 — 監視・出力制御・認証基盤の停止が、多数設備の同時挙動変化を招く。
• OTA更新失敗 — セキュリティ修正のつもりが、制御ロジック変更や不完全更新で運転リスクに。
• API侵害 — 認証済み機器より上位のSaaS、OCPP CSMS、VPP APIが単一点障害・侵害点になる。
• 運用ミス — 共通保守ID、過大権限、不要ポート開放、設定の横展開。
• 保守PC感染 — 現場LANへの持ち込み、USBメモリ、リモート保守端末。
• サプライチェーン — ファームウェア署名、OSSライブラリ、委託開発、保守アカウントの長期管理。

flowchart TB
  A["認証済み機器
(PCS / Logger / EMS)"] --> B["クラウド / SaaS"]
  B --> C["API / OCPP / VPP"]
  C --> D["OTA / 設定更新"]
  D --> E["運用
(保守PC・権限・ログ)"]
  E -.->|構成変更・侵害| A
  style A fill:#eaf7ef,stroke:#2f7a4d
  style E fill:#f0f4ff,stroke:#0071e3
          

詳しくは関連記事「認証済み機器を増やすほど安全になるのか」をご覧ください。

3. 本当に認証すべき境界はどこなのか？

系統連系の太陽光設備では、おおむね次のような階層が存在します。どこまでを「認証対象の境界」に置くかは、制度設計と実務の両方で未整理の部分が残ります。

flowchart TB
  INET["Internet"] --> VPN["認証済み VPNルーター"]
  VPN --> LAN["閉域 LAN"]
  LAN --> LOG["Logger / ゲートウェイ"]
  LOG --> RS["RS485 / Modbus"]
  RS --> PCS["PCS / インバータ"]
  LAN --> EMS["EMS / ローカル制御"]
  LAN --> EV["EV充電器 (OCPP)"]
  style VPN fill:#eaf7ef,stroke:#2f7a4d
  style PCS fill:#fff8e6,stroke:#c9a227
          

• PCSまで認証すべきなのか？ RS485配下のセンサは？
• Loggerは？ 交換・増設時の再認証は誰が行うのか？
• 下流のIP機器（カメラ、追加AP）は対象外でよいのか？
• 保守PCは境界の内側か外側か？
• Wi-Fi APを後付けしたら、誰が構成変更を検知するのか？
• USB-LANアダプタ一本で閉域が貫通した場合、制度上どう扱うのか？
• その追加・変更を、誰が継続的に確認するのか？

HuaweiやSolarEdge、その他のメーカー名を挙げる必要はありません。同じメーカーでも、インターネット直結か閉域か、OTAを誰が承認するか、保守権限を誰が持つかで実効リスクは変わります。境界の定義がなければ、認証は点検のたびに「その場限りのスナップショット」に留まります。

→ 関連記事：認証の境界をどこに引くか

4. Who Watches the Watchmen?

認証済み機器の「状態を維持する」には、出荷時の適合だけでは足りません。運用フェーズでは次が必要になります。

• 資産管理（何がどこに接続されているか）
• NAC（不正端末の検知・隔離）
• 構成監視（設定・ファームウェア・証明書のドリフト検知）
• 証明書・鍵のライフサイクル管理
• クラウド側のログ・権限・API監視

すると自然にこう問われます。「その監視システムは、誰が監視するのか？」

監視を増やすほど、監視基盤そのものが新たな攻撃面・単一点障害・運用負荷の源泉になり得ます。Zero Trust（ゼロトラスト）を掲げながら、実装がCentralized Trust（中央集権的な信頼の集約）に寄ると、複雑性そのものが脆弱性を生む——これは理論上の懸念ではなく、大規模クラウド障害や集中ID侵害の事例から学べるパターンです。

flowchart LR
  W1["Watch: 機器"] --> W2["Watch: NAC/CMDB"]
  W2 --> W3["Watch: SIEM/クラウド"]
  W3 --> W4["Watch: ???"]
  style W4 fill:#ffecec,stroke:#c9342a
        

→ 関連記事：Who Watches the Watchmen?

5. エネルギーシステムにおいて本当に重要なこと

認証済み機器の台数を増やすことと、系統・需要家・事業継続の安全性を高めることは、同じ指標ではありません。エネルギー実務で重視すべきは次の能力です。

電力設備の世界には、昔から保護協調とフェイルセーフがあります。異常時に危険側へ倒れ、一部の故障が全体停止に波及しない。サイバーセキュリティも同様に、

通信断時に一律ゼロ出力へ落とす設計は、系統側には分かりやすい安全側です。しかし広域に同一ロジックが入ると、DNS障害・カレンダー配信障害が相関的な同時停止を生む可能性もあります。Fail-safe と Graceful Degradation のバランスは、制度議論の中心に据える価値があります。

6. 静的認証中心とアーキテクチャ中心の比較

flowchart LR
  subgraph CS["Certified Secure 志向"]
    C1["ラベル確認"] --> C2["調達完了"]
  end
  subgraph RA["Resilient by Architecture"]
    R1["境界定義"] --> R2["疎結合設計"]
    R2 --> R3["縮退運転"]
    R3 --> R4["継続観測"]
  end
  CS -.->|不足を補う| RA
          

→ 関連記事：Resilient by Architecture 実務チェックリスト

7. I-S3としての提言 — 読者への問い

I-S3は太陽光・蓄電池・EV充電の設計施工とO&Mを通じ、運用で品質を確認し続けることを重視してきました。セキュリティも、ラベル取得の書類だけでなく、通信経路・権限・異常時の振る舞いを見続けるべき領域です。以下の問いに、貴社の設備で答えられるかご確認ください。

1. 認証の境界はどこにありますか？ 図面・契約・保守手順に明文化されていますか。
2. 認証済み機器の下流に新たな機器が接続されていないことを、誰がどの頻度で確認しますか。
3. 認証済み機器を増やすことと、システム全体の安全性向上は、同じKPIで測れますか。
4. 真に重要なのは「認証済みであること」ではなく、壊れても動き続けられることではありませんか。

これらは答えを押し付けるための問いではありません。JC-STARや系統連系要件が進むなかで、現場が迷わないための共通言語として使っていただければ幸いです。

関連記事・シリーズ

参考情報

• IPA「セキュリティ要件適合評価及びラベリング制度（JC-STAR）」
• 資源エネルギー庁「分散型電源のサイバーセキュリティ対策の要件化に係る今後の対応について」（第19回グリッドコード検討会 資料6 等）
• 各一般送配電事業者の系統連系技術要件
• NIST SP 800-82（ICS セキュリティ）、IEC 62443 等の公開ガイドライン