AWS Private Certificate Authority

解決する課題

• 内部 API やマイクロサービス間の mTLS 通信に使う証明書を、外部 CA に頼らず自前で発行したい
• OpenSSL などで手作りした自己管理 CA の鍵管理・運用負荷から解放されたい
• パブリックに信頼させる必要のない社内・IoT・コンテナ向け証明書を大量・安価に発行したい
• 証明書の発行・更新・失効を統制し、監査可能な形で一元管理したい

AWS Private Certificate Authority（AWS Private CA、旧 ACM Private CA）は、組織専用のプライベート認証局をマネージドに運用するサービスです。CA の秘密鍵を安全に保護しながら、内部だけで信頼される証明書を発行・管理でき、自前で CA サーバーを立てて鍵を守る運用を不要にします。

主要概念と用語

• プライベート CA: 組織内部でのみ信頼される私的な認証局。発行した証明書はパブリックには信頼されず、内部の通信や認証に使う
• ルート CA: 信頼の起点となる最上位の CA。自己署名証明書を持ち、通常は下位 CA への署名だけに使い、エンドエンティティ証明書は直接発行しない
• 下位 CA（subordinate / 中間 CA）: ルート CA に署名してもらって構成する中間の CA。実際の証明書発行はここから行い、ルート鍵の露出を抑える
• CA 階層: ルート CA と1つ以上の下位 CA を親子関係でつなげた信頼の連鎖。用途や部門ごとに下位 CA を分けて運用する
• エンドエンティティ証明書: サーバーやクライアントなど末端で使う実体証明書。CA 階層の下位 CA から発行される
• 証明書テンプレート: 発行する証明書の用途（サーバー認証、クライアント認証、コード署名など）や有効期間、拡張を定義したひな形
• トラストストア: 証明書を検証する側が「信頼する CA」として登録する CA 証明書の集合。プライベート CA はこのストアに自分で配布して信頼させる必要がある
• CRL（証明書失効リスト）: 失効した証明書の一覧。S3 に配置し、検証側が参照して失効を確認する
• OCSP（オンライン証明書状態プロトコル）: 個々の証明書の有効・失効をリアルタイムに問い合わせる仕組み。CRL より即時性が高い
• マネージド更新: ACM と統合した場合に、有効期限前に証明書を自動で再発行・差し替えする仕組み

仕様・制限・クォータ

• 発行する証明書はプライベート: パブリックに信頼される証明書は発行できない。検証側のトラストストアに CA を登録して初めて信頼される
• ルートと下位の両方を構成できる: ルート CA を AWS Private CA 内に作る方式と、外部の既存ルート CA に下位 CA を署名してもらう方式の両方をサポートする
• 2つの利用モード: 短命証明書向けに最適化された運用モードと、汎用の運用モードがあり、失効機能の利用可否や課金体系が異なる
• 失効は CRL / OCSP: 失効情報の配布として CRL（S3 経由）と OCSP を選べる。短命証明書中心なら失効機能を使わず有効期間を短くする設計も取れる
• ACM 連携で自動更新: ACM 統合により内部証明書のマネージド更新が可能。ACM を介さず API で直接発行した証明書は自動更新の対象外で、更新運用を自前で行う
• リージョンスコープ: CA はリージョン単位のリソース。マルチリージョン構成では各リージョンでの設計が必要
• CA の数や発行レートなどには上限があり、件数の上限はクォータ引き上げ申請で緩和できる場合がある

内部の仕組み

AWS Private CA の中核は「CA 階層」と「CA 秘密鍵の保護」です。まずルート CA を作成し、その配下に1つ以上の下位 CA を置きます。ルート CA の秘密鍵は普段使わず保管し、日常の証明書発行はすべて下位 CA から行うことで、信頼の起点である鍵の露出機会を最小化します。

各 CA の秘密鍵は、FIPS 140 準拠のハードウェアセキュリティモジュール（HSM）で生成・保管され、平文で外部に取り出せません。証明書への署名はマネージド基盤の内部で行われ、利用者は鍵そのものに触れずに発行・失効を指示します。これにより、自前で CA サーバーや HSM を運用して鍵を守る負荷から解放されます。

エンドエンティティ証明書を発行すると、下位 CA が署名した証明書と、ルートまでつながる中間証明書（チェーン）が得られます。検証側はルート CA 証明書をトラストストアに登録し、提示されたチェーンをたどって信頼を確認します。失効させた場合は CRL や OCSP を通じて失効状態が配布され、検証側がそれを参照して失効済み証明書を拒否します。

設計パターン / ベストプラクティス

• ルート＋下位の2層以上で構成する: ルート CA は署名専用にし、発行は下位 CA に任せてルート鍵の露出を抑える
• 用途・部門で下位 CA を分ける: サーバー認証用とクライアント認証用、本番と検証など、失効の影響範囲を切り分ける単位で下位 CA を設計する
• ACM 統合で更新を自動化する: 対応サービス向けの内部証明書は ACM 経由で発行し、マネージド更新で期限切れを防ぐ
• 短命証明書を活用する: 失効運用を簡素化するため、有効期間の短い証明書を頻繁に再発行する設計にすると、CRL/OCSP への依存を減らせる
• 外部ルートに下位 CA をぶら下げる選択肢: 既存の社内 PKI のルートを活かす場合は、外部ルート CA に署名してもらった下位 CA を AWS Private CA に置く
• トラストストア配布を自動化する: ルート CA 証明書を AMI・コンテナイメージ・構成管理ツールで各ノードへ確実に配布する

運用・監視

• 有効期限を監視する: ACM 統合で発行した証明書は ACM 側のメトリクスやイベントで期限を監視できる。API 直接発行分は自前で期限管理が必要
• 失効運用を整える: CRL を使う場合は配置先 S3 バケットの可用性とアクセス権を確認し、OCSP を使う場合は応答性を監視する
• 発行・失効を監査する: CA の作成、証明書の発行・失効といった操作は CloudTrail に記録される。誰がいつ何を発行・失効したかを追跡する
• CA の状態を把握する: CA は有効・無効・失効・削除待ちなどの状態を持つ。削除前には待機期間があり、誤削除からの復元余地が設けられている
• 証明書の棚卸し: どの下位 CA からどれだけ発行したかを定期的に確認し、不要な証明書を失効させる

コスト

• CA に月額がかかる: 稼働中の CA ごとに月額料金が発生する。下位 CA を増やすほど CA 課金が積み上がるため、分割の粒度はコストとのバランスで決める
• 証明書発行ごとに課金: 発行した証明書の数に応じた料金がかかる。発行量が多いと費用が増えるため、有効期間と再発行頻度の設計がコストに直結する
• 利用モードで体系が異なる: 短命証明書向けモードと汎用モードでは課金体系が異なるため、用途に合うモードを選ぶ
• 無効化（disable）でコスト抑制: 一時的に使わない CA は無効化することで稼働課金を抑えられる場合がある。長期不要なら削除を検討する

セキュリティ

• CA 秘密鍵を HSM で保護: CA の鍵は HSM 内に隔離され、平文で外部に出ない。自前運用にありがちな鍵ファイルの漏えいリスクを排除できる
• IAM で発行権限を最小化: CA の作成・証明書の発行・失効の権限を IAM ポリシーで分離し、発行できる主体と用途を絞る
• テンプレートで用途を限定: 証明書テンプレートで鍵用途や有効期間を制約し、想定外の用途への発行を防ぐ
• CloudTrail で証跡を残す: すべての発行・失効操作を記録し、監査と異常検知に使う
• ルートと下位の責務分離: ルート鍵の使用を署名のみに限定し、日常発行は下位 CA に委ねることで、最も重要な鍵への到達経路を減らす

Well-Architected の観点

• セキュリティ: CA 秘密鍵を HSM に隔離し、IAM と CloudTrail で発行・失効を統制することで、内部 PKI の鍵管理リスクと人的ミスを減らす。下位 CA への責務分離と短命証明書の活用は、失効時の影響範囲を局所化し、被害を封じ込めやすくする
• 運用負荷の観点でも、CA サーバーや HSM の自前運用、証明書の手動更新といった反復作業をマネージド基盤と ACM 統合に肩代わりさせ、運用上の手作業を削減する

試験で問われるポイント

関連サービス・比較

AWS Private CA はプライベート（内部向け）証明書を発行する CA サービスで、パブリックに信頼させる証明書を扱う ACM とは役割が分かれます。両者の違いを整理します。

ハンズオン / CLI例

# CA の設定ファイルを用意（サブジェクト情報・鍵アルゴリズムなど）
cat > ca_config.json <<'EOF'
{
  "KeyAlgorithm": "RSA_2048",
  "SigningAlgorithm": "SHA256WITHRSA",
  "Subject": {
    "Organization": "Example Corp",
    "CommonName": "Example Internal Root CA"
  }
}
EOF

# ルート CA を作成（CertificateAuthorityType を ROOT に指定）
aws acm-pca create-certificate-authority \
  --certificate-authority-configuration file://ca_config.json \
  --certificate-authority-type ROOT \
  --region ap-northeast-1

# 作成した CA の一覧と状態を確認
aws acm-pca list-certificate-authorities --region ap-northeast-1

# ルート CA を有効化するには、自己署名証明書を取得してインポートする
# （CSR 取得 → ルートとして署名 → import-certificate-authority-certificate の流れ）
aws acm-pca get-certificate-authority-csr \
  --certificate-authority-arn <CAのARN> \
  --region ap-northeast-1 \
  --output text > ca.csr

# ACM 経由で、この CA からプライベート証明書をリクエストする
aws acm request-certificate \
  --domain-name api.internal.example.com \
  --certificate-authority-arn <CAのARN> \
  --region ap-northeast-1