SSO и SaaS-хаос: почему архитектура идентификации важна до инцидента
Как накопление SaaS-инструментов создаёт проблему идентификации, которую не решают одни лишь средства безопасности - и что с этим делать до того, как что-то пойдёт не так.
В начале этого года взлом Okta поставил поставщиков систем идентификации на первые полосы технологических новостей. Несколько месяцев спустя отдельная атака с использованием учётных данных против Twilio показала, как один скомпрометированный вендор аутентификации может одновременно открыть злоумышленникам доступ к десяткам зависимых сервисов.
Этот пост - о связанной и более медленной проблеме: накоплении SaaS-инструментов в компании, каждый со своей системой идентификации, что создаёт фрагментированный ландшафт доступа, который сложно проверить, сложно защитить и практически невозможно быстро привести в порядок, когда что-то идёт не так.
Как выглядит хаос идентификации на практике
В компании из тридцати человек у сотрудников могут быть активные аккаунты в сорока - шестидесяти SaaS-приложениях. Часть из них предоставлена компанией и задокументирована. Многие - нет: индивидуальные подписки, оплаченные с личных карт, пробные аккаунты, которые никогда не отменяли, интеграции, настроенные подрядчиками, которые давно ушли.
Когда человек уходит из компании, кто-то из IT или операционного отдела в идеале деактивирует его аккаунты. На практике несколько аккаунтов всегда упускается. Инструмент продаж. Старая аналитическая платформа. Портал вендора, который кто-то создал для проекта два года назад. Такие спящие аккаунты накапливаются. Каждый - потенциальная точка входа.
Проблема не уникальна для какой-то одной компании или размера. Она структурная. В закупках SaaS нет естественной точки контроля, где проводился бы аудит идентификации. Инструменты добавляются постоянно, удаляются редко.
Где SSO помогает и где нет
Единый вход - подключение ваших SaaS-инструментов к центральному провайдеру идентификации, такому как Okta, Azure AD или Google Workspace - это стандартная архитектурная рекомендация для этой проблемы. С SSO, когда вы деактивируете кого-то в центральном каталоге, его доступ ко всем подключённым приложениям отзывается одновременно.
Это реально полезно, и компаниям, которые ещё не внедрили это, стоит сделать. Но у SSO есть проблема покрытия. Не каждый SaaS-инструмент поддерживает SSO, особенно на более низких ценовых тарифах. Не каждый инструмент, поддерживающий SSO, подключён. А некоторые категории доступа - API-ключи, сервисные аккаунты, учётные данные интеграций - вообще находятся вне модели SSO.
Я работал с компаниями, которые считали свою ситуацию с идентификацией хорошо управляемой, потому что у них был SSO, - а затем при проверке безопасности обнаруживали, что сорок процентов их активных SaaS-аккаунтов находились в инструментах вне конфигурации SSO, а ещё двадцать процентов были сервисными аккаунтами или API-токенами без срока действия и без назначенного владельца.
Вопрос аудита, который никто не задаёт
Самое полезное упражнение, которое я знаю для оценки хаоса идентификации, простое: составьте список каждого используемого SaaS-инструмента, затем по каждому ответьте на три вопроса.
- Можете ли вы отозвать весь человеческий доступ к этому инструменту менее чем за пять минут?
- Знаете ли вы все нечеловеческие учётные данные (API-ключи, сервисные аккаунты, секреты вебхуков), которые были выпущены для этого инструмента?
- Есть ли конкретный человек, ответственный за управление доступом к этому инструменту?
У большинства компаний честный ответ хотя бы на один из этих вопросов хотя бы по половине инструментов - «нет». Это не катастрофа - это отправная точка. Ценность упражнения в том, чтобы сделать пробелы явными.
Как выглядит разумная программа
Гигиена идентификации не требует выделенной команды безопасности. Она требует регулярного процесса. Минимальная рабочая версия:
- Ежеквартальный аудит аккаунтов пользователей во всех активных SaaS-инструментах с деактивацией тех, кто больше не работает в компании или больше не нуждается в доступе.
- Политика, что все новые закупки SaaS проходят через одного человека или команду, которые регистрируют инструмент и обеспечивают настройку SSO или аналогичного контроля доступа.
- Ежегодный аудит нечеловеческих учётных данных: API-ключи, сервисные аккаунты, OAuth-токены. Отзыв всего, у чего нет задокументированного владельца или что не использовалось шесть месяцев.
- Чеклист оффбординга, включающий доступ к SaaS наряду с электронной почтой и возвратом устройства.
Всё это не эффектно. Всё это существенно сокращает поверхность атаки. Компании, которые хуже всего реагируют на инциденты с учётными данными, - те, где никто не может ответить на базовый вопрос: к каким системам мог иметь доступ этот человек?