Certificate Authority Serviceは、プライベート認証局(CA)の展開・管理・セキュリティを効率化、自動化、カスタマイズできるサービスです。本記事では、Google Cloud Certificate Authority Serviceの3つの設計パターンをご紹介します。
Google Cloudのプロジェクトと組織でルートCAと下位CAを関連付ける3つのアプローチ
Certificate Authority Serviceは、プライベート認証局(CA)の展開・管理・セキュリティをシンプルに、かつ自動化・カスタマイズできるフルマネージドサービスです。
Google Cloud上のworkloadsや内部SSLロードバランサ向けにプライベート証明書をプロビジョニング・管理している組織であれば、Certificate Authority Serviceを活用することで、証明書の発行やローテーションといった手作業をなくし、厳格なアクセス制御を実現できます。
本記事では、Certificate Authority Serviceを実装する際の3つの設計パターン、すなわちGoogle Cloudのプロジェクトと組織でルートCAと下位CAを関連付ける3通りの方法について、それぞれのメリットとデメリットを解説します。
いずれのパターンも、機能が限定的なDevOpsティアではなくEnterprise CA poolティアを利用し、認証局の階層は2層構成とします(さらに増やすことも可能ですが、3層以下に抑えることをおすすめします)。
パターン1:組織レベルでのCA構成
このアーキテクチャでは、ルートCAを1つだけ用意し、環境ごとに下位CAを配置します。最もシンプルな構成で、すべてのCAと証明書を一元管理しながら、必要なIAMポリシーをまとめて適用できます。
クライアントにインストールするルートCAは1つで済みます。証明書発行ポリシーを設定すれば、各下位CAが想定したドメインに対してのみ証明書を発行するよう制御できます。
このパターンのデメリットは、ルートCAが1つであるがゆえに、すべてのクライアントがすべての環境の証明書を信頼してしまう点です(例えば本番系がプリプロダクション系を信頼し、その逆も同様です)。
また、ルートCAが1つだけだと変更のテストが難しくなります。設定ミスがすべての下位CAに波及してしまうためです。ルートCAそのものに手を加えることは避け、新たな下位CAをデプロイして変更内容を検証する運用が望ましいでしょう。
パターン2:環境タイプごとのCA構成
このアーキテクチャでは、環境タイプごとにルートCAと下位CAをそれぞれ用意します。CAは単一のプロジェクトにまとめつつ、本番とプリプロダクションを区別します。一方、その他のクラウドリソースは開発、プリプロダクション、本番など、用途別に異なるプロジェクトに配置します。
プロジェクトで稼働するサービスは、環境タイプに応じた下位CAから必要な証明書を取得できます。証明書発行ポリシーによって、各下位CAが想定したドメインに対してのみ証明書を発行するよう制御することも可能です。
この構成なら、本番にロールアウトする前に下位環境で変更内容をテストできます。
デメリットは、クライアントの環境タイプに応じて、異なるルートCAをインストールする必要がある点です。
パターン3:プロジェクトごとのCA構成
このアーキテクチャでは、プロジェクトごとにルートCAと下位CAを個別に用意し、完全な分離を実現します。他のCA構成に影響を与えることなく、下位環境で変更内容を手軽に検証できます。
ルートCAが複数になるため、クライアントが属する環境に応じて異なるルートCAをインストールする必要があります。
複数の環境にまたがる信頼関係が必要な場合は、対象のクライアントに複数のルートCAをインストールしなければなりません。
アーキテクチャと運用の両面で最も複雑なパターンですが、分離によって高いセキュリティを確保できる点が強みです。
まとめ
Certificate Authority Serviceの設計パターンをどう選ぶかは、組織がセキュリティ要件と、運用のしやすさ・コストのバランスをどう取るかによって決まります。
DoiTとの協業についてさらに詳しく知りたい方は、こちらからお問い合わせください。Certificate Authority Service(CAS)の設計をはじめ、クラウド関連の課題全般についてもお気軽にご相談ください。