Google Cloud在2026年9月7日宣布，Privileged Access Manager正式进入商用阶段。这项服务面向需要临时管理员权限的运维、安全和开发团队，让高权限不必长期绑定在个人账号上，而是在确有任务时申请，并在设定时间结束后自动回收。
对于云服务器、数据库和生产项目，长期保留Owner、管理员或网络管理权限会放大账号泄露和误操作的影响。Privileged Access Manager的价值不是新增一种更高权限，而是把权限提升变成一段有申请理由、有审批记录、有明确期限的受控过程。
长期管理员权限可以改为按需申请
管理员会先创建Entitlement，定义哪些用户可以申请、能够获得什么IAM角色、权限作用在哪个资源范围，以及单次授权最长可以持续多久。申请人真正需要处理故障或执行变更时，再针对这项Entitlement提交Grant请求。
临时授权时长可以短于管理员设定的上限。官方文档给出的可配置范围是30分钟至168小时，申请人不能要求超过Entitlement上限的时间。
核心变化是把默认拥有权限改成需要时才拥有权限。任务完成或期限到达后，系统自动撤销临时角色，减少团队依赖人工记得删除权限的情况。
审批和自动到期形成完整闭环
Entitlement可以设置无需审批直接激活，也可以要求指定人员或群组审核。审批流程能够要求申请人填写用途，也能要求审批人写下批准或拒绝原因，便于后续追踪一次高权限操作为什么发生。
审批人不能批准自己的请求。未安排具体开始时间的请求若在24小时内没有处理，会自动进入Expired状态；预约授权则必须在计划激活时间前完成审批，否则同样会过期。
授权进入Active状态后，Google Cloud通过带时间条件的IAM绑定提供权限。到期后系统自动回收，申请人需要继续工作时必须重新申请，而不是把原来的临时授权无限延长。
组织、文件夹和项目都能设置临时权限
Privileged Access Manager可以在Organization、Folder或Project层级创建Entitlement。授权范围会遵循Google Cloud资源层级，因此在组织层配置的角色可能向下影响多个文件夹和项目，不能只看当前控制台页面判断权限边界。
Google账号、群组以及Workforce Identity Federation等身份都可以纳入申请与审批流程。新版能力也覆盖Workload Identity Federation和Agent Identity等场景，但服务账号或工作负载参与审批时仍要检查组织设置和对应功能状态。
权限范围越高，Entitlement就越应该拆细。只需要管理一个项目或一个存储桶时，不应为了方便直接授予整个组织范围的管理员角色。
审计记录比临时口头授权更完整
每次Grant请求都会留下申请人、理由、审批动作、激活时间和结束状态。管理员可以在Privileged Access Manager界面查看记录，也能结合Cloud Audit Logs追踪授权期间发生的管理操作。
这对生产事故处理尤其有用。团队可以把故障工单号、变更单或值班原因写入申请说明，让临时权限和实际操作处于同一条审计时间线上，而不是事后再询问谁曾经拥有管理员权限。
需要注意，权限激活依赖IAM变更传播，不一定在批准瞬间对所有资源同时生效。紧急流程应把传播时间纳入预案，不能把临时授权当作毫无延迟的开关。
正式商用后仍要先从低风险范围上线
GA代表核心服务达到生产可用状态，但部分扩展能力仍可能处于预览阶段，例如与特定安全套餐相关的多级审批。部署时应分别核对基础功能和附加功能状态，不要把整套能力都视为相同支持级别。
更稳妥的落地方式是先选择一个非关键项目，把常用运维角色改造成Entitlement，验证申请、审批、通知、权限传播和自动回收是否符合预期，再逐步替换生产环境中的长期角色绑定。
企业还应保留受严格控制的紧急账号，防止身份系统或审批链故障时无人能够恢复服务。临时特权访问可以减少常驻权限，但不能代替完整的应急账号、日志和变更管理。
