Страница 196 из 372
Kerberos является протоколом, обеспечивающим безопасность функционирования распределенного приложения. Разработан этот протокол в начале 80-х годов в Массачусетском технологическом институте и в настоящее время принят как стандарт, поддерживаемый различными независимыми производителями программного обеспечения. С этим стандартом можно познакомиться по RFC 1510. Windows 2000 реализует этот стандарт, и далее рассматривается именно эта реализация — Windows 2000 Kerberos. Основой для данного раздела является статья David Chappel "Exploring Kerberos, the Protocol for Distributed Security in Windows 2000", Microsoft System Journal, August 1999.
Основные сервисы
Любая реализация Kerberos обеспечивает следующие сервисы:
• Аутентификация
При входе в систему пользователя или при вызове некоторого сервера клиентом в защищенных системах выполняется процесс аутентификации, что означает, что клиент должен представить доказательства того, что он именно тот, за кого себя выдает.
Аутентификация требует передачи от клиента на сервер некоторых данных, доказывающих его (клиента) идентичность некоторому зарегистрированному в системе клиенту. Передаваемые данные должны быть зашифрованы. Kerberos использует шифрование с секретным ключом, что означает, что и отправитель, и получатель зашифрованной информации должны иметь идентичные ключи.
Реализация Kerberos в Windows 2000 поддерживает два алгоритма шифрования:
♦ DES — Data Encription Standard
Это первый официально предложенный правительством США стандарт в области шифрования, предназначенный для коммерческого использования. Длина ключа равна 64 битам, из которых 8 используются для контроля ошибок, и, следовательно, эффективная длина ключа равна 56 битам.
♦ RC4
Более быстрый алгоритм шифрования потока данных с ключом переменной длины. Именно этот алгоритм используется по умолчанию в Windows 2000 Kerberos. Длина ключа в версиях, используемых на территории США, равна 128 бит, а за пределами США — 56 бит.
• Проверка целостности данных
Здесь имеется ввиду, что получатель данных должен быть уверен, что в процессе передачи данные не были изменены. Реализация данного требования основана на вычислении контрольной суммы для каждого передаваемого пакета данных, которая в зашифрованном виде передается вместе с ним. Контрольная сумма есть значение некоторой функции от передаваемых данных, имеющей различные значения на различных данных. В Kerberos для вычисления контрольной суммы используется НМАС — Hash-based Message Authentication Code. Передача зашифрованной контрольной суммы гарантирует, что искажение (случайное или умышленное) передаваемых данных будет обнаружено на принимающей стороне.
• Шифрование трафика
Использование зашифрованных контрольных сумм гарантирует целостность передаваемых данных, но не защищает их от неавторизированного просмотра. Данную проблему решает шифрование всего трафика. Заметим, что попутно при этом решается и проблема проверки целостности данных и аутентификация. Только клиент или сервер, имеющий секретный ключ, может подготовить и/или прочитать передаваемые данные.
Упомянутые выше сервисы требуют определенных накладных расходов. Наиболее накладно шифрование трафика. Проверка целостности данных дороже аутентификации. При изучении собственно модели безопасности в СОМ+ мы увидим, что клиент и сервер совместно выбирают тот уровень безопасности, который удовлетворит их требования.
Основные сценарии использования сервисов Kerberos
В данном разделе рассматриваются основные сценарии, реализуемые в СОМ+, и способы, посредством которых Kerberos обеспечивает необходимый уровень безопасности. Но прежде всего надо остановиться на основной идее этого протокола.
Если каждая пара клиент-сервер имеют известные только им секретные ключи, то проблемы с обеспечением всех упомянутых выше сервисов нет. Проблема в масштабируемости такого подхода, в его надежности и удобстве.
Идея Kerberos состоит в том, что при обращении клиента к серверу первый должен предъявить второму специальный билет, доказывающий его идентичность и содержащий необходимую серверу информацию о правах данного клиента, о секретном ключе, используемом для шифровки пересылаемых данных, и т. п.
Рассмотрим основные поля данных билета:
• Нешифруемые поля
♦ Домен
Домен, где был выдан этот билет. Предполагается, что на контроллере домена запущен сервер Kerberos — KDS (Key Distribution Server), который и выдает все билеты в данном домене,
♦ Имя принципала
Принципалом здесь называется любая сущность, обладающая в данном домене именем и паролем. Это и все зарегистрированные в данном домене пользователи, и приложения, и машины. Все принципалы регистрируются на контролере домена в Active Directory, где в зашифрованном виде для каждого принципала хранится, в частности, его имя и хешированный пароль.
• Шифруемые поля
♦ Флаги билета
♦ Ключ сессии
Билет выдается клиенту для предъявления некоторому серверу. Именно этим ключом будут шифроваться данные, передаваемые между данными клиентом и сервером в текущей сессии (или пока не истекло время действия билета)
♦ Домен
♦ Имя принципала
Клиент не имеет доступа к зашифрованным полям билета. Сопоставляя Домен и Имя приципала в шифруемых и нешифруемых полях билета, сервер может заметить ситуацию, когда предъявляемый билет был выдан другому клиенту,
♦ Время выдачи билета
♦ Время прекращения действия билета
♦ Адреса хоста
Список IP адресов, с которых клиент может вызывать сервер
♦ Авторизационные данные
Эти данные используются сервером для определения прав данного клиента при вызове методов данного сервера.
Для дальнейшего изложения удобно использовать следующие обозначения:
• — секретный ключ принципала, полученный хешированием его пароля. В случае клиента, в случае сервера, в случае KDS
• — ключ сессии между и
• — данные, зашифрованные ключом
Вход пользователя в систему
Процесс входа пользователя в систему состоит из нескольких стадий
1. Ввод имени, домена и пароля
2. Запрос TGT (ticket-granting ticket) у KDS
Специальный билет TGT можно рассматривать как паспорт данного пользователя в данном домене (но принимаемый только KDS). При всех последующих обращениях к KDS в рамках данного сеанса клиентское приложение предъявляет KDS этот билет, доказывая идентичность пользователя. Запрос на получение TGT формируется автоматически и включает в себя
♦ Имя пользователя
♦ Временную метку — момент выдачи запроса, шифрованный ключом
3. Получение и ключа сессии между пользователем и KDS-
Получив запрос, KDC использует известные ему из Active Directory секретный ключ пользователя для расшифровки временной метки. Если расхождение между этой временной меткой и текущим временем по часам KDS не превышает 5 минут, делается вывод о том, что клиент аутентифицирован, т. к. только он мог воспользоваться секретным ключом для кодирования свежей временной метки.
Использование в протоколе Kerberos временной метки для аутентификации пользователя опционно и используется именно в реализации данного протокола в Windows 2000. При отсутствии временной метки аутентификация пользователя реально выполняется при попытке клиента расшифровать полученные от KDS данные, зашифрованные его секретным ключом, и получить ключ сессии между данным пользователем и KDS.
Билет TGT имеет структуру обычного билета. Заметим, что TGT зашифрован секретным ключом самого KDS. Никто кроме KDS, включая самого пользователя, не может прочитать шифрованные поля. В поле Ключ сессии этого билета содержится, что позволяет KDS не хранить ключи сессий со всеми своими клиентами. В поле Авторизационные данные содержатся взятые из Active Directory права данного пользователя и идентификаторы безопасности (SID) этого пользователя и всех групп, в которые он входит.