看到账号之后

一句话总结

调查时有必要查看的信息，不等于可以留在报告中的信息；把不必要的个人信息写进文档，本身就是一次事故。

为什么需要它

查询银行数据时，个人信息会出现在眼前：账号、姓名、居民登记号码、电话号码和交易记录。调查确实需要这些信息——要追踪某位客户的一笔转账，就必须查看相应账户。

问题发生在下一步。调查结束并撰写报告时，只要把查询画面中的值原样复制进去，这份报告就成了包含个人信息的文档。它会经由邮件传递、被贴到 Slack、上传到 wiki，甚至几年后仍能被搜索到。原始数据库设有访问控制和日志，而我们制作的文档却没有任何保护。

如何判断

标准只有一个：这份文档的读者是否必须知道这个值？

전문 번호 MSG-20260825-0104   필요하다. 고객사가 그 건을 다시 찾아야 한다.
계좌번호 110-4378-567278      전체는 필요 없다. 뒤 4자리면 대조가 된다.
고객 이름 정하윤              필요 없다. 전문 번호로 특정된다.
주민등록번호 711455-2930474   어떤 경우에도 필요 없다.

掩码账号时保留末四位，不是出于宽松，而是为了能够核对。客户负责人需要在自己的系统中找到该事项并与我们的报告比对；如果全部遮住，就无法核对。只留下必要的最少部分，遮住其余内容，这才是掩码。

110-4378-567278  →  110-****-**7278

居民登记号码则不同。即使遮住后半部分，前六位仍是出生日期，后半部分的第一位还表示性别和出生世纪。也就是说，仅前六位就具有相当强的识别能力。因此，不应掩码后写入，而是根本不要记录。如果调查时需要查看居民登记号码，只记录曾因调查需要使用该信息，不留下具体值。

实际工作中的表现

第一，**截图是最常见的泄露途径。**截取查询画面时，留下的不只是我们想看的那一格，而是画面上的所有字段。银行现场禁止拍摄和截屏，原因就在这里。需要转录表格时，原则上应只选择必要的列并重新写成文本。

第二，**中间产物也是文档。**调查时制作的 CSV、临时 SQL 结果以及粘贴到 Slack 的消息，都必须遵守同一标准。“只需小心正式报告”的想法会酿成事故。实际泄露发生在中间产物中的频率，远高于正式报告。

第三，**遮住信息并不意味着工作结束，还必须记录已经做过遮蔽。**如果报告中只有掩码后的值，读者无法区分“没有查看原文”和“查看后进行了遮蔽”。应单独设置个人信息处理章节，说明遮蔽了什么、如何遮蔽，以及为何保留末四位。这样，文档本身就能成为遵守流程的证据。

第四，**查询行为本身也会留下记录。**我们查看过哪些账户，会保存在客户的访问日志中；之后审计时，可能会被问到“为什么查看这个账户”。届时，能够说明理由的只有我们撰写的调查记录。因此，把查询范围限制在必要程度，并记录为何需要该范围，也是在保护自己。

下一道测验将检查什么

测验将检查掩码的标准、居民登记号码连掩码都不应保留的原因、中间产物的处理方式，以及在网络隔离环境中应如何设计调查方向。