HTTPS 與API 呼叫如何透過單向資料二極體運作

現代營運技術（OT）環境越來越需要將資料傳送至企業 IT 系統、雲端平台、安全監控系統及分析應用程式。這些資料可能包含透過 HTTP、HTTPS 或 API 傳輸的遙測資料、日誌、警示、營運指標及應用程式資料。

但這裡存在一個根本性的網路挑戰：HTTP 和 HTTPS 傳統上是為雙向通訊而設計的，而資料二極體的設計則僅允許資料單向流動。

那麼，組織該如何在確保安全的前提下使用基於 HTTPS 和API 的整合方案，同時避免為受保護的 OT 網路建立回傳路徑呢？

答案在於理解應用層資料傳輸與網路層通訊之間的差異。

MetaDefender™Optical Diode 與 MetaDefender™Optical Diode Fend 採用硬體強制執行的單向資料流及具備協定感知能力的傳輸機制，使資料能夠跨越安全邊界，而無需建立傳統的雙向網路連線。

HTTPS 是在 TLS 協定上運作的 HTTP。在傳統的 HTTPS 連線中，客戶端會向伺服器發送請求，而伺服器則會回傳回應。

在網路層面上，這需要雙向通訊。TCP 本身需要進行握手程序，並在雙向之間持續傳輸控制流量。因此，傳統的 HTTPS 連線無法像將數據二極體視為一般防火牆或路由器那樣，直接透過實體單向數據二極體進行路由。

這由此產生了一個重要的區別：

資料二極體並不會將正常的「雙向」HTTPS 連線轉變為「單向」。相反地，它透過打破傳統的端對端通訊模式，來實現基於 HTTPS 的資料傳輸。

這種協議中斷是資料二極體架構的一項基本特徵。該架構並非將可路由的網路連線從一個安全區域延伸至另一個安全區域，而是將目標資料傳輸過邊界，並在目的地端重建適當的通訊。

讓我們來探討一個簡單的 OT 到 IT 應用案例。

某工業應用程式產生了一組溫度讀數，並需要透過 HTTPS 將其傳送至雲端分析平台：API ：OT 應用程式 → HTTPS/API → 雲端平台

在傳統網路中，OT 應用程式會與目的地建立網路連線，發送 HTTP 請求，並接收 HTTP 回應。

若採用資料二極體，其架構則有所不同。

從概念上來看，典型的單向實現方式可視為：OT 應用程式 → 來源端連接器／代理伺服器 → 單向光傳輸 → 目的地端連接器 → IT／雲端應用程式

關鍵在於，這兩個網路之間並未建立傳統的雙向連線。

來源端的元件會從 OT 環境接收資料。接著，資料會透過硬體強制實施的單向邊界進行傳輸。在目的地端，接收元件會重建資料，或將資料轉發至預定的應用程式。

此方法讓組織能在消除回傳網路路徑的同時，保留應用程式資料傳輸的語義。

例如：

1. OT 系統會產生遙測資料。
2. 源端服務會接收遙測資料。
3. 相關資料載荷已準備就緒，可供單向傳輸。
4. 有效載荷跨越了光學隔離邊界。
5. 目的地端服務會接收傳輸過來的資料。
6. 目標端將資料傳送至企業、監控、分析或雲端應用程式。

儘管有用的資訊可以在這些網路之間流通，但這些網路仍保持分離狀態。

這與設定防火牆規則以允許兩個網路之間進行 HTTPS 通訊在根本上有所不同。當政策允許時，防火牆可以允許雙向的 TCP 通訊；而資料二極體則是專門設計用來在硬體層級上阻止這種回傳路徑。

是的， MetaDefender 、 Optical Diode 以及 Fend 50 系列機型除了支援工業與 IT 通訊協定外，也支援 HTTP 和 HTTPS。

為此，二極體的每一側都必須具備必要的憑證和金鑰，才能分別與來源端及目的地端建立獨立的 TLS 連線。

REST API 通常透過 HTTP 或 HTTPS 實現，且越來越常被用於將 OT 資料與以下系統整合：

• Cloud 分析平台
• SIEM 與資安監控平台
• 企業儀表板
• 資料歷史學家
• 預測性維護的應用
• 集中式日誌記錄系統
• 票務與工作流程系統

傳統的 RESTAPI 互動通常如下所示：客戶端 → HTTP/S POST 或 PUT →API 伺服器 → HTTP 回應

在這些情況下，應用層回應屬於正常的應用程式通訊流程的一部分。客戶端預期會收到 HTTP 200 狀態碼，並可能在回應正文中收到自訂訊息。

在單向架構中，二極體的輸入端可代理此回應，彷彿該回應來自最終目的地一般。若已知且可重複產生成功 PUT/POST 請求的自訂回應正文，亦可進行代理。

舉例來說，一個 OT 監控系統可能需要傳送：

POST /api/v1/telemetry

其有效載荷包含：

{"temperature":72,"pressure":101.3,"status":"normal"}

此架構的目標並非在 OT 與 IT 之間建立永久性的雙向API 連線。相反地，資料會透過二極體向外傳輸，並傳送至目的地端的應用程式。

二極體的輸入端在收到 POST 請求後，會先向客戶端傳回 200 OK 狀態碼，接著將有效載荷透過光隔離傳送，然後連線至目標伺服器，並透過另一則 POST /api/v1/telemetry 請求傳送該訊息，

這使得單向架構對於遙測、事件、日誌和監控 API 特別有用，因為這些 API 的主要業務需求在於發佈外傳資料。

雖然加密有助於確保資料在傳輸過程中的機密性，但並不能防止惡意資料的發送或接收。資料二極體則解決了另一個問題：通訊方向。

若企業或雲端環境遭到入侵，根據網路架構與安全控制措施的不同，傳統的雙向連線可能會為攻擊者提供通往 OT 環境的途徑。

透過硬體強制實施的資料二極體可消除該回傳路徑。因此，OT 資料雖可離開受保護的網路，卻不會為外部系統建立可路由的路徑，使其將流量傳回該網路。

對於關鍵基礎設施而言，這種區別可能至關重要。資料二極體用於將運作資訊傳輸至監控系統與企業系統，同時維持實體網路的分離。

想強化您的 OT 網路安全嗎？

深入了解OPSWAT旗下的MetaDefender 、Optical Diode 及 Fend 解決方案，如何實現跨關鍵網路邊界的安全、硬體級保障的單向資料傳輸。歡迎與我們的專家聯繫，討論您的營運技術（OT）架構及資料傳輸需求。

在設計 OT 至 IT 架構時，應從實際的通訊需求著手，而非從應用協定開始，這一點至關重要。

請提出三個問題：

1. 哪些資料需要從 OT 環境傳送出去？

請識別需要傳送至 IT、雲端或監控系統的遙測資料、日誌、警示、檔案、處理資料或其他資訊。

2. 目的地是否真的需要將資料傳回？

許多整合方案常被描述為需要「連通性」，但其實其底層的業務需求僅是將資訊發佈至外部。若回傳的資料僅是收件確認或成功回報，單向架構即可代理這些回應，並省去不必要的網路路徑。

3. 通訊協定邊界應設於何處？

諸如 TCP、HTTPS 及 REST API 等通訊協定，皆預設了特定的雙向行為。因此，資料二極體架構必須明確定義：連線在何處終止、資料如何跨越邊界進行傳輸，以及目的地端的應用程式如何接收這些資料。

這種「應用程式的感知」方法，有助於企業實現 OT 連通性的現代化，同時無需將網路隔離與應用程式整合視為相互排斥的需求。

1. 資料二極體能否傳輸 HTTPS 流量？
   是的。MetaDefender Optical Diode 以及MetaDefender Fend 支援基於 HTTP/HTTPS 的資料傳輸，但 HTTPS 無法在物理上單向的邊界上作為傳統的雙向端對端連線運作。資料二極體會在二極體的每一側終止現有連線，並於該側建立獨立的加密連線，因此必須提供相應的金鑰和憑證以處理這些連線。
2. API 能否透過資料二極體運作？
   是的。API 基於的資料傳輸，若其架構是圍繞 PUT/POST 單向通訊設計的，便能透過資料二極體運作。關鍵在於避免要求資料二極體兩端建立雙向的API 連線，而是改用來源端與目的地端的機制來傳輸所需的應用程式資料。
3. 資料二極體能取代 HTTPS 加密嗎？
   不能。它們解決的是不同的安全問題。HTTPS 為應用程式流量提供加密與驗證，而資料二極體則透過硬體強制控制網路通訊的方向。
4. 防火牆與資料二極體有何區別？
   防火牆透過軟體定義的安全規則來控制流量，並可允許雙向通訊。資料二極體則透過硬體層面強制實施單向通訊，其設計上會阻止回程網路路徑。
5. 為何要在 OT 與 IT 之間的通訊中使用資料二極體？
   資料二極體可讓組織在與企業或雲端系統保持物理隔離的同時，仍能與這些系統共享營運資料、遙測資料、日誌及其他資訊。這能降低因雙向連通性所衍生的攻擊面。
6. 什麼是MetaDefender Optical Diode？
   MetaDefender Optical Diode 是一款基於光學技術、透過硬體強制實現的資料二極體，旨在提供網路間的安全單向資料傳輸。它除了支援 HTTP 和 HTTPS 等 IT 協定外，亦支援其他協定及應用場景。
7. 什麼是MetaDefender Optical Diode Fend？
   MetaDefender Optical Diode Fend 是一款專為在 IT 與 OT 環境間進行安全單向資料傳輸而設計的資料二極體解決方案。根據型號與部署方式的不同，它支援 IT 與工業通訊協定，並能協助將隔離的 OT 網路與需要存取營運資料的系統連接起來。