跳转至

基于所有者(Owner)的 RBAC 功能

在本指南中,我们将深入探讨基于所有者的 RBAC(Owner-Based RBAC)——这是一项专为在同一平台内有多个团队协同工作的大型组织而设计的功能。它允许您根据用户可访问的所有者(Owners)列表,精细调整其对平台内各要素的访问权限。

未采用基于所有者 RBAC 的访问模型

在引入基于所有者的 RBAC 之前,平台采用全组织范围的角色访问控制:

graph TB ORG[🏢 组织<br/>所有资源] subgraph "四种角色 - 全组织访问" ADMIN[👑 Admin<br/>读取 + 写入 + 管理操作<br/>集成、IAM、设置] USER[👨‍💼 User<br/>读取 + 写入<br/>无管理操作] READER[👁️ Reader<br/>只读<br/>所有资源] AUDITOR[🔍 Attack Surface Auditor<br/>通过所有者管理资产<br/>历史角色] end ORG -.->|完全访问| ADMIN ORG -.->|读取+写入| USER ORG -.->|只读| READER ORG -.->|基于所有者的资产| AUDITOR style ORG fill:#95a5a6,color:#fff style ADMIN fill:#e74c3c,color:#fff style USER fill:#3498db,color:#fff style READER fill:#95a5a6,color:#fff style AUDITOR fill:#f39c12,color:#fff

Admin:对所有内容拥有完全的读取和写入访问权限,以及管理操作权限,例如管理集成、IAM 设置和组织配置。

User:对组织内所有资源(资产、扫描、工单)拥有读取和写入访问权限。无法执行更改集成或 IAM 设置等管理操作。

Reader:对组织内所有资源拥有只读访问权限。非常适合需要可见性而无需修改权限的利益相关者。

Attack Surface Auditor:已通过所有者管理资产访问权限的历史角色。此角色已被弃用,即将被移除。

面临的问题:组织内的每个人都可以查看所有内容,团队之间缺乏隔离边界。在大型多团队环境中,这会产生大量干扰噪音、管理混乱,并可能导致团队间的操作冲突。

基于所有者的 RBAC 通过增加细粒度、基于团队的访问控制解决了这一问题。

什么是基于所有者的 RBAC?

基于所有者的 RBAC 引入了一个名为“所有者”(Owners)的中间访问层——即代表组织内部各团队的逻辑分组。

graph LR O[📁 所有者<br/>团队分组] -->|分配至| U[👤 用户] O -->|控制| A[📦 资产<br/>应用、域名、IP] O -->|控制| TG[🏷️ 标签<br/>元数据] S[🔍 扫描<br/>安全测试] -->|运行于| A S -->|创建| T[🎫 工单<br/>漏洞] style U fill:#3498db,color:#fff style O fill:#2ecc71,color:#fff style A fill:#f39c12,color:#fff style TG fill:#8e44ad,color:#fff style S fill:#9b59b6,color:#fff style T fill:#e74c3c,color:#fff

其业务流转清晰简单:所有者被分配给用户。所有者控制资产(如移动应用、域名和 IP 地址)以及标签。扫描针对资产运行。扫描完成后,针对发现的漏洞创建工单。访问权限会自动级联传递:如果您拥有某个所有者的访问权限,您将自动获得对其所有资产、标签、扫描和工单的访问权限。未分配所有者的标签仅对组织管理员严格可见。无需手动管理权限。系统支持层级结构——所有者可以具备镜像您组织架构的父子关系。这既构建了自然、易于管理的访问模式,又由平台在后台自动处理复杂的权限计算。

基于所有者 RBAC 中的用户角色

启用基于所有者的 RBAC 后,各角色的权限范围将发生变化:

flowchart TB subgraph roles["角色权限"] A["👑 Admin<br>全组织完全访问权限<br>绕过所有者限制"] B["👨‍💼 User<br>读取 + 写入<br>在分配的所有者范围内<br>无分配所有者 = 完全访问"] C["👁️ Reader<br>只读<br>在分配的所有者范围内<br>无分配所有者 = 完全访问"] D["🔍 Attack Surface Auditor<br>与 User 相同<br>已弃用 - 即将被移除"] end A -. 无限制 .-> ALL["所有资源"] B -. 受限 .-> OWN1["所拥有的资源<br>若未分配所有者则为全部"] C -. 受限 .-> OWN2["所拥有的资源<br>若未分配所有者则为全部"] D -. 受限 .-> OWN3["与 User 相同"] style A fill:#e74c3c,color:#fff style B fill:#3498db,color:#fff style C fill:#95a5a6,color:#fff style D fill:#f39c12,color:#fff,stroke-dasharray: 5 5

Admin:保持不变——对所有资源拥有不受限制的完全访问权限。绕过所有所有者限制。可以执行管理操作,例如管理集成和 IAM 设置。

User:对所分配所有者范围内的资产和标签拥有读取和写入访问权限。可以发起扫描、管理漏洞,并处理其所有者名下资源的工单。重要提示:如果未分配任何所有者,User 将拥有对所有组织资源的完全访问权限。

Reader:对所分配所有者范围内的资产和标签拥有只读访问权限。无法修改任何内容。重要提示:如果未分配任何所有者,Reader 将拥有对所有组织资源的只读访问权限。

Attack Surface Auditor:已弃用的历史角色。当前行为与 User 角色完全一致。将在未来版本中移除——请改用 User 角色。

关键区别:Admin 忽略所有者边界。User 和 Reader 遵循所有者分配规则;而在未分配任何所有者时,则获得完全访问权限。

访问层级结构——权限基石

访问权限通过一条清晰的链条流转:

graph TD O[📁 所有者] -->|1. 分配至| U[👤 用户] O -->|2. 控制| A[📦 资产] O -->|2. 控制| TG[🏷️ 标签] A -->|3. 关联| S[🔍 扫描] S -->|4. 生成| T[🎫 工单] ST[📝 独立工单] -.->|对所有人可见| U style U fill:#3498db,color:#fff style O fill:#2ecc71,color:#fff style A fill:#f39c12,color:#fff style TG fill:#8e44ad,color:#fff style S fill:#9b59b6,color:#fff style T fill:#e74c3c,color:#fff style ST fill:#e67e22,color:#fff,stroke-dasharray: 5 5

第 1 步:将所有者分配给用户——所有访问权限的基石。

第 2 步:所有者控制资产(移动应用、域名、IP 地址)和标签。

第 3 步:针对资产运行扫描。如果您能够访问该资产,您即可访问其扫描记录。

第 4 步:扫描生成工单。如果您能够访问该扫描,您即可访问其生成的工单。

例外情况:独立工单(Standalone Tickets)——脱离扫描手动创建的工单——在全组织范围内对所有用户可见。这确保了重要的安全通知和手动录入的发现能够传达给所有人。

该层级结构建立了与真实安全工作流无缝契合的自动级联访问机制。

所有者层级结构——父子级关系

所有者可以形成层级结构——镜像您组织架构的父子级关系。

graph TD P[👔 工程团队<br/>父级所有者] C1[📱 移动端团队<br/>子级所有者] C2[🌐 Web 团队<br/>子级所有者] P --> C1 P --> C2 C1 --> A1[iOS 应用] C1 --> A2[Android 应用] C2 --> A3[域名] C2 --> A4[API] U1[👤 分配至<br/>工程父级团队的用户] -.->|可见| P U1 -.->|可见| C1 U1 -.->|可见| C2 U2[👤 分配至<br/>移动端子级团队的用户] -.->|仅可见| C1 style P fill:#e74c3c,color:#fff style C1 fill:#3498db,color:#fff style C2 fill:#3498db,color:#fff style U1 fill:#2ecc71,color:#fff style U2 fill:#f39c12,color:#fff

向下访问是核心机制:

分配至父级所有者的用户可以查看所有子级所有者及其资产。非常适合监督管理多个团队的管理者。

分配至子级所有者的用户仅能查看该子级及其资产——无法查看父级或同级团队。这确保了团队成员能够专注于自身职责范围,不会看到无关数据。

示例:如果分配至移动端团队,您将仅能查看移动端资产——无法查看父级工程团队或同级 Web 团队的资产。

如果分配至工程父级团队,您将能够查看工程团队以及所有子团队:移动端和 Web 团队。

此机制具有递归性——祖父母级别可以向下穿透查看孙辈级别。您可以据此构建边界清晰的深层组织架构。

访问权限传递示例——追踪权限链

让我们通过一个真实示例来追踪访问权限的传递过程。

flowchart LR U[👤 Jane] -->|分配至| O[📁 移动端团队] O -->|控制| A1[📱 银行应用] O -->|控制| A2[📱 支付应用] A1 -->|扫描| S1[🔍 扫描 #12345] A2 -->|扫描| S2[🔍 扫描 #12346] S1 -->|发现| T1[🎫 SQL 注入] S1 -->|发现| T2[🎫 XSS] S2 -->|发现| T3[🎫 弱加密] U -.->|✓ 访问| A1 U -.->|✓ 访问| A2 U -.->|✓ 访问| S1 U -.->|✓ 访问| S2 U -.->|✓ 访问| T1 U -.->|✓ 访问| T2 U -.->|✓ 访问| T3 style U fill:#3498db,color:#fff style O fill:#2ecc71,color:#fff style A1 fill:#f39c12,color:#fff style A2 fill:#f39c12,color:#fff

Jane 被分配至 移动端团队 所有者。

移动端团队控制两项资产:银行应用支付应用。Jane 会自动获得对这两项资产的访问权限。

运行扫描:针对银行应用运行 扫描 #12345,针对支付应用运行 扫描 #12346。Jane 能够访问这两项扫描,因为它们运行在其所有者管辖的资产上。

发现漏洞:在银行应用中检出 SQL 注入和 XSS;在支付应用中检出弱加密。Jane 会自动获得对全部三张工单的访问权限。

一次分配 → 访问七项资源。整条权限链全自动流转:用户 → 所有者 → 资产 → 扫描 → 工单。无需任何手动权限配置。

启用基于所有者的 RBAC

要启用基于所有者的 RBAC,首先点击屏幕左上方的菜单按钮。

side_menu_button

然后在菜单中找到“设置”(Settings)。

settings_button

接着点击“组织”(Organization)。

organization_settings

向下滚动,直到找到“启用对象级访问控制”(Enable Object Level Access Control)的开关。

enable_rbac_toggle

如果开关处于关闭状态,平台将使用传统模式,即所有用户均可查看组织内的全部资源。如果打开该开关,将激活全新的基于所有者的 RBAC 系统,根据所有者分配过滤所有查询,并启用所有者分配管理界面。

在本指南中,我们探讨了基于所有者的 RBAC,这是一项专为在同一平台上协作的多团队大型组织打造的高效功能。我们了解了它如何提供基于团队的细粒度访问控制,彻底消除“所有人看到所有内容”带来的噪音与混乱。