CyberStrikeAI v1.7.0 更新：多人协作下的权限管理（RBAC）

v1.6 更适合个人或小团队快速用起来：单账号、配置简单、功能面已经比较全。
一旦要放进多人协作的实验室、安全团队或甲方运营环境，共享密码和「全员同等权限」就不够用了——
v1.7.0 的重点，是把平台 RBAC 接到 API、Agent、MCP、后台任务和机器人的执行链路上。

一、为什么 v1.7.0 要推 RBAC？

CyberStrikeAI 不是普通的聊天机器人。它能做的事包括：

• 调用 安全工具 与自定义 MCP
• 跑 单 Agent / Deep / Plan-Execute / Supervisor 多代理编排
• 操作 WebShell、内置 C2、批量任务、工作流
• 在 企业微信 / 钉钉 / 飞书 / 个人微信 / Telegram 等 IM 里远程指挥

这里其实有两个常见误区，也是 v1.7.0 要补 RBAC 的原因：

1. 能登录 ≠ 能做所有事
   以前大家共用一个密码，谁登进来谁就是「管理员」：能删别人的对话、能调 C2/WebShell、能改全局配置。
   多人协作时，更合理的是：实习生能看指定项目，但不能删数据；操作员能跑 Agent，但不能改系统配置——登录只证明「你是谁」，RBAC 才决定「你能干什么」。

2. 页面上看不见按钮 ≠ 真的安全
   如果只在前端把「删除」「终端」等按钮藏起来，懂一点技术的人仍可直接调 API。
   v1.7.0 会在服务端对每次 API、Agent 工具调用、机器人消息做权限校验；前端隐藏只是减少误点，真正的拦截发生在服务端。

v1.7.0 引入的平台 RBAC（Role-Based Access Control），目标很直接：

1. 多用户：每人独立账号，告别「全站一个密码」
2. 最小权限：按岗位给权限，而不是全员 admin
3. 数据隔离：项目、对话、漏洞、WebShell、C2 等资源按归属与授权可见
4. 全链路 enforcement：不只管 Web 页面，还管 API、Agent 工具调用、MCP、后台任务、机器人消息

一句话总结：RBAC 管的是「平台授权边界」，不是 Agent 的测试风格。

二、先分清两种「角色」——这是上手 RBAC 的第一关

很多人第一次用会懵：CyberStrikeAI 里本来就有「渗透测试」「CTF」「Web 扫描」等角色，现在又来一套 RBAC 角色，有什么区别？

关键原则：

• 选了「渗透测试」AI 角色，不会自动获得 C2、WebShell、终端等权限
• 给了 agent:execute，不会自动改变 Agent 的系统提示词
• 前者是安全边界，后者是测试策略

团队落地时可以这样记：按人的职责配平台 RBAC 角色（谁能看、谁能改、谁能执行）；按任务类型选 AI 测试角色（渗透、CTF、信息收集等测试风格）。

三、RBAC 到底怎么生效？不是「看不见」就算安全

v1.7.0 的授权模型是服务端强制校验，前端隐藏按钮只是体验优化。

一次操作要同时满足：

有效账号
  + 路由/工具所需 permission（如 project:read）
  + 该 permission 对应的 scope（all / assigned / own）
  + 目标资源的 owner / 显式授权 / 父资源继承
  + 全局对象的额外限制

处理链路（简化版）：

1. 登录后签发 Bearer Token，会话里带上用户、角色、权限和逐权限 Scope
2. HTTP 中间件把 API 路由映射为权限，例如 GET /api/projects → project:read
3. 带资源 ID 的请求继续校验：是不是 owner？有没有被显式授权？父项目是否已授权？
4. Agent 启动时把不可变 Principal 写入执行上下文
5. 内置 MCP 工具按工具名 + 参数里的资源 ID 再查一遍
6. 拒绝会写入 RBAC / 审计日志，方便复盘「谁越权了、越在哪」

所以：别指望改前端、猜 API 路径能绕过；真正的拒绝发生在服务端。

四、开箱即用的四个平台角色

v1.7.0 内置四个系统角色，升级时会按当前版本权限目录自动对齐，避免旧版本残留脏权限：

注意：

• 系统角色不可编辑，需要微调就复制思路建自定义角色
• 没分配任何角色的账号能登录，但基本没有业务权限——别拿「空角色」当正式岗位

五、权限与 Scope：比「能不能点」更细的一层

5.1 权限怎么命名？

采用 模块:动作，常见动作：

• read：查看、列表、导出
• write：创建、更新、执行
• delete：删除
• execute：跑 Agent、终端、工作流等

覆盖模块包括：对话、项目、漏洞、WebShell、C2、MCP、知识库、Skills、工作流、终端、审计、机器人、FOFA、攻击链等 30+ 模块。完整目录见 Web 端 平台权限，或 API GET /api/rbac/metadata。

5.2 几个容易踩坑的特殊权限

RBAC 允许调用 ≠ 可以跳过 HITL。 高危工具仍建议配合人机协同审批。

5.3 三种 Scope

多角色时权限取并集；同一权限的 Scope 取最宽：all > assigned > own。

但有个细节：全局读取不会把写权限放大成全局写。 服务端按 ScopeFor(permission) 逐项判断，不能只看用户「最宽总 Scope」。

5.4 哪些东西是「全局对象」？

即使你有 write，若 Scope 不是 all，仍可能改不了这些进程级共享配置：

• AI 测试角色、Skills、Markdown Agents
• 外部 MCP 配置、机器人配置、工作流定义
• 知识库写操作（搜索除外）、HITL 全局策略、C2 Profile 等

这是 v1 的设计取舍：先把执行链路和数据资源管住，全局定义的细粒度分权还在演进。

六、资源授权：项目授权一次，对话/漏洞往往跟着走

在 平台权限 → 成员详情 → 资源授权 里，可以给用户分配：

• 项目 project
• 对话 conversation
• 漏洞 vulnerability
• WebShell webshell
• 批量任务 batch_task
• C2 Listener c2_listener

继承关系（实用）：

• 授权项目 → 通常可访问该项目下对话、漏洞
• 对话 → 消息、过程详情、攻击链
• C2 Listener → Session → Task / 文件 / 事件

批量授权单次最多 100 个资源；重复授权会自动跳过。

七、Web 端怎么用？三步搭好团队权限

7.1 创建成员

1. 管理员登录 → 左侧 平台权限
2. 点击 添加成员：用户名、显示名、密码（至少 8 位）、启用状态
3. 分配一个或多个平台角色
4. 若角色 Scope 是 assigned，继续在 资源授权 里勾选项目等资源
5. 让用户重新登录，在右上角用户菜单确认角色、权限数、Scope

7.2 创建自定义角色

1. 新建角色 → 写清岗位名和说明（如「红队一线」「甲方只读」）
2. 选 all / assigned / own
3. 只勾岗位真正需要的权限——宁可少给，后续再加
4. 先用测试账号验证：列表、详情、写操作、删操作、Agent 调工具
5. 再批量分给正式用户

7.3 权限变更何时生效？

• 改用户角色/密码/启用状态 → 该用户现有会话立即作废，需重新登录
• 改/删自定义角色 → 全站会话作废，所有人重登
• 机器人 → 每条消息实时重新解析绑定用户权限，下一条就生效
• 后台批量任务 → 按任务 owner 重新解析 Principal，不依赖创建时的前端状态

八、典型落地场景

场景 A：安全实验室多人协作

• 队长：admin 或自定义 all 管理角色
• 队员：operator + assigned，只授权当前攻防项目
• 复盘同学：auditor，all 只读，能看全站但不能改
• 实习生：viewer + assigned，只看指定项目对话和漏洞

配合 项目管理 + 攻击链 + 事实黑板，不同人看到同一项目的不同切面，但改不了别人的 C2/WebShell。

场景 B：甲方安全运营「能用但不能乱动」

• 给 agent:execute + chat:read/write + vulnerability:read/write
• 不给agent:local-execute、terminal:execute、c2:write
• HITL 默认人工审批，审计 Agent 用小模型降本

Agent 能帮忙分析、记录漏洞，但很难在平台里直接执行破坏性本机命令。

场景 C：机器人值班号

建一个专用 RBAC 用户：

Scope: own（独立工作区）或 assigned（指定项目）
agent:execute
chat:read / chat:write
按需增加 project、vulnerability、knowledge 等

不要用 admin 当机器人账号，除非你真的想让白名单里每个人都拥有完整权限并共享全部数据。

场景 D：红队项目制

• 每个项目一个 assigned 操作员组
• WebShell、C2 Listener 按项目显式授权
• 项目结束：禁用账号 → 撤销机器人绑定 → 撤销资源授权

审计日志里可追踪 rbac/access_denied、角色变更、机器人服务账号执行。

九、机器人 + RBAC：IM 里也能按人分权

v1.7.0 把机器人纳入同一套 RBAC。平台 Token/签名只证明「消息来自钉钉/飞书」；真正决定能干什么的是 CyberStrikeAI 身份。

支持平台：个人微信、企业微信、钉钉、飞书、Telegram、Slack、Discord、QQ 机器人。

9.1 两种业务鉴权模式

机器人对话最低权限：

agent:execute
chat:read
chat:write

删对话要 chat:delete；用项目、WebShell、C2、外部 MCP 等还要各自权限。

9.2 逐用户绑定（默认，多人团队首选）

管理员：

1. 系统设置 → 机器人设置 → 选平台
2. 业务鉴权策略选 逐用户绑定
3. 应用配置

每位使用者：

1. Web 右上角头像 → 绑定机器人账号 → 生成绑定码（5 分钟有效）
2. 在机器人里发送：绑定 7C6E-BD4C（以页面显示为准）
3. 发送 身份 或 whoami，确认「鉴权状态：已授权」且实际身份是自己

绑定码一次性、哈希存储；过期需重新生成。可 解绑 或在 Web 端撤销。

9.3 专用服务账号（个人微信 / 单人 bot）

1. 机器人连上平台后，先发送 身份，复制完整 发送者 ID（个人微信常形如 [email protected]）
2. 机器人设置 → 专用服务账号
3. 填 RBAC User ID（不是显示名；填 admin 会有红色风险提示）
4. 允许的平台发送者 ID 每行一个，精确匹配、区分大小写、不支持通配符
5. 应用配置 → 再发 身份 验证

config.yaml 示例：

robots:
wechat:
enabled:true
auth:
mode:service_account
service_user_id:"你的RBAC用户ID"
allowed_external_users:
-"[email protected]"
dingtalk:
enabled:true
auth:
mode:user_binding
client_id:""
client_secret:""
lark:
enabled:true
auth:
mode:user_binding
app_id:""
app_secret:""

服务账号注意：

• 不接受 绑定 / 解绑
• 白名单里所有人共享该账号的对话、项目等 own 资源
• 要隔离就必须用 user_binding

9.4 机器人常用命令

除命令外，直接发文字即 AI 对话，与 Web 端逻辑一致，且受实时 RBAC 约束。

9.5 最短上手路径（建议收藏）

• 多人：机器人设 user_binding → 每人 Web 生成绑定码 → 机器人绑定 → 身份 验证 → 开聊
• 单人：机器人先 身份 拿发送者 ID → 设 service_account + 白名单 → 应用配置 → 再 身份 → 开聊

十、Agent / MCP 在 RBAC 下的行为

Agent

登录用户会转成不可变 Principal 注入单 Agent、多 Agent、工作流。长任务脱离浏览器后身份不丢，也不会因为「按钮曾可见」而绕过校验。

内置 MCP

每个内置工具有显式授权策略。例如 WebShell 工具同时检查 webshell:read/write/delete 和 connection_id 资源访问；漏洞、项目、C2 工具会检查参数指向的资源。未登记策略的工具默认拒绝。

外部 MCP

需要 mcp:external:execute 且 Scope 为 all——因为外部服务的资源模型通常不受本地 owner/assignment 约束。这是 v1 的保守策略。

十一、推荐角色模板

只读项目成员

Scope: assigned
dashboard:read, chat:read, project:read, vulnerability:read, files:read, attackchain:read

日常安全操作员

Scope: assigned
agent:execute, chat:read/write, project:read/write, vulnerability:read/write,
tasks:read/write, files:read/write, hitl:read/write

确实需要本机命令再加 agent:local-execute 或 terminal:execute。

机器人专用账号

Scope: own 或 assigned
agent:execute, chat:read/write
+ 按业务加 project / vulnerability / knowledge 等

十二、RBAC 第一版刚落地，还有哪些不足？

v1.7.0 的 RBAC 是第一版完整落地，核心执行链路已经打通，但我很清楚还有不少地方需要继续打磨。当前版本的主要限制与后续方向：

12.1 已知的 v1 局限

1. 外部 MCP 权限偏粗
   调用外部 MCP 需要 mcp:external:execute + Scope all，暂不能按项目/连接细拆。后续会评估更细的外部工具策略。

2. 全局配置对象的写权限
   Skills、AI 测试角色、知识库索引、机器人配置、工作流定义等，修改仍要求对应权限 Scope 为 all。岗位化「只能改自己 Skills」这类需求还在规划中。

3. 资源授权类型有限
   当前显式授权以项目、对话、漏洞、WebShell、批量任务、C2 Listener 为主；更细粒度（如单条 C2 Task、单个 Skill 包）会随场景反馈补充。

4. 批量授权上限
   单次最多 100 个资源 ID，大规模导入要靠 API 分批或后续工具化。

5. 身份体系
   v1 以平台本地账号为主，暂未内置 LDAP / OIDC / SAML 等企业统一身份；多租户、组织树、审批流也还在路线图里。

6. 机器人侧
   仅处理文本消息；图片、语音等暂不支持。服务账号模式下白名单用户共享数据，容易误配，需要管理员仔细选型。

7. 与 HITL 的关系
   RBAC 解决「有没有资格发起」；HITL 解决「高风险要不要批」。两层都要配，不能互相替代。

8. 体验仍在迭代
   前端已按 /api/rbac/me 隐藏无权操作，但部分复杂页面的权限提示、批量运维工具还会持续优化。

12.2 我接下来打算补什么？

• 更细的 外部 MCP / 插件 授权模型
• 更友好的 企业身份对接（SSO）
• 资源授权 类型扩展与批量导入
• 机器人与 Web 权限诊断（一键解释「为什么被拒绝」）
• 与审计、HITL 联动的 合规报表

欢迎通过 Issue 或社群告诉我使用中的问题——RBAC 这类能力，需要真实团队场景来验证和打磨。

十三、升级与快速验证

升级

1. 拉取 v1.7.0 代码或镜像，注意 config.example.yaml 中 version: "v1.7.0"
2. 首次启动后，用原 auth.password 或已有管理员登录
3. 进入 平台权限，确认内置角色与权限目录已加载

5 分钟自检清单

• [ ] 创建测试用户，只给 viewer + assigned，确认看不到别人的项目
• [ ] 给测试用户授权一个项目，确认能读不能写（除非有 write）
• [ ] 测试用户调 Agent，确认无 agent:local-execute 时本机 Shell 被拒绝
• [ ] 机器人 身份 命令返回正确 RBAC 用户
• [ ] 审计日志能看到 access_denied 与角色变更

文档入口

• RBAC 详解：docs/zh-CN/rbac.md
• 机器人配置：docs/zh-CN/robot.md
• 完整 README：README_CN.md

写在最后

v1.7.0 主要补的是「多人、多岗位、多资源」场景下的权限能力。对个人用户来说，原有使用方式基本不变；对团队来说，RBAC 是把平台往可协作、可审计方向推进的一步。

如果你已经在团队环境里用 CyberStrikeAI，建议优先做三件事：

1. 改掉共享 admin 密码，给每人建独立账号
2. 按项目做 assigned 授权，避免一上来全员 all
3. 机器人先跑一遍 身份，确认 user_binding 或 service_account 配对正确

当前 RBAC 仍是第一版，我会按实际使用反馈继续补细。有问题或需求，欢迎通过 Issue 或社群告诉我。

CyberStrikeAI v1.7.0 · 平台 RBAC 已就绪

授权测试，合法合规；权限最小化，操作可审计。