3. 理解Secrets审计：什么是敏感信息泄露
说实话，很多刚接触安全审计的同事，第一反应就是——我的日志里有没有密码？
对，也不全对。
密码只是敏感信息的冰山一角。我见过不少团队，把明文写在配置里，然后日志还全量输出，那真是“裸奔”。今天我们就来聊聊，到底什么是敏感信息泄露，以及在Secrets审计中，我们到底要盯住哪些东西。
3.1 敏感信息泄露的定义
说白了，敏感信息泄露就是那些不该出现在日志、配置、代码里的数据，意外暴露了。你想想看，日志本来是帮我们排查问题的，结果成了黑客的“内鬼”。
我个人的习惯是，只要符合下面任意一条，就算敏感信息：
- 凭据类：密码、密钥、、证书。这些一眼就能认出来。
- 身份类：身份证号、手机号、邮箱、家庭住址。很多日志会把用户信息全量打印。
- 业务敏感类：交易金额、余额、订单详情。金融日志尤其要注意。
- 内部结构类：IP、内网域名、数据库连接串、文件路径。这些暴露了，攻击面就大了。
关键点：敏感信息泄露不一定是明文密码。一个数据库连接字符串，如果包含用户名和IP，在审计眼里就是高危。
我在项目中遇到过，某团队把用户手机号做了脱敏，但日志里同时打印了用户ID和手机号——这跟没脱敏一个样。为什么？因为攻击者可以关联数据。
3.2 典型类型一览
| 类型 | 常见例子 | 泄露风险等级 |
|---|---|---|
| 凭据 | 密码、、JWT 、SSH密钥 | 极高 |
| 个人身份 | 身份证号、护照、手机号、邮箱 | 高 |
| 财务数据 | 信用卡号、银行账号、交易记录 | 极高 |
| 内部信息 | 内网IP、数据库地址、服务端口、目录结构 | 中 |
| 业务数据 | 订单详情、医疗记录、合同内容 | 高 |
3.3 为什么敏感信息会出现在日志里？
这个问题我问过很多团队。答案无非几种：
- 开发习惯：写日志时顺手把整个对象打印了，结果对象里有敏感字段。
- 调试残留：上线前忘记删调试日志。
- 框架默认行为：很多Web框架会默认打印请求参数，包括密码。
- 第三方库：引用的SDK自己写日志，你管不了。
- 误报：本来想脱敏，结果脱敏函数没生效。
我曾经帮一个客户做审计，发现他们的支付日志里，每次请求都打印了完整的信用卡前六位和后四位。嗯，这就是典型的敏感信息泄露。虽然没全打印，但结合交易时间、金额，攻击者照样能拼出线索。
3.4 Secrets审计中的核心识别原则
在ELK里做Secrets审计，说白了就是个“找茬”的活儿。但怎么找，得有方法。
我自己总结了三步走：
我的经验：先用正则扫显性敏感信息（如密码、），再用模式匹配找结构化的敏感数据（如身份证号、信用卡号），最后用上下文分析判断是否真的泄露。
- 显性识别：关键词匹配。比如日志中出现
password=、secret=、=。这些一眼就能揪出来。 - 模式识别：用正则匹配格式。比如
\b\d{16}\b可能是一张卡号，\d{17}[0-9Xx]可能是身份证号。这需要维护一个规则库。 - 上下文判断：光匹配到还不够。比如日志里出现了“password”，但上下文是“password字段被脱敏为****”——这时候其实不算泄露。我见过很多误报，就是因为没做上下文过滤。
举个例子。某系统日志里出现：
2025-02-18 10:30:22 [INFO] 用户登入请求: username=admin, password=123456, ip=10.0.0.1这种日志，密码裸奔，IP还是内网。如果被刷到Kibana里，ELK审计一搜一个准。
那处理后的日志应该是什么样？
2025-02-18 10:30:22 [INFO] 用户登入请求: username=admin, password=****, ip=10.0.0.1 (internal)嗯，这样就好多了。密码脱敏，IP标记为内网，审计时可以降低风险等级。
3.5 审计中的处理决策流程
当ELK发现一条潜在敏感信息日志时，你得决定怎么处理。我把它画成了一个简单的决策流程，你看一眼就明白了。
你看这个流程，核心就是两步判断：攻击行为 vs 意外泄露。攻击行为直接告警、阻断，甚至联动防火墙封IP。意外泄露则走评估、修复流程。
我常用的做法是：在ELK里建两个索引，一个叫secrets-attack，一个叫secrets-leak。攻击类告警给安全运营同事，泄露类告警给开发团队。
特别注意：不要把所有敏感信息都当成攻击。一个开发在调试时打印了密码，跟一个黑客用SQL注入拿密码，处理方式完全不同。我曾经见过团队把所有敏感信息日志都误判为攻击，结果运营同事每天几千条误报，最后干脆不看告警了。安全审计最怕的就是“狼来了”。
3.6 如何从日志中准确识别敏感信息
实际操作中，我建议用三层过滤：
- 预置规则层：ELK里自建一些正则，比如匹配密码、身份证、卡号。这个层不漏掉明显的敏感信息。
- 模式发现层：用机器学习或统计方法，发现日志中的异常模式。比如某个字段突然出现大量Base64编码字符串——这很可能是凭据泄露。
- 人工审核层：对于高风险的敏感信息，建议设置人工审核队列。机器可以筛出90%的误报，但剩下10%需要人来看。
我个人习惯把前两层做成Elasticsearch的Ingest Pipeline，这样日志一进来就自动处理了。
PUT _ingest/pipeline/sensitive_data_detection
{
"description": "敏感信息检测管道",
"processors": [
{
"grok": {
"field": "message",
"patterns": ["(?<sensitive_data>.*password.*)"]
}
},
{
"set": {
"field": "security.severity",
"value": "high"
}
}
]
}这段代码的意思：只要日志里出现“password”，就自动打上高危标签。当然，实际规则要复杂得多。
好了，关于敏感信息泄露的定义、类型、识别原则，还有处理流程，基本上就这些了。第三章的核心就一句话——知道哪些数据不能出现在日志里，并且能在ELK里快速把它揪出来。