SQL Server 安全性管理的途徑

　　當在伺服器上運行SQL Server 時，我們總是要想方設法去使SQL Server 免遭非法使用者的侵入，拒絕其訪問資料庫，保證資料的安全性。SQL Server 提供了強大的內建的安全性和資料保護，來協助實現這種理所當然的要求。從前面的介紹中我們可以看出SQL Server 提供了從作業系統，SQL ServerE， 資料庫到對象的多層級的安全保護。其中也涉及到角色、資料庫使用者、許可權等多個與安全性有關的概念。現在我們面臨的問題就是如何在SQL Server 內把這些不同的與安全性有關的組件結合起來，充分地利用各種組件的優點，考慮到其可能存在的缺點來揚長避短，制定可靠的安全性原則。使SQL Server 更健壯，更為“不可侵犯”。

　　下面我們將介紹幾種安全性管理原則，您應該做的就是看懂並理解這些策略方法，然後將它們簡單地結合到一起就可以了。

　　1 使用視圖作為安全機制

　　在遊標和視圖一章我們已經提到視圖可以做為一種安全機制的主要原因在於視圖是一張虛表,而且它是由查詢語句來定義的,是一個資料結果集，通過視圖，使用者僅能查詢修改他所能看到的資料，其它的資料庫或表對於該使用者既不可見也無法訪問。通過視圖的使用權限設定，使用者只具有相應的訪問視圖的許可權，但並不具有訪問視圖所引用的基本表的相應許可權。

　　通過使用不同的視圖並對使用者授予不同的許可權，不同的使用者可以看到不同的結果集，可以實現行級或列級的資料安全性。下面的幾個例子說明了視圖是如何?資料安全性。

　　2 使用了行級、列層級安全性的視圖

　　例14-18： 在該例中某一銷售點只能查看它自己的銷售資訊。我們使用pubs 資料庫中的sales 表。

　　首先建立視圖

　　3 視圖與許可權結合

　　如果將訪問視圖的許可權授予給使用者，這樣即使該使用者不具有訪問視圖所引用的基本表的許可權，但其仍可以從中查看相應的資料資訊。

　　視圖與許可權相結合究竟能帶來什麼好處呢?下面我們舉一個例子來進行說明。首先假設使用者A 對sales 表的payterms 列沒有SELECT 許可權，對其它列有且僅有SELECT 許可權，如果要查看其它銷售資訊不能使用這樣的語句：

　　select * from sales

　　而必須指出其餘列的列名。這就要求使用者瞭解表的結構，通常來說讓使用者瞭解表結構是一件很不聰明的事，那麼如何解決這一問題呢?

　　很簡單如果建立一個視圖view1， 該視圖包含除payterms 列外的所有列，並且將 SELECT 許可權授予使用者A， 這樣使用者A 就可以執行語句：select * from view1， 從而查看到銷售資訊。

　　4 使用預存程序作為安全機制

　　如果使用者不具有訪問視圖和表的許可權，那麼通過預存程序仍能夠讓其查詢相應的資料資訊，實現的方法很簡單，只要讓該使用者具有預存程序的EXEC 許可權就可以了。當然要確保該預存程序中包含了查詢語句。比如可建立下面的預存程序：

　　create procedure selsales as

　　select * from sales

　　然後將預存程序的EXEC 許可權授予使用者，當使用者執行該預存程序時就可以查看到相應資訊。

　　使用預存程序的優點在於不必對視圖和表的存取權限進行分配。

　　小結

　　本文主要討論了SQL Server 的安全性管理問題。涉及到資料庫使用者、角色、許可權等作為一名系統管理員或安全性系統管理員，在進行安全屬性配置前，首先要確定應使用哪種身份認證模式。要注意恰當地使用guest 使用者和public 角色，並深刻瞭解應用角色對於實現資料查詢和處理的可控性所展示出的優點。