AWS Client VPN：クライアント証明書はどの CA が発行すべきか

AWS Client VPN の証明書の問いは製品の問いとして語られますが、実際には運用の問いです。通常の三つの構成のどれでも、動作するトンネルは維持されます。既存の組織 CA、専用の自社運用発行元、あるいは AWS Private CA です。違いは、誰がデバイスを承認するか、誰が署名鍵を保持するか、そして都合の悪い時刻にノート PC が行方不明になったとき誰が応答するかです。担当者を名指しできる選択肢を選んでください。

AWS は証明書認証に Private CA を必須としていません。サーバー証明書を ACM に置くのは展開の手順であり、登録のプロセスではありません。

判断を決める三つの条件

三つの条件が選択肢を明確に分けます。承認済みのデバイス登録プロセスがすでにあるか、バックアップと指名された担当者を伴う署名鍵を運用できるか、そして失効がどのようにエンドポイントに届くかです。どれも「はい」か「いいえ」に近く、最初の「いいえ」が通常アーキテクチャを決めます。

順番に検討してください。いきなりコスト比較に飛びつくと、チームはマネージド CA を抱えたまま、次のノート PC 証明書を誰が発行するのか誰も知らない状態になります。

第一の条件：登録はすでにあるか

組織がすでに承認済みのデバイス登録経路を持つ CA を運用しているなら、そこから Client VPN のクライアント証明書を発行するのが最短の道です。承認、プロセス、資産記録はすでにそこにあります。その階層の下に専用の下位発行元を置く方が、汎用の発行 CA より通常は優れています。VPN に独自の信頼境界と独自の失効リストを与えられるからです。そのリストは階層の他の部分と分けておき、VPN のインシデントが PKI 全体の変更を強いることのないようにしてください。

そのようなプロセスがなければ、本当の問いはそれを構築したいかどうかです。CA は始めるのは容易で、まずく所有するのは高くつきます。

第二の条件：署名鍵を運用できるか

自社運用の発行元は文書化されたインポートモデルで動作し、EasyRSA や小さな社内ツールで素材を作れます。コマンドを実行することは難しい部分ではありません。難しいのは、署名鍵のオフラインバックアップ、誰かが実際に試した復旧手順、休暇中でない担当者、そして鍵がクライアントバンドルや構成のエクスポートに決して入らないというルールです。最初の証明書を発行する前に、最初のインシデントの後ではなく、手順として書き留めてください。

AWS Private CA はその保管をマネージドサービスへ移します。登録ポリシー、承認の手順、証明書をデバイスへ届けることは移しません。

第三の条件：失効はどう届くか

Client VPN は、エンドポイントにインポートするクライアント証明書の失効リストを消費します。証明書のライフサイクルガイドに記載されているとおりです。PKI の別の場所で CRL を公開しても、それがサービスに押し込まれるわけではありません。インポートは別個の定期的な作業であり、期限切れのリストは静かに劣化するのではなく接続を停止します。更新は証明書自体と同じカレンダーに置いてください。

これにより更新は担当者を持つ監視項目となり、ローンチで終わる作業ではありません。仕組みが本当に必要になる前に、テスト証明書を一つ、最初から最後まで失効させてください。

どの選択肢でも取り除けないもの

どの選択肢でも、独立して管理されるデバイスごとに別個のクライアント証明書と鍵が依然として必要です。全員に単一の識別情報を配るチュートリアルはチュートリアルの近道であり、選択的な失効も不可能にします。

ACM にインポートしたサーバー証明書にはマネージド更新がないため、担当者は代替を用意し、再インポートし、エンドポイントがそれを採用したことを確認する必要があります。サーバー証明書を更新しても、すでにノート PC 上にあるクライアント資格情報は更新されません。それらは別のカレンダーを持つ別のライフサイクルです。

何かを発行する前に、サービスが受け入れる鍵の種類と拡張を確認してください。CA があるアルゴリズムをサポートしていても、エンドポイントがそれを受け入れるとは限りません。

ローンチ前に、選んだワークフローで更新を一つとクライアントの削除を一つ実行し、どの資格情報が変わり、どのエンドポイント設定が変わり、アクティブなセッションがどうなったかを書き留めてください。その演習が明確な担当者なしで終わるなら、発行元の選択は終わっていません。