文章总结： 文章翻译整理了AWS云安全加固检查清单，覆盖身份与访问管理、网络安全、数据保护、存储、计算与数据库六大阶段，以条目化方式给出关键安全措施，强调最小权限、加密、监控和持续审查，帮助团队系统性消除常见漏洞并建立持续安全监控。 综合评分： 85 文章分类： 云安全,安全建设,解决方案

AWS云安全加固Checklist

Dubito Dubito

云原生安全指北

2026年3月20日 08:35 江苏

注：本文翻译自Apaksh[1]的文章《AWS Security Hardening: The Checklist Your Cloud Needs》[2]，可点击文末“阅读原文”按钮查看英文原文。

全文如下：

如果你在AWS上运行任何工作负载，那么这份指南就是为你准备的。我见过太多团队通过惨痛代价才学会AWS安全——因加密挖矿导致实例被入侵而产生的意外账单，或者更糟，发生登上了新闻的数据泄露事件。好消息是？大多数AWS安全问题都可以通过系统化的方法来预防。以下是你的云环境所需的检查清单。

这份清单涵盖了身份管理、网络安全、数据保护、监控和合规性。遵循它可以系统地消除常见漏洞，实施最小权限原则，并建立持续的安全监控。

第一阶段：身份与访问管理 (IAM)

Root 账户保护

• • 完全禁用 root 账户的访问密钥 —— Root 密钥提供对AWS账户的无限制访问；一旦泄露，攻击者可控制一切（关键）
• • 为 root 账户启用 MFA（多因素认证） —— 即使密码泄露也能防止未经授权的访问（关键）
• • 为 root 账户使用硬件 MFA 设备（而非虚拟 MFA） —— 硬件令牌无法通过恶意软件或网络钓鱼被攻破（关键）
• • 移除所有 root 账户的访问密钥 —— 缩小爆炸半径；root 密钥没有权限边界
• • 将 root 账户密码存储在安全的离线位置 —— 仅在极少数账户级变更时才需要 root 访问权限

IAM 用户与角色策略

• • 尽可能采用“角色而非用户”的架构 —— 角色使用临时凭证；拥有长期密钥的用户是高危目标（关键）
• • 对所有权限实施最小权限原则 —— 权限过高的用户会成为高价值目标；此举可限制爆炸半径（关键）
• • 使用 IAM 策略条件按 IP/时间/设备进行限制 —— 增加第二层防御；防止来自可疑位置的访问
• • 为所有人类用户（不仅仅是 root）启用 MFA —— 保护个人用户账户免遭入侵
• • 使用来自 STS 的临时凭证进行跨账户访问 —— 临时凭证会自动过期；泄露后也无法被重用
• • 实施服务控制策略 (SCP) 作为防护机制 —— 在整个组织单元层面禁止所有类别的危险操作
• • 使用具有会话时长限制的临时凭证 —— 缩小凭证泄露后的暴露时间窗口

凭证管理

• • 每 90 天轮换一次 IAM 访问密钥（首选自动化方式） —— 限制旧凭证泄露后的损害窗口期（关键）
• • 启用凭证报告生成并每季度审查 —— 识别应移除的未使用或老旧凭证（关键）
• • 立即禁用未使用的 IAM 用户和密钥 —— 被遗忘的孤立账户会成为安全漏洞
• • 使用 AWS Secrets Manager 或 Parameter Store 存储敏感数据 —— 切勿在代码或配置文件中硬编码凭证
• • 为服务账户实施自动访问密钥轮换 —— 减少凭证管理中的手动操作和人为错误
• • 要求强密码策略（14个以上字符，包含复杂性） —— 增加暴力破解的计算成本

跨账户与外部访问

• • 使用 IAM 角色而非密钥进行跨账户访问 —— 防止凭证泛滥；临时凭证更安全（关键）
• • 记录并审计所有信任关系 —— 恶意的信任关系会导致未经授权的访问
• • 使用外部 ID (External ID) 进行跨账户角色代入（role assumption） —— 防止未经授权方代入您的角色
• • 实施 sts:AssumeRole 的时间限制 —— 过期的会话无法被重用

第二阶段：网络安全

VPC 与子网架构

• • 为数据库和应用服务器使用私有子网 —— 防止直接暴露在互联网；强制流量通过安全层（关键）
• • 实施 公共/私有/数据库 子网分层 —— 网络分段可限制单层被攻破后的横向移动（关键）
• • 使用 VPC Flow Logs 监控所有网络流量 —— 检测未经授权的连接；事件调查所需
• • 将 VPC Flow Logs 发送至 CloudWatch 和 S3 —— 同时提供实时告警和长期审计跟踪
• • 使用 VPC Endpoints 访问 AWS 服务（如 S3, DynamoDB） —— 将流量隔离在互联网之外；防止数据通过公共互联网泄露
• • 通过服务网格 (Service Mesh) 实现服务间通信 —— 在微服务间强制执行双向 TLS 认证

安全组与网络ACL

• • 移除任何允许互联网访问的 0.0.0.0/0 安全组规则 —— 这会将服务暴露给整个互联网，使系统成为攻击目标（关键）
• • 限制数据库安全组的访问权限，仅允许应用服务器 —— 防止来自互联网攻击者的直接数据库访问（关键）
• • 使用网络ACL的出站规则阻止意外的出站流量 —— 防止数据泄露；检测被入侵实例的“回连”尝试
• • 记录所有安全组规则并实施版本控制 —— 防止出现未记录或遗留规则；支持审计追踪
• • 实施安全组链式引用（限制访问特定安全组） —— 比使用CIDR范围更安全；且能随环境自动扩展
• • 使用安全组管理工具防止规则偏离 —— 在部署前捕获意外引入的过度宽松规则

网络访问控制

• • 禁用默认VPC或将其隔离 —— 默认VPC带有过度宽松的默认安全组（关键）
• • 为公共Web应用使用WAF（Web应用防火墙） —— 拦截常见Web攻击（如SQL注入、XSS、DDoS）
• • 为管理工具实施IP白名单 —— 防止对堡垒机或管理接口的暴力破解攻击
• • 使用AWS Shield Standard（自动启用）和 Shield Advanced —— 抵御DDoS攻击；对面向公众的应用至关重要
• • 使用Private Link实现网络分段 —— 增加零信任网络访问控制

第三阶段：数据保护与加密

传输中加密

• • 为所有面向公众的应用启用TLS/HTTPS —— 防止用户数据被窃听；合规性要求（关键）
• • 在所有AWS服务间的通信中使用HTTPS —— 抵御AWS内部的中间人攻击（关键）
• • 最低使用TLS 1.2版本（首选TLS 1.3） —— 旧版TLS存在已知漏洞
• • 禁用未加密的协议（如HTTP、Telnet、FTP） —— 这些协议以明文形式发送凭证
• • 为关键API使用证书固定 —— 即使证书颁发机构被攻破，也能防止中间人攻击
• • 在服务间实施双向TLS (mTLS) —— 客户端和服务器互相验证身份

静态数据加密

• • 为所有S3存储桶启用默认加密 —— 防止敏感数据被未加密存储（关键）
• • 使用AWS KMS密钥（而非S3托管加密） —— KMS提供密钥轮换、访问审计和合规性控制（关键）
• • 为所有卷启用EBS加密 —— 在存储设备被物理访问时，保护数据免遭窃取（关键）
• • 启用RDS静态数据加密（所有引擎） —— 保护数据库免遭窃取；多数合规标准均要求
• • 启用DynamoDB静态数据加密 —— 保护NoSQL数据；KMS提供密钥管理
• • 使用客户管理型KMS密钥而非AWS托管型 —— 让您能控制密钥轮换和访问策略
• • 实施密钥轮换策略（至少每年一次） —— 限制主密钥泄露后的损害窗口期

密钥管理

• • 通过密钥策略限制KMS密钥的访问权限 —— 防止对加密数据的未授权解密（关键）
• • 对KMS操作启用CloudTrail日志记录 —— 检测未授权的解密尝试；合规性要求（关键）
• • 不同用途使用不同的KMS密钥 —— 单个密钥泄露时限制爆炸半径
• • 实施密钥策略的职责分离 —— 解密敏感数据需多重审批
• • 为KMS密钥别名实施清晰的命名规范 —— 便于审计；防止使用错误的密钥

Secrets 管理

• • 使用AWS Secrets Manager管理数据库密码 —— 防止在应用程序代码中硬编码凭证（关键）
• • 启用 Secrets 的自动轮换 —— 限制secrets信息泄露后的损害
• • 实施Secrets复制以实现灾难恢复 —— 确保应用在区域故障后仍能进行身份验证
• • 使用基于资源的策略来控制Secrets的访问 —— 防止未经授权的应用程序读取secrets信息

第四阶段：存储安全

S3 存储桶加固

• • 在存储桶级别阻止所有公共访问 —— 防止意外公开暴露；这是数据泄露最常见的途径（关键）
• • 在敏感存储桶上启用版本控制 —— 支持从勒索软件或意外删除中恢复数据（关键）
• • 在关键存储桶上启用 MFA Delete —— 即使管理员，若无 MFA 也无法删除存储桶内容（关键）
• • 使用存储桶策略强制仅允许 HTTPS 访问 —— 防止未加密的数据传输（关键）
• • 为合规性归档启用 S3 Object Lock（WORM，一次写入，多次读取） —— 防止审计日志和合规记录被修改
• • 使用 S3 访问日志记录跟踪所有存储桶访问 —— 检测未授权的访问尝试；合规性要求
• • 实施存储桶生命周期策略 —— 自动删除旧数据；减少数据暴露时间窗口

S3 访问控制

• • 使用 IAM 策略而非存储桶 ACL —— IAM 策略更灵活且更易于审计（关键）
• • 禁用 S3 “Authenticated Users（已验证用户）”组的访问权限 —— 防止任何经过身份验证的 AWS 用户访问存储桶（关键）
• • 对于临时访问，使用带过期时间的预签名 URL —— 限制暴露窗口；防止无限期访问
• • 通过代入角色（assumed roles）实现跨账户 S3 访问 —— 临时凭证比长期密钥更安全

第五阶段：计算安全

EC2 实例加固

• • 强制仅使用 IMDSv2 —— 防止 SSRF 攻击读取实例凭证（关键）
• • 使用 Systems Manager Session Manager 替代 SSH/RDP —— 无需开放互联网端口；提供审计追踪；无需管理密钥（关键）
• • 移除默认的 SSH/RDP 安全组规则 —— 防止对堡垒机的暴力破解攻击（关键）
• • 启用详细监控和 CloudWatch Agent —— 检测异常行为；建立性能基准
• • 使用 Systems Manager Patch Manager 进行操作系统更新 —— 自动化打补丁；减少手动操作和人为错误
• • 使用包含安全默认配置的启动模板 —— 确保所有新实例遵循安全标准

容器安全 (ECS/EKS)

• • 使用容器镜像扫描以发现漏洞 —— 在部署前检测已知的 CVE 漏洞（关键）
• • 实施准入控制器（K8s 环境使用 OPA/Gatekeeper） —— 阻止部署不合规的镜像（关键）
• • 使用带有 IAM 访问控制的私有 ECR 仓库 —— 防止拉取未经授权的镜像
• • 对容器镜像进行签名并验证签名 —— 防止篡改；确保镜像来源可信
• • 使用 Pod 安全策略/安全标准 (Kubernetes) —— 防止容器内的权限提升
• • 实施网络策略以限制 Pod 之间的流量 —— 防止单个 Pod 被攻破后的横向移动

Lambda 安全

• • 使用具有最小权限的 IAM 执行角色 —— 防止函数被攻破后的横向移动（关键）
• • 将secrets信息存储在 Secrets Manager 中，而非环境变量中 —— 环境变量在 CloudWatch 日志中可见（关键）
• • 为 Lambda 启用 VPC（如需访问私有资源） —— 将函数保持在高安全边界内
• • 实施 Lambda 并发限制 —— 防止因 DDoS 或恶意调用导致成本失控

第六阶段：数据库安全

RDS 加固

• • 将 RDS 实例放置在私有子网中 —— 防止直接互联网访问；强制流量经过应用层（关键）
• • 使用 AWS Secrets Manager 管理数据库凭证 —— 防止硬编码密码；启用自动轮换（关键）
• • 启用具有适当保留期的自动备份 —— 确保能从数据丢失或损坏中恢复（关键）
• • 为所有 RDS 实例启用静态数据加密 —— 保护数据免受物理访问威胁
• • 启用审计日志 —— 追踪何人于何时访问了何数据

总结： AWS 安全并非一蹴而就的配置。它是一个持续的过程。请有条不紊地执行这份检查清单，然后安排季度审查以发现配置偏离。预防的成本永远低于数据泄露的代价。

引用链接

[1] Apaksh: https://dev.to/apaksh [2] 《AWS Security Hardening: The Checklist Your Cloud Needs》: https://dev.to/apaksh/aws-security-hardening-the-checklist-your-cloud-needs-4d99

交流群

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：云原生安全指北 Dubito Dubito《AWS云安全加固Checklist》