数据库权限管理长期存在一个难解的规模问题：权限分得越细，账号开通、密码轮换、员工离职回收和审计的成本就越高；为了降低管理成本而共享高权限账号，又会扩大泄露影响范围，并让审计日志失去具体责任人。
AlloyDB 新增预览版 IAM 组认证后，企业可以把 Google Groups 映射到数据库访问策略。权限不再围绕数千个独立用户逐一配置，而是围绕财务分析、区域运营、生产值班或 AI Agent 等职能组进行管理。这也让 AlloyDB 与 Cloud SQL 形成更统一的无密码访问模型。
从逐人授权转向职能授权
传统的 IAM 数据库认证可以把单个 Google Cloud 身份映射为数据库用户，但在数百个实例和数千名员工的环境中，逐人授权会产生三类持续成本：
- 新员工加入团队后，需要在多个环境和实例中重复开通权限。
- 员工离职或转岗时，很难确认所有数据库入口都已回收。
- 开发、预发布和生产环境中的权限容易逐渐偏离既定策略。
组认证把管理边界上移到了企业身份目录。安全团队可以维护诸如 regional-analysts@company.com、financial-agents@company.com 这样的 Google Group，再把组映射到数据库角色。人员变化由组成员关系吸收，数据库中的授权结构则保持稳定。
AlloyDB 支持最多定义 200 个功能组。这个限制意味着组应该代表稳定的业务职能，而不是为每名用户、每张表或每次临时任务创建一个组。较合理的分层是：
- Google Group 表示“谁属于某项职能”。
- PostgreSQL 角色表示“这项职能可以执行什么操作”。
- IAM Conditions、组织政策和特权访问流程表示“何时、从哪里以及经过什么审批后可以访问”。
AI Agent 为什么更需要具体身份
AI Agent 经常位于用户与数据库之间。如果 Agent 始终使用一个共享服务账号，数据库只能看到这个通用身份。即使最终请求来自不同员工，审计记录也无法准确回答“谁要求 Agent 读取或修改了这些数据”。
更严重的问题是“混淆代理”：用户只具备查看某个区域数据的权限，但 Agent 持有覆盖全部区域的凭据，于是可能代表用户执行其本人无权执行的查询。
更稳妥的架构是让 Agent 保留调用者身份和授权范围，并把对应的用户或组上下文传递到 AlloyDB。数据库仍然是最终授权边界：Agent 负责生成或编排查询，但不能自行扩大访问范围。这样既能限制对象级权限，也能让审计日志记录访问了什么、修改了什么，以及操作代表谁执行。
这里需要区分认证与授权。IAM 组认证解决“连接者是谁、属于哪些组”；表、视图、函数和行级安全策略仍然决定“这个身份能做什么”。仅启用组登录并不会自动形成最小权限模型。
可以这样实践：建立稳定的数据库角色
下面示例使用 PostgreSQL 原生角色和授权语句，适合在 IAM 组主体已经按照当前 AlloyDB 预览版文档完成映射后执行。组主体的具体创建和映射命令可能随预览版接口变化，因此应以所在项目和区域的最新文档为准。
先把以下内容保存为 roles.sql，并把数据库、schema 和表名改成实际值：
\set ON_ERROR_STOP on
-- 稳定的业务角色，不允许直接登录。
CREATE ROLE regional_analyst NOLOGIN;
CREATE ROLE financial_agent_reader NOLOGIN;
GRANT CONNECT ON DATABASE appdb TO regional_analyst;
GRANT USAGE ON SCHEMA reporting TO regional_analyst;
GRANT SELECT ON ALL TABLES IN SCHEMA reporting TO regional_analyst;
ALTER DEFAULT PRIVILEGES IN SCHEMA reporting
GRANT SELECT ON TABLES TO regional_analyst;
GRANT CONNECT ON DATABASE appdb TO financial_agent_reader;
GRANT USAGE ON SCHEMA finance TO financial_agent_reader;
GRANT SELECT ON finance.approved_transactions TO financial_agent_reader;
-- 将已经映射到 AlloyDB 的 IAM 组主体授予业务角色。
-- 引号是必需的，因为主体名称通常包含 @ 和点号。
GRANT regional_analyst TO "regional-analysts@company.com";
GRANT financial_agent_reader TO "financial-agents@company.com";
使用具备角色管理权限的管理员连接执行：
export PGHOST="ALLOYDB_PRIVATE_IP_OR_DNS"
export PGPORT="5432"
export PGDATABASE="appdb"
export PGUSER="database-admin"
psql --set=sslmode=require --file=roles.sql
执行后可以检查角色成员关系和对象权限：
psql --set=sslmode=require <<'SQL'
\du
\dp reporting.*
\dp finance.approved_transactions
SQL
生产环境不要长期向应用授予所有现有及未来表的读取权限，除非这确实是角色职责。对于财务、医疗或多租户数据，可以优先暴露经过筛选的视图，并结合 PostgreSQL 行级安全策略进一步缩小范围。
Agent 接入时的身份约束
Agent 服务不能只接受客户端传来的组名，例如直接相信 X-User-Group: financial-agents。组信息必须来自经过验证的企业身份令牌或服务端身份查询，否则调用者可以伪造权限。
可以把 Agent 的连接流程设计成以下步骤：
- API 网关验证用户身份令牌，并拒绝过期或签名无效的请求。
- 服务端从可信身份上下文获得用户和组成员关系。
- 数据库连接层使用短期 IAM 凭据，而不是保存静态密码。
- AlloyDB 根据用户或组主体完成认证，数据库角色继续执行对象级授权。
- 应用审计日志记录请求 ID、最终用户和 Agent 身份，并与数据库审计记录关联。
不要把“在提示词中告诉模型不要访问敏感表”当作权限控制。提示词属于行为指导，数据库 GRANT、视图和行级安全才是可执行的安全边界。
上线前检查
采用组认证时，可以从一个只读团队和一个非生产实例开始，验证人员加入、转岗、离职以及紧急访问的完整流程。随后再把角色定义模板化，并推广到开发、预发布和生产环境。
上线前至少确认这些事项：
- 组按稳定职能划分，没有退化成大量单人组。
- 每个组对应明确的 PostgreSQL 角色和数据所有者。
- Agent 保留最终用户上下文，不依赖共享高权限账号。
- 静态数据库密码已从代码、CI 变量和密钥库中逐步移除。
- 私网连接、Private Service Connect 或其他网络边界已经启用。
- VPC Service Controls、组织政策和 IAM Conditions 与数据库权限协同生效。
- 审计测试能够从一条数据库操作追溯到具体用户、组、Agent 和请求。
- 已测试组成员移除后的权限传播时间，并为紧急回收制定补偿措施。
IAM 组认证降低的是身份生命周期管理成本，而不是数据库授权设计本身的复杂度。把企业身份、短期凭据、网络边界和 PostgreSQL 最小权限组合起来，才能同时获得工程效率、可追责审计和面向 AI Agent 的可靠访问控制。