# 資安職能訓練證書-資通安全概論
> 📚 **參考資料**
> - [資通安全概論_新版教材_11501_v4.pdf](https://ctts.nics.nat.gov.tw/DownloadDetail/70) — 數位發展部資通安全署
> - [資通安全概論新版教材_自我評量測驗v2.pdf](https://ctts.nics.nat.gov.tw/DownloadDetail/70) — 數位發展部資通安全署
---
# 前言：為什麼要考這張證書？
> 💡 **不是個人進修、不是履歷加分，是法定配置要求**。對公務機關及特定非公務機關而言，持有資安職能證書是《**資通安全責任等級分級辦法**》明文規定的人員配置門檻——機關沒達標，資安等級稽核就會出狀況。
**法源依據**
依《資通安全管理法》第 7 條第 3 項授權訂定的《**資通安全責任等級分級辦法**》。該辦法第 11 條規定各機關應依資安責任等級辦理附表一至附表八所定事項——其中**資安專職（責）人員的配置數量與所持證照和證書要求**，就是最核心的強制條件。
**人員配置與證照和證書要求**
| 等級 | 資安專職（責）人員 | 公務機關要求 | 特定非公務機關要求 |
| :---: | :---: | :--- | :--- |
| **A 級** | **4 人**以上 | 證照**及**證書各 1 張以上 | 證照**或**證書 1 張以上 |
| **B 級** | **2 人**以上 | 證照**及**證書各 1 張以上 | 證照**或**證書 1 張以上 |
| **C 級** | **1 人**以上 | 證照**及**證書各 1 張以上 | 證照**或**證書 1 張以上 |
> 📌 **法規用字陷阱：一字之差，意思完全不同**
>
> 《資通安全管理法》及其子法有許多關鍵字，字面只差一個字，法律效果完全不同。幾個本科會遇到的例子：
>
> | 用字對比 | 差異 | 本科實例 |
> | :--- | :--- | :--- |
> | **及** vs **或** | 並列（兩者都要） vs 擇一（一張即可） | 公務機關 證照**及**證書各 1 張 ／ 特定非公務機關 證照**或**證書 1 張 |
> | **應** vs **得** | 強制（必須做） vs 授權（可以做） | 機關**應**辦附表一至附表八所定事項（強制）；機關因技術限制**得**經核准免執行（授權，需申請）|
> | **通報** vs **報告** | 事件當下快速通知 vs 事後完整文件 | 事件發生起 **1 小時內通報**；事件處理完 **1 個月內**提交改善**報告** |
> | **以上** vs **超過** | 含本數 vs 不含本數 | A 級 **4 人以上**（含 4 人）；委外金額達 **1,000 萬以上**須第三方檢測 |
>
> 讀法條時把這些關鍵字**圈起來**再讀——法規遣詞都是精心設計的，一個字的差異就是一整套不同制度。
**證照 vs 證書：兩個詞不一樣**
很多人把「證照」和「證書」當成同義詞，但在這份法規裡它們**是兩個完全不同的東西**，搞錯會直接影響合規判斷：
| 類型 | 資通安全**專業證照** | 資通安全**職能訓練及評量證書** |
| :--- | :--- | :--- |
| **俗稱** | 「證照」 | 「證書」 |
| **發證來源** | 國內外發證機構，經主管機關認可 | 數位發展部**資通安全署**（ACS，主管機關） |
| **代表範例** | CISSP、CISA、CISM、CCSP、CEH、iPAS 資訊安全工程師（中級）、ISO 27001、27701、22301 主導稽核員 等 | **本課程**：資通安全概論、網路架構與部署安全、通訊與網路安全、業務持續運作管理、資安稽核實務、系統與網站滲透測試 等 |
| **取得方式** | 通過該證照對應之國際或國內考試 | 參加資安職能訓練 3 日課程並通過評量（或 115 年起的**免訓評量**，詳下方「取證路徑」） |
| **官方清單** | 資安署公告之「**資通安全專業證照清單**」（定期更新） | 資安人才培訓服務網（ctts.nics.nat.gov.tw） |
> 💼 **實例：證書長這樣**（下圖為筆記作者的證書）
>
> 
>
> 從這張實體證書可以直接驗證上表說的幾件事：
>
> - **發證單位**：**數位發展部資通安全署**（Administration for Cyber Security, moda），由**署長蔡福隆**親筆簽發 ✅
> - **證書效期**：**3 年**（範例為 2025.07.23 至 2028.07.23 止，舊制）✅
> - **證書編號格式**：`IS-25-SQCCB012107006`（`IS` = Information Security、`25` = 發證年份 2025、後續為科目與流水編號）
**必須「維持有效性」**
法規不只要求「持有」，還強制要求「**持續維持有效性**」：
- **證照**：依各發證機構規則續證（例：CISSP 每 3 年需 120 CPE + 年費）
- **證書**：原效期 **3 年**；**115 年 4 月起新考取或換證取得之證書，效期延長為 5 年**。到期前 6 個月要考「**換證評量**」續證，或重新受訓 + 評量（詳下方「取證路徑」區段）
**學習路徑強制規定：為什麼要先考「資通安全概論」**
依「資安職能訓練發展藍圖」學習路徑（**核心 → 專業**），**必須先取得「資通安全概論」證書**，才能報名其他專業科目（網路架構與部署安全、通訊與網路安全、業務持續運作管理、資安稽核實務、政府資訊作業委外安全管理、資通系統風險管理、系統與網站滲透測試、Web 應用程式安全、資安事件通報與應變等）。
> 📊 圖：資安職能訓練發展藍圖（資料來源：[數位發展部資通安全署](https://moda.gov.tw/ACS/operations/training/654)）
> 💡 **這就是為什麼這張叫「核心」科目**——它是整個資安職能訓練系列的**入門磚**。沒有它，後面任何專業科目都無法報名；反過來說，拿到這張後，後續進階路徑就全部打開了。
> 📌 **附錄詳表**：各等級完整應辦事項（人員訓練時數、第三方驗證、內部稽核次數、成熟度評估等），詳見本筆記末尾「**附錄一：資通安全責任等級應辦事項總表**」。
> 💬 **順帶一提：考多張有用嗎？** 法規上**專職人員 1 張就夠**，多考不會讓機關合規加分。唯一需要 2 張以上的情境是「**政府資安人力職能轉換訓練計畫**」——給非資訊職系、想轉任資訊處理職系的公務員走的補助計畫，需 2 張以上資安職能訓練證書才能拿到完整補助。其餘多考的動機通常是個人因素（補年度訓練時數、機關預算送訓等）。
> 💬 **志祥的話：為什麼要先搞清楚「為什麼考這張」？**
>
> 不知道大家有沒有看過電影《MIB 星際戰警》，片頭主角面試的橋段——一群軍中精英整齊劃一、不問原因照做；**只有主角（一個警察）舉手問：「為什麼我們要做這件事情？」**
>
> 其他人以為那是「不夠精銳」——但主角後來被錄取，**因為只有他問「為什麼」**。
>
> 同樣的道理——**政府叫你考這張證書，叫你做資安，你不能只是照做**。你得先搞清楚：
> - **這張證書的法源在哪？**（資通安全責任等級分級辦法）
> - **為什麼要分 A~E 級？**（資源有限、要抓重點）
> - **為什麼要 1 小時內通報？**（協防其他機關、避免整個產業被同一波攻擊）
>
> 搞懂「**為什麼**」，筆記不用背也會記得；只搞「**是什麼**」，你背了考完就忘。
>
> 這也是為什麼我這份筆記會花時間解釋背景脈絡，而不是只列法條——**沒有脈絡的條文是用完即丟的**。
---
## 課程大綱與學習目標
> 📋 **課程資訊來源**：數位發展部資通安全署《資安職能訓練課程簡介——資通安全概論》（113 年 5 月版本）
**課程基本資訊**
| 項目 | 內容 |
| :--- | :--- |
| **課程名稱** | 資通安全概論 |
| **課程時間** | 3 日（共 18 小時） |
| **授課對象** | 資訊人員、資通安全人員 |
| **先備知識** | 具備電腦與網路基本概念 |
**課程簡介**
介紹資通安全**策略面、管理面及技術面**之資通安全議題與防護措施。內容涵蓋：資通安全基本觀念、資通安全相關法規、資通安全風險管理與業務持續運作管理、作業安全、資訊委外安全、存取控制與加解密技術、網路安全與實體安全、應用程式安全、資安健診、資通安全事件通報及應變等。
**課程目標**
幫助學員建立資通安全領域基礎背景，使其能具備職務上所需要之資通安全知識與技能，同時為其他資通安全相關教育訓練課程建立**先備知識**。
---
**知識（K）指標**
| 代號 | 知識內容 |
| :---: | :--- |
| **K1** | 了解資通安全基本觀念與資通安全相關法規 |
| **K2** | 了解資通安全風險管理與業務持續運作管理 |
| **K3** | 了解日常作業中安全維護之工作與責任 |
| **K4** | 了解身分鑑別與存取控制方法 |
| **K5** | 了解加解密與數位簽章之概念與應用 |
| **K6** | 了解網路安全與實體安全防護方法 |
| **K7** | 了解應用程式開發生命週期安全 |
| **K8** | 了解資通安全健診流程 |
| **K9** | 了解資通安全事件通報及應變流程 |
**技能（S）指標**
| 代號 | 技能內容 |
| :---: | :--- |
| **S1** | 具備規劃機關資通安全管理制度能力 |
| **S2** | 具備日常作業中安全維護之處理能力 |
| **S3** | 具備身分鑑別與存取控制方法運用能力 |
| **S4** | 具備資料加解密與數位簽章運用能力 |
| **S5** | 具備應用程式變更安全控管能力 |
| **S6** | 具備資通安全健診規劃能力 |
| **S7** | 具備資通安全事件通報及應變能力 |
---
**單元大綱與 K/S 指標對應**
| 單元 | 主題 | 對應指標 |
| :---: | :--- | :--- |
| 第 1 單元 | 資通安全基本觀念 | K1、S1 |
| 第 2 單元 | 資通安全相關法規 | K1、S1 |
| 第 3 單元 | 資通安全風險管理與業務持續運作管理 | K2、S2 |
| 第 4 單元 | 作業安全 | K3、S2 |
| 第 5 單元 | 資訊委外安全 | K2、S2 |
| 第 6 單元 | 存取控制與加解密技術 | K4、K5、S3、S4 |
| 第 7 單元 | 網路安全與實體安全 | K6、S2 |
| 第 8 單元 | 應用程式安全 | K7、S5 |
| 第 9 單元 | 資通安全健診 | K8、S6 |
| 第 10 單元 | 資通安全事件通報及應變 | K9、S7 |
> 💡 **給同學的提醒**：官方課程大綱為 **10 單元**，本份筆記依據《資通安全概論_新版教材_11501_v4》之章節編排整理為 **9 章**，兩者涵蓋範圍一致，僅章節切分方式略有差異。各章重點對照請參閱下方「導讀」。
---
**測驗方式與成績核給**
| 項目 | 內容 |
| :--- | :--- |
| **題型配分** | 單選題 **40 題** + 複選題 **10 題**，每題 **2 分**（總分 100 分） |
| **測驗時間** | **75 分鐘** |
| **及格標準** | **70 分** |
| **成績核給類別** | 首測、複測、免訓評量 |
> ⚠️ **複選題計分規則（務必先搞清楚）**：複選題**必須所有選項都選對才給分**——**選錯、漏選、多選皆以 0 分計**，**沒有部分給分**。
**💡 作答策略建議**
複選題出題方式通常是把課本某段條列內容**打亂成排列組合**（例如「下列哪些屬於 XX 措施的子項目」、或抓 A、B、C、D 四個選項要你全部挑對），出題者從教材原文抓一串條列後重新組合，要全部命中難度不低。因此建議的作答策略：
1. **主攻單選題**：40 題 × 2 分 = **80 分**，這裡是分數的主戰場。單選題以常識判斷與背誦型題目為主，把課本讀熟、觀念釐清就能穩拿分數。
2. **複選題盡力而為**：10 題 × 2 分 = **20 分**，盡力做但不要卡太久。由於全對才給分的規則，複選題的「期望得分」天生偏低。
3. **時間分配**：75 分鐘 ÷ 50 題 ≈ 每題 **1.5 分鐘**。單選題若能在 1 分鐘內完成，可留更多時間給複選題推敲組合。
4. **70 分通過路線**：只要單選題拿到 **35 題正確（= 70 分）** 就已達及格，複選題全部視為加分即可。
> 📌 **核心觀念**：不用追求滿分，**穩穩拿到及格分數**才是最實際的目標——這也是資安證照與職能評量普遍適用的「**70 分通過策略**」。
> 💬 **志祥的話：考場心理戰——30 分那個魔鬼時間點**
>
> 這個考試**考滿 30 分鐘就可以交卷**。這個規則聽起來沒什麼，但實際在考場會出現一個**很影響心態的時刻**：
>
> **30 分鐘一到，會突然有一票人交卷走出考場**——這時候你正在寫題、正在掙扎某一題選 B 還是 C，你會忍不住想：「**天啊他們都寫完了，我是不是太慢？**」然後開始心慌意亂、匆忙亂選、原本會的題目也做錯。
>
> **關鍵是要知道**：**30 分鐘交卷的人有兩種極端**——
> 1. **超會的**：30 分鐘寫完直接滿分交卷走人
> 2. **超不會的**：寫不出來、直接放棄猜答案交卷
>
> **你沒辦法從外表判斷他們是哪一種**。看到人家走了就心慌，是最吃虧的反應。
>
> **建議作法**：
> - 30 分鐘的時間點**強制暫停 30 秒**，把手從滑鼠/鍵盤上移開、閉眼深呼吸幾下、鬆開肩膀
> - 告訴自己「**他們走他們的、我寫我的**」—— 反正重考也是他們重考，不是你
> - **穩穩寫到 60~70 分鐘**再檢查——有把握之後才交卷
> - 除非你是真的確定全部都對，不然**不要跟風交卷**
>
> **保持心情平穩** > **寫得比別人快**。這場考試又不是比速度，是比**有沒有及格**。
---
## 取證路徑：受訓評量 vs 免訓評量
115 年 4 月起新增「**免訓評量**」路徑——不用再經過 3 日訓練課程，自行研讀教材、直接報考評量。兩種路徑比較：
| 項目 | 受訓評量（傳統） | 免訓評量（115 新制） |
| :--- | :--- | :--- |
| **適用** | 希望系統性學習者 | 已有資安背景、願意自學者 |
| **費用** | 約 8,000 元（含 1 次評量） | 首測免費、複測每次 300 元 |
| **時間彈性** | 須配合開班 | **每月有申請/評量梯次**，不用等開課（115 年報名期為每月 18 日～次月 17 日，詳見[官網公告](https://ctts.nics.nat.gov.tw/NewsDetail/271)）|
> 📌 已有 CISSP、iPAS 資訊安全工程師（中級）等證照的資安老手，走**免訓評量**最划算。
**⚠️ 不要混淆「免訓評量」與「換證評量」**
| 機制 | 對象 | 題數 | 用途 |
| :--- | :--- | :---: | :--- |
| **免訓評量** | 尚未持有證書者 | 50 題 | 新取得證書的捷徑 |
| **換證評量** | 持證者，即將到期 | **20 題** | 效期前 6 個月報考續證 |
> 📎 詳細申請時程、流程與限制請參考 [資安人才培訓服務網](https://ctts.nics.nat.gov.tw/) 公告，或撥打資安署專線（02）2380-8500。
---
# 導讀：這本教材在講什麼？
這門課共 9 個單元，目的是讓公務機關人員搞懂「資安這件事從頭到尾該怎麼做」。整體結構可以拆成四大塊來理解：
---
## 一、先搞懂「保護什麼」和「依據什麼」（第 1～2 章）
| 單元 | 核心問題 | 重點 |
| :--- | :--- | :--- |
| **第 1 章：資通安全基本觀念** | 我們在保護什麼？目標是什麼？ | 保護對象是「資通系統」與「資通服務」，防護目標是 CIA（機密性、完整性、可用性）加上法律遵循性 |
| **第 2 章：資通安全相關法規** | 誰叫我做的？做到什麼程度？ | 資安法、個資法、國家機密保護法構成法律框架；責任等級分級辦法決定你的機關該做多少事 |
> 💡 **閱讀邏輯**：第 1 章建立「為什麼要做」的意識，第 2 章告訴你「法律要求你做什麼」。這兩章是後面所有內容的基礎，不懂這裡，後面的具體要求會看不懂為什麼要那樣規定。
---
## 二、用管理的方法做資安（第 3～4 章）
| 單元 | 核心問題 | 重點 |
| :--- | :--- | :--- |
| **第 3 章：資通安全風險管理** | 風險那麼多，怎麼決定先處理哪個？ | 透過風險評鑑（高階或詳細）識別威脅與弱點，再決定修改、避免、分擔或留存 |
| **第 4 章：管理面暨認知與訓練應辦事項** | 管理制度具體要做哪些事？ | ISMS 導入、稽核、業務持續運作（BCP/RTO/RPO）、人員教育訓練時數要求 |
> 💡 **閱讀邏輯**：第 3 章是方法論——教你**怎麼排風險優先順序**（資源有限，不可能全部處理）；第 4 章是 checklist——告訴你管理面「該交什麼作業」。
---
## 三、用技術的方法做資安（第 5～7 章）
| 單元 | 核心問題 | 重點 |
| :--- | :--- | :--- |
| **第 5 章：資通系統防護控制措施** | 系統本身該怎麼蓋才安全？ | 帳號管理、加密、日誌、備份、SSDLC——從系統設計到維運的防護基準（附表十） |
| **第 6 章：技術面應辦—防護及偵測** | 外面的攻擊怎麼擋？ | 防毒、防火牆、郵件過濾、APT 防禦、GCB 政府組態基準 |
| **第 7 章：技術面應辦—安全性檢測及健診** | 怎麼知道自己有沒有破洞？ | 弱點掃描、滲透測試、資安健診、雲端安全、實體安全 |
> 💡 **閱讀邏輯**：第 5 章是「蓋房子」（系統怎麼設計才安全），第 6 章是「裝監視器和門鎖」（日常防護與偵測），第 7 章是「請人來驗屋」（定期檢測找漏洞）。三章合起來就是技術面的完整生命週期。
---
## 四、兩個特殊情境（第 8～9 章）
| 單元 | 核心問題 | 重點 |
| :--- | :--- | :--- |
| **第 8 章：資訊委外安全管理** | 外包出去的事，資安誰負責？ | 委外生命週期（計畫→招標→履約→驗收→結案）各階段的資安要求，重點是「責任不能外包」 |
| **第 9 章：資通安全事件通報及應變** | 出事了怎麼辦？ | 事件分級（1～4 級）、1 小時內通報、封鎖→根除→復原→改善的處理流程、數位證據保全 |
> 💡 **閱讀邏輯**：第 8 章處理「別人幫你做事時的資安」，第 9 章處理「事情爆掉之後的 SOP」。這兩章是實務情境題的重點來源。
---
## 全書架構一覽
---
# 第一章：資通安全基本觀念
> **學習目標**
> 1. 了解資通系統的組成元素（定義與構成要素）。
> 2. 建立對資通安全威脅的危機意識。
> 3. 掌握資通安全的核心防護目標 (CIA + L)。
---
## 1.1 資通系統之組成
在深入探討資安之前，必須先界定保護對象。依據《資通安全管理法》第 3 條第 1 款及第 2 款，核心保護對象為 **「資通系統」** 與 **「資通服務」**。
### 1.1.1 資通系統 vs 資通服務
| 比較項目 | 資通系統 | 資通服務 |
| :--- | :--- | :--- |
| **法條** | 第 3 條第 **1** 款 | 第 3 條第 **2** 款 |
| **法規定義** | 用以蒐集、控制、傳輸、儲存、流通、刪除資訊或對資訊為其他處理、使用或分享之**系統** | 與資訊之蒐集、控制、傳輸、儲存、流通、刪除、其他處理、使用或分享**相關之服務** |
| **白話理解** | 涉及資訊處理的**軟硬體與網路環境總稱**，涵蓋資訊從產生到銷毀的整個生命週期 | **圍繞在資通系統周邊**的支援性活動，非系統本體但確保系統持續可用 |
| **本質** | 運作的**主體** | 確保主體可用的**支援環節** |
| **實例** | 考選部全球資訊網（流通）、eCPA 人事服務網及公文系統（蒐集、儲存、處理）、差勤系統（管理流程） | 個人電腦維護服務（終端可用性）、伺服器維護服務（機房核心系統連續與穩定） |
> 💡 **為什麼這兩個要分清楚？**
>
> 《資通安全管理法》第 1 條的立法目的就是保護**這兩樣東西**——分不清就不知道保護對象是誰，後面的分級、應辦事項、防護基準全部對不上。
>
> **教材定義：**
> - **資通系統**：所有涉及資訊處理的軟硬體與網路環境總稱（**系統本體 / 資產**）
> - **資通服務**：圍繞在資通系統周邊、與資訊處理相關的支援性活動（**服務提供 / 委外活動**）
>
> 📎 **官方 FAQ 8.3**：「**PC 維護屬資通服務之一種**」——只要是與資訊處理相關的服務（含委外維護、雲端代管、SOC 監控等），都算資通服務。
>
> **為什麼法規要分兩條線管？**
> - **資通系統**這條線管「**我要保護什麼**」——施行細則第 9 條要求盤點、第 10 條定義核心資通系統、分級辦法要求依等級套防護基準
> - **資通服務**這條線管「**誰在幫我做、我要怎麼管他**」——資安法第 9 條要求委外時選任適當受託者、簽書面契約、監督實施
>
> **常見狀況：同一件事往往兩面都要管**。例如機關租用**雲端公文平台**——從資產角度要做**資通系統**的分級（可能被列為核心資通系統）、從委外角度要做**資通服務**的供應商管理（簽契約、稽核廠商）。漏掉任一面都是破口。
### 1.1.2 五大關鍵要素
從實務角度，資通系統由五個關鍵要素構成，均為資安保護的對象：
| 要素 | 說明 | 考試提示 |
| :--- | :--- | :--- |
| **① 資訊與資料** | 最核心的保護對象：文件、資料庫、個資、業務數據 | CIA 保護的**首要目標** |
| **② 軟體** | 應用程式、作業系統、資料庫管理系統 | 保護完整性與可用性 |
| **③ 硬體** | 電腦、伺服器、網路設備、儲存裝置 | 需實體與邏輯雙重保護 |
| **④ 網路** | 路由器、交換器、防火牆、傳輸線路 | 資訊傳輸管道，防監聽與阻斷 |
| **⑤ 人員** | 使用者、管理者、開發人員、維護人員 | **最常被忽略但至關重要**，多數事件源於人為疏失或社交工程（如：誤點釣魚郵件導致憑證外洩） |
> 💬 **志祥的話：人員為什麼是五大要素中最難處理的？**
>
> 資訊、軟體、硬體、網路——出事都能**用錢解決**：資料有備份就還原、軟體重裝就好、硬體再買一套、網路找其他廠商（Cisco、Juniper 都有）。**唯獨「人員」出問題很難補**。
>
> **單點故障（Single Point of Failure）——最常被忽略的人員風險**
>
> 組織裡常常有一種情況：**某個系統只有一個人會管、某個密碼只有一個人知道**。這個人一旦離職、生病、請長假——整個系統就癱了。這就是「**人員層面的單點故障**」。
>
> **真實案例：竹科停電 + 柴油發電機事件**
>
> 之前竹科停電，所有廠商都去採購**柴油發電機**應急——結果發現：
> 1. 大家**找的都是同一家發電機廠商**
> 2. 那家廠商**供油人力有限**
> 3. 竹科各大廠都要供油 → 廠商當然**先供應大客戶** → 小廠商就沒了
>
> **演練的時候一切順利，真實事件發生時卻卡住**——為什麼？因為演練時每個廠商獨立演，沒想到**真實情況是大家一起出事搶同一個資源**。
>
> **延伸思考**：做 BCP 備援演練時，如果一個人管 5 個系統，演練時看起來都還 OK（一次恢復一個）——但真實災難時 5 個系統同時壞，**他能同時做 5 件事嗎？**
>
> **實務啟示**：
> - 重要系統**至少要有 2 人會操作**（避免單點故障）
> - 重要密碼**要有備援機制**（例如存在保險箱、雙人保管）
> - BCP 演練要考慮 **同時多事件** 的情境，不能只演單一事件
### 1.1.3 資產分類 (CNS 27002：2023)
依據 CNS 27002：2023（對應 ISO/IEC 27002），對組織具備價值的任何事物皆視為**資產**，分為兩大類：
| 資產類型 | 內容 | 說明 |
| :--- | :--- | :--- |
| **主要資產** | 資訊（含資料）、營運過程與活動 | 受損將**直接**影響組織使命與目標 |
| **支援資產** | 硬體、軟體、網路、人員、**場域**（如機房、辦公地點）、**組織結構**（如部門、職責劃分） | 主要資產安全運行的**前提** |
---
## 1.2 建立資通安全之危機意識
### 1.2.1 資安威脅的潛在影響超乎想像
現今的資安威脅已非傳統單純的病毒感染，其規模與影響已達前所未有的程度。當關鍵資通系統遭受攻擊並停擺時，可能導致嚴重的連鎖反應：
| 影響層面 | 範例 |
| :--- | :--- |
| **公共服務** | 醫院系統癱瘓危及病患生命、政府服務停擺影響社會正常運轉 |
| **企業營運** | 生產停滯、供應鏈中斷、鉅額財務損失、市場競爭力下降、商譽受損 |
| **國家安全** | 關鍵基礎設施（電力、交通、通訊、金融）遭攻擊恐造成大規模社會混亂，甚至危及國家安全 |
### 1.2.2 資安攻擊無孔不入
隨著科技進步，網路攻擊途徑與手法日益多元與隱蔽：
| 威脅面向 | 說明 |
| :--- | :--- |
| **物聯網 (IoT)** | 裝置設計之初常未充分考慮資安，易成駭客入侵新入口。一個被入侵的智慧家電可能成為跳板，進而攻擊整個家庭網路 |
| **行動與無線通訊** | 便利但伴隨高風險：個資外洩、通訊監聽、生活品質受影響 |
> 💬 **志祥的話：IoT 的威脅為什麼比想像中嚴重？**
>
> 課本講 IoT 威脅很抽象，舉兩個實際新聞案例就懂了：
>
> **案例一：對岸製掃地機器人洩漏家中隱私**
>
> 2025 年 9 月陸委會示警（[自由時報報導](https://news.ltn.com.tw/news/politics/breakingnews/5197307)）：韓國消費者院針對 6 款掃地機器人做安全性調查，發現中國品牌**科沃斯（ECOVACS）、雲鯨（NARWAL）、追覓（Dreame）**存在重大資安風險——**驗證缺陷讓第三方可竊取照片與影像**，家裡幾個房間、家具擺設、甚至家人作息都被看光。買的人覺得只是掃地工具，結果**整個家被「裸奔」**。
>
> **案例二：IP 攝影機被駭變成 DDoS 殭屍網路跳板**
>
> 趨勢科技 2025 年 2 月報告：自 2024 年底以來持續追蹤一個 **Mirai 殭屍網路**變種，專門入侵**無線路由器與 IP 攝影機**發動 DDoS 攻擊，瞄準日本多家大型企業與銀行。這類攻擊手法很標準：**利用 IoT 裝置的預設密碼或未修補漏洞感染** → 裝置變成「肉雞」 → 駭客命令它們同時對目標網站發動洪水攻擊。
>
> 很多人會覺得：「**我家的 IP 攝影機被入侵就被入侵了啊，我還是看得到監視畫面無所謂**。」
>
> **但重點是**：假設警方查 DDoS 攻擊來源，追到 IP 來自**你家設備**——你要負責。你還得**自己證明不是你做的**。這跟「阿伯從巷子鑽出來撞到車，你還要證明不是你撞他」是同樣邏輯——**法律上你要先自證清白**。
>
> **啟示**：IoT 設備已經是駭客的「入場券」——不是「會不會被入侵」而是「什麼時候被入侵」。政府把**危害國家資通安全產品審查辦法**拉到資安法位階，就是怕這類產品變成國安漏洞。
### 1.2.3 資安是每個人的責任
資通安全絕非僅是資安專業人員的責任——在網路戰與資訊戰日益頻繁的當代，資安問題已上升到國家安全層次。資安素養是現代公民的基本素養，如同識字一樣重要，看似微小的個人日常行為累積起來就是整體資安防線的組成部分，應落實於日常行為：
- 辨識釣魚郵件
- 使用強密碼
- 不隨意點擊不明連結
- 定期更新系統與應用程式
- 定期備份資料
---
## 1.3 資通安全之防護目標 (CIA + L)
依據《資通安全管理法》第 3 條第 3 款，資通安全係指：
> 防止資通系統或資訊遭受未經授權之存取、使用、控制、洩漏、破壞、竄改、銷毀或其他侵害，以確保其**機密性、完整性及可用性**。
資安的核心防護目標為 **CIA 三原則**，加上公務機關與特定非公務機關須遵循的**法律遵循性 (L)**。
> 💬 **志祥的話：CIA ≠ 中情局，以及怎麼記 CIA**
>
> 講個小笑話——**在 AI 還不發達的年代**，很多資安書是英文翻譯過來的，Google 翻譯把 **CIA 翻成「中情局」**——所以有些早期中文資安書寫到：「為了保護系統的**中情局**，我們應該...」讀者看得一頭霧水。這是資安界的經典笑話。
>
> **考試記憶技巧**：
>
> 不要去死背定義（每本書的定義還會不太一樣、學術論文有更嚴謹版本但你根本用不上），**用「能不能自圓其說」的口語記憶**就夠了：
>
> | 防護目標 | 白話版（考試能用） |
> | :--- | :--- |
> | **機密性** | 不是那個人的不能看 |
> | **完整性** | 不是那個人的不能改（改了還要看得出被改） |
> | **可用性** | 想用的時候隨時能用 |
>
> 任何資安考試，**不會寫的題目先從 CIA 角度去想就對了**——大部分資安題目都可以套回 CIA 其中一個。
### 1.3.1 機密性 (Confidentiality)
* **定義**：確保資訊不被未經授權的人員或系統存取。敏感資訊只能經由授權之人員或系統存取。
* **目標**：防止非授權人員存取資訊，確保資訊的秘密性與隱私。
* **威脅型態**：資料外洩、竊聽、未授權揭露。
* **防護措施**：資料加解密、存取控制、資料遮罩、去識別化。
> 💼 **教材案例**：某機關委外辦理推廣活動，廠商直播時不慎透漏抽獎網址，導致中獎人個資（姓名、手機）外洩。這直接影響了個資的**機密性**。
> ➡ **建議防範**：直播活動預先演練，確認內容無不當揭露；機關辦理對外活動或公告時，應確認內容妥適性及資安管理措施；敏感資訊應進行去識別化處理，降低外洩風險。
>
> 🌐 **時事案例（2025）**：[美國防部長在 Signal 群聊中透露機密戰爭計劃](https://cn.nytimes.com/usa/20250325/hegseth-classified-war-plans-group-chat/zh-hant/) — 川普政府國防部長 Hegseth 在 Signal 群組討論攻打葉門的作戰計畫（機種、飛彈類型、發射時間等機密細節），國安顧問 Waltz 誤將《大西洋月刊》總編加入群組，導致機密外洩給未授權人員。**Signal 本身有端對端加密、技術面安全，但人為疏失讓機密性全毀**——呼應「人員」是五大要素中最常被忽略的一環。
### 1.3.2 完整性 (Integrity)
* **定義**：確保資訊在生命週期中持續正確、具一致性且可被信任。防止未經授權的修改或破壞。
* **目標**：防止非授權人員竄改資訊，確保資訊的正確性、可靠性與未被更動。
* **威脅型態**：資料遭竄改（如「Buy 1 item → Buy 10,000 items」）、誤刪。
* **防護措施**：數位簽章、雜湊函數、資料驗證、版本控制、稽核追蹤。
> 💼 **教材案例**：某機關委請廠商進行個人電腦維護，駐點工程師因作業疏失輸入錯誤代碼，將機關內約 300 多台電腦的硬碟檔案刪除。這嚴重影響了資料的**完整性**。
> ➡ **建議防範**：定期備份重要資料以防範資料遺失；重大變更作業前應先小範圍測試再執行；建立多重審核機制確保操作正確性；高等級之資通系統，其備份資料應進行異地保存。
>
> 🌐 **時事案例（2025）**：[台新證券錯帳金額逾 17 億創台股黑紀錄](https://www.upmedia.mg/tw/focus/finance/256494) — 台新證券與新光證券合併當日因系統資料錯誤，導致下單金額計算錯誤達 **17 億新台幣**。系統本身正常運作（可用性 ✓），但資料**不正確**——金額全部算錯，證明可用性 ≠ 正確性，**完整性受損一樣造成重大損害**。
> 💬 **志祥的話：完整性 = 資料「對不對」，被動手腳你看得出來嗎？**
>
> 完整性最好懂的例子——**你的銀行存款原本有 2 筆，突然變成 1 筆**。是被駭客刪掉？還是系統 bug 誤刪？還是內部員工惡意操作？不管哪個，**結果都是資料不完整了**——這就是完整性受損。**注意：「誤刪」也算**，不一定要是惡意才算。
>
> **完整性的核心防護技術：雜湊（Hash）= 數位指紋**
>
> 課本講「雜湊函數、數位簽章」聽起來很玄，其實概念非常單純：
>
> - **雜湊** = 給一份資料**算一個獨一無二的「數位指紋」**
> - 資料只要被動**一個 bit**，指紋就會完全不同
> - 比對「存的時候」跟「取的時候」的指紋 → 一樣就沒被動，不一樣就有鬼
>
> **舉例**：一份合約存進硬碟前，算出指紋 `abc123`。過了一個月，再次取出這份合約、重新算指紋：
> - 如果還是 `abc123` → ✅ 沒被改過（完整性 OK）
> - 如果變成 `xyz789` → ⚠️ **有人動過手腳**
>
> **數位簽章 = 雜湊 + 公私鑰**——不僅確保資料沒被改，還能證明「**這份資料真的是我傳的、而且只有我能傳**」。
>
> 考試重點：**機密性 → 加密**、**完整性 → 雜湊**、存取控制三個都能做到。
### 1.3.3 可用性 (Availability)
* **定義**：確保資訊與資源在需要時，可被授權使用者存取與使用，且系統功能正常運作。
* **目標**：防止系統故障或人為惡意阻斷服務，確保資訊與資訊處理的可獲得性。
* **威脅型態**：系統故障、DDoS 攻擊、天災（如颱風造成電力中斷）。
* **防護措施**：系統備援、資料備份、負載平衡、容量規劃、系統監控、UPS 不斷電系統、災難復原計畫。
> 💼 **教材案例**：113 年 10 月底康芮颱風過境，影響部分地區電力設施，部分機關因電壓供電不穩，致空調設備或主機設備異常，進而影響系統服務。這導致了服務的**可用性**受損。
> ➡ **建議防範**：機房電力、空調及資通系統服務等皆需建置備援機制，避免因斷電或供電不穩造成服務中斷；規劃與辦理核心業務或重要資通系統之營運持續演練 (BCP)，並將電力異常納入演練情境，確保事件發生時可緊急切換。
>
> 🌐 **時事案例（2025）**：[彰基醫院遭駭客攻擊已修復 院外掛號系統短暫失靈](https://www.cna.com.tw/news/aloc/202503030073.aspx) — CrazyHunter 勒索病毒攻擊彰化基督教醫院，**掛號系統癱瘓、連帶影響民眾就診**。醫院屬關鍵民生設施，**可用性受損即直接影響病患權益**，呼應教材第 1.2.1 節「醫院系統癱瘓危及病患生命」。
### 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 | 備援、備份、負載平衡、容量規劃、**存取控制** |
> 📌 **考試重點**：**存取控制** 同時出現在機密性、完整性、可用性三個目標中，是**唯一橫跨 CIA 三面向的共通防護措施**。教材圖 5 以同心圓呈現此概念——最內層是「資訊」，外層分別為 CIA 三目標，「存取控制」在三個目標的周圍都有出現。
---
> 📝 **自我評量測驗**：請參閱 [自我評量題庫](https://hackmd.io/@hiiii/Hy0bFhHnWl#%E7%AC%AC-1-%E5%96%AE%E5%85%83%EF%BC%9A%E8%B3%87%E9%80%9A%E5%AE%89%E5%85%A8%E5%9F%BA%E6%9C%AC%E8%A7%80%E5%BF%B5)
---
> 💬 **志祥的話：CIA 怎麼分辨？看「題目句子的重點」**
>
> CIA 定義表面上很清楚，但考試很愛考**混合情境題**——單一事件往往同時涉及 C、I、A 三個面向，答題時常常覺得「好像都對」。關鍵是**讀題目時抓句子的重點**，而不是去想事件的每個環節。
>
> 以**勒索病毒**為例，同一個攻擊在不同題目會有不同答案：
>
> | 題目強調 | 答案 |
> | :--- | :---: |
> | 「檔案被**加密**無法還原」 | **完整性** |
> | 「導致網站**無法提供服務**」 | **可用性** |
> | 「駭客將竊取的資料**公開販售**」 | **機密性** |
>
> 解題訣竅：**看題幹的動詞和受詞**——
> - 題幹說「被竄改 / 被加密 / 被刪除」 → 完整性
> - 題幹說「無法存取 / 服務中斷 / 系統癱瘓」 → 可用性
> - 題幹說「被外洩 / 被販售 / 被未授權查看」 → 機密性
>
> 同一個事件可能涉及 CIA 多個面向，但**考題通常只凸顯其中一個角度**——跟著題幹走就對了。
>
> **經典範例**：電腦被植入後門程式——植入的瞬間先破壞**完整性**（系統被改）→ 後門將檔案外傳破壞**機密性** → 若順帶蠕蟲感染塞爆頻寬則破壞**可用性**。一次攻擊、三面俱失。考題問「主要破壞哪個面向」時，還是要跟著題幹強調的角度走。
# 第二章：資通安全相關法規
> **學習目標**
> 1. 了解我國資通安全管理體系的組織架構與主要角色。
> 2. 深入理解《資通安全管理法》及其六大子法的核心內容。
> 3. 認識其他與資通安全議題相關之重要法規（國家機密保護法、個資法、刑法）。
---
## 2.1 我國資通安全管理體系
我國資通安全管理體系是由多個部會協同合作、層級分明的結構，旨在統籌全國資通安全事務。
### 2.1.1 決策與協調層級：國家資通安全會報
「國家資通安全會報」是國家資安的**最高指導與協調單位**，負責制定國家資通安全政策的最終決策。
| 職位 | 擔任者 |
| :--- | :--- |
| **召集人** | 行政院**副院長**（課本寫法）；**114 年修法後**依資安法第 5 條明文為**院長或副院長** |
| **副召集人** | 行政院政務委員及指定相關部會首長 1 人 |
| **偕同副召集人** | 國家安全會議諮詢委員兼任 |
| **委員** | 行政院部會首長、直轄市政府副市長、國安局副局長、學者及專家 |
> 📌 **考試重點**：最高指導協調單位是「國家資通安全會報」（非數位發展部、非資安署）。召集人：**課本寫副院長**；**114 年修法後**依資安法第 5 條為**院長或副院長**。
### 2.1.2 國家資通安全會報下轄兩大體系
| 體系 | 主責機關 | 職能 |
| :--- | :--- | :--- |
| **網際防護體系** | **數位發展部** | 提升各機關及特定非公務機關資安防護能力。下轄關鍵資訊基礎設施安全管理組、產業發展組、資通安全防護組、法規及標準推動組、認知教育及人才培育組、外館網際防護組等 |
| **網路犯罪偵防體系** | **內政部與法務部** | 負責處理網路犯罪的偵查及防制。下轄防治網路犯罪組、資通訊環境及網路內容安全組 |
其他相關單位：
* **數位發展部**：會報幕僚單位，協助國安會報運作。
* **國家資通安全研究院**：負責資安技術研究與發展。
### 2.1.3 資通安全管理體系之金字塔層級架構
| 層級 | 機關 | 角色 |
| :--- | :--- | :--- |
| **第 1 層** | 行政院 | **決策機關**：資通安全政策的最終決策與指導 |
| **第 2 層** | 數位發展部 | **規劃機關**：制定相關政策及計畫 |
| **第 3 層**<br>（雙軌） | **① 資安專責機關**（數位發展部指定，即**資安署**） | **監管機關 + 部分規劃與執行**：監管**公務機關** |
| **第 3 層**<br>（雙軌） | **② 中央目的事業主管機關**（如金管會、NCC、衛福部等各部會） | **監管機關**：監管**特定非公務機關** |
| **第 4 層** | 公務機關、特定非公務機關 | **納管機關**：負責具體執行工作 |
> 📌 **考試重點：雙軌監管**
> - **公務機關** → 由**資安署**監管
> - **特定非公務機關**（關鍵基礎設施提供者、公營事業、特定財團法人等）→ 由**中央目的事業主管機關**監管（按業務屬性分屬不同部會：金融歸金管會、電信歸 NCC、醫療歸衛福部……）
### 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 提供者**適用之法規為先（就高原則）。
> 💬 **志祥的話：關鍵基礎設施 (CI) 有哪些？**
>
> 課本沒明列 CI 包含什麼，但**行政院國土安全政策會報**定義了**九大關鍵基礎設施**：
>
> | # | 九大 CI | 舉例 |
> | :---: | :--- | :--- |
> | 1 | **能源** | 電力、天然氣 |
> | 2 | **水資源** | 自來水、水庫 |
> | 3 | **資訊與通訊** | 電信業者、網路 ISP |
> | 4 | **交通** | 高鐵、台鐵、航空、高速公路 |
> | 5 | **金融** | 銀行、證券、保險 |
> | 6 | **緊急救援與醫院** | 消防、急救、醫院 |
> | 7 | **中央政府** | 行政院及所屬機關 |
> | 8 | **高科技園區** | 竹科、中科、南科 |
> | 9 | **糧食** | 糧食儲備、農產運銷 |
>
> **考試陷阱**：考題可能出「**下列何者不屬於關鍵基礎設施？**」——然後丟一個**百貨公司、便利商店**進來。答案：**不在**九大裡面。雖然百貨公司停擺也很麻煩，但它不是「國家安全層次」的設施。
### 2.2.2 114 年修正重點
| 章別 | 重要新增及修正 |
| :--- | :--- |
| **總則** | 新增「危害國家資通安全產品」定義；新增協助民間處理重大資安事件；行政院應定期召開國家資通安全會報 |
| **公務機關** | **禁用**危害國家資安產品（例外須經資安長核可並報主管機關核定）；新增適任性查核（未通過者不得辦理涉國密業務） |
| **特定非公務機關** | CI 提供者及其以外機構均須設**資安專職人員**；須設**資安長**；新增事件調查權；新增禁用危害國安產品 |
| **罰則** | 罰鍰上限提高：未通報→ 30 萬~**1,000 萬**；違反維護計畫等→ 10 萬~**500 萬**；拒絕調查→ 10 萬~100 萬 (新增) |
| **附則** | 新增：資安事件涉及**個資外洩**時，應另依《個資法》辦理 |
> 💬 **志祥的話：為什麼 114 修法要把「危害國家資通安全產品」提升到法律位階？**
>
> 原本《各機關對危害國家資通安全產品限制使用原則》只是**行政規則**，沒有法律強制力。但對岸產品的資安疑慮越來越嚴重，政府決定**提升到資安法本體**，授權主管機關直接禁止。
>
> **為什麼必要？看實際案例：**
> - **對岸掃地機器人**會把家中影像回傳中國伺服器
> - **電動車**——如果車輛軟體有後門，**哪天直接讓它在路上亂撞別人**怎麼辦？這不是科幻，是真實的資安戰略考量
> - **智慧牙刷、智慧音箱**——看似無害，都可能變成 DDoS 跳板或監聽設備
>
> **不只台灣這樣做——日本地方政府也禁採購對岸產品**（[Yahoo 新聞：最快 2027 夏季上路——日本禁止地方政府採購中國製設備](https://tw.news.yahoo.com/%E6%9C%80%E5%BF%AB2027%E5%A4%8F%E5%AD%A3%E4%B8%8A%E8%B7%AF-%E6%97%A5%E6%9C%AC%E7%A6%81%E6%AD%A2%E5%9C%B0%E6%96%B9%E6%94%BF%E5%BA%9C%E6%8E%A1%E8%B3%BC-%E4%B8%AD%E5%9C%8B%E8%A3%BD-%E8%A8%AD%E5%82%99-%E9%98%B2%E5%A0%B5%E8%B3%87%E5%AE%89%E6%BC%8F%E6%B4%9E-095000833.html)）：日本預計最快 2027 年夏季上路，禁止地方政府採購中國製資通訊設備。這是**全球性的趨勢**，不是台灣特例。
>
> **實務影響**：
> - 公務機關採購時要先查產品是否列入「危害國家資通安全產品清單」
> - 即使是雲端服務，也要確認後端運算、資料儲存位置**不在中國、香港、澳門**
> - 連委外廠商的分包團隊**不得有陸籍人士**參與
### 2.2.3 主要義務：事前、事中、事後
公務機關及特定非公務機關在資安管理上的義務貫穿事件全生命週期：
| 階段 | 共同義務 |
| :--- | :--- |
| **事前** | 訂定**資通安全維護計畫**；訂定**通報及應變機制** |
| **事中** | 接受資通安全**稽核**；提出資通安全維護計畫**實施情形**；發生事件時進行**通報及應變** |
| **事後** | 稽核後提出**改善報告**；事件通報後提出**調查、處理及改善報告** |
### 2.2.4 六大子法
> 📌 **六大子法學習地圖：哪些後面會詳細展開？**
>
> 本節是六大子法的**全貌總覽**，其中 3 個子法在後面章節會被**獨立展開**成完整章節：
>
> | 子法 | 本節份量 | 後續章節 |
> | :--- | :---: | :--- |
> | ① 施行細則 | 概要 | **第 8 章委外** 引用第 4、6 條具體規範 |
> | ② 責任等級分級辦法 | 概要 | **第 4 章管理面** + **第 5 章技術面** + **附錄一、二**（最重要） |
> | ③ 稽核辦法 | **完整** | 不再展開 |
> | ④ 事件通報及應變辦法 | 概要 | **第 9 章** 整章展開（通報時限、事件分級、演練要求） |
> | ⑤ 情資分享辦法 | **完整** | 不再展開 |
> | ⑥ 獎懲辦法 | **完整** | 不再展開 |
>
> 讀本節時心中有譜：**①②④ 後面會再深入**，**③⑤⑥ 本節就是重點**（要背熟）。
#### ① 資通安全管理法施行細則
補充母法執行細節，重點包括：
| 主題 | 內容 |
| :--- | :--- |
| **定義明確** | 界定「軍事及情報機關」、「核心業務」、「核心資通系統」 |
| **核心資通系統** | 支援核心業務持續運作必要之系統，或防護需求等級為**高**者 |
| **維護計畫** | 應包含 **13 項**：核心業務、資安政策目標、推動組織、人力經費、資安長配置、系統盤點、風險評估、防護控制措施、通報應變演練機制、情資評估、委外管理、考核機制、精進績效管理 |
| **委外管理** | 受託者需具完善資安措施或通過第三方驗證；涉及國密者需適任性查核；核心系統或金額達 **1,000 萬**者需安全性檢測 |
| **改善報告** | 應含缺失項目、原因、改善措施（管理、技術、人力、資源）、完成時程及追蹤方式 |
| **重大事件** | 第 3 級及第 4 級事件 |
#### ② 資通安全責任等級分級辦法
依此辦法，機關依業務性質與影響程度分為 **A/B/C/D/E 五級**，符合多個等級者取**最高**：
| 等級 | 定義簡述 | 關鍵判定條件 |
| :--- | :--- | :--- |
| **A 級** | 業務涉及**全國性**影響 | 國家機密、外交國防國土安全、全國性民眾服務或跨機關共用系統、全國性個資、全國性 CI、公立**醫學中心** |
| **B 級** | 業務涉及**區域性或地區性**影響 | 國家核心科技資訊、區域性民眾服務或共用系統、區域性個資、區域性 CI、中央二級機關共用系統、公立**區域及地區醫院** |
| **C 級** | **維運自行或委外開發之資通系統** | 具權限區分及管理功能之資通系統 |
| **D 級** | **自行辦理資通業務，無維運自開發系統** | 僅使用套裝軟體 |
| **E 級** | **無資通系統** | 基本認知宣導即可 |
* 各機關需**每 3 年** (114 年修法後) 核定或提交其資通安全責任等級，責任等級可依國家安全或其他影響考量進行調整
* 系統依 **CIA+L** 分為**高/中/普**三級，實施相應防護基準
* 📎 各等級應辦事項詳見本筆記末尾「附錄一：資通安全責任等級應辦事項總表」；系統防護基準詳見「附錄二：附表十」
#### ③ 特定非公務機關資通安全維護計畫實施情形稽核辦法
規範主管機關如何對特定非公務機關進行稽核：
| 流程 | 說明 |
| :--- | :--- |
| **擬定稽核計畫** | 主管機關每年依業務重要性、系統規模、事件頻率、歷史稽核結果等因素擇定對象 |
| **成立稽核小組** | **3 人以上**，須含政策、技術、管理、法律專業者，**公務機關代表不少於 1/4**，遵守利益衝突迴避及保密義務 |
| **通知受稽機關** | 稽核 **1 個月前**書面通知；受稽機關可於 5 日內申請調整日期（限 1 次） |
| **進行稽核** | 稽核前訪談 + 現場實地稽核；可要求說明、提供文件 |
| **交付稽核報告** | 稽核完成後 **1 個月內** |
| **提交改善報告** | 交付報告後 **1 個月內**，送交中央目的事業主管機關 |
#### ④ 資通安全事件通報及應變辦法
* **事件分級**：分為 **1 至 4 級**（4 級最嚴重）
* **通報時限**：知悉事件後 **1 小時內**完成通報
* **審核時限**：3/4 級事件，上級機關 **2 小時內**完成審核
* **損害控制**：1/2 級 **72 小時**內完成；3/4 級 **36 小時**內完成
* **演練要求**：社交工程每半年 1 次；通報應變、攻防及情境演練每年 1 次
> 💡 **選擇題判讀記憶圖**
>
> 
>
> 
> 💬 **志祥的話：為什麼政府要強制規定「1 小時內通報」？**
>
> 在通報辦法還沒有明文規範之前，**政府機關被攻擊了，很多不通報**——家醜不外揚，怕被記過、怕被媒體放大、怕長官難看。結果**行政院資通安全處首任處長簡宏偉**曾說過一段很經典的話：
>
> > 「政府機關一年通報的資安事件才幾百件，你相信嗎？**我才不信**。」
>
> 意思是——實際事件遠遠不只，只是被藏起來了。這就是為什麼後來修法要**強制規定通報時限**，而且把不通報寫進罰則（30 萬~1,000 萬罰鍰）。
>
> **為什麼政府這麼在乎通報？不是要抓你有沒有被駭，是要「協防」**
>
> 重點不是抓機關出糗——駭客**通常不會只打一家**，他們會用**相同的攻擊手法打整個產業**：
>
> - 先打 A 醫院 → 如果 A 醫院藏起來不通報 → B、C 醫院就不知道要防範
> - 先打 A 銀行 → 如果藏起來 → B、C 銀行被同一波攻擊就措手不及
>
> **只有每一家都通報，大家才能協防共生**。這呼應了⑤情資分享辦法的核心精神。
#### ⑤ 資通安全情資分享辦法
| 主題 | 內容 |
| :--- | :--- |
| **情資範圍** | 惡意偵察、安全漏洞、攻擊方法（安全控制措施失效方法）、惡意程式、事件損害、偵測預防措施及相關技術性資訊，共 **7 項** |
| **分享原則** | 各機關應適時與主管機關或中央目的事業主管機關分享；須辨識來源可靠性及時效性，分析威脅與弱點 |
| **限制** | 涉及**營業秘密**或依法應保密者**不得分享**（例外：公益、生命健康、當事人同意）；可部分分享 |
| **保護** | 規劃適當安全維護措施，避免情資、個資外洩或遭未授權存取或竄改 |
| **國際合作** | 主管機關應就情資分享事宜進行國際合作 |
| **整合分析** | 得依來源、日期、類別、威脅指標等進行關聯分析，並分享新型威脅情資 |
> 💬 **志祥的話：情資分享到底在分享什麼？馬偕 → 彰基 案例**
>
> 「情資分享」聽起來很抽象，用 2025 年 2 月馬偕醫院勒索軟體事件走一遍就懂了（[iThome 事件總整理](https://www.ithome.com.tw/news/167327)）：
>
> **事件經過**
>
> - **2025/2/9**：馬偕紀念醫院發現被 **CrazyHunter 勒索軟體**攻擊，500 多台電腦被加密
> - **2025/2/9 當天**：馬偕**通報衛福部 H-ISAC**（醫療資安資訊分享與分析中心）+ 向調查局報案
> - **2025/2/11**：H-ISAC 向全國各醫院**發布警訊**，公開了 **CrazyHunter 的惡意程式名稱、檔案 hash、攻擊手法**（AD 入侵、GPO 派送、BYOVD 提權）
> - **2025/3/1**：**彰化基督教醫院也被同一組 CrazyHunter 攻擊**——衛福部將事件定調為「**系統性攻擊**」
>
> **這個事件完美呈現了「情資分享」的兩層價值**：
>
> **第一層：法定通報管道 → 產業級協防**
>
> 馬偕不是自己去到處分享情資，而是透過 **H-ISAC 這個官方情資分享平台**：
> - 馬偕通報 H-ISAC → H-ISAC 整理後廣播給所有醫院 → 醫院拿 IOC（入侵指標）去掃自家系統
> - 這就是 **⑤情資分享辦法** 設計的運作方式：**不是各醫院私下交換，而是透過法定平台統一分發**
>
> **第二層：為什麼彰基還是被打了？**
>
> 雖然 H-ISAC 2/11 就發警訊了，但彰基 3/1 還是被同一組駭客打——這凸顯兩件事：
> 1. **情資分享不等於保證安全**：醫院還是要自己落實（部署 EDR、掃 IOC、加強 AD 防護）
> 2. **但有情資總比沒情資好**：彰基之所以能快速確認是 CrazyHunter、快速應變，就是因為**先有了馬偕事件的完整情資**
>
> **對應⑤情資分享辦法的 7 類情資**：
>
> | 情資類型 | 馬偕事件對應 |
> | :--- | :--- |
> | 惡意偵察 | 攻擊者怎麼進入 AD |
> | 安全漏洞 | BYOVD（利用合法驅動程式漏洞）|
> | 攻擊方法 | GPO 派送、弱密碼嘗試 |
> | **惡意程式** | **7 支程式的 SHA256 hash** ⭐ |
> | 事件損害 | 500 多台電腦加密 |
> | 偵測預防措施 | IOC 比對、EDR 部署 |
> | 相關技術性資訊 | MITRE ATT&CK 對照 |
>
> **但分享有底線**——涉及**營業秘密**或**依法應保密**的不得分享。所以實務上會做**去識別化處理**：特徵碼、攻擊手法照分享，但事主身份、受害人資料要遮罩掉。
#### ⑥ 公務機關所屬人員安全事項獎懲辦法
| 類型 | 適用情形 |
| :--- | :--- |
| **獎勵** (12 項) | 有效實施資安維護計畫；稽核及演練績效優良；成功預防事件或降低損害；即時發現重大事件；提出具體建議或革新方案；對資安人才培育、科技研發及國際合作有貢獻等 |
| **懲處** (3 項) | 未依規定辦理資安相關事項（情資分享、維護計畫、稽核、改善報告、通報應變等）且**情節重大**；業務績效不良經疏導無效且情節重大；其他違反法規且情節重大 |
| **程序保障** | 懲處前應給予當事人**申辯機會**；必要時得徵詢資安專家學者意見 |
| **考核注意** | 應綜合考量事件原因、過程、動機、手段、表現及影響；聘僱人員獎懲納入續聘參考 |
---
## 2.3 其他相關法規
### 2.3.1 國家機密保護法
92 年 2 月 6 日公布，112 年 12 月 27 日修正。核心目的：確保國家安全或利益，對政府機關持有或保管經核定機密等級之資訊提供嚴格保護。
**國家機密等級與保密期限**：
| 等級 | 敏感程度 | 最長保密期限 |
| :--- | :--- | :--- |
| **絕對機密** | 最高 | **30 年** |
| **極機密** | 高度 | **20 年** |
| **機密** | 一般 | **10 年** |
**核定原則**：
* 應在必要之「**最小範圍內**」為之
* 權責人員應於接獲報請後 **30 日內**完成核定
* 應併予核定保密期限或解除機密之條件
* 112 年修正後，原核定「永久保密」者應於修正施行日起 **2 年內**重新核定；屆滿未重新核定者，視為解除機密
* 變更機密等級者，保密期限仍自**原核定日**起算
### 2.3.2 個人資料保護法
99 年 5 月 26 日公布，101 年 10 月 1 日施行，112 年 5 月 31 日修正。
* **立法目的**：規範個人資料之蒐集、處理及利用，以**避免人格權受侵害，並促進個人資料之合理利用**。
* **個人資料定義**：限定於**自然人**的資料，且能**直接或間接識別**該個人者：
* 屬性資料：姓名、生日、身分證字號
* 行為資料：健康檢查報告、犯罪前科
* 其他可識別資料：聯絡方式、地址、病歷、消費紀錄
* **核心規範**：
* **自主權利不可拋棄**：當事人的個資自主權利不得預先拋棄
* **特定目的原則**：蒐集、處理或利用必須有特定目的
* **告知義務**：蒐集時需告知目的、類別、使用範圍及來源
* **刪除義務**：應保持正確性，蒐集目的消失後應刪除
* **安全維護**：保有個資之單位應採行適當安全維護措施，防止竊取、竄改或毀損
### 2.3.3 《資通安全管理法》vs《個人資料保護法》比較
| 比較項目 | 資通安全管理法 | 個人資料保護法 |
| :--- | :--- | :--- |
| **主管機關** | **數位發展部** | **個人資料保護委員會** |
| **立法目的** | 推動國家資安政策，保障國家安全，維護社會公共利益 | 規範個資蒐集、處理及利用，避免人格權受侵害，促進個資合理利用 |
| **適用對象** | **公務機關**及**特定非公務機關**（組織層面） | **所有**蒐集、處理或利用個資的單位，含公務與非公務機關、法人、自然人 |
| **主要重點** | 納管機關之資安管理作業，降低資安風險 | 個人資料的保護，限制個資外洩與不當使用 |
| **出發點** | **組織層面**：提升整體資安防護能力 | **個人權益**：規範個人資料處理行為 |
> 📌 兩者雖目標不同，但實務上相互影響：良好的資安管理可有效降低個資外洩風險。114 年修正亦新增：資安事件涉及個資外洩時，應另依個資法辦理。
---
> 📝 **自我評量測驗**：請參閱 [自我評量題庫](https://hackmd.io/@hiiii/Hy0bFhHnWl#%E7%AC%AC-2-%E5%96%AE%E5%85%83%EF%BC%9A%E8%B3%87%E9%80%9A%E5%AE%89%E5%85%A8%E7%9B%B8%E9%97%9C%E6%B3%95%E8%A6%8F)
# 第三章：資通安全風險管理
> **學習目標**
> 1. 了解資通安全風險管理的整體流程，包括其核心步驟與循環特性。
> 2. 掌握風險管理全景建立的重要性，包括內外部環境的識別與風險準則的設定。
> 3. 學習風險評鑑的作法，包括高階與詳細評鑑的選擇與執行。
> 4. 理解風險處理的各項策略（修改、留存、避免、分擔）。
> 5. 明確風險接受的考量因素，以及殘餘風險的管理。
> 6. 認識國際重要資通安全防護與管理標準（NIST CSF 2.0、CNS 27005:2024）。
---
## 3.1 風險管理之流程
資通安全風險管理是一個**持續性的循環過程**，核心目標是在**有限的防護成本投入下獲得最佳化的安全性**，而非追求絕對的零風險。
### 3.1.1 「風險」的產生
風險源於三個關鍵要素的交互作用：
| 要素 | 說明 | 範例 |
| :--- | :--- | :--- |
| **威脅 (Threat)** | 可能對組織資產造成損害的**潛在原因或事件** | 釣魚郵件、天災、內部惡意人員 |
| **脆弱性 (Vulnerability)** | 資訊資產本身或保護機制中存在的**弱點**，可能被威脅利用 | 未更新的防毒軟體、弱密碼 |
| **衝擊 (Impact)** | 威脅利用脆弱性成功時，對資產造成的**負面影響** | 公文外洩、系統癱瘓 |
> 📌 **因果鏈範例**：「釣魚郵件」（威脅）被使用者點開，利用「未更新的防毒軟體」（脆弱性），可能導致「公文外洩」（衝擊）。
### 3.1.2 「風險」的定義
> 威脅利用其相對應的脆弱性，造成組織或政府機關資訊資產受到衝擊的「**可能性**」。
**風險大小 = 衝擊 × 可能性**
### 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 風險處理之作法
風險處理是繼風險評鑑之後的關鍵步驟，針對已評估出的風險，選擇並實施適當的行動方案，使風險降至可接受水平。
### 3.4.1 風險修改
**四種策略中最常見**，藉由施行、移除或改變安全控制措施，修訂或降低風險等級，使殘餘風險被重新評定為可接受。
**控制措施可提供的九種保護形式**：
| 類型 | 說明 |
| :--- | :--- |
| 矯正 (Correction) | 修復已存在的漏洞或錯誤 |
| 消弭 (Elimination) | 完全移除風險來源 |
| 預防 (Prevention) | 阻止事件發生 |
| 衝擊最小化 (Impact Minimization) | 減輕事件發生後的損害 |
| 制止 (Deterrence) | 透過威懾手段阻止攻擊者 |
| 偵測 (Detection) | 即時發現資安事件 |
| 復原 (Recovery) | 恢復受損系統及資料 |
| 監視 (Monitoring) | 持續監測系統及環境 |
| 認知 (Awareness) | 提升人員資安意識 |
> 📌 選擇控制措施時，應權衡實作及維護的**成本**與被保護資產的**價值**，確保成本效益。高階評鑑可參考「安全控制措施參考指引」依等級（普、中、高）選擇適用之控制措施。
> 💬 **志祥的話：這 9 種控制措施類型有必要背熟嗎？**
>
> 老實說——**我自己也記不起來**，這種分得極細的分類在實務上用處有限，真正的資安從業人員**不會特別去想「這是矯正性還是消弭性」**。
>
> 其實 9 種可以用**三個大類**概括，同學背三個就能應付絕大多數題目：
>
> | 大類 | 包含課本的哪幾種 | 時機 |
> | :--- | :--- | :--- |
> | **預防**（Preventive）| 預防、制止、認知 | 事前阻止事件發生 |
> | **偵測**（Detective）| 偵測、監視 | 事中發現異常 |
> | **矯正**（Corrective）| 矯正、消弭、衝擊最小化、復原 | 事後修復、回復 |
>
> **用法**：考試看到陌生名詞時，用「事前、事中、事後」的時機去推——例如「認知」是教育訓練（**事前**）→ 屬於**預防**；「衝擊最小化」是減輕損害（**事後**）→ 屬於**矯正**。
>
> **課本列 9 種的真正用意**：不是要你背熟，而是**提醒你選控制措施時要全面**——同一個資安事件，如果你只做預防（防火牆）沒做偵測（日誌告警）沒做矯正（備份還原）——被攻破之後就無法收拾。
### 3.4.2 風險留存
依據風險評估結果，確認無進一步行動，而**保留風險**的決策。
| 項目 | 說明 |
| :--- | :--- |
| **適用情境** | 風險等級符合接受準則、處理成本過高、無其他可行方案 |
| **決策要求** | 即使保留，該決策也應基於正式評估過程，並得到**組織高層批准** |
| **後續管理** | 保留的風險仍為「殘餘風險」，需**定期監控**並考量業務持續管理計畫 |
| **教材範例** | 自建機房容易斷電，因空間限制無法建置發電機，也無法保險或搬遷，只能選擇保留此風險 |
> 💬 **志祥的話：「風險留存」跟「沒發現風險」看起來都是不處理，差在哪？**
>
> 老師上課講過一個很精彩的分類——**風險依「是否識別」與「是否處理」可以分成四種**：
>
> | 類型 | 是否知道風險？ | 是否處理？ | 例子 |
> | :--- | :---: | :---: | :--- |
> | **① 知道並處理** | ✅ | ✅ | 識別出 SQL Injection → 加 WAF、資料加密 |
> | **② 知道但不處理（= 風險留存）**| ✅ | ❌ | 識別出機房斷電風險 → 但成本太高 → 決定承擔，改為定期監控 |
> | **③ 不知道但誤打誤撞處理了** | ❌ | ✅ | 沒評估過勒索病毒風險 → 但 IT 平常有做備份 → 剛好救了公司 |
> | **④ 不知道也沒處理** | ❌ | ❌ | 系統有零日漏洞從未發現 → 被駭後才知道 → 資料全洩 |
>
> **關鍵觀念**：同學常問——「**風險留存（②）跟沒識別出風險（④）看起來結果一樣都是沒處理，有差嗎？**」
>
> **差很多！** 關鍵在於「**有沒有在監控**」：
>
> - **②風險留存**：已經識別、評估、決策過了 → 風險「**在雷達上**」→ 有專人**持續監控**、事件發生時可以快速應變、保險或 BCP 也預先設計好
> - **④未識別風險**：風險「**不在雷達上**」→ 沒人監控 → 事件爆發才知道 → 一片混亂、連怎麼應變都要臨時想
>
> **這就是為什麼「風險留存」要經過正式評估、要組織高層批准、要定期重新檢視**——因為它跟「沒發現」有本質差別：**一個是有意識的選擇，一個是失職**。
>
> 考試或實務上如果有人說「反正都沒處理，留不留存有差嗎？」**就可以用這張表反駁**。
### 3.4.3 風險避免
直接**放棄或避免**可能造成風險增加的活動或情況，從根本上消除風險。
| 項目 | 說明 |
| :--- | :--- |
| **方法** | 終止或避免活動，徹底消除與特定風險相關的暴露 |
| **教材範例 1** | 為避免零日漏洞風險，決定不使用未經安全審核的第三方開源函式庫，自行開發程式碼 |
| **教材範例 2** | 將發電機從容易淹水的地下室移至樓上，避免颱風淹水損壞風險 |
| **注意** | 有時可能影響組織運作或目標達成，需仔細評估 |
### 3.4.4 風險分擔
將部分或全部風險**分攤至能有效管理該風險的第三方**。
| 方式 | 說明 |
| :--- | :--- |
| **保險 (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 等的對應關係 |
| **保持靈活性** | 非合規性標準或清單，而是**風險管理工具**，允許依自身需求定制化實施 |
### 3.6.2 CNS 27005:2024
CNS 27005 是我國國家標準，對應國際標準 ISO/IEC 27005，提供組織資訊安全風險管理的指引。
| 項目 | 說明 |
| :--- | :--- |
| **核心目的** | 為 CNS 27001 中關於風險處理的要求提供指引，整合 CNS 31000（風險管理指導綱要）的原則 |
| **適用範圍** | 所有類型、規模或行業的組織 |
| **關鍵術語** | 風險、威脅、脆弱性、後果、可能性、風險接受準則、風險胃納、剩餘風險 |
| **風險管理過程** | 迭代循環，分為「策略循環」及「運作循環」，包含風險評鑑與風險處理 |
| **全景建立** | 識別內外部環境、建立風險準則（含風險接受準則及風險評鑑執行準則） |
| **風險評鑑** | 風險識別（事件式作法或資產式作法）→ 風險分析 → 風險評估 |
| **風險處理** | 處理選項選擇 → 控制措施判定 → 產出「**適用性聲明 (SOA)**」→ 制定風險處理計畫 |
| **附錄 A** | 提供技術示例與表格（後果尺度、可能性尺度、風險矩陣、典型威脅及脆弱性分類） |
---
### 💡 總結：風險管理流程圖
---
> 💬 **志祥的話：高階 vs 詳細風險評鑑，實際怎麼做？**
>
> 課本把兩種評鑑講得很抽象，用一個**健康 App 公司**的例子走一遍就懂了。
>
> ---
>
> **情境**：公司有一個健康管理 App，要盤點所有資通系統的風險。
>
> **第一步：高階風險評鑑（全部系統快速掃一遍）**
>
> 依四個構面（CIA + 法規）判定每個系統的安全等級（普、中、高）：
>
> | 系統 | 機密性 | 完整性 | 可用性 | 法規 | 等級（取最高）|
> | :--- | :---: | :---: | :---: | :---: | :---: |
> | App 前端官網 | 普 | 普 | 普 | 普 | **普** |
> | 會員帳號系統 | 中 | 中 | 中 | 中 | **中** |
> | 健康資料庫（含病歷） | 高 | 高 | 中 | 高 | **高** ⚠️ |
> | AI 健康教練模型 | 中 | 高 | 中 | 高 | **高** ⚠️ |
>
> → 篩選出被評為 **高** 等級的系統要進一步處理：健康資料庫、AI 教練模型。
>
> → 同時，**所有系統依自己的等級（普、中、高）套用《資通安全責任等級分級辦法》附表十的控制措施**：
>
> | 系統等級 | 要做的事（對應附表十七大構面） |
> | :--- | :--- |
> | **普** | 套用「普級」控制措施（基本存取控制、日誌、備份等） |
> | **中** | 套用「中級」控制措施（加上多因子驗證、弱點掃描等） |
> | **高** | 套用「高級」控制措施（最嚴格：加密、稽核追蹤、異地備援等） |
>
> 💡 **關鍵**：高階評鑑的「等級」不只是用來篩選要不要做詳細評鑑，**本身就會直接對應到一套法規強制要求的控制措施清單**——這就是為什麼高階評鑑又叫「**查表型**」。
>
> **第二步：詳細風險評鑑（只對高風險系統深入分析）**
>
> 課本說詳細風險評鑑分成**三個階段**，我們對健康資料庫系統實際走一遍：
>
> **🏁 前置：公司先訂好「風險接受準則」**
>
> 公司董事會決議：**風險分數 15 分以上不能接受，必須處理**。這個數字就是風險接受門檻（依課本 3.2.2「風險接受準則」，由組織依業務需求、法規、成本自訂）。
>
> 風險分數怎麼算？用**風險矩陣**（5×5，嚴重度 × 可能性）：
>
> 
>
> **但「嚴重度 5」、「可能性 3」到底是什麼意思？** 實務上必須先訂**操作型定義**，讓每個評鑑成員打分時有共同標準，否則每個人主觀認定會差很多。以這家健康 App 公司為例：
>
> **📏 嚴重度（衝擊程度）評分標準**
>
> | 分數 | 等級 | 財務損失 | 法規與聲譽 | 業務衝擊 |
> | :---: | :--- | :--- | :--- | :--- |
> | **5** | 災難性 | > 5,000 萬 | 違反個資法重大處分、登上全國新聞頭條 | 核心業務停擺 > 7 天 |
> | **4** | 嚴重 | 500 萬 ~ 5,000 萬 | 主管機關裁罰、媒體報導 | 核心業務停擺 1~7 天 |
> | **3** | 中度 | 50 萬 ~ 500 萬 | 內部違規處分、客訴增加 | 部分業務中斷數小時 |
> | **2** | 輕微 | 5 萬 ~ 50 萬 | 少數客訴、可內部處理 | 單一部門暫時不便 |
> | **1** | 可忽略 | < 5 萬 | 無對外影響 | 幾乎無感 |
>
> **📅 可能性（發生機率）評分標準**
>
> | 分數 | 等級 | 發生頻率 | 業界參考 |
> | :---: | :--- | :--- | :--- |
> | **5** | 幾乎必然 | 每週發生 ≥ 1 次 | 已知漏洞且無防護、業界此類事件頻傳 |
> | **4** | 很可能 | 每月發生 ≥ 1 次 | 已知漏洞但防護不完整 |
> | **3** | 可能 | 每季發生 ≥ 1 次 | 業界偶有類似事件 |
> | **2** | 不太可能 | 每年發生 ≥ 1 次 | 有防護，但不是零風險 |
> | **1** | 罕見 | 數年才可能發生 1 次 | 歷史上極少發生或從未發生 |
>
> > 💡 **為什麼一定要訂定義？** 不然 A 同事覺得「駭客入侵」可能性是 5（因為天天有人被駭），B 同事覺得是 2（因為自家有防火牆），打出來的分數會差 3 倍。定義統一後，大家討論的是**同一件事**。
> >
> > 上面這兩張表每家公司可以自己調整（金融業可能把「財務損失 5,000 萬」降為 4 而非 5，醫療業更重視「病患安全」而不是財務損失），**但原則是同一組織內所有系統都用同一套標準**。
>
> **🗣️ 志祥的實務觀察：金額真的估得準嗎？**
>
> 講一個比較殘酷的實務真相——**5,000 萬、500 萬這種金額其實很難預估**。要抓駭客入侵會不會造成 5,000 萬損失？沒人知道。所以**很多公司做風險評鑑時其實就是憑感覺給 1~5 分**：「嗯我感覺這個蠻嚴重的打個 4」、「這個還好啦給 2」——**好做是好做，但做出來有沒有用，其實大家心裡也有點虛**。
>
> 但為什麼還是要做？因為：
> 1. **法規要求**（資安法、ISO 27001 都要求做風險評鑑）
> 2. **至少讓討論有共同基礎**（就算不精確，至少不同系統之間可以相互比較）
>
> **如果真的想估得認真一點**，有一個實務上好用的錨定法——**用「停機一天的營業額」當換算基準**：
>
> 假設健康 App 公司**停機一天營業損失約 10 萬元**，那就可以換算成：
>
> | 嚴重度 | 金額範圍 | 換算停機天數 | 感受 |
> | :---: | :--- | :--- | :--- |
> | **5** | > 5,000 萬 | > 500 天 | 整家公司可能倒閉 |
> | **4** | 500 ~ 5,000 萬 | 50 ~ 500 天 | 元氣大傷，老闆要解釋到死 |
> | **3** | 50 ~ 500 萬 | 5 ~ 50 天 | 一季季報難看 |
> | **2** | 5 ~ 50 萬 | 半天 ~ 5 天 | 部門 KPI 不好看 |
> | **1** | < 5 萬 | < 半天 | 沒感覺 |
>
> 這樣跟業務端討論時就不是「5,000 萬很多吧？」這種抽象說法，而是「**停半年有沒有差？**」——**對業務主管來說，後者比較有感**。
>
> 💬 **但還是那句話**：估出來的分數不是真理，是**討論的起點**。重點不是「15 分對不對」，而是**大家看著同一個分數，決定要不要做、要做到什麼程度**。這才是風險評鑑的真正價值——**推動決策**，而不是產出一份準確到小數點以下的數字。
>
> ---
>
> **🔍 階段 1：風險識別（Risk Identification）**
>
> 針對健康資料庫，找出以下四件事：
>
> | 識別項目 | 內容 |
> | :--- | :--- |
> | **資產識別** | 健康資料庫（含 50 萬使用者的身高體重、血壓、用藥紀錄） |
> | **威脅與脆弱性識別** | 威脅：駭客 SQL Injection、勒索病毒、內部員工洩漏；脆弱性：密碼強度不足、未做異常存取偵測、DBA 權限過大 |
> | **現有控制措施識別** | 已做：帳號密碼登入、每日備份；未做：資料加密、多因子驗證 |
> | **後果識別** | 若外洩 → 違反個資法、公司被罰、50 萬使用者名譽受損、媒體負面報導 |
>
> ---
>
> **📊 階段 2：風險分析（Risk Analysis）**
>
> 針對已識別的威脅，逐一估算分數：
>
> | 風險項目 | 嚴重度 | 可能性 | 處理前分數 |
> | :--- | :---: | :---: | :---: |
> | 雲端資料庫被駭客入侵（SQL Injection） | 5 | 3 | **15** ⚠️ |
> | 去識別化統計報告被還原（樣本太小）| 5 | 4 | **20** ⚠️ |
> | 兒少未驗證年齡註冊 | 4 | 3 | **12** |
> | 員工誤將備份檔複製到隨身碟 | 3 | 2 | **6** |
> | 機房冷氣故障導致服務暫停 | 2 | 2 | **4** |
>
> ---
>
> **⚖️ 階段 3：風險評估（Risk Evaluation）**
>
> 對照公司門檻 15，把風險分成**可接受**與**不可接受**：
>
> | 風險項目 | 分數 | 判定 | 行動 |
> | :--- | :---: | :--- | :--- |
> | 雲端資料庫被駭 | 15 | ❌ 不可接受 | → 進入風險處理 |
> | 統計報告被還原 | 20 | ❌ 不可接受 | → 進入風險處理 |
> | 兒少未驗證年齡 | 12 | ✅ 低於門檻 | → 先**風險接受**（但仍要監控）|
> | 員工複製備份檔 | 6 | ✅ 低於門檻 | → **風險接受** |
> | 冷氣故障 | 4 | ✅ 低於門檻 | → **風險接受** |
>
> ---
>
> **🛠️ 風險處理階段（針對不可接受的 2 條）**
>
> 對不可接受的風險選策略，**處理完後要重新估算殘餘風險**（= 處理後的風險分數）：
>
> | 風險項目 | 處理前 | 處理策略 | 處理方式 | 處理後（殘餘風險）| 最終狀態 |
> | :--- | :---: | :---: | :--- | :---: | :---: |
> | 雲端資料庫被駭 | 15 | **降低（修改）** | 資料加密、WAF、滲透測試、MFA | 6 | ✅ 可接受 |
> | 統計報告被還原 | 20 | **避免** | 直接停止做小樣本報告，改用差分隱私演算法 | 0 | ✅ 可接受 |
>
> **關鍵邏輯**：
> - 處理前分數 ≥ 15 → **必須處理**
> - 處理後分數（殘餘風險）< 15 → 才可以**風險接受** ✅
> - 如果處理後**還是 ≥ 15** → 就要**回去重新選策略**（例如原本選「降低」不夠，改成「分擔」買保險，或「避免」直接停用系統）
>
> ---
>
> **📌 兒少風險補充說明**
>
> 兒少分數 12 雖然低於門檻 15，但**業務端覺得法遵風險高、主管機關關注度高**，所以**主動追加處理**（不一定要分數超標才處理）：加上年齡驗證、家長同意機制。**→ 這就是「風險接受準則」之外的業務判斷，課本 3.2.2 有提到「法規、業務需求也會影響風險接受準則」**。
>
> ---
>
> **📖 比較一下高階 vs 詳細**：
>
> | | 高階 | 詳細 |
> | :--- | :--- | :--- |
> | **輸出** | 一個等級（普、中、高）| 具體的風險分數 + 處理後殘餘風險 |
> | **處理方式** | 套附表十的控制措施清單 | 量身打造：修改 / 留存 / 避免 / 分擔 |
> | **範圍** | 所有系統跑一輪 | 只做高風險系統 |
> | **精神** | 「我這個系統屬於哪個等級？」| 「我這個具體風險可不可接受？能降到多少？」|
>
> **課本原文收尾**：「**初期採高階評鑑快速建立風險概觀，隨後針對高風險資產或資安事件後，再執行詳細評鑑**」——兩者**不是二選一**，是**先篩選、再聚焦**。
---
> 📝 **自我評量測驗**：請參閱 [自我評量題庫](https://hackmd.io/@hiiii/Hy0bFhHnWl#%E7%AC%AC-3-%E5%96%AE%E5%85%83%EF%BC%9A%E8%B3%87%E9%80%9A%E5%AE%89%E5%85%A8%E9%A2%A8%E9%9A%AA%E7%AE%A1%E7%90%86)
# 第四章：資通安全管理面暨認知與訓練應辦事項
> **學習目標**
> 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 業務持續運作管理程序（七步驟）
各步驟重點：
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/年 |
> ⚠️ 課本 p.138 表 29 係依修法前之舊版附表七編寫，D 級「資安專職以外之資訊人員」標示「無要求」。惟依 115 年 1 月 7 日修正後之[資通安全責任等級分級辦法](https://law.moj.gov.tw/LawClass/LawAll.aspx?pcode=A0030304)附表七，D 級已新增該類人員訓練要求。本表以修正後法規為準。
> 📌 **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)。
* **職能訓練證書**：指完成資通安全職能訓練課程後取得之證書。可參考[資安職能訓練課程網](https://ctts.nics.nat.gov.tw/)。
---
### 💡 總結：應辦事項 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 小時通識？
- [ ] 證照持有是否符合要求（公務：證照**及**證書；特非：證照**或**證書）？
---
> 📝 **自我評量測驗**：請參閱 [自我評量題庫](https://hackmd.io/@hiiii/Hy0bFhHnWl)
# 第五章：資通系統防護控制措施
> **🎯 學習目標**
> 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 ≥ 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測試階段） | ✓ | ✓ | ✓ |
| 異地備份 | ✓ | — | — |
| 傳輸加密 | ✓ | — | — |
| 自動化監控 | ✓ | — | — |
| 帳號自動登出 | ✓ | — | — |
| 日誌異地備份 | ✓ | — | — |
| 密碼雜湊儲存 | ✓ | ✓ | — |
---
> 📝 **自我評量測驗**：請參閱 [自我評量題庫](https://hackmd.io/@hiiii/Hy0bFhHnWl)
# 第六章：資通安全技術面應辦事項 ― 資通安全之防護及偵測
> **學習目標**
> 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（連通優先） |
---
> 📝 **自我評量測驗**：請參閱 [自我評量題庫](https://hackmd.io/@hiiii/Hy0bFhHnWl)
# 第七章：資通安全技術面應辦事項 (安全性檢測及資通安全健診)
> **學習目標**
> 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 漏水偵測
* 消防灑水系統可能會有漏水問題，**機房無法灑水**，需裝設特殊滅火裝置（如氣體滅火系統）。
* 水的偵測可避免損害設備、鋪設地板、牆、電腦、建築物基礎。
* **偵測位置**：高架地板下、天花板。
---
> 📝 **自我評量測驗**：請參閱 [自我評量題庫](https://hackmd.io/@hiiii/Hy0bFhHnWl)
# 第八章：資通系統委外安全管理
> **學習目標**
> 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 個面向，對應不同的採購階段：
| 階段 | 重點 | 對應採購階段 |
| :--- | :--- | :--- |
| **① 決定需求** | 明確定義資安需求（機密性、完整性、可用性、存取控制、稽核紀錄、隱私保護等），為後續所有階段奠定基礎 | 計畫 |
| **② 識別可行解決方案** | 分析現況與期望目標落差，識別方案選項，訂定評估指標（含資安風險、廠商資安能力、合規性等） | 計畫 |
| **③ 選定解決方案** | 依據評估指標（含資安指標）對合格廠商進行綜合評估，由決策者選出適當方案 | 決標 |
| **④ 完成建置** | 成立專案組織，督導廠商遵循 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 面向監控（組織、風險、人力、實體、管理、存取、事件） |
| **驗收** | 安全嗎？ | 安全性檢測證明、第三方元件揭露、權限移除 |
| **保固** | 能維持嗎？ | 變更管理、異常通報、維持驗收時資安水準 |
---
> 📝 **自我評量測驗**：請參閱 [自我評量題庫](https://hackmd.io/@hiiii/Hy0bFhHnWl)
# 第九章：資通安全事件通報及應變
> **學習目標**
> 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 正確防範觀念
> 📌 **最經濟有效的防治：強化認知訓練與宣導**
>
> 技術手段（防火牆、郵件過濾、SOC）無法 100% 攔住社交工程攻擊，**最後一道防線永遠是人的警覺心**。這也是為什麼《資通安全責任等級分級辦法》規定**社交工程演練每半年 1 次**，比其他演練都頻繁。
> 📌 **座右銘**：「**不輕信、多求證、速通報**」
1. **隨時提高警覺**：在沒有適當認證的情況下不應輕信他人，出現任何社交工程攻擊警訊都應保持**小心求證**的戒心。
2. **具體防範行動**：
* **不**未經確認即提供資料（帳號密碼、OTP 驗證碼等）
* **不**開啟來路不明的電子郵件及附加檔案（特別是壓縮檔或可執行檔）
* **不**連結及登入未經確認的網站（檢查網址正確性及 HTTPS）
* **不**下載非法軟體及檔案
* **避免**在公共場所使用免費 WiFi 熱點（如需使用應搭配 VPN）
3. **任何資訊釋出都要確認要求者身分及授權**：無論電話、即時通訊或面對面，不僅憑表面資訊就輕信。
4. **遇到疑似攻擊事件立即通報**：即使沒有上當，發現可疑社交工程企圖也應立即向資安部門通報。
---
### 💡 總結：事件應變 Check List
- [ ] 是否在知悉事件 **1 小時內** 完成通報？
- [ ] 是否依據 **CIA 衝擊**（取最高等級）與 **業務性質** 正確評估事件等級 (1~4 級)？
- [ ] 重大事件 (3、4 級) 是否在 **36 小時內** 完成損害控制及復原？
- [ ] 處理過程是否落實 **準備 → 識別 → 封鎖 → 根除 → 復原 → 經驗學習** 六階段？
- [ ] 鑑識過程是否確保 **監管鏈** 完整且未汙染原始證物？
- [ ] 個資外洩事件是否已依個資法 **主動通知** 受影響當事人？
- [ ] 調查處理改善報告是否在 **1 個月內** 提交？
---
> 📝 **自我評量測驗**：請參閱 [自我評量題庫](https://hackmd.io/@hiiii/Hy0bFhHnWl)
# 附錄一：資通安全責任等級應辦事項總表
> 📌 本表依 115 年 1 月 7 日修正後之[資通安全責任等級分級辦法](https://law.moj.gov.tw/LawClass/LawAll.aspx?pcode=A0030304)附表一～附表八彙整。
>
> 📌 **考試重點**：各機關需**每 3 年**（114 年修法後）核定或提交其資通安全責任等級。
**等級適用對象**
| 等級 | 公務機關 | 特定非公務機關 |
| :---: | :--- | :--- |
| **A** | 附表一 | 附表二 |
| **B** | 附表三 | 附表四 |
| **C** | 附表五 | 附表六 |
| **D** | 附表七（共用） | ← |
| **E** | 附表八（共用） | ← |
---
**一、管理面應辦事項**
| 項目 | A 級 | B 級 | C 級 |
| :--- | :---: | :---: | :---: |
| 資通系統分級及防護基準 | 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 次/年 | — |
> ⚠️ 資安治理成熟度評估：公務機關 A、B 級每年辦理；特定非公務機關僅**關鍵基礎設施提供者**每年辦理。
---
**二、技術面應辦事項**
| 項目 | A 級 | B 級 | C 級 | D 級 |
| :--- | :---: | :---: | :---: | :---: |
| 弱點掃描 | **2** 次/年 | 1 次/年 | 1 次/**2年** | — |
| 滲透測試 | 1 次/年 | 1 次/**2年** | 1 次/**2年** | — |
| 資通安全健診 | 1 次/年 | 1 次/2年 | 1 次/2年 | — |
| SOC 監控管理機制 | ✓ | ✓ | — | — |
| 政府組態基準 \(GCB\) | ✓ | ✓ | — | — |
| 弱點管理 \(VANS\) | ✓ | ✓ | ✓ | — |
| 端點偵測及應變 \(EDR\) | ✓ | ✓ | — | — |
| 資通安全防護 | 1 年內 | 1 年內 | 1 年內 | 1 年內 |
> 📌 資通安全健診包含項目詳見「三、資通安全健診項目」。
> 📌 資通安全防護包含項目詳見「四、資通安全防護措施」。
---
**三、資通安全健診項目**
| 項目 | A 級 | B 級 | C 級 |
| :--- | :---: | :---: | :---: |
| 網路架構檢視 | ✓ | ✓ | ✓ |
| 網路惡意活動檢視 | ✓ | ✓ | ✓ |
| 使用者端電腦惡意活動檢視 | ✓ | ✓ | ✓ |
| 伺服器主機惡意活動檢視 | ✓ | ✓ | ✓ |
| 目錄服務系統設定及防火牆連線設定檢視 | ✓ | ✓ | ✓ |
| 核心資通系統資料庫安全檢視 | ✓ | ✓ | — |
---
**四、資通安全防護措施**
| 項目 | A 級 | B 級 | C 級 | D 級 |
| :--- | :---: | :---: | :---: | :---: |
| 防毒軟體 | ✓ | ✓ | ✓ | ✓ |
| 網路防火牆 | ✓ | ✓ | ✓ | ✓ |
| 電子郵件過濾機制（具有郵件伺服器者） | ✓ | ✓ | ✓ | — |
| 入侵偵測及防禦機制 \(IDPS\) | ✓ | ✓ | — | — |
| 應用程式防火牆 \(WAF\)（具有對外服務之核心資通系統者） | ✓ | ✓ | — | — |
| 進階持續性威脅攻擊防禦措施 \(APT\) | ✓ | — | — | — |
---
**五、認知與訓練**
| 項目 | A 級 | B 級 | C 級 | D 級 | E 級 |
| :--- | :---: | :---: | :---: | :---: | :---: |
| 資安專職人員 | 專業 **12** hr/年 | ← | ← | — | — |
| 資安專職以外之資訊人員 | 專業 **3** hr/2年 + 通識 **3** hr/年 | ← | ← | ← | — |
| 一般使用者及主管 | 通識 **3** hr/年 | ← | ← | ← | ← |
---
**六、資通安全專業證照及職能訓練證書**
| 項目 | A 級 | B 級 | C 級 |
| :--- | :---: | :---: | :---: |
| 持有人數 | **4** 人以上 | **2** 人以上 | **1** 人以上 |
| 公務機關要求 | 證照**及**證書各一張 | ← | ← |
| 特定非公務機關要求 | 證照**或**證書一張 | ← | ← |
> 📌 **考試重點**：公務機關「**及**」vs 特定非公務機關「**或**」，一字之差！
---
**七、公務機關 vs 特定非公務機關差異速查**
| 項目 | 公務機關 | 特定非公務機關 |
| :--- | :--- | :--- |
| 證照要求 | 證照**及**證書**各一張**以上 | 證照**或**證書**一張**以上 |
| 成熟度評估 | A、B 級每年辦理 | 僅**關鍵基礎設施提供者**每年辦理 |
| 弱點管理導入 | A～C 級均須導入 | 僅**關鍵基礎設施提供者**須導入 |
---
# 附錄二：附表十 資通系統防護基準（精簡摘要）
> 📌 本表依 115 年 1 月 7 日修正後之[資通安全責任等級分級辦法](https://law.moj.gov.tw/LawClass/LawAll.aspx?pcode=A0030304)附表十摘要。完整條文請參閱法規原文。
> 📌 **閱讀方式**：各等級為累加關係，從左往右看。普級為基礎要求，中級含普級所有要求再加上中級欄位的內容，高級含中+普所有要求再加上高級欄位的內容。
**一、存取控制**
| 控制措施 | 普 | 中 | 高 |
| :--- | :--- | :--- | :--- |
| 帳號管理 | 建立帳號申請/建立/修改/啟停用/刪除程序；逾期臨時帳號刪除或禁用；閒置帳號禁用；定期審核 | 定義閒置時間或使用期限，逾期**自動登出** | 監控帳號違常使用並**回報管理者** |
| 最小權限 | 採最小權限原則，僅允許完成指派任務所需之授權存取 | （無額外要求） | （無額外要求） |
| 遠端存取 | 先取得授權並文件化；權限檢查於**伺服器端**完成；監控後臺連線；採**加密**；來源限定預定義存取控制點 | （無額外要求） | （無額外要求） |
---
**二、事件日誌與可歸責性**
| 控制措施 | 普 | 中 | 高 |
| :--- | :--- | :--- | :--- |
| 記錄事件 | 日誌留存至少 **6 個月**；記錄特定事件；記錄管理者帳號操作 | （無額外要求） | **定期審查**日誌 |
| 日誌紀錄內容 | 事件類型、時間、位置、使用者身分識別；單一日誌機制確保格式一致 | （無額外要求） | （無額外要求） |
| 日誌儲存容量 | 依需求配置儲存容量 | （無額外要求） | （無額外要求） |
| 日誌處理失效之回應 | 失效時採取適當行動 | （無額外要求） | 失效時於規定時效內**即時警告**特定人員 |
| 時戳及校時 | 內部時鐘產生時戳，對應 **UTC/GMT**；定期與基準時間源同步 | （無額外要求） | （無額外要求） |
| 日誌資訊之保護 | 日誌存取僅限有權限之使用者 | 運用**雜湊**或完整性確保機制 | 定期備份至**原系統外**之實體系統 |
---
**三、營運持續計畫**
| 控制措施 | 普 | 中 | 高 |
| :--- | :--- | :--- | :--- |
| 資料備份 | 訂定 **RPO**；執行資料備份 | 定期測試備份資料可靠性及完整性 | 備份還原納入 **BCP 演練**；建立**異地備份** |
| 系統備援 | 訂定 **MTPD**（最大可容忍中斷時間） | 定期測試於 MTPD 內由備援取代服務 | 備援啟動納入 **BCP 演練** |
---
**四、識別與鑑別**
| 控制措施 | 普 | 中 | 高 |
| :--- | :--- | :--- | :--- |
| 使用者識別與鑑別 | 識別及鑑別使用者；禁止**共用帳號** | （無額外要求） | **多因子鑑別** |
| 身分驗證管理 | 預設密碼首次登入**立即變更**；不以明文傳輸；帳號鎖定（失敗 **5 次鎖 15 分鐘**）；強制密碼複雜度及效期；不可與前 **3 次**密碼相同 | 防範自動化登入；密碼重設發送**一次性時效符記** | （無額外要求） |
| 鑑別資訊保護 | **遮蔽**鑑別過程中之資訊 | 密碼經**雜湊**或適當方式處理後儲存 | （無額外要求） |
---
**五、系統與服務獲得**
| 控制措施 | 普 | 中 | 高 |
| :--- | :--- | :--- | :--- |
| SDLC 需求階段 | 針對安全需求（機密性、可用性、完整性）進行確認 | （無額外要求） | （無額外要求） |
| SDLC 設計階段 | 無要求 | 識別威脅進行風險分析；回饋需求階段 | （無額外要求） |
| SDLC 開發階段 | 實作安全控制措施；避免常見漏洞；錯誤頁面僅顯示代碼不含詳細訊息 | （無額外要求） | 執行**源碼掃描**；嚴重錯誤通知機制 |
| SDLC 測試階段 | 執行**弱點掃描** | （無額外要求） | 執行**滲透測試** |
| SDLC 部署與維運 | 更新修補；關閉不必要服務及埠口；不使用預設密碼；源碼備份 | 版本控制與變更管理 | （無額外要求） |
| SDLC 委外階段 | 安全需求依等級納入委外契約 | （無額外要求） | （無額外要求） |
| 獲得程序 | 識別第三方軟體/服務/函式庫 | 開發、測試、正式環境**三環境區隔** | （無額外要求） |
| 系統文件 | 儲存與管理 SDLC 相關文件 | （無額外要求） | （無額外要求） |
---
**六、系統與通訊保護**
| 控制措施 | 普 | 中 | 高 |
| :--- | :--- | :--- | :--- |
| 傳輸之機密性與完整性 | 無要求 | 無要求 | **加密**防止未授權揭露；使用公開且未遭破解之演算法；金鑰/憑證定期更換；伺服器端金鑰保管規範 |
| 資料儲存之安全 | 無要求 | 無要求 | 重要組態設定檔案及具保護需求之資訊應**加密儲存** |
---
**七、系統與資訊完整性**
| 控制措施 | 普 | 中 | 高 |
| :--- | :--- | :--- | :--- |
| 漏洞修復 | 漏洞修復應測試有效性及潛在影響，定期更新 | 定期確認漏洞修復狀態 | （無額外要求） |
| 資通系統監控 | 發現被入侵跡象時**通報**特定人員 | 監控以偵測攻擊與未授權連線，識別未授權使用 | **自動化工具**監控進出通信流量，不尋常活動進行分析 |
| 軟體及資訊完整性 | 使用者輸入資料合法性檢查於**伺服器端** | 使用完整性驗證工具偵測未授權變更；違反時實施安全保護措施 | 定期執行軟體與資訊完整性檢查 |
---
**考試速記：附表十關鍵數字**
| 數字 | 內容 | 等級 |
| :---: | :--- | :---: |
| **6 個月** | 日誌留存至少 6 個月 | 普 |
| **5 次 / 15 分鐘** | 帳號登入驗證失敗達 5 次，至少 15 分鐘內不允許繼續嘗試登入 | 普 |
| **3 次** | 密碼變更時，不可與前 3 次使用過之密碼相同 | 普 |
| **3 環境** | 開發、測試、正式作業環境應為區隔 | 中 |
Google Drive
Gist
Clipboard
Sign in via Google
Sign in via Facebook
Sign in via X(Twitter)
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
