|
注意我們?nèi)匀粵]有授權(quán)任何組或帳戶訪問數(shù)據(jù)庫。事實上,我們不能通過Enterprise Manager授權(quán)數(shù)據(jù)庫訪問,因為Enterprise Manager的用戶界面只允許我們把數(shù)據(jù)庫訪問權(quán)限授予合法的登錄帳戶。SQL Server不要求NT帳戶在我們把它設置為數(shù)據(jù)庫角色的成員或分配對象權(quán)限之前能夠訪問數(shù)據(jù)庫,但Enterprise Manager有這種限制。盡管如此,只要我們使用的是sp_addrolemember存儲過程而不是Enterprise Manager,就可以在不授予域內(nèi)NT帳戶數(shù)據(jù)庫訪問權(quán)限的情況下為任意NT帳戶分配權(quán)限。
到這里為止,對Model數(shù)據(jù)庫的設置已經(jīng)完成。但是,如果你的用戶群體對企業(yè)范圍內(nèi)各個應用數(shù)據(jù)庫有著類似的訪問要求,你可以把下面這些操作移到Model數(shù)據(jù)庫上進行,而不是在面向特定應用的數(shù)據(jù)庫上進行。
四、允許數(shù)據(jù)庫訪問
在數(shù)據(jù)庫內(nèi)部,與迄今為止我們對登錄驗證的處理方式不同,我們可以把權(quán)限分配給角色而不是直接把它們分配給全局組。這種能力使得我們能夠輕松地在安全策略中使用SQL Server驗證的登錄。即使你從來沒有想要使用SQL Server登錄帳戶,本文仍舊建議分配權(quán)限給角色,因為這樣你能夠為未來可能出現(xiàn)的變化做好準備。
創(chuàng)建了數(shù)據(jù)庫之后,我們可以用sp_grantdbaccess存儲過程授權(quán)DB_Name Users組訪問它。但應該注意的是,與sp_grantdbaccess對應的sp_denydbaccess存儲過程并不存在,也就是說,你不能按照拒絕對服務器訪問的方法拒絕對數(shù)據(jù)庫的訪問。如果要拒絕數(shù)據(jù)庫訪問,我們可以創(chuàng)建另外一個名為DB_Name Denied Users的全局組,授權(quán)它訪問數(shù)據(jù)庫,然后把它設置為db_denydatareader以及db_denydatawriter角色的成員。注意SQL語句權(quán)限的分配,這里的角色只限制對對象的訪問,但不限制對DDL(Data Definition Language,數(shù)據(jù)定義語言)命令的訪問。
正如對登錄過程的處理,如果訪問標記中的任意SID已經(jīng)在Sysusers系統(tǒng)表登記,SQL將允許用戶訪問數(shù)據(jù)庫。因此,我們既可以通過用戶的個人NT帳戶SID授權(quán)用戶訪問數(shù)據(jù)庫,也可以通過用戶所在的一個(或者多個)組的SID授權(quán)。為了簡化管理,我們可以創(chuàng)建一個名為DB_Name Users的擁有數(shù)據(jù)庫訪問權(quán)限的全局組,同時不把訪問權(quán)授予所有其他的組。這樣,我們只需簡單地在一個全局組中添加或者刪除成員就可以增加或者減少數(shù)據(jù)庫用戶。
五、分配權(quán)限
實施安全策略的最后一個步驟是創(chuàng)建用戶定義的數(shù)據(jù)庫角色,然后分配權(quán)限。完成這個步驟最簡單的方法是創(chuàng)建一些名字與全局組名字配套的角色。例如對于前面例子中的會計系統(tǒng),我們可以創(chuàng)建Accounting Data Entry Operators、Accounting Data Entry Managers之類的角色。由于會計數(shù)據(jù)庫中的角色與帳務處理任務有關,你可能想要縮短這些角色的名字。然而,如果角色名字與全局組的名字配套,你可以減少混亂,能夠更方便地判斷出哪些組屬于特定的角色。
創(chuàng)建好角色之后就可以分配權(quán)限。在這個過程中,我們只需用到標準的GRANT、REVOKE和DENY命令。但應該注意DENY權(quán)限,這個權(quán)限優(yōu)先于所有其他權(quán)限。如果用戶是任意具有DENY權(quán)限的角色或者組的成員,SQL Server將拒絕用戶訪問對象。
接下來我們就可以加入所有SQL Server驗證的登錄。用戶定義的數(shù)據(jù)庫角色可以包含SQL Server登錄以及NT全局組、本地組、個人帳戶,這是它最寶貴的特點之一。用戶定義的數(shù)據(jù)庫角色可以作為各種登錄的通用容器,我們使用用戶定義角色而不是直接把權(quán)限分配給全局組的主要原因就在于此。
由于內(nèi)建的角色一般適用于整個數(shù)據(jù)庫而不是單獨的對象,因此這里建議你只使用兩個內(nèi)建的數(shù)據(jù)庫角色,,即db_securityadmin和db_owner。其他內(nèi)建數(shù)據(jù)庫角色,例如db_datareader,它授予對數(shù)據(jù)庫里面所有對象的SELECT權(quán)限。雖然你可以用db_datareader角色授予SELECT權(quán)限,然后有選擇地對個別用戶或組拒絕SELECT權(quán)限,但使用這種方法時,你可能忘記為某些用戶或者對象設置權(quán)限。一種更簡單、更直接而且不容易出現(xiàn)錯誤的方法是為這些特殊的用戶創(chuàng)建一個用戶定義的角色,然后只把那些用戶訪問對象所需要的權(quán)限授予這個用戶定義的角色。 |
【收藏】【打印】【進入論壇】 |
|
|
|
|
|
|
|