SSO и 2FA: как настроить безопасный единый вход для сотрудников

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

Что такое SSO и 2FA — и зачем их используют вместе

Как работает единый вход и двухфакторная аутентификация

SSO (Single Sign-On) — это технология единого входа, при которой сотрудник один раз проходит авторизацию и получает доступ сразу к нескольким корпоративным системам. Например, после входа в рабочий аккаунт пользователь может без повторного ввода пароля открыть Microsoft 365, CRM, корпоративный портал, Jira, VPN или внутренние веб-сервисы.

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

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

MFA (Multi-Factor Authentication) — это проверка личности пользователя по нескольким независимым факторам. Это могут быть:

• пароль;
• одноразовый код TOTP из приложения;
• push-подтверждение;
• аппаратный токен;
• биометрия.

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

Сценарий работы выглядит так:

1. Сотрудник вводит логин и пароль.
2. Система перенаправляет пользователя в identity-провайдер для проверки учетных данных и 2FA.
3. Пользователь подтверждает вход вторым фактором.
4. Система выдает токен авторизации.
5. Сотрудник получает доступ к подключенным сервисам без повторного входа.

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

Какие протоколы используют для SSO

Для работы единого входа SSO обычно используют три основных протокола: SAML, OAuth 2.0 и OpenID Connect (OIDC).

SAML чаще встречается в корпоративной среде — например, при интеграции с Active Directory, внутренними порталами, VPN и другими приложениями. OAuth 2.0 используют для делегированной авторизации между сервисами, а OpenID Connect работает как надстройка над OAuth и отвечает именно за аутентификацию пользователя.

На практике пользователь этого почти не замечает. Например, сотрудник открывает корпоративный портал, система перенаправляет его в identity-провайдер, проверяет 2FA и возвращает токен доступа. После этого сотрудник может работать сразу в нескольких сервисах без повторного ввода учетных данных.

Именно поэтому при настройке SSO для корпоративных решений важно заранее проверить совместимость приложений с SAML, OAuth или OIDC. Особенно если в инфраструктуре есть legacy-системы, старые веб-приложения или собственные разработки компании.

Двухфакторная аутентификация

ID — защита учетных записей сотрудников: подключений через VPN, RDG, ActiveSync, ADFS (протоколы OpenID Connect, SAML), защита входа в Windows, OWA.

Оставить заявку

Как настроить SSO с двухфакторной аутентификацией в корпоративной среде

Базовая схема внедрения SSO и 2FA

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

• корпоративная почта;
• CRM;
• VPN;
• файловые хранилища;
• HRM- и ERP-системы;
• внутренние веб-приложения;
• облачные сервисы.

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

Типовая схема внедрения SSO и 2FA выглядит так:

1. Компания выбирает identity-провайдер.
2. Подключает Active Directory или LDAP-каталог.
3. Интегрирует приложения через SAML 2.0 или OpenID Connect (OIDC).
4. Подключает корпоративные приложения.
5. Включает политики 2FA.
6. Настраивает правила доступа для сотрудников и подрядчиков.

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

• повторный запрос 2FA только при входе с нового устройства или браузера;
• отдельные политики безопасности для администраторов и привилегированных пользователей;
• усиленную проверку при входе из другой страны, необычной локации или сети;
• ограничение доступа к критичным системам через VPN и дополнительный контроль привилегированных сессий через PAM.

Например, сотрудник может без повторной авторизации работать в корпоративном портале и таск-трекере внутри офиса, но при подключении к финансовой системе из внешней сети система дополнительно запросит второй фактор.

Такой подход одновременно повышает безопасность учетных записей и снижает нагрузку на пользователей.

Интеграция с корпоративными и legacy-системами

С современными SaaS-сервисами настройка единого входа SSO обычно проходит относительно просто: большинство популярных платформ уже поддерживают SAML или OpenID Connect «из коробки». Например, SSO с 2FA сегодня поддерживают многие корпоративные сервисы — Microsoft 365, Битрикс24, Atlassian, Nextcloud и другие платформы, которые работают через SAML или OpenID Connect.

Сложности чаще возникают с legacy-системами — старыми корпоративными приложениями, которые изначально не проектировались для работы с SSO и 2FA. Это могут быть:

• «самописные» внутренние сервисы;
• старые ERP-системы;
• устаревшие веб-приложения;
• локальные системы документооборота.

В таких сценариях часто используют промежуточные шлюзы авторизации, обратные прокси или отдельные модули интеграции. Например, компания может централизовать вход сотрудников через Active Directory и SSO, но оставить старую бухгалтерскую систему внутри локального сегмента сети. Тогда пользователь сначала проходит 2FA в identity-провайдере, а уже затем получает доступ к legacy-приложению через защищенный шлюз.

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

• время жизни сессий;
• доступ по IP;
• список доступных систем;
• возможность входа без 2FA.

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

Информационная безопасность бизнеса

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

Оставить заявку

Как выбрать методы 2FA и не усложнить жизнь сотрудникам

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

На практике чаще всего используют четыре варианта 2FA:

Для большинства корпоративных сценариев оптимальным вариантом становятся push-уведомления или TOTP-приложения. SMS-аутентификацию используют реже — особенно для критичных систем и административных учетных записей.

При этом одна из возможных ошибок внедрения 2FA — попытка «закрутить гайки» одинаково для всех пользователей. Если сотрудник вынужден подтверждать вход по 20 раз в день, 2FA начинает восприниматься как помеха, а не как защита. Чтобы этого избежать, компании обычно комбинируют несколько подходов:

• запоминают доверенные устройства;
• не требуют 2FA внутри защищенного контура;
• усиливают проверки только для рискованных сценариев;
• разделяют политики для обычных пользователей и администраторов.

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

Отдельно стоит учитывать архитектуру сервиса. Облачные 2FA-платформы проще внедрять и масштабировать, особенно в распределенных компаниях. On-premise-решения чаще выбирают организации с жесткими требованиями к контролю инфраструктуры, хранению данных и внутренним регламентам информационной безопасности.

При выборе 2FA-решения важно смотреть не только на список методов аутентификации, но и на совместимость с инфраструктурой компании: Active Directory, VPN, RDP, веб-приложениями, Linux-серверами и корпоративными порталами. Иначе даже хорошая система может превратиться в набор разрозненных интеграций и ручных настроек.

Как выбрать SSO / 2FA-решение для компании

При выборе SSO- и 2FA-решений компании часто сравнивают только список поддерживаемых методов аутентификации: есть ли push, TOTP или биометрия. Но на практике проблемы могут возникать не из-за самих методов 2FA, а из-за несовместимости решения с инфраструктурой. Поэтому в первую очередь важно проверить, поддерживает ли система:

• Active Directory и LDAP;
• SAML, OAuth 2.0 и OpenID Connect;
• VPN, RDP и веб-приложения;
• Linux- и Windows-инфраструктуру;
• работу с legacy-системами.

Например, если 2FA-сервис хорошо работает с облачными приложениями, но не умеет интегрироваться с внутренним VPN или терминальным доступом, компании придется поддерживать несколько отдельных схем авторизации одновременно. В итоге вместо единого входа SSO появляется новый набор разрозненных доступов.

Для корпоративной среды также важны:

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

Отдельно стоит оценивать сценарии администрирования. Хорошая SSO / 2FA-система должна не только защищать вход сотрудников, но и упрощать работу IT- и ИБ-командам: быстро подключать новые сервисы, централизованно отключать доступы и управлять политиками безопасности без ручной настройки каждой системы.

В 2025–2026 годах многие компании также обращают внимание на российские SSO- и 2FA-решения — особенно если инфраструктура связана с импортозамещением, локальным размещением сервисов или внутренними требованиями к хранению данных.

При сравнении провайдеров полезно заранее ответить на несколько практических вопросов:

• Сколько корпоративных систем нужно подключить к SSO?
• Есть ли в инфраструктуре legacy-приложения?
• Нужен ли удаленный доступ подрядчиков?
• Где будут работать сотрудники — только внутри офиса или из внешних сетей?
• Нужен ли контроль действий администраторов?

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

Как SSO и 2FA защищают корпоративные учетные записи

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

Большинство атак на корпоративные системы начинаются именно с учетной записи сотрудника:

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

Если в компании нет 2FA, злоумышленнику часто достаточно одной связки логин-пароль для входа в почту, VPN или внутренние сервисы.

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

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

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

Дополнительную защиту дают политики безопасности:

• запрет входа из определенных стран, необычных локаций или сетей;
• ограничение доступа по времени;
• обязательная 2FA для администраторов;
• повторная проверка личности при рискованных действиях, например изменение настроек безопасности, сброс MFA или получение повышенных привилегий.

При этом важно понимать: SSO и 2FA не работают как «волшебная кнопка безопасности». Если учетные записи не контролируются, сотрудники используют общие аккаунты, а подрядчики месяцами сохраняют ненужные доступы, даже хорошая система аутентификации не устранит риски полностью. Поэтому эффективная защита обычно строится сразу на нескольких уровнях:

• единый вход SSO;
• многофакторная аутентификация;
• контроль привилегированных доступов;
• аудит действий пользователей;
• регулярный пересмотр прав доступа.

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

Реклама 16+

Единый журнал входов и централизованные политики

SSO дает ИТ контроль над аутентификацией во всех сервисах.

Подробнее

Заключение

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