作者：羿莉
你真的了解你的 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 角色，不必再摸黑前行。我们的解决方案通过：
-
覆盖全面：同时支持对 AccessKey 和 RAM 角色的活动进行深度观测。
-
技术领先：引入 Umodel 实体建模，将日志观测提升为关系关联洞察，提供前所未有的观测力。
-
开箱即用：提供内置的仪表盘和告警模板，让你跳过复杂的搭建过程，直接享受成果。
这套方案能够极大地提升你云账号的安全性和可管理性。现在，就去云监控 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/
