Как предоставить разрешения разработчикам предоставлять разрешения пользователям?

Question

Есть ли способ дать разработчикам право предоставлять права пользователя на объекты без предоставления им возможности создавать пользователей или функции?

Я пытаюсь ограничить права разработчиков, я недавно узнал, что у разработчиков были разрешения db_owner в средах разработчиков и prod! Поэтому я прилагаю все усилия, чтобы остановить это безумие.

Любая хорошая статья об этом вопросе?

Answer 1

Как сказано, если кто-то может выдавать разрешения, они могут выдавать разрешения для себя (или фиктивную учетную запись). Я не уверен, есть ли в SQL Server трюк, чтобы предоставить «предоставить права пользователя меньше, чем мне».

Способ, которым я бы это сделал, с хранимыми процедурами.

Создайте хранимая процедура, которая дает указанному пользователю конкретным правом или набором прав (эти права разрешены постоянным пользователям). Затем дайте разработчикам выполнить доступ к этой хранимой процедуре. Фактически вы используете хранимые процедуры для создания ограниченной версии GRANT, сохраняя при этом всю команду GRANT.

Answer 2

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

Answer 3

Вы можете сделать их членами «db_securityadmin» роли базы данных

Answer 4

Как сказал Стефан, давая им разрешения на гранты будут эффективно дать им все разрешения, так как если они хотят сделать что-то все они должны сделать, это предоставить себя разрешения для этого.

Вместо того, чтобы рассматривать разработчиков противника, вы можете подумать о том, чтобы предоставить разработчикам вторую учетную запись пользователя, которая используется для администрирования базы данных. Это довольно распространено, чтобы не давать разработчикам ЛЮБЫЕ разрешения на производство, по крайней мере, на их счете разработки.

Answer 5

Владельцы объектов могут предоставлять разрешения на эти объекты. Если вашим разработчикам не нужно предоставлять такие вещи, как права CREATE TABLE, вы можете предоставить им право собственности на объекты, на которые вы хотите получить разрешение.

Answer 6

Установка разрешения на объекты, такие как хранимые процедуры могут быть выполнены с «GRANT EXECUTE ON к;..

Однако, вы также можете предоставить обеспечительные права как на входе в систему и пользовательского уровня Вы хотите, чтобы определить и предоставить ТОЛЬКО необходимые права для объектов, которым требуется доступ (например, выполнение). Рассмотрим использование возможности «EXECUTE AS», которая позволяет олицетворить другого пользователя для проверки разрешений, необходимых для выполнения кода БЕЗ предоставления всех необходимых права на все базовые объекты (например, таблицы). EXECUTE AS может быть добавлен к сохраненным процессам, функциям, триггерам и т. д.

Добавить в корзину он закодирует следующим образом в рамках хранимой процедуры: СОЗДАТЬ ПРОЦЕДУРУ dbo.MyProcedure WITH EXECUTE AS OWNER

В этом случае вы выдаете себя за владельца вызываемого модуля. Вы также можете олицетворять SELF, или пользователь, создающий или изменяющий модуль OR ... imperonate CALLER, который позволит модулю принимать разрешения текущего пользователя, ИЛИ ... олицетворять OWNER, который возьмет на себя разрешение владелец процедуры, называемой OR ...олицетворять «имя_пользователя», которое выдаст себя за конкретного пользователя ИЛИ ... выдаст «имя_пользователя», выдаст себя за конкретный логин.

В самое короткое время вам необходимо предоставить права EXECUTE сохраненным процессам, а затем права предоставляются всем объектам, на которые ссылаются хранимые процедуры.

Таким образом, вам НЕ нужно давать неявные права (например: для обновления данных или для вызова дополнительных процедур). Собственная цепочка обрабатывает это для вас. Это особенно полезно для динамического sql или если вам нужно создать повышенные задачи безопасности, такие как CREATE TABLE. EXECUTE AS - удобный инструмент для рассмотрения.

Этот пример может помочь прояснить все это:

Создание пользователя с именем NoPrivUser с открытым доступом к базе данных (например, dbadb)

USE [мастер] GO CREATE LOGIN [NoPrivUser] С PASSWORD = N 'ABC5%', DEFAULT_DATABASE = [dbadb], CHECK_EXPIRATION = ВКЛ, CHECK_POLICY = О ГО ИСПОЛЬЗОВАНИЯ [dBAdb] GO CREATE USER [NoPrivUser] для входа в систему [NoPrivUser] GO

ПРИМЕЧАНИЕ: CREATOR или владелец этой процедуры ПОТРЕБУЕТ CREATE ТАБЛИЧНЫЕ ПРАВА в целевой базе данных.

использование DBAdb перейти CREATE ПРОЦЕДУРА dbo.MyProcedure С EXECUTE AS OWNER КАК ЕСЛИ НЕ СУЩЕСТВУЕТ (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID (N '[DBO] .MyTable') и введите (N'U ')) CREATE TABLE MyTable (PKid INT, столбец1 символ (10)) INSERT INTO MyTable VALUES (1, 'ABCDEF')

GO

GRANT EXEC ON dbo.MyProcedure TO NoPrivUser; GO

- Теперь войдите в свой сервер базы данных как NoPrivUser и выполните следующее.

использование dbadb идти

EXEC dbo.MyProcedure

(1 строка (ы) пострадавших)

Теперь попробуйте выбрать из новой таблицы при входе в систему как NoPrivuser.

вы получите следующее:

выберите * из MyTable перейти

Msg 229, Level 14, State 5, строка 1 ВЫБРАТЬ разрешение было отказано на объекте 'MyTable', базы данных 'DBAdb' , схема 'dbo'.

Ожидается, так как вы только запускали процедуру в контексте безопасности Владельца, когда вы вошли в систему как NoPrivUser. NoPrivUser как никакие права фактически читать таблицу. Просто выполните процедуру, которая создает и вставляет строки.

С условием EXECUTE AS хранимая процедура запускается в контексте владельца объекта. Этот код успешно создает dbo.MyTable, и строки успешно вставлены. В этом примере пользователь «NoPrivUser» не имеет абсолютных прав на изменение таблицы или чтения или изменения каких-либо данных в этой таблице. Он принимает только права, необходимые для выполнения этой конкретной задачи, закодированной в контексте этой процедуры.

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

Answer 7

Я обнаружил, что наиболее опасным аспектом роли 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 имеет права без возможности добавлять или удалять пользователей из фиксированных ролей базы данных. Вы должны быть в состоянии отрицать то, что вам нужно в данный момент, как сертификат резервного копирования, резервное копирование мастер-ключа и т.д.

Here список разрешений, которые могут быть отказано или предоставленных: