文章总结： CyberStrikeAIv1.7.0引入平台RBAC，实现多用户、最小权限、数据隔离与服务端全链路权限校验。区分平台角色（安全边界）与AI测试角色（测试策略），内置admin、operator、auditor、viewer四个角色，支持assigned/all/own三种Scope及资源继承。提供Web端成员与自定义角色管理，并覆盖机器人场景的逐用户绑定或服务账号模式。建议按岗位分配权限、使用assignedscope进行项目隔离，避免将admin用于机器人账号。 综合评分： 87 文章分类： 安全建设,安全运营,解决方案,实战经验,红队
CyberStrikeAI v1.7.0 更新：多人协作下的权限管理（RBAC）
原创
学安全也就图一乐 学安全也就图一乐
低调学安全
2026年7月10日 22:39 北京
在小说阅读器读本章
去阅读
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 的原因：
- 能登录 ≠ 能做所有事 以前大家共用一个密码，谁登进来谁就是「管理员」：能删别人的对话、能调 C2/WebShell、能改全局配置。 多人协作时，更合理的是：实习生能看指定项目，但不能删数据；操作员能跑 Agent，但不能改系统配置——登录只证明「你是谁」，RBAC 才决定「你能干什么」。
- 页面上看不见按钮 ≠ 真的安全 如果只在前端把「删除」「终端」等按钮藏起来，懂一点技术的人仍可直接调 API。 v1.7.0 会在服务端对每次 API、Agent 工具调用、机器人消息做权限校验；前端隐藏只是减少误点，真正的拦截发生在服务端。
v1.7.0 引入的平台 RBAC（Role-Based Access Control），目标很直接：
- 多用户：每人独立账号，告别「全站一个密码」
- 最小权限：按岗位给权限，而不是全员 admin
- 数据隔离：项目、对话、漏洞、WebShell、C2 等资源按归属与授权可见
- 全链路 enforcement：不只管 Web 页面，还管 API、Agent 工具调用、MCP、后台任务、机器人消息
一句话总结：RBAC 管的是「平台授权边界」，不是 Agent 的测试风格。
二、先分清两种「角色」——这是上手 RBAC 的第一关
很多人第一次用会懵：CyberStrikeAI 里本来就有「渗透测试」「CTF」「Web 扫描」等角色，现在又来一套 RBAC 角色，有什么区别？
| 概念 | 在哪里配 | 决定什么 |
| — | — | — |
| 平台角色（RBAC Role） | 左侧 平台权限 | 用户能访问哪些功能、哪些数据 |
| AI 测试角色（Agent Role） | 左侧 角色 / roles/*.yaml | Agent 的提示词、测试方法、可选工具集合 |
关键原则：
- 选了「渗透测试」AI 角色，不会自动获得 C2、WebShell、终端等权限
- 给了
agent:execute，不会自动改变 Agent 的系统提示词 - 前者是安全边界，后者是测试策略
团队落地时可以这样记：按人的职责配平台 RBAC 角色（谁能看、谁能改、谁能执行）；按任务类型选 AI 测试角色（渗透、CTF、信息收集等测试风格）。
三、RBAC 到底怎么生效？不是「看不见」就算安全
v1.7.0 的授权模型是服务端强制校验，前端隐藏按钮只是体验优化。
一次操作要同时满足：
有效账号
+ 路由/工具所需 permission（如 project:read）
+ 该 permission 对应的 scope（all / assigned / own）
+ 目标资源的 owner / 显式授权 / 父资源继承
+ 全局对象的额外限制
处理链路（简化版）：
- 登录后签发 Bearer Token，会话里带上用户、角色、权限和逐权限 Scope
- HTTP 中间件把 API 路由映射为权限，例如
GET /api/projects→project:read - 带资源 ID 的请求继续校验：是不是 owner？有没有被显式授权？父项目是否已授权？
- Agent 启动时把不可变 Principal 写入执行上下文
- 内置 MCP 工具按工具名 + 参数里的资源 ID 再查一遍
- 拒绝会写入 RBAC / 审计日志，方便复盘「谁越权了、越在哪」
所以：别指望改前端、猜 API 路径能绕过；真正的拒绝发生在服务端。
四、开箱即用的四个平台角色
v1.7.0 内置四个系统角色，升级时会按当前版本权限目录自动对齐，避免旧版本残留脏权限：
| 角色 | Scope | 适合谁 |
| — | — | — |
| admin 管理员 | all | 平台 Owner、实验室负责人 |
| operator 操作员 | assigned | 日常攻防、项目内测试人员 |
| auditor 审计员 | all （只读） | 合规审计、复盘、只看不改 |
| viewer 只读用户 | assigned （只读） | 外包/实习生、甲方对接人 |
注意：
- 系统角色不可编辑，需要微调就复制思路建自定义角色
- 没分配任何角色的账号能登录，但基本没有业务权限——别拿「空角色」当正式岗位
五、权限与 Scope：比「能不能点」更细的一层
5.1 权限怎么命名？
采用 模块:动作，常见动作：
read：查看、列表、导出write：创建、更新、执行delete：删除execute：跑 Agent、终端、工作流等
覆盖模块包括：对话、项目、漏洞、WebShell、C2、MCP、知识库、Skills、工作流、终端、审计、机器人、FOFA、攻击链等 30+ 模块。完整目录见 Web 端 平台权限，或 API GET /api/rbac/metadata。
5.2 几个容易踩坑的特殊权限
| 权限 | 说明 |
| — | — |
| agent:execute | 能跑 Agent，不自动包含本机文件/Shell |
| agent:local-execute | 本地执行兜底权限，只给可信操作员 |
| mcp:external:execute | 调外部 MCP，当前还要求 Scope 为 all |
| robot:write | 管机器人配置；聊天本身走绑定用户/服务账号的业务权限 |
RBAC 允许调用 ≠ 可以跳过 HITL。 高危工具仍建议配合人机协同审批。
5.3 三种 Scope
| Scope | 含义 | 典型场景 |
| — | — | — |
| all | 该权限覆盖的全部资源 | 管理员、全局审计 |
| assigned | 仅管理员显式授权的资源 + 支持的父资源继承 | 项目组成员 |
| own | 以本人创建/归属为主 | 个人工作区、机器人独立身份 |
多角色时权限取并集；同一权限的 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 创建成员
- 管理员登录 → 左侧 平台权限
- 点击 添加成员：用户名、显示名、密码（至少 8 位）、启用状态
- 分配一个或多个平台角色
- 若角色 Scope 是
assigned，继续在 资源授权 里勾选项目等资源 - 让用户重新登录，在右上角用户菜单确认角色、权限数、Scope
7.2 创建自定义角色
- 新建角色 → 写清岗位名和说明（如「红队一线」「甲方只读」）
- 选
all/assigned/own - 只勾岗位真正需要的权限——宁可少给，后续再加
- 先用测试账号验证：列表、详情、写操作、删操作、Agent 调工具
- 再批量分给正式用户
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 两种业务鉴权模式
| 场景 | 推荐模式 | 效果 |
| — | — | — |
| 企微/飞书/钉钉等多人共用机器人 | user_binding 逐用户绑定 | 每人绑自己的 Web 账号，数据隔离 |
| 个人微信、单人专属、固定自动化入口 | service_account 专用服务账号 | 白名单发送者共用指定 RBAC 用户 |
机器人对话最低权限：
agent:execute
chat:read
chat:write
删对话要 chat:delete；用项目、WebShell、C2、外部 MCP 等还要各自权限。
9.2 逐用户绑定（默认，多人团队首选）
管理员：
- 系统设置 → 机器人设置 → 选平台
- 业务鉴权策略选 逐用户绑定
- 应用配置
每位使用者：
- Web 右上角头像 → 绑定机器人账号 → 生成绑定码（5 分钟有效）
- 在机器人里发送：
绑定 7C6E-BD4C（以页面显示为准） - 发送
身份或whoami，确认「鉴权状态：已授权」且实际身份是自己
绑定码一次性、哈希存储；过期需重新生成。可 解绑 或在 Web 端撤销。
9.3 专用服务账号（个人微信 / 单人 bot）
- 机器人连上平台后，先发送
身份，复制完整 发送者 ID（个人微信常形如[email protected]） - 机器人设置 → 专用服务账号
- 填 RBAC User ID（不是显示名；填
admin会有红色风险提示） - 允许的平台发送者 ID 每行一个，精确匹配、区分大小写、不支持通配符
- 应用配置 → 再发
身份验证
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 机器人常用命令
| 命令 | 作用 |
| — | — |
| 身份 / whoami | 查看发送者 ID、鉴权模式、RBAC 身份、角色、Scope |
| 绑定 <码> / bind <码> | 逐用户绑定模式专用 |
| 解绑 / unbind | 解除绑定 |
| 列表 / 对话列表 | 列出有权访问的对话 |
| 切换 <对话ID> / 新对话 | 会话管理 |
| 角色 <角色名> | 切换 AI 测试角色（仍需有业务权限） |
| 帮助 / 版本 | 帮助与版本号 |
除命令外，直接发文字即 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 局限
- 外部 MCP 权限偏粗
调用外部 MCP 需要
mcp:external:execute+ Scopeall，暂不能按项目/连接细拆。后续会评估更细的外部工具策略。 - 全局配置对象的写权限
Skills、AI 测试角色、知识库索引、机器人配置、工作流定义等，修改仍要求对应权限 Scope 为
all。岗位化「只能改自己 Skills」这类需求还在规划中。 - 资源授权类型有限 当前显式授权以项目、对话、漏洞、WebShell、批量任务、C2 Listener 为主；更细粒度（如单条 C2 Task、单个 Skill 包）会随场景反馈补充。
- 批量授权上限 单次最多 100 个资源 ID，大规模导入要靠 API 分批或后续工具化。
- 身份体系 v1 以平台本地账号为主，暂未内置 LDAP / OIDC / SAML 等企业统一身份；多租户、组织树、审批流也还在路线图里。
- 机器人侧 仅处理文本消息；图片、语音等暂不支持。服务账号模式下白名单用户共享数据，容易误配，需要管理员仔细选型。
- 与 HITL 的关系 RBAC 解决「有没有资格发起」；HITL 解决「高风险要不要批」。两层都要配，不能互相替代。
- 体验仍在迭代
前端已按
/api/rbac/me隐藏无权操作，但部分复杂页面的权限提示、批量运维工具还会持续优化。
12.2 我接下来打算补什么？
- 更细的 外部 MCP / 插件 授权模型
- 更友好的 企业身份对接（SSO）
- 资源授权 类型扩展与批量导入
- 机器人与 Web 权限诊断（一键解释「为什么被拒绝」）
- 与审计、HITL 联动的 合规报表
欢迎通过 Issue 或社群告诉我使用中的问题——RBAC 这类能力，需要真实团队场景来验证和打磨。
十三、升级与快速验证
升级
- 拉取 v1.7.0 代码或镜像，注意
config.example.yaml中version: "v1.7.0" - 首次启动后，用原
auth.password或已有管理员登录 - 进入 平台权限，确认内置角色与权限目录已加载
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，建议优先做三件事：
- 改掉共享 admin 密码，给每人建独立账号
- 按项目做 assigned 授权，避免一上来全员
all - 机器人先跑一遍
身份，确认user_binding或service_account配对正确
当前 RBAC 仍是第一版，我会按实际使用反馈继续补细。有问题或需求，欢迎通过 Issue 或社群告诉我。
CyberStrikeAI v1.7.0 · 平台 RBAC 已就绪
授权测试，合法合规；权限最小化，操作可审计。
https://github.com/Ed1s0nZ/CyberStrikeAI
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：低调学安全 学安全也就图一乐 学安全也就图一乐《CyberStrikeAI v1.7.0 更新：多人协作下的权限管理（RBAC）》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
![[译苑雅集Vol.14]Anthropic最新论文：大语言模型没说出口的内心小秘密，藏在一个叫J空间的地方](/images/random/titlepic/13.jpg)
评论