【吐血整理】数据库的安全性
本文主講 數據庫的安全性，歡迎閱讀~
📋目錄
- 前言：
- 一、數據庫安全性概述
- 二、數據庫安全性控制
- 1. 用戶身份鑒別
- 2. 存取控制
- 3. 自主存取控制方法
- 4. 授權：授予與回收
- 5. 數據庫角色
- 6. 強制存取控制方法
- 三、視圖機制
- 四、審計（Audit）
- 五、數據加密
前言：
數據庫的一大特點是數據共享
數據共享必然帶來數據庫的安全性問題
數據庫系統中的數據共享不能是無條件的共享
數據庫的安全性：
保護數據庫以防止不合法使用所造成的數據泄露、更改或破壞
· 系統安全保護措施是否有效是數據庫系統主要的性能指標之一
一、數據庫安全性概述
1 . 數據庫的不安全因素
① 非授權用戶對數據庫的惡意存取和破壞
獵取用戶名和用戶口令，然后假冒合法用戶偷取、修改甚至破壞用戶數據。
② 數據庫中重要或敏感的數據被泄露
黑客和敵對分子千方百計盜竊數據庫中的重要數據，一些機密信息被暴露。
③ 安全環境的脆弱性
數據庫安全性與計算機系統安全性緊密聯系（計算機硬件、操作系統、網絡等安全性）
2 . 安全標準簡介
CC（Common Criteria）：2008年，CC V3.1 ISO/IEC15408-2008
CC評估等級分為EAL1、EAL2、EAL3、EAL4、EAL5、EAL6和EAL7共七個等級，等級越高，表示通過認證需要滿足的安全保證要求越多，系統的安全特性越可靠。
國際標準化組織（International Organization for Standardization，ISO）
二、數據庫安全性控制
非法使用數據庫的情況：
① 編寫合法程序繞過DBMS及其授權機制
② 直接（或編寫應用程序）執行非授權操作
③ 通過多次合法查詢數據庫從中推導出一些保密數據
計算機系統中，安全措施是一級一級層層設置的：
① 用戶標識鑒定用戶身份，合法用戶準許進入系統
② 數據庫管理系統還要進行存取控制，只允許用戶執行合法操作
③ 操作系統有自己的保護措施
④ 數據以密文形式存儲到數據庫中
（ps：數據以密文形式存儲在數據庫中，即使前三層被攻破，最后看到的是密文的話，是比較有安全性的）
數據庫安全性控制的常用方法：
用戶標識和鑒定、存取控制、視圖、審計、數據加密
數據庫管理系統安全性控制模型：
1. 用戶身份鑒別
① 靜態口令鑒別
靜態口令一般由用戶自己設定，這些口令是靜態不變的（例如自己設置的各種登陸密碼即靜態口令）
② 動態口令鑒別
口令是動態變化的，每次鑒別時均需使用動態產生的新口令登錄數據庫管理系統，即采用一次一密的方法（例如有的地方每次登陸需要手機短信驗證，每次發的驗證碼就是動態口令~）
③ 生物特征鑒別
通過生物特征進行認證的技術，生物特征如人臉、指紋等（現在這個技術比較普遍啦，很多智能手機上都有指紋識別和人臉識別）
④ 智能卡鑒別
智能卡是一種不可復制的硬件，內置集成電路的芯片，具有硬件加密功能（例如：IC銀行卡，IC卡是以芯片作為介質的銀行卡，與磁條卡相比，芯片卡安全性高，卡內敏感數據難以被復制）
2. 存取控制
存取控制機制組成：
- 定義用戶權限
DBMS提供適當的語言來定義用戶權限，存放在數據字典中，稱做安全規則或授權規則 - 合法權限檢查
用戶發出存取數據庫操作請求，DBMS查找數據字典，進行合法權限檢查
用戶權限定義和合法權檢查機制一起組成了DBMS的存取控制子系統
— — — — — — — — — — — — — — — — — — — — — — — —
常用存取控制方法：
- 自主存取控制（DAC）
用戶對不同的數據對象有不同的存取權限
不同的用戶對同一對象也有不同的權限
用戶還可將其擁有的存取權限轉授給其他用戶 - 強制存取控制（MAC）
每一個數據對象被標以一定的密級
每一個用戶也被授予某一個級別的許可證
對于任意一個對象，具有合法許可證的用戶才可以存取
3. 自主存取控制方法
通過 SQL 的GRANT 語句和REVOKE 語句實現
定義用戶存取權限：定義用戶可以在哪些數據庫對象上進行哪些操作
關系數據庫系統中存取控制對象：
（ps：ALL PRIVLEGES 即全部權限）
4. 授權：授予與回收
① GRANT 授予
GRANT <權限>[,<權限>]... ON <對象類型> <對象名>[,<對象類型> <對象名>]… TO <用戶>[,<用戶>]... [WITH GRANT OPTION];WITH GRANT OPTION子句:
指定：可以再授予
沒有指定：不能傳播
語義：將對指定操作對象的指定操作權限授予指定的用戶（即寫了WITH GRANT OPTION的話，TO之后的用戶能繼續傳播相應的權限）
— — — — — — — — — — — — — — — — — — — — — — — —
這里舉例需要用到很多用戶，所以咱們先來新建幾個用戶：
關于如何創建登錄名和用戶，在查閱了大量資料和自己實踐后，我寫了一篇博客（做了基礎的講解和示范）：SQL Server 創建登錄名和用戶名【詳細介紹】
這里我采用如下格式在STUDENT數據庫下創建了U1~U7用戶及對應的登錄名：
用以下SQL語句可查看當前數據庫下的所有用戶：
exec sp_helpuser;
好了~創建成功啦，接下來一大波例子來襲👣
— — — — — — — — — — — — — — — — — — — — — — — —
🌟來看例 1： 把查詢Student表權限授給用戶U1：
不是，這第一個例子就這么不友好嗎……
這里T-SQL中是不支持上面的標準SQL的寫法的，將TABLE去掉后方能正常運行：
如下圖查看用戶U1確實被授予了查詢Student表的權限：
🌟來看例 2： 把對Student表和Course表的全部權限授予用戶U2和U3：
emmm，這……（T-SQL和標準SQL要不干脆干一架算了😶）
因為提示的是"PRIVILIGES"附近有語法錯誤，所以我查看了SQL官方文檔：GRANT (Transact-SQL)，發現T-SQL中是有PRIVILEGES這個參數的，其解釋是：包含此參數是為了符合 ISO 標準。 請不要更改 ALL 的行為。emm（人類迷惑行為？😅，誒，等等我的單詞好像寫錯了，是PRIVILEGES）
然后有如下圖中的報錯，原來是因為ON后面只能跟一個對象，所以我將其拆分成了兩個SQL語句：
這會兒提示的是：ALL 權限已不再推薦使用，并且只保留用于兼容性目的。它并不表示對實體定義了 ALL 權限。 官方文檔中對參數ALL有以下講解，很不錯👏！
很明顯，這里的例子中安全對象是表Student和Course，所以授予了U2和U3相應的權限（這里以U2為例查看）
🌟來看例 3： 把對表SC的查詢權限授予所有用戶：
這里的PUBLIC即表示授權給所有的用戶~
🌟來看例 4： 把查詢Student表和修改學生學號的權限授給用戶U4：
注意： 在對屬性列授權時必須明確指出相應屬性列名 ，如這里授予修改學生學號的權限，但是如果不加(Sno)那就成了授予修改整個表的權限了，，啥都能改，這不行哈
🌟來看例 5： 把對表SC的INSERT權限授予U5用戶，并允許他再將此權限授予其他用戶：
GRANT INSERT ON TABLE SC TO U5 WITH GRANT OPTION;-- T-SQL如下 GRANT INSERT ON SC TO U5 WITH GRANT OPTION;
加上WITH GRANT OPTION后，U5不僅擁有了對表SC的INSERT權限，還可以傳播此權限
🌟來看例 6： 使用登錄名U5登錄后執行如下語句（因為在一個數據庫中登錄名和用戶名是一一對應的，所以登錄U5后切換至STUDENT數據庫進行如下操作實驗），將權限授予給U6：
（ps：登錄名必須映射到數據庫用戶才能連接到數據庫。 一個登錄名可以作為不同用戶映射到不同的數據庫，但在每個數據庫中只能作為一個用戶進行映射
）
🌟來看例 7： 如上面的方法，U6還可以將此權限授予U7：
因為沒有WITH GRANT OPTION，所以U7不能再傳播此權限！！用登錄名U7登錄之后執行以下語句，系統報錯：無法對 對象 'SC' 執行 查找，因為它不存在，或者您沒有所需的權限，顯然STUDENT數據庫中是有SC表的，所以原因是U7不能傳播該權限
— — — — — — — — — — — — — — — — — — — — — — — —
② REVOKE 回收
語句的一般格式為：
🌟來看例 1： 把用戶U4修改學生學號的權限收回：
REVOKE UPDATE(Sno) ON TABLE Student FROM U4;-- T-SQL如下 REVOKE UPDATE(Sno) ON Student FROM U4;
U4修改學生學號的權限UPDATE(Sno)已成功收回~
🌟來看例 2： 收回所有用戶對表SC的查詢權：
🌟來看例 3： 把用戶U5對SC表的INSERT權限收回：
REVOKE INSERT ON TABLE SC FROM U5 CASCADE ;-- T-SQL如下 REVOKE INSERT ON SC FROM U5 CASCADE ;因為U5還將該權限傳播給了U6和U7，所以將U5的INSERT權限收回的時候應該使用CASCADE（級聯收回），否則拒絕執行該語句
如果U6或U7還從其他用戶處獲得對SC表的INSERT權限，則他們仍具有此權限，系統只收回直接或間接從U5處獲得的權限。如下如U6的該權限還從dbo獲得，所以當收回U5授予的權限之后，他仍然具有對SC表的INSERT權限。
執行上面的SQL語句后：
5. 數據庫角色
角色（ROLE）：被命名的一組與數據庫操作相關的權限
角色是權限的集合。可以為一組具有相同權限的用戶創建一個角色（所以在修改權限等的操作時對角色ROLE修改即可，不用再去麻煩地對每一個用戶修改）
它的優點是：簡化授權的過程
— — — — — — — — — — — — — — — —
1.角色的創建
2.給角色授權
GRANT <權限>[,<權限>]… ON <對象類型>對象名 TO <角色>[,<角色>]…3.將一個角色授予其他的角色或用戶
GRANT <角色1>[,<角色2>]… TO <角色3>[,<用戶1>]… [WITH ADMIN OPTION]ps：該語句把角色授予某用戶，或授予另一個角色，授予者是角色的創建者或擁有在這個角色上的ADMIN OPTION（即授予者能傳播該權限）
指定了WITH ADMIN OPTION則獲得某種權限的角色或用戶還可以把這種權限授予其他角色（能繼續傳播該權限）
一個角色的權限：直接授予這個角色的全部權限 + 其他角色授予這個角色的全部權限（這和上面例子中用戶權限可以疊加起來（來自很多用戶授予）是一樣的，即這里某個角色的權限可以來自很多角色）
4.角色權限的收回
REVOKE <權限>[,<權限>]… ON <對象類型> <對象名> FROM <角色>[,<角色>]…用戶可以回收角色的權限，從而修改角色擁有的權限
REVOKE執行者是：①角色的創建者；②擁有在這個（些）角色上的ADMIN OPTION
🌟來看例 1： 通過角色來實現將一組權限授予一個用戶：
步驟如下：
1）首先創建一個角色 R1
2）然后使用GRANT語句，使角色R1擁有Student表的 SELECT、UPDATE、INSERT權限
（ps：這里UPDATE和SELECT的權限在圖中看不到，需要把滾動條拉到下面，我就不截圖啦）
3）將這個角色授予夏雨，夏雪，夏冰雹。使他們具有角色R1所包含的全部權限
（首先，需要創建夏雨，夏雪，夏冰雹玲這三個用戶，因為這里只是需要用于做角色的實驗，所以我就不新建登錄名啦~ 能讓他們能被授予權限就ok，實在想創建登錄名的小伙伴看我上面講解用戶時寫的就行~）
emmm，T-SQL中不支持此寫法，官方文檔CREATE ROLE (Transact-SQL)中有相關介紹：
附上鏈接：ALTER ROLE (Transact-SQL)
所以咱們可以通過下面的SQL語句來為角色R1添加成員，相當于為成員授予了角色R1擁有的權限：
（ps：需要注意的是，一條SQL語句只能添加一個角色！！）
4） 可以一次性通過R1來回收夏雨的這3個權限
同樣的因為T-SQL不支持此寫法，所以我們通過刪除角色成員的方式來達到回收其權限的目的
ALTER ROLE R1 DROP MEMBER 夏雨;
🌟來看例 2： 角色的權限修改：
使角色R1在原來的基礎上增加了Student表的刪除權限
🌟來看例 3：
使R1減少了SELECT權限
— — — — — — — — — — — — — — — — — — — — — — — —
6. 強制存取控制方法
自主存取控制缺點： 可能存在數據的“無意泄露”
原因：這種機制僅僅通過對數據的存取權限來進行安全控制，而數據本身并無安全性標記
（自主存取控制能夠通過授權機制有效地控制其他用戶對敏感數據的存取。但是由于用戶對數據的存取權限是“自主”的，用戶可以自由地決定將數據的存取權限授予何人、決定是否也將“授權”的權限授予別人。在這種授權機制下，仍可能存在數據的“無意泄露”）
解決：對系統控制下的所有主客體實施強制存取控制策略
強制存取控制（MAC）：
· 保證更高程度的安全性
· 用戶不能直接感知或進行控制
· 適用于對數據有嚴格而固定密級分類的部門：軍事部門、政府部門
在強制存取控制中，數據庫管理系統所管理的全部實體被分為主體和客體兩大類
· 主體是系統中的活動實體，即：數據庫管理系統所管理的實際用戶
· 客體是系統中的被動實體，即：文件、基本表、索引、視圖
敏感度標記（Label）： 對于主體和客體，DBMS為它們每個實例（值）指派一個敏感度標記（Label）
敏感度標記分成若干級別：
絕密（Top Secret，TS）
機密（Secret，S）
可信（Confidential，C）
公開（Public，P）
TS>=S>=C>=P
主體的敏感度標記稱為許可證級別（Clearance Level）
客體的敏感度標記稱為密級（Classification Level）
強制存取控制規則：
（1）僅當主體的許可證級別大于或等于客體的密級時，該主體才能讀相應的客體
（2）僅當主體的許可證級別小于或等于客體的密級時，該主體才能寫相應的客體
簡單記作：向下讀，向上寫
就比如，某個TS（絕密）密級的主體把一個密級為TS的數據惡意地降為P（公開），然后把它寫回。這樣原來是TS密級的數據大家都可以讀到了，這樣就導致了TS密級數據的泄露
另一方面，如果許可證級別大于客體的密級能寫的話也很可怕，因為上級（領導）能在大家不知道的情況下隨意修改，這，，，肯定是不行的
至于為什么等于，是因為自己寫的東西自己肯定也要能看到吖，不然自己寫完就看不到了，寫錯了或是想再看看也沒辦法了，no way，，，
三、視圖機制
把要保密的數據對無權存取這些數據的用戶隱藏起來，對數據提供一定程度的安全保護
視圖機制間接地實現支持存取謂詞的用戶權限定義
🌟來看例子： 建立計算機系學生的視圖，把對該視圖的SELECT權限授于夏雨，把該視圖上的所有操作權限授于夏冰雹：
🙋什么是“存取謂詞”？
我的理解是，存取謂詞是能直接對數據進行操作（增刪改查）的謂詞，需要系統能支持給用戶定義相關的存取謂詞的權限，在不支持存取謂詞的系統中，可以先建立相關視圖，然后在視圖上進一步定義存取權限。
🙋為什么要用視圖間接實現，直接用基本表不可以么？
emmm，可以為不同的用戶定義不同的視圖，把數據對象限制在一定的范圍內，也就是說，通過視圖機制把要保密的數據對無權存取這些數據的用戶隱藏起來，對數據提供一定程度的安全保護（不想讓他看到的數據就不定義在視圖里，這相對于直接給他看基本表要安全很多）
四、審計（Audit）
什么是審計：
- 審計日志（Audit Log）： 將用戶對數據庫的所有操作記錄在上面（就像記錄流水賬一樣的）
- 審計員利用審計日志：
監控數據庫中的各種行為
找出非法存取數據的人、時間和內容。
審計功能的可選性：
· 審計很費時間和空間
· DBA可以打開或關閉審計功能
· 審計功能主要用于安全性要求較高的部門
AUDIT語句和NOAUDIT語句：
AUDIT語句：設置審計功能
NOAUDIT語句：取消審計功能
🌟來看例 1： 對修改SC表結構或修改SC表數據的操作進行審計：
AUDIT ALTER, UPDATE ON SC;這里T-SQL是不支持這樣寫的，具體寫法暫時沒搞明白，待弄清楚之后第一時間回來更新補充上~
先附上官方文檔：SQL Server 審核（數據庫引擎），慚愧慚愧，沒看明白這個官方文檔😅
🌟來看例 2： 取消對SC表的一切審計：
五、數據加密
數據加密： 防止數據庫中數據在存儲和傳輸中失密的有效手段
加密的基本思想： 根據一定的算法將原始數據—明文（Plain text）變換為不可直接識別的格式—密文（Cipher text）
加密方法： ①存儲加密；②傳輸加密
— — — — — — — — — — — — — — — — — —
存儲加密：
-
透明存儲加密
①內核級加密保護方式，對用戶完全透明
②將數據在寫到磁盤時對數據進行加密，授權用戶讀取數據時再對其進行解密
③數據庫的應用程序不需要做任何修改，只需在創建表語句中說明需加密的字段即可
內核級加密方法: 性能較好，安全完備性較高 -
非透明存儲加密：通過多個加密函數實現
傳輸加密（結合計算機網絡學習，我暫時還沒學習相關內容，所以這里就只是寫個大概，嘻嘻）：
- 鏈路加密
①在鏈路層進行加密
②傳輸信息由報頭和報文兩部分組成
③報文和報頭均加密 - 端到端加密
①在發送端加密，接收端解密
②只加密報文不加密報頭
③所需密碼設備數量相對較少，容易被非法監聽者發現并從中獲取敏感信息
那 關于數據庫安全性 部分到這里也就結束啦，感謝你耐心地閱讀~😊
如有不恰當的地方，望提出指正~
咱們下期 見~
總結
以上是生活随笔為你收集整理的【吐血整理】数据库的安全性的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： openbsd_仔细看一下OpenBSD
- 下一篇： 找工作，还是找户口？