Certificate Manager

解決する課題

HTTPS を提供するには TLS 証明書が要りますが、その発行・配置・更新・失効監視を自前で回すのは手間でミスも起きやすい領域です。Certificate Manager はこのライフサイクルをマネージドに引き受けます。

• 証明書の有効期限切れでサービスが停止する事故を防ぎたい
• 多数のドメイン・ワイルドカードの証明書を一元管理したい
• 証明書の自動更新をマネージドに任せ、運用負荷を下げたい
• ロードバランサや Cloud Run などに証明書を安全に紐づけたい

主要概念と用語

• 証明書（Certificate）: TLS で使う公開証明書のリソース。Google が発行・更新を管理するマネージド証明書と、利用者が秘密鍵ごと持ち込むセルフマネージド証明書の2種類がある
• マネージド証明書: Google が認証局と連携して発行し、有効期限前に自動更新する証明書。ドメイン所有の検証が完了すると有効になる
• セルフマネージド証明書: 外部の認証局などで取得した証明書と秘密鍵を利用者がアップロードする方式。更新も利用者の責任
• 証明書マップ（Certificate Map）: ホスト名（SNI）と証明書を対応づけるルールの集合。1つのロードバランサで多数のドメインを名前で振り分けられる
• 証明書マップエントリ（Map Entry）: 証明書マップ内の1ルール。特定のホスト名や既定（プライマリ）に証明書を割り当てる
• DNS 認証（DNS Authorization）: マネージド証明書のドメイン所有検証を DNS レコードで行う仕組み。ワイルドカード証明書はこの方式が必要
• ロードバランサ認証: ロードバランサ経由の到達性でドメインを検証する従来型の方式
• 証明書発行設定（CA Pool 連携）: プライベート CA（Certificate Authority Service）と組み合わせ、内部用の証明書を発行する設定

仕様・制限・クォータ

• 対象は公開 TLS 証明書の管理。証明書は外部 HTTP(S) ロードバランサや Cloud Run、Cloud Service Mesh などに紐づけて使う
• マネージド証明書の自動更新: Google が有効期限前に自動で更新するため、原則として手動更新は不要
• ワイルドカード証明書: マネージド証明書でワイルドカード（例 アスタリスクとドメイン名）を発行する場合は DNS 認証が必須
• ドメイン検証: マネージド証明書はドメイン所有の検証完了まで有効化されない。DNS 認証ではあらかじめ指定の CNAME レコードを登録しておく
• リージョン/グローバル: 証明書はグローバル、またはリージョン（リージョナルなロードバランサ向け）に作成する。利用先のロードバランサの種別とロケーションを合わせる必要がある
• クォータ: プロジェクトあたりの証明書数・証明書マップ数・マップエントリ数などに上限があり、必要に応じて引き上げを申請できる

内部の仕組み

マネージド証明書では、ドメイン所有の検証と証明書の自動更新を Google が代行します。

1. 利用者が管理対象ドメインの証明書リソースを作成する
2. DNS 認証の場合、Certificate Manager が検証用の CNAME レコード値を提示し、利用者が DNS にそのレコードを登録する。ロードバランサ認証の場合は到達性で検証する
3. 検証が通ると Google が連携先の認証局から証明書を発行し、リソースが有効になる
4. 有効期限が近づくと Google が自動で再発行・更新する。DNS 認証のレコードを残しておけば更新も自動で完結する

• 配信時は証明書マップが SNI（クライアントが要求したホスト名）を見て、エントリのルールに従って適切な証明書を選択する
• 証明書の作成・更新・紐づけといった操作は Cloud Audit Logs に記録され、いつ誰が証明書を操作したかを監査できる

設計パターン / ベストプラクティス

• 運用負荷と失効事故を減らすため、原則はマネージド証明書＋自動更新を選ぶ
• マネージド証明書の検証はロードバランサ認証ではなく DNS 認証を基本にすると、ロードバランサ構築前でも検証でき、更新も自動化しやすい
• 多数のドメインを扱うフロントエンドでは証明書マップで振り分け、既定（プライマリ）エントリも用意してフォールバックを確保する
• ワイルドカードと個別ホストを使い分け、証明書を用途・環境（本番/検証）ごとに分離する
• 内部向けやクライアント認証が要る用途はプライベート CA（CA Service）と連携して発行する
• 証明書の操作権限は IAM で最小権限に絞り、検証用 DNS レコードの管理者と運用フローを明確にする

運用・監視

• 証明書の**状態（プロビジョニング中／有効／失敗）**を定期確認し、検証失敗（DNS レコード未登録など）を早期に検知する
• マネージド証明書が有効化されない場合は、DNS 認証の CNAME レコードが正しく登録・伝播しているか、ドメインの指定が一致しているかを確認する
• 証明書の作成・更新・紐づけは Cloud Audit Logs で監査する
• セルフマネージド証明書は自動更新されないため、有効期限を監視し、更新・差し替えの運用を用意する
• ロードバランサで意図した証明書が出ない場合は、証明書マップのエントリとホスト名（SNI）の対応、利用先とのロケーション一致を確認する

コスト

Certificate Manager は、管理する証明書やエントリの規模に応じた料金体系で、マネージド証明書の自動更新そのものに追加費用がかからない範囲が中心です。具体的な単価は変動するため、最新の料金ページで確認してください。

セキュリティ

• 証明書リソースの操作は IAM で最小権限に。発行・差し替えの権限を限られたプリンシパルに絞る
• 秘密鍵を持ち込むセルフマネージド証明書は鍵の保管・配布経路に注意し、可能なら秘密鍵を外に出さないマネージド証明書を優先する
• DNS 認証のレコードを消すと更新に失敗し得るため、検証レコードは恒久的に維持し、DNS の変更管理に組み込む
• 証明書の操作は Cloud Audit Logs で監査し、想定外の発行・差し替えを検知する
• 内部用途やクライアント証明書は**プライベート CA（CA Service）**で発行し、信頼チェーンを組織で統制する

Well-Architected の観点

• セキュリティ: TLS による通信の暗号化を一元管理し、秘密鍵を外に出さないマネージド証明書で漏洩面を縮小。証明書操作は IAM の最小権限と監査ログで統制する
• 運用面: マネージド証明書の自動更新により、有効期限切れによる障害という典型的な運用事故を構造的に排除できる
• 信頼性: 証明書マップに既定エントリを置いてフォールバックを確保し、検証レコードを維持して更新の連続性を保つことで、失効に起因するダウンタイムを防ぐ

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# マネージド証明書のドメイン検証用に DNS 認証を作成
gcloud certificate-manager dns-authorizations create example-dnsauth \
  --domain="example.com"

# 上記で提示された CNAME レコードを DNS に登録した前提で、
# DNS 認証を使うマネージド証明書を作成（ワイルドカードも可）
gcloud certificate-manager certificates create example-cert \
  --domains="example.com,*.example.com" \
  --dns-authorizations="example-dnsauth"

# 証明書の状態を確認（プロビジョニング中か有効か）
gcloud certificate-manager certificates describe example-cert

# SNI でドメインを振り分けるための証明書マップを作成
gcloud certificate-manager maps create example-map

# マップに既定（プライマリ）のエントリとして証明書を割り当て
gcloud certificate-manager maps entries create example-entry \
  --map="example-map" \
  --certificates="example-cert" \
  --hostname="example.com"

# 既存のセルフマネージド証明書（持ち込み）を登録する例
gcloud certificate-manager certificates create imported-cert \
  --certificate-file="cert.pem" \
  --private-key-file="privkey.pem"