Аутентификация и авторизация в ИБ

«Аутентификация и авторизация кажутся простыми — ввёл логин с паролем и получил доступ. Но на деле это сложный, многоуровневый мир протоколов, токенов и правил, где каждая ошибка конфигурации открывает дверь нарушителям. Российские стандарты, такие как требования 152-ФЗ к управлению доступом, лишь обрамляют эту техническую реальность, которую нужно понимать изнутри.»

Различие между аутентификацией и авторизацией

Аутентификация отвечает на вопрос «Кто вы?». Это процедура проверки заявленной идентичности субъекта — пользователя, устройства или сервиса. Она подтверждает, что вы действительно тот, за кого себя выдаёте, через факторы знания (пароль), владения (токен) или свойства (биометрия).

Авторизация решает вопрос «Что вам разрешено?». После того как система узнала, кто вы, она определяет, к каким ресурсам и операциям у вас есть права. Успешная аутентификация не гарантирует доступ — система может корректно идентифицировать вас, но отказать в авторизации, и это нормальная, а не ошибочная ситуация.

Протоколы аутентификации

Выбор протокола зависит от среды применения: сетевое подключение, веб-приложение или административный доступ.

EAP (Extensible Authentication Protocol)

Это не конкретный протокол, а фреймворк, поддерживающий множество методов аутентификации, таких как EAP-TLS (на основе сертификатов), EAP-PEAP (с туннелированием) и другие. Его ключевая роль — работа в связке со стандартом контроля доступа к сети 802.1X.

Преимущества: Гибкость, поддержка современных криптографических методов, возможность централизованного управления через сервер RADIUS. Риски: Сложность развёртывания, уязвимости конкретных методов (например, устаревший EAP-MD5).

CHAP и PAP

Эти протоколы исторически использовались для аутентификации соединений PPP (Point-to-Point Protocol), например, в dial-up или VPN.

PAP (Password Authentication Protocol) передаёт логин и пароль в открытом виде, что делает его непригодным для использования в ненадёжных сетях.

CHAP (Challenge-Handshake Authentication Protocol) безопаснее: сервер отправляет клиенту случайную строку (challenge), а клиент возвращает хеш, вычисленный от этой строки и своего пароля. Сам пароль по сети не передаётся, что защищает от перехвата. Однако CHAP уязвим к атакам методом перебора, если используется слабый пароль.

Сегодня эти протоколы считаются устаревшими, и для новых проектов рекомендуется переход на методы на основе EAP-TLS.

802.1X (Port-Based Network Access Control)

Этот стандарт реализует концепцию «закрытого порта». До успешной аутентификации сетевое устройство (коммутатор, точка доступа) блокирует весь трафик клиента, кроме кадров протокола EAP.

Архитектура включает три компонента:

  • Supplicant (клиент): Программное обеспечение на устройстве пользователя.
  • Authenticator (аутентификатор): Сетевое устройство, управляющее доступом к порту.
  • Authentication Server (сервер аутентификации): Обычно сервер RADIUS, который проверяет учётные данные.

Используется для защиты корпоративных проводных и беспроводных сетей, часто в рамках решений NAC (Network Access Control).

Схема взаимодействия Supplicant, Authenticator и Authentication Server в 802.1X

RADIUS и TACACS+

Это протоколы AAA (Authentication, Authorization, Accounting), обеспечивающие централизованное управление доступом.

>Архитектура AAA

Критерий RADIUS TACACS+
Транспорт UDP (порты 1812, 1813) TCP (порт 49)
Шифрование Только пароль в запросе доступа Всё тело пакета
Объединённая (аутентификация и авторизация в одном пакете) Модульная (отдельные сессии для каждой функции)
Основное применение Аутентификация пользователей сети (VPN, Wi-Fi) Администрирование сетевого оборудования (командно-уровневый контроль)

RADIUS распространён шире из-за простоты и поддержки множеством устройств. TACACS+, часто ассоциируемый с оборудованием Cisco, предоставляет более детальный контроль за командами, выполняемыми администраторами.

Единый вход и федерация идентичности

Эти технологии решают проблему множества паролей и разрозненных учётных записей.

Single Sign-On (SSO)

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

Реализация требует наличия центрального поставщика идентификации (IdP), которому доверяют все поставщики услуг (SP).

SAML и OpenID Connect

Это два основных стандарта для реализации федеративной идентичности и SSO.

SAML (Security Assertion Markup Language) использует XML-токены (assertions) для передачи утверждений об аутентификации и атрибутов пользователя от IdP к SP. Он зрелый, надёжный и широко применяется в корпоративных средах, часто интегрируется с Active Directory.

OpenID Connect (OIDC) — это современный стандарт, построенный поверх OAuth 2.0. Он использует лёгкие JSON Web Tokens (JWT). OIDC лучше подходит для веб- и мобильных приложений, API и сценариев, где важна производительность и простота разработки.

OAuth 2.0

Критически важно понимать: OAuth 2.0 — это протокол авторизации, а не аутентификации. Его цель — позволить приложению получить ограниченный доступ к ресурсам пользователя на другом сервисе (например, доступ к вашему фотоальбому в облаке) без необходимости передавать ему ваш пароль. Он работает через токены доступа. Для аутентификации используется расширение OAuth 2.0 — OpenID Connect.

Kerberos

Протокол, основанный на симметричном шифровании и системе билетов. Является основой аутентификации в доменах Windows (Active Directory). Пользователь, аутентифицировавшись один раз, получает билет выдачи билетов (TGT). Затем, для доступа к конкретному сервису (например, файловому share), он на основе TGT запрашивает у центра распределения ключей (KDC) сервисный билет.

Преимущества: Взаимная аутентификация, защита от повторного воспроизведения атак, прозрачный единый вход в пределах домена. Риски: Уязвимость к атакам типа «золотой билет» при компрометации мастер-ключа (KRBTGT), зависимость от точной синхронизации времени.

Архитектура доверия и PKI

PKI формирует основу доверия для большинства современных протоколов (TLS, EAP-TLS, подпись кода). Её сердце — иерархия центров сертификации (CA), выпускающих цифровые сертификаты стандарта X.509.

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

Различают несколько типов сертификатов:

  • SSL/TLS сертификаты: Для аутентификации веб-серверов.
  • Клиентские сертификаты: Для аутентификации пользователей или устройств (например, в VPN).
  • Сертификаты для подписи кода: Гарантируют, что ПО не было изменено после выпуска.
  • Сертификаты для подписи документов: Эквивалент собственноручной подписи.

Критические практики управления PKI

  • Безопасное хранение ключей: Закрытые ключи корневых и промежуточных центров сертификации должны храниться в аппаратных модулях безопасности (HSM) или изолированных системах.
  • Своевременная ротация: Регулярное обновление сертификатов и ключей до истечения срока их действия.
  • Контроль отзыва: Использование списков отозванных сертификатов (CRL) или протокола OCSP для проверки актуальности статуса.
  • Автоматизация: Применение протоколов вроде ACME (используется Let’s Encrypt) для автоматического получения и обновления TLS-сертификатов.
Упрощённая схема иерархии PKI: корневой CA -> промежуточный CA -> сертификаты серверов и пользователей

Практические шаги по внедрению

Мероприятие Приоритет Статус
Внедрить многофакторную аутентификацию для всех внешних и критичных систем Высокий
Настроить единый вход через SAML или OpenID Connect Высокий 🔄
Замена устаревших протоколов (PAP) на защищённые (EAP-TLS, CHAP) Высокий
Направление логов аутентификации и авторизации в систему SIEM Средний
Автоматизация жизненного цикла SSL/TLS сертификатов Средний 🔄

✅ Выполнено | 🔄 В процессе | ❌ Не начато

Ключевые принципы

  • Разделяйте процессы: Аутентификация и авторизация — разные механизмы. Их разделение повышает безопасность и гибкость системы.
  • Многофакторность как стандарт: Для любого доступа извне или к конфиденциальным данным MFA должна быть обязательной, а не опциональной.
  • Централизация управления: Федерация идентичности и SSO упрощают администрирование и улучшают пользовательский опыт, но требуют тщательной настройки отношений доверия.
  • Инфраструктура как основа доверия: PKI и корректное управление сертификатами — фундамент для TLS, подписей и аутентификации на основе сертификатов.
  • Непрерывный мониторинг: Логирование, аудит и анализ событий AAA (Authentication, Authorization, Accounting) критически важны для расследования инцидентов и соответствия требованиям регуляторов.
  • Автоматизация: Автоматизация рутинных операций (выпуск сертификатов, управление доступом) снижает человеческий фактор и операционные риски.

Оставьте комментарий