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

Azure Logic Apps spoléhá na Azure Storage ukládání a automatické šifrování dat v klidových uloženích. Toto šifrování chrání vaše data a pomáhá splnit závazky organizace týkající se zabezpečení a dodržování předpisů. Ve výchozím nastavení Azure Storage data šifruje pomocí klíčů spravovaných Microsoftem. Další informace najdete v tématu Azure Storage šifrování pro data v klidových stavu.

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

• Přístup k příchozím voláním triggerů na základě požadavků
• Přístup k operacím aplikace logiky
• Přístup ke vstupům a výstupům historie spuštění
• Přístup ke vstupům parametrů
• Přístup pro odchozí volání do jiných služeb a systémů
• Blokování vytváření připojení pro konkrétní konektory
• Pokyny k izolaci pro aplikace logiky
• Standardní hodnoty zabezpečení Azure pro Azure Logic Apps

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

• Přehled šifrování v Azure
• Šifrování dat v klidových zařízeních Azure
• Srovnávací test zabezpečení Azure

Přístup k příchozím voláním triggerů na základě požadavků

Příchozí volání, která aplikace logiky přijímá prostřednictvím triggeru založeného na žádostech, 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é jako SSL (Secure Sockets Layer) (SSL). 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 dojde k chybám 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

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

• Generování sdílených přístupových podpisů (SAS)
• Povolení Azure Active Directory ověřování (Azure AD OAuth)
• Vystavení aplikace logiky pomocí Azure API Management
• Omezení příchozích IP adres

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á tento formát:

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

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

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

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

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

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

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

1. V Azure Portalotevř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í, u které vyprší platnost

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

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

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

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

Při generování nebo zobrazení seznamu adres URL zpětného volání pro trigger založený na žádostech můžete zadat klíč, který se má použít k podepsání adresy URL. Pokud chcete vygenerovat adresu URL, která je podepsaná konkrétním klíčem, použijte Logic Apps REST API, například:

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

Do těla zahrnte KeyType vlastnost jako nebo Primary Secondary . Tato vlastnost vrátí adresu URL, která je podepsaná zadaným klíčem zabezpečení.

Povolení Azure Active Directory ověřování (Azure AD OAuth)

U příchozích volání do koncového bodu vytvořeného triggerem založeným na žádostech můžete povolit Azure AD OAuth definováním nebo přidáním zásad autorizace pro aplikaci 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 identity určenými jednotlivými zásadami autorizace. Pokud mezi deklaracemi identity tokenu a všemi deklaracemi identity v alespoň jedné zásadách existuje shoda, autorizace příchozího požadavku bude úspěšná. Token může mít více deklarací identity, než je číslo zadané zásadou autorizace.

Důležité informace před povolením azure AD OAuth

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

• Přístupové tokeny Azure AD OAuth podporují pouze schémata autorizace typu Bearer, což znamená, že hlavička přístupového tokenu musí Authorization určit Bearer typ.

• 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í zahrnovat aspoň deklaraci identity vystavitele , která má hodnotu začínající buď https://sts.windows.net/ nebo 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. Tento vzorový oddíl pro dekódování přístupového tokenu obsahuje oba typy deklarací, kde aud je hodnota cílové skupiny a iss je hodnotou vystavitele :

  {
      "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í služby Azure AD OAuth pro vaši aplikaci logiky

Použijte následující postup pro Azure Portal nebo šablonu Azure Resource Manager:

"resources": [
   {
      // Start logic app resource definition
      "properties": {
         "state": "<Enabled-or-Disabled>",
         "definition": {<workflow-definition>},
         "parameters": {<workflow-definition-parameter-values>},
         "accessControl": {
            "triggers": {
               "openAuthenticationPolicies": {
                  "policies": {
                     "<policy-name>": {
                        "type": "AAD",
                        "claims": [
                           {
                              "name": "<claim-name>",
                              "value": "<claim-value>"
                           }
                        ]
                     }
                  }
               }
            },
         },
      },
      "name": "[parameters('LogicAppName')]",
      "type": "Microsoft.Logic/workflows",
      "location": "[parameters('LogicAppLocation')]",
      "apiVersion": "2016-06-01",
      "dependsOn": [
      ]
   }
   // End logic app resource definition
],

Zahrnout do výstupů triggerů žádosti hlavičku Authorization

pro logic apps, které umožňují Azure Active Directory Open authentication (Azure AD OAuth) pro autorizaci příchozích volání s přístupem k aktivačním událostem založeným na žádostech, můžete povolit aktivační události triggeru požadavku nebo aktivační události webhooku protokolu HTTP, které budou zahrnovat Authorization hlavičku 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 žádosti:

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

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

• Referenční dokumentace schématu pro aktivační události a typy akcí – Trigger žádosti
• Referenční dokumentace schématu pro typy triggerů a akcí – Trigger Webhooku protokolu HTTP
• Referenční dokumentace schématu pro triggery a typy akcí – možnosti operací

Vystavení aplikace logiky pomocí Azure API Management

Další protokoly a možnosti ověřování můžete vystavit zveřejnění aplikace logiky jako rozhraní API pomocí služby Azure API Management. Tato služba poskytuje bohatě kvalitní možnosti monitorování, zabezpečení, zásad a dokumentace pro libovolný koncový bod. API Management může vystavit veřejný nebo privátní koncový bod pro vaši aplikaci logiky. pokud chcete autorizovat přístup k tomuto koncovému bodu, můžete použít Azure Active Directory otevřít ověřování (Azure AD OAuth), klientský certifikát nebo jiné standardy zabezpečení. Když API Management obdrží požadavek, služba pošle požadavek do vaší aplikace logiky a provede všechny potřebné transformace nebo omezení na cestě. Chcete-li povolit pouze API Management volání aplikace logiky, můžete omezit příchozí IP adresy vaší aplikace logiky.

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

• Informace o službě API Management
• Ochrana back-endu webového rozhraní API v Azure API Management pomocí autorizace OAuth 2,0 s Azure AD
• Zabezpečte rozhraní API pomocí ověřování klientského certifikátu v API Management
• Zásady ověřování ve službě API Management

Omezit příchozí IP adresy

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

Bez ohledu na IP adresy, které zadáte, můžete pořád spustit aplikaci logiky, která má aktivační událost na základě požadavků, a to pomocí Logic Apps REST API: triggery pracovního postupu – spustit požadavek nebo pomocí API Management. Tento scénář ale pořád vyžaduje ověřování proti REST API Azure. Všechny události se zobrazí v protokolu auditu Azure. Ujistěte se, že jste nastavili zásady řízení přístupu odpovídajícím způsobem.

Pokud chcete omezit příchozí IP adresy pro vaši aplikaci logiky, použijte následující postup pro Azure Portal nebo šablonu Azure Resource Manager:

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

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

Přístup k operacím aplikace logiky

Můžete povolit spouštění konkrétních úloh jenom konkrétním uživatelům nebo skupinám, jako je správa, úpravy a zobrazení aplikací logiky. K řízení jejich oprávnění použijte řízení přístupu na základě role v Azure (Azure RBAC). Předdefinované nebo přizpůsobené role můžete přiřadit členům, kteří mají přístup k vašemu předplatnému Azure. Azure Logic Apps má tyto konkrétní 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, povolovat a zakažovat 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 nebo sdílet galerie i image.

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

Pokud chcete ostatním zabránit ve změně nebo odstranění vaší aplikace logiky, můžete použít Azure Resource Lock. 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 části Konfigurace připojení v nástroji Azure Logic Apps 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 šifrují během přenosu pomocí protokolu TLS (Transport Layer Security) a v klidových přenosech. Po dokončení běhu aplikace logiky můžete zobrazit historii tohoto spuštění, včetně kroků, které se spouštěly, spolu se stavem, dobou trvání, vstupy a výstupy pro každou akci. 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, které vzniknou.

Když zobrazíte historii spuštění aplikace logiky, 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é zachytává 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 použije při ověřování akce HTTP, chcete tento tajný kód skrýt ze zobrazení.

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

• Omezte přístup podle rozsahu IP adres.

  Tato možnost pomáhá zabezpečit přístup k historii spuštění na základě požadavků z konkrétního rozsahu IP adres.

• Zabezpečte data v historii spuštění pomocí obfuskace.

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

Omezení přístupu podle rozsahu IP adres

Můžete omezit přístup ke vstupům a výstupům v historii spuštění aplikace logiky, aby tato data mohli zobrazit pouze požadavky z konkrétních rozsahů IP adres.

Pokud například chcete komukoli zablokovat přístup ke vstupům a výstupům, zadejte rozsah IP adres, například 0.0.0.0-0.0.0.0 . Toto omezení může odebrat jenom osoba s oprávněním správce, což umožňuje přístup k datům aplikace logiky "za běhu".

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

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

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

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

Než tato nastavení začnete používat k zabezpečení těchto dat, projděte si tyto aspekty:

• Když u triggeru nebo akce zakryjte vstupy nebo výstupy, Logic Apps neposílá zabezpečená data do Azure Log Analytics. Do tohoto triggeru nebo akce pro monitorování také nemůžete přidat sledované vlastnosti.

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

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

• Nezapomeňte zapnout zabezpečené vstupy nebo zabezpečené výstupy v akcích podřízeného serveru, u kterých očekáváte, že historie spuštění tato data zakrysne.

  Nastavení Zabezpečené výstupy

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

  

  Akce Psaní, Parsování JSON a Odpověď mají jenom nastavení Zabezpečené vstupy. Když je toto nastavení zapnuté, skryje také výstupy těchto akcí. Pokud tyto akce explicitně používají výstupy zabezpečené protisoudku jako vstupy, Logic Apps skryje vstupy a výstupy těchto akcí, ale nepomáhou nastavení zabezpečených vstupů těchto akcí. Pokud akce podřízeného serveru explicitně používá skryté výstupy z akcí Compose, Parse JSON nebo Response jako vstupy, Logic Apps neskryje vstupy nebo výstupy podřízené akce.

  

  Nastavení Zabezpečené vstupy

  Když v triggeru nebo akci ručně zapnete zabezpečené vstupy, Logic Apps vstupy v historii spuštění skryje. Pokud akce podřízené akce explicitně používá viditelné výstupy z této aktivační události nebo akce jako vstupy, Logic Apps skryje vstupy této podřízené akce v historii spuštění, ale v této akci nepomáhou zabezpečené vstupy a neskrytí výstupů této akce.

  

  Pokud akce Psaní, Parsovat JSON a Odpověď explicitně používají viditelné výstupy z triggeru nebo akce se zabezpečenými vstupy, Logic Apps skryje vstupy a výstupy těchto akcí, ale nepomáhou nastavení zabezpečených vstupů pro tyto akce. Pokud akce podřízeného serveru explicitně používá skryté výstupy z akcí Compose, Parse JSON nebo Response jako vstupy, Logic Apps neskryje vstupy nebo výstupy podřízené akce.

  

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

1. V Azure Portalotevřete aplikaci logiky v Návrháři aplikace logiky.

   

2. U triggeru nebo akce, u které chcete zabezpečit citlivá data, vyberte tlačítko se třemi tečkami (...) a pak vyberte Nastavení.

   

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

   

   Akce nebo trigger teď v záhlaví zobrazuje ikonu zámku.

   

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

   

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 skrýt vstupy i výstupy, tyto hodnoty se teď zobrazí skryté.

      

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

V podkladové definici triggeru nebo akce přidejte nebo aktualizujte pole pomocí jedné nebo runtimeConfiguration.secureData.properties 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 napříč různými prostředími, zvažte parametrizaci hodnot v definici pracovního postupu, které se liší v závislosti na těchto prostředích. Díky tomu se můžete vyhnout pevný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 těchto 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 AD OAuth), můžete definovat Azure Active Directory zakrytí parametrů, které přijímají ID klienta Azure Active Directory tajný kód klienta, které se používají k ověřování. Pokud chcete definovat tyto parametry v aplikaci logiky, použijte část v definici pracovního postupu vaší aplikace logiky a Resource Manager parameters šablony 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í typu nebo a podle potřeby použijte securestring secureobject kódování. Parametry, které mají tento typ, se nevrátily 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 je popsán jazykem definice pracovního postupu.

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

• Zabezpečené parametry v definicích pracovních postupů
• Zabezpečení dat v historii spuštění pomocí obfuskace

Pokud automatizujete nasazení pro aplikacelogiky pomocí Resource Manager šablon , můžete definovat zabezpečené parametry šablony ,které se vyhodnocují při nasazení, pomocí typů securestring a secureobject . Pokud chcete definovat parametry šablony, použijte oddíl nejvyšší úrovně šablony, který je oddělený a liší se od oddílu parameters definice pracovního parameters 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 nasazení. Pak můžete odkazovat na trezor klíčů a tajný kód v souboru parametrů. Další informace najdete v těchto tématech:

• Předání citlivých hodnot při nasazení pomocí Azure Key Vault
• Zabezpečené parametry v Azure Resource Manager šablony dále v tomto tématu

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 se po uložení aplikace logiky nezviditelněny. Předpokládejme například, že máte akci HTTP, která vyžaduje základní ověřování, které používá uživatelské jméno a heslo. V definici pracovního postupu oddíl definuje parametry a parameters basicAuthPasswordParam pomocí typu basicAuthUsernameParam securestring . Definice akce pak odkazuje na tyto parametry v authentication oddílu .

"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 Azure Resource Manager šablonách

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

Tady jsou další informace o těchto parameters částech:

• Na nejvyšší úrovni šablony oddíl definuje parametry pro parameters hodnoty, které šablona používá při nasazení. Tyto hodnoty mohou 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 jejich změnu.

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

• Oddíl uvnitř definice pracovního postupu definuje parametry, které vaše aplikace parameters 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 příkladová šablona, která obsahuje několik definic zabezpečených parametrů, které používají securestring typ :

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

Přístup pro odchozí volání do jiných služeb a systémů

Na základě schopnosti cílového koncového bodu odchozí volání odesílaná triggerem HTTP nebo akcí HTTPpodporují šifrování a jsou zabezpečena pomocí protokolu TLS (Transport Layer Security) 1.0, 1.1 nebo 1.2,dříve označované jako SSL (Secure Sockets Layer) (SSL). Logic Apps s cílovým koncovým bodem přes nejvyšší možnou podporovanou verzi. Pokud například cílový koncový bod podporuje 1.2, trigger HTTP nebo akce nejprve použije 1.2. Jinak konektor používá další nejvyšší podporovanou verzi.

Tady jsou informace o certifikátech tls/SSL podepsaných svým držitelem:

• U aplikací logiky v globálním prostředí s více tenanty Azure Logic Apps operace HTTP nepovolují certifikáty TLS/SSL podepsané svým držitelem. Pokud vaše aplikace logiky provede volání HTTP na server a zobrazí certifikát podepsaný svým držitelem TLS/SSL, volání HTTP selže s TrustFailure chybou.

• Pro aplikace logiky v prostředí s jedním tenantem Azure Logic Apps operace HTTP podporují certifikáty TLS/SSL podepsané svým držitelem. Pro tento typ ověřování ale musíte provést několik kroků navíc. Jinak se volání nezdaří. Další informace najdete v článku Ověřování certifikátem TSL/SSL proověřování s jedním tenantem Azure Logic Apps .

  Pokud místo toho chcete použít klientský certifikát nebo Azure Active Directory ověřování (Azure AD OAuth) s typem přihlašovacích údajů Certifikát, stále musíte pro tento typ ověřování provést několik dalších kroků. Jinak se volání nezdaří. Další informace najdete v části Klientský certifikát nebo Azure Active Directory ověřování (Azure AD OAuth)s typem přihlašovacích údajů Certifikát pro jednotenentské Azure Logic Apps .

• Pro aplikace logiky v prostředí integrační služby (ISE)povoluje konektor HTTP certifikáty podepsané svým držitelem pro metody handshake TLS/SSL. Musíte však nejprve povolit podporu certifikátů podepsaných svým držitelem pro existující ise nebo nové ise pomocí Logic Apps REST API a nainstalovat veřejný certifikát v TrustedRoot umístění.

Tady jsou další způsoby, jak můžete zabezpečit koncové body, které budou zpracovávat volání odeslaná z 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 nebo akci HTTP, 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í:

  • Základní ověřování

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

  • Ověřování OAuth služby Active Directory

  • Ověřování spravovaných identit

• 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, které jsou založené na oblastech vašich aplikací logiky. Můžete přidat filtrování, které přijímá požadavky pouze z těchto IP adres. Informace o získání těchto IP adres najdete v tématu 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, aby byla zajištěná bezpečnější a spolehlivější místní komunikace.

  • Místní brána dat

    Mnoho spravovaných konektorů Azure Logic Apps podporuje 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 služby 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í prostřednictvím Azure API Management

    Azure API Management poskytuje možnosti místního připojení, jako je například virtuální privátní síť 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 vašemu místnímu systému, API Management jste ho odhalili vytvořením instance služby API Management,můžete toto rozhraní API volat v pracovním postupu aplikace logiky výběrem integrovaného triggeru nebo akce v Návrháři aplikací logiky.

    Poznámka

    Konektor zobrazuje jenom ty API Management, ve kterých máte oprávnění k zobrazení a připojení, ale nezminí se v nich API Management služby.

    1. V Návrháři pro Logic App 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 pracovního postupu, vyberte Zvolit trigger azure API Management trigger.

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

       Tento příklad přidá trigger:

       

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

       

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

       

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ů do těchto koncových bodů, můžete zadat typ ověřování. V Návrháři pro Logic App mají triggery a akce, které podporují výběr typu ověřování, vlastnost Ověřování. Tato vlastnost se ale nemusí vždy zobrazit ve výchozím nastavení. V těchto případech otevřete u triggeru nebo akce seznam Přidat nový parametr a vyberte Ověřování.

Typy ověřování pro triggery a akce, které podporují ověřování

Tato tabulka uvádí typy ověřování, které jsou k dispozici u triggerů, a akce, ve kterých můžete vybrat typ ověřování:

Základní ověřování

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

Pokud používáte zabezpečené parametry ke zpracování a zabezpečení citlivých informací, například v šabloně Azure Resource Managerpro automatizaci nasazení , můžete použít výrazy pro přístup k těmto hodnotám parametrů za běhu. Tato příklad definice akce HTTP určuje ověřování jako a používá funkci type Basic 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í:

Když použijete 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 pro přístup k těmto hodnotám parametrů za běhu. Tato ukázka 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": {}
}

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

• Vylepšení zabezpečení pro rozhraní API pomocí ověřování klientského certifikátu v Azure API Management
• Zvýšení zabezpečení pro back-endové služby pomocí ověřování klientského certifikátu v Azure API Management
• Zvýšení zabezpečení služby RESTfuL pomocí klientských certifikátů
• Přihlašovací údaje certifikátu pro ověřování aplikací
• Použití certifikátu TLS nebo SSL v kódu ve službě Azure App Service

Azure Active Directory Otevřít ověřování

na triggerech žádosti můžete pomocí Azure Active Directory otevřít ověřování (Azure AD OAuth)ověřit příchozí volání po nastavení zásad autorizace azure ad pro vaši aplikaci logiky. Pro všechny ostatní triggery a akce, které poskytují typ ověřování služby Active Directory OAuth pro výběr, zadejte tyto hodnoty vlastností:

Když použijete 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 pro přístup k těmto hodnotám parametrů za běhu. Tato ukázka definice akce HTTP Určuje ověřování type jako ActiveDirectoryOAuth , typ přihlašovacích údajů Secret a 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": {}
}

Nezpracované ověřování

Pokud je k dispozici možnost raw , můžete tento typ ověřování použít, když budete muset použít schémata ověřování , která nedodržují protokol OAuth 2,0. Pomocí tohoto typu ručně vytvoříte hodnotu hlavičky autorizace, kterou odešlete s odchozím požadavkem, a v aktivační události nebo akci zadejte tuto hodnotu záhlaví.

Tady je příklad hlavičky pro požadavek HTTPS, který následuje po protokolu 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 aktivační události nebo akci, která podporuje nezpracované ověřování, zadejte tyto hodnoty vlastností:

Když použijete 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 pro přístup k těmto hodnotám parametrů za běhu. Tato ukázka definice akce HTTP Určuje ověřování type jako Raw a 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á identita dostupná na triggeru nebo akci, která podporuje spravované ověřování identity, může vaše aplikace logiky použít tuto identitu k ověřování přístupu k prostředkům Azure, které jsou chráněné službou Azure Active Directory (azure ad), a ne s přihlašovacími údaji, tajné kódy nebo tokeny Azure AD. Azure tuto identitu spravuje za vás a pomáhá zabezpečit vaše přihlašovací údaje, protože nemusíte spravovat tajné klíče ani přímo používat tokeny Azure AD. 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 (spotřeba) 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) může používat pouze identitu přiřazenou systémem, která je automaticky povolená. Identita přiřazená uživatelem je momentálně nedostupná.

1. Než bude vaše aplikace logiky moci používat spravovanou identitu, postupujte podle kroků v části Ověření přístupu k prostředkům Azure pomocí spravovaných identit v Azure Logic Apps. Tento postup povolí spravovanou identitu ve vaší aplikaci logiky a nastaví přístup této identity k cílovému prostředku Azure.

2. Předtím, než funkce Azure functions může použít spravovanou identitu, nejprve povolte ověřování pro azure functions.

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

   Integrované triggery a akce

   Vlastnost (designer)	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	Yes	* Spravovaná identita přiřazená systémem nebo SystemAssigned * <user-assigned-identity-ID>	Spravovaná identita, která se má použít
   Cílová skupina	audience	Yes	<target-resource-ID>	ID prostředku pro cílový prostředek, ke skupině prostředků, ke které chcete získat přístup. Například vytvoří https://storage.azure.com/ 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: U některých triggerů nebo akcí může být vlastnost Cílová skupina skrytá. Pokud chcete tuto vlastnost zviditelnit, otevřete v triggeru nebo akci seznam Přidat nový parametr a vyberte Cílová skupina. 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ítk. PROTO ID https://storage.azure.com/ prostředku pro všechny účty Azure Blob Storage vyžaduje koncové lomítko. ID prostředku pro konkrétní účet úložiště ale nevyžaduje koncové lomítko. Informace o těchto ID prostředků najdete v tématu 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 Managerpro automatizaci nasazení , můžete použít výrazy pro přístup k těmto hodnotám parametrů za běhu. Například tato definice akce HTTP určuje ověřování jako a používá funkci type ManagedServiceIdentity parameters() k získání hodnot parametrů:

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

   Triggery a akce spravovaného konektoru

   Vlastnost (designer)	Vyžadováno	Hodnota	Popis
   Název připojení	Yes	<název připojení>
   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

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

Pokud vaše organizace neumožňuje připojení ke konkrétním prostředkům pomocí jejich konektorů v Azure Logic Apps, můžete zablokovat možnost vytvářet tato 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.

Pokyny k izolaci pro aplikace logiky

K podpoře Azure Logic Apps úrovní Azure Government v oblastech popsaných v doprovodných pokynech k izolaci úrovně Azure Government Impact Level 5můžete použít nástroj . Aby bylo možné tyto požadavky splnit, Logic Apps podporuje schopnost vytvářet a spouštět pracovní postupy v prostředí s vyhrazenými prostředky, abyste mohli snížit dopad jiných tenantů Azure na vaše aplikace logiky a vyhnout se tak sdílení výpočetních prostředků s jinými tenanty.

• Pokud chcete spustit vlastní kód nebo provést transformaci XML, vytvořte a zavolejte funkci Azurea nepoužívejte funkci v řádku kódu nebo poskytte sestavení, která se mají použít jako mapy (v uvedeném pořadí). Nastavte také hostitelské prostředí pro vaši aplikaci funkcí tak, aby splňovalo vaše požadavky na izolaci.

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

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

  • Azure App Service plány
  • Možnosti sítí Azure Functions
  • Vyhrazení hostitelé Azure pro virtuální počítače
  • Izolace virtuálních počítačů v Azure
  • Nasazení vyhrazených služeb Azure do virtuálních sítí

• V závislosti na tom, jestli používáte více tenantů nebo jedno tenantů Azure Logic Appsmáte tyto možnosti:

  • Pomocí aplikací logiky založených na jednom tenantovi můžete soukromě a bezpečně komunikovat mezi pracovními postupy aplikace logiky a virtuální sítí Azure nastavením privátních koncových bodů pro příchozí provoz a použitím integrace virtuální sítě pro odchozí provoz. Další informace najdete v přehledu Zabezpečení provozu mezi virtuálními sítěmi a jedno tenanty Azure Logic Apps privátními koncovými body.

  • Pomocí aplikací logiky založených na více tenantech můžete vytvářet a spouštět aplikace logiky v prostředí integrační služby (ISE). Aplikace logiky tak běží na vyhrazených zdrojích a mají přístup k prostředkům chráněným virtuální sítí Azure. Pokud chcete mít větší kontrolu nad šifrovacími klíči používanými Azure Storage, můžete nastavit, používat a spravovat vlastní klíč pomocí Azure Key Vault. Tato funkce se také označuje jako Bring Your Own Key (BYOK) a váš klíč se nazývá klíč spravovaný zákazníkem. Další informace najdete v části Nastavení klíčů spravovaných zákazníkem pro šifrování dat v klidových stavu pro prostředí integrační služby (ISE) v Azure Logic Apps.

  Důležité

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

  Pokud vaše pracovní postupy potřebují přístup k virtuálním sítím, které používají privátní koncové body, a chcete tyto pracovní postupy vyvíjet pomocí typu prostředku Aplikace logiky (Consumption), musíte aplikace logiky vytvořit a spustit v prostředí ISE. Pokud ale chcete tyto pracovní postupy vyvíjet pomocí typu prostředku Aplikace logiky (Standard), nepotřebujete ISE. Pracovní postupy mohou komunikovat soukromě a bezpečně s virtuálními sítěmi pomocí privátních koncových bodů pro příchozí provoz a integrace virtuální sítě pro odchozí provoz. Další informace najdete v přehledu Zabezpečení provozu mezi virtuálními sítěmi a jedno tenanty Azure Logic Apps privátními koncovými body.

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

• Izolace ve veřejném cloudu Azure
• Zabezpečení vysoce citlivých aplikací IaaS v Azure

Další kroky

• Standardní hodnoty zabezpečení Azure pro Azure Logic Apps
• Automatizace nasazení pro Azure Logic Apps
• Monitorování aplikací logiky