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

Принудительно применять MFA

Cloudflare Access поддерживает два способа применения многофакторной аутентификации (MFA):

• MFA на основе поставщика идентификации : Требуйте определённые методы MFA, о которых сообщает ваш поставщик идентификации (IdP).
• Независимая MFA : Запрашивайте у пользователей второй фактор непосредственно в Access, не полагаясь на стороннего поставщика идентификации.

Для подключений по SSH к инфраструктурные приложения, Access также поддерживает независимая MFA с ключами PIV и FIDO2.

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

Применение MFA на основе IdP доступно только для следующих поставщиков идентификации:

• Okta
• Microsoft Entra ID (ранее Azure AD)
• Универсальный OIDC
• Универсальный SAML 2.0

Чтобы применить к приложению требование MFA от IdP:

1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Приложения.

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

3. Перейдите в Политики.

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

5. Добавьте следующее правило в политику:

   Тип правила	Селектор	Значение
   Require	Метод аутентификации	mfa - multiple-factor authentication

6. Сохраните политику.

Когда пользователи проходят аутентификацию через поставщика идентификации, IdP передает имя пользователя в Cloudflare Access. Access записывает это значение в JSON Web Token (JWT) сгенерированный для пользователя.

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

Cloudflare Access следует RFC 8176 ↗, Authentication Method Reference Values, чтобы задать методы аутентификации.

Независимая MFA запрашивает у пользователей второй фактор непосредственно в Access. Это позволяет применять требования MFA, не полагаясь на настройки MFA вашего IdP.

Вы можете настроить требования MFA на трёх уровнях:

Настройки MFA применяются в следующем порядке приоритета: Политика > Приложение > Организация.

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

У каждого приложения есть три варианта MFA:

Чтобы настроить MFA для приложения:

1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Приложения.
2. Найдите приложение, которое вы хотите настроить, и выберите Настройте.
3. Прокрутите вниз до Аутентификация и выберите MFA.tab.
4. Выберите один из следующих вариантов:
   • Чтобы унаследовать настройку организации, выберите Учитывать глобальную настройку принудительного применения.
   • Чтобы задать особые требования, выберите Пользовательские настройки MFA, затем настройте разрешённые методы MFA и продолжительность аутентификации.
   • Чтобы освободить приложение от MFA, выберите Отключить MFA.
5. Выберите Save.

Чтобы настроить MFA для инфраструктурного приложения, см. Приложения Infrastructure.

У каждой политики одинаковые три варианта MFA, описанные в Настройте независимую MFA для приложения. Настройки на уровне политики имеют приоритет над настройками на уровне приложения.

1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Политики.
2. Выберите Allow политику и выберите Настройте.
3. В разделе Многофакторная аутентификация (MFA), выберите вариант:
   • Чтобы унаследовать настройку приложения или организации, выберите Учитывать глобальную настройку принудительного применения.
   • Чтобы задать особые требования для пользователей, соответствующих этой политике, выберите Пользовательские настройки MFA, затем настройте разрешённые методы MFA и продолжительность аутентификации.
   • Чтобы освободить от MFA пользователей, соответствующих этой политике, выберите Отключить MFA.
4. Выберите Save.

Чтобы настроить MFA для политики инфраструктурного приложения, см. Приложения Infrastructure.

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

Access проверяет сессии MFA от наиболее специфичной к наименее специфичной:

1. Длительность сессии Policy MFA : Если задано, применяется к пользователям, соответствующим политике.
2. Длительность сеанса MFA приложения : Если задано, применяется ко всем пользователям, обращающимся к приложению.
3. Продолжительность глобальной сессии MFA : Значение по умолчанию для всех приложений, которые не задают собственную длительность.

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

• Организация : Перейдите в Zero Trust > Контроль доступа > Настройки Access > Разрешить многофакторную аутентификацию (MFA). Задайте Длительность аутентификации к Требовать при каждом входе. Это применяется ко всем приложениям, если не переопределено на уровне приложения или политики. Подробнее см. настройки независимой MFA.
• Приложение : Перейдите в Zero Trust > Контроль доступа > Приложения > выберите своё приложение > Настройте > Аутентификация > MFA вкладке. Выберите Пользовательские настройки MFA и задайте Длительность аутентификации к Требовать при каждом входе.
• Политика : Перейдите в Zero Trust > Контроль доступа > Политики > выберите свою политику > Настройте. В разделе Многофакторная аутентификация (MFA), выберите Пользовательские настройки MFA и задайте Длительность аутентификации к Требовать при каждом входе.

Чтобы настроить это для приложения через API, сначала отправьте GET запрос на получение полной конфигурации приложения, затем отправьте PUT запрос с полным телом приложения, включая обновленный mfa_config. Задайте session_duration к "0m":

curl --request PUT \
https://api.cloudflare.com/client/v4/accounts/{account_id}/access/apps/{app_id} \
--header "Authorization: Bearer <API_TOKEN>" \
--header "Content-Type: application/json" \
--data '{
  "mfa_config": {
    "mfa_disabled": false,
    "session_duration": "0m"
  }
}'

Рассмотрим следующую конфигурацию:

flowchart TD
    subgraph org["Organization"]
        orgSettings["**Apply global MFA settings by default**, <br/>**MFA methods**: Authenticator app + Security key, <br/>**Authentication duration**: 24 hours"]
    end

    subgraph appA["Application A"]
        appASettings["**Respect global enforcement setting**<br/>(inherits organization settings)"]
        subgraph policies["Policies"]
            policy1["Policy 1<br/>**Custom MFA settings**,<br/>**MFA methods**: Security keys only,<br/>**Authentication duration**: 1 hour"]
            policy2["Policy 2<br/>**Disable MFA**"]
        end
    end

    subgraph appB["Application B"]
        appBSettings["**Disable MFA**"]
    end

    orgSettings --> appASettings
    orgSettings -.->|"overridden"| appBSettings
    appASettings -.->|"overridden by"| policy1
    appASettings -.->|"overridden by"| policy2

В этом примере:

• Пользователи, которые обращаются к Application A и соответствуют Policy 1, должны использовать ключ безопасности и проходить повторную аутентификацию каждый час.
• Пользователям, которые обращаются к Application A и соответствуют Policy 2, не предлагается пройти MFA.
• Пользователи, которые обращаются к Application A и не соответствуют ни одной из политик, должны использовать приложение-аутентификатор или ключ безопасности, с сессией продолжительностью 24 часа.
• Пользователям, которые обращаются к Application B, не предлагается пройти MFA.

Приложения Infrastructure, использующие SSH, поддерживают два метода MFA, доступных только приложениям Infrastructure. piv_key использует зарегистрированный ключ Personal Identity Verification (PIV). ssh_fido2_key использует зарегистрированный ключ FIDO2. Ни один из этих методов не применяется к другим типам приложений Access или к аутентификации WebAuthn в браузере.

Вы можете настроить MFA для приложений Infrastructure на уровне приложения или на уровне политики.

Выберите ключ PIV, ключ FIDO2 или оба варианта при настройке пользовательской MFA. Соответствующие массивы API: ["piv_key"], ["ssh_fido2_key"], а также ["piv_key", "ssh_fido2_key"].

curl --request PUT \
https://api.cloudflare.com/client/v4/accounts/{account_id}/access/apps/{app_id} \
--header "Authorization: Bearer <API_TOKEN>" \
--header "Content-Type: application/json" \
--data '{
  "mfa_config": {
    "mfa_disabled": false,
    "session_duration": "12h",
    "allowed_authenticators": ["piv_key", "ssh_fido2_key"]
  }
}'

Настроив MFA на уровне политики, можно задать разные требования MFA для разных имён пользователей SSH. Настройки MFA уровня политики имеют приоритет над настройками уровня приложения.

curl --request PUT \
https://api.cloudflare.com/client/v4/accounts/{account_id}/access/policies/{policy_id} \
--header "Authorization: Bearer <API_TOKEN>" \
--header "Content-Type: application/json" \
--data '{
  "name": "Require MFA for root",
  "decision": "allow",
  "include": [
    {
      "email": {
        "email": "[email protected]"
      }
    }
  ],
  "mfa_config": {
    "mfa_disabled": false,
    "session_duration": "1h",
    "allowed_authenticators": ["piv_key", "ssh_fido2_key"]
  },
  "connection_rules": {
    "ssh": {
      "usernames": ["root"],
      "allow_email_alias": false
    }
  }
}'

Длительность сессии MFA определяет, как долго пользователи могут открывать новые SSH-подключения без повторного запроса MFA. Задайте длительность равной 0m и требуйте MFA для каждого нового подключения. Истечение срока действия не завершает активное подключение.

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

Длительность сессии определяется в следующем порядке:

1. Длительность на уровне политики : Если задано, применяется к пользователям, соответствующим политике.
2. Длительность на уровне приложения : Если длительность на уровне политики не задана, используется настройка приложения.
3. Длительность на уровне организации : Если ни политика, ни приложение не задают длительность, используется глобальная настройка.

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

Конфигурация MFA оценивается от наиболее специфичной к наименее специфичной: политика > приложение > организация.

Чтобы пользователи могли регистрировать ключи PIV, необходимо включить MFA на уровне организации. Явные настройки на более низком уровне (политика или приложение) переопределяют настройки более высоких уровней. Если на каком-либо уровне явная настройка отсутствует, применяется настройка следующего более высокого уровня.