ANSネットワークのセキュリティ、コンプライアンス、ガバナンス
ある企業はAWS Organizationsで30以上のAWSアカウントを管理し、各アカウントのAmazon EKSクラスターで数百のマイクロサービスを運用しています。セキュリティ要件として、マイクロサービス間のmTLS（相互TLS認証）通信には「組織内のみで信頼されるプライベート証明書」を使用し、証明書の自動ローテーションを実現する必要があります。CAインフラは中央の1つのAWSアカウントで集中管理し、各メンバーアカウントから証明書を発行できる構成としたい場合、最も適切なソリューションはどれですか？
A各AWSアカウントでAWS Certificate Manager（ACM）からパブリック証明書を申請し、EKSのcert-managerでPodに配布する
ACMパブリック証明書はAmazonやその委任CAが発行し、インターネット上で広く信頼される証明書である。組織内のみで信頼されるプライベートPKI基盤は構築できず、内部マイクロサービス間のmTLS（相互TLS認証）に必要なプライベート証明書の要件を満たさない。
B中央アカウントでAWS Private Certificate Authority（AWS Private CA）を作成し、AWS Resource Access Manager（RAM）を通じて各メンバーアカウントと共有し、ACMと統合して証明書の自動発行・自動ローテーションを実現する
✓ 正解
AWS Private CAはフルマネージドのプライベートPKIサービスであり、RAMでOrganization内メンバーアカウントとCAを共有することで中央集権的なCA管理と各アカウントからの証明書発行を両立できる。ACMとの統合により証明書の自動更新・ローテーションも実現し、すべての要件を満たす最適な構成。
C中央アカウントのEC2インスタンスにOpenSSLで社内認証局を構築し、ルートCA証明書と中間CA証明書を各EKSクラスターに手動で配布する
EC2上のOpenSSL CAは高可用性、バックアップ、HSM保護、監査ログをすべて自前で実装する必要があり、30以上のアカウントへの証明書配布と自動ローテーションを手動で管理する運用負荷は非常に高く、エンタープライズ規模の要件に適さない。
D中央アカウントのAWS Secrets Managerに自己署名証明書を格納し、AWS Lambdaの定期実行で90日ごとに証明書を再生成して各アカウントのSecrets Managerに複製する
Secrets ManagerとLambdaによる自己署名証明書の複製は正規のCA信頼チェーンを持たないため各EKSクラスターの信頼ストア管理が複雑になる。30以上のアカウントへの複製ロジックの実装・保守コストも高く、適切なmTLS向け証明書管理体制とは言えない。
解説
AWS Private Certificate Authority（AWS Private CA）は、フルマネージドなプライベートPKIインフラを提供するサービスです。中央アカウントでルートCAまたは下位CAを作成した後、AWS Resource Access Manager（RAM）を使用してOrganization内の各メンバーアカウントとCAを共有できます。各メンバーアカウントはACM（AWS Certificate Manager）と統合することで、共有されたプライベートCAから証明書を発行でき、ACMの自動更新機能により証明書の自動ローテーションも実現します。これにより組織内だけで信頼されるプライベート証明書の中央集権的なCA管理と、各アカウントへの分散した証明書発行という要件をすべて満たします。
選択肢AのACMパブリック証明書はAmazon Trust Servicesなどの公開CAから発行され、インターネット上で広く信頼されるものであり、「組織内のみで信頼される内部プライベート証明書」という要件を満たさない。
選択肢CのEC2上のOpenSSL CAは高可用性・バックアップ・証明書更新・スケーリングをすべて手動管理する必要があり、30以上のアカウントへの自動ローテーションを含む証明書配布は運用コストが過大となる。
選択肢DのSecrets Manager＋Lambda構成は、自己署名証明書が正規のCA信頼チェーンを持たないためmTLSでの信頼管理が複雑になる。また各アカウントへの複製ロジックの実装・管理コストが高く、証明書の整合性保証も困難。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでANSを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →