# 序章：CCSP 應考心態（給有 CISSP 背景的考生）

CCSP 看似是 CISSP 的延伸，但**心態擺錯就會踩坑**。下面這幾個轉換是答題時必須先到位的。

#### 一、第一個轉換：從「我擁有」到「我能要求」

CISSP 假設你擁有組織的全部資產 — 機房、伺服器、網路、應用、資料。你有 root、進得去機房、看得到 log、下得了指令。在這個前提下，「保護資產」這個語言才成立。

CCSP 假設的世界是「**你不擁有底層的東西**」。雲端的伺服器、機房、網路是 CSP 的，不是你的。你連「我能進機房嗎」這種事都做不到。

> **所以「我的資產」這個詞在雲端基本上崩潰了** — 你唯一真正擁有、唯一最終要負責的，**只有資料和對資料的合規責任**。

衍生出來的關鍵心態：你**不再「直接控制」，你「契約性地要求」**。
- CISSP：下指令給 IT
- CCSP：看 SLA、看 SOC 2 報告、看 ISO 27017 認證、看 DPA 條款

而且這條「要求」鏈不是單線，是**跨組織的責任結構**：

> **CSC ↔ CSP ↔ CSN ↔ Regulator**

這條線在哪、誰對誰負什麼責、合約怎麼寫、爭議怎麼解 — 是 CCSP 反覆考的東西。所以：

> **共享責任模型不是一張漂亮的圖，它是 CCSP 的核心世界觀。**

這也就是為什麼 CCSP 這麼重 D5 服務層級管理、D6 法律合規、D1 評估 CSP — 因為這些就是你唯一的「控制手段」。

#### 二、第二個轉換：從「保護一切」到「只保護資料」

第一個轉換解開了「我不擁有底層」 — 但即使是「我能控制的那一半」，CCSP 還會逼你做第二次轉換。

CISSP 假設你會花心力**保護整台伺服器** — OS、middleware、設定、應用、資料，每一塊都要備份、都要 patch、都是業務資產。

CCSP 假設的世界裡，這些東西只有**一種是真資產**：

> **雲端世界，你的資產只有資料。**
> **OS、Patch、套件、設定檔、應用程式碼 — 這些全部可以從 IaC 跟 Git 重建。**

所以工作負載要設計成「可拋棄」：

- VM 出事 → 重建一台新的，不要花時間救它（**Cattle 不是 Pets**）
- 配置漂了 → 不追究誰偷改了，直接從 IaC 部署回去
- 攻擊發生 → 砍掉受影響的 VM、IaC 重新部署一台乾淨的

> **「Cattle vs Pets」典故補充**：這是雲端業界經典隱喻、SRE 跟 DevOps 圈的標準術語。
> - **Pets（寵物）**：給他取名（如 web01、db-prod）、生病了帶看醫生（patch 修復、客製化）、每隻獨特、死了會難過
> - **Cattle（牛群）**：編號管理（如 vm-i-7d3a4f8b）、生病直接淘汰、每隻可替換、不必記得是哪一隻
>
> 由微軟前工程師 Bill Baker 提出、CERN 工程師 Gavin McCance 在 2012 OpenStack Summit 演講推廣後爆紅。**雲端 VM 應該當「牛」養、不是當「寵物」養** — 這是雲原生哲學最白話的版本。

| CISSP 視角 | CCSP 視角 |
|------------|-----------|
| 整台 VM 是我的資產 | 只有資料是我的資產 |
| 修補維護（Pet） | 拋棄重建（Cattle） |
| OS、middleware 很重要 | OS、middleware 是 IaC 的副產物 |
| 出事先找 root cause、修復 | 出事先重建、之後再分析 |

**Lambda、Fargate、Cloud Run 是這個哲學的極致** — 你連 OS 跟 Runtime 版本都不 care、只關心程式碼邏輯跟資料連到哪。雲端越「無伺服器」，這個哲學越徹底。

**考點反射**：

- 題目問「最佳的雲端 patch 管理策略」 → 答案常常是**重建 VM**（Immutable Infrastructure），不是 patch 管理流程
- 題目問「如何避免組態漂移（Configuration Drift）」 → 答案是 **IaC 加上不可變基礎設施**
- 題目問「DR 怎麼快速復原」 → 答案是 **IaC 重建**，不是傳統 backup/restore
- 選項出現「主動修補、加固既有 VM」vs「砍掉重建」二選一 → CCSP 多半選後者

**沒做這個轉換的 CISSP 老手最容易選錯**：他覺得「修補比重建專業」，但 CCSP 認為**重建才是雲端的標準作業**。

#### 三、CCSP 在考什麼（看到題目要反射什麼）

CCSP 不是雲端工程師考試（不考 AWS console、不考 K8s 指令），也不是純理論考試。它考的是：

> **一個要決定「公司要不要採用雲端、怎麼採用、出事怎麼辦」的人，腦袋裡該裝什麼。**

可以把自己想成剛被任命的雲端安全長 (Cloud CISO)，考題其實全部都繞著這四個情境轉，每個情境都要練到看到就反射：

| 情境 | 看到時要立刻反射 |
|------|------------------|
| 業務要把 CRM 搬到 SaaS | IaaS、PaaS、SaaS 哪一層、責任在誰、CSP 該提供什麼、CSC 該做什麼 |
| 工程要在 IaaS 上跑 K8s | 要靠合約、SLA、認證還是技術手段達成這個控制 |
| 法務問 GDPR 風險 | 資料分類、生命週期階段、適用法規、跨境怎麼處理 |
| 出事了要做 e-Discovery | 我有什麼證據、CSP 配合到哪、跨境管轄、合約是否預先準備 |

它不是抽象的，它是**很具體的決策題**，只是決策層級不在工程實作，而在治理、契約、評估、責任歸屬。

> **答題前的視角檢查（5 秒鐘反射）**：
>
> CCSP 題目 **90% 預設你是 CSC**（客戶端 CISO、合規長、稽核員），題目用「your organization」「the customer」「a bank/healthcare provider」暗示。少數題目會明說「as a CSP」或「the auditor」才切換視角。
>
> **同一個議題、3 個角色答案完全不同**：
>
> | 議題 | CSC 答案 | CSP 答案 | CSN:Auditor 答案 |
> |------|---------|---------|----------------|
> | 資料加密金鑰 | CMK / BYOK 自己掌控 | 提供 KMS 服務、看不到客戶明文 | 驗證金鑰輪換、生命週期 |
> | 資料外洩處理 | 通報主管機關、通知用戶 | 通知所有受影響客戶、修補 | 獨立評估事件嚴重性、出報告 |
> | 最重要的安全控制 | **合約 + SLA** + 自己這端 IAM | 隔離 + 透明度 + 合規證明 | 獨立稽核能力 |
>
> **答題反射**：每題前 5 秒先確認「**我是哪個角色**」、再看選項 — 比埋頭看選項少踩 90% 坑。
>
> **CISSP 老手最常踩的視角坑**：題目「EC2 上發現未修補 CVE、最佳處理方式？」 — CISSP 反射「立刻 patch」。但要先問**這個 CVE 在哪一層**：OS 層 → CSC 自己 patch；Hypervisor 層 → 開 ticket 給 CSP；託管服務（如 RDS）→ CSP 自動處理、你不能干預。**搞不清視角 = 連責任歸屬都答錯**。

#### 四、CISSP 底子怎麼用對地方

共享責任模型的「**CSP 那一半**」其實就是 CISSP 全書內容，不用重學。CCSP 真正要新學的是：

> **CSC 那一半 + 兩半交界處（合約、責任、跨境、評估手段）。**

但 CISSP 的反射在 CCSP 也會帶來兩個常踩的坑：

**坑一：看到「實作最佳實踐」就選下去**

題目問「保護雲端資料庫的最佳方法」，CISSP 腦袋會想「強化 OS、修補、加密、防火牆」全做。但 CCSP 答案常常是：
> 先讀 SLA、確認 CSP 在這層提供什麼控制、釐清是 CSP 還是 CSC 責任。

因為你都還不知道你能不能控制 OS 層，談強化幹嘛？

**坑二：看到「直接控制、實體存取、親自稽核」就覺得對**

傳統安全這些都是好詞。雲端裡這些常常是**錯的**或**不可行的** — CSP 不會讓你進機房、不會讓你掃他的網路、不會讓你看其他租戶的東西。正確答案常常是退一步的：
> 靠第三方認證、SOC 報告、合約條款、SLA 監控。

**簡單啟發**：當四個技術選項都看起來合理時，挑那個「**承認自己沒有底層控制權**」的答案。

把心態切到這一層，CISSP 的功底就會變成助力而不是干擾。

> **常見疑問：「我沒用過 AWS、Azure、GCP，能考 CCSP 嗎？」**
>
> **能**。CCSP 是 **vendor-neutral**（廠商中立）認證、考概念不考 console 操作。考綱對齊的是 ISO/IEC 17788、22123、27017、27018 這套國際標準，不是任何特定廠商的服務。
>
> 例如題目會問「**Tokenization 的主要安全目標是什麼**」（考概念），不會問「**AWS Macie 哪個選單可以開啟**」（考操作）。
>
> 但有兩個地方沒實作經驗會吃虧：
> - **對「規模」沒感覺**：地端管 50 個帳號 vs 雲端管 5000 個 IAM 角色，是質變不是量變。沒踩過這個牆會看不懂「為什麼雲端必須用 IaC 跟 Policy-as-Code」
> - **對「速度」沒感覺**：地端改一條防火牆要 1-3 天（變更管控）vs 雲端 5 秒改一條 Security Group。這個速度差會徹底改變安全模型（從靜態防禦變成持續監控、Drift Detection）
>
> **補救方式**：不用真去開 AWS 帳號玩，**多看雲端事故報告**就好（Capital One、SolarWinds、Uber 等案例），從別人的血淚中建立「為什麼雲端安全跟地端不一樣」的直覺。
>
> 一句話總結：**CCSP 不要求你會「操作雲端」、要求你會「思考雲端」**。地端老手考 CCSP 真正的障礙不是沒用過 AWS，是**心態還停在地端**。

#### 五、雲端權威三巨頭：NIST、ISO、CSA

CCSP 課本沒有原創內容、是這三家的整合：

| 組織 | 角色 | 代表文件 |
|------|------|---------|
| **NIST**（美國國家標準局） | 定義「**雲端是什麼**」 | SP 500-292、SP 800-145、SP 800-53、SP 800-61 |
| **ISO/IEC**（國際標準組織） | 規範「**怎麼合約稽核**」 | 22123、27017、27018、27701、27001 |
| **CSA**（雲端安全聯盟） | 提供「**業界實務工具**」 | CCM、CAIQ、CCSK、STAR、Top Threats |

**三者互補、缺一不可**：

- **NIST**（免費公開、技術導向）：解決「**沒共同詞彙**」的問題、定義 5 特性 + 3 服務模型 + 4 部署模型、美國聯邦機構必用（FedRAMP 整套建立在 NIST 上）
- **ISO**（付費標準、稽核導向）：解決「**跨國合約沒依據**」的問題、跨國企業合約必引、ISO 27001 主導稽核員必用
- **CSA**（業界自律、實務導向）：解決「**標準太抽象、實務怎麼做**」的問題、雲端業者展示安全（STAR）跟買家評估 CSP（CAIQ）必用

讀本筆記時看到引用這三家是常態 — **不是抄來抄去、是業界本來就要綜合三家視角**。CCSP 課本依據是混合三家：有時偏 NIST（定義）、有時偏 ISO（合約）、有時偏 CSA（控制）。**考試題目也會混用、看清楚題目來源就答對應視角**。

> **CCSP vs CCSK 的差異真相**：CCSP 是 **ISC2 + CSA 合作**出版（2015 起）、偏 **ISO 視角**（合約、稽核、治理）+ NIST 框架。CCSK 是 **CSA 自己**的認證、**CSA 自家內容**（CCM、Guidance）+ NIST + ENISA 為主。考完 CCSP 後考 CCSK 會非常順 — CSA 內容已經讀過了。

---

# 全書地圖：六大 Domain 怎麼串起來

CISSP 八章讀完容易見樹不見林，CCSP 六章也一樣。先看清楚「**這六章在解釋同一件事的哪一面**」，再進章節讀，會輕鬆很多。

#### 一張圖：六章的關係


#### 一個核心：資料（D2 為什麼權重最高 20%）

呼應前面的心態 — **雲端裡你唯一真正擁有的是資料**。所以 D2 不是「其中一章」，而是**所有其他五章圍繞的中心**：

| 章 | 一句話本質 | 跟 D2 的關係 |
|----|-----------|--------------|
| **D1** | 認識這個雲端世界（是什麼、誰是誰、怎麼分） | 給你雲端世界觀，但最後要保護的是 D2 |
| **D2** | 保護你唯一真正擁有的東西：資料 | — |
| **D3** | 檢視 CSP 給你的基礎建設安不安全 | 為了讓 D2 的資料躺得安全 |
| **D4** | 確保你跑在雲上的應用安不安全 | 為了讓 D2 的資料被處理時不出事 |
| **D5** | 日常怎麼跑、出事怎麼辦、鑑識怎麼做 | 為了 D2 的資料持續被正確管理 |
| **D6** | 跟外部世界（法律、客戶、稽核）怎麼打交道 | 為了 D2 的資料合規且可追責 |

讀任何一章卡住時，就問自己：「**這章跟保護資料有什麼關係？**」答得出來就抓到重點了。

#### 推薦讀法

CCSP 章節順序 **D1→D6 是合理的學習順序，但不一定是最佳記憶順序**。建議：

1. **第一輪**：依序 D1→D6 讀完，**先建立完整地圖**（這份筆記就是這個用途）
2. **第二輪**：以 **D2 為中心放射讀** — 從資料出發，每個保護需求往外連到 D3、D4、D5、D6 哪裡能配上
3. **第三輪**：拿模擬題練手感
4. **考前**：只看序章 + 全書地圖 — 重整大腦邏輯

---

# Domain 1：雲端概念、架構與設計 (Cloud Concepts, Architecture and Design)

> **考試權重**：17%
> **核心重點**：雲端運算的定義與特性、參考架構、安全概念、設計原則、CSP 評估、以及 AI/ML 在雲端安全的應用。

---

## 1.1 了解雲端運算概念

### 雲端運算定義

在開始探討雲端安全之前，我們必須先建立對「雲端運算」的共同理解。NIST（美國國家標準與技術研究院）提供了業界最廣泛採用的定義：

> 「雲端運算是一種模型，用於實現對可配置運算資源（例如網路、伺服器、儲存、應用程式和服務）共享池的無處不在、便捷、按需網路存取，這些資源可以快速配置和釋放，管理工作量或服務提供者互動最少。」

簡單來說，雲端運算就是透過網際網路，以「即服務」的方式提供可擴展和彈性的 IT 功能。這個定義包含三個核心要素：
- **共享資源池**：多個用戶共享底層基礎設施
- **按需存取**：需要時立即取得，不需要時立即釋放
- **最少管理**：自動化程度高，減少人工介入

---

### 雲端運算角色與職責

> **角色結構說明**：以下五個角色依 CCSP 考綱並列。理解上分兩層 — **CSC、CSP、CSN 是 ISO/IEC 22123 的三大主角色**；**CSB 嚴格來說是 CSN 的子集**（NIST 額外細分出來的具體類型），**監管機構則是外部規管者**。考綱把它們攤平列五個是因為考點分散，但層級關係要分清楚。
>
> **本節視角**：本節依 **CCSP 考綱的 5 角色架構**（混合 NIST + ISO），與後面「1.2 雲端運算活動」依 **ISO/IEC 22123-3:2023 的 3 子角色架構**不同 — 業界本來就有兩套標準、考試混用、學習時要分清楚是哪個視角。
>
> **NIST vs ISO 架構差異**（避免讀到後面霧颯颯）：
>
> | 架構 | 角色清單 |
> |------|---------|
> | **NIST SP 500-292** (2011) | 5 個並列：Consumer、Provider、**Carrier**（電信）、Auditor、Broker |
> | **ISO/IEC 22123-3** (2023) | 3 主角色：CSC、CSP、CSN（Auditor、Broker、**網路提供者**全收進 CSN 或 CSP 子角色） |
> | **CCSP 考綱**（本節依此） | 5 個並列：CSC、CSP、CSN、CSB、**Regulator**（監管機構） |
>
> **關鍵差異**：
> - **Cloud Carrier**（電信、ISP 如中華電信）：NIST 拎成獨立角色、ISO 收進 **CSP:網路提供者** 子角色、CCSP 考綱**省略**（合併到 CSP 處理）
> - **Cloud Auditor、Cloud Broker**：NIST 是獨立角色、ISO 跟 CCSP 都收進 **CSN** 下面當子角色
> - **Regulator**（監管機構如金管會）：**只有 CCSP 考綱有**、NIST 跟 ISO 都沒列
>
> 讀題目時看清楚是哪個架構的視角、就答哪個。三個架構都對、只是切割方式不同。

#### 1. 雲端服務客戶 (CSC, Cloud Service Customer)
- **定義**：與 CSP 建立業務關係以使用雲端服務的一方。
- **職責**：
- **SLA 監控**：確保服務水準符合需求。
- **安全性**：負責「雲中的安全」(如資料分類、身分管理、加密)。
- **合規**：確保使用雲端服務的方式符合自身行業法規。

#### 2. 雲端服務提供者 (CSP, Cloud Service Provider)
- **定義**：向客戶提供雲端服務的一方。
- **職責**：
- **基礎設施**：維護資料中心、實體安全、網路與伺服器。
- **服務交付**：確保服務的可用性、彈性與效能。
- **安全性**：負責「雲的安全」(實體、虛擬化層)。

#### 3. 雲端服務合作夥伴 (CSN, Cloud Service Partner)
- **定義**：依 ISO/IEC 22123-1（雲端運算詞彙標準），CSN 是參與支援或輔助 CSP、CSC 或兩者活動的一方。
- **NIST 對應**：依 NIST SP 500-292（雲端參考架構），NIST 使用「雲端服務經紀人」(Cloud Broker) 和「雲端稽核員」(Cloud Auditor) 兩個術語，這兩者在 ISO/IEC 22123 系列都歸入此 CSN 角色。

> 註：課本仍引用舊版 ISO/IEC 17789（已被 22123 系列取代）。CCSK v5 與最新考綱皆採用 22123 系列：22123-1（詞彙）、22123-2（概念）、22123-3（參考架構）。

#### 4. 雲端服務代理 (CSB, Cloud Service Broker)

> **為什麼單獨講**：CSB 是 CSN 的子集（見前面「角色結構說明」），但考試偏好考它的三大服務模式（仲介、聚合、套利），所以這份筆記把它從 CSN 分出來細講。答題時記得它仍屬於 CSN 範疇。

- **定義**：管理雲端服務的使用、效能和交付，並協商 CSP 與 CSC 之間關係的實體。
- **核心價值**：簡化雲端服務的整合與客製化。
- **三大服務模式 (NIST 定義)**：
1. **服務仲介**：在原服務上**增值** (如增加身分管理、加密功能) 後再提供給客戶。
2. **服務聚合**：將多個 CSP 的服務**整合**成一個新服務 (如將 AWS 和 Azure 整合在一個儀表板管理)。
3. **服務套利**：根據價格或效能在多個 CSP 之間動態切換。

#### 5. 監管機構 (Regulator)
- **定義**：授權機構 (政府、法律或產業團體)。
- **職責**：
- 制定雲端使用的法律與規範 (如 GDPR, HIPAA)。
- 確保持有資料的組織 (CSC/CSP) 符合合規要求。
- 進行調查與執法。

#### 一個故事把五個角色串起來

光看定義很抽象，下面用一個熟悉的場景把五個角色一次到位：

> **情境**：你是某銀行的雲端安全長 (Cloud CISO)，董事會決定把行內 CRM 系統搬上微軟 Azure。因為行內 IT 團隊對 Azure 不熟，所以透過一家本地代理商「伊雲谷」(eCloudvalley) 做轉售與加值服務。Azure 每年會找會計師事務所做 SOC 2 稽核，銀行也要應付主管機關的合規要求。

把這五個角色對應進故事 — 注意每個角色由不同的「人」扮演：

| 角色 | 在故事裡是誰 | 在做什麼 |
|------|--------------|----------|
| **CSC** | 銀行（你） | 決定是否上雲、資料分類、跟 CSP 與 CSN 簽合約、出事最終問責的主體 |
| **CSP** | 微軟 Azure | 提供雲端基礎設施與服務、簽 SLA、負責「雲的安全」（實體與虛擬化層） |
| **CSN** | 伊雲谷 | 代理銷售 Azure 給銀行、提供本地客服、整合服務 — 是銀行採用 Azure 路上的第三方支援角色 |
| **CSB**（CSN 的具體職能） | 伊雲谷做的業務本質 | 在 Azure 上加身分整合、多雲帳單聚合、議價轉售 — 也就是 NIST 三模式裡的「仲介」與「聚合」 |
| **Cloud Auditor**（CSN 的另一種職能） | KPMG、Deloitte 之類的會計師事務所 | 受 Azure 委託做 SOC 2 稽核、核發報告 — 銀行拿這份報告判斷 Azure 能不能信 |
| **監管機構** | 金管會、數位發展部、個資保護委員會 | 訂規則（如《金融機構作業委託他人處理內部作業制度及程序辦法》，俗稱「委外辦法」）、查核、開罰 |

**兩個記憶要點**：

1. **CSN 是「家族姓氏」，CSB 跟 Cloud Auditor 是「職稱」** — 伊雲谷的職稱是 CSB（轉售加值），KPMG 的職稱是 Cloud Auditor（第三方稽核）。兩家公司不同，但都姓 CSN。

2. **監管機構是「永遠不跟你簽合約」的角色** — CSC、CSP、CSN 之間是合約關係（私法），監管機構站在外面看，他們的權力來源是法律（公法）。所以「合約寫得再漂亮」不會抵掉法規責任。題目看到「即使 SLA 寫了 X，仍然要符合 Y」這種句子，Y 通常就是監管機構的要求。

**反射練習**（看到題目立刻對應到角色）：

- 銀行上 Azure 後，誰負責資料分類？→ **CSC**（銀行），雲中的安全永遠是 CSC 的事
- 某代理商幫銀行把 AWS、Azure 帳單整合到一個儀表板，他扮演什麼角色？→ **CSB**（服務聚合）
- KPMG 給 Azure 做 SOC 2 報告，KPMG 是哪個角色？→ **Cloud Auditor**
- 銀行被要求遵守歐盟 GDPR，這個要求來自誰？→ **監管機構**（GDPR 是 EU 法規，不是合約來的）

---

### 雲端運算基本特性

要判斷一個服務是否為「真正的雲端運算」，必須符合以下六個基本特性（根據 ISO/IEC 22123-1、NIST SP 800-145）：

#### 1. 按需自助服務 (On-demand Self-service)
客戶可以在不需要與雲端提供者互動的情況下，自行配置、管理或操作雲端服務。

**實務意義**：
- 使用者透過入口網站或 API 即可立即獲取資源
- 不需要經過採購流程或等待人工處理
- 帶來便利性，但也帶來安全挑戰（任何有信用卡的人都能配置資源）

#### 2. 廣泛的網路存取 (Broad Network Access)
雲端服務隨時隨地可存取，使用者只需要網際網路連線和適當的憑證。

**實務意義**：
- 支援各種設備（桌機、筆電、手機、平板）
- 實現真正的行動辦公
- 挑戰：設備相容性、安全控制的一致性、連接設備的可信度

#### 3. 多租戶 (Multi-tenancy)
**注意**：六大特性裡面唯一非 NIST SP 800-145 定義

單一實例為多個客戶（租戶）提供服務的架構，每個租戶的資料與其他租戶隔離。

**實務意義**：
- 降低成本（共享基礎設施）
- 關鍵要求：租戶之間的資料隔離必須確實
- 安全考量：一個租戶不應能存取或看到另一個租戶的資料

#### 4. 快速彈性 (Rapid Elasticity)
根據需求無縫擴展或縮減資源，對使用者通常是透明的。

**實務意義**：
- 像橡皮筋一樣可拉伸、可收縮
- 適合季節性或活動型企業（如票務系統在開賣時需要大量資源）
- 採用「按使用付費」模式，避免閒置資源的浪費

#### 5. 資源池 (Resource Pooling)
CSP 將資源池化供多個客戶使用，根據工作負載動態分配和調整。

**實務意義**：
- CSP 擁有大量資源（數百到數千台伺服器）
- 資源可根據需求動態分配給不同客戶
- 客戶通常不知道資源的確切實體位置

#### 6. 計量服務 (Measured Service)
資源使用可以被測量、控制、報告和警示，實現透明度和成本控制。

**實務意義**：
- 類似電費或手機帳單，使用多少付多少
- 可以按部門或業務單位分攤成本
- 提供詳細的使用報告，支援成本優化決策

---

### 基礎組件技術

雲端運算雖然是一種新的服務模式，但其底層技術並非全新。了解這些基礎組件有助於理解雲端的運作原理和安全考量。

#### 1. 虛擬化 (Virtualization)
虛擬化是將服務的呈現與支援它的實體基礎設施分離的技術，是雲端服務的核心基礎。

> **註：虛擬化是廣義概念**，共通邏輯是「**打破實體疆域、變成資源池、要時再取**」（正好對應前面「資源池化」基本特性）。它包含多個層次：
> - **計算虛擬化**（本節聚焦）：Hypervisor + VM
> - **網路虛擬化**：VLAN、SDN — 詳見後面「網路」段落
> - **儲存虛擬化**：儲存池、區塊與物件儲存抽象 — 詳見「儲存」段落
> - **OS 層級虛擬化**（容器）：共享 Host kernel — 詳見 D3「容器」段落

**運作方式**：
- Hypervisor 管理實體資源，向虛擬機器呈現虛擬化的硬體
- 允許多個 VM 在同一實體主機上運行
- 支援動態配置和取消配置資源

**安全意義**：
- Hypervisor 的安全至關重要（入侵 Hypervisor = 控制所有 VM）
- VM 之間的隔離必須確實
- 虛擬化層的漏洞可能影響所有租戶

#### 2. 儲存 (Storage)
雲端儲存服務可分為臨時儲存（隨 VM 配置）和持久儲存（VM 取消配置後仍然存在）。

> **為什麼分兩種**：
>
> 課本講的「臨時 vs 持久儲存」是雲端**儲存層**的設計理念 — 但實務上三大 CSP（AWS、Azure、GCP）的 **OS 碟預設都是持久**（VM 重啟不消失），跟理論模型對不起來。學生看到 C 槽不消失會以為學錯了，其實是廠商遷就傳統 IT 使用習慣的妥協。
>
> **業界立場：問題不在儲存，在工作負載的態度**：
>
> CCSK v5 §8.1.2 把議題拉到「**工作負載生命週期**」的高度 — 建議預設用**短期（Ephemeral）工作負載**（用 IaC 動態建立、用完整台砍、再建一台新的），長期只在特殊情況用。理由：短期暴露少、自動化降低錯誤、防止組態漂移。
>
> **再往下挖，雲原生哲學的核心**：
>
> 雲端在問你：「**你願意把哪些東西當作可拋棄、寫進 IaC 重建？**」
>
> | 類別 | 是不是資產？ | 例子 |
> |------|-------------|------|
> | **資料（Data）** | **是**，唯一真正的業務資產 | 客戶交易、上傳檔案、DB 內容 |
> | **無狀態的一切** | **否**，可從 IaC 或 Git 重建 | OS、Patch、套件、設定檔、應用程式碼 |
>
> **判斷標準**：問自己「**這個東西刪掉後，能不能從別的地方重新生出來？**」
> - **能重生** → 不是資產（是規格、放 Git 即可）
> - **不能重生** → 是資產（是狀態、必須持久儲存）
>
> 例：`yum install` 裝出來的 nginx → 不是資產（再裝就有）；客戶上傳到 nginx 的圖片 → 是資產（拉不回來）。設定檔之所以「不算資產」、不是因為不重要，是因為**它已經在 Git 裡有更完整的保護**（版本控制、分散備份、變更審查、回溯）— Git 是它最好的保險。
>
> Lambda、Fargate 是這個哲學的極致 — 你連 OS 跟 Runtime 版本都不 care，只關心程式碼邏輯跟資料連到哪。
>
> **三個層級分清楚**（不要混在一起）：
>
> | 層級 | 在講什麼 | 後面在哪講 |
> |------|---------|-----------|
> | 儲存層 | 臨時 vs 持久（OS 碟、資料碟） | D2.2 雲端資料儲存架構 |
> | 工作負載層 | 短期（Ephemeral）vs 長期（Long-running） | D1.4 設計原則 + D3 |
> | 哲學層 | 只有資料是資產、其他可拋棄 | 整本筆記的核心 mindset |
>
> **為什麼要分短期 vs 長期？** 不是技術分類、是 **CISO 的策略選擇** — 同一個 nginx 可以設計成短期也可以是長期，差別在「**你怎麼對待它的生命週期**」（修補 vs 重建、SSH 改 vs IaC 改）。
>
> **不是非黑即白**：CCSK 推薦預設用短期、CCSP 認知到現實有妥協。老 ERP、金融核心、監管限制應用、lift-and-shift 上雲的舊系統，這些可能還是得長期管理。CCSP 要你做的判斷是「**哪些工作負載該短期化、哪些保留長期**」 — 這個決定影響整個資安策略的預算分配跟控制設計。
>
> **記憶法（給未來的自己）**：三層由具體到抽象、由現場到策略 —
> - **儲存層 = 現場**（眼前看到的磁碟、檔案、Bucket）
> - **工作負載層 = 戰術**（你怎麼經營一台機器的一生）
> - **哲學層 = 戰略**（你公司資安世界觀）
>
> CCSP 考試問的多半是**戰術跟戰略**、CISSP 老手習慣回答「**現場**」所以選錯。課本沒明說這三層分開、知道分層後再讀、每段話的「層級」都會自動定位。

| 類型 | 說明 | 適用場景 |
|------|------|----------|
| **檔案儲存** | 類似傳統硬碟或網路共享 | 一般檔案存放 |
| **區塊儲存** | 資料以固定大小的區塊儲存 | 資料庫、高效能應用 |
| **物件儲存** | 儲存任意二進位物件，無預定義結構 | 日誌、多媒體內容 |

> **地端對應記憶法**（給學生秒懂用）：
> - **檔案儲存** = 雲端版 **NAS、SMB File Server**（mount 上去用、有目錄結構）
> - 例：AWS EFS、Azure Files、GCP Filestore
> - **區塊儲存** = 雲端版 **SAN**（給你一塊空間、自己格式化、可掛載到 VM 當磁碟）
> - 例：AWS EBS、Azure Managed Disk、GCP Persistent Disk
> - **物件儲存** = **API 加網址**存取（每個物件都有 URL、不能掛載、要透過 SDK 或 CLI 操作）
> - 例：AWS S3、Azure Blob、GCP Cloud Storage
>
> **三個常見學生卡住的點**：
> 1. **物件儲存沒有真正的資料夾**：`/2024/cat.jpg` 整串是 key 名字、不是路徑（重新命名「資料夾」要把所有 key 一個個改）
> 2. **物件儲存不可變**（Immutable）：要改檔案 → 整個下載、改完、整個重新上傳。設計上是「寫一次、讀多次」（WORM）
> 3. **物件儲存不能掛載當磁碟**：要透過 API 呼叫（GET/PUT），不像 EBS 可以 mount
>
> 詳細儲存設計、加密策略、安全控制見 D2.2。

#### 3. 網路 (Networking)
透過軟體定義網路 (SDN) 將實體網路硬體虛擬化。

**關鍵概念**：

> **三平面分工**（用機場類比）：
> - **管理平面 = 機場營運中心**：人或 IaC 配置整個系統（蓋跑道、開登機門）
> - **控制平面 = 塔台**：系統自動決策（封包該走哪條路、避免衝突）
> - **資料平面 = 跑道、行李帶**：實際傳送封包（飛機真的在跑、行李真的在跑）
>
> **口訣**：人按 = 管理、系統算 = 控制、封包跑 = 資料

- **管理平面**：配置、設定和取消配置所有雲端資源
- **控制平面**：將配置的資源連接到隔離網路中
- **資料平面（又稱轉發平面）**：傳輸租戶資料到虛擬運算和儲存資源

**客戶可配置**：虛擬電路、防火牆、負載平衡器、NAT、安全群組

#### 4. 資料庫 (Databases)
雲端資料庫服務通常以 PaaS 形式提供：

| 類型 | 說明 | 範例 |
|------|------|------|
| **關聯式** | 結構化資料，強制執行資料關係 | MySQL, PostgreSQL |
| **非關聯式** | 無強制結構，適合分散式處理 | Cassandra, MongoDB |

#### 5. 編排 (Orchestration)
負責接收、滿足、管理、監控和計量雲端基礎設施所有部分客戶服務的 CSP 營運過程。

**雲端作業系統**：
- 每個 CSP 都有自己的編排系統
- 使用硬體、軟體和 API 來完成
- 允許雲端消費者存取資訊或請求服務（自助服務的關鍵組件）

> **編排白話版**：把編排想成**交響樂指揮** — 它自己不拉小提琴、不吹喇叭，但**它讓所有樂手在對的時機演奏對的音符**。
>
> 雲端編排器同樣 — 它自己不存資料、不算 CPU、不轉封包，但**它讓 IAM、運算、儲存、網路、計費系統協調合作**。你按一下「Launch Instance」、編排器在背後跑 17 件事（驗證權限、配額檢查、找實體機、配置 Hypervisor、掛 EBS、配 IP、SDN 設定、Tag、計費啟動...）、3 分鐘後給你一台 VM。
>
> **沒編排器、雲端就不是雲端** — 「自助服務」「快速彈性」全是編排實現的。
>
> **跨領域連結（給 SOC 背景的學員）**：你寫過的 **SOAR Playbook** 就是「資安事件的編排」 — Playbook 收到 alert 後協調 SIEM、EDR、防火牆按順序動作。**雲端編排是同個概念**、只是「樂手」從資安工具變成 IAM、運算、儲存、網路。SOAR 的 O 字面就是 Orchestration、CI/CD pipeline 也是編排 — **同一個指揮家邏輯、不同領域的樂團**。

---

## 1.2 描述雲端參考架構

### 雲端運算活動

ISO/IEC 22123-3:2023 §8.2 定義了各角色的具體活動，了解這些活動有助於釐清責任歸屬。

> **本節視角**：本節依 **ISO/IEC 22123-3:2023 的 3 主角色架構**（CSC、CSP、CSN 並列、各自分子角色），與前面「1.1 雲端運算角色與職責」依 **CCSP 考綱 5 角色架構**（NIST 視角）不同。考試題目可能混用兩套、看清楚題目用哪個視角就答哪個。

#### 雲端服務夥伴 (CSN) 的活動

CSN 在 ISO 22123-3 §8.1.4 下分**3 個並列子角色**（不是線性流程、是 3 種不同的合作夥伴類型）：

> **核心觀念**：這三個分法**不是看公司是誰、是看實際做了什麼活動**。一家公司可以同時扮演多個子角色（例如四大會計師事務所做稽核 + 也做顧問經紀），但「**做哪個活動 = 扮演哪個角色**」。

| 子角色 | 主要活動 | 實務對應 |
|--------|---------|---------|
| **CSN:雲端服務開發者**（Developer） | 設計、建立和維護服務元件、組合服務、測試服務 | **SI 廠商、顧問公司**：伊雲谷、敦陽、宏碁雲端服務 |
| **CSN:雲端稽核員**（Auditor） | 執行稽核、報告稽核結果 | **獨立稽核機構**：四大會計師事務所（KPMG、Deloitte、PwC、EY） |
| **CSN:雲端服務經紀人**（Broker） | 獲取和評估客戶、評估市場、設定法律協議 | **代理商、經銷商**：CDW、SHI、台灣的雲端代理商（如精誠資訊） |

> **白話三個場景**（給學員秒懂用）：
>
> - **Broker 經紀人**：你公司想買 Azure、但**微軟不會直接理你** — 一定要透過台灣代理商（如精誠資訊）協調、開 case、處理付費問題。**這個代理商扮演的就是 CSN:Broker**。它們的核心活動是「協商客戶跟 CSP 之間的關係」。
>
> - **Developer 開發者**：你公司**不懂雲端**、想找顧問規劃「**權限怎麼設計、計費怎麼最優化、自動化容器怎麼跑在雲端上**」 — 找的這家顧問公司扮演的就是 **CSN:Developer**。它們的核心活動是「**為客戶設計、組合、測試雲端服務元件**」。
>
> - **Auditor 稽核員**：你公司用了雲端、需要**對外證明合規**（ISO 27017、SOC 2、GDPR）— 找四大會計師事務所做獨立稽核、出報告。它們扮演的就是 **CSN:Auditor**。它們的核心活動是「**獨立稽核 + 出報告**」。
>
> **三個子角色實務上多半是不同公司**、但同一家公司可以兼多個（例如 KPMG 同時做稽核 + 顧問業務）。**唯一的限制是稽核獨立性原則** — 不能稽核自己開發過的東西、否則違反 ISO 19011 稽核準則。

> **稽核實務 — 教科書 vs 業界現實**（給同學一個概念）：
>
> CCSP 課本暗示 CSC 可以稽核 CSP — **實務上不可能**。AWS、Azure、GCP 太大、不會配合單一客戶的稽核需求（規模不對等、商業祕密、法律不允許其他客戶被你看到）。業界三層解法：
>
> 1. **CSP 那端**：CSP 自己花錢請四大做稽核（SOC 2 Type II、ISO 27001、PCI DSS）、客戶簽 NDA 拿報告就好。SOC 3 是公開精簡版、實務無用、要 **SOC 2 Type II** 才有料。
>
> 2. **聯合稽核（Pooled Audit）**：歐盟金融業多家銀行集合資源、推派代表稽核 CSP、共享報告。**台灣很少實質做**（規模不夠、影響力不夠）。
>
> 3. **真正稽核重點是 CSN 跟 CSC**：
> - **CSN:Developer**（SI 廠商）：他們有你的 AWS key、知道架構、員工流動率高 — **這才是真正的風險點**（Capital One 2019、SolarWinds 2020 都是這環節出事）
> - **CSN:Broker**（代理商）：合約、SLA、退場機制
> - **CSC**（你自己）：內部 IAM、資料分類、加密、政策
>
> **台灣金管會實務**：2023 年 10 月修正發布「金融機構作業委託他人處理內部作業制度及程序辦法」（俗稱「委外辦法」）第 19 條，允許金融機構**委託具資訊專業之獨立第三人查核**雲端 CSP、不需自己去稽核 AWS，惟對委外負最終責任。配套 Q&A 列舉的國際標準為 **ISO 27001/27002/27017/27018/27701、CSA STAR 等**；**SOC 2 未明文列舉**，但屬「等」字涵蓋範圍，實務上廣為金融機構採用作為 CSP 盡職調查證據。
>
> 詳細稽核策略、合規要求見 **D1.5 評估 CSP** + **D6 法律法規**。

#### 雲端服務客戶 (CSC) 的活動 — 依 ISO/IEC 22123-3:2023 §8.2.2

CSC 分 **4 個子角色**（使用者、管理員、業務經理、整合者）、**11 個活動**。
重點在抓「客戶在做什麼」而非編號，可歸成 3 大類：

| 類別 | 活動範圍 |
|---|---|
| **服務使用** | 使用服務、執行試用、監控服務、把 ICT 系統連到雲端 |
| **安全與治理** | 管理服務安全（備份、加密、PII）、管理租戶、處理問題、**要求稽核報告** |
| **業務與選購** | 選擇與購買服務、業務管理、帳單與使用報告 |

> **考點反射**：CSC 是「**要求**稽核報告」（§8.2.2.11），不是自己稽核——呼應前面 1.1「CSC 拿 SOC 2 報告就好、不會直接稽核 AWS」的實務。

> 完整 11 項見 ISO/IEC 22123-3 §8.2.2.2 ~ §8.2.2.12。

#### 雲端服務提供者 (CSP) 的活動 — 依 ISO/IEC 22123-3:2023 §8.2.3

CSP 分 **7 個子角色**（營運、部署、服務、業務、客戶支援、跨雲、安全與風險經理）、**22 個活動**。
歸成 5 大類就好——別背編號：

| 類別 | 活動範圍 | 活動數 |
|---|---|---|
| **服務交付與營運** | 準備系統、定義環境與部署步驟、佈建、SLA 管理、監控、收集指標、資產管理 | 8 |
| **安全與合規** | 管理安全與風險、確保合規、**提供稽核資料**、服務持續性 | 4 |
| **業務管理** | 業務計劃、客戶關係、財務處理、處理客戶請求 | 4 |
| **跨雲協作** | 管理次要 CSP 服務、執行中介、聚合、仲裁 | 2 |
| **網路服務** | 提供網路連接、交付網路服務、網路管理服務 | 3 |

> **考點反射 1**：CSP **提供**稽核資料（§8.2.3.5）↔ CSC **要求**稽核報告（§8.2.2.11）。配對記憶。
>
> **考點反射 2**：「中介、聚合、仲裁」三件事 = NIST 視角的 CSB（Broker）三模式。ISO 把它放進 **CSP 活動**裡（§8.2.3.17），不另外切 CSB 角色——這是 **ISO 跟 NIST 最大的角色架構差異**。

> 完整 22 項見 ISO/IEC 22123-3 §8.2.3.2 ~ §8.2.3.23。

---

### 雲端服務能力類型

ISO/IEC 22123-1 定義了三種雲端能力類型，這些能力類型直接對應到我們熟悉的服務類別：

| 能力類型 | 對應服務類別 | 說明 |
|----------|--------------|------|
| **應用程式能力類型** | SaaS | CSC 可使用 CSP 的應用程式 |
| **平台能力類型** | PaaS | CSC 可使用程式語言和執行環境來部署、管理和執行應用程式 |
| **基礎設施能力類型** | IaaS | CSC 可配置和使用處理、儲存或網路資源 |

---

### 雲端服務類別

這是雲端運算最核心的分類方式，理解三種服務類別的差異對於掌握共享責任模型至關重要。

#### 軟體即服務 (SaaS)
CSP 提供完整的應用程式，客戶直接使用。

**特點**：
- 客戶責任最少，CSP 責任最多
- 無需管理基礎設施、平台或應用程式本身
- 範例：Salesforce, Office 365, Gmail

**優點**：
- 降低硬體和軟體成本
- 簡化應用程式授權
- 減少支援成本

#### 平台即服務 (PaaS)
CSP 提供開發和執行環境，客戶部署自己的應用程式。

**特點**：
- 支援多種程式語言和框架
- 提供自動擴展能力
- 可在多種環境（公有雲、私有雲）間遷移
- 範例：Google App Engine, Heroku, Azure App Service

**優點**：
- 開發人員可專注於程式碼
- 不需管理底層基礎設施
- 支援敏捷開發和快速部署

#### 基礎設施即服務 (IaaS)
CSP 提供基本運算資源，客戶擁有最大控制權。

**特點**：
- 客戶責任最多，CSP 責任最少
- 客戶管理 OS、中介軟體、應用程式
- 範例：AWS EC2, Azure VMs, GCP Compute Engine

**優點**：
- 最大的靈活性和控制
- 可自訂任何層級的配置
- 適合需要特殊配置的工作負載

#### 共享責任模型
理解共享責任模型是雲端安全的基礎：

- **CSP 負責「雲的安全」**：保護雲端基礎設施，包括硬體、軟體、網路和設施
- **客戶負責「雲中的安全」**：服務配置、客戶作業系統、應用軟體、防火牆配置

**責任比較圖**：


---

### 雲端部署模型

選擇哪種部署模型取決於組織的風險偏好、成本、合規要求和業務策略。

#### 公有雲 (Public Cloud)
透過網際網路向公眾提供的服務，客戶按需存取 CSP 的資源。

**優點**：
- 設置簡單且成本低
- 資源配置流程化
- 可擴展性高，無浪費資源（按使用付費）

**主要提供者**：AWS, Microsoft Azure, Google Cloud, Alibaba Cloud

#### 私有雲 (Private Cloud)
由特定實體擁有的專有網路或資料中心，利用雲端技術在防火牆後提供服務。

**優點**：
- 增加對資料、系統和應用程式的控制
- 治理控制的所有權和保留
- 資料位置的保證

**適用場景**：大型複雜組織、高度自訂環境、已有大量技術投資

> 💡 **業界實況：「機房 ≠ 私有雲」 — 跟人吵沒意義、但考試要分清**
>
> 很多企業說「我們有私有雲」、其實只是**機房 + 一些虛擬機**而已。嚴格按 NIST 或 ISO 的雲定義、要叫雲必須滿足 **5+1 大特性**（NIST 5 個：隨需自助、廣泛網路存取、資源池、快速彈性、計量服務 + CCSP 考綱加的多租戶）。
>
> **常見假私有雲徵兆**：
> - 申請一台 VM 要走簽核、3 天後才給 → 違反**隨需自助**
> - 資源固定切死、不能依需求動態擴展 → 違反**快速彈性**
> - 沒有用量計費或計量機制 → 違反**計量服務**
>
> 嚴格說、這些只是**虛擬化機房**、不是真正的雲。同理很多企業講的「混合雲」其實是「機房 + 公有雲連線」、也不算嚴格意義的混合雲。
>
> **但實務上不用跟人家糾正** — 語言是溝通工具、人家說「我們有私有雲」、你知道他講機房就好、雙方知道在聊同一件事就行。高興就好。
>
> ⚠️ **考試例外**：CCSP 題目一律用嚴格定義、看到「私有雲」「混合雲」就當成滿足雲特性的真雲、不是退化的機房。考試時別把實務的寬鬆定義帶進去。

#### 社群雲 (Community Cloud)
為具有相似焦點或共同合規要求的特定群組提供服務。

**特點**：
- 多個組織共享基礎設施
- 提供公有雲的效益，同時有更高的隱私和安全
- 適合有共同法規要求的產業（如醫療、金融）

#### 混合雲 (Hybrid Cloud)
組合多種雲端部署模型（通常是公有雲和私有雲）。

**優點**：
- 保留關鍵任務和流程的所有權
- 重用先前的技術投資
- 使用公有雲滿足非關鍵業務功能
- 支援「雲端爆發」（私有雲容量不足時使用公有雲）

**挑戰**：整合複雜、遷移問題、需要時間建置

#### 多雲 (Multi-cloud)
使用來自多個雲端服務提供者的服務。

**優點**：
- 避免供應商鎖定
- 可選擇各 CSP 的最佳服務
- 增加彈性和冗餘

**挑戰**：管理複雜度增加、需要跨平台技能

> 📘 **CCSK v5 補充**：Domain 4.3「**混合與多雲部署考量**（Hybrid & Multi-Cloud Deployments）」整章在講這個議題。
>
> **多雲策略的 3 種選擇**：
>
> | 策略 | 做法 | 實務例子 |
> |------|------|---------|
> | **同類最佳**（Best of Breed） | 每家 CSP 用各自最強的服務 | AWS 跑運算、Azure 接 AD 整合、GCP 做 BigQuery 分析 |
> | **多雲全面支援**（Full Multi-Cloud Support） | 兩家以上 CSP 平等支援、可互相替換 | 主用 AWS、Azure 做災備、隨時可切換 |
> | **單雲集中**（Consolidation） | 先在一家 CSP 做到成熟、再考慮第二家 | 銀行先把核心都搬到 AWS、3 年後才開始評估 Azure |
>
> CCSK v5 建議大多數 CSC 從**單雲集中**開始、把一家用好之後再擴展、避免一上來就多雲導致管理複雜度爆炸。
>
> **多雲必備工具**：CSPM（雲端安全狀態管理）跨雲統一管理、CASB（雲端存取安全代理）管 SaaS 服務。

> ⚠️ **實務批判：多雲不一定是好答案**
>
> 多雲表面合理：「**怕 AWS 出事、那就再加一個 Azure 備援**」 — 聽起來很 make sense。
>
> 但實務代價很高：
> - **人才成本**：員工要同時懂 AWS 跟 Azure、培訓跟徵才難度都加倍
> - **架構複雜**：兩邊的 IAM、網路、儲存架構都不同、串接費工
> - **管理工具**：要多一套 CSPM 跨雲監控、又一筆錢
>
> **多數情況下、單一 CSP 的多 AZ、多 Region 就夠用**：
>
> | 怕什麼風險 | 解法 | 比多雲簡單嗎 |
> |---------|------|----------|
> | 單一機房災難（電力、火災） | **同區域多 AZ**（AWS 同區自動切換 3 個機房） | ✅ 設定即可、不用學第二家 |
> | 單一區域災難（海底電纜斷、地震） | **跨區域備援**（如新加坡掛了切東京） | ✅ 同一家 CSP 內處理 |
> | CSP 整體服務中斷（罕見） | 才需要多雲 | ❌ 真的要多家 CSP |
>
> **真的需要多雲的情境**（少數）：
> - **法規要求**：金管會要求關鍵系統不能 100% 依賴單一 CSP
> - **特定服務鎖定**：GCP 的 BigQuery、AWS 的 Lambda 等獨家服務
> - **真實的廠商風險**：CSP 漲價、政策變動、地緣政治（中美科技戰）
>
> **結論呼應 CCSK v5**：先把一家 CSP 用好（Consolidation）、把多 AZ、多 Region 架構做扎實。**不要一上來就多雲、複雜度爆炸、成本爆炸、還不一定比較安全**。

> ⚠️ **責任永遠在你：外包職責、不能外包問責**
>
> 上一個 note 講「多雲是過度設計」 — 但**單雲也不是萬無一失**。這裡有 CCSP 的核心警句：
>
> > **你可以外包職責（誰來做）、但你不能外包責任（問責）**
> > — ENISA Cloud Computing Risk Assessment (2009)
>
> **真實案例 1：政府機關官網掛在雲端業者**
>
> 雲端業者出事、政府官網無法存取。記者採訪時官員說「**那是雲端業者掛了、不是我們的問題**」 — 但**消費者面對的是政府、不是 CSP**。從用戶角度、政府就是責任方。SLA 賠的錢、彌補不了商譽損失跟民眾抱怨。
>
> **真實案例 2：Cloudflare 大故障**
>
> 多家企業用 Cloudflare CDN、號稱 100% 不會斷。某次 Cloudflare 全球斷線、企業想把 DNS 切回直連、結果**連 Cloudflare 後台也掛了** — DNS 被「咬死」在 Cloudflare、根本無法切換。**整套備援計劃形同虛設**。
>
> **教訓對照**：
>
> | 你以為 | 真相 |
> |------|------|
> | CSP 掛了、SLA 賠償就好 | SLA 賠的錢**彌補不了商譽、客戶流失** |
> | 用大廠就安全 | Cloudflare、AWS 都掛過、**100% uptime 是行銷話術** |
> | 我有備援計劃 | 備援計劃**也依賴同一家**、等於沒有 |
>
> **CCSP 視角**：
>
> - **評估 CSP**（D1.5）：問「**你掛了我怎麼辦？**」、別只看認證跟 SLA 數字
> - **合約**（D6）：寫明賠償條款、但別期待賠償能彌補真實損失
> - **BCDR 規劃**（D1.4、D5）：必須**真實演練**、備援方案**不能跟主方案在同一個 CSP**
> - **關鍵業務**：BCDR 必須有**跨 CSP 或本地的 Plan B**
>
> **跟前一個 note「多雲不是萬靈丹」對話**：兩個原則不衝突、**依業務重要性決定備援等級**：
> - **一般業務** → 單雲多 AZ、多 Region 就夠（避免過度設計）
> - **關鍵業務** → **跨 CSP 或本地備援**（責任不能外包、必須有 Plan B）

---

### 雲端共享考量（跨領域方面）

這些考量應在組織的雲端運算生態系統中協調一致地實施，是跨所有角色、活動和組件的共同議題。

#### 關鍵共享考量

> 互通性與可攜性的詳細框架另見 **ISO/IEC 19941:2017**（雲端運算互通性與可攜性）。

| 考量 | 核心觀念 | 實務例子 |
|------|---------|---------|
| **互通性** | 不同來源的組件能協同工作、可替換 | AWS、Azure、GCP 的 IAM 都支援 SAML 認證、可互通 |
| **可攜性** | 應用程式和資料能輕鬆移到其他平台 | Docker 容器打包後、可從 AWS 搬到 GCP 直接跑 |
| **可逆性** | 客戶能取回資料、CSP 能完全刪除 | 合約終止後、CSP 必須交還資料並徹底刪除 |
| **可用性** | 系統和資源隨時可用、是雲端的單點故障 | AWS S3 承諾 99.99% uptime、一年最多停機 52 分鐘 |
| **安全** | 保護資料和系統免受威脅 | CSP 顧底層、客戶顧設定（共享責任模型） |
| **隱私** | 符合各地資料保護法規、跨境議題複雜 | 歐盟客戶資料不能跨境到美國處理（GDPR） |
| **彈性** | 中斷事件中繼續運營的能力 | AWS 多 AZ 部署、單一機房失效自動故障轉移 |
| **效能** | 網路、運算、儲存、資料的效能最佳化 | 選 ap-northeast-1（東京）region 讓台灣客戶訪問變快 |
| **治理** | 定義行動、分配責任、驗證效能 | 定期審視雲端帳單、刪除閒置 VM、控管成本 |
| **維護和版本控制** | 服務升級時清楚標示版本 | Office 365 從 2019 升 2024、客戶要知道現在用哪版 |
| **服務層級和 SLA** | CSP 跟 CSC 之間的服務品質協議 | 合約承諾 99.9% uptime、未達標 CSP 退費補償 |
| **可稽核性** | 提供足夠證據支援審查和調查 | AWS CloudTrail 記錄所有 API 呼叫、供稽核員追溯 |
| **監管** | 遵守法定、監管和法律要求 | 金管會 2023 委外辦法、銀行業必須遵守 |
| **外包** | 服務可能涉及多層供應鏈 | Salesforce（SaaS）跑在 AWS（IaaS）、底層多層供應鏈 |

> 💡 **批判性思考：這 14 條到底在約束誰？**
>
> 這 14 條**不是強制標準、不是法律條文**、是「**雙方都要考慮的議題清單**」。實際上每條的強制力來源不同 — 有些 CSP 自願做、有些被市場壓力推、有些被法規強迫、有些 CSP 根本不想做。
>
> **依強制力來源分四類**：
>
> | 強制來源 | 議題 | 邏輯 |
> |---------|------|------|
> | **法律強制** | 監管、隱私 | GDPR、HIPAA、金管會規定、不做罰錢 |
> | **合約強制** | SLA、可用性、效能、可稽核性 | 合約寫了不做違約賠錢 |
> | **市場壓力** | 可攜性、互通性、可逆性 | CSP 不想做（鎖客戶有利）、但客戶用腳投票會流失 |
> | **CSP 自願** | 安全、彈性、效能 | 做不好就沒生意、CSP 自己也想做 |
>
> **真實案例 — 為什麼 Yahoo 不幫你搬到 Gmail**：
>
> Yahoo 商業上沒有誘因配合（搬走 = 失去客戶）、所以不會主動提供無痛匯出。但歐盟 GDPR 第 20 條「**資料可攜權**」（Right to data portability）**強制**業者提供 — 這就是「**法律凌駕商業利益**」的典型。
>
> **CCSP 的視角 — 14 條主要是 CSC 的武器**：
>
> - 14 條是 **CSC 評估 CSP 跟談合約的清單**、不是 CSP 自動會給
> - **CSP 不想做的東西、CSC 必須主動寫進合約**（可攜性、可逆性、可稽核性是經典）
> - 「共享責任」不代表「自動共享」 — CSC 不要、CSP 不會給
>
> **考試題目記憶法**：
> - 問「**CSC 評估 CSP 要看什麼**」→ 14 條都是評估面向
> - 問「**合約中要寫什麼**」→ 14 條都要反映在合約、特別是 CSP 不想做的
> - 問「**誰負責**」→ 共享責任、但**CSC 必須主動要求、CSP 不會自願給**

---

### 相關技術的影響

雲端運算為許多新興技術提供基礎，這些技術因雲端的自動化、彈性和可擴展性而在經濟上變得可行。

> 💡 **為什麼雲端課要講這 9 個技術？**
>
> CCSP 不教技術原理（那是 CISSP 跟專業書的領域）、教**這些技術在雲端視角下的議題**：
>
> | 技術 | 為什麼 CCSP 要講 |
> |------|-------------|
> | **AI、ML、資料科學** | 雲端是主要交付平台（AWS SageMaker、Azure ML） |
> | **量子運算** | 量子作為雲端服務（AWS Braket）、且威脅現有雲端加密 |
> | **容器** | 雲端原生架構的基礎（K8s、ECS） |
> | **邊緣運算** | 雲端的地理延伸（CDN、AWS Wavelength） |
> | **機密計算** | 雲端解決「客戶不信任 CSP」的議題（AWS Nitro Enclaves） |
> | **區塊鏈** | 雲端業者提供區塊鏈服務（AWS QLDB） |
> | **IoT** | IoT 數據必須上雲處理（IoT Hub、AWS IoT Core） |
>
> **CISSP vs CCSP 的角度差異**：
> - **CISSP** 講「**後量子密碼遷移**」、容器跟 ML 的**技術原理**
> - **CCSP** 講「**怎麼安全用量子雲端服務**」、容器在雲端的**部署架構**
>
> 同一個技術、CISSP 教**怎麼運作**、CCSP 教**怎麼在雲端用得安全**。

#### 資料科學 (Data Science)
對不同形式的資料進行分析，以提取洞察或開發有用資訊。

**與雲端的關係**：
- 雲端提供大規模資料儲存和處理能力
- 支援大數據和資料湖等應用
- 使複雜分析在經濟上可行

#### 機器學習 (Machine Learning)
使用電腦程式調整演算法來訓練自動化系統，產生快速有效的期望結果。

**與雲端的關係**：
- 雲端提供訓練模型所需的大量運算資源
- 按需付費模式降低了 ML 的入門門檻
- 主要 CSP 都提供 ML 即服務

#### 人工智慧 (AI)
模擬人類行為或互動的任何技術或技術集的通用術語。

**與雲端的關係**：
- 以前需要專用硬體的大量資本支出
- 雲端使 AI 服務對大多數商業模式變得可負擔
- 可應用於雲端資料集進行高階分析

#### 區塊鏈 (Blockchain)
使共享交易會計帳本具有全球可見性的技術，建立不可變帳本。

**主要特性**：
- 去中心化性質增加安全性（無單點故障）
- 工作量證明共識驗證所有交易
- 不可變帳本（無法在參與者不知情的情況下更改資料）
- 時間戳交易驗證，允許即時資料驗證

**適用場景**：多個參與者、分散式參與者、無需受信任第三方、數位資產轉移

#### 物聯網 (IoT)
包含嵌入式感測器、控制器的眾多產品，與上游控制器或其他 IoT 設備互動。

**與雲端的關係**：
- IoT 設備通常計算能力有限，需要雲端支援
- 雲端服務可管理 IoT 部署、提供庫存和更新
- 可作為 IoT 設備之間的中央通訊平台
- 提供後端處理（如自然語言處理）

#### 容器 (Containers)
包含執行軟體套件所需的所有必要程式碼（包括函式庫和相依性）的軟體套件。

**特點**：
- 比傳統 VM 更輕量級
- 使用更少資源，啟動、停止更快
- 支援快速擴展和縮減
- 是短期運算的基礎

**與 VM 的比較**：

VM：完整作業系統 + 應用程式 + 相依性
容器：只有應用程式 + 相依性（共享 OS 核心）

#### 量子運算 (Quantum Computing)
使用量子態和量子位元來執行計算的新興運算架構。

**特點**：
- 量子位元可以是 0、1 或兩種狀態的疊加
- 有潛力更有效地解決某些困難計算
- 目前實際實作有限

**安全影響**：
- 可能降低公鑰加密演算法（**RSA、ECC、Diffie-Hellman**）的強度
- **對稱加密（如 AES）影響較小**、加長金鑰長度即可（如 AES-128 → AES-256）
- 需要關注後量子密碼學（PQC）的發展、NIST 已選定 CRYSTALS-Kyber、CRYSTALS-Dilithium 等標準

#### 邊緣運算 (Edge Computing)
將運算元素更靠近資料來源或服務請求者，主要目標是減少延遲。

**範例**：
- 內容分發網路 (CDN)：將內容分發到全球各地的邊緣伺服器（嚴格說 CDN 是「邊緣**分發**」、不是真正的邊緣**運算**；現代 CDN 如 Cloudflare Workers、AWS Lambda@Edge 已升級為真邊緣運算）
- IoT 閘道器：在邊緣處理資料後再上傳到雲端

> 💡 **CDN 已經不只是「靜態快取」**
>
> 現代邊緣平台（Cloudflare Workers、AWS Lambda@Edge、Fastly Compute@Edge）讓 JavaScript、商業邏輯**直接部署在 CDN 邊緣節點**、用戶請求不需要回到源頭就能處理。
>
> **新舊對比**：
> - **舊 CDN**：用戶請求 → CDN 檢查快取（沒有就回源） → 你公司網站處理
> - **新邊緣運算**：用戶請求 → CDN 邊緣節點**直接執行 JavaScript** → 回應用戶
>
> CDN 邊緣節點本來就有的資訊（用戶 IP、地理位置、裝置類型、HTTP Header）+ 邊緣資料庫（Workers KV、D1）、能處理大部分動態邏輯。**真正需要動到核心系統的請求才回源**。
>
> 這就是「**邊緣分發**」升級成「**邊緣運算**」的關鍵 — 算力下沉到邊緣、不只是內容下沉。

#### 機密計算 (Confidential Computing)
在處理過程中將敏感資料隔離在受保護的 CPU 區域（受信任執行環境, TEE）中。

**解決的問題**：
- 傳統上難以保護「使用中」的資料（相對於靜態資料和傳輸中資料）
- 提供對 CSP 和其他租戶的資料隔離保護

---

## 1.3 了解與雲端運算相關的安全概念

> 本節介紹雲端環境中的通用安全概念。這些概念並非雲端獨有，但在雲端環境中可能需要不同的實施方式。

### 密碼學和金鑰管理

#### 密碼學 (Cryptography)
在對手存在的情況下偽裝資訊的方法，是提供多種安全服務的重要工具。

**提供的安全服務**：
| 服務 | 說明 |
|------|------|
| **機密性** | 防止未經授權的資訊披露 |
| **完整性** | 確保資料未被未經授權修改 |
| **真實性** | 證明資料來源 |
| **不可否認性** | 發送者無法否認已發送的訊息 |
| **存取控制** | 限制對資源的存取 |

#### 加密 (Encryption)
將明文（可讀資料）轉換為密文（不可讀資料）以防止未經授權存取的過程。

**關鍵概念**：
- 只有擁有正確密碼金鑰的人才能解密資料
- 加密強度取決於演算法和金鑰長度

#### 金鑰管理 (Key Management)
監督密碼金鑰的完整生命週期管理。

**生命週期階段**：


**雲端中的挑戰**：
- 誰控制金鑰？CSP 還是客戶？
- 金鑰儲存在哪裡？
- 如何確保 CSP 無法存取客戶的金鑰？

---

### 身份和存取控制

身份和存取管理 (IAM) 是雲端安全的核心組件，涵蓋整個身份生命週期。

#### 身份生命週期


> #### 雲端身份的兩層架構
>
> 地端習慣的「使用者帳號、Administrator、服務帳號」三分法，到了雲端分裂成兩個獨立層級：
>
> | 層級 | 內容 | 攻陷後果 |
> |---|---|---|
> | **管理面**（Management Plane） | 登入 AWS Console、Azure Portal、Entra ID 的帳號，呼叫 CSP API 操作資源 | 整個雲端帳戶失守（**CCSP 主戰場**） |
> | **工作負載面**（Data Plane） | VM 內的 Linux、Windows 使用者、應用程式 DB 連線帳號 | 單一系統失守，跟地端一樣處理 |
>
> 下面討論的「使用者、特權、服務」存取，**預設指的是管理面**——這才是雲端 IAM 的新風險所在（暴露在 Internet、權限範圍大、是新的安全邊界）。

#### 使用者存取 (User Access)
針對人類使用者的存取管理。

| 項目 | 說明 |
|------|------|
| **身份配置** | 建立數位身份並頒發給身份所有者 |
| **身份取消配置** | 當使用者不再需要存取時移除身份，**避免授權蔓延** |
| **身份識別** | 使用者聲明身份（如輸入使用者名稱） |
| **驗證** | 驗證使用者聲稱的身份（密碼、生物特徵等） |
| **授權** | 確定使用者可以做什麼 |

> **授權蔓延（Authorization Creep）**：使用者換角色、調部門時，舊權限沒收回，逐漸累積出多餘存取權。是 deprovisioning 的核心防範對象，也是稽核最常抓到的發現之一。對策：定期權限審查、HR 系統與 IAM 整合自動觸發收權、最小權限原則。

#### 特權存取 (Privileged Access)
管理系統中具有最高權限的使用者帳戶。

**重要性**：
- 特權帳戶被入侵可能導致災難性後果
- 常見錯誤：過度配置管理帳戶的存取權限

**最佳實踐**：
- 只在需要時授予存取權限（JIT, Just-In-Time Access）
- 不再需要時自動撤銷，避免常駐特權（Standing Privileges）
- 增強的日誌記錄和監控
- 使用特權存取管理 (PAM) 工具
- 強制使用多因素驗證 (MFA)

#### 服務存取 (Service Access)
非人實體（過程、程式、設備）的存取授權。

**雲端中的挑戰**：
- 可能需要動態配置大量短期存在的服務
- 常見失敗：不了解授予服務的存取級別
- 過度寬鬆的預設存取權限

> #### 集中式目錄服務（IAM 的地基）
>
> CCSP 課本把集中式目錄服務形容為 IAM 的**基礎**——所有身份、群組、屬性的權威來源都在這裡。
>
> | 環境 | 主流目錄服務 | 通訊協定 |
> |---|---|---|
> | 地端 | Active Directory | LDAP、Kerberos |
> | 微軟雲端 | Entra ID（前身 Azure AD） | REST API（Graph）、OAuth、OIDC、SAML |
> | AWS | AWS IAM、IAM Identity Center | AWS API、SAML |
> | GCP | Cloud Identity | OAuth、OIDC、SAML |
>
> **雲端整合三種模式**：
> - 純地端：自建 AD，雲端透過聯邦登入
> - 純雲端：直接用 Entra ID 或 AWS IAM
> - 混合：地端 AD ＋ Entra Connect 同步到雲端（企業最常見）
>
> **重要區別**：Entra ID **不是**雲端版的 AD——它沒有 OU、預設不支援 LDAP（除非加開 Domain Services）、結構是扁平的。微軟 2023 年從 Azure AD 改名就是想消除這個誤解。它扮演同樣的角色（身份權威來源），但實作技術完全不同。

---

### 資料和媒體清理

組織必須考慮在需要時從雲端服務中安全移除資料的選項。

#### 清理方法比較

| 方法 | 說明 | 雲端適用性 |
|------|------|------------|
| **實體銷毀** | 焚燒、粉碎或其他方式銷毀媒體 | ❌ 客戶無法控制 |
| **消磁** | 使用強力磁鐵擾亂磁性媒體上的資料 | ❌ 客戶無法控制 |
| **覆寫** | 在資料上寫入隨機資料 | ❌ 不知道資料確切位置 |
| **加密抹除** | 銷毀加密金鑰使資料無法讀取 | ✅ 唯一可行方法 |

#### 覆寫 (Overwriting)
在原資料上寫入隨機或固定模式內容，覆寫次數越多銷毀越徹底。

**雲端中的限制**：
- 客戶不知道資料的**確切實體位置**——無法精準覆寫
- 多租戶共用實體磁碟，覆寫可能影響其他客戶
- CCSP 課本明示：**資料位置未知時，覆寫即被排除為雲端銷毀選項**

#### 加密抹除 (Cryptographic Erasure)
故意銷毀加密金鑰的過程，使加密資料變得不可讀。

**執行要點**：
- 資料**從一開始進入雲端就要全程加密**（encrypt-from-inception）——退場時才加密無法銷毀 CSP 已產生的明文副本（快照、跨區複本、退役磁碟殘留）
- 必須確保加密金鑰完全不可恢復
- 如果第三方管理金鑰，這可能難以實現
- 單獨銷毀金鑰不是全面方法（金鑰可能用鑑識技術恢復）

> **後面會展開**：金鑰由誰保管（CSP-managed、Client-managed、External KMS 三種模式）以及 HSM 在雲端的角色，**D2.3「設計與應用資料安全技術和策略」** 整節在講。這裡先有個概念就好，看不懂沒關係。

> **老師補充：從 CISSP 視角看資料銷毀**
>
> 五種方法（單純刪除、覆寫、消磁、實體銷毀、加密抹除）本質上在比同一件事：**資料被復原的機率有多低**。
>
> | 方法 | 復原機率 | 失敗模式 |
> |---|---|---|
> | 單純刪除 | **極高** | 只動 inode、索引，資料還在原磁區，`rm -f`、資源回收筒清空都救得回來 |
> | 覆寫（多次填 0/1） | 中 | 殘磁可被鑑識復原；SSD 上更不可靠 |
> | 消磁 | 低-中 | 可能漏掉某些區塊、過程中停電會殘留資料 |
> | 實體銷毀 | **極低** | 鐵鎚打爛、焚燒、粉碎，幾乎不可能復原 |
> | 加密抹除 | 看金鑰 | 金鑰完全銷毀 = 密文等同亂數；金鑰外流 = 全敗 |
>
> **CISSP 考試直覺**：選最物理的——「拿鐵鎚把硬碟打爛」（實體銷毀）復原機率最低。題目模糊時挑這個多半對。
>
> **CCSP 換了戰場**：你不能跑去 AWS 機房拿鐵鎚敲硬碟、也不能去消磁。連覆寫都做不精準（不知道資料在哪、SSD 機制不配合）。**唯一能完全自己控制的剩加密抹除**——資料事先加密、刪除資料、最後銷毀金鑰；攻擊者就算撈到密文，沒金鑰就只是亂數。

> **延伸：為什麼雲端不能用 DoD 7 次覆寫（5220.22-M）？**
>
> DoD 5220.22-M 是 1995 年針對**機械硬碟**設計的——前提是能精確地寫到指定實體磁區。雲端做不到，原因四點：
>
> 1. **位置未知**：你不知道資料在哪個實體裝置、哪個磁區，多租戶共用儲存，精準覆寫無從下手
> 2. **副本到處都是**：你的「一份」資料散在備份、快照、跨區複本、快取，覆寫一處不影響其他
> 3. **沒有低階存取**：你只能呼叫 S3、EBS 等 API，無法直接下 ATA Secure Erase 指令或 raw block write
> 4. **SSD 機制不適用**：CSP 機房早就全 SSD，SSD 的 wear-leveling 讓「邏輯位址」跟「實體 cell」不固定——你以為覆寫了 LBA 100，實際被映射到另一個 cell、原 cell 還留有資料。**DoD 7 次覆寫對 SSD 反而有害**（加速磨損、不保證銷毀）
>
> 補充兩個事實：
> - **DoD 自己在 2006 年就從 NISPOM 移除多次覆寫規範**（NIST SP 800-88r2 腳註 5 明示）
> - **NIST SP 800-88r2**（2025/9 發布）對「邏輯、虛擬儲存（如雲端儲存）」明確指出：因為資料擁有者**無法直接接觸實體 ISM**，**加密抹除可能是唯一可行的 purge 技術**；同時「destroy」（實體銷毀）方法**不適用**這類儲存

> **老師補充：「全程加密」實務上做得到嗎？**
>
> 「全程加密」**不是**「資料任何時刻都不能是明文」——CPU 沒辦法執行加密過的指令、資料總得有一刻是明文才能被處理。正確理解是**資料三狀態（Three States of Data）每一層都要規劃**：
>
> | 資料狀態 | 是否能加密 | 雲端做法 |
> |---|---|---|
> | **At Rest**（存在磁碟） | ✅ 必須 | KMS-CMK、BYOK 透明加密、SSE-KMS、TDE |
> | **In Transit**（網路傳輸） | ✅ 必須 | TLS 1.2+、IPsec VPN、mTLS |
> | **In Use**（記憶體被處理） | ⚠️ 傳統做不到、現代有解 | 一般：明文只在記憶體、不落盤；極端：機密計算（Confidential Computing） |
>
> 「**全程加密**」的真意：**磁碟上永遠只有密文**。記憶體那一瞬間是明文，但生命週期極短、隨程序結束消失、**從不持久化**。所以你銷毀金鑰時，磁碟上所有副本（含 CSP 偷拍的快照、跨區複本）瞬間變廢物。
>
> **真的撞牆的兩種情境**：
>
> 1. **加密欄位要查詢、JOIN、排序**：解法是欄位級加密、Tokenization 兩件事搭配（PCI DSS 標配，銀行卡號的標準做法）
> 2. **計算極敏感、不能讓 OS、hypervisor 看到記憶體**：解法是機密計算（Intel SGX、AWS Nitro Enclaves、Azure Confidential VMs）——連 CSP 工程師都看不到記憶體
>
> 業界 99% 的金融場景，「欄位級加密、Tokenization、HSM」這條傳統路線就夠了，剩 1% 才需要機密計算。

> **老師補充：先分級，別拿大砲打蚊子**
>
> 上面講的全程加密不代表「**所有資料**都要加密」——這違反資安最底層的原則：**資源有限，先做最緊急的**（風險導向）。
>
> ISC2 全系列（CISSP、CISM、CCSP）的順序永遠是：
>
> **資料分類 → 威脅評估 → 風險評估 → 控制措施（按等級配套）**
>
> CCSP 課本 **D2.5「計畫和實施資料分類」** 整章在教這個。**沒分類就全加密 = 倒著做**。
>
> **過度加密的副作用**：
> - **成本爆炸**：KMS API 收費、HSM 數十萬一台、金鑰生命週期人力
> - **效能下降**：每次讀寫多一層加解密、查詢慢、JOIN 不能用
> - **debug 噩夢**：log 加密後，半夜出事工程師救不了火
> - **稽核反效果**：看到「全部都加密」，稽核員反而懷疑你沒分類過、用加密當免責牌
> - **攻擊面擴大**：金鑰系統一旦失守，連無敏感資料都跟著失守——**過度保護 = 增加風險**
>
> **金融業實務分級**：
>
> | 分級 | 範例 | 加密策略 |
> |---|---|---|
> | **極機密** | 身份證、信用卡 PAN、生物特徵 | 欄位級加密、Tokenization、HSM |
> | **機密** | 帳戶餘額、交易紀錄、信評 | TDE 全庫加密、KMS-CMK |
> | **內部** | 員工績效、業務簡報 | 儲存層原生加密（SSE-S3 即可） |
> | **公開、低敏感** | access log、健康檢查 metric | **可以不加密** |
>
> **常見陷阱**：你以為 access log 沒機敏資料，但開發者偷懶把整個 request body 印進去 → 卡號、身份證就跑進 log 了。**「低敏感 log 不加密」要配套 DLP 掃描、log 內容稽核**，確認真的無敏感才能放行。
>
> **CCSP 考點反射**：題目「資料搬上雲、預算有限、第一步該做什麼？」 → 答案永遠是**建立資料分類政策**，不是部署全盤加密。

> **老師補充：為什麼最後責任還是在 CSC？「責任不可外包」與補償性控制**
>
> 學員常問：「CSP 都通過 ISO 27001、SOC 2，硬碟銷毀有專人護送、流程齊全，那我為什麼還要做加密抹除？」這個問題問得很好——背後牽涉 CCSP 最核心的責任歸屬哲學。
>
> **Responsibility 跟 Accountability 不一樣**：
>
> | 概念 | 中文 | 能外包嗎？ |
> |---|---|---|
> | **Responsibility**（執行責任） | 誰負責「做」這件事 | ✅ 可以外包給 CSP（簽合約、付錢） |
> | **Accountability**（最終問責） | 出事誰被告、誰被罰、誰丟工作 | ❌ **永遠在 CSC** |
>
> CCSP 經典原文：「**You can outsource the work, but not the accountability.**」CSP 把銷毀做爛、客戶資料外洩——金管會找的是你銀行，不是 AWS。CSP 賠的最多是 SLA 違約金（通常很小），**法律責任、品牌商譽、罰款**全是你的。
>
> **這也是為什麼客戶必須自己加密**——不是因為 CSP 不可信，而是因為你**無法直接驗證 CSP 在每個磁碟、每個機房、每個工程師手上的執行**。所以採取**補償性控制**：自己加密、自己掌控金鑰，CSP 流程出包時，金鑰銷毀仍能達成「資料不可讀」的安全目標。
>
> 這就是縱深防禦在雲端的具體實踐：
>
> ```
> 攻擊者要讀到你的資料，必須同時突破：
> ① CSP 實體安全（門禁、護送、銷毀流程） ← CSP 負責
> ② CSP 邏輯隔離（多租戶、hypervisor） ← CSP 負責
> ③ 客戶端加密（你加密、你掌控金鑰） ← CSC 負責 ★
> ```
>
> 任一層獨立失守都不會直接讓資料外洩。「萬一 CSP 沒按流程銷毀」就是 ① 失守的情境，③ 還在守，資料對攻擊者來說還是亂數。
>
> **從風險處理角度看**：客戶端加密屬於 **Risk Modification**（風險修改）——你沒有迴避（還是上雲）、沒完全分擔給 CSP（不信任他們會 100% 銷毀）、沒接受（不接受明文外洩），所以**主動施加一個控制來修改風險**。
>
> ---
>
> **重要觀念釐清：「共享責任」這個翻譯有點誤導**
>
> Shared Responsibility 字面是「共享責任」，但精準的意思是「**分工執行、最終問責不變**」：
>
> - **CSP 提供**：基礎安全能力（實體、hypervisor、加密選項、SOC 2 報告）
> - **CSC 必須**：主動採用、配置、驗證、補償
> - **法律與監管**：永遠找 CSC——GDPR、金管會、HIPAA 都罰資料控制者，不罰處理者
>
> CISSP 老手上雲常見盲點：「我都付錢給 AWS 了、他們有 ISO 認證，幹嘛還要這麼多事？」——這個盲點，CCSP 整本書都在矯正。

---

### 網路安全

網路安全在雲端中與任何環境一樣重要，但共享責任的分配因服務類型而異。

#### 網路安全考量面向

用戶端網路安全
    ↓
過境網路安全（公共網際網路、VPN）
    ↓
CSP 邊界安全
    ↓
雲端基礎設施內部安全

| 層級 | 在哪 | 銀行場景例子 | 主要負責 |
|---|---|---|---|
| **用戶端** | 行員筆電、行動裝置、瀏覽器 | EDR、MDM、VPN client、MFA token、瀏覽器端 TLS | CSC |
| **過境** | 從用戶到 CSP 之間的所有網路路徑 | TLS 1.3、IPsec VPN、AWS Direct Connect、Azure ExpressRoute、MPLS 專線 | CSC、電信業者 |
| **CSP 邊界** | CSP 雲端機房對外的接口 | AWS Shield（DDoS 防護）、CloudFront WAF、Azure Front Door、Cloudflare 預擋層 | CSP 為主，CSC 可加層 |
| **雲端內部** | CSP 機房內、你 tenant 內的虛擬網路 | VPC 隔離、NSG 規則、Bastion host、私有 endpoint、service mesh | CSC（管理面） |

> **老師補充**：四層裡 **CSP 邊界**最容易被誤會——它**不是**只有 CSP 自己處理。實務上銀行普遍會在 CSP 前面再放一層自己的 WAF 或 CDN（如 Cloudflare、Akamai），原因有三：(1) 不想完全依賴 CSP 的 DDoS 服務；(2) 跨多雲時統一一個進入點；(3) WAF 規則自己掌控、出事自己能調整、不用等 CSP support。所以「CSP 邊界」嚴格說是「**面向 internet 的接收點**」，CSP 跟 CSC 都可以在這層加裝。

#### 網路安全群組 (Network Security Groups)

**白話**：雲端版的防火牆規則。但不在硬體盒子裡——是 CSP 提供的「**標籤式規則**」，掛在 VM 或子網上。

**地端 vs 雲端對比**：

| 地端做法 | 雲端做法 |
|---|---|
| 機房放實體防火牆（Cisco ASA、Palo Alto） | 在 Console 設一組規則 |
| 網管登入防火牆 GUI 設規則 | 把規則「貼到」VM 或子網上 |
| 規則限定在這個防火牆所在的網段 | 規則跟著 VM 走，VM 漂到哪都生效 |

**各家 CSP 叫法不同**：

| CSP | 對應名稱 |
|---|---|
| AWS | Security Group（SG）、Network ACL |
| Azure | Network Security Group（NSG） |
| GCP | Firewall Rules |

**核心特性**：
- **預設拒絕**：建立後沒加規則就是不通
- **Stateful**：自動允許 return traffic，不用為了讓回應通過再加反向規則
- **跟著工作負載走**：VM 漂移到不同主機都不影響規則生效
- 可以做 VM 對 VM 的微分割（地端 VLAN 加 ACL 做不到這麼細）

**不當配置常見踩坑**：

| 踩坑 | 後果 |
|---|---|
| 圖方便寫 `0.0.0.0/0 → 22 (SSH)` | 整個 internet 可以對你打 SSH 暴力破解 |
| 測試環境 NSG 沒收緊 | 公雲掃描器幾分鐘內找到、被加入殭屍網路 |
| Outbound 完全沒限制 | VM 被入侵後可對外連 C2、外洩資料 |
| 多個 NSG 疊在同一張網卡 | 規則衝突、debug 噩夢 |

> **老師補充**：雲端沒有「機房邊界防火牆」這個概念——每台 VM 都直接面對 internet，沒設 NSG 就等於裸奔。地端習慣靠機房邊界保護內部 VM 的人最容易踩這坑。**「邊界消失」是雲端網安最大的觀念轉換**，跟前面 IAM 講的「身份是新邊界」是同一個底層哲學。

> **老師補充：NSG 最讓人混淆的點——規則可以掛在多個層級**
>
> 我自己當年學雲端最卡的就是這塊。NSG 規則可以**同時掛在不同層級**，每層各有自己的規則，流量要全部通過才會放行。
>
> **三層常見配置**（流量從外進入 VM）：
>
> ```
> Internet
> ↓
> [① 邊界層] WAF、CDN、Front Door ← 應用層過濾
> ↓
> [② 子網層] Subnet NSG、Network ACL ← L3-L4 過濾，整個 subnet 共用
> ↓
> [③ 網卡層] NIC NSG、Security Group ← L3-L4 過濾，每台 VM 獨立
> ↓
> VM
> ```
>
> **AWS 跟 Azure 的對應**：
>
> | 層級 | AWS | Azure |
> |---|---|---|
> | 邊界層 | AWS WAF、CloudFront | Application Gateway WAF、Front Door |
> | 子網層 | Network ACL（stateless，可設 deny） | NSG 綁 subnet |
> | 網卡層 | Security Group（stateful，只能 allow） | NSG 綁 NIC |
>
> **規則組合邏輯**：
> - **多層 AND**：流量要進 VM 必須**同時通過**邊界、subnet、NIC 三層的允許規則，任一層擋下就不通
> - **同層 OR**：同一層多條 allow 規則，符合任一條就通
>
> **學員最常踩的混淆**：
>
> | 踩坑 | 真實場景 |
> |---|---|
> | 只在 NIC 設規則、忘了 subnet NSG | subnet 預設 deny，VM 完全連不上 |
> | AWS NACL 是 stateless | 開了入站還要記得開出站 return traffic，不像 SG 自動處理 |
> | 規則套錯層級 | 想做整個 subnet 的廣域阻擋、卻設在每台 VM 的 SG，漏一台就破口 |
> | 安全群組互相引用搞錯方向 | Web SG 允許 DB SG 入站、結果 Web 連不到 DB（應該反過來） |
>
> **設計判準**：
> - **共通的、全 subnet 適用的規則** → 設在 subnet 層
> - **每台 VM 獨有的、職能限定的** → 設在 NIC 層
> - **應用層攻擊（SQLi、XSS、L7 DDoS）** → 設在邊界層 WAF

> **老師補充：AWS、Azure、GCP 三家結構性差異**
>
> 上面講的「三層架構」是**最大公約數的觀念框架**——但實際上每家 CSP 的網路安全模型是**不同設計哲學**。這也是為什麼跨雲、多雲管理時，網路規則沒辦法直接搬。
>
> | 比較項 | AWS | Azure | GCP |
> |---|---|---|---|
> | **網卡層** | Security Group（綁 ENI） | NSG 可綁 NIC | （沒有此層） |
> | **子網層** | Network ACL（stateless） | NSG 可綁 subnet | （沒有此層） |
> | **VPC 全域層** | （沒有獨立此層） | （沒有獨立此層） | **VPC Firewall Rules** |
> | **目標選擇** | SG 互相引用 | ASG 用 tag 群組化 | Network tags 或 service account |
> | **預設規則** | SG 入站 deny、出站 allow | 內建多條 default（複雜） | 隱含 deny 入站、allow 出站 |
> | **stateful?** | SG stateful、**NACL stateless** | NSG stateful | stateful |
> | **deny 規則** | SG 不支援、NACL 支援 | NSG 支援（用 priority） | 支援 |
>
> **根本設計差異**：
>
> - **AWS**：兩層獨立模型（SG 加 NACL）。**NACL stateless 是最大特色**——很多人忽略要開 ephemeral port（49152-65535）做 return traffic，被卡很久
> - **Azure**：單一 NSG 模型，但可掛在多層（NIC、subnet、或兩者）。用 priority 數字決定哪條規則先生效
> - **GCP**：**VPC 層級單一防火牆，沒有子網或網卡層的概念**。靠 network tags 或 service account 來「標記」哪些 VM 適用哪條規則——理念跟 AWS、Azure 完全不同
>
> **怎麼記**：
> - AWS = **兩層各管各的**（SG 為主、NACL 補強）
> - Azure = **一種 NSG、彈性掛**（NIC、subnet、或兩者）
> - GCP = **一個 VPC 防火牆、靠標籤指定對象**
>
> CCSP 考試本身 vendor-neutral 不會考細節差異——但**實務上跨雲架構或多雲管理時、這個差異是真痛點**，地端網管想用「同一份規則檔搬上三家雲」幾乎不可能。

#### 流量檢查 (Traffic Inspection)

**白話**：檢查網路流量「**裡面到底傳了什麼內容**」，看有沒有壞東西——對應地端的 IDS、IPS、NGFW、DLP 那層級在做的事。

**和 NSG 的差異**：

| 概念 | 看什麼 | 例子 |
|---|---|---|
| **NSG** | L3-L4：誰連誰、走哪個 port | 允許 1.2.3.4 連 443 |
| **流量檢查** | L7：放行的流量裡到底傳了什麼內容 | 抓 HTTP request 裡的 SQL injection、檔案上傳裡的惡意檔、外傳流量裡的客戶資料 |

NSG 把人放進門了，**門裡發生什麼事 NSG 不管**——流量檢查就是補這一塊。

**地端 vs 雲端做法**：

| 地端做法 | 雲端做法 |
|---|---|
| 機房邊界放實體 NGFW（Palo Alto、Fortinet），全部流量都過 | 沒有實體邊界，要靠**虛擬 NGFW 或雲原生服務** |
| SPAN port 把流量複製給 IDS 分析 | 改靠 VPC Flow Logs、CSP 提供的 telemetry |
| 客戶端裝企業 CA，防火牆做 TLS 攔截 | 雲端工作負載難以統一裝 cert |

**三家 CSP 對應工具**：

| CSP | 主要服務 |
|---|---|
| AWS | GuardDuty（log 分析路線）、AWS Network Firewall（inline NGFW） |
| Azure | Azure Firewall Premium、Defender for Cloud、Network Watcher |
| GCP | Cloud IDS、VPC Flow Logs |

**三個關鍵挑戰**：

**① 端到端加密看不到內容**
TLS 加密後封包裡只有亂數密文，傳統 IDS 想看「這個 HTTP request 有沒有 SQLi」完全看不到。唯一解法是在 **TLS 終止點**才看得到明文：
- ALB、Application Gateway 終止 TLS → 在這裡分析明文 → 重新加密送往後端（**TLS termination**）
- 主動攔截需 client 信任企業 CA，雲端工作負載做不到

**② TLS 1.3 加 PFS 讓問題更嚴重**
舊版 TLS 拿到 server 私鑰，可解密**過去**錄下的流量（事後鑑識用）。
TLS 1.3 加上 **Perfect Forward Secrecy（前向安全）**：每個 session 用一次性 ephemeral key——拿到 server 私鑰**也解不開過去的流量**。
對防守方衝擊：原本可「先錄下來、出事再回頭分析」，現在只能**即時處理**，過了就永遠看不到。鑑識調查能力大幅縮水。

**③ Sensor 要放哪**
地端機房進出口放一台就好。雲端流量散在多個 VPC、AZ、region，**東西向（VM 對 VM）流量可能根本不出 hypervisor**。三種放法各有取捨：

| 放法 | 看到什麼 | 缺點 |
|---|---|---|
| 邊界放 | 南北向（外進外出） | 看不到內部橫向移動（lateral movement） |
| 每個 subnet 放 | 東西向也看到 | 成本爆炸 |
| 雲原生服務（GuardDuty 等） | 靠 log 而不是封包 | 看到的東西不同（沒有原始 packet） |

> **老師補充：TLS termination 的責任議題**
>
> 一旦在某個元件（ALB、API Gateway、WAF）終止 TLS，那台元件就**看到了原始明文**——包括客戶身份證、卡號、所有 PII。這帶出實務問題：
>
> - **誰能管這台元件？** 它的 IAM、log、設定變更全都進入 PII 處理範圍
> - **它的 log 算不算個資？** 如果 log 記了 request body 沒過濾，就是個資外洩風險
> - **跨雲架構下要 terminate 幾次？** 每多一次就多一個明文暴露點
>
> 金管會「金融機構作業委託他人處理內部作業制度及程序辦法」（委外辦法）要求金融業掌握敏感資料的處理位置——TLS termination 點就是必須清查的關鍵位置之一。典型銀行多雲架構：客戶連 Cloudflare → Cloudflare 終止 TLS → 重新加密連到 AWS ALB → ALB 又終止 TLS → 連到後端。**整條路上有兩個明文暴露點**，兩個都要列入合規範圍。

#### 地理圍欄 (Geofencing)
將數位使用者與其實際實體位置關聯的技術。

**用途**：
- 允許或拒絕對雲端資源的存取
- 確定連接者的潛在威脅級別
- 促進可信存取

**信心程度考量**：
| 方法 | 信心程度 |
|------|----------|
| IP 位址地理定位 | 低（容易被 VPN 欺騙） |
| 企業控制的行動設備 + MDM + GPS | 高 |

---

### 虛擬化安全

虛擬化是雲端的核心技術，其安全性至關重要。

#### Hypervisor 安全
Hypervisor 是與底層基礎設施介面並向客戶作業系統呈現虛擬化組件的關鍵組件。

**重要性**：
- 是公有雲上執行租戶間分離的最重要工具
- 如果被入侵，可能存取 CSP 通常能存取的一切
- 可能存取其他租戶的資料或系統

**責任**：通常由 CSP 負責管理、維護和監控

#### 容器安全 (Container Security)
容器化平台編排和執行容器，其安全至關重要。

**特點**：
- 容器共享相同的作業系統或平台實例
- 平台的入侵可能是災難性的
- 容器化平台將容器內容與外部隔離

**責任**：取決於雲端服務產品，可能是 CSP 或客戶責任

#### 短期運算 (Ephemeral Computing)
虛擬系統或容器化應用程式設計為不需要在操作之間維護資訊或狀態。

**安全優勢**：
- 運行時間短，攻擊者時間窗口有限
- 不保留狀態，減少持久威脅的風險
- 可以快速建立和刪除

**挑戰**：
- 需要外部日誌記錄和監控
- 保留個別副本操作資訊可能有挑戰

#### 無伺服器技術 (Serverless Technology)
伺服器從使用者中被抽象出來，組織不需要處理伺服器相關的開銷任務。

**特點**：
- 使用預定義的協定或 API 向平台發出請求
- 平台決定如何提供資源
- 通常採用無狀態短期、微服務架構

**常見形式**：功能即服務 (FaaS)

#### 隔離 (Isolation)
在多租戶雲端環境中，確保不同租戶的工作負載彼此隔離是虛擬化安全的關鍵目標。

**隔離層級**：
- **硬體隔離**：使用專用主機（Dedicated Host），完全避免共享硬體
- **Hypervisor 隔離**：依賴 Hypervisor 提供的記憶體和 CPU 隔離機制
- **容器隔離**：透過 namespace 和 cgroups 實現程序層級隔離（隔離性較 VM 弱）
- **網路隔離**：透過 VLAN、VPC、安全群組實現網路層面分離

**安全考量**：
- 隔離失敗可能導致旁路攻擊（Side-channel Attack）或跨租戶資料洩漏
- 不同隔離層級對應不同的安全保證程度和成本

---

### 常見雲端威脅

雲端繼承了其組件部分的風險，但某些威脅在雲端環境中可能更嚴重。

| 威脅 | 說明 | 雲端特有考量 |
|------|------|--------------|
| **資料洩露** | 敏感資訊被不當披露 | 雲端的連接性增加了潛在風險 |
| **配置不當** | 資源未正確配置 | 雲端中配置不當更容易暴露，後果更嚴重 |
| **介面攻擊** | 對暴露介面的注入或操縱攻擊 | API 和 Web 介面是主要攻擊面 |
| **IAM 失敗** | 憑證丟失或配置不當 | 影響人類操作和非人實體 IAM |
| **應用程式缺陷** | 軟體缺陷 | 雲端中可能更容易遭受外部攻擊 |
| **密碼學不當使用** | 密碼學的錯誤使用、配置或實施 | 雲端中可能需要不同方式保護資料 |

---

### 安全衛生

安全營運是組織為維護系統安全隨時間進行的活動。

#### 修補 (Patching)
持續更新系統和軟體以修復已知漏洞。

**雲端中的考量**：
- 必須分析確切的責任分配
- 確保 CSP 和客戶都沒有維護缺口

#### 基準化 (Baselining)
建立系統的安全配置基準，作為比較和監控的標準。

**目的**：
- 定義「正常」的系統狀態
- 偵測未經授權的配置變更
- 確保系統符合安全政策

**實施方式**：
- 建立標準配置模板
- 持續監控配置偏差
- 自動化合規檢查

#### 不可變架構 (Immutable Architecture)
部署後不修改系統，需要變更時直接替換為全新的預配置映像。

**核心概念**：
- 伺服器一旦部署就不再進行修補或配置變更
- 需要更新時，從新的「黃金映像」(Golden Image) 重新部署
- 消除組態漂移 (Configuration Drift) 問題
- 與 Infrastructure as Code \(IaC\) 和 CI/CD 管道緊密結合

**安全優勢**：
- 降低未經授權變更的風險
- 確保每次部署都是已知良好的狀態
- 簡化事件回應（直接重新部署乾淨映像）

#### 強化 (Hardening)
透過系統性地減少攻擊面來提高安全性。

**常見措施**：
- 移除不必要的服務、協定和功能
- 關閉未使用的連接埠
- 變更預設帳戶和密碼
- 應用最小權限原則
- 參考 CIS Benchmarks 等業界標準配置指南

#### 典型安全衛生活動

| 活動 | 說明 |
|------|------|
| 關鍵資產識別和追蹤 | 包括資料資產 |
| 資產配置管理 | 維護配置基準 |
| 修補和漏洞管理 | 持續更新和修復 |
| 日誌記錄和監控 | 追蹤所有活動 |
| 帳戶管理 | 包括特權帳戶管理 |
| 事件管理和回應 | 偵測和處理安全事件 |
| 威脅狩獵和分析 | 主動尋找威脅 |
| 安全測試和滲透測試 | 驗證控制有效性 |
| 備份和恢復 | 確保資料可恢復 |
| 業務連續性和災難恢復 | 確保營運持續性 |

---

## 1.4 了解安全雲端運算的設計原則

### 雲端安全資料生命週期

資料在雲端中具有生命週期，了解各階段有助於實施適當的安全控制。

建立 (Create) → 儲存 (Store) → 使用 (Use) → 分享 (Share) → 歸檔 (Archive) → 銷毀 (Destroy)
                    ↑                              ↓
                    ←──────────────────────────────
                        （資料可能在各階段間來回）

**各階段的安全考量**：
| 階段 | 安全考量 |
|------|----------|
| **建立** | 分類、標記、初始權限設定 |
| **儲存** | 加密、存取控制、位置控制 |
| **使用** | 使用中的資料保護、存取記錄 |
| **分享** | 傳輸加密、權限管理、DRM |
| **歸檔** | 長期儲存安全、保留政策 |
| **銷毀** | 安全刪除、加密抹除 |

---

### 雲端型業務持續性 (BC) 和災難復原 (DR) 規劃

所有主要 CSP 都提供災難復原即服務 (DRaaS)。設計 BCDR 策略時，需考慮三種主要情境：

#### 情境一：本地環境，雲端作為 BCDR

[總部] ─── [本地資料中心]
              ↓ （災難發生時）
        [雲端資料中心]（備援）

**考量**：
- 實體機器工作負載可能需要轉換為虛擬環境
- 檢視所需資源可用的速度

#### 情境二：雲端用戶，主要提供者 BCDR

[總部] ─── [CSP 資料中心 A]
              ↓ （區域故障時）
        [CSP 資料中心 B]（同一 CSP 的另一區域）

**考量**：
- 依賴現有 CSP 的資源和能力
- 需評估負載平衡功能和可用頻寬

#### 情境三：雲端用戶，替代提供者 BCDR

[總部] ─── [CSP A 資料中心]
              ↓ （CSP 完全故障時）
        [CSP B 資料中心]（不同的 CSP）

**考量**：
- 解決 CSP 完全故障的風險
- 資料可攜性和互通性處於較高風險
- 遷移到新提供者的速度是主要考量
- SaaS 故障可能影響業務使用者習慣的功能

---

### 復原和復原

#### 關鍵指標

| 指標 | 說明 |
|------|------|
| **RPO** | 可接受的資料損失量（時間） |
| **RTO** | 恢復服務的目標時間 |

#### 資料複製 (Data Replication)
在不同位置維護所需資料的最新副本。

| 層級 | 說明 | 可緩解的風險 |
|------|------|--------------|
| **區塊層級** | 最底層的複製 | 實體資料損失 |
| **檔案層級** | 檔案同步 | 檔案損壞或刪除 |
| **資料庫層級** | 資料庫鏡像 | 資料庫故障 |

> ⚠️ **注意**：區塊層級複製可防止實體資料損失，但不能防止資料庫損壞。

#### 復原 (Restoration)
災難復原以恢復正常結束。

**選項**：
- 返回原始提供者或內部基礎設施
- DR 提供者成為「新常態」

**最佳實踐**：
- 記錄經驗教訓
- 清理不再需要的資源（包括敏感資料）
- 完整或部分地演練 BCDR 計畫

---

> 💡 **核心心法：問題驅動 vs 技術驅動 — 不要為了上雲而上雲**
>
> CCSK v5 開場（Domain 1）就點出：「**雲端的好處只有在正確理解、採用、且架構對齊雲端特性時才會實現**」。換句話說 — **不是上雲就會自動省錢、安全、有彈性**。
>
> **核心問題**：你想解決什麼問題？
>
> | 業務型態 | 適合上雲嗎？ | 例子 |
> |---------|---------|------|
> | **流量爆量、需求不固定** | ✅ 高度適合 | 台鐵春節訂票（瞬間幾萬人擠進來、訂完就閒置）、電商雙 11、新創產品快速擴展 |
> | **流量穩定、需求固定** | ⚠️ 不一定值得 | 傳統製造業 ERP、固定員工數內部系統、長期穩定的業務 |
> | **資料極度敏感、法規嚴格** | ❌ 仔細評估 | 軍方系統、央行核心、特定醫療資料 |
>
> **看不見的成本**（很多企業沒算到）：
> - **資料安全**：上雲後資料外洩風險不會消失、只是責任邊界變了
> - **法律遵從**：跨境資料、GDPR、金管會委外辦法
> - **雲端人才**：要找會 AWS、Azure、雲端架構的人、薪水不便宜
> - **持續訂閱**：地端是 capex 一次性、雲端是 opex 永遠在燒
> - **複雜度**：監控、計費、跨服務整合、要學很多新東西
>
> **CCSP 視角 — 業務驅動的決策框架**：
>
> 1. **先問**：我的業務需求是什麼？流量型態？合規要求？
> 2. **再問**：雲端的特性能解決這些問題嗎？（彈性、按需付費、全球部署）
> 3. **最後問**：上雲的隱藏成本能接受嗎？
>
> 這個觀念跟「**多雲不是萬靈丹**」「**雲端預設最貴**」一脈相承 — **雲端是工具、不是目的**。為了上雲而上雲、就像為了 AI 而 AI、結果通常不好。
>
> **CISSP、CCSP 老手的金句**：「**知道為什麼做、比知道怎麼做重要得多**」。

---

### 業務衝擊分析

BIA 試圖預測或計算任何對業務功能中斷的後果。

**重要性**：
- 將業務功能映射到中斷的潛在影響
- 為機密性、完整性和可用性設定保護需求
- 映射雲端服務中斷如何影響關鍵業務功能

### 成本效益分析

在選擇雲端服務時，應始終執行 CBA 以確保選擇符合組織最佳利益。

**CBA 方法要求**：
- 系統化、可重複和一致
- 比較兩種或多種方法的優缺點
- 盡可能量化實際效益

> 💡 **實務陷阱：雲端預設值都選最貴的**
>
> Azure 課堂上老師笑著說：「**我們以前裝軟體都按下一步下一步、雲端不能這樣**」 — 因為 CSP 的預設值通常選最貴的：
>
> | 設定項 | 預設值（最貴） | 多數場景夠用的選擇 |
> |-------|------------|---------------|
> | **儲存類型** | SSD（高效能） | 冷資料用 HDD、檔案儲存用 Cool Tier |
> | **備份** | 自動備份開啟 | 測試環境根本不需要備份 |
> | **冗餘等級** | GRS（地理冗餘） | 測試環境 LRS（本地冗餘）就夠 |
> | **執行個體規格** | 大規格 VM | 小流量服務用最小規格、流量大再 Auto Scaling |
> | **公網 IP** | 預設配給 | 內部服務用私有 IP 即可 |
>
> 一直「下一步下一步」建完、月底帳單嚇死人。
>
> **這就是為什麼需要「雲端顧問」**（呼應 1.1 節的 **CSN:Developer** 子角色）：
> - **配置最佳化**：選對規格、關掉不必要的選項、善用 Reserved Instance 折扣
> - **架構設計**：用 Auto Scaling 取代固定大規格、Spot Instance 跑非關鍵工作負載
> - **持續審視**：定期檢查閒置資源、移除過時 VM、評估服務替換
>
> **CCSP 視角**：CBA 不是只比「**雲端 vs 地端**」、還要看「**雲端內怎麼配置最省**」。同樣的服務、配置不同、月費可以差 5-10 倍。
>
> **跟前面「多雲不一定是好答案」呼應** — 很多企業上雲沒省錢、不是雲端不好、是**不會用**。雲端的彈性是雙面刃：用得對省錢、用不對更燒錢。

### 功能性安全需求

#### 可攜性 (Portability)
使雲端服務客戶能夠在獨立服務和 CSP 之間移動其資料或應用程式。

**三個面向**：
| 面向 | 說明 |
|------|------|
| **語法** | 使用目標系統可解碼的格式傳輸資料（如 XML、OVF） |
| **語意** | 目標在主題領域的上下文中理解資料模型 |
| **政策** | 遵守政府法律、法規和組織命令 |

#### 互通性 (Interoperability)
在獨立服務和 CSP 之間提供無縫的服務消費和管理。

**五個面向**：
| 面向 | 說明 |
|------|------|
| **政策** | 遵守法律、法規和組織命令進行互通 |
| **行為** | 交換資訊的使用結果符合預期 |
| **傳輸** | 通訊的通用性（如 HTTP/S、訊息佇列標準） |
| **語法** | 理解其他系統交換資訊的結構（如 JSON、XML） |
| **語意資料** | 在主題領域上下文中理解資料模型的含義 |

#### 供應商鎖定
過度依賴單一供應商的風險。

**評估考量**：
- 整體功能
- 總成本的真實估算
- 所選方法的風險評估

---

### 不同雲端類別的安全考量與責任

#### 安全考量一覽

| 考量 | 說明 | 影響的服務模型 |
|------|------|----------------|
| **虛擬機器攻擊** | VM 容易受到傳統攻擊，被入侵的 VM 可能攻擊同主機的其他 VM | IaaS, PaaS |
| **虛擬網路** | 虛擬網路可能被不當配置或實施 | IaaS, PaaS |
| **Hypervisor 攻擊** | 入侵 hypervisor 可控制 VM 和主機 | 所有 |
| **軟體和平台維護** | 必須分析確切的責任分配以避免維護缺口 | 所有 |
| **DoS 攻擊** | 可針對內部組件或存取 | 所有 |
| **多租戶** | 共享可能導致資訊洩漏和增加攻擊面 | 所有 |
| **工作負載複雜性** | 伺服器聚合增加管理複雜性 | IaaS, PaaS |
| **資料駐留控制損失** | 用戶不知道資料和服務的位置 | 所有 |
| **IAM** | 可能需要在多個層級正確實施 | 所有 |
| **資料存取政策** | 必須在所有相關技術層級實施 | 所有 |

---

### 雲端設計模式

設計模式是實施某些能力的標準化或「已知良好」的方式，在雲端設計中特別有價值。

#### SANS 安全原則
SANS 提出的核心安全設計原則：

| 原則 | 說明 |
|------|------|
| **最小權限** | 只給予完成工作所需的最低權限 |
| **縱深防禦** | 多層防護，一層失效還有其他層 |
| **職責分離** | 關鍵功能由不同人員執行 |
| **失敗安全** | 系統失敗時應進入安全狀態 |
| **開放設計** | 安全性不應依賴於設計的保密性 |
| **完整調解** | 每次存取都應驗證權限 |
| **最小共同機制** | 減少共享機制以限制攻擊面 |
| **心理可接受性** | 安全機制應易於使用 |

#### 良好架構框架 (Well-Architected Framework)
每個主要 CSP 都有自己的良好架構文件。

| 原則 | 說明 |
|------|------|
| **運營卓越** | 系統的運行和監控，自動化變更、定義標準、回應事件 |
| **安全** | 管理資料的機密性和完整性，用戶權限管理、安全事件偵測 |
| **可靠性** | 工作負載的可用性和從故障中恢復，多可用區域設計 |
| **效能最佳化** | 選擇適合工作負載的資源類型，監控利用率 |
| **成本最佳化** | 避免不必要的成本，選擇正確類型和數量的資源 |
| **永續性** | 綠色 IT，減少碳足跡 |

#### CSA 企業架構 (CSA Enterprise Architecture)
雲端安全聯盟提供的企業架構指南，協助組織設計和實施安全的雲端環境。

**主要元素**：
- 治理和風險管理框架
- 雲端安全控制
- 資料安全和隱私保護
- 合規和稽核要求
- 業務連續性和災難恢復

#### 安全設計 (Secure by Design)
從系統架構的最初階段就將安全內建到設計中，而非事後補救。

**核心原則**：
- 安全不是附加功能，而是架構的基本屬性
- 預設安全配置 (Secure Defaults)：系統出廠即為安全狀態
- 減少攻擊面：只暴露必要的介面和服務
- 與 DevSecOps 理念一致，在設計階段就考慮威脅模型

---

### DevOps 安全

#### DevSecOps
彌合安全和 DevOps 之間的差距，讓安全成為開發流程的一部分。

**核心理念**：
- 安全應保持聚焦於最小化企業風險
- 同時允許開發以 DevOps 速度交付更安全的程式碼

**每個階段的安全**：

規劃(Plan) → 編碼(Code) → 建置(Build) → 測試(Test) → 發布(Release) → 部署(Deploy) → 營運(Operate) → 監控(Monitor)
  ↑                                                                                                         ↓
  └─────────────────────────────────── 安全 (SECURITY) ──────────────────────────────────────────────────────┘

---

## 1.5 評估雲端服務提供者

### 根據標準進行驗證

雲端客戶有責任確定雲端服務必須滿足哪些要求，並確保提供者滿足這些要求。

**驗證方式**：
- 要求 CSP 提供獨立第三方稽核報告（如 SOC 2 Type 2）
- 確認 CSP 是否持有相關認證（如 ISO/IEC 27001、ISO/IEC 27017、CSA STAR）
- 審查 CSP 的合規聲明是否涵蓋客戶的法規要求（如 PCI DSS、HIPAA）
- 評估 CSP 的安全政策、事件回應程序和資料處理實務

---

### 系統、子系統產品認證

#### 共同準則 (Common Criteria)
評估資訊安全產品的國際指南和規範集 (ISO/IEC 15408)。

**四個關鍵組成部分**：

| 組成部分 | 說明 |
|----------|------|
| **保護剖繪** | 定義特定類型產品（如防火牆、IDS）的標準安全要求集 |
| **評估目標** | 供應商產品由第三方評估實驗室進行檢驗 |
| **安全目標** | 供應商提供的產品和安全功能概述、威脅評估、自我評估 |
| **評估保證級別** | 定義產品測試的徹底程度 |

**EAL 級別**：
| 級別 | 名稱 | 說明 |
|------|------|------|
| EAL1 | 功能測試 | 最低級別，基本功能驗證 |
| EAL2 | 結構測試 | 設計文件審查 |
| EAL3 | 方法性測試和檢查 | 開發環境審查 |
| EAL4 | 方法性設計、測試和審查 | 商業產品常見級別 |
| EAL5 | 半正式設計和測試 | 需要專業安全工程 |
| EAL6 | 半正式驗證設計和測試 | 高度敏感環境 |
| EAL7 | 正式驗證設計和測試 | 最高級別，極端安全需求 |

> ⚠️ **注意**：EAL 級別越高表示測試越徹底，但不一定表示產品更安全。

**共同準則的限制**：
- 僅查看產品認證，不包括管理或業務流程
- 測試可能需要超過一年
- 過程昂貴
- 產品可能已在測試期間改進

#### 聯邦資訊處理標準 (FIPS 140-2/3)
驗證密碼模組是否正確構建的產品認證計畫。

**NIST 支援的計畫**：
| 計畫 | 說明 |
|------|------|
| **CAVP** | 密碼演算法驗證計畫 - 驗證演算法是否正確實施 |
| **CMVP** | 密碼模組驗證計畫 - 驗證模組是否正確實施 |

**安全級別**：
| 級別 | 說明 |
|------|------|
| Level 1 | 基本安全要求 |
| Level 2 | 防篡改證據 |
| Level 3 | 防止物理存取 |
| Level 4 | 完整的物理安全封包 |

**過渡時程**：
- FIPS 140-2 證書自 2026 年 9 月 22 日起移至 Historical List（不再可用於新採購之合規證明，已部署模組仍可繼續運作）
- FIPS 140-3 已成為現行標準

---

## 1.6 理解人工智慧與機器學習

> ⚡ **新版大綱新增章節** (2026/8/1 生效)

AI/ML 正深刻改變雲端安全的運作方式，同時也帶來全新的風險面向。

### 雲端威脅偵測與分析

AI/ML 在雲端安全營運中的應用，大幅提升威脅偵測的速度和準確性。

**主要應用場景**：
- **異常行為偵測**：利用 ML 建立使用者和實體行為基線 (UEBA)，偵測偏離正常模式的活動
- **惡意軟體分析**：透過模式辨識自動分類和分析新型惡意軟體
- **日誌分析**：處理海量日誌資料，自動識別潛在威脅指標 (IoC)
- **預測性分析**：根據歷史資料預測可能的攻擊途徑

### 資料來源驗證與確認

AI/ML 模型的有效性取決於訓練資料的品質和可信度。

**關鍵考量**：
- **資料品質**：「垃圾進，垃圾出」— 低品質或有偏差的訓練資料會導致不可靠的結果
- **資料污染攻擊**：攻擊者故意注入惡意資料以操縱模型行為
- **模型驗證**：需要定期驗證模型的準確性和公正性
- **資料溯源**：追蹤資料的來源和處理歷程，確保資料完整性

### 安全編排、自動化與回應

SOAR 整合 AI/ML 能力，實現安全事件的自動化處理。

**三大支柱**：
| 支柱 | 說明 |
|------|------|
| **安全編排** | 整合不同安全工具（SIEM、防火牆、EDR）的資料和工作流程 |
| **自動化** | 對已知威脅類型自動執行預定義的回應動作（如封鎖 IP、隔離主機） |
| **回應** | 提供 Playbook 導向的事件回應流程，結合人工判斷和自動化動作 |

**與 SIEM 的關係**：
- SIEM 負責偵測和告警
- SOAR 負責接收告警後的自動化處理和回應
- 兩者結合可大幅縮短 MTTR (平均修復時間)

### 倫理議題

AI/ML 在安全領域的應用必須考慮倫理問題。

**主要議題**：
- **偏差與公平性**：模型可能對特定群體產生偏差（如某些行為模式被不公平地標記為可疑）
- **透明度與可解釋性**：安全決策（如封鎖帳戶）需要能被解釋和審計
- **隱私影響**：行為分析可能涉及過度監控員工或使用者
- **責任歸屬**：當 AI 做出錯誤的安全決策時，責任如何分配

### 法規要求

各國和各組織對 AI/ML 的使用逐漸建立法規框架。

**重要法規趨勢**：
- **歐盟 AI Act**：根據風險等級對 AI 系統進行分類和監管
- **演算法透明度要求**：要求組織能解釋 AI 決策的依據
- **資料保護法規的延伸**：GDPR 中的自動化決策權利（第 22 條）適用於 AI 驅動的安全決策
- **行業特定要求**：金融、醫療等受監管行業對 AI 使用有額外的合規義務

---

# Domain 2：雲端資料安全 (Cloud Data Security)

> **考試權重**：20%
> **核心重點**：資料生命週期、儲存架構、加密與金鑰管理、資料探索與分類、IRM、資料保留與歸檔、稽核追蹤、以及 AI/ML 資料保護。

---

## 2.1 描述雲端資料概念

### 雲端資料生命週期

理解資料生命週期是選擇正確安全控制措施的基礎。雖然模型是線性的，但資料可以在階段間跳轉。

**CSUSAD 模型**：

1. **建立**：數位內容被產生、修改或從外部匯入。
- *關鍵活動*：分類 (Classification)、標記 (Tagging)。這是分類的最佳時機。
2. **儲存**：資料被放入儲存庫（如資料庫、物件儲存）。
- *關鍵控制*：加密、存取控制、備份。
3. **使用**：資料被檢視、處理或修改。這是資料最脆弱的階段。
- *關鍵控制*：DLP、數位權限管理 (DRM)、存取監控。
4. **分享**：資料被提供給他人存取（內部或外部）。
- *關鍵控制*：DLP、加密傳輸、限制分享權限。
5. **歸檔**：長期儲存不再頻繁使用的資料。
- *關鍵控制*：確保格式長期可讀、法律保留 (Legal Hold)、完整性保護。
6. **銷毀**：從 CSP 處永久移除資料。
- *關鍵技術*：加密抹除 (Crypto-shredding) 是雲端中常見且可驗證的方法之一。
- *配套措施*：仍須仰賴 CSP 的銷毀程序（覆寫、實體銷毀、副本與快照清除）與合約／SLA 中的銷毀條款，並要求銷毀證明 (Certificate of Destruction)。
### 資料分散

資料分散是將資料儲存在多個位置的技術。不同 CSP 對此術語的實作可能不同，常見有三種：

- **複製 (Replication)**：在不同位置儲存完整的資料副本，每個位置都有完整資料。主要用於提升可用性與災難復原。
- **抹除編碼 (Erasure Coding)**：將原始資料分解成數個區塊並產生額外的編碼區塊，類似 RAID 但更複雜。**關鍵概念**：只要取得「最小數量子集」的區塊（少於全部）即可重建原始資料；若可用區塊低於該門檻則無法恢復。例如 64 位元資料可分成 6 個區塊，只要取得任 4 個即可恢復。
- **位元分割 (Bit Splitting)**：將資料加密後分割成碎片，分散儲存於不同位置或不同 CSP，降低單一 CSP 被入侵時的資料外洩風險。

> 跨國／跨管轄區的資料分散會引入新的風險：CCSP 必須了解所用的分散技術是否會讓單一位置上的資料可獨立讀取，或必須結合多個位置的區塊才能還原，並評估是否有額外的加密保護。

### 資料流

資料流指資料在實體或邏輯位置之間移動的任何情況。位置可以是系統、服務或元件。

**資料流圖 (Data Flow Diagram, DFD)**：用於描繪資料如何在位置之間移動，並可標註以下資訊：
- 移動時所應用的安全控制措施
- 實體或邏輯傳輸機制（如 TCP/IP 網路、虛擬網路、網際網路）
- 使用的協定（如 HTTPS）或保護措施（如加密、TLS）

**三種資料狀態的對應控制**：
- **靜態 (At Rest)**：儲存在實體媒介上 — 加密、存取控制、備份
- **傳輸中 (In Motion / Transit)**：在網路上移動 — TLS、VPN、安全通道
- **使用中 (In Use)**：被應用程式或人員處理 — DLP、IAM、機密計算 (TEE)

**為何重要**：不同的資料流面臨不同類型的威脅，因此需要不同的控制措施。同一份資料在生命週期中的不同階段，可能跨越多種狀態與位置，每種轉換點都需評估相應的保護措施。

---

## 2.2 設計與實作雲端資料儲存架構

### 儲存類型

不同的雲端服務模型對應不同的儲存控制層級。

| 服務模型 | 儲存類型 | 常見形式 | 加密控制 |
|----------|----------|----------|----------|
| **IaaS** | 磁碟區儲存 (Volume Storage) | 虛擬硬碟、區塊儲存 (Block Storage) | 客戶可控制 OS 層級加密、檔案系統加密 |
| **PaaS** | 結構化、非結構化 | 資料庫 (DB)、大數據平台 | 客戶控制較少，依賴 CSP 提供的加密功能 (TDE 等) |
| **SaaS** | 資訊儲存 | 應用程式資料、檔案上傳 | 客戶控制最少，依賴 CSP 設定或代理加密 (Proxy) |

- **物件儲存**：透過 API 存取，包含資料 (Data) 和元資料 (Metadata)。通常用於儲存非結構化資料（如圖片、備份）。適合大規模資料存放，具備高可用性和持久性。
- **磁碟區儲存**：類似傳統磁碟的區塊儲存，可掛載到虛擬機器。提供低延遲的隨機讀寫能力，適合資料庫和需要高效能 I/O 的應用。
- **臨時儲存**：隨執行個體 (Instance) 啟動而建立，關閉後消失。適合暫存資料、Swap 檔。
- **原始儲存**：未經格式化的區塊級儲存，由客戶自行管理檔案系統。
- **長期儲存**：用於資料歸檔和長期保存，通常存取速度較慢但成本較低（如 Amazon S3 Glacier）。

### 雲端儲存威脅

雲端儲存面臨的主要威脅有九種：

1. **未經授權的使用 (Unauthorized Usage)**：儲存被操縱成未經授權的用途，例如帳戶劫持或上傳非法內容。多租戶特性使追蹤更困難。
2. **未經授權的存取 (Unauthorized Access)**：駭客攻擊、多租戶環境下的權限配置錯誤、或 CSP 內部員工未經授權存取資料。
3. **因法規不合規而產生的責任**：並非所有雲端服務都啟用所有相關控制，可能導致 PCI DSS、HIPAA、GDPR 等合規違規。
4. **阻斷服務 (DoS / DDoS) 攻擊**：影響資料可用性。沒有資料，任何執行個體都無法啟動。
5. **資料損壞、修改和銷毀**：人為錯誤、硬體或軟體故障、火災水災等災害、或惡意攻擊。可能影響部分或整個儲存陣列。
6. **資料外洩 / 洩露**：威脅來自外部或具儲存存取權限的 CSP 員工。雲端中資料被複製和移動的頻率高，洩漏風險增加。
7. **媒體竊取或意外遺失**：通常與可攜式儲存相關，但決定允許哪些裝置存取雲端資料時也是考量。例如可限制行動裝置在本地儲存資料。
8. **惡意軟體攻擊或引入**：雲端儲存可能成為惡意軟體散佈點 — 受感染裝置會將惡意軟體複製到雲端儲存，再透過共享傳播給其他使用者。
9. **使用終止後的不當處理或清理**：CSP 管理的硬體在服務生命週期結束時的處置方式。客戶必須了解 CSP 的媒體清理流程。

---

## 2.3 設計與應用資料安全技術和策略

### 1. 加密與金鑰管理

#### A. 加密技術 (Encryption Technologies)
選擇正確的工具做正確的事。

| 類型 | 關鍵字、特性 | 適用場景 | 缺點 |
| :--- | :--- | :--- | :--- |
| **對稱加密** (Symmetric) | **單一金鑰**、速度快、AES-256。 | **大量資料**、硬碟加密、資料庫加密。 | **金鑰分發**困難 (Key Distribution)。 |
| **非對稱加密** (Asymmetric) | **公私鑰對** (Public/Private Key pair)。 | **金鑰交換** (Key Exchange)、**數位簽章** (Digital Signatures)。 | 速度慢，不適合加密大檔。 |
| **同態加密** (Homomorphic) | **不需解密**即可運算。 | 雲端資料處理的聖杯 (Data in Use 保護)。 | 效能極差 (目前主要為理論、實驗)。 |

#### B. 金鑰管理系統 (KMS)
遵循 **Kerckhoffs's Principle** (系統公開，唯金鑰保密)。

##### KMS 部署模式 (必考情境題) 🔥
| 模式 | 誰持有金鑰 (Custody) | 誰做運算 | 優缺點 |
| :--- | :--- | :--- | :--- |
| **CSP-Managed** | CSP | CSP | 方便、便宜。**信任風險高** (CSP 可解密資料)。 |
| **Client-Managed** | 客戶 (上傳給 CSP) | CSP | **平衡之選**。客戶生成，CSP 只能用不能匯出。 |
| **External** | 客戶 (地端 HSM) | 客戶 | **安全性最高**。金鑰從不離開自家。**功能受限** (無法搜尋、索引)。 |

##### 金鑰生命週期
1. **生成** (Generation)
2. **分發** (Distribution) - 最脆弱環節
3. **儲存** (Storage)
4. **使用** (Usage)
5. **輪換** (Rotation) - 限制外洩影響 (Crypto-period)
6. **撤銷** (Revocation)
7. **銷毀** (Destruction) - **加密抹除**

---

### 2. 雜湊
- **定義**：單向加密。使用數學函數從可變長度輸入產生固定長度輸出（雜湊值／訊息摘要）。**不需要金鑰**。
- **核心特性**：
- **確定性**：相同輸入永遠產生相同輸出
- **單向性 (Preimage Resistance)**：由雜湊值反推原始輸入在計算上不可行
- **抗第二原像 (Second Preimage Resistance)**：給定輸入 m1，找出 m2 ≠ m1 使 H(m1)=H(m2) 在計算上不可行
- **抗碰撞 (Collision Resistance)**：找出任意兩個不同輸入產生相同雜湊值在計算上不可行
- **雪崩效應 (Avalanche Effect)**：輸入改一個位元，輸出完全不同
- **演算法**：SHA-256 (安全), MD5/SHA-1 (不安全)。

**主要應用**：
- **資料完整性驗證**：下載檔案後比對雜湊值，確認傳輸過程中未被竄改
- **數位簽章基礎**：簽章前先對訊息雜湊
- **密碼儲存**：儲存密碼的雜湊值而非明文
- **鑑識用途**：製作證據映像後計算雜湊值，確保證據未被篡改

---

### 3. 數位簽章 (Digital Signatures)

提供「手寫簽名等同」效力給電子交易。**同時提供四種保證**：
- **真實性 (Authenticity)**：訊息確實來自聲稱發送者
- **完整性 (Integrity)**：訊息未被更改
- **不可否認性 (Non-repudiation)**：發送者無法否認發送過
- **責任性 (Accountability)**：行為可追溯到特定身分

**運作機制**：
1. 對原始訊息產生雜湊值（訊息摘要）
2. **以發送者私鑰對訊息摘要進行簽署運算** → 產生數位簽章（注意：RSA 簽章本質為加密摘要，但 ECDSA／EdDSA 不使用「加密」運算，故統稱為「簽署」較精確）
3. 將簽章附加到原訊息一同傳送
4. 接收者以發送者公鑰執行驗證運算（RSA 為解密、ECDSA/EdDSA 為驗章）
5. 接收者本地對訊息計算雜湊值
6. 比對兩個雜湊值，相同則驗證通過

> **重要**：數位簽章 **只保護真實性、完整性、不可否認性**，**不提供機密性**。需要機密性時必須額外加密訊息本身。

---

### 4. 資料遮罩
- **目的**：在**非生產環境** (開發、測試) 保護敏感資料。
- **靜態遮罩**：複製資料庫時進行脫敏 (產生副本)。
- **動態遮罩**：查詢時即時遮蔽 (如 `****-1234`)，資料庫內仍是明文。

---

### 5. 權杖化
- **定義**：用無意義的亂碼 (**Token**) 替換敏感資料 (如信用卡號)。
- **關鍵特性**：**無數學關聯** (不像加密可被破解)。
- **用途**：大幅降低 **PCI DSS** 合規範圍 (Scope Reduction)。
- **架構**：真實資料鎖在 **Token Vault** (權杖庫)。

---

### 6. 資料外洩防護
監控並阻擋資料流出。需對應資料的三種狀態：

| 狀態 | 部署位置 | 範例 |
| :--- | :--- | :--- |
| **傳輸中** | 網路閘道 (Gateway) | 阻擋上傳信用卡號到個人 Gmail (HTTP/SMTP)。 |
| **靜態** | 儲存掃描 (Discovery) | 掃描 S3 Bucket 找出權限過寬的敏感檔案。 |
| **使用中** | 端點代理 (Endpoint Agent) | 禁止複製貼上 (Clipboard)、禁止存入 USB。 |

---

### 7. 資料去識別化
- **匿名化 (Anonymization)**：移除所有可識別連結，使資料**真正不可逆**地無法重新識別到個人；達成此標準後 GDPR Recital 26 視為非個人資料、不受 GDPR 管轄。
- **重要**：實務上「真正不可逆」門檻極高 — 需考慮資料連結、輔助資訊、再識別風險；若理論上仍可被合理重建（如資料量過小、釋出統計可推回），仍視為個資。
- **假名化 (Pseudonymisation)**：**可逆** (有對照表／對應金鑰可還原)。**仍是個人資料**，仍受 GDPR 管轄，但被認可為一種強化安全措施 (GDPR Art. 32)。

---

### 8. 管理金鑰、機密和憑證

#### 機密管理 (Secrets Management)
- **對象**：API Key、DB 密碼、OAuth Token。
- **原則**：**絕不寫死** 在程式碼中。
- **工具**：使用 Secrets Manager (如 Vault) 進行**動態注入**與**自動輪換**。

#### 憑證管理 (Certificate Management)
- **PKI 核心組件**：
- **CA**：發憑證 (Sign)。
- **RA**：驗證身分 (Verify Identity)，**不**發憑證。
- **CRL/OCSP**：檢查憑證是否被撤銷 (Revoked)。
- **X.509**：數位憑證的標準格式。

#### 硬體安全 (Hardware Security)
| 設備 | 位置 | 用途 |
| :--- | :--- | :--- |
| **HSM** (硬體安全模組) | 專用設備、雲端服務 | **金鑰管理**、加密加速、保護 Root CA 金鑰 (防篡改)。 |
| **TPM** (信賴平台模組) | 主機板晶片 | **裝置認證**、安全開機 (Secure Boot)、密封 (Sealing)。 |

#### 金鑰托管 (Key Escrow)
確保第三方保管解密所需的私鑰或對稱金鑰副本，在約定條件下才釋出。

**典型情境**：
- 員工持有用於加密公司資料的金鑰，員工離職時公司仍需取回資料
- 與第三方托管服務簽約，在公司倒閉等條件下啟動托管金鑰
- 滿足合約義務或法規要求

**關鍵特性**：
- 與「金鑰備份」不同：托管須符合預定義條件才釋出
- 通常採用職責分離，避免單一人員可授權釋出
- 釋放條件須各方明確同意

#### 資料加密實施類型
依資料的位置與處理方式選擇不同實施：

| 類型 | 加密引擎位置 | 保護範圍 | 限制 |
| :--- | :--- | :--- | :--- |
| **基本儲存層級加密** | CSP 儲存管理層 | 硬體盜竊或遺失 | 不防 CSP 管理員或上層應用未授權存取 |
| **磁碟區加密 (Volume)** | VM 實例內或代理 | 實體遺失、儲存層管理員存取、快照備份 | 不防運行中實例上的應用攻擊 |
| **物件儲存加密 (Object)** | 客戶端（建議）或 CSP 端 | 客戶端加密：防 CSP 看明文；CSP 端：僅防第三方 | CSP 端加密無法保護資料免於 CSP 自身存取 |

**三大組件**（任何加密部署都包含）：
- **資料**：被加密的對象
- **加密引擎**：執行加密／解密運算
- **加密金鑰**：保護金鑰是維持加密有效性的核心

---

## 2.4 實施資料探索

在保護資料之前，必須先知道資料在哪裡。
**資料探索** 是資料分類的前置步驟 (先探索，再分類)。

### 1. 資料類型
- **結構化資料**：高度組織化，有預定義模型 (Schema)。如關聯式資料庫 (RDBMS) 中的資料。易於搜尋與管理。
- **非結構化資料**：無預定義模型。如 Word 文件、PDF、圖片、影片。佔企業資料的多數 (80% 以上)，最難管理與保護。
- **半結構化資料**：介於兩者之間。如 Email (標頭是結構化，內文是非結構化)、HTML、XML、JSON。

### 2. 資料探索方法
- **元資料分析**：檢查檔案屬性 (建立時間、擁有者、副檔名、欄位類型、大小) 而不檢查內容。速度快但準確度低，是最常見的方法。
- **標籤**：依賴使用者或系統在資料建立時打上的標籤進行探索。標籤可隨時間追加，比元資料更鬆散。
- **內容分析**：深入檢查檔案內容。
- **模式匹配**：使用正規表示式 (Regex) 搜尋特定格式 (如身分證號、信用卡號)。
- **關鍵字搜尋**：搜尋敏感字詞 (如 "Confidential", "Salary")。
- **雜湊與統計／詞彙分析**：用於 DLP 與網頁內容分析產品。
- **行為分析**：分析資料如何、何時、由誰存取的使用模式。可依資料對流程的重要性或使用時間／方式來識別關鍵資料。

### 3. 資料狀態與位置
探索需涵蓋資料的三種狀態：
- **靜態**：儲存體 (S3, EBS, 資料庫)。
- **傳輸中**：網路流量 (HTTP, SMTP)。
- **使用中**：端點記憶體、剪貼簿。

---

## 2.5 規劃與實施資料分類

### 1. 分類的目的與政策
並非所有資料價值相等。分類是為了**將適當的安全資源分配給適當的資料** (成本效益分析)。

**分類政策的角色**：
- 根據資料的某些特性，識別其保護要求或處理機制
- 高層級政策可分解為系統／應用層級的技術政策
- 政策可能重疊（同一筆資料可能符合多個分類），需明確規定哪一套保護優先

**強制分類的法規**：ISO 27001、PCI DSS 等都將資料分類列為要求。

### 2. 分類類別 (Classification Categories)

依用途不同，可採用多種分類維度：

| 分類維度 | 範例 |
| :--- | :--- |
| **資料類型** | 格式、結構（結構化／半結構化／非結構化） |
| **司法管轄區** | 來源地、住所地、跨境傳輸限制 |
| **上下文** | 業務情境、處理目的 |
| **所有權** | 內部／客戶／第三方 |
| **合約或業務限制** | NDA、保密協議涵蓋範圍 |
| **信任等級和來源** | 內部產生／外部接收 |
| **價值、敏感性、關鍵性** | 對組織或第三方的影響 |
| **保留與保存義務** | 法規要求保留 7 年、合約要求等 |

> 分類類別應與要使用的控制措施對應 — 例如為了加密分「加密／不加密」；為了 DLP 分「內部使用／限制共享」。

### 3. 資料對映 (Data Mapping)
建立特定對映或識別不同資料集中資料之間的關係。

**用途**：
- **欄位對齊**：兩個資料集都有「時間戳」欄位但格式不同（如 `timestamp` vs `time`，順序不同），對映可識別兩者為同類資料
- **敏感資料識別**：當敏感資料與非敏感資料混雜時，對映有助於識別敏感資料的存在

**資料流圖標示重點**：
- **位置**：地理位置 (影響 GDPR 等法規管轄權) 與邏輯位置
- **存取權限**：誰可以存取
- **敏感度**：機密等級

### 4. 標籤與標記
將分類結果「貼」在資料上。

| 項目 | 說明 |
| :--- | :--- |
| **標籤 (Labeling)** | 電腦可讀的標籤，常用元資料儲存 |
| **標記 (Marking)** | 人類可讀的識別符（如「機密」、「內部限閱」） |

**雲端挑戰**：
- 雲端服務 (特別是物件儲存) 可能會剝離 (Strip) 檔案原本的元資料或標籤
- 標籤被剝離後，自動化工具就無法識別該資料屬於特定分類
- 需驗證標籤在跨系統傳輸時是否被保留

### 5. 敏感度等級 (範例)
- **機密**：外洩會造成嚴重損害 (PII, 商業機密)
- **內部限閱**：僅供內部員工使用
- **公開**：可對外公開，無安全風險

---

## 2.6 設計與實施資訊權限管理

### 1. IRM 定義
一種以**資料為中心** 的保護技術。
與傳統 ACL 不同，IRM 的保護是**持續性** 的——保護機制跟隨檔案本身，無論檔案被複製到哪裡 (即使是隨身碟或外部郵件)，保護依然存在。

> **補充：DRM vs IRM**
> * **DRM**：通常指消費性內容 (音樂、電影) 的版權保護。
> * **IRM**：企業內部的權限控管 (文件、郵件)。

### 2. 核心功能
IRM 解決方案常見的關鍵功能：
- **持續保護 (Persistent Protection)**：保護隨檔案移動，無論檔案到哪裡都帶著存取控制
- **細粒度權限**：唯讀、禁止列印、禁止複製貼上、禁止螢幕擷取等
- **動態政策控制**：遠端可隨時調整或撤銷存取權限
- **自動過期**：文件設定特定時間後失效
- **持續稽核軌跡**：追蹤所有文件活動（開啟、列印、複製等）
- **支援既有身份驗證基礎設施**：與企業 AD、IdP、SSO 整合
- **與 ACL 對映**：可與儲存庫的存取控制清單整合
- **浮水印**：列印時自動加上識別資訊
- **多裝置／應用相容 (Multi-DRM)**：跨平台、跨閱讀器支援

### 3. 適當的工具：憑證簽發與撤銷

IRM 高度依賴 PKI 與憑證機制。**大綱明確要求**理解憑證的簽發與撤銷工具：

| 工具 | 說明 |
| :--- | :--- |
| **CRL (Certificate Revocation List)** | 從 CA 下載的清單，列出已被撤銷或暫時無效的憑證。**過期的憑證不在 CRL 中**。接收憑證時下載 CRL 比對，確認憑證是否仍可信任。 |
| **OCSP (Online Certificate Status Protocol)** | CRL 的替代方案。用於互動式檢查單一憑證的撤銷狀態，**不必下載整份清單**，效率較高。 |
| **資料探索工具** | 掃描未受保護的敏感資料（如 SSN、信用卡號），協助識別需以 IRM 保護的資產。 |

### 4. 實作挑戰
- **代理程式**：終端使用者通常需安裝本地 DRM 代理才能開啟受保護檔案
- **強大身份基礎設施**：每個資源都要配置存取政策、每位使用者都要配置帳戶與金鑰；身份基礎設施需擴展到客戶、合作夥伴
- **閱讀器相容性**：所有閱讀器都可能有相容性問題，部署前必須測試
- **行動裝置**：跨 OS 與不同檔案閱讀器的相容性挑戰更大
- **金鑰管理**：所有具存取權的使用者都需取得正確金鑰，分發機制複雜
- **跨 CSP 相容性**：CSP 提供的 IRM 解決方案可能與其他 CSP 不相容

---

## 2.7 規劃與實施資料保留、刪除和歸檔政策

### 1. 資料保留政策

**目標**：在「保留重要資訊」與「儲存成本／複雜度」之間取得平衡。

**良好的資料保留政策應定義**：
- 保留期限 (Retention Period)
- 資料格式 (Data Format)
- 資料安全
- 企業的資料檢索程序

**完整政策的 5 個組成要素**：

| 要素 | 說明 |
| :--- | :--- |
| **法規／法律／標準要求** | 各法規可能規定不同保留期限。例如 Basel II（財務交易 3-7 年）、PCI DSS 10.7（網路存取與持卡人資料至少保留 1 年、3 個月可上線存取）。可能存在「必須保留」與「必須刪除」衝突，需依管轄區決定 |
| **資料對映** | 對映所有資料以了解資料類型（結構化／非結構化）、檔案格式、儲存位置 |
| **資料分類** | 依位置、合規要求、所有權、業務價值分類，決定保留程序 |
| **保留程序** | 詳述保留時長、實體位置／管轄區、技術／格式、備份／還原程序 |
| **監控與維護** | 確保流程持續運作，定期審查政策與要求是否變動 |

### 2. 資料歸檔

**定義**：識別非活躍資料並從生產系統移到專門的長期歸檔儲存。優化生產系統效能 + 降低長期儲存成本。

**雲端歸檔政策應包含 6 個元素**：

| 元素 | 重點 |
| :--- | :--- |
| **資料加密程序** | 長期歸檔的金鑰管理是挑戰，金鑰遺失=整份歸檔銷毀 |
| **資料監控程序** | 追蹤所有資料存取與移動，維持資料治理 |
| **eDiscovery 與細粒度檢索能力** | 歸檔資料需能依日期、主題、作者等參數檢索 |
| **備份與災難復原選項** | 與 BC/DR 計畫保持同步 |
| **資料格式** | 避免專有格式（10 年後可能無法讀取），建議標準格式如 PDF/A |
| **資料還原程序** | 定期在隔離環境演練還原，避免還原時引入舊病毒或意外覆寫現有資料 |

### 3. 資料刪除與銷毀

雲端環境無法進行實體銷毀（消磁、粉碎），需依賴邏輯銷毀。

**驅動因素**：
- **法規／立法**：某些法律要求安全處置特定記錄
- **業務／技術要求**：如建立加密副本後安全處置明文資料

**雲端適用方法**：
- **加密抹除 (Cryptographic Erasure)**：銷毀解密金鑰，是雲端中常見且可驗證的銷毀方式之一；前提是資料**從未以明文外洩**、且**所有金鑰副本（含備份／HSM／逃生金鑰）皆能完整銷毀**。
- **覆寫**：用隨機數據覆蓋。但在 SSD 或分散式儲存上效果不佳（Wear Leveling 技術讓覆寫不一定真的覆蓋到原位置）。
- **實體銷毀**：適用於 CSP 自有硬體退役，由 CSP 執行並提供銷毀證明。

> CSP 控制底層硬體與技術功能，因此資料銷毀最終須結合：客戶端加密抹除 + CSP 的銷毀程序與 SLA / 合約條款（保留期、銷毀證明、稽核權）共同達成。單靠加密抹除無法完全免除 CSP 責任。

### 4. 法律保留
- 當涉及訴訟時，必須**暫停**所有正常的資料銷毀、回收流程，確保證據被完整保存。Legal Hold 的優先級高於 Retention Policy。

**關鍵要素**：
- **授權存取**：只有經授權的法務或合規人員可以存取被保留的資料，防止未經授權的修改或查看
- **刪除防護**：確保自動化的生命週期管理政策不會刪除被保留的資料，通常透過 WORM 儲存或物件鎖定 (Object Lock) 實現

---

## 2.8 設計與實施資料事件的可稽核性、可追溯性和問責性

### 1. 事件來源 (Event Sources)
日誌 (Logs) 是稽核的基礎。CSP 與消費者關注的事件來源不同：

**CSP 視角**：保護雲端本身（運算、儲存、SDN）。
**消費者視角**：在 CSP 產品層級衍生事件日誌（如 AWS CloudTrail 擷取所有 API 呼叫，含實例 ID、IP、區域）。

**主要事件來源類別**：
- **網路日誌**：防火牆、VPC Flow Logs、IDS/IPS、WAF 警報
- **應用程式日誌**：API 呼叫（CloudTrail）、資料庫查詢、API Gateway、Web Server
- **作業系統日誌**：登入成功／失敗、權限變更、特權操作（管理員／root 動作須記到安全位置）
- **效能與基礎設施日誌**：儲存、運算、記憶體、網路效能
- **第三方服務日誌**：SaaS 供應商、CDN、視訊串流（**注意**：這些日誌在他人控制之下，可靠性需評估）

### 2. 事件屬性 (Event Attributes)

每筆事件都應記錄足夠的屬性以支援後續分析。**大綱明確要求**至少包含：

| 屬性 | 用途 |
| :--- | :--- |
| **身份 (Identity)** | 哪個使用者／服務帳號／角色執行了動作 |
| **IP 位址** | 來源／目的端的網路位置 |
| **地理位置 (Geolocation)** | 行為發生的地理區域，異常可疑（如帳號平時在台灣、突然從中東登入）|
| **時間戳** | 精確時刻，需 NTP 同步以維持事件順序 |
| **動作／操作** | 做了什麼（讀取、寫入、刪除、修改權限等）|
| **結果** | 成功／失敗 |
| **資源** | 影響的資源／資料 |

### 3. 持續監控 (Continuous Monitoring)

依 **NIST SP 800-137**，**ISCM (Information Security Continuous Monitoring)** 定義為：「維持對資訊安全、漏洞和威脅的持續認知，以支援組織風險管理決策」。

**ISCM 重點**：
- 「持續」意味著評估與分析的頻率足以支援風險決策
- 將資安與風險管理整合進系統開發生命週期
- 需建立組織風險容忍度，並透過指標一致管理風險
- 確保所有安全控制持續有效
- 維持對資產、組態變更、威脅與漏洞的可見性

**典型監控子系統**：
- **網路**：丟棄封包過多
- **磁碟**：磁碟已滿、I/O 慢
- **記憶體**：使用率過高
- **CPU**：使用率過高

### 4. SIEM (安全資訊與事件管理)
- **功能**：集中收集各處日誌，進行**關聯分析**，以偵測複雜攻擊
- **WORM 儲存** (Write Once, Read Many)：確保存放日誌的儲存體不可被竄改，保障稽核可信度
- **防篡改要求**：某些法規與標準要求事件日誌機制必須防篡改，避免日誌被偽造

### 5. 監管鏈 (Chain of Custody)

**定義**：依時間順序的書面記錄／文件軌跡，記錄證據的扣押、保管、控制、轉移、分析與處置。

**ISO 27037:2012 對「證據保存」的定義**：維護和保護潛在數位證據的完整性與原始狀態的過程。

**雲端挑戰**：
- VM 實體位置未知；調查人員可能與 VM 在不同時區
- 缺乏實體存取（無法拔硬碟），需依賴 CSP 提供的日誌與快照
- 監管鏈關鍵在「認證」而非「複製」 — 任何對數位物件的變動都必須經身份驗證並記錄
- 需以雜湊值（Hash）證明完整性

### 6. 不可否認性 (Non-Repudiation)

**定義**：確保執行動作的實體日後不能聲稱自己沒做過。

**達成方式**：
- **仔細的記錄保存**：完整稽核軌跡
- **保留數位證據與日誌**：搭配 WORM 儲存防篡改
- **密碼學支援**：數位簽章可從技術上保證行為與身份綁定
- **時間戳服務**：證明動作發生的時間點

---

## 2.9 理解 AI/ML 資料的資料保護

> ⚡ **新版大綱新增章節** (2026/8/1 生效)

AI/ML 系統引入了獨特的資料保護挑戰，因為訓練資料和模型本身都可能包含敏感資訊。

### 資料集與模型隱私

AI/ML 模型可能無意中記憶訓練資料中的敏感資訊，產生隱私風險。

**主要隱私風險**：
- **模型反轉攻擊**：攻擊者透過查詢模型，反推出訓練資料中的敏感資訊
- **成員推斷攻擊**：判斷特定資料是否曾被用於模型訓練
- **訓練資料洩漏**：大型語言模型可能在回應中洩漏訓練資料的內容

**隱私保護措施**：
- **差分隱私**：在訓練過程中加入數學噪聲，防止個體資料被識別
- **聯邦學習**：資料留在本地，只傳輸模型更新
- **資料最小化**：只使用必要的資料進行訓練
- **匿名化、去識別化**：在訓練前移除 PII

### 資料集與模型安全

確保 AI/ML 資料集和模型的完整性、可用性和機密性。

**驗證**：
- 確認訓練資料的品質、完整性和代表性
- 檢測訓練資料中的偏差和異常
- 驗證模型輸出是否符合預期行為
- 定期重新驗證模型在新資料上的效能

**確認**：
- 驗證模型未被篡改（完整性檢查）
- 確認模型的版本控制和變更歷史
- 測試模型對抗對抗性範例 (Adversarial Examples) 的韌性
- 確保模型部署流程的安全性（供應鏈安全）

**安全威脅**：
| 威脅 | 說明 |
|------|------|
| **資料污染** | 攻擊者在訓練資料中注入惡意樣本，操縱模型行為 |
| **模型竊取** | 透過大量查詢模型 API，複製模型的功能 |
| **對抗性攻擊** | 對輸入資料進行微小修改，導致模型產生錯誤輸出 |
| **後門攻擊** | 在模型中植入隱藏的觸發條件，在特定輸入時產生惡意行為 |

---

# Domain 3：雲端平台與基礎設施安全 (Cloud Platform and Infrastructure Security)

> **考試權重**：17%
> **核心重點**：雲端基礎設施元件、資料中心設計、風險分析與處理、安全控制措施、以及 BC/DR 規劃。

---

## 3.1 了解雲端基礎設施元件

### 1. 實體環境
雖然雲端客戶 (CSC) 少有機會接觸實體層，但 CSP 需遵循國際標準。
- **標準遵循**：CSP 依據 ISO 標準及當地法規（如防震、防颶風）設計。
- **驗證**：客戶透過第三方稽核報告（如 SOC 2, ISO 27001）來驗證，而非親自稽核。

### 2. 網路與通訊
雲端網路高度依賴虛擬化技術。

#### 網路功能虛擬化 (NFV)
- **定義**：將防火牆、IDS/IPS、負載平衡器等硬體功能解耦，轉為軟體執行。
- **優勢**：
- 將資本支出 (CapEx) 轉為營運支出 (OpEx)。
- 縮短上市時間 (Time-to-market)。
- 提高敏捷性。

#### 軟體定義網路 (SDN)
- **核心概念**：將控制層與資料層分離，實現可程式化的網路管理。
- **SDN 的三個平面**：
| 平面 | 名稱 | 功能 | 介面、協定 |
| :--- | :--- | :--- | :--- |
| **管理平面** (Management) | 業務層 | 管理控制平面，透過 API 暴露給應用程式 | 北向介面 (Northbound) |
| **控制平面** (Control) | 大腦 | 決定流量路徑，下達指令給設備 | 南向介面 (Southbound, 如 OpenFlow) |
| **資料平面** (Data) | 轉發層 | 實際傳送封包的網路設備 (Switch/Router) | 基礎設施層 |

#### SD-WAN
- SDN 在廣域網路的延伸，支援雲端遷移，允許對流量進行微分段 (Microsegmentation) 和安全整合。

### 3. 運算
資源分配與隔離的核心。

#### 資源管理機制
CSP 使用以下機制管理多租戶資源爭用 (Contention)：
1. **保留**：保證 VM 獲得的**最小**資源量（低於此值無法開機）。
2. **限制**：VM 可使用的**最大**資源上限（可透過借用機制突破，但受限於此）。
3. **份額**：當發生資源爭用時，決定誰有**優先權**獲得剩餘資源的權重值。

#### 執行個體類型
- **保留執行個體**：承諾長期使用，換取折扣。
- **Spot 執行個體**：使用 CSP 閒置產能，價格極低，但隨時可能被收回（適合批次處理、無狀態應用）。
- **專用主機**：硬體不與其他租戶共享（適合嚴格合規需求）。

### 4. 虛擬化
- **Hypervisor**：
- **Type 1**：直接跑在硬體上 (如 ESXi, Hyper-V)。效能好，雲端主流。
- **Type 2**：跑在 OS 之上 (如 VMware Workstation)。雲端少見。
- **風險**：Hypervisor 是 CSP 的責任，若被攻破將導致所有租戶受害。

### 5. 儲存
CSP 將底層 HDD/SSD 抽象化後，向客戶呈現幾種儲存類型。

#### 傳統基礎（CSP 內部使用）
- **SAN (儲存區域網路)**：提供**區塊級**儲存，作業系統把它當本地磁碟使用。是雲端**磁碟區儲存**的源頭技術。
- **NAS (網路附加儲存)**：提供**檔案級**儲存（NFS、SMB、CIFS 協定），多台電腦共享檔案。是雲端**檔案／物件儲存**部分概念的源頭。

> 客戶不直接管理 SAN/NAS，但理解其差異有助於了解雲端儲存產品的設計選擇。

#### 雲端儲存類型

| 儲存類型 | 特性 | 適用場景 | 範例 |
| :--- | :--- | :--- | :--- |
| **物件儲存** (Object) | 透過 API 存取，包含資料 + 元資料 (Metadata)。通常在 VPC **之外**，預設可能對網際網路可見 | 影片、備份、靜態檔案、VM 啟動映像 | Amazon S3, Azure Blob |
| **磁碟區儲存** (Volume) | 虛擬硬碟 (Block Level)，可掛載到 VM | OS 碟、資料庫、頻繁讀寫 | AWS EBS, VMware VMFS, Cinder |

#### 底層儲存媒介
- **SSD**：交易性、頻繁讀寫工作負載；又分通用型與**預配置 IOPS**（任務關鍵）
- **HDD**：大型串流吞吐工作負載；不常存取資料的低成本選項

- **超融合基礎架構 (HCI)**：將運算、儲存、網路融合，透過軟體定義方式集中管理；常用於高頻寬、低延遲需求（大數據平行處理、串流影音）。

### 6. 管理平面
- **定義**：控制雲端資源的「上帝模式」(God Mode)。
- **功能**：開、關 VM、配置資源、IAM、日誌記錄。
- **風險**：
- 這是攻擊者的首要目標。
- 需透過 API 存取，通常透過 Web Console 呈現。
- **客戶責任**：保護管理控制台的存取憑證 (MFA 是必須的)。

---

## 3.2 設計安全資料中心

### 1. 邏輯設計
在雲端，邏輯設計優於實體設計。
- **虛擬私有雲 (VPC)**：租戶隔離的基礎。
- **隔離方法**：使用標籤 (Tagging)、安全群組 (Security Groups)。
- **部署策略**：
- **藍綠部署**：新舊版本並存，切換流量。若失敗可立即切回，減少停機時間。

### 2. 實體與環境設計
依據 ISO/IEC TS 22237 標準。

#### 場址選擇與建造（Location, Buy or Build）
- **場址選擇要素**：海拔（影響系統效能）、土地先前用途（殘留工業廢棄物可能影響人員）、地理風險（地震、颶風、冰風暴）、能源供應、網路骨幹接入
- **Buy or Build**：
- **私有雲擁有者**：可購買既有資料中心容量（速度快但設計受限）或從零建造（成本高但完全客製）
- 大多由第三方專業廠商承建
- 公有雲消費者：CSP 自行決定，客戶承擔較高的「保證」責任而非建造責任
- **ISO 涵蓋規範**：位置與場址、建築物建造、配置、消防保護、施工品質

#### 可用性等級 (Availability Classes)
| 等級 | 描述 | 特性 |
| :--- | :--- | :--- |
| **Class 1** | 單一路徑 | 無冗餘，故障即中斷。 |
| **Class 2** | 單一路徑 + 冗餘電力 | 電力有備援，但空調、網路無。 |
| **Class 3** | 多路徑 (一主一備) | 允許**同時維修**。 |
| **Class 4** | 多路徑 (雙主動) | **容錯**，能抵禦最嚴重故障。 |

#### 保護等級 (Protection Classes) - 實體區域
- **Zone 1**：公共區域。
- **Zone 2**：辦公區、裝卸區 (所有授權員工)。
- **Zone 3**：限制區 (電信機房、機電室)。
- **Zone 4**：最高安全區 (電腦機房、主配線區)。*保護等級是累加的。*

#### 消防系統 (Fire Suppression)
- **原則**：資料中心**避免使用水**（會損壞電子設備且有觸電風險）。
- **潔淨滅火劑 / 抑制劑（清潔劑型，不損害電子設備）**：
- **FM-200 (HFC-227ea)**：海龍替代品的化學潔淨氣體，藉由吸熱與化學中斷燃燒鏈反應；不置換氧氣，**人員在場可安全使用**。
- **Aero-K**：**鉀基氣溶膠 (Potassium-based Aerosol)**，非氣體；點燃後產生極細微鉀化合物粒子，藉化學反應抑制火焰自由基；密度低、無毒、可短時間人員在場使用。
- **Inergen / Argonite**：以 N₂、Ar、CO₂ 混合稀釋氧氣至約 12–14%，仍可維持人員短時呼吸。
- **CO2**：會置換氧氣至窒息濃度，對人員有致命風險，**通常不用於有人區域**。
- **防火封堵**：防止火勢、煙霧穿過牆壁開孔的技術。

### 3. 韌性設計
確保資料中心在元件故障時仍能持續運作。

**關鍵韌性面向**：
- **電力**：不間斷電源 (UPS)、備用發電機、雙路供電、自動切換開關 (ATS)
- **暖通空調**：冗餘冷卻系統、N+1 或 2N 配置、環境監控
- **連線**：多路徑網路連線、多供應商策略 (Multi-vendor Pathway)、自動故障轉移

---

## 3.3 分析雲端基礎設施與平台風險

### 1. 風險評估的雲端特殊性
雲端風險評估與本地環境的最大差異：
- **缺乏 CSP 控制可見性**：客戶看得到認證資訊，但無法精確評估 CSP 控制的實作細節
- **公有雲控制權低於私有雲／本地部署**：相當一部分責任由 CSP 承擔，客戶需評估 CSP 的控制是否符合自家風險情境
- **NDA 限制**：CSP 通常只在簽 NDA 後才願意分享詳細答案
- **建議實踐**：對 SLA 中所有功能完整測試，確保達到預期效能；要求第三方稽核報告（SOC 2、ISO 27001、CSA STAR）

### 2. 虛擬化相關風險（CSP 角度）

| 風險 | 說明 |
| :--- | :--- |
| **Hypervisor 漏洞** | hypervisor 中的安全漏洞可能導致惡意軟體針對在其上運行的 VM 或基礎架構其他元件 |
| **VM 逃逸 (VM Escape)** | 攻擊者從來賓 VM 利用 hypervisor 或虛擬化驅動漏洞，逃出隔離邊界，取得 hypervisor 或宿主機控制權 |
| **VM 跳躍 (VM Hopping)** | 攻擊者由一台 VM 透過共享資源（記憶體、網路、虛擬介面）移動到同主機上的另一台 VM，繞過租戶隔離 |
| **超劫持 (Hyperjacking)** | 攻擊者在 hypervisor 之下植入惡意 hypervisor（rogue hypervisor），完全控制其上所有 VM；通常需要在開機鏈或固件層下手 |
| **VM 資源餓死** | VM 佔用過多資源導致其他 VM 無法運作（DoS） |
| **VM 流量可見性不足** | VM 之間的網路流量與實體網路安全控制可見性不確定，可能需要額外控制 |
| **靜止 VM 映像被存取** | VM 與磁碟映像本質上只是檔案系統上的檔案；停止的 VM 若無控制可被第三方直接存取，繞過客戶 OS 的所有控制 |
| **VM 蔓延 (VM Sprawl)** | 未管理的 VM 過多，攻擊面擴大及合規問題 |

### 3. 雲端弱點、威脅與攻擊

#### SaaS 角度（消費者風險）
- 缺乏對應用程式內資料的透明度
- 惡意內部人員濫用 CSP 與消費者資料
- 影子 IT (Shadow IT)
- 法規遵循漂移
- 控制粒度不足
- 員工培訓不當（管理規定的控制）
- 對勒索軟體缺乏盡職調查與盡責照護

#### IaaS 角度（消費者風險）
- 提供商位置的資料實體保護不足
- 未經授權的工作負載被啟動
- 多雲安全不一致
- APT 的東西向移動
- 員工培訓不當（管理規定的控制）
- 應用程式未採用安全設計原則建構

### 4. 風險處理策略
- **零信任**：
- 原則：**永不信任，始終驗證**。
- 假設網路已被入侵。
- 五步驟：定義保護面 -> 繪製資料流 -> 架構零信任 -> 自動化政策 -> 持續監控。
- **微分段**：
- 針對**東西向流量** (資料中心內部) 進行細粒度控制。
- 每個工作負載都有自己的防火牆規則。
- **管理平面保護**：
- 限制存取 (MFA、跳板機)。
- 對加密金鑰進行加密抹除 (Crypto-shredding)。

### 5. MITRE ATT&CK 框架
基於紅隊或對手導向方法，提供 APT 操作者使用的真實戰術與技術 (TTPs)。

**三大技術領域知識庫**：
- **企業 (Enterprise)**：傳統 IT／雲端
- **行動裝置 (Mobile)**：行動 OS 與應用
- **工業控制系統 (ICS)**：OT、製造、能源等

**代表性攻擊階段**：
- **資源開發 (Resource Development)**：攻擊者取得基礎設施／工具／帳戶／能力（企業層獨有）
- **持久化 (Persistence)**：維持對目標系統的持續存取（所有層級通用）
- **網路效應 (Network Effects)**：在不直接存取設備的情況下控制其網路流量（行動裝置層級）
- **抑制回應功能 (Inhibit Response Function)**：阻斷警報、報告與控制訊息（ICS 層級）

**用途**：
- 事後發現入侵指標
- 調查異常並確認攻擊是否進行中
- 執行有針對性的弱點評估
- 改善偵測與回應流程

---

## 3.4 規劃與實施安全控制措施

### 1. 實體與環境保護（On-Premises）
依據 **ISO/IEC TS 22237**（共 7 個子文件），定義資料中心的可用性等級與保護等級。

- **保護等級分配**：最中心位置獲最高保護等級
- **累加性**：等級二的牆壁依賴等級一外牆存在 — 一道牆可同時滿足多個等級
- 詳細的可用性等級 (Class 1-4)、保護等級 (Zone 1-4)、消防系統見 **3.2 章節**
- 客戶必須確認 CSP 在這些標準上已執行盡責照護與盡職調查

### 2. 系統、儲存與通訊保護
IaaS 是多個服務協同運作的結果。CSP 需配置、維護與分析以下元件的風險：

| 元件 | 用途 |
| :--- | :--- |
| **Hypervisor** | VM 管理 |
| **儲存控制器** (Storage Controllers) | 區塊／物件儲存後端 |
| **磁碟區管理** (Volume Management) | EBS／磁碟區的配置 |
| **IP 位址管理 (DHCP)** | 動態 IP 分配 |
| **安全群組管理** | NSG 規則維護 |
| **VM 映像服務** | AMI、Image Library |
| **身分服務** | IAM 控制平面 |
| **訊息佇列** | 服務間非同步通訊 |
| **管理資料庫** | 組態與狀態儲存 |
| **客戶 OS 保護** | 客戶責任，但 CSP 提供工具 |

**虛擬化感知 (Virtualization-Aware)**：所有安全工具（病毒掃描、IDS/IPS、AV）必須能感知虛擬化環境，避免效能瓶頸或誤判。

### 3. 雲端環境中的身分識別、驗證與授權

**身分提供者標準協定**：
- **公有雲**：OpenID、SAML、OAuth（社交媒體與 SaaS 廣泛採用）
- **企業環境**：SAML、WS-Federation；Microsoft Active Directory 為主流

**身分驗證 (Authentication)**：以足夠確定性建立實體身分。
- 因素：知道（密碼）、擁有（金鑰產生器）、是（生物辨識）
- **高風險角色**（如管理功能）建議 MFA

**授權 (Authorization)**：授予資源存取權。
- 可基於身分、屬性（角色 RBAC）、上下文（位置／時間）
- 在「策略執行點」靠近資源處執行
- 聯合身分模型中，授權通常由「信賴方 (Relying Party)」執行

### 4. 稽核機制

**目的**：提供合理保證，確認風險控制存在且運作有效。
**動機**：法規合規、品質系統、客戶要求增加品質證明。

**雲端稽核挑戰**：客戶缺乏實體存取，需依賴 CSP 提供的：
- **日誌收集 (Log Collection)**：彙整來自管理平面、服務、資源的日誌
- **日誌關聯 (Correlation)**：跨來源事件比對，識別複雜攻擊（SIEM 核心能力）
- **封包擷取 (Packet Capture)**：擷取實際網路流量供深入分析；雲端中常受加密與 CSP 限制

**整合到 ERM**：稽核應嵌入企業風險管理框架，將技術、法律、合約、司法管轄、合規要求一併彙整。

---

## 3.5 規劃營運持續與災難復原

### 1. 定義與標準
- **ISO 22301**：**營運持續**。組織在中斷期間於可接受時間內繼續交付產品、服務的能力（整體生存能力）。
- **ISO 27031**：**災難復原**。ICT 元素在中斷後於預定時間內支援關鍵業務功能的能力（技術子集）。
- **DR ⊂ BC**：DR 是 BC 的技術子集。
- **優先順序**：**人身安全** 永遠是第一優先。

### 2. BCDR 策略與 BCMS

組織以 **營運持續管理系統 (BCMS)** 系統化方式支援 BCDR。ISO 22301 列出 BCMS 的 9 大元件：

| 元件 | 重點 |
| :--- | :--- |
| **領導與承諾** | BCDR 政策與組織策略一致；資源到位；持續改善 |
| **風險評估與業務衝擊分析 (BIA)** | 確定關鍵流程、MTPD、RTO、RPO |
| **法律與法規要求** | 識別、追蹤、文件化適用法規 |
| **意識** | 角色與責任、不遵循的後果、改善的好處 |
| **溝通** | 內外部溝通的什麼／何時／如何／誰 |
| **復原站點位置** | 建立、更新、按需要原則分享、機密性、變更控制 |
| **資源需求** | 人員、資料、運輸、實體基礎建設、財務、供應商 |
| **關鍵功能備援位置** | 災難時備援啟動點 |
| **回應結構** | 評估中斷、衡量影響、啟動回應、人身安全優先、監控有效性 |

### 3. BCDR 策略本身的風險
BCDR 機制本身會引入新風險：

- **冗餘架構複雜度**：容錯移轉策略增加新故障模式與技能需求
- **共同故障模式**：多區域架構仍可能受區域性事件影響；VM 容錯叢集仍可能整個叢集故障
- **地理分散副作用**：頻寬與延遲影響效能；不同司法管轄區可能有合規顧慮

### 4. 業務需求與關鍵指標

- **復原時間目標 (RTO)**：能容忍多久沒服務？業務中斷到恢復的時間目標。**RTO 必須小於 MTPD**。
- **復原點目標 (RPO)**：能容忍遺失多少資料？需回溯到多久前的備份。**通常以時間衡量**（分鐘、小時、天），不是以儲存量。
- **最大可容忍中斷期間 (MTPD)**：超過此時間企業將面臨永久性失敗。
- **復原服務水準 (Recovery Service Level)**：恢復後須達到的最低服務能力（並非完整正常營運）。

#### 規劃前必問的 5 個問題
1. 資料是否足夠有價值以制定 BCDR 策略？
2. 所需的 RPO 是什麼（多少資料遺失可容忍）？
3. 所需的 RTO 是什麼（多久業務不可用可容忍）？
4. 分析中包含哪些類型的「災難」？
5. 是否包括 CSP 故障？

> 極端情況下 RPO 與 RTO 都可為零，但實務上會在「損失預防」與「成本」間迭代取得平衡。

### 5. 計劃的建立、實施與測試

#### A. 計劃建立流程
1. **範圍**：定義角色、風險評估、分類、政策、意識與培訓
2. **收集需求與背景**：識別關鍵業務流程、所依賴服務系統、威脅模型（含 CSP 故障）、SLA 與法規義務
3. **設計**：建立並評估候選架構，制定程序與工作流程，明確擁有者與授權
4. **實施**：在主要平台與 DR 平台同步建構；確保 DR 平台追蹤主要平台變更；納入常規 IT 服務管理

#### B. 設計階段須回答的問題
- BCDR 解決方案如何調用？手動還是自動觸發？
- 故障切換期間業務如何受影響？
- DR 將如何測試？
- 設定、啟動、恢復正常需要什麼資源？

#### C. 測試類型（由簡至繁）
1. **桌面審查 (Desktop Review)**：紙上談兵，檢查計畫邏輯
2. **復原模擬 (Recovery Simulation)**：演練特定情境，不影響生產環境
- **元件故障復原**
- **服務復原**
3. **營運測試 (Operational)**：在冗餘生產系統間切換（最真實，含**完全中斷／切換**到 DR 平台）

> 測試應模擬最真實情境，包含遠端工作。**未經測試的故障切換不太可能有效**。

#### D. 混沌工程（Netflix Simian Army）
主動引入故障以發現弱點並建立信心：
- **Chaos Monkey**：隨機關閉生產 VM
- **Chaos Gorilla**：可用性區域 (AZ) 級別故障
- **Chaos Kong**：區域 (Region) 級別故障
- 經典案例：AWS DynamoDB 在 us-east-1 區域出問題時，Netflix 因壓力測試成功故障切換，其他大公司停機 7-8 小時

### 6. 支援雲端 BCDR 的託管服務

#### A. 兩種主要架構
| 模式 | 說明 |
| :--- | :--- |
| **主動／主動 (Active/Active)** | 多區域同時運行，流量同時導流；RTO 接近零 |
| **主動／被動 (Active/Passive)** | 主區域處理流量，備援區域待命；故障時切換 |

#### B. 雲端原生 BCDR 工具
- **跨區域複製服務**：物件儲存、資料庫、串流服務都有內建備份／複製
- **IaC**：用 Terraform 等工具讓 BCDR 部署可攜（甚至跨 CSP）
- **離線但準備就緒的精簡基礎建設**：保留最小規模在備援區域，故障時橫向擴展

#### C. 挑戰
- **資料主權**：異地備援可能違反資料居留法規
- **頻寬與延遲**：複製大量資料的成本與時間
- **CSP 容量**：BCDR 啟動時 CSP 是否有足夠彈性提供所有資源
- **應用程式相依性**：IaC 之外，還需確保應用映像、程式碼儲存庫等在備援站點可用

---

# Domain 4：雲端應用程式安全 (Cloud Application Security)

> **考試權重**：16%
> **核心重點**：安全軟體開發生命週期 (SDLC)、威脅建模、應用程式測試 (SAST/DAST)、身分與存取管理 (IAM/Federation)、以及雲端原生架構 (容器、微服務/FaaS)。

---

## 4.1 倡導應用程式安全培訓與意識

### 1. 雲端開發基礎

雲端開發與傳統本地部署在「整合開發環境、應用生命週期管理、應用安全測試」上有顯著差異。應用程式可從以下三個維度檢視，並對應三種資料狀態：

| 應用程式維度 | 對應資料狀態 |
| :--- | :--- |
| **資料 (Data)** | 靜態資料 (Data at Rest) |
| **功能 (Functions)** | 使用中資料 (Data in Use) |
| **流程 (Processes)** | 傳輸中資料 (Data in Motion) |

> 將敏感的元件劃分到指定位置處理，可同時符合企業政策、法規，並利用雲端經濟模型的彈性。

### 2. 雲端就緒評估
組織遷移雲端前，從六個面向評估準備程度：

| 面向 | 評估重點 |
| :--- | :--- |
| **業務使命 (Mission)** | 動機與業務案例（如新 CRM 平台需求＝上市時間驅動） |
| **人員 (People)** | 高層倡導、員工跨職能協作、變更管理人員的能力 |
| **流程 (Process)** | 現有變更／配置管理是否準確；服務管理與專案管理成熟度；先小規模 PoC |
| **平台 (Platform)** | 雲端登陸區 (Landing Zone) 設計；混合雲為最常見方法；遵循 Well-Architected Framework |
| **營運 (Operations)** | 共享責任模型對齊；責任映射（前 / 過渡 / 後）；BCDR 流程重新調整 |
| **安全 (Security)** | 多租戶、無 air gap、Shadow IT、第三方管理員、共享其他租戶（含競爭者與敵對群體） |

### 3. 常見陷阱（Common Pitfalls）

| 陷阱 | 說明 |
| :--- | :--- |
| **缺乏培訓與意識** | 雲端環境是軟體可配置、虛擬化的；直接參與者需培訓，間接參與者也要了解新平台 |
| **加密依賴性** | 新加密引擎需新流程；備份／靜態／傳輸資料保護方案更多 |
| **文件與指南不足** | CSP 常以 MVP 形式發布新服務，文件不成熟即代表風險；早期採用成本高 |
| **整合複雜性** | 共享責任模型下需新技能除錯、追蹤跨層事件；盡量使用 CSP 提供的 API |
| **總體挑戰** | 多租戶（資料庫表格邏輯隔離但實體共享）、第三方管理員、部署模型、服務模型 |

### 4. 應用程式遷移挑戰

判斷應用程式是否準備好遷移雲端：
- **是否為水平擴展架構？**（透過添加相同大小執行個體應對需求）
- **持久層是否從應用其餘部分抽象出來？**（託管 DB、訊息佇列、物件儲存等選項）
- **能否縮減水平規模而不遺失資料／交易？**（雲端經濟效益的關鍵）

**舊有應用程式 (Legacy)** 的限制：
- 多為**垂直擴展**設計，假設運行在資料中心防火牆後
- 狀態保存在多處，低需求時難以縮減
- 繼承的限制讓動態可擴展架構的節省效益打折

### 5. 常見雲端弱點
考試涵蓋多個重要的弱點清單，需要了解各清單的適用範圍。

#### OWASP Top 10 (Web 應用程式)
OWASP Top 10 是 Web 應用程式最關鍵的風險清單，考試極高機率出現。

| 排名 | 風險名稱 | 關鍵描述 |
| :--- | :--- | :--- |
| **A01** | **存取控制失效** (Broken Access Control) | 用戶能執行超出其權限的操作 (如越權存取)。**排名第一**。 |
| **A02** | **加密失敗** (Cryptographic Failures) | 敏感資料暴露、加密演算法薄弱 (舊稱敏感資料暴露)。 |
| **A03** | **注入** (Injection) | SQL Injection, XSS (現在歸類於此)。 |
| **A04** | **不安全設計** (Insecure Design) | **新類別**。強調「左移」，需在設計階段進行威脅建模。 |
| **A05** | **安全配置錯誤** (Security Misconfiguration) | 預設帳密未改、雲端儲存權限過大。XXE 現在歸類於此。 |
| **A06** | **易受攻擊和過時的元件** | 使用有漏洞的 Library 或 Framework (需透過 SCA 檢測)。 |
| **A07** | **身分識別和驗證失敗** | 弱密碼、無 MFA、Session 管理不當。 |
| **A08** | **軟體和資料完整性失敗** | **新類別**。來自不信任來源的更新、CI/CD 管道被竄改。 |
| **A09** | **安全日誌記錄和監控失敗** | 無法偵測入侵，導致攻擊時間延長。 |
| **A10** | **伺服器端請求偽造** (SSRF) | 攻擊者誘使伺服器向內部系統發出請求 (雲端環境中對 Metadata Service 的攻擊常屬此類)。 |

#### OWASP Application Security Verification Standard (ASVS)
提供應用程式安全驗證的標準框架，定義三個等級的安全要求，從基本到高安全。

#### OWASP Top 10 API Security Risks
專門針對 API 安全的風險清單，涵蓋物件層級授權失效 (BOLA)、驗證失效、過度資料暴露等 API 特有風險。雲端環境大量依賴 API，此清單與雲端安全高度相關。

#### OWASP Top 10 for Large Language Model Applications
針對 LLM 應用程式的安全風險清單，涵蓋提示注入 (Prompt Injection)、不安全的輸出處理、訓練資料污染、模型阻斷服務等新型態威脅。

#### SANS/CWE Top 25
基於 CVE 和 CVSS 分數統計最危險的軟體弱點。第一名通常是 CWE-787 (越界寫入)。

---

## 4.2 描述安全軟體開發生命週期流程

### 1. 業務需求與標準框架
SDLC 是一個從規劃到除役的系統化流程。業界常用的安全框架包括：

- **NIST SP 800-218**
- **全名**：安全軟體開發框架 (Secure Software Development Framework)。
- **目的**：提供一組核心高階實踐，目標是減少發布軟體中的弱點數量，並緩解未偵測到弱點的潛在影響。
- **優勢**：提供通用詞彙，促進軟體採購者與供應商之間的溝通。

- **NIST SP 800-160 Vol. 1**
- **核心**：系統安全工程 (Systems Security Engineering, SSE)。
- **方法**：將安全工程方法融入 ISO/IEC/IEEE 15288 的系統生命週期流程中，從利害關係人的角度解決安全問題。

- **ISO/IEC 27034**
- **核心**：應用程式安全管理流程 (Application Security Management Process, **ASMP**)。
- **原則**：跨多個應用程式使用**可重複使用**的軟體安全控制措施 (如 ONF/ANF) 比每次都重新客製化更有效率。

- **Microsoft SDL**
- **組成**：12 項實踐，涵蓋從培訓到事件回應全生命週期
- **12 項實踐**：
1. 提供培訓
2. 提供安全需求
3. 定義指標和合規報告
4. 執行威脅建模
5. 建立設計需求
6. 定義和使用加密標準
7. 管理使用第三方的安全風險
8. 使用核准的工具
9. 執行靜態分析安全測試 (SAST)
10. 執行動態分析安全測試 (DAST)
11. 執行滲透測試
12. 建立標準事件回應流程

### 2. SDLC 階段
大多數 SDLC 模型包含以下階段的變體：

1. **定義**：收集業務與安全需求，建立軟體需求規格書 (SRS)。
2. **設計**：將需求轉為架構。**威脅建模** 應在此階段進行以驅動安全設計。
3. **開發**：將設計轉為原始碼。實施程式碼審查、單元測試和靜態分析。
4. **測試**：進行功能測試、使用者驗收測試 (UAT) 和品質保證 (QA)。
5. **部署、營運**：進入生產環境。活動包括動態分析、弱點評估、滲透測試、WAF 防護。
6. **維護**：根據需要更新與修補。
7. **處置**：軟體除役。在雲端環境中，需特別注意資料的**加密銷毀** 或刪除金鑰。

### 3. 軟體開發模型

### 瀑布模型
- **特性**：線性順序模型，前一階段完成才能進入下一階段 (如瀑布般向下流動)。
- **優點**：簡單易懂，交付物明確，易於管理。
- **缺點**：變更困難，發布週期長。假設需求在早期就能完全確定，不適合需求頻繁變更的專案。

### 敏捷
- **核心價值 (敏捷宣言)**：
- 個人與互動優於流程與工具。
- 可運作的軟體優於全面的文件。
- 客戶協作優於合約談判。
- **回應變化優於遵循計劃**。
- **雲端支援**：雲端服務目錄 (Service Catalog) 可支援敏捷團隊快速獲取預配置的安全項目。

#### 常見敏捷實踐
| 方法 | 特點 |
| :--- | :--- |
| **Scrum** | 最流行的敏捷方法。包含每日站立會議 (Daily Stand-up)、短衝 (Sprint)。 |
| **極限程式設計** | 輕量級方法，適合需求模糊的專案。強調**結對程式設計** (一人寫碼，一人即時審查)、**重構**、**集體所有權**。 |

---

## 4.3 應用安全軟體開發生命週期

### 1. 雲端特定風險

雲端環境引入了獨特的風險類別，開發者在 SDLC 中需特別關注：

**新版大綱明確列出的風險類別**：
- **共享技術問題**：多租戶共享底層硬體和 Hypervisor，一個租戶的漏洞可能影響其他租戶
- **CSP 內部威脅**：CSP 員工可能有存取客戶資料的能力
- **缺乏可見性和控制**：客戶對底層基礎設施的監控和管理能力有限
- **法律和管轄權問題**：資料跨境儲存可能面臨不同法規的衝突

#### CSA Egregious Eleven
CSA 定義了雲端環境中最嚴重的 11 項威脅 (惡名昭彰的十一項)，開發者需針對這些風險進行緩解：

1. **資料外洩**：機密資訊的意外存取或被竊。
2. **配置錯誤和變更控制不足**：如 S3 Bucket 權限過大、保留預設密碼。需持續掃描配置。
3. **缺乏雲端安全架構和策略**：誤以為可以單純「提升並轉移 (Lift and Shift)」現有架構而不適配雲端特性。
4. **身分、憑證、存取和金鑰管理不足**：未實施 MFA、金鑰未輪換、憑證寫死在程式碼中。
5. **帳戶劫持**：惡意攻擊者獲得高權限帳戶存取權。
6. **內部威脅**：惡意或疏忽的員工。需限制特權存取。
7. **不安全的介面和 API**：API 是系統最暴露的部分 (前門)。需進行清點、測試與防護。
8. **薄弱的控制平面**：若無法完全掌控管理平面，將導致架構盲點。
9. **元結構和應用結構故障**：API 實施不良導致 CSP 層級的漏洞 (Metastructure 是 CSP 與消費者間的分界線)。
10. **有限的雲端使用可見性**：員工使用未經核准的雲端服務，導致無法管理與保護。
11. **濫用和惡意使用雲端服務**：如利用雲端資源進行挖礦或發動 DDoS。

### 2. 威脅建模
威脅建模通常在**設計階段**進行，目的是在寫程式碼之前識別潛在設計缺陷。

#### STRIDE 模型
幫助開發人員識別六大類威脅及其對應的安全屬性：

| 威脅 (Threat) | 定義 | 破壞的安全屬性 | 對應消減措施 |
| :--- | :--- | :--- | :--- |
| **S**poofing | 欺騙、假冒身分 | 身分驗證 (Authentication) | 強身分驗證 (MFA) |
| **T**ampering | 竄改資料或訊息 | 完整性 (Integrity) | 數位簽章、雜湊 |
| **R**epudiation | 否認做過某事 | 不可否認性 (Non-repudiation) | 稽核日誌、數位簽章 |
| **I**nformation Disclosure | 資訊洩露 | 機密性 (Confidentiality) | 加密、ACL |
| **D**enial of Service | 阻斷服務 | 可用性 (Availability) | 流量清洗、負載平衡 |
| **E**levation of Privilege | 權限提升 | 授權 (Authorization) | 最小權限原則 |

#### DREAD 模型
用於對已識別的威脅進行**風險評級**，每個維度以 1-10 分評估，總分越高風險越大：

| 維度 | 全稱 | 評估問題 |
| :--- | :--- | :--- |
| **D**amage | 損害程度 (Damage) | 攻擊成功後造成的損害有多大？ |
| **R**eproducibility | 可重現性 (Reproducibility) | 攻擊有多容易被重現？ |
| **E**xploitability | 可利用性 (Exploitability) | 發動攻擊需要多少技術能力？ |
| **A**ffected Users | 受影響使用者 (Affected Users) | 有多少使用者會受到影響？ |
| **D**iscoverability | 可發現性 (Discoverability) | 漏洞有多容易被發現？ |

> **STRIDE vs DREAD**：STRIDE 用於**識別**威脅類型，DREAD 用於**評估**威脅的嚴重程度。兩者常搭配使用——先用 STRIDE 找出威脅，再用 DREAD 排定優先處理順序。

#### 其他模型
- **攻擊模擬和威脅分析流程 (PASTA)**：
- **風險導向** 的 7 階段框架。
- 結合業務目標與技術範圍，包含攻擊者視角。
- **架構、威脅、攻擊面、緩解措施 (ATASM)**：
- 強調對系統架構的結構性理解。
- **濫用案例**：
- 與使用案例 (Use Cases) 相反，從**惡意攻擊者**的角度思考如何破壞系統。
- 這是定義安全需求的重要工具，有助於識別特定攻擊並評估業務風險。

### 3. 避免常見弱點 (Avoid Common Vulnerabilities)
從軟體開發角度應對常見技術問題的關鍵資源：

- **OWASP Top 10**：Web 應用程式最關鍵風險（已於 4.1 詳列）
- **CWE Top 25**：最危險軟體弱點（基於 CVE/CVSS 統計）
- **OWASP Cornucopia**：安全卡片遊戲，協助敏捷團隊在設計階段識別需求
- **ISC² CSSLP**：安全軟體生命週期專業認證的學習資源
- **組織 SDL 方法**：依組織自身挑戰選用最適合的資源

### 4. 安全需求驗證：OWASP ASVS
**OWASP 應用程式安全驗證標準**提供一組可驗證的安全需求，分為三個等級：

- **Level 1 (基本)**：防禦 OWASP Top 10 等常見漏洞。所有應用程式的最低標準
- **Level 2 (標準)**：適用於處理重要 B2B 交易、醫療資訊或敏感功能的應用程式
- **Level 3 (進階)**：適用於軍事、關鍵基礎設施等需要重大安全驗證的高風險領域

### 5. 安全編碼：SAFECode
**SAFECode (Software Assurance Forum for Excellence in Code)** 提供指南與建議，協助企業：
- 軟體產品採購決策
- 威脅建模 (Threat Modeling) 實踐指引
- DevOps 環境的安全實踐

**SAFECode 對 DevOps 的兩個重要威脅建模觸發點**：
| 觸發點 | 說明 |
| :--- | :--- |
| **軟體部署流程變更** | DevOps 環境的自動化部署工具，任何部分被妥協可能造成服務完全妥協 — 對部署自動化的身份驗證／授權／資料流變更須觸發威脅模型審查 |
| **服務執行環境變更** | 新的 port/protocol、應用伺服器或 OS 配置變更、帳戶與權限變更 |

### 6. 軟體配置管理與版本控制 (CM and Versioning)

**配置管理 (Configuration Management)**：在離散時間點識別軟體配置，並系統性控制變更，以維護整個生命週期的：
- **完整性 (Integrity)**
- **可追溯性 (Traceability)**
- **問責性 (Accountability)**

**捕獲資訊**：已應用的版本、更新、補丁

**常見工具**：Puppet、Chef、Ansible、Salt（每個大型 CSP 都提供配置管理服務）

**應用範圍**：開發、生產、修改的整個系統生命週期

**版本控制**：確保版本與配置一致性，部署時清楚知道使用哪個版本

## 4.4 應用雲端軟體保證和驗證

### 1. 功能與非功能測試

**功能測試**：驗證軟體是否符合業務需求規格（如功能正確性、使用者工作流程）。
**非功能測試**：驗證效能、可用性、安全性、可擴展性等品質屬性。

#### 持續整合與持續交付 (CI/CD) 流程
CI/CD 是現代雲端開發的基礎，安全測試應整合到 CI/CD 管道的每個階段：
- **持續整合 (CI)**：開發者頻繁合併程式碼，自動觸發建置和測試（包括 SAST、SCA）
- **持續交付、部署 (CD)**：自動化將通過測試的程式碼部署到各環境（包括 DAST、滲透測試）
- **安全關卡**：在管道中設定安全品質閘門，未通過安全測試的程式碼不得進入下一階段

### 2. 安全測試方法論

| 測試方法 | 全名 | 別名 | 特性 | 適用階段 |
| :--- | :--- | :--- | :--- | :--- |
| **SAST** | 靜態應用程式安全測試 (Static Application Security Testing) | 白箱 (White-box) | 分析**原始碼** (Source Code)，不執行程式。 | 開發 (IDE)、建置 (Build) |
| **DAST** | 動態應用程式安全測試 (Dynamic Application Security Testing) | 黑箱 (Black-box) | 測試**執行中**的應用程式，模擬外部攻擊 (如 XSS, SQLi)。 | 測試、預生產 (QA/Staging) |
| **IAST** | 互動式應用程式安全測試 (Interactive Application Security Testing) | 灰箱 | 結合 SAST + DAST，在 App 內安裝代理 (Agent)。 | 測試 |
| **SCA** | 軟體組成分析 (Software Composition Analysis) | - | 檢查**第三方元件、開源函式庫**的已知漏洞 (CVE) 和授權問題。 | 開發、建置 |
| **Fuzzing** | 模糊測試 | - | 輸入大量隨機、無效資料以導致崩潰。 | 測試 |

### 3. 黑箱與白箱測試

| 測試方法 | 視角 | 說明 |
| :--- | :--- | :--- |
| **黑箱 (Black-Box)** | 外部 | 根據需求和預期輸出驗證；測試者不關心程式碼內部結構，只看輸入與輸出 |
| **白箱 (White-Box)** | 內部 | 驗證業務邏輯如何實作；測試者可看到程式碼與系統建構方式；常用程式碼覆蓋率與路徑覆蓋率 |
| **灰箱 (Gray-Box)** | 部分 | 結合兩者，部分了解內部結構（如 IAST） |

### 4. 弱點評估 (Vulnerability Assessment)
- 識別並報告系統中**已知**的弱點
- 通常使用自動掃描或技術組合
- 報告應附帶風險評等與潛在暴露
- 評估者通常熟悉應用程式與運行環境

### 5. 滲透測試 (Penetration Testing)
- 收集系統弱點資訊後**主動利用**（測試者扮演攻擊者）
- 與弱點評估的差異：滲透測試者只獲得有限資訊，需「盲目」發現問題
- **交戰規則 (Rules of Engagement, RoE)** 必須先簽署：詳述測試範圍、責任限制
- **法律風險**：未簽合約執行滲透測試可能觸犯刑事與民事法律；可能對被測組織造成中斷而負責

**雲端環境的滲透測試**：
- IaaS/PaaS：通常 CSP 允許客戶執行（須事先告知或申請）
- **SaaS：通常 CSP 不允許客戶測試**（應用由 CSP 全權管理，只有 CSP 可以測試）

### 6. 安全程式碼審查 (Security Code Review)
可採正式或非正式流程：
- **正式**：軟體檢查流程，含培訓團隊、角色職責、指標與品質追蹤計畫
- 整合到 SDLC 中能顯著提升整體程式碼品質

### 7. 持續安全驗證（DevSecOps）

DevSecOps 把安全團隊納入 DevOps 實踐，將「審批每個版本」轉為「審批 CI/CD 流程 + 隨時監控／稽核」。

**關鍵步驟**：
1. **IDE 中的靜態分析**：避免安全弱點被引入 CI/CD
2. **CI 建構後的靜態分析**：確保程式碼遵守維護與安全規則
3. **預生產環境的自動化滲透測試**：對運行中的應用掃描弱點
4. **基礎建設驗證**：除應用外也驗證基礎建設配置

### 8. 品質保證 (Quality Assurance, QA)
QA 確保軟體按預期運作，同時降低弱點、惡意程式碼、缺陷的風險。

**核心要求**：
- **驗證 (Verification)**：產品是否依需求正確建構（建得對嗎）
- **確認 (Validation)**：產品是否滿足實際使用者需求（建對東西嗎）
- 兩者應在 SDLC **每個階段**進行，並結合**職責分離**與獨立審查
- 應用範圍：企業自開發程式碼 + 外部 API 與服務

**檢核要點**：
- 需求是否已指定且可衡量
- 測試計畫是否全面且一致應用到所有模組
- 是否與最終產品整合

### 9. 使用案例 vs 濫用案例
- **使用案例 (Use Case)**：描述系統**應該**如何運作（正常行為）；對引出**功能需求**有幫助
- **濫用／誤用案例 (Abuse/Misuse Case)**：描述攻擊者如何**破壞**系統（惡意行為）；用於**非功能需求**特別是安全需求

**濫用案例的價值**：
- 識別針對應用程式的特定攻擊
- 評估每個攻擊的業務風險
- 開發對應的安全需求
- 確定保護措施與反制措施
- 估計對專案時間／進度／資源的影響

**需求層次結構**：使命需求 → 業務需求 → 技術需求 → 功能需求／非功能需求／使用與濫用案例

---

## 4.5 使用經驗證的安全軟體

### 1. API 安全
API 是雲端服務的「前門」，幾乎所有雲端服務存取都透過 API。**API 使用 Token 而非傳統使用者名稱／密碼**。

#### REST vs SOAP vs GraphQL

| 特性 | REST | SOAP | GraphQL |
| :--- | :--- | :--- | :--- |
| **類型** | 架構風格 | 協定標準 | 查詢語言 |
| **格式** | JSON、XML、CSV、RSS | XML（為主） | JSON |
| **方法** | HTTP（GET, POST, PUT, DELETE） | 自訂協定 | Query / Mutation |
| **安全性** | 依賴 **TLS** | 內建 **WS-Security**（訊息層級加密）+ 一系列 WS-* 標準 | 通常配合 TLS |
| **特性** | 輕量、可快取、行動裝置友善 | 強型別、ACID、企業級 | 解決 REST 的 over-fetching / under-fetching |
| **缺點** | 控制較少，需自加控制 | 訊息傳輸量大，效能較慢 | 複雜查詢可能造成 DoS |

**API 消費的安全要求**：
- **TLS（REST）或訊息層加密（SOAP）**：保護傳輸機密性
- **存取身份驗證**：使用 Token（OAuth 2.0、JWT、API Key）
- **API 使用日誌記錄**：監控異常呼叫
- **外部 API 採購**：須經過與內部軟體相同的批准流程
- **API 閘道**：集中管理速率限制、身份驗證、合約檢查

### 2. 供應鏈管理 (Supply-Chain Management)

未知血統或不確定開發流程的軟體元件容易被組合成新應用程式，形成複雜的軟體供應鏈。沒有依循 ISO/IEC 27034 等安全開發指引的元件，會在整個供應鏈引入風險。

#### 供應商評估的關鍵面向（大綱明列）

| 面向 | 評估重點 |
| :--- | :--- |
| **完整性 (Integrity)** | 軟體是否未被篡改？提供者是否有簽章驗證？ |
| **真實性 (Authenticity)** | 確認軟體確實來自宣稱的來源（數位簽章、SBOM） |
| **授權 (Licensing)** | 開源 license（GPL、AGPL）是否與商業使用相容？是否有使用限制？ |
| **供應商安全姿態** | 採用 ISO/IEC 27034 等安全開發實踐？SOC 2 / ISO 27001 認證？ |

> 詳細的供應商評估方法論見 **Domain 6.5（外包與雲端合約設計）**。

### 3. 第三方軟體管理

雲端營運中常被忽略的安全缺口：每個雲端服務都透過 **第三方軟體（CSP API）** 存取、配置與操作，但組織通常只對應用程式做白名單管理，**很少對 API 做同樣的審查**。

**應在組織治理文件中明確描述**：
- API 的審查、使用與管理流程
- 第三方軟體更新與修補的處理方式
- 授權管理：用 SCA 等工具自動比對軟體堆疊與組織授權；按處理器、核心授權的軟體在雲端可能商業上不可行，應改用該產品的雲端版本

### 4. 經驗證的開源軟體 (Validated Open-Source Software)

**核心原則**：開源 ≠ 自動安全，但也 ≠ 不安全。
- **Linus 定律**：「眼球夠多，Bug 就無所遁形」 — 但需要實際有人在看
- **誤解**：開源 ≠ 免費；許多開發者收費提供諮詢／支援
- **優勢**：多方協作、創新快、模組化、可塑性

**風險**：
- 無人維護的孤兒專案
- 惡意貢獻者植入後門
- 授權合規問題

**管理建議**：
- 只使用**經過受信任第三方驗證**的開源軟體
- **SCA 工具**持續監控 OSS 的已知漏洞 (CVE) 與 license
- 建立組織內的「開源元件白名單」與淘汰策略

---

## 4.6 雲端應用程式架構

### 0. 應用程式架構演進

從單體式應用到雲端原生：
**單體式 (Monolithic)** → **微服務 (Microservices)** → **功能 (Functions / FaaS)**

**雲端原生 (Cloud Native)** = 基於容器的環境 + DevOps/DevSecOps + CI/CD 部署到雲端，常含：
- API 閘道
- 容器註冊表
- 支援 publish-subscribe 的訊息層

### 1. 微服務
- 將單體應用 (Monolithic) 拆解為獨立的小服務。
- **優點**：獨立部署、技術異質性 (可用不同語言寫)、高擴展性。
- **通訊**：透過 API (REST/gRPC) 溝通，無狀態 (Stateless)。

### 2. 容器
- **定義**：輕量級虛擬化，共享 Host OS 的 Kernel，但打包了 App + Libs。
- **技術**：
- **Docker**：容器格式與執行環境。
- **Kubernetes (K8s)**：容器**編排**，管理部署、擴展、自癒。
- **Linux 安全機制 (隔離關鍵)**：
- **Namespaces**：隔離資源視角 (讓行程以為自己有獨立的網路、硬碟)。
- **Cgroups**：限制資源使用 (CPU/RAM 份額)。
- **Seccomp/AppArmor/SELinux**：限制行程權限與系統呼叫。
- **可攜性 (Portability)**：
- **OCI (Open Container Initiative) 映像格式**在不同雲與平台間可攜
- **但** Kernel 須相容：Linux 容器只能跑在 Linux Kernel 主機，Windows 容器只能跑在 Windows 主機；CPU 架構（x86_64 vs ARM64）也需相符或映像本身為多架構 (multi-arch)
- 實務上常需 Kubernetes 抽象層 + 多架構建置 (buildx) 才能達到「真正可攜」

### 3. 無伺服器
- **FaaS**：如 AWS Lambda。
- **特性**：事件驅動、短期存在 (Ephemeral)、無狀態、完全由 CSP 管理基礎設施。
- **安全優勢**：無須修補 OS。
- **安全挑戰**：攻擊面在 API 和程式碼，容易有「冷啟動 (Cold Start)」延遲。

### 4. 應用程式虛擬化 (Application Virtualization)

創建虛擬環境執行應用程式，本質上是與底層 OS 的封裝，可隔離或沙箱應用程式。

**主要目標**：在保護 OS 與系統其他應用的同時測試應用程式。

**範例 — App-V**：
- 應用程式被「序列化」後可在端點上的隔離記憶體泡泡中運行，**不需實際安裝**
- 序列化的應用程式彼此隔離，**消除應用程式衝突**
- 但仍能與用戶端電腦互動

**與容器的差異**：
- 容器以 OS 層級虛擬化為基礎、跨平台
- 應用程式虛擬化以單一應用為單位，常聚焦端點使用

### 5. 編排 (Orchestration)

雲端編排自動化私有雲與公有雲中工作負載的營運。

**核心功能**：
- 將任務和流程整合到工作流程中以實現特定結果
- 同時執行政策（Policy as Code）
- 減少 VM 蔓延 (VM Sprawl)
- 消除自動化的孤島傾向

**容器編排的代表**：
- **Kubernetes (K8s)**：管理部署、擴展、自癒、服務發現
- 確保容器化微服務之間的 API 連接配置正確

### 6. 沙箱 (Sandboxing)
將應用程式或程式碼在隔離的受控環境中執行，防止其影響主系統或其他應用程式。

**CSP 角度**：CSP 無法信任客戶工作負載，因此投資於沙箱技術。

**應用場景**：
- **惡意軟體分析**：執行可疑檔案，觀察行為而不危害真實環境
- **程式碼測試**：在隔離環境中測試新程式碼
- **瀏覽器沙箱**：隔離瀏覽器程序，防止惡意網頁攻擊宿主
- **第三方應用程式隔離**：限制不受信任應用的系統存取
- **資料分隔**：個人資訊、公司資訊分置於不同沙箱

**雲端中的實現**：
- 容器本身就是一種輕量級沙箱
- CSP 提供的 FaaS 環境天然具備沙箱特性
- 部分供應商提供「基於雲端的沙箱環境」做應用測試
- 可搭配安全群組和網路隔離強化沙箱邊界

### 7. 加密 (Cryptography)
雲端應用架構必須以加密保護敏感資料。

**雲端應用必須加密的常見服務類型**：
- **電子郵件應用**：Google Mail、Outlook
- **檔案共享服務**：Google Drive、SharePoint、OneDrive

**加密應用範圍**：
- **處理中的資料**（Data in Use）
- **靜態資料**（Data at Rest）
- **傳輸中的資料**（Data in Motion）

> 詳細的加密技術、金鑰管理、KMS／HSM 配置，見 **Domain 2.3（資料安全技術和策略）**。

### 8. 補充安全元件
- **WAF**：防禦 Layer 7 攻擊 (OWASP Top 10)。
- **DAM**：監控資料庫查詢行為 (SQL Injection 偵測)。
- **XML Firewall**：專門過濾 XML 流量 (SOAP API 保護)。
- **API Gateway**：集中管理 API 存取，提供驗證、速率限制、流量管理。
- **負載平衡器**：分散流量到多個後端伺服器，提供高可用性和效能最佳化。也可作為安全元件，執行 SSL/TLS 終止、DDoS 緩解和流量過濾。

---

## 4.7 身分與存取管理

### 1. 聯合身分
允許跨組織、跨網域的身分信任。
- **IdP**：身分提供者 (如 AD, Okta)。負責**驗證**。
- **RP (Relying Party) / SP (Service Provider)**：服務提供者 (如 Salesforce, AWS)。負責**授權**，信任 IdP 發出的 Token。

### 2. 關鍵協定
| 協定 | 格式 | 用途 | 備註 |
| :--- | :--- | :--- | :--- |
| **SAML 2.0** | **XML** | 企業級 SSO | 歷史悠久，主要用於 Web Browser SSO。 |
| **OAuth 2.0** | **JSON** | **授權** | 允許第三方 App 代表使用者存取資源 (不處理身分驗證)。 |
| **OpenID Connect** | **JSON** | **驗證** | 建立在 OAuth 2.0 之上的身分層，現代 App 主流。 |

### 3. 存取決策 (Access Decisions)
雲端 IAM 的核心是回答各種存取問題：
- 裝置是否可以在本地網路接收 IP？
- Web 伺服器是否可以與特定資料庫伺服器通訊？
- 使用者是否可以存取某應用、應用內功能、應用內資料？
- 應用程式是否可從另一個應用程式存取資料？

**政策決策架構**：
- **PDP (Policy Decision Point)**：政策決定點，依政策做出許可／拒絕的判斷
- **PEP (Policy Enforcement Point)**：政策執行點，靠近資源處強制執行
- **XACML (eXtensible Access Control Markup Language)**：政策傳達的標準協定

### 4. 單一登入 (SSO)
SSO 通常用於促進「跨組織、跨安全網域」的資源存取，依賴聯合身份管理。

**SSO vs RSO 的關鍵差異**：

| 項目 | SSO（單一登入）| RSO（減少登入）|
| :--- | :--- | :--- |
| 機制 | 透過聯合 IdP，憑證集中產生與驗證 | 憑證同步到多個系統 |
| 安全性 | **高**：使用者名稱與敏感資料不在網路上多次傳輸 | **較低**：同步機制本身可能洩漏 |
| 是否屬聯合 | ✓ 是聯合身份的核心 | ✗ 不屬於聯合 |

> RSO 在聯合身份系統中沒有位置 — 因為聯合的基礎依賴於 IdP 的存在。

### 5. MFA (多因素驗證)
必須包含以下 **兩種以上** 不同類型的因素（ISC2 官方僅承認三類）：
1. **Type 1（你知道什麼，Knowledge）**：密碼、PIN
2. **Type 2（你擁有什麼，Possession）**：手機、硬體 Token、智慧卡
3. **Type 3（你是什麼，Inherence）**：指紋、臉部辨識、聲紋

> **補充因素（非 ISC2 官方三因素，常稱為情境式／適應性驗證）**：
> - **位置 (Somewhere you are)**：地理位置、IP 區段
> - **行為 (Something you do)**：打字節奏、滑鼠軌跡
>
> 這些因素通常不單獨計為 MFA 的一個「factor」，而是作為 Risk-Based / Adaptive Authentication 的條件，與三大主因素搭配使用。考試請以「三類」為主答案。

#### 升級身份驗證 (Step-up Authentication)
高風險交易或政策違規時，要求**額外因素或程序**驗證身份：
- **挑戰問題 (Challenge Questions)**
- **帶外身份驗證 (Out-of-Band)**：如 Token 鑰匙圈、Authenticator App
- **動態知識型驗證**：對最終使用者獨特的問題

> 一次性密碼（OTP）也屬 MFA 範疇，特別建議用於佈建首次登入密碼時。

### 6. CASB (雲端存取安全代理)
- **功能**：位於使用者與雲端服務之間的政策執行點（本地或雲端）
- **三大用途**：
- **可見性**：發現 Shadow IT
- **細粒度控制**：應用程式存取控制
- **合規與安全**：強制 DLP、資料加密

### 7. 機密、金鑰與憑證管理

#### 機密管理 (Secrets Management)
**問題背景**：開發者歷來把資料庫密碼、API Key 等「機密」**寫死 (hard-coded)** 在應用程式中。更新時必須同時改憑證+程式碼+重新部署，且**單一憑證在多個應用中共用時極脆弱**。

**機密管理器的運作流程**：
1. **建立憑證**：DBA 建立帶適當權限的憑證
2. **儲存到機密管理器**：以特定名稱儲存；機密管理器**加密**儲存（受保護的機密文字）
3. **應用程式請求**：自訂應用透過 API 以名稱請求機密
4. **解密並回傳**：機密管理器解密後透過 **TLS over HTTPS** 安全通道回傳
5. **使用憑證**：應用程式解析憑證並存取資料庫

**主要工具**：AWS Secrets Manager、Azure Key Vault、HashiCorp Vault、Google Secret Manager

**自動輪換**：依組織政策的時間表儲存與輪換憑證，無需修改程式碼

> 用 CSP 自家機密管理器存取**該 CSP** 的產品最簡單；擴展到 CSP 外部需要更大工作量。

#### 金鑰管理
- 管理加密金鑰的完整生命週期：產生、分發、使用、輪換、撤銷、銷毀
- 工具：KMS、HSM
- 詳細請見 **Domain 2.3**

#### 憑證管理
- 管理數位憑證的簽發、更新、撤銷
- 必須監控到期日避免服務中斷
- 涵蓋類型：TLS 憑證、程式碼簽章憑證、Client 憑證
- 撤銷檢查：CRL 或 OCSP（見 **Domain 2.6**）

---

# Domain 5：雲端安全營運 (Cloud Security Operations)

> **考試權重**：17%
> **核心重點**：實體與邏輯基礎設施的建構與維運、ITIL 服務管理流程、數位鑑識 (Digital Forensics) 的挑戰與標準、以及與相關方的溝通管理。

---

## 5.1 建構和實施雲端環境的實體和邏輯基礎架構

### 1. 硬體特定的安全配置
在雲端環境中，硬體安全是信任的基礎 (Root of Trust)。

| 元件 | 功能與安全重點 |
| :--- | :--- |
| **BIOS / UEFI** | 負責啟動硬體。應啟用密碼保護，防止未經授權的修改開機順序。UEFI 支援 **Secure Boot**，驗證開機程式碼簽章。 |
| **TPM** | 安裝在主機板上的晶片。提供**硬體信任根**，用於儲存加密金鑰、密碼和數位憑證。支援 **Measured Boot** (測量開機) 以確保系統未被竄改。 |
| **HSM** | 專用的加密處理器。用於生成、保護和儲存金鑰。比 TPM 更強大，通常用於高價值金鑰管理 (如 PKI CA、金融交易)。 |

#### TPM 架構與三個信任根
依據 **ISO/IEC 11889-1:2015**，TPM 包含處理器、RAM、ROM、快閃記憶體與密碼子系統（ECC、ECDH、HMAC 等）。

**三個信任根 (Roots of Trust)** 與主機系統互動，可由 CA 外部驗證：

| 信任根 | 功能 |
| :--- | :--- |
| **測量信任根 (RTM)** | 建立新信任鏈時執行的第一組指令 |
| **儲存信任根 (RTS)** | TPM 記憶體受保護，TPM 以外實體無法存取 |
| **報告信任根 (RTR)** | 對 TPM 內選定值內容的數位簽章摘要 |

#### 虛擬 TPM (vTPM)
- 客體 OS 在 hypervisor 下無法直接存取 TPM 晶片，因此供應商建立 **虛擬 TPM** 來複製 TPM 功能
- 客戶可配置 VM 使用 vTPM 來儲存私有金鑰
- **重要警告**：vTPM 降低了實體 TPM 提供的固有信任 — 不再具備 HSM 的特殊類別保證
- 範例：Microsoft BitLocker 原本要求直接存取 TPM 晶片，但因客戶需求被改為可不依賴 TPM

#### HSM 在雲端的角色
- CSP 可發放 HSM 給客戶在雲端應用上使用客戶金鑰；**CSP 無法存取 HSM 中的金鑰**
- HSM 位置：客戶資料中心、CSP 雲端、第三方管理位置
- **非託管模式**：消費者負責設計彈性（佈建多個 HSM）；CSP 提供符合認可標準的產品
- 共享責任：CSP 確保 HSM 符合規格；消費者負責建構符合自身需求的解決方案

#### 主機伺服器最佳實踐
- **安全變更授權 (Secure Change Authority)**：透過變更控制委員會 (CAB) 授權建構流程；審查修補測試結果、供應商建議、應用程式回歸測試
- **安全建構 (Secure Build)**：遵循 OS 供應商的特定安全部署建議
- **安全初始配置 (Secure Initial Configuration)**：依 OS 供應商、操作環境、業務需求、法規、風險評估與偏好客製

### 2. 預設安全
系統和服務在部署時應預設為安全配置狀態。

**原則**：
- 預設關閉不必要的服務和連接埠
- 預設啟用加密（傳輸中和靜態資料）
- 預設使用最小權限
- 預設啟用日誌記錄和監控
- 預設密碼必須在首次使用時強制變更

### 3. 管理平面工具的安裝與配置

從 CSP 角度看，虛擬化管理工具集的安全配置是建構雲端環境最重要的步驟之一 — 管理工具被妥協將允許攻擊者**無限制存取 VM、主機與企業網路**。

**配置與營運要點**：
- **管理平面活動必須在隔離的管理網路上進行**
- 面向消費者的管理主控台 API 設計需要高保證
- 工具更新必須納入配置管理計畫
- 更新可能需要伺服器停機，部署足夠資源讓 VM 可移動
- 進行外部弱點測試
- 依供應商安全指引：特權存取管理、日誌記錄、稽核、持續改進、內外部滲透測試

### 4. 虛擬硬體配置
- **網路**：虛擬交換機 (vSwitch) 需配置 VLAN 以隔離流量。
- **儲存**：確保存儲加密已啟用，並正確配置 LUN masking。
- **CPU/Memory**：配置資源限制 (Limits) 和保留 (Reservations) 以防止 DoS 攻擊。
- **Hypervisor 類型**：Type 1（裸機，雲端主流）vs Type 2（OS 之上，雲端少見） — 詳見 Domain 3.1

### 5. Guest OS 虛擬化工具集

虛擬化工具增強或穩定 Guest OS 效能。**範例**：VMware Tools、Hyper-V Integration Services。

**通用功能**：
- 客體作業系統特定套件與功能增強（Linux／Windows／Unix）
- 裝置驅動程式清單
- 控制面板存取
- 視訊增強（解析度與深度）
- 穩定化與增強的滑鼠移動
- 時間同步、心跳檢測

**風險**：這些工具運行在較高權限，若有漏洞可能導致攻擊者提升權限

---

## 5.2 雲端環境實體與邏輯基礎設施操作與維護

### 1. 存取控制
雲端管理需依賴遠端存取，安全性至關重要。

| 存取方式 | 描述 | 安全考量 |
| :--- | :--- | :--- |
| **KVM over IP** | **帶外管理**。模擬物理存取 (鍵盤、螢幕、滑鼠)。 | 應透過獨立的管理網路存取，並嚴格限制 IP。 |
| **RDP / SSH** | **帶內管理**。透過標準網路協定存取 OS。 | 預設連接埠 (3389/22) 易受攻擊。應使用強密碼、金鑰驗證，禁止 Root 直接登入。 |
| **跳板機** | 又稱 **堡壘主機**。位於 DMZ 或管理區段的中介伺服器。 | 管理員先連到跳板機，再連到目標系統。跳板機需高度強化 (Hardened)，僅開放必要服務。 |
| **虛擬用戶端** | 透過 VDI 或遠端桌面方式存取雲端資源。 | 資料不落地，集中管理。需確保連線通道加密。 |
| **SSO** | 統一身分驗證，使用者只需登入一次即可存取多個雲端系統。 | 簡化管理但增加單點失敗風險，需搭配 MFA。 |

### 2. 網路安全配置
- **VLAN**：邏輯隔離廣播網域，雖不能完全防止攻擊 (VLAN Hopping)，但可減少攻擊面
- **VXLAN (虛擬可擴展 LAN)**：擴展傳統 VLAN 至雲端規模，支援百萬等級網段（傳統 VLAN 限 4096 個）
- **TLS**：傳輸層加密，保護管理流量 (HTTPS, SSH)；TLS 1.3 為當前版本
- **DHCP**：需防範 Rogue DHCP Server（偽造的 DHCP）攻擊；建議使用 DHCP Snooping
- **DNS 與 DNSSEC**：
- **DNS 威脅**：DNS 欺騙、快取中毒 (cache poisoning)、DNS 隧道、DDoS 攻擊
- **DNSSEC**：透過數位簽章驗證 DNS 回應的真實性，防止欺騙與中毒
- **驗證鏈**：根 → TLD → 權威 DNS，每層都簽章

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

#### TLS VPN
- 基於 TLS 1.3 的 VPN，常見 SSL VPN 實作
- 適合用戶端到企業／雲端的存取
- 不需專用 VPN 客戶端（瀏覽器即可）

#### IPsec VPN
**核心元件**：
- **AH (Authentication Header)**：提供完整性、來源驗證、抗重送；**不加密**
- **ESP (Encapsulating Security Payload)**：提供完整性、來源驗證、**加密**（機密性）
- **SA (Security Association)**：兩端對使用演算法、金鑰、生命週期的協議
- **IKE (Internet Key Exchange)**：建立 SA 的協議

**兩種模式**：

| 模式 | 加密範圍 | 使用情境 |
| :--- | :--- | :--- |
| **傳輸模式 (Transport)** | 只加密 payload，保留原 IP header | 端對端通訊 |
| **隧道模式 (Tunnel)** | 加密整個原始封包，包進新 IP header | 站對站 (site-to-site) VPN |

### 4. 網路安全控制措施

| 控制 | 說明 |
| :--- | :--- |
| **防火牆** | 基於規則過濾流量；雲端有 Layer 4-7 的 NSG／Security Group |
| **WAF (Web Application Firewall)** | 防禦 Layer 7 攻擊（OWASP Top 10）— 在 4.6 詳述 |
| **IDS** | 被動監控，發出警報（Promiscuous mode） |
| **IPS** | 主動監控，可阻斷惡意流量（Inline mode） |
| **蜜罐 (Honeypot)** | 誘餌系統，吸引攻擊者並收集情報；**不應儲存真實生產數據** |
| **NSG (Network Security Group)** | 雲端中以實例／子網層級控制流量；通常 stateful |
| **堡壘主機 (Bastion Host)** | 高度強化的中介伺服器，集中管理員存取點；位於 DMZ 或管理區段 |
| **DMZ／半信任區** | 對外服務區，與內部網路隔離 |
| **網路分段** | 限制橫向移動；含微分段（工作負載層級控制） |

### 5. 作業系統強化（基於基線監控與修復）

#### 基線配置（Baselines）
**通用指南**：
- 移除或停用不必要的服務、帳號、軟體
- 關閉未使用的連接埠
- 變更預設帳密
- 啟用主機防火牆
- 套用最小權限

**捕獲基線**：定期擷取系統當前配置作為「正常狀態」；偵測組態漂移 (Configuration Drift)

#### 主流基線標準

| 標準 | 適用 | 重點 |
| :--- | :--- | :--- |
| **CIS Controls / Benchmarks** | 通用 | 網際網路安全中心發布，分 IG1/IG2/IG3 三實施群組；針對各 OS 與服務有具體 Benchmark |
| **NIST SCAP** | 通用／聯邦 | 安全內容自動化協定，標準化弱點與配置評估 |
| **DoD STIGs** | 美國政府／高安全 | 國防資訊系統局發布的安全技術實施指南 |
| **DISA CC SRG** | 雲端（美國政府） | 雲端運算安全要求指南 |
| **CSA CCM** | 雲端 | 雲端控制矩陣，可對應多種法規與標準 |

### 6. 修補程式管理
- **流程**：評估 → **測試** → 部署 → 驗證
- **重點**：絕不可在未經測試的情況下直接部署到生產環境
- **雲端做法**：可利用藍／綠部署或不可變基礎架構（IaC 重建）降低修補風險

### 7. 基礎設施即程式碼 (IaC) 策略
- 用程式碼描述基礎設施配置（Terraform、CloudFormation、Bicep）
- 版本控制讓變更可追溯、可回滾
- 大幅降低組態漂移風險，但只要 Console / CLI / API 仍允許手動操作，漂移仍可能發生；需以政策控制（IAM 限制直接修改、Drift Detection 工具如 `terraform plan`、AWS Config）持續校驗
- 修補時直接以新映像重建工作負載，而非就地修補

### 8. 叢集主機與高可用性

| 項目 | 說明 |
| :--- | :--- |
| **高可用性 (HA)** | 主機故障時，VM 自動在另一台主機重啟 |
| **分散式資源排程 (DRS)** | 動態平衡叢集負載，將 VM 遷移到資源較空閒的主機（如 vMotion） |
| **動態優化 (Dynamic Optimization)** | 持續根據資源使用情況調整 VM 配置 |
| **儲存叢集 (Storage Clusters)** | 多個儲存節點作為單一邏輯單位；提供冗餘與效能 |
| **維護模式 (Maintenance Mode)** | 主機在進入維護前，DRS 將其上 VM 自動遷移走，達零停機維護 |
| **獨立主機可用性** | 單機部署的可用性靠備份還原；無 HA 保護 |

### 9. Guest OS 可用性
- 確保虛擬機器內的作業系統持續可用
- **措施**：安裝 Guest OS 級別的監控代理、配置自動重啟策略、確保 Guest Tools（如 VMware Tools）正常運行
- 與主機層級 HA 互補：主機 HA 處理硬體故障，Guest OS 可用性處理 OS 層級的問題

### 10. 效能與容量監控
監控雲端資源的使用情況，確保服務品質並優化成本。

**監控面向**：
- **網路**：頻寬使用率、延遲、封包遺失率
- **運算**：CPU 使用率、記憶體使用率、執行緒數
- **儲存**：IOPS、吞吐量、儲存使用率、延遲
- **回應時間**：應用程式端到端回應時間、API 延遲

### 11. 硬體監控
針對實體基礎設施的健康狀態進行監控（主要由 CSP 執行，但客戶需了解）。
- **磁碟**：S.M.A.R.T. 狀態、故障預測
- **CPU**：使用率、溫度
- **風扇轉速**：異常轉速可能表示散熱問題
- **溫度**：機房和設備溫度監控

### 12. 主機與 Guest OS 備份與還原
配置主機和虛擬機器的備份與還原功能。
- **主機備份**：Hypervisor 配置、主機設定檔
- **Guest OS 備份**：VM 快照 (Snapshot)、映像備份 (Image Backup)、檔案層級備份
- **還原測試**：定期測試還原程序，確保 RPO/RTO 可達成
- **雲端特性**：CSP 通常提供自動化備份服務（如 AWS Backup、Azure Backup），但客戶需自行配置備份策略和保留政策

### 13. 雲端管理平面（操作面）
- **scheduling（排程）**：自動化資源排程、VM 啟停、修補時段
- **orchestration（編排）**：跨服務的工作流程協調
- **maintenance（維護）**：節點維護模式、滾動升級
- **存取控管**：所有管理操作必須走管理平面 IAM、走 immutable log（如 CloudTrail/Activity Log）

---

## 5.3 實施運營控制與標準

> 新版大綱大幅擴充此節，明確列出 NIST、ISO、HIPAA、COBIT、CIS Controls、COSO、ITIL、ISO/IEC 20000-1 等框架。

### 適用的框架與標準

| 框架、標準 | 類型 | 重點 |
|----------|------|------|
| **NIST** | 美國聯邦標準 | NIST CSF (網路安全框架)、NIST SP 800 系列提供全面的安全控制指引 |
| **ISO/IEC 27001** | 國際標準 | ISMS 資訊安全管理系統的要求，可被第三方認證 |
| **ISO/IEC 20000-1** | 國際標準 | IT 服務管理系統 (SMS) 的要求，確保 IT 服務的品質 |
| **HIPAA** | 美國醫療法規 | 保護健康資訊 (PHI)，規範技術、管理和實體安全措施 |
| **COBIT** | 治理框架 | 由 ISACA 發布，IT 治理和管理的框架，連接業務目標與 IT 目標 |
| **CIS Controls** | 安全控制 | 優先排序的安全最佳實務清單，分為三個實施群組 (IG1/IG2/IG3) |
| **COSO** | 內控框架 | 企業風險管理和內部控制框架，廣泛用於財務報告和合規 |
| **ITIL** | 服務管理 | IT 服務管理的最佳實務，定義服務生命週期的各個階段 |

### 1. 變更管理
- **目標**：以受控的方式處理所有變更，降低對服務的負面影響
- **CAB**：變更諮詢委員會，負責評估、優先排序和批准變更
- **標準變更 vs 緊急變更**：
- **標準變更**：低風險、預先授權、有既定程序（如密碼重置）
- **緊急變更**：需快速反應（如修補 0-day 漏洞），通常由 ECAB (Emergency CAB) 處理

### 2. 持續性管理 (Continuity Management)
- **目標**：確保 IT 服務在中斷事件中能持續或快速恢復
- **與 BCDR 的關係**：是 ITIL 中對應 BCDR 的服務管理流程；BC（業務）+ DR（技術）+ Continuity（IT 服務）三者協同
- **關鍵活動**：
- 識別關鍵服務及其業務影響（BIA）
- 設定可接受的 RTO/RPO 目標
- 制定持續性計畫並定期測試
- 與業務持續性計畫 (BCP) 對齊

### 3. 事件與問題管理
- **事件 (Incident)**：服務的**中斷**或品質下降（如伺服器當機）。目標是**盡快恢復服務**
- **問題 (Problem)**：一個或多個事件的**根本原因**（如伺服器記憶體洩漏）。目標是**永久解決**並防止復發

### 4. 持續服務改進
- 基於 **PDCA** 循環，不斷優化服務效率與效能

### 5. 資訊安全管理
- 確保資訊的 CIA（機密性、完整性、可用性）。通常參考 **ISO/IEC 27001** 標準

### 6. 發布管理
- **目標**：規劃、排程和控制軟體與服務的發布，確保新版本在最小影響下部署到生產環境
- **關鍵活動**：版本規劃、發布測試、發布授權、發布後驗證
- **與變更管理的關係**：發布通常由變更管理觸發和授權

### 7. 部署管理
- **目標**：將新的或變更的硬體、軟體或服務元件移到生產環境中
- **部署方式**：分階段部署 (Phased)、大爆炸部署 (Big Bang)、推送 (Push) 與拉取 (Pull)
- **雲端特性**：雲端環境中部署管理通常高度自動化，透過 CI/CD 管道和 Infrastructure as Code 實現

#### 不可變 vs 可變基礎設施
| 模式 | 描述 | 範例 |
| :--- | :--- | :--- |
| **可變 (Mutable)** | 修補與配置變更直接套用到既有資源 | 傳統 OS 修補、Ansible/Chef 修改現有節點 |
| **不可變 (Immutable)** | 從新映像重新部署整批，不修改既有 | Docker 映像、AMI、Lambda 重新部署 |

雲端原生環境傾向不可變部署，因為配合 CI/CD 與 IaC 可大幅降低組態漂移；前提是禁止對運行中執行個體進行手動修改。

### 8. 配置管理
- **目標**：維護 IT 基礎設施中所有配置項目 (CI) 的資訊，確保準確性和完整性
- **配置管理資料庫 (CMDB)**：記錄所有 CI 及其之間的關係
- **雲端挑戰**：動態資源需要自動化的配置追蹤（如 AWS Config、Azure Policy）

### 9. 服務層級管理
- **目標**：協商、同意、記錄和管理 IT 服務的服務層級目標
- **服務層級協議 (SLA)**：與外部客戶約定的服務品質指標
- **營運層級協議 (OLA)**：組織內部團隊之間的支援承諾
- **支撐合約 (UC)**：與外部供應商的服務合約

### 10. 可用性管理
- **目標**：確保 IT 服務的可用性符合或超過約定的業務需求
- **關鍵指標**：可用性百分比、MTBF（平均無故障時間）、MTTR（平均修復時間）
- **設計原則**：消除單點故障 (SPOF)、使用冗餘設計

### 11. 容量管理
- **目標**：確保 IT 服務的容量在各階段都能以合理成本滿足業務需求
- **三個面向**：業務容量管理、服務容量管理、元件容量管理
- **雲端優勢**：彈性擴展 (Auto-scaling) 大幅簡化容量管理，但仍需監控以控制成本

---

## 5.4 支援數位鑑識

### 1. 數位鑑識定義
將科學應用於資料的識別、收集、檢驗和分析，同時保持資訊完整性並維護資料嚴格的監管鏈。需符合法律標準以具備證據力 (Admissibility)。

**用途**：調查犯罪／內部政策違規、重建安全事件、排除運營問題、從系統損壞中恢復。

### 2. 鑑識資料收集方法論

#### ISO/IEC 27037:2012（識別、收集、獲取、保存）
| 階段 | 說明 |
| :--- | :--- |
| **識別** | 找出潛在的證據來源（Log、VM Image、RAM、組態變更紀錄）|
| **收集** | 實體獲取設備（在雲端通常做不到，改用 snapshot）|
| **獲取** | 製作數位證據的**位元對位元**映像檔（Forensic Image）|
| **保存** | 確保證據在整個生命週期中未被竄改（Hash 驗證、防寫保護）|

#### NIST SP 800-86 三步驟獲取流程

| 步驟 | 重點 |
| :--- | :--- |
| **1. 制定獲取計劃** | 依「可能價值、易變性、所需工作量」優先排序資料來源；不一定能在時間／預算內收齊全部 |
| **2. 獲取資料** | 先收易變性記憶體資料 → 再複製非易變性資料；副本以**位元級別**製作；原始來源儲於存取受限的安全位置 |
| **3. 驗證資料完整性** | 對原始與副本各計算雜湊值（hash），比對證明未被篡改 |

#### 資料優先排序的三因素
- **可能價值 (Likely Value)**：依情境經驗估計每個來源的相對價值
- **易變性 (Volatility)**：運作中系統關機就消失（如 RAM）；非易變性也可能動態（如被覆蓋的 log）
- **所需工作量 (Effort)**：成本含人時、設備、外部專家；從路由器拿 log 比向 CSP 申請快得多

### 3. 證據的五項規則

證據要有證明價值，必須符合以下五項：

| 規則 | 要求 |
| :--- | :--- |
| **真實性 (Authentic)** | 能追溯到事發現場 |
| **準確性 (Accurate)** | 整個收集過程中保持真實未變 |
| **完整性 (Complete)** | 收集**所有**證據，含支持與削弱起訴的兩面 |
| **說服力 (Convincing)** | 對陪審團清晰易懂、可信 |
| **可採納性 (Admissible)** | 能在法庭上使用 |

### 4. 證據管理

**政策需求**：
- 制定收集與管理證據的書面政策與程序
- 注意**不要超出**法律文件請求範圍
- 法院命令可能要求 CSP 對組織保密（gag order）— 客戶可能不知道自己被調查

**披露 (Disclosure)**：
- 多租戶環境下對其他租戶的鑑識活動是否需揭露，依 SLA 而定
- 通常 CSP 對於跨租戶調查不會主動通知

### 5. 監管鏈與不可否認性
- **監管鏈定義**：詳細記錄證據從收集到法庭呈現的整個過程（誰接觸過、何時、在哪裡、做了什麼）
- **重要性**：在任何相關司法管轄區中斷監管鏈都可能使所有證據無效
- **雲端複雜度**：跨多個司法管轄區，需與每個地區的合作夥伴組織建立關係並取得認證
- **預先準備**：在需要使用之前先部署鑑識擷取工具，並備好人員、流程、資金

### 6. 雲端鑑識的挑戰
| 挑戰 | 說明 |
| :--- | :--- |
| **缺乏實體存取** | 客戶無法拔硬碟，只能依賴 CSP 提供的日誌或快照 |
| **多租戶環境** | 收集證據時不能侵犯其他租戶的隱私；傳統「整台伺服器映像」在雲端不可行 |
| **資料揮發性** | 虛擬機重啟或刪除後，RAM 和暫存資料即消失 |
| **日誌格式** | 各家 CSP 格式不一，且客戶可能沒有開啟足夠詳細的日誌 |
| **跨司法管轄** | 雲端通常涉及多國，跨境證據傳輸有法律延遲與正式流程 |
| **CSP 可能不提供** | 不能假設 CSP 提供鑑識服務；SaaS 領域才開始有開箱即用支援 |

---

## 5.5 管理與相關方的溝通

有效的溝通計畫需涵蓋 5 類對象，每類需要不同管道與內容。

### 1. 供應商 (Vendors)

**核心要求**：
- 建立並測試**緊急通訊路徑**
- 連接到 BCDR 的**優先排序**與通話清單
- 維護「依賴項與第三方依賴」的清晰簡潔清單，定期更新
- **單點故障**識別並採取行動降低
- 確認合約涵蓋風險，或提供**稽核權條款**

#### 供應鏈供應商 4 類別（依價值／重要性 + 風險影響）

| 類別 | 價值／重要性 | 風險影響 |
| :--- | :--- | :--- |
| **商品供應商 (Commodity)** | 低 | 低 |
| **運營供應商 (Operational)** | 中 | 低～中 |
| **戰術供應商 (Tactical)** | 中 | 中 |
| **戰略供應商 (Strategic)** | 高 | 高 |

> 戰略供應商需最密集的溝通與監督；商品供應商標準合約即可。

### 2. 客戶 (Customers)

**核心要求**：
- 清楚傳達**共同責任模型** — 沒明說則客戶常假設 CSP 全責
- 區分內部與外部客戶
- 說明服務消費與使用條款

#### 共同責任在不同服務模型的分界

| 服務模型 | CSP 負責 | 客戶負責 |
| :--- | :--- | :--- |
| **IaaS** | 實體層、虛擬化層 | OS、中介軟體、應用程式、資料 |
| **PaaS** | 到 OS 層 | 應用程式與資料 |
| **SaaS** | 大部分堆疊 | 資料、呈現、使用者 |
| **FaaS** | 大部分（API 閘道、佇列、日誌服務） | 程式碼、輸入驗證、IAM |

### 3. 合作夥伴 (Partners)

**識別與管理**：
- 所有合作夥伴清楚識別並記錄
- 區分聯盟 vs 非聯盟（聯盟關係有不同存取權限）

**入職流程**：
- 授予系統存取前完成徹底審查
- 文件化的入職核對表

**運作期間**：
- 在現有安全基礎設施下管理，**避免「例外存取」**
- 依組織既有政策與程序檢查存取與活動

**離職流程**：
- 明確記錄、充分溝通的離職政策
- 有效且即時終止合作夥伴對**雲端與非雲端**所有系統的存取

### 4. 監管機構 (Regulators)

**核心要求**：
- 識別關鍵接觸點與正確管道
- 規劃正式溝通的時機
- 了解所有合規要求與期望（依地理、業務類型、服務變化）

**資料外洩報告**：
- 預先批准的溝通計畫，涵蓋**監管／公共／私人**三面向
- 可能涉及多方協調：鑑識調查人員、跨司法管轄監管機構、法務、企業通訊

### 5. 其他利害關係人 (Other Stakeholders)

- **媒體與大眾**：定義公眾溝通計畫，**事件發生前**就要備好
- **公關部門**：必須在任何安全事件期間參與
- **內部員工**：尤其在大規模事件中需要正確、一致的訊息
- **股東與董事會**：重大事件可能需要正式揭露

### 6. 溝通管理通則

- 建立**單點聯繫 (SPOC, Single Point of Contact)**，通常是服務台 (Service Desk)
- 定期審查溝通計畫的有效性
- 演練各類情境（資安事件、服務中斷、合規事件）

---

## 5.6 管理安全營運

### 1. 安全營運標準與框架

SOC 的運作需建立在標準之上，並適應現代開發流程。

- **ISO/IEC 18788**：針對私人安全營運管理系統 (SOMS) 的標準
- **方法論**：採用 **PDCA** 循環
- **適用性**：特別適用於治理薄弱或受損的組織
- **DevSecOps**：SOC 文化正向 DevSecOps 轉變，特別是在雲端環境中
- **AI 與自動化**：
- **自動化工具**：適合抵禦通用型攻擊 (Generic attacks)
- **人類分析師**：適合過濾針對特定組織的攻擊
- **AI/ML 警示**：廠商常過度行銷，需進行 PoC 驗證其實際效益

---

### 2. 網路安全控制

雲端環境中最重要的流量控制機制，分為實例層級與子網層級。

| 功能特徵 | 安全群組 (Security Groups) | 網路存取控制清單 (NACLs) |
| --- | --- | --- |
| **作用層級** | **實例** 層級 | **子網路** 層級 |
| **狀態屬性** | **Stateful**：允許入站自動允許出站 | **Stateless**：入站與出站需分別設定 |
| **規則順序** | 評估所有規則 (無優先順序) | 按規則編號順序評估 (由低到高) |
| **預設行為** | 通常預設拒絕所有 (Deny All) | 視 CSP 而定 (需檢查預設是 Allow 或 Deny) |
| **主要功能** | 精細控制個別 VM 的流量 | 作為 VPC 的額外安全層 |

---

### 3. 防火牆技術

| 類型 | 描述 | 優缺點 |
| --- | --- | --- |
| **靜態封包過濾** | 檢查每個封包，不考慮會話上下文 | ❌ 無法動態適應如 FTP 這種需協商連接埠的協定，需永久開啟高風險連接埠 |
| **狀態檢測** | 觀察主機間的互動上下文 | ✅ 能識別動態連接埠協商 (如 FTP Data port)，自動允許相關連線 |
| **深度封包檢測** | 深入檢查封包內容 (Payload) | ⚠️ 能識別應用層攻擊，但效能開銷較大 |

---

### 4. 日誌管理

依據 **NIST SP 800-92** 指南進行規劃。

- **日誌收集驅動因素**：合規 (PCI)、問責性、風險管理、事件回應
- **證據保存**：
- 若日誌需作為證據，應保留 **原始日誌**、**集中日誌** 與 **解讀後數據** 的副本
- 需確保時鐘同步 (NTP) 以維持事件順序的準確性
- **成本優化 (PCI 範例)**：
- **Hot Storage**：保留少量近期資料供即時分析
- **Cold Storage**：大量歷史資料存入低成本存儲 (如 Amazon S3)，需調查時再調取

---

### 5. SIEM 與進階分析

- **SIEM 核心功能**：
- **匯總**：集中收集
- **標準化**：統一格式
- **關聯**：建立事件間的關係
- **部署模式**：
- **On-Prem**：存取方便，資料不離地
- **Cloud/SaaS**：防止日誌被地端攻擊者篡改 (Immutable)
- **下一代功能**：
- **UEBA**：利用 ML 分析異常行為趨勢
- **SOAR**：支援安全編排與自動化回應
- **威脅情報**：整合外部威脅情報來源 (如 STIX/TAXII)，豐富告警的上下文資訊，提高偵測準確率

---

### 6. 事件回應
系統性地處理安全事件的流程，目標是控制損害、保存證據和恢復服務。

**IR 生命週期** (NIST SP 800-61)：
1. **準備**：建立 IR 團隊、工具和程序
2. **偵測與分析**：識別事件並確定範圍和影響
3. **封鎖、根除與恢復**：控制損害、消除威脅、恢復系統
4. **事後活動**：記錄教訓、改進流程

### 7. 弱點評估 (Vulnerability Assessment)

作為 SOC 持續性功能的一部分。

- **目的**：識別並報告系統中**已知**的弱點
- **方法**：自動掃描或技術組合
- **報告**：附帶風險評等與潛在暴露
- **頻率**：應持續進行（不是一次性）
- **與滲透測試的差異**：弱點評估找弱點，滲透測試**主動利用**弱點驗證

> 詳細的方法論與工具見 **Domain 4.4（軟體保證和驗證）**。

### 8. 滲透測試
授權的模擬攻擊，驗證安全控制的有效性。

**雲端滲透測試注意事項**：
- **需要 CSP 授權**：大多數 CSP 有專門的滲透測試政策，部分測試類型需事先申請
- **範圍限制**：只能測試客戶自己控制的範圍，不能測試 CSP 的基礎設施
- **SaaS**：通常 CSP 不允許客戶測試（只有 CSP 自己可以）
- **合規驅動**：PCI DSS 等法規要求定期執行滲透測試
- **RoE (Rules of Engagement)**：必須先簽署，明確責任限制與範圍

### 9. 雲端監控的特殊性
- 公／私雲、IaaS／PaaS／SaaS、容器、微服務都需要監控
- **CSP 原生監控通常專有**，跨 CSP 不易整合
- **跨 CSP 工具**：New Relic、SolarWinds、PagerDuty、Datadog
- 目標：環境可見性、服務狀態洞察、最佳化

---

# Domain 6：法律、風險與合規 (Legal, Risk and Compliance)

> **考試權重**：13%
> **核心重點**：跨國法律與隱私法規 (GDPR)、電子鑑識 (eDiscovery)、第三方稽核報告 (SOC 1/2/3)、風險管理架構 (ISO 31000/NIST RMF)、以及合約管理 (SLA/MSA)。

---

## 6.1 雲端環境中的法律要求與獨特風險

### 1. 法律衝突
雲端資料可能跨越不同司法管轄區 (Jurisdiction)，導致法律適用性的衝突。
- **資料主權**：資料受其所在國家法律管轄的概念。
- **跨境資料傳輸**：例如 GDPR 限制將歐盟公民資料傳輸到隱私保護不足的國家。

### 2. 智慧財產權
保護無形資產的法律權利。
| 類型 | 保護對象 | 範例 | 雲端相關性 |
| :--- | :--- | :--- | :--- |
| **版權** | 創意的**表達形式** (Expression of ideas)。 | 軟體代碼、文件、音樂、電影。 | 保護 SaaS 應用程式、數位內容。 |
| **商標** | 品牌識別 (Brand Identity)。 | Logo、品牌名稱、標語。 | CSP 的品牌保護。 |
| **專利** | 獨特的**發明**或**方法**。 | 硬體設計、演算法、商業流程。 | 保護雲端技術創新。 |
| **營業秘密** | 具有商業價值的機密資訊。 | 客戶名單、配方 (可口可樂)、Google 搜尋演算法。 | 需採取「合理措施」保護其機密性。 |

### 3. 政策層級結構
從上到下：
**法律／法規** → **政策** → **外部標準／合約要求** → **控制基準／內部標準** → **程序** → **指引**

- **政策 (Policy)**：為回應要求（標準／法規／合約）而制定，需懲罰措施與高層支持
- **程序 (Procedure)**：完成政策指令的逐步說明
- **基準 (Baseline)**：評估政策目標是否實現的基準點
- **指引 (Guideline)**：完成任務的建議方法（非強制）

> 範例：法規可能要求**最低 8 字元密碼**；組織可訂**內部 10 字元**更嚴格政策（policies can be stricter than regulations）。

### 4. 雲端特有法律風險

- 保護 PII 的法律與法規（GDPR、HIPAA 等）
- 未經授權存取／修改／遺失受監管資料
- 未能保護資料導致的罰款與法律挑戰
- 資料主權／地理圍欄要求
- 侵權或刑事案件
- 合約責任與強制責任

### 5. 法律與法規框架

| 框架／法律 | 重點 |
| :--- | :--- |
| **OECD 隱私與安全指引** | 通用隱私原則（詳見 6.2 8 大原則） |
| **APEC 隱私框架** | 亞太地區資料自由流動與保護 |
| **GDPR** | 歐盟最嚴格隱私法，具域外效力（詳見 6.2） |
| **刑法 (Criminal Law)** | 政府禁止行為的規則；犯罪依嚴重性分類，含最低／最高處罰 |
| **侵權法 (Tort Law)** | 為他人不法行為所致損害提供補救；建立在「損害證據優勢」上；責任落在實施行為的個人 |
| **CLOUD Act** | 允許美國執法機構獲取美國公司**海外**伺服器資料；解決微軟愛爾蘭案爭議 |

#### 侵權法的四個目標
1. 補償受害者
2. 將傷害成本轉移給應負責的人
3. 阻止未來不當行為
4. 恢復受妥協的法律權利

### 6. 電子發現 (E-Discovery)

電子發現是「電子儲存資訊 (ESI) 的識別、保存、收集、處理、審查、分析、產出」。

**驅動因素**：犯罪調查、內部政策違規、意外損壞復原、法律保留、合規／法律／法規。

#### ISO/IEC 27050 七步驟流程（必背）

| 步驟 | 內容 |
| :--- | :--- |
| **1. 識別 (Identification)** | 找出與案件相關的 ESI 位置（任何媒體與平台） |
| **2. 保存 (Preservation)** | 將相關資料置於法律保留下；防止遺失／竄改／擦除；可能需從運營系統建立真實副本 |
| **3. 收集 (Collection)** | 以鑑識合理方式收集；嚴格監管鏈；位置與技術決定機制 |
| **4. 處理 (Processing)** | 在大資料集中「篩選」案件相關資訊；用不破壞原資料的鑑識工具 |
| **5. 審查 (Review)** | 搜尋與分析資料以找相關資訊；可刪除無關資訊 |
| **6. 分析 (Analysis)** | 進一步分析相關性、適用性、權重、意義 |
| **7. 產出 (Production)** | 以適當證據格式呈現，附完整性證明 |

#### 雲端電子發現的 3 種類型

| 類型 | 說明 |
| :--- | :--- |
| **基於 SaaS 的電子發現** | 用雲端工具完成電子發現任務（收集／保存／審查） |
| **託管電子發現** | 雇用託管服務提供者（可能是 CSP 自己或第三方）執行 |
| **儲存在雲端的資料** | 對已在雲端的資料做電子發現；常需第三方專業資源 |

### 7. 鑑識要求 (Forensics Requirements)
雲端環境鑑識遵循的國際標準：
- **CSA 鑑識指引**：雲端環境特有的挑戰與最佳實務
- **ISO/IEC 27037:2012**：數位證據的**識別、收集、獲取、保存**指南
- **ISO/IEC 27041:2015**：事件調查方法的**保證**指南
- **ISO/IEC 27042:2015**：數位證據的**分析與解釋**指南
- **ISO/IEC 27043:2015**：事件調查的**原則與流程**

#### 雲端鑑識挑戰
- **所有權與控制權**：客戶擁有資料但設施在 CSP 處
- **多租戶**：取證時不能侵犯其他租戶隱私
- **揮發性**：VM 重啟或刪除後 RAM／暫存即消失
- **CSP 可信度**：證據可信度部分依賴 CSP
- **技術人員資格**：收集者可能不具備鑑識資格
- **實體位置未知**：阻礙跨境法律調查

### 8. 法律保留準備
為法律保留 (Legal Hold) 與電子發現預先準備：
- **SLA／合約檢查**：確認允許對雲端資產進行調查；事先通知與接受機制
- **通訊路徑明文化**：CSP 收到法院文件後立即通知客戶
- **資料分散與抹除編碼**：一處被扣押時其他位置仍可保護資料
- **資料探索工具**：定位法律產出所需的關鍵資料
- **法律事件回應團隊**：法務 + IT + CSP 協調
- **資料保留／銷毀政策**：保留期過後有效刪除可能受電子發現約束的資料
- **第三方關係**：雲端鑑識實驗室、電子發現獲取公司、安全資料傳輸公司
- **時限管理**：避免因 CSP 資料獲取緩慢招致法院制裁
- **產出範圍**：**只**提供法院文件要求的內容，不超出
- **法律部門對外**：所有與法院／請求方／法律參與者的溝通必須透過法律部門

---

## 6.2 理解隱私要求

### 1. 隱私數據定義
- **個人可識別資訊 (PII)**：能單獨或結合其他資訊識別個人的數據（姓名、身分證號、生物特徵）
- **受保護健康資訊 (PHI)**：與健康狀況相關的數據（病歷、處方）

### 2. 合約性 vs 受監管私人資料

| 類型 | 定義 | 來源 | 範例 |
| :--- | :--- | :--- | :--- |
| **合約性私人資料 (Contractual)** | 透過合約承諾保護的資料 | 雙方契約義務（NDA、SLA、DPA） | 客戶名單、商業機密 |
| **受監管私人資料 (Regulated)** | 受法律強制保護的資料 | 法律與法規 | PII、PHI、PCI 持卡人資料 |

**處理差異**：
- 合約性違反 → 違約責任（民事）
- 受監管違反 → 法律罰款 + 強制行動 + 聲譽損害

### 3. OECD 8 大隱私原則
許多現代隱私法（如 GDPR）的基礎。
1. **收集限制**：只收集必要的資料，且需經同意
2. **資料品質**：資料應準確、完整且最新
3. **目的明確**：收集時需說明用途
4. **使用限制**：不得挪作他用（除非經同意或法律要求）
5. **安全保障**：需有適當的安全保護措施
6. **公開性**：政策應透明
7. **個人參與**：個人有權查閱和更正資料
8. **問責性**：資料控制者需負起責任

### 4. GDPR (一般資料保護規範)
歐盟最嚴格的隱私法，具備**域外效力** (Extraterritoriality)，前身為 **歐盟資料保護指令 95/46/EC**。

- **角色**：
- **資料主體**：資料所屬的自然人
- **資料控制者**：決定資料處理**目的**與**方式**的實體（通常是雲端客戶）
- **資料處理者**：代表控制者處理資料的實體（通常是 CSP）
- **關鍵權利**：
- **被遺忘權**（Right to Erasure）
- **資料可攜權**（Data Portability）
- **存取權**、**更正權**、**反對自動化決策權**
- **資料保護官 (DPO)**：特定情況下必須指派
- **罰款上限**：全球年營業額 4% 或 2,000 萬歐元（取高者）
- **通報時限**：發現資料外洩後 **72 小時** 內通知監管機構

#### 跨境傳輸機制
| 機制 | 說明 |
| :--- | :--- |
| **充分性決定 (Adequacy Decision)** | 歐盟認可某國隱私保護「充分」，可自由傳輸 |
| **標準合約條款 (SCC)** | 歐盟批准的合約範本，雙方簽署後可傳輸 |
| **約束性企業規則 (BCR)** | 跨國公司內部規則，由監管機構批准 |
| **歐盟-美國資料隱私框架** | 取代失效的隱私護盾 (Privacy Shield)，作為美歐傳輸機制 |

### 5. 各國隱私法規
| 法規 | 適用領域 | 重點 |
| :--- | :--- | :--- |
| **HIPAA** | 美國醫療 | 保護 PHI，規範 **Covered Entities**（醫院）和 **Business Associates**（CSP） |
| **FERPA** | 美國教育 | 保護學生教育紀錄；適用於接受聯邦資金的教育機構 |
| **GLBA** (Gramm-Leach-Bliley) | 美國金融 | 允許消費者選擇退出 (Opt-out) 資料共享 |
| **COPPA** | 兒童隱私 | 保護 13 歲以下兒童，需家長同意 |
| **PIPEDA** | 加拿大 | 規範私部門在商業活動中收集、使用、揭露個人資訊 |
| **Digital Personal Data Protection Act** | 印度 | 個人資料保護法 |
| **APEC 隱私框架** | 亞太地區 | 促進亞太地區資料自由流動與保護 |
| **澳洲 APPs** (Australian Privacy Principles) | 澳洲 | 13 條原則涵蓋公開、收集、處理、跨境、安全 |

### 6. 司法管轄區差異

不同國家的隱私要求可能**直接衝突**：

| 衝突來源 | 範例 |
| :--- | :--- |
| **資料居留要求** | 某些國家要求資料必須儲存在當地（俄羅斯、中國） |
| **執法存取衝突** | 美國 CLOUD Act 要求美企交出海外資料，但這可能違反 GDPR |
| **保留期限衝突** | 一個法規要求「至少保留 X 年」，另一個要求「最多保留 Y 個月」（X > Y 時無解） |
| **跨境傳輸限制** | GDPR、中國 PIPL、印度 DPDPA 都限制跨境，機制各不相同 |

**處理建議**：建立「跨管轄合規矩陣」 — 把資料分類 × 地理區域 × 適用法規列表，作為部署決策依據。

### 7. 標準隱私要求

#### ISO/IEC 27018:2019
- **針對**：作為「**PII 處理者**」的公有雲提供商
- **基於**：ISO/IEC 27002（資訊安全控制）+ 27017（雲端安全）的擴充
- **內容**：在公有雲中保護 PII 的控制與指引
- **價值**：CSP 取得認證後，CSC 可作為「CSP 確實保護 PII」的合理保證

#### GAPP (Generally Accepted Privacy Principles)
由 AICPA 與 CICA 制定的**通用隱私十大原則**：
1. 管理（責任與權限）
2. 通知（隱私政策告知）
3. 選擇與同意
4. 收集（限於目的所需）
5. 使用、保留與處置
6. 存取（個人可查閱／更正）
7. 揭露給第三方
8. 安全（保護未授權存取）
9. 品質（準確、完整）
10. 監控與執行（合規驗證）

#### 隱私等級協議 (PLAs)
- 雲端 SLA 的隱私版本
- CSP 對 PII 處理方式（透明度、目的、保留、刪除）的書面承諾
- 由 CSA 推動的標準格式

### 8. 隱私衝擊評估 (PIA)
在系統開發或流程變更之前，系統性地評估對個人隱私的潛在影響。

**目的**：
- 在專案初期識別隱私風險，而非事後補救
- 確保符合隱私法規要求（如 GDPR 要求的 DPIA）
- 建立利害關係人對隱私保護的信心

**評估流程**：
- 描述資料處理活動的性質、範圍和目的
- 評估資料處理的必要性和比例原則
- 識別和評估對資料主體的風險
- 確定緩解風險的措施
- 記錄評估結果和決策

**GDPR 中的 DPIA (Data Protection Impact Assessment)**：
- 當資料處理「可能導致高風險」時為**強制性**要求
- 涵蓋大規模的系統性監控、敏感資料處理、自動化決策等情境
- 必須諮詢 DPO（若已任命）
- 高風險未能緩解時，須事先諮詢監管機構

---

## 6.3 稽核流程、方法論及雲端環境調適

### 1. 內部 vs 外部稽核控制

| 類型 | 執行者 | 目的 |
| :--- | :--- | :--- |
| **內部稽核** | 組織內部稽核團隊（獨立於業務單位） | 自我檢視合規與控制有效性；持續改進 |
| **外部稽核** | 獨立第三方稽核機構（如 CPA 事務所） | 提供對外可信的合規證明；通常為合規／法規要求 |

**雲端特殊性**：客戶無法直接稽核 CSP 的基礎設施，必須**依賴 CSP 提供的第三方稽核報告**（SOC、ISO 27001、CSA STAR）。

### 2. 稽核報告類型
雲端客戶主要依賴第三方稽核報告來評估 CSP。

#### 服務組織控制 (SOC) 報告
由 AICPA（美國會計師協會）定義，共 4 種類型。

| 報告類型 | 目標受眾 | 內容重點 | 適用場景 |
| :--- | :--- | :--- | :--- |
| **SOC 1** | 財務部門、稽核員 | **財務報告**相關的內部控制 (ICFR) | 客戶需進行財務報表稽核時 |
| **SOC 2** | 管理層、監管機構、客戶 | 基於 **Trust Services Criteria** 五原則：安全性、可用性、處理完整性、機密性、隱私性 | 詳細評估 CSP 的安全性與營運狀況（需簽 NDA） |
| **SOC 3** | **大眾** | SOC 2 的摘要版，無敏感細節 | 行銷用途，放在官網供下載「Seal of Approval」 |
| **SOC for Cybersecurity** | 董事會、投資人、監管機構 | 組織整體網路安全風險管理計畫的有效性 | 高層級風險治理證明 |

#### Type 1 vs Type 2
- **Type 1**：**時間點**的設計有效性。驗證控制措施是否設計良好
- **Type 2**：**一段時間**（通常 6-12 個月）的執行有效性。驗證控制措施是否持續有效運作。**更有價值**

### 3. 稽核要求的影響
雲端中稽核複雜度增加：
- 多租戶共享環境難以區隔不同客戶的稽核範圍
- CSP 不會為每個客戶執行客製稽核 → 提供「共通」報告供所有客戶共用
- 客戶必須評估 CSP 報告涵蓋是否符合**自己的**法規與業務需求

### 4. ISO 標準
| 標準 | 描述 |
| :--- | :--- |
| **ISO/IEC 27001** | ISMS（資訊安全管理系統）的**要求**。可被驗證／認證 |
| **ISO/IEC 27002:2022** | 資訊安全控制的**實務守則**。提供 93 項控制指引，不可被認證 |
| **ISO/IEC 27017** | **雲端服務**的資訊安全控制指引（基於 27002 的擴充） |
| **ISO/IEC 27018** | 公有雲中 **個資 (PII)** 保護的實務守則 |
| **NIST SP 800-53** | 美國聯邦資訊系統的安全與隱私控制 |

### 5. CSA STAR
- **Level 1**：**自我評估**。基於 CAIQ 或 CCM
- **Level 2**：**第三方認證**。結合 ISO 27001 或 SOC 2
- **Level 3**：**持續監控**

### 6. 差距分析 (Gap Analysis)
識別目前安全狀態與期望狀態之間的差距。
- **控制分析 (Control Analysis)**：評估現有控制措施是否符合標準要求
- **基線比較 (Baseline)**：將現狀與安全基線標準進行比較
- **風險與控制自評 (RCSA)**：由業務單位自行評估面臨的風險與控制有效性；是一種前瞻性的風險識別方法

### 7. 稽核範圍限制
- **SSAE**：美國 AICPA 的認證標準，SOC 報告依此標準執行
- **ISAE**：國際稽核與保證標準委員會（IAASB）的國際標準
- **範圍限制的意義**：SOC 報告只涵蓋**特定時間段內、特定控制目標**的稽核結論。客戶必須仔細閱讀報告的範圍聲明，確認其涵蓋自己關心的服務和控制
- **常見遺漏**：某些 CSP 服務可能不在報告範圍內；客戶誤以為「整個 CSP 都符合 SOC 2」

### 8. 稽核規劃流程
- 確定稽核目標、範圍、時程和資源
- 識別關鍵風險領域和優先審查項目
- 建立與 CSP 的溝通和配合機制
- 確認稽核方法論（如基於風險的稽核方法）

### 9. 內部 ISMS 與控制系統
- **資訊安全管理系統 (ISMS)**：基於 ISO/IEC 27001，建立系統性的資訊安全管理方法，包含政策、程序、技術控制和人員管理
- **內部資訊安全控制系統**：組織內部實施的安全控制措施集合，涵蓋預防性、偵測性和矯正性控制

### 10. 政策層級
- **組織政策 (Organizational)**：高層級的安全方針，由管理階層核准，定義安全目標與方向
- **功能政策 (Functional)**：針對特定功能領域的政策（如存取控制政策、事件回應政策）
- **雲端運算政策 (Cloud Computing)**：專門針對雲端服務使用的政策，包括可接受的雲端服務類型、資料分類要求、CSP 選擇標準等

### 11. 識別與參與相關利害關係人
稽核必須涵蓋與安全結果相關的所有利害關係人：
- **內部**：高階管理層、業務單位、IT、法務、財務、稽核委員會
- **外部**：客戶、合作夥伴、CSP、監管機構、第三方稽核員、保險業者
- **參與時機**：需求識別、控制設計、稽核規劃、結果審查、改進計畫

### 12. 虛擬化與雲端的保證挑戰
- 稽核人員可能無法直接存取底層基礎設施
- 多租戶環境下的稽核範圍界定困難
- 動態資源配置使傳統的靜態控制驗證方法受限
- 需要依賴 CSP 提供的稽核報告（如 SOC 2）作為替代保證
- CSP 通常**不允許客戶現場稽核**，僅能透過稽核報告

### 13. 高度受監管行業的特殊合規要求
| 法規／標準 | 產業 | 重點 |
| :--- | :--- | :--- |
| **NERC CIP** | 北美電力 | 關鍵基礎設施保護，規範電力系統的網路安全控制 |
| **HIPAA** | 美國醫療 | PHI 保護，技術／管理／實體安全措施 |
| **HITECH Act** | 美國醫療 | 擴大 HIPAA 的執法範圍，增加資料洩露通知要求和罰則 |
| **PCI DSS** | 支付卡產業 | 保護持卡人資料，12 項安全要求 |

### 14. 分散式 IT 模型的影響
- 雲端資源可能分散在不同地理位置，跨越多個法律管轄區
- 需要協調不同區域的合規要求和稽核標準
- 資料主權問題影響稽核範圍和方法
- 分散式架構讓「集中稽核」變得困難 — 證據可能分散在多個服務、多個帳戶、多個區域

---

## 6.4 雲端企業風險管理

### 1. 風險管理框架

| 框架 | 重點 |
| :--- | :--- |
| **ISO 31000:2018** | 風險管理的原則與指引（通用框架，不限資安） |
| **ISO 27000 系列** | 資安風險管理（27001 ISMS、27005 風險管理） |
| **NIST SP 800-37 r2** | 風險管理框架 (RMF)，6 步驟：Categorize → Select → Implement → Assess → Authorize → Monitor |
| **NIST CSF (Cybersecurity Framework)** | 自願性框架，廣泛採用 |
| **FedRAMP** | 美國聯邦雲端服務的風險管理計畫 |

#### NIST CSF 三組件

| 組件 | 說明 |
| :--- | :--- |
| **框架核心 (Core)** | 6 大功能：Govern、Identify、Protect、Detect、Respond、Recover（CSF 2.0 新增 Govern）|
| **實施層級 (Implementation Tiers)** | Tier 1 部分→ Tier 4 適應；描述組織風險管理嚴謹度 |
| **框架概況 (Profile)** | 組織的「目前」與「目標」風險管理狀態，用於差距分析 |

### 2. 風險處理策略

5 種風險處理選項（注意：transfer 與 share 略有不同）：

| 策略 | 描述 | 範例 |
| :--- | :--- | :--- |
| **規避 (Avoid)** | 停止產生風險的活動 | 不使用公有雲處理機密資料 |
| **緩解 (Mitigate)** | 降低發生的可能性或影響 | 實施加密、防火牆、MFA |
| **轉移 (Transfer)** | 將風險的財務或營運責任轉嫁第三方 | 購買網路保險、外包整個業務功能 |
| **分擔 (Share)** | 與另一方共同承擔風險（雙方各自仍保有部分風險） | 共享責任模型 (CSP / CSC)、合資企業 |
| **接受 (Accept)** | 接受風險的存在（通常處理成本 > 潛在損失時） | 簽署接受風險聲明 |

> **重要**：法律與聲譽責任**無法完全轉移**或分擔；最終責任仍在資料控制者身上。

### 3. 資料角色
- **資料所有者**：對資料負最終責任，負責分類資料。
- **資料控制者**：決定處理目的 (通常是客戶)。
- **資料保管者**：負責執行安全控制 (備份、加密)。
- **資料處理者**：代表控制者處理資料 (通常是 CSP)。
- **資料管理員**：負責日常資料品質管理，確保資料的準確性、一致性和合規性。通常是特定業務領域的資料治理執行者，介於 Owner 和 Custodian 之間。

### 4. 評估供應商風險管理程序
評估 CSP 的風險管理成熟度，包括：
- **控制措施**：CSP 實施了哪些安全控制
- **方法論**：CSP 使用的風險評估方法
- **政策**：CSP 的安全政策是否完善
- **風險剖繪**：CSP 面臨的主要風險類型
- **風險胃納**：CSP 願意接受的風險程度

### 5. 法規透明度要求
- **資料洩露通知**：各法規要求在發現資料洩露後的特定時間內通知受影響者和主管機關（如 GDPR 要求 72 小時內通知）
- **SOX**：美國上市公司的財務報告透明度法規，要求管理階層對財務報告中的內部控制有效性進行評估和認證
- **GDPR 透明度原則**：資料處理活動必須對資料主體透明

### 6. 風險管理指標

#### 質性指標
- **KRI**：關鍵風險指標，用於預警風險水準的變化（如未修補的高風險漏洞數量）
- **KPI**：關鍵績效指標，衡量安全控制的執行效能（如平均修補時間）
- **殘餘風險 (Residual Risk)**：實施控制措施後仍存在的風險水準
- **風險胃納 (Risk Appetite)** vs **風險容忍度 (Risk Tolerance)**

#### 量化指標（必背公式）

| 縮寫 | 全名 | 公式／意義 |
| :--- | :--- | :--- |
| **AV** | Asset Value 資產價值 | 資產總值（金額） |
| **EF** | Exposure Factor 暴露因子 | 單一事件造成的損失百分比（0%~100%）|
| **SLE** | Single Loss Expectancy 單次損失預期 | **SLE = AV × EF** |
| **ARO** | Annualized Rate of Occurrence 年化發生率 | 每年預期發生的次數（如 0.1 = 10 年一次）|
| **ALE** | Annualized Loss Expectancy 年化損失預期 | **ALE = SLE × ARO** |

**範例**：
- 資料庫資產 AV = $1,000,000
- 資料外洩 EF = 30% → SLE = $300,000
- 預期 5 年發生 1 次 → ARO = 0.2
- ALE = $300,000 × 0.2 = **$60,000/年**

> 控制措施的成本應**低於**降低 ALE 的金額才合理（成本效益分析）。

### 7. 風險環境評估
從不同面向系統性地評估風險：
- **服務風險**：雲端服務的可用性、效能和安全性風險
- **供應商風險**：CSP 的財務穩定性、合規性和服務持續性風險
- **基礎設施風險**：底層基礎設施的技術風險和韌性
- **業務風險**：對業務營運、聲譽和合規的潛在影響

---

## 6.5 外包與雲端合約設計

### 1. 業務需求與 SLR / SLO

- **業務需求 (Business Requirements)**：規劃外包前必須先確定要外包什麼、具體要求是什麼；區分「需要的」與「想要的」
- **服務等級需求 (SLR)**：從**雲端消費者角度**所需的服務水準
- **服務等級目標 (SLO)**：CSP 為一個或多個雲端服務發布的服務等級產品
- 評估時：將 SLR 與 SLO 進行比較，找最佳匹配

### 2. 合約文件類型

| 文件 | 全名 | 重點 |
| :--- | :--- | :--- |
| **CSA** | Cloud Service Agreement | 雲端服務客戶與 CSP 關係的整體文件（也叫主協議、服務條款） |
| **MSA** | Master Service Agreement | 通用條款條件（付款、保密、終止），適用於多個 SOW |
| **SLA** | Service Level Agreement | 具體服務品質指標（如 99.9% 可用性）與違約賠償 |
| **SOW** | Statement of Work | 特定專案的範圍、交付物與時程 |
| **AUP** | Acceptable Use Policy | CSP 限制／禁止雲端服務不當或非法使用；通常包含於 CSA 中 |

> **CSP 主協議的偏向性**：通常由 CSP 法務撰寫保護供應商，可能對客戶保護有限。**主觀條款**的 AUP 風險特別大（CSP 可單方面決定何為「不可接受」）。

#### CSA 評估要點
- 了解雙方角色責任
- 評估業務政策是否符合需求
- 了解服務／部署模型差異
- 確定 KPI、安全與隱私要求
- 為服務失敗做好準備
- 了解 CSP 災難復原計畫如何與客戶 BC/DR 互動
- 建立有效的治理流程
- 了解合約終止時的退出流程
- 監控 CSP 單方面對協議的變更（「繼續使用即同意」）

#### SLA 詳細涵蓋項目
- 服務可用性與性能
- 資料安全與隱私
- 事件回應與災難復原程序
- 基礎設施細節與安全標準
- 客戶稽核權
- 資料位置、存取、可攜性
- 變更管理與爭議調解
- 退出策略與終止成本

**ISO/IEC 19086 系列**（SLA 框架）：第 1 部（概述）、第 2 部（指標）、第 3 部（核心要求）

### 3. 供應商管理

#### 供應商分類

| 類別 | 性質 |
| :--- | :--- |
| **戰略供應商 (Strategic)** | 關鍵任務，無法輕易替換；少數但對企業成敗至關重要 |
| **戰術供應商 (Tactical)** | 補充戰略與商品供應商，管理不可預見問題 |
| **商品供應商 (Commodity)** | 提供易替換的商品服務，可從多家採購 |

#### 供應商評估 (Vendor Assessment)
- **時機**：服務獲取**前**（選擇最佳供應商）+ 實施**後**定期（確保持續滿足要求）
- **內容**：
- 認證與安全控制是否仍維持
- 控制框架未涵蓋的因素與歷史表現
- 風險剖繪、風險胃納
- 控制措施、方法論、政策

#### 供應商可行性 (Vendor Viability)
- 供應商支援組織業務需求的能力可能隨時間變化
- **重新評估時機**：定期（與風險評估更新或合約維護同步），頻率視風險水準與業務／服務波動性而定
- **評估項目**：財務穩定性、合規性、服務持續性、未來能力預測

#### 供應商鎖定 (Vendor Lock-in)
過度依賴單一供應商，無法輕易遷移到另一家。

**潛在風險**：
- 服務無法滿足不斷變化的業務需求
- 服務品質下降
- 服務隨時間更新後變得不再適合
- 價格變動
- 供應商倒閉
- 非自願下架
- 其他供應商有更好選擇

**解法**：標準介面、容器化、多雲策略、IaC 跨平台部署

#### 託管 (Escrow)
第三方持有或保護某些有價值的東西，以保護協議中各方的利益。

**雲端範例**：
- 客戶用地端 KMS 加密放雲端的資料；擔心 KMS 故障會導致資料無法存取
- 解法：找**另一家** CSP 的金鑰託管服務 — 兩家 CSP 都不能單獨存取加密資料
- 也可用於：原始碼託管（CSP 倒閉時客戶可拿到原始碼）、合約終止時的資料保管

### 4. 合約管理

合約是雙方爭議時**唯一的**法律文件。對雲端供應商的初步審查應確定：
- 滿足要求的能力
- 初步溝通管道
- 雙方責任清楚分離
- 報告合規的能力
- 違約處罰

#### 典型合約條款
- **稽核權**：客戶或代表的審查權；包含允許頻率
- **指標與定義**：明確定義 SLA 指標如何計算
- **終止條款**：資料退還、銷毀程序
- **訴訟**：管轄權、爭端解決機制
- **保證**：CSP 提供的可信保證水準
- **合規**：CSP 須符合的法規與標準
- **資料存取**：誰可在什麼條件下存取資料
- **網路風險保險 (Cyber Risk Insurance)**：保險範圍與限額
- **資料所有權**：明確歸屬客戶
- **安全要求**：CSP 須遵循的標準與控制
- **績效衡量**：誰負責報告？
- **事件回應**：解決時間框架、最大可容忍中斷期間、調查證據處理
- **控制與合規框架**：ISO 27001/2、PCI DSS、HIPAA、GLBA、GDPR、CLOUD Act
- **BC/DR**：恢復優先順序、最低可用性、第三方 BCDR 流程使用
- **人員審查**：員工與第三方承包商的背景調查
- **資料保留與處置**：保留期限、銷毀規則
- **變更管理**：升級、修補管理程序
- **存取控制**：MFA、密碼、帳戶管理、佈建／撤銷程序
- **限制與禁止**：CSP 未經同意不得使用客戶資料

### 5. 盡職注意 vs 盡職調查

| 概念 | 定義 | 性質 |
| :--- | :--- | :--- |
| **盡職注意 (Due Care)** | 合理且謹慎的人在情境中會表現的「合理行為標準」 | 持續的**行為**標準（每天的實踐） |
| **盡職調查 (Due Diligence)** | 為調查與理解公司面臨風險的行動；確保政策正確應用、控制有效 | 系統性的**調查**活動 |

> 一句話區分：**盡職調查**確保**盡職注意**始終被執行；前者是調查行為、後者是日常實踐。

#### 盡職調查不足的後果
雲端遷移常為「倉促」決定 — 在徹底風險審查前就行動，導致：
- 角色、治理、稽核、報告等運營要素變化未被妥善處理
- 安全架構未經完整思考即實施

> 雲端安全專業人員有責任確保**盡職注意與盡職調查同時行使**。

### 6. 供應鏈管理

雲端運算高度依賴第三方與供應商鏈。**ISO/IEC 27036-4:2016** 提供供應商關係的雲端服務安全指南。

#### 雲端供應鏈的特性
- **多層**：客戶 → SaaS → IaaS → 軟體開發商；每層都可能不為下層客戶可見
- **跨境風險**：底層參與者可能在不同管轄區，引入跨境法律問題
- **可見性挑戰**：客戶可能不知道自家 SaaS 服務跑在哪家 IaaS 上

#### 管理重點
- **持續更新依賴關係清單**：含主要供應商的對應與單點故障識別
- **以 BCDR 心態審視**：哪些第三方故障會讓你業務停擺？
- **合約審計權條款**：透過合約確保有「衡量供應鏈風險」的工具
- **快速優先排序**：當有上百份合約時，需有方法快速分類風險

---

## 參考資料

> **Classroom-Based CCSP Official ISC2 Textbook, 5th Edition**
>
> **CSA Security Guidance for Critical Areas of Focus in Cloud Computing v5**（CCSK v5 補充參考來源）
>
> **ISO/IEC 22123 系列**（雲端運算詞彙、概念、參考架構，22123-1、-2、-3）
>
> **NIST SP 800-145**：[The NIST Definition of Cloud Computing](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-145.pdf)（雲端運算官方定義；筆記 1.1「雲端運算定義」、「雲端運算基本特性」的來源）
>
> **NIST SP 500-292**：[NIST Cloud Computing Reference Architecture](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication500-292.pdf)（雲端參考架構；筆記 1.1「雲端服務代理」三大模式、Cloud Broker 與 Cloud Auditor 角色的來源）
>
> **NIST SP 800-88r2**：[Guidelines for Media Sanitization](https://doi.org/10.6028/NIST.SP.800-88r2)（2025/9 發布；筆記 1.3「加密抹除」、「DoD 7 次覆寫對 SSD 為何不適用」、邏輯、虛擬儲存的 purge 唯一可行技術等討論的依據）