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 pour votre application logique Consommation ou Standard dans le portail Azure ou votre modèle Azure Resource Manager :
Workflows Consommation
Sur le portail Azure, ouvrez votre workflow d’application logique dans le concepteur.
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, dans la liste Option d’accès au déclencheur, sélectionnez Plages d’adresses IP spécifiques.
Dans la zone 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 Standard.
Dans le menu de l’application logique, sous Paramètres, sélectionnez Mise en réseau.
Dans la section Configuration du trafic entrant, à côté d’Accès au réseau public, sélectionnez Activé sans restriction d’accès.
Dans la page Restrictions d’accès, sous Accès à l’application, sélectionnez Activé à partir de la sélection des réseaux virtuels et des adresses IP.
Sous Accès au site et règles, sous l’onglet Site principal, ajoutez une ou plusieurs règles aux requêtes Autoriser ou Refuser à partir 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).
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 suivantes ne 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 entrées, Azure Logic Apps masque les entrées de cette action en aval dans l’historique des exécutions, mais 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
.
Important
Pour une sécurité optimale, Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour l’authentification dans la mesure du possible. Cette option offre une sécurité supérieure sans avoir à fournir d’informations d’identification. Azure gère cette identité et sécurise les informations d’authentification. Ainsi, vous n’avez pas à gérer ces informations sensibles. Pour configurer une identité managée pour Azure Logic Apps, consultez Authentifier l’accès et les connexions aux ressources Azure avec des identités managées dans Azure Logic Apps.
"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.
Important
Pour une sécurité optimale, Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour l’authentification dans la mesure du possible. Cette option offre une sécurité supérieure sans avoir à fournir d’informations d’identification. Azure gère cette identité et sécurise les informations d’authentification. Ainsi, vous n’avez pas à gérer ces informations sensibles. Pour configurer une identité managée pour Azure Logic Apps, consultez Authentifier l’accès et les connexions aux ressources Azure avec des identités managées dans Azure Logic Apps.
Cette liste contient des informations supplémentaires sur les sections parameters
suivantes :
En haut du modèle, une section
parameters
dé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
parameters
spé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
parameters
dé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 |
Active Directory OAuth (OAuth 2.0 avec Microsoft Entra ID) | - Consommation : Gestion des API Azure, Azure App Service, 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 Service, 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 |
Important
Pour une sécurité optimale, Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour l’authentification dans la mesure du possible. Cette option offre une sécurité supérieure sans avoir à fournir d’informations d’identification. Azure gère cette identité et sécurise les informations d’authentification. Ainsi, vous n’avez pas à gérer ces informations sensibles. Pour configurer une identité managée pour Azure Logic Apps, consultez Authentifier l’accès et les connexions aux ressources Azure avec des identités managées dans Azure Logic Apps.
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 Requête ou le déclencheur Webhook HTTP, prennent en charge le chiffrement et sont sécurisés avec le protocole Transport Layer Security (TLS) 1.2 minimum, 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 Requête ou d’un rappel du déclencheur ou d’une action Webhook HTTP.
Remarque
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
Important
À 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 dans 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 des façons de limiter l’accès aux déclencheurs qui reçoivent des appels entrants à votre flux de travail d’application logique afin que seuls des clients autorisés puissent appeler votre flux de travail :
- Activer OAuth avec Microsoft Entra ID
- Générer des jetons ou des clés de signature d’accès partagé (SAP)
- Désactiver l’authentification par signature d’accès partagé (SAP)
- Limiter les adresses IP entrantes
- Exposer votre application logique avec Gestion des API Azure
Activer OAuth 2.0 avec Microsoft Entra ID
Dans un flux de travail Consommation qui démarre avec un déclencheur basé sur des requêtes, vous pouvez authentifier et autoriser les appels entrants envoyés au point de terminaison créés par ce déclencheur en activant OAuth 2.0 avec Microsoft Entra ID. Pour configurer cette authentification, définissez ou ajoutez une stratégie d’autorisation au niveau de la ressource d’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 Standard qui commence par le déclencheur Requête (mais pas un déclencheur Webhook), vous pouvez utiliser l’approvisionnement Azure Functions pour authentifier les appels entrants envoyés au point de terminaison créés par le déclencheur Requête à l’aide d’une identité managée. Cette disposition est également appelée « Authentification facile ». Pour plus d’informations, Consultez Flux de travail de déclencheur dans les applications logiques Standard avec l’authentification facile.
Considérations avant d’activer OAuth 2.0 avec Microsoft Entra ID
Pour une sécurité optimale, Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour l’authentification dans la mesure du possible. Cette option offre une sécurité supérieure sans avoir à fournir d’informations d’identification. Azure gère cette identité et sécurise les informations d’authentification. Ainsi, vous n’avez pas à gérer ces informations sensibles. Pour configurer une identité managée pour Azure Logic Apps, consultez Authentifier l’accès et les connexions aux ressources Azure avec des identités managées dans Azure Logic Apps.
Dans les flux de travail Consommation, les appels entrants à l’URL de point de terminaison pour un déclencheur basé sur des requêtes ne peut utiliser qu’un seul schéma d’autorisation : OAuth 2.0 avec Microsoft Entra ID ou Signature d’accès partagé (SAP). 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 dans Azure Logic Apps, car le service ne sait quel schéma choisir. Si votre flux de travail Consommation commence par le déclencheur Requête, vous pouvez désactiver l’authentification SAP et restreindre l’autorisation à uniquement OAuth 2.0 avec Microsoft Entra ID. Pour les flux de travail Standard, vous pouvez utiliser d’autres types d’authentification sans désactiver SAP.
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
Authorization
du jeton d’accès doit spécifier le typeBearer
ou 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 Consommation 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) comme émetteur pour Microsoft Entra ID.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ù
aud
est la valeur de Public ciblé etiss
la 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": "aaaabbbb-0000-cccc-1111-dddd2222eeee", "unique_name": "SophiaOwen@fabrikam.com", "upn": "SophiaOwen@fabrikam.com", "uti": "TPJ7nNNMMZkOSx6_uVczUAA", "ver": "1.0" }
Activer OAuth 2.0 avec Microsoft Entra ID comme seule option pour appeler un point de terminaison de requête (Consommation uniquement)
Pour les points de terminaison basés sur des requêtes, vous pouvez restreindre l’autorisation pour utiliser uniquement OAuth 2.0 avec Microsoft Entra ID. Cette option fonctionne même si vous désactivez aussi l’authentification par signature d’accès partagé (SAP).
Pour votre flux de travail Consommation, configurez votre déclencheur Requête ou 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 Requête ou Webhook HTTP.
Remarque
Cette étape rend l’en-tête
Authorization
visible dans l’historique des exécutions du workflow et dans les sorties du déclencheur.Sur le Portail Azure, ouvrez votre flux de travail Consommation 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 flux de travail de l’application logique Consommation 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, suivez les étapes de configuration d’OAuth avec Microsoft Entra ID.
Activer OAuth avec Microsoft Entra ID pour votre ressource d’application logique Consommation
Pour ajouter une stratégie d’autorisation à votre application logique Consommation, suivez les étapes pour le Portail Azure ou le modèle Azure Resource Manager :
Sur le portail Azure, ouvrez votre workflow d’application logique Consommation dans le concepteur.
Dans le menu de l’application logique, sous Paramètres, sélectionnez Autorisation.
Sur la page Autorisation, 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 Requête :
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": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
.
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
Authorization
du 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 Requête ou du déclencheur Webhook HTTP pour 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 Requête :
"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
Générer un jeton ou une clé de signature d’accès partagé (SAP)
Lorsqu’un flux de travail commence par un déclencheur basé sur des requêtes et que vous enregistrez ce flux de travail pour la première fois, Azure Logic Apps crée un point de terminaison pouvant être appelé sur ce déclencheur. Ce point de terminaison a une URL qui peut recevoir des appels entrants ou des requêtes pour démarrer le flux de travail. L’URL inclut une Signature d’accès partagé (SAP), qui est une clé ou un jeton qui accorde des autorisations, par exemple, aux services de stockage. L’URL du point de terminaison utilise le format suivant :
https://<request-endpoint-URI>sp=<permissions>sv=<SAS-version>sig=<signature>
Par exemple, pour afficher cette URL dans un déclencheur Requête, recherchez la propriété HTTP URL du déclencheur :
L’URL complète ressemble à l’exemple suivant :
https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
La SAP dans l’URL a des paramètres de requête, décrits 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é est secrète et chiffrée, stockée avec l’application logique, et 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. |
Important
Veillez à protéger votre clé SAP comme vous le feriez pour protéger une clé de compte contre toute utilisation non autorisée. Configurez ou mettez en œuvre un plan pour révoquer une clé d’accès compromise. Faites preuve de prudence lorsque vous distribuez des URI qui utilisent des clés d’accès et distribuez-les uniquement sur une connexion sécurisée, telle que HTTPS. Veillez à effectuer uniquement des opérations qui utilisent une clé d’accès via une connexion HTTPS. Tout utilisateur ayant un URI avec une clé valide peut accéder à la ressource associée. Pour maintenir la sécurité et protéger l’accès à votre workflow d’application logique, regénérez les clés d’accès à intervalles réguliers, car elles sont susceptibles de répondre à des stratégies de sécurité ou d’être compromises. Vous pouvez de cette manière veiller à ce que seules les requêtes autorisées puissent déclencher votre workflow, ce qui protège vos données et processus contre tout accès non autorisé.
Si vous utilisez une clé SAP pour accéder aux services de stockage, Microsoft vous recommande de créer une SAP de délégation d’utilisateur, sécurisée avec Microsoft Entra ID, plutôt qu’une clé de compte.
Pour une sécurité optimale, Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour l’authentification chaque fois que cela est possible. Cette option offre une sécurité supérieure sans avoir à fournir d’informations d’identification. Azure gère cette identité et sécurise les informations d’authentification. Ainsi, vous n’avez pas à gérer ces informations sensibles. Pour configurer une identité managée pour Azure Logic Apps, consultez Authentifier l’accès et les connexions aux ressources Azure avec des identités managées dans Azure Logic Apps.
Les appels entrants à un point de terminaison sur un déclencheur Requête ne peuvent utiliser qu’un seul schéma d’autorisation : SAS ou OAuth 2.0 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 dans Azure Logic Apps, car le service ne sait pas quel schéma choisir.
Si vous avez un workflow Consommation qui commence par le déclencheur Requête, vous pouvez désactiver l’authentification SAP. Cette option fonctionne, même si vous limitez aussi l’autorisation pour utiliser uniquement OAuth 2.0 avec Microsoft Entra ID. Pour les flux de travail Standard, vous pouvez utiliser d’autres types d’authentification sans désactiver SAP.
Pour découvrir plus d’informations sur la sécurité lorsque vous utilisez une clé SAP, consultez les sections suivantes de ce guide :
- 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
Désactiver l’authentification par signature d’accès partagé (SAP) (Consommation uniquement)
Par défaut, un déclencheur basé sur des requêtes est activé pour l’authentification SAP. L’URL du point de terminaison du déclencheur inclut une SAP, en commençant par les paramètres de requête, sp-<permissions>sv-<SAS-version>sig=<signature>
, par exemple :
https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
Si votre flux de travail Consommation commence par le déclencheur Requête et que vous souhaitez utiliser OAuth avec Microsoft Entra ID, vous pouvez désactiver l’authentification SAP pour éviter les erreurs et les problèmes d’exécution de votre flux de travail. Vous ajoutez également une couche de sécurité en supprimant la dépendance sur les secrets, ce qui réduit le risque de journalisation ou de fuite des secrets.
Cette option fonctionne même si vous activez aussi OAuth 2.0 avec Microsoft Entra ID comme seule option pour appeler un point de terminaison basé sur des requêtes. Pour les flux de travail Standard, vous pouvez utiliser d’autres types d’authentification sans désactiver SAP.
Remarque
Cette action désactive l’authentification SAP pour les requêtes entrantes et bloque les clés ou signatures SAP existantes. Toutefois, vos clés ou signatures SAP restent valides et fonctionnent toujours si vous activez à nouveau l’authentification SAP. Pour désactiver des signatures ou clés SAP en créant de nouvelles versions, consultez Regénération de clés d’accès.
Après avoir désactivé l’authentification SAP, l’URL du point de terminaison du déclencheur Requête n’inclut plus la clé SAP, par exemple :
https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01
Prérequis
Pour cette tâche, vous avez besoin d’un outil pour envoyer des appels d’API REST, par exemple :
- Visual Studio Code avec une extension de Visual Studio Marketplace
- Invoke-RestMethod de PowerShell
- Microsoft Edge - Outil console réseau
- Bruno
- curl
Attention
Dans les scénarios comprenant des données sensibles, comme des informations d’identification, des secrets, des jetons d’accès, des clés API et d’autres informations similaires, veillez à utiliser un outil qui protège vos données avec les fonctionnalités de sécurité nécessaires, qui fonctionne en mode hors connexion ou localement, qui ne synchronise pas vos données avec le cloud, et qui ne vous impose pas de vous connecter à un compte en ligne. Vous réduirez ainsi les risques liés à l’exposition de données sensibles au public.
Rechercher les déclencheurs avec SAP activé ou désactivé
Lorsque l’authentification SAP est désactivée, l’URL du point de terminaison du déclencheur n’inclut plus la clé SAP. En outre, la définition du flux de travail Consommation inclut l’objet JSON sasAuthenticationPolicy. Cet objet a une propriété d’état définie sur Désactivé, par exemple :
"properties": {
"accessControl": {
"triggers": {
"sasAuthenticationPolicy": {
"state": "Disabled"
}
}
}
}
Pour rechercher les flux de travail Consommation où SAP est activé ou désactivé, vérifiez si la définition de flux de travail inclut l’objet sasAuthenticationPolicy où la propriété d’état est définie sur Désactivé.
Avec votre outil qui envoie des appels d’API REST, obtenez des informations sur votre flux de travail en exécutant l’opération Flux de travail – Obtenir à l’aide de la requête GET suivante, par exemple :
GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Prenez la sortie de l’opération Flux de travail – Obtenir et vérifiez si l’objet sasAuthenticationPolicy existe où la propriété d’état est définie sur Désactivé.
Ajoutez la propriété sasAuthenticationPolicy à votre définition de flux de travail
Pour les flux de travail Consommation dans lesquels vous souhaitez désactiver l’authentification SAP, suivez ces étapes :
Si ce n’est déjà fait, obtenez des informations sur votre flux de travail en exécutant l’opération Flux de travail – Obtenir à l’aide de la requête GET suivante, par exemple :
GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Prenez la sortie de l’opération Flux de travail – Obtenir, puis ajoutez manuellement les éléments suivants :
Dans l’objet
properties
, ajoutez un objetaccessControl
qui contient un objettriggers
, s’il n’existe pas.Dans l’objet
triggers
, ajoutez un objetsasAuthenticationPolicy
qui contient la propriétéstate
définie surDisabled
.
Quand vous avez terminé, la partie modifiée ressemble à l’exemple suivant :
"properties": { "accessControl": { "triggers": { "sasAuthenticationPolicy": { "state": "Disabled" } } } }
Envoyez une autre requête pour mettre à jour votre flux de travail avec la sortie modifiée, que vous utilisez comme entrée dans le corps de la demande, en exécutant l’opération Flux de travail – Mettre à jour à l’aide de la requête PATCH suivante, par exemple :
PATCH https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Sur le Portail Azure, accédez à votre flux de travail Consommation dans le concepteur et vérifiez que l’URL du déclencheur Requête n’inclut plus la SAP.
Pour activer Oauth 2.0 avec Microsoft Entra ID, au niveau de la ressource d’application logique, ajouter une stratégie d’autorisation pour OAuth avec Microsoft Entra ID.
Pour plus d’informations, consultez Activer OAuth 2.0 avec Microsoft Entra ID.
Régénération de clés d'accès
Pour maintenir la sécurité et protéger l’accès à votre workflow d’application logique, regénérez les clés d’accès à intervalles réguliers, car elles sont susceptibles de répondre à des stratégies de sécurité ou d’être compromises. Vous pouvez de cette manière veiller à ce que seules les requêtes autorisées puissent déclencher votre workflow, ce qui protège vos données et processus contre tout accès non autorisé.
Pour regénérer une nouvelle clé d’accès à tout moment, utilisez l’API REST Azure ou le Portail Azure. Toutes les URL ou URI précédemment générés qui utilisent l’ancienne clé sont invalidés et ne sont plus autorisés à déclencher le workflow de votre application logique. Les URI 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 la ressource d’application logique utilisée par 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.
Important
Veillez à protéger votre clé d’accès comme vous le feriez pour protéger une clé de compte contre toute utilisation non autorisée. Configurez ou mettez en œuvre un plan pour révoquer une clé d’accès compromise. Faites preuve de prudence lorsque vous distribuez des URI qui utilisent des clés d’accès et distribuez-les uniquement sur une connexion sécurisée, telle que HTTPS. Veillez à effectuer uniquement des opérations qui utilisent une clé d’accès via une connexion HTTPS. Tout utilisateur ayant un URI avec une clé valide peut accéder à la ressource associée.
Si vous utilisez une clé SAP pour accéder aux services de stockage, Microsoft vous recommande de créer une SAP de délégation d’utilisateur, sécurisée avec Microsoft Entra ID, plutôt qu’une clé de compte.
Pour une sécurité optimale, Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour l’authentification dans la mesure du possible. Cette option offre une sécurité supérieure sans avoir à fournir d’informations d’identification. Azure gère cette identité et sécurise les informations d’authentification. Ainsi, vous n’avez pas à gérer ces informations sensibles. Pour configurer une identité managée pour Azure Logic Apps, consultez Authentifier l’accès et les connexions aux ressources Azure avec des identités managées dans Azure Logic Apps.
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/{subscription-ID}/resourceGroups/{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 Azure Logic Apps, par exemple :
POST /subscriptions/{subscription-ID}/resourceGroups/{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.
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 des requêtes en utilisant l’opération Déclencheurs de flux de travail – Exécuter ou en utilisant la Gestion des API. 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’opération Flux de travail – Créer ou mettre à jour dans l’API REST Azure Logic Apps.
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 Standard.
Dans le menu de l’application logique, sous Paramètres, sélectionnez Mise en réseau.
Dans la section Configuration du trafic entrant, à côté d’Accès au réseau public, sélectionnez Activé sans restriction d’accès.
Dans la page Restrictions d’accès, sous Accès à l’application, sélectionnez Activé à partir de la sélection des réseaux virtuels et des adresses IP.
Sous Accès au site et règles, sous l’onglet Site principal, ajoutez une ou plusieurs règles aux requêtes Autoriser ou Refuser à partir de plages d’adresses IP spécifiques. 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 ces cas, sur le déclencheur ou l’action, ouvrez la liste Paramètres avancés, puis sélectionnez Authentification.
Important
Pour protéger les informations sensibles traitées par votre flux de travail d’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.
Pour une sécurité optimale, Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour l’authentification dans la mesure du possible. Cette option offre une sécurité supérieure sans avoir à fournir d’informations d’identification. Azure gère cette identité et sécurise les informations d’authentification. Ainsi, vous n’avez pas à gérer ces informations sensibles. Pour configurer une identité managée pour Azure Logic Apps, consultez Authentifier l’accès et les connexions aux ressources Azure avec des identités managées dans Azure Logic Apps.
Authentification de base
Pour les appels HTTP, l’authentification de base utilise une chaîne encodée en base64 qui contient un nom d’utilisateur et un mot de passe pour effectuer une requête. Cette méthode transmet les informations d’identification sans chiffrement et pose des risques de sécurité accrus, sauf si vous utilisez cette option avec le protocole HTTPS/SSL.
Important
Pour une sécurité optimale, Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour l’authentification dans la mesure du possible. Cette option offre une sécurité supérieure sans avoir à fournir d’informations d’identification. Azure gère cette identité et sécurise les informations d’authentification. Ainsi, vous n’avez pas à gérer ces informations sensibles. Pour configurer une identité managée pour Azure Logic Apps, consultez Authentifier l’accès et les connexions aux ressources Azure avec des identités managées dans Azure Logic Apps.
Si l’option Essentiel est disponible et sélectionnée, 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
L’authentification par certificat client permet ou exige que les utilisateurs s’authentifient directement avec des certificats X.509 sur leur Microsoft Entra ID pour les connexions aux applications et au navigateur. Cette fonctionnalité vous aide à adopter une authentification résistante au hameçonnage et à vous authentifier avec un certificat X.509 sur votre infrastructure à clé publique (PKI).
Important
Pour une sécurité optimale, Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour l’authentification dans la mesure du possible. Cette option offre une sécurité supérieure sans avoir à fournir d’informations d’identification. Azure gère cette identité et sécurise les informations d’authentification. Ainsi, vous n’avez pas à gérer ces informations sensibles. Pour configurer une identité managée pour Azure Logic Apps, consultez Authentifier l’accès et les connexions aux ressources Azure avec des identités managées dans Azure Logic Apps.
Si l’option Certificat client est disponible et sélectionnée, 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 Microsoft Entra
Sur le déclencheur Requête, vous pouvez utiliser la plateforme Microsoft Entra pour authentifier les appels entrants après avoir configuré des stratégies d’autorisation Microsoft Entra pour votre application logique.
Important
Pour une sécurité optimale, Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour l’authentification dans la mesure du possible. Cette option offre une sécurité supérieure sans avoir à fournir d’informations d’identification. Azure gère cette identité et sécurise les informations d’authentification. Ainsi, vous n’avez pas à gérer ces informations sensibles. Pour configurer une identité managée pour Azure Logic Apps, consultez Authentifier l’accès et les connexions aux ressources Azure avec des identités managées dans Azure Logic Apps.
Sur tous les autres déclencheurs et actions qui prennent en charge le type d’authentification Active Directory OAuth (OAuth 2.0 avec Microsoft Entra ID), spécifiez les valeurs de propriété suivantes :
Propriété (concepteur) | Propriété (JSON) | Obligatoire | Value | Description |
---|---|---|---|---|
Authentification | type |
Oui | Active Directory OAuth (OAuth 2.0 avec Microsoft Entra ID) 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 la clé 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 monolocataire et que vous souhaitez utiliser une opération HTTP avec un certificat TSL/SSL, un certificat client ou 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 monolocataire.
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.
Important
Pour une sécurité optimale, Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour l’authentification dans la mesure du possible. Cette option offre une sécurité supérieure sans avoir à fournir d’informations d’identification. Azure gère cette identité et sécurise les informations d’authentification. Ainsi, vous n’avez pas à gérer ces informations sensibles. Pour configurer une identité managée pour Azure Logic Apps, consultez Authentifier l’accès et les connexions aux ressources Azure avec des identités managées dans Azure Logic Apps.
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 type
Oui Identité gérée
ouManagedServiceIdentity
Type d’authentification à utiliser Identité gérée identity
Non <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é audience
Oui <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.net
pour 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 Paramètres avancés, 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
type
en tant queManagedServiceIdentity
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": "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.
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.
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 :
Pour plus d’informations sur l’isolation, consultez la documentation suivante :