單向閘道器是一種把跨越安全邊界的資料方向固定為單向的設備。它常被稱為 Data Diode、Unidirectional Gateway 或單向資料閘道器。重點不是「只設定成單向」，而是邊界上的硬體路徑本身不提供反方向的資料通道。
這類架構常用在 OT、ICS 與關鍵基礎設施：來源安全域需要把監控資料、日誌或檔案送往另一個安全域，又不希望目的端沿同一條邊界路徑建立回程連線。它處理的是特定路徑的方向控制，不是整個環境的完整安全方案。
核心結論
一套可用的單向閘道通常不只有中間的單向硬體。來源端需要採集指定資料，硬體邊界只允許資料朝核准方向移動，目的端再把收到的內容重建成應用程式可使用的資料或服務。可以把它理解成三個相連但責任不同的階段：採集、單向傳輸、目的端重建。
Data Diode 回答的是「這條邊界上能不能往回傳資料」。它不直接回答資料內容是否正確、每筆資料是否送達、來源系統是否健康、目的端應用是否正確解析，也不取代身份管理、端點防護、網路分區、監控、備份與事件應變。
來源事實｜NIST 如何定義單向閘道
NIST SP 800-82 Rev. 3 把 Data Diode 定義為只允許資料朝一個方向移動的網路設備，也列出 Unidirectional Gateway、Deterministic One-Way Boundary Device 等相關名稱。文件在網路分區與隔離章節說明，單向閘道可讓經核准的通訊只朝一個方向進行；其硬體配置用來阻止資料朝相反方向跨越同一邊界。查閱 NIST SP 800-82 Rev. 3 的定義與架構說明
NIST SP 1800-7B 的電力公用事業參考設計則呈現一個實作範例：單向光學硬體負責固定傳輸方向，兩端軟體負責把操作環境中的資料複製到企業環境。這個例子顯示，單向硬體與資料應用層各自解決不同問題，不能只看中間的光纖連接就推定目的端一定能使用資料。查閱 NIST SP 1800-7B 的 one-way transfer reference design
運作原理｜採集、單向傳輸與重建
| 階段 | 主要工作 | 評估時要確認 |
|---|---|---|
| 來源端採集 | 從指定系統讀取允許釋出的日誌、檔案、歷史資料或其他內容 | 資料來源、格式、頻率、來源端權限與失敗處理 |
| 單向硬體邊界 | 只提供來源端到目的端的物理資料方向 | 實體方向、設備角色、邊界範圍與其他可能路徑 |
| 目的端重建 | 將收到的資料轉換成目的系統可讀取的介面或表示 | 解析、順序、重複、缺口、過期狀態與目的端可用性 |
第一步是來源端採集。來源端元件依明確定義的資料範圍讀取內容，並準備成可送往單向邊界的表示。若來源沒有產生紀錄、採集服務停止，或選錯資料範圍，後續硬體方向正確也無法補出缺少的內容。
第二步是單向傳輸。硬體路徑讓資料只朝目的端移動，不提供目的端沿同一通道送回請求、確認或控制資料的物理路徑。這是它和只靠可調整網路規則控制方向的設備最核心的差別。
第三步是目的端重建。因為原始的雙向互動不會直接跨越這條單向邊界，兩端通常要以適合資料類型的方式完成採集與目的端呈現。目的端看到的是收到後建立的資料介面或副本，不是來源端原始連線的延伸。
單向閘道器、Data Diode 與光纖閘道有什麼差別
Data Diode 與 Unidirectional Gateway 經常用來指稱同一類單向邊界技術；中文可稱為資料二極體、單向閘道器或單向資料閘道器。不同文件與供應商的用字不完全一致，評估時仍要回到硬體方向、兩端處理方式及實際資料介面。
「光纖閘道」則不是足以判定方向性的精確名稱。許多網路設備都能使用光纖，光纖媒介本身不代表資料只能單向移動。若需求是硬體固定方向，應進一步確認它是否具備單向光學路徑、反方向是否存在任何物理資料通道，以及管理或維護是否另有其他連線。
因此，搜尋或初步評估時可以用「單向光纖閘道」協助描述媒介與方向，但技術規格仍應寫清楚「硬體強制單向資料閘道器」或同等可驗證的邊界要求。
常見用途｜哪些資料路徑可能適合
單向閘道常見於「資料需要離開較受控環境，但同一條路徑不需要接受回傳」的情境，例如：
- 將 OT 或 ICS 的監控資料送往企業端分析平台。
- 將安全日誌送往集中式日誌或事件分析環境。
- 將歷史資料、報表或經核准檔案釋出到另一個安全域。
- 在不同安全區域之間建立只讀型的資料副本。
這些名稱只能作為初步分類。是否適合仍取決於應用程式的互動方式、更新需求、資料量、容錯方式、維運流程與現場風險。若業務流程必須由目的端即時送回指令、交握、查詢或確認，就不能假設原流程可直接搬到單向邊界上。
來源建議｜先畫資料流，再評估控制
NIST SP 800-82 Rev. 3 將網路分區、隔離、防火牆與單向閘道放在 OT 網路架構脈絡下討論。它的重點不是為所有環境指定同一種設備，而是依風險、區域、層級與必要通訊管理資訊流。評估前應先列出資料從哪裡來、要送到哪裡、允許哪個方向，以及哪些雙向流程必須保留。查閱 NIST 的 network segmentation and isolation guidance
NIST SP 1800-7B 的參考設計也顯示，單向路徑會改變維運與監測方式。企業端不能沿該單向路徑回頭探測操作端感測器；連線中斷或資料缺漏需要由來源端儲存、存活訊號、完整性檢查與缺口辨識等機制另行處理。若遠端管理另設繞行路徑，那條路徑必須被視為不同的安全邊界並單獨評估。查閱 NIST 的 liveness、data verification 與 management considerations
編輯推論｜單向控制能做什麼、不能做什麼
從上述資料可得到一個有限結論：硬體單向邊界可以把特定跨域路徑的方向，從可由設定改變的網路條件，轉成需要改動實體架構才能改變的條件。這對必須排除同一路徑回程通訊的需求具有明確價值。
但方向控制只涵蓋被納入設計的邊界。其他遠端存取、無線連線、可攜式媒體、維護介面、供應鏈與實體接觸仍要另行盤點。來源端已存在的問題、錯誤資料或未產生的紀錄，也不會因為跨越單向邊界而自動修正。
同樣地，沒有反向資料通道代表目的端不能沿同一路徑回傳狀態。資料缺漏、來源服務失效、目的端解析錯誤與資料過期，都需要額外的可觀測性與營運程序。架構評估應分別驗證「方向是否固定」與「資料是否符合使用需求」，不能用其中一項代替另一項。
若下一步要比較單向硬體與可設定網路規則的差異，可接著閱讀Data diode 與防火牆：兩種不同的邊界控制。
評估前先問的問題
- 哪個安全域是來源端，哪個安全域是目的端？核准方向是什麼？
- 哪些資料必須跨越邊界？它們由哪個系統產生、多久更新一次？
- 原本流程是否依賴目的端回傳查詢、確認、控制或管理資料？
- 來源端採集停止、目的端未收到資料或資料過期時，誰會知道？
- 是否另有遠端維護、備援、無線、可攜式媒體或其他跨域路徑？
- 目的端需要的是原始紀錄、資料副本、檔案，還是重新建立的應用介面？
- 如何測試資料順序、重複、缺口、解析錯誤與復原流程？
- 哪些安全控制仍由防火牆、身份管理、端點防護、監控與實體安全負責？
閱讀限制
本文是產品中立的技術說明，用來建立單向閘道器的基本概念與評估問題，不是對任何特定產品、部署或現場架構的核准。文中的 NIST 引用只支撐各段明確標示的來源內容，不延伸到本文推論或任何實作。實際選型仍需依資料流程、營運需求、安全分析、測試結果與適用規範個別判斷。