このページでは、Certificate Manager と Certificate Authority Service（CA Service）を使用して Google Cloud で証明書を構成および管理するためのさまざまなベスト プラクティスについて説明します。このページでは、証明書管理アーキテクチャを設計する方法について説明します。
このページを読む前に、Certificate Manager の概要と Certificate Authority Service の概要のページを理解しておいてください。
証明書管理アーキテクチャを設計する
エンタープライズ証明書管理戦略を設計する際は、組織の主なユースケースと証明書のライフサイクル全体を考慮する必要があります。これらの決定は、コスト、運用上のオーバーヘッド、発行、取り消し、ローテーションなどの証明書管理機能の実装の容易さに影響します。
以降のセクションでは、各設計の選択に関する推奨事項について説明します。
証明書のタイプを選択する
証明書を作成するときは、アプリケーションの要件と組織のセキュリティ ポリシーに応じて、ユースケースに適した証明書タイプを選択する必要があります。
最適な証明書のタイプを分析するには、次のフローチャートをご覧ください。
フローチャートで説明したトピックに関する役立つドキュメント リンクをいくつかご紹介します。
プライベート CA Service 階層を効率化する
スムーズな運用とトラブルシューティングを確保するため、CA サービスの階層をできるだけ単純にすることをおすすめします。ルート認証局（CA）は、独自の Google プロジェクトに保存する必要があります。ルート CA がいくつかの中間 CA に署名し、それらの中間 CA が最終的な証明書を発行します。
このフラットな階層構造により、透明性が向上し、証明書の取り消しプロセスが簡素化され、構成ミスの可能性が低減されます。CA Service はリージョン サービスですが、あるリージョンのルート CA は、他のリージョンにある下位 CA に署名できます。
図に示すように、CA Service 階層で次のベスト プラクティスに従います。
- 発行 CA に署名するために、ルート CA を独自の Google Cloud プロジェクトに分離します。
別々のプロジェクトでホストされている CA プールに発行元 CA を作成します。これらのプールを個別のプロジェクトでホストし、地理的位置（リージョン）、ソフトウェア開発ライフサイクル（開発、本番、テスト）、または特定のユースケースごとにセグメント化します。
サポートされているリソースにプライベートに信頼できる証明書を発行できる発行 CA プールを使用するように Certificate Manager を構成します。
包括的なホスト名カバレッジを使用する
サービスで保護する必要があるすべてのドメインとサブドメインに対して、証明書で十分なホスト名がカバーされていることを確認することをおすすめします。ホスト名のカバレッジが不十分だと、ユーザーにセキュリティ警告が表示されたり、サービスが中断されたり、ユーザー エクスペリエンスが低下したりする可能性があります。
複数のドメインに 1 つの証明書を使用しないでください。単一の証明書の更新に失敗した場合や、誤って削除された場合、その証明書が対象とするすべてのドメインが保護されなくなります。異なるドメインには個別の証明書を作成することをおすすめします。
後で新しいサブドメインやサービスを追加する予定がある場合は、ワイルドカード文字を使用して、最初から証明書にサブドメインやサービスを含めます。たとえば、*.myorg.example.com のワイルドカード証明書は、最初のサブドメイン レベルのみを保護し、sub.subdomain.myorg.example.com などのより深いサブドメイン レベルは保護しません。
Google マネージド証明書を使用する
一般公開証明書を効率的に管理し、使いやすさを高めるには、Google マネージド証明書を使用することをおすすめします。このアプローチにより、運用上のオーバーヘッドが大幅に削減され、証明書のローテーションなどのタスクが自動化され、手動更新に関連するリスクが排除されます。
また、Google マネージド証明書は、他のGoogle Cloud サービスとシームレスに統合できます。Certificate Manager は、公的に信頼できる Google マネージド証明書の発行に、Public Certificate Authority（pki.goog）と Let's Encrypt CA（letsencrypt.org）のみをサポートします。Certificate Manager は、発行元 CA に応じて、45 日間または 90 日間の有効期間の Google マネージド証明書をプロビジョニングします。
- Public CA によって発行された証明書は、有効期間が 90 日から 45 日に段階的に移行しています。既存の 90 日間の証明書は、次回の更新まで 90 日間有効です。
- Let's Encrypt CA が発行した証明書の有効期間は 90 日です。
Certificate Manager は、証明書の有効期間の約 3 分の 1 が残っているときに、更新プロセスを自動的に開始します。更新は、45 日間の証明書の場合は有効期限の約 15 日前、90 日間の証明書の場合は有効期限の約 30 日前に開始されます。
証明書のパフォーマンスをスケーリングして改善する
以降のセクションでは、証明書をスケーリングし、プロビジョニングや更新などの証明書関連のアクションのパフォーマンスを向上させるためのベスト プラクティスについて説明します。
Certificate Manager に分散型デプロイを適用する
Certificate Manager はプロジェクトごと、ロケーションごとに使用します。つまり、証明書は、同じリージョン内の関連リソースと同じプロジェクトに保存されます。この戦略により、異なるリージョン間での証明書の再利用を防ぎ、万が一リージョンが停止した場合の影響を効果的に最小限に抑えることで、信頼性を高めることができます。
さらに、割り当てと上限は Google Cloud プロジェクト レベルで適用されるため、複数のプロジェクトに Certificate Manager をデプロイすると、全体的な割り当てが増加します。これは、あるプロジェクトでリソースを使用しても、別のプロジェクトで使用可能な割り当てに影響しないためです。
ECDSA 鍵で証明書を使用する
このセクションでは、証明書署名鍵として RSA ではなく ECDSA を推奨する理由について説明します。
使用する鍵の種類
ECDSA P-256 は、ほとんどの TLS 証明書に推奨される鍵の種類です。ECDSA P-256 は、強力な暗号セキュリティ、署名オペレーションの優れたパフォーマンス、ネットワーク帯域幅の効率的な使用を提供します。
他の種類の証明書鍵を使用する理由としては、次のようなものがあります。
- ECDSA 証明書をサポートしていないレガシー クライアントをサポートする必要がある場合は、ECDSA P-256 証明書に加えて RSA-2048 証明書を提供できます。
- 特定のコンプライアンス要件により、大きなサイズの鍵や特定の種類の鍵を使用する必要がある場合は、ECDSA P-384、RSA-2048、RSA-3072、RSA-4096 の鍵を使用できます。
RSA ではなく ECDSA を選択する理由
ECDSA の主な利点は、RSA よりも大幅に小さい鍵で同等の暗号セキュリティ レベルを提供できることです。この効率性は、パフォーマンスとリソースのメリットに直接つながります。鍵が小さくてもセキュリティが弱くなるわけではありません。ECDSA は楕円曲線離散対数問題に基づいており、RSA と比較して、鍵あたりのセキュリティが強力であるほか、場合によっては計算効率も高くなります。
次に例を示します。
- 256 ビットの ECDSA 鍵は、RSA-3072 鍵と同等のセキュリティ レベルを提供します。
- 384 ビットの ECDSA 鍵は、広くサポートされている RSA 鍵のサイズよりも高いセキュリティ レベルを提供します。
ECDSA の主なメリット:
パフォーマンス: ECDSA の署名オペレーションは、同等のセキュリティ レベルを提供する RSA のオペレーションよりも計算負荷が大幅に低くなります。これにより、CPU 負荷とレイテンシが低減されます。これは、高スループットまたはレイテンシの影響を受けやすいシステムにとって重要です。
効率性: 鍵と署名が小さければ、必要な帯域幅とストレージが少なくなります。これは、モバイル デバイスや IoT デバイスなどのリソースが制限された環境で特にメリットがあります。
次のカスタムの組織のポリシーを作成して、証明書で特定の鍵タイプを使用するように強制できます。これは、CA Service の Google マネージド証明書（プライベート トラスト マネージド証明書）にのみ適用され、セルフマネージド証明書とパブリック トラストの Google マネージド証明書には適用されません。
name: organizations/ORGANIZATION_ID/customConstraints/custom.restrictAlgorithm \
resourceTypes: \
- certificatemanager.googleapis.com/CertificateIssuanceConfig \
methodTypes: \
- CREATE \
- UPDATE \
condition: "resource.keyAlgorithm == 'ECDSA_P256'" \
actionType: ALLOW \
displayName: Allow only ECDSA_P256 in Certificate Issuance configs \
description: Only ECDSA_P256 certificates are allowed from CA Service.
CA プールを使用してプライベート CA から証明書を発行する
発行元 CA には CA プールを使用することをおすすめします。CA プールは、共通の証明書発行ポリシーと Identity and Access Management（IAM）ポリシーを持つ複数の CA の集合です。CA プールを使用すると、プール内の有効なすべての CA に受信した証明書リクエストをロード バランシングして分散することで、有効な合計秒間クエリ数（QPS）を増やすことができます。これにより、ワークロードやクライアントサイドの変更に影響を与えることなく、パフォーマンスが向上します。
CA プールは、証明書の発行と取得のための単一のエンドポイントを提供します。CA プールを使用すると、証明書の有効期限切れや侵害によるダウンタイムを発生させることなく、CA を安全にローテーションできます。
証明書マップを使用する
最適なスケーラビリティを確保するには、サポートされているリソースで証明書マップを使用することをおすすめします。証明書マップはスケーリングを考慮して設計されており、デフォルトで数千の証明書エントリをサポートし、数百万の証明書を処理できます。ロードバランサで使用される場合、証明書マップエントリは、Compute Engine SSL 証明書などの他の証明書よりも優先されます。
証明書マップを使用すると、証明書の選択ロジックを構成することもできます。たとえば、ハンドシェイク中にクライアントのホスト名がプロビジョニングされた証明書マップのエントリと一致しない場合、ロードバランサはプライマリ証明書を返します。
適切なドメイン認証タイプを選択する
Google マネージド証明書を発行するには、ロードバランサ認証または DNS 認証を使用してドメインの所有権を証明します。
次の表に、各アプローチの考慮事項を示します。
| 機能 | ロードバランサ認証 | DNS 認証 |
|---|---|---|
| 設定の複雑さ | 追加の構成手順や DNS 構成の変更は必要ありません。 | DNS 認証を作成し、対応する CNAME レコードを DNS 構成に追加する必要があります。 |
| ネットワーク セキュリティ | ロードバランサには、証明書によって提供されるすべてのドメインの DNS 構成を含め、ポート 443 でインターネットから完全にアクセス可能である必要があります。ロードバランサ認証は他の構成では機能しません。 |
DNS 認証は、443 以外のポートやターゲット プロキシの前にある CDN レイヤなど、非常に複雑な構成で動作します。 |
| プロビジョニングの速度 | プロビジョニング速度の向上。証明書のプロビジョニングは、ロードバランサが完全に設定され、ネットワーク トラフィックの処理が行われるようになった後にのみ行えます。 | ターゲット プロキシがネットワーク トラフィックを処理できるようになる前に、証明書をプロビジョニングできます。 |
| ワイルドカード証明書 | サポートされていません。 | サポート対象 |
セルフマネージド証明書のローテーションを自動化する
Google マネージド証明書とは異なり、セルフマネージド証明書は有効期限が切れる前に手動で置き換える必要があります。このプロセスは、任意の証明書ライフサイクル管理（CLM）サービスを使用して自動化することをおすすめします。これにより、エラーやダウンタイムを減らし、運用効率を確保できます。
証明書マップを使用して、シームレスな証明書のローテーションをオーケストレートすることもできます。このプロセスには次の手順が含まれます。
- Cloud Monitoring とアラートを使用して、証明書の有効期限をモニタリングします。15 ～ 30 日以内に期限切れになる証明書のアラートを作成することをおすすめします。
- 証明書署名リクエスト（CSR）と秘密鍵を生成して、CA に送信します。
- CSR と秘密鍵を CA に送信し、新しい証明書を取得します。
新しい証明書を Certificate Manager の適切な証明書マップにアップロードします。
- 新しい証明書のドメイン名が期限切れ間近の証明書と一致する場合は、既存の証明書リソースで
UpdateCertificateメソッドを使用します。 - 新しい証明書のドメイン名が異なる場合は、まず新しい PEM（プライバシー強化メール）ファイルで
CreateCertificateRequestメソッドを使用して作成します。次に、UpdateCertificateMapEntryメソッドを使用して、証明書マップ内の古い証明書の参照を新しい証明書に置き換えます。
重要: このプロセスは、ダウンタイムが発生しないように 1 回の API 呼び出しで完了する必要があります。
- 新しい証明書のドメイン名が期限切れ間近の証明書と一致する場合は、既存の証明書リソースで
適切なアクセス制御を適用する
アクセス制御を構成する際は、最小権限の原則と職掌分散を検討することをおすすめします。以降のセクションでは、これらの推奨事項について詳しく説明します。
最小権限の原則を適用する
証明書を管理する権限を割り当てる場合は、最小権限の原則を考慮し、タスクの実行に必要な最小限の権限を付与します。基本 IAM ロールは使用しないことを強くおすすめします。代わりに、事前定義またはカスタムの Certificate Manager ロールと CA Service ロールを付与して、過剰な権限によるアクセスに関連するセキュリティ インシデントのリスクを軽減します。
職掌分散を計画する
証明書管理者と、証明書発行者または証明書リクエスト担当者のロールを持つユーザーの ID と権限は、個別に管理することをおすすめします。これを行うには、ユーザーのリソース階層の上部に個別の管理者グループとリクエスト元グループを作成します。
管理者グループが次の操作を実行できるようにします。
- CA プロビジョニングなどの証明書インフラストラクチャを管理および維持します。
- 証明書テンプレートを構成する。
- 証明書失効リスト（CRL）と Online Certificate Status Protocol（OCSP）レスポンダを管理します。
- CA のセキュリティ ポリシーを実装する。
ルート CA をホストするプロジェクトでは、オーナー（roles/owner）、編集者（roles/editor）、CA Service 管理者（roles/privateca.admin）などの基本ロールをユーザーまたはグループに割り当てないでください。この方法により、誤った削除、構成ミス、過剰な公開を防ぐことができます。代わりに、ルート CA のインストールと構成が完了したら、必要に応じて Privileged Access Manager（PAM）を使用して、正当な理由と承認を伴うジャストインタイム（JIT）アクセスを使用します。
リクエスト元グループが、事前定義されたテンプレートに基づいて証明書リクエストを処理し、証明書を発行する日常業務を担当していることを確認します。
次の表は、さまざまなジョブ機能に通常関連付けられている IAM ロールを示しています。
| ペルソナ | 説明 | IAM ロール |
|---|---|---|
| 証明書管理者 | CA と証明書のインフラストラクチャを設定して管理する。 | Certificate Manager オーナー（roles/certificatemanager.owner）、CA Service 管理者（ roles/privateca.admin） |
| 証明書リクエスタ | ワークロードの証明書をリクエストする。 | Certificate Authority Service 証明書リクエスト元（roles/privateca.certificateRequester） |
| ワークロード（自動化サービス アカウント） | ワークロードまたはパイプラインで証明書をリクエストするために使用されます。 | Certificate Authority Service ワークロード証明書リクエスト元（roles/privateca.workloadCertificateRequester） |
| セキュリティ エンジニアまたは PKI オーナー | 証明書ポリシー、取り消し、ライフサイクルを管理します。 | CA Service オペレーション マネージャー（roles/privateca.caManager）、Certificate Authority Service Certificate Manager（roles/privateca.certificateManager） |
| DevOps エンジニアまたはプラットフォーム エンジニア | ロードバランサでの証明書のデプロイなどを管理します。 | Certificate Manager 編集者（roles/certificatemanager.editor） |
| 監査者またはコンプライアンス | 証明書とその使用状況をモニタリングします。 | Certificate Manager 閲覧者（roles/certificatemanager.viewer）、Certificate Authority Service 監査者（roles/privateca.auditor） |
マルチリージョン デプロイとマルチクラウド デプロイにプロジェクトごとの DNS 認証を使用する
プロジェクトごとの DNS 認証アプローチを使用して、複数のリージョン、複数のクラウド、ソフトウェア開発ライフサイクル（SDLC）にわたるプロジェクトの複数の認証を個別に管理することをおすすめします。
DNS 認証を区分化すると、各プロジェクトが独自の DNS レコードと権限を維持できます。このレベルの制御により、各プロジェクトは他のプロジェクトのオペレーションに干渉したり、影響を受けたりすることなく、DNS 構成を自律的に管理できます。たとえば、開発チームは、本番環境システムや他の進行中のプロジェクトに悪影響を及ぼすことなく、特定のアプリケーションの新しい DNS 構成を試すことができます。
CAA レコードを使用してドメインを保護する
認証局認可（CAA）レコードは、ドメイン ネーム システム（DNS）のセキュリティ メカニズムです。CAA レコードを使用すると、ドメイン所有者は、ドメインの証明書を発行できる Public Certificate Authority を完全に制御できます。このコントロールは、証明書の不正な発行を防ぐうえで重要です。CAA を導入すると、不正な証明書の攻撃対象領域が縮小され、ウェブサイトのセキュリティが効果的に向上します。
Google マネージド証明書の場合、証明書の作成と更新のリクエストの信頼性を高めるために、次の項目を手動で承認することをおすすめします。
Cloud Logging、Cloud Monitoring、可視性
以降のセクションでは、監査ロギングと、証明書の使用状況と有効期限のモニタリングに関するベスト プラクティスについて説明します。
監査ロギングを有効にして集約する
組織のすべてのリソースをモニタリングするには、Certificate Manager を含むすべてのサービスの管理アクティビティ監査ログを一元化されたロケーションに集約します。
これにより、セキュリティ チームや監査者は、Certificate Manager と CA Service のリソースの作成または変更に関連するすべてのアクティビティを 1 か所で確認できます。集約ログの構成の詳細については、組織のログを集約して保存するをご覧ください。
証明書の使用状況と有効期限をモニタリングする
ルート CA の使用状況、証明書の有効期限、証明書の削除など、重要な Certificate Manager イベントに対してログベースのアラートを設定することをおすすめします。これらのアラートは、証明書作成の失敗率が高いなどのオペレーションのトリアージに役立ちます。また、新しい証明書をリクエストするか、割り当てを増やすダウンストリーム プロセスをトリガーできます。
権限関連のオペレーションに対して、次のログアラートとポリシーを構成します。
コンプライアンス要件
通常、コンプライアンス フレームワークでは、特定のプロダクトや構成ではなく、証明書管理に関する一般的な期待値と目標が指定されます。
たとえば、Payment Card Industry データ セキュリティ基準（PCI DSS）とアメリカ国立標準技術研究所（NIST）では、組織が署名鍵のローテーション期間を文書化して実装することが求められています。また、インベントリと、カード会員データを保護するすべての信頼できる署名鍵と証明書の継続的なモニタリングも義務付けています。
Google Cloud サービスがさまざまなコンプライアンス フレームワークの要件を満たす方法については、次のリソースをご覧ください。