Безопасность SQL Server через TSQL

Question

Я хочу создать транзакционный SQL-скрипт, который не позволит указанным людям запускать определенные команды для всех баз данных:

drop database, drop table or preferbly drop *

delete

update

Возможно ли это? Пользователь уже будет иметь доступ к серверу.

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

Answer 1

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

Предположительно, ваш пользователь не является владельцем схемы (или dbo)? В этом случае у них уже не должно быть доступа к чему-либо, если вы не предоставите это. Так что не GRANT доступ, который им не нужен, REVOKE любой доступ, который вы предоставили неправильно, и DENY все, что вам абсолютно не нужно когда-либо быть в состоянии сделать.

См. Также MSDN .

Answer 2

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

Если вы используете SQL Server 2000 (или ниже), вы можете проверить разрешения безопасности для каждого логина / пользователя. В конечном счете, это то, что нужно сделать, даже если вы работаете на SQL Server 2005 или 2008, но в предыдущих версиях не было ярлыка.

Answer 3

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

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

http://www.wwwcoder.com/main/parentid/191/site/4004/68/default.aspx

Answer 4

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

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

похоже, что пользователи, которых вы хотите ограничить, должны иметь только:

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

больше ничего не должно быть предоставлено.

Answer 5

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

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

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

Обновление: один сценарий, который я могу себе представить, где это имеет смысл, если у вас есть люди, которые только генерируют отчеты. В этом случае вам следует создать учетную запись с общим статусом DENY, а затем разрешением GRANT только для Select и для определенных хранимых процедур (только тех, которые извлекают данные, полезные для отчетов).

Answer 6

вы не можете действительно проверить, видите ли вы команды сброса, потому что кто-то может сделать что-то подобное

только представьте, что вместо печати есть exec

print ( convert(varchar(50), 0x64726F7020646174616261736520616263))

вы можете предоставить им доступ только для чтения и предоставить exec-доступ только для сохраненных процедур

Вы также можете использовать триггеры DDL http://msdn.microsoft.com/en-us/library/ms190989.aspx

Вот пример

CREATE TRIGGER safety 
ON DATABASE 
FOR DROP_TABLE, ALTER_TABLE 
AS 
   PRINT 'You are not allowed to drop or alter tables!' 
   ROLLBACK
;