一個人的安全部之大話企業資料安全保護
*本文原創作者:liong03,本文屬FreeBuf原創獎勵計劃,未經許可禁止轉載
先簡單自我介紹一下,其實,我是一個資訊保安工程師,也是一個人的“安全部”……
近期看到一些朋友問資料安全保護怎麼弄,剛好為某企業簡單規劃過,很多前輩大佬都有介紹過資料安全,突然想用一種不一樣的姿勢來分享,通過一些文字條框再結合一些故事案例來思考。
目錄架構
一、設計思路
資料安全也是一個整體的體系,環環相扣,說說對資料安全保護的構思吧。一張圖勝過千言萬語,如果不行,那就三張:
資料安全防護六“不”曲:
全面的網路安全防護:
二、資料安全威脅
簡單做了一個數據安全威脅/風險腦圖:
三、規劃內容
3.1 訪問控制
涉及資料相關的訪問控制需要進行網路隔離、使用者進行細粒度授權、訪問進行認證,訪問控制涉及物件包括作業系統、資料庫、中介軟體、應用程式甚至網路裝置等訪問,還是簡單點說吧:
(一) 網路控制 ,主要通過 ACL來實現,對源地址、目的地址、源埠、目的埠和協議的訪問進行控制。
1)僅限運維技術負責人有許可權訪問生產伺服器及業務資料接觸到客戶資料, 應用系統的發版均需要經過運維人員配合才能進行發版 。
2)網路邊界或區域之間根據訪問控制策略設定訪問控制規則:
a. 網路邊界部署交換機和防火牆進行訪問控制策略;
b. 一些埠或ACL也可通過主機自帶防火牆進行訪問控制,訪問控制策略儘量採用就近原則;
c. 訪問控制策略採用白名單形式,預設情況下除允許通訊外受控介面拒絕所有通訊,如遠端登陸埠、資料庫埠、中介軟體埠進行訪問控制,儘量避免埠暴露非信任區域,可以通過VPN進行跨區域安全通訊。
網路訪問控制通常是最熟悉的人去弄,為了讓網路管理員知道配置的需求,一般都會弄一個模板表,當然事前還會進行一些調研,如:
(二) 許可權控制 ,基於角色的許可權訪問控制:
1)根據管理使用者的角色分配許可權,實現管理使用者的許可權分離,僅授予管理使用者所需的最小許可權,儘量在許可權之間形成相互制約的關係;(通常情況:僅公司技術負責人才有許可權訪問生產伺服器及業務資料庫接觸到客戶資料,關鍵資料均是加密後的密文,同時對資料的維護操作進行了監控與審計)。 2)由授權主體配置訪問控制策略,訪問控制策略規定主體對客體的訪問規則; 3)許可權控制實現檔案、資料庫表級、記錄或欄位級的訪問控制; 4)及時刪除或停用多餘的、過期的賬戶,避免共享賬戶的存在。如長期未登陸使用者使用系統,如超過三個月未登陸系統,應對帳號進行長期鎖定。
(三)防資料庫誤刪
1)不要在任何時候使用rm –rf * ,他會永久刪除檔案,建議給“rm”命令添加個“垃圾桶”,而不是永久刪除;
2)改寫rm命令,防止誤操作;
3) 刪除命令儘量指令碼化 ,並把將執行的指令碼命令、需要刪除的物件進行描述發給第三者稽核通過,資料庫操作時不要飲酒, 重要的是要開心 。
太枯燥了, 來個故事 吧(瞎編的):
1)某次資訊洩露事件應急分析,檢視日誌,發現某黑闊半夜不睡覺的,用了好幾個管理員賬號也包括已離職人員的,竟然成功登陸了某後臺,後臺裡面是有很多資訊資料的,整理了下日誌資訊:
詢問IP所屬本人,都不是他本人操作,然後對IP所在電腦進行病毒查殺,發現一堆可疑檔案:

丟到情報平臺分析,發現好幾個木馬病毒,其中竟然有與大名鼎鼎“冰河木馬”相似:
執行程式後,生成了1個小檔案和幾個看起來像系統程序,然後檢視 網路流量 發現連線了一個 國外 IP的8086埠 ,應該就是木馬遠控端的IP地址:

大致的分析結果:
1)黑闊放了馬在網上,然後某人下載後被遠控了; 2)中馬後,黑闊通過內網探測、瀏覽器或檢視郵件啥啥的,找到了某後臺的一些管理員賬號和密碼(當然了預設密碼); 3)某黑闊是喜歡半夜不睡覺的,登陸後臺進行了一些不可描述的資訊資料操作。
這裡有幾個問題:某IP為什麼能訪問後臺、那些賬號的許可權有多大、賬號密碼是怎麼洩露的、離職人員的賬號為什麼未清除、為什麼會下載木馬、下載了木馬為什麼沒有發現、為什麼有預設密碼。這裡就涉及一些 訪問控制 、 許可權控制、 病毒防範以及安全意識等等了,所以資料安全還是不能單獨來看。
有時候不抓,可能是因為
3.2 身份認證
(一)身份認證可分為兩種認證方式,單點登入和雙因素認證。
1. 單點登入:在多個業務系統中,使用者只需要登入一次就可以訪問所有相互信任的業務系統。使用單點登入,在帶來便利的同時也會引入新的安全風險:使用者仿冒和單點故障。以下措施可提高業務系統(如:某個工作臺,包含了OA、後臺登陸、HRM等多個應用系統)單點登陸的安全性和可用性:
a. 使用者訪問任何一個業務系統時,如果已經在單點登入伺服器中認證成功,那麼可以獲取對應的許可權,訪問對應的介面; b. 使用者如果在其中任何一個業務系統中點選“登出”按鈕後,那麼不能繼續訪問其他業務系統,如果訪問,必須重新登入; c. 使用者訪問任何一個業務系統時,如果尚未在單點登入伺服器中認證成功,那麼需要跳轉到單點登入介面,輸入使用者名稱密碼,校驗成功後,再回到原來的訪問介面。 d. 通過備份、冗餘、負載均衡、功能模組化以及提高處理效能,來防範單點故障。
2. 雙因素身份認證:解決只有授權使用者才能訪問系統平臺與服務的問題,主流的身份認證手段包括:靜態密碼、動態口令、密碼技術或生物技術等。
(二)某系統的雙因素身份認證:
a. 進行資金交易、修改個人資訊或修改密碼等敏感操作進行雙因子認證;
b. 對後臺使用者在登入時採用雙因子認證,如使用者名稱/密碼+手機簡訊驗證碼、使用者名稱/密碼+動態令牌或使用者名稱/密碼+Ukey等等;
c. 作業系統、資料庫、網路裝置登陸,採用堡壘機進行登陸統一認證和操作審計。
(三)介面認證
在工作中發現過不少介面方面的安全問題,比如介面暴露,可以任意呼叫,甚至修改傳輸包,解決方法可參考:
1. 身份認證,呼叫鑑權(資源範圍、操作許可權); 2. 通道加密傳輸,如使用SSL傳輸; 3. 重要資訊加密演算法進行加密後傳輸; 4. 新增token校驗,防止請求重放; 5. 將登陸資訊等重要資訊存放為SESSION,其他資訊如果需要保留,可以放在COOKIE中; 6. 設定IP白名單; 7. 一些資源管理器/應用元件(如:YARN&MR、Spark、Hive、Storm、ZooKeeper、Impala),應開啟認證機制。若資源管理器/應用元件支援關閉認證機制功能,需要提示,並建議在關閉認證機制功能時介面上給出告警提示。
介面認證方式不能一概而論,還要根據所在業務和場景進行設計…….
來個故事吧, 搭建測試環境,某簡訊資料流轉示意圖:
一、問題現狀:
a. 簡訊資訊明文傳輸,也未使用SSL傳輸;
b. 可以任意修改簡訊資訊;
c. 使用GET傳輸賬號、密碼及簡訊內容;
d. 簡訊伺服器是在簡訊企業那邊,也就是簡訊平臺與簡訊伺服器是進行了跨不信任網路傳輸。
二、存在的風險
外部人員呼叫此簡訊介面或直接使用以往的介面資訊內容,進行修改,然後:
a. 簡訊詐騙;
b. 簡訊釣魚;
c. 由於簡訊內容可以隨意修改,也可以隨意發給任何人,可以利用的方式太多,不一一例舉。
三、測試驗證
外網直接呼叫介面資訊後不需要驗證,直接篡改,再發送簡訊成功:
資訊解碼後:
ofollow,noindex" target="_blank">http://116.58.xxx.xxx:8080/xxx/xxxx.action?cdkey=xxx-xxx-xxx-xxx&password=011xxxx &phone=189xxxxyyyy&message=奧巴嘛先生您好,戶名:深圳xxxxxxxx公司,開戶行:xx銀行深圳xx支行,賬號:xx42710xxx101665,金額為:11342000000000000000.00元。如有疑問,請聯絡26146182614343xxxxx,如需要開啟上帝模式請聯絡吳證銘先生,電話:18888889999
成功收到簡訊:
3.3 資料加密&脫敏
(一)資料加密
在資料儲存和傳輸的資料提供加密功能,在兩個維度上提供資料安全保護:
1.機密性:採用加密的方式,確保只有擁有相應金鑰的使用者能夠訪問被保護的資料; 2.完整性:保證資訊在儲存和傳輸過程中不被檢視和修改,如:使用SSL傳輸,並對敏感資訊(如使用者名稱、密碼、重要ID值)使用加密演算法+動態token驗證。
在加密演算法、隨機數使用、加密協議的選擇時需要兼顧效能考慮,需要對資料進行區分,只針對需要加密的資料進行加密處理。
常見的加密演算法:
內容加密通常採用對稱加密演算法,資料庫中常用的加密演算法AES或MD5+鹽;
傳輸通道加密通常採用非對稱加密演算法,如:SSL加密資料通道採用RSA(非對稱加密)、VPN採用RSA、SSH key採用RSA。
注:
a. MD5加密其實是比較弱,一次MD5可以防止相對安全的密碼被逆向出明文,但可順推。 b. 單純的MD5不是很安全,但加個固定的鹽值,就能防止已有的彩虹表攻擊,多次MD5更是增加了碰撞攻擊的計算成本,但不能防止重放攻擊。 c. 在傳輸過程中加動態token驗證,就需要服務端加邏輯配置,可以防止重放攻擊,但不能防止中間人攻擊。 d. 傳輸通道加密可以比較有效防止中間人攻擊。
(二)祕鑰保護
加密技術都基於金鑰的安全基礎上,如果金鑰洩露,就失去了安全性。實際開發中,把金鑰直接寫在原始碼中,或者是配置檔案中,線上和開發環境配置相同的金鑰。這樣的話,不夠安全。
通過兩種方案改善:
1.金鑰和演算法放在一個獨立的伺服器上,甚至做成一個專用的硬體裝置,對外提供加密和解密服務,用程式通過呼叫這個服務,實現資料的加解密。這種方法由專人維護,金鑰不容易洩露,但是成本較高。 2.將加解密演算法放在應用系統中,金鑰則放在獨立伺服器中,為了提高金鑰的安全性,實際儲存時,金鑰被切分成數片,加密後分別儲存在不同儲存介質中,兼顧金鑰安全性的同時又改善了效能。
(三)資料脫敏
企業擁有的敏感資料,包括商業祕密、智慧財產權、關鍵業務資訊、業務合作伙伴資訊或使用者資訊等。其中涉及個人隱私的使用者個人資訊是資訊系統中最重要最廣泛的敏感資訊。
個人資訊:指以電子或者其他方式記錄的能夠單獨或者與其他資訊結合識別自然人個人身份的各種資訊,包括但不限於自然人的姓名、出生日期、身份證件號碼、個人生物識別資訊、住址、電話號碼等。
公民個人資訊:是指以電子或者其他方式記錄的能夠單獨或者與其他資訊結合識別特定自然人身份或者反映特定自然人活動情況的各種資訊,包括姓名、身份證件號碼、通訊通訊聯絡方式、住址、賬號密碼、財產狀況、行蹤軌跡等。
個人建議:針對敏感資料,採用技術措施限制對使用者資訊的訪問和使用。
1)確認需要檢視客戶個人資訊的後臺賬號,賬號許可權為業務必須的許可權; 2)查詢客戶個人資訊儘量僅能查詢脫敏後的資訊,如電話號碼、身份證號碼只保留前後4位,中間內容脫敏; 3)不管是請求校驗還是脫敏不要在前端進行,前端是不可靠的; 4)對於需要匯出客戶個人資訊的後臺賬號,確認是否必要匯出客戶個人的明文資訊, a) 如無必要建議禁止匯出客戶明文資訊; b) 若確實必要匯出客戶個人資訊的明文資訊,建議嚴格限制後臺賬號的使用人員範圍(使用人員、登入的源IP),並設定匯出的資訊範圍,如資訊條數、資訊時長(如最近1個月),所有對客戶資訊的查詢和匯出有日誌記錄。
脫敏實現之資料脫敏系統的原理及功能:
第一步:評估資料資產的安全級別,根據不同的安全級別以及應用的資料要求,制定不同的脫敏策略。
第二步:設定脫敏任務和觸發條件,觸發條件如時間、某資料處理過程的呼叫。
第三步:觸發脫敏條件後,脫敏系統將脫敏演算法的執行演算法包下發各節點實現資料脫敏。
資料脫敏可發生在兩個階段:
1)資料的採集階段,實現最基本、簡單的脫敏; 2)資料資產應用過程中,針對不同的應用進行實時的脫敏,應用脫敏相對較為複雜多變。
好吧,這裡也來點關於 祕鑰 和 脫敏問題的故事 吧,在這裡講故事,沒人打我,大佬們說話又好聽,超喜歡這裡的感覺。
故事1 、硬編碼
反編譯APP,找到加密方式AES/CBC/PKCS5Padding
找到祕鑰:b60449ddb29221c8

測試解密成功:

剛好還有個資訊遍歷漏洞,現在有了祕鑰,就可進行遍歷了,自定義ID值,然後用祕鑰加密,再去遍歷,可遍歷出其他人的ID值對應的使用者資訊:

故事2 、前端脫敏
比如下面這種,看起來是脫敏的,但通過 中間抓包攔截就會發現完整資訊 ,當然了下面這個圖不只是前端脫敏問題,其實也是一個遍歷+前端脫敏問題,可通過遍歷獲取其他人完整的銀行卡號和餘額資訊:
還有一種場景,一些網站首頁會展示一些客戶資訊,當然展示時看到的重要資訊(如:姓名、電話、姓名、身份證)是進行脫敏了,但通過 抓包攔截就可以獲取到完整資訊 :
3.4 容災備份/恢復
(一)容災分類:
資料級容災:建立一個異地的資料系統,該系統是本地關鍵應用資料的一個可用複製。在本地資料及整個應用系統出現災難時,至少在異地儲存有一份可用的關鍵業務的資料。該資料可以是與本地生產資料的完全實時複製,也可以比本地資料略微落後,但一定是可用的。
應用級容災:在資料級容災基礎上,在異地建立一套與本地生產系統相當的備份環境,包括主機、網路、應用、IP等資源均有配套,當本地系統發生災難時,異地系統可以提供完全可用的生產環境。
(二)備份策略
備份策略是備份方案核心部分,要按照資料重要程度、資料管理方式制定不同的備份策略。備份策略包括:備份物件、備份方法、備份頻率、儲存時限等。
如:每天資料泵備份兩次,RMAN備份一次,備份儲存雙份,一份放本地,一份放儲存。
1) 日常備份 每日進行三次備份,資料泵每天兩次備份, RMAN每天一次備份。
a. 資料泵每天備份2次,時間為中午xx點xx分,晚上xx開始
b. RMAN晚上xx點xx分,凌晨xx點;
c. 資料泵備份完成後會傳輸到指定儲存裝置,本地存一份,儲存存一份,共儲存兩份,保證系統發生故障時能夠快速恢復。
d. 在進行資料表的截斷、刪除之前,進行備份,避免誤操作之後的措手不及。
2) 月備份
a. 每月月末對所有資料檔案進行離線備份,拷貝到備份介質中,並另行備份一份存放至xx。
3) 臨時備份
a. 臨時備份採用資料泵備份。
4) 備份儲存時限
a. 資料泵備份儲存一個月備份,RMAN備份儲存x天。
(三)備份執行和恢復演練
1) 必須定期巡檢和維護備份系統及時發現並排除故障隱患,保證備份系統的正常運轉。 2) 對於核心系統和關鍵系統,每半年進行備份介質可用性檢查,確保庫存介質可用。 3) 必須保證核心系統每季度進行的恢復測試順利完成,檢查備份可用性。關鍵系統至少每半年進行恢復測試。 4) 需要實施系統恢復時要按照備份恢復管理流程申報、審批,按照備份恢復方案進行系統恢復。 5) 個人做好對自己的資料檔案根據需要進行備份,但必須做好備份的資訊保安保護工作。 6) 資料備份應遵循“內容完備、安全保密、落實到人、定點存放、定期檢驗”的工作原則,切實保證備份資料的機密性、完整性和可用性。
這裡真沒什麼故事好講,百度一下會更豐富。還是來個簡單的容災/備份的網路構想圖吧:
3.5 安全審計
儘量通過部署日誌審計系統,實時監視網路各類操作行為及攻擊資訊。根據設定的規則,智慧的判斷出各種風險行為,對違規行為進行報警等。
日誌的分類包括:應用系統日誌、作業系統日誌、資料庫日誌、網路裝置日誌和資訊保安裝置日誌。每一類日誌記錄中應記錄以下基本內容:事件發生的日期和時間、事件描述,操作者資訊,匯入、匯出、成功和失敗操作。
(一)應用系統日誌
客戶訪問入口網站時,應對登入行為、業務操作以及系統執行狀態進行記錄與儲存,保證操作過程可追溯、可審計。並確保業務日誌資料的安全。日誌記錄應滿足如下安全要求:
1. 記錄關鍵業務操作日誌:應記錄關鍵業務操作的日誌,例如登入成功與失敗、關鍵業務辦理、敏感資料查詢、敏感資料匯入與匯出等。 2. 記錄應用系統執行日誌:應記錄應用系統的啟停、異常、資源使用情況等。 3. 敏感資料模糊化:禁止在業務日誌中記錄服務密碼等敏感資訊。如果確實需要記錄敏感資訊,則應進行模糊化處理。 4. 防止業務日誌欺騙:如果在生成業務日誌時需要引入來自非受信源的資料,則應進行嚴格校驗,防止欺騙攻擊。 5. 業務日誌安全儲存與訪問:禁止將業務日誌儲存到網頁目錄下,確保業務日誌資料的安全儲存並嚴格限制業務日誌資料的訪問許可權。應對業務日誌記錄進行簽名來實現防篡改。日誌記錄應線上至少儲存半年,離線儲存1年。
應用系統日誌分析,不同的系統日誌特徵不一樣,所以也不好去介紹(有機會再寫寫安全應急),在做應急分析時,有時候是需要去模擬操作分析出操作特徵,再去對日誌進行分析。
好吧,還是 講個故事 吧:
1)模擬登陸操作,獲取登陸成功的跳轉資訊:
GET /admin/basics/mainHTTP/1.1
Host: xxxx.com
xxxxxxxxx…………………..
Referer: https://xxxx.com/admin/manage/login
Cookie: PHPSESSID=xxxxxxxxxxxxxxxxxxxxxx
Connection: close
2)然後篩選日誌中/admin/basics/main,發現某黑闊也是半夜不睡覺的,成功登陸了某後臺:
查看了下IP是外省浙江的,當然了這種IP基本不是真實源,不會用代理的黑闊不是好黑闊。
3)看看他在幹嗎
在看page=1和page=2等等
測試了下這個page=是什麼,他大爺,在查其他使用者個人資訊啊(勿驚,問題不大,只是故事,大家都是做安全的,混口飯吃不容易):
(二)WINDOWS 系統日誌
做日誌審計,前提是要開啟相應的日誌審計策略,預設的日誌資訊是很少的,開啟日誌審計時還需要注意,如果全部開啟,日誌資訊可能巨龐大,會有很多無用日誌,所以最好是先確定是需要開啟哪些審計策略。
關於日誌資訊如何審計,審計哪些,這裡做了一個簡單的win2008常用審計事件ID(win7與win2008的日誌事件ID沒什麼區別):
手工檢視日誌:
1)這是在爆破賬號密碼啊:
2)訪問445埠的篩選:

(三)UNIX 系統日誌
收集的一些日誌特徵:
(四)Juniper 防火牆日誌
收集的一些日誌特徵:
(五)交換機/ 路由器
收集的一些日誌特徵:
為什麼這裡沒有介紹資料庫的日誌呢,因為一旦開啟資料庫的審計策略,資料庫效能將 產生巨大影響 ,因此建議只使用預設的審計策略。
資料庫日誌審計,可以參考如下:
1. 部署堡壘機進行運維管理,堡壘機日誌對操作者所有操作行為進行日誌記錄; 2. 旁路部署資料庫審計產品,並實現使用者IP、應用伺服器IP與資料庫IP三層關聯,對資料庫的每條資料庫命令的執行進行記錄; 3. 至於裝置部署以及策略配置位置,建議就近原則。
(六)IT 運維管理
通過專業的運維管理系統進行運維監控,對伺服器的CPU、硬碟、記憶體、網路等資源的使用情況,以及系統的服務水平進行檢測和告警。某卡的軟體可以實現這些功能,這裡就不放圖了以免廣告嫌疑。
(七)介面安全審計
介面的呼叫監控:限制訪問次數、最大連線量,介面流量實時監控、異常流量告警,如簡訊介面、提現介面、充值介面等等;
有時能看到一些爬蟲、簡訊炸彈、CC攻擊等,比如這種半夜不睡覺的黑闊,在換著IP刷簡訊,如果讓他刷上一晚:
注:比如某系統已經停用了,有漏洞也不打算補了,反正都不用了,但某天系統又重新開啟還不通知安全,這時技術、管理已經失效了,所以還有監控這一道防線。
(八)日誌保護
1. 關鍵資訊基礎設施的運營者在運營中收集和產生的個人資訊和重要資料應當在境記憶體儲; 2. 對審計程序進行保護,防止未經授權的中斷; 3. 審計記錄進行保護,定期備份,避免受到未預期的刪除、修改或覆蓋等,如:審計記錄備份到日誌伺服器; 4. 日誌資訊儲存至少6個月。
3.6 全面防護
設計安全防護框架,可能也不盡如人意。一圖勝千言,如果不行,那就兩張:
四、最後
最後不想多說,文章內容僅是個人工作生活中的一些經驗和想法,不同的角度會有不同的觀點。
文章內容也還有不足,主要是細說可以展開成很大的篇幅。幸好還是堅持把它寫完……
*本文原創作者:liong03,本文屬FreeBuf原創獎勵計劃,未經許可禁止轉載