“數(shù)據(jù)庫安全”這五個字聽起來像個老生常談但真正動手做的時候你會發(fā)現(xiàn)它比應(yīng)用安全、網(wǎng)絡(luò)安全更難落地。我見過不少團隊應(yīng)用層做了很嚴的權(quán)限校驗網(wǎng)絡(luò)層上了防火墻結(jié)果數(shù)據(jù)庫連的還是公網(wǎng)地址密碼依然是最原始的那幾個組合。為什么因為數(shù)據(jù)庫往往是整個系統(tǒng)里最“陳舊”的一層很多庫是從十年前直接遷移過來的賬號、權(quán)限、審計規(guī)則都帶著當(dāng)年的味道。這篇內(nèi)容我不會給你講抽象的安全理論而是按實操經(jīng)驗把數(shù)據(jù)庫安全拆成權(quán)限管理、數(shù)據(jù)加密、審計監(jiān)控、備份恢復(fù)四個核心板塊再附上自查清單和踩坑記錄。不管你是DBA、后端開發(fā)還是運維都可以直接對照自己的環(huán)境。1. 數(shù)據(jù)庫安全的整體視圖從外部防護到內(nèi)部管控1.1 數(shù)據(jù)庫安全不是裝個防火墻那么簡單先說一個常見誤區(qū)很多人以為數(shù)據(jù)庫安全等于“把端口藏起來不暴露公網(wǎng)”。這樣做當(dāng)然對但只是最外層。一次真正的事故往往不是外部黑客直接打數(shù)據(jù)庫而是通過應(yīng)用漏洞拿到一個低權(quán)限賬號然后水平越權(quán)、SQL注入甚至直接使用應(yīng)用連接串里的數(shù)據(jù)庫賬號連進去。也就是說攻擊者一旦進入內(nèi)網(wǎng)數(shù)據(jù)庫就暴露在所有內(nèi)部人員面前而內(nèi)部人員的權(quán)限劃分、安全意識、審計能力才是決定數(shù)據(jù)會不會泄露的關(guān)鍵。我在多個項目里反復(fù)強調(diào)一個詞縱深防御。數(shù)據(jù)庫這一層必須假設(shè)前面的所有防線都可能被攻破因此自己也要有獨立的安全能力。至少要包括認證與權(quán)限、加密、審計、備份。這四件事缺一不可。具體來說認證解決“你是誰”權(quán)限解決“你能干什么”加密解決“數(shù)據(jù)即使被拿走也讀不懂”審計解決“出了事能查到誰干的”備份解決“最壞情況下還能恢復(fù)”。這五層構(gòu)成了數(shù)據(jù)庫安全的基本盤。把這幾件事做好了數(shù)據(jù)庫這個“最后防線”才算真正立得住。1.2 常見威脅模型與攻擊路徑為了設(shè)計安全策略得先知道敵人會從哪來。常見的威脅模型有三類外部攻擊者通過SQL注入、弱口令暴破、未授權(quán)接口等途徑嘗試直接進入數(shù)據(jù)庫。內(nèi)部威脅開發(fā)、運維、第三方外包人員擁有合法的數(shù)據(jù)庫賬號但可能因為權(quán)限過大、誤操作或惡意行為造成數(shù)據(jù)泄露。物理與運維風(fēng)險硬盤損壞、機房斷電、勒索病毒加密文件、誤刪除表數(shù)據(jù)。攻擊路徑上我見過比較典型的一種攻擊者先掃描公網(wǎng)IP發(fā)現(xiàn)3306/5432端口開放然后對不同IP嘗試常見用戶名密碼。一旦命中弱口令直接連上數(shù)據(jù)庫把整庫導(dǎo)出。這個過程可能不需要任何應(yīng)用漏洞純粹是運維暴露面太大。還有一條路徑攻擊者找到應(yīng)用的一個SQL注入點通過注入讀取數(shù)據(jù)庫版本和當(dāng)前用戶然后利用過高權(quán)限執(zhí)行系統(tǒng)命令或讀取文件。這類問題在老舊系統(tǒng)里尤其常見。所以數(shù)據(jù)庫安全設(shè)計的時候要同時考慮“連不上”和“連上了也拿不到”兩層。后面展開的權(quán)限管理和加密正是針對這兩層。2. 權(quán)限管理最小權(quán)限原則的落地細節(jié)2.1 賬號規(guī)劃從應(yīng)用賬號到管理賬號分離我最常遇到的問題是一個庫只有一個賬號應(yīng)用用這個賬號連接DBA也用這個賬號維護監(jiān)控腳本也用這個賬號。全公司所有人都共用同一份數(shù)據(jù)庫賬號密碼密碼一旦泄露根本分不清是誰的操作。正確的賬號規(guī)劃至少應(yīng)該分成四類應(yīng)用賬號只給某個業(yè)務(wù)庫的增刪改查權(quán)限具體粒度視業(yè)務(wù)而定。運維賬號用于日常維護、索引調(diào)整、執(zhí)行DDL必須有單獨的賬號和登錄審批流程。管理賬號僅限D(zhuǎn)BA或數(shù)據(jù)庫負責(zé)人使用用于創(chuàng)建賬號、修改權(quán)限、恢復(fù)數(shù)據(jù)等高危操作。只讀賬號給報表、監(jiān)控、數(shù)據(jù)分析用盡量不連接生產(chǎn)庫而是連接從庫或數(shù)據(jù)倉庫。這樣分類有三個意義第一是責(zé)任追蹤每個人都知道自己用的是哪個賬號第二是限制爆炸半徑應(yīng)用賬號被拖庫也不會影響其他庫第三是方便輪換比如某員工離職時只要禁用他名下的賬號不用改應(yīng)用配置。操作上可以用類似下面的語句來創(chuàng)建基礎(chǔ)的應(yīng)用賬號CREATE USER app_order10.0.0.% IDENTIFIED BY 這里填高強度隨機密碼; GRANT SELECT, INSERT, UPDATE ON order_db.* TO app_order10.0.0.%;這里沒給DELETE權(quán)限也沒給DDL權(quán)限。對于很多業(yè)務(wù)系統(tǒng)來說邏輯刪除就夠了物理刪除權(quán)限能不給就別給。關(guān)于密碼輪換我建議結(jié)合配置中心和密鑰管理服務(wù)不要直接在代碼里維護數(shù)據(jù)庫密碼。如果數(shù)據(jù)庫支持短期令牌或動態(tài)憑證優(yōu)先使用那種方案。2.2 授權(quán)模型庫、表、列的精細化控制最小權(quán)限原則聽著簡單落地起來容易走極端。一種極端是給所有賬號全部權(quán)限另一種極端是因為權(quán)限太細導(dǎo)致業(yè)務(wù)無法運行。我建議分三步做。第一步按業(yè)務(wù)模塊拆分數(shù)據(jù)庫賬號。不要整個業(yè)務(wù)共用一個賬號而是每個微服務(wù)或每個應(yīng)用模塊有獨立賬號。第二步按操作類型授權(quán)。常見的授權(quán)矩陣如下賬號類型庫/表范圍權(quán)限應(yīng)用讀寫賬號業(yè)務(wù)庫的業(yè)務(wù)表SELECT、INSERT、UPDATE、DELETE應(yīng)用只讀賬號業(yè)務(wù)庫的統(tǒng)計表SELECT運維賬號全部業(yè)務(wù)庫SELECT、INDEX、ALTER、ANALYZE管理賬號全部庫ALL需要審批報表賬號指定庫的視圖SELECT第三步考慮行級和列級安全。大部分數(shù)據(jù)庫支持視圖先創(chuàng)建一個視圖只包含必要的列并且通過WHERE條件限制行范圍再給應(yīng)用賬號授權(quán)訪問視圖而不是直接訪問表。比如一個門店管理系統(tǒng)只允許查看本門店訂單就可以在視圖里帶上門店條件。這樣即使應(yīng)用邏輯被繞過數(shù)據(jù)庫層面也不會泄露其他門店的數(shù)據(jù)。提示DELETE權(quán)限是很多數(shù)據(jù)庫安全事件里最危險的權(quán)限。業(yè)務(wù)上通常不需要它寧愿多做幾次邏輯刪除改造也別把物理刪除的能力直接交給應(yīng)用賬號。2.3 密碼策略與生命周期管理密碼策略往往被當(dāng)成形式上的東西。但數(shù)據(jù)庫賬號的密碼參數(shù)確實需要符合一定的復(fù)雜度要求同時不能為了方便而改成弱密碼。我見過很多生產(chǎn)庫用了類似簡單遞增數(shù)字這樣的密碼甚至在代碼倉庫里明文保存連接串。這種情況一旦發(fā)生權(quán)限設(shè)計做得再好也沒用。關(guān)于密碼管理我會這樣做連接串不要寫死在代碼里放到配置中心或環(huán)境變量中并使用密鑰管理服務(wù)。數(shù)據(jù)庫賬號密碼至少16位包含大小寫字母、數(shù)字、特殊字符。避免使用默認端口進行公網(wǎng)暴露即使必須遠程訪問也要配合IP白名單和專用接入通道。定期輪換密碼并確保輪換后舊的連接串立即失效。另外要有賬號臺賬把每個庫的賬號、密碼、權(quán)限變更記錄維護在一張表里定期與實際環(huán)境比對發(fā)現(xiàn)“幽靈賬號”只有創(chuàng)建沒有使用記錄的賬號及時清理。這條工作很枯燥但能避免很多隱患。實際執(zhí)行時可以使用數(shù)據(jù)庫自帶的權(quán)限查詢語句導(dǎo)出賬號列表與權(quán)限列表再和臺賬逐條比對。3. 數(shù)據(jù)加密靜態(tài)加密、傳輸加密與動態(tài)脫敏3.1 靜態(tài)數(shù)據(jù)加密透明數(shù)據(jù)加密與表空間加密“數(shù)據(jù)庫文件被別人拷走了”這件事并不罕見可能是備份文件泄露也可能是磁盤被拿走。應(yīng)對辦法是靜態(tài)加密。主流數(shù)據(jù)庫都提供了透明數(shù)據(jù)加密或表空間加密。以某商業(yè)數(shù)據(jù)庫為例可以配置列級加密開源數(shù)據(jù)庫則通常需要借助文件系統(tǒng)加密或第三方工具。我做靜態(tài)加密時的幾個經(jīng)驗先確認需要加密哪些敏感列比如身份證號、手機號、銀行卡號。全部表加密會導(dǎo)致性能下降和管理復(fù)雜度上升。加密密鑰單獨保管不要和數(shù)據(jù)庫放在同一臺服務(wù)器。否則攻擊者拿到了服務(wù)器就同時拿到了密鑰和密文加密形同虛設(shè)。啟用透明數(shù)據(jù)加密后要測試對索引和查詢的影響。因為加密列通常無法直接進行模糊查詢或排序需要配合應(yīng)用層改造。如果數(shù)據(jù)庫本身不支持靜態(tài)加密可以在操作系統(tǒng)層面使用文件系統(tǒng)加密對整個數(shù)據(jù)目錄進行透明加密。好處是應(yīng)用無感知壞處是密鑰管理還是要單獨解決。這里也涉及一個細節(jié)密鑰備份要放到離線位置否則密鑰丟失比數(shù)據(jù)丟失更麻煩。3.2 傳輸加密TLS/SSL配置要點數(shù)據(jù)庫客戶端和服務(wù)器之間的流量如果不加密在同一個局域網(wǎng)內(nèi)可以被抓包。不要覺得內(nèi)網(wǎng)就安全攻擊者通過應(yīng)用漏洞進入某臺主機后第一件事就是抓流量、嗅探數(shù)據(jù)庫賬密。所以生產(chǎn)環(huán)境的數(shù)據(jù)庫連接必須啟用TLS/SSL。配置要點如下證書由內(nèi)部CA簽發(fā)客戶端配置CA根證書校驗服務(wù)器主機名。應(yīng)用連接串要明確標記使用SSL并禁止回退到非加密模式。數(shù)據(jù)庫服務(wù)端關(guān)閉非SSL監(jiān)聽端口或者至少對遠程連接強制SSL。注意TLS版本避免使用已經(jīng)被淘汰的老舊協(xié)議。配置完成后我習(xí)慣用抓包工具檢查一遍抓取數(shù)據(jù)庫握手包確認是否出現(xiàn)明文賬號密碼。如果還能看到明文說明配置沒生效別急著收工。很多數(shù)據(jù)庫的SSL是“可選”的客戶端可以連但不會報錯流量卻是明文。必須顯式要求客戶端使用SSL才能保證連接真正加密。3.3 數(shù)據(jù)脫敏與動態(tài)掩碼加密解決的是“存儲”和“傳輸”環(huán)節(jié)而在應(yīng)用演示、測試環(huán)境、日志采集場景下數(shù)據(jù)仍然需要脫敏。否則就算數(shù)據(jù)庫本身加密做得再好測試環(huán)境一旦泄露生產(chǎn)數(shù)據(jù)的敏感信息也會跟著泄露。我常建議在數(shù)據(jù)庫層做動態(tài)脫敏。比如某商業(yè)數(shù)據(jù)庫具備動態(tài)數(shù)據(jù)掩碼功能可以給特定列配置掩碼規(guī)則。普通用戶查詢時看到的是脫敏后的數(shù)據(jù)比如手機號顯示成中間四位隱藏的格式而有權(quán)限的用戶才能看到明文。相比在應(yīng)用層寫脫敏邏輯數(shù)據(jù)庫層脫敏的好處是即使有人繞過了應(yīng)用直接用客戶端查詢也拿不到真實數(shù)據(jù)。開源數(shù)據(jù)庫沒有內(nèi)置動態(tài)脫敏時可以兩種方案替代視圖脫敏創(chuàng)建一層脫敏視圖把敏感列通過函數(shù)轉(zhuǎn)換應(yīng)用賬號只訪問視圖。存儲過程代理所有查詢走存儲過程由存儲過程控制返回字段。這兩種方式都有維護成本但聊勝于無。另外一個常見坑是測試環(huán)境使用生產(chǎn)數(shù)據(jù)副本卻未脫敏。最好在備份恢復(fù)流程里加入“恢復(fù)后自動執(zhí)行脫敏更新”的步驟讓每次恢復(fù)出來的測試庫從一開始就是干凈數(shù)據(jù)。4. 數(shù)據(jù)庫審計與異常發(fā)現(xiàn)4.1 審計日志該記什么數(shù)據(jù)庫默認的日志往往只記錄錯誤和連接日志對于敏感操作查詢未必記錄。如果要滿足安全審計和事后追溯至少需要記錄這些內(nèi)容登錄成功與失敗包括來源IP、客戶端工具、登錄賬號、時間。DDL操作建表、改表、刪表尤其是DROP、TRUNCATE類操作。DCL操作授權(quán)、創(chuàng)建用戶、修改密碼。敏感表的DML操作比如對用戶表、訂單表的高頻查詢和大批量導(dǎo)出。記錄太多了會影響性能所以要有取舍。我一般會分為基礎(chǔ)審計和安全增強審計兩級基礎(chǔ)審計記錄登錄和DDL安全增強審計針對敏感表記錄DML。比如一個訂單系統(tǒng)用戶表和訂單表是核心那就把這兩張表的SELECT、UPDATE、DELETE都納入審計。審計日志的保存期限建議至少180天并且要異地存儲。很多系統(tǒng)審計日志和數(shù)據(jù)庫在同一臺服務(wù)器數(shù)據(jù)庫被入侵后日志先被清掉等于白審計。應(yīng)該把日志實時轉(zhuǎn)發(fā)到獨立的日志中心或者對象存儲?？梢耘渲脭?shù)據(jù)庫的syslog輸出讓審計日志實時發(fā)到遠程日志服務(wù)器。4.2 如何從日志中識別異常行為有了日志只是第一步怎么從海量日志里發(fā)現(xiàn)異常才是難點。我總結(jié)幾個高價值規(guī)則短時間內(nèi)登錄失敗次數(shù)超過閾值比如5分鐘內(nèi)10次說明可能有暴破。同一個賬號在多個IP同時登錄說明賬號可能被盜用。凌晨時段的批量導(dǎo)出操作例如對訂單表做全表SELECT行數(shù)超過一定量。應(yīng)用賬號執(zhí)行了DDL語句這絕對不正常。應(yīng)用賬號只應(yīng)該有DML和SELECT權(quán)限。使用異?？蛻舳斯ぞ哌B接比如突然出現(xiàn)一個GUI客戶端而不是應(yīng)用服務(wù)器IP。這些規(guī)則可以寫到告警系統(tǒng)里。如果數(shù)據(jù)庫自帶審計分析可以用內(nèi)置報表否則就需要把日志接入日志平臺設(shè)置規(guī)則。我重點提醒一下不要只監(jiān)控“登錄失敗”更要監(jiān)控“登錄成功后的異常動作”。攻擊者不會一直爆破失敗往往在某一瞬間用正確密碼登錄成功然后進行數(shù)據(jù)導(dǎo)出。如果只監(jiān)控失敗就看不到真正的竊取行為。實際環(huán)境中很多人把精力放在“有人掃端口”上卻忽略了真正已經(jīng)得手的那臺主機。4.3 堡壘機與數(shù)據(jù)庫防火墻的協(xié)同很多公司的數(shù)據(jù)庫運維是通過跳板機或堡壘機來操作的。這里要注意堡壘機只能管住“人”的連接管不住“應(yīng)用”的連接。應(yīng)用服務(wù)器的數(shù)據(jù)庫連接不會經(jīng)過堡壘機這部分連接要靠數(shù)據(jù)庫防火墻或者網(wǎng)絡(luò)ACL。數(shù)據(jù)庫防火墻可以在數(shù)據(jù)庫前面做四層和七層過濾IP白名單、協(xié)議解析、SQL黑名單。比如設(shè)置規(guī)則“只允許應(yīng)用服務(wù)器的固定IP訪問數(shù)據(jù)庫端口”再設(shè)置“禁止應(yīng)用賬號執(zhí)行DROP或TRUNCATE”。有了這道防線即使應(yīng)用被入侵攻擊者也很難直接在數(shù)據(jù)庫上執(zhí)行破壞性命令。不過數(shù)據(jù)庫防火墻的誤報問題挺頭疼尤其是SQL語句多樣化時規(guī)則寫得太死會影響業(yè)務(wù)。我的建議是先開啟審計模式觀察一段時間確認正常語句基線再逐步啟用攔截模式。不要第一天就上阻斷否則業(yè)務(wù)告警會淹沒了真正的安全問題。5. 備份恢復(fù)與應(yīng)急響應(yīng)5.1 備份策略不只是“每天備份一次”數(shù)據(jù)庫安全里最容易被忽略的是備份。實際上遇到勒索病毒或者誤刪數(shù)據(jù)時備份幾乎是唯一救命稻草。但備份策略如果設(shè)計不好恢復(fù)時才發(fā)現(xiàn)數(shù)據(jù)不全就晚了。我建議按“3-2-1原則”設(shè)計備份保留至少3份數(shù)據(jù)備份。存儲在2種不同介質(zhì)上比如本地磁盤和異地對象存儲。至少有1份離線備份或異地備份防止單一機房故障導(dǎo)致全部丟失。備份頻率要結(jié)合RPO需求。核心交易庫可能要每15分鐘做一次增量備份或日志備份一般業(yè)務(wù)庫可以每天全量加每小時增量。不要一味追求頻繁全量備份因為全量備份對生產(chǎn)環(huán)境IO影響較大。合理方式是每周一次全量每天一次增量加上實時的歸檔日志傳輸。備份驗證也要自動化。我見過不少備份文件是壞的大家一直以為沒問題。每個月隨機抽一個備份做一次恢復(fù)測試確保備份文件可讀、可恢復(fù)、恢復(fù)后數(shù)據(jù)一致性沒問題。這一步雖然花時間但比災(zāi)難發(fā)生時才發(fā)現(xiàn)備份不可用強得多。5.2 恢復(fù)演練才是安全的最后一公里“備份”做好了恢復(fù)能力是不是100%不一定?；謴?fù)演練才能驗證整個鏈路?；謴?fù)演練有幾個關(guān)鍵點使用與生產(chǎn)一致或接近的硬件資源。如果你的生產(chǎn)庫是大內(nèi)存配置恢復(fù)演練庫只有一小部分內(nèi)存那恢復(fù)時間會完全不同演練結(jié)果沒有參考價值。測試恢復(fù)后的數(shù)據(jù)一致性。比如先做一次事務(wù)操作記錄最后一條訂單ID恢復(fù)后檢查該ID是否存在以及關(guān)聯(lián)表數(shù)量是否匹配。演練要覆蓋“恢復(fù)到指定時間點”而不只是恢復(fù)到最近一次備份。因為最常發(fā)生的問題是誤操作后需要恢復(fù)到誤操作之前的某個時間點。舉個例子某業(yè)務(wù)系統(tǒng)誤刪了一張核心表準備用昨晚的備份恢復(fù)卻發(fā)現(xiàn)備份策略沒開啟歸檔日志只能恢復(fù)到昨晚零點丟失了當(dāng)天一整天的數(shù)據(jù)。這就是典型的RPO沒想清楚?；謴?fù)能力不是寫在文檔里的口號而是要真的滿足業(yè)務(wù)預(yù)期。5.3 勒索病毒場景下的應(yīng)急清單勒索病毒是數(shù)據(jù)庫安全里非?，F(xiàn)實的威脅。數(shù)據(jù)庫服務(wù)器一旦被加密業(yè)務(wù)會立刻中斷。面對這種場景應(yīng)急響應(yīng)要快但也要冷靜。我整理過一份應(yīng)急清單立即斷網(wǎng)隔離被感染的服務(wù)器防止加密擴散到其他主機和備份存儲。不要在未知情況下刪除任何文件先保留現(xiàn)場供取證。評估備份的完整性確認離線備份或異地備份是否可用。不建議支付贖金正規(guī)做法是走備份恢復(fù)?；謴?fù)后第一時間修改所有數(shù)據(jù)庫賬號密碼、系統(tǒng)賬號密碼并排查入侵入口。復(fù)盤問題是通過什么路徑進來的為什么備份也被加密后續(xù)如何補漏洞最后一條很重要備份存儲本身也要納入權(quán)限管控。如果備份目錄允許數(shù)據(jù)庫服務(wù)器直接寫入那勒索病毒就會把備份一并加密離線備份的意義正在于此。我見過不止一次攻擊者拿到數(shù)據(jù)庫服務(wù)器后順手把掛載在同一臺機器的備份盤也刪了。所以備份與生產(chǎn)環(huán)境的隔離一定要做扎實。6. 安全運維的常見坑與自查清單6.1 常見坑外網(wǎng)映射、弱口令、權(quán)限過大我把這幾年見到的低水平安全事件歸成幾類列成一張表坑典型表現(xiàn)后果數(shù)據(jù)庫端口映射公網(wǎng)把數(shù)據(jù)庫端口直接映射到公網(wǎng)弱口令暴破、拖庫弱口令簡單數(shù)字、通用單詞被猜中直接淪陷權(quán)限過大應(yīng)用賬號有ALL權(quán)限SQL注入可直接刪庫明文連接串配置文件里直接寫密碼源碼泄露導(dǎo)致拖庫日志不記錄關(guān)閉審計日志出事無從查證備份不驗證從未做過恢復(fù)測試關(guān)鍵時刻備份不可用這些坑看起來低級但存量系統(tǒng)里大量存在。我?guī)湍硞€客戶做安全咨詢的時候抽查他們的核心庫發(fā)現(xiàn)應(yīng)用連接串在代碼倉庫里明文保存而且應(yīng)用賬號擁有整個實例的ALL權(quán)限。雖然后來整改了但之前有沒有人通過泄露的代碼倉庫進入過數(shù)據(jù)庫沒人知道。這種歷史遺留風(fēng)險只能靠主動審計盡早發(fā)現(xiàn)。6.2 自查清單每季度做一次最后給一份可以直接抄作業(yè)的自查清單建議每季度做一次。每一項都不復(fù)雜但堅持做下來安全水位會明顯提高。賬號與權(quán)限[ ] 列出所有數(shù)據(jù)庫賬號標記負責(zé)人[ ] 清理超過90天未使用的賬號[ ] 確認應(yīng)用賬號沒有DELETE權(quán)限和DDL權(quán)限[ ] 確認管理賬號僅限少數(shù)人使用。認證與密碼[ ] 檢查是否存在弱口令、共用賬號[ ] 檢查連接串是否用密鑰管理而不是明文寫死[ ] 確認密碼輪換機制生效。網(wǎng)絡(luò)與暴露面[ ] 檢查數(shù)據(jù)庫端口是否有公網(wǎng)映射[ ] 確認應(yīng)用服務(wù)器到數(shù)據(jù)庫的訪問有IP白名單限制[ ] 確認遠程管理必須經(jīng)過堡壘機。加密與審計[ ] 檢查敏感列是否啟用加密[ ] 檢查數(shù)據(jù)庫連接是否強制SSL[ ] 確認審計日志已開啟并異地存儲。備份與恢復(fù)[ ] 確認備份任務(wù)的最近一次執(zhí)行成功[ ] 隨機抽一個備份做恢復(fù)測試[ ] 確認離線備份位置沒有被數(shù)據(jù)庫服務(wù)器直接訪問。這份清單適用于大多數(shù)中小規(guī)模數(shù)據(jù)庫環(huán)境。如果你管理的是大型集群還需要考慮多租戶隔離、變更審批流程、數(shù)據(jù)分類分級等更復(fù)雜的機制但底層邏輯不變權(quán)限最小化、數(shù)據(jù)加密、全程審計、可恢復(fù)。最后再分享一點個人體會我在實際工作中發(fā)現(xiàn)數(shù)據(jù)庫安全最核心的往往不是某一個高深技術(shù)而是持續(xù)的基礎(chǔ)管理。很多團隊在整改完弱口令和公網(wǎng)映射之后安全風(fēng)險已經(jīng)下降了大部分。剩下那些復(fù)雜方案可以慢慢補。不要一開始就追求“大而全”的安全架構(gòu)先把自己的家底盤清楚再逐項加固才是性價比最高的路徑。