Что такое идентификация и аутентификация

Логин бывшего сотрудника остался активным, пароль вовремя не обновили — посторонний получил доступ к CRM.  Фишинговое письмо «увело» код из SMS — баланс интернет-банка опустел. Пароль «Qwerty123» вскрыли за считанные минуты — внутренняя переписка с клиентами попала в руки злоумышленников.

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

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

Мы так привыкли к «входу в систему», что не замечаем, сколько раз за день проходим проверку: когда открываем смартфон по лицу, заходим в интернет-банк или подключаемся к рабочему VPN. Эти действия кажутся простыми, но за ними стоят сложные процессы, от которых зависит безопасность

Роль идентификации и аутентификации в защите ИТ-инфраструктур и личных данных

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

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

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

Различия в терминологии

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

• Идентификация — человек сообщает, кто он. Например: вводит логин, номер телефона, СНИЛС или прикладывает пропуск.
• Аутентификация — система проверяет: действительно ли перед ней тот, за кого он себя выдал. Это может быть пароль, отпечаток пальца, код из SMS или электронная подпись.
• Авторизация — проверка прав. То есть: что именно может делать этот человек после входа. Например, сотрудник техподдержки не должен видеть зарплаты отдела кадров, даже если он успешно вошёл в систему.

Еще проще:

1. Человек приходит на проходную, предъявляет документ — идентификация.
2. Система проверяет, если ли в базе его данные — аутентификация.
3. Охрана решает, разрешить ему пройти в бухгалтерию или только в курилку — авторизация.

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

Что такое идентификация?

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

Разберёмся, как работает идентификация, какие данные используются в этой роли и почему ошибки на этом этапе часто ведут к серьёзным инцидентам.

Как пользователь «заявляет» свою личность

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

• логин или email;
• номер телефона;
• СНИЛС или ИНН в государственных сервисах;
• ID из каталога пользователей (например, в Active Directory);
• карточка или метка (в СКУД, транспорте, на проходных).

Примеры идентификации

• Вы набираете номер квартиры в домофоне и называете себя.
• Вставляете банковскую карту в терминал — система «видит» клиента.
• Прикладываете пропуск к турникету, чтобы система «увидела» ваши данные.

На этом этапе ещё никто ничего не проверяет. Система просто связывает человека с конкретным идентификатором.

Какие ошибки можно допустить при идентификации

Если идентификация построена неграмотно, система примет за «настоящего» кого угодно. Вот типичные ошибки, которые допускаются в системах доступа:

1. Одинаковые или неуникальные логины.
   Если в системе могут быть несколько «admin» или «user», она не сможет однозначно определить, кто перед ней. Это дыра в контроле.
2. Фиктивные учётные записи.
   Иногда в спешке заводят «временных пользователей» с логинами вроде test, temp, guest. Такие записи легко угадать и использовать в атаках.
3. Идентификаторы, зависящие от внешних данных.
   Например, логин, совпадающий с e‑mail или ФИО, может быть легко найден через соцсети или корпоративные сайты. Это упрощает подбор и атаку.
4. Повторное использование идентификаторов.
   Когда бывшему сотруднику выдают тот же логин, что был у другого, остаётся риск спутать действия в журналах или дать лишние права.

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

Когда человек назвал себя, система должна проверить: действительно ли это он. Это и есть аутентификация. В отличие от идентификации на этом этапе понадобятся доказательства: знание пароля, код из SMS, биометрические данные — что-то, что сложнее, чем просто назвать логин. От надёжности этой проверки зависит, кого мы пускаем внутрь: владельца учётной записи или постороннего, который просто угадал.

Как система проверяет, кто ты есть

Аутентификация работает как фильтр. Человек что-то сообщает — система сверяет это с тем, что знает заранее. Если совпало, пускает. Если нет — отказывает.

Самые распространённые способы:

1. Пароль. Классика. Пользователь вводит строку, которую знает только он. Если совпадает с хэшем в базе — вход разрешён.
2. Одноразовый код (OTP). Генерируется каждый раз заново, действует ограниченное время. Может приходить по SMS, на email или через приложение.
3. Биометрия. Использует физические характеристики — отпечаток пальца, лицо, голос, сетчатку.

Каждый метод по-своему удобен и уязвим. Главное — подобрать способ  аутентификации под уровень риска. Где-то хватит пароля, а где-то нужен токен, который нельзя перехватить или угадать.

Базовые методы аутентификации

Однофакторная

Когда используется только один признак — например, пароль. Встречается чаще всего: быстро, просто, привычно. Но и самый уязвимый — если он украден или подобран, система не отличит злоумышленника от настоящего пользователя.

Аутентификация по OTP

Более надёжный подход. Система высылает временный код, который нужно ввести дополнительно. Даже если злоумышленник знает логин и пароль, без кода он не войдёт. Минус — можно перехватить, подменить, выманить через фишинг.

Биометрическая

Работает с тем, что у пользователя «встроено», что невозможно подделать или подобрать: лицо, палец, радужка глаза. Удобно, быстро, но требует оборудования. Не всегда подходит для удалённых или критичных систем — биометрию сложно отозвать, если она утекла.

Каждый метод можно использовать отдельно или в комбинации — так появляется многофакторная аутентификация, о которой ниже.

Акцент на факторах

Все методы аутентификации опираются на три типа факторов:

1. Знание. Что-то, что знает только пользователь. Например: пароль, PIN-код, кодовое слово.
2. Владение. Что-то, что есть только у пользователя. Телефон, смарт-карта, токен, физический ключ.
3. Признак личности. Биометрия — отпечаток, лицо, голос.

Если используется только один фактор — это уязвимо. Подбор, утечка, подделка — всё это работает против нас. Чем больше факторов задействовано — тем сложнее пройти проверку под чужим именем.

Аутентификация по двум и более факторам — уже давно необходимый стандарт для большинства бизнес-систем. Особенно если вопрос касается денег, персональных данных или корпоративных ресурсов.

Где мы проходим проверку личности и как она устроена

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

Интернет-банки:

• Идентификация: логин, номер карты или номер телефона.
• Аутентификация: постоянный пароль + одноразовый код из SMS, Push‑уведомление или биометрия (в мобильном приложении).
• Риски: фишинг (перехват логина и пароля), подмена SIM‑карты, вирусы, крадущие коды или перехватывающие Push.

Эта схема защиты становится всё сложнее: банки добавляют геолокацию, поведенческий анализ, ограничения по устройствам. Но всё упирается в слабые места — если человек доверчив, а система не отслеживает аномалии, защита ломается.

ЕСИА (госуслуги):

• Идентификация: СНИЛС, email или телефон.
• Аутентификация: комбинация пароля и одноразового кода, подтверждение через приложение «Госключ» или квалифицированная ЭП.
• Особенность: ЕСИА выступает как единая точка входа (SSO) — через неё можно авторизоваться в других госресурсах.

Система охватывает десятки миллионов пользователей, поэтому использует комбинацию методов. Главное требование — однозначно подтвердить личность. Для этого привязываются документ, телефон, даже визит в МФЦ. Ошибки в цепочке могут привести к компрометации профиля.

Домофон / СКУД:

• Идентификация: номер квартиры, идентификатор карты, брелка, NFC‑метки.
• Аутентификация: как правило, просто наличие устройства. Кто приложил ключ — тот и вошёл.
• Уязвимости: копирование RFID‑меток, продажа дублей, использование универсальных домофонных кодов.

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

Корпоративные сети:

• Идентификация: логин в Active Directory или другой LDAP‑каталог.
• Аутентификация: Kerberos‑токены, пароли, интеграция с 2FA, push‑коды, аппаратные ключи.
• Проблемы: фиктивные учётки, унаследованные аккаунты, «временные» доступы, забытые права бывших сотрудников.

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

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

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

Разберём, что требует государство, к чему приводит халатность и как простой шаг — добавление второго фактора — резко снижает риски.

Формальная обязательность идентификации и аутентификации

Это прямо прописано в нескольких нормативных актах:

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

Риски слабой аутентификации

Системы, где аутентификация настроена по принципу «лишь бы пускало» — первые жертвы атак. Типичные последствия:

• Утечка данных.
  Один пароль от почты или CRM — и вся переписка, заказы, контакты утекают наружу. Чаще всего атакующий использует скомпрометированные учётки или брутфорсит слабые пароли.
• Кража аккаунтов.
  Если клиент или сотрудник использует одну и ту же комбинацию в разных сервисах — утечка в одном месте открывает вход в другие. Особенно опасно в для админов, бухгалтерии, ИТ-отдела.
• Фишинг.
  Злоумышленники подделывают сайты или письма, чтобы выманить данные. Если система не проверяет устройство, географию или не требует подтверждения входа — подделка легко проходит.
• Подмена действий.
  Кто-то вошёл под учёткой начальника отдела — подписал документы, отправил письма, получил доступ к архиву. Если аутентификация была слабой, доказать подделку сложно.

Каждый такой случай — не просто сбой, а инцидент ИБ, требует расследования, реагирования, возможно уведомления регуляторов.

Как факторность снижает опасность

Самый простой и эффективный способ защитить доступ — использовать не один, а два и более факторов аутентификации. Это называется многофакторная аутентификация (MFA) — мы подробно рассказали о ней в нашем материале.

Факторы могут быть разными:

• знание (кодовое слово, PIN)
• владение (телефон, токен, пропуск)
• биометрия (отпечаток, лицо, голос).

Если один фактор скомпрометирован — например, пароль угадан — второй спасает инфраструктуру. Даже простая проверка по коду из приложения или SMS резко снижает риск входа злоумышленника.

По статистике Microsoft, внедрение MFA снижает вероятность компрометации учётки на 99% по сравнению с однофакторным доступом.

MFA — это не замена контроля, а его усиление. Он не требует сложных решений: начать можно с push-уведомлений в телефоне или генератора кода. Даже такой шаг закрывает десятки типовых сценариев атак.

Лучшие практики для российского бизнеса

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

Эти меры работают и в малом бизнесе, и в больших корпоративных структурах. Рассмотрим, какие практики можно применять в российских условиях уже сейчас.

Внедрение MFA: СМС, TOTP‑приложения

Начните с самого доступного — многофакторной аутентификации.

Варианты:

• Код из SMS. Простой и понятный большинству. Подходит, если нет высокой критичности.
• Приложения‑генераторы кода (TOTP). Например, TOTP‑приложения: от «Рутокена», «ИнфоТеКС», российских вендоров, а также open source‑решения, если проект не попадает под ограничения по импортозамещению.
• Push-уведомления. Удобны, но требуют интеграции и доверенного приложения.

Для бизнеса важно: не ограничиваться только SMS. Это устаревший, уязвимый канал. Лучше сразу рассматривать TOTP или push, особенно для доступа к внутренней инфраструктуре.

Даже простая настройка MFA — шаг вперёд. Это несложная и быстро внедряемая мера, которая спасает от большинства массовых атак.

Биометрия: FaceID, TouchID с привязкой к локальным регуляциям

Биометрическая аутентификация кажется удобной — палец приложил, вошёл. Но в корпоративной практике она требует внимательного подхода.

Что стоит учесть:

• Биометрия — это фактор, который нельзя поменять. Если отпечаток утёк, его не заменить, поэтому биометрия должна использоваться не как единственный фактор, а как дополнительный.
• FaceID, TouchID в смартфонах можно использовать как часть MFA через приложения, которые аутентифицируют пользователя локально перед генерацией кода или отправкой push.
• В России биометрия — чувствительная тема. Закон № 572‑ФЗ, № 152‑ФЗ, локальные акты требуют отдельного согласия, ограничивают хранение и передачу биометрических данных.

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

Важно учитывать правовые ограничения: в России действует закон № 572‑ФЗ, регулирующий обращение с биометрическими персональными данными. Он требует получения согласия, запрещает передачу данных в иностранные ИТ‑сервисы и допускает хранение только в государственной биометрической системе (ГИС ЕБС) или в строго контролируемых условиях.

Поэтому если биометрия используется, она должна быть локальной и не покидать устройство. Пример: TouchID используется только для разблокировки TOTP‑приложения, не передаёт данные и не нарушает закон.

Реализация на базе IAM‑решений

IAM (управление идентификацией и доступом) — это класс систем, которые контролируют, кто и куда может входить в ИТ‑инфраструктуре. Такие решения управляют учётными записями, правами пользователей, многофакторной аутентификацией и журналами входов.

Когда пользователей становится много, а доступ сложным, нужно централизовать управление. В российских реалиях можно опираться на отечественные системы:

• Открытая платформа, ее используют в компаниях и госсекторе. Доступны русскоязычные сборки, поддержка LDAP, интеграция с MFA и журналами. Используется как ядро IAM.
• Security Vision IAM, R‑Vision Identity, Цифра Отечественные сервисы, сертифицированные для работы в организациях с КИИ и персональными данными. Поддерживают SSO, управление жизненным циклом учёток, контроль доступа.
• Яндекс ID. Подходит для сервисов, работающих с клиентами: быстрый вход, подтверждение операций, логирование действий.
• ЕСИА. Единый механизм входа в государственные и связанные с ними инфосистемы. Требует авторизации по СНИЛС, электронной подписи, подтверждённых данных.

Выбор зависит от специфики: в коммерческой ИТ‑среде — Keycloak или R‑Vision, в госсекторе — ЕСИА, в клиентских системах — Яндекс ID, в инфраструктуре с повышенными требованиями — сертифицированные решения от российских вендоров.

Часто встречающиеся вопросы

В чём разница между идентификацией, аутентификацией и авторизацией?

Это три разных этапа, которые часто путают. Если упростить:

• Идентификация — «Я Петя» (пользователь называет себя).
• Аутентификация — «Вот доказательство, что я — Петя» (пароль, код, биометрия).
• Авторизация — «Можно ли Пете смотреть зарплаты или только свои отчёты?» (определение прав доступа).

Что выбрать — OTP или биометрию?

Зависит от задач:

• OTP (одноразовые коды) — удобно, просто, работает везде. Хорошо защищает от массовых атак, но может быть перехвачен или выманен.
• Биометрия — быстро и современно, но требует устройств, настроек и вызывает вопросы у регуляторов.

В идеале — использовать оба метода как части MFA: биометрия для подтверждения входа в приложение, OTP — для транзакций или чувствительных операций. Если выбираете между ними в контексте бизнеса — начните с OTP. Их проще внедрить и легче масштабировать.

Почему нельзя заменить пароль одним фактором?

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

Когда факторов два, атака становится сложнее в разы. Даже если злоумышленник знает логин и пароль, ему всё равно придётся получить код или пройти проверку по биометрии. Это уже другой уровень атаки и совсем другой уровень риска для бизнеса.

Как проверить уровень защищённости своей системы?

Начните с простого чек‑листа:

• Есть ли у всех пользователей уникальные логины?
• Применяется ли многофакторная аутентификация (MFA)?
• Записываются ли события входа и доступа в логи?
• Есть ли контроль за временными и внешними пользователями?
• Отключаются ли учётные записи уволенных сотрудников?
• Есть ли защита от перебора паролей (брутфорс)?
• Используются ли пароли из надёжных политик (длина, сложность, срок жизни)?

Если на три и более вопросов ответ — «нет» или «не уверен», значит, системе нужна донастройка. Можно начать с самого базового: ограничить вход по слабым паролям и подключить MFA хотя бы к критичным системам.

Главное

Идентификация — это когда пользователь сообщает системе, кто он.
Пример: логин, номер телефона, СНИЛС. Без уникального идентификатора система не сможет отличить одного пользователя от другого.

Аутентификация — проверка личности: действительно ли это тот, за кого себя выдают.
Сюда относятся пароли, коды, биометрия. Чем слабее проверка — тем выше риск компрометации.

Авторизация — это не вход, а распределение прав после входа.
После успешной аутентификации система решает, к каким данным и действиям допустить пользователя.

Один фактор — мало. Лучше два.
MFA снижает риск взлома в десятки раз. Даже SMS‑код или приложение‑генератор резко повышают безопасность.

Пароль — самый слабый элемент.
Ломается легко, утекает чаще других факторов. Его нельзя считать достаточной защитой.

В каждой системе — свои особенности.
Банки, домофоны, ЕСИА, корпоративные сети — у всех свои способы идентификации и уязвимости. Универсального подхода нет.

Российский бизнес может использовать локальные IAM‑решения.
Keycloak, R‑Vision, Security Vision, Яндекс ID, ЕСИА — это не только соответствие требованиям, но и практичный инструмент для управления доступом.

Слабая аутентификация — это реальная угроза.
Через взлом учётки уходят деньги, данные, контроль. Это один из самых частых сценариев атаки.