このページでは、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 サービスの階層で次のベスト プラクティスに従います。
- 発行 CA に署名するために、ルート CA を独自の Google Cloud プロジェクトに分離します。
別々のプロジェクトでホストされている CA プールに発行 CA を作成します。これらのプールを別々のプロジェクトでホストし、地理的位置(リージョン)、ソフトウェア開発ライフサイクル(開発、本番環境、テスト)、特定のユースケースでセグメント化します。
サポートされているリソースに対してプライベートに信頼できる証明書を発行できる発行 CA プールを使用するように Certificate Manager を構成します。
包括的なホスト名カバレッジを使用する
サービスで保護する必要があるすべてのドメインとサブドメインに対して、証明書で十分なホスト名がカバーされていることを確認することをおすすめします。ホスト名のカバレッジが不十分だと、ユーザーにセキュリティ警告が表示されたり、サービスが中断されたり、ユーザー エクスペリエンスが低下したりする可能性があります。
複数のドメインで 1 つの証明書を使用することは避けてください。単一の証明書の更新に失敗した場合や、誤って削除された場合、その証明書が対象とするすべてのドメインが保護されなくなります。異なるドメインには個別の証明書を作成することをおすすめします。
後で新しいサブドメインやサービスを追加する予定がある場合は、ワイルドカード文字を使用して、最初からサブドメインやサービスを証明書に含めます。たとえば、*.myorg.example.com
のワイルドカード証明書は、最初のサブドメイン レベルのみを保護しますが、sub.subdomain.myorg.example.com
などのより深いサブドメイン レベルは保護しません。
Google マネージド証明書を使用する
一般公開証明書を効率的に管理し、使いやすさを確保するため、Google マネージド証明書を使用することをおすすめします。このアプローチにより、運用上のオーバーヘッドが大幅に削減され、証明書のローテーションなどのタスクが自動化され、手動更新に伴うリスクが排除されます。
また、Google マネージド証明書は、他のGoogle Cloud サービスとのシームレスな統合を提供します。Google マネージド証明書の有効期間は 90 日間で、有効期限の約 1 か月前に更新プロセスが開始されます。
証明書のパフォーマンスをスケーリングして改善する
以降のセクションでは、証明書をスケーリングし、プロビジョニングや更新などの証明書関連のアクションのパフォーマンスを向上させるためのベスト プラクティスについて説明します。
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 証明書などの他の証明書よりも優先されます。
証明書マップでは、証明書の選択ロジックを構成することもできます。たとえば、handshake 中にクライアントのホスト名がプロビジョニングされた証明書マップのエントリと一致しない場合、ロードバランサはプライマリ証明書を返します。
正しいドメイン認証タイプを選択する
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)とオンライン証明書ステータス プロトコル(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 )、認証局サービス証明書マネージャー(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 レコードを使用してドメインを保護する
Certification Authority Authorization(CAA)レコードは、ドメイン ネーム システム(DNS)のセキュリティ メカニズムです。CAA レコードを使用すると、ドメイン所有者は、ドメインの証明書を発行できる公開認証局(CA)を完全に制御して構成できます。この制御は、証明書の不正な発行を防ぐうえで重要です。CAA を設定すると、不正な証明書の攻撃対象領域が縮小され、ウェブサイトのセキュリティが効果的に強化されます。
Google マネージド証明書の場合は、証明書の発行と更新リクエストの信頼性を高めるために、次の項目を手動で承認することをおすすめします。
Cloud Logging、Cloud Monitoring、可視性
以降のセクションでは、監査ロギングと、証明書の使用状況と有効期限のモニタリングに関するベスト プラクティスについて説明します。
監査ロギングを有効にして集約する
組織のすべてのリソースをモニタリングするには、Certificate Manager を含むすべてのサービスの管理アクティビティ監査ログを一元的な場所に集約します。
これにより、セキュリティ チームや監査担当者は、Certificate Manager と CA Service のリソースの作成または変更に関連するすべてのアクティビティを 1 か所で確認できます。集約ログの構成の詳細については、組織のログを集約して保存するをご覧ください。
証明書の使用状況と有効期限をモニタリングする
ルート CA の使用状況、証明書の有効期限、証明書の削除など、重要な Certificate Manager イベントに対してログベースのアラートを設定することをおすすめします。これらのアラートは、証明書作成の失敗率が高いなどのオペレーションのトリアージに役立ち、新しい証明書をリクエストするか割り当てを増やすダウンストリーム プロセスをトリガーできます。
権限関連のオペレーションに対して、次のログアラートとポリシーを構成します。
コンプライアンス要件
通常、コンプライアンス フレームワークでは、特定のプロダクトや構成ではなく、証明書管理に関する一般的な期待と目標が指定されます。
たとえば、Payment Card Industry Data Security Standard(PCI DSS)と National Institute of Standards and Technology(NIST)では、署名鍵のローテーション期間を文書化して実装することが求められています。また、インベントリと、カード会員データを保護するすべての信頼できる署名鍵と証明書の継続的なモニタリングも義務付けています。
Google Cloud サービスがさまざまなコンプライアンス フレームワークの要件を満たすのにどのように役立つかについて詳しくは、次のリソースをご覧ください。