Zabezpečený přístup a data pro pracovní postupy v Azure Logic Apps

  • Článek

Azure Logic Apps spoléhá na Službu Azure Storage k ukládání a automatickému šifrování neaktivních uložených dat. Toto šifrování chrání vaše data a pomáhá dodržet závazky vaší organizace z hlediska zabezpečení a dodržování předpisů. Ve výchozím nastavení služba Azure Storage používá k šifrování dat klíče spravované Microsoftem. Další informace najdete v tématu Šifrování služby Azure Storage pro neaktivní uložená data.

Pokud chcete podrobněji řídit přístup a chránit citlivá data v Azure Logic Apps, můžete nastavit vyšší zabezpečení v těchto oblastech:

Další informace o zabezpečení v Azure najdete v těchto tématech:

Přístup k operacím aplikace logiky

V případě aplikací logiky Consumption potřebujete před vytvořením nebo správou aplikací logiky a jejich připojení konkrétní oprávnění, která jsou poskytována prostřednictvím rolí pomocí řízení přístupu na základě role Azure (Azure RBAC). Můžete také nastavit oprávnění tak, aby mohli spouštět konkrétní úlohy, jako je správa, úpravy a zobrazení aplikací logiky jenom konkrétní uživatelé nebo skupiny. Abyste mohli řídit jejich oprávnění, můžete členům, kteří mají přístup k vašemu předplatnému Azure, přiřadit předdefinované nebo přizpůsobené role. Azure Logic Apps má následující konkrétní role na základě toho, jestli máte pracovní postup aplikace logiky Consumption nebo Standard:

Pracovní postupy consumption
Role Popis
Přispěvatel aplikace logiky Pracovní postupy aplikací logiky můžete spravovat, ale nemůžete k nim měnit přístup.
Operátor aplikace logiky Pracovní postupy aplikací logiky můžete číst, povolit a zakázat, ale nemůžete je upravovat ani aktualizovat.
Přispěvatel Máte úplný přístup ke správě všech prostředků, ale nemůžete přiřazovat role v Azure RBAC, spravovat přiřazení v Azure Blueprints nebo sdílet galerie imagí.

Předpokládejme například, že musíte pracovat s pracovním postupem aplikace logiky, který jste nevytvořili a ověřili připojení používaná tímto pracovním postupem aplikace logiky. Vaše předplatné Azure vyžaduje oprávnění přispěvatele pro skupinu prostředků, která obsahuje daný prostředek aplikace logiky. Pokud vytvoříte prostředek aplikace logiky, budete mít automaticky přístup přispěvatele.

Pokud chcete ostatním zabránit ve změně nebo odstranění pracovního postupu aplikace logiky, můžete použít zámek prostředků Azure. Tato funkce brání ostatním v změně nebo odstranění produkčních prostředků. Další informace o zabezpečení připojení najdete v tématu konfigurace Připojení v Azure Logic Apps a Připojení zabezpečení a šifrování.

Standardní pracovní postupy

Poznámka:

Tato funkce je ve verzi Preview a podléhá dodatečným podmínkám použití pro microsoft Azure Preview.

Role Popis
Logic Apps Standard Reader (Preview) Máte přístup jen pro čtení ke všem prostředkům ve standardní aplikaci logiky a pracovních postupech, včetně spuštění pracovního postupu a jejich historie.
Standardní operátor Logic Apps (Preview) Máte přístup k povolení, opětovnému odeslání a zakázání pracovních postupů a k vytváření připojení ke službám, systémům a sítím pro standardní aplikaci logiky. Role Operátor může provádět úlohy správy a podpory na platformě Azure Logic Apps, ale nemá oprávnění k úpravám pracovních postupů nebo nastavení.
Logic Apps Standard Developer (Preview) Máte přístup k vytváření a úpravám pracovních postupů, připojení a nastavení pro standardní aplikaci logiky. Role Vývojář nemá oprávnění provádět změny mimo rozsah pracovních postupů, například změny v celé aplikaci, jako je konfigurace integrace virtuální sítě. Plány služby App Service se nepodporují.
Standardní přispěvatel Logic Apps (Preview) Máte přístup ke správě všech aspektů standardní aplikace logiky, ale nemůžete změnit přístup ani vlastnictví.

Přístup k datům historie spuštění

Během spuštění aplikace logiky se všechna data během přenosu šifrují pomocí protokolu TLS (Transport Layer Security) a neaktivních uložených dat. Po dokončení spuštění aplikace logiky můžete zobrazit historii tohoto spuštění, včetně kroků, které běžely spolu se stavem, dobou trvání, vstupy a výstupy pro každou akci. Tento bohatý detail poskytuje přehled o tom, jak vaše aplikace logiky běžela a kde můžete začít řešit případné problémy, které nastanou.

Když zobrazíte historii spuštění aplikace logiky, Azure Logic Apps ověří váš přístup a pak poskytne odkazy na vstupy a výstupy požadavků a odpovědí pro každé spuštění. U akcí, které zpracovávají všechna hesla, tajné kódy, klíče nebo jiné citlivé informace, ale chcete ostatním zabránit v prohlížení a přístupu k těmto datům. Pokud například vaše aplikace logiky získá tajný kód ze služby Azure Key Vault , který se použije při ověřování akce HTTP, chcete tento tajný kód skrýt ze zobrazení.

Pokud chcete řídit přístup ke vstupům a výstupům v historii spuštění aplikace logiky, máte tyto možnosti:

Omezení přístupu podle rozsahu IP adres

Přístup ke vstupům a výstupům v historii spuštění pracovních postupů aplikace logiky můžete omezit tak, aby tato data mohly zobrazit jenom požadavky z konkrétních rozsahů IP adres.

Pokud chcete například blokovat přístup ke vstupům a výstupům, zadejte rozsah IP adres, například 0.0.0.0-0.0.0.0. Toto omezení může odebrat jenom osoba s oprávněními správce, která umožňuje přístup k datům v pracovních postupech aplikace logiky za běhu. Platný rozsah IP adres používá tyto formáty: x.x.x.x/x nebo x.x.x-x.x.x.x.x.

Pokud chcete zadat povolené rozsahy IP adres, postupujte podle těchto kroků pro azure portal nebo šablonu Azure Resource Manageru:

Pracovní postupy consumption

  1. Na webu Azure Portal otevřete pracovní postup aplikace logiky v návrháři.

  2. V nabídce aplikace logiky v části Nastavení vyberte Nastavení pracovního postupu.

  3. V části Konfigurace>řízení přístupu Povolené příchozí IP adresy vyberte Konkrétní rozsahy IP adres.

  4. V části Rozsahy IP adres pro obsah zadejte rozsahy IP adres, které mají přístup k obsahu ze vstupů a výstupů.

Standardní pracovní postupy

  1. Na webu Azure Portal otevřete prostředek aplikace logiky.

  2. V nabídce aplikace logiky v části Nastavení vyberte Sítě.

  3. V části Příchozí provoz vyberte Omezení přístupu.

  4. Vytvořte jedno nebo více pravidel pro povolení nebo zamítnutí požadavků z konkrétních rozsahů IP adres. Můžete také použít nastavení filtru hlaviček HTTP a nastavení předávání.

    Další informace najdete v tématu Blokování příchozích IP adres ve službě Azure Logic Apps (Standard).

Zabezpečení dat v historii spuštění pomocí obfuskace

Mnoho triggerů a akcí má nastavení pro zabezpečení vstupů, výstupů nebo obojího z historie spuštění aplikace logiky. Tyto možnosti podporují všechny spravované konektory a vlastní konektory . Následující integrované operaceale tyto možnosti nepodporují:

Zabezpečené vstupy – nepodporované Zabezpečené výstupy – nepodporované
Připojení k proměnné pole
Připojení k řetězcové proměnné
Proměnná dekrementace
Pro každý
Pokud
Proměnná přírůstku
Inicializace proměnné
Opakování
Rozsah
Nastavit proměnnou
Přepnout
Ukončit
Do		 Připojení k proměnné pole
Připojení k řetězcové proměnné
Skládat
Proměnná dekrementace
Pro každý
Pokud
Proměnná přírůstku
Inicializace proměnné
Parsování JSON
Opakování
Reakce
Rozsah
Nastavit proměnnou
Přepnout
Ukončit
Dokud
Wait

Důležité informace o zabezpečení vstupů a výstupů

Než použijete tato nastavení, abyste mohli tato data zabezpečit, projděte si tyto důležité informace:

  • Když zakryjete vstupy nebo výstupy triggeru nebo akce, Azure Logic Apps neodesílá zabezpečená data do Azure Log Analytics. Do této aktivační události nebo akce pro monitorování také nemůžete přidat sledované vlastnosti .

  • Rozhraní API Azure Logic Apps pro zpracování historie pracovních postupů nevrací zabezpečené výstupy.

  • Pokud chcete zabezpečit výstupy z akce, která zakrývá vstupy nebo explicitně zakrývá výstupy, zapněte v této akci ručně zabezpečené výstupy .

  • Ujistěte se, že v podřízených akcích zapnete zabezpečené vstupy nebo zabezpečené výstupy , u kterých očekáváte, že historie spuštění tato data zakrývá.

    Nastavení Zabezpečené výstupy

    Když v triggeru nebo akci ručně zapnete zabezpečené výstupy , Azure Logic Apps tyto výstupy skryje v historii spuštění. Pokud podřízená akce tyto zabezpečené výstupy explicitně používá jako vstupy, Azure Logic Apps skryje vstupy této akce v historii spuštění, ale nepovoluje nastavení zabezpečených vstupů akce.

    Zabezpečené výstupy jako vstupy a podřízený dopad na většinu akcí

    Akce Compose, Parse JSON a Response mají pouze nastavení Zabezpečené vstupy . Když je toto nastavení zapnuté, skryje se také výstupy těchto akcí. Pokud tyto akce jako vstupy explicitně používají upstreamové zabezpečené výstupy, Azure Logic Apps skryje vstupy a výstupy těchto akcí, ale nepovoluje nastavení zabezpečených vstupů těchto akcí. Pokud podřízená akce explicitně používá skryté výstupy z akcí Compose, Parse JSON nebo Response jako vstupy, Azure Logic Apps neskryje vstupy ani výstupy podřízené akce.

    Zabezpečené výstupy jako vstupy s následným dopadem na konkrétní akce

    Nastavení zabezpečených vstupů

    Když v triggeru nebo akci ručně zapnete zabezpečené vstupy , Azure Logic Apps tyto vstupy skryje v historii spuštění. Pokud podřízená akce explicitně používá viditelné výstupy z tohoto triggeru nebo akce jako vstupy, Azure Logic Apps skryje vstupy této podřízené akce v historii spuštění, ale v této akci nepovolujezabezpečené vstupy a neukrývá výstupy této akce.

    Zabezpečený vstup a podřízený dopad na většinu akcí

    Pokud akce Compose, Parse JSON a Response explicitně používají viditelné výstupy z triggeru nebo akce se zabezpečenými vstupy, Azure Logic Apps skryje vstupy a výstupy těchto akcí, ale nepovolí nastavení Secure Vstupy této akce. Pokud podřízená akce explicitně používá skryté výstupy z akcí Compose, Parse JSON nebo Response jako vstupy, Azure Logic Apps neskryje vstupy ani výstupy podřízené akce.

    Zabezpečený vstup a podřízený dopad na konkrétní akce

Zabezpečené vstupy a výstupy v návrháři

  1. Na webu Azure Portal otevřete pracovní postup aplikace logiky v návrháři.

  2. V návrháři vyberte trigger nebo akci, ve které chcete zabezpečit citlivá data.

  3. V podokně informací, které se otevře, vyberte Nastavení a rozbalte položku Zabezpečení.

    Snímek obrazovky s webem Azure Portal, návrhářem pracovního postupu a triggerem nebo akcí s otevřeným nastavením

  4. Zapněte buď zabezpečené vstupy, zabezpečené výstupy, nebo obojí.

    Snímek obrazovky znázorňující pracovní postup s povoleným nastavením zabezpečených vstupů nebo zabezpečených výstupů akce

    Trigger nebo akce teď v záhlaví zobrazuje ikonu zámku. Všechny tokeny, které představují zabezpečené výstupy z předchozích akcí, zobrazují také ikony zámků. Například po výběru tokenu pro zabezpečený výstup ze seznamu dynamického obsahu zobrazí tento token ikonu zámku.

    Snímek obrazovky znázorňující pracovní postup s otevřeným seznamem dynamického obsahu následující akce a tokenem předchozí akce pro zabezpečený výstup s ikonou zámku

  5. Po spuštění pracovního postupu můžete zobrazit historii tohoto spuštění.

    1. V nabídce aplikace logiky Consumption nebo v nabídce Standardní pracovní postup vyberte Přehled .

    2. V části Historie spuštění vyberte spuštění, které chcete zobrazit.

    3. V podokně historie spuštění pracovního postupu vyberte akce, které chcete zkontrolovat.

      Pokud jste se rozhodli skrýt vstupy i výstupy, tyto hodnoty se teď zobrazují skryté.

      Snímek obrazovky znázorňující zobrazení historie spuštění standardního pracovního postupu se skrytými vstupy a výstupy

Zabezpečené vstupy a výstupy v zobrazení kódu

V podkladové definici triggeru nebo akce přidejte nebo aktualizujte runtimeConfiguration.secureData.properties pole pomocí obou těchto hodnot:

  • "inputs": Zabezpečuje vstupy v historii spuštění.
  • "outputs": Zabezpečuje výstupy v historii spuštění.
"<trigger-or-action-name>": {
   "type": "<trigger-or-action-type>",
   "inputs": {
      <trigger-or-action-inputs>
   },
   "runtimeConfiguration": {
      "secureData": {
         "properties": [
            "inputs",
            "outputs"
         ]
      }
   },
   <other-attributes>
}

Přístup ke vstupům parametrů

Pokud nasazujete v různých prostředích, zvažte parametrizaci hodnot v definici pracovního postupu, které se liší v závislosti na těchto prostředích. Díky tomu se můžete vyhnout pevně zakódovaným datům pomocí šablony Azure Resource Manageru k nasazení aplikace logiky , ochraně citlivých dat definováním zabezpečených parametrů a předáním dat jako samostatných vstupů prostřednictvím parametrů šablony pomocí souboru parametrů.

Pokud například ověřujete akce HTTP pomocí OAuth pomocí Microsoft Entra ID, můžete definovat a zakrýt parametry, které přijímají ID klienta a tajný klíč klienta, které se používají k ověřování. Pokud chcete definovat tyto parametry v pracovním postupu aplikace logiky, použijte parameters pro nasazení oddíl v definici pracovního postupu aplikace logiky a šablonu Resource Manageru. Chcete-li pomoct zabezpečit hodnoty parametrů, které nechcete zobrazit při úpravách aplikace logiky nebo zobrazení historie spuštění, definujte parametry pomocí securestring nebo secureobject typu a podle potřeby použijte kódování. Parametry, které mají tento typ, se nevrácejí s definicí prostředku a nejsou přístupné při prohlížení prostředku po nasazení. Pokud chcete získat přístup k těmto hodnotám parametrů za běhu, použijte @parameters('<parameter-name>') výraz uvnitř definice pracovního postupu. Tento výraz je vyhodnocen pouze za běhu a je popsán jazykem definice pracovního postupu.

Poznámka:

Pokud použijete parametr v hlavičce nebo textu požadavku, může být tento parametr viditelný při zobrazení historie spuštění pracovního postupu a odchozího požadavku HTTP. Ujistěte se, že jste také nastavili zásady přístupu k obsahu odpovídajícím způsobem. Pomocí obfuskace můžete také skrýt vstupy a výstupy v historii spuštění. Ve výchozím nastavení Authorization nejsou hlavičky viditelné prostřednictvím vstupů nebo výstupů. Takže pokud se tam použije tajný klíč, tento tajný kód se nedá načíst.

Další informace najdete v těchto částech tohoto tématu:

Pokud automatizujete nasazení pro aplikace logiky pomocí šablon Resource Manageru, můžete definovat zabezpečené parametry šablony, které se vyhodnocují při nasazení pomocí typů securestring a secureobject typů. Pokud chcete definovat parametry šablony, použijte oddíl nejvyšší úrovně parameters šablony, který je oddělený a odlišný od oddílu parameters definice pracovního postupu. Pokud chcete zadat hodnoty parametrů šablony, použijte samostatný soubor parametrů.

Pokud například používáte tajné kódy, můžete definovat a používat zabezpečené parametry šablony, které tyto tajné kódy načítají ze služby Azure Key Vault při nasazení. Pak můžete v souboru parametrů odkazovat na trezor klíčů a tajný kód. Další informace najdete v těchto tématech:

Zabezpečené parametry v definicích pracovního postupu (pracovní postup Consumption)

Pokud chcete chránit citlivé informace v definici pracovního postupu aplikace logiky, použijte zabezpečené parametry, aby tyto informace po uložení pracovního postupu aplikace logiky nebylo viditelné. Předpokládejme například, že máte akci HTTP, která vyžaduje základní ověřování, které používá uživatelské jméno a heslo. V definici parameters pracovního postupu oddíl definuje parametry basicAuthPasswordParambasicAuthUsernameParam pomocí securestring typu. Definice akce pak odkazuje na tyto parametry v oddílu 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": {}
}

Zabezpečené parametry v šablonách Azure Resource Manageru (pracovní postup Consumption)

Šablona Resource Manageru pro prostředek aplikace logiky a pracovní postup obsahuje několik parameters oddílů. Pokud chcete chránit hesla, klíče, tajné kódy a další citlivé informace, definujte zabezpečené parametry na úrovni šablony a na úrovni definice pracovního postupu pomocí securestring typu nebo secureobject typu. Tyto hodnoty pak můžete uložit ve službě Azure Key Vault a pomocí souboru parametrů odkazovat na trezor klíčů a tajný klíč. Vaše šablona pak načte informace při nasazení. Další informace najdete v tématu Předání citlivých hodnot při nasazení pomocí služby Azure Key Vault.

Tento seznam obsahuje další informace o těchto parameters oddílech:

  • Na nejvyšší úrovni parameters šablony oddíl definuje parametry pro hodnoty, které šablona používá při nasazení. Tyto hodnoty mohou například zahrnovat připojovací řetězec pro konkrétní prostředí nasazení. Tyto hodnoty pak můžete uložit do samostatného souboru parametrů, což usnadňuje změnu těchto hodnot.

  • V definici prostředku aplikace logiky, parameters ale mimo definici pracovního postupu určuje oddíl hodnoty parametrů definice pracovního postupu. V této části můžete tyto hodnoty přiřadit pomocí výrazů šablon, které odkazují na parametry šablony. Tyto výrazy se vyhodnocují při nasazení.

  • V definici parameters pracovního postupu oddíl definuje parametry, které pracovní postup aplikace logiky používá za běhu. Tyto parametry pak můžete odkazovat v pracovním postupu aplikace logiky pomocí výrazů definice pracovního postupu, které se vyhodnocují za běhu.

Tato ukázková šablona s více zabezpečenými definicemi parametrů, které používají securestring tento typ:

Název parametru Popis
TemplatePasswordParam Parametr šablony, který přijímá heslo, které se pak předá parametru definice basicAuthPasswordParam pracovního postupu
TemplateUsernameParam Parametr šablony, který přijímá uživatelské jméno, které se pak předá parametru definice basicAuthUserNameParam pracovního postupu
basicAuthPasswordParam Parametr definice pracovního postupu, který přijímá heslo pro základní ověřování v akci HTTP
basicAuthUserNameParam Parametr definice pracovního postupu, který přijímá uživatelské jméno pro základní ověřování v akci HTTP 
{
   "$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": {}
}

Typy ověřování pro konektory, které podporují ověřování

Následující tabulka uvádí typy ověřování, které jsou k dispozici v operacích konektoru, kde můžete vybrat typ ověřování:

Authentication type Aplikace logiky a podporované konektory
Basic Azure API Management, Aplikace Azure Services, HTTP, HTTP + Swagger, HTTP Webhook
Klientský certifikát Azure API Management, Aplikace Azure Services, HTTP, HTTP + Swagger, HTTP Webhook
Active Directory OAuth - Consumption: Azure API Management, Aplikace Azure 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, HTTP Webhook, SQL Server
Syrové Azure API Management, Aplikace Azure Services, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
Spravovaná identita Integrované konektory:

- Consumption: Azure API Management, Aplikace Azure Services, Azure Functions, HTTP, HTTP, HTTP Webhook

- Standard: Azure Automation, Azure Blob Storage, Azure Event Hubs, Azure Queues, Azure Service Bus, Azure Tables, HTTP, HTTP, HTTP Webhook, SQL Server

Poznámka: V současné době většina integrovaných konektorů založených na poskytovatelích služeb nepodporuje výběr spravovaných identit přiřazených uživatelem pro ověřování.

Spravované konektory: Aplikace Azure 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, Virtuální počítač Azure, HTTP s MICROSOFT Entra ID, SQL Server

Přístup k příchozím voláním triggerů založených na požadavcích

Příchozí volání, která aplikace logiky přijímá prostřednictvím triggeru založeného na požadavku, jako je trigger požadavku nebo trigger HTTP Webhook, podporuje šifrování a jsou zabezpečená protokolem TLS (Transport Layer Security) minimálně 1.2, dříve označovaným jako SSL (Secure Sockets Layer). Azure Logic Apps vynucuje tuto verzi při přijímání příchozího volání triggeru požadavku nebo zpětného volání triggeru nebo akce webhooku HTTP. Pokud dojde k chybám handshake protokolu TLS, ujistěte se, že používáte protokol TLS 1.2. Další informace najdete v tématu Řešení problému s protokolem TLS 1.0.

Pro příchozí volání použijte následující šifrovací sady:

  • 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

Poznámka:

Kvůli zpětné kompatibilitě služba Azure Logic Apps v současné době podporuje některé starší šifrovací sady. Při vývoji nových aplikací ale starší šifrovací sady nepoužívejte, protože tyto sady nemusí být v budoucnu podporovány.

Pokud například při používání služby Azure Logic Apps nebo pomocí nástroje zabezpečení na adrese URL aplikace logiky zkontrolujete zprávy handshake protokolu TLS, můžete například najít následující šifrovací sady. Znovu nepoužívejte tyto starší sady:

  • 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

Následující seznam obsahuje další způsoby, jak omezit přístup k triggerům, které přijímají příchozí volání do aplikace logiky, aby vaši aplikaci logiky mohli volat jenom autorizovaní klienti:

Generování sdílených přístupových podpisů (SAS)

Každý koncový bod požadavku v aplikaci logiky má sdílený přístupový podpis (SAS) v adrese URL koncového bodu, který má tento formát:

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

Každá adresa URL obsahuje spparametr , sva sig parametr dotazu, jak je popsáno v této tabulce:

Parametr dotazu Popis
sp Určuje oprávnění pro povolené metody HTTP, které se mají použít.
sv Určuje verzi SAS, která se má použít k vygenerování podpisu.
sig Určuje podpis, který se má použít k ověřování přístupu k triggeru. Tento podpis se generuje pomocí algoritmu SHA256 s tajným přístupovým klíčem na všech cestách a vlastnostech adresy URL. Tento klíč se uchovává zašifrovaný, uložený v aplikaci logiky a nikdy se nezveřejní ani nepublikuje. Aplikace logiky autorizuje pouze triggery, které obsahují platný podpis vytvořený s tajným klíčem.

Příchozí volání koncového bodu požadavku můžou používat pouze jedno schéma autorizace, sas nebo OAuth s ID Microsoft Entra. I když použití jednoho schématu nezakazuje druhé schéma, použití obou schémat současně způsobí chybu, protože služba neví, které schéma zvolit.

Další informace o zabezpečení přístupu pomocí sdíleného přístupového podpisu najdete v těchto částech tohoto tématu:

Opětovné generování přístupových klíčů

Pokud chcete kdykoli vygenerovat nový přístupový klíč zabezpečení, použijte rozhraní Azure REST API nebo Azure Portal. Všechny dříve vygenerované adresy URL, které používají starý klíč, jsou neplatné a už nemají autorizaci k aktivaci aplikace logiky. Adresy URL, které načtete po regeneraci, jsou podepsané novým přístupovým klíčem.

  1. Na webu Azure Portal otevřete aplikaci logiky s klíčem, který chcete znovu vygenerovat.

  2. V nabídce prostředků aplikace logiky v části Nastavení vyberte Přístupové klíče.

  3. Vyberte klíč, který chcete znovu vygenerovat, a dokončete proces.

Vytvoření adres URL zpětného volání s vypršenou platností

Pokud sdílíte adresu URL koncového bodu pro trigger založený na požadavku s jinými stranami, můžete vygenerovat adresy URL zpětného volání, které používají konkrétní klíče a mají data vypršení platnosti. Tímto způsobem můžete bezproblémově zavádět klíče nebo omezit přístup k aktivaci aplikace logiky na základě konkrétního časového rozsahu. Pokud chcete zadat datum vypršení platnosti adresy URL, použijte rozhraní REST API služby Azure Logic Apps, například:

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

Do textu zahrňte NotAftervlastnost pomocí řetězce data JSON. Tato vlastnost vrátí adresu URL zpětného NotAfter volání, která je platná pouze do data a času.

Vytvoření adres URL s primárním nebo sekundárním tajným klíčem

Když vygenerujete nebo vypíšete adresy URL zpětného volání pro trigger založený na požadavku, můžete zadat klíč, který se má použít k podepisování adresy URL. Pokud chcete vygenerovat adresu URL podepsanou konkrétním klíčem, použijte rozhraní REST API pro Logic Apps, například:

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

Do těla zahrňte KeyType vlastnost buď nebo PrimarySecondary. Tato vlastnost vrátí adresu URL podepsanou zadaným klíčem zabezpečení.

Povolení otevřeného ověřování Microsoft Entra ID (Microsoft Entra ID OAuth)

V pracovním postupu aplikace logiky Consumption, který začíná triggerem založeným na požadavku, můžete ověřit příchozí volání odesílaná do koncového bodu vytvořeného danou aktivační událostí povolením OAuth Microsoft Entra ID. Pokud chcete toto ověřování nastavit, definujte nebo přidejte zásady autorizace na úrovni aplikace logiky. Příchozí volání tak k autorizaci používají přístupové tokeny OAuth.

Když pracovní postup aplikace logiky obdrží příchozí požadavek, který obsahuje přístupový token OAuth, Služba Azure Logic Apps porovná deklarace identity tokenu s deklaracemi, které jsou určené jednotlivými zásadami autorizace. Pokud mezi deklaracemi identity tokenu a všemi deklaracemi identity v alespoň jedné zásadě existuje shoda, autorizace pro příchozí požadavek proběhne úspěšně. Token může mít více deklarací identity než číslo určené zásadou autorizace.

V pracovním postupu standardní aplikace logiky, který začíná triggerem požadavku (ale ne triggerem webhooku), můžete použít zřízení Azure Functions k ověřování příchozích volání odeslaných do koncového bodu vytvořeného tímto triggerem pomocí spravované identity. Toto zřízení se také označuje jako "Easy Auth". Další informace najdete v pracovních postupech triggerů ve standardních aplikacích logiky pomocí snadného ověřování.

Důležité informace před povolením OAuth s Microsoft Entra ID

  • Příchozí volání koncového bodu požadavku může používat pouze jedno schéma autorizace, a to buď OAuth s Microsoft Entra ID, nebo sdíleným přístupovým podpisem (SAS). I když použití jednoho schématu nezakazuje druhé schéma, použití obou schémat současně způsobí chybu, protože Azure Logic Apps neví, které schéma se má zvolit.

  • Azure Logic Apps podporuje autorizační schémata nosného typu nebo ověření typu vlastnictví (pouze aplikace logiky Consumption) pro přístupové tokeny Microsoft Entra ID OAuth. Hlavička Authorization přístupového tokenu však musí určovat Bearer typ nebo PoP typ. Další informace o získání a použití tokenu PoP najdete v tématu Získání tokenu PoP (Proof of Possession).

  • Prostředek aplikace logiky je omezený na maximální počet zásad autorizace. Každá zásada autorizace má také maximální počet deklarací identity. Další informace najdete v tématu Omezení a konfigurace pro Azure Logic Apps.

  • Zásady autorizace musí obsahovat alespoň deklaraci identity vystavitele , která má hodnotu začínající https://sts.windows.net/ buď nebo https://login.microsoftonline.com/ (OAuth V2) jako ID vystavitele Microsoft Entra.

    Předpokládejme například, že prostředek aplikace logiky má zásady autorizace, které vyžadují dva typy deklarací identity, cílovou skupinu a vystavitele. Tato ukázková část datové části dekódovaného přístupového tokenu obsahuje oba typy deklarací identity, kde aud je hodnota Cílové skupiny a iss je hodnotou Vystavitel:

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

Povolte OAuth Microsoft Entra ID jako jedinou možnost volání koncového bodu požadavku.

  1. Nastavte trigger požadavku nebo webhooku HTTP s možností zkontrolovat přístupový token OAuth podle kroků pro zahrnutí hlavičky Autorizace do výstupů triggeru požadavku nebo webhooku HTTP.

    Poznámka:

    Tento krok zviditelní Authorization záhlaví v historii spuštění pracovního postupu a ve výstupech triggeru.

  2. Na webu Azure Portal otevřete pracovní postup aplikace logiky Consumption v návrháři.

  3. V návrháři vyberte trigger. V podokně informací, které se otevře, vyberte Nastavení.

  4. V části Obecné>podmínky triggeru vyberte Přidat. Do pole podmínky triggeru zadejte některý z následujících výrazů na základě typu tokenu, který chcete použít:

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

    nebo

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

Pokud zavoláte koncový bod triggeru bez správné autorizace, historie spuštění jenom zobrazí trigger jako Skipped bez jakékoli zprávy, že podmínka triggeru selhala.

Získání tokenu důkazu o vlastnictví (PoP)

Knihovny Knihovny MSAL (Microsoft Authentication Library) poskytují tokeny PoP, které můžete použít. Pokud pracovní postup aplikace logiky, který chcete volat, vyžaduje token PoP, můžete tento token získat pomocí knihoven MSAL. Následující ukázky ukazují, jak získat tokeny PoP:

Pokud chcete s pracovním postupem aplikace logiky Consumption použít token PoP, nastavte OAuth pomocí Microsoft Entra ID podle další části.

Povolení OAuth Microsoft Entra ID pro prostředek aplikace logiky Consumption

Postupujte podle těchto kroků pro web Azure Portal nebo šablonu Azure Resource Manageru:

Na webu Azure Portal přidejte k prostředku aplikace logiky Consumption jednu nebo více zásad autorizace:

  1. Na webu Azure Portal otevřete aplikaci logiky Consumption v návrháři pracovního postupu.

  2. V nabídce prostředků aplikace logiky v části Nastavení vyberte Autorizace. Po otevření podokna Autorizace vyberte Přidat zásadu.

    Snímek obrazovky s webem Azure Portal, nabídkou aplikace logiky Consumption, stránkou autorizace a vybraným tlačítkem pro přidání zásad

  3. Zadejte informace o zásadách autorizace zadáním typů deklarací identity a hodnot, které vaše aplikace logiky očekává v přístupovém tokenu prezentovaného jednotlivými příchozími voláními triggeru požadavku:

    Snímek obrazovky s webem Azure Portal, stránkou autorizace aplikace logiky Consumption a informacemi o zásadách autorizace

    Vlastnost Požaduje se Type Popis
    Název zásady Ano String Název, který chcete použít pro zásady autorizace
    Typ zásady Ano String AAD pro nosné tokeny typu nebo AADPOP pro tokeny typu Proof-of-Possession.
    Žádosti Ano String Pár klíč-hodnota, který určuje typ deklarace identity a hodnotu, kterou trigger požadavku pracovního postupu očekává v přístupovém tokenu prezentovaného jednotlivými příchozími voláními triggeru. Výběrem možnosti Přidat standardní deklaraci identity můžete přidat libovolnou standardní deklaraci identity. Pokud chcete přidat deklaraci identity specifickou pro token PoP, vyberte Přidat vlastní deklaraci identity.

    Dostupné standardní typy deklarací identity:

    - Emitenta
    - Publikum
    - Předmět
    - ID JWT (identifikátor webového tokenu JSON)

    Požadavky:

    - Minimálně musí seznam deklarací identity obsahovat deklaraci vystavitele , která má hodnotu, která začíná https://sts.windows.net/ ID vystavitele Microsoft Entra nebo https://login.microsoftonline.com/ jako JEHO ID.

    – Každá deklarace identity musí být jedna řetězcová hodnota, nikoli pole hodnot. Můžete mít například deklaraci identity s rolí jako typem a vývojářem jako hodnotou. Nemůžete mít deklaraci identity, která má roli jako typ a hodnoty nastavené na Developer and Program Manager.

    – Hodnota deklarace identity je omezena na maximální počet znaků.

    Další informace o těchto typech deklarací identity najdete v tématu Deklarace identity v tokenech zabezpečení Microsoft Entra. Můžete také zadat vlastní typ a hodnotu deklarace identity.

    Následující příklad ukazuje informace o tokenu PoP:

    Snímek obrazovky s webem Azure Portal, stránkou autorizace aplikace logiky Consumption a informacemi o zásadách kontroly vlastnictví

  4. Pokud chcete přidat další deklaraci identity, vyberte z těchto možností:

    • Pokud chcete přidat další typ deklarace identity, vyberte Přidat standardní deklaraci identity, vyberte typ deklarace a zadejte hodnotu deklarace identity.

    • Pokud chcete přidat vlastní deklaraci identity, vyberte Přidat vlastní deklaraci identity. Další informace najdete v tématu o tom, jak poskytnout volitelné deklarace identity pro vaši aplikaci. Vaše vlastní deklarace identity se pak uloží jako součást vašeho ID JWT; například "tid": "72f988bf-86f1-41af-91ab-2d7cd011db47".

  5. Pokud chcete přidat další zásady autorizace, vyberte Přidat zásadu. Opakujte předchozí kroky a nastavte zásadu.

  6. Až budete hotovi, zvolte tlačítko Uložit.

  7. Pokud chcete do výstupů triggeru založeného na požadavku zahrnout hlavičku Authorization z přístupového tokenu, zkontrolujte, jestli do výstupů triggeru požadavku a http webhooku zahrnete hlavičku Autorizace.

Vlastnosti pracovního postupu, jako jsou zásady, se nezobrazují v zobrazení kódu pracovního postupu na webu Azure Portal. Pokud chcete získat přístup k zásadám prostřednictvím kódu programu, volejte prostřednictvím Azure Resource Manageru následující rozhraní API: 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 Nezapomeňte nahradit zástupné hodnoty pro ID předplatného Azure, název skupiny prostředků a název pracovního postupu.

Zahrnutí hlavičky Authorization do výstupů triggeru požadavku nebo webhooku HTTP

U aplikací logiky, které povolují OAuth s ID Microsoft Entra pro autorizaci příchozích volání pro přístup k triggerům založeným na žádostech, můžete povolit trigger požadavku nebo výstupy triggeru HTTP Webhooku tak, aby zahrnovaly hlavičku Authorization z přístupového tokenu OAuth. V podkladové definici JSON triggeru přidejte a nastavte operationOptions vlastnost na IncludeAuthorizationHeadersInOutputs. Tady je příklad triggeru požadavku:

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

Další informace najdete v těchto tématech:

Zveřejnění pracovního postupu aplikace logiky pomocí služby Azure API Management

Pokud získáte další ověřovací protokoly a možnosti, zvažte zveřejnění pracovního postupu aplikace logiky jako rozhraní API pomocí služby Azure API Management. Tato služba poskytuje bohaté možnosti monitorování, zabezpečení, zásad a dokumentace pro libovolný koncový bod. Služba API Management může zveřejnit veřejný nebo privátní koncový bod pro vaši aplikaci logiky. K autorizaci přístupu k tomuto koncovému bodu můžete použít OAuth s ID Microsoft Entra, klientským certifikátem nebo jinými standardy zabezpečení. Když služba API Management obdrží požadavek, odešle požadavek do vaší aplikace logiky a provede potřebné transformace nebo omezení. Pokud chcete povolit, aby pracovní postup aplikace logiky volal jenom API Management, můžete omezit příchozí IP adresy aplikace logiky.

Další informace najdete v následující dokumentaci:

Omezení příchozích IP adres

Spolu se sdíleným přístupovým podpisem (SAS) můžete chtít omezit konkrétně klienty, kteří můžou volat pracovní postup aplikace logiky. Pokud například spravujete koncový bod žádosti pomocí služby Azure API Management, můžete pracovní postup aplikace logiky omezit tak, aby přijímal požadavky pouze z IP adresy instance služby API Management, kterou vytvoříte.

Bez ohledu na zadané IP adresy můžete stále spouštět pracovní postup aplikace logiky, který má trigger založený na požadavku pomocí rozhraní REST API pro Logic Apps: Triggery pracovního postupu – Žádost o spuštění nebo pomocí služby API Management. Tento scénář ale stále vyžaduje ověřování vůči rozhraní Azure REST API. Všechny události se zobrazí v protokolu auditu Azure. Ujistěte se, že jste odpovídajícím způsobem nastavili zásady řízení přístupu.

Pokud chcete omezit příchozí IP adresy pracovního postupu aplikace logiky, postupujte podle odpovídajících kroků pro azure portal nebo šablonu Azure Resource Manageru. Platný rozsah IP adres používá tyto formáty: x.x.x.x/x nebo x.x.x-x.x.x.x.x.

Omezení IP adres na webu Azure Portal ovlivňuje triggery i akce na rozdíl od popisu na portálu v části Povolené příchozí IP adresy. Pokud chcete nastavit tento filtr samostatně pro triggery a akce, použijte accessControl objekt v šabloně Azure Resource Manageru pro prostředek aplikace logiky nebo rozhraní REST API služby Azure Logic Apps: Pracovní postup – Operace vytvoření nebo aktualizace.

Pracovní postupy consumption

  1. Na webu Azure Portal otevřete aplikaci logiky Consumption v návrháři pracovního postupu.

  2. V nabídce aplikace logiky v části Nastavení vyberte Nastavení pracovního postupu.

  3. V části Konfigurace řízení přístupu v části Povolené příchozí IP adresy zvolte cestu pro váš scénář:

    • Pokud chcete, aby byl váš pracovní postup volatelný pomocí integrované akce Azure Logic Apps, ale jenom jako vnořený pracovní postup, vyberte jenom jiné Logic Apps. Tato možnost funguje jenom v případě, že k volání vnořeného pracovního postupu použijete akci Azure Logic Apps .

      Tato možnost zapíše do prostředku aplikace logiky prázdné pole a vyžaduje, aby volání pouze z nadřazených pracovních postupů, které používají integrovanou akci Azure Logic Apps, aktivovala vnořený pracovní postup.

    • Pokud chcete pracovní postup volat pomocí akce HTTP, ale pouze jako vnořený pracovní postup, vyberte Konkrétní rozsahy IP adres. Jakmile se zobrazí rozsahy IP adres pro triggery, zadejte odchozí IP adresy nadřazeného pracovního postupu. Platný rozsah IP adres používá tyto formáty: x.x.x.x/x nebo x.x.x-x.x.x.x.x.

      Poznámka:

      Pokud k volání vnořeného pracovního postupu použijete pouze jinou možnost Logic Apps a akci HTTP, volání se zablokuje a zobrazí se chyba 401 Neautorizováno.

    • Pokud chcete omezit příchozí volání z jiných IP adres, zadejte v případě, že se zobrazí rozsahy IP adres pro triggery, rozsahy IP adres, které trigger přijme. Platný rozsah IP adres používá tyto formáty: x.x.x.x/x nebo x.x.x-x.x.x.x.x.

  4. Volitelně můžete v části Omezit volání pro získání vstupních a výstupních zpráv z historie spuštění na zadané IP adresy zadat rozsahy IP adres pro příchozí volání, která mají přístup ke vstupním a výstupním zprávům v historii spuštění.

Standardní pracovní postupy

  1. Na webu Azure Portal otevřete prostředek aplikace logiky.

  2. V nabídce aplikace logiky v části Nastavení vyberte Sítě.

  3. V části Příchozí provoz vyberte Omezení přístupu.

  4. Vytvořte jedno nebo více pravidel pro povolení nebo zamítnutí požadavků z konkrétních rozsahů IP adres. Můžete také použít nastavení filtru hlaviček HTTP a nastavení předávání. Platný rozsah IP adres používá tyto formáty: x.x.x.x/x nebo x.x.x-x.x.x.x.x.

    Další informace najdete v tématu Blokování příchozích IP adres ve službě Azure Logic Apps (Standard).

Přístup k odchozím voláním dalších služeb a systémů

Na základě schopnosti cílového koncového bodu podporují odchozí volání odesílaná triggerem HTTP nebo akcí HTTP šifrování a jsou zabezpečená protokolem TLS (Transport Layer Security) 1.0, 1.1 nebo 1.2, dříve označovaným jako SSL (Secure Sockets Layer). Azure Logic Apps vyjednává s cílovým koncovým bodem s využitím nejvyšší podporované verze. Pokud například cílový koncový bod podporuje verzi 1.2, trigger HTTP nebo akce nejprve použije hodnotu 1.2. V opačném případě konektor používá další podporovanou verzi.

Tento seznam obsahuje informace o certifikátech podepsaných svým držitelem TLS/SSL:

  • U pracovních postupů aplikace logiky Consumption ve víceklientské prostředí Azure Logic Apps nepovolují operace HTTP certifikáty TLS/SSL podepsané svým držitelem. Pokud vaše aplikace logiky volá server HTTP a zobrazí certifikát podepsaný svým držitelem protokolu TLS/SSL, volání HTTP selže s chybou TrustFailure .

  • Pro pracovní postupy standardní aplikace logiky v prostředí Azure Logic Apps s jedním tenantem podporují operace HTTP certifikáty TLS/SSL podepsané svým držitelem. Musíte ale provést několik dalších kroků pro tento typ ověřování. Jinak volání selže. Další informace najdete v tématu Ověřování certifikátů TLS/SSL pro Azure Logic Apps s jedním tenantem.

    Pokud chcete místo toho použít klientský certifikát nebo OAuth s ID Microsoft Entra s typem přihlašovacích údajů certifikátu , musíte ještě provést několik dalších kroků pro tento typ ověřování. Jinak volání selže. Další informace najdete v tématu Klientský certifikát nebo OAuth s ID Microsoft Entra s typem přihlašovacích údajů "Certifikát" pro Azure Logic Apps s jedním tenantem.

Tady jsou další způsoby, jak můžete pomoct zabezpečit koncové body, které zpracovávají volání odesílaná z pracovních postupů aplikace logiky:

  • Přidejte ověřování k odchozím požadavkům.

    Když k odesílání odchozích volání použijete trigger HTTP nebo akci, můžete k požadavku odeslanému vaší aplikací logiky přidat ověřování. Můžete například vybrat tyto typy ověřování:

  • Omezte přístup z IP adres pracovního postupu aplikace logiky.

    Všechna volání koncových bodů z pracovních postupů aplikace logiky pocházejí z konkrétních určených IP adres založených na oblastech aplikací logiky. Můžete přidat filtrování, které přijímá požadavky pouze z těchto IP adres. Pokud chcete získat tyto IP adresy, projděte si limity a konfiguraci pro Azure Logic Apps.

  • Vylepšení zabezpečení pro připojení k místním systémům

    Azure Logic Apps poskytuje integraci s těmito službami, která pomáhá zajistit bezpečnější a spolehlivější místní komunikaci.

    • Místní brána dat

      Mnoho spravovaných konektorů v Azure Logic Apps usnadňuje zabezpečená připojení k místním systémům, jako je systém souborů, SQL, SharePoint a DB2. Brána odesílá data z místních zdrojů na šifrovaných kanálech prostřednictvím služby Azure Service Bus. Veškerý provoz pochází ze zabezpečeného odchozího provozu z agenta brány. Zjistěte , jak funguje místní brána dat.

    • Připojení prostřednictvím služby Azure API Management

      Azure API Management poskytuje možnosti místního připojení, jako je virtuální privátní síť typu site-to-site a integrace ExpressRoute pro zabezpečené proxy a komunikaci s místními systémy. Pokud máte rozhraní API, které poskytuje přístup k místnímu systému a toto rozhraní API jste zpřístupnili vytvořením instance služby API Management, můžete toto rozhraní API volat z pracovního postupu vaší aplikace logiky výběrem odpovídající operace služby API Management v návrháři pracovních postupů.

      Poznámka:

      Konektor zobrazuje jenom služby API Management, ve kterých máte oprávnění k zobrazení a připojení, ale nezobrazuje služby API Management založené na spotřebě.

      Na základě typu prostředku aplikace logiky postupujte podle odpovídajících kroků:

      Pracovní postupy consumption

      1. Podle toho, jestli přidáváte trigger nebo akci služby API Management, postupujte takto:

        • Aktivační událost:

          1. V návrháři pracovního postupu vyberte Přidat trigger.

          2. Po otevření podokna Přidat trigger zadejte do vyhledávacího pole službu API Management.

          3. V seznamu výsledků triggeru vyberte Zvolit trigger služby Azure API Management.

        • Akce:

          1. V návrháři pracovního postupu vyberte znaménko plus (+), kam chcete přidat akci.

          2. Po otevření podokna přidat akci zadejte do vyhledávacího pole službu API Management.

          3. V seznamu výsledků akcí vyberte Vybrat akci služby Azure API Management.

        Následující příklad ukazuje vyhledání triggeru služby Azure API Management:

        Snímek obrazovky s webem Azure Portal, návrhářem pracovního postupu Consumption a vyhledáním triggeru služby API Management

      2. V seznamu instancí služby API Management vyberte dříve vytvořenou instanci služby API Management.

      3. V seznamu operací rozhraní API vyberte operaci rozhraní API, která se má volat, a pak vyberte Přidat akci.

      Standardní pracovní postupy

      U standardních pracovních postupů můžete přidávat jenom akce služby API Management , ne triggery.

      1. V návrháři pracovního postupu vyberte znaménko plus (+), kam chcete přidat akci.

      2. Po otevření podokna přidat akci zadejte do vyhledávacího pole službu API Management.

      3. V seznamu výsledků akce vyberte Volání rozhraní API služby Azure API Management.

        Snímek obrazovky s webem Azure Portal, návrhářem standardních pracovních postupů a akcí služby Azure API Management

      4. V seznamu instancí služby API Management vyberte dříve vytvořenou instanci služby API Management.

      5. V seznamu operací rozhraní API vyberte operaci rozhraní API, která se má volat, a pak vyberte Vytvořit nový.

        Snímek obrazovky s webem Azure Portal, návrhářem standardních pracovních postupů a vybraným rozhraním API pro volání

Přidání ověřování do odchozích volání

Koncové body HTTP a HTTPS podporují různé druhy ověřování. U některých triggerů a akcí, které používáte k odesílání odchozích volání nebo požadavků do těchto koncových bodů, můžete zadat typ ověřování. V návrháři pracovního postupu mají triggery a akce, které podporují volbu typu ověřování, vlastnost Ověřování . Tato vlastnost se ale nemusí vždy zobrazovat ve výchozím nastavení. V těchto případech v triggeru nebo akci otevřete seznam Přidat nový parametr a vyberte Ověřování.

Důležité

K ochraně citlivých informací, které vaše aplikace logiky zpracovává, použijte zabezpečené parametry a podle potřeby zakódujte data. Další informace o použití a zabezpečení parametrů najdete v Accessu pro vstupy parametrů.

Základní ověřování

Pokud je k dispozici možnost Basic, zadejte tyto hodnoty vlastností:

Vlastnost (návrhář) Vlastnost (JSON) Požaduje se Hodnota Popis
Ověřování type Ano Basic Typ ověřování, který se má použít
Uživatelské jméno username Ano <uživatelské jméno> Uživatelské jméno pro ověřování přístupu k cílovému koncovému bodu služby
Heslo password Ano <Heslo> Heslo pro ověřování přístupu k cílovému koncovému bodu služby

Pokud používáte zabezpečené parametry pro zpracování a zabezpečení citlivých informací, například v šabloně Azure Resource Manageru pro automatizaci nasazení, můžete pomocí výrazů přistupovat k těmto hodnotám parametrů za běhu. Tato ukázková definice akce HTTP určuje ověřování type jako Basic a pomocí funkce parameters() získá hodnoty parametrů:

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

Ověřování klientským certifikátem

Pokud je k dispozici možnost Klientský certifikát, zadejte tyto hodnoty vlastností:

Vlastnost (návrhář) Vlastnost (JSON) Požaduje se Hodnota Popis
Ověřování type Ano Klientský certifikát
nebo
ClientCertificate		 Typ ověřování, který se má použít. Certifikáty můžete spravovat pomocí služby Azure API Management.

Poznámka: Vlastní konektory nepodporují ověřování na základě certifikátů pro příchozí i odchozí volání.
Pfx pfx Ano <encoded-pfx-file-content> Obsah kódovaný v base64 ze souboru PFX (Personal Information Exchange)

Pokud chcete převést soubor PFX do formátu kódování Base64, můžete použít PowerShell 7 pomocí následujícího postupu:

1. Uložte obsah certifikátu do proměnné:

$pfx_cert = [System.IO.File]::ReadAllBytes('c:\certificate.pfx')

2. Obsah certifikátu převeďte pomocí ToBase64String() funkce a uložte ho do textového souboru:

[System.Convert]::ToBase64String($pfx_cert) | Out-File 'pfx-encoded-bytes.txt'

Řešení potíží: Pokud používáte cert mmc/PowerShell příkaz, může se zobrazit tato chyba:

Could not load the certificate private key. Please check the authentication certificate password is correct and try again.

Pokud chcete tuto chybu vyřešit, zkuste pomocí příkazu převést soubor PFX na soubor PEM a znova openssl :

openssl pkcs12 -in certificate.pfx -out certificate.pem
openssl pkcs12 -in certificate.pem -export -out certificate2.pfx

Když pak získáte řetězec s kódováním base64 pro nově převedený soubor PFX certifikátu, řetězec teď funguje v Azure Logic Apps.
Heslo password No <password-for-pfx-file> Heslo pro přístup k souboru PFX

Poznámka:

Pokud se pokusíte ověřit pomocí klientského certifikátu pomocí OpenSSL, může se zobrazit následující chyba:

BadRequest: Could not load private key

Tuto chybu vyřešíte takto:

  1. Odinstalujte všechny instance OpenSSL.
  2. Nainstalujte OpenSSL verze 1.1.1t.
  3. Při nové aktualizaci odvolejte svůj certifikát.
  4. Při použití ověřování klientským certifikátem přidejte nový certifikát do operace HTTP.

Pokud používáte zabezpečené parametry pro zpracování a zabezpečení citlivých informací, například v šabloně Azure Resource Manageru pro automatizaci nasazení, můžete pomocí výrazů přistupovat k těmto hodnotám parametrů za běhu. Tato ukázková definice akce HTTP určuje ověřování type jako ClientCertificate a pomocí funkce parameters() získá hodnoty parametrů:

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

Důležité

Pokud máte prostředek standardní aplikace logiky v Azure Logic Apps s jedním tenantem a chcete použít operaci HTTP s certifikátem TSL/SSL, klientským certifikátem nebo ověřováním Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) s typem Certificate přihlašovacích údajů, nezapomeňte dokončit další kroky nastavení pro tento typ ověřování. Jinak volání selže. Další informace najdete v tématu Ověřování v prostředí s jedním tenantem.

Další informace o zabezpečení služeb pomocí ověřování klientských certifikátů najdete v těchto tématech:

Microsoft identity platform

Při aktivacích žádostí můžete použít platformu Microsoft Identity Platform k ověřování příchozích volání po nastavení zásad autorizace Microsoft Entra pro vaši aplikaci logiky. Pro všechny ostatní triggery a akce, které poskytují typ ověřování OAuth služby Active Directory, které můžete vybrat, zadejte tyto hodnoty vlastností:

Vlastnost (návrhář) Vlastnost (JSON) Požaduje se Hodnota Popis
Ověřování type Ano Active Directory OAuth
nebo
ActiveDirectoryOAuth		 Typ ověřování, který se má použít. Azure Logic Apps se v současné době řídí protokolem OAuth 2.0.
Orgán authority No <Url-for-authority-token-issuer> Adresa URL autority, která poskytuje přístupový token, například https://login.microsoftonline.com/ pro globální oblasti služeb Azure. V případě jiných národních cloudů si projděte koncové body ověřování Microsoft Entra – Volba vaší autority identit.
Klient tenant Ano <ID tenanta> ID tenanta pro tenanta Microsoft Entra
Publikum audience Ano <autorizace prostředku k autorizaci> Prostředek, který chcete použít k autorizaci, například https://management.core.windows.net/
ID klienta clientId Ano <client-ID> ID klienta pro aplikaci, která žádá o autorizaci
Typ přihlašovacích údajů credentialType Ano Certifikát
nebo
Tajný		 Typ přihlašovacích údajů, který klient používá k vyžádání autorizace. Tato vlastnost a hodnota se nezobrazují v podkladové definici aplikace logiky, ale určuje vlastnosti, které se zobrazí pro vybraný typ přihlašovacích údajů.
Tajný kód secret Ano, ale pouze pro typ tajných přihlašovacích údajů <tajný klíč klienta> Tajný klíč klienta pro vyžádání autorizace
Pfx pfx Ano, ale pouze pro typ přihlašovacích údajů "Certifikát" <encoded-pfx-file-content> Obsah kódovaný v base64 ze souboru PFX (Personal Information Exchange)
Heslo password Ano, ale pouze pro typ přihlašovacích údajů "Certifikát" <password-for-pfx-file> Heslo pro přístup k souboru PFX

Pokud používáte zabezpečené parametry pro zpracování a zabezpečení citlivých informací, například v šabloně Azure Resource Manageru pro automatizaci nasazení, můžete pomocí výrazů přistupovat k těmto hodnotám parametrů za běhu. Tato ukázková definice akce HTTP určuje ověřování type jako ActiveDirectoryOAuth, typ přihlašovacích údajů jako Secreta používá funkci parameters() k získání hodnot parametrů:

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

Důležité

Pokud máte prostředek standardní aplikace logiky v Azure Logic Apps s jedním tenantem a chcete použít operaci HTTP s certifikátem TSL/SSL, klientským certifikátem nebo ověřováním Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) s typem Certificate přihlašovacích údajů, nezapomeňte dokončit další kroky nastavení pro tento typ ověřování. Jinak volání selže. Další informace najdete v tématu Ověřování v prostředí s jedním tenantem.

Nezpracované ověřování

Pokud je k dispozici možnost Raw, můžete tento typ ověřování použít, pokud potřebujete použít schémata ověřování, která nedodržují protokol OAuth 2.0. S tímto typem ručně vytvoříte hodnotu autorizační hlavičky, kterou odešlete pomocí odchozího požadavku, a zadáte tuto hodnotu hlavičky v triggeru nebo akci.

Následující příklad ukazuje ukázkovou hlavičku požadavku HTTPS, která se řídí protokolem OAuth 1.0:

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

V triggeru nebo akci, která podporuje nezpracované ověřování, zadejte tyto hodnoty vlastností:

Vlastnost (návrhář) Vlastnost (JSON) Požaduje se Hodnota Popis
Ověřování type Ano Nezpracováno Typ ověřování, který se má použít
Hodnota value Ano <authorization-header-value> Hodnota autorizační hlavičky, která se má použít pro ověřování

Pokud používáte zabezpečené parametry pro zpracování a zabezpečení citlivých informací, například v šabloně Azure Resource Manageru pro automatizaci nasazení, můžete pomocí výrazů přistupovat k těmto hodnotám parametrů za běhu. Tato ukázková definice akce HTTP určuje ověřování type jako Rawa pomocí funkce parameters() získá hodnoty parametrů:

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

Ověřování spravovaných identit

Pokud je možnost spravované identity dostupná u triggeru nebo akce, která podporuje ověřování spravovaných identit, může vaše aplikace logiky tuto identitu použít k ověřování přístupu k prostředkům Azure, které jsou chráněny ID Microsoft Entra, a ne přihlašovacími údaji, tajnými kódy nebo tokeny Microsoft Entra. Azure tuto identitu spravuje za vás a pomáhá zabezpečit vaše přihlašovací údaje, protože nemusíte spravovat tajné kódy ani přímo používat tokeny Microsoft Entra. Přečtěte si další informace o službách Azure, které podporují spravované identity pro ověřování Microsoft Entra.

  • Prostředek aplikace logiky Consumption může používat identitu přiřazenou systémem nebo jednu ručně vytvořenou identitu přiřazenou uživatelem.

  • Prostředek standardní aplikace logiky podporuje povolení spravované identity přiřazené systémem a více spravovaných identit přiřazených uživatelem najednou, i když stále můžete vybrat jenom jednu identitu, kterou chcete použít.

    Poznámka:

    Ve výchozím nastavení je identita přiřazená systémem už povolená k ověřování připojení za běhu. Tato identita se liší od přihlašovacích údajů ověřování nebo připojovací řetězec, které používáte při vytváření připojení. Pokud tuto identitu zakážete, připojení nebudou za běhu fungovat. Pokud chcete toto nastavení zobrazit, vyberte v nabídce aplikace logiky v části Nastavení možnost Identita.

  1. Než bude vaše aplikace logiky moct používat spravovanou identitu, postupujte podle kroků v tématu Ověřování přístupu k prostředkům Azure pomocí spravovaných identit v Azure Logic Apps. Tímto postupem povolíte spravovanou identitu v aplikaci logiky a nastavíte přístup této identity k cílovému prostředku Azure.

  2. Než funkce Azure může používat spravovanou identitu, nejprve povolte ověřování pro funkce Azure Functions.

  3. V triggeru nebo akci, která podporuje použití spravované identity, zadejte tyto informace:

    Integrované triggery a akce

    Vlastnost (návrhář) Vlastnost (JSON) Požaduje se Hodnota Popis
    Ověřování type Ano Spravovaná identita
    nebo
    ManagedServiceIdentity    		 Typ ověřování, který se má použít
    Spravovaná identita identity No <user-assigned-identity-ID> Spravovaná identita přiřazená uživatelem, která se má použít. Poznámka: Nezahrnujte tuto vlastnost při použití spravované identity přiřazené systémem.
    Publikum audience Ano <target-resource-ID> ID prostředku cílového prostředku, ke kterému chcete získat přístup.

    https://storage.azure.com/ Například vytvoří přístupové tokeny pro ověřování platné pro všechny účty úložiště. Můžete ale také zadat adresu URL kořenové služby, například https://fabrikamstorageaccount.blob.core.windows.net pro konkrétní účet úložiště.

    Poznámka: Vlastnost Cílová skupina může být v některých triggerech nebo akcích skrytá. Pokud chcete tuto vlastnost zobrazit, otevřete v triggeru nebo akci seznam přidat nový parametr a vyberte Cílovou skupinu.

    Důležité: Ujistěte se, že toto ID cílového prostředku přesně odpovídá hodnotě, kterou očekává MICROSOFT Entra ID, včetně všech požadovaných koncových lomítek. https://storage.azure.com/ ID prostředku pro všechny účty Azure Blob Storage proto vyžaduje koncové lomítko. ID prostředku pro konkrétní účet úložiště ale nevyžaduje koncové lomítko. Pokud chcete tyto ID prostředků najít, projděte si služby Azure, které podporují ID Microsoft Entra.

    Pokud používáte zabezpečené parametry pro zpracování a zabezpečení citlivých informací, například v šabloně Azure Resource Manageru pro automatizaci nasazení, můžete pomocí výrazů přistupovat k těmto hodnotám parametrů za běhu. Například tato definice akce HTTP určuje ověřování type jako ManagedServiceIdentity a používá funkci parameters() k získání hodnot parametrů:

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

    Triggery a akce spravovaného konektoru

    Vlastnost (návrhář) Požaduje se Hodnota Popis
    Název připojení Ano <název připojení>
    Spravovaná identita Ano Spravovaná identita přiřazená systémem
    nebo
    <user-assigned-managed-identity-name>    		 Typ ověřování, který se má použít

Zablokování vytváření připojení

Pokud vaše organizace nepovoluje připojení ke konkrétním prostředkům pomocí jejich konektorů v Azure Logic Apps, můžete pomocí Azure Policy zablokovat možnost vytvořit tato připojení pro konkrétní konektory v pracovních postupech aplikace logiky. Další informace najdete v tématu Blokování připojení vytvořených konkrétními konektory v Azure Logic Apps.

Doprovodné materiály k izolaci aplikací logiky

Azure Logic Apps ve službě Azure Government můžete použít k podpoře všech úrovní dopadu v oblastech popsaných pokyny k izolaci úrovně dopadu na azure Government úrovně 5. Aby služba Azure Logic Apps splňovala tyto požadavky, podporuje schopnost vytvářet a spouštět pracovní postupy v prostředí s vyhrazenými prostředky, abyste mohli snížit dopad na výkon jiných tenantů Azure ve vašich aplikacích logiky a vyhnout se sdílení výpočetních prostředků s jinými tenanty.

  • Pokud chcete spustit vlastní kód nebo provést transformaci XML, vytvořte a volejte funkci Azure, namísto použití funkce vloženého kódu nebo poskytnutí sestavení, která se mají použít jako mapy. Nastavte také hostitelské prostředí pro vaši aplikaci funkcí tak, aby vyhovovalo vašim požadavkům na izolaci.

    Pokud chcete například splnit požadavky na úroveň 5 dopadu, vytvořte aplikaci funkcí s plánem služby App Service s využitím cenové úrovněIzolované prostředí (ASE), která používá také cenovou úroveň izolovaného prostředí. V tomto prostředí běží aplikace funkcí na vyhrazených virtuálních počítačích Azure a vyhrazených virtuálních sítích Azure, které poskytují izolaci sítě nad izolací výpočetních prostředků pro vaše aplikace a maximální možnosti škálování na více instancí.

    Další informace najdete v následující dokumentaci:

  • Na základě toho, jestli máte pracovní postupy aplikace logiky Consumption nebo Standard, máte tyto možnosti:

    • Pracovní postupy standardní aplikace logiky můžou soukromě a bezpečně komunikovat s virtuální sítí Azure prostřednictvím privátních koncových bodů, které jste nastavili pro příchozí provoz a integraci virtuální sítě pro odchozí provoz. Další informace najdete v tématu Zabezpečení provozu mezi virtuálními sítěmi a azure Logic Apps s jedním tenantem pomocí privátních koncových bodů.

    • Pracovní postupy aplikace logiky Consumption se můžou spouštět v prostředí integrační služby (ISE), kde můžou používat vyhrazené prostředky a přistupovat k prostředkům chráněným virtuální sítí Azure. Prostředek ISE se ale vyřadí 31. srpna 2024 z důvodu závislosti na službách Azure Cloud Services (classic), které současně vyřadí.

      Důležité

      Některé virtuální sítě Azure používají privátní koncové body (Azure Private Link) k poskytování přístupu ke službám Azure PaaS, jako jsou Azure Storage, Azure Cosmos DB nebo Azure SQL Database, partnerské služby nebo služby zákazníků hostované v Azure.

      Pokud chcete vytvořit pracovní postupy aplikace logiky Consumption, které potřebují přístup k virtuálním sítím s privátními koncovými body, musíte vytvořit a spustit pracovní postupy Consumption v prostředí ISE. Nebo můžete místo toho vytvořit standardní pracovní postupy, které nepotřebují ise. Místo toho můžou vaše pracovní postupy komunikovat soukromě a bezpečně s virtuálními sítěmi pomocí privátních koncových bodů pro příchozí provoz a integraci virtuální sítě pro odchozí provoz. Další informace najdete v tématu Zabezpečení provozu mezi virtuálními sítěmi a Azure Logic Apps s jedním tenantem pomocí privátních koncových bodů.

Další informace o izolaci najdete v následující dokumentaci:

Další kroky