Sécuriser l’accès et les données pour les flux de travail dans Azure Logic Apps

Azure Logic Apps s’appuie sur le Stockage Azure pour stocker et chiffrer automatiquement les données au repos. Ce chiffrement protège vos données et vous aide à répondre aux engagements de votre entreprise en matière de sécurité et de conformité. Par défaut, Stockage Azure utilise des clés managées par Microsoft pour chiffrer vos données. Pour plus d'informations, consultez Fonctionnalité de chiffrement du service Stockage Azure pour les données au repos.

Pour contrôler l’accès aux données sensibles et les protéger dans Azure Logic Apps, vous pouvez configurer des paramètres de sécurité supplémentaires dans les domaines suivants :

• Accès aux opérations d’une application logique
• Accès aux entrées et aux sorties de l’historique des exécutions
• Accès aux entrées de paramètres
• Types d’authentification pour les déclencheurs et les actions qui prennent en charge l’authentification
• Accès pour les appels entrants à des déclencheurs basés sur des requêtes
• Accès pour les appels sortants à d’autres services et systèmes
• Blocage de la création de connexions pour des connecteurs spécifiques
• Conseils d’isolation pour les applications logiques
• Base de référence de sécurité Azure pour Azure Logic Apps

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

• Vue d’ensemble du chiffrement Azure
• Azure Data Encryption-at-Rest (Chiffrement des données Azure au repos)
• Point de référence de sécurité Microsoft Cloud

Accès aux opérations d’une application logique

Pour les applications logiques Consommation uniquement, avant de pouvoir créer ou gérer des applications logiques et leurs connexions, vous avez besoin d'autorisations spécifiques, fournies par des rôles à l’aide du contrôle d'accès en fonction du rôle Azure (Azure RBAC). Vous pouvez également configurer des autorisations afin que seuls des utilisateurs ou des groupes spécifiques puissent exécuter des tâches spécifiques, telles que la gestion, la modification et l’affichage des applications logiques. Pour contrôle les autorisations, vous pouvez attribuer des rôles intégrés ou personnalisés aux membres qui ont accès à votre abonnement Azure. Azure Logic Apps a les rôles spécifiques suivants, selon que vous avez un flux de travail d'application logique de type Consommation ou Standard :

Workflows Consommation

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

Accès à l’historique des exécutions

Pendant l’exécution d’une application logique, toutes les données sont chiffrées pendant le transit à l’aide de Transport Layer Security (TLS) et au repos. À la fin de l’exécution de votre application logique, vous pouvez afficher l’historique de l’exécution. Celui-ci comprend notamment les étapes exécutées, ainsi que l’état, la durée, les entrées et les sorties associés à chaque action. Ces informations détaillées fournissent des insights sur la façon dont votre application logique s’est exécutée et vous permettent de résoudre les problèmes qui peuvent survenir.

Lorsque vous affichez l’historique des exécutions de votre application logique, Azure Logic Apps authentifie votre accès, et fournit des liens vers les entrées et les sorties des requêtes et des réponses pour chaque exécution. Toutefois, pour les actions qui gèrent des mots de passe, des secrets, des clés ou d’autres informations sensibles, vous devez empêcher les autres utilisateurs d’accéder à ces données. Par exemple, si votre application logique obtient un secret dans Azure Key Vault en vue de l’utiliser lors de l’authentification d’une action HTTP, vous devez empêcher l’affichage de ce secret.

Pour contrôler l’accès aux entrées et aux sorties dans l’historique des exécutions de votre application logique, vous disposez des options suivantes :

• Restreindre l’accès en fonction de la plage d’adresses IP.

  Cette option vous aide à sécuriser l’accès à l’historique des exécutions en fonction des requêtes provenant d’une plage d’adresses IP spécifique.

• Sécuriser les données dans l’historique des exécutions à l’aide d’une obfuscation.

  Vous pouvez sécuriser les entrées et/ou sorties de nombreux déclencheurs et actions dans l’historique d’exécution d’une application logique.

Restreindre l’accès en fonction de la plage d’adresses IP

Vous pouvez limiter l’accès aux entrées et sorties de l’historique d’exécution de vos flux de travail de l’application logique afin que seules les requêtes provenant de plages d’adresses IP spécifiques soient en mesure de visualiser ces données.

Par exemple, pour empêcher quiconque d’accéder aux entrées et aux sorties, spécifiez une plage d’adresses IP comme celle-ci : 0.0.0.0-0.0.0.0. Seule une personne disposant de droits d’administrateur peut supprimer cette restriction, ce qui permet un accès « juste à temps » aux données dans les flux de travail de votre application logique. Une plage d’adresses IP valide utilise ces formats : x.x.x.x/x ou x.x.x.x-x.x.x.x

Pour spécifier les plages d’adresses IP autorisées, suivez ces étapes pour votre application logique Consommation ou Standard dans le portail Azure ou votre modèle Azure Resource Manager :

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {<workflow-definition>},
            "parameters": {},
            "accessControl": {
               "contents": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     },
                     {
                        "addressRange": "2001:0db8::/64"
                     }
                  ]
               }
            }
         }
      }
   ],
   "outputs": {}
}

{
   "type": "Microsoft.Web/sites/config",
   "apiVersion": "2022-09-01",
   "name": "[concat(parameters('sites_My_Standard_Logic_App_name'), '/web')]",
   "location": "West US",
   "dependsOn": [
      "[resourceId('Microsoft.Web/sites', parameters('sites_My_Standard_Logic_App_name'))]"
   ],
   "tags": {
      "hidden-link: /app-insights-resource-id": "/subscriptions/{subscriptionID}/resourceGroups/Standard-RG/providers/Microsoft.Insights/components/My-Standard-Logic-App"
   },
   "properties": {
      "numberOfWorkers": 1,
      "defaultDocuments": [
         "Default.htm",
         "Default.html",
         "Default.asp",
         "index.htm",
         "index.html",
         "iisstart.htm",
         "default.aspx",
         "index.php"
      ],
      "netFrameworkVersion": "v6.0",
      "requestTracingEnabled": false,
      "remoteDebuggingEnabled": false,
      "httpLoggingEnabled": false,
      "acrUseManagedIdentityCreds": false,
      "logsDirectorySizeLimit": 35,
      "detailedErrorLoggingEnabled": false,
      "publishingUsername": "$My-Standard-Logic-App",
      "scmType": "None",
      "use32BitWorkerProcess": false,
      "webSocketsEnabled": false,
      "alwaysOn": false,
      "managedPipelineMode": "Integrated",
      "virtualApplications": [
         {
            "virtualPath": "/",
            "physicalPath": "site\\wwwroot",
            "preloadEnabled": false
         }
      ],
      "loadBalancing": "LeastRequests",
      "experiments": {
         "rampUpRules": []
      },
      "autoHealEnabled": false,
      "vnetRouteAllEnabled": false,
      "vnetPrivatePortsCount": 0,
      "publicNetworkAccess": "Enabled",
      "cors": {
         "supportCredentials": false
      },
      "localMySqlEnabled": false,
      "managedServiceIdentityId": 3065,
      "ipSecurityRestrictions": [
         {
            "ipAddress": "208.130.0.0/16",
            "action": "Deny",
            "tag": "Default",
            "priority": 100,
            "name": "Ports"
         },
         {
            "ipAddress": "Any",
            "action": "Deny",
            "priority": 2147483647,
            "name": "Deny all",
            "description": "Deny all access"
         }
      ],
      "ipSecurityRestrictionsDefaultAction": "Deny",
      "scmIpSecurityRestrictions": [
         {
            "ipAddress": "Any",
            "action": "Allow",
            "priority": 2147483647,
            "name": "Allow all",
            "description": "Allow all access"
         }
      ],
      "scmIpSecurityRestrictionsDefaultAction": "Allow",
      "scmIpSecurityRestrictionsUseMain": false,
      "http20Enabled": false,
      "minTlsVersion": "1.2",
      "scmMinTlsVersion": "1.2",
      "ftpsState": "FtpsOnly",
      "preWarmedInstanceCount": 1,
      "functionAppScaleLimit": 0,
      "functionsRuntimeScaleMonitoringEnabled": true,
      "minimumElasticInstanceCount": 1,
      "azureStorageAccounts": {}
   }
},

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 :

Considérations relatives à la sécurisation des entrées et des sorties

Avant d’utiliser ces paramètres pour sécuriser ces données, prenez connaissance des considérations suivantes :

• Quand vous rendez secrètes les entrées ou les sorties d’un déclencheur ou d’une action, Azure Logic Apps n’envoie pas les données sécurisées à Azure Log Analytics. De plus, vous ne pouvez pas ajouter de propriétés suivies à ce déclencheur ou à cette action à des fins de supervision.

• L’API Azure Logic Apps qui permet de gérer l’historique des workflows ne retourne pas de sorties sécurisées.

• Pour sécuriser les sorties d’une action qui rend les entrées secrètes ou qui rend explicitement les sorties secrètes, activez manuellement Sorties sécurisées dans cette action.

• Veillez à activer Entrées sécurisées ou Sorties sécurisées dans les actions en aval, où l’historique des exécutions doit rendre ces données secrètes.

  Paramètre Sorties sécurisées

  Lorsque vous activez manuellement les sorties sécurisées dans un déclencheur ou dans une action, Azure Logic Apps masque ces sorties dans l’historique des exécutions. Si une action en aval utilise explicitement ces sorties sécurisées comme des entrées, Azure Logic Apps masque les entrées de cette action dans l’historique des exécutions, mais il n’active pas le paramètre Entrées sécurisées de l’action.

  

  Les actions Composer, Analyser JSON et Réponse comportent uniquement le paramètre Entrées sécurisées. Lorsqu’il est activé, ce paramètre masque également les sorties de ces actions. Si ces actions utilisent explicitement les sorties sécurisées en amont comme des entrées, Azure Logic Apps masque les entrées et les sorties de ces actions, mais il n’active pas le paramètre Entrées sécurisées de ces actions. Si une action en aval utilise explicitement les sorties masquées des actions Composer, Analyser JSON ou Réponse comme des entrées, Azure Logic Apps ne masque pas les entrées ou les sorties de cette action en aval.

  

  Paramètre Entrées sécurisées

  Lorsque vous activez manuellement les entrées sécurisées dans un déclencheur ou dans une action, Azure Logic Apps masque ces entrées dans l’historique des exécutions. Si une action en aval utilise explicitement les sorties visibles de ce déclencheur ou de cette action comme entrées, Azure Logic Apps masque les entrées de cette action en aval dans l’historique des exécutions, mais n’active pas les Entrées sécurisées de cette action et ne masque pas les sorties de cette action.

  

  Si les actions Composer, Analyser JSON et Réponse utilisent explicitement les sorties visibles du déclencheur ou de l’action qui a des entrées sécurisées, Azure Logic Apps masque les entrées et les sorties de ces actions, mais il n’active pas le paramètre Entrées sécurisées de ces actions. Si une action en aval utilise explicitement les sorties masquées des actions Composer, Analyser JSON ou Réponse comme des entrées, Azure Logic Apps ne masque pas les entrées ou les sorties de cette action en aval.

  

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

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

   

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

   

   Le déclencheur ou l’action affiche désormais une icône de verrouillage dans la barre de titre. Tous les jetons qui représentent les sorties sécurisées d’actions précédentes affichent également les icônes verrou. Par exemple, dans une action suivante, après avoir sélectionné un jeton pour une sortie sécurisée dans la liste de contenu dynamique, ce jeton affiche une icône de verrouillage.

   

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.

      

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.

Pour en savoir plus, consultez les sections suivantes de la présente rubrique :

• Sécuriser des paramètres dans les définitions de workflow
• Sécuriser les données dans l’historique des exécutions à l’aide d’une obfuscation

Si vous automatisez le déploiement d’applications logiques à l’aide de modèles Azure Resource Manager, vous pouvez définir des paramètres de modèles sécurisés, qui sont évalués au moment du déploiement, à l’aide des types securestring et secureobject. Pour définir des paramètres de modèle, utilisez la section parameters de niveau supérieur de votre modèle, qui est différente de la section parameters de votre définition de workflow. Pour fournir les valeurs des paramètres de modèle, utilisez un autre fichier de paramètres.

Par exemple, si vous utilisez des secrets, vous pouvez définir et utiliser des paramètres de modèles sécurisés qui récupèrent ces secrets à partir d’Azure Key Vault lors du déploiement. Vous pouvez ensuite référencer le coffre de clés et le secret dans votre fichier de paramètres. Pour plus d’informations, consultez les rubriques suivantes :

• Transmettre des valeurs sensibles au déploiement à l’aide d’Azure Key Vault
• Sécuriser des paramètres dans des modèles Azure Resource Manager plus loin dans cette rubrique

Paramètres sécurisés dans les définitions de flux de travail (flux de travail de consommation)

Pour protéger des informations sensibles dans la définition du flux de travail de votre application logique, utilisez des paramètres sécurisés afin que ces informations ne soient pas visibles après l’enregistrement du flux de travail de l’application logique. Par exemple, supposons que vous avez une action HTTP qui nécessite une authentification de base, c’est-à-dire, un nom d’utilisateur et un mot de passe. Dans la définition de workflow, la section parameters définit les paramètres basicAuthPasswordParam et basicAuthUsernameParam à l’aide du type securestring. La définition de l’action référence ensuite ces paramètres dans la section authentication.

"definition": {
   "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
   "actions": {
      "HTTP": {
         "type": "Http",
         "inputs": {
            "method": "GET",
            "uri": "https://www.microsoft.com",
            "authentication": {
               "type": "Basic",
               "username": "@parameters('basicAuthUsernameParam')",
               "password": "@parameters('basicAuthPasswordParam')"
            }
         },
         "runAfter": {}
      }
   },
   "parameters": {
      "basicAuthPasswordParam": {
         "type": "securestring"
      },
      "basicAuthUsernameParam": {
         "type": "securestring"
      }
   },
   "triggers": {
      "manual": {
         "type": "Request",
         "kind": "Http",
         "inputs": {
            "schema": {}
         }
      }
   },
   "contentVersion": "1.0.0.0",
   "outputs": {}
}

Paramètres sécurisés dans les modèles Azure Resource Manager (flux de consommation)

Un modèle de Resource Manager pour une ressource d’application logique et un flux de travail comporte plusieurs sections parameters. Pour protéger les mots de passe, les clés, les secrets et d’autres informations sensibles, configurez des paramètres sécurisés au niveau du modèle et au niveau de la définition de workflow à l’aide du type securestring ou secureobject. Vous pouvez ensuite stocker ces valeurs dans Azure Key Vault et utiliser le fichier de paramètres pour référencer le coffre de clés et le secret. Votre modèle récupère ensuite ces informations au moment du déploiement. Pour plus d’informations, consultez Transmettre des valeurs sensibles au déploiement à l’aide d’Azure Key Vault.

Cette liste contient des informations supplémentaires sur les sections parameters suivantes :

• En haut du modèle, une section 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 :

{
   "$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 :

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.

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

La liste suivante inclut des façons de limiter l’accès aux déclencheurs qui reçoivent des appels entrants à votre flux de travail d’application logique afin que seuls des clients autorisés puissent appeler votre flux de travail :

• Activer OAuth avec Microsoft Entra ID
• Générer des jetons ou des clés de signature d’accès partagé (SAP)
• Désactiver l’authentification par signature d’accès partagé (SAP)
• Limiter les adresses IP entrantes
• Exposer votre application logique avec Gestion des API Azure

Activer OAuth 2.0 avec Microsoft Entra ID

Dans un flux de travail Consommation qui démarre avec un déclencheur basé sur des requêtes, vous pouvez authentifier et autoriser les appels entrants envoyés au point de terminaison créés par ce déclencheur en activant OAuth 2.0 avec Microsoft Entra ID. Pour configurer cette authentification, définissez ou ajoutez une stratégie d’autorisation au niveau de la ressource d’application logique. De cette façon, les appels entrants utilisent des jetons d’accès OAuth pour l’autorisation.

Quand votre flux de travail d’application logique reçoit une requête entrante qui inclut un jeton d’accès OAuth, Azure Logic Apps compare les revendications du jeton aux revendications spécifiées par chaque stratégie d’autorisation. S’il existe une correspondance entre les revendications du jeton et toutes celles d’au moins une stratégie, l’autorisation est validée pour la requête entrante. Le jeton peut avoir plus de revendications que le nombre spécifié par la stratégie d’autorisation.

Dans un flux de travail Standard qui commence par le déclencheur Requête (mais pas un déclencheur Webhook), vous pouvez utiliser l’approvisionnement Azure Functions pour authentifier les appels entrants envoyés au point de terminaison créés par le déclencheur Requête à l’aide d’une identité managée. Cette disposition est également appelée « Authentification facile ». Pour plus d’informations, Consultez Flux de travail de déclencheur dans les applications logiques Standard avec l’authentification facile.

Considérations avant d’activer OAuth 2.0 avec Microsoft Entra ID

• Pour une sécurité optimale, Microsoft recommande d’utiliser Microsoft Entra ID avec des identités managées pour l’authentification dans la mesure du possible. Cette option offre une sécurité supérieure sans avoir à fournir d’informations d’identification. Azure gère cette identité et sécurise les informations d’authentification. Ainsi, vous n’avez pas à gérer ces informations sensibles. Pour configurer une identité managée pour Azure Logic Apps, consultez Authentifier l’accès et les connexions aux ressources Azure avec des identités managées dans Azure Logic Apps.

• Dans les flux de travail Consommation, les appels entrants à l’URL de point de terminaison pour un déclencheur basé sur des requêtes ne peut utiliser qu’un seul schéma d’autorisation : OAuth 2.0 avec Microsoft Entra ID ou Signature d’accès partagé (SAP). Bien que l’utilisation d’un schéma ne désactive pas l’autre, l’utilisation des deux schémas en même temps provoque une erreur dans Azure Logic Apps, car le service ne sait quel schéma choisir. Si votre flux de travail Consommation commence par le déclencheur Requête, vous pouvez désactiver l’authentification SAP et restreindre l’autorisation à uniquement OAuth 2.0 avec Microsoft Entra ID. Pour les flux de travail Standard, vous pouvez utiliser d’autres types d’authentification sans désactiver SAP.

• Azure Logic Apps prend en charge les schémas d’autorisation de type jeton du porteur ou de type preuve de possession (application logique de consommation uniquement) pour les jetons d’accès Microsoft Entra ID OAuth. Cependant, l’en-tête Authorization du jeton d’accès doit spécifier le 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 :

• Une application console de démon .NET Core appelant une API web protégée avec sa propre identité

• SignedHttpRequest, également appelé PoP (Preuve de possession)

Pour utiliser le jeton PoP avec votre flux de travail d’application logique Consommation, suivez les étapes de configuration d’OAuth avec Microsoft Entra ID.

Activer OAuth avec Microsoft Entra ID pour votre ressource d’application logique Consommation

Pour ajouter une stratégie d’autorisation à votre application logique Consommation, suivez les étapes pour le Portail Azure ou le modèle Azure Resource Manager :

"resources": [
   {
      // Start logic app resource definition
      "properties": {
         "state": "<Enabled-or-Disabled>",
         "definition": {<workflow-definition>},
         "parameters": {<workflow-definition-parameter-values>},
         "accessControl": {
            "triggers": {
               "openAuthenticationPolicies": {
                  "policies": {
                     "<policy-name>": {
                        "type": "AAD",
                        "claims": [
                           {
                              "name": "<claim-name>",
                              "value": "<claim-value>"
                           }
                        ]
                     }
                  }
               }
            },
         },
      },
      "name": "[parameters('LogicAppName')]",
      "type": "Microsoft.Logic/workflows",
      "location": "[parameters('LogicAppLocation')]",
      "apiVersion": "2016-06-01",
      "dependsOn": [
      ]
   }
   // End logic app resource definition
],

Inclure l’en-tête « Autorisation » dans les sorties du déclencheur de requête ou de webhook HTTP

Pour les applications logiques qui activent OAuth avec Microsoft Entra ID pour autoriser les appels entrants à accéder aux déclencheurs basés sur des requêtes, vous pouvez autoriser les sorties du déclencheur Requête ou du déclencheur Webhook HTTP pour inclure l’en-tête Authorization provenant du jeton d’accès OAuth. Dans la définition JSON sous-jacente du déclencheur, ajoutez et définissez la propriété operationOptions sur IncludeAuthorizationHeadersInOutputs. Voici un exemple de déclencheur Requête :

"triggers": {
   "manual": {
      "inputs": {
         "schema": {}
      },
      "kind": "Http",
      "type": "Request",
      "operationOptions": "IncludeAuthorizationHeadersInOutputs"
   }
}

Pour plus d’informations, consultez les rubriques suivantes :

• Informations de référence sur le schéma des types d’actions et de déclencheurs - Déclencheur de demande
• Informations de référence sur le schéma des types d’actions et de déclencheurs - Déclencheur de Webhook HTTP
• Informations de référence sur le schéma des types d’actions et de déclencheurs - Options d’opérations

Générer un jeton ou une clé de signature d’accès partagé (SAP)

Lorsqu’un flux de travail commence par un déclencheur basé sur des requêtes et que vous enregistrez ce flux de travail pour la première fois, Azure Logic Apps crée un point de terminaison pouvant être appelé sur ce déclencheur. Ce point de terminaison a une URL qui peut recevoir des appels entrants ou des requêtes pour démarrer le flux de travail. L’URL inclut une Signature d’accès partagé (SAP), qui est une clé ou un jeton qui accorde des autorisations, par exemple, aux services de stockage. L’URL du point de terminaison utilise le format suivant :

https://<request-endpoint-URI>sp=<permissions>sv=<SAS-version>sig=<signature>

Par exemple, pour afficher cette URL dans un déclencheur Requête, recherchez la propriété HTTP URL du déclencheur :

L’URL complète ressemble à l’exemple suivant :

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

La SAP dans l’URL a des paramètres de requête, décrits dans le tableau suivant :

Les appels entrants à un point de terminaison sur un déclencheur Requête ne peuvent utiliser qu’un seul schéma d’autorisation : SAS ou OAuth 2.0 avec Microsoft Entra ID. Bien que l’utilisation d’un schéma ne désactive pas l’autre, l’utilisation des deux schémas en même temps provoque une erreur dans Azure Logic Apps, car le service ne sait pas quel schéma choisir.

Si vous avez un workflow Consommation qui commence par le déclencheur Requête, vous pouvez désactiver l’authentification SAP. Cette option fonctionne, même si vous limitez aussi l’autorisation pour utiliser uniquement OAuth 2.0 avec Microsoft Entra ID. Pour les flux de travail Standard, vous pouvez utiliser d’autres types d’authentification sans désactiver SAP.

Pour découvrir plus d’informations sur la sécurité lorsque vous utilisez une clé SAP, consultez les sections suivantes de ce guide :

• Régénération des clés d’accès
• Création d’URL de rappel qui arrivent à expiration
• Création d’URL avec une clé primaire ou une clé secondaire

Désactiver l’authentification par signature d’accès partagé (SAP) (Consommation uniquement)

Par défaut, un déclencheur basé sur des requêtes est activé pour l’authentification SAP. L’URL du point de terminaison du déclencheur inclut une SAP, en commençant par les paramètres de requête, sp-<permissions>sv-<SAS-version>sig=<signature>, par exemple :

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

Si votre flux de travail Consommation commence par le déclencheur Requête et que vous souhaitez utiliser OAuth avec Microsoft Entra ID, vous pouvez désactiver l’authentification SAP pour éviter les erreurs et les problèmes d’exécution de votre flux de travail. Vous ajoutez également une couche de sécurité en supprimant la dépendance sur les secrets, ce qui réduit le risque de journalisation ou de fuite des secrets.

Cette option fonctionne même si vous activez aussi OAuth 2.0 avec Microsoft Entra ID comme seule option pour appeler un point de terminaison basé sur des requêtes. Pour les flux de travail Standard, vous pouvez utiliser d’autres types d’authentification sans désactiver SAP.

Après avoir désactivé l’authentification SAP, l’URL du point de terminaison du déclencheur Requête n’inclut plus la clé SAP, par exemple :

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01

Prérequis

Pour cette tâche, vous avez besoin d’un outil pour envoyer des appels d’API REST, par exemple :

• Visual Studio Code avec une extension de Visual Studio Marketplace
• Invoke-RestMethod de PowerShell
• Microsoft Edge - Outil console réseau
• Bruno
• curl

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'en 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 requête, en exécutant l'opération Workflows - Update à l'aide de la requête PUT suivante, par exemple :

   PUT 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, ajoutez 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.

Créer des URL de rappel qui expirent

Si vous décidez de partager l’URL d’un point de terminaison pour un déclencheur basé sur des requêtes, vous pouvez générer des URL de rappel qui utilisent des clés et pour lesquelles des dates d’expiration ont été configurées. De cette façon, vous pouvez facilement restaurer les clés ou restreindre l’accès au déclenchement de votre application logique selon une période donnée. Si vous souhaitez spécifier une date d’expiration pour une URL, utilisez l’API REST Azure Logic Apps, par exemple :

POST /subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01

Dans le corps, ajoutez la propriété NotAfter en utilisant une chaîne de date JSON. Cette propriété retourne une URL de rappel qui est valide uniquement jusqu’à la date et l’heure NotAfter.

Créer des URL avec une clé de secret principale ou secondaire

Lorsque vous générez ou listez des URL de rappel pour des déclencheurs basés sur une requête, vous pouvez également spécifier la clé à utiliser pour signer l’URL. Pour générer une URL signée par une clé spécifique, utilisez l’API REST Azure Logic Apps, par exemple :

POST /subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01

Dans le corps, incluez la propriété KeyType en tant que Primary ou Secondary. Cette propriété retourne une URL signée par la clé de sécurité spécifiée.

Exposer votre flux de travail d’application logique avec Gestion des API Azure

Pour plus de protocoles d’authentification et d’options, envisagez d’exposer le flux de travail de votre application logique en tant qu’API à l’aide d’Azure API Management. Ce service fournit des fonctionnalités de surveillance, de sécurité, de stratégie et de documentation enrichies pour n’importe quel point de terminaison. Le service Gestion des API peut exposer un point de terminaison public ou privé pour votre application logique. Pour autoriser l’accès à ce point de terminaison, vous pouvez utiliser OAuth avec Microsoft Entra ID, un certificat client ou d’autres normes de sécurité. Lorsque Gestion des API reçoit une requête, le service envoie celle-ci à votre application logique, en effectuant également toutes les transformations ou restrictions nécessaires tout au long du processus. Pour permettre à l’API Management d’appeler le flux de travail de votre application logique, vous pouvez restreindre les adresses IP entrantes de votre application logique.

Pour plus d’informations, consultez la documentation suivante :

• En savoir plus sur la Gestion des API
• Protéger un back-end d’API web dans Gestion des API Azure en utilisant l’autorisation OAuth 2.0 avec Microsoft Entra ID
• Sécuriser les API à l’aide d’une authentification par certificat client dans Gestion des API
• Stratégies d’authentification dans Gestion des API

Limiter les adresses IP entrantes

En plus de la signature d’accès partagé (SAP), vous pouvez aussi restreindre spécifiquement les clients qui peuvent appeler le flux de travail de votre application logique. Par exemple, si vous gérez votre point de terminaison de requête avec Azure API Management, vous pouvez restreindre le flux de travail de votre application logique afin qu’il n'accepte que les requêtes qui proviennent de l’adresse IP de l’instance de service API Management que vous créez.

Quelles que soient les adresses IP que vous spécifiez, vous pouvez toujours exécuter un flux de travail d’application logique comportant un déclencheur basé sur des requêtes en utilisant l’opération Déclencheurs de flux de travail – Exécuter ou en utilisant la Gestion des API. Cependant, ce scénario nécessite encore une authentification auprès de l’API REST Azure. Tous les événements s’affichent dans le journal d’audit Azure. Veillez à définir les stratégies de contrôle d’accès en conséquence.

Pour restreindre les adresses IP entrantes pour le flux de travail de votre application logique, suivez les étapes correspondantes pour le portail Azure ou votre modèle Azure Resource Manager. Une plage d’adresses IP valide utilise ces formats : x.x.x.x/x ou x.x.x.x-x.x.x.x

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               <workflow-definition>
            },
            "parameters": {
            },
            "accessControl": {
               "triggers": {
                  "allowedCallerIpAddresses": []
               },
               "actions": {
                  "allowedCallerIpAddresses": []
               },
               // Optional
               "contents": {
                  "allowedCallerIpAddresses": []
               }
            },
            "endpointsConfiguration": {}
         }
      }
   ],
   "outputs": {}
}

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               <workflow-definition>
            },
            "parameters": {
            },
            "accessControl": {
               "triggers": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     }
                  ]
               },
               "actions": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     }
                  ]
               }
            },
            "endpointsConfiguration": {}
         }
      }
   ],
   "outputs": {}
}

{
   "type": "Microsoft.Web/sites/config",
   "apiVersion": "2022-09-01",
   "name": "[concat(parameters('sites_My_Standard_Logic_App_name'), '/web')]",
   "location": "West US",
   "dependsOn": [
      "[resourceId('Microsoft.Web/sites', parameters('sites_My_Standard_Logic_App_name'))]"
   ],
   "tags": {
      "hidden-link: /app-insights-resource-id": "/subscriptions/{subscriptionID}/resourceGroups/Standard-RG/providers/Microsoft.Insights/components/My-Standard-Logic-App"
   },
   "properties": {
      "numberOfWorkers": 1,
      "defaultDocuments": [
         "Default.htm",
         "Default.html",
         "Default.asp",
         "index.htm",
         "index.html",
         "iisstart.htm",
         "default.aspx",
         "index.php"
      ],
      "netFrameworkVersion": "v6.0",
      "requestTracingEnabled": false,
      "remoteDebuggingEnabled": false,
      "httpLoggingEnabled": false,
      "acrUseManagedIdentityCreds": false,
      "logsDirectorySizeLimit": 35,
      "detailedErrorLoggingEnabled": false,
      "publishingUsername": "$My-Standard-Logic-App",
      "scmType": "None",
      "use32BitWorkerProcess": false,
      "webSocketsEnabled": false,
      "alwaysOn": false,
      "managedPipelineMode": "Integrated",
      "virtualApplications": [
         {
            "virtualPath": "/",
            "physicalPath": "site\\wwwroot",
            "preloadEnabled": false
         }
      ],
      "loadBalancing": "LeastRequests",
      "experiments": {
         "rampUpRules": []
      },
      "autoHealEnabled": false,
      "vnetRouteAllEnabled": false,
      "vnetPrivatePortsCount": 0,
      "publicNetworkAccess": "Enabled",
      "cors": {
         "supportCredentials": false
      },
      "localMySqlEnabled": false,
      "managedServiceIdentityId": 3065,
      "ipSecurityRestrictions": [
         {
            "ipAddress": "208.130.0.0/16",
            "action": "Deny",
            "tag": "Default",
            "priority": 100,
            "name": "Ports"
         },
         {
            "ipAddress": "Any",
            "action": "Deny",
            "priority": 2147483647,
            "name": "Deny all",
            "description": "Deny all access"
         }
      ],
      "ipSecurityRestrictionsDefaultAction": "Deny",
      "scmIpSecurityRestrictions": [
         {
            "ipAddress": "Any",
            "action": "Allow",
            "priority": 2147483647,
            "name": "Allow all",
            "description": "Allow all access"
         }
      ],
      "scmIpSecurityRestrictionsDefaultAction": "Allow",
      "scmIpSecurityRestrictionsUseMain": false,
      "http20Enabled": false,
      "minTlsVersion": "1.2",
      "scmMinTlsVersion": "1.2",
      "ftpsState": "FtpsOnly",
      "preWarmedInstanceCount": 1,
      "functionAppScaleLimit": 0,
      "functionsRuntimeScaleMonitoringEnabled": true,
      "minimumElasticInstanceCount": 1,
      "azureStorageAccounts": {}
   }
},

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 :

  • Authentification de base

  • Authentification par certificat client

  • Authentification Active Directory OAuth (OAuth 2.0 avec Microsoft Entra ID)

  • Authentification d’une identité managée

• 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 :

       

    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.

       

    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.

       

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.

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.

Si l’option Essentiel est disponible et sélectionnée, spécifiez les valeurs de propriété suivantes :

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

Si l’option Certificat client est disponible et sélectionnée, spécifiez ces valeurs de propriété :

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": {}
}

Pour plus d’informations sur la sécurisation des services à l’aide de l’authentification par certificat client, consultez les rubriques suivantes :

• Améliorer la sécurité des API à l’aide de l’authentification par certificat client dans Gestion des API Azure
• Améliorer la sécurité des services back-end à l’aide de l’authentification par certificat client dans Gestion des API Azure
• Améliorer la sécurité de votre service RESTful à l’aide de certificats clients
• Informations d’identification de certificat pour l’authentification d’application
• Utiliser un certificat TLS/SSL dans votre code dans Azure App Service

Plateforme Microsoft Entra

Sur le déclencheur Requête, vous pouvez utiliser la plateforme Microsoft Entra pour authentifier les appels entrants après avoir configuré des stratégies d’autorisation Microsoft Entra pour votre application logique.

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 :

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": {}
}

Authentification brute

Si l’option Brut est disponible, vous pouvez utiliser ce type d’authentification lorsque vous devez utiliser des schémas d’authentification qui ne suivent pas le protocole OAuth 2.0. Avec ce type, vous créez manuellement la valeur d’en-tête d’autorisation que vous envoyez avec la demande sortante, puis vous spécifiez cette valeur d’en-tête dans votre déclencheur ou action.

Voici un exemple d’en-tête pour une requête HTTPS qui suit le protocole OAuth 1.0 :

Authorization: OAuth realm="Photos",
   oauth_consumer_key="dpf43f3p2l4k3l03",
   oauth_signature_method="HMAC-SHA1",
   oauth_timestamp="137131200",
   oauth_nonce="wIjqoS",
   oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
   oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"

Dans le déclencheur ou l’action qui prend en charge l’authentification brute, spécifiez les valeurs de propriétés suivantes :

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

• Vous pouvez utiliser Azure Logic Apps dans Azure Government, qui prend en charge tous les niveaux d’impact dans les régions décrites par les Conseils d’isolation pour le niveau d’impact 5 Azure Government. Pour répondre à ces exigences, Azure Logic Apps gère la possibilité de créer et d’exécuter des flux de travail dans un environnement comportant des ressources dédiées, ce qui vous permet de réduire l’impact sur les performances d’autres locataires Azure sur vos applications logiques et d’éviter de partager des ressources de calcul avec d’autres locataires.

• Les workflows d’application logique Standard peuvent communiquer en privé et en toute sécurité avec un réseau virtuel Azure par le biais de points de terminaison privés configurés pour le trafic entrant et de l’intégration de réseau virtuel pour le trafic sortant. Pour plus d’informations, consultez Sécuriser le trafic entre réseaux virtuels et monolocataires dans Azure Logic Apps à l’aide de points de terminaison privés.

• Pour exécuter votre propre code ou effectuer une transformation XML, créez et appelez une fonction Azure, au lieu respectivement d’utiliser la fonctionnalité de code inline ou de fournir des assemblys à utiliser comme mappages. En outre, configurez l’environnement d’hébergement de votre application de fonction de façon à respecter vos exigences d’isolation.

  Par exemple, pour répondre aux exigences du niveau d’impact 5, créez votre application de fonction avec le plan App Service suivant le niveau tarifaire isolé, ainsi qu’un environnement ASE (App Service Environment) qui utilise également le niveau tarifaire Isolé. Dans cet environnement, les applications de fonction s’exécutent sur des machines virtuelles et des réseaux virtuels Azure dédiés, ce qui assure à vos applications l’isolement réseau en plus de l’isolation du calcul, ainsi que des capacités de Scale-out maximales.

  Pour plus d’informations, consultez la documentation suivante :

  • Plans Azure App Service
  • Options de mise en réseau d’Azure Functions
  • Azure Dedicated Host pour les machines virtuelles
  • Isolation des machines virtuelles dans Azure
  • Déploiement de services Azure dédiés dans des réseaux virtuels

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

• Isolation dans le cloud public Azure
• Sécurité des applications IaaS hautement sensibles dans Azure

Contenu connexe

• Base de référence de sécurité Azure pour Azure Logic Apps
• Automatiser le déploiement pour le service Azure Logic Apps
• Surveiller les applications logiques