第二章 常见凭据类型与识别模式归纳总结

做DLP凭据扫描，第一步就是搞清楚——你到底要找什么？

我刚开始带团队搞数据防泄漏时，总以为凭据就那么几种：密码、、。结果被生产环境教育了一次：客户发来的样本里，连Kubernetes Service Account的JWT都混在日志里。从那以后我就养成了一个习惯——先把“敌人”的清单列清楚。

这一章没有复杂的算法。就是帮你建立一张“凭据地图”。把常见类型、长什么样、怎么用正则或关键词去抓，一次性说透。

2.1 凭据的“家族谱系”

凭据可以按用途分为四大类。我自己习惯这么分：

• 认证凭据：证明你是谁。比如用户名+密码、LDAP绑定、SSH密钥对。
• 授权凭据：允许你干什么。比如OAuth 2.0 Access 、Refresh 、JWT。
• API调用凭据：机器跟机器打招呼用的。比如AWS Access Key + Secret Key、阿里云AccessKey、GitHub Personal Access 。
• 基础设施凭据：数据库连接串、Redis密码、Kubernetes Service Account 、TLS证书私钥。

你想想看，如果把所有凭据混在一起拿正则硬扫，误报率会高到你怀疑人生。我见过有人用一个 password 关键字搜全量日志，结果把“password reset link”也标记成泄密——这显然不对。

2.2 各类凭据的“指纹”模式

每种凭据都有自己的格式特征。下面这张表是我整理了多个项目的发现，直接拿去用没问题。

2.3 识别模式的三层过滤法

光靠正则不够。我在生产线上总结了一个三层过滤流程，现在团队一直在用：

1. 第一层：快速关键词预筛。用 password、secret、、key、jwt 等常见关键词把可能行缩小到1%以内。
2. 第二层：格式正则精确匹配。针对每种凭据类型使用上表中的正则模式，把格式符合的片段挑出来。
3. 第三层：上下文验证去噪。检查命中位置前后50个字符，排除掉 example、test、placeholder 等样例标记，再判断是否属于配置注释而非真实凭据。

举个例子，一个文本里出现 password=123456，关键词筛出 password，正则 password=[^&\s]+ 命中，然后上下文没有 test 或 example，就标记为高风险。如果后面跟着 // just for development，那就降到低风险。

2.4 凭据类型与识别模式关系图

下面这张图总结了常见凭据类型和对应的识别模式。你可以把它贴在团队的白板上。

2.5 实战中的“暗坑”笔记

你以为看明白了表就能写好规则？来，我给你列几个我踩过的坑：

• JWT三个点不能少： 有些JWT只有两个点（缺签名部分），不能算有效凭据。正则里要写 \.[A-Za-z0-9\-_]+$ 结尾匹配。
• Base64编码里的凭据： AWS Secret Key被Base64编码后变成了乱码。我后来在第三层加了“如果命中的文本符合Base64特征，就解码后再跑一次正则”。
• 代码注释里的假阳性： 比如 // test_password = "thisistest"，正则命中但上下文出现 test 或 example，建议降权或跳过。
• 多行私钥的断行问题： SSH私钥跨行时，不能按单行正则处理。我用 -----BEGIN.*PRIVATE KEY----- 做起始锚点，然后跨行匹配到结束标记。