Contrôle de l’accès aux événements
Azure Event Hubs prend en charge Microsoft Entra ID et les signatures d’accès partagé (SAS) pour gérer les authentifications et les autorisations. Azure fournit les rôles intégrés Azure suivants pour autoriser l’accès aux données Event Hubs à l’aide de Microsoft Entra ID et d’OAuth :
- Propriétaire de données Azure Event Hubs : utilisez ce rôle pour accorder un accès complet aux ressources Event Hubs.
- Expéditeur de données Azure Event Hubs : utilisez ce rôle pour accorder l’accès en envoi aux ressources Event Hubs.
- Récepteur de données Azure Event Hubs : utilisez ce rôle pour accorder l’accès en réception aux ressources Event Hubs.
Autorisation de l’accès avec des identités managées
Pour autoriser l’envoi d’une demande au service Event Hubs à partir d’une identité managée dans votre application, vous devez configurer les paramètres de contrôle d’accès en fonction du rôle Azure de cette identité managée. Azure Event Hubs définit les rôles Azure qui englobent les autorisations d’envoi et de lecture à partir d’Event Hubs. Quand le rôle Azure est attribué à une identité managée, celle-ci est autorisée à accéder aux données Event Hubs selon l’étendue appropriée.
Autorisation de l’accès avec la Plateforme d’identités Microsoft
Le principal avantage d’utiliser Microsoft Entra ID avec Event Hubs est que vos informations d’identification n’ont plus besoin d’être stockées dans votre code. À la place, vous pouvez demander un jeton d’accès OAuth 2.0 sur la plateforme d’identités Microsoft. Microsoft Entra authentifie le principal de sécurité (un utilisateur, un groupe ou un principal de service) qui exécute l’application. Si l’authentification réussit, Microsoft Entra ID retourne le jeton d’accès à l’application et l’application peut ensuite l’utiliser pour autoriser les demandes sur Azure Event Hubs.
Autoriser l’accès aux éditeurs Event Hubs avec des signatures d’accès partagé
Un émetteur d’événements définit un point de terminaison virtuel pour un hub d’événements. L’éditeur peut être utilisé uniquement pour envoyer des messages à un hub d’événements et non pour en recevoir. En règle générale, un hub d’événements utilise un seul éditeur par client. Tous les messages qui sont envoyés à l’un des éditeurs d’un hub d’événements sont empilés dans celui-ci. Les éditeurs permettent un contrôle d’accès précis.
Chaque client Event Hubs reçoit un jeton unique qui est chargé sur le client. Un client qui possède un jeton ne peut envoyer qu’à un seul éditeur et à aucun autre. Si plusieurs clients partagent le même jeton, alors ils partagent l’éditeur.
Tous les jetons sont affectés avec des clés de signature d’accès partagé. En règle générale, tous les jetons sont signés avec la même clé. Les clients n’ont pas connaissance de la clé, ce qui les empêche de fabriquer des jetons. Les clients utilisent les mêmes jetons jusqu’à leur expiration.
Autorisation de l’accès à des consommateurs Event Hubs avec des signatures d’accès partagé
Pour authentifier les applications back-end qui consomment des données générées par des producteurs Event hubs, l’authentification par jeton Event Hubs nécessite que les clients disposent des droits de gestion ou des privilèges d’écoute attribués à l’espace de noms Event hubs ou à l’instance ou la rubrique de hub d’événements. Les données sont consommées à partir de Event Hubs par le biais de groupes de consommateurs. Même si la stratégie SAS vous donne une étendue granulaire, cette étendue est définie uniquement au niveau de l’entité et non au niveau du consommateur. Cela signifie que les privilèges définis au niveau de l’espace de noms ou au niveau de la rubrique ou de l’instance du hub d’événements sont appliqués aux groupes de consommateurs de cette entité.