クライアント証明書で接続を制限するには、証明書を発行する認証局（CA）、利用者へ渡す仕組み、接続時に証明書と失効を確認する仕組みが要る。 CAだけを選んでも、誰に発行し、どの端末へ渡し、不要になった証明書をどう止めるかは決まらない。
本稿では、CodeBuildでOpenSSLを実行するCA運用構成、Vault CommunityのPKI、AWS Private CAを比較する。 まずCodeBuild＋OpenSSL構成の具体的な部品と処理を示し、CAの鍵の保護と、実装・保守を引き受ける範囲の違いを整理する。 利用者の発行と管理者の停止は、運用画面例で試せる。
1. CA・配布・接続の判定を分ける
CAの公開証明書は、接続側が信頼する発行者を確認するために使う。CAの秘密鍵は署名する側だけが持つ。 また、所有者や配布状態を持つ台帳と、接続を拒否するための失効簿は別の役割である。 台帳の状態を書き換えても、接続時の照合先へ反映されなければ、その証明書による新しい接続を止められない。
2. CodeBuild＋OpenSSLによるCA運用構成
この構成はAWS Private CAを使わず、CodeBuildの実行環境でOpenSSLを動かしてCAを運用する。 CodeBuildが常時稼働するCAサーバーになるのではなく、初期作成・発行・失効の要求ごとに処理を起動する。 以下は参照したコミットの設定・実装定義を整理したもので、AWS実環境の稼働状態を確認した結果ではない。
発行APIは本人の要求を受け、CodeBuildを起動する。 CodeBuildがCAの鍵を一時取得してOpenSSLで署名し、配布ファイルをS3へ置く。 窓口はDynamoDBの所有者と状態を確認して、利用者へ取得方法を返す。
この構成の配布パスワード用KMS鍵は、CAの署名を行う鍵ではない。 パスワードを保護する処理と、CA秘密鍵を使って署名する処理を区別する必要がある。 また、署名付きURLの再発行を窓口で制御することと、発行済みURLが一度しか使えないことも別である。 S3の署名付きURLは、有効な期間中は再利用できる。
停止するときはCodeBuildがKeyValueStoreの失効簿へ通し番号を登録し、Connection Functionが新しいTLS接続を拒否する。 接続時の判定はDynamoDBの台帳を読まない。 Cognitoの利用者を削除・無効化しても、証明書そのものは失効しないため、通知と停止の運用を別に持つ。
人の端末用とは別に、配信監視用の機械証明書も扱う。 こちらは秘密鍵と証明書をSecrets Managerへ置き、監視Lambdaが更新を起動する。 CodeBuildは新しい証明書を発行し、古い証明書を失効させる。 人へのファイル配布と、機械の自動更新を同じ操作として扱わない。
この方式は、所有者の台帳、配布状態、本人による停止、監視用の自動更新まで含む構成である。 その分、CA処理のスクリプトだけでなく、API・台帳・配布・失効・定期処理の整合性も保守対象になる。 直接起動する経路の権限、途中失敗と再試行、鍵の更新、配布ファイルの削除などを、構成を維持する側が継続して管理する。
3. Vault CommunityのPKIへ任せる範囲
Vault Communityは、CAの鍵を内部で生成し、PKIのAPIから証明書の発行や失効を扱える。 内部生成する設定では、発行を頼むアプリケーションへCAの秘密鍵を返さずに署名する。 発行する名前・用途・期限の制限は、PKIのロールとVaultのポリシーへまとめる。
これにより、CodeBuildへCAの鍵を渡して署名する処理を持たずに済む。 一方、Vaultは自分で動かすサービスなので、稼働、版の更新、保存先、バックアップ、復旧、管理権限の保守を引き受ける。 CA処理の実装を製品へ任せることと、運用責任を外部へ委ねることは同じではない。
Vault CommunityでもKMSによる自動アンシールを使えるが、これは封印を解除するための仕組みである。 CAの署名鍵をHSMやKMSの中で使用するManaged Keysは、Vault Enterpriseの機能になる。 自動アンシールを使っていることだけで、CAの署名鍵がHSMから出ないとは判断できない。
この構成例では、利用者は本人の端末用に発行し、管理者は全件の確認と失効を担当する。 独自の配布台帳や本人だけの証明書一覧は設けず、発行者と通し番号の対応は監査ログで追う。 VaultのPKIの一覧・通常の失効APIは、発行した本人を基準に自動的に絞り込むAPIではないため、利用者へそのまま公開しない。
利用者の秘密鍵はVaultで生成し、APIが証明書とともにPKCS#12へまとめ、応答で一度だけ渡す。 取り損ねたときは再発行する。CodeBuild＋OpenSSL構成のS3による一時配布とは異なる方式である。 また、この構成例には機械証明書の自動更新や、所有者不在の証明書を検出する機能を作っていない。 Vaultの導入だけで、CodeBuild＋OpenSSL構成と同じ周辺機能まで提供されることにはならない。
CloudFrontとの接続では、Vaultの失効をKeyValueStoreへ同期する。 CAで失効したこと、失効簿への書込み、配信への伝播、新しい接続の拒否確認を別の状態として扱う。 この方式は接続のたびにVaultを呼ばないが、同期失敗の検知と再試行は必要になる。
4. AWS Private CAへ任せる範囲
AWS Private CAは、CAの生成・署名・失効を扱うマネージドサービスである。 CAの秘密鍵をAWS管理のHSMへ保管し、CAサービスの基盤運用をAWSが担う。 AWSの文書では、そのHSMはFIPS 140-3 Level 3に準拠する。 ソフトウェアで動かすVault Communityや、CodeBuildへ鍵ファイルを読み出す方式と比べ、CA鍵の保護と基盤保守を委ねられる点に利点がある。
証明書の発行APIへはCSRを渡す。 利用者の秘密鍵をどこで作るか、PKCS#12にまとめて誰へ渡すか、所有者をどう確認するかは別に設計する。 この比較でAWS Private CAを選ぶことは、CAの中核を任せることであり、利用者の窓口や既存の台帳・自動更新まで不要になることではない。
CAの鍵を直接読めなくても、不適切な相手へ発行できる権限を渡せば、正規の証明書を不正に作られる。 IAM、証明書テンプレート、窓口の認証と発行条件の管理は必要である。
5. 3方式を実装と保守の範囲で比較する
以下のCodeBuild＋OpenSSLとVaultの列は、それぞれ参照した構成を示す。 AWS Private CAの列はサービス仕様と、別途実装が必要な部分である。同じ一式をAWS Private CAで構築して実測した比較ではない。
Vault Community自体が、機械証明書の更新や所有者台帳の作成を妨げるわけではない。 必要なら周辺機能を追加することになる。 どの方式でも、PKCS#12とパスワードが複製されれば別の端末で使われ得ること、更新しても古い証明書が自動で止まらないことは共通の運用課題である。
費用も、CAの料金と周辺機能の開発・保守を分けて比較する。 2026年11月7日に確認したAWS Private CAの公表料金は、汎用モードが1 CAあたり月400 USD、短期証明書モードが1 CAあたり月50 USDで、発行等は別料金になる。 短期モードは最長7日の証明書向けなので、人が手で取り込む30日の証明書と、その料金だけを比べることはできない。
Vault CommunityはBSL 1.1で提供され、組織内で使うことは認められている。 競合する製品やサービスへ組み込む、またはホストして提供する場合は、採用版のLICENSEを確認する。 ライセンスの費用が発生しない使い方でも、稼働させる基盤と保守の費用は残る。
6. 選定では保守責任をどこへ置くかを決める
少人数の社内利用でVault Communityを採用した例では、独自のCA処理と周辺機能の組み合わせを維持する保守責任の重さを選定理由とした。 扱う情報と漏えい・停止時の影響、費用を評価し、必要な機能の範囲を絞ってCA処理をVaultへ任せている。 これはVaultの方がAWS Private CAより安全だからという評価ではなく、CA鍵の保護と基盤保守を委ねる利点を認めたうえでの判断である。 Vaultの保守が不要になったことや、全体の保守工数が実測で減ったことを示すものではない。
保守する処理と必要な機能を一覧にし、残すもの、製品へ任せるもの、作らないものを決める。 比較するのは証明書を発行できるかどうかだけでなく、利用者へ渡してから停止するまでの責任を継続して持てるかである。
運用画面例はVaultを使う構成を抽象化している。実際のサービスへの接続、実用の鍵・証明書・パスワードの生成は行わない。 CodeBuild＋OpenSSL構成やAWS Private CAの全機能を再現するモックではない。