应用安全系列之四十八：PII数据安全

1、PII数据简介

PII是Personally Identifiable Information的简称，主要是描述关于能够通过某些信息可以定位到某个人。PII（个人可识别信息）信息通常根据其识别能力、敏感程度和处理风险分为以下几类。不同法规和标准的具体分类可能略有差异，但核心思想相似：

1.1、按识别能力与方式分类

直接标识符
- 定义：能够单独、直接地唯一标识出特定个人的信息。
- 特点：一旦泄露，个人身份可能立即被确认，风险极高。
- 举例：
  - 身份证号码、护照号码、驾驶证号码
  - 社会保险号（如美国的SSN）、国民保险号（如英国的NI）
  - 生物识别信息（指纹、虹膜、面部识别模板、DNA）
  - 全名（在某些与其它信息结合或特定文化背景下可视为直接标识符）
  - 系统账号（如用户名、邮箱地址）、金融账户号码（银行卡号）
间接标识符 / 准标识符
- 定义：单独无法唯一识别个人，但与其他信息结合或交叉关联后，能够识别出特定个人的信息。
- 特点：风险在于数据聚合和关联分析。在去标识化处理中，常需要对这些信息进行泛化或删除。
- 举例：
  - 人口统计学信息：性别、年龄/出生日期、邮编、种族
  - 地理位置信息：精确到街道的住址、工作单位、常去地点（非实时）
  - 背景信息：职业、职务、教育程度、收入范围、婚姻状况
  - 设备与网络标识符：Cookie ID、设备ID（如IMEI）、IP地址（在某些情况下）、搜索浏览记录
  - 在某些系统里使用的成员ID或者账号标识的唯一ID

1.2、按信息敏感程度分类（法律和合规重点）

敏感个人信息
- 定义：一旦泄露、非法提供或滥用，极易导致个人的人格尊严受到侵害或人身、财产安全受到危害的信息。各国法律对此类信息的处理有更严格的限制（通常要求获得个人的明确单独同意）。
- 典型范围（以中国《个人信息保护法》为例）：
  - 生物识别信息
  - 宗教信仰、特定身份（如种族、民族、政治观点）
  - 医疗健康信息、生理健康信息
  - 金融账户、财产信息
  - 行踪轨迹
  - 不满十四周岁未成年人的个人信息
  - 性取向、性生活信息等私密信息
一般个人信息
- 定义：除敏感个人信息以外的其他个人信息。
- 处理要求：虽然也需要保护，但法律要求通常低于敏感个人信息。处理一般个人信息通常只需获得个人的同意（可能非单独明确同意）。

1.3、按信息属性与来源分类

基本信息：姓名、性别、身份证号、电话号码、邮箱、地址等。
设备与网络信息：IP地址、Cookie、浏览器类型、硬件标识符、应用使用数据。
行为与偏好信息：搜索记录、购物记录、浏览历史、位置轨迹、兴趣爱好。
社交与关系信息：通讯录好友、社交网络关系、互动记录。
生物与生理信息：指纹、声纹、人脸、健康数据、基因信息。
财产与信用信息：账户余额、交易记录、信贷记录、纳税信息。

下面是根据几种分类画出的思维导图，供参考。

2、PII数据相关的法律

国家/地区	核心法律名称	主要监管/执法机构	近期惩罚案例与关键信息
中国	《中华人民共和国个人信息保护法》(PIPL)、《网络安全法》、《数据安全法》	国家网信办、最高人民检察院、市场监督管理局等	最高检公益诉讼典型案例 (2026年1月发布)。聚焦停车扫码、人脸识别等生活场景，通过检察建议督促整改，推动行业治理。
欧盟	《通用数据保护条例》(GDPR)	欧盟各成员国数据保护机构 (如法国CNIL)	法国某公司GDPR罚款案 (2025年12月)。因在无合法依据、未充分告知的情况下，将超1050万会员数据共享给社交网络用于广告，被罚350万欧元。
美国	无统一联邦法，主要法律包括： • 《加州消费者隐私法》(CCPA/CPRA) • 州级隐私法 (如弗吉尼亚州、科罗拉多州等) • 行业联邦法 (如《健康保险可携性和责任法案》)	联邦贸易委员会(FTC)、各州总检察长、通过集体诉讼维权	Grubhub数据泄露集体诉讼 (2026年1月提起)。因2025年数据泄露导致客户和司机PII泄露，面临集体诉讼，指控其未能采取合理安全措施保护数据。
日本	《个人信息保护法》(APPI)	个人信息保护委员会 (PPC)	近期高额罚款案例待补充。日本PPC可下达纠正命令，并对违规者处以罚款（针对企业的罚款上限可达2亿日元）。
韩国	《个人信息保护法》(PIPA)	个人信息保护委员会 (PIPC)	SK Telecom天价罚单案 (2025年4月作出)。因黑客攻击泄露2700万客户信息，被PIPC处以1347.91亿韩元（约合1.35亿美元）的罚款，创韩国国内企业最高纪录。

3、容易导致PII数据泄漏的漏洞

3.1、注入漏洞

这是最危险、最直接的漏洞之一。

典型代表：SQL注入。攻击者在输入字段（如登录名、搜索框）中插入恶意SQL代码，欺骗后端数据库执行非预期命令。
泄露路径：可直接绕过认证，批量下载、篡改或删除整个数据库中的用户PII，包括身份证号、地址、交易记录等。
防护要点：对所有用户输入进行严格的验证和过滤；使用参数化查询（预编译语句）或ORM框架，从根本上杜绝代码与数据的混淆。
参考： https://blog.csdn.net/jimmyleeee/article/details/129006156 和 https://blog.csdn.net/jimmyleeee/article/details/147609779 以及 https://blog.csdn.net/jimmyleeee/article/details/113998641 。

3.2、配置与访问控制缺陷

不安全的直接对象引用：系统在URL或参数中直接使用数据库ID（如/user/profile?id=123）。攻击者只需修改ID值，就可能访问到其他用户的PII。
权限配置错误：
- 水平越权：用户A能操作用户B的数据。
- 垂直越权：普通用户能执行管理员功能。
存储服务公开访问：云上的数据库、文件存储桶（如AWS S3）由于配置疏忽，被设置为“公开可读”，导致海量PII直接暴露在公网上。
防护要点：实施基于角色的访问控制；每次数据访问都进行会话权限校验；对云存储资源进行严格的访问策略审计。
参考： https://blog.csdn.net/jimmyleeee/article/details/118632872 和 https://blog.csdn.net/jimmyleeee/article/details/114373307 。

3.3、加密与传输安全问题

静态数据未加密或弱加密：PII以明文或使用过时、弱算法（如MD5、DES）加密存储在数据库中。一旦数据库泄露，数据等同于“裸奔”。
传输中缺乏保护：在登录、提交表单等环节未使用HTTPS（TLS/SSL），导致数据在用户与服务器间以明文传输，容易被中间人窃听截获。
防护要点：对存储的敏感PII实施强加密；确保全站强制使用HTTPS；采用安全的密钥管理方案。
参考：https://blog.csdn.net/jimmyleeee/article/details/114941933

3.4 设计逻辑与内部风险

API接口过度暴露数据：后端API在响应请求时，返回了超出当前视图所需的全部用户字段（包括敏感PII），前端虽未展示，但攻击者可通过抓包直接获取。
不充分的日志记录与监控：系统未记录PII的访问和操作日志，导致发生泄露时无法追溯源头、界定影响范围和及时响应。
内部威胁：拥有数据访问权限的员工、承包商或合作伙伴，因恶意、疏忽或社交工程攻击，导致PII泄露。
防护要点：API设计遵循最小化原则；实施全面的日志审计；对内部人员进行严格的权限分级和操作培训。

3.5、供应链与第三方风险

第三方组件漏洞：系统使用的开源库、框架或中间件存在已知安全漏洞（如Log4j2漏洞），但未能及时更新修补。
集成的第三方服务泄露：系统集成的短信服务商、数据分析平台等第三方服务商发生数据泄露，间接导致自身用户PII暴露。
防护要点：建立软件物料清单，持续监控并更新第三方组件；对第三方供应商进行严格的安全评估，并在合同中明确其数据保护责任。

3.6、不安全的传输方式

在传输过程中，将PII放在URL（特别是通过GET请求）是极其高风险的做法。URL作为明文数据，会在互联网的多个环节被自动记录和存储，形成持久化的泄露风险。

以下是几种容易导致PII泄露的传输方式及相关场景：

3.6.1、各类系统与中间件日志

风险场景：几乎所有处理HTTP请求的软件都会默认记录访问日志。除了Web Server（如Nginx、Apache），还包括：
- 负载均衡器/反向代理日志：记录完整的客户端请求URL。
- 应用框架日志：开发框架的调试或错误日志可能打印出完整的请求参数。
- CDN日志：内容分发网络会记录源站请求。
典型泄露点：日志文件被未授权访问，或日志管理不当被拖库。

3.6.2、浏览器历史记录与自动补全

典型泄露点：共享设备、失窃设备、设备上的恶意软件。
风险场景：浏览器会保存用户访问过的URL历史。如果URL包含PII（如/reset-password?token=abcd1234&email=user@example.com），任何能接触到该设备的人（或恶意软件）都可能通过历史记录获取这些信息。浏览器的地址栏自动补全功能也会暴露这些URL。

3.6.3、引用来源头

风险场景：当用户从A网站点击链接跳转到B网站时，浏览器通常会向B网站发送一个Referer请求头，其中包含A网站的完整URL。如果源URL中含有PII（例如通过URL参数传递的姓名、邮箱），这些信息就会泄露给第三方网站。
典型泄露点：第三方网站的分析或广告服务器。

3.6.4、网络基础设施

风险场景：
1. 企业网络中的代理服务器、防火墙、DDoS清洗设备等，出于审计或安全分析目的，可能会记录完整的URL。
典型泄露点：内部运维人员滥用权限，或这些设备自身存在安全漏洞。

3.6.5、第三方脚本与集成

风险场景：
1. 页面内集成的第三方JavaScript SDK（如分析工具、广告跟踪、社交媒体插件）可能会读取页面的完整URL（document.location.href）并回传至其服务器。
典型泄露点：第三方服务商的数据收集行为。

3.7、PII信息写入日志

3.7.1、简介

将PII写入日志是一个普遍存在且极易被低估的高危风险。与数据库明文存储不同，日志文件通常缺乏同等强度的保护措施，却可能成为攻击者首要目标。

下图揭示了PII从系统日志泄露的主要路径与核心风险点：

除了图中的风险，以下情况也尤为危险：

错误日志中的完整对象：在捕获异常时，将整个请求对象、用户对象或SQL查询结果打印到日志，其中可能包含身份证、手机号等。
调试日志未清除：临时开启的详细调试日志中记录了完整的业务流程数据，上线后忘记关闭。
第三方组件日志：集成的中间件、服务框架默认开启了信息收集，其日志可能包含它们处理的数据。

3.7.2、🛡️ 如何安全地处理日志中的PII？

遵循以下原则和技术可以大幅降低风险：

原则	具体措施	示例/工具
1. 绝不记录	设计时避免：明确禁止将特定PII（如密码、完整金融账号、生物特征）写入任何日志。在需求与设计评审中加入此环节。	建立“禁止日志字段清单”。
2. 如必须记，则脱敏	实时脱敏：在日志语句执行前，对敏感字段进行掩码、哈希或替换。	`张三`→`张`，`13800138000`→`138*8000`，`sfz-110101199003079876`→`sfz-110101******9876`
3. 访问控制	严格授权：将日志系统视同核心数据库，实施基于角色的访问控制与最小权限原则，所有访问留有审计痕迹。	使用堡垒机访问日志服务器，查询需申请临时权限。
4. 加密保护	静态加密：对存储的日志文件进行加密。传输加密：确保日志从应用服务器到集中存储（如ELK）的传输通道是加密的。	使用TLS传输，对日志文件使用AES-256加密存储。
5. 生命周期管理	定期清理：根据法规要求（如GDPR的存储最小化原则）和业务需要，制定并执行日志保留与安全销毁策略。	生产环境日志保留30天后自动归档并加密，180天后安全删除。

3.7.3、实施流程与检查清单🔍

3.7.3.1、数据分类与发现：

首先明确你的系统中哪些数据属于PII或敏感个人信息。
使用日志扫描工具（如grep配合正则表达式，或专门的敏感数据发现工具）对现有历史日志进行批量扫描，评估泄露现状。

3.7.3.2、开发规范与培训：

在开发规范中强制要求：禁止在日志中使用toString()方法打印整个对象，禁止打印未脱敏的敏感参数。
提供安全的日志工具类，封装脱敏方法。

3.7.3.3、代码审查与审计：

将日志安全作为代码审查的必查项。重点关注错误处理、调试信息、API入参出参打印等代码段。
审查常用日志模式：log.debug(“User info: {}”, user);log.error(“Query failed, params: ” + params, e);

3.7.3.4、监控与响应：

监控对日志文件的异常访问行为。
在事件响应计划中，明确包含“如果泄露的日志中包含PII”的应急处置流程。

3.8、API过度暴露

3.8.1、简介

API过度暴露是PII泄露的一个高频且严重的风险点。它通常指后端API接口在设计或实现时，返回了远超客户端（如前端App、浏览器）当前业务场景所需的数据字段，导致敏感数据“意外”泄露。

这就像一个客服只需查询你的订单状态，但系统却把你的完整档案（包括住址、身份证号、历史消费记录）都返回了；有的系统还在用户列表页面把所有的用户的密码返回到页面以隐藏的形式保存到页面，这样管理员就可以看到每一个用户的原始密码。

3.8.2、API过度暴露的典型场景🔍

“万能”详情接口：例如，一个用于前端个人中心展示的/api/user/profile接口，为了方便，直接返回了数据库User表的全部字段，包括密码哈希、身份证号、手机号等，但前端可能只渲染了昵称和头像。攻击者通过调用此API，即可获取所有信息。
列表接口包含详情：例如，一个查询用户订单列表的接口/api/orders，为了减少前端请求次数，在每个订单对象里嵌套返回了完整的用户详情对象，导致攻击者遍历订单列表就能获取大量用户的PII。
基于ID的枚举攻击：由于API设计为/api/users/{id}，且未对访问权限进行严格校验（属于不安全的直接对象引用）。攻击者只需简单遍历ID（如从1到10000），即可批量爬取所有用户数据。
响应结构不一致：同一个接口在不同情况下返回的字段不一致。例如，正常请求返回脱敏数据，但当传入某个特定参数或报错时，调试信息中却包含了完整的敏感数据对象。

3.8.3、为什么它如此危险？⚠️

隐蔽性强：数据在正常业务流程中被“合法”获取，而非通过入侵数据库，因此传统的WAF或防火墙难以察觉。
危害性大：一旦被利用，攻击者可以低门槛、自动化地批量窃取海量用户数据。
组合风险高：若与认证缺陷（如令牌易被盗用）或速率限制缺失结合，可在短时间内造成灾难性泄露。

3.8.4、系统性的预防与修复措施🛡️

措施维度	具体实践	说明与示例
1. 设计原则	最小化数据返回	API设计之初就应明确：“前端需要什么，我就只返回什么”。为不同的视图（View）定义专用的数据传输对象（DTO/ViewModel），而不是直接返回数据库实体（Entity）。
2. 权限校验	强制上下文访问控制	在API逻辑的最开头进行校验：“当前登录的用户是否有权访问其请求的目标数据？” 例如，校验`requestedUserId`是否等于`session.userId`。
3. 输入与输出处理	使用响应模型/序列化器	利用框架特性（如Jackson的`@JsonView`， .NET的`[JsonIgnore]`，或专门的序列化库）显式定义哪些字段在何种情况下可以输出。示例（Java/Spring）： `public class UserDto {` `@JsonView(Views.Public.class) private String username;` `@JsonView(Views.Internal.class) private String phone; // 敏感字段` `}`
4. 接口安全	实施速率限制与监控	对查询类API（尤其是带ID参数的）实施严格的请求速率限制，防止枚举攻击。监控异常访问模式（如单一IP/账号短时间内请求大量不同ID）。
5. 测试与审计	进行专门的API安全测试	渗透测试中必须包含“越权数据访问”测试项。自动化扫描工具可帮助发现暴露了过多字段的API端点。定期代码审查，检查数据实体到DTO的映射。

3.9、其他

漏洞场景	具体风险描述	防护核心与建议
1. 第三方服务与供应链	集成的短信/邮件服务商、云服务商、数据分析SDK、开源组件一旦被入侵或配置不当，其持有的数据会连带泄露。攻击者甚至通过入侵一个弱安全供应商，“跳板”攻击其主要客户。	合同约束与持续审计：在合同中明确数据保护责任；定期审查第三方安全报告与认证；实施最小化数据共享，仅提供必要信息。
2. 内部威胁与权限泛滥	拥有数据访问权的员工、外包人员或离职账户，可能因误操作、恶意或社交工程攻击（如钓鱼邮件）导致数据泄露。权限未遵循最小化原则，导致普通角色可访问超范围数据。	零信任与行为监控：实施严格的权限审批与定期复核；启用操作日志审计与异常行为告警（如非工作时间大批量下载）；加强全员安全意识培训。
3. 数据备份与归档介质	备份文件、数据库转储文件、测试环境数据通常包含生产数据的完整副本，但保护等级远低于生产系统。这些文件可能被未加密存储、传输或访问控制不当。	同等安全保护：对备份数据实施与生产环境同级的加密与访问控制；测试数据必须使用合成数据或经强脱敏处理的数据。
4. API接口过度暴露与设计缺陷	API默认返回所有用户字段，前端虽未展示，但攻击者可通过调用接口直接获取完整数据。API缺乏速率限制、认证薄弱，易被撞库或枚举攻击，批量爬取用户信息。	最小化与纵深防御：API设计遵循最小化返回原则；实施强认证、速率限制和请求签名；定期进行渗透测试。
5. 客户端存储与缓存	为方便将PII（如用户资料）存储在浏览器LocalStorage、SessionStorage或IndexedDB中，这些数据易受XSS攻击窃取。移动端应用将数据缓存至本地明文文件。	避免客户端存储敏感信息：敏感信息应只在内存中处理，或使用安全的服务端会话；如必须存储，应使用强加密并确保密钥安全。
6. 废弃数据与资产残留	系统下线、功能迭代或用户注销后，其关联的PII数据在数据库、日志、搜索引擎索引、CDN缓存中未被彻底清除，形成“数据僵尸”。	数据生命周期管理：建立明确的数据保留与销毁政策；下线流程必须包含数据清理确认环节；定期清理缓存与索引。

4、如何预防

4.1、漏洞类型与预防

漏洞类别/场景	核心根本原因	可行的预防措施 (技术与管理结合)
1. 注入类漏洞 (SQL, NoSQL, OS命令等)	未隔离的数据与代码	技术：所有查询使用参数化查询（预编译语句）或ORM框架；对输入实施严格的白名单验证；使用安全的API以避免命令拼接。管理：在安全编码规范中强制要求；将注入漏洞扫描纳入CI/CD流水线。
2. 配置与权限漏洞 (IDOR，越权，公开存储桶)	缺乏最小权限原则与验证	技术：实施基于角色的访问控制；对每次数据访问进行会话/令牌权限校验；使用云安全态势管理工具定期扫描公开资产。管理：执行定期的权限审计与复核；云存储配置遵循“按需开放，默认拒绝”原则。
3. 加密与传输漏洞 (明文传输，弱加密)	缺乏传输与静态加密	技术：全站强制使用HTTPS（TLS 1.3+），并启用HSTS；对存储的敏感PII使用强加密算法，并安全管理密钥；备份数据加密。管理：制定并执行加密策略，明确算法和密钥管理要求。
4. 日志与监控漏洞	敏感数据写入非受保护日志	技术：在日志框架中集成实时脱敏组件，自动掩码PII；禁止在日志中打印完整请求对象或用户对象；集中化管理加密日志。管理：明确“禁止记录”的PII清单；将日志系统纳入数据保护范围，严格控制访问权限。
5. URL传输漏洞 (GET参数，Referer等)	敏感数据通过URL明文传递	技术：禁止使用GET在URL中传递PII，改用POST Body；配置Web服务器、WAF等不记录包含PII的URL参数；设置安全的`Referrer-Policy`。管理：在API设计规范中明确禁止；对现有接口进行审计和改造。
6. 第三方与供应链风险	对第三方数据处理失去控制	技术：通过API网关实施对出站数据的过滤与脱敏；对集成的SDK进行安全扫描。管理：在合同中明确数据保护责任与审计权；定期评估第三方安全性；实施最小化数据共享。
7. 内部威胁与权限滥用	权限过度与行为失察	技术：实施零信任网络访问；对敏感数据操作进行完整的行为日志记录与异常告警。管理：执行严格的权限审批与定期复核制度；开展全员安全意识培训与钓鱼演练。
8. 数据备份与测试数据	非生产环境缺乏同等保护	技术：备份数据必须加密；测试环境使用合成数据或经过强脱敏（假名化/匿名化）的数据。管理：将备份介质与测试数据纳入数据安全管理范畴，制定专门策略。
9. API过度暴露	接口返回远超需要的数据	技术：API设计遵循最小化原则；为不同场景设计专用的数据返回视图；实施强身份认证、速率限制和请求签名。管理：将API安全测试作为上线前必需环节；定期进行渗透测试。
10. 客户端存储与缓存	敏感数据留存于不可控客户端	技术：避免在LocalStorage、Cookie中存储敏感PII；如需存储令牌，应使用Secure/HttpOnly Cookie；移动端缓存数据应加密。管理：在客户端安全开发规范中明确禁止条款。
11. 废弃数据与资产残留	缺乏数据生命周期管理	技术：为数据表设计逻辑删除标志和自动归档清理任务；建立自动化下线流程，清理缓存、索引和文件。管理：制定明确的数据保留政策；将数据清理作为系统下线流程的强制检查项。