114 公務人員升官等薦任 資訊處理 資訊系統與分析 考古題詳解

（一）SSDLC 與傳統 SDLC 的差異，以及納入安全需求的原因

核心觀念

傳統軟體發展生命週期（SDLC）通常依序進行需求分析、系統設計、程式開發、測試、部署與維護，主要目標是完成系統功能、品質、成本與時程要求。安全軟體發展生命週期（SSDLC）則是在各階段同步納入安全需求、風險評估、安全設計、安全測試及持續改善，使安全成為軟體品質的一部分，而非開發完成後才補做的檢查。

兩者的主要差異如下：

解題方法

作答時可先比較「安全何時介入」，再說明「為何必須早期納入」，最後連結資訊安全的機密性、完整性與可用性（CIA）目標。安全需求並非只有防止駭客入侵，也包括身分驗證、授權、個人資料保護、稽核、備援及復原等控制。

SSDLC 必須納入安全需求的理由

1. 降低事後修補成本：設計階段若未考量安全，常須大幅修改架構、資料流程或權限設計；及早發現與處理通常較有效率。
2. 降低弱點與事件風險：不安全的輸入處理、權限設定或資料儲存方式，可能導致未授權存取、資料外洩、竄改或服務中斷。
3. 保護資訊安全目標：以身分驗證、最小權限、加密、完整性檢查、備援及復原機制，維護機密性、完整性與可用性。
4. 滿足法規與契約責任：政府機關及受規範組織須依適用法規、主管機關要求及契約義務，落實資通安全管理與個人資料保護。
5. 提升可稽核性與信任：明確記錄安全需求、風險決策、測試結果及核准紀錄，便於內部稽核、主管機關查核及事故追溯。

解題技巧

可用「早期納入、全程管理、風險導向、留下證據」概括 SSDLC。常見失分點是只列舉滲透測試或弱點掃描；這些屬於技術措施，並不能取代需求、設計與治理階段的安全管理。

（二）SSDLC 安全治理模型

核心觀念

完整的 SSDLC 治理可用「政策（Policy）—流程（Process）—技術（Technology）」三個面向建立，並以風險管理及持續改善串接。政策訂出治理責任與最低要求；流程將要求落實到生命週期；技術控制協助執行與驗證。三者均須留下可供稽核的紀錄。

題目提及 ISO 27001 與《資通安全管理法》，作答應說明如何把適用要求轉化為專案的安全控制與證據，而非僅列出法規或標準名稱。

解題方法：建立三層治理模型

一、政策（Policy）：建立責任、原則與最低要求

1. 制定安全開發政策：由機關或組織管理階層核定 SSDLC 政策，要求所有自行開發、委外建置及重大變更系統均納入安全管理。
2. 明定角色與權責：指定系統負責人、業務單位、開發與維運團隊、資安人員及稽核人員的責任；重要安全例外應有風險評估、核准與期限。
3. 依系統風險分級：依資料敏感度、系統重要性、服務影響及法規要求，決定安全審查、測試深度與核准層級。
4. 建立安全基準：訂定身分驗證、存取控制、加密、日誌保存、弱點修補、備份、委外管理及安全測試等最低要求。

核心觀念

本題考查如何在 SDLC 的需求規劃階段，將零信任安全原則轉化為可追蹤、可驗證的隱私需求。重點不是等系統上線後再補強，而是在決定系統目的、資料範圍、使用者角色與資料流程時，就把個資法遵及隱私保護納入設計。

零信任（Zero Trust）的核心是「永不預設信任，持續驗證」。系統不因使用者已登入、位於內部網路或使用受管設備，就自動信任其存取；每次存取都應依身分、權限、裝置狀態、情境與資料敏感度評估，並只授予完成任務所需的最低權限。

題目涉及的隱私與個資保護原則如下：

• 我國個人資料保護法：以命題當年（民國 114 年）法規為準。第 5 條要求個人資料之蒐集、處理及利用不得逾越特定目的之必要範圍，並須與蒐集目的具有正當合理關聯；第 3 條保障當事人查詢、閱覽、製給複製本、補充、更正、停止蒐集處理利用及刪除等權利；第 8 條規範直接向當事人蒐集資料時的告知事項；第 11 條規範資料正確性及目的消失或期限屆滿後的刪除或停止處理利用；第 12 條涉及個資遭侵害時的通知義務。安全維護方面，第 18 條規範公務機關安全維護事項，第 27 條則是命題年度適用的非公務機關安全維護依據。
• GDPR：第 5 條規定合法、公平、透明、目的限制、資料最小化、正確性、保存限制、完整性與機密性，以及控制者的責任；第 25 條要求資料保護設計及預設保護；第 32 條要求適當的處理安全措施；第 35 條要求在處理可能對個人權利與自由造成高風險時進行資料保護影響評估（DPIA）。

法規時間補充：個人資料保護法於民國 114 年 11 月 11 日另有修正，其中部分條文的施行日期由行政院另定；考試作答仍應依命題當年適用規定說明。修法後相關條文編排與內容已有調整，引用本文所列條次時應以民國 114 年命題時適用版本為準。

解題方法

可依「先盤點法遵義務，再將義務轉成需求，最後以零信任措施落實並留下驗證證據」作答。需求規劃階段應完成下列工作：

1. 界定處理目的與法遵範圍 盤點系統蒐集、處理、利用及跨境傳輸個資的目的、法律依據、適用對象與責任分工。逐項確認資料用途是否有正當依據，並確認符合個資法的特定目的及必要範圍，以及 GDPR 的合法性、目的限制與透明原則。不可只以「使用者同意」概括取代合法性分析。

2. 建立資料清冊與資料流程圖 盤點資料類別、來源、蒐集方式、使用者、系統介接、接收對象、儲存位置、保存期限及刪除方式；特別標示敏感個資、跨境傳輸及委外處理。以資料流程圖找出每一處蒐集、讀取、傳送、複製、分析與刪除節點，作為權限、稽核及風險評估的依據。

3. 落實資料最小化與預設隱私 每個欄位與資料用途都須有明確目的及必要性；不必要的欄位不得蒐集，非必要功能不得預設啟用。需求中明定去識別化或假名化、遮罩顯示、限制匯出，以及依保存期限自動刪除或封存。這同時對應個資法第 5 條及 GDPR 第 5、25 條。

4. 以零信任方式定義身分與存取需求 先定義使用者、管理者、維運人員、委外廠商及服務帳號等角色，再依工作職責採最小權限及角色或屬性式存取控制。

（一）軟體物料清單（SBOM）的定義與核心觀念

核心觀念

軟體物料清單（Software Bill of Materials, SBOM）是描述一個軟體產品所使用之軟體元件及其相依關係的正式清單，可視為軟體的「成分表」。它通常記錄元件名稱、版本、供應者、唯一識別資訊、相依關係，以及元件的來源或授權資訊等。

SBOM 涵蓋的對象包括直接納入軟體的開源或商用元件，也應呈現可識別的間接相依元件。透過 SBOM，開發及維運人員能掌握軟體的組成，並在元件發現漏洞、授權風險或供應鏈問題時，迅速判斷哪些產品受到影響。

SBOM 本身是軟體組成資訊的清單，不等同於安全認證，也不會自行保證元件沒有漏洞；必須搭配來源驗證、弱點掃描及持續管理，才能形成有效的供應鏈安全措施。

常見欄位與格式

一份實用的 SBOM 通常包含：

• 元件識別資料：元件名稱、版本、供應者及唯一識別資訊。
• 元件關係：元件的直接及間接相依關係。
• 來源與完整性資料：下載來源、檔案雜湊值等，可用於比對實際取得的元件。
• 授權及維護資訊：授權類型、維護狀態或已知安全資訊。

常見的 SBOM 交換格式包括 SPDX 與 CycloneDX。格式的用途是讓工具與組織能一致產生、交換和分析元件資訊。

（二）在系統建置階段結合 SBOM 與零信任

核心觀念

零信任的原則是「不因網路位置或既有身分而預設信任，必須持續驗證」。應用於軟體建置時，不能只因元件來自知名套件庫，或已被專案使用，就直接允許它進入正式部署；必須驗證元件身分、來源、完整性與安全狀態，並依明確政策決定是否放行。

解題方法

可將流程設計成部署前的供應鏈檢查關卡，依序回答三個問題：

1. 清單是否完整且與交付物相符？
2. 元件是否來自可信來源，且未遭竄改？
3. 元件是否符合漏洞及組織安全政策？

通過檢查後才允許部署；未通過者須阻擋、隔離或修補後重新驗證。

建置與部署流程

核心觀念

本題考查軟體測試的兩種觀點：黑箱測試依據需求與規格檢查系統輸入和輸出；白箱測試依據程式內部結構檢查控制流程與程式邏輯。主要差異在於測試者是否需要知道程式內部如何實作。

解題方法

作答時可從「測試依據、是否檢視程式碼、測試目的、適用情境」四個面向比較，再分別說明兩種方法適用的開發階段與測試目標。

黑箱測試：定義與適用情境

黑箱測試又稱功能測試，測試者不以程式碼或內部設計為依據，而是依照需求規格提供輸入，再檢查系統輸出、錯誤訊息或外部行為是否符合預期。測試者通常不必知道功能由哪些模組或演算法實作。

適合用於：

• 確認功能需求是否滿足：例如輸入有效帳號與密碼後，系統是否正確登入；輸入錯誤密碼時，是否依規格顯示訊息。
• 系統測試與驗收測試：從使用者或客戶角度確認整體功能、介面及業務流程是否符合規格。
• 測試輸入範圍與規則：可用等價分割將輸入分成有效與無效類別，或以邊界值分析檢查上下限。例如欄位允許 $1$ 至 $100$，可測試 $0$、$1$、$100$、$101$。
• 測試者無法取得程式碼時：例如委外系統驗收或由獨立測試團隊依規格執行測試。