從需求進入

從需求面進入本模組、從 0.8 資安與資料保護需求 開始——該章節定義六議題（權限分級 / 伺服器防護 / 資料遮罩 / 傳輸保護 / 密鑰與秘密 / 稽核追蹤）、各別 link 到本模組對應章節（7.2-7.7）。本模組是該六議題的 implementation-ready 層、提供問題節點、判讀訊號、風險邊界與交接路由。

模組方法

問題驅動方法的核心是讓案例退到證據角色，讓知識網以服務環節問題為主體。

1. 先定義服務環節問題與責任邊界。
2. 再定義判讀訊號與風險後果。
3. 接著定義交接路由與前置控制面。
4. 最後在問題觸發時引用對應案例。

模組分工定位

本模組提供觀念、判讀與路由。實作細節由對應模組承接，確保概念層與實作層分工清晰。

• backend/04-observability：偵測、稽核訊號、證據鏈與 alert / dashboard 實作。
• backend/05-deployment-platform：入口、部署與平台邊界實作。
• backend/06-reliability：驗證、回復與變更節奏實作。
• backend/08-incident-response：分級、指揮、通報與復盤實作。

案例驅動讀法

資安案例的核心讀法是先判斷事件發生在 identity、credential 還是 network control plane，再選擇對應治理控制。

反例與規模對照入口： 7.C9 反例 / 7.C10 對照。

回退判讀寫法見 0.C4 回退判讀寫法，資安案例要優先保留身份作用域、憑證輪替、例外權限與控制面擴散條件。

從章節到實作的 chain

各章節交付三樣：問題節點清單、判讀訊號、控制面 link。判讀完成後沿兩條 chain 進入 implementation：

1. Mechanism chain：點問題節點表的 [control-name] link 進 knowledge-cards、那層展開機制 / 邊界 / context-dependence。例：[authentication] 的 knowledge-card 是該 control 的 mechanism SSoT。
2. Delivery chain：章節「交接路由」欄位指向下游模組——04-observability（偵測 / 稽核 / 證據訊號）/ 05-deployment-platform（入口 / 配置 / 平台邊界）/ 06-reliability（驗證 / 回退 / 演練）/ 08-incident-response（分級 / 指揮 / 通報 / 復盤）。

兩條 chain 走完，控制面交付完整。Implementation 強度取決於兩條 chain 的完成度，章節閱讀本身完成 routing 階段。

各章節在「從本章到實作」段給該章的具體 control-name 例子跟交接路由 list、本段是模組級的共用規格。

Vendor / Platform 清單

資安控制服務見 vendors — 先以 index 大綱規劃身份、IAM、Secrets、KMS、WAF、PKI、供應鏈、SIEM 與 DLP 服務頁。這層目前只做服務頁教學大綱，不展開個別服務正文。

Deep article（vendor 自身的配置、故障、容量）跟 migration playbook（跨 vendor 遷移流程）的撰寫進度見 vendors/ 的「內容覆蓋進度」段。

章節列表

模組完成狀態

主章目前已形成基礎問題節點、藍隊操作循環、跨模組延伸章節與推演素材庫，並新增 7.27 的 credential rotation 實作示範。素材庫已完成 11 張 field cases、4 張 scenarios 與 7 張 control patterns，並回寫到 7.B1、7.B9、7.B12 與 7.24。比例設計依 素材庫比例支撐主情境的反向驗證，文章主情境保持 4-5 個、素材庫保留 2-3 倍來源做反向驗證。資安章節進入穩定維護狀態。

下一輪推演大綱

推演資產化的完成條件是讓讀者能從一個事故壓力出發，依序找到案例卡、情境卡、控制模式與回寫章節。這條路徑完成後，資安章節即可進入穩定維護狀態。

本輪輸出

本輪已完成主章的問題節點、藍隊循環與延伸章節骨架，並把設計輸入、放行判準、可靠性共同控制面、事故回寫與成熟度節奏接回後端實作路由。

跨分類引用

• → infra 模組二：身分與憑證地基：IAM role / policy、OIDC 短期憑證與權限邊界設計，是本模組 secret management 與 credential rotation 的地基層
• → infra 模組八：治理好習慣：secrets 不進 code 的儲存與引用模式、密鑰命名規範

讀法

資安服務要從控制問題進入。讀者如果要處理身份與授權，先回到 7.2 身分與授權邊界；如果要處理秘密與機器憑證，先回到 7.6 秘密管理與機器憑證治理；如果要處理入口與伺服器暴露，先回到 7.3 入口治理與伺服器防護。

教學順序同步

資安服務頁的教學順序是先建立 identity / IAM，再進入 secrets / KMS / PKI、edge、supply chain、detection / DLP。這個順序對齊 checkout E6：讀者先理解誰能做什麼、秘密與金鑰如何生命週期化，再比較入口防護、artifact trust、偵測訊號與資料控制如何接到 release gate、evidence package 與 incident handoff。

T1 服務頁大綱

內容覆蓋進度

每個 vendor 服務頁下會擴充兩類文章：deep article（vendor 自身的配置、故障、容量、走 6-section 模板）跟 migration playbook（跨 vendor 遷移流程、走 6-type 結構）。「→ X」代表遷移到 X 的 playbook。

本章節 vendor 服務頁覆蓋率高（51 個 vendor 服務頁、上方「T1 服務頁大綱」跟「後續候選」段已全部建立），但 deep article / migration playbook 還在早期階段。對應的 backlog 議題見上方「T1 服務頁大綱」段每個服務群要回答的核心問題、跟各 vendor _index.md 的「預計實作話題」段。

服務頁標準章節

撰寫批次

後續候選（C 批次完成）

主流覆蓋檢查的重點是分開 preventive control、detective control 與 response handoff。IAM / KMS / WAF / policy-as-code 是 preventive control；SIEM / runtime detection / secret scanning 是 detective control；PAM、incident channel 與 evidence write-back 連到 08 的 response handoff。

Reading paths（51 個 vendor 的進入順序建議）

讀完 51 個 vendor 不是線性目的、是 依組織當前的安全成熟度跳讀。以下是四條常見路徑：

Path A — Startup baseline（< 50 人、cloud-native）： Okta → AWS IAM / Google Cloud IAM → AWS Secrets Manager / Google Secret Manager → Cloudflare WAF → GitHub Advanced Security → Datadog Security。共 7-8 個 vendor、預算敏感、cloud-native、SaaS 優先。

Path B — Enterprise multi-cloud（500+ 人、跨雲）： Okta + HashiCorp Vault → 各雲 IAM（AWS / GCP / Azure）→ AWS KMS + CloudHSM → SPIRE + cert-manager → Fastly NG-WAF → Snyk + Trivy → Splunk → Google DLP + Microsoft Purview。

Path C — Compliance-heavy（金融 / 醫療 / 政府）： Keycloak（資料主權）→ HashiCorp Vault + CloudHSM（FIPS 140-2 L3）→ cert-manager + Let’s Encrypt → Google DLP + Microsoft Purview → Cloud-native data policy → Google Security Operations（Mandiant + 大規模）。

Path D — 事故驅動補洞：先讀 7.C 案例 + 紅隊案例 對應自家事故、再回 vendor 頁找控制面缺口。例如 helpdesk social engineering 失效 → Okta callback workflow + Splunk anomaly detection；signing key 失控 → AWS KMS / Azure Key Vault HSM-bound key + Google Security Operations cross-tenant token forging detection。

Cross-category 整合 stack

實務 stack 通常跨多個類別組合、不是單一 vendor。下表列三個典型 stack：

Stack 不是一次到位、按 Path A → B → C 的成熟度演進加 vendor。每加一個 vendor 都要對應一個 已被 case 庫驗證 的失效模式 — 不是「業界都用」就上。

下一步路由

• 上游：7.2 身分與授權邊界
• 上游：7.6 秘密管理與機器憑證治理
• 上游：7.12 供應鏈完整性與 Artifact 信任
• 案例：7.C 資安案例正文
• 服務路徑：7.27 Credential Rotation with Scoped Evidence 實作示範