Nó phải được thực hiện với hệ thống phân cấp quyền và sử dụng tư cách thành viên qua việc cấp quyền trực tiếp cho mỗi lần đăng nhập. Bài viết SQLMag này cho thấy một hình ảnh tốt về chữ tượng hình trong SQL Server. [Trong trường hợp bài báo bị chết, tôi đã sao chép hình ảnh bên dưới.]
Bạn đang cấp DENYcho vai trò Employeesđể Quản trị viên nhân sự là thành viên của vai trò cấp cao hơn có nghĩa là họ không trực tiếp kế thừa DENY. Ít nhất đó là cách tôi hiểu nó.
Phần cụ thể của bài viết được tham chiếu nói về DENY:
Tuyên bố cho phép thứ ba là DENY. Một tuyên bố DENY cũng thu hồi sự cho phép, nhưng thực hiện nó theo cách mà hiệu trưởng không thể kế thừa quyền thông qua vai trò thành viên. Khi bạn từ chối một sự cho phép, hiệu trưởng đó không có nó, khoảng thời gian. Từ chối quyền có thể cho phép bạn có được rất chi tiết với quyền. Một ví dụ phổ biến là cấp cho mọi người trong bộ phận một bộ quyền thông qua tư cách thành viên của họ trong một vai trò. Nhưng sau đó, bạn có thể tinh chỉnh lược đồ bằng cách từ chối cấp phép cho một số người dùng nhất định hoặc cho một vai trò khác mà chỉ một tập hợp con của người dùng thuộc về, tận dụng khả năng của người dùng thuộc nhiều vai trò.
Tôi đứng sửa
Hãy để tôi nói trước là tôi xin lỗi vì đã không kiểm tra những gì tôi đang nói khi tôi chứng minh mình đã sai. Đáng lẽ ra tôi phải biết nhiều hơn thế.
Bài học đầu tiên để học: Kiểm tra mọi thứ.
Bài học thứ hai để học: Không phải tất cả các câu hỏi của Microsoft thi đều hoàn hảo. Tôi sẽ đề nghị gắn bó với các công cụ kiểm tra mà Microsoft hỗ trợ (ví dụ: Đo lường.com )
Trả lời trước chi tiết
Trước tiên tôi sẽ cung cấp cho bạn những gì tôi khám phá, sau đó cho bạn thấy tôi đã thử nghiệm nó như thế nào. Vì vậy, phát hiện của tôi là về cơ bản tùy chọn D có thể đúng nếu bạn sử dụng REVOKEthay vì DENY. Điều này dựa trên tuyên bố từ whitepaper của Bob Beauchemin về Thực tiễn tốt nhất về bảo mật SQL Server 2005:
Trong SQL Server, ủy quyền được thực hiện thông qua Ngôn ngữ truy cập dữ liệu (DAL) thay vì DDL hoặc DML. Ngoài hai động từ DAL, GRANT và REVOKE, được ủy quyền bởi tiêu chuẩn ISO-ANSI, SQL Server còn chứa động từ DENY DAL. DENY khác với REVOKE khi người dùng là thành viên của nhiều cơ sở dữ liệu. Nếu người dùng Fred là thành viên của ba vai trò cơ sở dữ liệu A, B và C và vai trò A và B được cấp phép cho bảo mật, nếu quyền đó là REVOKEd từ vai trò C, Fred vẫn có thể truy cập bảo mật. Nếu bảo mật được DENYed cho vai trò C, Fred không thể truy cập vào bảo mật. Điều này làm cho việc quản lý SQL Server tương tự như quản lý các phần khác trong họ hệ điều hành Windows.
Vì vậy, về cơ bản REVOKEloại bỏ các quyền và về cơ bản sẽ không áp dụng bất kỳ quyền nào cho chính bảng. Bạn không từ chối rõ ràng bất cứ ai truy cập vào bảng. Vì vậy, nếu bạn thực sự muốn từ chối quyền, bạn sẽ phải xóa nhóm HRAdmins khỏi vai trò Nhân viên để nó hoạt động chính xác.
Tôi không có quyền truy cập vào Azure SQL vì vậy tôi chỉ có thể kiểm tra điều này trên phiên bản SQL Server 2014 cục bộ. Kịch bản dưới đây là những gì tôi đã trải qua, bao gồm các ý kiến khi tôi đi.
USE [master];
GO
--Create a database to work with
CREATE DATABASE [Database_WorkingWithPermissions];
GO
--Create the logins (I can't create Windows Groups but should work the same way)
CREATE LOGIN HRAdmin1 WITH PASSWORD = N'Apple123';
CREATE LOGIN Employee1 WITH PASSWORD = N'Apple123';
--Create the users in the database
USE [Database_WorkingWithPermissions];
GO
CREATE USER Employee1 FROM LOGIN Employee1;
CREATE USER HRAdmin1 FROM LOGIN HRAdmin1;
GO
--Create the role
CREATE ROLE Employees
--Create the tables noted in the question
CREATE TABLE [Employees] (employeeID int IDENTITY(1,1), employeeName varchar(15));
CREATE TABLE [SalaryDetails] (employeeID int, salaryAmount decimal(12,3));
CREATE TABLE [OtherTable] (column1 int);
--Grant permissions to the roles according to requirements
GRANT SELECT ON [dbo].[Employees] TO [Employees];
GO
GRANT SELECT ON [dbo].[OtherTable] TO [Employees];
GO
DENY SELECT ON [dbo].[SalaryDetails] TO [Employees];
GO
--Assign membership to the role based on requirements
ALTER ROLE [Employees] ADD MEMBER [Employee1];
GO
ALTER ROLE [Employees] ADD MEMBER [HRAdmin1]
GO
ALTER ROLE [db_datareader] ADD MEMBER [HRAdmin1];
GO
--Go through and see what permissions
EXECUTE AS USER = 'HRAdmin1'
SELECT * FROM [dbo].[Employees];
SELECT * FROM [dbo].[SalaryDetails];
REVERT;
EXECUTE AS USER = 'Employee1'
SELECT * FROM [dbo].[Employees];
SELECT * FROM [dbo].[SalaryDetails];
REVERT;
--So HRAdmin1 does not have permissions as it should
-- So they need to be removed from the Employee role
ALTER ROLE [Employees] DROP MEMBER [HRAdmin1]
GO
--Run the test again
--Go through and see what permissions
EXECUTE AS USER = 'HRAdmin1'
SELECT * FROM [dbo].[Employees];
SELECT * FROM [dbo].[SalaryDetails];
REVERT;
EXECUTE AS USER = 'Employee1'
SELECT * FROM [dbo].[Employees];
SELECT * FROM [dbo].[SalaryDetails];
REVERT;
--According to a SQL Server 2005 whitepaper Bob Beauchemin wrote on Security Best Practices
-- Revoke should be used
ALTER ROLE [Employees] ADD MEMBER [HRAdmin1]
GO
REVOKE SELECT ON [dbo].[SalaryDetails] TO [Employees];
GO
--Run the test again
--Go through and see what permissions
EXECUTE AS USER = 'HRAdmin1'
SELECT * FROM [dbo].[Employees];
SELECT * FROM [dbo].[SalaryDetails];
REVERT;
EXECUTE AS USER = 'Employee1'
SELECT * FROM [dbo].[Employees];
SELECT * FROM [dbo].[SalaryDetails];
REVERT;