Добавление разрешений к роли приложения

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

Снова перейдем к выполнению краткого примера:

GRANT SELECT ON Region TO OurAppRole

После вьшолнения этого примера роли приложения предоставляется право использовать оператор SELECT применительно к таблице Region, но доступ к чему-либо еще тем самым не обеспечивается.

Использование роли приложения

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

sp setapprole [@rolename =] <role name>,

[©password =] {Encrypt Npassword}password [, [©encrypt =] <encryption style>]

Параметр ©rolename задает имя той роли приложения, которую необходимо активизировать.

Пароль может быть задан с помощью параметра ©password либо в непосредственном виде, либо в зашифрованном виде с использованием функции шифрования ODBC. Если решено использовать зашифрованный пароль, то необходимо задать этот пароль в кавычках после ключевого слова Encrypt и ввести перед первой кавычкой префикс N, который служит для СУБД SQL Server указанием на то, что приведена строка Unicode и ее необходимо обработать соответствующим образом. Обратите внимание на то, что параметр с ключевым словом Encrypt задан в фигурных скобках ({}), а не в круглых. Если решено не использовать предварительное шифрование, то достаточно задать пароль, не указывая ключевое слово Encrypt.

Параметр ©encrypt требуется, только если пред)смотрено задание зашифрованного пароля в качестве значения параметра password. Если пароль зашифрован, то в качестве значения параметра ©encrypt должно быть указано ODBC.

Важно иметь в виду, что шифрование пароля может применяться только для клиентских программ ODBC и OLE DB, Если же в клиентской программе используется библиотека DB-Lib, то шифрование становится неприменимым.

Прежде чем приступить к рассмотрению примеров, проверим, какими правами обладает пользователь TestAccount. К этому моменту (при условии, что читателем были выполнены все примеры, приведенные в данной главе) пользователь TestAccount не должен иметь прав доступа к таблице Region, но возможность обращаться к таблице EmployeeTerritories должна быть ему предоставлена. Для проверки того, что дела обстоят именно так, можно выполнить несколько операторов SELECT:

SELECT * FROM Region

SELECT * FROM EmployeeTerritories

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

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

sp setapprole OurAppRole, {Encrypt Npassword}, odbc

После выполнения этой команды должно быть получено подтверждение, что применяемая роль приложения теперь активизирована.

Проверьте, так ли это, вызвав на выполнение те же два оператора SELECT, и вы обнаружите, что оператором, выполняемым успешно, окажется тот, который перед этим приводил к получению сообщения о неудачном завершении, и наоборот. Таким образом, пользователь TestAccount имел доступ к таблице EmployeeTerritories, но после перехода к применению роли приложения это право доступа было утрачено. С другой стороны, пользователь TestAccount не имел доступа к таблице Regions, но роль приложения позволила ему получить такой доступ.

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

Удаление ролей приложения

После того как необходимость в использовании роли приложения на сервере отпадает, можно применить хранимую процедуру sp dropapprole, чтобы удалить эту роль приложения из системы. Оператор вызова хранимой процедуры sp dropapprole имеет следующий синтаксис: sp dropapprole [©rolename =] <role name>

Чтобы удалить рассматриваемую роль приложения из системы, достаточно выполнить такую команду (от лица пользователя sa): ЕХЕС sp dropapprole OurAppRole

Более сложные проблемы обеспечения безопасности

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

Применение учетной записи guest

Учетная запись guest предоставляет своего рода способ получения доступа без указания конкретных сведений о пользователе. Если в системе разрешено использо-

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

Учетные записи получают доступ на уровне пользователя guest к любой базе данных, к которой им явно не предоставлен доступ.

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

Сам автор после любой инсталляции СУБД SQL Server первым делом удаляет даже самые незначительные с виду права, которыми можно было бы воспользоваться с помощью учетной записи guest. Любые права учетной записи guest становятся предпосылкой взлома защиты, причем наличие таких прав приводит к получению несанкционированного доступа с применением такого способа, который даже невозможно себе представить, не зная всех нюансов. (Многие разработчики считают, что предоставление прав какой-то учетной записи приводит к обладанию лишь этими правами. Но если учетная запись guest активна, это правило не соблюдается.) Автор рекомендует всем поступать точно так же.

Тем не менее автору известно о существовании по меньшей мере одного способа применения учетной записи guest, в которой она позволяет весьма изящно решать серьезную проблему; речь идет об использовании гостевой учетной записи с ролями приложения. Этот способ состоит в том, что учетной записи guest предоставляется доступ к базе данных, но не назначаются какие-либо права, за исключением обычной регистрации в этой базе данных; таким образом, учетная запись guest служит лишь для того, чтобы база данных, в которой с ее помощью выполнена регистрация, стала текущей. Затем можно воспользоваться хранимой процедурой sp setapprole для активизации роли приложения и приступить к работе. Итак, описанный способ позволяет пользователям, которые во всех прочих отношениях остаются анонимными, регистрироваться на сервере с соответствующими правами. Но сама регистрация будет иметь для анонимных пользователей какой-либо смысл, только если они эксплуатируют конкретное приложение.

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

Настройки порта TCP/IP

По умолчанию на сервере SQL Server для создания соединения с помощью набора протоколов TCP/IP используется порт 1433. Порт можно сравнить с радиоканалом; чтобы можно было связаться по конкретному каналу, на него должны быть настроены и передатчик, и приемник.