信任策略与可承担角色的主体

信任策略是附加到角色的文档，用于明确规定哪些主体可以代入该角色。它就是守门人：即使权限策略授予了强大权限，如果信任策略没有列出某个主体，该主体也无法使用该角色。在考试中，信任策略错误经常会导致访问失效或权限授予过度。

信任策略的 Principal 元素可以引用：

• AWS — 账户、用户或角色 ARN（Amazon Resource Name）。
• Service — AWS 服务，例如 lambda.amazonaws.com。
• Federated — SAML 提供商或 Web 身份提供商。

选择正确的主体类型并尽可能具体，对于避免授予超出预期的信任至关重要。

跨账户代入要求双方达成一致。目标账户中的角色信任策略必须允许调用主体，并且该主体必须拥有身份策略，允许其对该角色的 ARN 执行 sts:AssumeRole。缺少任一部分都会阻止请求。这种双向握手是经典的考试陷阱。

此信任策略允许账户 111122223333 中的特定角色代入该角色。与信任整个账户相比，指定确切的 ARN 更严格、更安全。

将主体指定为 arn:aws:iam::ACCOUNT:root 表示信任整个账户：该账户中任何同时拥有 sts:AssumeRole 权限的主体都可以代入角色。这种信任范围很大。在可能的情况下，请指定确切的用户或角色 ARN，以遵循最小权限原则并缩小信任面。

信任策略支持使用 Condition 块来进一步限制谁可以代入角色以及代入方式。常见的键包括 sts:ExternalId（用于阻止“困惑代理人”问题）、aws:MultiFactorAuthPresent（要求 MFA）和 aws:SourceIp。条件可以让您仅在特定且可验证的情况下授予代入权限。

一种强大的做法是在代入敏感角色之前要求 MFA。信任策略中的条件会检查调用会话是否通过 MFA 完成身份验证。这样，即使长期凭证被盗，没有第二重身份验证因素，攻击者也无法代入特权角色，从而显著提高攻击难度。

某些角色是服务相关角色，由 AWS 预先定义，并且其信任策略无法编辑。这些角色允许服务代表您管理资源，同时仅使用 AWS 所要求的信任。识别这类角色很重要，因为它们的权限和信任受到严格控制，并且与服务的生命周期紧密关联。

信任内部主体（同一账户）通常比信任外部账户或第三方 SaaS 供应商的风险低。对于外部信任，请始终将特定主体与 ExternalId 等条件结合使用。应将每条外部信任声明都视为攻击者会极力利用的入口点。

IAM Access Analyzer 会自动审查信任策略和资源策略，查找可以被外部账户或公众代入的角色。它会标记非预期的跨账户信任或公共信任，以便您收紧相关配置。审查 Access Analyzer 的发现结果，是发现信任范围过大的推荐控制措施，也是考试相关的重要内容。

要安全地设计信任关系，请指定尽可能具体的主体，在适当情况下添加 ExternalId 和 MFA 等条件，优先使用角色而不是信任账户根主体，并通过 Access Analyzer 进行审查。请记住，信任策略回答的是谁，而权限策略回答的是什么；两者必须保持一致，访问才能正常工作并持续遵循最小权限原则。

测试您对信任策略的了解。

信任策略定义哪些主体可以代入角色，并且无论权限策略如何，它都是守门人。跨账户代入需要双向握手：信任策略加上调用方的 sts:AssumeRole 权限。优先使用特定主体 ARN，而不是账户根主体；添加 ExternalId 和 MFA 等条件；并使用 IAM Access Analyzer 进行审计。