Implémenter des contrôles de sécurité pour les applications logiques
Les workflows Azure Logic Apps sont soumis à la même exigence de sécurité à trois niveaux que les applications Function : contrôler qui peut invoquer un déclencheur de workflow, l’identité que le workflow utilise lors de l’authentification auprès des connecteurs, et le chemin réseau pouvant atteindre le point de terminaison du déclencheur. Les contrôles disponibles et la façon dont vous les configurez dépendent du plan d’hébergement Logic Apps que vous choisissez. La sélection de plan est une décision de sécurité, pas seulement un coût ou une décision de mise à l’échelle.
Choisir entre la consommation et le plan Standard
Les workflows Logic Apps de type Consommation s’exécutent dans un environnement partagé et multilocataire géré par Microsoft. Les flux de travail standard s’exécutent dans un environnement monolocataire dédié. Cette différence architecturale a des implications directes en matière de sécurité qui affectent les contrôles que vous pouvez appliquer.
Le plan Consommation offre des contrôles réseau limités. Vous pouvez configurer des restrictions IP sur le point de terminaison du déclencheur et restreindre l’accès à l’historique des exécutions, mais l’intégration de réseau virtuel et les points de terminaison privés ne sont pas pris en charge. Si, un flux de travail Consommation doit appeler des ressources privées ( un SQL Server sans accès public ou un compte de stockage limité à des sous-réseaux de réseau virtuel spécifiques), vous avez besoin de services intermédiaires tels que Gestion des API Azure ou une passerelle de données locale pour combler l’écart réseau.
Le plan Standard prend en charge l’ensemble complet de contrôles réseau disponibles dans Azure App Service : intégration de réseau virtuel pour les appels de connecteur sortant, points de terminaison privés pour les demandes de déclencheur entrant et le même modèle de restriction d’accès utilisé dans Azure Functions. Les flux de travail de plan standard s’exécutent également de manière isolée des flux de travail d’autres locataires.
| Capacité | Consumption | Norme |
|---|---|---|
| Restrictions IP sur le déclencheur | ✔ | ✔ |
| Intégration de réseau virtuel (sortant) | ✗ | ✔ |
| Point de terminaison privé (entrant) | ✗ | ✔ |
| Isolation à locataire unique | ✗ | ✔ |
Pour les flux de travail qui gèrent des données personnelles (données personnelles), des données financières, des jetons d’authentification ou des appels à des ressources privées, le plan Standard est le choix approprié. Les limitations du réseau du plan Consommation constituent un écart de sécurité significatif pour ces charges de travail, et non un inconvénient mineur.
Utiliser l’identité managée pour l’authentification du connecteur
Les connecteurs Logic Apps utilisent des ressources de connexion pour s’authentifier auprès des services externes. Par défaut, ces ressources de connexion stockent les informations d’identification ( nom d’utilisateur et mot de passe, clé API ou clé secrète client OAuth) qui persistent dans la configuration de la connexion et sont visibles par toute personne ayant accès à la ressource d’application logique.
L’authentification d’identité managée pour les connecteurs remplace les informations d’identification stockées par une identité managée Azure. L’application logique utilise son identité managée affectée par le système ou affectée par l’utilisateur pour s’authentifier auprès des services Azure pris en charge par le biais de connecteurs. Les connecteurs pris en charge incluent Stockage Blob Azure, Azure Service Bus, Azure SQL Server, Azure Cosmos DB et Azure Key Vault.
Pour configurer l’identité managée pour un connecteur :
- Activez une identité managée sur l’application logique : accédez à Identity et définissez l’identité affectée par le système sur Activé, ou configurez une identité affectée par l’utilisateur.
- Lors de l’ajout ou de la modification d’une action de connecteur dans le concepteur de flux de travail, sélectionnez Identité managée comme type d’authentification.
- Attribuez à l’identité managée le rôle approprié sur la ressource cible, par exemple, Storage Blob Data Contributor pour accéder au stockage blob Azure.
Tous les connecteurs Logic Apps ne prennent pas en charge l’authentification d’identité managée. Avant de concevoir un flux de travail autour de ce modèle, vérifiez que vos connecteurs requis le prennent en charge. Pour les connecteurs qui ne prennent pas en charge l'identité managée, stockez les informations d'identification dans Azure Key Vault et référencez-les à partir de la configuration de la ressource de connexion, plutôt que d'entrer des informations d'identification directement dans la connexion.
Tip
La documentation du connecteur Azure Logic Apps pour chaque service répertorie les types d’authentification pris en charge. Vérifiez cela avant de générer le flux de travail, car la modification des méthodes d’authentification après qu’un flux de travail est en production nécessite la recréation des connexions affectées.
Restreindre l’accès au déclencheur avec des listes d’autorisation IP
Les déclencheurs de points de terminaison pour Logic Apps sont des points de terminaison HTTP. Vous pouvez restreindre les adresses IP qui peuvent appeler un déclencheur en configurant des listes d’autorisation IP, en bloquant toutes les autres adresses sources avant l’exécution du flux de travail.
Pour les flux de travail du plan Consommation, configurez les restrictions d’accès de déclencheur dans les paramètres de flux de travail sous configuration du contrôle d’accès. Spécifiez les plages d’adresses IP autorisées à appeler le déclencheur. Toutes les autres adresses IP sources sont rejetées.
Pour les flux de travail de plan Standard, configurez les restrictions d’accès dans Networking>Access restrictions, à l’aide de la même interface que Azure Functions. Vous pouvez autoriser des plages d’adresses IP spécifiques, des blocs CIDR (Classless Inter-Domain Route) ou des balises de service Azure.
Les règles d’étiquette de service sont utiles pour les applications logiques qui gèrent uniquement les événements provenant de services Azure spécifiques. Par exemple, le fait de restreindre le déclencheur à l’étiquette de service AzureEventGrid signifie uniquement les appels provenant de Azure Event Grid peuvent appeler le flux de travail. Les requêtes HTTP arbitraires provenant d’autres sources sont bloquées indépendamment de l’URL qu’ils utilisent.
Configurer des points de terminaison privés et l’intégration de réseau virtuel pour le plan Standard
Les applications logiques Standard prennent en charge le même modèle d’intégration avec des points de terminaison privés et des réseaux virtuels que les applications de fonction Elastic Premium. Ces contrôles sont configurés au niveau de la ressource Logic App (Standard) et s’appliquent à tous les flux de travail au sein de cette ressource.
Un point de terminaison privé pour une application logique standard affecte au point de terminaison de déclencheur de flux de travail une adresse IP privée au sein de votre réseau virtuel. Les appelants externes ne peuvent pas atteindre l’URL du déclencheur à partir de l’Internet public. Seules les ressources du réseau virtuel ou des réseaux connectés via le peering ou ExpressRoute peuvent appeler le flux de travail. Il s’agit de la configuration correcte pour les flux de travail qui traitent des données sensibles et qui ne doivent être accessibles qu’à partir de systèmes internes.
L’intégration de réseau virtuel pour les appels sortants permet à l’application logique d’effectuer des appels de connecteur à des ressources qui ne sont pas accessibles publiquement. Une fois l’intégration de réseau virtuel activée sur une application logique standard, les actions de connecteur peuvent atteindre un SQL Server sans point de terminaison public, un compte de stockage verrouillé sur un sous-réseau spécifique ou une API REST privée hébergée en interne, les mêmes fonctionnalités sortantes disponibles pour les applications de fonction Elastic Premium.
Note
Les points de terminaison privés et l’intégration de réseau virtuel pour Logic Apps sont disponibles uniquement sur le plan Standard. Si votre organisation a initialement déployé des flux de travail sur le plan Consommation et identifié ultérieurement une exigence pour l’accès au réseau privé, la migration vers le plan Standard n’est requise : il n’existe aucun chemin de mise à niveau sur place entre les types de plan.
Protéger les données sensibles dans l’historique des exécutions
Logic Apps stocke les entrées et sorties de chaque action dans l’historique des exécutions, visible dans le portail Azure. Ce comportement par défaut est utile pour le débogage, mais pour les actions qui traitent des données sensibles ( mots de passe, jetons d’authentification, données personnelles ou informations d’identification), il expose ces données à toute personne disposant d’un accès en lecture à la ressource d’application logique.
Les paramètres d’entrées sécurisées et de sorties sécurisées sur des actions individuelles obfusent les valeurs stockées dans l’historique des exécutions. Lorsqu’il est activé, le portail s’affiche [Redacted] au lieu du contenu réel. Le flux de travail traite toujours les données au moment de l’exécution. Seul le stockage de ces données dans l’historique des exécutions est affecté.
Activez les entrées et sorties sécurisées sur toute action qui gère :
- Jetons d’authentification ou clés API passés entre les étapes
- Données personnelles récupérées à partir de bases de données ou de systèmes externes
- Informations d’identification référencées à partir de connexions Key Vault
- Champs sensibles dans les corps de requête ou de réponse HTTP
Important
Les entrées et sorties sécurisées sont configurées par action, et non au niveau du flux de travail. Passez en revue chaque action dans les flux de travail sensibles à la sécurité individuellement et activez les deux paramètres le cas échéant. Une action antérieure dans le workflow qui traite les données sensibles sans sorties sécurisées activées expose ces données dans l’historique des exécutions même si toutes les actions en aval sont sécurisées.
Exiger l’authentification OAuth 2.0 pour les déclencheurs HTTP (plan standard)
Les workflows d’application logique du plan Standard prennent en charge la validation des jetons OAuth 2.0 pour les déclencheurs HTTP via Microsoft Entra ID. Lorsqu’il est configuré, le déclencheur nécessite un jeton d’accès Microsoft Entra valide avant que le flux de travail ne démarre — le même mécanisme d’application que celui d’EasyAuth sur les applications Function.
Pour activer OAuth 2.0 sur un déclencheur HTTP de plan Standard, configurez une stratégie d’autorisation sur le déclencheur. Ajoutez une stratégie d’autorisation Microsoft Entra ID qui spécifie l’audience autorisée, l’ID d’application (client) de l’enregistrement d’application, ainsi que le locataire requis. Les requêtes dépourvues d’un jeton Bearer valide conforme à la politique sont rejetées avant qu’une action du workflow ne soit exécutée.
Cette configuration est utile pour les flux de travail du plan Standard exposés comme points de terminaison d’API, qui ne doivent pouvoir être appelés que par des applications ou identités spécifiques enregistrées dans Microsoft Entra. Lorsque vous combinez la configuration avec des restrictions IP ou un point de terminaison privé, la validation de jeton OAuth 2.0 sur le déclencheur crée deux barrières d’authentification indépendantes.