Теневой SaaS: как найти и закрыть рискованные OAuth-интеграции
Теневой SaaS — это облачные сервисы и приложения, которые сотрудники подключают сами, без согласования с ИБ и ИТ. Чаще всего риск приходит не через логин-пароль, а через OAuth: пользователь нажимает «Войти через корпоративный аккаунт» или «Разрешить доступ», и сторонний сервис получает токен с правами читать почту, файлы, календарь или переписку — иногда бессрочно и в обход MFA. **Если коротко:** проблема решается не запретами, а наведением порядка. Нужно обнаружить, какие приложения реально подключены к вашему тенанту, проверить, какие OAuth-разрешения они запросили, отозвать токены у рискованных и избыточных интеграций и дальше держать минимум привилегий. Ниже — как находить теневой SaaS, таблица «риск OAuth → мера», процесс наведения порядка по шагам и чек-лист. Сравнить инструменты контроля SaaS по подтверждённым сигналам можно в [рейтинге SSPM и SaaS Security](/rating/sspm-saas-security).
Визуальный контекст исследования
Изображение помогает быстро считать тему материала: инфраструктура, данные, доступы и контрольные точки, которые важно проверить перед выбором решения.
Рейтинги подрядчиков по теме исследования
Если после чтения нужен короткий список исполнителей, начните с профильных рейтингов cyber-index.ru: в них видны компании, кейсы, интервью, категории экспертизы и доверительный индекс.
Как проверять выводы исследования
Используйте материал как основу для shortlist: сопоставьте выводы с профилями компаний, связанными рейтингами, кейсами, интервью клиентов и источниками. Если в статье есть список источников, начинайте проверку с него; если источников мало, дополнительно запросите у подрядчика методику, baseline и примеры работ.
Авторы и проверка материала
У каждого исследования есть персональные авторы, профиль экспертизы, дата публикации, список источников и редакционная проверка выводов.
author
Антон Смирнов
Старший редактор исследований ИБ-рынка
Ведет исследования по категориям ИБ, публичным источникам и критериям выбора поставщиков.
- 7 лет в SEO-аналитике и редакционных B2B-исследованиях
- Специализация: ИБ-категории, entity-based SEO и факторы E-E-A-T
author
Полина Лебедева
Исследователь рынка ИБ-поставщиков
Собирает и сравнивает данные по подрядчикам, услугам, публичным кейсам, ценовым диапазонам и рыночным сегментам.
- 5 лет в market research, digital-аналитике и конкурентных обзорах
- Специализация: ИБ-поставщики, сервисные категории, прайс-анализ и case review
Авторы закреплены по теме исследования и опираются на практические разборы страниц, кейсов, источников и рыночных выборок.
В профиле автора указаны зона экспертизы, роль в редакции, регалии и темы, за которые он отвечает.
Материалы связаны с методологией cyber-index.ru, внутренними рейтингами, карточками компаний и источниками.
Позиции не продаются, выводы отделены от рекламы, а проверяемые утверждения поддержаны источниками и датами обновления.
Что такое теневой SaaS и почему OAuth опаснее пароля
Теневой SaaS (shadow SaaS) — частный случай теневого ИТ: облачные приложения, подключённые в обход ИБ. Сотрудник регистрируется в сервисе для заметок, AI-помощнике, конвертере файлов или CRM, чтобы решить рабочую задачу быстрее. С точки зрения бизнеса — инициатива. С точки зрения безопасности — неучтённый канал доступа к корпоративным данным.
Ключевая разница между «обычным» теневым сервисом и рискованной OAuth-интеграцией — в механике доступа. Когда сотрудник просто завёл логин и пароль, данные хотя бы остаются в самом сервисе. Когда он нажимает «Войти через Google / Microsoft / Яндекс» или «Разрешить доступ к почте и диску», сторонний сервис получает **OAuth-токен** — делегированный доступ к вашим корпоративным данным напрямую. И у этого доступа есть неприятные свойства:
- **Он переживает смену пароля.** Сброс пароля и даже MFA не отзывают ранее выданный токен. - **Он часто бессрочный.** Refresh-токен может работать месяцами, пока его явно не отозвали. - **Он обходит периметр.** Доступ идёт по API сервиса, а не через ваши шлюзы и прокси. - **Он избыточен по умолчанию.** Приложения нередко просят больше прав, чем им нужно для работы.
Именно поэтому контроль OAuth-разрешений — отдельная задача, которую не закрывают ни пароли, ни MFA, ни обычный антивирус. Это профильная зона [SSPM-решений](/research/chto-takoe-sspm).
Теневой SaaS и OAuth: на что смотреть
Доступ к данным в обход пароля и MFA
Токен надо отзывать отдельно
Чтение/запись почты, диска, контактов
Отзыв избыточных и неактивных интеграций
Как находить теневой SaaS и рискованные интеграции
Обнаружение строится на нескольких независимых источниках — ни один не даёт полной картины в одиночку, но вместе они закрывают большинство слепых зон.
- **Аудит OAuth-приложений в самом тенанте.** Консоли Microsoft 365 / Entra ID, Google Workspace и Яндекс 360 показывают список сторонних приложений, которым выданы разрешения, и запрошенные scope. Это первичный и самый достоверный источник. - **Логи IdP и согласий.** Журналы провайдера идентичности фиксируют события выдачи согласия (consent) — кто, когда и какому приложению разрешил доступ. - **Сетевые и DNS-данные, логи прокси/NGFW.** Помогают увидеть обращения к облачным сервисам, которые вообще не интегрированы через OAuth, но используются сотрудниками. - **Финансовые следы.** Подписки на SaaS в корпоративных расходах и на картах — частый способ найти сервисы, о которых ИБ не знает. - **SSPM-платформа.** Сводит инвентаризацию приложений, оценку OAuth-разрешений и аномалии в один поток. Как это соотносится с CASB и DLP — в разборе [SSPM vs CASB vs DLP](/research/sspm-vs-casb-vs-dlp).
Риск OAuth → мера
| Риск OAuth-интеграции | Чем опасно | Мера |
|---|---|---|
| Избыточные scope (read/write почты, диска) | Сервис видит больше, чем нужно для функции | Минимизация привилегий, запрос узких scope или отказ |
| Бессрочные refresh-токены | Доступ живёт месяцами, переживает смену пароля | Отзыв токена, ротация, ограничение времени жизни |
| Неактивные интеграции | Старые приложения с живым доступом к данным | Регулярный отзыв всего, что не используется |
| Неизвестный издатель приложения | Нет гарантий по обработке данных | Allowlist доверенных издателей, блок остальных |
| Согласие без участия ИБ (user consent) | Любой сотрудник раздаёт доступ сам | Admin consent workflow, ограничение user consent |
| Доступ в обход MFA и периметра | Токен работает по API, минуя шлюзы | Условный доступ, мониторинг аномалий по токенам |
| Сервисные/межприложенческие токены | Широкие права без привязки к человеку | Инвентаризация app-to-app, отдельный аудит |
Где чаще всего прячется риск теневого SaaS
Усреднённая редакционная оценка распространённости проблемных мест по открытым данным и практике. Это не статистика по вашему тенанту — фактическую картину даёт аудит OAuth-приложений.
Минимизация привилегий: принцип наименьших прав для SaaS
Главная мера против рискованных интеграций — наименьшие привилегии. Применительно к OAuth это означает три правила. Первое: приложение получает только те scope, которые нужны для его функции, и ничего сверх. Второе: согласие на доступ к корпоративным данным даёт не любой сотрудник, а администратор по процессу (admin consent), тогда как самостоятельное согласие пользователей ограничивается или отключается. Третье: всё, что не используется, регулярно отзывается — неактивная интеграция с живым токеном опасна не меньше активной.
Этот подход не блокирует бизнес: доверенные и нужные сервисы остаются, но проходят через allowlist и контроль разрешений. Запрет «всего облачного» обычно лишь загоняет теневой SaaS глубже, поэтому ставка делается на видимость и управляемость, а не на тотальные блокировки.
Наведение порядка с OAuth: процесс по шагам
-
01
Инвентаризация
Выгрузите из Entra ID / Google Workspace / Яндекс 360 полный список сторонних приложений с выданными разрешениями и издателями.
-
02
Аудит разрешений
Разметьте scope по чувствительности: доступ к почте, файлам, контактам, календарю — высокий риск; узкие профильные права — низкий.
-
03
Приоритизация
Поднимите наверх избыточные, неактивные и приложения от неизвестных издателей — с них и начинайте.
-
04
Отзыв токенов
Отзовите доступ у рискованных и ненужных интеграций; помните, что смена пароля токен не отзывает — нужен явный revoke.
-
05
Минимум привилегий
Включите admin consent workflow, ограничьте user consent, оставьте allowlist доверенных издателей и узкие scope.
-
06
Постоянный мониторинг
Поставьте регулярный пересмотр согласий и алерты на новые/аномальные выдачи токенов — наведение порядка не разовое.
Чек-лист контроля теневого SaaS и OAuth
Как мы оцениваем поставщиков
cyber-index.ru не продаёт места в рейтинге. Поставщики SSPM и SaaS Security сравниваются по проверяемым сигналам: подтверждённые внедрения и кейсы, отзывы и интервью клиентов, внешняя репутация, специализация, прозрачность и свежесть данных. Поэтому статью стоит читать в связке с [рейтингом SSPM и SaaS Security](/rating/sspm-saas-security): здесь — суть проблемы и меры, там — сравнение конкретных решений по подтверждённым фактам.
Следующий шаг
Разобрались с рисками — переходите к выбору инструментов контроля: **[рейтинг SSPM и SaaS Security →](/rating/sspm-saas-security)**. Полезно прочитать рядом: [SSPM простыми словами](/research/chto-takoe-sspm), [SSPM vs CASB vs DLP](/research/sspm-vs-casb-vs-dlp) и [рейтинг SSPM-решений 2026](/research/reyting-sspm-resheniy-2026).
Частые вопросы
Чем теневой SaaS отличается от теневого ИТ?
Теневой ИТ — это любое неучтённое ИТ, включая «железо» и локальный софт. Теневой SaaS — его облачная часть: сервисы и приложения, которые сотрудники подключают сами, в обход ИБ. Главный канал риска здесь — OAuth-интеграции с делегированным доступом к корпоративным данным.
Почему отзыв пароля не закрывает риск OAuth?
Потому что OAuth-токен выдаётся отдельно от пароля. Сброс пароля и даже включение MFA не аннулируют ранее выданный токен — сторонний сервис продолжает обращаться к вашим данным по API, пока доступ не отозвали явно. Поэтому нужен именно revoke токена.
Как быстро найти все подключённые OAuth-приложения?
Начните с консолей провайдеров идентичности: Microsoft Entra ID, Google Workspace, Яндекс 360 показывают сторонние приложения и запрошенные разрешения. Дополните логами согласий, данными прокси/NGFW и финансовыми следами подписок. Свести это в один поток помогают SSPM-платформы.
Можно ли просто запретить сотрудникам подключать SaaS?
Тотальный запрет обычно загоняет теневой SaaS глубже и тормозит работу. Эффективнее видимость и управляемость: admin consent на доступ к данным, allowlist доверенных издателей, минимум привилегий и регулярный отзыв ненужных интеграций.
Где сравнить инструменты контроля SaaS между собой?
В рейтинге SSPM и SaaS Security — решения ранжированы по подтверждённым сигналам, а не по рекламе.
Источники и метод проверки
Теневой SaaS — это облачные сервисы и приложения, которые сотрудники подключают сами, без согласования с ИБ и ИТ. Чаще всего риск приходит не через логин-пароль, а через OAuth: пользователь нажимает «Войти через корпоративный аккаунт» или «Разрешить доступ», и сторонний сервис получает токен с правами читать почту, файлы, календарь или переписку — иногда бессрочно и в обход MFA. **Если коротко:** проблема решается не запретами, а наведением порядка. Нужно обнаружить, какие приложения реально подключены к вашему тенанту, проверить, какие OAuth-разрешения они запросили, отозвать токены у рискованных и избыточных интеграций и дальше держать минимум привилегий. Ниже — как находить теневой SaaS, таблица «риск OAuth → мера», процесс наведения порядка по шагам и чек-лист. Сравнить инструменты контроля SaaS по подтверждённым сигналам можно в [рейтинге SSPM и SaaS Security](/rating/sspm-saas-security).