憑證管理服務最佳做法

本頁面說明使用 Certificate Manager 和憑證授權單位服務 (CA 服務)，在 Google Cloud 設定及管理憑證的各種最佳做法。本頁說明如何設計憑證管理架構。

閱讀本頁面前，請務必熟悉Certificate Manager 總覽和憑證授權單位服務總覽頁面。

設計憑證管理架構

設計企業憑證管理策略時，必須考量組織的主要用途和憑證的整個生命週期。這些決策會影響成本、營運負擔，以及實作憑證管理功能 (例如核發、撤銷和輪替) 的便利性。

以下各節將說明每項設計選擇的建議做法。

選擇憑證類型

建立憑證時，請務必根據應用程式需求和組織的安全政策，選取適合用途的憑證類型。

如要分析最適合您的憑證類型，請參閱下列流程圖：

以下提供幾個實用的說明文件連結，可協助您瞭解流程圖中提及的主題：

• Google 代管憑證
• 憑證授權單位集區
• 憑證授權單位服務總覽
• 自行管理的憑證

簡化私人 CA 服務階層

建議您盡可能簡化 CA 服務的階層，確保作業和疑難排解程序順利進行。您必須將根憑證授權單位 (CA) 儲存在專屬的 Google 專案中。根 CA 會簽署幾個中繼 CA，再由這些 CA 核發最終憑證。

這種扁平式階層結構可提高透明度、簡化憑證撤銷程序，並降低設定錯誤的機率。雖然 CA 服務是區域性服務，但某個區域的根 CA 可以簽署位於其他區域的從屬 CA。

請遵循 CA 服務階層中的最佳做法，如下圖所示：

• 將根 CA 隔離在專屬的 Google Cloud 專案中，以便簽署核發 CA。

• 在不同專案託管的 CA 集區中建立核發 CA。將這些集區託管於不同專案，並依地理位置 (區域)、軟體開發生命週期 (開發、正式環境、測試) 或特定用途區隔。

• 設定 Certificate Manager，使用可為支援資源核發私人信任憑證的核發 CA 集區。

全面涵蓋主機名稱

建議您確認憑證為服務需要保護的所有網域和子網域提供足夠的主機名稱涵蓋範圍。如果主機名稱涵蓋範圍不足，可能會導致使用者收到安全性警告、服務中斷，以及使用者體驗不佳。

請避免為多個網域使用單一憑證。如果單一憑證無法續約或遭到誤刪，憑證涵蓋的所有網域都會變得不安全。建議您為不同網域建立不同的憑證。

如果您打算日後新增子網域或服務，請使用萬用字元，從一開始就在憑證中加入子網域或服務。舉例來說，*.myorg.example.com 的萬用字元憑證只會保護第一個子網域層級，不會保護更深層的子網域層級，例如 sub.subdomain.myorg.example.com。

使用 Google 代管憑證

為有效管理公開憑證並簡化操作，建議使用 Google 代管的憑證。這種做法可大幅減少作業負擔，自動執行憑證輪替等工作，並消除手動續訂相關風險。

此外，Google 代管憑證可與其他Google Cloud 服務完美整合。Certificate Manager 僅支援Public Certificate Authority (pki.goog) 和 Let's Encrypt CA (letsencrypt.org)，可核發公開信任的 Google 管理憑證。憑證管理工具會根據簽發 CA，提供效期為 45 天或 90 天的 Google 管理憑證：

• 公開 CA 核發的憑證有效期限，正逐步從 90 天縮短為 45 天。現有的 90 天憑證在下次續訂前仍有效。
• Let's Encrypt CA 核發的憑證有效期限為 90 天。

憑證的有效期限約剩三分之一時，Certificate Manager 會自動開始續約程序。45 天憑證會在到期前約 15 天開始續約，90 天憑證則會在到期前約 30 天開始續約。

擴充及改善憑證效能

以下各節說明擴充憑證的最佳做法，以及如何提升憑證相關動作 (例如佈建和更新) 的效能。

為 Certificate Manager 採用分散式部署

請依專案和位置使用 Certificate Manager，也就是說，憑證會與相關聯的資源儲存在相同區域的相同專案中。這項策略可防止不同區域重複使用憑證，並在發生區域性中斷時，有效降低影響，進而提升可靠性。

此外，由於配額和限制是在 Google Cloud 專案層級套用，因此在多個專案中部署 Certificate Manager 可提高整體配額。這是因為在某個專案中使用資源，不會影響另一個專案的可用配額。

使用含有 ECDSA 金鑰的憑證

本節將說明為何建議使用 ECDSA，而非 RSA，做為憑證簽署金鑰的最佳做法。

要使用的金鑰類型

ECDSA P-256 是大多數 TLS 憑證的建議金鑰類型，因為 ECDSA P-256 提供強大的加密編譯安全性、出色的簽署作業效能，以及高效的網路頻寬使用。

以下列舉使用其他憑證金鑰類型的可能原因：

• 如果需要支援不支援 ECDSA 憑證的舊版用戶端，除了 ECDSA P-256 憑證外，您也可以提供 RSA-2048 憑證。
• 如有特定法規遵循要求，必須使用較大的金鑰大小或特定金鑰類型，則可使用 ECDSA P-384、RSA-2048、RSA-3072 和 RSA-4096 金鑰。

選擇 ECDSA 而非 RSA 的原因

ECDSA 的主要優勢在於，相較於 RSA，它能以更小的金鑰提供同等的密碼編譯安全等級。這種效率可轉化為實質的效能和資源優勢。金鑰較小並不代表安全性較弱，ECDSA 是以橢圓曲線離散對數問題為基礎，可為每個金鑰單位提供更強大的安全性，在某些情況下，運算效率也比 RSA 更高。

例如：

• 256 位元 ECDSA 金鑰提供的安全等級與 RSA-3072 金鑰類似。
• 384 位元 ECDSA 金鑰提供的安全等級，高於任何廣泛支援的 RSA 金鑰大小。

ECDSA 的主要優點：

• 效能：ECDSA 簽署作業的運算密集度，明顯低於提供同等安全性等級的 RSA 作業。這可降低 CPU 負載和延遲時間，對於高處理量或延遲敏感系統來說至關重要。

• 效率：較小的金鑰和簽章所需的頻寬和儲存空間較少，特別適合行動裝置和物聯網裝置等資源受限的環境。

您可以建立下列自訂組織政策，強制憑證使用特定金鑰類型。這項功能僅適用於 CA 服務提供的 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 集區內含多個 CA，這些 CA 採用相同的憑證核發政策和 Identity and Access Management (IAM) 政策。使用 CA 集區時，系統會透過負載平衡，並將傳入的憑證要求分配給集區中所有已啟用的 CA，進而提高每秒查詢次數 (QPS)。這樣一來，既能提升效能，也不會影響工作負載或用戶端變更。

CA 集區提供單一端點，用於核發及擷取憑證。您可以使用 CA 集區安全地輪替 CA，避免因憑證過期或遭入侵而導致服務中斷。

使用憑證對應組合

為確保最佳擴充性，建議您搭配支援的資源使用憑證對應組合。憑證對應組合具備擴充性，預設支援數千個憑證項目，並可處理數百萬個憑證。負載平衡器使用憑證對應關係時，會優先採用這些項目，而非其他憑證 (例如 Compute Engine SSL 憑證)。

您也可以透過憑證對應組合設定憑證選擇邏輯。舉例來說，在交握期間，如果用戶端的主機名稱與佈建的憑證對應組合中的任何項目不符，負載平衡器就會傳回主要憑證。

選擇正確的網域授權類型

如要核發 Google 代管憑證，您可以透過負載平衡器授權或 DNS 授權證明網域擁有權。

下表說明每種做法的注意事項：

自動輪換自行管理的憑證

與 Google 代管的憑證不同，自行管理的憑證到期前必須手動更換。建議您使用所選的憑證生命週期管理 (CLM) 產品，自動執行這項程序。這有助於減少錯誤和停機時間，確保作業效率。

您也可以使用憑證對應組合，協調無縫憑證輪替。這項程序包含下列步驟：

1. 使用 Cloud Monitoring 和快訊監控憑證到期日。建議您為接下來 15 到 30 天內即將到期的憑證建立快訊。
2. 產生憑證簽署要求 (CSR) 和私密金鑰，並提交給 CA。
3. 將 CSR 和私密金鑰提交給 CA，然後擷取新憑證。

4. 將新憑證上傳至 Certificate Manager 的適當憑證對應組合。

   • 如果新憑證中的網域名稱與即將到期的憑證相符，請對現有憑證資源使用 UpdateCertificate 方法。
   • 如果新憑證有不同的網域名稱，請先使用 CreateCertificateRequest 方法和新的 PEM (隱私增強郵件) 檔案建立憑證。然後使用 UpdateCertificateMapEntry 方法，將憑證地圖中舊憑證的參照替換為新憑證。

   重要事項：您必須透過一次 API 呼叫完成這項程序，且不得造成任何停機時間。

套用適當的存取控管機制

設定存取控管時，建議您考量最小權限原則和分散權責原則。以下各節將詳細說明這些建議。

套用最小權限原則

指派憑證管理權限時，請考量最小權限原則，授予執行工作所需的最低權限。強烈建議您避免使用基本 IAM 角色。請改為授予預先定義或自訂的 Certificate Manager 和 CA 服務角色，以降低與權限過高存取權相關的安全事件風險。

規劃職責劃分

建議您為憑證管理員和具有憑證簽發者或憑證要求者角色的使用者，分別設定不同的身分和權限。如要這麼做，請在使用者資源階層的頂端，為使用者建立個別的管理員和要求者群組。

請確認管理員群組負責執行下列動作：

• 管理及維護憑證基礎架構，例如 CA 佈建。
• 設定憑證範本。
• 管理憑證撤銷清單 (CRL) 和線上憑證狀態通訊協定 (OCSP) 回應器。
• 為 CA 實施安全性政策。

如果專案託管根 CA，請避免將擁有者 (roles/owner)、編輯者 (roles/editor) 和 CA 服務管理員 (roles/privateca.admin) 等基本角色指派給任何使用者或群組。這種做法可避免意外刪除、設定錯誤和過度曝光。請改用 Privileged Access Manager (PAM)，在安裝及設定根 CA 後，視需要透過正當理由和核准程序，取得即時 (JIT) 存取權。

請確認要求者群組負責處理日常作業，包括處理憑證要求，以及根據預先定義的範本核發憑證。

下表列出通常與各種工作職能相關聯的 IAM 角色：

為多區域和多雲端部署作業使用個別專案的 DNS 授權

建議您採用個別專案 DNS 授權方法，獨立管理多個區域、多個雲端和軟體開發生命週期 (SDLC) 專案的多項授權。

劃分 DNS 授權，可確保每項專案都保有各自的 DNS 記錄和權限。有了這種控制層級，每個專案都能自主管理 DNS 設定，不會干擾其他專案的作業，也不會受到影響。舉例來說，開發團隊可以為特定應用程式實驗新的 DNS 設定，不必擔心對正式系統或其他進行中的專案造成負面影響。

使用 CAA 記錄保護網域

憑證授權單位授權 (CAA) 記錄是網域名稱系統 (DNS) 中的安全性機制。CAA 記錄可讓網域擁有者完整控管，設定可為其網域核發憑證的公開憑證授權單位 (CA)。這項控管措施對於防止未經授權核發憑證至關重要。有了 CAA，詐欺性憑證的攻擊面就會縮小，有效提升網站安全性。

如果是 Google 代管的憑證，建議您手動授權下列項目，確保憑證核發和續約要求能順利完成：

• pki.goog
• letsencrypt.org

Cloud Logging、Cloud Monitoring 和觀測能力

以下各節說明稽核記錄，以及監控憑證使用情形和到期日的最佳做法。

啟用及匯總稽核記錄

如要監控組織的所有資源，請將所有服務 (包括 Certificate Manager) 的管理員活動稽核記錄匯總至集中位置。

這項功能可讓安全團隊或稽核人員集中查看所有與建立或修改 Certificate Manager 和 CA Service 資源相關的活動。如要進一步瞭解如何設定匯總記錄，請參閱「匯總並儲存貴機構的記錄檔」。

監控憑證使用情形和到期日

建議您為重要的 Certificate Manager 事件設定記錄式警告，例如根 CA 使用情形、憑證到期和憑證刪除。這些快訊可協助您分類作業，例如憑證建立失敗率過高，並觸發下游程序，要求新憑證或提高配額。

針對與權限相關的作業，設定下列記錄檔快訊和政策：

• 憑證即將到期
• 過期的公開憑證
• 憑證授權單位將於 30 天後到期
• 憑證建立失敗率過高
• 過期的 CA 憑證
• CA 服務 KMS 金鑰問題

法規遵循規定

一般來說，法規遵循架構會指定憑證管理的高階期望和目標，而非特定產品或設定。

舉例來說，付款卡產業資料安全標準 (PCI DSS) 和美國國家標準暨技術研究院 (NIST) 要求組織記錄並實施簽署金鑰的輪替週期。此外，這些法規也要求持續監控目錄，以及所有用於保護持卡人資料的信任簽署金鑰和憑證。

如要進一步瞭解如何透過 Google Cloud 服務，滿足各種法規遵循架構的要求，請參閱下列資源：

• Google Cloud 法規遵循服務
• CA 服務安全性法規遵循
• 符合 PCI 資料安全標準

後續步驟

• 憑證授權單位服務的最佳做法
• mTLS 部署作業的架構