Идентификация

Материал проходит ревью.

НовичокФундамент ~38 мин

Границы темы

Scope: как система различает субъекты в своём контексте, когда требуется identity proofing, как создаётся account и как identity меняется со временем.

Не рассматриваем: алгоритмы OCR, face matching, конкретный KYC vendor и детали authentication protocols. Установить identity и доказать контроль authenticator при входе — разные процессы.

Что нужно знать заранее

Нужно понимать, что привилегии выдаются identity, а не строке из request body. «Принцип наименьших привилегий» задаёт требования к будущим правам account.

Результаты обучения

После статьи читатель сможет:

отделить identifier от набора attributes и реального человека;
определить, нужен ли identity proofing конкретной операции;
проследить resolution, validation, verification и enrollment;
выбрать стабильный внутренний identifier;
спроектировать изменения и закрытие account без потери referential integrity.

Основная модель

Идентификация отвечает на вопрос: какую identity система считает отдельным субъектом в данном контексте? Это ещё не доказательство, что текущий actor контролирует эту identity.

NIST SP 800-63-4 разделяет identity proofing, enrollment, authentication и federation. Успешный proofing приводит к subscriber account; authenticator затем привязывается к account и используется в другом процессе — authentication.

Основные термины

Термин	Рабочее определение	Пример
Identifier	Значение, однозначно связанное с entity в заданном контексте	`usr_01J...` внутри сервиса
Attribute	Характеристика identity	Email, возрастная категория, tenant membership
Claimed identity	Ещё не проверенное заявление субъекта о себе	«Я владелец account X»
Identity evidence	Данные или документ в поддержку claimed identity	Документ, подписанное цифровое evidence
Resolution	Выделение одного субъекта среди обслуживаемой популяции	Найти, что applicant не является duplicate
Validation	Проверка подлинности, точности и допустимости evidence/attributes	Подтвердить issuing source и срок действия
Verification	Проверка, что applicant является владельцем evidence	Сопоставление с защищённой процедурой
Enrollment	Создание subscriber account и binding authenticator	Зарегистрировать passkey после proofing

Не каждому сервису нужен proofing реального человека

Степень identification следует из риска операции.

Сервис или операция	Достаточная identity	Почему
Читать публичную документацию	Anonymous session	Нет персонального права или существенного риска
Сохранить настройки темы	Pseudonymous account	Нужна continuity, но не паспортное имя
Работать в корпоративном tenant	Workforce identity от доверенного IdP	Важны employment и membership attributes
Получить регулируемую финансовую услугу	Identity с требуемым assurance	Ошибка связывания создаёт финансовый и regulatory impact
Восстановить критичный account	Ранее установленные recovery bindings	Новый proofing может потребоваться по risk policy

End-to-end сценарий

Рассмотрим B2B-сервис, где приглашённый сотрудник получает доступ к tenant.

Здесь есть несколько identifiers:

email используется как адрес доставки и заявленный matching attribute;
invitation ID однозначно обозначает приглашение;
IdP subject ID стабильно обозначает identity у provider;
внутренний user ID обозначает account внутри backend;
tenant membership — отдельная связь, а не свойство email.

Что происходит под капотом

Внутренний identifier

Хороший primary identifier:

стабилен при смене имени, email и login method;
уникален в явно заданном namespace;
не переиспользуется для другого субъекта;
не содержит лишних PII;
не даёт внешнему клиенту права только потому, что его можно угадать.

UUID/ULID может решить uniqueness и opacity, но authorization всё равно обязана проверять resource и tenant.

External identity binding

Не связывайте federation account только по email. Практичная связь содержит:

text

issuer + subject -> internal_user_id

subject уникален в namespace конкретного issuer. Одинаковая строка subject от другого issuer не обязана обозначать того же человека.

Account не равен человеку

Один человек может иметь несколько accounts, а service account вообще не является человеком. Модель должна явно отвечать:

допускаются ли несколько accounts на субъекта;
можно ли связать identities разных providers;
кто подтверждает merge и как его откатить;
что происходит с history после закрытия account;
какие records обязаны сохраняться по бизнес- или legal policy.

Минимальный воспроизводимый пример

Спроектируйте identity record без использования email как primary key:

yaml

user_id: usr_01K0Y6M8N4
status: active
display_name: Анна
contacts:
  - type: email
    value: anna@example.com
    verified_at: 2026-07-31T10:00:00Z
external_identities:
  - issuer: https://idp.example.com
    subject: 00u7abc123
authenticators:
  - id: authn_01K0Y7
    type: passkey
    added_at: 2026-07-31T10:03:00Z
memberships:
  - tenant_id: tenant_42
    status: active
retention:
  contact_delete_after: null

Ожидаемый результат

Смена email не меняет user_id и ссылки заказов.
Federation binding использует пару issuer/subject.
Tenant membership можно отозвать, не удаляя всю identity.
Authenticator имеет собственный lifecycle.
PII отделены от стабильного ключа и могут иметь retention policy.

Проверки жизненного цикла

Событие	Ожидаемое поведение
Пользователь меняет email	Новый контакт подтверждается; `user_id` неизменен
IdP повторно выдаёт тот же email другому subject	Автоматического merge нет
Удалено tenant membership	Нет доступа к tenant, но account может существовать
Потерян authenticator	Recovery не меняет identity без отдельного основания
Account закрыт	Login запрещён; retention и anonymization выполняются по policy

Enumeration и privacy

Identification endpoints часто раскрывают существование account:

text

"Пользователь найден" vs "Такого email нет"

Для recovery и регистрации выбирайте response по threat model:

одинаковая внешняя формулировка и близкий timing снижают enumeration;
внутренний audit всё равно различает причины;
rate limit ограничивает массовый перебор;
support flow не должен раскрывать attributes до достаточной проверки;
masking не превращает PII в нечувствительные данные.

Полностью одинаковый timing трудно гарантировать, поэтому защита должна быть эшелонированной, а не опираться на одну строку ответа.

Trade-offs

Решение	Выигрыш	Цена или риск
Pseudonymous account	Меньше PII и friction	Ниже уверенность в real-world identity
Строгий proofing	Выше identity assurance	Ошибки отказа, стоимость, accessibility и privacy impact
Email как login alias	Удобно пользователю	Изменяемость, enumeration, account recovery risk
Несколько external identities	Resilience и удобство	Риск ошибочного linking/merge
Stable opaque ID	Независимость от attributes	Нужны отдельные индексы поиска и mapping

Failure modes и типичные ошибки

Email как primary key. Смена контакта ломает связи и audit.
Identification равна authentication. Найденный account не доказывает контроль actor над authenticator.
Proofing везде. Сервис собирает sensitive evidence без необходимости.
Автоматический merge по email. Разные issuers и повторное использование адреса связывают чужие accounts.
Identifiers как authorization. Непредсказуемый ID не заменяет permission check.
Нет lifecycle. Rename, duplicate, merge, recovery и deletion решаются вручную и непоследовательно.
Account deletion стирает audit без модели. Referential и regulatory требования конфликтуют с privacy, если не спроектированы заранее.

Практическое задание

Задача: нарисуйте identity lifecycle для одного продукта.

Укажите:

population и namespace identifiers;
нужен ли real-world proofing и почему;
claimed, validated и derived attributes;
внутренний ID и external bindings;
enrollment authenticators;
rename, duplicate, merge, recovery и deletion;
PII retention и enumeration controls.

Критерии готовности: ни один изменяемый attribute не используется как вечный primary key; linking имеет проверяемое основание и rollback; объём proofing соразмерен риску.

Подсказка

Проверьте модель на двух людях с одинаковым именем, смене email, повторном использовании номера телефона и двух IdP с одинаковым subject.

Проверка знаний

01Почему email не следует использовать как вечный primary key пользователя?

Он может измениться, повторно использоваться и раскрывает attributeВ email нет символа @Email автоматически является сильным authenticator

02Какие действия относятся к identity proofing?

Различить заявителя в целевой популяцииПроверить подлинность evidence и точность attributesСвязать evidence с заявителемПроверить пароль при каждом входе

03Любой пользовательский аккаунт обязан быть связан с паспортной личностью.

ВерноНеверно

04Восстановите упрощённый путь identity proofing и enrollment.

Создать subscriber account и привязать authenticator
Получить заявленную identity и attributes
Проверить принадлежность evidence заявителю
Проверить evidence и attributes

Самопроверка

Чем identifier отличается от attribute?
Почему proofing и authentication разделены?
Когда pseudonymous account лучше verified legal identity?
Почему issuer + subject надёжнее одного email для federation binding?

Ответы и критерии

Identifier однозначно обозначает entity в контексте; attribute описывает её и может меняться или совпадать у нескольких entities.
Proofing устанавливает связь claimed identity с субъектом при enrollment; authentication позже доказывает контроль bound authenticator.
Когда сервису нужна continuity, но real-world identity не требуется для управления риском; это уменьшает сбор PII и friction.
Subject определён в namespace issuer, тогда как email изменяем, может быть переиспользован и не доказывает одну identity между providers.

Краткое резюме

Identification определяет, какую identity различает система.
Реальный человек, account, identifier, attribute и authenticator — разные сущности.
Proofing состоит из resolution, validation и verification и нужен не всегда.
Внутренний ID должен быть стабильным и не содержать лишних PII.
Identity требует полного lifecycle, а не только формы регистрации.

Следующие шаги

Статья «Аутентификация и авторизация» продолжает путь: как actor доказывает контроль identity и как backend принимает решение о конкретном действии.

Источники

NIST SP 800-63-4 — модель digital identity, роли, subscriber accounts и разделение proofing, authentication и federation.
NIST SP 800-63A-4 — финальные требования к identity proofing и enrollment.
NIST SP 800-63A-4: Identity Proofing Overview — resolution, validation, verification и свойства identity evidence.

Идентификация ​

Границы темы ​

Что нужно знать заранее ​

Результаты обучения ​

Основная модель ​

Основные термины ​

Не каждому сервису нужен proofing реального человека ​

End-to-end сценарий ​

Что происходит под капотом ​

Внутренний identifier ​

External identity binding ​

Account не равен человеку ​

Минимальный воспроизводимый пример ​

Ожидаемый результат ​

Проверки жизненного цикла ​

Enumeration и privacy ​

Trade-offs ​

Failure modes и типичные ошибки ​

Практическое задание ​

Проверка знаний ​

Самопроверка ​

Краткое резюме ​

Следующие шаги ​

Источники ​