理解SQL Server中的許可權體系(上)—-主體

簡介

    許可權兩個字，一個權力，一個限制。在軟體領域通俗的解釋就是哪些人可以對哪些資源做哪些操作。在SQL Server中，”哪些人”，“哪些資源”,”哪些操作”則分別對應SQL Server中的三個對象，分別為主體(Principals),安全性實體(Securables)和許可權(Permissions)，而權力和限制則是對應了SQL Server中的GRENT和DENY。對於主體，安全性實體和許可權的初步理解，見圖1.

   

    圖1.簡單理解主體,安全性實體和許可權的關係

 

    對於圖1中的造句來說，並沒有主語，也就是並沒有說誰給予的許可權（難道是上帝?）。你可以理解為SA賬戶在最開始時給予了其他主體對於安全性實體的許可權。

 

SQL Server中的驗證方式

    在給予別人許可權之前，或是檢查你是否有某項許可權之前，SQL Server首先要知道“你”這個主體是否是你自己號稱的那個主體。比如武俠小說中接頭時對的暗號”天王蓋地虎，寶塔鎮河妖…”就是驗證身份的一種方式。而對於SQL Server,是在你串連SQL Server時SQL Server就需要確認你是誰。SQL Server提供了兩種身分識別驗證模式:

 

Windows身分識別驗證模式

    Windows身分識別驗證模式就像其名稱所示那樣，由Windows來驗證主體，SQL Server並不參與驗證。SQL Server完全相信Windows的驗證結果。所以用此方式登入SQL Server時並不需要提供密碼。雖然如此，但Windows身分識別驗證模式要更加安全，因為Windows身分識別驗證模式使用了Kerberos(這一名詞來源於希臘神話“三個頭的狗——地獄之門守護者”)協議。這也是微軟推薦的最安全的做法。

    但Windows身分識別驗證模式在由網域控制站控制網路訪問的情況下才得以使用(當然了，單機也包括在內)。

 

SQL Server和Windows身分識別驗證模式（混合模式）

    我一直覺得這種模式的名稱應該改為SQL Server或Windows身分識別驗證模式更容易理解。這種模式即允許由Windows來驗證主體身份，又允許SQL Server來驗證主體身份，當由SQL Server驗證主體身份時，需要使用者名稱和密碼來確認主體身份，和使用什麼Windows賬戶半毛錢關係都沒有。這些使用者資訊被加密後存在Master資料庫中。

 

設定驗證模式

    設定驗證模式非常簡單。既可以在安裝的時候進行設定，也可以在安裝之後通過右鍵點擊執行個體，選擇屬性，在安全性選項卡中進行改變，2所示。

   

    圖2.安裝完SQL Server之後改變身分識別驗證方式

 

理解主體

    “主體”是可以請求 SQL Server 資源的實體。主體可以是個體，組或者進程。主體可以按照作用範圍被分為三類:

•     Windows層級主體
•     伺服器層級主體
•     資料庫層級主體

 

    Windows 層級的主體包括Windows 域登入名稱和Windows 本地登入名稱。

    SQL Server級的主體包括SQL Server 登入名和伺服器角色。

    資料庫級的主體包括資料庫使用者和資料庫角色以及應用程式角色。

 

登入名稱

   登入名稱是伺服器層級的主體，但無論是上述哪個層級的主體，因為需要登入到SQL Server執行個體，所以每一個層級的主體都需要一個與之對應的登入名稱。對於Windows層級的主體來說，Windows使用者會映射到登入名稱。對於資料庫層級的主體來說，其使用者必須映射到登入名稱中。而登入名稱可以不映射到資料庫使用者，3所示。

   

       圖3.登入名稱的映射關係

 

    在圖3中執行個體層級的登入名稱中，我們看到除了自訂添加的使用者之外，還有一些由系統添加的登入名稱。首先，以”##”開頭和結尾的使用者是SQL Server內部使用的賬戶，由認證建立，不應該被刪除。其次是sa賬戶，sa登入名稱擁有一切特權，可以在SQL Server中為所欲為，並且不能夠被刪除。因此sa作為分配許可權的起點（也就是圖1中所說的主語）.因此對於Sa的密碼要設定的儘可能複雜，否則Sa登入名稱被盜取後果不堪設想。還有NT AUTHORITY\NETWORK SERVICE和NT AUTHORITY\SYSTEM賬戶是和啟動SQL Server這個Windows服務的賬戶有關，如果使用本地登入賬戶或是網路賬戶啟動SQL Server服務，請不要刪除這兩個賬戶，4所示。

       

      圖4.以本地系統賬戶啟動服務

 

    最後BUILDIN\Administrator賬戶是與本機系統管理員群組關聯的登入名稱，預設屬於sysadmin角色。這個賬戶使得任何屬於本地管理員的賬戶都可以獲得對SQL Server的完全控制權。

 

資料庫使用者
    資料庫使用者是資料庫層級的主體,被用於訪問資料庫層面的對象。每一個資料庫使用者都必須要一個與之對用的登入名稱。資料庫使用者的資訊存在資料庫中，而登入名稱存在執行個體層級的Master資料庫中(但SQL SERVER2012的Contained Database允許將登入名稱也存在資料庫層級)。通常來說，資料庫層級的使用者可以和映射的登入名稱不一致，但由於這種做法會引起混淆，因此並不推薦。5所示。

   

    圖5.可以讓使用者名稱和登入名稱不一致，但並不推薦

 

    預設情況下，每個資料庫都帶有4個內建使用者，6所示。

   

    圖6.資料庫帶的內建使用者

 

    dbo使用者是Database Owner的簡稱，如果說SA是執行個體層級的老大，那DBO就是資料庫層級的老大。這個使用者也同樣不能被刪除，每一個屬於sysadmin的伺服器角色都會映射到資料庫的dbo使用者。每一個表建立時如果沒有指定Schema，則預設在dbo這個schema下。

    guest使用者是一個來賓賬戶，這個賬戶允許登入名稱沒有映射到資料庫使用者的情況下訪問資料庫。預設情況下guest使用者是不啟用的，你可以通過代碼1來啟用或不啟用guest使用者。

--允許guest使用者串連許可權GRANT CONNECT TO guest--收回guest的串連許可權REVOKE CONNECT TO guest

    代碼1.啟用或回收guest使用者的串連許可權

    你也可以給guest使用者指派角色來控制guest的許可權(7所示)，但是這有可能造成潛在的安全問題，最佳做法是單獨建立資料庫使用者。

   

    圖7.為guest使用者指派角色

 

    而INFORMATION_SCHEMA使用者和sys使用者擁有系統檢視表，因此這兩個資料庫使用者不能被刪除，8所示。

   

    圖8.INFORMATION_SCHEMA和sys用於訪問系統檢視表

 

角色

    角色是方便對主體進行管理的一種舉措。SQL Server中的角色和Windows中的使用者組是一個概念。屬於某個角色的使用者或登入名稱就會擁有相應的許可權，這不難理解，就好比你在公司當經理，你就可以報銷多少錢的手機費用。而比你低一個層級的開發人員則沒有這個待遇。使用者或登入名稱可以屬於多個角色，這也同樣不難理解，就像你在公司中可以是專案經理，也同時兼任進階工程師一樣。

    角色在SQL Server中被分為三類，分別為:

    內建角色----這類角色在伺服器安裝時已經預設存在，其許可權是固定的，並且不能被刪除

    使用者自訂角色----這類角色由使用者按照需求自訂建立

    應用程式角色----這類特殊角色用於管理應用程式的資料訪問

 

    內建角色是在安裝SQL Server時就固定的，無論是伺服器角色還是資料庫角色，其對應的許可權都是固定的。具體每個角色對應的許可權請查看MSDN（固定伺服器角色http://msdn.microsoft.com/zh-cn/library/ms175892.aspx,固定資料庫角色http://msdn.microsoft.com/zh-cn/library/ms189121.aspx）,但這裡要注意一個特殊的角色: public角色。

    public角色不同於其它角色，其許可權可以被調整,9所示。

   

    圖9.Public角色不同於其它角色在於其許可權可以被修改

 

    可以將Public角色理解為訪問資料庫或執行個體的最小許可權，Public所擁有的許可權自動被任何主體繼承，所以對於Public角色的許可權修改要格外小心。

 

    而使用者自訂角色是按照使用者自己的需求組成的角色，由使用者建立。

    而應用程式角色並不包含任何使用者，應用程式角色與其說是角色，不如說是一個特殊的使用者。這是為應用程式專門準備的角色，僅僅為應用程式提供資料庫存取權限。這個角色並不提供給使用者，而是由應用程式的連接字串嵌入角色名稱和密碼來啟用對應許可權。

   

    圖10.不同於其它資料庫角色，應用程式角色需要設定密碼

 

理解構架

    構架（Schmea）是在SQL Server 2005之後的版本被引入的。可以將構架理解為一個命名空間。在SQL Server2000中其實也有構架的概念，但概念並不同。因為SQL Server 2000中的構架是和使用者綁定的，比如我建立使用者Jack,SQL Server自動分配一個叫Jack構架，使用者Jack並不能改變這個選項，而由Jack所建的任何對象都在Jack之下，比如建立一個表，則為Jack.Table1。當Jack如果離職時，這對管理來說簡直是一場噩夢。

    在SQL Server 2005之後，SQL Server允許使用者和構架分離。使得利用構架去擁有一些資料庫層級的對象，比如說:表，視圖等。

     下面幾種選擇方式，比如當我預設構架是Sales,時，我可以用代碼2中第一種寫法，不用構架:

SELECT * FROM CustomerSELECT * FROM sales.CustomerSELECT * FROM AdventureWorks.sales.Customer

    代碼2.引用對象的幾種不同寫法

 

    因此，假如Customer表是由Jack建的，我可以將其分配給Sales構架，引用時使用Sales.Customer,而不是Jack.Customer。這無疑大大方便了管理，此外，可以針對構設定許可權，這我會在本系列文章後續的文章中講到。

 

總結

    本文簡單講述了SQL Server的許可權體系。以及主體的概念。理解SQL Server的安全性要首先理解這三大方面。下一篇文章中我將接著講述安全性實體。