Типы разрешений SQL Server

Question

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

Многие из нас не знакомы с безопасностью SQL Server и столкнулись с ситуациями, когда мы развертываем что-то только для ограничения разрешений, например, для TRUNCATE TABLE.

Это просто раздражение на данном этапе, но я попытался найти сводный список (cheatsheet? Cribsheet? Reference lookup?), Чтобы легко проверять такие функции, чтобы это не так просто, но я не нашли.

Я знаю, что статья MSN для каждой функции перечисляет эти данные, но я не хочу, чтобы каждый отдельный просмотр на конкретном веб-сайте для каждой общей и редкой функции просто для проверки, особенно если мне нужно сделать это больше, чем один раз, потому что я забыл (например).

Ближайший я нашел, были сайты, подобные этим:

https://www.mssqltips.com/sqlservertip/1718/database-level-permissions-for-sql-server-2005-and-2008/

https://www.simple-talk.com/sql/database-administration/sql-server-security-cribsheet/

... но они были неполными (не могли найти TRUNCATE в обоих из них) и немного долго: Я надеюсь, что где-то есть таблица, которая просто помещает «действие -> имя действия -> имя разрешения -> сервер/уровень таблицы -> роль по умолчанию» или что-то вместе в одном месте.

Есть ли такой список где-нибудь?

Answer 1

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

Для сценария, который вы пытаетесь решить, похоже, что вы используете модули (SP) для четкого определения действий, разрешенных для пользователей, не являющихся администраторами, правильно? В этом случае вы можете использовать модули с цифровой подписью для предоставления соответствующих разрешений при выполнении SP вместо прямого назначения разрешения. Например:

CREATE USER [low_priv_user] WITHOUT LOGIN 
go 

CREATE TABLE [dbo].[myTable](data int); 
go 

CREATE PROC [dbo].[sp_truncate_my_table] 
AS 
    TRUNCATE TABLE [dbo].[sp_truncate_my_table]; 
go 

GRANT EXECUTE ON [dbo].[sp_truncate_my_table] TO [low_priv_user] 
go 

-- Will fail due to permission 
EXECUTE ('EXEC [dbo].[sp_truncate_my_table];')AS USER = 'low_priv_user'; 
go 

-- Create a certificate to sign the SP, 
CREATE CERTIFICATE [signing_cert] 
    ENCRYPTION BY PASSWORD = '<you_could_use_masetr_key_instead_of_p@55w0rD5>' 
    WITH SUBJECT = 'demo - module signature'; 
go 
-- sign the SP 
ADD SIGNATURE TO [dbo].[sp_truncate_my_table] BY CERTIFICATE [signing_cert] 
    WITH PASSWORD = '<you_could_use_masetr_key_instead_of_p@55w0rD5>'; 
go 
-- destroy the private key 
ALTER CERTIFICATE [signing_cert] REMOVE PRIVATE KEY; 
go 

-- Create a user for the certificate & grant it all the permissions you would need for running teh SP 
CREATE USER [signing_cert] FROM CERTIFICATE [signing_cert]; 
go 
GRANT ALTER ON [myTable] TO [signing_cert]; 
go 

-- Permission check will be OK for the low privileged user 
-- You control what this user is allowed to do via SPs 
EXECUTE ('EXEC [dbo].[sp_truncate_my_table];')AS USER = 'low_priv_user'; 
go 

Как вы можете видеть, что я создал модуль, который позволяет абоненту звонить TRUNCATE на столе, без предоставления ALTER разрешения непосредственно пользователю.

В идеале, при использовании этого механизма вы хотели бы следовать принципу наименьших привилегий и предоставлять только требуемые разрешения и ничего больше; но если вам не удается найти точные разрешения, которые вам нужны, вы можете использовать ярлык: GRANT CONTROL TO [signing_cert].

Очевидно, что такой ярлык имеет существенные последствия для безопасности, поскольку вы буквально предоставляете полный контроль над своей базой данных подписанному коду (включая динамический SQL, выполняемый в этих модулях), но если вы решите это сделать, я бы рекомендовал следующие меры предосторожности :

• уничтожить секретный ключ, чтобы никто не злоупотребляет его
• не использовать динамический SQL в ваших подписанных модулей (или, по крайней мере, убедитесь, что вы не подвержены инъекции SQL)
• Если возможно, избежать давая CONTROL разрешение на модули, где вы может предоставить минимальные привилегии.
• Аудит всей деятельности вашей базы данных.

Я также включаю в себя копию ссылки SQL Database Engine Permission Poster, которая может быть полезна.

Надеюсь, эта информация поможет.