使用 aws accessanalyzer get-archive-rule 查询归档规则的完整指南【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli导读本文以 AWS CLI 中accessanalyzer get-archive-rule命令为核心讲解如何查询 IAM Access Analyzer访问分析器中已定义的归档规则Archive Rule及其过滤条件。你将掌握该命令的完整用法、返回 JSON 的字段结构、底层 REST API 的实现细节以及与之配套的创建、更新、列表、应用和删除归档规则的完整操作链路可将其直接应用于日常的访问权限审计与告警收敛工作。一、归档规则与 get-archive-rule 的定位IAM Access Analyzer 会持续分析你的账户和资源并产出「发现项」findings提示潜在的公共访问、跨账户访问等问题。面对大量低价值或已确认无风险的 finding直接逐个处理并不现实。归档规则Archive Rule正是为此设计的它由一组过滤器filter条件定义命中条件的新finding 会被自动归档从而减少噪音、聚焦真正需要人工处理的问题。get-archive-rule命令用于检索指定 analyzer 下某一个归档规则的详细信息包括规则名称、过滤器条件、创建与更新时间。它属于只读查询操作在服务模型中标记为readonly: true不会对 analyzer 或规则产生任何副作用适合在自动化巡检、规则审计、变更前核对等场景中使用。二、命令格式与参数说明2.1 完整命令示例参考 get-archive-rule.rst 中的官方示例命令如下aws accessanalyzer get-archive-rule \ --analyzer-name UnusedAccess-ConsoleAnalyzer-organization \ --rule-name MyArchiveRule2.2 参数详解参数是否必填说明--analyzer-name必填要从中检索规则的 analyzer分析器名称例如控制台自动创建的UnusedAccess-ConsoleAnalyzer-organization。--rule-name必填要检索的归档规则名称例如MyArchiveRule。从底层服务模型 service-2.json 可以看到GetArchiveRuleRequest结构体将这两个参数都标记为required并且它们都会被放入URL 路径location: uri而不是请求体或查询字符串——这决定了该命令对应一次对 REST 资源的直接 GET 访问HTTP 方法GET请求 URI/analyzer/{analyzerName}/archive-rule/{ruleName}即get-archive-rule本质上是「按名称定位资源」的精确查询而非模糊搜索因此两个参数缺一不可。2.3 输出结构命令成功执行后返回如下 JSON示例输出同样来自 get-archive-rule.rst{ archiveRule: { createdAt: 2024-02-15T00:49:2700:00, filter: { resource: { contains: [ Cognito ] }, resourceType: { eq: [ AWS::IAM::Role ] } }, ruleName: MyArchiveRule, updatedAt: 2024-02-15T00:49:2700:00 } }返回体只有一个顶层字段archiveRule其类型为ArchiveRuleSummary。根据 service-2.json 中的模型定义该结构体包含四个必填字段含义如下字段类型说明ruleNameString归档规则的名称。filterFilterCriteriaMap定义规则的一组过滤条件见下节。createdAtTimestamp规则创建时间ISO 8601 格式。updatedAtTimestamp规则最近一次更新时间。2.4 filter 字段的深层解析filter是归档规则的核心它决定哪些 finding 会被自动归档。从 Criterion 结构体可以看到每个过滤键支持四类运算符运算符语义适用场景eq等于精确匹配如resourceType: {eq: [AWS::IAM::Role]}neq不等于排除特定值contains包含子串匹配如resource: {contains: [Cognito]}exists是否存在布尔判断如{exists: true}上面示例中filter的含义是资源类型为 IAM 角色且资源名称中包含 Cognito的 finding 将被自动归档。规则可以组合多个过滤键如同时使用resource与resourceType键与键之间为 AND 关系。提示关于可选用的过滤键filter keys全集可参考 IAM 用户指南中的「IAM Access Analyzer filter keys」章节。从源码注释可见Criterion与GetArchiveRule操作均明确指向该权威列表见 service-2.json 的文档字段。2.5 可能出现的异常根据服务模型GetArchiveRule的errors列表service-2.json该命令可能抛出以下异常可据此排查失败原因ResourceNotFoundException指定的 analyzer 或规则不存在最常见需核对两个名称ValidationException参数格式非法如名称为空或含非法字符AccessDeniedException当前凭证无权读取该 analyzer 下的规则ThrottlingException请求过于频繁被限流建议退避重试InternalServerException服务端内部错误。三、归档规则的完整生命周期与 get-archive-rule 配套的命令get-archive-rule通常不会单独使用而是与同一主题下的其他命令组成「创建 → 查询 → 更新 → 应用 → 列表 → 删除」闭环。以下命令示例均来自仓库中 accessanalyzer 示例目录。3.1 创建规则create-archive-ruleaws accessanalyzer create-archive-rule \ --analyzer-name UnusedAccess-ConsoleAnalyzer-organization \ --rule-name MyRule \ --filter {resource: {contains: [Cognito]}, resourceType: {eq: [AWS::IAM::Role]}}--filter直接以 JSON 字符串传入过滤条件与 get 返回结构中的filter字段完全同构。命令成功执行时不产生输出详见 create-archive-rule.rst。3.2 更新规则update-archive-ruleaws accessanalyzer update-archive-rule \ --analyzer-name UnusedAccess-ConsoleAnalyzer-organization \ --rule-name MyArchiveRule \ --filter {resource: {contains: [Cognito]}, resourceType: {eq: [AWS::IAM::Role]}}同样以--filter传入新的过滤条件整体替换原有条件详见 update-archive-rule.rst。更新后可通过get-archive-rule复核updatedAt与新的filter内容。3.3 应用规则到存量 findingapply-archive-rule归档规则默认只对创建之后产生的 finding 生效。如需让规则作用到已存在的 finding使用aws accessanalyzer apply-archive-rule \ --analyzer-arn arn:aws:access-analyzer:us-west-2:111122223333:analyzer/UnusedAccess-ConsoleAnalyzer-organization \ --rule-name MyArchiveRule注意此处参数是--analyzer-arn分析器 ARN而非--analyzer-name详见 apply-archive-rule.rst。结合源码可知ApplyArchiveRuleRequest结构体将该 ARN 作为必填字段并带幂等令牌clientTokenidempotencyToken: true避免重复提交产生副作用见 service-2.json。3.4 列出全部规则list-archive-rulesaws accessanalyzer list-archive-rules \ --analyzer-name UnusedAccess-ConsoleAnalyzer-organization该命令返回archiveRules数组其中每个元素即为ArchiveRuleSummary与get-archive-rule返回的单条结构一致。参考 list-archive-rules.rst 的输出示例可以看到同一 analyzer 下多条规则并存例如一条按resource/resourceType过滤另一条按findingType等于UnusedIAMUserAccessKey过滤可用于在调用 get 前确认规则的确切名称避免拼写错误导致ResourceNotFoundException。3.5 删除规则delete-archive-ruleaws accessanalyzer delete-archive-rule \ --analyzer-name UnusedAccess-ConsoleAnalyzer-organization \ --rule-name MyRule命令成功执行时不产生输出详见 delete-archive-rule.rst。四、源码级原理命令到 REST API 的映射为了理解get-archive-rule的完整调用链可以从 AWS CLI 的架构入手。AWS CLI 的每个服务命令都由 cli.json 中的服务定义驱动由 clidriver.py 负责命令分发与参数解析底层则通过仓库内置的 botocore 客户端client.py完成签名、序列化与 HTTP 发送。参数定义来自 botocore 维护的 service-2.json 服务模型因此服务模型的每一项变更都会自动反映到 CLI 的参数与校验行为中。以get-archive-rule为例从模型文件可以还原出完整的 REST 语义GET /analyzer/{analyzerName}/archive-rule/{ruleName}其中两个 URI 路径变量分别对应--analyzer-name与--rule-name这是「参数被标记为location: uri」的直接结果。这也解释了为何必须同时提供两个参数缺少任何一个都无法构成有效的资源路径。此外由于该操作被标记为只读readonly: true它在--no-sign-request之外仍受 IAM 权限控制调用方需要具备access-analyzer:GetArchiveRule权限。五、实践建议先 list 再 get在脚本中先调用list-archive-rules拿到规则名称再逐个get-archive-rule获取详情可避免硬编码名称带来的维护成本与 404 错误。用 updatedAt 做变更审计updatedAt字段可用于检测规则是否在未预期的时机被修改配合更新流程实现规则变更的可追溯。结合 apply 处理存量 finding新建规则后若发现存量噪音 finding 未被清理及时调用apply-archive-rule注意该命令需要 analyzer ARN。在 CI 巡检中引入只读查询由于get-archive-rule是纯只读操作可安全地写入定期巡检任务用于核对归档规则的过滤条件是否符合当前治理策略。六、关联文档与进一步阅读命令示例get-archive-rule.rst配套示例create-archive-rule.rst、update-archive-rule.rst、apply-archive-rule.rst、list-archive-rules.rst、delete-archive-rule.rst服务模型定义service-2.jsonGetArchiveRule操作位于 第 321 行请求/响应结构体位于 第 2543 行关于归档规则的更多背景如 filter keys 的完整清单与规则行为细节可查阅 IAM 用户指南中的 Archive rules 章节。本文所有命令参数、返回结构与异常说明均以当前仓库中的示例文档和服务模型为准。【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考