# 資安職能訓練-資通安全概論
> 📚 **參考資料**
> - [資通安全概論_新版教材_11501_v4.pdf](https://ctts.nics.nat.gov.tw/DownloadDetail/70) — 數位發展部資通安全署
> - [資通安全概論新版教材_自我評量測驗v2.pdf](https://ctts.nics.nat.gov.tw/DownloadDetail/70) — 數位發展部資通安全署
---
# 第一章：資通安全基本觀念
> **學習目標**
> 1. 了解資通系統的組成元素（定義與構成要素）。
> 2. 建立對資通安全威脅的危機意識。
> 3. 掌握資通安全的核心防護目標 (CIA + L)。
---
## 1.1 資通系統之組成
在深入探討資安之前，必須先界定保護對象。依據《資通安全管理法》第 3 條第 1 款及第 2 款，核心保護對象為 **「資通系統」** 與 **「資通服務」**。
### 1.1.1 資通系統 vs 資通服務
| 比較項目 | 資通系統 | 資通服務 |
| :--- | :--- | :--- |
| **法條** | 第 3 條第 **1** 款 | 第 3 條第 **2** 款 |
| **法規定義** | 用以蒐集、控制、傳輸、儲存、流通、刪除資訊或對資訊為其他處理、使用或分享之**系統** | 與資訊之蒐集、控制、傳輸、儲存、流通、刪除、其他處理、使用或分享**相關之服務** |
| **白話理解** | 涉及資訊處理的**軟硬體與網路環境總稱**，涵蓋資訊從產生到銷毀的整個生命週期 | **圍繞在資通系統周邊**的支援性活動，非系統本體但確保系統持續可用 |
| **本質** | 運作的**主體** | 確保主體可用的**支援環節** |
| **實例** | 考選部全球資訊網（流通）、eCPA 人事服務網及公文系統（蒐集、儲存、處理）、差勤系統（管理流程） | 個人電腦維護服務（終端可用性）、伺服器維護服務（機房核心系統連續與穩定） |
> 📌 **考試陷阱**：題目常互換兩者定義來出選擇題，關鍵辨識點在結尾——「之**系統**」vs「相關之**服務**」。
### 1.1.2 五大關鍵要素
從實務角度，資通系統由五個關鍵要素構成，均為資安保護的對象：
| 要素 | 說明 | 考試提示 |
| :--- | :--- | :--- |
| **① 資訊與資料** | 最核心的保護對象：文件、資料庫、個資、業務數據 | CIA 保護的**首要目標** |
| **② 軟體** | 應用程式、作業系統、資料庫管理系統 | 保護完整性與可用性 |
| **③ 硬體** | 電腦、伺服器、網路設備、儲存裝置 | 需實體與邏輯雙重保護 |
| **④ 網路** | 路由器、交換器、防火牆、傳輸線路 | 資訊傳輸管道，防監聽與阻斷 |
| **⑤ 人員** | 使用者、管理者、開發人員、維護人員 | **最常被忽略但至關重要**，多數事件源於人為疏失或社交工程（如：誤點釣魚郵件導致憑證外洩） |
> 📌 **記憶口訣**：「**資軟硬網人**」— 資訊最核心，人員最關鍵。
### 1.1.3 資產分類 (CNS 27002：2023)
依據 CNS 27002：2023（對應 ISO/IEC 27002），對組織具備價值的任何事物皆視為**資產**，分為兩大類：
| 資產類型 | 內容 | 說明 |
| :--- | :--- | :--- |
| **主要資產** | 資訊（含資料）、營運過程與活動 | 受損將**直接**影響組織使命與目標 |
| **支援資產** | 硬體、軟體、網路、人員、**場域**、**組織結構** | 主要資產安全運行的**前提** |
> 📌 **注意**：支援資產比 1.1.2 五大要素多了「**場域**（如機房、辦公地點）」和「**組織結構**（如部門、職責劃分）」，這是 CNS 27002 標準特有的分類。
---
## 1.2 建立資通安全之危機意識
資通安全不單純是技術問題，更是一種思維模式與普遍認知。在快速變化的數位環境中，建立資通安全的危機意識是每個人、每個組織的首要任務。這種深植人心的意識，正是所有防護措施得以有效實施的基石。
### 1.2.1 資安威脅的潛在影響超乎想像
現今的資安威脅已非傳統單純的病毒感染，其規模與影響已達前所未有的程度。當關鍵資通系統遭受攻擊並停擺時，可能導致嚴重的連鎖反應：
| 影響層面 | 範例 |
| :--- | :--- |
| **公共服務** | 醫院系統癱瘓危及病患生命、政府服務停擺影響社會正常運轉 |
| **企業營運** | 生產停滯、供應鏈中斷、鉅額財務損失、市場競爭力下降、商譽受損 |
| **國家安全** | 關鍵基礎設施（電力、交通、通訊、金融）遭攻擊恐造成大規模社會混亂，甚至危及國家安全 |
### 1.2.2 資安攻擊無孔不入
隨著科技進步，網路攻擊途徑與手法日益多元與隱蔽：
| 威脅面向 | 說明 |
| :--- | :--- |
| **物聯網 (IoT)** | 裝置設計之初常未充分考慮資安，易成駭客入侵新入口。一個被入侵的智慧家電可能成為跳板，進而攻擊整個家庭網路 |
| **行動與無線通訊** | 便利但伴隨高風險：個資外洩、通訊監聽、生活品質受影響 |
### 1.2.3 資安是每個人的責任
資通安全絕非僅是資安專業人員的責任——在網路戰與資訊戰日益頻繁的當代，資安問題已上升到國家安全層次。資安素養是現代公民的基本素養，如同識字一樣重要，應落實於日常行為：
- [ ] 辨識釣魚郵件
- [ ] 使用強密碼
- [ ] 不隨意點擊不明連結
- [ ] 定期更新系統與應用程式
- [ ] 定期備份資料
> 📌 這些看似微小的個人行為，累積起來卻是國家整體資安防線的重要組成部分。
---
## 1.3 資通安全之防護目標 (CIA + L)
依據《資通安全管理法》第 3 條第 3 款，資通安全係指：
> 防止資通系統或資訊遭受未經授權之存取、使用、控制、洩漏、破壞、竄改、銷毀或其他侵害，以確保其**機密性、完整性及可用性**。
資安的核心防護目標為 **CIA 三原則**，加上公務機關與特定非公務機關須遵循的**法律遵循性 (L)**。
### 1.3.1 機密性 (Confidentiality)
* **定義**：確保資訊不被未經授權的人員或系統存取。敏感資訊只能經由授權之人員或系統存取。
* **目標**：防止非授權人員存取資訊，確保資訊的秘密性與隱私。
* **威脅型態**：資料外洩、竊聽、未授權揭露。
* **防護措施**：資料加解密、存取控制、資料遮罩 (Data Masking)、去識別化。
> 💼 **教材案例**：某機關委外辦理推廣活動，廠商直播時不慎透漏抽獎網址，導致中獎人個資（姓名、手機）外洩。這直接影響了個資的**機密性**。
> ➡ **建議防範**：直播活動預先演練，確認內容無不當揭露；機關辦理對外活動或公告時，應確認內容妥適性及資安管理措施；敏感資訊應進行去識別化處理，降低外洩風險。
### 1.3.2 完整性 (Integrity)
* **定義**：確保資訊在生命週期中持續正確、具一致性且可被信任。防止未經授權的修改或破壞。
* **目標**：防止非授權人員竄改資訊，確保資訊的正確性、可靠性與未被更動。
* **威脅型態**：資料遭竄改（如「Buy 1 item → Buy 10,000 items」）、誤刪。
* **防護措施**：數位簽章 (Digital Signature)、雜湊函數 (Hash Function)、資料驗證、版本控制、稽核追蹤。
> 💼 **教材案例**：某機關委請廠商進行個人電腦維護，駐點工程師因作業疏失輸入錯誤代碼，將機關內約 300 多台電腦的硬碟檔案刪除。這嚴重影響了資料的**完整性**。
> ➡ **建議防範**：定期備份重要資料以防範資料遺失；重大變更作業前應先小範圍測試再執行；建立多重審核機制確保操作正確性；高等級之資通系統，其備份資料應進行異地保存。
### 1.3.3 可用性 (Availability)
* **定義**：確保資訊與資源在需要時，可被授權使用者存取與使用，且系統功能正常運作。
* **目標**：防止系統故障或人為惡意阻斷服務，確保資訊與資訊處理的可獲得性。
* **威脅型態**：系統故障、DDoS 攻擊、天災（如颱風造成電力中斷）。
* **防護措施**：系統備援 (Redundancy)、資料備份 (Backup)、負載平衡、容量規劃、系統監控、UPS 不斷電系統、災難復原計畫。
> 💼 **教材案例**：113 年 10 月底康芮颱風過境，影響部分地區電力設施，部分機關因電壓供電不穩，致空調設備或主機設備異常，進而影響系統服務。這導致了服務的**可用性**受損。
> ➡ **建議防範**：機房電力、空調及資通系統服務等皆需建置備援機制，避免因斷電或供電不穩造成服務中斷；規劃與辦理核心業務或重要資通系統之營運持續演練 (BCP)，並將電力異常納入演練情境，確保事件發生時可緊急切換。
### 1.3.4 法律遵循性 (Legal Compliance)
除了 CIA 三目標，對政府機關（構）及特定非公務機關而言，法律遵循性同樣是重要目標。
* **定義**：確保所欲保護的資訊內容與所有資安活動，皆遵循相關法規要求。
* **目的**：確保組織的資安措施合法合規，避免因違法而面臨法律責任、罰款或聲譽受損。
* **重要性**：在數位政府及數位經濟的背景下，法律遵循性是組織合法運作及取得公眾信任的基礎。
* **重要相關法規**：
| 法規 | 說明 | 修正日期 |
| :--- | :--- | :--- |
| 《資通安全管理法》 | 資安管理基本大法，確立防護原則、架構與機關權責 | 114.09.24 |
| 《資通安全管理法施行細則》 | 進一步細化母法具體實施細節 | 110.08.23 |
| 《資通安全責任等級分級辦法》 | 依業務性質與風險，劃定等級並規定應辦事項 | 110.08.23 |
| 《個人資料保護法》 | 規範個資之蒐集、處理與利用，保護個人隱私權益 | 112.05.31 |
| 《國家機密保護法》 | 保護攸關國家安全的重要機密資訊 | 112.12.27 |
| 其他業務相關法規 | 各行各業依其特殊性有特定資安規定，如《醫療法》、《兒少法》等 | — |
---
### 1.3.5 CIA 防護技術總覽
| 防護目標 | 定義關鍵字 | 常見威脅 | 核心防護技術 |
| :--- | :--- | :--- | :--- |
| **機密性 (C)** | 未經授權**存取** | 資料外洩、竊聽 | 加密、**存取控制**、資料遮罩、去識別化 |
| **完整性 (I)** | **正確性**、一致性 | 資料竄改、誤刪 | 數位簽章、雜湊函數、資料驗證、**存取控制** |
| **可用性 (A)** | 需要時可**使用** | 系統當機、斷電、DDoS | 備援、備份、負載平衡、容量規劃、**存取控制** |
> 📌 **考試重點**：**存取控制 (Access Control)** 同時出現在機密性、完整性、可用性三個目標中，是**唯一橫跨 CIA 三面向的共通防護措施**。教材圖 5 以同心圓呈現此概念——最內層是「資訊」，外層分別為 CIA 三目標，「存取控制」在三個目標的周圍都有出現。
> 📌 **綜合提醒**：資通安全的防護目標是多面向的，必須從機密性、完整性、可用性及法律遵循性等角度全面考量，綜合運用各種技術及管理策略，針對不同的安全目標及需求，選擇最適合的工具及策略，才能有效保護資訊資產，確保數位環境的安全與穩定。
---
### 第 1 單元：資通安全基本觀念
#### 1. 依據《資通安全管理法》第 3 條第 1 項的定義，以下何者最能完整描述「資通系統」？
- \(A\) 指用以儲存及流通資訊之硬體設備。
- \(B\) 指用以傳輸或分享資訊之網路軟體。
- \(C\) 指用以蒐集、控制、傳輸、儲存、流通、刪除資訊或對資訊為其他處理、使用或分享之系統。
- \(D\) 指與資訊之蒐集、控制、傳輸、儲存、流通、刪除、其他處理、使用或分享相關之服務。
> **答案：C**
---
#### 2. 下列關於「資產」的敘述，何者符合 ISO/CNS 27002 標準的定義？
- \(A\) 資產限於硬體和軟體等實體項目。
- \(B\) 資產被定義為對組織有價值的任何事物。
- \(C\) 主要資產僅指資訊，不包含營運流程與活動。
- \(D\) 支援資產不包含人員和場域等要素。
> **答案：B**
---
#### 3. 建立資通安全的危機意識的重要性，以下何者「錯誤」？
- \(A\) 資安的危害可能產生超乎一般人的想像，造成重大影響。
- \(B\) 資安攻擊無所不在，影響層面廣大。
- \(C\) 資安是資安專業人員的專屬責任，與一般員工無關。
- \(D\) 資安素養是現代公民需要培養的生活與工作知能。
> **答案：C**
---
#### 4. 資通安全的三個核心防護目標（CIA）是指？
- \(A\) 便利性、完整性、可用性
- \(B\) 機密性、有效性、整合性
- \(C\) 成本性、效率性、可用性
- \(D\) 機密性、完整性、可用性
> **答案：D**
---
#### 5. 為保護資料的「機密性」，下列哪一項為其主要措施？
- \(A\) 雜湊函數與數位簽章。
- \(B\) 容量規劃與備份。
- \(C\) 資料加解密與存取控制。
- \(D\) 容錯與負載平衡。
> **答案：C**
---
#### 6. 當資通安全事件涉及資料被「未經授權地修改或破壞」時，這主要影響了資通安全的哪一個防護目標？
- \(A\) 完整性
- \(B\) 機密性
- \(C\) 可用性
- \(D\) 法律遵循性
> **答案：A**
---
#### 7. 以下何者「不是」資通安全防護目標中「可用性」的主要保護措施？
- \(A\) 容量規劃
- \(B\) 備份
- \(C\) 數位簽章
- \(D\) 容錯、備援及負載平衡
> **答案：C**
---
#### 8. 《資通安全管理法》對「資通服務」的定義為何？
- \(A\) 專指政府機關內部使用的資訊系統。
- \(B\) 指與資訊之蒐集、控制、傳輸、儲存、流通、刪除、其他處理、使用或分享相關之服務。
- \(C\) 僅指雲端運算提供的各種服務。
- \(D\) 專指軟體開發與維護活動。
> **答案：B**
---
#### 9. 在資通安全風險意識的建立中，物聯網（IoT）的普及帶來了商機，同時也引發了哪些資安危機的思考？
- \(A\) 造成個人隱私洩露，但從不影響國家層面的資安風險。
- \(B\) 增加被攻擊的風險，可能導致更大的不便。
- \(C\) 對於軟體層面不會造成威脅，而只會對硬體設備造成威脅。
- \(D\) 促進資訊自由流通，完全沒有資安隱患。
> **答案：B**
---
#### 10. 資通安全防護目標中的「法律遵循性」主要指的是什麼？
- \(A\) 資安措施的重點為遵守《資通安全管理法》，不包含其他法規。
- \(B\) 確保所有資安措施都符合國際標準 ISO 27001。
- \(C\) 資訊安全措施必須符合相關的法律規定，如《資通安全管理法》、《個人資料保護法》等。
- \(D\) 資訊安全措施主要依循機關內部制定的資安政策與規範，不受外部法律約束。
> **答案：C**
--
# 第二章：資通安全相關法規
> **學習目標**
> 1. 了解我國資通安全管理體系的組織架構與主要角色。
> 2. 深入理解《資通安全管理法》及其六大子法的核心內容。
> 3. 認識其他與資通安全議題相關之重要法規（國家機密保護法、個資法、刑法）。
---
## 2.1 我國資通安全管理體系
我國資通安全管理體系是由多個部會協同合作、層級分明的結構，旨在統籌全國資通安全事務。
### 2.1.1 決策與協調層級：國家資通安全會報
「國家資通安全會報」是國家資安的**最高指導與協調單位**，負責制定國家資通安全政策的最終決策。
| 職位 | 擔任者 |
| :--- | :--- |
| **召集人** | 行政院**副院長** |
| **副召集人** | 行政院政務委員及指定相關部會首長 1 人 |
| **偕同副召集人** | 國家安全會議諮詢委員兼任 |
| **委員** | 行政院部會首長、直轄市政府副市長、國安局副局長、學者及專家 |
> 📌 **考試重點**：最高指導協調單位是「國家資通安全會報」（非數位發展部、非資安署）。召集人是行政院**副院長**。
### 2.1.2 國家資通安全會報下轄兩大體系
| 體系 | 主責機關 | 職能 |
| :--- | :--- | :--- |
| **網際防護體系** | **數位發展部** | 提升各機關及特定非公務機關資安防護能力。下轄關鍵資訊基礎設施安全管理組、產業發展組、資通安全防護組、法規及標準推動組、認知教育及人才培育組、外館網際防護組等 |
| **網路犯罪偵防體系** | **內政部與法務部** | 負責處理網路犯罪的偵查及防制。下轄防治網路犯罪組、資通訊環境及網路內容安全組 |
其他相關單位：
* **數位發展部**：會報幕僚單位，協助國安會報運作。
* **國家資通安全研究院**：負責資安技術研究與發展。
### 2.1.3 資通安全管理體系之金字塔層級架構
| 層級 | 機關 | 角色 |
| :--- | :--- | :--- |
| **第 1 層** | 行政院 | **決策機關**：資通安全政策的最終決策與指導 |
| **第 2 層** | 數位發展部 | **規劃機關**：制定相關政策及計畫 |
| **第 3 層** | 數位發展部指定之資安專責機關 | **監管機關 + 部分規劃與執行**：監管對象包括公務機關及特定非公務機關，並與中央目的事業主管機關協同 |
| **第 4 層** | 公務機關、特定非公務機關 | **納管機關**：負責具體執行工作 |
### 2.1.4 第七期國家資通安全發展方案 (114 年~117 年)
* **願景**：建構韌性安全的數位社會。
* **三大目標**：
1. 強化全社會資安防禦韌性。
2. 豐富資安產業生態系。
3. 促進新興科技資安技術的發展與應用。
* **四大推動策略**：
| 策略 | 重點 |
| :--- | :--- |
| **策略一：全社會資安防禦** | 完善國家資安應變機制、提升全民資安職能與意識、建構全民社會資安防護網 |
| **策略二：提升關鍵基礎設施資安韌性** | 建立 CI 資安防護體系、提升 CI 防禦能量、精進 CI 治理能力 |
| **策略三：壯大我國資安產業** | 推動資安產品檢測制度、強化政府採購供應鏈風險管理、擴大資安產業規模邁向國際 |
| **策略四：AI 新興資安科技應用與合作** | 拓展 AI 技術提升資安防護能量、強化新興資安科技前瞻研究、促進國際資安交流合作 |
---
## 2.2 資通安全管理法與子法
《資通安全管理法》（簡稱資安法）是我國資安防護的核心法律，於 107 年 6 月 6 日公布，108 年 1 月 1 日施行，**114 年 9 月 24 日再修正**。
### 2.2.1 立法目的與適用對象
* **立法目的**：積極推動國家資通安全政策，加速建構國家資通安全環境，以**保障國家安全，維護社會公共利益**。
* **適用對象**（按法規義務強度由高至低排列）：
1. **公務機關**：依法行使公權力之中央、地方機關（構）或公法人。
* ⚠️ **不包含「軍事機關及情報機關」**
* 軍事機關：國防部及所屬機關（構）、部隊、學校
* 情報機關：依《國家情報工作法》第 3 條規定之機關
2. **特定非公務機關**（法規義務強度由高至低）：
* **關鍵基礎設施提供者 (CI)**：如台灣中油。由中央目的事業主管機關指定，報請行政院核定
* **公營事業**：如台灣糖業公司
* **特定財團法人**：符合財團法人法相關規定之全國性財團法人，如工業技術研究院
* **受政府控制之事業、團體或機構** (114 年新增定義)
> 📌 **考試陷阱**：若同時具有 CI 提供者及公營事業身分者，以 **CI 提供者**適用之法規為先（就高原則）。
### 2.2.2 114 年修正重點
| 章別 | 重要新增及修正 |
| :--- | :--- |
| **總則** | 新增「危害國家資通安全產品」定義；新增協助民間處理重大資安事件；行政院應定期召開國家資通安全會報 |
| **公務機關** | **禁用**危害國家資安產品（例外須經資安長核可並報主管機關核定）；新增適任性查核（未通過者不得辦理涉國密業務） |
| **特定非公務機關** | CI 提供者及其以外機構均須設**資安專職人員**；須設**資安長**；新增事件調查權；新增禁用危害國安產品 |
| **罰則** | 罰鍰上限提高：未通報→ 30 萬~**1,000 萬**；違反維護計畫等→ 10 萬~**500 萬**；拒絕調查→ 10 萬~100 萬 (新增) |
| **附則** | 新增：資安事件涉及**個資外洩**時，應另依《個資法》辦理 |
### 2.2.3 主要義務：事前、事中、事後
公務機關及特定非公務機關在資安管理上的義務貫穿事件全生命週期：
| 階段 | 共同義務 |
| :--- | :--- |
| **事前** | 訂定**資通安全維護計畫**；訂定**通報及應變機制** |
| **事中** | 接受資通安全**稽核**；提出資通安全維護計畫**實施情形**；發生事件時進行**通報及應變** |
| **事後** | 稽核後提出**改善報告**；事件通報後提出**調查、處理及改善報告** |
### 2.2.4 資通安全責任等級 (A/B/C/D/E)
依據《資通安全責任等級分級辦法》，機關依業務性質與影響程度分為五級，符合多個等級者取**最高**：
| 等級 | 定義簡述 | 關鍵判定條件 |
| :--- | :--- | :--- |
| **A 級** | 業務涉及**全國性**影響 | 國家機密、外交國防國土安全、全國性民眾服務或跨機關共用系統、全國性個資、全國性 CI、公立**醫學中心** |
| **B 級** | 業務涉及**區域性或地區性**影響 | 國家核心科技資訊、區域性民眾服務或共用系統、區域性個資、區域性 CI、中央二級機關共用系統、公立**區域及地區醫院** |
| **C 級** | **維運自行或委外開發之資通系統** | 具權限區分及管理功能之資通系統 |
| **D 級** | **自行辦理資通業務，無維運自開發系統** | 僅使用套裝軟體 |
| **E 級** | **無資通系統** | 基本認知宣導即可 |
* 各機關需**每 3 年** (114 年修法後) 核定或提交其資通安全責任等級
* 責任等級可依國家安全或其他影響考量進行調整
### 2.2.5 資通安全事件通報應變 (摘要)
* **事件分級**：分為 1 至 4 級（4 級最嚴重）
* **通報時限**：知悉事件後 **1 小時內**完成通報
* **損害控制**：1/2 級 72 小時、3/4 級 36 小時
* 📎 詳見第九章
### 2.2.6 六大子法
#### ① 資通安全管理法施行細則
補充母法執行細節，重點包括：
| 主題 | 內容 |
| :--- | :--- |
| **定義明確** | 界定「軍事及情報機關」、「核心業務」、「核心資通系統」 |
| **核心資通系統** | 支援核心業務持續運作必要之系統，或防護需求等級為**高**者 |
| **維護計畫** | 應包含 **13 項**：核心業務、資安政策目標、推動組織、人力經費、資安長配置、系統盤點、風險評估、防護控制措施、通報應變演練機制、情資評估、委外管理、考核機制、精進績效管理 |
| **委外管理** | 受託者需具完善資安措施或通過第三方驗證；涉及國密者需適任性查核；核心系統或金額達 **1,000 萬**者需安全性檢測 |
| **改善報告** | 應含缺失項目、原因、改善措施（管理、技術、人力、資源）、完成時程及追蹤方式 |
| **重大事件** | 第 3 級及第 4 級事件 |
#### ② 資通安全責任等級分級辦法
* 規範 A~E 級之判定標準及各級應辦事項（附表一至附表十）
* 系統依 CIA+L 分為高/中/普三級，實施相應防護基準
* 📎 詳見附表一至附表十
#### ③ 特定非公務機關資通安全維護計畫實施情形稽核辦法
規範主管機關如何對特定非公務機關進行稽核：
| 流程 | 說明 |
| :--- | :--- |
| **擬定稽核計畫** | 主管機關每年依業務重要性、系統規模、事件頻率、歷史稽核結果等因素擇定對象 |
| **成立稽核小組** | **3 人以上**，須含政策、技術、管理、法律專業者，**公務機關代表不少於 1/4**，遵守利益衝突迴避及保密義務 |
| **通知受稽機關** | 稽核 **1 個月前**書面通知；受稽機關可於 5 日內申請調整日期（限 1 次） |
| **進行稽核** | 稽核前訪談 + 現場實地稽核；可要求說明、提供文件 |
| **交付稽核報告** | 稽核完成後 **1 個月內** |
| **提交改善報告** | 交付報告後 **1 個月內**，送交中央目的事業主管機關 |
#### ④ 資通安全事件通報及應變辦法
* 規範通報流程與時限（詳見第九章）
* 事件分為 4 級
* 知悉後 1 小時內通報；3/4 級事件 2 小時內審核
* 演練要求：社交工程每半年 1 次、通報應變、攻防及情境演練每年 1 次
#### ⑤ 資通安全情資分享辦法
| 主題 | 內容 |
| :--- | :--- |
| **情資範圍** | 惡意偵察、安全漏洞、攻擊方法（安全控制措施失效方法）、惡意程式、事件損害、偵測預防措施及相關技術性資訊，共 **7 項** |
| **分享原則** | 各機關應適時與主管機關或中央目的事業主管機關分享；須辨識來源可靠性及時效性，分析威脅與弱點 |
| **限制** | 涉及**營業秘密**或依法應保密者**不得分享**（例外：公益、生命健康、當事人同意）；可部分分享 |
| **保護** | 規劃適當安全維護措施，避免情資、個資外洩或遭未授權存取或竄改 |
| **國際合作** | 主管機關應就情資分享事宜進行國際合作 |
| **整合分析** | 得依來源、日期、類別、威脅指標等進行關聯分析，並分享新型威脅情資 |
#### ⑥ 公務機關所屬人員安全事項獎懲辦法
| 類型 | 適用情形 |
| :--- | :--- |
| **獎勵** (12 項) | 有效實施資安維護計畫；稽核及演練績效優良；成功預防事件或降低損害；即時發現重大事件；提出具體建議或革新方案；對資安人才培育、科技研發及國際合作有貢獻等 |
| **懲處** (3 項) | 未依規定辦理資安相關事項（情資分享、維護計畫、稽核、改善報告、通報應變等）且**情節重大**；業務績效不良經疏導無效且情節重大；其他違反法規且情節重大 |
| **程序保障** | 懲處前應給予當事人**申辯機會**；必要時得徵詢資安專家學者意見 |
| **考核注意** | 應綜合考量事件原因、過程、動機、手段、表現及影響；聘僱人員獎懲納入續聘參考 |
---
## 2.3 其他相關法規
### 2.3.1 國家機密保護法
92 年 2 月 6 日公布，112 年 12 月 27 日修正。核心目的：確保國家安全或利益，對政府機關持有或保管經核定機密等級之資訊提供嚴格保護。
**國家機密等級與保密期限**：
| 等級 | 敏感程度 | 最長保密期限 |
| :--- | :--- | :--- |
| **絕對機密** | 最高 | **30 年** |
| **極機密** | 高度 | **20 年** |
| **機密** | 一般 | **10 年** |
**核定原則**：
* 應在必要之「**最小範圍內**」為之
* 權責人員應於接獲報請後 **30 日內**完成核定
* 應併予核定保密期限或解除機密之條件
* 112 年修正後，原核定「永久保密」者應於修正施行日起 **2 年內**重新核定；屆滿未重新核定者，視為解除機密
* 變更機密等級者，保密期限仍自**原核定日**起算
### 2.3.2 個人資料保護法 (PDPA)
99 年 5 月 26 日公布，101 年 10 月 1 日施行，112 年 5 月 31 日修正。
* **立法目的**：規範個人資料之蒐集、處理及利用，以**避免人格權受侵害，並促進個人資料之合理利用**。
* **個人資料定義**：限定於**自然人**的資料，且能**直接或間接識別**該個人者：
* 屬性資料：姓名、生日、身分證字號
* 行為資料：健康檢查報告、犯罪前科
* 其他可識別資料：聯絡方式、地址、病歷、消費紀錄
* **核心規範**：
* **自主權利不可拋棄**：當事人的個資自主權利不得預先拋棄
* **特定目的原則**：蒐集、處理或利用必須有特定目的
* **告知義務**：蒐集時需告知目的、類別、使用範圍及來源
* **刪除義務**：應保持正確性，蒐集目的消失後應刪除
* **安全維護**：保有個資之單位應採行適當安全維護措施，防止竊取、竄改或毀損
### 2.3.3 《資通安全管理法》vs《個人資料保護法》比較
| 比較項目 | 資通安全管理法 | 個人資料保護法 |
| :--- | :--- | :--- |
| **主管機關** | **數位發展部** | **個人資料保護委員會** |
| **立法目的** | 推動國家資安政策，保障國家安全，維護社會公共利益 | 規範個資蒐集、處理及利用，避免人格權受侵害，促進個資合理利用 |
| **適用對象** | **公務機關**及**特定非公務機關**（組織層面） | **所有**蒐集、處理或利用個資的單位，含公務與非公務機關、法人、自然人 |
| **主要重點** | 納管機關之資安管理作業，降低資安風險 | 個人資料的保護，限制個資外洩與不當使用 |
| **出發點** | **組織層面**：提升整體資安防護能力 | **個人權益**：規範個人資料處理行為 |
> 📌 兩者雖目標不同，但實務上相互影響：良好的資安管理可有效降低個資外洩風險。114 年修正亦新增：資安事件涉及個資外洩時，應另依個資法辦理。
### 2.3.4 刑法 (妨害電腦使用罪章)
針對駭客攻擊行為的刑事處罰：
| 條文 | 罪名 | 行為態樣 |
| :--- | :--- | :--- |
| **第 358 條** | **入侵電腦罪** | 無故輸入帳號密碼、破解使用電腦之保護措施或利用電腦系統漏洞，而入侵他人電腦 |
| **第 359 條** | **破壞電磁紀錄罪** | 無故取得、刪除或變更他人電腦之電磁紀錄 |
| **第 360 條** | **干擾電腦系統罪** | 無故以電腦程式或其他電磁方式干擾他人電腦，致生損害（如 DDoS） |
---
### 💡 總結：法規遵循 Check List
- [ ] 確認機關或企業之資安責任等級 (A~E)。
- [ ] 是否依等級設置資安專職人員並完成年度培訓。
- [ ] 是否訂定並落實資通安全維護計畫（含 13 項內容）。
- [ ] 發生資安事件時，是否知悉通報窗口與時限（知悉後 **1 小時內**）。
- [ ] 資安事件涉及個資外洩時，是否另依個資法辦理。
---
### 第 2 單元：資通安全相關法規
#### 1. 我國資通安全管理體系的最高指導及協調單位是哪一個？
- \(A\) 數位發展部資通安全署
- \(B\) 國家資通安全會報
- \(C\) 國防部資通電軍指揮部
- \(D\) 內政部警政署
> **答案：B**
---
#### 2. 依據《資通安全管理法》，以下哪一類機關「不」屬於其適用對象？
- \(A\) 關鍵基礎設施提供者
- \(B\) 公營事業
- \(C\) 軍事機關
- \(D\) 政府捐助之財團法人
> **答案：C**
---
#### 3. 《資通安全管理法》的立法目的主要為何？
- \(A\) 規範個人資料蒐集與利用，避免人格權侵害。
- \(B\) 促進新興科技的資安技術發展。
- \(C\) 提升國家整體資安防護能力，保障國家安全和社會公共利益。
- \(D\) 該法案的立法目的完全集中於處理網路犯罪的偵查與防制。
> **答案：C**
---
#### 4. 依據《資通安全管理法施行細則》，公務機關與特定非公務機關在資通安全事件發生「事前」應辦理的共同義務為何？
- \(A\) 提出改善報告。
- \(B\) 接受資通安全稽核。
- \(C\) 提交資通安全事件調查報告。
- \(D\) 訂定資通安全維護計畫及通報應變機制。
> **答案：D**
---
#### 5. 依據《資通安全管理法》規定，公務機關除了資安長外，還需設置什麼人員？
- \(A\) 資安專責人員 \(非專職\)
- \(B\) 資安專職人員
- \(C\) 公關經理
- \(D\) 法律顧問
> **答案：B**
---
#### 6. 《資通安全管理法施行細則》第 7 條對「核心資通系統」的定義中，以下何者「不」是判斷標準？
- \(A\) 支持核心業務持續運作必要之系統。
- \(B\) 依資通安全責任等級分級辦法判定防護需求等級為高者。
- \(C\) 一般行政作業的辦公室軟體之必要功能。
- \(D\) 業務涉及全國性民眾服務或跨公務機關共用性資通系統之維運。
> **答案：C**
---
#### 7. 依據《資通安全責任等級分級辦法》，各機關應多久提報或核定其資通安全責任等級 1 次？
- \(A\) 每年
- \(B\) 每 2 年
- \(C\) 每 3 年
- \(D\) 每 5 年
> **答案：C**
> ⚠️ 114 年修法後改為每 **3 年**提報或核定 1 次（v1 原答案為 B「每 2 年」，v2 已更正為 C）。
---
#### 8. 關於《個人資料保護法》的目的，以下何者敘述「最完整」？
- \(A\) 其主要目的為避免人格權受侵害，與個人資料之利用無關。
- \(B\) 其主要目的為促進個人資料之合理利用，不涉及人格權的保護。
- \(C\) 為規範個人資料之蒐集、處理及利用，以避免人格權受侵害，並促進個人資料之合理利用。
- \(D\) 為積極推動國家資通安全政策。
> **答案：C**
---
#### 9. 比較《個人資料保護法》與《資通安全管理法》，關於其主管機關的敘述，何者正確？
- \(A\) 兩者主管機關皆為數位發展部。
- \(B\) 《個人資料保護法》主管機關為個人資料保護委員會（含籌備機制），《資通安全管理法》主管機關為數位發展部。
- \(C\) 《個人資料保護法》主管機關為法務部，《資通安全管理法》主管機關為內政部。
- \(D\) 兩者皆無特定主管機關。
> **答案：B**
---
#### 10. 依據《國家機密保護法》，以下哪一個是「絕對機密」的最長保密期限？
- \(A\) 10 年
- \(B\) 20 年
- \(C\) 30 年
- \(D\) 永久保密
> **答案：C**
--
# 第三章：資通安全風險管理
> **學習目標**
> 1. 了解資通安全風險管理的整體流程，包括其核心步驟與循環特性。
> 2. 掌握風險管理全景建立的重要性，包括內外部環境的識別與風險準則的設定。
> 3. 學習風險評鑑的作法，包括高階與詳細評鑑的選擇與執行。
> 4. 理解風險處理的各項策略（修改、留存、避免、分擔）。
> 5. 明確風險接受的考量因素，以及殘餘風險的管理。
> 6. 認識國際重要資通安全防護與管理標準（NIST CSF 2.0、CNS 27005:2024）。
---
## 3.1 風險管理之流程
資通安全風險管理是一個**持續性的循環過程**，核心目標是在**有限的防護成本投入下獲得最佳化的安全性**，而非追求絕對的零風險。
### 3.1.1 「風險」的產生
風險源於三個關鍵要素的交互作用：
| 要素 | 說明 | 範例 |
| :--- | :--- | :--- |
| **威脅 (Threat)** | 可能對組織資產造成損害的**潛在原因或事件** | 釣魚郵件、天災、內部惡意人員 |
| **脆弱性 (Vulnerability)** | 資訊資產本身或保護機制中存在的**弱點**，可能被威脅利用 | 未更新的防毒軟體、弱密碼 |
| **衝擊 (Impact)** | 威脅利用脆弱性成功時，對資產造成的**負面影響** | 公文外洩、系統癱瘓 |
> 📌 **因果鏈範例**：「釣魚郵件」（威脅）被使用者點開，利用「未更新的防毒軟體」（脆弱性），可能導致「公文外洩」（衝擊）。
### 3.1.2 「風險」的定義
> 威脅利用其相對應的脆弱性，造成組織或政府機關資訊資產受到衝擊的「**可能性**」。
**風險大小 = 衝擊 × 可能性**
```mermaid
flowchart LR
A[威脅] -->|利用| B[脆弱性]
B -->|產生| C[衝擊]
C --> E[風險]
D[可能性] --> E
```
### 3.1.3 衝擊準則
為客觀評估資安事件可能造成的損害程度，需訂定「衝擊準則」。衡量威脅與弱點結合後，破壞 CIA 時對組織造成的嚴重性，可能涵蓋營運受損、信譽損害、財務損失及法律遵循性問題。
| 衝擊等級 | 對應關鍵字 |
| :---: | :--- |
| **高** | 非常嚴重或**災難性**之影響 |
| **中** | **嚴重**之影響 |
| **普** | **有限**之影響 |
### 3.1.4 資通安全風險管理流程
依據 CNS 27005:2024（對應 ISO/IEC 27005），主要流程包含以下階段，各階段之間強調**持續溝通與協調**：
| 步驟 | 說明 |
| :--- | :--- |
| **① 風險溝通及諮詢** | **貫穿整個流程**，持續與內外部利害關係人溝通風險定義、評估結果與決策 |
| **② 全景建立** | 確定評鑑的範圍、限制與背景資訊 |
| **③ 風險評鑑** | 核心步驟，包含「風險識別 → 風險分析 → 風險評估」 |
| **④ 風險決策點 1** | 評鑑結果是否允當？允當則進入風險處理；不允當則返回重新評估 |
| **⑤ 風險處理** | 選擇策略：修改、留存、避免、分擔 |
| **⑥ 風險決策點 2** | 處理後風險是否可接受？可接受則進入風險接受；不可接受則返回重新處理 |
| **⑦ 風險接受** | 接受經處理後的殘餘風險 |
| **⑧ 風險監視與審查** | 持續監控風險及管理措施有效性，結果回饋至風險評鑑，形成**持續改進循環** |
> 📌 **考試重點**：「風險溝通及諮詢」**貫穿全流程**，不是單一階段；整個過程是 PDCA **循環**而非線性。
---
## 3.2 風險管理之全景建立
在啟動風險評鑑前，必須先劃定範圍與標準——建立清晰的「全景」是成功的關鍵。
### 3.2.1 識別機關內、外各方面的安全需求
組織必須**全面識別**其內外部安全需求，作為風險評鑑的基礎：
| 環境 | 識別項目 | 說明 |
| :--- | :--- | :--- |
| **外部環境** | 衝擊組織目標的關鍵因素與趨勢 | 市場變化、技術發展、產業競爭態勢 |
| | 社會、文化、政治、法律、財務、科技、經濟及自然因素 | 如新法規（GDPR、新資安法修正）、經濟環境影響資安預算、自然災害造成實體損失 |
| **內部環境** | 機關治理、組織架構、角色及責任 | 資安長、資安專責人員的職責與權責劃分 |
| | 政策、目標及策略 | 已制定的資安政策與長短期目標 |
| | 能力、資源及知識 | 人力、財力、技術工具及員工資安意識水平 |
### 3.2.2 規劃並定義風險管理基本準則
在啟動評鑑前，組織需規劃一套共同遵循的基本準則，確保評估的一致性與客觀性：
| 準則項目 | 說明 |
| :--- | :--- |
| **風險管理作法** | 明確採用何種模型或框架（如 ISO/IEC 27005 或 NIST RMF） |
| **風險評估準則** | 訂定判斷威脅可能性、評估脆弱性的具體方法與標準 |
| **衝擊準則** | 明確資安事件對組織的衝擊等級（普/中/高）及其衡量標準 |
| **風險接受準則** | 考慮成本、效益、法律遵循性後，定義可接受的風險水平 |
| **界定評鑑範圍** | 清查盤點範圍內所有相關資通系統，組成跨部門風險評鑑組織 |
---
## 3.3 風險評鑑之作法
依據評鑑的深度、所需資源及目標，可選擇不同的評鑑方法。
### 3.3.1 兩種評鑑模式比較
| 特性 | 高階風險評鑑 (High-Level) | 詳細風險評鑑 (Detailed) |
| :--- | :--- | :--- |
| **適用時機** | 初期建立（第 1、2 年）、資源有限、需快速了解主要風險 | 高價值資產、核心系統、高階評鑑後發現之高風險項目、資安事件後 |
| **方法** | 依「資通系統防護需求分級原則」直接判定安全等級 | 對資產進行深度識別，詳細列出威脅與弱點 |
| **優點** | ① 簡便易行，容易獲得參與人員接受<br>② 把握時效，優先找出最關鍵系統<br>③ 將有限資源運用於最有利處 | ① 精確度高，能找出具體技術弱點<br>② 可採定量（損失金額）、定性（高中低）或混合方法 |
| **缺點** | 精確度較低，可能遺漏特定營運過程或系統的潛在風險 | 耗時、需專業技術與較多資源 |
> 📌 **考試常見陷阱**：高階風險評鑑的優點**不包含**「精確」——精確是詳細風險評鑑的特點。
### 3.3.2 風險評鑑組織
為確保客觀性、全面性與實用性，建議成立**跨部門**的風險評鑑組織：
| 成員 | 角色 |
| :--- | :--- |
| **資訊及資安人員** | 提供技術專業知識 |
| **總務部門** | 協助評估實體安全、環境風險 |
| **人事部門** | 協助評估人員相關風險（人為失誤、內部威脅） |
| **會計部門** | 協助評估財務衝擊 |
| **業務承辦人員** | 最熟悉實際業務流程，提供最精確的資產重要性資訊 |
> 📌 **考試重點**：應避免由**單一成員**執行所有風險評鑑工作，以防產出結果過於主觀。
### 3.3.3 高階風險評鑑的流程
高階風險評鑑依資通系統分級原則，快速評估系統安全等級：
```
輸入：資通系統
↓
① 設定影響構面等級 ─ 由業務承辦人依 C/I/A/L 四構面評估衝擊
↓
② 識別業務屬性 ─ 確認系統所支援的業務性質
↓
③ 檢視安全等級 ─ 由承辦單位主管檢視等級是否合理
↓
④ 核定安全等級 ─ 經資訊主管確認後，由資通安全長核定
↓
輸出：資通系統安全等級
```
### 3.3.4 資通系統安全等級之衝擊構面 (CIA + L)
評估資通系統在四個構面受損時的衝擊程度（普/中/高），每個構面都有對應的案例：
| 構面 | 事件類型 | 普（有限影響） | 中（嚴重影響） | 高（災難性影響） |
| :--- | :--- | :--- | :--- | :--- |
| **機密性** | 未經授權之資訊**揭露** | 政府公開網站的非敏感資訊被揭露 | CRM 系統中客戶聯絡方式外洩 | 醫院電子病歷等高度敏感個資外洩 |
| **完整性** | 資訊**錯誤**或遭**竄改** | 校園論壇貼文被竄改 | 庫存管理系統數據被竄改致排程混亂 | 銀行核心交易系統金額被竄改 |
| **可用性** | 存取或使用之**中斷** | 圖書館自助借還書機中斷（可改用人工） | 電商訂單處理系統高峰期中斷 | 電力調度控制系統停擺致大範圍停電 |
| **法律遵循性** | 未遵循**法令** | 網站使用條款未完全符合新法細節要求 | 未落實個資法致非敏感個資外洩，受行政罰 | 金融機構資通系統漏洞致洗錢，負刑事責任 |
> 📌 **等級判定原則**：資通系統的最終安全等級，以四個構面中**最高者**定之。
> 📌 **法律遵循性速記**：高 →「**刑**」事責任 ｜ 中 →「**罰**」行政罰或懲戒 ｜ 普 →「**規**」一般法令規範
**範例**：「全球資訊網」（機關簡介與政策發布網站）
四構面皆初估為「普」——資訊為可公開的一般性資料，中斷影響有限，不涉根本違法 → 系統安全等級：**普**。
### 3.3.5 詳細風險評鑑的作法
對資產進行深度識別與鑑別，通常分為三個階段：
| 階段 | 工作內容 |
| :--- | :--- |
| **① 風險識別** | 資產識別（找出應優先處理的資產）→ 威脅與脆弱性識別 → 現有控制措施識別 → 後果識別 |
| **② 風險分析** | 後果評估（資產價值與衝擊）→ 事件可能性評估 → 綜合決定**風險等級** |
| **③ 風險評估** | 依風險分析結果，判斷風險是否在**可接受範圍**內 |
### 3.3.6 風險接受準則
風險接受準則因機關所負責任務不同而考量重點不同，可能影響的因素包括：業務需求與目標、法律、法令、規章及契約要求、資源分配狀況、技術成熟度、經費預算、社會與人道主義因素。
---
## 3.4 風險處理之作法 (Risk Treatment)
風險處理是繼風險評鑑之後的關鍵步驟，針對已評估出的風險，選擇並實施適當的行動方案，使風險降至可接受水平。
```mermaid
flowchart TD
A[風險評鑑結果] --> B{風險決策點}
B -->|不合意| C[返回風險評鑑]
B -->|合意| D[風險處理選擇]
D --> E[風險修改]
D --> F[風險留存]
D --> G[風險避免]
D --> H[風險分擔]
E & F & G & H --> I[殘餘風險]
I --> J{處理後可接受？}
J -->|否| D
J -->|是| K[風險接受]
```
### 3.4.1 風險修改 (Risk Modification) — 最常見
藉由施行、移除或改變安全控制措施，修訂或降低風險等級，使殘餘風險被重新評定為可接受。
**控制措施可提供的九種保護形式**：
| 類型 | 說明 |
| :--- | :--- |
| 矯正 (Correction) | 修復已存在的漏洞或錯誤 |
| 消弭 (Elimination) | 完全移除風險來源 |
| 預防 (Prevention) | 阻止事件發生 |
| 衝擊最小化 (Impact Minimization) | 減輕事件發生後的損害 |
| 制止 (Deterrence) | 透過威懾手段阻止攻擊者 |
| 偵測 (Detection) | 即時發現資安事件 |
| 復原 (Recovery) | 恢復受損系統及資料 |
| 監視 (Monitoring) | 持續監測系統及環境 |
| 認知 (Awareness) | 提升人員資安意識 |
> 📌 選擇控制措施時，應權衡實作及維護的**成本**與被保護資產的**價值**，確保成本效益。高階評鑑可參考「安全控制措施參考指引」依等級（普/中/高）選擇適用之控制措施。
### 3.4.2 風險留存 (Risk Retention)
依據風險評估結果，確認無進一步行動，而**保留風險**的決策。
| 項目 | 說明 |
| :--- | :--- |
| **適用情境** | 風險等級符合接受準則、處理成本過高、無其他可行方案 |
| **決策要求** | 即使保留，該決策也應基於正式評估過程，並得到**組織高層批准** |
| **後續管理** | 保留的風險仍為「殘餘風險」，需**定期監控**並考量業務持續管理計畫 |
| **教材範例** | 自建機房容易斷電，因空間限制無法建置發電機，也無法保險或搬遷，只能選擇保留此風險 |
### 3.4.3 風險避免 (Risk Avoidance)
直接**放棄或避免**可能造成風險增加的活動或情況，從根本上消除風險。
| 項目 | 說明 |
| :--- | :--- |
| **方法** | 終止或避免活動，徹底消除與特定風險相關的暴露 |
| **教材範例 1** | 為避免零日漏洞風險，決定不使用未經安全審核的第三方開源函式庫，自行開發程式碼 |
| **教材範例 2** | 將發電機從容易淹水的地下室移至樓上，避免颱風淹水損壞風險 |
| **注意** | 有時可能影響組織運作或目標達成，需仔細評估 |
### 3.4.4 風險分擔 (Risk Sharing)
將部分或全部風險**分攤至能有效管理該風險的第三方**。
| 方式 | 說明 |
| :--- | :--- |
| **保險 (Insurance)** | 適用於硬體資產（如機房設備），將意外事件損失風險轉移給保險公司 |
| **契約違約金條款** | 與供應商簽約時加入懲罰性違約金條款，將未履約造成的損失風險部分轉移給供應商 |
> 📌 **考試重點**：法律責任通常**無法完全轉移**，僅能轉移財務損失。保險適用於硬體資產。
---
## 3.5 風險接受之作法
風險接受涉及組織在全面了解殘餘風險後，決定是否承擔這些風險的過程。
### 3.5.1 影響風險接受準則的因素
| 因素 | 說明 |
| :--- | :--- |
| 業務需求與目標 | 核心業務對風險的承受度直接影響接受標準 |
| 法律、法令、規章及契約要求 | 法規可能有強制性的處理要求 |
| 資源分配狀況 | 預算、人力及技術資源限制可處理的風險數量與深度 |
| 技術成熟度 | 某些風險可能因缺乏成熟技術解決方案而不得不接受 |
| 經費預算 | 降低風險成本過高時，可能選擇接受 |
| 社會與人道主義因素 | 涉及公共安全或人道問題的風險，接受度通常非常低 |
### 3.5.2 殘餘風險不符接受準則時的處理
即使已採取處理措施，殘餘風險仍可能不符合常態接受準則。此時需採取更審慎策略：
| 策略 | 說明 |
| :--- | :--- |
| **決策與記錄** | 若必須接受，應明確註解並包含無視常態準則的**決策衡量理由**，確保透明性與可追溯性 |
| **持續監視** | 定期監視殘餘風險，追蹤威脅演變、偵測新脆弱性、評估現有控制措施有效性 |
| **應變計畫** | 制定應變計畫，在風險事件發生時迅速應對，降低實際損害（與 BCP 緊密相關） |
> 📌 **核心觀念**：資安管理**並非追求零風險**，而是在充分理解並記錄的情況下承擔部分風險，持續監控與管理，確保組織整體利益最大化。
---
## 3.6 國際相關防護及管理標準
### 3.6.1 NIST CSF 2.0 (2024)
美國 NIST 發布的資通安全框架 (Cybersecurity Framework)，自 2014 年首次發布以來最重大的更新。
**六大核心功能**（CSF 2.0 新增「治理」）：
| 功能 | 縮寫 | 說明 |
| :--- | :---: | :--- |
| **治理 (Govern)** | GV | ⭐ **CSF 2.0 新增**。建立並溝通資通安全策略、角色、責任及監督 |
| **識別 (Identify)** | ID | 了解組織的資通安全風險，包括資產、業務環境、治理結構及供應鏈 |
| **保護 (Protect)** | PR | 制定並實施保障措施，限制或遏制資安事件的能力 |
| **偵測 (Detect)** | DE | 識別資通安全事件的發生 |
| **回應 (Respond)** | RS | 制定並實施有關資安事件的行動 |
| **復原 (Recover)** | RC | 制定應急計畫，在事件後恢復能力及服務 |
**CSF 2.0 的重要變革**：
| 變革重點 | 說明 |
| :--- | :--- |
| **擴大適用範圍** | CSF 1.0 主要針對美國關鍵基礎設施；CSF 2.0 明確適用於**所有行業、所有規模的組織** |
| **強調成果導向** | 更注重資安活動帶來的實際「成果」與「成效」，而非僅是實施了哪些控制措施 |
| **強化供應鏈風險管理 (SCRM)** | 在「治理」功能中被明確突出，反映供應鏈攻擊日益頻繁與複雜 |
| **改進實施指南** | 提供快速入門指南、可編輯模板，並強化與 NIST SP 800-53、ISO 27001 等的對應關係 |
| **保持靈活性** | 非合規性標準或清單，而是**風險管理工具**，允許依自身需求定制化實施 |
> 📌 **記憶口訣**：CSF 2.0 六大功能 →「**治識保偵回復**」（治理是新增的核心）。
### 3.6.2 CNS 27005:2024
CNS 27005 是我國國家標準，對應國際標準 ISO/IEC 27005，提供組織資訊安全風險管理的指引。
| 項目 | 說明 |
| :--- | :--- |
| **核心目的** | 為 CNS 27001 中關於風險處理的要求提供指引，整合 CNS 31000（風險管理指導綱要）的原則 |
| **適用範圍** | 所有類型、規模或行業的組織 |
| **關鍵術語** | 風險、威脅、脆弱性、後果、可能性、風險接受準則、風險胃納、剩餘風險 |
| **風險管理過程** | 迭代循環，分為「策略循環」及「運作循環」，包含風險評鑑與風險處理 |
| **全景建立** | 識別內外部環境、建立風險準則（含風險接受準則及風險評鑑執行準則） |
| **風險評鑑** | 風險識別（事件式作法或資產式作法）→ 風險分析 → 風險評估 |
| **風險處理** | 處理選項選擇 → 控制措施判定 → 產出「**適用性聲明 (SOA)**」→ 制定風險處理計畫 |
| **附錄 A** | 提供技術示例與表格（後果尺度、可能性尺度、風險矩陣、典型威脅及脆弱性分類） |
---
### 💡 總結：風險管理流程圖
```mermaid
graph LR
A[全景建立] --> B[風險評鑑]
B --> C{風險是否可接受?}
C -- Yes --> D[風險留存或接受]
C -- No --> E[風險處理]
E --> F(修改、避免或分擔)
F --> G[評估殘餘風險]
G --> C
```
### 💡 總結：考試速記表
| 記憶點 | 內容 |
| :--- | :--- |
| **風險公式** | 風險 = 衝擊 × 可能性 |
| **風險三要素** | 威脅 × 脆弱性 → 衝擊 |
| **最常見的處理方式** | 風險修改（降低） |
| **風險管理目標** | 在最低的防護成本投入下獲得最佳化的安全性（≠ 零風險） |
| **衝擊等級關鍵字** | 高=災難性、中=嚴重、普=有限 |
| **法律遵循性** | 高=刑事、中=行政罰或懲戒、普=一般規範 |
| **系統安全等級判定** | 四構面取**最高者** |
| **風險評鑑組織** | **跨部門**組成，避免單一成員執行 |
| **高階 vs 詳細評鑑** | 高階＝快速簡便但不精確；詳細＝精確但耗時耗資源 |
| **NIST CSF 2.0 新增** | 治理 (Govern)，六大功能：治識保偵回復 |
---
### 第 3 單元：資通安全風險管理
#### 1. 在資通安全風險管理中，「風險」的定義是什麼？
- \(A\) 威脅本身的存在。
- \(B\) 資產的脆弱性。
- \(C\) 威脅利用其相對應脆弱性，造成組織或政府機關資訊資產受到衝擊的可能性。
- \(D\) 資安攻擊造成的直接財務損失。
> **答案：C**
---
#### 2. 資通安全風險管理的最終目標是什麼？
- \(A\) 達到絕對的安全性，不計成本。
- \(B\) 在最低的防護成本投入下獲得最佳化的安全性。
- \(C\) 將所有資安風險完全消除。
- \(D\) 以符合法規最低標準為目標，不考慮其他資安提升措施。
> **答案：B**
---
#### 3. 在風險管理的全景建立中，進行風險評鑑與實作資安各項防護控制措施前，應識別哪些方面的安全需求？
- \(A\) 識別資安需求時，主要關注組織內部環境，不包括外部因素。
- \(B\) 識別資安需求時，主要關注外部環境，不包括內部因素。
- \(C\) 應識別機關內、外各方面的安全需求。
- \(D\) 識別資安需求時，重心放在技術能力與經費預算，可忽略其他重要方面。
> **答案：C**
---
#### 4. 關於「高階風險評鑑」方法的優點，以下何者敘述不正確？
- \(A\) 一開始採用較簡便作法，容易獲得參與人員接受。
- \(B\) 評鑑結果較為精確，能識別所有營運過程或系統的潛在風險。
- \(C\) 把握時效，讓最關鍵且需受保護的資通系統優先被提出與實作。
- \(D\) 可將資源與預算運用於最有利之處。
> **答案：B**
---
#### 5. 在資通系統安全等級設定中，若某資通系統資料外洩將「危及國家安全」，或涉及「特殊屬性之個人資料」外洩導致相關個人身心受到危害，則其「機密性」應被評定為哪個等級？
- \(A\) 高級
- \(B\) 中級
- \(C\) 普級
- \(D\) 無法評估
> **答案：A**
---
#### 6. 下列哪種風險評鑑作法是對資產進行深度識別與鑑別，並詳細列出可能面臨威脅與可能存在的弱點？
- \(A\) 高階風險評鑑作法
- \(B\) 普級風險評鑑作法
- \(C\) 詳細風險評鑑作法
- \(D\) 簡易風險評鑑作法
> **答案：C**
---
#### 7. 在建立風險評鑑組織時，建議應如何組建，以避免產出結果過於主觀？
- \(A\) 由資訊人員或資安人員全權執行，不需徵詢其他部門的意見。
- \(B\) 由單一成員執行所有資通系統風險評鑑工作。
- \(C\) 建議成立「跨部門」風險評鑑組織，並宜包含熟悉業務的承辦人員。
- \(D\) 由高層主管主導評鑑，不需納入跨部門的多元觀點。
> **答案：C**
---
#### 8. 當機關面對風險時，若決定不採取額外行動，而是接受風險可能帶來的後果，這種風險處理方式稱為什麼？
- \(A\) 風險修改
- \(B\) 風險避免
- \(C\) 風險分擔
- \(D\) 風險留存
> **答案：D**
---
#### 9. 針對社交工程攻擊，除了進行演練作業外，本課程指出最經濟有效的控制措施是什麼？
- \(A\) 透過部署高階防火牆即可有效防禦社交工程攻擊。
- \(B\) 強化認知訓練與宣導。
- \(C\) 移除所有對外連線。
- \(D\) 購買資安保險。
> **答案：B**
---
#### 10. 將因機房設備損壞造成的損失風險轉移給保險公司，這種風險處理方式屬於哪一種？
- \(A\) 風險避免
- \(B\) 風險修改
- \(C\) 風險分擔
- \(D\) 風險留存
> **答案：C**
--
# 第四章：資通安全管理面暨認知與訓練應辦事項
> **學習目標**
> 1. 熟悉資通系統分級與防護基準之操作及各等級時程要求。
> 2. 了解 ISMS 導入驗證要求及 ISO/IEC 27000 系列標準體系。
> 3. 掌握資安專責人員配置規定及公務及特定非公務機關差異。
> 4. 認識內部資通安全稽核之三種類型（第一方、第二方及第三方）。
> 5. 掌握業務持續運作演練 (BCP) 之完整管理程序與關鍵指標 (RPO, RTO, MTPD)。
> 6. 理解資安治理成熟度評估模型（能力度 vs 成熟度）及計算方式。
> 7. 釐清各類人員之資安教育訓練時數需求與證照規定。
---
## 4.1 資通系統分級與防護基準
為有效分配資安資源，機關須對資通系統進行分級，並實施對應強度的防護措施。
### 4.1.1 各等級機關之應辦事項時程
| 等級 | 分級完成時限 | 控制措施完成時限 | 後續檢視 |
| :---: | :--- | :--- | :--- |
| **A、B 級** | 初次核定或等級變更後 **1 年內** | 同上 **1 年內** | 每年至少檢視 1 次 |
| **C 級** | 初次核定或等級變更後 **1 年內** | 初次核定或等級變更後 **2 年內** | 每年至少檢視 1 次 |
| **D、E 級** | 無強制要求 | 無強制要求 | — |
> 📌 **考試陷阱**：A/B 級是 1 年內完成分級「**並**」完成控制措施；C 級是 1 年內完成分級，但控制措施放寬到 **2 年內**。
> 📌 若資通系統為**共用性系統**，由該資通系統之主責設置、維護或開發機關判斷是否屬於核心資通系統。
### 4.1.2 資通系統防護需求分級
依據 **機密性 (C)、完整性 (I)、可用性 (A) 及法律遵循性 (L)** 四個構面之衝擊程度，將系統分為三級：
| 等級 | 影響程度關鍵字 | 說明 |
| :---: | :--- | :--- |
| **高 (High)** | 非常嚴重或**災難性** | 涉及國家機密、關鍵基礎設施、刑事責任 |
| **中 (Medium)** | **嚴重** | 涉及敏感個資、區域性服務中斷、行政罰或懲戒 |
| **普 (Low)** | **有限** | 一般公開資訊網站、一般法令規範 |
> 📌 **最終等級判定**：四個構面中取**最高者**為系統的防護需求等級。例如 C=普、I=中、A=普、L=普 → 系統等級為「**中**」。
### 4.1.3 防護基準 (Security Baselines)
資通系統防護基準涵蓋 **7 大構面**，共計 **171 項**控制措施：
| 構面 | 項次 | 控制措施內容 |
| :--- | :---: | :--- |
| **1. 存取控制** | 3 項 | 帳號管理、最小權限、遠端存取 |
| **2. 事件日誌與可歸責性** | 6 項 | 記錄事件、日誌內容、儲存容量、處理失效回應、時戳校時、日誌保護 |
| **3. 營運持續計畫** | 2 項 | 系統備份、系統備援 |
| **4. 識別與鑑別** | 5 項 | 內部使用者識別鑑別、身分驗證管理、鑑別資訊回饋、加密模組鑑別、非內部使用者識別鑑別 |
| **5. 系統與服務獲得** | 8 項 | SSDLC 各階段（需求、設計、開發、測試、部署與維運、委外）、獲得程序、系統文件 |
| **6. 系統與通訊保護** | 2 項 | 傳輸之機密性與完整性、資料儲存之安全 |
| **7. 系統與資訊完整性** | 3 項 | 漏洞修復、資通系統監控、軟體及資訊完整性 |
| 等級 | 控制措施數量 | 防護強度 |
| :---: | :---: | :--- |
| **高** | 78 項 | 涵蓋中級 + 嚴格要求（多因子鑑別、異地備援、源碼掃描、傳輸加密等） |
| **中** | 58 項 | 涵蓋普級 + 進階要求（弱點掃描、完整性驗證、備份測試等） |
| **普** | 35 項 | 基本防護（帳號管理、密碼複雜度、定期更新、日誌保留6個月等） |
---
## 4.2 ISMS 之導入及通過公正第三方驗證
資訊安全管理系統 (ISMS) 是一套系統化的管理制度，用於管理組織的敏感資訊。
### 4.2.1 導入與驗證規定
| 等級 | ISMS 導入要求 | 第三方驗證要求 |
| :--- | :--- | :--- |
| **A、B 級** | 初次核定或等級變更後 **2 年內**，全部核心資通系統導入 CNS 27001 或 ISO 27001 | **3 年內**通過公正第三方驗證，並持續維持有效性 |
| **C 級** | 同上（導入 ISMS 或其他經主管機關認可之標準） | **未要求**驗證 |
| **D、E 級** | 未要求 | 未要求 |
> 📌 **公正第三方驗證**：指通過我國標準法主管機關委託機構認證之機構；驗證證書應有該委託機構之認證標誌。
### 4.2.2 ISO/IEC 27000 系列標準體系
| 分類 | 標準編號 | 內容說明 |
| :--- | :--- | :--- |
| **詞彙** | 27000 | 資訊安全管理系統 — 概觀及詞彙 |
| **要求事項** | **27001** | ISMS 要求事項（**驗證標準**） |
| | 27006-1 | ISMS 審核與驗證機構之要求 |
| **指導綱要** | **27002** | 資訊安全控制措施（Best Practice） |
| | 27003 | ISMS 指導綱要 |
| | 27004 | 監控、測量、分析與評估 |
| | **27005** | 資訊安全**風險管理**指引 |
| | 27007 | ISMS 稽核指導綱要 |
| | 27014 | 資訊安全**治理** |
| **行業應用** | 27011 | 電信組織資訊安全控制措施 |
| | **27017** | **雲端服務**資訊安全控制措施 |
| | 27018 | 公有雲保護 PII 指導綱要 |
| | **27701** | **隱私資訊管理系統** (PIMS) 要求事項 |
### 4.2.3 CNS 27001：2023 章節結構
CNS 27001：2023 等同 ISO/IEC 27001：2022，其章節為：第 1~3 章（適用範圍、引用標準、用語定義）、第 4 章（組織全景）、第 5 章（領導作為）、第 6 章（規劃）、第 7 章（支援）、第 8 章（運作）、第 9 章（績效評估）、第 10 章（改善）。
**附錄 A 控制措施**（共 93 項）：
| 類別 | 項數 |
| :--- | :---: |
| A.5 組織控制措施 | **37** 項 |
| A.6 人員控制措施 | **8** 項 |
| A.7 實體控制措施 | **14** 項 |
| A.8 技術控制措施 | **34** 項 |
> 📌 **記憶口訣**：「組 37、人 8、體 14、技 34」— 合計 93 項。
### 4.2.4 CNS 27002：2023 四大類控制措施
CNS 27002：2023 等同 ISO/IEC 27002：2022，詳細說明 CNS 27001 附錄 A 之控制措施實作指引，分為組織（5.x）、人員（6.x）、實體（7.x）、技術（8.x）四大類。
---
## 4.3 資通安全專責人員
資通安全專責人員，係指**全職**執行資通安全業務者。
### 4.3.1 人力配置要求
| 等級 | 公務機關 | 特定非公務機關 |
| :--- | :--- | :--- |
| **A 級** | 1 年內，**4 人**；須以**專職**人員配置 | 1 年內，**4 人** |
| **B 級** | 1 年內，**2 人**；須以**專職**人員配置 | 1 年內，**2 人** |
| **C 級** | 1 年內，**1 人**；須以**專職**人員配置 | 1 年內，**1 人** |
| **D、E 級** | 無要求 | 無要求 |
> 📌 **記憶口訣**：A=4、B=2、C=1、D/E=0。公務機關強調「專職」。
---
## 4.4 內部資通安全稽核
### 4.4.1 稽核頻率
| 等級 | 稽核頻率 |
| :--- | :--- |
| **A 級** | 每年 **2** 次 |
| **B 級** | 每年 **1** 次 |
| **C 級** | 每 **2 年** 1 次 |
| **D、E 級** | 無要求 |
### 4.4.2 三種稽核類型
| 項目 | 第一方稽核 | 第二方稽核 | 第三方稽核 |
| :--- | :--- | :--- | :--- |
| **性質** | 內部資通安全稽核 | 上級稽核下級，或機關稽核委外廠商 | 公正第三方 ISMS 驗證 |
| **目的** | 自我檢查，確認資安維護計畫實施情形 | 確認下級或廠商符合契約或法規要求 | 取得國際認可之資安管理驗證 |
| **稽核範圍** | **全機關** | 全機關 或 委外廠商 | **驗證範圍** |
| **稽核項目** | 稽核檢核表、資安控制措施 | 稽核檢核表 | 資訊安全控制措施 |
| **法規依據** | 資安責任等級分級辦法 §11 | 資安法 §5、§13；特非機關稽核辦法 §3 | CNS 27001：2023 §9.2.2 |
> 📌 **記憶重點**：第一方 = 自律體現；第二方 = 監督管理；第三方 = 外部認可。
---
## 4.5 業務持續運作演練
業務持續運作演練是確保組織在面臨突發事件時，仍能維持核心業務運作的關鍵。
### 4.5.1 演練頻率
| 等級 | 演練頻率 |
| :--- | :--- |
| **A 級** | 全部核心資通系統，**每年** 1 次 |
| **B、C 級** | 全部核心資通系統，**每 2 年** 1 次 |
| **D、E 級** | 無要求 |
### 4.5.2 關鍵時間指標
| 指標 | 全名 | 定義 | 關注點 | 關聯決策 |
| :--- | :--- | :--- | :--- | :--- |
| **RPO** | Recovery Point Objective | 系統可容忍**資料損失**的最大時間 | 資料損失量 | 決定**備份頻率**（RPO=4hr → 至少每 4 小時備份） |
| **RTO** | Recovery Time Objective | 系統從中斷到**恢復服務**的最大時間 | 服務中斷時間 | 決定**備援機制**（熱備援或冷備援） |
| **MTPD** | Maximum Tolerable Period of Disruption | 業務無法運作的**絕對最長極限** | 組織存亡 | 是所有恢復策略的時間上限 |
| **WRT** | Work Recovery Time | 系統恢復最低運作後到**完全正常**所需時間 | 業務復工 | 含人工資料輸入、積壓處理等 |
**時間指標關係**：
```
MTPD = RTO + WRT
```
> ⚠️ **關鍵約束**：
> - RTO **不可大於** MTPD（否則業務在技術恢復前就已遭受無法承受的損失）
> - 備份週期 **不可大於** RPO（否則資料損失超過容忍範圍）
> - 核心資通系統之 RTO **不宜大於**非核心資通系統之 RTO
> [!NOTE]
> **關於 MTPD 的補充說明**
>
> 上述「MTPD = RTO + WRT」是課本的寫法，我參考金管會轄下證交所[「資訊作業韌性參考指引」](https://twse-regulation.twse.com.tw/m/LawContent.aspx?FID=FL099445)的理解如下：
>
> - **MTPD** 是業務面的容忍上限，指的是「多久內若未恢復到最小可接受服務水準，將造成不可接受的衝擊」，屬於**業務目標**
> - **最小可接受服務水準**（金管會用語，類似 CISM 的 服務交付目標 (SDO) 或 ISO 的 最低營運水準(MBCO)）是業務與技術約定的「最低限度運作水準」
> - **RTO** 是技術人員承諾在多久內恢復到最小可接受服務水準，屬於**技術目標（SLA）**
> - 因此關係應為 **MTPD ≥ RTO**
>
> 📌 **舉例**：公司有 4 個服務櫃台
> - MTPD = 12 小時（業務說：超過就嚴重影響營運）
> - 最小可接受服務水準 = 至少 1 個櫃台運作
> - RTO = 8 小時（技術承諾：8 小時內恢復到最小可接受服務水準）
>
> ⚠️ 不同框架（ISO 22301、NIST、CISM、CISSP）對這些術語定義略有出入，**考試時請以該認證官方教材為準**。
>
> ⚠️ 金管會的定義中，RTO 明確是恢復到「最小可接受服務水準」。雖然 MTPD 沒有明確定義終點，但從邏輯上推論，MTPD 應該是達到最小可接受服務水準的時間上限，也就是 **MTPD ≥ RTO**。
> - 簡單來說，課本的MTPD指的是完全恢復，我的定義是恢復到最小可接受服務水準。
### 4.5.3 系統備份與系統備援
**系統備份**（與 RPO 相關）：
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 訂定 RPO；執行資料備份 |
| **中** | 定期測試備份資料，驗證備份媒體可靠性及資訊完整性 |
| **高** | 備份還原作為營運持續計畫演練一部分；建立**異地備份**機制 |
**系統備援**（與 RTO 相關）：
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 訂定 RTO |
| **中** | 定期測試於 RTO 內由備援設備取代並提供服務 |
| **高** | 備援啟動作為營運持續計畫演練一部分 |
### 4.5.4 營運持續計畫 (BCP) 時程
BCP 時程分為以下主要階段：
| 階段 | 子任務 | 說明 |
| :--- | :--- | :--- |
| **災害發生** | — | 流程起點 |
| **啟動階段** | 緊急處理 → 災害評估 → 是否啟動 → 通報作業 | 立即應對、評估影響、決定是否啟動 BCP |
| **復原階段** | 移轉至備援系統 → 業務處理復原 | 將運作轉移至備援，恢復關鍵業務流程 |
| **重建階段** | 場所復原 → 作業遷移 → 環境測試 | 修復原場所，遷回主系統，驗證環境正常 |
### 4.5.5 業務持續運作管理程序（七步驟）
```mermaid
graph LR
A[1.建立業務持續<br>運作策略] --> B[2.營運衝擊<br>分析BIA]
B --> C[3.識別防禦性<br>控制措施]
C --> D[4.發展<br>復原策略]
D --> E[5.發展<br>營運持續計畫BCP]
E --> F[6.測試與<br>演練]
F --> G[7.維護<br>營運持續計畫BCP]
G -.->|持續循環| B
```
各步驟重點：
1. **建立業務持續運作策略**：定義願景、目標、範圍、原則（高階管理層決策）。
2. **營運衝擊分析 (BIA)**：識別關鍵業務功能及其 IT 依賴性，評估中斷對組織的潛在影響。BIA 步驟包含：識別核心業務功能 → 識別所仰賴資源 → 計算可容許缺少資源時間 → 識別威脅與弱點 → 計算風險 → 確認復原優先順序。BIA 的結果是設定 RPO 和 RTO 的基礎。
3. **識別防禦性控制措施**：依 BIA 結果實施預防性措施（系統冗餘、備份、防火牆等）。
4. **發展復原策略**：針對無法預防的中斷，制定恢復策略（異地備援、雲端備份等），須與 RPO/RTO 一致。
5. **發展營運持續計畫 (BCP)**：將策略具體化為正式文件（含聯絡資訊、應變流程、角色職責、恢復步驟）。
6. **測試與演練**：定期驗證 BCP 可行性，可為桌面演練、模擬演練或全面演練。
7. **維護營運持續計畫 (BCP)**：BCP 是需持續維護的「活文件」，依環境變化定期審查更新。
> 📌 **成功關鍵**：需**高階管理層**支持與調用資源，並須**核心業務所有相關部門**投入，而非僅是資訊部門的責任。
### 4.5.6 ISO/IEC 22301：2019 (BCMS)
| 項目 | 說明 |
| :--- | :--- |
| **標準全名** | 安全與韌性 — 營運持續運作管理系統 — 要求事項 |
| **目的** | 規範實施與維護 BCMS 的結構與要求事項 |
| **適用範圍** | 防止、減少中斷發生可能性、準備、應變及恢復 |
| **對應國內標準** | CNS 22301：2021 |
| **實作指引** | ISO 22313：2020（提供如何實踐 ISO 22301 要求的詳細建議） |
**核心名詞對照**：
| 術語 | 英文 | 說明 |
| :--- | :--- | :--- |
| 業務持續運作 | BC | 中斷期間以預定容量在可接受時間內繼續交付服務的**能力** |
| 業務持續運作管理 | BCM | 實施與維護 BC 的**過程** |
| 業務持續運作管理系統 | BCMS | 建立、實施、維運、監控、審查、維護及改善 BC 的**管理系統** |
| 業務持續運作計畫 | BCP | 指導應變、重啟及恢復的**文件化資訊**（= 營運持續計畫） |
| 營運衝擊分析 | BIA | 分析業務中斷隨時間推移對組織衝擊的**分析工具** |
### 4.5.7 演練實務要求
| 項目 | 要求 |
| :--- | :--- |
| **演練情境** | 應納入業務單位角色；建議評估複合式情境（多種災害同時、供應商中斷、人員短缺、網路攻擊+實體災害） |
| **結果處理** | 依演練發現問題進行「滾動式調整」，更新 BCP 並提報資安長 |
| **時間目標檢查** | 至少針對核心業務訂定 MTPD；中等級以上系統訂定 RTO |
| **PDCA 精神** | 演練目的是為了**改進**，體現計畫-執行-檢查-行動循環 |
---
## 4.6 資通安全治理成熟度
### 4.6.1 評估頻率
| 等級 | 評估頻率 | 備註 |
| :--- | :--- | :--- |
| **A、B 級** | 每年 1 次 | 特定非公務機關僅**關鍵基礎設施提供者**須辦理 |
| **C、D、E 級** | 無要求 | — |
### 4.6.2 資安治理 vs 資安管理
| 項目 | 資安治理 (Governance) | 資安管理 (Management) |
| :--- | :--- | :--- |
| **層次** | 高層決策 | 具體執行 |
| **功能** | 從「組織需求」出發，提供**指導**與**監視** | 負責**規劃、建立、執行、監督** |
| **權責範圍** | 機關首長、資安長、資安治理推動小組 | 資安長、資安管理推動小組、使用者 |
| **運作流程** | 評估 → 指導與監視 | 規劃 → 建立 → 執行 → 監督 → 管理回饋 |
> 📌 **考試重點**：治理是「**方向盤**」（定目標），管理是「**引擎**」（做事情）。兩者相輔相成。
### 4.6.3 資安治理架構（策略、管理、技術三面向）
| 面向 | 流程構面 | 目標範圍 |
| :--- | :--- | :--- |
| **策略面** | S1 資安政策與組織健全 | 政策建立、法規遵循、組織與管理審查 |
| | S2 資安治理架構 | 新興議題評估、利害關係人溝通 |
| | S3 資安資源管理 | 資源確保、專職人員配置 |
| | S4 資安管理監督 | 績效與成果監督、業務持續運作管理 |
| **管理面** | M1 資產管理與風險評鑑 | 風險管理、系統分級與防護 |
| | M2 資訊委外安全管理 | 委外廠商能力、管理及稽核 |
| | M3 資安認知與教育訓練 | 認知與教育訓練 |
| **技術面** | T1 存取控制管理 | 網路安全、權限管理、加密管理 |
| | T2 通訊與作業安全管理 | 惡意軟體、遠距工作、監控、防護、檢測等 |
| | T3 資安事件通報與處理 | 通報應變、日誌保存、情資聯防 |
| | T4 資通系統開發與維護安全管理 | SSDLC 落實 |
### 4.6.4 能力度等級 (ISO/IEC 33020：2015)
「能力度」衡量組織在**單一流程構面**上的執行水平：
| 等級 | 名稱 | 定義 | 累進要求 |
| :---: | :--- | :--- | :--- |
| **Level 0** | 未執行流程 | 組織未建立該流程或無法達成 | — |
| **Level 1** | 已執行流程 | 執行結果已達預先設定目標 | — |
| **Level 2** | 已管理流程 | 執行過程與產出**已被管理** | 需滿足 L1 |
| **Level 3** | 標準化流程 | 已被**標準化**並有效部署 | 需滿足 L1~2 |
| **Level 4** | 可預測流程 | 可透過衡量結果了解成效，已**量化管理** | 需滿足 L1~3 |
| **Level 5** | 最佳化流程 | 基於成效分析或**創新方式**優化流程 | 需滿足 L1~4 |
### 4.6.5 成熟度等級 (ISO/IEC 33004：2015)
「成熟度」衡量組織**整體**資安治理的水準，取決於各流程構面的能力度：
| 等級 | 名稱 | 定義 | 累進要求 |
| :---: | :--- | :--- | :--- |
| **Level 0** | 未成熟型 (Immature) | 未有效執行基本流程 | L1 任一流程構面能力度=0 |
| **Level 1** | 基礎型 (Basic) | 流程可支持業務，達基本要求 | **L1 流程構面**皆達能力度 ≥ 1 |
| **Level 2** | 管理型 (Managed) | 有規劃、執行及監督 | **L1~L2 流程構面**皆達能力度 ≥ 2 |
| **Level 3** | 制度化型 (Established) | **標準化**流程，成為常規作業 | **L1~L3 流程構面**皆達能力度 ≥ 3 |
| **Level 4** | 可預測型 (Predictable) | **量化管理**，可預測結果 | **L1~L4 流程構面**皆達能力度 ≥ 4 |
| **Level 5** | 創新型 (Innovating) | 持續**優化與創新** | **L1~L5 流程構面**皆達能力度 ≥ 5 |
### 4.6.6 成熟度等級與流程構面對應關係
| 成熟度等級 | 對應流程構面 | 分類 |
| :---: | :--- | :---: |
| **5** | S2 資安治理架構 | 擴展流程 |
| **4** | S4 資安管理監督 | 擴展流程 |
| **3** | S3 資安資源管理、T3 資安事件通報與處理、T4 系統開發與維護安全管理 | 擴展流程 |
| **2** | M1 資產管理與風險評鑑、M2 資訊委外安全管理、T1 存取控制管理 | 基礎流程 |
| **1** | S1 資安政策與組織健全、M3 資安認知與教育訓練、T2 通訊與作業安全管理 | 基礎流程 |
> 📌 **判定邏輯**：從 Level 1 往上逐級判斷，該等級所有對應流程構面的能力度都必須達到該等級數字（含以上），才算滿足。**任一構面不足，整體就卡在前一級**。
### 4.6.7 成熟度計算範例
假設某機關各流程構面能力度如下：
| 成熟度等級 | 流程構面 | 能力度 |
| :---: | :--- | :---: |
| 5 | S2 資安治理架構 | 1 |
| 4 | S4 資安管理監督 | 2 |
| 3 | S3 資安資源管理 | 3 |
| 3 | T3 資安事件通報與處理 | **2** ⬅ 瓶頸 |
| 3 | T4 系統開發與維護安全管理 | 4 |
| 2 | M1 資產管理與風險評鑑 | 4 |
| 2 | M2 資訊委外安全管理 | 3 |
| 2 | T1 存取控制管理 | 4 |
| 1 | S1 資安政策與組織健全 | 4 |
| 1 | M3 資安認知與教育訓練 | 4 |
| 1 | T2 通訊與作業安全管理 | 3 |
**判定過程**：
- ✅ **Level 1**：L1 構面（S1=4、M3=4、T2=3）皆 ≥ 1 → 滿足
- ✅ **Level 2**：L1~L2 構面全部 ≥ 2 → 滿足
- ❌ **Level 3**：T3 能力度 = 2，未達 ≥ 3 → **不滿足**
> 🎯 **結論：該機關整體成熟度為 Level 2（管理型）**
---
## 4.7 資通安全教育訓練
### 4.7.1 各類人員年度訓練時數
| 對象 | A 級 | B 級 | C 級 | D 級 | E 級 |
| :--- | :---: | :---: | :---: | :---: | :---: |
| **資安專職人員** | 專業 **12** hr/年 | 專業 **12** hr/年 | 專業 **12** hr/年 | — | — |
| **資安專職以外之資訊人員** | 專業 **3** hr/2年 + 通識 **3** hr/年 | ← | ← | 專業 **3** hr/2年 + 通識 **3** hr/年 | — |
| **一般使用者及主管** | 通識 **3** hr/年 | ← | ← | 通識 **3** hr/年 | 通識 **3** hr/年 |
> 📌 **E 級最簡單**：僅需一般使用者及主管每年 3 小時通識訓練。
---
## 4.8 資通安全專業證照及職能訓練證書
### 4.8.1 證照人數要求
| 等級 | 需持有相關證照及證書之人數 |
| :---: | :--- |
| **A 級** | 至少 **4** 名 |
| **B 級** | 至少 **2** 名 |
| **C 級** | 至少 **1** 名 |
### 4.8.2 公務機關 vs 特定非公務機關之重大差異
| 項目 | 公務機關 | 特定非公務機關 |
| :--- | :--- | :--- |
| **證照要求** | 證照**及**證書**各一張**以上 | 證照**或**證書**一張**以上 |
> 📌 **考試重點**：「**及**」vs「**或**」一字之差！公務機關要求更嚴格，必須**同時**持有證照和證書各至少一張。
### 4.8.3 證照定義
* **資通安全專業證照**：指由主管機關認可之國內外發證機關（構）所核發之資通安全證照。可參考[資通安全專業證照清單](https://moda.gov.tw/ACS/laws/certificates/676)。
* **職能訓練證書**：指完成資通安全職能訓練課程後取得之證書。
---
### 💡 總結：應辦事項 Check List
- [ ] 核心系統是否已在時限內完成分級（A/B級1年、C級1年）並落實防護基準（A/B級1年、C級2年）？
- [ ] A/B 級機關是否已在 2 年內導入 ISMS 並在 3 年內通過第三方驗證？
- [ ] 資安專職人員是否已在 1 年內配置完畢（A=4、B=2、C=1）？
- [ ] 是否按規定頻率完成內部稽核（A=2次/年、B=1次/年、C=1次/2年）？
- [ ] 是否按規定頻率完成 BCP 演練（A=1次/年、B/C=1次/2年）？
- [ ] 備份週期 ≤ RPO？RTO ≤ MTPD？
- [ ] 資安專職人員是否完成 12 小時專業訓練？一般使用者是否完成 3 小時通識？
- [ ] 證照持有是否符合要求（公務：證照**及**證書；特非：證照**或**證書）？
---
### 第 4 單元：資通安全管理面暨認知與訓練應辦事項
#### 1. 依據資通安全責任等級機關應辦事項規定，A 級機關初次受核定或等級變更後，應在多久時間內完成資通系統分級並完成附表十的控制措施？
- \(A\) 1 年內
- \(B\) 2 年內
- \(C\) 3 年內
- \(D\) 無明確時程要求
> **答案：A**
---
#### 2. 依據附表九資通系統防護需求分級原則，當資通系統發生資安事件導致「未經授權之資訊揭露」，對機關營運、資產或信譽產生「嚴重」影響時，其「機密性」防護需求應評定為哪個等級？
- \(A\) 普
- \(B\) 中
- \(C\) 高
- \(D\) 極高
> **答案：B**
---
#### 3. 依據資通安全管理面應辦事項，公務機關 A 級及 B 級的「核心資通系統」應在初次受核定或等級變更後多久完成 ISO 27001 或 CNS 27001 等資訊安全管理系統的導入？
- \(A\) 1 年內
- \(B\) 2 年內
- \(C\) 3 年內
- \(D\) 無要求
> **答案：B**
---
#### 4. 依據《資通安全責任等級分級辦法》規定，A 級公務機關應在機關初次受核定或等級變更後多久時間內，配置幾位資通安全專職人員？
- \(A\) 1 年內，2 人
- \(B\) 1 年內，4 人
- \(C\) 2 年內，2 人
- \(D\) 2 年內，4 人
> **答案：B**
---
#### 5. 關於資通安全稽核的類別，以下何者是組織內部的自我檢查，通常稽核範圍為「全機關」？
- \(A\) 第一方稽核
- \(B\) 第二方稽核
- \(C\) 第三方稽核
- \(D\) 外部稽核
> **答案：A**
---
#### 6. 業務持續運作演練中，「復原時間點目標 \(RPO\)」主要定義了什麼？
- \(A\) 系統從中斷後至恢復服務所需的最大可容忍時間。
- \(B\) 完成備份還原測試所需的時間。
- \(C\) 業務中斷後，對組織可能造成的最大不利衝擊時間。
- \(D\) 系統可容忍資料損失的最大時間要求。
> **答案：D**
---
#### 7. 關於資安治理與資安管理的區分，以下何者敘述正確？
- \(A\) 資安治理由資安長主導，資安管理由機關首長主導。
- \(B\) 資安治理負責具體執行資安措施，資安管理負責提供指導與監視。
- \(C\) 資安治理從組織需求出發，提供指導與監視；資安管理負責規劃、建立、執行與監督。
- \(D\) 兩者權責範圍完全相同，沒有區分必要。
> **答案：C**
---
#### 8. 在資安治理成熟度評估中，Level 3「標準化流程 \(Established Process\)」的定義為何？
- \(A\) 該流程尚未建立或無法達成目標。
- \(B\) 該流程之執行結果已達到預先設定目標。
- \(C\) 該流程已被標準化，並且已被有效地部署於組織中。
- \(D\) 該流程可透過衡量結果了解執行成效，且流程已被量化管理。
> **答案：C**
---
#### 9. 依據資安認知與訓練應辦事項，一般使用者及主管（A、B、C、D 級機關）每年至少應接受多少小時的資通安全通識教育訓練？
- \(A\) 1 小時
- \(B\) 3 小時
- \(C\) 6 小時
- \(D\) 12 小時
> **答案：B**
---
#### 10. 在業務持續運作的「管理程序」中，特別強調成功執行業務持續運作的關鍵，除了高階管理人員的認同與支持外，還需要哪些部門的投入？
- \(A\) 資訊部門的投入是唯一必要的。
- \(B\) 成功運作僅需高階管理層和資安部門的投入，其他部門的角色無關緊要。
- \(C\) 必須是核心業務所有相關部門投入，而非僅是資訊部門的責任。
- \(D\) 外部顧問的投入足以確保成功，無需內部資源參與。
> **答案：C**
--
# 第五章：資通系統防護控制措施
> **🎯 學習目標**
> 1. **存取控制**：理解最小權限、職務區隔、特殊權限管理與帳號生命週期。
> 2. **可歸責性**：掌握日誌 (Log) 管理、NTP 校時、保存要求，以及雜湊函式與 Salt 的應用。
> 3. **營運持續**：區分 RTO / RPO / WRT / MTPD 之差異，熟悉備份策略與異地備份原則。
> 4. **身分鑑別**：認識多因子鑑別 (MFA)、OTP（同步與非同步）、挑戰-回應機制與生物特徵技術。
> 5. **加密技術**：理解對稱與非對稱加密、數位簽章、數位信封原理及金鑰管理。
> 6. **系統生命週期**：了解 SSDLC 各階段之資安要求與等級對應措施。
> 📌 本章對應《資通安全責任等級分級辦法》**附表十**之七大構面控制措施，是技術面考試的**核心重點**。
---
## 5.1 存取控制 (Access Control)
存取控制是資通安全防護的核心基礎，其主要目的在於限制與管理對系統資源的存取權限，確保僅有經過授權的人員才能接觸資料及資源。
> 📌 **回顧第一章**：存取控制是**唯一橫跨 CIA 三面向的共通防護措施**——同時服務於機密性、完整性、可用性。
### 5.1.1 帳號管理
帳號管理涵蓋帳號從建立到失效的整個生命週期，確保所有操作皆有紀錄並符合規定。
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 建立帳號管理機制（申請、建立、修改、啟用、停用、刪除之程序） |
| **中** | ① 逾期臨時及緊急帳號應刪除或禁用 ② 閒置帳號應禁用 ③ 定期審核帳號 ④ 含「普」所有措施 |
| **高** | ① 定義各系統閒置時間或可使用期限 ② 逾時應自動登出 ③ 依機關規定條件使用資通系統 ④ 監控帳號，異常時回報管理者 ⑤ 含「中」所有措施 |
> ⚠️ **考試陷阱**
> - 「自動登出」是**高等級**才要求的，不要誤認為中等級。
> - 「閒置帳號禁用」是**中等級**才開始要求。
> - 「帳號管理機制」是**普等級**（全部等級）都需要的基本功。
### 5.1.2 最小權限 (Least Privilege)
高中等級均須採最小權限原則——僅允許使用者（或代表使用者行為之程序）依機關任務及業務功能，完成指派任務所需之授權存取。普等級則無要求。
### 5.1.3 遠端存取
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | ① 每種遠端存取類型均應先取得授權，建立使用限制、組態需求、連線需求及文件化 ② 權限檢查應於**伺服器端**完成 ③ 監控遠端存取內部網段或後臺之連線 ④ 採用**加密機制** (如 VPN) |
| **中/高** | ⑤ 來源應為已預先定義及管理的**存取控制點** ⑥ 含「普」所有措施 |
### 5.1.4 存取控制之授權原則
> 📌 **考試重點：四大授權原則**
> 1. **業務僅知原則 (Need-to-Know)**：只提供執行業務上所需知道的資訊，最小化資訊洩露風險。
> 2. **最小權限原則 (Least Privilege)**：權限開放時僅允許完成任務所需的最低操作權限。
> 3. **職務區隔 (Separation of Duties)**：避免衝突或監督工作職務由同一人進行，防止濫用職權或串通舞弊。
> 4. **特殊權限管理 (Privileged Access Management, PAM)**：對系統管理者帳號及安全組態設定權限，應採特別控管方式，並詳細記錄特權人員的存取行為。
### 5.1.5 存取控制之類型
| 控制類型 | 說明 | 範例 |
| :--- | :--- | :--- |
| **實體類控制** (Physical) | 透過實體手段限制存取 | 門禁、鎖、警衛、圍牆 |
| **技術類控制** (Technical) | 透過軟硬體技術管理存取 | 密碼鑑別、加解密、生物特徵識別、防火牆 |
| **管理類控制** (Administrative) | 透過政策與程序規範存取行為 | 資安政策、安全認知訓練、風險管理程序 |
---
## 5.2 事件日誌與可歸責性 (Event Logging)
事件日誌是資安防禦的重要組成部分——凡走過必留下痕跡，確保資安事件可被追蹤與分析。
### 5.2.1 記錄事件
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | ① 訂定日誌記錄週期及留存政策，保留**至少 6 個月** ② 確保系統有記錄特定事件功能 ③ 記錄管理者帳號執行之各項功能 |
| **中/高** | ④ 定期審查日誌 ⑤ 含「普」所有措施 |
* **保存項目**：應包含作業系統日誌 (OS event log)、網站日誌 (web log)、應用程式日誌 (AP log) 及登入日誌 (logon log) 等關鍵日誌。
### 5.2.2 日誌紀錄內容 (高中普)
資通系統產生之日誌應包含**事件類型、發生時間、發生位置、使用者身分識別**等資訊。應採用**單一日誌機制**，確保輸出格式之一致性，並依資安政策及法規要求納入其他相關資訊。
### 5.2.3 日誌儲存容量 (高中普)
依據日誌儲存需求、保留政策及法規要求，配置所需之儲存容量。
### 5.2.4 日誌處理失效之回應
| 等級 | 控制措施 |
| :---: | :--- |
| **普/中** | 日誌處理失效時，應採取適當行動 |
| **高** | 需即時通報之失效事件，應於規定時效內對特定人員提出警告 |
### 5.2.5 時戳及校時 (NTP)
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 使用內部時鐘產生時戳，對應 **UTC 或 GMT** |
| **中/高** | 內部時鐘應**定期**與基準時間源同步 |
* **目的**：確保跨系統日誌分析時，時間點具一致性 (Correlation)。
### 5.2.6 日誌資訊之保護
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 日誌存取僅限有權限之使用者 |
| **中** | 運用**雜湊**或其他完整性確保機制（含「普」措施） |
| **高** | 定期備份日誌至**原系統外**之其他實體系統（含「中」措施） |
> 📌 **實務建議**：日誌應拋送至獨立的 Log Server，防止駭客入侵後刪除紀錄。採用 WORM (Write Once Read Many) 儲存媒體更佳。
### 5.2.7 雜湊函式 (Hash Function)
雜湊函式是密碼學的核心工具，用於從任何長度的資料中建立固定長度的「數位指紋」（訊息摘要）。
**特性：**
| 特性 | 說明 |
| :--- | :--- |
| **固定長度** | 不論輸入資料多長，輸出皆為固定長度的摘要值 |
| **抗碰撞性** | 在計算上極難找到兩個不同輸入產生相同雜湊值 |
| **單向性** | 無法從雜湊值回推原始資料（不可逆） |
**常見演算法**：MD5（已不建議）、SHA-256、SHA-512、SHA3-512
**應用：**
* 驗證**資料完整性**（比對雜湊值判斷資料是否遭竄改）。
* 儲存**使用者密碼**（即使資料庫洩漏，攻擊者也難以直接取得原始密碼）。
> ⚠️ **Salt（鹽）技術 — 強化密碼儲存安全**
>
> Salt 是一個**隨機、唯一**的資料字串。系統將 Salt 與密碼結合後再進行雜湊：
>
> **最終雜湊值 = Hash（密碼 + Salt）**
>
> Salt 可防禦以下攻擊：
> 1. **彩虹表攻擊 (Rainbow Table Attack)**：預先計算好的雜湊對照表。加入 Salt 後，即使兩人密碼皆為 "123456"，因 Salt 不同，最終雜湊值也完全不同，彩虹表失效。
> 2. **碰撞攻擊 (Collision Attack)**：因 Salt 不同，相同密碼在資料庫中的雜湊值也不同，攻擊者無法透過相同雜湊值識別出密碼相同的帳戶。
---
## 5.3 營運持續計畫 (Business Continuity Plan, BCP)
確保組織在突發事件或災難情況下，關鍵業務能夠持續運作或快速恢復。
### 5.3.1 關鍵時間指標
> ⚠️ **RPO / RTO / WRT / MTPD（極易混淆，必背）**
| 指標 | 全名 | 定義 | 關注點 | 範例 |
| :--- | :--- | :--- | :--- | :--- |
| **RPO** | Recovery Point Objective | 復原點目標 | **資料損失量** | RPO=4hr → 至少每4小時備份一次，災難最多損失4小時資料 |
| **RTO** | Recovery Time Objective | 復原時間目標 | **服務中斷時間** | RTO=2hr → 系統當機後須在2小時內恢復服務 |
| **WRT** | Work Recovery Time | 工作復原時間 | **恢復至正常水準** | 從系統恢復運作到業務回到災前服務水準的時間（如復原資料、驗證系統正確性） |
| **MTPD** | Maximum Tolerable Period of Disruption | 最大可容忍中斷時間 | **業務存亡** | 業務無法運作的絕對上限，超過將造成不可接受的衝擊 |
**關係**：$MTPD \ge RTO + WRT$
> [!NOTE]
> **關於 MTPD 的補充說明**
>
> 上述「MTPD = RTO + WRT」是課本的寫法，我參考金管會轄下證交所[「資訊作業韌性參考指引」](https://twse-regulation.twse.com.tw/m/LawContent.aspx?FID=FL099445)的理解如下：
>
> - **MTPD** 是業務面的容忍上限，指的是「多久內若未恢復到最小可接受服務水準，將造成不可接受的衝擊」，屬於**業務目標**
> - **最小可接受服務水準**（金管會用語，類似 CISM 的 服務交付目標 (SDO) 或 ISO 的 最低營運水準(MBCO)）是業務與技術約定的「最低限度運作水準」
> - **RTO** 是技術人員承諾在多久內恢復到最小可接受服務水準，屬於**技術目標（SLA）**
> - 因此關係應為 **MTPD ≥ RTO**
>
> 📌 **舉例**：公司有 4 個服務櫃台
> - MTPD = 12 小時（業務說：超過就嚴重影響營運）
> - 最小可接受服務水準 = 至少 1 個櫃台運作
> - RTO = 8 小時（技術承諾：8 小時內恢復到最小可接受服務水準）
>
> ⚠️ 不同框架（ISO 22301、NIST、CISM、CISSP）對這些術語定義略有出入，**考試時請以該認證官方教材為準**。
>
> ⚠️ 金管會的定義中，RTO 明確是恢復到「最小可接受服務水準」。雖然 MTPD 沒有明確定義終點，但從邏輯上推論，MTPD 應該是達到最小可接受服務水準的時間上限，也就是 **MTPD ≥ RTO**。
> - 簡單來說，課本的MTPD指的是完全恢復，我的定義是恢復到最小可接受服務水準。
### 5.3.2 系統備份
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | ① 訂定資料可容忍損失之時間要求（**RPO**） ② 執行系統源碼與資料備份 |
| **中** | ③ 定期測試備份資料，驗證媒體可靠性及資訊完整性 ④ 含「普」措施 |
| **高** | ⑤ 備份還原作為營運持續計畫演練一部分 ⑥ 在與運作系統**不同地點之獨立設施或防火櫃**中儲存備份（**異地備份**） ⑦ 含「中」措施 |
> 📌 依「我國電腦機房異地備援機制參考指引」，主機房與異地備援機房距離應 **30 公里以上**，需考慮地震帶、颱風、土石流等因素，規避同時受災可能性。
### 5.3.3 系統備援
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 無要求 |
| **中** | 訂定系統從中斷後至重新恢復服務之可容忍時間要求（**RTO**） |
| **高** | 原服務中斷時，於可容忍時間內，由備援設備或其他方式取代並提供服務（含「中」措施） |
### 5.3.4 備份策略
| 備份方式 | 說明 | 備份速度 | 還原速度 | 佔用空間 |
| :--- | :--- | :---: | :---: | :---: |
| **完整備份** (Full) | 備份所有資料 | 最慢 | **最快** | 最大 |
| **差異備份** (Differential) | 備份自「上次**完整備份**」後變更的資料 | 中等 | 中等 | 中等 |
| **增量備份** (Incremental) | 備份自「上一次備份（無論類型）」後變更的資料 | **最快** | 最慢 | 最小 |
> ⚠️ **還原範例（必考）**
> 假設星期一完整備份，星期二至五進行備份，星期五資料毀損：
> - **差異備份**：還原星期一完整備份 + 星期四的差異備份 ✅
> - **增量備份**：還原星期一完整備份 + 星期二、三、四的**所有**增量備份（依序回補）⚠️ 最複雜
* **3-2-1 備份原則**：至少 **3** 份備份、使用 **2** 種不同媒體、其中 **1** 份異地保存。
**備份注意事項：**
- 事先評估備份範圍，避免遺漏重要資料。
- 定期檢驗備份媒體是否仍有合適的存取設備（相容性）。
- 定期確認備份檔案格式仍有合適的應用軟體可開啟。
- 備份資料回復測試應先於**專屬媒體**上執行，防止復原失敗造成資料毀損。
---
## 5.4 識別與鑑別 (Identification & Authentication)
識別與鑑別是資通安全防護的第一道關卡——確認「你是誰 (Identification)」以及「驗證你真的是你 (Authentication)」。
### 5.4.1 內部使用者之識別與鑑別
| 等級 | 控制措施 |
| :---: | :--- |
| **普/中** | 資通系統應具備唯一識別及鑑別使用者之功能，**禁止使用共用帳號** |
| **高** | 對資通系統之存取採取**多因子鑑別 (MFA)** 技術（含「中/普」措施） |
### 5.4.2 身分驗證管理
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | ① 預設密碼初次登入應**立即變更** ② 身分驗證資訊**不以明文傳輸** ③ 帳戶鎖定：失敗 **5 次**後，**15 分鐘**內不允許登入 ④ 強制最低密碼複雜度（文字+數字+符號+大小寫），強制效期限制 ⑤ 密碼不可與**前 3 次**相同 ⑥ 上述④⑤對非內部使用者得由機關自行規範 |
| **中/高** | ⑦ 防範自動化程式登入或密碼更換嘗試（如 CAPTCHA） ⑧ 密碼重設需重新身分確認，發送**一次性及具時效性**符記（含「普」措施） |
> 📌 **密碼安全數字速記**
>
> | 項目 | 數字 |
> | :--- | :--- |
> | 登入失敗鎖定次數 | **5 次** |
> | 鎖定時間 | **15 分鐘** |
> | 密碼歷程不可重複 | **前 3 次** |
> | 建議最低長度 | **8 碼** |
### 5.4.3 鑑別資訊回饋 (高中普)
資通系統應遮蔽鑑別過程中之資訊（輸入密碼時顯示星號 `****`）。
### 5.4.4 加密模組鑑別 (高中)
密碼應經**雜湊**或其他適當方式處理後儲存，確保即使資料庫洩漏，攻擊者也難以直接取得原始密碼。
### 5.4.5 非內部使用者之識別與鑑別 (高中普)
資通系統應識別及鑑別**非機關**使用者（或代表機關使用者行為之程序）。
### 5.4.6 使用者識別符 (Identifier) 管理
| 要求 | 說明 |
| :--- | :--- |
| **唯一性** | 每位使用者擁有唯一識別符，確保可歸責性，不得共用帳號 |
| **連結真實身分** | 在資通系統中代表使用者身分 |
| **命名規則** | 應發展命名格式並遵循（如 Firstname_Lastname） |
| **不代表職位** | 識別符應基於個體，非職責，避免職位變動需改帳號 |
| **生命週期管理** | 有申請、異動及刪除程序，與人事異動結合，需授權主管核准 |
| **定期盤查** | 發現已離職或非授權識別符應移除 |
| **暫停期** | 刪除後應暫停一段時間，不新增相同識別符，避免稽核混淆 |
### 5.4.7 鑑別因子與多因子鑑別 (MFA)
**三大鑑別因子：**
| 類型 | 說明 | 範例 |
| :--- | :--- | :--- |
| **所知 (Something you Know)** | 依賴使用者記憶的資訊 | 密碼、PIN 碼 |
| **所有 (Something you Have)** | 依賴使用者擁有的實體物品 | 晶片卡、手機、OTP Token、USB Key |
| **所是 (Something you Are)** | 依賴使用者的生理特徵 | 指紋、虹膜、臉部辨識 |
> ⚠️ **MFA 定義（考試必考）**
>
> **多因子鑑別 (MFA)** 必須結合**兩種以上不同類型**的因子。
> * ✅ 密碼 (所知) + 手機 OTP (所有) = MFA
> * ✅ 晶片卡 (所有) + 指紋 (所是) = MFA
> * ❌ 密碼 (所知) + PIN 碼 (所知) = 🚫 **不是** MFA（同一類型）
### 5.4.8 一次性通行碼 (OTP) 技術
OTP (One-Time Password) 每次產生的通行碼只能使用一次，可防止竊聽及猜測攻擊。
**同步式 vs 非同步式：**
| 特性 | 同步式 OTP | 非同步式 OTP |
| :--- | :--- | :--- |
| **同步機制** | 基於**時間**或事件計數 | 無時間同步 |
| **產生依據** | 時間 + 共享金鑰 → OTP | 伺服器發送的**隨機挑戰值** + 共享金鑰 → OTP |
| **流程** | Token 與伺服器各自用相同時間和金鑰計算 OTP，比對是否一致 | 伺服器發出 Challenge → 使用者輸入 Token → Token 用挑戰值和金鑰計算回應 → 伺服器比對 |
| **代表應用** | Google Authenticator (TOTP) | 傳統硬體 Token |
### 5.4.9 挑戰-回應 (Challenge-Response) 鑑別技術
基於**非對稱金鑰**的身分鑑別機制，又稱**數位簽章式身分驗證**：
1. 使用者發送登入請求。
2. 伺服器產生隨機挑戰值（如 232443）並傳送給客戶端。
3. 客戶端用使用者的**私鑰**對挑戰值加密，產生回應（如 611431）。
4. 伺服器用使用者的**公鑰**解密回應，比對是否與原始挑戰值一致。
5. 若一致，驗證成功。
> 📌 優點：雙方不必分享共同的金鑰，不必輸入任何通行碼即可完成鑑別。
### 5.4.10 生物特徵鑑別技術
* **特質**：最昂貴、最複雜、也最能識別人員身分的鑑別技術。
* **登錄步驟** (以指紋為例)：登錄請求 → 輸入指紋 → 擷取特徵值 → 轉換成數位內容 → 加密 → 回傳 → 解密 → 保存於伺服器。
* **鑑別步驟**：擷取特徵值 → 轉換成數位內容 → 加密 → 傳送 → 解密 → 與註冊範本**特徵值比對** → **相似度判斷**（超過閾值即驗證成功）。
* **社會接受性**：較低（隱私疑慮、侵入性及傳染病風險等考量）。
### 5.4.11 符記 (Token) 類型
| 類型 | 特點 |
| :--- | :--- |
| **記憶卡** | 無微處理器，僅有磁條，只存放鑑別資訊。使用者需輸入 PIN 碼，將帳號+PIN+卡內資訊傳送至後端伺服器比對。 |
| **智慧卡** | 具備微處理器與積體電路，**可記憶也可運算**。具防拆解與竄改保護機制。可存放生物特徵碼、執行加密運算。 |
* 依感應方式可分為：**接觸式**與**非接觸式**
* 外型：卡片式、隨身型計算機（OTP 產生器）、鑰匙環 USB 符記
### 5.4.12 通行碼攻擊與防護
| 攻擊手法 | 防護措施 |
| :--- | :--- |
| 字典猜測法 | 強制密碼長度至少 8 碼，包含文字、數字、符號、大小寫，且在字典中查不到 |
| 暴力破解 | 限制來源 IP 登入失敗次數 + 帳戶鎖定機制 |
| 通行碼監聽 | 不以明碼傳輸（使用 HTTPS）、不以明碼儲存（雜湊 + Salt） |
| 彩虹表攻擊 | 密碼加 Salt 後雜湊儲存 |
| 帳號重複利用 | 區分公務與私人服務密碼，定期更換，系統判斷不重複使用 |
---
## 5.5 系統與服務獲得 (SSDLC)
安全系統發展生命週期 (Secure SDLC) 強調在專案各階段及早加入安全思維，以打造具備安全體質的資通系統。
### 5.5.1 各階段安全要求
| 階段 | 高 | 中 | 普 |
| :--- | :--- | :--- | :--- |
| **需求** | 確認系統安全需求（機密性、可用性、完整性） | ← 同左 | ← 同左 |
| **設計** | ① 識別威脅，進行風險分析評估 ② 回饋需求階段，提出安全需求修正 | ← 同左 | 無要求 |
| **開發** | ① 執行**源碼掃描** ② 嚴重錯誤通知機制 ③ 含中/普措施 | ① 針對安全需求實作控制措施 ② 避免軟體常見漏洞 ③ 錯誤頁面僅顯示簡短訊息及代碼 | ← 同左 |
| **測試** | 執行**滲透測試** + 弱點掃描 | 執行**弱點掃描** | ← 同左 |
| **部署與維運** | ① 版本控制與變更管理 ② 含普級措施 | ← 同左 | ① 更新與修補 ② 關閉不必要服務及埠口 ③ 不使用預設密碼 ④ 源碼備份 |
| **委外** | 將各階段安全需求納入委外契約 | ← 同左 | ← 同左 |
### 5.5.2 獲得程序
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 識別第三方軟體、服務、函式庫或其他元件 |
| **中/高** | 開發、測試及正式作業環境應**區隔** |
### 5.5.3 系統文件 (高中普)
應儲存與管理系統發展生命週期之相關文件。
---
## 5.6 系統與通訊保護 (Cryptography)
系統與通訊保護旨在確保資訊在傳輸、儲存及處理過程中的機密性、完整性與可用性，主要透過加密與簽章技術來實現。
### 5.6.1 傳輸之機密性與完整性
| 等級 | 控制措施 |
| :---: | :--- |
| **普/中** | 無要求 |
| **高** | ① 採用加密機制防止未授權揭露或偵測變更 ② 使用**公開、國際機構驗證且未遭破解**之演算法 ③ 支援演算法**最大長度金鑰** ④ 金鑰或憑證**定期更換** ⑤ 伺服器端金鑰保管應訂定管理規範 |
> 📌 實作方式：HTTP**S** (TLS 1.2/1.3)、SSH、SFTP、VPN 等加密傳輸協定。金鑰與加密資料應**分開存放**。
### 5.6.2 資料儲存之安全 (高)
重要組態設定檔案及具保護需求資訊應**加密**或以其他適當方式儲存。中普等級無要求。
### 5.6.3 加解密技術比較
| 類型 | 金鑰數量 | 特性 | 常見演算法 | 適用場景 |
| :--- | :--- | :--- | :--- | :--- |
| **對稱式** | **1 把** (加密解密同一把) | 速度快，但金鑰傳遞困難 | AES, DES, 3DES, RC4 | 大量資料加密（硬碟及檔案） |
| **非對稱式** | **2 把** (公鑰+私鑰) | 速度慢，安全性高 | RSA, ElGamal, ECC | 身分鑑別、數位簽章、金鑰交換 |
> ⚠️ **對稱式金鑰數量公式（考試愛考）**
>
> N 個使用者需要 **N(N-1)/2** 把金鑰。
> - 3 人 → 3 把
> - 10 人 → 45 把
> - 1,000 人 → 499,500 把
>
> **非對稱式金鑰數量**：N 個使用者需要 **2N** 把金鑰（每人一對公私鑰）。
> - 1,000 人 → 僅 2,000 把 ← 金鑰管理大幅簡化
**對稱式 vs 非對稱式優缺點整理：**
| 比較項目 | 對稱式 | 非對稱式 |
| :--- | :--- | :--- |
| **速度** | 快 ✅ | 慢 |
| **金鑰管理** | 困難（N(N-1)/2） | 容易（2N）✅ |
| **金鑰傳遞** | 需安全通道交換 | 公鑰可公開傳送 ✅ |
| **機密性** | ✅ | ✅ |
| **不可否認性** | ❌ 無法提供 | ✅ 可提供 |
### 5.6.4 數位簽章 (Digital Signature)
* **功能**：確保**完整性** (Integrity)、**鑑別性** (Authentication)、**不可否認性** (Non-repudiation)。
* **原理**：
1. 發送者先對原始資料進行**雜湊**，得到訊息摘要 (Message Digest)。
2. 發送者用**私鑰**加密訊息摘要 → 產生數位簽章。
3. 接收者用發送者的**公鑰**解密數位簽章 → 取得原始摘要。
4. 接收者對收到的資料重新雜湊，比對兩個摘要是否一致。
> 📌 **記憶口訣**：「**私簽公驗**」— 私鑰簽署，公鑰驗證。
### 5.6.5 數位信封 (Digital Envelope)
結合對稱式與非對稱式加密的優點：
1. 用「**對稱金鑰**（隨機產生的 Session Key）」加密**大量資料**（速度快）。
2. 再用接收者的「**公鑰**」加密那把對稱金鑰一起傳送（安全傳遞金鑰）。
3. 接收者用自己的「**私鑰**」解開對稱金鑰，再用對稱金鑰解密資料。
### 5.6.6 加密技術強度
加密技術強度衡量其密碼被破解所需花費的時間與資源，主要受以下因素影響：
- **演算法強度**：應使用公開且經國際驗證的演算法。
- **金鑰長度**：較長的金鑰長度強度較高。
- **金鑰保護機制**：安全的金鑰保管是基礎。
- **亂數產生器不可預測性**：金鑰產生的隨機性。
> 📌 密碼系統的安全性**不在於演算法的保密**，而在於經得起公開挑戰。目前加密被成功攻擊的原因大部分屬**人為因素**（不正確實作、不安全的金鑰保密機制）。
---
## 5.7 系統與資訊完整性
### 5.7.1 漏洞修復
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 漏洞修復應測試有效性及潛在影響，並定期更新 |
| **中/高** | 定期確認漏洞修復狀態（含「普」措施） |
### 5.7.2 資通系統監控
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 發現被入侵跡象時，應**通報機關特定人員** |
| **中** | 監控系統以偵測攻擊與未授權連線，識別未授權使用 |
| **高** | 採用**自動化工具**監控進出通信流量，發現異常時進行分析 |
### 5.7.3 軟體及資訊完整性
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 使用者輸入資料合法性檢查應置於**伺服器端**（防止 XSS、SQL Injection） |
| **中** | ① 使用完整性驗證工具偵測未授權變更 ② 違反完整性時實施安全保護措施 |
| **高** | 定期執行軟體與資訊完整性檢查 |
> 📌 輸入驗證務必在**伺服器端**執行——客戶端檢查可被繞過，僅供使用者體驗參考。
---
## 5.8 媒體控管及可攜式設備 (Media Control)
* **USB 及可攜式設備**：原則上禁止使用，若必須使用需經核准並掃毒。
* **資料銷毀 (Sanitization)**：
| 媒體類型 | 建議銷毀方式 | 說明 |
| :--- | :--- | :--- |
| **傳統硬碟 (HDD)** | 消磁、實體破壞、覆寫 | NIST 新觀點：現代 HDD 進行**單次覆寫** (Single Pass) 已足夠安全 |
| **固態硬碟 (SSD)** | **加密抹除** (Cryptographic Erase) 為首選 | 單純覆寫對 SSD 效果不佳（因 Wear Leveling 技術），且耗損壽命 |
---
## 📝 第五章考試重點速記
| 關鍵數字 | 內容 |
| :--- | :--- |
| **6 個月** | 日誌保留最少期限 |
| **5 次** | 帳戶鎖定之登入失敗次數 |
| **15 分鐘** | 帳戶鎖定時間 |
| **前 3 次** | 密碼不可重複使用次數 |
| **30 公里** | 異地備援機房建議最小距離 |
| **N(N-1)/2** | 對稱式加密金鑰數量公式 |
| **2N** | 非對稱式加密金鑰數量 |
| 等級專屬功能 | 高 | 中 | 普 |
| :--- | :---: | :---: | :---: |
| 多因子鑑別 (MFA) | ✓ | — | — |
| 源碼掃描 | ✓ | — | — |
| 滲透測試 | ✓ | — | — |
| 弱點掃描（SSDLC測試階段） | ✓ | ✓ | ✓ |
| 異地備份 | ✓ | — | — |
| 傳輸加密 | ✓ | — | — |
| 自動化監控 | ✓ | — | — |
| 帳號自動登出 | ✓ | — | — |
| 日誌異地備份 | ✓ | — | — |
| 密碼雜湊儲存 | ✓ | ✓ | — |
---
### 第 5 單元：資通系統防護控制措施
#### 1. 依據資通系統防護基準的「帳號管理」措施，以下哪項敘述是「普級」機關所需建立的基本要求？
- \(A\) 機關應定義各系統之閒置時間。
- \(B\) 資通系統閒置帳號應禁用。
- \(C\) 建立帳號管理機制，包含帳號之申請、建立、修改、啟用、停用及刪除之程序。
- \(D\) 監控資通系統帳號，如發現帳號違常使用時回報管理者。
> **答案：C**
---
#### 2. 關於對稱式加解密演算法（如 AES），下列何者是其主要的特點？
- \(A\) 加密與解密使用不同的金鑰。
- \(B\) 無法保證資料機密性。
- \(C\) 加解密速度比非對稱式慢。
- \(D\) 加密與解密使用同一把金鑰。
> **答案：D**
---
#### 3. 關於資通系統「日誌紀錄內容」的要求，以下何者是所有等級（普中高）遵循的「基本資訊內容」原則？
- \(A\) 日誌應包含事件類型、發生時間、發生位置及相關使用者身分識別等資訊。
- \(B\) 日誌記錄應僅限於系統層級的錯誤訊息，以減少儲存空間。
- \(C\) 日誌資料只需在系統發生異常時才啟動記錄，平時可關閉。
- \(D\) 日誌的輸出格式應能根據不同部門的需求，自訂多種樣式。
> **答案：A**
---
#### 4. 關於營運持續計畫之「復原點目標」\(RPO\)，主要是衡量組織對下列何者的容忍度？
- \(A\) 服務中斷的時間長度。
- \(B\) 資料損失的時間量。
- \(C\) 維修人員到場的速度。
- \(D\) 設備更新的經費。
> **答案：B**
---
#### 5. 在資料備份方式中，哪一種備份方式在還原時最為複雜，需要先還原最近一次的完整備份，然後依序還原所有自上次完整備份以來的備份？
- \(A\) 完整備份。
- \(B\) 差異備份。
- \(C\) 增量備份。
- \(D\) 鏡像備份。
> **答案：C**
---
#### 6. 為了顯著提高身分驗證的強度，降低帳號被盜用的風險，資通系統存取應採取的鑑別技術是？
- \(A\) 多因子鑑別技術。
- \(B\) 變更預設密碼。
- \(C\) 唯一識別功能。
- \(D\) 帳戶鎖定機制。
> **答案：A**
---
#### 7. 安全系統發展生命週期 \(SSDLC\) 強調於專案各階段及早加入安全思維，以打造具備安全體質的資通系統。以下哪個選項「不是」SSDLC 的實作階段之一？
- \(A\) 需求階段。
- \(B\) 銷售階段。
- \(C\) 開發階段。
- \(D\) 部署與維運階段。
> **答案：B**
---
#### 8. 關於加密金鑰或憑證的管理，以下何者敘述不正確？
- \(A\) 加密金鑰或憑證應定期更換。
- \(B\) 避免使用萬年憑證，增加被破解風險。
- \(C\) 伺服器端之金鑰保管應訂定管理規範。
- \(D\) 加密金鑰與加密資料應存放在同一位置，方便管理。
> **答案：D**
---
#### 9. 關於系統漏洞修復的措施，以下何者是正確的？
- \(A\) 系統漏洞修復應直接在正式環境進行，以節省時間。
- \(B\) 只需注意廠商的安全通告，無需關注 CVE 等網站。
- \(C\) 漏洞修復應測試有效性及潛在影響，並定期更新。
- \(D\) 由弱點掃描檢出之系統漏洞，無需定期追蹤修復進度。
> **答案：C**
---
#### 10. 在儲存媒體安全丟棄或銷毀前，應採取哪些措施以防止資料洩漏？
- \(A\) 刪除資料後，無需進一步處理即可安全丟棄儲存媒體。
- \(B\) 對儲存媒體進行實體破壞後，不須確認資料是否已被徹底銷毀。
- \(C\) 應先安全的刪除資料或進行實體的破壞。
- \(D\) 無需特別處理，直接丟棄即可。
> **答案：C**
---
# 第六章：資通安全技術面應辦事項 ― 資通安全之防護及偵測
> **學習目標**
> 1. **惡意程式防護**：了解防毒軟體的部署方式與管理重點，區分傳統防毒與 EDR 之差異。
> 2. **防火牆技術**：掌握網路防火牆與應用程式防火牆 (WAF) 的運作原理與互補關係。
> 3. **郵件安全**：認識電子郵件過濾機制的判斷技術（含貝氏演算法）與部署模式。
> 4. **入侵偵測**：比較 IDS（監聽）與 IPS（阻擋）、特徵比對與異常偵測。
> 5. **APT 防禦**：理解進階持續性威脅的攻擊特色與多層次防禦策略。
> 6. **SOC 機制**：了解資通安全威脅偵測管理中心的監控範圍與聯防架構。
> 7. **GCB 組態基準**：掌握 GCB 的目的、類別項目與導入流程。
> 8. **VANS 弱點通報**：認識政府機關資安弱點通報機制的目的與服務。
> 9. **EDR 端點防護**：了解端點偵測及回應系統的技術類型與選購考量。
---
## 6.1 「防毒軟體」之安全防護
防毒軟體是資安防護最基礎的工具，主要防止惡意程式入侵。
### 6.1.1 惡意程式類型
| 類型 | 說明 |
| :--- | :--- |
| **病毒 (Virus)** | 感染其他合法程式進行傳播，執行時造成破壞 |
| **蠕蟲 (Worm)** | **獨立運行**，透過網路自我複製，不需使用者互動即可大規模感染 |
| **間諜軟體 (Spyware)** | 監控使用者行為、竊取個資，在使用者不知情下運行 |
| **後門程式 (Backdoor)** | 繞過正常驗證，讓攻擊者**遠端控制**受感染系統 |
| **木馬程式 (Trojan)** | **偽裝**成合法軟體，誘騙使用者下載執行 |
### 6.1.2 惡意程式的來源
電子郵件（最常見）、USB 硬碟、網站瀏覽（掛馬網站）、即時通訊、檔案分享（P2P 及雲端）。
### 6.1.3 部署方式（多層次防護）
| 部署位置 | 說明 |
| :--- | :--- |
| **個人電腦與伺服器防毒** | 保護單一端點與企業核心服務，兩者相輔相成構成基礎防禦 |
| **電子郵件防毒閘道** | 部署於 DMZ 網段（如 SMTP AntiVirus），郵件進入內部前先掃描過濾 |
| **上網防毒閘道** | 部署於內部與外部網路之間（如 HTTPS/FTP/POP3 AntiVirus），監控上網流量 |
### 6.1.4 管理重點
1. **定期自動更新病毒碼**：過舊的病毒碼使防毒軟體形同虛設。
2. **病毒感染事件與趨勢定期分析**：檢視日誌，了解感染類型與來源，調整資安策略。
3. **避免未安裝防毒軟體的電腦上線**：配合 **NAC** 設備，強制檢查設備是否符合安全規範。
4. **防火牆控管未經防毒閘道過濾的連線行為**：確保關鍵流量須經掃描才能進入內網。
5. **採用不同廠牌**：「個人電腦及伺服器防毒」與「防毒閘道」可採不同廠牌 → **縱深防禦**的應用，避免單一廠商漏洞導致全面失效。
### 6.1.5 選購考量
病毒偵測的精準度（參考第三方測試報告）、對電腦效能的影響、是否提供**中央控管機制**（統一派送更新、設定策略、監控端點）。
---
## 6.2 「網路防火牆」之安全防護
網路防火牆是網路邊界的守門員，依據規則允許或限制資料傳輸，可以是專屬硬體設備或架設在一般硬體上的軟體。
### 6.2.1 主要用途
1. **區隔不同安全等級網段**：外部網路 (Internet)、內部網路 (LAN)、DMZ 區。
2. **過濾資料封包**：控制來源 IP、目的 IP、Port、Protocol，阻擋非法連線。
3. **提供稽核與控制**：記錄所有被允許或拒絕的連線行為，供事件追溯與分析。
### 6.2.2 網路區域架構
| 區域 | 說明 |
| :--- | :--- |
| **外部網路 (Internet)** | 公眾區域，風險最高 |
| **DMZ (非軍事區)** | 放置對外服務伺服器（Web, Mail），即使 DMZ 被入侵，攻擊者仍需突破防火牆才能進入內網 |
| **內部網路 (Intranet)** | 員工日常工作及敏感資料，嚴格限制存取 |
> 📌 **防火牆部署原則**：只允許必要服務（如 HTTPS、Mail）進入 DMZ，其他存取完全禁止。
### 6.2.3 高可用度部署 (HA)
防火牆是網路關鍵節點，一旦故障可能導致網路癱瘓。建議部署**兩台防火牆**配置為 HA 模式：一台 Active 處理流量，一台 Standby 備援，故障時自動接手。
### 6.2.4 管理重點
1. **防火牆存取規則的變更管理程序**：建立「變更申請、核准及記錄」流程。
2. **防火牆存取紀錄的即時匯出與保留**：日誌**即時匯出**至集中式日誌伺服器。
3. **定期產出異常存取統計分析報表**：主動發現潛在威脅。
4. **防火牆存取控管規則定期盤查**：檢查規則有效性、移除冗餘或衝突規則。
### 6.2.5 選購考量
防火牆本身的安全性（廠商信譽、更新頻率）、可區隔的網路區段數（網路埠數量）、可支援的傳輸頻寬大小（吞吐量）。
---
## 6.3 「應用程式防火牆 (WAF)」之安全防護
### 6.3.1 角色及運作原理
* **定義**：專門針對**應用層封包**進行管控的防火牆，最常見的名稱是「**網站應用程式防火牆 (Web Application Firewall, WAF)**」。
* **與傳統防火牆的關係**：**互補而非取代**。網路防火牆管 IP/Port (L3/L4)，WAF 管 HTTP/HTTPS 內容 (L7)。
* **運作方式**：位於 HTTP 流量與網站應用程式之間，充當守門員。合法流量通過，惡意流量被偵測並阻擋。
### 6.3.2 用途
偵測並阻擋應用層攻擊：SQL Injection、XSS（跨站腳本）、路徑遍歷、遠端檔案包含、命令注入等 **OWASP Top 10** 威脅。
### 6.3.3 偵測與過濾技術
| 技術 | 說明 | 優缺點 |
| :--- | :--- | :--- |
| **白名單 (Whitelist)** | 只允許列在白名單的通過，其他一律拒絕 | 理論最安全，可防未知攻擊；但難以 100% 涵蓋，容易**誤擋** |
| **黑名單 (Blacklist)** | 列在黑名單的一律拒絕 | 實施容易，已知攻擊防禦好；但**無法防禦未知或變種攻擊** |
| **攻擊特徵判斷 (Signature)** | 基於已知攻擊特徵碼資料庫，**目前較常用** | 偵測效率高且準確；但有誤判與漏判，需定期更新特徵碼 |
### 6.3.4 類型與部署方式
| 類型 | 部署方式 | 優點 | 適用 |
| :--- | :--- | :--- | :--- |
| **硬體式 WAF** | 獨立專用硬體，部署在 Web Server 群組前方，扮演**反向代理** | 高性能、高吞吐量，對後端效能影響小 | 大型企業、高流量網站 |
| **軟體式 WAF** | 安裝在 Web Server 上，作為模組運行 | 部署彈性高、成本低、與應用程式整合度高 | 中小規模，需考量與 Server 共享資源 |
### 6.3.5 管理重點與選購考量
* **管理**：存取規則的變更管理（申請、核准及記錄）、異常攻擊事件的匯出與分析。
* **選購**：處理效能、**中文 URL 及傳輸內容的判斷能力**、HTTPS 加密連線的解密與過濾能力。
---
## 6.4 「電子郵件過濾機制」之安全防護
電子郵件過濾機制一般指**垃圾郵件過濾系統 (Anti-Spam System)**，是郵件安全的第一道防線。
### 6.4.1 用途
1. **過濾垃圾與廣告郵件**：減少使用者信箱中的垃圾郵件。
2. **避免電子郵件社交工程攻擊**（最重要的安全用途）：識別釣魚郵件、詐騙郵件等。
### 6.4.2 垃圾郵件判斷技術
| 技術 | 說明 |
| :--- | :--- |
| **連線模式** | 判斷寄件伺服器 IP、連線頻率、連線行為模式 |
| **關鍵字比對** | 檢查主旨和內容是否含常見垃圾郵件關鍵字（如「中獎」、「免費」） |
| **內容過濾條件** | 分析郵件格式、標頭、附件類型，偵測標頭偽造或可疑 HTML |
| **外部資料庫比對** | 與外部黑名單（如 **RBL, Real-time Blackhole List**）比對 |
| **貝氏演算法 (Bayesian)** | 分析垃圾與正常郵件的詞彙頻率建立模型，具備**學習能力**，可透過使用者標記訓練 |
| **圖片辨識技術** | 分析圖片中是否包含文字或已知惡意圖片特徵，對抗圖片垃圾郵件 |
### 6.4.3 部署方式
| 模式 | 說明 | 故障行為 | 適用 |
| :--- | :--- | :--- | :--- |
| **匣道模式 (Mail Relay)** | 部署在 Internet 與內部 Mail Server 之間，作為中繼站 | **Fail Close**：故障時信件無法進出（安全優先） | 郵件安全性要求極高 |
| **Bridge 模式**（較少見） | 直接部署在網路線路上，作為橋接器 | **Fail Open**：故障時自動 Bypass（連通性優先，安全性降低） | 網路連通性要求極高 |
### 6.4.4 管理重點與選購考量
* **管理**：定期自動更新垃圾郵件辨識特徵碼、規則變更管理程序。
* **選購**：垃圾郵件判斷精準度（偵測率 vs 誤判率）、處理效能、**中文信件或多國語言的支援能力**、全文檢索支援能力、圖片廣告信件的支援能力。
---
## 6.5 「IDS 與 IPS」之安全防護
入侵偵測系統 (IDS) 與入侵防禦系統 (IPS) 旨在識別網路中的異常行為與攻擊行為。
### 6.5.1 功能差異
| 比較 | IDS (Intrusion Detection System) | IPS (Intrusion Prevention System) |
| :--- | :--- | :--- |
| **部署方式** | **旁路監聽 (Passive)**：複製流量分析 (Mirror Port) | **串接 (Inline)**：流量實際流經設備 |
| **反應方式** | 發現攻擊時發出**告警 (Alert)**，**不主動阻擋** | 發現攻擊時直接**阻擋 (Block/Drop)** |
| **對網路影響** | **不影響**網路效能與傳輸 | 即時防護；但誤判 (False Positive) 會導致正常服務中斷 |
> 📌 **重要限制**：IDS/IPS 在未進行解密的情況下，**無法識別 SSL 加密連線**（如 HTTPS、SMTPS、FTPS）中的內容，攻擊者可藉加密流量隱藏惡意行為。
### 6.5.2 偵測技術
| 技術 | 又稱 | 原理 | 優點 | 缺點 |
| :--- | :--- | :--- | :--- | :--- |
| **誤用偵測** | 特徵比對 (Signature-based) | 建立攻擊特徵資料庫（黑名單） | 誤判率低 (False Positive 低) | **無法偵測未知攻擊** (Zero-day) |
| **異常偵測** | 行為分析 (Anomaly-based) | 建立「正常行為」基準線 (Baseline) | **可發現未知攻擊** | 誤判率高（正常大流量可能被視為攻擊） |
> 📌 **考試口訣**：特徵抓已知（誤判低）、異常抓未知（誤判高）。
### 6.5.3 IDS/IPS 比較與部署
| 比較 | IDS | IPS |
| :--- | :--- | :--- |
| **圖示** | 旁路（TAP/Mirror） | 串接（Inline） |
| **誤判後果** | 發出不必要的告警（影響較小） | **阻斷正常服務**（影響較大） |
| **適用場景** | 監控為主、合規稽核 | 即時阻擋、主動防禦 |
---
## 6.6 「APT」進階持續性威脅防禦
### 6.6.1 APT 攻擊特色
* **進階 (Advanced)**：使用自行開發或客製化的攻擊工具，非一般的現成惡意程式。
* **持續 (Persistent)**：長時間潛伏，低調地持續竊取資料或維持存取權限。
* **具針對性 (Targeted)**：針對特定組織或產業量身打造攻擊策略。
### 6.6.2 防禦策略
* **多層次防護**：結合防火牆、IPS、WAF、防毒軟體、EDR 等多道防線。
* **沙箱 (Sandbox)**：建立隔離的虛擬環境，讓可疑檔案在裡面實際執行，觀察其行為（是否改 Registry、是否連線 C2 Server），專門對付**未知惡意程式**。
* **威脅情報分享**：透過跨機關資安聯防機制、情資交換提升防禦策略。
* **備份管理**：確保遭攻擊後能快速復原。
* **持續改進**：資安防禦是持續改進的過程。
---
## 6.7 「SOC」資通安全威脅偵測管理機制
### 6.7.1 定義與核心目標
SOC (Security Operation Center) 提供資通設備紀錄與資訊服務或應用程式紀錄等資安監控、事件處理、資安威脅預警等服務。核心目標是**協助機關提升資安監控之有效性，即時掌握最新網路風險狀態及安全資訊**。
### 6.7.2 SOC 監控範圍（以 A 級公務機關為例）
EDR、防毒軟體、網路防火牆、電子郵件過濾機制、IDS/IPS、WAF、APT 防禦措施、目錄服務系統（如 Active Directory）、核心資通系統之資通設備紀錄及應用程式紀錄。
### 6.7.3 SOC 服務項目
1. **7×24 全天候監控服務**：任何時刻都能發現潛在事件。
2. **即時告警**：偵測到異常時即時發出告警。
3. **追蹤分析與應變處理**：對告警進行深入研判，啟動應變流程。
4. **定期提供網路威脅分析統計報表**：提供管理者宏觀的威脅趨勢洞察。
5. **監控與網路同步運作**：納管多樣資安設備，透過 **SIEM** 系統進行**關聯分析**。
6. **搭配全球預警、威脅情資服務**：獲取最新漏洞、攻擊手法、惡意 IP 黑名單等情報。
### 6.7.4 資通安全威脅偵測聯防機制（三層架構）
| 層級 | 角色 | 職責 |
| :--- | :--- | :--- |
| **N-SOC** | 國家資通安全監控中心 | 統籌協調、制定領域資安威脅規範、掌握各領域整體現況、研判全國性緊急事件 |
| **領域 SOC** | 產業或特定領域的資安監控中心 | 收整單位防護狀況、研判與通知緊急事件、掌握領域整體現況 |
| **CI 提供者 SOC** | 關鍵基礎設施提供者或個別企業 SOC | 建置資安防護機制、情資蒐集與分析、建構情資上報機制 |
> 📌 三層形成**雙向溝通**：下層上報情資，上層回傳分析結果與指導。
---
## 6.8 「GCB」政府組態基準
### 6.8.1 組態管理基本概念
* **組態 (Configuration)**：IT 系統的邏輯模型，包含服務、軟體、硬體、設定、文件及人員等**組態項目 (CI)**。
* **CMDB (組態管理資料庫)**：儲存所有組態項目及其關聯性的資料庫，提供 IT 環境的**單一真實來源**。
* **組態管理目標**：識別、控制、維護及檢查組態元件及其關聯性，確保穩定性、一致性、安全性及合規性。
* **變更管理**：記錄變更內容與過程、評估衝擊、成本及風險、取得授權核准、變更後更新 CMDB。
> 📌 **組態變更時應考量**：可用性影響、安全組態影響、存取控制影響 → 確保變更不會成為新的風險來源。
### 6.8.2 政府組態基準 (GCB)
* **全名**：Government Configuration Baseline
* **目的**：規範資通訊設備的**一致性安全設定**（如密碼長度、更新期限），降低被攻擊面 (Attack Surface)。
* **強制性**：GCB 的導入是 **A 級與 B 級公務機關**必須辦理的事項（僅公務機關，特定非公務機關免辦）。
* **部署範圍**：從終端設備（個人電腦）擴及伺服器及所有資通安全設備。
### 6.8.3 GCB 類別及項目
| 類別 | 涵蓋範圍 | 目的 |
| :--- | :--- | :--- |
| **網通設備** | 無線網路設備、Palo Alto / Fortinet / Cisco 防火牆等 | 確保網路基礎設施的安全配置 |
| **作業系統** | Windows, Linux 等 | 帳戶密碼策略、服務啟用、系統日誌配置 |
| **應用程式** | Exchange、IIS、SQL Server、Apache HTTP Server、Office 等 | 確保應用程式及配置符合安全規範 |
| **瀏覽器** | Chrome、Firefox、Edge | 安全性區域設定、彈出視窗阻擋、插件管理 |
### 6.8.4 例外管理
若因舊系統相容性導致無法套用某項 GCB 設定，必須填寫**例外排除申請單**，經權責主管核准後方可排除，並需**定期審查**。
---
## 6.9 「VANS」政府機關資安弱點通報機制
### 6.9.1 定義與目的
VANS (Vulnerability Analysis and Notification System) 旨在結合**資訊資產管理**與**弱點管理**，掌握整體風險情勢，降低重大弱點爆發時可能造成之損害。
* 掌握整體風險情勢
* 降低重大弱點爆發損害
* 建立資訊資產清冊（定期蒐集主機與電腦之資訊資產項目及版本）
* 將資產清冊與弱點資料庫比對，掌握已公開揭露之弱點
### 6.9.2 VANS 提供的服務
1. **持續維護資訊資產盤點資料**：確保資產清冊的即時性與準確性。
2. **系統化風險評估**：自動進行弱點比對作業，識別潛在安全漏洞。
3. **即時提醒與修補作業**：依據風險值門檻，即時發出提醒。
4. **微軟安全性更新檢測報告解析功能**：以自動化方式檢視安全性更新落實程度。
### 6.9.3 VANS 資訊資產涵蓋範圍（由上而下）
1. **應用軟體資產**（最上層）：Adobe 系列、MySQL、Office 等
2. **應用框架及程式語言**（中間層）：Java Struts2、PHP、.NET 等
3. **應用程式中介軟體**（支撐層）：IIS、Apache Tomcat 等
4. **作業系統**（最底層）：Windows Server 及其他 Windows 系列
---
## 6.10 「EDR」端點偵測及應變機制
### 6.10.1 定義與用途
EDR (Endpoint Detection and Response) 超越傳統防毒軟體，能識別更複雜的攻擊行為（無檔案攻擊、勒索軟體、零日漏洞利用、APT 攻擊），並提供更詳細的攻擊事件資訊，幫助資安人員快速判讀與應變。
### 6.10.2 技術類型
| 技術 | 說明 |
| :--- | :--- |
| **行為分析** | 持續監控端點上所有進程、檔案操作、網路連線、登錄檔變更，識別異常行為 |
| **規則比對** | 與已知「惡意行為規則集」比對（如特定 API 呼叫序列、惡意檔案雜湊值） |
| **黑白名單** | 黑名單阻止已知惡意檔案、進程及 IP；白名單允許已知合法程式運行 |
### 6.10.3 選購考量
1. **偵測威脅的精準度**：評估誤報率與漏判率。
2. **與防毒軟體整合**：應能與現有防毒或**次世代防毒 (NGAV)**（採用機器學習及行為分析的進階防毒）良好整合，形成互補防禦。
3. **攻擊事件資訊詳盡且易於判讀**：具備直觀的事件可視化界面，呈現攻擊鏈、受影響設備、時間軸等。
### 6.10.4 傳統防毒 vs EDR 比較
| 比較項目 | 傳統防毒 (AV) | EDR |
| :--- | :--- | :--- |
| **偵測原理** | 主要依賴**特徵碼比對** | **行為分析** + 規則比對 + 黑白名單 |
| **已知威脅** | ✅ 有效 | ✅ 有效 |
| **未知威脅 / Zero-day** | ❌ 防禦力較差 | ✅ 可偵測 |
| **無檔案攻擊 (Fileless)** | ❌ 難以偵測 | ✅ 可偵測 |
| **事件調查能力** | 有限 | ✅ 提供詳細的攻擊事件資訊與回應功能 |
---
## 💡 考試重點總結
| 記憶點 | 內容 |
| :--- | :--- |
| **防毒軟體不同廠牌** | 端點防毒與閘道防毒採不同廠牌 → 縱深防禦 |
| **WAF vs 傳統防火牆** | 互補非取代。防火牆管 L3/L4，WAF 管 L7 |
| **IDS vs IPS** | IDS 旁路告警不阻擋；IPS 串接阻擋但可能誤殺 |
| **Signature vs Anomaly** | Signature 抓已知（誤判低）、Anomaly 抓未知（誤判高） |
| **GCB** | 一致性安全設定。僅**公務機關** A/B 級須辦理。無法套用要走例外管理 |
| **SOC 聯防** | N-SOC → 領域 SOC → CI 提供者 SOC，三層雙向溝通 |
| **VANS** | 資產盤點 + 弱點比對 + 即時提醒 |
| **EDR vs 防毒** | 防毒靠特徵碼（抓已知）、EDR 靠行為分析（抓未知） |
| **郵件過濾 Fail Close/Open** | 匣道模式 = Fail Close（安全優先）；Bridge = Fail Open（連通優先） |
---
### 第 6 單元：資通安全技術面應辦事項-資通安全防護及偵測
#### 1. 防毒軟體在資通安全防護與偵測措施中扮演重要角色，其主要用途是防範下列哪一類的惡意程式入侵電腦軟體或系統？
- \(A\) 僅限於防範傳統型態的電腦病毒。
- \(B\) 蠕蟲、間諜軟體、後門程式及木馬程式。
- \(C\) 主要用於加密網路通訊，而非防範惡意程式。
- \(D\) 僅限於防範勒索軟體，不包含其他惡意程式。
> **答案：B**
---
#### 2. 關於防毒軟體的管理重點，以下哪項敘述是不正確？
- \(A\) 應定期自動更新病毒碼。
- \(B\) 病毒感染的事件與趨勢應定期分析。
- \(C\) 應避免未安裝防毒軟體的電腦上線。
- \(D\) 「個人電腦與伺服器防毒系統」與「防毒匣道系統」應採用相同廠牌以簡化管理。
> **答案：D**
> 📌 應採用**不同廠牌**以增加縱深防禦。
---
#### 3. 網路防火牆的主要功能是什麼？
- \(A\) 其唯一功能是監測內部網路的流量，不涉及外部連線。
- \(B\) 限制不必要的服務埠號開啟，僅允許必要的服務連線。
- \(C\) 網路防火牆的功能僅限於阻擋已知的惡意軟體入侵。
- \(D\) 主要用於加密網路通訊。
> **答案：B**
---
#### 4. 關於網路防火牆的管理重點，以下哪項是確保其安全有效運作的關鍵？
- \(A\) 防火牆存取規則的變更無需管理程序。
- \(B\) 防火牆存取紀錄無需即時匯出，定期備份即可。
- \(C\) 定期產出異常存取統計分析報表，進行異常處理。
- \(D\) 防火牆存取控管規則終身無需盤查。
> **答案：C**
---
#### 5. 電子郵件過濾機制的核心管理重點之一，是如何處理其規則的變更？
- \(A\) 規則變更由系統自動完成，無需人工介入。
- \(B\) 規則變更應建立管理程序，包含變更申請、核准及記錄。
- \(C\) 規則變更頻率越快越好，不需考量影響。
- \(D\) 規則變更僅由技術人員私下進行。
> **答案：B**
---
#### 6. 在選購電子郵件過濾機制時，除了其判斷垃圾郵件的精準度外，建議機關還應考量哪些其他重要因素，以確保機制能全面符合業務需求？
- \(A\) 僅需關注是否提供基礎的郵件收發功能。
- \(B\) 主要考量系統的硬體規格是否為最高級別。
- \(C\) 應評估對於中文信件或多國語言的支援能力。
- \(D\) 僅需確認系統的初始購買成本是否最低。
> **答案：C**
---
#### 7. 面對 APT（進階持續性威脅）攻擊，除了加強防禦，還應具備哪種能力，以應對攻擊後的影響？
- \(A\) 只需要部署單一高階資安設備即可全面應對。
- \(B\) 提升系統效能以加速攻擊。
- \(C\) 透過備份管理等機制進行快速復原。
- \(D\) 減少資安事件日誌紀錄。
> **答案：C**
---
#### 8. 為了有效防禦 APT 攻擊，透過哪種機制可提升安全防禦策略及戰略的部署？
- \(A\) 完全依賴內部資安團隊的分析，不參考外部資訊。
- \(B\) 透過跨機關的資安聯防機制、情資的交換機制。
- \(C\) 專注於修補已知漏洞，不需情資共享。
- \(D\) 減少對外部威脅情資的關注。
> **答案：B**
---
#### 9. 關於「政府組態基準 \(GCB\)」的目的和部署範圍，以下敘述何者不正確？
- \(A\) GCB 目的在於發展一致性安全組態設定。
- \(B\) GCB 可提升政府機關資通訊設備之資安防護。
- \(C\) GCB 部署範圍僅限於伺服器。
- \(D\) GCB 的導入是 A 級與 B 級公務機關必須辦理的事項。
> **答案：C**
> 📌 GCB 部署範圍從個人電腦擴及伺服器及所有資通安全設備，非僅限伺服器。
---
#### 10. 在組態變更管理中，當 IT 系統的組態變更時，下列哪一項層面是應特別考量的？
- \(A\) 進行組態變更時，考量重點僅在於系統功能是否正常運行。
- \(B\) 應考量可用性影響、安全組態影響及存取控制影響。
- \(C\) 組態變更評估時，唯一需考慮的因素是變更所產生的成本。
- \(D\) 變更後無需更新組態管理資料庫。
> **答案：B**
--
# 第七章：資通安全技術面應辦事項 (安全性檢測及資通安全健診)
> **學習目標**
> 1. 了解安全性檢測的法規規定，以及不同責任等級機關的檢測頻率。
> 2. 掌握弱點掃描的定義、目的、類型、流程與報告內容，並了解其執行考量。
> 3. 理解滲透測試的定義、目的、類型、流程與報告內容，以及其模擬攻擊的特性。
> 4. 認識應用程式安全的關鍵概念，包括 SSDLC、變更控制、輸入攻擊防護與檢測方法。
> 5. 了解資通安全健診的目的、頻率、健診項目與執行流程。
> 6. 學習網路區域規劃的原則與實踐，以及網路連線安全、VPN 與雲端運算安全。
> 7. 掌握實體安全的威脅類型與防護措施，包括進出控管、安全區域規劃、環境與消防安全。
---
## 7.1 安全性檢測概論
安全性檢測是資通安全防護體系中**主動發現與修補弱點**的關鍵步驟，如同定期的健康檢查。
* **法規依據**：《資通安全責任等級分級辦法》明確要求各級機關依其等級，定期辦理全部**核心資通系統**之安全性檢測，包括弱點掃描及滲透測試。
* **分類**：依據檢測深度與標的，可分為弱點掃描、滲透測試、源碼檢測等。
### 安全性檢測頻率規定 (表40)
| 機關級別 | 弱點掃描 | 滲透測試 |
| :---: | :---: | :---: |
| **A 級** | 每年 **2** 次 | 每年 1 次 |
| **B 級** | 每年 1 次 | 每 **2** 年 1 次 |
| **C 級** | 每 **2** 年 1 次 | 每 **2** 年 1 次 |
| **D 級** | 無要求 | 無要求 |
| **E 級** | 無要求 | 無要求 |
> 💡 **記憶口訣**：等級越高，檢測頻率越高。A 級最嚴格（掃描一年兩次、PT 一年一次），D/E 級無要求。
---
## 7.2 弱點掃描 (Vulnerability Scanning)
### 7.2.1 何謂弱點掃描
透過**自動化工具**與**非侵入式**檢查，對目標系統、網路及應用程式進行全面的安全評估，旨在識別其中**已知或潛在**的安全漏洞（如軟體版本過舊、不安全組態設定、預設密碼、開啟不必要的服務埠、已公開的軟體漏洞等）。
### 7.2.2 目的 (六大目的)
1. **評估資安防護能力**：了解掃描目標目前的資安保護狀況，提供「檢測報告」。
2. **發現潛在弱點**：主動找出可能被利用的安全漏洞（資安防線上的「破口」）。
3. **提供改善建議**：提供詳細的漏洞描述、風險評級及具體的修補或緩解建議。
4. **提升系統安全**：協助組織依據結果修補，逐步消除已知安全隱患。
5. **作為管理依據**：掃描結果可作為高階主管進行資安決策的參考基準，幫助評估資安投資成效、監控資安風險趨勢。
6. **確認弱點已排除**：透過後續**複掃**，驗證弱點是否已成功修補，避免「假修復」。
### 7.2.3 弱點掃描類型
**(1) 主機系統弱點掃描**
* **範圍**：針對主機（伺服器、工作站、電腦）的作業系統、網路服務、系統設定、帳號密碼管理等。
* **檢查項目**：至少應符合 **CVE** (Common Vulnerabilities and Exposures) 發布的弱點內容，包括：作業系統未修正的弱點、常用應用程式弱點、網路服務程式弱點、木馬及後門程式掃描、帳號密碼破解測試、不安全或錯誤設定、網路通訊埠掃描。
**(2) Web 網頁弱點掃描**
* **範圍**：針對網站應用程式的安全弱點。
* **檢查項目**：應符合 **OWASP TOP 10：2021**：
* A01 Broken Access Control（權限控制失效）
* A02 Cryptographic Failures（加密機制失效）
* A03 Injection（注入式攻擊）
* A04 Insecure Design（不安全設計）
* A05 Security Misconfiguration（安全組態錯誤）
* A06 Vulnerable and Outdated Components（脆弱及過時的組件）
* A07 Identification and Authentication Failures（身分識別及鑑別失效）
* A08 Software and Data Integrity Failures（軟體及資料完整性失效）
* A09 Security Logging and Monitoring Failures（安全日誌及監控失敗）
* A10 Server-Side Request Forgery（伺服器端請求偽造, SSRF）
### 7.2.4 弱點掃描流程 (PDCA)
1. **確認掃描需求 (Plan)**：定義掃描目標、類型、範圍，確認合規性要求及排程。需合法授權並知會相關單位。
2. **執行初掃 (Do)**：使用選定工具（如 Nessus, Qualys）對目標進行首次全面掃描。
3. **分析初掃報告 (Check)**：排除誤報，依風險等級、影響程度對弱點進行優先級排序。
4. **確認並修復弱點 (Act)**：針對高風險弱點進行驗證，分配修復任務給相關團隊，執行修補（安裝 Patch、修正組態、修正程式碼）。**這是最重要的環節**。
5. **執行複測 (Do)**：修復後再次掃描，驗證弱點是否已修復，並確認未引入新問題。
6. **生成複測報告 (Check)**：總結修復成效，評估風險降低狀況，提供後續建議。
### 7.2.5 弱點掃描報告內容
1. **執行結果摘要**：掃描背景、範圍、關鍵風險、整體安全態勢評估。
2. **專案執行計畫**：掃描期間、項目、範圍、人員、工具及方法。
3. **弱點統計分析**：依風險等級（高/中/低）及類別進行分類統計。
4. **詳細弱點清單**：每個弱點名稱、描述、受影響設備名稱、IP/URL、Port、風險等級、修補建議。
5. **掃描誤判清單**：被工具標示但經人工判斷為誤判的項目及理由。
6. **弱點排除清單**：因特定原因暫不修補的弱點及理由。
7. **複掃報告差異化分析**：與初掃結果比較（已修復、仍未修復及新發現）。
### 7.2.6 弱點掃描考慮因素
**(1) 內部掃描 VS 外部掃描**
* **外部掃描**：掃描位置在防火牆**外部**，模擬來自網際網路的攻擊。目標為對外開放的服務（Web Server、Mail Server、FTP Server、防火牆規則等）。如同檢查建築物的「大門」。
* **內部掃描**：掃描位置在防火牆**內部**（LAN 中），模擬內部人員或已突破周邊防線的攻擊。目標為內部所有資產（內部伺服器、Client 端電腦、Switch 等）。如同檢查「房間內部」。
* **DMZ**：位於防火牆內、但與內部 LAN 有所區隔的特殊區域。需同時考慮內部及外部掃描視角。
* 兩者具**高度互補性**，唯有同時執行，方能建構全面性的資安防護體系。
**(2) 有登錄權限 VS 無登錄權限**
* **無登錄權限掃描 (Unauthenticated)**：只能測試無需登入即可公開存取的服務及介面。局限：無法探測登入後功能，容易遺漏深層邏輯漏洞。模擬完全陌生的外部駭客。
* **有登錄權限掃描 (Authenticated)**：使用有效憑證登入，模擬合法用戶行為，能深入檢查系統內部配置及登入後功能（權限問題、注入攻擊、敏感資料存取等）。結果更全面、準確，誤報率較低。建議優先採用。
**(3) 侵入式 VS 非侵入式**
* **非侵入式**：不會對目標系統造成影響，主要透過分析響應判斷弱點（端口掃描、Banner Grabbing 等）。安全性高，適合生產環境。**弱點掃描主要採用非侵入式**。
* **侵入式**：可能對系統造成不穩定或破壞，模擬真實攻擊行為（注入惡意程式碼、提升權限等）。通常用於**滲透測試**，需謹慎授權。
**(4) 委外 VS 自行執行**
* **委外**：優勢為專業性高、工具先進、結果客觀；劣勢為成本較高、溝通成本、對內部系統理解有限。
* **自行執行**：優勢為對系統熟悉、反應快速、資料保密、內部能力累積；劣勢為可能有盲點、工具限制、人員流動風險。需購置弱點掃描軟體並持續更新。
---
## 7.3 滲透測試 (Penetration Test)
### 7.3.1 何謂滲透測試
一種深入的資安評估方法，透過**模擬有心人士之攻擊方式**，對系統或物聯網設備進行安全強度測試。由專業資安人員（**白帽駭客**）執行，嘗試利用系統或網路中的漏洞來取得存取權限。
* 不僅能發現已知弱點，更能揭露**複雜的邏輯漏洞**及**潛在的入侵路徑**。
* 通常具有**侵入性**，執行前需要仔細的授權與規劃。
### 7.3.2 目的 (五大目的)
1. **評估防護能力**：檢測受測目標在遭遇攻擊時之資安防護能力與執行成效。
2. **發現潛在弱點**：主動找出可能被利用的安全漏洞，包括複雜的邏輯漏洞。
3. **提供改善建議**：依據測試結果，提供修補弱點的方法與建議。
4. **確認弱點已排除**：透過複測，確認初測找出之資安漏洞已完成修正。
5. **精進整體防護**：透過報告及建議，檢討與精進受測目標之整體資安防護作為。
### 7.3.3 滲透測試之類型及類別 (表43)
| 測試類型 | 測試類別 |
| :--- | :--- |
| **作業系統** | 遠端服務、本機服務 |
| **網站服務** | 設定管理、使用者認證、連線管理、使用者授權、邏輯漏洞、輸入驗證、Web Service、Ajax |
| **應用程式** | 電子郵件服務套件、檔案傳檔服務套件、遠端連線服務套件、網路服務套件、其它 |
| **密碼破解** | 密碼強度測試 |
| **無線服務** | 無線服務弱點測試 |
### 7.3.4 滲透測試之流程
1. **事前準備與了解**：定義範圍、資產盤點、文件審查、情資蒐集。
2. **工具準備**：使用合法授權的商業滲透測試軟體，更新弱點資料庫至最新版本。
3. **風險管理**：與組織確認，具備適當應變措施與風險評估後才進行。事前需提出備份建議。
4. **執行測試（模擬攻擊）**：可針對網際網路及/或內部網路進行。通常於非公務時段執行。包含初次測試（探索、弱點發掘、漏洞利用）。
5. **協助修補與追蹤**：協助組織理解可利用弱點及其利用路徑，提供具體修補與防禦強化建議。
6. **執行複檢（驗證防禦成效）**：修補後再次複測，確認弱點已排除。
7. **產出報告**：提交包含攻擊路徑、利用證據、風險評估及具體修補建議的報告。
### 7.3.5 滲透測試報告內容
1. **執行結果摘要**：受測目標風險等級與數量列表、漏洞名稱列表及風險漏洞分布列表。
2. **專案執行計畫**：測試期間、執行項目、範圍、人員及使用工具。
3. **滲透測試弱點發現**：詳細測試結果、詳細過程及內容（檢測目標、弱點名稱、問題 URL/IP、問題參數、測試語法、測試截圖等），以及可能造成的風險。
4. **分析報告**：對測試結果進行統計分析。
5. **改善與建議**：弱點修補建議。
6. **結論**。
### 7.3.6 更深遠的意涵
* **自主資安檢測**：即使法規未強制要求（如 D/E 級），組織仍應自主規劃資安檢測。
* **持續改進循環**：定期檢測 → 修補改進 → 形成持續性的資安循環。
* **多重目的**：不僅為符合法規，更是為確保資通系統的韌性、CIA。
---
## 💡 掃描 vs 滲透測試 比較
| 項目 | **弱點掃描 (Scan)** | **滲透測試 (PT)** |
| :--- | :--- | :--- |
| **執行方式** | 自動化工具 | 人工 + 工具（白帽駭客） |
| **目的** | 全面盤點已知漏洞 | 驗證防禦深度，找邏輯漏洞與入侵路徑 |
| **深度與廣度** | 廣度高，深度淺 | 深度深，廣度依範圍而定 |
| **侵入性** | 主要為**非侵入式** | 通常具有**侵入性** |
| **產出** | 弱點清單 | 入侵路徑與利用證明 |
| **共同點** | 都需要**初測 + 複測**，確認弱點已修補 ||
---
## 7.4 應用程式安全
將資安融入軟體開發生命週期 (SSDLC)，從源頭降低風險。
### 7.4.1 傳統軟體開發 vs SSDLC
* **傳統軟體開發**：功能性導向，在最短時間完成開發與上線。缺乏安全性考量，面對日新月異的攻擊手法難以有效防護（如 SQL Injection 便因此崛起）。
* **SSDLC 思維**：在考量功能性的同時，導入安全性思維。雖開發時程長，但**降低了系統後續維運的成本及遭受入侵的損失**。
### 7.4.2 SSDLC 五個階段
1. **需求分析 (Requirements)**：進行風險分析並確認資安需求，以符合使用者需求與法規遵循。
2. **架構設計 (Design)**：設計系統目標、功能關聯、邊界範圍、各階層使用者角色等，搭配適當的資安架構。
3. **程式實作 (Implementation)**：落實規劃，完整實現使用者介面、功能運作及安全性，並培養程式設計師注意正確安全的程式撰寫習慣。
4. **測試與驗收 (Testing)**：依據資安需求擬訂測試計畫，進行測試與修正，確保功能與安全性符合需求。
5. **部署與維運 (Maintenance)**：進行軟體部署、安排教育訓練，**定期修補漏洞 (Patch)**、**按步升級更新版本 (Upgrade)** 及**即時監控 (Monitor)**。
### 7.4.3 安全控制 - 變更控制
變更控制確保在進行任何修改後，安全狀態仍能符合既定的安全政策要求。
**(1) 原因**：應用程式上線後，因業務需求變更、新功能導入、發現與修補瑕疵或漏洞等因素，需要不斷修改。這些變更若無妥善管理，極易引入新的安全漏洞。
**(2) 方法 — 確保變更的三個關鍵要素**：
* **授權**：所有變更都需經過正式審批，依風險層級決定批准權限。
* **測試**：變更後必須進行全面測試（功能測試、回歸測試、**安全測試**），確保未引入新的功能問題或安全漏洞。
* **記錄**：每次變更的所有相關資訊都必須詳細記錄，以便追溯問題源頭、支援稽核及資安事件應變。
**(3) 步驟**：
* 變更需求管理（申請 → 分析 → 實作策略 → 成本計算）
* 變更評估（評估與安全的關聯性、記錄請求）
* 變更審查（提交核准 → 開發 → 記錄產出）
* 變更測試與部署（程式碼連結變更申請 → 測試品質認可 → 上線）
* 變更結果報告（向管理階層報告）
### 7.4.4 安全控制 - 職責區隔
防止單一人員濫用權限或無意中造成安全漏洞，關鍵原則：
1. **作業人員**不應有權限存取線上的程式碼或程式物件。
2. **程式設計人員**不應存取線上運作中的軟體。
3. **品管部門**應測試程式碼品質，且與開發部門採用不同的測試方法。
4. 軟體開發測試完成後應被保存在**程式庫**中。
5. 線上運作的軟體應由程式庫中**發行 (Release)**，不應由程式設計人員或測試人員直接更新。
### 7.4.5 安全控制 - 程式庫維護
* **集中存放與存取控管**：應用程式集中存放在程式庫中並進行存取控管。
* **版本控制**：保留所有版本程式碼（主版本、次版本、緊急修正版本）。
* **開發與測試流程整合**：
* 開發部門凍結版本後 → **簽入 (Check In)** 到程式庫
* 測試部門 → 從程式庫 **簽出 (Check Out)** 最新版本進行測試
* 上線人員 → 從程式庫 **發行 (Release)** 最新版本至線上系統
### 7.4.6 行動應用程式安全
* **開發注意事項**：採用安全的第三方套件；避免索取過多敏感資訊（通訊錄、行事曆、座標位置、郵件、簡訊內容等）。
* **使用者注意事項**：不要在手機裡儲存重要資料；不要下載不明 APP。
### 7.4.7 安全威脅 - 輸入攻擊
Web 應用程式最常見的攻擊類型之一，如 **SQL Injection** 及 **XSS (Cross-Site Scripting)**。利用應用程式未能對使用者輸入進行充分檢查與過濾的弱點，可能導致程式錯誤、執行邏輯被改變、存取權限跳脫。
> ⚠️ **核心防護原則**：所有使用者輸入皆視為不可信，開發者必須在設計階段就納入輸入驗證與過濾機制。
### 7.4.8 Web 應用程式檢測 — 黑箱 vs 白箱
| 比較項目 | 黑箱：人工滲透 | 黑箱：AP掃描工具 | 白箱：人工源碼 | 白箱：自動源碼 |
| :--- | :---: | :---: | :---: | :---: |
| 弱點定位精準 | 普 | 差 | 佳 | **優** |
| 檢測詳細程度 | 差 | 普 | **優** | **優** |
| 執行時錯誤 | **優** | 佳 | 差 | 差 |
| 邏輯性錯誤 | 佳 | 普 | 差 | 差 |
| 存取控管機制 | 佳 | 普 | 差 | 差 |
| 檢測時效 | 差 | 佳 | 差 | **優** |
| 修補溝通 | 普 | 差 | 佳 | **優** |
| 誤判情形 | **優** | 普 | 佳 | 普 |
| **綜合評比** | **佳** | 普 | 普 | **優** |
* 若預算充足 → 同時採用**自動源碼掃描**與**人工滲透測試**。
* 若預算有限 → 優先採用**自動源碼掃描**。
* 無能力修改程式時 → 建置 **WAF (Web Application Firewall)** 作為外層防護。
---
## 7.5 資通安全健診
一種整合各資通安全項目的**綜合性檢視服務作業**，旨在提供機關資通安全改善建議。
### 7.5.1 健診目的
1. 整合各資安項目的檢視服務作業，透過系統性檢查全面了解組織在各資安面向的表現。
2. 提供機關資通安全**改善建議**，提升資安防護能力。
3. 實施技術面與管理面的相關控制措施，提升機關整體資通安全防護能力。
4. 針對已知弱點進行修補，並**持續追蹤**可能存在的風險。
### 7.5.2 健診辦理項目及頻率 (表45)
| 辦理項目 | A 級 | B 級 / C 級 | D 級 / E 級 |
| :--- | :---: | :---: | :---: |
| 網路架構檢視 | 每年辦理 1 次 | 每 **2** 年辦理 1 次 | 無要求 |
| 網路惡意活動檢視 | 每年辦理 1 次 | 每 **2** 年辦理 1 次 | 無要求 |
| 使用者端電腦惡意活動檢視 | 每年辦理 1 次 | 每 **2** 年辦理 1 次 | 無要求 |
| 伺服器主機惡意活動檢視 | 每年辦理 1 次 | 每 **2** 年辦理 1 次 | 無要求 |
| 目錄伺服器設定及防火牆連線設定檢視 | 每年辦理 1 次 | 每 **2** 年辦理 1 次 | 無要求 |
### 7.5.3 健診項目詳細內容
**(1) 網路架構檢視**：針對網路架構圖進行安全性弱點檢視，詳列風險等級、風險說明與改善建議。
**(2) 網路惡意活動檢視**：
* 架設**封包側錄設備**，觀察內部電腦或設備是否有對外之異常連線。
* 檢視**資安設備紀錄檔**，分析過濾內部電腦或設備是否有對外之異常連線紀錄。
**(3) 使用者端電腦惡意活動檢視**：
* 檢視作業系統**更新情形**。
* 檢視應用程式之**安全性更新**情形。
* 檢視是否使用**已停止支援**之作業系統或軟體。
* 檢視防毒軟體**安裝、更新及定期掃描**結果之處理情形。
**(4) 伺服器主機惡意活動檢視**：
* 檢視作業系統更新情形、應用程式安全性更新情形。
* 檢視是否使用已停止支援之作業系統或軟體。
* 檢視是否使用**不合宜之作業系統**。
* 檢視防毒軟體安裝、更新及定期掃描結果之處理情形。
**(5) 目錄伺服器設定及防火牆連線設定檢視**：
* **AD 伺服器組態設定**：以國家資通安全研究院之「**政府組態基準 (GCB)**」為標準，確認組態設定落實情形。
* **防火牆連線設定規則**：檢視是否有安全性弱點，確認來源與目的 IP 及通訊埠連通之適切性。
### 7.5.4 健診流程 (9 大步驟)
1. **基本環境調查**：收集使用者電腦與伺服器資訊、GCB 部署現況、Switch 是否支援 Port Mirror 等。
2. **決定範圍與抽樣方式**：須具有代表性，據以決定檢測時程與預算。
3. **檢測配合事項**：受測單位提供檢測環境相關資料。
4. **啟始會議**：說明檢測項目與範圍，協調配合事項，參與人員含機關主管與業務承辦人。
5. **執行檢測**：依啟始會議決議項目執行各項檢視。
6. **撰寫檢測報告**：執行結果摘要、執行計畫、執行情形、結果建議、結論及附件。
7. **提出改善建議**：針對各檢測項目發現事項，詳查根因並提出相對應之改善建議。
8. **結束會議**：說明各項目發現事項、改善建議與結論。參與人員含機關**管領階層**。
9. **修補規劃與追蹤**：
* 優先處理可即時修補與風險等級較高的弱點。
* 無法即時修補者，規劃改善計畫與時程，持續追蹤。
* 已修補弱點須留存修補紀錄。
* 修補完成後須**執行複測**。
---
## 7.6 網路安全
保護網路基礎設施與其上傳輸的資料，確保網路通訊的 CIA。
### 7.6.1 網路區域規劃
清楚界定不同屬性的網路區域，作為實施存取控制與制定安全策略的基礎，避免內外攻擊並防範災害擴大。建議的六大區域：
**(1) 外部網路**：機關對外網路區域，連接外部廣域網路 (WAN)。對內部需經防火牆存取控制。非允許的服務與來源不能進入其他區域。
**(2) 內部網路 (LAN)**：包含使用者終端、資通系統等設備。利用 **VLAN** 與不同路由等方式切開子網。外部網路**無法直接連線**內部網路。可考慮架設**代理伺服器 (Proxy Server)** 控管對外連線。
**(3) 非軍事區 (DMZ)**：放置對外服務伺服器（網頁伺服器、FTP 伺服器、郵件伺服器、DNS 伺服器等）。僅開放**特定服務**所需的通訊埠（如 TCP 80/443）。需**嚴密控管**此區域到內部區域的存取（通常有第二道防火牆或更嚴格的規則）。即使 DMZ 被入侵，攻擊者也難以跳轉到內部網路。
**(4) 網路管理區域**：放置網路管理設備（NMS、RADIUS/TACACS+ 鑑別系統、監控系統等）。應明確標示網路路徑及維運方式。網路設備維運應與服務的網段**有所區隔**（Out-of-Band Management）。
**(5) 網路記錄區域**：放置備份主機 (Backup Server) 及記錄主機 (Log Server)。所在網段應與其他網段**嚴格隔離**。僅允許設備備份及記錄發送及管理員管理連線行為。
**(6) 實體隔離區域**：與其他網路間**完全沒有實質的網路連線**。專用於處理高度機密資訊、國家安全事務等。**單向傳輸**：僅可將資料傳出，不可傳入（如透過**光閘 data diode**）。可能危害途徑：破解門禁系統、利用隨身碟竊取資料（**空隙攻擊 air-gap attack**）、私接網路。
### 7.6.2 網路連線安全
**(1) 傳輸加密**：
* 應優先採用通道加密（如 VPN）與傳輸層加密（如 **HTTPS、SSL/TLS 1.2/1.3**）。
* **應停用的協定**：SSLv3（POODLE 漏洞）、TLS 1.0 / TLS 1.1。
**(2) 加密演算法**：
* **對稱式**：AES-GCM、ChaCha20-Poly1305 (AEAD)。
* **非對稱式**：RSA (至少 2048-bit)、P-256 (ECC)。
* **應停用的演算法**：RC4（偏向性漏洞）、3DES（SWEET32 攻擊風險）。
**(3) 資訊完整性**：主要透過**數位簽章**技術驗證資料是否被竄改，並提供不可否認性。
**(4) 不安全的連線協定（明文傳輸）**：**HTTP**、**FTP**、**TELNET** → 通訊內容未加密，極易被監聽、截取。
**(5) 安全的連線協定（加密傳輸）**：**HTTPS**、**FTPS**、**SSH** → 在不安全的網路環境中提供安全傳輸。HTTPS 連線時需檢查伺服器憑證有效性。
### 7.6.3 虛擬私有網路 (VPN)
在公開網路上建立虛擬的私有通道，保護通訊資料的機密性與完整性。
**(1) VPN 類型**：
* **遠端使用者存取 VPN**：外勤人員或遠端工作者透過網際網路安全連線公司內部網路。如同建立一條專屬加密的秘密通道。
* **Site-to-Site VPN**：連接兩個或多個地理位置分散的實體網路（如總部與分公司），透過加密隧道使內部網路安全通訊。
* **Extranet VPN**：連接組織內部網路與外部合作夥伴（供應商、客戶、協力廠商）的網路。**注意存取權限的控管**特別重要。應具支援 **MFA (多因子鑑別)** 功能。
**(2) VPN 管理重點**：
* VPN 建立與帳號申請，應建立管理程序（變更申請、核准及記錄）。
* 定期分析異常事件（如 VPN 使用者簽入失敗）。
* VPN 存取紀錄應即時匯出存檔，保留足夠時間。
**(3) VPN 選購考量**：
* 支援的 VPN 數量及使用者連線數量應滿足需求。
* 本身應**具備防火牆功能**以控管 VPN 連線的存取。
* 與其他不同廠牌產品建立 VPN 連線的**相容性**。
### 7.6.4 雲端運算
**(1) 六個核心特性**：
* **隨選自助 (On-demand Self-service)**：依需求自行配置及部署運算資源，無需人工介入。
* **廣泛網路存取 (Broad Network Access)**：可透過標準網路機制（如網際網路）廣泛被存取，不受設備或地點限制。
* **資源匯聚 (Resource Pooling)**：大量運算資源匯聚為共享池，動態分配給多個客戶。
* **快速靈活性 (Rapid Elasticity)**：資源可被快速且彈性地擴展或縮減。
* **受量測服務 (Measured Service)**：對資源使用情況進行監控、測量及報告，**按實際消耗量計費**。
* **多租用 (Multi-tenancy)**：多個客戶共享同一套基礎設施及應用程式，但資料及配置邏輯隔離、互不影響。
**(2) 三種服務模式 (表46)**：
| 雲端服務模型 | 使用者管理層面 | 雲端供應商管理層面 |
| :--- | :--- | :--- |
| **IaaS** (基礎設施即服務) | 作業系統、中介軟體、應用程式 | 硬體（伺服器、儲存、網路） |
| **PaaS** (平台即服務) | 應用程式、資料 | 硬體、作業系統、中介軟體 |
| **SaaS** (軟體即服務) | 應用程式內的使用者設定及資料 | 硬體、作業系統、中介軟體、應用程式 |
> 💡 **記憶**：從 IaaS → PaaS → SaaS，使用者管理的越來越少，供應商管理的越來越多。SaaS 使用者基本上只需使用應用程式。
### 7.6.5 CMMC 2.0 (美國國防部網路安全成熟度模型)
確保與美國國防部合作的供應商具備足夠的網路安全能力，保護敏感的非機密資訊（尤其是 **CUI** 受控非機密資訊）。
| 等級 | 名稱 | 保護對象 | 要求數量 | 對應標準 | 評鑑方式 |
| :---: | :--- | :--- | :---: | :--- | :--- |
| **Level 1** | Foundational (基礎級) | FCI 聯邦契約資訊 | 15 項 | FAR 48 CFR 52.204-21 | 每年自我評鑑 + 年度確認 |
| **Level 2** | Advanced (進階級) | CUI 受控非機密資訊 | 110 項 | NIST SP 800-171 Rev 2 | 每 3 年第三方評鑑 + 年度確認 |
| **Level 3** | Expert (專家級) | CUI | 134 項 | NIST SP 800-171 + 800-172 | 每 3 年政府主導評鑑 + 年度確認 |
### 7.6.6 雲端安全管理 ISO/IEC 27017:2015
以 ISO/IEC 27002 為基礎，針對雲端服務的資訊安全需求增補的**七項專屬控制措施**：
1. **雲端環境下的角色共享與權責**：明確界定提供者與客戶在不同服務模式下的安全責任（責任共擔模型）。
2. **雲端服務客戶資產的移除**：終止服務時確保資料被安全、徹底刪除，防止資料殘留或洩露。
3. **虛擬運算環境的區隔**：確保不同虛擬環境間嚴格隔離，防止租戶間隔離失效。
4. **虛擬機器強化**：對虛擬機進行安全配置及加固（禁用不必要服務、修補漏洞、最小權限原則）。
5. **管理者的操作安全**：確保管理人員操作過程安全（強身分驗證、嚴格存取控制、操作日誌審核）。
6. **監控雲端服務**：對雲端環境活動進行持續監控（資源使用、網路流量、安全事件日誌、組態變更）。
7. **虛擬和實體網路安全管理的一致性**：確保虛擬網路與實體網路的安全策略保持一致。
### 7.6.7 雲端運算 — 資安問題
**(1) 客戶端面臨的挑戰**：資料竊取、資料可用性、網路封包竊聽、資料內容加密保護、共用環境的系統安全防護、退租後資料完整刪除。
**(2) 雲端服務提供者的挑戰**：虛擬化環境的系統與網路安全、分散式阻斷服務攻擊 (DDoS)、即時阻絕資安威脅。
### 7.6.8 雲端運算 — 服務協定
* **契約 (Contract)**：總體法律約束，涵蓋服務範圍、費用、終止條款、責任、罰則。
* **服務水準協議 (SLA)**：更具體量化的服務品質指標（可用性如 99.9%、延遲、RTO、RPO 等），客觀衡量業者是否滿足客戶要求。未達 SLA 標準通常觸發契約罰則。
---
## 7.7 實體安全 (Physical Security)
保護資訊資產所處的實體環境免受各種威脅，確保 CIA。
### 7.7.1 威脅類型 (四大類)
1. **天然環境災害**：水災、颱風、地震、土石流、山崩、極端溫度。
2. **供應系統中斷**：電力、通訊、瓦斯、水。
3. **人為的破壞**：火災（短路或縱火）、非授權入侵、破壞、偷竊、爆裂物、員工疏失。
4. **政治事件**：抗議團體與恐怖組織。
### 7.7.2 防護措施規劃 — 縱深防禦策略
多層次「縱深防禦」策略的五個階段：
1. **嚇阻**：圍牆、警衛、警告標語及狗、警報器、加強巡守頻率、全時攝影系統 (CCTV)、**公布違反實體控管要求人員姓名**、簽署認同規範及訂定罰則。
2. **延遲**：門鎖、隔間、人員及標示牌、**階層式防護設計**（從門口到重要資產需經過層層關卡）。
3. **偵測**：門窗開啟偵測、紅外線進出感應、動作感應器、煙霧偵測器、溫濕度偵測。
4. **評估**：警衛應具備緊急處理標準程序，對事件性質、範圍及潛在影響進行判斷。
5. **處理**：明確處理人員或組織，制定緊急處理程序，與警察、消防及醫療人員聯絡與通報。
> ⚠️ **縱深防禦的脆弱環節**：攻擊可能在「嚇阻」、「偵測」、「處理」及「逮捕」任一環節失敗或執行太慢，最終導致攻擊成功。每個環節都必須有效運作並相互配合。
### 7.7.3 進出控管
**(1) 需要控管的進出口**：主要與次要進出口、緊急疏散出口、車輛與貨物進出口、屋頂、維護孔及窗。
**(2) 進出識別方式**：識別證（有相片，警衛檢查）、生物特徵辨識（指紋、虹膜及臉部辨識）、卡片識別、多重鑑別（門禁卡 + PIN 碼）。
**(3) 尾隨進出 (Tailgating) 防範**：非授權人員跟隨授權人員一起進入管制區域。防範措施：警衛與人員訓練認知、旋轉門、驗票閘門、**Mantrap (人行閘)** 結合警衛或內外門鑑別機制。
### 7.7.4 安全區域規劃
依安全等級劃分為四種區域：
* **公開區**：訪客可自由活動的區域（如大廳、接待區）。
* **作業區**：需特定身分驗證才能進入（如部門辦公室）。
* **限制區**：需額外授權或陪同（如伺服器機房前廳）。
* **機敏區**：存放最敏感資料或關鍵設備的核心區域，需最高等級存取控制及監控（如主機房內部）。
**需要加強保護的區域**：電腦資訊設備機房、儲存媒體存放室、電力與空調設備機房、電話與資料線路配接室、監控與錄影機房、管道間。
**安全偵測與滅火器位置規劃**：
* 煙霧偵測器 → 置於天花板**下風處**。
* 滅火器 → 置於**容易取得**的位置。
* 門窗開啟感應器 → 分佈在進出口及機敏區窗戶附近。
* 安全區域等級較高的隔間 → 應採用足夠強度的牆面，牆面由樓地板連接到天花板，通風口應加裝鐵網。
### 7.7.5 監視錄影
**(1) 系統類型**（由基礎到進階）：單純錄影 → 動作偵測 → 行為分辨 → 身分識別（臉部辨識）。
**(2) 選擇考量**：CCTV 目的（偵測、行為及識別）、放置環境（室內或室外）、需監控的區域數量、照明條件（是否需紅外線）、儲存空間與保存期限需求、與其他安全系統的整合需求。
### 7.7.6 空調規劃
* **功能**：溫度調節（機房與人員作業區分開）、濕度調節（理想相對濕度 **40%~60%**，過高→生鏽，過低→靜電）、換氣功能。
* **規劃要點**：安全區域應維持**正風壓**（開門時風往外吹，防止外部有害物質進入）、保護進氣口（避免惡意污染）、自動偵煙與自動關閉機制、緊急手動開關、獨立電力供應線路、文件描述維護程序。
### 7.7.7 電力來源
* **主要電力來源**：日常電力（市電網），必要時由變電所提供專屬電力供應。
* **次要電力來源**：主要電力中斷時使用（如**發電機**），必要時由額外的變電所提供電力。
### 7.7.8 電力備援 — UPS 不斷電系統
| 項目 | **在線式 (Online) UPS** | **非在線式 (Offline) UPS** |
| :--- | :--- | :--- |
| **平時供電** | 電力始終通過 UPS 系統 | 市電直接 bypass 供應設備 |
| **切換時間** | **零轉換時間** | 有短暫延遲（幾~十幾毫秒） |
| **電力品質** | 最穩定（雙重轉換：AC→DC→AC） | 一般 |
| **適用場景** | 伺服器、網路設備、精密儀器等**對電力品質要求極高**的場所 | 一般家用或辦公設備 |
### 7.7.9 電力干擾
* **電力不穩定將導致**：設備故障（突然高電壓）、設備運作不正常（突然低電壓）、系統效能降低（持續低電壓）、瞬間資料遺失。
* **電力供應狀態應被偵測與記錄**，以掌握供電品質並作為改善依據。
* **干擾來源**：閃電、高壓電塔、電纜線、電器用品。
### 7.7.10 靜電防範
1. 機房使用**抗靜電高架地板**。
2. 使用**抗靜電桌面**。
3. 建築物、機房、電力設備及電腦設備要**正常接地**。
4. 空調維持在合適的濕度（**40%~60%**）。
5. 機房中**不使用地毯**，若必要請使用抗靜電地毯。
6. 組裝或拆解電腦硬體時戴上**抗靜電手環**。
### 7.7.11 滅火方式
**(1) 火由四種因素組成**：可燃物、溫度超出燃點、氧氣、化學反應。
**(2) 四種滅火方式**：降低溫度（冷卻法）、去除可燃物（隔離法）、去除氧氣（窒息法）、瓦解燃燒的化學反應（中斷法）。
**(3) 不同類型可燃物之滅火方式 (表47)**：
| 火災分類 | 別名 | 可燃物 | 滅火方式 |
| :---: | :--- | :--- | :--- |
| **A** | 普通火災 | 木材、紙張、衣服及塑膠 | 水、ABC 類乾粉、泡沫 |
| **B** | 油類火災 | 石油、焦油、油、溶劑、酒精及液態瓦斯 | BC/ABC 類乾粉、泡沫、CO₂、FM-200 |
| **C** | 電氣火災 | 電器設備、電路及電纜 | BC/ABC 類乾粉、CO₂、FM-200 |
| **D** | 金屬火災 | 鎂、鈉及鉀 | 乾粉（特殊滅火藥劑） |
> ⚠️ **資訊機房重點**：屬於 **C 類電氣火災**，應使用 **CO₂ 或 FM-200 等氣體滅火系統**（無殘留物，不損害電子設備）。❌ 禁用水（短路）、乾粉（殘留粉末導電損壞電路板）。CO₂ 適用於無人機房（注意人員窒息風險）。
### 7.7.12 漏水偵測
* 消防灑水系統可能會有漏水問題，**機房無法灑水**，需裝設特殊滅火裝置（如氣體滅火系統）。
* 水的偵測可避免損害設備、鋪設地板、牆、電腦、建築物基礎。
* **偵測位置**：高架地板下、天花板。
---
### 第 7 單元：資通安全技術面應辦事項-安全性檢測及資通安全健診
#### 1. 依據資通安全責任等級規定，A 級機關的滲透測試與弱點掃描頻率為何？
- \(A\) 每年 1 次滲透測試，每年 1 次弱點掃描。
- \(B\) 每 2 年 1 次滲透測試，每年 1 次弱點掃描。
- \(C\) 每年 1 次滲透測試，每年 2 次弱點掃描。
- \(D\) 每 2 年 1 次滲透測試，每 2 年 1 次弱點掃描。
> **答案：C**
---
#### 2. 關於弱點掃描與滲透測試的主要差異，以下敘述何者正確？
- \(A\) 弱點掃描是一種模擬攻擊，滲透測試是自動化檢測。
- \(B\) 弱點掃描用於快速識別已知漏洞，滲透測試用於驗證防護措施有效性並找出可利用弱點。
- \(C\) 弱點掃描主要針對內部網路，滲透測試主要針對外部網路。
- \(D\) 弱點掃描不需要修補，滲透測試才需要。
> **答案：B**
---
#### 3. 在應用程式安全中，安全系統開發生命週期（SSDLC）的「部署與維運」階段應落實哪些重要工作？
- \(A\) 擬訂資安需求與測試計畫。
- \(B\) 執行風險分析與評估。
- \(C\) 定期修補漏洞、升級更新版本及即時監控。
- \(D\) 進行源碼掃描安全檢測。
> **答案：C**
---
#### 4. 為了確保變更不會成為新的風險來源，應用程式安全中的「變更控制」機制強調所有變更都需符合哪三個關鍵要素？
- \(A\) 簡單、快速、有效。
- \(B\) 授權、測試、記錄。
- \(C\) 自動、手動、半自動。
- \(D\) 規劃、執行、評估。
> **答案：B**
---
#### 5. 資通安全健診的目的為何？
- \(A\) 資通安全健診的主要目的是處理已知的資安事件，不包括預防措施。
- \(B\) 資通安全健診服務僅限於提供資通系統的漏洞掃描，不提供其他建議。
- \(C\) 整合各資通安全項目的檢視服務作業，提供機關資通安全改善建議，並提升整體防護能力。
- \(D\) 其目的只在於評估內部人員的資安意識，不涉及系統層面的檢視。
> **答案：C**
---
#### 6. 在資通安全健診的「使用者端電腦惡意活動檢視」項目中，應檢視哪些內容？
- \(A\) 檢視內容局限於網路架構圖的安全性，不包含實際系統配置。
- \(B\) 檢視惡意活動時，主要檢查伺服器主機的作業系統更新，不包括使用者端。
- \(C\) 檢視作業系統及應用程式的安全性更新、是否使用停止支援的軟體、及防毒軟體狀態。
- \(D\) 只需要架設封包側錄設備來觀察對外異常連線，其他方法不需使用。
> **答案：C**
---
#### 7. 關於網路連線安全，為何應避免使用 HTTP、FTP 和 TELNET 等協議進行敏感資料傳輸？
- \(A\) 這些協議採用明文傳輸，通訊內容有可能被監聽，容易造成資訊洩露風險。
- \(B\) 這些協議不支援大檔案傳輸。
- \(C\) 這些協議傳輸速度較慢。
- \(D\) 這些協議容易受到分散式阻斷服務（DDoS）攻擊。
> **答案：A**
---
#### 8. 雲端運算具備多項核心特性，以下何者敘述是關於「受量測服務 \(Measured Service\)」的特性？
- \(A\) 雲端資源可以被快速且彈性地擴展或縮減。
- \(B\) 多個客戶共享同一套基礎設施和應用程式。
- \(C\) 供應商會對資源的使用情況進行監控、測量和報告，通常按照實際消耗量計費。
- \(D\) 雲端服務可以透過標準的網路機制廣泛被存取。
> **答案：C**
---
#### 9. 在雲端安全管理中，ISO/IEC 27017:2015 標準強調了哪些關鍵考量，尤其是關於供應商與客戶的責任界線？
- \(A\) 雲端安全管理只關注虛擬機器的強化，不涉及其他層面。
- \(B\) 雲端環境下的角色共享與權責，以及雲端服務客戶資產的移除。
- \(C\) 需確保虛擬和實體網路安全管理的一致性。
- \(D\) 雲端安全管理只針對管理者的操作安全進行考量，不包括客戶端的責任。
> **答案：B**
---
#### 10. 實體安全的三個核心防禦策略為嚇阻、延遲、偵測與處理。以下何者是屬於「嚇阻」的措施？
- \(A\) 感應式讀卡機。
- \(B\) 設置多層門禁。
- \(C\) 公布違反實體控管要求人員姓名。
- \(D\) 紅外線進出感應。
> **答案：C**
---
# 第八章：資通系統委外安全管理
> **學習目標**
> 1. 了解資訊委外之定義與相關法規要求。
> 2. 認識委外類別及形態，辨識不同委外模式的特點。
> 3. 理解委外潛在的資安風險，特別是遠端維運的安全挑戰。
> 4. 掌握委外生命週期（需求→方案→建置→營運）之資安管控架構。
> 5. 熟悉委外各階段（計畫、招標、決標、履約管理、驗收、保固）之資安要求。
---
## 8.1 資訊委外之相關法規
資訊委外（Outsourcing）雖能提升效率、降低成本或取得專業能力，但**資安責任無法完全移轉**，機關仍需負最終監督之責。我國已建立完整的法規體系來規範委外行為。
### 8.1.1 《資通安全管理法》第 9 條
> 公務機關或特定非公務機關，委外辦理資通系統之建置、維運或資通服務之提供，應考量受託者之**專業能力與經驗**、委外項目之**性質**及**資通安全需求**，選任適當之受託者，並**監督**其資通安全維護情形。
此條文確立四大核心原則：
| 原則 | 說明 |
| :--- | :--- |
| **適用對象** | 公務機關及特定非公務機關 |
| **委外範圍** | 資通系統之建置、維運及資通服務之提供 |
| **選任考量** | 綜合評估廠商的專業能力與經驗、委外項目性質及資安需求（涉及機敏資料者，資安要求遠高於一般服務） |
| **監督責任** | 選定受託者後，必須**持續監督**其資安維護情形，確保符合契約與法規要求 |
> 📌 **注意**：教材使用《資安法》第 9 條，練習題亦以第 9 條出題。114 年修法後條號可能有所調整，考試時請以該梯次教材版本為準。
### 8.1.2 《資通安全管理法施行細則》第 4 條第 1 項
進一步具體化第 9 條的規定，詳列委託機關在選任及監督受託者時應注意的 **10 款事項**：
| 款次 | 要求重點 | 白話說明 |
| :---: | :--- | :--- |
| **(1)** | 資安管理能力 | 受託者應具備完善資安管理措施或通過**第三方驗證** |
| **(2)** | 專業人員配置 | 受託者應配置充足、具資安**專業證照**或類似業務經驗之專業人員 |
| **(3)** | 複委託規範 | 明訂得否複委託、範圍與對象，以及複委託之受託者應具備之資安措施 |
| **(4)** | 國家機密業務 | 涉及國家機密者，人員應接受**適任性查核**，並依《國家機密保護法》管制出境 |
| **(5)** | 安全性檢測 | 客製化系統開發者須提供**安全性檢測證明**；屬核心系統或金額達 **1,000 萬元以上**者，應自行或委託第三方檢測；使用非自行開發之元件，應標示來源及授權證明 |
| **(6)** | 事件通報與補救 | 受託者違反資安法令或知悉資安事件時，應**立即通知**委託機關並採行補救措施 |
| **(7)** | 終止後資料處理 | 契約終止時，應確認受託者**返還、移交、刪除或銷毀**所持有之資料 |
| **(8)** | 其他維護措施 | 受託者應採取之其他資安相關維護措施 |
| **(9)** | 定期稽核 | 委託機關應**定期**或於知悉資安事件時，以稽核或適當方式確認執行情形 |
| **(10)** | 供應鏈安全 | **限制使用有資安疑慮之大陸廠牌設備**，確保供應鏈安全 |
**第二方稽核之實務操作：**
委託機關對委外廠商的監督（第二方稽核）應注意：
* **稽核優先排序**：依委外金額大小、是否涉及核心系統、業務敏感性（個資、國家機密、關鍵基礎設施）排定優先順序。
* **稽核方式彈性**：可採書面稽核（審查文件報告）、現場稽核（實地訪查）、或其他適當方式（如資安演練、監控平台確認）。
* **紀錄保存**：應留存監督（稽核）結果紀錄、廠商改善報告及後續追蹤紀錄，作為履行監督責任之證明。
### 8.1.3 《資通安全管理法施行細則》第 6 條第 1 項
依第 6 條第 1 項第 11 款規定，**資通安全維護計畫應包含「資通系統或服務委外辦理之管理措施」**。機關每年訂定的資安維護計畫中，應納入委外管理措施，並與第 4 條第 1 項之應注意事項結合，確保委外活動融入整體資安策略。
### 8.1.4 《資通安全責任等級分級辦法》第 11 條第 2 項
各機關自行或**委外開發之資通系統**，應依附表九完成資通系統分級，並依附表十之防護基準執行控制措施。此規定旨在將資安要求融入資通系統的整個生命週期，從源頭確保委外服務的安全性。
### 8.1.5 政府資訊作業委外資安參考指引
政府提供 **17 項**參考文件，涵蓋招標範本、契約範本、RFP 資安需求範例、稽核表及作業指引等，協助各機關妥善辦理委外作業。重點包括：
* **RFP 資安需求範例**：涵蓋 Web 網站建置、基礎設施維護、雲端服務、ISMS 顧問輔導、ISMS 第三方驗證等類型。
* **契約範本**：行政院公共工程委員會提供之資訊服務採購契約範本、雲端服務採購契約範本。
* **稽核與查核**：資訊委外資安稽核表、委外廠商查核項目表。
* **通用要求**：各類資訊（服務）採購之共通性資通安全基本要求參考一覽表。
---
## 8.2 資訊委外之類別及形態
資訊委外是指將機關之資通服務所有相關活動，**部分或全部**委託由機關外之資通服務提供者完成。即使是部分委外，機關仍需對整體資安負責——**委外改變的僅是風險管理的模式，而非責任的轉移**。
資訊委外主要分為 **4 大類別、22 種形態**：
### 8.2.1 系統發展類（3 種形態）
聚焦於開發、維護或整合資訊系統。
* **系統開發**：從零開始設計與建構新系統。
* **系統維護**：對現有系統進行功能更新、Bug 修復、效能優化。
* **系統整合**：將多個異質系統連接起來，實現資料共享及業務流程協同。
### 8.2.2 維運管理類（10 種形態）
確保資訊系統及基礎設施的穩定運行與日常管理，是**最常見也最廣泛**的委外類別。
包含：設備操作、硬體維護、機房設施管理、備份與復原服務、網路與資安服務（防火牆、IDS/IPS 及 SOC）、網路管理、資料處理、資料登錄、整體委外、人力支援。
### 8.2.3 顧問訓練類（6 種形態）
提供專業知識、建議及培訓，提升組織能力。
包含：顧問輔導（如 ISMS 導入）、稽核審查、系統稽核、軟體驗證、教育訓練、整體規劃。
### 8.2.4 雲端服務類（3 種形態）
利用雲端技術提供彈性、可擴展的服務。
| 服務模式 | 說明 | 範例 |
| :--- | :--- | :--- |
| **SaaS** | 直接使用雲端應用軟體 | 雲端郵件、辦公軟體 |
| **PaaS** | 租用雲端開發與部署平台 | 用於開發應用程式 |
| **IaaS** | 租用雲端運算資源 | 虛擬主機、儲存、網路 |
---
## 8.3 資訊委外之風險
### 8.3.1 遠端維運之常見資安風險
近年來多起資安事件顯示，駭客常利用委外廠商遠端維運的弱點作為攻擊途徑：
| 風險類型 | 說明 |
| :--- | :--- |
| **帳密被竊取** | 廠商的 VPN 或遠端連線帳密一旦被盜用，將為攻擊者開啟入侵通道 |
| **惡意程式植入** | 廠商維運主機本身缺乏足夠資安防護，可能被植入惡意程式，成為攻擊機關系統的**跳板** |
| **弱密碼或未限制來源 IP** | 遠端桌面服務（如 RDP）使用弱密碼或未限制來源 IP，極易成為駭客暴力破解目標 |
### 8.3.2 遠端維運應採「原則禁止、例外允許」
若因地理限制、處理時效及專案特性等因素確需開放，應至少辦理下列防護措施：
1. **依循法規並落實管理機制**：依《施行細則》第 4 條及《分級辦法》附表十之遠端存取規定，建立申請流程、審批機制、監控機制及定期審查機制。
2. **短天期開放原則**：遠端存取權限應為臨時性，用完即關閉，避免長期開啟的通道成為潛在漏洞。
3. **異常行為管理**：
* 透過 SOC 或 SIEM 監控所有遠端存取行為（非工作時間登入、異常 IP 連線、大量資料下載等）。
* 偵測到異常時，應即時觸發告警並啟動調查和應變程序。
4. **結束後處置**：
* 確實關閉網路連線。
* **更換** VPN 登入密碼（每次使用後立即更換）。
* 導入**多因子鑑別 (MFA)**（如 OTP、實體金鑰）。
---
## 8.4 資訊委外之生命週期
從宏觀角度，資訊委外應遵循結構化的生命週期管理。教材將委外專案分為 5 個面向，對應不同的採購階段：
```mermaid
flowchart LR
A["① 決定需求"] --> B["② 識別可行<br>解決方案"]
B --> C["③ 選定<br>解決方案"]
C --> D["④ 完成建置"]
D --> E["⑤ 確認<br>營運服務"]
A -.- A1["計畫階段"]
B -.- B1["計畫階段"]
C -.- C1["決標階段"]
D -.- D1["履約管理階段"]
E -.- E1["驗收階段"]
```
| 階段 | 重點 | 對應採購階段 |
| :--- | :--- | :--- |
| **① 決定需求** | 明確定義資安需求（機密性、完整性、可用性、存取控制、稽核紀錄、隱私保護等），為後續所有階段奠定基礎 | 計畫 |
| **② 識別可行解決方案** | 分析現況與期望目標落差，識別方案選項，訂定評估指標（含資安風險、廠商資安能力、合規性等） | 計畫 |
| **③ 選定解決方案** | 依據評估指標（含資安指標）對合格廠商進行綜合評估，由決策者選出適當方案 | 決標 |
| **④ 完成建置** | 成立專案組織，督導廠商遵循 RFP 與契約如期如質完成系統建置與測試 | 履約管理 |
| **⑤ 確認營運服務** | 驗收確認所有資安要求已達成，服務進入營運後持續監測 SLA 中資安指標的達成狀況 | 驗收 |
> 📌 **核心觀念**：資安需求若未在「決定需求」階段被明確定義，後續的設計、開發、測試及驗收都將缺乏資安依據，導致系統存在潛在風險。
---
## 8.5 資訊委外之資安要求
將委外視為一個完整專案，分為 **6 個階段**，每個階段都有其獨特的資安考量：
### 8.5.1 計畫階段
> 在正式決定委外前，機關必須進行嚴謹的資安「可行性評估」與「風險評估」。
計畫階段細分為 3 個步驟：
**(1) 資訊委外可行性分析**
* **篩選適合委託之業務**：機敏性極高、涉及國家核心利益或有嚴格法規限制的業務，需審慎評估是否完全委外。
* **成本效益分析**：不僅考量經濟效益，還應包括資安效益（如引入更專業的資安技術及人才），潛在資安事件損失也應納入成本考量。
* **資安風險評估**：
* 可先採**高階風險評估**得出風險值並制定對策。
* 當風險無法降低至可接受等級時，**不宜取得該項產品或服務**。
* 風險值較高時，宜在簽約前進行**詳細風險評估**。
**(2) 資訊委外專案編成**
* 指派對委外專案有充分了解能力之專案負責人。
* 視性質與規模邀請**跨部門人員**參與（採購、法務、會計、業務、資訊、政風等）。
**(3) 資訊委外資安需求識別**
| 步驟 | 說明 |
| :--- | :--- |
| 建立資安策略 | 為委外設定明確資安方向及原則，定期審查並確保相關人員知悉（含委外廠商） |
| 識別廠商限制 | 依業務敏感性及法規要求，考量是否涉及國家機密、影響國安或受 WTO 政府採購協定規範，限制投標廠商或其人員之資格 |
| 邀請廠商提方案 | 透過 RFI 或 RFC 徵詢廠商提供對應資安建議措施 |
| 建立資安管理計畫 | 將資安需求具體化，作為 RFP、契約書及 SLA 之依據 |
### 8.5.2 招標階段
重點在將資安需求有效傳達給潛在廠商，並據此**選出符合資安標準的廠商**。
* **作業內容**：定義評估準則、備妥保密協議書 (NDA)、撰寫招標文件、蒐集服務建議書。
* **資安管理重點**：**RFP 撰寫之完整度**與**評選準則中之資安要求符合度**。
* RFP 中資安要求模糊不清 → 廠商無法提供符合期待的方案，履約後也難以監督。
* 應仔細審查廠商服務建議書對資安要求的「符合度」——不只看「會做」，更要看「如何做」。
* **融入 SSDLC**：招標文件之 RFP 及契約書，應依委外服務之資通系統等級，納入**資通系統防護基準之系統發展生命週期**相關規定（需求、設計、開發、測試、部署與維運、委外等各階段）。
### 8.5.3 決標階段
重點為與廠商之**簽約作業**，將所有資安共識轉化為具法律效力的義務與責任。
* **最終協議**：雙方依據招標文件與服務建議書進行條款確認，特別是資安相關條款。
* **簽約行為重點**：
* 查核廠商是否完成**保密切結**。
* 完成**專案編成**：廠商須提出資安管理措施計畫、指派具資安專業能力之人員、明確資安職責。
* 所有準備工作需有明確紀錄，作為日後稽核依據。
### 8.5.4 履約管理階段
> 持續時間最長、風險最高的階段。前幾個階段是做好「預防」，履約階段的重點在於落實「監控」與「應變」。
教材列出 **7 個面向**：
**(1) 資通安全組織**
* 機關與廠商皆應指定**專案管理人員**，負責推動、協調及督導資安事項。
* 定期召開資安協調會議，並將會議紀錄歸檔。
**(2) 風險持續識別**
* 在核准廠商存取內部設施前，應先識別風險並作適當控制措施。
* 任何存取行為（遠端存取、資料傳輸、特權帳號管理等）都必須先經風險評估。
**(3) 人力資源安全（雇用前、期間、終止或變更）**
* 委外前依工作職掌進行人員篩選。
* 廠商員工應簽署雇用同意書，陳述其資安責任。
* 提供委外人員**資安認知教育及訓練**。
**(4) 實體與環境安全**
* 關鍵或敏感的資訊處理設施應置放於安全區域，並由適當之**安全屏障**與**進出控制措施**加以保護（門禁系統、監視器、訪客登記、權限卡片等）。
**(5) 資訊委外管理**
* 所有委外作業應符合機關之資安政策、程序及資通系統防護基準。
**(6) 使用者存取管理**
* 應有正式程序控制存取權限配置（申請、審批、發放、變更、收回皆須有紀錄）。
* 採**最小權限原則**，僅授予完成任務所需之最小權限。
* 權限應有時效性，到期自動收回。
* 完整的生命週期管理：從**註冊**到不再需要時**註銷**。
* 禁止共用帳號。
**(7) 資通安全事件管理**
* 備妥正式的事件通報與提報程序，提供委外廠商配合並施予教育訓練。
* 要求廠商認知可能之衝擊，並儘快向指定聯絡點通報任何資安事件與弱點。
### 8.5.5 驗收階段
> 確保委外服務在正式上線前，已確實符合所有資安要求。
**(1) 一般驗收程序**
* 依據**契約文件**與履約管理階段執行成果辦理。
* 勞務驗收得以書面或召開審查會方式辦理，並留存書面紀錄。
* 可要求廠商簽約後提交「專案工作計畫書」，確認資安要求事項是否符合。
* 廠商須提供定期工作進度報告會議之內容作為驗收佐證。
**(2) 依委外類別之資安驗收重點**
| 委外類別 | 驗收重點 |
| :--- | :--- |
| **顧問訓練類** | 確認交付物（報告、方案、課程）是否符合需求；若使用軟體工具輔助（如弱點掃描、源碼檢測），應確認工具是否為業界公認之**最適版本** |
| **系統發展類** | 除功能與效能外，應要求廠商提供**安全性檢測證明**（弱點掃描報告、滲透測試報告、源碼檢測報告）；使用非自行開發之元件時，須揭露**第三方元件來源與授權**，確認非來自大陸地區或其他限制地區 |
| **維運管理類** | 類似顧問訓練類，重點在日常營運是否符合資安規範及事件應變能力；若有新發現漏洞，需進行**程式修補或定期弱點掃描** |
| **雲端服務類** | 類似系統發展類，資安保證大多來自廠商提供之證明；應確認與評估雲端供應商宣稱之**認證範圍**是否涵蓋機關所使用的特定服務及功能 |
**(3) 專案結束後之處置**
* **立即停止**委外廠商之**實體與邏輯存取權限**（門禁卡、機房鑰匙、系統帳號、VPN 權限、特權帳號）。
* **回收或銷毀**屬於機關之資訊資產，必要時要求廠商出具**銷毀證明**。
* 確保無備份資料留存於廠商端。
### 8.5.6 保固階段
許多人認為驗收完成便萬事大吉，但保固期內的維護與異常管理同樣至關重要。
**(1) 保固服務**
* 不論軟硬體資產，應以**維持驗收完成時之狀態**為主要目的。
* 廠商有責任在保固期內修補缺陷、處理漏洞，並維持系統穩定與安全。
**(2) 異常管理**
* 保固期間之資訊處理設施與應用軟體系統，均應受到**嚴格之變更管理控制**（變更申請 → 資安評估 → 核准 → 測試 → 實施 → 記錄）。
* 若系統有重大資安顧慮或瑕疵且屬廠商責任，需由廠商另提**變更計畫**。
* 發生異常事件時，由廠商派駐人員負責反映至資訊業務承辦人員，再循正常程序陳報。
---
## 8.6 雲端服務安全：共同責任模型
當委外項目為公有雲服務時，需釐清資安責任邊界。
### 8.6.1 共同責任模型 (Shared Responsibility Model)
| 服務模式 | 雲端業者責任 (Security **of** Cloud) | 機關責任 (Security **in** Cloud) |
| --- | --- | --- |
| **IaaS** | 實體機房、電力、虛擬化層 | **作業系統**、應用程式、資料、防火牆設定 |
| **PaaS** | 實體機房、作業系統、中介軟體 | **應用程式**、資料、使用者權限 |
| **SaaS** | 應用程式及其底層所有設施 | **資料內容**、帳號管理、端點裝置安全 |
> 📌 **記憶口訣**：從 IaaS → PaaS → SaaS，**業者責任越來越多、機關責任越來越少**，但機關對「**資料**」的責任始終存在。
### 8.6.2 雲端驗收的特殊性
* 雲端服務的資安保證大多來自廠商提供之證明（如 ISO 27001、SOC 2 報告）。
* 機關應仔細審閱**認證範圍**：某供應商的 IaaS 通過 ISO 27001，不代表其 SaaS 服務也通過相同驗證。
---
## 8.7 供應鏈安全風險
### 8.7.1 供應鏈攻擊
駭客不直接攻擊防護嚴密的機關，轉而攻擊資安防護較弱的**委外廠商或軟體供應商**，將惡意程式植入合法軟體更新中。
> 💼 **經典案例 — SolarWinds 事件**：攻擊者滲透 SolarWinds 的開發環境，將後門植入其 Orion 平台的軟體更新中。全球約 18,000 個組織（包含美國多個政府機關）在安裝合法更新後遭到入侵。
### 8.7.2 防護策略
* 落實**軟體來源驗證**（檢查數位簽章）。
* 要求廠商揭露第三方元件來源與授權（確認非來自限制地區）。
* 將委外廠商視為延伸的資安防護範圍，要求其提升資安等級。
---
### 💡 總結：委外管理 Check List
- [ ] 計畫階段是否已完成**可行性分析與風險評估**？
- [ ] 招標文件（RFP）是否已**明確納入資安需求與罰則**？
- [ ] 是否已確認廠商**非陸資**且人員**非陸籍**（具敏感性業務）？
- [ ] 是否已簽署**保密協定 (NDA)** 並完成專案編成？
- [ ] 遠端維護是否已啟用 **VPN + MFA** 並採**短天期申請制**？
- [ ] 履約期間是否落實**最小權限**、**禁止共用帳號**、**定期稽核**？
- [ ] 系統上線前是否已完成**安全性檢測**並修補中高風險弱點？
- [ ] 第三方元件是否已揭露**來源與授權證明**？
- [ ] 廠商人員離退時，是否**立即移除**實體與邏輯存取權限？
- [ ] 保固期間是否落實**變更管理控制**？
---
### 💡 總結：各階段資安管控重點
| 階段 | 核心問題 | 關鍵動作 |
| :--- | :--- | :--- |
| **計畫** | 該不該委外？ | 可行性分析、風險評估、資安需求識別 |
| **招標** | 選誰來做？ | RFP 完整度、評選準則、SSDLC 融入 |
| **決標** | 怎麼約束？ | 簽約、保密切結、專案編成 |
| **履約管理** | 做得好不好？ | 7 面向監控（組織、風險、人力、實體、管理、存取、事件） |
| **驗收** | 安全嗎？ | 安全性檢測證明、第三方元件揭露、權限移除 |
| **保固** | 能維持嗎？ | 變更管理、異常通報、維持驗收時資安水準 |
---
### 第 8 單元：資訊委外安全管理
#### 1. 依據《資通安全管理法》第 9 條，機關委外辦理資通系統或服務時，應考量哪些因素來選任適當受託者並監督其維護情形？
- \(A\) 唯一的考量因素是服務的價格高低。
- \(B\) 選擇廠商時，只需考量其過往經驗，其他能力不重要。
- \(C\) 考量受託者之專業能力與經驗、委外項目之性質及資通安全需求。
- \(D\) 無需監督，全權交由廠商負責。
> **答案：C**
---
#### 2. 依據《資通安全管理法施行細則》第 4 條第 1 項，機關在選任及監督委外廠商時，哪些事項是需要注意的？
- \(A\) 評估廠商時，僅需確認其是否具備 ISO 9001 品質認證。
- \(B\) 廠商只需提供過去的合作經驗，其他資安相關資料不需評估。
- \(C\) 評估廠商的資安管理能力、確認資安專業人員、以及委託終止後的資料處理方式。
- \(D\) 無需關注涉及國家機密的委託業務。
> **答案：C**
---
#### 3. 資訊委外主要分為四大類別，以下何者是屬於「顧問訓練類」的服務形態？
- \(A\) ISMS 顧問輔導。
- \(B\) 機房設施管理。
- \(C\) 系統開發。
- \(D\) 軟體即服務 \(SaaS\)。
> **答案：A**
---
#### 4. 為降低遠端維護的資安風險，機關應採取的原則與防護措施為何？
- \(A\) 原則允許、例外禁止。
- \(B\) 原則禁止、例外允許，並應強化多因子鑑別。
- \(C\) 無需額外防護措施。
- \(D\) 遠端維護連線應該只在短天期內開放，不考慮其他條件。
> **答案：B**
---
#### 5. 資訊委外生命週期的「計畫階段」包含哪些關鍵步驟？
- \(A\) 決標與簽約。
- \(B\) 完成建置與確認營運。
- \(C\) 決定需求與識別可行解決方案。
- \(D\) 驗收與保固。
> **答案：C**
---
#### 6. 在委外資安需求識別時，為何需要「識別委外廠商之限制」？
- \(A\) 識別限制只是為了增加招標流程的複雜性。
- \(B\) 識別限制的目的完全在於確保廠商具備足夠的技術能力。
- \(C\) 依據委外業務的敏感性和法規要求，對潛在廠商設定資格限制，特別是涉及國家機密或國家安全。
- \(D\) 識別限制的唯一目的是篩選出價格最低的廠商。
> **答案：C**
---
#### 7. 在資訊委外生命週期的「招標階段」，資安管理重點著重在哪個方面？
- \(A\) 招標階段的資安管理重心完全放在廠商的價格競爭。
- \(B\) 資安管理重點主要在於合約條款的法律審查，不涉及技術層面。
- \(C\) RFP 撰寫之完整度與評選準則中之資安要求符合度。
- \(D\) 招標階段資安管理只針對最終解決方案進行選擇，不考慮前期要求。
> **答案：C**
---
#### 8. 在資訊委外「履約管理階段」中，機關應如何管理資訊委外的使用者存取？
- \(A\) 在專案初期授予委外人員最高權限，後續無需調整。
- \(B\) 委外人員權限由廠商自行管理，機關無需介入。
- \(C\) 機關只需透過電話確認委外人員的權限即可。
- \(D\) 建立正式程序，從開始登記使用註冊，到最終不再需要存取資通系統與服務註銷。
> **答案：D**
---
#### 9. 在資訊委外「驗收階段」，若資通系統使用非委外廠商自行開發的第三方元件，機關應要求廠商揭露哪些資訊？
- \(A\) 揭露第三方程式元件之來源與授權證明，以確保其元件非來自大陸地區或其他限制地區。
- \(B\) 廠商只需要揭露元件的功能說明，不需提供其他證明。
- \(C\) 廠商只需要揭露元件的版本號，其他資訊不重要。
- \(D\) 無需揭露，直接使用即可。
> **答案：A**
---
#### 10. 資訊委外專案「結束後」，機關應立即採取哪些資安措施？
- \(A\) 專案結束後，機關的主要任務是進行最終付款，其他資安措施可延後。
- \(B\) 專案結束後，機關只需回收紙本文件，無需處理電子資料或存取權限。
- \(C\) 立即停止委外廠商之實體與邏輯存取權限，並回收或銷毀屬於機關之資訊資產。
- \(D\) 等待保固期結束再處理。
> **答案：C**
--
# 第九章：資通安全事件通報及應變
> **學習目標**
> 1. 了解資通安全事件通報及應變的整體管理流程，及其法規依據。
> 2. 掌握資通安全事件通報及應變的作業規範（公務機關 vs 特定非公務機關）。
> 3. 學習資通安全事件等級評估方法，以「資訊或資通系統性質」與「CIA 衝擊性」為判斷依據。
> 4. 深入理解通報及應變的詳細作業流程，包括不同層級機關的權責與時限。
> 5. 認識通報及應變演練作業的重要性與內容。
> 6. 掌握資通安全事件處理的各個階段，從準備到經驗學習。
> 7. 了解數位證據的取得與數位鑑識的原則及應用。
> 8. 認識社交工程攻擊的本質、常見手法及正確防範觀念。
---
## 9.1 資通安全事件通報及應變流程
資安事件無法完全避免，因此建立完善的通報與應變機制至關重要。
### 9.1.1 法規依據：《資通安全管理法》
* **第 17 條第 1 項**：**公務機關**為因應資通安全事件，應訂定通報及應變機制。
* **第 24 條第 1 項**：**特定非公務機關**為因應資通安全事件，應訂定通報及應變機制。
### 9.1.2 目的
透過完善的通報與應變機制，全面提升所有機關處理資通安全事件的效能。其範圍不僅涵蓋**技術層面**，更包含**管理層面**的協調與**人員**的應變能力。
### 9.1.3 管理流程（五階段閉環）
通報及應變機制涵蓋事件處理的完整生命週期，從事前準備到事後檢討，形成一個不斷學習與改進的閉環：
```
作業規範 → 事件分級 → 事前演練 → 事中通報及應變 → 事後改善
↑ |
└────────────────── 持續回饋 ─────────────────────────┘
```
**(1) 作業規範**
* **流程定義**：明確界定資安事件處理的每一個步驟，例如誰負責接收通報、誰負責初步判斷、誰負責協調應變。
* **責任分配**：明確劃分每個角色在事件應變中的職責與權限，避免權責不清導致延誤或推諉。
**(2) 事件分級**
* **評估及分級**：依據資料洩露的敏感程度、服務中斷時間長短、影響範圍大小等進行嚴重性評估。
* **影響分析**：評估業務影響、財務損失、聲譽損害等。分級的目的是決定應變資源投入及通報層級與時效。
**(3) 事前演練**
* **模擬演練**：定期進行資安事件演練，模擬不同攻擊情境。
* **應變計畫驗證**：透過演練驗證應變計畫的可行性，發現不足並加以改進，同時提高團隊協作與應變速度。
**(4) 事中通報及應變**
* **通報流程**：事件發生時立即啟動通報機制，明確向誰通報、通報內容及時限。包含內部通報與對外通報（N-ISAC、主管機關、司法單位）。
* **應變措施**：隔離受感染系統、清除惡意程式、修補漏洞、恢復服務。
**(5) 事後改善**
* **事件分析**：深入了解事件發生的根本原因、攻擊手法、應變過程中的優缺點。
* **改善計畫**：制定技術防護加強、管理制度完善、人員培訓補充的具體計畫，確保從每次事件中學習。
---
## 9.2 資通安全事件通報及應變作業規範
在管理流程的基礎上，本節進一步探討「通報」及「應變」的作業規範，提供執行所需的實務指引及具體要求。
### 9.2.1 「通報」作業規範
**(1) 依據**：資通安全事件通報及應變辦法
* **第 9 條**：公務機關應就資通安全事件之通報訂定作業規範。
* **第 15 條**：特定非公務機關應就資通安全事件之通報訂定作業規範。
**(2) 目的**：確保資通安全事件的判斷、層級界定、內部傳達及外部知會都能迅速、準確且有效。
**(3) 通報作業規範應包括下列事項：**
* 判定事件等級之流程及權責。
* 事件之影響範圍、損害程度及機關因應能力之評估。
* 資通安全事件之**內部通報流程**。
* 通知受資通安全事件影響之**其他機關**之方式。
* 前四款事項之**演練**。
* 資通安全事件通報**窗口及聯繫方式**（需保持暢通）。
* 其他資通安全事件通報相關事項。
### 9.2.2 「應變」作業規範
**(1) 依據**：資通安全事件通報及應變辦法
* **第 10 條**：公務機關應就資通安全事件之應變訂定作業規範。
* **第 16 條**：特定非公務機關應就資通安全事件之應變訂定作業規範。
**(2) 目的**：確保事件發生時，能有組織、有計畫地進行損害控制、復原並從中學習。
**(3) 應變作業規範應包括下列事項：**
* 應變小組之**組織**。
* 事件發生前之**演練作業**。
* 事件發生時之**損害控制機制**。
* 事件發生後之**復原、鑑識、調查及改善機制**。
* 事件相關紀錄之**保全**。
* 其他資通安全事件應變相關事項。
> 📌 這些作業規範並非一成不變，需**定期檢視與更新**，以應對不斷演變的資安威脅及組織業務變化。
---
## 9.3 資通安全事件等級評估
「判定事件等級」是應變管理流程中的核心環節。不同等級的事件需投入不同層級的資源，啟動不同範圍的應變計畫，並向不同層級的單位進行通報。
### 9.3.1 評估方法
資通安全事件依嚴重程度，由輕至重分為**第 1 級至第 4 級**。評定時綜合考量兩大面向，以 CIA 三者中**最高的影響等級**作為該事件的綜合分級結果：
| 評估面向 | 內容 |
| :--- | :--- |
| **資訊或資通系統性質** | ① 核心業務資訊或資通系統（涉及或未涉及 CI）② 非核心業務資訊或資通系統 ③ 一般公務機密 ④ 敏感資訊（個資等）⑤ 國家機密 |
| **CIA 衝擊性** | 機密性（洩漏）、完整性（竄改）、可用性（中斷）各自的影響程度 |
> 📌 **關鍵字解釋**
> * **核心業務 vs 非核心業務**：受影響系統若屬核心業務或 CI，事件嚴重性顯著提升。
> * **一般公務機密**：依法有保密義務但不涉國家機密或敏感個資。
> * **敏感資訊**：個資法第 2 條之個人資料（姓名、身分證字號、病歷、財務等）。
> * **國家機密**：依《國家機密保護法》第 2 條及第 4 條核定之絕對機密、極機密及機密。**任何涉及國家機密的事件，無論衝擊程度，一律第 4 級。**
> * **輕微或嚴重**：由政府機關依洩漏、竄改或中斷所造成之影響**自行認定**。
### 9.3.2 機密性影響等級評估
| 影響等級 | 說明 | 案例 |
| :--- | :--- | :--- |
| **1 級**（輕微）| 非核心業務資訊遭**輕微**洩漏 | 機關內部研討會非公開報告被少量洩漏 |
| **2 級** | 非核心業務資訊遭**嚴重**洩漏；或**未涉及 CI 之核心業務**資訊遭輕微洩漏 | 內部辦公網頁遭攻擊，歷年刊物草稿被下載數千份並公開 |
| **3 級** | 未涉及 CI 之核心業務資訊遭**嚴重**洩漏；或**一般公務機密、敏感資訊或涉及 CI 之核心業務**資訊遭輕微洩漏 | 員工薪資系統部分資訊被廠商下載有外傳跡象（敏感資訊輕微洩漏）|
| **4 級**（嚴重）| 一般公務機密、敏感資訊或涉及 CI 之核心業務資訊遭**嚴重**洩漏；或**國家機密**遭洩漏 | 政府服務網站遭駭，數百萬筆民眾個資被竊取販賣 |
### 9.3.3 完整性影響等級評估
| 影響等級 | 說明 | 案例 |
| :--- | :--- | :--- |
| **1 級**（輕微）| 非核心業務資訊或非核心資通系統遭**輕微**竄改 | 內部公告欄過期活動公告被改幾個錯別字 |
| **2 級** | 非核心業務資訊或系統遭**嚴重**竄改；或未涉及 CI 之核心業務資訊或系統遭輕微竄改 | 對外形象網站首頁被置換為不雅圖片（非核心嚴重竄改）；核心業務公告日期被改一天（核心輕微竄改）|
| **3 級** | 未涉及 CI 之核心業務資訊或系統遭**嚴重**竄改；或一般公務機密、敏感資訊或涉及 CI 之核心業務資訊或系統遭輕微竄改 | 會計系統數百筆帳務紀錄遭竄改（核心嚴重竄改）；水庫感測器輔助資料被竄改（CI 輕微竄改）|
| **4 級**（嚴重）| 一般公務機密、敏感資訊或涉及 CI 之核心業務資訊或系統遭**嚴重**竄改；或**國家機密**遭竄改 | 健保給付紀錄數十萬筆被惡意竄改；國防戰略系統作戰目標數據被敵對勢力竄改 |
### 9.3.4 可用性影響等級評估
| 影響等級 | 說明 | 案例 |
| :--- | :--- | :--- |
| **1 級**（輕微）| 非核心業務運作受影響，**可於**容忍中斷時間內回復 | 會議室預約系統故障 3 小時，於容忍時間(4hr)內回復 |
| **2 級** | 非核心業務運作受影響，**無法於**容忍中斷時間內回復；或未涉及 CI 之核心業務或系統，**可於**容忍時間內回復 | 外部意見信箱中斷 6 小時超過容忍時間(4hr)（非核心逾時）；公文系統因電力故障中斷 1 小時但於容忍時間內回復（核心未逾時）|
| **3 級** | 未涉及 CI 之核心業務或系統，**無法於**容忍時間內回復；或涉及 CI 之核心業務或系統，**可於**容忍時間內回復 | 線上申辦系統中斷逾 12 小時超過容忍時間（核心逾時）；交通號誌監控系統中斷 1 小時但於容忍時間內回復（CI 未逾時）|
| **4 級**（嚴重）| 涉及 CI 之核心業務或系統，**無法於**容忍時間內回復 | 國家電網電力調度系統遭攻擊中斷逾 8 小時，大規模停電 |
### 9.3.5 CIA 影響等級評估總表
| 等級 | 機密性（洩漏）| 完整性（竄改）| 可用性（中斷）|
| :---: | :--- | :--- | :--- |
| **1 級** | 非核心 + 輕微 | 非核心 + 輕微 | 非核心 + **可**於容忍時間內回復 |
| **2 級** | 非核心 + 嚴重 / 核心(非CI) + 輕微 | 非核心 + 嚴重 / 核心(非CI) + 輕微 | 非核心 + **不可**回復 / 核心(非CI) + **可**回復 |
| **3 級** | 核心(非CI) + 嚴重 / 公務機密·敏感·核心(CI) + 輕微 | 核心(非CI) + 嚴重 / 公務機密·敏感·核心(CI) + 輕微 | 核心(非CI) + **不可**回復 / 核心(CI) + **可**回復 |
| **4 級** | 公務機密·敏感·核心(CI) + 嚴重 / 國家機密 | 公務機密·敏感·核心(CI) + 嚴重 / 國家機密 | 核心(CI) + **不可**回復 |
> 📌 **速記規律**：每往上升一級，就是「影響程度從輕微變嚴重」或「系統性質從非核心→核心(非CI)→CI 及敏感→國家機密」升級。
### 9.3.6 等級評估案例（一）
> **情境**：A 機關發現員工電腦檔案被加密（勒索軟體）。該員工負責核心資通系統相關行政作業，系統**未涉及 CI**。可用其他電腦代替，未造成資料外洩。資訊人員進行還原處理。
| CIA 構面 | 分析 | 等級 |
| :--- | :--- | :---: |
| 機密性 | 未造成資料外洩 | 0（無須通報）|
| 完整性 | 核心業務電腦被加密＝系統遭變更竄改（未涉及 CI、屬核心、輕微竄改）| **第 2 級** |
| 可用性 | 可用其他電腦代替，無系統運作中斷 | 0（無須通報）|
**綜評結果：第 2 級**（取最高等級）
### 9.3.7 等級評估案例（二）
> **情境**：B 機關「製程資料收集系統」為**負責 CI 運作團隊存放執行紀錄之系統**，每日備份。系統遭植入 KillDisk 程式，刪除主機 MBR 及系統資料。處理人員透過備份還原前日資料，各團隊重新匯入當日紀錄。
| CIA 構面 | 分析 | 等級 |
| :--- | :--- | :---: |
| 機密性 | KillDisk 目的是破壞非竊取，未造成外洩 | 0（無須通報）|
| 完整性 | MBR 及系統資料被刪除＝涉及 CI 之核心資通系統遭**嚴重**竄改 | **第 4 級** |
| 可用性 | 涉及 CI 核心系統運作中斷，但透過備份還原，於容忍中斷時間內回復 | **第 3 級** |
**綜評結果：第 4 級**（取最高等級）
---
## 9.4 資通安全事件通報及應變作業流程
強調「黃金時間」的處理原則。
### 9.4.1 資安事件處理之相關訊息
**(1) 通報基本項目**（記錄事件基本訊息，為後續調查提供依據）：
* 發生機關
* 發生或知悉時間
* 狀況描述
* 其他相關事項
* 事件等級評估
* 外部支援需求評估
* 因應事件所採取的措施
**(2) 損害控制內容**：記錄損害控制或復原的過程。
**(3) 調查、處理及改善報告**（深入分析根本原因，制定改善措施）：
* 事件發生或知悉、完成損害控制或復原的**時間**
* 事件影響範圍及**損害評估**
* 損害控制及**復原過程**
* 事件**調查及處理**過程
* 事件**根因分析** (Root Cause Analysis)
* 為防範類似事件再次發生所採取的**管理、技術、人力或資源**等措施
* 預定完成**時程**及**成效追蹤機制**
### 9.4.2 通報及應變作業流程
**(1) 通報機關的通報責任**
* **黃金 1 小時**：知悉資安事件後 **1 小時內** 完成通報。
* **「知悉」的定義**：不需待事件完全釐清或損害評估完成才通報，只要有**合理懷疑或初步證據**即應啟動。
**(2) 上級或監督機關及中央目的事業主管機關的審核**
| 事件等級 | 審核時限 | 說明 |
| :--- | :---: | :--- |
| 1 級、2 級（較輕微）| **8 小時**內 | 中央目的事業主管機關**定期彙送**至主管機關 |
| 3 級、4 級（較嚴重）| **2 小時**內 | 中央目的事業主管機關 **1 小時內**立即轉送主管機關 |
**(3) 主管機關的覆核範圍**
* **公務機關**：主管機關**應**覆核所有第 1 級至第 4 級之資安事件。
* **特定非公務機關**：主管機關**得**覆核所有第 1 級至第 4 級之資安事件。
**(4) 損害控制及復原時限及結案**
| 項目 | 1 級、2 級事件 | 3 級、4 級事件 |
| :--- | :---: | :---: |
| 完成損害控制及復原 | **72 小時**內 | **36 小時**內 |
| 調查、處理及改善報告 | **1 個月**內 | **1 個月**內 |
> 📌 報告如有特殊情況，可提出延長提交申請。若調查過程中事件影響擴大，通報機關須適時提出**等級變更申請**並詳細說明原因。
### 9.4.3 公務機關通報及應變作業流程
```
【第一階段】事件知悉與初步通報
公務機關 ──1小時內通報──→ 上級或監督機關 ──副知──→ 主管機關
（視情況召開資安防護會議）
【第二階段】上級審核與支援
上級或監督機關 ──1小時內通知審核結果──→ 主管機關
（視需要提供技術支援、人力、協調跨機關資源）
【第三階段】事件處理及結案
公務機關：立即處理（隔離、鑑識、修補、復原）
3/4級事件 → 36小時內完成損害控制或復原
→ 向上級或監督機關提交結案通知
【第四階段】調查、改善與最終報告
公務機關 → 1個月內提交調查處理改善報告 → 上級機關 + 主管機關檢視
主管機關進行最終覆核
```
> 📌 **無上級機關或監督機關者**，依資安法第 14 條及第 17 條直接向主管機關通報：總統府、五院向主管機關提出；直轄市及縣市政府向主管機關提出；區公所向直轄市政府提出、鄉鎮市公所向縣政府提出。
### 9.4.4 特定非公務機關通報及應變作業流程
```
【第一階段】知悉事件 → 1小時內通報 → 中央目的事業主管機關
【第二階段】中央目的事業主管機關審核
・1/2級事件：定期彙送主管機關
・3/4級事件：1小時內轉送主管機關（主管機關視情況召開資安防護會議）
【第三階段】事件處理 → 3/4級事件36小時內完成 → 提交結案通知
【第四階段】1個月內提交報告 → 中央目的事業主管機關審查 → 3/4級報告轉送主管機關覆核
```
> 📌 **公務 vs 特非關鍵差異**：公務機關通報對象為「上級或監督機關」再到主管機關；特定非公務機關直接通報「中央目的事業主管機關」。
---
## 9.5 資通安全事件通報及應變演練作業
演練是資安防護體系中不可或缺的一環，能有效驗證應變計畫可行性、提升人員熟練度、發現潛在盲點。
### 9.5.1 強制性演練要求
* **適用對象**：總統府、中央一級機關之直屬機關，以及直轄市及縣（市）政府。
* **成果報告**：演練完成後 **1 個月內** 將執行情形及成果報告送交主管機關。
* **最低頻率**：
* **社交工程演練**：每半年 1 次
* **資通安全事件通報及應變演練**：每年 1 次
### 9.5.2 演練項目對照表
| 演練項目 | 公務機關 | 特定非公務機關 |
| :--- | :---: | :---: |
| 社交工程演練 | ✅（強制）| 由中央主管機關另行規定 |
| 資通安全事件通報及應變演練 | ✅（強制）| 由中央主管機關另行規定 |
| 網路攻防演練 | ✅ | ✅ |
| 情境演練 | ✅ | ✅ |
| 其他必要之演練 | ✅ | ✅ |
> 📌 演練的目標並非追求完美，而是**發現計畫弱點及人員不足**，體現 PDCA 中「查核」與「行動」的環節。
---
## 9.6 資通安全事件處理
資通安全事件處理是一個系統化、多階段的程序。本節依序探討處理的**七大目的**、**處理計畫四大要素**、**六階段處理程序**，以及**個資外洩的特殊處理**。
### 9.6.1 資安事件處理的七大目的
1. **確認資安事件是否發生**：先驗證警報真實性，避免「狼來了」效應。
2. **降低對業務與網路服務的中斷時間**：核心目標，直接關乎營運效率。
3. **提供精準與及時的資訊**：向內部（管理階層）及外部（監管機構、客戶）保持透明。
4. **於規定時間內完成損害控制或復原作業**：呼應通報應變流程中的時限要求。
5. **保障由政策與法律要求的權利**：確保應變過程符合個資法、資安法等法定義務。
6. **實作控制措施以維護監管鏈**：確保數位證據從收集到呈堂的完整性與可信度。
7. **讓法務單位可對惡意者提起訴訟**：透過嚴格證據保全與鑑識分析，提供法律追訴所需證據。
### 9.6.2 資安事件處理計畫（四大要素）
一個完善的計畫需透過以下四大支柱持續維護與強化：
**(1) 定期重新審查計畫文件**：隨人員異動、技術變遷、業務流程改變而更新。
**(2) 教育訓練**：應涵蓋組織分工與權責、資安技能、危機處理、數位鑑識、調查技巧及溝通能力。
**(3) 財務支持**：預算編列、額外設備、專業人員配置、訓練費用等。
**(4) 持續演練**：定期模擬資安事件，測試應變流程、人員技能、工具有效性，每次演練後進行事後檢討並修正優化。
### 9.6.3 資安事件處理程序（六大階段）
業界通用的資安事件處理生命週期：**準備 → 識別 → 封鎖 → 根除 → 復原 → 經驗學習**
#### 階段一：準備 (Preparation)
事件發生前的所有準備工作，是成功處理的基石。
**六大核心要素：**
* **組織資安事件處理小組 (CSIRT)**：跨部門協作，明確架構、角色、職責與權限。
* **建立處理策略**：定義總體方針與優先順序（例如優先恢復服務 vs 優先鑑識追溯）。
* **設計處理程序**：為各類事件（惡意程式、資料外洩、DDoS）設計標準作業程序。
* **建立溝通管道**：對內（管理階層、受影響部門）與對外（客戶、監管機構、媒體）的溝通流程。
* **蒐集所需資源**：人力（資安專業人員）、技術工具（鑑識軟體、SIEM）、財務支持。
* **練習、練習及再練習**：定期演練，驗證計畫，找出弱點並修正。
**CSIRT 小組組成**：技術部門（IT、資安及系統管理）、管理人員、法務部門、數位鑑識專家、公共關係部門、人力資源部門、實體安全與維護部門、通訊部門。
#### 階段二：識別 (Identification)
偵測並確認事件是否真實發生，判斷性質與影響範圍。
* **確認真實性與範圍**：判斷事件是惡意攻擊或無意內部錯誤，快速精確判斷「哪些系統」「哪些人員」「哪些資訊資產」受影響。
* **偵測可疑指標**：
* 異常帳號與檔案活動（非授權帳號、不明新檔案、關鍵檔案被修改）
* IDS/IPS 警報、防火牆異常連線
* 系統效能異常（變差、無回應、不穩定）
* 透過 SIEM、EDR 或封包分析追蹤攻擊行為
* **數位證據取得與監管**：
* 採用經認可之**磁碟映像複製工具**進行位元級複製
* 配合**雜湊函數**（SHA-256）驗證原始資料與映像檔一致性
* **錄影紀錄**採證過程
* 維護**監管鏈**（明確保管人、詳細交接紀錄、安全儲存保護）
#### 階段三：封鎖 (Containment)
限制事件擴散，阻止損害蔓延，為根除與復原爭取時間。
* **識別可信任來源**：避免誤判影響正常業務。
* **避免驚動入侵者**：過於激烈的行動可能導致攻擊者銷毀證據。
* **同步進行鑑識**：封鎖與證據分析同步展開。
* **具體封鎖行動**：
* 變更受影響帳號之通行碼與權限
* 變更受感染主機名稱及 IP 位址
* 將可疑流量導向不存在位址（黑洞）
* 阻擋攻擊來源 IP 或網段
* 在類似系統上更新修補程式
* 必要時暫時關閉受影響服務
#### 階段四：根除 (Eradication)
徹底移除惡意程式及攻擊者留下的所有痕跡。
* **決策點：移除 vs 回存**
* 簡單惡意程式可透過工具清除；複雜入侵（如 rootkit）建議**重建系統**。
* 若決定回存，須確保備份資料**乾淨未受感染**，可在隔離環境中試恢復。
* **強化防禦**：
* 部署新的安全工具（EDR、NTA）、更新防火牆規則、實施更精細的網路分段
* 提升稽核紀錄詳細程度
* 在其他系統中主動排查已發現的惡意程式特徵
* 更嚴謹控管存取來源（實施 MFA、強化密碼策略、限制橫向移動）
#### 階段五：復原 (Recovery)
將受影響的系統及服務恢復至正常運作狀態。
* **優先順序**：依 BCP 中 RTO、RPO 定義，優先恢復最關鍵的系統。
* **徹底驗證**：重新上線前進行功能性測試和安全驗證，確保無殘留後門。
* **持續溝通**：與利害關係人溝通復原進度。
* **加強監控**：
* 客製化 IDS/IPS 規則（依據 IOCs 及攻擊模式）
* 在網路、主機及應用程式中額外實作更詳細的稽核紀錄
#### 階段六：經驗學習 (Lessons Learned)
整個循環的終點，也是下一個「準備」階段的起點。
* **召開經驗學習會議**（儘速，趁記憶猶新）：
* 識別成功經驗（值得推廣的最佳實務）
* 面對不足之處（識別延遲、封鎖不徹底、復原困難、溝通障礙）
* 深入**根因分析**（組態錯誤？漏洞未修補？意識不足？供應鏈風險？）
* 評估證據鑑識回顧
* **改進行動**：
* 更新資安事件處理計畫與程序
* 強化防禦機制
* 加強訓練與演練
* 優化財務支持及技術資源
### 9.6.4 個人資料外洩事件之特殊處理
處理個資外洩，除了遵循標準六大步驟外，更需考量法律責任與社會觀感。
**「識別」與「封鎖」階段的特殊要求：**
* 確定外洩資料的**類型**（姓名、身分證字號、病歷、財務資訊等）
* 確認受影響之**個資主體數量與身分**
* 查明**外洩方式**（竊取、誤傳、惡意公開）
**「復原」階段的特殊要求：**
* 依《個人資料保護法》**主動通知**個資被外洩的對象，內容包含：事件發生時間、外洩資料類型、可能造成的損害、已採取的應變措施、受害者可採取的保護行動。
* 提供**改善方案**以防止進一步損害：
* 提供身分盜用監控服務（如信用監測）
* 建議受害者更改密碼並啟用 MFA
* 提醒警惕釣魚郵件或詐騙電話
* 設立專屬諮詢熱線或網站
---
## 9.7 數位證據及數位鑑識
### 9.7.1 數位證據的定義與特性
**數位證據的四個核心要件：**
1. **由電腦來儲存或是傳送的資料**：涵蓋硬碟檔案、網路設備日誌、電子郵件、聊天紀錄，甚至記憶體中的「揮發性資料」。具有**易變性、隱匿性與無形性**。
2. **該資料可以用來進行後續的偵查**：重建事件時間軸、分析攻擊手法、識別入侵來源與影響範圍的可靠依據。
3. **偵查目的是確認或否定或反駁有關犯罪的推斷陳述**：要求採集與分析過程嚴謹、科學、客觀。
4. **該資料在法庭上具有具體的用途**：合規收集及保存的數位證據可作為呈堂證供，前提是嚴格遵循取得規範及監管鏈要求。
### 9.7.2 數位鑑識
數位鑑識是鑑識科學的領域之一，將數位資料轉化為可信賴、可追溯、可呈堂證供的過程。
**三大鑑識原則：**
| 原則 | 說明 |
| :--- | :--- |
| **物證的監管鏈 (Chain of Custody)** | 詳盡書面紀錄數位證據自被發現、扣押、蒐集、保管到運送、分析及呈堂的每一環節。明確「誰」在「何時」「何地」「為何」持有或處理了證據。核心目標：**確保資料的一致性與完整性**。|
| **數位證據的完整性** | 保證數位證據自採集那一刻起內容未發生任何變動。透過**雜湊函數**（如 SHA-256）產生「數位指紋」，驗證各階段的完整性。|
| **客觀性** | 鑑識過程保持中立公正，不受主觀偏見影響。鑑識人員的職責是**讓證據說話**，而非支持預設結論。須遵循標準流程，允許結果被第三方複查。|
> 📌 **鑑識實務要點**：
> * 使用**寫入保護裝置 (Write Blocker)** 進行採證，避免汙染原始證據。
> * 製作**映像檔 (Image)** 進行分析，**絕對不可以直接在原始證物上操作**。
> * 數位鑑識亦可運用在不涉及法律訴訟的一般場合，幫助理解事件根源、找出防護弱點。
---
## 9.8 社交工程 (Social Engineering)
### 9.8.1 何謂社交工程
社交工程的定義可歸納為三個特點：
1. **利用人性弱點**：利用信任、恐懼、貪婪、好奇、同情、權威崇拜、疲勞或匆忙，以簡單的溝通與欺騙伎倆，遂行非法存取與破壞行為。
2. **繞過技術防護，騙取機敏資料**：不需頂尖電腦技術，只要受害方缺乏防詐認知，即可避過軟硬體安全防護，騙取帳號、通行碼、身分證號碼等。
3. **善於偽裝，利用時事與日常情境**：利用重大新聞事件做誘餌，也利用日常活動（線上理財、投資、帳單管理、購物）降低戒心。
### 9.8.2 常見的八種攻擊手法
| # | 手法 | 媒介 | 說明 |
| :---: | :--- | :--- | :--- |
| 1 | **網路釣魚 (Phishing)** | 電子郵件 | 偽裝成銀行、機關或同事，製造緊急性或誘惑性，誘騙點擊惡意連結或輸入資訊。|
| 2 | **釣魚簡訊 (Smishing)** | 手機簡訊 | SMS + Phishing。偽裝成包裹通知、銀行警示、點數兌換等，簡訊內容短且警惕性低，欺騙性更強。|
| 3 | **電話詐騙 (Vishing)** | 電話語音 | Voice + Phishing。冒充銀行客服、地檢署、健保局等，利用急迫、恐懼及權威氛圍，誘導轉帳或提供 OTP。|
| 4 | **即時通訊詐騙** | Line/WhatsApp 等 | 盜用親友帳號或建假帳號，以緊急借錢、代買點數卡、投票、分享惡意連結等名義詐騙。|
| 5 | **冒充 (Pretexting)** | 多種管道 | 事先編造虛假但合理的故事或情境，冒充 IT 支援、審計員或供應商套取資訊。常是更複雜攻擊的前奏。|
| 6 | **誘餌 (Baiting)** | 實體或數位 | 提供有吸引力的誘餌。實體如帶有惡意程式的 USB 隨身碟丟在公共場所；數位如免費但帶毒的軟體下載。|
| 7 | **尾隨 (Tailgating)** | 實體門禁 | 跟隨合法授權人員進入受限制區域，利用善意與禮貌，趁門未關時溜入。|
| 8 | **蜜罐陷阱 (Honeytrap)** | 社交媒體 | 利用浪漫或情感關係誘使目標透露敏感資訊（財務、職場機密）或執行特定操作。|
### 9.8.3 社交工程演練作業流程（以電子郵件為例）
```
(1) 計畫與準備 → (2) 執行模擬攻擊 → (3) 評估與分析 → (4) 回饋與教育 → (5) 持續改進
↑ |
└──────────────────────── 定期循環 ────────────────────────────────────────┘
```
**(1) 計畫與準備**：確立目標（如評估對釣魚郵件識別能力）、設計逼真的攻擊場景（模擬釣魚郵件範本）。
**(2) 執行模擬攻擊**：發送模擬釣魚郵件，詳細記錄員工反應（開啟郵件、點擊連結、輸入帳密、正確回報的人數）。
**(3) 評估與分析**：計算各項反應率，找出哪些部門或類型的員工更容易上當，哪種手法最具欺騙性。
**(4) 回饋與教育**：對上當員工提供具體回饋、解釋受騙原因，組織全員資安意識培訓。
**(5) 持續改進**：更新郵件過濾規則、加強終端防護、優化事件回報流程，回到定期演練。
### 9.8.4 案例分析
> **情境**：攻擊者利用學術網路帳號，冒充「監察院名義」，向政府機關人員及企業發送含惡意附件的社交工程電子郵件。郵件主旨偽裝成「公職人員財產申報」，附件為 `財產申報.rar` 壓縮檔，提供「解壓縮密碼」降低戒心。開啟後觸發惡意程式，植入後門竊取帳號通行碼。
**運用到的手法**：網路釣魚（電子郵件攻擊）＋ 冒充（偽裝監察院名義）＋ 誘餌（財產申報壓縮檔）
### 9.8.5 正確防範觀念
> 📌 **座右銘**：「**不輕信、多求證、速通報**」
1. **隨時提高警覺**：在沒有適當認證的情況下不應輕信他人，出現任何社交工程攻擊警訊都應保持**小心求證**的戒心。
2. **具體防範行動**：
* **不**未經確認即提供資料（帳號密碼、OTP 驗證碼等）
* **不**開啟來路不明的電子郵件及附加檔案（特別是壓縮檔或可執行檔）
* **不**連結及登入未經確認的網站（檢查網址正確性及 HTTPS）
* **不**下載非法軟體及檔案
* **避免**在公共場所使用免費 WiFi 熱點（如需使用應搭配 VPN）
3. **任何資訊釋出都要確認要求者身分及授權**：無論電話、即時通訊或面對面，不僅憑表面資訊就輕信。
4. **遇到疑似攻擊事件立即通報**：即使沒有上當，發現可疑社交工程企圖也應立即向資安部門通報。
---
### 💡 總結：事件應變 Check List
- [ ] 是否在知悉事件 **1 小時內** 完成通報？
- [ ] 是否依據 **CIA 衝擊**（取最高等級）與 **業務性質** 正確評估事件等級 (1~4 級)？
- [ ] 重大事件 (3、4 級) 是否在 **36 小時內** 完成損害控制及復原？
- [ ] 處理過程是否落實 **準備 → 識別 → 封鎖 → 根除 → 復原 → 經驗學習** 六階段？
- [ ] 鑑識過程是否確保 **監管鏈** 完整且未汙染原始證物？
- [ ] 個資外洩事件是否已依個資法 **主動通知** 受影響當事人？
- [ ] 調查處理改善報告是否在 **1 個月內** 提交？
---
### 第 9 單元：資通安全事件通報及應變
#### 1. 依據《資通安全事件通報及應變辦法》的「管理流程」，以下哪一個環節是事件發生「事前」應辦理的重要步驟？
- \(A\) 進行事件的初步分級與影響分析。
- \(B\) 執行事件處理過程中的通報與應變措施。
- \(C\) 對已發生的事件進行改善措施與分析總結。
- \(D\) 應變計畫的演練與驗證。
> **答案：D**
---
#### 2. 資通安全事件等級評估時，若機關的「一般公務機密或敏感資訊」遭到「嚴重洩漏」，或「國家機密」遭到洩漏，其機密性應評估為哪個等級？
- \(A\) 第 1 級。
- \(B\) 第 2 級。
- \(C\) 第 3 級。
- \(D\) 第 4 級。
> **答案：D**
---
#### 3. 在資通安全事件處理中，公務機關或特定非公務機關在「知悉」資安事件發生後，應在多久時間內「向上通報」相關事件資訊？
- \(A\) 1 小時內。
- \(B\) 2 小時內。
- \(C\) 4 小時內。
- \(D\) 24 小時內。
> **答案：A**
---
#### 4. 發生「第 3 級或第 4 級」資安事件時，上級或監督機關或中央目的事業主管機關應在多久時間內完成審核作業？
- \(A\) 8 小時內。
- \(B\) 4 小時內。
- \(C\) 2 小時內。
- \(D\) 1 小時內。
> **答案：C**
---
#### 5. 資通安全事件處理的「目的」之一是為了確保符合《資通安全管理法》等法律要求。此外，處理目的還包括哪些？
- \(A\) 資安事件處理的唯一目的就是追溯攻擊者身分。
- \(B\) 僅為降低對業務與網路服務的中斷時間。
- \(C\) 確認資安事件是否發生、提供精準及時資訊、保障由政策與法律要求的權利、實作控制措施以維護監管鏈。
- \(D\) 處理資安事件主要目的是為了事後懲處相關人員。
> **答案：C**
---
#### 6. 資安事件處理後，應撰寫改善報告，其提交時限原則上為？
- \(A\) 3 天。
- \(B\) 1 週。
- \(C\) 1 個月。
- \(D\) 1 年。
> **答案：C**
---
#### 7. 資安事件處理程序中的「封鎖 \(Containment\)」階段，主要目的是什麼？
- \(A\) 徹底清除惡意程式。
- \(B\) 限制資安事件的擴散範圍，阻止損害進一步蔓延。
- \(C\) 恢復受影響的系統和服務。
- \(D\) 從事件中汲取教訓。
> **答案：B**
---
#### 8. 在處理個人資料外洩事件時，除了遵循標準處理程序外，個人資料在「復原」階段有何特殊要求？
- \(A\) 只需要對外發表道歉聲明，無需採取其他實質措施。
- \(B\) 在復原階段，只需進行內部調查，不需通知外部受影響者。
- \(C\) 應主動通知個資被外洩的對象，並提供改善方案防止進一步損害。
- \(D\) 無需額外處理，等待受害者聯繫。
> **答案：C**
---
#### 9. 關於「數位證據」的特性，以下何者敘述正確？
- \(A\) 數位證據僅限於電子郵件和檔案。
- \(B\) 數位證據的取得和保管無需特殊規範。
- \(C\) 數位證據由電腦儲存或傳送，可用於偵查，並在法庭上具有具體用途。
- \(D\) 數位證據一旦產生，其內容無法被改變。
> **答案：C**
---
#### 10. 社交工程攻擊主要利用了「人」的哪些弱點來達成其非法目的？
- \(A\) 社交工程攻擊完全是透過利用系統的技術漏洞來實現。
- \(B\) 利用人性弱點，應用簡單的溝通與欺騙伎倆。
- \(C\) 僅針對電腦系統進行攻擊。
- \(D\) 需要具備頂尖的電腦專業技術。
> **答案：B**
--
# 附表一到附表八 資通安全責任等級應辦事項總表（114年修正）
## 等級適用對象
| 等級 | 公務機關 | 特定非公務機關 |
| :---: | :--- | :--- |
| **A** | 附表一 | 附表二 |
| **B** | 附表三 | 附表四 |
| **C** | 附表五 | 附表六 |
| **D** | 附表七（共用） | ← |
| **E** | 附表八（共用） | ← |
---
## 一、管理面應辦事項
| 項目 | A 級 | B 級 | C 級 | D 級 | E 級 |
| :--- | :---: | :---: | :---: | :---: | :---: |
| 核定自身資通安全責任等級 | 3年 | 3年 | 3年 | 3年 | 3年 |
| 資通系統分級及防護基準 | 1年內，每年檢視 | 1年內，每年檢視 | 2年內，每年檢視 | － | － |
| ISMS 導入 | 2 年內 | 2 年內 | 2 年內 | － | － |
| 公正第三方驗證 | 3 年內 | 3 年內 | －＊ | － | － |
| 資安專職人員 | 1 年內，4 人 | 1 年內，2 人 | 1 年內，1 人 | － | － |
| 內部資安稽核 | 2 次/年 | 1 次/年 | 1 次/2年 | － | － |
| 營運持續計畫演練 | 1 次/年 | 1 次/2年 | 1 次/2年 | － | － |
| 資安治理成熟度評估 | 1 次/年＊＊ | 1 次/年＊＊ | － | － | － |
> ＊ C 級公務機關無須第三方驗證，特定非公務機關亦同
> ＊＊ 特定非公務機關僅「關鍵基礎設施提供者」須辦理
---
## 二、技術面應辦事項
| 項目 | A 級 | B 級 | C 級 | D 級 | E 級 |
| :--- | :---: | :---: | :---: | :---: | :---: |
| 弱點掃描 | 2 次/年 | 1 次/年 | 1 次/2年 | － | － |
| 滲透測試 | 1 次/年 | 1 次/2年 | 1 次/2年 | － | － |
| 資通安全健診 | 1 次/年 | 1 次/2年 | 1 次/2年 | － | － |
| 資通安全監控管理機制 | 1 年內 | 1 年內 | － | － | － |
| 政府組態基準 \(GCB\) | 1 年內＊ | 1 年內＊ | － | － | － |
| 資通安全弱點管理 | 1 年內＊＊ | 1 年內＊＊ | 2 年內＊＊ | － | － |
| 端點偵測及應變機制 \(EDR\) | 1 年內 | 1 年內 | － | － | － |
| 資通安全防護 | 1 年內 | 1 年內 | 1 年內 | 1 年內 | － |
> ＊ GCB 僅公務機關須辦理，特定非公務機關免辦
> ＊＊ 特定非公務機關僅「關鍵基礎設施提供者」須依主管機關指定方式導入
---
## 三、資通安全健診項目
| 項目 | A 級 | B 級 | C 級 |
| :--- | :---: | :---: | :---: |
| 網路架構檢視 | ✓ | ✓ | ✓ |
| 網路惡意活動檢視 | ✓ | ✓ | ✓ |
| 使用者端電腦惡意活動檢視 | ✓ | ✓ | ✓ |
| 伺服器主機惡意活動檢視 | ✓ | ✓ | ✓ |
| 目錄服務系統設定及防火牆連線設定檢視 | ✓ | ✓ | ✓ |
| 核心資通系統資料庫安全檢視 | ✓ | ✓ | － |
---
## 四、資通安全防護項目
| 項目 | A 級 | B 級 | C 級 | D 級 |
| :--- | :---: | :---: | :---: | :---: |
| 防毒軟體 | ✓ | ✓ | ✓ | ✓ |
| 網路防火牆 | ✓ | ✓ | ✓ | ✓ |
| 電子郵件過濾機制 | ✓ | ✓ | ✓ | － |
| 入侵偵測及防禦機制 \(IDPS\) | ✓ | ✓ | － | － |
| 應用程式防火牆 \(WAF\) | ✓ | ✓ | － | － |
| 進階持續性威脅攻擊防禦 \(APT\) | ✓ | － | － | － |
> 電子郵件過濾機制：具有郵件伺服器者應備
> 應用程式防火牆：具有對外服務之核心資通系統者應備
---
## 五、認知與訓練
### 5.1 教育訓練時數
| 對象 | A 級 | B 級 | C 級 | D 級 | E 級 |
| :--- | :---: | :---: | :---: | :---: | :---: |
| 資安專職人員 | 12hr/年（資安） | 12hr/年（資安） | 12hr/年（資安） | － | － |
| 資安專職人員以外之資訊人員 | 3hr/2年（資安）+<br>3hr/年（通識） | ← | ← | 3hr/2年（資安）+<br>3hr/年（通識） | － |
| 一般使用者及主管 | 3hr/年（通識） | 3hr/年（通識） | 3hr/年（通識） | 3hr/年（通識） | 3hr/年（通識） |
### 5.2 資安專業證照及職能訓練證書
| 類型 | 公務機關 | 特定非公務機關 |
| :--- | :--- | :--- |
| **A/B/C 級** | 證照**及**證書**各一張**以上 | 證照**或**證書**一張**以上 |
> 這是公務機關與特定非公務機關的**重要差異**！
---
## 六、公務機關 vs 特定非公務機關差異速查
| 項目 | 公務機關 | 特定非公務機關 |
| :--- | :--- | :--- |
| 政府組態基準 \(GCB\) | A、B 級須辦理 | **免辦** |
| 資安治理成熟度評估 | A、B 級每年辦理 | 僅**關鍵基礎設施提供者**須辦理 |
| 資安弱點管理導入 | 依規定期限導入 | 僅**關鍵基礎設施提供者**須依主管機關方式導入 |
| 資安證照要求 | 證照**及**證書各一張 | 證照**或**證書一張 |
---
## 七、D 級與 E 級簡易對照
| 項目 | D 級 | E 級 |
| :--- | :---: | :---: |
| 防毒軟體 | ✓ | － |
| 網路防火牆 | ✓ | － |
| 資訊人員訓練 | 3hr/2年（資安）+ 3hr/年（通識） | － |
| 一般使用者訓練 | 3hr/年（通識） | 3hr/年（通識） |
> **E 級最簡單**：僅需一般使用者及主管每年 3 小時通識訓練
---
## 考試重點速記
| 記憶點 | 內容 |
| :--- | :--- |
| **專職人員數** | A=4、B=2、C=1、D/E=0 |
| **第三方驗證** | A、B 級須 3 年內通過，C 級免 |
| **GCB** | 僅**公務機關** A、B 級 |
| **APT 防禦** | 僅 **A 級** |
| **資料庫安全檢視** | 僅 **A、B 級** |
| **證照要求差異** | 公務「及」、特非「或」 |
| **E 級唯一要求** | 3hr/年 通識訓練 |
---
# 附表九 資通系統防護需求分級原則（114年修正）
## 分級判定原則
> **重要**：資通系統之防護需求等級，以機密性、完整性、可用性及法律遵循性四個構面中，**任一構面之最高者**定之。
---
## 一、影響程度對照表
| 等級 | 影響程度關鍵字 |
| :---: | :--- |
| **高** | 非常嚴重或**災難性**之影響 |
| **中** | **嚴重**之影響 |
| **普** | **有限**之影響 |
---
## 二、四大構面分級原則
### 2.1 機密性（未經授權之資訊揭露）
| 等級 | 判定條件 |
| :---: | :--- |
| **高** | 資訊揭露對機關營運、資產或信譽產生**非常嚴重或災難性**影響 |
| **中** | 資訊揭露對機關營運、資產或信譽產生**嚴重**影響 |
| **普** | 資訊揭露對機關營運、資產或信譽產生**有限**影響 |
### 2.2 完整性（資訊錯誤或遭竄改）
| 等級 | 判定條件 |
| :---: | :--- |
| **高** | 資訊錯誤或竄改對機關營運、資產或信譽產生**非常嚴重或災難性**影響 |
| **中** | 資訊錯誤或竄改對機關營運、資產或信譽產生**嚴重**影響 |
| **普** | 資訊錯誤或竄改對機關營運、資產或信譽產生**有限**影響 |
### 2.3 可用性（存取或使用之中斷）
| 等級 | 判定條件 |
| :---: | :--- |
| **高** | 系統中斷對機關營運、資產或信譽產生**非常嚴重或災難性**影響 |
| **中** | 系統中斷對機關營運、資產或信譽產生**嚴重**影響 |
| **普** | 系統中斷對機關營運、資產或信譽產生**有限**影響 |
### 2.4 法律遵循性（違反資安相關法令）
| 等級 | 判定條件 | 法律責任 |
| :---: | :--- | :--- |
| **高** | 未遵循法令導致資安事件，影響他人權益或機關公正性 | **刑事責任** |
| **中** | 未遵循法令導致資安事件，影響他人權益或機關公正性 | **行政罰、懲戒或懲處** |
| **普** | 其他於法令有相關規範之情形 | 一般規範 |
---
## 三、構面差異速記
| 構面 | 事件類型 | 關鍵動詞 |
| :--- | :--- | :--- |
| **機密性** | 未經授權之資訊**揭露** | 洩漏、外流 |
| **完整性** | 資訊**錯誤**或遭**竄改** | 修改、破壞 |
| **可用性** | 存取或使用之**中斷** | 停擺、無法使用 |
| **法律遵循性** | 未遵循**法令** | 違法、受罰 |
---
## 四、法律遵循性責任等級速記
| 等級 | 責任類型 | 記憶口訣 |
| :---: | :--- | :--- |
| **高** | 刑事責任 | 高→**刑**（坐牢） |
| **中** | 行政罰、懲戒、懲處 | 中→**罰**（罰錢、記過） |
| **普** | 一般法令規範 | 普→**規**（有規定而已） |
---
## 五、考試情境題判斷
### 範例 1
> 某系統資料外洩，對機關信譽產生「嚴重」影響
**答案**：機密性 → **中**
### 範例 2
> 系統遭駭導致資料被竄改，造成「災難性」影響
**答案**：完整性 → **高**
### 範例 3
> 違反資安法令，機關人員需負刑事責任
**答案**：法律遵循性 → **高**
### 範例 4
> 某系統有以下評估結果：
> - 機密性：普
> - 完整性：中
> - 可用性：普
> - 法律遵循性：普
**答案**：系統防護需求等級 → **中**（取最高者）
---
## 考試重點速記
| 記憶點 | 內容 |
| :--- | :--- |
| **等級判定** | 四構面取**最高者** |
| **高級關鍵字** | 災難性、刑事責任 |
| **中級關鍵字** | 嚴重、行政罰或懲戒 |
| **普級關鍵字** | 有限、一般規範 |
| **CIA 對應** | 機密=揭露、完整=竄改、可用=中斷 |
---
# 附表十 資通系統防護基準（114年修正）
## 一、存取控制
### 1.1 帳號管理
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 1. 建立帳號管理機制（申請、建立、修改、啟用、停用、刪除）<br>2. 逾期臨時及緊急帳號應刪除或禁用<br>3. 閒置帳號應禁用<br>4. 定期審核帳號 |
| **中** | 1. 定義各系統閒置時間或可使用期限<br>2. 逾時應自動登出<br>3. 含「普」所有措施 |
| **高** | 1. 依機關規定條件使用資通系統<br>2. 監控帳號，異常時回報管理者<br>3. 含「中」所有措施 |
### 1.2 最小權限
| 等級 | 控制措施 |
| :---: | :--- |
| **普/中/高** | 採最小權限原則，僅允許完成指派任務所需之授權存取 |
### 1.3 遠端存取
| 等級 | 控制措施 |
| :---: | :--- |
| **普/中/高** | 1. 先取得授權，建立使用限制、組態需求、連線需求及文件化<br>2. 權限檢查應於**伺服器端**完成<br>3. 監控遠端存取內部網段或後臺連線<br>4. 採用**加密機制**<br>5. 來源應為預先定義之存取控制點 |
---
## 二、事件日誌與可歸責性
### 2.1 記錄事件
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 1. 訂定日誌記錄週期及留存政策，保留**至少 6 個月**<br>2. 確保系統有記錄特定事件功能<br>3. 記錄管理者帳號執行之各項功能 |
| **中/高** | 1. 定期審查日誌<br>2. 含「普」所有措施 |
### 2.2 日誌紀錄內容
| 等級 | 控制措施 |
| :---: | :--- |
| **普/中/高** | 應包含：**事件類型、發生時間、發生位置、使用者身分識別**<br>採單一日誌機制，確保格式一致性 |
### 2.3 日誌儲存容量
| 等級 | 控制措施 |
| :---: | :--- |
| **普/中/高** | 依儲存需求配置所需容量 |
### 2.4 日誌處理失效之回應
| 等級 | 控制措施 |
| :---: | :--- |
| **普/中** | 日誌處理失效時，應採取適當行動 |
| **高** | 需即時通報之失效事件，應於規定時效內對特定人員提出警告 |
### 2.5 時戳及校時
| 等級 | 控制措施 |
| :---: | :--- |
| **普/中/高** | 1. 使用內部時鐘產生時戳，對應 **UTC 或 GMT**<br>2. 內部時鐘應定期與基準時間源同步 |
### 2.6 日誌資訊之保護
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 日誌存取僅限有權限之使用者 |
| **中** | 運用**雜湊**或其他完整性確保機制 |
| **高** | 定期備份日誌至**原系統外**之其他實體系統 |
---
## 三、營運持續計畫
### 3.1 資料備份
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 1. 訂定資料可容忍損失之時間要求（**RPO**）<br>2. 執行資料備份 |
| **中** | 定期測試備份資料，驗證媒體可靠性及資訊完整性 |
| **高** | 1. 備份還原作為營運持續計畫演練一部分<br>2. 建立**異地備份**機制 |
### 3.2 系統備援
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 訂定系統中斷後重新恢復服務之最大可容忍中斷時間（**RTO**） |
| **中** | 定期測試於 RTO 內由備援設備取代並提供服務 |
| **高** | 備援啟動作為營運持續計畫演練一部分 |
---
## 四、識別與鑑別
### 4.1 使用者之識別與鑑別
| 等級 | 控制措施 |
| :---: | :--- |
| **普/中** | 識別及鑑別使用者，**禁止使用共用帳號** |
| **高** | 採取**多因子鑑別**技術 |
### 4.2 身分驗證管理
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 1. 預設密碼初次登入後應**立即變更**<br>2. 身分驗證資訊**不以明文傳輸**<br>3. 帳戶鎖定：失敗 **5 次**後，**15 分鐘**內不允許登入<br>4. 強制最低密碼複雜度，依效期變更<br>5. 密碼不可與**前 3 次**相同<br>6. 外部使用者得自行規範 |
| **中/高** | 1. 防範自動化程式登入或密碼更換嘗試<br>2. 密碼重設需重新身分確認，發送**一次性及具時效性**符記 |
### 4.3 鑑別資訊保護
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 遮蔽鑑別過程中之資訊 |
| **中/高** | 密碼應經**雜湊**或其他適當方式處理後儲存 |
---
## 五、系統與服務獲得
### 5.1 系統發展生命週期（SSDLC）
| 階段 | 高 | 中 | 普 |
| :--- | :--- | :--- | :--- |
| **需求階段** | 確認系統安全需求（機密性、可用性、完整性） | ← 同左 | ← 同左 |
| **設計階段** | 1. 識別威脅，進行風險分析評估<br>2. 回饋需求階段，提出安全需求修正 | ← 同左 | 無要求 |
| **開發階段** | 1. 執行**源碼掃描**<br>2. 嚴重錯誤通知機制<br>3. 含中/普措施 | 1. 針對安全需求實作控制措施<br>2. 避免軟體常見漏洞<br>3. 錯誤頁面僅顯示簡短訊息及代碼 | ← 同左 |
| **測試階段** | 執行**滲透測試** | 執行**弱點掃描** | ← 同左 |
| **部署與維運** | 1. 版本控制與變更管理<br>2. 含普級措施 | ← 同左 | 1. 更新與修補<br>2. 關閉不必要服務及埠口<br>3. 不使用預設密碼<br>4. 源碼備份 |
| **委外階段** | 將各階段安全需求納入委外契約 | ← 同左 | ← 同左 |
### 5.2 獲得程序
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 識別第三方軟體、服務、函式庫或其他元件 |
| **中/高** | 開發、測試及正式作業環境應**區隔** |
### 5.3 系統文件
| 等級 | 控制措施 |
| :---: | :--- |
| **普/中/高** | 應儲存與管理系統發展生命週期之相關文件 |
---
## 六、系統與通訊保護
### 6.1 傳輸之機密性與完整性
| 等級 | 控制措施 |
| :---: | :--- |
| **普/中** | 無要求 |
| **高** | 1. 採用加密機制防止未授權揭露或偵測變更<br>2. 使用**公開、國際機構驗證且未遭破解**之演算法<br>3. 金鑰或憑證**定期更換**<br>4. 伺服器端金鑰保管應訂定管理規範 |
### 6.2 資料儲存之安全
| 等級 | 控制措施 |
| :---: | :--- |
| **普/中** | 無要求 |
| **高** | 重要組態設定檔案及具保護需求資訊應**加密**或適當方式儲存 |
---
## 七、系統與資訊完整性
### 7.1 漏洞修復
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 漏洞修復應測試有效性及潛在影響，並定期更新 |
| **中/高** | 定期確認漏洞修復狀態 |
### 7.2 資通系統監控
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 發現被入侵跡象時，應**通報機關特定人員** |
| **中** | 監控系統以偵測攻擊與未授權連線，識別未授權使用 |
| **高** | 採用**自動化工具**監控進出通信流量，發現異常時進行分析 |
### 7.3 軟體及資訊完整性
| 等級 | 控制措施 |
| :---: | :--- |
| **普** | 使用者輸入資料合法性檢查應置於**伺服器端** |
| **中** | 1. 使用完整性驗證工具偵測未授權變更<br>2. 違反完整性時實施安全保護措施 |
| **高** | 定期執行軟體與資訊完整性檢查 |
---
## 考試重點速記
| 關鍵數字 | 內容 |
| :--- | :--- |
| **6 個月** | 日誌保留最少期限 |
| **5 次** | 帳戶鎖定之登入失敗次數 |
| **15 分鐘** | 帳戶鎖定時間 |
| **前 3 次** | 密碼不可重複使用次數 |
| 等級專屬 | 高 | 中 | 普 |
| :--- | :---: | :---: | :---: |
| 多因子鑑別 | ✓ | － | － |
| 源碼掃描 | ✓ | － | － |
| 滲透測試 | ✓ | － | － |
| 弱點掃描 | ✓ | ✓ | － |
| 異地備份 | ✓ | － | － |
| 傳輸加密 | ✓ | － | － |
| 自動化監控 | ✓ | － | － |
---
Sign in via Facebook
Sign in via X(Twitter)
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
Connect another wallet