Đặt quyền người dùng cho các lược đồ SQL Server khác nhau

Tôi cần giới hạn quyền truy cập vào một người dùng cụ thể, nhưng họ vẫn cần có thể xem dữ liệu trong các bảng do dbo sở hữu.

Tôi đang cố gắng làm như sau:

1. Các hàm lược đồ dbo như bình thường, có quyền truy cập vào mọi thứ
2. lược đồ lược đồ 1 chỉ có quyền truy cập vào các đối tượng giản đồ1
3. nếu chế độ xem lược đồ1 hoặc thủ tục được lưu trữ truy cập dữ liệu trong các bảng do dbo sở hữu, chuỗi quyền thích hợp
4. user1 có quyền truy cập vào lược đồ1, và không có gì khác; ngoại trừ trong trường hợp số 3

Đây là những gì tôi đã thử:

1. Tạo người dùng user1 được ánh xạ tới đăng nhập thử nghiệm bằng mật khẩu ngẫu nhiên
2. Tạo một vài bảng trong lược đồ dbo với một số dữ liệu thử nghiệm trong đó
3. Tạo lược đồ giản đồ1
4. Đã tạo một lược đồ1.get_profiles chọn từ chế độ xem được gọi là lược đồ1.profiles truy cập dữ liệu trong dbo.people, dbo.taglinks và dbo.tags

Tuy nhiên, sử dụng câu lệnh sau trong khi đăng nhập với tên user1:

EXEC get_profiles 1

kết quả trong:

The SELECT permission was denied on the object 'tags', database 'schema_test', schema 'dbo'.

Tôi đã thử WITH EXECUTE AS OWNERvà không thể bắt đầu hiểu "chuỗi sở hữu" được cho là hoạt động như thế nào.

Tôi cũng đã thử

GRANT EXECUTE ON SCHEMA::schema1 TO user1
GRANT INSERT ON SCHEMA::schema1 TO user1
GRANT SELECT ON SCHEMA::schema1 TO user1
GRANT UPDATE ON SCHEMA::schema1 TO user1
GRANT VIEW DEFINITION ON SCHEMA::schema1 TO user1

nhưng tôi gặp lỗi sau (mặc dù là người dùng có quyền truy cập cấp dbo):

Cannot grant, deny, or revoke permissions to sa, dbo, entity owner, information_schema, sys, or yourself.

Điều tôi cần là user1 để có thể truy cập dữ liệu thông qua các thủ tục được lưu trữ mà tôi cung cấp và không có gì khác.

Ngoài ra, điều này dự định cuối cùng sẽ sống trên cơ sở dữ liệu SQL Azure hiện có, nhưng trước tiên tôi đang thử nghiệm cơ sở dữ liệu giả.

Khái niệm cơ bản là sử dụng Quyền Schema GRANT / DENY . Bạn có thể quản lý quyền một cách hiệu quả bằng cách tạo một vai trò và sau đó thêm thành viên vào đó.

Dưới đây là một ví dụ sẽ giải thích chi tiết cho bạn

use master
go
--Create Logins
CREATE LOGIN UserA WITH Password='UserA123';
go
CREATE LOGIN UserB WITH Password='UserB123';

use AdventureWorks2008R2
go
--Create Database Users
CREATE USER UserA;
go
CREATE USER UserB;
go
--Create the Test Schemas
CREATE SCHEMA SchemaA AUTHORIZATION UserA
go
CREATE SCHEMA SchemaB AUTHORIZATION UserB
go

-- create test tables
create table schemaA.TableA (fname char(5))
go
insert into schemaA.TableA (fname) values ('Kin-A')
go

create table SchemaB.TableB (fname char(5))
go
insert into SchemaB.TableB (fname) values ('Kin-B')
go

Bây giờ kiểm tra:

--Test for UserA in SchemaA
EXEC('select * from schemaA.TableA') AS USER = 'UserA'
go
--Kin-A

-- Test for UserB in SchemaB == this should fail
EXEC('select * from SchemaB.TableB') AS USER = 'UserA'
go
--Msg 229, Level 14, State 5, Line 1
--The SELECT permission was denied on the object 'TableB', database 'AdventureWorks2008R2', schema 'SchemaB'.

Bây giờ tạo Thủ tục lưu trữ:

CREATE PROCEDURE SchemaB.proc_SelectUserB
AS
    select * from schemaA.TableA;
go
create procedure schemaA.proc_SchemaA
as 
    select * from schemaA.TableA

Bây giờ cấp quyền thực thi cho UserA trên SP của lược đồ

GRANT EXECUTE ON OBJECT::[SchemaB].[proc_SelectUserB] TO [UserA] 
go

Kiểm tra nó .. để xem UserA có thể chạy SP từ lược đồB không. Điều này sẽ vượt qua

EXECUTE AS LOGIN='UserA';
    Exec SchemaB.proc_SelectUserB;
    revert;
go
--- Kin-A

Nhưng UserA sẽ không thể xem dữ liệu từ SchemaB

EXECUTE AS LOGIN='UserA';
    select * from SchemaB.TableB
revert;
go

--- Msg 229, Level 14, State 5, Line 3
--- The SELECT permission was denied on the object 'TableB', database 'AdventureWorks2008R2', schema 'SchemaB'.

Ngoài ra, bạn có thể sử dụng DATABASE ROLE và chỉ cần thêm người dùng vào đó để quản lý quyền tốt hơn:

EXEC sp_addrole 'SchemaBUsesSchemaAProc'
go
EXEC sp_addrolemember 'SchemaBUsesSchemaAProc','UserA';
go

Tuyên bố dưới đây sẽ đảm bảo rằng UserA có thể thấy lược đồA và KHÔNG lược đồB. Điều tốt là bạn chỉ có thể thêm người dùng vào SchemaBUsesSchemaAProcvai trò và họ sẽ kế thừa tất cả các quyền được cấp cho vai trò đó.

GRANT SELECT ON SCHEMA::SchemaA TO SchemaBUsesSchemaAProc;
go

Nếu bạn chỉ muốn cho phép UserA thực thi SP do SchemaB sở hữu thì câu lệnh dưới đây sẽ thực hiện công việc:

GRANT EXECUTE ON OBJECT::[SchemaB].[proc_SelectUserB] TO [SchemaBUsesSchemaAProc] 
go

Theo cách này, UserA không thể thấy các bảng của SchemaB, nhưng vẫn có thể thực thi các procs từ SchemaB.

Dưới đây sẽ giải thích hệ thống phân cấp quyền :