← Cloudflare One / cloudflare-one / access-controls

Политики

Cloudflare Access определяет, кто может получить доступ к вашему приложению, применяя настроенные вами политики Access.

Каждая политика Access состоит из четырёх основных элементов:

• Действия: что происходит, когда пользователь соответствует политике (Allow, Block, Bypass или Service Auth)
• Типы правил: Как объединяются критерии (Include, Require или Exclude)
• Селекторы: Проверяемые атрибуты (например, домен электронной почты, страна или состояние устройства)
• Значения: Конкретные значения для сопоставления (например, @example.com)

Действия позволяют разрешать или запрещать доступ определенному пользователю или группе пользователей. Для каждой политики можно задать только одно действие.

Действие Allow в Cloudflare Access позволяет пользователям, соответствующим определённым критериям, получить доступ к приложению, защищённому Access.

В следующей таблице показан пример политики Cloudflare Access Allow, которая разрешает доступ любому пользователю с @example.com адрес электронной почты, подтверждённый через IdP, получат доступ к приложению:

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

Например, в следующей таблице показана политика Allow с правилами Require и Exclude. Эта конфигурация разрешает доступ любому пользователю из Португалии с @team.com адрес электронной почты, подтверждённый через IdP, получат доступ к приложению, кроме user-1 и user-2:

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

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

Действие Bypass в Cloudflare Access отключает применение Access для определённого трафика.

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

Например, у некоторых приложений есть конечная точка (endpoint) в разделе /admin маршрут, который должен быть доступен для маршрутизации из интернета. В этом случае вы можете создать приложение Access для домена test.example.com/admin/<your-url> и добавьте политику Bypass, показанную в следующей таблице:

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

Политики Bypass, содержащие проверка состояния устройства правила не будут работать, если:

• Zaraz включено для зоны, защищённой Access
• A Worker перехватывает запрос

Чтобы обойти эти ограничения и пропустить проверку Access, рекомендуем изменить действие политики на Service Auth.

Правила Service Auth в Cloudflare Access обеспечивают потоки аутентификации, которые не требуют входа через поставщика идентификации (IdP), например токены службы и взаимный TLS.

В следующей таблице показан пример настройки политики Cloudflare Access Service Auth:

Типы правил работают как логические операторы и определяют, как объединяются ваши критерии при оценке пользователя. Каждая политика Access должна содержать хотя бы одно правило Include. Это правило Include определяет исходный пул пользователей, которым разрешён доступ к приложению. Затем вы можете добавить правила Exclude и Require, чтобы сузить область действия.

Правило Include в Cloudflare Access похоже на логический оператор OR. Если указано несколько правил Include, пользователям достаточно соответствовать только одному из критериев.

Правило Exclude в Cloudflare Access работает как логический оператор NOT. Пользователь, соответствующий любому критерию исключения, не получит доступ к приложению.

Правило Require в Cloudflare Access работает как логический оператор AND. Чтобы получить доступ, пользователь должен выполнить все указанные правила Require.

По умолчанию значения, добавленные в правило Require, объединяются оператором AND. Например, предположим, что вы хотите предоставить доступ к приложению штатным сотрудникам и подрядчикам, но только тем из них, кто находится в определенных странах, скажем в Португалии и США. Если вы настроите правило со следующей конфигурацией:

Эта политика требует, чтобы пользователь одновременно находился в США И Португалии, а также имел email, заканчивающийся одновременно на @cloudflare.com AND @contractors.com. Поэтому доступа к приложению не будет ни у кого.

Решение: Используйте группа правил чтобы преобразовать логику AND в логику OR внутри правила Require.

1. Создайте группу правил с именем Country requirements которая включает пользователей в Португалии OR в США:

   Тип правила	Селектор	Значение
   Включить	Страна	United States, Portugal

2. Создайте политику, которая требует группу правил и также включает пользователей с адресами электронной почты, оканчивающимися на @cloudflare.com ИЛИ @contractors.com:

   Действие	Тип правила	Селектор	Значение
   Allow	Require	Группа правил	Country requirements
   	Включить	Адреса электронной почты, оканчивающиеся на	@cloudflare.com, @contractors.com

Когда вы добавляете правило в политику Cloudflare Access, вам нужно указать критерии, или атрибуты, которым должны соответствовать пользователи. Эти атрибуты доступны для всех типов приложений Access, включая SaaS, локально размещённый, а также не по HTTP приложения.

Неидентификационные атрибуты опрашиваются непрерывно, то есть проверяются на изменения при каждом новом HTTP-запросе в течение сессия пользователя. Если вы настроили Подготовка SCIM, вы можете заставить пользователя заново подтвердить все атрибуты в Access при отзыве пользователя в IdP или обновлении его членства в группе IdP.

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

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

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

Политики Cloudflare Access оцениваются на основе типа действия и заданного вами порядка. Сначала сверху вниз, в порядке, показанном в интерфейсе, оцениваются политики Bypass и Service Auth. Затем в том же порядке сверху вниз оцениваются политики Block и Allow.

Например, если ваши политики расположены следующим образом:

• Разрешить A
• Блок B
• Service Auth C
• Bypass D
• Разрешить E

Политики будут выполняться в следующем порядке: Service Auth C > Bypass D > Allow A > Block B > Allow E. Как только пользователь соответствует политике Allow или Block, оценка прекращается, и ни одна из последующих политик не может изменить это решение.

Если вы добавите любое из следующих правил в политику Allow, доступ к вашему приложению получит кто угодно.

В следующей таблице показана политика Cloudflare Access, которая включает всех пользователей:

В следующей таблице показана политика Cloudflare Access, которая включает всех пользователей с действительными методами входа по электронной почте:

API и Terraform предоставляют программные способы управления вашими политиками и конфигурациями Access.