Beveiligde toegang en gegevens in Azure Logic AppsSecure access and data in Azure Logic Apps

Voor het beheren van de toegang tot en het beveiligen van gevoelige gegevens in Azure Logic Apps, kunt u de beveiliging instellen voor de volgende gebieden:To control access and protect sensitive data in Azure Logic Apps, you can set up security for these areas:

Toegang tot activeringen op basis van een aanvraagAccess to request-based triggers

Als uw logische app gebruikmaakt van een trigger op basis van een aanvraag, die inkomende aanroepen of aanvragen ontvangt, zoals de trigger van de aanvraag of de webhook , kunt u de toegang beperken zodat alleen geautoriseerde clients uw logische app kunnen aanroepen.If your logic app uses a request-based trigger, which receives incoming calls or requests, such as the Request or Webhook trigger, you can limit access so that only authorized clients can call your logic app. Alle aanvragen die door een logische app worden ontvangen, zijn versleuteld en beveiligd met het Transport Layer Security TLS-protocol (voorheen bekend als Secure Sockets Layer (SSL).All requests received by a logic app are encrypted and secured with Transport Layer Security (TLS) protocol, previously known as Secure Sockets Layer (SSL).

Hier vindt u opties die u kunnen helpen bij het beveiligen van de toegang tot dit trigger type:Here are options that can help you secure access to this trigger type:

Hand tekeningen voor gedeelde toegang (SAS) genererenGenerate shared access signatures (SAS)

Elk aanvraag eindpunt op een logische app heeft een Shared Access Signature (SAS) in de URL van het eind punt, die de volgende indeling heeft:Every request endpoint on a logic app has a Shared Access Signature (SAS) in the endpoint's URL, which follows this format:

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

Elke URL bevat de sp sv para meter,, en sig query zoals beschreven in deze tabel:Each URL contains the sp, sv, and sig query parameter as described in this table:

Query parameterQuery parameter BeschrijvingDescription
sp Hiermee geeft u de machtigingen op voor het gebruik van de toegestane HTTP-methoden.Specifies permissions for the permitted HTTP methods to use.
sv Hiermee geeft u de SAS-versie op die moet worden gebruikt voor het genereren van de hand tekening.Specifies the SAS version to use for generating the signature.
sig Hiermee geeft u de hand tekening op die moet worden gebruikt voor het verifiëren van de toegang tot de trigger.Specifies the signature to use for authenticating access to the trigger. Deze hand tekening wordt gegenereerd met behulp van de SHA256-algoritme met een geheime toegangs sleutel voor alle URL-paden en eigenschappen.This signature is generated by using the SHA256 algorithm with a secret access key on all the URL paths and properties. Nooit beschikbaar of gepubliceerd, deze sleutel wordt versleuteld bewaard en opgeslagen met de logische app.Never exposed or published, this key is kept encrypted and stored with the logic app. Uw logische app machtigt alleen de triggers die een geldige hand tekening bevatten die is gemaakt met de geheime sleutel.Your logic app authorizes only those triggers that contain a valid signature created with the secret key.

Zie de volgende secties in dit onderwerp voor meer informatie over het beveiligen van de toegang met SAS:For more information about securing access with SAS, see these sections in this topic:

Toegangssleutels regenererenRegenerate access keys

Als u op elk gewenst moment een nieuwe beveiligings toegangs sleutel wilt genereren, gebruikt u de Azure REST API of Azure Portal.To generate a new security access key at any time, use the Azure REST API or Azure portal. Alle eerder gegenereerde Url's die gebruikmaken van de oude sleutel, zijn ongeldig en hebben geen autorisatie meer om de logische app te activeren.All previously generated URLs that use the old key are invalidated and no longer have authorization to trigger the logic app. De Url's die u na het opnieuw genereren hebt opgehaald, worden ondertekend met de nieuwe toegangs sleutel.The URLs that you retrieve after regeneration are signed with the new access key.

  1. Open in de Azure Portalde logische app met de sleutel die u opnieuw wilt genereren.In the Azure portal, open the logic app that has the key you want to regenerate.

  2. Selecteer toegangs sleutelsonder instellingenin het menu van de logische app.On the logic app's menu, under Settings, select Access Keys.

  3. Selecteer de sleutel die u opnieuw wilt genereren en voltooi het proces.Select the key that you want to regenerate and finish the process.

Url's voor verlopende call back makenCreate expiring callback URLs

Als u de eind punt-URL voor een op aanvragen gebaseerde trigger met andere partijen deelt, kunt u Url's voor terugbellen genereren die specifieke sleutels gebruiken en verloop datums hebben.If you share the endpoint URL for a request-based trigger with other parties, you can generate callback URLs that use specific keys and have expiration dates. Op die manier kunt u sleutels naadloos draaien of de toegang beperken tot het activeren van uw logische app op basis van een specifieke tijds duur.That way, you can seamlessly roll keys or restrict access to triggering your logic app based on a specific timespan. Als u een verval datum voor een URL wilt opgeven, gebruikt u de Logic Apps rest API, bijvoorbeeld:To specify an expiration date for a URL, use the Logic Apps REST API, for example:

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

Neem in de hoofd tekst de NotAfter eigenschap op met behulp van een JSON-datum teken reeks.In the body, include the NotAfterproperty by using a JSON date string. Deze eigenschap retourneert een call back-URL die alleen geldig is voor de NotAfter datum en tijd.This property returns a callback URL that's valid only until the NotAfter date and time.

Url's met een primaire of secundaire sleutel makenCreate URLs with primary or secondary secret key

Wanneer u call back-Url's voor een op aanvragen gebaseerde trigger genereert of lijsteert, kunt u de sleutel opgeven die moet worden gebruikt voor het ondertekenen van de URL.When you generate or list callback URLs for a request-based trigger, you can specify the key to use for signing the URL. Als u een URL wilt genereren die is ondertekend met een specifieke sleutel, gebruikt u de Logic Apps rest API, bijvoorbeeld:To generate a URL that's signed by a specific key, use the Logic Apps REST API, for example:

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

In de hoofd tekst, neemt KeyType u de eigenschap op als Primary of Secondary .In the body, include the KeyType property as either Primary or Secondary. Deze eigenschap retourneert een URL die is ondertekend door de opgegeven beveiligings sleutel.This property returns a URL that's signed by the specified security key.

Azure Active Directory OAuth inschakelenEnable Azure Active Directory OAuth

Als uw logische app begint met een trigger voor aanvragen, kunt u Azure Active Directory open-verificatie (Azure AD OAuth) inschakelen door een autorisatie beleid voor binnenkomende oproepen naar de aanvraag trigger te maken.If your logic app starts with a Request trigger, you can enable Azure Active Directory Open Authentication (Azure AD OAuth) by creating an authorization policy for inbound calls to the Request trigger. Lees de volgende overwegingen voordat u deze verificatie inschakelt:Before you enable this authentication, review these considerations:

  • Een inkomende oproep naar uw logische app kan slechts één autorisatie schema, ofwel Azure AD OAuth of Shared Access signatures (SAS), gebruiken.An inbound call to your logic app can use only one authorization scheme, either Azure AD OAuth or Shared Access Signatures (SAS). Alleen autorisatie schema's van Bearer-type worden ondersteund voor OAuth-tokens, die alleen voor de aanvraag trigger worden ondersteund.Only Bearer-type authorization schemes are supported for OAuth tokens, which are supported only for the Request trigger.

  • Uw logische app is beperkt tot een maximum aantal autorisatie beleidsregels.Your logic app is limited to a maximum number of authorization policies. Elk autorisatie beleid heeft ook een maximum aantal claims.Each authorization policy also has a maximum number of claims. Zie limieten en configuratie voor Azure Logic appsvoor meer informatie.For more information, see Limits and configuration for Azure Logic Apps.

  • Een autorisatie beleid moet ten minste de Issuer claim bevatten, die een waarde heeft die begint met https://sts.windows.net/ of https://login.microsoftonline.com/ (OAuth v2) als de id van de uitgever van Azure AD.An authorization policy must include at least the Issuer claim, which has a value that starts with https://sts.windows.net/ or https://login.microsoftonline.com/ (OAuth V2) as the Azure AD issuer ID. Zie toegangs tokens voor micro soft Identity platformvoor meer informatie over toegangs tokens.For more information about access tokens, see Microsoft identity platform access tokens.

Als u Azure AD OAuth wilt inschakelen, volgt u deze stappen om een of meer autorisatie beleid toe te voegen aan uw logische app.To enable Azure AD OAuth, follow these steps to add one or more authorization policies to your logic app.

  1. Zoek en open uw logische app in het Azure Portalin de ontwerp functie voor logische apps.In the Azure portal, find and open your logic app in the Logic App Designer.

  2. Selecteer in het menu van de logische app onder instellingende optie autorisatie.On the logic app menu, under Settings, select Authorization. Nadat het autorisatie venster is geopend, selecteert u beleid toevoegen.After the Authorization pane opens, select Add policy.

    Selecteer autorisatie > beleid toevoegen

  3. Geef informatie op over het autorisatie beleid door de claim typen en waarden op te geven die uw logische app verwacht in het verificatie token dat wordt gepresenteerd door elke binnenkomende aanroep naar de aanvraag trigger:Provide information about the authorization policy by specifying the claim types and values that your logic app expects in the authentication token presented by each inbound call to the Request trigger:

    Informatie opgeven voor autorisatie beleid

    EigenschapProperty VereistRequired BeschrijvingDescription
    Beleids naamPolicy name YesYes De naam die u wilt gebruiken voor het autorisatie beleidThe name that you want to use for the authorization policy
    ClaimsClaims YesYes De claim typen en-waarden die uw logische app accepteert van binnenkomende oproepen.The claim types and values that your logic app accepts from inbound calls. Dit zijn de beschik bare claim typen:Here are the available claim types:

    - Verlener- Issuer
    - Gericht- Audience
    - Onderwerp- Subject
    - JWT-id (JSON Web token-id)- JWT ID (JSON Web Token ID)

    De claim lijst moet mini maal de claim van de verlener bevatten, die een waarde heeft die begint met de https://sts.windows.net/ of https://login.microsoftonline.com/ als de id van de Azure AD-Uitgever.At the minimum, the Claims list must include the Issuer claim, which has a value that starts with the https://sts.windows.net/ or https://login.microsoftonline.com/ as the Azure AD issuer ID. Zie claims in azure AD-beveiligings tokensvoor meer informatie over deze claim typen.For more information about these claim types, see Claims in Azure AD security tokens. U kunt ook uw eigen claim type en-waarde opgeven.You can also specify your own claim type and value.

  4. Selecteer een van de volgende opties om een claim toe te voegen:To add another claim, select from these options:

    • Als u een ander claim type wilt toevoegen, selecteert u standaard claim toevoegen, selecteert u het claim type en geeft u de claim waarde op.To add another claim type, select Add standard claim, select the claim type, and specify the claim value.

    • Als u uw eigen claim wilt toevoegen, selecteert u aangepaste claim toevoegenen geeft u de aangepaste claim waarde op.To add your own claim, select Add custom claim, and specify the custom claim value.

  5. Selecteer beleid toevoegenom een ander autorisatie beleid toe te voegen.To add another authorization policy, select Add policy. Herhaal de vorige stappen om het beleid in te stellen.Repeat the previous steps to set up the policy.

  6. Selecteer Opslaan als u klaar bent.When you're done, select Save.

Uw logische app is nu ingesteld voor het gebruik van Azure AD OAuth voor het machtigen van inkomende aanvragen.Your logic app is now set up to use Azure AD OAuth for authorizing inbound requests. Wanneer uw logische app een binnenkomende aanvraag met een verificatie token ontvangt, vergelijkt Azure Logic Apps de claims van het token met de claims in elk autorisatie beleid.When your logic app receives an inbound request that includes an authentication token, Azure Logic Apps compares the token's claims against the claims in each authorization policy. Als er een overeenkomst is tussen de claims van het token en alle claims in ten minste één beleid, is de autorisatie geslaagd voor de inkomende aanvraag.If a match exists between the token's claims and all the claims in at least one policy, authorization succeeds for the inbound request. Het token kan meer claims hebben dan het aantal dat is opgegeven door het autorisatie beleid.The token can have more claims than the number specified by the authorization policy.

Stel bijvoorbeeld dat uw logische app een autorisatie beleid heeft dat twee claim typen vereist, verlener en publiek.For example, suppose that your logic app has an authorization policy that requires two claim types, Issuer and Audience. Dit voor beeld van een gedecodeerd toegangs token bevat beide claim typen:This sample decoded access token includes both those claim types:

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

Inkomende IP-adressen beperkenRestrict inbound IP addresses

Samen met Shared Access Signature (SAS) kunt u de clients die uw logische app kunnen aanroepen, het beste beperken.Along with Shared Access Signature (SAS), you might want to specifically limit the clients that can call your logic app. Als u bijvoorbeeld het eind punt van de aanvraag beheert met behulp van Azure API Management, kunt u de logische app beperken tot het accepteren van aanvragen van het IP-adres voor het API Management exemplaar.For example, if you manage your request endpoint by using Azure API Management, you can restrict your logic app to accept requests only from the IP address for the API Management instance.

Binnenkomende IP-bereiken in Azure Portal beperkenRestrict inbound IP ranges in Azure portal

  1. Open in de Azure Portaluw logische app in de ontwerp functie voor logische apps.In the Azure portal, open your logic app in the Logic App Designer.

  2. Selecteer werk stroom instellingenonder instellingenin het menu van de logische app.On your logic app's menu, under Settings, select Workflow settings.

  3. Access control configuration > Selecteer specifieke IP-bereikenonder toegangs beheer configuratietoegestane binnenkomende IP-adressen.Under Access control configuration > Allowed inbound IP addresses, select Specific IP ranges.

  4. Geef onder IP-bereiken voor triggersde IP-adresbereiken op die de trigger accepteert.Under IP ranges for triggers, specify the IP address ranges that the trigger accepts.

    Een geldig IP-bereik maakt gebruik van de volgende indelingen: x. x. x. x/x of x. x. x. x-x. x. x. xA valid IP range uses these formats: x.x.x.x/x or x.x.x.x-x.x.x.x

Als u wilt dat uw logische app alleen als een geneste logische app wordt geactiveerd, selecteert u alleen andere Logic appsin de lijst toegestane binnenkomende IP-adressen .If you want your logic app to trigger only as a nested logic app, from the Allowed inbound IP addresses list, select Only other Logic Apps. Met deze optie wordt een lege matrix naar de logische app-resource geschreven.This option writes an empty array to your logic app resource. Op die manier kunnen alleen aanroepen van de Logic Apps-service (bovenliggende Logic apps) de geneste logische app activeren.That way, only calls from the Logic Apps service (parent logic apps) can trigger the nested logic app.

Notitie

Ongeacht het IP-adres kunt u nog steeds een logische app met een op aanvragen gebaseerde trigger uitvoeren met behulp van /triggers/<trigger-name>/run de Azure-rest API of via API management.Regardless of IP address, you can still run a logic app that has a request-based trigger by using /triggers/<trigger-name>/run through the Azure REST API or through API Management. Voor dit scenario is echter nog steeds verificatie vereist voor de Azure-rest API.However, this scenario still requires authentication against the Azure REST API. Alle gebeurtenissen worden weer gegeven in het controle logboek van Azure.All events appear in the Azure Audit Log. Zorg ervoor dat u de beleids regels voor toegangs beheer dienovereenkomstig instelt.Make sure that you set access control policies accordingly.

Binnenkomende IP-bereiken in Azure Resource Manager sjabloon beperkenRestrict inbound IP ranges in Azure Resource Manager template

Als u de implementatie van Logic apps automatiseert met behulp van Resource Manager-sjablonen, kunt u de IP-adresbereiken in x. x. x. x/x -of x. x. x. x-x. x. x notatie gebruiken met behulp van de accessControl sectie en door de triggers actions secties en in de resource definitie van de logische app op te nemen, bijvoorbeeld:If you automate deployment for logic apps by using Resource Manager templates, you can specify the IP ranges in x.x.x.x/x or x.x.x.x-x.x.x.x format by using the accessControl section and by including the triggers and actions sections in your logic app's resource definition, for example:

{
   "$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:" : []
               }
            },
            "endpointsConfiguration": {}
         }
      }
   ],
   "outputs": {}
}

Azure Active Directory open-verificatie of andere beveiliging toevoegenAdd Azure Active Directory Open Authentication or other security

Als u meer verificatie protocollen wilt toevoegen aan uw logische app, kunt u overwegen de Azure API Management -service te gebruiken.To add more authentication protocols to your logic app, consider using the Azure API Management service. Deze service helpt u uw logische app beschikbaar te maken als een API en biedt uitgebreide bewaking, beveiliging, beleid en documentatie voor elk eind punt.This service helps you expose your logic app as an API and offers rich monitoring, security, policy, and documentation for any endpoint. API Management kunt een openbaar of persoonlijk eind punt beschikbaar maken voor uw logische app.API Management can expose a public or private endpoint for your logic app. Als u toegang tot dit eind punt wilt verlenen, kunt u Azure Active Directory open verificatie (Azure AD OAuth), client certificaatof andere beveiligings normen gebruiken om toegang tot het eind punt te verlenen.To authorize access to this endpoint, you can use Azure Active Directory Open Authentication (Azure AD OAuth), client certificate, or other security standards for authorizing access to that endpoint. Wanneer API Management een aanvraag ontvangt, stuurt de service de aanvraag naar uw logische app, worden ook de nodige trans formaties of beperkingen door lopen.When API Management receives a request, the service sends the request to your logic app, also making any necessary transformations or restrictions along the way. Als u uw logische app alleen API Management activeren, kunt u de instellingen voor het binnenkomende IP-adres bereik van uw logische app gebruiken.To let only API Management trigger your logic app, you can use your logic app's inbound IP range settings.

Toegang tot logische app-bewerkingenAccess to logic app operations

U kunt alleen specifieke gebruikers of groepen toestaan specifieke taken uit te voeren, zoals het beheren, bewerken en weer geven van logische apps.You can permit only specific users or groups to run specific tasks, such as managing, editing, and viewing logic apps. Als u de machtigingen wilt beheren, moet u gebruikmaken van Azure Role Access Control (RBAC) , zodat u aangepaste of ingebouwde rollen kunt toewijzen aan de leden van uw Azure-abonnement:To control their permissions, use Azure Role-Based Access Control (RBAC) so that you can assign customized or built-in roles to the members in your Azure subscription:

  • Inzender van Logicapps: Hiermee kunt u logische apps beheren, maar u kunt de toegang niet wijzigen.Logic App Contributor: Lets you manage logic apps, but you can't change access to them.

  • Logische app-operator: Hiermee kunt u logische apps lezen, inschakelen en uitschakelen, maar u kunt ze niet bewerken of bijwerken.Logic App Operator: Lets you read, enable, and disable logic apps, but you can't edit or update them.

U kunt Azure resource Lockgebruiken om te voor komen dat anderen uw logische app wijzigen of verwijderen.To prevent others from changing or deleting your logic app, you can use Azure Resource Lock. Deze mogelijkheid voor komt dat anderen productie resources wijzigen of verwijderen.This capability prevents others from changing or deleting production resources.

Toegang tot uitvoerings geschiedenis gegevensAccess to run history data

Tijdens de uitvoering van een logische app worden alle gegevens tijdens de overdracht versleuteld met behulp van Transport Layer Security (TLS) en in rust.During a logic app run, all the data is encrypted during transit by using Transport Layer Security (TLS) and at rest. Wanneer de logische app wordt uitgevoerd, kunt u de geschiedenis voor die uitvoering bekijken, met inbegrip van de stappen die samen met de status, duur, invoer en uitvoer voor elke actie worden uitgevoerd.When your logic app finishes running, you can view the history for that run, including the steps that ran along with the status, duration, inputs, and outputs for each action. Deze uitgebreide details bieden inzicht in hoe uw logische app wordt uitgevoerd en waar u kunt beginnen met het oplossen van problemen die zich voordoen.This rich detail provides insight into how your logic app ran and where you might start troubleshooting any problems that arise.

Wanneer u de uitvoerings geschiedenis van de logische app bekijkt, wordt uw toegang door Logic Apps geverifieerd en vindt u koppelingen naar de invoer en uitvoer voor de aanvragen en antwoorden voor elke uitvoering.When you view your logic app's run history, Logic Apps authenticates your access and then provides links to the inputs and outputs for the requests and responses for each run. Voor acties waarbij wacht woorden, geheimen, sleutels of andere gevoelige informatie worden verwerkt, wilt u echter voor komen dat anderen deze gegevens kunnen weer geven en gebruiken.However, for actions that handle any passwords, secrets, keys, or other sensitive information, you want to prevent others from viewing and accessing that data. Als uw logische app bijvoorbeeld een geheim krijgt van Azure Key Vault om te gebruiken bij het verifiëren van een http-actie, wilt u dat geheim verbergen in de weer gave.For example, if your logic app gets a secret from Azure Key Vault to use when authenticating an HTTP action, you want to hide that secret from view.

Als u de toegang tot de invoer en uitvoer in de uitvoerings geschiedenis van de logische app wilt beheren, hebt u de volgende opties:To control access to the inputs and outputs in your logic app's run history, you have these options:

Toegang beperken op basis van IP-adres bereikRestrict access by IP address range

U kunt de toegang tot de invoer en uitvoer in de uitvoerings geschiedenis van de logische app beperken zodat alleen aanvragen van specifieke IP-adresbereiken die gegevens kunnen weer geven.You can limit access to the inputs and outputs in your logic app's run history so that only requests from specific IP address ranges can view that data. Als u bijvoorbeeld wilt blok keren dat iedereen toegang heeft tot invoer en uitvoer, geeft u een IP-adres bereik op zoals 0.0.0.0-0.0.0.0 .For example, to block anyone from accessing inputs and outputs, specify an IP address range such as 0.0.0.0-0.0.0.0. Alleen gebruikers met beheerders machtigingen kunnen deze beperking verwijderen. Dit biedt de mogelijkheid om just-in-time toegang te krijgen tot de gegevens van uw logische app.Only a person with administrator permissions can remove this restriction, which provides the possibility for "just-in-time" access to your logic app's data. U kunt de IP-bereiken opgeven die u wilt beperken door gebruik te maken van de Azure Portal of in een Azure Resource Manager sjabloon die u gebruikt voor de implementatie van logische apps.You can specify the IP ranges to restrict either by using the Azure portal or in an Azure Resource Manager template that you use for logic app deployment.

IP-bereiken in Azure Portal beperkenRestrict IP ranges in Azure portal

  1. Open in de Azure Portal uw logische app in de ontwerp functie voor logische apps.In the Azure portal, open your logic app in the Logic App Designer.

  2. Selecteer werk stroom instellingenonder instellingenin het menu van de logische app.On your logic app's menu, under Settings, select Workflow settings.

  3. Access control configuration > Selecteer specifieke IP-bereikenonder toegangs beheer configuratietoegestane binnenkomende IP-adressen.Under Access control configuration > Allowed inbound IP addresses, select Specific IP ranges.

  4. Geef onder IP-adresbereiken voor inhoudde IP-adresbereiken op die toegang hebben tot inhoud van invoer en uitvoer.Under IP ranges for contents, specify the IP address ranges that can access content from inputs and outputs.

    Een geldig IP-bereik maakt gebruik van de volgende indelingen: x. x. x. x/x of x. x. x. x-x. x. x. xA valid IP range uses these formats: x.x.x.x/x or x.x.x.x-x.x.x.x

IP-bereiken in Azure Resource Manager sjabloon beperkenRestrict IP ranges in Azure Resource Manager template

Als u de implementatie van Logic apps automatiseert met behulp van Resource Manager-sjablonen, kunt u de IP-adresbereiken opgeven met behulp van de accessControl sectie in de contents resource definitie van de logische app, bijvoorbeeld:If you automate deployment for logic apps by using Resource Manager templates, you can specify the IP ranges by using the accessControl section with the contents section in your logic app's resource definition, for example:

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

Gegevens in de uitvoerings geschiedenis beveiligen met behulp van een afvallenSecure data in run history by using obfuscation

Veel triggers en acties hebben instellingen voor het beveiligen van invoer, uitvoer of beide vanuit de uitvoerings geschiedenis van een logische app.Many triggers and actions have settings to secure inputs, outputs, or both from a logic app's run history. Lees deze overwegingenvoordat u deze instellingen gebruikt voor het beveiligen van deze gegevens.Before using these settings to help you secure this data, review these considerations.

Invoer en uitvoer in de ontwerp functie beveiligenSecure inputs and outputs in the designer

  1. Open in de Azure Portaluw logische app in de ontwerp functie voor logische apps.In the Azure portal, open your logic app in the Logic App Designer.

    Logische app openen in de ontwerp functie voor logische apps

  2. Selecteer de knop met weglatings tekens (...) op de trigger of de actie waar u gevoelige gegevens wilt beveiligen en selecteer vervolgens instellingen.On the trigger or action where you want to secure sensitive data, select the ellipses (...) button, and then select Settings.

    Trigger-of actie-instellingen openen

  3. Schakel beveiligde invoer, beveiligde uitvoerof beide in.Turn on either Secure Inputs, Secure Outputs, or both. Wanneer u klaar bent, selecteert u Gereed.When you're finished, select Done.

    Schakel beveiligde invoer of beveiligde uitvoer in

    In de actie of de trigger wordt nu een vergrendelings pictogram weer gegeven in de titel balk.The action or trigger now shows a lock icon in the title bar.

    De titel balk van de actie of de trigger toont het vergrendelings pictogram

    Tokens die beveiligde uitvoer van vorige acties vertegenwoordigen, worden ook vergrendelings pictogrammen weer gegeven.Tokens that represent secured outputs from previous actions also show lock icons. Wanneer u bijvoorbeeld een dergelijke uitvoer van de lijst met dynamische inhoud selecteert die u wilt gebruiken in een actie, toont dat token een vergrendelings pictogram.For example, when you select such an output from the dynamic content list to use in an action, that token shows a lock icon.

    Token selecteren voor beveiligde uitvoer

  4. Wanneer de logische app wordt uitgevoerd, kunt u de geschiedenis voor die uitvoering weer geven.After the logic app runs, you can view the history for that run.

    1. Selecteer in het overzichts venster van de logische app de uitvoering die u wilt weer geven.On the logic app's Overview pane, select the run that you want to view.

    2. Vouw in het deel venster voor het uitvoeren van de logische app de acties uit die u wilt controleren.On the Logic app run pane, expand the actions that you want to review.

      Als u hebt gekozen voor het verbergen van beide invoer en uitvoer, worden deze waarden nu verborgen weer gegeven.If you chose to obscure both inputs and outputs, those values now appear hidden.

      Verborgen invoer en uitvoer in uitvoerings geschiedenis

Invoer en uitvoer in de code weergave beveiligenSecure inputs and outputs in code view

In de onderliggende trigger of actie definitie kunt u de matrix toevoegen of bijwerken runtimeConfiguration.secureData.properties met een van beide of beide van de volgende waarden:In the underlying trigger or action definition, add or update the runtimeConfiguration.secureData.properties array with either or both of these values:

  • "inputs": Beveiligt invoer in uitvoerings geschiedenis."inputs": Secures inputs in run history.
  • "outputs": Hiermee worden uitvoer in uitvoerings geschiedenis beveiligd."outputs": Secures outputs in run history.

Hier volgen enkele aandachtspunten om te controleren wanneer u deze instellingen gebruikt om u te helpen bij het beveiligen van deze gegevens.Here are some considerations to review when you use these settings to help you secure this data.

"<trigger-or-action-name>": {
   "type": "<trigger-or-action-type>",
   "inputs": {
      <trigger-or-action-inputs>
   },
   "runtimeConfiguration": {
      "secureData": {
         "properties": [
            "inputs",
            "outputs"
         ]
      }
   },
   <other-attributes>
}

Overwegingen bij het beveiligen van invoer en uitvoerConsiderations when securing inputs and outputs

  • Wanneer u de invoer of uitvoer van een trigger of actie verduidelijkt, worden Logic Apps de beveiligde gegevens niet naar Azure Log Analytics verzonden.When you obscure the inputs or outputs on a trigger or action, Logic Apps doesn't send the secured data to Azure Log Analytics. U kunt ook geen bijgehouden eigenschappen toevoegen aan deze trigger of actie voor bewaking.Also, you can't add tracked properties to that trigger or action for monitoring.

  • De Logic apps-API voor het verwerken van de werk stroom geschiedenis retourneert geen beveiligde uitvoer.The Logic Apps API for handling workflow history doesn't return secured outputs.

  • Als u uitvoer wilt beveiligen op basis van een actie die invoer verduidelijkt of als deze expliciet worden uitgevoerd, schakelt u de beveiligde uitvoer in die actie hand matig in.To secure outputs from an action that obscures inputs or explicitly obscures outputs, manually turn on Secure Outputs in that action.

  • Zorg ervoor dat u beveiligde invoer of beveiligde uitvoer inschakelt in downstream-acties waarbij u verwacht dat de uitvoerings geschiedenis deze gegevens verduidelijkt.Make sure that you turn on Secure Inputs or Secure Outputs in downstream actions where you expect the run history to obscure that data.

    Instelling voor beveiligde uitvoerSecure Outputs setting

    Wanneer u beveiligde uitvoer in een trigger of actie hand matig inschakelt, Logic apps deze uitvoer in de uitvoerings geschiedenis verbergen.When you manually turn on Secure Outputs in a trigger or action, Logic Apps hides these outputs in the run history. Als een stroomafwaartse actie deze beveiligde uitvoer expliciet gebruikt als invoer, Logic Apps de invoer van deze actie in de uitvoerings geschiedenis verbergen, maar wordt de instelling beveiligde invoer van de actie niet ingeschakeld .If a downstream action explicitly uses these secured outputs as inputs, Logic Apps hides this action's inputs in the run history, but doesn't enable the action's Secure Inputs setting.

    Beveiligde uitvoer als invoer en stroomafwaartse impact op de meeste acties

    De acties opstellen, parseren JSON en Response hebben alleen de instelling beveiligde invoer .The Compose, Parse JSON, and Response actions has only the Secure Inputs setting. Wanneer deze optie is ingeschakeld, worden de uitvoer van deze acties ook verborgen.When turned on, the setting also hides these actions' outputs. Als deze acties expliciet gebruikmaken van de upstream beveiligde uitvoer als invoer, worden de invoer en uitvoer van deze acties door Logic Apps verborgen, maar worden de instelling beveiligde invoer waarden niet ingeschakeld .If these actions explicitly use the upstream secured outputs as inputs, Logic Apps hides these actions' inputs and outputs, but doesn't enable these actions' Secure Inputs setting. Als een stroomafwaartse actie expliciet gebruikmaakt van de verborgen uitvoer van de acties opstellen, parseren van JSON of respons als invoer, Logic Apps de invoer of uitvoer van deze stroomafwaartse actie niet verbergen.If a downstream action explicitly uses the hidden outputs from the Compose, Parse JSON, or Response actions as inputs, Logic Apps doesn't hide this downstream action's inputs or outputs.

    Beveiligde uitvoer als invoer met downstream-impact op specifieke acties

    Instelling voor beveiligde invoerSecure Inputs setting

    Wanneer u beveiligde invoer in een trigger of actie hand matig inschakelt, Logic apps deze invoer in de uitvoerings geschiedenis verbergen.When you manually turn on Secure Inputs in a trigger or action, Logic Apps hides these inputs in the run history. Als een stroomafwaartse actie expliciet gebruikmaakt van de zicht bare uitvoer van die trigger of actie als invoer, Logic Apps de invoer van deze stroomafwaartse actie verbergen in de uitvoerings geschiedenis, maar worden geen beveiligde invoer in deze actie ingeschakeld en worden de uitvoer van deze actie niet verborgen.If a downstream action explicitly uses the visible outputs from that trigger or action as inputs, Logic Apps hides this downstream action's inputs in the run history, but doesn't enable Secure Inputs in this action and doesn't hide this action's outputs.

    Beveiligde invoer en downstream van invloed op de meeste acties

    Als de acties opstellen, parseren van JSON en respons expliciet gebruikmaken van de zicht bare uitvoer van de trigger of actie die de beveiligde invoer heeft, Logic Apps de invoer en uitvoer van deze acties verbergen, maar schakelt de instelling beveiligde invoer van deze actie niet in .If the Compose, Parse JSON, and Response actions explicitly use the visible outputs from the trigger or action that has the secured inputs, Logic Apps hides these actions' inputs and outputs, but doesn't enable these action's Secure Inputs setting. Als een stroomafwaartse actie expliciet gebruikmaakt van de verborgen uitvoer van de acties opstellen, parseren van JSON of respons als invoer, Logic Apps de invoer of uitvoer van deze stroomafwaartse actie niet verbergen.If a downstream action explicitly uses the hidden outputs from the Compose, Parse JSON, or Response actions as inputs, Logic Apps doesn't hide this downstream action's inputs or outputs.

    Beveiligde invoer en downstream-impact op specifieke acties

Toegang tot parameter invoerAccess to parameter inputs

Als u in verschillende omgevingen implementeert, kunt u de waarden in uw werk stroom definitie parameterizingen die variëren op basis van deze omgevingen.If you deploy across different environments, consider parameterizing the values in your workflow definition that vary based on those environments. Op die manier kunt u hardcoded gegevens voor komen door een Azure Resource Manager sjabloon te gebruiken om uw logische app te implementeren, gevoelige gegevens te beschermen door beveiligde para meters te definiëren en deze gegevens als afzonderlijke invoer door te geven via de para meters van de sjabloon met behulp van een parameter bestand.That way, you can avoid hard-coded data by using an Azure Resource Manager template to deploy your logic app, protect sensitive data by defining secured parameters, and pass that data as separate inputs through the template's parameters by using a parameter file.

Als u bijvoorbeeld HTTP-acties met Azure Active Directory open-verificatie (Azure AD OAuth) verifieert, kunt u de para meters die de client-id en het client geheim accepteren die worden gebruikt voor verificatie, definiëren en verbergen.For example, if you authenticate HTTP actions with Azure Active Directory Open Authentication (Azure AD OAuth), you can define and obscure the parameters that accept the client ID and client secret that are used for authentication. Als u deze para meters in uw logische app wilt definiëren, gebruikt u de parameters sectie in de werk stroom definitie van de logische app en de Resource Manager-sjabloon voor implementatie.To define these parameters in your logic app, use the parameters section in your logic app's workflow definition and Resource Manager template for deployment. Als u de parameter waarden die u niet wilt weer geven tijdens het bewerken van de logische app of de weer gave van de uitvoerings geschiedenis wilt helpen beveiligen, definieert u de para meters met behulp van de- securestring of- secureobject type en gebruikt u code ring.To help secure parameter values that you don't want shown when editing your logic app or viewing run history, define the parameters by using the securestring or secureobject type and use encoding as necessary. Para meters van dit type worden niet geretourneerd met de resource definitie en zijn niet toegankelijk wanneer de resource wordt weer gegeven na de implementatie.Parameters that have this type aren't returned with the resource definition and aren't accessible when viewing the resource after deployment. Als u tijdens runtime toegang wilt krijgen tot deze parameter waarden, gebruikt u de @parameters('<parameter-name>') expressie in de definitie van uw werk stroom.To access these parameter values during runtime, use the @parameters('<parameter-name>') expression inside your workflow definition. Deze expressie wordt alleen geëvalueerd tijdens runtime en wordt beschreven door de taal van de werk stroom definitie.This expression is evaluated only at runtime and is described by the Workflow Definition Language.

Notitie

Als u een para meter gebruikt in een aanvraag header of hoofd tekst, is die para meter mogelijk zichtbaar wanneer u de uitvoerings geschiedenis van de logische app en uitgaande HTTP-aanvraag weergeeft.If you use a parameter in a request header or body, that parameter might be visible when you view your logic app's run history and outgoing HTTP request. Zorg ervoor dat u ook uw beleids regels voor inhouds toegang dienovereenkomstig instelt.Make sure that you also set your content access policies accordingly. U kunt ook een afkorting gebruiken om invoer en uitvoer in de uitvoerings geschiedenis te verbergen.You can also use obfuscation to hide inputs and outputs in your run history. Autorisatie headers worden nooit weer gegeven via invoer of uitvoer.Authorization headers are never visible through inputs or outputs. Dus als er een geheim wordt gebruikt, kan dat geheim niet worden opgehaald.So if a secret is used there, that secret isn't retrievable.

Zie voor meer informatie deze secties in dit onderwerp:For more information, see these sections in this topic:

Als u de implementatie van Logic apps automatiseert met behulp van Resource Manager-sjablonen, kunt u de para metersvoor beveiligde sjablonen definiëren die tijdens de implementatie worden geëvalueerd met behulp van de-en- securestring secureobject typen.If you automate deployment for logic apps by using Resource Manager templates, you can define secured template parameters, which are evaluated at deployment, by using the securestring and secureobject types. Voor het definiëren van sjabloon parameters gebruikt u de sectie van het hoogste niveau van uw sjabloon parameters . deze is gescheiden en verschilt van de sectie van de werk stroom definitie parameters .To define template parameters, use your template's top level parameters section, which is separate and different from your workflow definition's parameters section. Als u de waarden voor sjabloon parameters wilt opgeven, gebruikt u een afzonderlijk parameter bestand.To provide the values for template parameters, use a separate parameter file.

Als u bijvoorbeeld geheimen gebruikt, kunt u de para meters voor beveiligde sjablonen definiëren en gebruiken om deze geheimen op te halen uit Azure Key Vault tijdens de implementatie.For example, if you use secrets, you can define and use secured template parameters that retrieve those secrets from Azure Key Vault at deployment. U kunt vervolgens naar de sleutel kluis en het geheim in het parameter bestand verwijzen.You can then reference the key vault and secret in your parameter file. Zie deze onderwerpen voor meer informatie:For more information, see these topics:

Veilige para meters in werk stroom definitiesSecure parameters in workflow definitions

Als u gevoelige informatie in de werk stroom definitie van de logische app wilt beveiligen, gebruikt u beveiligde para meters zodat deze informatie niet zichtbaar is nadat u uw logische app hebt opgeslagen.To protect sensitive information in your logic app's workflow definition, use secured parameters so this information isn't visible after you save your logic app. Stel dat u voor een HTTP-actie basis verificatie nodig hebt, waarbij een gebruikers naam en wacht woord worden gebruikt.For example, suppose you have an HTTP action requires basic authentication, which uses a username and password. In de definitie van de werk stroom parameters definieert de sectie de basicAuthPasswordParam en- basicAuthUsernameParam para meters met behulp van het securestring type.In the workflow definition, the parameters section defines the basicAuthPasswordParam and basicAuthUsernameParam parameters by using the securestring type. De actie definitie verwijst vervolgens naar deze para meters in de authentication sectie.The action definition then references these parameters in the authentication section.

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

Veilige para meters in Azure Resource Manager sjablonenSecure parameters in Azure Resource Manager templates

Een Resource Manager-sjabloon voor een logische app heeft meerdere parameters secties.A Resource Manager template for a logic app has multiple parameters sections. Als u wacht woorden, sleutels, geheimen en andere gevoelige informatie wilt beveiligen, definieert u de beveiligde para meters op sjabloon niveau en op het niveau van de werk stroom definitie met behulp van het securestring of- secureobject type.To protect passwords, keys, secrets, and other sensitive information, define secured parameters at the template level and workflow definition level by using the securestring or secureobject type. U kunt deze waarden vervolgens opslaan in Azure Key Vault en het parameter bestand gebruiken om te verwijzen naar de sleutel kluis en het geheim.You can then store these values in Azure Key Vault and use the parameter file to reference the key vault and secret. Uw sjabloon haalt vervolgens die informatie op tijdens de implementatie.Your template then retrieves that information at deployment. Zie voor meer informatie gevoelige waarden door geven tijdens de implementatie met behulp van Azure Key Vault.For more information, see Pass sensitive values at deployment by using Azure Key Vault.

Hier vindt u meer informatie over deze parameters secties:Here is more information about these parameters sections:

  • Op het hoogste niveau van de sjabloon parameters definieert een sectie de para meters voor de waarden die de sjabloon gebruikt bij de implementatie.At the template's top level, a parameters section defines the parameters for the values that the template uses at deployment. Deze waarden kunnen bijvoorbeeld verbindings reeksen bevatten voor een specifieke implementatie omgeving.For example, these values can include connection strings for a specific deployment environment. U kunt deze waarden vervolgens opslaan in een afzonderlijk parameter bestand, waardoor het wijzigen van deze waarden eenvoudiger wordt.You can then store these values in a separate parameter file, which makes changing these values easier.

  • In de resource definitie van uw logische app, maar buiten uw werk stroom definitie, parameters geeft een sectie de waarden voor de para meters van uw werk stroom definitie op.Inside your logic app's resource definition, but outside your workflow definition, a parameters section specifies the values for your workflow definition's parameters. In deze sectie kunt u deze waarden toewijzen met behulp van sjabloon expressies die verwijzen naar de para meters van uw sjabloon.In this section, you can assign these values by using template expressions that reference your template's parameters. Deze expressies worden geëvalueerd tijdens de implementatie.These expressions are evaluated at deployment.

  • In de definitie van de werk stroom parameters definieert een sectie de para meters die door de logische app worden gebruikt tijdens runtime.Inside your workflow definition, a parameters section defines the parameters that your logic app uses at runtime. U kunt vervolgens naar deze para meters in de werk stroom van de logische app verwijzen met behulp van definitie expressies voor werk stromen, die tijdens runtime worden geëvalueerd.You can then reference these parameters inside your logic app's workflow by using workflow definition expressions, which are evaluated at runtime.

Deze voorbeeld sjabloon met meerdere beveiligde parameter definities die gebruikmaken van het securestring type:This example template that has multiple secured parameter definitions that use the securestring type:

ParameternaamParameter name BeschrijvingDescription
TemplatePasswordParam Een sjabloon parameter die vervolgens een wacht woord accepteert dat vervolgens wordt door gegeven aan de para meter van de werk stroom definitie basicAuthPasswordParamA template parameter that accepts a password that is then passed to the workflow definition's basicAuthPasswordParam parameter
TemplateUsernameParam Een sjabloon parameter die vervolgens een gebruikers naam accepteert die vervolgens wordt door gegeven aan de para meter van de werk stroom definitie basicAuthUserNameParamA template parameter that accepts a username that is then passed to the workflow definition's basicAuthUserNameParam parameter
basicAuthPasswordParam Een para meter voor de werk stroom definitie die het wacht woord voor basis verificatie in een HTTP-actie accepteertA workflow definition parameter that accepts the password for basic authentication in an HTTP action
basicAuthUserNameParam Een para meter voor de werk stroom definitie die de gebruikers naam voor basis verificatie in een HTTP-actie accepteertA workflow definition parameter that accepts the username for basic authentication in an HTTP action
{
   "$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-0601/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": {}
}

Toegang tot services en systemen die worden aangeroepen vanuit Logic appsAccess to services and systems called from logic apps

Hier volgen enkele manieren waarop u eind punten kunt beveiligen die oproepen of aanvragen ontvangen van uw logische app:Here are some ways that you can help secure endpoints that receive calls or requests from your logic app:

  • Verificatie toevoegen aan uitgaande aanvragen.Add authentication to outbound requests.

    Wanneer u werkt met een HTTP-trigger of actie die uitgaande aanroepen uitvoert, zoals HTTP, HTTP + Swagger of webhook, kunt u verificatie toevoegen aan de aanvraag die wordt verzonden door uw logische app.When you work with an HTTP-based trigger or action that makes outbound calls, such as HTTP, HTTP + Swagger, or Webhook, you can add authentication to the request that's sent by your logic app. U kunt bijvoorbeeld de volgende verificatie typen selecteren:For example, you can select these authentication types:

    Zie verificatie toevoegen aan uitgaande oproepen verderop in dit onderwerp voor meer informatie.For more information, see Add authentication to outbound calls later in this topic.

  • Beperk de toegang tot IP-adressen van logische apps.Restrict access from logic app IP addresses.

    Alle aanroepen naar eind punten van Logic apps zijn afkomstig van specifieke IP-adressen die zijn gebaseerd op de regio's van uw Logic apps.All calls to endpoints from logic apps originate from specific designated IP addresses that are based on your logic apps' regions. U kunt filters toevoegen die alleen aanvragen van deze IP-adressen accepteren.You can add filtering that accepts requests only from those IP addresses. Zie limieten en configuratie voor Azure Logic appsom deze IP-adressen op te halen.To get these IP addresses, see Limits and configuration for Azure Logic Apps.

  • Verbeter de beveiliging van verbindingen met on-premises systemen.Improve security for connections to on-premises systems.

    Azure Logic Apps biedt integratie met deze services om veiligere en betrouw bare on-premises communicatie te bieden.Azure Logic Apps provides integration with these services to help provide more secure and reliable on-premises communication.

    • On-premises gegevensgatewayOn-premises data gateway

      Veel beheerde connectors in Azure Logic Apps ondersteunen beveiligde verbindingen met on-premises systemen, zoals bestands systeem, SQL, share point en DB2.Many managed connectors in Azure Logic Apps facilitate secured connections to on-premises systems, such as File System, SQL, SharePoint, and DB2. De Gateway verzendt gegevens via on-premises bronnen op versleutelde kanalen via de Azure Service Bus.The gateway sends data from on-premises sources on encrypted channels through the Azure Service Bus. Al het verkeer is afkomstig van het beveiligde uitgaande verkeer van de gateway-agent.All traffic originates as secured outbound traffic from the gateway agent. Meer informatie over de werking van de on-premises gegevens gateway.Learn how the on-premises data gateway works.

    • Verbinding maken via Azure API ManagementConnect through Azure API Management

      Azure API Management biedt opties voor on-premises verbindingen, zoals site-naar-site virtueel particulier netwerk en ExpressRoute-integratie voor beveiligde proxy en communicatie met on-premises systemen.Azure API Management provides on-premises connection options, such as site-to-site virtual private network and ExpressRoute integration for secured proxy and communication to on-premises systems. Vanuit de werk stroom van uw logische app in de ontwerp functie voor logische apps kunt u een API selecteren die wordt weer gegeven door API Management, die snelle toegang biedt tot on-premises systemen.From your logic app's workflow in the Logic App Designer, you can select an API that's exposed by API Management, which provides quick access to on-premises systems.

Verificatie toevoegen aan uitgaande oproepenAdd authentication to outbound calls

HTTP-en HTTPS-eind punten ondersteunen verschillende soorten verificatie.HTTP and HTTPS endpoints support various kinds of authentication. Bij sommige triggers en acties die u gebruikt voor het verzenden van uitgaande oproepen of aanvragen naar deze eind punten, kunt u een verificatie type opgeven.On some triggers and actions that you use for sending outbound calls or requests to these endpoints, you can specify an authentication type. In de ontwerp functie voor logische apps hebben triggers en acties die ondersteuning bieden voor het kiezen van een verificatie type een verificatie -eigenschap.In the Logic App Designer, triggers and actions that support choosing an authentication type have an Authentication property. Deze eigenschap wordt echter mogelijk niet standaard altijd weer gegeven.However, this property might not always appear by default. In deze gevallen opent u de lijst nieuwe para meter toevoegen op de trigger of actie en selecteert u verificatie.In these cases, on the trigger or action, open the Add new parameter list, and select Authentication.

Belangrijk

Voor het beveiligen van gevoelige informatie die uw logische app afhandelt, gebruikt u beveiligde para meters en codeer gegevens als dat nodig is.To protect sensitive information that your logic app handles, use secured parameters and encode data as necessary. Zie toegang tot para meters invoerenvoor meer informatie over het gebruik en het beveiligen van para meters.For more information about using and securing parameters, see Access to parameter inputs.

Deze tabel bevat de verificatie typen die beschikbaar zijn voor de triggers en acties waarbij u een verificatie type kunt selecteren:This table identifies the authentication types that are available on the triggers and actions where you can select an authentication type:

VerificatietypeAuthentication type BeschikbaarheidAvailability
StandaardBasic Azure API Management, Azure-app Services, HTTP, HTTP + Swagger, HTTP-webhookAzure API Management, Azure App Services, HTTP, HTTP + Swagger, HTTP Webhook
Client certificaatClient Certificate Azure API Management, Azure-app Services, HTTP, HTTP + Swagger, HTTP-webhookAzure API Management, Azure App Services, HTTP, HTTP + Swagger, HTTP Webhook
Active Directory OAuthActive Directory OAuth Azure API Management, Azure-app Services, Azure Functions, HTTP, HTTP + Swagger, HTTP-webhookAzure API Management, Azure App Services, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
OnbewerktRaw Azure API Management, Azure-app Services, Azure Functions, HTTP, HTTP + Swagger, HTTP-webhookAzure API Management, Azure App Services, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
Beheerde identiteitManaged identity Azure API Management, Azure-app Services, Azure Functions, HTTP, HTTP + Swagger, HTTP-webhookAzure API Management, Azure App Services, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook

BasisverificatieBasic authentication

Als de optie basis beschikbaar is, geeft u de volgende eigenschaps waarden op:If the Basic option is available, specify these property values:

Eigenschap (Designer)Property (designer) Eigenschap (JSON)Property (JSON) VereistRequired WaardeValue BeschrijvingDescription
VerificatieAuthentication type YesYes BasicBasic Het te gebruiken verificatie typeThe authentication type to use
GebruikersnaamUsername username YesYes <gebruikers naam><user-name> De gebruikers naam voor het verifiëren van de toegang tot het eind punt van de doel serviceThe user name for authenticating access to the target service endpoint
WachtwoordPassword password YesYes <wacht woord><password> Het wacht woord voor het verifiëren van de toegang tot het eind punt van de doel serviceThe password for authenticating access to the target service endpoint

Wanneer u beveiligde para meters gebruikt voor het verwerken en beveiligen van gevoelige informatie, bijvoorbeeld in een Azure Resource Manager sjabloon voor het automatiseren van de implementatie, kunt u expressies gebruiken om toegang te krijgen tot deze parameter waarden tijdens runtime.When you use secured parameters to handle and secure sensitive information, for example, in an Azure Resource Manager template for automating deployment, you can use expressions to access these parameter values at runtime. In dit voor beeld van een HTTP-actie definitie wordt de verificatie opgegeven type als Basic en wordt de functie para meters () gebruikt om de parameter waarden op te halen:This example HTTP action definition specifies the authentication type as Basic and uses the parameters() function to get the parameter values:

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

Verificatie van client certificatenClient Certificate authentication

Als de optie client certificaat beschikbaar is, geeft u de volgende eigenschaps waarden op:If the Client Certificate option is available, specify these property values:

Eigenschap (Designer)Property (designer) Eigenschap (JSON)Property (JSON) VereistRequired WaardeValue BeschrijvingDescription
VerificatieAuthentication type YesYes Client certificaatClient Certificate
ofor
ClientCertificate
Het verificatie type dat moet worden gebruikt.The authentication type to use. U kunt certificaten beheren met Azure API Management.You can manage certificates with Azure API Management.

Opmerking: aangepaste connectors bieden geen ondersteuning voor verificatie op basis van certificaten voor zowel binnenkomende als uitgaande oproepen.Note: Custom connectors don't support certificate-based authentication for both inbound and outbound calls.
PfxPfx pfx YesYes <encoded-pfx-file-content><encoded-pfx-file-content> De met base64 gecodeerde inhoud van een PFX-bestand (Personal Information Exchange)The base64-encoded content from a Personal Information Exchange (PFX) file

Als u het PFX-bestand wilt converteren naar een base64-gecodeerde indeling, kunt u Power shell gebruiken door de volgende stappen uit te voeren:To convert the PFX file into base64-encoded format, you can use PowerShell by following these steps:

1. Sla de certificaat inhoud op in een variabele:1. Save the certificate content into a variable:

$pfx_cert = get-content 'c:\certificate.pfx' -Encoding Byte

2. Converteer de certificaat inhoud met behulp van de ToBase64String() functie en sla die inhoud op in een tekst bestand:2. Convert the certificate content by using the ToBase64String() function and save that content to a text file:

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

WachtwoordPassword password NoNo <wacht woord voor pfx-bestand><password-for-pfx-file> Het wacht woord voor toegang tot het PFX-bestandThe password for accessing the PFX file

Wanneer u beveiligde para meters gebruikt voor het verwerken en beveiligen van gevoelige informatie, bijvoorbeeld in een Azure Resource Manager sjabloon voor het automatiseren van de implementatie, kunt u expressies gebruiken om toegang te krijgen tot deze parameter waarden tijdens runtime.When you use secured parameters to handle and secure sensitive information, for example, in an Azure Resource Manager template for automating deployment, you can use expressions to access these parameter values at runtime. In dit voor beeld van een HTTP-actie definitie wordt de verificatie opgegeven type als ClientCertificate en wordt de functie para meters () gebruikt om de parameter waarden op te halen:This example HTTP action definition specifies the authentication type as ClientCertificate and uses the parameters() function to get the parameter values:

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

Zie de volgende onderwerpen voor meer informatie over het beveiligen van services met behulp van verificatie via client certificaten:For more information about securing services by using client certificate authentication, see these topics:

Verificatie Azure Active Directory openenAzure Active Directory Open Authentication

Op aanvraag triggers kunt u Azure Active Directory open-verificatie (Azure AD OAuth) gebruiken voor de verificatie van binnenkomende oproepen nadat u een Azure AD-autorisatie beleid hebt ingesteld voor uw logische app.On Request triggers, you can use Azure Active Directory Open Authentication (Azure AD OAuth), for authenticating incoming calls after you set up Azure AD authorization policies for your logic app. Voor alle andere triggers en acties die het Active Directory OAuth -verificatie type voor u selecteren, geeft u de volgende eigenschaps waarden op:For all other triggers and actions that provide the Active Directory OAuth authentication type for you to select, specify these property values:

Eigenschap (Designer)Property (designer) Eigenschap (JSON)Property (JSON) VereistRequired WaardeValue BeschrijvingDescription
VerificatieAuthentication type YesYes Active Directory OAuthActive Directory OAuth
ofor
ActiveDirectoryOAuth
Het verificatie type dat moet worden gebruikt.The authentication type to use. Het OAuth 2,0-protocolwordt momenteel gevolgd door Logic apps.Logic Apps currently follows the OAuth 2.0 protocol.
InstantieAuthority authority NoNo <URL-voor-Authority-token-Uitgever><URL-for-authority-token-issuer> De URL voor de instantie die het verificatie token levert.The URL for the authority that provides the authentication token. Deze waarde is standaard ingesteld op https://login.windows.net .By default, this value is https://login.windows.net.
TenantTenant tenant YesYes <Tenant-ID><tenant-ID> De Tenant-ID voor de Azure AD-TenantThe tenant ID for the Azure AD tenant
DoelgroepAudience audience YesYes <resource-naar-autoriseren><resource-to-authorize> De resource die u wilt gebruiken voor autorisatie, bijvoorbeeldhttps://management.core.windows.net/The resource that you want to use for authorization, for example, https://management.core.windows.net/
Client-idClient ID clientId YesYes <client-ID><client-ID> De client-ID voor de app die autorisatie aanvraagtThe client ID for the app requesting authorization
Referentie typeCredential Type credentialType YesYes CertificaatCertificate
ofor
GeheimSecret
Het referentie type dat door de client wordt gebruikt voor het aanvragen van autorisatie.The credential type that the client uses for requesting authorization. Deze eigenschap en waarde worden niet weer gegeven in de onderliggende definitie van de logische app, maar bepaalt de eigenschappen die worden weer gegeven voor het geselecteerde referentie type.This property and value don't appear in your logic app's underlying definition, but determines the properties that appear for the selected credential type.
GeheimSecret secret Ja, maar alleen voor het referentie type ' geheim 'Yes, but only for the "Secret" credential type <client-geheim><client-secret> Het client geheim voor het aanvragen van autorisatieThe client secret for requesting authorization
PfxPfx pfx Ja, maar alleen voor het referentie type ' certificaat 'Yes, but only for the "Certificate" credential type <encoded-pfx-file-content><encoded-pfx-file-content> De met base64 gecodeerde inhoud van een PFX-bestand (Personal Information Exchange)The base64-encoded content from a Personal Information Exchange (PFX) file
WachtwoordPassword password Ja, maar alleen voor het referentie type ' certificaat 'Yes, but only for the "Certificate" credential type <wacht woord voor pfx-bestand><password-for-pfx-file> Het wacht woord voor toegang tot het PFX-bestandThe password for accessing the PFX file

Wanneer u beveiligde para meters gebruikt voor het verwerken en beveiligen van gevoelige informatie, bijvoorbeeld in een Azure Resource Manager sjabloon voor het automatiseren van de implementatie, kunt u expressies gebruiken om toegang te krijgen tot deze parameter waarden tijdens runtime.When you use secured parameters to handle and secure sensitive information, for example, in an Azure Resource Manager template for automating deployment, you can use expressions to access these parameter values at runtime. In dit voor beeld van een HTTP-actie definitie wordt de verificatie ingesteld type als ActiveDirectoryOAuth , het referentie type als en Secret wordt de functie para meters () gebruikt om de parameter waarden op te halen:This example HTTP action definition specifies the authentication type as ActiveDirectoryOAuth, the credential type as Secret, and uses the parameters() function to get the parameter values:

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

Onbewerkte authenticatieRaw authentication

Als de onbewerkte optie beschikbaar is, kunt u dit verificatie type gebruiken wanneer u verificatie schema's moet gebruiken die niet voldoen aan het OAuth 2,0-protocol.If the Raw option is available, you can use this authentication type when you have to use authentication schemes that don't follow the OAuth 2.0 protocol. Met dit type kunt u hand matig de waarde voor de autorisatie-header maken die u met de uitgaande aanvraag verzendt en die header waarde opgeven in de trigger of actie.With this type, you manually create the authorization header value that you send with the outgoing request, and specify that header value in your trigger or action.

Hier ziet u een voor beeld van een header voor een HTTPS-aanvraag die volgt op het OAuth 1,0-protocol:For example, here is a sample header for an HTTPS request that follows the OAuth 1.0 protocol:

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"

Geef in de trigger of actie die onbewerkte authenticatie ondersteunt de volgende eigenschaps waarden op:In the trigger or action that supports raw authentication, specify these property values:

Eigenschap (Designer)Property (designer) Eigenschap (JSON)Property (JSON) VereistRequired WaardeValue BeschrijvingDescription
VerificatieAuthentication type YesYes OnbewerktRaw Het te gebruiken verificatie typeThe authentication type to use
WaardeValue value YesYes <autorisatie-header-waarde><authorization-header-value> De waarde van de autorisatie-header die moet worden gebruikt voor verificatieThe authorization header value to use for authentication

Wanneer u beveiligde para meters gebruikt voor het verwerken en beveiligen van gevoelige informatie, bijvoorbeeld in een Azure Resource Manager sjabloon voor het automatiseren van de implementatie, kunt u expressies gebruiken om toegang te krijgen tot deze parameter waarden tijdens runtime.When you use secured parameters to handle and secure sensitive information, for example, in an Azure Resource Manager template for automating deployment, you can use expressions to access these parameter values at runtime. In dit voor beeld wordt de HTTP-actie definitie opgegeven type als Raw , en wordt de functie para meters () gebruikt om de parameter waarden op te halen:This example HTTP action definition specifies the authentication type as Raw, and uses the parameters() function to get the parameter values:

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

Verificatie van beheerde identiteitManaged identity authentication

Als de optie beheerde identiteit beschikbaar is, kan uw logische app gebruikmaken van de door het systeem toegewezen identiteit of een enkele hand matig gemaakte door de gebruiker toegewezen identiteit voor het verifiëren van toegang tot andere bronnen die worden beveiligd door Azure Active Directory (Azure AD) zonder dat u zich hoeft aan te melden.If the Managed Identity option is available, your logic app can use the system-assigned identity or a single manually created user-assigned identity for authenticating access to other resources that are protected by Azure Active Directory (Azure AD) without signing in. Azure beheert deze identiteit voor u en helpt u bij het beveiligen van uw referenties omdat u geen geheimen hoeft op te geven of te draaien.Azure manages this identity for you and helps you secure your credentials because you don't have to provide or rotate secrets. Meer informatie over Azure-Services die ondersteuning bieden voor beheerde identiteiten voor Azure AD-verificatie.Learn more about Azure services that support managed identities for Azure AD authentication.

  1. Voordat uw logische app een beheerde identiteit kan gebruiken, volgt u de stappen in toegang tot Azure-resources verifiëren door beheerde identiteiten te gebruiken in azure Logic apps.Before your logic app can use a managed identity, follow the steps in Authenticate access to Azure resources by using managed identities in Azure Logic Apps. Met deze stappen wordt de beheerde identiteit voor uw logische app ingeschakeld en wordt de toegang tot de Azure-doel bron ingesteld.These steps enable the managed identity on your logic app and set up that identity's access to the target Azure resource.

  2. Voordat een Azure-functie een beheerde identiteit kan gebruiken, moet u eerst verificatie voor Azure functions inschakelen.Before an Azure function can use a managed identity, first enable authentication for Azure functions.

  3. Geef in de trigger of actie waar u de beheerde identiteit wilt gebruiken, de volgende eigenschaps waarden op:In the trigger or action where you want to use the managed identity, specify these property values:

    Eigenschap (Designer)Property (designer) Eigenschap (JSON)Property (JSON) VereistRequired WaardeValue BeschrijvingDescription
    VerificatieAuthentication type YesYes Beheerde identiteitManaged Identity
    ofor
    ManagedServiceIdentity
    Het te gebruiken verificatie typeThe authentication type to use
    Beheerde identiteitManaged Identity identity YesYes * Door het systeem toegewezen beheerde identiteit* System Assigned Managed Identity
    ofor
    SystemAssigned

    * <door de gebruiker toegewezen identiteits naam>* <user-assigned-identity-name>

    De beheerde identiteit die moet worden gebruiktThe managed identity to use
    DoelgroepAudience audience YesYes <doel-Resource-ID><target-resource-ID> De resource-ID voor de doel resource waartoe u toegang wilt krijgen.The resource ID for the target resource that you want to access.

    https://storage.azure.com/Maakt bijvoorbeeld de toegangs tokens voor verificatie geldig voor alle opslag accounts.For example, https://storage.azure.com/ makes the access tokens for authentication valid for all storage accounts. U kunt echter ook een URL voor de basis service opgeven, zoals https://fabrikamstorageaccount.blob.core.windows.net voor een specifiek opslag account.However, you can also specify a root service URL, such as https://fabrikamstorageaccount.blob.core.windows.net for a specific storage account.

    Opmerking: de eigenschap doel groep kan in sommige triggers of acties worden verborgen.Note: The Audience property might be hidden in some triggers or actions. Als u deze eigenschap zichtbaar wilt maken, opent u de lijst nieuwe para meter toevoegen in de trigger of actie en selecteert u doel groep.To make this property visible, in the trigger or action, open the Add new parameter list, and select Audience.

    Belang rijk: Zorg ervoor dat deze doel resource-id precies overeenkomt met de waarde die door Azure AD wordt verwacht, inclusief alle vereiste afsluitende slashes.Important: Make sure that this target resource ID exactly matches the value that Azure AD expects, including any required trailing slashes. De https://storage.azure.com/ resource-id voor alle Azure Blob Storage-accounts vereist dus een afsluitende slash.So, the https://storage.azure.com/ resource ID for all Azure Blob Storage accounts requires a trailing slash. De resource-ID voor een specifiek opslag account vereist echter geen afsluitende slash.However, the resource ID for a specific storage account doesn't require a trailing slash. Zie Azure-Services die ondersteuning bieden voor Azure ADom deze resource-id's te vinden.To find these resource IDs, see Azure services that support Azure AD.

    Wanneer u beveiligde para meters gebruikt voor het verwerken en beveiligen van gevoelige informatie, bijvoorbeeld in een Azure Resource Manager sjabloon voor het automatiseren van de implementatie, kunt u expressies gebruiken om toegang te krijgen tot deze parameter waarden tijdens runtime.When you use secured parameters to handle and secure sensitive information, for example, in an Azure Resource Manager template for automating deployment, you can use expressions to access these parameter values at runtime. In dit voor beeld van een HTTP-actie definitie wordt de verificatie opgegeven type als ManagedServiceIdentity en wordt de functie para meters () gebruikt om de parameter waarden op te halen:This example HTTP action definition specifies the authentication type as ManagedServiceIdentity and uses the parameters() function to get the parameter values:

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

Maken van verbindingen blok kerenBlock creating connections

Als uw organisatie geen verbinding met specifieke bronnen kan maken met behulp van hun connectors in Azure Logic Apps, kunt u de mogelijkheid blok keren om deze verbindingen voor specifieke connectors in de werk stromen van logische apps te gebruiken met behulp van Azure Policy.If your organization doesn't permit connecting to specific resources by using their connectors in Azure Logic Apps, you can block the capability to create those connections for specific connectors in logic app workflows by using Azure Policy. Zie voor meer informatie blok keren verbindingen die zijn gemaakt door specifieke connectors in azure Logic apps.For more information, see Block connections created by specific connectors in Azure Logic Apps.

Volgende stappenNext steps