作为 AlloyDB Omni 客户，您负责配置和操作 AlloyDB Omni，以确保您的工作负载从该服务中获得最大价值。
| 图层 | Google 的责任 | 客户责任 | |
|---|---|---|---|
| 硬件和主机 | 物理基础设施 | 提供最低要求和推荐要求（如适用） | 预配物理服务器、虚拟机或边缘设备，例如电源、冷却和硬件。 |
| 主机操作系统 (OS) | 提供最低要求和推荐要求（如适用） | 管理 Linux 内核、应用操作系统安全补丁并强化主机节点。 | |
| Kubernetes | 集群管理 | 提供最低要求和推荐要求（如适用） | 按照业界标准最佳实践，对集群进行日常管理（包括升级）。 |
| 存储空间 (CSI/PV) | 提供最低要求和推荐要求（如适用） | 预配存储类别并管理底层设备。AlloyDB Omni 需要块存储设备，因此请务必选择块存储设备类。 | |
| 网络 (CNI) | 提供最低要求和推荐要求（如适用） | 预配和管理网络层，例如 Pod 网络、Ingress 控制器、负载均衡器和节点之间的防火墙规则。 | |
| 基于角色的访问控制 (RBAC) | 提供 AlloyDB Omni Kubernetes Operator 所需的服务账号、角色和角色绑定。 | 将这些基于角色的访问权限控制 (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) 的支持。 | 管理存储层加密，确保其符合您的要求。 | |
| 加密（传输中） | 为内部 Operator 组件提供 mTLS，并为用户到数据库的连接配置服务器端 TLS。 | 使用安全的 TLS 客户端连接到数据库，并管理底层证书基础架构。 | |
| 可观测性 | 指标 | 使用与 Prometheus 兼容的端点公开内部数据库指标。 | 使用 Prometheus、OpenTelemetry 或其他兼容的解决方案及其存储堆栈部署和管理爬取工具。监控系统的整体运行状况。 |
| 日志记录 | 将 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 节点操作系统 | 客户 | 工作器节点主机操作系统（例如 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 上的 PostgreSQL 9.x 安全技术实施指南 (STIG) 合规性核对清单》。
| 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) 颁发的最终实体证书。 | Operator 使用 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 模块来实现哈希函数。 | 客户必须在主机虚拟机节点上激活 FIPS 模式。 |
| V-233585 | 使用经过 FIPS 验证的加密技术来保护非机密信息。 | 使用支持 FIPS 的密码对通信和存储进行加密。 | 客户必须验证主机节点是否通过 FIPS 验证。 |
| V-233619 | 对所有操作使用经过 FIPS 验证的加密模块。 | 强制执行 UBI9 FIPS-ready 容器映像二进制文件。 | 客户必须在主机内核上启用 FIPS 模式。 |
| V-233623 | 确保 DBMS 在具有经过认证的 OpenSSL FIPS 的主机上运行。 | 数据库 Pod 依赖于主机 OpenSSL FIPS 配置。 | 客户必须验证主机 OpenSSL 是否与 NIST 认证的 FIPS 列表匹配。 |
| V-233615 | 将经过 PKI 身份验证的身份映射到关联的用户账号。 | Operator 使用安全的 SCRAM-SHA-256 密码身份验证。 |
如果客户不使用直接密码登录，则必须将外部组织目录角色映射到数据库角色。 |
| V-233540 | 仅限授权用户使用数据库安装账号。 | 容器将文件权限和执行限制为 postgres 用户。 |
客户必须锁定主机节点访问权限 (SSH/Kubectl)，以防止对 Pod 进行未经授权的终端访问。 |