在改進SQLServer7.0系列所實現的安全機制的過程中,Microsoft建立了一種既靈活又強大的安全管理機制,它能夠對使用者訪問 SQLServer伺服器系統和資料庫的安全進行全面地管理。按照本文介紹的步驟,你可以為SQLServer7.0(或2000)構造出一個靈活的、可管理的安全性原則,而且它的安全性經得起考驗。
一、驗證方法選擇
本文對驗證(authentication)和授權(authorization)這兩個概念作不同的解釋。驗證是指檢驗使用者的身份標識;授權是指允許使用者做些什麼。在本文的討論中,驗證過程在使用者登入SQLServer的時候出現,授權過程在使用者試圖訪問資料或執行命令的時候出現。
構造安全性原則的第一個步驟是確定SQLServer用哪種方式驗證使用者。SQLServer的驗證是把一群組帳戶、密碼與Master資料庫 Sysxlogins表中的一個清單進行匹配。WindowsNT/2000的驗證是請求網域控制站檢查使用者身份的合法性。一般地,如果伺服器可以訪問網域控制站,我們應該使用WindowsNT/2000驗證。網域控制站可以是Win2K伺服器,也可以是NT伺服器。無論在哪種情況下,SQLServer都接收到一個訪問標記(AccessToken)。訪問標記是在驗證過程中構造出來的一個特殊列表,其中包含了使用者的SID(安全標識號)以及一系列使用者所在組的SID。正如本文後面所介紹的,SQLServer以這些SID為基礎授予存取權限。注意,作業系統如何構造訪問標記並不重要,SQLServer只使用訪問標記中的SID。也就是說,不論你使用SQLServer2000、SQLServer7.0、Win2K還是NT進行驗證都無關緊要,結果都一樣。
如果使用SQLServer驗證的登入,它最大的好處是很容易通過EnterpriseManager實現,最大的缺點在於SQLServer 驗證的登入只對特定的伺服器有效,也就是說,在一個多伺服器的環境中管理比較困難。使用SQLServer進行驗證的第二個重要的缺點是,對於每一個資料庫,我們必須分別地為它系統管理權限。如果某個使用者對兩個資料庫有相同的許可權要求,我們必須手工設定兩個資料庫的許可權,或者編寫指令碼設定許可權。如果使用者數量較少,比如25個以下,而且這些使用者的許可權變化不是很頻繁,SQLServer驗證的登入或許適用。但是,在幾乎所有的其他情況下(有一些例外情況,例如直接管理安全問題的應用),這種登入方式的管理負擔將超過它的優點。
二、Web環境中的驗證
即使最好的安全性原則也常常在一種情形前屈服,這種情形就是在Web應用中使用SQLServer的資料。在這種情形下,進行驗證的典型方法是把一組SQLServer登入名稱稱和密碼嵌入到Web伺服器上啟動並執行程式,比如ASP頁面或者CGI指令碼;然後,由Web伺服器負責驗證使用者,應用程式則使用它自己的登入帳戶(或者是系統管理員sa帳戶,或者為了方便起見,使用Sysadmin伺服器角色中的登入帳戶)為使用者訪問資料。
這種安排有幾個缺點,其中最重要的包括:它不具備對使用者在伺服器上的活動進行審核的能力,完全依賴於Web應用程式實現使用者驗證,當 SQLServer需要限定使用者權限時不同的使用者之間不易區別。如果你使用的是IIS5.0或者IIS4.0,你可以用四種方法驗證使用者。第一種方法是為每一個網站和每一個虛擬目錄建立一個匿名使用者的NT帳戶。此後,所有應用程式登入SQLServer時都使用該安全環境。我們可以通過授予NT匿名帳戶合適的許可權,改進審核和驗證功能。
第二種方法是讓所有網站使用Basic驗證。此時,只有當使用者在對話方塊中輸入了合法的帳戶和密碼,IIS才會允許他們訪問頁面。IIS依靠一個 NT安全資料庫實現登入身分識別驗證,NT安全資料庫既可以在本機伺服器上,也可以在網域控制站上。當使用者運行一個訪問SQLServer資料庫的程式或者指令碼時,IIS把使用者為了瀏覽頁面而提供的身份資訊發送給伺服器。如果你使用這種方法,應該記住:在通常情況下,瀏覽器與伺服器之間的密碼傳送一般是不加密的,對於那些使用Basic驗證而安全又很重要的網站,你必須實現SSL(SecureSocketsLayer,安全通訊端層)。
在用戶端只使用IE5.0、IE4.0、IE3.0瀏覽器的情況下,你可以使用第三種驗證方法。你可以在Web網站上和虛擬目錄上都啟用NT驗證。IE會把使用者登入電腦的身份資訊發送給IIS,當該使用者試圖登入SQLServer時IIS就使用這些登入資訊。使用這種簡化的方法時,我們可以在一個遠程網站的域上對使用者身份進行驗證(該遠程網站登入到一個與運行著Web伺服器的域有著信任關係的域)。
最後,如果使用者都有個人數位憑證,你可以把那些認證映射到本地區的NT帳戶上。個人數位憑證與伺服器數位憑證以同樣的技術為基礎,它證明使用者身份標識的合法性,所以可以取代NT的Challenge/Response(質詢/回應)驗證演算法。Netscape和IE都自動在每一個頁面請求中把認證資訊發送給IIS。IIS提供了一個讓管理員把認證映射到NT帳戶的工具。因此,我們可以用數位憑證取代通常的提供帳戶名稱字和密碼的登入過程。
由此可見,通過NT帳戶驗證使用者時我們可以使用多種實現方法。即使當使用者通過IIS跨越Internet串連SQLServer時,選擇仍舊存在。因此,你應該把NT驗證作為首選的使用者身分識別驗證辦法。
三、設定全域群組
構造安全性原則的下一個步驟是確定使用者應該屬於什麼組。通常,每一個組織或應用程式的使用者都可以按照他們對資料的特定訪問要求分成許多類別。例如,會計應用軟體的使用者一般包括:資料輸入操作員,資料輸入管理員,報表編寫員,會計師,審計員,財務經理等。每一組使用者都有不同的資料庫訪問要求。
控制資料存取權限最簡單的方法是,對於每一組使用者,分別地為它建立一個滿足該組使用者權限要求的、域內全域有效組。我們既可以為每一個應用分別建立組,也可以建立適用於整個企業的、涵蓋廣泛使用者類別的組。然而,如果你想要能夠精確地瞭解群組成員可以做些什麼,為每一個應用程式分別建立組是一種較好的選擇。例如,在前面的會計系統中,我們應該建立DataEntryOperators、AccountingDataEntryManagers等組。請記住,為了簡化管理,最好為組取一個能夠明確表示出作用的名字。
除了面向特定應用程式的組之外,我們還需要幾個基本組。基本組的成員負責管理伺服器。按照習慣,我們可以建立下面這些基本組: SQLServerAdministrators,SQLServerUsers,SQLServerDeniedUsers, SQLServerDBCreators,SQLServerSecurityOperators, SQLServerDatabaseSecurityOperators,SQLServerDevelopers,以及DB_NameUsers(其中 DB_Name是伺服器上一個資料庫的名字)。當然,如果必要的話,你還可以建立其他組。
建立了全域群組之後,接下來我們可以授予它們訪問SQLServer的許可權。首先為SQLServerUsers建立一個NT驗證的登入並授予它登入許可權,把Master資料庫設定為它的預設資料庫,但不要授予它訪問任何其他資料庫的許可權,也不要把這個登入帳戶設定為任何伺服器角色的成員。接著再為SQLServerDeniedUsers重複這個過程,但這次要拒絕登入訪問。在SQLServer中,拒絕許可權始終優先。建立了這兩個組之後,我們就有了一種允許或拒絕使用者訪問伺服器的便捷方法。
為那些沒有直接在Sysxlogins系統資料表裡面登記的組授權時,我們不能使用EnterprisManagr,因為 EnterpriseManager只允許我們從現有登入名稱字的列表選擇,而不是域內所有組的列表。要訪問所有的組,請開啟QueryAnalyzer,然後用系統預存程序sp_addsrvrolemember以及sp_addrolemember進行授權。
對於動作伺服器的各個組,我們可以用sp_addsrvrolemember預存程序把各個登入加入到合適的伺服器角色: SQLServerAdministrators成為Sysadmins角色的成員,SQLServerDBCreators成為Dbcreator角色的成員,SQLServerSecurityOperators成為Securityadmin角色的成員。注意sp_addsrvrolemember 預存程序的第一個參數要求是帳戶的完整路徑。例如,BigCo域的JoeS應該是bigco/joes(如果你想用本地帳戶,則路徑應該是 server_name/joes)。
要建立在所有新資料庫中都存在的使用者,你可以修改Model資料庫。為了簡化工作,SQLServer自動把所有對Model資料庫的改動複製到新的資料庫。只要正確運用Model資料庫,我們無需定製每一個新建立的資料庫。另外,我們可以用sp_addrolemember預存程序把 SQLServerSecurityOperators加入到db_securityadmin,把SQLServerDevelopers加入到 db_owner角色。
注意我們仍然沒有授權任何組或帳戶訪問資料庫。事實上,我們不能通過EnterpriseManager授權資料庫訪問,因為 EnterpriseManager的使用者介面只允許我們把資料庫存取權限授予合法的登入帳戶。SQLServer不要求NT帳戶在我們把它設定為資料庫角色的成員或指派至許可權之前能夠訪問資料庫,但EnterpriseManager有這種限制。儘管如此,只要我們使用的是 sp_addrolemember預存程序而不是EnterpriseManager,就可以在不授予域內NT帳戶資料庫存取權限的情況下為任意NT帳戶分配許可權。
到這裡為止,對Model資料庫的設定已經完成。但是,如果你的使用者群體對企業範圍內各個應用程式資料庫有著類似的訪問要求,你可以把下面這些操作移到Model資料庫上進行,而不是在面向特定應用的資料庫上進行。
四、允許資料庫訪問
在資料庫內部,與迄今為止我們對登入驗證的處理方式不同,我們可以把許可權分配給角色而不是直接把它們分配給全域群組。這種能力使得我們能夠輕鬆地在安全性原則中使用SQLServer驗證的登入。即使你從來沒有想要使用SQLServer登入帳戶,本文仍舊建議分配許可權給角色,因為這樣你能夠為未來可能出現的變化做好準備。
建立了資料庫之後,我們可以用sp_grantdbaccess預存程序授權DB_NameUsers組訪問它。但應該注意的是,與 sp_grantdbaccess對應的sp_denydbaccess預存程序並不存在,也就是說,你不能按照拒絕對伺服器訪問的方法拒絕對資料庫的訪問。如果要拒絕資料庫訪問,我們可以建立另外一個名為DB_NameDeniedUsers的全域群組,授權它訪問資料庫,然後把它設定為 db_denydatareader以及db_denydatawriter角色的成員。注意SQL語句許可權的分配,這裡的角色只限制對對象的訪問,但不限制對DDL(DataDefinitionLanguage,資料定義語言 (Data Definition Language))命令的訪問。
正如對登入過程的處理,如果訪問標記中的任意SID已經在Sysusers系統資料表登記,SQL將允許使用者訪問資料庫。因此,我們既可以通過使用者的個人NT帳戶SID授權使用者訪問資料庫,也可以通過使用者所在的一個(或者多個)組的SID授權。為了簡化管理,我們可以建立一個名為 DB_NameUsers的擁有資料庫存取權限的全域群組,同時不把訪問權授予所有其他的組。這樣,我們只需簡單地在一個全域群組中添加或者刪除成員就可以增加或者減少資料庫使用者。
五、分配許可權
實施安全性原則的最後一個步驟是建立使用者定義的資料庫角色,然後分配許可權。完成這個步驟最簡單的方法是建立一些名字與全域群組名字配套的角色。例如對於前面例子中的會計系統,我們可以建立AccountingDataEntryOperators、 AccountingDataEntryManagers之類的角色。由於會計資料庫中的角色與帳務處理任務有關,你可能想要縮短這些角色的名字。然而,如果角色名稱字與全域群組的名字配套,你可以減少混亂,能夠更方便地判斷出哪些組屬於特定的角色。
建立好角色之後就可以分配許可權。在這個過程中,我們只需用到標準的GRANT、REVOKE和DENY命令。但應該注意DENY許可權,這個許可權優先於所有其他許可權。如果使用者是任意具有DENY許可權的角色或者組的成員,SQLServer將拒絕使用者訪問對象。
接下來我們就可以加入所有SQLServer驗證的登入。使用者定義的資料庫角色可以包含SQLServer登入以及NT全域群組、本機群組、個人帳戶,這是它最寶貴的特點之一。使用者定義的資料庫角色可以作為各種登入的通用容器,我們使用使用者定義角色而不是直接把許可權分配給全域群組的主要原因就在於此。
由於內建的角色一般適用於整個資料庫而不是單獨的對象,因此這裡建議你只使用兩個內建的資料庫角色,,即db_securityadmin和 db_owner。其他內建資料庫角色,例如db_datareader,它授予對資料庫裡面所有對象的SELECT許可權。雖然你可以用 db_datareader角色授予SELECT許可權,然後有選擇地對個別使用者或組拒絕SELECT許可權,但使用這種方法時,你可能忘記為某些使用者或者對象設定許可權。一種更簡單、更直接而且不容易出現錯誤的方法是為這些特殊的使用者建立一個使用者定義的角色,然後只把那些使用者訪問對象所需要的許可權授予這個使用者定義的角色。
六、簡化安全管理
SQLServer驗證的登入不僅能夠方便地實現,而且與NT驗證的登入相比,它更容易編寫到應用程式裡。但是,如果使用者的數量超過25,或者伺服器數量在一個以上,或者每個使用者都可以訪問一個以上的資料庫,或者資料庫有多個管理員,SQLServer驗證的登入不容易管理。由於 SQLServer沒有顯示使用者有效許可權的工具,要記憶每個使用者具有哪些許可權以及他們為何要得到這些許可權就更加困難。即使對於一個資料庫管理員還要擔負其他責任的小型系統,簡化安全性原則也有助於減輕問題的複雜程度。因此,首選的方法應該是使用NT驗證的登入,然後通過一些精心選擇的全域群組和資料庫角色管理資料庫訪問。
下面是一些簡化安全性原則的經驗規則:
·使用者通過SQLServerUsers組獲得伺服器訪問,通過DB_NameUsers組獲得資料庫訪問。
·使用者通過加入全域群組獲得許可權,而全域群組通過加入角色獲得許可權,角色直接擁有資料庫裡的許可權。
·需要多種許可權的使用者通過加入多個全域群組的方式獲得許可權。
只要規劃得恰當,你能夠在網域控制站上完成所有的訪問和許可權維護工作,使得伺服器反映出你在網域控制站上進行的各種設定調整。雖然實際應用中情況可能有所變化,但本文介紹的基本措施仍舊適用,它們能夠協助你構造出很容易管理的安全性原則。