SQL Server建立應用程式角色與標準角色

Microsoft® SQL Server™ 中的安全系統在最低階別，即資料庫本身上實現。無論使用什麼應用程式與 SQL Server 通訊，這都是控制使用者活動的最佳方法。但是，有時必須自定義安全控制以適應個別應用程式的特殊需要，尤其是當處理複雜資料庫和含有大表的資料庫時。

　　此外，可能希望限制使用者只能通過特定應用程式(例如使用 SQL 查詢分析器或 Microsoft Excel)來訪問資料或防止使用者直接訪問資料。限制使用者的這種訪問方式將禁止使用者使用應用程式(如 SQL 查詢分析器)連線到 SQL Server 例項並執行編寫質量差的查詢，以免對整個伺服器的效能造成負面影響。

　　SQL Server 通過使用應用程式角色適應這些要求。應用程式角色與標準角色有以下區別：

　　◆應用程式角色不包含成員。

　　不能將 Microsoft Windows NT® 4.0 或 Windows® 2000 組、使用者和角色新增到應用程式角色;當通過特定的應用程式為使用者連線啟用應用程式角色時，將獲得該應用程式角色的許可權。使用者之所以與應用程式角色關聯，是由於使用者能夠執行啟用該角色的應用程式，而不是因為其是角色成員。

　　◆預設情況下，應用程式角色是非活動的，需要用密碼啟用。

　　◆應用程式角色不使用標準許可權。

　　當一個應用程式角色被該應用程式啟用以用於連線時，連線會在連線期間永久地失去資料庫中所有用來登入的許可權、使用者帳戶、其它組或資料庫角色。連線獲得與資料庫的應用程式角色相關聯的許可權，應用程式角色存在於該資料庫中。因為應用程式角色只能應用於它們所存在的資料庫中，所以連線只能通過授予其它資料庫中 guest 使用者帳戶的許可權，獲得對另一個資料庫的訪問。因此，如果資料庫中沒有 guest 使用者帳戶，則連線無法獲得對該資料庫的訪問。如果 guest 使用者帳戶確實存在於資料庫中，但是訪問物件的許可權沒有顯式地授予 guest，則無論是誰建立了物件，連線都不能訪問該物件。使用者從應用程式角色中獲得的許可權一直有效，直到連線從 SQL Server 退出為止。

　　若要確保可以執行應用程式的所有函式，連線必須在連線期間失去應用於登入和使用者帳戶或所有資料庫中的其它組或資料庫角色的預設許可權，並獲得與應用程式角色相關聯的許可權。例如，如果應用程式必須訪問通常拒絕使用者訪問的表，則應廢除對該使用者拒絕的訪問許可權，以使使用者能夠成功使用該應用程式。應用程式角色通過臨時掛起使用者的預設許可權並只對他們指派應用程式角色的許可權而克服任何與使用者的預設許可權發生的衝突。

　　應用程式角色允許應用程式(而不是 SQL Server)接管驗證使用者身份的責任。但是，SQL Server 在應用程式訪問資料庫時仍需對其進行驗證，因此應用程式必須提供密碼，因為沒有其它方法可以驗證應用程式。

　　如果不需要對資料庫進行特殊訪問，則不需要授予使用者和 Windows NT 4.0 或 Windows 2000 組任何許可權，因為所有許可權都可以由它們用來訪問資料庫的應用程式指派。在這種環境下，假設對應用程式的訪問是安全的，則在系統範圍內統一使用指派給應用程式角色的密碼是可能的。

　　有幾個選項可用於管理應用程式角色密碼而無須將其硬編碼到應用程式中。例如，可以使用儲存在登錄檔(或 SQL Server 資料庫)中的加密鍵，只有應用程式有加密鍵的解密程式碼。應用程式讀取鍵，對其進行解密，並使用其值設定應用程式角色。如果使用多協議 Net-Library，則含有密碼的網路資料包也可以被加密。另外，當角色被啟用時，可以在傳送到 SQL Server 例項前將密碼加密。

　　如果應用程式使用者使用 Windows 身份驗證模式連線到 SQL Server 例項，則在使用應用程式時，可以使用應用程式角色設定 Windows NT 4.0 或 Windows 2000 使用者在資料庫中擁有的許可權。這種方法使得當使用者使用應用程式時，對使用者帳戶的 Windows NT 4.0 或 Windows 2000 稽核及對使用者許可權的控制容易維護。

　　如果使用 SQL Server 身份驗證，並且不要求稽核使用者在資料庫中的訪問，則應用程式可以更容易地使用預定義的 SQL Server 登入連線到 SQL Server 例項。例如，訂單輸入應用程式驗證執行該應用程式的使用者，然後用相同的 OrderEntry 登入連線到 SQL Server 例項。所有連線都使用同一登入，相關許可權授予該登入。

　　說明 應用程式角色可以和兩種身份驗證模式一起使用。

　　示例

　　作為應用程式角色使用的示例，假設使用者 Sue 執行銷售應用程式，該應用程式要求在資料庫 Sales 中的表 Products 和 Orders 上有 SELECT、UPDATE 和 INSERT 許可權，但她在使用 SQL 查詢分析器或任何其它工具訪問 Products 或 Orders 表時不應有 SELECT、INSERT 或 UPDATE 許可權。若要確保如此，可以建立一個拒絕 Products 和 Orders 表上的 SELECT、INSERT 或 UPDATE 許可權的使用者-資料庫角色，然後將 Sue 新增為該資料庫角色的成員。接著在 Sales 資料庫中建立帶有 Products 和 Orders 表上的 SELECT、INSERT 和 UPDATE 許可權的應用程式角色。當應用程式執行時，它通過使用 sp_setapprole 提供密碼啟用應用程式，並獲得訪問 Products 和 Orders 表的許可權。如果 Sue 嘗試使用除該應用程式外的任何其它工具登入到 SQL Server 例項，則將無法訪問 Products 或 Orders 表。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16436858/viewspace-545152/，如需轉載，請註明出處，否則將追究法律責任。