Säker åtkomst och data i Azure Logic Apps

Azure Logic Apps förlitar sig på Azure Storage att lagra och automatiskt kryptera vilodata. Den här 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 för att kryptera dina data. Mer information finns i Azure Storage för vilodata.

Om du vill kontrollera åtkomsten ytterligare och skydda känsliga data Azure Logic Apps kan du ställa in mer säkerhet inom följande områden:

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

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

• Översikt över Azure-kryptering
• Azure Data Encryption-at-Rest
• Benchmark för Azure-säkerhet

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

Inkommande anrop som en logikapp tar emot via en begärandebaserad utlösare, till exempel begärandeutlösaren eller HTTP Webhook-utlösaren, stöder kryptering och skyddas med Transport Layer Security (TLS) 1.2som minst , tidigare kallat Secure Sockets Layer (SSL). Logic Apps den här versionen när du tar emot ett inkommande anrop till begärandeutlösaren 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.

För inkommande anrop använder du följande chiffersviter:

• 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

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

• Generera signaturer för delad åtkomst (SAS)
• Aktivera Azure Active Directory Öppen autentisering (Azure AD OAuth)
• Exponera logikappen med Azure API Management
• Begränsa inkommande IP-adresser

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 sp frågeparametern sv , och enligt sig beskrivningen i den här tabellen:

Inkommande anrop till en slutpunkt för begäran kan bara använda ett auktoriseringsschema, antingen SAS Azure Active Directory Open Authentication. Även om användningen av ett schema inte inaktiverar det andra schemat, orsakar användningen av båda schemana samtidigt 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
• Skapa URL:er för motringning som upphör att gälla
• Skapa URL:er med primär eller sekundär nyckel

Återskapa åtkomstnycklar

Om du vill generera en ny säkerhetsåtkomstnyckel när som helst använder du Azure REST API eller Azure Portal. 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:erna som du hämtar efter återskapande signeras med den nya åtkomstnyckeln.

1. I Azure Portaldu logikappen som innehåller den nyckel som du vill återskapa.

2. På logikappens meny går du till Inställningar och väljer Åtkomstnycklar.

3. Välj den nyckel som du vill återskapa och slutför 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 återanrops-URL:er 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 specifikt tidsspann. Om du vill ange ett förfallodatum för en URL 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

Inkludera egenskapen med hjälp av en JSON-datumsträng NotAfter i brödtexten. Den här egenskapen returnerar en återanrops-URL som endast är giltig fram NotAfter till datum och tid.

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

När du genererar eller listar motringning-URL:er för en begärandebaserad utlösare kan du ange vilken nyckel som ska användas för att signera URL:en. Om du vill generera en URL som signerats av en viss 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 inkluderar du egenskapen KeyType som antingen Primary eller Secondary . Den här egenskapen returnerar en URL som signerats av den angivna säkerhetsnyckeln.

Aktivera Azure Active Directory Öppen autentisering (Azure AD OAuth)

För inkommande anrop till en slutpunkt som skapas av en begärandebaserad utlösare kan du aktivera Azure AD OAuth genom att definiera eller lägga till en auktoriseringsprincip för logikappen. På så sätt använder inkommande anrop OAuth-åtkomsttoken för auktorisering.

När logikappen tar emot en inkommande begäran som innehåller en OAuth-åtkomsttoken jämför Azure Logic Apps tokens anspråk med 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 antal som anges av auktoriseringsprincipen.

Att tänka på innan du aktiverar Azure AD OAuth

• Ett inkommande anrop till begärandeslutpunkten kan bara använda ett auktoriseringsschema, antingen Azure AD OAuth eller signatur för delad åtkomst (SAS). Även om användningen av ett schema inte inaktiverar det andra schemat, orsakar användningen av båda schemana samtidigt ett fel eftersom Logic Apps-tjänsten inte vet vilket schema som ska väljas.

• Endast autentiseringsscheman av bearertyp stöds för Azure AD OAuth-åtkomsttoken, vilket innebär att huvudet för Authorization åtkomsttoken måste ange Bearer typen.

• Logikappen ä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åk, som har ett värde som börjar med antingen eller https://sts.windows.net/ https://login.microsoftonline.com/ (OAuth V2) som Id för Azure AD-utfärdaren.

  Anta till exempel att logikappen har en auktoriseringsprincip som kräver två anspråkstyper: Målgrupp och Utfärdare. Det här exempelnyttolasten för en avkodad åtkomsttoken innehåller båda anspråkstyperna där är aud värdet för Målgrupp och är iss värdet Issuer:

  {
      "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 Azure AD OAuth för din logikapp

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

"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 rubriken "Authorization" (Auktorisering) i utdata för begärandeutlösare

För logikappar som aktiverar Azure Active Directory Open Authentication (Azure AD OAuth) för auktorisering av inkommande anrop för att få åtkomst till begärandebaserade utlösare kan du aktivera utdata från begärandeutlösaren eller HTTP Webhook-utlösaren för att inkludera huvudet från Authorization OAuth-åtkomsttoken. I utlösarens underliggande JSON-definition lägger du till och anger operationOptions egenskapen till IncludeAuthorizationHeadersInOutputs . Här är ett exempel på begärandeutlösaren:

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

Mer information finns i de här ämnena:

• Schemareferens för utlösare och åtgärdstyper – Begärandeutlösare
• Schemareferens för utlösare och åtgärdstyper – HTTP Webhook-utlösare
• Schemareferens för utlösare och åtgärdstyper – åtgärdsalternativ

Exponera din logikapp med Azure API Management

Om du vill ha fler autentiseringsprotokoll och alternativ kan du överväga att exponera din logikapp som ett API med hjälp av Azure API Management. Den här tjänsten ger omfattande funktioner för övervakning, säkerhet, policyer och dokumentation för alla slutpunkter. API Management kan exponera en offentlig eller privat slutpunkt för logikappen. Om du vill ge åtkomst till den här slutpunkten kan du använda Azure Active Directory Open Authentication (Azure AD OAuth), 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 API Management anropa logikappen kan du begränsa logikappens inkommande IP-adresser.

Mer information finns i följande dokumentation:

• Om API Management
• Skydda en webb-API-backend i Azure API Management med hjälp av OAuth 2.0-auktorisering med Azure AD
• Säkra API:er med klientcertifikatautentisering i API Management
• Principer för API Management-autentisering

Begränsa inkommande IP-adresser

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

Oavsett vilka IP-adresser du anger kan du fortfarande köra en logikapp som har en begäransbaserad utlösare med hjälp av Logic Apps REST API: Arbetsflödesutlösare – Kör begäran eller genom att använda API Management. Det här scenariot kräver dock fortfarande autentisering mot Azure-REST API. Alla händelser visas i Azure-granskningsloggen. Se till att du anger principer för åtkomstkontroll på motsvarande sätt.

Om du vill begränsa de inkommande IP-adresserna för logikappen följer du dessa steg för antingen Azure Portal eller din Azure Resource Manager mall:

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

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

Åtkomst till logikappåtgärder

Du kan endast tillåta specifika användare eller grupper att köra specifika uppgifter, till exempel hantera, redigera och visa logikappar. Om du vill kontrollera deras behörigheter använder du rollbaserad åtkomstkontroll i Azure (Azure RBAC). Du kan tilldela inbyggda eller anpassade roller till medlemmar som har åtkomst till din Azure-prenumeration. Azure Logic Apps har följande specifika roller:

• Logic App-deltagare:Låter dig hantera logikappar, men du kan inte ändra åtkomsten till dem.

• Logic App Operator:Låter dig läsa, aktivera och inaktivera logikappar, men du kan inte redigera eller uppdatera dem.

• Deltagare:Ger fullständig åtkomst för att hantera alla resurser, men tillåter inte att du tilldelar roller i Azure RBAC, hanterar tilldelningar i Azure Blueprints eller delar bildgallerier.

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

Om du vill förhindra att andra ändrar eller tar bort logikappen kan du använda Azure Resource Lock. Den här funktionen förhindrar att andra ändrar eller tar bort produktionsresurser. Mer information om anslutningssäkerhet finns i Anslutningskonfiguration i Azure Logic Apps anslutningssäkerhet och kryptering.

Åtkomst till körningshistorikdata

När en logikapp körs krypteras alla data under överföringen med hjälp av Transport Layer Security (TLS) och i vila. När logikappen har körts klart kan du visa historiken för körningen, inklusive de steg som kördes tillsammans med status, varaktighet, indata och utdata för varje åtgärd. Den här detaljerade detaljnivån 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 Logic Apps din åtkomst och innehå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 hindra andra från att visa och komma åt dessa data. Om logikappen till exempel hämtar en hemlighet från Azure Key Vault ska användas vid autentisering av en HTTP-åtgärd, vill du dölja hemligheten från vyn.

Du har följande alternativ för att styra åtkomsten till indata och utdata i logikappens körningshistorik:

• Begränsa åtkomsten efter IP-adressintervall.

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

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

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

Begränsa åtkomst efter IP-adressintervall

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

Om du till exempel vill blockera vem som helst från att komma åt indata och utdata anger du ett IP-adressintervall, till exempel 0.0.0.0-0.0.0.0 . Endast en person med administratörsbehörighet kan ta bort den här begränsningen, vilket ger möjlighet att "just-in-time"-åtkomst till logikappens data.

Om du vill ange tillåtna IP-intervall följer du dessa steg för antingen Azure Portal eller din Azure Resource Manager mall:

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

Skydda data i körningshistoriken med hjälp av förvirring

Många utlösare och åtgärder har inställningar för att skydda indata, utdata eller både och 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 dessa alternativ:

Att tänka på när du skyddar indata och utdata

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

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

• Det Logic Apps API:et 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 ska dölja dessa data.

  Inställningen Säkra utdata

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

  

  Åtgärderna Skriv, Parsa JSON och Svar har endast inställningen Säkra indata. När inställningen är aktiverad döljer den även utdata för dessa åtgärder. Om de här åtgärderna uttryckligen använder överordnade skyddade utdata som indata Logic Apps döljer Logic Apps dessa åtgärders in- och utdata, men aktiverar inte inställningen Säkra indata för dessa åtgärder. Om en underordnad åtgärd uttryckligen använder dolda utdata från åtgärderna Skriv, Parsa JSON eller Svar som indata döljer Logic Apps inte den här underordnade åtgärdens indata eller utdata.

  

  Inställningen Säkra indata

  När du aktiverar säkra indata i en utlösare eller åtgärd manuellt Logic Apps dessa indata i körningshistoriken. Om en underordnad åtgärd uttryckligen använder synliga utdata från utlösaren eller åtgärden som indata, döljer 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 skyddade indata döljer Logic Apps dessa åtgärders indata och utdata, men aktiverar inte inställningen Säkra indata för åtgärden. Om en underordnad åtgärd uttryckligen använder dolda utdata från åtgärderna Skriv, Parsa JSON eller Svar som indata döljer Logic Apps inte den här underordnade åtgärdens indata eller utdata.

  

Säkra indata och utdata i designern

1. I Azure Portaldu logikappen i Logikappdesignern.

   

2. På utlösaren eller åtgärden där du vill skydda känsliga data väljer du ellipsknappen (...) och väljer sedan Inställningar.

   

3. Aktivera antingen Säkra indata, Säkra utdata eller båda. När du är klar väljer du Klar.

   

   Åtgärden eller utlösaren visar nu en låsikon i namnlisten.

   

   Token som representerar skyddade utdata från tidigare åtgärder visar även låsikoner. När du till exempel väljer utdata från listan med dynamiskt innehåll som ska användas i en åtgärd, visar denna token en låsikon.

   

4. När logikappen har körts kan du visa historiken för den körningen.

   1. I logikappens fönster Översikt väljer du den körning som du vill visa.

   2. I fönstret Logikappkörning expanderar 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.

      

Säkra indata och utdata i kodvyn

I den underliggande utlösar- eller åtgärdsdefinitionen lägger du till eller uppdaterar runtimeConfiguration.secureData.properties matrisen med antingen eller båda av 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 mellan olika miljöer bör 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 genom att använda en Azure Resource Manager-mall för att distribuera logikappen, skydda känsliga data genom att definiera säkra 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 Azure Active Directory Open Authentication (Azure AD OAuth) kan du definiera och dölja de parametrar som accepterar det klient-ID och den klienthemlighet som används för autentisering. Om du vill definiera de här parametrarna i logikappen använder du avsnittet i logikappens parameters arbetsflödesdefinition 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 av - eller -typen och använder securestring secureobject 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 @parameters('<parameter-name>') uttrycket i arbetsflödesdefinitionen. Det här uttrycket utvärderas endast vid körning och beskrivs av Arbetsflödesdefinitionsspråk.

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

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

Om du automatiserar distributionenför logikappar med hjälp av Resource Manager -mallar kan du definiera säkra mallparametrar ,som utvärderas vid distribution med hjälp av securestring typerna och secureobject . Om du vill definiera mallparametrar använder du mallens toppnivåavsnitt, som är separat och parameters 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 säkra 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 de här ämnena:

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

Säkra parametrar i arbetsflödesdefinitioner

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 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 basicAuthPasswordParam basicAuthUsernameParam parametrarna och med hjälp av securestring typen . Åtgärdsdefinitionen refererar sedan till dessa parametrar i authentication avsnittet .

"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

En Resource Manager mall för en logikapp 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 av securestring typen secureobject eller . 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 informationen vid distributionen. Mer information finns i Skicka känsliga värden vid distribution med hjälp av Azure Key Vault.

Här finns 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ängar 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 avsnitt värdena parameters 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 parameters definierar ett avsnitt de parametrar som logikappen 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 säkra parameterdefinitioner som använder securestring typen :

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

Å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ärdenkryptering och skyddas med Transport Layer Security (TLS) 1.0, 1.1 eller 1.2, som tidigare kallades Secure Sockets Layer (SSL). Logic Apps förhandlar med målslutpunkten med hjälp av 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.

Här är information om själv signerade TLS/SSL-certifikat:

• För logikappar i den globala miljön för Azure Logic Apps klientorganisation tillåter HTTP-åtgärder inte själv signerade TLS/SSL-certifikat. Om logikappen gör ett HTTP-anrop till en server och presenterar ett självloggat TLS/SSL-certifikat misslyckas HTTP-anropet med ett TrustFailure fel.

• För logic apps in the single-tenant Azure Logic Apps environment, stöder HTTP-åtgärder själv signerade 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 TSL/SSL-certifikatautentisering för en enskild klientorganisation Azure Logic Apps.

  Om du vill använda klientcertifikat eller Azure Active Directory Open Authentication (Azure AD OAuth) med autentiseringstypen "Certifikat" 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 Azure Active Directory Open Authentication (Azure AD OAuth) med autentiseringstypen "Certifikat"för en enskild klientorganisation Azure Logic Apps .

• För logikappar i en Integration Service Environment (ISE)tillåter HTTP-anslutningsappen själv signerade certifikat för TLS/SSL-handskakningar. Du måste dock först aktivera stöd för själv signerade certifikat för en befintlig ISE eller ny ISE med hjälp av Logic Apps REST API och installera det offentliga certifikatet på TrustedRoot platsen.

Här är några fler sätt som du kan använda för att skydda slutpunkter som hanterar anrop som skickas från logikappen:

• 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 den begäran som skickas av logikappen. Du kan till exempel välja följande autentiseringstyper:

  • Grundläggande autentisering

  • Autentisering med klientcertifikat

  • Active Directory OAuth-autentisering

  • Autentisering av hanterad identitet

• Begränsa åtkomsten från LOGIKappens IP-adresser.

  Alla anrop till slutpunkter från logikappar kommer från specifika angivna 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 ger integrering med dessa tjänster för att ge säkrare och tillförlitligare lokal kommunikation.

  • Lokal datagateway

    Många hanterade anslutningsappar i Azure Logic Apps säkra anslutningar till lokala system, till exempel filsystem, SQL, SharePoint och DB2. Gatewayen skickar data från lokala källor på krypterade kanaler via Azure Service Bus. All trafik kommer från som 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 plats-till-plats virtuellt privat nätverk 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 det API:et genom att skapa en API Management-tjänstinstanskan du anropa det API:et i logikappens arbetsflöde genom att välja den inbyggda API Management-utlösaren eller åtgärden i Logikappdesignern.

    Anteckning

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

    1. I Logikappdesignern anger api management du i sökrutan. Välj steget baserat på om du lägger till en utlösare eller en åtgärd:

       • Om du lägger till en utlösare, som alltid är det första steget i arbetsflödet, väljer du Välj en Azure-API Management utlösare.

       • Om du lägger till en åtgärd väljer du Välj en Azure-API Management åtgärd.

       Det här exemplet lägger till en utlösare:

       

    2. Välj den tidigare skapade API Management-tjänstinstansen.

       

    3. Välj det API-anrop som ska användas.

       

Lägga till autentisering i utgående anrop

HTTP- och HTTPS-slutpunkter stöder olika typer av autentisering. För 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 Logikappdesignern 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 på utlösaren eller åtgärden och väljer Autentisering.

Autentiseringstyper för utlösare och åtgärder som stöder autentisering

Den här tabellen identifierar de autentiseringstyper som är tillgängliga för utlösare och åtgärder där du kan välja en autentiseringstyp:

Grundläggande autentisering

Om alternativet Grundläggande är tillgängligt anger du följande egenskapsvärden:

När du använder skyddade parametrar för att hantera och skydda känslig information, till exempel i en Azure Resource Manager-mallför att automatisera distributionen, kan du använda uttryck för att komma åt dessa parametervärden vid körning. Den här http-exempelåtgärdsdefinitionen anger type autentiseringen 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

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

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

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

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

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

Azure Active Directory Öppen autentisering

På Begäran-utlösare kan du använda Azure Active Directory Open Authentication (Azure AD OAuth)för att autentisera inkommande anrop när du har ställt in Azure AD-auktoriseringsprinciper för din logikapp. För alla andra utlösare och åtgärder som anger autentiseringstypen Active Directory OAuth som du kan välja anger du följande egenskapsvärden:

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

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ActiveDirectoryOAuth",
         "tenant": "@parameters('tenantIdParam')",
         "audience": "https://management.core.windows.net/",
         "clientId": "@parameters('clientIdParam')",
         "credentialType": "Secret",
         "secret": "@parameters('secretParam')"
     }
   },
   "runAfter": {}
}

Råautentisering

Om raw-alternativet ä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 kan du manuellt skapa det auktoriseringshuvudvärde som du skickar med den utgående begäran och ange rubrikvärdet i utlösaren eller åtgärden.

Här är till exempel ett exempelhuvud för en HTTPS-begäran som följer OAuth 1.0-protokollet:

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

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

När du använder säkra parametrar för att hantera och skydda känslig information, till exempel i en Azure Resource Manager-mallför att automatisera distributionen, kan du använda uttryck för att komma åt dessa parametervärden vid körning. Den här http-exempelåtgärdsdefinitionen anger autentiseringen som type och använder funktionen Raw 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 för hanterad identitet är tillgängligt för utlösaren eller åtgärden som stöder autentisering med hanterad identitet kanlogikappen använda den här identiteten för att autentisera åtkomst till Azure-resurser som skyddas av Azure Active Directory (Azure AD) i stället för autentiseringsuppgifter, hemligheter eller Azure AD-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 Azure AD-token direkt. Läs mer om Azure-tjänster som stöder hanterade identiteter för Azure AD-autentisering.

• Resurstypen Logikapp (förbrukning) kan använda den systemtilldelningsidentitet eller en användartilldelningsidentitet som skapats manuellt.

• Resurstypen Logic App (Standard) kan bara använda den systemtilldelningsidentitet som aktiveras automatiskt. Den användar tilldelade identiteten är för närvarande inte tillgänglig.

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 ställer in 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 Functions.

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)	Obligatorisk	Värde	Beskrivning
   Autentisering	type	Yes	Hanterad identitet eller ManagedServiceIdentity	Den autentiseringstyp som ska användas
   Hanterad identitet	identity	Yes	* System tilldelad hanterad identitet eller SystemAssigned * <användar-assigned-identity-ID>	Den hanterade identitet som ska användas
   Målgrupp	audience	Yes	<målresurs-ID>	Resurs-ID:t för den målresurs 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 även 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 Azure AD förväntar sig, inklusive eventuella avslutande snedstreck som krävs. https://storage.azure.com/Resurs-ID: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 något avslutande snedstreck. Information om hur du hittar de här resurs-ID:erna finns i Azure-tjänster som stöder Azure AD.

   När du använder skyddade parametrar för att hantera och skydda känslig information, till exempel i en Azure Resource Manager-mallfö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 och använder funktionen ManagedServiceIdentity parameters() för att hämta parametervärdena:

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

   Utlösare och åtgärder för hanterad anslutningsapp

   Egenskap (designer)	Obligatorisk	Värde	Beskrivning
   Anslutningsnamn	Yes	<anslutningsnamn>
   Hanterade identiteter	Yes	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 deras anslutningsappar i Azure Logic Apps kan du blockera möjligheten att skapa dessa anslutningar för specifika anslutningsappar i logikapparbetsflö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 stöd för alla effektnivåer i de regioner som beskrivs i isoleringsvägledningen för Azure Government effektnivå 5. För att uppfylla dessa krav stöder Logic Apps möjligheten 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 i dina logikappar och undvika att dela beräkningsresurser med andra klienter.

• Om du vill köra din egen kod eller utföra XML-transformering skapar du och anropar en Azure-funktioni stället för att använda den infogade kodfunktionen eller ange sammansättningar som ska användas som mappar. Konfigurera även värdmiljön för funktionsappen så att den uppfyller dina isoleringskrav.

  För att till exempel uppfylla kraven för effektnivå 5 skapar du din funktionsapp med App Service plan 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 ger nätverksisolering utöver beräkningsisolering för dina appar och maximala utskalningsfunktioner.

  Mer information finns i följande dokumentation:

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

• Beroende på om du använder flera klienter eller en enskild klientorganisation Azure Logic Appshar du följande alternativ:

  • Med logikappar baserade på en enda klientorganisation kan du kommunicera privat och säkert mellan logikapparbetsflöden och ett virtuellt Azure-nätverk genom att konfigurera privata slutpunkter för inkommande trafik och använda integrering av virtuella nätverk för utgående trafik. Mer information finns i Skydda trafik mellan virtuella nätverk och en enskild klientorganisation Azure Logic Apps privata slutpunkter.

  • Med logikappar för flera innehavare kan du skapa och köra dina logikappar i en integrationstjänstmiljö (ISE). På så sätt kan dina logikappar köras på dedikerade resurser och komma åt resurser som skyddas av ett virtuellt Azure-nätverk. Om du vill ha mer kontroll över krypteringsnycklarna som används av Azure Storage kan du konfigurera, använda och hantera din egen nyckel med hjälp av Azure Key Vault. Den här funktionen kallas även "Bring Your Own Key" (BYOK) och din nyckel kallas för en "kund-hanterad nyckel". Mer information finns i Konfigurera kund hanterade nycklar för att kryptera vilodata för integrationstjänstmiljöer (ISE) i Azure Logic Apps.

  Viktigt

  Vissa virtuella Azure-nätverk använder privata slutpunkter(Azure Private Link)för att ge åtkomst till Azure PaaS-tjänster, till exempel Azure Storage, Azure Cosmos DB eller Azure SQL Database, partnertjänster eller kundtjänster som finns i Azure.

  Om dina arbetsflöden behöver åtkomst till virtuella nätverk som använder privata slutpunkter och du vill utveckla dessa arbetsflöden med hjälp av resurstypen Logikapp (förbrukning) måste du skapa och köra dina logikappar i en ISE. Men om du vill utveckla dessa arbetsflöden med hjälp av resurstypen Logic App (Standard) behöver du inte en ISE. I stället kan dina arbetsflöden kommunicera privat och säkert med virtuella nätverk genom att använda privata slutpunkter 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 en enskild klientorganisation Azure Logic Apps privata slutpunkter.

Mer information om isolering finns i följande dokumentation:

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

Nästa steg

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