SSO и федерация идентичности: почему пользователей надо сводить, а не плодить
Чем больше систем в компании, тем дороже хаос в учётных записях. Как централизация аутентификации снижает и операционные расходы, и поверхность атаки.
У большинства компаний среднего размера нет единой картины того, кто и к чему имеет доступ. Есть Active Directory для корпоративной почты, отдельные логины в CRM, отдельные в ERP, несколько SaaS-инструментов с собственными учётными записями и пара самописных систем с таблицей пользователей в базе данных.
Каждая из этих систем живёт своей жизнью. Когда сотрудник увольняется, его отключают там, где вспомнят. Когда приходит новый - заводят там, где попросят. Это не злой умысел, это просто то, как оно растёт само по себе.
Что стоит за этим хаосом
Размытая идентичность - это не только неудобство для IT-отдела. Это реальный операционный и безопасностный риск.
Несколько конкретных проблем, которые я вижу в таких средах:
- Уволенный сотрудник сохраняет доступ к одной или нескольким системам, потому что об этой учётной записи никто не вспомнил. Та же проблема касается удалённых подрядчиков, которые формируют отдельный периметр риска.
- Пароли между системами синхронизируются неформально - люди ставят одинаковые, потому что иначе невозможно запомнить. Если одна система скомпрометирована, риск распространяется дальше.
- Аудит того, кто что делал, невозможен в полной мере - журналы разбросаны по разным системам и никем не сводятся.
- Онбординг новых сотрудников превращается в ручной чеклист из 15 пунктов, половина которых забывается.
Что такое SSO и федерация
Single Sign-On - это когда пользователь аутентифицируется один раз в одном месте, а все остальные системы доверяют этой аутентификации. Вариантов реализации несколько - SAML, OAuth, OpenID Connect - но суть одна: есть один источник истины об идентичности, и остальные системы к нему подключены.
Федерация идёт немного дальше: это способность нескольких независимых доменов идентичности доверять друг другу. Например, сотрудники подрядчика могут работать в системах заказчика без заведения отдельных аккаунтов - их организация удостоверяет их идентичность, а ваша система это принимает.
Для большинства компаний уровень "зрелой федерации" - это пока горизонт. Но базовый SSO внутри собственной инфраструктуры - это практическая задача, которую можно решить уже сейчас.
Что меняется, когда идентичность централизована
Эффект не только в удобстве входа. Централизация идентичности меняет несколько вещей сразу:
Увольнение сотрудника становится одним действием. Отключил центральную учётную запись - потерян доступ везде, где использовался SSO. Это не нулевой риск, но это радикально лучше, чем ручной обход двенадцати систем.
Политика паролей и многофакторная аутентификация применяются в одном месте и работают везде. Не надо добиваться от каждой системы поддержки нужных настроек.
Журналы аутентификации сводятся. Когда что-то происходит, у вас есть единая история входов - кто, когда, с какого устройства.
Онбординг упрощается: добавить пользователя в группы в центральном каталоге - это одна операция с предсказуемым результатом.
Где начинать
Перевести всё разом не получится. Разумный порядок:
- Определить, какие системы поддерживают SAML или OAuth уже сейчас - большинство корпоративных SaaS это умеют.
- Поднять или зафиксировать Identity Provider - Microsoft AD FS, Google Workspace, или одно из специализированных решений.
- Подключить системы одну за другой, начиная с самых критичных и самых посещаемых.
- Прописать процедуры: что происходит при найме, увольнении, смене роли.
Вопросы для аудита своей ситуации
- Сколько систем в вашей компании имеют собственную базу пользователей?
- Есть ли у вас актуальный список того, к чему имеет доступ каждый сотрудник?
- Как долго занимает полное отключение уволенного сотрудника от всех систем?
- Кто последний раз смотрел на "мёртвые" учётные записи - те, которыми не пользуются несколько месяцев?
Если ответы неудобные - это не повод для паники, это повод для плана.