亚马逊云安全保护 AWS 亚马逊云账号安全设置教程

亚马逊云安全保护 根账号安全：别让它成为“万能钥匙”

为什么根账号这么危险？

想象一下，你家的总钥匙就插在门锁上，谁都能拿走。AWS的根账号就是这个“总钥匙”，拥有账号下所有资源的最高权限。一旦被黑，整个云环境可能瞬间变“裸奔”。我见过一个小伙伴，用root账号登录控制台，顺手点了删除按钮，结果整个S3桶里的数据灰飞烟灭——连备份都没来得及。现在他每次看到AWS控制台，手都在抖，生怕再按错一个键。

所以，根账号绝对不能当日常账号用！它唯一的用途就是“紧急情况”时使用，比如重置MFA设备或者创建第一个IAM用户。平时请把它锁在保险箱里，别轻易拿出来。

如何保护根账号？

第一步，给根账号设置超强密码。别用“123456”或者“password”，AWS建议至少14位，包含大小写、数字和符号。比如“Tr0ub4dor&3”这种，虽然看起来像密码，但实际可能容易被破解。更安全的做法是用密码管理器生成随机字符串，再保存好。记住，根账号密码一旦泄露，后果不堪设想。

第二步，立即启用MFA！MFA就像给你的账号加了双重锁，即使密码被窃，黑客也要先过MFA这关。AWS支持硬件密钥、手机应用（比如Google Authenticator）或者短信验证。但别用短信，因为SIM卡劫持的风险太高。建议用Authenticator App或者YubiKey，安全系数更高。操作很简单：登录AWS控制台，进入“我的账户”>“安全凭证”，找到多因素认证，点击“设置MFA”。跟着步骤走，几分钟搞定。

第三步，限制根账号的访问权限。在IAM中设置条件策略，限制根账号只能从特定IP访问，或者只能用于某些操作。虽然根账号默认权限极高，但可以通过条件策略稍微收紧一下，比如只允许在工作时间登录，或者只能在特定VPC里操作。这样即使有人拿到了根账号密码，也很难轻易得手。

IAM用户：给每个操作者发“工牌”

别用root，创建IAM用户

很多新手直接用root账号操作，这简直是“拿大炮打蚊子”——杀伤力太大，风险也太高。正确的做法是为每个团队成员创建独立的IAM用户，分配必要的权限。比如开发人员只需要部署代码的权限，财务人员只需要查看账单的权限。这样即使某个人的账号被黑，影响范围也有限。

创建IAM用户时，AWS会提示你选择访问类型：程序化访问（API密钥）或控制台访问（密码）。如果是开发人员，可能需要API密钥；如果是运维人员，可能需要控制台访问。但记住，不要勾选“为用户创建密码”除非确实需要控制台登录。如果只需要API访问，那就不需要密码，直接用密钥更安全。

另外，别把权限“大包大揽”。比如，给一个只负责EC2的用户分配了S3的完整权限，这就像给厨师一把枪，他可能会误操作。要按需分配，只给必须的权限。

最小权限原则：少给权限多安心

“最小权限原则”是安全界的黄金法则。简单来说，就是给用户刚好够用的权限，再多给一毫都是危险。比如，假设你的团队需要创建EC2实例，但不需要删除它们，那在IAM策略中就只允许CreateInstance，禁止DeleteInstance。这样即使有人误操作，也不会造成灾难性后果。

AWS提供了很多预定义策略，比如“AmazonEC2FullAccess”，但这类策略往往权限过大。更好的做法是自定义策略，只包含必要的权限。比如，只允许在特定区域创建EC2实例，或者只允许访问特定的S3桶。写策略时可以用AWS Policy Generator或者直观的策略生成器，但一定要仔细检查每个权限。

举个例子，有个公司曾给开发人员分配了“AdministratorAccess”策略，结果有人不小心执行了DeleteBucket，整个数据备份全没了。后来他们改用“只读”策略和有限的写权限，安全多了。记住，权限不是越多越好，而是越少越安全。

MFA：账号的最后一道防线

开启MFA，让黑客挠头

多因素认证（MFA）是账号的最后一道防线。想象一下，你的账号密码被偷了，但黑客还得再通过MFA验证，比如手机上的动态验证码。这时候，他们只能干瞪眼，因为MFA的验证码每30秒变一次，根本来不及用。

AWS推荐为所有IAM用户和根账号启用MFA。操作步骤很简单：进入IAM控制台，选择用户，点击“安全凭证”标签，找到“MFA设备”，然后选择“激活MFA”。根据提示，选择设备类型（比如虚拟MFA设备），用手机App扫描二维码，输入验证码即可完成设置。

特别提醒：根账号的MFA必须启用！因为根账号的权限实在太大，一旦被攻破，后果不堪设想。有些公司会设置策略，要求只有启用MFA的用户才能登录，这样就彻底杜绝了单因素认证的风险。

另外，别用短信作为MFA方式。短信验证码可能被SIM卡劫持，黑客通过伪装成你向运营商申请新的SIM卡，就能截获验证码。所以优先选择Authenticator App（如Google Authenticator、Microsoft Authenticator）或者硬件密钥（如YubiKey），安全性更高。

密钥管理：别让“密码本”躺在电脑里

定期轮换访问密钥

程序化访问的密钥（Access Key ID和Secret Access Key）是API调用的凭证，但也是高风险点。很多人把密钥直接写在代码里，或者存到GitHub上，这简直就是“把银行卡密码贴在门口”。正确的做法是：

• 定期轮换密钥：AWS建议每90天更换一次密钥。在IAM控制台中，可以创建新密钥，然后在应用程序中更新，再删除旧密钥。
• 不要将密钥硬编码到代码中：使用AWS IAM角色，或者环境变量，或者AWS Secrets Manager来管理密钥。比如，在EC2实例上，应该用实例角色，而不是直接使用访问密钥。
• 禁用未使用的密钥：如果某个密钥已经不再使用，立即禁用或删除。比如，一个已经离职员工的密钥，必须及时处理。

我有个朋友曾经把密钥上传到GitHub，结果被黑客发现，用来盗取云资源挖矿。他的AWS账单一夜之间暴涨到上万美金，最后还得自己掏腰包补上。所以，密钥管理一定要重视，别让“小疏忽”变成大麻烦。

监控与审计：云上的“监控摄像头”

开启CloudTrail

CloudTrail就像云环境的“监控摄像头”，记录所有API调用和操作日志。开启后，你可以看到谁在什么时候做了什么操作，比如谁删除了EC2实例，谁修改了安全组规则。这对于事后审计和安全事件调查至关重要。

开启CloudTrail很简单：在AWS控制台搜索CloudTrail，创建跟踪，选择“所有区域”并启用日志文件加密。然后设置日志存储到S3桶中，这样即使有人试图删除日志，也至少有备份。建议开启“事件查询”功能，这样可以直接在控制台查看日志，不用下载文件分析。

比如，如果发现某天凌晨有异常的API调用，比如从某个陌生IP登录，可以快速定位问题。CloudTrail日志还能和AWS CloudWatch结合，设置告警，比如当删除重要资源时立即通知管理员。

使用GuardDuty检测威胁

GuardDuty是AWS的威胁检测服务，它会分析CloudTrail、VPC Flow Logs和DNS日志，自动检测异常行为。比如，发现某个EC2实例在连接已知的恶意IP，或者有暴力破解尝试。GuardDuty会生成安全警报，帮助你及时处理威胁。

开启GuardDuty只需在控制台点击“启用”，然后选择需要监控的区域。它会自动分析日志，无需额外配置。不过要注意，GuardDuty会生成一些警报，需要定期查看，避免漏掉真正的威胁。比如，曾经有个客户收到GuardDuty警报说有SSH暴力破解，及时排查后发现是员工的测试环境被误配置，避免了潜在的入侵。

亚马逊云安全保护 网络与资源安全：别让“大门”敞开着

安全组设置：防火墙要严格

安全组是EC2实例的“防火墙”，控制进出流量。默认情况下，安全组可能开放了所有端口，比如SSH（22端口）对0.0.0.0/0开放，这意味着任何IP都能尝试连接。这是非常危险的。正确的做法是：

• 只允许特定IP访问SSH端口，比如公司办公网IP。
• 对于Web服务器，只开放80和443端口，并且限制来源IP为负载均衡器或CDN的IP范围。
• 定期检查安全组规则，删除不必要的开放端口。

比如，有个团队曾经把数据库的安全组设置为“所有IP可访问”，结果被黑客扫描到，直接拖走了数据。后来他们把数据库放到私有子网，只允许应用服务器访问，才解决问题。记住，网络层面的安全同样重要，别让“大门”敞开着。