← Cloudflare One / cloudflare-one / access-controls / policies

Распространённые политики

Следующие политики Cloudflare Access обычно используются для защиты приложений.

См. Страница политик Access для полного списка доступных действий, типов правил и селекторов. Чтобы узнать, как создавать политики и управлять ими, см. Управлять политиками Access.

Разрешить сотрудников по домену электронной почты

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

Действие	Тип правила	Селектор	Значение
Allow	Включить	Адреса электронной почты, оканчивающиеся на	`@example.com`

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Создать многократно используемую политику Access

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Allow employees by email domain",
		"decision": "allow",
		"include": [
				{
						"email_domain": {
								"domain": "example.com"
						}
				}
		]
	}'

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Настройте cloudflare_zero_trust_access_policy ↗ ресурс:

resource "cloudflare_zero_trust_access_policy" "allow_employees_by_email_domain" {
  account_id = var.cloudflare_account_id
  name       = "Allow employees by email domain"
  decision   = "allow"
  include = [{
    email_domain = {
      domain = "example.com"
    }
  }]
}

Вы можете добавить несколько доменов электронной почты в правило Include, если ваша организация использует более одного домена (например, @example.com и @example.co.uk).

Разрешить сотрудников из определённых стран

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

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

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

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Organizations, Identity Providers, and Groups Write

Создать группу Access

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/groups" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Approved countries",
		"include": [
				{
						"geo": {
								"country_code": "US"
						}
				},
				{
						"geo": {
								"country_code": "PT"
						}
				}
		]
	}'

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Настройте cloudflare_zero_trust_access_group ↗ ресурс:

resource "cloudflare_zero_trust_access_group" "approved_countries" {
  account_id = var.cloudflare_account_id
  name       = "Approved countries"
  include = [
    {
      geo = {
        country_code = "US"
      }
    },
    {
      geo = {
        country_code = "PT"
      }
    },
  ]
}

Затем укажите группу правил в своей политике Access:

Действие	Тип правила	Селектор	Значение
Allow	Включить	Адреса электронной почты, оканчивающиеся на	`@example.com`
	Require	Группа правил	`Approved countries`
	Exclude	Электронная почта	`[email protected]`, `[email protected]`

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Создать многократно используемую политику Access

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Allow employees from specific countries",
		"decision": "allow",
		"include": [
				{
						"email_domain": {
								"domain": "example.com"
						}
				}
		],
		"require": [
				{
						"group": {
								"id": "<APPROVED_COUNTRIES_GROUP_ID>"
						}
				}
		],
		"exclude": [
				{
						"email": {
								"email": "[email protected]"
						}
				},
				{
						"email": {
								"email": "[email protected]"
						}
				}
		]
	}'

Замените <APPROVED_COUNTRIES_GROUP_ID> на id возвращённый при создании группы правил выше. Чтобы найти существующие группы, используйте List Access groups конечная точка.

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Настройте cloudflare_zero_trust_access_policy ↗ ресурс:

resource "cloudflare_zero_trust_access_policy" "allow_employees_from_specific_countries" {
  account_id = var.cloudflare_account_id
  name       = "Allow employees from specific countries"
  decision   = "allow"
  include = [{
    email_domain = {
      domain = "example.com"
    }
  }]
  require = [{
    group = {
      id = cloudflare_zero_trust_access_group.approved_countries.id
    }
  }]
  exclude = [
    {
      email = {
        email = "[email protected]"
      }
    },
    {
      email = {
        email = "[email protected]"
      }
    },
  ]
}

cloudflare_zero_trust_access_group.approved_countries ссылка указывает на cloudflare_zero_trust_access_group ↗ ресурс, созданный выше.

Требовать состояния устройства для важных приложений

Для приложений с конфиденциальными данными можно проверять, что пользователи подключаются с управляемых устройств, соответствующих базовым требованиям безопасности вашей организации. В следующем примере проверка личности сочетается с проверки состояния устройства чтобы убедиться, что на устройстве используется поддерживаемая Версия ОС и подключается через Cloudflare One Client, что обеспечивается Требовать проверки Gateway.

Действие	Тип правила	Селектор	Значение
Allow	Включить	Группы Okta	`Full-Time Employees`
	Require	Gateway	`Gateway`
	Require	Версия ОС	`Latest version of Windows`

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Создать многократно используемую политику Access

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Require device posture for sensitive apps",
		"decision": "allow",
		"include": [
				{
						"okta": {
								"name": "Full-Time Employees",
								"identity_provider_id": "<OKTA_IDP_ID>"
						}
				}
		],
		"require": [
				{
						"device_posture": {
								"integration_uid": "<GATEWAY_CHECK_ID>"
						}
				},
				{
						"device_posture": {
								"integration_uid": "<OS_VERSION_CHECK_ID>"
						}
				}
		]
	}'

Замените okta правило с подходящее правило для вашего провайдера идентификации. Чтобы получить ID поставщика идентификации, используйте List Access identity providers конечная точка. Чтобы получить UID интеграций для проверок состояния устройства, используйте List device posture checks конечная точка.

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Настройте cloudflare_zero_trust_access_policy ↗ ресурс:

resource "cloudflare_zero_trust_access_policy" "require_device_posture" {
  account_id = var.cloudflare_account_id
  name       = "Require device posture for sensitive apps"
  decision   = "allow"
  include = [{
    okta = {
      name                 = "Full-Time Employees"
      identity_provider_id = cloudflare_zero_trust_access_identity_provider.okta.id
    }
  }]
  require = [
    {
      device_posture = {
        integration_uid = cloudflare_zero_trust_device_posture_rule.gateway_check.id
      }
    },
    {
      device_posture = {
        integration_uid = cloudflare_zero_trust_device_posture_rule.os_version_check.id
      }
    },
  ]
}

Замените okta правило с соответствующим cloudflare_zero_trust_access_identity_provider ↗ ресурс для вашего поставщика идентификации. Инструкции по настройке ресурса поставщика идентификации см. в Поставщики удостоверений.
Чтобы настроить cloudflare_zero_trust_device_posture_rule ↗ ресурсы, указанные выше, см. в Проверки состояния устройства.

Чтобы использовать эти требования к устройству в нескольких приложениях, создайте группа правил с именем «Требования к корпоративным устройствам», содержащую проверки состояния. Затем эту группу правил можно указать в поле Require любой политики.

Требовать MFA для приложений с повышенным уровнем защиты

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

Access поддерживает два подхода к применению MFA:

MFA на основе поставщика идентификации

Если ваш поставщик идентификации сообщает метод аутентификации, использованный при входе, можно добавить Метод аутентификации селектор, чтобы требовать конкретный метод MFA, например аппаратный ключ безопасности.

Действие	Тип правила	Селектор	Значение
Allow	Включить	Группы Okta	`Employees`
	Require	Метод аутентификации	`Security key`
	Require	Gateway	(включено)

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Создать многократно используемую политику Access

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Require MFA for high-security apps",
		"decision": "allow",
		"include": [
				{
						"okta": {
								"name": "Employees",
								"identity_provider_id": "<OKTA_IDP_ID>"
						}
				}
		],
		"require": [
				{
						"auth_method": {
								"auth_method": "swk"
						}
				},
				{
						"device_posture": {
								"integration_uid": "<GATEWAY_CHECK_ID>"
						}
				}
		]
	}'

auth_method значение использует RFC 8176 ↗ референсные значения метода аутентификации из swk обозначает программно защищенный ключ (ключ безопасности). Замените okta правило с подходящее правило для вашего провайдера идентификации. Чтобы получить ID поставщика идентификации, используйте List Access identity providers конечная точка. Чтобы получить <GATEWAY_CHECK_ID>, используйте List device posture checks конечная точка.

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Настройте cloudflare_zero_trust_access_policy ↗ ресурс:

resource "cloudflare_zero_trust_access_policy" "require_mfa" {
  account_id = var.cloudflare_account_id
  name       = "Require MFA for high-security apps"
  decision   = "allow"
  include = [{
    okta = {
      name                 = "Employees"
      identity_provider_id = cloudflare_zero_trust_access_identity_provider.okta.id
    }
  }]
  require = [
    {
      auth_method = {
        auth_method = "swk"
      }
    },
    {
      device_posture = {
        integration_uid = cloudflare_zero_trust_device_posture_rule.gateway_check.id
      }
    },
  ]
}

auth_method значение использует RFC 8176 ↗ референсные значения метода аутентификации из swk обозначает программно защищенный ключ (ключ безопасности).

Замените okta правило с соответствующим cloudflare_zero_trust_access_identity_provider ↗ ресурс для вашего поставщика идентификации. Инструкции по настройке ресурса поставщика идентификации см. в Поставщики удостоверений.
Чтобы настроить cloudflare_zero_trust_device_posture_rule ↗ ресурс, указанный выше, см. в Проверки состояния устройства.

Независимая MFA

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

Подробнее об обоих подходах см. в Принудительно применять MFA.

Разрешить доступ подрядчиков с аутентификацией по электронной почте

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

Действие	Тип правила	Селектор	Значение
Allow	Включить	Адреса электронной почты, оканчивающиеся на	`@contractor-a.com`, `@contractor-b.com`
	Require	Login methods	`One-time PIN`

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Создать многократно используемую политику Access

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Allow contractor access with OTP",
		"decision": "allow",
		"include": [
				{
						"email_domain": {
								"domain": "contractor-a.com"
						}
				},
				{
						"email_domain": {
								"domain": "contractor-b.com"
						}
				}
		],
		"require": [
				{
						"login_method": {
								"id": "<OTP_IDENTITY_PROVIDER_ID>"
						}
				}
		]
	}'

Чтобы получить ID вашего провайдера идентификации OTP, используйте List Access identity providers конечная точка.

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Настройте cloudflare_zero_trust_access_policy ↗ ресурс:

resource "cloudflare_zero_trust_access_policy" "allow_contractor_access_with_otp" {
  account_id = var.cloudflare_account_id
  name       = "Allow contractor access with OTP"
  decision   = "allow"
  include = [
    {
      email_domain = {
        domain = "contractor-a.com"
      }
    },
    {
      email_domain = {
        domain = "contractor-b.com"
      }
    },
  ]
  require = [{
    login_method = {
      id = cloudflare_zero_trust_access_identity_provider.otp.id
    }
  }]
}

Чтобы настроить cloudflare_zero_trust_access_identity_provider ↗ ресурс для OTP (настроенный с помощью type = "onetimepin"), см. Одноразовый PIN.

Изолировать доступ подрядчиков к внутренним приложениям

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

Действие	Тип правила	Селектор	Значение
Allow	Включить	Адреса электронной почты, оканчивающиеся на	`@contractor-a.com`, `@contractor-b.com`

Дополнительные настройки: Включить Изолировать приложение.

Сначала включите Clientless Web Isolation в своём аккаунте, если вы ещё этого не сделали:

Patch: настройка конфигурации аккаунта Zero Trust

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/configuration" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"settings": {
				"browser_isolation": {
						"url_browser_isolation_enabled": true
				}
		}
	}'

Затем создайте политику Access с isolation_required имеет значение true:

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Создать многократно используемую политику Access

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Isolate contractor access",
		"decision": "allow",
		"include": [
				{
						"email_domain": {
								"domain": "contractor-a.com"
						}
				},
				{
						"email_domain": {
								"domain": "contractor-b.com"
						}
				}
		],
		"isolation_required": true
	}'

Сначала настройте cloudflare_zero_trust_gateway_settings ↗ ресурс, чтобы включить Clientless Web Isolation в аккаунте, если вы ещё этого не сделали:

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Zero Trust Write

resource "cloudflare_zero_trust_gateway_settings" "gateway_settings" {
  account_id = var.cloudflare_account_id
  settings = {
    browser_isolation = {
      url_browser_isolation_enabled = true
    }
  }
}

Затем настройте cloudflare_zero_trust_access_policy ↗ ресурс с isolation_required имеет значение true:

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

resource "cloudflare_zero_trust_access_policy" "isolate_contractor_access" {
  account_id         = var.cloudflare_account_id
  name               = "Isolate contractor access"
  decision           = "allow"
  isolation_required = true
  include = [
    {
      email_domain = {
        domain = "contractor-a.com"
      }
    },
    {
      email_domain = {
        domain = "contractor-b.com"
      }
    },
  ]
}

Чтобы ограничить действия пользователей внутри изолированного сеанса, создайте сопутствующую Политика HTTP Gateway который соответствует трафику к домену приложения. Установите для действия значение Изолировать и отключите интерактивные элементы управления в настройки политики.

Пример HTTP-политики Gateway

Селектор	Оператор	Значение	Действие
Домен	in	`wiki.example.com`	Изолировать

Настройки политики:

Параметр	Значение
Copy	Не разрешать
Вставить	Не разрешать
Клавиатура	Не разрешать
Загрузки файлов	Не разрешать
Загрузка файлов	Не разрешать
Печать	Не разрешать

Подробнее см. в Изолировать самостоятельно размещённое приложение.

Заблокировать запросы из стран высокого риска

Если ваша организация ограничивает доступ из определённых стран из-за внутренней политики или нормативных требований, таких как Санкции OFAC ↗ или нормы ITAR ↗, вы можете создать политику Block, запрещающую доступ из этих регионов. Добавление корпоративного allowlist IP-адресов в качестве правила Exclude гарантирует, что сотрудники, подключающиеся через доверенные офисные сети, не будут заблокированы по ошибке.

Действие	Тип правила	Селектор	Значение
Block	Включить	Страна	`Russian Federation`
	Exclude	Список IP-адресов	`Corporate IP allowlist`

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Создать многократно используемую политику Access

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Block requests from high-risk countries",
		"decision": "deny",
		"include": [
				{
						"geo": {
								"country_code": "RU"
						}
				}
		],
		"exclude": [
				{
						"ip_list": {
								"id": "<CORPORATE_IP_ALLOWLIST_ID>"
						}
				}
		]
	}'

Чтобы получить ID вашего списка IP-адресов, используйте List Zero Trust lists конечная точка.

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Настройте cloudflare_zero_trust_access_policy ↗ ресурс:

resource "cloudflare_zero_trust_access_policy" "block_high_risk_countries" {
  account_id = var.cloudflare_account_id
  name       = "Block requests from high-risk countries"
  decision   = "deny"
  include = [{
    geo = {
      country_code = "RU"
    }
  }]
  exclude = [{
    ip_list = {
      id = cloudflare_zero_trust_list.corporate_ip_allowlist.id
    }
  }]
}

Чтобы настроить cloudflare_zero_trust_list ↗ ресурс, указанный выше (настроенный с помощью type = "IP"), см. Lists.

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

Исключить пользователей с высоким риском

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

Действие	Тип правила	Селектор	Значение
Allow	Включить	Адреса электронной почты, оканчивающиеся на	`@example.com`
	Exclude	Оценка риска пользователя	High

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Создать многократно используемую политику Access

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Exclude high-risk users",
		"decision": "allow",
		"include": [
				{
						"email_domain": {
								"domain": "example.com"
						}
				}
		],
		"exclude": [
				{
						"user_risk_score": {
								"user_risk_score": [
										"high"
								]
						}
				}
		]
	}'

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Настройте cloudflare_zero_trust_access_policy ↗ ресурс:

resource "cloudflare_zero_trust_access_policy" "exclude_high_risk_users" {
  account_id = var.cloudflare_account_id
  name       = "Exclude high-risk users"
  decision   = "allow"
  include = [{
    email_domain = {
      domain = "example.com"
    }
  }]
  exclude = [{
    user_risk_score = {
      user_risk_score = ["high"]
    }
  }]
}

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

Аутентификация службы с помощью токена службы

Автоматизированным службам, таким как конвейеры CI/CD, системы мониторинга и backend-API, требуется доступ к защищённым приложениям без интерактивного входа. Политики Service Auth обеспечивают взаимодействие по принципу «машина-машина», аутентифицируя запросы, которые содержат действительные токен службы заголовки. Для дополнительной безопасности вы можете ограничить токен запросами из определенных диапазонов IP-адресов, чтобы он мог использоваться только из известной инфраструктуры.

Действие	Тип правила	Селектор	Значение
Service Auth	Включить	Service Token	`My service token`
	Require	Диапазоны IP-адресов	`192.0.2.0/24`

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Создать многократно используемую политику Access

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Authenticate service with service token",
		"decision": "non_identity",
		"include": [
				{
						"service_token": {
								"token_id": "<SERVICE_TOKEN_ID>"
						}
				}
		],
		"require": [
				{
						"ip": {
								"ip": "192.0.2.0/24"
						}
				}
		]
	}'

Чтобы получить ID вашего токена службы, используйте List service tokens конечная точка.

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Настройте cloudflare_zero_trust_access_policy ↗ ресурс:

resource "cloudflare_zero_trust_access_policy" "authenticate_service_with_token" {
  account_id = var.cloudflare_account_id
  name       = "Authenticate service with service token"
  decision   = "non_identity"
  include = [{
    service_token = {
      token_id = cloudflare_zero_trust_access_service_token.my_service_token.id
    }
  }]
  require = [{
    ip = {
      ip = "192.0.2.0/24"
    }
  }]
}

Чтобы настроить cloudflare_zero_trust_access_service_token ↗ ресурс, указанный выше, см. в Service tokens.

Аутентификация службы с помощью взаимного TLS

Для сред, где требуется аутентификация на основе сертификатов, можно использовать взаимный TLS (mTLS) чтобы убедиться, что подключающийся клиент предъявляет действительный сертификат с ожидаемой идентификацией. mTLS полезен для аутентификации автоматизированных систем и устройств IoT, которые не используют поставщика идентификации, а также в качестве дополнительного фактора аутентификации для участников команды, которые также входят в систему через IdP.

Чтобы ограничить доступ для конкретного клиента, используйте Общее имя селектор, чтобы сопоставить личность в клиентском сертификате:

Действие	Тип правила	Селектор	Значение
Service Auth	Включить	Общее имя	`John Doe`

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Создать многократно используемую политику Access

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Authenticate service with mTLS",
		"decision": "non_identity",
		"include": [
				{
						"common_name": {
								"common_name": "John Doe"
						}
				}
		]
	}'

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Настройте cloudflare_zero_trust_access_policy ↗ ресурс:

resource "cloudflare_zero_trust_access_policy" "authenticate_service_with_mtls" {
  account_id = var.cloudflare_account_id
  name       = "Authenticate service with mTLS"
  decision   = "non_identity"
  include = [{
    common_name = {
      common_name = "John Doe"
    }
  }]
}

Чтобы разрешить доступ любому клиенту, предъявляющему действительный сертификат, подписанный вашим CA, используйте Valid Certificate селектор. Этот селектор полезен, если вы доверяете всем сертификатам, выданным вашим CA, и вам не нужно проверять конкретное значение Common Name.

Действие	Тип правила	Селектор
Service Auth	Включить	Valid Certificate

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Создать многократно используемую политику Access

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Authenticate service with valid certificate",
		"decision": "non_identity",
		"include": [
				{
						"certificate": {}
				}
		]
	}'

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Настройте cloudflare_zero_trust_access_policy ↗ ресурс:

resource "cloudflare_zero_trust_access_policy" "authenticate_service_with_valid_certificate" {
  account_id = var.cloudflare_account_id
  name       = "Authenticate service with valid certificate"
  decision   = "non_identity"
  include = [{
    certificate = {}
  }]
}

Требовать обоснования цели для важных приложений

Для таких приложений, как инструменты администрирования баз данных, консоли production-среды или HR-системы, можно требовать от пользователей указывать письменную причину при каждом обращении к приложению. Это создаёт журнал аудита, который помогает командам безопасности понять, зачем запрашивался доступ. Запрос обоснования отображается после аутентификации пользователя и перед переходом к приложению. Подробнее см. в Требовать обоснования цели.

Действие	Тип правила	Селектор	Значение
Allow	Включить	Группы Okta	`IT Administrators`
	Require	Gateway	`Gateway`
	Require	Версия ОС	`Latest version of Windows`

Дополнительные настройки: Включить Обоснование цели.

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Создать многократно используемую политику Access

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Require purpose justification for sensitive apps",
		"decision": "allow",
		"include": [
				{
						"okta": {
								"name": "IT Administrators",
								"identity_provider_id": "<OKTA_IDP_ID>"
						}
				}
		],
		"require": [
				{
						"device_posture": {
								"integration_uid": "<GATEWAY_CHECK_ID>"
						}
				},
				{
						"device_posture": {
								"integration_uid": "<WINDOWS_VERSION_CHECK_ID>"
						}
				}
		],
		"purpose_justification_required": true,
		"purpose_justification_prompt": "Please enter a justification for accessing this application."
	}'

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Настройте cloudflare_zero_trust_access_policy ↗ ресурс:

resource "cloudflare_zero_trust_access_policy" "require_purpose_justification" {
  account_id                      = var.cloudflare_account_id
  name                            = "Require purpose justification for sensitive apps"
  decision                        = "allow"
  purpose_justification_required  = true
  purpose_justification_prompt    = "Please enter a justification for accessing this application."
  include = [{
    okta = {
      name                 = "IT Administrators"
      identity_provider_id = cloudflare_zero_trust_access_identity_provider.okta.id
    }
  }]
  require = [
    {
      device_posture = {
        integration_uid = cloudflare_zero_trust_device_posture_rule.gateway_check.id
      }
    },
    {
      device_posture = {
        integration_uid = cloudflare_zero_trust_device_posture_rule.windows_version.id
      }
    },
  ]
}

Замените okta правило с соответствующим cloudflare_zero_trust_access_identity_provider ↗ ресурс для вашего поставщика идентификации. Инструкции по настройке ресурса поставщика идентификации см. в Поставщики удостоверений.
Чтобы настроить cloudflare_zero_trust_device_posture_rule ↗ ресурсы, указанные выше, см. в Проверки состояния устройства.

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

Обход публичной конечной точки

У некоторых приложений есть конечные точки, которые должны быть доступны публично, например URL обратного вызова OAuth, приемники webhook или пути проверки работоспособности. Вы можете создать политику Bypass, ограниченную конкретным путь приложения чтобы отключить применение Access только для этой конечной точки. Например, если ваше приложение app.example.com, вы могли бы создать отдельное приложение Access для app.example.com/oauth/callback и примените следующую политику Bypass:

Действие	Тип правила	Селектор	Значение
Bypass	Включить	Все	`Everyone`

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Создать многократно используемую политику Access

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/policies" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Bypass public endpoint",
		"decision": "bypass",
		"include": [
				{
						"everyone": {}
				}
		]
	}'

Необходимые разрешения API-токена

Хотя бы одно из следующих права доступа токена требуется:

Access: Apps and Policies Write

Настройте cloudflare_zero_trust_access_policy ↗ ресурс:

resource "cloudflare_zero_trust_access_policy" "bypass_public_endpoint" {
  account_id = var.cloudflare_account_id
  name       = "Bypass public endpoint"
  decision   = "bypass"
  include = [{
    everyone = {}
  }]
}