如果你的审计员上来就找你要AWS的登录用户名和密码，这本身就是第一个安全发现标记。很多公司在面对外部审计要求时，第一反应不外乎两招：要么在账号里新建一个IAM用户，把访问密钥打包发过去；要么在自家的身份提供商里给审计员开个账户，让他们能直接进控制台。

但说实话，这两种做法都不必要。审计员根本不需要在你公司的体系里拥有一个正式的登录入口，有API访问权限就完全够用了。AWS其实在十多年前就为这类场景准备好了专门的机制，一直用到今天，也是AWS合作伙伴和各种第三方监控工具普遍使用的模式。

核心就是一条：创建一个可跨账户访问的IAM角色，加上信任关系。整个过程里，不需要传递任何一组长久凭证。在这篇文章里，我会把这个模式的运作逻辑讲清楚，同时分享我搭建好的两个CloudFormation模板，一个针对单个AWS账户，另一个覆盖整个组织，部署只需要五分钟左右。

选择直接新建用户，相当于把一项本可避免的负债，主动背在了自己身上。因为访问密钥是长期有效的，从创建那一刻起，就会一直生效，直到有人记得删掉它为止。我读到过的每次审计翻车案例，几乎都牵扯到那些早已过期却依然活跃的密钥。而密码的共享就更不可控，邮件、即时消息、随手一条短信，只要凭证离开了你的手，你就再也追不回它的去向。

在身份提供商里给外人开用户，对目录本身就是一种污染。外部人员可能被顺手塞进某个小组，附带获得你完全没想给的权限，或者分配到某个应用访问授权，最后还得靠人记着去销户。这些操作本质上都在增加组织暴露面，与最小权限原则背道而驰。

跨账户角色加外部ID的模式，解决思路极其直接。不给审计员你的凭证，而是在你的AWS账户里创建一个角色，并允许审计员自己的AWS账户来代入。整个安全保障由四部分构成。

第一，信任策略里只指定一个精确的AWS账户号，是账户对账户的信任，不涉及具体用户或密码。审计员在自家账户里完成身份验证后，通过STS的AssumeRole接口，临时获取你这个角色对应的凭证。第二，外部ID充当了信任关系的暗号，由你和审计员私下约定，作为信任策略里的条件判断。就算受信任的账户账号被泄露，如果拿不出这个外部ID，角色也无法被代入。这在防止混淆副手问题上尤其关键：如果审计员同时为多个客户服务，某个恶意客户没办法利用审计员的工具链来误访你的资源，因为他们不知道你的外部ID。

第三，所有访问都是短期的。STS会话默认一小时过期，并且时长可调。整个设置里不存在任何长久的静态凭据。第四，每一条AssumeRole调用，以及审计员后续发起的每一次API操作，都会完整落在你自己的CloudTrail里，全部关联到这次审计角色的会话。你能清晰回溯到底看了什么、在什么时间点，全程可审计。

权限方面遵循最小够用：只读，而且划定范围。模板里直接选用AWS托管的ReadOnlyAccess和安全审计策略，另有可选的计费只读权限。部署那块，我把所有步骤打包进了两个CloudFormation模板，单账号和全组织版都已经放在GitHub上，整个部署流程不超过五分钟。