Технологии и стандарты

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

Путаница между ними дороже, чем кажется. Размытые границы в терминологии ведут к размытым границам в архитектуре, а это уже уязвимости. По классификации OWASP Top 10, нарушение контроля доступа (Broken Access Control) занимает первое место среди угроз для веб-приложений.

Разберём каждый из терминов с примерами.

Главное

• Идентификация, аутентификация и авторизация — три независимых процесса, каждый из которых решает свою задачу.
• Идентификация устанавливает личность («Кто ты?») — логин, имейл, номер телефона. Это не секрет и не даёт никаких гарантий безопасности.
• Аутентификация верифицирует подлинность («Докажи, что это ты») через факторы: знание (пароль), владение (токен) или свойство (биометрия).
• Авторизация определяет права доступа («Что тебе разрешено?») после успешной аутентификации. RBAC назначает права через роли, ABAC — через атрибуты и контекст запроса (время, IP, устройство).
• Ключи доступа (Passkeys) — главный тренд 2025–2026 годов. Беспарольная аутентификация на базе FIDO2/WebAuthn устраняет фишинг, утечки с серверов и человеческий фактор. Приватный ключ не покидает устройство, вход подтверждается биометрией.
• Zero Trust отменяет концепцию доверенного периметра. Каждый запрос проходит верификацию независимо от источника. Непрерывная проверка, минимум привилегий и контекстная оценка риска — основа архитектуры нулевого доверия.

Идентификация, аутентификация, авторизация

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

Шаг 1. Идентификация: «Кто ты?»

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

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

Шаг 2. Аутентификация: «Докажи, что это ты»

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

Классификация факторов аутентификации:

• Знание (knowledge) — секрет, известный только пользователю: пароль, ПИН-код, ответ на контрольный вопрос.
• Владение (possession) — физический или цифровой объект, которым располагает пользователь: TOTP-приложение, аппаратный токен, SIM-карта для SMS-кода.
• Свойство (inherence) — биометрические характеристики: отпечаток пальца, геометрия лица (Face ID), сетчатка глаза.

Использование нескольких факторов одновременно — основа двухфакторной (2FA) и многофакторной аутентификации (MFA). Компрометация одного фактора не даёт злоумышленнику доступа, пока остальные не скомпрометированы.

Шаг 3. Авторизация: «Что тебе разрешено?»

Авторизация — процесс определения и применения прав доступа: что именно аутентифицированный пользователь может читать, изменять или выполнять в системе.

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

В чём главная разница?

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

Виды аутентификации: от паролей до биометрии

Однофакторная аутентификация (1FA)

Метод проверки личности, при котором пользователь подтверждает доступ единственным способом — как правило, паролем.

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

Двухфакторная аутентификация (2FA)

Метод, при котором доступ требует двух независимых факторов из разных категорий: например, пароля и одноразового кода с устройства.

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

Многофакторная аутентификация (MFA)

Метод, объединяющий три и более факторов из разных категорий: знание (пароль), владение (устройство) и биометрию (отпечаток пальца, лицо).

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

Методы второго фактора — от слабого к надёжному:

• SMS-коды — самый распространённый и наименее надёжный метод. Одноразовый код передаётся через сотовую сеть, которая уязвима к SIM-свопингу (злоумышленник переоформляет номер на свою SIM-карту) и SS7-атакам (перехват трафика на уровне протокола сигнализации). Допустим как временное решение или для низкорисковых сценариев. Для критичных систем — неприемлем.
• Email OTP — одноразовый код отправляется на почту. По надёжности сопоставим с SMS: безопасность фактора целиком зависит от защищённости почтового ящика. Если почта скомпрометирована, второй фактор не работает.
• Push-уведомления — запрос подтверждения поступает на зарегистрированное доверенное устройство. Пользователь видит контекст запроса: время, геолокацию, устройство инициатора. Это позволяет распознать подозрительный запрос и отклонить его. Уязвимость — усталость: злоумышленник отправляет серию запросов подряд в расчёте на то, что пользователь подтвердит один из них машинально.
• TOTP-приложения — генерируют одноразовые коды локально на устройстве. Код действителен 30 секунд и не передаётся через сеть при генерации. Не зависят от сотовой связи, устойчивы к SIM-свопингу и SS7-атакам. Уязвимость остаётся одна: код можно перехватить в реальном времени через фишинговый сайт-прокси, если пользователь не проверяет домен.
• Биометрия — отпечаток пальца, распознавание лица. Используется преимущественно как локальный фактор на устройстве — верификация происходит на стороне устройства, данные не передаются по сети. Надёжность ограничена качеством реализации на конкретной платформе.
• Ключи доступа (Passkey, FIDO2 без аппаратного токена) — криптографические ключи хранятся в защищённом хранилище устройства: TPM или Secure Enclave. Работает по той же логике, что и аппаратный FIDO2-ключ, но без отдельного физического токена. Устойчив к фишингу за счёт привязки к домену, поддерживается всеми современными платформами.
• Аппаратные FIDO2-ключи — физические устройства с криптографическим подтверждением на борту. Удалённая компрометация технически невозможна — злоумышленнику нужен физический доступ к устройству. Считаются эталоном надёжности второго фактора.

Тренд 2025 года: беспарольная аутентификация и ключи доступа (Passkeys)

Ключи доступа (Passkeys) — криптографический стандарт аутентификации на базе FIDO2/WebAuthn, при котором пароль полностью заменяется парой асимметричных ключей, а личность пользователя подтверждается биометрией устройства.

Главный структурный сдвиг в аутентификации — переход к полностью беспарольным схемам. Технология Passkeys на базе стандарта FIDO2/WebAuthn позволяет аутентифицироваться с помощью биометрии устройства без ввода пароля.

Механизм: при регистрации генерируется асимметричная криптографическая пара ключей. Приватный ключ хранится в защищённом анклаве устройства (Secure Enclave на Apple, TPM на Windows) и никогда не покидает его. Публичный ключ передаётся на сервер. При входе сервер отправляет запрос, устройство подписывает его приватным ключом после биометрического подтверждения пользователя.

Принципиальные преимущества перед паролями:

• Фишингоустойчивость — ключ привязан к конкретному домену и не сработает на поддельном сайте.
• Нечего красть с сервера — публичный ключ бесполезен без приватного.
• Нет человеческого фактора — пользователь не может создать слабый ключ или использовать его повторно.

Apple, Google и Microsoft внедрили поддержку Passkeys в свои платформы. Почти все крупные сервисы уже предлагают вход через ключи доступа в качестве основного метода.

Как работает авторизация в ИТ-системах

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

Ролевая модель (RBAC)

Ролевая модель (Role-Based Access Control) — наиболее распространённая модель в корпоративных системах. Права назначаются не конкретному субъекту, а роли; субъект наследует права через членство в роли. Это упрощает администрирование: изменение прав роли мгновенно распространяется на всех её носителей.

Типовая иерархия ролей:

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

RBAC хорошо масштабируется, но имеет ограничение: роль не учитывает контекст запроса. Для более тонкого управления используют ABAC.

Атрибутная модель (ABAC)

ABAC (Attribute-Based Access Control) — модель управления доступом, в которой решение об авторизации принимается на основе набора атрибутов: характеристик пользователя, ресурса, выполняемого действия и контекста запроса (время, местоположение, устройство).

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

OAuth 2.0 и делегирование авторизации

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

Сценарий «Войти через Google»:

1. Клиентское приложение перенаправляет пользователя на сервер авторизации.
2. Сервер проверяет личность пользователя и запрашивает согласие на передачу конкретных прав доступа.
3. После подтверждения выдаётся токен доступа — временный, ограниченный по правам и сроку действия.
4. Клиентское приложение использует токен для запросов к серверу ресурсов; пароль пользователя в процессе не фигурирует.

SSO (единый вход) в корпоративных средах работает по схожей логике: одна аутентификация через поставщика удостоверений открывает доступ ко всем связанным сервисам. Стандарты SAML 2.0 и JWT обеспечивают безопасную передачу токенов подтверждения между поставщиком удостоверений и поставщиком услуг.

Zero Trust: непрерывная верификация как архитектурный принцип

Концепция Zero Trust («никогда не доверяй, всегда проверяй») отказывается от модели периметровой безопасности, при которой субъект внутри сети считается доверенным по умолчанию. В Zero Trust каждый запрос к ресурсу проходит полный цикл верификации независимо от его источника.

Ключевые принципы:

• Непрерывная верификация — аутентификация и авторизация выполняются не один раз при установке сессии, а при каждом запросе к защищённому ресурсу.
• Минимум привилегий (Least Privilege) — субъект получает ровно те права, которые необходимы для конкретной задачи, на минимально необходимый срок.
• Контекстная оценка — решение об авторизации принимается с учётом устройства, геолокации, времени, поведенческих паттернов и уровня риска запроса.

Zero Trust особенно критичен в условиях распределённых инфраструктур и удалённой работы, где понятие «доверенного периметра» утратило практический смысл.

Ошибки, которые стоят дорого

Тест: идентификация, аутентификация, авторизация

Заключение

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

Практические выводы, которые стоит зафиксировать:

• MFA — минимальный стандарт для критичных систем. SMS-коды допустимы как временное решение, аппаратные FIDO2-ключи — как эталон.
• Принцип наименьших привилегий должен быть встроен в архитектуру, а не настраиваться вручную для каждого пользователя. Права по умолчанию — минимальные, расширение — явное и обоснованное.
• Аутентификация и авторизация — разные слои. Смешивать их логику в одном компоненте — источник IDOR и других уязвимостей контроля доступа.
• Passkeys устраняют целый класс атак — фишинг, утечки с серверов, повторное использование паролей на уровне протокола, а не пользовательской дисциплины.
• Zero Trust — не концепция будущего, а рабочий архитектурный принцип для распределённых инфраструктур. Каждый запрос верифицируется с учётом контекста — независимо от того, откуда он пришёл.

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

Часто задаваемые вопросы

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

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

Что такое двухфакторная аутентификация и почему её нельзя игнорировать?

2FA требует подтверждения личности двумя независимыми факторами из разных категорий: например, паролем (знание) и TOTP-кодом (владение). Компрометация одного фактора не даёт доступа без второго. По данным Microsoft, 2FA блокирует более 99,9% атак с использованием скомпрометированных учётных данных. Для критичных систем рекомендуется MFA с аппаратным токеном в качестве одного из факторов.

Что такое ключи доступа (Passkeys) и чем они архитектурно лучше паролей?

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

Что такое Zero Trust и как он меняет подход к аутентификации и авторизации?

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

Чем SSO отличается от стандартного входа и какие риски он несёт?

SSO (Single Sign-On) позволяет пройти аутентификацию один раз через поставщика удостоверений и получить доступ ко всем связанным сервисам без повторного ввода учётных данных. Это снижает парольную усталость и централизует аутентификацию. Оборотная сторона: компрометация поставщика удостоверений открывает доступ ко всем подключённым системам одновременно. Поэтому SSO-провайдер должен быть защищён MFA и строгими политиками доступа.

11 способов взлома паролей, которые хакеры используют в 2026 году

Больше половины паролей можно подобрать меньше чем за час. Но брутфорс уже не главная угроза. Инфостилеры, AiTM-фишинг, PassGAN и обход MFA — разбираем 11 актуальных методов взлома паролей в 2026 году и даём конкретный чек-лист защиты.

Блог ПассворкаИлья Шелыгин

Кибератаки 2025: статистика, векторы атак и главные уязвимости

Что изменилось в кибератаках за последний год — и почему привычные меры защиты больше не работают? Хакеры больше не крадут данные — они уничтожают инфраструктуру. Разбираем, что изменилось в атаках на российский бизнес в 2025 году и какие меры защиты дают реальный результат.

Блог ПассворкаАнастасия Лебедева

Внедрение менеджера паролей: пошаговое руководство

Сисадмин пересылает SSH-ключи в мессенджере. Уволенный сотрудник до сих пор получает рассылку с данными клиентов. Стажёр с правами администратора. Знакомо? Рассмотрим, как ИТ-отделу взять доступы под контроль — от первого аудита до работающей системы.

Блог ПассворкаАнастасия Лебедева

Компания потратила полгода на внедрение двухфакторной аутентификации. Все сотрудники подключены, ИТ-директор доволен. А через три недели — взлом. Злоумышленник вошёл в корпоративную почту с валидным сессионным токеном: MFA был пройден успешно, легитимно, самим сотрудником — на фишинговой странице, которую тот не распознал.

Многофакторная аутентификация сработала именно так, как должна. Просто атака была направлена не на неё.

За три года в России утекло 4,5 млрд записей персональных данных (в мире — 100 млрд), и масштаб каждого инцидента стабильно растёт. Персональные данные остаются самым распространённым типом данных, обнаруживаемом в утечках — на них приходится около 74% утечек информации. За каждой из этих цифр — скомпрометированный аккаунт, украденный токен или сотрудник, который не распознал фишинг.

Пароль давно перестал быть достаточной защитой — это факт, с которым согласны и регуляторы, и страховщики, и команды реагирования на инциденты. Но и базовый 2FA через SMS-сообщения уже не спасает: современные атаки типа «Злоумышленник посередине» (AiTM) перехватывают сессионные токены прямо в момент аутентификации, обходя любой одноразовый код.

Эта статья — практическое руководство для тех, кто уже понимает, что MFA нужен, и хочет внедрить его правильно: выбрать методы, соответствующие реальным угрозам, выполнить требования ФСТЭК №117 и не сломать рабочие процессы сотрудников.

Главное

• Двухфакторная аутентификация работает — но только если выбран правильный метод. Большинство корпоративных взломов происходят не потому, что второй фактор обошли технически, а потому что использовали метод, уязвимый к фишингу или перехвату сессии.
• SMS-коды устарели. Три независимых вектора атаки — перехват через уязвимости протокола SS7, подмена SIM-карты и фишинг в реальном времени — делают SMS архитектурно ненадёжным вторым фактором.
• TOTP и push-уведомления — переходный вариант, не финальный. Приложения-аутентификаторы лучше SMS, но уязвимы к атакам «злоумышленник посередине»: код перехватывается в реальном времени и действителен достаточно долго для атаки.
• Единственные методы, устойчивые к фишингу на уровне протокола, — аппаратные токены и ключи доступа. Для привилегированных учётных записей — аппаратные токены (Рутокен, JaCarta), для рядовых сотрудников — ключи доступа.
• Резервные процедуры обязательны. Регламент восстановления доступа при утере устройства или компрометации фактора должен быть прописан заранее — с верификацией личности, временным доступом с ограниченными правами и обязательным аудитом.

Что такое 2FA и MFA: в чём разница для бизнеса?

Двухфакторная аутентификация (2FA) — метод проверки личности, при котором пользователь подтверждает вход двумя независимыми способами: как правило, паролем и одноразовым кодом.

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

Три классических фактора аутентификации:

• Знание — то, что пользователь знает: пароль, ПИН-код, секретный вопрос. Знание можно выманить фишингом, подобрать брутфорсом, купить в утечке или перехватить через инфостилер. Именно поэтому пароль в одиночку давно не считается достаточной защитой.
• Владение — то, чем пользователь физически располагает: смартфон с приложением-аутентификатором, аппаратный токен (FIDO2/YubiKey), смарт-карта. Этот фактор существенно сложнее скомпрометировать удалённо.
• Свойство — биометрические характеристики пользователя: отпечаток пальца, распознавание лица, голос. Фактор удобен — его невозможно забыть или потерять. Но у него есть принципиальное ограничение: биометрию нельзя сменить после компрометации. Поэтому биометрия надёжна как дополнительный фактор, но не как единственный.

Современные системы двухфакторной аутентификации всё чаще дополняются SSO (Single Sign-On) и безпарольными методами (Passwordless). Сотрудник проходит строгую аутентификацию один раз — и получает доступ ко всем корпоративным системам без ввода паролей. Это снижает нагрузку на Helpdesk и устраняет главный источник уязвимостей — человека, который придумывает «удобные» пароли.

Почему SMS-коды больше не работают?

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

• Атаки на протокол SS7. SMS передаются через инфраструктуру телефонных сетей — Signaling System 7 (Система сигнализации №7). Уязвимости этого протокола известны с 2014 года, задокументированы исследователями и активно эксплуатируются в целевых атаках. Злоумышленник с доступом к SS7 перехватывает сообщения без физического контакта с устройством жертвы — удалённо, незаметно, без каких-либо следов на стороне пользователя.
• SIM-свопинг. Злоумышленник убеждает оператора связи перевыпустить SIM-карту на своё имя — используя данные из утечек или социальную инженерию. После этого все SMS с кодами приходят атакующему. Российские операторы внедрили уведомления о смене SIM, но это реактивная мера: к моменту, когда жертва получает уведомление, атака уже состоялась.
• Фишинг в реальном времени. Поддельная страница входа запрашивает SMS-код и немедленно передаёт его на настоящий сайт — пока код ещё действителен. Для рядового сотрудника такая страница визуально неотличима от оригинала. Никакой технической защиты от этого сценария у SMS нет: код не привязан к домену, устройству или сессии.

Все три вектора объединяет одно: SMS-код существует в открытой среде, которую пользователь не контролирует. Это архитектурное ограничение протокола.

Как хакеры обходят MFA в 2025–2026 годах?

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

Три вектора, которые определяют ландшафт атак в 2025–2026 годах:

• Злоумышленник посередине (AiTM, Adversary-in-the-Middle). Злоумышленник разворачивает прокси-сервер между пользователем и легитимным сайтом. Жертва вводит логин, пароль и код MFA — всё это в реальном времени передаётся на настоящий ресурс. Сервер возвращает валидную сессионную куку, которую атакующий перехватывает и использует самостоятельно. Второй фактор отработал корректно — сессия скомпрометирована.
• Усталость от MFA (атака на подтверждение push-уведомлений). Злоумышленник, располагая логином и паролем, отправляет непрерывный поток push-запросов на смартфон жертвы. Десятки уведомлений подряд — ночью, в рабочее время, во время совещания. Часть пользователей в какой-то момент нажимает «Подтвердить» — чтобы остановить поток или по невнимательности.
• Перехват сессии через программы-похитители данных (инфостилеры). Инфостилер — вредоносная программа, которая извлекает сохранённые сессионные куки из браузера уже после того, как пользователь прошёл аутентификацию. Украденная кука позволяет войти в систему без повторного ввода пароля и второго фактора — сессия считается активной и доверенной. Этот вектор не требует взаимодействия с жертвой в реальном времени.

Надёжные методы аутентификации: от TOTP до FIDO2

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

Приложения-аутентификаторы (TOTP)

Одноразовый пароль на основе времени (TOTP, Time-based One-Time Password) — метод генерации шестизначного кода каждые 30 секунд на основе общего секрета (seed), известного устройству и серверу. Алгоритм стандартизирован в RFC 6238. Приложения типа Пассворк 2ФА и Яндекс.Ключ работают офлайн и не зависят от оператора связи.

• Плюсы: простота развёртывания, нет зависимости от SMS-инфраструктуры, бесплатно для пользователя.
• Минусы: уязвим к AiTM-фишингу — код перехватывается в реальном времени и действителен 30 секунд, чего достаточно для атаки. При утере устройства восстановление доступа требует отдельного процесса.

Push-уведомления с числовым совпадением

Push-аутентификация с числовым совпадением (Number Matching) — улучшенная версия push-подтверждения: вместо кнопки «Разрешить / Отклонить» пользователь видит число на экране входа и вводит его вручную в мобильном приложении. Автоматическое подтверждение становится невозможным — случайное нажатие или нажатие под давлением потока уведомлений исключено.

Этот механизм хорошо знаком тем, кто пользуется сервисами Google: при входе в аккаунт на экране появляется двузначное число, которое нужно найти и выбрать в уведомлении на смартфоне.

Числовое совпадение (Number Matching) — минимальный стандарт для push-аутентификации в 2026 году. Без него push-уведомления остаются уязвимыми к атаке на усталость от двухфакторной аутентификации.

Аппаратные ключи (USB-токены)

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

• Плюсы: высокая надёжность, защита от удалённых атак, соответствие требованиям ФСТЭК для привилегированного доступа. Рутокен и JaCarta сертифицированы по российским стандартам.
• Минусы: стоимость от 2 000 до 8 000 руб. за устройство, необходимость физического управления парком токенов, неудобство для мобильных и удалённых сотрудников.

MFA, устойчивая к фишингу: FIDO2 и ключи доступа

FIDO2 — открытый стандарт аутентификации альянса FIDO, основанный на криптографии с открытым ключом и привязке к домену. Ключи доступа (Passkeys) — пользовательская реализация FIDO2, встроенная в операционные системы и браузеры: закрытый ключ хранится в защищённом хранилище устройства — доверенном анклаве или модуле TPM, — а подтверждение входа выполняется через биометрию или ПИН-код.

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

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

Сравнение методов MFA

Регуляторные требования: ФСТЭК №117 и обязательный MFA

С 1 марта 2026 года вступил в силу приказ ФСТЭК России №117, который существенно расширяет периметр обязательных требований к защите информации. Если прежние нормы (Приказ №17) касались преимущественно государственных информационных систем (ГИС), то теперь новые правила охватывают все информационные системы госорганов, ГУПов и подведомственных учреждений, независимо от их назначения и архитектуры.

Ключевые изменения, которые напрямую касаются аутентификации:

• Обязательная строгая аутентификация для удалённого доступа. Подключение к корпоративным ресурсам извне, а также доступ с мобильных устройств теперь безальтернативно требуют строгой аутентификации (по ГОСТ Р 58833-2020, с использованием криптографических протоколов, например, аппаратных токенов с УКЭП).
• Многофакторная аутентификация для привилегированного доступа. Для учетных записей с расширенными правами (администраторы, DevOps, DBA) также требуется строгая аутентификация. Однако регулятор делает важное практическое уточнение: если её реализация технически невозможна, допускается использование усиленной многофакторной аутентификации.
• Непрерывный мониторинг и журналирование. Вводятся жесткие требования к журналированию событий аутентификации и обязательной интеграции с системами мониторинга (SIEM) и ГосСОПКА в режиме 24/7.

Параллельные требования для КИИ и коммерческого сектора:

• Объекты КИИ (187-ФЗ). Если информационная система является значимым объектом критической информационной инфраструктуры, к ней параллельно применяются жесткие требования Приказа ФСТЭК №239 по идентификации, аутентификации и управлению доступом.
• Коммерческие организации (152-ФЗ). Для компаний, обрабатывающих персональные данные, актуальны требования 152-ФЗ и Приказа ФСТЭК №21. При высоких уровнях защищенности или организации удаленного доступа к базам ПДн применение надежных методов многофакторной аутентификации становится стандартом де-факто для выполнения рекомендаций регулятора.

Практический вывод: Если ваша организация попадает под действие Приказа ФСТЭК №117, внедрение MFA перестаёт быть вопросом целесообразности или внутренней оценки рисков — это прямое юридическое требование с конкретными сроками. Невыполнение этих норм приведет к невозможности пройти аттестацию информационной системы или продлить действующий аттестат при её модернизации.

Пошаговый план внедрения MFA в компании

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

Шаг 1. Аудит и инвентаризация

Составьте карту критичных систем с приоритизацией по риску:

• Высокий приоритет: почта, системы удалённого доступа, облачные сервисы (корпоративные порталы), привилегированные учётные записи.
• Средний приоритет: CRM, ERP, финансовые системы, HR-платформы.
• Базовый приоритет: внутренние инструменты с ограниченным доступом к данным.

Для каждой системы определите: поддерживает ли она FIDO2/SAML, какие методы MFA совместимы, есть ли API для интеграции.

Шаг 2. Сегментация пользователей и выбор методов

Не применяйте единый метод для всех — это неэффективно и создаёт лишние точки трения:

• Администраторы и привилегированные пользователи → аппаратные токены (Рутокен, JaCarta) или FIDO2-ключи.
• Рядовые сотрудники → TOTP-приложение или ключи доступа (Passkeys). Push-уведомления с сопостовлением цифр (Number Matching) — как переходный вариант.
• Внешние подрядчики → временные TOTP-токены с ограниченным сроком действия и минимальными правами доступа.

Шаг 3. Пилотный запуск

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

Фиксируйте: количество обращений в поддержку, время на аутентификацию, случаи блокировки доступа. Эти данные понадобятся для обоснования масштабирования.

Шаг 4. Обучение сотрудников

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

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

Шаг 5. Резервные пути доступа

Отсутствие регламента восстановления доступа — критическая ошибка. Пропишите процедуры для каждого сценария:

• Утеря телефона: резервные коды восстановления, хранящиеся в защищённом месте (не в почте)
• Утеря токена: процедура блокировки и выдачи нового с верификацией личности
• Недоступность сервера аутентификации: резервный метод аутентификации для критичных систем с обязательным аудитом использования

Сценарии потери доступа и порядок действий

Заключение

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

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

Начните с аудита: определите, какие системы защищены, какими методами и соответствуют ли они актуальным угрозам. Приоритизируйте привилегированный и удалённый доступ — именно там риск наиболее высок и требования ФСТЭК №117 наиболее жёсткие.

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

Часто задаваемые вопросы

Вступление

Как часто ваши сотрудники забывают пароли от корпоративных сервисов? Эта проблема знакома многим компаниям: «парольная усталость» забирает время у сотрудников на восстановление доступа, а у ИТ-отделов — на постоянную поддержку пользователей. Есть ли способ этого избежать?

На помощь приходит технология единого входа — Single-Sign-On (SSO), обещающая избавить бизнес от рутины и повысить безопасность. Но что такое SSO на самом деле, зачем она нужна, какие преимущества и подводные камни скрываются за её удобством? Почему грамотное управление системой единого входа — это не только про комфорт, но и про защиту данных компании.

Что такое единый вход

Представьте, что у вас есть один ключ, который открывает все двери в офисе. Удобно? Именно так работает Single Sign-On. Это система, позволяющая пользователю пройти единую аутентификацию и получить доступ ко всем корпоративным приложениям, сервисам и платформам без необходимости повторно вводить пароли.

После успешной аутентификации система автоматически передаёт сервисам специальные ключи доступа (SSO-токены). Благодаря этому приложения сразу распознают пользователя и предоставляют нужные права. Вместо десятков паролей сотруднику достаточно одной пары: логина и пароля SSO.

Технология SSO работает на основе современных протоколов — SAML, OAuth, OpenID Connect. Они обеспечивают безопасный обмен данными между сервисами. Для ИТ-отдела SSO становится центральной точкой управления доступом, а для сотрудников — простым и надёжным способом входа во все цифровые ресурсы компании.

Как работает SSO

1. Запрос доступа к приложению. Пользователь открывает корпоративное приложение (например, CRM или почту). Приложение не находит локальной сессии и перенаправляет пользователя на SSO-провайдера (Identity Provider, IdP).
2. Перенаправление и аутентификация. Пользователь попадает на страницу IdP (например, Microsoft Azure AD, Okta, или корпоративный сервер SAML/OAuth). Здесь он вводит свои корпоративные учетные данные.
3. Проверка личности и MFA. IdP проверяет логин и пароль, а также (если настроено) запрашивает второй фактор (например, SMS-код, push-уведомление, биометрию).
4. Генерация токена (Assertion/Token). После успешной аутентификации IdP создает специальный токен (например, SAML Assertion или JWT-токен для OAuth/OpenID Connect), который подтверждает личность пользователя.
5. Передача токена приложению и его верификация. SSO-провайдер перенаправляет пользователя обратно в приложение, передавая токен через защищённый канал (обычно HTTPS). Приложение проверяет токен: удостоверяется, что он выдан доверенным IdP и не был изменён.
6. Предоставление доступа. Если проверка успешна — пользователь получает доступ к приложению. При переходе к другим сервисам повторная аутентификация не требуется: токен уже есть.
7. Централизованное управление доступом. ИТ-отдел может централизованно управлять правами: блокировать пользователей, подключать MFA, просматривать логи входов и быстро отзывать доступ ко всем приложениям при необходимости.

Термины и определения

Собрали основные термины, которые помогут быстро разобраться в технологии SSO и связанных с ней понятиях.

• SSO (Single Sign-On). Технология единого входа — позволяет пользователю получить доступ ко многим приложениям и сервисам после одной аутентификации.
• Identity Provider (IdP). Провайдер идентификации — система, которая отвечает за проверку личности пользователя и выдачу токенов для доступа к приложениям.
• Service Provider (SP). Провайдер сервиса — приложение или сервис, к которому пользователь получает доступ через SSO.
• SAML (Security Assertion Markup Language). Один из популярных протоколов для передачи данных аутентификации между IdP и SP.
• OAuth 2.0. Протокол авторизации, позволяющий приложениям получать ограниченный доступ к учетной записи пользователя без передачи пароля.
• OpenID Connect. Расширение OAuth 2.0, добавляющее механизм аутентификации и передачи информации о пользователе.
• MFA (Multi-Factor Authentication). Многофакторная аутентификация — дополнительный уровень защиты, при котором требуется второй фактор (например, SMS, приложение, биометрия).
• Token (Токен). Цифровой «пропуск», который подтверждает успешную аутентификацию пользователя и содержит информацию о его правах.
• Assertion (Ассерция). Структурированный документ (обычно в SAML), который удостоверяет личность пользователя и его права.
• Session (Сессия). Промежуток времени, в течение которого пользователь аутентифицирован и может пользоваться сервисами без повторного входа.
• SSO Portal (SSO-портал). Централизованная точка входа, через которую сотрудники могут получать доступ ко всем корпоративным приложениям.

Почему это важно

Задумывались, сколько времени уходит у ваших сотрудников на восстановление паролей или поиск нужных доступов? Технология SSO решает эту проблему раз и навсегда:

• Меньше стресса для сотрудников. Больше не нужно запоминать десятки паролей или искать их в спешке — один вход открывает все нужные ресурсы.
• Централизованный контроль. Все права и доступы удобно управляются из единого центра. ИТ-отделу не нужно вручную раздавать или отзывать доступы по каждому сервису.
• Лёгкая интеграция новых сервисов. Подключили новый инструмент? С SSO сотрудник сразу получает к нему доступ.

Но, как и любой универсальный ключ, технология единого входа требует особого внимания к вопросам безопасности. В чём сильные и слабые стороны SSO?

Преимущества внедрения единого входа

Упрощение аутентификации

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

• Меньше лишних действий: сотрудники не тратят время на повторные входы и переключения между сервисами.
• Снижается барьер для внедрения новых решений: удобный и быстрый доступ через SSO мотивирует персонал пользоваться новыми сервисами без лишних вопросов.

Пример: в крупной ИТ-компании сотрудники используют до 20 разных систем ежедневно. Внедрение SSO позволяет им входить во все системы через единый вход, экономя до 30 минут рабочего времени в неделю на каждом сотруднике.

Меньше обращений в поддержку

Сотрудники забывают пароли, службы поддержки завалены запросами на сброс. SSO решает эту проблему — пользователю нужен только один пароль. Это снижает нагрузку на ИТ-отдел и экономит ресурсы компании. Вероятность потерять один доступ гораздо ниже.

• Снижение нагрузки на helpdesk: до 50% всех обращений в поддержку связаны именно с паролями. SSO позволяет сократить этот поток в разы.
• Больше времени на работу, меньше — на ожидание: меньше сбоев, выше удовлетворённость сотрудников и, как следствие, рост эффективности бизнеса.

Пример: если в компании с 1000 сотрудников каждый тратит по 5 минут в неделю на восстановление паролей, это 83 часа потерь ежемесячно. После внедрения SSO количество обращений может снизиться на 60–70%, а IT-отдел освободит до 50 часов в месяц для решения других задач.

Повышение уровня безопасности

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

• Многофакторная авторизация на базе SSO: ИТ-отдел легко подключает второй фактор — безопасность выходит на новый уровень.
• Мгновенное управление доступом: централизованное управление SSO позволяет быстро блокировать доступ уволенным сотрудникам.
• Современные стандарты защиты: SSO использует актуальные протоколы шифрования и ведёт подробные логи — вы всегда знаете, кто, когда и куда заходил.

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

Недостатки единого входа

Создание единой точки отказа

Если единый вход — это ключ ко всему, что будет, если он сломается?

• Если сервис SSO выходит из строя, сотрудники теряют доступ ко всем корпоративным системам одновременно
• В случае успешной атаки на SSO-аккаунт злоумышленник получает полный доступ ко всей инфраструктуре

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

Внедрение единого входа может быть сложным

Запустить SSO не получится за один день. Процесс требует времени, ресурсов и технической экспертизы. Не все корпоративные приложения поддерживают современные протоколы SSO (SAML, OAuth и другие). С устаревшими системами могут возникнуть сложности — часть из них не интегрируется с единой аутентификацией вовсе.

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

Не все приложения поддерживают единый вход

Даже самые продвинутые SSO-сервисы не всегда могут интегрироваться с нестандартными или устаревшими приложениями. В итоге часть сотрудников оказывается «за бортом» — им всё равно приходится использовать отдельные логины и пароли.

• Некоторые приложения не поддерживают SSO без доработки, что требует дополнительных ресурсов
• Для таких сервисов приходится вручную управлять доступом, что увеличивает риски и снижает общую эффективность системы безопасности
• Управление становится сложнее, если часть сервисов выпадает из единой схемы доступа

Чтобы минимизировать эти проблемы, важно заранее провести инвентаризацию всех используемых приложений и оценить возможности их интеграции с SSO. Так вы избежите неожиданных «узких мест» и сможете построить действительно удобную и безопасную инфраструктуру.

Разница между менеджером паролей и SSO

На первый взгляд, может показаться, что менеджеры паролей и системы единого входа (SSO) решают одну и ту же задачу — позволяют сотрудникам быстро и удобно получать доступ к нужным сервисам. Оба инструмента действительно упрощают жизнь пользователям и ИТ-отделу. Но если посмотреть глубже, у каждого решения есть свои сильные стороны, которые делают их не просто похожими, а взаимодополняющими.

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

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

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

Почему SSO и менеджер паролей должны работать вместе

Использовать только SSO недостаточно: не все сервисы и приложения поддерживают современные протоколы единого входа, такие как SAML или LDAP. В компании всегда найдутся системы, которые не интегрированы с SSO — старые приложения, сторонние сервисы, разовые проекты или даже те, о которых ИТ-отдел может не знать. Эти «слепые зоны» создают риски для безопасности и управления доступом.

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

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

Сравнение подходов к управлению доступом

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

Заключение

SSO делает работу проще, быстрее и безопаснее, но не решает все задачи сам по себе. Как и любой мощный инструмент, он требует продуманного подхода и поддержки.

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

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

Читайте также

Кибератаки: что это такое и как их распознать

Содержание * Вступление * Что такое угроза информационной безопасности * Классификация угроз информационной безопасности * Основные виды угроз информационной безопасности * Реальные последствия для бизнеса * Как защититься от угроз информационной безопасности * Глоссарий терминов * Заключение Вступление Что общего между утечкой данных в крупном банке, масштабной фишинговой атакой и внезапным отключением серверов? Все эти инциденты — проявления одной

Блог ПассворкаШелыгин Илья

Преимущества и недостатки Single Sign-On

Содержание * Вступление * Что такое единый вход * Как работает SSO * Термины и определения * Почему это важно * Преимущества внедрения единого входа * Недостатки единого входа * Разница между менеджером паролей и SSO * Почему SSO и менеджер паролей должны работать вместе * Сравнение подходов к управлению доступом * Заключение Вступление Как часто ваши сотрудники забывают пароли от

Блог ПассворкаИлья Шелыгин

Почему бизнес выбирает расширенную версию Пассворка

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

Блог ПассворкаАнастасия Лебедева