Amazon DVA-C02: 安全性、IAM、KMS 與機密管理 (Cognito, Secrets Manager, SSM) — 學習指南

By Laurynas Brazys · 28 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

屬於 AWS Developer Associate DVA-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

IAM、角色、政策與跨帳戶存取

身分與存取管理的設計應圍繞著最小權限、短期憑證，以及服務身分與人類使用者身分之間的明確區隔。對於在 EC2、ECS 或 Lambda 上執行的應用程式，應優先使用執行個體/任務/函數角色，而非嵌入存取金鑰；AWS SDK 會自動使用環境提供的憑證提供者鏈並更新臨時憑證。跨帳戶存取應使用 AWS STS AssumeRole (API: sts:AssumeRole)，在目標帳戶中設定明確的角色信任政策，並在呼叫者帳戶中設定 IAM 政策以限制可擔任的角色 ARN。當敏感操作需要 MFA 時，應在角色或資源政策中使用 aws:MultiFactorAuthPresent 條件來強制執行，或要求人類使用者使用 sts:GetSessionToken。對於網頁或行動用戶端，應透過 Cognito Identity 或聯合身分供應商使用 AssumeRoleWithWebIdentity (sts:AssumeRoleWithWebIdentity)，以避免使用長期憑證。注意常見的陷阱：過於寬鬆的萬用字元動作/資源、依賴資源型政策卻沒有匹配的主體條件，以及在跨帳戶存取 S3 或 KMS 時忘記包含 SourceAccount 或 aws:SourceVpc 條件。使用 IAM 政策模擬器和 sts:GetCallerIdentity 進行偵錯。可考慮在組織層級使用服務控制政策 (SCPs) 來強制實施防護機制，並在適當時對 kms:CreateGrant 或 iam:CreateAccessKey 等高風險動作進行明確拒絕。

KMS、加密模式與金鑰存取控制

使用 AWS KMS 進行信封加密：呼叫 GenerateDataKey/GenerateDataKeyWithoutPlaintext 來產生用於用戶端或伺服器端加密的資料金鑰，然後對小量酬載呼叫 Encrypt/Decrypt，或使用該資料金鑰進行大量加密。選擇正確的 CMK：為求方便可選用 AWS 擁有的金鑰，為整合服務可選用 AWS 管理的金鑰 (aws/*)，或為求完整控制與輪換可選用客戶管理的金鑰。金鑰政策是 KMS 的主要控制機制；附加允許 kms:Decrypt、kms:Encrypt 的 IAM 政策，並在需要臨時、委派的金鑰使用權限時（例如用於 CloudHSM 支援的操作或跨帳戶 Lambda 叫用）使用授權 (grants)。包含一個 EncryptionContext 以將密文與使用情境綁定，並透過 kms:EncryptionContextEquals 條件要求此項，以獲得更高的保證。跨帳戶使用 KMS 需要在金鑰政策中明確授予外部主體或角色的條目，在某些情況下還需要 CreateGrant/RetireGrant 權限。為了稽核與鑑識，應為 KMS 和 S3 啟用 CloudTrail 資料事件，以捕獲 GenerateDataKey 和 Decrypt 的呼叫；CloudTrail 日誌將包含 arn:aws:kms 以及關於哪個主體使用了金鑰的詳細資訊。常見的疏漏包括：忘記為在幕後使用授權的服務允許 kms:CreateGrant、未能輪換客戶管理的金鑰，以及假設僅靠 IAM 政策就能授權 KMS 操作而沒有適當的金鑰政策條目。

秘密管理：Secrets Manager vs Parameter Store

Secrets Manager 和 Systems Manager Parameter Store 都提供加密的秘密儲存，但在功能和成本結構上有所不同：Secrets Manager 支援自動輪換（使用 Lambda 輪換範本）、內建版本控制和整合式複寫，並按秘密數量計費；Parameter Store (SecureString) 對於許多參數都在免費方案範圍內，且更適合簡單的組態設定。存取權限由 IAM 政策控制，授予 secretsmanager:GetSecretValue 或 ssm:GetParameter (搭配 WithDecryption=true)，且底層的 KMS 金鑰必須允許該主體進行解密。對於跨帳戶的秘密，可在 Secrets Manager 上使用資源型政策，或使用秘密複寫功能進行複寫。使用 SDK 時，呼叫 secretsmanager.getSecretValue({ SecretId }) 或 ssm.getParameter({ Name, WithDecryption: true })，並避免記錄秘密值；設定 Lambda 環境變數以使用指向 Secrets Manager 或 Parameter Store 的參考，並在 CloudFormation 或 SAM 中進行動態解析，或在應用程式啟動時透過 SDK 擷取。開發人員常見的錯誤包括：將秘密以明文形式儲存在原始碼控制中、在沒有 KMS 保護的情況下依賴 Lambda 環境變數來儲存高度敏感的資料，以及設定過於寬鬆的 IAM 政策，例如將 secretsmanager:* 授予廣泛的角色。為了進行輪換，請確保輪換用的 Lambda 具有正確的 secretsmanager:RotateSecret 和 kms:GenerateDataKey 權限，並確保應用程式程式碼能在憑證變更時無縫地重新初始化連線。

Cognito 驗證、授權與 API 整合

Amazon Cognito 提供用於驗證的「使用者集區」(user pools) 和用於取得暫時性 AWS 憑證的「身分集區」(identity pools)。使用 Cognito User Pools 來管理註冊、多重要素驗證和 JWT (ID、存取、更新權杖) 的簽發。瀏覽器端的單頁應用程式必須使用沒有用戶端私密金鑰的應用程式用戶端，並且應使用託管 UI 或實作 SRP 流程的 Amazon Cognito SDK (amazon-cognito-identity-js)，以避免洩漏密碼。在伺服器或 API Gateway 上驗證 JWT 時，需從使用者集區取得 JWKS URI，並驗證其簽章、簽發者、受眾 (aud) 和權杖到期時間；API Gateway JWT 授權方或 Lambda 自訂授權方可以執行此驗證。對於伺服器對伺服器的驗證，可透過 Cognito Identity Pool 使用 sts:AssumeRoleWithWebIdentity 將使用者集區權杖交換為暫時性憑證。常見的陷阱包括設定錯誤的回呼或登出 URL、未驗證權杖的範圍或群組，以及期望 ID 權杖能直接用於 AWS API 呼叫 (您必須透過身分集區交換它們)。若要進行細微度的授權，請使用群組或自訂宣告，並在將身分對應至 AWS 角色時，將 Cognito 與資源型政策及 IAM 條件金鑰 (例如 aws:userid 或 cognito-identity.amazonaws.com:sub) 結合使用。透過 CloudTrail 稽核登入和管理員動作，並在 Cognito 中啟用進階安全功能以偵測受損憑證。

實務問題：使用案例情境

情境：遊戲工作室 PixelForge 在單一 AWS 帳戶中運行一個無伺服器後端，其中包含 Lambda、API Gateway、S3、DynamoDB 和 Cognito 使用者集區。敏感的 API 金鑰和資料庫憑證為多個部署階段而儲存，且一個第三方稽核團隊必須在 1-24 小時內存取 S3 中生產環境映像檔的子集。

挑戰：為外部稽核員安全地提供對生產環境映像檔的短期、可稽核的存取權限，確保應用程式的私密金鑰被輪換並由 Lambda 安全地存取，以及對管理員的跨帳戶存取強制執行 MFA。

建議方法：

建立一個客戶管理的 KMS 金鑰，其金鑰政策允許 PixelForge 帳戶進行解密，並為稽核員 IAM 角色提供授權；啟用金鑰輪換，並在解密操作期間要求使用 EncryptionContext。
將憑證儲存在 Secrets Manager 中 (每個階段使用獨立的私密金鑰)，並將一個 IAM 角色附加到 Lambda 上，該角色僅具有最小的 secretsmanager:GetSecretValue 權限以及對該 KMS 金鑰的 kms:Decrypt 權限；實作 Lambda 啟動程式碼，以使用 AWS SDK 呼叫 secretsmanager.getSecretValue({ SecretId })。
為了讓稽核員存取，建立一個獨立的稽核員 AWS 帳戶角色，並在一個資源型的 S3 儲存貯體政策中允許來自稽核員帳戶的 sts:AssumeRole，此政策受 aws:PrincipalArn 和一個有時間限制、預先設定的角色對應所限制；透過 sts:AssumeRole 產生短期憑證，並在擔任該角色時使用 aws:MultiFactorAuthPresent 條件來強制執行 MFA。
使用 CloudTrail 記錄所有存取 (S3 和 KMS 的管理事件與資料事件)，並啟用 S3 物件層級日誌記錄和 Amazon Macie 或 S3 Access Logs 以進行額外的鑑識；要求暫時的稽核員會話使用特定的 EncryptionContext，並標記物件/請求以確保可追溯性。

基本原理：結合使用 Secrets Manager、KMS 和短期的 STS 憑證，可以強制執行最小權限原則、實現自動化輪換，並避免嵌入私密金鑰。有時間限制的 assume-role 模式搭配 MFA 和 CloudTrail 資料事件，為第三方提供了可稽核、可撤銷的存取權限，同時保持了職責分離。

← 部署與 CI · 所有領域 · 監控、日誌記錄與偵錯 (CloudWatch →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →