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

Я работаю над проектом, который использует сетку событий Azure, где веб-приложение отправляет настраиваемое событие в сетку событий, а веб-перехватчик в отдельном приложении используется для подписки на эти события.

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

Есть ли способ ограничить сетку событий приемом событий только из определенного источника или сохранить и получить ключ из Key Vault, что является наиболее безопасным вариантом из доступных?


azure azure-security azure-authentication azure-eventgrid
person anonuser1    schedule 22.11.2019    source источник
comment
взгляните на docs.microsoft.com/en-us / лазурный / сетка событий / домены событий   -  person Roman Kiss    schedule 22.11.2019

Ответы (1)


arrow_upward
0
arrow_downward

При публикации сообщений в теме вы можете аутентифицироваться с помощью ключа или токена SAS.

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

    Один из способов защитить этот подход - использовать KeyVault, как вы упомянули. Клиенты могут безопасно подключаться к KeyVault с помощью Managed Удостоверение (при работе в Azure) или поток учетных данных клиента.

  2. Рекомендуется использовать токены SAS для защиты конечной точки публикации. Для этого вам нужно будет генерировать токены по мере необходимости, используя ключ (тот же ключ, что и в 1).

    При таком подходе у вас может быть API (например, функция Azure), который генерирует токены SAS от имени ваших клиентов. Этому API все равно потребуется ключ (который может быть в KeyVault) для генерации токенов SAS.

  3. Другой подход - иметь API, который мог бы пересылать события в Event Grid после аутентификации / авторизации. Этому API все равно потребуется доступ к ключу.

    Этого можно достичь несколькими способами, например

person PramodValavala-MSFT    schedule 05.12.2019
comment
Если я использую keyvault или MSI; есть ли способ автоматической ротации ключей, и чтобы приложение публикации автоматически получало новые ключи. Интересно, предоставить MSI прямой доступ для чтения ключа, но я не видел: а) какие разрешения требуются; или б) как программно читать ключ. Я не вижу преимуществ использования keyvault в этом случае, если MSI может быть предоставлен доступ только для чтения к ключам в первую очередь. Вы можете использовать SAS - это здорово, но я не вижу, как создать его прагматично, не дав системе ключ, который побеждает объект - person rgammans; 02.09.2020