Beveiligde toegang en gegevens voor werkstromen in Azure Logic Apps

  • Artikel

Azure Logic Apps is afhankelijk van Azure Storage om data-at-rest op te slaan en automatisch te versleutelen. Deze versleuteling beschermt uw gegevens en helpt u om te voldoen aan de beveiligings- en nalevingsverplichtingen van uw organisatie. Azure Storage maakt standaard gebruik van door Microsoft beheerde sleutels om uw gegevens te versleutelen. Bekijk Azure Storage-versleuteling voor data-at-rest voor meer informatie.

Als u de toegang verder wilt beheren en gevoelige gegevens in Azure Logic Apps wilt beveiligen, kunt u meer beveiliging instellen op de volgende gebieden:

Raadpleeg de volgende onderwerpen voor meer informatie over beveiliging in Azure:

Toegang tot bewerkingen van logische apps

Voor alleen logische apps voor verbruik, voordat u logische apps en hun verbindingen kunt maken of beheren, hebt u specifieke machtigingen nodig. Deze worden geleverd via rollen met behulp van op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC). U kunt ook machtigingen instellen, zodat alleen specifieke gebruikers of groepen specifieke taken kunnen uitvoeren, zoals het beheren, bewerken en weergeven van logische apps. Als u hun machtigingen wilt beheren, kunt u ingebouwde of aangepaste rollen toewijzen aan leden die toegang hebben tot uw Azure-abonnement. Azure Logic Apps heeft de volgende specifieke rollen, op basis van of u een werkstroom voor de logische app Verbruik of Standard hebt:

Werkstromen voor verbruik
Rol Beschrijving
Inzender voor logische apps U kunt werkstromen voor logische apps beheren, maar u kunt de toegang tot deze werkstromen niet wijzigen.
Logische app-operator U kunt werkstromen voor logische apps lezen, inschakelen en uitschakelen, maar u kunt ze niet bewerken of bijwerken.
Inzender U hebt volledige toegang om alle resources te beheren, maar u kunt geen rollen toewijzen in Azure RBAC, toewijzingen beheren in Azure Blueprints of afbeeldingengalerieën delen.

Stel dat u moet werken met een werkstroom voor logische apps die u niet hebt gemaakt en verbindingen hebt geverifieerd die worden gebruikt door die werkstroom voor logische apps. Uw Azure-abonnement vereist inzendermachtigingen voor de resourcegroep die die logische app-resource bevat. Als u een resource voor een logische app maakt, hebt u automatisch inzendertoegang.

Als u wilt voorkomen dat anderen de werkstroom van uw logische app wijzigen of verwijderen, kunt u Azure Resource Lock gebruiken. Met deze mogelijkheid voorkomt u dat anderen productiebronnen kunnen wijzigen of verwijderen. Raadpleeg Verbinding maken ionconfiguratie in Azure Logic Apps en Verbinding maken ion-beveiliging en -versleuteling voor meer informatie over verbindingsbeveiliging.

Standaardwerkstromen

Notitie

Deze mogelijkheid is in preview en is onderworpen aan de aanvullende gebruiksvoorwaarden voor Microsoft Azure Previews.

Rol Beschrijving
Logic Apps Standard Reader (preview) U hebt alleen-lezentoegang tot alle resources in een standaard logische app en werkstromen, waaronder de werkstroomuitvoeringen en hun geschiedenis.
Logic Apps Standard Operator (preview) U hebt toegang tot het inschakelen, opnieuw verzenden en uitschakelen van werkstromen en het maken van verbindingen met services, systemen en netwerken voor een standaard logische app. De rol Operator kan beheer- en ondersteuningstaken uitvoeren op het Azure Logic Apps-platform, maar heeft geen machtigingen om werkstromen of instellingen te bewerken.
Logic Apps Standard Developer (preview) U hebt toegang tot het maken en bewerken van werkstromen, verbindingen en instellingen voor een standaard logische app. De rol Ontwikkelaar heeft geen machtigingen om wijzigingen aan te brengen buiten het bereik van werkstromen, bijvoorbeeld wijzigingen in de hele toepassing, zoals het configureren van integratie van virtuele netwerken. App Service-plannen worden niet ondersteund.
Logic Apps Standard-inzender (preview) U hebt toegang om alle aspecten van een standaard logische app te beheren, maar u kunt de toegang of het eigendom niet wijzigen.

Toegang tot uitvoeringsgeschiedenisgegevens

Tijdens een uitvoering van een logische app worden alle gegevens tijdens de overdracht versleuteld met behulp van Transport Layer Security (TLS) en at-rest. Wanneer de logische app is uitgevoerd, kunt u de geschiedenis voor die uitvoering bekijken, inclusief de stappen die zijn uitgevoerd, samen met de status, duur, invoer en uitvoer voor elke actie. Deze uitgebreide details bieden inzicht in de manier waarop uw logische app is uitgevoerd en waar u kunt beginnen met het oplossen van eventuele problemen die zich voordoen.

Wanneer u de uitvoeringsgeschiedenis van uw logische app bekijkt, verifieert Azure Logic Apps uw toegang en biedt vervolgens koppelingen naar de invoer en uitvoer voor de aanvragen en antwoorden voor elke uitvoering. Voor acties waarmee wachtwoorden, geheimen, sleutels of andere gevoelige informatie worden verwerkt, wilt u echter voorkomen dat anderen die gegevens bekijken en openen. Als uw logische app bijvoorbeeld een geheim van Azure Key Vault krijgt dat moet worden gebruikt bij het verifiëren van een HTTP-actie, wilt u dat geheim verbergen in de weergave.

Als u de toegang tot de invoer en uitvoer in de uitvoeringsgeschiedenis van uw logische app wilt beheren, hebt u de volgende opties:

Toegang beperken per IP-adresbereik

U kunt de toegang tot de invoer en uitvoer in de uitvoeringsgeschiedenis voor uw werkstromen voor logische apps beperken, zodat alleen aanvragen van specifieke IP-adresbereiken die gegevens kunnen bekijken.

Als u bijvoorbeeld wilt voorkomen dat iedereen toegang heeft tot invoer en uitvoer, geeft u een IP-adresbereik op, zoals 0.0.0.0-0.0.0.0. Alleen een persoon met beheerdersmachtigingen kan deze beperking verwijderen, wat de mogelijkheid biedt om just-in-time toegang te krijgen tot gegevens in uw werkstromen voor logische apps. Een geldig IP-bereik gebruikt deze indelingen: x.x.x.x/x of x.x.x.x.x.x.x.x

Als u de toegestane IP-bereiken wilt opgeven, volgt u deze stappen voor Azure Portal of uw Azure Resource Manager-sjabloon:

Werkstromen voor verbruik

  1. Open uw werkstroom voor logische apps in Azure Portal in de ontwerpfunctie.

  2. Selecteer werkstroominstellingen in het menu van uw logische app, onder Instellingen.

  3. Selecteer onder Configuratie van toegangsbeheer> toegestane binnenkomende IP-adressen specifieke IP-bereiken.

  4. Geef onder IP-bereiken voor inhoud de IP-adresbereiken op die toegang hebben tot inhoud van invoer en uitvoer.

Standaardwerkstromen

  1. Open uw logische app-resource in Azure Portal.

  2. Selecteer Netwerken in het menu van de logische app onder Instellingen.

  3. Selecteer toegangsbeperking in de sectie Inkomend verkeer.

  4. Maak een of meer regels om aanvragen van specifieke IP-bereiken toe te staan of te weigeren . U kunt ook de instellingen voor http-headerfilters en doorstuurinstellingen gebruiken.

    Zie Voor meer informatie het blokkeren van binnenkomende IP-adressen in Azure Logic Apps (Standard).

Gegevens in de uitvoeringsgeschiedenis beveiligen met behulp van verdoofing

Veel triggers en acties hebben instellingen voor het beveiligen van invoer, uitvoer of beide uit de uitvoeringsgeschiedenis van een logische app. Alle beheerde connectors en aangepaste connectors ondersteunen deze opties. De volgende ingebouwde bewerkingenbieden echter geen ondersteuning voor deze opties:

Beveiligde invoer - niet-ondersteund Beveiligde uitvoer - niet-ondersteund
Toevoegen aan matrixvariabele
Toevoegen aan tekenreeksvariabele
Variabele voor verlagen
Voor elke
Als
Incrementele variabele
Variabele initialiseren
Herhaling
Scope
Variabele instellen
Schakelen
Beëindigen
Until		 Toevoegen aan matrixvariabele
Toevoegen aan tekenreeksvariabele
Opstellen
Variabele voor verlagen
Voor elke
Als
Incrementele variabele
Variabele initialiseren
JSON parseren
Herhaling
Reactie
Scope
Variabele instellen
Schakelen
Beëindigen
Tot
Wachten

Overwegingen voor het beveiligen van invoer en uitvoer

Bekijk de volgende overwegingen voordat u deze instellingen gebruikt om deze gegevens te beveiligen:

  • Wanneer u de invoer of uitvoer van een trigger of actie verdoezelt, verzendt Azure Logic Apps de beveiligde gegevens niet naar Azure Log Analytics. U kunt ook geen bijgehouden eigenschappen toevoegen aan die trigger of actie voor bewaking.

  • De Azure Logic Apps-API voor het verwerken van werkstroomgeschiedenis retourneert geen beveiligde uitvoer.

  • Als u uitvoer van een actie wilt beveiligen waarmee invoer wordt verborgen of expliciet uitvoer wordt verborgen, schakelt u Beveiligde uitvoer in die actie handmatig in.

  • Zorg ervoor dat u Secure Inputs of Secure Outputs inschakelt in downstreamacties waar u verwacht dat de uitvoeringsgeschiedenis die gegevens verborgen laat.

    Instelling Voor beveiligde uitvoer

    Wanneer u beveiligde uitvoer handmatig inschakelt in een trigger of actie, worden deze uitvoer in Azure Logic Apps verborgen in de uitvoeringsgeschiedenis. Als een downstreamactie deze beveiligde uitvoer expliciet als invoer gebruikt, worden de invoer van deze actie in de uitvoeringsgeschiedenis verborgen in Azure Logic Apps, maar wordt de instelling Beveiligde invoer van de actie niet ingeschakeld.

    Beveiligde uitvoer als invoer en downstream-impact op de meeste acties

    De acties Opstellen, JSON parseren en Antwoorden hebben alleen de instelling Beveiligde invoer . Wanneer deze instelling is ingeschakeld, worden de uitvoer van deze acties ook verborgen. Als deze acties expliciet gebruikmaken van de upstream beveiligde uitvoer als invoer, verbergt Azure Logic Apps de invoer en uitvoer van deze acties, maar schakelt u de instelling Beveiligde invoer van deze acties niet in. Als een downstreamactie expliciet gebruikmaakt van de verborgen uitvoer van de acties Opstellen, JSON parseren of Reageren als invoer, verbergt Azure Logic Apps de invoer of uitvoer van deze downstreamactie niet.

    Beveiligde uitvoer als invoer met downstream-impact op specifieke acties

    Instelling Voor beveiligde invoer

    Wanneer u Beveiligde invoer handmatig inschakelt in een trigger of actie, worden deze invoer in azure Logic Apps verborgen in de uitvoeringsgeschiedenis. Als een downstreamactie expliciet gebruikmaakt van de zichtbare uitvoer van die trigger of actie als invoer, verbergt Azure Logic Apps de invoer van deze downstreamactie in de uitvoeringsgeschiedenis, maar schakelt Beveiligdeinvoer in deze actie niet in en verbergt de uitvoer van deze actie niet.

    Beveiligde invoer en downstream-impact op de meeste acties

    Als de acties Compose, Parse JSON en Response expliciet gebruikmaken van de zichtbare uitvoer van de trigger of actie met de beveiligde invoer, verbergt Azure Logic Apps de invoer en uitvoer van deze acties, maar schakelt de instelling Beveiligde invoer van deze actie niet in. Als een downstreamactie expliciet gebruikmaakt van de verborgen uitvoer van de acties Opstellen, JSON parseren of Reageren als invoer, verbergt Azure Logic Apps de invoer of uitvoer van deze downstreamactie niet.

    Beveiligde invoer en downstreamimpact op specifieke acties

Invoer en uitvoer beveiligen in de ontwerpfunctie

  1. Open uw werkstroom voor logische apps in Azure Portal in de ontwerpfunctie.

  2. Selecteer in de ontwerpfunctie de trigger of actie waar u gevoelige gegevens wilt beveiligen.

  3. Selecteer in het informatievenster dat wordt geopend Instellingen en vouw Beveiliging uit.

    Schermopname van Azure Portal, workflowontwerper en trigger of actie met geopende instellingen.

  4. Schakel Beveiligde invoer, beveiligde uitvoer of beide in.

    Schermopname van de werkstroom met de instellingen voor beveiligde invoer of beveiligde uitvoer van een actie ingeschakeld.

    De trigger of actie toont nu een vergrendelingspictogram op de titelbalk. Tokens die beveiligde uitvoer van eerdere acties vertegenwoordigen, tonen ook vergrendelingspictogrammen. Wanneer u bijvoorbeeld in een volgende actie een token hebt geselecteerd voor een beveiligde uitvoer uit de lijst met dynamische inhoud, wordt in dat token een vergrendelingspictogram weergegeven.

    Schermopname van de werkstroom waarin de lijst met dynamische inhoud van een volgende actie is geopend en het token van de vorige actie voor beveiligde uitvoer met het vergrendelingspictogram.

  5. Nadat de werkstroom is uitgevoerd, kunt u de geschiedenis voor die uitvoering bekijken.

    1. Selecteer Overzicht in het menu Logische app Verbruik of in het menu Standaardwerkstroom.

    2. Selecteer onder Uitvoeringsgeschiedenis de uitvoering die u wilt weergeven.

    3. Selecteer in het deelvenster Uitvoeringsgeschiedenis van de werkstroom de acties die u wilt controleren.

      Als u ervoor kiest om zowel invoer als uitvoer te verbergen, worden deze waarden nu verborgen weergegeven.

      Schermopname van de weergave Uitvoeringsgeschiedenis van de Standaardwerkstroom met verborgen invoer en uitvoer.

Invoer en uitvoer beveiligen in de codeweergave

Voeg in de onderliggende trigger- of actiedefinitie de matrix toe of werk deze runtimeConfiguration.secureData.properties bij met een of beide waarden:

  • "inputs": beveiligt invoer in de uitvoeringsgeschiedenis.
  • "outputs": Beveiligt uitvoer in de uitvoeringsgeschiedenis.
"<trigger-or-action-name>": {
   "type": "<trigger-or-action-type>",
   "inputs": {
      <trigger-or-action-inputs>
   },
   "runtimeConfiguration": {
      "secureData": {
         "properties": [
            "inputs",
            "outputs"
         ]
      }
   },
   <other-attributes>
}

Toegang tot parameterinvoer

Als u in verschillende omgevingen implementeert, kunt u overwegen om de waarden in uw werkstroomdefinitie te parameteriseren die variëren op basis van die omgevingen. Op die manier kunt u in code vastgelegde gegevens voorkomen met behulp van een Azure Resource Manager-sjabloon om uw logische app te implementeren, gevoelige gegevens te beveiligen door beveiligde parameters te definiëren en die gegevens door te geven als afzonderlijke invoer via de parameters van de sjabloon met behulp van een parameterbestand.

Als u bijvoorbeeld HTTP-acties verifieert met OAuth met Microsoft Entra ID, kunt u de parameters definiëren en verborgen die de client-id en het clientgeheim accepteren die worden gebruikt voor verificatie. Als u deze parameters wilt definiëren in uw werkstroom voor logische apps, gebruikt u de sectie in de parameters werkstroomdefinitie van uw logische app en de Resource Manager-sjabloon voor implementatie. Als u parameterwaarden wilt beveiligen die u niet wilt weergeven bij het bewerken van uw logische app of het weergeven van de uitvoeringsgeschiedenis, definieert u de parameters met behulp van het securestring of secureobject type en gebruikt u zo nodig codering. Parameters met dit type worden niet geretourneerd met de resourcedefinitie en zijn niet toegankelijk bij het weergeven van de resource na de implementatie. Als u tijdens runtime toegang wilt krijgen tot deze parameterwaarden, gebruikt u de @parameters('<parameter-name>') expressie in uw werkstroomdefinitie. Deze expressie wordt alleen tijdens runtime geëvalueerd en wordt beschreven door de werkstroomdefinitietaal.

Notitie

Als u een parameter in een aanvraagheader of hoofdtekst gebruikt, is die parameter mogelijk zichtbaar wanneer u de uitvoeringsgeschiedenis en uitgaande HTTP-aanvraag van uw werkstroom bekijkt. Zorg ervoor dat u ook het beleid voor toegang tot inhoud instelt. U kunt ook verdoezeling gebruiken om invoer en uitvoer in uw uitvoeringsgeschiedenis te verbergen. Kopteksten zijn standaard Authorization niet zichtbaar via invoer of uitvoer. Dus als daar een geheim wordt gebruikt, kan dat geheim niet worden opgehaald.

Raadpleeg deze secties in dit onderwerp voor meer informatie:

Als u de implementatie voor logische apps automatiseert met behulp van Resource Manager-sjablonen, kunt u beveiligde sjabloonparameters definiëren, die tijdens de implementatie worden geëvalueerd, met behulp van de securestring en secureobject typen. Als u sjabloonparameters wilt definiëren, gebruikt u de sectie op het hoogste niveau parameters van uw sjabloon. Deze sectie is gescheiden en verschilt van de sectie van parameters uw werkstroomdefinitie. Als u de waarden voor sjabloonparameters wilt opgeven, gebruikt u een afzonderlijk parameterbestand.

Als u bijvoorbeeld geheimen gebruikt, kunt u bij de implementatie beveiligde sjabloonparameters definiëren en gebruiken die deze geheimen ophalen uit Azure Key Vault . Vervolgens kunt u verwijzen naar de sleutelkluis en het geheim in uw parameterbestand. Raadpleeg de volgende onderwerpen voor meer informatie:

Beveiligde parameters in werkstroomdefinities (werkstroom verbruik)

Als u gevoelige informatie in de werkstroomdefinitie van uw logische app wilt beveiligen, gebruikt u beveiligde parameters, zodat deze informatie niet zichtbaar is nadat u de werkstroom van uw logische app hebt opgeslagen. Stel dat u een HTTP-actie hebt waarvoor basisverificatie is vereist, waarbij een gebruikersnaam en wachtwoord worden gebruikt. In de werkstroomdefinitie definieert de parameters sectie de basicAuthPasswordParam en basicAuthUsernameParam parameters met behulp van het securestring type. De actiedefinitie verwijst vervolgens naar deze parameters in de authentication sectie.

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

Beveiligde parameters in Azure Resource Manager-sjablonen (werkstroom verbruik)

Een Resource Manager-sjabloon voor een resource en werkstroom voor een logische app heeft meerdere parameters secties. Als u wachtwoorden, sleutels, geheimen en andere gevoelige informatie wilt beveiligen, definieert u beveiligde parameters op sjabloonniveau en werkstroomdefinitieniveau met behulp van het securestring of secureobject type. U kunt deze waarden vervolgens opslaan in Azure Key Vault en het parameterbestand gebruiken om te verwijzen naar de sleutelkluis en het geheim. Uw sjabloon haalt die informatie vervolgens op tijdens de implementatie. Raadpleeg gevoelige waarden doorgeven bij de implementatie met behulp van Azure Key Vault voor meer informatie.

Deze lijst bevat meer informatie over deze parameters secties:

  • Op het hoogste niveau van de sjabloon definieert een parameters sectie de parameters voor de waarden die door de sjabloon worden gebruikt bij de implementatie. Deze waarden kunnen bijvoorbeeld verbindingsreeks s bevatten voor een specifieke implementatieomgeving. U kunt deze waarden vervolgens opslaan in een afzonderlijk parameterbestand, waardoor het wijzigen van deze waarden eenvoudiger wordt.

  • In de resourcedefinitie van uw logische app, maar buiten de werkstroomdefinitie, worden in een parameters sectie de waarden voor de parameters van uw werkstroomdefinitie opgegeven. In deze sectie kunt u deze waarden toewijzen met behulp van sjabloonexpressies die verwijzen naar de parameters van uw sjabloon. Deze expressies worden geëvalueerd tijdens de implementatie.

  • In uw werkstroomdefinitie definieert een parameters sectie de parameters die uw werkstroom van de logische app tijdens runtime gebruikt. U kunt vervolgens verwijzen naar deze parameters in de werkstroom van uw logische app met behulp van werkstroomdefinitieexpressies, die tijdens runtime worden geëvalueerd.

Deze voorbeeldsjabloon met meerdere beveiligde parameterdefinities die gebruikmaken van het securestring type:

Parameternaam Beschrijving
TemplatePasswordParam Een sjabloonparameter die een wachtwoord accepteert dat vervolgens wordt doorgegeven aan de parameter van basicAuthPasswordParam de werkstroomdefinitie
TemplateUsernameParam Een sjabloonparameter die een gebruikersnaam accepteert die vervolgens wordt doorgegeven aan de parameter van basicAuthUserNameParam de werkstroomdefinitie
basicAuthPasswordParam Een parameter voor de werkstroomdefinitie die het wachtwoord accepteert voor basisverificatie in een HTTP-actie
basicAuthUserNameParam Een parameter voor de werkstroomdefinitie die de gebruikersnaam accepteert voor basisverificatie in een HTTP-actie 
{
   "$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": {}
}

Verificatietypen voor connectors die verificatie ondersteunen

De volgende tabel bevat de verificatietypen die beschikbaar zijn voor de connectorbewerkingen, waar u een verificatietype kunt selecteren:

Authentication type Logische app en ondersteunde connectors
Basic Azure API Management, Azure-app Services, HTTP, HTTP + Swagger, HTTP Webhook
Clientcertificaat Azure API Management, Azure-app Services, HTTP, HTTP + Swagger, HTTP Webhook
Active Directory OAuth - Verbruik: Azure API Management, Azure-app Services, Azure Functions, HTTP, HTTP + Swagger, HTTP-webhook

- Standard: Azure Automation, Azure Blob Storage, Azure Event Hubs, Azure Queues, Azure Service Bus, Azure Tables, HTTP, HTTP, HTTP Webhook, SQL Server
Raw Azure API Management, Azure-app Services, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
Beheerde identiteit Ingebouwde connectors:

- Verbruik: Azure API Management, Azure-app Services, Azure Functions, HTTP, HTTP, HTTP-webhook

- Standard: Azure Automation, Azure Blob Storage, Azure Event Hubs, Azure Queues, Azure Service Bus, Azure Tables, HTTP, HTTP, HTTP Webhook, SQL Server

Opmerking: Momenteel bieden de meeste ingebouwde connectors op basis van serviceproviders geen ondersteuning voor het selecteren van door de gebruiker toegewezen beheerde identiteiten voor verificatie.

Beheerde connectors: Azure-app Service, Azure Automation, Azure Blob Storage, Azure Container Instance, Azure Cosmos DB, Azure Data Explorer, Azure Data Factory, Azure Data Lake, Azure Event Grid, Azure Event Hubs, Azure IoT Central V2, Azure IoT Central V3, Azure Key Vault, Azure Log Analytics, Azure Queues, Azure Resource Manager, Azure Service Bus, Azure Sentinel, Azure Table Storage, Azure VM, HTTP met Microsoft Entra ID, SQL Server

Toegang voor inkomende aanroepen naar triggers op basis van aanvragen

Inkomende aanroepen die een logische app ontvangt via een trigger op basis van aanvragen, zoals de aanvraagtrigger of http-webhooktrigger, ondersteunen versleuteling en worden beveiligd met TLS 1.2 (Transport Layer Security) 1.2, voorheen bekend als SSL (Secure Sockets Layer). Azure Logic Apps dwingt deze versie af bij het ontvangen van een inkomende aanroep naar de aanvraagtrigger of een callback naar de HTTP-webhooktrigger of -actie. Als u TLS-handshake-fouten krijgt, moet u TLS 1.2 gebruiken. Raadpleeg het oplossen van het TLS 1.0-probleem voor meer informatie.

Gebruik de volgende coderingssuites voor binnenkomende oproepen:

  • 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

Notitie

Voor achterwaartse compatibiliteit ondersteunt Azure Logic Apps momenteel een aantal oudere coderingssuites. Gebruik echter geen oudere coderingssuites wanneer u nieuwe apps ontwikkelt, omdat dergelijke suites in de toekomst mogelijk niet worden ondersteund.

U kunt bijvoorbeeld de volgende coderingssuites vinden als u de TLS-handshake-berichten inspecteert tijdens het gebruik van de Azure Logic Apps-service of met behulp van een beveiligingshulpprogramma op de URL van uw logische app. Gebruik deze oudere suites nogmaals niet:

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

De volgende lijst bevat meer manieren waarop u de toegang kunt beperken tot triggers die binnenkomende aanroepen naar uw logische app ontvangen, zodat alleen geautoriseerde clients uw logische app kunnen aanroepen:

Shared Access Signatures (SAS) genereren

Elk aanvraageindpunt in een logische app heeft een SHARED Access Signature (SAS) in de URL van het eindpunt, die de volgende indeling volgt:

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

Elke URL bevat de sp, sven sig queryparameter zoals beschreven in deze tabel:

Queryparameter Beschrijving
sp Hiermee geeft u machtigingen op voor de toegestane HTTP-methoden die moeten worden gebruikt.
sv Hiermee geeft u de SAS-versie die moet worden gebruikt voor het genereren van de handtekening.
sig Hiermee geeft u de handtekening op die moet worden gebruikt voor het verifiëren van de toegang tot de trigger. Deze handtekening wordt gegenereerd met behulp van het SHA256-algoritme met een geheime toegangssleutel op alle URL-paden en eigenschappen. Deze sleutel wordt versleuteld bewaard, opgeslagen met de logische app en wordt nooit weergegeven of gepubliceerd. Uw logische app autoriseert alleen de triggers die een geldige handtekening bevatten die is gemaakt met de geheime sleutel.

Binnenkomende aanroepen naar een aanvraageindpunt kunnen slechts één autorisatieschema gebruiken, SAS of OAuth met Microsoft Entra-id. Hoewel het gebruik van een schema het andere schema niet uitschakelt, veroorzaakt het gebruik van beide schema's tegelijkertijd een fout omdat de service niet weet welk schema u moet kiezen.

Raadpleeg de volgende secties in dit onderwerp voor meer informatie over het beveiligen van toegang met SAS:

Toegangssleutels regenereren

Als u op elk gewenst moment een nieuwe beveiligingstoegangssleutel wilt genereren, gebruikt u de Azure REST API of 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. De URL's die u na regeneratie ophaalt, worden ondertekend met de nieuwe toegangssleutel.

  1. Open in Azure Portal de logische app met de sleutel die u opnieuw wilt genereren.

  2. Selecteer toegangssleutels in het resourcemenu van de logische app onder Instellingen.

  3. Selecteer de sleutel die u opnieuw wilt genereren en voltooi het proces.

Verlopende callback-URL's maken

Als u de eindpunt-URL deelt voor een trigger op basis van aanvragen met andere partijen, kunt u callback-URL's genereren die gebruikmaken van specifieke sleutels en vervaldatums hebben. Op die manier kunt u naadloos sleutels uitrollen of de toegang beperken tot het activeren van uw logische app op basis van een specifieke periode. Als u een vervaldatum voor een URL wilt opgeven, gebruikt u de REST API van Azure Logic Apps, bijvoorbeeld:

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 hoofdtekst de NotAftereigenschap op met behulp van een JSON-datumtekenreeks. Deze eigenschap retourneert een callback-URL die alleen geldig is tot de NotAfter datum en tijd.

URL's maken met primaire of secundaire geheime sleutel

Wanneer u callback-URL's voor een trigger op basis van aanvragen genereert of weergeeft, kunt u de sleutel opgeven die moet worden gebruikt voor het ondertekenen van de URL. Als u een URL wilt genereren die is ondertekend door een specifieke sleutel, gebruikt u de Rest API van Logic Apps, bijvoorbeeld:

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 hoofdtekst de KeyType eigenschap op als of SecondaryPrimary . Deze eigenschap retourneert een URL die is ondertekend door de opgegeven beveiligingssleutel.

Microsoft Entra ID Open Authentication inschakelen (Microsoft Entra ID OAuth)

In een werkstroom voor logische verbruiks-apps die begint met een trigger op basis van aanvragen, kunt u binnenkomende aanroepen verifiëren die zijn verzonden naar het eindpunt dat door die trigger is gemaakt door microsoft Entra ID OAuth in te schakelen. Als u deze verificatie wilt instellen, definieert of voegt u een autorisatiebeleid toe op het niveau van de logische app. Op deze manier gebruiken inkomende aanroepen OAuth-toegangstokens voor autorisatie.

Wanneer uw werkstroom voor logische apps een binnenkomende aanvraag ontvangt die een OAuth-toegangstoken bevat, vergelijkt Azure Logic Apps de claims van het token met de claims die zijn opgegeven door elk autorisatiebeleid. Als er een overeenkomst bestaat tussen de claims van het token en alle claims in ten minste één beleid, slaagt de autorisatie voor de binnenkomende aanvraag. Het token kan meer claims hebben dan het nummer dat is opgegeven door het autorisatiebeleid.

In een standaardwerkstroom voor logische apps die begint met de aanvraagtrigger (maar niet een webhooktrigger), kunt u de Azure Functions-inrichting gebruiken voor het verifiëren van binnenkomende aanroepen die zijn verzonden naar het eindpunt dat door die trigger is gemaakt met behulp van een beheerde identiteit. Deze inrichting wordt ook wel 'Easy Auth' genoemd. Raadpleeg Triggerwerkstromen in Standaard logische apps met Easy Auth voor meer informatie.

Overwegingen voordat u OAuth voor Microsoft Entra-id inschakelt

  • Een binnenkomende aanroep naar het aanvraageindpunt kan slechts één autorisatieschema gebruiken, OAuth met Microsoft Entra ID of Shared Access Signature (SAS). Hoewel het gebruik van een schema het andere schema niet uitschakelt, veroorzaakt het gebruik van beide schema's tegelijkertijd een fout omdat Azure Logic Apps niet weet welk schema u moet kiezen.

  • Azure Logic Apps biedt ondersteuning voor het bearer-type of proof-of-possession-type (alleen verbruikslogica-app) autorisatieschema's voor OAuth-toegangstokens voor Microsoft Entra ID. De Authorization header voor het toegangstoken moet echter het Bearer type of PoP het type opgeven. Zie Een PoP-token (Proof of Possession) ophalen en gebruiken voor meer informatie over het ophalen en gebruiken van een PoP-token.

  • Uw logische app-resource is beperkt tot een maximum aantal autorisatiebeleidsregels. Elk autorisatiebeleid heeft ook een maximum aantal claims. Raadpleeg limieten en configuratie voor Azure Logic Apps voor meer informatie.

  • Een autorisatiebeleid moet ten minste de verlenerclaim bevatten, die een waarde heeft die begint met of https://sts.windows.net/https://login.microsoftonline.com/ (OAuth V2) als de Microsoft Entra-verlener-id.

    Stel dat uw logische app-resource een autorisatiebeleid heeft waarvoor twee claimtypen, doelgroep en verlener vereist zijn. Dit voorbeeld van een nettoladingsectie voor een gedecodeerd toegangstoken bevat zowel claimtypen als aud de doelgroepwaarde en iss de waarde van de uitgever :

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

Microsoft Entra ID OAuth inschakelen als enige optie om een aanvraageindpunt aan te roepen

  1. Stel uw aanvraag- of HTTP-webhooktrigger in met de mogelijkheid om het OAuth-toegangstoken te controleren door de stappen te volgen om de autorisatieheader op te nemen in de uitvoer van de aanvraag- of HTTP-webhooktrigger.

    Notitie

    Met deze stap wordt de Authorization header zichtbaar in de uitvoeringsgeschiedenis van de werkstroom en in de uitvoer van de trigger.

  2. Open in Azure Portal uw werkstroom voor logische verbruiks-apps in de ontwerpfunctie.

  3. Selecteer de trigger in de ontwerpfunctie. Selecteer Instellingen in het informatievenster dat wordt geopend.

  4. Selecteer Toevoegen onder Algemene>triggervoorwaarden. Voer in het vak triggervoorwaarde een van de volgende expressies in op basis van het tokentype dat u wilt gebruiken:

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

    – of –

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

Als u het triggereindpunt zonder de juiste autorisatie aanroept, wordt in de uitvoeringsgeschiedenis alleen de trigger weergegeven, net als Skipped zonder een bericht dat de triggervoorwaarde is mislukt.

Een PoP-token (Proof-of-Possession) ophalen

De MSAL-bibliotheken (Microsoft Authentication Library) bieden PoP-tokens die u kunt gebruiken. Als voor de werkstroom van de logische app die u wilt aanroepen een PoP-token is vereist, kunt u dit token ophalen met behulp van de MSAL-bibliotheken. In de volgende voorbeelden ziet u hoe u PoP-tokens kunt verkrijgen:

Als u het PoP-token wilt gebruiken met de werkstroom van de logische app Verbruik, volgt u de volgende sectie om OAuth in te stellen met Microsoft Entra-id.

Microsoft Entra ID OAuth inschakelen voor de resource van de logische app Verbruik

Volg deze stappen voor Azure Portal of uw Azure Resource Manager-sjabloon:

Voeg in Azure Portal een of meer autorisatiebeleidsregels toe aan de resource van uw logische app verbruik:

  1. Open uw logische app Verbruik in Azure Portal in de ontwerpfunctie voor werkstromen.

  2. Selecteer Autorisatie in het resourcemenu van de logische app onder Instellingen. Nadat het deelvenster Autorisatie is geopend, selecteert u Beleid toevoegen.

    Schermopname van azure Portal, menu Logische verbruiks-app, autorisatiepagina en geselecteerde knop om beleid toe te voegen.

  3. Geef informatie op over het autorisatiebeleid door de claimtypen en waarden op te geven die uw logische app verwacht in het toegangstoken dat wordt weergegeven door elke binnenkomende aanroep naar de aanvraagtrigger:

    Schermopname van de azure-portal, de pagina Autorisatie van logische app verbruik en informatie over autorisatiebeleid.

    Eigenschappen Vereist Type Description
    Beleidsnaam Ja String De naam die u wilt gebruiken voor het autorisatiebeleid
    Beleidstype Ja String AAD voor bearer-typetokens of AADPOP voor proof-of-possession-tokens.
    Claims Ja String Een sleutel-waardepaar dat het claimtype en de waarde aangeeft die de aanvraagtrigger van de werkstroom verwacht in het toegangstoken dat wordt weergegeven door elke inkomende aanroep naar de trigger. U kunt elke gewenste standaardclaim toevoegen door standaardclaim toevoegen te selecteren. Als u een claim wilt toevoegen die specifiek is voor een PoP-token, selecteert u Aangepaste claim toevoegen.

    Beschikbare standaardclaimtypen:

    - Verlener
    - Publiek
    - Onderwerp
    - JWT-id (JSON-webtoken-id)

    Eisen:

    - Minimaal moet de lijst claims de claim Issuer bevatten, die een waarde heeft die begint met https://sts.windows.net/ of https://login.microsoftonline.com/ als de verlener-id van Microsoft Entra.

    - Elke claim moet één tekenreekswaarde zijn, niet een matrix met waarden. U kunt bijvoorbeeld een claim hebben met Rol als het type en Ontwikkelaar als de waarde. U kunt geen claim hebben met Rol als het type en de waarden die zijn ingesteld op Developer en Program Manager.

    - De claimwaarde is beperkt tot een maximum aantal tekens.

    Raadpleeg claims in Microsoft Entra-beveiligingstokens voor meer informatie over deze claimtypen. U kunt ook uw eigen claimtype en -waarde opgeven.

    In het volgende voorbeeld ziet u de informatie voor een PoP-token:

    Schermopname van de azure-portal, de autorisatiepagina van de logische app verbruik en informatie voor een proof-of-possession-beleid.

  4. Als u een andere claim wilt toevoegen, selecteert u een van de volgende opties:

    • Als u nog een claimtype wilt toevoegen, selecteert u Standaardclaim toevoegen, selecteert u het claimtype en geeft u de claimwaarde op.

    • Als u uw eigen claim wilt toevoegen, selecteert u Aangepaste claim toevoegen. Raadpleeg voor meer informatie hoe u optionele claims voor uw app kunt opgeven. Uw aangepaste claim wordt vervolgens opgeslagen als onderdeel van uw JWT-id; bijvoorbeeld "tid": "72f988bf-86f1-41af-91ab-2d7cd011db47".

  5. Als u nog een autorisatiebeleid wilt toevoegen, selecteert u Beleid toevoegen. Herhaal de vorige stappen om het beleid in te stellen.

  6. Selecteer Opslaan als u klaar bent.

  7. Als u de Authorization header uit het toegangstoken wilt opnemen in de uitvoer van de trigger op basis van aanvragen, raadpleegt u De header Autorisatie opnemen in de uitvoer van de aanvraag- en HTTP-webhooktrigger.

Werkstroomeigenschappen, zoals beleidsregels, worden niet weergegeven in de codeweergave van uw werkstroom in Azure Portal. Als u programmatisch toegang wilt krijgen tot uw beleid, roept u de volgende API aan via Azure Resource Manager: https://management.azure.com/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group-name}/providers/Microsoft.Logic/workflows/{your-workflow-name}?api-version=2016-10-01&_=1612212851820 Zorg ervoor dat u de tijdelijke aanduidingen vervangt voor de id van uw Azure-abonnement, de naam van de resourcegroep en de naam van de werkstroom.

De header Autorisatie opnemen in de uitvoer van de aanvraag- of HTTP-webhooktrigger

Voor logische apps die OAuth met Microsoft Entra-id inschakelen voor het autoriseren van binnenkomende aanroepen voor toegang tot triggers op basis van aanvragen, kunt u de aanvraagtrigger of HTTP Webhook-triggeruitvoer inschakelen om de Authorization header van het OAuth-toegangstoken op te nemen. Voeg in de onderliggende JSON-definitie van de trigger de eigenschap toe en stel deze operationOptions in op IncludeAuthorizationHeadersInOutputs. Hier volgt een voorbeeld voor de aanvraagtrigger:

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

Raadpleeg de volgende onderwerpen voor meer informatie:

Uw werkstroom voor logische apps beschikbaar maken met Azure API Management

Voor meer verificatieprotocollen en -opties kunt u overwegen om uw werkstroom voor logische apps beschikbaar te maken als API met behulp van Azure API Management. Deze service biedt uitgebreide mogelijkheden voor bewaking, beveiliging, beleid en documentatie voor elk eindpunt. API Management kan een openbaar of privé-eindpunt beschikbaar maken voor uw logische app. Als u toegang tot dit eindpunt wilt autoriseren, kunt u OAuth gebruiken met Microsoft Entra-id, clientcertificaat of andere beveiligingsstandaarden. Wanneer API Management een aanvraag ontvangt, verzendt de service de aanvraag naar uw logische app en voert de benodigde transformaties of beperkingen aan. Als u alleen API Management uw werkstroom voor logische apps wilt laten aanroepen, kunt u de binnenkomende IP-adressen van uw logische app beperken.

Voor meer informatie raadpleegt u de volgende documentatie:

Binnenkomende IP-adressen beperken

Samen met Shared Access Signature (SAS) wilt u mogelijk de clients beperken die uw werkstroom voor logische apps kunnen aanroepen. Als u bijvoorbeeld uw aanvraageindpunt beheert met behulp van Azure API Management, kunt u de werkstroom van uw logische app beperken tot alleen aanvragen van het IP-adres voor het API Management-service-exemplaar dat u maakt.

Ongeacht de IP-adressen die u opgeeft, kunt u nog steeds een werkstroom voor logische apps uitvoeren die een trigger op basis van aanvragen heeft met behulp van de Logic Apps REST API: Werkstroomtriggers - Aanvraag uitvoeren of met BEHULP van API Management. Voor dit scenario is echter nog steeds verificatie vereist voor de Azure REST API. Alle gebeurtenissen worden weergegeven in het Azure-auditlogboek. Zorg ervoor dat u het beleid voor toegangsbeheer dienovereenkomstig instelt.

Als u de binnenkomende IP-adressen voor de werkstroom van uw logische app wilt beperken, volgt u de bijbehorende stappen voor Azure Portal of uw Azure Resource Manager-sjabloon. Een geldig IP-bereik gebruikt deze indelingen: x.x.x.x/x of x.x.x.x.x.x.x.x

In Azure Portal is de beperking van IP-adressen van invloed op zowel triggers als acties, in tegenstelling tot de beschrijving in de portal onder Toegestane binnenkomende IP-adressen. Als u dit filter afzonderlijk wilt instellen voor triggers en voor acties, gebruikt u het accessControl object in een Azure Resource Manager-sjabloon voor uw logische app-resource of de Azure Logic Apps REST API: Werkstroom - Bewerking maken of bijwerken.

Werkstromen voor verbruik

  1. Open uw logische app Verbruik in Azure Portal in de ontwerpfunctie voor werkstromen.

  2. Selecteer werkstroominstellingen in het menu van de logische app, onder Instellingen.

  3. Kies in de sectie Configuratie van toegangsbeheer onder Toegestane binnenkomende IP-adressen het pad voor uw scenario:

    • Als u uw werkstroom aanroepbaar wilt maken met behulp van de ingebouwde actie van Azure Logic Apps, maar alleen als geneste werkstroom, selecteert u Alleen andere Logic Apps. Deze optie werkt alleen wanneer u de actie Azure Logic Apps gebruikt om de geneste werkstroom aan te roepen.

      Deze optie schrijft een lege matrix naar uw logische app-resource en vereist dat alleen aanroepen van bovenliggende werkstromen die gebruikmaken van de ingebouwde Azure Logic Apps-actie de geneste werkstroom kunnen activeren.

    • Als u uw werkstroom aanroepbaar wilt maken met behulp van de HTTP-actie, maar alleen als een geneste werkstroom, selecteert u Specifieke IP-bereiken. Wanneer het vak IP-bereiken voor triggers wordt weergegeven, voert u de uitgaande IP-adressen van de bovenliggende werkstroom in. Een geldig IP-bereik gebruikt deze indelingen: x.x.x.x/x of x.x.x.x.x.x.x.x

      Notitie

      Als u de optie Alleen andere Logic Apps en de HTTP-actie gebruikt om uw geneste werkstroom aan te roepen, wordt de aanroep geblokkeerd en krijgt u de foutmelding '401 Niet geautoriseerd'.

    • Voor scenario's waarin u binnenkomende aanroepen van andere IP-adressen wilt beperken, geeft u de IP-adresbereiken op die door de trigger worden geaccepteerd wanneer het VAK IP-bereiken voor triggers wordt weergegeven. Een geldig IP-bereik gebruikt deze indelingen: x.x.x.x/x of x.x.x.x.x.x.x.x

  4. Desgewenst kunt u onder Aanroepen beperken om invoer- en uitvoerberichten op te halen uit de uitvoeringsgeschiedenis naar de opgegeven IP-adressen, de IP-adresbereiken opgeven voor binnenkomende aanroepen die toegang hebben tot invoer- en uitvoerberichten in de uitvoeringsgeschiedenis.

Standaardwerkstromen

  1. Open uw logische app-resource in Azure Portal.

  2. Selecteer Netwerken in het menu van de logische app onder Instellingen.

  3. Selecteer toegangsbeperking in de sectie Inkomend verkeer.

  4. Maak een of meer regels om aanvragen van specifieke IP-bereiken toe te staan of te weigeren . U kunt ook de instellingen voor http-headerfilters en doorstuurinstellingen gebruiken. Een geldig IP-bereik gebruikt deze indelingen: x.x.x.x/x of x.x.x.x.x.x.x.x

    Zie Voor meer informatie het blokkeren van binnenkomende IP-adressen in Azure Logic Apps (Standard).

Toegang voor uitgaande aanroepen naar andere services en systemen

Op basis van de mogelijkheid van het doeleindpunt ondersteunen uitgaande aanroepen die worden verzonden door de HTTP-trigger of HTTP-actie versleuteling en worden beveiligd met TLS (Transport Layer Security) 1.0, 1.1 of 1.2, voorheen bekend als SSL (Secure Sockets Layer). Azure Logic Apps onderhandelt met het doeleindpunt over het gebruik van de hoogst mogelijke versie die wordt ondersteund. Als het doeleindpunt bijvoorbeeld 1.2 ondersteunt, gebruikt de HTTP-trigger of -actie eerst 1.2. Anders gebruikt de connector de volgende versie die het hoogst wordt ondersteund.

Deze lijst bevat informatie over zelfondertekende TLS/SSL-certificaten:

  • Voor werkstromen van logische apps voor verbruik in de omgeving met meerdere tenants van Azure Logic Apps zijn voor HTTP-bewerkingen geen zelfondertekende TLS/SSL-certificaten toegestaan. Als uw logische app een HTTP-aanroep naar een server uitvoert en een zelfondertekend TLS/SSL-certificaat weergeeft, mislukt de HTTP-aanroep met een TrustFailure fout.

  • Voor standaardwerkstromen voor logische apps in de Azure Logic Apps-omgeving met één tenant ondersteunen HTTP-bewerkingen zelfondertekende TLS/SSL-certificaten. U moet echter een paar extra stappen uitvoeren voor dit verificatietype. Anders mislukt de aanroep. Raadpleeg TLS/SSL-certificaatverificatie voor Azure Logic Apps met één tenant voor meer informatie.

    Als u in plaats daarvan clientcertificaat of OAuth wilt gebruiken met Microsoft Entra-id met het certificaatreferentietype , moet u nog enkele extra stappen uitvoeren voor dit verificatietype. Anders mislukt de aanroep. Zie Clientcertificaat of OAuth met Microsoft Entra ID met het referentietype Certificaat voor Azure Logic Apps met één tenant voor meer informatie.

Hier volgen meer manieren waarop u eindpunten kunt beveiligen die oproepen verwerken die worden verzonden vanuit uw werkstromen voor logische apps:

  • Verificatie toevoegen aan uitgaande aanvragen.

    Wanneer u de HTTP-trigger of -actie gebruikt om uitgaande aanroepen te verzenden, kunt u verificatie toevoegen aan de aanvraag die door uw logische app wordt verzonden. U kunt bijvoorbeeld deze verificatietypen selecteren:

  • Beperk de toegang tot ip-adressen van de werkstroom van logische apps.

    Alle aanroepen naar eindpunten van werkstromen van logische apps zijn afkomstig van specifieke aangewezen IP-adressen die zijn gebaseerd op de regio's van uw logische apps. U kunt filteren toevoegen die alleen aanvragen van deze IP-adressen accepteert. Als u deze IP-adressen wilt ophalen, bekijkt u Limieten en configuratie voor Azure Logic Apps.

  • Verbeter de beveiliging voor verbindingen met on-premises systemen.

    Azure Logic Apps biedt integratie met deze services om veiligere en betrouwbare on-premises communicatie te bieden.

    • On-premises gegevensgateway

      Veel beheerde connectors in Azure Logic Apps maken beveiligde verbindingen met on-premises systemen mogelijk, zoals Bestandssysteem, SQL, SharePoint en DB2. De gateway verzendt gegevens van on-premises bronnen op versleutelde kanalen via Azure Service Bus. Al het verkeer is afkomstig als beveiligd uitgaand verkeer van de gatewayagent. Meer informatie over hoe de on-premises gegevensgateway werkt.

    • Verbinding maken via Azure API Management

      Azure API Management biedt on-premises verbindingsopties, zoals site-naar-site virtueel particulier netwerk en ExpressRoute-integratie voor beveiligde proxy en communicatie met on-premises systemen. Als u een API hebt die toegang biedt tot uw on-premises systeem en u die API beschikbaar hebt gemaakt door een API Management-service-exemplaar te maken, kunt u die API aanroepen vanuit de werkstroom van uw logische app door de bijbehorende API Management-bewerking te selecteren in de werkstroomontwerper.

      Notitie

      De connector toont alleen de API Management-services waarvoor u gemachtigd bent om API Management-services weer te geven en er verbinding mee te maken, maar geen API Management-services op basis van verbruik.

      Volg de bijbehorende stappen op basis van het resourcetype van uw logische app:

      Werkstromen voor verbruik

      1. Volg deze stappen op basis van of u een API Management-trigger of -actie toevoegt:

        • Trigger:

          1. Selecteer een trigger toevoegen in de werkstroomontwerper.

          2. Nadat het deelvenster Een trigger toevoegen is geopend, voert u IN het zoekvak API Management in.

          3. Selecteer een Azure API Management-trigger kiezen in de lijst met triggerresultaten.

        • Actie:

          1. Selecteer in de werkstroomontwerper het plusteken (+) waaraan u de actie wilt toevoegen.

          2. Nadat het deelvenster Een actie toevoegen is geopend, voert u IN het zoekvak API Management in.

          3. Selecteer een Azure API Management-actie kiezen in de lijst met actieresultaten.

        In het volgende voorbeeld ziet u hoe u een Azure API Management-trigger kunt vinden:

        Schermopname van De Azure-portal, de ontwerpfunctie voor verbruikswerkstromen en het vinden van een API Management-trigger.

      2. Selecteer in de lijst met API Management-service-exemplaren uw eerder gemaakte API Management-service-exemplaar.

      3. Selecteer in de lijst met API-bewerkingen de API-bewerking die u wilt aanroepen en selecteer vervolgens Actie toevoegen.

      Standaardwerkstromen

      Voor Standaardwerkstromen kunt u alleen API Management-acties toevoegen, niet triggers.

      1. Selecteer in de werkstroomontwerper het plusteken (+) waaraan u de actie wilt toevoegen.

      2. Nadat het deelvenster Een actie toevoegen is geopend, voert u IN het zoekvak API Management in.

      3. Selecteer een Azure API Management-API aanroepen in de lijst met actieresultaten.

        Schermopname van de actie Azure Portal, Standard Workflow Designer en Azure API Management.

      4. Selecteer in de lijst met API Management-service-exemplaren uw eerder gemaakte API Management-service-exemplaar.

      5. Selecteer in de lijst met API-bewerkingen de API-bewerking die u wilt aanroepen en selecteer vervolgens Nieuwe maken.

        Schermopname van De Azure-portal, de standaardwerkstroomontwerper en de geselecteerde API die moet worden aangeroepen.

Verificatie toevoegen aan uitgaande oproepen

HTTP- en HTTPS-eindpunten ondersteunen verschillende soorten verificatie. Op sommige triggers en acties die u gebruikt voor het verzenden van uitgaande aanroepen of aanvragen naar deze eindpunten, kunt u een verificatietype opgeven. In de werkstroomontwerper hebben triggers en acties die ondersteuning bieden voor het kiezen van een verificatietype een verificatie-eigenschap . Deze eigenschap wordt echter mogelijk niet altijd standaard weergegeven. In deze gevallen opent u bij de trigger of actie de lijst Nieuwe parameter toevoegen en selecteert u Verificatie.

Belangrijk

Als u gevoelige informatie wilt beveiligen die door uw logische app wordt verwerkt, gebruikt u beveiligde parameters en codeert u zo nodig gegevens. Raadpleeg Access voor parameterinvoer voor meer informatie over het gebruik en beveiligen van parameters.

Basisverificatie

Als de optie Basic beschikbaar is, geeft u deze eigenschapswaarden op:

Eigenschap (ontwerper) Eigenschap (JSON) Vereist Weergegeven als Beschrijving
Verificatie type Ja Basis Het te gebruiken verificatietype
Gebruikersnaam username Ja <gebruikersnaam> De gebruikersnaam voor het verifiëren van toegang tot het doelservice-eindpunt
Wachtwoord password Ja <password> Het wachtwoord voor het verifiëren van toegang tot het doelservice-eindpunt

Wanneer u beveiligde parameters gebruikt om gevoelige informatie te verwerken en te beveiligen, bijvoorbeeld in een Azure Resource Manager-sjabloon voor het automatiseren van de implementatie, kunt u expressies gebruiken voor toegang tot deze parameterwaarden tijdens runtime. In dit voorbeeld van de HTTP-actiedefinitie wordt de verificatie type opgegeven als Basic en wordt de functie parameters() gebruikt om de parameterwaarden op te halen:

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

Verificatie van clientcertificaten

Als de optie Clientcertificaat beschikbaar is, geeft u deze eigenschapswaarden op:

Eigenschap (ontwerper) Eigenschap (JSON) Vereist Weergegeven als Beschrijving
Verificatie type Ja Clientcertificaat
of
ClientCertificate		 Het verificatietype dat moet worden gebruikt. U kunt certificaten beheren met Azure API Management.

Opmerking: aangepaste connectors bieden geen ondersteuning voor verificatie op basis van certificaten voor zowel binnenkomende als uitgaande aanroepen.
Pfx pfx Ja <gecodeerde-pfx-file-content> De base64-gecodeerde inhoud uit een PFX-bestand (Personal Information Exchange)

Als u het PFX-bestand wilt converteren naar een base64-gecodeerde indeling, kunt u PowerShell 7 gebruiken door de volgende stappen uit te voeren:

1. Sla de certificaatinhoud op in een variabele:

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

2. Converteer de certificaatinhoud met behulp van de ToBase64String() functie en sla die inhoud op in een tekstbestand:

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

Probleemoplossing: Als u de cert mmc/PowerShell opdracht gebruikt, wordt deze fout mogelijk weergegeven:

Could not load the certificate private key. Please check the authentication certificate password is correct and try again.

Als u deze fout wilt oplossen, converteert u het PFX-bestand naar een PEM-bestand en vervolgens opnieuw met behulp van de openssl opdracht:

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

Daarna werkt de tekenreeks nu in Azure Logic Apps wanneer u de met base64 gecodeerde tekenreeks voor het zojuist geconverteerde PFX-bestand van het certificaat krijgt.
Wachtwoord password Nee <password-for-pfx-file> Het wachtwoord voor toegang tot het PFX-bestand

Notitie

Als u probeert te verifiëren met een clientcertificaat met behulp van OpenSSL, krijgt u mogelijk de volgende fout:

BadRequest: Could not load private key

Om deze fout op te lossen, volgt u deze stappen:

  1. Verwijder alle OpenSSL-exemplaren.
  2. Installeer OpenSSL versie 1.1.1t.
  3. Uw certificaat opnieuw toewijzen met behulp van de nieuwe update.
  4. Voeg het nieuwe certificaat toe aan de HTTP-bewerking bij het gebruik van clientcertificaatverificatie.

Wanneer u beveiligde parameters gebruikt om gevoelige informatie te verwerken en te beveiligen, bijvoorbeeld in een Azure Resource Manager-sjabloon voor het automatiseren van de implementatie, kunt u expressies gebruiken voor toegang tot deze parameterwaarden tijdens runtime. In dit voorbeeld van de HTTP-actiedefinitie wordt de verificatie type opgegeven als ClientCertificate en wordt de functie parameters() gebruikt om de parameterwaarden op te halen:

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

Belangrijk

Als u een standaardresource voor logische apps in Azure Logic Apps met één tenant hebt en u een HTTP-bewerking wilt gebruiken met een TSL/SSL-certificaat, clientcertificaat of Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) met het Certificate referentietype, moet u de extra installatiestappen voor dit verificatietype voltooien. Anders mislukt de aanroep. Raadpleeg verificatie in een omgeving met één tenant voor meer informatie.

Raadpleeg de volgende onderwerpen voor meer informatie over het beveiligen van services met behulp van clientcertificaatverificatie:

Microsoft Identity Platform

Op aanvraagtriggers kunt u Microsoft Identity Platform gebruiken om binnenkomende oproepen te verifiëren nadat u Microsoft Entra-autorisatiebeleid voor uw logische app hebt ingesteld. Geef de volgende eigenschapswaarden op voor alle andere triggers en acties die het verificatietype Active Directory OAuth bieden dat u wilt selecteren:

Eigenschap (ontwerper) Eigenschap (JSON) Vereist Weergegeven als Beschrijving
Verificatie type Ja Active Directory OAuth
of
ActiveDirectoryOAuth		 Het verificatietype dat moet worden gebruikt. Azure Logic Apps volgt momenteel het OAuth 2.0-protocol.
Autoriteit authority Nee <URL-for-authority-token-issuer> De URL voor de instantie die het toegangstoken levert, zoals https://login.microsoftonline.com/ voor globale Azure-serviceregio's. Raadpleeg microsoft Entra-verificatie-eindpunten voor andere nationale clouds : uw identiteitsinstantie kiezen.
Tenant tenant Ja <tenant-id> De tenant-id voor de Microsoft Entra-tenant
Publiek audience Ja <resource-to-authorize> De resource die u wilt gebruiken voor autorisatie, bijvoorbeeld https://management.core.windows.net/
Client ID clientId Ja <client-id> De client-id voor de app die autorisatie aanvraagt
Referentietype credentialType Ja Certificaat
of
Geheim		 Het referentietype dat de client gebruikt voor het aanvragen van autorisatie. Deze eigenschap en waarde worden niet weergegeven in de onderliggende definitie van uw logische app, maar bepaalt de eigenschappen die worden weergegeven voor het geselecteerde referentietype.
Geheim secret Ja, maar alleen voor het referentietype Geheim <clientgeheim> Het clientgeheim voor het aanvragen van autorisatie
Pfx pfx Ja, maar alleen voor het referentietype Certificaat <gecodeerde-pfx-file-content> De base64-gecodeerde inhoud uit een PFX-bestand (Personal Information Exchange)
Wachtwoord password Ja, maar alleen voor het referentietype Certificaat <password-for-pfx-file> Het wachtwoord voor toegang tot het PFX-bestand

Wanneer u beveiligde parameters gebruikt om gevoelige informatie te verwerken en te beveiligen, bijvoorbeeld in een Azure Resource Manager-sjabloon voor het automatiseren van de implementatie, kunt u expressies gebruiken voor toegang tot deze parameterwaarden tijdens runtime. In dit voorbeeld van de HTTP-actiedefinitie wordt de verificatie type opgegeven als ActiveDirectoryOAuth, het referentietype als Secreten wordt de functie parameters() gebruikt om de parameterwaarden op te halen:

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

Belangrijk

Als u een standaardresource voor logische apps in Azure Logic Apps met één tenant hebt en u een HTTP-bewerking wilt gebruiken met een TSL/SSL-certificaat, clientcertificaat of Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) met het Certificate referentietype, moet u de extra installatiestappen voor dit verificatietype voltooien. Anders mislukt de aanroep. Raadpleeg verificatie in een omgeving met één tenant voor meer informatie.

Onbewerkte verificatie

Als de optie Onbewerkt beschikbaar is, kunt u dit verificatietype gebruiken wanneer u verificatieschema's moet gebruiken die niet voldoen aan het OAuth 2.0-protocol. Met dit type maakt u handmatig de autorisatieheaderwaarde die u verzendt met de uitgaande aanvraag en geeft u die headerwaarde op in uw trigger of actie.

In het volgende voorbeeld ziet u een voorbeeldheader voor een HTTPS-aanvraag die het OAuth 1.0-protocol volgt:

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 verificatie ondersteunt de volgende eigenschapswaarden op:

Eigenschap (ontwerper) Eigenschap (JSON) Vereist Weergegeven als Beschrijving
Verificatie type Ja Onbewerkt Het te gebruiken verificatietype
Value value Ja <authorization-header-value> De waarde van de autorisatieheader die moet worden gebruikt voor verificatie

Wanneer u beveiligde parameters gebruikt om gevoelige informatie te verwerken en te beveiligen, bijvoorbeeld in een Azure Resource Manager-sjabloon voor het automatiseren van de implementatie, kunt u expressies gebruiken voor toegang tot deze parameterwaarden tijdens runtime. In dit voorbeeld van de HTTP-actiedefinitie wordt de verificatie type opgegeven als Rawen wordt de functie parameters() gebruikt om de parameterwaarden op te halen:

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

Verificatie van beheerde identiteit

Wanneer de optie beheerde identiteit beschikbaar is op de trigger of actie die ondersteuning biedt voor verificatie van beheerde identiteiten, kan uw logische app deze identiteit gebruiken voor het verifiëren van toegang tot Azure-resources die worden beveiligd door Microsoft Entra-id, in plaats van referenties, geheimen of Microsoft Entra-tokens. Azure beheert deze identiteit voor u en helpt u bij het beveiligen van uw referenties omdat u geen geheimen hoeft te beheren of rechtstreeks Microsoft Entra-tokens hoeft te gebruiken. Meer informatie over Azure-services die beheerde identiteiten ondersteunen voor Microsoft Entra-verificatie.

  • Een resource voor de logische app Verbruik kan de door het systeem toegewezen identiteit of één handmatig gemaakte door de gebruiker toegewezen identiteit gebruiken.

  • Een standaardresource voor logische apps biedt ondersteuning voor het tegelijkertijd toestaan van de door het systeem toegewezen beheerde identiteit en meerdere door de gebruiker toegewezen beheerde identiteiten , maar u kunt nog steeds maar één identiteit selecteren die u op elk gewenst moment kunt gebruiken.

    Notitie

    Standaard is de door het systeem toegewezen identiteit al ingeschakeld voor het verifiëren van verbindingen tijdens runtime. Deze identiteit verschilt van de verificatiereferenties of verbindingsreeks die u gebruikt wanneer u een verbinding maakt. Als u deze identiteit uitschakelt, werken verbindingen niet tijdens runtime. Als u deze instelling wilt weergeven, selecteert u Identiteit in het menu van uw logische app onder Instellingen.

  1. Voordat uw logische app een beheerde identiteit kan gebruiken, volgt u de stappen in Verificatietoegang tot Azure-resources met behulp van beheerde identiteiten in Azure Logic Apps. Met deze stappen schakelt u de beheerde identiteit in uw logische app in en stelt u de toegang van die identiteit tot de Azure-doelresource in.

  2. Voordat een Azure-functie een beheerde identiteit kan gebruiken, moet u eerst verificatie voor Azure-functies inschakelen.

  3. Geef in de trigger of actie die ondersteuning biedt voor het gebruik van een beheerde identiteit deze informatie op:

    Ingebouwde triggers en acties

    Eigenschap (ontwerper) Eigenschap (JSON) Vereist Weergegeven als Beschrijving
    Verificatie type Ja Beheerde identiteit
    of
    ManagedServiceIdentity    		 Het te gebruiken verificatietype
    Beheerde identiteit identity Nee <door de gebruiker toegewezen identiteit-id> De door de gebruiker toegewezen beheerde identiteit die moet worden gebruikt. Opmerking: neem deze eigenschap niet op wanneer u de door het systeem toegewezen beheerde identiteit gebruikt.
    Publiek audience Ja <target-resource-ID> De resource-id voor de doelresource waartoe u toegang wilt krijgen.

    Maakt bijvoorbeeld https://storage.azure.com/ de toegangstokens voor verificatie geldig voor alle opslagaccounts. U kunt echter ook een BASISservice-URL opgeven, zoals https://fabrikamstorageaccount.blob.core.windows.net voor een specifiek opslagaccount.

    Opmerking: De eigenschap Doelgroep is mogelijk verborgen in bepaalde triggers of acties. Als u deze eigenschap zichtbaar wilt maken, opent u in de trigger of actie de lijst Nieuwe parameters toevoegen en selecteert u Doelgroep.

    Belangrijk: zorg ervoor dat deze doelresource-id exact overeenkomt met de waarde die microsoft Entra-id verwacht, inclusief eventuele vereiste afsluitende slashes. https://storage.azure.com/ De resource-id voor alle Azure Blob Storage-accounts vereist dus een afsluitende slash. Voor de resource-id voor een specifiek opslagaccount is echter geen afsluitende slash vereist. Als u deze resource-id's wilt vinden, bekijkt u De Azure-services die Ondersteuning bieden voor Microsoft Entra-id.

    Wanneer u beveiligde parameters gebruikt om gevoelige informatie te verwerken en te beveiligen, bijvoorbeeld in een Azure Resource Manager-sjabloon voor het automatiseren van de implementatie, kunt u expressies gebruiken voor toegang tot deze parameterwaarden tijdens runtime. Deze HTTP-actiedefinitie geeft bijvoorbeeld de verificatie type op als ManagedServiceIdentity en gebruikt de functie parameters() om de parameterwaarden op te halen:

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

    Triggers en acties voor beheerde connectors

    Eigenschap (ontwerper) Vereist Weergegeven als Beschrijving
    Verbindingsnaam Ja <verbindingsnaam>
    Beheerde identiteit Ja Door het systeem toegewezen beheerde identiteit
    of
    <door de gebruiker toegewezen beheerde identiteit-naam>    		 Het te gebruiken verificatietype

Blok dat verbindingen maakt

Als uw organisatie geen verbinding met specifieke resources toestaat met behulp van hun connectors in Azure Logic Apps, kunt u de mogelijkheid blokkeren om deze verbindingen te maken voor specifieke connectors in werkstromen voor logische apps met behulp van Azure Policy. Raadpleeg verbindingen blokkeren die zijn gemaakt door specifieke connectors in Azure Logic Apps voor meer informatie.

Isolatierichtlijnen voor logische apps

U kunt Azure Logic Apps in Azure Government gebruiken die alle impactniveaus ondersteunen in de regio's die worden beschreven in de richtlijnen voor isolatie op azure Government Impact Level 5. Om aan deze vereisten te voldoen, ondersteunt Azure Logic Apps de mogelijkheid om werkstromen te maken en uit te voeren in een omgeving met toegewezen resources, zodat u de invloed van de prestaties door andere Azure-tenants op uw logische apps kunt verminderen en geen rekenresources kunt delen met andere tenants.

Raadpleeg de volgende documentatie voor meer informatie over isolatie:

Volgende stappen