CASB контроль облачных приложений: когда нужен и что дает

Почему облачные приложения нужно контролировать даже on-prem

On-prem стратегия часто звучит как "все под контролем": свои серверы, свои сети, свои правила. Но сотрудники и подрядчики все равно каждый день используют облачные сервисы. Они появляются не через ИТ, а через браузер и мобильные приложения: обмен файлами, заметки, дизайн, CRM, онлайн-опросы, переводчики, сервисы для кадров и бухгалтерии.

Облако становится самым быстрым обходным путем, когда нужной функции нет в корпоративной системе или ее долго согласовывать. Поэтому риски из облака остаются даже в компании, где ключевые системы стоят в своем дата-центре. Здесь CASB дает заметный эффект: он помогает видеть и управлять тем, что происходит за пределами привычного периметра.

Что обычно ускользает от классической защиты

Классические средства хорошо защищают сеть и устройства, но хуже видят действия внутри SaaS. Часто остаются "слепые зоны": вход с личных аккаунтов, шаринг ссылками "для всех", подключение внешних приложений через OAuth, работа из дома, где трафик идет мимо корпоративного прокси.

Потери обычно случаются не из-за "взлома", а из-за операционной небрежности. Например, данные уходят в теневые SaaS и потом оказываются у бывших сотрудников или внешних адресатов. Доступы остаются активными из-за токенов и постоянных сессий даже после смены пароля. ИТ тратит дни на разбор инцидента, потому что нет единого журнала действий. А комплаенс и закупки неожиданно находят неучтенные сервисы и платежи по корпоративным картам.

CASB помогает снизить эти риски без ломки on-prem подхода: вы не переносите системы в облако, вы наводите порядок в том, чем люди уже пользуются.

На каких симптомах стоит задуматься о CASB

Если узнаете себя хотя бы в нескольких пунктах, пора обсуждать пилот:

• ИТ узнает о новом SaaS от бухгалтерии, когда приходят счета.
• Сотрудники пересылают рабочие файлы на личную почту или в мессенджеры.
• Есть Microsoft 365, Google Workspace или другие SaaS, но нет ясных правил шаринга и работы с внешними гостями.
• Доступ к SaaS выдают быстро, а отзыв прав и контроль подключенных приложений не отлажены.
• После инцидента сложно ответить на простые вопросы: кто скачал, кому расшарил, откуда входил.

Для организаций с высокими требованиями к прозрачности и поддержке (например, в госсекторе и финансах) это особенно критично: контроль должен сохраняться, даже когда данные и доступы уходят в сторонние облака.

Что делает CASB простыми словами

CASB (Cloud Access Security Broker) - это контролер для облачных приложений. Он помогает компании понять, какие облачные сервисы реально используются, и задавать правила работы: что можно загружать, откуда заходить, какие данные нельзя отправлять и что делать при нарушении.

Удобная метафора - дополнительный слой между пользователями и SaaS. Важно, что CASB не требует "перевести всю ИТ в облако": даже при on-prem стратегии люди все равно используют почту, файлообменники, CRM и десятки небольших сервисов.

Где он стоит в архитектуре

CASB может работать по-разному, но цель одна: видимость и управляемость.

Самые частые варианты:

• Интеграция с самим облаком (например, Microsoft 365, Google Workspace, Salesforce). Тогда видно действия внутри сервиса и проще реагировать.
• Контроль трафика (прокси или агенты на устройствах). Тогда видно, куда пользователь идет, и можно блокировать или ограничивать.
• Анализ журналов и событий (из сети, с конечных устройств, от провайдера идентификации). Тогда сигналы связываются в одну картину.

Видимость, политики и реагирование

Видимость отвечает на вопрос "что у нас происходит": какие SaaS используются (включая теневые), кто куда загружает файлы, какие аккаунты активны, откуда идут входы.

Политики отвечают на вопрос "как должно быть": например, запретить загрузку документов с персональными данными в личные облака, разрешить вход в корпоративные SaaS только с управляемых устройств, требовать MFA при подозрительном входе.

Реагирование отвечает на вопрос "что делаем, если правило нарушено": оповещение, блокировка действия, отзыв токена, завершение сессии, карантин файла, запрос подтверждения у сотрудника.

Пример из жизни: бухгалтерия пытается сохранить отчет в личный облачный диск. CASB распознает тип данных, останавливает загрузку и подсказывает безопасный корпоративный вариант.

Какие задачи CASB не решает

CASB не заменяет антивирус/EDR, межсетевой экран, DLP на рабочих станциях и управление доступом (IAM). Он не исправит слабые пароли и не сделает сервис безопасным, если в нем изначально неверно настроены права.

Обычно CASB дополняют управлением устройствами (чтобы отличать корпоративные ноутбуки от личных), точечным DLP для конечных точек и понятным процессом реагирования.

Типовые угрозы: теневые SaaS, утечки, токены

Даже если основная инфраструктура у вас on-prem, сотрудники все равно используют облачные сервисы. Это удобно и быстро, но для безопасности и соответствия требованиям появляется слепая зона: не видно, где живут данные и кто к ним имеет доступ.

Теневые SaaS: как они появляются

Теневые SaaS обычно подключают не из злого умысла. Отделу нужно решить задачу быстро: обменяться файлами с подрядчиком, собрать форму, согласовать макет, провести онлайн-встречу, сделать рассылку. Если корпоративный инструмент неудобен или нет доступа, люди находят альтернативу.

Проблема в том, что такие сервисы обходят правила: нет единой политики, нет контроля доступа, нет понятного владельца, а учетные записи часто создаются на личную почту. В итоге данные компании оказываются в сервисе, про который ИБ узнает только после инцидента или проверки.

Утечки: чаще всего это обычные действия

Большинство утечек в SaaS происходят не из-за хакеров, а из-за привычных действий пользователей. Сотрудник отправляет файл себе в личное облако, чтобы поработать дома. Или делает публичную ссылку "на пару дней", а потом забывает закрыть доступ.

Самые частые причины - пересылка файлов в личные аккаунты и внешним адресатам, публичные ссылки "доступно всем у кого есть ссылка", ошибочные права ("всем в компании" вместо конкретной группы), совместная работа с подрядчиками без понятного процесса выдачи и отзыва прав.

Для комплаенса это тоже риск: данные могут оказаться "не там, где нужно" - в неподходящем регионе, в неподконтрольном хранилище или в сервисе без нужных журналов и сроков хранения.

Токены и сессии: кража может быть опаснее пароля

Многие сервисы после входа выдают токен или сессионный "пропуск". Если злоумышленник перехватывает этот пропуск, он получает доступ без знания пароля и иногда даже без прохождения второго фактора. Такое случается из-за фишинга, вредоносных расширений, зараженного ПК, перехвата в браузере.

Опасность в том, что со стороны это выглядит как обычная активность пользователя: та же учетная запись, тот же сервис, привычные действия. Если нет контроля сессий и нормальной корреляции событий, расследование затягивается.

Еще одна боль - отсутствие единой картины. Когда события разбросаны по разным SaaS, сложно быстро ответить: кто открыл доступ, кому, на какой файл, откуда входили, что скачали и что было дальше. CASB закрывает эту дыру в наблюдаемости: помогает предотвратить часть инцидентов и ускоряет разбор уже случившихся.

Ключевые функции, которые дают быстрый эффект

Быстрый эффект от CASB начинается не с "идеальной политики на все случаи", а с нескольких вещей, которые сразу показывают реальную картину и перекрывают самые частые риски. Лучше целиться в результат за недели, а не за кварталы.

Видимость: какие облака используются на самом деле

Первая победа - инвентаризация. CASB показывает теневые SaaS, которые не проходили согласование: где сотрудники хранят файлы, как отправляют документы подрядчикам, чем заменяют корпоративные чаты.

Полезно сразу собрать несколько простых метрик:

• топ-20 SaaS по пользователям и трафику;
• сервисы, где активно загружают и выгружают файлы;
• приложения, где сотрудники работают с личной почтой или без корпоративной аутентификации;
• новые приложения, появившиеся за последние 30 дней.

Контроль доступа: сессии, устройства и рискованные входы

После видимости логичный шаг - управляемый доступ. Хорошо работает принцип "разрешить, но безопасно": вход только с управляемых устройств, ограничения по подозрительным локациям, запрос MFA при риске.

Отдельная ценность - контроль сессий и токенов. Можно ограничить действия в браузере (например, запретить скачивание) и при подозрении принудительно завершить активные сессии, чтобы украденный токен не жил неделями.

DLP и проверки конфигураций SaaS

DLP дает эффект, когда он точечный. Например, блокировать отправку файлов с ИИН/паспортными данными в личные хранилища или предупреждать при попытке сделать ссылку "для всех".

Параллельно полезны проверки конфигураций SaaS: опасные настройки общего доступа, внешние коллаборации без контроля, отключенные журналы аудита.

Реакции: оповещения и быстрые блокировки

Хорошее реагирование - это не "шумный SOC", а понятные действия: уведомить владельца сервиса, заблокировать конкретное приложение, изолировать сессию, открыть расследование по пользователю.

Пример: бухгалтерия начала использовать новый сервис для обмена актами. CASB видит массовую выгрузку, находит шаблоны персональных данных и замечает, что доступ идет с личных устройств. Быстрая мера - разрешить сервис только с корпоративных устройств, запретить скачивание и включить предупреждение при внешнем шаринге. Риск падает сразу, без долгой перестройки процессов.

Netskope, Defender for Cloud Apps, Skyhigh: как сравнивать

Сравнивать CASB лучше не по списку функций, а по тому, как быстро он решает ваши реальные проблемы. Обычно это 3-5 повторяющихся сценариев: теневые SaaS, унос данных в личные хранилища, "висящие" токены, непонятно кто и откуда сейчас в системе.

Netskope часто выбирают, когда нужен сильный контроль на уровне доступа и поведения пользователей: хорошая видимость по SaaS, гибкие политики, контроль сессий (например, ограничить загрузку файлов, запретить копирование, потребовать дополнительную проверку по риску). Это удобно, когда облаков много и не хочется жестко привязываться к одной экосистеме.

Microsoft Defender for Cloud Apps (бывш. MCAS) обычно проще всего стартует, если вы уже в экосистеме Microsoft: Microsoft 365, Entra ID, Defender, Purview. Часто сильная сторона здесь в скорости и в том, что расследования, алерты и базовые политики оказываются рядом с привычными инструментами.

Skyhigh CASB стоит оценивать прежде всего по удобству ежедневного сопровождения (политики, отчеты) и по качеству интеграций с теми SaaS, которые у вас реально используются. У разных поставок и версий акценты могут отличаться, поэтому проверяйте на практике.

Чтобы сравнение было понятным уже на пилоте, используйте вопросы:

• Интеграции: какие SaaS из ваших топ-10 поддерживаются, что доступно через API, а что только через прокси/агенты.
• DLP: насколько точно ловит ваши типовые данные и сколько ложных срабатываний.
• Токены и сессии: видит ли опасные OAuth-приложения, умеет ли отзывать токены и ограничивать сессии по риску и устройству.
• Отчеты и расследования: можно ли быстро ответить "кто скачал", "куда загрузил", "с какого IP/страны", "что было дальше".
• Встраивание в текущую ИБ: SIEM/SOAR, журналы, роли, делегирование, работа 24/7.

Практичный подход: выбрать 3-5 сценариев и прогнать все продукты по одному чек-плану. Например: обнаружить теневой SaaS, заблокировать загрузку файлов в личный аккаунт, найти и отозвать подозрительный токен, настроить алерт на массовое скачивание, выгрузить отчет для руководителя.

Пошагово: как запустить CASB без долгого проекта

Быстрый запуск CASB начинается не с идеальной схемы, а с видимости. Даже при on-prem стратегии сотрудники используют облака, и задача первого этапа простая: понять, какие SaaS уже живут в сети, и закрыть самые рискованные действия.

Шаг 1. Соберите инвентарь SaaS из того, что уже есть

Не обязательно ставить новые железки. Часто хватает логов с межсетевого экрана, прокси, DNS, VPN, почтового шлюза или агента на рабочих станциях. За 1-2 недели обычно видно, какие домены и приложения используются, кто их открывает и какие объемы данных уходят наружу.

Чтобы не распыляться, выделите 10-20 самых популярных облачных приложений и отдельно пометьте редкие и неизвестные: там чаще всего и прячется риск.

Шаг 2. Включите политики, которые дают быстрый эффект

Правила должны быть понятны пользователям и легко объясняться службе поддержки. Хороший стартовый набор:

• блокировать неизвестные облачные хранилища и файлообменники, оставив утвержденные варианты;
• ограничить загрузку файлов в личные аккаунты (особенно в сегментах с чувствительными данными);
• запретить публикацию ссылок "для всех по ссылке" для корпоративных файлов (если сервис это поддерживает);
• включить контроль токенов и сессий: выявлять долгоживущие токены и отзывать их при риске.

Смысл не в том, чтобы "запретить все", а в том, чтобы убрать самые частые пути утечек: загрузки, шаринг и бесконтрольные сессии.

Шаг 3. Настройте оповещения, а не шум

Оповещения должны приходить тем, кто реально реагирует. Начните с нескольких сигналов: массовая выгрузка данных, вход из необычной страны, невозможное перемещение (два входа из разных локаций за короткое время), резкий рост скачиваний, новые и подозрительные OAuth-разрешения.

Шаг 4. Зафиксируйте правила игры: кто подключает новые SaaS

Без процесса согласования CASB превращается в вечную погоню. Определите владельца каталога разрешенных приложений и простой маршрут согласования (например, ИБ + владелец данных + ИТ). Отдельно решите, что делаете с "серой зоной": временно разрешаете с ограничениями или блокируете до проверки.

Шаг 5. Проведите пилот на узкой группе

Выберите одну группу пользователей и один тип данных (например, договоры или персональные данные). Пилот обычно занимает 2-4 недели и заканчивается измеримыми результатами:

• сколько теневых SaaS нашли и что из этого реально нужно бизнесу;
• сколько попыток выгрузки или опасного шаринга остановили;
• сколько рискованных токенов и сессий выявили и отозвали.

Заранее договоритесь о критериях успеха. Это экономит месяцы споров и помогает быстро масштабировать настройки.

Реалистичный пример: теневой SaaS в отделе и быстрые меры

Маркетинговый отдел готовит материалы для тендера и начинает обмениваться макетами через "удобный" публичный файлообменник. Вроде бы ничего страшного: ссылка на папку, быстро, без заявок в ИТ. Через пару недель появляются проблемы: ссылки уходят внешним подрядчикам, часть файлов попадает не тем адресатам, а один сотрудник хранит доступ в браузере, и с его учеткой скачивают документы после увольнения.

Когда появляется CASB, выясняется, что сервисов не один: кто-то использует один файлообменник, кто-то другой, а часть людей пересылает файлы через личную почту. CASB видит это по трафику и журналам входа, показывает, какие приложения используются, кем и как часто, и где риск выше: нет корпоративной аутентификации, включены публичные ссылки, живут "длинные" сессии.

Дальше важен не запрет, а быстрые правила, которые не ломают работу. Обычно в первые дни вводят ограничения и понятную альтернативу:

• утвердить корпоративное хранилище и дать простой шаблон структуры папок под проект;
• для несанкционированных файлообменников запретить загрузку, но оставить просмотр, если это действительно нужно;
• ограничить публичные ссылки (или запретить их) и включить контроль срока жизни;
• настроить контроль сессий: при подозрительном входе требовать повторную проверку, при увольнении быстро отзывать токены;
• самые рискованные сервисы блокировать полностью, но после короткого периода уведомлений.

Эффект измеряют не количеством блокировок, а тем, что важно бизнесу и ИТ. Через 2-4 недели обычно видно меньше инцидентов с неверными получателями, меньше случаев "потеряли файл по ссылке", быстрее разборы: кто и где делился документами. Появляется единая картина по отделам и типам данных.

Частые ошибки при внедрении CASB

Разочарование в CASB чаще связано не с технологией, а с ожиданиями. Инструмент быстро показывает много фактов о теневых SaaS и рискованных действиях, но без простых правил и владельцев процессов это превращается в шум.

Включают все политики сразу и тонут в алертах

Частая ошибка - сразу включить десятки детектов, DLP и поведенческих правил. В итоге ИБ получает лавину событий, а бизнес слышит только про запреты.

Начните с 5-10 сигналов, которые важны именно вам: массовые выгрузки, доступ из необычных стран, публикация файлов наружу, использование несанкционированных хранилищ. Когда команда научилась разбирать эти случаи, добавляйте следующий слой.

Игнорируют владельцев данных и согласования

CASB часто вскрывает ситуацию, когда "все вроде бы нормально", но данные уходят в личные облака, а никто формально не отвечает за решения. Если не назначить владельцев данных (финансы, HR, юристы, ИТ), каждый инцидент превращается в спор.

Договоритесь о простом маршруте: кто подтверждает, что это рабочие данные, кто принимает риск, кто дает исключение и на какой срок.

Делают слишком жесткие блокировки и ломают работу

Резкие запреты (например, полный запрет личных аккаунтов или загрузок в облако) часто останавливают процессы, особенно там, где много подрядчиков и больших файлов. Люди начинают обходить ограничения через новые сервисы, и теневой SaaS растет.

Рабочая схема обычно ступенчатая: сначала наблюдение, затем мягкие ограничения (предупреждения, ограничения на внешний шаринг), и только потом точечные блокировки.

Забывают про токены, OAuth и сторонние приложения

Многие фокусируются на файлах и загрузках, но пропускают тихий риск: доступ через OAuth-токены и сторонние приложения. Пользователь может выдать разрешения "читать почту" или "доступ ко всем файлам", и дальше утечка пойдет без логина и привычных признаков.

Минимальный набор: отслеживать новые согласия OAuth, запрещать избыточные права, регулярно пересматривать выданные токены, быстро отзывать доступ при увольнении и при подозрительной активности.

Не задают критерии успеха пилота

Если пилот запускают без измеримых целей, он заканчивается фразой "ну, вроде работает". Заранее определите, что считается быстрым эффектом: сколько теневых SaaS выявить, какие закрыть или легализовать, на сколько снизить внешние шаринги, сколько опасных OAuth-разрешений отозвать, за какое время реагировать на массовую выгрузку.

Короткий чеклист: нужен ли вам CASB прямо сейчас

Если вы считаете, что у вас "все on-prem", это еще не значит, что облака нет. Почта, мессенджеры, обмен файлами, CRM, трекеры задач и расширения в браузере часто появляются сами, без участия ИТ. Когда эти сервисы влияют на данные и доступы, CASB становится не "проектом на потом", а быстрым способом закрыть самые частые риски.

Ответьте на пять вопросов. Если хотя бы на два вы не можете уверенно сказать "да", CASB, скорее всего, нужен уже сейчас:

• Можете ли вы назвать реальные топ-20 облачных приложений, которыми пользуются сотрудники (по факту трафика и входов), а не "разрешенный список" на бумаге?
• Есть ли понятные правила обмена файлами: что можно отправлять наружу, когда допустимы публичные ссылки, как долго они живут и кто их контролирует?
• Видите ли вы подключения сторонних приложений через OAuth ("Войти через Google/Microsoft"), и умеете ли быстро отключать рискованные токены и выданные разрешения?
• Понимаете ли вы, где оказываются чувствительные данные (персональные, финансы, коммерческая тайна), и кто имеет к ним доступ в облачных сервисах?
• Есть ли простой план реагирования: кто получает сигнал об инциденте, кто блокирует сессию или доступ, кто связывается с владельцем бизнеса и как фиксируются действия?

Самый быстрый эффект обычно дают три вещи: видимость теневых SaaS, контроль публичных ссылок и отключение лишних OAuth-токенов.

Следующие шаги: пилот, критерии успеха и кому поручить

Чтобы CASB не стал "еще одним инструментом", начните с двух вопросов: какие облачные приложения реально используются и где риск самый ощутимый. Во многих организациях быстрый результат дают простые ограничения для самых популярных SaaS и базовая защита от утечек.

С чего начать пилот: 2-3 сценария с быстрым эффектом

Выберите то, что можно проверить за 2-4 недели:

• Теневые SaaS: обнаружить топ-10 сервисов, найти владельцев, договориться что разрешаем и что блокируем.
• Утечки через загрузку файлов: включить базовые DLP-правила для персональных данных и финансовых документов.
• Токены и сессии: отозвать подозрительные сессии, ограничить вход с неуправляемых устройств, включить условный доступ.
• Аномальная активность: массовые скачивания, входы из необычных геолокаций, подозрительные OAuth-разрешения.
• Права в критичных SaaS: проверить публичные ссылки и внешний шаринг.

Цель пилота зафиксируйте простыми словами: "уменьшить долю несанкционированных облаков", "снизить риск утечки" или "навести порядок с токенами и внешним доступом".

Какие данные собрать заранее (без сложной аналитики)

На старте не нужна идеальная картина. Хватит минимума:

• список ключевых SaaS (включая неофициальные) и кто ими пользуется;
• какие типы данных туда попадают (персональные данные, договоры, медданные, исходники);
• как устроен доступ (SSO, MFA, локальные учетные записи, гостевой доступ);
• где сейчас есть видимость (логи прокси, firewall, EDR, почта, Microsoft 365);
• 3-5 прошлых инцидентов или почти инцидентов, которые не должны повторяться.

Чтобы встроить CASB в общую архитектуру, заранее определите точки интеграции: IdP (учетки и MFA), SIEM (события), DLP (правила), EDR (состояние устройства) и процесс реагирования (кто подтверждает блокировку, кто общается с бизнесом).

Роли обычно делят так: владелец со стороны ИБ отвечает за политики и риск, владелец со стороны ИТ - за интеграции и доступы, бизнес-владелец SaaS - за то, чтобы ограничения не ломали работу.

Если нужен быстрый и аккуратный пилот, его часто отдают партнеру по системной интеграции: подключить источники логов, настроить базовые политики, проверить "не ломаем бизнес" и подготовить инфраструктуру под ИБ-задачи. В Казахстане это, например, делает GSE.kz: как производитель и системный интегратор они могут закрыть не только внедрение, но и сопутствующую инфраструктуру (рабочие станции и серверы для журналирования, SIEM или изолированных тестовых зон) с дальнейшей поддержкой.