Inblade/security-incident-response

# 安全事件应急响应手册 面向云/Kubernetes 平台团队在实际工作中面临的安全事件，提供切实可行的防御性应急响应手册。 内容提炼自真实的生产事件经验：每份手册都遵循相同的处置原则 —— **隔离 → 轮换/清除 → 审计 → 加固** —— 提供具体的命令、决策树和明确的退出标准，而非泛泛而谈的建议。 本仓库内容严格限定于响应与防护；不包含任何关于如何攻击系统的描述。 ## 目录结构 ``` . ├── README.md ├── LICENSE ├── runbooks/ │ ├── compromised-cloud-credentials.md # contain → rotate → audit → harden │ ├── cryptomining-pod.md # quarantine, entry-point hunt, node replacement │ ├── leaked-secret-in-git.md # rotation first; history-rewrite decision tree │ └── suspicious-admin-activity.md # out-of-band verification, persistence sweep ├── templates/ │ └── security-incident-report.md # blameless report template └── docs/ └── severity-and-disclosure.md # SEV definitions, disclosure guidance ``` ## 如何使用 **事件发生期间** 1. 使用 [docs/severity-and-disclosure.md](docs/severity-and-disclosure.md) 对严重程度进行分类 —— 如有疑问，上调一级。 2. 打开对应的应急响应手册并从头到尾严格执行；各手册之间存在交叉引用，因为事件往往是连锁发生的（例如，发现挖矿 pod 通常意味着需要进一步参考凭据相关的响应手册）。 3. 在响应事件*期间*，立即使用 [templates/security-incident-report.md](templates/security-incident-report.md) 开始撰写报告 —— 实时记录的时间戳才是最终能保留下来数据。 **事件发生前（这也是本仓库存在的真正意义）** - 根据你的实际环境调整命令：账号 ID、日志查询界面，以及特定于 IdP 的吊销步骤。 - 验证每份手册所做出的假设：审计日志的保留期限能够覆盖你实际存在的检测延迟；在吊销第一个管理员权限之前，确保还存在备用管理员路径；确认密钥存储是唯一的轮换节点。 - 对每份手册至少进行一次桌面演练 —— 未经演练的手册只是一份文档，而非真正的能力。 ## 融入这些响应手册的核心原则 1. **先轮换，后清理。** 删除恶意构件（artifact）并不能吊销已泄露的凭据。 2. **先隔离，后删除。** 删除 pod 会导致证据随之消失。 3. **每发现一个新凭据，都要触发一次独立的响应流程。** 需追踪整个事件树。 4. **通过带外通信（Out-of-band）验证相关人员身份。** 你正在询问的账号背后回答你的，未必是其真正的所有者。 5. **始终保持无责备文化。** 对报告者进行惩罚只会导致无人报告；下一次泄露将一直隐藏在暗处。 ## 许可证 MIT —— 详见 [LICENSE](LICENSE)。

标签：子域名突变, 安全事件响应, 库, 应急响应, 运维手册, 防御加固, 防御策略