數據庫管理員希望保護其千兆字節的重要業務數據免受未經授權的外部人員和企圖超越其權限的內部人士的窺視，因此安全性至關重要。 所有的關係數據庫管理系統都提供某種內在的安全機制，旨在將這些威脅降到最低。 它們的範圍從Microsoft Access提供的簡單密碼保護到高級關係數據庫（如Oracle和Microsoft SQL Server）支持的複雜用戶/角色結構。 本文重點介紹實現結構化查詢語言 （或SQL ）的所有數據庫通用的安全機制。 我們將一起完成加強數據訪問控制並確保數據安全的過程。
用戶
基於服務器的數據庫都支持類似於計算機操作系統中使用的用戶概念。 如果您熟悉在Microsoft Windows NT和Windows 2000中找到的用戶/組層次結構，則會發現SQL Server和Oracle支持的用戶/角色分組非常相似。
強烈建議您為將要訪問數據庫的每個人創建個人數據庫用戶帳戶。 技術上可以在用戶之間共享帳戶，或者簡單地為每種需要訪問數據庫的用戶類型使用一個用戶帳戶，但是我強烈勸阻這種做法有兩個原因。 首先，它將消除個人責任 - 如果用戶對數據庫進行更改（假設通過給自己提高5,000美元），則通過使用審計日誌將無法追溯到特定人員。 此外，如果特定用戶離開您的組織並且您希望從數據庫中刪除他或她的訪問權限，您將被迫更改所有用戶依賴的密碼。
創建用戶帳戶的方法因平台而異，您必須查閱您的DBMS特定文檔以了解確切的過程。 Microsoft SQL Server用戶應該調查sp_adduser存儲過程的使用情況。 Oracle數據庫管理員會發現CREATE USER命令很有用。 您也可能想要調查替代身份驗證方案。 例如，Microsoft SQL Server支持使用Windows NT集成安全性。 在這種方案下，用戶通過其Windows NT用戶帳戶被識別到數據庫，並且不需要輸入額外的用戶ID和密碼來訪問數據庫。 這種方法在數據庫管理員中非常流行，因為它將帳戶管理的負擔轉移給了網絡管理人員，並為最終用戶提供了簡單的登錄功能。
角色
如果您處於少數用戶的環境中，您可能會發現創建用戶帳戶並直接為其分配權限足以滿足您的需求。 但是，如果您擁有大量用戶，則很可能會因維護帳戶和適當的權限而負擔過重。 為了減輕這種負擔，關係數據庫支持角色的概念。 數據庫角色的功能與Windows NT組相似。 用戶帳戶分配給角色，然後將權限作為一個整體分配給角色，而不是單獨的用戶帳戶。 例如，我們可以創建DBA角色，然後將管理人員的用戶帳戶添加到此角色。 一旦我們完成了這個任務，我們可以通過簡單地為角色分配權限來為所有現在（和將來）的管理員分配特定的權限。 再一次，創建角色的過程因平台而異。 MS SQL Server管理員應調查sp_addrole存儲過程，而Oracle DBA應使用CREATE ROLE語法。
授予權限
現在我們已經將用戶添加到我們的數據庫中，現在可以通過添加權限來加強安全性。 我們的第一步將是為我們的用戶授予適當的數據庫權限。 我們將通過使用SQL GRANT語句來完成此操作。
以下是該語句的語法：
授予<權限>
[ON
]
TO <用戶/角色>
[有贈送選項]
現在，讓我們一行一行看看這個說法。 第一行GRANT 允許我們指定我們授予的特定表權限。 這些可以是表級權限（如SELECT，INSERT，UPDATE和DELETE）或數據庫權限（例如CREATE TABLE，ALTER DATABASE和GRANT）。 可以在單個GRANT語句中授予多個權限，但表級權限和數據庫級權限可能不會合併到一個語句中。
第二行ON
用於為表級權限指定受影響的表。 如果我們授予數據庫級權限，則此行將被省略。 第三行指定正在被授予權限的用戶或角色。
最後，第四行WITH GRANT OPTION是可選的。 如果該行包含在該語句中，則受影響的用戶也可以將這些相同的權限授予其他用戶。 請注意，將權限分配給角色時，不能指定WITH GRANT OPTION。
例子
我們來看幾個例子。 在我們的第一種情況下，我們最近僱用了一組42名數據錄入員，他們將增加和維護客戶記錄。 他們需要能夠訪問Customers表中的信息，修改此信息並向表中添加新記錄。 他們不應該能夠從數據庫中完全刪除記錄。 首先，我們應該為每個操作員創建用戶帳戶，然後將它們全部添加到新角色DataEntry中。 接下來，我們應該使用以下SQL語句為它們授予適當的權限：
授予選擇，插入，更新
ON客戶
到DataEntry
這就是它的全部！ 現在讓我們來看看我們分配數據庫級權限的情況。 我們希望允許DBA角色的成員將新表添加到我們的數據庫中。 此外，我們希望他們能夠授予其他用戶同樣的權限。 這是SQL語句：
授予創建表
致DBA
贈與選項
請注意，我們已經包含了WITH GRANT OPTION行，以確保我們的DBA可以將此權限分配給其他用戶。
刪除權限
一旦我們授予權限，通常證明有必要在以後撤銷它們。 幸運的是，SQL為我們提供了REVOKE命令來刪除以前授予的權限。 語法如下：
REVOKE [授予選項] <權限>
ON
FROM
您會注意到，該命令的語法與GRANT命令的語法相似。 唯一的區別在於WITH GRANT OPTION是在REVOKE命令行上指定的，而不是在命令的末尾。 舉個例子，讓我們想像一下，我們想撤銷Mary之前授予的從Customers數據庫中刪除記錄的權限。 我們將使用以下命令：
REVOKE DELETE
ON客戶
瑪麗
這就是它的全部！ 還有一個額外的機制是由Microsoft SQL Server支持的，值得一提的是DENY命令。 這個命令可以用來顯式拒絕他們可能通過當前或將來角色成員身份獲得的用戶權限。 語法如下：
DENY <權限>
ON
TO <用戶/角色
例子
回到我們之前的例子，我們假設Mary也是可以訪問Customers表的Managers角色的成員。 之前的REVOKE聲明不足以拒絕她進入桌子。 它將通過以她的用戶帳戶為目標的GRANT語句刪除授予她的權限，但不會影響通過其在Managers角色中的成員資格獲得的權限。 但是，如果我們使用DENY語句，它將阻止她繼承權限。 這裡是命令：
拒絕刪除
ON客戶
對瑪麗
DENY命令實質上在數據庫訪問控制中創建了“否定權限”。 如果我們後來決定授予Mary從Customers表中刪除行的權限，我們不能簡單地使用GRANT命令。 該命令將立即被現有的DENY覆蓋。 相反，我們首先使用REVOKE命令刪除否定權限條目，如下所示：
REVOKE DELETE
ON客戶
瑪麗
您會注意到，該命令與用於刪除肯定權限的命令完全相同。 請記住，DENY和GRANT命令都以類似的方式工作* mdash;它們都在數據庫訪問控制機制中創建權限（正數或負數）。 REVOKE命令刪除指定用戶的所有正面和負面權限。 一旦發布此命令，Mary將能夠從表中刪除行，如果她是擁有該權限的角色的成員。 或者，可以發出GRANT命令來直接向她的帳戶提供DELETE權限。
在本文的整個過程中，您都了解了標準查詢語言支持的訪問控制機制。 本介紹應該為您提供一個良好的起點，但我鼓勵您引用DBMS文檔以了解您的系統支持的增強安全措施。 您會發現很多數據庫都支持更高級的訪問控制機制，例如授予特定列的權限。