AlloyDB Omni 客戶有責任設定及操作 AlloyDB Omni，確保工作負載能充分發揮服務價值。
| 圖層 | Google 的責任 | 客戶的責任 | |
|---|---|---|---|
| 硬體和主機 | 實體基礎架構 | 提供最低和建議規格 (如適用) | 佈建實體伺服器、VM 或邊緣裝置，例如電源、冷卻和硬體。 |
| 主機作業系統 (OS) | 提供最低和建議規格 (如適用) | 管理 Linux 核心、套用 OS 安全性修補程式，以及強化主機節點。 | |
| Kubernetes | 叢集管理 | 提供最低和建議規格 (如適用) | 按照業界標準最佳做法，每天管理叢集 (包括升級)。 |
| 儲存空間 (CSI/PV) | 提供最低和建議規格 (如適用) | 佈建儲存空間類別，並管理底層裝置。AlloyDB Omni 需要區塊裝置，因此請務必選擇區塊裝置類別。 | |
| 網路 (CNI) | 提供最低和建議規格 (如適用) | 佈建及管理網路層，例如 Pod 網路、Ingress 控制器、負載平衡器，以及節點之間的防火牆規則。 | |
| 角色式存取控管 (RBAC) | 提供 AlloyDB Omni Kubernetes 運算子所需的服務帳戶、角色和角色繫結。 | 將這些角色型存取控管 (RBAC) 規則套用至叢集，並確保這些規則符合內部安全政策。如要存取 AlloyDB Omni 資源，請建立其他 RBAC 角色和角色繫結。 | |
| 密鑰管理 | 讀取標準 Kubernetes 密鑰，以佈建資源，例如初始 postgres 使用者。 |
在叢集中建立、保護及輪替 Kubernetes Secret。 | |
| 憑證管理功能 | 依賴標準 Kubernetes Secret 和 cert-manager 進行憑證整合。 |
安裝、設定及管理 cert-manager 的生命週期。 |
|
| 操作員軟體 | 開發與發布 | 開發 AlloyDB Omni 運算子邏輯和 CRD，並發布容器映像檔、Helm 資訊套件和 OLM 組合包。 | 無，您可以將儲存在 Artifact Registry 中的構件用於部署作業。 |
| 安裝和生命週期 | 提供文件和升級構件。 | ||
| 資料庫引擎 | 資料庫二進位檔 | 提供 AlloyDB Omni 容器映像檔，其中包含資料欄引擎和 AI 加速等專有最佳化功能。 | 無 |
| 修補 | 發布引擎的安全性修補程式，以及次要和主要版本更新。提供升級操作說明。 | 視每個版本的重大程度，盡快安排升級。 | |
| 使用者管理 |
|
|
|
| 資料管理 | 備份 | 提供 `BackupPlan` 和 `Backup` CRD，以及管理備份的邏輯，這些備份會透過 pgBackrest 使用與 S3 相容的整合功能進行管理。 |
設定備份時間表和保留期限，並佈建本機、S3 或 Cloud Storage 目標儲存空間值區。 |
| 高可用性 (HA) | 提供自動容錯移轉邏輯和修復機制。 | 佈建足夠的節點和區域，以提供待命目標來支援容錯移轉。 | |
| 加密 (靜態資料) | 支援透明資料加密 (TDE)。 | 管理儲存層加密，確保符合您的需求。 | |
| 加密 (傳輸中) | 為內部運算子元件提供 mTLS，並為使用者與資料庫的連線設定伺服器端 TLS。 | 使用安全的 TLS 用戶端連線至資料庫，並管理基礎憑證基礎架構。 | |
| 觀測能力 | 指標 | 使用與 Prometheus 相容的端點，公開內部資料庫指標。 | 使用 Prometheus、Open Telemetry 或其他相容的解決方案及其儲存空間堆疊，部署及管理擷取器。監控系統的整體健康狀態。 |
| 記錄 | 將 PostgreSQL 和稽核記錄寫入容器磁碟上的檔案，並輪替這些檔案。 | 部署記錄收集工具 (例如 Fluentd 和 Fluent Bit)，將記錄傳送至儲存空間後端 (例如 Splunk 或 ELK)。請確保記錄檔收集器已設定為保留記錄檔，建議至少保留一個月。 | |
| 圖表 | 提供範例指標和記錄資訊主頁，監控標準工作負載。 | 部署及監控視覺化工具 (例如 Grafana) 的健康狀態。建立資訊主頁，並將其納入日常營運工作。 | |
| 警告 | 無 | 管理快訊管道，例如 PagerDuty 整合。 | |
| 支援 | 疑難排解 | 提供軟體錯誤和引擎錯誤的支援。如要取得這項支援服務，您必須訂閱授權。 | 透過說明文件和知識庫提供初步支援。偵錯基礎架構相關問題。 |
安全性和 FIPS 法規遵循
為確保資料安全，AlloyDB Omni 會使用聯邦資訊處理標準 (FIPS) 140-2 或 140-3 驗證的加密編譯模組。Google 和客戶共同承擔 FIPS 法規遵循責任。
下圖顯示 Google 和客戶在 AlloyDB Omni 架構層中，如何分擔 FIPS 法規遵循責任。
下表說明 AlloyDB Omni 的 FIPS 邊界和責任：
| FIPS 邊界層 | 責任 | 說明 |
|---|---|---|
| 符合 FIPS 規範的硬體 | 客戶 | 實體硬體和加密元件必須通過 NIST 認證，並以 FIPS 核准的狀態設定。 |
| Kubernetes 節點作業系統 | 客戶 | 工作節點主機作業系統 (例如 RHEL) 必須以 FIPS 模式執行。必須驗證 FIPS 狀態 (cat /proc/sys/crypto/fips_enabled 會傳回 1)。 |
| Kubernetes 控制層 | 客戶 | 控制層元件 (例如 kubelet) 和網路與儲存空間外掛程式必須使用通過 FIPS 驗證的加密模組，例如使用 Go-BoringCrypto 建構的模組。 |
| AlloyDB Omni 運算子控制器 | 由 Google 開發，以符合 FIPS 標準的基本映像檔 (Red Hat UBI) 為基礎建構，且資料庫執行的容器已啟用 FIPS 標準。 | |
| AlloyDB Omni 容器映像檔 | 使用符合 FIPS 標準的密碼編譯程式庫 (例如 BoringSSL)，並強制執行 FIPS 核准的密碼雜湊演算法 (scram-sha-256) 和傳輸層安全標準 (TLS) 加密套件。 |
|
| 自訂 CA 憑證 | 共用 | 數位憑證必須符合 FIPS 標準的金鑰強度和簽章演算法。憑證鏈結必須追溯至符合 FIPS 標準的根 CA。 |
STIG 共同責任
美國國防資訊系統局 (DISA) 會發布安全性技術實作指南 (STIG)，為軟體、作業系統和資料庫制定網路安全標準和強化要求。這些指南定義了具體的安全參數，可保護系統免於漏洞和網路威脅。
如需完整的 STIG 規則清單，請參閱「AlloyDB Omni STIG 法規遵循」。
根據 STIG 規定強化環境，是在高安全性或政府部門取得營運授權 (ATO) 的必要條件。AlloyDB Omni 預設會導入許多資料庫層級的安全控管措施，但要完全符合 STIG 規範，需要客戶設定及驗證基礎架構層級的設定，因此是共同責任。
下表列出所有需要客戶採取行動、驗證或設定的 STIG 弱點 ID。如需完整資訊，請參閱 Red Hat Enterprise Linux 安全技術實作指南 (STIG) 合規性檢查清單中的 PostgreSQL 9.x。
| STIG 或 SRG ID | 安全控管措施說明 | 平台和電信業者預設行為 | 客戶必須採取行動或進行設定 |
|---|---|---|---|
| V-233535 | 稽核記錄失敗時，立即通知支援人員。 | 標準錯誤診斷資訊會寫入 stdout 和 stderr 容器。 |
顧客必須設定 SIEM 或記錄轉送器指標 (例如 Splunk/Elastic 警示)，才能在擷取量下降時觸發警示。 |
| V-233599 | 稽核儲存空間達到 75% 容量時，通知支援人員。 | 檔案系統指標會透過標準 Prometheus 端點公開。 | 客戶必須在 Prometheus 和 Grafana 中設定快訊規則，才能在磁碟空間超過 75% 時通知支援團隊。/obs/ |
| V-233610 | 將稽核資料卸載至獨立的連續記錄設施。 | 稽核記錄會持續寫入 /obs/diagnostic/ 磁碟區。 |
顧客必須設定記錄轉送器 (例如 FluentBit 和 Vector)，才能將記錄檔持續串流至中央 SIEM。 |
| V-233603 | 請只信任由公開金鑰基礎架構 (PKI) 或核准的憑證授權單位 (CA) 核發的實體憑證。 | 運算子會使用 cert-manager 設定本機 TLS 設定。 |
客戶必須向營運商提供 PKI 根憑證和中繼 CA 憑證，才能建立信任鏈。 |
| V-233520 | 強制執行核准的邏輯存取授權。 | 拒絕純文字密碼和訊息摘要演算法 5 (MD5)。允許透過 SSL 進行 scram-sha-256。 |
客戶必須設定用戶端，在連線字串中使用 SCRAM-SHA-256 和 sslmode=verify-full。 |
| V-233522 | 限制每位使用者的並行工作階段門檻。 | 預設資料庫角色設有無限限制，但受 max_connections 限制。 |
客戶必須明確變更自訂應用程式角色的連線限制 (ALTER ROLE ... CONNECTION LIMIT)。 |
| V-233584 | 針對靜態機密資訊，使用 NSA 核准的加密技術。 | 資料庫容器使用安全且強化的 UBI9 基礎層。 | 顧客必須確認基礎 Kubernetes 主機核心已啟用 FIPS 140 模式。 |
| V-233515 | 與 Active Directory (AD) 和輕量型目錄存取通訊協定 (LDAP) 機構層級驗證機制整合。 | 運算子支援自訂驗證設定。 | 客戶必須將 AD 和 LDAP 身分對應至資料庫叢集設定。 |
| V-233583 | 使用通過 FIPS 驗證的加密編譯模組進行雜湊。 | 容器依賴主機 OpenSSL FIPS 模組執行雜湊函式。 | 顧客必須在主機 VM 節點上啟用 FIPS 模式。 |
| V-233585 | 使用通過 FIPS 驗證的加密技術，保護未分類資訊。 | 使用符合 FIPS 規範的密碼編譯演算法加密通訊和儲存空間。 | 客戶必須驗證主機節點是否通過 FIPS 驗證。 |
| V-233619 | 針對所有作業使用通過 FIPS 驗證的加密編譯模組。 | 強制執行 UBI9 FIPS 就緒容器映像檔二進位檔。 | 顧客必須在主機核心上啟用 FIPS 模式。 |
| V-233623 | 確認 DBMS 在主機上執行時，使用通過認證的 OpenSSL FIPS。 | 資料庫 Pod 依賴主機 OpenSSL FIPS 設定。 | 客戶必須確認主機 OpenSSL 符合 NIST 認證的 FIPS 清單。 |
| V-233615 | 將 PKI 驗證的識別資訊對應至相關聯的使用者帳戶。 | 運算子會使用安全的 SCRAM-SHA-256 密碼驗證機制來驗證身分。 |
如果客戶不使用直接密碼登入，就必須將外部機構目錄角色對應至資料庫角色。 |
| V-233540 | 限制只有授權使用者才能使用資料庫安裝帳戶。 | 容器會將檔案權限和執行作業限制為 postgres 使用者。 |
客戶必須鎖定主機節點存取權 (SSH/Kubectl)，防止未經授權的終端機存取 Pod。 |