25、AWS权限管理与账户结构优化

AWS权限管理与账户结构优化

1. 紧急管理角色与权限边界

1.1 紧急管理角色

“Emergency admin role” 能够访问资源A，但在正常情况下，公司内任何人都无法承担此角色。工程总监可以控制谁能承担 “Emergency admin role”，不过他们自己不能承担该角色。开发人员只有在工程总监允许后，才能承担该角色并访问资源。

1.2 权限边界

权限边界是管理员通过指定其他身份可获得的最大权限来分配权限的一种方式。与IAM策略不同，它不会向接收者授予任何新权限，而是规定接收者可拥有的最大权限。对IAM身份应用权限边界后，其有效权限始终是其IAM策略权限的子集。

例如，有一个团队仅需使用AWS Simple Storage Service (S3) 或AWS Lambda，可设置如下权限边界IAM策略条件：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "lambda:*"
            ],
            "Resource": "*"
        }
    ]
}

若创建一个带有此边界策略的用户 “Gaurav”，并附加一个允许创建用户的IAM策略：

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "iam:CreateUser",
        "Resource": "*"
    }
}

由于边界策略中不允许 “iam:CreateUser”，用户 “Gaurav” 仍无法创建新用户，其有效权限是边界策略和IAM策略所提供权限集合中的较小者。

1.3 使用权限边界委派职责

在小型组织中，管理团队和云资源相对简单，可能有云管理员负责执行组织的安全策略。但随着组织发展，集中式团队的扩展性会变差。此时可将一些云管理任务委派给团队内的领导者或开发人员，这可通过权限边界实现。

例如，团队X使用AWS Lambda，希望团队经理Bob能创建或删除团队用户，可创建权限边界PBX：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "BasicPermissions",
            "Effect": "Allow",
            "Action": [
                "iam:*",
                "lambda:*"
            ],
            "Resource": "*"
        }
    ]
}

然而，若有一个存储敏感信息的秘密数据库，团队X无需访问此数据。尽管团队X的所有用户都分配了权限边界PBX，但Bob可以创建没有此限制策略的新用户Alice，导致Alice能够访问秘密数据库。

为防止权限升级，可使用AWS建议的调整后的权限边界PBY。在PBY中添加额外条件，确保只能创建附加PBY的新用户：

{
    "Sid": "CreateOrChangeOnlyWithBoundary",
    "Effect": "Allow",
    "Action": [
        "iam:CreateUser",
        "iam:DeleteUserPolicy",
        "iam:AttachUserPolicy",
        "iam:DetachUserPolicy",
        "iam:PutUserPermissionsBoundary",
        "iam:PutUserPolicy"
    ],
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/PBY"
        }
    }
}

同时，还需添加策略防止团队成员更改或删除PBY：

{
    "Sid": "NoBoundaryPolicyEdit",
    "Effect": "Deny",
    "Action": [
        "iam:CreatePolicyVersion",
        "iam:DeletePolicy",
        "iam:DeletePolicyVersion",
        "iam:SetDefaultPolicyVersion",
        "iam:DeleteUserPermissionsBoundary"
    ],
    "Resource": [
        "*"
    ]
}

2. 大型组织的AWS账户结构

2.1 单账户与多账户结构对比

多数公司在云之旅初期会设置一个单一的AWS账户来配置所有云资源和基础设施。这种设置起初看似简单，只需考虑一个账户，便于应用最小权限原则 (PoLP)，终止员工时也无需在多个地方删除账户。

但将许多不相关的团队放在同一个账户中，会使云组织的扩展性变差，尤其是对于领域驱动的组织。在大型账户中应用PoLP变得困难，成本分离和审计也会出现问题，管理身份和资源的复杂性呈指数级增加。此外，还存在严重的安全隐患，如根用户、管理员或高级用户被攻破时，整个账户和基础设施都将面临风险，合规审计的复杂性也会大幅增加。

因此，AWS建议使用多账户结构，每个业务开发团队拥有自己的账户。将整个组织按业务领域分解为单个账户，能为微服务环境提供足够的自主性和隔离性。

2.2 AWS账户与团队

在AWS中，为每个团队提供单独的AWS账户可赋予其足够的自主性，确保身份、资源和安全策略的管理相互不干扰。AWS Organizations允许管理员将这些独立的账户分组，以进行监控、安全管理和合并计费，从而对高功能的自主团队进行治理和控制。

为团队分配单独账户的好处如下：
| 好处 | 说明 |
| ---- | ---- |
| 安全控制 | 每个账户可配置自己的安全策略，实现对团队的精细控制，有助于证明合规性。 |
| 攻击隔离 | 潜在风险和安全威胁可被限制在一个账户内，不影响其他账户。 |
| 自主性和敏捷性 | 多个账户可避免团队之间的相互干扰。 |
| 治理 | 管理员更容易管理和治理较小的资源集。 |
| 委派 | 可将上下文级账户的管理任务委派给不同团队。 |

2.3 AWS Organizations

AWS Organizations可帮助复杂企业在不影响控制和治理的情况下创建独立账户。公司通常有现有的组织结构，AWS Organizations可创建一个顶级伞形账户（管理账户），在组织内创建AWS账户的层次结构。

创建管理账户后，它可作为顶级实体，负责确保每个账户的访问、权利和特权。组织可决定每个账户的自主性，并在授予高功能团队自主性时遵循最小权限原则。

当在组织下创建新账户时，成员账户会自动创建 “OrganizationAccountAccessRole” 角色，顶级组织账户的管理员或超级用户可承担此角色并进行更改。若注册现有账户，则需手动创建该角色。

AWS Organizations还可帮助大型公司设置合并计费解决方案，顶级账户可为所有成员账户支付费用，会计人员可访问组织账户，而无需对公司内的各个部门或领域进行细粒度访问，从而保留最小权限。

2.4 组织单位和服务控制策略

2.4.1 组织单位 (OU)

每个AWS账户可属于一个组织单位 (OU)，OU是将组织内的实体分类到一个共同组的方式。管理员可将成员账户直接放在根目录下或某个OU下，OU可嵌套，有助于创建类似公司部门层次结构的树状OU层次结构，简化账户管理。

2.4.2 服务控制策略 (SCP)

服务控制策略 (SCP) 可用于控制组织内所有账户和OU的权限。SCP本身不足以授予账户权限，而是定义每个账户或OU可授予的权限限制。用户的有效权限是SCP允许的权限和IAM允许的权限的交集。

使用OU和SCP可创建一个层次结构，在每个层次上设计SCP以控制该层次账户的访问权限。

2.4.3 SCP控制示例

• 确保资源正确标记 ：AWS标签可方便对资源进行分类，有助于成本和预算管理。为确保每个资源都被正确标记，可使用以下SCP策略：

{
    "Sid": "DenyRunInstanceWithNoProjectTag",
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    "Resource": [
        "arn:aws:ec2:*:*:instance/*",
        "arn:aws:ec2:*:*:volume/*"
    ],
    "Condition": {
        "Null": {
            "aws:RequestTag/MarketingTeam": "true"
        }
    }
}

此策略确保在请求中不包含 “MarketingTeam” 标签时，无法在账户中运行实例。

3. SCP其他控制示例

除了确保资源正确标记，SCP 还有许多其他的控制用例，下面为大家详细介绍：

3.1 允许创建特定类型的资源

在某些场景下，我们可能只希望团队在 AWS 上创建特定类型的资源，这时可以通过 SCP 来实现。以下是一个示例策略，只允许创建 Amazon S3 存储桶和 Amazon EC2 实例：

{
    "Sid": "AllowSpecificResourceCreation",
    "Effect": "Allow",
    "Action": [
        "s3:CreateBucket",
        "ec2:RunInstances"
    ],
    "Resource": [
        "arn:aws:s3:::*",
        "arn:aws:ec2:*:*:instance/*"
    ]
}

3.2 禁止用户禁用 AWS CloudTrail 或 CloudWatch 日志记录和监控

AWS CloudTrail 和 CloudWatch 对于监控和审计账户活动至关重要，为了确保这些功能始终开启，可以使用以下 SCP 策略：

{
    "Sid": "PreventDisableLogging",
    "Effect": "Deny",
    "Action": [
        "cloudtrail:StopLogging",
        "cloudwatch:DeleteAlarms",
        "cloudwatch:DeleteDashboards"
    ],
    "Resource": "*"
}

3.3 防止用户使用 AWS Resource Access Manager (RAM) 外部共享资源

为了保护公司资源不被外部非法共享，可以使用以下 SCP 策略：

{
    "Sid": "PreventExternalSharing",
    "Effect": "Deny",
    "Action": [
        "ram:CreateResourceShare",
        "ram:AssociateResourceShare"
    ],
    "Resource": "*"
}

4. 总结与建议

4.1 总结

通过本文的介绍，我们了解了 AWS 权限管理和账户结构优化的重要性和相关技术。紧急管理角色和权限边界的设置可以有效控制用户的权限，避免权限滥用。对于大型组织，采用多账户结构和 AWS Organizations 可以实现更好的资源管理和安全控制，同时通过组织单位 (OU) 和服务控制策略 (SCP) 可以进一步细化权限管理。

4.2 建议

以下是一些实际操作中的建议：
- 逐步实施多账户结构 ：对于已经使用单账户的大型组织，不要急于一次性迁移到多账户结构，可以逐步将不同的业务团队迁移到独立的账户中，降低迁移风险。
- 定期审查权限策略 ：随着业务的发展和变化，定期审查和更新权限边界、SCP 等策略，确保权限的分配始终符合最小权限原则。
- 加强培训和教育 ：对团队成员进行 AWS 权限管理和安全控制的培训，提高他们的安全意识和操作技能。

4.3 未来展望

随着云计算技术的不断发展，AWS 可能会推出更多的权限管理和账户结构优化功能。我们可以期待更加智能化、自动化的权限管理工具，帮助企业更好地应对日益复杂的业务需求和安全挑战。

4.4 流程图总结

下面是一个 mermaid 格式的流程图，总结了 AWS 权限管理和账户结构优化的主要流程：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px

    A([开始]):::startend --> B(设置紧急管理角色和权限边界):::process
    B --> C{是否为大型组织}:::decision
    C -->|是| D(采用多账户结构):::process
    C -->|否| E(单账户管理):::process
    D --> F(使用 AWS Organizations):::process
    F --> G(创建组织单位和 SCP):::process
    G --> H(定期审查和更新策略):::process
    E --> H
    H --> I([结束]):::startend

通过以上的总结和建议，希望能够帮助大家更好地理解和应用 AWS 权限管理和账户结构优化的相关技术，在实际操作中提高资源管理效率和安全性。