En 400-6655-581
5
返回列表
> 資源中心 > 文章>產(chǎn)品>PAM(特權(quán)訪問)> 身份安全 | 特權(quán)管控難題之應用系統(tǒng)特權(quán)

身份安全 | 特權(quán)管控難題之應用系統(tǒng)特權(quán)

文章

2020-10-23瀏覽次數(shù):173

特權(quán)賬號泛指企業(yè)IT環(huán)境中具有高級別權(quán)限、共享使用的賬號,存在于操作系統(tǒng)、數(shù)據(jù)庫、網(wǎng)絡設備、安全設備、應用系統(tǒng)、API接口中。這些特權(quán)賬號是打開企業(yè)系統(tǒng)、數(shù)據(jù)大門的關(guān)鍵鑰匙,一旦泄露,企業(yè)將面臨數(shù)據(jù)泄露、數(shù)據(jù)丟失、系統(tǒng)宕機等災難性損失。因此,特權(quán)賬號往往是黑客攻擊的頭號目標,據(jù)權(quán)威機構(gòu)統(tǒng)計,80%的數(shù)據(jù)泄露都與特權(quán)賬號有關(guān)。守住特權(quán)賬號,就是守住企業(yè)資產(chǎn)的最后一道防線。

為了守住企業(yè)資產(chǎn)的最后一道防線,企業(yè)通常都會標配堡壘機、特權(quán)賬號管理系統(tǒng)等安全產(chǎn)品。但脫庫(被黑)、刪庫、數(shù)據(jù)泄露等安全運維事件仍是頻頻發(fā)生。

 

 
 
原因可從以下幾個維度分析

 

 

01
 
防護的全面性

堡壘機、特權(quán)賬號管理系統(tǒng)等主流特權(quán)運維安全產(chǎn)品能解決的是運維賬號、特權(quán)賬號的合規(guī)性授權(quán)、統(tǒng)一入口、安全審計問題。但這里注意的是他們所能管控的運維賬號、特權(quán)賬號,僅涵蓋了操作系統(tǒng)、數(shù)據(jù)庫、網(wǎng)絡設備、安全設備等IDC設備的特權(quán)。

 

02
 
誰會擁有特權(quán)

主機管理員、DBA、網(wǎng)絡管理員、業(yè)務系統(tǒng)主管、應用系統(tǒng)廠商實施人員、應用系統(tǒng)IT管理員、API接口代碼等等;這里我們能夠借助于堡壘機、特權(quán)賬號管理系統(tǒng)等實現(xiàn)特權(quán)的集中管理、集中授權(quán)發(fā)放及回收、過程訪問控制等從而達到事前、事中管控的目標,但所能管控的同樣有限,僅有主機管理員、DBA、網(wǎng)絡管理員。

  

03
 
特權(quán)的密碼

我們可以借助于特權(quán)賬號管理系統(tǒng)實現(xiàn)對主機、數(shù)據(jù)庫、網(wǎng)絡設備、安全設備等整個IDC基礎(chǔ)設施的資源進行定期修改密碼、密碼申請、公私鑰生命周期管理,但我們的應用系統(tǒng)、API接口中的特權(quán)密碼卻因代碼編碼限制、業(yè)務管理限制、應用系統(tǒng)廠商限制,無法對超大權(quán)限的管理賬號、授權(quán)賬號做密碼的定期修改。

 

04
 
安全審計的全面性

目前市面上比較成熟的堡壘機、特權(quán)賬號管理產(chǎn)品都可以在主機、數(shù)據(jù)庫、網(wǎng)絡設備、安全設備等整個IDC基礎(chǔ)設施層面實現(xiàn)事后全過程的監(jiān)控視頻審計。但我們的應用系統(tǒng)、API接口中的特權(quán)就僅能憑借應用系統(tǒng)本身的日志進行事后審計。

 

 

 
 
當下政策對其要求
 

 

01
 
ISO27001相關(guān)條款

A11.2.2 特權(quán)管理:特殊權(quán)限管理,應限制和控制特殊權(quán)限的分配及使用;

A11.5.2 用戶標識:所有用戶應有唯一的、專供其個人使用的標識符(用戶ID)

應選擇一種適當?shù)蔫b別技術(shù)證實用戶所宣稱的身份;

A10.10.1要求組織必須記錄用戶訪問、意外和信息安全事件的日志,并保留一定期限,以便安全事件的調(diào)查和取證;

A10.10.4要求組織必須記錄系統(tǒng)管理和維護人員的操作行為;

A15.1.3 明確要求必須保護組織的運行記錄;

A15.2.1則要求信息系統(tǒng)經(jīng)理必須確保所有負責的安全過程都在正確執(zhí)行,符合安全策略和標準的要求。

 

02
 
等級保護2.0相關(guān)條款

8.1.4.1 身份鑒別:應對登錄的用戶進行身份標識和鑒別,身份標識具有唯一性;

8.1.4.2 訪問控制:應授予管理用戶所需的最小權(quán)限,實現(xiàn)管理用戶的權(quán)限分離;

8. 1.5. 1 系統(tǒng)管理:應對系統(tǒng)管理員進行身份鑒別,只允許其通過特定的命令或

操作界面進行系統(tǒng)管理操作,并對這些操作進行審計;

8.1.4.3 安全審計:應啟用安全審計功能,審計覆蓋到每個用戶,對重要的用戶

行為和重要安全事件進行審計;

8.1.5.2 審計管理:應對審計管理員進行身份鑒別,只允許其通過特定的命令或

操作界面進行安全審計操作,并對這些操作進行審計;

   

通過以上4個維度及政策面上我們可以看出,特權(quán)的管理需要在身份鑒別、權(quán)限分離、訪問控制、授權(quán)管理、密碼管控、安全審計等維度進行全訪問的集中管控。

   要想管控好應用系統(tǒng)的特權(quán),其核心在于管控應用系統(tǒng)特權(quán)賬號的身份鑒別、 授權(quán)發(fā)放回收控制、密碼管控、安全審計。

 
 
解決應用系統(tǒng)的特權(quán)管控的幾個維度
 

 

01
 
【實名制問題-身份鑒別】

應用系統(tǒng)的出廠內(nèi)置管理員賬號admin/sysadmin通常并不具備用戶實名制唯一標識的特質(zhì),通常是會被應用負責人或廠商運維人員掌管著賬號密碼。在使用過程中由使用者人為輸入賬號口令進行登錄。(如圖1所示)解決的關(guān)鍵借助于一個特殊的平臺作為跳板,能讓用戶通過自己的個人賬號進行登錄認證,成功后再通過這個特殊的平臺訪問應用系統(tǒng)的特權(quán),這樣就可以解決實名制問題(如圖2所示)

  

  

          

 

 

02
 
【密碼擴散問題-特權(quán)密碼管控】

特權(quán)賬號在使用過程中應用負責人通常會將賬號、口令轉(zhuǎn)告知第三人。這么以來管理員賬號的密碼就會不經(jīng)意地傳給第三個、第四個...導致特權(quán)賬號密碼擴散的風險,所以我們將通過密碼定期修改、密碼自動代填或基于票據(jù)的方式由中轉(zhuǎn)系統(tǒng)自動完成應用系統(tǒng)的特權(quán)登錄過程,避免使用者因登錄需要而知曉密碼。

 

 

03
 
【特權(quán)授權(quán)問題-特權(quán)發(fā)放自動收回】

通常企業(yè)中申請使用特權(quán)賬號的方式:管理員代為輸入口令、郵件申請、工單申請、微信、釘釘?shù)?。那么這些方式的通病就是授權(quán)的過程不嚴謹導致申請記錄無從查起;授權(quán)之后權(quán)限不能及時主動的收回。為了避免這種情況多數(shù)企業(yè)都會將所有的權(quán)限相關(guān)與流程工單系統(tǒng)進行結(jié)合,如OA、BPM等,用戶通過流程工單走線上的特權(quán)申請,并備注使用的周期。工單由相關(guān)干系人完成審批后由中轉(zhuǎn)系統(tǒng)自動完成自然人(特權(quán)申請人)與應用系統(tǒng)特權(quán)的授權(quán)映射過程。用戶登錄中轉(zhuǎn)系統(tǒng)即可查閱自己的應用特權(quán)權(quán)限。最后在特權(quán)申請時間結(jié)束后中轉(zhuǎn)系統(tǒng)自動完成自然人(特權(quán)申請人)與應用系統(tǒng)特權(quán)的授權(quán)關(guān)系解除操作,那么用戶也是無法再次訪問特權(quán)賬號的。