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

Проектирование политик доступа ZTNA для Cloudflare Access

Сегодня все больше организаций внедряют безопасность Zero Trust ↗ защиту для сохранности активов и инфраструктуры компании в постоянно меняющемся ландшафте угроз. Традиционная безопасность, свойственная устаревшей архитектуре сети, предполагает доверие внутри периметра корпоративной сети. Zero Trust, напротив, строится на принципе «никогда не доверяй, всегда проверяй» и реализует постоянную аутентификация и строгий контроль доступа ↗ для всех пользователей, устройств и приложений независимо от их местоположения или сети.

Как правило, в архитектуре Zero Trust задействованы две технологии. Во-первых, Secure Web Gateway (SWG) ↗ фильтрует исходящий трафик в интернет и блокирует доступ пользователей к сайтам повышенного риска, например используемым в фишинговых кампаниях. Затем, чтобы обеспечить пользователям удалённый доступ к SaaS-приложениям, внутренним приложениям и сетям, применяется Zero Trust Network Access (ZTNA ↗) сервисы используются для создания защищенных туннелей и предоставления удаленным пользователям доступа к частным приложениям.

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

Этот документ предназначен для администраторов, которые рассматривают или уже внедрили Cloudflare для замены существующих служб VPN или организации нового удаленного доступа к внутренним ресурсам. Он служит отправной точкой при проектировании первых политик ZTNA и постоянным справочным материалом. Это руководство состоит из трех основных разделов:

• Технические предварительные требования: Что должно быть готово, прежде чем вы сможете защитить доступ к первому приложению и определить политики доступа.
• Создание политик: Основные компоненты политики доступа и способы их объединения.
• Сценарии использования: Типичные сценарии использования и политики, которые можно взять за основу при разработке собственных политик.

Это руководство по проектированию предполагает базовое понимание решения ZTNA от Cloudflare, Cloudflare Access. Поэтому в этом руководстве мы сосредоточимся на разработке эффективных политик доступа, предполагая, что вы уже настроили DNS, идентичность и поставщики контроля состояния устройств а также созданная связность к самостоятельно размещаемым приложениям и связанным с ними сетям.

К концу этого руководства вы будете готовы внедрять детализированные политики доступа, реализующие принципы Zero Trust в различных типичных корпоративных сценариях.

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

Cloudflare позволяет организациям упрощать доступ к приложениям с помощью нашего connectivity cloud ↗, которая безопасно связывает пользователей, приложения и данные независимо от их местоположения. В основе платформы лежит обширная глобальная сеть ↗ который обеспечивает подключение с низкой задержкой для пользователей по всему миру. Запуская каждый сервис в каждом дата-центре, Cloudflare применяет функции сети, производительности и безопасности за один проход, что устраняет необходимость направлять трафик через несколько специализированных серверов безопасности, снижая тем самым задержку и избегая узких мест в производительности.

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

Чтобы использовать публичные имена хостов, у вас должен быть активный домен в Cloudflare. Большинство клиентов используют Cloudflare как основной DNS-сервис, однако можно настроить домены для использования с Access и сохранить при этом Записи DNS в другом месте.

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

Cloudflare поддерживает доступ к следующим типам приложений:

• SaaS-приложения в интернете
• Приложения, размещённые самостоятельно, доступ к которым осуществляется по публичному имени хоста
• Приложения, размещённые самостоятельно, доступ к которым осуществляется по частному IP-адресу

Для SaaS и других приложений, доступных из интернета, доступ через Cloudflare прост, ведь они уже находятся в интернете. А для самостоятельно размещённых приложений вы создаёте туннель от Cloudflare к приватной сети, в которой работает приложение. Есть два способа это сделать:

• Мы рекомендуем использовать программные агенты например, cloudflared или Cloudflare Mesh. (Обратите внимание: в настоящее время проксирование публичных hostname к приватным приложениям поддерживает только cloudflared.)
• Для подключения на сетевом уровне Cloudflare WAN (ранее Magic WAN) использует туннели IPsec или GRE, соединяющие Cloudflare с существующими сетевыми устройствами, подключёнными к частным сетям, и Network Interconnect обеспечивает прямое подключение, если ваши приложения работают на серверах в дата-центре, которым управляет Cloudflare. (При переходе с существующих устаревших VPN-решений на туннели на основе сети вам может пригодиться это руководство полезным.)

После того как соединение с вашими приложениями установлено, настало время обеспечить пользователям доступ. В зависимости от требований политики (подробнее об этом далее) пользователи могут обращаться к приложению напрямую через интернет по публичному имени хоста, но для более высокой безопасности мы рекомендуем использовать наш агент устройства, Cloudflare One Client, который создает туннель напрямую к Cloudflare, а также предоставляет сведения об устройстве для использования в политиках доступа.

Важной частью доступа к приложению является аутентификация пользователя. У Cloudflare есть встроенная аутентификация метод на основе электронной почты. Однако мы настоятельно рекомендуем настроить стороннего провайдера идентификации. Мы поддерживаем как потребительские, так и корпоративные поставщики идентификации, при этом можно использовать любую службу, совместимую с SAML или OpenID. Членство в группе - один из самых распространенных атрибутов для определения доступа к приложению, и его можно задавать вручную или импортировать через систему System for Cross-Domain Identity Management (SCIM).

Последнее условие для создания действительно эффективных политик доступа: настроить состояние устройства. При использовании агент устройства, Cloudflare имеет доступ к различная информация об устройстве, которые затем можно использовать в политике доступа. При использовании безагентный метод для доступа к приложениям доступна только информация об идентификации пользователя. Мы также поддерживаем использование информации о состоянии устройства из другие поставщики, например Microsoft, Crowdstrike и Sentinel One.

Кратко резюмируя описанную архитектуру, Cloudflare выступает как:

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

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

Cloudflare Access поддерживает четыре основных типа приложений:

• Self-hosted относится к приложениям, которые ваша организация размещает и обслуживает, локально или в облаке. Cloudflare создаёт публичный хост, через который трафик проксируется в приложение по безопасному туннелю. Доступ через публичные хосты поддерживается и в случае, если ваш сервер просто напрямую доступен из интернета, однако мы рекомендуем использовать cloudflared для создания защищённого исходящего соединения между вашим приложением и edge-сетью Cloudflare. После этого Cloudflare выполняет обратное проксирование целевого приложения или содержимого вашим пользователям.
• Частный IP-адрес приложения также размещаются в частной сети, но не имеют полных публичных доменных имён. Организовать доступ к ним можно через cloudflared, Cloudflare Mesh, Cloudflare WAN или Cloudflare Network Interconnect. Удаленным пользователям, не подключенным к сети, уже подключенной к Cloudflare, потребуется использовать клиент на устройстве, чтобы получить доступ к приложению по частному IP-адресу, а чтобы не привязывать IP-адреса к пользователям, используйте внутренние DNS-сервисы для преобразования частных имен хостов в частные IP-адреса. Однако можно предоставить доступ без установки какого-либо ПО на стороне клиента, используя наш безагентный служба изоляции браузера.
• SaaS приложения доступны через публичный интернет и поэтому не требуют туннельного подключения к Cloudflare. Вместо этого Access выступает в роли прокси идентификации между пользователями и SaaS-приложением. Когда пользователь пытается получить доступ к SaaS-приложению, он сначала проходит аутентификацию через Cloudflare, которая перенаправляет его к вашему основному сервису идентификации. Затем SaaS-приложения настраиваются через SAML или OAuth так, чтобы доверять Cloudflare. Это позволяет организациям внедрять дополнительные уровни защиты (например, проверку состояния устройства) и централизовать управление доступом к своим SaaS-приложениям, даже если сам SaaS-сервис или провайдер идентификации не поддерживает эти функции изначально.
• Infrastructure приложения позволяют пользователям управлять доступом к отдельным серверам, кластерам и базам данных в частной сети. Принцип работы инфраструктурных приложений основан на определении 'target', который проксируется через cloudflared, но позволяет пользователям объединять несколько машин под одной и той же целью: по сути, это дает возможность определять единые политики доступа для потенциально разнородных инфраструктурных ресурсов. Встроенные возможности логирования доступа и команд позволяют организациям вести подробные журналы аудита для целей соответствия требованиям и расследования инцидентов безопасности.

Как правило, приложение Access соответствует одному конкретному приложению. Однако возможен вариант, когда приложение Access и связанные с ним политики применяются сразу к нескольким конечным точкам приложений. Это может быть диапазон IP-адресов нескольких серверов Windows RDP, для которых вы хотите использовать единую политику доступа. Тот же подход применим и к публичным именам хостов: у вас может быть несколько имён хостов, ссылающихся на разные приложения, к которым нужно применить одинаковые политики. Например, у вас могут быть wiki.domain.com и wiki.domain.co.uk: это разные экземпляры приложений, но с общими требованиями к политике доступа.

Далее мы разберём основные элементы приложения, защищённого ZTNA, которые нужно понимать для создания эффективных политик доступа, а затем рассмотрим сценарии использования, где эти элементы применяются на практике.

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

Как уже говорилось, Cloudflare можно интегрировать со всеми вашими поставщиками идентификации (IdP), как корпоративными, так и потребительскими. Затем на уровне приложения и политики вы выбираете, каким IdP разрешить аутентификацию. Например, если доступ к приложению должен быть только у ограниченного круга сотрудников, вы включаете только свой корпоративный IdP. Для другого приложения может понадобиться открыть доступ более широкому кругу пользователей, не являющихся сотрудниками, например подрядчикам или сторонним партнёрам. Часть таких пользователей можно аутентифицировать через учётные данные GitHub или LinkedIn.

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

После аутентификации IdP отправляет информацию об идентификации обратно в Cloudflare. В зависимости от IdP эта информация может включать Authentication Method Reference ↗ (amr) значений, групп IdP, атрибутов SAML или claims OIDC, которые затем можно использовать в политиках.

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

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

Каждое приложение может содержать несколько политик, которые оцениваются по порядку. Поскольку несколько политик, каждая со своим набором правил, могут образовать довольно сложную структуру, для проверки есть специальный инструмент policy tester: в нём можно указать имя пользователя и посмотреть, как он будет оценён по всем политикам и правилам. Политика состоит из следующих элементов:

Хотя назначение этого может казаться очевидным, мы настоятельно рекомендуем продумать стратегию именования политик. Дело в том, что вы, вероятно, будете создавать похожие политики для разных приложений, например «Разрешить всем штатным сотрудникам» или «Блокировать пользователей с высоким риском». Использование единой схемы именования во всех приложениях значительно упростит проверку доступа к приложениям и понимание полного списка политик в будущем.

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

• Allow предоставляет доступ к приложению. При первом запросе доступа пользователю будет показана страница входа.
• Block запрещает доступ к приложению. Обычно в этом нет необходимости, поскольку по умолчанию доступ через Access запрещён. Единственная причина, по которой пользователю стоит применять политику block, это тестирование конкретного условия политики или прерывание дальнейшей проверки политик. Если политика block имеет более высокий приоритет, чем Allow, и пользователь подпадает под условия block, вся дальнейшая проверка политик прекращается.
• Bypass позволяет пользователям или сервисам отключать применение политик для трафика перед обращением к приложению. Например, конкретной конечной точке приложения может потребоваться широкий доступ из интернета.
• Service Auth позволяет аутентифицировать запросы от других сервисов или приложений с помощью mTLS или токены службы. Если пользователь или сервис соответствует критериям этой политики, страница входа не показывается. Это сделано для того, чтобы запросы не от пользователей, например от других приложений, могли получать доступ к защищенным ресурсам.

Длительность сессии определяет, сколько времени аутентификация пользователя остаётся действительной после успешного входа в приложение. Обычно длительность сессии составляет 24 часа, но для критически важных приложений можно настроить немедленное истечение срока действия. Такой подход соответствует ключевому принципу Zero Trust: «никогда не доверяй, всегда проверяй». Даже если пользователь изначально предоставил корректные данные о состоянии устройства и контекст идентификации, непрерывная проверка гарантирует, что права доступа переоцениваются при каждом новом запросе. Этот метод значительно сокращает окно риска, поскольку устраняет предположение о том, что первоначальное состояние аутентификации и авторизации остаётся действительным в течение длительного периода.

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

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

• Включить правила определяют, кто или что имеет право на доступ. Когда пользователь соответствует правилу "Include", он становится кандидатом на доступ при условии соблюдения других правил политики. Эти правила используют логику ИЛИ: достаточно выполнения любого одного условия. Например, вы можете сделать приложение доступным для определённой группы, но при этом добавить подрядчиков по списку адресов электронной почты, и пока пользователь соответствует хотя бы одному из условий (членство в группе или действительный адрес электронной почты), он включается в правило. В каждой политике должно быть как минимум одно правило Include.

• Require правила задают обязательные условия, которые должны быть выполнены для предоставления доступа. В отличие от правил Include правила "Require" используют логику И: должно выполняться каждое правило. Обычно это применяется для усиления безопасности поверх базовых критериев доступа, заданных правилами Include. Например, администраторы могут потребовать, чтобы любой пользователь, пытающийся получить доступ к приложению, использовал определённые методы MFA.

• Exclude правила определяют исключения из доступа, отменяя действие правил других типов. Если пользователь соответствует правилу "Exclude", ему будет отказано в доступе независимо от других условий политики. Например, пользователь может выполнять требование об использовании метода MFA при входе в систему, но если его конкретный метод многофакторной аутентификации (MFA) указан в правиле Exclude, политика заблокирует его. Также, если пользователь связан с группой IdP с высоким риском, его можно исключить на этом основании, даже если он соответствует всем остальным требованиям posture.

Применение этих разных типов правил удобно представить в виде воронки. Селекторы Include определяют, какие атрибуты пользователя, трафика или устройства учитываются в политике, результатом которой будет Allow, Block и так далее. Require затем дополнительно фильтрует этот список, задавая, какие атрибуты обязательно должны быть связаны с пользователем, а тип Exclude отсеивает пользователей, совпавших одновременно с условиями Include и Require.

На диаграмме выше показан пример для политики «All employees and contractors on secure devices using strong MFA». Ей соответствует любой пользователь из группы «All Employees», а также подрядчики, прошедшие аутентификацию с именем пользователя в домене компании. От них требуется использовать устройство с последней версией ОС и включённым шифрованием хранилища. Они должны пройти аутентификацию с помощью MFA-фактора, но не по SMS. Кроме того, доступ к приложению должен осуществляться через защищённый веб-шлюз Cloudflare.

Существует множество различных типы селекторов. Здесь не перечислены все возможные селекторы, но ниже приведены конкретные результаты, которых обычно хотят достичь организации, использующие Cloudflare Access, при построении политик. Это поможет разобраться, как достичь конкретного результата.

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

  Настроить эту проверку можно, включив device posture check «gateway» и затем указав требование «gateway» в политиках приложений. Требование «gateway» гибче, чем опора исключительно на device agent, поскольку пользователи также могут подключаться через Browser Isolation или сайт, подключенный к Cloudflare WAN, и оба варианта обеспечивают журналирование и фильтрацию трафика. Кроме того, использование device agent позволяет гарантировать, что пользователь заходит с соответствующего требованиям устройства, прошедшего набор device posture check.

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

• Принадлежит ли пользователь к существующей группе или обладает определёнными атрибутами идентификации? Если ваш IdP поддерживает SCIM, информацию о членстве в группах можно импортировать в Cloudflare и использовать в политиках. Данные о группах могут также поступать из данных SAML или OAuth, передаваемых при аутентификации. Более того, если используется OIDC или SAML и передаются claims, их тоже можно применять в политике. Так, если пользователи проходят аутентификацию в вашем IDP через SAML и итоговый токен содержит их «role», это значение можно запросить в правиле.

• Какая служба идентификации использовалась для аутентификации? Как и в случае с группами и атрибутами IdP, селектор «Login methods» определяет, какой сервис идентификации был использован, и, подобно группам IdP, его лучше применять на уровне access group, а не в отдельной строке access policy. Login methods позволяют применять разные политики к пользователям в зависимости от того, через какого провайдера идентификации они прошли аутентификацию. Например, можно разрешить доступ только тем пользователям, которые аутентифицировались через потребительскую личность, например GitHub или LinkedIn, если их метод аутентификации включал MFA на основе аппаратного токена.

  Это нетипичный сценарий, но если вам всё же требуется включить несколько IdP для аутентификации, этот селектор поможет убедиться, что пользователи аутентифицируются именно через нужную службу. Ценность этого требования становится очевиднее при работе с несколькими слоями политик безопасности, когда нужно задавать разный уровень доступа в зависимости от способа входа.

• Личные или корпоративные адреса электронной почты Все сервисы идентификации предоставляют адрес электронной почты, который часто совпадает с именем пользователя. Указание почты в политике полезно, когда нужно разрешить доступ всем пользователям целого домена, но они могут проходить аутентификацию через потребительский IdP, допускающий любой адрес электронной почты. Например, можно разрешить доступ только тем, кто прошёл аутентификацию через GitHub с адресом вида @company.com.

  Этот селектор также удобно использовать, если вы управляете список электронных писем пользователей, которые могут представлять высокий риск или были заблокированы для доступа к конкретному приложению. Вы можете использовать правило Exclude с вашим списком, чтобы гарантировать, что часть пользователей не сможет получить доступ к приложению.

• Как пользователь прошел аутентификацию? Когда провайдер идентификации аутентифицирует пользователя и затем перенаправляет его обратно в Cloudflare, он передаёт информацию о том, какой метод аутентификации был использован. Обычно она передаётся как Authentication Method Reference ↗ данные. С их помощью можно проверить, использовалась ли MFA и какого типа.

  Это может быть полезно для задания разных уровней требований к учетным данным для разных приложений. Например, обычному корпоративному приложению может требоваться просто использование MFA без уточнения способа. А для по-настоящему чувствительного административного инструмента может потребоваться аппаратный ключ безопасности FIDO2,и поэтому в доступе будет явно отказано, если в процессе аутентификации использовался только одноразовый код через SMS.

• Из какой страны поступает запрос? Можно задавать правила на основе географического определения местоположения входящего запроса. Это может быть полезно для ограничения доступа из определённых стран, где вы ведёте бизнес.

• Из какого диапазона IP-адресов поступает запрос? Можно задавать правила на основе диапазона IP-адресов входящего запроса. Например, разрешать доступ только из диапазонов IP-адресов вашей корпоративной сети.

• Можно ли проверить информацию об устройстве или пользователе по списку? Иногда требуется предоставить или ограничить доступ на основании конкретных характеристик устройства или пользователя, которые не вписываются в другие категории. Именно для этого предназначен lists пригодятся: вы можете задать или импортировать список адресов электронной почты подрядчиков либо список одобренных серийных номеров устройств и использовать их как критерии в политике Access. Эти списки можно обновлять вручную или через наш API, что позволяет интегрировать ее с другими системами управления устройствами или пользователями.

• Достаточен ли уровень защищённости устройства? Здесь клиент устройства передаёт телеметрию о самом устройстве, с которого выполняется запрос доступа. Для этого он выполняет сканирование на уровне устройства. Зашифрован ли жёсткий диск устройства? Агент может проверить, активны ли такие технологии, как BitLocker или FileVault, а также проверить наличие определённых имён томов. Если вы защищаете важное приложение или ресурс с критически значимой информацией, это эффективное требование для применения.

• Выполняется ли запрос другим процессом или приложением? К приложению не всегда пытается получить доступ живой человек с устройства. Поэтому Cloudflare Access удобно использовать для управления обращениями к API со стороны другого программного обеспечения. Такой запрос может включать сервисные токены, сертификаты для взаимной TLS аутентификации и сертификаты SSH, что позволяет выполнять вход для автоматизированных процессов и обеспечивать взаимодействие между устройствами. Использование средств сервисной аутентификации в Cloudflare также централизует хранение этих токенов и сертификатов и управление их жизненным циклом.

• Что стороннее средство сообщает о вашем устройстве? Многие организации используют другие специализированные инструменты для защиты конечных точек, такие как Crowdstrike, SentinelOne или Microsoft Intune, чтобы получать телеметрию о состоянии безопасности устройства, с которого поступает запрос к приложению. Вместо того чтобы заставлять пользователя переключаться между несколькими интерфейсами, эти инструменты можно интегрировать в Cloudflare One через их API и применять полученные данные о состоянии устройства при входе в приложение.

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

Иногда требуется управлять доступом к self-hosted приложению для менее доверенных сторонних пользователей, например подрядчиков или партнёров. Может понадобиться разрешить им просматривать содержимое приложения, но ограничить возможность скачивать файлы, копировать и вставлять данные, а также печатать страницу. Cloudflare Access позволяет отображать приложение в удалённом браузер (используя удалённая изоляция браузера, или RBI) чтобы приложение отображалось с помощью headless-браузера в нашей сети, а не передавало все содержимое в браузер пользователя. Это позволяет Cloudflare применять ряд элементов управления тем, как пользователь может взаимодействовать с содержимым.

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

Этот параметр направляет трафик в изолированный браузер перед доставкой конечному пользователю, поэтому весь трафик затем проверяется и обрабатывается Cloudflare Gateway. Чтобы ограничить действия пользователя, нужно создать соответствующую политику в Gateway, которая определяет тех же пользователей и применяет меры контроля для которых вы хотите ограничить доступ. Обратите внимание, что важно составить политику Gateway так, чтобы она применяла RBI только к той же группе пользователей, для которой действует политика Cloudflare Access при доступе к приложению. В противном случае по умолчанию политика будет применять изоляцию браузера ко всем пользователям.

Для тех же пользователей можно принудительно применять RBI, если они пытаются получить доступ к приложению с незащищённого устройства. В этом случае вы по-прежнему определяете политику для сотрудников в Cloudflare Access, но дополнительно создаёте политику в Cloudflare Gateway, которая изолирует приложение, если пользователи, обращающиеся к тому же URL приложения, не прошли проверку состояния устройства, показавшую, что устройство не управляется или не защищено. Это может произойти, если на устройстве не установлен корпоративный клиент защиты конечных точек, например Crowdstrike или SentinelOne, или если устройство не прошло проверку безопасности. Мы продемонстрируем это на примерах использования ниже.

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

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

Добавьте дополнительный уровень контроля доступа, требуя от пользователей получения одобрения «temporary authentication» от назначенных утверждающих лиц перед доступом к приложению. При включении этой функции запрос пользователя на доступ отправляет уведомление уполномоченным утверждающим лицам.

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

Например, можно один раз определить группу Access «Employees», а затем использовать её в любой политике приложения, где нужно ссылаться на сотрудников. Обновления этой группы Access будут автоматически отражаться во всех политиках. Это также удобный способ добавить вложенную логику (например, для пользователей с устройством на Linux и включённым антивирусом)

Ниже приведена диаграмма с Access Group под названием «Secure Administrators», который использует ряд атрибутов для описания характеристик привилегированных администраторов. На диаграмме показано добавление ещё двух Access Group внутри «Secure Administrators». В эти группы входят устройства под управлением последней версии Windows или macOS, а также требование, чтобы на устройстве был включён File

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

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

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

Сначала создайте приложение Access со следующими параметрами:

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

Эта группа доступа будет использоваться в обеих политиках, и ее единственная задача состоит в том, чтобы определить, что такое «защищенный сотрудник».

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

Как видно, здесь определено, что к «всем сотрудникам» относятся участники группы Azure AD «Full Time Employees», которые также входят в группу «Completed security training». Первый селектор задаёт исходную область действия Access Group, а второй требует дополнительного вхождения в указанную группу.

Эта группа доступа требует, чтобы три проверки состояния устройства были созданы для Версия ОС. Например, posture check "Latest version of macOS" определяется условием "macOS version is greater than or equal to 15.1" и отражает последнюю версию, которую компания считает стабильной и безопасной (в отличие от самой новой версии ОС). После включения в политику Access это условие обеспечивает описанную здесь логику: чтобы войти в роли «Secure Employee», пользователю нужно соответствовать этим требованиям.

Теперь определим первую политику в приложении. Сначала выберите уже созданную Access Group. Затем задайте следующие правила, определяющие, как пользователи проходят аутентификацию и подключаются к приложению.

Эта политика гарантирует, что пользователи получают полный доступ к вики компании только при выполнении следующих требований:

• Это штатные сотрудники, использующие устройства с последней версией операционной системы.
• Пользователи прошли аутентификацию с использованием MFA.
• Пользователи обращаются к приложению с устройства, на котором работает агент Cloudflare.

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

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

Обратите внимание, что теперь мы включаем "Isolate Application". Что это значит? Это заставляет все запросы к приложению рендериться с помощью нашей технологии RBI. RBI не позволяет интерфейсу wiki загружаться напрямую в браузере конечного пользователя, а вместо этого рендерит содержимое в headless-браузере, запущенном на сервере в глобальной облачной сети Cloudflare. Затем результат этого рендеринга безопасно и эффективно передаётся в браузер конечного пользователя. Из-за этого запрос также проходит через наш сервис SWG, что позволяет вам написать политику, контролирующую взаимодействие пользователей с wiki.

HTTP-политика Gateway

В примере выше политика SWG отбирает весь трафик, направленный на корпоративную вики, применяет к нему RBI (в соответствии с политикой приложения ZTNA), а затем блокирует любое взаимодействие с вики.

Кроме того, добавляется проверка состояния устройства "WARP Check (Mac OS)", которая проверяет, установлен ли на устройстве пользователя наш агент устройства. Если агент не установлен или не включён, проверка состояния устройства выполниться не может, и пользователь автоматически не будет соответствовать требованиям политики. Если у пользователя агент устройства включён, он пройдёт проверку состояния и получит полный доступ к wiki. Обратите внимание, что "WARP" ранее было названием Cloudflare One Client, агента устройства Cloudflare.

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

Такой подход к политикам решает сразу несколько задач:

1. Это обеспечивает использование доверенных устройств для полного доступа к wiki, что соответствует целям безопасности Zero Trust.
2. Это предоставляет запасной вариант для сотрудников, использующих личные устройства, позволяя им получать ограниченный, но безопасный доступ к wiki через изоляцию браузера.
3. Это стимулирует сотрудников использовать корпоративные устройства и (или) держать Cloudflare One Client включённым, что в целом положительно влияет на уровень защищённости организации.
4. Это демонстрирует мощь и гибкость более детального управления безопасностью, которые достигаются за счёт сочетания политик Cloudflare Access с HTTP-политиками Cloudflare Gateway.

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

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

Прежде чем перейти к деталям, вы узнаете о преимуществах защищённого доступа к SaaS приложениям через Cloudflare. Ведь Salesforce и другие крупные поставщики SaaS уже предлагают надёжные средства защиты, включая собственные средства управления доступом, MFA и журналы аудита. Так почему же некоторые организации всё равно предпочитают направлять свой SaaS трафик через Cloudflare?

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

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

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

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

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

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

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

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

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

Здесь мы вводим большое количество проверок security posture, начиная с MFA. У нас есть два выражения для MFA: первое требует, чтобы пользователи проходили аутентификацию с помощью метода MFA. Второе, выражение 'excludes', указывает, что SMS не считается допустимым методом аутентификации. Мы делаем так, потому что SMS один из самых простых способов, которые злоумышленники используют для эксплуатации и обхода защиты, и поэтому считается менее безопасным ↗ чем другие методы MFA. Поэтому мы разрешаем доступ только при использовании более надёжных учётных данных, например аппаратного ключа или одноразового пароля (OTP) из приложения-аутентификатора. Применение этих более строгих требований MFA снижает риск атак на основе учётных данных и значительно затрудняет злоумышленникам получение несанкционированного доступа к этой критически важной базе данных, даже если им удалось узнать пароль пользователя.

К другим элементам оценки состояния относятся:

• Требование использовать последнюю версию ОС.
• Устройство пользователя подключено к домену Microsoft Active Directory.
• Устройство пользователя явно является управляемым компанией устройством (что подтверждается ссылкой на список серийных номеров управляемых устройств).

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

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

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

Последний сценарий посвящён защите удалённого доступа к устройствам по RDP: локально размещённым решением или через приватный IP. У каждого варианта свои преимущества, и выбор в конечном счёте зависит от приоритетов: что важнее, упростить доступ или обеспечить строгий контроль активности?

Начнем с варианта самостоятельного развертывания: проксирования порта 3389 через туннель с привязкой к имени хоста.

Определите политику:

В этой политике мы сделали приложение доступным для новой группы доступа IT Admins. В блоке "Require" мы требуем использование именно Cloudflare One Client (а не только Cloudflare Gateway). Пользователь должен находиться на устройстве, управляемом компанией, с активным клиентом устройства, аутентифицированным в экземпляре Cloudflare компании, при входе должна использоваться MFA, а ниже есть дополнительный параметр для внешней проверки.

Внешняя оценка означает, что у нас есть конечная точка API, содержащая тот или иной логика доступа ↗: в данном случае доступ по времени суток. Мы выполняем вызов API к этой конечной точке и задаем ключ, с помощью которого Cloudflare проверяет, что ответ действительно пришел от API. Это полезно по нескольким причинам:

Внешняя оценка позволяет создавать собственные проверки состояния безопасности по критериям, которые не входят в стандартный набор проверок. В этом примере мы используем сервис, созданный на Cloudflare Workers ↗.

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

Теперь вы узнаете, как защитить доступ по RDP как приложение с частным IP-адресом:

Как уже говорилось, приложения с приватными IP-адресами работают благодаря тому, что Cloudflare проксирует диапазон IP-адресов через свою сеть. Такой характер работы требует использования клиента на устройстве: пока пользователь не подключён к Cloudflare (а точнее, пока он не может воспользоваться соединением Client-to-Tunnel), он не сможет обратиться к нелокальным адресам RFC 1918.

Здесь определить приложение просто: Cloudflare автоматически заполняет диапазон IP-адресов, а вам нужно только ограничить обнаруженный протокол значением RDP. Однако для приложений с приватными IP-адресами правила немного отличаются. Обратите внимание, что они отображаются как сетевые политики в меню Cloudflare Gateway, хотя управляются в разделе Access. Некоторые параметры, например проверка MFA и внешняя оценка, здесь не отображаются. Тем не менее эти атрибуты можно проверить, когда пользователь активирует клиент устройства и проходит аутентификацию в своей организации.

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

Сочетая детализированный контроль доступа с подробным журналированием активности, Cloudflare предлагает комплексное решение для защиты критически важных ресурсов и мониторинга доступа к ним в рамках методологии Zero Trust.

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

Если вы хотите узнать больше о ZTNA, SASE или других аспектах платформы Cloudflare One, посетите наш библиотека эталонных архитектур или наш документация для разработчиков чтобы начать работу.

Дополнительные материалы

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