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

Artikel
10/15/2024

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:

Å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

Roll	beskrivning
Logic App-deltagare	Du kan hantera arbetsflöden för logikappar, men du kan inte ändra åtkomsten till dem.
Logikappoperator	Du kan läsa, aktivera och inaktivera arbetsflöden för logikappar, men du kan inte redigera eller uppdatera dem.
Deltagare	Du har fullständig åtkomst för att hantera alla resurser, men du kan inte tilldela roller i Azure RBAC, hantera tilldelningar i Azure Blueprints eller dela bildgallerier.

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

Kommentar

Den här funktionen är i förhandsversion och omfattas av kompletterande användningsvillkor för Förhandsversioner av Microsoft Azure.

Roll	beskrivning
Logic Apps Standard Reader (förhandsversion)	Du har skrivskyddad åtkomst till alla resurser i en standardlogikapp och arbetsflöden, inklusive arbetsflödeskörningar och deras historik.
Logic Apps Standard Operator (förhandsversion)	Du har åtkomst till att aktivera, skicka om och inaktivera arbetsflöden och att skapa anslutningar till tjänster, system och nätverk för en standardlogikapp. Rollen Operatör kan utföra administrations- och supportuppgifter på Azure Logic Apps-plattformen, men har inte behörighet att redigera arbetsflöden eller inställningar.
Logic Apps Standard Developer (förhandsversion)	Du har åtkomst till att skapa och redigera arbetsflöden, anslutningar och inställningar för en standardlogikapp. Utvecklarrollen har inte behörighet att göra ändringar utanför arbetsflödenas omfång, till exempel programomfattande ändringar som att konfigurera integrering av virtuella nätverk. App Service-planer stöds inte.
Logic Apps Standard-deltagare (förhandsversion)	Du har åtkomst till att hantera alla aspekter av en standardlogikapp, men du kan inte ändra åtkomst eller ägarskap.

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

Portal
Resource Manager-mall

Förbrukningsarbetsflöden

I Azure Portal öppnar du arbetsflödet för förbrukningslogikappen i designern.
På logikappmenyn går du till Inställningar och väljer Arbetsflödesinställningar.
I avsnittet Konfiguration av åtkomstkontroll går du till Tillåtna inkommande IP-adresser i listan Alternativ för utlösareåtkomst och väljer Specifika IP-intervall.
I rutan IP-intervall för innehåll anger du DE IP-adressintervall som kan komma åt innehåll från indata och utdata.

Standardarbetsflöden

Öppna din standardlogikappresurs i Azure Portal.
På logikappmenyn går du till Inställningar och väljer Nätverk.
I avsnittet Konfiguration av inkommande trafik bredvid Åtkomst till offentligt nätverk väljer du Aktiverad utan åtkomstbegränsning.
På sidan Åtkomstbegränsningar går du till Appåtkomst och väljer Aktiverad från välj virtuella nätverk och IP-adresser.
Under Webbplatsåtkomst och regler på fliken Huvudwebbplats lägger du till en eller flera regler i antingen Tillåt eller Neka begäranden från specifika IP-intervall. Du kan också använda inställningarna för HTTP-sidhuvudfilter och vidarebefordran. Ett giltigt IP-intervall använder följande format: x.x.x.x/x eller x.x.x.x.x.x.x.x.x

Mer information finns i Blockera inkommande IP-adresser i Azure Logic Apps (Standard).

Förbrukningsarbetsflöden

I ARM-mallen anger du IP-intervallen accessControl med hjälp av avsnittet med contents avsnittet i logikappens resursdefinition, till exempel:

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

Standardarbetsflöden

I ARM-mallen anger du de tillåtna inkommande IP-adressintervallen i logikappens resursdefinition med hjälp Microsoft.Web/sites/config av avsnittet . I det här avsnittet under propertieslägger du till ipSecurityRestrictions avsnittet och använder avsnitten ipAddress, action="Deny" | "Allow", tag=Default, priorityoch name="Ports" för att definiera en regel och ange ipAddress till det tillåtna IP-intervallet i x.x.x.x/x - eller x.x.x.x.x.x.x.x.x-x-format , till exempel:

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

Säkra indata – stöds inte	Säkra utdata – stöds inte
Lägg till i matrisvariabel Lägg till i strängvariabel Minskningsvariabel För varje Om Inkrementsvariabel Initiera variabel Återkommande Omfattning Ange variabel Strömbrytare Avsluta Do Until	Lägg till i matrisvariabel Lägg till i strängvariabel Komponera Minskningsvariabel För varje Om Inkrementsvariabel Initiera variabel Parsa JSON Återkommande Svar Omfattning Ange variabel Strömbrytare Avsluta Tills Wait

Ö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

Öppna arbetsflödet för logikappen i designern i Azure Portal.
I designern väljer du utlösaren eller åtgärden där du vill skydda känsliga data.
I informationsfönstret som öppnas väljer du Inställningar och expanderar Säkerhet.
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.
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.

Kommentar

Om du använder en parameter i en begäranderubrik eller brödtext kan den parametern visas när du visar arbetsflödets körningshistorik och utgående HTTP-begäran. Se till att du även anger dina principer för innehållsåtkomst i enlighet med detta. Du kan också använda obfuscation för att dölja indata och utdata i körningshistoriken. Som standard Authorization visas inte rubriker via indata eller utdata. Så om en hemlighet används där kan den hemligheten inte hämtas.

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 .

Viktigt!

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.

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

Viktigt!

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 :

Parameternamn	beskrivning
`TemplatePasswordParam`	En mallparameter som accepterar ett lösenord som sedan skickas till arbetsflödesdefinitionens `basicAuthPasswordParam` parameter
`TemplateUsernameParam`	En mallparameter som accepterar ett användarnamn som sedan skickas till arbetsflödesdefinitionens `basicAuthUserNameParam` parameter
`basicAuthPasswordParam`	En parameter för arbetsflödesdefinition som accepterar lösenordet för grundläggande autentisering i en HTTP-åtgärd
`basicAuthUserNameParam`	En parameter för arbetsflödesdefinition som accepterar användarnamnet för grundläggande autentisering i en HTTP-åtgärd

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

Authentication type	Logikapp och anslutningsappar som stöds
Grundläggande	Azure API Management, Azure App Service, HTTP, HTTP + Swagger, HTTP Webhook
Klientcertifikat	Azure API Management, Azure App Service, HTTP, HTTP + Swagger, HTTP Webhook
Active Directory OAuth (OAuth 2.0 med Microsoft Entra ID)	- Förbrukning: Azure API Management, Azure App Service, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook - Standard: Azure Automation, Azure Blob Storage, Azure Event Hubs, Azure Queues, Azure Service Bus, Azure Tables, HTTP, HTTP Webhook, SQL Server
Rå	Azure API Management, Azure App Service, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
Hanterade identiteter	Inbyggda anslutningsappar: - Förbrukning: Azure API Management, Azure App Service, Azure Functions, HTTP, HTTP Webhook - Standard: Azure Automation, Azure Blob Storage, Azure Event Hubs, Azure Queues, Azure Service Bus, Azure Tables, HTTP, HTTP Webhook, SQL Server Obs! För närvarande stöder de flesta inbyggda, tjänstleverantörsbaserade anslutningsappar inte val av användartilldelade hanterade identiteter för autentisering. Hanterade anslutningsappar: Azure App Service, Azure Automation, Azure Blob Storage, Azure Container Instance, Azure Cosmos DB, Azure Data Explorer, Azure Data Factory, Azure Data Lake, Azure Event Grid, Azure Event Hubs, Azure IoT Central V2, Azure IoT Central V3, Azure Key Vault, Azure Log Analytics, Azure Queues, Azure Resource Manager, Azure Service Bus, Azure Sentinel, Azure Table Storage, Virtuell Azure-dator, HTTP med Microsoft Entra-ID, SQL Server

Viktigt!

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

Kommentar

Om du får TLS-handskakningsfel kontrollerar du att du använder TLS 1.2. Mer information finns i Lösa TLS 1.0-problemet.

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

Viktigt!

För bakåtkompatibilitet stöder Azure Logic Apps för närvarande vissa äldre chiffersviter. Använd dock inte äldre chiffersviter när du utvecklar nya appar eftersom sådana sviter kanske inte stöds i framtiden.

Du kan till exempel hitta följande chiffersviter om du inspekterar TLS-handskakningsmeddelandena i Azure Logic Apps eller med hjälp av ett säkerhetsverktyg på logikappens URL. Använd inte dessa äldre sviter igen:

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

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

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.
Öppna arbetsflödet Förbrukning i designern i Azure Portal.
Välj utlösaren i designern. I informationsfönstret som öppnas väljer du Inställningar.
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:

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:

Portal
Resource Manager-mall

Öppna logikappen och arbetsflödet för förbrukning i designern i Azure Portal.
På logikappmenyn går du till Inställningar och väljer Auktorisering.
På sidan Auktorisering väljer du Lägg till princip.

Ange information om auktoriseringsprincipen genom att ange de anspråkstyper och värden som logikappen förväntar sig i åtkomsttoken som presenteras av varje inkommande anrop till utlösaren Begäran :

Property	Obligatoriskt	Type	Beskrivning
Principnamn	Ja	String	Namnet som du vill använda för auktoriseringsprincipen
Principtyp	Ja	String	Antingen AAD för token av ägartyp eller AADPOP för token av typen Proof-of-Possession.
Anspråk	Ja	String	Ett nyckel/värde-par som anger anspråkstypen och värdet som arbetsflödets begärandeutlösare förväntar sig i åtkomsttoken som presenteras av varje inkommande anrop till utlösaren. Du kan lägga till valfritt standardanspråk genom att välja Lägg till standardanspråk. Om du vill lägga till ett anspråk som är specifikt för en PoP-token väljer du Lägg till anpassat anspråk. Tillgängliga standardanspråkstyper: - Utfärdare - Publik - Ämne - JWT-ID (JSON-webbtokenidentifierare) Krav: – Listan Anspråk måste minst innehålla utfärdaranspråket, som har ett värde som börjar med `https://sts.windows.net/` eller `https://login.microsoftonline.com/` som Microsoft Entra-utfärdar-ID. – Varje anspråk måste vara ett enda strängvärde, inte en matris med värden. Du kan till exempel ha ett anspråk med Roll som typ och Utvecklare som värde. Du kan inte ha ett anspråk som har Roll som typ och värdena som anges till Developer och Program Manager. – Anspråksvärdet är begränsat till ett maximalt antal tecken. Mer information om dessa anspråkstyper finns i Anspråk i Microsoft Entra-säkerhetstoken. Du kan också ange din egen anspråkstyp och ditt eget värde.

I följande exempel visas information för en PoP-token:

Om du vill lägga till ett annat anspråk väljer du bland följande alternativ:
- Om du vill lägga till en annan anspråkstyp väljer du Lägg till standardanspråk, väljer anspråkstyp och anger anspråksvärdet.
- Om du vill lägga till ett eget anspråk väljer du Lägg till anpassat anspråk. Mer information finns i hur du tillhandahåller valfria anspråk till din app. Ditt anpassade anspråk lagras sedan som en del av ditt JWT-ID. till exempel "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee".
Om du vill lägga till ytterligare en auktoriseringsprincip väljer du Lägg till princip. Upprepa föregående steg för att konfigurera principen.
När du är klar väljer du Spara.
Om du vill ta med Authorization huvudet från åtkomsttoken i utdata från den begärandebaserade utlösaren läser du Inkludera auktoriseringshuvud i begäran och HTTP webhook-utlösare.

Arbetsflödesegenskaper som principer visas inte i arbetsflödets kodvy i Azure Portal. Om du vill komma åt dina principer programmatiskt anropar du följande API via Azure Resource Manager: https://management.azure.com/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group-name}/providers/Microsoft.Logic/workflows/{your-workflow-name}?api-version=2016-10-01&_=1612212851820. Se till att du ersätter platshållarvärdena för ditt Azure-prenumerations-ID, resursgruppsnamn och arbetsflödesnamn.

I ARM-mallen definierar du en auktoriseringsprincip enligt dessa steg och syntax nedan:

I avsnittet för logikappens properties resursdefinition lägger du till ett accessControl objekt, om inget finns, som innehåller ett triggers objekt.

Mer information om objektet finns accessControl i Begränsa inkommande IP-intervall i Azure Resource Manager-mallen och mallreferensen för Microsoft.Logic-arbetsflöden.
I objektet triggers lägger du till ett openAuthenticationPolicies objekt som innehåller objektet policies där du definierar en eller flera auktoriseringsprinciper.
Ange ett namn för auktoriseringsprincipen, ange principtypen till AADoch inkludera en claims matris där du anger en eller flera anspråkstyper.

Matrisen claims måste minst innehålla anspråkstypen Utfärdare där du anger anspråkets name egenskap till iss och ange value till att börja med https://sts.windows.net/ eller https://login.microsoftonline.com/ som Microsoft Entra-utfärdar-ID. Mer information om dessa anspråkstyper finns i Anspråk i Microsoft Entra-säkerhetstoken. Du kan också ange din egen anspråkstyp och ditt eget värde.
Om du vill inkludera Authorization huvudet från åtkomsttoken i utdata från den begärandebaserade utlösaren läser du Inkludera "auktorisering"-huvudet i utdata för begärandeutlösare.

Här är syntaxen som ska följas:

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

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 :

Skärmbild som visar Azure Portal, Förbrukningsarbetsflödesdesigner och URL för utlösarslutpunkt för begäran.

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:

Frågeparameter	beskrivning
`sp`	Anger behörigheter för tillåtna HTTP-metoder att använda.
`sv`	Anger den SAS-version som ska användas för att generera signaturen.
`sig`	Anger signaturen som ska användas för att autentisera åtkomsten till utlösaren. Den här signaturen genereras med hjälp av SHA256-algoritmen med en hemlig åtkomstnyckel på alla URL-sökvägar och egenskaper. Den här nyckeln hålls hemlig och krypterad, lagras med logikappen och exponeras aldrig eller publiceras aldrig. Logikappen auktoriserar endast de utlösare som innehåller en giltig signatur som skapats med den hemliga nyckeln.

Viktigt!

Se till att skydda din SAS-nyckel precis som du skyddar en kontonyckel från obehörig användning. Konfigurera eller ha en plan för att återkalla en komprometterad åtkomstnyckel. Använd diskretion när du distribuerar URI:er som använder åtkomstnycklar och endast distribuerar sådana URI:er via en säker anslutning, till exempel HTTPS. Se till att endast utföra åtgärder som använder en åtkomstnyckel via en HTTPS-anslutning. Alla som har en URI med giltig nyckel kan komma åt den associerade resursen. 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 använder en SAS-nyckel för att få åtkomst till lagringstjänster rekommenderar Microsoft att du skapar en SAS för användardelegering som skyddas med Microsoft Entra-ID i stället för en kontonyckel.

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:

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.

Kommentar

Den här åtgärden inaktiverar SAS-autentisering för inkommande begäranden och blockerar befintliga SAS-nycklar eller signaturer från att fungera. Dina SAS-nycklar eller signaturer är dock giltiga och fungerar fortfarande om du aktiverar SAS-autentisering igen. Information om hur du inaktiverar SAS-nycklar och signaturer genom att skapa nya versioner finns i Återskapa åtkomstnycklar.

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:

Varning

För scenarier där du har känsliga data, till exempel autentiseringsuppgifter, hemligheter, åtkomsttoken, API-nycklar och annan liknande information, bör du använda ett verktyg som skyddar dina data med nödvändiga säkerhetsfunktioner, fungerar offline eller lokalt, inte synkroniserar dina data till molnet och inte kräver att du loggar in på ett onlinekonto. På så sätt minskar du risken för att exponera känsliga data för allmänheten.

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.

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

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
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"
            }
        }
    }
}
```
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
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.
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.

I Azure Portal öppnar du logikappresursen som använder nyckeln som du vill återskapa.
På resursmenyn för logikappen går du till Inställningar och väljer Åtkomstnycklar.
Välj den nyckel som du vill återskapa och slutföra processen.

Viktigt!

Se till att skydda din åtkomstnyckel precis som du skyddar en kontonyckel från obehörig användning. Konfigurera eller ha en plan för att återkalla en komprometterad åtkomstnyckel. Använd diskretion när du distribuerar URI:er som använder åtkomstnycklar och endast distribuerar sådana URI:er via en säker anslutning, till exempel HTTPS. Se till att endast utföra åtgärder som använder en åtkomstnyckel via en HTTPS-anslutning. Alla som har en URI med giltig nyckel kan komma åt den associerade resursen.

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:

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

Portal
Resource Manager-mall

I Azure Portal påverkar BEGRÄNSNING av IP-adresser både utlösare och åtgärder, i motsats till beskrivningen i portalen under Tillåtna inkommande IP-adresser. Om du vill konfigurera det här filtret separat för utlösare och åtgärder använder du accessControl objektet i en Azure Resource Manager-mall för din logikappresurs eller åtgärden Arbetsflöde – Skapa eller uppdatera i REST-API:et för Azure Logic Apps.

Förbrukningsarbetsflöden

Öppna logikappen Förbrukning i arbetsflödesdesignern i Azure Portal.
På logikappmenyn går du till Inställningar och väljer Arbetsflödesinställningar.
I avsnittet Konfiguration av åtkomstkontroll under Tillåtna inkommande IP-adresser väljer du sökvägen för ditt scenario:
- Om du vill göra arbetsflödet anropbart med hjälp av den inbyggda åtgärden Azure Logic Apps, men bara som ett kapslat arbetsflöde, väljer du Endast andra Logic Apps. Det här alternativet fungerar bara när du använder Azure Logic Apps-åtgärden för att anropa det kapslade arbetsflödet.
  
  Det här alternativet skriver en tom matris till logikappresursen och kräver att endast anrop från överordnade arbetsflöden som använder den inbyggda Azure Logic Apps-åtgärden kan utlösa det kapslade arbetsflödet.
- Om du vill göra arbetsflödet anropbart med http-åtgärden, men bara som ett kapslat arbetsflöde, väljer du Specifika IP-intervall. När rutan IP-intervall för utlösare visas anger du det överordnade arbetsflödets utgående IP-adresser. Ett giltigt IP-intervall använder följande format: x.x.x.x/x eller x.x.x.x.x.x.x.x.x
  
  Kommentar
  
  Om du använder alternativet Endast andra Logic Apps och HTTP-åtgärden för att anropa ditt kapslade arbetsflöde blockeras anropet och du får felet "401 Obehörig".
- För scenarier där du vill begränsa inkommande anrop från andra IP-adresser anger du de IP-adressintervall som utlösaren accepterar när rutan IP-intervall för utlösare visas. Ett giltigt IP-intervall använder följande format: x.x.x.x/x eller x.x.x.x.x.x.x.x.x
Under Begränsa anrop för att hämta in- och utdatameddelanden från körningshistoriken till de angivna IP-adresserna kan du också ange IP-adressintervallen för inkommande anrop som kan komma åt in- och utdatameddelanden i körningshistoriken.

Standardarbetsflöden

Öppna din standardlogikappresurs i Azure Portal.
På logikappmenyn går du till Inställningar och väljer Nätverk.
I avsnittet Konfiguration av inkommande trafik bredvid Åtkomst till offentligt nätverk väljer du Aktiverad utan åtkomstbegränsning.
På sidan Åtkomstbegränsningar går du till Appåtkomst och väljer Aktiverad från välj virtuella nätverk och IP-adresser.
Under Webbplatsåtkomst och regler på fliken Huvudwebbplats lägger du till en eller flera regler i antingen Tillåt eller Neka begäranden från specifika IP-intervall. Ett giltigt IP-intervall använder följande format: x.x.x.x/x eller x.x.x.x.x.x.x.x.x

Mer information finns i Blockera inkommande IP-adresser i Azure Logic Apps (Standard).

Förbrukningsarbetsflöden

I ARM-mallen anger du de tillåtna inkommande IP-adressintervallen i logikappens resursdefinition med hjälp accessControl av avsnittet . I det här avsnittet använder du triggers, actionsoch de valfria contents avsnitten efter behov genom att inkludera allowedCallerIpAddresses avsnittet med addressRange egenskapen och ange egenskapsvärdet till det tillåtna IP-intervallet i formatet x.x.x.x/x eller x.x.x.x.x.x.x .

Om ditt kapslade logikapparbetsflöde använder alternativet Endast andra Logic Apps , som endast tillåter inkommande anrop från andra logikapparbetsflöden som använder den inbyggda Azure Logic Apps-åtgärden, anger du allowedCallerIpAddresses egenskapen till en tom matris ([]) och utelämnar addressRange egenskapen.
Om ditt kapslade logikapparbetsflöde använder alternativet Specifika IP-intervall för andra inkommande anrop, till exempel andra arbetsflöden för logikappar som använder HTTP-åtgärden, inkluderar du allowedCallerIpAddresses avsnittet och anger addressRange egenskapen till det tillåtna IP-intervallet.

Det här exemplet visar en resursdefinition för logikappen för ett kapslat arbetsflöde som endast tillåter inkommande anrop från andra logikapparbetsflöden som använder den inbyggda Azure Logic Apps-åtgärden:

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

Det här exemplet visar en resursdefinition för logikappen för ett kapslat arbetsflöde som tillåter inkommande anrop från logikapparbetsflöden som använder HTTP-åtgärden:

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

Standardarbetsflöden

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

Viktigt!

Om du vill skydda känslig information som arbetsflödet för logikappen hanterar använder du skyddade parametrar och kodar data efter behov. Mer information om hur du använder och skyddar parametrar finns i Åtkomst till parameterindata.

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.

Viktigt!

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

Egenskap (designer)	Egenskap (JSON)	Obligatoriskt	Värde	beskrivning
Autentisering	`type`	Ja	Grundläggande	Den autentiseringstyp som ska användas
Användarnamn	`username`	Ja	<användarnamn>	Användarnamnet för att autentisera åtkomst till måltjänstslutpunkten
Lösenord	`password`	Ja	<lösenord>	Lösenordet för att autentisera åtkomst till måltjänstslutpunkten

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

Viktigt!

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

Egenskap (designer)	Egenskap (JSON)	Obligatoriskt	Värde	beskrivning
Autentisering	`type`	Ja	Klientcertifikat eller `ClientCertificate`	Den autentiseringstyp som ska användas. Du kan hantera certifikat med Azure API Management. Obs! Anpassade anslutningsappar stöder inte certifikatbaserad autentisering för både inkommande och utgående anrop.
Pfx	`pfx`	Ja	<kodat pfx-file-content>	Det base64-kodade innehållet från en PFX-fil (Personal Information Exchange) Om du vill konvertera PFX-filen till base64-kodat format kan du använda PowerShell 7 genom att följa dessa steg: 1. Spara certifikatinnehållet i en variabel: `$pfx_cert = [System.IO.File]::ReadAllBytes('c:\certificate.pfx')` 2. Konvertera certifikatinnehållet med hjälp `ToBase64String()` av funktionen och spara innehållet i en textfil: `[System.Convert]::ToBase64String($pfx_cert) \| Out-File 'pfx-encoded-bytes.txt'` Felsökning: Om du använder `cert mmc/PowerShell` kommandot kan det här felet visas: `Could not load the certificate private key. Please check the authentication certificate password is correct and try again.` Lös det här felet genom att försöka konvertera PFX-filen till en PEM-fil och gå tillbaka igen med hjälp `openssl` av kommandot : `openssl pkcs12 -in certificate.pfx -out certificate.pem` `openssl pkcs12 -in certificate.pem -export -out certificate2.pfx` När du sedan får den base64-kodade strängen för certifikatets nyligen konverterade PFX-fil fungerar strängen nu i Azure Logic Apps.
Lösenord	`password`	Nej	<password-for-pfx-file>	Lösenordet för att komma åt PFX-filen

Kommentar

Om du försöker autentisera med ett klientcertifikat med OpenSSL kan du få följande fel:

BadRequest: Could not load private key

Du åtgärdar felet genom att följa dessa steg:

Avinstallera alla OpenSSL-instanser.
Installera OpenSSL version 1.1.1t.
Avsäg certifikatet med hjälp av den nya uppdateringen.
Lägg till det nya certifikatet i HTTP-åtgärden när du använder klientcertifikatautentisering.

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

Viktigt!

Om du har en standardlogikappresurs i Azure Logic Apps med en enda klientorganisation och vill använda en HTTP-åtgärd med ett TSL/SSL-certifikat, klientcertifikat eller Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) med Certificate autentiseringstypen måste du slutföra de extra installationsstegen för den här autentiseringstypen. Annars misslyckas anropet. Mer information finns i Autentisering i en klientorganisationsmiljö.

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

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.

Viktigt!

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:

Egenskap (designer)	Egenskap (JSON)	Obligatoriskt	Värde	beskrivning
Autentisering	`type`	Ja	Active Directory OAuth (OAuth 2.0 med Microsoft Entra ID) eller `ActiveDirectoryOAuth`	Den autentiseringstyp som ska användas. Azure Logic Apps följer för närvarande OAuth 2.0-protokollet.
Auktoritet	`authority`	Nej	<URL-for-authority-token-issuer>	URL:en för den utfärdare som tillhandahåller åtkomstnyckeln, till exempel `https://login.microsoftonline.com/` för globala Azure-tjänstregioner. Andra nationella moln finns i Microsoft Entra-autentiseringsslutpunkter – Välja din identitetsutfärdare.
Klientorganisation	`tenant`	Ja	<klientorganisations-ID>	Klientorganisations-ID för Microsoft Entra-klientorganisationen
Publik	`audience`	Ja	<resource-to-authorize>	Den resurs som du vill använda för auktorisering, till exempel `https://management.core.windows.net/`
Klient-ID	`clientId`	Ja	<klient-ID>	Klient-ID:t för appen som begär auktorisering
Typ av autentiseringsuppgifter	`credentialType`	Ja	Intyg eller Hemlig	Den typ av autentiseringsuppgifter som klienten använder för att begära auktorisering. Den här egenskapen och värdet visas inte i logikappens underliggande definition, utan avgör vilka egenskaper som visas för den valda autentiseringstypen.
Hemlighet	`secret`	Ja, men bara för autentiseringstypen "Hemlig"	<klienthemlighet>	Klienthemligheten för att begära auktorisering
Pfx	`pfx`	Ja, men bara för autentiseringstypen "Certifikat"	<kodat pfx-file-content>	Det base64-kodade innehållet från en PFX-fil (Personal Information Exchange)
Lösenord	`password`	Ja, men bara för autentiseringstypen "Certifikat"	<password-for-pfx-file>	Lösenordet för att komma åt PFX-filen

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

Viktigt!

Om du har en standardlogikappresurs i Azure Logic Apps med en enda klientorganisation och vill använda en HTTP-åtgärd med ett TSL/SSL-certifikat, klientcertifikat eller Microsoft Entra ID OAuth med Certificate typen autentiseringsuppgifter ska du slutföra de extra installationsstegen för den här autentiseringstypen. Annars misslyckas anropet. Mer information finns i Autentisering i en klientorganisationsmiljö.

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.

Viktigt!

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:

Egenskap (designer)	Egenskap (JSON)	Obligatoriskt	Värde	beskrivning
Autentisering	`type`	Ja	Raw	Den autentiseringstyp som ska användas
Värde	`value`	Ja	<authorization-header-value>	Värdet för auktoriseringshuvud som ska användas för autentisering

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.

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.
Innan en Azure-funktion kan använda en hanterad identitet måste du först aktivera autentisering för Azure-funktioner.

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:

Mer information om isolering finns i följande dokumentation:

Dela via

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

Åtkomst till logikappsåtgärder

Förbrukningsarbetsflöden

Standardarbetsflöden

Åtkomst till körningshistorikdata

Begränsa åtkomsten efter IP-adressintervall

Förbrukningsarbetsflöden

Standardarbetsflöden

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

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

Skydda indata och utdata i designern

Skydda indata och utdata i kodvyn

Åtkomst till parameterindata

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

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

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

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

Aktivera OAuth 2.0 med Microsoft Entra-ID

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

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)

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

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

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

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

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

Förutsättningar

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

Lägg till egenskapen sasAuthenticationPolicy i arbetsflödesdefinitionen

Återskapa åtkomstnycklar

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

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

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

Begränsa inkommande IP-adresser

Förbrukningsarbetsflöden

Standardarbetsflöden

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

Lägga till autentisering i utgående anrop

Grundläggande autentisering

Autentisering med klientcertifikat

Microsoft Entra-plattform

Råautentisering

Autentisering av hanterad identitet

Blockera skapande av anslutningar

Isoleringsvägledning för logikappar

Relaterat innehåll

Feedback

Ytterligare resurser