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

Расширьте ZTNA с помощью внешней авторизации и бессерверных вычислений

Компании, использующие сервисы Zero Trust Network Access (ZTNA), создают политики, определяющие, может ли пользователь получить доступ к защищенному ресурсу, например к приватному Wiki-серверу или репозиторию исходного кода. Такие политики обычно опираются на членство в группах, методы аутентификации и состояние безопасности устройства, чтобы определить, какие пользователи могут получить доступ к каким ресурсам.

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

Например, у вас может быть политика, согласно которой все участники группы «Engineers», прошедшие аутентификацию с использованием учётных данных, требующих аппаратного токена, получают доступ к самостоятельно размещённому репозиторию исходного кода. Но вы также хотите разрешить доступ только тем инженерам, кто прошёл обучение по безопасности. Эти данные могут храниться в другой системе, поэтому Cloudflare позволяет в рамках проверки политики выполнить вызов с помощью Workers ↗ в систему обучения, чтобы определить, прошел ли этот пользователь обучение по безопасности.

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

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

В этом документе описано, как объединить оба решения, чтобы расширить возможности Cloudflare Access в части авторизация и аутентификация ↗.

• Настраиваемая логика авторизации: Доступ к внешней оценке с использованием Workers в качестве backend (например, с использованием собственной реализации Open Policy Agent, также известный как OPA ↗])
• Расширенная JSON Web Token (JWT): С использованием собственного материала аутентификации JWT от Cloudflare, например добавления данных posture в состав входящего запроса.
• Расширенные приложения Serverless, защищённые по модели Zero Trust: Позволяет всем, кто создает serverless-приложения, использовать встроенные функции ZTNA

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

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

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

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

Вот пример JWT, отправляемого на origin-сервер (используйте JWT.io ↗ чтобы прочитать содержимое JWT)

{
	"aud": ["264063895705477af73bfbaed1bf401981f4812eefcdb9fea33f5e10e666e282"],
	"email": "[email protected]",
	"exp": 1728551137,
	"iat": 1728464737,
	"nbf": 1728464737,
	"iss": "https://myorg.cloudflareaccess.com",
	"type": "app",
	"identity_nonce": "IA0hPRvwILtbUXSQ",
	"sub": "ce40d564-c72f-475f-a9b8-f395f19ad986",
	"device_id": "8469d7c4-83a9-11ee-b559-76e6e80876db",
	"country": "FR"
}

Cloudflare предоставляет определенный конечная точка чтобы любой мог проверить и декодировать JWT, подписанный Cloudflare.

Cloudflare Workers отлично подходят для работы с входящими JSON Web Tokens (JWT), позволяя выполнять дополнительную обработку прямо на serverless-платформе без дополнительной задержки.

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

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

При разворачивании JSON Web Token (JWT) становятся видны детали связанного с ним события аутентификации. Такое разворачивание раскрывает гораздо больше информации, чем предоставляется по умолчанию в самом JWT, пример приведён ниже.

{
  "id": "P51Tuu01fWHMBjIBvrCK1lK-eUDWs2aQMv03WDqT5oY",
  "name": "John Doe",
  "email": "[email protected]",
  "amr": [
    "pwd"
  ],
  "oidc_fields": {
    "principalName": "john.doe_cloudflare.com#EXT#@XXXXXXcloudflare.onmicrosoft.com"
  },
  "groups": [
    {
      "id": "fdaedb59-e9be-4ab7-8001-3e069da54185",
      "name": "Security Team"
    }
  ],
  "idp": {
    "id": "b9f4d68e-dac1-48b0-b728-ae05a5f0d4b2",
    "type": "azureAD"
  },
  "geo": {
    "country": "FR"
  },
  "user_uuid": "ce40d564-c72f-475f-a9b8-f395f19ad986",
  "account_id": "121287a0c6e6260ec930655e6b39a3a8",
  "iat": 1724056537,
  "devicePosture": {
    "f6f9391e-6776-4878-9c60-0cc807dc7dc8": {
      "id": "f6f9391e-6776-4878-9c60-0cc807dc7dc8",
      "schedule": "5m",
      "timestamp": "2024-08-19T08:31:59.274Z",
      "description": "",
      "type": "disk_encryption",
      "check": {
        "drives": {
          "C": {
            "encrypted": true
          }
        }
      },
      "success": false,
      "rule_name": "Disk Encryption - Windows",
      "input": {
        "requireAll": true,
        "checkDisks": []
    },
    "a0a8e83d-be75-4aa6-bfa0-5791da6e9186": {
      "id": "a0a8e83d-be75-4aa6-bfa0-5791da6e9186",
      "schedule": "5m",
      "timestamp": "2024-08-19T08:31:59.274Z",
      "description": "",
      "type": "firewall",
      "check": {
        "firewall": false
      },
      "success": false,
      "rule_name": "Local Firewall Check - Windows",
      "input": {
        "enabled": true
      }
    }
    ...
  }

Используя данные из JWT, можно с помощью Worker извлечь сведения о состоянии устройства (device posture) и добавить их обратно в HTTP-заголовки, которые приложение использует для собственной логики авторизации. Ниже приведено пошаговое руководство о том, как выполнить такую модификацию запроса на платформе Cloudflare Developer.

• Правила External Evaluation
• Эталонная архитектура SASE
• статья блога External Evaluation ↗