企业官网建设流程全解析

AWS CLIaccessanalyzer list-archive-rules命令实战指南：检索 IAM Access Analyzer 归档规则

【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli

本文聚焦 AWS CLI 中aws accessanalyzer list-archive-rules命令的完整用法，说明如何按分析器（analyzer）检索账户内已创建的归档规则（archive rule），并深入解析输出 JSON 结构、筛选条件（filter）语义、分页参数以及底层 API 实现（基于 service-2.json 与 paginators-1.json）。读完本文，你将能够独立运行该命令查询归档规则、读懂每条规则的过滤条件与时间戳字段，并借助--max-results与--next-token完成分页遍历。

一、归档规则（Archive Rule）与 IAM Access Analyzer 简介

IAM Access Analyzer 会持续分析账户中的资源，并生成"外部访问发现项"（findings），提示可能存在的非预期访问风险。当某些 finding 属于已知的、可接受的场景时，直接删除会丢失审计信息，此时可以通过创建**归档规则（archive rule）**让符合条件的 finding 自动进入归档状态（archived），从而减少告警噪音，同时保留审计记录。

归档规则与某个具体的分析器（analyzer）绑定。分析器分为账户级、组织级（organization）以及"未使用访问"（unused access）类型；例如本仓库示例中反复出现的UnusedAccess-ConsoleAnalyzer-organization即是一个组织级的未使用访问分析器。list-archive-rules的作用正是：列出指定分析器名下已创建的全部归档规则。

在 AWS CLI 中，归档规则的生命周期由一组命令共同管理，本文讲解的list-archive-rules是其中的"查询"环节：

• create-archive-rule.rst：创建归档规则
• get-archive-rule.rst：获取单条规则的详情
• update-archive-rule.rst：更新规则的筛选条件
• delete-archive-rule.rst：删除规则
• apply-archive-rule.rst：将规则应用于已存在的 findings

二、命令语法与参数说明

list-archive-rules的核心语法如下：

aws accessanalyzer list-archive-rules \ --analyzer-name <分析器名称> \ [--max-results <整数>] \ [--next-token <分页令牌>]

根据 service-2.json 中ListArchiveRulesRequest结构体的定义（约 L3392-L3415），本命令的参数语义如下：

从服务模型可以看到，该操作是只读操作（"readonly": true），底层对应 HTTPGET方法，响应码为 200，其定义位于 service-2.json。

三、实战示例：检索指定分析器的归档规则

仓库中的示例文档 list-archive-rules.rst 给出了一个完整的调用与响应示例。假设你的账户中存在一个组织级分析器UnusedAccess-ConsoleAnalyzer-organization，运行：

aws accessanalyzer list-archive-rules \ --analyzer-name UnusedAccess-ConsoleAnalyzer-organization

返回的 JSON 输出如下：

{ "archiveRules": [ { "createdAt": "2024-02-15T00:49:27+00:00", "filter": { "resource": { "contains": [ "Cognito" ] }, "resourceType": { "eq": [ "AWS::IAM::Role" ] } }, "ruleName": "MyArchiveRule", "updatedAt": "2024-02-15T00:49:27+00:00" }, { "createdAt": "2024-02-15T23:27:45+00:00", "filter": { "findingType": { "eq": [ "UnusedIAMUserAccessKey" ] } }, "ruleName": "ArchiveRule-56125a39-e517-4ff8-afb1-ef06f58db612", "updatedAt": "2024-02-15T23:27:45+00:00" } ] }

上述输出中包含了该分析器名下创建的两条归档规则，分别对应手动命名的规则MyArchiveRule与一个自动生成名称的规则（形如ArchiveRule-<UUID>）。

输出字段逐项解读

根据ListArchiveRulesResponse结构（service-2.json），响应体由archiveRules与可选的nextToken组成：

• archiveRules：归档规则列表，必填字段。数组中的每个元素包含：
  • ruleName：规则名称，唯一标识该规则，后续get-archive-rule、update-archive-rule、delete-archive-rule均需引用它；
  • filter：规则使用的筛选条件（详见下文第四节）；
  • createdAt：规则创建时间，ISO 8601 格式（如2024-02-15T00:49:27+00:00）；
  • updatedAt：规则最近一次更新时间，同样为 ISO 8601 时间戳。
• nextToken：分页令牌（可选）。当结果被截断、还有更多数据时返回；若为空则表示已遍历完所有规则。

观察示例可以发现，两条规则的createdAt与updatedAt完全一致——这是规则创建后尚未被修改过的典型表现；一旦通过update-archive-rule变更筛选条件，updatedAt会晚于createdAt。

四、深入理解 filter：归档规则的筛选条件语义

归档规则的核心是filter（筛选条件），它决定哪些 finding 会被自动归档。示例中的第一条规则展示了两个维度：

"filter": { "resource": { "contains": ["Cognito"] }, "resourceType": { "eq": ["AWS::IAM::Role"] } }

• resource键使用contains操作符，含义是"资源标识符包含字符串Cognito"；
• resourceType键使用eq操作符，含义是"资源类型等于AWS::IAM::Role"。

第二条规则则演示了针对 finding 类型的过滤：

"filter": { "findingType": { "eq": ["UnusedIAMUserAccessKey"] } }

从服务模型 service-2.json 中Criterion结构体的定义可以看到，每个筛选键（如resource、resourceType、findingType）支持以下四种操作符：

同一filter内可组合多个筛选键，多个条件之间按"与"（AND）关系生效——例如第一条规则要求资源同时满足"包含 Cognito"且"类型为 IAM Role"。这与 create-archive-rule.rst 中创建规则时所传入的--filterJSON 完全对应，即：在创建/更新规则时写入的 filter 结构，会原样在 list/get 的输出中返回，因此该命令的输出也可以作为核对规则是否符合预期的依据。

五、分页：max-results 与 next-token

当分析器下的归档规则数量较多时，单次调用可能无法返回全部结果。服务模型（ListArchiveRulesRequest）与分页配置（paginators-1.json）共同明确了分页机制：

• 请求参数中的nextToken对应响应中的nextToken（input_token/output_token）；
• maxResults为每页条数上限（limit_key）；
• archiveRules为结果字段（result_key）。

因此在 CLI 层面有两种分页用法：

方式一：显式分页

# 第一页，每页最多返回 10 条 aws accessanalyzer list-archive-rules \ --analyzer-name UnusedAccess-ConsoleAnalyzer-organization \ --max-results 10 # 用上一页返回的 nextToken 继续取下一页 aws accessanalyzer list-archive-rules \ --analyzer-name UnusedAccess-ConsoleAnalyzer-organization \ --next-token "eyJhbGciOi..." \ --max-results 10

方式二：使用--no-paginate关闭自动分页。AWS CLI 默认会自动跟随分页令牌直至取完所有结果；当希望精确控制或调试单次请求时，可显式传入--no-paginate查看原始分页响应。

六、异常与权限说明

根据 service-2.json，ListArchiveRules可能抛出以下四种异常，理解它们有助于排查问题：

• ValidationException：请求参数校验失败，最常见的原因是--analyzer-name为空、格式非法或引用了不存在的分析器名称；
• AccessDeniedException：调用者缺乏执行access-analyzer:ListArchiveRules权限，需要检查 IAM 策略是否授予了对应分析器资源的读取权限；
• ThrottlingException：请求频率过高触发限流，可适当退避重试；
• InternalServerException：服务端内部错误，通常需要稍后重试。

七、与其他 archive-rule 命令的配合使用

list-archive-rules的输出字段（尤其是ruleName与filter）可以直接复用到归档规则生命周期的其他环节：

1. 核对规则详情：拿到ruleName后，可用 get-archive-rule.rst 中的get-archive-rule单独查询某条规则的完整定义；
2. 修改规则：当某条规则的筛选条件过时，可用 update-archive-rule.rst 中的update-archive-rule --rule-name <名称> --filter '<新条件>'进行更新；
3. 删除规则：不再需要的规则可用 delete-archive-rule.rst 中的delete-archive-rule --rule-name <名称>删除；
4. 批量归档存量 finding：新规则默认只作用于之后产生的 finding，若想让它同时处理已经存在的历史 finding，可参考 apply-archive-rule.rst 使用apply-archive-rule（注意该命令传入的是分析器 ARN 而非名称）。

八、小结

aws accessanalyzer list-archive-rules是管理 IAM Access Analyzer 归档规则的"只读视图"：通过--analyzer-name定位分析器，即可一次性查看其名下所有归档规则的名称、筛选条件与创建/更新时间。结合--max-results与--next-token可以处理大规模规则集；结合filter的eq/neq/contains/exists四类操作符，可以准确理解每条规则的实际归档语义，从而与创建、更新、删除、应用等命令构成完整的规则生命周期管理闭环。对于希望自动化审计 Access Analyzer 配置、减少误报噪音的运维与安全团队而言，该命令是日常巡检与合规检查中高频使用的基础能力。

【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli