2016-12-14 1 views
0

Я попытался найти ответ, но этот сценарий кажется уникальным или необычным. Выполнение SQL 2008 и 2012. Мы хотели бы настроить пользователя, который может только читать данные, выполнять хранимые процедуры и просматривать определение хранимой процедуры (последний бит является необязательным). Назовем этого пользователя «servicedesk». Я также создал роль под названием «Exec_sps»SQL, предоставить пользователю только readaccess, выполнить хранимую процедуру для вставки, удаления, удаления и т. Д.

Хранимые процедуры должны иметь возможность вставлять, обновлять, удалять, отбрасывать таблицу. Но пользователь «servicedesk» не должен это делать вообще. Только с помощью хранимой процедуры. И пользователь, конечно, не должен сам изменять процедуру.

Мне удалось создать доказательство концепции, добавив выполнение в роль и добавив пользователя «servicedesk» к этой роли. Но когда я это делаю, пользовательский «справочный центр» всегда получает более высокое разрешение на изменение хранимой процедуры, чего мы хотим избежать.

Таким образом, в основном, предоставить низкий доступ к пользователю, пользователь может выполнить хранимую процедуру и много разрешений для этой процедуры, без того, чтобы пользователь наследовал доступ к хранимым процедурам.

Это выполнимо?

С уважением

+1

Почему вы хотите, чтобы эта роль могла просматривать определение вашей процедуры? Это кажется довольно глупым. Они могут рассматривать логику, но ничего не могут сделать. Если им нельзя доверять данные, почему им следует доверять, чтобы просмотреть логику? –

+0

Привет. Фактически просмотр определения хранимой процедуры не является обязательным. Важно то, что пользователь может «исправлять» данные через хранимую процедуру, не имея возможности модифицировать что-либо своими собственными привилегиями, вне хранимой процедуры. –

+1

Я полагаю, вы могли бы выполнить хранимые процедуры как кто-то с более высокими привилегиями. например 'create proc myproc с выполнением как 'myadminaccount' как begin ...' – ZLK

ответ

0

Требования, кажется странным для меня, но это, кажется, работает в SQL 2012.

запустить этот сценарий, как [са] или Войти с членством в фиксированной серверной роли [сисадмина]:

CREATE LOGIN ServiceDesk 
WITH PASSWORD = '123ABCdef' 

USE YourDatabase 
GO 

CREATE USER SDUser 
FOR LOGIN ServiceDesk 
GO 

CREATE TABLE dbo.Stooge(
    ID INT IDENTITY PRIMARY KEY, 
    Name VARCHAR(32) 
) 

CREATE PROC dbo.AddStooge 
    @StoogeName VARCHAR(32) 
AS 
INSERT INTO dbo.Stooge(Name) VALUES(@StoogeName); 
GO 

CREATE PROC dbo.UpdateStooge 
    @StoogeId INT, 
    @NewName VARCHAR(32) 
AS 
UPDATE dbo.Stooge 
SET Name = @NewName 
WHERE ID = @StoogeId 
GO 

CREATE PROC dbo.DeleteStooge 
    @StoogeId INT 
AS 
DELETE FROM dbo.Stooge 
WHERE ID = @StoogeId 
GO 

CREATE PROC dbo.DropStoogeTable 
WITH EXECUTE AS OWNER 
AS 
IF EXISTS (SELECT * FROM INFORMATION_SCHEMA.TABLES t WHERE t.TABLE_SCHEMA = 'dbo' AND t.TABLE_NAME = 'Stooge') 
    DROP TABLE dbo.Stooge; 
GO 

ALTER ROLE db_datareader ADD MEMBER SDUser 
GRANT EXECUTE ON dbo.AddStooge TO SDUser 
GRANT EXECUTE ON dbo.UpdateStooge TO SDUser 
GRANT EXECUTE ON dbo.DeleteStooge TO SDUser 
GRANT EXECUTE ON dbo.DropStoogeTable TO SDUser 

Теперь подключить как логин [ServiceDesk] (созданный выше) и запустить скрипт команды по одному:

USE YourDatabase 
GO 
--[SDUser] should be able to select from any table. 
SELECT * FROM dbo.Stooge 

--[SDUser] should be able to execute [AddStooge] proc. 
EXEC dbo.AddStooge 'Larry' 
EXEC dbo.AddStooge 'Carly' 
EXEC dbo.AddStooge 'Moo' 

--verify stooges added. 
SELECT * FROM dbo.Stooge 

--Fix spelling mistake. [SDUser] should be able to execute [UpdateStooge] proc. 
EXEC dbo.UpdateStooge 2, 'Curley' 

--Verify updated stooge 
SELECT * FROM dbo.Stooge 

--[SDUser] should be able to execute [DeleteStooge] proc. 
EXEC dbo.DeleteStooge 3 

--Verify deleted stooge 
SELECT * FROM dbo.Stooge 

--This should fail. [SDUser] should not be able to alter proc. 
ALTER PROCEDURE dbo.DeleteStooge 
    @StoogeId INT 
AS 
    IF NOT EXISTS (SELECT * FROM dbo.Stooge WHERE ID = @StoogeId) 
     RAISERROR('Stooge does not exist', 16, 1); 
    ELSE 
     DELETE FROM dbo.Stooge 
     WHERE ID = @StoogeId 
GO 

--[SDUser] should not be able to view the proc definition. ([ROUTINE_DEFINITION] is null) 
SELECT r.ROUTINE_NAME, r.ROUTINE_DEFINITION 
FROM INFORMATION_SCHEMA.ROUTINES r 
WHERE r.ROUTINE_NAME = 'DeleteStooge' 
GO 

--[SDUser] should be able to execute [DropStoogeTable] proc. 
EXEC dbo.DropStoogeTable; 
+0

Спасибо, я попробую эти примеры и посмотрю, что произойдет. –