AWS 機密、憑證與金鑰管理是一組 AWS 服務與設計模式的組合，負責保護 AWS 環境中長期存在的憑證、應用程式機密與加密金鑰材料。核心服務為：AWS Secrets Manager（需要自動輪換的應用程式機密）、AWS Systems Manager Parameter Store（支援選擇性加密的階層式設定儲存），以及 AWS Key Management Service（AWS KMS）（負責包裹每一個機密、每一個 Parameter Store SecureString、每一個 Amazon EBS 磁碟區、每一個 Amazon S3 SSE-KMS 物件，以及每一個 Amazon RDS 資料庫的加密金鑰）。三者共同構成 SCS-C02 Domain 5 Task Statement 5.4 要求你在考試壓力下設計、操作與排錯的 AWS 機密、憑證與金鑰管理層。
考試指引將 Task 5.4 定義為「設計並實作保護憑證、機密與加密金鑰材料的控制措施」，知識項目點名 Secrets Manager、Systems Manager Parameter Store，以及透過 AWS KMS 使用和管理對稱與非對稱金鑰。技能項目則進一步要求：設計輪換機制、設計限制授權使用者的 AWS KMS key policy，以及建立匯入與移除客戶自備金鑰材料的機制。本指南端對端涵蓋每個概念，搭配考試陷阱、白話類比，以及輪換排錯手冊，讓 AWS 機密、憑證與金鑰管理在考試當天不再是猜謎。
什麼是 AWS 機密、憑證與金鑰管理？
AWS 機密、憑證與金鑰管理是 AWS 原生框架，防止長期機密和金鑰材料洩漏到原始碼、設定檔和 Amazon EC2 user data 中。資料庫密碼、API token、OAuth client secret、TLS 私鑰等應用程式憑證，若需要自動輪換則存放於 AWS Secrets Manager，若屬於靜態設定值則存放於 AWS Systems Manager Parameter Store。包裹這些機密以及保護靜態資料的加密金鑰存放於 AWS KMS，AWS CloudHSM 則作為單租戶 FIPS 140-2 Level 3 的進階選項。
設計空間由三個核心問題定義。第一，機密必須輪換，讓洩漏的憑證迅速失效；AWS Secrets Manager 透過受管 rotation Lambda function 解決這個問題。第二，機密必須能被工作負載取用，且絕不以明文出現在磁碟上；AWS Secrets Manager 和 AWS Systems Manager Parameter Store 都提供 SDK 取用、記憶體內傳遞的方式。第三，保護所有機密的金鑰本身必須受到防護、稽核與輪換；AWS KMS 透過信封加密、key policy、grants 和自動金鑰輪換來彌補這個缺口。AWS 機密、憑證與金鑰管理是上述三個答案的聯集。
- AWS Secrets Manager：受管 AWS 服務，透過 Lambda rotation function 儲存、取用與輪換應用程式機密。
- AWS Systems Manager Parameter Store：階層式設定儲存；SecureString 參數以 AWS KMS 加密。
- AWS KMS key（CMK）：AWS Key Management Service 頂層金鑰物件；分為 AWS 擁有、AWS 受管或客戶受管三種。
- 對稱 AWS KMS key：AES-256-GCM 金鑰，用於加密與解密；每個 AWS Region 一份金鑰材料（Multi-Region Key replica 例外）。
- 非對稱 AWS KMS key：RSA 或 ECC 金鑰對，用於簽章/驗證或搭配公開金鑰的加密/解密。
- 匯入金鑰材料（BYOK）：客戶自備金鑰位元組載入 AWS KMS key；僅支援對稱金鑰，最長有效期 384 天。
- Grant：暫時性、程式化的 AWS KMS 權限委派；疊加於 key policy 和 IAM 之上。
- AWSCURRENT、AWSPENDING、AWSPREVIOUS：AWS Secrets Manager 在輪換期間標記機密版本的暫存標籤。
- Reference: https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html
AWS 機密、憑證與金鑰管理對 SCS-C02 的重要性
Domain 5（資料保護）佔 SCS-C02 考試的 18%，Task 5.4 約佔該 Domain 的四分之一。出題者最愛的情境包括：「rotation Lambda 無法連線到資料庫——哪裡出了問題？」（VPC 連通性或 rotation Lambda IAM）、「團隊需要跨帳號存取客戶受管 AWS KMS key——最低限度的設定為何？」（key policy 加上 identity policy）、「團隊必須使用自己的金鑰材料並能隨時撤銷——是哪個 AWS KMS 功能？」（匯入金鑰材料），以及「公司儲存永不變動的 OAuth client secret——用 Secrets Manager 還是 Parameter Store？」（Parameter Store SecureString，除非需要輪換）。掌握這四個題型家族，AWS 機密、憑證與金鑰管理就成為高收益的備考區域。
白話文解釋 AWS 機密、憑證與金鑰管理
AWS 機密、憑證與金鑰管理內容密集，具體的類比最能發揮效果。以下四個各具特色的類比，合力涵蓋 Task 5.4 的每個概念。
類比一：夜市攤位老闆與輪換保險箱鑰匙（Secrets Manager rotation）
想像一個熱鬧的台灣夜市。每個攤位（你的應用程式）需要一把能開啟儲藏室（資料庫）的鑰匙。AWS Secrets Manager 是攤主公會的保管員，保存每把鑰匙的備份；rotation Lambda function 是深夜當班的巡邏員，依固定排程走到儲藏室換鎖、製作新鑰匙，把新鑰匙交給保管員，再停用舊鑰匙。換鑰匙的過程中，保管員把鑰匙分別標上 AWSCURRENT（現用的那把）、AWSPENDING（新製作正在測試的那把）和 AWSPREVIOUS（剛退役的那把），讓手上還握著舊鑰匙的攤位老闆在巡邏員確認換鑰成功前，仍能開門做生意。若巡邏員無法到達儲藏室（網路被封鎖），或沒有換鎖的權限（IAM），輪換就會失敗，保管員向 Amazon CloudWatch 觸發警報，人工操作員必須介入調查。AWS 為 Amazon RDS、Amazon Aurora 等熱門服務提供受管 rotation Lambda 範本，其他任何機密則可自行撰寫自訂 rotation Lambda。
類比二：大樓公佈欄 vs 保管員辦公室（Parameter Store vs Secrets Manager）
同一個夜市還有一面公佈欄（AWS Systems Manager Parameter Store），是一個階層式的索引系統，每個格子（/prod/db/host、/prod/db/port、/prod/db/password）放著一張小紙條。多數紙條是公開資訊（主機位址、通訊埠、區域），放在普通信封裡（String 參數）。少數幾張紙條有敏感內容（API token、TLS 金鑰），放在上鎖的格子裡（SecureString 參數），鎖由 AWS KMS 控管。公佈欄沒有巡邏員——Parameter Store 不會自動輪換值。保管員辦公室就是 AWS Secrets Manager，收費較高，但全天候配備輪換巡邏員。選擇原則：需要輪換 → 保管員辦公室（Secrets Manager）；靜態設定偶爾含幾個敏感值 → 公佈欄（Parameter Store）。公佈欄的標準層免費，進階層才收費；保管員辦公室每個機密每月約 USD 0.40 加上 API 費用。
類比三：銀行金庫與兩種鑰匙類型（KMS 對稱 vs 非對稱）
想像一間銀行有兩個鑰匙櫃。對稱鑰匙櫃放的是開鎖和上鎖用同一把銅鑰匙的鑰匙——每個保管箱一把黃銅鑰匙。AWS KMS 對稱金鑰就是這樣運作的：一把 256 位元 AES-GCM 金鑰負責加密和解密，金鑰材料永遠不離開 AWS KMS。非對稱鑰匙櫃放的是配對的鑰匙：任何人都能複製的公鑰，以及銀行嚴格保管的私鑰。AWS KMS 非對稱金鑰就是這樣運作的：RSA 或 ECC 金鑰對，公鑰那半可以匯出分發（讓客戶在平台以外加密資料或驗證簽章），私鑰那半則留在 AWS KMS 內。日常加密/解密以及 AWS 服務整合（Amazon S3、Amazon EBS、Amazon RDS 都需要對稱 AWS KMS 金鑰）選對稱金鑰；數位簽章、簽章驗證，以及加密方不能擁有解密金鑰的場景選非對稱金鑰。
類比四：開卷考 vs 工具箱（BYOK vs 自動輪換 vs 手動輪換）
把 AWS KMS 輪換想像成考試。自動金鑰輪換是帶著預備參考資料的開卷考——AWS KMS 每 365 天（或你設定的 90 到 2,560 天週期）自動為客戶受管對稱金鑰產生新的金鑰材料，保留舊材料讓舊密文仍能解密，應用程式毫無感知，因為 key ID 和 ARN 都不會改變。手動輪換是工具箱方式——你建立一把全新的 AWS KMS key，把 alias 從舊金鑰指向新金鑰，並重新加密任何希望由新材料保護的資料。匯入金鑰材料（BYOK）是自備教科書的考試——你在 AWS 外部產生金鑰材料，用 AWS KMS 提供的公鑰包裹後匯入，設定最長 384 天的有效期，材料到期後再重新匯入或換到新金鑰。BYOK 不支援自動輪換。取捨在於：BYOK 讓你掌握最高程度的保管權（可以撤回金鑰材料），但增加了操作負擔（必須手動重新匯入或輪換）。
題目說「每週輪換資料庫憑證」，想夜市保管員換鑰匙——AWS Secrets Manager 加 rotation Lambda。題目說「便宜儲存 API endpoint、通訊埠和幾個敏感 token」，想公佈欄——AWS Systems Manager Parameter Store。題目說「必須在 AWS 外部保留原始金鑰位元組並能隨時撤銷」，想自備教科書的考試——AWS KMS 匯入金鑰材料。Reference: https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html
AWS Secrets Manager 深度解析
AWS Secrets Manager 是機密需要自動輪換、稽核，以及與資料庫引擎整合時的首選 AWS 服務。它將機密以 AWS KMS key 加密後儲存（預設使用 AWS 受管的 aws/secretsmanager 金鑰，或你指定的任何客戶受管 AWS KMS key），對每個值進行版本管理，並套用暫存標籤（AWSCURRENT、AWSPENDING、AWSPREVIOUS），讓呼叫端在輪換進行中時始終讀到已知正確的版本。
AWS 受管資料庫的原生輪換
針對五項 AWS 服務，AWS Secrets Manager 內建預製的 rotation Lambda 範本：Amazon RDS（所有支援的引擎）、Amazon Aurora、Amazon Redshift、Amazon DocumentDB，以及 Amazon ElastiCache for Valkey/Redis。啟用輪換後，選擇排程（例如每 30 天），AWS Secrets Manager 會自動串接 Lambda、IAM role 和 KMS 權限。Lambda 在每次輪換時呼叫資料庫引擎的密碼變更 API，更新機密，Amazon CloudWatch 記錄成功或失敗事件。
三種 rotation Lambda 策略
rotation Lambda 實作三種策略之一，各自適用不同的應用程式架構。理解哪種策略適用於哪種場景，是 SCS-C02 常見的考題。
- Single-user rotation（單使用者輪換）。 一個資料庫使用者。Lambda 在每次輪換時變更該使用者的密碼。模式最簡單，但輪換期間若應用程式剛好重新連線，可能短暫看到舊密碼。
- Alternating-user rotation（交替使用者輪換）。 兩個具備相同權限的資料庫使用者（
appuser_a和appuser_b）。Lambda 輪換其中一個使用者的密碼，同時另一個保持可用，完成後翻轉暫存標籤，讓應用程式下次讀取時透明切換到新的活動使用者。消除了 single-user rotation 短暫中斷的窗口。建議用於生產 OLTP 工作負載。 - Master-user rotation（主使用者輪換）。 以一個擁有較高權限的「master」使用者（其憑證存放在另一個 Secrets Manager 機密中）來變更應用程式使用者的密碼。應用程式使用者沒有自行更改密碼的權限，滿足更嚴格的職責分離要求。
任意機密的自訂 rotation Lambda
除了 AWS 受管的五種以外，你可以為任何機密撰寫自訂 rotation Lambda——第三方 API token、SaaS 金鑰、地端資料庫密碼，甚至 Active Directory 服務帳號密碼。Lambda 實作四個步驟：createSecret、setSecret、testSecret、finishSecret。AWS Secrets Manager 依序呼叫 Lambda 執行每個步驟，並透過暫存標籤追蹤進度。
跨帳號與跨 Region 機密共享
AWS Secrets Manager 在每個機密上支援資源政策，因此你可以授予另一個 AWS 帳號的主體呼叫該機密的 secretsmanager:GetSecretValue 的權限。對於多 Region 應用程式，AWS Secrets Manager 支援自動跨 Region 複寫：us-east-1 的主要機密持續複寫到 eu-west-1，主要機密的輪換事件也會傳播到副本。跨 Region 複寫是 AWS Secrets Manager 獨有的功能——AWS Systems Manager Parameter Store 原生不支援複寫。
rotation Lambda 執行後若無法連線到目標資料庫，從安全操作員的角度來看會靜默失敗，除非事先設定警報。兩項連通性要求：(1) rotation Lambda 的執行角色必須具備 secretsmanager:UpdateSecretVersionStage、secretsmanager:DescribeSecret、secretsmanager:GetSecretValue、secretsmanager:PutSecretValue，以及對加密該機密的 AWS KMS key 的 kms:Decrypt 和 kms:GenerateDataKey。(2) 若資料庫位於私有 Amazon VPC 子網路，rotation Lambda 必須設定為在該 Amazon VPC 內執行，並使用能連線到資料庫通訊埠的 security group；否則輪換步驟 setSecret 會逾時。Reference: https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets-lambda-function-overview.html
偵測輪換失敗
輪換失敗是一個安全事件：現有憑證仍然有效（因此應用程式繼續運作），但輪換節奏已中斷（因此憑證比政策允許的更老舊）。AWS Secrets Manager 在輪換未成功完成時，會發布 RotationFailed 指標和 Amazon EventBridge 事件 Rotation Failed。建議的 SCS-C02 設計是：對 RotationFailed 建立 Amazon CloudWatch 警報，並設定 Amazon EventBridge 規則將事件轉發至 Amazon SNS 或 AWS Security Hub，讓值班工程師在幾分鐘內收到通知。
AWS Systems Manager Parameter Store 深度解析
AWS Systems Manager Parameter Store 是存放階層式設定值的 AWS 服務。它支援三種參數類型：String、StringList 和 SecureString。只有 SecureString 會呼叫 AWS KMS。
標準層 vs 進階層
AWS Systems Manager Parameter Store 有兩個層級。標準層免費，每個 AWS 帳號每個 AWS Region 最多 10,000 個參數，值的大小限制為 4 KB。進階層每個進階參數每月 USD 0.05，最多 100,000 個參數，值大小限制為 8 KB，並新增參數政策（TTL 到期、到期通知、無變更通知）。大多數工作負載標準層已足夠；僅在需要參數政策或較大值時才升級至進階層。
SecureString 與 AWS KMS
SecureString 參數在靜態時以 AWS KMS key 加密——預設使用 AWS 受管的 aws/ssm 金鑰，或你指定的客戶受管 AWS KMS key。AWS KMS key 以信封加密方式加密值：AWS Systems Manager 呼叫 kms:GenerateDataKey，以資料金鑰在本地加密值，並將加密後的資料金鑰與密文一起儲存。取用時需要對 AWS KMS key 的 kms:Decrypt 以及對參數的 ssm:GetParameter，因此每次讀取都受到兩層授權保護。
階層式命名與 IAM 範圍
Parameter Store 強制使用路徑式命名慣例：/prod/web/db/password、/prod/web/db/host、/staging/api/token。這個階層結構是細粒度 AWS IAM policy 的基礎——你可以授予主體對 arn:aws:ssm:us-east-1:123456789012:parameter/prod/web/* 的 ssm:GetParametersByPath，該主體就能讀取所有 prod web 參數，無需逐一列舉。這個模式是多環境部署的核心，在 SCS-C02 上比扁平命名的參數儲存更受青睞。
參數政策（僅限進階層）
附加到進階層參數的參數政策可以做三件事：Expiration（在未來的時間戳記自動刪除參數）、ExpirationNotification（在到期前 N 天發送 Amazon EventBridge 事件，讓你有時間輪換值），以及 NoChangeNotification（若參數在 N 天內未變更，發送 Amazon EventBridge 事件以偵測過時的設定）。參數政策是 Parameter Store 最接近原生輪換的功能——它們提醒你，但不像 AWS Secrets Manager rotation Lambda 那樣自動變更值。
- 需要自動輪換憑證？→ AWS Secrets Manager。
- 靜態設定（主機、通訊埠、ARN）搭配少數敏感值？→ AWS Systems Manager Parameter Store SecureString。
- 需要機密本身的跨 Region 複寫？→ AWS Secrets Manager（Parameter Store 不原生複寫）。
- 成本敏感的工作負載有數千個小設定值？→ Parameter Store 標準層（免費）；保留 Secrets Manager 給真正需要輪換的機密（每個機密每月 USD 0.40 加上每 10,000 次 API 呼叫 USD 0.05）。
Reference: https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html
AWS KMS 對稱金鑰
對稱金鑰是 AWS 機密、憑證與金鑰管理的主力。每一個說「以 AWS KMS 加密」的原生 AWS 服務整合——Amazon S3 SSE-KMS、Amazon EBS 加密、Amazon RDS 加密、Amazon DynamoDB 加密、AWS Secrets Manager、AWS Systems Manager Parameter Store SecureString——底層都使用對稱 AWS KMS key。
對稱 AWS KMS key 的特性
對稱 AWS KMS key 是以 GCM 模式運作的 256 位元 AES 金鑰。金鑰材料在 AWS KMS 的 FIPS 140-2 驗證硬體邊界內產生，並且永遠不以明文離開該邊界。每個 AWS KMS key 的範圍限定於一個 AWS Region（Multi-Region Key 是特例，詳見下文）。支援的操作包括 Encrypt、Decrypt、GenerateDataKey、GenerateDataKeyPair、GenerateRandom、ReEncrypt，以及各種管理操作。
金鑰規格與來源
你選擇金鑰規格（對稱 AES-256-GCM 選 SYMMETRIC_DEFAULT）以及來源：
AWS_KMS— AWS KMS 產生並持有材料；自動輪換必須使用此選項。EXTERNAL— 你匯入金鑰材料；僅支援對稱金鑰，無法自動輪換。AWS_CLOUDHSM— 材料存放於你的 AWS CloudHSM 自訂金鑰存放區；單租戶 FIPS 140-2 Level 3。EXTERNAL_KEY_STORE— 材料存放於 proxy 後方的外部 HSM；用於混合主權工作負載。
Multi-Region Keys（MRK）
Multi-Region Key 是一種客戶受管的 AWS KMS key，在多個 AWS Region 之間複寫，同時共用相同的 key ID 和金鑰材料。us-east-1 的 MRK 和 eu-west-1 的副本可以互通加解密同一份密文，這簡化了儲存密文的 AWS 服務（Amazon DynamoDB Global Tables、Amazon S3 跨 Region 複寫）的跨 Region 容錯移轉。對 MRK 啟用輪換時，會在所有 Region 同步輪換金鑰材料——它們本來就共享金鑰材料。若不使用 MRK，跨 Region 容錯移轉需要以目的地 Region 的 AWS KMS key 重新加密密文。
AWS KMS 非對稱金鑰
非對稱 AWS KMS key 存在於兩個特定使用場景：數位簽章/驗證，以及加密方不能擁有解密金鑰的加密/解密。
非對稱 AWS KMS key 的金鑰規格
- RSA_2048、RSA_3072、RSA_4096 — 用於簽章或加密的 RSA 金鑰對。
- ECC_NIST_P256、ECC_NIST_P384、ECC_NIST_P521 — 用於簽章的 NIST 橢圓曲線。
- ECC_SECG_P256K1 — 比特幣等加密貨幣用於簽章的曲線。
- SM2（僅限中國 Region）— 中國政府核准的簽章/加密。
- HMAC_224、HMAC_256、HMAC_384、HMAC_512 — 用於訊息認證碼的對稱 HMAC 金鑰（技術上屬於對稱，但因為是簽章金鑰而非加密金鑰，考試覆蓋範圍上常與非對稱歸為同類）。
金鑰用途模式
你為每個非對稱 AWS KMS key 宣告 SIGN_VERIFY 或 ENCRYPT_DECRYPT 的金鑰用途。兩種模式在單一 AWS KMS key 上互斥——你無法用同一把 RSA 金鑰同時進行簽章和加密。SCS-C02 常見陷阱就在這裡：題目給你一把簽章用的 AWS KMS key，問「為什麼加密會失敗？」答案是該金鑰的 KeyUsage 是 SIGN_VERIFY 而非 ENCRYPT_DECRYPT。
公鑰匯出
任何非對稱 AWS KMS key 的公鑰那半可以透過 kms:GetPublicKey 匯出並自由分發——客戶可以驗證簽章，或加密只有 AWS KMS 內的私鑰才能解密的資料。這是 JWT 簽章等模式的基礎：行動客戶端驗證 token 的簽章，卻從未看到私鑰。
SCS-C02 常見陷阱是在 Amazon S3 SSE-KMS 情境中把「使用非對稱 AWS KMS key」列為干擾選項。Amazon S3 SSE-KMS、Amazon EBS 加密、Amazon RDS 加密、AWS Secrets Manager 和 AWS Systems Manager Parameter Store SecureString 都需要對稱 AWS KMS key。非對稱 AWS KMS key 適用於簽章/驗證，或直接呼叫 KMS API 的應用程式層加密/解密。Reference: https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html
AWS KMS 金鑰輪換——自動 vs 手動
輪換在保留 AWS KMS key 身份識別（key ID 和 ARN）的同時，替換底層的加密材料。這是 SCS-C02 最常考的單一知識點之一，也是 Task 5.4 技能項目「為工作負載設計機密及 AWS KMS 客戶受管金鑰的管理和輪換」的核心。
自動輪換
對於 Origin = AWS_KMS 的客戶受管對稱 AWS KMS key，你可以啟用自動金鑰輪換。AWS KMS 預設每 365 天輪換底層加密材料，自 2024 年起可設定為 90 到 2,560 天。重要特性：
- AWS KMS key 的 ID 和 ARN 不會改變——應用程式持續參照相同的 ARN。
- 保留舊金鑰材料，讓先前加密的資料仍可解密。
- 輪換是透明的——不需要重新加密現有資料。
- AWS 受管金鑰每年自動輪換，你無法關閉或修改週期。
- 自動輪換僅適用於使用 AWS 擁有材料的對稱 AWS KMS key——非對稱金鑰和匯入材料的金鑰不能使用自動輪換。
手動輪換（alias 切換）
對於非對稱 AWS KMS key、使用匯入金鑰材料的 AWS KMS key，以及任何無法使用自動輪換的情境，輪換模式是 alias 切換式手動輪換：
- 建立一把全新的 AWS KMS key，使用全新的金鑰材料。
- 將 alias（
alias/my-app-key）更新為指向新的 AWS KMS key。 - 重新加密任何希望由新材料保護的密文（或接受舊密文繼續由舊金鑰保護）。
參照 alias 而非底層 key ID 的應用程式，不需要任何程式碼變更就能繼續運作。舊的 AWS KMS key 維持 Enabled 狀態，讓舊密文仍可解密。
Multi-Region Key 輪換
當你在 Multi-Region 主要金鑰上啟用自動輪換時，輪換會傳播到每個 AWS Region 的每個副本——它們本來就共享金鑰材料。你只在主要金鑰上啟用輪換；副本自動繼承。這是 MRK 相較於各 Region 單獨建立金鑰的操作優勢之一。
- 自動輪換：預設 365 天，可設定 90–2,560 天；僅限
AWS_KMS來源的對稱客戶受管金鑰。 - AWS 受管金鑰：每年自動輪換一次；無法停用，無法調整排程。
- AWS 擁有金鑰：AWS 依自己的排程輪換；對你不可見。
- Key ID 和 ARN 在輪換後保持不變——應用程式持續正常運作。
- 保留舊金鑰材料，讓先前的密文仍可解密。
- 非對稱金鑰、匯入材料金鑰和 CloudHSM 自訂金鑰存放區的金鑰，需要手動（alias 切換）輪換。
- Multi-Region Key：只在主要金鑰上啟用輪換；副本自動繼承。
Reference: https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html
匯入客戶自備金鑰材料（BYOK）
Bring Your Own Key（BYOK）讓你在 AWS 外部產生金鑰位元組，匯入到 AWS KMS key，並保留主要副本，以便日後透過刪除匯入材料來撤銷存取。Task 5.4 技能項目「建立匯入與移除客戶自備金鑰材料的機制」直接對應此功能。
BYOK 工作流程
- 建立一個
Origin = EXTERNAL、金鑰規格為SYMMETRIC_DEFAULT的 AWS KMS key。金鑰從PendingImport狀態開始，尚無法加密或解密。 - 呼叫
kms:GetParametersForImport取得公開包裹金鑰和一次性匯入 token。包裹金鑰為 RSA-2048、RSA-3072 或 RSA-4096；匯入 token 在 24 小時後過期。 - 在你的環境中（使用地端 HSM、OpenSSL 或任何 FIPS 驗證的來源）產生一個 256 位元 AES 金鑰。
- 以公開包裹金鑰（RSA-OAEP 填充）包裹你的金鑰位元組，並呼叫
kms:ImportKeyMaterial，帶入包裹後的位元組、匯入 token，以及可選的到期時間戳記（自匯入起最長 384 天）。 - AWS KMS key 轉換到
Enabled狀態，應用程式可以透過其 ARN 進行加密/解密。
移除匯入金鑰材料
你可以隨時呼叫 kms:DeleteImportedKeyMaterial。AWS KMS key 立即轉換到 PendingImport 狀態，停止解密密文。任何以該材料加密的資料，在你重新匯入完全相同的金鑰位元組之前都無法解密（你必須在 AWS 外部保留主要副本）。這是 SCS-C02「緊急停止」模式：監管機構可以要求你在幾秒內切斷 AWS 對金鑰材料的存取，只需刪除 AWS KMS 中的匯入位元組即可。
BYOK 限制
- 僅限對稱金鑰。 非對稱 AWS KMS key 不能使用匯入材料。
- 不支援自動輪換。 你必須手動輪換：將新金鑰材料匯入到新的 AWS KMS key 並更新 alias。
- 最長 384 天有效期。 匯入材料會到期；你在匯入時設定到期時間。到期前必須重新匯入（相同位元組或新位元組——重新匯入相同位元組會重設到期，AWS KMS 稱之為「rewrapping」）。
- 僅限同一 Region。 匯入材料不會複寫到 MRK 副本——每個副本需要各自匯入。
SCS-C02 情境中包含「公司必須在 AWS 外部保留金鑰材料副本」、「法規要求客戶能隨時撤銷 AWS 對金鑰材料的存取」或「資料主權規定金鑰必須在客戶自己的設施中產生」等描述時，指向的是 AWS KMS 匯入金鑰材料（BYOK）。AWS 受管金鑰、AWS_KMS 來源的客戶受管金鑰，甚至 AWS CloudHSM 自訂金鑰存放區，都無法如此乾淨地滿足這些要求，因為 AWS 仍然產生或持有唯一副本。Reference: https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html
AWS KMS Key Policy——主要存取控制機制
每個 AWS KMS key 都有一個 key policy——一份直接附加到 AWS KMS key 的 JSON 文件。與 Amazon S3 或 Amazon DynamoDB 不同，AWS KMS 將 key policy 視為主要存取控制機制。沒有 key policy 中的明確允許，任何 AWS IAM policy 和任何 grant 都無法授權 AWS KMS 操作。
預設 key policy 與 IAM 委派陳述
當你在 AWS 主控台建立客戶受管 AWS KMS key 時，預設 key policy 包含兩個重要陳述：一個授予 kms:* 給 AWS 帳號 root 的根委派陳述（確保帳號擁有者永遠不會失去金鑰控制權），以及一個**「Enable IAM policies」**陳述，透過允許同一 AWS 帳號中的主體在其 AWS IAM policy 明確允許的情況下呼叫任何 AWS KMS 操作，將授權委派給 AWS IAM。IAM 委派陳述讓 AWS KMS 感覺像其他 AWS 服務——但這是可選的。若你移除該陳述，AWS IAM policy 就無法在這個 AWS KMS key 上生效，只有在 key policy 中明確列舉的主體才能使用它。這是高度敏感 AWS KMS key 的建議強化措施。
跨帳號 AWS KMS key 存取
帳號 B 中的 AWS 主體若要使用帳號 A 擁有的 AWS KMS key，需要兩個條件同時滿足：
- 帳號 A 的 key policy 必須明確允許帳號 B 的主體（或帳號 B 的帳號 root）呼叫所需的 AWS KMS 操作。這是大門；沒有這個，什麼都不能運作。
- 帳號 B 的 identity policy 必須授予該主體對帳號 A AWS KMS key ARN 的相同 AWS KMS 操作。這是消費端的一般 AWS IAM 授予。
兩層都必須允許該操作；任何一層的沉默等同於拒絕。這個雙重政策模型在跨帳號 Amazon S3 SSE-KMS 情境中反覆出現：帳號 A 中的 bucket 以帳號 A 中的客戶受管 AWS KMS key 加密，帳號 B 中的消費者試圖讀取它。若 AWS KMS key policy 或帳號 B 的 identity policy 任一缺少授予，GetObject 就會失敗，錯誤訊息引用的是 AWS KMS 而非 Amazon S3。
AWS 受管 CMK 不能跨帳號共享
SCS-C02 常見陷阱：題目提議用 AWS 受管金鑰 aws/s3 加密共享的 Amazon S3 bucket，並授予跨帳號存取。這行不通。 AWS 受管 AWS KMS key（aws/s3、aws/ebs、aws/rds、aws/secretsmanager）有固定的 key policy，你無法編輯，而且該 key policy 不授予其他 AWS 帳號存取。解決方法是使用客戶受管 AWS KMS key，其 key policy 你可以編輯以授予跨帳號存取。
題目問「團隊在 bucket 上啟用了 SSE-KMS，但跨帳號讀取仍然失敗」時，檢查 bucket 設定使用的是哪把 AWS KMS key。Amazon S3 預設加密主控台選項中「AWS KMS key」但未選擇 key ARN 時，使用的是 aws/s3（AWS 受管）——該金鑰不能跨帳號共享。團隊必須在 bucket 預設加密設定中明確選擇客戶受管 AWS KMS key（或按物件覆寫），並編輯該金鑰的 key policy 以允許消費帳號存取。Reference: https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html
AWS KMS Grants——暫時權限委派
Grant 是一種暫時性、程式化的 AWS KMS 權限委派，從一個主體委派給另一個主體。Grants 疊加於 key policy 和 IAM policy 之上；它們永遠不會覆蓋 key policy 中的明確拒絕。
Grant 的使用場景
Grants 主要存在於 AWS 服務整合。當你啟動一個使用加密 Amazon EBS 磁碟區的 Amazon EC2 執行個體時，Amazon EBS 會在 AWS KMS key 上建立一個範圍限定於該磁碟區的 grant，讓 AWS 服務可以代表 EC2 執行個體解密。當 AWS Lambda 設定了加密的環境變數時，Lambda 也會建立 grant。這些 grant 具有短暫性，你可以用 kms:RetireGrant 或 kms:RevokeGrant 撤銷它們。
Grant 限制條件與加密情境
Grant 可以限定到特定的操作（grantee operations）、特定的被授予主體，以及特定的加密情境（encryption context）——傳遞給加密/解密呼叫的額外認證資料。Encryption context 是 AWS KMS 最強大的功能之一：透過要求針對 grant 的任何解密呼叫必須包含特定的加密情境（例如 tenant=acme-corp），你能防禦混淆代理人攻擊（confused-deputy attack）——被授予主體試圖用 AWS KMS key 解密錯誤租戶的資料。
ListGrants 與 grant 生命週期
kms:ListGrants 回傳 AWS KMS key 上的每個 grant，這在金鑰遭到入侵的事件回應期間至關重要——你需要列舉每個有效的 grant 並撤銷它們。服務連結角色會自動建立 grants，因此清單中常有你自己未建立的項目；大量撤銷前請仔細審查。
Encryption context 並未加密，但它繫結在密文中：若加密呼叫設定了 tenant=acme-corp，解密呼叫必須傳入完全相同的值，否則 AWS KMS 拒絕。你可以在 AWS IAM policy 條件中固定這一點："Condition": {"StringEquals": {"kms:EncryptionContext:tenant": "acme-corp"}}。結果是在一個共享的 AWS KMS key 上實現每租戶授權，無需每個租戶各自建立一把金鑰。Reference: https://docs.aws.amazon.com/kms/latest/developerguide/grants.html
常見陷阱與考試模式
SCS-C02 關於 AWS 機密、憑證與金鑰管理的題目，圍繞著一組數量有限的關鍵辨別事實。記住這些，你就能消解大多數的干擾選項。
陷阱一：AWS 受管 CMK 不能自訂或跨帳號共享
alias 為 aws/s3、aws/ebs、aws/rds、aws/dynamodb、aws/secretsmanager、aws/ssm 的金鑰都是 AWS 受管的。你不能編輯它們的 key policy，不能跨帳號共享，也不能停用每年一次的自動輪換。若情境需要跨帳號、自訂稽核或自訂 key policy，答案是客戶受管 AWS KMS key。
陷阱二：對稱 vs 非對稱用於 AWS 服務整合
AWS 服務整合（Amazon S3 SSE-KMS、Amazon EBS、Amazon RDS、Amazon DynamoDB、AWS Secrets Manager、AWS Systems Manager Parameter Store SecureString）需要對稱 AWS KMS key。非對稱 AWS KMS key 適用於應用程式層的簽章/驗證，或加密方不能擁有解密金鑰的場景。
陷阱三：匯入材料金鑰不能自動輪換
匯入材料的 AWS KMS key（BYOK）不能使用自動輪換。若情境說「我們使用 BYOK 且每 90 天輪換」，輪換是手動的——alias 切換或重新匯入。出題者喜歡把「在匯入金鑰上啟用自動輪換」列為干擾選項；直接排除。
陷阱四：Parameter Store 不會自動輪換值
Parameter Store SecureString 在靜態時以 AWS KMS 加密值，但不會自動輪換值。若情境需要自動憑證輪換，答案是 AWS Secrets Manager 或你自己撰寫的自訂 Lambda；單靠 Parameter Store 是不夠的。
陷阱五：rotation Lambda 必須能連線到資料庫
輪換失敗幾乎總是以下兩個原因之一：(1) rotation Lambda 的 IAM role 對機密、AWS KMS key 或資料庫引擎 API 缺少權限；(2) rotation Lambda 在資料庫的 Amazon VPC 外部執行，無法連線到資料庫通訊埠。若題目描述「輪換已七天未完成」，先檢查 VPC 連通性，再檢查 IAM。
陷阱六：Encryption context 是密文的一部分
若你以 EncryptionContext = {tenant=acme} 加密，解密時必須傳入完全相同的 context。Context 不儲存在密文標頭中——你的應用程式必須記住並提供它。出題者會描述一個在取用時丟棄 encryption context 的應用程式，並詢問解密為何失敗。
SCS-C02 要求你同時推理這四個層次。Key policy 是所有操作的大門；AWS IAM policy 在 key policy 的邊界內細化或擴展；grants 為 AWS 服務或特定工作流程添加暫時委派；encryption context 將個別密文繫結到授權條件。任何一個層次的缺失都會打斷整條鏈。Reference: https://docs.aws.amazon.com/kms/latest/developerguide/overview.html
決策框架：選擇正確的 AWS 服務
使用這個決策樹，在幾秒內分類 SCS-C02 情境。
- 機密需要自動輪換嗎？ 是 → AWS Secrets Manager。否 → 優先考慮 AWS Systems Manager Parameter Store SecureString。
- 機密需要跨 Region 複寫嗎？ 是 → AWS Secrets Manager（原生複寫）。否 → 兩種服務皆可。
- 你在儲存數千個小設定值，大多數非敏感？ 是 → AWS Systems Manager Parameter Store 標準層（免費）。
- 加密金鑰需要 FIPS 140-2 Level 3 單租戶硬體？ 是 → AWS CloudHSM（或以 AWS CloudHSM 支援的 AWS KMS 自訂金鑰存放區）。否 → AWS KMS 客戶受管金鑰。
- 客戶必須在 AWS 外部保留金鑰材料的主要副本？ 是 → AWS KMS 匯入金鑰材料（BYOK）。否 → AWS_KMS 來源（可使用自動輪換）。
- AWS KMS key 被 AWS 服務整合使用（Amazon S3、Amazon EBS、Amazon RDS）？ 是 → 對稱，
SYMMETRIC_DEFAULT。否，你直接呼叫 KMS API 進行簽章？→ 非對稱。 - 需要跨帳號或跨 Region 存取？ 客戶受管 AWS KMS key，搭配編輯後的 key policy 加上消費端的 identity policy。AWS 受管金鑰不能跨帳號共享。
常見問題
AWS Secrets Manager 與 AWS Systems Manager Parameter Store 有什麼不同？
AWS Secrets Manager 提供透過 Lambda function 的內建自動輪換，原生整合 Amazon RDS/Aurora/DocumentDB/Redshift/ElastiCache，並支援跨 Region 複寫。每個機密每月約 USD 0.40 加上 API 費用。AWS Systems Manager Parameter Store 提供具有免費標準層和進階層（每個進階參數 USD 0.05）的階層式設定儲存，但不自動輪換值。若輪換是必要需求，使用 AWS Secrets Manager；若憑證和設定很少變動，使用 AWS Systems Manager Parameter Store SecureString。
我可以在 Amazon S3 SSE-KMS 或 Amazon EBS 加密中使用非對稱 AWS KMS key 嗎？
不行。Amazon S3 SSE-KMS、Amazon EBS 加密、Amazon RDS 加密、AWS Secrets Manager 和 AWS Systems Manager Parameter Store SecureString 等 AWS 服務整合，都需要金鑰規格為 SYMMETRIC_DEFAULT 的對稱 AWS KMS key。非對稱 AWS KMS key（RSA、ECC）保留給應用程式層的簽章/驗證，或加密方不能擁有私鑰的加密/解密場景。
為什麼我的 rotation Lambda 出現逾時失敗？
兩個根本原因最為常見。第一，rotation Lambda 必須在與目標資料庫相同的 Amazon VPC 內執行（或透過 VPC peering、AWS Transit Gateway 或 VPC endpoint 有路由可達），並使用允許連線到資料庫通訊埠的 security group。第二，rotation Lambda 的執行角色必須具備 secretsmanager:UpdateSecretVersionStage、secretsmanager:DescribeSecret、secretsmanager:GetSecretValue、secretsmanager:PutSecretValue，以及對加密機密的 AWS KMS key 的 kms:Decrypt 和 kms:GenerateDataKey。設定 Amazon CloudWatch 對 RotationFailed 指標的警報，讓失敗立即浮現。
我可以在使用匯入金鑰材料的 AWS KMS key 上啟用自動輪換嗎？
不行。**匯入金鑰材料（BYOK）**不支援 AWS KMS 自動輪換。輪換 BYOK 金鑰的方式：(a) 將全新金鑰材料匯入到新的 AWS KMS key 並更新 alias，或 (b) 重新匯入相同材料以將到期時間延長最多再 384 天（有時稱為「rewrapping」）。自動輪換僅適用於 Origin = AWS_KMS 的客戶受管對稱 AWS KMS key。
如何授予跨帳號存取 AWS KMS key？
需要兩個條件同時滿足。第一，擁有帳號中的 AWS KMS key policy 必須明確允許外部帳號主體（或外部帳號的 root）呼叫所需的 AWS KMS 操作——沒有這個，什麼都不能運作。第二，消費帳號中的 identity-based policy 必須授予相同的 AWS KMS 操作對應到 AWS KMS key ARN。兩者都必須允許該操作；任何一方的沉默等同於拒絕。AWS 受管 AWS KMS key（aws/s3、aws/ebs 等）不能跨帳號共享，因為它們的 key policy 是固定的——改用客戶受管 AWS KMS key。
AWSCURRENT、AWSPENDING 和 AWSPREVIOUS 有什麼區別？
AWS Secrets Manager 在輪換期間為每個機密版本附加暫存標籤。AWSCURRENT 標記應用程式在不指定版本時呼叫 GetSecretValue 所取用的版本。AWSPENDING 標記由 rotation Lambda 的 createSecret 步驟建立但尚未啟用的新版本；Lambda 的 setSecret 和 testSecret 步驟負責驗證它。AWSPREVIOUS 標記最近一次輪換前的 AWSCURRENT 版本；在短暫窗口內仍可取用，讓有快取連線的應用程式能完成工作。輪換完成後，標籤以原子方式移動：舊的 AWSCURRENT 變成 AWSPREVIOUS，AWSPENDING 成為新的 AWSCURRENT。
什麼時候應該使用 AWS CloudHSM 而非 AWS KMS？
選擇 AWS CloudHSM 的時機：(a) 法規要求單租戶 FIPS 140-2 Level 3 硬體，沒有共享的多租戶邊界；(b) 地端應用程式需要 AWS KMS 不提供的標準 PKCS #11、JCE 或 Microsoft CNG API；(c) 你必須執行 AWS KMS 不支援的加密操作（老式 3DES、某些自訂曲線）。其他所有情況，AWS KMS 全受管、費用較低，且與每個 AWS 服務整合。你也可以將 AWS CloudHSM 叢集連結為 AWS KMS 自訂金鑰存放區，以獲得 AWS KMS API 介面搭配單租戶金鑰材料。
Multi-Region Key 可以用於跨 Region Amazon S3 SSE-KMS 複寫嗎？
可以——而且這是建議的模式。使用 Multi-Region Key（MRK） 時，us-east-1 的主要金鑰和 eu-west-1 的副本共享相同的 key ID 和金鑰材料，因此以主要金鑰加密的 Amazon S3 物件可以複寫到目的地 bucket，並在那裡以副本解密，無需重新加密。若不使用 MRK，Amazon S3 必須呼叫 kms:ReEncrypt 將密文從來源 Region 的 AWS KMS key 轉換為目的地 Region 的 AWS KMS key，這會增加延遲和費用。
總結
AWS 機密、憑證與金鑰管理——Domain 5 Task 5.4——將三個協同運作的 AWS 服務整合在一起：AWS Secrets Manager（輪換、原生資料庫整合、跨 Region 複寫）、AWS Systems Manager Parameter Store（可選 SecureString 加密的階層式設定），以及 AWS KMS（包裹一切的加密骨幹，涵蓋對稱 vs 非對稱金鑰規格、自動 vs 手動輪換、BYOK 匯入材料、key policy、grants 和 Multi-Region Key）。掌握 rotation Lambda 的失敗模式、雙重政策的跨帳號 AWS KMS 模式、BYOK 生命週期，以及 AWS 服務整合對對稱金鑰的要求，AWS 機密、憑證與金鑰管理就會成為 SCS-C02 考試的高信心區域。