A、文件定位
這一版是給船東技術部門、造船廠、系統整合商、設備供應商與驗船師快速建立共同語言的 15 分鐘導覽版。它不追求把每一條 checklist 全部展開，而是先讓讀者掌握三件事：
- 這個法規架構為什麼出現
- IMO、IACS UR E26／E27 與 LR 船級規則各自管什麼
- 實際新造船、審圖、工廠／船上測試、年度檢驗與營運維持時應怎麼應用
實務提醒： 本文是學習與內訓用途的視覺化整理。正式設計、審圖、檢驗與合規判斷，仍應以最新 IMO 文件、IACS UR、LR 船級規則、船旗國要求及船級社正式意見為準。
B、先講核心：網路韌性不是防毒，而是船舶安全能力
現代船舶已經不是單純的機械平台。電子海圖（ECDIS）、整合自動化系統（IAS）、警報監控系統（AMS）、電力管理系統（PMS）、動態定位（DP）、貨控系統、遠端監控、衛星通訊與供應商遠端維護，都讓船舶成為 資訊技術（IT）與操作技術（OT）互相連動的複合系統。
因此，海事網路韌性的重點不是「有沒有裝防毒」或「有沒有防火牆」，而是：
即使發生網路事件，船舶仍能維持安全狀態、繼續必要操作，並能恢復關鍵功能。
LR 在與 COSCO Heavy Industry 合作的 E26 合規散貨船設計報導中，也把 UR E26 的船舶營運適用面整理為：設備識別、保護、攻擊偵測、應變與復原。用這五個功能元素來讀，最容易理解網路韌性要求如何落到船舶設計與營運。(LR)
| 功能元素 | 對船舶的意思 | 現場應用 |
|---|---|---|
| 識別 | 知道船上有哪些電腦系統、軟硬體、網路連線與依存關係 | 資產清單、網路圖、安全區域圖 |
| 保護 | 降低未授權存取與惡意程式影響 | 網路分區、帳號權限、USB 管制、遠端連線管制 |
| 偵測 | 能發現異常行為或事件徵兆 | 紀錄、警報、異常連線與掃描紀錄 |
| 應變 | 發生事件時知道如何隔離、通報、切換 | 事件應變、停用遠端連線、切換手動或備援模式 |
| 復原 | 事件後能恢復系統與營運 | 備份、還原測試、系統映像與復原程序 |
這也是為什麼網路韌性在船舶領域已經從資訊題目變成 安全與船級維持題目。
C、法規沿革與生效時程
1. IMO：先把網路風險放進 SMS／ISM
IMO 在 2017 年通過 MSC.428(98)「安全管理系統中的海事網路風險管理」，要求主管機關確保公司把網路風險適當納入既有的 安全管理系統（SMS），且不晚於 2021 年 1 月 1 日後公司 符合證明（DOC） 第一次年度驗證。(imo.org)
IMO 也發布 MSC-FAL.1/Circ.3/Rev.3「海事網路風險管理指南」，提供高層次的海事網路風險管理建議。(imo.org)
公司與船舶管理者必須把網路風險納入 ISM／SMS。
2. IACS：從管理要求走向船級技術要求
IMO 先解決「誰要管理網路風險」，但沒有細到規定一艘船和船上設備在設計、測試、審圖與驗船時要交什麼文件、做什麼測試。
IACS 因此制定：
- UR E26：船舶網路韌性
- UR E27：船上系統與設備網路韌性
LR 在 North Star 風電維運船（CSOV）的網路韌性船級案例中說明，相關船舶是依 LR 規則所導入的 IACS UR E26（船舶網路韌性）與 UR E27（船上系統與設備網路韌性） 取得正式核准；LR 也指出，這類認證的目的在於協助船舶抵抗網路攻擊、在威脅下維持操作，並於事件後快速復原。(LR)
3. 關鍵生效日期：2024 年 7 月 1 日
IACS 正式說明，修訂後 UR E26／E27 適用於 2024 年 7 月 1 日及以後簽訂建造合約的新船；原先 2024 年 1 月 1 日的適用日期已撤回。(Safer and Cleaner Shipping - IACS)
簡化理解：
| 時間 | 事件 | 實務意思 |
|---|---|---|
| 2017 | IMO MSC.428(98) | 網路風險進入 SMS／ISM |
| 2021.01.01 | 符合證明年度驗證節點 | 公司管理制度需納入網路風險 |
| 2024.07.01 | IACS UR E26／E27 主要生效 | 新造船開始面對船級技術要求 |
| 2025.07 | LR 2025 年 7 月船級規則 | 要求落到 LR 審圖、檢驗與持續符合性 |
| 2026－2027 | EU CRA 部分時程 | 船用數位產品供應鏈可能同步受產品網路安全要求影響 |
D、整體法規架構：誰管什麼？
這套規定最容易混亂的地方，是把 IMO、IACS、LR、船旗國、船東、船廠與供應商全部混在一起看。比較清楚的理解方式，是把它分成四層：
| 層級 | 代表規範 | 核心作用 |
|---|---|---|
| IMO 管理層 | MSC.428(98)、MSC-FAL.1/Circ.3/Rev.3 | 要求公司把網路風險放進 SMS／ISM |
| IACS 船級技術層 | UR E26、UR E27 | 建立船舶與船上系統設備的最低網路韌性要求 |
| 船級社規則層 | LR 2025 年 7 月船級規則 | 把要求轉成審圖、工廠／船上測試、年度檢驗與完整檢驗可查核項目 |
| 營運維持層 | SMS、船東程序、供應商支援 | 交船後持續維持資產清單、圖面、帳號、更新、備份與演練 |
IMO 告訴你要管理；IACS 告訴你船與設備要具備什麼能力；LR 把它落到船級審查與檢驗；船東與管理公司負責營運期間持續維持。
E、UR E26：船舶層級要求，管整艘船
1. E26 的定位
UR E26 = Ship Level Requirement（船舶層級要求）
它不是只看單一設備，而是看整艘船的網路韌性：哪些系統互連、哪些系統屬於關鍵操作、哪些網路區域需要隔離、遠端維護如何管制、事件後如何維持安全狀態與恢復功能。
LR 在與 COSCO Heavy Industry 的 E26 合規散貨船設計報導中指出，UR E26 管的是船舶網路韌性，並著重確保船上操作技術與資訊技術設備在船舶全生命週期中的安全整合。因此，E26 可理解為整船層級的要求：不是只看單一設備，而是看整艘船能否在設計、建造、交船與營運期間維持網路韌性。(LR)
2. E26 最重要的交付物
對新造船而言，E26 的成果不應只是一本網路韌性文件，而是一組能被審查、驗證、交船與營運維持的證據。
| E26 要求方向 | 應看到的證據 | 為什麼重要 |
|---|---|---|
| 資產清單 | 電腦系統、硬體、軟體、韌體、版本、IP／網段、區域資訊 | 沒有清單，就不知道風險在哪裡 |
| 網路拓樸 | 實體／邏輯網路圖、安全區域圖、通訊通道圖 | 判斷 OT、IT、船員 Wi-Fi、供應商遠端入口是否混接 |
| 網路區隔 | 防火牆、虛擬區域網路、閘道、安全區域邊界設定與規則 | 避免船員 Wi-Fi 或 IT 事件橫向影響 OT |
| 存取控制 | 帳號、權限、密碼政策、預設密碼移除、遠端登入授權 | 讓事件可追蹤，降低未授權修改 |
| 備份與復原 | 備份程序、系統映像、還原測試、事故後恢復程序 | 有備份不夠，必須證明能還原 |
| 變更管理 | 軟體、網路、設定與供應商服務變更紀錄 | 避免交船後文件與現場快速脫節 |
3. E26 的實務判斷
驗船師或船東不需要一開始就深入每個封包細節。更有效的第一步是問：
- 船上有哪些關鍵 CBS？
- OT、IT、船員 Wi-Fi、供應商遠端入口是否清楚分區？
- 網路圖與現場交換器、虛擬區域網路、閘道、防火牆設定是否一致？
- 最近更新過哪些軟體、韌體或網路設定？
- 如果整合自動化系統、電力管理系統、電子海圖或貨控系統故障，是否有備份與復原程序？
若這五個問題都答不清楚，通常表示 E26 的船舶層級管理還沒有真正落地。
F、UR E27：系統與設備層級要求，管供應商交付
1. E27 的定位
UR E27 = System／Equipment Level Requirement（系統與設備層級要求）
它管的是船上各個 電腦系統（CBS），例如電子海圖、整合自動化、警報監控、電力管理、動態定位控制、主機控制、貨控、壓載控制、液位量測、火警偵測與通訊系統等。
LR 在 North Star 風電維運船的網路韌性船級報導中說明，相關船舶依 LR 規則所導入的 UR E26 與 UR E27 取得正式核准；認證過程會檢視動態定位軟體、連接推進單元的複雜控制系統等關鍵任務系統。這也說明 E27 的重點，是讓船上系統與設備在交付前具備可審查、可測試、可維護的網路安全能力。(LR)
2. E27 要求供應商提供什麼？
E27 的重點不是要求供應商只說「我們的設備很安全」，而是要求供應商拿得出可審查、可測試、可維護的文件與證據。
| 供應商文件 | 用途 |
|---|---|
| 電腦系統資產清單 | 說明系統內硬體、軟體、韌體與元件 |
| 拓樸圖 | 說明系統內部與外部連線關係 |
| 安全能力說明 | 說明帳號、權限、紀錄、惡意程式防護、備份等能力 |
| 安全設定指南 | 提供安全設定與系統硬化基準 |
| 修補／更新程序 | 說明更新、修補、相容性與回復管理 |
| 測試程序／測試報告 | 證明安全功能已在 FAT 或適當環境中測試 |
| 事件與維護資訊 | 支援事件處置、維護與後續生命週期管理 |
3. E27 與 FAT／審圖的關係
E27 對造船廠和供應商的實務影響很直接：
- 規格書階段就要要求 E27 文件
- 工廠驗收測試程序要包含網路安全能力測試
- 系統整合商要確認不同供應商設備接到整船網路後仍符合分區與存取控制
- 交船文件不能只交操作手冊，還要能支援營運期間修補、備份、還原與事件應變
G、LR 2025 年 7 月船級規則：把要求落到審圖與檢驗
依 LR 官方頁面，2025 年 7 月 1 日版船舶入級規則 已發布並可透過 Regs4ships 存取。(lr.org)
就實務理解而言，LR 的角色是把 IMO 與 IACS 的要求轉成船級流程中可以查核的項目：
| 船級流程 | 查核重點 |
|---|---|
| 新造船審圖 | 網路韌性計畫、資產清單、網路圖、安全區域／通訊通道、E27 供應商文件 |
| 工廠／碼頭／海上測試 | 安全功能測試、網路分區確認、遠端連線控制、備份／還原驗證 |
| 年度檢驗 | 船上計畫書是否在船、清單與圖面是否更新、變更紀錄與安全措施是否維持 |
| 完整／五年檢驗 | 經多年營運後，軟體版本、帳號、網路架構、備份、遠端連線與測試證據是否仍有效 |
年度檢驗的核心，不是重新做一次完整審圖，而是確認：
船舶營運期間沒有讓原本的網路韌性安排失效。
完整檢驗則要更重視多年營運後的偏差：交船時的圖面、帳號、軟體版本、遠端維護方式，是否已經與現場不同。
H、不同角色的責任分工
這套法規真正困難的地方，是責任跨越船東、船廠、系統整合商與供應商。若合約與交付界面沒有講清楚，很容易變成「設備各自合規，但整船不合規」。
| 角色 | 最重要責任 |
|---|---|
| 船東／公司 | 在規格書寫入要求，交船後維持 SMS、訓練、演練、更新、備份與變更紀錄 |
| 造船廠 | 整合整船網路架構、收斂供應商文件、組織工廠／碼頭／海上測試與交船文件 |
| 系統整合商 | 設計 Zone／Conduit、確認跨系統介面、避免遠端維護入口混亂 |
| 設備供應商 | 提供 E27 文件、安全功能、測試報告、修補支援、系統硬化指南與還原程序 |
| 驗船師 | 查核文件、現場、測試與持續符合性證據是否一致 |
| 船員 | 遵守 USB、帳號、遠端連線、通報、演練與應變程序 |
最重要的責任轉移點是交船。交船前，造船廠與供應商要完成設計、測試、文件與整合；交船後，船東與管理公司要維持更新、紀錄、訓練與演練。
I、15 分鐘讀完後，現場應該怎麼應用？
如果只能用最短時間判斷一艘船的網路韌性準備程度，可以問以下六個問題：
| 現場提問 | 判斷重點 |
|---|---|
| 1. 請提供網路安全與韌性計畫書。 | 如果船方不知道在哪裡，通常表示制度沒有真正落地。 |
| 2. 請提供最新資產清單與網路圖。 | 如果圖面仍是交船版，但船上已加裝 Starlink、4G／5G router 或遠端監控設備，文件可能已失效。 |
| 3. OT、IT、船員 Wi-Fi、供應商遠端入口是否真的隔離？ | 不只看圖面，還要看 switch、VLAN、gateway、firewall 與現場配線。 |
| 4. 供應商遠端連線如何授權、記錄與中止？ | 供應商不是不能遠端維護，但必須受控、限時、可追蹤、可由船方中止。 |
| 5. 最近一年有哪些軟體、韌體或網路設定變更？ | 有變更但沒有批准、測試、回復與文件更新，就是變更管理風險。 |
| 6. 最近一次還原測試或網路事件演練是什麼時候？ | 有備份不代表能復原；有程序不代表船員知道怎麼做。 |
這六個問題能快速看出：文件是否在船、現場是否一致、遠端入口是否受控、變更是否有管理、復原與演練是否真的做過。
J、常見誤解
| 誤解 | 比較正確的理解 |
|---|---|
| E26／E27 只是一份文件要求 | 它要求的是船舶與設備具備可證明的網路韌性能力 |
| 只要裝防毒與 firewall 就可以 | 防護只是其中一部分，還要有識別、偵測、應變與復原 |
| 現有船完全不用管 | 強制技術適用主軸是新造船，但現有船仍可能因船級符號、改裝、船旗國、租家或管理制度面對要求 |
| 供應商設備各自合規，整船就合規 | E26 看的是整船層級整合，供應商 E27 合規不自動等於整船合規 |
| 交船拿到網路韌性文件就結束 | 交船後的更新、帳號、遠端連線、備份、演練與變更紀錄才是持續符合性的核心 |
K、最後總結
IMO MSC.428(98) 解決「誰要管理網路風險」；IACS UR E26 解決「整艘船如何具備網路韌性」；IACS UR E27 解決「船上系統與設備應提供哪些安全能力與文件」；LR 船級規則 則把這些要求落實到審圖、測試、年度檢驗、完整檢驗與現場查核。
網路韌性已經是船舶安全、船級維持、新造船交付與營運管理的一部分；它不是單一資訊措施，而是一套跨越設計、設備、整合、測試、交船與全生命週期維護的管理與技術架構。