提交缺陷前如何识别并遮蔽截图与日志中的敏感信息

生产环境缺陷往往带着真实用户数据进入缺陷库：截图里有手机号，日志里有内网IP和访问令牌。提交前先按统一口径识别敏感字段，再分别对截图和日志做遮蔽与替换，最后逐项复核，才能既保护数据又保留足够的复现信息。本文给出可直接套用的分类清单、操作步骤、角色分工与提交前检查表。

要点总览（TL;DR）

• 提交前先按账号与身份、联系方式、内部地址与主机信息、业务数据四类列出敏感字段清单，生产环境附件默认全量检查，测试数据可标注后简化。
• 截图先全屏截取再局部裁剪，用不透明色块或足够强度的马赛克覆盖敏感区域，保留菜单路径、报错文案和操作时间，确保看图能复现问题。
• 日志按字段替换手机号、账号、IP和令牌，保留字段结构与错误码，只截取报错前后相关时间段和请求链路，并在文件开头注明替换规则。
• 提交人负责识别与遮蔽并填写脱敏说明，复核人按清单二次检查截图边缘和日志首尾；发现残留敏感信息时退回重新处理，不进入流转。

先定敏感信息清单：哪些内容必须遮蔽

识别是遮蔽的前提。提交人如果凭感觉判断“这条算不算敏感”，不同人就会给出不同结果：有人遮了手机号却漏了内网IP，有人把整段日志删掉导致无法复现。可行做法是在团队内先定一份敏感信息分类清单，把常见字段归入四类，提交时逐类对照。

类别	示例字段	处理方式	是否必遮
账号与身份	用户名、工号、邮箱、身份证号、会话令牌、Cookie	替换为占位符或色块覆盖	必遮
联系方式	手机号、座机、家庭或收货地址	中间位替换或整体打码	必遮
内部地址与主机信息	内网IP、内部域名、主机名、数据库连接串、端口、服务器路径	替换为示例值，保留字段结构	必遮
业务数据	真实客户名称、订单号、金额、证件与合同信息	替换为虚构示例或打码	必遮

清单需要按场景裁剪。附件来自生产环境时，默认对四类字段做全量检查，不因“看起来不重要”跳过；使用测试数据复现的缺陷，可以在缺陷记录中标注“测试数据”，对业务数据类适当简化，但账号、令牌、内部地址仍应处理，因为这些信息一旦泄露同样可被利用。

清单落地时建议写明每条字段的判定示例，例如“以 10.、172.16–31.、192.168. 开头的地址视为内网IP”，减少提交人与复核人之间的理解偏差。清单本身随业务变化更新，新增字段类型时同步补充示例。

截图脱敏：识别、遮蔽与保留证据的操作步骤

截图脱敏的目标是让看图的人能复现问题，同时看不到真实数据。操作按以下步骤执行，每一步都有明确的完成标志。

输入：原始截图、S1 的敏感字段清单。

第一步，先全屏截取再局部裁剪。直接对着局部区域截图容易漏掉边缘信息，例如浏览器地址栏、页面右上角的登录用户名、悬浮提示。先截取完整窗口，再裁掉与问题无关的区域，保留菜单路径、按钮状态和报错文案。

第二步，用色块或马赛克覆盖敏感区域。覆盖时注意三点：色块要完全盖住字符，半透明覆盖仍可能被还原；马赛克强度要足够，低强度马赛克对短数字几乎无效；覆盖区域不要压到关键界面元素，例如把报错弹窗的标题一起盖掉。手机号可保留前三位和后两位，便于说明“这是同一用户的号码”；账号名可替换为“user_A”这类占位文本。

第三步，保留可复现信息。菜单路径、按钮状态、报错文案、操作时间（保留到分钟即可）都应可见。时间戳精确到秒通常没有必要，反而可能关联到具体用户行为。

输出：遮蔽后的截图文件，文件名标注“已脱敏”，例如“订单提交报错_已脱敏.png”。

完成标志：对照清单逐项确认无残留，同时自己或同事仅凭这张截图能说清“在哪个页面、做了什么操作、看到什么错误”。两个条件同时满足才算完成。

日志脱敏：字段替换与附件整理

日志的问题通常不是“遮不遮”，而是“整段上传”。一份完整的请求日志可能包含令牌、内网地址和用户标识，直接作为附件提交等于把访问凭证放进了缺陷库。处理方式是按字段替换，而不是删除整段。

输入：原始日志、敏感字段清单。

动作一，按字段替换。手机号、账号、IP、令牌分别替换为固定占位符，例如 <PHONE>、<USER>、<IP>、<TOKEN>。替换时保留字段名和值的长度特征，例如令牌统一替换为等长的星号串，便于判断是否被截断。错误码、异常类型、堆栈信息保持原样，这些是定位问题的关键。

动作二，截取相关时间段与请求链路。只保留报错前后若干分钟、同一请求ID关联的日志行，去掉无关的大段启动日志和健康检查记录。截取时保留时间戳和日志级别，方便复核人判断上下文。

输出：脱敏后的日志片段或附件，在文件开头或缺陷描述中注明替换规则，例如“手机号已替换为 <PHONE>，内网IP已替换为 <IP>”。

完成标志：关键报错与堆栈可读，按替换规则无法还原出原始敏感值。可以用搜索功能在脱敏后的文件中检索原始手机号、IP片段，确认无残留。

角色分工与交付物：谁识别、谁复核

脱敏靠提交人一个人把关容易出错，尤其是截图边缘和日志尾部这类容易遗漏的位置。建议在缺陷流程中明确两个角色和一份记录字段。

角色	职责	交付物
提交人	按清单识别敏感字段，完成截图遮蔽与日志替换，填写脱敏说明	脱敏后的附件、脱敏说明
复核人	按清单二次检查，重点看截图边缘、日志首尾和替换规则是否一致	复核结论（通过或退回）
审批或知会角色	涉及生产数据的场景，确认附件外发范围与知会对象	审批或知会记录

缺陷记录中应保留“脱敏说明”字段，内容包括：处理了哪些字段、使用了什么替换规则、附件是否来自生产环境。这个字段既是追溯依据，也方便后续同类缺陷参考。复核人退回时，在缺陷记录中写明残留位置，提交人处理后重新提交，避免同一问题反复出现。

在缺陷提交与复核环节，ONES 工作项支持附件上传与字段记录，团队可以把脱敏说明设为缺陷工作项的必填项，让提交人在提交时完成说明，复核人依据同一份记录检查，减少线下沟通遗漏。

示例：一条生产环境缺陷的附件脱敏过程

以下为演示情景，用于说明操作顺序，不涉及真实用户数据。

场景：生产环境订单提交页面报错，提交人截取了报错页面，并导出了对应时间段的日志。截图中包含用户手机号和登录邮箱，日志中包含内网IP、会话令牌和用户ID。

截图处理：先全屏截取报错页面，保留浏览器地址栏中的页面路径和报错弹窗。用不透明色块覆盖手机号中间四位和邮箱前缀，手机号保留首尾各两位，邮箱替换为“user@example.com”。报错文案“提交失败，请稍后重试”、按钮置灰状态、操作时间（精确到分钟）保持可见。文件命名为“订单提交报错_已脱敏.png”。

日志处理：截取报错前后五分钟、同一请求ID的日志行。将手机号替换为 <PHONE>，用户ID替换为 <USER>，内网IP替换为 <IP>，令牌替换为等长星号串。保留异常类型、错误码和堆栈前若干行。文件开头注明替换规则。

脱敏说明填写：“附件来自生产环境。截图已遮蔽手机号与邮箱；日志已替换手机号、用户ID、内网IP、令牌，替换规则见日志文件首行。保留报错文案、请求ID与堆栈信息用于复现。”

保留的信息：页面路径、报错文案、操作时间、请求ID、错误码、堆栈。这些信息足以让开发人员定位问题，同时不暴露用户身份和内部网络结构。

提交前完成检查：逐项核对与阻断条件

脱敏完成后，提交前按清单逐项核对。截图、日志和其他附件分别检查，避免只看了截图就提交。

• 截图：敏感字段无残留，重点检查边缘、地址栏、悬浮提示和弹窗标题；界面结构完整，能支撑复现。
• 日志：替换规则已注明，检索原始手机号、IP片段无结果；关键报错与堆栈可读。
• 其他附件：导出的表格、配置文件同样按四类字段检查，不因文件类型不同而跳过。
• 脱敏说明：已填写处理字段、替换规则和附件来源。

阻断条件：任一附件发现残留敏感信息，不得提交，退回重新处理；脱敏说明缺失时，缺陷记录不进入流转。复核人确认通过后，缺陷才进入处理环节。

团队可以定期抽查已提交的缺陷附件，统计退回原因，例如“日志尾部遗漏令牌”“截图边缘露出用户名”，据此更新敏感字段清单和检查项。抽查结果用于改进流程，不针对个人追责，这样提交人才愿意主动报告疑似泄露并配合处理。

常见问题

截图里的手机号只遮住中间几位，是否算完成脱敏？

部分遮蔽是否足够，取决于能否结合其他信息还原。手机号保留首尾各两位、中间用不透明色块完全覆盖，通常可以说明“是同一用户的号码”而不暴露完整号码；如果保留位数过多，或覆盖层半透明，仍存在被还原的风险。判断标准是：按截图上的可见信息，无法拼出完整号码，同时不影响复现问题。

日志太长，能否只上传报错那几行？

可以截取，但要保留上下文。只留一行报错往往缺少请求ID、时间戳和调用链路，开发人员难以定位。建议保留报错前后若干分钟、同一请求ID关联的日志行，并保留时间戳和日志级别。截取后同样要按字段替换手机号、账号、IP和令牌，不能因为“只传了几行”就跳过脱敏。

测试环境复现的缺陷，附件还需要脱敏吗？

测试数据可以在缺陷记录中标注后，对业务数据类字段适当简化；账号、令牌、内部地址仍应处理。测试环境如果接入了真实用户数据或使用了生产配置，按生产环境标准全量检查。判断依据是附件内容的实际来源，而不是环境名称。

复核人退回后，提交人应该怎么处理？

复核人应在缺陷记录中写明残留位置，例如“日志尾部含令牌”“截图地址栏露出用户名”。提交人按位置重新遮蔽或替换，更新脱敏说明后再次提交。同一类残留反复出现时，把它补充进敏感字段清单的判定示例，减少后续同类问题。

团队没有专职复核人，如何保证脱敏质量？

可以由同组同事交叉复核，或由缺陷流转的下一个环节（如开发负责人）在受理时顺带检查。关键是保留脱敏说明字段并执行阻断规则：发现残留即退回。团队还可以定期抽查已提交附件，统计退回原因并更新检查项，抽查结果用于改进流程而非追责个人。