随着云计算的普及，越来越多的企业开始依赖亚马逊网络服务（AWS）来托管其关键业务系统。为了确保访问安全，AWS通过OpenID Connect（OIDC）实现第三方身份验证，允许各种SaaS解决方案与AWS账户安全集成。然而，OIDC集成中的配置错误常常导致安全漏洞，使攻击者能够绕过权限限制，获取对AWS资源的非法访问。对此，了解和掌握正确的集成条件设置变得尤为重要。本文将深入剖析AWS OIDC集成过程中常见的错误和潜在漏洞，结合不同厂商的集成要求，提供系统性的安全配置指导。 OIDC是一种基于OAuth 2.0协议的身份层协议，它允许客户端应用验证用户身份，并获取有关用户的基本信息。
当使用OIDC与AWS进行集成时，权限的控制集中反映在IAM角色的信任策略中。这些策略中包含多个条件（Condition）以限制谁可以通过OIDC身份验证来假设（Assume）IAM角色。忽略某个关键条件往往就会造成权限放大或泄露，给企业带来严重的安全隐患。 GitHub Actions是2023年初曝光AWS OIDC集成错误风险的典型案例。研究者发现，部分企业在IAM角色的信任策略中忽略了“sub”条件，使得任何拥有GitHub账户的人都能自定义GitHub Action，并借此假冒授权访问受害企业的AWS资源。“sub”条件代表身份令牌中的主题标识，它限定了允许访问的特定代码仓库和分支路径，从而确保访问权限的粒度化控制。
缺失该条件即意味着权限边界的模糊，容易遭受恶意攻击。AWS官方已对此漏洞采取措施，防止新配置中遗漏“sub”条件，但遗留配置依然存在潜在风险。除了GitHub Actions，类似的问题也被发现在其他SaaS供应商集成中，如Terraform Cloud、Microsoft Defender以及GitLab等。这些问题的根源均是缺乏对身份令牌的精细条件筛选，导致任意注册用户可获取对客户AWS账户的未经授权访问。 为了遏制此轮安全风险的蔓延，行业内专家对公开文档中的二十多个主流厂商的OIDC集成说明进行了深入研究，试图归纳出统一的安全配置规范。研究结果显示，并非所有厂商的集成条件完全依赖“sub”。
例如，Microsoft Defender强制要求“sts:RoleSessionName”条件，而DoIT厂商则使用“aws:RequestTag/DoitEnvironment”等自定义标签作为条件限制。这提示我们，简单的条件判断不足以覆盖所有场景。与此类似，有些厂商重点校验“aud”字段，它代表身份令牌的受众范围，是识别认证请求是否针对AWS服务的关键。需要注意的是，某些厂商为所有客户提供统一的“aud”值，如GitHub统一使用“sts.amazonaws.com”，而Env0则采用特定但一致的“aud”字符串。虽然统一的受众字段降低了条件的唯一性，但整体策略仍应同时包含“sub”及“aud”等多个维度的校验，以严密管控权限。 在实际操作中，企业还须警惕条件设置过宽或含糊，比如GitHub Actions中的“sub”可被配置为“StringLike”模式，允许同一组织内所有代码仓库和分支访问目标角色。
这种配置虽然方便管理，但却牺牲了一定的安全性。更严格的做法则是结合访问来源IP地址限制等多因素措施，如Bitbucket和Buildkite所推荐的做法。 进一步而言，市场上部分厂商通过客户特有的OIDC供应商URL或“aud”值实现访问控制，这些独特标识帮助限定只有特定客户的服务账户能访问对应AWS角色。此类客户专属配置降低了攻击者无凭无据获取权限的可能性，但仍不能放松对“sub”及其他条件关键字段的审查。企业务必深入厂商官方文档，并结合自身业务需求，制定差异化且细致的IAM信任策略。 AWS内置的四大身份提供商——包括Cognito、Amazon、Facebook及Google账号——同样设定了专用条件关键词，如“aud”及“amr”等，确保身份令牌的合法性和关联性。
对于使用Amazon EKS的企业，OIDC集成尤其常见，官方建议严格配置“aud”为“sts.amazonaws.com”以及合理限定“sub”字段，形成有效的访问边界。 虽然条件语句在理论上能够严格限定访问权限，但实施细节往往影响最终安全效果。不恰当的条件值或者模糊匹配策略都可能创造安全盲区。因此，企业应结合自动化安全检测工具，如AWS Access Analyzer所提供的OIDC策略检查功能，定期扫描IAM策略配置，排查缺失“aud”或“sub”等关键条件的角色，及时修复潜在风险。另外，使用专门的检测脚本和规则，可以针对不同厂商的OIDC集成特征，识别异常配置和访问活动，防止权限滥用。 AWS OIDC集成条件设置的安全性体现了云平台身份治理的复杂性和细节要求。
企业不能简单复制厂商示例策略，必须根据实际场景动态调整条件表达式，并辅以多层防御机制加固访问控制。掌握清晰明确的“aud”与“sub”条件，识别和应用厂商提供的额外条件要求，如“sts:RoleSessionName”或自定义标签，是构建安全稳定OIDC集成环境的核心要素。 综上所述，AWS在通过OIDC实现第三方授权时，条件配置失误极易埋下安全隐患。正确设置身份验证令牌中的受众和主题字段，针对不同厂商定制特定条件，为IAM角色配置完善的访问限制，结合网络层面的源IP白名单约束，共同打造多维度的安全防线。企业应保持对新出现的集成方案和漏洞及时关注，利用行业最佳实践持续完善权限配置体系，从根本上防止未经授权的访问风险，保障云上资产的安全稳定运行。
