112 調查局特考三等 資訊科學組 系統分析與設計 考古題詳解

核心觀念

本題考查安全軟體設計的基本原則，重點是以簡單、可靠、分層且權限受限的設計，降低系統遭受攻擊或發生安全失誤時的影響。題目沒有涉及特定法條，作答時應逐一說明各原則的設計意涵及其在系統開發中的實踐方式。

解題方法

可將五項原則依序整理為：縮小機制複雜度、善用可信元件、建立多層防護、失敗時維持安全、限制使用者權限。每項先說明核心要求，再補充一個系統設計上的例子，即可清楚呈現原則意義。

各原則說明

（一）Economy of Mechanism：機制經濟原則

安全機制應保持簡單、精簡，避免不必要的功能、複雜流程或過多元件。機制愈複雜，愈難以完整理解、檢查與測試，也愈容易產生漏洞或設定錯誤。

例如，設計市府系統的身分驗證與存取控制時，應採用清楚一致的驗證流程，避免各模組自行建立互不相同的權限判斷方式，以利維護及安全稽核。

（二）Leveraging Existing Components：元件槓桿原則

優先運用經過驗證、維護良好且符合需求的既有安全元件或服務，例如成熟的身分驗證機制、加密函式庫或權限管理元件，而非自行重複開發已有可靠方案的功能。

既有元件可減少重複造輪子的風險，也能利用其累積的測試與安全修補成果。不過，採用前仍須確認元件來源可信、版本受支援、設定正確，並符合專案的安全需求；直接套用未維護或未經檢視的元件，並不符合此原則。

（三）Defense in Depth：縱深防禦原則

系統應設置多層、彼此補充的安全防護，使單一防線遭突破時，其他防線仍能阻止攻擊或降低損害。不能假設某一道控制措施永遠不會失效。

核心觀念

本題考查安全軟體發展生命週期（Secure Software Development Life Cycle, SSDLC）的目的，以及如何在傳統軟體發展生命週期（SDLC）的各階段納入安全活動。

傳統 SDLC 的主要工作是確認需求、設計與建置系統，安全性常被當成開發後期的測試或修補工作。SSDLC 則把安全視為全生命週期的品質要求：從需求與設計階段開始辨識威脅、制定安全控制，並在實作、測試、部署及維運階段持續驗證和改進。

（一）客戶要求採用 SSDLC 的原因

1. 及早降低風險與修補成本 若在需求或設計階段發現權限控管不足、資料保護不完整等問題，通常比系統上線後才補救容易且成本較低。SSDLC 將安全檢查前移，降低缺陷累積至後期的風險。

2. 保護政府資料與服務 政府系統可能處理個人資料、機敏資訊或重要公共服務。SSDLC 有助於維護機密性、完整性與可用性，降低資料外洩、未授權竄改、服務中斷等風險。

3. 因應威脅與攻擊面 系統可能面臨身分冒用、注入攻擊、弱密碼、設定錯誤、供應鏈漏洞等威脅。SSDLC 要求在開發過程中辨識威脅並驗證防護措施，而非只在交付前進行一般功能測試。

4. 滿足法規、政策與契約要求 政府機關須依適用的資通安全、個人資料保護及採購規範管理系統風險。採用 SSDLC 能留下需求、風險評估、測試及修補紀錄，作為治理與稽核的證據。本題未指定特定法條，不涉及法條計算；如援引法規，應以命題當年（民國 112 年）法規為準。

5. 提升系統品質與可維護性 安全需求若在設計時納入，可減少後續大幅修改，也能透過安全基準、程式碼檢查、漏洞管理及更新程序，讓系統在維運期間持續保持適當防護。

（二）在 SDLC 各階段納入安全性

核心觀念

本題考的是軟體專案的需求變更管理。需求一旦核准並納入基準，後續變更就必須經過正式程序，評估影響、取得適當核准，並更新相關文件與計畫。變更管理的目的不是拒絕客戶，而是確保變更經過評估、決策與追蹤，避免未評估的要求直接進入開發，造成範圍蔓延、成本超支、時程延誤或品質下降。

本題不涉及特定法條；應以系統分析與設計、軟體專案管理中的變更控制原則作答。

（一）為何不能直接照老闆的意思變更

老闆提出的要求會改變原先的點餐與計價規則：客人必須先點一份基本鹹粥，才能加點魚肚、魚腸等單品。這不只是畫面或文字的小修改，也可能影響需求、系統功能、資料設計、測試與交付範圍，因此不能僅憑提出者是出資者，就直接視為已核准的系統需求。

主要理由如下：

1. 變更可能超出已核准的範圍基準 原專案規劃採各品項分別計價；新規則增加「基本鹹粥為加點前提」的限制，屬於需求與業務規則的變更，應更新需求文件及相關基準。

2. 必須評估對成本、時程與資源的影響 新規則可能需要修改菜單資料、購物車邏輯、價格計算、訂單驗證及管理功能，也可能增加開發與測試工作。未先估算就承諾，容易造成預算或交期失控。

3. 必須檢查對其他需求與系統元件的影響 例如客人能否取消基本鹹粥、基本品項是否有多種選擇、加點品項能否單獨退訂、外送平台或報表如何呈現等。若只修改下單畫面，可能造成訂單資料、結帳金額或後台作業不一致。

4. 避免未受控的範圍蔓延 若每次口頭要求都直接開發，專案範圍會不斷增加，團隊難以確認哪些功能已承諾，也無法有效控管成本、時程及品質。

5. 確保決策與責任可追蹤 正式紀錄變更內容、提出者、評估結果與核准者，可作為後續開發、驗收及爭議處理的依據。老闆是重要利害關係人，但仍應依專案既定的變更權責與核准流程處理。

因此，專案人員應尊重並記錄客戶需求，但在完成影響分析及核准前，不應直接把它當成已納入基準的工作執行。

（二）建議的需求變更程序

可依下列步驟執行，並以專案既定的變更管理計畫及核准權責為準：

核心觀念

本題考查機關如何管控遠端存取，以避免未經授權者透過外部連線進入機關內部網路或資通系統。答題應涵蓋「事前授權與規範、身分與權限控管、連線加密、來源限制、連線監控與紀錄」等面向。

法規依據為《資通安全責任等級分級辦法》附表十「資通系統防護基準」的遠端存取控制措施。**以下以命題當年（民國 112 年）法規為準。**其基本要求是：遠端存取類型須事先取得授權，訂定使用限制、組態需求與連線需求並留存文件；使用者權限檢查應在伺服器端完成。依系統防護需求等級，另須監控遠端連線、採用加密機制，並限制遠端存取來源為機關預先定義及管理的存取控制點。

解題方法與措施說明

可依遠端連線的生命週期作答：先規範誰能連、從哪裡連及能做什麼，再保護連線過程，最後監測並保存紀錄。具體措施如下：

1. 事前核准並建立遠端存取規範 每一種允許的遠端存取類型均應事先取得授權，明定使用目的、適用人員、可存取的系統與資源、使用時段、連線條件及組態要求，並將規範文件化。遠端維護或委外廠商連線也應納入相同的核准與管理流程。

2. 管理帳號、驗證身分並落實最小權限 建立帳號申請、開通、停用及刪除程序，確認使用者身分與授權範圍。權限檢查應在伺服器端完成，並只授予完成工作所需的最低權限；臨時或維護帳號應有明確期限，任務完成後即停用或刪除。可透過多因素驗證強化遠端登入的身分確認。

3. 限制遠端連線來源與通道 僅允許從機關預先定義並管理的存取控制點連線，例如核准的 VPN 閘道或跳板主機；