Большинство организаций, с которыми я работаю, вложили значительные средства в облачную безопасность. У них есть средства обнаружения на конечных точках, платформы SIEM, управление положением в облачной безопасности и квалифицированные команды специалистов, работающие посменно круглосуточно. И все же, когда я задаю им простой вопрос — «У кого сейчас есть права администратора в вашем тенанте Salesforce?» — в комнате наступает тишина. Никто не знает. Не потому, что они небрежны. А потому, что они действительно не могут это увидеть.
Это слепая зона SaaS.
SaaS: цифры говорят сами за себя
Я задаю этот вопрос почти в каждом проекте: сколько SaaS-приложений работает в вашей организации? Ответы, которые я получаю, варьируются от 30 до, возможно, 50. Реальное число, когда кто-то подсчитывает, обычно превышает триста. Исследование AppOmni за 2024 год показало еще более высокие цифры — 49% организаций, использующих Microsoft 365, полагали, что к их тенанту подключено менее десяти приложений, хотя фактическое среднее значение превышало тысячу.
Вот что беспокоит меня больше, чем количество. Из всех этих приложений команды безопасности имеют четкое представление, возможно, об одном из десяти. Остальные — где хранятся записи о клиентах, где находится исходный код, где распространяются финансовые отчеты — никто не отслеживает. Не потому, что команда небрежна. А потому, что инструменты, которые у них есть, никогда не были созданы для того, чтобы туда заглядывать.
Следующие инциденты иллюстрируют эти реалии.
Salesforce в 2023 году
В апреле 2023 года KrebsOnSecurity опубликовал новость: сайты Salesforce Community незаметно утекали конфиденциальные данные государственных учреждений, банков и медицинских организаций. Никакой сложной техники атаки. Просто правильная конечная точка API и неправильно настроенный профиль гостевого пользователя. Раскрытые записи включали номера социального страхования, данные учетных записей и домашние адреса. Salesforce четко ответила: это не была уязвимость платформы. Администраторы неправильно настроили политики гостевого доступа, и никто этого не проверил.
Профили гостевых пользователей в Salesforce Communities могут получать доступ к записям данных. Когда администраторы устанавливают эти разрешения слишком широко — часто не осознавая этого — неаутентифицированные внешние пользователи могут запрашивать эти данные напрямую через API. Более 150 000 компаний потенциально находились в этом окне, прежде чем кто-либо поднял тревогу.
Схема всегда одна и та же. Конфигурация, выполненная в условиях цейтнота, настройки по умолчанию слегка излишне разрешительные, и никто больше не пересматривает их. SaaS-приложения накапливают такие тихие уязвимости в течение месяцев и лет.
GitHub в 2022 году
В апреле 2022 года GitHub раскрыл, что злоумышленник использовал украденные OAuth-токены, выданные Heroku и Travis CI, для доступа и загрузки содержимого частных репозиториев десятков организаций, включая npm. Собственные системы GitHub не пострадали. Токены были получены от сторонних приложений, которым пользователи разрешили подключаться к своим учетным записям, и эти приложения были незаметно скомпрометированы.
Точкой входа был не GitHub. Это были даже не организации, потерявшие свои данные. Это были инструменты CI/CD, которые эти организации подключали к GitHub месяцами или годами ранее — инструменты, которым были предоставлены широкие права на чтение и запись, и которые никогда не пересматривались.
Вот она, проблема OAuth, простыми словами. Как только вы авторизуете стороннее приложение, его состояние безопасности становится и вашей проблемой. У большинства организаций десятки таких открытых соединений на их SaaS-платформах, и никто их не проверяет.
Microsoft в 2023 году
Кейс Microsoft 2023 года я привожу, когда люди предполагают, что такое случается только с небрежными организациями. Wiz Research обнаружила, что собственная команда Microsoft по ИИ раскрыла 38 ТБ внутренних данных — закрытые ключи, пароли и более 30 000 внутренних сообщений Teams — из-за одного неправильно настроенного токена доступа Azure. Этот токен должен был предоставить общий доступ к одному обучающему набору данных на GitHub. Вместо этого он открыл целую учетную запись хранения для любого, кто нашел ссылку.
Что меня поражает в этом случае, так это хронология. Этот токен находился там с октября 2021 года. Почти два года внутри Microsoft, прежде чем кто-то его заметил. Если команда с таким уровнем ресурсов и экспертизы может оставить дверь открытой на два года, то идея «мы бы заметили» — это не очень хорошая стратегия безопасности. И стоит отметить: это была не утечка базы данных. Это были сообщения Teams. Те же средства совместной работы, которые ваши сотрудники используют каждый день, так же уязвимы, как и платформы со структурированными данными.
Почему традиционные инструменты безопасности это упускают
Инструменты управления положением в облачной безопасности — CSPM — предназначены для мониторинга конфигурации инфраструктуры: виртуальных машин, хранилищ, сетевых правил и политик IAM на уровне инфраструктуры. Они выполняют приемлемую работу на этом уровне. Но они не заглядывают внутрь SaaS-приложений. Руководство CISA по безопасным облачным бизнес-приложениям (SCuBA) специально указывает на разрыв между инструментами безопасности инфраструктуры и видимостью на уровне SaaS как на одну из наименее проработанных областей в корпоративной облачной безопасности.
Это разрыв, который SSPM был создан, чтобы закрыть. Вместо наблюдения за инфраструктурой, он отслеживает конфигурацию самих SaaS-приложений — разрешения, настройки общего доступа, у кого есть доступ к чему. И это различие не просто теоретическое. Неправильные конфигурации инфраструктуры, как правило, раскрывают системы. Неправильные конфигурации SaaS, как правило, раскрывают данные — напрямую, незаметно и часто без какой-либо обнаруживаемой атаки.
Что должны сделать команды безопасности сейчас
Вам не нужно завтра же разворачивать полноценную платформу SSPM, чтобы начать закрывать разрыв. Есть практические шаги, которые сразу же дают результат.
- Проведите аудит подключенных OAuth-приложений на ваших основных SaaS-платформах. Отзовите любую интеграцию, которая не может быть обоснована текущей бизнес-потребностью.
- Частый источник раскрытия публичных данных: проверьте разрешения для гостевых и внешних пользователей в Salesforce Communities и Microsoft SharePoint.
- Проверьте, отключены ли устаревшие протоколы аутентификации в Microsoft 365. Устаревшая аутентификация обходит MFA и становится потенциальной точкой входа в корпоративных средах.
- Установите ежеквартальный обзор доступа для привилегированных учетных записей в SaaS-приложениях. Большинство организаций проводят ежегодные проверки в лучшем случае — это недостаточно часто для платформ, которые ежедневно меняют конфигурацию.
- Составьте карту, какие SaaS-приложения содержат конфиденциальные данные, а какие вообще не имеют ответственного лица от команды безопасности. Этот список будет длиннее, чем вы ожидаете.
Ключевая проблема не в том, что организации небрежны. А в том, что они построили программы безопасности вокруг периметра и инфраструктуры, а SaaS-приложения выросли внутри этого периметра, так и не попав в охват. Данные есть. Доступ есть. Неправильная конфигурация часто тоже есть. Чего не хватало — так это видимости, чтобы это увидеть.
SSPM закрывает этот разрыв. Но даже до внедрения формального инструмента, просто задав вопрос — что могут видеть и передавать приложения, которые мы уже используем? — это уже значимый первый шаг. По моему опыту, ответ удивляет почти каждую организацию, которая находит время заглянуть.
Эта статья опубликована в рамках сети экспертных авторов Foundry.
Хотите присоединиться?
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Ashish Mishra
