身為 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 角色和角色繫結。 | |
| Secret 管理 | 讀取標準 Kubernetes Secret 來佈建資源，例如初始 postgres 使用者。 |
在叢集中建立、保護及輪替 Kubernetes Secret。 | |
| 憑證管理 | 使用標準 Kubernetes Secret 和 cert-manager 整合憑證。 |
安裝、設定及管理 cert-manager 的生命週期。 |
|
| 操作員軟體 | 開發與發布 | 開發 AlloyDB Omni operator 邏輯和 CRD，並發布容器映像檔、Helm chart 和 OLM 套件。 | 無，您可以將儲存在 Artifact Registry 中的構件用於部署作業。 |
| 安裝和生命週期 | 提供文件並升級構件。 | ||
| 資料庫引擎 | 資料庫二進位檔 | 提供 AlloyDB Omni 容器映像檔，並採用資料欄引擎和 AI 加速等專屬最佳化功能。 | 無 |
| 正在套用修補程式 | 發布引擎的安全性修補程式，以及子版本和主要版本更新。提供升級操作說明。 | 視各版本的重要性，盡快安排升級。 | |
| 使用者管理 |
|
|
|
| 資料管理 | 備份 | 提供 `BackupPlan` 和 `Backup` CRD，以及管理備份的邏輯，這些備份是使用 pgBackrest 搭配 S3 相容整合功能管理。 |
設定備份時間表和保留期限，並佈建本機、S3 或 Cloud Storage 目標儲存空間 bucket。 |
| 高可用性 (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 驗證的加密編譯模組。FIPS 法規遵循是 Google 和客戶的共同責任。
下圖顯示在 AlloyDB Omni 的架構層中，Google 和客戶如何分擔 FIPS 法規遵循責任。
下表說明 AlloyDB Omni 的 FIPS 邊界和責任：
| FIPS 邊界圖層 | 責任 | 說明 |
|---|---|---|
| 符合 FIPS 規範的硬體 | 客戶 | 實體硬體和加密元件必須通過 NIST 認證，並以 FIPS 核准的狀態設定。 |
| Kubernetes 節點 OS | 客戶 | worker 節點主機作業系統 (例如 RHEL) 必須在 FIPS 模式下執行。必須驗證 FIPS 狀態 (cat /proc/sys/crypto/fips_enabled 傳回 1)。 |
| Kubernetes 控制層 | 客戶 | kubelet 等控制層元件，以及網路和儲存空間外掛程式，都必須使用通過 FIPS 驗證的加密編譯模組，例如以 Go-BoringCrypto 建構的模組。 |
| AlloyDB Omni operator 控制器 | 由 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。如需完整資訊，請參閱「PostgreSQL 9.x on Red Hat Enterprise Linux Security Technical Implementation Guide (STIG) compliance checklist」。
| STIG 或 SRG ID | 安全控管措施說明 | 平台和電信業者預設行為 | 客戶須採取的行動或設定 |
|---|---|---|---|
| V-233535 | 稽核記錄失敗時，立即通知支援人員。 | 標準錯誤診斷會寫入容器 stdout 和 stderr。 |
客戶必須設定 SIEM 或記錄轉送工具指標 (例如 Splunk/Elastic 警示)，在擷取量下降時觸發。 |
| V-233599 | 稽核儲存空間達到 75% 容量時，通知支援人員。 | 檔案系統指標會透過標準 Prometheus 端點公開。 | 客戶必須在 Prometheus 和 Grafana 中設定警告規則，才能在 /obs/ 磁碟空間超過 75% 時通知支援團隊。 |
| 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) 機構層級驗證機制整合。 | Operator 支援自訂驗證設定。 | 客戶必須將 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。 |