使用 AWS CLI 的 accessanalyzer check-no-new-access 校验策略更新是否引入新权限【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli在修改 IAM 身份策略或资源策略之前最怕的一件事就是改着改着把权限改宽了——例如在原有 Allow 动作列表里多加了几个高权限 Action或者放宽了 Resource 范围。AWS Access Analyzer 提供的check-no-new-access自定义策略检查Custom Policy CheckAPI可以在策略真正生效之前把待更新的策略与现有策略做一次逐语句对比直接回答这次更新是否引入了新访问权限这个问题。本文以 check-no-new-access.rst 为骨架结合 AWS CLI 中 Access Analyzer 服务模型 的字段定义完整讲解命令用法、参数含义、JSON 策略文档的编写要点以及返回结果的解读帮助你把它接入 CI 流水线或变更评审流程实现策略变更的自动化安全把关。check-no-new-access 是做什么的CheckNoNewAccess是 AWS CLI 中accessanalyzer服务的自定义策略检查类命令。服务模型中对它的定义非常直白Checks whether new access is allowed for an updated policy when compared to the existing policy.即以现有策略为基线检查更新后的策略是否允许了任何新的访问权限。它属于 Access Analyzer 的策略检查Policy Check功能族与check-access-not-granted检查策略是否未授予指定动作、check-no-public-access检查策略是否不公开并列。从 AWS CLI 的命令结构看它位于aws accessanalyzer命令族下完整命令族见 examples/accessanalyzer 目录其中还包含validate-policy、create-access-preview、list-findings等命令。它面向的典型场景是策略变更评审在把新策略应用到 IAM 角色、用户、组或资源之前先确认这次改动没有悄悄扩大权限面最小权限回归检查配合参考策略reference policy使用确保生产策略始终不会超出既定基线CI 安全门禁把本命令放进代码仓库的 CI 流程对策略文件变更做自动化检查FAIL即阻断合并。命令完整用法与参数详解原文档给出了命令的标准调用形式aws accessanalyzer check-no-new-access \ --existing-policy-document file://existing-policy.json \ --new-policy-document file://new-policy.json \ --policy-type IDENTITY_POLICY该命令有三个必填参数在服务模型 CheckNoNewAccessRequest 结构 中三个参数均标记为requiredTrue参数含义是否必填说明--existing-policy-document现有基线策略的 JSON 文档是作为对比基线参考策略reference policy也应传到这里--new-policy-document更新后策略的 JSON 文档是待检查的新策略检查其相对基线是否引入了新访问权限--policy-type策略类型是取值IDENTITY_POLICY身份策略或RESOURCE_POLICY资源策略参数取值细节策略类型--policy-type在服务模型的AccessCheckPolicyType形状中枚举为两个值IDENTITY_POLICY身份策略授权给 IAM 主体角色、用户、组的权限包括托管策略与内联策略RESOURCE_POLICY资源策略授权作用于 AWS 资源包括 IAM 角色的信任策略、S3 存储桶策略、KMS 密钥策略等。原示例中使用的是IDENTITY_POLICY因为它对比的是典型的身份策略对 S3 存储桶的s3:GetObject等动作授权。策略文档的传入方式示例使用file://前缀加载本地 JSON 文件这是 AWS CLI 加载 JSON 文档的标准做法。也可以直接传入以 JSON 字符串如{Version:2012-10-17,...}形式书写的策略内容。两个文档参数的类型在模型中都定义为AccessCheckPolicyDocument字符串类型即策略的完整 JSON 文档。策略文档结构要点两份策略文档都使用标准的 IAM 策略语法核心字段为Version策略语言版本示例使用2012-10-17Statement策略语句数组每条语句包含EffectAllow/Deny、Action、Resource等元素。原示例中的现有策略existing-policy.json{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ s3:GetObject, s3:ListBucket ], Resource: [ arn:aws:s3:::amzn-s3-demo-bucket, arn:aws:s3:::amzn-s3-demo-bucket/* ] } ] }新策略new-policy.json在现有策略基础上Action数组中新增了s3:GetObjectAcl{ Version: 2012-10-17, Statement: [ { Effect: Allow, Action: [ s3:GetObject, s3:GetObjectAcl, s3:ListBucket ], Resource: [ arn:aws:s3:::amzn-s3-demo-bucket, arn:aws:s3:::amzn-s3-demo-bucket/* ] } ] }注意amzn-s3-demo-bucket是 AWS 文档中用于示例的占位存储桶名实际使用时应替换为真实资源 ARN。输出结果解读原示例运行后返回如下输出{ result: FAIL, message: The modified permissions grant new access compared to your existing policy., reasons: [ { description: New access in the statement with index: 0., statementIndex: 0 } ] }对照服务模型 CheckNoNewAccessResponse 结构响应的三个字段含义如下字段类型含义result枚举字符串PASS表示更新后的策略没有允许新访问权限FAIL表示更新后的策略可能允许了新访问权限message字符串人类可读的检查结果说明reasons对象列表对检查结果的逐条推理说明ReasonSummaryList每个reasons元素ReasonSummary结构包含description对检查结果的推理描述statementIndex触发该结论的策略语句的索引号从 0 开始statementId触发该结论的语句的Sid标识若策略语句中定义了Sid。在这个示例中result为FAILreasons[0]明确指出索引为 0 的语句引入了新访问权限——正是新策略中新增的s3:GetObjectAcl动作。这验证了该命令的判定逻辑只要更新后的策略比现有策略多允许任何新的动作、资源或条件组合就返回FAIL。反过来如果新策略只是收窄权限例如删除s3:ListBucket则result应为PASS。结合源码理解命令的底层模型check-no-new-access命令之所以能在 AWS CLI 中直接使用得益于仓库内置的 Access Analyzer 服务模型API 版本2019-11-01。该目录下还包含 paginators-1.json分页配置与 endpoint-rule-set-1.json端点解析规则等元数据文件。服务模型中的CheckNoNewAccess操作定义了命令的输入输出结构输入结构CheckNoNewAccessRequest三个必填成员newPolicyDocument、existingPolicyDocument、policyType输出结构CheckNoNewAccessResponse可选成员resultCheckNoNewAccessResult枚举PASS/FAIL、message字符串、reasonsReasonSummaryList。从模型还可以确认CheckNoNewAccess不在分页器paginators配置中——它的输出是单次调用的检查结论无需也不支持分页遍历。这是它作为一次性策略检查命令与list-findings、list-analyzers等列表型命令后者在 paginators-1.json 中配置了分页的本质区别。此外服务模型对existingPolicyDocument有一个重要使用提示参考策略reference policy应当作为现有策略文档传入。也就是说如果你的团队维护了一份允许的最大权限边界参考策略就把它作为--existing-policy-document传入然后用--new-policy-document传入待上线策略——任何超出参考策略范围的新权限都会被标记为FAIL这正是一种可落地的基线约束实践。实战把检查接入策略变更流程将命令投入实际使用的完整步骤准备基线策略把当前线上生效的策略导出为existing-policy.json或维护一份团队参考策略。准备待检策略把修改后的策略保存为new-policy.json。执行检查aws accessanalyzer check-no-new-access \ --existing-policy-document file://existing-policy.json \ --new-policy-document file://new-policy.json \ --policy-type IDENTITY_POLICY解读与处置result为PASS可以放心部署新策略result为FAIL结合reasons[].statementIndex定位到具体语句人工确认该新增权限是否符合业务预期若不符合回退策略改动。更进一步的工程化用法是把它封装进 CI 脚本——用aws accessanalyzer check-no-new-access的输出配合jq判断result是否为PASS非PASS即非零退出、阻断合并。示例result$(aws accessanalyzer check-no-new-access \ --existing-policy-document file://existing-policy.json \ --new-policy-document file://new-policy.json \ --policy-type RESOURCE_POLICY \ --query result --output text) if [ $result ! PASS ]; then echo Policy change introduces new access; blocking merge. exit 1 fi注意检查结果判定在 AWS 服务端完成AWS CLI 只负责把策略文档安全地传给服务并展示结论因此运行命令需要配置好具备access-analyzer:CheckNoNewAccess权限的凭证。若策略涉及的是资源策略如 S3 桶策略、KMS 密钥策略记得把--policy-type改为RESOURCE_POLICY。总结check-no-new-access是一个轻量而高价值的安全检查命令一次 API 调用即可回答策略更新是否引入了新权限并通过reasons字段精确定位到具体语句。与check-access-not-granted约束不得授予某组动作互补它约束的是相对基线不得变宽这一动态边界。配合参考策略传入--existing-policy-document即可把最小权限原则固化为可自动执行的检查项。相关命令的更多示例可继续查阅 awscli/examples/accessanalyzer 目录下的其他.rst文档例如 check-access-not-granted.rst 与 check-no-public-access.rst。【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考