---

前言

• 在前幾期博客中，我們探討了 SQL 連接查詢，單表查詢，嵌套查詢，集合查詢，基于派生表的查詢，數據插入，修改與刪除，空值的處理，視圖技術等知識點。
• 從本節開始，我們將深入講解 SQL 中數據庫安全性的知識點。

我的個人主頁，歡迎來閱讀我的其他文章
https://blog.csdn.net/2402_83322742?spm=1011.2415.3001.5343
我的數據庫系統概論專欄
https://blog.csdn.net/2402_83322742/category_12911520.html?spm=1001.2014.3001.5482

---

一、數據庫安全性

1. 什么是數據庫安全性？

• 數據庫安全性就像是給數據庫配備的“安全保鏢”，其主要任務是防止非法用戶對數據庫進行訪問，阻止非法操作導致的數據泄露、被篡改或者遭到破壞。

舉個簡單的例子，銀行的用戶儲蓄數據、醫院的患者醫療檔案等都屬于敏感信息，必須通過數據庫安全性措施來確保它們的安全。

2. 為何會存在安全問題？

數據庫的顯著特點之一是數據共享，但這種共享并非毫無條件。如果不加以限制，軍事機密、企業的市場營銷策略等敏感數據就可能被別有用心的人獲取。

• 所以，數據共享必須建立在安全的基礎之上，這就需要借助一系列的安全機制來實現。

二、安全標準的發展

數據庫安全問題日益受到關注，各國紛紛制定了相關的安全標準，這些標準的發展大致經歷了以下幾個階段：

1. 早期的“開拓者”：TCSEC標準

• 誕生背景：1985年，美國國防部發布了《可信計算機系統評估準則》（TCSEC），這是首個針對計算機系統安全的評估標準，后來又推出了針對數據庫的擴展標準TDI（紫皮書）。
• 安全級別劃分（從低到高）：
  • D級（最低保護）：這類系統幾乎沒有任何安全機制，就像一個不設門禁的倉庫，任何人都能隨意進出。例如DOS系統，在安全性方面幾乎沒有專門的保障措施。
  • C1級（自主安全保護）：實現了用戶和數據的初步分離，允許用戶自主設置權限，就好像給倉庫上了一把普通的鎖，只有擁有鑰匙（權限）的人才能進入。現在的大多數商業系統基本都能達到這個級別。
  • C2級（受控存取保護）：在C1級的基礎上進一步細化，要求用戶進行身份注冊，就如同倉庫管理員會記錄每個進入者的身份，并且對操作進行審計。例如Windows 2000和Oracle 7就符合這個級別。
  • B級（強制存取控制）：這是“安全產品”的級別，采用強制存取控制（MAC），就像倉庫對不同重要程度的物品設置了不同的進入權限，只有符合特定級別的人才能接觸相應的物品。其中：
    • B1級：要求對數據進行標記（如“機密”“公開”），并實施強制訪問控制，例如Trusted Oracle 7數據庫。
    • B2級：需要建立形式化的安全模型，對系統內的所有主體（用戶、進程等）和客體（數據、文件等）都進行嚴格控制。
    • B3級：具備更強的審計和恢復能力，確保系統在出現問題時能夠及時恢復。
  • A1級（最高級別）：不僅要達到B3級的要求，還需要對系統的設計進行形式化驗證，就像經過嚴格的數學證明一樣，確保安全機制確實有效。

2. 走向國際統一：CC標準

• 發展歷程：由于各國的標準存在差異，1993年，美國、歐洲、加拿大等國家和地區聯合開展了CC項目，旨在統一安全標準。1999年，CC成為國際標準（ISO 15408），2001年我國也采用其作為國家標準，如今它已成為評估信息產品安全性的主要標準。
• 核心特點：
  • 將安全要求分為兩類：
    • 安全功能要求：規定了產品需要具備哪些安全功能，例如訪問控制、加密等。
    • 安全保證要求：關注產品的開發過程和測試，確保安全功能是可靠的。
  • 評估保證級（EAL）：從EAL1到EAL7共7個級別，級別越高，安全性越強，并且與TCSEC級別有對應關系：

    評估保證級	特點	對應TCSEC級別
    EAL1	僅進行功能測試	無對應（安全性較低）
    EAL2	進行結構測試	C1級
    EAL3	系統地測試和檢查	C2級
    EAL4	系統地設計、測試和復查	B1級
    EAL5	半形式化設計和測試	B2級
    EAL6	半形式化驗證的設計和測試	B3級
    EAL7	形式化驗證的設計和測試	A1級

3. TCSEC和CC標準有什么不同？

維度	TCSEC	CC標準
適用范圍	主要針對美國政府和軍方系統	是國際通用標準，適用于各類信息產品
安全要求	級別劃分較粗，側重于強制存取控制	明確區分功能要求和保證要求，更加全面
評估方式	以級別劃分（如C1、B1）	以評估保證級（EAL）劃分，更具靈活性
現狀	逐漸被CC標準取代	成為主流標準，廣泛應用于全球

三、數據庫安全性控制

1. 第一層防線：用戶身份鑒別

為什么需要這一步？
就像進入銀行需要先證明“你是你自己”，數據庫也需要確認用戶身份，防止陌生人闖入。
常見的鑒別方法：

1. 靜態口令（最基礎）
   • 比如設置“密碼”（如“user123”），但容易被破解（像家門鑰匙可能被偷配）。
2. 動態口令（更安全）
   • 比如手機短信驗證碼、APP生成的動態數字（每分鐘一變），像每次進門都需要新鑰匙。
3. 生物特征（高級）
   • 指紋、人臉、虹膜識別（獨一無二），類似“只有本人指紋才能開門”。
4. 智能卡（硬件輔助）
   • 比如銀行卡+密碼，必須同時擁有卡和密碼才能訪問（像“鑰匙+密碼鎖”雙重保障）。

2. 第二層防線：存取控制（決定能看什么、做什么）

（1） 自主存取控制（DAC）

核心思想：用戶自己決定“誰能訪問我的數據，能怎么訪問”，類似“老師給學生發作業權限”。

• 權限類型（以學生成績表為例）：
  • 查詢（SELECT）：允許查看成績。
  • 修改（UPDATE）：允許修改分數。
  • 刪除（DELETE）：允許刪除記錄。
• 如何授權/回收？
  • 授權語句（GRANT）：

    GRANT SELECT ON TABLE 成績表 TO 學生A;  -- 允許學生A查詢成績
    

  • 回收語句（REVOKE）：

    REVOKE UPDATE ON TABLE 成績表 FROM 學生B;  -- 禁止學生B修改成績
    

• 特點：靈活但有漏洞。比如老師不小心把“修改權限”給了學生，可能導致數據被誤改或泄露。

（2）數據庫角色：批量管理權限的“快捷方式”

為什么需要角色？
當有多個用戶需要相同權限時，逐個授權太麻煩。比如“財務部員工”都需要訪問工資表，可創建一個“財務角色”，一次性授權給所有人。

• 步驟示例：
  1. 創建角色：

     CREATE ROLE 財務角色;
     

  2. 給角色授權：

     GRANT SELECT, UPDATE ON TABLE 工資表 TO 財務角色;  -- 角色擁有查詢和修改權限
     

  3. 將角色授予用戶：

     GRANT 財務角色 TO 張三, 李四, 王五;  -- 三人自動獲得角色權限
     

  4. 回收角色權限：

     REVOKE 財務角色 FROM 張三;  -- 張三失去財務相關權限
     

優點：像“給一群人發相同鑰匙”，管理效率高。

（3）強制存取控制（MAC）：嚴防死守的密級管理

為什么需要MAC？
DAC的漏洞在于“用戶可能無意泄露數據”。比如：

• 財務人員A有權限訪問“絕密級”工資表，但他復制了一份表并“不小心”分享給公開用戶，DAC無法阻止（因為A有復制權限）。
  MAC如何解決？
  給數據和用戶都打上“密級標簽”，強制規定：
• 讀規則：用戶的密級 ≥ 數據密級，才能讀取（比如“機密級”用戶只能讀“機密級”或更低的數據）。
• 寫規則：用戶的密級 ≤ 數據密級，才能寫入（比如“機密級”用戶只能往“機密級”或更高密級的數據里寫，防止高權限用戶誤改低密級數據）。
  類比場景：
• 軍隊中，只有“上校”（高密級用戶）能讀取“絕密文件”（高密級數據），且不能將絕密內容寫入“公開文件”（低密級數據），避免敏感信息泄露。

MAC與DAC的配合：

1. 先進行DAC檢查：判斷用戶是否有“查詢/修改”等權限（如“學生A是否有權限查成績”）。
2. 再進行MAC檢查：判斷用戶密級是否符合數據密級（如“學生A的密級是否≥成績表的密級”）。

總結：DAC是“權限開關”，MAC是“密級門禁”，雙重保障更安全。

3. 其他安全手段

1. 審計（Audit）
   • 記錄用戶對數據庫的所有操作（如“誰查了工資表，何時查的”），像“監控攝像頭”，用于事后追蹤問題。
2. 數據加密
   • 將數據變成亂碼（如“123456”加密為“!@#$%^”），即使數據被竊取，沒有密鑰也無法破解，類似“給文件上密碼鎖”。
3. 視圖（View）
   • 隱藏敏感數據，只給用戶看部分內容。比如給普通員工的“工資視圖”只顯示自己的工資，不顯示他人工資，像“透過小孔看風景，只能看到部分”。

總結

層次	手段	作用描述
最外層	用戶身份鑒別	攔住無關人員，確認“你是誰”
第二層	自主存取控制（DAC）	靈活分配權限，決定“你能做什么”
第三層	強制存取控制（MAC）	按密級嚴格管控，防止“無意泄露”
輔助層	審計、加密、視圖等	記錄操作、加密數據、隱藏敏感信息，全方位加固

四、視圖機制

1. 為什么需要視圖？

• 場景：老師想讓學生只能看到自己的成績，而看不到全班成績表。
• 傳統授權的局限：GRANT SELECT ON 成績表 TO 學生 會讓學生看到整個表的數據，無法只允許查看某一行（如自己的成績）。
• 視圖的作用：視圖就像一扇“窗戶”，可以從完整的數據表中“截取”部分數據（行或列），用戶通過視圖只能看到窗戶內的內容。

2. 如何用視圖實現安全控制？

示例：計科專業老師只能查看本專業學生信息

1. 創建計科學生視圖（只包含計算機科學與技術專業的學生）：

   CREATE VIEW 計科學生視圖 AS 
   SELECT * FROM 學生表 WHERE 專業='計算機科學與技術';
   

   這個視圖相當于從“學生表”中切出一個“計科學生”的小窗口。
2. 授權：
   • 給小明老師授權只能查詢視圖：

     GRANT SELECT ON 計科學生視圖 TO 小明;
     

     小明通過視圖只能看到計科學生的數據，看不到其他專業學生。
   • 給系主任張三授權所有權限：

     GRANT ALL PRIVILEGES ON 計科學生視圖 TO 張三;
     

     張三可以通過視圖增刪改查計科學生數據，但同樣看不到其他專業數據。

3. 核心優勢

• 隱藏敏感數據：通過視圖屏蔽無關行/列，比如工資表中只讓員工看到自己的工資列。
• 與授權結合：視圖相當于“數據過濾器”，授權決定“誰能看”，視圖決定“能看什么”。

五、審計

1. 什么是審計？

• 類比：超市安裝監控攝像頭，記錄所有顧客的行為，以便事后追查盜竊或糾紛。
• 數據庫中的審計：開啟審計后，數據庫會自動記錄用戶的所有操作（如查詢、修改、刪除），包括：
  • 誰操作的（用戶賬號）
  • 何時操作的（時間戳）
  • 操作了什么數據（如表名、列名）
  • 數據前后的變化（如修改前工資是5000，修改后是6000）

2. 審計有什么用？

• 追蹤非法操作：如果工資表被篡改，通過審計日志可以查到是誰在幾點修改了數據。
• 合規要求：金融、醫療等行業必須記錄操作日志，滿足監管要求。
• 性能分析：通過分析日志，發現高頻操作或慢查詢，優化數據庫。

3. 審計的類型和適用場景

• 用戶級審計：用戶自己設置，監控自己創建的表。比如小王對自己的“報銷表”開啟審計，查看誰修改過。
• 系統級審計：只有管理員（DBA）能設置，監控整個數據庫。比如銀行DBA開啟對“轉賬表”的審計，防止內部人員篡改交易記錄。
• 注意：審計會增加存儲和性能開銷，默認不開啟，僅在高安全需求場景（如銀行、政府）使用。

4. 數據庫對審計的支持

• SQL Server：2008版本后自帶審計功能，可記錄登錄、語句執行等。
• MySQL：企業版收費提供審計，社區版需用第三方插件（如MariaDB Audit Plugin）。
• 示例：對“成績表”的修改操作開啟審計：

  -- 打開審計開關
  SET AUDIT_TRAIL TO ON;
  -- 對成績表的更新和刪除操作進行審計
  AUDIT UPDATE, DELETE ON 成績表;
  

六、數據加密

1. 為什么需要數據加密？

• 場景：數據在硬盤存儲時被偷，或在網絡傳輸時被截獲。如果數據是明文（如“張三工資8000”），攻擊者可直接讀取；如果是密文（如“@#$%&*”），則無法理解。
• 核心思想：將明文（原始數據）通過算法變成密文（亂碼），只有擁有密鑰的人才能解密回明文。

2. 加密的時機和方法

• 按階段劃分：
  • 傳輸加密：數據在網絡中傳輸時加密（如從客戶端到數據庫服務器），防止中途被截獲。類似快遞包裹用密碼鎖封裝。
  • 存儲加密：數據存到硬盤時加密，防止硬盤被盜后數據泄露。類似行李箱用密碼鎖鎖住。
• 按算法劃分：
  • 對稱加密（如DES）：加密和解密用同一把鑰匙（密鑰），速度快但密鑰需保密。類似“一把鑰匙開一把鎖”。
  • 非對稱加密（如RSA）：用公鑰加密，私鑰解密，密鑰成對出現。公鑰可公開，私鑰需保密。類似“用鎖頭鎖門，用鑰匙開門”。

3. 簡單加密示例：凱撒密碼（替換法）

• 明文：I love you
• 加密規則：每個字母后移3位（如A→D，B→E）。
• 密文：L oryh brx
• 解密：每個字母前移3位，還原為明文。

4. 數據庫中的加密實現

• 庫內加密：在數據庫內部自動完成加密和解密，用戶感覺不到（透明加密）。比如數據寫入硬盤前自動加密，讀取時自動解密。
• 庫外加密：在客戶端或應用層先加密數據，再存入數據庫。數據庫存儲的是密文，但需要應用自己管理密鑰。
• 優缺點對比：

  方式	優點	缺點
  庫內加密	對應用透明，操作簡單	依賴數據庫廠商，可能影響性能
  庫外加密	靈活性高，適合定制化需求	需自行管理密鑰，增加開發成本

5. 總結三層安全手段

手段	核心功能	類比場景
視圖機制	限制數據可見范圍，屏蔽敏感行/列	用窗戶限定能看到的風景
審計	記錄所有操作，用于事后追蹤和安全分析	超市監控攝像頭記錄顧客行為
數據加密	防止數據在存儲和傳輸中被竊取或泄露	給文件加密碼鎖，防止被偷看

七、其它安全性保護（了解就好）

1. 推理控制

1.1 什么是推理控制？

• 場景引入：假設數據庫中有兩張表：
  • 公開表：記錄職工號、姓名、職務（如“張三，程序員”）。
  • 機密表：記錄職工號、工資（如“張三，月薪20000”）。
  • 普通用戶只能訪問公開表，但通過“職務→工資”的常識（如“程序員的平均工資約15000-25000”），可能推斷出張三的工資屬于該范圍，甚至結合其他同事數據精準推算出具體數值。
• 定義：推理控制是防止用戶利用公開數據和背景知識，間接推斷出敏感數據的安全機制，解決MAC（強制存取控制）未覆蓋的“邏輯漏洞”。

1.2 為什么需要推理控制？

• MAC的局限：MAC通過密級限制直接訪問（如工資表設為“機密”，普通用戶無法直接查詢），但無法阻止用戶通過公開數據“間接推理”機密信息。

• 示例：

  職工號	姓名	職務	（公開）
  001	張三	高級工程師
  002	李四	實習生

  職工號	工資	（機密）
  001	30000
  002	5000

  • 用戶已知“高級工程師工資遠高于實習生”，即使看不到工資列，也能推斷001的工資高于002，可能進一步通過行業數據估算具體數值。

1.3 常用的推理控制方法

• 方法1：基于函數依賴的推理控制
  • 禁止公開數據中存在與敏感數據的“固定關聯”。
  • 例：如果“職務→工資范圍”是強關聯（如“實習生工資固定為5000”），則隱藏“職務”或“工資”中的一方，避免用戶通過函數關系（職務→工資）推斷。
• 方法2：基于敏感關聯的推理控制
  • 打亂公開數據與敏感數據的關聯，增加推理難度。
  • 例：在公開表中不顯示“職務”，改為“崗位編號”（如“崗位A、崗位B”），且崗位編號與工資無明確對應關系，用戶無法通過崗位推斷工資。

2. 經濟學角度的安全考量：沒有絕對安全，只有性價比最優

2.1 為什么沒有“絕對安全”的系統？

• 技術層面：任何加密算法或安全措施都可能被破解（如量子計算可能破解RSA加密），只是時間和成本問題。
• 現實層面：投入無限資源追求絕對安全不現實。例如：
  • 保護“明天的天氣預測”數據，投入百萬級加密措施顯然不合理，因為數據過了今天就失去價值。

2.2 什么是“經濟上安全”的系統？

• 標準1：破譯成本＞信息價值
  • 若黑客破譯數據的成本（如購買設備、雇傭專家的費用）超過數據本身的價值，則系統是安全的。
  • 例：保護“某公司明天的股票交易策略”，若策略帶來的收益預期為10萬元，而破譯需要花費20萬元，黑客會因“不劃算”放棄攻擊。
• 標準2：破譯時間＞信息生命周期
  • 若數據在被破譯前已失去時效性，則系統是安全的。
  • 例：保護“雙十一促銷活動細節”，活動結束后數據價值驟降，即使一周后被破譯，也不會造成損失。

2.3 如何應用經濟學思維設計安全方案？

• 步驟1：評估數據價值和生命周期
  • 敏感數據（如用戶隱私）：價值高、生命周期長，需投入較高安全成本（如AES-256加密、定期密鑰更換）。
  • 臨時數據（如臨時驗證碼）：價值低、生命周期短，使用簡單加密（如Base64編碼）即可。
• 步驟2：平衡成本與收益
  • 小企業無需采購千萬級的加密硬件，選擇云服務商提供的標準化加密服務（如阿里云SSL證書）更經濟。
  • 金融機構則需投入高成本實現“量子加密+多重審計”，因為數據泄露的損失可能遠超防護成本。

---

以上就是這篇博客的全部內容，下一篇我們將繼續探索更多精彩內容。

我的個人主頁，歡迎來閱讀我的其他文章
https://blog.csdn.net/2402_83322742?spm=1011.2415.3001.5343
我的數據庫系統概論專欄
https://blog.csdn.net/2402_83322742/category_12911520.html?spm=1001.2014.3001.5482

非常感謝您的閱讀，喜歡的話記得三連哦