AWS Solutions Architect — セキュアなアーキテクチャの設計：練習問題80問

Step 1: 要件整理 — 要件は「セキュリティ（強制ポリシー）、監査ログの集中管理、請求の一元化、環境分離（prod/dev）」であるため、論理分離（タグやIAMのみ）では不十分。AWS Organizationsは複数アカウント管理、OUによる階層構造、SCPによる組織横断のガードレールを提供する。CloudTrailのOrganization Trailを専用ログアカウントに配信すれば、各アカウントのイベントを集中管理・改ざん耐性のあるS3バケットに保管できる。

Step 2: コスト・性能・運用の考慮 — 複数アカウントは初期運用コストと管理オーバーヘッドが増えるが、セキュリティ境界が明確になりインシデント時の被害範囲を限定できる（レジリエンシー向上）。集中ログにより監査・フォレンジック作業が効率化される。SCPは「できることの上限」を定義するので、IAMで誤って強力な権限を付与してもSCPで制限可能。

Step 3: 実装手順と推奨構成 — OrganizationsでOU（例えば /Production, /NonProduction ）を作成、各OUに複数アカウントを作る（prod-app, prod-db, dev-appなど）。ログ専用アカウントを作成し、Organization Trailを作成してそのS3バケットに全てのCloudTrailログを集約。SCPを用いて例えば本番OUでは特定リージョンのみ利用可、RootやIAMの作成制限等のルールを適用する。Trap: よくある誤解は「複数アカウントはコストが高いから単一アカウントでタグ運用すればよい」というもの。単一アカウントは境界が弱く、誤操作や権限昇格時に影響が全環境に及ぶ。なぜ他選択肢が不適切かの解説: 1番（単一アカウント＋タグ）は初期コストや管理面で一見単純だが、権限分離が弱く、Rootや横断的な誤操作で全環境が危険に晒される。IAMだけでは組織横断の強制（例：全アカウントでS3暗号化必須）を確実に適用できない。3番（別アカウントだがSCPを使わない）はアカウント分離の利点を生かし切れない。SCPはコンプライアンスを強制するための重要なガードレールであり、使わないと設定ミスでルールが破られるリスクが高い。4番（単一アカウント内のVPC分離）はVPCレベルの分離は有効だが、IAMやRootの権限境界が同じアカウントに残るため、人的ミスやクリデンシャル漏洩時に全環境が危険に晒される。総合的に、Organizations＋OU＋SCP＋集中ログの組合せが、セキュリティ、監査、運用効率、コスト（長期的なリスク低減を含む）のバランスで最も適切である。

Step 1: 監査要件の把握 ログの改ざん防止、可用性、アクセス制御、監査証跡の保全が求められます。中央集約されたログアカウントは改ざん耐性と単一の監査ポイントを提供します。CloudTrailのS3配信先とKMSキーは監査基盤の核心です。

Step 2: 暗号化とガードレールの実装 S3バケットとCloudTrailログにはSSE-KMSを利用し、専用のCMKを作成してキー ポリシーで中央監査アカウントのコントロールを維持します。CloudTrail自体もSSE-KMSを使って暗号化でき、KMSの利用ログをCloudTrailで追跡することで相互監査が可能です。さらに、OrganizationsのSCPでCloudTrailの停止やS3バケットの削除、KMSキーの削除といった破壊的操作を禁止するポリシーをOUレベルで適用して基盤を守ります。

Step 3: 運用・監査フローと最小権限 ログアカウントへのアクセスは最小権限で制限し、クロスアカウントロールを通じて読み取り専用のダッシュボードアクセスを許可します。キーのローテーション、アクセスレビュー、定期的な復旧テストを運用プロセスとして組み込みます。 Trap: よくある誤解 「AWS管理キーで十分」という考えは短期的には簡便ですが、専用CMKを使えばキーアクセスの詳細な制御、グラント管理、ローテーションポリシー、削除ガード（削除保護）などガバナンス機能を活用でき、監査要件を満たしやすくなります。 Why each wrong answer fails: 1. 専用ログアカウントにCloudTrailを配信、S3とCloudTrailに専用CMKでSSE-KMSを適用する（正解）— 理由: ログの集中化と暗号化、KMSによるアクセス制御と監査が可能。改ざん耐性と追跡を確保できる。 2. 各アカウントでCloudTrailを個別に管理し中央集約しない（不正解）— 理由: ログの改ざんリスク、検索／相関分析の手間、監査要求対応のばらつきが発生し、エンタープライズ監査基盤として不適切。 3. OrganizationsのSCPでログ配信停止やS3/KMSの破壊操作を禁止する（正解）— 理由: SCPを事前に仕掛けることで基盤を保護し、意図的または誤操作でのログ破壊を防げる。ガードレールとして有効。 4. AWS管理キーを使えば十分（不正解）— 理由: AWS管理キーは運用負担が少ないが、専用CMKのような詳細なアクセス制御・監査・削除制御ができない。機密ログやコンプライアンスログには専用CMKが望ましい。 総括: 監査基盤は専用アカウントと専用CMKで暗号化・アクセス制御を行い、SCPで破壊操作を禁止することで高い改ざん耐性とガバナンスを実現します。

Step 1: 要件整理 — EC2上のアプリがS3へ読み書きするための認証・認可方法として、セキュリティ（長期資格情報の排除、最小権限）、運用性（ローテーション不要、短期認証の利用）を重視する。

Step 2: AWSの仕組み適用 — 最も推奨されるパターンはインスタンスプロファイル（EC2に割り当てるIAMロール）で、ロールからは一時的な短期クレデンシャルが自動的に提供される。ロールに付与するポリシーは最小権限の原則に従い、特定バケットやパス、必要なAPI（例：s3:GetObject、s3:PutObject）だけを許可する。

Step 3: トレードオフと運用面 — インスタンスプロファイルは資格情報の手動管理を不要にし、キー漏洩リスクを大幅に下げる。ロールの更新は中央で行えるためポリシー変更や権限付与・剥奪が迅速に行える。唯一の注意点は、ロールの権限を広げすぎる（例：S3フルアクセス）と、万が一インスタンスが侵害された際に被害が拡大する点であるため、最小権限設定が重要。Trap: よくある誤解は「インスタンスIDを使ったS3バケットポリシーで十分」という考えだが、S3バケットポリシーの主な主体はAWSアカウントやIAMプリンシパルであり、インスタンスIDでの厳密なアクセス制御は不十分かつ容易に回避される可能性がある。なぜ他の選択肢が不適切か: 1) EC2に長期のIAMユーザーアクセスキーを配置する方法はキーの漏洩リスクが高く、キーのローテーション・管理が煩雑でありクラウドのベストプラクティスに反する。2) 正解のインスタンスプロファイルは短期的な自動ローテーションされたクレデンシャルを使用し、最小権限ポリシーで必要な操作のみを許可できるためセキュリティと運用性の両立に優れる。3) EC2ロールにS3フルアクセスを付与するのは権限が過剰であり侵害時のリスクが高い。アプリケーション側で制御しても、OSやプロセスの脆弱性で権限が悪用され得るためこの設計は推奨されない。4) S3バケットポリシーでインスタンスIDを基に制御する案は、実務上信頼できるプリンシパル識別方法にならない（S3はプリンシパルに対するポリシー適用を想定しており、インスタンスIDに基づく一貫した制御は実装困難）。加えて、バケットポリシー単体ではアカウント内の権限管理運用やIAMロールの柔軟性を欠く。結論として、EC2インスタンスにインスタンスプロファイルを割り当て、必要最小限のS3権限を付与する方法が最良のバランスを提供する。

Step 1: 要件の分解 要件は「安全に資格情報を保管」「自動ローテーション」「アクセスを最小限に抑える」ことです。運用面ではローテーションの自動化と監査、鍵の管理が重要であり、これらは AWS のマネージドサービスである Secrets Manager と KMS を使うと大幅に簡素化されます。

Step 2: AWS の機能とマッチング • AWS Secrets Manager はシークレットの安全な保管、バージョン管理、自動ローテーション（RDS 等の組み込み統合または Lambda でのカスタムローテーション）を提供します。Secrets Manager はデフォルトで KMS による暗号化を利用し、カスタマー管理型 CMK を指定すれば鍵のローテーションやキーポリシーの制御ができます。 • インスタンスプロファイル（EC2 にアタッチする IAM ロール）を使ってアプリに secretsmanager:GetSecretValue の権限だけを与えることで、API キーや固定の長期資格情報を配布する必要がなく、最小権限の原則を守れます。

Step 3: 実装フローと運用上の利点 1. Secrets Manager に DB 資格情報を保存し、必要に応じてカスタマー管理型 CMK を指定する。 2. EC2 用 IAM ロールを作成し、secretsmanager:GetSecretValue など必要最小限の権限を付与する（条件で SecretId を限定する）。 3. アプリケーションは EC2 の IAM ロール経由で Secrets Manager から資格情報を取得する。ローテーションは Secrets Manager の設定で自動化する。 4. CloudTrail と Secrets Manager の監査ログで誰がいつシークレットを取得したかを追跡する。 Trap: 試験の落とし穴 よくある誤りは「SSM パラメータストア（プレーンテキスト）やユーザーデータに平文で保存すれば簡単」と考えることです。しかし平文は再利用・漏洩リスクが高く、ローテーションや監査の自動化が困難です。また長期の IAM アクセスキーを配布する方法は最小権限、キーの管理・廃止を破るため避けるべきです。 Why each wrong answer fails 1) EC2 のユーザーデータに平文で埋め込む: 初期配布は容易ですが、AMI を再作成する運用負荷、キーローテーションが困難、漏洩リスクが高く監査も不十分です。 3) 長期 IAM ユーザーアクセスキーを配布: 長期資格情報は漏洩や回収の際に重大なリスクがあり、最小権限や一時的認証のベストプラクティスに反します。Secrets Manager + IAM ロールの方が安全です。 4) SSM パラメータストアのプレーンテキスト: SSM には SecureString（KMS 暗号化）オプションがありますが、プレーンテキストは暗号化されずローテーション機能も限定的です。Secrets Manager はローテーションやシークレット特化の機能を提供するため、企業要件により適合します。 まとめ: セキュリティ、監査性、ローテーション、自動化、最小権限の観点から、Secrets Manager とカスタマー管理型 CMK、そして EC2 の IAM ロールによるアクセス制御が最も推奨される実装です。

Step 1: 要件整理 — CI/CDパイプライン（中央アカウント）が多数の対象アカウントへデプロイする必要があり、秘密情報の横流しを避け、アクセスを必要最小限に限定しつつ、監査やローテーションを容易に行いたい。

Step 2: AWSの仕組み適用 — 推奨パターンはターゲット（メンバー）アカウント側に必要最小権限のみを付与したデプロイ用ロールを作成し、ロールの信頼ポリシー（trust policy）に中央CIアカウントのサービスプリンシパル（例：CodeBuild/CodePipelineのロール、あるいはCIツールのIAMロール）を含めてAssumeRoleを許可する。CIはそのロールをAssumeRoleして一時的なクレデンシャルでデプロイ操作を行うため、長期的なアクセスキーを配布する必要がなく、権限の追跡と取り消しがしやすい。

Step 3: トレードオフと運用 — このアプローチはセキュリティ（長期資格情報の排除、アカウント境界の維持）と運用性（ロールを使った権限付与/剥奪、CloudTrailによる監査）が両立できる。一方、各アカウントでのロール作成や管理は初期工数がかかるが、CloudFormation StackSetsやAutomationで標準化すればスケール可能。Trap: よくある誤解は「マスターアカウントの強い権限をそのまま使えば楽」という発想。ルートや過剰権限の利用は単一障害点（single point of compromise）を作るため避けるべき。なぜ他の選択肢が不適切か: 1) 各アカウントにIAMユーザーを作り中央に長期キーを配布する方式は、キー管理とローテーションが煩雑で、キー漏洩時の影響範囲が大きくなり、最小権限原則にも反する。2) 正解のAssumeRoleパターンは短期クレデンシャルを使い、ロールポリシーでデプロイに必要な最小操作だけを許可できるため安全かつ監査しやすい。3) 中央アカウントで管理者権限のロールを作ってCIに与える設計は過剰権限で危険。万一CIが侵害されると全アカウントに対して深刻な影響を与える。管理者権限は原則として最小限に留めるべきである。4) マスターアカウントのルート資格情報をCI/CDで使用するのは最も危険であり、AWSベストプラクティスでも厳禁とされている。ルート資格情報は手動で保管し、日常的な運用で使うべきではない。総合的に見て、各メンバーアカウントに限定的なデプロイロールを作成し、中央CIがAssumeRoleする設計が最小権限・監査性・運用性の面で最適である。

Step 1: 要求の理解と制約 S3 オブジェクトは SSE-KMS（KMS によるサーバーサイド暗号化）で保護されており、別アカウントのパイプラインが復号して読み取る必要があります。重要なのは最小権限と安全性（キーの濫用防止、監査）です。KMS はキーポリシーと IAM ポリシーの両方を考慮する必要がある点がポイントです。

Step 2: 適切な AWS 構成 • KMS は「キーポリシー」が最初のアクセス制御レイヤです。キーポリシーでプリンシパル（IAM ユーザー/ロール）を許可しないと、IAM 側の許可だけではアクセスできないケースが発生します。そのため、S3 所有アカウントで作成した CMK のキーポリシーに別アカウントの処理用 IAM ロールを明示的に許可する必要があります。 • 一方、別アカウント側でも対象ロールに対して最小限の IAM ポリシー（kms:Decrypt など）を付与しておく必要があります。両側の設定が揃うことで、初めて復号が許可されるというのが KMS の設計思想です。

Step 3: 実装の流れ（ステップ） 1. S3 所有アカウントで CMK を作成し、キーポリシーに別アカウントの処理用ロールの ARN を Principal として許可する。 2. 別アカウントでそのロールに対して最小限の IAM 権限（kms:Decrypt、必要なら kms:GenerateDataKey、および S3 の読み取り権限）をアタッチする。 3. S3 バケットポリシーも適切に設定し、別アカウントのロールがオブジェクトを取得できるようにする（ただしバケットポリシーだけでは KMS 復号を許可しない）。 4. CloudTrail と KMS のログでアクセスを監査する。 Trap: 試験の落とし穴 受験者が陥りやすい誤解は「S3 バケットポリシーだけ設定すれば復号もできる」「aws/s3（AWS 管理型キー）を使えばクロスアカウントが自動的に可能になる」と考えることです。特に KMS はキーポリシーが重要であり、それを適切に設定しないと IAM 側の許可が無効になります。 Why each wrong answer fails 1) S3 バケットポリシーだけ: バケットポリシーはオブジェクトの GET/PUT に関する S3 レベルの許可に有効ですが、SSE-KMS されたオブジェクトの復号には KMS の許可（キーポリシーと IAM ポリシー）が必要です。したがってバケットポリシーだけでは不十分です。 3) AWS 管理型キー（aws/s3）: AWS 管理型キーは AWS が管理するため、カスタマイズやキーポリシーの編集が制限されます。クロスアカウントでの細かいアクセス許可が必要な場合には適していません。加えて必ずしも自動的にクロスアカウント復号を許すわけではありません。 4) 別アカウントに新しい KMS キーを作成して再暗号化: 再暗号化作業はデータ移動や運用負荷を増やし、無駄なコストと複雑さを招きます。S3 オブジェクトを一旦ダウンロードして再暗号化する手順はセキュリティリスクを高め、最小権限の原則にも反します。 まとめ: 最小権限かつ安全にクロスアカウント復号を実現するには、S3 側と KMS 側の両方を正しく設定する必要がある。具体的には KMS のキーポリシーで別アカウントの IAM ロールを許可し、別アカウント側で最小権限の IAM ポリシーを付与することが必須です。

Step 1: 要件と制約 — 目的は "無許可の CMK 作成を防ぐ" こと。効果的に制御するには、アカウント横断的な強制力を持つガードレールが必要。IAM ポリシーだけでは、組織全体に強制適用できないケース（管理者権限を持つユーザーなど）や、新規アカウントが生じたときの適用漏れが発生する。

Step 2: AWS の提供機能と採用理由 — AWS Organizations の Service Control Policies（SCP）はその OU 配下にある全アカウントに対して強制的にアクセスを拒否・許可できるため、キー作成の禁止を組織単位で適用できる。具体的には OU に対して Deny kms:CreateKey を設定し、例外的に運用を担当するセキュリティアカウントを作成してそこでのみキー作成を許可する。これにより、中央で鍵のライフサイクル管理、監査、ローテーション方針を統一できる。監査は CloudTrail（KMS API 呼び出しログ）や AWS Config で補助する。

Step 3: 実装上の注意点とトレードオフ — SCP は組織管理者によって適用されるため最初に正しく設計する必要がある。また SCP は組織のルートや OU の階層構造に依存するので、新規アカウントは正しい OU に配置される運用が重要。SCP は Deny が優先されるため、既存の管理者やサービス用ロールが必要とする KMS 操作を誤ってブロックしないようにテストを行う。運用コストは若干増えるが、コンプライアンス上の利点が大きい。 Trap: 受験者は "CloudTrail の検出で対応すればよい" や "IAM ポリシーだけで十分" と考えがちだが、IAM 単体では組織全体に強制適用することが難しく、検出後の対応は事後対応であるため予防措置としては不十分である。 Why each wrong answer fails: - 選択肢1（各アカウントの IAM ポリシーで拒否）: IAM ポリシーは各アカウントやロール単位で管理されるため、完全な一貫性を保証しにくい。特に、アカウント内の管理者ユーザーには IAM 上の別の許可があり、ポリシーの適用漏れやバイパスが起きる可能性がある。 - 選択肢3（検出して手動対応）: 事後検出はリスクを生み、コンプライアンスや即時的な鍵乱立による誤利用を防げない。自動化での検出後削除も誤削除リスクや運用負荷が高い。 - 選択肢4（自前鍵管理で分散）: 鍵管理を分散すると統制が効かず、セキュリティ・コンプライアンスの確保が困難になる。中央での監査・ローテーションポリシー適用も難しい。 総括すると、組織レベルで強制力のある SCP を用いて kms:CreateKey を OU 単位で制御し、鍵作成は中央の指定アカウントに集約するという設計が、管理性とセキュリティのバランスで最も優れている。

Step 1: 要件の整理 要件は「監査ログの中央集約」「改ざん防止（ログ完全性）」「鍵管理の明確化・制限」「監査チームが復号できる権限管理」などで、ログの所有権と鍵の所有権を一致させ改ざんリスクを最小化する必要があります。

Step 2: 推奨設計と理由 回答2の構成が最も適切です。理由は以下: - Centralized LoggingアカウントにCloudTrailを配信することでログの所有権が一箇所に集中し、監査・保管方針を一元的に管理できる。 - S3のサーバー側暗号化（SSE-KMS）にCustomer managed CMKを使用することで、鍵政策（Key policy）で「CloudTrailサービス」「セキュリティチームのIAMロールのみが復号できる」ように明確に制御できる。 - S3 Object Lock（ガバナンス／コンプライアンスモード）を有効にすることで、指定期間オブジェクトの削除や上書きを防ぎ、不変ログ（WORM）を実現して改ざん防止に寄与する。 - CloudTrail自体の設定は全アカウントで強制し、CloudTrailイベントの整合性検証機能（ログファイル検証）を用いることでさらに完全性を高める。

Step 3: 実装上の注意点 - S3バケットポリシーでPutObjectはCloudTrailのサービスプリンシパルとSourceAccountに限定する。 - CMKのKey policyやIAMポリシーで復号（Decrypt）を許可する主体を限定する（例：監査用ロールのみ）。 - S3バケットにバージョニングを有効にし、Object Lockを設定する際はライフサイクルと保持期間を慎重に設計する。 - MFA Deleteやアクセスログの収集も検討し、監査証跡を残す。 Trap: よくある誤解 「CloudTrailを各アカウントで保持すれば安全」や「AWS管理キーで十分」は誤解。ログの所有が分散していると改ざんリスク管理が難しく、AWS管理キーは鍵管理やアクセス制御の柔軟性に欠ける。 Why each wrong answer fails: - 回答1（各アカウントでS3に保存・鍵も分散）: ログの所有と保管が分散するため、一貫した保持ポリシーや改ざん防止策が適用しにくい。監査時にログ収集・整合性確認が困難となり、鍵を各チームに委ねると運用ミスや不正利用のリスクが高まる。 - 回答3（CloudWatch Logsのみ・KMS不使用）: CloudWatch Logsにだけ保存するのは可用性や長期保存、アクセス制御、WORM（不変性）要件の観点から不十分なことが多い。KMSを使わないとログデータの暗号化統制が甘く、規制要件を満たせない可能性がある。 - 回答4（CentralizedでAWS管理キーを使用）: Centralizedは良いがAWS管理キーは顧客によるキー管理や詳細なポリシー付与ができないため、誰がいつキーを使用できるかを厳密に制御・監査する要件を満たしにくい。Object Lockを無効にすると削除や上書きリスクが残る。 総括: 監査ログの改ざん防止には中央集約＋顧客管理CMKによる制御＋S3 Object Lockなど不変化の仕組みを組み合わせるのが最も堅牢で運用上の推奨となる。

Step 1: コンプライアンス要件で顧客管理キーを求められる場合、AWS の Customer managed CMK（カスタマー管理型 CMK）を中央アカウントに作成して集中管理することが推奨されます。キー ポリシーでどの IAM ロールやアカウントが暗号化／復号できるか厳密に定義し、CloudTrail による KMS の操作ログを取得して監査可能にします。

Step 2: S3 側では SSE-KMS（サーバーサイド暗号化 KMS）を選ぶことで、S3 に保存される各オブジェクトの暗号化に CMK を利用し、かつ AWS 側のアクセスを監査できます。また、S3 へのアップロードとダウンロードは TLS（HTTPS）で保護し、転送時の機密性を担保します。

Step 3: 設計上、クライアントサイド暗号化のみで済ますか TLS を無効にする設計は避けるべきです。TLS は転送時の保護であり、KMS は保存時のキー管理とアクセス制御を提供するため両者を組み合わせるのが正攻法です。Trap: よくある誤解は「SSE-S3 は十分」「TLS を無効化しても VPC 内だから大丈夫」などで、これらはコンプライアンスやゼロトラスト原則に反します。Why each wrong answer fails: Option '中央のセキュリティアカウントでカスタマー管理型 CMK を作成し...'（正解） — 中央管理でキーのライフサイクル、ローテーション、ポリシー、監査を一元化でき、クロスアカウント利用もキー ポリシーと IAM で安全に許可できます。Option 'S3 のオブジェクトは SSE-S3 で暗号化し、通信は VPC 内に閉じるために TLS を無効にしてもよい'（間違い） — SSE-S3 は AWS 管理キーであり、顧客管理キー要件を満たさない可能性があるほか、TLS を無効にすることは転送中の盗聴リスクを招き、VPC 内に閉じるだけでは内部脅威や誤設定リスクを排除できません。Option 'S3 側は SSE-KMS を使い、サーバー間通信は必ず TLS（HTTPS）を使うよう設定する'（正解） — 保存時は SSE-KMS、転送時は TLS で保護する組み合わせはコンプライアンスや監査要件を満たす最も実践的な解です。Option '顧客鍵を渡すことを避けるために、クライアントサイドで独自の鍵管理だけで暗号化し、AWS の KMS は使わない'（間違い） — クライアントサイド暗号化はセキュリティ上有用だが、キー管理やスケーリング、監査の観点で運用負荷と可用性のリスクが高く、SSE-KMS と併用しない設計は再利用性・監査性を損なうことがあります。

Step 1: 保存時暗号化と転送時保護の基本設計 - S3 のデフォルト暗号化を SSE-KMS（Customer Managed CMK）に設定することで、バケットに格納される全オブジェクトが顧客管理の KMS キーで暗号化されます。転送時は TLS（HTTPS）を使うのが前提で、S3 の HTTPS エンドポイントは自動的に提供されます。保存時のキー管理を顧客が行うことで鍵のライフサイクル、アクセス制御、監査（CloudTrail による KMS の使用ログ）を細かく制御できます。

Step 2: クロスアカウントアクセスと最小権限の実装 - KMS キーはキー ポリシーが最上位のアクセス制御になります。別アカウントの EC2/Lambda に復号を許可するには、CMK のキー ポリシーでそのロール（またはアカウント）を明示的に許可する必要があります。加えて、EC2/Lambda に付与する IAM ロールには S3:GetObject のみを許可し、KMS に対しては必要最小限の kms:Decrypt と kms:GenerateDataKey を限定的に許可します。これにより最小権限が保たれます。

Step 3: 運用・コスト・可用性の考慮 - 顧客管理 CMK は若干のコスト管理（暗号操作にかかる API コール）やキー管理運用（ローテーション、有効化／無効化）を伴いますが、セキュリティと監査性が向上します。SSE-S3（aws/s3 のマネージドキー）は簡便だがキー制御ができないため、クロスアカウント復号をきめ細かく管理したい要件には不向きです。CMK を使う場合、KMS のスループット制限（API レート）やリージョン差異も考慮して設計します。 Trap: よくある試験の誤解 - 「IAM ポリシーだけを設定すれば KMS 操作ができる」と考えるのは誤りです。KMS のキー ポリシーが最上位で、キー ポリシーで明示的に許可がないと、IAM ポリシーに権限があっても KMS 操作は拒否されます。試験ではキー ポリシーと IAM ポリシーの両方を想定して正しくアクセスを与えることが重要です。 Why each wrong answer fails: - 選択肢1（正しい）: SSE-KMS（カスタマー管理 CMK）をデフォルトにすることは、保存時暗号化の統一的な方法であり、監査・管理がしやすい。 - 選択肢2（誤り）: SSE-S3 は簡易でコストは低いが、KMS と違ってキーの明示的なアクセス制御（キー ポリシー）ができないため、クロスアカウントでの復号許可や監査要件を満たせない。S3 バケットポリシーのみでは KMS 復号は許可されない。 - 選択肢3（正しい）: CMK のキー ポリシーで別アカウントのロールに kms:Decrypt 等の権限を付与することは、クロスアカウント読み取りをセキュアに行うベストプラクティスであり、最小権限の原則に合致する。 - 選択肢4（誤り）: アプリケーションレイヤでの独自鍵管理は運用負荷と鍵漏洩リスクを増やす。長期 IAM ユーザーのアクセスキーで鍵共有するのは明確に不適切（キー漏洩と回転が困難）。KMS を使う方が安全で監査可能である。

Step 1: 保存時暗号化の実装。RDS の encryption を有効にして KMS のカスタマー管理キー（CMK）を使用すると、RDS はデータファイルやスナップショット、バックアップを KMS で暗号化する。CMK を顧客管理にすることで、どの IAM エンティティがキーを使えるかを key policy と IAM ポリシーで細かく制御できる。これにより、運用者とアプリケーションの分離、キーのローテーションや監査も容易になる。

Step 2: 転送時の保護。RDS は TLS（SSL）によるクライアント接続をサポートしている。DB インスタンス側で TLS を要求する設定（パラメータグループや接続文字列の server CA 検証）を有効にし、アプリケーション側でサーバ証明書の検証を必須にすることで中間者攻撃などを防止する。

Step 3: アクセス制御と監査。KMS の key policy と IAM ポリシーで最小権限を付与し、アプリケーション実行ロールにのみ必要な KMS 操作（例: kms:Decrypt）を許可する。加えて CloudTrail で KMS API 呼び出しや RDS 操作ログを収集すれば、誰がいつキーを利用したかを監査できる。 Trap: よくある誤解は「RDS の EBS を OS レベルで暗号化すれば十分」という点。RDS はマネージドサービスであり、DB レベルでの暗号化（RDS encryption）を有効にすることでバックアップ、スナップショットまで含めて暗号化されるが、単に OS レベルや EBS だけの暗号化に頼るとマネージドバックアップやスナップショットの暗号化が漏れる可能性がある。 Why each wrong answer fails: 2（EBS レベルだけの暗号化）：マネージド RDS の場合、RDS encryption を有効にするとスナップショットやリストア、バックアップも全て暗号化される。EBS ボリュームだけをターゲットにしたローカル OS レベルの暗号化は、RDS の自動バックアップやスナップショットの保護を保証しないし、KMS ベースのキー管理や監査の利点を活かせない。4（中央キーを作って無制限に付与）：キーを無制限に共有すると分離の原則（separation of duties）や最小権限の要件を満たせず、万一キーが悪用された場合の影響範囲が拡大する。運用は簡素化されるかもしれないがセキュリティとコンプライアンスの要件に反することが多い。まとめると、RDS encryption + KMS CMK と TLS の強制（DB 側とアプリ側の両面で）は要件を満たす妥当な選択である。

Step 1: 要件整理と技術選択 大量オブジェクトの高速処理が必要で、KMS 呼び出しコストとレイテンシを低減したい場合、KMS を完全に排除するのではなく「エンベロープ暗号化（データキー + CMK）」を採用するのが標準的な設計である。エンベロープ暗号化はセキュリティとパフォーマンスのトレードオフを最適化する。

Step 2: 実装詳細 1) KMS の GenerateDataKey を使ってデータキー（対称鍵）を生成する。KMS はデータキーの平文と暗号化されたバージョン（CiphertextBlob）を返す。 2) 平文データキーで実際のデータ（S3 オブジェクト等）を暗号化し、暗号化されたデータキー（KMS が暗号化したもの）をメタデータとして保存する。復号時はその CiphertextBlob を KMS に渡して Decrypt し、復号されたデータキーでデータを復号する。 3) 大量処理では平文データキーを短期間（メモリ内）でキャッシュして再利用することで、KMS への呼び出しを大幅に削減できる。キャッシュは TTL（短時間）とアクセス制御、プロセス終了でのクリアを実装し、キーの有効期限やローテーション方針に従う。

Step 3: 運用とセキュリティ上の配慮 - データキーの平文はメモリ内にのみ保持し、ディスクにスワップさせない設計にする。コンテナの再起動やプロセス死で確実に消去されるようにする。鍵の TTL を短くし、頻繁にローテーションする必要があるシナリオではキャッシュ時間を短縮する。 - コスト面では KMS の API 呼び出し数が削減されるため、費用対効果が高い。ただしキャッシュはセキュリティとトレードオフになるため、機密性要件に応じて最適な TTL を設計する。 Trap: よくある誤解 「KMS を呼び出すごとに安全が担保されるため、常に KMS を使うべきだ」と考える受験者がいるが、それでは高スループット処理で性能とコストの問題が生じる。KMS はデータキー管理に最適化されており、エンベロープパターンが推奨される。 Why wrong answers fail: 2) 各オブジェクトごとに常に KMS Encrypt/Decrypt を呼ぶ案：確かに安全だが高い遅延とコストが発生し、KMS のリクエストレート制限に引っかかるとスループットが著しく低下する。エンベロープ暗号化で十分かつ効率的に安全を保てる。 3) データ鍵を平文で S3 に保存する案：平文のキーを永続保存することは重大なセキュリティリスクであり、コンプライアンス違反になる。誰でもアクセスできれば復号されてしまう。 4) 非対称鍵（RSA）でクライアント側管理する案：非対称鍵はデータ暗号化（特に大量データ）には非効率で遅い。また鍵配布・保管・ローテーションが難しく、大規模運用では管理負荷とリスクが高い。KMS のマネージドな鍵管理とエンベロープ暗号化の組合せがベストプラクティスである。 結論：GenerateDataKey によるエンベロープ暗号化とアプリ側での短期データキーキャッシュにより、セキュリティを保ちながらコストとレイテンシを最小化するのが最良の選択である。