Security 10：權限管理
- 2020 年 7 月 1 日
- 筆記
- Security, SQL Server 安全
SQL Server 用於管理權限的TSQL命令有：GRANT用於授予權限，REVOKE 用於移除授予的權限，而DENY用於防止安全主體通過GRANT獲得權限。但是，SQL Server的權限管理不是扁平的，是立體的，在不同的安全上下文（Security context）中，不同的權限空間（Permission Space）中，這三個命令的優先級是不同的。
在進行權限管理時，應遵守「最低權限」原則，即每個人只授予必需的最小權限。相對於授予的權限，數據庫中還有一個特殊的權限，那就是所有權（Ownship）。
一，管理權限的規則
在管理權限時，要注意權限的上下文、權限的立體空間和權限的優先級
1，安全上下文和權限空間
安全上下文（Security Context），是跟user 或 login 相關的環境，用戶可以通過EXECUTE AS 來切換安全上下文。安全上下文主要包括：Login、User、Role membership、Windows Group membership
權限空間，是指安全對象（Securable）和包含安全對象的所有安全對象類（Securable class），比如，表包含在schema 中，schema是表的安全對象類；而database包含schema，database是schema的安全對象類。訪問表的權限，受到表、schema和database的權限的影響，這三個對象構成一個權限空間，訪問受到權限空間的約束。
2，權限的優先級
當這三個命令作用於同一個安全對象（Securable）時，情況會變得複雜，不僅需要考慮權限空間，還需要考慮權限的優先級。
在同一個安全主體範圍內對同一個安全對象設置權限，GRANT子句會移除DENY和REVOKE子句設置的權限，這三個命令的優先級相同，後執行的語句會移除先執行語句的效果。
但是，當相同的權限作用於同一安全主體的不同範圍時，如果DENY 作用於更高的範圍內，那麼DENY優先，但是在更高的範圍內，REVOKE不優先。
這裡有一個例外，列級別的GRANT語句，會覆蓋Object級別的DENY語句，但是後續Object級別的DENY語句會覆蓋列級別的GRANT語句。
3，權限的層次結構
權限的層次結構，類似於權限空間，但是權限的層次結構是一種父子結構。
舉個例子，數據庫級別的權限：
- 在數據庫級別授予操作數據庫對象的權限，比如 EXECUTE、DELETE、INSERT、SELECT、UPDATE、REFERENCES、VIEW DEFINITION，實際上，授予的是操作數據庫中所有對象的權限。
- 數據庫級別獨有的權限：ALTER、BACKUP DATABASE、BACKUP LOG、CHECKPOINT、CONNECT、CREATE TABLE、CREATE VIEW、CREATE PROCEDURE等
二，權限管理的實現
權限管理涉及到Principal、Securable和Permission三個概念。Principal可以是單個User，也可以是多個User構成的Windows Group；Securable可以是單個數據庫對象，也可以是包含多個數據庫對象的schema；同時，User也可以通過role獲得數據庫對象的權限。
第一種方式，為每一個User設置單個Securable的權限
第二種方式，創建Windows Group，把User分組，為每一個Windows Group設置單個Securable的權限，簡少了授權用戶的數量。
第三種方式，通過數據庫 role來設置權限，通過Role來組織Securable，減少了授權對象的數量。
第四種方式，通過Schema來設置權限，在一個Schema下包含多個Securables，並通過Role來管理Scurable，通過Windows Group來管理User，這種方式雖然複雜，但是權限的管理非常精細和靈活。
三，所有權和所有權鏈
對象的所有者對一個對象擁有所有可能的權限，並且這些權限不能禁止。CONTROL權限可以執行與對象所有者幾乎相同的操作，但是所有權和授權是不同的。對象的所有者通常是其創建者，但是可以在創建時使用AUTHORIZATION子句指定其他所有者，也可以把Ownship轉移給其他Principal。
如何在不授予基礎表訪問權限的情況下，僅對視圖或任何其他類型的程序授予SELECT權限呢？答案是使用所有權鏈（Ownership-chaining）。通常情況下，當用戶從視圖中查詢數據時，系統做兩次權限檢查，第一次是檢查用戶是否有權限查詢視圖，第二次是在視圖引用基礎表時檢查用戶是否有權限查詢基礎表，由於用戶沒有基礎表的權限，因此第二次權限檢查失敗。
所有權鏈（Ownership-chaining）通過繞過第二次權限檢查來避免這種情況，否則將在視圖引用基礎表時進行第二次權限檢查。當鏈接的對象（underlying table）與調用對象（view）具有相同的所有者時，權限檢查將被完全繞開。
如果一個user在具有Ownership權限的Schema中創建視圖，因為它視圖的所有者，就是被視圖引用的基表的所有者，這是一個鏈：我是Schema的所有者，那麼Schema下的所有對象的Owner都是我，我有權限訪問視圖，但不能訪問基礎表。
參考文檔：
Schema-Based Access Control for SQL Server Databases
