作者：羿莉
你真的了解你的 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 地址。
点击 PutObject，进一步溯源执行日志写入的凭证 LTAxxx。
点击凭证 LTAxxx，即可发现其通过 client_ip( 8.216.xx.xx) 进行跨境访问河源地域的 OSS Bucket，从而完成调查闭环。
总结一下
管理云上的 AK 和 RAM 角色，不必再摸黑前行。我们的解决方案通过：
1. 覆盖全面：同时支持对 AccessKey 和 RAM 角色的活动进行深度观测。
2. 技术领先：引入 Umodel 实体建模，将日志观测提升为关系关联洞察，提供前所未有的观测力。
3. 开箱即用：提供内置的仪表盘和告警模板，让你跳过复杂的搭建过程，直接享受成果。
这套方案能够极大地提升你云账号的安全性和可管理性。现在，就去云监控 2.0 日志审计开启接入吧，让每一对身份凭证都变得清晰、可控。
相关链接：
[1] 日志审计
https://help.aliyun.com/zh/cms/cloudmonitor-2-0/user-guide/log-audit/
[2] Umodel
https://help.aliyun.com/zh/cms/cloudmonitor-2-0/user-guide/umodel/
