结论先行：日志能不能定位到人，不取决于日志平台多先进，而取决于业务系统有没有把「谁」记下来。身份核验缺位的系统，日志里只剩时间、来源地址与动作，事后既说不清谁看过数据，也证明不了谁没看过。可落地的顺序是三步：把免登录查询收口到统一身份，把查询类操作纳入操作日志并定死字段，再用一次检索演练检验能不能在要求时间内还原到人。
这次事件暴露了什么
据韩国中央日报英文版 2026 年 10 月 4 日报道，以及中央社 2026 年 10 月 2 日与 10 月 4 日报道，韩国多家银行与金融机构连续发生客户信息泄露，涉及机构已从大型银行扩展到储蓄银行与金融公司，当地监管部门先后两次召开紧急会议并要求全行业开展排查。
这些攻击有一个共同特征：目标不是核心交易系统，而是员工日常使用的辅助系统——贷款中介专用服务、员工移动业务支持系统、销售支持系统。网上银行与手机银行等核心交易渠道未受影响，目前也未确认资金损失。
据朝鲜日报英文版 2026 年 10 月 4 日报道，报道中列出的几个细节与日志治理直接相关：
- 部分信息查询服务在无需身份核验的情况下就能查看贷款申请历史与企业代表信息；
- 员工支持系统的移动设备访问控制未正常生效；
- 有机构因网站服务器的已知漏洞被植入恶意软件，并导致包含客户信息的日志文件被导出；
- 报道同时提到，实施了多因素认证或提前修复漏洞的机构没有发生实际泄露。
同篇报道还提到，监管方在攻击银行体系的地址中发现某开源自主安全检测工具的使用痕迹，该工具基于大语言模型自动寻找漏洞并尝试入侵，攻击来源地址在多个国家和地区之间轮换。监管方随后向数百家金融机构共享了攻击地址与安全通告，并要求机构在限期内完成外部可达资产、访问控制与补丁状态的检查。
为什么「日志可归因」这件事会失灵
一条能用的审计记录要回答三件事：谁、在什么时候、对什么做了什么。三者缺一，剩下的信息就只能描述「发生了什么」，无法落到责任人。
免身份核验的查询入口正好把「谁」这一项挖空了。具体表现为三类：
| 空洞类型 | 日志里留下什么 | 事后会卡在哪一步 |
|---|---|---|
| 免登录查询 | 只有来源地址与时间 | 说不清是内部人员、外包人员还是攻击者 |
| 共享服务账号 | 同一账号的大量调用记录 | 账号背后的操作人无法区分 |
| 只记访问不记查询 | 页面被打开过，查询条件与返回范围没有 | 说不清看了哪些记录、看了多少 |
更麻烦的是日志本身的价值：它同时是证据和敏感数据。集中存放的日志里往往包含账号、地址与业务标识，一旦被导出，等于把「谁在什么时候看过什么」的线索一并交出去。
把「谁」补回来的三件事
| 动作 | 要解决的问题 | 验收方式 |
|---|---|---|
| 补身份 | 把免登录查询、内网直连查询收口到统一身份；对外接口加鉴权，服务账号一人一号或一系统一号 | 随机抽取一个查询类接口，能打出对应到具体主体或系统的记录 |
| 定字段 | 明确操作日志必须包含主体标识、主体来源、操作对象、操作类型、时间、结果，并统一账号口径与时间戳 | 从业务系统、数据库、访问代理三侧取同一笔操作，能关联成一条链 |
| 做演练 | 验证检索能力，而不是验证存储容量 | 给定一个时间窗与一个客户编号，能在约定时间内还原访问清单 |
日志文件本身也要按敏感数据管
事件里出现的「日志文件被导出」提示了两件事：一是日志存储与导出的权限要收口，能看日志的人本来就掌握了大量信息；二是导出行为自身要留痕——谁导的、导了多大范围、导到哪里去，这几项要能查。把日志平台的访问控制、端口暴露面一并纳入巡检范围，比事后追查更划算。
边界与前提
三点需要说清楚。其一，上述信息来自公开报道，报道中的归因仍在调查中，不宜指认具体主体。其二，日志能证明曾经发生过什么，无法单独证明「没有发生过」；在日志缺失的时段，要有替代证据的约定，例如网络流量记录、终端侧记录与业务流水。其三，补身份核验会影响现有系统与接口的调用方式，改造范围要先做一轮盘点再排期，避免上线时打断业务。
落地清单
- 盘点所有免身份核验即可访问的查询类页面与接口，按敏感程度排序。
- 把查询类操作纳入操作日志，字段覆盖主体、对象、动作、时间、结果。
- 统一账号口径与时间戳，确保跨源可关联；服务账号登记到人。
- 收口日志文件与日志平台的导出权限，导出行为单独留痕。
- 日志留存周期与合规要求对齐，并纳入巡检项。
- 每半年做一次检索演练，记录实际用时与缺口，作为改进依据。
日志治理做到最后，检验方式很朴素：出事的时候，能不能拿出一份完整、可读、能落到人的记录。奇摩在日志分析与企业合规项目中，通常先做日志源与身份入口的盘点，再补字段规范与检索演练，避免存了一堆、用时找不到。如果这块口径还没对齐，欢迎 预约咨询。