短期憑證與自動化輪換策略

短期憑證概述

短期憑證（Short-Lived Certificates）是一種有效期限較短的數位憑證，通常有效期從數分鐘到數天不等。與傳統憑證動輒一年甚至更長的有效期相比，短期憑證透過頻繁輪換來降低憑證洩漏或遭到濫用的風險。

在現代雲原生架構與零信任安全模型中，短期憑證已成為身份驗證與加密通訊的重要基石。透過自動化的憑證發放與輪換機制，組織可以在不增加營運負擔的情況下，大幅提升安全性。

傳統憑證的問題

長期憑證的風險

傳統的 TLS/SSL 憑證通常具有 1-2 年的有效期限，這種做法存在以下問題：

憑證洩漏風險：一旦私鑰洩漏，攻擊者可以在整個有效期內冒充合法服務
撤銷機制不完善：憑證撤銷清單（CRL）和線上憑證狀態協定（OCSP）在實務上效率不彰
人工管理負擔：手動更新憑證容易出錯，常導致服務中斷
稽核困難：長期憑證使得追蹤和稽核變得複雜

真實案例

許多重大安全事件都與憑證管理不當有關：

2017 年 Equifax 資料外洩事件，部分原因是過期憑證導致入侵偵測失效
多家企業因憑證過期導致服務中斷數小時甚至數天

短期憑證優勢

安全性提升

特性	傳統憑證	短期憑證
有效期限	1-2 年	數分鐘至數天
洩漏影響範圍	長期	極短
撤銷需求	高	低（自然過期）
自動化程度	低	高

核心優勢

降低攻擊窗口：即使私鑰洩漏，攻擊者可利用的時間極為有限
無需撤銷機制：憑證自然過期，避免 CRL/OCSP 的效能與可靠性問題
強制自動化：短期憑證必須透過自動化管理，消除人為錯誤
符合零信任原則：持續驗證，不假設信任

有效期限建議

不同場景的建議期限

根據使用情境，短期憑證的有效期限建議如下：

內部服務間通訊（Service-to-Service）

建議期限：1-24 小時
適用場景：微服務架構、Kubernetes Pod 間通訊
理由：內部網路通訊頻繁，短期憑證可有效防止橫向移動攻擊

使用者認證憑證

建議期限：8-24 小時
適用場景：員工存取內部系統、VPN 連線
理由：配合工作時間，每日重新驗證身份

對外服務（Public-Facing）

建議期限：7-90 天
適用場景：網站 HTTPS 憑證
理由：需考量 DNS 快取、CDN 等因素

期限設定原則

1
最短期限 = 憑證更新週期 × 2 + 緩衝時間

例如：若憑證每 6 小時更新一次，建議有效期限至少為 12-15 小時，確保在更新失敗時有足夠的恢復時間。

自動化發放機制

憑證生命週期管理

完整的自動化憑證管理應包含以下階段：

申請（Request）：服務啟動時自動向 CA 申請憑證
驗證（Validation）：CA 驗證申請者身份
簽發（Issuance）：CA 簽發短期憑證
部署（Deployment）：憑證自動載入至服務
監控（Monitoring）：持續監控憑證狀態
輪換（Rotation）：在過期前自動更新

自動化工具比較

工具	適用場景	特點
cert-manager	Kubernetes	原生整合，支援多種 Issuer
Vault PKI	企業環境	完整的秘密管理解決方案
SPIRE	零信任架構	SPIFFE 標準實作
Certbot	Web 伺服器	Let’s Encrypt 官方工具

SPIFFE/SPIRE 方案

SPIFFE 簡介

SPIFFE（Secure Production Identity Framework For Everyone）是一套用於在異質環境中建立安全身份的開放標準。其核心概念包括：

SPIFFE ID：統一的身份識別格式，如 spiffe://trust-domain/workload-identifier
SVID：SPIFFE Verifiable Identity Document，用於證明身份的文件
Trust Bundle：信任根憑證集合

SPIRE 實作

SPIRE（SPIFFE Runtime Environment）是 SPIFFE 的參考實作，由以下元件組成：

SPIRE Server

負責簽發 SVID
管理信任關係
維護工作負載註冊

SPIRE Agent

部署於各節點
執行工作負載證明（Workload Attestation）
快取與輪換 SVID

部署範例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# SPIRE Server 配置範例
server {
    bind_address = "0.0.0.0"
    bind_port = "8081"
    trust_domain = "example.org"

    ca_ttl = "24h"
    default_svid_ttl = "1h"

    ca_key_type = "ec-p256"
}

plugins {
    DataStore "sql" {
        plugin_data {
            database_type = "postgres"
            connection_string = "..."
        }
    }

    NodeAttestor "k8s_psat" {
        plugin_data {
            clusters = {
                "production" = {
                    service_account_allow_list = ["spire:spire-agent"]
                }
            }
        }
    }
}

Let’s Encrypt 短期憑證

自動化更新策略

Let’s Encrypt 憑證有效期為 90 天，建議在到期前 30 天進行更新。使用 Certbot 可實現自動化：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# 安裝 Certbot
apt-get update
apt-get install certbot

# 申請憑證
certbot certonly --webroot -w /var/www/html -d example.com

# 設定自動更新（透過 cron 或 systemd timer）
# /etc/cron.d/certbot
0 0,12 * * * root certbot renew --quiet --post-hook "systemctl reload nginx"

Kubernetes 整合

在 Kubernetes 環境中，可使用 cert-manager 自動管理 Let’s Encrypt 憑證：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
    - http01:
        ingress:
          class: nginx

---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com-tls
  namespace: default
spec:
  secretName: example-com-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
  - example.com
  - www.example.com
  duration: 2160h    # 90 天
  renewBefore: 720h  # 提前 30 天更新

監控與告警

關鍵監控指標

有效的憑證監控應包含以下指標：

憑證到期時間：距離過期的剩餘時間
更新成功率：自動更新的成功/失敗比例
簽發延遲：從申請到取得憑證的時間
CA 可用性：憑證頒發機構的服務狀態

Prometheus 監控範例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
# Prometheus 告警規則
groups:
- name: certificate-alerts
  rules:
  - alert: CertificateExpiringSoon
    expr: (x509_cert_not_after - time()) / 86400 < 7
    for: 1h
    labels:
      severity: warning
    annotations:
      summary: "憑證即將過期"
      description: "{{ $labels.subject_cn }} 將在 {{ $value | humanizeDuration }} 後過期"

  - alert: CertificateExpired
    expr: x509_cert_not_after < time()
    for: 0m
    labels:
      severity: critical
    annotations:
      summary: "憑證已過期"
      description: "{{ $labels.subject_cn }} 已過期"

  - alert: CertificateRenewalFailed
    expr: increase(cert_renewal_failures_total[1h]) > 0
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "憑證更新失敗"
      description: "過去一小時有 {{ $value }} 次更新失敗"

告警通知策略

到期時間	告警等級	通知方式
< 30 天	資訊	Email
< 7 天	警告	Slack + Email
< 24 小時	緊急	PagerDuty + 電話
已過期	嚴重	全通道告警

部署考量

漸進式導入策略

建議採用以下步驟導入短期憑證：

評估階段
- 盤點現有憑證清單
- 識別關鍵服務與依賴關係
- 評估自動化基礎設施成熟度
試驗階段
- 選擇非關鍵服務進行試點
- 建立監控與告警機制
- 收集效能與可靠性數據
擴展階段
- 逐步推廣至更多服務
- 建立標準化流程與最佳實踐
- 培訓團隊
全面部署
- 所有服務採用短期憑證
- 持續優化與改進

常見挑戰與解決方案

挑戰：CA 單點故障

解決方案：部署高可用 CA 叢集，實施異地備援

挑戰：網路分區導致無法更新

解決方案：延長憑證有效期，實施本地快取機制

挑戰：大規模部署的效能問題

解決方案：分散式 CA 架構，實施憑證預先簽發

挑戰：舊系統不支援自動化

解決方案：使用 sidecar 代理，或建立轉接層