Partage via


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 :

Pour plus d’informations sur la sécurité dans Azure, consultez les rubriques suivantes :

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

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
  1. Sur le portail Azure, ouvrez votre workflow d’application logique dans le concepteur.

  2. Dans le menu de l’application logique, sous Paramètres, sélectionnez Paramètres de flux de travail.

  3. 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.

  4. 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
  1. Dans le portail Azure, ouvrez votre ressource d’application logique Standard.

  2. Dans le menu de l’application logique, sous Paramètres, sélectionnez Mise en réseau.

  3. Dans la section Configuration du trafic entrant, à côté d’Accès au réseau public, sélectionnez Activé sans restriction d’accès.

  4. 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.

  5. 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.

    Sorties sécurisées en tant qu’entrées et impact en aval sur la plupart des actions

    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.

    Sorties sécurisées en tant qu’entrées et impact en aval sur certaines actions

    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.

    Entrées sécurisées et impact en aval sur la plupart des actions

    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.

    Entrées sécurisées et impact en aval sur certaines actions

Sécuriser les entrées et sorties dans le concepteur

  1. Sur le Portail Azure, ouvrez votre flux de travail d’application logique dans le Concepteur.

  2. Dans le concepteur, sélectionnez le déclencheur ou l’action dont vous souhaitez sécuriser les données sensibles.

  3. Dans le volet d’informations qui s’ouvre, sélectionnez Paramètres, puis développez Sécurité.

    Capture d’écran montrant le Portail Azure, le concepteur de flux de travail et le déclencheur ou l’action avec les paramètres ouverts.

  4. Activez Entrées sécurisées, Sorties sécurisées, ou les deux.

    Capture d’écran montrant le flux de travail avec les paramètres d’entrées ou de sorties sécurisées d’une action activés.

    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.

    Capture d’écran montrant le flux de travail avec la liste de contenu dynamique d’une action ultérieure ouverte, et le jeton de l’action précédente pour la sortie sécurisée avec l’icône verrou.

  5. Après l’exécution du flux de travail, vous pouvez voir l’historique de cette exécution.

    1. Sélectionnez Vue d’ensemble dans le menu de l’application logique Consommation ou dans le menu du flux de travail Standard.

    2. Dans Historique des exécutions, sélectionnez l’exécution que vous souhaitez consulter.

    3. 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.

      Capture d’écran de l’historique de l’exécution du flux de travail standard avec les entrées et sorties 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 :

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 :

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 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 type Bearer ou le type PoP. 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/ ou https://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é et iss 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).

  1. 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.

  2. Sur le Portail Azure, ouvrez votre flux de travail Consommation dans le concepteur.

  3. Dans le concepteur, sélectionnez le déclencheur. Dans le volet d’information qui s’ouvre, sélectionnez Paramètres.

  4. 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 :

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 :

  1. Sur le portail Azure, ouvrez votre workflow d’application logique Consommation dans le concepteur.

  2. Dans le menu de l’application logique, sous Paramètres, sélectionnez Autorisation.

  3. Sur la page Autorisation, sélectionnez Ajouter une stratégie.

    Capture d’écran montrant le Portail Azure, la page Autorisation et le bouton sélectionné pour ajouter une stratégie.

  4. 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 :

    Capture d’écran montrant le Portail Azure, la page Autorisation et les détails de la stratégie d’autorisation.

    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 par https://sts.windows.net/ ou https://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 :

    Capture d’écran montrant le Portail Azure, la page Autorisation et les informations de la stratégie de preuve de possession.

  5. 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".

  6. 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.

  7. Quand vous avez terminé, sélectionnez Enregistrer.

  8. 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 :

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 :

Capture d’écran du Portail Azure, du concepteur de flux de travail Consommation et de l’URL du point de terminaison du déclencheur Requête.

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 :

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 :

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é.

  1. 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

  2. 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 :

  1. 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

  2. Prenez la sortie de l’opération Flux de travail – Obtenir, puis ajoutez manuellement les éléments suivants :

    1. Dans l’objet properties, ajoutez un objet accessControl qui contient un objet triggers, s’il n’existe pas.

    2. Dans l’objet triggers, ajoutez un objet sasAuthenticationPolicy qui contient la propriété state définie sur Disabled.

    Quand vous avez terminé, la partie modifiée ressemble à l’exemple suivant :

    "properties": {
        "accessControl": {
            "triggers": {
                "sasAuthenticationPolicy": {
                    "state": "Disabled"
                }
            }
        }
    }
    
  3. 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

  4. 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.

  5. 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.

  1. Dans le Portail Azure, ouvrez la ressource d’application logique utilisée par la clé que vous souhaitez régénérer.

  2. Dans le menu de la ressource d’application logique, sous Paramètres, sélectionnez Clés d’accès.

  3. 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 :

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
  1. Dans le Portail Azure, ouvrez votre application logique Consommation dans le concepteur du flux de travail.

  2. Dans le menu de l’application logique, sous Paramètres, sélectionnez Paramètres de flux de travail.

  3. 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

  4. É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
  1. Dans le portail Azure, ouvrez votre ressource d’application logique Standard.

  2. Dans le menu de l’application logique, sous Paramètres, sélectionnez Mise en réseau.

  3. Dans la section Configuration du trafic entrant, à côté d’Accès au réseau public, sélectionnez Activé sans restriction d’accès.

  4. 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.

  5. 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

      1. En fonction de l’ajout d’un déclencheur ou d’une action Gestion des API, procédez comme suit :

        • Déclencheur :

          1. Dans le concepteur de flux de travail, sélectionnez Ajouter un déclencheur.

          2. Une fois le volet Ajouter un déclencheur ouvert, entrez Gestion des API dans la zone de recherche.

          3. Dans la liste des résultats du déclencheur, sélectionnez Choisir un déclencheur Gestion des API Azure.

        • Action :

          1. Dans le concepteur de flux de travail, sélectionnez le signe plus (+) où vous souhaitez ajouter l’action.

          2. Une fois le volet Ajouter une action ouvert, entrez Gestion des API dans la zone de recherche.

          3. 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 :

        Capture d’écran du Portail Azure, du concepteur de flux de travail Consommation et la recherche du déclencheur de Gestion des API.

      2. 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.

      3. 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.

      1. Dans le concepteur de flux de travail, sélectionnez le signe plus (+) où vous souhaitez ajouter l’action.

      2. Une fois le volet Ajouter une action ouvert, entrez Gestion des API dans la zone de recherche.

      3. Dans la liste des résultats de l’action, sélectionnez Appeler une API Gestion des API Azure.

        Capture d’écran du portail Azure, du concepteur de flux de travail standard et de l’action de Gestion des API Azure.

      4. 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.

      5. Dans la liste des opérations d’API, sélectionnez l’opération d’API à appeler, puis sélectionnez Créer.

        Capture d’écran montrant le portail Azure, le concepteur de flux de travail standard et l’API sélectionnée à appeler.

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 :

  1. Désinstallez toutes les instances OpenSSL.
  2. Installez OpenSSL version 1.1.1t.
  3. Resignez votre certificat en utilisant la nouvelle mise à jour.
  4. 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 :

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é.

  1. 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.

  2. Pour qu’une fonction Azure puisse utiliser une identité managée, vous devez d’abord activer l’authentification des fonctions Azure.

  3. 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
    ou
    ManagedServiceIdentity
    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 exemple https://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 ressource https://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 que ManagedServiceIdentity 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

Pour plus d’informations sur l’isolation, consultez la documentation suivante :