110 中華郵政招考營運職 資通訊與安全管理 資訊系統及網路安全 考古題詳解

核心觀念

本題考查軟體測試的四個測試層級、測試執行順序，以及白箱測試與黑箱測試的差異。判斷重點如下：

• 依測試對象由小到大，可分為：單一模組、模組間介面、完整系統、使用者需求。
• 白箱測試重視程式內部結構與控制流程。
• 黑箱測試重視輸入、輸出及功能需求，不必知道程式內部實作方式。

---

（一）四種測試及執行順序

1. 單元測試（Unit Testing）

單元測試是針對軟體中最小可測試單位進行測試，例如：

• 函式
• 程式程序
• 類別
• 個別模組

其目的在確認單一單元的邏輯、計算、資料處理及例外處理是否正確。

單元測試通常由程式設計人員執行，測試範圍小，容易定位錯誤。例如測試「計算應繳金額」的函式是否能針對不同輸入產生正確結果。

2. 整合測試（Integration Testing）

整合測試是將已通過單元測試的模組組合起來，檢查模組之間的介面及互動是否正確。

主要檢查：

• 資料傳遞格式是否一致
• 函式呼叫參數是否正確
• 模組間的控制流程是否正常
• API、資料庫、外部系統介接是否正常
• 錯誤處理及例外狀況是否能正確傳遞

例如，訂單模組將資料傳給付款模組時，需確認金額、訂單編號及付款結果是否能正確交換。

3. 系統測試（System Testing）

系統測試是將所有模組整合成完整系統後，依據系統規格與需求進行整體測試。

測試內容包括：

• 功能是否完整
• 系統流程是否正確
• 效能是否符合要求
• 安全性是否足夠
• 相容性、可靠性及可用性是否符合規格
• 系統在正常與異常情況下是否能正確運作

系統測試著重整個系統的外部行為，而非單一程式碼片段。

4. 驗收測試（Acceptance Testing）

驗收測試是由客戶、業主、使用者或其代表，依據業務需求及驗收標準，確認系統是否可正式接受與使用。

其目的在回答：

系統是否滿足使用者需求，是否具備上線條件？

驗收測試可能包含：

• 使用者驗收測試（User Acceptance Testing, UAT）
• 作業驗收測試
• 合約驗收測試
• 法規或業務規範符合性測試

驗收測試通過後，通常才會進入正式部署或上線階段。

5. 測試先後順序

系統開發過程中，通常依下列順序進行：

$$\text{單元測試} \rightarrow \text{整合測試} \rightarrow \text{系統測試} \rightarrow \text{驗收測試}$$

其理由是：

1. 先確認每個單一模組本身正確。
2. 再確認模組組合後的介面與互動正確。
3. 接著確認完整系統符合系統規格。
4. 最後由使用者或業主確認是否符合實際需求。

【（一）答案】

單元測試針對個別函式、程序、類別或模組進行測試；整合測試針對模組間的介面、資料傳遞與互動進行測試；系統測試針對完整系統進行功能、效能、安全性及可靠性等整體測試；驗收測試則由使用者、客戶或業主依需求與驗收標準確認系統是否可接受及正式使用。

先後順序為：

$$\boxed{\text{單元測試}\rightarrow\text{整合測試}\rightarrow\text{系統測試}\rightarrow\text{驗收測試}}$$

---

（二）白箱測試與黑箱測試

1. 白箱測試（White Box Testing）

白箱測試又稱結構測試或透明盒測試，是根據程式的內部結構、邏輯及控制流程設計測試案例。

測試人員通常需要了解：

• 程式碼
• 判斷式
• 迴圈
• 分支
• 執行路徑
• 資料結構
• 程式內部控制流程

常見的白箱測試方式包括：

• 敘述覆蓋（Statement Coverage）
• 分支覆蓋（Branch Coverage）
• 條件覆蓋（Condition Coverage）

核心觀念

本題考查三種軟體開發模式：

1. 瀑布模式：依序完成各階段，前一階段完成後才進入下一階段。
2. 雛型模式：先快速建立可操作的雛型，透過使用者反覆試用與回饋，逐步確認需求。
3. 敏捷開發：以短週期、反覆迭代、持續交付與快速回應變更為核心，強調客戶與開發團隊的密切合作。

---

（一）瀑布模式的軟體開發週期【10 分】

1. 系統規劃與可行性分析

確認組織需求、系統目標、開發範圍及資源限制，並評估系統是否值得開發。

常見評估項目包括：

• 技術可行性
• 經濟可行性
• 作業可行性
• 時程可行性
• 法律或政策可行性

此階段的主要成果是確定系統目標、初步需求、開發範圍與可行性評估報告。

2. 需求分析

蒐集並分析使用者需求，明確定義系統應提供的功能、輸入、輸出、資料、效能及安全要求。

需求分析必須將「使用者想要什麼」轉換成可供設計與開發使用的正式需求規格，例如：

• 功能需求
• 資料需求
• 效能需求
• 使用者權限需求
• 資訊安全需求
• 備援與可用性需求

此階段通常產出需求規格書。

3. 系統設計

依據需求規格，規劃系統的整體架構與詳細設計，包括：

• 系統架構
• 資料庫與資料結構
• 輸入與輸出介面
• 模組劃分
• 網路與硬體配置
• 使用者介面
• 存取控制與安全機制

系統設計可分為：

• 概要設計：規劃整體架構與主要模組。
• 詳細設計：定義各模組的處理流程、資料結構與介面細節。

4. 程式設計與建置

依據設計文件撰寫程式，建立資料庫、設定系統環境，並完成各項軟硬體元件的整合。

此階段重點包括：

• 程式撰寫
• 模組開發
• 資料庫建置
• 程式碼檢查
• 版本管理
• 單元測試準備

5. 測試

確認系統是否符合需求規格，並找出程式錯誤、介面錯誤、資料錯誤及安全弱點。

常見測試層次如下：

1. 單元測試：測試個別程式模組。
2. 整合測試：測試模組間的介面與資料傳遞。
3. 系統測試：測試完整系統是否符合整體需求。
4. 驗收測試：由使用者或業主確認系統是否可正式接受。

測試的目的不只是確認「程式能執行」，更要確認功能、效能、安全性及可靠性均符合需求。

6. 系統實施與轉換

將完成測試的系統正式導入作業環境，包含：

• 安裝軟體與硬體
• 資料轉換與移轉
• 使用者教育訓練
• 操作手冊製作
• 舊系統與新系統切換

常見系統轉換方式包括：

• 直接轉換：一次停止舊系統並啟用新系統，速度快但風險高。
• 平行轉換：新舊系統同時運作，風險較低但成本較高。
• 先導轉換：先在部分單位或範圍導入，再逐步擴大。
• 階段轉換：依功能或模組逐步導入。

7. 運作與維護

系統正式上線後，持續處理錯誤修正、功能增修、效能改善及環境變更。

軟體維護通常包括：

• 更正性維護：修正系統錯誤。
• 適應性維護：因應作業環境、法規、硬體或作業系統變更。
• 完善性維護：新增或改善功能。
• 預防性維護：降低未來發生錯誤的可能性。

作答整理

瀑布模式的標準流程可整理為：

規劃與可行性分析 → 需求分析 → 系統設計 → 程式設計與建置 → 測試 → 實施與轉換 → 運作與維護

不同教材可能將「規劃」併入分析階段，或將「程式設計」與「實施」合併，但核心順序相同。

---

（二）雛型模式的系統開發程序與參與人員【7 分】

1. 雛型模式的核心觀念

雛型模式適用於需求不明確、使用者難以用文字完整描述需求，或人機介面與操作流程需要頻繁確認的系統。

其核心做法是：

先建立一個簡化、可操作的系統雛型，讓使用者實際操作，再根據回饋修正需求與系統設計。

雛型不一定是最終產品，而是用來協助確認需求、驗證設計及降低開發風險的模型。

2. 系統開發程序

（1）確認初步需求

系統分析師先訪談使用者，掌握系統目標、主要功能、重要資料及基本操作流程。

此時不要求需求完全確定，而是先找出最重要、最容易被使用者理解與驗證的部分。

（2）快速建立初始雛型

使用快速開發工具、畫面原型、流程模型或簡化程式，建立具有基本操作功能的雛型。

初始雛型可包含：

• 操作畫面
• 功能選單
• 輸入欄位
• 查詢及報表
• 基本資料流程
• 部分核心功能

（3）使用者試用與評估

讓實際使用者操作雛型，觀察畫面、流程、功能及輸出是否符合工作需求。

使用者可指出：

• 功能遺漏
• 操作不便
• 欄位不合理
• 流程不符合實際作業
• 報表內容不足
• 權限或安全需求未納入

（4）修正雛型與需求

系統分析師根據使用者意見修正雛型，同時補充及澄清需求規格。

此階段會反覆進行：

$$\text{建立雛型} \rightarrow \text{使用者評估} \rightarrow \text{修正雛型}$$

直到使用者與開發團隊對主要需求及操作方式達成共識。

（5）確認需求並完成正式系統

雛型確認後，將已確定的需求正式化，再進行完整的系統設計、程式開發、測試、導入與維護。

核心觀念

本題考查防火牆的三項基本概念：

1. 封包過濾防火牆如何依據網路封包的標頭資訊進行允許、拒絕或丟棄。
2. 網路層、傳輸層防火牆與應用層攻擊之間的防護能力差異。
3. 透過 DMZ 進行網路分區與存取控制，以降低公開服務遭入侵時對內部網路的影響。

本題不涉及特定法條或計算公式，應依網路安全的「最小權限」、「分區防禦」及「縱深防禦」原則作答。

---

（一）封包過濾防火牆的運作機制【10 分】

1. 定義

封包過濾防火牆（Packet Filtering Firewall）是在網路封包通過網路介面或路由器時，檢查封包標頭中的欄位，依據預先設定的安全規則判斷封包是否可以通過。

它主要工作在 OSI 模型的網路層與傳輸層，通常不深入解析應用程式的實際內容。

2. 判斷依據

防火牆規則通常會檢查下列資訊：

• 來源 IP 位址
• 目的 IP 位址
• 通訊協定，例如 TCP、UDP、ICMP
• 來源埠號
• 目的埠號
• TCP 旗標，例如 SYN、ACK
• 封包進入及離開的網路介面
• 封包方向，例如由外部進入內部、由內部連往外部
• 連線狀態；具狀態檢查功能的防火牆會追蹤既有連線

例如，可設定下列規則：

• 允許外部使用者連線至 DMZ 網頁伺服器的 TCP 443 埠。
• 拒絕外部直接連線至內部資料庫伺服器的 TCP 1433 埠。
• 允許內部使用者對外發出 HTTP 或 HTTPS 連線。
• 拒絕來源不明、目的地不符規則或具有異常旗標的封包。

3. 運作流程

封包通過防火牆時，處理流程如下：

1. 防火牆接收網路封包。
2. 讀取封包標頭資訊。
3. 依序比對既定的存取控制規則。
4. 若符合允許規則，則轉送封包。
5. 若符合拒絕規則，則丟棄封包，或回傳拒絕訊息。
6. 若沒有任何規則符合，則依預設政策處理。

安全性較高的設定通常採用「預設拒絕」（Default Deny）原則，也就是只有明確允許的流量才能通過，其餘流量一律拒絕。

4. 無狀態與有狀態過濾

傳統封包過濾多屬無狀態過濾（Stateless Filtering），每一個封包單獨判斷，不記憶前後封包的連線關係。

具狀態檢查功能的防火牆（Stateful Inspection Firewall）則會建立狀態表，追蹤 TCP 三向交握、連線建立、傳輸及結束等狀態，只允許屬於合法既有連線的回應封包通過，因此安全性與判斷能力較佳。

5. 機制整理

封包過濾防火牆的核心可表示為：

$$\text{封包標頭資訊}+\text{存取控制規則} \longrightarrow \text{允許、拒絕、丟棄或記錄}$$

因此，它的本質是「依封包特徵進行流量存取控制」，而不是對所有應用程式內容進行完整理解。

---

（二）封包過濾防火牆是否能抵擋 SQL Injection？原因為何【5 分】

判斷

一般封包過濾防火牆無法有效抵擋 SQL Injection 攻擊。

原因

SQL Injection 是發生在應用層的攻擊。攻擊者將惡意 SQL 語法嵌入登入欄位、查詢參數、網址參數、表單內容或 API 請求中，誘使後端應用程式將外部輸入誤當成 SQL 指令執行。

封包過濾防火牆主要檢查：

• IP 位址
• 埠號
• TCP、UDP 等協定
• 封包方向
• 連線狀態

它通常只確認封包是否從合法來源前往允許的目的埠，無法理解 HTTP、HTTPS 請求中的參數語意，也不會判斷其中是否含有惡意 SQL 字串。

例如，攻擊者透過正常的 TCP 443 埠傳送 HTTPS 請求。對封包過濾防火牆而言，這只是合法的加密網頁流量，無法直接辨識其中的 SQL Injection 內容。

適當防護措施

防範 SQL Injection 應採用應用層安全機制，例如：

• 使用參數化查詢或預備陳述式（Prepared Statement）
• 嚴格進行輸入驗證
• 避免直接串接 SQL 字串
• 限制資料庫帳號權限
• 使用具應用層檢測能力的 Web Application Firewall（WAF）
• 建立資料庫及應用程式的稽核記錄

解題技巧

看到「封包過濾防火牆」時，先判斷其檢查層次：

• 只看 IP、埠號、協定：無法辨識 SQL Injection。
• 能解析 HTTP 內容並比對攻擊特徵：屬於 WAF 或應用層防護，不是單純封包過濾。

---

核心觀念

本題考查區塊密碼的兩項基本參數：

1. 秘密金鑰長度：決定可能的金鑰數量與暴力破解難度。
2. 加密區塊長度：決定演算法每次處理的明文與密文資料大小。

另考查 Triple-DES 將 DES 連續執行三次時，依「加密或解密的排列」及「使用獨立金鑰數量」所形成的四種實作法。

---

解題方法

先分別整理 DES 與 AES 的標準規格，再以符號表示 Triple-DES 的運算順序：

• $E_K(X)$：使用金鑰 $K$ 對資料 $X$ 加密。
• $D_K(X)$：使用金鑰 $K$ 對資料 $X$ 解密。
• 明文記為 $P$，密文記為 $C$。

Triple-DES 的三次 DES 運算可依序排列為：

• 三次皆加密：EEE
• 加密、解密、加密：EDE

再依金鑰是否全部獨立，區分為三金鑰與二金鑰兩種形式。

---

（一）DES 與 AES 的金鑰長度及區塊長度

1. DES

DES 的金鑰欄位長度為 64 位元，但每 8 位元中有 1 位元作為同位檢查位元，因此真正參與加密運算的有效金鑰長度為：

$$64-8=56\text{ 位元}$$

DES 每次處理一個固定大小的資料區塊，區塊長度為：

$$64\text{ 位元}=8\text{ 位元組}$$

因此，DES 的規格為：

• 金鑰長度：有效長度 56 位元；儲存格式通常為 64 位元，含 8 位元同位檢查位元。
• 加密區塊長度：64 位元。

2. AES

AES 的區塊長度固定為：

$$128\text{ 位元}=16\text{ 位元組}$$

AES 可使用三種金鑰長度：

• AES-128：128 位元
• AES-192：192 位元
• AES-256：256 位元

因此，AES 的規格為：

• 金鑰長度：128、192 或 256 位元。
• 加密區塊長度：128 位元。

3. 比較表

比較項目	DES	AES
秘密金鑰長度	有效 56 位元；格式為 64 位元含同位檢查位元	128、192、256 位元
加密區塊長度	64 位元	128 位元
加密型態	區塊加密	區塊加密

---

（二）Triple-DES 的四種實作法

Triple-DES 對每一個 DES 區塊連續執行三次運算。四種實作法是由下列兩個條件組合而成：

1. 三次運算採用 EEE 或 EDE。
2. 使用三把獨立金鑰，或使用兩把獨立金鑰並重複其中一把。

1. 三金鑰 EEE：EEE3

使用三把獨立金鑰 $K_1,K_2,K_3$，三次皆執行加密：

$$C=E_{K_3}\left(E_{K_2}\left(E_{K_1}(P)\right)\right)$$

特徵：

• 三次運算均為 DES 加密。
• $K_1,K_2,K_3$ 彼此獨立。
• 金鑰欄位總長度為 $3\times 56=168$ 位元，未考慮密碼分析攻擊的實際安全強度。

---

2. 三金鑰 EDE：EDE3

使用三把獨立金鑰，依序執行加密、解密、加密：

$$C=E_{K_3}\left(D_{K_2}\left(E_{K_1}(P)\right)\right)$$

特徵：