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

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:

Přístup k operacím aplikace logiky
Přístup ke vstupům a výstupům z historie běhu
Přístup ke vstupům parametrů
Typy ověřování pro triggery a akce, které podporují ověřování
Přístup k příchozím voláním na spouštěče založené na požadavcích
Přístup k odchozím voláním do jiných služeb a systémů
Blokování vytváření připojení pro konkrétní konektory
Pokyny k izolaci pro aplikace logiky
Standardní hodnoty zabezpečení Azure pro Azure Logic Apps

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 spotřeby

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

Například předpokládejme, že musíte pracovat s workflow logické aplikace, který jste nevytvořili, a ověřte připojení používaná tímto workflow. 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 zabezpečení a šifrování připojení.

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
Standardní čtečka Logic Apps (Preview)	Máte přístup jen pro čtení ke všem prostředkům ve standardní logické aplikaci a pracovních postupech, včetně běhů pracovních postupů 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 – standardní vývojář (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 App Service nejsou podporovány.
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 jsou všechna data šifrována pomocí protokolu TLS (Transport Layer Security) jak během přenosu, tak i ve chvíli, kdy jsou uložená. 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:

Omezte přístup podle rozsahu IP adres.

Tato možnost vám pomůže zabezpečit přístup k historii spuštění na základě požadavků z konkrétního rozsahu IP adres.
Zabezpečení dat v historii spuštění pomocí obfuskace

V mnoha triggerech a akcích můžete zabezpečit vstupy, výstupy nebo obojí v historii spuštění logické aplikace.

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 pouze osoba s oprávněními správce, což umožňuje přístup k datům v pracovních postupech Logic App v režimu "just-in-time". 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 aplikaci logiky Consumption nebo Standard na webu Azure Portal nebo v šabloně Azure Resource Manageru:

Portál
Šablona Resource Manageru

Pracovní postupy spotřeby

V portálu Azure otevřete pracovní postup logické aplikace typu Consumption v návrháři.
V nabídce aplikace logiky v části Nastavení vyberte Nastavení pracovního postupu.
V části Konfigurace řízení přístupu v části Povolené příchozí IP adresy ze seznamu Možnosti přístupu triggeru vyberte Konkrétní IP rozsahy.
V poli Rozsahy IP adres pro obsah zadejte rozsahy IP adres, které mají přístup k obsahu ze vstupů a výstupů.

Standardní pracovní postupy

V Azure Portal otevřete svůj prostředek Standard pro logické aplikace.
V nabídce aplikace logiky v části Nastavení vyberte Sítě.
V části Konfigurace příchozího provozu vedle přístupu k veřejné síti vyberte Povoleno bez omezení přístupu.
Na stránce Omezení přístupu v části Přístup k aplikaci vyberte Možnost Povoleno z výběru virtuálních sítí a IP adres.
V části Přístup k webu a pravidla na kartě Hlavní web přidejte jedno nebo více pravidel k povolení nebo odepření žádostí 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).

Pracovní postupy spotřeby

V šabloně ARM zadejte rozsahy IP adres použitím sekcí accessControl a contents v definici prostředku vašeho logického aplikačního programu, například:

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

Standardní pracovní postupy

V šabloně ARM zadejte povolené rozsahy příchozích IP adres v definici prostředku vaší Logic App pomocí části Microsoft.Web/sites/config. V této části pod properties přidejte sekci ipSecurityRestrictions a pomocí sekcí ipAddress, action="Deny" | "Allow", tag=Default, priority a name="Ports" definujte pravidlo a nastavte ipAddress na povolený rozsah IP v x.x.x.x/x nebo x.x.x.x-x.x.x.x, například:

{
   "type": "Microsoft.Web/sites/config",
   "apiVersion": "2022-09-01",
   "name": "[concat(parameters('sites_My_Standard_Logic_App_name'), '/web')]",
   "location": "West US",
   "dependsOn": [
      "[resourceId('Microsoft.Web/sites', parameters('sites_My_Standard_Logic_App_name'))]"
   ],
   "tags": {
      "hidden-link: /app-insights-resource-id": "/subscriptions/{subscriptionID}/resourceGroups/Standard-RG/providers/Microsoft.Insights/components/My-Standard-Logic-App"
   },
   "properties": {
      "numberOfWorkers": 1,
      "defaultDocuments": [
         "Default.htm",
         "Default.html",
         "Default.asp",
         "index.htm",
         "index.html",
         "iisstart.htm",
         "default.aspx",
         "index.php"
      ],
      "netFrameworkVersion": "v6.0",
      "requestTracingEnabled": false,
      "remoteDebuggingEnabled": false,
      "httpLoggingEnabled": false,
      "acrUseManagedIdentityCreds": false,
      "logsDirectorySizeLimit": 35,
      "detailedErrorLoggingEnabled": false,
      "publishingUsername": "$My-Standard-Logic-App",
      "scmType": "None",
      "use32BitWorkerProcess": false,
      "webSocketsEnabled": false,
      "alwaysOn": false,
      "managedPipelineMode": "Integrated",
      "virtualApplications": [
         {
            "virtualPath": "/",
            "physicalPath": "site\\wwwroot",
            "preloadEnabled": false
         }
      ],
      "loadBalancing": "LeastRequests",
      "experiments": {
         "rampUpRules": []
      },
      "autoHealEnabled": false,
      "vnetRouteAllEnabled": false,
      "vnetPrivatePortsCount": 0,
      "publicNetworkAccess": "Enabled",
      "cors": {
         "supportCredentials": false
      },
      "localMySqlEnabled": false,
      "managedServiceIdentityId": 3065,
      "ipSecurityRestrictions": [
         {
            "ipAddress": "208.130.0.0/16",
            "action": "Deny",
            "tag": "Default",
            "priority": 100,
            "name": "Ports"
         },
         {
            "ipAddress": "Any",
            "action": "Deny",
            "priority": 2147483647,
            "name": "Deny all",
            "description": "Deny all access"
         }
      ],
      "ipSecurityRestrictionsDefaultAction": "Deny",
      "scmIpSecurityRestrictions": [
         {
            "ipAddress": "Any",
            "action": "Allow",
            "priority": 2147483647,
            "name": "Allow all",
            "description": "Allow all access"
         }
      ],
      "scmIpSecurityRestrictionsDefaultAction": "Allow",
      "scmIpSecurityRestrictionsUseMain": false,
      "http20Enabled": false,
      "minTlsVersion": "1.2",
      "scmMinTlsVersion": "1.2",
      "ftpsState": "FtpsOnly",
      "preWarmedInstanceCount": 1,
      "functionAppScaleLimit": 0,
      "functionsRuntimeScaleMonitoringEnabled": true,
      "minimumElasticInstanceCount": 1,
      "azureStorageAccounts": {}
   }
},

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é operace ale tyto možnosti nepodporují:

Zabezpečené vstupy – nepodporované	Zabezpečené výstupy – nepodporované
Připojení k proměnné pole Připojit k řetězcové proměnné Dekrementace proměnné Pro každý Když Proměnná přírůstku Inicializujte proměnnou Opakování Rozsah Nastavit proměnnou Vypínač Ukončit Do	Připojení k proměnné pole Připojit k řetězcové proměnné Napsat Dekrementace proměnné Pro každý Když Proměnná přírůstku Inicializujte proměnnou Parsování JSON Opakování Odpověď Rozsah Nastavit proměnnou Vypínač Ukončit Do Počkej

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. Také nemůžete přidat sledované vlastnosti k této aktivační události nebo akci pro monitorování.
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á.

Zabezpečené výstupy – nastavení

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.

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.

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.

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í Zabezpečené Vstupy pro tyto 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é vstupy a výstupy v návrháři

Na webu Azure portal otevřete pracovní postup logické aplikace v návrháři.
V návrháři vyberte trigger nebo akci, ve které chcete zabezpečit citlivá data.
V podokně informací, které se otevře, vyberte Nastavení a rozbalte položku Zabezpečení.
Zapněte buď zabezpečené vstupy, zabezpečené výstupy, nebo obojí.

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.
Po spuštění pracovního postupu můžete zobrazit historii tohoto spuštění.
1. V nabídce logické aplikace Consumption nebo v nabídce standardního pracovního postupu vyberte Přehled.
2. V části Historie spuštění vyberte běh, 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é.

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 inputy 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 oddíl parameters v definici pracovního postupu aplikace logiky a šablonu Resource Manager pro nasazení. 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:

Zabezpečené parametry v definicích pracovního postupu
Zabezpečení dat v historii spuštění pomocí obfuskace

Pokud automatizujete nasazování aplikací logiky pomocí šablon Resource Manageru, můžete pomocí typů a definovat zabezpečené parametry šablony, které se vyhodnocují při nasazení. 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:

Předání citlivých hodnot při nasazení pomocí služby Azure Key Vault
Zabezpečení parametrů v šablonách Azure Resource Manageru dále v tomto tématu

Zabezpečené parametry v definicích pracovních postupů (pracovní postup pro spotřebu)

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 pracovního postupu tento oddíl definuje parametry parameters a basicAuthPasswordParam pomocí typu basicAuthUsernameParam. Definice akce pak odkazuje na tyto parametry v oddílu authentication .

Důležité

Pro zajištění optimálního zabezpečení společnost Microsoft doporučuje používat ID Microsoft Entra se spravovanými identitami pro ověřování, pokud je to možné. Tato možnost poskytuje vynikající zabezpečení bez nutnosti zadávat přihlašovací údaje. Azure tuto identitu spravuje a pomáhá zabezpečit ověřovací informace, abyste tyto citlivé informace nemuseli spravovat. Pokud chcete nastavit spravovanou identitu pro Azure Logic Apps, přečtěte si téma Ověřování přístupu a připojení k prostředkům Azure pomocí spravovaných identit v Azure Logic Apps.

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

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

Šablona Resource Manageru pro prostředek logické aplikace 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.

Důležité

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

Na nejvyšší úrovni šablony definuje sekce parameters 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 vaší aplikace logiky, ale mimo definici pracovního postupu, je oddíl parameters který určuje 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 pracovního postupu je sekce parameters, která definuje parametry používané logickou aplikací při běhu. Tyto parametry pak můžete odkazovat ve svém pracovním postupu v aplikaci Logic App pomocí výrazů definice pracovního postupu, které se vyhodnocují během běhu programu.

Tato ukázková šablona má více zabezpečených definic parametrů, které používají typ securestring.

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

Typ autentizace	Aplikace logiky a podporované konektory
Základní	Azure API Management, Azure App Service, HTTP, HTTP + Swagger, HTTP Webhook
Klientský certifikát	Azure API Management, Azure App Service, HTTP, HTTP + Swagger, HTTP Webhook
Active Directory OAuth (OAuth 2.0 s Microsoft Entra ID)	- Consumption: Azure API Management, Azure App Service, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook - Standard: Azure Automation, Azure Blob Storage, Azure Event Hubs, Azure Queues, Azure Service Bus, Azure Tables, HTTP, HTTP, HTTP Webhook, SQL Server
Syrový	Azure API Management, Azure App Service, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
Spravovaná identita	Integrované konektory: - Consumption: Azure API Management, Azure App Service, Azure Functions, HTTP, HTTP Webhook - Standard: Azure Automation, Azure Blob Storage, Azure Event Hubs, Azure Queues, Azure Service Bus, Azure Tables, HTTP, HTTP, 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: Azure App Service, Azure Automation, Azure Blob Storage, Azure Container Instance, Azure Cosmos DB, Azure Data Explorer, Azure Data Factory, Azure Data Lake, Azure Event Grid, Azure Event Hubs, Azure IoT Central V2, Azure IoT Central V3, Azure Key Vault, Azure Log Analytics, Azure Queues, Azure Resource Manager, Azure Service Bus, Azure Sentinel, Azure Table Storage, Azure VM, HTTP s Microsoft Entra ID, SQL Server

Důležité

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 spouštěcího prvku založeného na požadavku, jako je spouštěč Požadavek nebo spouštěč HTTP Webhook, podporují šifrování a jsou zabezpečená minimálně protokolem Transport Layer Security (TLS) verze 1.2, dříve známý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.

Poznámka:

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

Důležité

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 zkontrolujete zprávy handshake protokolu TLS v Azure Logic Apps nebo pomocí nástroje zabezpečení na adrese URL vaší aplikace logiky, 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 způsoby, jak omezit přístup k triggerům, které přijímají příchozí volání pracovního postupu aplikace logiky, aby váš pracovní postup mohli volat jenom autorizovaní klienti:

Povolení OAuth pomocí Microsoft Entra ID
Generování klíčů nebo tokenů sdíleného přístupového podpisu (SAS)
Zakázání ověřování sdíleného přístupového podpisu (SAS)
Omezení příchozích IP adres
Zveřejnění aplikace logiky pomocí služby Azure API Management

Zapněte OAuth 2.0 pomocí Microsoft Entra ID

V pracovním postupu Consumption, který začíná triggerem založeným na požadavku, můžete ověřovat a autorizovat příchozí volání odesílaná do koncového bodu vytvořeného danou aktivační událostí povolením OAuth 2.0 s ID Microsoft Entra. Pokud chcete toto ověřování nastavit, definujte nebo přidejte zásady autorizace na úrovni prostředku 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í než počet určený zásadou autorizace.

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

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

Pro zajištění optimálního zabezpečení společnost Microsoft doporučuje používat ID Microsoft Entra se spravovanými identitami pro ověřování, pokud je to možné. Tato možnost poskytuje vynikající zabezpečení bez nutnosti zadávat přihlašovací údaje. Azure tuto identitu spravuje a pomáhá zabezpečit ověřovací informace, abyste tyto citlivé informace nemuseli spravovat. Pokud chcete nastavit spravovanou identitu pro Azure Logic Apps, přečtěte si téma Ověřování přístupu a připojení k prostředkům Azure pomocí spravovaných identit v Azure Logic Apps.
V pracovních postupech Consumption můžou příchozí volání adresy URL koncového bodu pro spouštěcí mechanismus na základě požadavku používat pouze jedno schéma autorizace, a to buď OAuth 2.0 s Microsoft Entra ID, nebo Sdílený přístupový podpis (SAS). I když použití jednoho schématu nezakazuje druhé schéma, pokud současně používáte obě schémata, Azure Logic Apps vygeneruje chybu, protože služba neví, které schéma se má zvolit. Pokud pracovní postup Consumption začíná spouštěčem Request, můžete zakázat ověřování SAS a také omezit autorizaci tak, aby používala pouze OAuth 2.0 s ID Microsoft Entra. U standardních pracovních postupů můžete použít jiné typy ověřování bez zakázání SAS.
Azure Logic Apps podporuje autorizační schémata typu nositele typu nebo typu důkazu o vlastnictví (pouze spotřební logická aplikace) 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 logické aplikace Consumption je omezen maximálním počtem zásad autorizace. Každá zásada autorizace má také maximální počet nároků. 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í buď https://sts.windows.net/ nebo https://login.microsoftonline.com/, jako vystavitele pro Microsoft Entra ID (OAuth V2).

Předpokládejme například, že prostředek logické aplikace má zásady autorizace, které pož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í, kde je aud a je iss:

{
    "aud": "https://management.core.windows.net/",
    "iss": "https://sts.windows.net/<Azure-AD-issuer-ID>/",
    "iat": 1582056988,
    "nbf": 1582056988,
    "exp": 1582060888,
    "_claim_names": {
       "groups": "src1"
    },
    "_claim_sources": {
       "src1": {
          "endpoint": "https://graph.windows.net/7200000-86f1-41af-91ab-2d7cd011db47/users/00000-f433-403e-b3aa-7d8406464625d7/getMemberObjects"
       }
    },
    "acr": "1",
    "aio": "AVQAq/8OAAAA7k1O1C2fRfeG604U9e6EzYcy52wb65Cx2OkaHIqDOkuyyr0IBa/YuaImaydaf/twVaeW/etbzzlKFNI4Q=",
    "amr": [
       "rsa",
       "mfa"
    ],
    "appid": "c44b4083-3bb0-00001-b47d-97400853cbdf3c",
    "appidacr": "2",
    "deviceid": "bfk817a1-3d981-4dddf82-8ade-2bddd2f5f8172ab",
    "family_name": "Sophia Owen",
    "given_name": "Sophia Owen (Fabrikam)",
    "ipaddr": "167.220.2.46",
    "name": "sophiaowen",
    "oid": "3d5053d9-f433-00000e-b3aa-7d84041625d7",
    "onprem_sid": "S-1-5-21-2497521184-1604012920-1887927527-21913475",
    "puid": "1003000000098FE48CE",
    "scp": "user_impersonation",
    "sub": "KGlhIodTx3XCVIWjJarRfJbsLX9JcdYYWDPkufGVij7_7k",
    "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
    "unique_name": "SophiaOwen@fabrikam.com",
    "upn": "SophiaOwen@fabrikam.com",
    "uti": "TPJ7nNNMMZkOSx6_uVczUAA",
    "ver": "1.0"
}

Povolit OAuth 2.0 s Microsoft Entra ID jako jedinou možností pro volání koncového bodu žádosti (jen pro Consumption)

U koncových bodů, které jsou založeny na požadavcích, můžete omezit autorizaci tak, aby používala pouze OAuth 2.0 s Microsoft Entra ID. Tato možnost funguje i v případě, že zakážete také ověřování sdíleného přístupového podpisu (SAS).

Pro pracovní postup Consumption nastavte spouštěč žádosti nebo spouštěč webhooku HTTP se schopností zkontrolovat přístupový token OAuth podle kroků k zahrnutí hlavičky 'Authorization' do výstupů spouštěče požadavku nebo HTTP webhooku.

Poznámka:

Tento krok zviditelní Authorization záhlaví v historii spuštění pracovního postupu a ve výstupech triggeru.
Na webu Azure Portal otevřete pracovní postup Consumption v návrháři.
V návrháři vyberte trigger. V podokně informací, které se otevře, vyberte Nastavení.
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 MSAL (Microsoft Authentication Library) poskytují tokeny PoP, které můžete použít. Pokud pracovní postup logické aplikace Consumption, 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 použít token PoP s logikou aplikace Consumption, postupujte podle kroků k nastavení OAuth pomocí Microsoft Entra ID.

Povolte OAuth s Microsoft Entra ID pro váš prostředek Consumption logic app

Pokud chcete do aplikace logiky Consumption přidat zásadu autorizace, postupujte podle pokynů pro šablonu Azure Portal nebo Azure Resource Manageru:

Portál
Šablona Resource Manageru

V Azure portálu otevřete aplikaci Consumption logic a pracovní postup v návrháři.
V nabídce aplikace logiky v části Nastavení vyberte Autorizace.
Na stránce Autorizace vyberte Přidat zásadu.

Zadejte informace o zásadách autorizace zadáním typů nároků a hodnot, které vaše aplikace logiky očekává v přístupovém tokenu předkládaného každým příchozím voláním spouštěče Požadavek:

Vlastnictví	Požaduje se	Typ	Popis
Název zásady	Ano	Řetězec	Název, který chcete použít pro zásady autorizace
Typ zásady	Ano	Řetězec	Buď AAD pro tokeny typu nosič nebo AADPOP pro tokeny typu Proof-of-Possession.
Žádosti	Ano	Řetězec	Dvojice klíč-hodnota, která určuje typ nároku a hodnotu, kterou požadavek pracovního toku očekává v přístupovém tokenu poskytovaném jednotlivými příchozími voláními na trigger. Výběrem možnosti Přidat standardní tvrzení můžete přidat libovolné standardní tvrzení. Pokud chcete přidat deklaraci identity specifickou pro token PoP, vyberte Přidat vlastní deklaraci identity. Dostupné standardní typy nároků: - Emitent - Obecenstvo - Předmět - Identifikátor webového tokenu JSON (JWT ID) Požadavky: - Seznam deklarací musí minimálně obsahovatdeklaraci vystavitele, která má hodnotu začínající `https://sts.windows.net/` nebo `https://login.microsoftonline.com/` jako ID vystavitele Microsoft Entra. – Každá deklarace musí být jedna řetězcová hodnota, nikoli pole hodnot. Můžete mít například deklaraci s rolí jako typem a vývojářem jako hodnotou. Nemůžete mít tvrzení, které má Role jako typ a hodnoty nastavené na Developer a Program Manager. – Hodnota nároku je omezena na maximální počet znaků. Další informace o těchto typech nároků najdete v tématu Nároky v bezpečnostních tokenech Microsoft Entra. Můžete také zadat vlastní typ a hodnotu nároku.

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

Pokud chcete přidat další položku, 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 naleznete v jak poskytnout volitelné nároky pro vaši aplikaci. Vaše vlastní deklarace se pak uloží jako součást vašeho ID JWT; například "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee".
Pokud chcete přidat další zásady autorizace, vyberte Přidat zásadu. Opakujte předchozí kroky a nastavte zásadu.
Až budete hotovi, zvolte tlačítko Uložit.
Pokud chcete do výstupů triggeru založeného na požadavku zahrnout hlavičku Authorization z přístupového tokenu, přečtěte si Include 'Authorization' header in request and HTTP webhook trigger outputs.

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.

V šabloně ARM definujte zásady autorizace pomocí následujících kroků a syntaxe:

V části definice prostředku vaší aplikace logiky přidejte objekt properties, pokud dosud žádný neexistuje, který obsahuje objekt .

Další informace o objektu accessControl najdete v tématu Omezení rozsahů příchozích IP adres v šabloně Azure Resource Manageru a šablony pracovních postupů Microsoft.Logic.
Do objektu triggersopenAuthenticationPoliciespolicies přidejte objekt obsahující objekt, ve kterém definujete jednu nebo více zásad autorizace.
Zadejte název zásad autorizace, nastavte typ zásady na AAD, a zahrňte claims pole, kde specifikujete jeden nebo více typů nároků.

claims pole musí minimálně obsahovat typ deklarace identity Vystavitel, kde nastavíte vlastnost deklarace na name a určíte, že iss má začínat hodnotou value nebo https://sts.windows.net/ jako ID vydavatele Microsoft Entra. Další informace o těchto typech požadavků naleznete v části Požadavky v bezpečnostních tokenech Microsoft Entra. Můžete také zadat vlastní typ a hodnotu nároku.
Pokud chcete do výstupů triggeru požadavku zahrnout hlavičku Authorization z přístupového tokenu, přečtěte si téma Zahrnutí hlavičky Autorizace do výstupů triggeru.

Tady je syntaxe, kterou je třeba dodržovat:

"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
],

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:

Vygenerování klíče nebo tokenu sdíleného přístupového podpisu (SAS)

Když pracovní postup začíná triggerem založeným na požadavku a tento pracovní postup uložíte poprvé, Azure Logic Apps vytvoří na daném triggeru volatelný koncový bod. Tento koncový bod má adresu URL, která může přijímat příchozí volání nebo požadavky na spuštění pracovního postupu. Adresa URL obsahuje sdílený přístupový podpis (SAS), což je klíč nebo token, který uděluje oprávnění, například službám úložiště. Adresa URL tohoto koncového bodu používá následující formát:

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

Například pokud chcete zobrazit tuto adresu URL v triggeru Request, vyhledejte vlastnost HTTP URL triggeru:

Snímek obrazovky s webem Azure Portal, návrhářem pracovního postupu Consumption a adresou URL koncového bodu triggeru požadavku

Úplná adresa URL vypadá jako v následujícím příkladu:

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

Sas v adrese URL obsahuje parametry dotazu, které popisuje následující tabulka:

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 je generován pomocí algoritmu SHA256 s tajným přístupovým klíčem na všech cestách a vlastnostech URL. Tento klíč se uchovává v tajnosti a šifruje, ukládá se 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.

Důležité

Ujistěte se, že klíč SAS chráníte stejně jako klíč účtu před neoprávněným použitím. Nastavte nebo vytvořte plán pro odvolání ohroženého přístupového klíče. Při distribuci identifikátorů URI, které využívají přístupové klíče, buďte obezřetní a provádějte ji pouze přes zabezpečené připojení, jako je HTTPS. Ujistěte se, že provádíte pouze operace, které používají přístupový klíč přes připojení HTTPS. Každý, kdo má identifikátor URI s platným klíčem, má přístup k přidruženému prostředku. Pokud chcete zachovat zabezpečení a chránit přístup k pracovnímu postupu aplikace logiky, znovu vygenerujte přístupové klíče podle běžného plánu, protože můžou potřebovat dodržovat zásady zabezpečení nebo se stát ohroženými. Tímto způsobem se můžete ujistit, že váš pracovní postup můžou aktivovat jenom autorizované žádosti, které chrání vaše data a procesy před neoprávněným přístupem.

Pokud pro přístup ke službám úložiště používáte klíč SAS, Microsoft doporučuje, abyste vytvořili delegovaný klíč SAS uživatele, který je zabezpečen pomocí Microsoft Entra ID, a ne pomocí klíče účtu.

Pro zajištění optimálního zabezpečení společnost Microsoft doporučuje používat ID Microsoft Entra se spravovanými identitami pro ověřování, kdykoli je to možné. Tato možnost poskytuje vynikající zabezpečení bez nutnosti zadávat přihlašovací údaje. Azure tuto identitu spravuje a pomáhá zabezpečit ověřovací informace, abyste tyto citlivé informace nemuseli spravovat. Pokud chcete nastavit spravovanou identitu pro Azure Logic Apps, přečtěte si téma Ověřování přístupu a připojení k prostředkům Azure pomocí spravovaných identit v Azure Logic Apps.

Příchozí volání do koncového bodu v triggeru založeném na požadavku můžou používat pouze jedno schéma autorizace( SAS nebo OAuth 2.0 s ID Microsoft Entra). I když použití jednoho schématu druhou nezakáže, pokud současně používáte obě schémata, Azure Logic Apps vygeneruje chybu, protože služba neví, které schéma se má zvolit.

Pokud máte pracovní postup Consumption, který začíná triggerem Request, můžete zakázat ověřování SAS. Tato možnost funguje i v případě, že autorizaci omezíte tak, aby používala jenom OAuth 2.0 s ID Microsoft Entra. U standardních pracovních postupů můžete použít jiné typy ověřování bez zakázání SAS.

Další informace o zabezpečení při použití klíče SAS najdete v následujících částech tohoto průvodce:

Opětovné generování přístupových klíčů
Vytvoření adres URL zpětného volání s vypršenou platností
Vytvoření adres URL s primárním nebo sekundárním klíčem

Zakázat ověřování prostřednictvím sdíleného přístupového podpisu (SAS) (pouze spotřeba)

Ve výchozím nastavení má požadavkový trigger povolené ověřování SAS. Adresa URL koncového bodu triggeru zahrnuje SAS, počínaje parametry dotazu, sp-<permissions>sv-<SAS-version>sig=<signature>například:

Pokud pracovní postup Consumption začíná triggerem požadavku a chcete použít OAuth s ID Microsoft Entra, můžete zakázat ověřování SAS, abyste se vyhnuli chybám a problémům se spuštěním pracovního postupu. Také přidáváte vrstvu zabezpečení tím, že odstraníte závislost na tajných údajích, což snižuje riziko, že se tajné údaje zaznamenají nebo uniknou.

Tato možnost funguje i v případě, že povolíte OAuth 2.0 s ID Microsoft Entra jako jedinou možnost volání koncového bodu založeného na požadavku. U standardních pracovních postupů můžete použít jiné typy ověřování bez zakázání SAS.

Poznámka:

Tato akce zakáže ověřování SAS pro příchozí požadavky a blokuje fungování existujících klíčů SAS nebo podpisů SAS. Klíče nebo podpisy SAS ale zůstávají platné a stále fungují, pokud znovu povolíte ověřování SAS. Pokud chcete zakázat klíče SAS a podpisy vytvořením nových verzí, přečtěte si téma Opětovné generování přístupových klíčů.

Po zakázání ověřování SAS už adresa URL koncového bodu triggeru požadavku neobsahuje klíč SAS, například:

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

Požadavky

Pro tuto úlohu potřebujete nástroj pro odesílání volání rozhraní REST API, například:

Visual Studio Code s rozšířením z Webu Visual Studio Marketplace
PowerShell Invoke-RestMethod
Microsoft Edge – nástroj konzoly sítě
Bruno
kudrna

Upozornění

V situacích, kdy máte citlivá data, jako jsou přihlašovací údaje, tajné kódy, přístupové tokeny, klíče rozhraní API a další podobné informace, nezapomeňte použít nástroj, který chrání vaše data pomocí nezbytných funkcí zabezpečení. Nástroj by měl fungovat offline nebo místně a nevyžaduje přihlášení k online účtu nebo synchronizaci dat do cloudu. Při použití nástroje s těmito charakteristikami snížíte riziko zveřejnění citlivých dat veřejnosti.

Zkontrolujte triggery s povoleným nebo zakázaným SAS

Pokud je ověřování SAS zakázané, adresa URL koncového bodu triggeru už neobsahuje klíč SAS. Definice pracovního postupu Consumption zahrnuje také objekt JSON sasAuthenticationPolicy. Tento objekt má vlastnost stavu , která je nastavena na Zakázáno, například:

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

Pokud chcete najít pracovní postupy Consumption, kde je sas povolený nebo zakázaný, zkontrolujte, jestli definice pracovního postupu zahrnuje objekt sasAuthenticationPolicy , ve kterém je vlastnost stavu nastavena na Zakázáno.

Pomocí nástroje, který odesílá volání rozhraní REST API, získejte informace o vašem pracovním postupu spuštěním pracovních postupů – získání operace pomocí následujícího požadavku GET , například:

GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Převezměte výstup z Workflows – Get operace a zkontrolujte, jestli existuje objekt sasAuthenticationPolicy , kde je vlastnost stavu nastavena na Disabled.

Přidání vlastnosti sasAuthenticationPolicy do definice pracovního postupu

V případě pracovních postupů Consumption, ve kterých chcete zakázat ověřování SAS, postupujte takto:

Pokud jste tak ještě neučinili, získejte informace o svém pracovním postupu spuštěním operace Workflows - Get pomocí následujícího požadavku GET, například:

GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Převezměte výstup z pracovních postupů – Operace Get a ručně přidejte následující prvky:
1. V objektu properties přidejte accessControl objekt, který obsahuje triggers objekt, pokud neexistuje.
2. V objektu triggerssasAuthenticationPolicy přidejte objekt, který obsahuje vlastnost nastavenou state na Disabled.
Po dokončení bude upravená část vypadat jako v následujícím příkladu:
```
"properties": {
    "accessControl": {
        "triggers": {
            "sasAuthenticationPolicy": {
                "state": "Disabled"
            }
        }
    }
}
```
Odešlete další požadavek na aktualizaci pracovního postupu upraveným výstupem, který použijete jako vstup v textu požadavku spuštěním operace Workflows – Update pomocí následujícího požadavku PUT, například:

PUT https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Na webu Azure Portal přejděte do pracovního postupu Consumption v návrháři a ověřte, že adresa URL triggeru požadavku už sas neobsahuje.
Chcete-li povolit OAuth 2.0 s Microsoft Entra ID, přidejte na úrovni prostředku Logic App zásady autorizace pro OAuth s Microsoft Entra ID.

Další informace naleznete v tématu Povolení OAuth 2.0 s Microsoft Entra ID.

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

Pokud chcete zachovat zabezpečení a chránit přístup k pracovnímu postupu aplikace logiky, znovu vygenerujte přístupové klíče podle běžného plánu, protože můžou potřebovat dodržovat zásady zabezpečení nebo se stát ohroženými. Tímto způsobem se můžete ujistit, že váš pracovní postup můžou aktivovat jenom autorizované žádosti, které chrání vaše data a procesy před neoprávněným přístupem.

Pokud chcete kdykoli vygenerovat nový přístupový klíč, použijte rozhraní Azure REST API nebo Azure Portal. Všechny dříve vygenerované identifikátory URI nebo adresy URL, které používají starý klíč, se zneplatní a už nemají autorizaci k aktivaci pracovního postupu aplikace logiky. Identifikátory URI, které načtete po regeneraci, jsou podepsané novým přístupovým klíčem.

Na webu Azure Portal otevřete prostředek aplikace logiky, který používá klíč, který chcete znovu vygenerovat.
V nabídce prostředků aplikace logiky v části Nastavení vyberte Přístupové klíče.
Vyberte klíč, který chcete znovu vygenerovat, a dokončete proces.

Důležité

Nezapomeňte chránit přístupový klíč stejně, jako chráníte klíč účtu před neoprávněným použitím. Nastavte nebo vytvořte plán pro odvolání ohroženého přístupového klíče. Při distribuci identifikátorů URI, které využívají přístupové klíče, buďte obezřetní a provádějte ji pouze přes zabezpečené připojení, jako je HTTPS. Ujistěte se, že provádíte pouze operace, které používají přístupový klíč přes připojení HTTPS. Každý, kdo má identifikátor URI s platným klíčem, má přístup k přidruženému prostředku.

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/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01

Do textu zahrňte NotAfter vlastnost 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 služby Azure Logic Apps, například:

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

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

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

Pro více možností a protokolů ověřování zvažte vystavení pracovního postupu aplikace Logic 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 konkrétně omezit klienty, kteří mohou volat pracovní postup logiky aplikace. 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 jakékoliv zadané IP adresy můžete stále spustit pracovní postup aplikační logiky, který má aktivační událost založenou na požadavku, a to buď pomocí operace Workflow Triggers - Run, nebo pomocí správy API (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.

Portál
Šablona Resource Manageru

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 pracovní postup – Vytvoření nebo aktualizace operace v rozhraní REST API služby Azure Logic Apps.

Pracovní postupy spotřeby

Na webu Azure Portal otevřete aplikaci logiky Consumption v návrháři pracovního postupu.
V nabídce aplikace logiky v části Nastavení vyberte Nastavení pracovního postupu.
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.
- Aby bylo možné pracovní postup volat pomocí akce HTTP, ale pouze jako vnořený pracovní postup, vyberte Konkrétní rozsahy IP adres. Jakmile se zobrazí pole rozsahy IP adres pro triggery, zadejte IP adresy pro odchozí spojení 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 rozsahy IP adres, které trigger přijme, když se zobrazí pole rozsahy IP adres pro triggery. Platný rozsah IP adres používá tyto formáty: x.x.x.x/x nebo x.x.x-x.x.x.x.x.
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

V Azure Portal otevřete svůj prostředek Standard pro logické aplikace.
V nabídce aplikace logiky v části Nastavení vyberte Sítě.
V části Konfigurace příchozího provozu vedle přístupu k veřejné síti vyberte Povoleno bez omezení přístupu.
Na stránce Omezení přístupu v části Přístup k aplikaci vyberte Možnost Povoleno z výběru virtuálních sítí a IP adres.
V části Přístup k webu a pravidla na kartě Hlavní web přidejte jedno nebo více pravidel k povolení nebo odepření žádostí z konkrétních rozsahů IP adres. 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).

Pracovní postupy spotřeby

V šabloně ARM zadejte povolené rozsahy příchozích IP adres v definici prostředku vaší Logic App pomocí části accessControl. V této části použijte triggers, actions a volitelné contents podle potřeby tím, že zahrnete oddíl allowedCallerIpAddresses s vlastností addressRange a nastavte hodnotu vlastnosti na povolený rozsah IP v x.x.x.x/x nebo x.x.x.x-x.x.x.x.

Pokud pracovní postup vnořené aplikace logiky používá pouze jinou možnost Logic Apps, která povoluje příchozí volání pouze z jiných pracovních postupů aplikace logiky, které používají integrovanou akci Azure Logic Apps, nastavte allowedCallerIpAddresses vlastnost na prázdné pole ([]) a tuto vlastnost vynecháteaddressRange.
Pokud váš pracovní postup vnořené aplikace logiky používá možnost Konkrétní rozsahy IP adres pro jiná příchozí volání, jako jsou jiné pracovní postupy aplikace logiky, které používají akci HTTP, zahrňte allowedCallerIpAddresses oddíl a nastavte addressRange vlastnost na povolený rozsah IP adres.

Tento příklad ukazuje definici prostředku aplikace logiky pro vnořený pracovní postup, který povoluje příchozí volání pouze z jiných pracovních postupů aplikace logiky, které používají integrovanou akci Azure Logic Apps:

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

Tento příklad ukazuje definici prostředku aplikace logiky pro vnořený pracovní postup, který umožňuje příchozí volání z pracovních postupů aplikace logiky, které používají akci HTTP:

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

Standardní pracovní postupy

{
   "type": "Microsoft.Web/sites/config",
   "apiVersion": "2022-09-01",
   "name": "[concat(parameters('sites_My_Standard_Logic_App_name'), '/web')]",
   "location": "West US",
   "dependsOn": [
      "[resourceId('Microsoft.Web/sites', parameters('sites_My_Standard_Logic_App_name'))]"
   ],
   "tags": {
      "hidden-link: /app-insights-resource-id": "/subscriptions/{subscriptionID}/resourceGroups/Standard-RG/providers/Microsoft.Insights/components/My-Standard-Logic-App"
   },
   "properties": {
      "numberOfWorkers": 1,
      "defaultDocuments": [
         "Default.htm",
         "Default.html",
         "Default.asp",
         "index.htm",
         "index.html",
         "iisstart.htm",
         "default.aspx",
         "index.php"
      ],
      "netFrameworkVersion": "v6.0",
      "requestTracingEnabled": false,
      "remoteDebuggingEnabled": false,
      "httpLoggingEnabled": false,
      "acrUseManagedIdentityCreds": false,
      "logsDirectorySizeLimit": 35,
      "detailedErrorLoggingEnabled": false,
      "publishingUsername": "$My-Standard-Logic-App",
      "scmType": "None",
      "use32BitWorkerProcess": false,
      "webSocketsEnabled": false,
      "alwaysOn": false,
      "managedPipelineMode": "Integrated",
      "virtualApplications": [
         {
            "virtualPath": "/",
            "physicalPath": "site\\wwwroot",
            "preloadEnabled": false
         }
      ],
      "loadBalancing": "LeastRequests",
      "experiments": {
         "rampUpRules": []
      },
      "autoHealEnabled": false,
      "vnetRouteAllEnabled": false,
      "vnetPrivatePortsCount": 0,
      "publicNetworkAccess": "Enabled",
      "cors": {
         "supportCredentials": false
      },
      "localMySqlEnabled": false,
      "managedServiceIdentityId": 3065,
      "ipSecurityRestrictions": [
         {
            "ipAddress": "208.130.0.0/16",
            "action": "Deny",
            "tag": "Default",
            "priority": 100,
            "name": "Ports"
         },
         {
            "ipAddress": "Any",
            "action": "Deny",
            "priority": 2147483647,
            "name": "Deny all",
            "description": "Deny all access"
         }
      ],
      "ipSecurityRestrictionsDefaultAction": "Deny",
      "scmIpSecurityRestrictions": [
         {
            "ipAddress": "Any",
            "action": "Allow",
            "priority": 2147483647,
            "name": "Allow all",
            "description": "Allow all access"
         }
      ],
      "scmIpSecurityRestrictionsDefaultAction": "Allow",
      "scmIpSecurityRestrictionsUseMain": false,
      "http20Enabled": false,
      "minTlsVersion": "1.2",
      "scmMinTlsVersion": "1.2",
      "ftpsState": "FtpsOnly",
      "preWarmedInstanceCount": 1,
      "functionAppScaleLimit": 0,
      "functionsRuntimeScaleMonitoringEnabled": true,
      "minimumElasticInstanceCount": 1,
      "azureStorageAccounts": {}
   }
},

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 samopodepsaných certifikátech 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 logická aplikace volá HTTP server a použije samopodepsaný certifikát TLS/SSL, volání HTTP selže s chybou TrustFailure.
Pro pracovní postupy ve standardním prostředí logických aplikací Azure Logic Apps s jedním tenantem podporují operace HTTP certifikáty TLS/SSL, které jsou 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 logických aplikací.

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í jako zabezpečený odchozí provoz z bránového agenta. 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 pro spotřebu
  1. Podle toho, jestli přidáváte trigger nebo akci služby API Management, postupujte takto:
    - Spoušť:
      1. V návrháři pracovního postupu vyberte Přidat trigger.
      2. Po otevření podokna Přidat trigger zadejte do vyhledávání API Management.
      3. V seznamu výsledků triggeru vyberte Vyberte trigger 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:
  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 Zavolejte API 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ý.

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 podporující 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 rozšířených parametrů a vyberte Ověřování.

Důležité

Pokud chcete chránit citlivé informace, které pracovní postup 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í

Pro volání HTTP používá základní ověřování řetězec kódování base64, který obsahuje uživatelské jméno a heslo k vytvoření požadavku. Tato metoda přenáší přihlašovací údaje bez šifrování a představuje zvýšená bezpečnostní rizika, pokud tuto možnost nepoužíváte s protokolem HTTPS/SSL.

Důležité

Pokud je k dispozici a vybrána možnost Základní , 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ých certifikátů

Ověřování klientských certifikátů umožňuje nebo vyžaduje, aby se uživatelé ověřili přímo pomocí certifikátů X.509 v jejich ID Microsoft Entra pro aplikace a přihlašování v prohlížeči. Tato funkce vám pomůže přijmout ověřování odolné proti útokům phishing a ověřit se pomocí certifikátu X.509 pro infrastrukturu veřejných klíčů (PKI).

Důležité

Pokud je možnost Klientský certifikát k dispozici a vybrána, 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	< zakódovaný-obsah-souboru-pfx>	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`	Ne	< heslo pro soubor pfx>	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:

Odinstalujte všechny instance OpenSSL.
Nainstalujte OpenSSL verze 1.1.1t.
Při nové aktualizaci odvolejte svůj certifikát.
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:

Platforma Microsoft Entra

Na triggeru požadavku můžete pomocí platformy Microsoft Entra ověřovat příchozí volání po nastavení zásad autorizace Microsoft Entra pro vaši aplikaci logiky.

Důležité

U všech ostatních triggerů a akcí, které podporují ověřování Active Directory OAuth (OAuth 2.0 s ID Microsoft Entra), zadejte tyto hodnoty vlastností:

Vlastnost (návrhář)	Vlastnost (JSON)	Požaduje se	Hodnota	Popis
Ověřování	`type`	Ano	Active Directory OAuth (OAuth 2.0 s Microsoft Entra ID) nebo `ActiveDirectoryOAuth`	Typ ověřování, který se má použít. Azure Logic Apps se v současné době řídí protokolem OAuth 2.0.
Autorita	`authority`	Ne	< Url-for-authority-token-issuer>	Adresa URL autority, která poskytuje přístupový klíč, například `https://login.microsoftonline.com/` pro oblasti globální služby Azure. V případě jiných národních cloudů si projděte koncové body ověřování Microsoft Entra – Výběr autority identity.
Nájemce	`tenant`	Ano	< ID klienta>	ID tenanta pro nájemce Microsoft Entra
Obecenstvo	`audience`	Ano	< prostředek k autorizaci>	Prostředek, který chcete použít k autorizaci, například `https://management.core.windows.net/`
ID klienta	`clientId`	Ano	< ID klienta>	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"	< zakódovaný-obsah-souboru-pfx>	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"	< heslo pro soubor pfx>	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 standardní prostředek Logic Apps v jedné instanci Azure Logic Apps a chcete použít operaci HTTP s certifikátem TLS/SSL, klientským certifikátem nebo OAuth Microsoft Entra ID s typem Certificate přihlašovacích údajů, nezapomeňte provést 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.

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

Důležité

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	< Hodnota hlavičky autorizace>	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 logické aplikace Consumption může používat systémem přiřazenou identitu nebo jednu uživatelsky přiřazenou identitu, která byla vytvořena ručně.
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ího řetězce, 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.

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.
Než Azure funkce může používat spravovanou identitu, nejprve povolte ověřování pro Azure funkce.

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`	Ne	< ID identity přiřazené uživatelem>	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.
Obecenstvo	`audience`	Ano	< ID cílového prostředku>	ID zdroje cílového zdroje, 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 rozšířených 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. Nicméně, ID prostředku pro konkrétní účet úložiště nevyžaduje koncové lomítko. Pokud chcete najít tyto identifikátory prostředků, projděte si služby Azure, které podporují Microsoft Entra ID.

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 < uživatelsky-přiřazený-spravovaný-identitní-název>	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.

Pokyny k izolaci logických aplikací

Azure Logic Apps v Azure Government můžete použít k podpoře všech úrovní dopadu v oblastech popsaných pokyny pro izolaci úrovně 5 v Azure Government. 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.
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ů.
Pokud chcete spustit vlastní kód nebo provést transformaci XML, vytvořte a spusťte funkci Azure místo použití schopnosti vloženého kódu nebo poskytnutí sestavení, která mají sloužit jako mapy. Nastavte také hostitelské prostředí pro vaši aplikaci funkcí tak, aby vyhovovalo vašim požadavkům na izolaci.

Chcete-li například splnit požadavky na úroveň dopadu 5, vytvořte svou aplikační funkci s plánem App Service pomocí izolované cenové úrovně a také s App Service Environment (ASE), který rovněž používá izolovanou cenovou úroveň. V tomto prostředí běží funkční aplikace 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 výpočetní izolaci pro vaše aplikace a maximální možnosti škálování.

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

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

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-06-22

Sdílet prostřednictvím

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

Přístup k operacím aplikace logiky

Pracovní postupy spotřeby

Standardní pracovní postupy

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

Omezení přístupu podle rozsahu IP adres

Pracovní postupy spotřeby

Standardní pracovní postupy

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

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

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

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

Přístup ke vstupům parametrů

Zabezpečené parametry v definicích pracovních postupů (pracovní postup pro spotřebu)

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

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

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

Zapněte OAuth 2.0 pomocí Microsoft Entra ID

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

Povolit OAuth 2.0 s Microsoft Entra ID jako jedinou možností pro volání koncového bodu žádosti (jen pro Consumption)

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

Povolte OAuth s Microsoft Entra ID pro váš prostředek Consumption logic app

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

Vygenerování klíče nebo tokenu sdíleného přístupového podpisu (SAS)

Zakázat ověřování prostřednictvím sdíleného přístupového podpisu (SAS) (pouze spotřeba)

Požadavky

Zkontrolujte triggery s povoleným nebo zakázaným SAS

Přidání vlastnosti sasAuthenticationPolicy do definice pracovního postupu

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

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

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

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

Omezení příchozích IP adres

Pracovní postupy spotřeby

Standardní pracovní postupy

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

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

Základní ověřování

Ověřování klientských certifikátů

Platforma Microsoft Entra

Surové ověřování

Ověřování spravovaných identit

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

Pokyny k izolaci logických aplikací

Související obsah

Váš názor

Další materiály