清理祖传 AK 不怕炸锅：基于 UModel 的云监控 2.0 身份凭证观测实践

news/2025/10/31 11:46:46/文章来源:https://www.cnblogs.com/alisystemsoftware/p/19179332

作者：羿莉

你真的了解你的 AccessKey 吗？

在云时代，AccessKey（AK）、Role（角色）是企业在云上进行身份认证和资源操作的“数字钥匙”。它们被广泛用于各种自动化工具、应用程序和 CI/CD 流程中。然而，随着业务的快速发展，AK、Role 的数量可能迅速膨胀，其使用情况也变得越来越复杂。

从一个常见的任务说起：清理“祖传”身份凭证

一个普普通通的下午，你的团队接到了一个任务：出于安全合规或成本优化的考虑，需要梳理并清理掉一批可能不再使用的 AccessKey（AK）和 RAM 角色。

你看着列表里一长串的AK和ARN，眉头一紧，脑子里立刻冒出好几个问题：

这个 AK 是哪个应用或脚本在用？文档里没写...
这个 RAM 角色最近被谁扮演过？它用临时权限都干了什么？
它们上次活动是什么时候？一个月前？还是一年前？
我现在直接禁用它，线上的业务会“炸”吗？

这些问题，如果只能靠“猜”和“回忆”，那每一次身份凭证管理都像是一场赌博。我们需要的不是猜测，而是基于数据的确凿证据。而传统的 AK 管理方式往往是割裂的、被动的，缺乏全局的可观测性，这在日益复杂的云环境中无疑是一个巨大的安全隐患。这篇文章，就想分享一个行之有效的方法，通过云监控 2.0 的日志审计 [ 1] 应用，实现对 AK 和 RAM 角色清晰观测和主动管理。

从日志解析到实体关联：如何做到清晰可观测？

过去，我们依赖日志查询，就像在成堆的流水账里找线索。虽然有效，但始终缺乏一个更高维度的视角。现在，云监控 2.0 引入了 Umodel [ 2] （统一实体模型） 的概念，从根本上改变了观测的方式。

Umodel 的核心思想是，不再将日志视为孤立的文本行，而是将其解析为相互关联的“实体（Entity）”。

一个 AccessKey 是一个实体，一个 RAM 角色是一个实体。
一个 ECS 实例、一个OSS 存储桶也都是实体。
同时云产品的 API 也是一个实体。

一次 AccessKey 通过调用云产品的 API 实现对云上资源的访问或修改，就是连接这些实体之间的“关系”。

通过接入云监控 2.0 日志审计应用，会自动从管控日志、数据面日志的海量数据中，为你构建出这张“云上身份与资源关系图谱”。基于这张图谱，我们可以轻松地进行各种维度的分析，实现真正的深度可观测。比如，你可以直接观测：“这个 AccessKey，在过去一周内，访问了哪些 ECS 实例，并且执行了哪些 API 操作？” 2.0 日志审计应用会通过 Umodel 为你呈现清晰的答案，而不是一堆人为在海量日志中翻查搜索。

管控面+数据面：全方位构建观测的基础

身份凭证观测的精准性，来源于对两类关键日志数据的深度整合。

管控面日志：来自操作审计 (ActionTrail)

我们可以通过云监控 2.0 日志审计接入操作审计日志，接入后会自动创建跟踪并记录整个阿里云账号下的活动（包含控制台、OpenAPI、开发者工具等对云上产品和服务的访问及使用行为）到当前工作空间下。

数据面日志：来自 OSS、SLS 等服务自身

我们可以通过云监控 2.0 日志审计接入 OSS 访问日志和 SLS 审计日志，它回答的是：“这个身份（AK 或角色）是怎样访问、处理云服务里的数据的？” 比如文件上传下载、日志读写等。

我们将从这两类数据源中提取身份凭证相关的 AccessKey 实体和 Ram 角色实体，通过 Umodel 进行分析，结合云产品 API 实体以及云上各类资源实体，确保了云上身份访问图谱的完整性和可观测性。

实体列表

下图是接入以上数据后，自动提取的相关实体列表示例。

关联建模+洞察穿透：可观测的双轮驱动

关联建模

实体之间关联

实体关联的核心优势在于通过 Node（节点）和 Link（边）的方式揭示云上身份图谱的逻辑结构，显性化地揭示身份凭证和云上资源的关系。下图是一个例子，我们可以看到 AccessKey 和各种身份角色通过 sls 的 PostLogStoreLogs 接口，对日志服务 SLS 的 Project 进行写入操作。

实体和可观测数据集的关联

通过云监控 2.0 日志审计接入数据后，会自动创建身份认证实体与其可观测数据集的关联关系，例如点击身份认证-AccessKey 实体，点击日志探索，会自动完成基础的日志字段映射，可以在可观测对应的日志集中进行深入分析和调查。

洞察穿透

日志审计提供内置的洞察报表，帮助用户进行直观的 AK/角色的使用及下钻分析。

操作审计

例如通过操作审计内置大盘可以筛选用户 AK、RAM 角色，看到当前这个 AK 对每个云服务的最近访问时间、有没有疑似高危操作、是否有未授权的 API 访问等等。

访问详情

通过 OSS 访问审计大盘，可以看到角色 xx 执行的查询、更新、删除操作及具体的频次信息。

告警规则+溯源调查：云上安全风险闭环

告警规则

无需您成为安全运营专家，我们已经将一些最佳实践固化为内置告警模板，你只需要简单配置即可开启告警巡检，主动狩猎潜在的云上安全风险。您也可以根据自身运营详情，创建自己的专属告警规则。

溯源调查

Root AK 使用检测示例

Root AccessKey 是云服务商提供的主账号的最高权限的访问凭证，具备访问和管理资源的全量权限，一旦泄露，攻击者可永久控制账户，且其操作记录无法关联到具体的个人，因此在云上环境极其不推荐直接使用 Root AK。下面是一个检测到 Root AK 使用的告警，可以看到使用的具体是哪个 Root AK，当前的 RootAK 通过云产品接口对哪些资源进行了访问或操作。

OSS 访问权限变更调查示例

OSS 的 ACL 权限变更可能存在安全与合规风险，例如将敏感数据设为公共读导致用户隐私被任意访问泄露等，下面是一个告警检测到 OSS Bucket 的 ACL 权限变更的溯源调查流程。可以看到当前的 OSS Bucket xx 因为修改了 ACL 权限，目前处于一种风险状态。

点击 PutBucketAcl 可以进一步溯源找到具体是哪一个身份凭证进行 BucketAcl 变更的操作

OSS 数据读写来源异常示例

根据有关数据安全规定条例，存储数据的 Bucket 不应该被跨境访问，下面是一个根据数据面 OSS 访问日志检测到 OSS Becket 被跨境访问的溯源调查流程例子，可以看到当前 OSS Bucket 检测到异常的写入行为（PutObject），通过调查溯源可以发现其写入凭证是某个具体 AccessKey LTAxxx，其写入客户端来源是境外 IP 地址。