起点状况
客户业务增长很快，但基础设施是逐步堆起来的：所有资源在一个 AWS 账号里，研发有生产环境权限，root 账号在共用，审计日志留存不足三个月。监管检查在即，这个状态过不了。
另一个现实约束是：公司只有两名运维，没有专职安全人员。所以方案不能是「配一堆安全产品然后交给客户自己运营」，必须包含托管运营，否则配好的东西没人看，等于白配。
控制项落地对照（节选）
| 等保要求 | 落地实现 | 举证材料 |
|---|---|---|
| 身份鉴别：双因子 | IAM Identity Center + 强制 MFA + 企业 IdP 对接 | 权限集配置 + MFA 启用截图 |
| 访问控制：最小权限 | 按角色划分权限集 + SCP 护栏 + 权限边界 | IAM Access Analyzer 报告 |
| 安全审计：日志留存 | 组织级 CloudTrail → 独立日志账号，留存 3 年 | 日志完整性校验记录 |
| 入侵防范：边界防护 | Network Firewall + WAF + 安全组最小开放 | 规则配置导出 + 拦截日志 |
| 数据完整性：传输加密 | 全链路 TLS 1.2+，内部服务间 mTLS | 证书清单 + 配置审计 |
| 数据保密性：存储加密 | KMS CMK 加密全部存储，密钥年度轮换 | 加密覆盖率报告 + 密钥策略 |
| 备份恢复：异地备份 | 跨区域备份 + Vault Lock + 季度恢复演练 | 备份成功率 + 演练报告 |
| 个人信息保护 | Macie 扫描 + 字段级加密 + 分析环境脱敏 | PII 分布报告 + 脱敏规则 |
账号重构方案
从 1 个账号拆到 14 个
- 管理账号：仅做组织管理与计费，不放任何工作负载
- 审计账号：Security Hub 与 Config 汇总，只读权限
- 日志归档账号：CloudTrail 与访问日志集中存储，Object Lock 防删
- 备份账号：跨账号备份副本，与生产权限完全隔离
- 网络中枢账号：Transit Gateway、防火墙、集中出口
- 生产账号 ×3：按业务域拆分，核心交易独立账号
- 预生产 / 测试 / 开发 / 沙箱账号各一
迁移过程的关键取舍
- 资源不做物理迁移，用新账号新建 + 数据同步的方式切换
- 先拆非生产环境，验证 IaC 与流程，再动生产
- 生产按业务域分三次切，每次间隔两周
- 过渡期通过 Transit Gateway 保持跨账号互通
- 全程 IaC 化，为后续审计提供配置基线证据
项目节奏
-
第 1-3 周
差距分析
按等保三级逐条对照现状，输出 87 项差距清单与优先级。
-
第 4-9 周
着陆区建设
Organizations 结构、SCP 护栏、SSO 接入、日志与审计账号搭建。
-
第 10-16 周
非生产迁移
开发测试环境迁到新账号，IaC 模块打磨成型。
-
第 17-24 周
生产迁移
三个业务域分批切换，每批完成后做一次配置基线快照。
-
第 25-28 周
安全运营接入
GuardDuty/Security Hub 调优降噪，7×24 值守上线，Runbook 定稿。
-
第 29-32 周
测评准备与过审
举证材料整理、预评估、现场答疑，一次性通过。
过等保这件事，我们最担心的是「为了过审而过审」，配一堆东西审完就闲置。他们把安全运营也接了，每个月的态势报告我都看，是真的在跑而不是摆着。
技术栈
- Organizations
- Control Tower
- IAM Identity Center
- SCP
- KMS
- GuardDuty
- Security Hub
- Config
- CloudTrail
- Macie
- Network Firewall
- WAF
- Backup Vault Lock