CCSP Domain 5：Cloud Security Operations 彙整講義

範圍： simulate-test/ 內所有測驗講義中屬於 Domain 5 的內容，跨場次合併後依主題重組。 考試權重： 17% 來源： by-test/03、04、07、09、10、by-test/learnzapp/02、03、04 維護： 新增測驗講義後，將該檔的 D5 章節併入本檔，並更新 §0 來源對照。 註： 各場次分數、進步判定與補強排程留在 by-test/ 原檔，不併入本檔。

0. 來源對照 / Source Map

1. 核心觀念 / Core Concepts

1.1 維運生命週期心智模型

Baseline → Harden → Document → Monitor
        → Detect deviation → Change management
        → Patch / test → Remediate → Re-baseline

資料中心三層視角：

Physical              Environmental          Resilience
├─ site / location    ├─ HVAC                ├─ UPS / generators / fuel
├─ physical access    ├─ temperature/humidity├─ redundant power
├─ seismic/flood/fire ├─ airflow/hot-cold aisle ├─ redundant cooling
└─ facility security  └─ fire suppression    └─ redundant connectivity

實體與環境細節見 Domain 3 §1.1，其中 Hot／Cold Aisle 的 Front ↔ Front / Rear ↔ Rear 判斷規則（來源 by-test/11 D5 §5）也在該節。

1.2 Baseline、Hardening 與 Configuration Management

Baseline 沒有 documentation 就等於不存在： 無法證明 configuration drift、無法稽核偏離、無法可靠還原。遇到「baseline 需要什麼」時選 Documentation，不要選培訓、HIDS 或更多掃描。

Baseline deviation 的正確處理順序：

Document → Assess → Authorize / Remediate → 若屬合理則透過變更流程 update baseline

不要發現 deviation 就直接改回去，因為它可能是 approved change、emergency change、unauthorized change、drift 或 compromise——必須先判斷。

Social engineering 不屬於 configuration maintenance，它是 human-layer 的攻擊／測試活動。

Hardening 的典型動作（by-test/12 §2）

• 移除不必要軟體
• 關閉不必要 service／ports
• patch／update
• secure configuration
• least privilege
• host firewall
• HIDS／endpoint protection
• disable weak protocols
• secure logging configuration

⭐ Audit ≠ Hardening（by-test/12 §3）

Audit     = assessment / verification     → 找問題、驗證
Hardening = implementation / remediation  → 改系統、修問題

常見反駁： 不 audit，怎麼知道 baseline／policy／control 哪裡有缺口？

這在 workflow 上完全成立——audit 可以驅動下一輪 hardening，是 hardening loop 的重要 feedback mechanism：

Baseline / Policy
      ↓
Hardening
      ↓
Audit / Assessment
      ↓
Find drift / gaps
      ↓
Remediation
      ↓
Re-audit

但 taxonomy 上兩者不同。 工程類比：

Unit test ≠ Feature implementation
Test discovers defect → developer modifies code

Audit discovers:  SSH root login enabled
Hardening:        disable root SSH

動詞判斷法：

Hardening changes the system; Audit checks the system.

1.3 Patch Management

典型流程：

Identify → Evaluate → Test → Approve → Deploy → Validate

Production 不能看到更新就直接部署，必須測試 compatibility、availability impact 與 change risk。

Patch 不解決 interoperability（by-test/12 §6）

Patch 可以修 vulnerability、修 bug、改善 performance，有時帶入功能或 compatibility fix。但 generic cloud interoperability 是架構層面的問題。

Patch            → software defect / vulnerability / performance
Interoperability → architecture / API / format / standard

看到「升級／打補丁能否解決跨雲互通」時，答案是不能——那要靠標準、API 與格式（見 Domain 1 §1.5）。

Vendor 的角色

復現標記： 已在 by-test/10 上篇 D 與 by-test/12 §7 連續出現，屬高頻考點。

題目問「production 系統修補時誰的建議權重最高」→ Vendor，因為 vendor 最清楚 prerequisites、compatibility、supported versions、known issues、rollback、reboot requirement。

但治理模型必須分清：

Vendor                → technical advice
Security              → vulnerability risk
Compliance            → obligation / deadline
Change Management     → controlled approval
Business/System Owner → operational risk / accountability

一句記： Vendor advises; the organization decides. Vendor guidance 展現 due diligence，但 vendor 不是組織的 risk owner。

修補死角

自動化修補排程只對正在運行的機器有效。存在 storage 裡的 snapshots、saved VM images、dormant／powered-off guests 都收不到 patch，下次被喚醒時就帶著已知漏洞上線。

考場句型： 問「cloud auto-patching 的最大風險」→ 找 snapshot / saved VM images won't take a patch。

1.4 Maintenance Mode 與高可用

維護模式心智模型：

Drain / migrate workload
        → 必要時阻擋新工作負載（prevent new logins）
        → 維持 monitoring / logging
        → 執行維護
        → 驗證
        → 恢復服務

High Availability（by-test/11 D5 §7）

HA 關注的是 service remains available despite failures，常見手段：redundancy、replication、clustering、failover、load balancing。

易錯點：failback to on-prem 不是所有 cloud HA 架構的必備元素。 它是否存在取決於 hybrid architecture、組織環境與 DR strategy——看到選項列出「必須能 failback 回自有機房」時不要反射選它。

BC/DR 的完整指標與 4R 流程見 Domain 3 §1.6。

1.5 監控、日誌與偵測工具

Synthetic Monitoring vs RUM（by-test/11 D5 §3）

腳本範例：Login → Search → Checkout。

為什麼 synthetic 有 broad coverage？ 因為不必等真實使用者剛好操作，可以主動排程測試少用流程與離峰時段。

Synthetic asks: Can it work?
RUM asks:       How is it actually working for users?

DHCP vs NTP（by-test/11 D5 §6）

DHCP 派送的是 network configuration：IP address、subnet mask、gateway、DNS 以及各種 option-based 設定。

它可以透過 Option 42 告訴 client NTP server 的位址，但 DHCP 本身不執行時間同步。

DHCP distributes network configuration.
NTP synchronizes clocks.
DHCP does not negotiate encryption protocols.

與本節第一列併讀：跨系統日誌關聯的先決條件是 NTP 的時鐘同步，不是 DHCP 發得出 IP。

Honeypot

EXCEPT 題秒選： Luring attackers。主動引誘可能構成 legal entrapment，傷害後續追訴。

1.6 Incident、權限與內部威脅

Incident 定義： 題庫常寫 Incident = unscheduled event，這是過度寬鬆的 legacy operational wording。

Security incident 更好的理解：對 CIA、系統或安全政策造成實際或潛在危害／違反的事件。NIST 現行定義也以 confidentiality、integrity、availability 或 security-policy violation 為核心。

不要背： Every unscheduled event = security incident.

Insider Threat 控制分類（by-test/11 D1 §4）

Insider threat 指已位於某種 trust boundary 內的對象：employee、contractor、privileged administrator、trusted partner。

用語修正： 題庫的「aggressive background checks」措辭過強。較正確的說法是 appropriate／lawful／proportionate personnel screening——不是「越激進越安全」。人員篩查受當地勞動與隱私法規限制。

為什麼強化周界不是主要的 insider control？ 周界型控制確實能擋住一些內部風險，但名稱與層級要分清：

Corporate LAN
     |
Internal Firewall      ← 這叫 internal segmentation
     |
Sensitive Network

• Internal segmentation firewall 可以限制 insider lateral movement，但它是內部分段，不是典型的 perimeter device。
• Biometric 屬 physical access control，可防未授權實體進入、冒用身分、盜用識別證，但不是 network perimeter hardening。

Background screening         = preventive personnel control
Internal segmentation        = limits insider movement
External perimeter hardening = primarily outsider-focused

Personnel Controls 的範圍（by-test/12 §4）

Personnel controls 治理的是人的可信度、行為與 employment lifecycle：

• Background checks
• Reference checks
• Security awareness／training
• Job rotation
• Separation of duties
• Termination procedures
• Exit process

⭐ Physical Access Control ≠ Personnel Control（by-test/12 §5）

精確的說法是：Physical access controls 會作用在人身上，但 taxonomy 上不等於 personnel controls。

Mantrap
→ controls people
→ but category = Physical Access Control   （不是 Personnel Control）

最短記法： Personnel = govern the person Physical Access = govern entry／movement

常見反駁： Mantrap／turnstile 比 training 更有用吧？

這是在比較 effectiveness，但題目考的是 classification。兩個維度要分開。 結論一句：作用對象相同，不代表 control category 相同。

實體存取控制的分層（reception／badging／video／mantrap／bollards）見 Domain 3 §1.2。

1.7 Responsibility、Accountability 與供應鏈

核心 CCSP 原則： Responsibility can be shared or delegated. Accountability usually remains with the accountable organization, data owner, or controller.

不要看到「CSP caused the incident」就自動選「CSP has all responsibility」。

Access control criteria 的來源層次：

External requirements（law / regulation / contract / standards）
        ↓
Organizational policies
        ↓
Technical controls（IAM / ACL / configuration）

題目問「誰決定組織的 access criteria」→ 組織依適用要求制定的 policy，通常不是直接回答 ISO／NIST。

供應鏈風險： 評估 CSP 時，除了 CSP 自身的 security posture，還要看它所依賴的 third parties／subprocessors。

Customer → CSP → Subprocessor → Another service

CSP secure ≠ entire service chain secure。這是典型的 concentration／dependency／supply-chain risk。

1.8 風險指標（與 D6 交叉）

SLE = AV × EF
ALE = SLE × ARO

Exposure Factor（EF） 是單一事件可能造成的資產損失比例；威脅媒介類型（type of threat vector）決定破壞機制與損失百分比，因此對 EF 影響最大。不要把 EF 等同「攻擊目標」或「資產名稱」。

風險處置、質性／量化評估、risk appetite 歸屬的完整整理見 Domain 6 彙整講義，其中也包含 ARO 的 evidence vs calculation 之分與 NIST RMF 七步驟（來源 by-test/11 D5 §1、§4）。

1.9 Cloud Sprawl

Cloud sprawl 除了 compute／storage 費用，還會產生容易被忽略的 software licensing 成本：

新增 VM / database instance / commercial OS / security appliance / enterprise software
        ↓
license count、subscription fee、support cost、management overhead 同步增加

Cloud sprawl ≠ only infrastructure bill。雲端最常見的無意行為是忘記關 VM，造成 resource sprawl。

⭐ Virtualization sprawl：成因、風險與 targeted remediation（來源：2026-10-18 D3 補強）

最短模型：Sprawl ＝ 好建立 ＋ 難追蹤 ＋ 沒人刪。 三個條件各自對應一組控制；remediation 要逐一對準，不是只「關掉多餘 VM」。

成因鏈：

好建立：self-service、API、template 讓 VM 幾秒內就能開
   ↓
難追蹤：沒有 tag、沒有 owner、沒有 CMDB 紀錄，跨帳號／跨 region 散落
   ↓
沒人刪：專案結束、測試完、人員離職後無人負責 decommission
   ↓
結果：orphaned／dormant VM、snapshot、image、volume 持續累積

風險不只帳單：

Targeted remediation（對準三個成因）：

發現 sprawl 的處理順序：
Discover（找出全部）→ Attribute（找到 owner）→ Secure（patch／隔離）
→ Decide（保留或退役）→ Decommission（依 retention 與銷毀政策）→ Prevent（tag／approval／expiry）

出題角度： 題目問「降低 VM sprawl 的最佳控制」→ 優先選 lifecycle management／asset inventory 與 provisioning policy 這類治理控制；「多買監控工具」「直接刪除所有閒置 VM」都不是完整答案。與 snapshot／dormant VM 收不到 patch 的盲點見 Domain 3 §1.4。

1.10 TLS 的維運面

TLS
├─ Authentication          → certificate / PKI（X.509 + digital signature）
├─ Key agreement           → TLS 1.3 通常為 (EC)DHE，或 PSK / PSK+(EC)DHE
├─ Derived traffic keys    → symmetric
└─ Application traffic     → symmetric AEAD encryption

TLS session key = symmetric cryptography；TLS trust 通常來自 PKI certificates。 密碼學原理見 Domain 2 §1.7，協定與傳輸面見 Domain 3 §1.3。

2. 錯題與修正規則 / Errors & Corrections

2.1 內部威脅與特權存取（by-test/03 Q1、Q14、Q15）

• 內部威脅控制的例外是 hardened perimeter devices（那是外部威脅控制）。
• Privilege escalation 控制的例外是 cryptographic sanitization（那是資料殘餘控制）。
• Privileged access 的正解是 temporary／time-bound，不是 granular。

2.2 Hardening vs Redundancy（by-test/04 §9.2）

冗餘電源供應器是 redundancy，不是 hardening。

Hardening  = 縮小攻擊面 / 安全組態 / 關閉不必要服務 / patch / baseline
Redundancy = 可用性 / 容錯

2.3 Maintenance mode 與 vendor 盡職（by-test/09 §8）

• Maintenance mode 不會阻擋 admin 存取。
• 遵循 vendor guidance 可展現 due diligence。
• DLP／SIEM 工具需要調校與學習期。
• 雲端是多租戶環境，isolation 是關鍵。

2.4 Patch 建議權重（by-test/10 上篇 D，Recurring）

Whose advice should receive most weight about patching a production system? → Vendor。但 vendor ≠ final decision maker，見 §1.3 的治理模型。

2.5 BC/DR 模型（by-test/03 Q10）

常見雲端 BC/DR 模型：private architecture + cloud backup、同一 provider 的雲端備份、另一家 cloud provider。「cloud provider 由 private provider 備援」不是典型模式。 BC/DR 的完整整理見 Domain 3 §1.6。

3. 一句話規則表 / One-liner Rules

4. 易混淆邊界 / Confusable Boundaries

Boundary learning 提示： Audit vs Hardening、Personnel vs Physical Access 這兩組都屬「兩個答案技術上都合理，但題目在問分類」的典型。處理流程見 README 的錯題複習與 argue 流程。

5. 補強演練 / Drills

Drill A：2 天 patch

Day 1（約 60 分鐘）

• Hardening／baseline／patching 觀念：30 分鐘
• D5 drill 20 題

Day 2（約 60 分鐘）

• 機房與維運事實（maintenance mode、KVM、UPS、燃料、ASHRAE）：30 分鐘
• D5 drill 20 題

Gate：D5 mini-test ≥ 75%。

Drill B：閉卷問答（不看筆記）

1. Baseline、hardening、configuration management 差在哪？
2. Baseline deviation 的正確處理順序是什麼？
3. 為什麼 production 不能看到 patch 就直接部署？
4. Golden image／snapshot 為何造成 patch risk？
5. 進入 maintenance mode 前，workload 要怎麼處理？
6. HA、clustering、live migration 的差異？
7. 為什麼 management plane 應隔離？
8. 為什麼 maintenance mode 不能停 logging？
9. 跨系統日誌關聯的第一先決條件是什麼？
10. Honeypot 的哪一項用途會是 EXCEPT 題的答案？
11. Synthetic monitoring 與 RUM 各回答什麼問題？為什麼 synthetic 的涵蓋面較廣？
12. DHCP 的 Option 42 做什麼？它等於時間同步嗎？
13. Insider threat 的 preventive／detective／administrative 控制各舉三項。
14. 為什麼 internal segmentation firewall 不算 perimeter device？
15. Audit 與 hardening 的分類差異是什麼？為什麼「audit 能找出缺口」不能讓它變成 hardening？
16. 題幹出現 verify、review 時該選哪一類？出現 disable、restrict 時呢？
17. Mantrap 控制的是人，為什麼分類不是 personnel control？
18. Patch 能解決跨雲 interoperability 嗎？為什麼？
19. Sprawl ＝ 好建立 ＋ 難追蹤 ＋ 沒人刪 三個成因各對應哪一組控制？
20. 為什麼 dormant VM 是安全風險而不只是成本問題？
21. 發現一批無 tag、無 owner 的 VM，處理順序是什麼？為什麼不能直接刪除？

Drill C：責任邊界演練（15 分鐘）

寫出 responsibility vs accountability、controller vs processor 的定義，並各舉一個雲端 breach 情境說明歸責落在誰身上。

值得記 vs 現階段不必死磕