Cloudflare переводит CASB из режима панели состояния в сторону автоматизированной системы управления. 11 сентября 2026 года компания опубликовала сведения о политиках автоматического исправления в Cloudflare CASB — функции Cloudflare One, которая может реагировать на новую находку безопасности в SaaS. Первый практический сценарий знаком многим ИТ- и security-командам: файл или папка в Microsoft 365 либо Google Workspace расшарены слишком широко, а очередь безопасности растёт быстрее, чем люди успевают её разбирать.

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

Изменение важно потому, что контроль состояния SaaS обычно находился в неудобной промежуточной зоне. Инструменты обнаруживают открытые файлы, опасные OAuth-разрешения, неиспользуемые административные ключи и другие проблемы конфигурации, но исправление часто требует открыть другую консоль, проверить владельца, решить, было ли раскрытие намеренным, и вручную изменить настройку. Политики Cloudflare CASB сжимают этот процесс. Правило может сопоставить находку, отозвать опасный общий доступ через API провайдера SaaS и отправить вебхук в Slack, Teams, Jira, ServiceNow, Tines или на пользовательский endpoint.

На первый взгляд это история об эффективности. Отчасти так и есть. Но для ИТ-операторов важнее вопрос управления. Автоматическое исправление даёт платформе безопасности доступ на запись к пакетам для совместной работы, где хранятся договоры, финансовые таблицы, планы продукта, документы рядом с исходным кодом и данные клиентов. При грамотной настройке оно сокращает время раскрытия и превращает повторяющуюся уборку в управляемый сервис. При небрежной — создаёт новый путь изменения продакшена, способный нарушить легитимную совместную работу или скрыть ошибки политики за успешно отработавшей автоматизацией.

Что объявила Cloudflare

Cloudflare сообщает, что политики CASB доступны в разделе Cloud and SaaS findings панели Cloudflare One. Политика определяет, к какому поставщику и интеграции она относится, какой тип находки её запускает и какое действие должно выполниться. Действием может быть встроенное исправление, отправка вебхука или оба варианта одновременно.

На старте область встроенного исправления намеренно ограничена. Cloudflare указывает, что автоматическое исправление сейчас охватывает типы находок, связанные с файлами и папками в Microsoft 365 и Google Workspace. Проще говоря, система может использовать API SaaS-провайдера, чтобы отменить опасную настройку общего доступа, например публичный доступ к файлу. Отправка вебхуков шире: документация Cloudflare говорит, что вебхуки можно отправлять для данных о состоянии находок во всех интеграциях CASB, даже если для конкретного типа находки встроенное исправление недоступно.

Операторам также важно понимать устройство серверной части. Cloudflare описывает конвейер, в котором движок находок помещает сообщение оркестрации в Cloudflare Queues. Worker проверяет, соответствует ли ему политика. Если соответствует, задание передаётся в конвейер исправлений на базе Cloudflare Workflows. По словам Cloudflare, это даёт заданию устойчивое выполнение, обработку повторных попыток и паузу при ограничениях скорости, когда сторонний API замедляет работу или отклоняет вызовы. Компания заявляет целевой показатель: не более пяти минут от обнаружения до завершённого исправления.

Функция не работает задним числом. В документации Cloudflare сказано, что политики применяются к новым экземплярам подходящих находок, обнаруженным после создания или обновления политики. Существующие находки требуют отдельной обработки. Это небольшая, но существенная деталь эксплуатации: включение политики само по себе не разберёт старую очередь, а тихий журнал политики не доказывает, что текущий тенант уже чист.

Почему это больше, чем ещё один флажок CASB

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

Во многих средах это давно назрело. Microsoft 365 и Google Workspace больше не являются второстепенными инструментами. Это рабочие хранилища данных. Таблица, публично расшаренная ради удобства, может содержать прогноз продаж. Папка поставщика — идентификаторы клиентов. План продукта может попасть в презентацию и остаться доступным по ссылке после завершения проекта. Очистка через тикеты разумна, когда находки редки. Она ломается, когда платформы совместной работы создают тысячи событий общего доступа с минимальным трением.

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

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

Кого это затрагивает

Непосредственная аудитория — клиенты Cloudflare One, использующие Cloudflare CASB с интеграциями Microsoft 365 или Google Workspace. Команды безопасности, которые уже применяют CASB для находок состояния, теперь могут решать, какие из них заслуживают автоматического действия, а не ручного исправления. ИТ-администраторы тоже становятся частью решения: для включения исправления нужны более широкие права, чем для пассивного сканирования.

Для Microsoft 365 документация интеграции Cloudflare перечисляет разрешения на чтение для обычной видимости CASB и отдельный набор разрешений на чтение и запись для исправлений. В него входят такие высокопривилегированные области Microsoft Graph, как Files.ReadWrite.All, User.ReadWrite.All, Group.ReadWrite.All, Directory.ReadWrite.All, а также другие разрешения с возможностью записи — в зависимости от функций интеграции. Важно не то, что эти области неожиданны: инструмент не может изменить настройку SaaS без права на изменение. Важно, что интеграцию для исправлений нужно считать привилегированной, а не безобидным продолжением мониторинга.

Для Google Workspace Cloudflare описывает покрытие CASB для Gmail, Google Admin, Calendar, Drive и Gemini for Google Workspace; необходимы соответствующие административные права Workspace и Google Cloud. Командам, сосредоточенным на раскрытии данных в Google Drive, нужно выяснить, обладает ли интеграция только правами, необходимыми для видимости, или переведена на режим чтения и записи, требуемый для автоматических исправлений.

Более широкая аудитория — любая организация, стремящаяся сократить рутинную работу вокруг безопасности SaaS. Даже если она не использует Cloudflare, объявление отражает направление рынка. Границы между SSPM, CASB, DLP и SOAR становятся менее чёткими. Всё больше инструментов не только обнаруживают дрейф конфигурации, но и пытаются его исправить. Поэтому закупки, архитектура безопасности и ИТ-эксплуатация должны заранее задавать новые вопросы перед подключением инструмента к рабочему тенанту.

Практический безопасный шаблон внедрения

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

У хорошей первой политики есть пять свойств. Она относится к ограниченной интеграции. Нацелена на тип находки с низкой неоднозначностью. Имеет документированного бизнес-владельца. Отправляет вебхук туда же, где команда ведёт операции безопасности. И предусматривает откат или путь исключения для легитимной совместной работы, которую прервали.

Cloudflare позволяет совмещать исправление с отправкой вебхука. На раннем этапе это сочетание стоит сделать стандартным. Тихое исправление заманчиво: панели остаются чистыми. Но операторам нужен заметный след событий, пока они оценивают долю ложных срабатываний и влияние на бизнес. Вебхук в Jira, ServiceNow или SOAR-систему может сохранить контекст: какая находка сработала, какой файл затронут, завершилось ли действие успешно и какая политика выполнилась.

Cloudflare также выводит два класса журналов для этой функции. Журналы Admin Activity фиксируют изменения политик: создание, редактирование и отключение. Журналы политик Cloud and SaaS Security фиксируют результаты выполнения: находку, затронутый файл, успех или ошибку, а также детали вроде ответа unauthorized или ограничения скорости API поставщика. Такое разделение полезно. Аудит конфигурации отвечает на вопрос, кто изменил правило. Аудит выполнения — что именно сделало правило. Зрелому внедрению нужны оба журнала.

Компромисс с разрешениями

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

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

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

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

Где нужны вебхуки

Сторона вебхуков может оказаться для многих команд не менее полезной, чем встроенное исправление. Документация Cloudflare говорит, что CASB отправляет JSON-полезную нагрузку с метаданными события, сведениями о находке, данными актива и метаданными, специфичными для находки. Благодаря этому команды могут отправлять события состояния в существующие системы, не давая Cloudflare права напрямую исправлять каждую категорию.

Например, находка о публичном файле с высокой уверенностью может запустить встроенное исправление и открыть тикет. Находка с меньшей уверенностью — OAuth-разрешение или административная настройка — может только отправить вебхук в очередь разбора. Для чувствительного отдела можно направить все подходящие находки в SOAR-процесс, который дополнит событие владельцем файла, членством в группе, метками данных и недавним доступом, а уже затем решит, действовать ли автоматически.

Такой многоуровневый подход здоровее, чем модель «всё или ничего». Встроенное исправление подходит там, где правило ясно. Вебхуки — там, где правилу нужен дополнительный контекст. Ручная проверка — там, где цена неправильного изменения высока. Со временем находки, которые снова и снова разрешаются одинаково, можно переводить из проверки в автоматизацию.

Что проверить до включения

Начните с инвентаризации. Подтвердите, какие интеграции Microsoft 365 и Google Workspace существуют в Cloudflare CASB, работают ли они только на чтение или на чтение и запись и какие бизнес-подразделения покрывают. Не считайте, что граница интеграции совпадает с границей компании. В крупных организациях часто есть несколько тенантов, домены приобретённых компаний, региональные рабочие пространства и устаревшие административные схемы.

Затем изучите таксономию находок. Документация Cloudflare по политикам исправления перечисляет поддерживаемые находки для Google Workspace и Microsoft 365. Сопоставьте эти типы с внутренними формулировками политики. Если внутреннее правило говорит, что конфиденциальные финансовые файлы не должны быть публичными, а CASB сообщает лишь о публичной доступности файла, всё равно нужен способ отличать финансовые документы от публичных маркетинговых материалов. Значимыми могут оказаться путь папки, группа владельца, DLP-метки, расположение диска и метаданные файла.

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

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

Сбои, которые нужно предусмотреть

Очевидный сценарий — чрезмерное исправление: политика отзывает доступ, который должен был остаться открытым. Это может сорвать проверку партнёром, закупочный процесс или передачу результата клиенту. Решение не в том, чтобы навсегда отказаться от автоматизации. Нужно узко ограничить первые политики и отслеживать последствия.

Более тихий сценарий — недостаточное исправление. Команда включает политику и считает проблему решённой, хотя старые находки остаются нетронутыми: политики применяются только к новым обнаруженным находкам. Другой вариант — дрейф разрешений: администратор SaaS отзывает или меняет права интеграции, после чего исправления начинают завершаться ошибками. В документации Cloudflare по устранению проблем CASB администраторам уже предлагается проверять разрешения при сбоях исправления. Такая проверка должна войти в операционные инструкции.

Ограничения скорости — ещё одна практическая проблема. Cloudflare говорит, что Workflows может приостановить и повторить запрос, когда API поставщика ограничивает частоту. Это помогает сохранить задания, но не отменяет необходимости понимать фактическое время исправления во время крупного события. Если общая ошибка конфигурации порождает тысячи находок, команда должна знать, ожидает ли она очистку за минуты, часы или поэтапными пакетами.

Есть и сбой аудита. Если исправление прошло успешно, но доказательства разбросаны по разным системам, командам соответствия всё равно будет трудно показать, что произошло. Связывайте журналы выполнения политики с тикетом или записью инцидента. Чистая панель не равна доказательству.

Почему это задача ИТ-эксплуатации, а не только безопасности

Раскрытие данных SaaS часто называют проблемой безопасности, но операционная ответственность разделена. ИТ-администраторы управляют тенантом, группами идентификации, настройками общего доступа и очередью поддержки. Команды безопасности определяют недопустимое раскрытие и следят за риском. Бизнес-команды создают давление совместной работы, из-за которого появляются исключения. Автоматизация касается всех троих.

Поэтому важны названия и владельцы политик. Имя public-share-fix менее полезно, чем название, прямо указывающее цель и действие, например revoke-public-edit-access-drive-non-exempt-users. До открытия деталей должно быть понятно, что произойдёт. В описании стоит указать бизнес-правило, владельца, ожидаемый маршрут уведомлений и контакт для отката.

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

Сигнал для рынка

Cloudflare не единственная компания, которая двигает продукты безопасности к автоматическим действиям. Вся категория испытывает давление: нужно снижать усталость от предупреждений и доказывать сокращение времени до исправления. Здесь примечательна связь между находками состояния SaaS и прямыми изменениями общего доступа к файлам в ведущих офисных пакетах. Это повседневная рабочая поверхность обычных сотрудников, а не нишевый инфраструктурный слой.

Запуск также соответствует более широкой стратегии Cloudflare — строить средства безопасности на собственных примитивах платформы разработчиков. Компания использует Queues, Workers и Workflows для клиентского конвейера автоматизации безопасности. Для покупателей важнее не сама архитектурная формулировка, а операционный контракт, который она подразумевает: устойчивые задания, повторы, журналы аудита и предсказуемое поведение при отказе сторонних API. Именно об этих свойствах следует спрашивать любого поставщика автоматического исправления.

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

Практические следующие шаги

Для клиентов Cloudflare CASB первый шаг — проверка, а не переключатель. Определите три повторяющиеся находки SaaS, которые создают реальное раскрытие и отнимают время людей. Для каждой спросите, всегда ли правильный ответ одинаков. Если да, находка может быть кандидатом на исправление. Если иногда — начните с маршрутизации вебхука и обогащения контекста.

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

Для клиентов других поставщиков используйте объявление как контрольный список для собственных инструментов. Может ли ваша SSPM- или CASB-система пройти путь от находки к исправлению? Если может, можно ли ограничить действие тенантом, интеграцией, типом находки и бизнес-подразделением? Умеет ли она отправлять события в существующую систему процессов? Хранит ли отдельные журналы изменений политики и действий во время выполнения? Объясняет ли обработку лимитов и повторные попытки? Делает ли изменения разрешений очевидными до их выдачи?

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

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

Источники