1. Bảo mật trong cơ sở dữ liệu
Chương 14 SECURITY
Bảo mật trong cơ sở dữ liệu

2. Mục tiêu Trong phần này, chúng ta sẽ học về:
Các tính chất bảo mật của SQL Server
Tạo tài khoản đăng nhập (user login)
Phân biệt tài khoản đăng nhập (user login) và tài khoản người dùng (user ID)
Các loại User Roles:
Fixed Server Roles
Database Roles
Các loại quyền bảo mật( Security Permissions)
Nhóm lệnh DCL : GRANT, DENY, REVOKE
Giải quyết xung đột giữa các quyền

3. Khái quát về tính bảo mật trong SQL Server
Mỗi database nên có 1 hệ thống bảo mật đáng tin cậy (reliable security system) để giám sát mọi hoạt động cũng như các thông tin cần được xem và chỉnh sửa
Một hệ thống bảo mật đáng tin cậy phải bảo đám được việc bảo vệ dữ liệu bất kể việc user đã dùng cách nào để truy xuất vào database. SQL áp dụng các quyền bảo mật vào các mức: mức database, mức các đối tượng và mức các cột của bảng

4. Login ID và user ID Cần phân biệt Login ID và user ID:
Người dùng muốn truy xuất vào Microsoft SQL Server, thì phải có login ID và password. Nhưng login ID chính nó không cho phép nguời dùng quyền truy xuất đến các DB. Muốn tạo login ID, dùng lệnh sp_addlogin
User ID nhận dạng người dùng trong 1 DB. Tất cả các quyền và chủ quyền của các đối tượng trong DB đều được điều khiển bởi user ID. Ví dụ user ID là xyz trong DB sales khác với user ID cũng tên là xyz trong DB inventory.

5. Login ID và user ID
Một login ID phải kết hợp với 1 user ID trong mỗi DB để truy xuất dữ liệu trong DB. Nếu login ID không được kết hợp tường minh với 1 user ID thì nó sẽ kết hợp với user ID là guest. Nều DB không có user ID guest thì không thể truy xuất vào DB được
sa là 1 tài khoản đăng nhập (login account) được ánh xạ tự động với user ID dbo trong mọi DB.
Guest là user ID đặc biệt
Việc quản trị sẽ dễ dàng hơn nếu login ID và user ID giống nhau nhưng điều này không bắt buộc.

6. Authentication &Authorization
User có thể truy xuất vào DB thông qua 1 account đăng nhập (login ID) hợp lệ , nhờ đó user có khả năng kết nối vào database server. Quá trình này được gọi là authentication(xác thực).
Tài khoản đăng nhập (Login ID) sẽ được ánh xạ với tài khoản user ( user ID) để cho phép user được quyền truy xuất trong 1 DB. Quá trình này gọi là authorization (cấp phép) (hay permission validation). User sẽ không thể truy xuất vào DB ngay cả khi họ có tài khoản đăng nhập (login ID ) hợp lệ.

7. Tạo Login ID
Sử dụng tài khoản đăng nhập của chính Windows như tài khoản đăng nhập vào SQL server.
Sử dụng thủ tục sp_grantlogin
Tạo 1 tài khoản đăng nhập của riêng SQL server
Sử dụng thủ tục sp_addlogin

8. Gán user của Windows Cú pháp sp_grantlogin [@loginame =] 'login‘
Ví dụ: muốn có thể đăng nhập vào SQL server bằng account của Windows là user1, ta dùng lệnh sau:
sp_grantlogin ‘user1’

9. Tạo User login của SQL server
Chỉ có người quản tri (administrator) mới có quyền tạo login ID mới.
Cú pháp
sp_addlogin = ] 'login'     [ , = ] 'password' ]     [ , = ] 'database' ]
Ví dụ:
EXEC sp_addlogin ‘student1','Password','master'

10. Xem các login ID
Dùng thủ tục sp_helplogins

11. Tạo user cho DB hiện hành
Để thêm 1 tài khoản (ID) cho 1 user mới vào DB hiện hành
Cú pháp:
sp_adduser = ] 'login'     [ , = ] 'user' ]     [ , = ] 'group' ]
Chú ý: chỉ có thể tạo user mới cho những user nào đã có tài khoản đăng nhập (login ID)
‘login‘: xác định login id của user
'user‘ là tên của user mới. Nếu tuỳ chọn này không được xác định, tên của user sẽ chính là tên login id của user đó. Có thể tạo ra tài khoản user khác với tên login id của user đó.
'group‘ là nhóm hay role mà user mới này sẽ tự động trở thành thành viên của nhóm.
Có thể tạo user mới từ Enterprise Manager

12. Role là gì?
Role là một công cụ cực mạnh cho phép ta tập hợp các user vào cùng 1 unit nhờ đó ta có thể gán quyền chung cho cả unit đó.
Tương tự như trong 1 công ty, ta có thể tập hợp các công nhân làm cùng 1 công việc lại 1 nhóm, nhờ đó ta có thể giao việc, cấp quyền cho cả nhóm. Mọi thành viên trong nhóm sẽ có quyền như nhau. Nếu chức năng của nhóm thay đổi, ta chỉ đơn giản thay đổi quyền của nhóm, khi đó những thay đổi này sẽ được tự động áp dụng cho tất cả các thành viên trong nhóm.

13. Vai trò của role
Để dễ quản lý 1 DB, nên xác định 1 tập hợp các role dựa theo yêu cầu công việc và gán mỗi role những quyền hạn (permission) khác nhau. Sau đó, chỉ cần chuyển các user vào các role thích hợp hơn là phải cấp quyền cho mỗi user riêng lẻ. Nếu công việc thay đổi. chỉ cần thay đổi quyền trong mỗi role thì những thay đổi này sẽ tự động được áp dụng cho toàn bộ các thành viên của role đó.
Các user có thể là thành viên của nhiều role

14. Ví dụ minh hoạ
Giả sử có CSDL là courses, sau khi người quản trị cho phép 5 tài khoản Windows bao gồm giáo sư John, Sarah, Diane và 2 sinh viên Betty và Ralph được đăng nhập vào SQL server. Đặc biệt là Diane vừa là giáo sư nhưng lại vừa theo học 1 lớp khác. Người quản trị cần cấp cho các giáo sư quyền được update điểm sinh viên, còn các sinh viên thì chỉ được xem điểm của họ. Người quản trị đã tạo ra 2 view có tên là ProfessorGradeView dành cho giáo sư, và StudentGradeView dành cho sinh viên.
 Script của người quản trị nên có nội dung như thế nào??

15. USE master GO
sp_grantlogin 'NETDOMAIN\John'
sp_defaultdb 'NETDOMAIN\John', 'courses‘
sp_grantlogin 'NETDOMAIN\Sarah'
sp_defaultdb 'NETDOMAIN\Sarah', 'courses'
sp_grantlogin 'NETDOMAIN\Betty'
sp_defaultdb 'NETDOMAIN\Betty', 'courses'

16. sp_grantlogin 'NETDOMAIN\Ralph'GO
sp_defaultdb 'NETDOMAIN\Ralph', 'courses'
sp_grantlogin 'NETDOMAIN\Diane'
sp_defaultdb 'NETDOMAIN\Diane', 'courses'
USE courses
sp_grantdbaccess 'NETDOMAIN\John‘
sp_grantdbaccess 'NETDOMAIN\Sarah'
sp_grantdbaccess 'NETDOMAIN\Betty'
sp_grantdbaccess 'NETDOMAIN\Ralph'
sp_grantdbaccess 'NETDOMAIN\Diane'

17. sp_addrole 'Professor' GO
sp_addrole 'Student'
sp_addrolemember 'Professor', 'NETDOMAIN\John‘
sp_addrolemember 'Professor', 'NETDOMAIN\Sarah‘
sp_addrolemember 'Professor', 'NETDOMAIN\Diane‘
sp_addrolemember 'Student', 'NETDOMAIN\Betty‘
sp_addrolemember 'Student', 'NETDOMAIN\Ralph'
sp_addrolemember 'Student', 'NETDOMAIN\Diane'

18. GRANT SELECT ON StudentGradeView TO StudentGO
GRANT SELECT, UPDATE ON ProfessorGradeView TO Professor

19. Các loại User Roles
Trong SQL server không có group. Tuy nhiên ta có thể quản lý việc bảo mật của SQL server thông qua các group của Windows.
Các nhóm của Windows có thể được dùng như là các role của SQL server.
Có 2 loại user roles đã được định nghĩa sẵn trong SQL Server 2000:
• Fixed Server Roles
• Database Roles

20. Fixed Server Roles
Hạn chế khả năng truy xuất vào các CSDL riêng lẻ sau khi user đăng nhập vào.
Có 8 loại server roles. Danh sách sau liệt kê các loại này mà khả năng quản trị theo thứ tự giảm dần.
sysadmin: quyền tối đa mà không bị bất kỳ 1 hạn chế nào. Mặc định, tất cả các thành viên của nhóm quản trị Windows (Administrators)và user sa thuộc vào server role này
serveradmin: có quyền cấu hình mức server như xác lập lượng bộ nhớ mà SQL server có thể dùng khi truyền thông tin qua mạng.

21. Fixed Server Roles
setupadmin: có quyền thực thi replication và quản trị các thủ tục (extended stored procedures).
securityadmin: điều hành bảo mật như tạo login và gán quyền.
processadmin: có quyền kết thúc các tiến trình được gọi không hợp lệ
dbcreator: tạo và chỉnh sửa database

22. sp_srvrolepermission
Fixed Server Roles
diskadmin: thực hiện các hoạt động sao lưu như sao chép đĩa và tạo các thiết bị sao lưu
bulkadmin: thực hiện lệnh BULK INSERT
Lưu ý: Một thành viên của bất kỳ server role nào đều có thể thêm các user khác vào chính server role đó.
Để xem các fixed server roles:
sp_helpsrvrole
Để xem quyền của mỗi role
sp_srvrolepermission

23. Fixed Server Roles
Để gán 1 user vào 1 fixed server role, ta có thể dùng lệnh sau
Cú pháp:
sp_addsrvrolemember = ] 'login', = ] 'role‘
Ví dụ 1: gán user1 vào nhóm sysadmin
EXEC sp_addsrvrolemember 'User1', 'sysadmin‘
Ví dụ 2: thêm user của Windows NT Corporate\HelenS vào role sysadmin EXEC sp_addsrvrolemember 'Corporate\HelenS', 'sysadmin'

24. Database roles
Mỗi Database có một bộ các fixed database roles. Phạm vi của mỗi role này là chỉ trong từng database riêng rẽ.
Ví dụ: nếu Database1 và Database2 cả hai đều có 1 user ID là UserX. Nhưng UserX trong Database1 thuộc fixed database role tên là db_owner. Role này không ảnh hưởng gì đến UserX trong Database2 khi user này là thành viên của role có tên là db_owner.
Database roles cho phép bạn gán quyền cho 1 nhóm các user thay vì phải gán quyền cho từng user riêng lẻ.
Có 3 loại database roles:
• Fixed
• Custom
• Application

25. Fixed Database Roles DatabaseRole Mô tả db_owner
Có tất cả các quyền trong DB
db_accessadmin
Thêm hay xóa các user ID
db_securityadmin
Quản lý tất cả các role và permission trong DB,có thể thay đổi chủ quyềnower (ownership)
db_ddladmin
Có thể thực hiện tất cả các lệnh DDL nhưng không thể sử dụng các lệnh GRANT, REVOKE hay DENY
db_backupoperator
Có thể thực hiện các lệnh DBCC, CHECKPOINT và BACKUP.

26. Fixed Server Roles
DatabaseRole
Mô tả
db_datareader
Có thể chọn tất cả dữ liệu từ bất kỳ bảng của user nào trong DB
db_datawriter
Có thể chỉnh sửa bất kỳ dữ liệu trong các bảng của user trong DB.
db_denydatareader
Không thể chọn tất cả dữ liệu từ bất kỳ bảng của user nào trong DB
db_denydatawriter
Không thể chỉnh sửa bất kỳ dữ liệu trong các bảng của user trong DB.

27. sp_dbfixedrolepermission.
Fixed Server Roles
Để xem các fixed database role:
sp_helpdbfixedrole
Để xem các quyền của mỗi role:
sp_dbfixedrolepermission.
Mỗi user trong 1 DB đều thuộc về role public. Nếu muốn mọi user trong 1 DB có quyền đặc biệt nào đó thì hãy gán quyền đó cho role public. Nếu 1 user chưa được cấp quyền đặc biệt gì thì họ sẽ chỉ được dùng những quyền đã được gán cho public.
Bất kỳ thành viên nào của fixed database role đều có thể thêm các user khác vào role của thành viên đó

28. Thêm thành viên vào DB role
Tài khoản bảo mật (security account):
có thể là bất kỳ user hợp lệ nào của SQL server
Có thể là 1 role nào đó của SQL Server
có thể là bất kỳ user hay group nào của Windows đã được gán quyền truy cập vào DB hiện hành
Để thêm user hay group của Windows NT, dùng sp_grantdbaccess
Dùng lệnh sp_addrolemember để thêm 1 tài khoản vào 1 role, khi đó thành viên có thể kế thừa bất kỳ quyền nào của role đó.
sp_addrolemember = ] 'role' , = ] 'security_account'

29. sp_grantdbaccess Cú pháp
sp_grantdbaccess =] 'login' =] 'name_in_db' OUTPUT]]
Ví dụ: thêm user của Windows vào CSDL hiện hành với user ID là Georgie.
EXEC sp_grantdbaccess 'Corporate\GeorgeW', 'Georgie'
Để xoá tài khoản ra khỏi CSDL: sp_revokedbaccess = ] 'name‘
Ví dụ : EXEC sp_revokedbaccess 'Corporate\GeorgeW'

30. sp_addrolemember Cú pháp sp_droprolemember [ @rolename = ] 'role' ,
sp_addrolemember = ] 'role' , = ] 'security_account'
sp_droprolemember
= ] 'role' ,
= ] 'security_account'

31. Custom Database Roles
Người dùng có thể cần có thêm một số quyền mà các quyền này chưa được xác định trong bất kỳ role database cố định nào. SQL server cho phép tạo các database role tuỳ biến (custom)
Khi tạo một role database tùy biến, trước tiên cần thêm các quyền vào role, sau đó sẽ gán các user vào role.

32. EXEC sp_addrole 'Managers'
Tạo DB role tuỳ biến
Dùng lệnh
sp_addrole = ] 'role'     [ , = ] 'owner' ]
Bằng Enterprise Manager
Chỉ có những thành viên của role sysadmin, db_securityadmin và db_owner mới có quyền chạy lệnh này
Ví dụ: tạo 1 role mới tên Managers cho CSDL hiện hành.
EXEC sp_addrole 'Managers'

33. Vai trò của Application Roles
Hệ thống bảo mật trong SQL server được thực thi ở mức thấp nhất:là database. Đây là phương pháp tốt nhất để kiểm soát các hoạt động của user bất kể ứng dụng nào được dùng để kết nối với SQL server. Tuy nhiên, đôi khi việc kiểm soát bảo mật phải được “customized” ( tuỳ biên) để phù hợp với các yêu cầu đặc biệt của mỗi ứng dụng.
Hơn nữa, để có thể hạn chế việc truy xuất dữ liệu của người dùng thông qua 1 ứng dụng nào đó hay để tránh khỏi truy xuất dữ liệu trực tiếp, cần ngăn chặn người dùng không được kết nối vào SQL server thông qua ứng dụng. Vì khi truy xuất vào SQL server được, họ có thể tạo ra các truy vấn sai trong cửa sồ analyzer , ảnh hưởng đến việc thực thi của cả server. gây hậu quả xấu
Để đáp ứng các yêu cầu trên, SQL server đã cung cấp 1 role đặc biệt khác với role tiêu chuẩn, đó là application role

34. Application Roles
Application role không có member (thành viên) như các role khác. Quyền của apllication role có được khi application role hoạt động do 1 ứng dụng nào đó đang chạy. Người dùng có liên quan đến application role là do người dùng đó có khả năng chạy được ứng dụng hơn là do nguời dùng đó là thành viên của application role.
Mặc định application role không hoạt động ( inactive) và đòi hỏi password khi được kích hoạt.

35. Application Role
Application role sẽ bỏ qua các quyền tiêu chuẩn. Application role sẽ hoạt động khi có 1 ứng dụng đang kết nối vào SQL server.
Việc kết nối này sẽ làm mất tất cả các quyền của login ID, user ID, các group hay các database role khác trong tất cả các DB trong suốt thời gian kết nối. Việc kết nối này sẽ đạt được các quyền có liên quan đến application role của DB nào mà ứng dụng đang chạy.

36. Application Role
Vì application role chỉ có thể áp dụng vào DB mà ứng dụng đang chạy, kết nối có thể truy xuất được đến các DB khác chỉ thông qua các quyền được cấp cho user guest trong các DB khác mà thôi. Vì vậy nếu user guest không tồn tại trong 1 DB nào đó, thì kết nối không thể truy xuất vào DB đó được. Thậm chí ngay cà khi có user guest nhưng quyền truy xuất vào 1 đối tượng nào đó không được gán 1 cách tường minh thì user guest dù có kết nối được cũng không thể truy xuất đối tượng đó được bất kể ai đã tạo ra đối tựong đó. Quyền của user có được từ application role vần còn có hiệu quả cho đến khi kết nối thoát khỏi SQL server.

37. Application Role
Để bảo đảm là tất cả chức năng của ứng dụng có thể được thực thi, một kết nối phải làm mất đi các quyên được áp dụng cho các tài khoản login và user hay các group, database role trong tất cả các DB trong suốt thời gian kết nối và chỉ có quyền liên quan đến ứng dụng mà thôi. Ví dụ nếu 1 user thường bị từ chối truy xuất vào bảng mà 1 ứng dụng có thể truy xuất vào được,khi đó việc bị từ chối truy xuất này sẽ hủy bỏ khi user sử dụng ứng dụng này
Application role cho phép ứng dụng được quyền xác nhận người dùng ( user authentication). Tuy nhiên SQL server vần phải xác nhận ứng dụng khi nó truy xuất vào DB, ứng dụng phải cung cấp password vì không có cách nào khác đề xác nhận một ứng dụng có hợp lệ hay không.

38. sp_addapprole Tạo 1 application role cho DB hiện hành Cú pháp
sp_addapprole = ] 'role‘ ,
= ] 'password'
Giá trị trả về của thủ tục :
0 (thành công)
hoặc 1(bị lỗi)
Có thể tạo application role từ enterprise manager

39. sp_setapprole Để kích hoạt 1 application role trong DB hiện hành
Cú pháp
sp_setapprole =] 'role' ,
=] 'password‘
Sau khi application role được kích hoạt bằng sp_setapprole, role sẽ không bị mất tác dụng trong DB hiện hành cho đến khi user ngắt kết nối khỏi SQL Server
Thủ tục sp_setapprole chỉ có thể được gọi trực tiếp bằng lệnh exec. Nó không thể được thực thi bên trong 1 thủ tục khác hay từ 1 transaction của người dùng
Ví dụ: EXEC sp_setapprole 'SalesApprole', 'AsDeFXX'

40. Ví dụ
Sue đang chạy ứng dụng Sales ma ứng dụng này yêu cầu các quyền SELECT, UPDATE và INSERT vào các bảng Products và Orders trong CSDL Sales, nhưng cô ta lại không có các quyền này khi truy xuất trực tiếp vào hai bảng trên khi dùng cửa sổ Analyzer hay các công cụ khác của SQL.
Tạo 1 Database role cấm các quyền SELECT, INSERT và UPDATE trên bảng Products và Orders, và thêm Sue vào như là thành viên của role đó. Sau đó tạo 1 application role trong database Sales với các quyền SELECT, INSERT và UPDATE trên các bảng Products và Orders. Khi application chạy, cần đưa password vào để kích hoạt application role. Nếu Sue cố đăng nhập vào SQL server không thông qua ứng dụng thì cô ta không thể nào truy xuất vào được hai bảng Products và Orders

41. Các loại quyền (Permissions)
Khi 1 đối tượng được tạo ra, chỉ có owner ( người tạo đối tượng) mới có quyền truy xuất đối tựong. Owner phải cấp quyền cho các user khác
User phải có quyền thích hợp để thực thi bất kỳ hoạt động nào liên quan đến việc thay đổi định nghĩa DB hay truy xuất dữ liệu
Có 3 loại quyền
• Object Permissions
• Statement Permissions
• Implied Permissions
Tất cả các quyền trong SQL server có thể tồn tại dưới 1 trong 3 trạng thái sau: granted ( cấp quyền), revoked (thu hồi) và denied (từ chối).

42. Object Permissions (Quyền về đối tượng)
Ngay khi 1 DB được tạo, các user cần được cho quyền để làm việc với dữ liệu được lưu trữ trong DB.
Có 6 lọai quyền object :
SELECT: cho phép user đọc dữ liệu từ 1 bảng hay view
INSERT: cho phép user thêm các hàng mới vào bảng
UPDATE: cho phép user sửa đổi dữ liệu hiện có trong bảng, tuy nhiên user không thể thêm hay xóa các hàng trong bảng được
DELETE: cho phép user được quyền xóa các hàng trong bảng
REFERENCES khi 2 bảng kết với nhau thông qua khóa ngọai (foreign key) quyền REFERENCES cho phép user chọn dữ liệu từ bảng primary mà không cần có quyền SELECT trên bảng foreign
EXECUTE: cho phép user thực thi thủ tục mà user được cấp quyền

43. Statement Permissions Quyền về lệnh
Cho phép các họat động liên quan đến việc tạo DB hay 1 đối tượng nào đó trong DB như bảng, thủ tục. Các quyền về lệnh đươc áp dụng chỉ cho lệnh hơn là cho bản thân các đối tượng.
Các Statement permissions là
BACKUP DATABASE
BACKUP LOG
CREATE DATABASE
CREATE DEFAULT
CREATE FUNCTION
CREATE PROCEDURE
CREATE RULE
CREATE TABLE
CREATE VIEW

44. Implied Permissions Quyền ngầm định
Implied permissions kiểm sóat các họat động mà chỉ có thể được thực hiện bởi các thành viên của các role hệ thống (như sysadmin,..) hoặc các owner của các đối tượng CSDL.
Các owner của các đối tượng DB cũng có thể có các quyền ngầm định cho phép họ thực thi tất cả các hoạt động với đối tượng mà họ là chủ

45. Data Control Language
Có thể dùng các lệnh DCL(Data Control Language) để thay đổi các quyền có liên quan đến user hay role của DB.
Có 3 lệnh DCL :
• GRANT
• REVOKE
• DENY

46. Data Control Language
Lệnh GRANT cho phép user, group hay role làm việc với lệnh về dữ liệu hay thực thi các lệnh T-SQL
Cú pháp:
Statement permissions:
GRANT { ALL | statement [ ,...n ] } TO security_account [ ,...n ]
Object permissions:
GRANT     { ALL | permission [ ,...n ] }     {         [ ( column [ ,...n ] ) ] ON { table | view }         | ON { table | view } [ ( column [ ,...n ] ) ]         | ON { stored_procedure | extended_procedure }         | ON { user_defined_function }     } TO security_account [ ,...n ] [ WITH GRANT OPTION ] [ AS { group | role } ]

47. Data Control Language
ALL: đối với quyền về lệnh (statement permission), thì ALL chỉ có thể được dùng bởi các thành viên của sysadmin. Đối với quyền về đối tượng (object permissions), ALL chỉ được dùng bởi các thành viên của sysadmin, db_owner và owner của đối tượng CSDL.
WITH GRANT OPTION (chỉ dùng cho quyền về đối tượng) cho khả năng các tài khoản sau khi được gán quyền được phép cấp quyền này cho các tài khoản khác
Ví dụ:
Use pubs
GRANT select, insert, update ON titles TO faculty

48. Data Control Language (Contd.)
Lệnh Deny để loại bỏ quyền khỏi 1 tài khoản trong CSDL hiện hành và để tránh tài khoản này được thừa hưởng quyền của nhóm hay role của tài khoản đó.
Cú pháp:
DENY <permissions>[ON <object>]TO <user/role>
Ví dụ:
Use pubs
DENY select, insert, update ON titles TO faculty
Lệnh REVOKE dùng để thu hồi lại quyền đã đuợc cấp hay từ chối từ 1 user của CSDL hiện hành
Cú pháp
REVOKE [GRANT OPTION FOR] <permissions>
[ON <object>]
TO <user/role>
REVOKE select, insert, update ON titles TO faculty

49. Giải quyết xung đột các quyền
Các quyền được cấp cho 1 nhóm hay 1 role sẽ được kế thừa bởi các thành viên của nhóm hay role đó. Mặc dù user có thể có quyền grant hay revoke 1 mức nào đó nhưng có thể bị xung đột ở mức cao hơn làm cho user có thể bị ngăn hay cho phép truy xuất đến 1 đối tượng.
Deny: quyền deny luôn ưu tiên hơn. Quyền deny ở bất kỷ mức nào cũng sẽ cấm các quyền trên các đối tượng bất kể có tồn tại quyền grant hay revoke dành cho user đó hay không. Ví dụ nếu John là thành viên của role sales, role này đã được cấp quyền SELECT trên bảng Customer, nếu John bị cấm (deny) 1 cách tường minh quyền SELECT trên bảng Customer thì John sẽ không còn được truy xuất vào bảng đó nữa. Tương tự, nều role sales bị cấm truy xuất bảng customer thì dù cho John được cấp quyền truy xuất cũng sẽ bị cấm theo.
Lưu ý: SQL Server luôn xử lý các quyền bị cấm trước. Nếu bạn deny các quyền vào role public thì có nghĩa là bạn cấm mọi người truy xuất đến đối tượng đó kể cả người đã tạo ra lệnh DENY này

50. Giải quyết xung đột các quyền
Revoke: chỉ thu hồi các quyền được cấp hoặc bị từ chối ở mức được thu hồi ( user, group hay role). Cùng 1 quyền đó mà được cấp hay cấm ở mức khác chẳng hạn của 1 group hay 1 role chứa user đó thì quyền của group hay role vẫn đựoc áp dụng.
Ví dụ: nếu role sale được cấp quyền SELECT trong bảng Customer và John (thành viên của sales) đã bị thu hồi một cách tường minh quyền SELECT trên bảng customer, anh ta vẫn có thể truy xuất bảng đó do anh ta vẫn là thành viên của role sales. Để tránh cho John không truy xuất được vào bảng customer phải thực hiện 1 trong 3 cách sau:
Thu hồi quyền (giả thiết là John không có quyền nào khác ở cấp khác)
Cấm quyền vào role sales ( cấm tất cả các thành viên của sales không được truy xuất vào bảng)
Cấm 1 cách tường mình John quyền SELECT trên bảng customer.

51. Giải quyết xung đột các quyền
Grant: xóa các quyền bị cấm hoặc bị thu hồi ở mức được cấp. Cùng quyền này mà bị cấm ở mức khác chẳng hạn mức group hay role thì các quyền này vẫn còn được áp dụng. Ví dụ quyền thu hồi dành cho role sales kết hợp với quyền được cấp cho John sẽ cho John quyền được cấp.
Vì vậy, 1 user nhận 1 tổ hợp của tất cả quyền được cấp, cấm hay thu hồi trên 1 đối tượng thì quyền bị cấm sẽ ưu tiên hơn.