获取分析器列表：AWS CLIaccessanalyzer list-analyzers命令深度解析
【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli
导读：本文以 aws-cli 仓库中的官方示例文档 list-analyzers.rst 为核心，系统讲解 AWS IAM Access Analyzer 的list-analyzers命令——包括命令语法、可选参数、返回字段语义、分页机制与常见错误处理。结合 service-2.json 服务模型与 paginators-1.json 分页配置，帮助你彻底掌握如何审计账户内已有的分析器（Analyzer），并为其后续的创建、删除、归档规则管理打下基础。
一、命令概览：一次列出账户内的所有分析器
aws accessanalyzer list-analyzers用于检索当前 AWS 账户（或组织）中已有的全部分析器。在 IAM Access Analyzer 的体系中，"分析器"是执行资源访问分析的最小单位——它会持续扫描受支持资源上的策略，并生成"发现项"（findings），提示潜在的外部访问或未使用权限。因此，list-analyzers通常是你开始使用 Access Analyzer 时最先执行的命令之一：先看清现有分析器的类型、状态与所属范围，再决定是复用、扩展还是新建。
官方示例给出了最简调用形式：
aws accessanalyzer list-analyzers示例输出（JSON 格式）如下：
{ "analyzers": [ { "arn": "arn:aws:access-analyzer:us-west-2:111122223333:analyzer/UnusedAccess-ConsoleAnalyzer-organization", "createdAt": "2024-02-15T00:46:40+00:00", "name": "UnusedAccess-ConsoleAnalyzer-organization", "status": "ACTIVE", "tags": { "auto-delete": "no" }, "type": "ORGANIZATION_UNUSED_ACCESS" }, { "arn": "arn:aws:access-analyzer:us-west-2:111122223333:analyzer/ConsoleAnalyzer-organization", "createdAt": "2020-04-25T07:43:28+00:00", "lastResourceAnalyzed": "arn:aws:s3:::amzn-s3-demo-bucket", "lastResourceAnalyzedAt": "2024-02-15T21:51:56.517000+00:00", "name": "ConsoleAnalyzer-organization", "status": "ACTIVE", "tags": { "auto-delete": "no" }, "type": "ORGANIZATION" }, { "arn": "arn:aws:access-analyzer:us-west-2:111122223333:analyzer/ConsoleAnalyzer-account", "createdAt": "2019-12-03T07:28:17+00:00", "lastResourceAnalyzed": "arn:aws:sns:us-west-2:111122223333:config-topic", "lastResourceAnalyzedAt": "2024-02-15T18:01:53.003000+00:00", "name": "ConsoleAnalyzer-account", "status": "ACTIVE", "tags": { "auto-delete": "no" }, "type": "ACCOUNT" } ] }示例中的三条记录正好体现了三种典型场景：一个组织级"未使用访问"分析器（ORGANIZATION_UNUSED_ACCESS）、一个组织级标准分析器（ORGANIZATION），以及一个账户级标准分析器（ACCOUNT）。注意，由 IAM 控制台自动创建的分析器会带有auto-delete: no标签，用于在关闭控制台集成时保护其不被自动清理。
二、命令参数：从服务模型看支持的三种过滤选项
尽管list-analyzers不要求任何必填参数，但根据服务模型 service-2.json 中的ListAnalyzersRequest定义，它支持三个可选请求参数，全部以 query string 形式附加在 HTTP 请求中：
| 参数 | 位置 | 说明 |
|---|---|---|
type | query string | 按分析器类型过滤，例如ACCOUNT、ORGANIZATION、ORGANIZATION_UNUSED_ACCESS |
maxResults | query string | 单次响应中返回的最大结果数（对应 CLI 的--max-items/--page-size） |
nextToken | query string | 用于分页续取的令牌，服务端返回的nextToken原样传回即可获取下一页 |
对应到 AWS CLI 命令行，你可以这样组合使用：
# 只列出账户级标准分析器 aws accessanalyzer list-analyzers --type ACCOUNT # 每次只取 2 条结果（便于演示分页） aws accessanalyzer list-analyzers --max-items 2 # 使用 CLI 自动分页：循环输出全部分析器，每页 10 条 aws accessanalyzer list-analyzers --page-size 10 --max-items 100从底层实现看，该命令对应的服务端接口是GET /analyzer（HTTP 200），属于只读操作（readonly: true），不会对分析器产生任何副作用，可以放心在审计脚本中高频调用。CLI 之所以支持--max-items与--page-size，是因为 paginators-1.json 为ListAnalyzers声明了分页规则：input_token = nextToken、output_token = nextToken、limit_key = maxResults、result_key = analyzers。也就是说，CLI 会把服务端的maxResults/nextToken参数对自动串联起来，按页拉取直到取完--max-items指定的总数。
三、返回字段逐项拆解：分析器摘要（AnalyzerSummary）的语义
根据服务模型中AnalyzerSummary结构的定义（service-2.json），analyzers数组中的每个元素包含以下字段。其中arn、name、type、createdAt、status为必返回字段，其余字段按实际情况出现：
| 字段 | 必返 | 语义 |
|---|---|---|
arn | ✅ | 分析器的 Amazon 资源名称，格式为arn:aws:access-analyzer:<region>:<account-id>:analyzer/<name> |
name | ✅ | 分析器名称，在同一账户同一区域内唯一 |
type | ✅ | 分析器的信任区类型（zone of trust）与用途，详见下文"类型枚举" |
createdAt | ✅ | 分析器创建时间，ISO 8601 格式时间戳 |
status | ✅ | 分析器当前状态，取值见下文"状态枚举" |
lastResourceAnalyzed | 否 | 最近一次被该分析器扫描的资源 ARN |
lastResourceAnalyzedAt | 否 | 最近一次资源扫描发生的时间戳（纳秒精度，如2024-02-15T21:51:56.517000+00:00） |
tags | 否 | 应用于分析器的标签键值对；键最长 128 字符且不能以aws:前缀开头，值最长 256 字符 |
statusReason | 否 | 状态补充说明，例如创建失败时的具体原因（如组织型分析器创建时成员账户的服务相关角色创建失败） |
configuration | 否 | 指明分析器是外部访问、未使用访问还是内部访问分析器。注意：ListAnalyzers响应中会省略该字段，只有调用GetAnalyzer才会返回它 |
managedBy | 否 | 管理该分析器的服务主体（如securityhubv2.amazonaws.com），仅服务关联分析器（service-linked analyzer）才有此字段 |
值得特别说明的两点：
lastResourceAnalyzed与lastResourceAnalyzedAt是审计信号：当分析器类型为未使用访问分析器（如ORGANIZATION_UNUSED_ACCESS）时，这两个字段通常不出现（示例中第一条记录就缺失它们）；而标准分析器在完成至少一次扫描后就会填充。如果你看到某个分析器长期没有lastResourceAnalyzed更新，可能意味着其扫描范围被限制或已停用。configuration字段的"省略"行为：从服务模型文档可以确认，ListAnalyzers有意省略该字段以减小响应体积，需要查看分析器具体配置（例如未使用访问分析器的unusedAccessAge阈值、内部访问分析器的inclusions规则）时，应改用get-analyzer命令获取单个分析器的完整详情。
四、类型与状态枚举：理解分析器的"身份"与"健康度"
type与status是判断分析器行为能力的两个关键字段，其合法取值均由服务模型中的枚举定义。
分析器类型（Type枚举，见 service-2.json）：类型描述了分析器的"信任区"（zone of trust）范围与分析目的，共 6 种：
| 枚举值 | 作用域 | 分析目的 |
|---|---|---|
ACCOUNT | 单账户 | 外部访问分析（经典类型），扫描账户内资源策略，寻找可被外部主体访问的发现项 |
ORGANIZATION | 整个组织 | 外部访问分析，覆盖组织内所有成员账户 |
ACCOUNT_UNUSED_ACCESS | 单账户 | 未使用访问分析，识别闲置的 IAM 角色、密钥与 S3 桶访问 |
ORGANIZATION_UNUSED_ACCESS | 整个组织 | 未使用访问分析，覆盖组织内所有成员账户 |
ACCOUNT_INTERNAL_ACCESS | 单账户 | 内部访问分析，评估内部主体对资源的访问路径 |
ORGANIZATION_INTERNAL_ACCESS | 整个组织 | 内部访问分析，覆盖组织内所有成员账户 |
分析器状态（AnalyzerStatus枚举，见 service-2.json）：
| 枚举值 | 含义 |
|---|---|
ACTIVE | 分析器正常运行，持续监控受支持资源并生成新发现项 |
CREATING | 分析器创建中，尚未开始工作 |
DISABLED | 已停用，不再生成新发现项。典型触发场景：从 Organizations 中移除了对 Access Analyzer 的可信访问授权 |
FAILED | 创建失败。例如组织型分析器创建时，若组织成员账户中的服务相关角色创建出现问题，就会进入此状态 |
实操建议：在自动化巡检脚本中，应把status != "ACTIVE"的分析器视为异常信号——DISABLED说明账户信任访问配置被改动过，FAILED说明创建链路存在环境问题，两者都需要人工介入。示例输出中三条记录全部为ACTIVE，属于健康状态。
五、分页实战：从服务端令牌到 CLI 自动分页
当账户中分析器数量较多时，单次请求无法返回全部结果。此时分页机制至关重要。其工作流程如下：
- 首次调用不传
nextToken，服务端返回一页结果；若存在更多数据，响应体中携带非空的nextToken。 - 将返回的
nextToken原样传入下一次请求，直到响应中不再包含nextToken。
以服务端协议为例，手动分页的调用序列大致如下：
# 第一页 aws accessanalyzer list-analyzers --max-items 2 # 第二页（将第一页输出中的 "nextToken" 值传入） aws accessanalyzer list-analyzers --max-items 2 --starting-token <上一页的nextToken值>而在日常脚本中，更推荐依赖 CLI 内置的自动分页能力。由于ListAnalyzers在 paginators-1.json 中已声明result_key: analyzers，你可以直接使用--query提取全部分析器名称而无需关心令牌：
# 自动翻页，仅输出所有分析器的名称 aws accessanalyzer list-analyzers --query "analyzers[].name" --output json # 按类型分组统计 aws accessanalyzer list-analyzers --query "analyzers[].type" --output text | sort | uniq -c配合--output table还能获得适合人工阅读的表格视图，例如查看每个分析器的状态与最后扫描时间：
aws accessanalyzer list-analyzers \ --query "analyzers[].[name, type, status, lastResourceAnalyzed]" \ --output table六、异常处理：四种可能的错误响应
根据服务模型，ListAnalyzers接口可能返回以下四种错误（service-2.json），脚本编写时应针对性地捕获与重试：
| 错误 | HTTP 语义 | 典型成因与处理 |
|---|---|---|
ValidationException | 400 | 参数校验失败，如type传入了枚举之外的值；检查参数拼写后重试 |
AccessDeniedException | 403 | 调用者缺少access-analyzer:ListAnalyzers权限；需在 IAM 策略中补充授权 |
ThrottlingException | 429 | 请求频率超限；指数退避（exponential backoff）后重试 |
InternalServerException | 500 | 服务端内部错误；稍后重试 |
最小权限策略示例（仅允许列出与查看分析器）：
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "access-analyzer:ListAnalyzers", "Resource": "*" } ] }七、与其他分析器命令的组合用法
list-analyzers是整个 Access Analyzer CLI 操作链的入口。拿到分析器的arn与name后，你可以继续使用同目录下的其他示例命令：
- 查看单个分析器详情：使用
get-analyzer获取ListAnalyzers响应中被省略的configuration等字段； - 创建分析器：参考 create-analyzer.rst，创建账户级（
ACCOUNT）或组织级（ORGANIZATION）分析器； - 删除分析器：参考 delete-analyzer.rst，按
analyzer-name删除废弃分析器； - 管理归档规则：参考 apply-archive-rule.rst 与 create-archive-rule.rst，为分析器配置发现项的自动归档规则；
- 检索发现项：通过
list-findings拉取分析器生成的安全发现。
一个典型的安全巡检脚本流程是：先用list-analyzers确认所有分析器status为ACTIVE，再对每个ACTIVE分析器调用list-findings汇总外部访问风险。这样就能把"分析器是否健康"与"发现了什么问题"两个层面的审计闭环打通。
八、小结
aws accessanalyzer list-analyzers虽然是无参数即可运行的基础命令，但正确理解其type过滤、分页令牌与状态字段，才能写出稳健的自动化审计脚本。本文结合 官方示例、服务模型 与 分页配置 三个仓库证据，完整还原了该命令的请求参数、响应结构与底层协议（GET /analyzer）。当你在日常运维中看到DISABLED或FAILED状态时，可对照上文的状态说明与错误表快速定位问题，再通过 create-analyzer.rst 等配套命令完成修复。
【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
