Partager via


Sécuriser Azure Functions avec Event Hubs

Lorsque vous configurez l’accès aux ressources dans Azure, vous devez contrôler finement les autorisations d’accès aux ressources. L’accès à ces ressources doit être basé sur des principes de sécurité du besoin de savoir et du privilège minimum pour s’assurer que les clients ne puissent exécuter que l’ensemble limité d’actions qui leur sont attribuées.

Autorisation de l’accès à Event Hubs

L’autorisation d’accès aux ressources Azure Event Hubs peut être effectuée à l’aide des constructions de sécurité suivantes :

  • Microsoft Entra ID : Microsoft Entra ID fournit un contrôle d’accès en fonction du rôle (RBAC) pour un contrôle granulaire sur l’accès d’un client aux ressources Event Hubs. En fonction des rôles et des autorisations accordés, Microsoft Entra ID autorise les demandes à l’aide d’un jeton d’accès OAuth 2.0.

  • Signature d’accès partagé : une signature d’accès partagé (SAP) offre la possibilité de protéger des ressources Event Hubs en fonction de règles d’autorisation. Vous définissez des stratégies d’autorisation en sélectionnant une ou plusieurs règles de stratégie, telles que la possibilité d’envoyer des messages, d’écouter des messages et de gérer les entités dans l’espace de noms.

Considérations relatives à la signature d’accès partagé

Lorsque vous utilisez une signature d’accès partagé avec Azure Functions et Event Hubs, vous devez prendre en compte les considérations suivantes :

  • Éviter le droit de gestion : en plus de la possibilité de gérer les entités dans un espace de noms Event Hubs, le droit gérer comprend des droits d’envoi et d’écoute. Idéalement, une application de fonction ne devrait se voir accorder qu’une combinaison des droits d’envoi et d’écoute, selon les actions qu’elle effectue.

  • Ne pas utiliser de règle de gestion par défaut : évitez d’utiliser la règle de stratégie par défaut nommée RootManageSharedAccessKey, sauf si votre application de fonction l’exige, ce qui doit être un scénario rare. Une autre réserve à l’utilisation de cette règle par défaut est qu’elle est créée au niveau de l’espace de noms et accorde des autorisations d’accès à tous les hubs d’événements sous-jacents.

  • Examiner les étendues de stratégie d’accès partagé : des stratégies d’accès partagé peuvent être créées au niveau de l’espace de noms et par hub d’événements. Envisagez de créer des stratégies d’accès granulaires adaptées à chaque client pour limiter leur portée et leurs autorisations.

Identité managée

Une identité Active Directory peut être attribuée à une ressource managée dans Azure, par exemple, une application de fonction ou une application web. Une fois qu’une identité est attribuée, elle dispose des capacités nécessaires pour travailler avec d’autres ressources qui utilisent Microsoft Entra ID pour l’autorisation, à l’instar d’un principal de service.

Des applications de fonction peuvent se voir attribuer une identité managée et profiter de connexions basées sur une identité pour un sous-ensemble de services, dont Event Hubs. Les connexions basées sur une identité prennent en charge les extensions de liaison de déclenchement et de sortie, et doivent utiliser l’extension Event hubs 5.x ou version ultérieure pour la prise en charge.

Réseau

Par défaut, les espaces de noms Event Hubs sont accessibles à partir d’Internet tant que la demande s’accompagne d’une authentification et d’une autorisation valides. Il existe trois options pour limiter l’accès réseau aux espaces de noms Event Hubs :

Dans tous les cas, il est important de noter qu’au moins une règle de pare-feu IP ou une règle de réseau virtuel pour l’espace de noms est spécifiée. Dans le cas contraire, si aucune règle d’adresse IP ou de réseau virtuel n’est spécifiée, l’espace de noms est accessible via l’Internet public (à l’aide de la clé d’accès).

Azure Functions peut être configuré pour utiliser des événements ou publier des événements de hubs configurés avec des points de terminaison de service ou des points de terminaison privés. Une intégration de réseau virtuel régional est nécessaire pour que votre application de fonction se connecte à un hub d’événements à l’aide d’un point de terminaison de service ou d’un point de terminaison privé.

Lorsque vous intégrez Functions à un réseau virtuel et que vous activez vnetRouteAllEnabled, tout le trafic sortant de l’application de fonction est dirigé vers le réseau virtuel. Ceci est particulièrement important lorsque vous souhaitez sécuriser votre application de fonction en vous assurant que tout le trafic, y compris celui vers les services Azure, passe par votre réseau virtuel à des fins d’inspection et de contrôle. Si vous souhaitez verrouiller complètement votre application de fonction, vous devez également restreindre votre compte de stockage.

Pour déclencher (consommer) des événements dans un environnement de réseau virtuel, l’application de fonction doit être hébergée dans un plan Premium, un plan Dédié (App Service) ou un App Service Environment (ASE).

En outre, l’exécution dans un plan Azure Functions Premium et la consommation d’événements à partir d’un hub d’événements restreints de réseau virtuel nécessitent une prise en charge des déclencheurs de réseau virtuel, également appelée surveillance de la mise à l’échelle du runtime. Vous pouvez configurer la surveillance de la mise à l’échelle du runtime via le portail Azure, Azure CLI ou d’autres solutions de déploiement. La surveillance de la mise à l’échelle du runtime n’est pas disponible quand la fonction est exécutée dans un plan Dédié (App Service) ou un ASE.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Avant de continuer, songez à consulter les articles connexes suivants :

Traitement d’événements sans serveur est une architecture de référence détaillant une architecture typique de ce type, avec des exemples de code et des informations importantes à prendre en compte.