Проверка конечной точки с помощью схемы событий Сетки событий

Веб-перехватчики — это один из многих способов получения событий из службы "Сетка событий Azure". Когда новое событие будет готово, служба сетки событий отправляет HTTP-запрос в настроенную конечную точку с информацией о событии в тексте запроса.

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

Проверка конечной точки с помощью событий Сетки событий

При использовании любой из следующих трех служб Azure инфраструктура Azure автоматически обрабатывает эту проверку:

• Azure Logic Apps с соединителем Сетки событий;
• служба автоматизации Azure через веб-перехватчик;
• Функции Azure с триггером службы "Сетка событий".

При использовании любого другого типа конечной точки, такого как функция Azure на основе триггера HTTP, код конечной точки должен участвовать в подтверждении проверки со службой "Сетка событий". Сетка событий поддерживает два типа проверки подписки.

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

• Асинхронное подтверждение. В некоторых случаях вы не можете синхронно возвращать validationCode в ответе. Например, если вы используете службу, не связанную с Корпорацией Майкрософт (напримерZapier, IFTTT), вы не можете программно реагировать на код проверки.

  Сетка событий поддерживает подтверждение проверки вручную. Если вы создаете подписку на события с помощью пакета SDK или инструмента, который использует версию API 2018-05-01-preview или более позднюю, Сетка событий отправит свойство validationUrl в часть данных события проверки подписки. Чтобы выполнить подтверждение, найдите URL-адрес в данных события и отправьте по нему запрос GET. Вы можете использовать клиент REST или свой веб-браузер.

  Указанный URL-адрес действителен в течение 10 минут. В течение этого времени состояние подготовки подписки на событие находится в AwaitingManualAction. Если вы не завершили проверку вручную в течение 10 минут, состояние обеспечения установится на Failed. Перед началом проверки вручную необходимо создать подписку на события.

  Для этого механизма проверки подлинности также требуется, чтобы конечная точка веб-перехватчика возвращала код состояния HTTP 200 для подтверждения, что POST для события проверки был принят, прежде чем он может быть переведен в режим ручной проверки. Другими словами, если конечная точка возвращает код 200, но синхронно не возвращает ответ проверки, режим переходит в режим ручной проверки. Если в течение 10 минут имеется URL-адрес проверки GET, подтверждение проверки считается успешным.

Примечание.

Использование самозаверяющих сертификатов для проверки не поддерживается. Вместо этого используйте подписанный сертификат из коммерческого центра сертификации (ЦС).

Сведения о проверке

• Во время создания или обновления подписки на события Сетка событий публикует в целевую конечную точку событие проверки подписки.
• В качестве заголовка событие содержит значение aeg-event-type: SubscriptionValidation.
• Текст события имеет ту же схему, что и другие события сетки событий.
• Свойство eventType события имеет значение Microsoft.EventGrid.SubscriptionValidationEvent.
• К свойству data события относится свойство validationCode со строкой, сгенерированной случайным образом. Например, validationCode: acb13….
• Данные о событии включают свойство validationUrl с URL-адресом для проверки подписки вручную.
• Массив содержит только событие проверки. Другие события отправляются в отдельном запросе после возврата кода проверки.
• Пакеты SDK для плоскости данных сетки событий имеют классы, соответствующие данным события проверки подписки и ответу на проверку подписки.

Пример SubscriptionValidationEvent показан в следующем примере:

[
  {
    "id": "2d1781af-3a4c-4d7c-bd0c-e34b19da4e66",
    "topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "subject": "",
    "data": {
      "validationCode": "512d38b6-c7b8-40c8-89fe-f46f9e9622b6",
      "validationUrl": "https://rp-eastus2.eventgrid.azure.net:553/eventsubscriptions/myeventsub/validate?id=0000000000-0000-0000-0000-00000000000000&t=2022-10-28T04:23:35.1981776Z&apiVersion=2018-05-01-preview&token=1A1A1A1A"
    },
    "eventType": "Microsoft.EventGrid.SubscriptionValidationEvent",
    "eventTime": "2022-10-28T04:23:35.1981776Z",
    "metadataVersion": "1",
    "dataVersion": "1"
  }
]

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

{
  "validationResponse": "512d38b6-c7b8-40c8-89fe-f46f9e9622b6"
}

А также выполните одно из следующих действий:

• Должен возвратиться код состояния ответа HTTP 200 OK. HTTP 202 Accepted не распознается как действительный ответ проверки подписки Сетки событий. HTTP-запрос должен быть выполнен в течение 30 секунд. Если операция не завершается в течение 30 секунд, операция будет отменена, и она повторно презрится через 5 секунд. Если все попытки завершаются ошибкой, она рассматривается как ошибка подтверждения проверки.

  Если приложение готово к обработке и возврату кода проверки, это означает, что вы создали подписку на события и ожидали получения события. Представьте себе сценарий, в котором не поддерживается проверка подтверждения, и хакер получает сведения о URL-адресе приложения. Злоумышленник может создать раздел и подписку на события с URL-адресом вашего приложения и начать DoS-атаку на приложение, отправив большое количество событий. Проверка подтверждения предотвращает такие ситуации.

  Представьте, что в приложении уже реализована проверка, так как вы создали собственные подписки на события. Даже если хакер создает подписку на события с URL-адресом приложения, правильная реализация события запроса проверки проверяет заголовок aeg-subscription-name в запросе, чтобы убедиться, что это подписка на события, которую вы распознаете.

  Даже после правильной реализации подтверждения злоумышленник может произвести flood-атаку на приложение (где уже прошла проверка подписки на события), реплицируя запрос, который якобы поступает из Сетки событий. Чтобы предотвратить это, необходимо защитить веб-перехватчик с помощью проверки подлинности Microsoft Entra. Дополнительные сведения см. в разделе "Доставка событий в защищенные конечные точки Microsoft Entra".

• Можно также вручную проверить подписку, отправив запрос GET по URL-адресу проверки. Подписка на событие остается в состоянии ожидания, пока проверка не будет завершена. URL-адрес проверки использует порт 553. Если правила брандмауэра блокируют порт 553, необходимо обновить правила для успешного подтверждения вручную.

  При проверке события проверки подписки, если вы определяете, что это не подписка на события, для которой вы ожидаете события, вы не вернете ответ 200 или вообще не ответ. Поэтому проверка завершается ошибкой.

Пример обработки подтверждения проверки подписки на C# см. на сайте GitHub.

Связанный контент

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