Компрометация одного SSO-аккаунта в Университете Пенсильвании в 2025 году, по данным BleepingComputer, открыла злоумышленникам доступ сразу к VPN, Salesforce, Qlik, SAP и SharePoint. Итогом могла стать утечка данных 1,2 млн человек. Для компаний, где единый вход давно стал нормой, вывод неприятный, но полезный: защиту SSO нельзя считать задачей из серии «настроили и забыли».
Речь не о том, что single sign-on сам по себе опасен. Проблема в другом: если одна учетная запись открывает путь в несколько корпоративных систем, ее компрометация быстро перестает быть локальной историей и превращается в инцидент уровня всей ИТ-инфраструктуры.
Взлом PennKey показал цену одного логина
В материале BleepingComputer, подготовленном при поддержке Specops Software, приводят показательный пример с PennKey — системой единого входа Университета Пенсильвании. По опубликованным данным, атакующие получили доступ к одной учетной записи и через нее добрались до внутренних сервисов, включая VPN, Salesforce, Qlik, SAP и SharePoint.
Этот набор выглядит слишком знакомо для любого среднего и крупного бизнеса: удаленный доступ, CRM, BI, ERP и корпоративные файлы. Поэтому SSO удобен сотрудникам и так привлекателен для атакующих. Один успешный вход заменяет им длинную и дорогую цепочку отдельных взломов.
Но это только половина истории.
SSO при нормальной настройке, наоборот, упрощает защиту: сокращает число паролей, дает одну точку для MFA, условного доступа и журналирования, а заодно снимает часть нагрузки с ИТ-поддержки. Проблемы начинаются, когда компания воспринимает единый вход как удобную кнопку, а не как критический элемент защиты.
Парольная политика до сих пор решает слишком много
Авторы материала отдельно ссылаются на рекомендации NIST. Если система по-прежнему допускает вход только по паролю, минимальная длина должна быть не меньше 15 символов. Если пароль используется вместе с MFA, достаточно восьми символов, а максимальную длину лучше разрешать до 64 символов.
Отдельный акцент — на проверке новых паролей по стоп-листам часто используемых, ожидаемых и уже скомпрометированных комбинаций. Логика здесь здравая: меньше экзотики ради галочки, больше упора на длину, удобство и отсев заведомо слабых вариантов.
Заодно под сомнение ставятся старые корпоративные привычки. Обязательные спецсимволы и принудительная регулярная смена пароля нередко толкают людей к предсказуемым шаблонам вроде «Winter2026!» после «Winter2025!». На бумаге политика соблюдена, на практике пароль становится проще угадать. Для SSO это особенно опасно, потому что такой шаблонный ключ сразу подходит к нескольким системам.
MFA нужна не для галочки, а против фишинга
Одними паролями вопрос давно не закрывается. Рынок живет в эпоху инфостилеров, которые вытаскивают с устройств не только логины и пароли, но и куки, токены и другую аутентификационную информацию. На этом фоне даже хороший пароль перестает быть надежной границей.
Поэтому защита SSO без MFA сегодня выглядит скорее как приглашение к проблемам. Причем важна не только сама многофакторная аутентификация, но и ее качество. SMS-коды и базовые одноразовые пароли лучше, чем ничего, но против современных фишинговых схем и перехвата сессий это уже слабая броня.
Более устойчивыми вариантами авторы называют FIDO2-ключи, WebAuthn и passkeys, особенно для администраторов и доступа к чувствительным системам. Для компаний в России и СНГ вывод простой: если SMS до сих пор считают достаточной защитой для критичных сервисов, этот подход пора пересматривать без иллюзий.
Под защитой должен быть не только вход, но и вся цепочка доверия
Отдельная зона риска — учетные записи администраторов identity provider. Именно они меняют политики аутентификации, подключают приложения, сбрасывают пользователей и одобряют интеграции. Если такой аккаунт перехватили, атакующему уже не нужно штурмовать каждую систему отдельно: он получает возможность переписать правила доступа.
Базовый минимум здесь жесткий, но логичный: отдельные администраторские учетные записи, MFA с защитой от фишинга, доступ just-in-time и постоянный мониторинг действий.
Не менее чувствительная тема — сертификаты и ключи подписи. В SAML именно они подтверждают, что приложению можно доверять identity provider. Если такие ключи утекли или их использовали не по назначению, злоумышленник потенциально сможет выдавать себя за легитимного пользователя или злоупотреблять доверенными сессиями. Поэтому доступ к ним нужно жестко ограничивать, изменения — отслеживать, а ротацию не откладывать до даты истечения.
Та же логика касается OAuth-секретов, client secrets, учетных данных приложений и refresh token. В реальной атаке они особенно ценны тем, что позволяют удерживать доступ без нового интерактивного входа. Для разработчиков и платформенных команд это уже не абстрактная безопасность, а обычная инженерная дисциплина: хранить секреты в защищенном хранилище, регулярно ротировать их, проверять избыточные разрешения и чистить устаревшие выданные доступы.
Значение для рынка
Чем активнее бизнес сводит SaaS, внутренние сервисы и удаленный доступ в единый контур идентификации, тем ценнее для атакующих становится не конкретный пароль, а вся инфраструктура доверия вокруг identity provider. Для стартапов это вопрос скорости и цены инцидента, для крупных компаний — вопрос масштаба ущерба и аудита. Проще говоря: единый вход экономит время сотрудникам, но при слабой защите так же эффективно экономит время и атакующему.
Следующий логичный шаг для рынка — переход от формального внедрения SSO к его «закалке»: с обязательной MFA, защитой администраторов, ротацией ключей и регулярной ревизией всех доверенных интеграций.