清理祖傳 AK 不怕炸鍋：基于 UModel 的云監控 2.0 身份憑證觀測實踐

在云時代，AccessKey（AK）、Role（角色）是企業在云上進行身份認證和資源操作的“數字鑰匙”。它們被廣泛用于各種自動化工具、應用程序和 CI/CD 流程中。然而，隨著業務的快速發展，AK、Role 的數量可能迅速膨脹，其使用情況也變得越來越復雜。

作者：羿莉

你真的了解你的 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/