在大數(shù)據(jù)平臺混久了你會發(fā)現(xiàn)一個特別現(xiàn)實的問題數(shù)據(jù)產(chǎn)品上線前大家問得最多的往往不是這個指標算得對不對而是這個產(chǎn)品安全嗎。我最近連續(xù)被幾個朋友問到大屏和API服務(wù)的安全加固方案才意識到很多團隊的所謂安全策略其實還停留在服務(wù)器設(shè)個密碼、接口加個鑒權(quán)的階段。數(shù)據(jù)產(chǎn)品是個挺特殊的節(jié)點——它一頭連著數(shù)倉里的明細數(shù)據(jù)另一頭連著幾十上百個業(yè)務(wù)用戶中間還掛著調(diào)度任務(wù)和BI工具任何一個環(huán)節(jié)出現(xiàn)漏洞泄露的就不是一條SQL而是一整片數(shù)據(jù)資產(chǎn)。這篇文章就把我在數(shù)據(jù)產(chǎn)品安全加固上踩過的坑、驗證過的方案、以及最后沉淀下來的一套完整策略一條線給你捋清楚。1. 先搞清楚我們嘴里的數(shù)據(jù)產(chǎn)品安全策略究竟要給誰做在談安全策略之前必須先統(tǒng)一一個概念到底什么算數(shù)據(jù)產(chǎn)品。我發(fā)現(xiàn)很多團隊把數(shù)據(jù)產(chǎn)品理解成一個報表平臺或者一個數(shù)據(jù)門戶然后安全策略就照著Web應(yīng)用的模板抄一遍。這是最要命的起點錯誤。1.1 三類主流數(shù)據(jù)產(chǎn)品形態(tài)安全側(cè)重點完全不同我自己習慣把數(shù)據(jù)產(chǎn)品分成三類每類的暴露面和安全側(cè)重點差異很大可視化分析型產(chǎn)品典型如數(shù)據(jù)大屏、自助分析BI、報表系統(tǒng)。這類產(chǎn)品直接面向業(yè)務(wù)人員和領(lǐng)導層特點是展示邏輯復雜、前端交互多、動不動就全屏投屏到會議室。它的安全風險集中在展示層面的裸奔比如大屏被拍照外傳、報表導出到本地再轉(zhuǎn)發(fā)、前端接口被繞過直接拉數(shù)。API數(shù)據(jù)服務(wù)型產(chǎn)品通過接口對外提供指標查詢、數(shù)據(jù)訂閱、模型預(yù)測等能力。這類產(chǎn)品的用戶可能是內(nèi)部系統(tǒng)、移動端App、合作伙伴的外部系統(tǒng)。安全風險集中在身份認證、接口鑒權(quán)、限流防刷、參數(shù)注人這幾塊一旦鑒權(quán)被繞過去黑客拿到的就是完整的數(shù)據(jù)通道。數(shù)據(jù)訂閱與分發(fā)型產(chǎn)品定時或事件驅(qū)動地把處理好的數(shù)據(jù)集推送出去比如離線同步、郵件報表、數(shù)倉到業(yè)務(wù)庫的導出任務(wù)。很多團隊壓根不把它當產(chǎn)品看但它同樣面向具體用戶、輸出具體數(shù)據(jù)。這類產(chǎn)品的安全問題最容易被忽視往往是HDFS目錄權(quán)限開著、FTP賬號是通用賬號、數(shù)據(jù)落地之后沒人管。如果你連自己的數(shù)據(jù)產(chǎn)品屬于哪一類都沒分清楚后面的安全策略就是無根之萍。1.2 為什么不能直接套平臺的整體安全方案很多公司其實有大數(shù)倉平臺的安全規(guī)范比如統(tǒng)一的Kerberos認證、統(tǒng)一的網(wǎng)關(guān)鑒權(quán)、統(tǒng)一的敏感數(shù)據(jù)申請流程。但你會發(fā)現(xiàn)這些安全規(guī)范落到數(shù)據(jù)產(chǎn)品上經(jīng)常失效。原因很簡單平臺安全管的是到庫為止數(shù)據(jù)產(chǎn)品管的是到用戶為止。用戶在平臺上拿數(shù)據(jù)要申請、要走審批流但是一旦數(shù)據(jù)進了大屏系統(tǒng)或者API服務(wù)很多人默認這是我們自己開發(fā)的系統(tǒng)里面應(yīng)該沒問題吧于是完全放養(yǎng)。我見過一個真實案例公司數(shù)倉權(quán)限管得極嚴但是某個數(shù)據(jù)大屏項目的后端接口居然可以傳入任意日期參數(shù)去查整個平臺的用戶明細前端只是做了一層展示后端沒有任何權(quán)限判斷。平臺安全做得再好產(chǎn)品層這一刀切開數(shù)據(jù)還是裸奔。所以數(shù)據(jù)產(chǎn)品的安全策略必須是針對產(chǎn)品自身形態(tài)重新設(shè)計的而不是平臺安全的延伸或簡化。2. 一張風險地圖數(shù)據(jù)產(chǎn)品最常見的五種泄漏姿勢做安全加固第一步不是上工具是先畫威脅模型。我整理了數(shù)據(jù)產(chǎn)品領(lǐng)域最常出事的五種泄漏姿勢按發(fā)生頻率從高到低排了個序。2.1 身份與訪問層面賬號共享是最難防的頭號問題數(shù)據(jù)產(chǎn)品的目標用戶往往是業(yè)務(wù)線的人他們習慣于讓運營幫我導出一下把管理員賬號給我用一下。賬號共享一旦存在所有安全策略都會變成笑話——審計日志里看到的是張三的操作實際動手的是李四明明要通過權(quán)限申請才能看的數(shù)據(jù)借個號就繞過去了。這個問題的根源是兩條一是數(shù)據(jù)產(chǎn)品接入統(tǒng)一身份認證太晚很多小產(chǎn)品上線時自己建一套賬號體系二是權(quán)限申請流程太麻煩業(yè)務(wù)人員寧可找熟人要賬號也不走流程。2.2 數(shù)據(jù)內(nèi)容層面最怕的不是黑客而是合法用戶越權(quán)很多團隊做安全只會盯著外部攻擊但真實的泄露場景里內(nèi)部合法用戶的越權(quán)使用占了大頭。常見的有幾類橫向越權(quán)A區(qū)域的運營人員把URL里的org_id參數(shù)改成B區(qū)域直接查到了B區(qū)域的數(shù)據(jù)。縱向越權(quán)普通用戶調(diào)用了管理員的API接口看到全量數(shù)據(jù)。推理攻擊就算每個字段都做了權(quán)限控制用戶可以通過匯總指標的差值反推出單個人的敏感信息這在明細數(shù)據(jù)和匯總數(shù)據(jù)同時開放的產(chǎn)品里特別常見。導出無痕頁面明明只能看前1000條但導出接口沒做限制用戶直接把全量明細Excel拖回自己電腦。2.3 終端與展示層面大屏拍照、導出按鈕、瀏覽器緩存大屏類和報表類產(chǎn)品的問題往往不在后端而在終端。會議室大屏不鎖屏陌生人路過直接用。報表頁面打開后F12一看接口返回的全部是明文數(shù)據(jù)瀏覽器緩存里存了一整天的查詢結(jié)果。還有更常見的頁面做了脫敏但導出功能沒有脫敏——頁面顯示手機號是138****1234導出的Excel是完整手機號。2.4 基礎(chǔ)設(shè)施與鏈路層面集群部署留下的暗門數(shù)據(jù)產(chǎn)品的底層都跑在大數(shù)據(jù)集群上但集群的安全配置經(jīng)常是裝了樣子沒裝靈魂。最典型的是Kerberos只在NameNode開了認證HiveServer2裸奔YARN隊列任何人可提交任務(wù)HDFS目錄權(quán)限是777Spark任務(wù)日志里打印了敏感字段名外加部分數(shù)據(jù)。這些基礎(chǔ)層漏洞往往歸屬于大數(shù)據(jù)平臺團隊管理范圍數(shù)據(jù)產(chǎn)品團隊以為有人管其實三不管。2.5 運維與發(fā)布層面上線和變更時的窗口期事故數(shù)據(jù)產(chǎn)品是迭代最快的系統(tǒng)之一幾乎每周都有發(fā)布。發(fā)布窗口期是安全事件的高發(fā)時段測試環(huán)境數(shù)據(jù)沒脫敏就同步到預(yù)發(fā)布、臨時排查問題把數(shù)據(jù)庫賬號密碼寫死在代碼里、回滾時把安全策略一并回滾了。很多事故復盤到最后不是技術(shù)不行是發(fā)布流程里壓根沒有安全評審這一步。我把上面的風險匯總了一張表后面每個章節(jié)的解決方案都對著這張表來泄漏姿勢典型場景危害等級核心對策賬號共享與弱認證業(yè)務(wù)借管理員賬號導出數(shù)據(jù)極高統(tǒng)一SSO、MFA、操作審計合法用戶越權(quán)改參數(shù)查他人數(shù)據(jù)、繞過導出限制極高行列權(quán)限、接口鑒權(quán)、導出管控終端展示裸奔大屏拍照、瀏覽器緩存明文高水印溯源、防截屏、展示層脫敏基礎(chǔ)設(shè)施暗門HiveServer2無認證、HDFS權(quán)限過大高Kerberos全覆蓋、網(wǎng)絡(luò)隔離、目錄收斂發(fā)布窗口期事故測試數(shù)據(jù)進生產(chǎn)、密鑰寫進代碼高發(fā)布安全評審、密鑰托管、自動巡檢3. 身份認證與行列權(quán)限把誰能看什么真正落實到代碼風險地圖畫完首先要堵的是最大那個窟窿身份與權(quán)限。這部分聽起來基礎(chǔ)實際落地坑最多。3.1 認證層統(tǒng)一賬號體系與登錄態(tài)管理數(shù)據(jù)產(chǎn)品絕對不要自建賬號密碼體系這是我在實戰(zhàn)里的第一個大原則。自建賬號會帶來三連問題密碼管理不規(guī)范、無法復用企業(yè)已有的人員離職流程、審計體系割裂。如果你所在的公司已經(jīng)有統(tǒng)一身份認證平臺數(shù)據(jù)產(chǎn)品必須無條件對接通過OAuth2/OIDC或CAS協(xié)議接入單點登錄。前端登錄流程就是跳到統(tǒng)一認證頁認證成功后拿一個授權(quán)碼后端拿授權(quán)碼去換用戶信息和會話Token。我強烈建議所有數(shù)據(jù)產(chǎn)品使用短時Token配合刷新機制不要自己做傳統(tǒng)的SessionCookie。JWT這類無狀態(tài)Token有個好處后端服務(wù)可以水平擴容Token驗簽不依賴會話存儲。但JWT也有個容易踩的坑Token一旦簽發(fā)在過期之前無法主動作廢。所以人員離職、權(quán)限變更的數(shù)據(jù)產(chǎn)品Token有效期要短最好15分鐘到30分鐘配合刷新Token機制來控制生命周期。還有一點要強調(diào)管理端和普通用戶端必須分庫分權(quán)限。管理端的登錄必須強制MFA不能只輸入一個密碼就進入用戶管理、權(quán)限分配、數(shù)據(jù)配置這些高危頁面。3.2 授權(quán)模型從菜單級授權(quán)走向數(shù)據(jù)級授權(quán)授權(quán)模型我推薦按數(shù)據(jù)域來抽象而不是按頁面來授權(quán)。傳統(tǒng)做法是按菜單授權(quán)用戶能進某個頁面就完事了但進去之后看到什么數(shù)據(jù)完全沒控制。數(shù)據(jù)域授權(quán)是把數(shù)據(jù)按業(yè)務(wù)線、區(qū)域、組織、時間維度劃分成域每個用戶或角色只能訪問被授權(quán)的域。舉個例子網(wǎng)約車項目里的數(shù)據(jù)分析平臺如果只做菜單授權(quán)所有運營人員都能打開司機明細查詢頁面但是A區(qū)的運營人員不應(yīng)該看到B區(qū)的司機數(shù)據(jù)。正確的做法是把司機明細這個數(shù)據(jù)域按區(qū)域打標權(quán)限系統(tǒng)管控到誰可以在這個頁面上看哪些區(qū)域的數(shù)據(jù)這樣不管是哪個團隊開發(fā)了新頁面只要數(shù)據(jù)域模型不被繞過權(quán)限邏輯就是一致的。在模型選型上我對大部分團隊的建議是以角色為核心用角色綁定數(shù)據(jù)域不要讓權(quán)限直接掛在個人身上。個人直接授權(quán)短期內(nèi)好用但半年后你就會發(fā)現(xiàn)權(quán)限列表膨脹到無法維護。角色模型可以順便解決崗位調(diào)整的場景人員換崗后換個角色組權(quán)限自動變化。3.3 行級與列級權(quán)限的實現(xiàn)思路SQL改寫與結(jié)果集重寫這是數(shù)據(jù)產(chǎn)品安全里被問得最多、也最核心的技術(shù)點。在線分析產(chǎn)品要真正做到每個人只能看到該看的行和列主流的實現(xiàn)路徑有兩條。第一種SQL改寫Query Rewrite。在服務(wù)端攔截用戶的查詢SQL解析語法樹然后自動注入行級過濾條件和列級脫敏規(guī)則。比如用戶是一個區(qū)域運營查詢dw_order_detail訂單明細表中間層自動把他的區(qū)域編碼加進WHERE條件把手機號列替換成脫敏函數(shù)。這種方式的優(yōu)點是對上層透明業(yè)務(wù)代碼不需要知道權(quán)限的存在缺點是SQL語法解析本身有兼容性成本業(yè)務(wù)部門寫SQL五花八門解析不到就放行就變成了漏洞。第二種結(jié)果集后置過濾。先查到結(jié)果再在內(nèi)存里做行列裁剪。優(yōu)點是實現(xiàn)簡單邏輯清晰但缺點也很明顯數(shù)據(jù)已經(jīng)查出來了內(nèi)存開銷大而且只適合查詢結(jié)果量可控的場景。假如一個用戶查了100萬行你要在內(nèi)存里逐行判斷權(quán)限性能直接崩。實操中成熟團隊一般是在網(wǎng)關(guān)層做一套權(quán)限解析組件同時支持規(guī)則注入和結(jié)果集重寫兩種模式。規(guī)則上如果列權(quán)限的要求是隱藏/脫敏那就優(yōu)先走SQL改寫如果是聚合后再放行往往需要結(jié)果集重寫配合聚合計算。開源社區(qū)這幾年也出了不少行列權(quán)限的實現(xiàn)組件比如基于Apache Calcite做SQL解析的方案已經(jīng)比較成熟可以引入到自己的數(shù)據(jù)服務(wù)中間層不用從零造輪子。但別迷信開源組件部署即用它通常需要你提供完整的元數(shù)據(jù)映射和數(shù)據(jù)域模型前期的數(shù)據(jù)整理工作量才是大頭。3.4 權(quán)限管理的工程化細節(jié)同步、緩存與審計權(quán)限系統(tǒng)最怕的不是設(shè)計不好而是權(quán)限數(shù)據(jù)和真實的數(shù)據(jù)對不上。我見過太多產(chǎn)品權(quán)限表是手工維護的Excel導入的人員和數(shù)據(jù)域早就調(diào)整了權(quán)限卻沒跟著變。這里有四條工程化經(jīng)驗權(quán)限數(shù)據(jù)必須從權(quán)威上游同步通常來自HR系統(tǒng)或組織架構(gòu)系統(tǒng)每天定時同步到數(shù)據(jù)產(chǎn)品的權(quán)限庫。手工增刪只能作為臨時通道并且要留審批記錄。權(quán)限變更要實時推送敏感服務(wù)。人的權(quán)限被回收后如果服務(wù)端緩存了30分鐘那這30分鐘就是泄漏窗口。發(fā)布一個權(quán)限變更的消息隊列對核心服務(wù)實時失效相關(guān)緩存。每次查詢請求都要帶有權(quán)限上下文。后端接口不要信任前端傳入的用戶ID要從前端攜帶的登錄態(tài)中解析用戶標識再綁定到權(quán)限上下文后續(xù)的行列裁剪都基于這個上下文。審計日志要記到行。誰在什么時間、通過哪個產(chǎn)品、訪問了哪個數(shù)據(jù)域、執(zhí)行了什么查詢、導出了多少行數(shù)據(jù)這些都要記錄。出了事后審計日志就是你唯一的破案線索。4. 數(shù)據(jù)內(nèi)容保護分級識別、動態(tài)脫敏與溯源水印權(quán)限解決的是誰能看內(nèi)容保護解決的是看到的東西泄露出去會不會出事。這兩個層面缺一不可。4.1 數(shù)據(jù)分級是安全策略的地基沒有對數(shù)據(jù)本身的分級談脫敏和防泄露都是空話。我建議數(shù)據(jù)產(chǎn)品團隊不要自己拍腦袋定級而是復用數(shù)倉已有的數(shù)據(jù)分級機制把底層表字段按四級來管級別定義典型字段處理要求L1公開數(shù)據(jù)商品名稱、城市名展示不受限L2內(nèi)部數(shù)據(jù)訂單量、銷售額對內(nèi)可見需要登錄L3敏感數(shù)據(jù)手機號、身份證號、精確地址展示脫敏導出需申請L4高危數(shù)據(jù)銀行卡號、密碼、生物信息禁止明文展示禁止導出這里有個實操技巧不要對整張表定級要按字段級別定級。同一張用戶表中用戶ID可能是L2手機號是L3常駐地是L3消費偏好是L2。把這個關(guān)系維護成數(shù)據(jù)字典后面所有脫敏組件、權(quán)限組件都引用這份字典。這張數(shù)據(jù)字典是整個數(shù)據(jù)產(chǎn)品內(nèi)容安全的核心配置文件。4.2 動態(tài)脫敏的三種落地方式脫敏分為靜態(tài)脫敏存儲層的假數(shù)據(jù)替換和動態(tài)脫敏查詢時實時變換。數(shù)據(jù)產(chǎn)品用的是動態(tài)脫敏因為要保證原始數(shù)據(jù)進、脫敏數(shù)據(jù)出源表不能輕易動。三種落地方式各有場景視圖層脫敏在數(shù)據(jù)倉庫層創(chuàng)建脫敏視圖視圖里用concat、substr這樣的函數(shù)把手機號、身份證號做部分隱藏數(shù)據(jù)產(chǎn)品直接讀取脫敏視圖。優(yōu)點是最簡單缺點是靈活性差不同用戶對同一字段的可見級別不同就沒法用——你不能給每個人建一個不同的視圖。中間件攔截改寫在數(shù)據(jù)訪問中間件層攔截SQL解析出敏感列自動把查詢改寫為脫敏版本。適合統(tǒng)一管控、多產(chǎn)品復用的場景但依賴SQL解析能力。結(jié)果集重寫服務(wù)端拿到明細結(jié)果后根據(jù)當前用戶的權(quán)限級別在內(nèi)存里把敏感字段的某些位置替換成星號。適合展示邏輯可控、結(jié)果集不大的系統(tǒng)。在實際項目里我對大屏和報表系統(tǒng)的建議是無論底層用哪種脫敏方案前端拿到結(jié)果之后還要做一層兜底脫敏。后端萬一配置漏了前端的格式化函數(shù)也能擋住明文泄漏。脫敏要特別注意保留數(shù)據(jù)可用性比如手機號脫敏成138****1234雖然中間四位沒了但在同一天內(nèi)同一個人的脫敏值要保持一致否則報表里對賬都對不上。所以脫敏函數(shù)不能是每次查詢隨機變化的要基于哈希或確定性加密來實現(xiàn)。4.3 水印溯源讓截圖和導出能追到人數(shù)據(jù)產(chǎn)品里水印幾乎是最低成本、最高效率的溯源手段。我強烈建議每個可視化頁面都強制疊加水印至少在敏感數(shù)據(jù)頁面不能提供關(guān)閉選項。水印分兩種明水印頁面背景里半透明的工號或姓名橫豎交錯鋪滿屏幕。會議室有人拿手機拍照事后一放大就能看到是哪個工號泄的密。之前有客戶測試過把明水印嵌入到圖表背后的灰色紋理里既不擋數(shù)據(jù)拍照后依然清晰可辨。暗水印肉眼看不見但可以通過程序從圖片或數(shù)據(jù)中還原。在數(shù)據(jù)下載場景下做暗水印很有價值給下載的Excel文件里通過修改某些列的小數(shù)位精度或文本末尾的隱藏字符把用戶ID編碼進去。文件一旦外傳拿回原始數(shù)據(jù)做校驗就能定位到下載人。暗水印簡單實現(xiàn)可以這么做把用戶ID和導出時間做一個哈希轉(zhuǎn)成一段數(shù)字編碼然后把編碼拆成若干位逐一埋進Excel數(shù)值型字段的最后一個十進制位上。比如原值是12.34編碼位是7導出值就變成12.347。對業(yè)務(wù)分析來說一位的小數(shù)偏差幾乎無感但對溯源來說這就是鐵證。4.4 大屏場景的特殊處理大屏是目前數(shù)據(jù)產(chǎn)品里安全最容易被忽略的形態(tài)。因為大屏天生是擺出來給別人看的大家默認它不是個內(nèi)部系統(tǒng)反而忘了它的數(shù)據(jù)有多敏感。我總結(jié)的大屏安全四板斧獨立數(shù)據(jù)接口層大屏不要直接連底層庫或Hive后端單獨封裝一層只讀接口且接口只返回大屏展示需要的聚合數(shù)據(jù)不返回明細。這是從源頭上減小暴露面。會話與投屏管控大屏的登錄態(tài)要有獨立過期時間比如凌晨無人時自動強制退出投屏用的終端要做固定IP白名單避免任何人在任意電腦上都能訪問大屏地址。防截屏與防錄屏檢測頁面監(jiān)聽窗口失焦、復制事件檢測到DevTools打開或截圖操作時可以觸發(fā)告警。前端方案防不了專業(yè)工具但不設(shè)防等于敞開大門。屏幕水印強制疊加明水印在大屏上一律不能關(guān)并且水印內(nèi)容要包含操作人和當前時間這樣會議室拍回去的照片才具備溯源價值。5. 鏈路與基礎(chǔ)設(shè)施安全集群部署階段就要留下的底子數(shù)據(jù)產(chǎn)品跑在集群上如果鏈路本身不安全上層產(chǎn)品做得再好也是白搭。這部分其實屬于大數(shù)據(jù)集群部署策略的范疇但我一定要從數(shù)據(jù)產(chǎn)品視角再說一遍因為太多數(shù)據(jù)產(chǎn)品團隊以為這是平臺團隊的事結(jié)果兩頭落空。5.1 認證與準入Kerberos必須覆蓋到接入端Kerberos在Hadoop生態(tài)里是標配但這幾年我看到最常見的部署問題是只開了NameNode的認證HiveServer2裸奔。數(shù)據(jù)產(chǎn)品通過JDBC直連HiveServer2查詢數(shù)據(jù)時只要知道連接地址和端口任意用戶都能連上去執(zhí)行SQL。這等于你給銀行金庫裝了高級指紋鎖卻把后門消防通道常年開著。所以數(shù)據(jù)產(chǎn)品上線之前一定要和技術(shù)平臺共同確認一件事所有數(shù)據(jù)訪問入口包括HiveServer2、JDBC/ODBC、Spark ThriftServer、HBase/Redis認證是否全部納入了Kerberos或LDAP認證域。不只是HDFS上的文件要認證計算引擎和元數(shù)據(jù)服務(wù)也要認證。5.2 網(wǎng)絡(luò)隔離與數(shù)據(jù)加密數(shù)據(jù)產(chǎn)品服務(wù)器應(yīng)該放在獨立的網(wǎng)絡(luò)區(qū)域通過安全組或防火墻只開放80/443端口對外數(shù)據(jù)庫、HDFS、Kafka這些后端組件的端口一律不對數(shù)據(jù)產(chǎn)品服務(wù)器之外的主機開放。數(shù)據(jù)產(chǎn)品訪問集群的鏈路也要走專用的內(nèi)網(wǎng)網(wǎng)段不要圖省事把集群的公共訪問開關(guān)打開。傳輸層和數(shù)據(jù)落地的加密原則是能開全開數(shù)據(jù)產(chǎn)品對外訪問全部走HTTPS禁用HTTP明文端口。別省證書的錢也別信內(nèi)網(wǎng)不需要加密這種話。數(shù)據(jù)產(chǎn)品到Hive/HDFS之間的連接開啟TLS或至少走安全RPC。集群內(nèi)部各節(jié)點之間如果規(guī)模不大也建議開啟RPC加密。底層的敏感字段在入庫前就做加密存儲。注意加密要支持可檢索或可脫敏匹配比如手機號加密后仍然要能支持精確匹配和前綴匹配否則業(yè)務(wù)就廢了。這塊可以通過在Hive表中增加一個加密的確定性哈希列來解決。5.3 審計日志集中化與異常檢測安全策略里最容易做的部分是日志最容易拖垮效率的也是日志。我的原則是日志要集中、要帶上鏈路ID、要能被查詢分析。數(shù)據(jù)產(chǎn)品的審計日志至少包括四類訪問日志誰、從哪個IP、在哪個時間、訪問了哪個接口和頁面。數(shù)據(jù)查詢?nèi)罩就ㄟ^這個產(chǎn)品執(zhí)行了哪些SQL涉及哪些表和字段這個數(shù)據(jù)量很大建議只記表和敏感字段級別的摘要不要記全量SQL否則成本太高。導出日志哪些用戶導出了什么文件、導出行數(shù)、文件hash值。權(quán)限變更日志誰在什么時候給誰加了什么權(quán)限、走了什么審批流。日志集中到統(tǒng)一平臺后可以順帶做異常行為檢測。幾條簡單實用的規(guī)則就能抓住大多數(shù)風險場景同一賬號在短時間內(nèi)從多個不同城市IP登錄。深夜時段出現(xiàn)高頻率、大批量的數(shù)據(jù)導出或明細查詢。單賬號在短時間內(nèi)請求了大量未授權(quán)的數(shù)據(jù)域。導出文件的hash值在外網(wǎng)被分享可以做企業(yè)DLP的聯(lián)動檢測。這里其實可以做一點大數(shù)據(jù)偵察思路把這些日志當數(shù)據(jù)源用離線分析任務(wù)跑一套異常特征再把嫌疑人和嫌疑操作推送給人審。不用追求全自動判定能把風險收斂到人工可處理的量級就是勝利。6. 發(fā)布、監(jiān)控與應(yīng)急上線不等于萬事大吉處理完前面五層你的數(shù)據(jù)產(chǎn)品不能說絕對安全但至少主路徑上沒有大窟窿了。接下來是最后一公里讓安全策略在迭代過程中持續(xù)生效。很多產(chǎn)品安全做得好是靜態(tài)的一上線一迭代就漏回去了。6.1 安全評審清單上線前逐項打勾我把數(shù)據(jù)產(chǎn)品的安全評審濃縮成一張清單每次上線前對照著勾一遍。不要在代碼寫完后才走評審應(yīng)該在需求評審階段就讓安全評審介入。評審項檢查點認證是否接入統(tǒng)一SSO是否強制MFA管理端測試賬號是否清理授權(quán)新頁面是否接入數(shù)據(jù)域權(quán)限接口是否校驗權(quán)限上下文數(shù)據(jù)分級新用到的字段是否已維護進數(shù)據(jù)字典敏感字段是否配置脫敏SQL注入所有查詢接口是否參數(shù)化是否限制返回行數(shù)導出管控導出功能是否脫敏、有水印、有審批、有審計基礎(chǔ)設(shè)施訪問鏈路是否加密后端組件端口是否隔離密鑰管理數(shù)據(jù)庫密碼、Token密鑰是否托管代碼里是否有硬編碼依賴安全前后端依賴是否有已知高危CVE是否升級到安全版本如果團隊里沒有獨立安全崗我建議由數(shù)據(jù)產(chǎn)品負責人和技術(shù)負責人共同勾這張表每次上線發(fā)版時把勾選結(jié)果附在發(fā)布單里。6.2 生產(chǎn)環(huán)境的持續(xù)監(jiān)控與告警上線之后的安全監(jiān)控不要追求大而全的SIEM平臺先把核心指標盤活。數(shù)據(jù)產(chǎn)品主要盯四類指標接口訪問監(jiān)控5xx錯誤率、平均響應(yīng)時間、單IP/QPS突增。數(shù)據(jù)量監(jiān)控單用戶日查詢行數(shù)、導出行數(shù)是否超基線。權(quán)限異常權(quán)限變更頻率突然增加尤其夜間批量授權(quán)。敏感接口監(jiān)控返回敏感L3/L4字段的接口調(diào)用頻率如果出現(xiàn)階梯式上升立刻告警。告警閾值要按產(chǎn)品歷史基線來定不要套統(tǒng)一模板。比如導出量運營團隊周一大促后導出量是平時的5倍如果閾值設(shè)得死可能天天誤報最后狼來了沒人看。6.3 應(yīng)急響應(yīng)數(shù)據(jù)安全事件應(yīng)該怎么處置再好的防御也會有漏網(wǎng)的時候把應(yīng)急響應(yīng)流程理順比發(fā)誓絕不出事靠譜。我的處置鏈路大概是確認與凍結(jié)接到疑似泄露告警先確認是否真實存在。確認后第一時間凍結(jié)嫌疑賬號、撤回相關(guān)API的臨時Token把暴露面停下來。定位暴露面從審計日志倒查這個賬號訪問了哪些數(shù)據(jù)域、導出了哪些文件、時間段是多久。通過水印和導出文件hash鎖定最終泄露樣本。評估影響范圍涉及字段級別是否L3/L4、用戶數(shù)、數(shù)據(jù)時間跨度同步給數(shù)據(jù)和合規(guī)同事確定是否要通知業(yè)務(wù)方或用戶做進一步處置。根因修復不要只補眼前這個洞。賬號共享導致的就上MFA和最小權(quán)限接口越權(quán)導致的就補數(shù)據(jù)域過濾脫敏缺失導致的就補數(shù)據(jù)字典和脫敏組件。復盤沉淀把事件過程、處置時間線、根因、改進動作寫成一頁紙的復盤發(fā)到團隊內(nèi)部。復盤的重點是下次怎么提前發(fā)現(xiàn)不是追責。另外我強烈建議每年給數(shù)據(jù)產(chǎn)品做兩次安全演練模擬賬號失陷和大批量數(shù)據(jù)泄露兩種場景讓值班的人動手跑一遍處置鏈路。很多團隊應(yīng)急文檔寫得很完善但真出了事連告警群在哪都找不到演練就是用最小的成本暴露這些問題。做數(shù)據(jù)產(chǎn)品安全這幾年我最大的一個體會是安全策略不是一勞永逸的工程而是一套不斷跟著產(chǎn)品和數(shù)據(jù)形態(tài)演進的機制。別追求第一步就把所有安全組件都堆上去先畫清楚三張地圖——用戶訪問地圖、數(shù)據(jù)流向地圖、鏈路依賴地圖然后按風險從高到低逐個堵洞比一次性鋪一堆安全產(chǎn)品可靠得多。很多團隊一上來就買脫敏平臺、加密系統(tǒng)結(jié)果賬號體系還是共用的等于給保險箱上了三重鎖卻讓大門敞開著。優(yōu)先順序一定不能搞反。至于行列權(quán)限這類核心技術(shù)點現(xiàn)在開源社區(qū)的方案已經(jīng)不少了但記住一句話技術(shù)永遠不是最難的部分最難的是把數(shù)據(jù)域模型梳理清楚。模型理清了安全策略就是往模型上掛規(guī)則的活兒。