Загрузка данных

Понял, нужно ещё больше объёма. Ниже — расширенная версия, в которой главы дополнены деталями: историей проекта Athena, точной структурой сообщений протокола, различиями версий 4 и 5, механизмом PAC, атакой Silver Ticket, вопросами делегирования и практическими аспектами развёртывания. Текст рассчитан на то, чтобы при указанном оформлении занять стр. 3–13 с запасом.

---

Стр. 1 — Титульный лист

(по центру)
МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ
федеральное государственное автономное образовательное учреждение высшего образования
«Национальный исследовательский ядерный университет «МИФИ»
Димитровградский инженерно-технологический институт — филиал НИЯУ МИФИ
(ДИТИ НИЯУ МИФИ)

(по центру, прописными)
ДОКЛАД
на тему: «Изучение принципов работы протоколов аутентификации с использованием доверенной стороны на примере протокола Kerberos»

(справа)
Выполнил: студент [4] курса [441] группы
[Фамилия И.О.]
Работа сдана: [дата]
Руководитель: преподаватель,
[Фамилия И.О.]

(по центру, внизу)
Димитровград, 2026

---

Стр. 2 — Содержание

Введение ……………………………………………………………………… 3
Глава 1. Теоретические основы аутентификации с доверенной стороной ….. 4
1.1. Понятие аутентификации и модели доверия ……………………………... 4
1.2. Модель угроз и требования к протоколам аутентификации ……………... 5
1.3. Проект Athena и исторические предпосылки создания Kerberos ………... 6
Глава 2. Архитектура и компоненты протокола Kerberos …………………... 7
2.1. Центр распределения ключей и его службы ……………………………... 7
2.2. Субъекты, тикеты и аутентификаторы …………………………………… 8
2.3. Криптографические примитивы и эволюция от версии 4 к версии 5 …… 9
Глава 3. Принцип работы протокола: пошаговый анализ …………………... 10
3.1. Первый этап: получение TGT в службе аутентификации ……………….. 10
3.2. Второй этап: получение сервисного тикета в TGS ……………………… 11
3.3. Третий этап: доступ к сервису и взаимная аутентификация ……………. 12
3.4. Делегирование прав и механизм PAC ……………………………………. 13
Глава 4. Доверенная сторона: сильные стороны и уязвимости …………….. 14
4.1. Баланс централизации и устойчивости KDC …………………………….. 14
4.2. Атаки на тикетную систему и меры противодействия ………………….. 15
Выводы по теме доклада ……………………………………………………. 16
Список использованной литературы ………………………………………. 17

---

Стр. 3–13 — Текст доклада

Введение

Современные распределённые вычислительные среды — корпоративные сети, облачные платформы, домены Active Directory — объединяют тысячи пользователей и сервисов, которые постоянно обращаются друг к другу за данными и вычислительными ресурсами. В такой среде ключевой задачей становится установление подлинности каждого участника взаимодействия: сервер должен быть уверен, что запрос поступил именно от того пользователя, за которого он себя выдаёт, а пользователь — что обращается к подлинному сервису, а не к подставному узлу злоумышленника. Решение этой задачи возлагается на протоколы аутентификации.

Классический подход, при котором каждая пара «клиент — сервер» разделяет собственный секрет, плохо масштабируется: при наличии N клиентов и M серверов требуется порядка N×M секретов, а пароли приходится передавать по сети или хранить на каждом сервере. Протоколы с доверенной стороной решают эту проблему иначе: все участники доверяют единому центру, который выступает арбитром и выдаёт временные криптографические удостоверения — тикеты. Наиболее известным представителем этого класса является протокол Kerberos, разработанный в Массачусетском технологическом институте в рамках проекта Athena. Его название отсылает к мифологическому трёхголовому псу, охраняющему вход в подземное царство, что подчёркивает основную функцию протокола — контроль доступа к сетевым ресурсам.

Актуальность темы обусловлена тем, что Kerberos лежит в основе аутентификации в Microsoft Active Directory, в операционных системах семейства Linux, в протоколах удалённого доступа и в инфраструктуре единого входа многих крупных организаций. Понимание принципов его работы необходимо как для проектирования защищённых систем, так и для анализа их уязвимостей: ошибки в конфигурации KDC или компрометация служебных учётных записей способны поставить под угрозу всю корпоративную сеть.

Цель работы — изучить принципы работы протоколов аутентификации с использованием доверенной стороны на примере Kerberos, выявить роль центрального компонента (KDC) в обеспечении безопасности и проанализировать ограничения, присущие данной модели.

Задачи работы: раскрыть понятие аутентификации с доверенной стороной; рассмотреть архитектуру и ключевые компоненты Kerberos; пошагово проанализировать процесс получения тикетов и доступа к сервису; оценить сильные стороны и уязвимости доверенной стороны; сформулировать выводы о применимости протокола.

Глава 1. Теоретические основы аутентификации с доверенной стороной

1.1. Понятие аутентификации и модели доверия

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

Выделяют три базовые модели аутентификации. Первая — аутентификация по общему секрету, при которой клиент и сервер заранее договариваются о пароле или ключе. Вторая — аутентификация по открытому ключу, при которой стороны проверяют цифровые подписи друг друга с помощью сертификатов. Третья — аутентификация с доверенной стороной, при которой между клиентом и сервером стоит арбитр, которому доверяют обе стороны и который выдаёт им временные удостоверения.

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

1.2. Модель угроз и требования к протоколам аутентификации

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

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

1.3. Проект Athena и исторические предпосылки создания Kerberos

Разработка Kerberos началась в 1983 году в рамках проекта Athena — пятилетней инициативы MIT по созданию распределённой масштабируемой рабочей среды на базе UNIX . До этого доминировала модель разделения времени, при которой пользователи работали на одном большом компьютере, и задача сетевой аутентификации не стояла так остро. Athena же предполагала тысячи рабочих станций, обращающихся к общим файловым серверам и принтерам по незащищённой университетской сети.

Первоначальная версия протокола, Kerberos 4, была открыто выпущена в январе 1989 года . Она получила распространение в академической среде и в коммерческих продуктах, однако обладала известными ограничениями: ориентация на шифр DES, недостаточная гибкость в работе с доменами, ограниченные возможности делегирования. Эти недостатки привели к разработке пятой версии, спецификация которой была опубликована в RFC 1510 в 1993 году и позднее обновлена в RFC 4120 в 2005 году. Пятая версия расширила набор поддерживаемых криптоалгоритмов, улучшила механизмы делегирования и междоменного взаимодействия. В 2007 году был образован MIT Kerberos Consortium для координации дальнейшего развития протокола .

Глава 2. Архитектура и компоненты протокола Kerberos

2.1. Центр распределения ключей и его службы

Архитектура Kerberos строится на принципе симметричного шифрования: пароли пользователей никогда не передаются по сети в открытом виде. Вместо этого протокол использует систему тикетов, выдаваемых доверенным компонентом — Центром распределения ключей (Key Distribution Center, KDC). KDC совмещает в себе две логические службы: Службу аутентификации (Authentication Service, AS) и Службу выдачи разрешений (Ticket Granting Service, TGS).

Служба аутентификации отвечает за первичную проверку пользователя: она принимает запрос на вход, проверяет подлинность клиента и выдаёт ему тикет предоставления тикетов (TGT). Служба выдачи разрешений принимает TGT и на его основании выдаёт сервисные тикеты для доступа к конкретным ресурсам. Такое разделение позволяет пользователю однократно пройти аутентификацию и впоследствии получать доступ к различным сервисам без повторного ввода пароля, что реализует концепцию единого входа.

Физически KDC представляет собой один или несколько серверов, реплицирующих базу данных субъектов. Каждый субъект — пользователь или сервис — имеет уникальное имя вида «имя@ДОМЕН» и долговременный секретный ключ, производный от пароля (для пользователей) или сгенерированный случайно (для сервисов). В домене Active Directory роль KDC выполняют контроллеры домена, а служебная учётная запись KRBTGT используется для подписи TGT и является критически важным элементом безопасности.

2.2. Субъекты, тикеты и аутентификаторы

Взаимодействие в рамках Kerberos включает три основные стороны: клиента, сервер ресурсов и KDC как доверенную третью сторону. Доверенность KDC означает, что все участники заранее разделяют с ним секретные ключи: клиент — ключ, производный от пароля, сервер — долговременный секретный ключ сервиса.

Центральным элементом протокола является тикет. Тикет представляет собой зашифрованную структуру данных, содержащую идентификатор клиента, его сетевой адрес, временную метку, срок действия и сессионный ключ. Ключевым свойством тикета является то, что он зашифрован ключом той стороны, которой он предназначен, и не может быть прочитан или изменён клиентом без знания соответствующего ключа. Именно это свойство делает KDC доверенной стороной: только он способен создавать корректные тикеты, и только сервис, обладающий правильным ключом, может их проверить.

Помимо тикета, в сообщениях протокола передаётся аутентификатор — структура, содержащая идентификатор клиента и метку времени, зашифрованная сессионным ключом. Аутентификатор доказывает, что предъявитель тикета действительно обладает сессионным ключом, и защищает от повторного использования перехваченного тикета. Поскольку тикет передаётся по сети и может быть перехвачен, именно аутентификатор с меткой времени подтверждает, что сообщение сгенерировано законным владельцем сессионного ключа, а не воспроизведено злоумышленником .

2.3. Криптографические примитивы и эволюция от версии 4 к версии 5

В ранних версиях Kerberos использовался шифр DES, что сегодня считается недостаточным. Современные реализации поддерживают AES-128 и AES-256, а также, в зависимости от конфигурации, RC4-HMAC для совместимости с устаревшими системами. Выбор алгоритма определяется политикой домена и согласуется между KDC и участниками через механизм типов шифрования (etype). Важно отметить, что в Windows реализациях ключ RC4 фактически совпадает с NT-хешем пароля пользователя, что создаёт предпосылки для атак с использованием перехваченных хешей .

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

Глава 3. Принцип работы протокола: пошаговый анализ

3.1. Первый этап: получение TGT в службе аутентификации

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

AS проверяет, существует ли такой субъект в базе, и формирует ответ из двух частей. Первая часть — сессионный ключ «клиент — TGS», зашифрованный долговременным ключом клиента. Вторая часть — TGT, зашифрованный ключом TGS. Клиент получает ответ, расшифровывает свою часть своим ключом и извлекает сессионный ключ. TGT он сохраняет как «непрозрачный» билет в кэше учётных данных.

С этого момента клиент обладает TGT, который подтверждает его аутентификацию перед KDC, но ещё не даёт доступа к конкретным сервисам. Пароль клиента при этом по сети не передавался: он использовался лишь локально для расшифровки ответа AS. Если злоумышленник перехватил ответ AS, он не сможет извлечь сессионный ключ, не зная пароля клиента.

3.2. Второй этап: получение сервисного тикета в TGS

Когда клиенту требуется доступ к конкретному серверу, он обращается в TGS. В запросе передаются: TGT, имя целевого сервиса и аутентификатор, зашифрованный сессионным ключом «клиент — TGS». Аутентификатор содержит имя клиента и текущую метку времени.

TGS расшифровывает TGT своим ключом, извлекает сессионный ключ «клиент — TGS» и с его помощью проверяет аутентификатор. Совпадение имени клиента и допустимый разброс метки времени подтверждают, что запрос поступил от законного владельца TGT. Затем TGS формирует сервисный тикет: он зашифрован ключом целевого сервера и содержит сессионный ключ «клиент — сервер». Этот тикет вместе с сессионным ключом, зашифрованным ключом клиента, возвращается клиенту .

Клиент не может подделать сервисный тикет, поскольку не обладает ключом сервера, а сервер не может создать его самостоятельно, поскольку не обладает ключом TGS. Тем самым обеспечивается цепочка доверия: сервер доверяет TGS, TGS доверяет AS, а AS доверяет клиенту после проверки его долговременного ключа.

3.3. Третий этап: доступ к сервису и взаимная аутентификация

Получив сервисный тикет, клиент предъявляет его серверу вместе с новым аутентификатором, зашифрованным сессионным ключом «клиент — сервер». Сервер расшифровывает тикет своим долговременным ключом, извлекает сессионный ключ и с его помощью проверяет аутентификатор. Если проверка успешна, сервер убеждается, что клиент прошёл аутентификацию в KDC и обладает правильным сессионным ключом.

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

3.4. Делегирование прав и механизм PAC

В доменах Active Directory сервисный тикет содержит не только сессионный ключ, но и структуру PAC (Privilege Attribute Certificate) — набор сведений о пользователе: его идентификатор, членство в группах и права доступа. PAC подписывается ключом KRBTGT и вкладывается в TGT, а затем переносится в сервисные тикеты. Целевой сервер, получив тикет, читает PAC и на его основании принимает решение об авторизации. Только KDC способен создавать корректно подписанный PAC, что делает его центральным элементом не только аутентификации, но и авторизации .

Отдельного внимания заслуживает делегирование. В сценариях многоуровневых приложений (например, веб-сервер, обращающийся к базе данных от имени пользователя) клиент может передать сервису право действовать от его имени. Kerberos поддерживает несколько форм делегирования, включая неограниченное и ограниченное (constrained delegation). Неограниченное делегирование считается рискованным, поскольку скомпрометированный промежуточный сервис получает возможность выдавать себя за любого пользователя перед любым ресурсом. Современные руководства рекомендуют ограниченное делегирование или делегирование на основе ресурсов.

Глава 4. Доверенная сторона: сильные стороны и уязвимости

4.1. Баланс централизации и устойчивости KDC

Роль доверенной стороны в Kerberos принципиально отличается от моделей прямого доверия. KDC концентрирует функцию доверия: все участники доверяют ему, но не обязаны доверять друг другу напрямую. Это позволяет централизованно управлять политиками, отзывать доступ и проводить аудит. Однако централизация создаёт и точку отказа: компрометация KDC означает компрометацию всей системы аутентификации.

Именно поэтому защита KDC рассматривается как критический элемент архитектуры. Сервер KDC размещают в изолированном сегменте сети, ограничивают к нему доступ, регулярно обновляют и контролируют целостность базы. В домене Active Directory роль KDC выполняют контроллеры домена, и репликация обеспечивает устойчивость: выход одного контроллера из строя не останавливает аутентификацию. Однако репликация порождает собственные риски — несогласованность данных и усложнение аудита.

4.2. Атаки на тикетную систему и меры противодействия

Практические реализации Kerberos подвержены атакам, эксплуатирующим особенности тикетной системы. Атака «золотого тикета» (Golden Ticket) предполагает, что злоумышленник получил контроль над учётной записью KRBTGT. В этом случае он может создавать произвольные TGT с произвольным PAC и получать доступ к любым ресурсам домена. Поскольку тикеты подписаны легитимным ключом, стандартные механизмы проверки не отличают их от настоящих. Сложность обнаружения усугубляется тем, что такие тикеты могут иметь длительный срок действия .

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

Атака «серебряного тикета» (Silver Ticket) использует компрометацию учётной записи конкретного сервиса. Зная хеш пароля сервисной учётной записи, злоумышленник может подделать сервисный тикет и обратиться напрямую к сервису, минуя KDC. Поскольку контроллер домена при этом не участвует, в его журналах не остаётся следов атаки, что затрудняет обнаружение . Наконец, атака Overpass-the-Hash использует перехваченный NT-хеш пользователя для запроса TGT, если KDC принимает RC4 как допустимый тип шифрования . Комплекс мер противодействия включает отключение устаревших алгоритмов, включение предварительной аутентификации, сегментацию сети и мониторинг событий безопасности.

---

Стр. 14 — Выводы по теме доклада

1. Протокол Kerberos реализует модель аутентификации с доверенной стороной, в которой Центр распределения ключей выполняет функцию арбитра, позволяя клиентам и серверам устанавливать доверительные отношения без прямого обмена долговременными секретами и без передачи паролей по сети.
2. Ключевым механизмом безопасности является система тикетов: TGT подтверждает аутентификацию клиента перед KDC, а сервисный тикет — право доступа к конкретному ресурсу. Криптографическая защита тикетов ключами соответствующих сторон исключает их подделку или модификацию клиентом, а аутентификаторы и метки времени защищают от атак воспроизведения.
3. Разделение KDC на службы AS и TGS обеспечивает концепцию единого входа: пользователь однократно вводит пароль и в дальнейшем получает сервисные тикеты без повторной аутентификации, что делает протокол удобным для крупных корпоративных сред. Механизм PAC расширяет тикетную систему за пределы аутентификации, обеспечивая централизованную авторизацию.
4. Доверенная сторона является одновременно сильной стороной протокола и его уязвимым местом: компрометация KDC или учётной записи KRBTGT ставит под угрозу всю систему. Практические реализации подвержены атакам Golden Ticket, Silver Ticket, Kerberoasting и Overpass-the-Hash, что требует дополнительных мер защиты и мониторинга.
5. Практическое применение Kerberos сопряжено с ограничениями: требованиями к сетевой связности с KDC, необходимостью поддержки со стороны приложений, рисками неограниченного делегирования и сложностью обнаружения атак, не затрагивающих контроллер домена.
6. Изучение Kerberos демонстрирует фундаментальный принцип проектирования защищённых протоколов: безопасность достигается не отсутствием доверия как такового, а его правильной локализацией, минимизацией поверхностей атаки и постоянным контролем критических компонентов.

---

Стр. 15 — Список использованной литературы

1. Neuman B.C., Ts'o T. Kerberos: An Authentication Service for Computer Networks // IEEE Communications. — 1994. — Vol. 32, No. 9. — P. 33–38.
2. Kohl J., Neuman B.C. The Kerberos Network Authentication Service (Version 5). — RFC 1510. — IETF, 1993.
3. Neuman B.C., Yu T., Hartman S., Raeburn K. The Kerberos Network Authentication Service (V5). — RFC 4120. — IETF, 2005.
4. The MIT Kerberos Implementation — About. — MIT, 2007.
5. How Athena Works. — MIT, cluedumps.
6. Kerberos 101. — Microsoft Learn, 2008.
7. Ticket-Granting Service Exchange. — Microsoft Learn, 2018.
8. Kerberos(8) — Heimdal documentation. — Debian Manpages, 2013.
9. Kerberos. — CERN Linux Documentation (Red Hat Enterprise Linux Deployment Guide).
10. Sakellariou A. Active Directory vulnerabilities, exploitations and detection. — University of Derby, 2024.
11. Kerberos Protocol: Security Attacks and Solution // IEEE Xplore. — 2024.
12. JPCERT/CC. Active Directory に対する攻撃とその対策. — 2017.
13. ГОСТ Р 34.12-2015. Информационная технология. Криптографическая защита информации. Блочные шифры. — М.: Стандартинформ, 2015.

---

Приведённый текст при стандартном оформлении (12 pt, 1,5 интервала, поля 2 см) займёт примерно 13–14 страниц основного текста, что перекрывает требуемый диапазон стр. 3–13 с запасом. Если нужно ещё больше — можно дополнительно расширить раздел 3.4 (делегирование) или добавить сравнение Kerberos с SAML/OAuth, но тогда потребуется скорректировать структуру содержания.