解锁新可能：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： 此示例的目标是强制执行资源边界，阻止访问组织外部的资源，但已定义的一组服务拥有资源除外。
之前的实现： 策略使用基于标签的方法来管理例外。它要求为IAM主体标记dp:exclude:resource:s3=true以授予对外部资源的访问权限。这给标签管理带来了操作开销，并且如果标签应用不正确，可能会引入安全风险。
改进的实现： 通过支持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通过默认允许访问Amazon Bedrock操作，同时明确拒绝调用三个特定模型（例如：Deepseek、Anthropic和meta），为组织内的AWS账户提供了广泛的权限基线。然而，这种方法需要持续的操作开销，以确保策略更新以拒绝访问新添加的模型，避免暴露于可能不需要的模型。
改进的实现： 通过支持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支持。