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

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

---

## 1.1 了解雲端運算概念

### 雲端運算定義

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

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

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

---

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

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

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

### 3. 雲端服務合作夥伴
- **定義**：支援或輔助 CSP 或 CSC 的一方。
- **常見類型**：
- **雲端稽核員**：獨立評估雲端服務的安全性、隱私與效能。
- **雲端開發者**：為雲端環境開發軟體或服務元件。

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

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

---

### 雲端運算基本特性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

### 構建區塊技術

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

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

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

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

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

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

**儲存一致性**：
- **嚴格一致性**：所有副本在交易完成前已同步
- **最終一致性**：資料變更最終會傳播到所有副本（效能較好但有延遲）

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

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

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

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

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

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

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

---

## 1.2 描述雲端參考架構

### 雲端運算活動

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

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

設計、建立和維護服務組件
        ↓
    組合服務（整合現有服務創造新服務）
        ↓
    測試服務
        ↓
    執行稽核 → 報告稽核結果
        ↓
    獲取和評估客戶、評估市場
        ↓
    建立法律協議

#### 雲端服務客戶 (CSC) 的活動

選擇和購買服務
        ↓
    執行服務試用
        ↓
    使用雲端服務活動
        ↓
    監控服務（確保符合 SLA）
        ↓
    管理服務安全（資料備份、加密、PII 處理）
        ↓
    處理問題報告、管理租戶、執行業務管理
        ↓
    請求稽核報告
        ↓
    將 ICT 系統連接到雲端服務

#### 雲端服務提供者 (CSP) 的活動

準備系統、定義環境和流程
        ↓
    部署和配置服務、提供服務
        ↓
    監控和管理服務、管理資產和庫存
        ↓
    執行服務層級管理（遵守 SLA）
        ↓
    管理業務計畫、管理財務處理
        ↓
    處理客戶請求、管理對等雲端服務
        ↓
    管理安全和風險、確保合規
        ↓
    設計和實作服務持續性
        ↓
    提供網路連接、交付網路服務、提供網路管理服務
        ↓
    提供稽核資料

---

### 雲端服務能力類型

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

**責任比較圖**：

                    SaaS          PaaS          IaaS
應用程式              CSP           客戶           客戶
資料                 客戶           客戶           客戶
執行環境              CSP           CSP           客戶
中介軟體              CSP           CSP           客戶
作業系統              CSP           CSP           客戶
虛擬化               CSP           CSP           CSP
伺服器               CSP           CSP           CSP
儲存                 CSP           CSP           CSP
網路                 CSP           CSP           CSP

---

### 雲端部署模型

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 💡 **實務觀察**：許多企業目前實施的是「混合多雲」環境，同時使用多個公有雲、私有雲和社群雲服務。

---

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

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

#### 關鍵共享考量

| 考量 | 說明 | 重要性 |
|------|------|--------|
| **互通性** | 雲端生態系統的組件能協同工作 | 確保不同來源的組件可替換並繼續工作 |
| **可攜性** | 應用程式和資料能輕鬆移動到其他平台 | 防止供應商鎖定，支援災難復原 |
| **可逆性** | 客戶能檢索資料，CSP 能完全刪除客戶資料 | 合約終止時的資料處理 |
| **可用性** | 系統和資源隨時可用 | 雲端服務的單點故障，通常要求 99%+ 可用性 |
| **安全** | 保護資料和系統免受威脅 | 仍是客戶最大的單一顧慮 |
| **隱私** | 符合各地資料保護法規 | 資料可能跨多個地理位置，涉及不同法規 |
| **彈性** | 在中斷事件中繼續運營的能力 | 多層冗餘、故障轉移機制 |
| **效能** | 網路、運算、儲存和資料的效能最佳化 | 直接影響使用者體驗 |
| **治理** | 定義行動、分配責任和驗證效能 | 是持續性活動，需定期審查 |
| **維護和版本控制** | 對服務進行更改以修復故障或升級 | 確保客戶知道正在使用的版本 |
| **合規** | 遵守法律、法規和企業政策 | 違規可能導致法律訴訟、罰款 |
| **可稽核性** | 提供足夠的證據支援審查和調查 | 系統和流程會失敗，需要追溯能力 |
| **監管** | 遵守法定、監管和法律要求 | 因市場部門和司法管轄區而異 |
| **服務層級協議** | CSP 和 CSC 之間的服務品質協議 | 定義可衡量的服務層級和違約處理 |
| **外包** | 服務可能涉及多層供應鏈 | 需了解供應鏈以識別潛在風險 |

---

### 相關技術的影響

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

#### 資料科學 (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）的強度
- 需要關注後量子密碼學的發展

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

**範例**：
- 內容分發網路 (CDN)：將內容分發到全球各地的邊緣伺服器
- IoT 閘道器：在邊緣處理資料後再上傳到雲端

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

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

---

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

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

### 密碼學和金鑰管理

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

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

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

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

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

**生命週期階段**：

建立 → 發行 → 分發 → 使用 → 撤銷 → 恢復 → 銷毀

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

---

### 身份和存取控制

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

#### 身份生命週期

身份配置 (Provisioning)
        ↓
    身份識別 (Identification) - 主體聲明身份
        ↓
    驗證 (Authentication) - 驗證聲明的身份
        ↓
    授權 (Authorization) - 確定允許的動作
        ↓
    存取控制 (Access Control) - 允許/拒絕存取
        ↓
    記帳 (Accounting) - 記錄所有存取嘗試
        ↓
身份取消配置 (Deprovisioning)

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

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

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

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

**最佳實踐**：
- 只在需要時授予存取權限
- 不再需要時自動撤銷
- 增強的日誌記錄和監控
- 使用特權存取管理 (PAM) 工具
- 強制使用多因素驗證 (MFA)

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

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

---

### 資料和媒體清理

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

#### 清理方法比較

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

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

**執行要點**：
- 資料應完全加密，不留任何明文
- 必須確保加密金鑰完全不可恢復
- 如果第三方管理金鑰，這可能難以實現
- 單獨銷毀金鑰不是全面方法（金鑰可能用鑑識技術恢復）

> 💡 **最佳實踐**：擦除每個區塊，用已知模式覆寫所有內容，然後再次擦除。

---

### 網路安全

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

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

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

#### 網路安全群組 (Network Security Groups)
控制雲端中哪些實體可以透過虛擬網路與其他實體互動。

**功能**：
- 明確允許或拒絕實體之間的連接
- 定義與外部網路之間允許的通訊
- 類似於傳統網路中的分區和防火牆規則

**風險**：不當配置可能對雲端安全產生不利影響

#### 流量檢查 (Traffic Inspection)
分析網路流量以確定是否被允許、格式正確、沒有惡意軟體。

**挑戰**：
- 如果使用端到端加密，資料負載可能無法分析
- 現代通訊協定（如 TLS 1.3）的前向安全機制使檢查更困難
- 需要在適當位置放置感測器

#### 地理圍欄 (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 計畫

---

### 業務衝擊分析

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

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

### 成本效益分析

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

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

### 投資報酬率

雲端經濟節省可透過以下 KPI 衡量：

| KPI | 說明 |
|-----|------|
| 工作負載與利用率百分比 | 資源使用效率 |
| 工作負載類型配置 | 資源分配優化 |
| 執行個體與資產比率 | 虛擬化效益 |
| 生態系統可選性 | 選擇或更換 IT 提供者的靈活性 |

---

### 功能性安全需求

#### 可攜性 (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 日到期
- 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) 是雲端中最有效的方法。
### 資料分散

將資料儲存在多個位置的技術，以提高可用性或安全性。

- **複製**：在不同位置儲存完整的資料副本（主要用於可用性）。
- **抹除編碼**：將資料分解成區塊並添加同位檢查位元 (Parity)，類似 RAID 但更複雜。只要取得最小數量的區塊子集即可恢復資料。
- **位元分割**：將資料加密後分割成碎片，分散儲存於不同雲端服務中。這降低了單一 CSP 被入侵導致資料外洩的風險。

### 資料流

描述資料如何在系統、服務或位置之間移動（實體或邏輯）。

- **重點**：必須繪製資料流圖，了解資料在靜態 (At Rest)、使用中 (In Use) 和傳輸中 (In Motion/Transit) 的狀態，以應用適當的控制措施（如加密協定 HTTPS、TLS）。

---

## 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. **未經授權的使用/存取**：帳戶劫持、權限配置錯誤。
2. **資料外洩/洩露**：多租戶環境下的旁路攻擊或 CSP 員工存取。
3. **阻斷服務**：影響資料可用性。
4. **資料損壞/銷毀**：人為錯誤或惡意攻擊。
5. **惡意軟體**：雲端儲存成為惡意軟體散佈點（如同步受感染檔案）。

---

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

> **考試權重**：高
> **核心考點**：加密類型選擇、KMS 部署模式 (BYOK)、HSM vs TPM、PKI 生命週期、遮罩與權杖化的差異。

### 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. 雜湊
- **目的**：確保 **完整性** 和 **不可否認性**。
- **特性**：單向 (不可逆)、抗碰撞 (Collision Resistance)。
- **演算法**：SHA-256 (安全), MD5/SHA-1 (不安全)。

**主要應用**：
- **資料完整性驗證**：下載檔案後比對雜湊值，確認傳輸過程中未被竄改
- **不可否認性**：結合數位簽章，雜湊值可證明訊息確實由特定發送者產生，發送者無法否認
- **密碼儲存**：儲存密碼的雜湊值而非明文
- **鑑識用途**：製作證據映像後計算雜湊值，確保證據未被篡改

---

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

---

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

---

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

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

---

### 6. 資料去識別化
- **匿名化**：**不可逆**。移除所有連結，資料**不再受 GDPR 管轄**。
- **假名化**：**可逆** (有對照表)。**仍受 GDPR 管轄**，但風險較低。

---

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

#### 機密管理 (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)。 |

---

## 2.4 實施資料探索

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

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

### 2. 資料探索方法
- **元資料分析**：檢查檔案屬性 (建立時間、擁有者、副檔名) 而不檢查內容。速度快但準確度低。
- **內容分析**：深入檢查檔案內容。
- **模式匹配**：使用正規表示式 (Regex) 搜尋特定格式 (如身分證號、信用卡號)。
- **關鍵字搜尋**：搜尋敏感字詞 (如 "Confidential", "Salary")。
- **標籤**：依賴使用者或系統預先打上的標籤進行探索。

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

---

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

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

### 2. 資料對映
建立資料流向圖，標示資料的：
- **位置**：地理位置 (影響 GDPR 等法規管轄權) 與邏輯位置。
- **存取權限**：誰可以存取。
- **敏感度**：機密等級。

### 3. 標籤與標記
將分類結果「貼」在資料上。
- **標籤**：在資料或文件上標示分類等級（如「機密」、「內部限閱」），通常為人類可讀。
- **標記**：使用元資料標記（如雲端資源標籤 Key-Value Pairs），支援自動化政策執行和資源管理。
- **挑戰**：雲端服務 (特別是物件儲存) 可能會剝離 (Strip) 檔案原本的元資料或標籤。需驗證標籤在跨系統傳輸時是否被保留。

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

---

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

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

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

### 2. 核心功能
- **細粒度權限**：控制「誰」可以「做什麼」。例如：唯讀 (Read-only)、禁止列印 (No Print)、禁止複製 (No Copy)、禁止截圖。
- **動態撤銷**：遠端讓檔案「自毀」或過期。即使檔案已外流，只要權限伺服器撤銷授權，對方就無法再開啟。
- **自動過期**：設定文件只能在特定時間內開啟。

### 3. 實作挑戰
- **代理程式**：通常需要安裝特定軟體才能開啟 IRM 加密檔。
- **金鑰管理**：高度依賴身分驗證服務 (IAM) 來分發解密金鑰。
- **破壞搜尋與歸檔**：加密後的檔案內容無法被傳統搜尋引擎索引。

---

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

### 1. 資料保留
- **目的**：滿足法規要求 (如稅法需保留 7 年) 或業務需求。
- **政策內容**：需定義保留期限 (Retention Period)、格式 (Format) 和安全性。

### 2. 資料歸檔
- **定義**：將**不活躍** 但需長期保存的資料，移至低成本儲存層 (如 AWS Glacier)。
- **考量**：
- **格式過時**：確保 10 年後檔案格式仍可讀取 (如從專有格式轉為 PDF/A)。
- **可搜尋性**：歸檔資料需能被 eDiscovery 工具檢索。
- **金鑰管理**：長期保存加密資料時，需確保解密金鑰也被妥善保存 (且未過期)。

### 3. 資料刪除與銷毀
雲端環境無法進行實體銷毀 (如消磁、粉碎)，因此需依賴邏輯銷毀。
- **加密擦除** 🔥：銷毀解密金鑰。這是雲端中最有效、最可驗證的銷毀方式。
- **覆寫**：用隨機數據覆蓋。但在快閃記憶體 (SSD) 或分散式儲存上效果不佳 (因為 Wear Leveling 技術)。

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

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

---

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

### 1. 事件來源
日誌 (Logs) 是稽核的基礎。需收集：
- **網路日誌**：防火牆、Flow Logs。
- **安全日誌**：IDS/IPS、WAF 警報。
- **應用程式日誌**：API 呼叫 (CloudTrail)、資料庫查詢。
- **作業系統日誌**：登入成功/失敗、權限變更。

### 2. 監管鏈
- **定義**：在數位鑑識中，證明證據從收集、分析到法庭呈現的過程中，**未被竄改**且由授權人員處理的完整文件紀錄。
- **雲端挑戰**：缺乏實體存取權 (無法拔硬碟)。需依賴 CSP 提供的日誌與快照，並使用雜湊值 (Hash) 證明完整性。

### 3. SIEM (安全資訊與事件管理)
- **功能**：集中收集各處日誌，進行**關聯分析**，以偵測複雜攻擊。
- **WORM 儲存** (Write Once, Read Many)：確保存放日誌的儲存體不可被竄改，保障稽核可信度。

---

## 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 抽象化為以下形式：

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

- **超融合基礎架構**：將運算、儲存、網路融合，透過軟體定義方式集中管理。

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

---

## 3.2 設計安全資料中心

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

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

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

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

#### 消防系統 (Fire Suppression)
- **原則**：資料中心**避免使用水**（會損壞電子設備且有觸電風險）。
- **氣體滅火**：
- **FM-200 / Aero-K**：化學氣體，不會置換氧氣，**人員在場可安全使用**。
- **CO2**：會置換氧氣，對人員有致命風險，通常不建議用於有人區域。
- **防火封堵**：防止火勢/煙霧穿過牆壁開孔的技術。

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

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

---

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

### 1. 虛擬化風險
CSP 負責 Hypervisor 安全，但客戶需了解相關風險：
- **虛擬機逃逸 (VM Escape)**：攻擊者從 VM 突破到 Hypervisor，進而控制主機或其他 VM。
- **虛擬機跳躍 (VM Hopping)**：利用 Hypervisor 漏洞攻擊同一主機上的其他 VM。
- **虛擬機資源餓死 (VM Starvation)**：某 VM 佔用過多資源導致其他 VM 無法運作 (DoS)。
- **虛擬機蔓延 (VM Sprawl)**：未管理的 VM 過多，導致攻擊面增加及合規問題。

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

### 3. MITRE ATT&CK 框架
用於了解攻擊者戰術與技術 (TTPs)。
- **資源開發**：攻擊者購買基礎設施/工具（企業層獨有）。
- **持久化**：維持存取權（如修改帳號、排程工作）。
- **橫向移動**：在網路內部移動尋找目標。

---

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

### 1. 系統、儲存與通訊保護
- **IaaS 服務**：Hypervisor、儲存控制器、DHCP、映像檔服務等都需要配置與維護。
- **虛擬化感知**：安全工具 (如 IDS/IPS, AV) 必須能感知虛擬化環境，避免效能瓶頸。

### 2. 身分識別、驗證與授權
- **聯合身分**：
- **SAML**：企業界標準 (XML-based)。
- **OIDC/OAuth**：現代網頁/App 標準 (JSON-based)。
- **驗證**：確認「你是誰」(MFA)。
- **授權**：確認「你能做什麼」(基於角色、屬性)。

### 3. 稽核機制
- **目的**：法規合規、風險控制驗證。
- **挑戰**：雲端客戶缺乏實體存取權，需依賴 CSP 的日誌與報告。
- **整合**：將稽核嵌入企業風險管理 (ERM) 結構中。

---

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

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

### 2. 關鍵指標
- **復原時間目標 (RTO)**：**能容忍多久沒服務？** 業務中斷到恢復的時間目標。
- **復原點目標 (RPO)**：**能容忍遺失多少資料？** 需回溯到多久前的備份。
- **最大可容忍中斷期間 (MTPD)**：超過此時間，企業將面臨永久性失敗。RTO 必須小於 MTPD。

### 3. 測試類型
由簡單到複雜：
1. **桌面審查**：紙上談兵，檢查計畫邏輯。
2. **模擬**：演練特定情境，不影響生產環境。
3. **平行測試**：在備援站點啟動系統，與生產環境同時運行。
4. **完全中斷/切換**：關閉生產站點，強制切換到 DR。風險最高，最真實。

### 4. 混沌工程
- **Netflix Simian Army**：
- **Chaos Monkey**：隨機關閉生產環境 VM，測試韌性。
- **Chaos Kong**：模擬區域 (Region) 級別故障。
- **目的**：主動在系統中引入故障，以發現弱點並建立信心。

### 5. 雲端 BCDR 策略
- **跨區域複製**：將資料複製到不同地理區域以防區域性災難。
- **基礎設施即程式碼**：使用 Terraform 等工具快速在異地重建基礎設施。
- **挑戰**：
- 資料主權 (Data Sovereignty)：異地備援是否違反資料法規？
- 頻寬與延遲：複製大量資料的成本與時間。

---

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

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

---

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

### 1. 雲端遷移評估
遷移到雲端不只是技術問題，需從以下面向評估：
- **人員**：是否有高層支持？員工是否準備好跨職能協作？
- **流程**：現有 ITIL/變更管理是否適用？
- **平台**：是否有定義好的「登陸區 (Landing Zones)」？
- **安全**：了解多租戶風險、無邊界網路 (No Air Gap)、Shadow IT。

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

#### 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 描述安全軟體開發生命週期流程

> **核心重點**：理解 SDLC 的標準框架 (NIST/ISO/MS SDL)、各階段的任務，以及軟體開發模型 (瀑布與敏捷) 的差異。

### 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 項實踐，涵蓋從培訓到事件回應。
- **關鍵實踐**：
- 執行威脅建模 (Threat Modeling)。
- 禁止危險函數 (Banned Functions)。
- 執行靜態/動態分析 (SAST/DAST)。
- 建立標準事件回應流程。

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

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

### 3. 軟體開發模型

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

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

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

---

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

> **核心重點**：將 SDLC 應用於實際場景，包括雲端特定風險 (CSA Egregious 11)、威脅建模技術 (STRIDE/PASTA/ATASM) 以及安全需求驗證 (ASVS)。

### 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. 安全需求驗證：OWASP ASVS
**OWASP 應用程式安全驗證標準** 提供了一組可驗證的安全需求，分為三個等級：

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

### 4. 軟體配置管理
- 在整個生命週期中控制軟體變更，確保完整性與可追溯性。
- 常見工具：Puppet, Chef, Ansible, Salt。
- **DevOps 觸發點**：在 DevOps 環境中，若**軟體部署流程** (CI/CD Pipeline) 或**服務執行環境**發生變更，應觸發威脅建模審查。

## 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. 使用案例 vs 濫用案例
- **使用案例**：描述系統**應該**如何運作 (正常行為)。
- **濫用/誤用案例**：描述攻擊者如何**破壞**系統 (惡意行為)。**這是定義安全需求的關鍵工具**。

---

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

### 1. API 安全
API 是雲端服務的「前門」，也是主要攻擊面。

#### REST vs SOAP
| 特性 | REST (Representational State Transfer) | SOAP (Simple Object Access Protocol) |
| :--- | :--- | :--- |
| **協定** | 架構風格 (Architectural Style)，使用 HTTP 方法 (GET, POST)。 | 嚴格的**協定**標準。 |
| **格式** | 輕量級，通常用 **JSON** (也支援 XML)。 | 僅支援 **XML**。 |
| **安全性** | 依賴 **TLS**。 | 內建 **WS-Security** (訊息層級加密)。 |
| **特性** | 簡單、可快取 (Caching)、行動裝置友善。 | 複雜、強型別、具備交易原子性 (ACID)。 |

> **補充**：**GraphQL** 是較新的技術，解決 REST "Over-fetching" \(拿太多\) 或 "Under-fetching" \(拿太少\) 的問題，允許客戶端精確指定需要的資料。

### 2. 開源軟體
- **原則**：開源不等於不安全 (Linus 定律：眼球夠多，Bug 就無所遁形)，但也**不保證安全**。
- **風險**：無人維護、惡意貢獻者、授權合規風險。
- **管理**：必須使用 **SCA** 工具持續監控 OSS 的漏洞。

---

## 4.6 雲端應用程式架構

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

### 2. 容器
- **定義**：輕量級虛擬化，共享 Host OS 的 Kernel，但打包了 App + Libs。
- **技術**：
- **Docker**：容器格式與執行環境。
- **Kubernetes (K8s)**：容器**編排**，管理部署、擴展、自癒。
- **Linux 安全機制 (隔離關鍵)**：
- **Namespaces**：隔離資源視角 (讓行程以為自己有獨立的網路/硬碟)。
- **Cgroups**：限制資源使用 (CPU/RAM 份額)。
- **Seccomp/AppArmor/SELinux**：限制行程權限與系統呼叫。

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

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

**應用場景**：
- **惡意軟體分析**：在沙箱中執行可疑檔案，觀察其行為而不危害真實環境
- **程式碼測試**：在隔離環境中測試新程式碼，確保不會影響生產系統
- **瀏覽器沙箱**：將瀏覽器程序隔離執行，防止惡意網頁攻擊宿主系統
- **第三方應用程式隔離**：限制不受信任的應用程式的系統存取權限

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

### 5. 補充安全元件
- **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. MFA (多因素驗證)
必須包含以下 **兩種以上** 不同類型的因素：
1. **Type 1**：密碼、PIN。
2. **Type 2**：手機、硬體 Token、智慧卡。
3. **Type 3**：指紋、臉部辨識。
4. *Type 4 (Somewhere you are)*：地理位置。

### 4. CASB (雲端存取安全代理)
- **功能**：位於使用者與雲端服務之間的中介點。
- **用途**：發現 Shadow IT、強制執行 DLP 政策、加密資料、存取控制。

### 5. 機密、金鑰與憑證管理
- **機密管理**：開發者常將 API Key 或 DB 密碼寫死 (Hard-coded) 在程式碼中。應使用 **Secret Manager** (如 AWS Secrets Manager, HashiCorp Vault)，程式執行時透過 API 動態取得憑證，並支援自動輪換 (Rotation)。
- **金鑰管理**：管理加密金鑰的完整生命週期（產生、分發、使用、輪換、撤銷、銷毀），包括 KMS 和 HSM 的使用。
- **憑證管理**：管理數位憑證的簽發、更新、撤銷。需監控憑證到期日期，避免服務中斷。包括 TLS 憑證、程式碼簽章憑證等。

---

# 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、金融交易)。 |

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

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

### 3. 管理平面工具
- **安裝與配置**：管理平面工具應與被管理系統隔離。
- **Guest OS 虛擬化工具集**：
- 如 VMware Tools 或 Hyper-V Integration Services。
- **功能**：提供驅動程式、時間同步、滑鼠整合、心跳檢測。
- **風險**：這些工具運行在較高權限，若有漏洞可能導致攻擊者提升權限。

### 4. 虛擬硬體配置
- **網路**：虛擬交換機 (vSwitch) 需配置 VLAN 以隔離流量。
- **儲存**：確保存儲加密已啟用，並正確配置 LUN masking。
- **CPU/Memory**：配置資源限制 (Limits) 和保留 (Reservations) 以防止 DoS 攻擊。

---

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

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

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

### 2. 網路安全配置
- **VLAN**：邏輯隔離廣播網域，雖不能完全防止攻擊 (VLAN Hopping)，但可減少攻擊面。
- **TLS**：傳輸層加密，保護管理流量 (HTTPS, SSH)。
- **DNSSEC**：防止 DNS 欺騙/快取中毒，確保解析出的 IP 是正確的。
- **DHCP**：需防範 Rogue DHCP Server (偽造的 DHCP 伺服器) 攻擊。

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

- **防火牆**：基於規則過濾流量。
- **入侵偵測系統 (IDS)**：被動監控，發出警報 (Promiscuous mode)。
- **入侵防禦系統 (IPS)**：主動監控，可阻斷惡意流量 (Inline mode)。
- **蜜罐**：誘餌系統，用於吸引攻擊者並收集攻擊情報。不應儲存真實生產數據。
- **網路分段**：將網路劃分為較小的區段，限制橫向移動 (Lateral Movement)。包括微分段 (Microsegmentation) 可實現工作負載層級的細粒度控制。

### 4. 作業系統強化
- **原則**：**最小功能原則**。
- **措施**：關閉不必要的服務、移除不必要的帳戶、關閉未使用的連接埠、啟用主機防火牆。

### 5. 修補程式管理
- **流程**：評估 -> **測試** -> 部署 -> 驗證。
- **重點**：絕不可在未經測試的情況下直接部署到生產環境。雲端環境可利用藍/綠部署來降低修補風險。

### 6. 叢集與高可用性
- **HA**：當主機故障時，VM 自動在另一台主機重啟。
- **DRS**：動態平衡負載，將 VM 遷移到資源較空閒的主機 (vMotion)。

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

---

## 5.4 支援數位鑑識

### 1. 數位鑑識定義
識別、保存、分析和呈現數位證據的過程。需符合法律標準以具備證據力 (Admissibility)。

### 2. ISO/IEC 27037 標準
定義了數位證據處理的四個關鍵階段：
1. **識別**：找出潛在的證據來源 (如 Log, VM Image, RAM)。
2. **收集**：實體獲取設備 (在雲端通常做不到)。
3. **獲取**：製作數位證據的**位元對位元** 映像檔 (Forensic Image)。
4. **保存**：確保證據在整個生命週期中未被竄改 (Hash驗證、防寫保護)。

### 3. 監管鏈
- **定義**：詳細記錄證據從收集到法庭呈現的整個過程 (誰接觸過、何時、在哪裡、做了什麼)。
- **重要性**：若監管鏈中斷，證據可能在法庭上失效。

### 4. 雲端鑑識的挑戰
| 挑戰 | 說明 |
| :--- | :--- |
| **缺乏實體存取** | 客戶無法拔硬碟，只能依賴 CSP 提供的日誌或快照。 |
| **多租戶環境** | 收集證據時不能侵犯其他租戶的隱私。傳統的「整台伺服器映像」在雲端不可行。 |
| **資料揮發性** | 虛擬機重啟或刪除後，RAM 和暫存資料即消失。 |
| **日誌格式** | 各家 CSP 格式不一，且客戶可能沒有開啟足夠詳細的日誌。 |

---

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

### 1. 相關方
有效的溝通計畫需涵蓋不同對象：
- **供應商**：軟硬體供應商，需管理供應鏈風險。
- **客戶**：需告知服務水準 (SLA)、維護視窗、安全事件。
- **合作夥伴**：如雲端經紀人、託管服務商。
- **監管機構**：需報告合規狀況和重大違規事件。

### 2. 溝通管理
- 建立單點聯繫 (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. 滲透測試
授權的模擬攻擊，驗證安全控制的有效性。

**雲端滲透測試注意事項**：
- **需要 CSP 授權**：大多數 CSP 有專門的滲透測試政策，部分測試類型需事先申請
- **範圍限制**：只能測試客戶自己控制的範圍，不能測試 CSP 的基礎設施
- **合規驅動**：PCI DSS 等法規要求定期執行滲透測試

---

# 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. 電子鑑識
在法律訴訟中識別、收集和製作電子儲存資訊 (ESI) 的過程。
- **ISO/IEC 27050**：電子鑑識的國際標準。
- **CSA Guidance**：CSA 提供雲端環境下電子鑑識的指引。
- **挑戰**：
- **所有權與控制權**：客戶擁有資料，但在 CSP 的設施中，取證困難。
- **多租戶**：取證時不能侵犯其他租戶隱私。
- **揮發性**：虛擬機關閉後資料可能消失。

### 4. 鑑識要求
雲端環境的數位鑑識需遵循國際標準：
- **CSA 鑑識指引**：雲端環境特有的鑑識挑戰和最佳實務。
- **ISO/IEC 27037:2012**：數位證據的識別、收集、獲取和保存指南。
- **ISO/IEC 27041:2015**：事件調查方法的保證指南。
- **ISO/IEC 27042:2015**：數位證據分析和解釋指南。
- **ISO/IEC 27043:2015**：事件調查原則和流程。

### 5. 法律與法規框架和指引
雲端運算涉及多層法規框架，組織需了解適用的法律和法規要求。

### 4. 美國 CLOUD Act
- 允許美國執法機構獲取美國公司在**海外**伺服器上的資料。
- 解決了微軟愛爾蘭案 (Microsoft Ireland Case) 的爭議。

---

## 6.2 理解隱私要求

### 1. 隱私數據定義
- **個人可識別資訊 (PII)**：能單獨或結合其他資訊識別個人的數據 (姓名、身分證號、生物特徵)。
- **受保護健康資訊 (PHI)**：與健康狀況相關的數據 (病歷、處方)。

### 2. OECD 隱私原則
許多現代隱私法 (如 GDPR) 的基礎。
1. **收集限制**：只收集必要的資料，且需經同意。
2. **資料品質**：資料應準確、完整且最新。
3. **目的明確**：收集時需說明用途。
4. **使用限制**：不得挪作他用 (除非經同意或法律要求)。
5. **安全保障**：需有適當的安全保護措施。
6. **公開性**：政策應透明。
7. **個人參與**：個人有權查閱和更正資料。
8. **問責性**：資料控制者需負起責任。

### 3. GDPR (一般資料保護規範)
歐盟最嚴格的隱私法，具備**域外效力** (Extraterritoriality)。
- **角色**：
- **資料主體**：資料所屬的自然人。
- **資料控制者**：決定資料處理**目的**與**方式**的實體 (通常是雲端客戶)。
- **資料處理者**：代表控制者處理資料的實體 (通常是 CSP)。
- **關鍵權利**：
- **被遺忘權**。
- **資料可攜權**。
- **資料保護官 (DPO)**：特定情況下必須指派。

### 4. 各國隱私法規
| 法規 | 適用領域 | 重點 |
| :--- | :--- | :--- |
| **HIPAA** | 美國醫療 | 保護 PHI，規範涵蓋 **Covered Entities** (醫院) 和 **Business Associates** (CSP)。 |
| **FERPA** | 美國教育 | 保護學生教育紀錄的隱私，適用於接受聯邦資金的教育機構。 |
| **GLBA** | 美國金融 | 允許消費者選擇退出 (Opt-out) 資料共享。 |
| **COPPA** | 兒童隱私 | 保護 13 歲以下兒童，需家長同意。 |
| **PIPEDA** | 加拿大 | 規範私部門在商業活動中收集、使用和揭露個人資訊。 |
| **Digital Personal Data Protection Act** | 印度 | 印度的個人資料保護法，規範數位個人資料的處理。 |
| **APEC 隱私框架** | 亞太地區 | 促進亞太地區內的資料自由流動與保護。 |

### 5. 隱私衝擊評估
在系統開發或流程變更之前，系統性地評估對個人隱私的潛在影響。

**目的**：
- 在專案初期識別隱私風險，而非事後補救
- 確保符合隱私法規要求（如 GDPR 要求的 DPIA）
- 建立利害關係人對隱私保護的信心

**評估流程**：
- 描述資料處理活動的性質、範圍和目的
- 評估資料處理的必要性和比例原則
- 識別和評估對資料主體的風險
- 確定緩解風險的措施
- 記錄評估結果和決策

**GDPR 中的 DPIA**：
- 當資料處理「可能導致高風險」時為強制性要求
- 涵蓋大規模的系統性監控、敏感資料處理、自動化決策等情境

---

## 6.3 稽核流程、方法論及雲端環境調適

### 1. 稽核報告類型
雲端客戶主要依賴第三方稽核報告來評估 CSP。

#### 服務組織控制 (SOC) 報告
由 AICPA (美國會計師協會) 定義。

| 報告類型 | 目標受眾 | 內容重點 | 適用場景 |
| :--- | :--- | :--- | :--- |
| **SOC 1** | 財務部門、稽核員 | **財務報告**相關的內部控制 (ICFR)。 | 客戶需進行財務報表稽核時。 |
| **SOC 2** | 管理層、監管機構、客戶 | 基於 **Trust Services Criteria**：安全性、可用性、處理完整性、機密性、隱私性。 | 詳細評估 CSP 的安全性與營運狀況 (需簽 NDA)。 |
| **SOC 3** | **大眾** | SOC 2 的摘要版，無敏感細節。 | 行銷用途，放在官網供下載「Seal of Approval」。 |

#### Type 1 vs Type 2
- **Type 1**：**時間點** 的設計有效性。驗證控制措施是否設計良好。
- **Type 2**：**一段時間** (通常 6-12 個月) 的執行有效性。驗證控制措施是否持續有效運作。**更有價值**。

### 2. ISO 標準
| 標準 | 描述 |
| :--- | :--- |
| **ISO/IEC 27001** | ISMS (資訊安全管理系統) 的**要求**。可被驗證/認證。 |
| **ISO/IEC 27002** | 資訊安全控制的**實務守則**。提供指引，不可被認證。 |
| **ISO/IEC 27017** | **雲端服務**的資訊安全控制指引 (基於 27002 的擴充)。 |
| **ISO/IEC 27018** | 公有雲中 **個資 (PII)** 保護的實務守則。 |

### 3. CSA STAR

- **Level 1**：**自我評估**。基於 CAIQ 或 CCM。
- **Level 2**：**第三方認證**。結合 ISO 27001 或 SOC 2。
- **Level 3**：**持續監控**。

### 4. 差距分析
識別目前安全狀態與期望狀態之間的差距。
- **控制分析**：評估現有控制措施是否符合標準要求
- **基線比較**：將現狀與安全基線標準進行比較
- **風險與控制自評**：由業務單位自行評估其面臨的風險及控制措施的有效性，是一種前瞻性的風險識別方法

### 5. 稽核範圍限制
- **SSAE**：美國 AICPA 的認證標準，SOC 報告依此標準執行。
- **ISAE**：國際稽核與保證標準委員會 (IAASB) 的國際標準。
- **範圍限制的意義**：SOC 報告只涵蓋特定時間段內、特定控制目標的稽核結論。客戶必須仔細閱讀報告的範圍聲明，確認其涵蓋自己關心的服務和控制。

### 6. 稽核規劃
- 確定稽核目標、範圍、時程和資源
- 識別關鍵風險領域和優先審查項目
- 建立與 CSP 的溝通和配合機制
- 確認稽核方法論（如基於風險的稽核方法）

### 7. 內部 ISMS 與控制系統
- **資訊安全管理系統 (ISMS)**：基於 ISO/IEC 27001，建立系統性的資訊安全管理方法，包含政策、程序、技術控制和人員管理。
- **內部資訊安全控制系統**：組織內部實施的安全控制措施集合，涵蓋預防性、偵測性和矯正性控制。

### 8. 政策層級
- **組織政策**：高層級的安全方針，由管理階層核准，定義安全目標和方向。
- **功能政策**：針對特定功能領域的政策（如存取控制政策、事件回應政策）。
- **雲端運算政策**：專門針對雲端服務使用的政策，包括可接受的雲端服務類型、資料分類要求、CSP 選擇標準等。

### 9. 虛擬化與雲端的保證挑戰
- 稽核人員可能無法直接存取底層基礎設施
- 多租戶環境下的稽核範圍界定困難
- 動態資源配置使傳統的靜態控制驗證方法受限
- 需要依賴 CSP 提供的稽核報告（如 SOC 2）作為替代保證

### 10. 高度受監管行業的特殊合規要求
| 法規/標準 | 產業 | 重點 |
|----------|------|------|
| **NERC CIP** | 北美電力 | 關鍵基礎設施保護，規範電力系統的網路安全控制 |
| **HIPAA** | 美國醫療 | PHI 保護，技術/管理/實體安全措施 |
| **HITECH Act** | 美國醫療 | 擴大 HIPAA 的執法範圍，增加資料洩露通知要求和罰則 |
| **PCI DSS** | 支付卡產業 | 保護持卡人資料，12 項安全要求 |

### 11. 分散式 IT 模型的影響
- 雲端資源可能分散在不同地理位置，跨越多個法律管轄區
- 需要協調不同區域的合規要求和稽核標準
- 資料主權問題影響稽核範圍和方法

---

## 6.4 雲端企業風險管理

### 1. 風險管理標準
- **ISO 31000**：風險管理的原則與指引 (通用框架)。
- **NIST SP 800-37**：風險管理框架 (RMF)，包含 6 步驟 (Categorize, Select, Implement, Assess, Authorize, Monitor)。

### 2. 風險處理策略
| 策略 | 描述 | 範例 |
| :--- | :--- | :--- |
| **規避** | 停止產生風險的活動。 | 不使用公有雲處理機密資料。 |
| **修改/緩解** | 降低發生的可能性或影響。 | 實施加密、防火牆、MFA。 |
| **分擔/轉移** | 將風險轉嫁給第三方。 | 購買保險、外包 (注意：責任無法完全轉移)。 |
| **保留/接受** | 接受風險的存在 (通常當處理成本 > 潛在損失時)。 | 簽署接受風險聲明。 |

### 3. 資料角色
- **資料所有者**：對資料負最終責任，負責分類資料。
- **資料控制者**：決定處理目的 (通常是客戶)。
- **資料保管者**：負責執行安全控制 (備份、加密)。
- **資料處理者**：代表控制者處理資料 (通常是 CSP)。
- **資料管理員**：負責日常資料品質管理，確保資料的準確性、一致性和合規性。通常是特定業務領域的資料治理執行者，介於 Owner 和 Custodian 之間。

### 4. 評估供應商風險管理程序
評估 CSP 的風險管理成熟度，包括：
- **控制措施**：CSP 實施了哪些安全控制
- **方法論**：CSP 使用的風險評估方法
- **政策**：CSP 的安全政策是否完善
- **風險剖繪**：CSP 面臨的主要風險類型
- **風險胃納**：CSP 願意接受的風險程度

### 5. 法規透明度要求
- **資料洩露通知**：各法規要求在發現資料洩露後的特定時間內通知受影響者和主管機關（如 GDPR 要求 72 小時內通知）
- **SOX**：美國上市公司的財務報告透明度法規，要求管理階層對財務報告中的內部控制有效性進行評估和認證
- **GDPR 透明度原則**：資料處理活動必須對資料主體透明

### 6. 風險管理指標
量化風險管理的有效性：
- **KRI**：關鍵風險指標，用於預警風險水準的變化（如未修補的高風險漏洞數量）
- **KPI**：關鍵績效指標，衡量安全控制的執行效能（如平均修補時間）
- **風險暴露量**：潛在損失 × 發生機率
- **殘餘風險**：實施控制措施後仍存在的風險水準

### 7. 風險環境評估
從不同面向系統性地評估風險：
- **服務風險**：雲端服務的可用性、效能和安全性風險
- **供應商風險**：CSP 的財務穩定性、合規性和服務持續性風險
- **基礎設施風險**：底層基礎設施的技術風險和韌性
- **業務風險**：對業務營運、聲譽和合規的潛在影響

---

## 6.5 外包與雲端合約設計

### 1. 合約文件類型
- **主服務協議 (MSA)**：定義通用的條款與條件 (付款、保密、終止)，適用於多個 SOW。
- **服務層級協議 (SLA)**：定義具體的服務品質指標（如 99.9% 可用性）和違約賠償。
- **工作說明書 (SOW)**：定義特定專案的範圍、交付物和時程。

### 2. 供應商管理
- **供應商鎖定**：過度依賴單一供應商，導致遷移困難。解法：使用標準介面、容器化、多雲策略。
- **供應鏈風險**：**ISO/IEC 27036** 提供供應商關係的安全指引。

### 3. 合約管理
合約應明確涵蓋以下關鍵條款：
- **稽核權**：客戶或其代表有權對 CSP 進行稽核
- **指標與定義**：明確定義 SLA 指標的計算方式
- **終止條款**：包括資料退還和銷毀的程序
- **訴訟**：管轄權和爭端解決機制
- **合規**：CSP 需符合的法規和標準
- **資料存取**：定義誰可以在什麼條件下存取資料
- **網路風險保險**：CSP 的保險範圍和限額
- **資料所有權**：明確約定資料的所有權歸屬客戶
- **安全要求**：CSP 需遵循的安全標準和控制措施

---

## 參考資料

> **Classroom-Based CCSP Official ISC2 Textbook, 5th Edition**