企业官网建设流程全解析

简介：面向云安全工程师、架构师与运维人员的AWS安全实践参考文档，围绕身份与访问管理、数据保护、网络安全、基础设施安全、日志监控五大维度展开，帮助读者在云上落地最小权限、纵深防御与零信任架构。内容涵盖IAM用户隔离与MFA启用、KMS密钥集中管理、VPC安全组与网络ACL配置、WAF与PrivateLink部署、GuardDuty威胁检测及CloudTrail审计等具体做法，并结合云安全CAF架构与五大安全自动化层次，梳理从识别、保护到监控、合规、联动的能力建设路径。资源包共1个PDF文件，约15.34MB，适合作为方案设计与日常运维的案头查阅材料。已有796人学习，可帮助读者对照自身环境查漏补缺，快速理解AWS原生安全服务的组合方式与策略要点。

1. 一份 2020 年的 AWS 安全 PDF，为什么现在翻出来还值得逐页拆

上周帮一个团队做上云后的安全基线复核，翻他们共享盘时看到一份 2020 年的《AWS 云上安全最佳实践.pdf》。本来以为又是那种“把服务图标排一排、讲两句最小权限”的宣讲稿，结果打开发现它把 AWS 的 Layered Security Services 按 CAF 的 Identify、Protect、Detect、Respond、Recover 五个阶段做了映射，还给了 WAF 规则 JSON、TOP10 策略清单和 Landing Zone 的账户结构图。这类材料对正在做云上安全落地、又不想从零拼服务清单的从业者来说，价值不在“新”，而在“全”和“能对上号”。它适合三类人：刚接手 AWS 账号安全治理的工程师、要把等保或行业合规要求翻译成云上配置的安全负责人、以及准备做多账号 Landing Zone 的架构同学。下面按“这份 PDF 讲了什么 → 怎么照着配 → 哪里容易翻车”的顺序拆。

2. 五层自动化与 CAF 映射：先把服务清单对到自己的账号上

这份 PDF 最值得先看的是它把云安全拆成五层自动化：识别自动化、保护自动化、监控自动化、合规自动化、联动自动化。很多人拿到服务清单会直接照着开服务，结果开了一堆 GuardDuty、Security Hub、Config，却没人看告警，钱花了、风险还在。正确的读法是先把自己的账号现状映射到这五层上，找出断点在哪一层。

2.1 五层自动化到底对应哪些服务

PDF 里把 Layered Security Services 按 CAF 的六个阶段做了归类，我整理成下面这张对照表，方便你直接拿去和自己的账号比对：

这张表的作用不是让你全开，而是让你判断自己卡在哪一层。常见情况是 Protect 层配得挺全，Detect 层只开了 CloudTrail 没开 GuardDuty，Respond 层完全靠人肉看邮件。PDF 里反复强调“自动化”三个字，意思就是每一层都要有机器参与的闭环，而不是靠安全团队盯屏。

2.2 用 Organizations 和 Control Tower 搭 Landing Zone 骨架

PDF 的 TOP-LandingZone 部分给了一个多账号结构：Master account 下挂 Control Tower 和 Organizations，再分 Log archive account、Audit account、Core OU、Custom OU，Provisioned accounts 通过 Account baseline 和 Network baseline 统一配置。这个结构现在看依然是主流做法，照着搭能省很多返工。

落地步骤我一般这样走：

# 1. 在管理账号启用 Organizations 并开启所有功能 aws organizations enable-all-features # 2. 创建日志归档账号和审计账号（账号创建建议走控制台或 IaC，这里只示意查询） aws organizations list-accounts --query 'Accounts[?Name==`log-archive`]' # 3. 启用 Control Tower 前先确认主区域，Landing Zone 一旦选定主区域改动成本很高 aws controltower list-landing-zones

第一行开启 Organizations 的全部功能，是后面用 SCP（服务控制策略）做权限边界的前提；第二行只是确认账号是否已存在，实际创建账号建议用 Control Tower 的 Account Factory 或 IaC 模板，避免手工建号导致基线不一致；第三行查 Landing Zone 状态，注意 Control Tower 的主区域选择要一次定好，后面换区域等于重建。PDF 里提到用 StackSets 做跨账号部署、用 Service Catalog 给最终用户发预置产品，这两条在多账号环境里是标配，StackSets 负责把 CloudTrail、Config 这类基线推到所有账号，Service Catalog 负责限制业务团队只能开白名单内的资源组合。

2.3 把 TOP10 策略翻译成可执行的检查项

PDF 列了安全团队该花时间的 TOP10 策略，包括 IAM 多角色和边界、集中存储审计日志、密钥轮换、GuardDuty 发现应对、MFA 和数据加密、自动化账户授权、有限访问安全组、减少硬编码密钥等。这些条目本身不新鲜，但它的排序有参考价值：前三条是身份、日志、密钥，说明这三块是地基。

拿“减少硬编码密钥”这条举例，PDF 在 GDPR 合规章节里提到 Secrets Manager 和 KMS 的配合。实际检查时可以用 Config 规则加自定义 Lambda 做扫描，也可以先用下面这条命令粗筛：

# 列出所有 Secrets Manager 中的密钥，确认是否有该托管却没托管的 aws secretsmanager list-secrets --query 'SecretList[].Name' # 检查 IAM 用户是否开启 MFA，未开启的输出出来 aws iam list-users --query 'Users[].UserName' --output text | \ while read u; do mfa=$(aws iam list-mfa-devices --user-name "$u" --query 'MFADevices' --output text) [ -z "$mfa" ] && echo "NO_MFA: $u" done

第一段列出 Secrets Manager 里的密钥名，用来和代码仓库里的硬编码做比对；第二段遍历 IAM 用户查 MFA 设备，输出为空的就是没开 MFA 的账号。注意list-mfa-devices只对 IAM 用户有效，走 SSO 联合登录的用户要在身份源侧查，别在这条命令上纠结。PDF 里把 MFA 和数据加密放在同一条策略里，实际落地时建议把 MFA 强制写进 SCP，比靠人工巡检可靠得多。

3. WAF 规则 JSON 与可视化：从托管规则到自定义 CSRF 拦截

PDF 里有一段完整的 WAF V2 规则 JSON，讲的是用正则表达式集合匹配 CSRF token，再结合 URI 路径做拦截。这段内容对要自己写 WAF 规则的人很有用，因为它展示了 AndStatement、NotStatement、OrStatement 的嵌套写法，比官方文档的零散示例更接近真实业务。

3.1 拆解那段 CSRF 规则的逻辑

那段 JSON 的结构是：在 AndStatement 里放两个条件，第一个是 NotStatement 包着 RegexPatternSetReferenceStatement，检查请求头x-csrf-token是否不匹配预定义的正则集合；第二个是 OrStatement，匹配 URI 路径以/form.php开头或完全等于/form.php。两个条件同时满足才 Block。翻译成人话就是：访问表单页、但 CSRF token 格式不对的请求，直接拦掉。

这里有几个参数值得注意。TextTransformations里的URL_DECODE表示先对请求头做 URL 解码再匹配，防止攻击者用编码绕过；PositionalConstraint用STARTS_WITH和EXACTLY两种，是为了覆盖带查询参数和不带参数两种访问形态；VisibilityConfig里SampledRequestsEnabled和CloudWatchMetricsEnabled都设为 true，这是后面做监控和告警的前提，很多人写规则时忘了开，出事时连采样请求都看不到。

3.2 用 API 创建规则时最容易错的三个参数

PDF 提示“更新 WAF 所在区域 ID、AWS 账户 ID 和正则表达式模式 ID，通过 JSON 文档调用单个 API 来创建或更新规则”。这三个 ID 就是翻车高发区。区域 ID 要和 Web ACL 的 Scope 一致，REGIONAL 的 ACL 用区域端点，CLOUDFRONT 的 ACL 必须用us-east-1端点；账户 ID 填错会直接报 AccessDenied，但报错信息不会告诉你是 ID 错了还是权限不够；正则集合的 ARN 里带区域和账户，跨账号引用时要确认资源策略允许。

创建规则的命令大致如下：

# 把规则 JSON 存为 rule.json 后，用 update-web-acl 追加或替换规则 aws wafv2 update-web-acl \ --name my-web-acl \ --scope REGIONAL \ --id <web-acl-id> \ --lock-token <lock-token> \ --default-action Allow={} \ --rules file://rule.json \ --region ap-southeast-1

--lock-token是乐观锁，先get-web-acl拿到当前 token 再提交，并发修改时会失败重试；--scope必须和 ACL 创建时一致，REGIONAL 和 CLOUDFRONT 不能混；--rules是整体替换，不是追加，所以改规则前一定要先把现有规则导出备份，否则一次提交就把别的规则冲掉了。这是血泪经验，WAF 没有“后悔药”，规则被覆盖只能从备份恢复。

3.3 用 CloudWatch 给 WAF 规则上监控

PDF 专门提到用 CloudWatch 显示 Web ACL 规则活动，并基于阈值设警报。规则上线不等于生效，得能看到它拦了什么、误拦了什么。常见做法是给每条规则单独设 MetricName（上面 JSON 里的A-matchCSRF就是），然后在 CloudWatch 里对 BlockedRequests 指标设告警。

# 查看指定 Web ACL 的规则指标（指标名要和规则里的 MetricName 一致） aws cloudwatch get-metric-statistics \ --namespace AWS/WAFV2 \ --metric-name BlockedRequests \ --dimensions Name=WebACL,Value=my-web-acl Name=Rule,Value=A-matchCSRF Name=Region,Value=ap-southeast-1 \ --start-time 2024-01-01T00:00:00Z \ --end-time 2024-01-02T00:00:00Z \ --period 300 \ --statistics Sum

维度里的 WebACL、Rule、Region 三个都要对上，少一个就查不到数据；period 设 300 秒是 WAF 指标的最小粒度附近，再小没有意义。建议对 BlockedRequests 设一个突增告警，同时对 AllowedRequests 设一个骤降告警，前者防攻击，后者防误拦把正常流量挡了。PDF 里还提到 WAF V2 托管策略，实际项目里托管规则组先上，自定义规则后补，顺序反了容易一开始就误拦。

4. 避坑与排查：五条从账号到规则的翻车记录

这份 PDF 内容密度高，但它是 2020 年的材料，部分服务界面和默认行为已经变了，照抄容易踩坑。下面五条是我在实际项目里遇到过的，按“现象 → 原因 → 解决”记下来。

4.1 GuardDuty 开了但没告警

现象：控制台显示 GuardDuty 已启用，模拟的异常 API 调用也出现了 finding，但安全团队没收到任何通知。原因：GuardDuty 只负责生成 finding，不会主动推送，必须通过 EventBridge 规则转发到 SNS 或 Security Hub。解决：在 EventBridge 里建规则匹配aws.guardduty源，目标指向 SNS 主题，并在 Security Hub 里开启 GuardDuty 集成做聚合。PDF 的 Respond 层提到 Lambda 和 Step Functions，就是干这个的。

4.2 CloudTrail 只开了管理事件

现象：出了数据泄露怀疑，想查 S3 对象的读取记录，发现 CloudTrail 里没有。原因：默认的 CloudTrail 跟踪只记录管理事件，数据事件（S3 对象级、Lambda 调用）要单独勾选，而且数据事件量大、额外计费。解决：对关键桶单独开数据事件跟踪，用高级事件选择器只选敏感前缀，别全桶全量开，否则日志成本会失控。PDF 里强调集中日志归档，Log archive account 就是放这些的。

4.3 WAF 规则更新把旧规则冲掉

现象：用update-web-acl加了一条新规则，结果原来的 IP 黑名单规则没了。原因：--rules参数是整体替换语义，不是追加。解决：改之前先get-web-acl导出完整 JSON，在本地合并新规则后再提交，或者用 IaC 管理 WAF 配置，把规则变更走代码评审。这条和第 3 章说的备份是同一件事，吃过一次亏就会记住。

4.4 KMS 密钥轮换开了但旧数据读不了

现象：开启自动密钥轮换后，部分老应用报解密失败。原因：KMS 自动轮换只轮换密钥材料，密钥 ID 和 ARN 不变，正常不会导致解密失败；真正的原因是应用侧缓存了旧的密钥材料，或者跨区域复制时用了不同的密钥。解决：确认应用用的是密钥 ARN 而不是本地缓存的材料，跨区域场景用多区域密钥。PDF 里把 KMS 和 CloudHSM 并列，CloudHSM 适合需要自管密钥材料的场景，但运维成本高，别为了“更安全”盲目上。

4.5 Control Tower Landing Zone 更新卡住

现象：Control Tower 的 Landing Zone 更新一直处于 IN_PROGRESS，超过一小时没动静。原因：通常是某个成员账号里有手工改过的基线资源（比如手动删了 Config recorder），导致 StackSets 部署失败。解决：去 StackSets 里看具体哪个账号哪个 stack instance 失败，修复漂移后重试；预防办法是所有基线变更走 Control Tower 的 controls 或 IaC，别在成员账号里手工动基线资源。PDF 里用 Account baseline 统一配置的思路是对的，但前提是没人手工破坏基线。

5. 把 PDF 变成可验证的基线：我的复核清单与一个习惯

这份 PDF 最大的用法不是读完，而是把它当成一张复核清单。我现在的习惯是每接手一个 AWS 账号，先按它的五层自动化过一遍：Identify 层看 Organizations 和 IAM 是否有集中管控和权限边界；Protect 层看 VPC 分层、KMS 密钥策略、WAF 是否挂了托管规则组；Detect 层看 CloudTrail 是否多区域、GuardDuty 是否全区域、Config 是否记录了关键资源类型；Respond 层看有没有至少一条 EventBridge 到 SNS 的告警链路；Recover 层看备份是否做过恢复演练。五层里任何一层是空的，就先补那一层，而不是继续堆服务。

具体到验证方法，我会用下面这段脚本做一次快速体检，输出结果直接对照 PDF 的 TOP10 策略：

#!/bin/bash # AWS 账号安全基线快速体检，只读操作 echo "== CloudTrail 多区域跟踪 ==" aws cloudtrail describe-trails --query 'trailList[?IsMultiRegionTrail==`true`].[Name,HomeRegion]' --output table echo "== GuardDuty 检测器 ==" aws guardduty list-detectors --query 'DetectorIds' --output text echo "== Config 记录器状态 ==" aws configservice describe-configuration-recorder-status \ --query 'ConfigurationRecordersStatus[].[name,recording,lastStatus]' --output table echo "== 未启用 MFA 的 IAM 用户 ==" aws iam list-users --query 'Users[].UserName' --output text | \ while read u; do mfa=$(aws iam list-mfa-devices --user-name "$u" --query 'MFADevices' --output text) [ -z "$mfa" ] && echo "NO_MFA: $u" done echo "== 开放 0.0.0.0/0 入站的安全组 ==" aws ec2 describe-security-groups \ --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]].[GroupId,GroupName]' \ --output table

这段脚本全是只读调用，可以放心在审计账号里跑。第一段查多区域跟踪，输出为空说明 CloudTrail 没做多区域，跨区域事件会漏；第二段查 GuardDuty 检测器 ID，为空就是没开；第三段看 Config 记录器是否在 recording 状态，lastStatus不是 SUCCESS 就要查原因；第四段筛没开 MFA 的 IAM 用户；第五段找对全网开放入站的安全组，这是最常见的暴露面。注意第五段的查询只覆盖 IPv4 的 0.0.0.0/0，IPv6 的::/0要另加条件，别以为跑完就干净了。

跑完这份体检，再回到 PDF 的 TOP10 架构清单逐条打勾：IAM 账户与权限策略架构、VPC 网络安全设计、KMS 密钥管理、WAF 与 DDoS 综合防御、GuardDuty 主动检测、Control Tower 自动化、Central Log 集中日志、ACM 与 HSM 私有 CA、DevSecOps、SIEM 事件响应。十条里能对上七条以上，说明基线基本成型；对不上的就是下一阶段的活。PDF 里那句“零信任安全架构：永不信任，始终验证，强制执行最小权限”听着像口号，落到操作上就是每次复核都从身份和权限开始，而不是从买服务开始。

从那以后我每次做云上安全复核，都强制先跑一遍只读体检脚本、再对照五层自动化找断点，最后才谈加服务。顺序反了，很容易变成服务清单越拉越长、风险却没少。希望这份拆解帮到你，把那份 PDF 从“存着”变成“用起来”。

本文还有配套的精品资源，点击获取