7.2.6Делегирование учетной записи безопасности — до 15 мин.

SQL Server 2000 использует средства безопасности Windows 2000 с помощью модели безопасности Kerberos. SQL Server 2000 использует протокол Kerberos для поддержки взаимной аутентификации между клиентом и сервером. Это позволяет передавать "верительные данные" клиента между компьютерами, чтобы этот клиент мог подсоединяться к нескольким серверам; при доступе к новому серверу этот сервер может продолжать работу с помощью верительных данных клиента. Это совместное использование верительных данных называется делегированием учетной записи безопасности.

Рассмотрим пример делегирования учетной записи безопасности. Предположим, что клиент подсоединяется к серверу ServerA как NTDOMAIN\AlexR, а ServerA подсоединяется к серверу ServerB. Тем самым ServerB "знает", что подсоединение осуществляется с помощью учетной записи системы безопасности NTDOMAIN\AlexR. Это позволяет клиенту обойтись без регистрации на сервере ServerB.

Если вы хотите использовать делегирование учетной записи безопасности, то все серверы, к которым вы подсоединяетесь, должны работать под управлением Windows 2000 с активизированной поддержкой Kerberos, а вы должны использовать службы Active Directory. Для делегирования работы в службах Active Directory должны быть установлены следующие параметры:

• Account is sensitive and cannot be delegated (Учетная запись является критически важной и не может быть делегирована). Этот параметр нельзя устанавливать, если пользователь запрашивает делегирование.

• Account is trusted for delegation (Учетная запись является доверяемой для делегирования). Этот параметр должен быть установлен для служебной учетной записи SQL Server 2000.

• Computer is trusted for delegation (Компьютер является доверяемым для делегирования). Этот параметр должен быть установлен для сервера, на котором выполняется один из экземпляров SQL Server 2000.

Прежде чем использовать делегирование учетных записей безопасности, вы должны сконфигурировать SQL Server, чтобы он допускал делегирование. Делегирование вызывает взаимную аутентификацию. Чтобы можно было использовать делегирование учетных записей безопасности, SQL Server 2000 должен иметь SPN-имя (Service Principal Name), назначенное администратором учетных записей домена Windows 2000. SPN-имя должно быть присвоено служебной учетной записи сервера SQL Server на данном компьютере. SPN-имя необходимо для проверки того, что SQL Server верифицирован на определенном сервере и по определенному адресу порта (socket) администратором учетных записей домена Windows 2000. Администратор вашего домена может задать SPN-имя для SQL Server с помощью утилиты Setspn, входящей в комплект Windows 2000 Resource Kit. Чтобы создать SPN-имя для SQL Server, запустите следующий оператор:

setspn -A MSSQLSvc/Host:port serviceaccount

Чтобы использовать делегирование учетных записей безопасности, вы должны также использовать TCP/IP. Вы не можете использовать именованные каналы (named pipes), поскольку SPN-имя указывает определенный порт (socket) TCP/IP. Если вы используете несколько портов, то должны иметь SPN для каждого порта.

Вы можете активизировать делегирование с помощью учетной записи LocalSystem. SQL Server выполнит саморегистрацию при запуске службы и автоматически зарегистрирует SPN-имя. Этот вариант проще, чем активизация с помощью пользовательской учетной записи в домене. Однако при закрытии SQL Server SPN-имена будут лишены регистрации для учетной записи LocalSystem. Чтобы активизировать делегирование под учетной записью LocalSystem, выполните следующий оператор в утилите Setspn:

setspn -A MSSQLSvc/Host:port serviceaccount

8Лекция № 13. Организация системы безопасности

Продолжительность: 2 часа (90 мин.)

8.1Ключевые вопросы

• Распространенные ошибки при защите сервера БД

• Внедрение SQL кода.

• Защита SQL Server в Интернет.

• Пример организации системы безопасности приложений.

8.2Текст лекции

8.2.1Распространенные ошибки при защите сервера БД — до 10 мин.

Ошибки можно разделить на три категории:

• Ошибки администрирования

• Ошибки программирования

• Ошибки реализации SQL Server

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

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

Ошибки третьей категории: множественные переполнения буфера в системных расширенных процедурах и командах DBCC, излишне "большие" разрешения на выполнение ряда системных процедур для рядовых пользователей СУБД и т.п. Единственным способом преодоления подобных проблем является регулярный мониторинг соответствующих ресурсов на предмет выхода очередных заплат, сервис паков и их немедленная установка их на сервера.