CCSP Domain 4 核心觀念與架構 / Cloud Application Security

Domain 4 定位： 本領域涵蓋雲端應用程式安全設計、威脅建模、軟體開發生命週期（SDLC）與 API 安全。考題重點在於安全設計原則與應用層控制，而非底層基礎設施。

核心資料保護技術對照表

1. Data Masking 的「最佳定義」

在測驗中看到 Data Masking 時，直覺往往會聯想到「隱藏個人機密資訊 (Hide PII)」。這是一個嚴重的誘答陷阱。

隱藏 PII 只是 Masking 達成的一種「效果」，但從安全管理的最高框架來看，其最佳定義 (Best definition) 是「提供用於測試或訓練的相似但不真實的資料集」。這就像是在 Staging 環境倒 Production 資料前，透過腳本把真實的姓名和 Email 洗掉，換成符合格式的假字串。目的是讓 SDLC 中的測試階段能順利進行，而不會引發真實個資外洩的風險。

2. Tokenization 與 PCI DSS 合規架構

在 CCSP 框架下，Tokenization 幾乎與 PCI DSS (支付卡產業資料安全標準) 完全綁定。您必須釐清以下兩個絕對觀念：

• 機制本質： Tokenization 絕對不是 Encryption。它不涉及複雜的數學演算法，也沒有金鑰 (Key)。從後端系統架構來看，它更像是一個高度安全的 Key-Value 對應機制，類似於實作 Redis 查表：Token 是 Key，真實信用卡號是 Value，兩者的對應關係嚴格儲存在一個獨立的 Token Vault 中。

• 合規責任邊界： 企業常會將 Tokenization 交由第三方服務商代管。這樣做能有效縮減商家自身的合規範圍 (Reduce merchant compliance scope)，因為真實卡號不再流經商家的內部系統。然而，這並不能完全免除商家的最終責任。身為資料擁有者 (Data Owner)，商家仍需為整體業務架構與第三方供應商的風險管理負起最終責任。

1. Threat Modeling：STRIDE / DREAD / PASTA 詳解

跨 Domain 威脅建模框架 (STRIDE/DREAD)

1.1 先記核心差別

• STRIDE：拿來分威脅類型
• DREAD：拿來評估、排序風險
• PASTA：拿來走完整風險分析流程

你這批錯題裡，最明顯就是把 STRIDE 的分類 和 DREAD 的排序 混掉；另外 TLS、XSS、MFA、DevSecOps 也是重點弱區。
（你上傳的錯題分析也明確點出：STRIDE = threat categories、DREAD = prioritization、Certificate validation = anti-MITM、XSS 主控制 = output encoding + input validation、Broken Authentication 主控制 = MFA、SQLi 根因常在 DevSecOps / SDLC）

1.2 STRIDE 詳細解說

STRIDE 是什麼

STRIDE 是微軟常見的 threat modeling 分類法。
重點不是算分數，而是問：

「系統可能遭遇哪些種類的威脅？」

六大類

S — Spoofing

假冒別人身分。
例子：

• 假冒使用者登入
• 假冒服務帳號
• 假冒 API client
• 偽造 session / token

你可以問自己：

• 攻擊者能不能冒充合法使用者或系統？

常見控制：

• MFA
• 強認證
• 憑證驗證
• 安全 session / token 管理

T — Tampering

資料被未授權修改。
例子：

• 修改封包內容
• 改資料庫紀錄
• 改 API 請求參數
• 改 log

你可以問自己：

• 攻擊者能不能偷偷改資料？

常見控制：

• 完整性驗證
• 數位簽章
• MAC
• 權限控管
• 參數驗證

R — Repudiation

做了事卻否認。
例子：

• 使用者刪了資料卻說不是他
• 管理員改設定卻無法追溯
• 金融交易沒有可驗證紀錄

你可以問自己：

• 事後能不能證明是誰做的？

常見控制：

• 不可否認性機制
• 完整 log
• 時間戳
• 稽核軌跡
• 簽章

I — Information Disclosure

機密資料外洩。
例子：

• 個資外洩
• API 回傳過多資料
• 錯誤訊息洩漏系統資訊
• 傳輸未加密

你可以問自己：

• 不該看的人能不能看到資料？

常見控制：

• 存取控制
• 加密
• 遮罩
• 最小揭露
• 安全錯誤處理

D — Denial of Service

服務不可用。
例子：

• 流量打爆
• 資源耗盡
• 惡意重試
• 鎖表、死循環、排程壅塞

你可以問自己：

• 攻擊者能不能讓服務變慢、掛掉、不可用？

常見控制：

• Rate limiting
• WAF / DDoS 防護
• 資源隔離
• 自動擴展
• 快取 / queue

E — Elevation of Privilege

權限提升。
例子：

• 一般使用者變管理員
• 橫向移動拿到高權限
• 繞過授權檢查

你可以問自己：

• 攻擊者能不能拿到本來不該有的權限？

常見控制：

• Least privilege
• RBAC / ABAC
• 權限檢查
• 安全設計與測試

1.3 DREAD 詳細解說

DREAD 是什麼

DREAD 用來做風險評分。
不是問「這是哪一種威脅」，而是問：

「哪個威脅比較值得先處理？」

常見構面

• Damage potential：造成多大損害？
• Reproducibility：容易重現嗎？
• Exploitability：容易利用嗎？
• Affected users：會影響多少人？
• Discoverability：容易被發現與利用嗎？

例子

同樣是漏洞：

• 漏洞 A 可遠端利用、影響全部用戶、可穩定重現
• 漏洞 B 只能內網、影響少數人、利用條件高

那 A 通常優先。

DREAD 的優點

• 方便排序
• 幫忙分配修補優先級
• 讓團隊可討論風險高低

DREAD 的限制

• 主觀性高
• 不同評分者可能打分不同
• 現代很多團隊會改用更貼近業務的風險方法

所以你要記：

STRIDE 問「是什麼威脅」
DREAD 問「先修哪個」

1.4 PASTA 詳細解說

PASTA 是什麼

PASTA = Process for Attack Simulation and Threat Analysis

它不是單一分類表，也不是單一評分表。
它是以風險為核心的完整 threat modeling 方法。

核心精神

從上往下看：

1. 先看業務目標
2. 再看技術範圍
3. 再看系統組成
4. 再看威脅
5. 再看弱點
6. 再看攻擊路徑 / 模擬
7. 最後做風險處理

常見 7 階段

1. 定義業務目標
2. 定義技術範圍
3. 應用程式分解
4. 威脅分析
5. 弱點與漏洞分析
6. 攻擊建模與模擬
7. 風險分析與管理

什麼時候用 PASTA

適合：

• 系統大
• 利害關係人多
• 要連到業務風險
• 要做較完整的 threat modeling

你要避免的誤解

PASTA 可能包含模擬與驗證，
但它不是「一個 DAST 工具」或「等於動態測試」。

1.5 三者比較表

1.6 考題陷阱

常見陷阱 1

題目問：
Which model categorizes threats?
你要先想到 STRIDE

常見陷阱 2

題目問：
Which model prioritizes threats?
你要先想到 DREAD

常見陷阱 3

題目問：
Which method is most comprehensive / risk-centric / business-driven?
你要先想到 PASTA

2. TLS 詳細解說（附 Mermaid）

2.1 TLS 在做什麼

TLS 的三大目標：

• Authentication：確認對方是誰
• Confidentiality：內容不被偷看
• Integrity：內容不被竄改

考題裡最容易錯的是：

防 MITM 的核心不是「session key 產生」本身，
而是「server certificate validation」。

也就是：
先確認你連到的是對的伺服器，再建立安全通道。

2.2 TLS 的核心元件

1. Certificate

伺服器拿來證明自己身分的憑證。

2. Public key / private key

• 公鑰可公開
• 私鑰只能由伺服器持有

3. Session key

真正用來加密大量資料的，通常是對稱金鑰

4. CA / Trust store

用來驗證憑證是否可信

2.3 為什麼不用非對稱加密一路加到底

因為非對稱加密比較慢。
所以 TLS 會用：

• 非對稱機制：做身分驗證、交換/協商祕密
• 對稱加密：加密後續大量資料

也就是：
先驗身分，再協商金鑰，再用對稱金鑰保護傳輸。

2.4 TLS 1.3 典型流程

2.5 每一步在做什麼

Step 1: ClientHello

Client 告訴 server：

• 我支援哪些 TLS 版本
• 我支援哪些 cipher suites
• 我提供哪些 extensions
• 我這次的 key share 是什麼

重點：
這一步是提議能力與參數，不是驗身分。

Step 2: ServerHello

Server 回答：

• 我選哪個 TLS 版本
• 我選哪個 cipher suite
• 我用哪個 key share

重點：
ServerHello 是協商，不是身分驗證本體。

Step 3: 產生共享祕密

雙方根據 key exchange 資料導出共享祕密。
之後再導出 handshake keys、application traffic keys。

重點：
這讓雙方可建立後續加密通道。

但注意：
如果你還沒確認 server 是真的，單有共享祕密還是不夠防 MITM。

Step 4: Server 傳 Certificate

Server 給 client 看憑證。
內容通常包含：

• 網域名稱資訊
• 公鑰
• 簽發者資訊
• 有效期限
• 簽章

Step 5: Client 驗證 Certificate

這一步非常重要。

Client 會看：

• 憑證是不是可信 CA 簽的
• 憑證鏈是否完整
• 憑證有沒有過期
• 網域名稱是否相符
• 是否被撤銷（視情況）
• 簽章是否正確

這一步的意義

這一步在回答：

「我現在連到的，真的是我要連的 server 嗎？」

所以你錯題裡關於 TLS 的幾題，核心都在這一句：
Certificate validation 才是 anti-MITM 的關鍵。

Step 6: CertificateVerify

Server 用私鑰對某些握手資料做簽章。
這是在證明：

「我真的持有跟這張 certificate 對應的 private key。」

Step 7: Finished

雙方各自傳 Finished。
代表：

• 握手資料一致
• 金鑰已建立
• 可以開始安全傳輸

2.6 TLS 1.2 和 1.3 的考點差別

你考試不一定要背到封包級，但要知道：

TLS 1.2

• 常看到更傳統的 key exchange 流程
• 常會看到 ChangeCipherSpec
• 考題很愛問 ServerHello、certificate、key exchange

TLS 1.3

• 流程更精簡
• 更強調前向保密
• 很多舊演算法被淘汰

不管哪一版，考試最穩的觀念都是：

• ServerHello ≠ 真正驗證身分
• Certificate validation = 驗 server 身分
• Session key = 保護後續資料
• anti-MITM 的核心先在 authentication

2.7 Kerckhoffs’s Principle

這也是 TLS / crypto 很愛混在一起考的記憶點。

原則

系統即使公開，仍應安全；安全性應建立在 key 的保密上。

不應依賴：

• 演算法藏起來
• 協定藏起來
• 實作細節沒人知道

應依賴：

• 金鑰保護
• 正確設計
• 正確實作

一句話記：
不要靠「沒人知道」來安全，要靠 key。

2.8 Key Management 基本觀念

你錯題裡還有一個點是：

金鑰在 cloud provider 基礎設施內生成、儲存、輪替
這種描述，重點在於：

• 金鑰生命週期由 provider 內部管理
• 不是外部 escrow
• 不是第三方代管

考試通常會看你能不能抓關鍵字：

• where the keys live
• who controls lifecycle
• who can access them
• provider-managed / customer-managed / external

3. XSS / MFA / OWASP 主控制 詳解

3.1 先抓這包的核心

你這包最需要補的是：

primary control（主控制）
vs
defense-in-depth（加強防護）

也就是：

• 題目問「最有效」「最直接」「主要」
  你要先找第一線控制
• 題目問「額外強化」
  才去想第二層控制

你這批題的分析也明確指出：
你常把 CSP 當 XSS 主控制、把 session management 當 Broken Authentication 最直接答案、把 單點輸入檢查當 SQLi 根因解法；但題目更常要你回答 output encoding + input validation、MFA、DevSecOps / SDLC integration。

3.2 XSS 詳細解說

XSS 是什麼

Cross-Site Scripting。
攻擊者把惡意 script 注入到頁面，讓受害者瀏覽器執行。

常見種類

• Stored XSS
• Reflected XSS
• DOM-based XSS

為什麼會發生

本質上是：

不可信輸入，進入了可執行的瀏覽器上下文。

例如：

• 放進 HTML 內容
• 放進 attribute
• 放進 JavaScript 字串
• 放進 URL
• 放進 CSS

XSS 的主控制為什麼是 output encoding + input validation

1. Output encoding

最核心。
因為 XSS 最後發生在「輸出到瀏覽器」那一刻。

你把資料輸出到不同位置時，要做對應編碼：

• HTML context
• HTML attribute context
• JavaScript context
• URL context
• CSS context

這叫 context-aware output encoding

2. Input validation

也重要。
它能減少惡意輸入進入系統。

但單靠 input validation 不夠，因為：

• 很難擋住所有 payload
• 合法輸入也可能在特定 context 變危險
• 不同輸出位置風險不同

所以最完整的考試答案常是：

output encoding + input validation

CSP 為什麼不是第一線主答案

CSP（Content Security Policy）很好。
它可以：

• 限制可載入腳本來源
• 降低 inline script 風險
• 幫你縮小 XSS 成功後的影響

但它通常是：

defense-in-depth，不是主控制。

因為：

• 不是所有環境都配置得好
• 容易誤設
• 不能取代安全輸出處理
• 有些 XSS 型態仍可能繞過或部分成功

考試思路

如果題目問：

• most effective
• primary mitigation
• core control

先想：
output encoding + input validation

如果問：

• additional safeguard
• layered defense
• defense-in-depth

再想：
CSP

3.3 Broken Authentication / MFA 詳解

Broken Authentication 是什麼

使用者身分驗證流程有弱點，導致帳號被冒用、接管、濫用。

現在新版 OWASP 常叫：
Identification and Authentication Failures

常見問題

• 弱密碼
• 密碼重用
• 暴力破解
• session 管理不佳
• credential stuffing
• 缺少 MFA

為什麼 MFA 是最直接主控制

因為就算密碼被偷：

• 攻擊者仍缺第二因素
• 單一憑證失守不等於直接入侵

所以題目問：
most effective / most direct mitigation
常常就是：
MFA

那 session management 重不重要嗎

很重要。
但它更像：

• 補強整體登入安全
• 保護 session 生命週期
• 防止 session hijacking

它不是在所有題目裡都比 MFA 更「直接」。

考試判斷法

• 題目問 Broken Authentication 最有效 → 先想 MFA
• 題目問 session hijacking / cookie / timeout / fixation → 再想 session management

3.4 SQL Injection 為什麼一直存在

SQLi 是什麼

把不可信輸入拼進 SQL 查詢，導致查詢語意被改掉。

直接技術控制

• Parameterized queries / prepared statements
• ORM 正確使用
• Input validation
• Least privilege
• 安全錯誤處理

但為什麼考題常不選「只做輸入檢查」

因為很多題目不是問：

「眼前這一個點怎麼擋？」

而是在問：

「為什麼這類問題一直重複發生？最有效的根因解法是什麼？」

那答案就會往：

• SDLC
• Secure coding standard
• Code review
• SAST / DAST / SCA
• Security gates
• 開發前移（shift left）
• DevSecOps

所以這題的層次要分清楚

• 技術層立即修補：parameterized queries
• 組織層根因治理：DevSecOps / Secure SDLC

3.5 你要建立的答題習慣

遇到安全控制題，先問自己：

第 1 步：題目在問哪一層？

• 威脅分類？
• 風險排序？
• 單點技術控制？
• 架構層治理？
• 流程層根因？

第 2 步：題目在問 primary 還是 secondary？

• primary / most effective / most direct
• 還是 defense-in-depth / additional / supporting

第 3 步：題目在問眼前症狀，還是根因？

• 單點漏洞修補
• 還是 SDLC / governance / architecture 問題

這三步一做，你的命中率會高很多。

4. 超濃縮考前版

Threat Modeling

• STRIDE = 分類威脅
• DREAD = 排序風險
• PASTA = 完整風險導向流程

TLS

• ServerHello = 協商
• Certificate validation = 驗 server 身分
• anti-MITM 核心 = 先確認對方身分
• Session key = 保護後續資料
• Kerckhoffs = 安全靠 key，不靠藏系統

OWASP / AppSec

• XSS 主控制 = output encoding + input validation
• CSP = defense-in-depth
• Broken Authentication 最直接主控制 = MFA
• SQLi 根因治理 = Secure SDLC / DevSecOps
• SQLi 直接技術控制 = parameterized queries