03 不该被看的数据：敏感数据泄露

03 不该被看的数据：敏感数据泄露

敏感数据泄露指应用未能保护信用卡、账号、密码、病历、身份信息等高价值数据，使它们在传输、存储或日志中被非授权方读到。防范靠强制 HTTPS、字段级加密与脱敏、最小化收集与留存、以及日志中不落敏感明文四管齐下。它既是漏洞清单条目，也是第一幕那笔经济账的实际兑现。

第一幕我们算了笔泄露的账，这一节回到“数据到底怎么漏出去”的执行细节。敏感数据不只是“数据库里的表”，它在三处流动：浏览器到服务器的网络传输、数据库与缓存里的静止存储、日志与备份里的沉淀。三处都有裸奔的可能。

一、问题与直觉：敏感数据的三种裸奔姿势

传输中：站点还在用纯 HTTP，WiFi 抓包就能读到明文请求体里的密码、手机号。这是最没技术含量也仍然高发的一种。

存储中：数据库把密码明文、把信用卡明文、把手机号无脱敏地存下来，一旦前面任何漏洞被利用（越权、注入、拖库），这些明文数据直接变成战利品。

日志与服务：排查问题时把完整参数打进日志，日志再被拖走，等于把敏感数据又送了一份。真实事故里，日志漏总是最容易被低估的一处。

二、核心原理：纵深兜底

数据保护不是一道门，而是一层全链路思想：任何一道门漏了，数据本身还能靠“拿到了也没用”来兜底。加密让拿走的数据不可读，脱敏让审计里的人看不到完整值，最小化让即使没了也没那么多可没。这三件事叠加，才让“数据泄露”从受害变成一个打了折扣的损失。

三、工程实践要点

• 强制 HTTPS 并配 HSTS：让浏览器只走加密链路，避免降级与中间人；禁弱 TLS 版本与不安全套件。
• 字段级加密与脱敏：对密码用加盐强哈希（前文已讲），对信用卡、手机号等敏感列做加密或按要求脱敏（如只显示末尾四位）。
• 密钥安全：密钥集中管理、按环境隔离、定期轮换，不硬编码进前端代码或仓库。
• 最小化收集与留存：只收业务必须的字段，到了期限就删除，减少“泄露面原有的量”。
• 日志脱敏：记录规则里对敏感参数打码，从源头不让完整值落入日志。

⚠️ 常见坑：以为“开了 HTTPS 就安全了”。HTTPS 只保护传输层，不保护存储和日志；真正事故常发生在明文存储一被拖库就全灭，或日志里留下完整的支付回调参数。传输、存储、日志要一起治理。

四、先给数据分类，再谈怎么护

防护动作总是从“这是不是敏感数据”的判断开始。给一个能落地的分档：第一档高风险（口令、支付卡、证件号、token），传输必加密、存储必加密或强哈希、日志必打码；第二档中风险（手机号、邮箱、生日、设备信息），传输加密、日志可部分保留；第三档低风险（昵称、公开资料、埋点聚合），常规处理即可。

别急着对所有字段上重药——加密有性能与检索成本，过度加密会影响索引与查询。分级的意义是让资源打在刀刃上：高风险字段接受更多成本，中低风险用更轻的手段。同时每个字段要登记“谁在生产（采集接口）、谁在消费（下游系统）、谁偶尔路过（日志/备份/第三方）”，只有把流向画清楚，才知道该在哪几个节点落加密与脱敏，而不是撒胡椒面。

五、加密、脱敏、哈希，别用混

三个词字面相近，用途完全不同，用错等于白做。哈希是单向的，适合验证口令（不能还原）；加密是双向的，适合既要存储又要还原的字段（支付卡按业务需要解密）；脱敏是把值加工成不可识别的展示形态（日志审计用），它不用于存储权威数据。常见错误：把口令字段做“加密”而不是“哈希”——一旦加密密钥泄露，口令全部还原，等于没护；把信用卡号只做“脱敏”存库，业务却需要原始卡号走支付时到处找原值，架构一团乱。分开这三种选择，是对敏感数据真正的负责，也是第四幕讲密钥管理时的先决条件。

六、一次完整的演练

背景：一个订单站，排查期间把查询参数的完整 JSON 打印进日志，手机号在日志里明文。操作：模拟一次拖库（对演示库做全量导出）和一次日志检索。结果：明文手机号在数据库与日志里都直接可见。解读：数据在存储和日志两处裸奔，之前的 HTTPS 完全没帮上。变式：对手机号列加字段加密、对日志打印加脱敏规则，导出与检索时看到的是密文/打码值，攻击者拿到的信息变成不可用的废料。

七、别让“最小化”成了口号

最小化收集和留存最容易被砍掉研发心智，但它是性价比最高的防线——你没有的数据，攻击者无论如何都拿不到。落地两件事：一是采集前过一遍“真需要吗”，把优惠、活动、A/B 实验等非核心版块的过度收集砍掉；二是给数据定生命周期，到期自动清理，备份也按同样规则归档而非无限堆存。它表面上不“炫技”，却直接把第一幕的风险账本里的“持有量”这一项压下来，是四管齐下里成本最低、见效最稳的一管。

八、一个驱动一切的敏感数据登记表

把前面的分级、流向、生命周期落在一张表上，管理起来才不靠记忆。登记表的列建议这样设计：字段名、风险定档（高中低）、出现位置（采集/存储/展示/日志/第三方）、采用的防护手段（HTTPS 依赖、加密、哈希、脱敏、最小化）、负责人与检查周期。字段一进来，先量定档，再勾防护动作，有人负责、到了期限就巡检。这张表既是自检底稿，也是合规审计要看的证据台账——监管问你“手机号存哪、怎么护、留多久”，翻表即可回答。很多团队把数据保护做成“每次出事了才想起来查”，有了这张登记表，防护就提前变成“新增即登记、登记即定档”的默认流程，敏感数据在生命中每一步都有人盯着。

本节要点回顾

• 分级定档再防护：高风险字段接受加密与打码全成本，中低风险用轻手段，别对全量上重药。
• 加密、脱敏、哈希别用混：口令用哈希、需还原字段用加密、展示用脱敏，各自职责清晰。
• 最小化是性价比之王：砍非核心采集、定数据生命周期与清理，直接压住风险账本的持有量项。
• 敏感数据在三处流动：传输、存储、日志，三处都要防护。
• HTTPS+HSTS 护传输，字段级加密与脱敏护存储，脱敏规则护日志。
• 密钥集中管理、按环境隔离、定期轮换，不硬编码前端。
• 最小化收集留存减少泄露面的原有量。
• 纵深兜底：即使防线失守，也要让读到的数据没用。