新增功能 – AWS Single Sign-On 支持基于属性的访问控制

从今天开始，当员工使用 AWS Single Sign-On 登录到云时，您可以在 AWS 会话中传递用户属性。这让您不仅能够利用 AWS Single Sign-On 和 ABAC 的集中账户访问管理功能，而且还可以灵活地将 AWS SSO、Active Directory 或外部身份提供商作为您的身份来源使用。要了解更多有关在 AWS 上使用 ABAC 策略的优势的信息，请参阅我之前有关此主题的博客文章。

概览
一方面，系统管理员可以在 AWS Single Sign-On 身份存储库或托管的 Active Directory 上配置用户属性。此外，系统管理员还可以配置 Okta、OneLogin 或 PingIdentity 等外部身份提供商，以在其员工通过联合身份登录 AWS 时在 AWS 会话中传递现有的用户属性。这些属性在 AWS 中称为会话标签。另一方面，云管理员可以创建精细的权限策略，以确保您的员工只能访问具有匹配的资源标签的云资源。

创建基于属性匹配的策略，而不采用基于功能角色的策略，可帮助减少您必须在 AWS 环境中创建和管理的不同权限和角色的数量。例如，当红队的开发人员 Bob 与蓝队的开发人员 Alice 登录 AWS 并代入相同的 AWS Identity and Access Management (IAM) 角色时，他们将获得不同的权限，只能访问为其团队标记的项目资源。Bob 和 Alice 登录 AWS 时，身份系统会在 AWS 会话中发送其团队名称属性。角色的权限将允许访问具有匹配的团队名称标签的项目资源。现在，如果 Bob 调入蓝队并且系统管理员在身份提供商目录中为其更新了团队名称，Bob 将自动获得对蓝团队项目资源的访问权限，而无需在 IAM 中更新权限。

如何配置 AWS SSO 以映射用户属性
在配置 AWS SSO 之前，需要注意两点。首先，ABAC 支持来自在 AWS SSO 中配置的任何身份源的属性：AWS SSO 本身、托管的 Active Directory 或外部身份提供商。其次，有两种方法可以将用于访问控制的属性传递到 AWS SSO。您可以使用前缀 https://aws.amazon.com/SAML/Attributes/AccessControl 直接在 SAML 断言中传递属性，也可以使用 AWS SSO 身份存储中的属性。这些属性可由 AWS SSO 管理员为在 AWS SSO 中创建的用户配置、或从某个 Active Directory 同步而来或使用自动预置(SCIM)功能从某个外部身份提供商同步而来。

对于本演示，我选择使用外部身份提供商和 SCIM。

我可以通过三个步骤使用 AWS SSO 在 AWS 中启用 ABAC：

第 1 步：我使用外部身份提供商中关联的用户身份和属性配置了我的身份源。截至今天，AWS SSO 支持通过 SCIM 与 Azure AD、Okta、OneLogin 和 PingIdentity 进行身份同步。请关注此页面以获取最新列表。具体情况取决于具体的身份提供商。

第 2 步：我在 AWS SSO 控制台或 API 中使用新的“访问控制属性”全局设置来配置我要用于访问控制的 SCIM 属性。在此屏幕中，我可以选择来自我在第 1 步中配置的身份源的访问控制属性。

第 3 步：我使用我在第 2 步中配置的属性，通过权限集和基于资源的策略编写了 ABAC 规则。稍后我将更详细介绍此步骤。

然后，当员工使用 SSO 以联合身份登录某个 AWS 账户时，员工将能够访问具有匹配的属性的 AWS 资源。

属性将作为会话标签，将以逗号分隔的 key:value 对方式传递。所有属性的字符长度总和必须小于等于 460 个字符。

策略会是什么样子？
我现在可以在创建访问控制规则时使用 aws:PrincipalTag 条件键在权限集中使用用户属性。例如，我可以使用相应的部门名称来标记我组织中的所有资源，然后使用单个权限集以仅向开发人员授予对其部门资源的访问权限。此后，每当开发人员以联合身份到 AWS 账户时，AWS SSO 都会使用从身份提供商收到的值创建一个 department 会话标签。安全策略将仅允许开发人员访问各自部门的资源。随着团队为其项目增加更多的开发人员和资源，我只需使用正确的部门名称来标记资源即可。因此，在组织为部门增加新资源和开发人员时，开发人员依然只能管理与其部门对应的资源，而无需任何权限更新。

ABAC SSO 权限集策略的可能示例如下：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [ "ec2:DescribeInstances"],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": ["ec2:StartInstances","ec2:StopInstances"],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "ec2:ResourceTag/Department": "${aws:PrincipalTag/Department}"
                }
            }
        }
    ]
}

此策略允许任何人 DescribeInstances，但仅 aws:PrincipalTag/Department 标签的值与 EC2 实例 ec2:ResourceTag/Department 标签的值匹配的用户才有权停止或启动实例。

我将此策略附加到一个 AWS 账户的权限集中。在 AWS Single Sign-On 控制台的左侧，单击 AWS Accounts（AWS 账户），然后选择 Permission sets（权限集）选项卡。然后我单击 Create permission set（创建权限集）。在下一个屏幕上，我选择 Create a customer permission set（创建自定义权限集）。

我输入一个名称和描述，并检查确保我选择了 Create a custom permissions policy（创建自定义权限策略）。然后，我可以复制/粘贴之前的策略，以允许在部门名称标签值与该人的部门名称标签值相等时启动和停止 EC2 实例。

在下一个屏幕上，我输入一些标签，然后再检查我的配置，最后单击 Create（创建）。瞧，我准备好了。

如果您已使用 AWS Security Token Service 配置了现有的联合身份，请记住，外部身份提供商会将 AWS SSO 视为一个新的应用程序配置。这意味着当您从直接 IAM 联合身份迁移到 AWS SSO 时，您必须更新外部身份提供商配置才能使用 AWS SSO 连接并将此配置的会话标签作为属性引入。

现已推出
使用 AWS Single Sign-On 配置用户属性无需额外付费。您可以立即在所有提供 AWS SSO 的 AWS 区域开始使用此功能。

— seb

亚马逊AWS官方博客

新增功能 – AWS Single Sign-On 支持基于属性的访问控制