把 OT 資料送往 IT，與允許 IT 主動連回 OT，是兩個不同的架構決定。前者可以支援集中監看、紀錄與分析；後者則新增一條由 IT 朝受保護 OT 資產移動的路徑。如果兩者綁在同一條雙向連線，單純讀取資料的需求，也可能連帶帶入回覆、查詢、錯誤處理或控制流量。
討論這類風險時，最容易混淆四件事：「網路上有路」、「規則目前允許」、「應用已建立連線」，以及「硬體根本沒有反向通道」。四者對攻擊面的影響不同，也需要不同證據。回程路徑代表多了一個可被嘗試、設定與維護的入口，但不代表入侵已經發生。
核心結論
只要 IT 到 OT 的回程路徑在實際拓撲與現行規則下可達，Red Side 或其他 IT 端點就有機會向 Blue Side 的 OT 端點送出通訊。每一條必要回程，都會多出目的位址、允許協定、服務端實作、身份與規則生命週期等管理工作。條件越多，可能被錯設、冒用或利用弱點的交界也越多。因此，攻擊面評估應從「哪些端點真的可達、哪些服務真的必要」開始，而不是只看邊界設備名稱。
移除同一邊界的回程路徑，可以排除 Red Side 沿這條路徑與 Blue Side 互動的可能性。若硬體在物理上沒有反向通道，這個方向也不依賴可修改的允許／拒絕規則。不過，這只處理該邊界的反向資訊流；其他入口、Blue Side 既有狀態、資料內容風險與營運失效仍要另外處理。
四個邊界概念｜不要把路徑、連線與實體方向混在一起
| 概念 | 本文使用的判斷方式 | 需要的證據 | 不能由它推定的事 |
|---|---|---|---|
| 回程可達性 | 在目前拓撲、路由與規則下，IT 發出的流量能否到達特定 OT 端點或邊界服務 | 實際資料流圖、路由、規則、位址、服務與雙向測試 | 已建立連線、身份檢查成功或已成功利用弱點 |
| 雙向連線 | 兩端是否依協定交換建立、維持或結束互動所需的資料與控制訊息 | 兩端狀態、握手、請求／回覆、確認或等價協定證據 | 所有可達路徑都一定會形成連線 |
| 規則控制的路徑 | 實體或邏輯路徑存在，流量是否通過由防火牆、路由器、ACL 或其他規則引擎決定 | 核准規則、預設拒絕、變更紀錄、測試與監控 | 物理上沒有反向通道，或規則不會改變與失效 |
| 硬體邊界沒有反向通道 | 邊界硬體只提供 Blue-to-Red 方向，Red Side 沒有同一跨域路徑可送回資訊 | 實體方向、獨立路徑盤點與架構檢查 | Blue Side 本身可信、資料內容安全、每筆資料送達或營運不會失敗 |
可達性是實際部署狀態，不只是拓撲圖上畫了一條線。若路由存在，但現行規則阻擋所有相關流量，目的端當下並不可達；不過這條路徑仍由規則控制，後續的規則、例外與變更程序都要持續維護。相反地，若物理上沒有反向通道，就無法只靠更新網路規則把同一邊界改成 Red-to-Blue 資訊流。
雙向連線也不等於一般可達性。可達性只回答通訊是否可能抵達；連線還要由兩端依協定交換狀態。TCP 是具體例子，但不是唯一的雙向協定：它透過三向交握建立連線，兩端都要送出自己的序號並確認對方的序號，建立後也會用確認訊息維持資料傳輸。查閱 RFC 9293 的 connection establishment
來源事實｜網路分區、防火牆規則與雙向連線
NIST SP 800-82 Rev. 3 將盤點、分區與隔離 IT／OT 裝置列為良好的網路架構做法。組織應先依資料流辨識必要通訊，再透過交換器、路由器、防火牆、單向閘道或 data diode，只允許經核准的跨區段通訊。查閱 NIST 的 network architecture 指引
同一份文件把防火牆描述為控制網路區段間連線與資訊流的彈性邊界設備。對分層架構，文件建議避免讓較高層設備直接連到較低層 OT 裝置。它也把 unidirectional gateway 或 data diode 描述為只允許核准通訊朝一個方向移動，並在詞彙表說明其硬體物理上無法把資訊送回來源網路。查閱 NIST 的 isolation 與 unidirectional gateway 定義
NIST SP 800-41 Rev. 1 說明，防火牆會依組織的資安政策，控制不同安全狀態之網路或主機間的流量。狀態式檢查可以記錄連線狀態；文件以 TCP 為例，說明一個被規則允許的連線嘗試，要完成三向交握後才會成為已建立的連線。查閱 NIST 的 firewall 與 stateful inspection 說明
RFC 9293 則把 TCP connection 的雙向依賴寫得更具體。每一端都必須送出自己的 initial sequence number、接收對方的 number，並回傳確認；established connection 中，接收與 acknowledgement 也屬於協定狀態的一部分。查閱 RFC 9293 的 sequence 與 acknowledgement 規則 這項來源事實用來說明 session 需要雙向交換，不表示所有 IT-to-OT 通訊都使用 TCP。
來源建議｜只保留必要通訊，並驗證規則真的生效
NIST SP 800-82 Rev. 3 建議先依資料流、關鍵程度、信任、位置或管理權責分組，再評估區域與隔離設定對日常營運、安全與應變的影響。防火牆規則應只允許相鄰層級或區域間真正需要的連線；對外規則也要和對內規則一樣嚴格管理。查閱 NIST 的 OT-specific recommendations
NIST SP 800-41 Rev. 1 建議防火牆採預設拒絕，只讓必要的 IP 協定、來源／目的位址與連接埠通過。文件同時要求規則明確、部署前測試連線及允許／阻擋結果，並持續管理後續政策、軟體、日誌與設定變更。查閱 NIST 的 firewall policy 與生命週期建議
依這些來源建議，回程路徑的審查不應停在「有防火牆」或「目前沒有業務連線」：
- 以實際用途列出每一條 IT-to-OT communication requirement，記錄發起端、目的端、協定、身份與必要時間範圍。
- 對照 route、NAT、ACL、firewall rule、跳板與遠端維護機制，確認哪些路徑在現行 enforcement 下真正可達。
- 分別測試允許與拒絕案例，包含從非預期來源、目的位址、port 與 session state 發起的 traffic。
- 將例外、臨時連線、規則物件、管理介面與變更權限納入同一份 data-flow review。
- 若用途只需要 Blue-to-Red data release，重新檢查回程是否是資料需求，或只是原協定互動方式留下的假設。
- 若用途確實需要 command、maintenance、interactive query 或 acknowledgement，保留其雙向需求並明確治理，不把它描述成不存在。
編輯推論｜回程路徑如何增加攻擊面
綜合 NIST 對資料流、核准通訊、防火牆規則與單向閘道的區分，以及 RFC 9293 對雙向連線狀態的規範，可以推論：每一條可達的 IT-to-OT 回程路徑，都會增加一組需要保護的入口條件。這些條件至少包括可被定址的 OT 目的端、會解析輸入的服務、允許規則、連線狀態、身份或管理權限，以及改變這些項目的程序。
「增加攻擊面」不代表建立路徑後就必然遭到攻擊。攻擊仍取決於威脅行動者能否接近發起點、是否取得身份、能否利用服務或設定弱點，以及其他防護是否有效。另一方面，規則目前拒絕流量，也不會讓底層路徑變成物理不存在；規則誤設、例外、未盤點入口或維護變更，仍是需要管理的失效方式。
若硬體強制單向邊界沒有物理反向通道，Red Side 遭入侵的端點就無法沿同一跨域路徑，建立回到 Blue Side 的雙向連線。這是一項明確但有限的資訊流結論。它不涵蓋惡意程式從其他媒介或網路入口進入、內部人員活動、Blue Side 已存在的入侵、來源端失陷、被釋出資料本身的風險、目的端處理問題或營運失效。
因此，移除回程路徑應記錄為威脅模型中一項可驗證的邊界條件，而不是完整的防護敘事。來源端強化、身份與權限、媒體與供應鏈控制、內容驗證、目的端防護、監控、事件應變、安全與復原，仍有各自的責任。
評估清單
- 先畫出 Blue-to-Red data release 與所有 IT-to-OT return paths，避免用一條「雙向」箭頭隱藏不同用途。
- 對每條回程分別記錄 return-path reachability、policy decision 與實際 session behavior。
- 確認 deny-by-default 規則只允許必要來源、目的端、protocol、port、identity 與時間範圍。
- 搜尋繞過主要 enforcement point 的其他 ingress、臨時路徑、dual-homed host 與維護連線。
- 用雙向測試驗證允許與拒絕結果，不只閱讀規則畫面或 route table。
- 將規則新增、修改、停用、緊急例外與回復程序納入 review 與 log。
- 若宣告不存在物理反向通道，另外檢查共享 data／management channel 與其他實體路徑，而不以 firewall policy 代替證據。
- 在 residual risk 中逐項保留 insider activity、其他 malware path、source-side compromise 與 operational failure。
閱讀限制
本文提供產品中立的 network reachability 與 attack-surface reasoning，不是完整 penetration test、incident attribution、產品適用性或合規判定。引用 NIST 與 IETF 文件用來保留 segmentation、firewall policy、unidirectional boundary 與 TCP session 的原始語境，不構成任何產品或部署的適用性證據。實際架構仍須依 data flows、OT safety、operation、threat model、其他 ingress 與組織程序完成風險評估。