将AWS IAM/AWS IAM身份中心引入公司组织/系统【的指南】注意事项

📅 发布日: 2023/08/07, 更新日: 2025/05/05 ⏱️ 预计阅读时间约11分钟 (4,464字)

AWS IAM Identity Center是一项服务，用于在多帐户环境中集中管理用户和应用程序的身份验证和授权。
相比之下， AWS IAM是一项服务，用于在单个AWS帐户中管理用户和应用程序的身份验证和授权。本文概述了AWS IAM/AWS IAM Identity Center ，并介绍了在考虑将其引入公司组织或系统时需要检查的要点。

修订历史
什么是 AWS IAM？
什么是 AWS IAM 身份中心？
采用注意事项
1. 1. 您的AWS账户的合同类型是什么？
设计考虑因素
相关文件

修订历史

日期	更新详情
2025/05/05	“设计注意事项”新增“③IAM权限设计策略定义”

什么是 AWS IAM？

AWS IAM（以下简称“IAM”）是一项用于管理对 AWS 资源的访问的服务。
使用 IAM，您可以创建用户、组和角色，并授予这些实体控制对 AWS 资源的访问的权限。
IAM 是使用 AWS 的一项重要服务。您可以创建用于操作AWS管理控制台的“IAM用户”和用于授予对AWS资源的访问权限的“IAM角色”。
但是，如果您按照如下所述使用 AWS IAM Identity Center，则无需创建 IAM 用户即可进行操作。
使用 IAM 用户时，您需要颁发凭证才能通过 AWS CLI 或开发工具包进行访问，但使用 AWS IAM Identity Center 则无需颁发凭证。
为 IAM 用户颁发凭证需要定期更新，从而增加了管理开销。如果凭据泄露，还存在滥用风险。
使用 AWS IAM Identity Center，您无需颁发凭证。您可以通过 AWS Access Portal 或在执行 AWS CLI 命令时获取临时凭证。

什么是 AWS IAM 身份中心？

AWS IAM Identity Center（以下简称“IIC”）是多账户 AWS 环境中的身份和访问管理服务。
提供AWS访问门户，用于统一管理对AWS资源的访问，提供访问每个AWS账户管理控制台的链接。
访问权限以称为“权限集”的单元进行管理，该单元定义对 AWS 账户的访问权限。
您还可以获取每个 AWS 账户的临时凭证，该凭证可用于通过 AWS CLI 或 SDK 操作 AWS 资源。
通过与外部身份提供商 (IdP) 集成，您可以使用现有凭据登录访问门户。自 2023 年 7 月 30 日起，支持以下 IdP：
Azure AD
赛博方舟
谷歌工作区
跳云
奥克塔
一次登录
Ping 身份

采用注意事项

1. 您的AWS账户的合同类型是什么？

如果您有多账户结构，建议使用IIC、Okta、Entra ID或其他可以管理多个账户访问的IDaaS。IIC 自动将 IAM 角色分配给每个 AWS 账户，与 IDaaS 相比减少了运营开销。
在管理帐户中启用 IIC。请务必检查您的 AWS 账户的合同类型以及管理账户功能是否可用。
有关合同类型的详细信息，请参阅指南：将 AWS Organizations 引入公司结构/系统的注意事项 |Moderniser.repo 。

设计考虑因素

1. 组织利益相关者

设计 IAM 时， 明确组织内利益相关者的角色非常重要。
参考标准化AWS使用指南的最佳实践|Amazon Web Services Blog ，我以自己的方式组织了定义。
CCoE、通用平台管理员、安全人员和会计/财务这四个角色可能由同一部门或人员处理，具体取决于组织。

不	角色	描述	职责
01	中央教育中心	促进和运营云采用中心	制定指导方针
02	通用平台管理	云端提供跨系统通用平台和功能	构建和运营通用平台
03	安全	维护云环境的安全	定义安全策略、构建和运行安全功能、安全监控和运营
04	系统管理员	构建并操作系统在云中运行的系统	AWS资源搭建与运营、系统建设与运营
05	运营	云环境下的运营管理	系统监控及运行
06	会计/金融	AWS使用成本的分配和优化	审查成本分配政策、考虑购买选项、成本监控、支付 AWS 使用费

2.角色分配组织（确定IAM权限委托的范围和方式）

决定应向系统管理员委派多少 IAM 管理权限，以及在执行委派时应采用哪些方法或限制。
IAM 中管理的元素有：“IAM 用户”、“IAM 组”、“IAM 角色”和“IAM 策略”。
虽然普通平台管理员可以管理一切，但随着系统的增长，管理成本会增加，因此可以考虑将IAM管理权限委托给用户。
一般来说，考虑使用SCP（服务控制策略）来禁止帐户级别的特定操作，作为委派给系统管理员的主要方法。
以下是六个典型用例。

使用案例 1：委派管理权限（IAM 用户/组除外）

要求项目	细节
使用 AWS Organizations (SCP) 或 IIC	✓ 可用
用户管理委托	✗ 无法委托给系统
角色委派/策略管理	✓ 可委托给系统

一种有效的内部欺诈对策是删除不必要的用户。
有权访问 AWS 账户的用户必须定期检查并删除不必要的用户。
为防止用户删除时的遗漏，用户管理应由公共平台管理员进行，而不是委托给系统管理员。
为防止 IAM 角色信任策略配置不当，请考虑使用访问分析器进行检测。

使用案例 2：使用权限边界委派管理权限（IAM 用户/组除外）

要求项目	细节
使用 AWS Organizations (SCP) 或 IIC	✗ 不可用
用户管理委托	✓ 可委托给系统
角色委派/策略管理	✓ 可委托给系统

如果管理账户功能不可用，您可以通过使用权限边界限制可授予 IAM 角色的权限来委派给系统管理员。

使用案例 3：创建系统专用堡垒账户并委派所有 IAM 管理权限

要求项目	细节
使用 AWS Organizations (SCP) 或 IIC	✓/✗ 可用/不可用
用户管理委托	✓ 可委托给系统
角色委派/策略管理	✓ 可委托给系统

将IAM用户管理权限委托给系统管理员时，您还可以创建由系统管理员集中管理的堡垒账户。

使用案例 4：委派除 IAM 组之外的 IAM 管理权限

要求项目	细节
使用 AWS Organizations (SCP) 或 IIC	✗ 不可用
用户管理委托	✓ 可委托给系统
角色委派/策略管理	✓ 可委托给系统

IAM组由公共平台管理员管理，系统管理员通过将IAM用户分配到IAM组来授予IAM用户权限。
由于IAM用户权限由公共平台管理员控制，防止系统管理员授予未经授权的权限。
这也减少了权限设计的工作量。

使用案例 5：不委派任何 IAM 管理权限

要求项目	细节
使用 AWS Organizations (SCP) 或 IIC	✓/✗ 可用/不可用
用户管理委托	✗ 无法委托给系统
角色委派/策略管理	✗ 无法委托给系统

通过让公共平台管理员保留所有 IAM 管理权限，您可以选择不委托给系统管理员。
由于必须根据系统管理员的请求创建IAM用户和角色，因此管理成本可能会增加。

3. 定义IAM权限设计策略

设计 IAM 权限的主要挑战之一是确定如何严格地应用最小权限原则。
作为最佳实践，建议仅向 IAM 用户和 IAM 角色授予必要的最低权限。
但是，限制IAM用户和角色的权限可能会增加系统管理员的操作负担。
因此， 提前评估与授予的IAM权限相关的业务风险并在可接受的风险范围内授予权限非常重要。
除了 IAM 权限控制之外，使用 AWS Organizations 的 SCP（服务控制策略）可以帮助减轻 IAM 权限设计的负担。
正确划分AWS账户也很重要。通过划分AWS账户，即使IAM权限被不当授予，影响也可以受到限制。
您可以使用三种类型的策略来授予 IAM 权限：
内联政策
AWS 托管策略
客户管理政策
其中，“AWS 托管策略”由 AWS 提供，并在 AWS 正确评估权限后提供。通过使用这些策略，您可以授予每个 AWS 服务的写入和读取权限。
基本上，建议使用AWS托管策略。但是，由于 AWS 托管策略可能会授予过多的权限，因此请考虑使用“客户托管策略”或“内联策略”来根据需要进一步限制权限。
例如，在以下模式中，考虑使用“客户管理策略”或“内联策略”来限制权限。

模式一：授予KMS密钥管理权限

要使用 AWS 托管策略授予 KMS 密钥的管理权限，您可以使用 AWS 托管策略“AWSKeyManagementServicePowerUser”。
参考： AWSKeyManagementServicePowerUser - AWS 托管策略
但是，使用此策略将为 KMS 密钥授予强大的权限，例如创建或删除密钥以及更改 IAM 策略。
因此， 考虑使用 IAM 策略仅授予特定 KMS 密钥的权限。
例如，以下 IAM 策略授予解密使用具有特定标签的 KMS 密钥加密的数据的权限：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                   "kms:Decrypt",
                   "kms:GenerateDataKey"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/System": "SystemA"
                }
            }
        }
    ]
}

模式2：授予SSM Automation / Lambda / Step Functions等执行权限

授予 AWS 资源（例如 Lambda 或 Step Functions）的执行权限时，您将授予执行这些资源时所行使的权限。
如果执行这些资源会带来业务风险，请考虑使用 IAM 策略限制执行权限。
例如，通过使用以下 IAM 策略，您可以授予执行遵循特定命名约定的 Lambda 函数的权限。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                   "lambda:InvokeFunction"
            ],
            "Resource": [
                "arn:aws:lambda:ap-northeast-1:123456789012:function:SystemA-*"
            ]
        }
    ]
}

模式 3：在外部账户中承担 IAM 角色

当您需要在外部账户中代入 IAM 角色时，您可以使用 IAM 策略授予 AssumeRole 权限。
无法使用 AWS 托管策略授予此权限，因此您必须使用自定义 IAM 策略来授予权限。
例如，以下 IAM 策略授予担任特定 IAM 角色的权限。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                   "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::123456789012:role/SystemA-*"
            ]
        }
    ]
}

模式 4：当数据管理员和用户不同时

使用 S3 或 DynamoDB 等数据存储时，数据管理员和用户可能不同。
例如，如果S3存储桶的管理员不同，您可以使用IAM策略向特定S3存储桶管理员授予权限。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                   "s3:PutObject",
                   "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::systema-bucket",
                "arn:aws:s3:::systema-bucket/*"
            ]
        }
    ]
}