第十四章OPC協(xié)議安全第十四章OPC協(xié)議安全14.1OPC概述14.2

OPCUA14.3

OPC的通信結(jié)構(gòu)14.4

OPC協(xié)議的安全風(fēng)險與防護(hù)策略O(shè)PC概述14.1PARTONE010203OPC的定義OPC的發(fā)展背景OPC的發(fā)展歷程CONTENTS目錄14.1.1OPC的定義全稱：OLEforProcessControl（用于過程控制的OLE）技術(shù)基礎(chǔ)：基于微軟的OLE/COM/DCOM技術(shù)，實現(xiàn)工業(yè)設(shè)備間的標(biāo)準(zhǔn)化數(shù)據(jù)交換。核心作用：

（1）提供統(tǒng)一的通信接口，解決不同廠商設(shè)備間的協(xié)議不兼容問題

（2）實現(xiàn)“即插即用”的工業(yè)自動化系統(tǒng)集成。OLE（對象連接與嵌入）：微軟技術(shù)，允許應(yīng)用程序共享數(shù)據(jù)和功能（如Excel嵌入Word）。COM/DCOM（分布式組件對象模型）：COM：本地進(jìn)程間通信。DCOM：跨網(wǎng)絡(luò)的分布式通信（經(jīng)典OPC的核心依賴）。C/S架構(gòu)：OPCServer：由設(shè)備廠商提供，封裝硬件數(shù)據(jù)。OPCClient：第三方軟件通過標(biāo)準(zhǔn)接口訪問數(shù)據(jù)。14.1.1OPC的定義14.1.2OPC的發(fā)展背景工業(yè)自動化早期的通信困境協(xié)議碎片化：每個設(shè)備廠商使用私有協(xié)議系統(tǒng)集成需為每類設(shè)備單獨開發(fā)驅(qū)動，成本高昂數(shù)據(jù)孤島問題：PLC、傳感器、SCADA系統(tǒng)間無法直接通信數(shù)據(jù)需人工導(dǎo)出/導(dǎo)入，實時性差維護(hù)復(fù)雜度：設(shè)備升級導(dǎo)致接口變更，需重新開發(fā)適配層

14.1.2OPC的發(fā)展背景需求方核心訴求設(shè)備制造商降低驅(qū)動開發(fā)成本，擴(kuò)大設(shè)備兼容性系統(tǒng)集成商減少定制開發(fā)，縮短項目周期終端用戶實現(xiàn)多品牌設(shè)備統(tǒng)一監(jiān)控和維護(hù)工業(yè)軟件開發(fā)商避免為每個硬件重復(fù)開發(fā)數(shù)據(jù)接口行業(yè)對標(biāo)準(zhǔn)化通信的迫切需求

行業(yè)對標(biāo)準(zhǔn)化通信的迫切需求

技術(shù)條件成熟（1990年代）：微軟技術(shù)普及WindowsNT成為工業(yè)主流操作系統(tǒng)COM/DCOM技術(shù)為跨進(jìn)程通信提供基礎(chǔ)工業(yè)網(wǎng)絡(luò)發(fā)展以太網(wǎng)開始應(yīng)用于工業(yè)現(xiàn)場（替代RS-232/485）為標(biāo)準(zhǔn)化通信提供物理層支持14.1.2OPC的發(fā)展背景OPC的誕生契機(jī)：14.1.2OPC的發(fā)展背景1995年：由Fisher-Rosemount、西門子等多家工業(yè)巨頭聯(lián)合發(fā)起核心突破：將硬件驅(qū)動封裝為標(biāo)準(zhǔn)化的OPCServer定義統(tǒng)一數(shù)據(jù)接口規(guī)范（如IOPCServer接口）經(jīng)典OPC階段（1996-2008）

接口類型功能典型應(yīng)用場景OPCDA(DataAccess)實時數(shù)據(jù)讀寫（如溫度、壓力）設(shè)備監(jiān)控OPCAE(Alarms&Events)報警和事件管理故障診斷OPCHDA(HistoricalData)訪問歷史數(shù)據(jù)庫生產(chǎn)報表生成OPCDX(DataExchange)服務(wù)器間數(shù)據(jù)交換多廠區(qū)數(shù)據(jù)整合技術(shù)架構(gòu)：基于WindowsCOM/DCOM的二進(jìn)制協(xié)議核心組件：OPCServer：廠商提供的設(shè)備驅(qū)動封裝OPCClient：SCADA/HMI等上層系統(tǒng)主要接口標(biāo)準(zhǔn)：

14.1.3OSI/RM模型的優(yōu)缺點局限性平臺鎖定：僅支持Windows系統(tǒng)安全隱患：DCOM使用動態(tài)端口（135+隨機(jī)端口），防火墻難以防護(hù)配置復(fù)雜：需手動配置DCOM權(quán)限（企業(yè)域環(huán)境下尤為困難）14.1.3OPCUA革命（2008至今）跨平臺架構(gòu)：脫離COM/DCOM，原生支持Linux/嵌入式系統(tǒng)（如樹莓派）傳輸協(xié)議可選：TCP/HTTPS/MQTT安全體系：端到端加密（AES-256）X.509證書身份驗證審計日志功能信息建模：統(tǒng)一地址空間（整合DA/AE/HDA功能）支持復(fù)雜對象建模（如定義"生產(chǎn)線"對象包含設(shè)備、工藝參數(shù)等子節(jié)點）對比總結(jié)特性經(jīng)典OPCOPCUA技術(shù)基礎(chǔ)COM/DCOM（Windows依賴）跨平臺（TCP/IP、HTTPS等）安全性弱（動態(tài)端口、明文傳輸）強(qiáng)（加密、數(shù)字證書、審計跟蹤）擴(kuò)展性有限高（支持新協(xié)議、復(fù)雜數(shù)據(jù)建模）適用場景傳統(tǒng)工業(yè)控制系統(tǒng)工業(yè)互聯(lián)網(wǎng)、物聯(lián)網(wǎng)、云平臺

對比總結(jié)

OPCUA14.2PARTTWO010203OPCUA的核心特點OPCUA的報文格式OPCUA擴(kuò)展CONTENTS目錄14.2.1OPCUA客戶端架構(gòu)14.2.1OPCUA服務(wù)器架構(gòu)14.2.1OPCUA的核心特點OPC統(tǒng)一架構(gòu)具有功能對等性、平臺獨立性、安全性、可擴(kuò)展性及綜合信息建模等特性。功能對等性：OPCUA不僅實現(xiàn)了經(jīng)典OPC的所有功能，還增加或增強(qiáng)了以下功能，以滿足不斷發(fā)展的工業(yè)自動化需求。發(fā)現(xiàn)可以在本地PC和/或網(wǎng)絡(luò)上查找可用的OPC服務(wù)器地址空間所有數(shù)據(jù)都是分層表示的，類似于文件和文件夾的組織方式，允許OPC客戶端發(fā)現(xiàn)、利用簡單和復(fù)雜的數(shù)據(jù)結(jié)構(gòu)按需訪問基于訪問權(quán)限讀取和寫入數(shù)據(jù)/信息訂閱監(jiān)視數(shù)據(jù)/信息，并且當(dāng)值變化超出客戶端的設(shè)定時報告異常事件基于客戶端的設(shè)定通知重要信息方法客戶端可以基于在服務(wù)器上定義的方法來執(zhí)行程序等；集成通過COM/ProxyWrappers可以實現(xiàn)OPCUA產(chǎn)品和經(jīng)典OPC產(chǎn)品之間的集成14.2.1OPCUA的核心特點OPCUA是跨平臺的,不依賴于硬件或者軟件操作系統(tǒng);可以運(yùn)行在PC、PLC、云服務(wù)器、微控制器等不同的硬件下,支持Windows、Linux、AppleOS、Android等操作系統(tǒng);平臺獨立性O(shè)PCUA支持會話加密、信息簽名等安全技術(shù),每個UA的客戶端和服務(wù)器都要通過OpenSSL證書標(biāo)識,具有用戶身份驗證,審計跟蹤等安全功能。安全性可擴(kuò)展性：OPCUA的多層架構(gòu)提供了一個“面向未來”的框架。諸如新的傳輸協(xié)議、安全算法、編碼標(biāo)準(zhǔn)或應(yīng)用服務(wù)等創(chuàng)新技術(shù)和方法可以并入OPCUA，同時保持現(xiàn)有產(chǎn)品的兼容性；綜合信息建模：OPCUA信息建?？蚣芸梢詫?shù)據(jù)轉(zhuǎn)換為信息。通過完全的面向?qū)ο蠹夹g(shù)，即使非常復(fù)雜多層次結(jié)構(gòu)也可以被建模和擴(kuò)展。14.2.1OPCUA的核心特點14.2.2OPCUA的報文格式OPCUA的報文格式通用的OPCUA的報文格式包含一個消息頭和消息體。消息頭部分報文包含的字段類型、長度及功能。其中消息類型部分共分四類：HEL：表示消息體為Hello報文ACK：表示消息體為Acknowledge報文ERR：表示消息體為Error報文RHE：表示消息體為ReverseHello報文

字段消息類型保留段消息大小長度3字節(jié)1字節(jié)4字節(jié)用途標(biāo)識報文類型如果消息類型是OPCUA鏈接協(xié)議支持的值之一，則設(shè)置為“F”的ACSII碼消息頭+消息體的長度，單位為字節(jié)消息頭包含了關(guān)于整個消息的一些基本信息，這些信息對于消息的路由、處理以及安全驗證都是至關(guān)重要的。序列號用于確保消息的順序和唯一性。在OPCUA中，每個會話的每條消息都會有一個唯一的序列號。消息類型指示這是一個什么類型的消息。認(rèn)證令牌用于安全通信的令牌。這個令牌可能被用于驗證發(fā)送者的身份或權(quán)限。消息大小Message的長度，以字節(jié)為單位。該值包括MessageType的8個字節(jié)時間戳可選字段，表示消息被發(fā)送或創(chuàng)建的時間。消息體包含了消息的實際內(nèi)容，它取決于消息的類型。對于請求消息，消息體可能包含服務(wù)ID、節(jié)點ID、方法名以及參數(shù)列表等；對于響應(yīng)消息，它可能包含狀態(tài)碼、診斷信息以及響應(yīng)數(shù)據(jù)。14.2.2OPCUA的報文格式OPCUASecureConversation報文格式14.2.2OPCUA的報文格式字段消息頭安全頭序列頭載荷安全腳長度12字節(jié)不定8字節(jié)不定不定用途控制和描述報文包含安全相關(guān)的信息。根據(jù)對稱、不對稱安全算法有不同長度包括序列號和請求ID根據(jù)安全頭中定義的安全策略，可能被加密和/或簽名。（可選）如果報文被簽名，則包含簽名。OPCUASecureConversation是OPCUA協(xié)議的一個安全通信模式，它提供了一種安全的客戶端與服務(wù)器之間的一個加密和簽名的通信通道，確保OPCUA客戶端和服務(wù)器之間數(shù)據(jù)的安全傳輸。14.2.2OPCUA的信息模型OPCUA建模其實就是建立節(jié)點以及節(jié)點間的引用。在OPCUA中，最重要的節(jié)點類別是對象，變量和方法。對象節(jié)點：對象節(jié)點用于構(gòu)成地址空間，不包含數(shù)據(jù)，使用變量為對象公開數(shù)值，對象節(jié)點可用于分組管理對象，變量或方法（變量和方法總屬于一個對象）。變量節(jié)點：變量節(jié)點代表一個值，值的數(shù)據(jù)類型取決于變量，客戶端可以對值進(jìn)行讀寫和訂閱。方法節(jié)點：方法節(jié)點代表服務(wù)器中一個有客戶端調(diào)用并返回結(jié)果的方法，輸入?yún)?shù)和輸出結(jié)果以變量的形式作為方法節(jié)點的組成部分，客戶端指定輸入?yún)?shù)，調(diào)用后獲得輸出結(jié)果。14.2.2OPCUA的信息模型節(jié)點模型節(jié)點通用屬性14.2.3MQTTMQTT（MessageQueuingTelemetryTransport）是為物聯(lián)網(wǎng)設(shè)備和應(yīng)用程序設(shè)計的消息協(xié)議，采用發(fā)布與訂閱模型，具有輕量、高效、可靠，支持實時通訊等優(yōu)點。非常適合資源受限的環(huán)境。它通過其兩個組件來實現(xiàn)發(fā)布/訂閱模型：客戶端和代理14.2.3OPCUA擴(kuò)展OPC基金會在最新的OPCUA規(guī)范中提出的Pub-Sub模型允許使用MQTTbroker將數(shù)據(jù)變更推送給訂閱者。14.2.3OPCUA與MQTT的連接在工業(yè)場景中，MQTT擅長在分布式系統(tǒng)中發(fā)送信息，而OPCUA則側(cè)重于提供互操作性。通過將兩者結(jié)合，可以使用OPCUA對業(yè)務(wù)數(shù)據(jù)進(jìn)行抽象和聚合，而MQTT則可以利用其強(qiáng)大的連接能力，以分布式方式實現(xiàn)無縫數(shù)據(jù)交換。通過結(jié)合MQTT等此類通信協(xié)議，OPC協(xié)議即可更方便的應(yīng)用Internet中。OPCUA與MQTT的連接能夠?qū)崿F(xiàn)工業(yè)自動化系統(tǒng)和IoT設(shè)備之間的互操作性和集成，降低系統(tǒng)的復(fù)雜性和提高可維護(hù)性，提高系統(tǒng)的實時性和可靠性，具有良好的適應(yīng)性和可擴(kuò)展性。OPC的通信結(jié)構(gòu)14.3PARTTHREE010203OPC對象OPC的通訊結(jié)構(gòu)OPC的通訊過程CONTENTS目錄14.3.1OPC對象OPC標(biāo)準(zhǔn)規(guī)定的OPC對象有三類，OPCServer（服務(wù)器對象）、OPCGroup（組對象）和OPCItem（數(shù)據(jù)項對象）。OPCServer記錄了服務(wù)器的所有信息，一個服務(wù)器對應(yīng)一個OPCServer，即一種設(shè)備的驅(qū)動程序，同時，OPCServer作為OPCGroup對象的容器，可以有多個組對象。OPCServer對象接口描述IOPCCommon用于處理服務(wù)器基本信息。IOPCServer客戶程序管理服務(wù)器內(nèi)部OPC組對象，包括添加、刪除、查詢等IOPCBrowse用于瀏覽服務(wù)器地址空間的查詢IOPCItemIO使客戶程序可以之間讀寫數(shù)據(jù)IConnectionPointContainer用于實現(xiàn)與客戶端雙向通信OPCGroup對象提供了對服務(wù)器的數(shù)據(jù)進(jìn)行組織管理，組是應(yīng)用程序組織數(shù)據(jù)的一個單位，客戶端得到組對象的接口指針后便可訪問其提供的服務(wù)，包括讀寫OPCItem對象對應(yīng)的數(shù)據(jù)、配置OPC服務(wù)器提供數(shù)據(jù)變化的速率等。OPCGroup對象接口描述IOPCItemMgt管理Item對象。IOPCGroupStateMgtIOPCGroupStateMgt2管理Croup本身的一些屬性，主要是設(shè)置Group組織數(shù)據(jù)的方式。IOPCSyncIOIOPCSyncIO2實現(xiàn)數(shù)據(jù)同步訪問。IOPCAsyncIO2IOPCAsyncIO3實現(xiàn)數(shù)據(jù)異步訪問。IOPCItemDeadbandnMgtIOPCItemSamplingMgt對Item部分參數(shù)進(jìn)行管理。程序通過OPCGroup對象訪問OPCItem對象，OPCItem對象是讀寫數(shù)據(jù)的最小單位，Item對象不對外提供接口，一個數(shù)據(jù)項與一個具體的位號相連；OPC客戶對設(shè)備寄存器的操作都是通過數(shù)據(jù)項來完成的。OPCItem對象14.3.2OPC的通訊結(jié)構(gòu)OPC通信采用Client/Server的通信結(jié)構(gòu)，OPCServer由設(shè)備生產(chǎn)廠商提供，用于連接他們的PLC、現(xiàn)場總線設(shè)備、HMI/SCADA系統(tǒng)等，OPCClient通過OPC標(biāo)準(zhǔn)接口對各OPCServer管理的設(shè)備進(jìn)行操作，由客戶端發(fā)出數(shù)據(jù)請求，當(dāng)OPCServer接收到來自O(shè)PCClient的數(shù)據(jù)請求后會按照要求返回請求的數(shù)據(jù)。OPCServer與OPCClient的連接支持自動化接口和自定義接口兩種類型，如圖所示。其中，自動化接口是為基于腳本編程語言開發(fā)客戶端應(yīng)用而定義的標(biāo)準(zhǔn)接口，技術(shù)人員可以利用VB、Delphi等編程語言開發(fā)OPCClient應(yīng)用。自定義接口則是為C++等高級編程語言開發(fā)OPCClient應(yīng)用而定義的標(biāo)準(zhǔn)接口。14.3.2OPC的通訊結(jié)構(gòu)14.3.3建立連接客戶端創(chuàng)建socket之后，發(fā)送Hello報文，其中包括客戶端支持的buffer大小。服務(wù)器接收報文后返回Acknowledge報文完成buffer大小協(xié)商。協(xié)商好的buffer大小會上報給SecureChannel層，其中SendBufferSize字段指定在此連接上發(fā)送的MessageChunk的最大長度。14.3.3建立連接Hello/Acknowledge報文一般只能發(fā)送一次，若對端再一次接收到該報文會報錯并關(guān)閉socket。如果socket創(chuàng)建之后，服務(wù)器很長一段時間（可配，不超過2分鐘）內(nèi)沒有接收到Hello報文會主動關(guān)閉socket。14.3.3建立連接客戶端接收到Acknowledge報文后，緊接著會發(fā)送OpenSecureChannel請求報文，服務(wù)器若接受該channel會將該socket和一個SecureChannelId關(guān)聯(lián)，后續(xù)服務(wù)器發(fā)送應(yīng)答報文時會根據(jù)SecureChannelId決定使用哪個socket發(fā)送?？蛻舳私邮盏絆penSecureChannel應(yīng)答報文后也會做相同的操作。14.3.3斷開連接客戶端首先發(fā)送CloseSession請求報文準(zhǔn)備關(guān)閉連接，服務(wù)器收到后，會回復(fù)一個CloseSessionResponse報文。14.3.3斷開連接客戶端發(fā)送CloseSecureChannel請求報文主動關(guān)閉連接，服務(wù)器接收到該報文后釋放該channel相關(guān)的所有資源，但不會發(fā)送CloseSecureChannel應(yīng)答報文。OPC協(xié)議的安全風(fēng)險與防護(hù)策略14.4PARTFOUR0102OPC協(xié)議的安全風(fēng)險OPC協(xié)議的防護(hù)策略CONTENTS目錄14.4.1OPC協(xié)議的安全風(fēng)險最新版本的OPC

(OPC

UA)在其設(shè)計中已經(jīng)包括了安全性需求，但OPC“Classic”協(xié)議(OPC

DA,

OPC

HAD和OPC

A&E)

基于微軟的DCOM協(xié)議，DCOM協(xié)議是在網(wǎng)絡(luò)安全問題被廣泛認(rèn)識之前設(shè)計的。因此，這些協(xié)議給那些希望能確?？刂葡到y(tǒng)安全性和可靠性的工程師帶來了極大的挑戰(zhàn)。OPC協(xié)議現(xiàn)存的安全問題概況為以下三個方面：動態(tài)端口、協(xié)議缺陷、明文傳輸動態(tài)端口：在工業(yè)控制領(lǐng)域，OPCClassic依托于微軟的DCOM協(xié)議進(jìn)行通信。由于OPC通信采用不固定的端口號，這使得傳統(tǒng)的IT防火墻在保障其安全性方面幾乎無能為力。通過wireshark工具能夠清晰地看到，OPC通信端口呈現(xiàn)出極大的不確定性。針對端口使用狀況展開一系列統(tǒng)計后發(fā)現(xiàn)，端口的變化毫無規(guī)律可循，隨機(jī)不定。14.4.1動態(tài)端口在90年代，微軟操作系統(tǒng)占據(jù)市場主導(dǎo)，自動化供應(yīng)商在別無更好選擇的情況下采用了微軟推出的COM和DCOM技術(shù)，這導(dǎo)致服務(wù)器和客戶機(jī)必須在Windows系統(tǒng)下才能工作。DCOM協(xié)議在設(shè)計之初，網(wǎng)絡(luò)安全問題尚未得到廣泛重視，因而存在諸多安全漏洞，缺少有效的入侵檢測與防護(hù)措施，在認(rèn)證、鑒別與訪問控制機(jī)制方面也存在不足，這使得其極易遭受攻擊。黑客可能利用其漏洞篡改實時數(shù)據(jù)，導(dǎo)致生產(chǎn)流程失控，造成巨大的經(jīng)濟(jì)損失和安全事故。OPCDA協(xié)議在實際應(yīng)用中存在諸多缺陷和風(fēng)險，給工業(yè)生產(chǎn)帶來了嚴(yán)重的安全威脅。黑客可能利用其漏洞篡改實時數(shù)據(jù)，導(dǎo)致生產(chǎn)流程失控，造成巨大的經(jīng)濟(jì)損失和安全事故。14.4.1協(xié)議缺陷專用的工控通信協(xié)議或規(guī)約在設(shè)計之初一般只考慮通信的實時性和可用性，很少或根本沒有考慮安全性問題，缺乏強(qiáng)度足夠的認(rèn)證、加密或授權(quán)措施等，為保證數(shù)據(jù)傳輸?shù)膶崟r性，OPCClassic協(xié)議在多種類型的請求以及在多種程序的交互中多采用明文傳輸，易于被劫持和修改指令。14.4.1明文傳輸14.4.2OPC協(xié)議的防護(hù)策略常見的防護(hù)技術(shù)是設(shè)立不