策略评估逻辑
在您尝试使用华为云Console、API或CLI 时，它们将向华为云发送请求。在云服务收到请求时，会完成几个步骤来确定是允许还是拒绝该请求。
- 身份验证：首先对发出请求的主体进行身份验证（一些服务可能不需要此步骤，它们可能允许来自匿名身份的某些请求）。
- 处理请求上下文：处理请求中携带的信息用于后续的策略评估。
- 执行策略逻辑评估：IAM会按照顺序评估所有的策略类型，然后根据请求上下文来决定是允许还是拒绝请求。
例如：
- 当身份策略和资源策略一起使用时，如果IAM主体是访问同账号内资源，只需要身份策略或资源策略任意一种允许访问即可；如果IAM主体是访问跨账号的资源，则需要身份策略和资源策略同时允许访问才行。
- 当用户所属的账号是某个组织的成员，并且访问一个未配置资源策略的资源时，最终的权限是身份策略和服务控制策略 (SCP) 的交集。这意味着一个操作必须被这两种策略同时允许，才最终被允许；如果身份策略或SCP中的任意一个策略显示拒绝，则最终被拒绝。更多策略的联合使用评估逻辑请参见IAM策略评估逻辑。
任何一种策略的显式拒绝均将覆盖其他类型策略的允许操作。
请求上下文
- 请求上下文的重要性
理解请求上下文及其与策略评估的交互方式对于以下方面至关重要：
- 排查访问问题。
- 设计有效且安全的策略。
- 了解策略授予的权限的全部范围。
- 预测不同场景下的策略评估结果。
- IAM如何使用请求上下文
华为云会将策略评估过程中所需的必要信息收集到请求上下文中，然后IAM根据请求上下文对策略进行评估。请求上下文一般包含：
- 主体（Principal）：发送请求的人员（IAM用户、信任委托或应用程序等）。
- 授权项（Action）：主体想要执行的操作对应的授权项。
- 资源（Resource）：主体想要执行的操作所关联的华为云资源。
- 环境数据（Environment Data）：请求中有关IP、时间、用户代理等信息。
- 资源数据（Resource Data）：与华为云资源相关的数据，例如IAM用户和信任委托上的标签。
最后，IAM将这些信息与请求主体所关联的策略进行比较，来确定是允许还是拒绝该请求。
IAM如何评估策略取决与请求主体所关联的策略类型。有关策略类型的更多信息，请参见IAM支持的访问控制策略。多种策略联合使用时的评估逻辑请参见IAM策略评估逻辑。
身份策略评估示例
接下来以身份策略的权限控制为例，说明如何使用请求上下文进行策略评估。
{
"Version": "5.0",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:agencies:getV5"
],
"Resource": [
"iam:*:8c1eef3a241945f69c3d3a6b0252e783:agency:test"
],
"Condition": {
"StringEquals": {
"g:PrincipalTag/dept": [
"123"
]
}
}
}
]
}
|
请求上下文 |
结果 |
|---|---|
Principal: 973189f65882479fb8a3b8d8672c15e2 Action: iam:agencies:getV5 Resource: iam:*:8c1eef3a241945f69c3d3a6b0252e783:agency:test Context: - g:PrincipalTag/dept=123 |
匹配 |
Principal: 973189f65882479fb8a3b8d8672c15e2 Action: iam:mfa:listMFADevicesV5 Resource: iam:*:8c1eef3a241945f69c3d3a6b0252e783:agency:test Context: - g:PrincipalTag/dept=123
说明：
请求中Action为iam:mfa:listMFADevicesV5，不匹配。 |
不匹配 |
Principal: 973189f65882479fb8a3b8d8672c15e2 Action: iam:agencies:getV5 Resource: iam:*:8c1eef3a241945f69c3d3a6b0252e783:agency:test Context: - g:PrincipalTag/dept=321
说明：
请求中g:PrincipalTag/dept=321，不匹配。 |
不匹配 |
Principal: 973189f65882479fb8a3b8d8672c15e2 Action: iam:agencies:getV5 Resource: iam:*:8c1eef3a241945f69c3d3a6b0252e783:agency:test Context:
说明：
请求中没有g:PrincipalTag/dept，不匹配。 |
不匹配 |
IAM 策略评估逻辑
- IAM 策略评估逻辑
我们将IAM策略评估逻辑的整体描述分为“账号内授权”和“跨账号授权”两大类。IAM将依据此次鉴权请求上下文，检查其强制访问控制策略与自主访问控制策略：若鉴权请求上下文未匹配上允许（Allow）的强制访问策略，则此次鉴权结果为拒绝（Deny），检查强制访问控制策略后，需再检查此次请求的主体是否经过自主访问控制策略授权。有关强制访问控制策略和自主访问控制策略的介绍，请参见 IAM支持的访问控制策略。
- 账号内策略评估
以下流程图详细介绍了账号内授权场景的策略评估逻辑。图1 账号内授权场景的策略评估逻辑
账号内策略评估示例：
策略的最常见类型是身份策略和资源策略。当主体请求访问账号内资源时，要求这两种策略至少有一种授予了该主体允许访问的权限。注意，这两种策略的任意一种策略的显示拒绝将覆盖其他策略的允许。
如果同一账号内身份策略或资源策略其中一个允许该请求，而另一个没有允许(也没有显示拒绝)，仍然会允许该请求。注意：信任策略除外，使用信任委托时需要信任策略和身份策略同时允许时，才最终允许切换该信任委托。
例如，可以将以下身份策略附加到用户名为colorsone的IAM用户身上，以允许他获取OBS服务的一些列表权限。{ "Version": "5.0", "Statement": [ { "Effect": "Allow", "Action": [ "obs:bucket:listAllMyBuckets", "obs:bucket:listBucket", "obs:bucket:listBucketMultipartUploads", "obs:bucket:listBucketVersions", "obs:object:listMultipartUploadParts" ], "Resource": [ "obs:*:*:bucket:*" ], "Condition": { "StringEquals": { "g:UserName": [ "colorsone" ] } } } ] }假设colorsone用户的ID为aaaaaae41869426db2e2d87b7d1db00b，所属账号的账号ID为66871fe214924948a794aaaaaaaaaaaa。您还可以将以下资源策略（称为桶策略）附加到存储桶my-bucket上来达到类似效果，此策略指定了colorsone用户可以访问my-bucket存储桶，拥有该资源所有的列表和查询详情的权限。{ "Statement": [ { "Sid": "listobs", "Effect": "Allow", "Principal": { "ID": [ "domain/66871fe214924948a794aaaaaaaaaaaa:user/aaaaaae41869426db2e2d87b7d1db00b" ] }, "Action": [ "Get*", "List*" ], "Resource": [ "my-bucket" ] } ] } - 跨账号策略评估
您可以允许一个账号中的主体访问另一个账号中的资源，这称为跨账号访问。要允许跨账号授权，请将资源策略附加到您想共享的资源，资源策略中指定了有权限访问该资源的主体。此外，您还必须给想要共享账号中的主体附加身份策略，身份策略中指定了该主体有权访问什么资源。只有资源策略和身份策略同都允许访问时，该主体才有权限访问，同时其他类型的策略也可能会影响跨账号访问的策略评估，例如Organizations服务的SCP策略、RAM服务的资源共享策略等。
以下流程图详细介绍了跨账号授权场景的策略评估逻辑。图2 跨账号授权场景的策略评估逻辑
跨账号策略评估示例
以下示例演示了一个账号AccountB（账号ID 为 888888888888434680659e1bec79e6e5）向另一个账号AccountA（账号ID为777777777777434680659e1bec79e6e5）中的 IAM 用户授予权限访问其资源的情况。
例如，用户A是一名开发人员，在账号AccountA 中拥有用户ID 为 11111111111e4cdba0df0735a4bf01ed 的 IAM用户。 他想访问账号AccountB 中桶名为 test-d177的资源。假定用户A被附加了以下身份策略，在该身份策略中授予了用户A拥有OBS服务所有操作的权限。{ "Version": "5.0", "Statement": [ { "Effect": "Allow", "Action": [ "OBS:*:*" ] } ] }此外，以下资源策略（称为桶策略）还需要附加到账号AccountB 中的test-d177存储桶。此策略授权用户A拥有对 test-d177 桶所有的列表和查询详情权限，用户A可以查询存储桶中的资源，但是不能执行删除和修改操作。{ "Statement": [ { "Sid": "listobs", "Effect": "Allow", "Principal": { "ID": [ "domain/777777777777434680659e1bec79e6e5:user/11111111111e4cdba0df0735a4bf01ed" ] }, "Action": [ "Get*", "List*" ], "Resource": [ "test-d177", "test-d177/*" ] } ] }有关跨账号资源访问的更多示例，请参见跨账号资源访问。
- 显示拒绝和隐式拒绝
如果策略包含Deny语句，则会导致请求被显示拒绝。如果应用于请求的策略包含一个Allow语句和一个Deny语句，Deny语句优先于Allow语句，将显示拒绝该请求。
当没有的Deny语句也没有Allow语句时，会发生隐式拒绝，因此必须明确允许主体请求的操作。在创建策略时，您必须创建包含Allow语句的策略才能允许该主体成功发出请求。
您可以选择显示拒绝和隐式拒绝的任意组合。例如，您可以创建以下身份策略，其中包括显示允许的操作、隐式拒绝的操作和显示拒绝的操作。该身份策略第一个statement允许所有与iam:users:*相关的操作，但没有明确允许其他操作，例如iam:agencies:*相关的操作会被隐式拒绝；而在第二和第三个statement中，对iam:groups:*相关的操作既有Deny又有Allow，那么对 iam:groups:*相关的所有操作都会被第二个statement显示拒绝，即使第三个statement 显示授予了iam:groups:*的允许的权限。{ "Version": "5.0", "Statement": [ { "Sid": "statementOne", "Effect": "Allow", "Action": [ "iam:users:*" ], "Resource": [ "*" ] }, { "Sid": "statementTwo", "Effect": "Deny", "Action": [ "iam:groups:*" ], "Resource": [ "*" ] }, { "Sid": "statementThree", "Effect": "Allow", "Action": [ "iam:groups:*" ], "Resource": [ "*" ] } ] }
- 账号内策略评估
