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

Azure Logic Apps ukládá a automaticky šifruje data v klidu pomocí Azure Storage. Toto šifrování chrání vaše data pomocí klíčů spravovaných Microsoft a pomáhá vám splnit bezpečnostní a compliance závazky organizace. Další informace najdete v tématu Šifrování služby Azure Storage pro neaktivní uložená data.

Tento průvodce ukazuje, jak můžete dále zabezpečit a chránit citlivá data v následujících hlavních oblastech Azure Logic Apps:

Task Přejít na
Kontrolovat, kdo může spravovat nebo upravovat pracovní postupy Bezpečné operace logických aplikací
Skrýt vstupy, výstupy, hesla a tajné údaje v historii spuštění Zabezpečená data historie spuštění
Chraňte hodnoty parametrů v různých prostředích Bezpečné vstupy parametrů
Pochopte typy autentizace Zkontrolujte typy autentizace pro workflow operace
Autentizujte hovory, které zahajují váš pracovní postup Bezpečné příchozí hovory
Ověřujte volání, která odesílá váš pracovní postup Bezpečné odchozí hovory
Konektory specifické pro daný blok Blokovat připojení
Splnění požadavků na izolaci Pokyny k izolaci
Zkontrolujte základní bezpečnostní úroveň Standardní hodnoty zabezpečení Azure pro Azure Logic Apps

Pro informace o bezpečnosti v rámci celého Azure viz:

Zabezpečení přístupu k operacím aplikace logiky pomocí Azure RBAC

V Azure řídí řízení přístupu založené na rolích (RBAC), kdo má přístup a oprávnění pracovat se zdroji. Než ostatní mohou vytvářet nebo spravovat logické aplikace, workflowy a připojení, musíte jim přiřadit roli, která poskytuje potřebná oprávnění. Můžete nastavit oprávnění tak, aby konkrétní úkoly mohli provádět pouze konkrétní uživatelé nebo skupiny, například správu, úpravu a prohlížení logických aplikací. Pro kontrolu jejich oprávnění přiřaďte vestavěné nebo přizpůsobené role členům, kteří mají přístup k vašemu předplatnému Azure.

Important

Pro snížení útočné plochy vždy přiřazujte role podle principu nejmenších privilegií.

Než přidělíte roli, projděte si následující osvědčené postupy, úvahy a dopady:

  • Umožnit uživatelům, aplikacím a spravovaným identitám přístup pouze k datům a operacím, které potřebují k výkonu své práce.

  • Přiřaďte role přispěvatelů nebo oprávnění k úpravě workflow na základě nejmenších oprávnění pouze důvěryhodným principalům .

  • Přiřaďte pouze minimální nezbytná oprávnění pro spravované identity v pracovních postupech logických aplikací, aby mohly vykonávat svou práci.

  • Oprávnění pro úpravy přispěvatelů nebo workflow znamenají držení oprávnění pro každou spravovanou identitu přiřazenou danému workflow.

  • Kdokoli s oprávněním pro přispěvatele nebo úpravy workflow může nastavit vestavěné HTTP operace, které využívají spravované identity k požadavku na tokeny nositele identity pro libovolné publikum. Mohou s těmito tokeny posílat požadavky na jakýkoli koncový bod nebo cíl. Platforma neomezuje cílovou stanici. Tokeny bearer jsou platné po dobu jedné hodiny a mohou přistupovat k libovolnému rozhraní API Azure, ke kterému mají jejich identity přístup.

Azure Logic Apps má následující specifické role, podle toho, zda máte workflow Consumption nebo Standard:

Pracovní postupy spotřeby
Role Description
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 potřebujete pracovat s pracovním postupem aplikace logiky, který jste nevytvořili, a ověřit připojení používaná tímto pracovním postupem aplikace logiky. Vaše předplatné Azure vyžaduje oprávnění přispěvatele pro skupinu prostředků, která obsahuje daný prostředek aplikace logiky. Pokud vytvoříte zdroj v logic app, automaticky získáte přístup k přispěvatelům .

Aby ostatní neměnili nebo nemazali váš workflow logických aplikací, použijte Azure Resource Lock. 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
Role Description
Čtenář Logic Apps Standard 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.
Logic Apps Standard Operator Máte přístup k povolení, opětovnému odeslání a zakázání pracovních postupů a k vytváření připojení ke službám, systémům a sítím pro standardní aplikaci logiky. Role Operátor může provádět úlohy správy a podpory na platformě Azure Logic Apps, ale nemá oprávnění k úpravám pracovních postupů nebo nastavení.
Logic Apps Standard Developer 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.
Přispěvatel Logic Apps Standard 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 historii běhů workflow

Během běhu workflow jsou všechna data během přenosu šifrována pomocí Transport Layer Security (TLS) a v klidu. 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í.

Pro kontrolu přístupu ke vstupům a výstupům v historii běhů workflow použijte následující možnosti:

Omezení přístupu podle rozsahu IP adres

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

Pokud chcete například blokovat přístup ke vstupům a výstupům, zadejte rozsah IP adres, například 0.0.0.0-0.0.0.0. Toto omezení může odebrat 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ý IP rozsah 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:

Pracovní postupy spotřeby

  1. V portálu Azure otevřete pracovní postup logické aplikace typu Consumption v návrháři.

  2. V postranním panelu Logické aplikace v Nastavení vyberte Nastavení pracovního postupu.

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

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

  1. V Azure Portal otevřete prostředek Standardní aplikace logiky.

  2. Na postranním panelu Logické aplikace v Nastavení vyberte Síťové připojení.

  3. V části Konfigurace příchozího provozu vedle přístupu k veřejné síti vyberte Povoleno bez omezení přístupu.

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

  5. 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ý IP rozsah 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).

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
Až 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
Wait

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

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

  • Když zakryjete vstupy nebo výstupy triggeru nebo akce, Azure Logic Apps neodesílá zabezpečená data do Azure Log Analytics. 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.

    Diagram ukazuje, jak zabezpečené výstupy ovlivňují viditelnost jako skryté vstupy pro následné akce v historii běhu workflow.

    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, Parsovat JSON nebo Response jako vstupy, Azure Logic Apps neskryje vstupy nebo výstupy podřízené akce.

    Diagram ukazuje, jak zabezpečené výstupy ovlivňují viditelnost jako vstupy pro akce Compos, Parse JSON a Response.

    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.

    Diagram ukazuje, jak zabezpečené spouštěcí nebo akční vstupy ovlivňují viditelnost jako vstupy pro následné pracovní akce.

    Pokud akce Compose, Parse JSON a Response explicitně používají viditelné výstupy ze spouštěče nebo akce, která obsahuje zabezpečené vstupy, Azure Logic Apps skryje vstupy a výstupy těchto akcí, ale nepovolí nastavení Secure Inputs těchto akcí. Pokud podřízená akce explicitně používá skryté výstupy z akcí Compose, Parsovat JSON nebo Response jako vstupy, Azure Logic Apps neskryje vstupy nebo výstupy podřízené akce.

    Diagram ukazuje, jak zabezpečené vstupy ovlivňují pracovní postupy Compose, Parse JSON a Response.

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

  1. Na webu Azure portal otevřete pracovní postup logické aplikace v návrháři.

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

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

    Screenshot, který ukazuje Azure portál, workflow designer a trigger nebo akci s otevřenými nastaveními.

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

    Screenshot, který ukazuje pracovní postup s aktivovanými nastaveními Secure Inputs nebo Secure Outputs dané akce.

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

    Screenshot, který ukazuje pracovní postup s otevřeným dynamickým seznamem obsahu následující akce a tokenem předchozí akce pro zabezpečený výstup s ikonou zámku.

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

    1. Na bočním panelu aplikace logiky 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é.

      Screenshot, který ukazuje standardní zobrazení běhů workflow s ukrytými vstupy a výstupy.

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

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

  • "inputs": Zabezpečuje 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>
}

Bezpečný přístup k vstupům parametrů napříč prostředími

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. Použitím šablony Azure Resource Manager pro nasazení vaší logické aplikace se můžete vyhnout pevně zakódovaným datům, chránit citlivá data definováním zabezpečených parametrů a tato data předávat jako samostatné vstupy přes parametry šablony pomocí parametrového souboru.

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.

Note

Pokud použijete parametr v hlavičce nebo těle požadavku, může být tento parametr viditelný při prohlížení historie běhů vašeho workflow a odchozího HTTP požadavku. 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ů. Pokud tam použijete tajemství, nemůžete ho získat zpět.

Pro více informací viz následující části tohoto článku:

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

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é. Například si představte, že máte HTTP akci, která vyžaduje základní autentizaci, 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 .

Important

Pro optimální bezpečnost používejte Microsoft Entra ID se spravovanými identitami pro autentizaci, pokud je to možné. Tato možnost poskytuje vynikající bezpečnost bez nutnosti přihlašovacích údajů. 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.

Important

Pro optimální bezpečnost používejte Microsoft Entra ID se spravovanými identitami pro autentizaci, pokud je to možné. Tato možnost poskytuje vynikající bezpečnost bez nutnosti přihlašovacích údajů. 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.

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 Description
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 Logic a podporované konektory
Basic 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
služba 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
Nezpracovaný 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

Important

Pro optimální bezpečnost používejte Microsoft Entra ID se spravovanými identitami pro autentizaci, pokud je to možné. Tato možnost poskytuje vynikající bezpečnost bez nutnosti přihlašovacích údajů. 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ří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.

Note

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.

Important

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:

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, abyste k ověřování použili ID Microsoft Entra se spravovanými identitami , pokud je to možné. Tato možnost poskytuje vynikající bezpečnost bez nutnosti přihlašovacích údajů. 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.

  • Autorizační zásada musí zahrnovat alespoň claimy Issuer a Audience. Deklarace identity Issuer má hodnotu, která začíná buď na https://sts.windows.net/, nebo na https://login.microsoftonline.com/ (OAuth V2) jako identifikátor vystavitele pro Microsoft Entra ID. Tvrzení o publiku má hodnotu, která je očekávaným publikem pro váš zdroj logické aplikace.

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

Povolení OAuth 2.0 s Microsoft Entra ID jako jedinou možností volání koncového bodu žádosti

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

  1. Ve vašem pracovním postupu nastavte aktivační událost Request nebo aktivační událost HTTP Webhook tak, aby bylo možné ověřit přístupový token OAuth, a to podle postupu pro zahrnutí hlavičky „Authorization“ do výstupů aktivační události Request nebo HTTP webhooku.

    Note

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

  2. Na portálu Azure otevřete pracovní postup v návrháři.

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

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

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

    -or-

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

Pokud zavoláte koncový bod triggeru bez správné autorizace, v historii běhu se trigger zobrazí jako Skipped bez jakékoli zprávy o tom, že podmínka triggeru selhala.

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

Knihovny MSAL (Identity a ověřování Microsoftu) poskytují tokeny PoP, které můžete použít. Pokud workflow aplikace Consumption logic, který chcete volat, vyžaduje PoP token, můžete tento token získat pomocí MSAL knihoven. 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:

  1. V Azure portálu otevřete aplikaci Consumption logic a pracovní postup v návrháři.

  2. V postranním panelu logické aplikace v Nastavení vyberte Autorizace.

  3. Na stránce Autorizace vyberte Přidat zásadu.

    Screenshot, který ukazuje Azure portál, stránku autorizace a vybrané tlačítko pro přidání politiky.

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

    Screenshot, který ukazuje Azure portál, stránku autorizace a podrobnosti o autorizační politice.

    Property Povinné Typ Description
    Název zásady Ano String Název, který chcete použít pro zásady autorizace
    Typ zásady Ano String Buď AAD pro tokeny typu nosič nebo AADPOP pro tokeny typu Proof-of-Possession.
    Claims Ano String 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 Claims musí minimálně obsahovat následující typy deklarací:

    -- Vydavatel: Nastavte hodnotu tak, aby začínala na https://sts.windows.net/ nebo https://login.microsoftonline.com/ jako identifikátorem vydavatele Microsoft Entra.
    -- Cílová skupina: Hodnota je nastavená na očekávanou cílovou skupinu prostředku aplikace logiky.

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

    Můžete také zadat vlastní typ a hodnotu nároku. Další informace o těchto typech požadavků naleznete v části Požadavky v bezpečnostních tokenech Microsoft Entra.

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

    Snímek obrazovky zobrazující portál Azure, stránku Autorizace a informace o zásadě prokázání držení.

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

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

  7. Až budete hotovi, vyberte Uložit.

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

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

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:

Screenshot, který ukazuje Azure portál, workflow Consumption a vlastnost endpointu Request trigger s názvem HTTP URL.

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

Important

Chraňte svůj SAS klíč stejně jako chráníte klíč k úč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.

Pro udržení bezpečnosti a ochranu přístupu k vašemu pracovnímu postupu pravidelně obnovujte přístupové klíče , protože mohou být nutné dodržovat bezpečnostní politiky nebo být kompromitovány. 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 k přístupu ke službám úložiště používáte klíč SAS, vytvořte uživatelsky delegovaný SAS, který je zabezpečený pomocí Microsoft Entra ID, namísto SAS zabezpečeného klíčem účtu.

Pro optimální bezpečnost používejte Microsoft Entra ID s řízenými identitami pro autentizaci, kdykoli je to možné. Tato možnost poskytuje vynikající bezpečnost bez nutnosti přihlašovacích údajů. 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:

Zakázání ověřování sdíleného přístupového podpisu (SAS)

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:

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

Pokud váš pracovní postup začíná triggerem požadavku a chcete použít OAuth s Microsoft Entra ID, 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.

Note

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

Předpoklady pro vypnutí SAS autentizace

Chcete-li zakázat ověřování SAS u triggeru založeného na požadavku, potřebujete nástroj k odesílání volání rozhraní REST API, například:

Caution

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.

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

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

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

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

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

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

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

  1. Na webu Azure Portal otevřete prostředek aplikace logiky, který používá klíč, který chcete znovu vygenerovat.

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

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

Important

Chraňte svůj přístupový klíč stejně jako chráníte klíč k úč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. Kdokoli, kdo má URI s platným klíčem, může přistupovat k příslušnému zdroji.

Pokud používáte SAS klíč k přístupu k úložným službám, vytvořte uživatelský delegační SAS, který je zabezpečený Microsoft Entra ID, místo klíče účtu.

Pro optimální bezpečnost používejte Microsoft Entra ID se spravovanými identitami pro autentizaci, pokud je to možné. Tato možnost poskytuje vynikající bezpečnost bez nutnosti přihlašovacích údajů. 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.

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. Pomocí tohoto přístupu můžete plynule obměňovat klíče nebo omezit přístup ke spuštění vaší logické aplikace na určité časové období. 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 tady:

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ý IP rozsah používá tyto formáty: x.x.x.x/x nebo x.x.x.x-x.x.x.x.

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

Pracovní postupy spotřeby

  1. V Azure portálu otevřete aplikaci Consumption logic a pracovní postup v návrháři.

  2. V postranním panelu Logické aplikace v Nastavení vyberte Nastavení pracovního postupu.

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

    • Chcete-li, aby bylo možné váš pracovní postup volat pomocí integrované akce Azure Logic Apps, ale pouze jako vnořený pracovní postup, vyberte možnost Pouze jiné aplikace 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.

    • Chcete-li svůj pracovní postup vyvolat 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ý IP rozsah používá tyto formáty: x.x.x.x/x nebo x.x.x.x-x.x.x.x.

      Note

      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ý IP rozsah používá tyto formáty: x.x.x.x/x nebo x.x.x.x-x.x.x.x.

  4. Volitelně, v sekci Omezit volání pro získání vstupních a výstupních zpráv z historie běhů na zadané IP adresy, určete rozsahy IP adres pro příchozí hovory, které mohou přistupovat ke vstupním a výstupním zprávám v historii běhů.

Standardní pracovní postupy

  1. V Azure Portal otevřete prostředek Standardní aplikace logiky.

  2. Na postranním panelu Logické aplikace v Nastavení vyberte Síťové připojení.

  3. V části Konfigurace příchozího provozu vedle přístupu k veřejné síti vyberte Povoleno bez omezení přístupu.

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

  5. 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ý IP rozsah používá tyto formáty: x.x.x.x/x nebo x.x.x.x-x.x.x.x.

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

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

Na základě schopností cílového koncového bodu podporují odchozí hovory odeslané pomocí HTTP triggeru nebo HTTP akce šifrování a jsou zabezpečeny pomocí Transport Layer Security (TLS) 1.0, 1.1, 1.2 nebo 1.3, dříve známé jako Secure Sockets Layer (SSL). 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.3, trigger HTTP nebo akce nejprve použije hodnotu 1.3. 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.

    • Brána pro místní data.

      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í přes 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ů.

      Note

      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:

        • Trigger: Přidejte trigger s názvem Choose an Azure API Management Trigger podle obecných kroků.

        • Akce: Přidejte akci s názvem Vyberte akci Azure API Management podle obecných kroků.

      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 přidejte akci s názvem Volat rozhraní API služby Azure API Management podle obecných kroků.

      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 Vytvořit nový.

        Screenshot, který ukazuje Azure portál, standardního workflow designéra a vybrané API k volání.

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

Koncové body HTTP a HTTPS podporují různé druhy ověřování. U některých triggerů a akcí, které používáte k odesílání odchozích volání nebo požadavků do těchto koncových bodů, můžete zadat typ ověřování. V návrháři pracovního postupu mají triggery a akce 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í.

Important

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

Pro optimální bezpečnost používejte Microsoft Entra ID se spravovanými identitami pro autentizaci, pokud je to možné. Tato možnost poskytuje vynikající bezpečnost bez nutnosti přihlašovacích údajů. 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.

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.

Important

Pro optimální bezpečnost používejte Microsoft Entra ID se spravovanými identitami pro autentizaci, pokud je to možné. Tato možnost poskytuje vynikající bezpečnost bez nutnosti přihlašovacích údajů. 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.

Pokud je k dispozici a vybrána možnost Základní , zadejte tyto hodnoty vlastností:

Vlastnost (návrhář) Vlastnost (JSON) Povinné Value Description
Authentication 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 schopnost vám pomůže přijmout autentizaci odolnou vůči phishingu a autentizovat se pomocí certifikátu X.509 proti vaší infrafraře veřejných klíčů (PKI).

Important

Pro optimální bezpečnost používejte Microsoft Entra ID se spravovanými identitami pro autentizaci, pokud je to možné. Tato možnost poskytuje vynikající bezpečnost bez nutnosti přihlašovacích údajů. 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.

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

Vlastnost (návrhář) Vlastnost (JSON) Povinné Value Description
Authentication 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 No < heslo pro soubor pfx> Heslo pro přístup k souboru PFX

Note

Pokud se pokusíte autentizovat pomocí klientského certifikátu pomocí OpenSSL, můžete dostat následující chybu:

BadRequest: Could not load private key

Tuto chybu vyřešíte takto:

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

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

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

Important

Pokud máte standardní logickou aplikaci v single-tenant Azure Logic Apps a chcete použít HTTP operaci s TLS/SSL certifikátem, klientským certifikátem nebo Microsoft Entra ID OAuth s typem Certificate přihlašovacích údajů, ujistěte se, že dokončíte další nastavovací kroky pro tento typ autentizace. Jinak volání selže. Další informace najdete v tématu Ověřování v prostředí s jedním tenantem.

Pro více informací o zabezpečení služeb pomocí autentizace klientských certifikátů viz:

služba Active Directory OAuth (OAuth 2.0 s Microsoft Entra ID) autentizace

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.

Important

Pro optimální bezpečnost používejte Microsoft Entra ID se spravovanými identitami pro autentizaci, pokud je to možné. Tato možnost poskytuje vynikající bezpečnost bez nutnosti přihlašovacích údajů. 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.

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

Vlastnost (návrhář) Vlastnost (JSON) Povinné Value Description
Authentication type Ano služba 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 No < 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 tenanta> ID tenanta pro nájemce Microsoft Entra
Publikum 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": {}
}

Important

Pokud máte standardní logickou aplikaci v single-tenant Azure Logic Apps a chcete použít HTTP operaci s TLS/SSL certifikátem, klientským certifikátem nebo Microsoft Entra ID OAuth s typem Certificate přihlašovacích údajů, ujistěte se, že dokončíte další nastavovací kroky pro tento typ autentizace. 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 dostupná možnost Raw , použijte tento typ autentizace, když potřebujete použít autentizační schémata , která neodpovídají protokolu 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.

Important

Pro optimální bezpečnost používejte Microsoft Entra ID se spravovanými identitami pro autentizaci, pokud je to možné. Tato možnost poskytuje vynikající bezpečnost bez nutnosti přihlašovacích údajů. 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.

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) Povinné Value Description
Authentication type Ano Syrový Typ ověřování, který se má použít
Value value Ano < Hodnota hlavičky autorizace> Hodnota autorizační hlavičky, která se má použít pro ověřování

Když používáte zabezpečené parametry pro zpracování a zabezpečení citlivých informací, například v šabloně Azure Resource Manager pro automatizaci nasazení, můžete použít výrazy k přístupu 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

Když je možnost spravované identity dostupná na spouštěči nebo akci podporující autentizaci spravované identity, vaše logická aplikace může tuto identitu použít k ověření přístupu k Azure zdrojům chráněným Microsoft Entra ID, místo použití přihlašovacích údajů, tajemství nebo Microsoft Entra ID. 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.

    Note

    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 deaktivujete, připojení nefunguje za běhu. Pro zobrazení tohoto nastavení vyberte v postranním panelu vaší logické aplikace v sekci NastaveníIdentitu.

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

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

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

    Integrované triggery a akce

    Vlastnost (návrhář) Vlastnost (JSON) Povinné Value Description
    Authentication type Ano Spravovaná identita
    nebo
    ManagedServiceIdentity    		 Typ ověřování, který se má použít
    Spravovaná identita identity No < 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.
    Publikum 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 cílové ID prostředku přesně odpovídá hodnotě, kterou Microsoft Entra ID očekává, 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. Avšak 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.

    Když používáte zabezpečené parametry pro zpracování a zabezpečení citlivých informací, například v šabloně Azure Resource Manager pro automatizaci nasazení, můžete použít výrazy k přístupu 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ář) Povinné Value Description
    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

Bloková spojení vytvořená specifickými konektory

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í

Pro více informací o izolaci viz:

Související obsah

  • Last updated on