AWS Organizations服务控制策略现已全面支持IAM语言
Amazon Web Services（AWS）近期宣布，AWS Organizations现在为服务控制策略（SCPs）提供完整的AWS身份和访问管理（IAM）策略语言支持。通过此功能，您可以在Allow语句中使用条件、单个资源Amazon资源名称（ARN）和NotAction元素。此外，您现在可以在Action元素字符串的开头或中间使用通配符，并在SCPs的Allow和Deny语句中实现NotResource元素。此功能现已在AWS商业区和AWS GovCloud（美国）区域全面可用。
在本文中，我们将介绍一系列新支持的SCP语言功能，这些功能简化了权限管理场景。这些增强功能实现了更直观、更简洁的策略设计。我们将探讨这些功能如何解决过去的限制，以减少操作开销并提高策略可读性。我们还将展示之前的实现方式，并提供示例说明新功能如何使意图更清晰、实现更简单。
新支持的元素概述
下表列出了支持的SCP语言元素及其用途和适用效果。粗体显示的元素和效果表示新支持的功能。
| 元素 | 用途 | 支持的效果 |
|---|---|---|
| Version | 指定用于处理策略的语言语法规则。 | Allow, Deny |
| Statement | 作为策略元素的容器。一个SCP中可以包含多个语句。 | Allow, Deny |
| Statement ID (Sid) | （可选）为语句提供友好名称。 | Allow, Deny |
| Effect | 定义SCP语句是允许还是拒绝对账户中IAM用户和角色的访问。 | Allow, Deny |
| Action | 指定SCP允许或拒绝的AWS服务和操作。 | Allow, Deny |
| NotAction | 指定不受SCP约束的AWS服务和操作。用于替代Action元素。 | Allow, Deny |
| Resource | 指定SCP适用的AWS资源。 | Allow, Deny |
| NotResource | 指定不受SCP约束的AWS资源。用于替代Resource元素。 | Allow, Deny |
| Condition | 指定语句生效的条件。 | Allow, Deny |
此外，您现在可以在Action或NotAction元素中的任意位置使用通配符*和?。以前，这些通配符只能单独使用或出现在元素末尾。例如，以下所有形式现在均有效：
"servicename:action*""servicename:*action""servicename:some*action""servicename:*"
探索新的SCP语言功能
让我们通过一些示例来探讨推荐的策略策略和最佳实践。
将Deny与NotResource结合使用
您可以使用NotResource元素将策略应用于除显式列出资源之外的所有资源。这对于实施具有范围例外的广泛默认拒绝策略特别有用，可以简化策略结构同时强制执行强边界。
示例1：
此示例的目标是强制执行资源边界，阻止访问组织外部的资源，但一组定义的服务自有资源除外。
之前的实现： 策略使用基于标签的方法来管理例外。它要求使用dp:exclude:resource:s3=true标记IAM主体，以授予对外部资源的访问权限。这给标签管理带来了操作开销，并且如果标签应用不正确，可能会引入安全风险。
改进的实现： 支持Deny语句中的NotResource后，更新后的SCP使用单个合并的Deny语句来拒绝操作，但一组定义的AWS自有资源除外。
| 支持NotResource之前的策略结构 | 支持NotResource之后的策略结构 |
|---|---|
json { "Version": "2012-10-17", "Statement": [ { "Sid": "EnforceResourcePerimeterAWSResourcesS3", "Effect": "Deny", "Action": "s3:GetObject", "Resource": "*", "Condition": { "StringNotEqualsIfExists": { "aws:ResourceOrgID": "<my-org-id>", "aws:PrincipalTag/dp:exclude:resource:s3": "true" } } } ] } |
json { "Version": "2012-10-17", "Statement": [ { "Sid": "EnforceResourcePerimeterAWSResources", "Effect": "Deny", "Action": "s3:GetObject", "NotResource": [ "arn:aws:s3:::service-owned-bucket/*", "arn:aws:s3:::service-owned-bucket2/*" ], "Condition": { "StringNotEquals": { "aws:ResourceOrgID": "<org-id>" } } } ] } |
示例2：
此示例拒绝访问Amazon Bedrock模型，但一个特定模型除外。
在此更改之前： SCP默认允许访问Amazon Bedrock操作，同时明确拒绝调用三个特定模型（例如：Deepseek、Anthropic和meta），从而为组织内的AWS账户提供了广泛的权限基线。然而，这种方法需要持续的操作开销，以确保策略更新以拒绝访问新添加的模型，从而避免暴露于可能不需要的模型。
改进的实现： 支持Deny语句中的NotResource后，更新后的SCP使用单个合并的Deny语句来拒绝操作，但Amazon模型除外。
| 支持NotResource之前的策略结构 | 支持NotResource之后的策略结构 |
|---|---|
json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "bedrock:*", "Resource": "*" }, { "Effect": "Deny", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream", "bedrock:PutFoundationModelEntitlement" ], "Resource": [ "arn:aws:bedrock:*::foundation-model/deepseek.*", "arn:aws:bedrock:*::foundation-model/anthropic.*", "arn:aws:bedrock:*::foundation-model/meta.*" ] } ] } |
json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "bedrock:*", "Resource": "*" }, { "Sid": "Statement1", "Effect": "Deny", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream", "bedrock:PutFoundationModelEntitlement" ], "NotResource": [ "arn:aws:bedrock:*::foundation-model/amazon.*" ] } ] } |
将Allow与条件结合使用
通过使用Condition元素，您可以指定策略语句生效的环境。虽然此元素是可选的，但它现在在SCPs中的Allow语句中得到支持，从而实现更精确和可扩展的访问控制。
注意： 在大多数情况下，我们建议在编写SCP时使用显式Deny语句。使用Deny语句有助于确保每个控制独立工作并保持可执行性。仅依赖allow语句和隐式的默认拒绝模型可能导致意外访问，因为更广泛或重叠的Allow语句可能会覆盖限制性更强的语句。
以下示例允许在特定AWS区域访问特定的AWS服务。
在此更改之前： 策略在Sid: AllowSpecificServices下使用单个Allow语句。它在Action元素中列出广泛的服务级别操作（例如，“ec2:"、“s3:“等），并将其应用于所有资源（“Resource”: “*"）。由于AWS SCP在默认拒绝模型下运行，此设置有效地允许所列服务的操作，同时隐式拒绝对未包含的其他服务的访问。例如，使用Region条件的显式Deny限制了在us-east-1、us-west-2和eu-central-1之外的操作。
改进的实现： 在更新后的示例中，策略允许相同的服务，但仅当它们在特定区域（例如，“us-east-1”、“us-west-2"和"eu-central-1”）中被请求时。这是通过Allow语句中使用aws:RequestedRegion条件键实现的。此增强功能允许组织保留基本的Allow逻辑，同时引入上下文边界（例如，按区域、账户或资源标签限制访问）——这在以前只能通过Deny条件实现。
注意： 我们建议在策略中使用一个广泛的Allow语句和多个有针对性的Deny语句。避免编写可能重叠的额外Allow语句，因为这样做可能导致意外访问。推荐的方法是首先使用一个广泛的Allow语句，然后根据需要使Deny语句来细化和限制访问。
| 支持Allow与条件之前的策略结构 | 支持Allow与条件之后的策略结构 |
|---|---|
json { "Version":"2012-10-17", "Statement":[ { "Sid":"AllowSpecificServices", "Effect":"Allow", "Action":[ "ec2:*", "s3:*", "rds:*", "lambda:*", "cloudformation:*", "iam:*", "cloudwatch:*" ], "Resource":"*" }, { "Sid":"AllowAccessOnlyTo3Regions", "Effect":"Deny", "Action":"*", "Resource":"*", "Condition":{ "StringNotEquals":{ "aws:RequestedRegion":[ "us-east-1", "us-west-2", "eu-central-1" ] } } } ] } |
json { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowServicesBasedOnRegion", "Effect": "Allow", "Action": [ "ec2:*", "s3:*", "rds:*", "lambda:*", "cloudformation:*", "iam:*", "cloudwatch:*" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestedRegion": [ "us-east-1", "us-west-2", "eu-central-1" ] } } } ] } |
其他新支持的元素
为了使SCPs完全支持IAM策略语言，现在支持其他元素。虽然这些结构在技术上是有效的，但由于如果管理不当可能产生意外访问，其中一些结构在实践中需要额外的考虑和测试。
| 新支持的功能 | 重要注意事项 |
|---|---|
| 带通配符（*, ?）的Action | 有助于缩短策略，但请谨慎使用——AWS添加的新操作将按设计匹配现有的通配符模式，可能授予意外权限。 |
| 带通配符（*, ?）的NotAction | 如果您想拒绝除列出操作之外的所有操作，我们建议将NotAction与Deny语句一起使用，这有助于使您的控制面向未来（例如，拒绝Amazon EC2中的所有操作，但不拒绝与”vpn“不匹配的操作）。 |
| Allow与NotResource | 用例有限。虽然受支持，但Allow与NotResource可能默认包含所有资源——可能允许访问后来添加的新资源。请谨慎使用，并尽可能首选显式Deny语句。 |
| Allow与NotAction | 用例有限。虽然受支持，但Allow与NotAction可能无意中允许访问AWS添加的新操作。请谨慎使用，并随着服务的发展首选显式Deny语句以保持控制。 |
| Allow与除通配符”*“之外的Resource。 | 当使用Allow与特定资源（非”*"）时，请确保您的策略设计避免冲突或重叠的Allow语句。首先使用广泛的Allow，然后使用有针对性的Deny语句来限制访问——这有助于防止因重叠的Allow语句而产生意外访问。 |
使用IAM Access Analyzer验证您的策略
您可以使用AWS IAM Access Analyzer在应用SCPs之前验证它们，使用策略验证和自定义策略检查两种方式。
IAM Access Analyzer根据IAM策略语法和最佳实践验证您的策略。您可以查看策略验证检查结果，其中包括安全警告、错误、一般警告和建议。这些结果提供了可操作的建议，帮助您编写既功能正常又符合安全最佳实践的策略。
自定义策略检查是IAM Access Analyzer的一项功能，安全团队可以使用它来帮助准确、主动地识别其策略中的关键权限。自定义策略检查可以确定策略的新版本是否比旧版本更宽松。它们使用自动推理（一种静态分析形式）来在云中提供更高级别的安全保证。
自定义策略检查可以嵌入到持续集成和持续交付（CI/CD）管道中，从而可以在不部署策略的情况下检查策略。开发人员还可以从其本地开发环境运行自定义策略检查，并快速获得关于他们正在编写的策略是否符合组织安全标准的反馈。有关更多信息，请参阅介绍IAM Access Analyzer自定义策略检查。
结论
AWS服务控制策略的最新增强功能提高了策略的表达能力和精确性，同时减少了操作工作量。通过启用诸如带条件的Allow和特定资源ARN、支持Deny语句中的NotResource以及扩展通配符灵活性等结构，您可以简化策略，并避免使用分层或复杂的策略来实现目标。这些更新使SCPs与IAM策略功能保持一致，并使组织能够实施更清晰、更直观的访问控制。作为最佳实践，重要的是要谨慎使用这些功能——特别是通配符的使用——以避免随着AWS服务的发展而产生意外权限。我们还鼓励将实施显式Deny语句作为最佳实践，并在需要时使用Allow语句。
如果您对本文有反馈，请在下面的评论部分提交评论。如果您对本文有疑问，请联系AWS支持。