Что такое SSO и как его настроить в корпоративной среде
Сотрудник приходит на работу и за утро вводит пароль восемь раз: при входе в Windows, в корпоративную почту, в CRM, в систему документооборота, в таск-трекер, в облачное хранилище, в корпоративный мессенджер и в систему учёта рабочего времени. Каждый раз — отдельный логин, отдельный пароль. При этом половину он уже не помнит и сохранил в браузере.
Это не только раздражает. Это реальная проблема безопасности: чем больше паролей, тем выше вероятность слабых, повторяющихся или записанных в небезопасных местах.
SSO решает эту проблему. Сотрудник входит один раз — и получает доступ ко всем системам без повторной аутентификации.
Что такое SSO
SSO расшифровывается как Single Sign-On — единый вход. Это механизм аутентификации, при котором пользователь один раз проходит проверку подлинности в центральной системе и затем получает доступ ко всем подключённым приложениям без повторного ввода логина и пароля.
Ключевой элемент SSO — провайдер идентификации (Identity Provider, IdP). Это центральная система, которая знает, кто вы, и выдаёт вам «пропуск» для доступа к другим системам. Остальные приложения называются поставщиками услуг (Service Provider, SP) — они доверяют IdP и не проверяют пользователя самостоятельно.
Когда вы открываете корпоративную CRM, она не спрашивает ваш пароль — она обращается к IdP с вопросом «этот пользователь аутентифицирован?». IdP отвечает «да, вот его токен» — и CRM пускает вас без дополнительных вопросов.
Как SSO работает технически
Существует несколько протоколов, на которых строится SSO. Важно понимать разницу между ними, потому что разные системы поддерживают разные протоколы.
SAML 2.0 (Security Assertion Markup Language) — самый распространённый протокол для корпоративного SSO. Работает на основе XML-токенов, которыми обмениваются IdP и SP. Хорошо подходит для веб-приложений и корпоративных систем. Именно SAML чаще всего имеют в виду, когда говорят «настроить SSO».
OAuth 2.0 и OpenID Connect — протоколы, более характерные для облачных сервисов и мобильных приложений. OpenID Connect построен поверх OAuth 2.0 и добавляет к нему слой аутентификации. Если вы когда-либо входили на сайт через кнопку «Войти через Google» — это OpenID Connect.
Kerberos — протокол для аутентификации внутри корпоративной сети на основе билетов. Используется в Windows-среде в связке с Active Directory. Обеспечивает SSO внутри домена без участия внешних провайдеров.
LDAP — технически не протокол SSO, а протокол для доступа к каталогу пользователей. Но в корпоративной среде LDAP и SSO тесно связаны: Active Directory на базе LDAP часто выступает источником данных для IdP.
Основные компоненты корпоративного SSO
Чтобы SSO заработал, нужны три составляющих.
Identity Provider (IdP) — провайдер идентификации. Это может быть корпоративный Active Directory с настроенными службами федерации (AD FS), облачный сервис (Keycloak, Authentik, Яндекс 360 для бизнеса) или специализированное решение. IdP хранит учётные данные пользователей и выдаёт токены аутентификации.
Service Provider (SP) — все приложения, которые подключены к SSO. Корпоративная почта, CRM, таск-трекер, менеджер паролей, система документооборота. Каждый SP настраивается на доверие конкретному IdP.
Протокол обмена — SAML, OpenID Connect или Kerberos. Определяет формат и механизм передачи токенов между IdP и SP.
Зачем SSO нужен бизнесу
Преимущества SSO выходят далеко за рамки удобства.
Снижение числа паролей — снижение рисков. Чем меньше паролей нужно помнить, тем меньше соблазна использовать слабые или повторяющиеся. Сотрудник помнит один надёжный пароль от корпоративного аккаунта — остальное берёт на себя SSO.
Централизованное управление доступами. При увольнении сотрудника достаточно заблокировать одну учётную запись в IdP — доступ ко всем подключённым системам прекращается мгновенно. Не нужно перебирать каждую систему по отдельности.
Ускорение онбординга. Новый сотрудник получает одну корпоративную учётку — и автоматически получает доступ ко всем системам, которые соответствуют его роли. Первый день проходит без часов ожидания, пока IT-отдел вручную выдаёт доступы.
Улучшение контроля и аудита. Все авторизации проходят через один IdP и фиксируются в одном журнале. Это даёт полную картину того, кто и когда входил в какие системы.
Совместимость с 2FA. SSO и двухфакторная аутентификация отлично работают вместе: пользователь один раз проходит 2FA при входе в IdP — и больше не видит запросов второго фактора при переходе между системами.
Ограничения SSO и почему нужен менеджер паролей
Здесь важный момент, который часто упускают.
SSO не охватывает все системы. В типичной компании часть сервисов не поддерживает SAML или OpenID Connect: старые внутренние системы, некоторые SaaS-сервисы, внешние сайты, сервисные аккаунты, API-ключи, SSH-данные. Для всего этого по-прежнему нужны пароли — и ими нужно как-то управлять.
Именно поэтому SSO и корпоративный менеджер паролей не конкурируют, а дополняют друг друга. SSO берёт на себя аутентификацию в системах, которые его поддерживают. Менеджер паролей закрывает всё остальное: хранит учётные данные для систем вне SSO, управляет сервисными аккаунтами, хранит API-ключи, обеспечивает безопасный шаринг паролей внутри команды.
Кроме того, менеджер паролей хранит сам корпоративный пароль от IdP — тот единственный, который сотрудник должен помнить. Если он хранится только в голове, это слабое звено: забыл, записал на стикере, использовал слабый вариант. Если хранится в менеджере паролей с мастер-ключом — проблема снимается.
Как настроить SSO в корпоративной среде: пошаговый алгоритм
Шаг 1. Выбрать Identity Provider
Выбор IdP зависит от существующей инфраструктуры.
Если в компании уже есть Active Directory, логичный путь — настроить AD FS (Active Directory Federation Services) или использовать Azure AD. Это позволяет использовать существующий каталог пользователей как основу для SSO.
Если компания работает преимущественно в Linux-среде или ищет независимое от Microsoft решение, хорошие варианты — Keycloak (открытый код, разворачивается на своём сервере) или Authentik. Оба поддерживают SAML, OpenID Connect и интеграцию с LDAP.
Для российских компаний с требованиями импортозамещения — Яндекс 360 для бизнеса или отечественные IdP-решения, совместимые с ALD Pro.
Шаг 2. Провести инвентаризацию приложений
Составьте список всех корпоративных систем и проверьте, какие из них поддерживают SSO и по какому протоколу. Большинство современных SaaS-сервисов поддерживают SAML 2.0 или OpenID Connect. Внутренние системы — по-разному.
Результат инвентаризации даст понимание: какие системы войдут в SSO сразу, какие потребуют дополнительной настройки, а какие останутся за пределами SSO и будут управляться через менеджер паролей.
Шаг 3. Настроить IdP
Независимо от выбранного IdP, основные шаги схожи.
Установить и развернуть IdP на сервере или настроить облачный сервис. Подключить IdP к корпоративному каталогу пользователей (LDAP или Active Directory) — это позволит использовать существующие учётные записи. Настроить политики аутентификации: требования к паролю, обязательность 2FA, время жизни сессии. Создать сертификаты для подписи SAML-токенов.
Шаг 4. Подключить приложения
Для каждого приложения, которое будет работать через SSO, нужно настроить доверие к IdP. В интерфейсе IdP создаётся запись для приложения (SP), генерируются метаданные в формате XML. В настройках приложения указывается URL IdP и загружаются метаданные.
В результате при попытке входа в приложение оно перенаправляет пользователя на страницу входа IdP, пользователь аутентифицируется один раз, IdP выдаёт токен, приложение принимает токен и пускает пользователя.
Шаг 5. Настроить маппинг атрибутов
SSO передаёт от IdP к приложению не только факт аутентификации, но и атрибуты пользователя: имя, email, группы, роли. Каждое приложение ожидает эти атрибуты в определённом формате.
Маппинг атрибутов настраивается в IdP: какое поле из каталога пользователей соответствует какому атрибуту в токене. Например, поле «mail» из AD маппится в атрибут «email» в SAML-ответе.
Шаг 6. Подключить корпоративный менеджер паролей
BearPass поддерживает вход через SAML SSO. После настройки сотрудники входят в менеджер паролей через тот же корпоративный аккаунт, что и во все остальные системы — без отдельного пароля от BearPass.
При этом в самом BearPass хранятся пароли от систем, не охваченных SSO, сервисные учётные записи, API-ключи и другие секреты. Таким образом, SSO и менеджер паролей вместе обеспечивают полное покрытие: ни одна система не остаётся без управляемого и аудируемого доступа.
Шаг 7. Провести тестирование
Перед тем как переводить всех сотрудников на SSO, проведите тестирование на небольшой группе. Проверьте каждое подключённое приложение, сценарий выхода из системы (logout должен завершать сессию во всех приложениях), сценарий блокировки аккаунта (блокировка в IdP должна немедленно прекращать доступ везде), корректность маппинга атрибутов и работу 2FA.
Шаг 8. Провести онбординг сотрудников
SSO меняет привычный процесс входа, поэтому сотрудники нуждаются в кратком объяснении. Достаточно короткой инструкции: как войти в первый раз, что делать если сессия истекла, куда обращаться при проблемах.
Типичные ошибки при внедрении SSO
Не настроен Single Logout. SSO обеспечивает единый вход, но без Single Logout (SLO) выход из одного приложения не завершает сессии в других. Пользователь думает, что вышел — а сессии остаются активными.
Слишком долгое время жизни сессии. Если токен действует 30 дней, сотрудник фактически не вводит пароль месяц. Удобно, но опасно — особенно при работе с чужих устройств. Оптимальное время жизни сессии для корпоративной среды — 8–12 часов.
SSO без 2FA. Единая точка входа удобна и для злоумышленника: скомпрометировав один пароль, он получает доступ ко всем системам. Обязательная 2FA при входе в IdP нейтрализует этот риск.
Неполная инвентаризация приложений. Часть систем остаётся за пределами SSO, о них «забывают», и они не попадают ни в аудит, ни в управление доступами.
Нет плана на случай недоступности IdP. Если IdP недоступен, сотрудники не могут войти ни в одну систему. Нужны процедуры аварийного доступа и обеспечение отказоустойчивости IdP.
SSO и требования регуляторов
Для российских компаний, работающих в регулируемых отраслях, внедрение SSO напрямую помогает выполнить ряд регуляторных требований.
Приказ ФСТЭК №17 и №21 требуют идентификации и аутентификации пользователей при доступе к защищаемым системам. SSO обеспечивает единую точку аутентификации с журналом всех входов.
ГОСТ Р 57580.1 для финансовых организаций требует разграничения доступа на основе ролей и контроля привилегированных учётных записей. SSO в связке с RBAC в менеджере паролей закрывает оба требования.
152-ФЗ требует документировать меры по защите персональных данных. Централизованная аутентификация через IdP с журналом событий — весомый аргумент при проверке регулятора.
Итог
SSO избавляет сотрудников от необходимости помнить и вводить десятки паролей, даёт IT-отделу централизованное управление доступами и обеспечивает полный аудит авторизаций. При увольнении сотрудника блокировка одной учётной записи мгновенно закрывает доступ ко всем подключённым системам.
При этом SSO не охватывает всю инфраструктуру: системы без поддержки SAML, сервисные аккаунты, API-ключи и внешние сервисы по-прежнему требуют управления паролями. Именно здесь в связку входит корпоративный менеджер паролей — он закрывает то, что SSO не охватывает, и сам работает через SSO для удобного входа сотрудников.
BearPass поддерживает интеграцию через SAML SSO и LDAP, разворачивается на серверах компании и входит в Реестр отечественного ПО. Попробуйте бесплатно или запросите демо.
