Все действия по обеспечению безопасности в SQL Server зависят от процессов аутентификации и авторизации. Если пользователь не подтвердил свою личность, и, следовательно, серверу неизвестно, какие у него имеются полномочия, попытки управлять доступом к данным ни к чему не приведут. На протяжении долгого времени Microsoft предпочитает способ регистрации, реализованный в Windows NT, способу регистрации в SQL Server, поскольку Windows обладает более эффективными механизмами проверки индивидуальных данных пользователей, чем простое сопоставление комбинаций учетной записи и пароля. Протокол аутентификации Kerberos, установленный в Windows 2000 по умолчанию, в некотором отношении еще лучше протокола аутентификации NT и, кроме того, обеспечивает идентификацию и клиента, и сервера. Рассмотрим вкратце, как работает Kerberos и как применить его функции для защиты данных на серверах SQL Server 2000. Замечу, что для использования Kerberos необходимо иметь SQL Server 2000, работающий под Windows 2000. Более подробно набор требований будет описан ниже.

Зачем нужен Kerberos?

Если приложение использует учетные данные SQL Server, то клиентская часть отправляет пароль на сервер в виде простого текста. В SQL Server 2000 по умолчанию пароль шифруется во время установления связи. Для того чтобы защитить пароль при пересылке, необходимо использовать шифрование одного из трех протоколов — Multiprotocol Net-Library, Secure Sockets Layer (SSL) или IP Security (IPSec). Из них только IPSec можно настроить в рамках целого предприятия при помощи доменных политик. Multiprotocol Net-Library имеет два недостатка: клиенты вправе не использовать его в том случае, если сервер поддерживает еще какой-либо протокол Net-Library, и он работает только с экземпляром по умолчанию. SSL требует отдельного сертификата для каждого сервера, что может увеличить расходы и затраты при обслуживании нескольких серверов. Сравнение IPSec и Kerberos проводится во врезке «IPSec против Kerberos».

Напротив, учетные данные, предназначенные для аутентификации в Windows, используют протоколы аутентификации Windows, а те всегда шифруют информацию, идентифицирующую пользователя. Смысл шифрования в том, что никто не может выступить от имени какого-либо пользователя. В протоколе аутентификации Kerberos действуют более сложные алгоритмы шифрования, чем в используемом NT протоколе NT LAN Manager (NTLM), поэтому при наличии Kerberos тому, кто вклинивается в процесс обмена информацией между клиентом и сервером, труднее похитить пароль.

Способность Kerberos идентифицировать и клиента, и сервер также дает определенные преимущества по сравнению с другими механизмами аутентификации. Если используется операционная система не Windows 2000, то SQL Server может определять пользователя либо с помощью учетных данных NT, либо с помощью учетных данных SQL Server, но лучшее, что может сделать клиент для «установления личности» сервера, — узнать его сетевой адрес. В SSL предусмотрено решение этой проблемы, поскольку сертификат сервера содержит его адрес, но он идентифицирует только компьютер, а не конкретную службу SQL Server, к которой клиент пытается получить доступ. Кроме того, при отсутствии локально управляемого сервера сертификатов Windows 2000, получение сертификатов от таких организаций, как Verisign или Thawte, — дорогостоящий процесс, занимающий много времени. Поэтому многие администраторы используют SSL только на тех серверах, где шифрование обязательно. IPSec, как и SSL, проверяет оба компьютера, но не службу SQL Server. Только аутентификация Kerberos гарантирует, что взаимодействие происходит с нужной службой SQL Server.

Что касается доступа к Web-серверам, то аутентификация Kerberos предоставляет возможность защиты Web-приложений от взаимодействия с другими SQL Server, если Web-север заражается вирусом типа Code Red. В рамках Active Directory (AD) можно предоставлять и запрещать доступ к отдельным службам, поэтому есть возможность повысить безопасность внутренней сети, разрешив своему Web-серверу взаимодействовать только с определенной службой SQL Server.

Аутентификация Kerberos

Основной принцип аутентификации Kerberos состоит в том, что, если два участника сетевой коммуникации хранят некий секрет, известный только им одним, они могут распознать друг друга, демонстрируя, что знают секрет. По умолчанию Windows 2000 использует в качестве секрета пароль, поскольку пользователь и контроллер домена всегда применяют общий пароль. Или же можно задействовать открытый ключ, но идея та же самая — подтвердить свою личность.

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

Windows 2000 могла бы свободно пересылать хешированный пароль, однако не делает этого. Kerberos использует еще один способ защиты и пароля, и хешированного значения. В процессе аутентификации провайдер Kerberos Security Provider на стороне клиента в Windows 2000 генерирует зашифрованную строку, содержащую текущее время, используя при этом хешированный пароль в качестве ключа. Затем он посылает окончательно зашифрованную строку службе Authentication Service (AS) на контроллере домена Windows 2000. Служба AS берет хешированный пароль для указанной учетной записи из базы данных AD и дешифрует присланную клиентом строку. Если дешифровка проходит успешно, а время, значащееся в строке, не сильно отличается от текущего времени на контроллере домена, то AS может быть уверена, что пользователь, находящийся за клиентским компьютером, знает общий секрет (пароль). Подробный рассказ о том, как работает процесс аутентификации, можно найти в третьей главе книги Дэвида Чаппела «Understanding Microsoft Windows 2000 Distributed Services» (изд-во Microsoft Press, 2000).

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

В тот момент, когда Джо регистрируется на своем компьютере, службы Windows 2000 Local Security Authority и Kerberos Security Provider работают совместно с контроллером домена и аутентифицируют сочетание учетной записи и пароля. При успешном завершении этой процедуры служба выдачи билетов Ticket Granting Service (TGS), работающая на контроллере домена совместно с AS, посылает билет на получение разрешений Ticket Granting Ticket (TGT) на компьютер Джо (см. Рисунок 1). TGT содержит информацию о SID, принадлежащем Джо, и обо всех SID всех доменных групп, которым принадлежит его учетная запись. Эта информация нужна службе TGS для создания новых билетов, которые предоставили бы Джо право использовать другие службы не только на его компьютере, но и на других машинах сети.

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

Помимо сеансового ключа TGS зашифровывает части каждого билета, предназначенного для той или иной службы, с помощью хешированного пароля. Основное преимущество этого частичного шифрования состоит в том, что только две стороны, знающие ключ, могут просматривать или менять зашифрованные данные. Так, например, Джо не может, манипулируя билетом, сделать себя членом глобальной группы Domain Admins и получить права системного администратора (sysadmin) в SQL Server. Более того, частичное шифрование билета доказывает службе, что его создал контроллер домена, потому что только контроллер домена и служба знают ключ. И, наконец, это косвенно доказывает, что контроллер домена к тому моменту аутентифицировал Джо, так как у Джо нет другого способа получить билет, зашифрованный при помощи секретного ключа службы. После успешной регистрации в системе компьютер Джо обладает его хешированным паролем, который он может использовать в качестве:

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

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

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

Делегирование

Аутентификация между клиентом и сервером — лишь одна из функций Kerberos. Еще одна функция — делегирование — позволяет одному SQL Server подключаться к другому серверу, используя имя и пароль, введенные пользователем при регистрации в системе. Пусть, например, Джо создал запрос к серверу A, в котором затребовал некоторые данные сервера B.

В SQL Server 6.5 и 7.0 для подключения к серверу B от сервера A Джо может воспользоваться данными учетной записи для регистрации в SQL Server (но не своей учетной записью Windows 2000/NT). В SQL Server 6.5 запросы к удаленным машинам требуют использования хранимых процедур. Самый простой способ разрешить эту ситуацию в SQL Server 7.0 — установить удаленное соединение серверов. Однако SQL Server 2000 может обращаться с данными из запроса, который выполняется на удаленном сервере, как если бы они были получены из локальной таблицы. Такая интеграция с удаленными источниками данных в синтаксисе T-SQL предполагает подключение SQL Server к источникам данных без участия пользователя.

Благодаря делегированию у пользователя появляется дополнительная гибкость при доступе к нескольким серверам, с учетом различий в наборах полномочий на них. Например, Джо может иметь разрешения SELECT, INSERT, UPDATE и DELETE на сервере A и в то же время только разрешение SELECT на сервере B. В версиях SQL Server, предшествовавших SQL Server 2000, разрешить запросу, выполняемому на сервере A, получить данные от сервера B можно было с помощью хранимых процедур, допускающих только чтение данных. Такой подход требует модификации хранимых процедур при каждом изменении пользовательских прав на обработку данных. Делегирование же дает администраторам возможность управлять полномочиями на всех серверах, используя встроенные команды авторизации SQL Server.

Делегирование является естественным развитием идеи аутентификации Kerberos. Если Джо отправляет на сервер A свой TGT и сеансовый ключ, общий для него и контроллера домена, сервер A может запрашивать билет у сервера B от имени Джо (см. Рисунок 2). TGT уже зашифрован с помощью хешированного значения контроллера домена, поэтому контроллер домена знает, что TGT действителен. Сеансовый ключ Джо, общий для него и контроллера домена, зашифрован с использованием сеансового ключа, общего для Джо и сервера A. Следовательно, если Джо доверяет серверу A настолько, что дает ему сеансовый ключ, контроллер домена рассматривает запрос сервера A, как если бы Джо был зарегистрирован на сервере A.

Делегирование Kerberos действует для любого количества экземпляров SQL Server, а также работает и для других служб. XML и .NET Web-службы в среде SQL Server предоставляют новые возможности для выполнения запросов к данным из внешних источников. Кроме того, разработчики Microsoft подготовили модуль расширения SQL Server 2000 — SQLXML, доступный по адресу: http://msdn. microsoft.com/ downloads/ default.asp?URL=/ downloads/ sample.asp?url=/ msdnfiles/ 027/001/824/msdncompositedoc.xml. Он позволяет приложениям на базе .NET использовать хранимые процедуры как .NET Web-службы. Такая функциональность открывает широкие возможности в плане применения SQL Server как промежуточного звена для других серверов SQL Server и даже источников нереляционных данных. Делегирование, или возможность перемещать учетные данные от сервера к серверу, — лучший способ извлечь пользу из этих новых функций.

Требования

Для того чтобы использовать Kerberos, между клиентами и серверами SQL Server должен быть домен Windows 2000, который может работать либо в смешанном, либо в собственном режиме. Необходимо установить SQL Server 2000 на сервер Windows 2000, а все клиентские компьютеры, обращающиеся к серверу, должны работать под Windows XP (Professional или .NET Server) или Windows 2000 (любой серверной версии или Professional). Компьютеры, работающие с операционными системами, отличными от XP или Windows 2000, не могут задействовать Kerberos ни для аутентификации, ни для шифрования.

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

Чтобы использовать делегирование, служба MSSQLServer должна выполнить регистрацию с учетной записью домена, но не с локальной учетной записью LocalSystem. Для учетной записи домена следует настроить два параметра, открыв оснастку AD Users and Computers консоли Microsoft Management Console (MMC) и перейдя на вкладку Account. Затем нужно убрать флажок Account is sensitive and cannot be delegated («Учетная запись не может быть делегирована»). Далее следует установить флажок в ячейке Account is trusted for delegation («Учетная запись может быть делегирована»), как показано на Рисунке 3.

Рисунок 3. Настройка делегирования.

Кроме того, в учетной записи сервера должно быть выбрано свойство Computer is trusted for delegation («Компьютер может участвовать в делегировании»). Данный параметр можно настроить в диалоговом окне свойств компьютера в оснастке AD Users and Computers. Эти настройки требуют наличия полномочий администратора.

В оперативной документации (Books Online, BOL) по SQL Server говорится, что нужно также воспользоваться утилитой setspn из комплекта Windows 2000 Server Resource Kit и с ее помощью для службы SQL Server создать основное имя службы Service Principal Name (SPN). С другой стороны, SQL Server 2000 автоматически создает SPN при запуске. Чтобы проверить, существует ли SPN, следует запустить утилиту setspn с параметром -L и просмотреть поле SPN для учетной записи службы, с которой она выполнила регистрацию в системе.

Проверка

Для проверки сети необходимы по крайней мере контроллер домена Windows 2000, клиентский компьютер с Windows 2000 или XP Professional и сервер Windows 2000 в качестве рядового сервера с SQL Server 2000. Несмотря на то что лучше всегда поддерживать применение последних пакетов обновления (service packs), аутентификация Kerberos должна работать при любом сочетании пакетов обновления на компьютерах. Помимо серверов нужно установить Windows 2000 Server Resource Kit на системы с Windows 2000 Professional и SQL Server. Две утилиты из этого комплекта — KerbTray и setspn — позволяют просматривать билеты Kerberos.

После конфигурирования SPN и проверки наличия у службы SQL Server записи в AD, необходимо убедиться в том, что учетная запись, которая будет использоваться на клиентском компьютере, может подключиться к SQL Server. Проще всего для этого использовать Query Analyzer и учетную запись Windows 2000/NT. Чтобы гарантировать отсутствие проблем с учетными данными SQL Server, следует настроить SQL Server на использование только аутентифицированных имени и пароля Windows 2000/NT. Если это пробное соединение устанавливается успешно, можно быть уверенным, что аутентификация пользователя пройдет без проблем.

Следующие шаги необходимы для того, чтобы проверить, использует ли клиентский компьютер для аутентификации Kerberos. На клиентском компьютере в комплекте ресурсов нужно найти инструмент KerbTray, открыть его и просмотреть список билетов, находящихся в кэш-памяти локального компьютера. Убедившись, что билет для SQL Server есть, следует повторить эту процедуру на компьютере с SQL Server и проверить, есть ли билет на клиентский компьютер. Наконец, необходимо выполнить в Query Analyzer команду SELECT SUSER_SNAME(), чтобы выяснить, совпадает ли SID учетной записи клиента с идентификатором учетной записи в SQL Server. При регистрации с учетной записью SQL Server системный идентификатор пользователя (SUID) остается пустым, поэтому, если виден SID, это означает, что вход выполнен с именем и паролем Windows 2000/NT.

О процессе аутентификации можно собрать больше информации, если включить аудит событий регистрации и завершения сеанса, а также журнал событий Kerberos. Если включить аудит через доменную политику, можно увидеть события на всех серверах домена. Для включения журнала событий Kerberos следует добавить в реестр следующий подраздел: HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet ControlLsa Kerberos Parameters.

В подразделе Parameters нужно добавить параметр типа DWORD с именем LogLevel и присвоить ему значение 1. Эти записи следует добавить на всех серверах, на которых необходимо вести журнал событий Kerberos. После перезагрузки сервера эти события можно будет увидеть в журнале System.

Если возникнут проблемы при настройке клиентского компьютера на использование Kerberos, сначала следует проверить состояние SPN. При неправильной конфигурации SPN аутентификация возвращается к протоколу аутентификации Windows. Еще один источник проблем — разрешения, назначенные учетным записям компьютеров и клиента. Локальные доменные и групповые политики, примененные к имеющимся компьютерам и учетным записям, могут препятствовать подключению к SQL Server. Если есть подозрения, что проблемы связаны с политиками, то наиболее вероятно, что причина — в настройках безопасности.

Окончательный результат

После всех попыток аутентификации службы SQL Server и клиента, SQL Server получает о клиенте такую же информацию, как об имени и пароле Windows 2000/NT, не использующих Kerberos. Независимо от того, как выполняется аутентификация пользователя, операционная система создает маркер доступа, содержащий SID пользователя и SID всех локальных и доменных групп, которым он принадлежит. Затем SQL Server просматривает список SID и проверяет, не совпадает ли один из них с какой-либо записью в таблице sysxlogins главной базы данных. Если совпадение есть, то SQL Server разрешает доступ к своим базам данных.

Разрешения в пределах баз данных также действуют независимо от протокола аутентификации, используемого клиентом для регистрации. Если говорить об учетных записях домена Windows 2000, разрешения и роли неизменно назначаются на основе SID учетных записей, поэтому если пользователь уже зарегистрировался в системе, во внутренней структуре авторизации SQL Server 2000 ничего не меняется.

Единственное отличие от SQL Server 7.0 состоит в том, что во всех случаях клиент XP/Windows 2000, подключаясь к серверу XP/Windows 2000, пытается выполнить аутентификацию с помощью Kerberos. Если попытка не удается, XP/Windows 2000 возвращается к протоколу NTLM, используемому NT и Windows Me/9x. Поскольку SQL Server 2000, 7.0 и 6.5 оставляют аутентификацию учетных записей доменов на усмотрение операционной системы, некоторую пользу из применения Kerberos можно извлечь, запуская SQL Server под Windows 2000. Помните, что по умолчанию, прежде чем SQL Server «увидит» запрос имени и пароля, будет выполнена аутентификация всех доверительных связей в рамках операционной системы. Несмотря на то что пользователи Server 6.5 и 7.0 не могут задействовать SPN для аутентификации или применить делегирование для подключения к удаленным серверам, хорошо уже то, что Kerberos превосходит NTLM по параметрам безопасности и что в Windows 2000 реализованы усовершенствованные инструменты управления. IPSec также легче настраивать под Windows 2000, чем под NT, поэтому даже если нет желания переходить к SQL Server 2000, стоит рассмотреть возможность модернизации NT до Windows 2000.

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

Морис Льюис - президент компании Holitech, специализирующейся на консалтинге и обучении технологиям Internet и разработкам корпорации Microsoft в области баз данных. С ним можно связаться по адресу: morris@holitech.com

IPSec против Kerberos

Решая проблемы среды безопасности, многие задумываются о том, что лучше использовать для аутентификации и шифрования — IPSec или Kerberos. Основная разница между ними в том, что в IPSec выполняется аутентификация при взаимодействии компьютер-компьютер, а в Kerberos аутентификация происходит при взаимодействии пользователь-сервис. IPSec не контролирует доступ к работающим на сервере службам; он определяет, может ли пользователь подключиться к компьютеру на уровне IP-адреса, а не на уровне приложения. Таким образом, Kerberos для аутентификации пользователей SQL Server предпочтительней.

Если же говорить о шифровании, то лучше выбрать IPSec, потому что сетевые протоколы ни у клиента, ни у сервера SQL Server 2000 не позволяют включить шифрование Kerberos. IPSec может шифровать весь поток данных в сети и защитить их от любого вмешательства. В IPSec также реализована функция обязательного требования шифрования для успешного соединения. Если приоритетной задачей является защита данных в сети, то следует выбрать IPSec, потому что он предназначен для защиты от большего количества атак и поддерживается обеими платформами — и Windows, и UNIX/Linux.