it-swarm.com.de

Festlegen von Benutzerberechtigungen für verschiedene SQL Server-Schemas

Ich muss den Zugriff auf einen bestimmten Benutzer beschränken, aber er muss weiterhin in der Lage sein, die Daten in Tabellen zu sehen, die dbo gehören.

Ich versuche Folgendes zu tun:

  1. das dbo-Schema funktioniert wie gewohnt und hat Zugriff auf alles
  2. schema1 schema hat nur Zugriff auf schema1-Objekte
  3. wenn eine Schema1-Ansicht oder eine gespeicherte Prozedur auf Daten in Tabellen zugreift, die dbo gehören, wird die Berechtigungskette entsprechend angepasst
  4. benutzer1 hat Zugriff auf Schema1 und sonst nichts. außer im Fall von # 3

Folgendes habe ich versucht:

  1. Erstellen Sie einen Benutzer1-Benutzer, der einem Test-Login mit einem zufälligen Kennwort zugeordnet ist
  2. Erstellt einige Tabellen im dbo-Schema mit einigen Testdaten
  3. Erstellt ein Schema1 Schema
  4. Erstellt ein schema1.get_profiles, das aus einer Ansicht namens schema1.profiles auswählt, die auf Daten in dbo.people, dbo.taglinks und dbo.tags zugreift

Verwenden Sie jedoch die folgende Anweisung, während Sie als Benutzer1 angemeldet sind:

EXEC get_profiles 1

ergebnisse in:

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

Ich habe versucht WITH EXECUTE AS OWNER und kann nicht verstehen, wie "Eigentumsverkettung" funktionieren soll.

Ich habe es auch versucht

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

ich erhalte jedoch den folgenden Fehler (obwohl ich ein Benutzer mit Zugriff auf Dbo-Ebene bin):

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

Was ich brauche, ist Benutzer1, um über die von mir angegebenen gespeicherten Prozeduren auf die Daten zugreifen zu können, und sonst nichts.

Darüber hinaus soll dies eventuell in einer vorhandenen SQL Azure-Datenbank ausgeführt werden, ich teste jedoch zuerst anhand einer lokalen Dummy-Datenbank.

16
Julia McGuigan

Das Grundkonzept besteht darin, GRANT/DENY Schema Permissions zu verwenden. Sie können Berechtigungen effizient verwalten, indem Sie eine Rolle erstellen und dieser dann Mitglieder hinzufügen.

Im Folgenden finden Sie ein Beispiel, das Sie ausführlich erklärt

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

Jetzt testen:

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

Erstellen Sie nun gespeicherte Prozeduren:

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

Jetzt gewähren Sie UserA Ausführungsberechtigungen für den SP von schemaB

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

Testen Sie es .. um zu sehen, ob UserA in der Lage ist, SP from schemaB. Dies wird PASS

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

UserA kann jedoch keine Daten aus SchemaB anzeigen

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

Alternativ können Sie DATABASE ROLE verwenden und Benutzer hinzufügen, um die Berechtigungen besser verwalten zu können:

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

Die folgende Anweisung stellt sicher, dass BenutzerA SchemaA und NICHT SchemaB sehen kann. Das Gute ist, dass Sie einfach Benutzer zur Rolle SchemaBUsesSchemaAProc hinzufügen können und diese alle dieser Rolle erteilten Berechtigungen erben.

GRANT SELECT ON SCHEMA::SchemaA TO SchemaBUsesSchemaAProc;
go

Wenn Sie nur zulassen möchten, dass UserA SPs ausführt, die SchemaB gehören, führt die folgende Anweisung die Aufgabe aus:

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

Auf diese Weise kann UserA die Tabellen von SchemaB nicht sehen, aber dennoch Procs von SchemaB ausführen.

Im Folgenden wird die Berechtigungshierarchie erläutert:

enter image description here

17
Kin Shah