«О CASB обычно говорят в двух крайностях: как о волшебной таблетке для облачной безопасности или как об очередном дорогом и бесполезном продукте вендоров. На деле это не продукт, а архитектурная концепция, и её смысл — не в том, чтобы встать ‘между’ пользователем и облаком, а в том, чтобы создать единый центр управления политиками для того хаоса SaaS-инструментов, который уже живёт в компании без спроса.»
CASB: почему концепция важнее продукта
Cloud Access Security Broker, или CASB, появился как ответ на стихийное проникновение облачных сервисов в корпоративную среду. Традиционные границы сети размылись — данные теперь не в локальном дата-центре, а в сотнях сторонних SaaS-приложений, к которым сотрудники подключаются напрямую. Межсетевые экраны и классические DLP слепнут, когда трафик шифруется и уходит прямо в интернет. CASB задумывался как «посредник» (broker), который восстанавливает видимость и контроль там, где классические средства его теряют.
Ключевая ошибка — рассматривать CASB исключительно как готовый коммерческий продукт. На деле, это в первую очередь набор функциональных возможностей, которые можно реализовать разными способами: через специализированный шлюз, агенты на конечных точках, интеграцию с провайдером идентификации (IdP) или API облачных платформ. Важно понять, какую именно проблему вы решаете, и только потом выбирать архитектуру.
Четыре основных столпа CASB
Функциональность любого CASB строится вокруг четырех ключевых возможностей, известных как «четыре кита».
Видимость (Visibility)
Вы не можете контролировать то, чего не видите. Первая задача CASB — составить полную инвентаризацию всех облачных сервисов, используемых в организации. Речь не только о разрешённых корпоративных пакетах, но и о «теневом IT» — тех сервисах, которые сотрудники начали использовать самостоятельно. Современные CASB-решения анализируют сетевой трафик и журналы событий, чтобы составить рейтинг риска для каждого обнаруженного приложения, основываясь на таких факторах, как сертификация безопасности, юрисдикция данных и репутация.
Соответствие требованиям (Compliance)
CASB помогает привести использование облаков в соответствие с внутренними политиками и внешними регуляторными требованиями, такими как 152-ФЗ, приказы ФСТЭК или отраслевые стандарты. Решение может автоматически обнаруживать нарушения: например, хранение персональных данных в публичном облачном хранилище с доступом по ссылке, использование несертифицированных криптосредств для передачи информации или доступ к корпоративным ресурсам из геолокации, не входящей в белый список.
Защита данных (Data Security)
Это ядро функционала, близкое к традиционной DLP, но адаптированное для облачной среды. CASB может классифицировать данные (например, находить номера паспортов, банковские карты или коммерческую тайну) как в движении, так и в состоянии покоя внутри облачных хранилищ. На основе классификации применяются политики: шифрование чувствительных файлов перед их сохранением в облаке, блокировка загрузки определённых типов данных или маскирование конфиденциальных полей при просмотре с неподконтрольных устройств.
Защита от угроз (Threat Protection)
CASB анализирует поведение пользователей и приложений для выявления аномалий, указывающих на потенциальную угрозу. Например, массивная выгрузка файлов в нерабочее время, одновременный вход учётной записи из двух географически удалённых точек или подозрительная активность привилегированного администратора. Интеграция с SIEM и SOAR-платформами позволяет автоматизировать реакцию на такие инциденты: принудительный логаут пользователя, сброс сессии или эскалацию события в службу безопасности.
Режимы развёртывания: от прокси до API
То, как CASB реализует свои функции, зависит от выбранного режима работы. Часто используются комбинации нескольких режимов для максимального покрытия.
- Прокси-режим (Forward/Reverse Proxy): Классический подход, когда весь трафик к облачным сервисам перенаправляется через CASB. Это даёт возможность инспектировать и контролировать трафик в реальном времени, включая защиту от угроз и DLP. Однако такой режим может создавать задержки, требует сложной настройки маршрутизации и плохо подходит для мобильных приложений, которые не используют корпоративный VPN.
- API-режим: CASB подключается напрямую к API облачных провайдеров (таких как Яндекс 360, VK Workspace, S3-совместимые хранилища). Это позволяет проводить аудит конфигураций, сканировать данные на предмет нарушений политик и управлять правами доступа постфактум. Режим не требует изменения сетевых потоков, но работает не в реальном времени, а с некоторой периодичностью.
- Режим на основе агентов (Endpoint Agent): Лёгкие агенты устанавливаются на устройства пользователей (ноутбуки, смартфоны) и перехватывают трафик на уровне операционной системы. Это эффективно для защиты данных на неподконтрольных сетях, но требует управления флотом устройств.
- Режим на основе IdP (Identity Provider): CASB интегрируется с поставщиком идентификации (например, AD FS, Keycloak) и анализирует контекст аутентификации (устройство, местоположение, роль). Политики применяются на этапе предоставления доступа к приложению.
CASB и российская регуляторика: точки пересечения
В контексте российского законодательства, особенно 152-ФЗ о персональных данных и требований ФСТЭК, CASB становится не просто удобным инструментом, а потенциально необходимым элементом.
| Требование / Задача | Как помогает CASB |
|---|---|
| Инвентаризация и классификация ИСПДн (152-ФЗ) | Автоматическое обнаружение всех облачных сервисов, обрабатывающих ПДн, и оценка их рисков. |
| Контроль доступа и учёт событий (требования ФСТЭК) | Детальный мониторинг действий пользователей в облачных приложениях (кто, когда, что делал), централизованный сбор журналов. |
| Защита от утечек информации (УЗ) | DLP-функции для классификации и блокировки передачи ПДн или гостайны через неавторизованные каналы. |
| Обеспечение использования сертифицированных СКЗИ | Контроль за применением разрешённых средств шифрования при передаче данных в облако и хранении в нём. |
| Ограничение трансграничной передачи данных | Политики, блокирующие доступ к облачным сервисам или загрузку данных в них, если их ЦОДы находятся за пределами нужной юрисдикции. |
Типичные ошибки при внедрении
Внедрение CASB часто проваливается не из-за плохого продукта, а из-за ошибочного подхода.
- Внедрение без цели: Покупка «коробки» CASB как серебряной пули, без чёткого понимания, какие именно риски нужно снизить в первую очередь. В результате разворачиваются все политики сразу, что вызывает шквал ложных срабатываний и протесты пользователей.
- Игнорирование человеческого фактора: Жёсткая блокировка «теневого IT» без предложения альтернатив. Сотрудники найдут обходные пути, и безопасность только снизится. Эффективнее сначала использовать CASB в режиме мониторинга, чтобы понять реальные бизнес-потребности, а затем внедрять санкционированные аналоги.
- Недооценка интеграций: CASB не должен работать в вакууме. Его ценность многократно возрастает при интеграции с SIEM, SOAR, IdP и ITSM-системами. Без этого он останется просто дорогим генератором отчётов.
- Фокус только на техническом контроле: Забывают, что CASB — также мощный инструмент для аудита и отчётности. Не используют его возможности для демонстрации соответствия регуляторам или для внутренних проверок.
Что дальше: CASB, SASE и будущее периметра
Концепция CASB не стоит на месте. Она естественным образом эволюционирует и встраивается в более широкие архитектурные модели, такие как SASE (Secure Access Service Edge). SASE объединяет сетевые и security-функции (SD-WAN, Firewall as a Service, CASB, Zero Trust Network Access) в едином облачном сервисе. В этой модели CASB теряет свою «коробочную» индивидуальность, становясь одной из многих облачных политик безопасности, применяемых к пользователю и устройству независимо от их местоположения.
Тренд очевиден: безопасность окончательно отвязывается от физического периметра и становится атрибутом самой идентичности пользователя, устройства и данных. В этом контексте принципы, заложенные в CASB — централизованное управление политиками для распределённых ресурсов, контекстный контроль доступа и защита данных везде, где они находятся, — становятся базовыми для любой современной security-архитектуры.