Есть ли способ дать разработчикам разрешение на предоставление пользователю разрешений на объекты, не предоставляя им возможность создавать пользователей или функции?
Я пытаюсь ограничить разрешения разработчиков, недавно я узнал, что у разработчиков было db_owner разрешений в средах разработки и производства! Поэтому я делаю все возможное, чтобы остановить это безумие.
Любая хорошая статья по этому вопросу?
Как было сказано, если кто-то может раздавать разрешения, он может раздавать разрешения себе (или фиктивной учетной записи). Я не уверен, есть ли в SQL Server хитрость, обеспечивающая «предоставление прав пользователя меньше, чем у меня».
Я бы сделал это с помощью хранимых процедур.
Создайте хранимую процедуру, которая дает указанному пользователю конкретное право или набор прав (эти права разрешены обычным пользователям). Затем предоставьте разработчикам доступ к этой хранимой процедуре. По сути, вы используете хранимые процедуры для создания ограниченной версии GRANT, оставляя себе полную команду GRANT.
Вы можете сделать их членами роли базы данных "db_securityadmin"
Если кто-то может дать разрешение кому-то другому, он также может разрешить себе делать то, что он хочет. Итак, для чего это хорошо? Наверное, я не понимаю вашей ситуации.
Владельцы объектов могут предоставлять разрешения на эти объекты. Если вашим разработчикам не нужно предоставлять такие вещи, как права CREATE TABLE, вы можете дать им право собственности на объекты, на которые вы хотите, чтобы они предоставили разрешение.
Как сказал Стефан, предоставление им разрешений на грант фактически даст им все разрешения, поскольку, если они хотят что-то сделать, все, что им нужно сделать, это предоставить себе разрешения на это.
Однако вместо того, чтобы считать разработчиков врагами, вы можете рассмотреть возможность предоставления разработчикам второй учетной записи пользователя, которая будет использоваться для администрирования базы данных. Довольно часто разработчикам не дают НИКАКИХ разрешений на производство, по крайней мере, для их учетной записи разработки.
Установка разрешения на такие объекты, как хранимые процедуры, может быть выполнена с помощью «GRANT EXECUTE ON . to ;
Однако вы также можете захотеть предоставить права безопасности как на уровне входа, так и на уровне пользователя. Вы захотите определить и предоставить ТОЛЬКО необходимые права для объектов, к которым требуется доступ (например, выполнение). Рассмотрите возможность использования возможности «ВЫПОЛНИТЬ КАК», которая позволяет олицетворять другого пользователя для проверки разрешений, необходимых для выполнения кода, БЕЗ необходимости предоставлять все необходимые права всем базовым объектам (например, таблицам). EXECUTE AS можно добавить к хранимым процессам, функциям, триггерам и т. д.
Добавьте в код, как указано ниже, прямо в хранимой процедуре: CREATE PROCEDURE dbo.MyProcedure WITH EXECUTE AS OWNER.
В этом случае вы выдаете себя за владельца вызываемого модуля. Вы также можете выдать себя за СЕБЯ, ИЛИ пользователя, создающего или изменяющего модуль, ИЛИ... выдать себя за CALLER, что позволит модулю получить разрешения текущего пользователя, ИЛИ... выдать себя за ВЛАДЕЛЬЦА, который получит разрешение владелец вызываемой процедуры ИЛИ... олицетворение 'user_name', которое будет олицетворять определенного пользователя ИЛИ... олицетворение 'login_name' с олицетворением определенного логина.
БОЛЬШУЮ часть времени вам нужно будет только предоставить права EXECUTE для хранимых процедур, а затем права будут предоставлены всем объектам, на которые есть ссылки в хранимой процедуре.
Таким образом, вам НЕ нужно давать неявные права (например, для обновления данных или вызова дополнительных процедур). Цепочка владения справится с этим за вас. Это особенно полезно для динамического SQL или если вам нужно создать задачи повышенной безопасности, такие как CREATE TABLE. EXECUTE AS — удобный инструмент для таких случаев.
Этот пример может помочь прояснить все это:
Создайте пользователя с именем NoPrivUser с публичным доступом к базе данных (например, dbadb)
USE [master] GO CREATE LOGIN [NoPrivUser] WITH PASSWORD=N'ABC5%', DEFAULT_DATABASE=[dbadb], CHECK_EXPIRATION=ON, CHECK_POLICY=ON GO USE [DBAdb] GO CREATE USER [NoPrivUser] ДЛЯ ВХОДА [NoPrivUser] GO
ПРИМЕЧАНИЕ: СОЗДАТЕЛЮ ИЛИ ВЛАДЕЛЕЦУ ЭТОЙ ПРОЦЕДУРЫ ТРЕБУЕТСЯ ПРАВА СОЗДАНИЯ ТАБЛИЦЫ в целевой базе данных.
используйте DBAdb go CREATE PROCEDURE dbo.MyProcedure WITH EXECUTE AS OWNER AS IF НЕ СУЩЕСТВУЕТ (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].MyTable') AND введите (N'U')) CREATE TABLE MyTable (PKid int, column1 char(10)) INSERT INTO MyTable VALUES (1, 'ABCDEF')
GO
GRANT EXEC ON dbo.MyProcedure TO NoPrivUser; ИДТИ
-- Теперь войдите на сервер базы данных как NoPrivUser и выполните следующее.
использовать dbadb идти
EXEC dbo.MyProcedure
(затронуты 1 ряд)
Теперь попробуйте выбрать из новой таблицы, войдя в систему как NoPrivuser.
Вы получите следующее:
выберите * из MyTable перейти
Сообщение 229, уровень 14, состояние 5, строка 1. Отказано в разрешении SELECT для объекта «MyTable», базы данных «DBAdb», схемы «dbo».
Это ожидаемо, так как вы запускали процедуру только в контексте безопасности Owner при входе в систему как NoPrivUser. NoPrivUser, так как нет прав на фактическое чтение таблицы. Просто для выполнения процедуры, которая создает и вставляет строки.
С предложением EXECUTE AS хранимая процедура запускается в контексте владельца объекта. Этот код успешно создает dbo.MyTable, и строки успешно вставляются. В этом примере пользователь «NoPrivUser» не имеет абсолютно никаких прав на изменение таблицы, а также на чтение или изменение каких-либо данных в этой таблице. Он принимает только права, необходимые для выполнения этой конкретной задачи, закодированной ВНУТРИ контекста этой процедуры.
Этот метод создания хранимых процедур, которые могут выполнять задачи, требующие повышенных прав безопасности, без постоянного назначения этих прав, оказывается очень полезным.
Я обнаружил, что наиболее опасным аспектом роли db_owner является то, что если вы отказываете в разрешении, то члены роли могут вернуть его себе. Я только начал читать об этом, и я тестирую это
Create role db_ControlDatabase
grant control to db_ControlDatabase
deny backup database to db_ControleDatabase
alter role db_ControlDatabase add member TestUser
До сих пор я обнаружил, что у субъекта TestUser есть разрешения, но он не может добавлять или удалять членов фиксированных ролей базы данных. Вы должны иметь возможность отклонить все, что вам нужно на этом этапе, например, сертификат резервного копирования, мастер-ключ резервного копирования и т. д.
здесь список разрешений, которые могут быть запрещены или предоставлены:
