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

Разговор о SSO в российских компаниях актуален не только из-за удобства пользователей. Чем больше корпоративных сервисов работает с отдельными учётными записями, тем выше риск повторного использования паролей и тем сложнее контролировать жизненный цикл доступа. По данным BI.ZONE, в среднем и крупном бизнесе на одного ИТ-специалиста приходится от трёх до семи привилегированных учётных записей, а 30–40% таких аккаунтов используют одинаковые пароли в разных системах. Кроме того, в 60% организаций, пострадавших от атак в 2025 году, сотрудники использовали один и тот же пароль для доступа к нескольким рабочим сервисам.

Единый вход часто продают как понятную идею: сотрудник один раз проходит аутентификацию и затем работает со всеми корпоративными сервисами без новых паролей. В презентации это выглядит просто. В реальной инфраструктуре — заметно сложнее. Когда мы начинали строить SSO, казалось, что главный вопрос — какой протокол выбрать: SAML или OIDC. Но очень быстро стало понятно, что это самая простая часть, и вопрос стандарта давно решён. Самое сложное — это системы, которые живут вне этих протоколов. Реальная сложность SSO — не передать токен, а объяснить старой АБС или кассовому ПО, что этот токен вообще существует. Федерация идентичности с «непротокольными» системами — вот где зарыта собака: где-то нужно проксировать заголовки, где-то — ставить агентов, а где-то — честно признать, что единого входа здесь не будет.

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

Я — Антон Букарев, руководитель отдела продаж продукта MULTIFACTOR SSO компании МУЛЬТИФАКТОР, расскажу о сквозной авторизации. Что реально удаётся подключить к единому входу, а что остаётся жить с отдельными паролями, и почему это нормально.

Сначала — инвентаризация, а не выбор IdP

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

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

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

Три зоны корпоративного ландшафта

Если представить ИТ-инфраструктуру средней российской компании как карту, то она делится на три достаточно чёткие зоны. В первой — всё относительно безболезненно. Во второй — больно, но решаемо. В третьей — проще смириться, чем бороться.

Зелёная зона: современные системы

Сюда попадают корпоративные порталы, HR-системы, современные версии Service Desk, корпоративные мессенджеры, Git-платформы, B2B-кабинеты. Это софт, который разрабатывался в последние пять-семь лет, и чьи вендоры понимают, что без поддержки OIDC или SAML на рынок выходить уже неприлично.

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

Жёлтая зона: legacy и специфический софт

Самая интересная территория. Здесь живут 1С старых конфигураций, банковские АБС, SCADA-системы, кассовое ПО, самописные порталы на древних стеках. Эти системы не знают про OIDC. Более того, многие из них вообще не понимают, что такое федерация. У них есть своя табличка пользователей, свой механизм хэширования паролей и своя сессия.

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

1. LDAP-мосты. Если система умеет ходить в LDAP, мы подключаем её к каталогу. Это не SSO в чистом виде: сессия не передаётся, каждый вход — отдельная проверка учётки. Но пароль становится единым. Пользователь вводит одни и те же данные везде, смена пароля происходит централизованно. В нашей практике для решения этой задачи мы используем модуль LDAP-моста в системе MULTIFACTOR. Он принимает аутентификационные запросы от legacy-систем, которые умеют только LDAP, и транслирует их в единый каталог.
2. Проксирование заголовков. Если у legacy-системы есть веб-интерфейс, перед ней можно поставить reverse proxy, который перехватывает запрос, проверяет токен и передаёт приложению заголовок с именем пользователя. Приложение думает, что аутентификация уже произошла. У нас эта задача решается через встроенный reverse proxy: он проверяет токен до того, как запрос попадёт в саму систему. Приложение получает уже проверенный заголовок и дальше работает как обычно.
3. Агенты на рабочих станциях. Для толстых клиентов, которые не поддерживают ни OIDC, ни LDAP, могут использоваться агенты, перехватывающие окна ввода логина и пароля и автоматически подставляющие учётные данные. Технически это не SSO в строгом смысле, а автоматизация управления паролями. Однако для пользователя разница практически незаметна: он проходит первичную аутентификацию при входе на рабочую станцию, а дальнейшие учётные данные для подключённых приложений подставляются автоматически.

Отдельная боль этой зоны — сервисные учётные записи. Даже если мы закрыли SSO для людей, остаются интеграции, боты, M2M-обмены. Стандарт здесь — Client Credentials Flow в OAuth 2.0. Но у многих систем есть «сервисный логин» и «сервисный пароль», который зашит в конфиг и не менялся с момента установки.

Красная зона: что подключить не получится

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

Однако в этой части речь уже идёт не столько о классическом SSO, сколько об управлении инфраструктурным, привилегированным и межсистемным доступом. Поэтому тут я передаю слово моему коллеге Ивану Дёмкину, который руководит продуктом MULTIFACTOR в нашей компании.

«Сетевое оборудование — коммутаторы, маршрутизаторы, межсетевые экраны, — промышленные контроллеры, принтеры, изолированные сегменты и системные учётные записи сервисов для M2M-взаимодействия не рассчитаны на классический веб-SSO с браузерными редиректами. Их защита строится на других протоколах и инструментах. Для инфраструктурного доступа сетевые устройства и VPN-шлюзы подключаются к централизованному каталогу через связку RADIUS/TACACS+ с обязательным использованием многофакторной аутентификации. Привилегированные и сервисные учетные записи: доступ администраторов к технологическим серверам и базам данных выносится в PAM-контур с выдачей одноразовых доступов, ротацией паролей и строгим аудитом действий. А для M2M- и межсервисных интеграций жёстко зашитые в конфигурации пароли следует переводить на OAuth 2.0 Client Credentials либо изолировать в защищённых хранилищах секретов», — отмечает Иван Дёмкин, руководитель продукта MULTIFACTOR, компания МУЛЬТИФАКТОР.

Сначала порядок в каталоге, потом SSO

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

Поэтому правильный порядок такой: сначала наводим порядок в HR-источнике — 1С ЗУП или его аналоге. Потом настраиваем IDM, который раздаёт атрибуты и роли в каталог. И только потом подключаем SSO. Без этого фундамента единый вход превращается в бардак.

Когда мы приходим в компанию, то обычно начинаем не с внедрения SSO, а с разбора того, что вообще есть. Наша система позволяет подключать приложения по мере их готовности: современные — через OIDC, legacy — через LDAP-мост или прокси, а то, что не подключается, — через PAM.

Мобильный доступ и личные устройства

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

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

В MULTIFACTOR такие правила могут применяться вместе с федеративной аутентификацией. Это позволяет не ставить одинаковые барьеры для всех сервисов: доступ к корпоративной новостной ленте и к финансовой системе объективно требуют разного уровня контроля.

Что считать результатом SSO-проекта

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

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

MULTIFACTOR SSO может использоваться как единая точка входа для современных приложений, поддерживающих стандартные протоколы, и как часть более широкого контура управления доступом для legacy-систем. В зависимости от возможностей приложения применяются федерация, LDAP-мост, reverse proxy или отдельные средства управления привилегированными и сервисными учётными записями. Это позволяет не выбирать между идеальной архитектурой и текущей реальностью, а последовательно сокращать число разрозненных механизмов входа.

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

Используемые термины

SSO (Single Sign-On) — единый вход.

SAML (Security Assertion Markup Language) — язык разметки утверждений безопасности.

OIDC (OpenID Connect) — открытое подключение идентичности.

Токен — цифровой объект, который подтверждает результат аутентификации или содержит разрешение на выполнение определённых действий.

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

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

IdP (Identity Provider) — поставщик идентификации.

HR-система (Human Resources) — система управления персоналом.

Service Desk — система обработки заявок и поддержки пользователей.

Git-платформа — платформа управления исходным кодом.

B2B-кабинет (Business-to-Business cabinet) — личный кабинет для организаций.

Discovery-документ — документ обнаружения конфигурации.

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

Legacy-системы — действующие, но технологически устаревшие приложения или программно-аппаратные комплексы.

SCADA (Supervisory Control and Data Acquisition) — система диспетчерского управления и сбора данных.

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

LDAP (Lightweight Directory Access Protocol) — протокол облегчённого доступа к каталогам.

Учётка (учётная запись) — совокупность сведений, которые идентифицируют пользователя, устройство или сервис в информационной системе и связывают их с правами доступа.

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

Reverse proxy — обратный прокси-сервер.

M2M (Machine-to-Machine) — межмашинный обмен.

Поток учётных данных клиента в OAuth 2.0 (Client Credentials Flow) — сценарий, при котором сервис или приложение получает маркер доступа от своего имени, используя собственные учётные данные, а не данные конкретного пользователя.

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

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

IP-камера — видеокамера, подключаемая к компьютерной сети по интернет-протоколу (IP, Internet Protocol) и передающая данные через сеть.

Веб-SSO — единый вход для веб-приложений.

Редирект (redirect) — перенаправление.

VPN-шлюз (Virtual Private Network gateway) — сетевое устройство или программный компонент, который обеспечивает защищённое подключение пользователя или удалённой сети к корпоративной инфраструктуре через VPN.

RADIUS (Remote Authentication Dial-In User Service) — служба удалённой аутентификации пользователей по коммутируемым линиям.

TACACS+ (Terminal Access Controller Access-Control System Plus) — система управления доступом к сетевым устройствам.

PAM-контур (Privileged Access Management) — контур управления привилегированным доступом.

Межсервисные интеграции — автоматическое взаимодействие между программными системами, при котором одна система передаёт или получает данные от другой через API, очереди сообщений, файлы или иные способы обмена.

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

IDM (Identity Management) — управление идентификационными данными.

MFA (Multi-Factor Authentication) — многофакторная аутентификация.