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

核心觀念

本題考查系統需求分析中，功能需求與非功能需求的定義、差異，以及如何將兩者具體化到企業資源規劃（ERP）系統。

• 功能需求（functional requirement）：描述系統「要提供哪些服務」及「在特定輸入或情境下應有何種行為」。通常可從使用者工作流程、業務規則、輸入輸出、資料處理與系統介面加以描述。
• 非功能需求（non-functional requirement）：描述系統「應具備何種品質或限制」，例如效能、可用性、安全性、易用性、相容性、法令遵循及維護性。它規範系統服務的品質、運作條件或實作限制，通常不是某一項特定業務功能。

非功能需求並非「不重要的需求」，也不只是技術規格；它會直接影響系統架構、開發成本、驗收標準及使用者能否有效完成工作。

解題方法

先把 ERP 的需求分成兩個問題：

1. **系統要替公司完成哪些工作？**列為功能需求，例如採購、庫存、財務、人事及跨部門資料處理。
2. **這些工作要以何種品質與條件完成？**列為非功能需求，例如回應時間、服務可用率、權限控管、備份與操作便利性。

需求應盡量寫成可檢查、可驗收的敘述。像「系統要很快」不夠明確；若能寫成「一般查詢在指定負載下於三秒內回應」，就較適合驗收。具體門檻須由大成公司與邦邦資訊公司依業務量、風險及預算協議。

（一）功能需求與非功能需求的定義

功能需求說明系統必須具備的功能與處理規則，回答「系統做什麼」。例如，使用者輸入採購單後，系統檢查品項與核准狀態、更新訂單資料，並提供後續查詢。功能需求通常可依使用者角色、使用案例、流程、資料及業務規則整理。

非功能需求說明系統服務應達到的品質，以及系統運作時必須遵守的限制，回答「系統做得如何、在什麼條件下運作」。例如，查詢要在一定時間內完成、重要服務須維持一定可用程度、敏感資料須依權限存取。非功能需求亦可稱品質需求或系統限制；常見類別包括效能、可靠性、可用性、安全性、易用性、相容性、可維護性與法規遵循。

兩者常須搭配描述。例如，「系統須提供月結功能」是功能需求；「月結須於月底批次作業期間，在指定資料量下於一小時內完成」則是效能需求。前者定義要做的工作，後者定義工作須達到的品質或限制。

（二）ERP 系統需求舉例

功能需求

1. 採購管理：建立、修改及查詢採購單；依金額或部門設定簽核流程；核准後產生訂單並追蹤交貨狀態。
2. 庫存管理：記錄各倉庫的入庫、出庫、調撥與盤點；依交易更新庫存數量；低於安全庫存量時產生補貨通知。

核心觀念

本題考查系統架構的分層，以及選擇架構時如何兼顧系統品質。三層架構是依職責劃分系統；架構選擇原則則用來評估系統在安全、服務不中斷、效能、擴充與成本等面向的需求。

解題方法

先說明三層各自負責什麼，再逐項說明五項架構原則及其設計考量。作答時要把「架構分層」與「架構選擇原則」分開：前者回答系統由哪些職責層構成，後者回答選擇架構時應達成哪些品質目標。

（一）系統架構的三層

1. 表示層（Presentation Layer） 負責與使用者或外部系統互動，例如網頁、手機 App、操作介面及 API 入口。它接收輸入、呈現結果，並將請求交給業務邏輯層處理。表示層應著重介面易用性、輸入檢核與傳輸安全，不宜承擔核心業務規則。

2. 業務邏輯層（Business Logic Layer） 負責執行系統的業務規則、流程控制、計算與驗證。例如檢查申請資格、計算費用、判斷交易是否可成立。此層接收表示層的請求，必要時呼叫資料層存取資料，再將處理結果回傳。

3. 資料層（Data Layer） 負責資料的存取、管理與持久化，例如資料庫、檔案系統或其他儲存服務。此層處理資料層面的查詢與寫入，並應維護資料完整性、存取權限及備份復原機制。

三層依序形成「呈現與輸入、業務處理、資料管理」的分工。分層可降低各部分的耦合，讓介面、業務規則或資料儲存方式能較獨立地調整。

（二）選擇系統架構的五項重要原則

1. 安全性（Security） 架構應保護資料與服務，維護機密性、完整性及可用性。

核心觀念

本題考查雲端服務的三種服務模式，以及企業採用雲端服務時應辨識的安全風險與責任分工。三種模式的差異在於雲端服務商與客戶各自管理的技術層級不同：

• IaaS（基礎設施即服務）：服務商提供運算、儲存、網路等基礎資源；客戶通常仍負責作業系統、應用程式、資料與身分權限管理。
• PaaS（平台即服務）：服務商除基礎設施外，也管理作業系統、執行環境與平台；客戶主要負責部署的應用程式、資料及其存取權限。
• SaaS（軟體即服務）：服務商提供可直接使用的應用軟體，並管理大部分底層環境；客戶仍須妥善管理帳號、權限、資料與使用設定。

雲端服務的安全責任不會因服務商代管而完全轉移。企業應依服務模式確認責任分界，並以資料、身分與存取管理、系統組態、服務持續性及供應商管理等面向評估風險。

解題方法

可依「服務模式 → 客戶控制範圍 → 對應安全問題」作答。先指出三種模式各自由服務商管理哪些層級，再說明企業仍須處理的風險；最後補充各模式共同面對的資料保護、可用性、法遵與委外管理議題。如此可避免只列出一般資安名詞，卻未回答 IaaS、PaaS、SaaS 的差異。

IaaS 的安全問題

IaaS 提供的主要是虛擬化運算、儲存與網路資源，企業仍有較大的系統管理責任，須注意：

• 虛擬化與多租戶隔離：確認不同租戶的運算、儲存及網路資源能有效隔離，避免跨租戶存取或虛擬機逃逸等風險。
• 作業系統與主機安全：客戶須負責作業系統的安全設定、修補更新、防毒與惡意程式防護、主機防火牆及弱點管理。
• 網路組態與暴露面：妥善設定虛擬網路、路由、防火牆、存取控制清單及對外服務；錯誤組態可能使主機或儲存服務暴露於公開網路。
• 映像檔與虛擬機管理：控管映像檔來源、完整性及存取權限，並安全管理快照、備份與退役資源，避免其中的機敏資料遭未授權取得。
• 管理介面與權限：雲端管理主控台具有高度權限，應實施多因素驗證、最小權限、權限分工及操作稽核。

PaaS 的安全問題

PaaS 由服務商管理較多底層平台，企業可專注於應用程式開發與部署，但仍須注意：

• 應用程式弱點：程式可能存在輸入驗證不足、注入攻擊、身分驗證缺陷或不安全的 API；應在開發與部署流程中進行程式碼檢查、弱點掃描及安全測試。
• 平台設定與版本管理：確認執行環境、函式庫、框架及平台版本的更新與支援狀態，避免使用已知有漏洞或停止支援的元件。
• 租戶隔離與執行環境安全：確認服務商如何隔離租戶應用程式、保護執行環境及處理共用資源，並了解重大事件的通報與處置方式。

核心觀念

本題考查資料庫安全的三個面向：預防、偵查與管理。金融交易資料量大且攸關財務正確性，安全目標不只有防止未授權存取，也須維持資料的機密性、完整性與可用性，並能在當機或交易失敗後復原。

題目沒有要求特定法條或計算公式；作答重點是依「事前降低風險、事中及時發現、事後妥善管理與復原」組織措施，並呼應交易資料不一致的情境。

解題方法

先把題目情境拆成兩類風險：

• 當機、交易失敗：涉及資料庫可用性，以及故障後的復原能力。
• 交易資料不一致：涉及資料完整性，以及交易處理是否具備正確的控制與紀錄。

接著分別從預防、偵查與管理提出控制措施。作答時應兼顧資料庫本身、應用程式、作業流程與人員權限，才能形成完整的安全管理架構。

一、預防：降低事故發生與資料受損的機率

1. 權限控管與職務分離 採最小權限原則，依職務授予查詢、寫入、修改或刪除權限；避免共用帳號，並將資料庫管理、程式部署與交易核准等職責適度分離。管理者帳號應採多因素驗證，並限制可登入的主機與網路來源。

2. 交易完整性控制 資料庫交易應具備 ACID 特性：原子性、一致性、隔離性與持久性。交易的多個步驟必須整體成功或整體回復，避免只完成部分更新而造成帳務不一致。另應透過主鍵、外鍵、唯一性與檢核條件等約束，阻擋不合法或彼此矛盾的資料。

3. 系統與資料庫變更管理 新系統上線前應進行功能、負載、壓力、故障復原及資料轉換測試；程式與資料庫結構變更須經審核、測試與核准，並保留回復版本的能力。上線過程宜規劃分階段導入與回復方案，降低大規模故障的影響。

4. 修補、設定與網路防護 定期更新資料庫與作業系統修補程式，停用不必要的服務及預設帳號，強化組態設定。限制資料庫對外連線，使用防火牆及網段隔離，並對敏感資料採加密傳輸與加密儲存。

5. 備份與容錯設計 定期備份資料庫、交易紀錄與必要的系統設定，將備份與正式環境適度隔離，防止同一事故同時損及兩者。可依服務需求採用複寫、備援主機或高可用架構，降低單點故障造成的停機時間；並設定合理的復原時間目標（RTO）與復原點目標（RPO）。

二、偵查：及早發現異常與資料不一致

1. 稽核與存取紀錄 記錄資料庫登入、權限異動、資料查詢與修改、管理者操作及結構變更。紀錄須包含時間、帳號、來源與操作結果，並限制一般管理者任意刪改，以利追查責任與事件經過。