第1章：课程概览——为什么需要采集Secrets审计日志？ELK能做什么？整体架构图

1.1 为什么非要盯住Secrets审计日志？

你先想想看，一个公司的“命根子”是什么？不是代码，不是服务器IP，而是那些密钥、凭证、、数据库密码。这些玩意一旦泄露，别人可以直接进你的系统，拿你的数据，删你的库。

我刚开始做安全运维那几年，其实不太重视Secrets审计。总以为密钥放在Vault里，权限卡死就安全了。结果呢？有一次客户那边，一个开发把AWS Access Key硬编码在GitHub公开仓库里，半小时后云账单就多了几万刀。后来一查，根本不知道是谁什么时候提交的，也没人告警——因为没有审计日志。

说白了，没有Secrets审计日志，你等于在黑暗里管金库。你不知道谁碰了密钥，谁创建了，谁在凌晨三点读取了数据库密码。合规要求（比如SOC 2、PCI DSS）也明确要求你记录所有对敏感凭证的访问和变更。

1.2 ELK能帮我们干哪些事？

ELK不是银弹，但它对付审计日志确实有一套。我总结下来，核心就四点：

• 统一采集：不管你的Secrets来源是Vault、AWS Secrets Manager、GitHub Actions、Kubernetes，还是自研的密钥中心，ELK都能通过各种各样的Beats、插件或API把日志收过来。
• 实时解析：原始日志通常是乱七八糟的JSON、Syslog或者纯文本。Logstash可以按规则拆字段、标准化，把“谁、何时、从哪里、做了什么”变成整齐的结构化数据。
• 长期存储与检索：Elasticsearch管存储和搜索。你可以快速查出“上周二谁访问了production数据库密码”。
• 可视化与告警：Kibana画仪表盘，你一眼就能看到异常峰值。配置Watcher或Elastic Alert，一有敏感操作立马发钉钉、Slack。

举个我实际做过的例子：一个金融客户需要审计所有Vault中“管理员角色”的操作。用Filebeat监控Vault审计文件，Logstash解析出operation: read且path: /secret/production/*的事件，索引到ES。Kibana上搞个折线图，每天正常量是200次，某天突然飙到5000次？立刻触发告警。那次真抓到了一个内部人员批量导密钥的行为。

1.3 整体架构长什么样？

下面这张图是我在设计这类系统时的标准参考架构。数据从左到右流动：从各种Secrets源，经过采集层，再到缓冲/处理层，最后落地到ELK核心。

1.4 为什么不直接用Secrets管理工具自带的审计？

很多工具自带的审计功能确实能用，但坑也不少。我列个表让你对比一下：

对比维度	自带审计（Vault/AWS/K8s）	ELK统一审计平台
日志来源	单一工具	聚合所有Secrets源
存储时长	一般只保留几天或几周	按需配置，可保存数月甚至数年
跨源关联	无法跨系统关联操作	可以关联“同一个用户在Vault和AWS同时做了什么”
可视化	命令行或简单界面	Kibana仪表盘，柱状图、地图、时间线
告警灵活性	固定规则，难自定义	可以写任意逻辑，比如“10分钟内同一密钥被读取超过50次”

说白了，自带审计是「点监控」，ELK是「面监控」。你搞安全运维，不能只看某一个点的日志，必须把整个凭证使用链串起来。

1.5 我们的课程要达成什么目标？

我把这个课程分成30章，从零开始搭建一套生产级的Secrets审计日志系统。我踩过的坑、调优的经验、安全配置的注意事项，都会揉在里面讲。