DVA-C02 D2 セキュリティ 徹底解説（2025年最新）｜Cognito認証・KMS暗号化・最小権限

1. はじめに — D2「セキュリティ」とは

本記事はAWS DVA-C02（Developer – Associate）試験対策シリーズの Vol2 です。
シリーズ全体の学習ロードマップは Vol0 ロードマップ をご確認ください。

DVA-C02試験の第2ドメイン「D2 Security」は、試験全体の 26% を占める重要領域です。
CertTrend LMSでは本ドメインの演習問題を102問収録しています。
D2は開発者としてアプリケーションを安全に設計・実装するための知識を問うドメインであり、認証・認可・暗号化・シークレット管理 の4つの柱を軸に出題されます。

1-1. D2の出題傾向

D2では「どのサービスを選ぶか」よりも「なぜそのサービスを選ぶか」という判断力が問われます。
たとえば「APIキーをどこで管理するか」という問いに対し、Secrets Manager・Parameter Store・環境変数のいずれが適切かを、自動ローテーション要否・コスト・クロスアカウント要否 などの条件から判断する必要があります。
単純な機能暗記ではなく、要件に応じたサービス選択の論理を身につけることが合格の鍵です。

2. Cognitoによる認証（User Pools vs Identity Pools）

2-1. Amazon Cognito の全体像

Amazon Cognitoは、ユーザー認証（Authentication）と AWS リソースへの認可（Authorization） を提供するマネージドサービスです。
2つのコアコンポーネントがあり、混同しないことが試験の最重要ポイントです。

2-2. User Pools — ユーザー認証と管理

User Poolsは ユーザーディレクトリ として機能し、アプリケーションへのサインアップ・サインインを管理します。

主な機能：

• ユーザーの登録・ログイン・パスワードリセット
• MFA（多要素認証）：TOTP/SMS対応
• Eメール・電話番号の検証
• ユーザー属性の管理（email, phone_number, custom属性等）
• ホステッドUI：Cognitoがホストするサインインページのカスタマイズ
• Lambda トリガー：認証フローの各フェーズをカスタマイズ（Pre-signup, Post-confirmation等）
• ソーシャルIDプロバイダー連携（Google, Facebook, OIDC/SAML準拠IdP）

サインイン成功後、User PoolsはJWTトークン（IDトークン・アクセストークン・リフレッシュトークン）を返します。
このJWTを後続のAPIやリソースへのアクセス制御に活用します。

Lambda トリガーの頻出パターン：

DVA-C02では、Lambda トリガーを使ったカスタム認証フローが出題されます。
代表的なユースケースは「既存の認証システムをCognito User Poolsのバックエンドとして利用する」ケースで、Define Auth Challenge / Create Auth Challenge / Verify Auth Challenge Responseの3トリガーを組み合わせて実装します。

2-3. Identity Pools — 一時的AWS認可

Identity Poolsは、認証済みユーザーや未認証ゲストに対し、AWS リソースへの一時的なアクセス権限（STS認証情報） を付与します。

Identity Poolsの処理フロー：

1. ユーザーがUser Pools（またはGoogle/Facebook等）でサインインし、トークンを取得
2. Identity Poolsがそのトークンを受け取り、STS AssumeRoleWithWebIdentity を呼び出す
3. STSが一時的なIAM認証情報（Access Key ID / Secret Access Key / Session Token）を返す
4. アプリがその認証情報でAWSサービス（S3, DynamoDB等）に直接アクセス

認証済みvs未認証の使い分け：

Identity Poolsは 認証済み（Authenticated） と 未認証（Unauthenticated / Guest） の2つのIAMロールを設定できます。
ゲストユーザーにも限定的なAWSリソースへのアクセスを許可するユースケースで活用されます。

3. ID連携の仕組み（SAML/OIDC/JWT/OAuth/STS）

3-1. SAML 2.0

SAML（Security Assertion Markup Language）は、エンタープライズのオンプレ環境（Active Directory等）とAWSを連携 するための業界標準プロトコルです。

• フロー：IdP（Active Directory Federation Services等）がSAMLアサーション（XML形式）を発行 → STSの AssumeRoleWithSAML を呼び出し一時認証情報を取得
• 使いどころ：社内の既存IdPをそのままAWSのID連携に使いたい場合
• 設定：IAMにIDプロバイダー（SAML）を登録し、信頼関係にIdPのエンティティIDを指定

3-2. OIDC（OpenID Connect）

OIDCはOAuth 2.0を拡張した 認証プロトコル で、Cognito以外のOIDC準拠IdP（GitHub Actions, Google等）とAWSを連携するために使います。

• フロー：OIDCプロバイダーがIDトークン（JWT）を発行 → STSの AssumeRoleWithWebIdentity を呼び出し一時認証情報を取得
• DevOps用途：GitHub Actions OIDCを使うことで、GitHubからAWSへのアクセス時にシークレットキー不要のフェデレーションが実現
• 設定：IAMにIDプロバイダー（OIDC）を登録し、Provider URL とClient IDを指定

3-3. JWT（JSON Web Token）

JWTは3つのパートをBase64URLエンコードしてドット（.）で繋いだトークン形式です。

{ヘッダー}.{ペイロード}.{署名}

• ヘッダー：アルゴリズム（RS256等）とタイプ（JWT）を含む
• ペイロード：クレーム（sub, iss, exp, aud等のユーザー情報）を含む
• 署名：秘密鍵またはRSA秘密鍵でヘッダー＋ペイロードに署名したもの

JWTの検証は公開鍵で行われます。Cognito User Poolsはトークン検証用のJWKS（JSON Web Key Set）エンドポイントを公開しており、Lambda等で署名検証が可能です。

3-4. OAuth 2.0

OAuth 2.0は 認可（Authorization）フレームワーク です。
「認証」ではなく「あるアプリが別のサービスのリソースにアクセスすることを認可する」仕組みです。
OIDCはOAuth 2.0の認可フローの上に「認証」レイヤーを追加したものです。

DVA-C02で重要なOAuth 2.0フロー：

• Authorization Code Flow：サーバーサイドアプリで使用。認可コードをバックエンドでトークンに交換（最も安全）
• Authorization Code Flow with PKCE：モバイル/SPAで使用。シークレット不要でコードインターセプト攻撃を防ぐ
• Implicit Flow：非推奨。フロントエンドに直接トークンを返す（セキュリティリスクあり）
• Client Credentials Flow：機械間（M2M）通信で使用。ユーザーなしでクライアントが認証

3-5. STS（Security Token Service）

STSは 一時的なAWS認証情報 を生成するサービスです。

一時認証情報にはデフォルトで有効期限（最長12時間）があり、長期的な認証情報より安全です。

4. Bearerトークンの種類と用途

Bearerトークンは「所持者がアクセスを得られる」仕組みで、HTTP Authorizationヘッダーに Bearer <token> の形式で渡します。
Cognito User Poolsが発行する3種類のトークンを理解することが重要です。

試験頻出ポイント：

• API Gatewayとの連携：API GatewayのCognitoオーソライザーは IDトークン または アクセストークン を検証します。Lambda オーソライザー（カスタム）と混同しないよう注意してください。
• リフレッシュトークンの無効化：ユーザーをサインアウトさせる際は GlobalSignOut または RevokeToken APIを呼び出し、リフレッシュトークンを無効化します。

5. IAMポリシーと最小権限（managed vs customer・RBAC）

5-1. IAMポリシーの種類

IAMポリシーは JSON形式のアクセス制御文書 で、3種類があります。

AWS管理ポリシー（AWS Managed Policy）：
– AWSが作成・管理するポリシー（例: AmazonS3ReadOnlyAccess）
– 定期的にAWSが更新するため、最新のアクションが自動で追加される
– 複数のエンティティに再利用可能
– 欠点：権限が広めに設定されているため、最小権限原則に反する場合がある

カスタマー管理ポリシー（Customer Managed Policy）：
– ユーザーが作成・管理するポリシー
– バージョン管理が可能（最大5バージョン）
– 複数のエンティティに再利用可能
– 最小権限を実現するための推奨方法

インラインポリシー（Inline Policy）：
– IAMエンティティ（ユーザー/グループ/ロール）に直接埋め込まれるポリシー
– エンティティを削除するとポリシーも削除される
– 再利用不可。特定エンティティとの1対1の厳密な関係が必要な場合に使用

5-2. 最小権限の原則

最小権限の原則は「必要最小限の権限のみ付与する」という考え方で、DVA-C02の設計問題で繰り返し問われます。

実践的な実装方法：

• アクション指定：s3:* ではなく s3:GetObject など具体的なアクションを指定
• リソース指定：* ではなく特定のARN（例: arn:aws:s3:::my-bucket/*）を指定
• 条件（Condition）の活用：IP制限・MFA必須・リクエスト元VPCの制限等
• IAM Access Analyzerの活用：未使用の権限を検出し、ポリシーの縮小を提案

5-3. RBAC と ABAC の違い

RBAC（Role-Based Access Control）：
– ロールや職種に基づいてアクセスを制御
– IAMロール・グループを「Developers」「ReadOnlyUsers」等で管理
– ユーザー数の増加に伴いポリシー管理が複雑になる

ABAC（Attribute-Based Access Control）：
– タグ（属性）に基づいてアクセスを制御
– ポリシー内で aws:PrincipalTag や aws:ResourceTag を条件に使用
– 例：aws:PrincipalTag/Team = Development かつ aws:ResourceTag/Team = Development の場合のみアクセス許可
– スケーラビリティが高い：新規ユーザーに適切なタグを付けるだけでポリシー変更不要

DVA-C02では「アカウント内に多数の開発チームがあり、それぞれが自分のリソースのみアクセスできるようにする最も効率的な方法」という問いでABACが正解になるケースが多いです。

6. IAMロールのassume（クロスアカウント・Lambda実行ロール）

6-1. Trust Policy vs Permission Policy

IAMロールには 2種類のポリシー が必要です。

信頼ポリシー（Trust Policy）：
– 「誰がこのロールをAssumeできるか」を定義
– Principal（信頼されるエンティティ）を指定
– STSの AssumeRole を許可するポリシー

{
  "Effect": "Allow",
  "Principal": {
 "AWS": "arn:aws:iam::123456789012:root"
  },
  "Action": "sts:AssumeRole"
}

許可ポリシー（Permission Policy）：
– ロールがAssumeされた後に実行できるAWS APIアクションを定義
– 通常のIAMポリシーと同じ形式

6-2. クロスアカウントアクセス

クロスアカウントアクセスは、アカウントAのユーザーがアカウントBのリソースへアクセスする 場合に使います。

設定手順：

1. アカウントBにIAMロールを作成し、信頼ポリシーでアカウントAのエンティティを指定
2. アカウントAのユーザー/ロールに sts:AssumeRole を許可するポリシーを付与
3. アカウントAのユーザーがSTSの AssumeRole を呼び出し、アカウントBの一時認証情報を取得

ExternalId の重要性（混乱した副次効果/Confused Deputy問題）：

サードパーティのAWSアカウント（SaaS等）にロールをAssumeさせる場合、攻撃者が別の顧客のリソースにアクセスできてしまう「Confused Deputy問題」を防ぐために sts:ExternalId 条件を信頼ポリシーに設定します。

6-3. Lambda実行ロール

Lambda関数には 実行ロール（Execution Role） が必須です。
Lambda関数が他のAWSサービス（CloudWatch Logs, S3, DynamoDB等）にアクセスするための権限を定義します。

デフォルトの権限（AWS Lambda Basic Execution Role）：
– logs:CreateLogGroup
– logs:CreateLogStream
– logs:PutLogEvents

VPC内でLambdaを実行する場合は追加で ec2:CreateNetworkInterface 等のVPC関連権限が必要です。

リソースベースポリシー（Resource-based Policy）：

実行ロールとは別に、Lambda関数自体にもリソースベースポリシーを設定できます。
「誰がこのLambda関数を呼び出せるか」を定義するもので、API GatewayやS3イベントからのトリガー設定時に自動で追加されます。

7. KMSによる暗号化（キーローテーション・envelope暗号化）

7-1. AWS KMS キーの種類

AWS KMS（Key Management Service）は暗号化キーの作成・管理・使用を担うマネージドサービスです。

7-2. キーローテーション

自動キーローテーション（CMK）：

• コンソールまたはCLIで有効化（enable-key-rotation）
• デフォルトのローテーション周期：1年（365日）
• ローテーション後も古いバージョンのキーマテリアルは保持され、既存の暗号化データを復号可能
• キーARNは変わらないため、アプリの変更不要

注意事項：

• インポートしたキーマテリアル（External origin）は自動ローテーション非対応 → 手動ローテーション必要
• 非対称CMK（RSA/ECC）は自動ローテーション非対応
• AWS管理キー（aws/*）は自動的に毎年ローテーション（ユーザーが無効化不可）

7-3. Envelope暗号化

Envelope暗号化は 「データキーをCMKで暗号化する」2層構造 の暗号化方式です。
KMSは大容量データを直接暗号化せず、envelope暗号化で効率的に処理します。

暗号化のフロー：

1. KMS GenerateDataKey APIを呼び出し、プレーンテキストデータキーと暗号化済みデータキーを取得
2. プレーンテキストデータキーでデータをローカル暗号化（AES-256-GCM等）
3. プレーンテキストデータキーをメモリから削除
4. 暗号化済みデータと暗号化済みデータキーを一緒に保存

復号のフロー：

1. KMS Decrypt APIを呼び出し、暗号化済みデータキーからプレーンテキストデータキーを取得
2. プレーンテキストデータキーでデータをローカル復号
3. プレーンテキストデータキーをメモリから削除

envelope暗号化のメリット：

• 大容量データをKMSへ送らずに済む（KMSはデータキーの暗号化のみ担当）
• データキーをアプリでキャッシュすることで、毎回KMSを呼び出さずに済む
• 複数のCMKで同一データキーを暗号化し、マルチリージョンアクセスが可能

8. クライアントサイド vs サーバーサイド暗号化

8-1. S3のサーバーサイド暗号化（SSE）

S3はアップロード時に自動でデータを暗号化するSSEを3種類提供します。

S3バケットのデフォルト暗号化：

バケットレベルでデフォルト暗号化を設定すると、暗号化ヘッダーなしのアップロードにもSSEが適用されます。
S3バケットポリシーで aws:SecureTransport: false の拒否条件を設定し、HTTP（平文）アクセスを禁止することもベストプラクティスです。

SSE-KMS のスロットリング対策：

SSE-KMSを使うS3バケットへのリクエストが大量になると、KMS APIスロットリングの発生を招く場合があります。
対策として S3 Bucket Keyを有効化 すると、バケットレベルのデータキーをキャッシュしKMSのAPI呼出し回数を大幅に削減できます。

8-2. クライアントサイド暗号化

クライアントサイド暗号化は、AWSにデータを送る前にクライアント側でデータを暗号化 する方式です。

• AWS Encryption SDK：envelope暗号化を簡単に実装できるSDK（Java/Python/JavaScript等）
• S3 Encryption Client：S3専用のクライアントサイド暗号化SDK
• キーはKMSまたはローカルで管理
• AWSにプレーンテキストデータが渡らないため、コンプライアンス要件が最も厳しい場合に選択

使い分けの基準：

• サーバーサイド（SSE-KMS）：監査証跡が必要、管理が簡単
• クライアントサイド：AWSを完全に信頼できない規制要件がある場合、E2E暗号化が必要な場合

8-3. DynamoDB の暗号化

DynamoDBのデータは 保存時に自動で暗号化（At-rest encryption） されます。

DynamoDB Encryption Clientを使えば、DynamoDBへの書き込み前にクライアントサイドで属性値を暗号化できます（パーティションキー・ソートキーは除く）。

9. Secrets Manager / Parameter Store の使い分け

9-1. AWS Secrets Manager

Secrets Managerは 機密情報（データベース認証情報・APIキー等）の一元管理と自動ローテーション を提供するサービスです。

主な機能：

• 自動ローテーション：RDS/Aurora/Redshift/DocumentDB等のネイティブ連携で、ローテーションLambdaが自動実行
• クロスアカウントアクセス：シークレットのリソースベースポリシーで別アカウントからのアクセスを許可
• バージョン管理：AWSCURRENT（現在）/ AWSPREVIOUS（直前）/ AWSPENDING（ローテーション中）のステージングラベル
• KMS連携：シークレットの値をCMKで暗号化
• SDK連携：GetSecretValue APIでシークレットを取得

料金：
– $0.40/シークレット/月 + API呼出料金
– 30日間の無料トライアルあり

9-2. Systems Manager Parameter Store

Parameter Storeは 設定値・シークレット・テキストデータの一元管理 サービスで、2種類のパラメータタイプがあります。

• String / StringList：平文の設定値（DBエンドポイント・S3バケット名等）
• SecureString：KMSで暗号化されたシークレット値

Standard vs Advanced Tier：

9-3. 使い分けのポイント

自動ローテーション必要?
├── Yes → Secrets Manager
└── No → 機密性が高い?
 ├── Yes → Parameter Store SecureString（コスト重視）
 └── No → Parameter Store String

試験頻出パターン：

「RDSのパスワードを90日ごとに自動ローテーションしたい」→ Secrets Manager
「Lambda間で共有するAPIエンドポイントを管理したい」→ Parameter Store String
「Lambdaが使うサードパーティAPIキーを安全に管理したい（ローテーション不要）」→ Parameter Store SecureString

10. 機微データのサニタイズ

10-1. 入力バリデーション

アプリケーションセキュリティの基本は 入力値の検証とサニタイズ です。

API GatewayのリクエストバリデーションとLambdaの組み合わせ：

• API GatewayでJSONスキーマによるリクエストバリデーションを設定（クエリパラメータ・ヘッダー・リクエストボディ）
• バリデーション失敗時は400エラーを返し、Lambdaの呼び出しをスキップ
• SQLインジェクションやXSSの入力をLambdaが受け取る前にブロック

DynamoDBでのSQLインジェクション対策：

DynamoDBはSQLを使わないため、従来のSQLインジェクションは不適用です。
ただし、ExpressionAttributeNamesとExpressionAttributeValuesを使ったパラメータ化クエリ（プレースホルダー）が推奨されます。
直接ユーザー入力をFilter式やCondition式に埋め込まないよう注意してください。

10-2. PIIデータの管理

PII（個人識別情報）の管理は規制要件（GDPR/個人情報保護法等）への対応として重要です。

Amazon Macie：

• S3に保存されたデータからPII（氏名・クレジットカード番号・メールアドレス等）を自動検出
• 機械学習と正規表現でデータを分類
• SecurityHub/EventBridgeと連携した自動対応フロー構築が可能

Lambdaでの機微データ取り扱いルール：

• CloudWatch Logsにクレジットカード番号・パスワード等を絶対ログ出力しない
• 環境変数は SSM Parameter Store SecureString または Secrets Manager から取得
• Lambdaレイヤーに認証情報を含むコードを組み込まない

10-3. 転送時の暗号化

• TLS（HTTPS）の強制：S3バケットポリシー、API Gatewayのカスタムドメイン設定、ALBのHTTPS リダイレクト
• VPCエンドポイント：S3/DynamoDB等へのアクセスをインターネットを経由せずVPC内で完結

11. CertTrend LMS で400問チェック

D2セキュリティの理解を深めたら、CertTrend LMSで実践問題を演習しましょう。
Cognito・KMS・IAM・Secrets Managerを含むDVA-C02の全ドメインを網羅した400問の演習問題で試験合格力を高めることができます。

12. 実務で深掘り — セキュリティ本番運用記事

試験合格後、実際のAWS開発でD2の知識を活かすための本番運用記事を紹介します。

Lambda オーソライザーによるAPIセキュリティの実装：

IAM Access Analyzer・KMS・Secrets Managerのエンタープライズ設計：

DVA-C02 試験対策シリーズ全体像：