Zabezpečení přístupu a dat v Azure Logic Apps

  • Článek

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

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

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

Přístup k operacím aplikace logiky

Pouze u aplikací logiky Consumption potřebujete před vytvářením nebo správou aplikací logiky a jejich připojení specifická oprávnění, která jsou poskytována prostřednictvím rolí pomocí řízení přístupu na základě role v Azure (Azure RBAC). Můžete také nastavit oprávnění tak, aby konkrétní úlohy, jako je správa, úpravy a zobrazení aplikací logiky, mohli spouštět jenom konkrétní uživatelé nebo skupiny. Pokud chcete ří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í specifické role:

  • Přispěvatel aplikací logiky: Umožňuje spravovat aplikace logiky, ale nemůžete k nim měnit přístup.

  • Operátor aplikace logiky: Umožňuje číst, povolit a zakázat aplikace logiky, ale nemůžete je upravovat ani aktualizovat.

  • Přispěvatel: Uděluje úplný přístup ke správě všech prostředků, ale neumožňuje přiřazovat role v Azure RBAC, spravovat přiřazení v Azure Blueprints ani sdílet galerie obrázků.

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

Pokud chcete ostatním zabránit v tom, aby vaši aplikaci logiky změnili nebo odstranili, můžete použít Zámek prostředků Azure. Tato funkce brání ostatním ve 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í.

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

Během spuštění aplikace logiky se všechna data během přenosu šifrují pomocí protokolu TLS (Transport Layer Security) a neaktivních uložených dat. Po dokončení spuštění aplikace logiky můžete zobrazit historii tohoto spuštění, včetně kroků, které proběhly spolu se stavem, dobou trvání, vstupy a výstupy jednotlivých akcí. Tyto podrobné informace poskytují přehled o tom, jak vaše aplikace logiky běžela a kde můžete začít řešit případné problémy.

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

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

Omezení přístupu podle rozsahu IP adres

Přístup ke vstupům a výstupům v historii spuštění 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 uživatelů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 vaší aplikace logiky za běhu.

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

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

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

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

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

    Platný rozsah IP adres používá tyto formáty: x.x.x.x/x nebo x.x.x.x-x.x.x.x

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

Zabezpečené vstupy – nepodporované Zabezpečené výstupy – nepodporované
Připojit k proměnné pole
Připojit k řetězcové proměnné
Dekrementační proměnná
Pro každou
Pokud uživatel
Inkrementační proměnná
Inicializace proměnné
Opakování
Obor
Nastavit proměnnou
Přepínač
Terminate (Ukončení)
Dokud		 Připojit k proměnné pole
Připojit k řetězcové proměnné
Vytvořit
Dekrementační proměnná
Pro každou
Pokud uživatel
Inkrementační proměnná
Inicializace proměnné
Parsovat JSON
Opakování
Odpověď
Obor
Nastavit proměnnou
Přepínač
Terminate (Ukončení)
Dokud
Wait

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

Než použijete tato nastavení k lepšímu zabezpečení těchto dat, 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. Ke triggeru nebo akci pro monitorování také nemůžete přidat sledované vlastnosti .

  • Rozhraní API služby 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ě funkci Zabezpečené výstupy .

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

    Nastavení Zabezpečené výstupy

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

    Zabezpečené výstupy jako vstupy a následný dopad na většinu akcí

    Akce Compose, Parse JSON a Response mají jenom nastavení Zabezpečené vstupy . Když je toto nastavení zapnuté, skryje 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é vstupy 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 neskrývá vstupy nebo výstupy této podřízené akce.

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

    Nastavení zabezpečených vstupů

    Když v triggeru nebo akci ručně zapnete zabezpečené vstupy , Azure Logic Apps tyto vstupy skryje v historii spuštění. Pokud podřízená akce explicitně používá viditelné výstupy z této aktivační události 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 neskryje výstupy této akce.

    Zabezpečené vstupy a následný dopad na většinu akcí

    Pokud akce Compose, Parse JSON a Response explicitně používají viditelné výstupy z triggeru nebo akce, která má zabezpečené vstupy, Azure Logic Apps skryje vstupy a výstupy těchto akcí, ale nepovoluje nastavení Zabezpečené vstupy 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 neskrývá vstupy nebo výstupy této podřízené akce.

    Zabezpečené vstupy a následný dopad na konkrétní akce

Zabezpečení vstupů a výstupů v návrháři

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

    Otevření aplikace logiky v aplikaci logiky Designer

  2. Na triggeru nebo akci, kde chcete zabezpečit citlivá data, vyberte tlačítko se třemi tečkami (...) a pak vyberte Nastavení.

    Otevření nastavení triggeru nebo akce

  3. Zapněte buď zabezpečené vstupy, zabezpečené výstupy, nebo obojí. Jakmile budete hotovi, vyberte Hotovo.

    Zapněte

    Akce nebo aktivační událost teď v záhlaví zobrazuje ikonu zámku.

    V záhlaví akce nebo aktivační události se zobrazuje ikona zámku.

    Tokeny, které představují zabezpečené výstupy z předchozích akcí, také zobrazují ikony zámků. Když například vyberete takový výstup ze seznamu dynamického obsahu, který se má použít v akci, zobrazí se v tomto tokenu ikona zámku.

    Výběr tokenu pro zabezpečený výstup

  4. Po spuštění aplikace logiky můžete zobrazit historii tohoto spuštění.

    1. V podokně Přehled aplikace logiky vyberte spuštění, které chcete zobrazit.

    2. V podokně Spuštění aplikace logiky rozbalte akce, které chcete zkontrolovat.

      Pokud jste se rozhodli zakrýt vstupy i výstupy, budou se tyto hodnoty zobrazovat skryté.

      Skryté vstupy a výstupy v historii spuštění

Zabezpečení vstupů a výstupů v zobrazení kódu

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

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

Přístup ke vstupům parametrů

Pokud nasazujete do různých prostředí, zvažte parametrizaci hodnot v definici pracovního postupu, které se liší v závislosti na těchto prostředích. Tímto způsobem se můžete vyhnout pevně zakódovaným datům pomocí šablony Azure Resource Manager 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í otevřeného ověřování Azure Active Directory (Azure AD OAuth), 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 tyto parametry definovat v aplikaci logiky, použijte parameters oddíl v definici pracovního postupu aplikace logiky a Resource Manager šablonu pro nasazení. Pokud chcete zabezpečit hodnoty parametrů, které nechcete zobrazovat při úpravách aplikace logiky nebo zobrazení historie spuštění, definujte parametry pomocí securestring typu nebo secureobject a podle potřeby použijte kódování. Parametry, které mají tento typ, se nevrátí s definicí prostředku a nejsou přístupné při zobrazení 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 se vyhodnocuje pouze za běhu a popisuje ho jazyk 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í aplikace logiky a odchozího požadavku HTTP. Nezapomeňte také odpovídajícím způsobem nastavit zásady přístupu k obsahu. Pomocí obfuskace můžete také skrýt vstupy a výstupy v historii spuštění. Autorizační hlavičky nejsou nikdy viditelné prostřednictvím vstupů nebo výstupů. Pokud se tam používá tajný kód, není možné ho načíst.

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

Pokud automatizujete nasazení pro aplikace logiky pomocí šablon Resource Manager, můžete pomocí typů a secureobject definovat zabezpečené parametry šablony, které se vyhodnocují při nasazenísecurestring. K definování parametrů šablony použijte oddíl nejvyšší úrovně parameters vaší šablony, který je oddělený a liší se 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í z Azure Key Vault při nasazení. Pak můžete odkazovat na trezor klíčů a tajný klíč v souboru parametrů. Další informace najdete v těchto tématech:

Zabezpečené parametry v definicích pracovních postupů

Pokud chcete chránit citlivé informace v definici pracovního postupu aplikace logiky, použijte zabezpečené parametry, aby tyto informace po uložení aplikace logiky nebylo vidět. Předpokládejme například, že máte akci HTTP, která vyžaduje základní ověřování, které používá uživatelské jméno a heslo. V definici parameters pracovního postupu oddíl definuje basicAuthPasswordParam parametry a basicAuthUsernameParam pomocí securestring typu. Definice akce pak odkazuje na tyto parametry v oddílu authentication .

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

Zabezpečené parametry v šablonách Azure Resource Manager

Šablona Resource Manager pro aplikaci logiky má 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 definice pracovního postupu pomocí securestring typu nebo secureobject . Tyto hodnoty pak můžete uložit v Azure Key Vault a pomocí souboru parametrů odkazovat na trezor klíčů a tajný klíč. Šablona pak načte informace při nasazení. Další informace najdete v tématu Předání citlivých hodnot při nasazení pomocí Azure Key Vault.

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

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

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

  • V rámci definice pracovního postupu definuje oddíl parametry, parameters které vaše aplikace logiky používá za běhu. Na tyto parametry pak můžete odkazovat v pracovním postupu aplikace logiky pomocí výrazů definice pracovního postupu, které se vyhodnocují za běhu.

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

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 ověřování Podporované konektory aplikace & logiky
Basic Azure API Management, Aplikace Azure Services, HTTP, HTTP + Swagger, WEBhook HTTP
Klientský certifikát Azure API Management, Aplikace Azure Services, HTTP, HTTP + Swagger, WEBhook HTTP
Active Directory OAuth - Využití: Azure API Management, Aplikace Azure Services, Azure Functions, HTTP, HTTP + Swagger, WEBhook HTTP

- Standardní: Azure Automation, Azure Blob Storage, Azure Event Hubs, fronty Azure, Azure Service Bus, tabulky Azure, HTTP, webhook HTTP SQL Server
Žádný Azure API Management, Aplikace Azure Services, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
Spravovaná identita Integrované konektory:

- Využití: Azure API Management, Aplikace Azure Services, Azure Functions, HTTP, webhook HTTP

- Standardní: Azure Automation, Azure Blob Storage, Azure Event Hubs, fronty Azure, Azure Service Bus, tabulky Azure, HTTP, webhook HTTP SQL Server

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

Spravované konektory: Azure AD Identity Protection, 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, virtuální počítač Azure, HTTP s Azure AD SQL Server

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

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

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

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

Poznámka

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

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

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA

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

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

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

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

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

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

Příchozí volání koncového bodu požadavku můžou používat pouze jedno schéma autorizace, a to buď SAS, nebo otevřené ověřování Azure Active Directory. I když použití jednoho schématu nezakáže druhé, použití obou schémat současně způsobí chybu, protože služba neví, které schéma zvolit.

Další informace o zabezpečení přístupu pomocí SAS najdete v těchto částech tohoto tématu:

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

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

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

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

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

Vytvoření adres URL zpětného volání, kterým vyprší platnost

Pokud sdílíte adresu URL koncového bodu triggeru založeného 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. Díky tomu můžete bezproblémově spouštět klíče nebo omezit přístup k aktivaci aplikace logiky na základě konkrétního časového rozsahu. Pokud chcete zadat datum vypršení platnosti adresy URL, použijte rozhraní REST API služby Azure Logic Apps, například:

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

V těle zahrňte NotAftervlastnost pomocí řetězce data JSON. Tato vlastnost vrátí adresu URL zpětného volání, která je platná pouze do NotAfter 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 podepsání adresy URL. Pokud chcete vygenerovat adresu URL podepsanou konkrétním klíčem, použijte rozhraní REST API služby Logic Apps, například:

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

V těle zahrňte KeyType vlastnost jako nebo PrimarySecondary. Tato vlastnost vrátí adresu URL podepsanou zadaným klíčem zabezpečení.

Povolení otevřeného ověřování Azure Active Directory (Azure AD OAuth)

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

Když vaše aplikace logiky obdrží příchozí požadavek, který obsahuje přístupový token OAuth, azure Logic Apps porovná deklarace identity tokenu s deklaracemi identit určenými jednotlivými zásadami autorizace. Pokud se deklarace identity tokenu shodují se všemi deklaracemi identity v alespoň jedné zásadě, autorizace příchozího požadavku proběhne úspěšně. Token může mít více deklarací identity, než je číslo určené zásadami autorizace.

V pracovním postupu aplikace logiky Standard, který se spouští triggerem požadavku (ale ne triggerem webhooku), můžete pomocí Azure Functions zřízení ověřit příchozí volání odesílaná do koncového bodu vytvořeného tímto triggerem pomocí spravované identity. Toto zřízení se označuje také 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 Azure AD OAuth

  • Příchozí volání koncového bodu žádosti může používat pouze jedno schéma autorizace, Azure AD OAuth nebo sdílený přístupový podpis (SAS). I když použití jednoho schématu nezakáže druhé, použití obou schémat současně způsobí chybu, protože Azure Logic Apps neví, které schéma zvolit.

    Pokud chcete povolit Azure AD OAuth, aby tato možnost byla jediným způsobem volání koncového bodu požadavku, postupujte následovně:

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

    2. Na triggeru vyberte v pravém horním rohu tlačítko se třemi tečkami (...) a pak vyberte Nastavení.

    3. V části Aktivační podmínky vyberte Přidat. Do pole podmínka triggeru zadejte následující výraz a vyberte Hotovo.

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

    Poznámka

    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.

  • Pro Azure AD přístupové tokeny OAuth jsou podporována pouze schémata autorizace nosný typ, což znamená, že Authorization typ musí určovat hlavička přístupového tokenuBearer.

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

  • Zásady autorizace musí obsahovat alespoň deklaraci identity vystavitele, která má hodnotu, která začíná na nebo https://sts.windows.net/https://login.microsoftonline.com/ (OAuth V2) jako ID vystavitele Azure AD.

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

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

Povolení Azure AD OAuth pro aplikaci logiky

Pro Azure Portal nebo šablonu Azure Resource Manager postupujte následovně:

V Azure Portal přidejte do aplikace logiky jednu nebo více zásad autorizace:

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

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

    Vyberte

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

    Zadání informací pro zásady autorizace

    Vlastnost Požaduje se Typ Popis
    Název zásad Ano Řetězec Název, který chcete použít pro zásady autorizace
    Žádosti Ano Řetězec Typy deklarací identity a hodnoty, které pracovní postup přijímá z příchozích volání. Tady jsou dostupné typy deklarací identity:

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

    Požadavky:

    – Seznam deklarací identity musí obsahovat minimálně deklaraci identity vystavitele, která má hodnotu, která začíná https://sts.windows.net/ na nebo https://login.microsoftonline.com/ jako id Azure AD vystavitele.
    – Každá deklarace identity musí být jedna řetězcová hodnota, ne pole hodnot. Můžete mít například deklaraci identity s typem Role a hodnotou Developer . Nemůžete mít deklaraci identity, která má jako typ Roli a hodnoty nastavené na Developer a Program Manager.
    – Hodnota deklarace identity je omezená na maximální počet znaků.

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

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

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

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

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

  6. Jakmile budete mít hotovo, vyberte Uložit.

  7. Pokud chcete do výstupů triggeru Authorization založeného na požadavku zahrnout hlavičku z přístupového tokenu, projděte si téma Zahrnutí hlavičky autorizace do výstupů triggeru požadavku.

Vlastnosti pracovního postupu, jako jsou zásady, se nezobrazují v zobrazení kódu aplikace logiky v Azure Portal. Pokud chcete získat přístup k zásadám prostřednictvím kódu programu, volejte následující rozhraní API prostřednictvím Azure Resource Manager: https://management.azure.com/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group-name}/providers/Microsoft.Logic/workflows/{your-workflow-name}?api-version=2016-10-01&_=1612212851820. Nezapomeňte nahradit zástupné hodnoty pro ID předplatného Azure, název skupiny prostředků a název pracovního postupu.

Zahrnout autorizační hlavičku do výstupů triggeru požadavku

Pro aplikace logiky, které umožňují ověřování Azure Active Directory Open Authentication (Azure AD OAuth) pro autorizaci příchozích volání pro přístup k triggerům založeným na žádostech, můžete povolit výstupy triggeru požadavku nebo triggeru webhooku HTTP tak, aby zahrnovaly hlavičku Authorization z přístupového tokenu OAuth. V základní definici JSON triggeru přidejte a nastavte operationOptions vlastnost na IncludeAuthorizationHeadersInOutputs. Tady je příklad triggeru Požadavku:

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

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

Zveřejnění aplikace logiky pomocí Azure API Management

Pokud chcete získat další ověřovací protokoly a možnosti, zvažte zveřejnění aplikace logiky jako rozhraní API pomocí Azure API Management. Tato služba poskytuje bohaté možnosti monitorování, zabezpečení, zásad a dokumentace pro libovolný koncový bod. 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 otevřené ověřování Azure Active Directory (Azure AD OAuth), klientský certifikát nebo jiné standardy zabezpečení. Když API Management obdrží požadavek, služba odešle požadavek do vaší aplikace logiky a provede všechny potřebné transformace nebo omezení. Pokud chcete aplikaci logiky volat 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ří můžou volat vaši aplikaci logiky. Pokud například spravujete koncový bod požadavku pomocí Azure API Management, můžete aplikaci logiky omezit tak, aby přijímala požadavky jenom z IP adresy pro instanci služby API Management, kterou vytvoříte.

Bez ohledu na zadané IP adresy můžete aplikaci logiky s triggerem založeným na požadavku spustit pomocí rozhraní REST API služby Logic Apps: Triggery pracovního postupu – Spustit požadavek nebo pomocí API Management. Tento scénář ale stále vyžaduje ověřování pomocí 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 pro vaši aplikaci logiky, postupujte podle těchto kroků pro Azure Portal nebo šablonu Azure Resource Manager:

V Azure Portal tento filtr ovlivňuje triggery i akce, což je v rozporu s popisem na portálu v části Povolené příchozí IP adresy. Pokud chcete tento filtr nastavit samostatně pro triggery a akce, použijte accessControl objekt v šabloně Azure Resource Manager pro vaši aplikaci logiky nebo rozhraní REST API služby Azure Logic Apps: Pracovní postup – operace vytvoření nebo aktualizace.

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

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

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

    • Pokud chcete, aby se vaše aplikace logiky pomocí integrované akce Azure Logic Apps volatelná jenom jako vnořená aplikace logiky, vyberte Pouze jiné aplikace logiky, která funguje jenom v případě, že k volání vnořené aplikace logiky použijete akci Azure Logic Apps .

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

    • Pokud chcete aplikaci logiky volat jenom jako vnořenou aplikaci pomocí akce HTTP, vyberte Konkrétní rozsahy IP adres, neJenom ostatní aplikace logiky. Když se zobrazí pole Rozsahy IP adres pro triggery , zadejte odchozí IP adresy nadřazené aplikace logiky. 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é aplikace logiky použijete možnost Pouze jiné logic Apps a akci HTTP, volání se zablokuje a zobrazí se chyba 401 Neautorizováno.

    • Ve scénářích, kdy chcete omezit příchozí volání z jiných IP adres, když se zobrazí pole Rozsahy IP adres pro triggery, zadejte rozsahy IP adres, které trigger přijímá. Platný rozsah IP adres používá tyto formáty: x.x.x.x/x nebo x.x.x.x-x.x.x.x.

  4. Volitelně můžete v části Omezit volání za účelem 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í.

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

V závislosti na schopnostech cílového koncového bodu odchozí volání odesílaná triggerem HTTP nebo akcí HTTP podporují š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 použitím nejvyšší možné verze, která je podporována. Pokud například cílový koncový bod podporuje verzi 1.2, trigger http nebo akce nejprve použije 1.2. V opačném případě konektor používá další nejvyšší podporovanou verzi.

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

Tady jsou další způsoby, jak můžete pomoct zabezpečit koncové body, které zpracovávají volání odeslaná z vaší 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 aplikace logiky.

    Všechna volání koncových bodů z aplikací 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 tyto IP adresy získat, projděte si téma Omezení a konfigurace pro Azure Logic Apps.

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

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

    • Místní brána dat

      Řada spravovaných konektorů v Azure Logic Apps umožň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ů v šifrovaných kanálech prostřednictvím Azure Service Bus. Veškerý provoz pochází jako zabezpečený odchozí provoz z agenta brány. 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 servery 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 zveřejnili vytvořením instance služby API Management, můžete toto rozhraní API volat v pracovním postupu vaší aplikace logiky tak, že v návrháři pracovního postupu vyberete předdefinovaný trigger nebo akci API Management.

      Poznámka

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

      1. V návrháři pracovního postupu zadejte api management do vyhledávacího pole . Zvolte krok podle toho, jestli přidáváte trigger nebo akci:

        • Pokud přidáváte trigger, který je vždy prvním krokem v pracovním postupu, vyberte Zvolit trigger Azure API Management.

        • Pokud přidáváte akci, vyberte Zvolit akci azure API Management.

        Tento příklad přidá trigger:

        Přidání triggeru Azure API Management

      2. Vyberte dříve vytvořenou instanci služby API Management.

        Výběr instance služby API Management

      3. Vyberte volání rozhraní API, které chcete použít.

        Vyberte existující rozhraní API.

Přidání ověřování k odchozím voláním

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ů na tyto koncové body, můžete zadat typ ověřování. V návrháři pracovního postupu mají triggery a akce, které podporují volbu typu ověřování, vlastnost Ověřování . Tato vlastnost se ale nemusí vždy zobrazovat ve výchozím nastavení. V těchto případech v triggeru nebo akci otevřete seznam Přidat nový parametr a vyberte Ověřování.

Důležité

Pokud chcete chránit citlivé informace, které vaše aplikace logiky zpracovává, použijte zabezpečené parametry a podle potřeby kódujte data. Další informace o používání a zabezpečení parametrů najdete v tématu Přístup ke vstupům parametrů.

Základní ověřování

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

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

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

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

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

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

Vlastnost (návrhář) Vlastnost (JSON) Vyžadováno Hodnota Popis
Authentication type Yes Klientský certifikát
nebo
ClientCertificate		 Typ ověřování, který se má použít. Certifikáty můžete spravovat pomocí 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 Yes <encoded-pfx-file-content> Obsah kódovaný jako base64 ze souboru PFX (Personal Information Exchange)

Pokud chcete převést soubor PFX do formátu s kódováním base64, můžete použít PowerShell 7 pomocí těchto kroků:

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

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

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

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

Řešení potíží: Pokud použijete 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.

Chcete-li tuto chybu vyřešit, zkuste převést soubor PFX na soubor PEM a znovu pomocí openssl příkazu:

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

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

Pokud používáte zabezpečené parametry ke zpracování a zabezpečení citlivých informací, například v šabloně Azure Resource Manager pro automatizaci nasazení, můžete k těmto hodnotám parametrů za běhu přistupovat pomocí výrazů. Tato ukázková definice akce HTTP určuje ověřování type jako ClientCertificate a používá funkci parameters() k získání hodnot 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 aplikace logiky (Standard) v Azure Logic Apps s jedním tenantem a chcete použít operaci HTTP s certifikátem TSL/SSL, klientským certifikátem nebo otevřeným ověřováním Azure Active Directory (Azure AD OAuth) s typem Certificate přihlašovacích údajů, nezapomeňte pro tento typ ověřování provést další kroky nastavení. V opačném případě 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:

Otevřené ověřování Azure Active Directory

V triggerech požadavků můžete k ověřování příchozích volání po nastavení zásad autorizace Azure AD pro aplikaci logiky použít otevřené ověřování Azure Active Directory (Azure AD OAuth). Pro všechny ostatní triggery a akce, které poskytují typ ověřování Active Directory OAuth , který můžete vybrat, zadejte tyto hodnoty vlastností:

Vlastnost (návrhář) Vlastnost (JSON) Vyžadováno Hodnota Popis
Authentication type Yes Active Directory OAuth
nebo
ActiveDirectoryOAuth		 Typ ověřování, který se má použít. Azure Logic Apps se v současné době řídí protokolem OAuth 2.0.
Autorita authority No <Url-for-authority-token-issuer> Adresa URL autority, která poskytuje přístupový token, 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 Azure AD koncové body ověřování – Volba vaší autority identity.
Tenant tenant Yes <ID tenanta> ID tenanta pro tenanta Azure AD
Cílová skupina audience Yes <autorizace prostředku> Prostředek, který chcete použít k autorizaci, například https://management.core.windows.net/
ID klienta clientId Yes <CLIENT-ID> ID klienta aplikace, která žádá o autorizaci
Typ přihlašovacích údajů credentialType Yes Certifikát
nebo
Tajný kód		 Typ přihlašovacích údajů, který klient používá pro žádost o autorizaci. Tato vlastnost a hodnota se nezobrazují v základní definici aplikace logiky, ale určují vlastnosti, které se zobrazí pro vybraný typ přihlašovacích údajů.
Tajný kód secret Ano, ale jenom pro typ přihlašovacích údajů Tajný <tajný klíč klienta> Tajný klíč klienta pro žádost o autorizaci
Pfx pfx Ano, ale pouze pro typ přihlašovacích údajů "Certifikát". <encoded-pfx-file-content> Obsah kódovaný jako base64 ze souboru PFX (Personal Information Exchange)
Heslo password Ano, ale pouze pro typ přihlašovacích údajů "Certifikát". <password-for-pfx-file> Heslo pro přístup k souboru PFX

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

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

Důležité

Pokud máte prostředek aplikace logiky (Standard) v Azure Logic Apps s jedním tenantem a chcete použít operaci HTTP s certifikátem TSL/SSL, klientským certifikátem nebo otevřeným ověřováním Azure Active Directory (Azure AD OAuth) s typem Certificate přihlašovacích údajů, nezapomeňte pro tento typ ověřování provést další kroky nastavení. V opačném případě volání selže. Další informace najdete v tématu Ověřování v prostředí s jedním tenantem.

Nezpracované ověřování

Pokud je k dispozici možnost Nezpracovaný , můžete tento typ ověřování použít, když musíte 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 spolu s odchozím požadavkem, a tuto hodnotu hlavičky zadáte do triggeru nebo akce.

Následující příklad ukazuje ukázkovou hlavičku pro požadavek 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) Vyžadováno Hodnota Popis
Authentication type Yes Žádný Typ ověřování, který se má použít
Hodnota value Yes <authorization-header-value> Hodnota hlavičky autorizace, která se má použít pro ověřování

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

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

Ověřování spravovaných identit

Pokud je u triggeru nebo akce, která podporuje ověřování spravovaných identit, dostupná možnost spravované identity, může aplikace logiky tuto identitu použít k ověřování přístupu k prostředkům Azure chráněným službou Azure Active Directory (Azure AD), a ne k přihlašovacím údajům, tajným klíčům nebo Azure AD tokenům. Azure spravuje tuto identitu 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 Azure AD tokeny. Přečtěte si další informace o službách Azure, které podporují spravované identity pro ověřování Azure AD.

  • Typ prostředku Aplikace logiky (Consumption) může používat identitu přiřazenou systémem nebo jednu ručně vytvořenou identitu přiřazenou uživatelem.

  • Typ prostředku Aplikace logiky (Standard) podporuje, aby byla současně povolena spravovaná identita přiřazená systémem a několik spravovaných identit přiřazených uživatelem , i když můžete kdykoli vybrat jenom jednu identitu.

    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 ověřovacích přihlašovacích údajů nebo připojovacího řetězce, které používáte při vytváření připojení. Pokud tuto identitu zakážete, nebudou připojení za běhu fungovat. Toto nastavení zobrazíte tak, že v nabídce aplikace logiky v části Nastavení vyberete Identita.

  1. Než vaše aplikace logiky může 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. Tento postup povolí spravovanou identitu v aplikaci logiky a nastaví přístup této identity k cílovému prostředku Azure.

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

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

    Předdefinované triggery a akce

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

    Nastaví například https://storage.azure.com/přístupové tokeny pro ověřování jako 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 Audience (Cílová skupina ) může být v některých triggerech nebo akcích skrytá. Pokud chcete tuto vlastnost zviditelnit, otevřete v triggeru nebo akci seznam Přidat nový parametr a vyberte Cílovou skupinu.

    Důležité: Ujistěte se, že toto ID cílového prostředku přesně odpovídá hodnotě, kterou Azure AD 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. ID prostředku pro konkrétní účet úložiště ale nevyžaduje koncové lomítko. Pokud chcete tato ID prostředků najít, projděte si služby Azure, které podporují Azure AD.

    Pokud používáte zabezpečené parametry ke zpracování a zabezpečení citlivých informací, například v šabloně Azure Resource Manager pro automatizaci nasazení, můžete k těmto hodnotám parametrů za běhu přistupovat pomocí výrazů. 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ář) Vyžadováno Hodnota Popis
    Název připojení Yes <connection-name>
    Spravovaná identita Yes Spravovaná identita přiřazená systémem
    nebo
    <user-assigned-managed-identity-name>    		 Typ ověřování, který se má použít

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

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

Doprovodné materiály k izolaci aplikací logiky

Azure Logic Apps můžete použít v Azure Government podpory všech úrovní dopadu v oblastech popsaných v pokynech k izolaci Azure Government Impact Level 5. Pro splnění těchto požadavků azure Logic Apps podporuje možnost vytvářet a spouštět pracovní postupy v prostředí s vyhrazenými prostředky, abyste mohli snížit dopad ostatních tenantů Azure na výkon vašich aplikací logiky a vyhnout se sdílení výpočetních prostředků s jinými tenanty.

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

Další kroky