112 專技高考高等考試 資訊技師 系統分析與資訊安全 考古題詳解

核心觀念

本題考查 ISO/IEC 27005 的資訊安全風險管理流程，以及風險評估後如何選擇風險處置方式。風險管理的目的，是在組織可接受的風險準則下，辨識並評估資訊安全風險，再決定如何處理及持續監督。

解題方法

第一小題依風險管理流程，按「建立情境、評估風險、處置風險、接受風險、溝通與諮詢、監督與審查」說明各階段工作。第二小題則從風險處置對風險的影響，區分降低、避免、移轉與接受四種策略，並分別舉例。

（一）ISO 27005 資訊安全風險管理的五個階段及工作重點

ISO 27005 的流程圖常以五個階段呈現：建立情境、風險評估、風險處置、風險接受、風險溝通與諮詢、監督與審查。因而實際作答時，可將風險溝通與監督審查視為貫穿全程的工作，並將中間四個主要步驟整理成題目所稱的五階段架構：

1. 建立情境（Context Establishment） 確認風險管理的範圍、目標與內外部條件，包括組織任務、法規要求、資訊資產、利害關係人及其需求。並制定風險評估準則，例如風險可能性與衝擊的分級方式，以及組織可接受風險的門檻。

2. 風險評估（Risk Assessment） 依建立的情境進行風險識別、風險分析與風險評估。辨識資訊資產、威脅、弱點及可能造成的後果；分析威脅利用弱點的可能性與對機密性、完整性、可用性的衝擊；再依風險準則判斷風險等級及優先順序。

3. 風險處置（Risk Treatment） 對高於可接受門檻的風險選擇適當處置方式，規劃控制措施、負責人、資源及完成期限。完成處置計畫後，應評估控制措施實施後的剩餘風險，確認是否已降至可接受程度。

4. 風險接受（Risk Acceptance） 由有權責者依組織的風險接受準則，正式接受處置後的剩餘風險。接受決定應有紀錄，並明確指出接受的風險、理由、核准者與後續檢視時點；不能僅因缺乏資源，就把未處理的風險視為已接受。

核心觀念

本題考查零信任架構（Zero Trust Architecture, ZTA）的定義、建置目的、核心原則，以及它與傳統以網路邊界為主的防禦模式有何不同。作答時可依序說明「信任假設如何改變、如何決定存取、如何降低入侵後的影響」。

零信任的基本精神是「永不預設信任，持續驗證」（Never trust, always verify）。使用者、裝置、應用程式或網路流量，無論位於組織內網或外部，都不因其所在位置而自動取得信任。每次存取特定資源前，都須依身分、裝置狀態、情境與安全政策進行判斷。

ZTA 是依循零信任原則設計的企業資安架構與運作方式，重點在保護資源，而非單純保護一段網路。資源包括資料、應用程式、服務及運算資源。它不是單一產品，也不代表取消所有網路邊界設備；組織可將既有控制措施整合進架構，逐步落實零信任。

解題方法

本題是申論題，沒有計算或選項。作答可分成四層：

1. 定義：指出不因內外網位置而預設信任，存取需經驗證與政策判斷。
2. 目的：說明保護資源、降低資料外洩及未授權存取風險，並限制入侵後的橫向移動。
3. 核心原則：列出驗證、最小權限、持續監控、動態政策及假設可能遭入侵等原則。
4. 架構比較：比較信任基礎、存取範圍、驗證方式及入侵後的影響。

ZTA 的目的

ZTA 的主要目的，是在使用者、裝置與資源分散於內網、雲端、遠端辦公等環境時，仍能以一致的方式管控資源存取。其安全目標包括：

• 保護重要資源：將存取控制直接套用於資料、應用程式與服務，不只依賴網路邊界。
• 降低未授權存取與資料外洩風險：每次存取都依身分及情境核准，縮小憑證遭竊或帳號遭濫用時的影響。
• 限制入侵後的擴散：以資源層級的細緻控管及網路分段，減少攻擊者在系統間橫向移動。
• 因應混合與分散式環境：無論使用者在辦公室、遠端或雲端，均依安全政策進行存取決策。

ZTA 的核心原則

1. 不因位置而信任：內網、外網及雲端環境都不構成自動信任的依據；內部網路中的使用者或裝置也必須接受驗證。
2. 驗證使用者與裝置：存取前評估使用者身分、裝置識別與安全狀態，並可納入所在地點、時間、行為或資源敏感度等情境資訊。
3. 實施最小權限：只授予完成工作所需的資源與權限，並限制存取範圍與有效期間；避免以廣泛的網路連線權限取代資源層級授權。

核心觀念

本題考查敏捷開發中 CI/CD 的定義、運作特性與導入挑戰。CI/CD 不是單一工具，而是一組自動化的軟體開發與交付實踐，目標是縮短從程式碼變更到可用軟體的時間，並以頻繁驗證降低整合與發布風險。

• 持續整合（Continuous Integration, CI）：開發者頻繁將程式碼變更合併至共用程式碼庫；每次變更都由自動化流程建置並執行測試，及早發現整合錯誤。
• 持續交付（Continuous Delivery, CD）：在 CI 基礎上，將通過驗證的軟體自動整理成可發布版本，並維持在可部署狀態；正式上線通常仍由人員決定或核准。
• 持續部署（Continuous Deployment, CD）：將通過自動化驗證的變更進一步自動部署至正式環境，不需每次另行人工核准。

「持續交付」與「持續部署」常共用縮寫 CD，差異在於正式環境部署是否自動進行。

解題方法

依題目要求分成三部分作答：先界定 CI/CD，再說明其對開發與交付流程的影響，最後指出導入後的成本、風險與管理挑戰。作答時須區分 CI、持續交付及持續部署，並避免將 CI/CD 說成「只要自動部署就算完成」。

CI/CD 的特性

1. 頻繁整合與小批次變更：開發者常將較小的程式碼變更合併至共用版本庫，降低長時間分支造成的整合衝突。
2. 自動化建置與測試：程式碼提交後，自動進行編譯、單元測試、整合測試及其他品質檢查，迅速回饋問題。
3. 流程可重複且可追蹤：以管線（pipeline）管理建置、測試、封裝與部署步驟，提升交付的一致性，也便於追蹤變更紀錄。
4. 快速且頻繁地交付：通過驗證的版本可快速進入測試或正式環境，縮短發布週期，讓團隊更快回應使用者需求。
5. 提早發現問題並降低變更風險：小幅變更搭配持續驗證，通常較容易定位錯誤來源；若搭配監控與回復機制，也可縮短故障影響時間。
6. 跨職能協作：開發、測試、維運及資安人員需共同維護交付流程，使軟體品質、部署與營運需求能在開發過程中一併考量。

核心觀念

SMART 是設定專案目標的原則，協助團隊把抽象願望轉成清楚、可執行且可驗收的目標。SMART 五個字母通常代表：

• S（Specific，明確具體）：說明要完成什麼、範圍為何、由誰負責，避免目標含糊。
• M（Measurable，可衡量）：設定量化指標或明確驗收條件，據以追蹤進度與判斷成果。
• A（Achievable，可達成）：目標須考量預算、人力、技術與時程，在資源限制下合理可行。
• R（Relevant，具相關性）：目標須符合專案目的、組織需求及利害關係人的期待。
• T（Time-bound，有時限）：設定完成期限或階段里程碑，避免工作無限期延伸。

本題要將這五項原則套用到「開發線上訂單管理系統」，說明專案目標如何從抽象描述具體化。

解題方法

以一項完整的專案目標為主軸，再逐項指出它如何符合 SMART。範例需同時交代系統範圍、量化驗收標準、可行性、專案價值與完成期限；如此才能清楚呈現五項原則，而不是只列出英文全名。

範例說明

假設某企業要改善人工處理訂單的效率，可設定以下專案目標：

於民國 113 年 6 月 30 日前完成線上訂單管理系統的開發與驗收，提供顧客下單、查詢訂單狀態、取消訂單，以及管理人員查詢與更新訂單等功能；系統正式上線後，至少 95% 的訂單可在 3 秒內完成送出，且試營運期間訂單資料正確率達 99% 以上。

這項目標符合 SMART 的方式如下：

• S（明確具體）：明列顧客與管理人員的使用功能，包括下單、查詢、取消及更新訂單，界定了系統的核心範圍。