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、ロール、ポリシー、クロスアカウントアクセス

IDおよびアクセス管理は、最小権限、一時的な認証情報、そしてサービスIDとヒューマンIDの明確な分離を基本に設計する必要があります。EC2、ECS、またはLambdaで実行されるアプリケーションには、アクセスキーを埋め込む代わりに、インスタンス/タスク/関数ロールを使用することを推奨します。AWS SDKは、環境から提供される認証情報プロバイダーチェーンを自動的に使用し、一時的な認証情報を更新します。クロスアカウントアクセスには、AWS STS AssumeRole (API: sts:AssumeRole) を使用し、ターゲットアカウントに明示的なロール信頼ポリシーを、呼び出し元アカウントには引き受け可能なロールARNを制限するIAMポリシーを設定する必要があります。機密性の高い操作にMFAを要求する場合は、ロールまたはリソースポリシーの条件で aws:MultiFactorAuthPresent を使用して強制するか、ヒューマンユーザーに sts:GetSessionToken を要求します。Webまたはモバイルクライアントには、Cognito Identityまたはフェデレーションプロバイダーを介して AssumeRoleWithWebIdentity (sts:AssumeRoleWithWebIdentity) を使用し、長期的な認証情報を避けます。よくある落とし穴に注意してください：過度に許可的なワイルドカードアクション/リソース、プリンシパルの条件が一致しないリソースベースのポリシーへの依存、クロスアカウントでのS3またはKMSアクセスに対する SourceAccount や aws:SourceVpc 条件の付け忘れなどです。デバッグには、IAMポリシーシミュレーターと sts:GetCallerIdentity を使用します。組織レベルでサービスコントロールポリシー (SCP) を使用してガードレールを適用し、kms:CreateGrant や iam:CreateAccessKey のようなリスクの高いアクションを必要に応じて明示的に拒否することを検討してください。

KMS、暗号化パターン、キーアクセスコントロール

エンベロープ暗号化にはAWS KMSを使用します。GenerateDataKey/GenerateDataKeyWithoutPlaintext でクライアントサイドまたはサーバーサイド暗号化用のデータキーを生成し、その後、小さなペイロードには Encrypt/Decrypt を呼び出すか、一括暗号化にはそのデータキーを使用します。適切なCMKを選択します。利便性のためのAWS所有キー、サービス統合のためのAWSマネージドキー (aws/*)、または完全な制御とローテーションのためのカスタマーマネージドキーがあります。キーポリシーはKMSの主要な制御手段です。kms:Decrypt、kms:Encrypt を許可するIAMポリシーをアタッチし、CloudHSMバックアップ操作やクロスアカウントでのLambda呼び出しのようなサービスで一時的にキーの使用を委任する必要がある場合は、グラントを使用します。暗号文を使用コンテキストに紐付けるために 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) は多くのパラメータで無料利用枠があり、単純な設定に適しています。アクセスは、secretsmanager:GetSecretValue または ssm:GetParameter (WithDecryption=true付き) を許可するIAMポリシーによって制御され、基盤となるKMSキーはプリンシパルによる復号を許可する必要があります。クロスアカウントのシークレットには、Secrets Managerのリソースベースのポリシーを使用するか、シークレットのレプリケーション機能を使用します。SDKを使用する際は、secretsmanager.getSecretValue({ SecretId }) または ssm.getParameter({ Name, WithDecryption: true }) を呼び出し、シークレット値をログに出力しないようにします。Lambdaの環境変数には、CloudFormationやSAMで動的に解決されるSecrets ManagerやParameter Storeへの参照を設定するか、起動時にSDKで取得します。開発者が犯しがちな間違いには、シークレットをソース管理に平文で保存すること、非常に機密性の高いデータをKMSで保護せずにLambdaの環境変数に依存すること、広範なロールに secretsmanager:* のような過度に許可的なIAMポリシーを付与することなどがあります。ローテーションについては、ローテーション用のLambdaが正しい secretsmanager:RotateSecret と kms:GenerateDataKey 権限を持っていること、そして認証情報が変更されたときにアプリケーションコードがシームレスに接続を再初期化できることを確認してください。

Cognitoの認証、認可、API統合

Amazon Cognitoは、認証用のユーザープールと、一時的なAWS認証情報用のIDプールを提供します。Cognitoユーザープールを使用して、サインアップ、多要素認証、JWT（ID、アクセス、リフレッシュトークン）の発行を管理します。ブラウザベースのシングルページアプリでは、クライアントシークレットなしのアプリクライアントを使用し、パスワードの漏洩を避けるために、ホストされたUIまたはSRPフローを実装したAmazon Cognito SDK (amazon-cognito-identity-js) を使用する必要があります。サーバーまたはAPI GatewayでJWTを検証するには、ユーザープールからJWKS URIを取得し、署名、発行者（issuer）、オーディエンス（aud）、トークンの有効期限を検証します。API GatewayのJWTオーソライザーまたはLambdaカスタムオーソライザーがこの検証を実行できます。サーバー間の認証では、Cognito IDプールを介してユーザープールトークンを一時的な認証情報に交換し、sts:AssumeRoleWithWebIdentityを使用します。よくある落とし穴には、コールバックURLやサインアウトURLの設定ミス、トークンのスコープやグループの未検証、IDトークンがAWS API呼び出しに直接使用できるという誤解（IDプールを介して交換する必要があります）などがあります。きめ細やかな認可には、グループやカスタムクレームを使用し、IDをAWSロールにマッピングする際に、Cognitoをリソースベースのポリシーやaws:userid、cognito-identity.amazonaws.com:subなどのIAM条件キーと組み合わせます。CloudTrailを介してサインインや管理アクションを監査し、Cognitoの高度なセキュリティ機能を有効にして、侵害された認証情報を検出します。

実践的な問題: ユースケースシナリオ

シナリオ: ゲームスタジオであるPixelForgeは、単一のAWSアカウントで、Lambda、API Gateway、S3、DynamoDB、Cognitoユーザープールを使用してサーバーレスバックエンドを運用しています。複数のデプロイステージ用の機密APIキーとデータベース認証情報が保存されており、サードパーティの監査チームが本番環境の画像サブセットに1〜24時間アクセスする必要があります。

課題: 外部の監査員に対して、本番環境の画像への短期的な監査可能なアクセスを安全に提供し、アプリケーションのシークレットがローテーションされ、Lambdaによって安全にアクセスされることを保証し、管理者によるクロスアカウントアクセスにMFAを強制すること。

推奨アプローチ:

PixelForgeアカウントによる復号を許可するキーポリシーと、監査員IAMロールへのグラントを持つカスタマーマネージドKMSキーを作成します。キーのローテーションを有効にし、復号操作中にEncryptionContextを要求します。
Secrets Managerに認証情報（ステージごとに個別のシークレット）を保存し、最小限のsecretsmanager:GetSecretValue権限とKMSキーに対するkms:Decrypt権限を持つIAMロールをLambdaにアタッチします。AWS SDKを使用して

undefined

を呼び出すLambdaの起動コードを実装します。 3. 監査員のアクセス用に、別の監査員AWSアカウントロールを作成し、リソースベースのS3バケットポリシーで監査員アカウントからのsts:AssumeRoleを許可します。このポリシーはaws:PrincipalArnと時間制限のある事前設定されたロールマッピングによって制限します。sts:AssumeRoleを介して短期的な認証情報を生成し、ロールを引き受ける際にaws:MultiFactorAuthPresent条件でMFAを強制します。 4. CloudTrailですべてのアクセス（S3とKMSの管理イベントおよびデータイベント）をログに記録し、追加のフォレンジックのためにS3オブジェクトレベルのロギングとAmazon MacieまたはS3アクセスログを有効にします。一時的な監査員セッションでは特定のEncryptionContextを使用し、追跡可能性のためにオブジェクト/リクエストにタグを付けることを要求します。

論理的根拠: Secrets ManagerをKMSおよび短期的なSTS認証情報と組み合わせて使用することで、最小権限の原則を徹底し、自動ローテーションを可能にし、シークレットの埋め込みを回避します。MFAとCloudTrailデータイベントを伴う時間制限付きのassume-roleパターンは、職務の分離を維持しつつ、サードパーティに対して監査可能で取り消し可能なアクセスを提供します。

← デプロイと CI · すべてのドメイン · モニタリング、ロギングとデバッグ (CloudWatch →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →