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

  • Artikel

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:

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 konfigurationen av Anslut ion i Azure Logic Apps och Anslut ionssä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

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 de tillåtna IP-intervallen följer du dessa steg för antingen Azure-portalen eller din Azure Resource Manager-mall:

Förbrukningsarbetsflöden

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

  2. Välj Arbetsflödesinställningar under Inställningar på logikappens meny.

  3. Under Konfiguration av>åtkomstkontroll Tillåtna inkommande IP-adresser väljer du Specifika IP-intervall.

  4. Under IP-intervall för innehåll anger du DE IP-adressintervall som kan komma åt innehåll från indata och utdata.

Standardarbetsflöden

  1. Öppna logikappresursen i Azure-portalen.

  2. På logikappmenyn går du till Inställningar och väljer Nätverk.

  3. I avsnittet Inkommande trafik väljer du Åtkomstbegränsning.

  4. Skapa en eller flera regler för att antingen tillåta eller neka begäranden från specifika IP-intervall. Du kan också använda inställningarna för HTTP-sidhuvudfilter och vidarebefordran.

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

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ärderstö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
Växla
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
Växla
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 .

    Skyddade utdata som indata och nedströmspåverkan på de flesta åtgärder

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

    Skyddade utdata som indata med nedströmspåverkan på specifika åtgärder

    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 aktiverarinte säkra indata i den här åtgärden och döljer inte den här åtgärdens utdata.

    Skyddade indata och nedströmspåverkan på de flesta åtgärder

    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.

    Säkra indata och nedströmspåverkan på specifika åtgärder

Skydda indata och utdata i designern

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

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

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

    Skärmbild som visar Azure-portalen, arbetsflödesdesignern och utlösaren eller åtgärden med öppnade inställningar.

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

    Skärmbild som visar arbetsflödet med en åtgärds inställningar för säkra indata eller säkra utdata aktiverade.

    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.

    Skärmbild som visar arbetsflödet med en efterföljande åtgärds lista över dynamiskt innehåll öppnad och den föregående åtgärdens token för skyddade utdata med låsikonen.

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

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

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

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

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

      Skärmbild som visar vyn Körningshistorik för standardarbetsflöde med dolda indata och utdata.

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:

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:

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

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

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

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

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

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

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

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

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

Den här exempelmallen som har flera skyddade parameterdefinitioner som använder typen securestring :

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 Services, HTTP, HTTP + Swagger, HTTP Webhook
Klientcertifikat Azure API Management, Azure App Services, HTTP, HTTP + Swagger, HTTP Webhook
Active Directory OAuth - Förbrukning: Azure API Management, Azure App Services, 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
Raw Azure API Management, Azure App Services, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
Hanterade identiteter Inbyggda anslutningsappar:

- Förbrukning: Azure API Management, Azure App Services, 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

Å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 utlösaren för begäran eller ett återanrop till HTTP Webhook-utlösaren eller åtgärden. 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

Kommentar

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 när du använder Azure Logic Apps-tjänsten 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

Följande lista innehåller fler sätt som du kan begränsa åtkomsten till utlösare som tar emot inkommande anrop till logikappen så att endast auktoriserade klienter kan anropa logikappen:

Generera signaturer för delad åtkomst (SAS)

Varje begärandeslutpunkt i en logikapp har en signatur för delad åtkomst (SAS) i slutpunktens URL, som följer det här formatet:

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

Varje URL innehåller frågeparametern sp, svoch sig enligt beskrivningen i den här tabellen:

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

Inkommande anrop till en begärandeslutpunkt kan bara använda ett auktoriseringsschema, antingen SAS eller OAuth med Microsoft Entra-ID. Om du använder ett schema inaktiveras inte det andra schemat, men om du använder båda schemana samtidigt uppstår ett fel eftersom tjänsten inte vet vilket schema som ska väljas.

Mer information om hur du skyddar åtkomst med SAS finns i följande avsnitt i det här avsnittet:

Återskapa åtkomstnycklar

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

  1. I Azure-portalen öppnar du logikappen som har den nyckel som du vill återskapa.

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

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

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

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

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

I brödtexten NotAftertar 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 Logic Apps REST API, till exempel:

POST /subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-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.

Aktivera Öppen autentisering för Microsoft Entra-ID (Microsoft Entra ID OAuth)

I ett arbetsflöde för förbrukningslogikappen som börjar med en begäransbaserad utlösare kan du autentisera inkommande anrop som skickas till slutpunkten som skapats av utlösaren genom att aktivera Microsoft Entra ID OAuth. Om du vill konfigurera den här autentiseringen definierar eller lägger du till en auktoriseringsprincip på logikappsnivå. 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 standardarbetsflöde för logikappar 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 utlö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 Microsoft Entra ID OAuth

  • Ett inkommande anrop till begärandeslutpunkten kan bara använda ett auktoriseringsschema, antingen OAuth 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 uppstår ett fel eftersom Azure Logic Apps inte vet vilket schema som ska väljas.

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

  • Logikappresursen ä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 Microsoft Entra-utfärdar-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": "72f988bf-86f1-41af-91ab-2d7cd011db47",
    "unique_name": "SophiaOwen@fabrikam.com",
    "upn": "SophiaOwen@fabrikam.com",
    "uti": "TPJ7nNNMMZkOSx6_uVczUAA",
    "ver": "1.0"
}

Aktivera Microsoft Entra ID OAuth som det enda alternativet för att anropa en begärandeslutpunkt

  1. Konfigurera din request- eller HTTP-webhook-utlösare med funktionen för att kontrollera OAuth-åtkomsttoken genom att följa stegen för att inkludera rubriken "Auktorisering" i utdata från request- eller HTTP webhook-utlösaren.

    Kommentar

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

  2. Öppna arbetsflödet för förbrukningslogikappen i designern i Azure-portalen.

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

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

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

    -eller-

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

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

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

MsAL-bibliotek (Microsoft Authentication Library) tillhandahåller PoP-token som du kan använda. Om logikappens arbetsflöde 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 nästa avsnitt för att konfigurera OAuth med Microsoft Entra-ID.

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

Följ dessa steg för antingen Azure-portalen eller din Azure Resource Manager-mall:

I Azure-portalen lägger du till en eller flera auktoriseringsprinciper i din förbrukningslogikappresurs:

  1. Öppna logikappen Förbrukning i arbetsflödesdesignern i Azure-portalen.

  2. På resursmenyn för logikappen går du till Inställningar och väljer Auktorisering. När fönstret Auktorisering har öppnats väljer du Lägg till princip.

    Skärmbild som visar Azure-portalen, menyn Förbrukningslogikapp, auktoriseringssidan och den valda knappen för att lägga till en princip.

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

    Skärmbild som visar azure-portalen, auktoriseringssidan för förbrukningslogikappen och information för auktoriseringsprincip.

    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:

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

    Skärmbild som visar azure-portalen, auktoriseringssidan för förbrukningslogikappen och information om en princip för innehavsbevis.

  4. 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": "72f988bf-86f1-41af-91ab-2d7cd011db47".

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

  6. När du är klar väljer du Spara.

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

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:

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 Logic Apps REST API: Workflow Triggers – Kör begä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-portalen 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

I Azure-portalen påverkar IP-adressbegränsning 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 REST API:et för Azure Logic Apps: Arbetsflöde – Skapa eller uppdatera.

Förbrukningsarbetsflöden

  1. Öppna logikappen Förbrukning i arbetsflödesdesignern i Azure-portalen.

  2. Välj Arbetsflödesinställningar under Inställningar på logikappmenyn.

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

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

  1. Öppna logikappresursen i Azure-portalen.

  2. På logikappmenyn går du till Inställningar och väljer Nätverk.

  3. I avsnittet Inkommande trafik väljer du Åtkomstbegränsning.

  4. Skapa en eller flera regler för att antingen tillåta 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).

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

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

        Skärmbild som visar Azure-portalen, arbetsflödesdesignern för förbrukning och hur du hittar en 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.

        Skärmbild som visar azure-portalen, standardarbetsflödesdesignern och Azure API Management-åtgärden.

      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.

        Skärmbild som visar Azure-portalen, standardarbetsflödesdesignern och det valda API:et som ska anropas.

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 Lägg till ny parameter i utlösaren eller åtgärden och väljer Autentisering.

Viktigt!

Om du vill skydda känslig information som 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

Om alternativet Basic är tillgängligt 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 av klientcertifikat

Om alternativet Klientcertifikat är tillgängligt 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:

  1. Avinstallera alla OpenSSL-instanser.
  2. Installera OpenSSL version 1.1.1t.
  3. Avsäg certifikatet med hjälp av den nya uppdateringen.
  4. 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-identitetsplattform

På Begärandeutlösare kan du använda Microsofts identitetsplattform för att autentisera inkommande samtal när du har konfigurerat Microsoft Entra-auktoriseringsprinciper för logikappen. Ange följande egenskapsvärden för alla andra utlösare och åtgärder som anger autentiseringstypen Active Directory OAuth som du kan välja:

Egenskap (designer) Egenskap (JSON) Obligatoriskt Värde beskrivning
Autentisering type Ja Active Directory OAuth
eller
ActiveDirectoryOAuth		 Den autentiseringstyp som ska användas. Azure Logic Apps följer för närvarande OAuth 2.0-protokollet.
Myndigheten authority Nej <URL-for-authority-token-issuer> URL:en för utfärdaren som tillhandahåller åtkomsttoken, 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 Certifikat
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 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ö.

Råautentisering

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

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

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

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

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 logikappens meny under Inställningar och väljer Identitet.

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

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

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

    Inbyggda utlösare och åtgärder

    Egenskap (designer) Egenskap (JSON) Obligatoriskt Värde beskrivning
    Autentisering type Ja Hanterad identitet
    eller
    ManagedServiceIdentity    		 Den autentiseringstyp som ska användas
    Hanterad identitet identity Nej <user-assigned-identity-ID> Den användartilldelade hanterade identiteten som ska användas. Obs! Inkludera inte den här egenskapen när du använder den systemtilldelade hanterade identiteten.
    Publik audience Ja <target-resource-ID> Resurs-ID:t för målresursen som du vill komma åt.

    Gör till exempel https://storage.azure.com/ åtkomsttoken för autentisering giltiga för alla lagringskonton. Du kan dock också ange en rottjänst-URL, till exempel https://fabrikamstorageaccount.blob.core.windows.net för ett specifikt lagringskonto.

    Obs! Egenskapen Målgrupp kan vara dold i vissa utlösare eller åtgärder. Om du vill göra den här egenskapen synlig öppnar du listan Lägg till ny parameter 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.

Mer information om isolering finns i följande dokumentation:

Nästa steg