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

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

Предположительно, ваш пользователь не является владельцем схемы (или dbo)? В этом случае у них уже не должно быть доступа к чему-либо, если вы этого не ПРЕДОСТАВЛЯЕТЕ. Так что не ГРАНТ доступ, который им не нужен, ОТЗЫВ - любой доступ, который вы предоставили неправильно, и ОТКАЗЫВАТЬСЯ ОТ - все, что вы абсолютно не хотите, чтобы они когда-либо могли делать.

См. Также MSDN.

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

Stored procedures provide significant benefits when it comes to security. By using a stored procedure, you can grant permissions to certain users to access data, reducing the immense coding that you need to do in your client applications. This is one of the best ways to control access to your data.

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

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

просто представьте, что у этого есть exec вместо print

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
;

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

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

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

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

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

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

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

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

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

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

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