26 марта 2026 года системный интегратор в области информационной безопасности iTProtect объявил о соглашении с вендором Identity Blitz: в портфеле интегратора появился сервер аутентификации — продукт класса Identity Provider, закрывающий единый вход (SSO), многофакторную аутентификацию и централизованное управление учётными записями. Для выпускника ИТ-направления это не просто новость рынка. Пока интеграторы собирают портфели из отечественных IAM-решений, заказчики и рецензенты всё чаще проверяют дипломные проекты на один и тот же признак зрелости: умеет ли автор спроектировать вход в систему, а не только форму поверх базы данных. Аутентификация даёт редкое сочетание — понятную теорию, измеримые метрики и очевидную экономику внедрения. Ниже разберём, как превратить этот новостной повод в структуру работы, к которой не придраться.
Актуальность. Появление новых интеграционных соглашений вокруг серверов аутентификации показывает, что рынок переходит от разрозненных «самописных» логинов к централизованному Identity Provider. Значит, типовой дипломный проект «веб-приложение для отдела X» без SSO выглядит устаревшим уже на этапе постановки задачи.
Цель: разработать архитектуру и прототип подсистемы аутентификации и авторизации, обеспечивающей единый вход в 3–5 внутренних сервисов.
Структура: Глава 1 — анализ угроз аутентификации, обзор стандартов и решений; Глава 2 — архитектура подсистемы, модели угроз по методике ФСТЭК, диаграммы последовательности; Глава 3 — реализация, тестирование, расчёт экономического эффекта от отказа от нескольких паролей.
Актуальность. Сервер аутентификации в портфеле крупного интегратора ИБ — сигнал, что MFA перестала быть «фичей» и стала требованием регуляторов и заказчиков.
Цель: обосновать и проверить на прототипе переход от однофакторной аутентификации к криптографической (WebAuthn) с сохранением резервного канала.
Структура: Глава 1 — теория аутентификации и человеческий фактор; Глава 2 — проектирование доверенной среды, жизненный цикл ключей; Глава 3 — эксперимент с группой пользователей и метрики удобства.
Актуальность. Тренд на замену собственной таблицы пользователей внешним сервером аутентификации напрямую отражён в новости: интегратор добавляет чужой продукт в портфель, а не пишет свой.
Цель: показать, как микросервисы получают доверенную идентичность без «протаскивания» сессий через все сервисы.
Структура: Глава 1 — паттерны аутентификации в распределённых системах, принципы Zero Trust; Глава 2 — проектирование потоков токенов и схемы развёртывания; Глава 3 — тестирование, отказоустойчивость, RTO/RPO.
Первая глава чаще всего проваливается в реферат. Чтобы этого не случилось, привяжите сравнение к требованиям вашей системы: число пользователей, требуемый уровень доверия, наличие внешних подрядчиков, законодательные ограничения. Сравнивайте не «продукты вообще», а протоколы и подходы — это защищается гораздо легче.
| Протокол / подход | Где уместен | Плюсы для ВКР | Что придётся объяснять комиссии |
|---|---|---|---|
| SAML 2.0 | Веб-SSO, корпоративные приложения, федерации | Зрелые готовые библиотеки, XML-обмен понятен для схем | Многословность разметки, сложность отладки подписей |
| OpenID Connect поверх OAuth 2.0 | SPA, мобильные клиенты, микросервисы | JSON, компактные токены, легко показать метрики | Разница между аутентификацией и делегированием доступа |
| Kerberos | Внутренняя доменная среда, рабочие станции | Сильная криптография, отсутствие передачи пароля | Требования к инфраструктуре и синхронизации времени |
| LDAP-каталог | Хранение учётных записей, справочник пользователей | Простая интеграция, знакомый стек | LDAP — не протокол аутентификации сам по себе, а каталог |
Отдельно стоит блок обоснования выбора стека: здесь уместно опереться на ГОСТ 34.602-2020 (требования к техническому заданию на автоматизированную систему) и на модель качества ISO/IEC 25010 — вы сравниваете варианты по функциональной полноте, защищённости, сопровождаемости и производительности, а не «мне так удобнее».
Архитектура подсистемы аутентификации отлично ложится на три обязательных диаграммы:
Код в дипломе по этой теме обычно невелик, но он должен быть осмысленным. Достаточно показать валидацию токена и получение claims:
# Проверка access-токена через discovery-документ сервера аутентификации
curl -s -X POST https://idp.example.local/realms/corp/protocol/openid-connect/token \
-d "grant_type=authorization_code" \
-d "client_id=warehouse-web" \
-d "code=${AUTH_CODE}" \
-d "code_verifier=${PKCE_VERIFIER}" \
-d "redirect_uri=https://warehouse.example.local/callback" | jq '.access_token'
Важно не только «получить токен», но и объяснить, как сервис проверяет подпись, срок жизни, издателя и область действия. Комиссия почти всегда спрашивает: «Что будет, если токен украдут?» — и ответ про 5-минутный срок жизни плюс отдельный короткий refresh-токен звучит убедительно.
Раздел тестирования — то, что отличает инженерную работу от описательной. Минимальный набор метрик, который считается быстро и подтверждается логами или отчётом инструмента:
| Группа метрик | Показатель | Как получить |
|---|---|---|
| Производительность | Пропускная способность (аутентификаций в секунду), p95 времени ответа | Нагрузочный прогон с постепенным ростом числа виртуальных пользователей |
| Надёжность | Доступность за период, MTTR, RTO и RPO при отказе провайдера | Отключение узла, измерение времени переключения на резервный |
| Безопасность | Доля успешных входов после серии попыток подбора, срабатывание блокировок | Эмуляция перебора, разбор журналов событий |
| Удобство | Среднее время входа, доля отказов от второго фактора | Замер на группе пользователей, журнал регистрации методов MFA |
Для наблюдаемости на стенде хватит сбора метрик и трассировок: тайминги по операциям токен-эндпоинта, счётчики ошибок, отдельная панель с графиком задержек. Если стенд собран в Kubernetes, добавьте описание проб готовности и пределов ресурсов — это отличный материал для третьей главы и для защиты по отказоустойчивости.
Типичные ошибки студентов.
Уровень входа ниже, чем кажется. Развернуть стенд с готовым сервером аутентификации в контейнерах можно за вечер, основная работа — интеграция двух-трёх клиентов и оформление схем. Сложность растёт не в коде, а в обосновании решений: именно это и оценивают.
Зависит от формулировки задач в задании. Если в цели стоит «разработать подсистему», нужен рабочий прототип: манифесты развёртывания, настройки клиентов, обработчик обратного вызова на стороне сервиса. Чистая конфигурация без собственного кода обычно читается как «администрирование», а не «разработка».
Единый нотационный стиль на всю работу: диаграммы компонентов и последовательностей, схема развёртывания, при необходимости — схема данных. Каждая диаграмма должна иметь подпись, ссылку в тексте и легенду. Не смешивайте на одном рисунке бизнес-процесс и сетевую топологию.
Генерируйте: скрипт создания учётных записей с реалистичными атрибутами (отдел, должность, роль) и разными методами второго фактора. Для нагрузочных прогонов — синтетические сессии с разным профилем. Реальные персональные данные использовать нельзя, и это стоит отдельно проговорить в разделе о защите информации.
Если тема уже выбрана, но непонятно, с чего начать проектную главу, — начните с одной консультации. Мы бесплатно разберём вашу формулировку цели и задач, подскажем, какой объём реализации реально успеть, и поможем выстроить структуру работы. Средний объём поддержки по такому направлению — около 120 часов: от постановки задачи и схем до оформления и подготовки к защите. Работаем с любой темой, включая интеграцию серверов аутентификации и построение защищённых контуров.
Источник: iTProtect и Identity Blitz заключили соглашение о сотрудничестве (опубликовано 2026-03-26)