110 中華郵政招考專業職(一) 資安與網路管理 中華郵政專業職(一) (資訊系統安全管理概要) 考古題詳解

（一）勒索軟體攻擊對資訊人的省思【4 分】

核心觀念

勒索軟體已由單純加密個人電腦，發展為鎖定企業重要伺服器、備份系統與營運環境的「雙重勒索」甚至「多重勒索」。攻擊者除加密資料外，也可能竊取敏感資料並威脅公開，造成營運中斷、商譽損失、法令責任與供應鏈衝擊。

解題方法

本題應從「資訊安全不只是 IT 技術問題，而是企業營運與風險管理問題」切入，說明資訊人應建立預防、偵測、應變及復原的完整防禦體系。

參考作答

資訊人應有下列省思：

1. 落實風險評估與資產盤點：確認關鍵業務、重要資料、核心伺服器及外部連線弱點，依營運影響程度配置防護資源。
2. 強化身分與端點安全：落實多因素驗證、最小權限、特權帳號管理、端點防護、弱點修補及防毒偵測，避免利用釣魚郵件、遠端服務或未修補漏洞入侵。
3. 落實網路分段與權限隔離：將辦公網路、伺服器區、備份區及營運技術網路分隔，限制橫向移動，避免單一帳號或單一主機遭入侵後擴散至全企業。
4. 建立可靠備份與復原機制：採用離線、異地或不可變更備份，並定期執行還原測試。備份系統必須與正式環境及一般網域帳號隔離，否則可能一併遭到加密。
5. 建立事件應變與營運持續計畫：事先規劃隔離感染主機、保存鑑識證據、通報、系統復原及對外溝通流程，並定期演練。
6. 提升人員資安意識與供應鏈管理：持續進行社交工程演練與教育訓練，並要求委外廠商及供應商符合資安要求。

解題技巧

答題時可用「預防—偵測—應變—復原」四階段組織內容；只寫「安裝防毒軟體」屬於單一技術措施，無法完整回應企業型勒索軟體的命題重點。

【答案】

資訊人應將勒索軟體視為企業整體營運風險，從資產盤點、身分與端點防護、網路分段、離線及異地備份、事件應變、營運持續、資安教育與供應鏈管理等面向，建立縱深防禦及可驗證的復原能力。

---

（二）RAID 與 RAID 5【各 4 分】

1. 容錯式磁碟陣列 RAID

核心觀念

RAID 是將多顆獨立實體磁碟組合成一個邏輯儲存單元，透過資料分割（striping）、鏡像（mirroring）或同位元檢查（parity），在提升效能、容量利用率或磁碟故障容忍能力之間取得平衡。

RAID 的重點包括：

• 資料分割：將資料分散寫入多顆磁碟，以提升平行存取效能。
• 鏡像：將相同資料複製到不同磁碟，以提高可用性。
• 同位元檢查：利用計算出的校驗資料，在部分磁碟故障時重建遺失資料。
• 容錯能力：磁碟故障時，系統仍可維持運作或於更換磁碟後重建資料。

RAID 並非備份。若發生誤刪除、勒索軟體加密、檔案毀損或整個儲存系統遭破壞，RAID 會同步保存錯誤結果，仍須搭配獨立備份。

解題方法

先指出 RAID 的全名與基本目的，再說明其結合多顆磁碟的方式，以及「效能、容量、可用性」三者的關係，最後補充 RAID 不等於備份，即可完整作答。

2. RAID 5 的容錯能力

核心觀念

RAID 5 使用分散式同位元檢查資料，將資料區塊與 parity 區塊分散寫入所有磁碟，避免將校驗資料集中於單一磁碟而形成效能瓶頸。

假設某一資料區塊為 $D_1$、另一資料區塊為 $D_2$，同位元檢查資料可概念化表示為：

$$P = D_1 \oplus D_2$$

其中 $\oplus$ 表示 XOR。當 $D_1$ 遺失時，可利用：

$$D_1 = P \oplus D_2$$

重建原資料。

RAID 5 的容錯能力

RAID 5 至少需要三顆磁碟，具有以下特性：

• 可容忍任一顆磁碟故障，故障期間通常仍可讀取資料，但效能會下降。
• 更換故障磁碟後，可利用其餘磁碟的資料與 parity 重建內容。
• 可用容量約為：

$$(N-1)\times \text{單顆磁碟容量}$$

其中 $N$ 為磁碟數量。

• 無法容忍同時兩顆磁碟故障；在重建期間若再發生另一顆磁碟故障，陣列可能失效。

解題技巧

記憶方式為：RAID 5 的「5」可聯想到「至少 3 顆、容忍 1 顆故障、容量少 1 顆」。另須注意，RAID 5 的容錯是針對磁碟故障，不代表資料備份。

【答案】

RAID 是以多顆獨立磁碟組成邏輯陣列，透過資料分割、鏡像或 parity，提升效能、容量利用率及磁碟故障容忍能力。RAID 5 將 parity 分散配置於所有磁碟，因此可容忍任一顆磁碟故障，並於更換故障磁碟後重建資料；

核心觀念

本題綜合考查：

1. HTTPS、HTTP 與 SSL/TLS 的協定關係。
2. 單一登入的定義及其安全性效益與風險。
3. IPsec VPN 的運作層次、封包保護方式與通道建立程序。
4. OWASP 常見網路應用程式弱點，尤其是 Injection Flaws 的成因與防護。

---

（一）HTTPS、HTTP 與 SSL 的關係【6 分】

1. HTTPS 英文全名

HTTPS 是：

Hypertext Transfer Protocol Secure

中文通常稱為「安全超文字傳輸協定」。

2. HTTPS 與 HTTP 的差異

HTTP 是應用層的網頁傳輸協定，主要負責瀏覽器與網站伺服器之間的請求與回應；但傳輸內容通常以明文方式傳送，容易遭到竊聽、竄改或冒充。

HTTPS 的本質是：

$$\text{HTTPS}=\text{HTTP over TLS}$$

亦即在 HTTP 與 TCP 之間加入 TLS 安全機制，使 HTTP 資料在傳輸前先受到保護。

兩者差異如下：

比較項目	HTTP	HTTPS
資料機密性	通常無加密	透過 TLS 加密
資料完整性	無法有效防止竄改	可偵測傳輸內容是否遭竄改
身分驗證	通常不驗證伺服器身分	透過數位憑證驗證伺服器
預設連接埠	TCP 80	TCP 443
防護能力	易遭竊聽、中間人攻擊	可降低竊聽、竄改及冒充風險

HTTPS 可提供三項主要安全性：

• 機密性（Confidentiality）：防止第三者直接讀取傳輸內容。
• 完整性（Integrity）：防止資料在傳輸途中被竄改而不被發現。
• 身分鑑別（Authentication）：利用伺服器憑證確認連線對象的身分。

3. HTTPS 與 SSL 的關係

SSL 是 Secure Sockets Layer 的縮寫，是早期用於保護網路傳輸的安全協定；後續由 TLS（Transport Layer Security）取代。

因此，嚴格來說，目前 HTTPS 使用的是 TLS，而不是早期的 SSL。實務上仍常以「SSL 憑證」泛稱網站使用的 TLS 數位憑證。

TLS 建立安全連線時，通常會：

1. 協商加密演算法。
2. 驗證伺服器的數位憑證。
3. 透過非對稱式加密或金鑰交換協定建立工作階段金鑰。
4. 使用對稱式加密保護後續 HTTP 資料。

解題技巧

看到 HTTPS，應立即聯想到：

HTTP 是應用內容，TLS 是安全保護層，SSL 是 TLS 的前身。

「HTTPS 等於 HTTP 加密」只說到部分重點，完整答案還應包括伺服器身分驗證及資料完整性。

【答案】

HTTPS 全名為 Hypertext Transfer Protocol Secure。HTTPS 是將 HTTP 建立於 TLS 安全通道之上，與明文傳輸的 HTTP 相比，可提供資料機密性、完整性及伺服器身分鑑別。SSL 是早期的安全協定，已由 TLS 取代；實務上所稱的 SSL 憑證，多數是指 TLS 憑證。

---

（二）單一登入 SSO 及其安全性好處【6 分】

1. SSO 的定義

單一登入（Single Sign-On，SSO）是指使用者只需向中央身分驗證服務完成一次登入，即可在授權範圍內存取多個不同的應用系統，而不必在每一個系統分別輸入帳號及密碼。

典型架構包含：

• 使用者。
• 服務提供者（Service Provider，SP）。
• 身分提供者（Identity Provider，IdP）。
• 身分驗證憑證或權杖。

使用者向 IdP 驗證身分後，IdP 將驗證結果或權杖傳給各應用系統，應用系統依據該結果判斷是否授權使用者存取。

2. 使用 SSO 的安全性好處

（1）減少密碼數量及重複使用

使用者不必為每個系統設定不同密碼，可降低使用者將同一組密碼重複使用於多個系統的情形。

（2）集中套用身分驗證政策

組織可在中央身分驗證服務統一實施：

• 多因素驗證。
• 密碼複雜度要求。
• 登入失敗鎖定。
• 裝置或地點限制。
• 風險式登入判斷。

可避免各系統安全設定不一致。

（3）集中管理帳號生命週期

人員離職、轉調或權限變更時，管理者可在中央系統停用帳號或撤銷權限，降低遺漏停用個別系統帳號的風險。

（4）降低密碼輸入及暴露機會

使用者只需在中央登入頁面輸入密碼，可減少在多個應用程式中輸入密碼而遭釣魚、側錄或惡意程式竊取的機會。

（5）集中記錄與稽核

所有登入事件可以集中記錄，包括登入時間、來源位置、使用裝置、失敗次數及存取系統，有利於異常偵測、事件調查及稽核。

（6）降低應用系統自行處理密碼的風險

各應用系統不必個別保存或驗證使用者密碼，可減少密碼資料庫外洩、弱雜湊及錯誤驗證實作等問題。

3. SSO 的安全注意事項

SSO 雖然可提高整體管理安全性，但 IdP 成為重要的信任核心。若中央帳號、SSO 權杖或 IdP 遭入侵，攻擊者可能橫向存取多個系統。

因此應搭配：

• 多因素驗證。
• 短效期權杖。
• 權杖撤銷機制。
• 最小權限原則。
• 登出與逾時控制。
• 異常登入偵測。
• IdP 高可用性及備援。

解題技巧

SSO 的安全性利益可用「少密碼、集中管、易稽核」記憶；但答題時宜補充：

SSO 並不等於所有系統自動擁有相同權限，驗證成功後仍須進行授權控管。

【答案】

SSO 是使用者向中央身分提供者完成一次身分驗證後，即可在授權範圍內存取多個應用系統。其安全性好處包括減少密碼重複使用、集中套用多因素驗證與密碼政策、集中管理帳號停權、減少密碼暴露、集中記錄稽核，以及降低各應用系統自行保存密碼所造成的風險。但 IdP 屬於關鍵信任中心，必須搭配多因素驗證、權杖保護、最小權限及異常監控。

---

（三）IPsec VPN 的作法【6 分】

1. IPsec 的定義

IPsec（Internet Protocol Security）是一組工作於網路層的安全協定，用來保護 IP 封包的機密性、完整性、來源鑑別及抗重送攻擊。

IPsec 常被用來建立 VPN，例如：

• 分公司與總公司之間的 Site-to-Site VPN。
• 遠端使用者與企業內部網路之間的 Remote Access VPN。

2. IPsec 的主要安全協定

（1）AH

AH（Authentication Header）可提供：

• 封包來源鑑別。
• 資料完整性。
• 抗重送保護。

AH 不提供資料內容加密，因此無法提供機密性。

（2）ESP

ESP（Encapsulating Security Payload）可提供：

• 資料內容加密。
• 資料完整性驗證。
• 來源鑑別。
• 抗重送保護。

實務上的 IPsec VPN 主要使用 ESP，因為 ESP 同時具備加密及完整性保護功能。

3. IPsec 的運作模式

（1）傳輸模式（Transport Mode）

只保護原 IP 封包的有效負載，原本的 IP 標頭仍保留。

適用於主機對主機的安全通信，封包結構大致為：

$$\text{原 IP 標頭}+\text{ESP/AH 標頭}+\text{加密的有效負載}$$

（2）通道模式（Tunnel Mode）

核心觀念

本題考查資訊系統安全管理中的「一般控制」與「作業控制」，目的在維持資訊資產的：

• 機密性（Confidentiality）：避免未授權存取或洩漏。
• 完整性（Integrity）：避免資料遭未授權竄改或破壞。
• 可用性（Availability）：確保系統與資料能持續提供服務。

五項安全管理可依「制度建立、系統建置、軟體變更、日常運作、媒體保護」加以區分。

本題主要考資訊安全管理觀念，並非特定法條題。若涉及法規或政府機關資安管理要求，應以命題當年（民國110年）法規為準；現行法規及資安管理規範已可能修正，但本題仍依命題當年觀念作答。

解題方法

採「定義＋管理措施＋安全目的」作答。五個項目各自說明其管理對象，再列出具體控制措施，最後指出其對機密性、完整性或可用性的作用，即可形成完整答案。

【答案】

（一）作業程序

作業程序是指為確保資訊系統作業一致、正確且可追蹤，而建立的書面化工作規範與處理流程。

主要安全管理內容如下：

1. 建立標準作業程序（SOP） 明確規定系統啟動、關機、資料輸入、資料處理、備份、異常處理及故障通報流程。

2. 落實權責分工 明確區分系統管理者、操作人員、程式設計人員、資料管理人員及稽核人員的權限，避免一人同時負責申請、核准、執行及驗證。

3. 建立作業紀錄 記錄操作人員、作業時間、處理內容、異常狀況及處理結果，以利日後追蹤與稽核。

4. 執行變更及例外管理 作業程序如有修改，應經申請、審查、核准、測試及正式發布；臨時處理也應留下完整紀錄。

5. 定期檢討與更新 系統環境、業務需求或威脅情勢改變時，應檢查程序是否仍然適用，並定期演練重大事件處理流程。

作業程序的重點是「標準化、授權化、可追蹤化」，可降低人為疏失並確保作業結果具備完整性。

（二）系統規劃

系統規劃是指在資訊系統建置或重大更新前，將安全需求納入系統生命週期及整體架構設計。

主要安全管理內容如下：

1. 進行風險評估 盤點重要資訊資產，分析可能威脅、弱點、影響程度及發生機率，決定適當的安全控制措施。

2. 將安全納入系統生命週期 在需求分析、系統設計、程式開發、測試、上線、維護及汰換等階段，均應考量資訊安全，而非等系統完成後才補強。

3. 規劃存取控制 依職務與業務需要設定身分驗證、授權、最小權限及職務分離，避免使用者取得過多權限。

4. 規劃備援與營運持續 針對重要系統設計備份、備援設備、異地備援、災難復原及復原優先順序，並訂定可接受的復原時間與資料損失程度。

5. 考量實體與環境安全 規劃機房門禁、電力、空調、消防、防水、防震及設備擺放，避免環境事故造成系統中斷。

6. 規劃測試與驗收 上線前進行功能測試、安全測試、弱點檢測及權限驗證，確認系統符合安全需求後再正式使用。

系統規劃的核心是「事前納入安全」，以風險為基礎，在成本、功能與安全之間取得適當平衡。

（三）軟體控制

軟體控制是指對系統軟體、應用程式及程式修改進行管理，以避免未授權、未測試或錯誤的軟體影響資訊安全。

主要安全管理內容如下：

1. 軟體取得與授權管理 使用合法授權軟體，建立軟體清冊，記錄版本、授權狀態、安裝位置及負責人員。

2. 程式開發與測試分離 開發、測試及正式作業環境應分離，避免尚未完成或未經測試的程式直接影響正式資料。

3. 執行程式變更管理 程式修改須提出變更申請，說明變更原因、影響範圍及回復方式，經核准後開發、測試，再由授權人員部署至正式環境。

4. 維護程式版本及基準線 保留正式版本、原始程式碼及變更紀錄，避免版本混用，並確保發生錯誤時能回復至穩定版本。

5. 進行安全測試 包括弱點掃描、程式碼檢視、權限測試、輸入驗證測試及整合測試，降低惡意程式、後門及程式漏洞風險。

核心觀念

本題考查「安全軟體開發生命週期」（Secure Software Development Life Cycle, Secure SDLC），重點在於：將資訊安全要求、風險管理與安全控制措施，整合至傳統軟體開發生命週期的每一階段，而非等到系統完成後才進行弱點掃描或滲透測試。

一般軟體開發生命週期著重功能、成本、時程與品質；Secure SDLC 則進一步確保軟體具備：

• 機密性（Confidentiality）
• 完整性（Integrity）
• 可用性（Availability）
• 身分鑑別與授權
• 稽核性與可追蹤性
• 隱私與法令遵循

本題未涉及特定法條；若涉及法規依據，應以命題當年（民國 110 年）法規為準。

解題方法

答題時可採「特性總論＋生命週期分階段活動」的方式：

1. 先說明 Secure SDLC 的基本定義。
2. 再說明它與傳統 SDLC 的差異及主要特性。
3. 依序列出各階段。
4. 每一階段同時交代一般開發工作與安全工作。
5. 強調安全活動必須持續進行，並以風險評估、測試、審查及回饋形成閉環。

常見階段可分為：

$$\text{規劃與需求} \rightarrow \text{設計} \rightarrow \text{實作} \rightarrow \text{測試與驗證} \rightarrow \text{部署} \rightarrow \text{維運} \rightarrow \text{汰換}$$

不同機關或企業的名稱可能略有差異，但核心安全活動大致相同。

（一）安全軟體開發生命週期的特性

1. 安全由全生命週期負責

Secure SDLC 將安全要求納入規劃、需求分析、系統設計、程式開發、測試、部署與維運等階段。安全不是單一部門或測試人員的責任，而是產品經理、系統分析師、架構師、開發人員、測試人員、維運人員及管理階層共同負責。

2. 強調安全內建，而非事後補救

安全控制應在系統設計初期完成，例如：

• 權限控管
• 輸入驗證
• 加密
• 日誌與稽核
• 備份與復原
• 錯誤處理
• 個人資料保護

越早發現安全問題，修正成本通常越低。因此 Secure SDLC 強調「Security by Design」及「Shift Left」，將安全活動提前至需求與設計階段。

3. 以風險為導向

依據系統資產、威脅、弱點、影響程度及發生可能性評估風險，再決定適當的安全控制措施與測試深度。有限資源應優先處理高風險功能，例如身分驗證、付款、個資處理及管理者權限。

4. 安全需求可追蹤且可驗證

安全需求必須具體、可衡量，並可追蹤至設計、程式、測試案例及驗證結果。例如：

• 需求：連續登入失敗達一定次數後鎖定帳號。
• 設計：建立帳號鎖定機制。
• 實作：撰寫登入失敗計數及鎖定程式。
• 測試：驗證超過失敗次數後確實拒絕登入。

如此可避免安全要求只停留在文件層次。

5. 設置安全審查與品質關卡

各階段均應設置審查點或核准條件，例如：

• 需求安全審查
• 威脅模型審查
• 程式碼審查
• 弱點掃描
• 滲透測試
• 上線前安全核准

若重大風險尚未降低至可接受程度，應暫緩進入下一階段。

6. 採取縱深防禦

Secure SDLC 不依賴單一安全機制，而是同時使用多層控制，例如網路分段、身分鑑別、最小權限、輸入驗證、加密、日誌監控、備份及事件通報，以降低單一控制失效所造成的影響。

7. 持續監控與持續改善

軟體上線後仍可能出現新漏洞、新型攻擊及環境變更，因此必須持續進行弱點管理、修補、日誌監控、事件回應及版本更新，並將事故與測試結果回饋至下一輪開發。

8. 重視供應鏈與第三方元件安全

現代軟體通常使用開源套件、外部 API、雲端服務及第三方程式庫，因此應管理：

• 元件版本與來源
• 已知漏洞
• 授權條件
• 依賴關係
• 軟體成分清單（Software Bill of Materials, SBOM）
• 第三方廠商安全責任

9. 符合安全政策、標準及法令

開發流程應符合組織資訊安全政策、個人資料保護要求、業務規範及適用標準，並保留風險評估、審查、測試及核准紀錄，以利稽核與責任追蹤。

（二）各階段的重點活動

1. 規劃與需求分析階段

此階段決定系統的安全目標、適用範圍及風險接受程度。

重點活動包括：

• 確認系統目的、使用者、資料類型及業務流程。
• 盤點重要資產，例如帳號資料、個人資料、交易資料及機密文件。
• 進行初步風險評估，辨識可能威脅、弱點及衝擊。
• 界定機密性、完整性、可用性及隱私需求。
• 訂定安全需求，例如：
• 身分鑑別及多因素驗證
• 角色型存取控制
• 最小權限
• 密碼政策
• 傳輸及儲存加密
• 日誌與稽核
• 備份與災難復原
• 個資遮罩及資料保存期限
• 確認法規、契約及組織政策要求。
• 建立安全需求追蹤矩陣及初步安全測試計畫。
• 決定安全責任分工、審查關卡及核准流程。

本階段的成果應包含安全需求文件、初步風險評估、資料分類及安全測試規劃。

2. 系統與安全架構設計階段

此階段將安全需求轉化為可實作的架構與控制措施。

重點活動包括：

• 設計系統整體架構、網路區隔、信任邊界及資料流。
• 建立威脅模型，分析可能的攻擊者、攻擊面、攻擊路徑及潛在影響。
• 使用資料流程圖辨識輸入點、輸出點、外部介面及敏感資料流向。
• 設計身分鑑別、授權及權限管理機制。
• 落實最小權限、職務分離及失敗預設拒絕。
• 設計加密機制、金鑰管理及憑證管理。
• 設計輸入驗證、輸出編碼、錯誤處理及例外處理。
• 設計日誌、稽核、監控、告警及事件追蹤機制。
• 規劃備份、復原、高可用性及災難復原能力。
• 審查第三方元件、外部服務及 API 的安全性。
• 進行架構安全審查，確認重大風險已有對應控制措施。

設計階段的核心是「安全設計先於程式撰寫」。若架構本身存在權限繞過、資料暴露或信任邊界錯誤，單靠後續程式碼修補通常難以徹底解決。

3. 程式實作階段

此階段依照安全設計完成程式開發，並將安全編碼要求落實於原始碼。

重點活動包括：