---

theme: default themeName: "默认主题" title: "你的API密钥可能正在暗网流通——敏感信息泄露排查实战"

---

你的API密钥可能正在暗网流通——敏感信息泄露排查实战

去年帮一个客户做安全审计，发现他们的阿里云AccessKey、数据库密码、微信支付密钥全部在GitHub上公开可见——不是被黑客偷的，是他们自己的开发人员提交上去的。

更恐怖的是，这些密钥已经在暗网流通了至少2个月。期间有人用他们的阿里云账号跑了价值12万元的GPU算力挖矿。

敏感信息泄露是网络安全里最"无声"的威胁——不像勒索病毒那样大张旗鼓，它在你不知道的地方持续被利用。今天讲怎么系统地排查和治理这个问题。

泄露的主要渠道

根据我的实战经验，敏感信息泄露主要有这几个渠道：

1. 代码仓库（最常见） — GitHub/GitLab/Gitee上的公开仓库，提交记录里包含密钥 2. 配置文件打包 — 打包部署时把.env、config.json一起打了进去 3. 日志文件 — 应用日志里打印了请求参数，包含token和密钥 4. Docker镜像 — 镜像里打包了配置文件，推到了公开仓库 5. 前端代码 — API Key硬编码在JavaScript里，F12就能看到 6. 文档/知识库 — 内部Wiki、Confluence上写了连接信息

排查第一步：GitHub泄露检查

这是最高频的泄露渠道，优先排查。

用trufflehog扫描历史提交

# 安装trufflehog
go install github.com/trufflesecurity/trufflehog/v3@latest

扫描你的GitHub组织
trufflehog github --org=your-org-name --only-verified

扫描单个仓库的所有历史提交
trufflehog git https://github.com/your-org/your-repo --only-verified

`--only-verified`很重要——只显示验证过确实有效的密钥，排除误报。

用git-secrets预防未来泄露

# 安装git-secrets
git clone https://github.com/awslabs/git-secrets cd git-secrets && make install

在仓库中启用
cd your-repo git secrets --install git secrets --register-aws  # 检测AWS密钥模式

自定义检测规则
git secrets --add 'password\s=\s["\x27].+["\x27]' git secrets --add 'secret_key\s=\s["\x27].+["\x27]' git secrets --add 'api_key\s=\s["\x27].+["\x27]'

启用后，`git commit`时如果检测到密钥模式会自动拦截。

GitHub官方的Secret Scanning

如果你用GitHub Enterprise，开启Secret Scanning功能：

1. 进入仓库Settings → Code security and analysis 2. 开启Secret scanning 3. 开启Push protection（提交时拦截）

GitHub维护了一个超过200种密钥模式的检测库，覆盖AWS、Azure、GCP、Slack、Stripe等主流服务。

排查第二步：代码仓库全面扫描

不只是GitHub，你内部的所有代码仓库都要扫描。

Gitleaks——更全面的开源扫描工具

# 安装
go install github.com/gitleaks/gitleaks/v8@latest

扫描当前目录
gitleaks detect -v

扫描特定仓库的所有历史
gitleaks detect --source /path/to/repo -v

只扫描未提交的变更（CI/CD集成）
gitleaks protect -v

自定义规则
cat > .gitleaks.toml << 'EOF' [[rules]] id = "custom-db-password" description = "Database Password"

regex = '''(?i)(db_password
database_password
mysql_password)\s[:=]\s["\x27]?[^\s"'\x27]{8,}'''

tags = ["key", "database"]

[[rules]] id = "custom-jwt-secret" description = "JWT Secret"

regex = '''(?i)(jwt_secret
jwt_key
token_secret)\s[:=]\s["\x27]?[^\s"'\x27]{16,}'''

tags = ["key", "jwt"] EOF

gitleaks detect --config-path .gitleaks.toml -v

CI/CD集成

在GitLab CI中集成gitleaks：

# .gitlab-ci.yml
gitleaks:   stage: test   image: zricethezav/gitleaks:latest   script:     - gitleaks protect -v --redact   rules:     - if: $CI_PIPELINE_SOURCE == "merge_request_event"

排查第三步：日志和监控审查

很多应用会在日志里打印敏感信息，自己都不知道。

# 搜索日志中的可疑内容

grep -rn "password\
secret\
token\
api_key\
access_key" /var/log/myapp/ --include="*.log"
head -50


搜索常见的密钥模式

grep -rnE '(AKIA[0-9A-Z]{16}
eyJ[A-Za-z0-9-_]+
sk_live_[0-9a-zA-Z]+)' /var/log/ --include="*.log"

代码层面排查：

# 搜索代码中的敏感日志输出

grep -rn "log\.\(info\
debug\
warn\).*\(password\
token\
secret\)" src/
grep -rn "System.out.println.*\(password\
token\)" src/
grep -rn "console.log.*\(password\
token\
key\)" src/

修复方案——日志脱敏：

// 不要这样
log.info("User login: password={}", password);

// 应该这样 log.info("User login: password=");

// 或者用工具自动脱敏 log.info("User login: {}", MaskUtil.mask(request));

排查第四步：Docker镜像检查

# 检查镜像中的敏感文件
docker run --rm -it your-image:latest find / -name ".env" -o -name ".key" -o -name ".pem" -o -name "config.json" -o -name "credentials" 2>/dev/null

检查镜像历史（看Dockerfile里有没有COPY敏感文件）
docker history --no-trunc your-image:latest

更彻底：导出镜像文件系统检查
docker create --name inspect your-image:latest

docker export inspect
tar -tvf -
grep -E '\.(env
key
pem
p12
jks)$'

docker rm inspect

排查第五步：前端代码检查

# 扫描前端JS文件中的密钥

find /var/www -name "*.js" -exec grep -l "api_key\
apiKey\
API_KEY\
secret\
token" {} \;


更精确的模式

grep -rnE '(api[_-]?key
secret[_-]?key
access[_-]?key)\s[:=]\s["\x27][^"\x27]{10,}' /var/www/

前端泄露特别危险——任何人F12就能看到。解决方案：

1. 敏感操作走后端代理，不在前端暴露任何密钥 2. 如果必须前端使用（如地图API Key），设置IP/域名白名单限制

泄露后的应急处置

发现密钥泄露后，立即按以下步骤处理：

1. 立刻轮换密钥。 不要先删代码，先换密钥。代码删了，暗网副本还在。

2. 审查使用记录。 登录云服务商控制台，查看该密钥的操作日志。

# 阿里云ActionTrail查询
aliyun actiontrail LookupEvents --KeyList '["AccessKeyId"]' --ValueList '["LTAI5t..."]'

AWS CloudTrail查询
aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIA...

3. 删除GitHub历史。 如果密钥在历史提交中，仅仅删除当前代码是不够的。

# 用BFG清除历史
git clone --mirror https://github.com/your-org/your-repo java -jar bfg.jar --replace-text passwords.txt your-repo.git cd your-repo.git git reflog expire --expire=now --all git gc --prune=now --aggressive git push

4. 通知相关方。 如果泄露的密钥涉及第三方服务，通知对方采取防护措施。

长期治理方案

排查只是治标，要治本需要建立制度：

1. 密钥统一管理 — 使用HashiCorp Vault、AWS Secrets Manager或阿里云KMS集中管理密钥，代码中不硬编码。

2. Pre-commit Hook — 开发者提交代码前自动扫描密钥。

3. CI/CD门禁 — 流水线中集成gitleaks，检测到密钥自动阻断。

4. 最小权限 — 每个服务只用自己需要的最小权限密钥，出了问题爆炸半径小。

5. 定期轮换 — 设置密钥过期时间，强制定期轮换。

6. 暗网监控 — 订阅Have I Been Pwned或Flare等暗网监控服务，发现泄露立即告警。

做IT这么多年，见过太多"早知道就好了"的情况。

希望这篇文章能帮你少走弯路。如果真的遇到问题，别一个人扛着——易云城IT服务随时待命。

📞 服务热线：13708730161 💬 微信：eyc1689 📧 邮箱：service@eycit.com 🌐 https://www.eycit.com

您身边的IT专家。