在企業(yè)云上安全中，除了服務(wù)器內(nèi)部漏洞風(fēng)險和DDOS攻擊等外部攻擊風(fēng)險外，還有一種風(fēng)險是內(nèi)部用戶風(fēng)險，由于這類風(fēng)險往往是由內(nèi)部用戶的異常操作造成的，且內(nèi)部用戶的操作在安全檢測中天然擁有高可靠性，因此具有極高的隱蔽性，在真正發(fā)生安全事件后往往引起巨大危險。
騰訊云安全運(yùn)營中心中帶有的UBA模塊，即用戶行為分析模塊，在云上安全中可幫助企業(yè)做好用戶安全的管理，該模塊主要基于騰訊云用戶在控制臺的相關(guān)操作記錄以及使用云進(jìn)行自動化操作的相關(guān)記錄，進(jìn)行用戶安全性分析，并提示運(yùn)維人員及時處理相關(guān)風(fēng)險。
由于云后臺只是粗略記錄了用戶相關(guān)操作的事件類型，因此無法僅通過用戶的單條操作記錄進(jìn)行風(fēng)險判定，VPS租用，只有在某些層面上的統(tǒng)計量才具有一定意義。UBA模塊正是在這種背景下，服務(wù)器租用，提出了基于風(fēng)險場景的用戶安全檢測機(jī)制。下面我們將圍繞用戶安全檢測機(jī)制的三大模塊及其應(yīng)用場景，為大家介紹如何利用云原生SOC降低內(nèi)部用戶操作風(fēng)險。
檢測機(jī)制由三個模塊構(gòu)成：用戶身份識別模塊、檢測閾值生成模塊以及場景檢測模塊。
一、用戶身份識別模塊
在實際工作中，不同子用戶擔(dān)任的角色不一樣，涉及的權(quán)限與工作量也必然不一樣，為了方便用戶自查以及后續(xù)模塊的利用，需要對用戶進(jìn)行身份的識別。目前，一個用戶的身份由四個身份因子組成，分別為：是否高風(fēng)險、是否api、是否人類以及操作密度。具體含義如下所示：
是否高風(fēng)險：該用戶在14天內(nèi)的操作記錄是否涉及高風(fēng)險權(quán)限(用戶權(quán)限提升、資產(chǎn)高風(fēng)險權(quán)限修改)
是否api：該用戶在14天內(nèi)的操作記錄是否存在規(guī)律性
是否人類：該用戶除去規(guī)律性操作外是否存在其他操作
操作密度：該用戶7天內(nèi)的操作密度。由7天內(nèi)每天操作記錄總數(shù)的四分位數(shù)得出，具體規(guī)則如下所示：
根據(jù)得到的用戶各身份因子，可以得到用戶的具體身份，規(guī)則如下所示：
在獲取用戶身份后，管理員可以審核用戶身份是否符合預(yù)期，并及時處理不符合預(yù)期的用戶。其中high_risk_api_ops和high_risk_ops用戶在一天記錄量低于200的情況下進(jìn)行了高風(fēng)險操作，需要核查是否安全。
二、檢測閾值生成模塊
閾值即一個用戶在某個場景下統(tǒng)計量的預(yù)期最大值，但是不同身份的用戶的預(yù)期值是不一樣的，例如一個運(yùn)維用戶和一個普通觀察用戶的預(yù)期值不一樣，運(yùn)維用戶根據(jù)工作量和負(fù)責(zé)事務(wù)的不同預(yù)期最大值也不一樣。因此閾值生成模塊的目的是根據(jù)該用戶歷史的數(shù)據(jù)以及用戶身份自動生成用戶在每個場景下的檢測閾值。
本模塊在閾值生成中遵循一個假設(shè)，即用戶的操作數(shù)量符合正態(tài)分布，并按照置信度及一定的規(guī)則取合適的值作為最終的檢測閾值，具體的生成規(guī)則如下所示：
(一)用戶權(quán)限提升
(二)資產(chǎn)高風(fēng)險權(quán)限修改
(三)用戶權(quán)限遍歷
三、場景檢測模塊
目前uba模塊已有的風(fēng)險場景有以下四種：用戶權(quán)限提升、資產(chǎn)高風(fēng)險權(quán)限修改、用戶權(quán)限遍歷、新用戶高危操作。
(一)用戶權(quán)限提升
該類場景聚焦于權(quán)限提升類的操作事件，例如綁定某一策略到特定用戶。這一類操作事件在實際工作中基本由運(yùn)維人員操作產(chǎn)生且大多是經(jīng)由主賬號操作產(chǎn)生。若一個子賬號在短期內(nèi)進(jìn)行的權(quán)限提升類操作次數(shù)異常，則該用戶可能被盜號或操作行為不當(dāng)，均需告知用戶及時排查處理。
基于以上需求，用戶權(quán)限提升場景的檢測邏輯如下：
在上述檢測邏輯中，將主賬號和子賬號區(qū)分，對于主賬號的風(fēng)險評分更加寬松。
(二)資產(chǎn)高風(fēng)險權(quán)限修改
該類場景聚焦于資產(chǎn)高風(fēng)險權(quán)限修改類的操作事件，例如修改安全組規(guī)則。這一類操作事件在實際工作中基本由運(yùn)維人員操作產(chǎn)生，但是可能存在運(yùn)維人員為了方便工作，為自己的子賬號提權(quán)后也進(jìn)行了該類操作。由于目前未對子賬號身份作進(jìn)一步劃分，因此未對這類子賬號做特殊處理。這類場景與用戶權(quán)限提升場景的檢測邏輯類似，如下所示：
