Идентификация – это шаг, на котором система определяет, кто именно обращается к ресурсу. На этом этапе еще не подтверждается, что человек или сервис действительно тот, за кого себя выдает. Система связывает запрос с конкретным идентификатором и подготавливает контекст: какую учетную запись искать, какие политики применить, какие события записать.
Зачем нужна идентификация
Без корректной идентификации невозможно построить управление доступом и аудит. Если субъект определен неоднозначно, далее легко получить путаницу в правах, ошибочную выдачу токенов, смешение событий в логах. Это особенно заметно там, где один пользователь работает с несколькими приложениями, а сервисы обращаются друг к другу по API.
Какие данные используют для идентификации
Идентификация опирается на данные, которые должны быть уникальными и стабильными в пределах домена. Важно, чтобы идентификатор не пересекался с другими учетными записями и не менялся без контролируемой процедуры. Типовые варианты:
-
логин или UPN, связанный с записью в каталоге
-
внутренний ID пользователя в приложении и его сопоставление с каталогом
-
идентификатор устройства или сертификата для сервисов и машинных аккаунтов
-
идентификатор клиента в OAuth2 или ключ API для интеграций
-
связка атрибутов, если единого ID нет, но это рискованный вариант
Где этап идентификации ломается
Проблемы обычно начинаются при интеграции. Одно приложение принимает логин как email, другое – как короткое имя, третье хранит локальные учетные записи. Если нет правила сопоставления, идентификация становится непредсказуемой. Еще одна ошибка – доверие данным из внешнего запроса без проверки источника: заголовки, параметры, поля формы. Система может принять подставной идентификатор и перейти к неверному контексту проверки.
Нормализация и уникальность
Для единообразия вводится правило нормализации. Например, логин приводится к нижнему регистру, запрещаются пробелы по краям, задается допустимый набор символов. Отдельно решается вопрос с похожими символами: латинская a и кириллическая а выглядят одинаково, но в строке это разные коды. Если правило не закреплено, появляются дубли и обход ограничений.
Жизненный цикл учетной записи
Идентификатор существует дольше, чем пароль. Люди меняют фамилию, отдел, домен, формат почты. При проектировании выбирается такой идентификатор, который не придется часто менять. Если смена неизбежна, нужна процедура миграции: сохранение связи старого и нового значения, перенос прав, обновление связей в приложениях, корректная запись в журналах.
Связь с журналированием
Журналы полезно вести в двух видах: вводимый идентификатор и внутренний стабильный ID, который используется в базе. Тогда при расследовании можно искать цепочку событий даже после переименований. Также стоит фиксировать источник идентификации: форма, SSO, API, сертификат. Это помогает быстро понять, где возник сбой.
Как проверить качество идентификации
Практическая проверка начинается с перечня всех точек входа: веб-форма, SSO, API, интеграционные очереди. Для каждой точки фиксируется, какой идентификатор принимается, где он нормализуется, как ищется учетная запись, что пишется в лог. Далее проверяются крайние случаи: регистр, пробелы, кодировки, пустые значения. Если идентификация неустойчива, дефект обычно проявляется именно на таких сценариях.
Идентификация сервисов и автоматизации
Внутрисистемные вызовы выполняют сервисные учетные записи. Для них важно запретить общий идентификатор на несколько процессов, иначе теряется трассируемость действий. Практично привязывать сервисный идентификатор к конкретной задаче и владельцу, ограничивать права по принципу минимальной достаточности, а секреты хранить и ротировать централизованно.
Поведение при ошибках
Нужно заранее определить, что делает система, если идентификатор не найден, найдено несколько совпадений или внешний каталог недоступен. Нормальная реакция – явный отказ и запись события, а не переход в “гостевой” режим по умолчанию. Для интеграций полезно возвращать однозначные коды ошибок, чтобы администратор видел причину и точку отказа.
Практическая рекомендация
Если в инфраструктуре уже есть каталог, его удобно назначить источником истины для идентификаторов, а в приложениях хранить сопоставление с внутренним ID. Тогда идентификация становится единообразной и проще контролируется при росте числа систем.
В процессе создания статьи частично задействованы материалы с сайта blog.infra-tech.ru – идентификация в информационных системах
Дата публикации: 27 июня 2022 года
