作为 AlloyDB Omni 客户，您负责配置和操作 AlloyDB Omni，以确保您的工作负载从该服务中获得最大价值。
| 图层 | Google 的责任 | 客户责任 | |
|---|---|---|---|
| 硬件和主机 | 物理基础设施 | 在适用情况下提供最低要求和推荐要求 | 预配物理服务器、虚拟机或边缘设备，例如电源、冷却和硬件。 |
| 主机操作系统 (OS) | 在适用情况下提供最低要求和推荐要求 | 管理 Linux 内核、应用操作系统安全补丁并强化主机节点。 | |
| Kubernetes | 集群管理 | 在适用情况下提供最低要求和推荐要求 | 按照行业标准最佳实践，每天管理集群（包括升级）。 |
| 存储空间 (CSI/PV) | 在适用情况下提供最低要求和推荐要求 | 预配存储类别并管理底层设备。AlloyDB Omni 需要块设备，因此请务必选择块设备类。 | |
| 网络 (CNI) | 在适用情况下提供最低要求和推荐要求 | 预配和管理网络层，例如 pod 网络、Ingress 控制器、负载平衡器以及节点之间的防火墙规则。 | |
| 基于角色的访问权限控制 (RBAC) | 提供 AlloyDB Omni Kubernetes 操作器所需的服务账号、角色和角色绑定。 | 将这些基于角色的访问权限控制 (RBAC) 规则应用于集群，并确保它们与内部安全政策保持一致。如需访问 AlloyDB Omni 资源，请创建额外的 RBAC 角色和角色绑定。 | |
| 密钥管理 | 读取标准 Kubernetes Secret 以预配资源，例如初始 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、OpenTelemetry 或其他兼容的解决方案及其存储堆栈部署和管理抓取工具。监控系统的整体运行状况。 |
| 日志记录 | 将 PostgreSQL 和审核日志写入容器中的磁盘文件，并轮替这些文件。 | 部署日志收集器（例如 Fluentd 和 Fluent Bit），将日志发送到存储后端（例如 Splunk 或 ELK）。确保将日志收集器配置为保留日志至少一个月（推荐）。 | |
| 可视化 | 提供示例指标和日志信息中心，以监控标准工作负载。 | 部署和监控可视化工具（例如 Grafana）的运行状况。创建信息中心并将其纳入日常运营任务。 | |
| 提醒 | 无 | 管理提醒流水线，例如 PagerDuty 集成。 | |
| 支持 | 问题排查 | 提供软件 bug 和引擎错误方面的支持。如需获得此 支持，您需要订阅许可。 | 通过文档和知识库提供初始支持。调试与基础架构相关的问题。 |
安全性和 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。如需了解全面信息，请参阅 PostgreSQL 9.x on Red Hat Enterprise Linux Security Technical Implementation Guide (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) 颁发的终端实体证书。 | 操作器使用 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。 |