核心觀念

本題考查軟體定義網路（Software Defined Networking, SDN）的三項核心：

1. 控制平面與資料平面分離：將傳統網路設備中的路由決策功能集中至控制器，交換器主要負責依流表轉送封包。
2. 集中式、可程式化控制：透過控制器統一掌握網路拓樸、流量與政策，並由應用程式下達網路服務需求。
3. 分層架構與開放介面：應用層、控制層、基礎設施層各自負責不同功能，層與層之間透過北向介面、南向介面及東西向介面溝通。

答題時應依「定義與特性 → 架構與介面 → 各層威脅」順序作答，並將威脅分成應用層、控制層、資料平面及介面與管理面說明。

【答案】

（一）軟體定義網路

軟體定義網路是一種將網路的「控制平面」與「資料平面」分離的網路架構。傳統網路設備通常由各交換器或路由器自行執行路由計算、政策判斷及封包轉送；SDN 則將路由決策、流量工程、存取控制及網路政策集中交由 SDN 控制器管理，網路設備依控制器下發的流表進行封包轉送。

SDN 的主要特性如下：

1. 控制與轉送分離：控制器負責決策，交換器負責依流表轉送封包。
2. 集中管理：控制器具有全域網路視觀，能統一設定路由、QoS、存取控制及流量工程政策。
3. 可程式化：應用程式可透過北向介面呼叫網路服務，不必逐台設定設備。
4. 設備功能簡化與彈性提高：底層設備可透過標準化介面接受控制器指令，方便虛擬化、自動化及動態調整。
5. 支援網路切片與多租戶：可依不同服務需求建立邏輯隔離的虛擬網路，適合 5G 大量設備及差異化服務需求。

（二）SDN 網路架構

1. 架構圖

┌──────────────────────────────────────────────┐
│ 應用層 Application Layer │
│ 網路管理、流量工程、QoS、防火牆、入侵偵測、 │
│ 網路切片、負載平衡、服務鏈等應用程式 │
└──────────────────────────────────────────────┘
 ▲
 │ 北向介面 Northbound API
 │ REST API、RESTCONF、Intent API
 ▼
┌──────────────────────────────────────────────┐
│ 控制層 Control Layer │
│ SDN Controller／控制器 │
│ 拓樸探索、路由計算、流表管理、政策管理、 │
│ 網路視觀、資源配置、事件處理 │
└──────────────────────────────────────────────┘
 ▲ ▲
 │ 東西向介面 │ 東西向介面
 │ Controller-to-Controller │ 控制器同步
 ▼ ▼
 南向介面 Southbound API
 OpenFlow、NETCONF、
 OVSDB、P4Runtime
 │
 ▼
┌──────────────────────────────────────────────┐
│ 基礎設施層 Infrastructure Layer │
│ 實體／虛擬交換器、路由器、基地台、 │
│ 防火牆及其他網路轉送設備 │
│ 依流表執行封包轉送、丟棄及統計 │
└──────────────────────────────────────────────┘

2. 應用層

應用層包含使用網路能力的各種應用程式，例如：

• 網路管理系統。
• 流量工程與負載平衡。
• 防火牆與存取控制。
• 入侵偵測與安全事件分析。
• QoS 管理。
• 5G 網路切片管理。
• 服務鏈與虛擬網路功能管理。

應用程式不直接控制交換器，而是透過北向介面向控制器提出需求，例如要求建立特定路徑、限制某類流量或配置一個網路切片。

3. 控制層

控制層的核心是 SDN 控制器，主要功能包括：

1. 蒐集網路拓樸及設備狀態。
2. 維持全域網路視觀。
3. 執行路由計算及流量工程。
4. 將應用層政策轉換為具體的轉送規則。
5. 產生並下發流表。
6. 接收設備回報的流量統計、錯誤及事件。
7. 進行資源配置、網路切片與服務品質管理。

控制器可採單一控制器，也可採分散式多控制器架構。大型 5G 網路通常需要多控制器以提高可用性、擴充性及容錯能力。

4. 基礎設施層

基礎設施層又稱資料平面，包含實體交換器、虛擬交換器、路由器、基地台及其他轉送設備。其主要工作是：

• 查詢封包標頭。
• 比對流表。
• 依流表執行轉送、丟棄、修改封包或送往控制器。
• 蒐集流量與設備統計資料。
• 回報鏈路狀態及異常事件。

資料平面通常不負責整體路由政策的決定，而是執行控制器下達的規則。

5. 北向介面

北向介面連接應用層與控制層，常見形式包括 REST API、RESTCONF、Intent API 及其他程式介面。應用程式透過北向介面要求控制器執行：

• 建立路由。
• 設定流量限制。
• 配置 QoS。
• 建立或刪除網路切片。
• 實施存取控制政策。

北向介面重點在於「提出網路需求」，不一定直接指定底層設備的每一項命令。

6. 南向介面

南向介面連接控制器與基礎設施層，常見協定包括 OpenFlow、NETCONF、OVSDB 及 P4Runtime。其功能包括：

• 下發流表。
• 取得設備狀態。
• 讀取流量統計。
• 接收設備事件。
• 設定轉送行為。

南向介面是控制器影響資料平面的主要管道，因此必須進行身分驗證、完整性保護及機密性保護。

7. 東西向介面

東西向介面用於多個控制器之間交換資訊，例如：

• 同步拓樸及流表狀態。
• 分配網路資源。
• 進行跨控制器路由。
• 執行故障轉移。
• 維持分散式控制器的一致性。

東西向介面若遭竄改，可能導致多個控制器產生錯誤決策或狀態不一致。

（三）SDN 各階層所面臨的威脅

1. 應用層威脅

（1）惡意或遭入侵的應用程式

攻擊者若取得網路管理、流量工程或防火牆應用程式的控制權，便可透過北向介面修改網路政策，例如：

• 將流量導向攻擊者控制的設備。
• 開放原本禁止的連接埠。
• 刪除防火牆規則。
• 建立未經授權的網路切片。

（2）應用程式權限過大

若所有應用程式都具有完整控制權，單一應用程式遭入侵便可能影響整個網路。因此須採取最小權限、角色分離及細緻化授權。

（3）應用程式間政策衝突

不同應用程式可能同時下達互相矛盾的政策，例如一個應用程式要求轉送流量，另一個應用程式要求封鎖流量。控制器若缺乏政策衝突偵測，會產生錯誤流表或安全漏洞。

（4）北向 API 攻擊

核心觀念

本題考查我國政府零信任架構的「資源門戶部署」及其三大核心機制。零信任的基本原則是「永不信任，持續驗證」：不因使用者已在機關內網、曾經登入成功，或設備位於受信任網段，就直接授予存取權限。

我國政府架構參考 NIST SP 800-207，並配合集中防護需求，採資源門戶部署。使用者存取機關資通系統時，須先經過存取閘道；系統再依身分、設備及當下情境進行判斷，決定是否允許存取。

解題方法

題目已指定「三大核心機制」，作答時依序說明：誰在存取（身分鑑別）、使用什麼設備存取（設備鑑別）、這次存取是否符合安全條件（信任推斷）。最後補上三者如何由存取閘道與決策機制串接，即可完整說明此部署方式。

三大核心機制

一、身分鑑別

身分鑑別的目的，是確認發起存取要求者確為其所聲稱的使用者，避免只憑帳號或密碼就取得資源存取權。

1. 多因子身分鑑別：使用者須以具備足夠安全性的鑑別方式證明身分，例如硬體安全金鑰或其他多因子鑑別器。設計重點是避免單一遭竊的密碼即可冒用身分。
2. 身分鑑別聲明：驗證成功後，身分鑑別系統將使用者身分及鑑別結果，以安全方式傳遞給欲存取的資通系統，使該系統能確認請求者身分及其鑑別狀態。

二、設備鑑別

設備鑑別的目的，是確認使用者所用的終端設備為已註冊、受機關管理且狀態符合要求的設備。使用者身分正確，不代表其設備也可信。

核心觀念

本題考查資安事件的分類與確認，以及確認事件後的事故回應行動。事件候選（Incident Candidate）是值得調查的異常訊號，但單一訊號不一定代表事故已經發生。Pipkin 將事故指標分為「有可能（possible）」、「極有可能（probable）」及「明確（definite）」三類；明確指標通常能直接指出資訊安全原則已受侵害。

資訊安全的核心原則為機密性、完整性及可用性（CIA）。若資訊或系統的機密性、完整性或可用性受到實際損害，即屬真實資安事故的重要判據。違反組織安全政策或相關法律，也可作為明確事故指標。

解題方法

第一小題從 Pipkin 的「明確指標」切入：說明哪些安全原則或規範已受侵害，並交代如何蒐集、核對證據，以排除正常作業或誤報。第二小題依事故處理流程作答，涵蓋通報與協調、控制擴散、保全證據、清除威脅及復原驗證。

（一）確認真實資安事故的方法

1. 確認可用性是否受損 檢查系統、網路服務或資料是否無法正常使用，例如服務遭阻斷、主機離線、使用者無法存取必要資源。應比對監控紀錄、系統狀態及服務中斷時間，確認問題並非例行維護、設備故障或短暫負載尖峰。確認服務確實因未授權行為或攻擊而中斷，即為可用性受損。

2. 確認完整性是否受損 檢查檔案、資料庫或系統設定是否遭未授權修改、刪除或破壞，例如資料內容異常、檔案雜湊值改變、設定被更動。可比對備份、版本紀錄、檔案雜湊值及稽核日誌，確認變更時間、來源帳號與操作是否經授權。證實資料或系統遭未授權竄改，即為完整性受損。

3. 確認機密性是否受損 查明敏感資料是否遭未授權存取、複製或外洩，例如帳號異常下載大量資料、機敏資訊出現在外部位置，或收到可信的資料外洩通知。應核對存取紀錄、網路流量、檔案傳輸紀錄及資料外洩範圍；確認資訊已暴露給未授權對象，即為機密性受損。

4. 確認是否違反組織安全政策或法律 核對異常行為是否違反帳號使用、權限管理、資料處理等安全政策；若涉及違法行為，亦應確認相關資訊資產是否受影響。可比對政策規定、帳號權限、操作日誌、變更單及事件通報資料。違規事實與資訊資產的關聯獲得證實，即可判定為事故指標。

實務上應將警示與系統日誌、網路紀錄、使用者通報及資產狀態交叉比對，記錄時間、來源與影響範圍。未知程序、異常資源使用或入侵偵測系統（IDPS）警示多屬有可能或極有可能的指標；需進一步調查，才能排除誤報並確認事故。

核心觀念

本小題考查「弱點如何被統一命名、整理，以及對應到實際資訊資產」。CVE 是弱點的識別編號；NVD 是整理、補充弱點資料的資料庫；CPE 則是描述軟體、作業系統與硬體產品的標準化名稱。三者搭配後，才能把「已知弱點」連結到「受影響產品」。

• CVE（Common Vulnerabilities and Exposures，共同弱點與曝險）：一套公開已知資安弱點的識別與命名機制。每筆弱點會取得唯一的 CVE 編號，格式如 CVE-年份-流水號。CVE 的用途是讓不同廠商、資料庫及資安工具能以一致編號指稱同一項弱點；CVE 編號本身不是嚴重性評分，也不代表已提供修補程式。

• NVD（National Vulnerability Database，國家弱點資料庫）：由美國國家標準暨技術研究院（NIST）維護的弱點資料庫。NVD 收錄 CVE 資料，並補充弱點描述、CVSS 嚴重性評分、受影響產品資訊、修補或參考資料等內容，供弱點管理及自動化比對使用。

• CPE（Common Platform Enumeration，共同平台列舉）：用於標準化識別資訊科技產品的平台命名方式，可描述作業系統、應用程式及硬體等資產。CPE 條目會以欄位呈現產品類別、廠商、產品名稱、版本、更新版本及其他屬性，例如： cpe:2.3:a:oracle:jdk:1.8.0:update92:*:*:*:*:*:* 其中 a 表示應用程式；後續欄位描述廠商、產品及版本等資訊。

解題方法與運作關係

作答時可依「弱點編號 → 弱點資料補充 → 產品對應」說明：

1. CVE 提供弱點的共同編號：研究人員或廠商揭露弱點後，依 CVE 機制為其建立識別編號，使各方能以同一編號交換資訊。
2. NVD 收錄並補充 CVE 資料：NVD 將 CVE 資料整理入庫，再加入 CVSS 評分、弱點說明及修補資訊等內容。
3. NVD 將弱點對應到 CPE：NVD 以 CPE 描述受影響的產品及版本，建立「CVE 弱點 ↔ CPE 產品」的對應關係。
4. 資產管理工具進行比對：機關盤點自身產品名稱及版本，將資產轉成或對應至 CPE，再與 NVD 中的受影響 CPE 範圍比對。符合受影響條件的資產，即列為需評估及處理的弱點項目。

因此，CVE 解決「這是哪一項弱點」；CPE 解決「這是哪一種產品或版本」；NVD 則提供兩者之間的整理、關聯及風險資料。

解題技巧與常見陷阱

記憶口訣：CVE 編弱點、NVD 補資料、CPE 認產品。CVE 編號不是產品名稱，也不是 CVSS 分數；CPE 本身不是弱點資料庫。若只寫出三個英文全名，未交代 NVD 如何藉 CPE 將弱點連結到資產，便沒有完整回答三者的運作情形。

（二）資通安全弱點通報機制（VANS）及其運作方法

核心觀念