Создайте разрешение процедуры ТОЛЬКО

У меня есть требование в SQL Server 2008 в базе данных разработки

  1. Только DBA (кто владельцы базы данных) может создать, изменить таблицы. Разработчик не должен создавать или изменять таблицы.
  2. Разработчики могут создать/изменить Хранимую процедуру / Определяемые пользователем функции в dbo схеме и могут выполнить SP/UDF.
  3. Разработчики должны иметь ВЫБОР, ВСТАВИТЬ, УДАЛИТЬ, ОБНОВЛЕНИЕ на таблицах (таблицы в dbo схеме

Как достигнуть этого оператора GRANT использования


Найденный демонстрационным решением от Google, но все еще имеют проблему

CREATE LOGIN testdev WITH PASSWORD = 'sldkjlkjlkj 987kj//'

CREATE USER testdev

GRANT ALTER ON SCHEMA::dbo TO testdev
GRANT CREATE PROCEDURE TO testdev
GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::dbo TO testdev

CREATE TABLE mysig (a int NOT NULL)
EXECUTE AS USER = 'testdev'
go

CREATE PROCEDURE slaskis AS PRINT 12
go

CREATE TABLE hoppsan(a int NOT NULL) -- FAILS!
go

INSERT mysig (a) VALUES(123)
go

REVERT
go

DROP PROCEDURE slaskis
DROP TABLE mysig
DROP USER testdev
DROP LOGIN testdev

Синтаксис выше способного для блокирования разработчика для составления таблицы, но разработчика блока наклона, чтобы использовать дизайн SSMS и изменить таблицу.

Спасибо.

5
задан marc_s 28 June 2010 в 09:58
поделиться

1 ответ

Прежде всего, я бы использовал роли вместо предоставления доступа напрямую пользователям. Возможно, вы уже делаете это, но я подумал, что упомяну об этом.

Хорошо, проблема здесь в том, что предоставление ALTER схеме означает, что получатель разрешения имеет доступ ALTER ко всем типам объектов в схеме. К сожалению, насколько мне известно, нет возможности предоставить разрешения для определенных типов объектов, так что это все или ничего. И наоборот, вы не можете предоставить ALTER для всех объектов, а затем запретить ALTER для определенных типов объектов.

Я нашел единственный способ сделать это - предоставить ALTER схеме и затем использовать триггер DDL для управления действиями роли.

Вот обновленная версия вашего примера, демонстрирующая принцип:

--** Create a Developer Role
CREATE ROLE [Developer] AUTHORIZATION db_securityadmin;
GO

--** Grant view and execute on all SPs to Devloper
--GRANT VIEW DEFINITION ON SCHEMA::dbo TO [Developer];
GRANT CREATE PROCEDURE TO [Developer];
GRANT SELECT, INSERT, UPDATE, DELETE, ALTER, EXECUTE, VIEW DEFINITION ON SCHEMA::dbo TO [Developer]

--** Create user and login for testdev and add to the Developer role
CREATE LOGIN testdev WITH PASSWORD = 'sldkjlkjlkj987kj' 
CREATE USER testdev 
EXEC sp_addrolemember @rolename = 'Developer', @membername = 'testdev';
GO

--** Create DDL trigger to deny drop and alter to the Developer role
CREATE TRIGGER tr_db_DenyDropAlterTable_Dev 
ON DATABASE 
FOR DROP_TABLE, ALTER_TABLE 
AS 
BEGIN 
   IF IS_MEMBER('Developer') = 1 
   BEGIN 
       PRINT 'You are not authorized to alter or drop a table.'; 
       ROLLBACK TRAN; 
   END; 
END; 
GO

--** Testing
CREATE TABLE mysig (a int NOT NULL) ;

EXECUTE AS USER = 'testdev'; 
GO

CREATE PROCEDURE slaskis AS PRINT 12; 
GO

CREATE TABLE hoppsan(a int NOT NULL); -- FAILS! 
GO

INSERT mysig (a) VALUES(123); 
GO

ALTER TABLE mysig ADD test INT; --** This will fail too
GO 

REVERT; 
GO

DROP PROCEDURE slaskis ;
DROP TABLE mysig ;
DROP USER testdev;
DROP LOGIN testdev;
DROP ROLE [Developer];
DROP TRIGGER tr_db_DenyDropAlterTable_Dev on DATABASE;
9
ответ дан 14 December 2019 в 04:30
поделиться
Другие вопросы по тегам:

Похожие вопросы: