從雲AK泄露利用看企業特權管理

2022 年 9 月 16 日
筆記
產品經理, 安全, 隨筆

從雲AK泄露利用看企業特權管理

– 緣起

– 特權管理與堡壘機、IAM、零信任的關係？

– 特權管理是否應該侵入到業務流程中？

如果你是一名黑客，你是試圖直接攻擊一個層層加固、布滿各種檢測技術、24小時人員職守的系統並竊取數據。還是選擇通過社會工程學的方式獲取系統賬號後，如入無人之境地查看、下載數據。

大多數情況從外部發起攻擊都需要經歷建立據點、搜尋目標、獲取權限、拿到數據的幾個階段。對於一個基礎安全牢固且運營良好的系統而言，直接攻擊將耗費大量的時間和精力，而通過社工等方式獲取系統特權賬號則成了一條捷徑。

緣起

雲環境相比傳統環境，新增的一大風險即用戶Access key的泄露風險。AK是應用程序調用雲平台API時使用的認證憑據。一個用戶的AK泄露往往代表用戶在雲平台最高權限的泄露，雲環境中所有計算、存儲資源對入侵者門洞大開。非法利用者甚至不需要為此單獨開發工具，直接使用現成的產品就能直接獲取用戶在雲內的所有資源列表。

將AK導入商用的產品後可輕鬆獲取用戶雲上資源

入侵者實際能做的還遠不止這些。包括輕易查看當前用戶所有的數據資產，在主機資產上執行任意命令，修改存儲訪問權限，數據庫賬號創建、提權，增加高權限用戶，刪除日誌等等，可謂是無所不能。所以不能簡單地將雲平台的AK當作單個系統的頂級權限，而是雲上所有資源的頂級權限。這也註定了用戶在雲上的AK將成為攻擊者的重點目標。

AK功能強大，基本上管理員賬號能做的AK都能做

當前主流AK泄露檢測方式

從Gartner預言至少90%的雲安全事故是因為用戶的錯誤配置導致，到CSPM成為熱門。AK泄露的檢測其實並不是一個全新的領域。但是現有對於雲平台AK泄露的手段主要還集中在檢測代碼泄露這一個途徑上。

將倉庫克隆到本地後就可以通過正則表達式來搜索，當時實際的掃描會更複雜一點，github承載的代碼已經非常龐大了。

這種檢測方式主要思想為：每次用戶commit代碼，添加新的文件或修改現有的文件時，密鑰泄漏檢測模塊就會被啟動。掃描被硬編碼到代碼中的Access Key和Access Secret字符串，將疑似AK的字符串發送給對應合作夥伴處進行確認，一旦合作夥伴匹配上真實的AK，即認為發生了AK明文泄露。隨後對AK的擁有者發送郵件告警。

按照這位老哥在這裡的測試，他故意提交包含AWS明文AK的代碼到github平台測試惡意攻擊者利用的時間。從提交代碼到收到AWS 平台發出的AK泄露告警郵件，中間時間間隔不到1分鐘。

而需要注意的是代碼提交6分鐘後，故意泄露的AK已經被3個攻擊者利用，而且產生了查詢S3存儲桶的日誌記錄。

之所以有6分鐘的延遲，還是因為github平台 commit 的事件訂閱流有5分鐘延遲。也就是說扣掉這5分鐘延遲，攻擊者和git平台幾乎同時發現用戶泄露的明文AK（扣除發郵件的時間，可能github平台稍快一點？不過重點還是在於攻擊手段之普遍）。

這種通過掃描程序員代碼中硬編碼AK的檢測技術，有點類似於密碼撞庫，其優點在於：

1、能在AK泄露的第一時間儘早發現，運氣好的話AK此時還未被真正利用，給AK擁有者留了一定的反應時間。但是鑒於惡意使用者的掃描速度，以及從收到通知到完全禁用AK中間的操作時間，這個時間還是不容樂觀，最好能通過SOAR工具進行自動化響應。

2、可檢測的AK種類不局限於單個平台。目前國內的阿里雲、騰訊雲、京東雲的AK都在github官方支持的範圍內。//docs.github.com/en/code-security/secret-scanning/secret-scanning-patterns#supported-secrets-for-partner-patterns

但是，這種方案的問題也很明顯：

對於非git平台上傳的代碼無法檢測。代碼管理平台那麼多，不是每個都集成了AK明文檢查。而且git平台的合作夥伴數量也很有限，並沒有覆蓋企業用戶的核心供應商，這是非常致命的問題。而且在越來越多的企業信息管理趨嚴，禁止員工將代碼上傳公共平台的情況下，這個方案的效果將比較有限。
內部人員被網絡釣魚、社會工程後泄露的AK無法及時發現。極有可能發一個免費領雲平台代金券的釣魚郵件就能收穫到一堆的AK，參照某學校發郵件領月餅的測試。
這種檢測方式無法檢測通過第三方系統暴露的AK，雲平台AK應用範圍極為廣闊，雲廠家在努力構建生態的同時，各種生態的合作夥伴水平參差不齊，容易成為整個環節的短板，一旦發生從第三方泄露的事件，極有可能又會產生對雲平台的信任危機，以及最終責任難以追溯。
最後還是跟第三方有關，用戶在開放AK給第三方時，如果沒有做到良好的訪問控制，不受監控的第三方可能濫用AK權限讀取和保存過多原本它不應該讀取的數據。

當然除了代碼庫掃描以外，還有其他的檢測方式，比如通過瀏覽器插件來掃描隱藏在跨源http請求中的AK，但這些方案目前都還不是企業級方案。

防止AK濫用的關鍵要素？

AK濫用的問題需要從平台方和用戶方兩邊共同解決。平台方需要提供足夠多的安全措施，而用戶則需要做好特權的管理。

1、默認安全：安全與開放和便利天然就是對立的，從雲平台的角度來說對於開放API的範圍以及開放的形式需要更加謹慎。高危的功能以什麼形式開放，執行權限和編輯權限是否同時對外開放等。應該經過充分的安全評估後，再決定對外開放的範圍。

2、分權。避免權限濫用最重要的就是做分權，這是API設計思想層面的改造。在給子賬號分配權限時，將API分為讀、寫操作能達到及格的水平。按API業務屬性和管理屬性區分會更適合。參照三權分立的思想，創建密鑰、重置主機密碼這類授權類的讀寫API，與資源列表、彈性配置等業務數據類的讀寫API分開。上傳任意自定義腳本與運行已經上傳腳本的權限分開。最安全的方式也是雲平台推薦的方式即刪除主AK，只保留子AK。

3、審計和檢測。對於AK的利用行為進行審計，記錄下請求發起方的角色、調用的記錄、讀取的實例範圍等內容。用以評估是否有AK在用戶不知情的情況下被調用。在這基礎上可以進一步基於行為進行調用風險的檢測，對於某些特定的API調用序列進行告警，高風險API的調用告警。這一點似乎還沒有哪一個雲平台做到足夠的重視。

4、訪問控制。平台方有義務提供足夠多的訪問控制手段，包括不限於單獨限制每一個AK訪問源IP、訪問時間段、可以訪問的資源集/資源id、可以調用的API的範圍。盡量從API權限層面縮減暴露面，減少不必要的訪問風險。不過這麼基礎的能力，目前卻只有華為雲做了，而且不能單獨對AK進行設置。限制key的使用範圍是非常有必要的，但是訪問控制不能解決所有的問題。因為高權限的key始終存在泄露的風險，除非高權限的key不存在。

這些都是在git平台泄露檢測以外，出於安全的主觀視角去考慮應該如何防止最高權限被濫用。當前主流雲平台可提供的檢測方案與理想還存在不小的差距，更別提還有很多雲平台連AK泄露檢測都還沒有。

對於企業用戶而言問題要更棘手一點，AK只是特權賬號的一種，分散在各級系統、產品、控制台中的特權賬號依舊無法得到有效管理。用戶也無法被動指望自己的所有供應商都提供足夠的特權管理手段。站在用戶的角度來看，特權賬號的管理必須是一個統一的產品，而不是鬆散的產品集合。但是目前並沒有一個產品能夠提供所有的保護手段。

哪些算特權賬號管理？

特權賬號廣泛分佈在企業內部的各個操作系統、應用程序中，而一旦發生雲平台AK這種頂級權限的泄露將危害無窮。按照權限級別，大致可以分為以下3類。

根據賬號的屬性分，大致可以分為4類。

對於特權賬號的管理，重點則在於對這4類賬號中的高特權的管理員賬號進行識別和管理。

如何做特權賬號管理？

特權管理的思路本質上與管理其他的資產沒有太大的區別。為了達到最佳效果，特權管理解決方案應該至少接入ATT&CK框架中常用到的本地賬號、域賬號、雲賬號。並且能夠做到：

能夠協助企業管理人員識別分散在內部各種系統中的特權賬號-包括root賬號、公用賬號、高權限管理員、SSH密鑰、證書、API key等等。
持續監控賬號狀態，包括賬號的權限變更、輪換記錄、使用範圍等信息。
根據賬號的權限等級和用途，將特權賬號的使用監控起來，審計特權賬號的所有使用記錄，包括特權賬號的登陸設備、訪問源、訪問目的、訪問時間、訪問數據範圍等信息，及時發發現對關鍵文件和目錄的未授權訪問和/或更改。
最好能根據賬號的使用記錄自動學習生成每個賬號的安全策略。再通過人的運營來補齊管理策略。
能對特權賬號的可疑行為進行告警。必要時並可以聯動其他設備，阻斷惡意的訪問行為。對可疑的活動進行阻斷或放行後，能持續更新賬號安全策略。

特權管理與堡壘機、IAM、零信任的關係？

堡壘機、IAM、零信任都屬於特權管理的一部分，在特權管理的實施層面提供支持。這些產品在各自領域都能發揮特權訪問控制的能力，應該利用他們自身的認證、審計和管控能力，保證特權管理策略落地。

而零信任平台則是在將來最有希望能夠成為統一大PAM的平台。只是目前的階段還掙扎在權限控制的大坑裡。