Add 6 runbook documents: - 服务启动 (Service Startup) - 服务停止 (Service Shutdown) - 配置更新 (Configuration Update) - 日志分析 (Log Analysis) - 备份恢复 (Backup & Recovery) - 安全事件 (Security Incident) Add Kubernetes Helm Chart: - Chart.yaml, values.yaml - Deployment with health checks - Ingress with TLS support - PVC for data persistence - PDB for high availability - HPA for autoscaling - ServiceAccount configuration Add cron-backup.conf for automated backup scheduling.
5.3 KiB
5.3 KiB
安全事件 Runbook
用途: 处理安全事件和漏洞响应
适用场景: 账户被盗、数据泄露、恶意攻击、权限异常
安全事件分级
| 级别 | 名称 | 描述 | 响应时间 |
|---|---|---|---|
| P0 | 严重 | 数据泄露、系统入侵、权限被完全绕过 | 立即 |
| P1 | 高危 | 账户被盗、密码泄露、疑似入侵 | 1小时内 |
| P2 | 中危 | 异常登录、权限提升尝试、API滥用 | 4小时内 |
| P3 | 低危 | 可疑行为、配置弱点、潜在风险 | 24小时内 |
事件响应流程
发现事件 → 评估确认 → 遏制影响 → 调查取证 → 修复漏洞 → 恢复服务 → 事后复盘
1. 发现与评估
识别安全事件
异常迹象:
- 大量失败登录尝试
- 异常用户活动(异地登录、时间异常)
- 未经授权的配置变更
- 服务性能异常下降
- 用户报告账户异常
初步评估
# 检查最近登录失败
docker-compose logs --since=1h app | grep "status: 401"
# 检查异常 IP 访问
docker-compose logs --since=1h app | awk '{print $NF}' | grep -v "user_id" | sort | uniq -c | sort -rn
# 检查用户权限异常
docker-compose logs --since=1h app | grep -i "admin\|permission\|role"
# 检查配置文件变更
stat configs/config.yaml
ls -la configs/config.yaml.*
2. 遏制影响
P0 严重事件 - 立即行动
# 1. 隔离受影响系统
docker-compose kill
# 2. 保存现场
docker-compose logs > logs/security_$(date +%Y%m%d_%H%M%S).log
cp -r data data_backup_$(date +%Y%m%d_%H%M%S)
# 3. 撤销会话
# 如果使用 Redis,清除所有会话
docker exec user-management-app redis-cli FLUSHALL
# 4. 重置所有密码(紧急情况)
# 参考下面的密码重置流程
P1 高危事件
# 1. 禁用受影响账户
docker-compose logs app | grep "user_id: XXX" # 找出受影响用户
# 2. 撤销可疑会话
# 检查并清除可疑 token
# 3. 加强监控
# 增加日志详细程度
3. 调查取证
日志分析
# 导出相关日志
docker-compose logs --since="2026-04-11T00:00:00" > logs/investigation_$(date +%Y%m%d).log
# 分析攻击痕迹
grep -E "error|warning|fail|invalid" logs/investigation_*.log
# 分析攻击者行为
docker-compose logs | grep "attacker_ip" -A 5 -B 5
# 检查数据库异常
sqlite3 data/user_management.db "SELECT * FROM users WHERE updated_at > '2026-04-11';"
常见攻击特征
| 攻击类型 | 日志特征 | 检查命令 |
|---|---|---|
| 暴力破解 | 大量 401 状态码 | grep status: 401 |
| SQL 注入 | SQL 关键字在请求中 | grep -i sql|union|select |
| XSS | 脚本标签在请求中 | grep -i <script|javascript: |
| CSRF | 异常 Referer | 检查请求头 |
| 权限提升 | 异常角色操作 | grep -i admin|role |
4. 修复漏洞
密码重置(所有用户)
#!/bin/bash
# 紧急密码重置脚本 - 强制所有用户重新设置密码
# 1. 备份数据库
./scripts/backup/backup.sh
# 2. 创建密码重置标记
sqlite3 data/user_management.db "UPDATE users SET password_reset_required = 1 WHERE status = 1;"
# 3. 清除所有活跃会话
# 如果使用 Redis
docker exec user-management-app redis-cli KEYS "session:*" | xargs docker exec user-management-app redis-cli DEL
# 4. 重启服务
docker-compose restart
单独用户密码重置
# 找出用户 ID
sqlite3 data/user_management.db "SELECT id, username, email FROM users WHERE username = 'target_user';"
# 禁用用户账户
sqlite3 data/user_management.db "UPDATE users SET status = 0 WHERE id = USER_ID;"
# 或删除用户
sqlite3 data/user_management.db "DELETE FROM users WHERE id = USER_ID;"
JWT 密钥轮换
# 1. 生成新密钥
NEW_SECRET=$(openssl rand -base64 32)
echo "新密钥: $NEW_SECRET"
# 2. 更新配置
vi configs/config.yaml
# 修改 jwt.secret
# 3. 清除所有现有会话
docker exec user-management-app redis-cli FLUSHALL
# 4. 重启服务
docker-compose restart
5. 恢复服务
# 1. 确认漏洞已修复
# 检查代码/配置变更
# 2. 启动服务
docker-compose up -d
# 3. 验证服务正常
curl http://localhost:8080/api/v1/health
# 4. 通知用户
# 发送密码重置邮件/通知
6. 事后复盘
必须完成的复盘内容
- 事件时间线
- 根本原因分析
- 影响范围评估
- 修复措施验证
- 改进建议
- 下次预防措施
复盘报告模板
# 安全事件复盘报告
**事件编号**: INC-YYYY-MM-DD-001
**发现时间**: YYYY-MM-DD HH:MM
**解决时间**: YYYY-MM-DD HH:MM
**影响范围**: 影响用户数、服务中断时间
## 事件描述
[详细描述事件经过]
## 根本原因
[分析根本原因]
## 响应措施
[列出采取的响应措施]
## 经验教训
[从事件中学到的教训]
## 改进行动
| 行动项 | 负责人 | 完成日期 |
|-------|-------|---------|
| | | |
紧急联系人
| 角色 | 联系方式 | 职责 |
|---|---|---|
| 运维负责人 | [联系方式] | 基础设施响应 |
| 安全负责人 | [联系方式] | 安全事件协调 |
| 开发负责人 | [联系方式] | 技术支持和修复 |
维护日期: 2026-04-11 下次审查: 每季度检查一次 测试频率: 每半年进行一次应急演练