SOUND OFF!!! – Should OPC really be spelled OOPS?
上の記事ではControlGlobal誌にて発表されたホワイトペーパーを引用しており、そこにはOPCを使う場合のリスクについて書かれている。ここでのリスクとは基本的にセキュリティに関連している。
OPCの抱えるセキュリティ上の問題点は幾つかある。
-
基本技術をDCOMとしている問題
実装上の問題
運用上の問題
OPC-Fの対応のまずさ
1番目の問題点はOPCがDCOMをベースとした技術である為、DCOMやRPCに関連して発生する脆弱性がそのままOPCの脆弱性となる。とくにRPC/DCOMに関する脆弱性はクリティカルな物が今までも多く、一般のオフィス環境以上にパッチを当てにくいプラント・ファクトリフロアの装置に置いてはかなり根深い問題になる。基本的にプラント・ファクトリフロアは外のネットワークと切り離されている為、Windows Update, WSUSが使えない、使いにくい環境にあり、かつ製造設備と密に繋がっているので、機器の停止が難しい。
2番目の実装上の問題点は、OPCとしては一応OPC Securityとして、今の基準では十分ではないかもしれないがセキュリティに関する仕様があるにもかかわらず、ほとんどのベンダがその実装をしていない。また、次の問題点とも関わるが、DCOMが持つ通常の認証システムでさえ満足にサポートしていないケースが多い。また、そのプログラム実行にあたり本当にAdministrator権限は必要なんだろうか。
3番目の運用上の問題点は、まずDCOMセキュリティの関して最小限の設定がなされているのだろうかということ。簡単に言えばEveryoneフルコントロールとなっていませんか、プログラムの実行は不必要にAdministrator権限で動作していませんかと言うところなのだが、これは大抵のOPC製品のマニュアルにはそう書かれており、ユーザーとしてはそうするしかないのも実情だと思う。これを回避するには、ネットワークレベルで認証をかけセキュアにするしかないが(例：IPsec)、プラントフロアの設備設計、設備管理に関わる人はそこまでネットワークに詳しくなく、そこまでコストをかけられないのも実情だろう。ついこの間までは全部オシロとテスターだけで何とかなっていた世界にみんな住んでいたわけで、関係者全てネットワークに対する知識やネットワークセキュリティに関する意識が低すぎたんだ。でももう違うんだから、みんながんばっていくしかないし、雇用側もそれらの教育や訓練の支援をすべきだ。
4番目の問題はOPC-Fのミスリードもあって、例えばWinXP SP2のリリースはOPCのセキュリティを見直す良い機会であったはずなのに、いきなりOPCを使いたければWindows Firewallを殺せというある意味斜め上にすごいホワイトペーパーを出してみたりしてくれる。本来は、最低限あけておく必要があるポートと、それをプラントフロアのネットワークだけにととどめるような設定を例示しておくべきだったのに、それすらしなかった。ある程度わかっていた部分もあるはずであり、OPC-Fとして今まで出来たことも多かったんじゃないかと思う。
結局、提供側も、使用者側も、仕様策定者もあまり意識できなかったところで、ネットワーク特にインターネットが普及した為に、それに対する対策と対応が完全に後手に回ってしまい、もうどうしようもなくなっている感じもする。
ではどうするかだが、技術的にはDCOMベースの今のOPCを捨てて、さっさとOPC-UAに行きましょうと言うことになる。ただし、大事なのはOPC-UAは現状のネットワークセキュリティの枠組みを使用できるようになるけど、結局その実装、設定というのは人間がやるものなのであり、OPCに関わる人間がそれへの意識と知識、技術を持たなければ今まで何ら変わらないものが出来あがってしまう。
この際良い機会だから、今年のDevConのテーマはOPCにおけるネットワークセキュリティ技術に関するセッションで構成してみてはどうだろう。
コメント