다른 SQL Server 스키마에 대한 사용자 권한 설정

특정 사용자에 대한 액세스를 제한해야하지만 dbo 소유 테이블의 데이터를 여전히 볼 수 있어야합니다.

다음을 수행하려고합니다.

1. dbo 스키마 기능은 정상적으로 작동하며 모든 것에 액세스 할 수 있습니다.
2. schema1 스키마는 schema1 객체에만 액세스 할 수 있습니다
3. schema1보기 또는 저장 프로 시저가 dbo가 소유 한 테이블의 데이터에 액세스하는 경우 권한 체인이 적절하게
4. user1은 schema1에 액세스 할 수 있으며 다른 것은 없습니다. # 3의 경우를 제외하고

내가 시도한 것은 다음과 같습니다.

1. 임의의 비밀번호로 테스트 로그인에 맵핑 된 user1 사용자를 작성하십시오.
2. 테스트 데이터가 포함 된 dbo 스키마에 몇 개의 테이블을 작성했습니다.
3. schema1 스키마 생성
4. dbo.people, dbo.taglinks 및 dbo.tags의 데이터에 액세스하는 schema1.profiles라는보기에서 선택하는 schema1.get_profiles를 작성했습니다.

그러나 user1으로 로그인 한 상태에서 다음 명령문을 사용하십시오.

EXEC get_profiles 1

결과 :

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

저는 WITH EXECUTE AS OWNER"소유권 체인"이 어떻게 작동해야하는지 이해 하려고 노력 하지 못했습니다.

나는 또한 시도했다

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

그러나 다음과 같은 오류가 발생합니다 (dbo 수준 액세스 권한을 가진 사용자 임에도 불구하고).

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

내가 필요한 것은 user1이 내가 제공하는 저장 프로 시저를 통해 데이터에 액세스 할 수 있고 다른 것은 없습니다.

또한 이것은 결국 기존 SQL Azure 데이터베이스에 살려고하지만 로컬 더미 데이터베이스에 대해 먼저 테스트하고 있습니다.

기본 개념은 GRANT / DENY 스키마 권한을 사용하는 것 입니다. 역할을 만든 다음 구성원을 추가하여 권한을 효율적으로 관리 할 수 ​​있습니다.

아래는 자세히 설명하는 예입니다.

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

이제 테스트 :

--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'.

이제 저장 프로 시저를 만듭니다.

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

이제 schemaB의 SP에서 UserA에게 실행 권한을 부여하십시오.

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

테스트하여 .. UserA가 schemaB에서 SP를 실행할 수 있는지 확인하십시오. 통과 할 것이다

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

그러나 UserA는 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'.

또는 DATABASE ROLE을 사용하고 권한을보다 잘 관리하기 위해 사용자를 추가 할 수 있습니다.

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

아래 문장은 UserA가 schemaA와 NOT schemaB를 볼 수 있는지 확인합니다. 좋은 점은 사용자를 SchemaBUsesSchemaAProc역할에 추가하기 만하면 해당 역할에 부여 된 모든 권한을 상속한다는 것입니다.

GRANT SELECT ON SCHEMA::SchemaA TO SchemaBUsesSchemaAProc;
go

UserA가 SchemaB가 소유 한 SP를 실행하도록 허용하려면 아래 명령문이 작업을 수행합니다.

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

이런 식으로 UserA는 SchemaB의 테이블을 볼 수 없지만 SchemaB에서 여전히 procs를 실행할 수 있습니다.

아래는 권한 계층 구조 를 설명합니다 .