新專案的安全架構設計

全新解決方案的安全設計是 SAP-C02 Task 1.2 的核心能力，要求你在第一行 Terraform 就把安全設計進去，而非事後把控制措施硬套到既有架構上。在 Professional 等級考試中，「全新解決方案的安全設計」的題目情境通常描述一個尚未建置的工作負載——全新的 B2B SaaS、全新的合規醫療平台、全新的全球金融科技 API——並要求架構師規劃 Zero Trust 身分模型、加密階層、租戶隔離模式、邊緣防護分層、偵測管道以及日誌設計。正確答案需要將十餘個 AWS 安全服務組合成一個連貫的架構，考試也獎勵那些理解各服務如何相互強化的考生。

本 Pro 深度指南以考試最愛的參考情境為主軸：一個擁有 10,000 個租戶、資料受合規約束（SOC 2、HIPAA、PCI DSS 依租戶而異），且 CISO 強制要求 Zero Trust 的 B2B SaaS。你將看到 AWS Verified Access 如何取代傳統的 Client VPN、VPC Lattice 加上 ACM Private CA 如何在微服務間強制執行 mTLS、KMS 金鑰階層如何按環境／租戶／資料分類拆分、多租戶隔離如何在帳號級、VPC 級與行級之間取捨、WAF + Shield Advanced + CloudFront 簽章 URL 如何在邊緣分層防護、以及 GuardDuty + Detective + Security Hub 搭配集中式 CloudTrail + VPC Flow Logs + CloudWatch Logs 如何建立跨組織的偵測與稽核平面。讀完之後，你看到 Greenfield 情境就能開立完整的安全設計處方。

什麼是全新解決方案的安全設計？

全新解決方案的安全設計是一套規範性的架構演練：在工作負載建置之前，挑選並組合 AWS 安全服務，讓控制措施原生嵌入設計，而非事後拼裝。AWS Well-Architected Security Pillar 歸納出七項設計原則——強固的身分基礎、可追溯性、全層安全、自動化最佳實踐、靜態與傳輸中的資料保護、讓人遠離資料、以及為事件做好準備——而全新解決方案的安全設計就是將這些原則轉化為具體服務選擇的實踐。

為何 SAP-C02 如此重視全新解決方案的安全設計

SAP-C02 的 Task 1.2（「規範安全控制措施」）在近年考題中已明顯向 Greenfield 情境傾斜。題目越來越常出現「全新的 SaaS 應用程式」、「正在建置中的全新醫療平台」或「架構團隊正在設計一個全新的全球 API 閘道器」。這類題目獎勵熟悉 2023–2025 Zero Trust 服務目錄的考生——Verified Access、VPC Lattice、IAM Identity Center、Verified Permissions——而非只會 VPN 加 Security Group 的舊式答案。全新解決方案的安全設計還要求你理解哪個服務取代了什麼：Verified Access 取代 Client VPN 做應用程式存取；VPC Lattice 取代自管理服務網格加上大量 NLB 蔓延；Verified Permissions 取代自行開發的 RBAC 資料庫。

全新解決方案安全設計的七大支柱

每個 Greenfield 架構都必須處理七項關切，考試會單獨或組合測試它們：

1. 身分與存取 — Zero Trust、Identity Center、Verified Access、Verified Permissions、VPC Lattice auth policies。
2. 資料保護 — KMS 金鑰階層、封包加密、傳輸中 TLS / mTLS、ACM + Private CA。
3. 網路安全 — VPC 設計、Security Groups、Network Firewall、Transit Gateway、PrivateLink、透過 VPC Lattice 實現的 Zero Trust 服務網格。
4. 租戶隔離 — 帳號級、VPC 級、命名空間級、行級，或混合隔離。
5. 邊緣防護 — CloudFront、WAF、Shield Advanced、簽章 URL、Route 53、AWS Global Accelerator 強化。
6. 偵測與回應 — GuardDuty、Detective、Security Hub、Inspector、Config、Macie、Access Analyzer。
7. 日誌與稽核 — 組織 CloudTrail、VPC Flow Logs、CloudWatch Logs、集中式 Log Archive、不可變保留。

在考試中，單一題目往往涉及三到四個支柱，正確答案必須回應題目暗示的每個支柱，而不只是其中一個。

參考情境 — 擁有 Zero Trust 授權的萬租戶 B2B SaaS

本指南全程以同一個情境作為設計決策的錨點。請把它內化；SAP-C02 考試頻繁以極小差異變化這個情境。

工作負載： 一個服務 10,000 個企業租戶的 B2B SaaS 產品。每個租戶有不同的合規需求，從 SOC 2 基線到 HIPAA PHI 或 PCI DSS 持卡人資料不等。CISO 下令採用 Zero Trust 架構：不以網路位置作為隱性信任依據，每個請求都要明確認證與授權，持續驗證。平台必須在三年內擴展到 50,000 個租戶。租戶期待獨占式的效能感與嚴格隔離，其中較小的企業層級願意接受共用隔離以換取較低定價。工程團隊有 80 位開發者分佈在 12 個微服務團隊中。十二個月後上線。

這個情境把全新解決方案安全設計的每一項決策都擺上桌。你無法用單一服務或單一帳號解決它。正確架構是約十五個 AWS 服務的紀律性分層，本指南逐節說明。

白話文解釋 New Solutions Security Design

全新解決方案的安全設計很抽象，直到你把它翻譯成日常語言。三個來自不同領域的類比讓每個面向都變得具體——三個都讀一遍。

類比一：設計一棟新的大型辦公大樓（建築類比）

想像你是台北市中心一棟全新智慧辦公大樓的首席設計師，大樓容納 200 家企業租戶，混合高度機密的金融公司、一般科技公司與共用空間的新創團隊。全新解決方案的安全設計，就是在打地基之前把安全設計進建築藍圖——而不是大樓啟用後再補裝門禁。

Zero Trust 是這棟大樓的全程刷卡原則：沒有任何走廊「預設安全」；每扇門都要驗證識別證，每台電梯都要確認你目前有沒有去那一層的權限，每個訪客室都登記進出紀錄。AWS Verified Access 是取代傳統大門警衛崗哨的智慧門禁系統——以前只要進了大樓就信任你（VPN），現在每道門都要確認你目前的身分、目前的授權，以及裝置是否健康。VPC Lattice 搭配 mTLS 是大樓內部的機密文件傳遞系統：每份在部門之間流通的文件都附有密碼簽章信封（ACM Private CA 核發的 mTLS 憑證），證明這份文件真的來自財務部而非偽裝的快遞。

KMS 金鑰階層是大樓的多層保險箱系統：地下室有整棟大樓的主金庫（環境層 CMK），各樓層有各自的子保險箱（租戶金鑰），每個高價值文件室有各自的抽屜鎖（資料分類金鑰）。多租戶隔離是樓層規劃——頂樓整層給全棟最大客戶獨用（帳號級隔離，爆炸半徑完全隔開），中層是每家公司有獨立辦公室但共用電梯核心（VPC 級隔離），低樓層是共用開放辦公格局但有隔板（行級隔離，共用資源、最便宜）。WAF + Shield + CloudFront 簽章 URL 是大樓入口的安全設施：WAF 是門口的掃描儀檢查已知威脅，Shield Advanced 是當抗議人群衝門時的保全中隊，簽章 URL 是給特定訪客、限時有效的訪客通行證。

GuardDuty + Detective 是大樓的監控中心加事後回放系統：GuardDuty 即時發現異常行為（有人深夜在機房門口徘徊），Detective 讓調查人員調出前三十天的監視錄影，把五個看似無關的事件串接成一個完整入侵時間軸。Security Hub 是大樓管理委員會的合規儀表板——消防法規、建築法規、ISO 認證，所有項目紅黃綠一目了然。集中式 CloudTrail 和 VPC Flow Logs 是法規要求、存放在異地保險箱、不可竄改的進出紀錄與貨物清單。在藍圖階段就把這一切設計進去，大樓建好就天然安全；等大樓住滿人再補裝，每一次改裝都要請住戶暫時離開。

類比二：設計一座全新的中央銀行（金融 / 機構類比）

想像你受委託為一個國家政府設計全新的中央銀行——金庫、財政廳、電匯系統、偽鈔鑑定室、稽核辦公室，一切在同一個機構章程下運作。全新解決方案的安全設計就是這份設計委託對雲端工作負載的翻譯。

Zero Trust 搭配 AWS Verified Access 是每一層電梯的身分驗證：銀行廢除了「你已進入大樓就信任你」的概念。通往金庫的電梯、通往交易廳的電梯、通往稽核套房的電梯，每一部都需要重新認證身分卡與當前授權——IAM Identity Center 提供識別證，Verified Access 是電梯讀卡機。VPC Lattice mTLS 是部門間的氣動傳輸管系統：貸款部門發給合規部門的每個文件膠囊都蓋有密碼印章（來自 ACM Private CA 的 mTLS 憑證），證明發件人身分並偵測竄改。

KMS 金鑰階層是巢狀金庫系統：根層的主金庫保存國家財政金鑰，裡面是各部門子金庫（各環境 CMK），再裡面是各戶保管箱（租戶金鑰），最裡面是特定文件信封（資料分類金鑰）。KMS Grants 是由金庫官員簽署的臨時委託單，授權特定承包商在特定期間內取用某個保管箱。多租戶隔離——帳號級隔離是給每個大客戶開設獨立的子行；VPC 級隔離是獨立分行；行級隔離是共用出納員加隔板與嚴格流程。

WAF + Shield + CloudFront 是公眾入口安全設施：WAF 是入口安全門檢查已知威脅特徵（SQL 注入、XSS、機器人模式），Shield Advanced 是當抗議人潮湧入時的群眾管制隊（DDoS 吸收與 24/7 SOC 支援），CloudFront 簽章 URL 是有日期姓名的限時訪客證。GuardDuty 是偽鈔與詐欺偵測實驗室，對每筆交易執行 ML；Detective 是鑑識會計師，在事件發生時把六週的日誌拉成一張關係圖。Security Hub 是監管合規長的辦公桌，即時顯示每個認證的狀態（SOC 2、PCI DSS、金融監管機構）。集中式日誌是法律強制的一次性寫入帳本，每日運送到異地保存——稽核員永遠不可被竄改。

類比三：從零設計一座新城市的公用電網（基礎設施 / 土木工程類比）

假設你是負責設計一座 50 萬人新規劃城市的電力、供水、電信與緊急服務電網的總工程師。全新解決方案的安全設計就是這項工程對雲端工作負載的翻譯。

Zero Trust 是沒有任何區域預設安全的原則——每個變電站、每個抽水站、每座基地台都有獨立的門禁與監控，無論它位於城市哪一區。AWS Verified Access 是每個關鍵基礎設施閘門的讀卡機，取代了舊式「整個電力設施區用一道圍籬圍起來」的模型（Client VPN）。VPC Lattice 搭配 ACM Private CA 核發的 mTLS 是 SCADA 控制訊號系統：從控制中心發往變電站的每道指令都有密碼簽章，變電站在執行前驗證簽章——即使控制頻道被盜，沒有憑證也無法發出有效指令。

KMS 金鑰階層是分級鎖匠系統：區域電力公司層級的主金鑰、變電站層金鑰、配電箱層金鑰、元件層金鑰。Grants 是短期工作指令，讓承包商在一天內存取一個配電箱，而不需要發放永久鑰匙。多租戶隔離——在這個類比中，租戶是使用專屬變電站容量的大型工業客戶（帳號級隔離）、共用饋線加計量表的商業區（VPC 級隔離），以及共用線路加智慧電表的住宅區（行級隔離）。

邊緣防護是城市邊界：WAF 是入境資料的邊境檢查哨（特徵碼、速率限制），Shield Advanced 是協調式網路實體攻擊來襲時的緊急應變機制，CloudFront 簽章 URL 是讓特定承包商進入特定設施的限時工作許可。GuardDuty 是分散式入侵感測網路——每個變電站的動作偵測器、每個配電箱的攝影機——向單一控制中心回報異常。Detective 是事件重建實驗室，把數個月的感測器資料拼接成一條攻擊時間軸。Security Hub 是監管合規儀表板，顯示對公用事業委員會要求的符合程度。集中式日誌是每日複製到防火異地存檔的法定營運日誌。

在動工前把這一切設計在圖紙上，城市建好就天生安全。等電網通電後再補裝，每次改裝都要停電。

Zero Trust 架構與 AWS Verified Access

Zero Trust 是 SAP-C02 全新解決方案安全設計的基礎模式。心智轉換：永遠不憑網路位置信任；在每個請求時都驗證身分、裝置狀態與授權。

為何 Verified Access 取代 Client VPN 做應用程式存取

AWS Client VPN（傳統模式）建立網路層隧道；進入隧道後，用戶端可以連到 VPC 並與 Security Groups 允許的任何應用程式通訊。這違反了 Zero Trust——網路成員資格不等於身分。AWS Verified Access 翻轉了這個模型：用戶端透過公共網際網路連到 Verified Access 端點，端點透過身分提供者（IAM Identity Center、Okta、Ping，任何 OIDC IdP）認證使用者，透過裝置信任提供者（CrowdStrike、Jamf、Jumpcloud）評估裝置信任訊號，評估 Verified Access 政策（基於 Cedar，以布林表達式撰寫，涵蓋使用者屬性、群組成員、裝置屬性與請求屬性），然後才將請求路由到端點後方的私有應用程式。

Verified Access 在應用程式層提供每次請求的授權。使用者一旦認證進入 Identity Center，並不因此獲得網路層對所有資源的存取權。每個應用程式（內部 HR 入口、內部管理主控台、開發者 Kubernetes 儀表板）都有各自的 Verified Access 端點與各自的政策。承包商可能被允許存取開發者儀表板但被拒於 HR 入口之外，即使兩者位於同一個 VPC 中。

Verified Access 政策語言 — Cedar

Verified Access 使用 Cedar，AWS 的開源授權政策語言。Cedar 政策讀起來相當直覺：

permit(principal, action, resource)
when {
  context.identity.groups.contains("Engineering") &&
  context.identity.email_verified == true &&
  context.device.os_version >= "14.0" &&
  context.http_request.method == "GET"
};

Cedar 與 Amazon Verified Permissions 用於應用程式層授權的語言相同，這意味著你的 Verified Access 政策與應用程式內的細粒度授權可以共用一致的表達式語法。這是全新解決方案安全設計的精髓：在 Greenfield 中一次選定 Cedar，兩處都受益。

Verified Access 信任提供者 — 身分與裝置

Verified Access 端點掛載一個使用者身分信任提供者（Identity Center 或外部 OIDC），以及視需要掛載一個或多個裝置信任提供者（Jamf、CrowdStrike、Jumpcloud）。Cedar 政策可同時參照兩者，例如要求使用者屬於特定 Identity Center 群組，且端點的 CrowdStrike 回報裝置狀態健康。裝置信任是 Zero Trust 的要求：即使使用者憑證有效，受入侵的裝置也應被拒絕。

Verified Access 日誌與 Detective 整合

Verified Access 將結構化存取日誌輸出到 S3、CloudWatch Logs 或 Kinesis Data Firehose。每個允許與拒絕決策都記錄了使用者、裝置狀態、政策結果與請求屬性。這些日誌送入 Security Hub、GuardDuty（用於偵測異常存取）以及 Detective（用於鑑識分析）。在考試中，「稽核員要求過去一年每個應用程式存取決策的紀錄」就是 Verified Access 加集中式日誌存檔的答案。

VPC Lattice 與服務對服務的 Zero Trust

東西向流量（服務對服務）是許多 Greenfield Zero Trust 設計的弱點。Amazon VPC Lattice 是讓東西向 Zero Trust 變得宣告式的 AWS 原生服務網格。

VPC Lattice 的功能

VPC Lattice 是一個受管的應用程式網路服務，連接跨 VPC 與跨帳號的服務。服務擁有者將一個服務（ALB、NLB、Lambda 或 IP 目標群組）註冊到 VPC Lattice。組織中任何 VPC 任何帳號的消費端應用程式都可以透過 Lattice 資料平面，以主機名稱連到該服務，無需 VPC 對等連接、Transit Gateway 附件或 PrivateLink 端點。Lattice 在受管的多 VPC「服務網路」中路由流量。

對全新解決方案安全設計至關重要的是，每個透過 Lattice 的服務對服務呼叫都會通過 Lattice 授權引擎，該引擎評估auth policies（服務或服務網路上的 IAM 型政策）。這是 Zero Trust 服務對服務授權：服務 A 只有在服務 B 的 auth policy 明確允許服務 A 的 IAM principal 時才能呼叫服務 B。

Lattice Auth Policies — 服務層 Zero Trust

VPC Lattice 服務上的 auth policy 看起來像 IAM resource policy：

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::TENANT-ACCOUNT:role/OrderServiceTaskRole"
    },
    "Action": "vpc-lattice-svcs:Invoke",
    "Resource": "arn:aws:vpc-lattice:us-east-1:PROD-ACCOUNT:service/svc-orders/*",
    "Condition": {
      "StringEquals": {
        "vpc-lattice-svcs:RequestMethod": "POST",
        "vpc-lattice-svcs:RequestPath": "/orders/submit"
      }
    }
  }]
}

這段政策的意思是：訂單服務只接受來自租戶帳號中 OrderServiceTaskRole 的呼叫，且只能是 POST 到 /orders/submit。其他所有呼叫者、所有方法、所有路徑預設拒絕。相較於傳統以 Security Group 為基礎的東西向控制（同一 Security Group 中的任何工作負載都能存取任何連接埠），Lattice auth policies 提供了每個 IAM principal、每個 HTTP 方法、每個路徑的授權——Zero Trust 的理想。

在服務層以 ACM Private CA 實現 mTLS

VPC Lattice 支援原生 TLS 終止，若要達到密碼學上的對等身分驗證（不只是傳輸加密），可以使用由 AWS Private Certificate Authority（PCA）核發的憑證來疊加 mTLS。全新解決方案安全設計的標準模式：

1. 在共用服務帳號或安全帳號中建立 AWS Private CA 階層：根 CA（離線，極少使用）簽發負責核發端實體憑證的從屬 CA。
2. 透過 AWS RAM 將從屬 CA 分享給工作負載帳號。
3. 每個微服務從從屬 CA 取得憑證，以其 DNS 名稱作為主體別名（SAN）。
4. 服務終止 mTLS，對照共用 CA 的信任鏈驗證對等憑證。
5. 結合 Lattice auth policies 在密碼學對等身分之上追加 IAM 型授權。

mTLS 提供了 Zero Trust 在最敏感的服務對服務呼叫中所需的密碼學身分證明——例如付款服務只接受訂單服務在出示根於內部 PCA 的憑證鏈時的請求。

VPC Lattice vs 服務網格（App Mesh、Istio）

App Mesh 是 AWS 的 Envoy sidecar 服務網格，現已進入維護模式——不是 Greenfield 的前瞻選擇。Istio 是自管理的，營運負擔重。VPC Lattice 是受管的、AWS 原生的、無 sidecar 服務網格，是全新解決方案安全設計的答案。在考試中，若情境說「跨帳號與 VPC 的服務對服務授權，最低營運開銷，Zero Trust」，答案是 Lattice。

大規模 KMS 金鑰階層設計

靜態加密在參考情境中是不可妥協的。10,000 個租戶加上混合合規需求的挑戰，不在於要不要加密——而在於如何組織金鑰階層，讓營運、稽核、成本與租戶隔離都能正常運作。

三軸金鑰階層

成熟的 Greenfield KMS 設計將 Customer Managed Key（CMK）沿三個軸組織：

• 環境軸： 每個環境（dev / stage / prod）使用獨立金鑰。防止開發帳號被入侵後解密正式資料。
• 租戶軸： 對隔離要求嚴格的租戶（HIPAA BAA、PCI 持卡人環境、高級企業層級）使用各自獨立的金鑰。
• 資料分類軸： 每個資料類別（一般、PII、PHI、持卡人、財務紀錄）使用獨立金鑰。啟用每類別的存取政策與保留/輪換設定。

對 10,000 個混合隔離需求的租戶，務實的設計是：

• 一般層級租戶（約 9,000 個）每個環境每個資料類別共用一個 pool CMK（總計約 5–10 個 CMK，跨 9,000 個租戶共享）。
• 高級／合規層級租戶（前 10%，最多 1,000 個）各自擁有專屬 CMK。

這種混合設計在成本（KMS 金鑰每月每個 $1）與隔離之間取得平衡。10,000 個專屬金鑰每月光金鑰儲存就要 $10,000；混合設計便宜了一個數量級，且與租戶實際付費方式一致。

大規模使用 Key Policies vs IAM Policies vs Grants

三種機制控制對 KMS 金鑰的存取，正確選擇是 SAP-C02 常見陷阱：

Key policies 是金鑰的權威授予。編輯 key policy 來新增 principals、條件與動作範圍。當數千個短命 principals 需要存取時，key policies 無法擴展——你無法持續改寫 key policy。

IAM policies 在同一帳號中從 key policy 的「允許 IAM 委派」條款委派。IAM policies 可擴展到同一帳號的許多 principals，因為它們附加到呼叫者而非金鑰。對於帳號內大規模存取，principals 上的 IAM policies 加上啟用 IAM 委派的 key policy 是正確模式。

KMS Grants 是程式化的、臨時性的委派。Grant 授權特定 principal 對特定金鑰執行特定操作，可附加選用的加密上下文約束，且可獨立撤銷。當 AWS 服務（EBS 掛載磁碟區、RDS 啟動執行個體、Aurora 建立複本、Lambda 以加密環境變數呼叫）需要臨時金鑰存取時，Grants 擴展性最佳。服務建立 grant、使用它，然後 grant 撤銷或到期。

對萬租戶情境，grant 模式佔主導地位：當租戶的工作負載佈建新的 EBS 磁碟區或新的 RDS 執行個體時，佈建自動化為該資源建立範圍限定的 KMS grant。當資源下線時，grant 到期。日常操作不需要修改 key policy。

加密上下文作為租戶標籤

KMS 加密上下文是一組在加密時提供、在解密時必須提供的非機密鍵值對。使用它將每個密文與其租戶綁定：

encryption_context = { "tenant_id": "tenant-47381", "data_class": "PHI" }

現在，未提供匹配加密上下文的解密呼叫將失敗，即使呼叫者對金鑰擁有 kms:Decrypt 權限。結合 key policy 條件 "kms:EncryptionContext:tenant_id": "${aws:PrincipalTag/TenantId}"，你在密碼學上強制執行了租戶 A 的 principal 無法解密租戶 B 的密文——即使兩者共享同一個 pool CMK。

KMS Multi-Region Keys 用於災難恢復

參考情境受合規約束且需要災難恢復。KMS Multi-Region Keys（MRK）在各複本區域擁有相同的金鑰 ID，因此在 us-east-1 加密的密文可在 us-west-2 解密，無需在容錯移轉時重新加密。MRK 複本有獨立的 key policies，因此跨帳號 grants 必須各區域分別設定。對 Greenfield，在開始時就決定哪些金鑰是 MRK（保護需要 DR 複製資料的金鑰），哪些是單區域。

多租戶隔離模式

情境要求 10,000 個混合合規租戶的隔離。沒有唯一正確答案——AWS SaaS Tenant Isolation Strategies 白皮書定義了四種模式，Greenfield 設計通常組合使用。

模式一 — 帳號級隔離（Silo）

每個租戶一個 AWS 帳號。隔離最強——SCP、IAM、KMS、VPC、資源全部租戶限定。適用於高合規租戶（PCI、HIPAA 有明確隔離要求）和願意為專屬基礎設施付費的高價值企業客戶。

營運成本高——租戶上線需要 Control Tower Account Factory 或 AFT 來佈建帳號、建立安全服務基線並部署應用程式堆疊。CI/CD 管道必須處理每帳號部署（CodePipeline 跨帳號角色）。計費按帳號計算，成本歸因清晰明確。

限制：AWS Organizations 預設每個組織上限為 10,000 個帳號（軟限制，可提高）。三年目標的 50,000 個租戶實際上可能觸及此限制；一開始就規劃多組織，或與共用模式結合。

模式二 — VPC 級隔離（Silo）

每個租戶一個 VPC，位於共用帳號（或少數帳號）中。網路隔離強（租戶間無網路路徑）。帳號層控制（SCP、CloudTrail）是共用的。中等合規租戶通常落在這裡。

實作：Transit Gateway 或 VPC Lattice 連接租戶 VPC 與共用服務（可觀測性、日誌、身分）。即使在共用帳號中，KMS 金鑰和 IAM 角色通常也是每租戶獨立的。

模式三 — 命名空間級隔離（Pool）

每個租戶一個 Kubernetes namespace（或共用資料庫中的每租戶 schema、每租戶 OpenSearch index、每租戶 Lambda alias）。共用運算、共用控制平面，租戶上下文由應用程式層邏輯強制執行。每租戶成本較低；隔離保證較弱。

適用於租戶接受共用資源換取較低定價的基礎層。適合 SOC 2 基線租戶；單獨使用無法滿足 HIPAA 或 PCI。

模式四 — 行級隔離（Pool）

共用資料庫表格，每行有 tenant_id 欄位。資料庫層行安全或 ORM 層過濾器強制租戶隔離。最便宜；隔離保證最弱（ORM 過濾器中的 bug 可能洩露跨租戶資料）。

結合行級隔離與每租戶封包加密——每行的敏感欄位用租戶特定的 KMS 資料金鑰加密。即使查詢 bug 回傳了另一個租戶的行，沒有目標租戶的金鑰也無法解密密文。這是 pool 層有意義隔離的常見模式。

混合參考設計

對 10,000 個租戶的情境，務實的混合設計：

• 白金層（前 1%，約 100 個租戶）： 帳號級隔離、專屬 CMK、專屬 VPC、嚴格 SCP。PCI/HIPAA 合規。
• 黃金層（次 10%，約 1,000 個租戶）： 共用帳號池內的 VPC 級隔離，每租戶專屬 CMK，更嚴格的 IAM 角色隔離。帶有租戶特定控制的 SOC 2。
• 銀級層（大宗 89%，約 8,900 個租戶）： 共用 EKS 叢集中的命名空間級隔離、共用 RDS 中的行級隔離，加上加密上下文綁定解密的每租戶封包加密。SOC 2 基線。

此混合設計直接對應商業定價層，並向考試評分者說明你理解隔離是一個光譜，而非單一選擇。

租戶隔離的 SCP 模式

帳號級隔離使用 SCP 防止跨租戶操作：拒絕可能建立能從另一租戶帳號受信任角色的 iam:* 操作，拒絕修改 key policy 以新增外部 principals 的 kms:* 操作，拒絕透過 RAM 在核准清單外分享資源。SCP 是強制保證：即使租戶管理員被入侵，爆炸半徑也限定在租戶範圍內。

邊緣安全分層 — WAF + Shield Advanced + CloudFront 簽章 URL

對外的進入點是新 SaaS 中攻擊最頻繁的面。全新解決方案安全設計在邊緣分三層防護。

CloudFront 作為邊緣終止點

所有公共流量在 CloudFront 終止。好處：地理攻擊面縮減（來源不暴露）、快取吸收量批負載、與 WAF 和 Shield 原生整合、簽章 URL／簽章 Cookie 支援私有內容，以及邊緣函數（Lambda@Edge 和 CloudFront Functions）用於請求時邏輯。

來源（ALB、API Gateway、S3）透過來源存取控制（S3 用 OAC、ALB 用 VPC origin、ALB 監聽器的 AWS WAF IP-set 只接受 AMAZON_CLOUDFRONT 發布的 CloudFront IP 範圍）加以限制。確保每個請求只能透過邊緣到達來源。

在 CloudFront 層使用 AWS WAF

WAF 掛載到 CloudFront（公共流量）以及區域 ALB／API Gateway／AppSync（內部或區域端點）。受管規則群組涵蓋 OWASP Top 10（AWSManagedRulesCommonRuleSet）、已知惡意輸入、IP 信譽清單、機器人控制、帳號接管防護。自訂規則新增工作負載特定邏輯——封鎖來自非預期地理位置的請求、按標頭中的租戶 ID 速率限制、封鎖缺少必要 API 金鑰的請求。

WAF 日誌流向 S3、CloudWatch Logs 或 Kinesis Data Firehose。對 Greenfield，啟用 WAF 完整日誌輸出到帶有 Object Lock 的 S3——WAF 日誌既是偵測資料（送入 GuardDuty／Detective／Security Hub），也是合規稽核的鑑識證據。

Shield Advanced 用於 DDoS 防禦

Standard Shield 在 CloudFront 和 ALB 上免費提供。Shield Advanced（每月每組織 $3,000）新增增強型 DDoS 偵測、攻擊期間 24/7 SRT（Shield Response Team）參與、成本保護（DDoS 相關的擴展費用退款），以及由 SRT 調整的 WAF 速率型規則進行應用層 DDoS 緩解。

對受合規約束的 B2B SaaS，Shield Advanced 通常是合理的。在考試中，「具有 SLA 綁定可用性的業務關鍵工作負載，擔心 DDoS」就是 Shield Advanced 的答案。

CloudFront 簽章 URL 與簽章 Cookie

對私有內容（租戶資料下載、每租戶影片、高級資產），CloudFront 簽章 URL 是限時的、可選政策範圍的 URL，授予特定 principal 在特定時間窗口內存取特定資源的權限。簽章 Cookie 則一次限定多個資源。

在 Greenfield 中，每個面向租戶的資產交付都使用簽章 URL——應用程式在交付時生成 URL，用 CloudFront 金鑰群組私鑰簽署，邊緣驗證簽章與到期時間。這防止了 URL 囤積與跨租戶 URL 分享。洩漏的 URL 幾分鐘後到期；洩漏的簽署金鑰可透過金鑰群組更新輪換，無需使現有 CloudFront 部署失效。

Firewall Manager 用於全組織邊緣政策

AWS Firewall Manager 在整個組織的所有帳號中強制執行 WAF web ACL、Shield Advanced 防護以及 Security Group 基線。在 Greenfield 中，安全帳號是 Firewall Manager 委派管理員；它將基線 WAF 政策（OWASP 核心規則）推送到組織中每個面向公眾的 ALB 和 CloudFront distribution，防止租戶帳號在沒有 WAF 的情況下部署公共端點。

GuardDuty 與 Detective — Greenfield 的偵測管道

GuardDuty 是每個 Greenfield 的基線威脅偵測服務。Detective 在上面疊加鑑識調查能力。兩者都應在第零天啟用，而不是在第一次事件後才加入。

Greenfield 的 GuardDuty 基線

從第一天起以組織委派管理員模式啟用 GuardDuty：

• 安全帳號是 GuardDuty 委派管理員。
• 自動啟用新帳號並啟用所有必要的防護計畫。
• 啟用每個適用的防護計畫：EC2 的 Malware Protection、S3 Protection、EKS Protection、Lambda Protection、RDS Protection。
• 發現項目流向 Security Hub 以及 EventBridge 匯流排用於 SIEM 整合。

GuardDuty 的 ML 模型為每個帳號的正常活動建立基線。對 Greenfield，這意味著前 30 天是學習期——預期會有初始誤報需要透過抑制規則調整。之後，GuardDuty 可靠地偵測異常 API 模式、加密採礦、DNS 外洩與受入侵的憑證。

Detective 用於鑑識調查

Amazon Detective 從 CloudTrail、VPC Flow Logs、GuardDuty 發現項目、EKS 稽核日誌與 Route 53 查詢日誌建立關係圖。當 GuardDuty 發出發現項目——例如「IAM 角色 X 從 Tor 出口節點發出 API 呼叫」——Detective 讓分析師點進去查看該角色過去 30 天的活動、它碰觸的資源、來源 IP 位址，以及可能共享行為模式的其他角色。

Detective 是委派管理員服務（安全帳號）。在 Greenfield 時與 GuardDuty 一起啟用；一旦兩者都開啟，資料來源啟用是自動的。儲存按攝入資料的 GB 計費；對 50 帳號的 Greenfield，Detective 每月費用低至幾百美元，且大幅縮短事件回應時間。

GuardDuty EC2 的 Malware Protection

EC2 的 Malware Protection 在 GuardDuty 發出可疑發現項目時掃描 EBS 磁碟區——它對磁碟區拍快照，在 AWS 管理的掃描環境中掛載快照，執行惡意程式偵測，並在不接觸活躍工作負載的情況下回傳發現項目。關鍵是，掃描不需要工作負載上的代理程式——零足跡。對 Greenfield，從第一天就啟用此防護計畫。

GuardDuty S3 和 EKS Protection

S3 Protection 分析 S3 資料事件中的異常存取模式（異常的下載量、來自異常 principals 的存取）。EKS Protection 攝入 EKS 稽核日誌並偵測 pod 行為異常（pod 發出非預期的 API 呼叫、提權嘗試）。對於使用大量 S3 資料儲存和以 EKS 為基礎的運算的 SaaS 工作負載，兩者都是必要的。

Security Hub 作為 CSPM 基線

Cloud Security Posture Management（CSPM）是針對標準基線持續衡量安全設定錯誤。Security Hub 是 AWS 的原生 CSPM。

啟用第零天標準

在 Greenfield 時，從委派管理員（安全帳號）啟用 Security Hub 並開啟：

• AWS Foundational Security Best Practices（FSBP）： AWS 精選的 200+ 個控制項。每個工作負載的基線。
• CIS AWS Foundations Benchmark v3.0： 業界標準。
• PCI DSS v4.0： 為白金層帳號啟用。
• NIST SP 800-53 Rev. 5： 若有任何聯邦或聯邦相鄰租戶則啟用。

Security Hub 為每個帳號每個標準計算安全分數。在 Greenfield 基線中，多數帳號從 60–70% 合規起步；正式環境上線目標是 90%+，其餘有記錄的例外。

跨區域彙整

第一天就選定彙整區域（通常是 us-east-1）並啟用 Security Hub 跨區域彙整。每個區域的每個發現項目都流入彙整區域的主控台。安全團隊在整個組織與每個操作區域都有統一的單一檢視窗口。

自動化規則用於發現項目分類

Security Hub 自動化規則根據屬性修改發現項目，無需撰寫 Lambda。範例：自動抑制 Sandbox 帳號的發現項目（標籤 Environment=Sandbox）、自動提升 PCI 分類資源發現項目的嚴重性（標籤 DataClass=PCI）、自動為涉及特定控制項的發現項目新增合規框架參考注記。在 Greenfield 時設定自動化規則；它們會隨工作負載擴展。

與 GuardDuty、Inspector、Macie、Access Analyzer 整合

所有 AWS 安全服務的發現項目以標準 AWS Security Finding Format（ASFF）流入 Security Hub。第三方合作夥伴發現項目（CrowdStrike、Wiz、Palo Alto Prisma）透過合作夥伴目錄整合。Security Hub 是安全團隊看到一切的統一儀表板。

集中式日誌設計 — CloudTrail + VPC Flow Logs + CloudWatch Logs

稽核日誌是合規的基本要求。全新解決方案安全設計將日誌集中在具有不可變保留的 Log Archive 帳號中。

組織 CloudTrail 輸出到 Log Archive

從管理帳號建立組織追蹤，捕捉每個成員帳號每個區域的所有管理事件以及選用的資料事件。輸出到 Log Archive 帳號中的中央 S3 儲存桶。啟用：

• 日誌儲存桶上合規模式的 S3 Object Lock（不可變保留、防勒索軟體）。
• S3 Bucket Key 用於 KMS 成本最佳化。
• CloudTrail 日誌檔案完整性驗證（摘要檔案）。
• CloudWatch Logs 交付用於透過 CloudTrail Lake 或 Athena 即時查詢。
• 儲存桶的 MFA 刪除。

Log Archive 帳號沒有人類使用者；存取透過另行稽核的緊急 IAM 角色進行。SCP 防止任何人修改或刪除 Log Archive 儲存桶。

CloudTrail 資料事件 — 選擇性而非全面性

管理事件是基礎。資料事件（S3 物件層級、Lambda 函數層級、DynamoDB 項目層級、EKS kubectl）按事件計費，可能產生大量流量。在 Greenfield 時，選擇性啟用資料事件：

• Log Archive 儲存桶本身的 S3 資料事件（誰讀取了稽核日誌）。
• PCI/HIPAA 分類儲存桶的 S3 資料事件。
• 特權函數的 Lambda 資料事件（輪換 Secrets 的函數、佈建租戶的函數）。

第一天不要全組織範圍啟用 S3 資料事件——成本會暴增。按分類標籤選擇性開啟。

VPC Flow Logs 集中收集

在每個 VPC 上啟用 Flow Logs（或在集中式架構的 TGW 層級啟用）。輸出到 Log Archive 帳號的 S3 儲存桶，按帳號/區域/vpc/日期分區以利高效的 Athena 查詢，並以 parquet 格式儲存以降低成本與提升效能。Flow Logs 送入 GuardDuty（VPC Flow Logs 資料來源）、Detective 以及臨時鑑識查詢。

CloudWatch Logs 全組織收集

應用程式日誌、Lambda 日誌、Lambda@Edge 日誌、容器日誌——CloudWatch Logs 是通用的接收端。在多帳號組織中，透過 CloudWatch Logs 訂閱過濾器 → Kinesis Data Firehose → 中央 S3 將關鍵日誌群組傳送到 Log Archive 帳號。帳號內保留 30 天用於營運疑難排解；中央 S3 保留數年用於合規。

日誌分類與保留

對日誌流進行分類：安全日誌（CloudTrail、GuardDuty 發現項目、WAF 日誌、VPC Flow Logs）保留 7 年；營運日誌（應用程式日誌、Lambda 日誌）保留 30–90 天；稽核證據日誌（SOC 2／HIPAA 要求的）按框架保留（通常 7 年）。使用 S3 生命週期政策：熱（S3 Standard）90 天 → Infrequent Access → Glacier Instant Retrieval → Glacier Deep Archive 用於最低成本的多年合規保留。

IAM Identity Center 作為人類身分平面

對 12 個團隊的 80 位開發者，人類身分使用 IAM Identity Center（前稱 AWS SSO）。Identity Center 是跨所有組織帳號的聯合單一登入。

身分來源選擇

Identity Center 支援三種身分來源：Identity Center 目錄（內建，適合小型組織）、Active Directory（本地端或 AWS Managed Microsoft AD），以及外部 IdP（Okta、Azure AD、Ping，透過 SAML 或 SCIM）。對 Greenfield，通常透過 SCIM 使用 Okta 或 Azure AD——使用者和群組自動同步，權限在企業 IdP 中管理，在 IdP 中下線使用者會立即撤銷所有 AWS 存取。

Permission Sets

Permission sets 是 Identity Center 的 IAM 單元——permission set 是一組 IAM 政策，分配給特定帳號的使用者或群組時，會在該帳號中佈建帶有這些政策的 IAM 角色。集中定義 permission sets：

• AdminAccess（緊急存取，需要 MFA，限制群組）。
• DevOpsDeveloper（在 permission boundary 內的廣泛工作負載存取）。
• ReadOnly（稽核與支援角色）。
• SecurityAuditor（安全團隊在所有帳號的唯讀）。
• TenantOperator（租戶帳號管理員，租戶範圍）。

將 permission sets 分配給群組（而非使用者）。使用者的 AWS 存取來自 Identity Center 群組成員資格，而群組成員資格來自 IdP。這是 Zero Trust：員工目前的 HR 紀錄決定他們目前的 AWS 存取，永遠如此。

Verified Permissions 用於應用程式授權

對 SaaS 應用程式的內部授權（哪個租戶使用者可以對應用程式中的哪個資源執行哪個操作），Amazon Verified Permissions 是受管的基於 Cedar 的授權引擎。在 Cedar 中一次定義政策；透過 Verified Permissions API 每秒評估數百萬次。這取代了自行開發的 RBAC 資料庫，並讓應用程式授權邏輯可稽核且集中管理。

Permissions Boundary 用於開發者自助服務

對 12 個團隊的 80 位開發者，中央 IAM 管理員不能成為瓶頸。Permissions Boundary 是安全委派 IAM 角色建立的方法。

模式

• 中央安全團隊定義名為 PlatformDeveloperBoundary 的 Permissions Boundary 政策。此 boundary 允許 Lambda、DynamoDB、S3、CloudWatch Logs、Secrets Manager、特定金鑰的 KMS decrypt；拒絕 IAM 管理員、Organizations、CloudTrail 修改、Config 修改。
• 開發者 permission sets 授予 iam:CreateRole、iam:PutRolePolicy、iam:PassRole——但有條件 "iam:PermissionsBoundary": "arn:aws:iam::ACCOUNT:policy/PlatformDeveloperBoundary"。開發者只能建立附加了此 boundary 的角色。
• 工作負載 OU 的 SCP 拒絕刪除 boundary 政策，以及拒絕修改標記了 SecurityManaged=true 的任何角色。

結果：開發者可自助建立 Lambda 執行角色、ECS task 角色、CodeBuild 角色——但無法逃脫 boundary。安全團隊不再是部署時的閘門。

整合起來 — 完整的全新解決方案安全設計

對萬租戶 B2B SaaS Greenfield，完整的全新解決方案安全設計如下：

帳號結構

• 管理帳號（Organizations root，使用量最小化）。
• Log Archive 帳號（集中式 CloudTrail、VPC Flow Logs、WAF 日誌、CloudWatch Logs、不可變 S3）。
• 安全帳號（GuardDuty 委派管理員、Security Hub 委派管理員、Config aggregator、Macie 管理員、Detective 管理員、Access Analyzer 組織分析器、Firewall Manager 管理員）。
• 共用服務帳號（ACM Private CA 根 CA 加從屬 CA、Identity Center、共用 VPC Lattice 服務網路）。
• 每個租戶層的工作負載 OU：
  • 白金 OU（帳號級隔離，約 100 個帳號）。
  • 黃金 OU（小型帳號池，VPC 級隔離）。
  • 銀級 OU（共用帳號，命名空間/行級租戶池）。

身分與存取

• Identity Center 透過 SCIM 從 Okta/Azure AD 聯合。
• Permission sets 按團隊角色對齊。
• PlatformDeveloperBoundary Permissions Boundary 用於自助角色建立。
• 每個內部網頁應用程式的 AWS Verified Access 端點；Cedar 政策要求 Identity Center 群組加裝置信任。
• 跨工作負載帳號共用的 VPC Lattice 服務網路；每個服務的 auth policies。
• mTLS 憑證的 ACM Private CA 階層；服務憑證自動輪換。
• 租戶使用者及其權限的應用程式層 RBAC 使用 Amazon Verified Permissions。

資料保護

• 平台服務的每環境 KMS CMK。
• 白金/黃金層的每租戶 KMS CMK。
• 銀級層帶有加密上下文租戶綁定的 pool CMK。
• KMS Grants 用於臨時服務委派（EBS、RDS、Aurora 複本）。
• DR 複製資料的 Multi-Region Keys。
• S3 預設加密 SSE-KMS，bucket keys 啟用。

網路

• 帳號間連接使用 Transit Gateway。
• 服務對服務流量使用 VPC Lattice。
• AWS 服務使用 PrivateLink（減少 API 流量的 NAT gateway 費用）。
• 出口使用 Network Firewall 做 IDS/IPS 與網域允許清單。
• 運算上零公共 IP；所有網際網路流量透過 NAT 或 Network Firewall 出口 VPC。

邊緣

• 每個公共應用程式前方放置 CloudFront。
• WAF 受管規則群組加每工作負載自訂規則，日誌輸出到 S3。
• Shield Advanced 啟用。
• 每個私有資產使用 CloudFront 簽章 URL。
• 公共區域啟用 DNSSEC 的 Route 53。
• Firewall Manager 全組織推送基線 WAF 政策。

偵測與回應

• GuardDuty 含所有防護計畫，自動啟用新帳號。
• Detective 用於鑑識圖。
• Inspector v2 用於 EC2／ECR／Lambda 漏洞掃描。
• Macie 用於 S3 敏感資料探索。
• Security Hub 含 FSBP + CIS + PCI + NIST 標準，跨區域彙整。
• Config aggregator 含組織合規套件（PCI、HIPAA、營運最佳實踐）。
• IAM Access Analyzer 組織分析器（外部存取 + 未使用存取 + 政策生成）。
• 集中發現項目的 EventBridge 匯流排；Lambda 或 Step Functions 自動化用於修復腳本。

日誌

• 組織 CloudTrail 輸出到 Log Archive S3，合規模式 Object Lock。
• 每個 VPC 的 VPC Flow Logs 輸出到中央 S3。
• WAF 完整日誌輸出到中央 S3。
• CloudWatch Logs 訂閱過濾器到中央 Firehose 用於應用程式日誌。
• S3 生命週期：Standard → IA → Glacier Instant Retrieval → Glacier Deep Archive 用於 7 年合規保留。
• CloudTrail Lake 或 Athena 用於中央日誌的臨時查詢。

合規

• Audit Manager 含 SOC 2 Type 2、PCI DSS v4.0、HIPAA Security Rule 框架。
• 來自 CloudTrail、Config、Security Hub 的持續證據收集。
• 季度稽核就緒匯出。

這就是考試所獎勵的全新解決方案安全設計：每個支柱都有回應、每一層都是刻意選擇的，每個服務都因為能完成其他服務無法完成的工作而被選用。

全新解決方案安全設計的成本影響

安全不是免費的，考試也測試具成本意識的設計。

參考 Greenfield 的概略每月成本

對 50 帳號組織（第一年內增長到 200 個）：

• 含所有防護計畫的 GuardDuty：每帳號每月 $500–$2,000（依活動量）。50 個帳號預算 $25,000–$100,000/月。
• Security Hub：50 個帳號的發現項目攝入約 $1,000–$3,000/月。
• Config：依資源數約 $2,000–$5,000/月。
• Detective：$500–$2,000/月。
• Macie 自動化敏感資料探索：依 S3 資料量約 $1,000–$5,000/月。
• Shield Advanced：$3,000/月固定費 + 每個受保護資源。
• KMS：少量（pool 金鑰）到低千位（高級層專屬租戶金鑰）。
• Verified Access：每個端點 $0.27/小時 + 每次請求 $0.02。
• VPC Lattice：每個服務 $0.025/小時 + 每 GB 處理 $0.025。
• CloudTrail S3 儲存（7 年保留）：到第三年增長到 $5,000–$20,000/月。

50 帳號 Greenfield 第一天的安全服務總成本大約是 $40,000–$120,000/月。這是雲端原生合規規模下成熟安全狀態的代價。考試有時問到「降低安全成本」——答案涉及選擇性資料事件日誌、取樣型 Macie、GuardDuty 的區域限制，以及日誌儲存的積極 Glacier 轉換。

最佳化手冊

• 只在有實際工作負載的區域啟用 GuardDuty（結合區域限制 SCP）。
• 對一般儲存桶使用 Macie 自動化敏感資料探索（取樣）；只對 PCI/HIPAA 儲存桶使用目標性工作。
• 選擇性 CloudTrail 資料事件（非全面性 S3 或 Lambda）。
• Security Hub 彙整區域（避免重複攝入成本）。
• KMS bucket keys 大幅降低 S3 的 KMS API 呼叫成本。
• 銀級層租戶使用帶加密上下文的 pool CMK，而非專屬金鑰。

全新解決方案安全設計的常見考試陷阱

陷阱一 — Verified Access 取代 Site-to-Site VPN

錯誤。Verified Access 取代 Client VPN 用於使用者對應用程式存取。Site-to-Site VPN 連接辦公室網路到 VPC，是不同的使用情境。

陷阱二 — VPC Lattice Auth Policies 取代 Security Groups

部分正確。Lattice auth policies 在服務層新增 IAM 型授權；Security Groups 仍存在於 VPC 層。現代模式兩者並用：Security Groups 做粗粒度網路分段，Lattice auth policies 做細粒度每 principal 服務授權。

陷阱三 — 每租戶專屬 KMS 金鑰永遠是對的

錯誤。專屬金鑰適合高隔離層；帶加密上下文的 pool 金鑰適合成本效益的銀級層。在萬租戶情境中「永遠專屬」每月浪費 $10,000+。

陷阱四 — 帳號級隔離是唯一合規的隔離

錯誤。HIPAA 不要求帳號級隔離。設計正確的帶每租戶封包加密的 pool 隔離可滿足 HIPAA。考試有時把帳號級隔離作為「安全」答案；若題目說「10,000 個租戶」——在那個規模，帳號級隔離通常不切實際且錯誤。

陷阱五 — Shield Standard 對合規 SaaS 已足夠

在多數業務關鍵情境中是錯誤的。Shield Standard 免費且涵蓋網路層 DDoS。Shield Advanced 新增應用層 DDoS、24/7 SRT 參與與成本保護。對有 SLA 的 SaaS，Shield Advanced 是基本要求。

陷阱六 — GuardDuty 單獨構成偵測平面

錯誤。GuardDuty 是威脅偵測；Security Hub 彙整發現項目並評分合規；Detective 提供鑑識調查；Inspector 處理漏洞；Macie 處理資料分類。五者共同構成偵測平面，不是只有 GuardDuty。

陷阱七 — CloudFront 簽章 URL 與簽章 Cookie 可互換

部分正確。簽章 URL 限定於單一 URL；簽章 Cookie 限定於符合模式的多個 URL。租戶下載特定報告用簽章 URL；租戶瀏覽有許多檔案的私有資產區用簽章 Cookie。

陷阱八 — ALB 的 WAF 已足夠，不需要 CloudFront

對於面向公眾的合規 workload 是錯誤的。CloudFront 提供邊緣 DDoS 吸收、快取與來源屏蔽——只在區域 ALB 部署 WAF 會暴露來源 IP，且不受益於全球邊緣拒絕。

陷阱九 — Private CA 只對公共網站重要

錯誤。Private CA（AWS Private Certificate Authority）核發微服務間 mTLS 和內部 TLS 的內部憑證。公共網站使用 ACM 公共憑證（免費）。兩者服務不同用途。

陷阱十 — Identity Center 取代企業 IdP

錯誤。Identity Center 從企業 IdP（Okta、Azure AD）聯合。企業 IdP 仍是就業狀態、群組、MFA 的真實來源。Identity Center 是 AWS 端的 SSO 端點。企業 IdP 中斷不意味 AWS 現在是 IdP。

關鍵數字與必記事實

Verified Access

端點類型：瀏覽器（HTTPS）、CLI/API 透過 token broker。信任提供者：一個使用者 + 選用裝置。政策語言：Cedar。日誌：S3/CloudWatch/Firehose。

VPC Lattice

每個服務網路最多 500 個服務。一個 VPC 最多關聯 1 個服務網路。SigV4 認證 + 選用 mTLS。Auth policies 每次請求評估。

KMS

Key policy 具有權威性；同帳號使用 IAM policy 委派；臨時/服務委派使用 Grants。Multi-Region Keys 用於跨地理區域。加密上下文將密文綁定到範圍。Bucket Keys 將 S3 KMS 呼叫成本降低 99%。

多租戶隔離層

Silo（強，貴）→ Pool（較弱，便宜）。帳號級 → VPC 級 → 命名空間級 → 行級。按商業層級的混合設計是務實的 Greenfield 答案。

邊緣

CloudFront + WAF + Shield（關鍵工作負載用 Advanced）+ 簽章 URL。Firewall Manager 用於全組織基線強制執行。

偵測

GuardDuty + Detective + Security Hub + Inspector + Macie + Config + Access Analyzer。全部從安全帳號委派管理員；全部送入 Security Hub。

日誌

組織 CloudTrail 到 Log Archive，Object Lock。VPC Flow Logs。WAF 日誌。CloudWatch Logs 訂閱到中央 Firehose。Athena／CloudTrail Lake 用於查詢。

FAQ — 全新解決方案安全設計高頻問題

Q1 — 何時選擇 AWS Verified Access 而非 AWS Client VPN？

當需求是使用者存取內部網頁應用程式、管理儀表板、開發者工具的應用層 Zero Trust 存取時，選 Verified Access。Verified Access 以身分 + 裝置狀態 + Cedar 政策認證每個請求，並記錄決策。當你需要連到 VPC 的網路層連接（存取非 HTTP 的服務、存取 IP 位址、傳統厚用戶端應用程式）時，選 Client VPN。對 Greenfield SaaS，Verified Access 幾乎永遠是使用者對應用程式的正確選擇；Client VPN 是傳統後備。另外注意 Client VPN 與 Verified Access 可以共存——你可能同時擁有兩者用於不同用途。

Q2 — VPC Lattice auth policies 與 ALB 上的 IAM resource policies 有何不同？

ALB 上的 IAM resource policies 不存在——ALB 不在負載平衡器層支援 IAM 型授權。VPC Lattice 正是引入服務對服務 HTTP 流量 IAM 型授權的服務。若你想要跨 VPC 與帳號的微服務間 Zero Trust 授權，且不需要 sidecar 服務網格，VPC Lattice 搭配 auth policies 是 AWS 原生答案。你可以將 Lattice 與 mTLS（ACM Private CA）結合，在 IAM 型授權之上新增密碼學對等身分驗證。

Q3 — 我應該每租戶使用專屬 KMS 金鑰，還是帶加密上下文的 pool 金鑰？

混合使用。高合規層（PCI、HIPAA、有明確金鑰隔離需求的高級企業客戶）使用專屬金鑰。成本效益的基礎層租戶使用帶加密上下文加 key policy 條件的 pool 金鑰。10,000 個租戶全部專屬，每月光 KMS 金鑰儲存就要 $10,000+——混合模式大幅降低成本，同時為真正重要的租戶保留隔離。加密上下文 tenant_id 將每個密文綁定到其租戶，即使在 pool 金鑰上也能防止跨租戶解密。

Q4 — 如何為 10,000 個租戶的 SaaS 實作多租戶隔離？

將隔離映射到商業層。白金層（前 1%）獲得帶專屬 KMS 金鑰與專屬 VPC 的帳號級隔離。黃金層在共用帳號中獲得帶專屬 KMS 金鑰的 VPC 級隔離。銀級層獲得命名空間級隔離（Kubernetes）+ 行級隔離（資料庫），加上以加密上下文綁定的 pool KMS 金鑰。大規模時，混合設計是務實答案；純帳號級隔離會遇到 Organizations 帳號限制與營運成本壁壘。

Q5 — 面向公眾的 Greenfield SaaS 正確的邊緣安全分層是什麼？

CloudFront 在邊緣（來源混淆、快取、邊緣拒絕）→ CloudFront 上的 WAF（OWASP 受管規則群組、自訂速率限制、機器人控制）→ Shield Advanced（DDoS、SRT、成本保護）→ 來源（ALB／API Gateway／S3）透過 OAC 或 VPC origin 鎖定只接受 CloudFront。對私有內容，CloudFront 簽章 URL／簽章 Cookie 將存取限定於特定 principal 的特定時間段。Firewall Manager 跨組織所有公共端點推送基線 WAF 政策，防止任何租戶帳號端點在沒有 WAF 的情況下上線。

Q6 — GuardDuty 與 Detective 如何協同工作？

GuardDuty 偵測；Detective 調查。GuardDuty 發出發現項目——「角色 X 從 Tor 出口節點存取」——幾分鐘內，分析師跳到 Detective，它顯示該角色 30 天的活動圖：它碰觸的每個資源、每個假設它的 IP、每個有類似行為的相關角色。Detective 是唯讀的，不自行生成發現項目；它消費 CloudTrail、VPC Flow Logs、GuardDuty 發現項目、EKS 稽核日誌。兩者都從安全帳號委派管理員，兩者都應在 Greenfield 的第零天啟用。

Q7 — Shield Advanced 每月 $3,000 對新 SaaS 值得嗎？

對任何有 SLA 的業務關鍵工作負載通常是值得的。好處：攻擊期間 24/7 與 AWS Shield Response Team 的互動、DDoS 成本保護（DDoS 期間的擴展費用退款）、進階應用層 DDoS 偵測、受保護資源上的 WAF 免費。對有企業 SLA 的 B2B SaaS，一次 DDoS 相關中斷的代價遠超 $3,000。在考試中，「具有可用性 SLA 的業務關鍵工作負載，擔心 DDoS」就是 Shield Advanced 的答案。

Q8 — 如何集中 50 個帳號的 CloudTrail 日誌？

從 Organizations 管理帳號建立組織追蹤。輸出到 Log Archive 帳號的單一 S3 儲存桶。啟用合規模式的 S3 Object Lock 與 MFA 刪除。啟用日誌檔案完整性驗證。啟用 CloudWatch Logs 交付用於即時監控。SCP 防止成員帳號建立可能被竄改或產生重複費用的自己的追蹤。Log Archive 帳號沒有人類使用者；調查存取透過另行稽核的緊急角色進行。這是標準模式；SAP-C02 考試期望你知道它。

Q9 — Amazon Verified Permissions 在新 SaaS 設計中扮演什麼角色？

Verified Permissions 處理應用程式層授權——不是「使用者能否認證」（那是 Cognito 或 IdP 的工作），而是「這個已認證的使用者能否對這個資源執行這個操作」。在 Cedar 中定義政策。應用程式以 principal、action、resource 與 context 呼叫 Verified Permissions API；取得允許/拒絕決策。使用情境：具有細粒度角色（管理員、編輯者、檢視者）的租戶使用者、功能旗標限制能力、屬性型存取控制（這個部門的這個使用者可以編輯這個文件類別）。Verified Permissions 取代自行開發的 RBAC 資料庫，並與 Verified Access 共享 Cedar 語言——整個堆疊使用同一套授權語法。

Q10 — Permissions Boundary 如何讓 80 位開發者自助而不冒險？

中央安全定義 PlatformDeveloperBoundary 來限制權限——允許特定模式的 Lambda、DynamoDB、S3；拒絕 IAM 管理員、Organizations、CloudTrail 修改。開發者 permission sets 授予 iam:CreateRole，但有條件要求新角色附加此 boundary。開發者可以建立任何他們想要的角色，但該角色的有效權限受到限制。結合 SCP 防止刪除 boundary 政策，以及 Access Analyzer 偵測非預期的外部存取，80 位開發者可以快速運作而不冒特權提升風險。這是每個 Greenfield 都需要的大規模安全委派模式。

延伸閱讀 — 全新解決方案安全設計的官方 AWS 文件

超出 SAP-C02 範圍的深度閱讀：AWS Well-Architected Security Pillar 白皮書（概念錨點）、AWS Verified Access 文件（Cedar 政策、信任提供者、日誌）、Amazon VPC Lattice 文件（auth policies、mTLS、服務網路）、AWS KMS Developer Guide（key policies、grants、multi-region keys、加密上下文）、AWS Private Certificate Authority 文件（CA 階層、RAM 分享、憑證範本）、AWS SaaS Tenant Isolation Strategies 白皮書（silo/pool 模式與混合）、AWS WAF／Shield／CloudFront 文件（邊緣分層）、GuardDuty／Detective／Security Hub／Config／Macie／Access Analyzer 使用者指南，以及 AWS Security Reference Architecture（SRA）白皮書。

摘要 — 全新解決方案安全設計的決策樹

SAP-C02 考試碰到全新解決方案安全設計情境時，跑這個決策樹：

1. 情境是「使用者要存取內部 Web 應用程式但不走傳統 VPN」？→ AWS Verified Access + Identity Center + Cedar 政策。
2. 情境是「跨 VPC 與帳號的服務對服務 Zero Trust」？→ VPC Lattice 加 auth policies；若需要密碼學層級的對等身分驗證則加上 ACM Private CA 做 mTLS。
3. 情境是「大規模多租戶加密」？→ KMS 階層：基礎層用 pool CMK + encryption context、進階層用專屬 CMK、用 Grant 做服務層委派、用 MRK 做災難復原。
4. 情境是「多租戶 SaaS 隔離」？→ 混合策略：合規／高階層用 account-per-tenant、中階層用 VPC-per-tenant、基礎層用 namespace + row-level + 每租戶的 envelope encryption。
5. 情境是「合規約束 SaaS 的公開邊緣防護」？→ CloudFront + WAF（managed rules）+ Shield Advanced + 簽章 URL + Firewall Manager 基線。
6. 情境是「從第零天就需要跨帳號威脅偵測」？→ GuardDuty（全部 protection plans、delegated admin、auto-enable）+ Detective + Security Hub（FSBP／CIS／PCI／NIST）+ Inspector + Macie。
7. 情境是「合規評分與持續稽核」？→ Security Hub 標準 + Config aggregator 加上 organization conformance packs + Audit Manager frameworks。
8. 情境是「不可竄改的稽核日誌」？→ Organization CloudTrail 寫到 Log Archive S3，搭配 Object Lock compliance mode + VPC Flow Logs + WAF logs + lifecycle 進 Glacier Deep Archive。
9. 情境是「跨帳號 80 位工程師的人類身分」？→ IAM Identity Center 從企業 IdP 聯合 + permission sets + permission boundaries 用於委派 role 建立。
10. 情境是「租戶使用者在應用程式內的授權」？→ Amazon Verified Permissions 配合 Cedar 政策。

掌握這十個分支，SAP-C02 Task 1.2 的全新解決方案安全設計題目就答得出來。全新解決方案安全設計獎勵架構廣度更甚於單一服務的深度——研究服務之間如何組合，正確的全新解決方案安全設計答案永遠會從題幹的明示與隱示需求中浮現。