AWS支付卡绑定 AWS EC2 安全加固指南：IAM权限最小化、网络隔离与数据保护实操教程

用户搜索“AWS EC2 安全加固指南”时，通常不是想看概念说明，而是已经准备上线或正在整改现有实例。最常见的决策问题包括：SSH 是否还能对 0.0.0.0/0 开放、EC2 应该绑定什么 IAM Role、应用服务器和数据库是否需要分子网、EBS 是否必须加密、快照怎么做才方便恢复、Windows RDP 如何避免被暴力扫描。下面的内容直接围绕这些操作问题展开，适合新建实例加固，也适合存量实例整改。

一、上线前最容易遗漏的风险点

在实际环境里，EC2 安全问题通常不出在“有没有买防火墙”，而出在默认配置没有收紧。以下几项建议你在控制台逐项核对。

如果你当前环境已经存在公网 SSH、宽松安全组和无加密磁盘，这篇教程建议先从网络和数据保护开始，再处理 IAM 和审计。

二、实施前准备：账号、权限与资源条件

1. 账号与权限要求

执行下面的操作，登录账号至少需要 EC2、IAM、VPC、KMS、CloudWatch、SSM、EBS Snapshot 相关权限。如果你不是主账号，建议提前确认以下操作是否被授权：

• 创建和绑定 IAM Role
• 编辑 Security Group 和 Network ACL
• 创建 KMS Key 或使用默认 EBS KMS Key
• AWS支付卡绑定 启用 Systems Manager
• 创建快照和恢复卷

2. 建议准备的资源

3. 前置条件

如果是新建 EC2，尽量一开始就启用加密卷、私网部署和 IAM Role。对于已运行实例，部分项目如卷加密、子网调整涉及停机或迁移，建议先做快照。

三、步骤一：创建更安全的 EC2 实例

1. 在控制台创建实例时怎么选

进入 AWS 控制台，依次点击 EC2 → Instances → Launch instances。这里不要只关注实例规格，安全相关参数应同时完成。

2. Linux 和 Windows 的安装选择

如果是 Linux，优先选择 Amazon Linux 2023、Ubuntu LTS、RHEL 官方镜像。Windows 场景通常用于 .NET、IIS、传统桌面应用中间层。无论 Linux 还是 Windows，都优先选择官方 AMI，并确保后续补丁可持续更新。

对于 Linux，不建议为了“方便”在 User Data 中写入明文数据库密码；如果必须初始化配置，建议从 SSM Parameter Store 或 Secrets Manager 读取。

3. 实例创建后先做的三件事

• 检查公网 IP 是否真的需要保留，不需要就去掉并通过负载均衡或堡垒方案访问。
• 确认根卷和数据卷已启用加密。
• 立即为实例绑定 IAM Role，避免应用内使用长期凭证。

AWS支付卡绑定 四、步骤二：收紧身份权限，避免实例拥有过大授权

1. 为 EC2 创建专用 IAM Role

进入 IAM → Roles → Create role，选择 AWS service → EC2。这里不要图省事直接选 AdministratorAccess。应按应用访问目标拆分，例如：

创建后回到 EC2 → Instances → 选中实例 → Actions → Security → Modify IAM role，将 Role 绑定到实例。

2. 减少人为登录与共享密钥

Linux 管理建议优先使用 Systems Manager Session Manager。这样可以不开放 22 端口，也不分发 SSH 私钥。操作路径为 Systems Manager → Fleet Manager 或 Session Manager，前提是实例满足以下条件：

• 实例已绑定包含 AmazonSSMManagedInstanceCore 的 IAM Role
• 子网可访问 SSM 相关端点，或已配置 NAT / VPC Endpoint
• 实例中 SSM Agent 正常运行

Windows 也可以通过 SSM 减少 RDP 直接暴露。如果确实需要 RDP，建议安全组仅允许固定源 IP，且启用复杂密码与定期轮换。

3. 应用凭证不要放进代码和镜像

实际事故里，最常见的问题不是 IAM 配少了，而是开发把 Access Key 写进环境变量、镜像层或 Git 仓库。整改方案是：

• EC2 调用 AWS 服务一律通过实例角色获取临时凭证
• 数据库密码放 Parameter Store 或 Secrets Manager
• 在启动脚本中按需拉取参数，避免写死在 AMI

五、步骤三：完成网络隔离，限制 SSH、RDP 与业务端口暴露

1. 安全组怎么配更稳妥

进入 EC2 → Security Groups，为不同层级创建独立安全组，而不是一个组开放所有端口。

这里最关键的一条是：应用层对数据库开放时，来源应填写上游安全组，而不是整段网段或 0.0.0.0/0。这样即使有人在同 VPC 新建实例，也不能自动连到数据库。

2. 子网和路由的实操建议

一个可执行的基础架构是：

• 公有子网：ALB、必要的 NAT Gateway、少量运维入口
• 私有子网：应用 EC2、内部任务节点、缓存和数据库
• 数据库子网：仅私网路由，不关联 Internet Gateway

如果你当前 EC2 已在公有子网，且不需要直接被公网访问，可以新建私有子网后迁移应用，或者通过镜像/快照重建实例。这个动作比单纯改安全组更彻底。

3. 主机防火墙不要省略

除了 Security Group，Linux 建议同时检查操作系统防火墙。例如 Ubuntu 使用 ufw，RHEL/Amazon Linux 使用 firewalld 或 nftables。这样可以形成第二层过滤，避免误改安全组后端口完全暴露。

Linux 常用命令示例：

开放 443：firewall-cmd --permanent --add-service=https

移除 22 的公网开放后重载：firewall-cmd --reload

查看监听端口：ss -lntp

Windows 则在“Windows Defender 防火墙”中限制入站规则，尤其是 3389、5985/5986 等管理端口。

六、步骤四：启用数据保护，避免磁盘裸奔和备份不可恢复

1. EBS 加密怎么检查和启用

进入 EC2 → Volumes，查看每个卷的 Encryption 列。如果新建时没开加密，已存在的未加密卷不能直接原地改成加密，常见处理流程是：

• 对原卷创建快照
• 从快照复制为加密快照
• 基于加密快照创建新卷
• AWS支付卡绑定 停机后替换卷，或新建实例挂载迁移

如果是生产环境，先评估停机窗口。对于根卷，建议通过创建 AMI 或新卷替换方案操作，不要在高峰期直接切换。

2. 快照备份不要只做“有备份”

真正有用的备份必须能恢复。建议至少做两层策略：

AWS支付卡绑定 可在 EC2 Lifecycle Manager 或 AWS Backup 中配置自动快照。注意：EBS 快照适合卷级恢复，不等于数据库一致性备份。MySQL、PostgreSQL、Redis 仍应有独立导出或持久化策略。

3. 数据传输和 HTTPS 部署

如果 EC2 对外提供 Web 服务，建议在 ALB 或 Nginx/IIS 上启用 HTTPS。证书可通过 ACM 管理并绑定到负载均衡器。对内服务如应用访问数据库，也应优先开启 TLS，尤其是跨可用区或混合云连接。

DNS 解析方面，推荐使用 Route 53 并对公网入口统一收口到 ALB，而不是把每台 EC2 公网 IP 直接暴露给用户。这样后续替换实例、滚动升级和证书续期都更容易控制。

七、步骤五：连接、审计、补丁与故障排查

1. SSH 或 RDP 无法连接时先查什么

2. 审计日志至少要留哪些

• CloudTrail：记录控制台与 API 层面的资源变更，例如谁改了安全组、谁创建了快照。
• CloudWatch Logs：采集系统日志、应用日志、认证日志。
• AWS支付卡绑定 Session Manager 日志：记录远程会话，便于审计运维操作。
• VPC Flow Logs：用于追踪网络连通与异常访问来源。

如果你经常遇到“端口明明开放了但还是不通”，VPC Flow Logs 对排查最有帮助，它能快速看出流量是被拒绝、无返回，还是根本没到实例。

3. 补丁和系统重装策略

Linux 建议每月固定补丁窗口，Windows 建议在测试后分批更新。不要在生产实例上长期手工改配置却不沉淀为镜像或自动化脚本。出现系统被篡改、权限异常或基线无法确认时，最稳妥的方案通常不是在线修修补补，而是：

• 保留快照与日志证据
• 创建新 AMI 或使用干净镜像重建实例
• 挂载旧数据卷做只读检查后迁移数据
• 切换流量并下线旧实例

八、按使用场景给配置建议

九、持续优化方向：安全、性能、成本、稳定性一起做

1. 安全优化

• 把 SSH/RDP 作为应急通道，而不是日常默认入口。
• 定期审查 IAM Role 的实际调用记录，删除未使用权限。
• 对高风险端口设置最小来源范围，并启用主机层防火墙。

2. 性能优化

• AWS支付卡绑定 gp3 卷可独立调整 IOPS 和吞吐，适合日志与数据库型负载。
• 安装 CloudWatch Agent 观察 CPU、内存、磁盘和网络，不要只看默认指标。
• 跨地域访问高延迟时，先做 Region 调整和 CDN 前置，再考虑单纯扩容实例。

3. 成本优化

• 不需要公网 IP 的实例取消公网地址，减少暴露面也减少附加成本。
• 快照保留周期按恢复目标设置，避免长期无清理累积费用。
• 把运维入口切到 SSM 后，可减少跳板机和公网管理通道依赖。

4. 稳定性优化

• 关键业务至少跨两个可用区部署。
• 补丁更新前先做快照或 AMI，出现异常可快速回滚。
• 数据库和文件数据分别制定恢复演练，不要只验证“备份创建成功”。

如果你正在做正式上线前检查，建议按“入口收口 → 权限收缩 → 磁盘加密 → 自动备份 → 审计留痕”的顺序执行。这样能先处理最容易被利用的风险，再完善长期治理项，整体改动更稳，也更适合已有业务逐步整改。