Google SecOps扩展受限只读角色：更多调查功能可见，全局访问权限仍需分开核对
2026年9月30日，Google SecOps更新了Chronicle API Restricted Data Access Viewer预定义IAM角色。官方说明，这个受限数据查看者现在包含Chronicle API Viewer提供的全部只读权限，但排除全局数据访问权限chronicle.globalDataAccessScopes.permit。结果是受限用户可以在已分配的数据范围内查看更多安全运营功能，而不必仅为读取调查材料就获得全局范围。
配图为AI生成的概念插图，表现安全调查中的限定范围只读访问，不是Google SecOps真实界面或权限配置截图。
哪些工作更容易串起来
发布说明列举了SOAR案件与playbook、调查、威胁集合、发现项、安全验证及数据接入资源等只读能力。对按部门、客户或业务环境分工的安全团队，这有助于减少一种常见割裂：分析人员能看到日志，却无法在相关功能中查看调查所需的上下文，需要反复请求其他管理员代查。
不过，这次更新扩大的是功能读取权限，并未宣布允许受限查看者修改playbook、执行响应动作或改变数据接入配置。“能查看某项功能”与“可以操作它”需要分别确认。文章中的具体权限范围来自官方更新说明，实际授权还应以对应角色与实例配置为准。
数据范围与功能权限是两层控制
Google把feature RBAC和data RBAC区分开来：前者决定可以使用哪些功能，后者决定这些功能中能接触哪些数据。预定义的受限只读路径需要结合Chronicle API Restricted Data Access角色与Restricted Data Access Viewer角色，前一个标识用户受数据范围约束，后一个提供功能查看能力。
因此，角色名称里有“Restricted”并不足以证明整个账户已经受到预期限制。还需要确认数据范围已经配置和启用、范围分配给了正确用户或群组，以及数据进入系统时带有适用标签。一次权限检查应同时回答“能做什么”和“能看哪部分”，不能只截图一张角色列表就结束。
有全局角色时，局部限制不会把它收回来
官方Data RBAC概览明确指出，全局访问会覆盖范围访问；如果用户同时拥有全局角色和受限角色，仍可访问全局数据。配置文档也提醒，无条件的角色绑定不会被同一角色上的条件绑定覆盖。把受限权限叠加到旧全局授权上，不能实现预想中的收窄。
这对迁移中的企业尤其重要。某些账户可能曾为排障临时获得较广权限，之后又加入按业务划分的群组，看起来已经进入受限流程，实际有效权限仍来自旧绑定。应从用户、所属群组和其他继承路径汇总有效授权，再验证代表性查询。不要为了修复一次“看不到数据”的问题，直接增加全局查看者而不记录原因和退出条件。
启用状态与标签逻辑会影响真实结果
Google说明，在Data RBAC尚未启用时，即使已经分配范围，用户仍拥有全局数据访问。启用前可以先规划部分范围，但“已建好scope”并不等于限制已经生效。对正在分阶段部署访问控制的团队，应把启用时刻和范围验证结果作为正式变更的一部分。
范围由标签定义，同类型允许标签通常以OR组合，不同类型以AND组合；排除标签也有自己的匹配逻辑。多范围分配会扩大用户能接触的数据集合。实际测试可以准备应当可见、应当不可见、同时匹配多个条件三类记录，避免只用一个能成功查询的样本来证明隔离正确。本文建议的是验证方法，不要求为了测试接触真实敏感事件。
预定义角色变化值得纳入权限复核
这次更新对已经使用该预定义角色的组织具有实际意义，因为角色本身的功能覆盖扩大了。安全团队应检查新增可见资源是否与人员职责匹配，并更新内部访问说明。即使数据范围保持不变，可查看的调查材料种类增加，也可能改变日常交接和审计方式。
若组织使用的是自行维护的自定义角色，不能假定它会跟随预定义角色自动得到同样的只读能力。更稳妥的做法是逐项比较需要的权限，在保留数据隔离设计的前提下补齐缺口。官方公告没有要求所有用户改为统一角色，也没有给出一套适合所有组织的授权模板。
费用与落地范围要如实表述
发布说明没有宣布新的独立收费项目，也没有把此次权限更新描述成新的免费安全服务。已有Google SecOps产品、数据用量及合同条款仍需按适用条件核对。它是现有权限模型的能力调整，不能据此推断所有用户已经获得额外产品许可或无限数据访问。
这次更新最直接的受益者，是确实需要跨功能查看调查上下文、又必须遵守数据隔离要求的人员。实施价值要通过两项结果证明：他们可以独立完成被授权的调查阅读，同时无法看到范围之外的信息。把这两项一起验收，才算真正减少协作阻力，而不是悄悄扩大访问面。
官方资料
资料核对：2026年10月3日。以下解读基于官方公告与文档，产品规则以官方后续更新为准。
