# iPAS 資訊安全工程師初級 考試重點整理

> **最後修改日期**：2026/01/14

[TOC]

---

# 第一科：資訊安全管理概論

## 1.1 資訊安全管理概念

### 為什麼要做資安？

資訊安全不是目的，而是**支撐組織使命與願景的手段**。

| 概念 | 定義 | 範例 |
|:-----|:-----|:-----|
| 使命 | 組織「現在」存在的理由，說明在做什麼、為誰服務 | 提供安全可靠的金融服務 |
| 願景 | 組織「未來」想成為的樣子，代表方向與理想 | 成為最值得信賴的銀行 |

**資訊安全的三階目標：**

| 層級 | 目標 | 說明 |
|:----:|:-----|:-----|
| 最終 | 實現組織使命與願景 | 資安存在的終極價值 |
| 中層 | 支持組織業務運作 | 讓業務流程順利進行 |
| 基礎 | 保護 CIA 三要素 | 機密性、完整性、可用性 |

**資安的價值：**
- 🛡️ **保護資產與信任**：客戶資料、商業機密、企業聲譽
- ⚖️ **降低風險與合規**：避免裁罰、訴訟、財務損失
- 🔄 **確保營運不中斷**：業務持續運作，服務不停擺

**達標方法：**
- 策略管理：制定資安政策與方向
- 風險管理：識別、評估、處理風險
- 問題解決：事件應變與持續改善

> 💡 **考試重點**：CIA 只是基礎目標，資安的最終目的是「支撐組織使命與願景」。

---

### 1.1.1 資訊安全管理系統

#### 資安三要素 (CIA Triad)

資訊安全的核心建立在三大要素之上：

| 要素 | 英文 | 定義 | 防護技術 | 對應威脅 |
|------|------|------|----------|----------|
| 機密性 | Confidentiality | 確保資料只有經授權的人才能看到 | 加密技術 | 竊聽 |
| 完整性 | Integrity | 確保資料不被未經授權的更改 | 雜湊函數 | 竄改 |
| 可用性 | Availability | 確保資料在需要時都能使用 | 叢集系統、備份機制 | 阻斷攻擊 |

> 💡 **CIA 三要素沒有固定優先順序**：銀行重視完整性（帳務不能錯）、醫院重視可用性（系統不能停）、軍方重視機密性（資料不能洩）。

#### 延伸安全要素

除了 CIA 三要素外，還有四個延伸要素：

| 要素 | 英文 | 定義 | 實作方式 | 失敗情境 |
|------|------|------|----------|----------|
| 身分認證性 | Authentication | 確認你是你說的那個人 | IAM 身分識別與存取管理 | 暴力破解密碼 |
| 真實性 | Authenticity | 確認來源是真的且內容未被竄改 | 數位簽章 | 冒用身分 |
| 不可否認性 | Non-repudiation | 做過的事情不能否認 | 數位憑證 | 事後否認行為 |
| 可歸責性 | Accountability | 可追蹤誰對系統做了什麼事 | 稽核軌跡 | 共用帳號無法追蹤 |

#### 控制方法分類

**依實施方法分類：**
- **管理控制 (Administrative Control)**：透過政策與程序來規範，如資安政策、教育訓練
- **技術控制 (Technical Control)**：透過技術手段實作，如防火牆、加密
- **實體控制 (Physical Control)**：透過實體設備保護，如監視器、門禁系統

**依控制目的分類：**

| 類型 | 說明 | 範例 |
|------|------|------|
| 預防性 (Preventive) | 事前預防事件發生 | 要求主管核准超過特定金額的交易 |
| 威懾性 (Deterrent) | 嚇阻潛在攻擊者 | 張貼「內有惡犬」告示牌 |
| 檢測性 (Detective) | 偵測異常或攻擊 | 身分證最後一碼檢查碼 |
| 糾正性 (Corrective) | 發現問題後立即修正 | 連網前檢查並安裝最新病毒碼 |
| 還原性 (Recovery) | 災後恢復正常運作 | 資料備份還原 |
| 補償性 (Compensating) | 當其他控制無法實施時的替代方案 | 將不安全系統放置在隔離網段 |

---

### 1.1.2 相關法規概論與遵循

#### 國內法規

**資通安全管理法**

納管對象包括：
- **公務機關**：各級政府機關
- **特定非公務機關**：關鍵基礎設施提供者（能源、水資源、通訊傳播、交通、金融、緊急救援與醫院、政府機關、科學園區與工業區、農業）、公營事業、公營法人

**資通安全管理法子法架構**

| 子法 | 主要內容 | 備註 |
|:-----|:---------|:-----|
| **資通安全管理法施行細則** | 母法條文解釋、資安維護計畫應包含事項、委外監督規定 | 常考 |
| **資通安全責任等級分級辦法** | 機關分級\(A/B/C/D/E\)、應辦事項\(附表1-8\)、**資安演練規定**、資通系統防護基準\(附表9-10\) | 常考 |
| **資通安全事件通報及應變辦法** | 事件分級\(1-4級\)、**通報時限**、應變程序、損害控制及復原 | 常考 |
| 資通安全情資分享辦法 | 情資類型定義、分享機制與程序、分享對象範圍、保密義務規定 | |
| 公務機關資通安全維護計畫實施情形稽核辦法 | 公務機關稽核頻率、內容、方法、改善報告程序 | ⭐ 114年修法新增 |
| 特定非公務機關資通安全維護計畫實施情形稽核辦法 | 特定非公務機關稽核小組設置、稽核流程、稽核結果報告 | |
| 公務機關所屬人員資通安全事項獎懲辦法 | 資安績優獎勵、違規懲處標準、督導不力之懲處 | |
| 危害國家資通安全產品審查辦法 | 危害產品審查程序、風險評估、情資分享、使用限制 | ⭐ 114年修法新增 |

> 💡 **演練規定**在「資通安全責任等級分級辦法」，**通報時限**在「資通安全事件通報及應變辦法」。

**資通安全責任等級分級：**

| 等級 | 說明 |
|------|------|
| A級 | 全國性重要機關 |
| B級 | 區域或地區性重要機關 |
| C級 | 自行或委外設置、開發資通系統者 |
| D級 | 自行辦理資通業務，但未維運資通系統者 |
| E級 | 無資通系統且未提供資通服務者 |

**資通安全事件分級標準**

**資通安全事件通報時限：**

**妨害電腦使用罪（刑法第 358-363 條）：**
- 第 358 條：無故入侵他人電腦，處 3 年以下有期徒刑，併科 30 萬元以下罰金
- 第 359 條：無故取得、刪除或變更他人電磁紀錄致生損害，處 5 年以下有期徒刑，併科 60 萬元以下罰金
- 第 360 條：無故以電腦程式干擾他人電腦致生損害，處 3 年以下有期徒刑，併科 30 萬元以下罰金

**上市櫃公司資安重訊規定：**
若發生資安事件導致重大損害，預估損失超過實收資本額 20% 或新台幣 3 億元以上者，應於上午 7 點前發布重大訊息。未依規定揭露，最高可處 500 萬元違約金。

#### 國際標準與框架

**ISO 27001 和 ISO 27002重要常考**



| 標準 | 說明 |
|------|------|
| ISO 27001 | 資訊安全管理系統（ISMS）標準 |
| ISO 27002 | 資訊安全控制措施指引 |
| ISO 27701 | 隱私資訊管理系統 |
| ISO 22301 | 營運持續管理系統 |
| NIST CSF | 美國國家標準技術研究院網路安全框架，包含：治理、識別、保護、偵測、回應、復原 |
| ISO 27017 | 雲端服務供應商安全 |
| ISO 27018 | 雲端個人資料隱私保護 |
| CSA STAR | 雲端安全聯盟認證，評估雲端服務安全性 |
| SOC 2 | 服務組織控制報告，適用各種服務組織 |

> 💡 **CNS 與 ISO 的關係**：CNS 是台灣國家標準，由標準檢驗局將 ISO 國際標準翻譯為繁體中文版本。例如 CNS 27001 對應 ISO 27001、CNS 27002 對應 ISO 27002，內容相同。

#### 產業相關標準

| 標準 | 適用領域 |
|------|----------|
|BS 10012|英國隱私相關|
| PCI DSS | 支付卡產業資料安全標準 |
| HIPAA | 美國醫療資訊隱私 |
| IEC 62443 | 工業控制系統安全 |
| SEMI E187 | 半導體產線設備資安標準 |
| SOX 沙賓法案 | 美國上市公司財報內控 |
| CIS Controls | 資安控管最佳實務 |

---

#### SOC 服務組織控制報告

| 類型 | 適用對象 | 說明 |
|:-----|:---------|:-----|
| SOC 1 | 財務相關服務 | 針對影響客戶財務報告的內部控制 |
| SOC 2 | 各種服務組織 | 針對安全性、可用性、處理完整性、機密性、隱私 |
| SOC 3 | 一般大眾 | SOC 2 的簡化公開版本 |

| Type | 評估範圍 | 說明 |
|:-----|:---------|:-----|
| Type 1 | 某一時間點 | 評估控制措施的「設計適當性」 |
| Type 2 | 一段期間（6-12 個月） | 評估控制措施的「運作有效性」 |

| 報告類型 | 公開性 | 取得方式 |
|:---------|:------:|:---------|
| SOC 2 | 受限 | 需簽署 NDA 或有業務往來 |
| SOC 3 | 公開 | 可直接從官網下載 |

> 💡 **SOC 2 vs SOC 3**：SOC 2 內容詳細但受限，SOC 3 是公開摘要版。想看 Azure、AWS 的 SOC 2 報告需簽 NDA，但 SOC 3 可直接下載。

### 1.1.3 隱私權保護與智慧財產權

#### 智慧財產權相關法規

| 法規 | 保護標的 | 保護期限 | 取得方式 |
|:-----|:---------|:---------|:---------|
| 專利法 | 發明、新型、設計 | 發明 20 年、新型 10 年、設計 15 年 | 需申請註冊 |
| 商標法 | 品牌標識 | 10 年，可無限續展 | 需申請註冊 |
| 著作權法 | 創作表達 | 著作人生存期間 + 死後 50 年 | 創作完成自動取得 |
| 營業秘密法 | 商業機密資訊 | 無期限（秘密性存續期間） | 無需註冊，符合要件即受保護 |

**營業秘密三要件：**
1. **秘密性**：非一般人所知
2. **經濟價值**：因秘密性而具有實際或潛在價值
3. **合理保密措施**：所有人已採取合理保護措施

**著作權法重點：**

| 類型 | 說明 | 可否轉讓 |
|:-----|:-----|:--------:|
| 著作人格權 | 公開發表權、姓名表示權、禁止不當修改權 | ❌ |
| 著作財產權 | 重製、改作、散布、公開傳輸等權利 | ✅ |

> 💡 **著作權 vs 專利**：著作權保護「表達形式」，專利保護「技術內容」。同樣的演算法，程式碼受著作權保護，但演算法本身需申請專利。

> ⚠️ **合理使用**：為個人非營利目的，在合理範圍內得引用已公開著作，但仍應註明出處。

#### 個人資料保護法

個人資料保護法所稱「個人資料」，指**自然人**之相關資料，可直接或間接識別該個人者。

> ⚠️ **法人（公司、機關）不適用個資法**，公司統一編號、機關代碼等不屬於個人資料。

**個資處理三階段：**
- **蒐集**：以任何方式取得個人資料
- **處理**：對個資進行記錄、建檔、編輯、整理、儲存、修改、檢索、刪除、輸出、連結或內部傳送等行為
- **利用**：在蒐集目的範圍內或外，對個資進行使用、提供、國際傳輸等行為

**個資類型：**
- **直接識別**：姓名、身分證號、指紋等可直接識別個人的資料
- **間接識別**：出生年月日等需與其他資料組合才能識別的資料
- **特種個資**：病歷、醫療、基因、性生活、健康檢查及犯罪前科（依個資法第 6 條，原則上不得蒐集處理利用）

**去識別化方式：**
- **匿名化**：如「林○○」，不可還原
- **假名化**：如「A1234 代表林志祥」，可透過對照表還原

#### GDPR（歐盟一般資料保護規則）

**適用範圍（域外效力）：**
- 在歐盟境內設有據點的組織
- 雖不在歐盟境內，但有處理歐盟居民個資的組織

> 💡 台灣企業若有歐盟客戶、會員或員工，即使公司在台灣，仍須遵守 GDPR。

**重要規定：**
- 發現個資侵害事件後，須於 **72 小時內**向監管機關通報
- 違規罰款最高可達 **2,000 萬歐元**或企業年度全球總營業額的 **4%**（取較高者）

**當事人權利：**

| 權利 | 說明 |
|:-----|:-----|
| 存取權 | 查詢個資被如何使用 |
| 更正權 | 要求更正錯誤資料 |
| 刪除權（被遺忘權） | 要求刪除個人資料 |
| 可攜權 | 要求以通用格式取得個資 |
| 反對權 | 反對特定目的的資料處理 |

#### GDPR vs 台灣個資法比較

| 項目 | GDPR | 台灣個資法 |
|:-----|:-----|:-----------|
| 適用範圍 | 有域外效力 | 僅限台灣境內 |
| 通報時限 | 72 小時內 | 查明後通知，無明確時限 |
| 被遺忘權 | ✅ 可要求搜尋引擎移除連結 | ❌ 僅有刪除權，無法要求第三方移除 |
| 可攜權 | ✅ | ❌ |
| 罰款上限 | 2,000 萬歐元或營業額 4% | 最高 1,500 萬台幣 |
| 保護對象 | 自然人 | 自然人 |

> 💡 **被遺忘權 vs 刪除權**：
> - GDPR 被遺忘權：可要求蒐集機關「及第三方（如 Google）」刪除相關資料與連結
> - 台灣刪除權：僅能要求「蒐集機關」刪除，無法要求搜尋引擎移除

---

### 範例題目

> **Q：** ISO 27001資訊安全管理系統中，管理審查會議是屬於 PDCA 中的何項程序？
> - \(A\) 規畫(Plan)
> - \(B\) 執行(Do)
> - \(C\) 檢核(Check)
> - \(D\) 行動(Act)

<details>
<summary>查看答案</summary>

**\(C\) 檢核(Check)**

管理審查會議是高階管理層定期「檢視」ISMS 運作績效與有效性的活動，屬於 Check 階段。

</details>

---

> **Q：** 因應客戶的要求，貴公司擬導入個人資料保護的相關標準，因兩個月前您才幫公司完成 ISO 27001:2022 轉版驗證；為達最佳效益，試問您會建議公司導入下列何項認證標準？
> - \(A\) ISO 10012
> - \(B\) ISO 27701
> - \(C\) ISO 27017
> - \(D\) ISO 27018

<details>
<summary>查看答案</summary>

**\(B\) ISO 27701**

- **ISO 27701**：隱私資訊管理系統（PIMS），是 ISO 27001 的擴展標準，專門針對個人資料保護，可直接整合現有 ISMS
- ISO 10012：測量管理系統，與資安無關
- ISO 27017：雲端服務資訊安全控制指引
- ISO 27018：公有雲個資保護實務準則

已有 ISO 27001 基礎，導入 27701 可達到最佳效益。

</details>

---

> **Q：** 台灣某國際商業銀行為一家 Visa、MasterCard 等信用卡發卡銀行，為了確保持卡人的信用卡資訊及付款資料，能在安全可信的環境中處理、傳輸或儲存，進而建置國際公認且專屬信用卡資訊處理保護的管理制度。請問此制度的最有可能為下列何項？
> - \(A\) PCI DSS
> - \(B\) GDPR
> - \(C\) HIPAA
> - \(D\) Sarbanes-Oxley

<details>
<summary>查看答案</summary>

**\(A\) PCI DSS**

**PCI DSS**（Payment Card Industry Data Security Standard）是由 Visa、MasterCard 等國際信用卡組織共同制定的資料安全標準，專門規範信用卡資訊的處理、傳輸與儲存。

| 標準 | 用途 |
|------|------|
| PCI DSS | 信用卡資訊安全標準 |
| GDPR | 歐盟個人資料保護規則 |
| HIPAA | 美國醫療資訊保護法案 |
| Sarbanes-Oxley | 美國企業財務報告法規（沙賓法案） |

</details>

---

> **Q：** 下列何項與 GDPR（General Data Protection Regulation）規範的要求不符？
> - \(A\) GDPR 為歐盟一般資料保護法規
> - \(B\) 要求持有歐盟個人可識別資訊的組織，需實施安全控制措施以防止個人資料遺失
> - \(C\) 任何使用與歐盟居民相關資訊的組織都須遵循
> - \(D\) 僅規定位於歐盟地區的公司組織須遵守

<details>
<summary>查看答案</summary>

**\(D\) 不符**

GDPR 具有**域外效力**，不論組織是否位於歐盟境內，只要處理歐盟居民的個人資料，都必須遵守 GDPR 規範。

例如：台灣企業若有歐盟客戶資料，同樣需遵守 GDPR。

</details>

---

> **Q：** 請問下列何項屬於個人資料保護法第六條所規範，除符合特定情形，不得蒐集、處理或利用之個人資料？
> - \(A\) 姓名
> - \(B\) 職業
> - \(C\) 健康檢查的報告內容
> - \(D\) 國民身分證統一編號

<details>
<summary>查看答案</summary>

**\(C\) 健康檢查的報告內容**

個資法第六條規範的是「**特種個資**」，原則上不得蒐集、處理或利用：

| 特種個資類型 |
|:------------|
| 醫療 |
| 基因 |
| 性生活 |
| 健康檢查 |
| 犯罪前科 |
| 病歷 |

姓名、職業、身分證字號屬於「一般個資」，適用第六條以外的規範。

</details>

---

> **Q：** 對達成使用密碼技術的資訊安全目標，下列何項描述有誤？
> - \(A\) 機密性：使用資訊加密可以保護敏感資訊
> - \(B\) 完整性：使用數位簽章加密機制於檔案，以確保資料完整性傳遞
> - \(C\) 不可否認性：對資料使用密碼技術，以提供事故發生時存取相關的證據
> - \(D\) 可用性：使用密碼技術以鑑別使用者對資源存取異動時的證據

<details>
<summary>查看答案</summary>

**\(D\) 有誤**

選項 D 描述的是「**可歸責性（Accountability）**」，不是「可用性（Availability）」。

| 安全目標 | 密碼技術應用 |
|:--------:|:-------------|
| 機密性 | 加密保護敏感資訊 |
| 完整性 | 數位簽章、雜湊驗證 |
| 不可否認性 | 數位簽章提供證據 |
| 可歸責性 | 稽核軌跡追蹤存取行為 |
| 可用性 | 與密碼技術較無直接關係 |

> 💡 可用性主要透過備份、叢集、備援等機制達成，而非密碼技術。

</details>

---

> **Q：** 依據「資通安全事件通報及應變辦法」所訂定的資通安全事件之嚴重等級共有四類，如某一特定非公務機關判別某一個非核心資通系統之資訊遭受輕微竄改，則該事件之嚴重等級為下列哪一級？
> - \(A\) 第一級
> - \(B\) 第二級
> - \(C\) 第三級
> - \(D\) 第四級

<details>
<summary>查看答案</summary>

**\(A\) 第一級**

判斷關鍵：
- **非核心系統** → 影響較低
- **輕微竄改** → 損害程度輕微

| 等級 | 影響範圍 | 損害程度 |
|:----:|:---------|:---------|
| 第一級 | 非核心系統 | 輕微 |
| 第二級 | 核心系統或非核心系統 | 一般 |
| 第三級 | 核心系統 | 嚴重 |
| 第四級 | 核心系統 | 非常嚴重 |

</details>

---

> **Q：** 關於 CNS 27002:2023 國家標準，下列何項描述最為適切？
> - \(A\) 特定產業的資訊安全稽核標準
> - \(B\) 通用資訊安全控制措施的參考與實作指引
> - \(C\) 資訊安全事故的法律訴訟程序
> - \(D\) 雲端服務的防護模型

<details>
<summary>查看答案</summary>

**\(B\) 通用資訊安全控制措施的參考與實作指引**

CNS 27002 對應國際標準 ISO 27002，提供資訊安全控制措施的實作指引，適用於各類組織。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 非特定產業，是通用標準 |
| B | ✅ 控制措施的參考指引 |
| C | ❌ 與法律訴訟無關 |
| D | ❌ 雲端防護是 ISO 27017/27018 |

| 標準 | 說明 |
|:-----|:-----|
| ISO/CNS 27001 | ISMS 管理系統「要求」（可驗證） |
| ISO/CNS 27002 | 控制措施「指引」（參考用） |

> 💡 27001 是「要做什麼」，27002 是「怎麼做」。

</details>

---

> **Q：** 於保護資料之機密性、完整性與可用性描述，下列何項正確？
> - \(A\) 應用系統的可用性對組織而言，皆為同等級重要
> - \(B\) 公司內部員工的個人資訊，不在機密性的保護範圍
> - \(C\) 保護資料之機密性、完整性與可用性而言，機密性最為重要
> - \(D\) 組織之公開資訊對外公布時，資料的完整性需審查後再開放

<details>
<summary>查看答案</summary>

**\(D\) 組織之公開資訊對外公布時，資料的完整性需審查後再開放**

即使是公開資訊，仍須確保內容正確無誤（完整性），避免錯誤資訊對外發布。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 不同系統重要性不同，需依 BIA 評估 |
| B | ❌ 員工個資屬於機密資料，需保護 |
| C | ❌ CIA 三者無絕對優先順序，依資產性質決定 |
| D | ✅ 公開資訊仍需確保完整性 |

> 💡 **CIA 三要素沒有固定優先順序**：銀行重視完整性（帳務不能錯）、醫院重視可用性（系統不能停）、軍方重視機密性（資料不能洩）。

</details>

---

> **Q：** 有關資通安全演練作業類型的規定，是明定於《資通安全管理法》的哪一項子法？
> - \(A\) 資通安全責任等級分級辦法
> - \(B\) 資通安全管理法施行細則
> - \(C\) 資通安全情資分享辦法
> - \(D\) 資通安全事件通報及應變辦法

<details>
<summary>查看答案</summary>

**\(A\) 資通安全責任等級分級辦法**

資安演練作業（如社交工程演練、滲透測試等）的規定，是依據機關的責任等級來要求，因此規範於「資通安全責任等級分級辦法」。

| 子法 | 規範重點 |
|:-----|:---------|
| 資通安全責任等級分級辦法 | ✅ 分級、應辦事項、演練規定 |
| 資通安全事件通報及應變辦法 | 事件分級、通報時限 |
| 資通安全情資分享辦法 | 情資分享機制 |
| 資通安全管理法施行細則 | 母法條文解釋 |

</details>

---

> **Q：** 下列「資通安全管理法」的哪一項子法，有明確規範資通安全演練作業項目？
> - \(A\) 資通安全責任等級分級辦法
> - \(B\) 資通安全管理法施行細則
> - \(C\) 資通安全情資分享辦法
> - \(D\) 資通安全事件通報及應變辦法

<details>
<summary>查看答案</summary>

**\(A\) 資通安全責任等級分級辦法**

資安演練作業項目（如社交工程演練、滲透測試、營運持續演練等）依機關責任等級有不同要求，規範於「資通安全責任等級分級辦法」。

| 子法 | 規範重點 |
|:-----|:---------|
| 資通安全責任等級分級辦法 | ✅ 分級、應辦事項、演練規定 |
| 資通安全事件通報及應變辦法 | 事件分級、通報時限 |
| 資通安全情資分享辦法 | 情資分享機制 |
| 資通安全管理法施行細則 | 母法條文解釋 |

</details>

---

> **Q：** 依個人資料保護法對於個人資料之定義，下列何者「不」屬於個人資料的範疇？
> - \(A\) 社群帳號
> - \(B\) 指紋
> - \(C\) 性生活
> - \(D\) 公司統一編號

<details>
<summary>查看答案</summary>

**\(D\) 公司統一編號**

個資法保護的是「**自然人**」的個人資料，公司統一編號屬於「法人」資料，不在保護範疇。

| 選項 | 類型 | 屬於個資 |
|:----:|:-----|:--------:|
| A | 社群帳號（可識別個人） | ✅ |
| B | 指紋（生物特徵） | ✅ |
| C | 性生活（特種個資） | ✅ |
| D | 公司統一編號（法人資料） | ❌ |

> 💡 個資法僅保護「自然人」，法人（公司、機關、團體）不適用。

</details>

---

> **Q：** 下列何項驗證「不」是專門針對雲端機房的驗證制度？
> - \(A\) CSA STAR
> - \(B\) SOC 2
> - \(C\) ISO/IEC 27017
> - \(D\) ISO/IEC 27018

<details>
<summary>查看答案</summary>

**\(B\) SOC 2**

SOC 2 是針對服務組織的內部控制審計報告，適用於各種服務組織，不是專門針對雲端。

| 選項 | 說明 | 專門針對雲端 |
|:----:|:-----|:------------:|
| A | CSA STAR 雲端安全聯盟認證 | ✅ |
| B | SOC 2 服務組織控制報告 | ❌ |
| C | ISO 27017 雲端安全控制指引 | ✅ |
| D | ISO 27018 公有雲個資保護 | ✅ |

| 標準 | 適用範圍 |
|:-----|:---------|
| CSA STAR | 雲端服務供應商 |
| ISO 27017 | 雲端服務安全控制 |
| ISO 27018 | 公有雲個資保護 |
| SOC 2 | 各種服務組織（含雲端但不限於） |

</details>

---

> **Q：** 根據政府頒佈之資通安全事件通報及應變辦法，受資通安全管理法管制之機關（以下簡稱：受管制機關）進行資通安全事件應變及通報之敘述，下列何者有誤？
> - \(A\) 受管制機關知悉資通安全事件後，應於一小時內依主管機關指定之方式及對象，進行資通安全事件之通報
> - \(B\) 主管機關應於受管制機關完成資通安全事件之通報後，通報為第一級或第二級資通安全事件者，於接獲後八小時內完成資通安全事件等級之審核
> - \(C\) 主管機關應於受管制機關完成資通安全事件之通報後，通報為第三級或第四級資通安全事件者，於接獲後二小時內完成資通安全事件等級之審核
> - \(D\) 受管制機關知悉資通安全事件後，第三級或第四級資通安全事件，應於知悉該事件後七十二小時內完成損害控制或復原作業，並依主管機關指定之方式及對象辦理通知事宜

<details>
<summary>查看答案</summary>

**\(D\) 有誤**

第三級或第四級資通安全事件，應於知悉該事件後 **36 小時內**完成損害控制或復原作業，而非 72 小時。

| 事件等級 | 損害控制或復原時限 |
|:--------:|:------------------:|
| 第一級、第二級 | 72 小時內 |
| 第三級、第四級 | 36 小時內 |

</details>

---

## 1.2 資產與風險管理

### 1.2.1 資產分類分級與盤點

#### 資訊資產定義

資訊資產是指對組織具有價值的任何資訊或資源，其「價值」是以對組織的**業務衝擊**（CIA 影響）來評估，而非財務上的殘值或採購成本。

> ⚠️ 資訊資產 ≠ 資訊設備。資產範圍包含：人員、軟體、硬體、資料、文件、通訊設備、環境等。
> ⚠️ 考試常考辦公室桌椅算不算資訊資產，他是資產，但不是資訊資產。

#### 資產盤點流程

1. 清查所有資產
2. 確認資產擁有者
3. 評估資產價值
4. 定義保護等級
5. 建立盤點清冊

#### 資產分類

| 類型 | 英文 | 範例 |
|:-----|:-----|:-----|
| 人員資產 | People | 員工、承包商 |
| 通訊設備 | Communication Equipment | 路由器、交換器、電話系統 |
| 軟體資產 | Software | 作業系統、應用程式、資料庫 |
| 硬體資產 | Hardware | 伺服器、電腦、儲存設備 |
| 文件資產 | Documents | 合約、手冊、政策文件 |
| 資料資產 | Data | 客戶資料、財務報表、原始碼 |
| 環境資產 | Environment | 機房、辦公室、電力設施 |

#### 資產盤點內容範例

以人資系統伺服器為例：

| 項目 | 內容 | 說明 |
|------|------|------|
| 資產編號 | SRV-114-07-01 | SRV=設備類型、114=年度、07=月份、01=流水號 |
| 設備名稱 | SRHRAP01 | SR=伺服器、HR=人資、AP=應用系統、01=流水號 |
| 資產類別 | 伺服器 | |
| 資產區域 | 總部機房A | |
| 資產位置 | 機櫃A01 | |
| 網路位置 | 192.168.1.10 | |
| 作業系統 | Microsoft Windows Server 2025 Standard (繁體中文) | |
| 用途 | 人資系統服務使用 | |
| 權責單位 | 人力資源處 | |
| 管理單位 | 資訊處 | |
| 機密性評級 | 3 (中) | 有存取控制 |
| 完整性評級 | 5 (高) | 薪資資料不能錯 |
| 可用性評級 | 1 (低) | 可短暫中斷 |
| 法遵性評級 | 1 (低) | 無法規要求 |
| 資產價值 | 5 | 取 CIA和法遵(L)，四者最大值 |

#### 資料分級

| 等級 | 說明 | 範例 |
|------|------|------|
| 公開 (Public) | 可自由公開，不會造成損害 | 企業介紹、產品型錄 |
| 內部 (Internal) | 僅供內部使用，外洩影響輕微 | 內部通訊錄、作業程序 |
| 敏感 (Sensitive) | 限特定人員存取，外洩影響嚴重 | 客戶資料、財務報表 |
| 機密 (Confidential) | 最高機敏等級，外洩造成重大損害 | 商業機密、研發資料 |

#### 資料處理角色

- **資料所有者 (Data Owner)**：如人資系統主管，負責決定資料分級與存取權限
- **資料保管人 (Data Custodian)**：如資訊人員，負責技術面的資料保護
- **資料使用者 (Data User)**：全體員工，依所有者授權使用資料

#### 資料保護三態

| 狀態 | 英文 | 說明 | 保護方式 |
|:----:|:-----|:-----|:---------|
| 使用中 | Data in Use | 正在被處理、存取的資料 | 存取控制、DLP |
| 靜態 | Data at Rest | 儲存在硬碟、資料庫中的資料 | 加密、權限控管 |
| 傳輸中 | Data in Transit | 透過網路傳輸的資料 | TLS/SSL、VPN |

#### 資料銷毀

| 方法 | 英文 | 說明 | 安全等級 |
|:----:|:-----|:-----|:--------:|
| 清除 | Clearing | 軟體覆寫，防止簡單復原 | ⭐ |
| 清洗 | Purging | 消磁等方式，防止實驗室等級復原 | ⭐⭐ |
| 銷毀 | Destruction | 物理破壞（打爛、磨碎、焚燒） | ⭐⭐⭐ |

> 💡 **安全性排序**：銷毀 > 清洗 > 清除

---

### 1.2.2 風險評鑑與風險處理

#### 風險基本概念

當有價值的**資產**存在**脆弱點**並遭受**威脅**利用時，會對資產造成**衝擊**。依據**威脅事件**發生的**可能性**與**衝擊**程度，就會形成**風險**。透過實施**控制措施**，可將風險降低至**可接受風險**水準，控制後仍存在的部分稱為**殘餘風險**。

| 名詞 | 英文 | 定義 | 範例 |
|:-----|:-----|:-----|:-----|
| 資產 | Asset | 具價值之對象 | 客戶資料庫 |
| 脆弱點 | Vulnerability | 資產或環境的弱點（通常來自內部） | 未更新的伺服器、弱密碼 |
| 威脅 | Threat | 可能造成損害的潛在來源 | 駭客、員工疏失、地震 |
| 威脅事件 | Threat Event | 威脅成功利用脆弱點的情境 | 駭客入侵、員工誤刪資料 |
| 可能性 | Likelihood | 威脅事件發生的機率 | 高/中/低 或 百分比 |
| 衝擊 | Impact | 威脅事件對資產造成的損害程度 | 高/中/低 或 金額 |
| 風險 | Risk | 可能性 × 衝擊 | 風險值 = 3 × 4 = 12 |
| 控制措施 | Control | 為降低風險而採取的手段 | 安裝防火牆、定期備份 |
| 可接受風險 | Acceptable Risk | 組織願意承受的風險水準 | 風險值 ≤ 6 視為可接受 |
| 殘餘風險 | Residual Risk | 實施控制措施後仍存在的風險 | 裝了防火牆仍可能被入侵 |

> 💡 **衝擊程度與資產價值相關**：資產價值越高（CIA和法遵性 評級越高），遭受攻擊時的衝擊就越大。
> - 資產價值 = 機密性、完整性、可用性、法遵性評級**取最大值**
> - 範例：某系統 C=3、I=5、A=1、L=1，資產價值 = 5（高）

flowchart TB
    subgraph 風險要素
        A[📦 資產] -->|存在| V[🔓 脆弱點]
        T[⚡ 威脅] -->|利用| V
    end
    
    V --> TE[威脅事件]
    
    TE --> L[可能性]
    TE --> I[衝擊]
    
    L --> R[⚠️ 風險 = 可能性 × 衝擊]
    I --> R
    
    R -->|實施| C[🛡️ 控制措施]
    C --> RR[殘餘風險]

#### 風險值計算

| 方法 | 說明 | 表示方式 |
|:-----|:-----|:---------|
| 定性分析（Qualitative） | 依專家判斷評估 | 高/中/低 或 1~5 分 |
| 定量分析（Quantitative） | 依歷史數據計算 | 金額（ALE = ARO × SLE） |

**定量分析公式：**
- **ALE（年度預期損失）= ARO × SLE**
- ARO = 年發生率，SLE = 單次損失金額
- 範例：公司車每次修車花 5 萬（SLE），平均兩年發生一次（ARO=0.5），ALE = 5 萬 × 0.5 = 2.5 萬/年

> 💡 **定性分析**：高/中/低 或 1~5 分都是定性方法，風險矩陣就是定性分析的應用。

#### 風險管理流程

> 💡 **口訣**：**識別 → 分析 → 評估 → 處理**（循環進行，非一次性）


> 感謝高點金乃傑(魏取向)老師上課方法

**1. 建立全景（Establishing Context）**
- 了解組織內外部環境
- 確定風險管理目標與準則
- 定義評估範圍

**2. 風險評鑑（Risk Assessment）**

| 階段 | 工作內容 |
|:-----|:---------|
| 風險識別 | 識別資產、威脅、脆弱點、現有控制措施、潛在影響 |
| 風險分析 | 估算發生可能性、評估衝擊程度、計算風險值 |
| 風險評估 | 與可接受風險比較，判斷處理優先順序 |

**可能性評估基準：**

| 等級 | 分數 | 說明 |
|:-----|:----:|:-----|
| 極低 | 1 | 幾乎不可能發生（數年一次） |
| 低 | 2 | 不太可能發生（每年一次） |
| 中 | 3 | 可能發生（每季一次） |
| 高 | 4 | 很可能發生（每月一次） |
| 極高 | 5 | 幾乎確定發生（每週或每天） |

**衝擊評估基準：**

| 等級 | 分數 | 說明 |
|:-----|:----:|:-----|
| 極低 | 1 | 輕微不便，無財務損失 |
| 低 | 2 | 小額財務損失，影響可忽略 |
| 中 | 3 | 中度財務損失，部分業務受影響 |
| 高 | 4 | 重大財務損失，商譽受損 |
| 極高 | 5 | 組織存亡危機，人命安全 |

**風險矩陣（Risk Matrix）：**

| 可能性➡️ <br> 衝擊⬇️ | 1 | 2 | 3 | 4 | 5 |
|:--------------|:--:|:--:|:--:|:--:|:--:|
| **5** | 🟢 5 | 🟡 10 | 🔴 15 | 🔴 20 | 🔥 25 |
| **4** | 🟢 4 | 🟡 8 | 🟡 12 | 🔴 16 | 🔴 20 |
| **3** | 🟢 3 | 🟢 6 | 🟡 9 | 🟡 12 | 🔴 15 |
| **2** | 🟢 2 | 🟢 4 | 🟢 6 | 🟡 8 | 🟡 10 |
| **1** | 🟢 1 | 🟢 2 | 🟢 3 | 🟢 4 | 🟢 5 |

| 風險等級 | 風險值 | 處理方式 |
|:---------|:------:|:---------|
| 🟢 低風險 | 1~6 | 可接受，持續監控 |
| 🟡 中風險 | 7~12 | 應處理，排定時程 |
| 🔴 高風險 | 13~20 | 優先處理 |
| 🔥 極高風險 | 21~25 | 立即處理 |

> 💡 **風險容忍度**：組織願意承受的風險水準，由**高階管理層**決定，每個產業不同例如新創公司風險容忍度高，金融業風險容忍度低。
> - 風險 > 容忍度 → 必須處理
> - 風險 ≤ 容忍度 → 可以接受

**3. 風險處理（Risk Treatment）**

| 處理方式 | 英文 | 別名 | 說明 | 範例 |
|:---------|:-----|:-----|:-----|:-----|
| 風險避免 | Risk Avoidance | - | 停止該業務或活動 | 不再提供高風險服務 |
| 風險降低 | Risk Reduction | 風險修改（Risk Modification）<br>風險緩解（Mitigation） | 實施控制措施降低風險，**最常見** | 安裝防火牆 |
| 風險轉移 | Risk Transfer | 風險分擔（Risk Sharing） | 將風險轉移給第三方 | 購買保險、外包 |
| 風險保留 | Risk Retention | 風險接受（Risk Acceptance） | 接受風險，不採取行動 | 風險成本低於控制成本時 |

**4. 監控審查與溝通諮詢**
- 持續監控風險變化
- 定期審查風險管理流程
- 與利害關係人保持溝通

---

### 範例考題

> **Q：** 某組織在進行資訊資產分類及保護的過程中，會明定不同角色人員以確保其功能與職責，一般常見為稱擁有者（Owner）、保管者（Custodian）、使用者（User）、稽核員（Auditor），參考 CNS 27002:2023 對資產擁有者的相關職掌項目定義後，請問下列何項最可能「非」屬擁有者必要負責之工作事項？
> - \(A\) 確保已對系統、資訊及其他相關聯資產完成盤點
> - \(B\) 確保將資訊及其他相關聯資產適切分類分級並保護之
> - \(C\) 確保資產以最低成本進行採購
> - \(D\) 確保資訊及其他相關聯資產於刪除或棄置時，以安全方式處理

<details>
<summary>查看答案</summary>

**\(C\) 確保資產以最低成本進行採購**

資產擁有者的職責著重於**資訊安全管理**，而非成本控制。依 CNS 27002:2023，擁有者應負責：

| 擁有者職責 |
|:----------|
| 資產盤點 |
| 分類分級與保護 |
| 定義存取控制 |
| 定期審查 |
| 安全處置與棄置 |

採購成本屬於財務或採購部門的職責，非資產擁有者的資安職掌。

</details>

---

> **Q：** 有關 NIST 定義資料生命週期的資料運用狀況，依方式和時間點不同而有不同狀態。請問，當資料在非永久性儲存硬體、應用軟體等情境時，如 RAM、CPU、DLP Agent，可將其歸類於下列何狀態？
> - \(A\) Data in use
> - \(B\) Data on the fly
> - \(C\) Data in motion
> - \(D\) Data at rest

<details>
<summary>查看答案</summary>

**\(A\) Data in use**

資料在 RAM、CPU 等非永久性儲存媒體中被處理時，屬於「使用中」狀態。

| 狀態 | 說明 | 範例 |
|:----:|:-----|:-----|
| Data in Use | 正在被處理、存取的資料 | RAM、CPU、應用程式記憶體 |
| Data in Motion / Transit | 透過網路傳輸中的資料 | 網路封包、Email 傳送中 |
| Data at Rest | 儲存於永久性媒體的資料 | 硬碟、資料庫、備份磁帶 |

> 💡 Data on the fly 與 Data in motion 同義，皆指傳輸中的資料。

</details>

---

> **Q：** 風險評鑑發現，公司內部機密外洩的風險過大；資訊單位導入資料外洩防護（DLP）系統做為因應措施，請問資訊單位的做法是屬於下列何種風險回應？
> - \(A\) 風險保留（Risk Retention）
> - \(B\) 風險避免（Risk Avoidance）
> - \(C\) 風險降低（Risk Reduction）
> - \(D\) 風險轉移（Risk Transfer）

<details>
<summary>查看答案</summary>

**\(C\) 風險降低（Risk Reduction）**

導入 DLP 系統是實施控制措施來降低風險發生的可能性或衝擊。

| 風險回應 | 英文 | 說明 | 範例 |
|:--------:|:-----|:-----|:-----|
| 風險降低 | Risk Reduction | 實施控制措施降低風險 | 導入 DLP、防火牆、加密 |
| 風險避免 | Risk Avoidance | 停止產生風險的活動 | 不再提供某項服務 |
| 風險轉移 | Risk Transfer | 將風險轉嫁給第三方 | 購買保險、外包 |
| 風險保留 | Risk Retention | 接受風險，不採取行動 | 風險成本低於控制成本時 |

</details>

---

> **Q：** 關於風險管理循環執行順序的描述，下列何者較為正確？
> - \(A\) 風險識別 ＞ 風險處理 ＞ 風險分析 ＞ 風險評估
> - \(B\) 風險評估 ＞ 風險識別 ＞ 風險處理 ＞ 風險分析
> - \(C\) 風險處理 ＞ 風險識別 ＞ 風險分析 ＞ 風險評估
> - \(D\) 風險識別 ＞ 風險分析 ＞ 風險評估 ＞ 風險處理

<details>
<summary>查看答案</summary>

**\(D\) 風險識別 ＞ 風險分析 ＞ 風險評估 ＞ 風險處理**

依據 ISO 31000 風險管理標準，正確順序為：

| 順序 | 階段 | 英文 | 說明 |
|:----:|:----:|:-----|:-----|
| 1 | 風險識別 | Risk Identification | 找出潛在風險有哪些 |
| 2 | 風險分析 | Risk Analysis | 分析風險的可能性與衝擊 |
| 3 | 風險評估 | Risk Evaluation | 決定風險優先順序 |
| 4 | 風險處理 | Risk Treatment | 選擇並實施風險回應措施 |

> 💡 口訣：**識分評處**（先認識、再分析、後評估、最後處理）

</details>

---

> **Q：** 當企業需要永久刪除機密資料，使用下列何種方法處置最為安全？
> - \(A\) 在作業系統中刪除檔案並清空資源回收筒
> - \(B\) 對硬碟使用標準格式化
> - \(C\) 使用資料覆寫工具或物理銷毀
> - \(D\) 將硬碟存放於安全的地方以防止存取

<details>
<summary>查看答案</summary>

**\(C\) 使用資料覆寫工具或物理銷毀**

永久刪除機密資料需使用覆寫工具（清洗）或物理銷毀，一般刪除與格式化都可被復原。

| 選項 | 方法 | 安全性 |
|:----:|:-----|:------:|
| A | 刪除檔案 | ❌ 可輕易復原 |
| B | 標準格式化 | ❌ 可透過工具復原 |
| C | 覆寫或物理銷毀 | ✅ 最安全 |
| D | 實體保管 | ❌ 資料仍存在，有外洩風險 |

| 銷毀方法 | 說明 | 安全等級 |
|:---------|:-----|:--------:|
| 清除（Clearing） | 軟體覆寫 | ⭐ |
| 清洗（Purging） | 消磁或多次覆寫 | ⭐⭐ |
| 銷毀（Destruction） | 物理破壞 | ⭐⭐⭐ |

</details>

---

> **Q：** 下列何項「不」屬於資訊資產分類時需考量的依據？
> - \(A\) 鑑別性
> - \(B\) 可用性
> - \(C\) 完整性
> - \(D\) 機密性

<details>
<summary>查看答案</summary>

**\(A\) 鑑別性**

資訊資產分類分級是依據 **CIA 三要素**（機密性、完整性、可用性）來評估資產價值，「鑑別性」不是標準評估依據。

| 選項 | CIA 三要素 | 資產分類依據 |
|:----:|:----------:|:------------:|
| A | ❌ | ❌ |
| B | ✅ 可用性 | ✅ |
| C | ✅ 完整性 | ✅ |
| D | ✅ 機密性 | ✅ |

> 💡 資產價值 = 取 CIA 三者評級的最大值。例如：機密性 2、完整性 3、可用性 1，則資產價值為 3。

</details>

---

> **Q：** 資訊資產管理中要求對每項資產指定一位「資產擁有者」，該人員指的是下列何項？
> - \(A\) 實際使用該資產的人或部門
> - \(B\) 對資產提供技術支援的人或部門
> - \(C\) 決定是否採購資產的人或部門
> - \(D\) 對資產負有管理責任的人或部門

<details>
<summary>查看答案</summary>

**\(D\) 對資產負有管理責任的人或部門**

資產擁有者是對資產負有「管理責任」的人，負責決定分級、存取權限、保護措施等。

| 選項 | 角色 |
|:----:|:-----|
| A | 資料使用者（Data User） |
| B | 資料保管人（Data Custodian） |
| C | 採購人員（非資安角色） |
| D | ✅ 資產擁有者（Data Owner） |

| 角色 | 職責 |
|:-----|:-----|
| 資產擁有者 | 決定分級、授權、保護措施，負管理責任 |
| 資產保管人 | 技術面保護（如備份、維護） |
| 資產使用者 | 依授權使用資產 |

</details>

---

> **Q：** 關於資訊資產盤點作業的描述，下列何者最「不」適當？
> - \(A\) 資訊資產盤點即是資訊設備盤點
> - \(B\) 資訊資產盤點在確認資產的殘值
> - \(C\) 資訊資產盤點應考量全面性
> - \(D\) 資訊資產盤點應確認資產的可用性

<details>
<summary>查看答案</summary>

**\(B\) 資訊資產盤點在確認資產的殘值**

資訊資產的「價值」是以對組織的業務衝擊（CIA）評估，而非財務上的「殘值」。

| 選項 | 說明 |
|:----:|:-----|
| A | ⚠️ 不完全正確，資產不只設備，但至少是部分正確 |
| B | ❌ 最不適當，殘值是財務概念，與資安盤點無關 |
| C | ✅ 盤點應全面涵蓋所有資產類型 |
| D | ✅ 應確認資產的可用性狀態 |

| 概念 | 說明 |
|:-----|:-----|
| 資訊資產價值 | 依 CIA 衝擊評估對組織的重要性 |
| 財務殘值 | 資產扣除折舊後的帳面金額 |

> 💡 資訊資產盤點的目的是**識別、分類、評估資產重要性**，作為風險評鑑的基礎。

</details>

---

> **Q：** 下列何種「不」是風險處理的策略之一？
> - \(A\) 風險降低（Risk Reduction）
> - \(B\) 風險避免（Risk Avoidance）
> - \(C\) 風險轉移（Risk Transfer）
> - \(D\) 風險拒絕（Risk Reject）

<details>
<summary>查看答案</summary>

**\(D\) 風險拒絕（Risk Reject）**

「風險拒絕」不是正式的風險處理策略。正確的四種策略為：

| 處理方式 | 英文 | 說明 |
|:---------|:-----|:-----|
| 風險避免 | Risk Avoidance | 停止產生風險的活動 |
| 風險降低 | Risk Reduction | 實施控制措施降低風險 |
| 風險轉移 | Risk Transfer | 將風險轉嫁給第三方 |
| 風險保留 | Risk Retention | 接受風險，不採取行動 |

> ⚠️ 沒有「風險拒絕」這個選項，可能混淆的是「風險保留（Risk Retention）」或「風險接受（Risk Acceptance）」。

</details>

---

> **Q：** 關於資通安全風險處理內容的描述，下列何者較為正確？
> - \(A\) 風險保留（Risk Retention）是組織避免接受任何風險的做法，確保避開所有可能對組織產生負面影響的風險
> - \(B\) 風險修改（Risk Modification）是指組織不對風險採取任何行動，接受風險的存在並準備承擔其後果
> - \(C\) 風險分擔（Risk Sharing）是透過與其他組織或他方分享風險來分散風險，例如透過保險或委外來達成
> - \(D\) 風險避免（Risk Avoidance）是指組織採取措施主動減少風險的可能性和影響，例如通過技術改進或政策更新

<details>
<summary>查看答案</summary>

**\(C\) 風險分擔（Risk Sharing）是透過與其他組織或他方分享風險來分散風險，例如透過保險或委外來達成**

各選項的錯誤分析：

| 選項 | 敘述的定義 | 實際定義 |
|:----:|:-----------|:---------|
| A | 避免接受任何風險 | ❌ 風險保留是「接受」風險 |
| B | 不採取任何行動 | ❌ 風險修改是「採取措施降低」風險 |
| C | 與他方分享風險 | ✅ 正確 |
| D | 採取措施減少風險 | ❌ 這是「風險降低」的定義，風險避免是「停止活動」 |

| 術語 | 別名 | 定義 |
|:-----|:-----|:-----|
| 風險保留 | 風險接受 | 接受風險存在 |
| 風險修改 | 風險降低 | 實施控制措施 |
| 風險分擔 | 風險轉移 | 轉嫁給第三方 |
| 風險避免 | - | 停止產生風險的活動 |

</details>

---

> **Q：** 風險處理活動是依照風險評鑑結果及實作風險處理方案之預期成本及預期利益等，選擇適當之行動方案，以使風險之不利後果能合理的降低，風險處理活動之選項主要有風險修改（Risk Modification）、風險保留（Risk Retention）、風險避免（Risk Avoidance）及風險分擔（Risk Sharing）等 4 種。請問下列何種情境最適合運用「風險分擔」來處理？
> - \(A\) 電腦機房的滅火設施老舊
> - \(B\) 座落於洪災頻繁區域的機房大樓
> - \(C\) 隨身碟遺失的可能性
> - \(D\) 滿腹牢騷的員工所造成蓄意破壞的威脅

<details>
<summary>查看答案</summary>

**\(B\) 座落於洪災頻繁區域的機房大樓**

天災是組織難以控制的外部風險，最適合透過保險等方式「分擔/轉移」風險。

| 選項 | 風險類型 | 適合處理方式 |
|:----:|:---------|:-------------|
| A | 設備老舊 | 風險修改（更換設備） |
| B | 天災風險 | ✅ 風險分擔（購買保險） |
| C | 人為疏失 | 風險修改（加密、管理措施） |
| D | 內部威脅 | 風險修改（改善管理、監控） |

> 💡 **風險分擔/轉移**適用情境：組織難以控制的風險（如天災）、損失金額巨大但發生機率低的風險。

</details>

---

> **Q：** 在工控資安的風險管理流程中，下列何者屬於風險處理（Risk Treatment）的措施？
> - \(A\) 識別 PLC 與 SCADA 系統清單
> - \(B\) 決定是否採取風險接受、風險降低、風險轉移或風險避免等措施
> - \(C\) 建立風險矩陣並評分
> - \(D\) 召開資產盤點會議

<details>
<summary>查看答案</summary>

**\(B\) 決定是否採取風險接受、風險降低、風險轉移或風險避免等措施**

風險處理是選擇並實施風險回應措施的階段。

| 選項 | 對應階段 |
|:----:|:---------|
| A | 風險識別（識別資產） |
| B | ✅ 風險處理 |
| C | 風險分析/評估（計算風險值） |
| D | 風險識別（資產盤點） |

| 階段 | 工作內容 |
|:-----|:---------|
| 風險識別 | 盤點資產、識別威脅與脆弱點 |
| 風險分析 | 評估可能性與衝擊、計算風險值 |
| 風險評估 | 建立風險矩陣、決定優先順序 |
| 風險處理 | 選擇回應措施（避免/降低/轉移/接受） |

</details>

---

> **Q：** 你是一位電子商務公司的資安管理人員，經由外部資安廠商進行評估後發現其公司電子商務網站存在 SQL 注入（SQL Injection）漏洞。駭客可以利用此漏洞竊取大量客戶資料，導致企業形象及名譽的受損，也需要負責法律上的責任。上述內容的「脆弱性」（Vulnerability）為下列何項？
> - \(A\) 網站存在 SQL 注入漏洞
> - \(B\) 客戶資料外洩
> - \(C\) 企業形象及名譽的受損
> - \(D\) 駭客（惡意攻擊者）

<details>
<summary>查看答案</summary>

**\(A\) 網站存在 SQL 注入漏洞**

脆弱點是資產或系統本身存在的弱點，可被威脅利用造成損害。

| 選項 | 風險要素 |
|:----:|:---------|
| A | ✅ 脆弱點（Vulnerability） |
| B | 衝擊/影響（Impact） |
| C | 衝擊/影響（Impact） |
| D | 威脅（Threat） |

| 風險要素 | 定義 | 本題對應 |
|:---------|:-----|:---------|
| 資產 | 具價值之對象 | 客戶資料、電商網站 |
| 脆弱點 | 系統或環境的弱點 | SQL 注入漏洞 |
| 威脅 | 可能利用脆弱點的事件或來源 | 駭客 |
| 衝擊 | 威脅發生後造成的損害 | 資料外洩、名譽受損 |

</details>

---

## 1.3 存取控制、加解密與金鑰管理

### 1.3.1 存取控制與身份認證

#### 存取控制四要素 (IAAA)

| 要素 | 說明 | 範例 |
|------|------|------|
| 識別 (Identification) | 用戶宣稱自己是誰 | 輸入使用者帳號 |
| 認證 (Authentication) | 驗證身分是否屬實 | 輸入密碼、指紋辨識 |
| 授權 (Authorization) | 決定可存取哪些資源 | 依角色給予權限 |
| 紀錄 (Accounting) | 記錄存取行為供稽核 | 系統日誌 |

> 💡 IAAA vs AAA：AAA為考試常考，IAAA 多了 識別(Identification)，是更完整的存取控制流程。

#### 認證方式

| 類型 | 說明 | 範例 |
|------|------|------|
| 所知之事 (Something you know) | 你知道的資訊 | 密碼、PIN 碼 |
| 所持之物 (Something you have) | 你擁有的物品 | 卡片、手機、Token |
| 所具之形 (Something you are) | 你的生物特徵 | 指紋、虹膜、臉型 |
| 多因子認證 (MFA) | 結合上述兩種以上 | 密碼 + 手機 OTP |

#### 單一登入 (SSO, Single Sign On)

| 項目 | 說明 |
|:-----|:-----|
| 定義 | 使用者只需登入一次，即可存取多個已授權的系統 |
| 優點 | 減少密碼數量、提升使用者體驗、降低忘記密碼機率 |
| 缺點 | 單點失敗風險（SSO 故障則全部系統無法登入） |
| 常見協定 | SAML、OAuth 2.0、OpenID Connect、Kerberos |

> ⚠️ **SSO 不是密碼記憶工具**：SSO 是透過信任機制讓多系統共享認證狀態，而非單純記住密碼。

#### FIDO（Fast Identity Online）無密碼認證

| 項目 | 說明 |
|:-----|:-----|
| 定義 | 無密碼登入解決方案，基於公開金鑰加密架構 |
| 核心特色 | 伺服器端只保存公鑰，私鑰留在用戶裝置，降低個資外洩風險 |
| 驗證方式 | 結合 MFA 與生物辨識（指紋、臉部、PIN 碼等） |

**FIDO 三大協議：**

| 協議 | 說明 |
|:-----|:-----|
| FIDO UAF | 無密碼驗證（Passwordless），使用生物辨識 |
| FIDO U2F | 第二因素驗證（2FA），搭配實體安全金鑰 |
| FIDO2 | 最新標準，整合 WebAuthn + CTAP，支援網頁瀏覽器 |

> 💡 **台灣金融 FIDO**：用戶於金融機構開通後，可用手機生物辨識取代金融卡進行身分驗證。

#### 生物辨識錯誤類型


| 類型 | 說明 | 影響 |
|------|------|------|
| FRR (誤殺率) | 拒絕合法使用者 | 抱怨上升，但風險較低 |
| FAR (誤放率) | 接受非法使用者 | 資產被盜，風險較高 |
| CER (交叉錯誤率) | FAR 與 FRR 的交叉點 | 系統最佳平衡點 |


#### 存取控制核心概念

| 角色 | 英文 | 定義 | 範例 | 關鍵字 |
|:-----|:-----|:-----|:-----|:-------|
| 主體 | Subject | **主動**發起請求的實體 | 使用者、程式、程序 | 發起者 |
| 客體 | Object | **被動**接受請求的實體 | 檔案、資料庫、印表機 | 資源 |
| 規則 | Rule | 判斷主體能否存取客體的指令 | 防火牆規則、ACL | 政策 |

> 💡 考試常考「誰是主動？誰是被動？」，記住：**主體發起、客體被存取**。

graph LR
    Sub[主體 Subject - 主動]
    Obj[客體 Object - 被動]
    Rule{規則 Rule - 守門員}
    
    Sub -->|Request| Rule
    Rule -->|Allow| Obj
    Rule -.->|Deny| Sub
    
    style Sub fill:#e1f5fe,stroke:#01579b,stroke-width:2px
    style Obj fill:#fff9c4,stroke:#fbc02d,stroke-width:2px
    style Rule fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

---

#### 授權模型

| 模型 | 說明 | 範例 |
|:-----|:-----|:-----|
| DAC（自由存取控制） | 資源擁有者決定權限 | Windows 檔案權限 |
| MAC（強制存取控制） | 系統強制執行，無法修改 | SELinux |
| RBAC（角色存取控制） | 依角色群組給予權限（管理常用） | 業務人員加入業務群組 |
| ABAC（屬性存取控制） | 依多種動態屬性決定授權（雲端常用） | 時間、地點、設備狀態 |

> 💡 **RBAC vs ABAC**：RBAC 依「角色」授權，ABAC 可依「主體、客體、環境」等多種屬性動態授權，更適合零信任架構。

#### 存取控制原則

| 原則 | 說明 |
|------|------|
| 職責區隔 (SOD) | 同一業務由不同人負責 <br> 如開發與上版人員分開 |
| 最小權限 (PoLP) | 只給予工作所需的最小權限 <br> 如操作員只需要開關機就不用給他修改檔案權限 |
| 僅知原則 (Need to Know) | 只能接觸工作所需資訊 <br> 如主治醫生也只能看自己病人病歷 |
| 職務輪調 (Job Rotation) | 定期調動職務，避免單人長期掌握 <br> 如銀行經理每五年定期輪調分行 |
| 強制休假 (Mandatory Leave) | 休假期間由他人代理，可發現異常 <br> 如突然給你一星期的假也不能使用公司系統 |
| 雙人控制 (Dual Control) | 重要操作需兩人以上 <br> 如金庫雙鑰匙 |
| 縱深防禦 (Defense in Depth) | 多層防護（實體、技術、管理），不依賴單一控制 <br> 如就算駭客取得權限，執行也要主管放行 |

---

### 1.3.2 加解密與金鑰生命週期

#### 密碼學基礎概念

| 名詞 | 英文 | 說明 |
|:-----|:-----|:-----|
| 明文 | Plaintext | 原始可讀的資料 |
| 密文 | Ciphertext | 加密後無法讀取的資料 |
| 加密 | Encryption | 將明文轉換為密文 |
| 解密 | Decryption | 將密文還原為明文 |
| 金鑰 | Key | 加解密過程中使用的秘密參數 |

flowchart LR
    P1[📄 明文] -->|🔐 加密 + 金鑰| C[🔒 密文]
    C -->|🔓 解密 + 金鑰| P2[📄 明文]

> 💡 **密碼學目的**：確保資料在傳輸或儲存過程中，即使被截取也無法被解讀。

#### 科克霍夫原則 (Kerckhoffs's principle)

即使加密算法是公開的，只要密鑰足夠保密且難以破解，系統仍然是安全的。

#### 加密技術比較

| 類型 | 對稱加密 | 非對稱加密 |
|------|----------|------------|
| 金鑰 | 加解密使用相同金鑰 | 公鑰加密、私鑰解密 |
| 速度 | 快 | 慢 |
| 金鑰數量 | N(N-1)/2 | 2N |
| 安全演算法 | AES | RSA、ECC |
| 不安全演算法 | DES | - |
| 用途 | 大量資料加密 | 金鑰交換、數位簽章 |

#### 非對稱加密應用場景

| 操作 | 使用金鑰 | 達成目標 (CIA) | 潛在風險 (考試重點) |
|:-----|:---------|:---------|:---|
| **公鑰加密** | 接收方公鑰 → 接收方私鑰 | **機密性** | 無法確認是誰寄的 (任何人都有公鑰) |
| **私鑰加密** | 發送方私鑰 → 發送方公鑰 | **真實性、不可否認性** | **若無搭配雜湊，無法偵測內容是否被篡改** |

> 💡 **觀念釐清：**
> * **私鑰** 證明「是誰寄的」（來源）。
> * **雜湊** 證明「沒被改過」（內容）。
> * **數位簽章** = 私鑰 + 雜湊 = **來源沒錯 且 內容沒錯**（這才是完美的不可否認性）。

#### 金鑰類型

| 名詞 | 別稱 | 用於 | 說明 |
|:-----|:-----|:-----|:-----|
| 秘密金鑰（Secret Key） | 對稱金鑰、共享金鑰 | 對稱加密 | 加解密使用同一把金鑰 |
| 公開金鑰（Public Key） | 公鑰 | 非對稱加密 | 可公開，用於加密或驗章 |
| 私密金鑰（Private Key） | 私鑰 | 非對稱加密 | 須保密，用於解密或簽章 |

> 💡 **考試陷阱**：看到「Secret Key」不要以為是私鑰，它是對稱加密的「秘密金鑰」！

#### 雜湊與編碼

| 類型 | 特性 | 用途 | 安全演算法 | 不安全演算法 |
|------|------|------|------------|--------------|
| 雜湊 | 不可逆、固定長度輸出 | 完整性驗證、密碼儲存 | SHA-2、SHA-3 | MD5、SHA-1 |
| 編碼 | 可逆、無機密性 | 資料格式轉換 | Base64 | - |

> 💡 **彩虹表攻擊防護**：在雜湊前加入隨機「鹽值 (Salt)」，即使相同密碼也會產生不同雜湊值。
> 💡 常考編碼是不是加密，答案是編碼不是加密，比較像語言翻譯過而已。

#### HMAC（訊息驗證碼）

| 項目 | 說明 |
|:-----|:-----|
| 全名 | Hash-based Message Authentication Code |
| 原理 | 雜湊函數 + 共享密鑰 |
| 驗證完整性 | ✅ 訊息未被篡改 |
| 驗證真實性 | ✅ 訊息來自擁有密鑰的人 |
| 提供機密性 | ❌ 訊息仍是明文 |

| 比較 | 雜湊 | HMAC |
|:-----|:-----|:-----|
| 輸入 | 訊息 | 訊息 + 密鑰 |
| 驗證完整性 | ✅ | ✅ |
| 驗證真實性 | ❌ | ✅ |

> 💡 **雜湊 vs HMAC**：雜湊只能驗證「沒被改過」，HMAC 還能驗證「來自正確的人」。

**共享密鑰的產生方式：**

| 方式 | 說明 | 範例 |
|:-----|:-----|:-----|
| 事先約定 | 雙方線下交換密鑰 | API Key、預設金鑰 |
| 密鑰交換協定 | 透過演算法安全協商 | Diffie-Hellman |
| TLS 握手 | 在加密通道建立時協商 | HTTPS 連線 |

### 數位安全機制

#### 數位簽章（Digital Signature）

**特性**：真實性、完整性、不可否認性
**缺點**：❌ 無機密性（文件是明文）

flowchart LR
    subgraph 發送方
        M1[📄 文件] --> H1[#️⃣ 雜湊]
        H1 --> D1[📝 訊息摘要]
        D1 --> E1[🔐 私鑰加密]
        E1 --> S[✍️ 數位簽章]
    end
    
    M1 -->|傳送| M2[📄 文件]
    S -->|傳送| S2[✍️ 數位簽章]
    
    subgraph 接收方
        M2 --> H2[#️⃣ 雜湊]
        H2 --> D2[📝 訊息摘要 A]
        S2 --> E2[🔓 公鑰解密]
        E2 --> D3[📝 訊息摘要 B]
        D2 --> CMP{比對}
        D3 --> CMP
        CMP -->|相同| OK[✅ 驗證成功]
        CMP -->|不同| FAIL[❌ 驗證失敗]
    end

> 💡 **私鑰簽章、公鑰驗章**：只有擁有私鑰的人能簽章，任何人都能用公鑰驗證。

---

#### 數位信封（Digital Envelope）

**特性**：機密性
**缺點**：❌ 無完整性驗證

flowchart LR
    subgraph 發送方
        M1[📄 明文] --> E1[🔐 對稱加密]
        K1[🔑 對稱金鑰] --> E1
        E1 --> C[🔒 密文]
        K1 --> E2[🔐 公鑰加密]
        PK[🔑 接收方公鑰] --> E2
        E2 --> EK[🔒 加密的金鑰]
    end
    
    C -->|傳送| C2[🔒 密文]
    EK -->|傳送| EK2[🔒 加密的金鑰]
    
    subgraph 接收方
        EK2 --> D1[🔓 私鑰解密]
        SK[🔑 接收方私鑰] --> D1
        D1 --> K2[🔑 對稱金鑰]
        C2 --> D2[🔓 對稱解密]
        K2 --> D2
        D2 --> M2[📄 明文]
    end

> 💡 **結合兩種加密優點**：對稱加密快速處理大量資料，非對稱加密安全交換金鑰。

---

#### 數位憑證（Digital Certificate）

**特性**：驗證公鑰擁有者身分

**PKI 架構：**

| 角色 | 英文 | 功能 |
|:-----|:-----|:-----|
| RA | Registration Authority | 註冊中心，身分認證、審查申請 |
| CA | Certificate Authority | 憑證機構，發行憑證、管理生命週期 |
| VA | Validation Authority | 驗證中心，驗證憑證狀態 |

flowchart TB
    subgraph PKI架構
        User[👤 使用者] -->|申請| RA[📋 RA 註冊中心]
        RA -->|審核通過| CA[🏛️ CA 憑證機構]
        CA -->|簽發憑證| Cert[📜 數位憑證]
        Cert -->|發給| User
    end
    
    subgraph 憑證驗證
        Verifier[🔍 驗證方] -->|查詢狀態| VA[✅ VA 驗證中心]
        VA -->|CRL/OCSP| Result{有效?}
    end

**憑證鏈（Certificate Chain）：**

🏛️ 根憑證（Root CA）
    └── 📜 中繼憑證（Intermediate CA）
            └── 📄 使用者憑證（End Entity）

> ⚠️ **任一層憑證無效，整條憑證鏈都無效。**

**憑證撤銷查詢：**

| 方式 | 說明 | 特性 |
|:-----|:-----|:-----|
| CRL | Certificate Revocation List | 下載完整撤銷清單，離線查詢 |
| OCSP | Online Certificate Status Protocol | 線上即時查詢單筆憑證狀態 |

---

#### 實務應用：三者混搭

flowchart TB
    M[📄 原始文件] --> DS[✍️ 數位簽章]
    DS --> DE[📦 數位信封]
    DE --> DC[📜 數位憑證驗證身分]
    
    DC --> R[✅ 達成 CIA + 不可否認性]

| 機制 | 達成目標 |
|:-----|:---------|
| 數位簽章 | 完整性、真實性、不可否認性 |
| 數位信封 | 機密性 |
| 數位憑證 | 驗證公鑰擁有者身分 |
| **三者結合** | **機密性 + 完整性 + 真實性 + 不可否認性** |

> 💡 **實務上混搭使用**：數位憑證驗證身分 + 數位信封保護內容 + 數位簽章確保不可否認，達到完整的安全防護。

#### 數位憑證內容

| 欄位 | 說明 |
|:-----|:-----|
| 版本 | 憑證格式版本（通常為 X.509 v3） |
| 序號 | CA 發行的唯一識別碼 |
| 簽章演算法 | CA 簽署憑證使用的演算法 |
| 發行者 | 簽發憑證的 CA 名稱 |
| 有效期間 | **發行日期**與**到期日期** |
| 主體 | 憑證擁有者身分資訊 |
| 公鑰資訊 | 擁有者的公鑰及演算法 |
| 數位簽章 | CA 對憑證內容的簽章 |

#### 常見憑證類型

| 類型 | 說明 | 範例 |
|:-----|:-----|:-----|
| SSL/TLS 憑證 | 網站加密通訊 | HTTPS 網站 |
| 程式碼簽章憑證 | 驗證軟體來源 | 應用程式簽章 |
| 個人憑證 | 身分識別 | 自然人憑證 |
| 機構憑證 | 組織身分識別 | 工商憑證 |

#### 憑證類型

| 類型 | 說明 | 瀏覽器信任 |
|:-----|:-----|:----------:|
| CA 簽發憑證 | 由受信任的 CA（憑證授權機構）簽發 | ✅ |
| 自簽憑證（Self-signed） | 自己簽發給自己，未經 CA 驗證 | ❌ |

**常見憑證錯誤原因：**

| 錯誤訊息 | 可能原因 |
|:---------|:---------|
| 憑證不被信任 | 使用自簽憑證、CA 不在信任清單 |
| 憑證已過期 | 超過有效期限 |
| 憑證名稱不符 | 網域名稱與憑證 CN/SAN 不一致 |

> 💡 自簽憑證常用於內部測試環境，正式環境應使用受信任 CA 簽發的憑證。

#### 後量子密碼學 (PQC)

量子電腦可快速破解現有非對稱加密（如 RSA），對稱加密有效位元長度會減半。後量子演算法設計用來抵抗量子電腦攻擊。

#### 金鑰生命週期管理

| 階段 | 說明 |
|:-----|:-----|
| 產生 | 使用安全的亂數產生器建立金鑰 |
| 儲存 | 加密保護、存放於安全環境（如 HSM） |
| 分發 | 透過安全通道傳輸金鑰 |
| 使用 | 依據用途與權限控管使用 |
| 更新 | 定期輪換，過期前更換新金鑰 |
| 銷毀 | 安全刪除，確保無法復原 |

> ⚠️ 金鑰過期後必須更換，不可繼續使用。金鑰管理應嚴格控管權限，不可任意開放。

#### 金鑰儲存安全

| 機制 | 說明 |
|:-----|:-----|
| HSM（硬體安全模組） | 專用硬體設備，安全儲存與處理金鑰 |
| FIPS 140-2 | 美國加密模組安全標準，分 Level 1-4 |

> ⚠️ 金鑰儲存於 HSM 時，**不可明文匯出**，應以加密方式保護。

#### 密碼學常見名詞比較

| 名詞 | 說明 | 達成目標 |
|:-----|:-----|:---------|
| 編碼（Encoding） | 格式轉換，如 Base64、URL Encoding | 無（僅格式轉換） |
| 加密（Encryption） | 用金鑰將明文轉為密文 | 機密性 |
| 雜湊（Hash） | 單向函數產生固定長度摘要 | 完整性 |
| 訊息摘要（Message Digest） | 雜湊運算的產物，又稱雜湊值、指紋 | 完整性 |
| HMAC | 雜湊 + 共享密鑰 | 完整性、真實性 |
| 數位簽章（Digital Signature） | 雜湊 + 私鑰加密 | 真實性、不可否認性、完整性 |
| 數位信封（Digital Envelope） | 對稱金鑰加密資料 + 公鑰加密對稱金鑰 | 機密性 |
| 數位憑證（Digital Certificate） | CA 簽發，綁定公鑰與身分 | 真實性 |
| PQC（後量子密碼學） | 可抵抗量子電腦攻擊的演算法 | 未來安全性 |
| 隱寫術（Steganography） | 將資料藏在載體中（如圖片、音訊） | 隱藏資訊存在 |

**常考比較：**

| 比較 | 差異 |
|:-----|:-----|
| 編碼 vs 加密 | 編碼無金鑰可直接還原，加密需金鑰才能解密 |
| 加密 vs 雜湊 | 加密可逆（有金鑰），雜湊不可逆 |
| 加密 vs 隱寫術 | 加密讓資料「看不懂」，隱寫術讓資料「看不到」 |
| 雜湊 vs HMAC | 雜湊只驗證完整性，HMAC 還能驗證真實性 |
| 數位簽章 vs 數位信封 | 簽章驗證身分，信封保護內容 |
| 數位簽章 vs 數位憑證 | 簽章驗證訊息，憑證驗證公鑰擁有者 |

---

#### 範例題目

> **Q：** 對於 SSO（Single Sign On）的描述，下列何者較「不」適切？
> - \(A\) 一次登入可以對應多個系統帳號
> - \(B\) 每個系統都有自己的帳號
> - \(C\) 當系統、API 修改或系統異常，信任關係即失效
> - \(D\) 可記憶密碼

<details>
<summary>查看答案</summary>

**\(D\) 可記憶密碼**

SSO 的核心是「**信任機制**」，讓使用者登入一次後，透過 Token 或 Session 存取其他系統，而非記憶密碼的功能。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ 正確，一次登入可存取多個系統 |
| B | ✅ 正確，各系統仍可有獨立帳號，SSO 負責對應關係 |
| C | ✅ 正確，信任關係依賴系統間的正常溝通 |
| D | ❌ 錯誤，SSO 不是密碼管理工具 |

</details>

---

> **Q：** 數位憑證（Digital Certificate）是在網際網路上識別人員和資源的電子檔案，能夠讓兩個實體之間能夠進行安全、機密的通訊。請問下列何項「不」是數位憑證的正確描述？
> - \(A\) 使用在伺服器上的數位憑證又稱為「伺服器憑證」、HTTPS/SSL 憑證，SSL 憑證是在網頁伺服器（主機）與網頁瀏覽器（客戶端）之間建立一個密碼連結的標準規範
> - \(B\) 一般網頁用的 SSL 憑證檔案中包含公鑰資訊、擁有者身分資訊、數位憑證發行者、憑證有效到期日，但是不會出現發行憑證日期
> - \(C\) 大部分的瀏覽器會在網址列裡顯示一個鎖的圖示或是其他識別方式，如果要了解 SSL 憑證的細節，只要點擊鎖的圖示即可
> - \(D\) 憑證用途非常廣泛，像是自然人憑證、工商憑證、健保卡等都是屬於數位憑證的用途，幾乎身分與機構識別都有利用到此技術

<details>
<summary>查看答案</summary>

**\(B\) 不正確**

SSL 憑證**會包含發行日期**。憑證的有效期間包含「生效日期（Not Before）」與「到期日期（Not After）」兩個欄位。

| 憑證欄位 | 是否包含 |
|:---------|:--------:|
| 公鑰資訊 | ✅ |
| 擁有者身分 | ✅ |
| 發行者資訊 | ✅ |
| 發行日期 | ✅ |
| 到期日期 | ✅ |

</details>

---

> **Q：** 在存取控制或零信任中，常提到 AAA 原則或 3A 管制、3A 框架，下列何項「不」是其中之一？
> - \(A\) 驗證身份（Authentication）
> - \(B\) 檢查授權（Authorization）
> - \(C\) 記錄行為（Accounting）
> - \(D\) 帳號管理（Account Management）

<details>
<summary>查看答案</summary>

**\(D\) 帳號管理（Account Management）**

AAA 框架指的是：

| 縮寫 | 全名 | 說明 |
|:----:|:-----|:-----|
| A | Authentication | 驗證身份 |
| A | Authorization | 檢查授權 |
| A | Accounting | 記錄行為 |

帳號管理（Account Management）不屬於 AAA 框架。

> 💡 **IAAA vs AAA**：IAAA 多了 Identification（識別），是更完整的存取控制流程。

</details>

---

> **Q：** 當使用者主張自己的身分後，系統應該確認使用者是否為所宣稱的合法身分擁有者，這個證明使用者身分的過程就被稱為「身分驗證」（Authentication），常見的身分驗證方法，下列敘述何者最「不」適切？
> - \(A\) 所知之事（Something you Know）：密碼、PIN Code、安全問答等
> - \(B\) 所有之物（Something you Have）：Token、USB 金鑰、智慧晶片卡（Smart Cards）
> - \(C\) 所具之形（Something you Are）：生物特徵（指紋、虹膜、聲紋等）
> - \(D\) 所用之物（Something you Use）：透過使用者所使用的裝置，例如電腦、瀏覽器類型或作業系統來確認身分

<details>
<summary>查看答案</summary>

**\(D\) 所用之物（Something you Use）**

傳統身分驗證三因子只有：

| 因子 | 英文 | 範例 |
|:----:|:-----|:-----|
| 所知之事 | Something you Know | 密碼、PIN、安全問答 |
| 所持之物 | Something you Have | Token、智慧卡、手機 |
| 所具之形 | Something you Are | 指紋、虹膜、聲紋 |

「所用之物」不是標準認證因子。裝置資訊（如瀏覽器、OS）通常用於**風險評估**或**情境驗證**，而非獨立的身分驗證方法。

</details>

---

> **Q：** 請問數位簽章的主要作用為下列何項？
> - \(A\) 加密資料
> - \(B\) 解密資料
> - \(C\) 生成隨機數
> - \(D\) 驗證資料的完整性與來源

<details>
<summary>查看答案</summary>

**\(D\) 驗證資料的完整性與來源**

數位簽章的主要特性：

| 特性 | 說明 |
|:----:|:-----|
| 完整性 | 確保資料未被竄改 |
| 真實性 | 確認資料來源（驗證身分） |
| 不可否認性 | 簽署者無法否認曾簽署 |

> ⚠️ 數位簽章**不提供機密性**，若需加密資料應使用「數位信封」。

</details>

---

> **Q：** 假設手上有一組金鑰對，其中金鑰 A 能將明文 x 變成密文 y；金鑰 B 能將密文 y 變成明文 x，這二把金鑰非屬同一把金鑰，且當加密演算法所用的運算函數為指數運算（mod）時，請問所用的加密演算法較有可能是下列哪一項？
> - \(A\) ECC
> - \(B\) AES
> - \(C\) RSA
> - \(D\) DES

<details>
<summary>查看答案</summary>

**\(C\) RSA**

題目關鍵：
1. **兩把金鑰不同** → 非對稱加密
2. **指數運算（mod）** → RSA 特徵

| 演算法 | 類型 | 數學基礎 |
|:------:|:----:|:---------|
| RSA | 非對稱 | 大數分解、模指數運算 |
| ECC | 非對稱 | 橢圓曲線 |
| AES | 對稱 | 區塊加密 |
| DES | 對稱 | 區塊加密（已不安全） |

</details>

---

> **Q：** 在網路通訊中，數位憑證的主要作用是下列何項？
> - \(A\) 加速網路傳輸速度
> - \(B\) 過濾垃圾郵件
> - \(C\) 壓縮檔案大小
> - \(D\) 驗證通訊對象的身份

<details>
<summary>查看答案</summary>

**\(D\) 驗證通訊對象的身份**

數位憑證由 CA（憑證機構）簽發，用於驗證網站或個人的身份，確保通訊對象是可信的。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 與傳輸速度無關 |
| B | ❌ 垃圾郵件過濾是郵件伺服器功能 |
| C | ❌ 壓縮是編碼技術，非憑證功能 |
| D | ✅ 數位憑證核心功能是身份驗證 |

> 💡 HTTPS 網站透過 SSL/TLS 憑證讓瀏覽器驗證網站身份，確保連線對象正確。

</details>

---

> **Q：** 在開發安全的應用程式時，使用者密碼應該如何安全儲存最為適當？
> - \(A\) 儲存於設定檔，方便管理員查詢
> - \(B\) 使用 SHA-1 進行雜湊後存儲
> - \(C\) 使用鹽（Salt）與 SHA-2 雜湊演算法存儲
> - \(D\) 直接儲存不做處理

<details>
<summary>查看答案</summary>

**\(C\) 使用鹽（Salt）與 SHA-2 雜湊演算法存儲**

密碼應使用安全的雜湊演算法加上鹽值儲存，防止彩虹表攻擊。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 明文儲存，任何人都可讀取 |
| B | ❌ SHA-1 已被證實不安全 |
| C | ✅ Salt + SHA-2 是目前推薦做法 |
| D | ❌ 明文儲存，風險最高 |

| 演算法 | 安全性 |
|:-------|:------:|
| MD5、SHA-1 | ❌ 不安全 |
| SHA-2、SHA-3 | ✅ 安全 |
| bcrypt、Argon2 | ✅ 專為密碼設計，更安全 |

> 💡 **鹽值（Salt）**：隨機字串加在密碼前後再雜湊，即使相同密碼也會產生不同雜湊值。

</details>

---

> **Q：** 資料安全在量子時代遭受極大挑戰，下列因應對策何者較為適切？
> - \(A\) CPC 中央處理加密
> - \(B\) PQC 後量子加密
> - \(C\) EEG 橢圓曲線圖
> - \(D\) AGV 自動圖形向量

<details>
<summary>查看答案</summary>

**\(B\) PQC 後量子加密**

PQC（Post-Quantum Cryptography）是專門設計用來抵抗量子電腦攻擊的加密演算法。

| 選項 | 說明 | 真實存在 |
|:----:|:-----|:--------:|
| A | CPC 不存在此術語 | ❌ |
| B | PQC 後量子密碼學 | ✅ |
| C | ECC 才是橢圓曲線加密（非 EEG） | ❌ |
| D | AGV 是自動導引車，與加密無關 | ❌ |

> 💡 量子電腦可快速破解 RSA、ECC 等現有非對稱加密，PQC 是目前主要的因應方案。

</details>

---

> **Q：** 對於保護儲存設備中的資料不被第三方竊取或篡改，下列何者描述最為適切？
> - \(A\) 使用對稱加密演算法，並將加密金鑰儲存在同一個設備上
> - \(B\) 可以對資料進行 Base64 編碼以隱藏資料內容
> - \(C\) 對資料進行加密保護，並額外使用 HMAC 來驗證資料完整性
> - \(D\) 將資料壓縮後再儲存於儲存設備

<details>
<summary>查看答案</summary>

**\(C\) 對資料進行加密保護，並額外使用 HMAC 來驗證資料完整性**

加密保護機密性（防竊取），HMAC 驗證完整性（防篡改），兩者結合是最佳做法。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 金鑰與資料存同一設備，設備遺失則加密無效 |
| B | ❌ Base64 是編碼非加密，可輕易解碼 |
| C | ✅ 加密 + HMAC 同時防竊取與篡改 |
| D | ❌ 壓縮只減少空間，無安全保護 |

> 💡 **HMAC（Hash-based Message Authentication Code）**：結合雜湊與密鑰，可同時驗證資料完整性與來源真實性。

</details>

---

> **Q：** FIDO（Fast Identity Online）是無密碼登入解決方案，主要是透過公開金鑰加密的架構結合終端裝置的多重因素驗證（MFA）與生物辨識驗證進行登入動作，可以更嚴密地保護個資。請問下列關於 FIDO 的描述何者較「不」正確？
> - \(A\) FIDO 的三大認證協議分別為 FIDO UAF、FIDO U2F、FIDO2
> - \(B\) FIDO 的最大特色是所有協定都建立於公開金鑰加密上，讓伺服器端只保存公鑰，不再需要負責保管使用者個資
> - \(C\) 使用者於各家金融機構先進行身分驗證開通「金融 FIDO」的使用，就可以利用個人終端裝置而不需要攜帶金融卡進行各項金融服務的驗證
> - \(D\) 使用者可以在終端裝置上透過指紋辨識、聲音辨識、輸入個人識別碼 PIN 等方式進行線上登入

<details>
<summary>查看答案</summary>

**\(D\) 使用者可以在終端裝置上透過指紋辨識、聲音辨識、輸入個人識別碼 PIN 等方式進行線上登入**

FIDO 標準支援的驗證方式包含指紋、臉部辨識、PIN 碼等，但**聲音辨識（Voice Recognition）不是 FIDO 標準支援的驗證方式**。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ 三大協議正確 |
| B | ✅ 公鑰加密、伺服器只存公鑰是核心特色 |
| C | ✅ 金融 FIDO 可用手機取代金融卡 |
| D | ❌ 聲音辨識非 FIDO 標準支援 |

| FIDO 支援驗證方式 | 不支援 |
|:------------------|:-------|
| 指紋辨識 | 聲音辨識 |
| 臉部辨識 | |
| PIN 碼 | |
| 實體安全金鑰 | |

</details>

---

> **Q：** 關於最小權限（Least Privilege）原則的描述，下列何項描述最為適切？
> - \(A\) 應授予所有使用者系統管理員權限，以提高效率
> - \(B\) 應根據使用者在組織階層中的級別來授予權限
> - \(C\) 所有使用者應享有相同的權限，以確保公平
> - \(D\) 僅授予使用者完成其工作所必需的最低權限

<details>
<summary>查看答案</summary>

**\(D\) 僅授予使用者完成其工作所必需的最低權限**

最小權限原則（Principle of Least Privilege, PoLP）是指只給予使用者完成工作所需的最小權限，不多也不少。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 違反最小權限，增加風險 |
| B | ❌ 權限應依工作職責，非組織層級 |
| C | ❌ 權限應依職責差異化，非一視同仁 |
| D | ✅ 最小權限原則的正確定義 |

> 💡 最小權限原則可降低帳號被盜用或誤操作造成的損害範圍。

</details>

---

> **Q：** 關於屬性存取控制（Attribute Based Access Control, ABAC）其中之「主體（Subject）」，下列何項描述最為適切？
> - \(A\) 對物件執行操作的角色，如：使用者
> - \(B\) 需要被保護的系統資源，如：檔案、資料庫
> - \(C\) 規範存取規則的政策文件，如：防火牆規則
> - \(D\) 定義操作情境的環境條件，如：時間、地點

<details>
<summary>查看答案</summary>

**\(A\) 對物件執行操作的角色，如：使用者**

ABAC 的「主體」是指發起存取請求、對物件執行操作的實體。

| 選項 | 對應要素 |
|:----:|:---------|
| A | ✅ 主體（Subject） |
| B | 物件（Object） |
| C | 政策（Policy） |
| D | 環境（Environment） |

| ABAC 要素 | 說明 | 範例 |
|:----------|:-----|:-----|
| 主體 | 執行操作的實體 | 使用者、程式 |
| 物件 | 被存取的資源 | 檔案、資料庫 |
| 操作 | 執行的動作 | 讀取、寫入 |
| 環境 | 情境條件 | 時間、地點 |

</details>

---

> **Q：** 為有效強化身分認證機制，常會使用多因子（Multi-factor authentication, MFA）認證機制，下列哪一項應用組合屬於多因子認證類型？
> 1. 聲紋辨識+帳號密碼
> 2. 指紋辨識+圖形驗證碼（Captcha）
> 3. 臉型辨識+指靜脈辨識+虹膜
> 4. 帳號密碼+自然人憑證IC卡
> 5. 帳號密碼+虹膜+自然人憑證IC卡
> 6. 帳號密碼+指紋辨識+圖形驗證碼（Captcha）
>
> - \(A\) 1、2、3、5
> - \(B\) 1、4、5、6
> - \(C\) 1、2、3
> - \(D\) 2、3、5

<details>
<summary>查看答案</summary>

**\(B\) 1、4、5、6**

MFA 必須結合「**兩種以上不同類型**」的認證因子：

| 組合 | 因子分析 | 是否 MFA |
|:----:|:---------|:--------:|
| 1 | 聲紋（所具）+ 密碼（所知） | ✅ |
| 2 | 指紋（所具）+ Captcha（非認證因子） | ❌ |
| 3 | 臉型+指靜脈+虹膜（全部都是所具） | ❌ |
| 4 | 密碼（所知）+ IC卡（所持） | ✅ |
| 5 | 密碼（所知）+ 虹膜（所具）+ IC卡（所持） | ✅ |
| 6 | 密碼（所知）+ 指紋（所具）+ Captcha（非認證因子） | ✅ |

**關鍵觀念：**
- **Captcha 不是認證因子**：用於區分人類與機器人，非身分驗證
- **同類型生物特徵不算多因子**：三種生物特徵仍只是「一種因子」

| 因子類型 | 範例 |
|:---------|:-----|
| 所知之事 | 密碼、PIN |
| 所持之物 | IC卡、Token、手機 |
| 所具之形 | 指紋、虹膜、臉型、聲紋 |

</details>

---

> **Q：** 加密與解密使用不同的金鑰，稱為公開金鑰演算法，或非對稱金鑰演算法，下列密碼演算法中，何者屬於此種加密演算法？
> - \(A\) RSA
> - \(B\) DES
> - \(C\) AES
> - \(D\) Blowfish

<details>
<summary>查看答案</summary>

**\(A\) RSA**

RSA 是非對稱加密演算法，使用公鑰加密、私鑰解密。

| 選項 | 演算法類型 |
|:----:|:-----------|
| A | ✅ 非對稱加密 |
| B | ❌ 對稱加密（已不安全） |
| C | ❌ 對稱加密 |
| D | ❌ 對稱加密 |

| 類型 | 特性 | 安全演算法 | 不安全演算法 |
|:-----|:-----|:-----------|:-------------|
| 對稱加密 | 加解密使用相同金鑰 | AES | DES、3DES、Blowfish |
| 非對稱加密 | 公鑰加密、私鑰解密 | RSA、ECC | - |

</details>

---

> **Q：** 關於金鑰管理生命週期的描述，下列何項正確？
> - \(A\) 金鑰管理的安全要求，必須包含從產生、儲存、分發、管理到銷毀整個生命週期
> - \(B\) 金鑰的使用因為內部資安預算分配考量，應以使用免費金鑰為優先
> - \(C\) 因為應用系統皆須使用金鑰考量，管理的權限可開放使用
> - \(D\) 因為金鑰有使用期限的設定，超過有效期限之金鑰可以不需要替換

<details>
<summary>查看答案</summary>

**\(A\) 金鑰管理的安全要求，必須包含從產生、儲存、分發、管理到銷毀整個生命週期**

金鑰管理必須涵蓋完整生命週期，確保每個階段的安全性。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ 金鑰生命週期管理的正確定義 |
| B | ❌ 金鑰選擇應以安全性為優先，非成本 |
| C | ❌ 金鑰權限應嚴格控管，不可任意開放 |
| D | ❌ 過期金鑰必須更換，不可繼續使用 |

| 生命週期階段 |
|:-------------|
| 產生 → 儲存 → 分發 → 使用 → 更新 → 銷毀 |

</details>

---

> **Q：** 關於金鑰管理之安全考量，下列敘述何者較「不」適當？
> - \(A\) 應確保金鑰品質（避免產生弱金鑰）
> - \(B\) 金鑰之使用、儲存、傳送與銷毀，應確保金鑰之內容無洩露之虞
> - \(C\) 金鑰應儲存於通過 FIPS 140-2 Level3（含）以上之硬體安全模組內並可明文匯出
> - \(D\) 金鑰應備份，並妥適保管，以確保其可用性

<details>
<summary>查看答案</summary>

**\(C\) 金鑰應儲存於通過 FIPS 140-2 Level3（含）以上之硬體安全模組內並可明文匯出**

金鑰儲存於 HSM 是正確的，但**不可明文匯出**，否則失去安全性。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ 避免弱金鑰是基本要求 |
| B | ✅ 金鑰全生命週期都要保護 |
| C | ❌ 金鑰不可明文匯出 |
| D | ✅ 金鑰應備份確保可用性 |

| FIPS 140-2 等級 | 安全要求 |
|:----------------|:---------|
| Level 1 | 基本演算法要求 |
| Level 2 | 防拆封條、角色認證 |
| Level 3 | 防篡改、金鑰不可明文匯出 |
| Level 4 | 最高等級實體防護 |

</details>

---

> **Q：** 請問下列何項其主要用途是用於解密資料？
> - \(A\) 公鑰
> - \(B\) 私鑰
> - \(C\) 數位簽章
> - \(D\) 訊息摘要

<details>
<summary>查看答案</summary>

**\(B\) 私鑰**

在非對稱加密中，公鑰加密、私鑰解密。

| 選項 | 用途 |
|:----:|:-----|
| A | 加密資料、驗證簽章 |
| B | ✅ 解密資料、產生簽章 |
| C | 驗證身分與完整性 |
| D | 資料完整性驗證（雜湊值） |

| 用途 | 使用的金鑰 |
|:-----|:-----------|
| 加密資料 | 公鑰加密 |
| 解密資料 | 私鑰解密 |
| 產生簽章 | 私鑰簽章 |
| 驗證簽章 | 公鑰驗章 |

> 💡 記憶口訣：**公加私解、私簽公驗**

</details>

---

> **Q：** 關於雜湊函數（Hash function）的主要用途說明，下列何項描述最為適切？
> - \(A\) 對訊息進行加密以保護其隱私
> - \(B\) 生成訊息摘要（Message digest）來驗證完整性
> - \(C\) 建立秘密金鑰（Secret key）以用於對稱加密
> - \(D\) 在加密過程中隨機化明文

<details>
<summary>查看答案</summary>

**\(B\) 生成訊息摘要（Message digest）來驗證完整性**

雜湊函數將任意長度的資料轉換為固定長度的摘要值，用於驗證資料是否被竄改。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 雜湊不可逆，不是加密，無法保護隱私 |
| B | ✅ 雜湊主要用途是驗證完整性 |
| C | ❌ 金鑰生成是另一種機制 |
| D | ❌ 隨機化明文是加鹽（Salt）或初始向量（IV）的功能 |

| 技術 | 特性 | 用途 |
|:-----|:-----|:-----|
| 雜湊 | 不可逆、固定長度 | 完整性驗證、密碼儲存 |
| 加密 | 可逆（有金鑰） | 機密性保護 |
| 編碼 | 可逆（無金鑰） | 格式轉換 |

</details>

---

> **Q：** 在零信任架構下，若一個帳號憑證遭竊，下列何項機制最能降低駭客利用該憑證進行橫向移動？
> - \(A\) 使用靜態防火牆（Static Packet Filtering Firewall）規則
> - \(B\) 增加 DMZ（Demilitarized Zone）伺服器數量
> - \(C\) 啟用多因素驗證（Multi-factor authentication）
> - \(D\) 啟用 NAT（Network Address Translation）對應

<details>
<summary>查看答案</summary>

**\(C\) 啟用多因素驗證（Multi-factor authentication）**

MFA 要求額外的驗證因子，即使密碼被盜，攻擊者沒有第二因子仍無法登入。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 靜態防火牆只過濾封包，無法驗證身分 |
| B | ❌ 增加伺服器數量與身分驗證無關 |
| C | ✅ MFA 可防止憑證被盜後的濫用 |
| D | ❌ NAT 是位址轉換，與身分驗證無關 |

| 憑證遭竊的防護 | 說明 |
|:---------------|:-----|
| MFA | 即使密碼被盜，仍需第二因子 |
| 最小權限 | 限制帳號可存取的範圍 |
| 持續驗證 | 每次存取都重新驗證 |
| 網路分段 | 限制橫向移動範圍 |

> 💡 零信任原則：**永不信任，持續驗證**。MFA 是零信任架構「身分」支柱的核心控制措施。

</details>

---

> **Q：** 在完成 HTTPS 網站設定後，瀏覽器仍顯示「憑證不被信任」的錯誤訊息，最可能的原因是下列何項？
> - \(A\) 使用的憑證尚未過期
> - \(B\) 使用了自簽憑證
> - \(C\) TLS 版本太新，瀏覽器不支援
> - \(D\) 加密演算法長度太長

<details>
<summary>查看答案</summary>

**\(B\) 使用了自簽憑證**

自簽憑證未經受信任的 CA 簽發，瀏覽器無法驗證其真實性，因此顯示不被信任。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 憑證未過期不會導致不被信任 |
| B | ✅ 自簽憑證不在瀏覽器信任清單中 |
| C | ❌ TLS 版本太新通常不會出現此錯誤 |
| D | ❌ 加密長度太長不會導致信任問題 |

| 憑證類型 | 瀏覽器信任 |
|:---------|:----------:|
| CA 簽發憑證 | ✅ |
| 自簽憑證 | ❌ |

> 💡 瀏覽器內建受信任的 CA 清單（Root CA），只有這些 CA 簽發的憑證才會被自動信任。

</details>

---

> **Q：** 若系統管理員採用「基於角色的存取控制（Role-Based Access Control, RBAC）」來管理伺服器，下列何項最能反映 RBAC 與傳統 DAC（Discretionary Access Control）的主要差異？
> - \(A\) RBAC 的存取決策依據使用者所屬角色，DAC 的存取決策依據資源擁有者的設定
> - \(B\) RBAC 屬於強制式存取控制的一種，DAC 屬於集中式管理模型
> - \(C\) DAC 無法支援多使用者環境，RBAC 則能依角色分派給多人
> - \(D\) 在 RBAC 中，使用者可直接修改自己資源的存取權限；在 DAC 中則需透過系統管理員

<details>
<summary>查看答案</summary>

**\(A\) RBAC 的存取決策依據使用者所屬角色，DAC 的存取決策依據資源擁有者的設定**

這是 RBAC 與 DAC 最核心的差異。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ 正確描述兩者核心差異 |
| B | ❌ RBAC 不是 MAC，DAC 也非集中式管理 |
| C | ❌ DAC 可支援多使用者環境 |
| D | ❌ 說反了，DAC 才是使用者可自行設定權限 |

| 模型 | 授權依據 | 特性 |
|:-----|:---------|:-----|
| DAC（自由存取控制） | 資源擁有者決定 | 彈性高，使用者可自行設定 |
| RBAC（角色存取控制） | 依角色群組授權 | 集中管理，依職責分配 |

</details>

---

> **Q：** 下列何項「不」屬於常見的資源存取控制模式？
> - \(A\) 以長效為基礎的安全模式（Permanent-based Access Control, PBAC）
> - \(B\) 任意式安全模式（Discretionary Access Control, DAC）
> - \(C\) 強制式安全模式（Mandatory Access Control, MAC）
> - \(D\) 以角色為基礎的安全模式（Role-based Access Control, RBAC）

<details>
<summary>查看答案</summary>

**\(A\) 以長效為基礎的安全模式（Permanent-based Access Control, PBAC）**

PBAC 不存在，是虛構的名稱。

| 選項 | 說明 | 真實存在 |
|:----:|:-----|:--------:|
| A | PBAC（虛構） | ❌ |
| B | DAC（自由存取控制） | ✅ |
| C | MAC（強制存取控制） | ✅ |
| D | RBAC（角色存取控制） | ✅ |

| 授權模型 | 說明 |
|:---------|:-----|
| DAC | 資源擁有者決定權限 |
| MAC | 系統強制執行，無法修改 |
| RBAC | 依角色群組給予權限 |
| ABAC | 依多種動態屬性決定授權 |

</details>

---

> **Q：** 在資訊安全領域，下列何種技術能夠確保即使攻擊者成功取得敏感資料，但無法直接解讀其內容？
> - \(A\) 數位簽章（Digital Signature）
> - \(B\) 非破壞性資料壓縮（Lossless Compression）
> - \(C\) 訊息摘要（Message Digest）
> - \(D\) 隱寫術（Steganography）

<details>
<summary>查看答案</summary>

**\(D\) 隱寫術（Steganography）**

隱寫術將敏感資料隱藏在載體（如圖片、音訊）中，攻擊者即使取得檔案，也不知道裡面藏有秘密資訊。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 數位簽章驗證身分與完整性，不保護內容機密性 |
| B | ❌ 壓縮只減少檔案大小，可輕易解壓縮讀取 |
| C | ❌ 訊息摘要用於驗證完整性，非保護內容 |
| D | ✅ 隱藏資訊的存在，攻擊者不知道有隱藏資料 |

| 技術 | 目的 |
|:-----|:-----|
| 加密 | 讓資料「看不懂」 |
| 隱寫術 | 讓資料「看不到」 |

</details>

---

> **Q：** 當使用者主張自己的身分後，系統應該確認使用者是否為所宣稱的合法身分擁有者，這個證明使用者身分的過程就被稱為「身分驗證」（Authentication）。關於常見身分驗證方法中的所具之形（Something you Are），下列敘述何者最「不」適切？
> - \(A\) 指紋（Fingerprints）
> - \(B\) 視網膜（Retina）
> - \(C\) 掌形（Palm）
> - \(D\) 個人密碼（Password）

<details>
<summary>查看答案</summary>

**\(D\) 個人密碼（Password）**

密碼屬於「**所知之事（Something you Know）**」，而非「所具之形」。

| 選項 | 認證類型 |
|:----:|:---------|
| A | ✅ 所具之形（生物特徵） |
| B | ✅ 所具之形（生物特徵） |
| C | ✅ 所具之形（生物特徵） |
| D | ❌ 所知之事 |

| 認證因子 | 範例 |
|:---------|:-----|
| 所知之事 | 密碼、PIN 碼、安全問答 |
| 所持之物 | Token、智慧卡、手機 |
| 所具之形 | 指紋、虹膜、視網膜、掌形、臉型、聲紋 |

</details>

---

## 1.4 事故管理與營運持續

### 1.4.1 事件與事故管理

#### 日誌、事件、事故的區別

| 名詞 | 定義 | 範例 |
|------|------|------|
| 日誌 (Log) | 如實記錄所有系統活動 | 使用者 A 在 9:00-9:15 嘗試登入 5 次失敗 |
| 資安事件 (Event) | 建立的規則需要判斷的異常現象 | 15 分鐘內密碼錯誤 5 次，是忘記密碼還是攻擊？ |
| 資安事故 (Incident) | 確認造成組織傷害的事件 | 確認是駭客成功入侵系統 |

#### 事故處理流程 (NIST 800-61)

準備 → 偵測與分析 → 遏制、根除與復原 → 事後檢討

1. **準備 (Preparation)**：建立應變團隊、準備工具與程序
2. **偵測與分析 (Detection and Analysis)**：發現並確認事故
3. **遏制、根除與復原 (Containment, Eradication, Recovery)**：阻止擴散、移除威脅、恢復服務
4. **事後檢討 (Post-Incident Activity)**：檢討改進、更新程序

> 💡 常考發生事故是第一件事是救火，就是遏制，並免災情持續擴大。

#### 入侵指標與攻擊指標

| 指標 | 英文 | 說明 | 特性 |
|:-----|:-----|:-----|:-----|
| IOC | Indicators of Compromise | 入侵指標，已發生攻擊的證據 | 事後分析、被動 |
| IOA | Indicators of Attack | 攻擊指標，正在進行攻擊的行為 | 即時偵測、主動 |

**常見 IOC 類型：**

| 類型 | 範例 |
|:-----|:-----|
| 檔案 | 惡意程式雜湊值（MD5、SHA-256） |
| 網路 | 可疑 IP、惡意網域、C2 伺服器 |
| 主機 | 異常登錄檔、可疑排程任務 |
| 行為 | 異常 PowerShell 執行、大量檔案加密 |

> 💡 **IOC vs IOA**：IOC 是「已被入侵的痕跡」，IOA 是「正在攻擊的行為」。IOA 可更早發現攻擊。

#### 數位證據處理

**證據保管鏈（Chain of Custody）**

記錄證據從取得到呈堂的完整過程，確保證據的完整性與可信度。

| 階段 | 說明 |
|:-----|:-----|
| 識別 | 辨識潛在證據來源 |
| 保全 | 防止證據被竄改或毀損 |
| 蒐集 | 使用鑑識工具取得證據副本 |
| 分析 | 檢驗證據內容 |
| 呈現 | 以報告形式呈堂 |

**證據完整性驗證**

| 方法 | 說明 |
|:-----|:-----|
| 雜湊值比對 | 對證據計算 SHA-256 等雜湊值，確認未被竄改 |
| 寫入保護 | 使用防寫設備，避免意外修改原始證據 |
| 映像備份 | 對原始媒體製作完整映像檔（Image），分析副本而非原件 |

> ⚠️ **鑑識黃金原則**：永遠分析副本，不可直接操作原始證據。所有操作都要記錄並可重現。

---

### 1.4.2 備援與營運持續

#### 營運持續相關計畫

| 計畫 | 全名 | 說明 | 範圍 |
|:-----|:-----|:-----|:-----|
| BCP | Business Continuity Plan | 營運持續計畫，確保業務不中斷 | 整體業務流程 |
| DRP | Disaster Recovery Plan | 災難復原計畫，IT 系統復原程序 | IT 基礎設施 |
| IRP | Incident Response Plan | 事件應變計畫，資安事件處理程序 | 資安事件 |

| 比較 | BCP | DRP | IRP |
|:-----|:----|:----|:----|
| 目的 | 維持業務運作 | 復原 IT 系統 | 處理資安事件 |
| 觸發 | 重大災難 | 系統故障/災難 | 資安事件 |
| 範圍 | 全組織 | IT 部門 | 資安團隊 |
| 時間 | 中長期復原 | 系統復原 | 即時應變 |

> 💡 **關係**：IRP 處理「資安事件」，DRP 處理「IT 災難復原」，BCP 涵蓋「整體業務持續」。DRP 和 IRP 都是 BCP 的一部分。

---

#### 關鍵指標

| 指標 | 全名 | 說明 |
|:-----|:-----|:-----|
| BIA | 營運衝擊分析 | 評估災難影響，決定優先恢復順序 |
| MTPD | 最大可容忍中斷時間 | 業務最多可停多久（業務目標） |
| RTO | 復原時間目標 | 系統需多久恢復運作（技術目標） |
| RPO | 復原點目標 | 容許丟失多少時間的資料（技術目標） |

> ⚠️ **重要原則**：RTO 必須小於 MTPD，否則無法在業務容忍時間內恢復。

#### BIA 營運衝擊分析步驟

| 步驟 | 說明 |
|:-----|:-----|
| 1. 識別核心業務 | 找出組織的關鍵業務功能 |
| 2. 評估中斷影響 | 分析業務中斷的財務、法規、聲譽衝擊 |
| 3. 計算容忍時間 | 決定 MTPD、RTO、RPO |
| 4. 確認復原順序 | 依重要性排定復原優先順序 |
| 5. 識別所需資源 | 確認復原所需的人員、設備、系統 |

> ⚠️ BIA 是「分析」階段，不包含「技術操作手冊」的制定，那是 DRP 的範疇。

#### 備份方式比較

| 方式 | 備份內容 | 空間需求 | 還原速度 | 備份速度 |
|:-----|:---------|:--------:|:--------:|:--------:|
| 完整備份（Full） | 所有資料 | 最大 | 最快 | 最慢 |
| 差異備份（Differential） | 上次完整備份後的變更 | 中等 | 中等 | 中等 |
| 增量備份（Incremental） | 上次任何備份後的變更 | 最小 | 最慢 | 最快 |


**還原所需備份數量：**

| 方式 | 還原需要 |
|:-----|:---------|
| 完整備份 | 最近 1 份完整備份 |
| 差異備份 | 最近 1 份完整 + 最近 1 份差異 |
| 增量備份 | 最近 1 份完整 + 所有後續增量 |

> ⚠️ **備份不等於可還原**：備份必須定期進行還原測試，確保資料可被有效復原。

#### 備份 3-2-1 原則

- **3** 份資料副本
- **2** 種不同的儲存媒體
- **1** 份異地備份

#### 備份安全原則

| 原則 | 說明 |
|:-----|:-----|
| 3-2-1 原則 | 3 份備份、2 種媒體、1 份異地 |
| Immutable Backup（不可變備份） | 備份資料無法被修改或刪除，防止勒索軟體破壞 |
| Air-gapped Backup（離線備份） | 備份與網路隔離，攻擊者無法存取 |
| 存取控管 | 備份系統採用獨立帳號、MFA、最小權限 |

> ⚠️ **勒索軟體防禦**：攻擊者常會嘗試刪除備份，採用不可變備份可確保備份無法被竄改或刪除。

#### RAID 陣列

| 類型 | 特性 | 容錯能力 |
|------|------|----------|
| RAID 0 | 資料分散 (Striping) | 無容錯 |
| RAID 1 | 資料鏡像 (Mirroring) | 可壞 1 顆 |
| RAID 5 | 分散式同位檢查 | 可壞 1 顆 |
| RAID 6 | 雙重同位檢查 | 可壞 2 顆 |
| RAID 10 | RAID 1+0 組合 | 單邊可壞 1 顆 |

#### 備援站點

| 類型 | 接手時間 | 建置成本 | 說明 |
|------|----------|----------|------|
| 鏡像站點 (Mirror Site) | 即時 | 最高 | 即時同步，可立即切換 |
| 熱備援 (Hot Site) | 數小時 | 高 | 設備就緒，需載入資料 |
| 溫備援 (Warm Site) | 數天 | 中 | 部分設備就緒 |
| 冷備援 (Cold Site) | 數週 | 最低 | 僅有空間，需採購設備 |

#### 系統轉換方式

| 方式 | 英文 | 說明 | 風險 | 成本 |
|:----:|:-----|:-----|:----:|:----:|
| 並行式 | Parallel | 新舊系統同時運作，確認無誤後才關閉舊系統 | 最低 | 最高 |
| 階段式 | Phased | 分階段逐步轉換，一次只轉換部分功能或部門 | 低 | 中高 |
| 引導式 | Pilot | 先在小範圍（如單一部門）試行，成功後再全面推廣 | 中 | 中 |
| 一次性 | Abrupt | 直接關閉舊系統，立即切換至新系統 | 最高 | 最低 |

> 💡 **風險與成本的關係**：風險越低的轉換方式，成本通常越高（需同時維護兩套系統）

#### 營運持續演練類型

| 類型 | 說明 | 真實度 | 成本 |
|:-----|:-----|:------:|:----:|
| 檢查表測試 | 書面檢核文件與程序 | 最低 | 最低 |
| 桌上推演 | 開會討論模擬情境 | 低 | 低 |
| 模擬測試 | 模擬災難流程，不中斷系統 | 中 | 中 |
| 並行測試 | 備援與主系統並行運作 | 高 | 高 |
| 完全中斷測試 | 實際停止主系統切換備援 | 最高 | 最高 |

> ⚠️ **計畫寫得再完美，沒有實際演練驗證都是紙上談兵。** 唯有透過演練才能發現問題並持續改進。

#### 機房實體安全

:::info
人員安全永遠第一
:::

**門禁故障模式：**
- **Fail-Safe (失效開啟)**：停電時自動開門，優先人身安全，適用逃生門
- **Fail-Secure (失效鎖定)**：停電時保持上鎖，優先資產安全，適用機房

**消防系統：**
- **FM200 (HFC-227)**：目前主流，化學滅火，對設備與人體較安全
- **INERGEN 惰性氣體**：物理滅火，對設備無害但價格較高
- 避免使用：一般灑水（損壞設備）、CO₂（人身安全疑慮）、海龍（環保問題）

**電力系統：**
- **UPS**：穩壓、濾波、短暫備援（約 5 分鐘供關機用，非發電設備）
- **柴油發電機**：長時間供電，但地下室有淹水與通風風險

---

### 範例題目

> **Q：** 系統在完成測試並確認了變更作業後，就得以開始進行「系統轉換」，以更換至另一個系統或軟體版本，目前實務上常見的「系統轉換」方法有下列四種：並行式（Parallel）轉換、階段式（Phased）轉換、一次性（Abrupt）轉換、引導式（Pilot）轉換。請問，下列何項系統轉換方式的轉換作業風險是最大的？
> - \(A\) 並行式（Parallel）
> - \(B\) 階段式（Phased）
> - \(C\) 一次性（Abrupt）
> - \(D\) 引導式（Pilot）

<details>
<summary>查看答案</summary>

**\(C\) 一次性（Abrupt）**

一次性轉換又稱「直接切換」或「Big Bang」，沒有退路，若新系統出問題將直接影響業務運作，風險最高。

| 風險排序（高→低） |
|:------------------|
| 一次性 Abrupt |
| 引導式 Pilot |
| 階段式 Phased |
| 並行式 Parallel |

</details>

---

> **Q：** 在資安事故管理中，下列何項活動應於事故發生後立即進行？
> - \(A\) 計畫的定期審查
> - \(B\) 員工教育訓練
> - \(C\) 影響範圍評估
> - \(D\) 事件記錄歸檔

<details>
<summary>查看答案</summary>

**\(C\) 影響範圍評估**

依據 NIST 800-61 事故處理流程，事故發生後應立即進行「偵測與分析」，評估影響範圍是首要工作。

| 選項 | 所屬階段 | 時機 |
|:----:|:---------|:-----|
| A | 事後檢討 | 定期執行 |
| B | 準備階段 | 事前預防 |
| C | 偵測與分析 | ✅ 事故發生後立即 |
| D | 事後檢討 | 事故處理完畢後 |

</details>

---

> **Q：** 下列何項較「不」屬於資安事故數位證據的要求？
> - \(A\) 記錄完整且未遭竄改
> - \(B\) 與原件相同的電子證據複本
> - \(C\) 所涉資訊系統於記錄時應有正確時間戳記
> - \(D\) 於存放證據之文件袋加以彌封

<details>
<summary>查看答案</summary>

**\(D\) 於存放證據之文件袋加以彌封**

「彌封」是**實體證據**的保存方式，不適用於數位證據。

| 數位證據要求 | 說明 |
|:-------------|:-----|
| 完整性 | 記錄完整且未遭竄改 |
| 真實性 | 複本與原件一致 |
| 時間正確性 | 具備正確時間戳記 |
| 保管鏈 | 記錄證據取得、保管、移轉過程 |

> 💡 數位證據透過**雜湊值**驗證完整性，而非實體彌封。

</details>

---

> **Q：** 備援計劃的主要目的，下列何者描述較為適切？
> - \(A\) 提高系統運作性能
> - \(B\) 確保業務持續
> - \(C\) 減少員工工作負荷
> - \(D\) 增加公司營收

<details>
<summary>查看答案</summary>

**\(B\) 確保業務持續**

備援計劃的核心目標是在災難或系統故障時，確保關鍵業務能夠持續運作，將營運中斷的影響降到最低。

| 選項 | 說明 |
|:----:|:-----|
| A | 性能提升是系統優化目標，非備援目的 |
| B | ✅ 備援計劃的核心目標 |
| C | 與備援計劃無直接關係 |
| D | 營收是業務目標，非備援目的 |

</details>

---

> **Q：** 在規劃緊急災難復原方法時，下列何項較屬優先的重要核心考慮因素？
> - \(A\) 業務流程的關鍵性和對影響的容忍度
> - \(B\) 存取權限
> - \(C\) 資料類型
> - \(D\) 資料容量

<details>
<summary>查看答案</summary>

**\(A\) 業務流程的關鍵性和對影響的容忍度**

災難復原規劃的首要步驟是進行 **BIA（營運衝擊分析）**，評估業務流程的重要性與可容忍的中斷時間。

| 考量因素 | 優先順序 | 說明 |
|:---------|:--------:|:-----|
| 業務關鍵性與容忍度 | ✅ 最優先 | 決定 MTD、RTO、RPO |
| 資料類型 | 次要 | 影響備份策略 |
| 資料容量 | 次要 | 影響儲存規劃 |
| 存取權限 | 次要 | 影響復原後存取控制 |

> 💡 先確認「哪些業務最重要、能停多久」，才能決定後續的復原策略與資源配置。

</details>

---

> **Q：** 當組織設定重要系統災害復原之 RTO 為 16 小時、RPO 為 3 天時，下列何項的備份週期係屬最小成本且能符合組織要求之規劃？
> - \(A\) 12 小時
> - \(B\) 2 天
> - \(C\) 5 天
> - \(D\) 每週備份

<details>
<summary>查看答案</summary>

**\(B\) 2 天**

RPO = 3 天，代表最多可接受丟失 3 天的資料，因此備份週期必須 **≤ 3 天**。

| 選項 | 備份週期 | 是否符合 RPO | 成本 |
|:----:|:--------:|:------------:|:----:|
| A | 12 小時 | ✅ | 最高 |
| B | 2 天 | ✅ | 中等 |
| C | 5 天 | ❌ 超過 3 天 | 低 |
| D | 每週 | ❌ 超過 3 天 | 最低 |

題目要求「最小成本且符合要求」，2 天備份週期是最佳選擇。

> 💡 **備份週期 ≤ RPO** 才能確保資料丟失在可接受範圍內。

</details>

---

> **Q：** 某公司遭受勒索軟體攻擊，導致主要系統資料被加密，業務運作受到嚴重影響。在這種情況下，下列何項措施對於確保營運持續性最為關鍵？
> - \(A\) 立即支付贖金，以恢復系統運作
> - \(B\) 找技術專家破解加密，以恢復資料
> - \(C\) 使用未受感染的備份資料，恢復系統運作
> - \(D\) 關閉所有系統，暫停服務運作

<details>
<summary>查看答案</summary>

**\(C\) 使用未受感染的備份資料，恢復系統運作**

面對勒索軟體，**離線備份**是最有效的復原手段。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 不建議支付贖金，無法保證取回資料，且助長犯罪 |
| B | ❌ 現代勒索軟體加密強度高，破解幾乎不可能 |
| C | ✅ 使用乾淨備份還原是最佳做法 |
| D | ❌ 暫停服務無法恢復營運 |

> 💡 **勒索軟體最佳防禦**：定期離線備份、遵守 3-2-1 備份原則。

</details>

---

> **Q：** 在數位鑑識調查中，為確保證據的完整性並能在法庭上被接受，下列哪一項原則較「不」適切？
> - \(A\) 在證據的扣押、蒐集、保管和運送過程中，應確保資料的一致性與完整性
> - \(B\) 為保持證據完整性，應利用加密機制保護數位證據
> - \(C\) 確保所有證據的取得、分析和儲存過程都被完整記錄並可被重現
> - \(D\) 其他人依據蒐證人員宣稱的鑑識程序應能得出相同的鑑識結果

<details>
<summary>查看答案</summary>

**\(B\) 為保持證據完整性，應利用加密機制保護數位證據**

數位證據的**完整性**應透過**雜湊值（Hash）**驗證，而非加密。加密是保護**機密性**的手段。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ 證據保管鏈的核心原則 |
| B | ❌ 完整性用雜湊驗證，非加密 |
| C | ✅ 可重現性是鑑識的基本要求 |
| D | ✅ 相同程序應得出相同結果 |

| 安全目標 | 保護技術 |
|:---------|:---------|
| 完整性 | 雜湊值（MD5、SHA-256） |
| 機密性 | 加密（AES、RSA） |

> 💡 數位鑑識三原則：**保管鏈完整、程序可重現、結果可驗證**。

</details>

---

> **Q：** 在資安事故管理中，下列何項措施最能提升企業的資安韌性？
> - \(A\) 購買效能更好的資安設備
> - \(B\) 建立適合的資安架構，並定期進行演練
> - \(C\) 增加資安預算、招募專業的監控人員
> - \(D\) 將所有資安工作外包給第三方廠商

<details>
<summary>查看答案</summary>

**\(B\) 建立適合的資安架構，並定期進行演練**

資安韌性強調的是「應變與復原能力」，定期演練可驗證架構有效性並持續改進。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 設備只是工具，非韌性關鍵 |
| B | ✅ 架構 + 演練是提升韌性的核心 |
| C | ❌ 預算與人力是基礎，但非最關鍵 |
| D | ❌ 全部外包會失去掌控能力 |

> 💡 **資安韌性**：不只是預防攻擊，更重要的是在事故發生時能快速應變、復原並持續營運。

</details>

---

> **Q：** 在資安事故管理中，下列何項措施最能提升企業的資安韌性？
> - \(A\) 購買效能更好的資安設備
> - \(B\) 建立適合的資安架構，並定期進行演練
> - \(C\) 增加資安預算、招募專業的監控人員
> - \(D\) 將所有資安工作外包給第三方廠商

<details>
<summary>查看答案</summary>

**\(B\) 建立適合的資安架構，並定期進行演練**

資安韌性強調的是「應變與復原能力」，定期演練可驗證架構有效性並持續改進。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 設備只是工具，非韌性關鍵 |
| B | ✅ 架構 + 演練是提升韌性的核心 |
| C | ❌ 預算與人力是基礎，但非最關鍵 |
| D | ❌ 全部外包會失去掌控能力 |

> 💡 **資安韌性**：不只是預防攻擊，更重要的是在事故發生時能快速應變、復原並持續營運。

</details>

---

> **Q：** 在資安事件處理的偵測與分析階段中，下列哪一項行為最有助於快速辨識是否為資安事件？
>
> X 公司資安監控中心（SOC）於尖峰時段收到多來源告警：
> - 入侵偵測系統（IDS）出現可疑掃描行為
> - 端點偵測與回應（EDR）回報異常 PowerShell 程式啟動
> - 安全資訊與事件管理（SIEM）將多筆事件關聯後提升為高風險
>
> - \(A\) 立即關閉受影響系統以防止可能的擴散
> - \(B\) 對相關系統與網路設備進行日誌關聯分析，比對入侵指標（IOC）並確認事件是否成立
> - \(C\) 依內規直接向主管機關進行對外通報
> - \(D\) 優先套用廠商最新修補（Patch）以移除可能弱點

<details>
<summary>查看答案</summary>

**\(B\) 對相關系統與網路設備進行日誌關聯分析，比對入侵指標（IOC）並確認事件是否成立**

「偵測與分析」階段的核心任務是**確認事件是否成立**，需透過日誌關聯與 IOC 比對來判斷。

| 選項 | 對應階段 |
|:----:|:---------|
| A | 遏制階段（確認後才執行） |
| B | ✅ 偵測與分析階段 |
| C | 通報（確認後才通報） |
| D | 復原/預防階段 |

| NIST 800-61 事故處理流程 |
|:-------------------------|
| 準備 → **偵測與分析** → 遏制、根除與復原 → 事後檢討 |

> 💡 先確認是否為真正的資安事件，再採取後續行動，避免誤判造成業務中斷。

</details>

---

> **Q：** 下列何項是確保數據中心備援運作有效的最佳做法？
> - \(A\) 定期進行員工輪調
> - \(B\) 定期測試備份系統
> - \(C\) 定期進行財務審查
> - \(D\) 減少數據中心的外圍安全措施

<details>
<summary>查看答案</summary>

**\(B\) 定期測試備份系統**

備份系統必須定期測試，確保資料可被有效還原，否則備份形同虛設。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 員工輪調與備援運作無直接關係 |
| B | ✅ 定期測試確保備份可用性 |
| C | ❌ 財務審查與備援運作無關 |
| D | ❌ 減少安全措施會增加風險 |

> ⚠️ **備份不等於可還原**：未經測試的備份可能因損壞、加密錯誤、版本不符等原因無法還原。定期測試是驗證備援有效性的唯一方式。

</details>

---

> **Q：** 關於營運持續管理之敘述，下列何者最「不」正確？
> - \(A\) 營運持續管理是資訊安全部門的權責，故無需其他部門人員參與
> - \(B\) 營運持續管理包含緊急災害復原計畫
> - \(C\) 營運持續管理應與公司目標、政策一致
> - \(D\) 營運持續管理應適時調整、更新

<details>
<summary>查看答案</summary>

**\(A\) 營運持續管理是資訊安全部門的權責，故無需其他部門人員參與**

營運持續管理是**全組織的責任**，需要各部門共同參與，不只是資訊安全部門的工作。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 需全組織參與，非單一部門權責 |
| B | ✅ DRP 是 BCP 的一部分 |
| C | ✅ 應與組織目標一致 |
| D | ✅ 應定期檢視與更新 |

| 計畫 | 說明 | 範圍 |
|:-----|:-----|:-----|
| BCP | 營運持續計畫 | 整體業務流程 |
| DRP | 災難復原計畫 | IT 基礎設施 |

</details>

---

> **Q：** 工控環境中，營運持續管理規劃的首要目的為何？
> - \(A\) 確保公司網站維持最新設計
> - \(B\) 在事故發生後，確保關鍵工控系統能持續或迅速恢復運作
> - \(C\) 減少員工流動率
> - \(D\) 強化社群媒體行銷

<details>
<summary>查看答案</summary>

**\(B\) 在事故發生後，確保關鍵工控系統能持續或迅速恢復運作**

營運持續管理的核心目的是確保關鍵業務在災難或事故後能持續或快速恢復運作。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 網站設計與營運持續無關 |
| B | ✅ 營運持續管理的核心目的 |
| C | ❌ 人力資源議題，非營運持續範疇 |
| D | ❌ 行銷議題，非營運持續範疇 |

> 💡 工控環境（OT）的營運持續更強調**安全性與可用性**，因為系統中斷可能影響實體設備運作甚至人身安全。

</details>

---

> **Q：** 在營運持續運作管理程序中，下列何項「不」是營運衝擊分析（Business Impact Analysis, BIA）的主要步驟？
> - \(A\) 識別機關的核心業務功能
> - \(B\) 計算核心業務可容許缺少資源的時間
> - \(C\) 制定詳細的災害復原技術操作手冊
> - \(D\) 確認業務功能與資源復原的先後順序

<details>
<summary>查看答案</summary>

**\(C\) 制定詳細的災害復原技術操作手冊**

BIA 是「分析」階段，目的是評估衝擊與決定優先順序。「技術操作手冊」屬於 DRP（災難復原計畫）的內容。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ BIA 步驟：識別核心業務 |
| B | ✅ BIA 步驟：計算 MTPD/RTO |
| C | ❌ 屬於 DRP，非 BIA |
| D | ✅ BIA 步驟：確認復原順序 |

| 階段 | 產出 |
|:-----|:-----|
| BIA | 衝擊分析報告、復原優先順序 |
| DRP | 災難復原技術操作手冊 |

</details>

---

> **Q：** 下列何項敘述是資料備份的主要目的？
> - \(A\) 確保資料的機密性，防止未經授權的存取
> - \(B\) 對抗資料毀損的威脅與抵抗勒索攻擊，以保護資料的可用性
> - \(C\) 確保資料的機敏性，防止資料遭到竄改
> - \(D\) 降低營運成本，減少儲存需求

<details>
<summary>查看答案</summary>

**\(B\) 對抗資料毀損的威脅與抵抗勒索攻擊，以保護資料的可用性**

備份的主要目的是確保資料在災難、故障或勒索攻擊後能被復原，保護的是「**可用性**」。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 機密性靠加密，非備份 |
| B | ✅ 備份保護可用性 |
| C | ❌ 完整性靠雜湊驗證，非備份 |
| D | ❌ 備份會增加儲存需求，非降低成本 |

| CIA | 保護技術 |
|:----|:---------|
| 機密性 | 加密 |
| 完整性 | 雜湊、數位簽章 |
| 可用性 | 備份、備援、叢集 |

</details>

---

> **Q：** 當偵測到一個可疑的惡意程式在企業內部網路中傳播，下列哪一項是最適當的立即處理方式？
> - \(A\) 斷開受感染設備的網路連線
> - \(B\) 關閉所有防毒軟體以防止誤報
> - \(C\) 向所有員工發送通知，要求他們自行檢查電腦
> - \(D\) 重新安裝受感染設備的作業系統

<details>
<summary>查看答案</summary>

**\(A\) 斷開受感染設備的網路連線**

當惡意程式正在傳播時，首要任務是「遏制」，防止擴散。斷開網路連線可立即阻止橫向移動。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ 遏制措施，防止擴散 |
| B | ❌ 關閉防毒會降低防禦能力 |
| C | ❌ 自行檢查緩不濟急，無法有效遏制 |
| D | ❌ 重灌是復原階段，非立即處理 |

| 事故處理階段 | 本題對應 |
|:-------------|:---------|
| 偵測與分析 | 發現惡意程式傳播 |
| **遏制** | ✅ 斷開網路連線 |
| 根除 | 移除惡意程式 |
| 復原 | 重灌系統、還原資料 |

> 💡 遏制的目的是「止血」，先阻止擴散，再進行後續處理。

</details>

---

> **Q：** 某公司於每日的凌晨 1 點進行備份，每日皆進行完整備份（Full Backup），假設需要還原至週三晚上 9 點時的狀況，需要下列何項備份檔案才能完成上述工作？
> - \(A\) 該週日的備份即可
> - \(B\) 該週三的備份即可
> - \(C\) 該週四的備份即可
> - \(D\) 該週四前所有的備份檔案

<details>
<summary>查看答案</summary>

**\(C\) 該週四的備份即可**

週四凌晨 1 點的備份包含截至該時間點的所有資料，涵蓋週三晚上 9 點的狀態。

| 備份時間 | 包含資料範圍 |
|:---------|:-------------|
| 週三凌晨 1 點 | 至週二晚上 12 點 |
| 週四凌晨 1 點 | 至週三晚上 12 點（✅ 包含週三晚上 9 點） |

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 週日備份不包含週三資料 |
| B | ❌ 週三備份只到週二晚上，不包含週三晚上 |
| C | ✅ 週四備份包含週三整天資料 |
| D | ❌ 完整備份只需一份即可還原 |

> 💡 **完整備份**只需最近一份即可還原，不需要多份備份檔案。

</details>

> **Q：** 某企業採用「每日增量備份＋每週完整備份」的方式。這樣設計的主要目的為下列何項？
> - \(A\) 減少備份檔案加密強度
> - \(B\) 降低儲存空間與備份時間成本
> - \(C\) 提高應用系統效能優先度
> - \(D\) 防止惡意程式注入

<details>
<summary>查看答案</summary>

**\(B\) 降低儲存空間與備份時間成本**

增量備份只備份上次備份後的變更，搭配每週完整備份，可在空間與還原效率間取得平衡。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 與加密強度無關 |
| B | ✅ 增量備份節省空間與時間 |
| C | ❌ 與應用系統效能無關 |
| D | ❌ 備份策略與防止惡意程式無關 |

| 備份方式 | 空間需求 | 備份速度 | 還原速度 |
|:---------|:--------:|:--------:|:--------:|
| 完整備份 | 最大 | 最慢 | 最快 |
| 差異備份 | 中等 | 中等 | 中等 |
| 增量備份 | 最小 | 最快 | 最慢 |

> 💡 **常見備份策略**：每週完整備份 + 每日增量/差異備份，兼顧空間效率與還原速度。

</details>

---

> **Q：** 企業採用混合式備份策略：本地快照（Snapshot）＋雲端異地備份（Offsite Backup）。在一次大規模勒索軟體攻擊中，攻擊者利用被竊取的管理者帳號，刪除了雲端的備份檔案，導致資料無法復原。請問此案例最主要暴露了下列何項備份管理風險？
> - \(A\) 備份資料未經壓縮，導致空間不足
> - \(B\) 備份存放在與生產系統同一環境
> - \(C\) 備份缺乏不可變性（Immutable Backup）與良好的存取控管
> - \(D\) 備份採用增量模式，導致復原速度過慢

<details>
<summary>查看答案</summary>

**\(C\) 備份缺乏不可變性（Immutable Backup）與良好的存取控管**

攻擊者能用管理者帳號刪除備份，說明備份可被修改/刪除，且存取控管不足。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 與壓縮無關 |
| B | ❌ 題目說有雲端異地備份，非同一環境 |
| C | ✅ 備份應設為不可變，且應有獨立存取控管 |
| D | ❌ 與備份模式無關 |

| 防護措施 | 說明 |
|:---------|:-----|
| Immutable Backup | 備份無法被修改或刪除 |
| 獨立帳號 | 備份系統使用獨立管理帳號 |
| MFA | 備份管理需多因子驗證 |
| Air-gapped | 離線備份，與網路隔離 |

> 💡 勒索軟體常見手法：先刪除備份，再加密資料，逼迫受害者付贖金。

</details>

---

# 第二科：資訊安全技術概論

## 2.1 網路與通訊安全

### 2.1.1 網路安全

#### OSI 七層模型與 TCP/IP 對照

| OSI 層級 | TCP/IP 層級 | 協定範例 | 設備範例 |
|----------|-------------|----------|----------|
| 應用層 | 應用層 | HTTP, DNS, SMTP | WAF,PROXY |
| 表現層 | - | 壓縮、加密 | - |
| 會議層 | - | Session 管理 | - |
| 傳輸層 | 傳輸層 | TCP, UDP | 傳統防火牆 |
| 網路層 | 網路層 | IP, ICMP | 路由器 |
| 資料連結層 | 鏈結層 | ARP, MAC Address | 交換器 |
| 實體層 | - | 電子訊號 | 集線器（僅訊號放大） |

#### TCP 三向交握

sequenceDiagram
    participant C as Client
    participant S as Server
    
    C->>S: 1. SYN（請求連線）
    Note right of S: Server 收到請求
    S->>C: 2. SYN + ACK（確認並回應）
    Note left of C: Client 收到回應
    C->>S: 3. ACK（確認連線）
    Note over C,S: ✅ 三向交握完成，連線建立

#### 常見通訊埠

| 服務 | 埠號 |
|------|------|
| SSH | TCP 22 |
| Telnet | TCP 23 |
| DNS | UDP 53（查詢）、TCP 53（Zone Transfer） |
| HTTP | TCP 80 |
| HTTPS | TCP 443 |
| NTP | UDP 123 |
| RDP | TCP 3389 |
| MS SQL | TCP 1433 |
| SMB | TCP 445 |

#### DNS 安全

| 技術 | 說明 | 保護目標 |
|:-----|:-----|:--------:|
| DNSSEC | DNS 安全擴充，數位簽章驗證 DNS 回應 | 完整性、真實性 |
| DoH（DNS over HTTPS） | 透過 HTTPS 加密 DNS 查詢 | 機密性 |
| DoT（DNS over TLS） | 透過 TLS 加密 DNS 查詢 | 機密性 |

> ⚠️ **DNSSEC 不提供機密性**：只驗證 DNS 回應是否被竄改，查詢內容仍是明文。

#### 郵件相關協定

| 協定 | Port | 用途 | 安全性 |
|:-----|:----:|:-----|:------:|
| SMTP | 25 | 郵件傳送 | ❌ |
| SMTP + STARTTLS | 587 | 郵件傳送（加密） | ✅ |
| SMTPS | 465 | 郵件傳送（SSL/TLS） | ✅ |
| POP3 | 110 | 郵件接收 | ❌ |
| POP3S | 995 | 郵件接收（SSL/TLS） | ✅ |
| IMAP | 143 | 郵件接收 | ❌ |
| IMAPS | 993 | 郵件接收（SSL/TLS） | ✅ |

> 💡 **STARTTLS**：在原有明文協定上啟動 TLS 加密，讓原本不安全的連線升級為加密連線。

#### 郵件驗證機制

| 機制 | 全名 | 功能 | 驗證內容 |
|:-----|:-----|:-----|:---------|
| SPF | Sender Policy Framework | 驗證寄件伺服器是否被授權 | 寄件者 IP |
| DKIM | DomainKeys Identified Mail | 驗證郵件內容未被竄改 | 數位簽章 |
| DMARC | Domain-based Message Authentication, Reporting and Conformance | 整合 SPF 與 DKIM，定義處理政策 | SPF + DKIM |

flowchart LR
    M[📧 收到郵件] --> SPF{SPF 驗證}
    SPF -->|檢查| IP[寄件 IP 是否授權]
    M --> DKIM{DKIM 驗證}
    DKIM -->|檢查| SIG[簽章是否有效]
    SPF --> DMARC{DMARC 政策}
    DKIM --> DMARC
    DMARC -->|通過| OK[✅ 接收]
    DMARC -->|失敗| ACT[依政策處理：<br> 拒絕/隔離/放行]

| 驗證結果 | DMARC 政策 | 處理方式 |
|:---------|:-----------|:---------|
| 驗證失敗 | none | 僅記錄，不採取行動 |
| 驗證失敗 | quarantine | 隔離至垃圾郵件 |
| 驗證失敗 | reject | 直接拒絕 |

> 💡 **防禦 BEC/釣魚**：SPF + DKIM + DMARC 三者搭配使用，可有效防止郵件偽造與詐騙。

#### 安全與不安全的技術

| 類型 | 不安全 | 安全 |
|------|--------|------|
| 傳輸協定 | HTTP, Telnet, FTP | HTTPS, SSH, SFTP |
| Wi-Fi 加密 | WEP, WPA | WPA2, WPA3 |
| 檔案分享 | SMBv1, SMBv2 | SMBv3 |
| 網管協定 | SNMPv1, SNMPv2 | SNMPv3 |
| TLS 版本 | SSL, TLS 1.0, TLS 1.1 | TLS 1.2, TLS 1.3 |
| 雜湊 | MD5, SHA-1 | SHA-2, SHA-3 |
| 對稱加密 | DES, 3DES, RC4 | AES |

---

### 2.1.2 通訊安全

#### 網路分段（Network Segmentation）

| 技術 | 說明 | 層級 |
|:-----|:-----|:----:|
| VLAN（虛擬區域網路） | 邏輯切割廣播範圍 | L2 |
| Subnet（子網路） | 以 IP 位址區分不同網段 | L3 |
| 防火牆區隔 | 不同安全等級區域間設置防火牆 | L3-L7 |
| Micro-Segmentation（微分段） | 以單一主機或應用為單位隔離 | 進階 |

**網路分段的效益：**
- 縮小攻擊面、限制橫向移動範圍
- 簡化存取控制管理、提升網路效能

> 💡 **Lateral Movement（橫向移動）**：攻擊者入侵一台主機後，利用內網信任關係擴散到其他系統。網路分段可有效限制擴散範圍。

---

#### 防火牆（Firewall）

**防火牆類型：**

| 類型 | 說明 |
|:-----|:-----|
| Packet Filtering（封包過濾） | 根據 IP、Port 進行基本過濾 |
| Stateful Inspection（狀態檢測） | 動態追蹤連線狀態，自動允許已建立連線 |
| Application Firewall（應用程式防火牆） | 深入分析應用層協定 |
| WAF（網頁應用防火牆） | 專門保護網站，可防 SQL Injection、XSS |

**NGFW（次世代防火牆）功能：**

| 功能 | 說明 |
|:-----|:-----|
| 傳統防火牆 | 封包過濾、狀態檢測 |
| IPS（入侵防禦） | 即時阻擋攻擊 |
| 應用程式識別 | 辨識並控制 L7 應用程式 |
| VPN | 遠端安全連線 |
| DLP（資料外洩防護） | 監控敏感資料傳輸 |
| Sandbox（沙箱） | 隔離環境分析可疑檔案 |
| URL 過濾 | 阻擋惡意網站 |

> ⚠️ NGFW 不具備「程式原始碼掃描」功能，那是 SAST 工具的範疇。

**防火牆規則原則：**
- 依序比對，第一條匹配即生效
- 預設最後一條為「Deny All」

| 原則 | 說明 | 安全性 |
|:-----|:-----|:------:|
| Whitelist（白名單） | 預設拒絕，僅允許明確許可的 | 較高 |
| Blacklist（黑名單） | 預設允許，僅拒絕明確禁止的 | 較低 |

**DMZ（非軍事區）架構：** 因為DMZ會直接被外面存取，預設不安全，要死就死在這裡，不要影響內部網路。

flowchart LR
    Internet[🌐 網際網路] --> FW1[🔥 外部防火牆]
    FW1 --> DMZ[📦 DMZ<br>Web/Mail/DNS]
    DMZ --> FW2[🔥 內部防火牆]
    FW2 --> Internal[🏢 內部網路]

---

#### IDS / IPS（入侵偵測與防禦系統）

**類型比較：**

| 類型 | 說明 |
|:-----|:-----|
| IDS（入侵偵測系統） | 被動監控，僅偵測告警 |
| IPS（入侵防禦系統） | 主動防禦，可阻擋攻擊 |
| NIDS / NIPS（網路型） | 部署在網路上，監控所有流量 |
| HIDS / HIPS（主機型） | 部署在主機上，監控系統活動與檔案變更 |

**網路型部署方式：**

| 部署方式 | 說明 | 適用 |
|:---------|:-----|:-----|
| Inline（串接） | 流量必須經過設備，可即時阻擋 | NIPS |
| Tap / Mirror（旁路） | 複製流量分析，不影響原流量 | NIDS |

> 💡 NIDS 用旁路不影響效能但無法阻擋；NIPS 用串接可阻擋但設備故障會影響網路。

**偵測方式比較：**

| 偵測方式 | 說明 | 優點 | 缺點 |
|:---------|:-----|:-----|:-----|
| Signature-based（特徵比對） | 比對已知攻擊特徵 | 準確率高 | 無法偵測 Zero-day 攻擊 |
| Anomaly-based（異常偵測） | 偵測偏離正常行為 | 可偵測未知攻擊 | 誤判率較高 |

> 💡當初勒索病毒就是因為特徵比對不出大量檔案加密，後來才出現EDR主要看行為。

**誤判類型：**

| 類型 | 說明 | 影響 |
|:-----|:-----|:-----|
| False Positive（偽陽性） | 正常流量誤判為攻擊 | 告警疲勞 |
| False Negative（偽陰性） | 攻擊未被偵測 | ⚠️ 較嚴重 |

---

#### VPN（虛擬私人網路）

| 類型 | 說明 | 應用場景 |
|:-----|:-----|:---------|
| Site-to-Site VPN | 連接兩個網路 | 總部與分公司互連 |
| Remote Access VPN | 遠端使用者連回內網 | 遠距辦公 |

| 協定 | 說明 |
|:-----|:-----|
| IPsec | 網路層加密，安全性高 |
| SSL / TLS VPN | 應用層加密，透過瀏覽器即可使用 |

**IPsec 核心協定：**

| 協定 | 全名 | 功能 | 加密 |
|:-----|:-----|:-----|:----:|
| AH | Authentication Header | 完整性、身分驗證 | ❌ |
| ESP | Encapsulating Security Payload | 完整性、身分驗證、加密 | ✅ |

> 💡 **AH vs ESP**：AH 只驗證不加密，ESP 驗證又加密。實務上多使用 ESP。

> 💡 VPN 提供**機密性**與**完整性**，但無法防止惡意流量，仍需搭配防火牆。

---

#### 進階防護機制

| 機制 | 說明 |
|:-----|:-----|
| DLP（資料外洩防護） | 監控防止敏感資料外洩 |
| EDR（端點偵測回應） | 持續監控終端設備行為 |
| SIEM（安全資訊事件管理） | 集中分析日誌，偵測威脅 |
| Virtual Patching（虛擬修補） | 無法修補漏洞時，透過 WAF/IPS 或 HIPS 阻擋攻擊 |
| CDR（內容威脅解除與重建） | 移除檔案中的潛在惡意內容後重建乾淨檔案 |
| RBI（遠端瀏覽器隔離） | 網頁在遠端執行，僅將安全畫面傳回使用者 |

---
#### 範例題目

> **Q：** 網路防火牆的訪問控制列表（Access Control List，ACL）指的是下列何項？
> - \(A\) 列出所有使用者帳號
> - \(B\) 定義哪些流量可以通過防火牆
> - \(C\) 記錄網路活動
> - \(D\) 阻止惡意軟體

<details>
<summary>查看答案</summary>

**\(B\) 定義哪些流量可以通過防火牆**

ACL 是防火牆用來控制網路流量的規則清單，依據來源/目的 IP、Port、協定等條件，決定允許或拒絕流量通過。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 使用者帳號屬於身分管理，非 ACL |
| B | ✅ ACL 定義流量過濾規則 |
| C | ❌ 記錄網路活動是日誌功能 |
| D | ❌ 阻止惡意軟體是防毒/IPS 功能 |

> 💡 ACL 規則依序比對，第一條匹配即生效，通常最後一條為「Deny All」。

</details>

---

> **Q：** 當配置 DMZ（Demilitarized Zone）時，通常放置在該區域的伺服器是下列何項？
> - \(A\) 內部員工專用檔案伺服器
> - \(B\) 公司內部財務資料庫伺服器
> - \(C\) 需對外提供服務的 Web 或郵件伺服器
> - \(D\) 個人用電腦

<details>
<summary>查看答案</summary>

**\(C\) 需對外提供服務的 Web 或郵件伺服器**

DMZ（非軍事區）是介於外部網路與內部網路之間的緩衝區，用於放置需要對外提供服務的伺服器。

網際網路 → 外部防火牆 → DMZ → 內部防火牆 → 內部網路

| 伺服器類型 | 放置位置 |
|:-----------|:--------:|
| Web 伺服器 | DMZ |
| 郵件伺服器 | DMZ |
| DNS 伺服器 | DMZ |
| 財務資料庫 | 內部網路 |
| 檔案伺服器 | 內部網路 |

> 💡 DMZ 的設計目的：即使對外伺服器被攻破，攻擊者仍需突破內部防火牆才能進入內網。

</details>

---

> **Q：** 有關狀態檢視防火牆（Stateful Inspection Firewalls）以及封包過濾防火牆（Packet Filter Firewalls）之敘述，下列何者錯誤？
> - \(A\) 狀態檢視防火牆是基於 TCP/IP 協定特徵而發展出來的功能
> - \(B\) 狀態檢視防火牆使用「狀態表」來確認任何進入流量
> - \(C\) 封包過濾防火牆基於 OSI 模型的第 4 層-傳送層（Transport Layer）運作
> - \(D\) 封包過濾防火牆會針對 IP 封包的標頭加以檢查，藉以過濾掉非法封包

<details>
<summary>查看答案</summary>

**\(C\) 錯誤**

封包過濾防火牆主要是基於 **OSI 第 3 層（網路層）** 運作，檢查 IP 封包標頭，而非第 4 層。

| 防火牆類型 | OSI 層級 | 檢查內容 |
|:-----------|:--------:|:---------|
| 封包過濾防火牆 | 第 3 層（網路層） | IP 位址、協定類型 |
| 狀態檢測防火牆 | 第 3-4 層 | 連線狀態、TCP 旗標 |
| 應用程式防火牆 | 第 7 層（應用層） | 應用層協定內容 |

> 💡 封包過濾防火牆雖然也會檢查 Port（第 4 層資訊），但主要是依據 IP 標頭進行過濾。

</details>

---

> **Q：** 關於通訊安全的敘述，下列何者錯誤？
> - \(A\) 當兩個系統進行通訊時，務必確保系統透過安全通道進行通訊，獲授權存取雙方使用共用資源
> - \(B\) 安全通訊端層（SSL）是對網際網路通訊提供隱私、驗證和整合性的安全性通訊協定
> - \(C\) SSL 是通道加密，資料也加密保護
> - \(D\) 傳輸層安全標準（TLS）是標準網際網路通訊協定，可以加密處理電子郵件，確保郵件在傳輸過程中安全不外洩

<details>
<summary>查看答案</summary>

**\(C\) 錯誤**

SSL/TLS 是「**通道加密**」，僅保護**傳輸中的資料（Data in Transit）**，資料到達目的地後會被解密，並不會對資料本身進行額外加密保護。

| 資料狀態 | SSL/TLS 保護 |
|:---------|:------------:|
| Data in Transit（傳輸中） | ✅ |
| Data at Rest（靜態） | ❌ |
| Data in Use（使用中） | ❌ |

> 💡 若要保護靜態資料，需使用 TDE、磁碟加密等技術；SSL/TLS 僅保護傳輸過程。

</details>

---

> **Q：** 下列何者是虛擬私人網路（Virtual Private Network，VPN）的主要功能？
> - \(A\) 過濾垃圾郵件
> - \(B\) 加速網路速度
> - \(C\) 防止病毒感染
> - \(D\) 隱藏 IP 位址，加密網路流量

<details>
<summary>查看答案</summary>

**\(D\) 隱藏 IP 位址，加密網路流量**

VPN 透過加密通道傳輸資料，隱藏使用者真實 IP，保護傳輸中的資料安全。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 垃圾郵件過濾是郵件伺服器功能 |
| B | ❌ VPN 可能因加密反而略降速度 |
| C | ❌ 防毒是端點防護功能 |
| D | ✅ VPN 核心功能 |

> 💡 VPN 保護的是 **Data in Transit（傳輸中資料）**，常見協定：IPsec、OpenVPN、WireGuard。

</details>

---

> **Q：** 若一台設備已無法修補特定漏洞，下列哪一項防護措施最「不」能有效防止攻擊者利用該漏洞進行攻擊？
> - \(A\) 安裝最新的應用程式更新，降低可能被利用的攻擊面
> - \(B\) 使用虛擬補丁技術，在網路層面阻止針對漏洞的攻擊流量
> - \(C\) 對該設備進行嚴格的存取控制，限制只有特定來源能夠存取
> - \(D\) 啟用入侵偵測和防禦系統（IDS/IPS），監控並阻擋可疑流量

<details>
<summary>查看答案</summary>

**\(A\) 安裝最新的應用程式更新，降低可能被利用的攻擊面**

題目明確指出「該漏洞已無法修補」，因此安裝更新無法解決該特定漏洞的問題。

| 選項 | 措施類型 | 對該漏洞有效 |
|:----:|:---------|:------------:|
| A | 更新修補 | ❌ 無法修補該漏洞 |
| B | 虛擬補丁 | ✅ 網路層阻擋攻擊流量 |
| C | 存取控制 | ✅ 限制攻擊來源 |
| D | IDS/IPS | ✅ 監控並阻擋可疑行為 |

> 💡 **虛擬補丁（Virtual Patching）**：當無法直接修補漏洞時，透過 WAF 或 IPS 在網路層阻擋針對該漏洞的攻擊流量，屬於**補償性控制**。

</details>

---

> **Q：** 在物聯網安全中，下列何種技術可有效防止設備與伺服器之間的通訊被竊聽或篡改？
> - \(A\) Telnet
> - \(B\) HTTPS
> - \(C\) FTP
> - \(D\) SNMPv1

<details>
<summary>查看答案</summary>

**\(B\) HTTPS**

HTTPS 使用 TLS 加密通訊，可同時防止竊聽（機密性）與篡改（完整性）。

| 選項 | 安全性 | 說明 |
|:----:|:------:|:-----|
| A | ❌ | Telnet 明文傳輸，應改用 SSH |
| B | ✅ | HTTPS 加密傳輸 |
| C | ❌ | FTP 明文傳輸，應改用 SFTP |
| D | ❌ | SNMPv1 無加密，應改用 SNMPv3 |

| 不安全協定 | 安全替代方案 |
|:-----------|:-------------|
| HTTP | HTTPS |
| Telnet | SSH |
| FTP | SFTP / FTPS |
| SNMPv1/v2 | SNMPv3 |

</details>

---

> **Q：** 關於預設拒絕（Deny by Default）原則的描述，下列何項描述最為適切？
> - \(A\) 除非使用者明確要求，否則所有功能預設為啟用
> - \(B\) 應用程式應預設允許所有請求，除非有規則明確拒絕
> - \(C\) 當沒有任何存取控制規則明確符合時，應預設拒絕存取請求
> - \(D\) 只有被列入黑名單的使用者才被拒絕存取

<details>
<summary>查看答案</summary>

**\(C\) 當沒有任何存取控制規則明確符合時，應預設拒絕存取請求**

預設拒絕原則：未明確允許的一律拒絕，是白名單思維的核心。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 預設啟用是「預設允許」，非預設拒絕 |
| B | ❌ 這是「預設允許」原則 |
| C | ✅ 預設拒絕的正確定義 |
| D | ❌ 這是黑名單機制，屬於預設允許 |

| 原則 | 思維 | 安全性 |
|:-----|:-----|:------:|
| 預設拒絕 | 白名單：只放行已知好的 | 較高 |
| 預設允許 | 黑名單：只阻擋已知壞的 | 較低 |

> 💡 防火牆最後一條規則通常是「Deny All」，就是預設拒絕原則的實踐。

</details>

---

> **Q：** 下列何項是防火牆策略的最佳資安實踐？
> - \(A\) 允許所有的外部連入請求
> - \(B\) 預設拒絕所有連接，除非明確允許
> - \(C\) 預設允許所有連接，除非明確拒絕
> - \(D\) 不使用防火牆，以增加網路效能

<details>
<summary>查看答案</summary>

**\(B\) 預設拒絕所有連接，除非明確允許**

防火牆最佳實踐是「**預設拒絕（Deny by Default）**」，採白名單思維，僅允許明確許可的連線。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 允許所有連入會暴露風險 |
| B | ✅ 預設拒絕，白名單思維 |
| C | ❌ 預設允許，黑名單思維，安全性較低 |
| D | ❌ 不使用防火牆會失去邊界防護 |

| 原則 | 思維 | 安全性 |
|:-----|:-----|:------:|
| 預設拒絕 | 白名單：只放行已知好的 | 較高 |
| 預設允許 | 黑名單：只阻擋已知壞的 | 較低 |

> 💡 防火牆最後一條規則通常是「Deny All」，就是預設拒絕原則的實踐。

</details>

---

> **Q：** 若希望在防火牆上設定，讓對外的所有連線預設為拒絕（Deny），只有經過許可的才允許通過，這種策略常被稱下列何項？
> - \(A\) 黑名單（Blacklist）
> - \(B\) 白名單（Whitelist）
> - \(C\) 預設通過（Default Allow）
> - \(D\) 動態篩選（Dynamic Filter）

<details>
<summary>查看答案</summary>

**\(B\) 白名單（Whitelist）**

白名單策略是「預設拒絕，只允許明確許可的」，安全性較高。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 黑名單是「預設允許，只擋已知壞的」 |
| B | ✅ 白名單是「預設拒絕，只放已知好的」 |
| C | ❌ 預設通過是黑名單思維 |
| D | ❌ 動態篩選是封包檢測技術，非存取策略 |

| 策略 | 預設動作 | 安全性 |
|:-----|:---------|:------:|
| 白名單 | 預設拒絕（Deny by Default） | 較高 |
| 黑名單 | 預設允許（Allow by Default） | 較低 |

</details>

---

> **Q：** 公司部署的入侵偵測系統主要依靠簽章或特徵比對為偵測機制。當遭遇零時差（Zero-day）攻擊，入侵偵測系統的偵測結果最可能是下列何項？
> - \(A\) 大量正常流量被誤判為惡意，導致告警數量急遽上升
> - \(B\) 系統立即阻斷攻擊封包，並防止橫向擴散
> - \(C\) 入侵偵測系統因處理效率影響，造成封包轉送速度異常加快
> - \(D\) 攻擊流量未被標記為異常，直到後續分析才可能察覺

<details>
<summary>查看答案</summary>

**\(D\) 攻擊流量未被標記為異常，直到後續分析才可能察覺**

特徵比對型 IDS 只能偵測「已知攻擊」，零時差攻擊尚無特徵可比對，因此會漏判。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 誤判多是異常偵測的問題，非特徵比對 |
| B | ❌ IDS 只偵測不阻擋，且無特徵無法偵測 |
| C | ❌ 與偵測機制無關 |
| D | ✅ 無特徵可比對，攻擊會被漏過 |

| 偵測方式 | 可偵測零時差攻擊 |
|:---------|:----------------:|
| 特徵比對 | ❌ |
| 異常偵測 | ✅（但誤判率高） |

> 💡 **零時差攻擊**：漏洞被發現後、修補程式發布前的攻擊，此時尚無特徵可供比對。

</details>

---

> **Q：** 若要在網路層面降低駭客橫向移動風險，最適合的設計是下列何項？
> - \(A\) 啟用 VPN（Virtual Private Network）加密流量
> - \(B\) 增加 DMZ（Demilitarized Zone）伺服器數量
> - \(C\) 使用 IDS（Intrusion Detection System）偵測可疑封包
> - \(D\) 採用網路分段（Network Segmentation）將整體網路劃分為多個較小的子網路或區域

<details>
<summary>查看答案</summary>

**\(D\) 採用網路分段（Network Segmentation）將整體網路劃分為多個較小的子網路或區域**

網路分段可限制攻擊者在入侵後的橫向移動範圍，降低擴散風險。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ VPN 保護傳輸機密性，無法阻止橫向移動 |
| B | ❌ 增加伺服器數量不影響橫向移動風險 |
| C | ❌ IDS 只偵測不阻擋，屬被動防禦 |
| D | ✅ 網路分段限制橫向移動範圍 |

| 網路分段層級 | 說明 |
|:-------------|:-----|
| 傳統網段隔離 | 依功能區分（DMZ、內部、外部） |
| 微分段（Micro-Segmentation） | 以單一主機或應用為單位隔離 |

> 💡 **橫向移動（Lateral Movement）**：攻擊者入侵一台主機後，利用內網信任關係擴散到其他系統。網路分段是零信任架構的核心防禦手段。

</details>

---

> **Q：** 關於 VLAN（Virtual Local Area Network）與安全性的敘述，下列何者較為正確？
> - \(A\) 僅能提升效能，與安全性無關
> - \(B\) 可以減少廣播範圍並降低橫向攻擊風險
> - \(C\) 可取代防火牆的功能
> - \(D\) 僅能應用於無線網路環境

<details>
<summary>查看答案</summary>

**\(B\) 可以減少廣播範圍並降低橫向攻擊風險**

VLAN 透過邏輯切割網路，縮小廣播域並限制不同群組間的直接通訊，降低橫向移動風險。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ VLAN 同時提升效能與安全性 |
| B | ✅ 減少廣播範圍、降低橫向攻擊風險 |
| C | ❌ VLAN 無法取代防火牆，兩者功能不同 |
| D | ❌ VLAN 可用於有線與無線網路 |

| VLAN 效益 | 說明 |
|:----------|:-----|
| 效能 | 減少廣播流量，提升網路效率 |
| 安全 | 隔離不同群組，限制橫向移動 |
| 管理 | 邏輯分組，簡化網路管理 |

> ⚠️ VLAN 是 L2 隔離，不同 VLAN 間通訊仍需透過 L3 路由或防火牆控管。

</details>

---

> **Q：** 在設定防火牆的規則時，下列哪一種策略可以有效減少誤報並提高安全性？
> - \(A\) 使用最小權限原則，僅允許必要的流量
> - \(B\) 設定所有流量為允許，然後逐步添加拒絕規則
> - \(C\) 僅依賴預設的防火牆規則
> - \(D\) 定期重置防火牆設定以清除舊規則

<details>
<summary>查看答案</summary>

**\(A\) 使用最小權限原則，僅允許必要的流量**

最小權限原則搭配預設拒絕，只開放必要的流量，可減少攻擊面並提高安全性。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ 最小權限 + 白名單，安全性最高 |
| B | ❌ 預設允許是黑名單思維，安全性較低 |
| C | ❌ 預設規則可能不符合實際需求 |
| D | ❌ 重置會清除有效規則，造成安全漏洞 |

| 原則 | 說明 |
|:-----|:-----|
| 最小權限 | 僅開放完成工作所需的最小流量 |
| 預設拒絕 | 未明確允許的一律拒絕 |

> 💡 防火牆最佳實踐：**預設拒絕 + 最小權限 + 定期審查規則**

</details>

---

> **Q：** 下列哪一項是防火牆的主要功能之一，能夠防止未經授權的存取？
> - \(A\) 加密資料傳輸
> - \(B\) 監控網路流量
> - \(C\) 檢查和過濾進出網路的封包
> - \(D\) 提供虛擬私人網路（Virtual Private Network, VPN）連接

<details>
<summary>查看答案</summary>

**\(C\) 檢查和過濾進出網路的封包**

防火牆的核心功能是依據規則檢查並過濾封包，決定允許或拒絕通過。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 加密是 VPN 或 TLS 的功能 |
| B | ⚠️ 監控是附加功能，非主要功能 |
| C | ✅ 封包過濾是防火牆的核心功能 |
| D | ❌ VPN 是獨立功能，部分防火牆有整合 |

| 設備 | 主要功能 |
|:-----|:---------|
| 防火牆 | 封包過濾、存取控制 |
| IDS | 監控流量、偵測威脅 |
| VPN | 加密傳輸、建立安全通道 |

</details>

---

> **Q：** 某公司內部郵件傳輸需要保護機密性，下列何者為最適當採用的安全通訊協定？
> - \(A\) SMTP 搭配 STARTTLS
> - \(B\) HTTP 搭配 TLS
> - \(C\) DNSSEC
> - \(D\) Telnet

<details>
<summary>查看答案</summary>

**\(A\) SMTP 搭配 STARTTLS**

SMTP 是郵件傳輸協定，搭配 STARTTLS 可將連線升級為加密，保護郵件機密性。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ 郵件傳輸加密的標準做法 |
| B | ❌ HTTP + TLS 是 HTTPS，用於網頁，非郵件 |
| C | ❌ DNSSEC 是 DNS 安全擴充，與郵件無關 |
| D | ❌ Telnet 是明文傳輸，無加密功能 |

| 郵件協定 | 加密方式 |
|:---------|:---------|
| SMTP + STARTTLS | 升級加密（Port 587） |
| SMTPS | 直接加密（Port 465） |

</details>

---

> **Q：** 依照 IP 的來源地區（GEOIP）限制連線，這種防火牆的運作，主要是針對開放式系統互聯模型（OSI Model）中哪一層來進行？
> - \(A\) 第 2 層資料連結層（Data Link Layer）
> - \(B\) 第 3 層網路層（Network Layer）
> - \(C\) 第 4 層傳輸層（Transport Layer）
> - \(D\) 第 5 層會議層（Session Layer）

<details>
<summary>查看答案</summary>

**\(B\) 第 3 層網路層（Network Layer）**

GEOIP 是根據 IP 位址判斷地理位置，IP 位址屬於 OSI 第 3 層網路層。

| 選項 | OSI 層級 | 處理內容 |
|:----:|:---------|:---------|
| A | L2 資料連結層 | MAC 位址 |
| B | L3 網路層 | ✅ IP 位址 |
| C | L4 傳輸層 | Port、TCP/UDP |
| D | L5 會議層 | 連線管理 |

| 防火牆類型 | 運作層級 | 過濾依據 |
|:-----------|:--------:|:---------|
| 封包過濾 | L3-L4 | IP、Port |
| 狀態檢測 | L3-L4 | 連線狀態 |
| 應用層防火牆 | L7 | 應用協定內容 |

</details>

---

> **Q：** 防火牆（Firewall）設備內通常擁有一整套網路安全規則，可以用來監控、篩選和控制進出特定範圍的網路封包內容與流量。配置防火牆設備的主要目的，是在受信任的內部網路和不受信任的外部網路之間建立屏障。請問下一個世代防火牆 NGFW（Next-Generation Firewall）較「不」具備下列何項功能？
> - \(A\) 遠端 VPN 連線
> - \(B\) 資料外洩防護（Data Loss Prevention, DLP）
> - \(C\) 程式原始碼掃描
> - \(D\) 沙箱（Sandbox）運作與程式分析

<details>
<summary>查看答案</summary>

**\(C\) 程式原始碼掃描**

程式原始碼掃描是 SAST（靜態應用程式安全測試）工具的功能，屬於開發階段的安全檢測，不是防火牆的功能。

| 選項 | NGFW 功能 |
|:----:|:---------:|
| A | ✅ VPN 連線 |
| B | ✅ DLP 資料外洩防護 |
| C | ❌ 屬於 SAST，非 NGFW |
| D | ✅ 沙箱分析 |

| 工具 | 用途 |
|:-----|:-----|
| NGFW | 網路層防護、流量分析 |
| SAST | 程式原始碼靜態掃描 |
| DAST | 執行中應用程式動態測試 |

</details>

---

> **Q：** 遠端瀏覽器隔離（Remote Browser Isolation），是一種先進的網路安全技術，技術上主要是透過下列何種核心機制，以保護使用者免於遭受網頁惡意程式的攻擊？
> - \(A\) 在本機電腦的瀏覽器中直接掃描網頁程式碼，並比對已知的惡意軟體特徵碼資料庫
> - \(B\) 在網站伺服器前端部署一道防線，用以保護網站本身不被惡意流量（如 SQL Injection）攻擊
> - \(C\) 將所有網頁內容的載入與執行，都放在一個遠端的、隔離的雲端或伺服器環境中進行，僅將安全的視覺影像傳回給使用者
> - \(D\) 根據一份不斷更新的黑名單，禁止使用者存取已知的惡意或釣魚網站

<details>
<summary>查看答案</summary>

**\(C\) 將所有網頁內容的載入與執行，都放在一個遠端的、隔離的雲端或伺服器環境中進行，僅將安全的視覺影像傳回給使用者**

RBI 的核心概念是「隔離執行」，網頁在遠端環境執行，使用者只接收安全的畫面。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 這是傳統防毒的特徵比對方式 |
| B | ❌ 這是 WAF 的功能 |
| C | ✅ RBI 的核心機制 |
| D | ❌ 這是 URL 過濾 / 黑名單機制 |

| 技術 | 說明 |
|:-----|:-----|
| RBI | 網頁在遠端執行，僅傳回畫面 |
| WAF | 保護網站伺服器 |
| URL 過濾 | 阻擋已知惡意網站 |

> 💡 RBI 屬於零信任架構的一環，即使網頁有惡意程式，也不會在使用者電腦上執行。

</details>

---

> **Q：** 物聯網設備常用的遠端管理設定，包含 Telnet 與 SSH，請問下列何項敘述正確？
> - \(A\) Telnet 較安全，使用 Port 22
> - \(B\) SSH 較安全，使用 Port 22
> - \(C\) Telnet 較安全，使用 Port 23
> - \(D\) SSH 較安全，使用 Port 23

<details>
<summary>查看答案</summary>

**\(B\) SSH 較安全，使用 Port 22**

SSH 提供加密傳輸，Telnet 是明文傳輸，不安全。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ Telnet 不安全，且 Port 22 是 SSH |
| B | ✅ SSH 加密傳輸，使用 Port 22 |
| C | ❌ Telnet 不安全 |
| D | ❌ Port 23 是 Telnet |

| 協定 | Port | 傳輸方式 | 安全性 |
|:-----|:----:|:---------|:------:|
| Telnet | 23 | 明文 | ❌ |
| SSH | 22 | 加密 | ✅ |

> ⚠️ Telnet 應避免使用，改用 SSH 進行遠端管理。

</details>

---

## 2.2 作業系統與應用程式安全

### 2.2.1 作業系統安全

#### 基本安全設定

**帳號管理：**
- 停用或刪除不必要的帳號
- 停用預設帳號（如 Guest、Administrator）
- 離職人員帳號應立即停用

**密碼政策：**

| 項目 | 建議設定 |
|:-----|:---------|
| 密碼長度 | 至少 12 字元以上 |
| 複雜度 | 大小寫字母、數字、特殊符號組合 |
| 密碼歷程 | 記住前 N 組密碼，禁止重複使用 |
| 錯誤鎖定 | 連續錯誤 3-5 次後鎖定帳號 |
| 預設密碼 | 首次登入必須強制變更 |

> ⚠️ **預設帳密必須立即變更**，這是最常見的安全設定錯誤。

**權限設定：**
- 遵循最小權限原則
- 一般作業不使用管理者帳號

**稽核記錄：**
- 啟用登入/登出、權限變更、系統事件記錄

**漏洞修補：**
- 定期更新系統與應用程式

---

#### 系統強化（Hardening）

**強化原則：** 最小化安裝、最小化服務、最小化權限

| 項目 | 說明 |
|:-----|:-----|
| 服務最小化 | 關閉非必要服務、移除非必要工具 |
| 連接埠管理 | 僅開放必要 Port |
| 帳號管理 | 禁用預設帳號、禁止 root 直接登入 |
| 密碼政策 | 密碼複雜度、錯誤鎖定（fail2ban） |
| 防火牆 | 限制存取來源（iptables / firewalld） |
| 系統更新 | 定期修補漏洞 |
| 組態基準 | 政府組態基準（GCB） |

> ⚠️ 掃描工具（如 nmap）、編譯器等非必要工具應從生產環境移除，避免被攻擊者利用。

---

#### 端點防護

防毒軟體、主機型防火牆、EDR/XDR 解決方案、應用程式白名單

| 控制方式 | 說明 | 防護效果 |
|:---------|:-----|:--------:|
| 白名單 | 僅允許已核准的軟體執行，其餘全擋 | 較嚴格 |
| 黑名單 | 僅阻擋已知惡意軟體，其餘放行 | 較寬鬆 |

> 💡 白名單可有效防止未授權軟體與零時差攻擊，但管理成本較高。

---

### 2.2.2 作業系統與應用程式攻擊手法

#### 公開來源情報 (OSINT)

| 工具 | 用途 |
|------|------|
| Google Hacking | 搜尋引擎找敏感資訊 |
| Shodan | 搜尋連網設備 |
| Censys | 網路資產探測 |

#### 網路協議攻擊

| 攻擊 | 說明 |
|------|------|
| ARP 欺騙 | 偽造 ARP 回應，攔截流量 |
| IP 欺騙 | 偽造來源 IP |
| DNS 快取汙染 | 植入假的 DNS 記錄 |
| 中間人攻擊 (MITM) | 攔截並可能竄改雙方通訊 |
| 重送攻擊 | 重複播放已截取的合法請求 |

#### Web 應用程式攻擊

| 攻擊 | 手法 | 防禦 |
|------|------|------|
| SQL Injection | `' OR '1'='1` | 參數化查詢、預存程序 |
| XSS | `<script>alert('x')</script>` | 輸出編碼、CSP、HttpOnly Cookie |
| CSRF | 冒充用戶發送請求 | CSRF Token、SameSite Cookie |
| Command Injection | 使用 `&`, `;`, `\|` 執行系統命令 | 避免呼叫 Shell、白名單輸入 |
| 目錄遍歷 | `../../etc/passwd` | 路徑白名單、過濾 `..` |
| 緩衝區溢位 | 輸入超長字串覆蓋記憶體 | 邊界檢查、DEP/ASLR |

#### 阻斷服務攻擊 (DoS/DDoS)

| 類型 | 範例 | 防禦 |
|------|------|------|
| 流量型 | DNS 放大攻擊 | CDN、流量清洗 |
| 資源消耗型 | SYN Flood | SYN Cookie、WAF |

#### DoS / DDoS 防護措施

| 措施 | 說明 | 防護對象 |
|:-----|:-----|:--------:|
| Rate Limiting（速率限制） | 限制單一 IP 的請求頻率 | DoS |
| CDN（內容傳遞網路） | 分散流量至多個節點 | DDoS |
| WAF（網頁應用防火牆） | 過濾惡意請求 | 兩者 |
| 黑洞路由（Blackhole） | 將攻擊流量導入黑洞丟棄 | DDoS |
| Anycast | 將流量分散到多個資料中心 | DDoS |

##### 社交工程攻擊

| 類型 | 說明 |
|:-----|:-----|
| Phishing（網路釣魚） | 大量散發釣魚信 |
| Spear Phishing（魚叉式釣魚） | 針對特定員工 |
| Whaling（捕鯨攻擊） | 針對高階主管 |
| BEC（商業電子郵件詐騙） | 偽造或入侵高層郵件，誘騙匯款或洩密 |
| Deepfake（深偽攻擊） | AI 偽造影音 |

**防禦措施：**
- 教育訓練、定期演練
- Out of Band 確認（透過不同管道確認請求真實性）
- 郵件驗證（SPF、DKIM、DMARC）

> 💡 **BEC vs Phishing**：Phishing 是大量散發，BEC 是針對性詐騙，通常冒充高層要求匯款或機密資料。

#### 惡意程式類型

| 類型 | 說明 |
|------|------|
| 病毒 (Virus) | 需依附宿主檔案 |
| 蠕蟲 (Worm) | 可自我複製傳播 |
| 木馬 (Trojan) | 偽裝成正常程式 |
| 勒索軟體 (Ransomware) | 加密資料勒索 → 最佳防禦是離線備份 |
| Rootkit | 隱藏自身的惡意程式 |
| 無檔案惡意程式 | 僅存在記憶體，透過 PowerShell 等執行 |

#### 密碼攻擊

| 攻擊 | 說明 |
|------|------|
| 暴力破解 | 嘗試所有可能組合 |
| 字典攻擊 | 使用常見密碼清單 |
| 密碼噴灑 | 用少數常見密碼對大量帳號測試 |
| 憑證填充 | 用外洩的帳密嘗試登入其他網站 |

#### 進階威脅

- **APT (進階持續性威脅)**：長期潛伏、目標式攻擊
- **零時差攻擊 (Zero-day)**：利用尚未修補的漏洞
- **旁路攻擊**：透過時間、功耗等旁路資訊推測機密

#### 惡意程式反偵測技術

| 技術類型 | 目的 | 範例 |
|:---------|:-----|:-----|
| 沙盒偵測 | 判斷是否在分析環境中執行 | 檢查運行時間、虛擬機特徵、人機互動 |
| 程式碼混淆 | 防止靜態分析 | 加密、多型變形（Polymorphic） |
| 反除錯 | 防止動態分析 | 偵測除錯器、斷點 |

#### Cyber Kill Chain（網路攻擊鏈）

偵查 → 武器化 → 投遞 → 利用 → 安裝 → 指揮控制 (C2) → 行動達標

#### MITRE 安全框架

| 框架 | 用途 | 說明 |
|:-----|:-----|:-----|
| ATT&CK | 攻擊行為 | 描述攻擊者的戰術與技術 |
| D3FEND | 防禦對策 | 對應 ATT&CK 的防禦技術矩陣 |
| ENGAGE | 對抗參與 | 欺敵、誘捕等主動防禦策略 |

**ATT&CK 矩陣結構：**
- 橫向為**戰術（Tactic）**：攻擊者要達成的階段目標
- 縱向為**技術（Technique）**：達成目標的方法手段

---

### 2.2.3 程式與開發安全

#### 測試左移

在軟體開發初期就提早進行測試，以提前發現問題、降低修復成本。

#### 安全軟體開發生命週期 (SSDLC)

需求 → 設計（威脅建模）→ 開發 → 測試 → 部署 → 維護
> SSDLC為每個階段加入資安考量

#### 軟體測試層級

| 測試 | 說明 |
|------|------|
| 單元測試 | 測試最小單元（函式/模組） |
| 整合測試 | 測試模組間介面與互動 |
| 系統測試 | 測試完整系統功能與效能 |
| 驗收測試 | 使用者確認符合需求 |

#### 軟體測試類型

| 測試類型 | 說明 | 屬於安全檢測 |
|:---------|:-----|:------------:|
| SAST（靜態應用安全測試） | 分析原始碼找出漏洞 | ✅ |
| DAST（動態應用安全測試） | 執行中測試應用程式弱點 | ✅ |
| 白箱測試 （White Box Testing） | 可看到原始碼進行測試 | ✅ |
| 黑箱測試 （Black Box Testing） | 不看原始碼，從外部測試 | ✅ |
| 冒煙測試（Smoke Testing） | 快速驗證基本功能是否正常 | ❌ |
| 回歸測試（Regression Testing） | 確認修改後舊功能仍正常 | ❌ |

#### 安全開發原則

| 原則 | 說明 |
|:-----|:-----|
| 輸入驗證 | 驗證並淨化所有使用者輸入 |
| 伺服器端驗證 | 授權檢查、輸入驗證必須在伺服器端執行 |
| 最小權限 | 程式僅請求必要的系統權限 |
| 預設安全 | 預設關閉非必要功能 |
| 縱深防禦 | 多層防護，不依賴單一控制 |

> ⚠️ **永遠不要只依賴客戶端驗證**：客戶端驗證可被繞過，伺服器端驗證才是安全保障。

---
#### 範例題目

> **Q：** 下列哪一種攻擊手法主要是透過大量的請求來使目標系統無法正常運作？
> - \(A\) 魚叉式釣魚（Spear phishing）攻擊
> - \(B\) 阻斷式服務（Denial of Service，DoS）攻擊
> - \(C\) 中間人（Man-in-the-Middle，MITM）攻擊
> - \(D\) SQL 注入（SQL Injection）攻擊

<details>
<summary>查看答案</summary>

**\(B\) 阻斷式服務（Denial of Service，DoS）攻擊**

DoS 攻擊透過大量請求耗盡目標系統資源，導致無法提供正常服務。

| 攻擊手法 | 目的 |
|:---------|:-----|
| 魚叉式釣魚 | 針對特定目標騙取機密資訊 |
| DoS/DDoS | 癱瘓系統，破壞可用性 |
| 中間人攻擊 | 攔截並竄改通訊內容 |
| SQL Injection | 竊取或竄改資料庫資料 |

</details>

---

> **Q：** 下列何者最能描述「ARP 詐騙（ARP Spoofing）」的攻擊手法？
> - \(A\) 改寫目標伺服器上的帳號密碼
> - \(B\) 竄改 DNS 伺服器的 IP 紀錄
> - \(C\) 竄改區域網路中 MAC 與 IP 對應
> - \(D\) 強行中斷 TCP 三向交握（Three-way Handshake）

<details>
<summary>查看答案</summary>

**\(C\) 竄改區域網路中 MAC 與 IP 對應**

ARP 詐騙是攻擊者在區域網路中發送偽造的 ARP 回應，將自己的 MAC 位址與目標 IP 綁定，藉此攔截或竄改流量。

| 選項 | 對應攻擊 |
|:----:|:---------|
| A | 帳號破解/權限提升 |
| B | DNS 快取汙染 |
| C | ✅ ARP 詐騙 |
| D | SYN Flood 攻擊 |

> 💡 ARP 詐騙常用於發動**中間人攻擊（MITM）**，攔截同一網段內的通訊。

</details>

---

> **Q：** 當突然發現區域網路中，有大量的電腦連線並傳輸不明的資料時，請問最有可能是下列何種網路攻擊？
> - \(A\) 分散式阻斷服務攻擊（Distributed Denial-of-service Attack，DDoS）
> - \(B\) 中間人攻擊（Man-in-the-Middle Attack，MITM）
> - \(C\) 蠕蟲（Worms）
> - \(D\) 鍵盤側錄（Keylogging / Keystroke Logging）

<details>
<summary>查看答案</summary>

**\(C\) 蠕蟲（Worms）**

蠕蟲的特性是**可自我複製並主動傳播**，會在區域網路中快速擴散感染多台電腦，造成大量異常流量。

| 攻擊類型 | 特徵 |
|:---------|:-----|
| DDoS | 對外部目標發起大量請求 |
| MITM | 攔截雙方通訊，流量不會異常增加 |
| 蠕蟲 | ✅ 自我複製、快速擴散、大量內部流量 |
| 鍵盤側錄 | 僅記錄按鍵，不產生大量流量 |

> 💡 蠕蟲與病毒的差異：蠕蟲**不需依附宿主檔案**，可獨立傳播。

</details>

---

> **Q：** 在網路通訊中，中間人攻擊（Man-in-the-Middle Attack）的主要目的是下列何項？
> - \(A\) 癱瘓目標系統
> - \(B\) 竊取或竄改通訊內容
> - \(C\) 感染惡意程式
> - \(D\) 偽造 IP 位址

<details>
<summary>查看答案</summary>

**\(B\) 竊取或竄改通訊內容**

中間人攻擊是攻擊者插入通訊雙方之間，攔截並可能竄改傳輸的資料。

| 選項 | 對應攻擊類型 |
|:----:|:-------------|
| A | DoS/DDoS 攻擊 |
| B | ✅ 中間人攻擊 |
| C | 惡意程式攻擊 |
| D | IP 欺騙（IP Spoofing） |

> 💡 MITM 常見手法：ARP 欺騙、DNS 劫持、SSL 剝離等。防禦方式：使用 HTTPS、憑證驗證。

</details>

---

> **Q：** 在作業系統安全防護中，為了降低勒索病毒（Ransomware）的影響，下列何種作法最為有效？
> - \(A\) 停用所有網路連線以阻止病毒傳播
> - \(B\) 定期備份重要資料，並存放於離線或雲端安全儲存空間
> - \(C\) 只安裝作業系統更新，不安裝應用程式更新
> - \(D\) 透過簡單密碼來保護系統，減少複雜性

<details>
<summary>查看答案</summary>

**\(B\) 定期備份重要資料，並存放於離線或雲端安全儲存空間**

勒索軟體會加密資料並勒索贖金，**離線備份**是最有效的復原手段。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 過於極端，影響正常運作 |
| B | ✅ 離線備份可確保資料不被加密 |
| C | ❌ 應用程式更新同樣重要 |
| D | ❌ 簡單密碼反而增加風險 |

> 💡 **3-2-1 備份原則**：3 份副本、2 種媒體、1 份異地/離線，是對抗勒索軟體的最佳策略。

</details>

---

> **Q：** 下列有關網路釣魚（Phishing）的敘述何者正確？
> - \(A\) 主要透過加密程式來加密受害者電腦中的檔案
> - \(B\) 通常利用社交工程手法，偽裝成可信賴的實體，誘使受害者提供敏感資訊
> - \(C\) 攻擊途徑只會發生在電子郵件中，無法在社交媒體或簡訊中發現
> - \(D\) 安裝並更新防毒軟體可完全阻止網路釣魚攻擊

<details>
<summary>查看答案</summary>

**\(B\) 通常利用社交工程手法，偽裝成可信賴的實體，誘使受害者提供敏感資訊**

網路釣魚是一種社交工程攻擊，透過偽裝成可信來源騙取機密資訊。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 加密檔案是勒索軟體特徵 |
| B | ✅ 釣魚攻擊的核心手法 |
| C | ❌ 釣魚可透過 Email、簡訊（Smishing）、社群媒體等多種管道 |
| D | ❌ 防毒軟體無法完全阻止社交工程攻擊 |

> 💡 釣魚攻擊的最佳防禦是**教育訓練**與**提高警覺**，技術控制只能輔助。

</details>

---

> **Q：** 在管理非法軟體使用時，下列何項最能有效防止員工安裝未授權軟體？
> - \(A\) 允許員工自行安裝軟體，但定期進行系統掃描和審計以確保合規
> - \(B\) 採用應用程式白名單，僅允許經批准的軟體安裝並限制其他軟體執行
> - \(C\) 定期檢查已安裝軟體，並由 IT 部門手動移除未授權軟體
> - \(D\) 設置軟體下載和安裝警告系統，提醒員工遵守公司政策

<details>
<summary>查看答案</summary>

**\(B\) 採用應用程式白名單，僅允許經批准的軟體安裝並限制其他軟體執行**

應用程式白名單是**預防性控制**，從源頭阻止未授權軟體執行，效果最佳。

| 選項 | 控制類型 | 效果 |
|:----:|:--------:|:-----|
| A | 檢測性 | 事後發現，無法預防 |
| B | 預防性 | ✅ 從源頭阻止，最有效 |
| C | 糾正性 | 事後處理，效率低 |
| D | 威懾性 | 僅提醒，無強制力 |

> 💡 白名單 vs 黑名單：白名單「只允許已知好的」，黑名單「只阻擋已知壞的」，白名單防護更嚴格。

</details>

---

> **Q：** 下列何項較「不」屬於作業系統上常見的惡意程式？
> - \(A\) 電腦病毒與蠕蟲（Viruses & Worms）
> - \(B\) 特洛依木馬程式（Trojan）
> - \(C\) 間諜軟體與廣告軟體（Spyware & Adware）
> - \(D\) 網路釣魚郵件（Phishing）的連結

<details>
<summary>查看答案</summary>

**\(D\) 網路釣魚郵件（Phishing）的連結**

網路釣魚是「**社交工程攻擊**」，透過欺騙手法誘騙使用者，本身不是惡意程式。

| 選項 | 類型 |
|:----:|:-----|
| A | ✅ 惡意程式 |
| B | ✅ 惡意程式 |
| C | ✅ 惡意程式 |
| D | ❌ 社交工程攻擊 |

> 💡 釣魚郵件的連結可能「導向」惡意程式下載，但連結本身不是惡意程式。

</details>

---

> **Q：** XSS（Cross-Site-Scripting）與 SQLi（SQL Injection）兩種攻擊方式均與輸入程式碼有關。請問關於這兩種攻擊的差別，下列敘述何項最為適當？
> - \(A\) SQLi 是一種用於攻擊 SQL 資料庫的駭客手法，而 XSS 攻擊可以存在於許多不同類型的程式語言，如 Python
> - \(B\) XSS 攻擊用於從資料庫竊取資料，而 SQLi 攻擊用於將使用者重定向到攻擊者可以從中竊取資料的網站
> - \(C\) XSS 是一種用於攻擊 SQL 資料庫的駭客手法，而 SQLi 攻擊可以存在於許多不同類型的應用程式中
> - \(D\) SQLi 攻擊用於從資料庫竊取資料，而 XSS 攻擊用於將使用者重定向到攻擊者可以從中竊取資料的網站

<details>
<summary>查看答案</summary>

**\(D\) SQLi 攻擊用於從資料庫竊取資料，而 XSS 攻擊用於將使用者重定向到攻擊者可以從中竊取資料的網站**

| 攻擊 | 攻擊目標 | 執行位置 | 主要危害 |
|:----:|:---------|:---------|:---------|
| SQLi | 資料庫 | 伺服器端 | 竊取/竄改資料庫資料 |
| XSS | 使用者瀏覽器 | 客戶端 | 竊取 Cookie、重定向、冒用身分 |

> 💡 **關鍵差異**：SQLi 攻擊的是「伺服器端資料庫」，XSS 攻擊的是「客戶端瀏覽器」。

</details>

---

> **Q：** 下列何項觀點才是正確的程式安全開發的精神？
> - \(A\) 可以交由工具來把關，針對掃出來的問題進行修復即可
> - \(B\) 資料都有加密儲存，而且透過安全通道傳輸，所以不會有問題
> - \(C\) 時間目標才是王道，安全是額外附加，所以最後再考慮
> - \(D\) 遵循安全開發指引，於寫程式初期即考量安全設計的概念

<details>
<summary>查看答案</summary>

**\(D\) 遵循安全開發指引，於寫程式初期即考量安全設計的概念**

這就是「**測試左移（Shift Left）**」的精神，在開發初期就納入安全考量，而非事後補救。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 工具只是輔助，無法取代安全設計 |
| B | ❌ 加密與安全通道只是部分控制，無法涵蓋所有風險 |
| C | ❌ 安全應從一開始考量，事後修補成本更高 |
| D | ✅ 符合 SSDLC 精神 |

> 💡 **修補成本法則**：越晚發現問題，修補成本越高。需求階段修復成本是上線後的 1/100。

</details>

---

> **Q：** 在安全開發的最佳實踐中，為了防止使用者輸入惡意內容導致安全漏洞，開發者應該採取下列哪一種措施？
> - \(A\) 將使用者的輸入直接以常數的方式撰寫在原始碼（Hard-Coding）
> - \(B\) 將使用者輸入的資料直接儲存在資料庫中
> - \(C\) 驗證（Validation）並淨化（Sanitization）所有使用者輸入
> - \(D\) 僅針對管理員帳號檢查輸入

<details>
<summary>查看答案</summary>

**\(C\) 驗證（Validation）並淨化（Sanitization）所有使用者輸入**

安全開發的基本原則：**永不信任使用者輸入**，所有輸入都必須經過驗證與淨化。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ Hard-Coding 無法處理動態輸入，且維護困難 |
| B | ❌ 直接儲存可能導致 SQL Injection 等攻擊 |
| C | ✅ 輸入驗證與淨化是防禦注入攻擊的關鍵 |
| D | ❌ 所有使用者輸入都應檢查，不分角色 |

| 處理方式 | 說明 |
|:---------|:-----|
| 驗證（Validation） | 檢查輸入格式、長度、範圍是否符合預期 |
| 淨化（Sanitization） | 移除或轉義危險字元，防止注入攻擊 |

</details>

---

> **Q：** 下列何項「不」屬於程式開發過程中的安全檢測項目？
> - \(A\) 動態應用系統安全測試 DAST（Dynamic Application Security Testing）
> - \(B\) 系統冒煙測試（Smoke Testing）
> - \(C\) 原始碼測試（Source Code Testing）
> - \(D\) 白箱測試（White Box Testing）

<details>
<summary>查看答案</summary>

**\(B\) 系統冒煙測試（Smoke Testing）**

冒煙測試是快速驗證系統基本功能是否正常運作，屬於**功能測試**，而非安全檢測。

| 選項 | 測試類型 | 安全檢測 |
|:----:|:---------|:--------:|
| A | DAST 動態安全測試 | ✅ |
| B | 冒煙測試 | ❌ |
| C | 原始碼測試（SAST） | ✅ |
| D | 白箱測試 | ✅ |

> 💡 「冒煙測試」名稱源自硬體測試：通電後沒冒煙就代表基本功能正常。

</details>

---

> **Q：** 為了躲避安全研究人員的分析與惡意軟體偵測機制，某些惡意程式會嘗試偵測自己是否執行於沙盒環境（Sandbox）內，並在偵測到時隱藏或延遲執行惡意行為。下列何種方法「不」是惡意程式常見的沙盒偵測技術？
> - \(A\) 檢查系統運行時間是否極短，以判斷是否為剛啟動的虛擬環境
> - \(B\) 嘗試存取特定的虛擬機或沙箱環境特徵，如硬體資訊
> - \(C\) 檢查是否有鍵盤或滑鼠輸入活動，以確認系統是否由真人操作
> - \(D\) 自動將自身程式碼重新加密以防止靜態分析

<details>
<summary>查看答案</summary>

**\(D\) 自動將自身程式碼重新加密以防止靜態分析**

程式碼加密是「**反分析/混淆技術**」，用於防止靜態分析，而非偵測沙盒環境。

| 選項 | 技術類型 | 沙盒偵測 |
|:----:|:---------|:--------:|
| A | 檢查系統運行時間 | ✅ |
| B | 檢查虛擬機硬體特徵 | ✅ |
| C | 檢查人機互動 | ✅ |
| D | 程式碼加密混淆 | ❌ |

> 💡 沙盒偵測的目的是「判斷環境」，程式碼加密的目的是「隱藏行為」，兩者目的不同。

</details>

---

> **Q：** 下列何項「不」是常用來觀察駭客攻擊行為的模型（Models）？
> - \(A\) MITRE ATT&CK
> - \(B\) MITRE D3FEND
> - \(C\) MITRE ENGAGE
> - \(D\) MITRE DEFEND

<details>
<summary>查看答案</summary>

**\(D\) MITRE DEFEND**

MITRE DEFEND 不存在，是虛構的名稱。

| 框架 | 用途 | 真實存在 |
|:-----|:-----|:--------:|
| ATT&CK | 攻擊者戰術與技術矩陣 | ✅ |
| D3FEND | 防禦技術矩陣 | ✅ |
| ENGAGE | 主動對抗策略（欺敵、誘捕） | ✅ |
| DEFEND | 不存在 | ❌ |

> 💡 D3FEND 是「D」efensive，與 ATT&CK 互補；DEFEND 是虛構名稱，注意拼法差異。

</details>

---

> **Q：** 關於密碼（Password）要求的描述，下列何項最「不」適切？
> - \(A\) 於不同之應用系統中，系統管理者不使用相同密碼
> - \(B\) 即使是系統管理者帳號，密碼不與任何人共享使用
> - \(C\) 為了套裝軟體維護上的安全要求，由廠商預先提供之密碼，不要隨意變更
> - \(D\) 當使用密碼作為系統登入鑑別資訊時，需套用高強度密碼

<details>
<summary>查看答案</summary>

**\(C\) 為了套裝軟體維護上的安全要求，由廠商預先提供之密碼，不要隨意變更**

廠商預設密碼是公開資訊，**必須立即變更**，否則容易被攻擊者利用。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ 不同系統使用不同密碼，防止撞庫攻擊 |
| B | ✅ 密碼不共享，確保可歸責性 |
| C | ❌ 預設密碼必須立即變更 |
| D | ✅ 高強度密碼可抵抗暴力破解 |

> ⚠️ 使用預設密碼是常見的安全設定錯誤，屬於 OWASP Top 10「A02 安全設定錯誤」。

</details>

---

> **Q：** 關於應用程式之授權檢查（Authorization Checks）最佳實務，下列何項描述最為適切？
> - \(A\) 僅在客戶端（Client-side）執行，以提升使用者體驗
> - \(B\) 僅在使用者首次登入時執行一次，以提升伺服器效能
> - \(C\) 必須在伺服器端（Server-side）執行，以提昇安全性
> - \(D\) 可由使用者自行選擇是否執行，以兼顧便利與安全性

<details>
<summary>查看答案</summary>

**\(C\) 必須在伺服器端（Server-side）執行，以提昇安全性**

授權檢查必須在伺服器端執行，因為客戶端驗證可被攻擊者繞過或竄改。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 客戶端驗證可被繞過，不安全 |
| B | ❌ 授權應每次請求都檢查，非僅登入時 |
| C | ✅ 伺服器端驗證無法被使用者繞過 |
| D | ❌ 安全機制不應由使用者決定是否執行 |

| 驗證位置 | 安全性 | 說明 |
|:---------|:------:|:-----|
| 客戶端 | ❌ | 可被繞過、竄改 |
| 伺服器端 | ✅ | 使用者無法直接控制 |
| 兩者都做 | ✅✅ | 客戶端提升體驗，伺服器端確保安全 |

> 💡 客戶端驗證是為了「使用者體驗」，伺服器端驗證是為了「安全性」，兩者目的不同。

</details>

---

> **Q：** 下列何項攻擊手法的目的是要破解密碼？
> - \(A\) 阻斷服務攻擊
> - \(B\) 網路連線攻擊
> - \(C\) 後門攻擊
> - \(D\) 字典攻擊

<details>
<summary>查看答案</summary>

**\(D\) 字典攻擊**

字典攻擊是利用常見密碼清單逐一嘗試，目的是破解密碼。

| 選項 | 攻擊目的 |
|:----:|:---------|
| A | 癱瘓服務（破壞可用性） |
| B | 攔截或干擾網路連線 |
| C | 建立隱藏存取管道 |
| D | ✅ 破解密碼 |

| 密碼攻擊類型 | 說明 |
|:-------------|:-----|
| 字典攻擊 | 使用常見密碼清單嘗試 |
| 暴力破解 | 窮舉所有可能組合 |
| 彩虹表攻擊 | 預先計算的雜湊對照表 |
| 撞庫攻擊 | 利用外洩的帳密嘗試其他網站 |

</details>

---

> **Q：** 關於 SQL 注入（SQL Injection）攻擊的描述，下列何者較為適當？
> - \(A\) 使網站無法訪問
> - \(B\) 竊取電腦重要檔案
> - \(C\) 在資料庫中執行惡意 SQL 語句
> - \(D\) 破壞網路設備

<details>
<summary>查看答案</summary>

**\(C\) 在資料庫中執行惡意 SQL 語句**

SQL Injection 是透過輸入惡意 SQL 語句，讓資料庫執行非預期的指令。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 使網站無法訪問是 DoS 攻擊 |
| B | ❌ 竊取檔案可能是木馬或其他攻擊 |
| C | ✅ SQL Injection 的核心手法 |
| D | ❌ 破壞網路設備與 SQL Injection 無關 |

| SQL Injection 可能造成的危害 |
|:----------------------------|
| 繞過身分驗證（登入繞過） |
| 竊取資料庫內容 |
| 竄改或刪除資料 |
| 執行系統指令（進階攻擊） |

</details>

---

> **Q：** 下列何種攻擊方式會利用大量偽造的網路流量，癱瘓目標伺服器？
> - \(A\) 分散式阻斷服務（DDoS）
> - \(B\) 社交工程（Social Engineering）
> - \(C\) 跨網站指令碼（XSS）
> - \(D\) SQL 注入（SQL Injection）

<details>
<summary>查看答案</summary>

**\(A\) 分散式阻斷服務（DDoS）**

DDoS 透過多個來源發送大量偽造流量，耗盡目標伺服器資源，使其無法正常服務。

| 選項 | 攻擊目標 |
|:----:|:---------|
| A | ✅ 癱瘓伺服器（破壞可用性） |
| B | 欺騙人員取得資訊 |
| C | 攻擊使用者瀏覽器 |
| D | 攻擊資料庫 |

| 比較 | DoS | DDoS |
|:-----|:----|:-----|
| 攻擊來源 | 單一來源 | 多個分散來源 |
| 流量規模 | 較小 | 大量 |
| 防禦難度 | 較易阻擋 | 難以阻擋 |

</details>

---

> **Q：** 為了讓作業系統變得更安全、更難以入侵，通常企業會對作業系統進行安全強化（Harden），下列何項不是 Linux 作業系統經常採用的安全強化機制？
> - \(A\) 設定密碼原則、登入錯誤次數限制，並且使用 fail2ban 服務將登入錯誤次數太多的使用者列入黑名單
> - \(B\) 關閉所有非必要的系統服務與通訊協定，但是保留 nmap，以便進行自我掃描跟檢測
> - \(C\) 禁止使用 root 帳號登入 SSH 服務，只能使用一般使用者的帳號，若要提升權限變成 root 則必須使用 sudo 指令
> - \(D\) 使用 iptables 防火牆功能限制存取來源，讓連線來源最小化

<details>
<summary>查看答案</summary>

**\(B\) 關閉所有非必要的系統服務與通訊協定，但是保留 nmap，以便進行自我掃描跟檢測**

nmap 是網路掃描工具，在生產環境中不應保留，可能被攻擊者利用來探測網路。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ 密碼政策 + fail2ban 是常見強化措施 |
| B | ❌ nmap 應移除，非必要工具不應保留 |
| C | ✅ 禁止 root SSH 登入是最佳實踐 |
| D | ✅ iptables 限制來源是常見強化措施 |

**Linux 常見強化措施：**
- 密碼政策與帳號鎖定（fail2ban）
- 關閉非必要服務與 Port
- 禁止 root 直接登入 SSH
- 使用防火牆限制存取來源（iptables / firewalld）
- 移除非必要的工具與套件

> 💡 系統強化原則：**最小化安裝、最小化服務、最小化權限**。

</details>

---

> **Q：** 網路釣魚的常見手法，「不」包含下列何項？
> - \(A\) 中間人攻擊（Man-in-the-Middle）
> - \(B\) 類似的網域名稱
> - \(C\) 吸引人的優惠
> - \(D\) 帳號鎖定通知

<details>
<summary>查看答案</summary>

**\(A\) 中間人攻擊（Man-in-the-Middle）**

中間人攻擊是攔截通訊的技術性攻擊，而網路釣魚是利用社交工程欺騙使用者的手法。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 中間人攻擊是網路攻擊，非釣魚手法 |
| B | ✅ 假冒網域名稱（如 g00gle.com） |
| C | ✅ 利用優惠誘騙點擊 |
| D | ✅ 製造緊迫感讓人點擊 |

**網路釣魚常見手法：**

| 手法 | 說明 |
|:-----|:-----|
| 偽造網域 | 使用相似網域名稱混淆視聽 |
| 緊急通知 | 帳號鎖定、密碼過期等製造緊迫感 |
| 利益誘惑 | 中獎、優惠、免費贈品 |
| 冒充身分 | 偽裝成銀行、政府、主管 |

</details>

---

> **Q：** 下列哪一種攻擊手法試圖利用作業系統對於記憶體存取的管理不當，透過將惡意程式碼注入到應用程式的記憶體空間中，從而執行未經授權的操作？
> - \(A\) 中間人攻擊（Man-in-the-Middle）
> - \(B\) 緩衝區溢位攻擊（Buffer Overflow Attack）
> - \(C\) 分散式拒絕服務攻擊（DDoS）
> - \(D\) 旁通道攻擊（Side-channel Attack）

<details>
<summary>查看答案</summary>

**\(B\) 緩衝區溢位攻擊（Buffer Overflow Attack）**

緩衝區溢位是利用程式未檢查輸入長度的漏洞，將惡意程式碼注入記憶體並執行。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 中間人攻擊是攔截通訊，非記憶體攻擊 |
| B | ✅ 利用記憶體管理不當注入惡意程式碼 |
| C | ❌ DDoS 是癱瘓服務，非記憶體攻擊 |
| D | ❌ 旁通道攻擊是透過物理特徵（如耗電、時間）推測資訊 |

| 防禦措施 | 說明 |
|:---------|:-----|
| ASLR | 隨機化記憶體位址配置 |
| DEP / NX | 禁止資料區段執行程式碼 |
| Stack Canary | 堆疊檢查值偵測溢位 |

</details>

---

> **Q：** 下列何項措施最能有效防止阻斷服務攻擊（Denial-of-Service, DoS）？
> - \(A\) 隱藏伺服器的位置
> - \(B\) 使用內容傳遞網路（CDN）
> - \(C\) 限制單個 IP 位址的請求速率
> - \(D\) 啟用伺服器的日誌記錄

<details>
<summary>查看答案</summary>

**\(C\) 限制單個 IP 位址的請求速率**

Rate Limiting 可限制單一來源的請求頻率，直接阻止 DoS 攻擊。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 隱藏位置無法防止已知 IP 被攻擊 |
| B | ⚠️ CDN 對 DDoS 較有效，對單一來源 DoS 效果有限 |
| C | ✅ Rate Limiting 直接限制單一 IP 請求頻率 |
| D | ❌ 日誌記錄是偵測，無法防止攻擊 |

| 攻擊類型 | 最有效防護 |
|:---------|:-----------|
| DoS（單一來源） | Rate Limiting |
| DDoS（分散來源） | CDN、Anycast |

</details>

---

> **Q：** 在 Web 應用程式中，若未對使用者輸入進行適當的驗證與過濾，攻擊者可能利用下列何種攻擊方法，輸入惡意資料進而未經授權地存取或修改資料庫中的資料？
> - \(A\) 跨站腳本攻擊（Cross-Site Scripting, XSS）
> - \(B\) SQL 注入攻擊（SQL Injection）
> - \(C\) 跨站請求偽造（Cross-Site Request Forgery, CSRF）
> - \(D\) 釣魚攻擊（Phishing）

<details>
<summary>查看答案</summary>

**\(B\) SQL 注入攻擊（SQL Injection）**

SQL Injection 是透過輸入惡意 SQL 語句，讓資料庫執行非預期的查詢或修改操作。

| 選項 | 攻擊目標 |
|:----:|:---------|
| A | 使用者瀏覽器（注入惡意腳本） |
| B | ✅ 資料庫（注入 SQL 語句） |
| C | 使用者身分（偽造請求） |
| D | 使用者（社交工程欺騙） |

| 攻擊 | 目標 | 防禦 |
|:-----|:-----|:-----|
| SQL Injection | 資料庫 | 參數化查詢、輸入驗證 |
| XSS | 瀏覽器 | 輸出編碼、CSP |
| CSRF | 使用者身分 | CSRF Token |

</details>

---

> **Q：** 下列何項措施最能有效防禦跨站請求偽造（Cross-Site Request Forgery, CSRF）攻擊？
> - \(A\) 在表單中加入隱藏的隨機令牌（Token）
> - \(B\) 對使用者輸入的資料進行編碼
> - \(C\) 使用 HTTPS 協定傳輸資料
> - \(D\) 設置強密碼策略

<details>
<summary>查看答案</summary>

**\(A\) 在表單中加入隱藏的隨機令牌（Token）**

CSRF Token 是隨機產生的令牌，每次請求都需驗證，攻擊者無法取得合法 Token，因此無法偽造請求。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ CSRF Token 是最有效的防禦方式 |
| B | ❌ 輸入編碼是防禦 XSS，非 CSRF |
| C | ❌ HTTPS 保護傳輸機密性，無法防 CSRF |
| D | ❌ 強密碼與 CSRF 無關 |

| CSRF 防禦措施 | 說明 |
|:--------------|:-----|
| CSRF Token | 表單中加入隨機令牌驗證 |
| SameSite Cookie | 限制 Cookie 跨站傳送 |
| Referer 檢查 | 驗證請求來源網域 |

</details>

---

> **Q：** 下列何種攻擊方法是利用網頁的輸入欄位或網址，插入惡意的腳本（Script），使其他使用者在瀏覽該網頁時執行該腳本？
> - \(A\) 跨站腳本攻擊（Cross-Site Scripting, XSS）
> - \(B\) 跨站請求偽造（Cross-Site Request Forgery, CSRF）
> - \(C\) 釣魚攻擊（Phishing）
> - \(D\) 阻斷服務攻擊（Denial-of-Service, DoS）

<details>
<summary>查看答案</summary>

**\(A\) 跨站腳本攻擊（Cross-Site Scripting, XSS）**

XSS 是將惡意腳本注入網頁，當其他使用者瀏覽時，腳本會在其瀏覽器中執行。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ 注入惡意腳本，在使用者瀏覽器執行 |
| B | ❌ CSRF 是偽造請求，非注入腳本 |
| C | ❌ 釣魚是社交工程，非注入攻擊 |
| D | ❌ DoS 是癱瘓服務，非注入攻擊 |

| XSS 類型 | 說明 |
|:---------|:-----|
| Stored XSS（儲存型） | 惡意腳本儲存於伺服器，持續影響 |
| Reflected XSS（反射型） | 惡意腳本透過 URL 參數反射回使用者 |
| DOM-based XSS | 在客戶端 DOM 中執行惡意腳本 |

</details>

---

> **Q：** 在惡意程式的「預防與阻擋」策略中，下列何項技術的核心原則是在個人電腦「預設全部禁止，僅允許明確授權的應用程式執行」，以達到最高的安全性？
> - \(A\) CDR 內容解除與重建（Content Disarm and Reconstruction）
> - \(B\) 應用程式黑名單（Application Blacklisting）
> - \(C\) 網路防火牆（Network Firewall）
> - \(D\) 應用程式白名單（Application Whitelisting）

<details>
<summary>查看答案</summary>

**\(D\) 應用程式白名單（Application Whitelisting）**

白名單的核心原則是「預設拒絕，僅允許明確授權」，安全性最高。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ CDR 是移除檔案中的惡意內容後重建 |
| B | ❌ 黑名單是「預設允許，僅阻擋已知壞的」 |
| C | ❌ 防火牆是網路層控制，非應用程式控制 |
| D | ✅ 白名單是「預設禁止，僅允許明確授權」 |

| 控制方式 | 原則 | 安全性 |
|:---------|:-----|:------:|
| 白名單 | 預設禁止，僅允許已知好的 | 較高 |
| 黑名單 | 預設允許，僅阻擋已知壞的 | 較低 |

> 💡 白名單可有效防止零時差攻擊與未知惡意程式，但管理成本較高。

</details>

---

> **Q：** 為強化 Windows 作業系統安全，使用者在維護作業系統運作穩定性並降低資安風險，採取下列何項是最有效的方式？
> - \(A\) 向原廠購買有效授權
> - \(B\) 購買硬體防火牆進行防護
> - \(C\) 維持網路連線速率與提昇連線品質
> - \(D\) 定期進行更新與修補漏洞

<details>
<summary>查看答案</summary>

**\(D\) 定期進行更新與修補漏洞**

定期更新是防禦已知漏洞最直接有效的方式，可降低被攻擊的風險。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 授權合法性不等於安全性 |
| B | ❌ 防火牆是輔助措施，無法修補系統漏洞 |
| C | ❌ 網路品質與資安防護無直接關係 |
| D | ✅ 修補漏洞是最有效的防護方式 |

> 💡 許多攻擊利用已知漏洞入侵，及時更新可大幅降低風險。

</details>

---

## 2.3 資安維運技術

### 2.3.1 惡意程式防護與弱點管理

#### 資安健診項目

網路架構檢視、網路惡意活動檢視、用戶端電腦惡意活動檢視、伺服器惡意活動檢視、目錄伺服器與防火牆設定檢視

#### 常見工具

| 類型 | 工具 |
|------|------|
| SIEM | Splunk, ArcSight, OSSIM |
| 原始碼掃描 | SonarQube, Checkmarx, Fortify |
| 主機弱掃 | Nessus, OpenVAS |
| 網頁弱掃 | Burp Suite, OWASP ZAP, Nikto |
| 滲透測試 | Nmap, Metasploit, Sqlmap, Wireshark |

#### 弱點相關名詞

| 名詞 | 說明 |
|------|------|
| CWE | 定義軟體常見弱點類型 |
| CVE | 具體標識已發生的漏洞 |
| CVSS | 漏洞嚴重程度評分 |
| NVD | 漏洞資訊與修補建議資料庫 |
| CPE | 指出漏洞影響的軟硬體平台 |
| KEV | CISA 標示已被實際利用的漏洞清單 |

> 💡 只有 4% 的 CVE 被公開利用，但被利用的漏洞中，42% 在揭露當天就被攻擊。

#### OWASP Top 10 (2025)

| 排名 | 風險 | 說明 | 與 2021 比較 |
|------|------|------|--------------|
| A01 | 權限控管失效 (Broken Access Control) | 未檢查權限就允許存取，SSRF 併入此類別 | 維持第 1 |
| A02 | 安全設定錯誤 (Security Misconfiguration) | 使用預設設定、暴露管理介面、不必要的服務 | ⬆️ 從第 5 升 |
| A03 | 軟體供應鏈失敗 (Software Supply Chain Failures) | 第三方元件漏洞、惡意套件、建置流程遭入侵 | 🆕 新類別 |
| A04 | 密碼學失誤 (Cryptographic Failures) | 敏感資料未加密或使用過時演算法 | ⬇️ 從第 2 降 |
| A05 | 注入攻擊 (Injection) | SQL/Command/Code Injection | ⬇️ 從第 3 降 |
| A06 | 不安全設計 (Insecure Design) | 系統架構或邏輯設計缺乏安全考量 | ⬇️ 從第 4 降 |
| A07 | 識別與驗證失效 (Authentication Failures) | 帳號/Session 管理不當，允許身分冒用 | 維持第 7 |
| A08 | 軟體與資料完整性失敗 (Software & Data Integrity Failures) | 未驗證更新、CI/CD 流程、外部模組完整性 | 維持第 8 |
| A09 | 安全記錄與監控失效 (Security Logging & Monitoring Failures) | 缺乏日誌、告警與事件回應機制 | 維持第 9 |
| A10 | 例外狀況處理不當 (Mishandling of Exceptional Conditions) | 錯誤處理不當導致系統崩潰、資料外洩或 DoS | 🆕 新類別 |

> 💡 **常見攻擊歸類：**
> - **XSS** → A05 Injection（注入惡意腳本）
> - **CSRF** → A01 Broken Access Control（偽造請求繞過權限）
> - **SSRF** → A01 Broken Access Control（2021 原為獨立 A10，現併入）
> - **IDOR** → A01 Broken Access Control（不安全的直接物件參考）

#### 滲透測試 vs 弱點掃描

- **弱點掃描**：自動化工具偵測已知漏洞，產出修補清單
- **滲透測試**：人員模擬攻擊，嘗試串聯漏洞驗證實際風險

> 三個低風險漏洞經串聯後，可能導致高風險入侵。

#### 紅藍紫隊

| 角色 | 職責 |
|------|------|
| 紅隊 | 攻擊方，模擬駭客 |
| 藍隊 | 防守方，偵測與回應 |
| 紫隊 | 協調雙方，提供顧問建議 |

#### 軟體供應鏈安全

| 名詞 | 全名 | 說明 |
|:-----|:-----|:-----|
| SBOM | Software Bill of Materials | 軟體物料清單，列出所有使用的元件與版本 |
| SCA | Software Composition Analysis | 軟體組成分析，掃描第三方元件的漏洞與授權 |

> 💡 **SBOM + SCA** 可識別供應鏈中的已知漏洞（如 Log4j），是供應鏈安全的基礎。

---

#### TLP 威脅情資分享標籤（Traffic Light Protocol 2.0）

| 標籤 | 顏色 | 分享範圍 |
|:-----|:-----|:---------|
| TLP:RED | 🔴 紅色 | 僅限特定人員，不可分享 |
| TLP:AMBER | 🟠 琥珀色 | 限組織內部及必要合作夥伴 |
| TLP:GREEN | 🟢 綠色 | 可分享給同業社群 |
| TLP:CLEAR | ⚪ 透明 | 可公開分享 |

> ⚠️ TLP 2.0 將原本的 **WHITE** 改為 **CLEAR**，沒有 BLACK 和 BLUE。

---

### 2.3.2 資料安全及備份管理

#### 資料生命週期

產生 → 儲存 → 使用 → 傳輸 → 銷毀

#### 資料庫保護技術

| 技術 | 類型 | 說明 | 可還原原始資料 |
|:-----|:----:|:-----|:--------------:|
| 透明資料加密 (TDE) | 加密 | 資料庫層級自動加密，應用程式無感 | ✅ 有金鑰可解密 |
| 欄位加密 | 加密 | 針對敏感欄位單獨加密 | ✅ 有金鑰可解密 |
| 檔案加密 | 加密 | 加密整個資料庫檔案 | ✅ 有金鑰可解密 |
| 資料遮罩 (Data Masking) | 遮蔽 | 隱藏部分資料，如 `****1234` | ❌ 無法還原 |

> 💡 **遮罩 vs 加密**：加密是將資料轉換為密文，有金鑰可還原；遮罩是直接隱藏或替換資料，無法還原原始值。

---

### 2.3.3 日誌管理

#### 日誌種類

系統日誌、應用程式日誌、安全性日誌、網路設備日誌

#### 管理機制
- 集中管理
- 保存期限（如資通安全管理法要求 6 個月）
- 完整性保護
- 存取控制
- 容量控制（Log Rotation 日誌輪替）
- 傳輸加密
- 時間同步

> 💡 **Log Rotation（日誌輪替）**：依時間或檔案大小自動切割、歸檔或刪除舊日誌，避免磁碟空間耗盡。

#### 日誌完整性防護

| 面向 | 說明 | 措施範例 |
|:-----|:-----|:---------|
| 事前預防 | 防止日誌被竄改 | 存取控制、唯讀設定 |
| 事中監視 | 即時偵測異常行為 | SIEM 告警、異常偵測 |
| 事後驗證 | 確認日誌未被異動 | 雜湊比對、數位簽章 |

#### 作業系統日誌工具

| 作業系統 | 日誌工具 | 說明 |
|:---------|:---------|:-----|
| Windows | Event Viewer（事件檢視器） | Windows 專用，分為系統、應用程式、安全性日誌 |
| Linux | rsyslogd | 傳統 Syslog 增強版，多數 Linux 預設 |
| Linux | Syslog-NG | 進階日誌管理，支援複雜過濾與轉發 |
| Linux | journald | systemd 的日誌服務 |

#### Syslog 協定

| 標準 | 傳輸協定 | 說明 |
|:-----|:---------|:-----|
| RFC 3164 | UDP 514 | 傳統 Syslog，不可靠傳輸 |
| RFC 5424 | TCP 514 | 新版 Syslog，可靠傳輸 |
| RFC 5425 | TLS 6514 | 加密傳輸 |

> 💡 **Syslog** 是跨平台標準，Windows 需額外安裝代理程式才能使用。

---

#### 範例題目

> **Q：** 下列何項「不」是資料庫的資料加密方式？
> - \(A\) 資料遮罩（Data Masking）
> - \(B\) 透明資料加密（Transparent Data Encryption，TDE）
> - \(C\) 資料欄位加密
> - \(D\) 資料庫檔案加密

<details>
<summary>查看答案</summary>

**\(A\) 資料遮罩（Data Masking）**

資料遮罩是「**遮蔽**」技術，不是「加密」技術。

| 技術 | 類型 | 可還原 |
|:-----|:----:|:------:|
| 資料遮罩 | 遮蔽 | ❌ |
| TDE | 加密 | ✅ |
| 欄位加密 | 加密 | ✅ |
| 檔案加密 | 加密 | ✅ |

> 💡 遮罩是將資料部分隱藏（如身分證顯示 `A123***456`），無法還原；加密則是透過金鑰可解密還原。

</details>

---

> **Q：** OWASP Top 10:2021 是網頁安全領域中經常被拿來參考的弱點種類，請問下列關於 OWASP Top 10:2021 的描述何項錯誤？
> - \(A\) A01:2021 - Broken Access Control：這個種類通常發生在程式沒有做好權限控管，導致可以讀取到其他使用者的資料，甚至可以切換權限
> - \(B\) A03:2021 - Injection：這個種類的弱點風險等級通常偏高，因為無論是 SQL Injection、Command Injection、Code Injection 都有可能造成伺服器資料外洩或是被取得控制權，必須嚴加防範
> - \(C\) A06:2021 - Vulnerable and Outdated Components：這個種類指的是企業的開發人員或系統維運人員沒有定期檢查程式套件、開發框架、作業系統的版本，導致企業使用的版本存在已知的弱點
> - \(D\) A10:2021 - Server-Side Request Forgery（SSRF）：這個種類的弱點經常被用在網路探勘或存取內網資料，不過因為這個種類排在 OWASP Top 10 第十名，威脅性不高，也很難搭配其他弱點一起使用，通常企業不需要優先修補

<details>
<summary>查看答案</summary>

**\(D\) 錯誤**

SSRF 雖排名第十，但威脅性**非常高**，可用於：
- 存取內網敏感資源
- 讀取雲端 Metadata（如 AWS IAM 憑證）
- 搭配其他漏洞進行攻擊鏈

| 錯誤描述 | 正確說明 |
|:---------|:---------|
| 威脅性不高 | ❌ SSRF 可造成嚴重內網滲透 |
| 難搭配其他弱點 | ❌ 常與 RCE、資料外洩組合攻擊 |
| 不需優先修補 | ❌ 應優先處理 |

> ⚠️ OWASP 排名是「普遍性」，不代表「嚴重性」。SSRF 在雲端環境尤其危險。

</details>

---

> **Q：** 面對來自於供應鏈的資安威脅防護，下列敘述何者正確？
> - \(A\) 供應商系統可以開放在網路上，不需要限制來源
> - \(B\) 供應商所提供的軟硬體，要經過測試檢驗方可上線
> - \(C\) 外部採購的軟體可以直接安裝使用
> - \(D\) 軟體供應鏈固定即可不需要評估漏洞風險

<details>
<summary>查看答案</summary>

**\(B\) 供應商所提供的軟硬體，要經過測試檢驗方可上線**

供應鏈安全的核心原則是「不信任、要驗證」，所有外部軟硬體都應經過安全檢驗。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 應限制網路存取來源，遵循最小權限原則 |
| B | ✅ 軟硬體需經測試檢驗才能上線 |
| C | ❌ 外部軟體應先驗證完整性與安全性 |
| D | ❌ 供應鏈需持續監控與評估漏洞風險 |

> 💡 供應鏈攻擊案例：SolarWinds 事件、Log4j 漏洞，皆因信任第三方元件而遭入侵。

</details>

---

> **Q：** 下列何項「不」是常用的弱點分類或評分標準？
> - \(A\) CWE（Common Weakness Enumeration）
> - \(B\) CSRS（Common Security Risk System）
> - \(C\) CVE（Common Vulnerability and Exposure）
> - \(D\) CVSS（Common Vulnerability Scoring System）

<details>
<summary>查看答案</summary>

**\(B\) CSRS（Common Security Risk System）**

CSRS 不是真實存在的標準，是虛構的名稱。

| 名詞 | 說明 | 真實存在 |
|:-----|:-----|:--------:|
| CWE | 定義軟體常見弱點類型 | ✅ |
| CVE | 具體標識已發生的漏洞 | ✅ |
| CVSS | 漏洞嚴重程度評分系統 | ✅ |
| CSRS | 不存在此標準 | ❌ |

> 💡 記憶口訣：**CWE 分類、CVE 編號、CVSS 評分**。

</details>

---

> **Q：** 為了有效防禦惡意程式的入侵，下列哪一種做法最能幫助快速發現並處理可能存在的弱點？
> - \(A\) 一年一度書面審查所有系統和軟體
> - \(B\) 依賴員工在發現問題時主動報告
> - \(C\) 定期執行弱點掃描並立即修復發現的漏洞
> - \(D\) 將所有檔案加密以防止惡意程式進行存取

<details>
<summary>查看答案</summary>

**\(C\) 定期執行弱點掃描並立即修復發現的漏洞**

弱點掃描可主動、快速地發現系統漏洞，搭配及時修補是最有效的防禦方式。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 頻率太低，無法快速發現問題 |
| B | ❌ 被動等待，效率低且不可靠 |
| C | ✅ 主動掃描 + 即時修補，最有效 |
| D | ❌ 加密防止資料外洩，無法發現弱點 |

> 💡 弱點掃描應定期執行（如每月或每季），並優先修補高風險漏洞（CVSS 高分或 KEV 清單中的漏洞）。

</details>

---

> **Q：** 依據「資通安全責任等級分級辦法」之資通系統防護基準規範，以下對於「事件日誌與可歸責性」的描述何者正確？
> - \(A\) 資通系統應使用格林威治標準時間（GMT）作為系統的時戳標準
> - \(B\) 只要有需要，都可以任意存取日誌紀錄
> - \(C\) 從日誌完整性防護必須分為事前預防、事中監視及事後驗證等三種面向，可驗證日誌內容是否曾經遭到異動
> - \(D\) 將日誌備份至原日誌系統不同之實體系統，以驗證資料機密性

<details>
<summary>查看答案</summary>

**\(C\) 從日誌完整性防護必須分為事前預防、事中監視及事後驗證等三種面向，可驗證日誌內容是否曾經遭到異動**

日誌完整性保護需從三個面向著手，確保日誌內容可被信任。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 應使用統一時間來源（如 NTP），不限定 GMT |
| B | ❌ 日誌應有存取控制，不可任意存取 |
| C | ✅ 事前預防、事中監視、事後驗證是正確的完整性保護框架 |
| D | ❌ 異地備份是保護「可用性」，非「機密性」 |

| 保護面向 | 目的 | 措施 |
|:---------|:-----|:-----|
| 事前預防 | 防止竄改 | 存取控制、權限管理 |
| 事中監視 | 即時偵測 | SIEM、異常告警 |
| 事後驗證 | 確認完整 | 雜湊比對、簽章驗證 |

</details>

---
> **Q：** 日誌管理要求應定期執行日誌備份的任務，關於日誌管理的敘述下列何項有誤？
> - \(A\) 定期備份日誌至與原系統外之其他實體系統，以避免因實體主機損毀而造成原始資料與備份資料一併丟失
> - \(B\) 常見的日誌備份方式有建置日誌伺服器、NAS 及雲端空間等
> - \(C\) 可以利用磁碟與磁帶等儲存媒體存放備份資料
> - \(D\) 為避免備份相關弊端產生，驗證人員於檢視機關日誌紀錄時，不可以訪談相關權責人員

<details>
<summary>查看答案</summary>

**\(D\) 有誤**

驗證人員在檢視日誌時，**應該訪談相關權責人員**，以了解實際操作情況與流程，這是正常的稽核程序。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ 異地備份避免單點故障 |
| B | ✅ 日誌伺服器、NAS、雲端都是常見備份方式 |
| C | ✅ 磁碟與磁帶都是有效的備份媒體 |
| D | ❌ 訪談是稽核的正常程序，可協助驗證日誌管理有效性 |

> 💡 稽核三要素：**查閱文件、訪談人員、實地查核**，訪談是不可或缺的環節。

</details>

---

> **Q：** 某網路管理員收到要求，需要開放在 DMZ 區的伺服器 A，讓其可以透過 RFC 5424 的協定寫入相關的日誌記錄到 DMZ 區以外的區域中的伺服器 B，請問以下列何項設定較為合適？
> - \(A\) 允許所有伺服器到伺服器 B 的連線
> - \(B\) 允許所有來自伺服器 A 到伺服器 B 的連線
> - \(C\) 允許伺服器 A 至伺服器 B 中 TCP Port 514 的連線
> - \(D\) 允許伺服器 A 至伺服器 B 中 UDP Port 514 的連線

<details>
<summary>查看答案</summary>

**\(C\) 允許伺服器 A 至伺服器 B 中 TCP Port 514 的連線**

RFC 5424 是 Syslog 協定標準，建議使用 **TCP** 進行可靠傳輸。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 過於寬鬆，違反最小權限原則 |
| B | ❌ 仍過於寬鬆，應限定特定 Port |
| C | ✅ 符合 RFC 5424（TCP）與最小權限原則 |
| D | ❌ UDP 514 是傳統 Syslog（RFC 3164） |

| Syslog 版本 | 傳輸協定 | Port |
|:------------|:---------|:----:|
| RFC 3164（傳統） | UDP | 514 |
| RFC 5424（新版） | TCP | 514 |
| RFC 5425（加密） | TLS | 6514 |

> 💡 防火牆規則應遵循**最小權限原則**：僅開放必要的來源、目的、Port。

</details>

---

> **Q：** 使用雲端資料庫與應用程式十分方便，但若設定稍有不慎將導致資料外洩或是服務遭到攻擊，下列何項是因設定不慎而導致問題，同時也列為 OWASP TOP 10 2021 之一的漏洞？
> - \(A\) Cryptographic Failures
> - \(B\) Security Misconfiguration
> - \(C\) Vulnerable and Outdated Components
> - \(D\) Software and Data Integrity Failures

<details>
<summary>查看答案</summary>

**\(B\) Security Misconfiguration**

「安全設定錯誤」指的是系統因設定不當而導致的安全漏洞，如使用預設帳密、暴露管理介面、不必要的服務等。

| 選項 | 中文 | 說明 |
|:----:|:-----|:-----|
| A | 密碼學失誤 | 敏感資料未加密或使用過時演算法 |
| B | 安全設定錯誤 | ✅ 設定不當導致的漏洞 |
| C | 易受攻擊和過時的元件 | 使用有漏洞的第三方元件 |
| D | 軟體與資料完整性失敗 | 未驗證更新或外部模組完整性 |

> 💡 常見設定錯誤：預設帳密未更改、雲端儲存桶公開存取、錯誤的權限設定、不必要的服務開啟。

</details>

---

> **Q：** 美國「網路安全暨基礎設施安全局」（CISA）規範了用以識別及分類資通安全威脅情資（Cyber Threat Intelligence, CTI），並指定可以閱讀或共享 CTI 接收者的管理指導準則《Traffic Light Protocol 2.0 User Guide》，其中規範 CTI 敏感程度的 TLP（Traffic Light Protocol）標籤共有 4 種。請問是下列何項？
> 1. RED
> 2. GREEN
> 3. BLACK
> 4. BLUE
> 5. WHITE
> 6. CLEAR
> 7. AMBER
>
> - \(A\) 1、2、3、4
> - \(B\) 2、3、5、6
> - \(C\) 1、2、6、7
> - \(D\) 1、4、5、7

<details>
<summary>查看答案</summary>

**\(C\) 1、2、6、7（RED、GREEN、CLEAR、AMBER）**

TLP 2.0 共有 4 種標籤：

| 標籤 | 分享範圍 |
|:-----|:---------|
| TLP:RED | 僅限特定人員 |
| TLP:AMBER | 限組織內部及必要夥伴 |
| TLP:GREEN | 可分享給同業社群 |
| TLP:CLEAR | 可公開分享 |

> ⚠️ TLP 2.0 將 **WHITE 改為 CLEAR**，沒有 BLACK 和 BLUE。

</details>

---

> **Q：** 某作業系統在同一天釋出四個安全更新。若資安團隊必須依照資安風險優先級安排安裝順序，最合理的順序是下列何項？
> 1. 修補 Kernel 本地提權漏洞（已公開 exploit 程式，CVSS 9.0，高風險）
> 2. 修補 OpenSSL 資料外洩漏洞（尚未出現 exploit，但影響機敏資料，CVSS 7.5，中高風險）
> 3. 修補 GUI 顯示錯誤（功能異常）
> 4. 修補低風險應用程式錯誤（僅影響單一非關鍵應用，CVSS 3.0，低風險）
>
> - \(A\) 3 → 2 → 1 → 4
> - \(B\) 1 → 2 → 4 → 3
> - \(C\) 2 → 1 → 3 → 4
> - \(D\) 2 → 1 → 4 → 3

<details>
<summary>查看答案</summary>

**\(B\) 1 → 2 → 4 → 3**

漏洞修補應優先處理「已有 Exploit 的高風險漏洞」，功能異常非安全問題排最後。

| 順序 | 項目 | 原因 |
|:----:|:-----|:-----|
| 1️⃣ | Kernel 提權漏洞 | CVSS 9.0 + 已有 Exploit，風險最高 |
| 2️⃣ | OpenSSL 外洩漏洞 | CVSS 7.5，影響機敏資料 |
| 3️⃣ | 低風險應用程式錯誤 | CVSS 3.0，仍是安全漏洞 |
| 4️⃣ | GUI 顯示錯誤 | 功能異常，非安全性問題 |

| 判斷因素 | 優先級 |
|:---------|:------:|
| 已有 Exploit | 最高 |
| CVSS 分數高 | 高 |
| 影響機敏資料 | 高 |
| 功能異常（非安全） | 最低 |

</details>

---

> **Q：** OWASP 所列出的 10 大弱點列表中，注入（Injection）一向是被關注的重點。下列何項攻擊方式較「不」屬於此項範疇？
> - \(A\) SQL 注入（SQL Injection）
> - \(B\) 命令注入（Command Injection）
> - \(C\) 跨站攻擊（Cross-Site Scripting）
> - \(D\) 跨站偽造（Cross-Site Request Forgery）

<details>
<summary>查看答案</summary>

**\(D\) 跨站偽造（Cross-Site Request Forgery）**

CSRF 是「偽造請求」，利用使用者已登入的身分發送惡意請求，不是將程式碼注入系統。

| 選項 | 類型 | 屬於 Injection |
|:----:|:-----|:--------------:|
| A | SQL Injection | ✅ |
| B | Command Injection | ✅ |
| C | XSS（注入惡意腳本） | ✅ |
| D | CSRF（偽造請求） | ❌ |

| 攻擊 | 本質 |
|:-----|:-----|
| Injection | 將惡意程式碼「注入」系統執行 |
| CSRF | 利用已驗證身分「偽造」請求 |

> 💡 OWASP 2021 將 XSS 歸類在 A03 Injection，因為 XSS 本質上是將惡意腳本注入網頁。

</details>

---

> **Q：** 攻擊者透過修改查詢參數「account」為任意帳號即可存取資訊，關於此應用程式缺陷的敘述，下列何者正確？
> ```
> https://vulnerable.site/app/profile?account=victim
> ```
> - \(A\) 存取控制失效（Broken Access Control）
> - \(B\) 密碼機制失效（Cryptographic Failures）
> - \(C\) 注入攻擊（Injection）
> - \(D\) 安全日誌與監控失效（Security Logging and Monitoring Failures）

<details>
<summary>查看答案</summary>

**\(A\) 存取控制失效（Broken Access Control）**

這是典型的 IDOR（Insecure Direct Object Reference，不安全的直接物件參考）漏洞，屬於存取控制失效。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ 未驗證使用者是否有權存取該帳號 |
| B | ❌ 與加密機制無關 |
| C | ❌ 未注入惡意程式碼 |
| D | ❌ 與日誌監控無關 |

**IDOR（不安全的直接物件參考）：**
- 應用程式直接使用使用者輸入（如 ID、帳號）存取資源
- 未驗證使用者是否有權限存取該資源
- 攻擊者可修改參數存取他人資料

> 💡 防禦方式：每次存取資源前，都要驗證使用者是否有權限存取該資源。

</details>

---

> **Q：** 關於應用系統開發過程納入資訊安全要求的描述，下列何項正確？
> - \(A\) 各個程式設計皆有一套執行方式，較難書面記錄以套用於資訊系統撰寫流程
> - \(B\) 應用系統安全測試需於開發完成之後再進行，以免影響程式開發時間流程
> - \(C\) 應用系統委外第三方廠商開發，內部建立之開發安全工程原則不適用要求委外開發的活動
> - \(D\) 曾經發生常見導致資訊安全脆弱性之程式開發實務作法及缺陷，可納入文件做為開發遵守依據

<details>
<summary>查看答案</summary>

**\(D\) 曾經發生常見導致資訊安全脆弱性之程式開發實務作法及缺陷，可納入文件做為開發遵守依據**

將過去的漏洞經驗納入開發指引，是持續改善安全開發的良好實踐。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 安全開發流程可以書面化、標準化 |
| B | ❌ 違反「測試左移」原則，安全應從開發初期就納入 |
| C | ❌ 委外開發也應遵守相同的安全要求 |
| D | ✅ 經驗教訓納入文件是持續改善的實踐 |

| SSDLC 原則 | 說明 |
|:-----------|:-----|
| 測試左移 | 安全測試提早到開發初期 |
| 經驗回饋 | 將漏洞經驗納入開發指引 |
| 委外管理 | 委外開發適用相同安全要求 |

</details>

---

> **Q：** 下列何項「不」是常見的網站設計安全漏洞？
> - \(A\) 脆弱的身分識別控制，造成權限控制失效（Broken Access Control）
> - \(B\) 缺乏有效的漏洞修補管理程序和安全設定（Security Configuration）
> - \(C\) 雲端服務興起，缺乏資訊基礎設施（Information Infrastructure）並造成資安記錄及監控分散（Security Logging and Monitoring Spread）
> - \(D\) 有效的商業電子郵件詐騙（BEC），並造成伺服端請求偽造（Server-Side Request Forgery, SSRF）

<details>
<summary>查看答案</summary>

**\(D\) 有效的商業電子郵件詐騙（BEC），並造成伺服端請求偽造（Server-Side Request Forgery, SSRF）**

BEC 是社交工程攻擊，與 SSRF 無因果關係，且 BEC 不是「網站設計」漏洞。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ OWASP A01 Broken Access Control |
| B | ✅ OWASP A02 Security Misconfiguration |
| C | ⚠️ 描述奇怪但涉及 A09 Logging & Monitoring |
| D | ❌ BEC 是社交工程，非網站設計漏洞 |

| 攻擊類型 | 分類 |
|:---------|:-----|
| SSRF | 網站設計漏洞（OWASP A01） |
| BEC | 社交工程攻擊（非網站漏洞） |

> 💡 **BEC（商業電子郵件詐騙）**：透過偽造或入侵高層郵件，誘騙員工匯款或洩漏機密，屬於社交工程攻擊。

</details>

---

> **Q：** 請問下列日誌記錄相關的系統或標準，何項較「不」適合用於 Linux 環境？
> - \(A\) Windows Event Viewer
> - \(B\) RFC 5424
> - \(C\) Syslog-NG
> - \(D\) rsyslogd

<details>
<summary>查看答案</summary>

**\(A\) Windows Event Viewer**

Windows Event Viewer 是 Windows 專用的事件檢視器，不適用於 Linux 環境。

| 選項 | 說明 | 適用環境 |
|:----:|:-----|:--------:|
| A | Windows 事件檢視器 | ❌ Windows 專用 |
| B | Syslog 協定標準 | ✅ 跨平台 |
| C | Syslog-NG 日誌服務 | ✅ Linux |
| D | rsyslog 日誌服務 | ✅ Linux |

| Linux 常見日誌工具 | 說明 |
|:-------------------|:-----|
| rsyslogd | 傳統 Syslog 的增強版，預設於多數 Linux |
| Syslog-NG | 進階日誌管理，支援複雜過濾與轉發 |
| journald | systemd 的日誌服務 |

</details>

---

> **Q：** 在設計應用程式的日誌管理時，下列哪一種做法最能幫助快速偵測並回應潛在的安全事件？
> - \(A\) 只記錄應用程式的主要功能操作，可忽略登入及權限變更等活動
> - \(B\) 將日誌以純文字格式儲存在本地伺服器上，不需備份
> - \(C\) 設定日誌警報機制，在偵測到異常行為時即時通知管理員
> - \(D\) 定期刪除日誌，以避免佔用過多儲存空間

<details>
<summary>查看答案</summary>

**\(C\) 設定日誌警報機制，在偵測到異常行為時即時通知管理員**

即時告警機制可在異常發生時第一時間通知管理員，達到「快速偵測並回應」的目的。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 登入與權限變更是重要安全事件，必須記錄 |
| B | ❌ 日誌應集中管理、加密傳輸並備份 |
| C | ✅ 即時告警可快速偵測與回應 |
| D | ❌ 日誌應依法規保留（如 6 個月），非定期刪除 |

| 日誌管理原則 | 說明 |
|:-------------|:-----|
| 完整記錄 | 包含登入、權限變更、異常操作 |
| 集中管理 | 使用 SIEM 統一收容與分析 |
| 即時告警 | 偵測異常時即時通知 |
| 保留期限 | 依法規要求保留（如 6 個月） |

</details>

---

> **Q：** 在設計「日誌輪替」（Log Rotation）機制時，其主要目標為下列何項？
> - \(A\) 永久保存所有日誌，以確保不遺漏任何資訊
> - \(B\) 只記錄特定類型的日誌，例如錯誤日誌或訪問日誌，忽略其他日誌
> - \(C\) 根據時間或檔案大小限制日誌，並自動歸檔或刪除舊日誌
> - \(D\) 定期手動刪除所有日誌檔案，以釋放存儲空間

<details>
<summary>查看答案</summary>

**\(C\) 根據時間或檔案大小限制日誌，並自動歸檔或刪除舊日誌**

日誌輪替的目的是自動管理日誌檔案大小與數量，避免磁碟空間耗盡。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 永久保存會耗盡儲存空間 |
| B | ❌ 這是日誌過濾，非輪替 |
| C | ✅ 日誌輪替的核心功能 |
| D | ❌ 應自動執行，非手動刪除 |

| Log Rotation 機制 | 說明 |
|:------------------|:-----|
| 依時間 | 每日、每週、每月切割 |
| 依大小 | 達到指定大小時切割 |
| 保留數量 | 保留最近 N 份，自動刪除舊檔 |
| 壓縮歸檔 | 舊日誌壓縮節省空間 |

</details>

---

> **Q：** 關於確保日誌的完整性，下列敘述何項最為適切？
> - \(A\) 禁止所有人存取日誌，僅允許管理員修改日誌內容，以確保記錄正確
> - \(B\) 記錄日誌變更歷史，並使用數位簽章或雜湊技術來驗證日誌的完整性
> - \(C\) 透過壓縮技術對日誌進行壓縮，確保儲存時間最大化
> - \(D\) 只保留最近七天的日誌，其他日誌自動刪除

<details>
<summary>查看答案</summary>

**\(B\) 記錄日誌變更歷史，並使用數位簽章或雜湊技術來驗證日誌的完整性**

雜湊與數位簽章可驗證日誌是否被竄改，是確保完整性的標準做法。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 管理員也不應修改日誌，日誌應為唯讀 |
| B | ✅ 雜湊/數位簽章可驗證完整性 |
| C | ❌ 壓縮是節省空間，與完整性無關 |
| D | ❌ 保留期限與完整性無關，且 7 天不符法規要求 |

| 日誌完整性防護 | 措施 |
|:---------------|:-----|
| 事前預防 | 存取控制、唯讀設定 |
| 事中監視 | SIEM 告警、異常偵測 |
| 事後驗證 | 雜湊比對、數位簽章 |

</details>

---

> **Q：** 在日誌管理（Log Management）流程中，「日誌收集」（Log Collection）階段最主要的目的為下列何項？
> - \(A\) 即時分析日誌以偵測威脅
> - \(B\) 對日誌進行加密以確保傳輸安全
> - \(C\) 將分散在不同來源的日誌資料，系統性地彙整集中存放
> - \(D\) 刪除不重要的日誌以節省儲存空間

<details>
<summary>查看答案</summary>

**\(C\) 將分散在不同來源的日誌資料，系統性地彙整集中存放**

日誌收集階段的核心任務是將各系統、設備的日誌彙整到集中存放位置。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 即時分析屬於「日誌分析」階段 |
| B | ❌ 加密屬於「日誌傳輸」的安全措施 |
| C | ✅ 日誌收集的核心目的 |
| D | ❌ 刪除屬於「日誌輪替」階段 |

| 日誌管理流程 | 說明 |
|:-------------|:-----|
| 收集（Collection） | 彙整各來源日誌至集中存放 |
| 傳輸（Transport） | 安全傳輸至集中管理系統 |
| 儲存（Storage） | 保存並確保完整性 |
| 分析（Analysis） | 偵測威脅與異常行為 |
| 保留/輪替（Retention） | 依規定保留或歸檔刪除 |

</details>

---

## 2.4 新興科技安全

### 2.4.1 雲端安全概論

#### NIST 雲端運算五大特性

隨需自助、無遠弗屆、資源共享、伸縮自如、按量計價

#### 雲端部署模式

私有雲、公有雲、混合雲、社群雲

#### 服務模式與責任劃分

| 模式 | 說明 | 客戶責任 |
|------|------|----------|
| IaaS | 基礎架構即服務 | OS 以上全部 |
| PaaS | 平台即服務 | 應用程式與資料 |
| SaaS | 軟體即服務 | 僅資料與存取管理 |

#### 零信任架構（Zero Trust Architecture）

**核心原則**：永不信任，持續驗證（Never Trust, Always Verify）

**五大支柱（CISA / 金管會）：**

| 支柱 | 重點功能 | 關鍵措施 |
|:-----|:---------|:---------|
| 身分 | 身分認證、權限存取 | MFA、FIDO、RBAC/ABAC、動態授權 |
| 設備 | 設備合規、威脅防護 | 設備納管、健康檢查、EDR |
| 網路 | 網路區隔、流量加密 | 微分段、加密傳輸、NDR |
| 應用程式 | 存取授權、程式安全 | 最小授權、安全檢測、CI/CD |
| 資料 | 外洩防護、資料加密 | DLP、資料分類分級、加密儲存 |

**導入成熟度四階段：**

| 階段 | 等級 | 特性 | 說明 |
|:-----|:----:|:-----|:-----|
| 傳統 | Ⅰ | 靜態指標 | 盤點既有機制，不以導入新產品為必要 |
| 起始 | Ⅱ | 動態指標 | 建立 ABAC 機制，動態屬性納入授權條件 |
| 進階 | Ⅲ | 即時指標 | 整合 SIEM/SOC，即時偵測告警與回應 |
| 最佳化 | Ⅳ | 整合指標 | 自動化治理，快速調適資安政策 |

> 💡 金管會建議以**高風險、低衝擊**場域優先導入，如：遠距辦公、雲端存取、特權帳號管理、委外廠商維運。

---

### 2.4.2 行動裝置安全概論

#### 行動裝置管理 (MDM)

- 裝置註冊與控管
- 應用程式管理
- 資料保護
- 遠端抹除

#### 威脅類型

惡意程式、網路攻擊、資料外洩、實體安全

---

### 2.4.3 智慧製造及物聯網安全概論

### 物聯網三層架構

| 層級 | 說明 | 組成 |
|:-----|:-----|:-----|
| 感知層 | 收集外界資訊 | 感測器、RFID、攝影機 |
| 網路層 | 傳輸資料 | Wi-Fi、藍牙、ZigBee、LoRa |
| 應用層 | 處理與應用資料 | 智慧家庭、工業控制、醫療系統 |

> 💡 感知層資訊透過「**網路層**」傳輸至應用層，而非直接透過應用層連通。

#### 智慧製造安全考量

工控系統安全、產線監控、資料收集、供應鏈安全

#### OWASP IoT Top 10（2018）

| 排名 | 風險 | 說明 |
|:----:|:-----|:-----|
| I1 | 弱密碼/預設密碼 | 使用弱密碼、可猜測或硬編碼密碼 |
| I2 | 不安全的網路服務 | 暴露不必要的網路服務 |
| I3 | 不安全的生態系統介面 | API、雲端、行動介面缺乏安全控制 |
| I4 | 缺乏安全更新機制 | 無法安全地更新韌體 |
| I5 | 使用不安全或過時元件 | 使用有漏洞的第三方元件 |
| I6 | 隱私保護不足 | 個人資料未妥善保護 |
| I7 | 不安全的資料傳輸與儲存 | 傳輸或儲存時缺乏加密 |
| I8 | 缺乏設備管理 | 無法有效管理大量設備 |
| I9 | 不安全的預設設定 | 出廠設定不安全 |
| I10 | 缺乏實體強化 | 缺乏防拆、防竄改等實體保護 |

---

#### 範例考題

> **Q：** 企業使用雲端服務時，下列哪一個資安技術較「不」屬於企業維運人員優先需要關注的？
> - \(A\) 身分識別與存取管理
> - \(B\) 實體安全
> - \(C\) 網站應用程式防火牆（WAF）
> - \(D\) 資料隱私保護

<details>
<summary>查看答案</summary>

**\(B\) 實體安全**

在雲端服務中，**實體安全**是雲端服務供應商（CSP）的責任，企業客戶無需直接管理機房、電力、門禁等實體設施。

| 選項 | 責任歸屬 |
|:----:|:---------|
| A | ✅ 客戶責任（所有服務模式） |
| B | ❌ CSP 責任 |
| C | ✅ 客戶責任（IaaS/PaaS） |
| D | ✅ 客戶責任（所有服務模式） |

| 服務模式 | 客戶責任 | CSP 責任 |
|:---------|:---------|:---------|
| IaaS | OS 以上全部 | 實體設施、虛擬化層 |
| PaaS | 應用程式與資料 | OS 以下全部 |
| SaaS | 資料與存取管理 | 應用程式以下全部 |

> 💡 雲端責任共享模型：實體安全永遠是 CSP 的責任，客戶專注於資料與存取管理。

</details>

---

> **Q：** 下列何項「不」是物聯網設備常見的問題？
> - \(A\) 預設密碼或使用弱密碼
> - \(B\) 缺乏安全的更新機制
> - \(C\) 缺乏設備管理
> - \(D\) 加密機制失效

<details>
<summary>查看答案</summary>

**\(D\) 加密機制失效**

A、B、C 都是 OWASP IoT Top 10（2018）明確列出的項目，「加密機制失效」則是 OWASP Web Top 10 的項目，而非 IoT 特有的常見問題。

| 選項 | OWASP IoT Top 10 |
|:----:|:-----------------|
| A | ✅ I1 - 弱密碼/預設密碼 |
| B | ✅ I4 - 缺乏安全更新機制 |
| C | ✅ I8 - 缺乏設備管理 |
| D | ❌ 屬於 Web Top 10，非 IoT 特有 |

> 💡 IoT 設備常見問題多與資源受限、大量部署、難以更新有關。

</details>

---

> **Q：** 在零信任架構（Zero Trust Architecture, ZTA）實作參考原則中，下列何者描述與應用程式的存取授權最直接相關？
> - \(A\) 以作業屬性及風險區隔角色，並依角色風險等級定義授權條件（如身分及設備鑑別之等級），採最小授權原則定義授權範圍；並針對特權作業採獨立角色授權（不混用於非特權作業），減少特權帳號之濫用及風險
> - \(B\) 對網路連線紀錄具有即時偵測及回應機制（如 NDR），可因應業務需求、偵測到入侵指標（IOC）或遭受攻擊時，動態調整網路設定或即時告警，以維持網路服務，將對業務影響最小化
> - \(C\) 具網段隔離機制，採最小需求原則限制存取資源之網路連線，並得限制同網段主機間連線及資源存取，防止攻擊者利用遭入侵的主機作為跳板機進行橫向擴散
> - \(D\) 具有效盤點且可唯一識別（如 TPM 等）納管設備機制，並對其安全要求（如病毒碼、作業系統狀態等）之判斷及應處機制；對未納管設備具有即時偵測及風險控管機制

<details>
<summary>查看答案</summary>

**\(A\) 以作業屬性及風險區隔角色，並依角色風險等級定義授權條件，採最小授權原則定義授權範圍**

各選項對應的零信任支柱：

| 選項 | 對應支柱 | 說明 |
|:----:|:---------|:-----|
| A | ✅ 應用程式 | 存取授權、最小授權原則、特權管理 |
| B | 網路 | NDR、網路韌性 |
| C | 網路 | 網路區隔、防止橫向擴散 |
| D | 設備 | 設備納管、合規檢測 |

> 💡 應用程式支柱的核心是「存取授權」，強調 RBAC/ABAC、最小授權、特權帳號獨立管理。

</details>

---

> **Q：** 關於零信任（Zero Trust）的敘述，下列何者正確？
> - \(A\) 零信任是不用始終驗證
> - \(B\) 僅提供必要的權限
> - \(C\) 不需保持網路可見性
> - \(D\) 非所有流量都是不安全的前提下進行零信任設計

<details>
<summary>查看答案</summary>

**\(B\) 僅提供必要的權限**

零信任的核心原則是「永不信任，持續驗證」，並遵循最小權限原則。

| 選項 | 說明 |
|:----:|:-----|
| A | ❌ 零信任要求「持續驗證」，非不用驗證 |
| B | ✅ 最小權限原則是零信任核心概念 |
| C | ❌ 零信任需要保持可見性以監控異常行為 |
| D | ❌ 零信任假設「所有流量都不安全」 |

**零信任核心原則：**

| 原則 | 說明 |
|:-----|:-----|
| 永不信任 | 假設所有流量、使用者、設備都不可信 |
| 持續驗證 | 每次存取都要驗證身分與授權 |
| 最小權限 | 僅給予完成工作所需的最小權限 |
| 假設被入侵 | 設計時假設網路已被滲透，降低橫向移動風險 |

</details>

---

> **Q：** 物聯網感知層主要作用是全面感知外界資訊，包括物體識別、資訊收集等功能。請問對於物聯網感知層的描述何者不正確？
> - \(A\) 物聯網的感知層主要由感測裝置和讀取與識別裝置組成
> - \(B\) 物聯網安全需求應包括判斷與阻斷惡意節點與其行為，並保證阻斷惡意節點後網路的連通性
> - \(C\) 感知層的資訊通常透過應用層與外界連通，才能作為應用層正確控制決策的主要依據
> - \(D\) 無線感測器是物聯網感知層重要的組成部分，由於無線感測器採用無線通訊，攻擊者可以輕易實施監聽訊號，並儲存監聽資料

<details>
<summary>查看答案</summary>

**\(C\) 感知層的資訊通常透過應用層與外界連通，才能作為應用層正確控制決策的主要依據**

感知層的資訊是透過「**網路層**」傳輸，而非應用層。

| 選項 | 說明 |
|:----:|:-----|
| A | ✅ 感知層由感測器與識別裝置組成 |
| B | ✅ 阻斷惡意節點是 IoT 安全需求 |
| C | ❌ 應為「網路層」，非應用層 |
| D | ✅ 無線通訊容易被監聽是 IoT 的安全風險 |

| 物聯網架構 | 功能 |
|:-----------|:-----|
| 感知層 | 收集資訊 |
| 網路層 | 傳輸資料 |
| 應用層 | 處理應用 |

</details>

---

> 題目來源皆為 [iPAS資訊安全工程師學習資源](https://www.ipas.org.tw/certification/ISE/learning-resources) 114-1 和 114-2 管理和技術考題