Utiliser le service Event Grid dans un contexte privé pour prévenir les intrusions

L’intégration des systèmes est devenue une nécessité pour les entreprises modernes. Les solutions d’intégration telles qu’Azure Event Grid, un produit de la plateforme AIS (Azure Integration Service), offrent des moyens flexibles pour connecter des systèmes hétérogènes, contribuent à l’automatisation des workflows, et à l’amélioration de l’efficacité opérationnelle.

Cependant, avec l’augmentation des cyberattaques et des violations de données, il est crucial de prendre des mesures de sécurité appropriées pour protéger les données sensibles qui transitent entre ces systèmes. Dans cet article, nous allons explorer les bonnes pratiques pour l’utilisation sécurisée d’Azure Event Grid, en mettant l’accent sur l’importance de la sécurité dans les solutions d’intégration.

Pour les curieux et qui n’ont pas encore eu l’occasion de travailler avec Event Grid je vous invite à consulter notre précédent article sur « Azure Integration Platform As A Service (IPaaS) : gérez vos événements avec Azure Event Grid & Logic Apps ».

La protection des données circulant sur Azure Event Grid

Azure Event Grid consiste à fournir/livrer des évènements en temps quasi réel pour synchroniser des données avec des systèmes tiers et/ou dans un système fortement découplé.

Avec cette facilité de communication vient une exposition accrue aux menaces de sécurité. Les événements qui transitent sur Azure Event Grid peuvent contenir des données sensibles, telles que des informations d’identification utilisateur ou des données de transaction financière. Par conséquent, il est important de s’assurer que ces données sont protégées pendant la transmission.

Pour garantir la sécurité des données transitant sur Azure Event Grid, il est essentiel d’utiliser :

1. Des méthodes de communication sécurisées (le chiffrement des données), telles que HTTPS ;
2. Des identités managées pour les abonnements à Event Grid (Event Subscriptions), afin de garantir que seuls les utilisateurs/applications autorisé(e)s peuvent accéder aux données ;
3. La configuration appropriée et la privatisation du réseau basé sur des VNet, private Link/Private Endpoint ;
4. Des définitions intégrées Azure Event Grid (Azure policies) ;
5. La mise en œuvre de la journalisation et de la surveillance peut aider à détecter et à prévenir les attaques avant qu’elles ne causent des dommages.

Event Grid et la sécurité dans un réseau privé : Possibilités et limitations

La mise en place de réseau privé dans le Cloud est un élément clé pour assurer la sécurité, la confidentialité, et surtout prévenir la fuite des données d’entreprise.

Private endpoints (publier les évènements)

Les private endpoints offrent une solution sécurisée pour publier des événements directement depuis votre réseau virtuel (VNet) vers des Topics personnalisés, sans avoir à passer par le réseau public. Le private link permet de créer une connexion privée entre le VNet et le Topic personnalisé, et le private endpoint utilise une adresse IP privée appartenant à l’espace d’adressage du VNet pour communiquer avec le Topic.

Utiliser le point de terminaison (private endpoint) pour Event Grid permet de :

• Sécuriser l’accès au Topic via un réseau virtuel privé (VNet) plutôt que via accès public.
• Sécuriser l’accès depuis le réseau local de l’entreprise dans le cas d’une infrastructure hybride (VPN Site-To-Site ou Express Route).

A noter :

• Les sources d’événements « publishers » qui envoient les événements sur le réseau virtuel (VNet) utilisant private endpoint doivent utiliser la même chaîne de connexion (connection string) pour se connecter via le réseau public (pas de changement).
• La résolution DNS route automatiquement les connexions du VNet vers le topic via un lien privé. Event Grid crée une zone DNS privée (Private DNS Zone) liée au VNet avec la mise à jour nécessaire pour les private endpoints, par défaut.
• La résolution DNS est résolue à partir du VNet hébergeant le private endpoint, l’URL du Topic est résolue en fonction de l’adresse IP du private endpoint. Les enregistrements de ressources DNS pour un Topic nommé par exemple “topicEX”, lorsqu’ils sont résolus à partir du VNet hébergeant le private endpoint, sera comme suit :

Voici le lien des étapes à suivre pour configurer un private endpoint Event Grid.

Pare-feu IP

Par défaut, les Topics Event Grid sont accessibles depuis Internet même si une authentification et une autorisation valide sont requises. Toutefois, l’accès réseau reste en public.

Par conséquent, en limitant l’accès des abonnements Event Grid (Event Subscriptions) à des adresses IP spécifiques à l’aide des règles de pare-feu réseau Azure, vous pouvez réduire le risque d’attaques de déni de service distribué (DDoS) et d’autres attaques par injection. Les règles de pare-feu réseau Azure permettent également de garantir que seuls les utilisateurs/applications autorisé(e)s peuvent accéder à votre Event Grid, ce qui contribue à protéger vos données.

Les sources d’événements « publishers » provenant d’autres adresses IP non autorisées dans le pare-feu seront rejetées, et recevront une réponse http 403 (pour découvrir les étapes à suivre pas à pas pour la configuration du pare-feu IP Event Grid, je vous invite à consulter la documentation Microsoft).

Délivrer les évènements via private endpoints : est-ce possible ?

A date, Microsoft a communiqué (dernière mise à jour le 02/03/2023) qu’Event Grid ne supporte pas la livraison des événements à des ressources privées (via private endpoint). En d’autres termes, il n’y a pas de prise en charge si vous avez des exigences strictes en matière d’isolation du réseau, où le trafic des événements livrés ne doit pas quitter votre VNet.

Pour cela, et pour pallier cette limitation, Microsoft préconise de mettre en place un middleware pour envoyer les évènements par exemple à des services tels qu’Event Hub, Service Bus ou Azure Storage, en utilisant les identités gérées (Managed Identity) type système (system-assigned) ou bien type utilisateur (user-assigned).

Ensuite, il est nécessaire d’utiliser un Private link configuré dans Azure Functions ou votre webhook déployé dans votre VNet pour recevoir les événements.

Via cette configuration, le trafic entre Azure Event Grid et Event Hubs, Service Bus, ou Azure Storage, reste dans le réseau de base Microsoft Azure (backbone Azure), et une identité managée est utilisée en occurrence.

En configurant webhook ou Azure Function dans le réseau virtuel (VNet) pour utiliser Event Hubs, Service Bus ou Stockage Azure via private endpoint, on peut garantir que le trafic entre ces services et webhook ou Azure Function reste confiné dans le périmètre du VNet.

Cette configuration permet de renforcer la sécurité de la solution d’intégration en limitant l’accès aux données transitant par ces services aux utilisateurs autorisés du VNet, et en réduisant les risques liés à la transmission de données sur Internet.

Voici la documentation Microsoft pour plus d’informations sur la livraison d’événements à l’aide d’une identité managée.

Event Grid : l’essentiel à retenir

En suivant les bonnes pratiques présentées dans cet article, vous pouvez renforcer la sécurité de votre solution d’intégration basée sur Azure Event Grid et réduire les risques de violation de données.

Enfin, la sécurité des données est une préoccupation majeure pour les entreprises et les organisations de toutes tailles, et la mise en œuvre des mesures de sécurité appropriées est essentielle pour protéger les données sensibles contre les cyberattaques et les violations de données. Avec Azure Event Grid, il est possible de garantir la sécurité des événements en utilisant des fonctionnalités telles que la configuration de l’accès réseau, la gestion des identités managées et des accès (ACLs).