Взлом Okta: что происходит, когда скомпрометирован провайдер идентификации
Разбор инцидента с Okta в октябре 2023 года и практические выводы для компаний, которые используют централизованную аутентификацию.
В октябре 2023 года Okta сообщила об инциденте: злоумышленники получили доступ к системе поддержки клиентов и через неё смогли просмотреть файлы, связанные с аккаунтами части клиентов. Это не первый раз, когда у Okta возникают проблемы с безопасностью - в 2022 году был схожий инцидент через подрядчика.
Для компаний, которые используют Okta или аналогичные системы единого входа (SSO), этот инцидент задаёт несколько важных вопросов. Не про Okta конкретно - а про то, как выглядит ваша зависимость от провайдера идентификации в целом.
Почему провайдер идентификации - особенная зависимость
Централизованная аутентификация - это огромная ценность с операционной точки зрения. Один аккаунт для всех систем, единое управление доступом, возможность мгновенно отозвать права уволенного сотрудника. Это работает хорошо.
Но есть обратная сторона. Провайдер идентификации - это точка, через которую проходит доступ ко всему. Если он скомпрометирован - под угрозой оказываются не отдельные системы, а вся инфраструктура. Это не гипотетически - именно это произошло с рядом клиентов Okta в 2022 году: через скомпрометированный аккаунт подрядчика злоумышленники получили возможность воздействовать на клиентские среды.
Чем централизованнее управление доступом - тем выше операционная эффективность и тем выше цена компрометации центра.
Что конкретно произошло в октябре 2023
По данным Okta, злоумышленники получили доступ к системе поддержки клиентов. Через эту систему сотрудники поддержки имеют доступ к файлам клиентов для диагностики проблем - в частности, к HTTP Archive (HAR) файлам, которые клиенты передают при обращениях. HAR-файлы могут содержать сессионные куки и другие чувствительные данные.
Ряд клиентов Okta был уведомлён, что их файлы были просмотрены. Несколько крупных компаний - BeyondTrust, Cloudflare, 1Password - публично подтвердили, что обнаружили подозрительную активность, связанную с этим инцидентом.
Практические вопросы для руководителя
Инцидент у провайдера - не то, что вы контролируете. Но есть вещи, которые в вашей зоне ответственности.
Привилегированные аккаунты должны быть защищены сильнее. Административные аккаунты в SSO-провайдере - это не просто ещё один корпоративный логин. Их нужно защищать отдельно: уникальные пароли, аппаратный второй фактор, минимальный круг людей с доступом.
Что происходит, если провайдер идентификации недоступен? Это не параноя, это вопрос непрерывности. Если Okta упала или скомпрометирована, как сотрудники получают доступ к критичным системам? Есть ли резервные механизмы?
Логирование и детектирование аномалий. Аномальные входы, попытки доступа из нетипичных мест, массовые запросы доступа - всё это должно генерировать алерты. Если инциденты в провайдере не отражаются в вашем мониторинге - это слепая зона.
Что вы передаёте в систему поддержки? HAR-файлы, о которых шла речь в инциденте - это пример того, как вспомогательные каналы могут содержать чувствительные данные. Политика того, что передаётся в техподдержку вендора, заслуживает отдельного внимания.
Чеклист минимальной готовности
- Есть ли у административных аккаунтов в SSO-провайдере hardware-second factor?
- Ограничен ли список людей с доступом к административной консоли?
- Есть ли журнал доступа к административным функциям с алертами на аномалии?
- Есть ли план действий при недоступности или компрометации провайдера?
- Знаете ли вы, какие данные о вашем окружении доступны поддержке вендора?
Ни один провайдер не застрахован от инцидента. Вопрос в том, насколько ваши зависимости от него очевидны вам и насколько вы готовы к развитию событий.