第1章 DLP概述与凭据安全风险归纳总结
1.1 什么是DLP？为什么需要它？
DLP，全称Data Loss Prevention，数据防泄漏。说白了，就是一套技术组合拳——帮你盯着敏感数据别跑出去。
我刚开始做安全那会儿，觉得DLP不就是个关键字匹配加正则么？后来在客户现场碰了个硬钉子：对方把几百个数据库连接串明文写在了配置文件里，还随手传到了GitHub公开仓库。两个小时后，云上数据库被勒索。嗯，从那以后我再看DLP，眼神都不一样了。
DLP的核心就三件事：
- 发现——找到藏在哪儿的敏感数据
- 监控——看数据怎么流动、谁在碰它
- 保护——该拦的拦，该脱敏的脱敏
凭据，就是那类最要命的敏感数据。密钥、令牌、密码、证书……哪个不是一泄露就“爆炸”的东西？所以凭据扫描，就是DLP的第一道防线。
1.2 凭据安全风险面面观
凭据到底有哪些？我归结了最常见的几类：
| 凭据类型 | 典型例子 | 泄露后果 |
|---|---|---|
| 硬编码密码 | 数据库连接串中的明文密码 | 数据库被拖，数据全量泄露 |
| /令牌 | AWS Secret Key、GitHub Personal | 云资源被滥用，账单爆炸 |
| 证书私钥 | .pem文件、JKS密钥库 | HTTPS被劫持，中间人攻击 |
| 会话令牌 | JWT、Session ID | 用户身份被冒用，权限失控 |
| 环境变量中的敏感值 | 加密盐、初始化向量 | 加密失效，系统被攻破 |
注意： 我见过最离谱的案例——某团队把生产环境的root密码写在Spring Boot的application.yml里，还提交到了git的master分支。你想想看，只要仓库权限没锁死，整个公司的基础设施就等于裸奔。
1.3 凭据泄露的典型场景
凭据不会自己“跑出去”，但现实中常见的泄露路径有这几条：
- 代码仓库外泄——开发人员误提交包含凭据的配置文件，或者.git目录被暴露。
- 日志与错误栈——异常信息里顺手打印了数据库密码或，日志系统又没脱敏。
- 构建产物与制品——Docker镜像、JAR包里埋了明文凭据，被拉到公开仓库。
- 协作工具误发——Slack、钉钉、邮件里直接贴了密钥，别人一搜就搜到。
- 第三方SDK/API调用——回调URL参数或请求头里带了令牌，日志记录时又没做脱敏。
我曾经帮一家金融科技公司做安全审计，发现他们的核心业务日志里，居然把用户的支付令牌当作普通参数打印了出来。那日志文件有几十个TB，且保留周期是180天。你想想，如果日志系统被入侵，那后果……
1.4 凭据扫描与脱敏的必要性
扫描，就是把这些藏起来的凭据“揪出来”。脱敏，就是在数据流出之前把凭据“抹掉”。缺哪个都不行。
关键原则： 扫描要全量、定时、增量；脱敏要就地、实时、不可逆。不能只扫一次就完事，也不能脱敏后还能还原回去。
从技术实现上看，凭据扫描需要：
- 基于模式匹配（正则、指纹）和上下文分析
- 支持多种文件格式和编码（包括Base64、压缩包）
- 低误报率——不然运维团队会疯
而SDK级脱敏，指的是在应用程序内部，以SDK形式嵌入脱敏逻辑，在数据写入日志、发送消息、返回API响应时自动处理。我习惯把这叫作“防君子也防小人”：既挡住外部攻击者，也防止内部开发人员无意泄露。
个人小建议： 没必要一开始就追求99.9%的覆盖率。先扫最容易出问题的——比如.git目录、application.properties、Dockerfile、CI/CD的yaml文件。我每次带团队做凭据扫描，都是从这四类文件开始，一抓一个准。
1.5 本章小结
DLP不是锦上添花，是雪中送炭。凭据作为最敏感的一类数据，一旦泄露就是安全事故。扫描是“主动发现”，脱敏是“被动防御”，两者搭配才能形成闭环。
我个人习惯把凭据安全归纳为三句话：知道它在哪，知道它在流，知道它被改了。后面章节咱们会深入每个环节的实操手法，包括怎么定义扫描规则、怎么在SDK里做高性能脱敏。