作为 AlloyDB Omni 客户，您负责配置和操作 AlloyDB Omni，以确保您的工作负载从该服务中获得最大价值。
| 图层 | 由 Google 负责 | 客户责任 | |
|---|---|---|---|
| 硬件和主机 | 物理基础设施 | 在适用的情况下提供最低要求和推荐要求 | 预配物理服务器、虚拟机或边缘设备，例如电源、冷却和硬件。 |
| 主机操作系统 (OS) | 在适用的情况下提供最低要求和推荐要求 | 管理 Linux 内核、应用操作系统安全补丁并强化主机节点。 | |
| 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 操作器逻辑和 CRD，并发布容器映像、Helm 图表和 OLM 软件包。 | 无。您可以将存储在 Artifact Registry 中的工件用于 部署。 |
| 安装和生命周期 | 提供文档和升级工件。 | ||
| 数据库引擎 | 数据库二进制文件 | 提供具有专有优化（例如列式引擎和 AI 加速）的 AlloyDB Omni 容器映像。 | 无。 |
| 修补 | 发布引擎的安全补丁以及次要和主要版本更新。提供升级说明。 | 根据每个版本的严重性，尽快安排升级。 | |
| 用户管理 |
|
|
|
| 数据管理 | 备份 | 提供 `BackupPlan` 和 `Backup` CRD 以及用于管理备份的逻辑，
这些备份使用 pgBackrest 和与 S3 兼容的
集成进行管理。 |
配置备份时间表和保留期限，并预配本地、S3 或 Cloud Storage 目标存储桶。 |
| 高可用性 (HA) | 提供自动故障切换逻辑和修复机制。 | 预配足够的节点和可用区，以提供备用目标来支持故障切换。 | |
| 加密（静态） | 提供对 透明数据加密 (TDE) 的支持。 | 管理存储层加密，确保其满足您的要求。 | |
| 加密（传输中） | 为内部操作器组件提供 mTLS，并为用户到数据库连接配置服务器端 TLS。 | 使用安全的 TLS 客户端连接到数据库，并管理底层证书基础架构。 | |
| 可观测性 | 指标 | 使用与 Prometheus 兼容的端点公开内部数据库指标。 | 使用 Prometheus、OpenTelemetry 或其他兼容的解决方案及其存储堆栈部署和管理爬取工具。监控系统的整体运行状况。 |
| 日志记录 | 将 PostgreSQL 和审核日志写入容器中磁盘上的文件，并轮换这些文件。 | 部署日志收集器（例如 Fluentd 和 Fluent Bit），将日志发送到存储后端（例如 Splunk 或 ELK）。确保将日志收集器配置为保留日志至少一个月（建议）。 | |
| 可视化 | 提供示例指标和日志信息中心，以监控标准工作负载。 | 部署和监控可视化工具（例如 Grafana）的运行状况。创建信息中心并将其纳入日常运营任务。 | |
| 提醒 | 无 | 管理提醒流水线，例如 PagerDuty 集成。 | |
| 支持 | 问题排查 | 提供针对软件错误和引擎错误的支持。如需获得此 支持，您需要订阅许可。 | 通过文档和知识库提供初始支持。调试与基础架构相关的问题。 |
安全性和 FIPS 合规性
为确保数据安全，AlloyDB Omni 使用通过联邦信息处理标准 (FIPS) 140-2 或 140-3 验证的加密模块。FIPS 合规性是 Google 与客户之间的责任共担。
下图展示了 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），并针对密码哈希 (scram-sha-256) 和 TLS 加密套件强制执行 FIPS 批准的算法。 |
|
| 自定义 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 中设置提醒规则，以便在 /obs/ 磁盘可用空间超过 75% 时通知支持人员。 |
| V-233610 | 将审核数据卸载到单独的持续日志记录设施。 | 审核日志会持续写入 /obs/diagnostic/ 卷。 |
客户必须配置日志转发器（例如 FluentBit 和 Vector），以便将日志文件持续流式传输到中央 SIEM。 |
| V-233603 | 仅信任由公钥基础架构 (PKI) 或批准的证书授权机构 (CA) 颁发的最终实体证书。 | 操作器使用 cert-manager 配置本地 TLS 配置。 |
客户必须向操作器提供其 PKI 根 CA 证书和中间 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 模块来实现哈希函数。 | 客户必须在主机虚拟机节点上启用 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。 |