★1がダメなら★2？事業者の自費で？いつまで続くJC-STARというやつ

前回、JC-STARが低圧のHUAWEI製PCSに与える影響について書きました。

今回はなぜあそこまでキレているのか補足します。

2027年10月以降JC-STARが連系要件になったところで、不正アクセスの温床には何ら手を打てていないのだから、不正アクセスや踏み台になる事件は一向に減らないでしょうね。

簡単な発電所ネットワーク構成図ですが、ローカルネット内のPCやWebCAMは規制対象外だそうで、ルーターもポート開け放題でも別に問題ないようです。（当然非推奨ではあるが）

★1がダメなら★2にするのでしょうか？実質的に意味のない事をいつまでやるのかな？事業者の自費で？今回10kW未満にも適用するんでしょ？マジで？

やってられないのよね。

そもそも無限に項目が増え続けるクライアント側チェックリストで対処しようとするのがバカすぎるわけで、ハッキングされるものというところを出発点にして、基本は遠隔制御OFF、遠隔制御する場合はあらかじめ登録された事業者への認証を行って認証できるまで遠隔制御はできない仕組みを仕様化すればいいだけ。

踏み台を防止するならば発電所ネットワークの入口のポートをすべて閉じて内側からしかアクセスできないようにすればいいだけなのに

いつまでこんなバカな話に付き合わなければならないのか？

どうせ、役所は最初から何も考えていなかったのだろう？と思っていたので

Table of Contents

最初の想定はどうだったのか？調べてみた

先に言葉を整理しておきます。以下では、電力会社サーバーとPCSを結ぶ出力制御の通信経路を「本線」、メーカー独自の遠隔保守機能やローカルネット内の監視カメラ・ルーターなど、出力制御の仕様に含まれない周辺の通信経路を「勝手口」と呼びます。この記事の評価が割れて見えるとしたら、この二つを分けて読んでいただくためです。

2015年の設計は意外と堅かった

2015年の設計は、セキュリティをかなり真面目に考えていた。問題は、その後の修正方法を間違えたことです。

2015年の系統ワーキンググループでは、オンライン出力制御の基本要件として

電力の安定供給のため、必要なセキュリティを確保すること

が明記されていました。

想定していた脅威も、

ウイルス感染
サイバー攻撃
不正侵入
PCSのなりすまし
データ改ざん
通信の盗聴

など、かなり網羅的です。

対策としても、

PCS側からしか通信を開始できない
ID認証とSSL通信
重要情報は送らない
スケジュールのバックアップ

などが採用されていました。

つまり、「電力会社サーバーとPCSを結ぶ本線」は、当時としてはかなり慎重に設計されていたのです。

抜けていたのはメーカーの「勝手口」

問題だったのは本線ではありません。

PCSや監視装置には、メーカー独自の遠隔保守機能があります。

例えばHUAWEIならFusionSolar経由でSmartLoggerへアクセスできます。

これは出力制御仕様とは別に用意された保守用経路です。

ここには、本線で採用された

外部からの着信を受け付けない

という考え方が適用されていませんでした。

2024年にはSolarView Compactが約800台まとめて不正アクセスされ、ネットバンキング不正送金の踏み台になる事件も発生しました。

出力制御装置ではありませんでしたが、

本線は堅いが、保守用インターフェースは弱い

という問題を示した事件だったと言えます。

本来やるべきだった対策

産業制御システムの国際規格IEC62443では、

普段は外部から接続できない
保守時だけ認証済み技術者が一時的に接続する

という考え方が標準です。

これは2015年に出力制御で採用された設計思想とほぼ同じです。

つまり、保守用インターフェースにも同じ原則を適用するだけでよかった。

メーカーや国籍は関係ありません。

HUAWEIでも、OMRONでも、Panasonicでも、「保守用ポートは通常閉じる」という要件を追加すれば済む話だったはずです。

ところが選ばれたのはJC-STAR

2024年の事件を受け、経産省が対策を検討したこと自体は当然です。

しかし採用されたのは、IoT製品全般向けのJC-STARでした。

経産省自身も、

JC-STAR★1では太陽光発電設備に必要な対策をすべて満たすものではない

と説明しています。

さらに、

★1・★2は自己適合宣言
第三者が実際に検証するのは★3

という制度です。

低圧太陽光で義務化される予定なのは★1だけ。

つまり、事業者には負担が増える一方、本当に重要な部分は十分検証されません。しかも、JC-STARの対象はあくまでPCS・EMSなど系統連系に関わる制御システムに限られ、冒頭で触れたWebCAMやルーターは対象外のままです。JC-STARをどれだけ徹底しても、非連系機器の踏み台化リスクは手つかずで残ります。

問題は「対策がずれた」こと

ここまでの流れを整理すると、

2015年の設計で本線のセキュリティはかなり考えられていた。
弱点はメーカー独自の保守用インターフェースだった。
2024年の事件でその弱点が明らかになった。
しかし対策は、その穴を塞ぐことではなく、汎用IoT制度の導入になった。
その結果、事業者負担は増えた一方で、本質的な問題は残った。

本当に必要だったこと

本来必要だったのは、とてもシンプルです。

系統連系技術要件に、保守用インターフェースは通常時に外部から接続できないことを義務付ける。

保守が必要な場合だけ、認証された技術者がアクセスできるようにする。

この要件をメーカー共通で課せば、国籍を問わず同じ基準で評価できます。ただし、これはメーカーのクラウド基盤（HUAWEIで言えばFusionSolar側）自体が乗っ取られた場合までは防げません。装置側が着信を受け付けない設計であっても、正規の認証ルートを通じて不正な命令が流れ込む可能性は残るため、メーカー側のクラウド基盤の認証強度や監査体制についても、別途問う必要があります。

ただし、これだけでは冒頭で触れたWebCAMやルーターの踏み台化までは防げません。系統連系技術要件の対象はあくまで連系する発電設備であり、監視カメラのような非連系機器はそもそも対象の外にあるからです。PCS・EMSの保守ポートを閉じるのとあわせて、発電所内ネットワーク全体を対象にした最低限のポート管理・機器分離の義務化も必要です。なお、これはJC-STARのように毎年チェックリストを見直し続けるような継続的な自己申告コストではなく、系統連系の申請時に一度確認すれば足りる設計にすべきです。負担の性質が違うことは強調しておきたいところです。

JC-STARのような汎用制度を積み重ねるよりも、この二点を義務化した方が、効果も高く、事業者負担も小さかったのではないでしょうか。

今後も、本来防ぎたかった不正ログインは減らないでしょう。★1がダメなら★2にするのでしょうか？いつまでやるのかな？事業者の自費で？

やってられないのよね。