在企業雲上安全中，除了服務器內部漏洞風險和DDOS攻擊等外部攻擊風險外，還有一種風險是內部用戶風險，由於這類風險往往是由內部用戶的異常操作造成的，且內部用戶的操作在安全檢測中天然擁有高可靠性，因此具有極高的隱蔽性，在真正發生安全事件後往往引起巨大危險。
騰訊雲安全運營中心中帶有的UBA模塊，即用戶行爲分析模塊，在雲上安全中可幫助企業做好用戶安全的管理，該模塊主要基於騰訊雲用戶在控制檯的相關操作記錄以及使用雲進行自動化操作的相關記錄，進行用戶安全性分析，並提示運維人員及時處理相關風險。
由於雲後臺只是粗略記錄了用戶相關操作的事件類型，因此無法僅通過用戶的單條操作記錄進行風險判定，只有在某些層面上的統計量才具有一定意義。UBA模塊正是在這種背景下，提出了基於風險場景的用戶安全檢測機制。下面我們將圍繞用戶安全檢測機制的三大模塊及其應用場景，爲大家介紹如何利用雲原生SOC降低內部用戶操作風險。
檢測機制由三個模塊構成：用戶身份識別模塊、檢測閾值生成模塊以及場景檢測模塊。
一、用戶身份識別模塊
在實際工作中，不同子用戶擔任的角色不一樣，涉及的權限與工作量也必然不一樣，爲了方便用戶自查以及後續模塊的利用，需要對用戶進行身份的識別。目前，一個用戶的身份由四個身份因子組成，分別爲：是否高風險、是否api、是否人類以及操作密度。具體含義如下所示：
- 是否高風險：該用戶在14天內的操作記錄是否涉及高風險權限（用戶權限提升、資產高風險權限修改）
- 是否api：該用戶在14天內的操作記錄是否存在規律性
- 是否人類：該用戶除去規律性操作外是否存在其他操作
- 操作密度：該用戶7天內的操作密度。由7天內每天操作記錄總數的四分位數得出，具體規則如下所示：
| min | 25% | 50% | 75% | max | 操作密度 |
| <200 | <200 | <200 | <200 | <200 | 0 |
| >=200 | — | — | — | — | 1 |
| — | >=200 | — | — | — | 2 |
| — | — | >=200 | — | — | 3 |
| — | — | — | >=200 | — | 4 |
| — | — | — | — | >=200 | 5 |
| — | — | — | — | =0 | 6 |
根據得到的用戶各身份因子，可以得到用戶的具體身份，規則如下所示：
| 是否高風險 | 是否api | 是否人類 | 操作密度 | 身份 |
| — | — | — | 6 | silent_user |
| 是 | 是 | — | <=2 | high_dense_api_ops |
|
否 |
是 | 是 | <=2 | high_dense_api_user |
| 否 | 是 | 否 | <=2 | high_dense_api_pure |
| 是 | 否 | — | <=2 | high_dense_ops |
| 否 | 否 | — | <=2 | high_dense_user |
| 是 | 是 | — | >2 | normal_dense_api_ops |
| 否 | 是 | 是 | >2 | normal_dense_api_user |
| 否 | 是 | 否 | >2 | normal_dense_api_pure |
| 是 | 否 | — | >2 | normal_dense_ops |
| 否 | 否 | — | >2 | normal_dense_user |
| 是 | 是 | — | =0 | high_risk_api_ops |
| 否 | 是 | 是 | =0 | low_dense_api_user |
| 否 | 是 | 否 | =0 | low_dense_api_pure |
| 是 | 否 | — | =0 | high_risk_ops |
| 否 | 否 | — | =0 | low_dense_user |
在獲取用戶身份後，管理員可以審覈用戶身份是否符合預期，並及時處理不符合預期的用戶。其中high_risk_api_ops和high_risk_ops用戶在一天記錄量低於200的情況下進行了高風險操作，需要覈查是否安全。
二、檢測閾值生成模塊
閾值即一個用戶在某個場景下統計量的預期最大值，但是不同身份的用戶的預期值是不一樣的，例如一個運維用戶和一個普通觀察用戶的預期值不一樣，運維用戶根據工作量和負責事務的不同預期最大值也不一樣。因此閾值生成模塊的目的是根據該用戶歷史的數據以及用戶身份自動生成用戶在每個場景下的檢測閾值。
本模塊在閾值生成中遵循一個假設，即用戶的操作數量符合正態分佈，並按照置信度及一定的規則取合適的值作爲最終的檢測閾值，具體的生成規則如下所示：
（一）用戶權限提升
（二）資產高風險權限修改
（三）用戶權限遍歷
三、場景檢測模塊
目前uba模塊已有的風險場景有以下四種：用戶權限提升、資產高風險權限修改、用戶權限遍歷、新用戶高危操作。
（一）用戶權限提升
該類場景聚焦於權限提升類的操作事件，例如綁定某一策略到特定用戶。這一類操作事件在實際工作中基本由運維人員操作產生且大多是經由主賬號操作產生。若一個子賬號在短期內進行的權限提升類操作次數異常，則該用戶可能被盜號或操作行爲不當，均需告知用戶及時排查處理。
基於以上需求，用戶權限提升場景的檢測邏輯如下：
在上述檢測邏輯中，將主賬號和子賬號區分，對於主賬號的風險評分更加寬鬆。
（二）資產高風險權限修改
該類場景聚焦於資產高風險權限修改類的操作事件，例如修改安全組規則。這一類操作事件在實際工作中基本由運維人員操作產生，但是可能存在運維人員爲了方便工作，爲自己的子賬號提權後也進行了該類操作。由於目前未對子賬號身份作進一步劃分，因此未對這類子賬號做特殊處理。這類場景與用戶權限提升場景的檢測邏輯類似，如下所示：
因爲在某些業務場景中，可能存在需要週期性修改規則的需求，因此在上述檢測邏輯中，利用了時間序列異常檢測算法進行了中間處理，目的爲排除這種週期性的影響。
（三）用戶權限遍歷
該類場景聚焦於用戶在單位時間內涉及的操作事件種類數。結合歷史數據以及實際工作需求來看，一個行爲正常的子賬號在單位時間內操作事件的種類必然不會太多，若子賬號在一定時間段內執行的操作種類數超過預警值，則可以說明該類用戶存在試探性操作的可能性，可能是對業務不熟悉或者黑客入侵。
基於以上需求，用戶權限遍歷的場景檢測邏輯如下所示：
（四）新用戶高危操作
該類場景關注的是用戶在被創建後的一小時內是否存在風險。在實際工作環境中，一個低風險的新用戶在被創建後一般不會進行大量高風險操作，而是會較小心的查看一些數據，例如查看服務器流量情況，這類操作本身就是低風險的，而且涉及的事件類型也比較固定。因此，首先對所有的事件類型進行粗略的風險評估，抽取其中高風險的事件類型，然後重點關注用戶新入後的操作記錄中涉及這些高風險事件類型的操作。若高危操作過多，則該新用戶可能爲誤操作或爲黑客創建。
基於以上需求，新用戶高危操作的場景檢測邏輯如下所示：
四、實際案例解析
在UBA模塊正式上線運行後，騰訊雲安全運營中心也陸續接到了一些客戶關於告警的反饋，其中來自某互聯網公司的反饋引起了安全人員的注意。該客戶反饋其名下一個子用戶存在用戶權限遍歷告警，還在UBA概覽頁的登錄來源地圖中發現了來自境外的登陸信息。
在排查用戶權限遍歷告警中，我們發現該子用戶當天進行了大量的存儲桶相關操作以及一些權限檢查操作，因操作種類數超過了場景檢測閾值，因此進行了相應告警。之後又分析了用戶操作行爲日誌中來自境外的操作記錄，發現這些操作記錄均屬於API調用。調查到這裏，安全人員發現了該事件的嚴重性，在與相關人員溝通後，確認到該子用戶的SecretKey已經泄漏，客戶確認該子用戶操作與以往不符，隨即進行了一系列響應和補救措施，防止更嚴重的安全事件發生。在確定風險來源後，除了刪除已經泄漏的SecretKey外，在安全人員的建議下，該用戶還開啓了安全運營中心的泄漏檢測模塊，防止以後類似的事情發生。