В компании быстро накапливаются десятки мест, куда сотрудник входит под своим аккаунтом: почта, CRM, облачное хранилище, таск-трекер, Git, база знаний, VPN, BI-система, внутренние панели и сервисы подрядчиков. Если у каждого приложения свой логин и пароль, доступы начинают жить отдельно друг от друга. Один пароль забыли отключить, второй повторили в нескольких сервисах, третий сохранили в браузере, четвертый знает только сотрудник, который уже уволился.
SSO, или единый вход, убирает эту разрозненность. Пользователь проходит проверку через корпоративного провайдера идентификации, а подключенные сервисы принимают результат этой проверки. Приложения не получают пароль сотрудника и не хранят его у себя. Они доверяют системе, которая отвечает за учетные записи, MFA, группы, роли и правила входа. Ниже рассказала подробнее, как всё устроено.
Что такое SSO и чем он отличается от обычного входа
При обычной авторизации каждое приложение проверяет пользователя самостоятельно. У почты своя база учетных записей, у CRM своя, у внутренней панели своя. Администратор должен отдельно создать пользователя, выдать права, включить или выключить доступ, а потом не забыть повторить то же самое в других системах.
В SSO проверку переносит на себя провайдер идентификации. Его часто называют IdP. Это может быть Microsoft Entra ID, Keycloak, Active Directory Federation Services или другой сервис управления учетными записями. Приложение в этой схеме называется сервис-провайдером: оно не проверяет пароль, а принимает подписанное подтверждение от IdP.
Такой подход особенно важен при увольнении, смене должности и работе с подрядчиками. Если учетная запись отключена у провайдера идентификации, человек теряет доступ к подключенным сервисам. Если сотрудник переходит из отдела продаж в финансовый отдел, права можно менять через группы и роли, а не вручную в каждом приложении.
SSO не заменяет парольный менеджер. Парольный менеджер хранит разные пароли и помогает не повторять их. Единый вход меняет саму схему доступа: сотрудник проходит проверку в одном месте, а приложения получают результат этой проверки. В нормальной корпоративной схеме эти инструменты не мешают друг другу. SSO закрывает основные рабочие сервисы, а парольный менеджер остается для редких учетных записей, аварийных доступов и систем без поддержки единого входа.
Как проходит вход через SSO
Снаружи процесс выглядит просто: сотрудник открывает сервис и выбирает вход через корпоративный аккаунт. Внутри происходит несколько проверок. Сервис отправляет пользователя к провайдеру идентификации, провайдер проверяет учетную запись, пароль, второй фактор, устройство, IP-адрес, группу или роль, а затем возвращает приложению защищенный ответ.
- Пользователь открывает корпоративный сервис.
- Сервис понимает, что локальной сессии нет, и перенаправляет пользователя к IdP.
- IdP проверяет учетную запись и применяет политики входа: MFA, устройство, сеть, роль, группу.
- После успешной проверки IdP выпускает ответ для приложения.
- Приложение проверяет подпись, срок действия, адрес возврата и атрибуты пользователя.
- Если все корректно, сервис создает сессию и открывает доступ.
Важная деталь: приложение получает не пароль, а подтверждение личности. В SAML это подписанное assertion, в OpenID Connect - ID token. В ответе обычно есть идентификатор пользователя, адрес электронной почты, имя, группы или другие атрибуты. По ним сервис понимает, кого пустить и какие права выдать.
Ошибки в этой схеме часто связаны не с самим SSO, а с настройками. Например, неправильно указан адрес возврата, не проверяется подпись, слишком долго живут токены, не синхронизируются группы или после миграции остается старый вход по локальному паролю. Поэтому внедрение SSO нельзя сводить к обмену метаданными между двумя системами.
SAML, OpenID Connect и OAuth 2.0: где часто путаются
В заявках и договорах часто пишут поддержку OAuth, хотя компании нужен вход сотрудников через корпоративный аккаунт. OAuth 2.0 сам по себе решает другую задачу: он позволяет одному приложению получить ограниченный доступ к ресурсу от имени пользователя или сервиса. Для входа пользователя поверх OAuth 2.0 используют OpenID Connect.
| Технология | Зачем используется | Что уточнить у поставщика |
|---|---|---|
| SAML 2.0 | Корпоративный веб-вход через подписанный ответ от IdP | Поддержку SP-initiated входа, сертификаты, атрибуты, Single Logout |
| OpenID Connect | Вход пользователя в веб-приложения, мобильные клиенты и новые сервисы | Redirect URI, ID token, refresh token, срок жизни сессии |
| OAuth 2.0 | Делегированный доступ к API и ресурсам | Области доступа, отзыв токенов, хранение client secret |
Если компания покупает SaaS, формулировка должна быть конкретной: нужен SAML SSO или OpenID Connect для входа пользователей. Иначе можно получить интеграцию для API, но не получить нормальную авторизацию сотрудников через корпоративную учетную запись.
Что SSO дает корпоративной безопасности
Главный эффект SSO - централизованное управление доступом. Администратор работает с одной учетной записью сотрудника, а не с набором разрозненных логинов в разных сервисах. Это ускоряет прием на работу, перевод между отделами и отключение доступа после увольнения.
| Проблема без SSO | Как помогает единый вход | Что все равно нужно контролировать |
|---|---|---|
| Пароли повторяются в разных сервисах | Пользователь входит через корпоративную учетную запись | MFA, фишинг, защита самого IdP |
| После увольнения доступы ищут вручную | Отключение учетной записи закрывает вход в подключенные системы | Локальные аккаунты, API-ключи, сервисные пользователи |
| У каждого сервиса свои журналы входа | События авторизации можно собирать централизованно | Срок хранения логов и передача в SIEM |
| Права выдаются вручную и забываются | Доступ можно привязать к группам и ролям | Владельцев групп и регулярный пересмотр прав |
SSO особенно полезен для компаний с удаленными сотрудниками, подрядчиками и большим числом облачных сервисов. Но единый вход не отменяет другие меры защиты. Нужны MFA, контроль администраторов, отдельные аварийные учетные записи, мониторинг входов, резервирование IdP и понятная процедура восстановления.
Где SSO может создать новые риски
Провайдер единого входа становится критичной системой. Если он недоступен, пользователи не смогут открыть сервисы, где нет активной сессии. Если злоумышленник получит доступ к администраторской учетной записи IdP, он сможет менять правила входа, добавлять приложения, выдавать права и обходить обычные ограничения.
Еще один риск - старые способы входа. После подключения SSO некоторые сервисы продолжают принимать локальные пароли. Пользователь вроде входит через корпоративный аккаунт, но в приложении остается отдельный пароль, о котором забыли. При инциденте такой запасной вход легко пропустить.
Отдельно стоит проверить сервисные учетные записи и API-ключи. SSO управляет входом людей, но не всегда закрывает доступы, которыми пользуются интеграции, скрипты, роботы и технические процессы. Если сотрудник создал личный API-ключ для выгрузки данных, отключение его SSO-аккаунта может не отозвать этот ключ автоматически.
- включайте MFA для администраторов IdP без исключений;
- ограничивайте доступ к панели управления по ролям;
- храните аварийные учетные записи отдельно и проверяйте их по регламенту;
- отключайте локальный вход после миграции, если сервис это поддерживает;
- проверяйте API-ключи, токены и сервисные аккаунты при увольнении сотрудников.
Какие решения смотреть в 2026 году
Выбор зависит от уже используемых сервисов и требований к размещению. Если компания работает в Microsoft 365, Teams, SharePoint и Windows-инфраструктуре, обычно рассматривают Microsoft Entra ID. У него много готовых корпоративных интеграций, MFA, условный доступ и управление приложениями.
Для собственной инфраструктуры часто выбирают Keycloak. Он поддерживает OpenID Connect, OAuth 2.0 и SAML, умеет работать с LDAP и Active Directory, поддерживает роли, группы и внешних провайдеров входа. Плюс Keycloak в гибкости и контроле над размещением. Минус - систему нужно самостоятельно обновлять, резервировать, мониторить и защищать.
В российских сервисах поддержку единого входа лучше проверять по документации конкретного поставщика и тарифу. В Яндекс 360 для бизнеса SSO настраивается через SAML 2.0. У Контур.SSO описан вход в продукты Контура через корпоративных провайдеров аутентификации.
Как внедрять SSO без лишних ошибок
Начинать стоит с инвентаризации. Нужно составить список сервисов, владельцев, способов входа, локальных администраторов, сервисных учетных записей и API-ключей. Без такой таблицы легко подключить SSO для видимых приложений и забыть про старые панели, тестовые аккаунты и интеграции.
- Соберите список сервисов. Укажите владельца, критичность, способ входа и поддержку SAML или OpenID Connect.
- Определите источник пользователей. Данные должны приходить из актуального каталога, LDAP, Active Directory или кадровой системы.
- Настройте группы и роли. Приложения должны получать понятные атрибуты без ручных правок после каждого перевода сотрудника.
- Включите MFA до массового запуска. Единый вход без второго фактора плохо защищает от фишинга и кражи пароля.
- Проведите пилот. Начните с одного сервиса и небольшой группы сотрудников, проверьте вход, выход, роли и журналирование.
- Закройте обходные входы. После проверки отключите локальные пароли, удалите лишние админские аккаунты и пересмотрите API-ключи.
После запуска SSO нужно проверять права регулярно. Владелец сервиса должен подтверждать, кто имеет доступ, какие группы используются и какие учетные записи больше не нужны. Без такого пересмотра единый вход быстро превращается в аккуратную витрину поверх старого беспорядка.
FAQ: пять вопросов про SSO
SSO заменяет MFA?
Нет. SSO централизует вход, а MFA добавляет второй фактор проверки. Для корпоративных сервисов их лучше включать вместе.
SSO заменяет парольный менеджер?
Нет. Парольный менеджер хранит разные пароли, а SSO позволяет приложениям доверять проверке пользователя у корпоративного провайдера входа.
Что лучше выбрать: SAML или OpenID Connect?
Для зрелых корпоративных веб-сервисов часто используют SAML 2.0. Для новых веб-приложений, мобильных клиентов и API обычно удобнее OpenID Connect. Безопасность зависит не от названия протокола, а от настройки.
Что произойдет, если провайдер SSO перестанет работать?
Новые входы могут остановиться, а уже открытые сессии будут работать до истечения срока. Поэтому IdP нужно резервировать, мониторить и заранее готовить аварийный доступ.
С чего начать внедрение SSO?
Начните со списка сервисов, способов входа, локальных администраторов и API-ключей. После этого выберите IdP, включите MFA, проведите пилот и только затем переносите остальные приложения.
