Аутентификация

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

Сотрудник входит в корпоративную учётную запись один раз. После этого он открывает почту, трекер задач и корпоративный портал без ввода новых паролей. В статье разберём:

• Как работает единый вход (SSO) по шагам
• Какие плюсы у SSO и какие риски
• Чем SAML отличается от OIDC
• Кому SSO нужен и что остаётся за его границей

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

Что такое SSO: расшифровка, участники и отличия от LDAP, OAuth и MFA

SSO (сокращение от англ. Single Sign-On, то есть «единый вход» или «единая аутентификация») — метод аутентификации, при котором сотрудник подтверждает личность один раз, у провайдера идентификации (IdP, Identity Provider). Остальные приложения доверяют результату этой проверки и не запрашивают пароль повторно.

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

В схеме три участника:

• Пользователь запрашивает доступ и один раз подтверждает личность.
• Поставщик услуг (SP, Service Provider) — приложение, которое доверяет IdP и проверяет подпись токена.
• Провайдер идентификации (IdP) проверяет пароль и второй фактор, ведёт сессию и выпускает токены. Примеры: Keycloak, AD FS, MULTIFACTOR SSO, Yandex Identity Hub.

С SSO часто путают соседние технологии. Единый вход опирается на каждую, но решает свою задачу:

Как работает SSO: схема входа по шагам

Вход по SSO проходит в шесть шагов. Приложение отправляет браузер пользователя к IdP, IdP проверяет пароль и второй фактор и выпускает подписанный токен, приложение проверяет подпись и открывает доступ. Для каждого следующего приложения IdP выдаёт новый токен, а пароль пользователь не вводит.

Шесть шагов входа

1. Запрос доступа. Сотрудник открывает приложение (SP). Активной сессии у приложения нет, пользователя нужно проверить.
2. Перенаправление. Приложение направляет браузер к IdP и передаёт запрос: кто просит доступ и куда вернуть результат.
3. Проверка. IdP запрашивает пароль и второй фактор (MFA). Это происходит один раз за сессию: если сессия у IdP уже есть, шаг пропускается.
4. Выпуск токена. IdP формирует подписанный токен: SAML-утверждение (assertion) или ID-токен в формате JWT (JSON Web Token). В нём указаны пользователь, срок действия и адресат. Браузер доставляет токен приложению.
5. Проверка токена. Приложение сверяет подпись с сертификатом IdP, а также срок действия и адресата.
6. Открытие сессии. Приложение создаёт собственную сессию и пускает пользователя.

Когда сотрудник открывает второе приложение, повторяются шаги 1, 2, 4, 5 и 6. IdP находит активную сессию, не запрашивает пароль и MFA и сразу выдаёт токен. Проверка проходит один раз, а доверие распространяется на все подключённые приложения. Отсюда слово «единый».

Почему MFA настраивают на уровне IdP

Страница входа IdP становится главной целью фишинга. По данным BI.ZONE (Threat Zone 2026), в 2025 году фишинг стал основным способом первоначального проникновения: 64% эпизодов в атаках на организации России и СНГ. Поэтому MFA включают на IdP: приложения получают токен с подтверждением пройденной проверки, и отдельный второй фактор им обычно не нужен. От фишинга лучше защищают ключи доступа, о них — в разделе про меры защиты.

Два сценария входа: из приложения и из портала

В схеме выше вход начинает приложение. Это SP-initiated вход. При IdP-initiated входе сотрудник сначала заходит на корпоративный портал IdP, где собраны значки доступных ему приложений, и выбирает нужное, например CRM-систему. IdP сам отправляет токен этому приложению, хотя оно запроса не делало.

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

Сессии, токены и выход

Единый вход держится на трёх временных объектах: токене, сессии у IdP и сессии в приложении. Что происходит при их истечении и при увольнении сотрудника, зависит от сроков и от поддержки единого выхода.

Какие бывают токены и сессии

• Токен подтверждения входа (SAML-утверждение или ID-токен) нужен один раз: приложение проверяет его на шаге 5 и открывает сессию. Срок действия у него короткий, обычно минуты.
• Токен доступа (access token) используется в OAuth 2.0 и OIDC: подтверждает право приложения обращаться к данным или API от имени пользователя. Живёт от минут до часов. Чем короче срок, тем меньше времени у злоумышленника, но тем чаще токен приходится обновлять.
• Токен обновления (refresh-токен) наследуется от OAuth 2.0 и даёт новый токен доступа без ввода пароля, пока сессия у IdP не закончилась.
• Сессия IdP — период, пока IdP помнит, что пользователь прошёл проверку. Длится часы или дни, в зависимости от политики компании.
• Сессия приложения — собственная сессия, которую приложение открывает на шаге 6. Она не зависит от сессии IdP: если сессия у IdP завершилась, приложение об этом само не узнает.

SAML и OIDC: что выдаёт IdP

SAML (Security Assertion Markup Language) — открытый стандарт обмена данными об аутентификации между IdP и приложением на основе XML. IdP выдаёт SAML-утверждение: подписанный XML-документ с идентификатором пользователя, атрибутами, сроком действия и адресатом. SAML появился раньше OIDC и до сих пор широко применяется в корпоративных системах, например при подключении веб-приложений к AD FS и Keycloak.

OIDC (OpenID Connect) — протокол входа на основе OAuth 2.0. OAuth 2.0 отвечает на вопрос «что разрешено приложению», OIDC добавляет ответ на вопрос «кто этот пользователь». Для этого IdP выдаёт ID-токен в формате JWT: подписанный набор данных о пользователе, сроке действия и адресате в формате JSON. OIDC проще встроить в мобильные и одностраничные приложения.

Почему выход сложнее входа

Единый выход (SLO, Single Logout) должен завершить сессию у IdP и во всех приложениях одновременно. На практике он работает не везде: приложение без поддержки SLO сохраняет собственную сессию до истечения токена.

Поэтому при увольнении отзыв доступа в IdP закрывает только новые входы. Открытые сессии продолжают работать до конца срока токена. Чтобы сократить этот интервал, задают короткий срок токена для критичных приложений и проверяют, поддерживает ли каждое из них SLO.

Протоколы SSO: SAML, OpenID Connect, OAuth 2.0 и Kerberos

Протокол SSO определяет, в каком формате IdP сообщает приложению о пройденной проверке. Для корпоративных веб-приложений чаще используют SAML 2.0, для облачных и мобильных — OpenID Connect (OIDC), внутри домена Windows — Kerberos. OAuth 2.0 отвечает за доступ к API. Для входа поверх него нужен OIDC.

SAML и OIDC определены выше, в блоке «Какие протоколы выдают токены». Здесь они сравниваются с двумя другими протоколами.

Сравнение протоколов SSO: что выдаёт IdP и где применяется

Сравнение протоколов SSO: сильные стороны и ограничения

Чем SSO отличается от OAuth 2.0

Частая ошибка — путать SSO и OAuth. OAuth 2.0 описывает делегирование: приложение получает право читать календарь или вызывать API от имени пользователя. Кто вошёл в систему, OAuth не сообщает. Это делает OIDC: он добавляет к OAuth ID-токен с идентификатором пользователя.

Плюсы SSO и оборотная сторона каждого

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

Безопасность SSO: риски, минусы и единая точка отказа

Главный минус SSO — единая точка отказа (SPOF, Single Point of Failure). Если IdP недоступен или скомпрометирован, под ударом все подключённые приложения. Риск снижают отказоустойчивая установка IdP, MFA и документированный резервный вход.

Шесть сценариев отказа и как их закрыть

Номера шагов в таблице относятся к схеме входа из начала статьи.

Минусы, которые настройкой не закрыть

• Стоимость. Лицензии или подписка на IdP, настройка каждого приложения, люди на поддержку. При малом числе сервисов затраты не окупаются: выгода растёт вместе с числом приложений и сотрудников.
• Ограничения протоколов. SAML и OIDC работают через браузер. «Толстые» клиенты и самописные системы подключают через агентов и прокси либо оставляют вне SSO.

Как снизить риски SSO: пять мер

Пять мер превращают единый вход из точки риска в точку контроля: MFA на уровне IdP, короткие сессии, отказоустойчивый IdP с резервным входом, аудит приложений и журнал входов в SIEM. Каждая закрывает сценарий из таблицы отказов.

1. Включите MFA на уровне IdP. Лучше использовать ключи доступа (passkey, FIDO2/WebAuthn). Ключ привязан к домену IdP, поэтому поддельная страница входа ответа не получит.
2. Сократите срок сессий и токенов. Это сессия IdP, сессия приложения и токены доступа. Чем короче срок, тем меньше окно для украденной сессии.
3. Сделайте IdP отказоустойчивым. Нужны кластер, резервные копии базы и сертификатов, календарь замены сертификатов и синхронизация времени по NTP. Для критичных систем заведите документированный резервный вход.
4. Раз в квартал сверяйте подключённые приложения и права. Отзывайте неиспользуемые интеграции и избыточные роли.
5. Передавайте журнал входов в SIEM и настройте оповещения. Сигналы: вход из нетипичной страны, серия отказов MFA, одновременные сессии из разных мест.

Пассворк разворачивается на серверах компании, интегрируется с SSO, Active Directory и LDAP и даёт ИТ-отделу контроль над учётными данными. Попробуйте Пассворк бесплатно в своей инфраструктуре или облаке.

SSO для бизнеса: когда внедрение оправдано, а когда нет

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

Чек-лист: 6 признаков, что компании пора внедрять SSO

1. Десять и больше корпоративных сервисов, в каждом отдельная учётная запись.
2. Регулярный найм и увольнения или подрядчики с временным доступом. При ручном отзыве часть записей остаётся.
3. Регулятор требует строгой или многофакторной аутентификации (ГИС, ИСПДн, финансовая отрасль).
4. Единый журнал входов нужен для аудита и расследований.
5. Большинство сервисов поддерживает SAML или OIDC.
6. Есть команда для поддержки IdP или бюджет на облачный IdP.

Если отмечено меньше трёх пунктов, начните с менеджера паролей и 2ФА. SSO не оправдан и при любом из трёх условий:

• сервисов не больше пяти, администратор один;
• большинство систем работает без SAML и OIDC;
• нет ресурса на отказоустойчивый IdP.

SSO и менеджер паролей: где заканчивается единый вход и как работает Пассворк

SSO закрывает вход в приложения с поддержкой SAML или OIDC. За его границей остаются устаревшие и самописные системы, общие аккаунты команд, инфраструктурные секреты и доступы подрядчиков. Эту зону закрывает корпоративный менеджер паролей, а вход в него можно настроить через тот же IdP.

Как Пассворк работает с SSO

Пассворк подключается к IdP как поставщик услуг по SAML 2.0. Сотрудник открывает Пассворк, система перенаправляет его в корпоративный IdP, после проверки там он попадает обратно в Пассворк уже авторизованным. Если SSO не нужен, вход можно настроить через Active Directory или LDAP. Сотрудники заходят с доменной учётной записью, а заблокированный в каталоге пользователь теряет доступ и к Пассворку.

Как в Пассворке устроены права на общие данные

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

Заключение

SSO даёт управляемость: выдача, смена и отзыв прав происходят в одном месте, а удобство для сотрудников приходит как следствие. Обратная сторона такая же: вся защита входа сосредоточена в IdP. Её держат MFA, короткие сессии, отказоустойчивая установка и резервный вход.

Решение о внедрении принимают по шести признакам из чек-листа, порог — три. Если IdP уже работает, подключите к нему менеджер паролей и закройте то, что единый вход не покрывает: устаревшие системы, общие аккаунты, инфраструктурные секреты и доступы подрядчиков.

Пассворк разворачивается на серверах компании или в облаке, интегрируется с SSO, AD/LDAP и даёт ИТ-отделу полный контроль над учётными данными. Протестируйте бесплатно в своей инфраструктуре или в облаке

Часто задаваемые вопросы о Single Sign-On (SSO)

Что такое SSO (Single Sign-On) простыми словами?

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

SSO — это аутентификация или авторизация?

Это аутентификация: SSO подтверждает, кто вошёл, а права внутри приложения (авторизацию) определяет само приложение. Токен SAML или OIDC может передавать роли и группы, но решение о доступе принимает приложение.

SSO — это безопасно?

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

Чем SSO отличается от OAuth 2.0 и OpenID Connect?

OAuth 2.0 — протокол делегирования доступа к API, личность пользователя он не подтверждает. OpenID Connect добавляет поверх него ID-токен, и по этому токену приложение пускает пользователя. SSO — сценарий, который реализуют через OIDC, SAML 2.0 или Kerberos, в зависимости от поддержки в приложении.

Чем SSO отличается от LDAP и Active Directory?

LDAP — протокол обращения к каталогу пользователей и групп, Active Directory — служба каталогов Microsoft. Каталог хранит учётные записи и проверяет пароль, а SSO строится поверх него: IdP обращается к каталогу, проверяет пользователя и выдаёт токены приложениям.

Нужна ли двухфакторная аутентификация, если есть SSO?

Да. SSO второй фактор сам не добавляет: без MFA на IdP один украденный пароль открывает все приложения. Приказ ФСТЭК № 117 требует для привилегированного и удалённого доступа строгой или усиленной многофакторной аутентификации (п. 46 и 48 Требований).

Что будет, если провайдер идентификации недоступен?

Новые входы невозможны, пока IdP не восстановится, а открытые сессии в приложениях работают до конца срока. Поэтому IdP разворачивают отказоустойчиво, а для критичных систем держат документированный резервный вход. Его учётные данные хранят вне самого IdP и периодически проверяют, что вход работает.

Нужен ли менеджер паролей, если есть SSO?

Да. SSO покрывает приложения с поддержкой SAML или OIDC. Устаревшие системы, общие аккаунты команд, инфраструктурные секреты и доступы подрядчиков остаются за его границей, их закрывает корпоративный менеджер паролей. Вход в менеджер можно вести через тот же IdP, но при клиентском шифровании мастер-пароль остаётся.

Авторизация, аутентификация и идентификация: в чём разница

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

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

Пассворк 7.8: политики паролей

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

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

Кейс-стади Пассворк и Петрович-Тех: управление доступами сотрудников

Крупный ритейл, сотни сотрудников, десятки подрядчиков — и ни одного пароля в Excel. «Петрович-Тех» развернула Пассворк на своих серверах, настроила SSO и AD. Итог — полный контроль без потери удобства.

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

Идентификация отвечает на вопрос «Кто ты?», аутентификация на вопрос «Докажи, что это ты», авторизация на вопрос «Что тебе разрешено?». Это не синонимы: три последовательных процесса, у каждого свои механизмы.

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

На практике эти слова путают постоянно: кнопку входа подписывают «Авторизация», хотя за ней стоит аутентификация. Ниже разберём каждый этап, сравним их в таблице и пройдём по 12 ошибкам, которые ИТ-команды допускают на каждом из них. В статье есть тест из шести вопросов, чтобы проверить себя.

Авторизация, аутентификация и идентификация на примере входа в систему

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

Посмотрим, как эти три проверки проходят по шагам:

1. Идентификация. Сотрудник открывает страницу входа корпоративного портала и вводит доменный логин i.ivanov. Система находит запись в каталоге Active Directory.
2. Аутентификация. На той же странице он вводит пароль и код из приложения-аутентификатора. Это два фактора из разных категорий: знание и владение. Если они верны, система подтверждает вход.
3. Авторизация. Затем он открывает, например, менеджер паролей. Пароль повторно вводить не нужно: благодаря единому входу (SSO) система принимает подтверждение входа от портала. По роли и правам сотрудник видит сейфы своего отдела.

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

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

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

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

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

Что такое авторизация

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

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

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

Идентификация: виды идентификаторов и типичные сбои

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

Какие бывают идентификаторы

• Имя пользователя или email — то, что вводят на странице входа.
• Внутренний идентификатор (UID, табельный номер) — остаётся прежним при смене логина.
• Доменная учётная запись в Active Directory — единое имя для всех подключённых систем.
• Идентификатор сервиса или устройства — сертификат, идентификатор API-клиента.

Первичная и повторная идентификация

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

Где идентификация ломается

Идентификация ломается из-за небрежного учёта учётных записей. Четыре типовые ошибки:

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

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

Аутентификация: виды, факторы и методы

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

Три фактора

• Знание: пароль, ПИН-код, ответ на контрольный вопрос.
• Владение: приложение-аутентификатор, аппаратный ключ, SIM-карта для SMS.
• Свойство: отпечаток пальца, геометрия лица.

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

1FA, 2ФА и MFA: в чём разница

Однофакторная аутентификация (1FA) опирается на один фактор, обычно пароль. Фишинговая страница, подбор по словарю, утёкшая база или покупка в даркнете, и учётная запись скомпрометирована целиком. Подробнее о приёмах взлома паролей: актуальные методы взлома паролей.

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

Многофакторная аутентификация (MFA) объединяет два и более фактора: 2ФА остаётся её частным случаем. Три фактора (пароль, аппаратный ключ, биометрия) применяют там, где цена ошибки максимальна: для привилегированного доступа и критичных систем.

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

1. SMS-код. Самый распространённый и самый уязвимый: SIM-своп и перехват на уровне сигнального протокола SS7 дают атакующему код. Допустим как временная мера для низкорисковых сценариев.
2. Одноразовый код на почту. Надёжность равна защищённости почтового ящика. Если почта скомпрометирована, второго фактора фактически нет.
3. Пуш-уведомление. Запрос приходит на доверенное устройство и показывает контекст: время, геолокацию, источник. Слабое место: серия запросов подряд, после которой уставший пользователь подтверждает один из них.
4. Приложение-аутентификатор (TOTP). Код генерируется на устройстве и живёт 30 секунд, от SIM-свопа не зависит. Проксирующая фишинговая страница всё же способна перехватить его в реальном времени.
5. Ключи доступа (Passkeys) и аппаратные ключи FIDO2. Приватный ключ не покидает защищённое хранилище устройства, а подпись привязана к домену сайта, поэтому на поддельной странице вход не сработает. Биометрия на этом уровне служит локальным способом разблокировать ключ.

Пассворк поддерживает вход по ключам доступа, биометрии, аппаратным ключам, TOTP и приложению «Пассворк 2ФА», а также единый вход через SAML SSO и каталог LDAP/Active Directory. Попробуйте Пассворк бесплатно

Авторизация: виды, модели доступа и принцип наименьших привилегий

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

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

Ролевая модель (Role-Based Access Control, RBAC) назначает права ролям, а сотрудники получают их через членство в роли или группе. В сквозном примере сотрудник входит в группу своего отдела и получает доступ к сейфам и папкам этого отдела. При переводе в другой отдел меняется группа, правки каждой записи не требуется. Ограничение модели: роль не знает контекста запроса.

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

Атрибутная модель (Attribute-Based Access Control, ABAC) принимает решение по атрибутам субъекта, объекта, действия и окружения. Пример политики: менеджер читает клиентскую базу, если запрос идёт с корпоративного адреса в рабочее время. Тот же запрос с незнакомого адреса ночью требует повторной аутентификации или блокируется.

OAuth 2.0 и SSO: что здесь авторизация

OAuth 2.0 — это протокол делегирования доступа: пользователь разрешает приложению действовать от его имени в другом сервисе, а сервис выдаёт приложению токен с ограниченными правами и сроком действия. Например, приложение-планировщик получает доступ к календарю пользователя и не узнаёт пароль от него.

OpenID Connect (OIDC) — это надстройка над OAuth 2.0, которая добавляет аутентификацию: сервис входа сообщает приложению, какой именно пользователь вошёл. Сам OAuth 2.0 личность не проверяет. OIDC стоит за кнопкой «Войти через…».

Единый вход (Single Sign-On, SSO) — это схема, при которой пользователь проходит аутентификацию один раз в центральной системе входа, например в корпоративном каталоге, а остальные сервисы принимают это подтверждение без повторного ввода пароля. Для этого используют протоколы SAML и OIDC. Права внутри каждого сервиса остаются своими: их определяет авторизация самого сервиса.

Принцип наименьших привилегий

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

12 типичных ошибок идентификации, аутентификации и авторизации

Чек-лист «12 ошибок доступа» содержит по четыре ошибки на каждый из трёх этапов. Для каждой указано, что делать. Пройдите список по порядку, отметьте, что у вас уже закрыто, и начните с ошибок, которые опаснее всего для вашей инфраструктуры. Для регулярной сверки парольной части подойдёт чек-лист аудита парольной безопасности.

На этапе идентификации

На этапе аутентификации

На этапе авторизации

ГОСТ и приказ ФСТЭК № 117 об идентификации и аутентификации

Термины закреплены нормативно. ГОСТ Р 58833-2020 «Защита информации. Идентификация и аутентификация. Общие положения» описывает основы идентификации и аутентификации и уровни доверия к ним. Приказ ФСТЭК России от 11 апреля 2025 года № 117 ссылается на этот стандарт и называет идентификацию, аутентификацию и управление доступом базовыми мерами защиты.

Приказ действует с 1 марта 2026 года для государственных информационных систем и систем государственных органов и учреждений. Для привилегированного и удалённого доступа он требует строгой аутентификации или, если это технически невозможно, усиленной многофакторной. Остальным организациям документ служит ориентиром для самопроверки, а об обязательности стоит советоваться с юристом. Текст приказа: fstec.ru.

Заключение

Три вопроса, три слоя, три класса ошибок. Система спрашивает «Кто ты?», затем «Докажи», затем «Что тебе разрешено?», и сбой на каждом шаге выглядит по-своему: общий логин в журнале, украденный пароль, чужой объект в ответе API. Проверить всю цепочку идентификации, аутентификации и авторизации можно по журналу: он должен отвечать, кто вошёл, чем подтвердил личность, что получил и что запросил.

Если начинать с малого, четыре действия закрывают основные разрывы из таблиц выше:

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

Управление корпоративными учётными данными образует отдельный слой этой архитектуры: ролевая модель на уровне сейфов и записей, вход по ключам доступа, аппаратным ключам и SSO, журнал действий. Пассворк включён в реестр российского ПО и имеет сертификат ФСТЭК № 5063 (4-й уровень доверия). Попробуйте бесплатно

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

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

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

Почему кнопку входа называют «Авторизация», если это аутентификация?

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

Что идёт первым: авторизация или аутентификация?

Первой идёт аутентификация, второй авторизация. Сначала система должна установить, кто обращается, и только потом решает, что ему разрешено. Идентификация предшествует обоим этапам: без найденной учётной записи проверять нечего. Путаница возникает из-за кнопки входа, которую часто подписывают «Авторизация». Отказ на первом шаге даёт ошибку 401, на втором 403.

Можно ли пройти аутентификацию без идентификации, а авторизацию без аутентификации?

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

К какому этапу относится двухфакторная аутентификация?

Двухфакторная аутентификация (2ФА) относится к этапу аутентификации: второй фактор усиливает доказательство, что учётная запись принадлежит предъявителю. Идентификация происходит до неё, авторизация после. Если второй фактор запрашивают позже, перед чувствительным действием, это повторная аутентификация (step-up), и она остаётся частью того же этапа.

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

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

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

Как создать надёжный пароль в 2026: новые требования, правила и примеры

73% российских компаний до сих пор пользуются паролем по умолчанию — притом что одна лишняя буква длины часто защищает больше, чем весь набор спецсимволов. Разбираем, что на этот счёт думают ФСТЭК, NIST и OWASP, и как быстро собрать пароль, который устроит всех.

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

12 методов социальной инженерии и как им противостоять

Периметр можно укрепить до любого уровня. Социальная инженерия всё равно обойдёт его через человека. двенадцать рабочих методов атак 2025–2026 года и что с ними делать.

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

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

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