我以为我的 AWS EC2 已经安全——直到我检查了 Security Groups

Source: Dev.to

为什么我以为我的 EC2 实例是安全的

和许多初学者一样，我只关注让东西能跑起来：

• EC2 实例成功启动
• SSH 访问正常
• 应用可以访问

当时我就直接往前走——认为安全已经“处理好”。
我最初没有去质疑在配置实例时所做的默认和便利驱动的选择。这正是问题的起点。

我最初使用的安全组配置

创建 EC2 实例时，我允许了类似以下的入站流量规则：

• SSH（端口 22） → 来源：0.0.0.0/0
• HTTP（端口 80） → 来源：0.0.0.0/0

当时觉得这样合理：

• 我需要访问实例
• 我想测试连通性
• AWS 没有给出警告，直接允许

但实际上这意味着更严重的后果。

审查安全组后我的认识

安全组是有状态的虚拟防火墙，控制 EC2 实例的入站和出站流量。
通过允许来自 0.0.0.0/0 的流量，我实际上在说：

“互联网上的任何人都可以尝试连接我的实例。”

这包括：

• 自动化扫描器
• 探测开放端口的机器人
• 寻找错误配置系统的恶意行为者

EC2 实例本身并没有改变——但我的认知改变了。

我的关键错误

1. 过于宽松的入站规则

允许任何地方的 SSH 是最常见的初学者错误之一。即使没有人立刻攻击，你始终面临风险。

2. 把安全组当作设置表单

我把安全组配置当成勾选框练习，而不是安全边界。

3. 没有最小权限原则

我为了便利而开放了超出实际需要的访问。

我为确保 EC2 实例安全所做的更改

限制 SSH 访问

• 只允许来自我特定 IP 地址的 SSH
• 不再全局开放

仔细审查入站规则

• 只打开必要的端口
• 删除未使用或临时的规则

将安全组视为动态控制

• 定期审查，而不是“一次设置后忘记”
• 根据实际使用情况调整规则

这些更改立刻降低了实例的暴露风险。

更大的教训：AWS 不会替你保安

我得到的一个重要认识是：AWS 提供工具——你负责如何安全地使用它们。
EC2 功能强大，但它默认用户已经了解：

• 网络基础
• 访问控制
• 曝露风险

安全组不是高级功能——它们是基础。

这对谁重要

如果你是以下角色，这个教训尤为重要：

• AWS 新手
• 通过动手项目学习云技术
• 第一次部署 EC2
• 为真实的云岗位做准备

及早理解安全组可以帮助你避免后期更大的问题。

我接下来要改进的地方

这次经历促使我思考超越基础设置：

• 使用堡垒机而不是直接 SSH
• 自动化安全检查
• 添加监控和日志
• 设计完全减少公共暴露的架构

安全不是一次性任务——它是持续的实践。

最后感想

我的 EC2 实例之所以不安全，并不是因为 AWS 失职。
而是因为我没有完全理解自己到底放行了什么。

检查安全组只需几分钟——却能防止严重问题。
如果你正在学习 AWS，请从这里开始。