Sécuriser l’accès et les données pour les flux de travail dans Azure Logic Apps
Azure Logic Apps s’appuie sur le Stockage Azure pour stocker et chiffrer automatiquement les données au repos. Ce chiffrement protège vos données et vous aide à répondre aux engagements de votre entreprise en matière de sécurité et de conformité. Par défaut, Stockage Azure utilise des clés managées par Microsoft pour chiffrer vos données. Pour plus d'informations, consultez Fonctionnalité de chiffrement du service Stockage Azure pour les données au repos.
Pour contrôler l’accès aux données sensibles et les protéger dans Azure Logic Apps, vous pouvez configurer des paramètres de sécurité supplémentaires dans les domaines suivants :
- Accès aux opérations d’une application logique
- Accès aux entrées et aux sorties de l’historique des exécutions
- Accès aux entrées de paramètres
- Types d’authentification pour les déclencheurs et les actions qui prennent en charge l’authentification
- Accès pour les appels entrants à des déclencheurs basés sur des requêtes
- Accès pour les appels sortants à d’autres services et systèmes
- Blocage de la création de connexions pour des connecteurs spécifiques
- Conseils d’isolation pour les applications logiques
- Base de référence de sécurité Azure pour Azure Logic Apps
Pour plus d’informations sur la sécurité dans Azure, consultez les rubriques suivantes :
- Vue d’ensemble du chiffrement Azure
- Azure Data Encryption-at-Rest (Chiffrement des données Azure au repos)
- Point de référence de sécurité Microsoft Cloud
Accès aux opérations d’une application logique
Pour les applications logiques Consommation uniquement, avant de pouvoir créer ou gérer des applications logiques et leurs connexions, vous avez besoin d'autorisations spécifiques, fournies par des rôles à l’aide du contrôle d'accès en fonction du rôle Azure (Azure RBAC). Vous pouvez également configurer des autorisations afin que seuls des utilisateurs ou des groupes spécifiques puissent exécuter des tâches spécifiques, telles que la gestion, la modification et l’affichage des applications logiques. Pour contrôle les autorisations, vous pouvez attribuer des rôles intégrés ou personnalisés aux membres qui ont accès à votre abonnement Azure. Azure Logic Apps a les rôles spécifiques suivants, selon que vous avez un flux de travail d'application logique de type Consommation ou Standard :
Workflows Consommation
| Rôle | Description |
|---|---|
| Contributeur d’application logique | Vous pouvez gérer les flux de travail d’applications logiques, mais pas en modifier l’accès. |
| Opérateur d’application logique | Vous pouvez lire, activer et désactiver des flux de travail d’applications logiques, mais pas les modifier ni les mettre à jour. |
| Contributeur | Vous avez un accès total pour gérer toutes les ressources, mais ne vous pouvez pas affecter des rôles dans Azure RBAC, de gérer des affectations dans Azure Blueprints ou de partager des galeries d’images. |
Par exemple, supposez que vous devez utiliser un flux de travail d’application logique que vous n’avez pas créée, et authentifier les connexions utilisées par le flux de travail de cette application logique. Votre abonnement Azure requiert des autorisations de Contributeur pour le groupe de ressources qui contient cette ressource d’application logique. Si vous créez une ressource d’application logique, vous bénéficiez automatiquement d’un accès Contributeur.
Pour empêcher la modification ou la suppression de votre flux de travail d’application logique, vous pouvez utiliser le Verrouillage de la ressource Azure. Grâce à cette fonctionnalité, vous pouvez empêcher d’autres utilisateurs de modifier ou de supprimer des ressources de production. Pour plus d’informations sur la sécurité des connexions, consultez Configuration de la connexion dans Azure Logic Apps et Sécurité et chiffrement de la connexion.
Workflows Standard
Remarque
Cette fonctionnalité est en préversion et est soumise aux conditions d’utilisation supplémentaires des préversions de Microsoft Azure.
| Rôle | Description |
|---|---|
| Lecteur Logic Apps Standard (Préversion) | Vous avez un accès en lecture seule à toutes les ressources d'une application logique Standard et aux flux de travail, y compris les exécutions de flux de travail et leur historique. |
| Opérateur Logic Apps Standard (Préversion) | Vous avez le droit d'activer, de soumettre à nouveau et de désactiver des flux de travail et de créer des connexions avec des services, des systèmes et des réseaux pour une application logique Standard. Le rôle d'opérateur permet d'effectuer des tâches d'administration et de support sur la plateforme Azure Logic Apps, mais ne permet pas de modifier les flux de travail ou les paramètres. |
| Développeur Logic Apps Standard (Préversion) | Vous avez accès à la création et à la modification des flux de travail, des connexions et des paramètres d'une application logique Standard. Le rôle Développeur n'est pas autorisé à apporter des modifications en dehors du champ d'application des flux de travail, par exemple, des modifications à l'échelle de l'application telles que la configuration de l'intégration du réseau virtuel. Les plans App Service ne sont pas pris en charge. |
| Contributeur Logic Apps Standard (Préversion) | Vous avez accès à la gestion de tous les aspects d'une application de logique Standard, mais vous ne pouvez pas modifier l'accès ou la propriété. |
Accès à l’historique des exécutions
Pendant l’exécution d’une application logique, toutes les données sont chiffrées pendant le transit à l’aide de Transport Layer Security (TLS) et au repos. À la fin de l’exécution de votre application logique, vous pouvez afficher l’historique de l’exécution. Celui-ci comprend notamment les étapes exécutées, ainsi que l’état, la durée, les entrées et les sorties associés à chaque action. Ces informations détaillées fournissent des insights sur la façon dont votre application logique s’est exécutée et vous permettent de résoudre les problèmes qui peuvent survenir.
Lorsque vous affichez l’historique des exécutions de votre application logique, Azure Logic Apps authentifie votre accès, et fournit des liens vers les entrées et les sorties des requêtes et des réponses pour chaque exécution. Toutefois, pour les actions qui gèrent des mots de passe, des secrets, des clés ou d’autres informations sensibles, vous devez empêcher les autres utilisateurs d’accéder à ces données. Par exemple, si votre application logique obtient un secret dans Azure Key Vault en vue de l’utiliser lors de l’authentification d’une action HTTP, vous devez empêcher l’affichage de ce secret.
Pour contrôler l’accès aux entrées et aux sorties dans l’historique des exécutions de votre application logique, vous disposez des options suivantes :
Restreindre l’accès en fonction de la plage d’adresses IP.
Cette option vous aide à sécuriser l’accès à l’historique des exécutions en fonction des requêtes provenant d’une plage d’adresses IP spécifique.
Sécuriser les données dans l’historique des exécutions à l’aide d’une obfuscation.
Vous pouvez sécuriser les entrées et/ou sorties de nombreux déclencheurs et actions dans l’historique d’exécution d’une application logique.
Restreindre l’accès en fonction de la plage d’adresses IP
Vous pouvez limiter l’accès aux entrées et sorties de l’historique d’exécution de vos flux de travail de l’application logique afin que seules les requêtes provenant de plages d’adresses IP spécifiques soient en mesure de visualiser ces données.
Par exemple, pour empêcher quiconque d’accéder aux entrées et aux sorties, spécifiez une plage d’adresses IP comme celle-ci : 0.0.0.0-0.0.0.0. Seule une personne disposant de droits d’administrateur peut supprimer cette restriction, ce qui permet un accès « juste à temps » aux données dans les flux de travail de votre application logique. Une plage d’adresses IP valide utilise ces formats : x.x.x.x/x ou x.x.x.x-x.x.x.x
Pour spécifier les plages d’adresses IP autorisées, suivez ces étapes selon que vous utilisez le portail Azure ou votre modèle Azure Resource Manager :
Workflows Consommation
Sur le Portail Azure, ouvrez votre flux de travail d’application logique dans le Concepteur.
Dans le menu de votre application logique, sous Paramètres, sélectionnez Paramètres de flux de travail.
Sous Configuration du contrôle d’accès>Adresses IP entrantes autorisées, sélectionnez Plages d’adresses IP spécifiques.
Sous Plages d’adresses IP pour le contenu, spécifiez les plages d’adresses IP qui peuvent accéder au contenu issu des entrées et sorties.
Workflows Standard
Dans le portail Azure, ouvrez votre ressource d’application logique.
Dans le menu de l’application logique, sous Paramètres, sélectionnez Mise en réseau.
Dans la section Trafic entrant, sélectionnez Restriction d’accès.
Créez une ou plusieurs règles pour Autoriser ou Refuser les requêtes provenant de plages d’adresses IP spécifiques. Vous pouvez également utiliser les paramètres de filtre d’en-tête HTTP et les paramètres de transfert.
Pour plus d’informations, consultez Blocage des adresses IP entrantes dans Azure Logic Apps (Standard).
Sécuriser les données dans l’historique des exécutions à l’aide d’une obfuscation
De nombreux déclencheurs et actions disposent de paramètres permettant sécuriser les entrées et/ou sorties dans l’historique d’exécution d’une application logique. L’ensemble des connecteurs managés et des connecteurs personnalisés prennent en charge ces options. Cependant, les opérations intégrées ci-aprèsne prennent pas en charge les options suivantes :
| Entrées sécurisées - non prises en charge | Sorties sécurisées - non prises en charge |
|---|---|
| Ajouter à une variable tableau Ajouter à une variable chaîne Décrémenter une variable Pour chaque Si Incrémenter une variable Initialiser la variable Périodicité Étendue Définir une variable Commutateur Terminate Jusqu’à |
Ajouter à une variable tableau Ajouter à une variable chaîne Composer Décrémenter une variable Pour chaque Si Incrémenter une variable Initialiser la variable Analyse JSON Périodicité response Étendue Définir une variable Commutateur Terminate Jusqu’à Wait |
Considérations relatives à la sécurisation des entrées et des sorties
Avant d’utiliser ces paramètres pour sécuriser ces données, prenez connaissance des considérations suivantes :
Quand vous rendez secrètes les entrées ou les sorties d’un déclencheur ou d’une action, Azure Logic Apps n’envoie pas les données sécurisées à Azure Log Analytics. De plus, vous ne pouvez pas ajouter de propriétés suivies à ce déclencheur ou à cette action à des fins de supervision.
L’API Azure Logic Apps qui permet de gérer l’historique des workflows ne retourne pas de sorties sécurisées.
Pour sécuriser les sorties d’une action qui rend les entrées secrètes ou qui rend explicitement les sorties secrètes, activez manuellement Sorties sécurisées dans cette action.
Veillez à activer Entrées sécurisées ou Sorties sécurisées dans les actions en aval, où l’historique des exécutions doit rendre ces données secrètes.
Paramètre Sorties sécurisées
Lorsque vous activez manuellement les sorties sécurisées dans un déclencheur ou dans une action, Azure Logic Apps masque ces sorties dans l’historique des exécutions. Si une action en aval utilise explicitement ces sorties sécurisées comme des entrées, Azure Logic Apps masque les entrées de cette action dans l’historique des exécutions, mais il n’active pas le paramètre Entrées sécurisées de l’action.
Les actions Composer, Analyser JSON et Réponse comportent uniquement le paramètre Entrées sécurisées. Lorsqu’il est activé, ce paramètre masque également les sorties de ces actions. Si ces actions utilisent explicitement les sorties sécurisées en amont comme des entrées, Azure Logic Apps masque les entrées et les sorties de ces actions, mais il n’active pas le paramètre Entrées sécurisées de ces actions. Si une action en aval utilise explicitement les sorties masquées des actions Composer, Analyser JSON ou Réponse comme des entrées, Azure Logic Apps ne masque pas les entrées ou les sorties de cette action en aval.
Paramètre Entrées sécurisées
Lorsque vous activez manuellement les entrées sécurisées dans un déclencheur ou dans une action, Azure Logic Apps masque ces entrées dans l’historique des exécutions. Si une action en aval utilise explicitement les sorties visibles de ce déclencheur ou de cette action comme des entrées, Azure Logic Apps masque les entrées de cette action en aval dans l’historique des exécutions, mais il n’active pas les entrées sécurisées de cette action, et ne masque pas les sorties de cette action.
Si les actions Composer, Analyser JSON et Réponse utilisent explicitement les sorties visibles du déclencheur ou de l’action qui a des entrées sécurisées, Azure Logic Apps masque les entrées et les sorties de ces actions, mais il n’active pas le paramètre Entrées sécurisées de ces actions. Si une action en aval utilise explicitement les sorties masquées des actions Composer, Analyser JSON ou Réponse comme des entrées, Azure Logic Apps ne masque pas les entrées ou les sorties de cette action en aval.
Sécuriser les entrées et sorties dans le concepteur
Sur le Portail Azure, ouvrez votre flux de travail d’application logique dans le Concepteur.
Dans le concepteur, sélectionnez le déclencheur ou l’action dont vous souhaitez sécuriser les données sensibles.
Dans le volet d’informations qui s’ouvre, sélectionnez Paramètres, puis développez Sécurité.
Activez Entrées sécurisées, Sorties sécurisées, ou les deux.
Le déclencheur ou l’action affiche désormais une icône de verrouillage dans la barre de titre. Tous les jetons qui représentent les sorties sécurisées d’actions précédentes affichent également les icônes verrou. Par exemple, dans une action suivante, après avoir sélectionné un jeton pour une sortie sécurisée dans la liste de contenu dynamique, ce jeton affiche une icône de verrouillage.
Après l’exécution du flux de travail, vous pouvez voir l’historique de cette exécution.
Sélectionnez Vue d’ensemble dans le menu de l’application logique Consommation ou dans le menu du flux de travail Standard.
Dans Historique des exécutions, sélectionnez l’exécution que vous souhaitez consulter.
Dans le volet de l’historique des exécutions du flux de travail, sélectionnez les actions que vous souhaitez réviser.
Si vous avez choisi de masquer à la fois les entrées et les sorties, ces valeurs sont désormais masquées.
Sécuriser les entrées et sorties en mode Code
Dans la définition de déclencheur ou d’action sous-jacente, ajoutez ou mettez à jour le tableau runtimeConfiguration.secureData.properties avec une des deux valeurs ou les deux :
"inputs": Sécurise les entrées dans l’historique des exécutions."outputs": Sécurise les sorties dans l’historique des exécutions.
"<trigger-or-action-name>": {
"type": "<trigger-or-action-type>",
"inputs": {
<trigger-or-action-inputs>
},
"runtimeConfiguration": {
"secureData": {
"properties": [
"inputs",
"outputs"
]
}
},
<other-attributes>
}
Accès aux entrées de paramètres
Si vous effectuez des déploiements dans différents environnements, vous pouvez paramétrer les valeurs de votre définition de workflow qui varient selon l’environnement. De cette façon, vous pouvez éviter les données codées en dur en utilisant un modèle Azure Resource Manager pour déployer votre application logique, protéger les données sensibles en définissant des paramètres sécurisés et transmettre ces données sous forme d’entrées distinctes par le biais des paramètres du modèle à l’aide d’un fichier de paramètres.
Par exemple, si vous authentifiez des actions HTTP avec OAuth avec Microsoft Entra ID, vous pouvez définir et rendre secrets les paramètres qui acceptent l’ID client et la clé secrète client utilisés pour l’authentification. Pour définir ces paramètres dans le flux de travail de votre application logique, utilisez la section parameters située dans la définition du flux de travail de votre application logique et dans le modèle de déploiement de Resource Manager. Pour sécuriser les valeurs de paramètre que vous ne voulez pas présenter lors de la modification de votre application logique ou de la consultation de l’historique des exécutions, configurez les paramètres avec le type securestring ou secureobject et utilisez un encodage si nécessaire. Les paramètres de ce type ne sont pas retournés avec la définition de la ressource, et ne sont pas accessibles lors de l’affichage de la ressource après le déploiement. Pour accéder à ces valeurs de paramètre pendant l’exécution, utilisez l’expression @parameters('<parameter-name>') située dans la définition de votre workflow. Cette expression est évaluée uniquement au moment de l’exécution et est décrite par le langage de définition du workflow.
Notes
Si vous utilisez un paramètre dans l’en-tête ou le corps de requête, il peut être visible lorsque vous consultez l’historique des exécutions du flux de travail et la requête HTTP sortante. Veillez également à définir vos stratégies d’accès au contenu en conséquence. Vous pouvez également utiliser l’obfuscation pour masquer les entrées et les sorties dans votre historique des exécutions.
Par défaut, les en-têtes Authorization ne sont pas visibles via les entrées ou les sorties.
Si un secret est utilisé ici, il n’est pas récupérable.
Pour en savoir plus, consultez les sections suivantes de la présente rubrique :
- Sécuriser des paramètres dans les définitions de workflow
- Sécuriser les données dans l’historique des exécutions à l’aide d’une obfuscation
Si vous automatisez le déploiement d’applications logiques à l’aide de modèles Azure Resource Manager, vous pouvez définir des paramètres de modèles sécurisés, qui sont évalués au moment du déploiement, à l’aide des types securestring et secureobject. Pour définir des paramètres de modèle, utilisez la section parameters de niveau supérieur de votre modèle, qui est différente de la section parameters de votre définition de workflow. Pour fournir les valeurs des paramètres de modèle, utilisez un autre fichier de paramètres.
Par exemple, si vous utilisez des secrets, vous pouvez définir et utiliser des paramètres de modèles sécurisés qui récupèrent ces secrets à partir d’Azure Key Vault lors du déploiement. Vous pouvez ensuite référencer le coffre de clés et le secret dans votre fichier de paramètres. Pour plus d’informations, consultez les rubriques suivantes :
- Transmettre des valeurs sensibles au déploiement à l’aide d’Azure Key Vault
- Sécuriser des paramètres dans des modèles Azure Resource Manager plus loin dans cette rubrique
Paramètres sécurisés dans les définitions de flux de travail (flux de travail de consommation)
Pour protéger des informations sensibles dans la définition du flux de travail de votre application logique, utilisez des paramètres sécurisés afin que ces informations ne soient pas visibles après l’enregistrement du flux de travail de l’application logique. Par exemple, supposons que vous avez une action HTTP qui nécessite une authentification de base, c’est-à-dire, un nom d’utilisateur et un mot de passe. Dans la définition de workflow, la section parameters définit les paramètres basicAuthPasswordParam et basicAuthUsernameParam à l’aide du type securestring. La définition de l’action référence ensuite ces paramètres dans la section authentication.
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"actions": {
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "https://www.microsoft.com",
"authentication": {
"type": "Basic",
"username": "@parameters('basicAuthUsernameParam')",
"password": "@parameters('basicAuthPasswordParam')"
}
},
"runAfter": {}
}
},
"parameters": {
"basicAuthPasswordParam": {
"type": "securestring"
},
"basicAuthUsernameParam": {
"type": "securestring"
}
},
"triggers": {
"manual": {
"type": "Request",
"kind": "Http",
"inputs": {
"schema": {}
}
}
},
"contentVersion": "1.0.0.0",
"outputs": {}
}
Paramètres sécurisés dans les modèles Azure Resource Manager (flux de consommation)
Un modèle de Resource Manager pour une ressource d’application logique et un flux de travail comporte plusieurs sections parameters. Pour protéger les mots de passe, les clés, les secrets et d’autres informations sensibles, configurez des paramètres sécurisés au niveau du modèle et au niveau de la définition de workflow à l’aide du type securestring ou secureobject. Vous pouvez ensuite stocker ces valeurs dans Azure Key Vault et utiliser le fichier de paramètres pour référencer le coffre de clés et le secret. Votre modèle récupère ensuite ces informations au moment du déploiement. Pour plus d’informations, consultez Transmettre des valeurs sensibles au déploiement à l’aide d’Azure Key Vault.
Cette liste contient des informations supplémentaires sur les sections parameters suivantes :
En haut du modèle, une section
parametersdéfinit les paramètres à l’aide des valeurs utilisées par le modèle au moment du déploiement. Par exemple, ces valeurs peuvent inclure des chaînes de connexion pour un environnement de déploiement spécifique. Vous pouvez ensuite stocker ces valeurs dans un autre fichier de paramètres, ce qui facilite la modification de ces valeurs.Dans la définition de ressource de votre application logique, mais en dehors de la définition de workflow, une section
parametersspécifie les valeurs des paramètres de votre définition de workflow. Dans cette section, vous pouvez affecter ces valeurs à l’aide d’expressions de modèle qui référencent les paramètres de votre modèle. Ces expressions sont évaluées au moment du déploiement.Dans votre définition de votre flux de travail, une section
parametersdéfinit les paramètres que votre flux de travail d’application logique utilise au moment de l’exécution. Vous pouvez ensuite référencer ces paramètres dans le workflow de votre application logique à l’aide d’expressions de définition de workflow, qui sont évaluées au moment de l’exécution.
Cet exemple de modèle avec plusieurs définitions de paramètres sécurisés qui utilisent le type securestring :
| Nom du paramètre | Description |
|---|---|
TemplatePasswordParam |
Paramètre de modèle acceptant un mot de passe qui est ensuite passé au paramètre basicAuthPasswordParam de la définition de workflow. |
TemplateUsernameParam |
Paramètre de modèle acceptant un nom d’utilisateur qui est ensuite passé au paramètre basicAuthUserNameParam de la définition de workflow. |
basicAuthPasswordParam |
Paramètre de définition de workflow qui accepte le mot de passe pour l’authentification de base dans une action HTTP |
basicAuthUserNameParam |
Paramètre de définition de workflow qui accepte le nom d’utilisateur pour l’authentification de base dans une action HTTP |
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"LogicAppName": {
"type": "string",
"minLength": 1,
"maxLength": 80,
"metadata": {
"description": "Name of the Logic App."
}
},
"TemplatePasswordParam": {
"type": "securestring"
},
"TemplateUsernameParam": {
"type": "securestring"
},
"LogicAppLocation": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"allowedValues": [
"[resourceGroup().location]",
"eastasia",
"southeastasia",
"centralus",
"eastus",
"eastus2",
"westus",
"northcentralus",
"southcentralus",
"northeurope",
"westeurope",
"japanwest",
"japaneast",
"brazilsouth",
"australiaeast",
"australiasoutheast",
"southindia",
"centralindia",
"westindia",
"canadacentral",
"canadaeast",
"uksouth",
"ukwest",
"westcentralus",
"westus2"
],
"metadata": {
"description": "Location of the Logic App."
}
}
},
"variables": {},
"resources": [
{
"name": "[parameters('LogicAppName')]",
"type": "Microsoft.Logic/workflows",
"location": "[parameters('LogicAppLocation')]",
"tags": {
"displayName": "LogicApp"
},
"apiVersion": "2016-06-01",
"properties": {
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"actions": {
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "https://www.microsoft.com",
"authentication": {
"type": "Basic",
"username": "@parameters('basicAuthUsernameParam')",
"password": "@parameters('basicAuthPasswordParam')"
}
},
"runAfter": {}
}
},
"parameters": {
"basicAuthPasswordParam": {
"type": "securestring"
},
"basicAuthUsernameParam": {
"type": "securestring"
}
},
"triggers": {
"manual": {
"type": "Request",
"kind": "Http",
"inputs": {
"schema": {}
}
}
},
"contentVersion": "1.0.0.0",
"outputs": {}
},
"parameters": {
"basicAuthPasswordParam": {
"value": "[parameters('TemplatePasswordParam')]"
},
"basicAuthUsernameParam": {
"value": "[parameters('TemplateUsernameParam')]"
}
}
}
}
],
"outputs": {}
}
Types d’authentification pour les connecteurs qui prennent en charge l’authentification
Le tableau suivant identifie les types d’authentification disponibles sur les opérations de connecteur offrant la possibilité de sélectionner un type d’authentification :
| Type d'authentification | Application logique et connecteurs pris en charge |
|---|---|
| De base | Gestion des API Azure, Azure App Service, HTTP, HTTP + Swagger, Webhook HTTP |
| Certificat client | Gestion des API Azure, Azure App Service, HTTP, HTTP + Swagger, Webhook HTTP |
| OAuth Active Directory | - Consommation : Gestion des API Azure, Azure App Services, Azure Functions, HTTP, HTTP + Swagger, Webhook HTTP - Standard : Azure Automation, Stockage Blob Azure, Azure Event Hubs, Files d’attente Azure, Azure Service Bus, Tables Azure, HTTP, Webhook HTTP, SQL Server |
| Brut | Gestion des API Azure, Azure App Service, Azure Functions, HTTP, HTTP + Swagger, Webhook HTTP |
| Identité gérée | Connecteurs intégrés : - Consommation : Gestion des API Azure, Azure App Services, Azure Functions, HTTP, Webhook HTTP - Standard : Azure Automation, Stockage Blob Azure, Azure Event Hubs, Files d’attente Azure, Azure Service Bus, Tables Azure, HTTP, Webhook HTTP, SQL Server Remarque : Actuellement, la plupart des connecteurs intégrés basés sur un fournisseur de service ne prennent pas en charge la sélection d’identités managées affectées par l’utilisateur pour l’authentification. Connecteurs managés : Azure App Service, Azure Automation, Stockage Blob Azure, Azure Container Instances, Azure Cosmos DB, Azure Data Explorer, Azure Data Factory, Azure Data Lake, Azure Event Grid, Azure Event Hubs, Azure IoT Central V2, Azure IoT Central V3, Azure Key Vault, Azure Log Analytics, Files d’attente Azure, Azure Resource Manager, Azure Service Bus, Azure Sentinel, Stockage Table Azure, Machine virtuelle Azure, HTTP avec Microsoft Entra ID, SQL Server |
Accès pour les appels entrants à des déclencheurs basés sur des requêtes
Les appels entrants qu’une application logique reçoit via un déclencheur basé sur des requêtes, tel que le déclencheur de demande ou le déclencheur Webhook HTTP, prennent en charge le chiffrement et sont sécurisés avec au minimum Transport Layer Security (TLS) 1.2, précédemment appelé Secure Sockets Layer (SSL). Azure Logic Apps applique cette version lors de la réception d’un appel entrant au déclencheur de requête ou d’un rappel du déclencheur ou d’une action Webhook HTTP. Si vous constatez des erreurs de liaison TLS, assurez-vous d’utiliser le protocole TLS 1.2. Pour plus d'informations, consultez Résolution du problème lié au protocole TLS 1.0.
Pour les appels entrants, utilisez les suites de chiffrement suivantes :
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Notes
À des fins de compatibilité descendante, Azure Logic Apps prend actuellement en charge certaines suites de chiffrement plus anciennes. Cependant, n’utilisez pas de suites de chiffrement plus anciennes lorsque vous développez de nouvelles applications car ces suitespeuvent ne pas être prises en charge à l’avenir.
Par exemple, vous pouvez trouver les suites de chiffrement suivantes si vous examinez les messages d’établissement d’une liaison TLS lors de l’utilisation du service Azure Logic Apps ou à l’aide d’un outil de sécurité sur l’URL de votre application logique. De nouveau, n’utilisez pas les suites de chiffrement plus anciennes suivantes :
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA256
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
La liste suivante inclut d’autres façons de limiter l’accès aux déclencheurs qui reçoivent des appels entrants à votre application logique afin que seuls des clients autorisés puissent appeler votre application logique :
- Générer des signatures d’accès partagé (SAP)
- Activer OAuth avec Microsoft Entra ID
- Exposer votre application logique avec Gestion des API Azure
- Limiter les adresses IP entrantes
Générer des signatures d’accès partagé (SAP)
Dans une application logique, l’URL de chaque point de terminaison de requête comprend une signature d’accès partagé (SAP). L’URL est au format suivant :
https://<request-endpoint-URI>sp=<permissions>sv=<SAS-version>sig=<signature>
Chaque URL contient le paramètre de requête sp, sv et sig, comme vous pouvez le voir dans le tableau suivant :
| Paramètre de requête. | Description |
|---|---|
sp |
Spécifie des autorisations pour les méthodes HTTP autorisées à utiliser. |
sv |
Spécifie la version SAP à utiliser pour générer la signature. |
sig |
Spécifie la signature à utiliser pour authentifier l’accès au déclencheur. La signature est générée à l’aide de l’algorithme SHA256 avec une clé d’accès secrète pour l’ensemble des chemins et des propriétés de l’URL. Cette clé chiffrée et stockée avec l’application logique n’est jamais exposée ou publiée. Votre application logique autorise uniquement les déclencheurs contenant une signature valide créée avec la clé secrète. |
Les appels entrants à un point de terminaison de requête ne peuvent utiliser qu’un seul schéma d’autorisation : SAS ou OAuth avec Microsoft Entra ID. Bien que l’utilisation d’un schéma ne désactive pas l’autre, l’utilisation des deux schémas en même temps provoque une erreur, car le service ne sait quel schéma choisir.
Pour plus d’informations sur la sécurisation de l’accès avec la signature d’accès partagé, consultez les sections suivantes de cette rubrique :
- Régénération des clés d’accès
- Création d’URL de rappel qui arrivent à expiration
- Création d’URL avec une clé primaire ou une clé secondaire
Régénération de clés d'accès
Pour générer une nouvelle clé d’accès de sécurité à tout moment, utilisez l’API REST Azure ou le portail Azure. Toutes les URL précédemment générées qui utilisent l’ancienne clé sont invalidées et ne sont plus autorisées à déclencher l’application logique. Les URL que vous récupérez après la regénération sont signées avec la nouvelle clé d’accès.
Dans le portail Azure, ouvrez l’application logique possédant la clé que vous souhaitez régénérer.
Dans le menu de la ressource d’application logique, sous Paramètres, sélectionnez Clés d’accès.
Sélectionnez la clé que vous souhaitez regénérer et terminez le processus.
Créer des URL de rappel qui expirent
Si vous décidez de partager l’URL d’un point de terminaison pour un déclencheur basé sur des requêtes, vous pouvez générer des URL de rappel qui utilisent des clés et pour lesquelles des dates d’expiration ont été configurées. De cette façon, vous pouvez facilement restaurer les clés ou restreindre l’accès au déclenchement de votre application logique selon une période donnée. Si vous souhaitez spécifier une date d’expiration pour une URL, utilisez l’API REST Azure Logic Apps, par exemple :
POST /subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.Logic/workflows/<workflow-name>/triggers/<trigger-name>/listCallbackUrl?api-version=2016-06-01
Dans le corps, ajoutez la propriété NotAfter en utilisant une chaîne de date JSON. Cette propriété retourne une URL de rappel qui est valide uniquement jusqu’à la date et l’heure NotAfter.
Créer des URL avec une clé de secret principale ou secondaire
Lorsque vous générez ou listez des URL de rappel pour des déclencheurs basés sur une requête, vous pouvez également spécifier la clé à utiliser pour signer l’URL. Pour générer une URL signée par une clé spécifique, utilisez l’API REST Logic Apps, par exemple :
POST /subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.Logic/workflows/<workflow-name>/triggers/<trigger-name>/listCallbackUrl?api-version=2016-06-01
Dans le corps, incluez la propriété KeyType en tant que Primary ou Secondary. Cette propriété retourne une URL signée par la clé de sécurité spécifiée.
Activer Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth)
Dans un workflow d’application logique de consommation qui démarre avec un déclencheur basé sur une requête, vous pouvez authentifier les appels entrants envoyés au point de terminaison créés par ce déclencheur en activant Microsoft Entra ID OAuth. Pour configurer cette authentification, définissez ou ajoutez une stratégie d’autorisation au niveau de l’application logique. De cette façon, les appels entrants utilisent des jetons d’accès OAuth pour l’autorisation.
Quand votre flux de travail d’application logique reçoit une requête entrante qui inclut un jeton d’accès OAuth, Azure Logic Apps compare les revendications du jeton aux revendications spécifiées par chaque stratégie d’autorisation. S’il existe une correspondance entre les revendications du jeton et toutes celles d’au moins une stratégie, l’autorisation est validée pour la requête entrante. Le jeton peut avoir plus de revendications que le nombre spécifié par la stratégie d’autorisation.
Dans un flux de travail d’application logique standard qui commence par le déclencheur de requête (mais pas un déclencheur Webhook), vous pouvez utiliser la disposition Azure Functions pour authentifier les appels entrants envoyés au point de terminaison créé par ce déclencheur à l’aide d’une identité managée. Cette disposition est également appelée « Authentification facile ». Pour plus d’informations, Consultez Workflows de déclencheur dans les applications logiques standard avec l’authentification facile.
Éléments à prendre en considération avant d’activer Microsoft Entra ID OAuth
Un appel entrant au point de terminaison de requête ne peut utiliser qu’un seul schéma d’autorisation : OAuth avec Microsoft Entra ID ou SAP (Signature d’accès partagé). Bien que l’utilisation d’un schéma ne désactive pas l’autre, l’utilisation des deux schémas en même temps provoque une erreur, car le service Azure Logic Apps ne sait quel schéma choisir.
Azure Logic Apps prend en charge les schémas d’autorisation de type jeton du porteur ou de type preuve de possession (application logique de consommation uniquement) pour les jetons d’accès Microsoft Entra ID OAuth. Cependant, l’en-tête
Authorizationdu jeton d’accès doit spécifier le typeBearerou le typePoP. Pour plus d’informations sur l’obtention et l’utilisation d’un jeton PoP, consultez Obtenir un jeton de preuve de possession (PoP)..Votre ressource d’application logique est limitée à un nombre maximum de stratégies d’autorisation. Chaque stratégie d’autorisation a également un nombre maximal de revendications. Pour plus d’informations, consultez Limites et configuration pour Azure Logic Apps.
Une stratégie d’autorisation doit inclure au moins la revendication Émetteur, dont la valeur commence par
https://sts.windows.net/ouhttps://login.microsoftonline.com/(OAuth v2) en tant qu’ID de l’émetteur Microsoft Entra.Supposons, par exemple, que votre ressource d’application logique dispose d’une stratégie d’autorisation qui nécessite deux types de revendication, Public ciblé et Émetteur. Cet exemple de section de charge utile pour un jeton d’accès décodé comprend les deux types de revendication, où
audest la valeur de Public ciblé etissla valeur d’Émetteur :{ "aud": "https://management.core.windows.net/", "iss": "https://sts.windows.net/<Azure-AD-issuer-ID>/", "iat": 1582056988, "nbf": 1582056988, "exp": 1582060888, "_claim_names": { "groups": "src1" }, "_claim_sources": { "src1": { "endpoint": "https://graph.windows.net/7200000-86f1-41af-91ab-2d7cd011db47/users/00000-f433-403e-b3aa-7d8406464625d7/getMemberObjects" } }, "acr": "1", "aio": "AVQAq/8OAAAA7k1O1C2fRfeG604U9e6EzYcy52wb65Cx2OkaHIqDOkuyyr0IBa/YuaImaydaf/twVaeW/etbzzlKFNI4Q=", "amr": [ "rsa", "mfa" ], "appid": "c44b4083-3bb0-00001-b47d-97400853cbdf3c", "appidacr": "2", "deviceid": "bfk817a1-3d981-4dddf82-8ade-2bddd2f5f8172ab", "family_name": "Sophia Owen", "given_name": "Sophia Owen (Fabrikam)", "ipaddr": "167.220.2.46", "name": "sophiaowen", "oid": "3d5053d9-f433-00000e-b3aa-7d84041625d7", "onprem_sid": "S-1-5-21-2497521184-1604012920-1887927527-21913475", "puid": "1003000000098FE48CE", "scp": "user_impersonation", "sub": "KGlhIodTx3XCVIWjJarRfJbsLX9JcdYYWDPkufGVij7_7k", "tid": "72f988bf-86f1-41af-91ab-2d7cd011db47", "unique_name": "SophiaOwen@fabrikam.com", "upn": "SophiaOwen@fabrikam.com", "uti": "TPJ7nNNMMZkOSx6_uVczUAA", "ver": "1.0" }
Activer Microsoft Entra ID OAuth comme seule option pour appeler un point de terminaison de requête
Configurez votre déclencheur de requête ou de webhook HTTP avec la possibilité de vérifier le jeton d’accès OAuth en suivant les étapes pour inclure l’en-tête « Authorization » dans les sorties du déclencheur de requête ou de webhook HTTP.
Remarque
Cette étape rend l’en-tête
Authorizationvisible dans l’historique des exécutions du workflow et dans les sorties du déclencheur.Sur le portail Azure, ouvrez votre workflow d’application logique dans le concepteur.
Dans le concepteur, sélectionnez le déclencheur. Dans le volet d’information qui s’ouvre, sélectionnez Paramètres.
Sous Général>Conditions du déclencher, sélectionnez Ajouter. Dans la zone des conditions du déclencheur, entrez une des expressions suivantes, en fonction du type de jeton que vous souhaitez utiliser :
@startsWith(triggerOutputs()?['headers']?['Authorization'], 'Bearer')-ou-
@startsWith(triggerOutputs()?['headers']?['Authorization'], 'PoP')
Si vous appelez le point de terminaison du déclencheur sans l’autorisation correcte, l’historique des exécutions affiche simplement le déclencheur comme Skipped sans aucun message indiquant que la condition de déclencheur a échoué.
Obtenir un jeton de preuve de possession (PoP)
Les bibliothèques d’authentification Microsoft (MSAL) fournissent des jetons PoP que vous pouvez utiliser. Si le workflow de l’application logique que vous souhaitez appeler nécessite un jeton PoP, vous pouvez obtenir ce jeton en utilisant les bibliothèques MSAL. Les exemples suivants montrent comment acquérir des jetons PoP :
Une application console de démon .NET Core appelant une API web protégée avec sa propre identité
SignedHttpRequest, également appelé PoP (Preuve de possession)
Pour utiliser le jeton PoP avec votre flux de travail d’application logique Consommation, consultez la section suivante pour configurer OAuth avec Microsoft Entra ID.
Activer Microsoft Entra ID OAuth pour votre ressource d’application logique de consommation
Procédez comme suit selon que vous utilisez le portail Azure ou votre modèle Azure Resource Manager :
Dans le Portail Azure, ajoutez une ou plusieurs stratégies d’autorisation à votre ressource d’application logique Consommation :
Dans le Portail Azure, ouvrez votre application logique Consommation dans le concepteur du flux de travail.
Dans le menu de la ressource d’application logique, sous Paramètres, sélectionnez Autorisation. Une fois le volet Autorisation ouvert, sélectionnez Ajouter une stratégie.
Fournissez des informations sur la stratégie d’autorisation en spécifiant les types de revendication et les valeurs que votre application logique attend dans le jeton d’accès présenté par chaque appel entrant au déclencheur de demande :
Propriété Obligatoire Type Description Nom de la stratégie Oui String Nom que vous voulez utiliser pour la stratégie d’autorisation Type de stratégie Oui Chaîne AAD pour les jetons de type porteur ou AADPOP pour les jetons de type Preuve de possession. Revendications Oui Chaîne Une paire clé-valeur qui spécifie le type de revendication et la valeur que le déclencheur de requête du workflow attend dans le jeton d’accès présenté par chaque appel entrant au déclencheur. Vous pouvez ajouter n’importe quelle revendication standard en sélectionnant Ajouter une revendication standard. Pour ajouter une revendication spécifique à un jeton PoP, sélectionnez Ajouter une revendication personnalisée.
Types de revendications standard disponibles :
- Émetteur
- Audience
- Objet
- ID JWT (identificateur JSON Web Token)
Conditions requises :
– Au minimum, la liste Revendications doit inclure la revendication Émetteur, dont la valeur commence parhttps://sts.windows.net/ouhttps://login.microsoftonline.com/en tant qu’ID d’émetteur Microsoft Entra ID.
- Chaque revendication doit être une valeur de type chaîne unique, et non un tableau de valeurs. Par exemple, vous pouvez avoir une revendication avec Rôle comme type et Développeur comme valeur. Vous ne pouvez pas avoir une revendication qui Rôle comme type et les valeurs définies sur Développeur et Gestionnaire de programmes.
- La valeur de la revendication est limitée à un nombre maximal de caractères.
Pour plus d’informations sur ces types de revendication, consultez Revendications dans les jetons de sécurité Microsoft Entra. Vous pouvez également spécifier vos propres type et valeur de revendication.L’exemple suivant montre les informations relatives à un jeton PoP :
Pour ajouter une autre revendication, sélectionnez l’une des options suivantes :
Pour ajouter un autre type de revendication, sélectionnez Ajouter une revendication standard, sélectionnez le type de revendication, puis spécifiez sa valeur.
Pour ajouter votre propre revendication, sélectionnez Ajouter une revendication personnalisée. Pour plus d'informations, consultez Guide pratique pour fournir des revendications facultatives à votre application. Votre revendication personnalisée est ensuite stockée dans le cadre de votre ID JWT, par exemple
"tid": "72f988bf-86f1-41af-91ab-2d7cd011db47".
Pour ajouter une autre stratégie d’autorisation, sélectionnez Ajouter une stratégie. Répétez les étapes précédentes pour configurer la stratégie.
Quand vous avez terminé, sélectionnez Enregistrer.
Pour inclure l’en-tête
Authorizationdu jeton d’accès dans les sorties du déclencheur basé sur une requête, consultez Inclure l’en-tête « Autorisation » dans les sorties du déclencheur de requête et de webhook HTTP.
Les propriétés de workflow comme les stratégies n’apparaissent pas dans la vue du code de votre workflow dans le portail Azure. Pour accéder à vos stratégies par programmation, appelez l’API suivante via Azure Resource Manager : https://management.azure.com/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group-name}/providers/Microsoft.Logic/workflows/{your-workflow-name}?api-version=2016-10-01&_=1612212851820. Veillez à remplacer les valeurs d’espace réservé par votre ID d’abonnement Azure, le nom du groupe de ressources et le nom du workflow.
Inclure l’en-tête « Autorisation » dans les sorties du déclencheur de requête ou de webhook HTTP
Pour les applications logiques qui activent OAuth avec Microsoft Entra ID pour autoriser les appels entrants à accéder aux déclencheurs basés sur des requêtes, vous pouvez autoriser les sorties du déclencheur de requête ou du déclencheur de webhook HTTP à inclure l’en-tête Authorization provenant du jeton d’accès OAuth. Dans la définition JSON sous-jacente du déclencheur, ajoutez et définissez la propriété operationOptions sur IncludeAuthorizationHeadersInOutputs. Voici un exemple de déclencheur de demande :
"triggers": {
"manual": {
"inputs": {
"schema": {}
},
"kind": "Http",
"type": "Request",
"operationOptions": "IncludeAuthorizationHeadersInOutputs"
}
}
Pour plus d’informations, consultez les rubriques suivantes :
- Informations de référence sur le schéma des types d’actions et de déclencheurs - Déclencheur de demande
- Informations de référence sur le schéma des types d’actions et de déclencheurs - Déclencheur de Webhook HTTP
- Informations de référence sur le schéma des types d’actions et de déclencheurs - Options d’opérations
Exposer votre flux de travail d’application logique avec Gestion des API Azure
Pour plus de protocoles d’authentification et d’options, envisagez d’exposer le flux de travail de votre application logique en tant qu’API à l’aide d’Azure API Management. Ce service fournit des fonctionnalités de surveillance, de sécurité, de stratégie et de documentation enrichies pour n’importe quel point de terminaison. Le service Gestion des API peut exposer un point de terminaison public ou privé pour votre application logique. Pour autoriser l’accès à ce point de terminaison, vous pouvez utiliser OAuth avec Microsoft Entra ID, un certificat client ou d’autres normes de sécurité. Lorsque Gestion des API reçoit une requête, le service envoie celle-ci à votre application logique, en effectuant également toutes les transformations ou restrictions nécessaires tout au long du processus. Pour permettre à l’API Management d’appeler le flux de travail de votre application logique, vous pouvez restreindre les adresses IP entrantes de votre application logique.
Pour plus d’informations, consultez la documentation suivante :
- En savoir plus sur la Gestion des API
- Protéger un back-end d’API web dans Gestion des API Azure en utilisant l’autorisation OAuth 2.0 avec Microsoft Entra ID
- Sécuriser les API à l’aide d’une authentification par certificat client dans Gestion des API
- Stratégies d’authentification dans Gestion des API
Limiter les adresses IP entrantes
En plus de la signature d’accès partagé (SAP), vous pouvez aussi restreindre spécifiquement les clients qui peuvent appeler le flux de travail de votre application logique. Par exemple, si vous gérez votre point de terminaison de requête avec Azure API Management, vous pouvez restreindre le flux de travail de votre application logique afin qu’il n'accepte que les requêtes qui proviennent de l’adresse IP de l’instance de service API Management que vous créez.
Quelles que soient les adresses IP que vous spécifiez, vous pouvez toujours exécuter un flux de travail d’application logique comportant un déclencheur basé sur une requête en utilisant la requête API REST Logic Apps : Déclencheurs de flux de travail – Exécuter ou en utilisant API Management. Cependant, ce scénario nécessite encore une authentification auprès de l’API REST Azure. Tous les événements s’affichent dans le journal d’audit Azure. Veillez à définir les stratégies de contrôle d’accès en conséquence.
Pour restreindre les adresses IP entrantes pour le flux de travail de votre application logique, suivez les étapes correspondantes pour le portail Azure ou votre modèle Azure Resource Manager. Une plage d’adresses IP valide utilise ces formats : x.x.x.x/x ou x.x.x.x-x.x.x.x
Dans le portail Azure, la restriction des adresses IP affecte à la fois les déclencheurs et les actions, contrairement à la description figurant dans le portail sous Adresses IP entrantes autorisées. Pour configurer ce filtre séparément pour les déclencheurs et pour les actions, utilisez l’objet accessControl dans un modèle Azure Resource Manager pour votre ressource d’application logique ou l’API REST Azure Logic Apps : Flux de travail - Opération de création ou de mise à jour.
Workflows Consommation
Dans le Portail Azure, ouvrez votre application logique Consommation dans le concepteur du flux de travail.
Dans le menu de l’application logique, sous Paramètres, sélectionnez Paramètres de flux de travail.
Dans la section Configuration du contrôle d’accès, sous Adresses IP entrantes autorisées, choisissez le chemin de votre scénario :
Pour que votre flux de travail puisse être appelé à l’aide de l'action intégrée Azure Logic Apps, mais uniquement en tant que flux de travail imbriqué, sélectionnez Uniquement les autres applications logiques. Cette option fonctionne uniquement lorsque vous utilisez l’action Azure Logic Apps pour appeler le flux de travail imbriqué.
Cette option écrit un tableau vide dans votre ressource d’application logique et exige que seuls les appels des flux de travail parents qui utilisent l’action Azure Logic Apps intégrée puissent déclencher le flux de travail imbriqué.
Pour rendre votre flux de travail appelable à l’aide de l’action HTTP, mais uniquement en tant que flux de travail imbriqué, sélectionnez Plages d’adresses IP spécifiques. Quand la fenêtre Plages d’adresses IP pour les déclencheurs s’affiche, entrez les adresses IP sortantes du flux de travail parent. Une plage d’adresses IP valide utilise ces formats : x.x.x.x/x ou x.x.x.x-x.x.x.x
Notes
Si vous utilisez l’option Uniquement les autres Logic Apps et l’action HTTP pour appeler votre flux de travail imbriqué, l’appel est bloqué et vous recevez une erreur « 401 Non autorisé ».
Pour les scénarios où vous voulez limiter les appels entrants à partir d’autres adresses IP, quand la fenêtre Plages d’adresses IP pour les déclencheurs s’affiche, spécifiez les plages d’adresses IP acceptées par le déclencheur. Une plage d’adresses IP valide utilise ces formats : x.x.x.x/x ou x.x.x.x-x.x.x.x
Éventuellement, sous Limitez les appels visant à obtenir des messages d’entrée et de sortie à partir de l’historique d’exécution aux plages d’adresses IP fournies, vous pouvez spécifier les plages d’adresses IP pour les appels entrants qui peuvent accéder aux messages d’entrée et de sortie dans l’historique des exécutions.
Workflows Standard
Dans le portail Azure, ouvrez votre ressource d’application logique.
Dans le menu de l’application logique, sous Paramètres, sélectionnez Mise en réseau.
Dans la section Trafic entrant, sélectionnez Restriction d’accès.
Créez une ou plusieurs règles pour Autoriser ou Refuser les requêtes provenant de plages d’adresses IP spécifiques. Vous pouvez également utiliser les paramètres de filtre d’en-tête HTTP et les paramètres de transfert. Une plage d’adresses IP valide utilise ces formats : x.x.x.x/x ou x.x.x.x-x.x.x.x
Pour plus d’informations, consultez Blocage des adresses IP entrantes dans Azure Logic Apps (Standard).
Accès pour les appels sortants à d’autres services et systèmes
En fonction de la capacité du point de terminaison cible, les appels sortants envoyés par le déclencheur ou l’action HTTP prennent en charge le chiffrement et sont sécurisés avec le protocole TLS (Transport Layer Security) 1.0, 1.1 ou 1.2, anciennement appelé Secure Sockets Layer (SSL). Azure Logic Apps négocie avec le point de terminaison cible en utilisant la version la plus élevée possible prise en charge. Par exemple, si le point de terminaison cible prend en charge la version 1.2, le déclencheur ou l’action HTTP utilisent d’abord la version 1.2. Sinon, le connecteur utilise la version prise en charge juste inférieure.
La liste inclut des informations sur les certificats auto-signés TLS/SSL :
Pour les workflows d’application logique de consommation dans l’environnement Azure Logic Apps multilocataire, les opérations HTTP n’autorisent pas les certificats TLS/SSL auto-signés. Si votre application logique émet un appel HTTP vers un serveur et présente un certificat auto-signé TLS/SSL, l’appel HTTP échouera avec une erreur
TrustFailure.Pour les flux de travail des applications logiques standard dans l’environnement Azure Logic Apps à locataire unique, les opérations HTTP prennent en charge les certificats TLS/SSL auto-signés. Toutefois, vous devez effectuer quelques étapes supplémentaires pour ce type d’authentification. Dans le cas contraire, l’appel échoue. Pour plus d’informations, consultez Authentification par certificat TLS/SSL pour Azure Logic Apps à un seul locataire.
Si vous souhaitez utiliser le certificat client ou OAuth avec Microsoft Entra ID avec le type d’informations d’identification Certificat à la place, vous devez effectuer quelques étapes supplémentaires pour ce type d’authentification. Dans le cas contraire, l’appel échoue. Pour plus d’informations, consultez Certificat client ou OAuth avec Microsoft Entra ID avec le type d’informations d’identification « Certificat » pour Azure Logic Apps à locataire unique.
Voici d’autres façons de sécuriser les points de terminaison qui gèrent les appels envoyés à partir des flux de travail de votre application logique :
Ajoutez l’authentification aux requêtes sortantes.
Lorsque vous utilisez le déclencheur ou l’action HTTP pour envoyer des appels sortants, vous pouvez ajouter l’authentification à la demande envoyée par votre application logique. Par exemple, vous pouvez sélectionner les types d’authentification suivants :
Restreignez l’accès des adresses IP du flux de travail de l’application logique.
Tous les appels vers des points d’extrémité provenant de flux de travail d’applications logiques proviennent d’adresses IP spécifiques désignées, en fonction des régions de vos applications logiques. Vous pouvez ajouter le filtrage afin d’accepter les requêtes provenant uniquement de ces adresses IP. Pour obtenir ces adresses IP, consultez Limites et configuration d’Azure Logic Apps.
Améliorez la sécurité des connexions aux systèmes locaux.
Azure Logic Apps permet l’intégration avec ces services pour fournir une communication locale plus sécurisée et plus fiable.
Passerelle de données locale
De nombreux connecteurs managés dans Azure Logic Apps facilitent les connexions sécurisées aux systèmes locaux, par exemple File System, SQL, SharePoint et DB2. La passerelle envoie les données des sources locales sur des canaux chiffrés via Azure Service Bus. L’ensemble du trafic est généré sous forme de trafic sortant sécurisé en provenance de l’agent de passerelle. Découvrez comment la passerelle de données sur site fonctionne.
Connectez-vous via la Gestion des API Azure.
La Gestion des API Azure fournit des options de connexion locale, par exemple, un réseau privé virtuel de site à site et une intégration ExpressRoute pour un proxy et une communication sécurisés vers les systèmes locaux. Si vous disposez d’une API qui permet d’accéder à votre système local et que vous l’avez exposée en créant une instance de service Gestion des API, vous pouvez appeler cette API à partir du flux de travail de votre application logique en sélectionnant l’opération Gestion des API correspondante dans le concepteur de flux de travail.
Remarque
Le connecteur affiche uniquement les services Gestion des API pour lesquels vous disposez d’autorisations d’affichage et de connexion, et non les services Gestion des API basés sur la consommation.
En fonction du type de ressource de votre application logique, suivez les étapes correspondantes :
Workflows Consommation
En fonction de l’ajout d’un déclencheur ou d’une action Gestion des API, procédez comme suit :
Déclencheur :
Dans le concepteur de flux de travail, sélectionnez Ajouter un déclencheur.
Une fois le volet Ajouter un déclencheur ouvert, entrez Gestion des API dans la zone de recherche.
Dans la liste des résultats du déclencheur, sélectionnez Choisir un déclencheur Gestion des API Azure.
Action :
Dans le concepteur de flux de travail, sélectionnez le signe plus (+) où vous souhaitez ajouter l’action.
Une fois le volet Ajouter une action ouvert, entrez Gestion des API dans la zone de recherche.
Dans la liste des résultats de l’action, sélectionnez Choisir une action Gestion des API Azure.
L’exemple suivant montre la recherche d’un déclencheur Gestion des API Azure :
Dans la liste de l’instance de service Gestion des API, sélectionnez votre instance de service Gestion des API créée précédemment.
Dans la liste des opérations d’API, sélectionnez l’opération d’API à appeler, puis sélectionnez Ajouter une action.
Workflows Standard
Pour les flux de travail Standard, vous ne pouvez ajouter que des actions Gestion des API, et non des déclencheurs.
Dans le concepteur de flux de travail, sélectionnez le signe plus (+) où vous souhaitez ajouter l’action.
Une fois le volet Ajouter une action ouvert, entrez Gestion des API dans la zone de recherche.
Dans la liste des résultats de l’action, sélectionnez Appeler une API Gestion des API Azure.
Dans la liste de l’instance de service Gestion des API, sélectionnez votre instance de service Gestion des API créée précédemment.
Dans la liste des opérations d’API, sélectionnez l’opération d’API à appeler, puis sélectionnez Créer.
Ajouter l’authentification aux appels sortants
Les points de terminaison HTTP et HTTPS prennent en charge différents types d’authentification. Il est possible, sur certains déclencheurs et actions permettant d’envoyer des appels sortants ou des demandes à ces points de terminaison, de spécifier un type d’authentification. Dans le concepteur de flux de travail, les déclencheurs et les actions qui prennent en charge le choix du type d’authentification disposent d’une propriété Authentification. Toutefois, celle-ci n’apparaît pas toujours par défaut. Dans ce cas, ouvrez la liste Ajouter un nouveau paramètre dans le déclencheur ou l’action, puis sélectionnez Authentification.
Important
Pour protéger les informations sensibles gérées par votre application logique, utilisez des paramètres sécurisés et encodez les données si nécessaire. Pour plus d’informations sur l’utilisation et la sécurisation des paramètres, consultez Accès aux entrées de paramètres.
Authentification de base
Si l’option De base est disponible, spécifiez les valeurs de propriété suivantes :
| Propriété (concepteur) | Propriété (JSON) | Obligatoire | Value | Description |
|---|---|---|---|---|
| Authentification | type |
Oui | De base | Type d’authentification à utiliser |
| Nom d’utilisateur | username |
Oui | <user-name> | Nom d’utilisateur permettant d’authentifier l’accès au point de terminaison de service cible |
| Mot de passe | password |
Oui | <password> | Mot de passe permettant d’authentifier l’accès au point de terminaison de service cible |
Lorsque vous utilisez des paramètres sécurisés pour traiter et sécuriser des informations sensibles, par exemple dans un modèle Azure Resource Manager pour l’automatisation du déploiement, vous pouvez utiliser des expressions pour accéder à ces valeurs de paramètre au moment de l’exécution. Cet exemple de définition d’action HTTP spécifie l’authentification type en tant que Basic et utilise la fonction parameters() pour récupérer les valeurs des paramètres :
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "@parameters('endpointUrlParam')",
"authentication": {
"type": "Basic",
"username": "@parameters('userNameParam')",
"password": "@parameters('passwordParam')"
}
},
"runAfter": {}
}
Authentification par certificat client
Si l’option Certificat client est disponible, spécifiez ces valeurs de propriété :
| Propriété (concepteur) | Propriété (JSON) | Obligatoire | Value | Description |
|---|---|---|---|---|
| Authentification | type |
Oui | Certificat client ou ClientCertificate |
Type d’authentification à utiliser. Vous pouvez gérer les certificats avec la Gestion des API Azure. Remarque : Les connecteurs personnalisés ne prennent pas en charge l’authentification par certificat pour les appels entrants ni sortants. |
| Pfx | pfx |
Oui | <encoded-pfx-file-content> | Contenu encodé en base64 à partir d’un fichier Personal Information Exchange (PFX) Pour convertir le fichier PFX au format encodé en base64, vous pouvez utiliser PowerShell 7 en procédant comme suit : 1. Enregistrez le contenu du certificat dans une variable : $pfx_cert = [System.IO.File]::ReadAllBytes('c:\certificate.pfx') 2. Convertissez le contenu du certificat à l’aide de la fonction ToBase64String() et enregistrez ce contenu dans un fichier texte : [System.Convert]::ToBase64String($pfx_cert) | Out-File 'pfx-encoded-bytes.txt' Résolution des problèmes : si vous utilisez la commande, il se peut que vous rencontriez cette erreur : Could not load the certificate private key. Please check the authentication certificate password is correct and try again. Pour résoudre cette erreur, essayez de convertir le fichier PFX en fichier PEM, puis de nouveau en fichier PFX à l’aide de la commande openssl : openssl pkcs12 -in certificate.pfx -out certificate.pem openssl pkcs12 -in certificate.pem -export -out certificate2.pfx Ensuite, lorsque vous recevez la chaîne encodée en base64 pour le fichier PFX nouvellement converti du certificat, la chaîne fonctionne dans Azure Logic Apps. |
| Mot de passe | password |
Non | <password-for-pfx-file> | Mot de passe pour accéder au fichier PFX |
Remarque
Si vous essayez de vous authentifier avec un certificat client en utilisant OpenSSL, vous pouvez recevoir l’erreur suivante :
BadRequest: Could not load private key
Pour résoudre cette erreur, procédez comme suit :
- Désinstallez toutes les instances OpenSSL.
- Installez OpenSSL version 1.1.1t.
- Resignez votre certificat en utilisant la nouvelle mise à jour.
- Ajoutez le nouveau certificat à l’opération HTTP lors de l’utilisation de l’authentification par certificat client.
Lorsque vous utilisez des paramètres sécurisés pour traiter et sécuriser des informations sensibles, par exemple dans un modèle Azure Resource Manager pour l’automatisation du déploiement, vous pouvez utiliser des expressions pour accéder à ces valeurs de paramètre au moment de l’exécution. Cet exemple de définition d’action HTTP spécifie l’authentification type en tant que ClientCertificate et utilise la fonction parameters() pour récupérer les valeurs des paramètres :
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "@parameters('endpointUrlParam')",
"authentication": {
"type": "ClientCertificate",
"pfx": "@parameters('pfxParam')",
"password": "@parameters('passwordParam')"
}
},
"runAfter": {}
}
Important
Si vous avez une ressource d’application logique standard dans une instance Azure Logic Apps à un seul locataire et que vous souhaitez utiliser une opération HTTP avec un certificat TSL/SSL, un certificat client ou Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) avec le type d’informations d’identification Certificate, veillez à effectuer les étapes de configuration supplémentaires pour ce type d’authentification. Dans le cas contraire, l’appel échoue. Pour plus d’informations, consultez Authentification dans un environnement à locataire unique.
Pour plus d’informations sur la sécurisation des services à l’aide de l’authentification par certificat client, consultez les rubriques suivantes :
- Améliorer la sécurité des API à l’aide de l’authentification par certificat client dans Gestion des API Azure
- Améliorer la sécurité des services back-end à l’aide de l’authentification par certificat client dans Gestion des API Azure
- Améliorer la sécurité de votre service RESTful à l’aide de certificats clients
- Informations d’identification de certificat pour l’authentification d’application
- Utiliser un certificat TLS/SSL dans votre code dans Azure App Service
Plateforme d’identité Microsoft
Sur les déclencheurs de requête, vous pouvez utiliser Plateforme d’identités Microsoft pour authentifier les appels entrants après avoir configuré des stratégies d’autorisation Microsoft Entra ID pour votre application logique. Pour tous les autres déclencheurs et actions qui proposent la sélection du type d’authentification Active Directory OAuth, spécifiez ces valeurs de propriété :
| Propriété (concepteur) | Propriété (JSON) | Obligatoire | Value | Description |
|---|---|---|---|---|
| Authentification | type |
Oui | OAuth Active Directory ou ActiveDirectoryOAuth |
Type d’authentification à utiliser. Azure Logic Apps suit actuellement le protocole OAuth 2.0. |
| Authority | authority |
Non | <URL de l’autorité émettrice du jeton> | URL de l’autorité qui fournit le jeton d’accès, par exemple https://login.microsoftonline.com/ pour les régions du service global Azure. Pour les autres clouds nationaux, passez en revue Points de terminaison d’authentification Microsoft Entra – Choix de votre autorité d’identité. |
| Locataire | tenant |
Oui | <ID de locataire> | L’ID de locataire pour le locataire Microsoft Entra |
| Public ciblé | audience |
Oui | <ressource à autoriser> | Ressource à utiliser pour l’autorisation, par exemple, https://management.core.windows.net/ |
| ID client | clientId |
Oui | <ID client> | ID client pour l’application demandant l’autorisation |
| Type d’informations d’identification | credentialType |
Oui | Certificat ou Secret |
Type d’informations d’identification que le client utilise pour la demande d’autorisation. Ces propriété et valeur n’apparaissent pas dans la définition sous-jacente de votre application logique, mais elles déterminent les propriétés affichées pour le type d’informations d’identification sélectionné. |
| Secret | secret |
Oui, uniquement pour le type d’informations d’identification « Secret » | <client-secret> | Clé secrète client permettant de demander une autorisation |
| Pfx | pfx |
Oui, mais uniquement pour le type d’informations d’identification « Certificat » | <encoded-pfx-file-content> | Contenu encodé en base64 à partir d’un fichier Personal Information Exchange (PFX) |
| Mot de passe | password |
Oui, mais uniquement pour le type d’informations d’identification « Certificat » | <password-for-pfx-file> | Mot de passe pour accéder au fichier PFX |
Lorsque vous utilisez des paramètres sécurisés pour traiter et sécuriser des informations sensibles, par exemple dans un modèle Azure Resource Manager pour l’automatisation du déploiement, vous pouvez utiliser des expressions pour accéder à ces valeurs de paramètre au moment de l’exécution. Cet exemple de définition d’action HTTP spécifie l’authentification type en tant que ActiveDirectoryOAuth, le type d’informations d’identification en tant que Secret et utilise la fonction Parameters() pour récupérer les valeurs des paramètres :
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "@parameters('endpointUrlParam')",
"authentication": {
"type": "ActiveDirectoryOAuth",
"tenant": "@parameters('tenantIdParam')",
"audience": "https://management.core.windows.net/",
"clientId": "@parameters('clientIdParam')",
"credentialType": "Secret",
"secret": "@parameters('secretParam')"
}
},
"runAfter": {}
}
Important
Si vous avez une ressource d’application logique standard dans une instance Azure Logic Apps à un seul locataire et que vous souhaitez utiliser une opération HTTP avec un certificat TSL/SSL, un certificat client ou Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) avec le type d’informations d’identification Certificate, veillez à effectuer les étapes de configuration supplémentaires pour ce type d’authentification. Dans le cas contraire, l’appel échoue. Pour plus d’informations, consultez Authentification dans un environnement à locataire unique.
Authentification brute
Si l’option Brut est disponible, vous pouvez utiliser ce type d’authentification lorsque vous devez utiliser des schémas d’authentification qui ne suivent pas le protocole OAuth 2.0. Avec ce type, vous créez manuellement la valeur d’en-tête d’autorisation que vous envoyez avec la demande sortante, puis vous spécifiez cette valeur d’en-tête dans votre déclencheur ou action.
Voici un exemple d’en-tête pour une requête HTTPS qui suit le protocole OAuth 1.0 :
Authorization: OAuth realm="Photos",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131200",
oauth_nonce="wIjqoS",
oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"
Dans le déclencheur ou l’action qui prend en charge l’authentification brute, spécifiez les valeurs de propriétés suivantes :
| Propriété (concepteur) | Propriété (JSON) | Obligatoire | Value | Description |
|---|---|---|---|---|
| Authentification | type |
Oui | Brut | Type d’authentification à utiliser |
| Valeur | value |
Oui | <authorization-header-value> | Valeur d’en-tête d’autorisation à utiliser pour l’authentification |
Lorsque vous utilisez des paramètres sécurisés pour traiter et sécuriser des informations sensibles, par exemple dans un modèle Azure Resource Manager pour l’automatisation du déploiement, vous pouvez utiliser des expressions pour accéder à ces valeurs de paramètre au moment de l’exécution. Cet exemple de définition d’action HTTP spécifie l’authentification type en tant que Raw et utilise la fonction parameters() pour récupérer les valeurs des paramètres :
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "@parameters('endpointUrlParam')",
"authentication": {
"type": "Raw",
"value": "@parameters('authHeaderParam')"
}
},
"runAfter": {}
}
Authentification d’une identité managée
Quand l’option Identité managée est disponible sur le déclencheur ou l’action qui prend en charge l’authentification avec une identité managée, votre application logique peut utiliser cette identité pour authentifier l’accès à des ressources Azure protégées par Microsoft Entra ID, plutôt que par des informations d’identification, des secrets ou des jetons Microsoft Entra. Azure gère cette identité pour vous et vous aide à sécuriser vos informations d’identification, car vous n’avez pas besoin de gérer des secrets ou d’utiliser directement des jetons Microsoft Entra. En savoir plus sur les services Azure qui prennent en charge les identités managées pour l’authentification Microsoft Entra.
Une ressource d’application logique de consommation peut utiliser l’identité affectée par le système ou une identité unique affectée par l’utilisateur créée manuellement.
Une ressource d’application logique standard prend en charge l’activation simultanée de l’identité managée affectée par le système et de plusieurs identités managées affectées par l’utilisateur, même si vous ne pouvez sélectionner qu’une seule identité à utiliser à un moment donné.
Remarque
Par défaut, l’identité affectée par le système est déjà activée pour authentifier les connexions au moment de l’exécution. Cette identité diffère des informations d’identification d’authentification ou de la chaîne de connexion que vous utilisez lors de la création d’une connexion. Si vous désactivez cette identité, les connexions ne fonctionneront pas au moment de l’exécution. Pour afficher ce paramètre, dans le menu de votre application logique, sous Paramètres, sélectionnez Identité.
Pour que votre application logique puisse utiliser une identité managée, suivez les étapes décrites dans Authentifier l’accès aux ressources Azure à l’aide des identités managées dans Azure Logic Apps. Ces étapes activent l’identité managée sur votre application logique et configurent l’accès de cette identité à la ressource Azure cible.
Pour qu’une fonction Azure puisse utiliser une identité managée, vous devez d’abord activer l’authentification des fonctions Azure.
Dans le déclencheur ou l’action qui prend en charge l’utilisation d’une identité gérée, fournissez les informations suivantes :
Déclencheurs et actions intégrés
Propriété (concepteur) Propriété (JSON) Obligatoire Value Description Authentification typeOui Identité gérée
ouManagedServiceIdentityType d’authentification à utiliser Identité gérée identityNon <user-assigned-identity-ID> L’identité managée affectée par l’utilisateur à utiliser. Remarque: n’incluez pas cette propriété lors de l’utilisation de l’identité managée affectée par le système. Public ciblé audienceOui <target-resource-ID> ID de la ressource cible à laquelle vous souhaitez accéder.
Par exemple,https://storage.azure.com/rend les jetons d’accès pour l’authentification valides pour tous les comptes de stockage. Toutefois, vous pouvez également spécifier une URL de service racine, par exemplehttps://fabrikamstorageaccount.blob.core.windows.netpour un compte de stockage spécifique.
Remarque : La propriété Audience peut être masquée dans certains déclencheurs ou certaines actions. Pour que la propriété apparaisse, dans le déclencheur ou l’action, ouvrez la liste Ajouter un nouveau paramètre, puis sélectionnez Audience.
Important : Vérifiez que l’ID de cette ressource cible correspond exactement à la valeur attendue par Microsoft Entra ID, y compris les barres obliques de fin nécessaires. Ainsi, l’ID de ressourcehttps://storage.azure.com/pour tous les comptes Stockage blob Azure requiert une barre oblique finale. Toutefois, l’ID de ressource pour un compte de stockage spécifique ne requiert pas de barre oblique finale. Pour trouver ces ID de ressource, consultez les services Azure qui prennent en charge Microsoft Entra ID.Lorsque vous utilisez des paramètres sécurisés pour traiter et sécuriser des informations sensibles, par exemple dans un modèle Azure Resource Manager pour l’automatisation du déploiement, vous pouvez utiliser des expressions pour accéder à ces valeurs de paramètre au moment de l’exécution. Par exemple, cette définition d’action HTTP spécifie l’authentification
typeen tant queManagedServiceIdentityet utilise la fonction parameters() pour récupérer les valeurs des paramètres :"HTTP": { "type": "Http", "inputs": { "method": "GET", "uri": "@parameters('endpointUrlParam')", "authentication": { "type": "ManagedServiceIdentity", "audience": "https://management.azure.com/" }, }, "runAfter": {} }Déclencheurs et actions de connecteur managé
Propriété (concepteur) Obligatoire Value Description Nom de connexion Oui <connection-name> Identité gérée Oui Identité managée affectée par le système
ou
<user-assigned-managed-identity-name>Type d’authentification à utiliser
Blocage de la création de connexions
Si votre organisation n’autorise pas la connexion à des ressources spécifiques à l’aide de leurs connecteurs dans Azure Logic Apps, vous pouvez bloquer la possibilité de créer ces connexions pour certains connecteurs dans les flux de travail d’application logique avec Azure Policy. Pour plus d’informations, consultez Blocage des connexions créées par des connecteurs spécifiques dans Azure Logic Apps.
Conseils d’isolation pour les applications logiques
Vous pouvez utiliser Azure Logic Apps dans Azure Government, qui prend en charge tous les niveaux d’impact dans les régions décrites par les Conseils d’isolation pour le niveau d’impact 5 Azure Government. Pour répondre à ces exigences, Azure Logic Apps gère la possibilité de créer et d’exécuter des flux de travail dans un environnement comportant des ressources dédiées, ce qui vous permet de réduire l’impact sur les performances d’autres locataires Azure sur vos applications logiques et d’éviter de partager des ressources de calcul avec d’autres locataires.
Pour exécuter votre propre code ou effectuer une transformation XML, créez et appelez une fonction Azure, au lieu respectivement d’utiliser la fonctionnalité de code inline ou de fournir des assemblys à utiliser comme mappages. En outre, configurez l’environnement d’hébergement de votre application de fonction de façon à respecter vos exigences d’isolation.
Par exemple, pour répondre aux exigences du niveau d’impact 5, créez votre application de fonction avec le plan App Service suivant le niveau tarifaire isolé, ainsi qu’un environnement ASE (App Service Environment) qui utilise également le niveau tarifaire Isolé. Dans cet environnement, les applications de fonction s’exécutent sur des machines virtuelles et des réseaux virtuels Azure dédiés, ce qui assure à vos applications l’isolement réseau en plus de l’isolation du calcul, ainsi que des capacités de Scale-out maximales.
Pour plus d’informations, consultez la documentation suivante :
Selon que vous disposez de workflows d’application logique Consommation ou Standard, vos options sont les suivantes :
Les workflows d’application logique Standard peuvent communiquer en privé et en toute sécurité avec un réseau virtuel Azure par le biais de points de terminaison privés configurés pour le trafic entrant et de l’intégration de réseau virtuel pour le trafic sortant. Pour plus d’informations, consultez Sécuriser le trafic entre réseaux virtuels et monolocataires dans Azure Logic Apps à l’aide de points de terminaison privés.
Les workflows d’application logique Consommation peuvent s’exécuter dans un environnement de service d’intégration (ISE) où ils peuvent utiliser des ressources dédiées et accéder à des ressources protégées par un réseau virtuel Azure. Toutefois, la ressource ISE sera mise hors service le 31 août 2024, en raison de sa dépendance vis-à-vis d’Azure Cloud Services (Classic), qui sera mis hors service au même moment.
Important
Certains réseaux virtuels Azure utilisent des points de terminaison privés (Azure Private Link) pour fournir un accès aux services PaaS Azure, tels que Stockage Azure, Azure Cosmos DB ou Azure SQL Database, aux services partenaires ou aux services clients hébergés sur Azure.
Pour créer des flux de travail d’application logique Consommation qui ont besoin d’accéder à des réseaux virtuels avec des points de terminaison privés, vous devez créer et exécuter vos flux de travail Consommation dans un environnement ISE. Vous pouvez également créer des workflows Standard à la place, qui n’ont pas besoin d’un environnement ISE. Au lieu de cela, vos workflows peuvent communiquer en privé et en toute sécurité avec des réseaux virtuels à l’aide de points de terminaison privés pour le trafic entrant et l’intégration du réseau virtuel pour le trafic sortant. Pour plus d’informations, consultez l’article Sécuriser le trafic entre les applications logiques Standard et les réseaux virtuels Azure à l’aide de points de terminaison privés.
Pour plus d’informations sur l’isolation, consultez la documentation suivante :