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

Использование модели нулевого доверия для защиты SaaS-приложений

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

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

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

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

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

• Одна из стратегий, которые организации применяют для повышения безопасности, заключается в том, чтобы защитить SaaS-приложения от открытого интернета с помощью белых списков IP-адресов и направлять трафик через дата-центр организации, где его можно проверять и фильтровать согласно политике безопасности. Однако такой подход ухудшает пользовательский опыт: при маршрутизации всего трафика через один дата-центр возрастает задержка и снижается пропускная способность.
• И наоборот, если пользовательский трафик направляется напрямую в интернет, минуя локальный VPN-клиент за счёт split tunneling, это снижает уровень безопасности и видимости, поскольку корпоративные средства контроля сети остаются в стороне (а использование списков разрешённых IP-адресов становится невозможным).

Именно здесь Архитектура SASE (Secure Access Service Edge), реализующая модель Zero Trust становится необходимым. Благодаря централизации безопасности в глобальной облачной сети компромисс между безопасностью и производительностью исчезает. Трафику пользователей больше не требуется проходить через единственный удалённый дата-центр ради безопасности. При использовании Cloudflare трафик пользователей направляется в наши сервисы через ближайший из сотен дата-центров, где он проходит необходимые проверки безопасности. Эти проверки реализованы в архитектуре единого прохода (single-pass), что позволяет избежать лишней задержки, и применяются одинаково во всей сети Cloudflare.

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

Это руководство предназначено для ИТ-специалистов и специалистов по безопасности, которые хотят безопасно внедрять и использовать SaaS-приложения в организации, сохраняя при этом удобство работы пользователей. Предполагается знакомство с такими понятиями, как поставщики удостоверений (IdP), каталоги пользователей, единый вход (SSO) и технологии предотвращения утечки данных (DLP).

Чему вы научитесь:

• Как защитить доступ к управляемым SaaS приложениям и обезопасить их данные
• Ключевые аспекты использования облачных решений для электронной почты
• Как получить видимость неуправляемых SaaS приложений и вернуть контроль над ними

Это руководство предполагает наличие у вас контракта Enterprise с Cloudflare, включающего:

• Лицензии Cloudflare Zero Trust на количество пользователей, которых вы планируете подключить
• Cloudflare Cloud Email security лицензируется по числу пользователей, чьи облачные почтовые ящики будут проверяться

Рекомендуемые материалы для более глубокого понимания Cloudflare:

• Что такое Cloudflare? | Сайт ↗ (пять минут на чтение) или видео ↗ (две минуты)
• Блог: Zero Trust, SASE и SSE: базовые концепции для сети нового поколения ↗ (14 минут на чтение)
• Эталонная архитектура: Переход к архитектуре SASE с Cloudflare (три часа на чтение)

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

1. Защита доступа: Обеспечение доступа к SaaS-приложениям только для авторизованных пользователей и устройств. Сюда входит управление подключением и отключением пользователей. Например, если сотрудник покидает организацию, его доступ автоматически отзывается. Как правило, это подразумевает интеграцию SaaS-приложения с корпоративным решением для управления идентификацией.
2. Защита данных: Предотвращение утечек данных изнутри SaaS-приложения и упреждающее устранение рискованного поведения пользователей, которое может привести к утечкам данных.
3. Конфигурация монитора: Выявление и оперативное исправление неверных конфигураций в SaaS-приложении для обеспечения их безопасной и эффективной работы.
4. Cloud email security: ИТ-командам следует уделять особое внимание облачным SaaS-решениям для электронной почты. Поскольку почта является одним из главных векторов атак, для защиты пользователей от фишинга и других угроз, связанных с почтой, требуется специализированный подход.

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

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

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

• Гибридные сотрудники: Подключение к Cloudflare с помощью нашего клиента Zero Trust, WARP.
• Офисные пользователи: Подключение к локальной сети, которая направляет исходящий интернет-трафик в Cloudflare через GRE или IPsec Cloudflare WAN (ранее Magic WAN) туннели.
• Подрядчики и внешние пользователи: Доступ к SaaS-приложениям через удалённый браузер размещенном в дата-центре Cloudflare.

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

Использование выделенных исходящих IP-адресов Cloudflare имеет ряд преимуществ по сравнению с IP-адресами локальной инфраструктуры:

• Местоположение выделенных исходящих IP-адресов можно определить по геолокации к одному или нескольким дата-центрам Cloudflare в выбранном вами географическом регионе, вместо того чтобы ограничиваться географическим расположением существующих у вас точек выхода в интернет.
• Пользователи всегда подключаются к Cloudflare через ближайший дата-центр Cloudflare, после чего Cloudflare оптимизирует путь к этому SaaS-приложению.
• Выделенные IP-адреса для исходящего трафика назначаются пользовательскому трафику по политикам, основанным на принципах Zero Trust. Политики Egress можно настроить так, чтобы выделенный исходящий IP-адрес назначался пользователю только в том случае, если он входит в нужную группу IdP и/или проходит состояние устройства проверок. В противном случае трафик будет исходить из публичного диапазона IP-адресов Cloudflare, который может не входить в разрешённый список IP-адресов SaaS, что заблокирует доступ к SaaS-приложению, но не помешает обычному использованию интернета.
• Выделенные исходящие IP-адреса подразумевают, что трафик должен проходить через Cloudflare, прежде чем достигнет SaaS-приложения. Благодаря этому легко добавить политики защищённого веб-шлюза для защиты данных в SaaS-приложениях после того, как пользователи прошли аутентификацию.

С Cloudflare, Zero Trust Network Access (ZTNA) ↗ можно применить к управляемым SaaS-приложениям. В этом сценарии Cloudflare выступает в роли Единый вход (SSO) ↗ сервиса для приложения, который проксирует запросы аутентификации пользователей к существующим поставщикам удостоверений (IdP) организации. Это позволяет добавить дополнительные ограничения перед предоставлением доступа, например потребовать многофакторная аутентификация ↗, внедряя проверки состояния устройства, или оценка страны отправлен запрос.

Большинство организаций сначала используют Сервис ZTNA для self-hosted приложений. Распространение этого подхода на SaaS-приложения упрощает ИТ-управление сразу в нескольких аспектах, поскольку и self-hosted, и SaaS-приложения будут:

• Используйте те же политики доступа
• Используйте те же интеграции IdP и оценки состояния устройств
• Последовательный аудит запросов на доступ

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

Рассмотрим ситуацию, когда пользователь переходит в другую группу или команду внутри организации. Как только сведения о группе пользователя обновляются в IdP, политики ZTNA Cloudflare динамически применяют эти изменения, и доступ пользователя к SaaS-приложениям сразу же приводится в соответствие с его новой ролью. Это также помогает оптимизировать лицензии на SaaS-приложения. Например, если сотрудника переводят из отдела продаж, который использует Salesforce, в команду, которой доступ к Salesforce не требуется, политики ZTNA отзывают этот доступ. Благодаря такой автоматизации освобождается лицензия, ранее закреплённая за пользователем, и приложением могут пользоваться только те, кому оно действительно нужно.

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

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

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

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

Хотя распространение принципов ZTNA на управляемые SaaS-приложения гарантирует, что доступ к ним получат только нужные пользователи и устройства, не менее важно устранить риск утечки данных со стороны авторизованных пользователей, уже получивших доступ.

Для снижения этих рисков нужно применять меры контроля как для данных при передаче, так и для данных при хранении.

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

• Ограничение возможности скачивать all или подмножество файлов из управляемых SaaS-приложений для конкретных групп пользователей внутри организации.
• Использование Data Loss Prevention (DLP) профили для ограничения скачивания данных, содержащих конфиденциальную информацию, из управляемых SaaS приложений.

Дополнительные сведения о защите передаваемых данных см. в нашей центр эталонных архитектур.

Cloudflare Cloud Access Security Broker (CASB) интегрируется с популярные SaaS-приложения через API. После интеграции Cloudflare непрерывно сканирует эти приложения на предмет угроз безопасности. Это позволяет ИТ-командам выявлять случаи, когда авторизованные пользователи чрезмерно открывают доступ к данным, например публикуют файл в открытом доступе в интернете. Для Google Workspace, Microsoft 365, Box и Dropbox API CASB также может использовать профили DLP для обнаружения передачи конфиденциальных данных. Подробнее о защите хранимых данных см. в нашем центр эталонных архитектур.

Помимо перечисленных выше мер, ИТ-командам стоит также рассмотреть внедрение Аналитика поведения пользователей и сущностей (UEBA) ↗ элементы управления. Cloudflare может назначить risk score пользователям при обнаружении действий и поведения, которые могут представлять риск для организации. К такому рискованному поведению относятся, например, случаи, когда пользователь вызывает необычно большое количество срабатываний политик DLP. Внедряя эти меры, организации могут значительно снизить риск утечки данных из управляемых SaaS-приложений, даже со стороны авторизованных пользователей.

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

Снизить эти риски можно с помощью CASB от Cloudflare. API CASB непрерывно сканирует конфигурацию и выявляет ошибки, что позволяет быстро их устранять. Он способен обнаружить, среди прочего, раскрытые учетные данные, ключи, которые пора обновить, пользователей с отключенной двухфакторной аутентификацией (2FA) и неавторизованные сторонние приложения с доступом к SaaS-приложению.

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

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

Организациям с жёсткими требованиями к переписке по электронной почте, будь то из соображений комплаенса и нормативного регулирования, операционного контроля и подотчётности, или для снижения риска утечек данных, может потребоваться заблокировать доступ к почтовым тенантам, отличным от собственного. Добиться этого можно с помощью Управление SaaS-арендаторами в Cloudflare Gateway. Cloudflare добавляет в поток трафика собственные HTTP-заголовки, сообщающие Microsoft 365 и Google Workspace, в какой именно tenant пользователям разрешено выполнять аутентификацию, и блокирует любые попытки доступа к другим tenant.

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

Email Security от Cloudflare ↗ сканирует электронные письма на предмет вредоносного содержимого или вложений и проактивно отслеживает в интернете инфраструктуру злоумышленников и механизмы доставки атак. Он выявляет автоматически созданные и имитирующие домены, используемые для размещения вредоносного содержимого в рамках спланированных атак. Эти данные также помогают защититься от компрометации деловой переписки и переписки с поставщиками (BEC ↗/VEC ↗), которые печально известны тем, что их трудно обнаружить из-за отсутствия вредоносной нагрузки и схожести с легитимной перепиской, а также из-за пробелов в устаревших платформах защиты почты.

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

При Inline-развёртывании защита почты Cloudflare проверяет письма до того, как они попадут во входящие пользователей (для этого MX-запись почтового домена указывается на Cloudflare). Это позволяет Cloudflare помещать сообщения в карантин чтобы они никогда не попадали во входящие пользователя или помечать сообщения с помощью заголовков электронной почты чтобы сообщить почтовому провайдеру, как следует обрабатывать письма (например, путём перенаправления массовых писем сразу в папку «Спам»). Cloudflare также может изменять тему и текст сообщений электронной почты чтобы предупредить пользователя о необходимости проявлять осторожность в отношении подозрительного письма и переписывать ссылки в письмах и даже изолировать эти ссылки за удалённым браузером.

При API-развёртывании защита почты Cloudflare видит письма только после того, как они уже попали во входящие пользователей, благодаря настройке правил Journaling/BCC у почтового провайдера или через сканирование по API. Затем, за счёт интеграции с почтовым провайдером, Cloudflare может отзывать фишинговые письма из почтовых ящиков пользователей. В отличие от инлайн-режима, этот способ развёртывания не поддерживает помещение писем в карантин или изменение содержимого сообщений. Однако это простой способ добавить защиту в сложную почтовую инфраструктуру без изменения существующего процесса обработки почты.

Эти режимы можно использовать одновременно для повышения безопасности электронной почты. Встроенный режим гарантирует, что Cloudflare Email Security сканирует и фильтрует письма до того, как они попадут во входящие пользователей. Для писем, которые изначально проходят проверку без пометки как угроза, Cloudflare периодически их переоценивает. Если впоследствии эти письма признаются частью фишинговой кампании, они автоматически отзываются через API. Такой проактивный подход защищает организации от отложенных фишинговых атак, при которых злоумышленники рассылают письма с виду безобидными ссылками, которые становятся вредоносными уже после доставки, чтобы обойти первоначальное обнаружение.

Cloudflare также помогает обеспечивать доступность облачных почтовых сервисов. Он автоматически масштабирует TCP-соединения и SMTP-трафик при всплесках сообщений, защищая организацию от DoS-атак по электронной почте. Сервис автоматически объединяет сообщения в пул и ставит их в очередь на длительные периоды, а после всплеска ограничивает скорость доставки в соответствии с пропускной способностью нижестоящего почтового сервиса. Эта возможность пулинга и постановки в очередь полезна во время сбоев облачных почтовых сервисов.

Организации, использующие Microsoft 365, могут усилить защиту от утечек конфиденциальной информации через электронную почту, встроив в свою среду надстройку Cloudflare. Эта интеграция позволяет ИТ-администраторам настроить исходящие политики Data Loss Prevention (DLP) которые используют те же профили DLP, что и Secure Web Gateway (SWG) и API Cloud Access Security Broker (CASB).

Кроме того, организации, которые используют Microsoft Purview Sensitivity Labels для классификации и защиты конфиденциальных документов может включать эти метки в профили DLP Cloudflare. Это позволяет создавать точечные политики, например блокировать отправку внешним получателям писем с документами Microsoft Office, помеченными в Microsoft Outlook как 'Highly Confidential'. Такие профили DLP также можно применять в SWG и API CASB.

Неуправляемыми SaaS-приложениями называют приложения, которые сотрудники используют без согласования или уведомления IT-отдела, часто их называют теневой ИТ ↗. Эта растущая проблема связана с распространением бесплатных и недорогих SaaS-приложений. Такие приложения могут повышать удовлетворенность и продуктивность сотрудников, но при этом несут значительные риски, например:

• Утечки данных: Сотрудники могут загружать конфиденциальные данные в эти приложения без каких-либо мер защиты. А без единого входа (SSO) или надежных парольных политик риск утечки или кражи данных значительно возрастает.
• Нарушения требований соответствия: В регулируемых отраслях использование несанкционированных SaaS-инструментов может привести к несоответствию правовым и отраслевым стандартам, что чревато штрафами, судебными разбирательствами и репутационным ущербом.
• Увеличение затрат: ИТ-отдел, как правило, может добиться выгодных цен, управляя подписками на SaaS в масштабах всей компании. Однако когда сотрудники самостоятельно оформляют подписки по личным банковским картам, это приводит к неконтролируемым расходам теневого ИТ и увеличивает общие затраты организации.

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

Располагая этой информацией, IT-команды могут проанализировать и решить, как поступить с каждым неуправляемым SaaS-приложением:

• Разрешить приложение: Если приложение не представляет риска для организации, оно считается допустимым для использования сотрудниками, и никаких дальнейших действий не требуется.
• Разрешить приложение с элементами управления защитой данных: Если приложение допустимо, но несет риск утечки данных, следует внедрить соответствующие меры защиты данных.
• Внедрите приложение как управляемое SaaS-приложение : Если приложение полезно для организации, его следует передать под управление ИТ.
• Заблокировать приложение: Если приложение признано недопустимым, его следует заблокировать с помощью политик Cloudflare Gateway DNS и (или) HTTP.

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

• Ограничение возможности загружать файлы определённых типов к SaaS-приложениям, ограничивая эту возможность определёнными группами пользователей внутри организации.
• Использование профилей Data Loss Prevention (DLP) для блокировки загрузки данных, содержащих конфиденциальную информацию.

Помимо этих мер, удалённая изоляция браузера можно рассмотреть для неуправляемых SaaS-приложений. Такой подход позволяет пользователям обращаться к отдельным неуправляемым SaaS-приложениям, при этом ограничение их действий в этих приложениях для предотвращения неправомерного использования.

Многие SaaS-приложения предлагают бесплатную версию как часть своей бизнес-модели, чтобы поощрить пользователей внедрять их в работу. Это помогает продемонстрировать полезность приложения и облегчает его внедрение на уровне компании (Cloudflare также следует этой модели ↗). Когда ранее неуправляемое SaaS-приложение официально принимается организацией на баланс, ИТ-команда берет на себя управление им для обеспечения надлежащей поддержки и соблюдения лучших практик. Это подразумевает приведение нового SaaS-приложения в соответствие со всеми аспектами, описанными в разделе Securing Managed SaaS Applications.

После полного перехода на новое SaaS-приложение доступ к потребительской версии можно ограничить. Если корпоративная версия SaaS использует уникальный домен, доступ к доменам других арендаторов или к потребительскому домену можно заблокировать с помощью политик Cloudflare DNS и (или) HTTP. Некоторые SaaS-решения предлагают встроенный контроль на уровне tenant через HTTP-заголовки, что можно обеспечить, добавляя эти заголовки для передаваемых данных с помощью HTTP-политик Cloudflare Gateway.

В этом руководстве по проектированию описано, как организации могут повысить безопасность своих SaaS-приложений, внедрив принципы Zero Trust в рамках архитектуры SASE. С Cloudflare организации получают комплексное решение, устраняющее проблемы, связанные как с управляемыми, так и с неуправляемыми SaaS-приложениями. Используя такие методы, как ZTNA, выделенные исходящие IP-адреса, CASB и надежные средства защиты электронной почты, организации могут обеспечить безопасный доступ, защитить конфиденциальные данные и взять под контроль теневые ИТ, сохранив при этом удобство работы пользователей. Эти методы и случаи их применения обобщены на диаграмме ниже:

• Эталонная архитектура SASE
• Использование Cloudflare SASE с Microsoft