110 高普考高考三級 資訊處理 資訊管理與資通安全 考古題詳解

核心觀念

以命題當年（民國 110 年）法規為準，依《資通安全事件通報及應變辦法》第 3 條，通報要讓受通報機關掌握「誰發生、何時發生、發生什麼事、事件多嚴重、已做什麼處置，以及還需要什麼協助」。通報內容應包括七項：

1. 發生機關：發生資安事件的機關名稱。
2. 發生或知悉時間：事件實際發生時間，或機關知悉事件的時間。
3. 狀況之描述：事件現象、受影響的資訊或系統、影響範圍等。
4. 等級之評估：依事件造成的資訊洩漏、竄改或系統運作影響等情形，評估事件等級。
5. 因應事件所採取之措施：已採取的隔離、阻斷、修復或其他應變處置。
6. 外部支援需求評估：評估是否需要外部技術、人力或其他協助。
7. 其他相關事項：補充有助於了解與處理事件的資訊。

解題方法

本小題是法條列舉題，作答時依第 3 條完整列出七項，再用簡短文字說明各項所要交代的資訊。注意題目問的是「通報內容」，不是機關應訂定的通報作業規範，也不是事件發生後的應變報告。

（二）公務機關資通安全事件之通報及應變流程

核心觀念

依命題當年《資通安全事件通報及應變辦法》第 4 條至第 7 條，流程涵蓋：知悉事件後通報、主管機關審核等級、完成損害控制或復原、後續調查改善，以及必要時召開會議與尋求支援。應特別記住時限：一小時通報、依級別於 72 或 36 小時內完成損害控制或復原、一個月內送交調查處理及改善報告。

解題方法與流程

1. 知悉事件並評估等級 公務機關知悉事件後，先依事件影響評估等級，並彙整第 3 條所列通報資料。

2. 於一小時內通報 知悉事件後，應於 一小時內依主管機關指定的方式及對象通報。事件等級變更時，須依相同規定續行通報。若因故無法依指定方式通報，應在原定時限內改以其他適當方式通報，並註明原因；障礙解除後，再依指定方式補行通報。

3. 主管機關審核事件等級 主管機關於接獲通報後，應完成等級審核，並得依審核結果變更等級：

• 第一級或第二級：於接獲後 八小時內完成審核。

核心觀念

雜湊函數（Hash Function）是將任意長度的輸入資料，經運算轉換成固定長度輸出值的函數，輸出稱為雜湊值（Hash Value）、摘要（Digest）或訊息摘要。可表示為：

其中 $m$ 是原始訊息，$H$ 是雜湊函數，$h$ 是固定長度的摘要。

安全雜湊函數具備下列特性：

1. 確定性：相同輸入必定產生相同雜湊值。
2. 定長輸出：輸入長度不同，輸出長度仍固定。
3. 單向性（抗原像性）：已知 $h$，難以找出 $m$ 使 $H(m)=h$。
4. 抗第二原像性：已知 $m_1$，難以找出 $m_2\ne m_1$，使 $H(m_1)=H(m_2)$。
5. 抗碰撞性：難以找出任意兩個不同輸入 $m_1,m_2$，使 $H(m_1)=H(m_2)$。
6. 雪崩效應：輸入即使只有少量位元不同，輸出也會有大量位元改變。

雜湊函數本身不使用密鑰，因此一般不具備加密的可逆性，也不能單獨證明資料是由特定人士傳送。實務上可用於檔案完整性檢查、密碼驗證，以及搭配數位簽章或 HMAC 提供安全服務。

常見演算法

密碼儲存不宜直接使用一般快速雜湊函數（如 SHA-256）處理，應採用專為密碼設計的慢速雜湊或金鑰衍生機制，例如 Argon2、bcrypt、scrypt 或 PBKDF2，並搭配每筆密碼獨立的 salt，以提高暴力破解成本。

解題方法

作答時先定義「任意長度輸入轉成固定長度摘要」，再列出安全性特性，最後以 MD5、SHA-1、SHA-2、SHA-3 說明常見演算法，並補充雜湊函數的應用與限制。如此可同時涵蓋定義、特性、演算法及實務用途。

解題技巧與常見陷阱

• 雜湊是單向摘要，不是可逆加密；不要把「雜湊」與「加密」混為一談。
• 雜湊值可用來檢查資料是否改變，但單獨使用不等於身分驗證；若需驗證訊息來源，可使用 HMAC 或數位簽章。

核心觀念

本題考查微型服務（Microservices）的架構特性，以及這種架構相較於單體式架構所帶來的管理與技術優勢。微型服務將應用程式拆分為多個小型、可獨立部署的服務；各服務負責特定業務能力，透過輕量化機制（如 API）互相溝通。設計重點在於服務邊界清楚、服務間鬆散耦合，並讓各服務能獨立發展與運作。

解題方法

作答時先說明「微型服務如何組成」，整理出服務規模、業務責任、部署與溝通方式等特性；再由「服務可獨立」推導優勢，例如可獨立部署、擴充、選用技術及降低變更影響。題目配分顯示第二小題比重較高，應列出多項優勢並逐項解釋，避免只寫名詞。

（一）微型服務的特性（6 分）

1. 小型且聚焦於單一業務能力：系統由多個服務組成，每個服務負責明確的業務功能，服務範圍以能獨立理解、開發和維護為原則。
2. 服務邊界清楚、鬆散耦合：各服務透過明確介面交換資料，避免直接依賴其他服務的內部實作；服務內部則可維持較高的內聚性。
3. 可獨立部署與執行：服務通常能個別建置、測試、發布及執行，一個服務的改版不必然要求整個系統同時重新部署。
4. 以輕量化通訊協作：服務透過 API、HTTP 或訊息傳遞等方式溝通，介面契約是服務間協作的重要依據。
5. 資料與業務邏輯由服務負責：各服務對其負責的業務資料及規則具有一定自主性，避免所有服務緊密依賴同一套內部資料結構。
6. 支援多種技術與平台：不同服務可依需求採用不同的程式語言、框架或資料儲存方式，但仍須遵守共同的介面及營運規範。

（二）微型服務的優勢（24 分）

1. 可獨立部署，縮短發布週期：修改單一服務時，可針對該服務進行建置、測試及發布，不必每次都重新部署整個大型系統，因而能更頻繁地交付功能。
2. 可獨立擴充，提升資源使用效率：負載集中在特定服務時，只需增加該服務的執行個體或資源；不必連同使用量較低的其他功能一起擴充，能依需求配置運算資源。
3. 降低變更的影響範圍：服務邊界與介面清楚時，局部修改通常集中在相關服務，較不容易牽動整個應用程式；故障或變更的影響也較容易限制在特定範圍。

核心觀念

本題考查資訊系統風險評鑑中的三個相連階段：風險識別找出風險由何而來；風險估計衡量資產價值、事故可能性與風險大小；風險評估則依風險準則判定風險是否可接受，並決定後續處理的優先順序。

以下依命題時常用的資訊系統風險評鑑作法說明：風險分析包含風險識別與風險估計，風險評估則將分析結果與組織的風險準則比較。

（一）風險識別及其步驟

**定義：**風險識別是有系統地找出資訊資產可能面臨的威脅、弱點、既有控制措施，以及事故發生後可能對組織造成的後果。目的在釐清風險來源與風險情境，作為後續估計及評估的基礎。

步驟：

1. 資產識別 依資訊系統所支援的業務流程，盤點系統中的資訊資產，例如資料、軟硬體、網路設備、人員及相關服務，並確認資產範圍與使用情境。

2. 威脅與脆弱性識別 針對各項資產，找出可能造成損害的威脅，以及威脅可能利用的脆弱性。威脅可來自人為、技術或環境因素；脆弱性則是資產或作業流程中可被利用的弱點。並應考量對機密性、完整性及可用性的影響。

3. 現有控制措施識別 盤點已實施及已規劃的安全控制措施，了解其實際執行狀況與成效。估計事故可能性時，須將現有控制措施納入考量，避免把控制措施的效果重複計入。

4. 後果識別 分析威脅利用脆弱性而發生事故時，可能對組織造成的後果，例如業務中斷、資料外洩或遭竄改、法令遵循問題、財務損失及信譽受損。

完成識別後，應形成清楚的風險情境，例如「某威脅利用某項資產的某弱點，造成特定資訊安全衝擊與組織後果」。

（二）風險估計及其步驟

**定義：**風險估計是根據風險識別結果，衡量資訊資產價值、事故發生可能性及事故後果的衝擊程度，據以估算各項資產相關風險的大小，供後續訂定風險等級及處理順序。

步驟：

1. 鑑別資訊資產價值 評估資產若在機密性、完整性或可用性方面遭受破壞，對組織造成的衝擊。可分別評定各構面的影響程度，再加總為資產價值：