解锁新可能：AWS Organizations服务控制策略现已全面支持IAM语言
Amazon Web Service（AWS）最近宣布，AWS Organizations现在为服务控制策略（SCPs）提供了完整的AWS身份和访问管理（IAM）策略语言支持。通过此功能，您可以在Allow语句中使用条件、单个资源Amazon资源名称（ARN）和NotAction元素。此外，您现在可以在Action元素字符串的开头或中间使用通配符，并在SCPs的Allow和Deny语句中实现NotResource元素。此功能现已在AWS商业区和AWS GovCloud（US）区域全面可用。
在这篇博客文章中，我们将介绍一组新支持的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<br/>{<br/> "Version": "2012-10-17",<br/> "Statement": [<br/> {<br/> "Sid": "EnforceResourcePerimeterAWSResourcesS3",<br/> "Effect": "Deny",<br/> "Action": "s3:GetObject",<br/> "Resource": "*",<br/> "Condition": {<br/> "StringNotEqualsIfExists": {<br/> "aws:ResourceOrgID": "<my-org-id>",<br/> "aws:PrincipalTag/dp:exclude:resource:s3": "true"<br/> }<br/> }<br/> }<br/> ]<br/>}<br/> |
json<br/>{<br/> "Version": "2012-10-17",<br/> "Statement": [<br/> {<br/> "Sid": "EnforceResourcePerimeterAWSResources",<br/> "Effect": "Deny",<br/> "Action": "s3:GetObject",<br/> "NotResource": [<br/> "arn:aws:s3:::service-owned-bucket/*",<br/> "arn:aws:s3:::service-owned-bucket2/*"<br/> ],<br/> "Condition": {<br/> "StringNotEquals": {<br/> "aws:ResourceOrgID": "<org-id>"<br/> } <br/> }<br/> }<br/> ]<br/>}<br/> |
示例2：
此示例拒绝访问Amazon Bedrock模型，除了一个特定模型。
- 在此更改之前：SCP依赖于组织内AWS账户的广泛权限基线，默认允许访问Amazon Bedrock操作，同时明确拒绝调用三个特定模型（例如：Deepseek、Anthropic和meta）。然而，这种方法需要持续的操作开销，以确保策略更新以拒绝访问新添加的模型，避免暴露于可能不需要的模型。
- 改进的实现：支持Deny语句中的NotResource后，更新的SCP使用单个合并的Deny语句，拒绝除Amazon模型之外的操作。
| 不支持NotResource时的策略结构 | 支持NotResource后的策略结构 |
|---|---|
json<br/>{<br/> "Version": "2012-10-17",<br/> "Statement": [<br/> {<br/> "Effect": "Allow",<br/> "Action": "bedrock:*",<br/> "Resource": "*"<br/> },<br/> {<br/> "Effect": "Deny",<br/> "Action": [<br/> "bedrock:InvokeModel",<br/> "bedrock:InvokeModelWithResponseStream",<br/> "bedrock:PutFoundationModelEntitlement"<br/> ],<br/> "Resource": [<br/> "arn:aws:bedrock:*::foundation-model/deepseek.*",<br/> "arn:aws:bedrock:*::foundation-model/anthropic.*",<br/> "arn:aws:bedrock:*::foundation-model/meta.*"<br/> ]<br/> }<br/> ]<br/>}<br/> |
json<br/>{<br/> "Version": "2012-10-17",<br/> "Statement": [<br/> {<br/> "Effect": "Allow",<br/> "Action": "bedrock:*",<br/> "Resource": "*"<br/> },<br/> {<br/> "Sid": "Statement1",<br/> "Effect": "Deny",<br/> "Action": [<br/> "bedrock:InvokeModel",<br/> "bedrock:InvokeModelWithResponseStream",<br/> "bedrock:PutFoundationModelEntitlement"<br/> ],<br/> "NotResource": [<br/> "arn:aws:bedrock:*::foundation-model/amazon.*"<br/> ]<br/> }<br/> ]<br/>}<br/> |
使用带条件的Allow
通过使用Condition元素，您可以指定策略语句生效的情况。虽然此元素是可选的，但现在在SCPs中的Allow语句中受支持，实现了更精确和可扩展的访问控制。
注意：在大多数情况下，我们建议在编写SCPs时使用显式Deny语句。使用Deny语句有助于确保每个控制独立工作并保持可执行性。仅依赖allow语句和隐式的默认拒绝模型可能导致意外访问，因为更广泛或重叠的Allow语句可能覆盖更严格的语句。
以下示例允许在特定AWS区域中访问特定AWS服务。
- 在此更改之前：策略在Sid: AllowSpecificServices下使用单个Allow语句。它在Action元素中列出了广泛的服务级别操作（例如，“ec2:"、“s3:“等），并将它们应用于所有资源（“Resource”: “*"）。由于AWS SCPs在默认拒绝模型下运行，此设置有效地允许列出的服务中的操作，同时隐式拒绝未包含的其他服务的访问。例如，显式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<br/>{<br/> "Version":"2012-10-17",<br/> "Statement":[<br/> {<br/> "Sid":"AllowSpecificServices",<br/> "Effect":"Allow",<br/> "Action":[<br/> "ec2:*",<br/> "s3:*",<br/> "rds:*",<br/> "lambda:*",<br/> "cloudformation:*",<br/> "iam:*",<br/> "cloudwatch:*"<br/> ],<br/> "Resource":"*"<br/> },<br/> {<br/> "Sid":"AllowAccessOnlyTo3Regions",<br/> "Effect":"Deny",<br/> "Action":"*",<br/> "Resource":"*",<br/> "Condition":{<br/> "StringNotEquals":{<br/> "aws:RequestedRegion":[<br/> "us-east-1",<br/> "us-west-2",<br/> "eu-central-1"<br/> ]<br/> }<br/> }<br/> }<br/> ]<br/>}<br/> |
json<br/>{<br/> "Version": "2012-10-17",<br/> "Statement": [<br/> {<br/> "Sid": "AllowServicesBasedOnRegion",<br/> "Effect": "Allow",<br/> "Action": [<br/> "ec2:*",<br/> "s3:*",<br/> "rds:*",<br/> "lambda:*",<br/> "cloudformation:*",<br/> "iam:*",<br/> "cloudwatch:*"<br/> ],<br/> "Resource": "*",<br/> "Condition": {<br/> "StringEquals": {<br/> "aws:RequestedRegion": [<br/> "us-east-1",<br/> "us-west-2",<br/> "eu-central-1"<br/> ]<br/> }<br/> }<br/> }<br/> ]<br/>}<br/> |
其他新支持的元素
为了使SCPs完全支持IAM策略语言，现在支持其他元素。虽然技术上有效，但其中一些结构在实践中需要额外的考虑和测试，因为如果管理不当，它们可能导致意外访问。
| 新支持的功能 | 重要考虑事项 |
|---|---|
| 带通配符(*, ?)的Action | 可以帮助缩短策略，但需谨慎使用——AWS添加的新操作将按设计匹配现有的通配符模式，可能授予意外权限。 |
| 带通配符(*, ?)的NotAction | 我们建议将NotAction与Deny语句一起使用，如果您想拒绝除列出的操作之外的所有操作，这有助于使您的控制面向未来（例如，拒绝Amazon EC2中的所有操作，除了不匹配”vpn“的操作）。 |
| 带NotResource的Allow | 用例有限。虽然受支持，但带NotResource的Allow默认包含所有资源——可能允许访问后来添加的新资源。请谨慎使用，并尽可能优先使用显式Deny语句。 |
| 带NotAction的Allow | 用例有限。虽然受支持，但带NotAction的Allow可能无意中允许访问AWS添加的新操作。请谨慎使用，并优先使用显式Deny语句以在服务演进时保持控制。 |
| 带除通配符”*“之外的Resource的Allow | 当使用特定资源（非”*"）的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支持。