← Справочные архитектуры / reference-architecture / diagrams / sase

Безопасный доступ к SaaS-приложениям с помощью SASE

SaaS-приложения стали незаменимым инструментом в повседневной работе бизнеса. Снижая нагрузку на ИТ и инфраструктуру, они одновременно создают новые проблемы безопасности, с которыми традиционные архитектуры справляются с трудом. Сегодня многие компании находятся на пути к внедрению Архитектура Zero Trust ↗, которая объединяет данные об идентификации, устройствах и сети для более надежной защиты приложений.

Однако SaaS приложения, как правило, сосредотачивают свою защиту на собственной платформе: они безопасно хранят данные в состоянии покоя и следят за тем, чтобы приложение не раскрывало данные клиентов из-за уязвимостей. В этом документе рассматривается, как устранить некоторые ограничения SaaS приложений с помощью платформы Cloudflare Secure Access Service Edge (SASE), а именно сервисов Zero Trust Network Access (ZTNA) и Secure Web Gateway (SWG) в сочетании с интеграциями с вашими существующими поставщиками решений для управления идентификацией и безопасностью устройств.

Прежде чем переходить к деталям реализации SASE для SaaS приложений, стоит задаться вопросом: разве SaaS ещё недостаточно защищён? Крупные поставщики, такие как Salesforce, ServiceNow, Microsoft и другие, уже внедрили надёжные средства защиты, включая интеграцию с провайдерами identity для единого входа (SSO), SSL/TLS для всех коммуникаций приложения, шифрование данных при хранении и полноценные журналы аудита. Однако поставщики SaaS не пытаются полностью воссоздать платформу безопасности внутри своих приложений, поэтому не могут предоставить многие возможности, необходимые для современной архитектуры Zero Trust.

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

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

Платформа SASE от Cloudflare позволяет использовать подход, в большей степени ориентированный на Zero Trust, для защиты SaaS-приложений. Централизованные политики, учитывающие состояние устройства, атрибуты идентификации и точное сетевое расположение, можно применять к одному или сразу нескольким SaaS-приложениям. Cloudflare становится новой корпоративной сетью и позволяет ограничивать доступ к SaaS-приложениям в интернете только теми пользователями и устройствами, которые подключены к Cloudflare. По сути это новая корпоративная сеть в облаке.

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

• Zero Trust Network Access. Позволяет Cloudflare выступать в роли identity proxy, благодаря чему можно легко подключить аутентификацию через самых разных провайдеров идентификации к одному SaaS-приложению. Этот сервис также позволяет оценивать доступ на основе состояния устройства и сетевого местоположения.
• Secure Web Gateway. Как только весь трафик к SaaS-приложению начинает проходить через наш gateway, HTTPS-соединения завершаются на стороне Cloudflare, и у вас появляется возможность проверять данные, поступающие в SaaS-приложение и исходящие из него. Это позволяет блокировать экспорт конфиденциальных данных в незащищенные места.

На приведённой выше диаграмме показаны различные способы направить трафик в Cloudflare: сервис ZNTA обеспечивает аутентификацию, а Secure Web Gateway фильтрует входящий и исходящий трафик SaaS-приложения.

1. Первоначальные запросы к SaaS приложению перенаправляются в Cloudflare в рамках процесса SSO. Сервис ZTNA аутентифицирует пользователей через существующих поставщиков идентификации.
2. Пользователю, независимо от того, прошёл ли он аутентификацию, будет отказано в доступе к SaaS-приложению, если его трафик поступает не из сети Cloudflare.
3. Пользователь на неуправляемом устройстве может использовать изоляцию браузера: браузер, обращающийся к SaaS-приложению, работает на сервере Cloudflare, а результат отрисовки страницы безопасно передаётся в локальный браузер пользователя.
4. Управляемое устройство подключается к Cloudflare через защищённый туннель, поэтому весь обмен данными между устройством и SaaS-приложением фильтруется и защищается.
   1. Данные о состоянии устройства (device posture), получаемые агентом Cloudflare, также можно учитывать при авторизации трафика от этих устройств.
5. Устройство, подключённое к локальной сети, где весь интернет-трафик направляется в Cloudflare через защищённый туннель IPsec к Cloudflare, также гарантирует, что весь трафик от сети к приложению SaaS фильтруется и защищается.
6. Затем трафик проходит через наш secure web gateway, где к нему можно применять DNS- и HTTP-политики.
   1. HTTP-политики позволяют проверять данные, загружаемые в SaaS-приложение и скачиваемые из него, с помощью профилей DLP.
7. Трафик выходит из Cloudflare с определённого IP-адреса. SaaS-приложение настроено так, чтобы разрешать весь трафик с этого адреса.

Далее приведен пример набора политик, демонстрирующих, как можно использовать Cloudflare для защиты доступа к Salesforce.

Первый шаг: использовать политика исходящего IP в Cloudflare Gateway. Это позволяет приобретать и назначать определенные IP-адреса пользователям, чей трафик фильтруется через Gateway. Затем в Salesforce вы разрешаете доступ только для трафика с исходным IP-адресом, соответствующим указанному в политике egress. Такое сочетание гарантирует, что доступ к Salesforce возможен только через Cloudflare.

Это важно не только для защиты доступа к Salesforce, но и для надлежащей защиты его содержимого во время использования. Теперь рассмотрим политику доступа, ограничивающую доступ участниками групп Sales или Executives. Также используется интеграция с Crowdstrike, гарантирующая, что пользователи работают с управляемых компанией устройств.

Вторая политика распространяется на всех сотрудников, но перед предоставлением доступа мы применим ещё несколько дополнительных шагов.

Добавим временную аутентификацию во вторую политику. Это означает, что если Cloudflare определит, что входящий запрос поступил от пользователя не из отдела продаж или руководства, администратору потребуется явно предоставить ему временный доступ. В данном контексте такую политику можно использовать для защиты доступа к Salesforce для сотрудников за пределами отдела продаж, поскольку информация о клиентах может быть конфиденциальной.

Такой подход важен по нескольким причинам:

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

Платформа SASE от Cloudflare позволяет организациям централизовать политики безопасности для доступа к SaaS-приложениям. Она также повышает уровень защиты, поскольку позволяет учитывать состояние устройств (device posture) и сетевые атрибуты. Вы можете настроить ее так, чтобы SaaS-приложение было доступно только через новую корпоративную сеть, построенную на Cloudflare.

• Переход к архитектуре SASE с Cloudflare
• Проектирование политик доступа ZTNA для Cloudflare Access
• Доступ к приватным приложениям без развёртывания клиентских агентов