权限审查发现外包账号能访问合同范围外的项目，或非项目成员能读写项目内容时，先别急着批量改权限。外包账号超范围访问属于账号与授权范围问题，跨项目越权属于项目边界与角色配置问题，两类发现要分开定性，再合并到同一张整改单里闭环。处置按“立即止损—范围核查—根因修复—验证—复发预防”分级推进，每一步留下可核验的证据，验证通过后才关闭整改单。本文覆盖这两类发现的识别、原因验证、处置动作与关闭标准，整改过程可在 ONES 中承载整改任务与复核记录。
要点总览（TL;DR）
- 外包账号超范围访问与跨项目越权要分开定性：前者是账号与授权范围失配，后者是项目边界与角色配置失守，再合并到同一张整改单闭环。
- 处置按“立即止损—范围核查—根因修复—验证—复发预防”推进，能触达生产、密钥、客户数据的发现优先处理。
- 原因排查先列假设再找证据，账号清单与合同范围比对、成员与角色导出、访问日志、权限变更历史是四类核心证据，证据不足标记待确认。
- 批量冻结账号、批量改权限、关闭公开可见属于破坏性操作，执行前备份原权限快照、分批执行并设回滚点。
- 整改单关闭看证据：权限复核与合同范围一致、越权路径复测不可达、日志无残留访问，且无未决待确认项。
症状与范围：两类越权发现分别意味着什么
两类发现指向不同的管理缺口，处置入口也不同。外包账号超范围访问，问题出在“这个人以什么身份、被授予了多大范围”；跨项目越权，问题出在“项目边界和角色配置是否守得住”。先分清类型，才能选对止损动作和修复方向。
外包账号超范围访问的典型表现
- 账号权限大于合同约定范围，例如合同只约定参与测试，账号却能访问代码仓库或发布流程。
- 人员退场后账号仍可登录，或仍保留在原项目成员列表中。
- 共享账号多人使用，操作日志无法对应到具体自然人，出问题无法追溯责任人。
- 同一外包人员被复制了内部员工的权限模板，权限随人走而非随角色走。
跨项目越权的典型表现
- 非项目成员可以读取甚至修改项目内容，常见于项目可见范围被设为公开。
- 成员角色权限超出职责，例如只负责需求评审的角色拥有删除或发布权限。
- 通过跨项目关联、分享链接或接口调用绕过项目边界，访问到未授权项目的数据。
影响面判断与优先级
界定影响面时，逐项确认四个维度：涉及哪些数据对象（需求、代码、构建产物、发布记录）、波及多少个项目、是否包含敏感仓库与生产发布权限、是否涉及客户数据或密钥。优先级按“能触达什么”排序：能触达生产环境、密钥管理、客户数据的发现先处置，即使涉及账号数量少；仅能读取低敏感文档的发现可以排在后面，但同样要进整改单。
| 发现类型 | 核心问题 | 优先处置条件 | 初步动作方向 |
|---|---|---|---|
| 外包账号超范围访问 | 账号与授权范围失配 | 账号可触达生产、密钥、客户数据，或退场后仍可登录 | 冻结账号、核对合同范围 |
| 跨项目越权 | 项目边界与角色配置失守 | 非成员可写、可发布，或公开范围含敏感项目 | 收敛可见范围、撤销越权角色 |
原因假设与排除证据：先验证再定性
越权现象背后的原因往往不止一个，凭经验直接下结论容易修错地方。可行做法是先列原因假设，再为每个假设指定验证证据，按“账号侧—项目侧—配置侧”的顺序排查，证据不足的项标记为待确认，不写进结论。
账号侧假设与验证证据
- 假设：账号未随人员退场回收。验证：导出账号清单与人员退场记录比对，确认退场日期后账号是否仍处于启用状态。
- 假设：权限按人复制而非按角色授予。验证：导出成员与角色对应关系，检查是否存在多人共享同一套超范围权限。
- 假设：共享账号无法追溯责任人。验证：查看操作日志中的操作者标识，确认能否对应到自然人。
项目侧假设与验证证据
- 假设：项目可见范围设为公开。验证：导出各项目的可见范围配置，筛出公开项目并核对是否包含敏感内容。
- 假设：成员角色粒度过粗。验证：导出角色权限定义，对照岗位职责检查是否存在“一个角色包揽读写删发”的情况。
- 假设：跨项目关联或分享链接未受控。验证：检查项目关联关系与外部分享链接清单，复测链接在未登录或非成员身份下是否可达。
配置侧假设与验证证据
- 假设：默认权限过宽。验证：检查新建项目、新建成员的默认角色配置。
- 假设：审批流缺失。验证：抽取近期权限变更记录，确认是否有审批单据对应。
- 假设：权限变更无记录。验证：查看权限变更历史是否完整，缺失记录的时段单独标注。
| 原因假设 | 验证证据 | 证据不足时的处理 |
|---|---|---|
| 退场未回收账号 | 账号清单与退场记录比对 | 标记待确认，先冻结再核实 |
| 权限按人复制 | 成员与角色导出、权限快照 | 标记待确认，不据此批量改权限 |
| 项目可见范围公开 | 项目可见范围配置导出 | 标记待确认，先收紧再复核 |
| 角色粒度过粗 | 角色权限定义与岗位职责对照 | 标记待确认，列入角色拆分计划 |
| 分享链接未受控 | 链接清单与未授权身份复测 | 标记待确认，先关闭外链 |
| 权限变更无审批无记录 | 变更记录与审批单据抽查 | 标记待确认，补建审批流程 |
分级处置步骤：从止损到根因修复
处置顺序按风险从高到低推进，先切断越权入口，再查清范围，最后修根因。批量操作有破坏正常协作的风险，执行前要交代条件和停止点。
第一步：立即止损
对确认越权的账号执行冻结或停用，撤销越权角色，关闭公开可见设置与外部分享链接。操作前先确认哪些账号仍在正常协作中，避免误伤在岗人员；同时留存原权限快照，包括账号、角色、项目成员关系和可见范围配置，作为后续核查与回滚依据。止损动作只处理已确认的越权入口，待确认项先限制访问再核实。
第二步：范围核查
列出受影响账号、项目和具体数据对象，逐项确认是否已发生数据外带。核查依据包括访问日志、下载与导出记录、发布操作记录。发现异常外带迹象时，升级为安全事件处理，保留日志原件，不覆盖不删除。
第三步：根因修复
- 外包账号按合同约定范围重建最小权限，权限授予以角色为单位，不按人复制。
- 建立退场即回收流程，人员退场与账号停用、项目移除联动执行。
- 项目边界改为按成员授权，默认不公开，新增成员需明确授权。
- 角色按职责拆分，读写、发布、管理权限分开授予，避免单一角色包揽全部操作。
第四步：审批与记录
权限变更走审批，保留变更单与操作日志。审批记录要能回答三个问题：谁申请的、依据是什么、谁批准的。整改过程中的每一次权限调整都对应一条记录，便于后续验证时逐项核对。
风险边界
批量冻结账号、批量修改权限、批量关闭公开可见都属于破坏性操作。执行前备份配置，分批执行，每批完成后观察正常协作是否受影响，设置回滚点。一旦发现误伤在岗人员或关键流程中断，立即回滚该批次再排查。
验证与复发预防：整改单何时可以关闭
整改单的关闭不看动作是否做完，而看证据是否成立。验证通过的标准是：权限复核导出结果与合同范围一致，越权路径复测不可达，日志确认无残留访问。
验证证据清单
- 权限复核导出：外包账号权限与合同约定范围逐项比对一致，无多余授权。
- 越权路径复测：以非成员身份访问目标项目不可达，分享链接失效，接口调用被拒绝。
- 日志确认：止损后无残留访问记录，退场账号无登录记录。
- 变更记录：每项处置动作有对应审批单与操作日志。
关闭条件
同时满足以下条件才可关闭整改单：处置动作全部完成且有证据支撑；责任人确认验证结果；无未决的待确认项。存在待确认项的，整改单保持开启，待确认项单独挂责任人跟进。
复发预防机制
- 建立外包账号台账，账号与合同、人员、项目绑定，退场时联动停用。
- 定期权限复核，按季度或项目里程碑节点导出权限清单与合同范围比对。
- 项目可见范围默认收紧，新建项目默认不公开，公开需审批。
- 权限变更纳入审计，变更单、审批记录与操作日志定期抽查。
遗留风险登记
暂不能修复的项，例如角色拆分需要改造配置、历史分享链接需要逐条清理，登记责任人与完成期限，纳入下一轮复核。遗留风险不阻塞整改单关闭的前提是：风险已登记、责任人已确认、期限已明确，且不涉及生产、密钥与客户数据。
在 ONES 中，整改任务、权限复核任务与证据附件可以放在同一工作项下流转，账号目录可通过企业微信、钉钉、LDAP 或 Microsoft AD 同步，多团队之间数据隔离，便于把外包账号与内部团队分域管理；整改单从发现到验证关闭的状态变化与操作记录留在平台内，供复核时追溯。具体角色粒度与审计能力以实际部署和版本为准，选型时向厂商核实。
常见问题
外包人员退场后账号还在，但合同期内可能还要回来协作，应该直接停用吗？
建议先停用再按需重开，而不是保留启用状态等对方回来。停用是止损动作，重开时走一次完整的授权流程，正好借机核对合同范围与当前项目需求是否一致。
具体做法：退场当日停用账号并从项目成员中移除，留存原权限快照；需要返场时由对接人提交申请，注明参与项目、角色和期限，审批通过后按最小权限重新授予。返场账号建议设置到期时间，到期自动复核，避免再次出现长期挂起的账号。
跨项目越权复测时，用管理员身份访问当然能通，怎么判断边界是否真的收住了？
复测要用“应当无权访问的身份”去测，管理员身份不构成验证证据。至少覆盖三类身份：非项目成员、仅具只读角色的成员、已退场或已停用的账号。
测试路径也要覆盖完整：直接访问项目地址、通过分享链接访问、通过跨项目关联跳转、通过接口调用读取数据。四类路径都不可达，才算边界收敛。测试结果连同测试身份、时间、路径一起记录，作为整改单关闭的证据附件。
整改过程中发现历史分享链接已经扩散到外部，无法逐条确认谁打开过，怎么处理？
这类情况按已发生外带风险处理，不再停留在权限整改层面。先关闭全部外部分享链接并使其失效，再依据访问日志梳理打开记录，确认涉及的数据对象和敏感级别。
涉及生产配置、密钥或客户数据的，升级为安全事件，保留日志原件，不覆盖不删除，按企业安全事件流程通报。整改单中把这一项单独登记为遗留风险，写明责任人、处置期限和已采取的补救措施，在风险登记完成、责任人确认、期限明确之前不关闭整改单。
角色拆分需要改造现有配置，短期内做不完，整改单要不要一直开着？
不必让整张整改单被一项长期改造拖住。可以把整改单拆成两个层次：已完成的止损、核查和账号权限重建作为第一阶段，验证通过后关闭；角色粒度改造作为独立的改进项，单独立项、单独排期。
拆分的前提是遗留风险已登记、责任人已确认、期限已明确，且不涉及生产、密钥与客户数据。涉及高敏感范围的，在改造完成前用临时收敛措施控制，例如收紧该角色的可见范围或增加审批环节。
权限复核按什么频率做比较合适，每次都全量导出比对吗？
频率取决于人员流动和项目变更的节奏。外包人员进出频繁的团队，退场即回收应做成联动流程，不依赖定期复核；全量权限复核可以按季度或项目里程碑节点执行。
全量比对工作量大时，可以分层做：外包账号与合同范围每季度全量比对一次，内部成员按项目抽样复核，高风险项目（含生产发布、密钥、客户数据）提高频次。每次复核的导出结果和比对结论留存，作为下一轮复核的基线。
