Säker åtkomst och data för arbetsflöden i Azure Logic Apps

Azure Logic Apps förlitar sig på Azure Storage för att lagra och automatiskt kryptera vilande data. Krypteringen skyddar dina data och hjälper dig att uppfylla organisationens säkerhets- och efterlevnadsåtaganden. Som standard använder Azure Storage Microsoft-hanterade nycklar till datakrypteringen. Mer information finns i Azure Storage-kryptering för vilande data.

För att ytterligare kontrollera åtkomst och skydda känsliga data i Azure Logic Apps kan du konfigurera högre säkerhet inom följande områden:

• Åtkomst till logikappsåtgärder
• Åtkomst till indata och utdata för körningshistorik
• Åtkomst till parameterindata
• Autentiseringstyper för utlösare och åtgärder som stöder autentisering
• Åtkomst för inkommande anrop till begärandebaserade utlösare
• Åtkomst för utgående anrop till andra tjänster och system
• Blockera skapande av anslutningar för specifika anslutningsappar
• Isoleringsvägledning för logikappar
• Azure-säkerhetsbaslinje för Azure Logic Apps

Mer information om säkerhet i Azure finns i följande avsnitt:

• Översikt över Azure-kryptering
• Azure-datakryptering i vila
• Microsoft Cloud Security Benchmark

Åtkomst till logikappsåtgärder

Endast för förbrukningslogikappar behöver du specifika behörigheter som tillhandahålls via roller med rollbaserad åtkomstkontroll (Azure RBAC) innan du kan skapa eller hantera logikappar och deras anslutningar. Du kan också konfigurera behörigheter så att endast specifika användare eller grupper kan köra specifika uppgifter, till exempel att hantera, redigera och visa logikappar. Om du vill styra deras behörigheter kan du tilldela inbyggda eller anpassade roller till medlemmar som har åtkomst till din Azure-prenumeration. Azure Logic Apps har följande specifika roller, baserat på om du har ett arbetsflöde för förbrukning eller standardlogikapp:

Förbrukningsarbetsflöden

Anta till exempel att du måste arbeta med ett logikapparbetsflöde som du inte har skapat och autentiserat anslutningar som används av logikappens arbetsflöde. Din Azure-prenumeration kräver deltagarbehörigheter för resursgruppen som innehåller den logikappresursen. Om du skapar en logikappresurs har du automatiskt deltagaråtkomst.

Om du vill förhindra att andra ändrar eller tar bort arbetsflödet för logikappen kan du använda Azure Resource Lock. Den här funktionen hindrar andra från att ändra eller ta bort produktionsresurser. Mer information om anslutningssäkerhet finns i Anslutningskonfiguration i Azure Logic Apps och Anslutningssäkerhet och kryptering.

Standardarbetsflöden

Åtkomst till körningshistorikdata

Under en logikappskörning krypteras alla data under överföringen med hjälp av TLS (Transport Layer Security) och i vila. När logikappen är klar kan du visa historiken för den körningen, inklusive de steg som kördes tillsammans med status, varaktighet, indata och utdata för varje åtgärd. Den här detaljerade informationen ger insikt i hur logikappen kördes och var du kan börja felsöka eventuella problem som uppstår.

När du visar logikappens körningshistorik autentiserar Azure Logic Apps din åtkomst och tillhandahåller sedan länkar till indata och utdata för begäranden och svar för varje körning. För åtgärder som hanterar lösenord, hemligheter, nycklar eller annan känslig information vill du dock förhindra att andra visar och kommer åt dessa data. Om logikappen till exempel får en hemlighet från Azure Key Vault att använda när du autentiserar en HTTP-åtgärd, vill du dölja hemligheten från vyn.

Om du vill styra åtkomsten till indata och utdata i logikappens körningshistorik har du följande alternativ:

• Begränsa åtkomsten efter IP-adressintervall.

  Det här alternativet hjälper dig att skydda åtkomsten till körningshistoriken baserat på begäranden från ett specifikt IP-adressintervall.

• Skydda data i körningshistoriken med hjälp av fördunkling.

  I många utlösare och åtgärder kan du skydda indata, utdata eller båda i en logikapps körningshistorik.

Begränsa åtkomsten efter IP-adressintervall

Du kan begränsa åtkomsten till indata och utdata i körningshistoriken för logikappens arbetsflöden så att endast begäranden från specifika IP-adressintervall kan visa dessa data.

Om du till exempel vill blockera alla från att komma åt indata och utdata anger du ett IP-adressintervall, 0.0.0.0-0.0.0.0till exempel . Endast en person med administratörsbehörighet kan ta bort den här begränsningen, vilket ger möjlighet till "just-in-time"-åtkomst till data i logikappens arbetsflöden. Ett giltigt IP-intervall använder följande format: x.x.x.x/x eller x.x.x.x.x.x.x.x.x

Om du vill ange tillåtna IP-intervall följer du de här stegen för din förbruknings- eller standardlogikapp i Azure Portal eller din Azure Resource Manager-mall:

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

Skydda data i körningshistoriken med hjälp av obfuscation

Många utlösare och åtgärder har inställningar för att skydda indata, utdata eller båda från en logikapps körningshistorik. Alla hanterade anslutningsappar och anpassade anslutningsappar stöder dessa alternativ. Följande inbyggda åtgärder stöder dock inte följande alternativ:

Överväganden för att skydda indata och utdata

Innan du använder de här inställningarna för att skydda dessa data bör du läsa följande överväganden:

• När du skymmer indata eller utdata på en utlösare eller åtgärd skickar Inte Azure Logic Apps skyddade data till Azure Log Analytics. Du kan inte heller lägga till spårade egenskaper till utlösaren eller åtgärden för övervakning.

• Azure Logic Apps API för hantering av arbetsflödeshistorik returnerar inte skyddade utdata.

• Om du vill skydda utdata från en åtgärd som döljer indata eller uttryckligen döljer utdata aktiverar du säkra utdata manuellt i den åtgärden.

• Se till att du aktiverar Säkra indata eller Säkra utdata i underordnade åtgärder där du förväntar dig att körningshistoriken skymmer dessa data.

  Inställning för säkra utdata

  När du aktiverar säkra utdata manuellt i en utlösare eller åtgärd döljer Azure Logic Apps dessa utdata i körningshistoriken. Om en nedströmsåtgärd uttryckligen använder dessa skyddade utdata som indata döljer Azure Logic Apps den här åtgärdens indata i körningshistoriken, men aktiverar inte åtgärdens inställning för säkra indata .

  

  Åtgärderna Compose, Parse JSON och Response har endast inställningen Säkra indata . När inställningen är aktiverad döljer den även dessa åtgärders utdata. Om dessa åtgärder uttryckligen använder uppströms skyddade utdata som indata döljer Azure Logic Apps dessa åtgärders indata och utdata, men aktiverar inte de här åtgärdernas inställning för säkra indata . Om en nedströmsåtgärd uttryckligen använder dolda utdata från åtgärderna Skriv, Parsa JSON eller Svar som indata döljer Inte Azure Logic Apps den här underordnade åtgärdens indata eller utdata.

  

  Inställning för säkra indata

  När du aktiverar säkra indata manuellt i en utlösare eller åtgärd döljer Azure Logic Apps dessa indata i körningshistoriken. Om en nedströmsåtgärd uttryckligen använder synliga utdata från utlösaren eller åtgärden som indata döljer Azure Logic Apps den här underordnade åtgärdens indata i körningshistoriken, men aktiverar inte säkra indata i den här åtgärden och döljer inte den här åtgärdens utdata.

  

  Om åtgärderna Skriv, Parsa JSON och Svar uttryckligen använder synliga utdata från utlösaren eller åtgärden som har säkra indata döljer Azure Logic Apps de här åtgärdernas indata och utdata, men aktiverar inte den här åtgärdens inställning för säkra indata . Om en nedströmsåtgärd uttryckligen använder dolda utdata från åtgärderna Skriv, Parsa JSON eller Svar som indata döljer Inte Azure Logic Apps den här underordnade åtgärdens indata eller utdata.

  

Skydda indata och utdata i designern

1. Öppna arbetsflödet för logikappen i designern i Azure Portal.

2. I designern väljer du utlösaren eller åtgärden där du vill skydda känsliga data.

3. I informationsfönstret som öppnas väljer du Inställningar och expanderar Säkerhet.

   

4. Aktivera antingen Säkra indata, Säkra utdata eller båda.

   

   Utlösaren eller åtgärden visar nu en låsikon i namnlisten. Alla token som representerar skyddade utdata från tidigare åtgärder visar även låsikoner. I en efterföljande åtgärd visas till exempel en låsikon när du har valt en token för säkra utdata från listan med dynamiskt innehåll.

   

5. När arbetsflödet har körts kan du visa historiken för den körningen.

   1. Välj Översikt antingen på menyn Förbrukningslogikapp eller på standardarbetsflödesmenyn.

   2. Under Körningshistorik väljer du den körning som du vill visa.

   3. I fönstret för arbetsflödeskörningshistorik väljer du de åtgärder som du vill granska.

      Om du väljer att dölja både indata och utdata visas dessa värden nu dolda.

      

Skydda indata och utdata i kodvyn

I den underliggande utlösaren eller åtgärdsdefinitionen lägger du till eller uppdaterar matrisen runtimeConfiguration.secureData.properties med något av eller båda dessa värden:

• "inputs": Skyddar indata i körningshistoriken.
• "outputs": Skyddar utdata i körningshistoriken.

"<trigger-or-action-name>": {
   "type": "<trigger-or-action-type>",
   "inputs": {
      <trigger-or-action-inputs>
   },
   "runtimeConfiguration": {
      "secureData": {
         "properties": [
            "inputs",
            "outputs"
         ]
      }
   },
   <other-attributes>
}

Åtkomst till parameterindata

Om du distribuerar i olika miljöer kan du överväga att parameterisera värdena i arbetsflödesdefinitionen som varierar beroende på dessa miljöer. På så sätt kan du undvika hårdkodade data med hjälp av en Azure Resource Manager-mall för att distribuera logikappen, skydda känsliga data genom att definiera skyddade parametrar och skicka dessa data som separata indata via mallens parametrar med hjälp av en parameterfil.

Om du till exempel autentiserar HTTP-åtgärder med OAuth med Microsoft Entra-ID kan du definiera och dölja de parametrar som accepterar klient-ID och klienthemlighet som används för autentisering. Om du vill definiera dessa parametrar i logikappens arbetsflöde använder du avsnittet i logikappens parameters arbetsflödesdefinition och Resource Manager-mall för distribution. För att skydda parametervärden som du inte vill ska visas när du redigerar logikappen eller visar körningshistoriken definierar du parametrarna med hjälp securestring av eller secureobject skriver och använder kodning efter behov. Parametrar som har den här typen returneras inte med resursdefinitionen och är inte tillgängliga när du visar resursen efter distributionen. Om du vill komma åt dessa parametervärden under körningen använder du uttrycket i arbetsflödesdefinitionen @parameters('<parameter-name>') . Det här uttrycket utvärderas endast vid körning och beskrivs av arbetsflödets definitionsspråk.

Mer information finns i de här avsnitten i det här avsnittet:

• Säkra parametrar i arbetsflödesdefinitioner
• Skydda data i körningshistoriken med hjälp av obfuscation

Om du automatiserar distributionen för logikappar med hjälp av Resource Manager-mallar kan du definiera skyddade mallparametrar som utvärderas vid distributionen med hjälp av typerna securestring och secureobject . Om du vill definiera mallparametrar använder du mallens avsnitt på den översta nivån parameters , som är separat och skiljer sig från arbetsflödesdefinitionens parameters avsnitt. Om du vill ange värden för mallparametrar använder du en separat parameterfil.

Om du till exempel använder hemligheter kan du definiera och använda skyddade mallparametrar som hämtar dessa hemligheter från Azure Key Vault vid distributionen. Du kan sedan referera till nyckelvalvet och hemligheten i parameterfilen. Mer information finns i följande avsnitt:

• Skicka känsliga värden vid distribution med hjälp av Azure Key Vault
• Säkra parametrar i Azure Resource Manager-mallar senare i det här avsnittet

Säkra parametrar i arbetsflödesdefinitioner (förbrukningsarbetsflöde)

Om du vill skydda känslig information i logikappens arbetsflödesdefinition använder du skyddade parametrar så att den här informationen inte visas när du har sparat arbetsflödet för logikappen. Anta till exempel att du har en HTTP-åtgärd som kräver grundläggande autentisering, som använder ett användarnamn och lösenord. I arbetsflödesdefinitionen parameters definierar avsnittet parametrarna basicAuthPasswordParam och basicAuthUsernameParam med hjälp securestring av typen . Åtgärdsdefinitionen refererar sedan till dessa parametrar i avsnittet 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": {}
}

Säkra parametrar i Azure Resource Manager-mallar (arbetsflöde för förbrukning)

En Resource Manager-mall för en logikappresurs och ett arbetsflöde har flera parameters avsnitt. För att skydda lösenord, nycklar, hemligheter och annan känslig information definierar du skyddade parametrar på mallnivå och arbetsflödesdefinitionsnivå med hjälp securestring av eller-typen secureobject . Du kan sedan lagra dessa värden i Azure Key Vault och använda parameterfilen för att referera till nyckelvalvet och hemligheten. Mallen hämtar sedan den informationen vid distributionen. Mer information finns i Skicka känsliga värden vid distribution med hjälp av Azure Key Vault.

Den här listan innehåller mer information om dessa parameters avsnitt:

• På mallens översta nivå definierar ett parameters avsnitt parametrarna för de värden som mallen använder vid distributionen. Dessa värden kan till exempel innehålla anslutningssträng för en specifik distributionsmiljö. Du kan sedan lagra dessa värden i en separat parameterfil, vilket gör det enklare att ändra dessa värden.

• I logikappens resursdefinition, men utanför arbetsflödesdefinitionen, anger ett parameters avsnitt värdena för arbetsflödesdefinitionens parametrar. I det här avsnittet kan du tilldela dessa värden med hjälp av malluttryck som refererar till mallens parametrar. Dessa uttryck utvärderas vid distributionen.

• I arbetsflödesdefinitionen definierar ett parameters avsnitt de parametrar som logikappens arbetsflöde använder vid körning. Du kan sedan referera till dessa parametrar i logikappens arbetsflöde med hjälp av arbetsflödesdefinitionsuttryck som utvärderas vid körning.

Den här exempelmallen som har flera skyddade parameterdefinitioner som använder typen 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": {}
}

Autentiseringstyper för anslutningsappar som har stöd för autentisering

I följande tabell identifieras de autentiseringstyper som är tillgängliga i anslutningsåtgärderna där du kan välja en autentiseringstyp:

Åtkomst för inkommande anrop till begärandebaserade utlösare

Inkommande anrop som en logikapp tar emot via en begäransbaserad utlösare, till exempel utlösare för begäran eller HTTP Webhook-utlösare, stöder kryptering och skyddas med TLS (Transport Layer Security) 1.2 som minimum, tidigare kallat Secure Sockets Layer (SSL). Azure Logic Apps tillämpar den här versionen när du tar emot ett inkommande anrop till en begäransutlösare eller ett återanrop till HTTP Webhook-utlösaren eller åtgärden.

Använd följande chiffersviter för inkommande anrop:

• 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

I följande lista finns olika sätt att begränsa åtkomsten till utlösare som tar emot inkommande anrop till logikappens arbetsflöde så att endast behöriga klienter kan anropa arbetsflödet:

• Aktivera OAuth med Microsoft Entra-ID
• Generera sas-nycklar eller token (signatur för delad åtkomst)
• Inaktivera sas-autentisering (signatur för delad åtkomst)
• Begränsa inkommande IP-adresser
• Exponera logikappen med Azure API Management

Aktivera OAuth 2.0 med Microsoft Entra-ID

I ett förbrukningsarbetsflöde som börjar med en begäransbaserad utlösare kan du autentisera och auktorisera inkommande anrop som skickas till slutpunkten som skapats av utlösaren genom att aktivera OAuth 2.0 med Microsoft Entra-ID. Om du vill konfigurera den här autentiseringen definierar eller lägger du till en auktoriseringsprincip på logikappens resursnivå. På så sätt använder inkommande anrop OAuth-åtkomsttoken för auktorisering.

När logikappens arbetsflöde tar emot en inkommande begäran som innehåller en OAuth-åtkomsttoken jämför Azure Logic Apps tokens anspråk mot de anspråk som anges av varje auktoriseringsprincip. Om det finns en matchning mellan tokens anspråk och alla anspråk i minst en princip lyckas auktoriseringen för den inkommande begäran. Token kan ha fler anspråk än det nummer som anges av auktoriseringsprincipen.

I ett Standard-arbetsflöde som börjar med utlösaren Förfrågning (men inte en webhook-utlösare) kan du använda Azure Functions-etableringen för att autentisera inkommande anrop som skickas till slutpunkten som skapats av begärandeutlösaren med hjälp av en hanterad identitet. Den här etableringen kallas även "Easy Auth". Mer information finns i Utlösa arbetsflöden i Standard-logikappar med Easy Auth.

Överväganden innan du aktiverar OAuth 2.0 med Microsoft Entra-ID

• För optimal säkerhet rekommenderar Microsoft att du använder Microsoft Entra-ID med hanterade identiteter för autentisering när det är möjligt. Det här alternativet ger överlägsen säkerhet utan att behöva ange autentiseringsuppgifter. Azure hanterar den här identiteten och hjälper till att skydda autentiseringsinformationen så att du inte behöver hantera den här känsliga informationen. Information om hur du konfigurerar en hanterad identitet för Azure Logic Apps finns i Autentisera åtkomst och anslutningar till Azure-resurser med hanterade identiteter i Azure Logic Apps.

• I arbetsflöden för förbrukning kan inkommande anrop till slutpunkts-URL:en för en begäransbaserad utlösare endast använda ett auktoriseringsschema, antingen OAuth 2.0 med Microsoft Entra-ID eller signatur för delad åtkomst (SAS). Om du använder ett schema inaktiveras inte det andra schemat, men om du använder båda schemana samtidigt genererar Azure Logic Apps ett fel eftersom tjänsten inte vet vilket schema som ska väljas. Om ditt förbrukningsarbetsflöde börjar med utlösaren Förfrågning kan du inaktivera SAS-autentisering och begränsa auktoriseringen till att endast använda OAuth 2.0 med Microsoft Entra-ID. För Standard-arbetsflöden kan du använda andra autentiseringstyper utan att inaktivera SAS.

• Azure Logic Apps stöder antingen auktoriseringsscheman för innehavartyp eller innehavsbevis (endast förbrukningslogikapp) för Microsoft Entra ID OAuth-åtkomsttoken. Huvudet för åtkomsttoken måste dock Authorization ange antingen Bearer typ eller PoP typ. Mer information om hur du hämtar och använder en PoP-token finns i Hämta en PoP-token (Proof of Possession).

• Din förbrukningslogikappresurs är begränsad till ett maximalt antal auktoriseringsprinciper. Varje auktoriseringsprincip har också ett maximalt antal anspråk. Mer information finns i Gränser och konfiguration för Azure Logic Apps.

• En auktoriseringsprincip måste innehålla minst utfärdaranspråket, som har ett värde som börjar med antingen https://sts.windows.net/ eller https://login.microsoftonline.com/ (OAuth V2) som utfärdare för Microsoft Entra-ID.

  Anta till exempel att logikappresursen har en auktoriseringsprincip som kräver två anspråkstyper, Målgrupp och Utfärdare. Det här exempelnyttolastavsnittet för en avkodad åtkomsttoken innehåller båda anspråkstyperna där aud är målgruppsvärdet och iss är utfärdarvärdet:

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

Aktivera OAuth 2.0 med Microsoft Entra-ID som det enda alternativet för att anropa en slutpunkt för begäran (endast förbrukning)

För begärandebaserade slutpunkter kan du begränsa auktoriseringen till att endast använda OAuth 2.0 med Microsoft Entra-ID. Det här alternativet fungerar även om du även inaktiverar SAS-autentisering (signatur för delad åtkomst).

1. För ditt förbrukningsarbetsflöde konfigurerar du utlösaren för begäran eller HTTP Webhook med funktionen för att kontrollera OAuth-åtkomsttoken genom att följa stegen för att inkludera rubriken "Auktorisering" i utdata från request- eller HTTP webhook-utlösaren.

   Kommentar

   Det här steget gör Authorization huvudet synligt i arbetsflödets körningshistorik och i utlösarens utdata.

2. Öppna arbetsflödet Förbrukning i designern i Azure Portal.

3. Välj utlösaren i designern. I informationsfönstret som öppnas väljer du Inställningar.

4. Under Allmänna>utlösarvillkor väljer du Lägg till. I rutan för utlösarvillkor anger du något av följande uttryck, baserat på den tokentyp som du vill använda:

   @startsWith(triggerOutputs()?['headers']?['Authorization'], 'Bearer')

   -eller-

   @startsWith(triggerOutputs()?['headers']?['Authorization'], 'PoP')

Om du anropar utlösarslutpunkten utan rätt auktorisering visar körningshistoriken bara utlösaren som Skipped utan något meddelande om att utlösarvillkoret har misslyckats.

Hämta en PoP-token (Proof-of-Possession)

MsAL-bibliotek (Microsoft Authentication Library) tillhandahåller PoP-token som du kan använda. Om arbetsflödet för logikappen Förbrukning som du vill anropa kräver en PoP-token kan du hämta den här token med hjälp av MSAL-biblioteken. Följande exempel visar hur du hämtar PoP-token:

• Ett .NET Core-daemonkonsolprogram som anropar ett skyddat webb-API med en egen identitet

• SignedHttpRequest, även känd som PoP (Proof of Possession)

Om du vill använda PoP-token med arbetsflödet för förbrukningslogiken följer du stegen för att konfigurera OAuth med Microsoft Entra-ID.

Aktivera OAuth med Microsoft Entra-ID för din förbrukningslogikappresurs

Om du vill lägga till en auktoriseringsprincip i din förbrukningslogikapp följer du stegen för antingen mallen Azure Portal eller 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
],

Inkludera auktoriseringshuvud i utdata för begärande- eller HTTP-webhook-utlösare

För logikappar som aktiverar OAuth med Microsoft Entra-ID för att auktorisera inkommande anrop för åtkomst till begärandebaserade utlösare kan du aktivera utdata för utlösare för begäran eller HTTP Webhook-utlösare för att inkludera Authorization huvudet från OAuth-åtkomsttoken. I utlösarens underliggande JSON-definition lägger du till och anger operationOptions egenskapen till IncludeAuthorizationHeadersInOutputs. Här är ett exempel på utlösaren Förfrågning :

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

Mer information finns i följande avsnitt:

• Schemareferens för utlösare och åtgärdstyper – Utlösare för begäran
• Schemareferens för utlösare och åtgärdstyper – HTTP Webhook-utlösare
• Schemareferens för utlösar- och åtgärdstyper – Åtgärdsalternativ

Generera en SAS-nyckel (signatur för delad åtkomst) eller token

När ett arbetsflöde börjar med en begäransbaserad utlösare och du sparar arbetsflödet för första gången skapar Azure Logic Apps en anropsbar slutpunkt på utlösaren. Den här slutpunkten har en URL som kan ta emot inkommande anrop eller begäranden om att starta arbetsflödet. URL:en innehåller en signatur för delad åtkomst (SAS) som är en nyckel eller token som ger behörigheter, till exempel till lagringstjänster. Den här slutpunkts-URL:en använder följande format:

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

Om du till exempel vill visa den här URL:en i en begäransutlösare letar du reda på utlösarens HTTP URL-egenskap :

Den fullständiga URL:en ser ut som i följande exempel:

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

SAS i URL:en har frågeparametrar som beskrivs i följande tabell:

Inkommande anrop till slutpunkten på en begäransbaserad utlösare kan bara använda ett auktoriseringsschema, antingen SAS eller OAuth 2.0 med Microsoft Entra-ID. Om du använder det ena schemat inaktiveras inte det andra, men om du använder båda schemana samtidigt genererar Azure Logic Apps ett fel eftersom tjänsten inte vet vilket schema som ska väljas.

Om du har ett arbetsflöde för förbrukning som börjar med utlösaren Begäran kan du inaktivera SAS-autentisering. Det här alternativet fungerar även om du även begränsar auktoriseringen till att endast använda OAuth 2.0 med Microsoft Entra-ID. För Standard-arbetsflöden kan du använda andra autentiseringstyper utan att inaktivera SAS.

Mer information om säkerhet när du använder en SAS-nyckel finns i följande avsnitt i den här guiden:

• Återskapa åtkomstnycklar
• Skapa url:er för motringning som upphör att gälla
• Skapa URL:er med primär eller sekundär nyckel

Inaktivera sas-autentisering (signatur för delad åtkomst) (endast förbrukning)

Som standard har en begäransbaserad utlösare SAS-autentisering aktiverad. Utlösarens slutpunkts-URL innehåller en SAS, som börjar med frågeparametrarna, , sp-<permissions>sv-<SAS-version>sig=<signature>till exempel:

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

Om ditt förbrukningsarbetsflöde börjar med utlösaren Begäran och du vill använda OAuth med Microsoft Entra-ID kan du inaktivera SAS-autentisering för att undvika fel och problem med att köra arbetsflödet. Du lägger också till ett säkerhetslager genom att ta bort beroendet av hemligheter, vilket minskar risken för att hemligheter loggas eller läckas.

Det här alternativet fungerar även om du även aktiverar OAuth 2.0 med Microsoft Entra-ID som det enda alternativet för att anropa en begäransbaserad slutpunkt. För Standard-arbetsflöden kan du använda andra autentiseringstyper utan att inaktivera SAS.

När du har inaktiverat SAS-autentisering innehåller slutpunkts-URL:en för begärandeutlösaren inte längre SAS-nyckeln, till exempel:

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

Förutsättningar

För den här uppgiften behöver du ett verktyg för att skicka REST API-anrop, till exempel:

• Visual Studio Code med ett tillägg från Visual Studio Marketplace
• PowerShell Invoke-RestMethod
• Microsoft Edge – verktyg för nätverkskonsol
• Bruno
• hårlock

Sök efter utlösare med SAS aktiverat eller inaktiverat

När SAS-autentisering har inaktiverats innehåller utlösarens slutpunkts-URL inte LÄNGRE SAS-nyckeln. Arbetsflödesdefinitionen för förbrukning innehåller även JSON-objektet sasAuthenticationPolicy . Det här objektet har en tillståndsegenskap som är inställd på Inaktiverad, till exempel:

"properties": {
    "accessControl": {
        "triggers": {
            "sasAuthenticationPolicy": {
                "state": "Disabled"
            }
        }
    }
}

Om du vill hitta förbrukningsarbetsflöden där SAS antingen är aktiverat eller inaktiverat kontrollerar du om arbetsflödesdefinitionen innehåller objektet sasAuthenticationPolicy där tillståndsegenskapen är inställd på Inaktiverad.

1. Med verktyget som skickar REST API-anrop hämtar du information om arbetsflödet genom att köra åtgärden Arbetsflöden – Hämta med hjälp av följande GET-begäran, till exempel:

   GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

2. Ta utdata från åtgärden Arbetsflöden – Hämta och kontrollera om objektet sasAuthenticationPolicy finns där tillståndsegenskapen är inställd på Inaktiverad.

Lägg till egenskapen sasAuthenticationPolicy i arbetsflödesdefinitionen

Följ dessa steg för förbrukningsarbetsflöden där du vill inaktivera SAS-autentisering:

1. Om du inte redan har gjort det kan du hämta information om arbetsflödet genom att köra åtgärden Arbetsflöden – Hämta med hjälp av följande GET-begäran, till exempel:

   GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

2. Ta utdata från åtgärden Arbetsflöden – Hämta och lägg till följande element manuellt:

   1. I objektet properties lägger du till ett accessControl objekt som innehåller ett triggers objekt, om det inte finns något.

   2. triggers I objektet lägger du till ett sasAuthenticationPolicy objekt som innehåller egenskapen inställd på state Disabled.

   När du är klar ser den redigerade delen ut som i följande exempel:

   "properties": {
       "accessControl": {
           "triggers": {
               "sasAuthenticationPolicy": {
                   "state": "Disabled"
               }
           }
       }
   }
   

3. Skicka en annan begäran om att uppdatera arbetsflödet med de redigerade utdata som du använder som indata i begärandetexten genom att köra åtgärden Arbetsflöden – Uppdatering med hjälp av följande PATCH-begäran, till exempel:

   PATCH https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

4. I Azure Portal går du till ditt förbrukningsarbetsflöde i designern och bekräftar att URL:en för utlösaren för begäran inte längre innehåller SAS.

5. Om du vill aktivera Oauth 2.0 med Microsoft Entra-ID lägger du till en auktoriseringsprincip för OAuth med Microsoft Entra-ID på logikappens resursnivå.

   Mer information finns i Aktivera OAuth 2.0 med Microsoft Entra-ID.

Återskapa åtkomstnycklar

För att upprätthålla säkerheten och skydda åtkomsten till logikappens arbetsflöde återskapar du åtkomstnycklar enligt ett regelbundet schema eftersom de kan behöva följa säkerhetsprinciper eller komprometteras. På så sätt kan du se till att endast auktoriserade begäranden kan utlösa arbetsflödet, vilket skyddar dina data och processer från obehörig åtkomst.

Om du vill generera en ny åtkomstnyckel när som helst använder du Azure REST API eller Azure Portal. Alla tidigare genererade URL:er eller URL:er som använder den gamla nyckeln är ogiltiga och har inte längre behörighet att utlösa arbetsflödet för logikappen. DE URI:er som du hämtar efter regenereringen har signerats med den nya åtkomstnyckeln.

1. I Azure Portal öppnar du logikappresursen som använder nyckeln som du vill återskapa.

2. På resursmenyn för logikappen går du till Inställningar och väljer Åtkomstnycklar.

3. Välj den nyckel som du vill återskapa och slutföra processen.

Skapa url:er för motringning som upphör att gälla

Om du delar slutpunkts-URL:en för en begärandebaserad utlösare med andra parter kan du generera url:er för återanrop som använder specifika nycklar och har förfallodatum. På så sätt kan du sömlöst rulla nycklar eller begränsa åtkomsten till att utlösa logikappen baserat på ett visst tidsintervall. Om du vill ange ett förfallodatum för en URL använder du Rest-API:et för Azure Logic Apps, till exempel:

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

I brödtexten NotAfter tar du med egenskapen med hjälp av en JSON-datumsträng. Den här egenskapen returnerar en motringnings-URL som endast är giltig fram till NotAfter datum och tid.

Skapa URL:er med primär eller sekundär hemlig nyckel

När du genererar eller listar url:er för återanrop för en begärandebaserad utlösare kan du ange den nyckel som ska användas för att signera URL:en. Om du vill generera en URL som är signerad av en specifik nyckel använder du Rest-API:et för Azure Logic Apps, till exempel:

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

I brödtexten tar du KeyType med egenskapen som antingen Primary eller Secondary. Den här egenskapen returnerar en URL som är signerad av den angivna säkerhetsnyckeln.

Exponera arbetsflödet för logikappen med Azure API Management

Om du vill ha fler autentiseringsprotokoll och alternativ kan du överväga att exponera logikappens arbetsflöde som ett API med hjälp av Azure API Management. Den här tjänsten tillhandahåller omfattande funktioner för övervakning, säkerhet, princip och dokumentation för alla slutpunkter. API Management kan exponera en offentlig eller privat slutpunkt för din logikapp. Om du vill auktorisera åtkomst till den här slutpunkten kan du använda OAuth med Microsoft Entra-ID, klientcertifikat eller andra säkerhetsstandarder. När API Management tar emot en begäran skickar tjänsten begäran till logikappen och gör alla nödvändiga omvandlingar eller begränsningar längs vägen. Om du bara vill låta API Management anropa logikappens arbetsflöde kan du begränsa logikappens inkommande IP-adresser.

Mer information finns i följande dokumentation:

• Om API Management
• Skydda en webb-API-serverdel i Azure API Management med OAuth 2.0-auktorisering med Microsoft Entra-ID
• Skydda API:er med klientcertifikatautentisering i API Management
• Principer för API Management-autentisering

Begränsa inkommande IP-adresser

Tillsammans med signatur för delad åtkomst (SAS) kanske du specifikt vill begränsa de klienter som kan anropa logikappens arbetsflöde. Om du till exempel hanterar din slutpunkt för begäran med hjälp av Azure API Management kan du begränsa arbetsflödet för logikappen till att endast acceptera begäranden från IP-adressen för den API Management-tjänstinstans som du skapar.

Oavsett vilka IP-adresser du anger kan du fortfarande köra ett logikapparbetsflöde som har en begäransbaserad utlösare med hjälp av arbetsflödesutlösare – Kör åtgärdsbegäran eller med hjälp av API Management. Det här scenariot kräver dock fortfarande autentisering mot Azure REST API. Alla händelser visas i Azure-granskningsloggen. Kontrollera att du anger principer för åtkomstkontroll i enlighet med detta.

Om du vill begränsa inkommande IP-adresser för logikappens arbetsflöde följer du motsvarande steg för antingen Azure Portal eller din Azure Resource Manager-mall. Ett giltigt IP-intervall använder följande format: x.x.x.x/x eller x.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": {}
   }
},

Åtkomst för utgående anrop till andra tjänster och system

Baserat på målslutpunktens kapacitet stöder utgående anrop som skickas av HTTP-utlösaren eller HTTP-åtgärden kryptering och skyddas med TLS (Transport Layer Security) 1.0, 1.1 eller 1.2, som tidigare kallades Secure Sockets Layer (SSL). Azure Logic Apps förhandlar med målslutpunkten om att använda den högsta möjliga versionen som stöds. Om målslutpunkten till exempel stöder 1.2 använder HTTP-utlösaren eller åtgärden 1.2 först. Annars använder anslutningsappen den näst högsta versionen som stöds.

Den här listan innehåller information om självsignerade TLS/SSL-certifikat:

• För arbetsflöden för förbrukningslogikappar i Azure Logic Apps-miljön med flera klientorganisationer tillåter HTTP-åtgärder inte självsignerade TLS/SSL-certifikat. Om logikappen gör ett HTTP-anrop till en server och visar ett självsignerat TLS/SSL-certifikat misslyckas HTTP-anropet med ett TrustFailure fel.

• För standardarbetsflöden för logikappar i Azure Logic Apps-miljön med en enda klient stöder HTTP-åtgärder självsignerade TLS/SSL-certifikat. Du måste dock utföra några extra steg för den här autentiseringstypen. Annars misslyckas anropet. Mer information finns i TLS/SSL-certifikatautentisering för Azure Logic Apps med en klientorganisation.

  Om du vill använda klientcertifikat eller OAuth med Microsoft Entra-ID med certifikatautentiseringstypen i stället måste du fortfarande utföra några extra steg för den här autentiseringstypen. Annars misslyckas anropet. Mer information finns i Klientcertifikat eller OAuth med Microsoft Entra-ID med autentiseringstypen "Certifikat" för Azure Logic Apps med en enda klientorganisation.

Här är fler sätt att skydda slutpunkter som hanterar anrop som skickas från logikappens arbetsflöden:

• Lägg till autentisering i utgående begäranden.

  När du använder HTTP-utlösaren eller åtgärden för att skicka utgående anrop kan du lägga till autentisering i begäran som skickas av logikappen. Du kan till exempel välja dessa autentiseringstyper:

  • Grundläggande autentisering

  • Autentisering av klientcertifikat

  • Active Directory OAuth-autentisering (OAuth 2.0 med Microsoft Entra ID)

  • Hanterad identitetsautentisering

• Begränsa åtkomsten från IP-adresser för logikappens arbetsflöde.

  Alla anrop till slutpunkter från logikappens arbetsflöden kommer från specifika avsedda IP-adresser som baseras på dina logikappars regioner. Du kan lägga till filtrering som endast accepterar begäranden från dessa IP-adresser. Information om hur du hämtar dessa IP-adresser finns i Gränser och konfiguration för Azure Logic Apps.

• Förbättra säkerheten för anslutningar till lokala system.

  Azure Logic Apps tillhandahåller integrering med dessa tjänster för att ge säkrare och mer tillförlitlig lokal kommunikation.

  • Lokal datagateway

    Många hanterade anslutningsappar i Azure Logic Apps underlättar säkra anslutningar till lokala system, till exempel filsystem, SQL, SharePoint och DB2. Gatewayen skickar data från lokala källor i krypterade kanaler via Azure Service Bus. All trafik kommer från en skyddad utgående trafik från gatewayagenten. Lär dig hur den lokala datagatewayen fungerar.

  • Ansluta via Azure API Management

    Azure API Management tillhandahåller lokala anslutningsalternativ, till exempel virtuellt privat nätverk från plats till plats och ExpressRoute-integrering för säker proxy och kommunikation till lokala system. Om du har ett API som ger åtkomst till ditt lokala system och du exponerar API:et genom att skapa en API Management-tjänstinstans, kan du anropa api:et från logikappens arbetsflöde genom att välja motsvarande API Management-åtgärd i arbetsflödesdesignern.

    Kommentar

    Anslutningsappen visar endast de API Management-tjänster där du har behörighet att visa och ansluta, men som inte visar förbrukningsbaserade API Management-tjänster.

    Följ motsvarande steg baserat på resurstypen för logikappen:

    Förbrukningsarbetsflöden

    1. Baserat på om du lägger till en API Management-utlösare eller åtgärd följer du dessa steg:

       • Utlösare:

         1. I arbetsflödesdesignern väljer du Lägg till en utlösare.

         2. När fönstret Lägg till en utlösare öppnas anger du API Management i sökrutan.

         3. I listan med utlösarresultat väljer du Välj en Azure API Management-utlösare.

       • Åtgärd:

         1. I arbetsflödesdesignern väljer du plustecknet (+) där du vill lägga till åtgärden.

         2. När fönstret Lägg till en åtgärd öppnas anger du API Management i sökrutan.

         3. I listan med åtgärdsresultat väljer du Välj en Azure API Management-åtgärd.

       I följande exempel visas hur du hittar en Azure API Management-utlösare:

       

    2. Välj din tidigare skapade API Management-tjänstinstans i listan API Management-tjänstinstans.

    3. I listan ÖVER API-åtgärder väljer du den API-åtgärd som ska anropas och väljer sedan Lägg till åtgärd.

    Standardarbetsflöden

    För Standard-arbetsflöden kan du bara lägga till API Management-åtgärder , inte utlösare.

    1. I arbetsflödesdesignern väljer du plustecknet (+) där du vill lägga till åtgärden.

    2. När fönstret Lägg till en åtgärd öppnas anger du API Management i sökrutan.

    3. I listan med åtgärdsresultat väljer du Anropa ett Azure API Management API.

       

    4. Välj din tidigare skapade API Management-tjänstinstans i listan API Management-tjänstinstans.

    5. I listan API-åtgärder väljer du den API-åtgärd som ska anropas och väljer sedan Skapa ny.

       

Lägga till autentisering i utgående anrop

HTTP- och HTTPS-slutpunkter stöder olika typer av autentisering. På vissa utlösare och åtgärder som du använder för att skicka utgående anrop eller begäranden till dessa slutpunkter kan du ange en autentiseringstyp. I arbetsflödesdesignern har utlösare och åtgärder som stöder val av autentiseringstyp en autentiseringsegenskap . Den här egenskapen kanske dock inte alltid visas som standard. I dessa fall öppnar du listan Avancerade parametrar i utlösaren eller åtgärden och väljer Autentisering.

Grundläggande autentisering

För HTTP-anrop använder grundläggande autentisering en base64-kodad sträng som innehåller ett användarnamn och lösenord för att göra en begäran. Den här metoden överför autentiseringsuppgifter utan kryptering och medför ökade säkerhetsrisker om du inte använder det här alternativet med HTTPS/SSL-protokollet.

Om alternativet Basic är tillgängligt och valt anger du följande egenskapsvärden:

När du använder skyddade parametrar för att hantera och skydda känslig information, till exempel i en Azure Resource Manager-mall för att automatisera distributionen, kan du använda uttryck för att komma åt dessa parametervärden vid körning. I det här exemplet anger HTTP-åtgärdsdefinitionen autentiseringen type som Basic och använder funktionen parameters() för att hämta parametervärdena:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "Basic",
         "username": "@parameters('userNameParam')",
         "password": "@parameters('passwordParam')"
      }
  },
  "runAfter": {}
}

Autentisering med klientcertifikat

Klientcertifikatautentisering tillåter eller kräver att användarna autentiserar direkt med X.509-certifikat mot sitt Microsoft Entra-ID för program och webbläsarinloggning. Den här funktionen hjälper dig att använda en nätfiskebeständig autentisering och autentisera med ett X.509-certifikat mot din offentliga nyckelinfrastruktur (PKI).

Om alternativet Klientcertifikat är tillgängligt och valt anger du följande egenskapsvärden:

När du använder skyddade parametrar för att hantera och skydda känslig information, till exempel i en Azure Resource Manager-mall för att automatisera distributionen, kan du använda uttryck för att komma åt dessa parametervärden vid körning. I det här exemplet anger HTTP-åtgärdsdefinitionen autentiseringen type som ClientCertificate och använder funktionen parameters() för att hämta parametervärdena:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ClientCertificate",
         "pfx": "@parameters('pfxParam')",
         "password": "@parameters('passwordParam')"
      }
   },
   "runAfter": {}
}

Mer information om hur du skyddar tjänster med hjälp av klientcertifikatautentisering finns i följande avsnitt:

• Förbättra säkerheten för API:er med hjälp av klientcertifikatautentisering i Azure API Management
• Förbättra säkerheten för serverdelstjänster med hjälp av klientcertifikatautentisering i Azure API Management
• Förbättra säkerheten för din RESTfuL-tjänst med hjälp av klientcertifikat
• Certifikatautentiseringsuppgifter för programautentisering
• Använda ett TLS-/SSL-certifikat i koden i Azure App Service

Microsoft Entra-plattform

På begärandeutlösaren kan du använda Microsoft Entra-plattformen för att autentisera inkommande samtal när du har konfigurerat Microsoft Entra-auktoriseringsprinciper för din logikapp.

För alla andra utlösare och åtgärder som stöder autentiseringstypen Active Directory OAuth (OAuth 2.0 med Microsoft Entra ID) anger du följande egenskapsvärden:

När du använder skyddade parametrar för att hantera och skydda känslig information, till exempel i en Azure Resource Manager-mall för att automatisera distributionen, kan du använda uttryck för att komma åt dessa parametervärden vid körning. I det här exemplet anger HTTP-åtgärdsdefinitionen autentiseringen type som ActiveDirectoryOAuth, typ av autentiseringsuppgifter som Secretoch använder funktionen parameters() för att hämta parametervärdena:

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

Råautentisering

Om alternativet Rådata är tillgängligt kan du använda den här autentiseringstypen när du måste använda autentiseringsscheman som inte följer OAuth 2.0-protokollet. Med den här typen skapar du manuellt det auktoriseringshuvudvärde som du skickar med den utgående begäran och anger det rubrikvärdet i utlösaren eller åtgärden.

I följande exempel visas ett exempelhuvud för en HTTPS-begäran som följer OAuth 1.0-protokollet:

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"

I utlösaren eller åtgärden som stöder råautentisering anger du följande egenskapsvärden:

När du använder skyddade parametrar för att hantera och skydda känslig information, till exempel i en Azure Resource Manager-mall för att automatisera distributionen, kan du använda uttryck för att komma åt dessa parametervärden vid körning. I det här exemplet anger HTTP-åtgärdsdefinitionen autentiseringen type som Rawoch använder funktionen parameters() för att hämta parametervärdena:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "Raw",
         "value": "@parameters('authHeaderParam')"
      }
   },
   "runAfter": {}
}

Autentisering av hanterad identitet

När alternativet hanterad identitet är tillgängligt för utlösaren eller åtgärden som stöder hanterad identitetsautentisering kan logikappen använda den här identiteten för att autentisera åtkomst till Azure-resurser som skyddas av Microsoft Entra-ID i stället för autentiseringsuppgifter, hemligheter eller Microsoft Entra-token. Azure hanterar den här identiteten åt dig och hjälper dig att skydda dina autentiseringsuppgifter eftersom du inte behöver hantera hemligheter eller använda Microsoft Entra-token direkt. Läs mer om Azure-tjänster som stöder hanterade identiteter för Microsoft Entra-autentisering.

• En förbrukningslogikappresurs kan använda den systemtilldelade identiteten eller en enda användartilldelad identitet som skapats manuellt.

• En standardlogikappresurs har stöd för att aktivera den systemtilldelade hanterade identiteten och flera användartilldelade hanterade identiteter samtidigt, även om du fortfarande bara kan välja en identitet att använda när som helst.

  Kommentar

  Som standard är den systemtilldelade identiteten redan aktiverad för att autentisera anslutningar vid körning. Den här identiteten skiljer sig från autentiseringsuppgifterna eller anslutningssträng som du använder när du skapar en anslutning. Om du inaktiverar den här identiteten fungerar inte anslutningar vid körning. Om du vill visa den här inställningen går du till logikappmenyn under Inställningar och väljer Identitet.

1. Innan logikappen kan använda en hanterad identitet följer du stegen i Autentisera åtkomst till Azure-resurser med hjälp av hanterade identiteter i Azure Logic Apps. De här stegen aktiverar den hanterade identiteten i logikappen och konfigurerar identitetens åtkomst till Azure-målresursen.

2. Innan en Azure-funktion kan använda en hanterad identitet måste du först aktivera autentisering för Azure-funktioner.

3. Ange följande information i utlösaren eller åtgärden som stöder användning av en hanterad identitet:

   Inbyggda utlösare och åtgärder

   Egenskap (designer)	Egenskap (JSON)	Obligatoriskt	Värde	beskrivning
   Autentisering	type	Ja	Hanterad identitet eller ManagedServiceIdentity	Den autentiseringstyp som ska användas
   Hanterad identitet	identity	Nej	<user-assigned-identity-ID>	Den användartilldelade hanterade identiteten som ska användas. Obs! Inkludera inte den här egenskapen när du använder den systemtilldelade hanterade identiteten.
   Publik	audience	Ja	<target-resource-ID>	Resurs-ID:t för målresursen som du vill komma åt. Gör till exempel https://storage.azure.com/ åtkomsttoken för autentisering giltiga för alla lagringskonton. Du kan dock också ange en rottjänst-URL, till exempel https://fabrikamstorageaccount.blob.core.windows.net för ett specifikt lagringskonto. Obs! Egenskapen Målgrupp kan vara dold i vissa utlösare eller åtgärder. Om du vill göra den här egenskapen synlig öppnar du listan Avancerade parametrar i utlösaren eller åtgärden och väljer Målgrupp. Viktigt: Kontrollera att det här målresurs-ID:t exakt matchar det värde som Microsoft Entra-ID förväntar sig, inklusive eventuella efterföljande snedstreck. Resurs-ID https://storage.azure.com/ :t för alla Azure Blob Storage-konton kräver därför ett avslutande snedstreck. Resurs-ID:t för ett specifikt lagringskonto kräver dock inte ett avslutande snedstreck. Information om hur du hittar dessa resurs-ID:er finns i Azure-tjänster som stöder Microsoft Entra-ID.

   När du använder skyddade parametrar för att hantera och skydda känslig information, till exempel i en Azure Resource Manager-mall för att automatisera distributionen, kan du använda uttryck för att komma åt dessa parametervärden vid körning. Den här HTTP-åtgärdsdefinitionen anger till exempel autentiseringen type som ManagedServiceIdentity och använder funktionen parameters() för att hämta parametervärdena:

   "HTTP": {
      "type": "Http",
      "inputs": {
         "method": "GET",
         "uri": "@parameters('endpointUrlParam')",
         "authentication": {
            "type": "ManagedServiceIdentity",
            "audience": "https://management.azure.com/"
         },
      },
      "runAfter": {}
   }
   

   Utlösare och åtgärder för hanterade anslutningsappar

   Egenskap (designer)	Obligatoriskt	Värde	beskrivning
   Anslutningens namn	Ja	<anslutningsnamn>
   Hanterade identiteter	Ja	Systemtilldelad hanterad identitet eller <user-assigned-managed-identity-name>	Den autentiseringstyp som ska användas

Blockera skapande av anslutningar

Om din organisation inte tillåter anslutning till specifika resurser med hjälp av sina anslutningsappar i Azure Logic Apps kan du blockera möjligheten att skapa dessa anslutningar för specifika anslutningsappar i logikappens arbetsflöden med hjälp av Azure Policy. Mer information finns i Blockera anslutningar som skapats av specifika anslutningsappar i Azure Logic Apps.

Isoleringsvägledning för logikappar

• Du kan använda Azure Logic Apps i Azure Government för att stödja alla påverkansnivåer i de regioner som beskrivs i Azure Government Impact Level 5 Isolation Guidance.You can use Azure Logic Apps in Azure Government supporting all impact levels in the regions described by the Azure Government Impact Level 5 Isolation Guidance. För att uppfylla dessa krav stöder Azure Logic Apps möjligheten för dig att skapa och köra arbetsflöden i en miljö med dedikerade resurser så att du kan minska prestandapåverkan från andra Azure-klienter på dina logikappar och undvika att dela databehandlingsresurser med andra klienter.

• Standardarbetsflöden för logikappar kan kommunicera privat och säkert med ett virtuellt Azure-nätverk via privata slutpunkter som du konfigurerar för inkommande trafik och integrering av virtuella nätverk för utgående trafik. Mer information finns i Skydda trafik mellan virtuella nätverk och Azure Logic Apps med en enda klientorganisation med hjälp av privata slutpunkter.

• Om du vill köra din egen kod eller utföra XML-transformering skapar och anropar du en Azure-funktion i stället för att använda funktionen infogad kod eller tillhandahåller sammansättningar som ska användas som kartor. Konfigurera även värdmiljön för din funktionsapp så att den uppfyller dina isoleringskrav.

  Om du till exempel vill uppfylla kraven på effektnivå 5 skapar du din funktionsapp med App Service-planen med hjälp av prisnivån Isolerad tillsammans med en App Service-miljön (ASE) som också använder prisnivån Isolerad. I den här miljön körs funktionsappar på dedikerade virtuella Azure-datorer och dedikerade virtuella Azure-nätverk, som tillhandahåller nätverksisolering utöver beräkningsisolering för dina appar och maximala utskalningsfunktioner.

  Mer information finns i följande dokumentation:

  • Azure App Service-planer
  • Nätverksalternativ för Azure Functions
  • Azure Dedicated Hosts för virtuella datorer
  • Isolering av virtuella datorer i Azure
  • Distribuera dedikerade Azure-tjänster till virtuella nätverk

Mer information om isolering finns i följande dokumentation:

• Isolering i det offentliga Azure-molnet
• Säkerhet för mycket känsliga IaaS-appar i Azure

Relaterat innehåll

• Azure-säkerhetsbaslinje för Azure Logic Apps
• Automatisera distributionen för Azure Logic Apps
• Övervaka logikappar