企业官网建设流程全解析

AWS CLI 实战：使用accessanalyzer update-archive-rule更新 IAM Access Analyzer 归档规则

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

导读

IAM Access Analyzer 会持续分析 AWS 账户与组织中的资源访问行为并生成 findings（发现项），而**归档规则（archive rule）**可以自动将符合条件的 findings 标记为已归档（Archived），从而减少安全团队的噪声干扰。本篇指南以 AWS CLI 的accessanalyzer update-archive-rule命令为核心，讲解如何就地更新既有归档规则的过滤条件与匹配值，涵盖命令语法、过滤条件 JSON 结构（eq/neq/contains/exists四种操作符）、与create-archive-rule的区别，以及底层 HTTP 调用与幂等设计。读完本文，你将能够用一条命令精准维护 Access Analyzer 的自动化归档策略，并结合get-archive-rule与list-archive-rules验证更新结果。

一、归档规则与update-archive-rule的定位

Access Analyzer 使用analyzer（分析器）持续监控资源，并产出 findings。当某类 finding 属于已知的、可接受的访问行为时，你无需逐条手动处理——归档规则可以基于特定过滤条件自动将这些 finding 归档。

官方文档示例（update-archive-rule.rst）给出了命令的核心定位：更新指定归档规则的 criteria（过滤条件）和 values（匹配值）。它与创建命令create-archive-rule的区别在于：

• create-archive-rule：为一个 analyzer 创建一条全新的归档规则；
• update-archive-rule：就地修改一条已存在规则的过滤逻辑，覆盖原有的 filter 定义，命令本身不产生任何输出；
• delete-archive-rule：删除不再需要的归档规则；
• get-archive-rule/list-archive-rules：分别用于查看单条规则详情或列出某 analyzer 下的全部规则，是更新前后的验证手段。

在 service-2.json 中，该操作被定义为 HTTPPUT请求，请求路径为/analyzer/{analyzerName}/archive-rule/{ruleName}，响应码 200，且标记为idempotent（幂等）——即重复执行相同请求不会产生副作用，这与规则整体替换的语义一致。

二、命令语法与参数详解

2.1 完整命令示例

以下命令更新名为MyArchiveRule的归档规则，使其只归档「资源名包含Cognito且资源类型为 IAM Role」的 findings（官方示例原文）：

aws accessanalyzer update-archive-rule \ --analyzer-name UnusedAccess-ConsoleAnalyzer-organization \ --rule-name MyArchiveRule \ --filter '{"resource": {"contains": ["Cognito"]}, "resourceType": {"eq": ["AWS::IAM::Role"]}}'

命令执行成功时不产生任何输出。若需确认更新效果，可配合以下验证命令：

# 查看单条规则的过滤条件与更新时间 aws accessanalyzer get-archive-rule \ --analyzer-name UnusedAccess-ConsoleAnalyzer-organization \ --rule-name MyArchiveRule # 列出该 analyzer 下的全部归档规则 aws accessanalyzer list-archive-rules \ --analyzer-name UnusedAccess-ConsoleAnalyzer-organization

get-archive-rule的返回中会包含filter字段及createdAt/updatedAt时间戳，可用于核对规则是否按预期更新（完整输出示例见 get-archive-rule.rst）。

2.2 三个必需参数

从模型定义UpdateArchiveRuleRequest（service-2.json）可以看出，该请求有三个required成员：

此外还支持可选的--client-token参数（模型中的clientToken，标记为idempotencyToken），用于保证请求幂等——在网络重试等场景下，相同的 client token 不会导致重复处理。

2.3 常见错误

模型定义中UpdateArchiveRule操作声明了五类错误响应（service-2.json）：

• ResourceNotFoundException：指定的 analyzer 或规则不存在（规则尚未创建，或已通过delete-archive-rule删除）；
• ValidationException：参数不合法，例如 analyzer 名称、规则名称为空，或 filter 结构不符合Criterion定义；
• InternalServerException：服务端内部错误；
• ThrottlingException：请求过于频繁被限流；
• AccessDeniedException：当前凭证缺少access-analyzer:UpdateArchiveRule权限。

三、--filter过滤条件 JSON 结构深度解析

3.1 Criterion：四种匹配操作符

--filter参数的类型为FilterCriteriaMap，其 value 结构为Criterion（service-2.json），支持四种操作符：

结合示例命令逐层拆解：

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

• 外层键resource、resourceType是filter key（过滤键），对应 finding 的不同属性维度；
• 内层{"contains": ["Cognito"]}表示：resource属性值包含子串Cognito；
• 内层{"eq": ["AWS::IAM::Role"]}表示：resourceType属性值精确等于AWS::IAM::Role；
• 多个键之间为AND（与）关系，即一条规则内所有条件需同时满足。

3.2 更多组合示例

仅按 finding 类型归档未使用的 IAM 访问密钥（此键值组合可见于 list-archive-rules.rst 的返回样例）：

aws accessanalyzer update-archive-rule \ --analyzer-name UnusedAccess-ConsoleAnalyzer-organization \ --rule-name ArchiveRule-56125a39 \ --filter '{"findingType": {"eq": ["UnusedIAMUserAccessKey"]}}'

排除型条件与存在性条件：

# 归档非 S3 桶资源、且 region 属性存在的 findings aws accessanalyzer update-archive-rule \ --analyzer-name my-analyzer \ --rule-name MyRule \ --filter '{"resourceType": {"neq": ["AWS::S3::Bucket"]}, "region": {"exists": "true"}}'

注意：exists在 JSON 中以布尔值表达（"true"/"false"），其余操作符均为字符串数组。可用过滤键的完整清单以服务端文档为准，本仓库的模型注释指向「IAM Access Analyzer filter keys」参考（service-2.json）。

3.3 与创建命令的对应关系

create-archive-rule（create-archive-rule.rst）与update-archive-rule的--filter结构完全一致——示例中两者使用了相同的过滤 JSON：

aws accessanalyzer create-archive-rule \ --analyzer-name UnusedAccess-ConsoleAnalyzer-organization \ --rule-name MyRule \ --filter '{"resource": {"contains": ["Cognito"]}, "resourceType": {"eq": ["AWS::IAM::Role"]}}'

这正体现了「先创建、后更新」的规则生命周期：创建时定义初始条件，后续业务变化时用update-archive-rule整体覆盖 filter，无需删除重建。需要强调的是，更新是全量替换语义——调用时传入的 filter 会完整覆盖旧 filter，未在命令中列出的旧条件将被移除，因此务必在命令中写全所有期望保留的匹配条件。

四、底层实现：PUT 请求与幂等语义

从源码模型可确认该命令的底层行为（service-2.json）：

• 采用 HTTPPUT方法访问/analyzer/{analyzerName}/archive-rule/{ruleName}，analyzerName与ruleName都作为 URI 路径参数传递；
• PUT语义本身就是「整体替换资源」，与--filter的全量覆盖行为相互印证；
• 操作声明为"idempotent": true，配合可选的--client-token幂等令牌，保证在超时重试、重复提交等场景下不会产生副作用；
• 命令的返回码为 200 但无响应体（操作未声明 output shape），因此 AWS CLI 正常退出且不打印内容——这正是文档中「This command produces no output」的底层原因。

在 IAM Access Analyzer 的规则生命周期中，本命令对应「更新（update）」环节：创建（create-archive-rule）→ 查询（get-archive-rule/list-archive-rules）→ 更新（update-archive-rule）→ 删除（delete-archive-rule），四者配合即可完成归档规则的完整运维闭环。同类示例文件均位于 awscli/examples/accessanalyzer/ 目录，可一并参考。

五、最佳实践小结

1. 更新前先取证：先用get-archive-rule或list-archive-rules查看当前 filter，避免全量覆盖时误删原有条件；
2. 写全所有条件：update-archive-rule是整体替换而非增量合并，新 filter 需包含所有期望生效的键；
3. 遵守 AND 语义：同一规则内多个过滤键之间是「与」关系，需确保条件之间不互相矛盾；
4. 权限最小化：更新规则至少需要access-analyzer:UpdateArchiveRule权限，且被操作的 analyzer 与规则必须真实存在，否则会触发ResourceNotFoundException或AccessDeniedException；
5. 善用幂等令牌：在自动化脚本中传入--client-token，可规避网络重试带来的重复请求风险；
6. 更新后验证：命令无输出，更新结果应通过get-archive-rule返回的filter字段与updatedAt时间戳确认。

通过update-archive-rule，你可以让 Access Analyzer 的归档策略始终与业务访问模式保持一致，将安全团队的精力从重复性 triage 中释放出来，聚焦真正需要决策的异常访问。

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