3、敏感字段定义与分类：个人身份信息（PII）、认证凭证、设备标识、地理位置、支付信息等

在端侧诊断日志的治理工作中，第一步并非编写扫描规则，而是建立一套清晰、可执行、可扩展的敏感字段分类体系。端侧日志与服务器日志有显著差异：它们产生于用户设备（手机、平板、IoT 网关、车载终端等），往往包含实时传感器数据、应用运行状态、网络连接参数以及用户行为痕迹。若缺乏明确的字段定义与分类标准，扫描引擎要么因规则过宽产生大量误报，要么因覆盖不全导致敏感数据泄露。本章将系统阐述五类核心敏感字段的定义边界、识别特征、分类方法及在日志中的典型呈现形态，为后续扫描与拦截策略奠定语义基础。

上图展示了端侧日志敏感字段分类的整体框架。需要特别强调的是，这五类字段并非完全互斥——例如，一个设备标识（如 MAC 地址）在特定场景下可能同时关联到用户身份（PII），而支付信息中往往包含设备标识和地理位置。因此，在实际工程落地时，我们不仅要关注字段本身的语义，还要关注字段之间的关联关系以及它们在日志上下文中的组合暴露风险。下面逐一展开每类字段的定义、识别方法与处理要点。

3.1 个人身份信息（PII）——最广泛也最容易被忽视的敏感字段

核心原理：PII 的边界与粒度

个人身份信息（Personally Identifiable Information, PII）是指能够直接或间接识别到特定自然人的数据。在端侧日志中，PII 的呈现形式极为多样，既包括显式的姓名、身份证号、手机号，也包括隐式的性别+年龄+职业+居住地组合、社交关系链、行为偏好等。根据 GDPR、PIPL（《个人信息保护法》）等法规要求，PII 的收集与处理必须遵循最小必要原则，而日志系统往往在无意识状态下记录了远超业务必要范围的 PII。

从工程角度看，PII 的识别难点在于其非结构化和上下文依赖。例如，一段日志中出现的"138****1234"可能是一个手机号，也可能是一个订单号；"张三"可能是用户名，也可能是备注信息。因此，单纯依赖正则表达式无法覆盖所有 PII 场景，必须结合字段路径（如 user.name、contact.phone）、数据格式（如 11 位数字以 1 开头）以及上下文关键词（如 phone=、mobile=）进行综合判断。

判断方法：PII 识别四步法

1. 字段路径分析：检查日志 JSON 或 key-value 结构中的字段名，优先关注包含 user、person、contact、profile、customer 等前缀的字段。
2. 格式模式匹配：对字段值进行正则校验，如中国大陆手机号 ^1[3-9]\d{9}$、身份证号 ^\d{17}[\dXx]$、邮箱 ^[\w.+-]+@[\w-]+\.[\w.]+$。
3. 上下文语义推断：当字段名不明确时，结合同一行日志中的其他字段进行推断。例如，{"name":"张伟","age":35,"city":"上海"} 虽然单个字段不构成直接 PII，但组合后可以间接识别到个人。
4. 数据字典比对：建立企业级 PII 数据字典，将已知的敏感字段路径、样例值、脱敏规则纳入统一管理，实现持续迭代。

案例拆解：一个典型的用户注册日志

假设某 IoT 设备在用户注册时输出如下日志：

[2025-06-01 09:15:32] [INFO] register_success uid=10086 username=zhangsan phone=13812341234 email=zhangsan@example.com id_card=310101199001011234

这段日志中，username、phone、email、id_card 均属于直接 PII，且 id_card 属于法律明确规定的敏感个人信息。若该日志被上传至云端日志平台，一旦发生泄露，将导致用户身份被冒用、电信诈骗等风险。正确的处理方式是在日志输出前进行脱敏：

[2025-06-01 09:15:32] [INFO] register_success uid=10086 username=zh***san phone=138****1234 email=zh***@example.com id_card=310101********1234

3.2 认证凭证——泄露后果最严重的敏感字段

核心原理：认证凭证的范畴与生命周期

认证凭证（Authentication Credentials）是用于验证用户或设备身份的机密信息，包括但不限于：密码（Password）、访问令牌（Access Token）、刷新令牌（Refresh Token）、API 密钥（API Key）、会话标识（Session ID）、数字证书私钥、OAuth 授权码等。在端侧日志中，认证凭证通常出现在登录流程、网络请求、缓存刷新、后台同步等场景。与 PII 不同，认证凭证的泄露往往导致直接的系统入侵风险，攻击者可利用泄露的 Token 冒充合法用户调用后端 API，造成数据窃取或业务欺诈。

特别需要警惕的是，现代应用普遍采用 JWT（JSON Web Token）作为认证机制。JWT 由 Header、Payload、Signature 三部分组成，其中 Payload 是 Base64 编码的 JSON 数据，并未加密。如果日志中记录了完整的 JWT，攻击者只需解码 Payload 即可获取 sub（用户标识）、exp（过期时间）、role（角色权限）等敏感信息，甚至可能通过篡改算法类型（如将 RS256 改为 HS256）尝试伪造 Token。

判断方法：凭证字段的识别特征

凭证类型	典型字段名	格式特征	风险等级
密码	password, pwd, passwd	任意字符串，通常不满足正则规则	极高
JWT Token	token, access_token, jwt	三段式 Base64URL，以 . 分隔	极高
API Key	api_key, apikey, client_secret	16-32 位随机字符串，可能含连字符	高
Session ID	session_id, sid, jsessionid	32 位十六进制或 Base64 字符串	高
私钥	private_key, pem, key	以 -----BEGIN 开头	极高

实战场景：日志中的 Token 泄露排查

在一次端侧应用安全审计中，我们发现某 Android 应用在每次网络请求失败时，会将完整的请求头写入日志文件，其中包含 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMDA4NiIsInJvbGUiOiJhZG1pbiIsImV4cCI6MTc1MDAwMDAwMH0.signature。该日志文件被第三方 SDK 自动上传至开发者的日志分析平台，且未设置访问控制。攻击者通过 GitHub 搜索该应用的日志上传接口，获取了管理员的 JWT，进而调用管理接口获取了全量用户数据。

复盘此案例，核心问题在于：日志输出时未对认证凭证进行任何过滤。正确的做法是：

• 在日志框架层（如 Logback、Timber）配置全局过滤器，拦截包含 Authorization、token、password 等关键字的日志条目。
• 对必须记录的 Token 进行截断处理，仅保留前 10 个字符用于问题定位。
• 使用 @Sensitive 注解标记数据模型中的敏感字段，在序列化时自动脱敏。

3.3 设备标识——端侧日志特有的敏感维度

核心原理：设备标识的多样性与稳定性

设备标识（Device Identifiers）用于唯一识别一台物理设备或安装实例，包括 IMEI（国际移动设备识别码）、MEID、MAC 地址、UDID（iOS 唯一设备标识）、Android ID、OAID（匿名设备标识）、设备序列号（Serial Number）等。在端侧日志中，设备标识通常作为日志的公共维度出现，用于关联同一设备在不同时间点的行为轨迹。然而，设备标识本身具有长期稳定性和跨应用关联性，一旦泄露，攻击者可以追踪特定用户的行踪，甚至结合其他数据源实现用户画像。

值得注意的是，IMEI 和 MAC 地址在 Android 10+ 和 iOS 14+ 中已受到系统级访问限制，应用无法直接获取。但部分老旧设备或特殊场景（如企业定制 ROM、IoT 设备）仍可能输出这些字段。此外，WiFi 的 BSSID（路由器 MAC 地址）也属于设备标识的范畴，可用于推断用户的地理位置。

判断方法：设备标识的识别与分级

• 永久标识：IMEI、MEID、MAC、设备序列号——不可重置，风险最高，应默认禁止输出到日志。
• 半永久标识：Android ID、UDID——可重置但频率低，需脱敏后使用。
• 可重置标识：OAID、IDFA——用户可主动重置，风险相对可控，但仍需注意关联分析风险。

案例拆解：IoT 网关日志中的设备指纹

某智能家居网关在每次上报状态时输出：

{"device_id":"GW-2025-0001","mac":"AA:BB:CC:DD:EE:FF","sn":"SN1234567890","firmware":"v2.1.0","status":"online"}

其中 mac 和 sn 属于永久设备标识。虽然网关是固定设备，但若该日志被第三方云平台存储，且平台发生数据泄露，攻击者可通过 MAC 地址反查设备所在网络，进而定位家庭住址。处理方案是：将 mac 替换为哈希值（如 SHA-256），并截断 sn 仅保留后 4 位。

3.4 地理位置——时空维度的敏感信息

核心原理：位置数据的间接识别能力

地理位置（Geolocation）包括 GPS 经纬度、基站 Cell ID、WiFi 热点位置、IP 地址归属地、蓝牙 Beacon 位置等。位置数据具有时空关联性，单点位置可能不敏感，但连续的位置轨迹可以揭示用户的工作地、居住地、生活习惯、健康状况（如频繁访问医院）等隐私信息。在端侧日志中，位置数据通常由定位 SDK 自动附加，或由业务逻辑在特定场景（如打卡、导航、附近推荐）中主动记录。

从法律角度看，精确位置信息（如 GPS 坐标）在中国《个人信息保护法》中被列为敏感个人信息，处理前需取得用户单独同意。而粗略位置（如城市级别）的敏感等级相对较低。因此，日志系统需要区分精确位置和粗略位置，并采用不同的脱敏策略。

判断方法：位置字段的识别与脱敏

位置类型	字段示例	精度	脱敏策略
GPS 经纬度	latitude, longitude, lat, lng	米级	网格化（如保留 2 位小数）或偏移
基站信息	cell_id, lac, mcc, mnc	百米级	哈希 Cell ID
WiFi 信息	bssid, ssid, rssi	十米级	BSSID 哈希，SSID 过滤
IP 地址	ip, client_ip, src_ip	城市级	保留前 3 段，最后一段置 0

实战场景：地图 SDK 的日志泄露

某出行应用集成了第三方地图 SDK，该 SDK 在调试模式下会将每次定位结果输出到系统日志：

D/LocationClient: onLocationChanged: 31.230416, 121.473701, accuracy=5.0m, provider=gps

由于该应用未关闭 SDK 的调试日志，任何拥有设备 ADB 权限的人（如维修人员、恶意应用）都可以读取精确位置。更严重的是，日志中未包含时间戳，但系统日志本身带有时间，攻击者可以拼接出用户完整的出行轨迹。修复方案包括：在发布版本中强制关闭 SDK 调试模式、在日志输出层拦截 LocationClient 标签、对坐标进行网格化处理（如将 31.230416 转换为 31.23）。

3.5 支付信息——高价值目标与强监管字段

核心原理：支付信息的范围与合规要求

支付信息（Payment Information）涵盖银行卡号（PAN）、信用卡有效期、CVV/CVC 安全码、支付令牌（Payment Token）、交易金额、订单号、支付渠道流水号、余额信息等。其中，银行卡号、有效期、CVV 属于 PCI DSS（支付卡行业数据安全标准）明确禁止存储的字段（除非经过加密或令牌化）。在端侧日志中，支付信息通常出现在支付 SDK 的回调、订单状态更新、对账异常等场景。

需要特别注意的是，支付令牌（如支付宝的 trade_token、微信的 prepay_id）虽然不等同于银行卡号，但可用于发起支付请求，同样属于高敏感字段。此外，交易金额和订单号虽然单独看敏感度不高，但结合用户 ID 和时间戳，可以分析用户的消费能力和消费习惯，属于间接 PII。

判断方法：支付字段的识别清单

• 卡号类：字段名包含 card_no、pan、account_no，值符合 Luhn 算法校验的 13-19 位数字。
• 安全码类：字段名包含 cvv、cvc、cid，值为 3-4 位数字。
• 令牌类：字段名包含 token、prepay_id、transaction_id，值为 16-64 位随机字符串。
• 金额类：字段名包含 amount、price、total_fee，值为数字且可能带货币单位。

案例拆解：支付回调日志的脱敏改造

某电商 App 在支付成功后输出如下日志用于对账：

[2025-06-01 14:22:10] [INFO] pay_callback order_id=20250601142210001 user_id=10086 amount=299.00 card_no=6222021234567890 bank=ICBC

该日志存在两个问题：一是记录了完整的银行卡号，违反 PCI DSS 要求；二是 user_id 与 order_id 关联后，可查询到用户的购买记录。改造后的日志应仅保留对账所需的最小字段：

[2025-06-01 14:22:10] [INFO] pay_callback order_id=20250601142210001 amount=299.00 card_last4=7890 bank=ICBC

同时，order_id 与 user_id 的关联关系应通过后端安全接口查询，而非直接输出到日志。

3.6 分类体系的工程落地与常见误区

核心原理：从分类到策略的映射

敏感字段分类的最终目的是驱动扫描与拦截策略。在工程实践中，我们需要为每一类字段定义：检测规则（正则、关键词、机器学习模型）、处置动作（脱敏、丢弃、告警、阻断上传）、审计要求（记录谁在何时访问了该字段）。建议建立如下映射表：

敏感类别	默认处置	可配置选项	审计级别
PII	脱敏（保留部分字符）	加密、假名化	中
认证凭证	丢弃或截断	哈希（仅用于比对）	高
设备标识	哈希或替换	截断、加密	中
地理位置	网格化	偏移、模糊化	低
支付信息	丢弃（除 last4）	令牌化	极高

常见误区与复盘

• 误区一：只关注字段名，不关注字段值。例如，字段名为 data 但值可能是 Base64 编码的身份证号。需要结合值的内容进行二次判断。
• 误区二：脱敏后即认为安全。如将手机号中间 4 位替换为 *，但若攻击者知道归属地和尾号，仍可暴力枚举。建议采用可逆加密或更彻底的假名化。
• 误区三：忽略日志上下文中的组合风险。单个字段可能不敏感，但多个字段组合后可以识别到个人。例如，{"age":35,"gender":"male","zip":"200000"} 可唯一确定约 87% 的用户。
• 误区四：分类规则一成不变。随着业务发展和法规更新，敏感字段的范围会动态变化。建议每季度审查一次分类字典，并纳入新的字段模式。