歐盟網路資訊安全條例初探（七之三）

（續前篇）

EU Regulation 2019/881 (Cybersecurity Act)

適合讀者：大學以上程度｜法規、資訊、資安、工程、產業界從業人員 此文僅供個人參考與資訊喚回，尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。法規內容可能隨時間修訂，具體符合決策宜諮詢歐盟專業法律顧問或驗證機構。文中提及之市場資料係基於公開報告及邏輯估算，實際數值可能隨時變動。參考法規資訊截至2026年3月，後續修訂請查閱ENISA官方網站和EUR-Lex資料庫。 CC BY-SA 4。0。

六、ICT產品、服務與流程——優點與缺點

6.1 驗證對ICT產品的優點

●     市場通行（Market Access）：持有ECCF驗證的產品在整個歐盟市場免於各國重複驗證，節省驗證成本估計達30-50%

●     競爭優勢：驗證成為差異化利器，有助贏得政府採購和B2B大客戶

●     責任保護：製造商可藉驗證降低因產品安全缺陷引發的法律風險

●     消費者信任提升：統一的ECC標誌讓終端用戶易於識別安全產品

●     供應鏈透明度：驗證過程強制揭露依賴的第三方元件，改善供應鏈可見度 

6.2 驗證對ICT產品的缺點與挑戰

●     成本高昂：「高」等級驗證費用可達50-200萬歐元，對中小企業（SMEs）構成重大障礙

●     時程冗長：完整評鑑周期通常需12-24個月，對快速迭代的軟體產品不友好

●     動態技術與靜態驗證的矛盾：軟體頻繁更新可能使驗證快速失效，需重新評鑑

●     CAB產能不足：具備「高」等級評鑑能力的實驗室在歐洲僅約20-30家，供不應求

●     跨境驗證的不完整：ECCF驗證方案尚在建立，過渡期間各國驗證仍共存 

6.3 ICT服務與流程的特殊考量

類型	說明
ICT服務的挑戰	雲端服務具有動態性、多租戶性、跨境性，傳統「產品驗證」邏輯難以直接套用。EUCS方案因此採「持續監控」機制，而非一次性驗證。
ICT流程的挑戰	開發流程的安全性評鑑需深入軟體供應鏈（含開源元件），參考SBOM（Software Bill of Materials）概念，評鑑難度遠高於最終產品。
服務提供商的責任	雲端服務的驗證責任在服務提供商（CSP），而非個別用戶，形成「責任共擔模型（Shared Responsibility Model）」的監管挑戰。

七、符合性測試與調和標準

7.1 核心調和標準

該CSA條例驗證方案所參照的主要調和標準，涵蓋ISO/IEC標準系統及歐盟特有標準，說明如下：

標準	說明與應用
ISO/IEC 15408（通用準則 CC）	ICT產品安全評鑑的基礎國際標準，EUCC直接基於此等標準而建立符合性假設，定義保護剖繪（PP）、安全目標（ST）、評估保證等級（EAL）。目前已出版5個部份： Part 1：介紹與通用模型 Part 2：資安功能元件 Part 3：資安保證元件 Part 4：評估方法與定義的規格架構 Part 5：資安要求的預定義工具集
ISO/IEC TS 27103:2018	提供將ISO/IEC 27001/27002等ISMS資安管理標準映射至產品層級的網路資訊安全架構的指引，協助組織在不同架構間建立從組織面過渡到產品面對應資安管制的交互關係（例如ISO 27001與NIST CSF）。
ISO/IEC TS 27110:2021	《資訊技術、網路資訊安全與隱私保護——網路資訊安全架構開發指引》，提供了識別 (Identify)、保護 (Protect)、偵測 (Detect)、回應 (Respond)、復原 (Recover) 的核心架構（類似 NIST CSF），適用於 ICT 流程的驗證評估。為政策制定者建立國家/組織層級網路資訊安全架構提供方法學，是ENISA在評估成員國架構時的重要參考。
ISO/IEC 27404:2022	指導物聯網（IoT）生態系統的資安要求，針對IoT設備的唯一識別、，測試設備的授權、加密儲存、韌體更新、安全通訊等關鍵控制措施提供規範性指引，對IoT產品ECCF驗證方案有直接影響，適用於 ICT 流程的驗證評估。
ISO/TS 6268:2025	健康資訊科技設備的資安，與醫療電子設備相關之技術規範)，在醫療 ICT 產品申請 CSA 驗證時作為重要參考。
IEC 62443	工業自動化與控制系統（IACS）的資安標準系列，與ECCF的工業OT驗證方案整合，特別是第3-3部分（系統安全要求）和第4-2部分（元件要求），對於申請 ICS 相關設備的驗證至關重要。
ETSI EN 303 645	消費性IoT產品的網路資訊安全基準要求，已被多個ECCF候選方案採納為「基本等級」的技術參考。
ISO/IEC 27001:2022	資訊安全管理系統（ISMS）標準，在EUCS雲端驗證方案中作為「基本等級」的核心要求之一。
SOC 2（AICPA）	雖為美國民間標準，EUCS草案允許部分SOC 2控制措施作為「基本等級」的替代符合性路徑，體現國際互認的務實取向。

7.2 測試方法學

ICT產品符合性測試依保證等級採用不同的測試方法學：

●     功能測試（Functional Testing）：查證安全功能是否按設計運作（適用全部等級）

●     漏洞掃描（Vulnerability Scanning）：自動化工具識別已知漏洞（適用顯著/高等級）

●     滲透測試（Penetration Testing）：模擬攻擊者行為，識別邏輯漏洞（適用高等級）

●     原始碼審查（Source Code Review）：靜態分析工具加人工審查（適用高等級，EUCC EAL5+）

●     模糊測試（Fuzzing）：大量隨機/半隨機輸入以觸發意外行為（廣泛應用於高等級）

●     側訊號通道攻擊測試（Side-Channel Analysis）：針對硬體安全模組，測試電磁洩漏、功耗分析等

●     韌性測試 (Resilience Testing)：驗證系統在受攻擊下的恢復能力。

●     供應鏈評估：審查第三方元件之安全來源。 

7.3 軟體物料清單（SBOM）的新興要求

受美國總統行政令（EO 14028, 2021年）及歐盟《網路韌性法》（Cyber Resilience Act, CRA）草案（2022年）的影響，ENISA正在推動SBOM成為ICT驗證的標準要求之一，要求製造商揭露所有軟體元件（含開源元件）的完整清單，以利漏洞追蹤與供應鏈風險管理。 

八、已知缺陷之風險、陷阱與主要疑慮

8.1 技術層面的已知風險

🚨 高風險警示

風險1：驗證快照問題（Snapshot Problem）——驗證反映特定時間點的安全狀態，無法保證驗證後的安全性

風險2：供應鏈攻擊——SolarWinds式攻擊凸顯，即使通過驗證的產品也可能因上游元件被植入後門而受害

風險3：零日漏洞（Zero-day exploits）——驗證只能證明產品在「測試當下」是安全的，無法預測未知漏洞，廠商可能因此疏於後續維護，形成「驗證=安全」的錯誤公眾認知

風險4：驗證洗綠（Certification Washing）——企業僅取得低等級驗證卻宣稱全面安全符合性

風險5：依賴項風險：開源軟體組件之漏洞可能導致整體驗證失效

8.2 法規層面的陷阱

●     自願性架構的激勵不足：缺乏強制性要求時，高風險產品製造商可能逃避驗證

●     驗證方案開發遲滯：EUCS雲端方案因政治爭議（美國雲服務商的資料主權問題）延宕數年 

●     上市時間延遲 (Time-to-Market)：驗證過程耗時數月，對於生命週期極短的消費性電子產品而言，可能導致產品上市即過時。

●     與網路韌性法（CRA）的重疊與衝突：CRA要求ICT產品滿足基本安全要求，可能與ECCF形成雙軌符合性負擔

●     驗證撤銷機制不明：當已驗證產品發現嚴重漏洞時，撤銷驗證的程序尚未完善 

8.3 市場層面的主要疑慮

●     中小企業的進入障礙：驗證成本對SMEs過高，造成巨大財務與時間壓力，可能造成市場集中化，不利創新競爭

●     非歐盟企業的競爭劣勢：美國、中國ICT大廠在歐洲的驗證取得上面臨額外的主權資料審查

●     評鑑機構的利益衝突：CAB同時提供顧問服務與驗證評鑑，潛在利益衝突問題

●     標準碎片化仍存：在全歐統一驗證建立前，EUCC與各國舊方案並存，形成過渡期混亂

●     標誌濫用：在未取得證書前預先宣稱符合，將面臨市場監督處罰。 

8.4 操作層面的陷阱

●     錯誤解讀保證等級：客戶要求高等級驗證而產品實際風險僅需基本等級，造成資源浪費

●     針對「Substantial」以上的驗證，實驗室測試與稽核費用極高（可能達數萬至數十萬歐元），

●     驗證範圍界定不清：IoT生態系統中，邊緣裝置、閘道器、後端雲端各自需要何種驗證，常見爭議；若僅驗證了軟體版本，但未涵蓋雲端部署環境，導致合規漏洞；

●     持續監控成本被低估：「高」等級驗證的持續監控費用往往是初次驗證費用的50-100%/年 

●     配置錯誤：產品本身安全，但用戶配置不當。驗證需包含安全配置指南 (Hardening Guidelines)。

●     供應鏈斷層：未對下遊供應商進行足夠之安全評估，導致連帶責任。

●     靜態符合法規：認為通過驗證即可延續有效，忽視了持續監督與漏洞修復等後市場義務事項。

（未完，見續篇）

歐盟網路資訊安全條例初探（七之二）

（續前篇）

EU Regulation 2019/881 (Cybersecurity Act)

適合讀者：大學以上程度｜法規、資訊、資安、工程、產業界從業人員 此文僅供個人參考與資訊喚回，尚非法律建議或符合性途徑。內文引用人工智慧網路平臺提供資訊，經由整合篩選與文字調整。法規內容可能隨時間修訂，具體符合決策宜諮詢歐盟專業法律顧問或驗證機構。文中提及之市場資料係基於公開報告及邏輯估算，實際數值可能隨時變動。參考法規資訊截至2026年3月，後續修訂請查閱ENISA官方網站和EUR-Lex資料庫。 CC BY-SA 4。0。

三、法規架構與範圍

3.1 法規結構概覽

Regulation (EU) 2019/881共計九個章節、88條條款，附錄涵蓋ENISA管理委員會組成及驗證方案技術要求。

章節	主要內容
第I章（第1-4條）	總則：目標、定義、成員國義務
第II章（第5-12條）	ENISA的任務與職能
第III章（第13-14條）	ENISA內部組織架構
第IV章（第15-20條）	ENISA的運作規則
第V章（第21-31條）	ENISA與利害關係人的合作
第VI章（第32-49條）	歐洲網路資訊安全驗證架構（ECCF）核心規定
第VII章（第50-59條）	主管機關、市場監督、同儕審查
第VIII章（第60-67條）	授權、執行措施、委員會程序
第IX章（第68-88條）	過渡條款、廢止、修訂、生效

圖3-1：法規架構圖，展示 2019/881 與相關歐盟法規之關聯

此圖展示2019/881 法規之雙支柱架構：
- 左支柱：ENISA 永久授權，包含知識庫 (Knowledge Hub)、政策制定 (Policy Making)、CSIRT 網絡三大職能
- 右支柱：歐盟認證框架，分為 Basic、Substantial、High 三個保證等級
- 周邊關聯法規：GDPR、NIS2、AI Act、Cyber Resilience Act，箭頭顯示相互影響關係

3.2 適用範圍

該CSA條例適用於在歐盟市場銷售或提供使用的所有ICT產品、服務及流程：

l   ICT 產品 (Products)： 如路由器、IoT 設備、智慧家電、工業控制系統 (ICS)。

l   ICT 服務 (Services)： 如雲端運算服務 (Cloud Services)。

l   ICT 流程 (Processes)： 如軟體開發生命週期 (SDLC)、漏洞管理流程。

然而，特定領域存在排除適用CSA條例或特別規定：

⚠️ 重要排除事項

1. 國家安全相關產品：涉及國防、情報活動及軍事用途的ICT系統資安產品，各成員國可依TFEU第346條豁免，各成員國自行決定。

2. EU 2018/1139（民用航空安全）：民航相關的航空器、無人機及航空通訊設備的資安，ICT系統由歐洲航空安全局 (EASA) 依據專屬法規管轄，並負責驗證，以確保飛航安全與資安的整合。不適用CSA條例的ECCF驗證架構。

3. 核能設施相關：依Euratom條約另行規範

4. 已受NIS 2監管的特定實體：驗證方案可與NIS 2要求整合但不重疊

5. 純研發用途的ICT產品：未正式進入市場者暫不適用

6. 特定醫療器材雖受 CSA 影響，但主要仍受 MDR (Medical Device Regulation)或IVDR (In vitro Diagnostic Medical Device Regulation) 的嚴格規範。

3.3 自願性與強制性驗證

該CSA條例第49條明確規定，驗證架構原則上為「自願性」（voluntary）。但第49條第7款同時允許歐盟法規或各成員國法律將特定驗證設為強制性。已知的強制驗證趨勢包括：

●     關鍵基礎設施相關ICT產品（能源、交通、金融）

●     連網醫療器材（與MDR/IVDR整合）

●     公共採購中的ICT產品（2024年後逐步強制）

●     高保證等級的政府通訊系統

四、ENISA的角色、職責與CSIRT

4.1 ENISA的演進

ENISA成立於2004年（Regulation (EC) No 460/2004），歷經2013年（Regulation (EU) No 526/2013）的任期延展，至2019/881方才獲得永久授權。這項轉變具有里程碑意義，反映歐盟對網路資訊安全治理的長期承諾。

4.2 ENISA的核心職能（共10大類）

職能類別	具體內容
① 政策支援	協助歐盟機構及成員國制定與執行網路資訊安全政策，每年發布威脅形勢報告 (Threat Landscape) 提供技術建議及政策分析
② 能力建構	協助成員國提升國家網路資訊安全能力，特別是CSIRT的建立與運作
③ 知識與情資	維護歐洲網路資訊安全威脅態勢資料庫（European Cyber Threat Intelligence），發布年度威脅態勢報告（ENISA Threat Landscape，ETL）
④ 市場、驗證與標準化	協助制定驗證方案，與CEN、CENELEC、ETSI等標準化機構合作推動調和標準；
⑤ 研究與創新	支援EU研究架構（Horizon Europe）中的網路資訊安全研究，協調JRC等機構
⑥ 國際合作	代表EU參與FIRST、ITU-T SG17等國際網路資訊安全組織
⑦ 演習與訓練	每年舉辦「Cyber Europe」大規模跨國網路資訊安全演習
⑧ 事件應對支援	協調重大跨境事件的應對，支援各國CSIRT，事態嚴重時並可能觸發驗證撤銷機制
⑨ 公眾意識	推動歐洲網路資訊安全月（European Cybersecurity Month，ECSM）
⑩ 驗證架構管理	接受委員會委託起草EUCC、EUCS 等驗證計畫/驗證方案，維護ECCF的技術一致性

圖 4-1 ENISA 組織職責圖：呈現 ENISA 與各機構間之協作關係

圖中展示 ENISA 在歐盟網路安全治理架構中之 樞紐角色：
- 上方：歐盟委員會 (European Commission) — 政策指導
- 左側：成員國主管機關 — 市場監督
- 右側：認證機構 (CABs) — 第三方審核
- 下方：CSIRTs — 事件應變
- 協調機構：ECCG (歐洲網路安全認證集團)
核心價值：釐清各機構間之權責劃分與資訊流向。

4.3 CSIRT（電腦資安事件應變小組）網路

ENISA作為EU-CSIRT網路（CSIRTs Network）的秘書處，協調各成員國的國家/政府CSIRT進行資訊交換。CSIRTs Network依NIS 2第14-15條強制建立，其職責包括：

●     提早預警：跨國資安事件的早期通報

●     事件協調：重大事件中的多國協調應對

●     最佳實務分享：安全設定、漏洞揭露流程等

●     演習協調：與Cyber Europe演習整合

ENISA 2024年預算與人員規模

年度預算：約2,300萬歐元（2023年），2024年增至約2,500萬歐元

員工人數：約250人（雅典與赫拉克利翁兩地）

ETL報告：每年發布，涵蓋15+威脅類別，為歐洲網安情資的核心文件

五、驗證架構（ECCF）與第三方稽核

5.1 三級保證等級詳解

該CSA條例第52條定義三種保證等級，決定測試嚴格程度與所需評估活動：

項目	基本（Basic）	顯著（Substantial）	高（High）
適用產品	低風險消費性ICT：智慧音響、家用IoT	中風險：企業路由器、雲端服務	高風險：關鍵基礎設施、政府系統
評估方式	製造商自我評鑑（Self-Assessment）或簡易測試，目的是增加用戶基本信心	CAB執行的系統性測試、協力廠商測試，評估設計與開發流程	CAB全面滲透測試與原始碼審查、嚴格之協力廠商測試、威脅模擬 (Threat Simulation)，評估者需具備最高等級資格
文件要求	技術文件、EU符合性聲明	詳細設計文件、安全測試報告	完整安全評鑑文件、獨立查證
監督強度	後市場監督	中度監督	嚴格持續監督
對應CC等級	EAL 1-2（非必要）	EAL 3-4	EAL 5-7

圖 5-1 驗證三級保證金字塔圖：視覺化三個驗證等級之風險對應關係

基本級 Basic，綠色，自我評估，智能家居設備、USB 充電器、基礎 IoT 感測器
顯著級 Substantial，橙色，第三方測試，企業路由器、雲端備份服務、電子政務門戶
高級 High：紅色，持續監控，SCADA 系統、國家 ID 平台、5G 核心網絡

5.2 驗證方案（Schemes）進展

驗證方案	說明
EUCC（ICT Products）	基於通用準則（CC/ISO 15408），針對ICT硬體及軟體。2024年由EU實施法規（Implementing Act）正式採用，為首個ECCF方案。涵蓋保護剖繪（PP）開發。
EUCS（Cloud Services）	雲端服務驗證方案，2023年發布諮詢草案，整合CSA STAR、ISO 27001，設基本/顯著/高三級。
EU5G（5G網路）	歐盟5G安全驗證方案，基於ENISA的5G網路資訊安全指引（2019年），重點評鑑供應商多元化與網路韌性。
EUCC for ICS/OT	工業控制系統及操作技術驗證方案，開發中，與IEC 62443深度整合。
候選方案（正在評估）	IoT設備安全、人工智慧系統安全、量子抗性密碼應用等新方案正在研究階段。

5.3 第三方稽核與符合性評鑑機構（CAB）

取得「顯著」或「高」保證等級驗證，必須通過獨立的符合性評鑑機構（CAB）評鑑。CAB的資格要求包括：

●     依ISO/IEC 17065（產品驗證機構）或ISO/IEC 17025（測試實驗室）的認證

●     由成員國之國家認證機構（NAB）認證，NAB本身須為EA（歐洲認證合作組織）成員

●     具備針對特定產品類別的技術能力（Technical Competence），需定期接受NAB的監督評鑑 

●     跨境服務：獲得一個成員國認證之 CAB ，可在整個歐盟提供服務，但需接受目的地國主管機關之監督

●     「高」等級評鑑的CAB，還須具備先進攻擊場景（AVA_VAN.5）的滲透測試能力 

5.4 稽核流程（Audit process）

1.    申請人向選定的評鑑機構（CAB）提交申請，附上技術文件及佐證資料；

2.    （如 SGS, TÜV, BSI 等經過成員國認證的稽核機構）CAB執行相關稽核，包括各項步驟：

l   文件審查（Desktop Review）：檢查技術文件是否符合法規及標準要求

l   顯著/高等級：CAB執行實驗室測試、模糊測試 (Fuzzing)、密碼學查證、漏洞/弱點掃描及穿透性測試等現場評鑑；

l   現場稽核 (Site Audit)：針對「高」級別或流程驗證，稽核員會實地訪查開發環境的安全性（實體安全、存取控制）。

l   凡是不符合事項，受稽核機構（申請者）須在給定期間內，做成矯正、矯正措施（若適用時，尚須預防措施），回覆CAB，以佐證其ICT產品及服務的有效及安全。

3.    CAB出具稽核與評鑑報告，送交主管機關（對應「高」等級）

4.    頒發歐洲網路資訊安全憑證（ECC），有效期依方案規定（通常為3至5年）

5.    持續監督：主管機關執行後市場監督，若適用的驗證方案要求，由CAB執行年度複核 

6.    失效：若發現重大漏洞未修復，證書可被暫停或撤銷。

5.5 技術文件（Technical Documentation）

製造商必須準備申請ICT產品或服務之詳盡的技術文件，包括：（非完整列出）

l   架構與設計圖： 產品或服務的系統架構、信任邊界 (Trust Boundaries)、資料流圖。

l   風險與威脅建模 (Threat Modeling)： 如 STRIDE 模型分析，包括識別、評估與處理風險。

n   產品在發布前透過 SBOM 掃描發現的 已知缺陷 (Known Defects)。法規不允許產品帶著「未修補且可被利用的高危漏洞」上市。

n   新興風險 (Emerging Risks)： 如量子計算對現有 RSA/ECC 加密演算法的威脅，以及 AI 生成的自動化攻擊。風險評鑑報告必須具備「前瞻性」，並展示產品的密碼敏捷性 (Crypto-agility)。

l   材料清單 (SBOM - Software Bill of Materials)： 詳列所有開源與第三方元件，以利追蹤已知漏洞 (CVEs)。

l   用戶手冊與安全配置指南： 指導終端用戶如何安全地部署與更新設備。

l   自我宣告 (僅限 基本Basic 級別)： 製造商內部檢驗後起草符合性聲明 (DoC)。

（未完，見續篇）