• Шифрование трафика
Использование зашифрованных контрольных сумм гарантирует целостность передаваемых данных, но не защищает их от неавторизированного просмотра. Данную проблему решает шифрование всего трафика. Заметим, что попутно при этом решается и проблема проверки целостности данных и аутентификация. Только клиент или сервер, имеющий секретный ключ, может подготовить и/или прочитать передаваемые данные.
Упомянутые выше сервисы требуют определенных накладных расходов. Наиболее накладно шифрование трафика. Проверка целостности данных дороже аутентификации. При изучении собственно модели безопасности в СОМ+ мы увидим, что клиент и сервер совместно выбирают тот уровень безопасности, который удовлетворит их требования.
Основные сценарии использования сервисов 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) этого пользователя и всех групп, в которые он входит.
4. Запрос билета для локальных сервисов
Для обращения к локальным сервисам на машине пользователя последнему также необходим билет для локальных сервисов, который автоматически и запрашивается у KDS с предъявлением TGT.
5. Получение билета для локальных сервисов
С этого момента пользователь может обращаться к локальным сервисам, на чем вход в систему и завершается.
Аутентификация клиента удаленным серверным приложением
Данный процесс выполняется автоматически при вызове клиентским приложением удаленного сервера. Точнее, здесь описывается процесс, выполняемый при первом обращении клиента к серверу в данном сеансе. В зависимости от выбранных клиентом и сервером уровнях аутентификации (этот вопрос будет рассмотрен позже), аутентификация клиента сервером может выполняться с различной периодичностью, от однократной при первом вызове сервера до аутентификации при получении каждого нового пакета. При повторной аутентификации выполняется только часть из рассматриваемых ниже операций.
Процесс аутентификации клиента С сервером S при первичном вызове состоит из следующих шагов:
• Клиент С посылает KDS запрос на получение билета для сервера S Этот запрос включает
♦ — билет TGT клиента С, зашифрованный ключом KDS
♦ имя сервера S
♦ — аутентификатор, зашифрованный ключом сессии для С и S
Аунтетификатор содержит текущее время и имя пользователя. Так как он зашифрован ключом сессии, никто кроме самого клиента С не может его сформировать. Временная метка усложняет попытку перехватить и послать этот запрос повторно от другого клиента (кроме того, KDS будет еще анализировать и IP адрес, с которого пришел запрос)
• KDS аутентифицирует клиента
Используя свой собственный секретный ключ KDS расшифровывает TGT клиента и извлекает из него ключ сессии. Используя ключ сессии, KDS расшифровывает аутентификатор. Аутентификация клиента считается успешной если