数据上云这件事很多人最担心的一环就是安全。一说到AWS安全有人觉得是玄学有人觉得把数据丢上去就万事大吉其实都不对。我做了几年云落地相关的项目见过太多因为前期安全配置没做好、后期被账单、被漏洞、被权限问题追着跑的例子。这篇文章就想把这些入门阶段最该盯住的基础防线从头到尾拆开讲清楚让准备把数据迁到AWS上的团队在动手之前先有一张清晰的作战地图。标题看着是“入门”但内容不糊弄。我会从责任共担模型讲起再到IAM权限、VPC网络边界、数据加密、日志审计最后给一份可以直接照着抄的上云前自查清单。适合谁看准备把第一个生产环境迁到AWS的运维和开发同学以及被老板问“云上安不安全”但不知道怎么回答的技术负责人。看完你会发现AWS安全没有想象中那么玄只要抓住几条主线一步步配置到位它比很多自建机房要可靠得多。1. 先搞懂责任共担模型上云安全的第一步不是配置是划清界限很多人对云安全的误解是从“我把数据放你那儿了你就得全权负责”开始的。AWS有一整套安全体系但它不是保姆。你要是不理解责任共担模型的边界后面所有配置都可能走偏。1.1 租公寓的逻辑AWS管什么你管什么责任共担模型Shared Responsibility Model是AWS所有安全文档的基石。用租公寓来类比特别好理解物业公司负责大楼结构、公共水电、电梯保养、门禁系统这部分出了问题比如水管爆了、电梯坏了是物业的活但你自己屋里的家具、门窗锁、贵重物品怎么保管、出门有没有反锁这是你自己的事。放到AWS上AWS负责的是“云本身”的安全全球机房的物理安全、硬件设备的可靠性、虚拟化层的隔离、托管服务S3、RDS这些底层基础设施的维护。至于你的数据分级、IAM权限怎么分、EC2上要不要打补丁、安全组怎么配、应用代码有没有漏洞这些统统是你自己的责任。我见过最典型的反面案例有人把数据库的公网端口直接暴露在0.0.0.0/0被扫到密码爆破数据被拖走。事后他第一反应是“AWS安全性太差了”。但AWS从一开始就在文档里写得很清楚2255端口是否对外开放、密码强度够不够这些属于你的责任。云厂商做得再好也架不住你把大门钥匙挂在门口。1.2 当云厂商出故障时靠兜底的是你自己责任共担模型还有个容易被忽略的隐藏含义即使是成熟的云厂商也有故障的时候。2023年和2024年AWS都出现过影响范围较大的区域故障事件很多人当时才发现自己以为的“高可用”其实是个假象。如果只在一个可用区部署了应用没有跨可用区的负载均衡和数据库主备一旦该可用区出问题业务就停摆。这时候能兜底的不是云厂商而是你自己提前做的架构设计多可用区部署、自动伸缩组、RDS多AZ、S3跨区域复制、定期备份和恢复演练。这些都属于“你的责任”范畴。说白了安全不只是防黑客也包括防故障、防误删、防配置漂移。你在责任共担框架里越早意识到“自己需要承担的部分”后面每一项配置都会做得更扎实。2. IAM权限体系把钥匙管理员当回事AWS安全里最容易出事故的环节不是网络攻击而是人的操作失误。而IAMIdentity and Access Management身份与访问管理就是所有权限操作的入口。很多账号被入侵不是云厂商防线被突破而是管理员自己的Access Key泄露、密码太弱、权限给得太大。2.1 根账号只做保险箱日常干活用IAM用户注册AWS账号后拿到的那个账号是根账号Root User它拥有整个账号的完全控制权。很多人为了方便一直用根账号登录控制台、创建访问密钥、跑AWS CLI这是入门阶段最容易犯的错误。正确做法是根账号开启多因素认证MFA用强密码保存好最好再绑一个不常用的安全邮箱然后把它锁进“保险箱”。日常所有操作都通过IAM用户完成。具体落地步骤用根账号登录控制台先开启MFA推荐用虚拟MFA应用Google Authenticator这类或硬件MFA Key。创建第一个IAM用户加入Admins用户组该用户组附加AdministratorAccess托管策略。给这个管理员IAM用户也开启MFA。之后退出根账号改用IAM用户登录。确认根账号没有创建任何Access Key如果之前创建过立刻删除或停用。2.2 最小权限不是口号是写进策略的规则最小权限原则Least Privilege听上去是安全圈的老生常谈但它真的是IAM里最核心的一条。很多团队图省事给所有开发人员统一分配一个管理员策略出事了根本分不清是谁动了什么资源。最小权限落到实操上就是把每个人“要做的事”和“需要的权限”一一对应。比如前端开发只需要读取S3里的静态资源就给只读权限后端开发需要往S3传图片就给PutObject和GetObject权限。每个IAM策略都应该是“白名单”逻辑默认没有权限按需添加。举一个S3只读策略的例子{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ s3:GetObject, s3:ListBucket ], Resource: [ arn:aws:s3:::my-app-assets, arn:aws:s3:::my-app-assets/* ] } ] }注意Resource写了两行第一行是桶本身对应ListBucket第二行是桶里的对象对应GetObject。这是S3策略里最容易漏掉的一处漏了第二行GetObject就会报错漏了第一行aws s3 ls就没法列出桶内容。很多初学者在这上面卡半小时其实原理很简单S3的桶和对象是两个独立的授权层级。2.3 关键教训密钥泄露怎么来的怎么防IAM用户创建时可以生成一组Access Key和Secret Access Key用来调用AWS CLI或SDK。这组密钥一旦泄露等于把账号的部分控制权交给了别人。现实里最常见的泄露途径是把密钥硬编码在代码里然后代码不小心推到GitHub仓库。我遇到过一次真实事故一个团队的Access Key被打包进Docker镜像镜像推到公共仓库结果几分钟内就被爬虫扫到攻击者用这个密钥批量调用EC2 RunInstances起了一堆实例跑挖矿程序。等团队发现一个月账单已经多了几万块光清理和复盘就折腾了一周。避免这类事故可以这样做不要在代码、仓库、镜像、配置文件里保存任何Access Key。用IAM角色代替长期密钥。EC2、ECS、Lambda这些计算服务都可以在运行时自动注入临时凭证不需要任何Access Key。如果某个场景必须使用长期密钥比如本地开发记得定期轮换并在IAM控制台查看“上次使用时间”把超过90天未使用的密钥删除。AWS CLI配置时不要用管理员用户的Access Key给本地产一个“只读用户”的密钥够用就行。使用aws cli的时候可以先跑aws sts get-caller-identity确认当前用的是哪个身份再执行实际命令避免不小心用管理员身份跑了高危操作。3. 网络边界VPC、安全组、WAF与DDoS防线网络层是云上安全的最外层防线也是攻击者最先碰到的部分。AWS的网络防护能力很丰富但如果配置不对再强的能力也拦不住。3.1 用VPC把生产环境关进独立“小区”VPCVirtual Private Cloud虚拟私有云相当于你在云上划出的一块独立网络空间和小区一样有自己的门牌号CIDR网段、出入口Internet Gateway、内部道路路由表。入门阶段建议这样规划VPC生产环境和开发环境用不同的VPC彻底隔离避免测试环境的网络策略影响生产。生产VPC内划分多个子网Web层放公有子网需要接收外部流量应用层和数据库层放私有子网不直接暴露公网。私有子网如果需要访问外网比如拉取系统补丁用NAT网关而不是直接给它分配公网IP。数据库子网不要配置路由到Internet Gateway只在内部通过应用层访问。这套结构就是经典的“三明治”架构外层接收流量中层处理业务内层存数据每一层之间都有防火墙安全组隔离。攻击者就算突破最外层也得再穿过一层才能碰到核心数据。3.2 安全组默认拒绝按业务链路逐层放行安全组Security Group是AWS的核心网络安全组件相当于实例级防火墙。两个关键特性默认全部拒绝Deny by Default只有显式添加的规则才能放行有状态Stateful只要入站流量被允许出站响应就自动放行。很多新手在这里会犯迷糊其实记住“按业务链路逐层放行”这句话就够了Web层实例只允许80/443端口从负载均衡器进入。负载均衡器只把流量转发给Web层的安全组。应用层实例只允许8080端口从Web层的安全组进入不直接对公网开放。数据库实例只允许3306端口MySQL或5432端口PostgreSQL从应用层安全组进入。这里有个特别实用的技巧安全组的Source可以直接引用另一个安全组ID而不是写IP地址。比如数据库安全组只允许“来自应用层安全组ID的流量”这样即使应用层实例的IP变了规则也不用改而且比写CIDR更安全因为它精确到了特定的实例集合。3.3 WAF能挡什么又挡不住什么AWS WAFWeb Application Firewall是应用层的Web防火墙通常挂在CloudFront或ALB前面用托管规则集就能挡住相当一部分常见攻击比如SQL注入、XSS跨站脚本、恶意爬虫等。它还支持自定义规则比如限制某个IP的访问速率、屏蔽特定国家地区的流量、拦截带恶意签名特征的请求。但WAF不是银弹我在实战中见过不少“WAF已开启但还是被打了”的案例。常见原因有攻击者利用编码绕过或分块传输绕过WAF检测规则这就是网上经常讨论的“WAF Bypass”问题。WAF匹配的是特征模式攻击者通过大小写混淆、URL编码、参数污染等方式可以让特征匹配失效。业务逻辑漏洞WAF管不了。比如订单金额被篡改、越权访问其他用户的数据这类请求看起来完全是正常的WAF不会拦截。分布式慢速攻击比如Slowloris单个请求看起来没问题但组合起来可以拖垮后端。所以WAF的正确用法是作为第一道防线挡住批量化的、特征明显的攻击但应用层的代码质量和安全测试不能放松。WAF挡不住应用本身写出来的洞也挡不住逻辑层的漏洞。把WAF当成安全体系的“重要一环”而不是“全部”。3.4 DDoS与公网暴露面的基础防护AWS Shield Standard是免费的默认开启主要防护网络层和传输层的常见DDoS攻击。只要你的流量经过CloudFront或Route53它就能自动清洗一部分攻击流量。如果业务规模大、面向公网且对可用性要求很高可以评估Shield Advanced但费用不低入门阶段先用免费版就好。比高级防护更重要的是把公网暴露面缩到最小。很多DDoS攻击其实是在扫“哪些端口开着”端口开得越多被利用的反射面就越大。我见过有团队把SSH的22端口对全网开放结果每天被爆破几十万次。正确做法是SSH只允许办公网IP访问或者通过堡垒机跳板登录数据库等内部服务绝不开放公网端口所有非必要服务都放在私有子网里。再说一个容易被忽略的点S3桶默认是可以通过公网API访问的如果你的业务只允许VPC内部的实例访问桶可以配置S3 VPC Endpoint走内部网络通路不经过公网既能节省流量费用也降低暴露面。4. 数据加密、日志审计与合规底座网络层防住外部攻击数据加密和日志审计则是数据安全和事故追溯的关键。数据上云之后敏感数据一旦被拖走如果没做加密等于裸奔如果没做审计连谁动的都不知道。4.1 静态加密与传输加密让数据在任何一个环节都“不可直接读”数据在云端通常分两种状态存储时的静态数据和传输过程中的动态数据。两种状态都要加密。静态加密方面S3、EBS、RDS都支持免费开启加密S3可以在桶设置里开启Default Encryption用SSE-S3AWS托管密钥或SSE-KMS通过KMS管理密钥。EBS创建卷时选择加密这样该卷上的所有快照也会自动加密。RDS创建实例时勾选加密选项数据库存储、备份和自动副本都会加密。入门阶段建议全部开启默认加密。费用上SSE-S3基本免费SSE-KMS会有KMS密钥调用费但通常很低。不要为了省这几块钱把加密关掉数据泄露一次的成本够你加密几百年。传输加密方面对外服务强制启用HTTPS/TLS可以用ALB策略强制最低TLS 1.2版本关闭老旧协议。内部服务之间同样建议启用SSL/TLS防止内网中的横向窃听。还有一个容易忽略的点访问S3时尽量使用HTTPS Endpoint不要在代码里用http://去调用AWS API。4.2 KMS与Secrets Manager钥匙也要安全地放加密的钥匙如果和数据放在一起加密就失去了意义。AWS KMSKey Management Service集中管理密钥通过权限策略控制谁能用哪个密钥、谁能管理哪个密钥。创建密钥时建议开启自动轮换让密钥定期更换。数据库口令、API密钥这类敏感信息不要明文写在配置文件和环境变量里更不要写进代码仓库。用AWS Secrets Manager管理应用运行时从Secrets Manager读取配合IAM权限精确控制能读哪些密钥。这样即使代码仓库被泄露攻击者也拿不到真正的数据库口令。这里有一个很多人忽略的权限细节KMS密钥权限和IAM权限是两层独立的权限体系。就算IAM策略允许你解密如果KMS密钥策略里没授权照样解密失败。配置的时候要同时看IAM侧和KMS侧排查问题也按这个思路来。4.3 CloudTrail、GuardDuty与Config出事前发现出事后追溯安全事件最怕的其实是“不知道发生了什么”。CloudTrail是AWS的API审计服务记录账号内所有API操作包括谁在什么时间调用了什么接口、参数是什么、源IP是什么。这是安全事故发生后最直接的溯源证据。建议在所有区域开启CloudTrail并把日志投递到一个集中管理的S3桶开启日志文件完整性验证防止日志被篡改。GuardDuty是威胁检测服务基于机器学习识别异常行为比如API调用频率异常、访问已知的恶意IP、出现挖矿行为特征等。它的部署成本不高建议在整个账号开启并且把告警接入SNS通知到运维群。AWS Config则是配置审计工具持续监控资源状态是否偏离合规基线。比如它能发现某个安全组的入站规则被意外从限制IP改成了0.0.0.0/0或者某个S3桶突然被允许公开访问。这类配置漂移很适合用Config做自动检测。4.4 备份与合规安全里最容易忽略的最后一公里数据安全还有一个最朴素的指标丢了能不能恢复。因此S3版本控制、RDS自动备份、EBS快照、跨可用区部署这些能力本身就是安全防线的一部分。建议把“恢复演练”也纳入安全检查的例行项目不要等到真丢了数据才发现备份从来没验证过。合规方面AWS提供了大量合规认证材料比如ISO 27001、SOC系列报告可以在Artifact服务里直接下载用于合同审计或客户尽调。如果团队有国内合规测评需求建议提前跟测评机构确认部署形态和数据驻留要求把日志留存周期、数据存储区域这些细节规划好不要等上了云之后再来补。这部分事情虽说不算“技术”但漏掉一次代价往往比技术配置失误更大。5. 上云前安全自查清单照着抄就行讲完了各个模块最后给一份可以直接拿来用的自查清单。这是我每次帮团队做上云前评估时会过的内容整理成表格方便你对着勾。5.1 六个阶段的自查清单阶段检查项完成标准账号与身份根账号MFA已开启并保存好恢复码账号与身份根账号Access Key已删除或停用账号与身份管理员IAM用户已创建并启用MFA账号与身份普通用户权限按最小权限分配无多余管理员网络边界VPC划分生产/开发隔离Web/应用/DB分层网络边界安全组规则全部默认拒绝按链路放行网络边界SSH/RDP端口不对公网开放走堡垒机或办公网IP网络边界数据库端口不对公网开放存储与数据S3 Block Public Access已开启存储与数据S3默认加密已开启存储与数据EBS/RDS加密已开启存储与数据备份策略RDS自动备份、EBS快照、S3版本控制已启用监控与日志CloudTrail多区域开启日志投递S3监控与日志GuardDuty已启用监控与日志AWS Config已启用关键规则监控与日志告警通知SNS告警已接入运维群应急与合规恢复演练已至少验证一次数据可恢复应急与合规合规要求已确认数据驻留和日志留存要求这18项不用一天做完但每一项都不要跳过。我见过很多团队赶迁移进度前面账号阶段没做好后面所有安全策略都建立在沙地上出了事故才回头补代价大得多。5.2 迁移窗口里的安全禁忌迁移上云期间因为时间紧、过程复杂安全配置最容易出现临时性妥协。这里有三条禁忌是拿真金白银换来的教训第一迁移时不要让数据库端口临时对全公网开放。有些团队为了从本地机房同步数据把数据库安全组临时改成只允许某个IP后来忘了收回去等于给攻击者留了一扇后门。第二不要为了赶进度跳过IAM最小权限配置。临时给某个用户开个AdministratorAccess想着“迁完再收”结果迁完了也忘了收权限就一直挂在那里。第三迁移工具和脚本里不要硬编码敏感凭证。用DMS、SCT这类迁移服务时凭证通过IAM角色和Secrets Manager管理不要写在脚本参数里。6. 常见问题速查与避坑心得最后把实际运维中最多碰到的问题和排查思路整理成速查表再分享几个踩过坑之后的经验。6.1 高频问题排查表问题现象常见原因排查与解决思路S3文件突然对公网可读桶策略误配置或ACL公开开启S3 Block Public Access用Access Analyzer扫描公开桶ECS里的应用读取不了S3对象实例没有附加IAM角色给ECS任务角色附加S3只读策略确认角色有Trust Policy安全组放行了还是连不上数据库网络ACL或实例系统防火墙又挡了一道逐层自检安全组→网络ACL→系统防火墙→服务监听地址CloudTrail没有日志S3投递桶策略没给CloudTrail写权限检查桶策略、KMS密钥策略确认投递配置某个IAM用户密钥可能在泄露CloudTrail发现未知区域登录或API调用立刻停用密钥查CloudTrail定位影响范围检查EC2和账单跨区域误操作创建了一堆高配实例IAM策略没限制区域在IAM策略里加Condition限制区域设置预算告警6.2 我踩过的几个坑第一个坑是跨区域权限。以前团队里有同学用管理员账号在海外区域创建了一堆重型实例做测试月底账单翻了好几倍。后来我在IAM策略里给所有用户加了Condition限制只允许在指定的区域操作这个坑才算填上。具体做法是在策略里加一段Condition: { StringEquals: { aws:RequestedRegion: [ap-northeast-1, ap-southeast-1] } }不过要小心别把IAM、CloudFront这类全球服务也限制住了需要单独放行。第二个坑是安全组规则改完没验证。有一次我改数据库安全组的入站规则把自己办公网的IP写错了结果远程工具连不上数据库排查了半小时才发现是安全组里IP打错了一位。教训是改网络规则后第一件事就是立即连接验证不要等到业务方反馈才发现。第三个坑是日志不归档。CloudTrail日志默认存90天时间一过自动删除。后来我配置了S3生命周期规则把CloudTrail日志自动转储到Glacier归档存储留存期设为多年费用也低。否则出事想追查半年之前的操作记录就真的找不回来了。个人习惯上我每次做安全配置都遵循一个顺序先账号身份再网络边界再数据加密最后日志监控。这个顺序就像盖房子打地基一层一层往上叠每次开始新项目我都会先过一遍第5节那张清单再动手做具体的迁移配置。说实话前期多花一小时把IAM和安全组做扎实后期至少能少熬好几个通宵。最后再分享一个小技巧如果你不知道怎么判断某个权限该不该给先不给跑一遍业务做一遍测试真报错了再补权限——这个过程看着费事但能让你的权限体系保持最小化少很多不必要的暴露面。
