四、允許數據庫訪問
在數據庫內部，與迄今為止我們對登錄驗證的處理方式不同，我們可以把權限分配給角色而不是直接把它們分配給全局組。這種能力使得我們能夠輕松地在安全策略中使用SQL Server驗證的登錄。即使你從來沒有想要使用SQL Server登錄帳戶，本文仍舊建議分配權限給角色，因為這樣你能夠為未來可能出現的變化做好准備。
創建了數據庫之後，我們可以用sp_grantdbaccess存儲過程授權 DB_Name Users組訪問它。但應該注意的是，與sp_grantdbaccess對應的sp_denydbAccess存儲過程並不存在，也就是說，你不能按照拒絕對服務器訪問的方法拒絕對數據庫的訪問。如果要拒絕數據庫訪問，我們可以創建另外一個名為DB_Name DenIEd Users的全局組，授權它訪問數據庫，然後把它設置為db_denydatareader以及db_denydatawriter角色的成員。注意 SQL語句權限的分配，這裡的角色只限制對對象的訪問，但不限制對DDL（Data Definition Language，數據定義語言）命令的訪問。
正如對登錄過程的處理，如果訪問標記中的任意SID已經在Sysusers系統表登記，SQL將允許用戶訪問數據庫。因此，我們既可以通過用戶的個人NT帳戶SID授權用戶訪問數據庫，也可以通過用戶所在的一個（或者多個）組的SID授權。為了簡化管理，我們可以創建一個名為DB_Name Users的擁有數據庫訪問權限的全局組，同時不把訪問權授予所有其他的組。這樣，我們只需簡單地在一個全局組中添加或者刪除成員就可以增加或者減少數據庫用戶。
五、分配權限
實施安全策略的最後一個步驟是創建用戶定義的數據庫角色，然後分配權限。完成這個步驟最簡單的方法是創建一些名字與全局組名字配套的角色。例如對於前面例子中的會計系統，我們可以創建Accounting Data Entry Operators、Accounting Data Entry Managers之類的角色。由於會計數據庫中的角色與帳務處理任務有關，你可能想要縮短這些角色的名字。然而，如果角色名字與全局組的名字配套，你可以減少混亂，能夠更方便地判斷出哪些組屬於特定的角色。
創建好角色之後就可以分配權限。在這個過程中，我們只需用到標准的GRANT、REVOKE和DENY命令。但應該注意DENY權限，這個權限優先於所有其他權限。如果用戶是任意具有DENY權限的角色或者組的成員，SQL Server將拒絕用戶訪問對象。
接下來我們就可以加入所有SQL Server驗證的登錄。用戶定義的數據庫角色可以包含SQL Server登錄以及NT全局組、本地組、個人帳戶，這是它最寶貴的特點之一。用戶定義的數據庫角色可以作為各種登錄的通用容器，我們使用用戶定義角色而不是直接把權限分配給全局組的主要原因就在於此。
由於內建的角色一般適用於整個數據庫而不是單獨的對象，因此這裡建議你只使用兩個內建的數據庫角色，即db_securityadmin和db_owner。其他內建數據庫角色，例如db_datareader，它授予對數據庫裡面所有對象的SELECT權限。雖然你可以用db_datareader角色授予SELECT權限，然後有選擇地對個別用戶或組拒絕SELECT權限，但使用這種方法時，你可能忘記為某些用戶或者對象設置權限。一種更簡單、更直接而且不容易出現錯誤的方法是為這些特殊的用戶創建一個用戶定義的角色，然後只把那些用戶訪問對象所需要的權限授予這個用戶定義的角色。
六、簡化安全管理
SQL Server驗證的登錄不僅能夠方便地實現，而且與NT驗證的登錄相比，它更容易編寫到應用程序裡。但是，如果用戶的數量超過25，或者服務器數量在一個以上，或者每個用戶都可以訪問一個以上的數據庫，或者數據庫有多個管理員，SQL Server驗證的登錄不容易管理。由於SQL Server沒有顯示用戶有效權限的工具，要記憶每個用戶具有哪些權限以及他們為何要得到這些權限就更加困難。即使對於一個數據庫管理員還要擔負其他責任的小型系統，簡化安全策略也有助於減輕問題的復雜程度。因此，首選的方法應該是使用NT驗證的登錄，然後通過一些精心選擇的全局組和數據庫角色管理數據庫訪問。
下面是一些簡化安全策略的經驗規則：
用戶通過SQL Server Users組獲得服務器訪問，通過DB_Name Users組獲得數據庫訪問。
用戶通過加入全局組獲得權限，而全局組通過加入角色獲得權限，角色直接擁有數據庫裡的權限。
需要多種權限的用戶通過加入多個全局組的方式獲得權限。
只要規劃得恰當，你能夠在域控制器上完成所有的訪問和權限維護工作，使得服務器反映出你在域控制器上進行的各種設置調整。雖然實際應用中情況可能有所變化，但本文介紹的基本措施仍舊適用，它們能夠幫助你構造出很容易管理的安全策略。
