Japan Computer Emergency Response Team Coordination Center

電子署名者 : Japan Computer Emergency Response Team Coordination Center
DN : c=JP, st=Tokyo, l=Chiyoda-ku, email=office@jpcert.or.jp, o=Japan
Computer Emergency Response Team Coordination Center, cn=Japan
Computer Emergency Response Team Coordination Center
日付 : 2011.02.18 15:48:19 +09'00'

OPC UAとUA Securityのご紹介
制御システムセキュリティカンファレンス２０１１
2011.2.10
コクヨホール

日本OPC協議会
発表者：
藤井 稔久

目次
OPC協議会について
UA仕様についてUAセキュリティについて参考情報 : UAシステムが想定する脅威と対策

日本OPC協議会

2OPC Foundation / OPC協議会
国際業界標準化団体
加入会社 392社(エンドユーザ 60社)
※2010/10/8現在
3,500を超えるOPC製品取り扱い会社 = 22,000を 超えるOPC製品
数百万規模のインストールベース

OPCのビジョンは、マルチベンダー、マルチプラットフォームにおけるセキュアで高信頼な相互運用環境を提供すること
データソースから基幹業務系における情報の垂直統合
異なるベンダーの異なるネットワーク間における情報の水平統合
単なるデータとしてではなく、情報として…….

高信頼でセキュアな相互運用性は必須要件(オプションではない)
統合オープンプラットフォームアーキテクチャにより、各種のオープンな標準(国際標準、業界標準など)の連携を実現

日本OPC協議会
会員数：40社

全体会議（総会)(2010年9月現在)

監事

代表幹事
9社で幹事会を構成

日本OPC協議会

幹事会

事務局

企画部会

普及部会

技術部会

ﾕｰｻﾞ交流部会•将来ビジョン立案•他団体連携•総務事項•広報、展博
•製品普及•協議会ｲﾝﾌﾗ整備•新仕様策定•技術教育/セミナー•認証・インオペ推進•ﾕｰｻﾞ交流会運営•ﾕｰｻﾞﾌｨｰﾄﾞﾊﾞｯｸまとめ•ﾕｰｻﾞﾒﾘｯﾄまとめ3

UA仕様について

Classic OPC ： プロセスデータ交換 I/FOPC⇒ ベンダや機器に依存することなくデータ交換を行なうClient / Server システムのための標準インタフェースです。
課題


多数のベンダー製品
カスタムメイドのソリューション
プロプラエタリィな技術
1対1結合による統合
限られたリアルタイム情報
保守の悪夢
散逸した責任解決策
 OPC！

Application X

...

PLC

DCS

Application Y

Controller

Application X

Application Y

OPCクライアント

OPCクライアント

COM/DCOM

日本OPC協議会

OPCサーバ

OPCサーバ

PLC

DCS

OPCサーバController

5OPC UA ： 製造情報データ連携 I/F
OPC UA ：業界標準の相互運用性を提供⇒ interOperability, Productivity & Collaboration
ERP, SAP … 経営情報システム （本社・社外)
OPC Unified Architecture

製造、生産、保守 (工場管理)
OPC Unified Architecture

HMI

日本OPC協議会

SCADA

OPC
PC ベース制御
OPC
工業用ネットワーク

データ収集

OPC

PLC
DCS

OPC

高度制御

MES

バッチ??.......??
6

OPC スケーラビリティ

OPC.NET 3.0

Mainframe

OPC
ClassicServer
Cluster
ServerDesktop
PC
Portables

Controllers

OPC
UA

Embedded
Systems
日本OPC協議会

7

特徴：UA (Unified Architecture) とは？
抽象化されたサービス

型定義
オブジェクトモデル

データモデル
既存OPC(DA, HDA,A&E,,)

プロトコル
非依存
日本OPC協議会

SOA
モデル

OPC
UA
通信モデル

プラットフォーム
非依存Intranet/
Internet
アクセス8

オブジェクトモデル&アドレススペース
UA アドレススペース

UA オブジェクトモデル
OPC DA and HDA

OPC Commands

OPC UA Object
Variables
___
___
___

Methods
___()
___()
___()
EventsReference

OPC A&E
日本OPC協議会

9スタック プロファイル
SecurityをBuilt-inした3種類のスタックプロファイル：
XML Web Service: ITシステムとの親和性⇒ ERP / ビジネスApp
Native Binary: 高速通信⇒組み込み / PCベース制御 / SCADA
Native with SOAP/HTTP : MES / ERPXML Web Services

UA XMLWS Secure Conversation

日本OPC協議会

NativeWith SOAP/HTTP

NativeBinary

UA Binary
UA Secure Conversation

SOAP 1.2

UA TCP

HTTP/HTTPSTCP/IP
10

インタフェース レイヤ

Vendor Information Model
Information Model Specifications
DA

A&E

HDA

OPC UA Base Services

日本OPC協議会

CMDs

FDI, ADI, PLCopen
OPC Information Model
All Necessary Services11活動中の協業プロジェクト

EDDL + FDT = FDI
ADI
PLCopenInformation Model Specifications

日本OPC協議会

12検討中の協業プロジェクト

Building Automation
OpenO&M
Smart GridMTConnect
ISA-95
Information Model Specifications
ISA-88

日本OPC協議会

13

UA Securityについて

UA Security
UAセキュリティ：仕様書(12部)のコア仕様として定義
 Part.1--- Part.2
 Part.3
 Part.4
 Part.5
 Part.6
 Part.7--- Part.8
 Part.9 Part.10
 Part.11--- Part.12
日本OPC協議会:Concepts & Overview//概要:Security Model:Address Space Model:Services:Information Model:Service Mappings:Profiles//コア仕様
// ..
// ..
// ..
// ..
// ..

:Data Access:Alarms and Conditions:Programs:Historical Access//OPC独自情報モデル
// ..
// ..
// ..

:Discovery15

- UA Security : 目的・脅威・対策Part.2：UAに求められるクライアント/サーバシステムのSecurityアセスメント結果
Threat(s)・Message Flooding
・Eavesdropping (盗聴)・Message Spoofing(ﾒｯｾｰｼﾞ捏造)
・Message Alteration(ﾒｯｾｰｼﾞ改竄)
・Message Replay
・Malformed Message
・Server Profiling・Session Hijacking
・。。。

Objective(s)Auhtentication
Authorization
Confidentiality
Integrity
Auditability
Availability

詳細は後述の参考情報を参照
日本OPC協議会

16

- UA Security : アプリケーション
Secure アプリケーション
安全なアーキテクチャを採用し、⇒安全メカニズムをビルトイン

OPC UA Client
アプリケーション層• ユーザ 認証

アプリケーション層
Session• ユーザ 権限の付与• ユーザ 認証
• ユーザ 権限の付与

コミュニケーション層

コミュニケーション層• アプリケーション認証• メッセージの完全性

OPC UA Server• アプリケーション認証
Secure Channel• メッセージの機密性• メッセージの完全性• メッセージの機密性

トランスポート層

日本OPC協議会

17

- UA Security :プロファイル（Part.7)
Security モード
None
Sign
SignAndEncrypt– セキュリティなし– メッセージに署名は付けるが、暗号化はしない。
–メッセージに署名は付けかつ暗号化する。

Security ポリシー
Basic128Rsa15
Basic256
None– 最低限のセキュリティ(⇔高速応答性が必要な場合)– 推奨セキュリティ– 推奨できない⇒ Security要件に応じて組合せをプロファイルに定義し、使い分けます。

日本OPC協議会

18

- UA Security: サービス（Part.4)
セッション
UAアプリケーション層で実装
Client/Server間のハイレベルな論理的接続機能を提供
ユーザの認証・認可(アクセス制御)によりClientのServerアクセスを制限
セッションの確立にはSecureチャネルの開設が必要
Secureチャネルが切断しても、セッションは維持したままでの再接続が可能

Secureチャネル
UAコミュニケーション層(通信スタック)で実装
Client/Server間のローレベルな論理的接続機能を提供
アプリケーション認証のための証明書を提供
送信メッセージを暗号化するなど、Sercureなメッセージ送信を可能に！
受信メッセージの署名による改ざん検査(Verify)など、Sercureなメッセージ受信を可能に！
Secureチャネルを維持したままでのトランスポート層の再接続が可能
日本OPC協議会

19

- UA Security: Secureチャネル

OpenSecureChannelによるセッション確立時は非対称方式で鍵共有を確立。
その後のメッセージ交換はOpenSecureChannelで交換した乱数（nonce）から派生した鍵を使用
日本OPC協議会

20

- UA Security: 監査
UA
ClientAudit Entry ID : Z
Client A Audit InfoA
UA
ServerUA
ClientB

UA
ServerUA
ClientUA
Server

日本OPC協議会

DAudit Entry ID : Y
Client Name : A
Client Audit Entry ID : Z
Client B Audit Info

CAudit Entry ID : X
Client Name : B
Client Audit Entry ID : Y
Client C Audit Info
Audit Entry ID : W
Client Name : C
Client Audit Entry ID : X
Server D Audit Info21

- UA Security : まとめ①UAセキュリティは特殊なものではありません。
⇒ITの世界で標準的に使用されているセキュリティ対策を使用します。
②UAセキュリティのための特別な実装は不要です。
⇒スタックに実装されている機能を利用することによりその恩恵を簡単に享受することができます。

日本OPC協議会

22参考情報：UA システムが想定する脅威と対策

- UA Security : 目的
Authentication （認証）なりすまし などへの対策。

対象が本当に正しいものだと証明する。

UAの対策
Application Authentication (クライアントとサーバーのアプリケーション)の識
別に http://tools.ietf.org/html/rfc3174 X.509 Certificatesを用いている。
User Authenticationに、使用プロトコルに応じて username/password,
X.509.v3 certificate, WS-SecurityToken を用いている。
User Identity TokenがDigital Certificateである場合、このトークンはchallengeresponse process（サーバーは乱数と署名アルゴリズムをCreateSessionの返信で渡し、クライアントはサーバ発行乱数に署名を施したものをActivateSession以降のサービス呼び出しの引数として渡す処理手段）で評価される。

日本OPC協議会

24

- UA Security : 目的
Authorization （権限）
正しい権限を持ったものにしか適切な処理は行わせない。
UAの対策
アプリケーション作成側の処理に委ねる。アプリケーション作成側はAuthentication情報を参照することが出来る。

日本OPC協議会

25

- UA Security : 目的
Confidentiality （信頼性）
盗聴 などへの対策。

UAの対策
暗号化
非対称鍵暗号（asymmetric encription 公開鍵で暗号化して秘密鍵で複合化する。）を鍵共有(key agreement)に用いる。
対称鍵暗号（symmetric encription 暗号化と複合化に同じ鍵を使う。）を他のメッセージ交換に用いる。

制限
ネットワークやシステム構造のConfidentialityはCSMS(Cyber SecurityManagement System)に依存する。
鍵の管理には公開鍵基盤（Public Key Infrastructure 利用者の身元について「信頼できる第三者」が審査を行い、保証を実現する仕組み)に依存する。

日本OPC協議会

26

- UA Security : 目的
Integrity （完全性）
改ざん などへの対策。

UAの対策
署名
非対称署名（asymmetric signature）をSecure Channel確立時の鍵共有（keyagreement）に用いる。
対称署名（symmetric signature）を他のメッセージ交換に用いる。

制限
ネットワークやシステム構造のIntegrityはCSMS(Cyber Security
Management System)に依存する。
鍵の管理には公開鍵基盤（Public Key Infrastructure 利用者の身元について「信頼できる第三者」が審査を行い、保証を実現する仕組み)に依存する。

日本OPC協議会

27

- UA Security : 目的
Auditability （監視）セキュリティ状態が有効であるかを確認する為にシステムの運用状況を確認する。

UAの対策
通信スタックでは標準的な処理に対するAuditイベントを発行している。
Auditイベントの追加、Auditイベントを受信してどのよう処理するかはアプリケーション作成側の処理に委ねる。

日本OPC協議会

28

- UA Security : 目的
Availability （可用性）メッセージ洪水 などへの対策。

UAの対策
メッセージが認証される前の処理を最小化して、Message Floodingの影響を少なくする。
GetEndpointsとOpenSecureChannelサービスが唯一のユーザ認識される前にサーバが処理するもので、それ以外は認証されないメッセージは破棄。
GetEndpointsは静的情報を返すだけなのでサーバー側に負荷はない。
OpenSecureChannelについては1)不正な情報を受けたら意図的に処理を遅らせてアラート通知する、2)サーバ最大許容チャネル数を超過した接続には署名や暗号化処理を行わずにエラーを返す という2つの仕組みでMessage Floodingに対応。

Authenticationにより、適正ユーザがMessage Floodingに利用されるリスクを低める。
Auditingにより、異常状況を認識させる。
制限
システムとネットワークプロトコルのレベルでのMessage FloodingについてはCSMS(Cyber Security Management System)に依存する。
日本OPC協議会

29

- UA Security : 脅威
Message Flooding
クライアントがセッションを持っていないケース：UAのセッション確立能力を阻害したり、サーバー内にある既存セッションを終了させる。
クライアントがセッションを持っているケース：仕様外のメッセージを沢山送ってサーバリソースを枯渇させる。
通信を妨害してサービスを正常に実行させない。
阻害される目的 ： Availability
UAの対策
Availability に記載した対策と同じ。

日本OPC協議会

30

- UA Security : 脅威
Eavesdropping
盗聴阻害される目的 ： Confidentiality、 間接的には他全てに影響し得る
UAの対策
暗号化

Message Spoofing
メッセージの捏造をしてクライアントやサーバに送る阻害される目的 ： Integrity、 Authorization
UAの対策メッセージ署名
SessionID, SecureChannelID, Timestamp, シーケンス番号, Request ID
をメッセージに持ち正当性を評価している
日本OPC協議会

31

- UA Security : 脅威
Message Alteration
メッセージ改ざん阻害される目的 ： Integrity、 Authorization
UAの対策
メッセージが変更されている場合は署名データの検証により変更を認識し、そのメッセージを破棄

Message Reply
メッセージを別のタイミングで再送して誤った動き（不必要な時にバルブを開くなど）を引き起こす。
阻害される目的 ： Authorization
UAの対策
Message Spoofingと同じ。
同じメッセージを送ってもシーケンス番号が正当性を失っている。
データを捏造して同じメッセージを送っても署名データで検証される。
日本OPC協議会

32

- UA Security : 脅威
Malformed Message
不正な構造のメッセージを送り想定外の処理を行わせる。サーバクラッシュなどに繋げる。
阻害される目的 ： Integrity、 Availability
UAの対策
UAのサービス呼び出しでは、メッセージが正しい様式と適正範囲内のパラメータ値になっているかをチェックしている

Server Profiling
相手に正しい/不正なメッセージを送り、その反応などからサーバーの情報を推定する。乗っ取りなどに繋げる。
阻害される目的 ： 全て
UAの対策
識別されていないクライアントに提供する情報は最小限にしている。
GetEndpointsの戻り値のみがその対象。他はクライアント識別済み。
日本OPC協議会

33

- UA Security : 脅威
Server Hijacking
接続中セッションの情報を取得・類推してセッションを乗っ取り、任意のメッセージを送る。
阻害される目的 ： 全て
UAの対策
各セッションにセキュリティ情報を割当てている。
セッションのハイジャックには最初にそのセキュリティ情報に準拠する必要がある。

Rogue Server
偽UAサーバーをセットアップして情報入手する。
阻害される目的 ： Integrity以外の全てUAの対策
サーバのApplication Instance Certificationを用いる。
偽サーバーが同じCertificationを持っていたとしても、暗号化技術のPrivate Keyが複製できない為に、正しいPublic Keyで守られたメッセージを利用できない。
日本OPC協議会

34

- UA Security : 脅威
Compromising User Credentials
ユーザ情報（ユーザ名、パスワード、認証、キーなど）を取得して悪意にサーバにアクセスする。
阻害される目的 ： Authorization, Confidentiality
UAの対策
ユーザ情報の暗号化
制限
パスワード類推やソーシャルエンジニアリングに対してはCSMS(CyberSecurity Management System)に依存する。

日本OPC協議会

35

Questions?
日本OPC協議会

日本OPC協議会

36