---

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

---

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

(Верхний блок — выравнивание по центру)
Министерство науки и высшего образования Российской Федерации
[Название учебного заведения]
[Название кафедры]

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

(Правый блок — выравнивание по правому краю)
Выполнил: студент группы [номер]
[Фамилия И.О.]
Проверил: [Фамилия И.О. преподавателя]

(Нижний блок — по центру)
[Город]
2026

---

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

Введение ……………………………………………………………………… 3

1. Исторические предпосылки и архитектура Kerberos ……………………. 4
2. Ключевые компоненты и участники аутентификации …………………... 6
3. Принцип работы протокола: от TGT к сервисному тикету ……………... 8
4. Доверенная сторона как основа безопасности …………………………... 10
5. Уязвимости и ограничения практической реализации ………………….. 12
   Выводы по теме доклада ……………………………………………………. 14
   Список использованной литературы ………………………………………. 15

---

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

Введение

Современные распределённые вычислительные среды требуют надёжных механизмов подтверждения подлинности субъектов доступа. Протокол Kerberos, разработанный в Массачусетском технологическом институте (MIT) в рамках проекта Athena в конце 1980-х годов, представляет собой классический пример протокола аутентификации с использованием доверенной стороны . Его название отсылает к мифологическому трёхголовому псу, охраняющему вход в подземное царство, что подчёркивает основную функцию протокола — контроль доступа к сетевым ресурсам.

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

1. Исторические предпосылки и архитектура Kerberos

Протокол Kerberos возник как ответ на проблему передачи паролей в открытом виде по незащищённым каналам связи. Первые версии (с первой по третью) не выходили за пределы MIT, однако четвёртая версия получила широкое распространение, в том числе в академической среде и коммерческих продуктах, таких как файловая система AFS . Четвёртая версия обладала рядом известных ограничений и уязвимостей, что привело к разработке пятой версии, спецификация которой была опубликована в RFC 1510 в 1993 году, а позднее обновлена в RFC 4120 в 2005 году .

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

2. Ключевые компоненты и участники аутентификации

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

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

3. Принцип работы протокола: от TGT к сервисному тикету

Процесс аутентификации в Kerberos разворачивается в несколько этапов. На первом этапе клиент направляет в AS запрос, содержащий его идентификатор и метку времени, зашифрованную его секретным ключом. AS проверяет подлинность клиента и возвращает два компонента: сессионный ключ, зашифрованный ключом клиента, и Тикет предоставления тикетов (Ticket Granting Ticket, TGT), зашифрованный ключом TGS . TGT содержит информацию о клиенте и сессионный ключ, но клиент не может его прочитать или модифицировать. С этого момента клиент обладает TGT, который подтверждает его аутентификацию перед KDC, но ещё не даёт доступа к конкретным сервисам.

На втором этапе, когда клиенту требуется доступ к конкретному серверу, он предъявляет TGT в TGS вместе с запросом на сервисный тикет. TGS проверяет TGT, извлекает сессионный ключ и формирует новый тикет — Сервисный тикет (Service Ticket), зашифрованный ключом целевого сервера. Клиент получает этот тикет и может предъявить его серверу. Сервер, расшифровав тикет своим ключом, убеждается, что он выдан доверенной стороной (TGS), и предоставляет доступ. Важно, что клиент не может подделать сервисный тикет, поскольку не обладает ключом сервера, а сервер не может создать его самостоятельно, поскольку не обладает ключом TGS.

4. Доверенная сторона как основа безопасности

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

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

5. Уязвимости и ограничения практической реализации

Несмотря на концептуальную стройность, практические реализации Kerberos подвержены атакам, эксплуатирующим особенности тикетной системы. Одной из наиболее известных является атака «золотого тикета» (Golden Ticket), при которой злоумышленник, получивший контроль над учётной записью KRBTGT (служебной учётной записью KDC), может создавать произвольные TGT и получать доступ к любым ресурсам домена . Другой класс атак, Kerberoasting, направлен на извлечение сервисных тикетов и их офлайн-взлом с целью получения паролей сервисных учётных записей .

Кроме того, Kerberos предъявляет требования к инфраструктуре: клиенты должны иметь сетевую связность с KDC, а приложения — поддерживать Kerberos (быть «кеберозированными») . Для унаследованных приложений, не поддерживающих протокол, это создаёт сложности внедрения. Наконец, существуют уязвимости реализации, такие как CVE-2025-60704 в Windows Kerberos, связанная с пропуском криптографической проверки при обработке тикетов и позволяющая повысить привилегии . Это подчёркивает, что даже зрелые протоколы требуют постоянного внимания к качеству кода и своевременного обновления.

---

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

1. Протокол Kerberos реализует модель аутентификации с доверенной стороной, в которой Центр распределения ключей (KDC) выполняет функцию арбитра, позволяя клиентам и серверам устанавливать доверительные отношения без прямого обмена долговременными секретами.
2. Ключевым механизмом безопасности является система тикетов: TGT подтверждает аутентификацию клиента перед KDC, а сервисный тикет — право доступа к конкретному ресурсу. Криптографическая защита тикетов ключами соответствующих сторон исключает их подделку или модификацию клиентом.
3. Доверенная сторона является одновременно и сильной стороной протокола (централизованное управление, масштабируемость, единый вход), и его уязвимым местом: компрометация KDC или учётной записи KRBTGT ставит под угрозу всю систему.
4. Практическое применение Kerberos сопряжено с ограничениями: требованиями к инфраструктуре, необходимостью поддержки со стороны приложений и наличием специфических атак (Golden Ticket, Kerberoasting), что требует дополнительных мер защиты и мониторинга.
5. Изучение 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. Kerberos 101. — Microsoft Learn, 2008 .
4. Kerberos(8) — Heimdal documentation. — Debian Manpages, 2013 .
5. Kerberos. — CERN Linux Documentation (Red Hat Enterprise Linux Deployment Guide) .
6. Kerberos Protocol: Security Attacks and Solution // IEEE Xplore. — 2024 .
7. CVE-2025-60704 in Windows Kerberos. — VulDB, 2025 .
8. Active Directory vulnerabilities, exploitations and detection. — Zenodo, 2024 .