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

«Для российского ИБ-специалиста самая частая ошибка — считать, что аутентификация и авторизация сводятся к проверке пароля и роли. На самом деле ФСТЭК и 152-ФЗ требуют построить юридически значимую систему доказательств: кто, когда и на каком основании получил право на действие. Без этой доказуемости любая, даже самая криптостойкая, система не пройдет проверку.»

Федеральные требования: не функция, а каркас доказательств

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

Неизменность идентификатора. Уникальный ключ, привязанный к пользователю или службе, должен сохраняться на протяжении всего жизненного цикла в системе. Перевыпуск учётной записи без сохранения логической связи разрывает цепочку событий в журналах, делая их бесполезными для долгосрочного расследования.
Неразрывная связь события и субъекта. Каждая операция — вход, проверка прав, их изменение — фиксируется с привязкой к уникальному идентификатору, точной временной метке и результату. Шестимесячный срок хранения логов обусловлен практикой: внутренние расследования часто запускаются с серьёзной задержкой.
Минимизация привилегий как процесс, а не настройка. Разграничение прав — это не разовое создание матрицы RBAC. Регулятор требует регулярный, документированный пересмотр обоснованности каждого права для каждой учётной записи. Без этого журнал изменений привилегий становится формальностью, маскирующей реальные, зачастую избыточные, уровни доступа.

Ключевая особенность — доказуемость. Можно внедрить самый современный протокол, но если его работа не описана в организационно-распорядительных документах, а события не поступают в систему аудита в полном объёме, проверка зафиксирует нарушение. В контексте ФСТЭК недоказанное соответствие равнозначно несоответствию.

Разделение ответственности: аутентификация против авторизации

Чёткое разделение этих понятий критично для распределения ответственности при инцидентах. Аутентификация отвечает на вопрос «Кто это был?», авторизация — «Имел ли он право на это действие?». Сбой аутентификации — проблема службы управления идентификацией. Провал авторизации — претензия к архитекторам системы и владельцам бизнес-процессов, утверждавших политики доступа.

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

Глубинная связь: как журналы входа меняют политики доступа

Журналы аутентификации — это не просто сырые данные для SIEM. Их контекстуальный анализ становится основой для динамической корректировки авторизации. Если пользователь регулярно проходит MFA из географически аномальной локации, система авторизации должна получить сигнал для риск-ориентированного ограничения его сессии — например, временного запрета на экспорт данных. Такая связка между системами выходит за рамки буквальных требований, но соответствует их духу — активному предотвращению ущерба на основе поведения.

Выбор протоколов: баланс между стойкостью и аудитом

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

802.1X с EAP-TLS. Стандарт для контролируемого сетевого доступа. С точки зрения ФСТЭК критична не сама технология, а детальное логгирование на RADIUS-сервере: должен фиксироваться не только успех или провал, но и предъявленный сертификат, что необходимо для полноценного расследования.
OpenID Connect (OIDC) с локальным Identity Provider. Для веб-приложений. Ключевой момент — способность провайдера идентификации (IdP) передавать в SIEM обязательные атрибуты сессии, такие как уникальный идентификатор сессии и использованный метод аутентификации. Многие зарубежные облачные IdP не предусматривают такой интеграции «из коробки».
Kerberos в Active Directory. Работоспособное решение для внутренней инфраструктуры, но требующее углублённой настройки аудита. Без логов, фиксирующих процесс выдачи билетов (TGT), невозможно отследить делегирование полномочий между службами — классический вектор атаки.
Многофакторная аутентификация (МФА). Требования ФСТЭК делают акцент на независимости факторов. Пароль и SMS-код считаются двумя факторами, но оба зависят от инфраструктуры мобильного оператора, что создаёт единую точку отказа. Аппаратные токены (FIDO2) или TOTP-приложения, генерирующие код на отдельном устройстве, рассматриваются как более надёжные.

Техническая реализация: от политик до процессов

Внедрение — это выстраивание замкнутой, документируемой цепочки действий, где каждый шаг оставляет проверяемый след.

Политики паролей. Их недостаточно просто активировать. Требуется автоматизированный механизм, который с заданной периодичностью формирует и проверяет отчёт о соответствии всех учётных записей (включая системные) установленным правилам. Отсутствие такого отчёта — прямое указание на формальный подход.
Блокировка учётных записей. Статический порог в 5 неудачных попыток — лишь основа. Система должна учитывать контекст: 5 попыток за минуту с одного IP — это атака. 5 попыток, растянутых на неделю с разных IP в рабочее время, — сигнал для службы безопасности, а не повод для автоматической блокировки, которая может парализовать работу.
Централизованное управление доступом (SSO). Главная выгода с точки зрения 152-ФЗ — создание единой точки аудита для событий входа во все связанные приложения. При выборе решения необходимо убедиться, что оно способно передавать в SIEM полный контекст сессии, включая метод аутентификации и её уникальный идентификатор.
Регулярная переаттестация прав. Этот процесс должен быть максимально автоматизирован. Владелец ресурса получает автоматическое уведомление со списком лиц, имеющих доступ, и обязан подтвердить или отозвать каждое право. Архив таких подтверждений с электронными подписями или отметками в ITSM — первое, что запросит аудитор.

Аудит и отчётность: демонстрация работающего процесса

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

Журналы аутентификации. Помимо стандартных полей (пользователь, время, IP, результат) требуется обязательная фиксация метода аутентификации (пароль, сертификат, TOTP) и уникального идентификатора сессии. Без этого невозможно связать разрозненные события в единую цепочку действий пользователя.
Журналы управления учётными записями. Каждое изменение — создание, блокировка, смена пароля, назначение роли — должно фиксироваться с указанием администратора, совершившего действие, и формального основания (например, номера заявки в ITSM). Без этого журнал теряет доказательную силу.
Проверки принципа наименьших привилегий. Отчёт по такой проверке должен содержать не просто список избыточных прав, но анализ причин их появления, а также утверждённый план исправления с назначенными ответственными и сроками.
Интеграция с SIEM. Необходима настройка корреляционных правил, специфичных для регуляторных требований. Например: «Выдача роли «Администратор БД» пользователю, не входящему в группу «DBA»» или «Успешный вход в критичную систему в нерабочие часы после серии неудачных попыток». Наличие таких правил и отчётов по ним — прямое доказательство работоспособности мониторинга.

Риски несоответствия: что скрывается за штрафами

Прямые финансовые санкции — лишь верхушка айсберга. Основные убытки носят операционный и репутационный характер.

Формальный подход (риски)	Системный подход (результат)	Последствия для аудита и инцидентов
Отсутствие сквозного неизменного ID пользователя	Сквозной идентификатор на всём жизненном цикле	Невозможность построить полную цепочку действий пользователя при расследовании; журналы теряют юридическую силу.
Статическая блокировка по числу попыток	Контекстная блокировка с учётом IP, времени, геолокации	Ложные срабатывания, блокировка легитимных пользователей; или пропуск медленной атаки перебора.
Ручная, эпизодическая переаттестация прав	Автоматизированный процесс с уведомлением владельцев ресурсов	Накопление «мёртвых» и избыточных прав, расширение поверхности атаки; формальный отчёт не отражает реальное положение дел.
Журналы без связи события с субъектом и методом	Полный контекст (кто, когда, как, с какого устройства)	Невозможность доказать в суде, кто совершил действие; бесполезность логов для активного мониторинга угроз.

Кроме того, существуют системные риски:

Процедурный паралич. Отказ в аттестации или неудовлетворительные результаты проверки ФСТЭК могут полностью остановить легальную обработку определённых категорий информации, заморозив проекты и сорвав контракты.
Усиление надзора. Для объектов КИИ нарушения в контроле доступа — прямой путь к включению в план для частых и глубоких проверок.
Накопление технического долга. Попытка формального «закрытия» требований (например, внедрение МФА только на вход в портал) создаёт уязвимости в смежных компонентах (API, бэкенд-сервисы), увеличивая общую поверхность атаки и стоимость последующего исправления.

Итог: от технической функции к управленческому процессу

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