第三方渗透测试：如何授权、验证角色并证明彻底收口

第三方渗透测试通常不只是把测试人员的 IP 加入白名单。测试团队可能需要普通用户、受限的高权限角色、云端委托、代码仓库读取权限、VPN、API 凭据，以及受保护的证据空间。客户面临的真正问题，是让测试触达约定边界，同时避免把一个短期项目变成供应商的长期访问通道。

适合管理的对象不是“账号清单”，而是访问关系图。一个人可能通过外部目录身份登录，承担一个角色，取得会话，使用部署密钥，复制代码仓库，创建测试数据，再把证据上传到门户。删除入口账号并不一定让其他节点失效。只有每条路径都已撤销、按可接受规则到期，或作为有明确业务和安全负责人的例外保留，技术收口才算得到证明。

本文只讨论访问开通和技术收口。更广泛的供应商选择可以参考基于证据的渗透测试供应商比较，授权、范围与验收则见渗透测试合同和范围指南。

先画访问关系图，而不是只“创建一个测试账号”

针对每条测试路径，记录六个相连对象：实际操作人员、登录身份、承担的角色或应用身份、凭据或会话、资源授权，以及该路径能够创建或复制的制品。每个对象都应有客户侧负责人和预定的移除动作。这样才能暴露那些不容易被注意到的持久访问。

一条常见链路可能是：实名测试员 → 来宾身份 → VPN 会话 → 云角色 → 对象存储读取权 → 已下载的证据。禁用来宾身份可能阻止下次登录，但已有的应用会话可能受另一套规则控制。撤销旧的云角色会话，也不一定阻止测试员在信任关系仍开放时取得新会话。移除仓库协作者不会抹去本地副本。证据导出件还可能根据约定，在交互访问结束后继续保留。

因此，关系图要分别标注入口、权限、运行态和残留物。入口说明如何完成身份验证；权限是角色、组、应用同意、资源策略、仓库权限或委托权；运行态是已签发的令牌、Cookie、VPN 租约、SSH 会话或临时角色凭据；残留物则包括代码副本、截图、日志、测试账号、上传工具、临时记录和最终报告。

不要让多名测试员共用一个管理员账号。实名身份更利于归因、访问复核、紧急暂停和负向测试。自动化可能确实需要共享的服务身份，但它必须拥有独立负责人、独立凭据、明确动作集合、日志线索和停用步骤。

从测试主张反推最小够用的访问权

访问申请应由测试主张产生，而不是由职位名称产生。“验证租户管理员的授权边界”可以转化为测试；“给渗透测试团队管理员权限”则不行。每个主张都要列出主体角色、目标资源、允许动作、禁止的副作用、环境、时间窗口和验收证据。

如果产品支持，应至少分开三类身份：

• 普通业务身份代表真实用户角色，只拥有该角色本来的产品权限；
• 高权限测试身份用于管理员或支持流程，但不应顺带获得无关的生产运维权；
• 测试基础设施身份运行扫描、收集或云端工具，不继承某个人类管理员的宽泛权限。

云端委托应由客户控制。AWS 角色提供临时跨账号访问：信任策略标识供应商，权限策略限定资源与动作。在多客户服务中，由供应商分配、每客户唯一的 ExternalId 将请求关联到正确客户；它不是秘密。针对本次项目，另外记录会话限制、适用的来源限制、每项授权的负责人，以及阻止再次承担角色的方法。

到期时间很有用，但“周五自动过期”不是完整的关闭方案。有些会话会在创建者身份变化后继续存在；有些凭据没有原生到期时间；有些会话由业务应用自身而不是身份提供方控制。访问记录中既要写预定到期，也要写可执行的提前撤销路径。

验证预期角色，同时避免悄悄改变范围

渗透测试需要正向和负向证据。先用一个控制对象证明正确角色确实能访问范围内功能；再由低权限身份尝试相同业务动作，并在真正做出授权决定的层面确认拒绝；最后检查下游状态，证明拒绝没有偷偷创建队列任务、对象或交易。单独看到前端错误消息，并不能有力证明系统没有产生副作用。

测试身份和访问管理身份应分开。客户访问负责人创建或批准授权；测试员使用授权；客户观察人员确认日志和副作用。这样可避免同一个供应商账号既修改边界，又自行宣布边界安全的循环证明。

如果约定测试因缺少权限而受阻，应把新增权限视为一次范围事件。记录测试主张、授权差异、批准人、生效时间和移除步骤。不要无记录地提升普通测试角色，也不要借用无关的生产管理员。如果破坏性动作未获授权，可以使用可逆控制对象、非生产环境中的代表性数据，并在报告中明确限制。

渗透测试范围规划器可以确定系统与约束，但访问矩阵还要再深入一层：哪个身份通过哪条授权关系，到达哪个具体对象。

测试开始前建立证据矩阵

下面的矩阵把每项授权变成一个小型验收测试。实际使用时应填写具体标识符，而不是笼统名称。

负向测试必须匹配要关闭的通道。只测网页登录，无法说明 API 令牌是否失效；只测人类账号，无法说明部署密钥是否失效；只看角色名称也不够，因为资源策略可能独立授予同一主体权限。证据至少要记录观察组件、时间、请求身份、目标、决定和下游状态。

按受控顺序关闭所有权限

收口包含两项工作：阻止未来权限，并核对仍然存在的内容。应在客户仍能联系测试人员、日志仍容易关联时完成。

1. 冻结停止新增测试，记录最终访问关系图和仍在运行的工作
2. 撤销停止签发新权限，撤销已签发会话并删除独立凭据
3. 验证证明供应商原有路径已被拒绝，同时客户独立控制路径仍可用
4. 核对盘点制品、例外、负责人、保留日期和最终证据

先冻结活动并导出最后使用情况。盘点正在运行的任务、回调、隧道和队列操作，按照获批方案排空或停止，并验证最终状态。撤销提交任务所用的凭据，并不会自动取消已经排队或运行的工作。然后关闭产生新权限的能力：按实际情况移除信任关系、角色分配、组成员、应用同意、仓库协作者和网络通道。接着处理已经签发的权限：角色会话、刷新令牌、应用 Cookie、VPN 会话、个人令牌、SSH 密钥、部署密钥、证书和自动化秘密。

顺序非常关键。AWS IAM 角色会话撤销可以拒绝截止时间之前签发的会话，却仍可能允许之后新承担的会话；如果多人共用该角色，撤销还会影响其他使用者。由 AWS IAM Identity Center 权限集生成的角色采用另一条撤销路径。先删除用户也可能让管理员失去最方便的活动会话撤销入口。因此，运行手册要识别实际身份路径，写明平台操作顺序，并让客户侧应急负责人留在场，直到验证通过。

有效撤销是观察到的结果，不是管理员点击按钮的时间。通过每类凭据路径重新执行原来获准的供应商控制动作，此时必须被拒绝且不产生副作用；同时，未改动的客户控制路径仍应成功，以证明目标服务可用，而且拒绝只针对已移除权限。一个在收口前就失败的负向用例，既不能证明撤销，也不能证明可用性。记录最后一次供应商成功和第一次确认拒绝，但不要把这个区间宣传成平台的普遍承诺。如果决定让会话自然到期，要写清可接受的最长存活期，以及阻止新会话签发的补偿限制。

分别处理凭据、会话、委托和制品

删除账号容易得到一张清晰截图，但它并不是完整的收口模型。

代码仓库很好地说明了这个问题。移除外部协作者可以关闭托管访问并处理相关私有派生仓库，但对方仍可能保留本地副本。GitHub 部署密钥是独立、面向单个仓库的凭据，可以脱离创建它的人继续存在，并且没有到期机制。因此，收口要分别盘点仓库协作者、应用授权、可见令牌、部署密钥、Webhook、自动化秘密和供应商持有的副本。对本地副本的删除声明属于治理证明；旧凭据无法再次拉取则是托管访问结束的技术证明。两者回答的问题不同。

身份平台也有多个层次。阻止登录、撤销刷新令牌、使浏览器 Cookie 失效、移除应用权限，以及结束应用自己签发的会话，是不同动作。外部来宾可能在其主目录中完成身份验证，因此资源目录中的通用用户会话操作未必会撤销主目录会话。即使上游登录仍有效，资源应用也必须执行已变化的资源授权。

制品需要单独台账，包括位置、分类、加密负责人、允许接收者、保留依据、删除日期和删除证据。保留报告与修复所需的材料，同时移除测试账号、临时文件、工具、回连端点、植入数据和多余副本。普通截图和通用日志中不应保存凭据、原始秘密或会话令牌。

一个 SaaS 测试的假设收口案例

假设一家 SaaS 公司聘请独立团队测试租户隔离。两名实名测试员获得来宾身份和 VPN。客户创建三个普通租户用户、一个受限支持角色、一个只读云日志角色，并开放两个仓库的读取权限。另一个供应商自动化身份使用仓库部署密钥，并把扫描结果上传到证据空间。

测试过程中，为验证一个已约定主张，支持角色需要增加一项诊断动作。客户记录差异，只增加该动作，并同时建立移除任务。测试员证明诊断调用可用，也证明同一身份不能修改租户配置。客户观察人员确认拒绝之后没有排队中的配置变更。

收口时，客户先冻结测试，禁用新的 VPN 和来宾分配；随后移除云角色的信任关系，撤销旧会话，并分别验证现有会话和新的角色承担都失败。客户移除仓库协作者，删除自动化使用的独立部署密钥，轮换证据上传秘密，并确认人类和自动化路径都不能再拉取代码。对于产品测试用户，客户先阻止新登录和新令牌签发，再使活动会话失效，并确认旧会话无法继续使用。旧凭据上传证据也被拒绝，而未修改的客户账号仍然能够访问。

团队交还制品台账。最终报告和选定证据按约定保留在客户控制的空间中。本地代码副本、临时扫描结果和植入数据已声明删除；客户日志显示撤销动作及之后的拒绝。一份由测试方保留、用于明确争议期的加密证据档案被列为例外，注明负责人和删除日期。最终结果不是一句“供应商账号已删除”，而是一张已核对的关系图，每条边都有证明或具名例外。

客户在交接时应该验收什么

可辩护的交接包应包含最终访问关系图、授权变更、测试用例矩阵、带时间的移除动作、撤销后的复测结果、制品台账和例外。每项结果都应说明验证人，以及做出允许或拒绝决定的组件。没有先前正向控制的拒绝，可能只是路径从未正常工作；只有身份清单而不测会话，可能漏掉仍然有效的权限；没有制品盘点的删除声明，则无法说明数据最终去了哪里。

当客户需要对真实授权边界进行对抗性验证，并取得可用于修复的证据时，独立渗透测试服务很有价值。如果组织还不能提供稳定测试身份、观察下游副作用或授权安全控制动作，先进行访问设计评审可能更合适。Pentest.red 可以在双方约定的项目中设计角色测试、证据处理和技术收口。还可以事先参照渗透测试报告示例约定发现项格式，使访问证据直接支持修复，而不是变成一堆截图。