Что не так с SSO в облачных сервисах и как снизить риски

Система единого входа (single sign-on) должна значительно усиливать защиту организации, но важно, чтобы команде ИБ помогали поставщики используемых облачных решений.

Утечки учетных данных остаются одним из самых популярных у злоумышленников способов проникновения в организацию. Только за 9 месяцев 2023 года по данным Kaspersky Digital Footprint Intelligence в даркнете было опубликовано 315 миллионов записей учетных данных, среди которых множество реквизитов доступа к корпоративным ресурсам, в том числе и к ресурсам компаний из списка Fortune 500.  Чтобы эффективнее управлять связанными с этим рисками, минимизировать число уязвимых аккаунтов, быстрее замечать и пресекать несанкционированный доступ, компании внедряют системы управления identity, о которых мы подробно писали ранее. Но эффективный процесс управления identity невозможен, пока большинство корпоративных систем не поддерживают процедуру унифицированной аутентификации. Для внутренних систем компании она обычно завязана на централизованный каталог, например Active Directory, а во внешних SaaS-системах взаимодействие с корпоративным каталогом identity ведется через платформу Single Sign-on (SSO) —либо внешнюю, либо развернутую в инфраструктуре компании, такую как ADFS.

Для сотрудников это предельно удобно — логинясь во внешние системы, такие как SalesForce или Concur, сотрудник проходит единый для корпоративной сети процесс аутентификации, включая ввод пароля и предъявление второго фактора (кода OTP, USB-токена и так далее, согласно корпоративной политике), ему не нужны никакие дополнительные логины и пароли. Более того, однократно войдя утром в одну из систем, в остальные можно входить автоматически. Помимо удобства этот процесс в теории безопасен, поскольку службы IT и ИБ имеют полный централизованный контроль над учетными записями, парольными политиками, методами МФА и логами.
Но на практике уровень безопасности внешних систем, поддерживающих SSO, зачастую оказывается не таким уж высоким.

Подводные камни Single Sign-On

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

• указание периода действия токена (и сессии), по истечении которого потребуется повторная аутентификация;
• привязка токена к конкретному браузеру или мобильному устройству;
• привязка токена к конкретным IP-адресам или IP-диапазонам, что позволяет реализовать в том числе географические ограничения;
• дополнительные условия окончания сессии, например закрытие браузера или выход пользователя из самой SSO-платформы.

Ключевая проблема заключается в том, что некоторые облачные провайдеры неверно интерпретируют или вовсе игнорируют эти ограничения, нарушая таким образом модель безопасности, которую выстроила команда ИБ. Более того, в ряде случаев SaaS-платформы недостаточно контролируют корректность самих токенов, открывая простор для их подделки.

Как этими ошибками в реализации SSO пользуются злоумышленники?

Самый типичный сценарий — похищение токенов аутентификации в той или иной форме. Это может быть кража файлов cookie с компьютера пользователя, перехват трафика или захват HAR-файлов (архивов трафика). В принципе, использование токена на другом устройстве и с другого IP является достаточно серьезным сигналом для SaaS-платформы, требующим перепроверки и возможно повторной аутентификации. Но на практике ворованные токены часто позволяют злоумышленникам входить в систему от имени легитимного пользователя, целиком минуя пароли, одноразовые коды и прочие ухищрения ИБ.

Другой распространенный сценарий атаки — целевой фишинг с использованием страниц, имитирующих корпоративные порталы и по необходимости обратного прокси наподобие evilginx2, позволяющего воровать пароли, коды МФА и те же токены.

Как улучшить безопасность процесса SSO

Контролируйте поставщиков SaaS. Команда ИБ может включить в опросник, который заполняется поставщиками в процессе тендера, вопросы, касающиеся реализации SSO на SaaS-платформе. В частности, вопросы, касающиеся соблюдения различных ограничений использования токенов, процессов их валидации, устаревания и досрочного отзыва. Дополнительными мерами проверки будут аудиты кода приложения, интеграционные тесты, анализ на уязвимости и пентесты.

Проработайте компенсирующие меры. Манипуляция токенами и их похищение могут быть предотвращены самыми разными способами. Например, применение EDR на всех компьютерах значительно снижает риски заражения вредоносным ПО и посещения фишинговых сайтов, а управление мобильными устройствами (EMM/UEM) позволяет навести порядок в доступе к корпоративным ресурсам с мобильных устройств. В ряде случаев рекомендуется запретить доступ к корпоративным сервисам с устройств, неподконтрольных компании (unmanaged device).

Настройте системы анализа сетевого трафика и управления identity на анализ запросов и ответов SSO, чтобы идентифицировать подозрительные запросы: от нехарактерных клиентских приложений или пользователей, из неожиданных IP-зон и так далее. Также на уровне трафика можно контролировать «залежавшиеся» токены с избыточно большим сроком действия.

Настаивайте на более качественной реализации SSO.  Для многих SaaS-платформ реализация SSO – это скорее элемент удобства для клиентов и повод взять с них деньги за более дорогой «корпоративный» тариф, а ИБ-аспекты стоят на втором плане.  В партнерстве с отделом закупок на эту ситуацию можно влиять (хоть и достаточно медленно).  В переговорах с SaaS-платформами никогда не лишним будет запросить информацию о развитии функции SSO: поддерживаются ли вышеописанные ограничения токенов (геоблокировка, срок годности и т. п.), планируется ли переход на более современные и лучше стандартизованные протоколы обмена токенами, например JWT и CAEP.

16.01.2024