SSO

SSO, или Single Sign-On, — технология единого входа, которая позволяет пользователю один раз пройти аутентификацию и затем получать доступ к нескольким корпоративным приложениям без повторного ввода логина и пароля в каждом из них.

Вместо десятков отдельных учетных записей и независимых процедур входа компания использует центральный Identity Provider. Он подтверждает личность пользователя, а подключенные приложения доверяют результату этой проверки.

SSO широко используется в корпоративных порталах, SaaS-сервисах, CRM, Service Desk, облачных платформах, системах документооборота и других приложениях.

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

Что такое SSO простыми словами

Без единого входа сотрудник может иметь отдельные Credentials для каждой системы:

CRM → отдельный login
Wiki → отдельный login
Service Desk → отдельный login
Cloud → отдельный login
HR system → отдельный login

При использовании SSO схема меняется:

User
↓
Identity Provider
↓
CRM / Wiki / Service Desk / Cloud / HR

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

Расшифровка SSO

SSO расшифровывается как Single Sign-On — единый вход.

Основная идея заключается в повторном использовании уже подтвержденной Identity для доступа к нескольким доверяющим приложениям.

Для чего нужен SSO

SSO решает сразу несколько задач:

• уменьшает количество паролей;
• упрощает вход сотрудников;
• централизует Authentication;
• позволяет единообразно применять MFA;
• упрощает отключение доступа после увольнения;
• снижает нагрузку на Service Desk;
• улучшает аудит входов;
• помогает централизованно управлять Security Policies.

Как работает SSO

Упрощенная схема выглядит так:

User opens application
↓
Application redirects to IdP
↓
User authenticates
↓
IdP confirms identity
↓
Application creates session

Если пользователь уже имеет активную Session у Identity Provider, повторный ввод Password может не потребоваться.

Identity Provider

Identity Provider, или IdP, — система, которая выполняет Authentication пользователя и предоставляет другим приложениям подтверждение его Identity.

IdP может дополнительно применять:

• MFA;
• Conditional Access;
• Device Trust;
• Risk-based Authentication;
• Password Policy;
• Session Policy.

Service Provider

Service Provider, или SP, — приложение, которое доверяет результату Authentication от Identity Provider.

Например, CRM не проверяет корпоративный Password самостоятельно, а принимает утверждение о том, что пользователь уже прошел проверку у IdP.

SSO и Authentication

Authentication отвечает на вопрос: кто пользователь?

SSO позволяет выполнять эту проверку централизованно.

После успешного подтверждения Identity пользователь может переходить между подключенными системами без постоянного повторного ввода Credentials.

SSO и Authorization

SSO не обязательно определяет, что пользователь может делать внутри приложения.

Например, два сотрудника успешно входят через один IdP, но один имеет Role Manager, а другой — Viewer.

Authentication → IdP
Authorization → Application / IAM policy

Поэтому единый вход и управление правами доступа необходимо различать.

SSO и IAM

SSO является одной из функций Identity and Access Management.

IAM охватывает более широкий круг задач:

• Identity Lifecycle;
• Provisioning;
• Deprovisioning;
• Roles;
• Access Reviews;
• MFA;
• SSO.

Таким образом, SSO — важный, но не единственный компонент IAM.

SSO и MFA

Одно из главных преимуществ SSO — возможность централизованно включить Multi-Factor Authentication.

Вместо настройки второго фактора отдельно в десятках приложений компания может применять его на уровне Identity Provider.

User
↓ Password + MFA
IdP
↓
Multiple applications

Почему MFA особенно важна при SSO

SSO повышает удобство, но одновременно делает центральную Identity более ценной целью.

Если злоумышленник получает доступ к основной SSO Session, ему потенциально могут быть доступны сразу несколько приложений.

Поэтому центральную учетную запись желательно защищать MFA и другими Identity Security Controls.

SSO и 2FA

Двухфакторную Authentication можно применять непосредственно при входе в Identity Provider.

После успешной 2FA подключенные приложения принимают результат Authentication, если их Policies это допускают.

Federation

SSO часто строится на Identity Federation.

Federation позволяет одному приложению доверять Identity, подтвержденной другой системой.

Например, внешний SaaS доверяет корпоративному IdP компании.

SAML

SAML является одним из распространенных протоколов корпоративного Web SSO.

Схема упрощенно выглядит так:

User → Service Provider
↓ redirect
Identity Provider
↓ authentication
SAML assertion
↓
Service Provider

Приложение получает утверждение о пользователе и создает локальную Session.

SAML Assertion

SAML Assertion содержит информацию, подтверждающую Authentication пользователя и может включать его Attributes.

Например:

User: ivan.petrov@example.com
Department: Finance
Role: Employee

Получатель должен проверять подпись и другие параметры Assertion согласно конфигурации доверия.

OpenID Connect

OpenID Connect широко используется для Authentication современных Web и Mobile Applications.

Он строится поверх OAuth-подобной инфраструктуры и предоставляет приложению информацию о подтвержденной Identity пользователя.

OAuth и SSO

OAuth прежде всего предназначен для Delegated Authorization, а не для классической пользовательской Authentication.

Для реализации Login обычно используют OpenID Connect или другой Identity Protocol поверх соответствующей инфраструктуры.

ID Token

В OpenID Connect приложение может получить ID Token с информацией о результате Authentication и пользователе.

Приложение должно корректно проверять его подпись, Issuer, Audience, срок действия и другие необходимые параметры.

Access Token

Access Token предназначен для доступа к API или Resource Server.

Его не следует автоматически считать прямой заменой ID Token для всех сценариев Authentication.

Session в SSO

При SSO могут существовать как минимум две Session:

• Session у Identity Provider;
• локальная Session в конкретном приложении.

Это важно для правильного Logout и отзыва доступа.

Как пользователь входит без повторного пароля

Когда второе приложение перенаправляет пользователя к IdP, центральная система обнаруживает уже активную Session.

Если Security Policy не требует повторной Authentication, IdP сразу подтверждает Identity.

SSO и Password

SSO не означает, что один пароль передается всем приложениям.

В правильно построенной Federation Service Provider обычно не получает корпоративный Password пользователя вообще.

Password вводится только на доверенной странице Identity Provider.

Почему это безопаснее множества отдельных паролей

При централизованной Authentication приложение не обязано самостоятельно хранить пользовательские Password Hash и реализовывать сложный Login Flow.

Организация может сосредоточить сильные меры защиты вокруг IdP.

SSO и Password Manager

Password Manager и SSO решают разные задачи.

Password Manager хранит Credentials для сервисов, а SSO позволяет приложениям доверять центральной Authentication без отдельного Password для каждого входа.

Enterprise SSO

Корпоративный SSO обычно объединяет SaaS, внутренние Web Applications и Cloud Services вокруг одного Identity Provider.

Так сотрудник использует единую корпоративную Identity.

Web SSO

Web SSO работает с Browser Applications через Redirect, Cookies, Tokens и Federation Protocols.

Это наиболее распространенный современный сценарий единого входа.

Desktop SSO

В корпоративной среде Desktop Applications также могут использовать уже подтвержденную Identity операционной системы или центрального IdP.

Конкретный механизм зависит от платформы и приложения.

SSO и Active Directory

Active Directory может быть источником корпоративных Identities и участвовать в SSO.

Но само понятие SSO шире одной Directory Technology и может включать Cloud Identity Provider и внешние SaaS Services.

SSO и LDAP

LDAP может использоваться приложением для доступа к Directory, но простая проверка Password через LDAP еще не означает полноценный SSO.

Если каждое приложение отдельно спрашивает Password и проверяет его в Directory, пользователь все равно выполняет отдельный Login.

SSO и Kerberos

В доменной инфраструктуре Kerberos позволяет пользователю получать доступ к совместимым ресурсам без повторного ввода Password для каждого сервиса.

Это один из классических механизмов Single Sign-On во внутренних корпоративных сетях.

Ticket в Kerberos

После Authentication пользователь получает специальные Credentials, которые используются для доступа к отдельным Services.

Пароль при этом не требуется передавать каждому серверу заново.

SSO и SaaS

Для бизнеса один из наиболее полезных сценариев — подключение внешних SaaS Applications к корпоративному IdP.

Например:

Corporate IdP
↓
CRM
Project tracker
HR platform
Service Desk
Cloud storage

Преимущества SSO для SaaS

При увольнении сотрудника можно заблокировать центральную Identity, после чего доступ к множеству подключенных приложений прекращается или ограничивается согласно их интеграции и Session Policy.

Это значительно надежнее ручного поиска отдельных Accounts.

SSO и Provisioning

Сам SSO не всегда создает Account внутри приложения.

Для автоматического создания и удаления пользователей дополнительно могут использоваться Provisioning Mechanisms, например SCIM или API.

Just-in-Time Provisioning

Некоторые приложения создают локальную учетную запись при первом успешном SSO Login.

Это называют Just-in-Time Provisioning.

Подход упрощает создание Accounts, но нужно отдельно продумать их последующее удаление и изменение доступа.

SCIM и SSO

SCIM дополняет SSO автоматическим управлением Users и Groups.

SSO → authentication
SCIM → provisioning and deprovisioning

Вместе эти механизмы позволяют централизовать жизненный цикл SaaS Accounts.

SSO и Deprovisioning

После увольнения сотрудника недостаточно только запретить новый Login.

Нужно также учитывать:

• активные Sessions;
• Refresh Tokens;
• локальные Accounts;
• API Keys;
• Application-specific Credentials.

Single Logout

Single Logout пытается завершить связанные Sessions сразу в нескольких приложениях.

На практике его поддержка и поведение зависят от используемых протоколов и конкретных систем.

Почему Logout сложнее Login

После SSO каждое приложение может создать собственную локальную Session.

Закрытие Session у IdP не всегда автоматически завершает уже существующие Sessions во всех приложениях.

Session Revocation

При компрометации Account важно иметь возможность отозвать активные Sessions и Tokens.

Одной смены Password может быть недостаточно.

SSO и Conditional Access

Центральный IdP может применять правила доступа на основании Context.

Например:

User = Finance
Device = managed
MFA = passed
Risk = low
→ allow

Какие условия можно учитывать

Policy может использовать:

• User;
• Group;
• Application;
• Device;
• IP Address;
• Location;
• Risk Score;
• MFA Status.

SSO и Zero Trust

SSO хорошо сочетается с Zero Trust, потому что Identity становится централизованной точкой принятия решений.

Однако один факт успешного SSO Login не должен автоматически означать безусловное доверие ко всем ресурсам.

Step-up Authentication

Пользователь может войти через SSO в обычные приложения, но перед доступом к критичной системе IdP повторно потребует MFA.

Это позволяет повышать уровень Authentication в зависимости от риска.

SSO и Device Trust

Доступ можно предоставлять только с корпоративно управляемого устройства.

Например, финансовая SaaS Platform открывается через SSO только если Notebook соответствует Security Policy.

SSO и VPN

VPN Gateway также можно интегрировать с корпоративным Identity Provider.

Пользователь использует ту же Identity и централизованную MFA Policy, что и для SaaS.

SSO и RDP

Для Remote Desktop единый доступ может строиться через VPN, RD Gateway, Identity-aware Gateway или доменную Authentication.

Конкретная реализация зависит от архитектуры.

SSO и Cloud

Вместо создания отдельных постоянных Cloud Users сотрудники могут входить через корпоративный Identity Provider.

После Authentication им назначаются необходимые Cloud Roles.

Преимущество Federation в Cloud

Компания централизует жизненный цикл сотрудников и уменьшает количество постоянных самостоятельных Accounts внутри Cloud Platform.

SSO и Developer Platforms

Git, CI/CD и другие Developer Services удобно подключать к корпоративному SSO.

При увольнении разработчика его центральная Identity отключается, что уменьшает риск забытых Accounts.

SSO и 1С

В инфраструктуре 1С единый вход может быть реализован через поддерживаемые механизмы корпоративной Authentication, операционную систему, Web Access, Remote Desktop или внешние Identity Components.

Конкретная схема зависит от архитектуры 1С и используемых способов подключения.

SSO и внутренние приложения

Разработчики корпоративного Web Application могут делегировать Authentication существующему IdP вместо создания собственного Password Storage.

Это упрощает внедрение MFA и централизованный аудит.

SSO и API

Пользовательский SSO и Machine-to-Machine Authentication следует разделять.

Backend Service обычно не должен эмулировать вход сотрудника через Browser.

Для API применяются Service Identity, Tokens и Client Credentials.

SSO и Microservices

Frontend может получить Identity пользователя через IdP, после чего Backend использует проверенный Token.

Однако каждый Microservice должен корректно проверять Audience, Scope и Permissions.

SSO не заменяет Authorization

Даже если пользователь успешно прошел SSO, приложение обязано проверять, имеет ли он право открыть конкретный документ, выполнить Delete или назначить Administrator Role.

Broken Access Control

Ошибка Application Authorization может позволить обычному пользователю получить данные другого клиента.

SSO такую уязвимость не исправляет, потому что Identity пользователя подтверждена правильно, но Permissions проверяются неправильно.

Преимущества SSO для пользователей

Пользователю не нужно помнить множество корпоративных паролей.

Это снижает вероятность:

• записи Password на бумаге;
• повторного использования одинаковых Credentials;
• частых Reset Requests;
• ошибок при входе.

Преимущества SSO для IT

IT Team получает централизованную точку управления Authentication и может быстрее подключать новые Services.

Изменение Security Policy выполняется на уровне IdP, а не вручную в десятках систем.

Преимущества SSO для Security

Security Team получает:

• централизованные Authentication Logs;
• единую MFA Policy;
• Conditional Access;
• быстрое Account Disable;
• удобную интеграцию с SIEM и XDR.

Риски SSO

Главный архитектурный риск — высокая ценность центральной Identity.

Если IdP или пользовательская SSO Session скомпрометированы, злоумышленник может получить доступ сразу к нескольким системам.

Single Point of Compromise

SSO не обязательно является Single Point of Failure технически, если инфраструктура отказоустойчива, но центральная Identity становится критической точкой Security.

Поэтому IdP требует особенно сильной защиты.

SSO и Phishing

Централизация Login позволяет обучить пользователей вводить корпоративные Credentials только на одном доверенном IdP.

Однако злоумышленник может создать копию его Login Page, поэтому MFA и Phishing-resistant Authentication остаются важными.

SSO и Session Theft

Даже сильная MFA не всегда защищает от кражи уже созданной Session.

Malware или AiTM Attack может попытаться получить Session Token после успешной Authentication.

Как защищать SSO Session

Нужны:

• HTTPS;
• Secure Cookies;
• разумный Session Lifetime;
• Token Revocation;
• Device Security;
• Reauthentication для чувствительных операций;
• Monitoring.

SSO и EDR

EDR защищает Endpoint, на котором пользователь работает с SSO Session.

Если устройство заражено, злоумышленник потенциально может использовать уже авторизованный Browser.

Поэтому Identity и Endpoint Security дополняют друг друга.

SSO и SIEM

Identity Provider должен отправлять Authentication Events в SIEM.

Полезно контролировать:

• Failed Logins;
• New Device;
• новое Location;
• MFA Failure;
• Role Changes;
• новые Application Access;
• Session Revocation.

SSO и SOC

SOC использует SSO Logs для расследования Account Compromise.

Если один User внезапно входит в несколько критичных приложений из необычной сети, это может быть признаком атаки.

SSO и XDR

XDR может связывать Identity Events с Endpoint и Email Telemetry.

Phishing email
↓
SSO login from new IP
↓
Cloud access
↓
Suspicious download

Так Security Team видит более полную цепочку Incident.

SSO и Availability

Центральный IdP становится критичным компонентом.

Если он недоступен, новые пользователи могут потерять возможность входа сразу в несколько приложений.

High Availability SSO

Для критичной инфраструктуры Identity Provider должен иметь отказоустойчивую архитектуру, Monitoring и Disaster Recovery.

Что произойдет при недоступности IdP

Уже активные Application Sessions могут продолжать работать некоторое время, но новые Authentication Requests могут завершаться ошибкой.

Точное поведение зависит от конкретного приложения и Session Policy.

Break Glass Accounts

Для критичных административных систем могут использоваться Emergency Accounts, позволяющие восстановить доступ при сбое центрального IdP.

Их необходимо строго ограничивать, защищать и мониторить.

SSO и Shared Accounts

SSO способствует использованию индивидуальных Identities.

Общий Account вроде admin@example.com затрудняет аудит и не позволяет точно определить, кто выполнил действие.

Audit Trail

Централизованный IdP позволяет видеть историю Authentication:

SSO и Privacy

Центральный Identity Provider получает значительный объем информации о том, к каким приложениям обращаются пользователи.

Доступ к таким Logs должен быть ограничен и соответствовать внутренним требованиям по защите данных.

Типичные ошибки при внедрении SSO

1. Не включать MFA для центрального IdP.
2. Считать SSO заменой Authorization.
3. Не продумывать Logout и Session Revocation.
4. Оставлять локальные Password Accounts как обходной путь.
5. Не автоматизировать Deprovisioning.
6. Не защищать Administrator Accounts.
7. Не проверять подписи Tokens и Assertions в приложениях.
8. Не мониторить Authentication Events.
9. Не иметь аварийного сценария при отказе IdP.
10. Подключать приложения без анализа их Permissions.

Локальный вход как обход SSO

После внедрения Federation некоторые приложения продолжают разрешать старую локальную Authentication.

Если такие Accounts не контролируются, злоумышленник может обойти MFA и центральную Policy.

SSO и Administrator Access

Административные роли желательно отделять от повседневной пользовательской Identity.

Для критичных операций можно дополнительно требовать Step-up Authentication или PAM.

SSO и PAM

PAM дополняет SSO контролем Privileged Access.

Сотрудник подтверждает корпоративную Identity через IdP, а затем получает временную Administrator Session через PAM.

Как внедрить SSO

Шаг 1. Определить Identity Provider

Выберите центральную систему Authentication и источник Identities.

Шаг 2. Провести инвентаризацию приложений

Определите, какие системы поддерживают Federation.

Шаг 3. Выбрать протокол

Для разных приложений могут использоваться SAML, OpenID Connect, Kerberos или другие поддерживаемые механизмы.

Шаг 4. Включить MFA

Особенно для Administrators и внешнего доступа.

Шаг 5. Настроить Provisioning

SSO желательно дополнить автоматическим созданием и удалением Accounts.

Шаг 6. Закрыть обходные методы

Проверьте ненужные Local Accounts и Legacy Authentication.

Шаг 7. Настроить Logging

Authentication Events должны поступать в SIEM или XDR.

Шаг 8. Подготовить отказоустойчивость

Продумайте действия при недоступности Identity Provider.

Практический пример

В компании работает 500 сотрудников и используется 20 SaaS Applications.

Раньше для каждого сервиса создавался отдельный Account, поэтому сотрудники забывали Password, а IT Team вручную удаляла доступ после увольнения.

Компания подключает SaaS к корпоративному Identity Provider.

Теперь сотрудник утром проходит Authentication:

Corporate login
+
MFA
↓
Identity Provider

После этого он открывает CRM, Service Desk, Wiki и HR Platform без повторного ввода Password.

Когда сотрудника переводят в другой Department, IAM меняет Groups и доступные Applications.

При увольнении его центральная Identity блокируется, активные Sessions отзываются, а SCIM удаляет или отключает Accounts в SaaS.

Все события входа поступают в SIEM. Если пользователь неожиданно входит из нового региона и открывает финансовый сервис, SOC получает дополнительный Security Context.

Так SSO одновременно упрощает работу сотрудников и делает управление Authentication более централизованным.

SSO для бизнеса

Для бизнеса SSO уменьшает количество отдельных Credentials и упрощает подключение сотрудников к корпоративным приложениям.

Особенно заметен эффект при большом количестве SaaS Services и удаленной работе.

Одновременно организация получает возможность централизованно применять MFA и быстро блокировать Identity при увольнении или компрометации.

Преимущества SSO

• меньше отдельных Password;
• удобный вход для сотрудников;
• централизованная MFA;
• быстрое Account Disable;
• единая Security Policy;
• централизованный Audit;
• меньше обращений в Service Desk;
• удобная интеграция SaaS.

Ограничения SSO

• центральная Identity становится критичной целью;
• не все приложения поддерживают Federation;
• нужна отказоустойчивость IdP;
• SSO не заменяет Authorization;
• необходимо управлять локальными Sessions;
• старые Local Accounts могут создавать обход;
• требуется надежный Deprovisioning.

Когда SSO особенно полезен

SSO особенно полезен компаниям с большим количеством SaaS и внутренних Web Applications, удаленными сотрудниками и централизованным IAM.

Чем больше отдельных сервисов использует один сотрудник, тем выше операционная и Security-ценность единого входа.

Связанные термины

Краткий итог

SSO — Single Sign-On, технология единого входа, при которой пользователь проходит Authentication у центрального Identity Provider и затем получает доступ к нескольким доверяющим приложениям без повторного ввода Password.

SSO улучшает User Experience и одновременно упрощает централизованную Security Policy: MFA, Conditional Access, аудит и блокировку Accounts. При этом единый вход не заменяет Authorization и не означает передачу одного общего Password всем приложениям.

Главный Security Risk SSO связан с высокой ценностью центральной Identity и Session. Поэтому Identity Provider должен быть защищен сильной MFA, Monitoring, отказоустойчивостью и надежным процессом Deprovisioning и Session Revocation.