Ошибки на этапе идентификации — почему доступ получает не тот субъект

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

Где обычно появляется ошибка

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

Неудачный выбор идентификатора

Нельзя строить идентификацию на атрибутах, которые не гарантируют уникальность и стабильность. Имя, номер телефона, должность, табельный номер в локальной базе без синхронизации — все это может повторяться или меняться. Опасна и ситуация, когда email используется как первичный идентификатор, а затем меняется домен или формат адресов. Тогда учетная запись становится «плавающей»: доступ привязан к значению, которое больше не является постоянным.

Нормализация, регистр и похожие символы

Даже при хорошем идентификаторе можно получить дубли из-за неявных преобразований. Отдельный класс проблем — смешение алфавитов и визуально похожих символов. Латинская «a» и кириллическая «а» выглядят одинаково, но это разные коды. Если система не фиксирует допустимый набор символов, можно создать учетную запись-двойник и обойти часть проверок, которые рассчитаны на простое сравнение строк.

Сопоставление при SSO и федерации

При подключении SSO добавляются токены и атрибуты. Ошибка — использовать разные атрибуты как ключ идентификации в разных приложениях. В одном месте берется email, в другом — значение subject, в третьем — произвольный claim. При смене почты пользователь внезапно получает новую «личность» в одной системе, а в другой остается прежняя. Иногда это приводит к тому, что новый сотрудник получает доступ к данным предыдущего владельца адреса.

Локальные аккаунты и забытые учетные записи

Если приложение допускает локальные учетные записи параллельно доменным, появляются дубли. Для администратора «Иванов» в каталоге и «ivanov» в приложении могут выглядеть как один человек, но это два разных субъекта. Самый рискованный вариант — старый локальный аккаунт с расширенными правами, который остался после пилота, миграции или временной поддержки подрядчика.

Что проверить, чтобы дефекты проявились на тестах

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

• как обрабатываются регистр, пробелы и кодировки во всех компонентах цепочки

• что происходит при отсутствии пользователя, при двух совпадениях и при недоступности каталога

• можно ли подменить источник идентификатора (заголовки, параметры, поля формы, прокси)

• какие значения попадают в логи: введенный идентификатор, внутренний ID, источник входа

• как ведут себя сервисные аккаунты: есть ли разделение по задачам и понятная трассировка

Журналирование и реакция на ошибки

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

Отдельно про сервисы и API

Для интеграций часто используется ключ API, client_id или сертификат. Ошибка — переиспользовать один идентификатор на несколько систем «для удобства». В логах теряется источник действий, а при компрометации приходится отключать сразу весь контур. Лучше держать отдельный идентификатор на каждую интеграцию, фиксировать владельца, срок актуальности и перечень разрешенных операций.

В процессе создания статьи частично задействованы материалы с сайта blog.infra-tech.ru — ошибки на этапе идентификации

Дата публикации: 27 июня 2022 года