さまざまな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 Schema Permissionsを使用することです。ロールを作成してからメンバーを追加することにより、権限を効率的に管理できます。

以下は、あなたを詳細に説明する例です

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がschemaBでなくschemaAを参照できることを確認します。良いことは、ユーザーを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からプロシージャを実行できます。

以下は許可階層を説明します：