安全性公告

選取說明文件版本：

如要評估 AlloyDB Omni Kubernetes 部署項目的資安態勢，並規劃控制層和資料庫叢集升級，請參閱本頁面的安全政策、運算子架構、角色式存取控管 (RBAC) 和安全性背景資訊，以及常見安全漏洞與揭露事項 (CVE) 揭露做法。

如要在動態消息閱讀器中接收最新的 AlloyDB Omni 版本資訊和安全性更新，請訂閱 AlloyDB Omni 版本資訊動態消息。

運算子架構和安全性背景資訊

Kubernetes 上的 AlloyDB Omni 會將 Kubernetes 控制層與處理應用程式查詢的資料庫引擎 Pod 分離：

  • 控制層和 operator 元件：每個 AlloyDB Omni operator 版本都包含 10 個容器映像檔，這些映像檔是以 Red Hat Universal Base Image 9 (UBI 9) 建構：
    • operator/fleet-operator：機群層級 Kubernetes 控制器，可協調 DBCluster 和機群自訂資源
    • operator/local-operator：執行個體層級的 Kubernetes 控制器，可管理本機資料庫 Pod 生命週期，且只會與受信任的叢集內部 Kubernetes API 伺服器通訊
    • alloydbomni-operator-catalog 和 alloydbomni-operator-olm-bundle：Red Hat OpenShift Operator Lifecycle Manager (OLM) 目錄索引和宣告式套件中繼資料映像檔
    • operator/dbinit 和 operator/backupinit：用於資料庫啟動、備份和還原工作流程的暫時初始化容器
    • operator/alloydbomni-monitor (取代 monitoring-agent)、operator/g-pgbouncer、operator/logrotate 和 operator/node-manager：隨附的 Sidecar 和 Node Manager 容器，用於健康狀態探測、連線集區、記錄輪替和儲存空間管理
  • RBAC 和安全性情境：AlloyDB Omni operator 會使用限定範圍的 Kubernetes Role 和 ClusterRole 權限，協調目標命名空間中的自訂資源，並在受限的容器安全性情境中執行控制層和 sidecar 工作負載。
  • 資料庫引擎 Pod：由運算子管理的資料庫執行個體，會執行獨立 AlloyDB Omni 資料庫核心容器映像檔。如要確認您的運算子版本支援哪些資料庫核心版本，請參閱「選擇相容的 Kubernetes 運算子和資料庫叢集版本」。

範圍和嚴重性篩選

為確保修復工作流程著重於可採取行動的安全諮詢，並減少掃描器雜訊，AlloyDB Omni 漏洞摘要和詳細 CVE 記錄會遵循下列回報政策：

  • 嚴格篩選「重大」和「高」嚴重性：安全漏洞摘要表格和詳細 CVE 記錄，只會根據美國國家安全漏洞資料庫 (NVD) 和上游供應商的嚴重性評等，回報「重大」和「高」嚴重性的 CVE。嚴重性為「低」和「中」的公告不會計入摘要計數，也不會列入詳細記錄。
  • 分離的控制層和資料庫核心回報：Kubernetes AlloyDB Omni 的控制層公告會回報 10 個 AlloyDB Omni operator 和邊車容器映像檔特有的安全漏洞。
  • 版本專屬隔離：詳細的 CVE 記錄會使用標準化的 4 欄結構定義 (CVE ID、Severity、Impacted images 和 Mitigated in)，依發布版本整理至專屬子頁面。在每個發布記錄中， Mitigated in 欄則會顯示後續發布版本，代表安全漏洞已在該版本中修復。

安全漏洞評估和更新政策

Google 會定期根據 NVD、Red Hat 安全性資料、Debian 安全性追蹤工具和 Go 安全漏洞資料庫，掃描所有已發布的 AlloyDB Omni 容器映像檔。Google 會在發布新版本時更新 AlloyDB Omni 安全性公告：

  • 已修正的 CVE：先前 AlloyDB Omni operator 控制層容器映像檔中存在的安全漏洞，已在後續 operator 版本中獲得緩解。Google 會將安全性修補程式套用至最新支援的 AlloyDB Omni operator 版本，以及支援的 PostgreSQL 主要版本 18、17、16 和 15 的最新子版本。
  • 已取代的容器映像檔：當新版 AlloyDB Omni operator 緩解舊版中的 CVE 時，Google 會將已取代的容器映像檔摘要標示為已淘汰。請一律部署與最新支援版本對應的操作器和控制層代理程式映像檔。

FIPS 140-3 法規遵循和 CVE 修補

為維持符合聯邦資訊處理標準 (FIPS) 140-3 規範，同時持續修補次要版本和修補程式版本中的安全漏洞，AlloyDB Omni 會將內部通過 FIPS 驗證的加密編譯模組，與外部加密編譯和通訊協定程式庫分離：

  • 密碼編譯模組的 FIPS 驗證：美國國家標準與技術研究院 (NIST) 的密碼編譯模組驗證計畫 (CMVP) 會認證凍結的內部密碼編譯模組或供應商，並核發憑證編號。修改該驗證邊界內的任何指令，都會改變其內嵌的雜湊式訊息驗證碼 (HMAC) 完整性核對和，並使憑證失效。
  • 部署作業符合 FIPS 規範：AlloyDB Omni 部署作業在啟用 FIPS 的主機 OS (例如 Red Hat Enterprise Linux (RHEL) 9，且 /proc/sys/crypto/fips_enabled 檔案設為 1) 上執行時，會以符合 FIPS 140-3 規範的模式運作。在這種模式下，部署作業會透過 FIPS 驗證模組，轉送所有與安全性相關的加密編譯作業，並啟用開機已知答案測試 (KAT) 和 HMAC 完整性檢查。此外，也會強制執行核准的傳輸層安全標準 (TLS) 版本 (TLS 1.2 以上版本)、核准的加密套件，以及 scram-sha-256 密碼驗證方式。AlloyDB Omni operator 容器映像檔和 Red Hat UBI 9 資料庫容器映像檔 (-ubi9) 支援 FIPS，貴組織必須在基礎主機 OS 啟用及驗證 FIPS 模式。詳情請參閱「安全性與 FIPS 法規遵循」。
  • FIPS 邊界外的 CVE 修補：通訊協定剖析和網路程式庫 (例如 TLS 狀態機器、X.509 和 ASN.1 憑證剖析、HTTP/2 和網路 I/O) 位於凍結 FIPS 模組邊界外的外層。由於這些元件位於經過驗證的邊界之外，Google 會在次要版本和修補程式版本中修補外層 CVE，而不會修改內部密碼編譯模組或撤銷其 NIST CMVP 認證。只有在低階密碼編譯原始碼實作本身存在安全漏洞時，才需要更新內部 FIPS 模組。
下表說明 AlloyDB Omni 運算子控制層和邊車容器映像檔的密碼編譯堆疊，包括凍結的內部 FIPS 邊界，以及在各版本中修補的外部密碼編譯和通訊協定層：

密碼編譯堆疊 控制層容器映像檔 二進位檔 內部 FIPS 驗證模組或供應商 外部加密和通訊協定層
使用 GOFIPS140=v1.0.0 建構設定的 Go 內建 FIPS operator/fleet-operator
operator/local-operator
operator/logrotate
operator/node-manager
operator/dbinit
operator/backupinit 		/operator
/local
/logrotate
/nodemgr
dbinit
dbdaemon
credfetcher
backupinit
backupdaemon 		Go 密碼編譯模組 v1.0.0，NIST CMVP 認證編號 5247 Go 標準程式庫套件 crypto/tls、crypto/x509 和 net/http、外部 Go 套件 (例如 golang.org/x/crypto)，以及 Go 執行階段和編譯器
OpenSSL 3 operator/g-pgbouncer /usr/bin/pgbouncer RHEL 9 OpenSSL FIPS 供應商 openssl-libs RPM 套件中的 /lib64/libssl.so.3 和 /lib64/libcrypto.so.3，以及 pgbouncer C 二進位檔
BoringSSL 和 BoringCrypto operator/alloydbomni-monitor /monitoring_agent Go 二進位檔建構工具：boringcrypto Google BoringCrypto 模組 (BCM) 適用於 monitoring_agent 的 Go crypto/tls、crypto/x509 和 net/http 套件

後續步驟