Авторизация и разрешения в SQL Server (ADO.NET)

Статья
11/04/2008

Обновлен: November 2007

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

Принцип минимальных привилегий

Подход к разработке приложений на основе учетных записей пользователей с минимальными правами доступа (LUA) представляет собой важной часть оборонительной, всесторонней стратегии противостояния угрозам безопасности. Подход LUA гарантирует то, что пользователи будут следовать принципу минимальных разрешений и всегда регистрироваться с помощью ограниченных учетных записей пользователя. Административные задачи подразделяются на категории с использованием предопределенных ролей сервера, а возможность применения предопределенной роли сервера sysadmin строго ограничивается.

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

Примечание о безопасности.
Разработка и проверка приложений с использованием подхода LUA вносит дополнительные сложности в процесс разработки. Проще создавать объекты и разрабатывать код, будучи зарегистрированным в качестве системного администратора или владельца базы данных, чем при использовании учетной записи LUA. Но разработка приложений в рамках высоко привилегированной учетной записи может не дать почувствовать влияния уменьшенных функциональных возможностей, которые обнаруживаются при попытке наименее привилегированных пользователей эксплуатировать приложение, для надлежащего функционирования которого требуется более высокий уровень разрешений. А после того как пользователям будут предоставлены чрезмерные разрешения, чтобы они могли вновь приобрести утраченные функциональные возможности, приложение может оказаться уязвимым для атаки. Проектирование, разработка и проверка приложения в условиях регистрации в учетной записи LUA требуют дисциплинированного подхода к планированию безопасности, что позволяет избежать неприятных сюрпризов и избавиться от стремления предоставлять расширенные права в целях скорейшего возобновления работы. Для проверки можно использовать имя входа SQL Server, даже если приложение предназначено для развертывания и эксплуатации с использованием проверки подлинности Windows.

Разработка и проверка приложений с использованием подхода LUA вносит дополнительные сложности в процесс разработки. Проще создавать объекты и разрабатывать код, будучи зарегистрированным в качестве системного администратора или владельца базы данных, чем при использовании учетной записи LUA. Но разработка приложений в рамках высоко привилегированной учетной записи может не дать почувствовать влияния уменьшенных функциональных возможностей, которые обнаруживаются при попытке наименее привилегированных пользователей эксплуатировать приложение, для надлежащего функционирования которого требуется более высокий уровень разрешений. А после того как пользователям будут предоставлены чрезмерные разрешения, чтобы они могли вновь приобрести утраченные функциональные возможности, приложение может оказаться уязвимым для атаки. Проектирование, разработка и проверка приложения в условиях регистрации в учетной записи LUA требуют дисциплинированного подхода к планированию безопасности, что позволяет избежать неприятных сюрпризов и избавиться от стремления предоставлять расширенные права в целях скорейшего возобновления работы. Для проверки можно использовать имя входа SQL Server, даже если приложение предназначено для развертывания и эксплуатации с использованием проверки подлинности Windows.

Разрешения на основе ролей

Если разрешения предоставляются ролям, а не пользователям, то администрирование средств безопасности упрощается. Наборы разрешений, назначенные ролям, становятся унаследованными всеми членами роли. Проще добавлять или удалять пользователей из состава членов роли, чем повторно создавать отдельные наборы разрешений для каждого пользователя. Роли могут быть вложенными; но применение слишком большого количества уровней вложенности может привести к снижению производительности. Можно также вводить пользователей в состав членов предопределенных ролей базы данных в целях упрощения задачи назначения разрешений.

Начиная с версии SQL Server 2005, можно предоставлять разрешения на уровне схемы. Пользователи автоматически наследуют разрешения на все новые объекты, создаваемые в схеме; после создания новых объектов не требуется предоставлять для них разрешения.

Управление разрешениями с помощью процедурного кода

Инкапсуляция средств доступа к данным с помощью таких модулей, как хранимые процедуры и определяемые пользователем функции, позволяет создать для приложения дополнительный уровень защиты. Чтобы исключить для пользователей возможность непосредственно взаимодействовать с объектами базы данных, можно предоставлять им разрешения только на хранимые процедуры или функции и отказывать в предоставлении разрешений на базовые объекты, такие как таблицы. В СУБД SQL Server такая цель достигается путем формирования цепочек владения.

Инструкции разрешения

Три инструкции разрешения языка Transact-SQL описаны в следующей таблице.

Инструкция разрешения	Описание
GRANT	Предоставляет разрешение.
REVOKE	Отменяет разрешение. Это — состояние нового объекта, предусмотренное по умолчанию. Разрешение, в котором отказано пользователю или роли, все еще может быть унаследовано от других групп или ролей, в которые назначен участник.
DENY	Инструкция DENY отменяет разрешение так, что его нельзя больше унаследовать. Инструкция DENY имеет наивысший приоритет по сравнению со всеми инструкциями разрешения, однако действие инструкции DENY не распространяется на владельцев объектов или на членов роли sysadmin. Если осуществляется отзыв разрешений с помощью инструкции DENY на какой-либо объект по отношению к роли public, то этот отзыв распространяется на всех пользователей и все роли, кроме владельцев объекта и членов роли sysadmin.

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

Примечание.
Членам предопределенной роли сервера sysadmin и владельцам объекта не может быть отказано в разрешениях.

Цепочки владения

SQL Server гарантирует, что только участники, которым были предоставлены разрешения, могут получить доступ к объектам. Если несколько объектов базы данных последовательно обращаются друг к другу, то такая последовательность известна как цепочка. В СУБД SQL Server при прохождении по ссылкам в цепочке владения проверка разрешений происходит иначе, чем при получении доступа отдельно к каждому объекту. Если доступ к объекту осуществляется с помощью цепочки владения, то в SQL Server вначале сравнивается владелец объекта с владельцем вызывающего объекта (который представляет предыдущую ссылку в цепочке). Если оба объекта имеют одного владельца, то разрешения для объекта, указанного в ссылке, не проверяются. После обнаружения любой ситуации, в которой доступ к объекту осуществляется со стороны объекта, имеющего другого владельца, цепочка владения разрывается и в SQL Server должна быть выполнена проверка контекста безопасности вызывающего объекта.

Процедурный код и формирование цепочки владения

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

Примечание.
Формирование цепочки владения не применяется в случае выполнения динамических инструкций SQL. Чтобы вызвать процедуру, в которой выполняется инструкция SQL, вызывающему объекту необходимо предоставить разрешения на базовые таблицы, в результате чего приложение становится уязвимым для атаки путем внедрения кода SQL. В версии SQL Server 2005 введены новые механизмы, такие как олицетворение и подписание модулей с помощью сертификатов, не требующие предоставления разрешений на базовые таблицы. Эти механизмы могут также использоваться для работы с хранимыми процедурами среды CLR.

Формирование цепочки владения не применяется в случае выполнения динамических инструкций SQL. Чтобы вызвать процедуру, в которой выполняется инструкция SQL, вызывающему объекту необходимо предоставить разрешения на базовые таблицы, в результате чего приложение становится уязвимым для атаки путем внедрения кода SQL. В версии SQL Server 2005 введены новые механизмы, такие как олицетворение и подписание модулей с помощью сертификатов, не требующие предоставления разрешений на базовые таблицы. Эти механизмы могут также использоваться для работы с хранимыми процедурами среды CLR.

Внешние ресурсы

Дополнительные сведения см. в следующих ресурсах.

Ресурс	Описание
Разрешения в электронной документации по SQL Server 2008	Содержит разделы, описывающие иерархию разрешений, представления каталога и разрешения предопределенных ролей сервера и базы данных.
Разрешения и Цепочки владения в электронной документации по SQL Server 2005	Разделы, описывающие иерархию разрешений, представления каталога и разрешения предопределенных ролей сервера и базы данных.
Управление разрешениями и Использование цепочек владения в электронной документации по SQL Server 2000.	Разделы, описывающие предоставление и управление разрешениями.