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

[KL FC Bot]

Утечки учетных данных остаются одним из самых популярных у злоумышленников способов проникновения в организацию. Только за 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-платформы недостаточно контролируют корректность самих токенов, открывая простор для их подделки.

 

Посмотреть статью полностью