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

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

CREATE PROC GetUserRights AS

DECLARE ©User varchar(128) SELECT ©User = USER NAME()

SELECT * FROM UserPermissions WHERE LoginID = ©User

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

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

Варианты организации системы безопасности

в современных версиях SQL Server предусмотрены два варианта организации системы безопасности.

Интегрированные средства обеспечения безопасности Windows. При использовании этих средств пользователь регистрируется в операционной системе Windows, а не в СУБД SQL Server. Аутентификация пользователя выполняется

с помощью системы обеспечения безопасности Windows на основе доверительных соединений.

Стандартный режим обеспечения безопасности. Пользователь регастрируется в СУБД SQL Server отдельно от регистрации в операционной системе Windows. Аутентификация выполняется с помощью СУБД SQL Server.

Эти два варианта организации системы безопасности рассматриваются в следующих разделах.

Обеспечение безопасности с помощью СУБД SQL Server

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

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

Для получения доступа к системе пользователь не обязательно должен быть пользователем домена.

Упрощается задача получения контроля над пользовательской информацией программным путем.

Но этот подход не лишен и недостатков, описанных ниже.

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

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

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

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

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

Даже если ваши обязанности действительно таковы, что требуется полный доступ к базе данных, воспользуйтесь учетной записью sa лишь для того, чтобы включить свою обычную учетную запись пользователя в состав роли сервера sysadmin. Это позволит вам получить все права, предназначенные для учетной записи sa, но вместе с тем обеспечить дополнительную безопасность (в связи с использованием отдельных паролей) и доступ к контрольному журналу (в программе Profiler или в средствах анализа активности операционной системы), в котором отображается информащ-хя о том, кто в настоящее время зарегистррфован в системе.

Создание учетных записей и управление ими

в настоящее время предусмотрены следующие способы создания учетных записей в СУБД SQL Server.

С использованием команды CREATE LOGIN.

С использованием программы Management Studio.

На основе объектной модели SMO (SQL Server Management Objects).

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

Команда create login

Команда CREATE LOGIN впервые появилась в версии SQL Server 2005 и разработана в рамках общих усилий, предпринимаемых корпорацией Microsoft по стандартизации синтаксиса, который используется для создания объектов сервера и базы данных. Эта команда предназначена для замены хранимой процедуры sp addlogin, которая рассматривалась как основа процедурного способа добавления учетных записей в предыдущих версиях. Команда CREATE LOGIN имеет синтаксис CREATE <object> <obj ect type>, аналогичный синтаксису создания всех прочих объектов, с которым мы неоднократно сталкивались при рассмотрении средств языка SQL, но с некоторыми дополнительными, но необязательными параметрами, которые встречаются в таких программных объектах, как хранимые процедуры.

В своей основной форме оператор CREATE LOGIN имеет несложный синтаксис, однако предусмотренный в нем способ совместного использования дополнительных