---

Понял. Ниже — максимально расширенная версия. Я добавил новые разделы и детализацию, чтобы основного текста (стр. 3–14) хватило с большим запасом. Оформление: Times New Roman 12, интервал 1,5, отступ 1,25, выравнивание по ширине.

---

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

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

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

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

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

---

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

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

(При верстке в Word разделы можно слегка уплотнить, чтобы уложиться в 15 страниц; текст ниже дан с запасом.)

---

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

Введение

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

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

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

Цель работы — изучить принципы работы протоколов аутентификации с использованием доверенной стороны на примере 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 для координации дальнейшего развития протокола.

1.4. Сравнение Kerberos с другими моделями аутентификации

Чтобы понять место Kerberos, полезно сравнить его с альтернативами. Аутентификация по паролю с хранением хешей на каждом сервере проста, но плохо масштабируется и создаёт множество точек утечки. Инфраструктура открытых ключей (PKI) снимает проблему общего секрета, но требует развёртывания удостоверяющих центров, управления сертификатами и их отзывом. Протоколы на основе токенов, такие как OAuth 2.0 и OpenID Connect, ориентированы прежде всего на веб-сценарии и делегированный доступ к API, тогда как Kerberos изначально проектировался для нативных сетевых протоколов и операционных систем.

Ключевое преимущество Kerberos — прозрачность для пользователя и приложений: после входа в систему пользователь получает тикеты автоматически, а приложения обращаются к ним через стандартный интерфейс GSS-API. Ключевое ограничение — привязка к инфраструктуре KDC и необходимость поддержки со стороны приложений. На практике Kerberos часто сосуществует с PKI: сертификаты используются для смарт-карт и подписи, а Kerberos — для интерактивного входа и доступа к сетевым ресурсам.

Глава 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 и является критически важным элементом безопасности. База KDC содержит не только учётные записи, но и политики: сроки действия тикетов, допустимые типы шифрования, требования к предварительной аутентификации.

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

Взаимодействие в рамках Kerberos включает три основные стороны: клиента, сервер ресурсов и KDC как доверенную третью сторону. Доверенность KDC означает, что все участники заранее разделяют с ним секретные ключи: клиент — ключ, производный от пароля, сервер — долговременный секретный ключ сервиса. Клиент может быть как интерактивным пользователем, так и службой, работающей без участия человека; в последнем случае используется либо ключевой файл (keytab), либо управляемая учётная запись.

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

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

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

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

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

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

2.4. Междоменное взаимодействие и доверительные отношения

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

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

Глава 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 доверяет клиенту после проверки его долговременного ключа. Если клиенту нужен доступ к нескольким сервисам, он повторяет этот шаг для каждого из них, используя один и тот же TGT.

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

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

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

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

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

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

3.5. Обновление тикетов, кэширование и завершение сеанса

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

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

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

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

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

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

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

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

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

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

4.3. Практические аспекты развёртывания и администрирования

Развёртывание Kerberos требует согласованной настройки всех участников. Клиенты должны иметь сетевую связность с KDC и корректно синхронизированное время: расхождение часов больше допустимого разброса приводит к отказу в аутентификации. Серверы должны иметь корректные ключи в keytab-файлах или в базе домена. Приложения должны поддерживать GSS-API или его аналоги.

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

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

---

Стр. 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.

---

Теперь текст существенно больше: добавлены разделы 1.4 (сравнение с другими моделями), 2.4 (междоменное взаимодействие), 3.5 (обновление тикетов и кэширование), 4.3 (практические аспекты развёртывания), а также расширены существующие подразделы. При верстке в Word это займёт порядка 15–17 страниц основного текста, так что при необходимости можно немного уплотнить, но запас по объёму теперь большой.