亚马逊云安全保护 亚马逊云 AWS 账号多子号管理代开

亚马逊云安全保护 你有没有过这种体验？刚在AWS控制台点开EC2，手一抖删错了生产环境的RDS实例——然后发现，这个实例和你的测试账号、开发账号、财务账号，全挤在同一个根账号里，像一锅乱炖的麻辣烫，香是香，但谁也分不清哪块毛肚归谁管。

一、别再拿根账号当全家福了

AWS官方文档里把“单账号起步”写得温温柔柔，仿佛它是个慈祥的老奶奶，张开双臂欢迎你拎着一箱EC2、两袋S3桶、三捆Lambda函数直接入住。可现实呢？等你上了生产，来了审计，来了财务要分摊账单，来了安全团队半夜打电话说‘你那个dev-test-2023的IAM用户居然有AdministratorAccess’……那一刻，你才恍然大悟：原来不是AWS不提醒你分家，是你自己舍不得买新碗筷。

多子账号不是炫技，是生存刚需。就像你不会让实习生、会计、CTO共用一张门禁卡刷进机房——AWS也一样。账号即边界，边界即责任。一个账号=一套独立的IAM策略、独立的CloudTrail日志、独立的账单、独立的资源命名空间、独立的合规水印（比如GDPR或等保三级要求的逻辑隔离）。想混着用？可以，但建议提前写好辞职信，措辞诚恳些。

二、Organizations：AWS官方认证的“云上居委会”

别再手动建十个账号再挨个发邮件邀请了！AWS Organizations不是工具，是组织哲学。它让你用一个“管理账户”（Management Account）统管所有“成员账户”（Member Accounts），像居委会主任拿着花名册，谁家WiFi蹭太猛、谁家服务器半夜挖矿、谁家S3桶忘了关public-read，一眼尽收眼底。

创建流程简单到令人感动：进入Organizations控制台 → 创建组织 → 添加账户（支持新建或邀请已有账号）→ 设置服务控制策略（SCP）。重点来了——SCP不是IAM策略，它不授予权限，而是砍权限。比如给所有非生产账号加一条SCP："禁止启动t3.2xlarge以上实例"，从此再也不用担心实习生为跑个Hello World买了个r6i.4xlarge，账单出来时你的心跳比CloudWatch告警还准。

小贴士：别把SCP当万能膏药

有人试图用SCP一刀切禁掉所有root操作，结果连创建S3存储桶都报错。记住：SCP只限制成员账号的最大能力上限，具体能干啥，还得靠各账号内的IAM策略来细粒度授权。它俩关系，类似“宪法”和“部门规章”——宪法说“不能造原子弹”，部门规章才规定“行政部只能订咖啡，技术部才能碰KMS密钥”。

三、SSO：告别17个密码+3个浏览器隐身窗口的悲惨人生

以前管理5个AWS账号，等于每天在Chrome、Edge、Firefox里各开两个隐身窗口，每个窗口记一个密码，还要反复切换MFA设备——活脱脱当代数字版《盗梦空间》，三层嵌套，意识快断联。

AWS SSO（Single Sign-On）就是那个递给你一把万能钥匙的人。它不存密码，只管身份源（AD、Okta、甚至自带用户池），一次登录，自动映射到所有关联子账号的预设角色（比如DevAccount-ReadOnly、ProdAccount-Deployer）。最爽的是：你改一次AD密码，所有AWS账号权限同步刷新；HR删了离职员工账号，他第二天连登录页都打不开，更别说删S3了。

注意：SSO角色默认没有权限，你得在每个子账号里用IAM创建对应角色，并赋予Trust Policy信任SSO的Provider ARN。这步常被跳过，导致SSO登录成功却提示“Access Denied”——不是系统坏了，是你忘了给人家发工牌。

四、账单分家：让财务部对你露出微笑

财务部最恨什么？不是超支，是“这笔$2,389.42到底算市场部还是研发部的？”AWS账单默认按根账号聚合，像一盘没拌匀的蛋炒饭，米饭粒儿和蛋花儿黏成一团。

解决方案就俩字：标签（Tags）。但光打标签不够，得配合Cost Allocation Tags开启+ Cost Explorer深度钻取。我们实践下来最稳的组合是：
• 强制所有资源创建时带Project、Environment（prod/staging/dev）、Owner三个标签；
• 在Billing Console开启这些为Cost Allocation Tags；
• 每月初用Cost Explorer导出CSV，按Project+Environment透视，生成部门级报表。

曾有个客户坚持不用标签，结果季度审计时翻了三天CloudTrail找谁启的EKS集群——最后发现是实习生用个人GitHub账号绑的OIDC，根本没走公司SSO。所以，标签不仅是分钱工具，更是责任溯源GPS。

五、权限隔离实战：最小权限不是口号，是肌肉记忆

“最小权限原则”被念叨烂了，但真正落地时，很多人还在写"Resource": "*"。别急着骂，我们当年也这么干过——直到某天发现，一个本该只读S3的CI/CD角色，因为Policy里漏写了Condition，顺手删了整个合规审计桶。

推荐三板斧：
第一斧：用AWSServiceRoleFor***系列托管角色——比如AWSServiceRoleForAutoScaling，专为ASG服务设计，权限精准到行，不带私货；
第二斧：对跨账号访问，必用Resource-based Policy——比如S3 Bucket Policy明确允许dev-account通过AssumeRole访问特定前缀；
第三斧：定期跑Access Advisor——进IAM控制台，点角色→Access Advisor页签，看哪些权限三个月没被调用，直接删。别怕，删错了会报错，报错比背锅强。

彩蛋：一个冷知识

AWS Organizations支持创建OU（Organizational Unit），你可以把dev/test/prod账号分在不同OU里，再针对OU批量应用SCP。比如给PROD-OU加一条："禁止删除任何带有Production=true标签的资源"。这招，比在每个账号里手写10遍策略优雅多了。

六、最后说句掏心窝的

多子账号管理不是一步到位的魔法，而是一场持续的园艺——你得修剪SCP的枝杈，浇灌SSO的信任链，给标签施肥，时不时拔掉闲置角色的杂草。刚开始可能觉得麻烦，像每天早起叠被子。但半年后你会发现：审计报告通过了，财务邮件夸你账单清晰，新同事入职3分钟就能进对应环境干活……那时候你会懂：所谓云原生治理，不过是把混沌，种成了秩序。

对了，如果你现在正盯着那个孤零零的根账号发呆，不妨就今晚——关掉这个页面，打开AWS Organizations，建第一个子账号。就当给未来的自己，寄一封不用邮票的信。