服務定位

Azure Key Vault 的核心定位是 三合一 secret + key + cert service 加 Azure-native secret-less 取用。AWS 是 Secrets Manager + KMS + ACM 三個獨立 service、職責邊界清楚但要管三套權限；GCP 是 Google Secret Manager + Cloud KMS + Certificate Authority Service 三個獨立；Azure 把這三件事合在 Key Vault — 同一 RBAC role 可同時管 secret / key / cert、減少 IAM 維護成本、但治理上需要在 Vault 內用 naming convention + 多 Vault instance 自己劃分敏感度邊界（例：production secret / cert 分開不同 Vault、admin access 分人）。

跟 HashiCorp Vault 相比、Azure Key Vault 是 Azure-only 的 static-focused 服務 — 沒有 dynamic credential engine、沒有 transit encryption-as-a-service、沒有跨雲統一介面。優勢是 零運維 + Managed Identity 取用免 client secret + Premium tier 直接 HSM-backed。Azure-heavy + 一站式 secret/key/cert + secret-less workload 取用是 Key Vault 的甜蜜點。

本章目標

讀完本頁、讀者能判斷：

1. 哪些 secret / key / cert 適合放 Key Vault、哪些該走 Managed HSM（FIPS 140-2 Level 3 需求）
2. Access Policy 跟 Azure RBAC 兩種授權模型的差異與 migration 路徑
3. Soft Delete + Purge Protection 的 防誤刪 與 防勒索 邊界
4. 何時用 Key Vault、何時改走 HashiCorp Vault（跨雲 + dynamic credential）的取捨

最短判讀路徑

判斷 Azure Key Vault deployment 是否健康、最少看四件事：

• 誰能 access：Vault 用 Access Policy 還是 Azure RBAC、是否還有 legacy Access Policy 沒清掉、Managed Identity 的 role assignment 是否最小化（Key Vault Secrets User 而非 Key Vault Administrator）
• RBAC vs Access Policy 模型：production 應該全走 Azure RBAC（跟 Azure RBAC vendor 同套）、舊 Access Policy 是 migration backlog、不可長期兩軌並存
• Soft Delete + Purge Protection：兩個都應開、Soft Delete 90 天 retention、Purge Protection 開了之後連 owner 都不能立即 purge — 防誤刪 + 防 ransomware 一次性刪光
• Diagnostic Logs：Key Vault 預設不記操作 log、必須手動配 Diagnostic Setting 推 Log Analytics / Event Hub / Storage — 沒這層 KeyVaultGet / SecretGet 都沒 audit trail

四件事任一缺失、就是 Audit Log 與 Secret Management 邊界的待補項目。

日常操作與決策形狀

Vault Standard vs Premium：Standard 用 software protection（key 存在 Microsoft-managed software boundary）、Premium 用 FIPS 140-2 Level 2 HSM-backed key、key material 在 HSM 內、不可 export。Premium 適合 signing key / wrapping key 等高敏 key、Standard 適合 application secret + 常規 envelope encryption key。要 FIPS 140-2 Level 3、Standard 跟 Premium 都不夠、必須用 Managed HSM。

Access Policy vs Azure RBAC（兩種授權）：Access Policy 是 Key Vault legacy 模型 — 在 Vault 物件上掛一張 capability 表（Get / List / Set / Delete / Encrypt / Sign 等細粒度權限）、跟 Azure RBAC 體系獨立。Azure RBAC 模型是新版 — 用 Azure built-in role（Key Vault Secrets User / Key Vault Crypto User / Key Vault Administrator）走 Entra ID 統一身份治理。production 全走 RBAC、舊 Vault 的 Access Policy 是 migration backlog — 兩軌並存會出現 RBAC 拒絕但 Access Policy 允許 的權限漏洞。

Managed Identity 取用（secret-less）：Azure VM / Function / App Service / AKS pod 走 Managed Identity 直接呼叫 Key Vault API — 不需要存 client secret 或 cert。Workload 拿 IMDS token、token 帶 Entra ID identity、Key Vault 端用 RBAC role assignment 驗證 — 這是 Azure-native 的 secret-less 取用模式、跟 AWS IAM Role for Service Account / GCP Workload Identity 同類設計。production 應該 只允許 Managed Identity 取用、禁用 service principal + client secret。

Secret rotation（手動 / event-driven）：Key Vault Secret 沒有像 AWS Secrets Manager 內建的 rotation Lambda。Rotation 走兩條路：手動更新 secret version（app 端拉新版）、或 Event Grid 通知 secret 過期 + Azure Function 觸發 rotation。後者需要自己寫 rotation logic、Key Vault 只提供 版本管理 跟 過期通知、不負責執行 rotation。

Key Rotation Policy：Key（不是 Secret）有 native Rotation Policy — Vault 在 key 到期前自動生成新版、舊版保留可解密但不再 encrypt。policy 設 rotationPeriod + notifyBeforeExpiry、Key Vault 自動跑、不需要外部觸發。Secret 沒這功能、Key 才有。

Certificate auto-renewal：Certificate object 可整合 Issuer（DigiCert / GlobalSign / 自簽）做 auto-issue + auto-renew — Key Vault 在到期前自動跑 CSR、向 Issuer 申請新 cert、寫回同一個 Certificate object（保留歷史版本）。比起手動跑 OpenSSL + 寫進 AWS ACM、Certificate object 的優勢是 Issuer 在 Vault 端統一治理 — 不過只支援整合過的 public CA。

Soft Delete + Purge Protection：Soft Delete 預設開（2020 後新 Vault 強制開）、delete 後 90 天 retention、Recover 可救回。Purge Protection 是 額外 開關 — 開了之後 retention 內任何人（包含 subscription owner）都不能 purge 立即清除、必須等 90 天到期才會物理刪除。這是 防勒索 的關鍵 — 沒 Purge Protection、attacker 拿到 owner role 可以 delete + purge 一次性清光。

Private Endpoint：Key Vault 預設是 public endpoint（FQDN 走 internet）。Private Endpoint 把 Vault 拉進 VNet、只走內網存取 — 高敏 Vault 應該關 public access、強制走 Private Endpoint + Firewall rule（IP 白名單）。

核心取捨表

選 Azure Key Vault 的核心訴求：Azure-only、需要 secret + key + cert 一站式、workload 走 Managed Identity secret-less 取用、可接受 無 dynamic credential。需要跨雲統一 secret 控制面、或要 dynamic database credential、走 HashiCorp Vault。

進階主題

Managed HSM（dedicated）：Managed HSM 是 dedicated single-tenant HSM cluster、FIPS 140-2 Level 3、跟 multi-tenant 的 Key Vault Premium 是不同 service。Managed HSM 適合 主權合規（key material 完全自有控制權、Microsoft 也不可存取）、金融 / 醫療 / 政府場景。代價是 貴 跟 初始化要走 ceremony（多人持有 activation key、Microsoft 不可單方面操作）— 不是 Premium 的簡單升級、是另一條 product line。

Premium tier HSM-backed Key：Premium tier 的 key 有 HSM-protected 屬性、key material 在 multi-tenant HSM 內、API call 還是走標準 Key Vault endpoint、但 cryptographic operation 在 HSM 跑。比 Standard 慢一點、價格高、適合 signing key / wrapping key / root encryption key — 一般 application secret 還是 Standard 即可。

Certificate Issuer 整合：Vault 內可註冊 Issuer（DigiCert / GlobalSign / Entrust）、提供 API credential、Vault 在 Certificate 到期前自動跑 CSR、向 Issuer 申請、Issuer 簽完寫回 Vault。Self-signed / Unknown Issuer 也支援、後者表示 Vault 產 CSR、人或 pipeline 拿去外部 CA 簽完再 import 回 Vault。

Cross-tenant key access（federated identity）：Key Vault 可允許跨 Entra ID tenant 的 service principal 取用 — 透過 Federated Identity Credential（Workload Identity Federation）、外部 tenant 的 identity（甚至 GitHub Actions OIDC、AWS workload）拿 token 來 Key Vault 驗證。這是 cross-cloud workload 拉 Azure secret 的方式、不需要存 Azure service principal credential。

跟 Entra ID Conditional Access 整合：Key Vault 用 Azure RBAC 模型時、可走 Conditional Access policy — 特定 IP、已 enrolled 裝置、MFA 已驗證 才能取用 secret / key。production 高敏 Vault 應該疊 Conditional Access、避免單純 RBAC 在 token leak 時就直接被存取。

排錯與失敗快速判讀

• Diagnostic Setting 沒開：production Vault 啟用後忘了配 Diagnostic Setting 推 log、事故發生時無 SecretGet / KeyDecrypt 紀錄 — 啟動 checklist 必含「Diagnostic Setting → Log Analytics」、Azure Policy 強制全 subscription Vault 都配
• Access Policy 跟 RBAC 兩軌並存：migration 過程中 RBAC 已切換但舊 Access Policy 沒清、出現 RBAC 拒絕但 Access Policy 允許 — migration 一次切斷、跑 az keyvault update --enable-rbac-authorization true 後清空所有 Access Policy
• Soft Delete 沒開 / Purge Protection 沒開：誤刪 secret 救不回、或 attacker 拿到 owner role 一次 purge 清光 — 新 Vault 兩個都強制開、Azure Policy 阻擋 enablePurgeProtection: false 的 Vault 建立
• Managed Identity role 過寬：給 workload identity Key Vault Administrator 而非 Key Vault Secrets User — workload 拿到 admin role 等於可改 ACL — role assignment 走 least privilege built-in role
• Premium key 跑非 HSM operation：Premium key 配錯 attribute、key 變成 software-protected 而非 HSM-protected — 建 key 時明示 --protection hsm、CI 驗證 key attribute
• Certificate auto-renew Issuer credential 過期：Vault 內 DigiCert API credential 過期、auto-renew 默默失敗、cert 到期前才發現 — Issuer credential 也要 rotation + monitor
• Public access 開著：Vault 沒關 public endpoint、secret 暴露在 internet（雖然有 RBAC、但 attack surface 多一層）— 高敏 Vault 強制 Private Endpoint + Firewall rule

何時改走其他服務

不在本頁內的主題

• Key Vault REST API / Azure CLI 完整 reference
• Managed HSM activation ceremony 完整步驟
• Bicep / Terraform 配置 Key Vault 的完整 IaC 範例
• Certificate Issuer（DigiCert / GlobalSign）的合約與計價細節
• 每個 Entra ID role 的細粒度 permission map

案例回寫

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、7.5 傳輸信任與憑證生命週期（Key Vault Certificate + Managed HSM 為 TLS / signing key 的 root custodian）、7.2 身分與授權邊界
• 平行（secret store）：AWS Secrets Manager、Google Secret Manager、HashiCorp Vault
• 平行（KMS-class）：AWS KMS、Google Cloud KMS、CloudHSM（Key Vault 是跨類 vendor、同時是 secret store 跟 key management）
• 下游：Azure RBAC（Managed Identity + RBAC 取用模型）
• 下游：cert-manager（K8s workload cert 自動化、可整合 Key Vault Certificate）
• 跨模組：8 事故處理 vendor 清單（Key Vault 事件如何 routing 進 IR 流程）
• 官方：Azure Key Vault Documentation

服務定位

Purview 的核心 first-class concept 是 sensitivity label — 一個 label 帶動 encryption、access restriction、watermarking、DLP policy 多個控制、可由 user 手動標也可由 trainable classifier 自動標、跨 Office docs / SharePoint / Teams / Power BI / endpoint 繼承。其上的模組包含：Data Loss Prevention (DLP) — 跨 Exchange / SharePoint / Teams / Endpoint / Microsoft Defender for Cloud Apps (MDA) 的 policy 引擎；Data Map / Data Catalog — Azure / 多雲資料源 discovery + lineage；Unified Audit Log — M365 + Azure AD + Defender 統一 audit；Insider Risk Management — 行為 risk score 偵測內部威脅；Communication Compliance — Teams / email 內容 review。

跟 Google DLP 比、Purview 走 information protection 層 + label-driven + endpoint inline、Google DLP 走 infrastructure 層 + content-based + transformation pipeline。跟 Splunk 比、Purview 不是 SIEM — Unified Audit Log 是 event source、Splunk 或 Microsoft Sentinel 才是 aggregation 平面；Purview audit 進 SIEM 是常見組合。跟雲端原生 data policy（BigQuery Column-Level Security / S3 Block Public Access）比、Purview 跨平台 + label 統一、雲端原生只覆蓋單一雲、不同責任邊界。

關鍵張力：label 設計簡單度 ↔ 自動分類精準度 ↔ 使用者教育成本 是 Purview 導入時最常踩的三角。label 太細（10+ 層 hierarchical）使用者選不出來、label 太粗（只有 Public / Internal / Confidential）DLP policy 觸發精度不夠。Trainable classifier + auto-labeling 是補救、但要投入訓練樣本維運。

本章目標

讀完本頁、讀者能判斷：

1. Purview 在 information protection stack 中承擔哪一段（label / DLP / audit / insider risk）、跟 Azure RBAC + Entra ID / SIEM / cloud-native policy 怎麼分工
2. Sensitivity label 的層級設計（粗細、auto-label 條件、跨 Office / endpoint / Power BI 一致性）
3. DLP policy 的 location + condition + action 三軸如何配置、跟 endpoint DLP / MDA 怎麼覆蓋 SaaS shadow IT
4. Purview 計費分 SKU 的 trap、E3 + add-on vs E5 license 的決策

最短判讀路徑

判斷 Purview deployment 是否健康、最少看四件事：

• Label 層級設計：sensitivity label 幾層、是否 hierarchical（parent / sublabel）、是否定義 auto-labeling 條件（含某 SIT、來自某 SharePoint site、某 user group 建立）、跨 Office / endpoint / Power BI / Teams 是否一致繼承
• DLP policy coverage：location 是否涵蓋 Exchange + SharePoint + Teams + Endpoint + MDA、condition 是否用 SIT + label 雙軸（而非只看 SIT）、action 是否依風險分層（block / warn / encrypt / audit-only）
• Audit + Insider Risk 證據鏈：Unified Audit Log retention 是否足夠（預設 180 天、E5 可到 1 年、長期要 archive）、Insider Risk policy 是否定義「離職前 30 天 mass download」「異常時段 access」等 organization-specific pattern、是否 export 進 SIEM
• License 跟模組對應：Information Protection / DLP / Insider Risk / Communication Compliance 屬不同 SKU、是否買到所需模組、E3 + add-on 還是 E5、避免「policy 寫好但 license 沒解鎖功能」

四件事任一缺失、就是 Data Protection and Masking Governance 邊界的待補項目。

日常操作與決策形狀

Sensitivity label 是 first-class control：label 不只是 metadata、而是 單一 identifier 帶動多個控制 — 標到 document 後同時觸發 AES encryption（透過 Azure Rights Management）、access restriction（誰能開 / 列印 / 轉寄）、watermarking、DLP policy condition、Power BI dataset 繼承。Hierarchical label（Confidential → Confidential\Finance、Confidential\Legal）讓子部門客製、但層級超過 3 層使用者選擇困難。Label 設計要先決定 跨 BU 共用 base set + 每 BU 自家 sublabel 的拓撲、不是一次列 20 個。

Trainable classifier 補 SIT 不足：預定義 SIT（Sensitive Information Type、如 credit card / SSN / passport）涵蓋通用 PII / PCI、但 organization-specific 敏感資料（內部 product spec、合約模板、未公開財報草稿）SIT 抓不到。Trainable classifier 用 ML 訓練 — 提供 50-500 個正例 + 反例、Purview 訓 classifier、跑 staging 驗證 precision / recall 達標再 promote。維運成本是樣本要定期 refresh、business 變動時 classifier 會 drift。

DLP policy = location + condition + action：location（Exchange email / SharePoint site / Teams chat / OneDrive / Endpoint / MDA-managed SaaS）決定 在哪攔、condition（含某 SIT N 次 / 標 Confidential / 來自外部 user / 含某 trainable classifier 命中）決定 何時觸發、action（block + notify / encrypt / quarantine / audit-only / require justification）決定 怎麼處理。production 不該一上來就 block — 先 audit-only 跑 2 週收集 baseline、tune false positive、再 promote 到 warn、最後選擇性 block 高風險 condition。

Endpoint DLP（Windows / macOS）：透過 Microsoft Defender for Endpoint agent 在端點 inline 攔截 — copy to USB / upload to non-corp cloud（Dropbox / Google Drive personal）/ print / paste to browser、針對標 Confidential 的 document 自動 block 或 warn。跟 Datadog Security 的 Sensitive Data Scanner 不同層 — 後者 scan log / APM payload 事後發現、Endpoint DLP 事前在 user action 攔截。Endpoint DLP 要 Defender for Endpoint license + Purview Endpoint DLP add-on 雙重 license、容易踩計費 trap。

Microsoft Defender for Cloud Apps (MDA) 整合：MDA 是 Microsoft 的 CASB（Cloud Access Security Broker）、把 Purview DLP policy 延伸到非 Microsoft 的 SaaS（Salesforce / Box / Slack / Google Workspace）。MDA 透過 API connector 或 reverse proxy 攔截 SaaS 上的 sensitive document、套 Purview label / DLP action。覆蓋 shadow IT 跟 third-party SaaS 是 MDA 的價值、但每個 connector 都要單獨配置 + 維運。

Data Map / Data Catalog discovery + lineage：Purview Data Map 自動掃描 Azure Storage / Synapse / SQL DB / Power BI / 部分 AWS / GCP 資料源、產 metadata + classification + lineage。跟 information protection 模組是不同 surface — Data Map 偏 data governance（誰擁有什麼資料、資料流向哪）、information protection 偏 control（誰能存取、能否 export）。中大型組織通常分開 onboard、不要一次全推。

Unified Audit Log 是 SIEM source：M365 + Azure AD + Defender + Purview 自身的 audit event 統一進 Unified Audit Log、可透過 Compliance Center search、或 Office 365 Management Activity API export 到 Splunk / Sentinel / Elastic Security。Purview 自己不做 correlation / alerting、要做跨來源 detection 必須接 SIEM。Retention 預設 180 天、E5 license 1 年、長期合規要走 Audit Premium 或 archive 到 long-term storage。

Insider Risk Management 跟 SIEM 互補：SIEM 主軸是 external threat + cross-source correlation、Insider Risk 主軸是 single-user 行為 risk score over time — 離職前 30 天 mass download、異常時段存取 sensitive folder、跨 sensitivity tier 大量 access。Risk score 累積到 threshold 觸發 case、進 Compliance officer review queue。預定義 policy template（departing employee、disgruntled employee、data leak）可快速 onboard、organization-specific pattern 要自己定。

跟 Azure RBAC + Entra ID 整合：Purview policy 的 user / group 引用直接吃 Entra ID identity、sensitivity label 的 access restriction 也走 Entra ID group。Compliance / Information Protection admin 是 Entra ID role、應該收緊到少數人 + 走 PIM (Privileged Identity Management) just-in-time elevation。Break-glass account 要單獨設計、不能跟日常運維混。

核心取捨表

選 Purview 的核心訴求：M365 / Office / collaboration 為主、需要 label 統一控制跨 document / email / Teams / endpoint、insider risk 是主要威脅、且能買到 E5 或對應 add-on。Non-Microsoft 環境或 infrastructure data 為主（BigQuery / S3）走 Google DLP / cloud-native policy 更直接、不要硬塞 Purview。

進階主題

Trainable classifier 的 lifecycle：classifier 不是 train 一次永久用、business context 變化（產品線改、合約模板更新、合規詞彙變）會讓 precision / recall 下降。Production 應定期 review classifier hit / miss、補新樣本 retrain、跟 SIT 互補不是替代 — 通用 PII 走 SIT 穩定、organization-specific 走 trainable classifier。Staging 跑 2 週驗證 false positive < threshold 才 promote。

Endpoint DLP 跟 Datadog Security Sensitive Data Scanner 的不同層：Endpoint DLP 在 user action 當下攔截（copy / upload / print）、Datadog Sensitive Data Scanner 在 log / APM ingestion 時 scrub。兩者不互斥 — Endpoint DLP 防 資料離開端點、Datadog Scanner 防 PII 寫進觀測 log、典型 Microsoft + Datadog 環境會並存。

Data Loss Prevention for Power BI：Power BI dataset / report 可繼承 Purview sensitivity label、export to Excel / PDF 時 label 跟著走、DLP policy 可條件 標 Highly Confidential 的 dataset 不能 export。是 Microsoft analytics stack 比 Tableau / Looker 在 information protection 上的關鍵優勢。

Information Barriers（內部 walled garden）：合規場景（投行 research vs trading desk、law firm 對手客戶）需 organization 內部某 group 不能 Teams 對話 / 不能 share 檔案、Purview Information Barriers 設定 segment + policy 阻擋。是 compliance-specific feature、非合規環境用不到、但金融 / 法律 / 顧問業是 must-have。

E3 + add-on vs E5 的計費決策：Purview 完整功能（trainable classifier、Endpoint DLP、Insider Risk、Communication Compliance、Audit Premium）要 E5 license、單價約 E3 的 1.5 倍。中小組織從 E3 + 個別 add-on（Information Protection and Governance E5、Insider Risk Management E5）起步、避免一次 E5 全推；大組織直接 E5 反而簡化計費跟 license 管理。

排錯與失敗快速判讀

• DLP policy 寫好但沒觸發：condition 或 location 設錯（policy 只覆蓋 Exchange 沒包 SharePoint）、或 license 沒解鎖該模組（Endpoint DLP 要額外 add-on）— 在 Compliance Center 看 policy match 統計、確認 license 對應
• 使用者抱怨 label 選不出來 / 選錯：label 層級太細 + 沒有預設 label、user 不知該選哪個 — 簡化到 3-5 個 base label、用 auto-labeling 補自動分類、加 label tooltip
• Trainable classifier false positive 多：訓練樣本不足 / 正反例失衡 — 補樣本到 50+ per class、retrain、staging 跑 2 週驗證再 promote
• Audit log retention 不夠 / 合規查不到：預設 180 天、合規要 1 年以上 — 升 E5 或 Audit Premium、或 export 到 SIEM / long-term storage
• Insider Risk policy 太敏感 / 太多 case：預設 template 沒 tune organization baseline — 跑 audit-only 模式 30 天統計、調 threshold、加 user group 排除（VIP / legitimate bulk download role）
• Endpoint DLP 攔到合法業務操作：policy 沒區分 corp managed device vs BYOD、或沒給 user override + justification — 加 device compliance condition、設 warn + justification 而非直接 block
• MDA connector 落後 SaaS 新功能：API connector 有 lag、新功能未涵蓋 — 對高風險 SaaS 補 reverse proxy 模式、或在 SaaS 側設原生 DLP
• License 模組混亂：policy 寫好但功能沒解鎖、admin 不知道哪些要 E5 — 維護 license-to-feature 對照表、Compliance Center 警示「需要 license」要直接修

何時改走其他服務

不在本頁內的主題

• Microsoft 365 / Azure AD 完整管理（屬 Azure RBAC + Entra ID）
• eDiscovery 跟法律 hold 流程細節
• Microsoft Sentinel SIEM 完整配置（屬 SIEM 群、跟 Purview 是互補不是同一頁）
• Purview Data Map 對非 Azure 資料源（AWS / GCP / on-prem）的完整 connector 矩陣
• Compliance Manager 的法規對照與 scoring 細節
• Azure Information Protection (AIP) 舊版 client 的 migration 流程

案例回寫

Purview 在 07 案例庫沒有直接 vendor-level 事件、但 information protection + insider risk 角度跟多個案例對照：

下一步路由

• 上游：7.4 資料保護與遮罩治理、7.8 稽核軌跡與責任邊界
• 平行：Google DLP（infrastructure 層 DLP、跟 Purview 並存）、Cloud-native Data Policy (BigQuery + S3)（resource-bound access control、跟 Purview label-driven 互補）
• 下游：Splunk / Elastic Security（Unified Audit Log export 進 SIEM）
• 跨類：Azure RBAC + Entra ID（identity 基底）、Datadog Security（log PII scrubbing、不同層互補）
• 跨模組：8 事故處理 vendor 清單（Insider Risk case → IR routing）
• 官方：Microsoft Purview Documentation

服務定位

Entra ID 是 Microsoft 自有的 workforce IdP、跟 Okta 是直接競爭者。M365 / Azure-heavy 的組織通常直接用 Entra ID 當主 IdP；Okta-first 的組織可以把 Entra ID 當下游 SP（federation）、也可以雙 IdP 並存、但雙 IdP 的 break-glass 跟 lifecycle 路徑要重新設計。Entra ID 同時承擔 consumer-side 跟 partner-side 的 multi-tenant app 信任、跟 Auth0 在 B2C 場景有交集。

Azure RBAC 是 cloud resource permission engine、跟 AWS IAM / Google Cloud IAM 同層 — 都在解「身份對 cloud resource 能做什麼」。差異在 scope hierarchy — Azure 用 Management Group → Subscription → Resource Group → Resource 四層繼承、AWS 用 account + organization、Google 用 organization → folder → project。Azure RBAC 預期 role assignment 沿 scope 向下繼承、這跟 AWS 在每個 account 重新指派的習慣不一樣、跨雲團隊轉過來常踩到。

本章目標

讀完本頁、讀者能判斷：

1. 哪一段控制屬於 Entra ID（身份）、哪一段屬於 Azure RBAC（resource permission）、不要把兩層當同一件事
2. Entra ID tenant 的最低稽核需求（Global Admin、App Registration、Conditional Access、Managed Identity）
3. Azure RBAC 的 scope 設計、Custom Role 跟 PIM 何時必要
4. Entra ID 控制面事故的降級路徑、跟 Azure RBAC 出事的徵兆差異

最短判讀路徑

判斷 Azure 雙層體系是否健康、要分兩層各看兩件事、跟「日常操作與決策形狀」段的兩層結構對齊。

Entra ID 層（身份控制面）：

• 誰能做什麼：Global Admin / Privileged Role Administrator 的人數、是否走 PIM just-in-time、Conditional Access 是否強制 phishing-resistant 認證、break-glass 帳號是否 exclude 自所有 CA policy 又單獨監控
• 入口如何暴露：App Registration 是否限定 single-tenant、multi-tenant app 的 admin consent 流程是否經審查、Managed Identity 是否取代 service principal client secret

Azure RBAC 層（resource permission）：

• 誰能對 resource 做什麼：Owner / Contributor 在哪個 scope（Management Group 還是 Subscription）、production 環境是否用 Custom Role 收緊權限、有沒有 standing assignment 該改 PIM
• 證據是否可回查：Entra ID Sign-in Log / Audit Log 是否同步到 SIEM、Azure Activity Log 是否設保留與 alert、admin consent / role assignment 變更是否觸發 alert runbook

兩層任一邊任一條缺失、就是 Audit Log 與 Authorization 邊界的待補項目。

日常操作與決策形狀

Entra ID 層

User / Group / lifecycle：HRIS 推 SCIM 進 Entra ID、Entra ID 同步到下游 SaaS 跟 Azure RBAC group。決策點是 source of truth — 多數組織把 HRIS 設為人員來源、Entra ID 當分發層、避免雙寫造成 stale account。

Conditional Access 是 MFA 主要強制機制：MFA 不是設在 user 屬性上、是 Conditional Access policy 在登入時判斷 user / device / location / app / risk 後觸發。常見設定錯誤包含 exclude legacy auth 沒做、break-glass 規則太寬、emergency access 帳號沒獨立監控。Conditional Access 規則設計錯、就是高權限 bypass 的入口。

App Registration vs Enterprise Application：開發者註冊 multi-tenant app 走 App Registration（app 的定義）、組織 admin 為某 app 設定 SAML SSO / admin consent 走 Enterprise Application（該 tenant 對 app 的信任）。兩者常被混講、但安全意義不同 — App Registration 是「我們做了一個 app」、Enterprise Application 是「我們信任這個 app 用我們的身份」。Consent phishing 攻擊就是針對後者。

Managed Identity：Azure resource（VM、Function、AKS pod）自帶身份、不需要 service principal client secret、跟 Google Workload Identity Federation 同概念但 Azure-internal。System-assigned 跟 resource 生命週期綁定、resource 刪掉 identity 跟著刪；User-assigned 獨立、可跨 resource 共用。production 環境的服務存取 Key Vault / Storage 應走 Managed Identity、不該用 client secret。

Workload Identity Federation：Entra ID 可以 trust 外部 OIDC issuer（GitHub Actions、AWS、Google）、讓外部 workload 直接拿 Entra ID token、不用儲存 client secret。CI/CD 的 OIDC 整合是這層的主用例、比把 client secret 塞進 CI variable 安全很多。

Signing key 是 control plane 託管：Entra ID 不暴露 signing key、客戶沒有 rotate 它的能力。這層信任邊界一旦失守、客戶側 直接修不了、要等供應商發 patch 或公告 — Storm-0558 揭示了這條依賴的代價。客戶側能做的補強是 下游檢查 而非 上游修復：

• 訂閱 Microsoft Security Advisory（MSRC）+ tenant-specific notification、讓事件公告第一時間進 IR pipeline、不要靠新聞才知道
• SIEM alert anomalous token issuance pattern（跨租戶 token 在 Exchange / Graph API 出現異常存取序列）、不能只信 token signature valid
• 高敏 app 的 token validation 不只看 Entra ID 標準驗證、加 issuer + tenant + audience + nonce 多層比對、攻擊者偽造跨租戶 token 時可能漏掉某層
• Conditional Access 配 token protection（token binding to device）、降低 stolen token replay 的命中率
• IR playbook 預設 signing key 事件 一條 — 一旦供應商公告、強制 sign-out 高權限 user、token TTL 收短、回頭看 90 天 sign-in log 找異常

Azure RBAC 層

Scope 設計：role assignment 沿 Management Group → Subscription → Resource Group → Resource 向下繼承。在 Management Group 給 Contributor、底下所有 subscription / RG / resource 都繼承 — 這既是優點（統一治理）也是風險（誤指派擴散範圍大）。設計原則是 指派盡量低、不要對全 Management Group 給 Contributor。

Built-in role vs Custom Role：Owner（含 user access admin）/ Contributor（不含權限管理）/ Reader 是 built-in、通常太粗。production 環境需要 Custom Role 把 Microsoft.Storage/storageAccounts/listKeys/action 之類的高風險 action 收掉、只留 read。Custom Role 是 least privilege 在 Azure 的落實工具、不做就是用 Contributor 當預設、權限過寬。

Privileged Identity Management（PIM）：高權限角色（Global Admin、Subscription Owner、User Access Administrator）應走 just-in-time activation、需要 MFA 跟 approval、不該 permanent assignment。沒上 PIM 的組織通常會發現 standing Global Admin 超過 10 個、那是 phishing / token theft 的高價值靶。

Service principal vs Managed Identity：service principal 是 app 在 Entra ID 的代表、可以用 client secret 或 certificate 認證；Managed Identity 是 service principal 的特殊形式、由 Azure 自動管 credential。能用 Managed Identity 就不用 service principal client secret — 後者要自己 rotate、要存 secret management、容易 stale。

Azure Policy 是 RBAC 的補位：RBAC 管 principal 能不能對 resource 做這個 action、Azure Policy 管 允不允許這樣設定 resource（例如 storage account 強制加密、VM 只能用認可的 image）。RBAC 給 Contributor 的人可以建 storage account、但 Azure Policy 可以拒絕未加密的 storage account 建立 — 兩層互補、缺一不可。

核心取捨表

Azure 雙層體系的取捨要分開看 — 一張表回答 cloud resource permission 該選哪家（Azure RBAC vs AWS IAM vs Google IAM）、一張表回答 workforce IdP 該選哪家（Entra ID vs Okta）。兩個決策獨立、可以混搭（例如：Okta 當 workforce IdP + federate 到 Entra ID + 走 Azure RBAC 管 Azure resource）。

Azure RBAC vs AWS IAM vs Google Cloud IAM

Entra ID vs Okta（workforce IdP）

選 Entra ID 的核心訴求：M365 / Azure 重度使用、要跟 RBAC + Managed Identity 直接整合、能接受 Microsoft 控制面風險；選 Okta 的核心訴求看 Okta vendor 頁。

進階主題

Conditional Access 進階規則：除了 user / device / location 基本條件、進階場景包含 risk-based（Identity Protection 給的 user risk / sign-in risk）、token protection（token binding 到 device、防止 token replay）、authentication strength（強制 phishing-resistant factor）。production tenant 至少要有「Global Admin 必須走 phishing-resistant + compliant device」這條規則。

Privileged Identity Management（PIM）的設計細節：activation 要求 MFA、approval（高權限角色）、justification、時限（預設 8 小時、最長 24）。Access Review 是 PIM 的配套 — 季度檢視 standing assignment 是否還需要、不需要的撤掉。沒做 Access Review 的 PIM 等於只把問題從 standing 推到 誰申請就給 — 不是 least privilege。

Workload Identity Federation 跨雲：Entra ID 可以 trust GitHub Actions / GitLab / AWS / Google 的 OIDC issuer、讓 CI 直接拿 Azure token。同向也成立 — Azure workload 可以拿 Google ID token federate 進 GCP。多雲 CI 不該存任何 client secret、走 federation 比較安全。

Custom Role 設計實務：用 Microsoft.Authorization/roleDefinitions API 或 portal 定義、actions / notActions / dataActions 各自獨立 — actions 是 control plane、dataActions 是 data plane（讀寫 blob、key vault secret 內容）。常見錯誤是只收 actions 沒收 dataActions、結果 storage account 設定改不了但 blob 內容隨便讀。

Azure Policy 跟 Initiative：Policy 是單一規則、Initiative 是 policy 的集合（用來組 baseline、例如 CIS、ISO 27001）。Policy effect 有 audit / deny / deployIfNotExists、後者可以自動補洞（例如自動加 diagnostic setting）。RBAC + Policy 一起設計才是完整的 Authorization 邊界。

排錯與失敗快速判讀

• Global Admin 過多：standing Global Admin 超過 5 個就要警惕 — 上 PIM、把日常運維改用 Privileged Role Administrator + 特定 admin role group
• Conditional Access 規則漏 legacy auth：規則只 cover modern auth、IMAP / POP / SMTP 等 legacy protocol 不走 CA — 用「Block legacy authentication」baseline policy 補
• App Registration / Enterprise Application admin consent 沒審查：使用者自己 consent 把 mail.read 給三方 app、變 consent phishing 入口 — 關閉 user consent、改 admin consent workflow
• Service principal client secret 散落：CI / 服務裡有大量 client secret、rotate 沒節奏 — 改 Managed Identity（內部）或 Workload Identity Federation（跨雲 CI）
• Subscription Owner 太多：subscription 級 Owner 是高風險、應該收到 Management Group 級 Reader + 必要時 PIM activate Owner
• Azure Activity Log 沒進 SIEM：role assignment 變更、Key Vault access policy 變更只在 Azure portal 看得到、沒 alert — 用 Diagnostic Setting 推 Event Hub / Log Analytics、再進 SIEM
• Break-glass 帳號 exclude 自所有 CA policy、但沒監控：emergency access 帳號不能被 CA 鎖、但 任何登入都該 alert — 配對 Sign-in Log alert + 季度驗證可用

何時改走其他服務

不在本頁內的主題

• Entra ID 完整 SAML / OIDC / SCIM 規格細節
• Azure RBAC built-in role 完整清單與 action 對照
• Conditional Access policy template 細節
• Azure Policy 內建 initiative 完整清單
• Microsoft 365 / Defender for Identity 等周邊產品

案例回寫

下一步路由

• 上游：7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：AWS IAM、Google Cloud IAM、Okta
• 下游：7.6 秘密管理與機器憑證治理（Entra ID / Managed Identity 之後的 secret / key 層、Azure Key Vendor 個別 vendor 頁 S2 批次撰寫中）
• 跨模組：8 事故處理 vendor 清單（Entra ID / Azure 事件如何 routing 進 IR 流程）
• 官方：Microsoft Entra Documentation、Azure RBAC Documentation

觀察

Minecraft Earth 在 Azure Cosmos DB 的關鍵敘述（引自 Minecraft Earth and Azure Cosmos DB）：

Cosmos DB 平台特性（引自 Cosmos DB technical overview）：

• 配置擴容延遲：99 百分位 5 秒內生效
• 多 model 支援：SQL API、MongoDB API、Cassandra API、Gremlin、Table
• partition 動態分裂：透明
• 5 個 well-defined consistency levels（strong / bounded staleness / session / consistent prefix / eventual）

判讀

Cosmos DB 設計揭露三個全球 KV / document DB 的容量設計重點。

1. 一致性是 spectrum、不是 binary：Cosmos DB 提供 5 個層級、每個延遲與吞吐特性不同。AR 遊戲的玩家位置不需要 strong consistency（位置稍微 stale 沒問題）、但庫存交易需要 strong。同一 application 內不同操作選不同 consistency、是進階的容量設計策略。對應 01.5 transaction boundary 的一致性取捨。
2. Request Unit (RU) 是抽象容量單位：1 RU = 1 KB document 的 strong read 成本、寫成本約 5 RU、複雜 query 可達數百 RU。容量規劃變成「估每個操作多少 RU × 操作頻率」、跟「估 CPU / IOPS」是不同的思維。對應 9.6 容量規劃模型 的容量單位設計。
3. turnkey global distribution = 容量單位的全球複製：開啟跨地區後、容量在每個地區都 mirror 一份、成本乘以地區數。對中等規模團隊、turnkey 省下大量 ops、但要算「全球複製的成本是否值得業務需求」。對應 9.7 成本邊界與 efficiency。

需要警惕：「100 萬 RU/s 通過測試」是 壓測通過、不是 生產持續跑。實際營運要看 partition key 設計是否均勻、是否有 hot partition、跨地區複製延遲是否符合業務需求。

策略

可重用的工程做法：

1. 一致性需求分流到不同 collection / table：同一 application 不同操作有不同一致性需求、用不同 collection 配不同 consistency level、不要一刀切。
2. partition key 設計影響容量上限：跟 DynamoDB 一樣、hot partition 會讓名義容量達不到。Cosmos DB 的特殊性是「synthetic partition key」可以混合多個 field 強制分散。對應 9.4 Saturation Discovery 的 hot partition 識別。
3. RU-based pricing 鼓勵 query 最佳化：每個 expensive query 都吃 RU、優化 query 直接降成本。對應 9.9 Performance Improvement Loop 的持續改進迴圈。

跨平台等效：AWS DynamoDB Global Tables（global KV）、GCP Spanner（global SQL with strong consistency）、ScyllaDB Cloud（自管 Cassandra）都是對等候選。差異是 multi-model 廣度（Cosmos 最廣）vs 一致性深度（Spanner 最強）。

下一步路由

• 想設計全球分散 KV → 01 資料庫模組 + 9.6 容量規劃模型
• 想對照強一致全球 OLTP → 9.C10 Spanner
• 想對照單區 KV 高吞吐 → 9.C5 Amazon Ads DynamoDB
• 想理解 consistency level 的取捨 → 01.5 transaction boundary
• 想理解 Cosmos DB 五層一致性的工程選擇 → Cosmos DB 一致性層次工程
• 想做全球 multi-region write 衝突收斂 → Cosmos DB 多 region write 衝突
• 想拆 partition key 設計與全球分散搭配 → Cosmos DB partition key 設計

引用源

• Minecraft Earth and Azure Cosmos DB part 2: Delivering turnkey geographic distribution
• A technical overview of Azure Cosmos DB
• Azure Cosmos DB: Pushing the frontier of globally distributed databases

觀察

ASOS 在 Azure 的關鍵數字（引自 ASOS Microsoft Customer Story）：

關鍵業務驅動：「ASOS chose Azure Cosmos DB because of its global distribution and ability to handle heavy seasonal bursts like Black Friday」。

判讀

ASOS 案例揭露三個全球零售 KV 容量規劃重點。

1. Black Friday 24h 1.67 億 = 平均 1,930 req/sec、峰值 3,500 req/sec：峰值 / 平均 = 1.81 倍。這個比例顯示 Black Friday 「持續高峰」、不是「瞬間爆量」 — 24 小時內流量曲線相對平緩、跟 9.C15 Tixcraft 的「5 分鐘賣完」是完全不同形狀。對應 9.2 Workload Modeling 的負載形狀識別。
2. 48ms 平均響應 = 全球分散下 Cosmos DB 的代表性數字：英國時尚電商、客戶遍及全球、Cosmos DB 在每個地區複製、讀取在最近 region 完成。這個 48ms 包含網路、DB、應用層 — DB 本身可能只佔 5-10ms、其他是網路與應用層。對應 9.12 SLO 與 Performance Budget 的 latency budget 分解。
3. 85K SKU + 每週新增 5K = 高更新頻率 catalog：商品資料不只是讀、還有頻繁更新（價格、庫存、推薦排序）。這層 write throughput 對 Cosmos DB partition key 設計（通常用 category_id 或 brand_id）至關重要。對應 9.4 Saturation Discovery 的 hot partition 識別。

需要警惕：這是 2016 年的數字、過去 10 年 ASOS 應該成長很多。但 1.67 億 req/24h 跟 33 orders/sec 對許多新興電商仍是天花板級數字、可作為「中大型零售」對標。

策略

可重用的工程做法：

1. Black Friday 類「持續高峰」適合 provisioned + scheduled scaling：跟 flash-sale 的「on-demand 吃彈性」不同、Black Friday 整天高、用 provisioned 比較划算。對應 9.11 高峰事件準備 的可預期峰值準備。
2. 全球零售用 Cosmos DB / DynamoDB Global Tables：客戶在哪、讀取就在哪、避免跨洲 latency。對應 9.C10 Spanner 的全球分散取捨。
3. 微服務 + Cosmos DB 是電商現代化典型路徑：從單體 → 微服務、從關聯式 DB → multi-model NoSQL、是 2016 後零售業常見遷移。對應 01 資料庫模組 與 05 部署平台模組。

跨平台等效：AWS DynamoDB Global Tables + Lambda、GCP Firestore + Cloud Run 都可以實作對等架構。差異是 Cosmos DB 的 multi-model（同一服務支援 SQL、Mongo、Cassandra、Gremlin、Table API）、AWS 對應有 DynamoDB（KV/Document）+ Neptune（Graph）+ Keyspaces（Cassandra）等多個服務。

下一步路由

• 對照其他可預期峰值 → 9.C1 AWS Prime Day / 9.C13 Hotstar IPL
• 對照 flash-sale-spike → 9.C15 Tixcraft
• 想對照其他 Cosmos DB 使用 → 9.C11 Minecraft Earth
• 想規劃全球電商 → 01 資料庫模組 + 9.6 容量規劃模型
• 想拆 Black Friday 容量背後的 RU 成本與 sizing → Cosmos DB RU 成本模型與 sizing
• 想做電商 partition key 設計 → Cosmos DB partition key 設計

引用源

• ASOS – Online retailer uses cloud database to deliver world-class shopping experiences
• Azure Cosmos DB

觀察

Microsoft 365 在 Cosmos DB 的關鍵敘述（引自 Microsoft 365 boosts usage analytics with Azure Cosmos DB）：

關鍵敘述：「The team decided to replace MongoDB with Azure Cosmos DB, a fully managed globally-distributed, multi-model database service designed for global distribution and virtually unlimited elastic scalability.」

判讀

Microsoft 365 案例揭露三個全球 SaaS 分析平台的工程重點。

1. MongoDB → Cosmos DB 是「相容 API + 升級擴展性」的遷移路徑：Cosmos DB 提供 MongoDB API 相容、應用層程式幾乎不用改、但底層儲存改用 Cosmos DB 的分散式架構。這層遷移成本遠低於改寫 application 到 native Cosmos DB SQL API、適合大規模既有系統。對應 01.4 database migration playbook、跟 9.C20 Zomato 形成對照。
2. 分析平台 vs 交易平台的 DB 取捨不同：交易平台優先 latency + consistency（9.C10 Spanner）、分析平台優先 throughput + global distribution + cost。Cosmos DB 5 個 consistency level 讓分析場景可以選 weakest（eventual / session），換最大 throughput。對應 9.C11 Minecraft Earth 同思維。
3. Microsoft 自家產品 dogfood Cosmos DB：跟 Amazon Prime Day 用自家 DynamoDB（9.C1）、Google 自家用 Spanner（9.C10）一樣 — 雲商旗艦 DB 都會用在自家旗艦產品。讀此類 dogfood 案例的權重應該高、因為「雲商自己賭身家」。

需要警惕：

• 案例 沒有 提具體 throughput、latency、cost 數字。Microsoft 內部數字通常不公開、跟 AWS / GCP 案例的數字密度差很多。
• 「MongoDB 不夠用」是行銷話術。實際是 MongoDB 在某些 workload pattern 下不夠用、不是普遍結論。

策略

可重用的工程做法：

1. MongoDB-compatible Cosmos DB 是大規模遷移的捷徑：應用層改動少、底層擴展性升級。但要驗證 特定 query pattern 在兩邊行為一致。對應 01.3 schema migration rollout evidence 的 dual-write 驗證。
2. 分析平台用 weakest acceptable consistency：session consistency 或 eventual consistency 通常夠用、能換到 3-10x throughput。對應 01.5 transaction boundary 的一致性取捨。
3. dogfood 是 vendor selection 的重要訊號：vendor 自家是否用在 production-critical workload、能告訴你「他們對自己服務的信任度」。
4. Multi-model 是 Cosmos DB 的差異化價值：同一個服務可以用 SQL API / MongoDB API / Cassandra API / Gremlin / Table API、避免多個 DB 服務並存。

跨平台等效：AWS DynamoDB（KV）+ DocumentDB（MongoDB-compatible）、GCP Firestore（document）+ Spanner（SQL）+ Bigtable（KV）— 各家用不同產品覆蓋 multi-model、Cosmos DB 是少數「單一產品支援多 model」。

下一步路由

• 對照其他 Cosmos DB 案例 → 9.C11 Minecraft Earth / 9.C21 ASOS Black Friday
• 對照其他 dogfood 案例 → 9.C1 AWS Prime Day / 9.C10 Spanner
• 想做 MongoDB-compatible 遷移 → 01.4 database migration playbook
• 想理解 multi-model 取捨 → 01 資料庫模組 + 00 服務選型模組
• 想對比 Cosmos DB MongoDB API vs SQL API 的選型 → Cosmos DB MongoDB API vs SQL API
• 想做 RU 成本模型與容量 sizing → Cosmos DB RU 成本模型

引用源

• Microsoft 365 boosts usage analytics with Azure Cosmos DB
• A technical overview of Azure Cosmos DB

觀察

Clearent 在 Azure SQL Hyperscale 的關鍵敘述（引自 Clearent Customer Story）：

關鍵特性：Azure SQL Hyperscale 把 storage 跟 compute 分離、跟 9.C23 Netflix Aurora 的 Aurora 是同類設計。

判讀

Clearent 案例揭露三個 Hyperscale 設計的工程重點。

1. 5 億筆 / 年 ≈ 1500 筆 / 秒平均、但 peak 可能 10-50x：支付交易有日內 / 月內 / 季內節律。早上 9-11 點商家對帳高峰、下午 12-1 點消費高峰、晚上 6-8 點消費高峰、月底結算高峰。容量規劃必須按 peak 訂、不是平均。對應 9.2 Workload Modeling 的 peak/avg ratio 跟 9.6 容量規劃模型。
2. Hyperscale = storage / compute 解耦：傳統 SQL Server primary 對 storage 跟 CPU / RAM 綁定、擴 storage 就要換更大 instance、不便。Hyperscale 把 storage 拉到分散式 log service、可以獨立擴 storage（最高 100 TB）、compute 獨立擴。對應 9.C10 Spanner 的同類分離思維、跟 9.C23 Netflix Aurora。
3. 「unite all information in one place」是支付業的特殊需求：merchants 需要對帳、退款、清算、稅務報表都即時可查、不能 OLAP 分開。Hyperscale 的 read scale-out（最多 4 個 secondary replica）讓即時報表跑在 OLTP DB 上不影響交易吞吐。

需要警惕：「scale automatically and almost infinitely」是行銷敘述。實際 Hyperscale 有上限（100 TB storage、Gen5 series 80 vCore）、超過要 sharding 應用層分散。

策略

可重用的工程做法：

1. Hyperscale 跟 Aurora 是同類設計、選型按生態：Azure 生態用 Hyperscale、AWS 生態用 Aurora、GCP 用 AlloyDB / Spanner。三家底層工程哲學一致（log-structured storage、storage / compute 分離）、選哪家取決於 application 已在哪個 cloud。
2. 微服務 + 共用 OLTP 是支付業常見架構：服務拆細、但 OLTP 仍是 single source of truth、共用一個 Hyperscale cluster。這跟 9.C23 Netflix microservice 各自 Aurora 不同 — Netflix 每微服務 自己 Aurora、Clearent 微服務共用 Hyperscale。取捨：Clearent 的「對帳一致性」需求讓共用更划算。
3. 支付業容量規劃以 peak 為主：不能用平均 RPS 規劃、要按單日 / 單秒 peak。歷史 peak × 預期成長 × headroom 是基本公式（9.6 容量規劃模型）。

跨平台等效：AWS Aurora Serverless v2、GCP AlloyDB、Spanner、PostgreSQL 自管 + Patroni 都可實作對等架構。差異是 vendor managed 程度跟 OLAP / OLTP 統一視覺。

下一步路由

• 對照其他 OLTP 案例 → 9.C4 DraftKings Aurora / 9.C23 Netflix Aurora / 9.C14 Standard Chartered
• 想設計支付業容量 → 9.6 容量規劃模型 + 9.11 高峰事件準備
• 想理解 storage / compute 分離 → 9.5 瓶頸定位流程

引用源

• Clearent scales its modern microservices architecture to handle 500 million payment transactions a year
• Announcing Azure SQL Database Hyperscale
• Get high-performance scaling for your Azure database workloads with Hyperscale

觀察

Maersk + Bosch 在 Azure AKS 的關鍵敘述（引自 AKS Customer Stories）：

其他常見 AKS 大客戶：Siemens Healthineers（醫療設備）、Finastra（金融軟體）、Hafslund（能源）。

判讀

Maersk 跟 Bosch 案例揭露三個傳統產業 K8s 治理的工程重點。

1. 傳統產業上 K8s 的動機是「治理一致性」、不是「成長彈性」：
   • 雲原生公司（Riot、Netflix）上 K8s 是為了 快速擴容 跟 跨 region 部署
   • 傳統產業上 K8s 是為了 統一 50+ 個應用團隊的部署流程、降低 ops 複雜度
   • 訴求不同、配置不同 — 傳統產業可能用 較大 node、較少 cluster、不是 9.C12 Riot 246 cluster 那種多 cluster 策略
2. 微服務 release cycle 多元化是傳統產業上 K8s 的核心需求：Bosch Connected Building 有「樓宇感測 daily release、能源計費 weekly release、設備運維 monthly release」、每個 release cycle 不同。K8s + GitOps（Argo CD、Flux）讓不同 cycle 共存於同一 cluster。對應 05 部署平台模組 的 release governance。
3. 「focus on business impact」是 managed K8s 的真正價值：Maersk 不是科技公司、是航運公司。工程資源從 維持 K8s 運維 釋放到 貨櫃追蹤演算法、港口物流優化、是商業 ROI 的關鍵。對應 9.C29 Lemino 90% 工程工時下降 的同類訴求、跟 9.7 成本邊界與 efficiency 的人力成本工程化。

需要警惕：Azure 官方對 Maersk / Bosch 的描述偏行銷、缺具體 throughput / latency 數字。讀此類案例要對 策略 學習、不要套用數字。

策略

可重用的工程做法：

1. 傳統產業 K8s 採用先做「單一 cluster 多 namespace」、再考慮多 cluster：管理 1 個大 cluster 比管理 246 個小 cluster 容易。除非有 9.C12 Riot Games 的隔離需求、否則 single-cluster-multi-namespace 是 sane default。
2. 不同 release cycle 用 GitOps + namespace 隔離：每個團隊 own 自己的 namespace、配合 Argo CD / Flux 各自 release。對應 05 部署平台模組。
3. AKS / EKS / GKE 的差異對傳統產業不關鍵：選哪家通常取決於企業已用哪家 cloud、不是 K8s feature 本身。重點是 managed K8s ops 比自管划算、不是哪家 managed 最好。
4. 監控訊號設計按業務 cycle：每天 release 的服務跟每月 release 的服務 monitoring 策略不同、alert 敏感度不同。對應 04 可觀測性模組。

跨平台等效：AWS EKS、GCP GKE、自管 Kubernetes + Rancher 都可實作對等架構。Azure 在 enterprise 整合（Active Directory、Azure DevOps）有優勢、特別適合 Microsoft 生態企業。

下一步路由

• 對照雲原生 K8s 策略 → 9.C12 Riot Games 246 cluster
• 對照其他 managed 服務釋放工程資源 → 9.C29 Lemino / 9.C19 Capcom
• 想設計 K8s 治理 → 05 部署平台模組 + 9.6 容量規劃模型

引用源

• Azure Kubernetes Service customer stories
• Maersk Azure case
• Bosch Software Innovations
• Kubernetes on Azure - Enterprise Expertise