AI agent 借用員工帳號有手尾:CSA 點出機器身分治理盲位
Tech News

AI agent 借用員工帳號有手尾:CSA 點出機器身分治理盲位

圖片:via iThome — https://www.ithome.com.tw/news/177637
TechLab 編輯部(譯)·

由 service account 到自動代理,每個身分都要有人負責

AI agent 可以幫手改 code、查文件、整理電郵,甚至直接操作雲端資源,但好多團隊接駁工具嗰陣,仍然貪方便借用員工帳號,或者塞一條長期 API key 入設定檔。功能係行到,出事嗰陣卻好難答到邊個代理、邊次任務同邊項授權觸發咗操作。Cloud Security Alliance(CSA)新報告就由呢個缺口切入,整理企業點管理非人類身分(NHI)。

NHI 唔止係 service account

CSA 嘅定義有條清楚界線:一個程式、裝置或者代理,要能夠證明自己身分,同時獲准存取資源,先算係 NHI。API key、token 同證書只係佢用嚟驗證身分嘅憑證,兩者唔應混埋一齊。iThome 報道,CSA 把 NHI 分成五類,包括 service account 同整合帳號、workload 同微服務、虛擬機及容器等基建身分、IoT 或工控裝置,仲有能夠代人或系統做決定嘅 autonomous agent。

呢個分法幾重要。兩個微服務可能各自用 OIDC token 同 mTLS 證書,但背後仍然係兩個獨立 workload;同一條 API key 俾五個 app 共用,亦唔代表佢哋變成同一個合理身分。每個身分都要交代由邊個負責、可以做咩同幾時停用;至於憑證,就要管好驗證方式、有效期同輪換安排。 混埋管理,最後通常只會見到一堆 key,睇唔出實際邊個服務仲用緊。

CSA《Defining Non-Human Identity》報告封面圖

圖片:Cloud Security Alliance

AI agent 借人帳號,audit log 都幫唔到幾多

AI agent 特別麻煩,因為佢可以按任務內容規劃多個步驟,又可能沿途呼叫 Microsoft 365、GitHub、AWS、Azure、Google Cloud 或其他 SaaS。若果佢直接借用員工帳號,系統記錄好多時只會顯示嗰名員工做過操作;究竟係人手撳掣、邊個 agent 執行、當時收到咩授權同點解採取嗰個動作,未必追得完整。CSA 亦提醒,代理權限可能喺多步操作之間擴張,原本只准睇日曆,之後卻走去發邀請,影響範圍已經唔同咗。

長期 API key 就有另一種手尾。佢一旦流入程式碼、CI secret、agent 工具設定或者測試環境,通常唔會隨住單次任務完結而失效。要撤銷時,所有共用嗰條 key 嘅流程又可能一齊停機,團隊自然愈拖愈耐。較穩陣嘅做法係每個 agent、app 或 workload 有獨立身分,權限跟任務收窄,憑證亦盡量即時簽發同自動過期。

六件事可以即刻開始做

第一,整一份持續更新嘅 inventory。 唔好淨係掃 secret vault,仲要對返 service account、OAuth app、雲端 role、GitHub Actions workflow、裝置證書同 agent 工具連接,記低佢哋存取邊啲資源。第二,每個 NHI 指定技術負責人同業務用途。 員工離職、app 下架或者專案完結時,先有人知道應唔應該停用,避免留下冇人認領嘅帳號。

第三,按實際工作拆細最小權限。 讀取日曆、建立活動、寄信同刪檔應分開授權,唔好為怕 automation 壞掉就一次過開晒。權限亦要定期重看,因為 agent 加咗新工具之後,好容易一路累積舊有存取權。第四,優先用短期憑證。 AWS IAM role、Azure managed identity、Google Workload Identity Federation,同 GitHub Actions 經 OIDC 換取短期 cloud token,都可以減少長期 key 四圍擺。

第五,設定輪換同退役程序。 真係避唔到靜態 key,就要定期限、自動提醒、測試輪換,同準備即時撤銷方法;停用服務時亦要一併拆走相關權限。第六,持續記錄同監察行為。 Audit log 最好保留員工授權者、agent 身分、執行 session、任務意圖同實際操作,再對異常時段、陌生資源同權限突然增加設警報,否則有 log 都未必砌得返完整經過。

標準可以幫手,但先要搞清楚自己有咩

CSA 建議 workload 身分可參考 CNCF 旗下 SPIFFE。佢用短期 X.509 或 JWT 身分文件,配合 workload attestation,自動向服務發證同輪換,較適合容器、微服務同混合雲環境。IETF 嘅 WIMSE 同 SPICE 就仍在發展跨平台 workload 身分及憑證做法。公司未必一開始就要導入成套架構;先盤點共用帳號、長期 key 同冇負責人嘅 NHI,通常已經會搵到最急嗰批風險。

CSA 今次發布嘅係定義同治理框架,冇披露一宗新嘅大型事故。份框架提醒團隊,機器身分建立同停用得好密,唔可以照搬管理員工帳號嗰套做法。正在導入 AI coding agent、SaaS automation 或跨雲部署嘅公司,可以先由共用員工帳號同永不過期 API key 開刀。


參考來源

本文根據原文及公開資料整理;資料有出入時,以原文及官方資料為準。

分享:WhatsAppThreadsTelegramFacebook