Взлом Okta: что значит, когда взламывают провайдера идентификации
В марте 2022 года Okta подтвердила взлом. Разбираю, какой урок из этого должен вынести директор, а не специалист по безопасности.
В марте 2022 года группа Lapsus$ опубликовала скриншоты, свидетельствующие о доступе к внутренним системам Okta. Okta - один из крупнейших провайдеров систем управления идентификацией и доступом, которыми пользуются тысячи компаний для единого входа в корпоративные приложения.
Инцидент подтвердился. Okta сообщила, что взлом затронул аккаунт подрядчика службы поддержки и что потенциально затронутыми оказались около 2,5% клиентов.
Для технических специалистов этот инцидент поднял вопросы о цепочке поставщиков, управлении доступом подрядчиков и процедурах реагирования. Для руководителей он поднял другой вопрос: что происходит с моей компанией, если взламывают тех, кому я делегировал управление доступом?
Что такое провайдер идентификации и почему это важно
Когда ваши сотрудники входят в рабочие приложения через единый аккаунт - это SSO, single sign-on. Провайдер идентификации - это система, которая проверяет, кто вы, и выдаёт токены доступа к остальным сервисам.
Это очень удобно. Один аккаунт вместо десятков паролей. Централизованное управление: уволили сотрудника - отозвали доступ в одном месте. Это правильная архитектура.
Но она создаёт концентрацию риска. Тот, кто контролирует провайдера идентификации, потенциально контролирует доступ ко всем сервисам, которые к нему подключены. Взлом Okta показал, что этот риск не абстрактный.
Три уровня вопросов после инцидента
Первый уровень - операционный. Как вы узнаете, если ваш провайдер идентификации будет скомпрометирован? Есть ли у вас мониторинг аномального поведения аккаунтов? Можете ли вы быстро заблокировать подозрительные сессии?
Второй уровень - архитектурный. Все ли ваши системы идут через единый провайдер? Есть ли у вас возможность временно переключиться на резервную процедуру аутентификации, если основной провайдер недоступен или скомпрометирован?
Третий уровень - контрактный и аудиторский. Что ваш провайдер идентификации обязан вам сообщать в случае инцидента и в какие сроки? Как он управляет доступом своих собственных подрядчиков - то есть тех, кто поддерживает систему, которая управляет вашим доступом?
Что изменилось в управлении идентификацией после этого инцидента
Инцидент обострил несколько требований к выбору и настройке провайдеров идентификации:
- многофакторная аутентификация должна распространяться не только на конечных пользователей, но и на административные аккаунты провайдера;
- доступ подрядчиков и сотрудников поддержки к системам управления идентификацией должен быть строго ограничен по принципу минимальных привилегий;
- компании-клиенты должны иметь независимые логи аномального поведения, а не полагаться только на логи провайдера.
Это не новые принципы. Но Okta превратила их из теории в конкретный повод для проверки.
Проверочные вопросы для директора
- Знаете ли вы, какие системы в вашей компании подключены к провайдеру идентификации?
- Есть ли у вас процедура действий при компрометации провайдера?
- Как вы узнаете о подозрительном входе, который произошёл ночью?
- Ваши ключевые системы имеют дополнительный слой защиты помимо SSO, или единственный барьер - это провайдер идентификации?
Инциденты с поставщиками вроде Okta показывают, что безопасность инфраструктуры нельзя полностью делегировать третьей стороне. Вы делегируете операционную работу, но не ответственность за понимание рисков.