Beveiligde toegang en gegevens voor werkstromen in Azure Logic Apps

Artikel
10/15/2024

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:

Toegang tot bewerkingen van logische apps
Toegang tot invoer en uitvoer van uitvoeringsgeschiedenis
Toegang tot parameterinvoer
Verificatietypen voor triggers en acties die ondersteuning bieden voor verificatie
Toegang voor inkomende aanroepen naar triggers op basis van aanvragen
Toegang voor uitgaande aanroepen naar andere services en systemen
Het maken van verbindingen voor specifieke connectors blokkeren
Isolatierichtlijnen voor logische apps
Azure-beveiligingsbasislijn voor Azure Logic Apps

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 de verbindingsconfiguratie in Azure Logic Apps en verbindingsbeveiliging 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:

Beperk de toegang per IP-adresbereik.

Met deze optie kunt u de toegang tot de uitvoeringsgeschiedenis beveiligen op basis van de aanvragen van een specifiek IP-adresbereik.
Beveilig gegevens in de uitvoeringsgeschiedenis met behulp van verdoofing.

In veel triggers en acties kunt u de invoer, uitvoer of beide in de uitvoeringsgeschiedenis van een logische app beveiligen.

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 uw logische app Verbruik of Standard in Azure Portal of uw Azure Resource Manager-sjabloon:

Portal
Resource Manager-sjabloon

Werkstromen voor verbruik

Open in Azure Portal uw werkstroom voor logische verbruiks-apps in de ontwerpfunctie.
Selecteer werkstroominstellingen in het menu van de logische app onder Instellingen.
Selecteer in de sectie Configuratie van toegangsbeheer onder Toegestane binnenkomende IP-adressen in de lijst met opties voor triggertoegang specifieke IP-bereiken.
Geef in het vak IP-bereiken voor inhoud de IP-adresbereiken op die toegang hebben tot inhoud van invoer en uitvoer.

Standaardwerkstromen

Open uw resource voor de logische standaard-app in Azure Portal.
Selecteer Netwerken in het menu van de logische app onder Instellingen.
Selecteer in de sectie Voor binnenkomend verkeer, naast openbare netwerktoegang, ingeschakeld zonder toegangsbeperking.
Selecteer op de pagina Toegangsbeperkingen onder App-toegang de optie Ingeschakeld in de geselecteerde virtuele netwerken en IP-adressen.
Voeg onder Sitetoegang en -regels op het tabblad Hoofdsite een of meer regels toe 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).

Werkstromen voor verbruik

Geef in uw ARM-sjabloon de IP-bereiken op met behulp van de accessControl sectie met de sectie in de contents resourcedefinitie van uw logische app, bijvoorbeeld:

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

Standaardwerkstromen

Geef in uw ARM-sjabloon de toegestane binnenkomende IP-adresbereiken op in de resourcedefinitie van uw logische app met behulp van de Microsoft.Web/sites/config sectie. Voeg in deze sectie onder propertiesde sectie de ipSecurityRestrictions sectie toe en gebruik de ipAddress, action="Deny" | "Allow", tag=Default, en priorityname="Ports" secties om een regel te definiëren en het ipAddress toegestane IP-bereik in x.x.x.x/x of x.x.x.x.x.x.x.x, bijvoorbeeld:

{
   "type": "Microsoft.Web/sites/config",
   "apiVersion": "2022-09-01",
   "name": "[concat(parameters('sites_My_Standard_Logic_App_name'), '/web')]",
   "location": "West US",
   "dependsOn": [
      "[resourceId('Microsoft.Web/sites', parameters('sites_My_Standard_Logic_App_name'))]"
   ],
   "tags": {
      "hidden-link: /app-insights-resource-id": "/subscriptions/{subscriptionID}/resourceGroups/Standard-RG/providers/Microsoft.Insights/components/My-Standard-Logic-App"
   },
   "properties": {
      "numberOfWorkers": 1,
      "defaultDocuments": [
         "Default.htm",
         "Default.html",
         "Default.asp",
         "index.htm",
         "index.html",
         "iisstart.htm",
         "default.aspx",
         "index.php"
      ],
      "netFrameworkVersion": "v6.0",
      "requestTracingEnabled": false,
      "remoteDebuggingEnabled": false,
      "httpLoggingEnabled": false,
      "acrUseManagedIdentityCreds": false,
      "logsDirectorySizeLimit": 35,
      "detailedErrorLoggingEnabled": false,
      "publishingUsername": "$My-Standard-Logic-App",
      "scmType": "None",
      "use32BitWorkerProcess": false,
      "webSocketsEnabled": false,
      "alwaysOn": false,
      "managedPipelineMode": "Integrated",
      "virtualApplications": [
         {
            "virtualPath": "/",
            "physicalPath": "site\\wwwroot",
            "preloadEnabled": false
         }
      ],
      "loadBalancing": "LeastRequests",
      "experiments": {
         "rampUpRules": []
      },
      "autoHealEnabled": false,
      "vnetRouteAllEnabled": false,
      "vnetPrivatePortsCount": 0,
      "publicNetworkAccess": "Enabled",
      "cors": {
         "supportCredentials": false
      },
      "localMySqlEnabled": false,
      "managedServiceIdentityId": 3065,
      "ipSecurityRestrictions": [
         {
            "ipAddress": "208.130.0.0/16",
            "action": "Deny",
            "tag": "Default",
            "priority": 100,
            "name": "Ports"
         },
         {
            "ipAddress": "Any",
            "action": "Deny",
            "priority": 2147483647,
            "name": "Deny all",
            "description": "Deny all access"
         }
      ],
      "ipSecurityRestrictionsDefaultAction": "Deny",
      "scmIpSecurityRestrictions": [
         {
            "ipAddress": "Any",
            "action": "Allow",
            "priority": 2147483647,
            "name": "Allow all",
            "description": "Allow all access"
         }
      ],
      "scmIpSecurityRestrictionsDefaultAction": "Allow",
      "scmIpSecurityRestrictionsUseMain": false,
      "http20Enabled": false,
      "minTlsVersion": "1.2",
      "scmMinTlsVersion": "1.2",
      "ftpsState": "FtpsOnly",
      "preWarmedInstanceCount": 1,
      "functionAppScaleLimit": 0,
      "functionsRuntimeScaleMonitoringEnabled": true,
      "minimumElasticInstanceCount": 1,
      "azureStorageAccounts": {}
   }
},

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 bewerkingen bieden 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 Terugkeerpatroon Draagwijdte Variabele instellen Schakelaar Beëindigen Until	Toevoegen aan matrixvariabele Toevoegen aan tekenreeksvariabele Componeren Variabele voor verlagen Voor elke Als Incrementele variabele Variabele initialiseren JSON parseren Terugkeerpatroon Antwoord Draagwijdte Variabele instellen Schakelaar Beëindigen Totdat 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.

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.

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 Beveiligde invoer in deze actie niet in en verbergt de uitvoer van deze actie niet.

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.

Invoer en uitvoer beveiligen in de ontwerpfunctie

Open uw werkstroom voor logische apps in Azure Portal in de ontwerpfunctie.
Selecteer in de ontwerpfunctie de trigger of actie waar u gevoelige gegevens wilt beveiligen.
Selecteer Instellingen in het informatievenster dat wordt geopend en vouw Beveiliging uit.
Schakel Beveiligde invoer, beveiligde uitvoer of beide in.

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

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:

Beveiligde parameters in werkstroomdefinities
Gegevens in de uitvoeringsgeschiedenis beveiligen met behulp van verdoofing

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:

Gevoelige waarden doorgeven bij de implementatie met behulp van Azure Key Vault
Beveiligingsparameters in Azure Resource Manager-sjablonen verderop in dit onderwerp

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.

Belangrijk

Voor optimale beveiliging raadt Microsoft aan om Microsoft Entra ID met beheerde identiteiten te gebruiken voor verificatie, indien mogelijk. Deze optie biedt superieure beveiliging zonder referenties op te geven. Azure beheert deze identiteit en helpt verificatiegegevens veilig te houden, zodat u deze gevoelige informatie niet hoeft te beheren. Zie Toegang en verbindingen met Azure-resources verifiëren met beheerde identiteiten in Azure Logic Apps om een beheerde identiteit in te stellen voor Azure Logic Apps.

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

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.

Belangrijk

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 Service, HTTP, HTTP + Swagger, HTTP Webhook
Clientcertificaat	Azure API Management, Azure-app Service, HTTP, HTTP + Swagger, HTTP Webhook
Active Directory OAuth (OAuth 2.0 met Microsoft Entra-id)	- Verbruik: Azure API Management, Azure-app Service, Azure Functions, HTTP, HTTP + Swagger, HTTP-webhook - Standard: Azure Automation, Azure Blob Storage, Azure Event Hubs, Azure Queues, Azure Service Bus, Azure Tables, HTTP, HTTP, HTTP Webhook, SQL Server
Rauw	Azure API Management, Azure-app Service, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
Beheerde identiteit	Ingebouwde connectors: - Verbruik: Azure API Management, Azure-app Service, 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

Belangrijk

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 een aanvraagtrigger of een callback naar de HTTP-webhooktrigger of -actie.

Notitie

Als u TLS-handshake-fouten krijgt, moet u TLS 1.2 gebruiken. Zie Het TLS 1.0-probleem oplossen 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

Belangrijk

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-handshakeberichten in Azure Logic Apps inspecteert 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 manieren waarop u de toegang kunt beperken tot triggers die binnenkomende aanroepen naar uw werkstroom voor logische apps ontvangen, zodat alleen geautoriseerde clients uw werkstroom kunnen aanroepen:

OAuth inschakelen met Microsoft Entra-id
Sas-sleutels (Shared Access Signature) of tokens genereren
Sas-verificatie (Shared Access Signature) uitschakelen
Binnenkomende IP-adressen beperken
Uw logische app beschikbaar maken met Azure API Management

OAuth 2.0 inschakelen met Microsoft Entra-id

In een verbruikswerkstroom die begint met een trigger op basis van aanvragen, kunt u binnenkomende aanroepen verifiëren en autoriseren die zijn verzonden naar het eindpunt dat door die trigger is gemaakt door OAuth 2.0 in te schakelen met Microsoft Entra-id. Als u deze verificatie wilt instellen, definieert of voegt u een autorisatiebeleid toe op resourceniveau 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 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 is gemaakt door de aanvraagtrigger met behulp van een beheerde identiteit. Deze inrichting wordt ook wel 'Easy Auth' genoemd. Zie Werkstromen activeren in Standaard logische apps met Easy Auth voor meer informatie.

Overwegingen voordat u OAuth 2.0 inschakelt met Microsoft Entra-id

Voor optimale beveiliging raadt Microsoft aan om Microsoft Entra ID met beheerde identiteiten te gebruiken voor verificatie, indien mogelijk. Deze optie biedt superieure beveiliging zonder referenties op te geven. Azure beheert deze identiteit en helpt verificatiegegevens veilig te houden, zodat u deze gevoelige informatie niet hoeft te beheren. Zie Toegang en verbindingen met Azure-resources verifiëren met beheerde identiteiten in Azure Logic Apps om een beheerde identiteit in te stellen voor Azure Logic Apps.
In verbruikswerkstromen kunnen binnenkomende aanroepen naar de eindpunt-URL voor een trigger op basis van aanvragen slechts één autorisatieschema gebruiken, ofwel OAuth 2.0 met Microsoft Entra-id of Shared Access Signature (SAS). Hoewel het gebruik van een schema het andere schema niet uitschakelt, genereert Azure Logic Apps een fout als u beide schema's tegelijk gebruikt, omdat de service niet weet welk schema u moet kiezen. Als uw werkstroom Verbruik begint met de aanvraagtrigger , kunt u SAS-verificatie uitschakelen en autorisatie beperken om alleen OAuth 2.0 te gebruiken met Microsoft Entra-id. Voor Standaardwerkstromen kunt u andere verificatietypen gebruiken zonder SAS uit te schakelen.
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.
De resource van de logische app Verbruik is beperkt tot een maximum aantal autorisatiebeleidsregels. Elk autorisatiebeleid heeft ook een maximum aantal claims. Zie Informatie over 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 verlener voor Microsoft Entra-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": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
    "unique_name": "SophiaOwen@fabrikam.com",
    "upn": "SophiaOwen@fabrikam.com",
    "uti": "TPJ7nNNMMZkOSx6_uVczUAA",
    "ver": "1.0"
}

OAuth 2.0 met Microsoft Entra-id inschakelen als enige optie om een aanvraageindpunt aan te roepen (alleen verbruik)

Voor eindpunten op basis van aanvragen kunt u de autorisatie beperken om alleen OAuth 2.0 te gebruiken met Microsoft Entra-id. Deze optie werkt zelfs als u ook SAS-verificatie (Shared Access Signature) uitschakelt.

Voor uw verbruikswerkstroom stelt u de aanvraagtrigger of HTTP-webhooktrigger in met de mogelijkheid om het OAuth-toegangstoken te controleren door de stappen te volgen om de header Autorisatie 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.
Open in Azure Portal uw werkstroom Verbruik in de ontwerpfunctie.
Selecteer de trigger in de ontwerpfunctie. Selecteer Instellingen in het informatievenster dat wordt geopend.
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 Verbruik 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 stappen voor het instellen van OAuth met Microsoft Entra-id.

OAuth inschakelen met Microsoft Entra-id voor de resource van de logische app Verbruik

Als u een autorisatiebeleid wilt toevoegen aan uw logische app Verbruik, volgt u de stappen voor de Azure-portal of de Azure Resource Manager-sjabloon:

Portal
Resource Manager-sjabloon

Open in Azure Portal uw logische app voor verbruik en werkstroom in de ontwerpfunctie.
Selecteer Autorisatie in het menu van de logische app onder Instellingen.
Selecteer Beleid toevoegen op de pagina Autorisatie.

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 :

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 - Audiëntie - 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:

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": "aaaabbbb-0000-cccc-1111-dddd2222eeee".
Als u nog een autorisatiebeleid wilt toevoegen, selecteert u Beleid toevoegen. Herhaal de vorige stappen om het beleid in te stellen.
Selecteer Opslaan als u klaar bent.
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.

Definieer in uw ARM-sjabloon een autorisatiebeleid volgens deze stappen en syntaxis hieronder:

Voeg in de sectie voor de properties resourcedefinitie van uw logische app een accessControl object toe, als er geen bestaat, dat een triggers object bevat.

Raadpleeg voor meer informatie over het accessControl object binnenkomende IP-bereiken beperken in azure Resource Manager-sjabloon en naslaginformatie over microsoft.logic-werkstromen.
Voeg in het triggers object een openAuthenticationPolicies object toe dat het policies object bevat waarin u een of meer autorisatiebeleidsregels definieert.
Geef een naam op voor autorisatiebeleid, stel het beleidstype AADin op en neem een matrix op waarin u een claims of meer claimtypen opgeeft.

De matrix moet minimaal claims het claimtype Verlener bevatten waarop u de eigenschap van name de claim instelt en de value waarde iss instelt om te beginnen met https://sts.windows.net/ of https://login.microsoftonline.com/ als de id van de Microsoft Entra-uitgever. Zie Claims in Microsoft Entra-beveiligingstokens voor meer informatie over deze claimtypen. U kunt ook uw eigen claimtype en -waarde opgeven.
Zie Autorisatieheader opnemen in uitvoer van aanvraagtriggers om de header van het Authorization toegangstoken op te nemen in de uitvoer van de aanvraagtrigger.

Dit is de syntaxis die u moet volgen:

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

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:

Een SAS-sleutel (Shared Access Signature) of -token genereren

Wanneer een werkstroom begint met een trigger op basis van aanvragen en u die werkstroom voor het eerst opslaat, maakt Azure Logic Apps een aanroepbaar eindpunt op die trigger. Dit eindpunt heeft een URL die binnenkomende oproepen of aanvragen kan ontvangen om de werkstroom te starten. De URL bevat een Shared Access Signature (SAS), een sleutel of token die bijvoorbeeld machtigingen verleent aan opslagservices. Deze eindpunt-URL maakt gebruik van de volgende indeling:

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

Als u deze URL bijvoorbeeld wilt weergeven in een aanvraagtrigger, zoekt u de HTTP-URL-eigenschap van de trigger:

Schermopname van De Azure-portal, de ontwerpfunctie voor verbruikswerkstromen en de eindpunt-URL van de aanvraagtrigger.

De volledige URL ziet eruit als in het volgende voorbeeld:

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

De SAS in de URL heeft queryparameters, die in de volgende tabel worden beschreven:

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 geheim gehouden en versleuteld, 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.

Belangrijk

Zorg ervoor dat u uw SAS-sleutel beveiligt, net zoals u een accountsleutel beveiligt tegen onbevoegd gebruik. Stel een plan in of heb een plan voor het intrekken van een gecompromitteerde toegangssleutel. Gebruik discretie wanneer u URI's distribueert die gebruikmaken van toegangssleutels en distribueer deze URI's alleen via een beveiligde verbinding, zoals HTTPS. Zorg ervoor dat u alleen bewerkingen uitvoert die gebruikmaken van een toegangssleutel via een HTTPS-verbinding. Iedereen met een URI met een geldige sleutel heeft toegang tot de bijbehorende resource. Als u de beveiliging wilt behouden en de toegang tot de werkstroom van uw logische app wilt beveiligen, genereert u regelmatig toegangssleutels , omdat ze mogelijk moeten voldoen aan beveiligingsbeleid of dat ze gecompromitteerd moeten worden. Op deze manier kunt u ervoor zorgen dat alleen geautoriseerde aanvragen uw werkstroom kunnen activeren, waardoor uw gegevens en processen worden beschermd tegen onbevoegde toegang.

Als u een SAS-sleutel gebruikt voor toegang tot opslagservices, raadt Microsoft u aan een SAS voor gebruikersdelegatie te maken, die is beveiligd met Microsoft Entra-id, in plaats van een accountsleutel.

Voor optimale beveiliging raadt Microsoft aan om Microsoft Entra ID te gebruiken met beheerde identiteiten voor verificatie, indien mogelijk. Deze optie biedt superieure beveiliging zonder referenties op te geven. Azure beheert deze identiteit en helpt verificatiegegevens veilig te houden, zodat u deze gevoelige informatie niet hoeft te beheren. Zie Toegang en verbindingen met Azure-resources verifiëren met beheerde identiteiten in Azure Logic Apps om een beheerde identiteit in te stellen voor Azure Logic Apps.

Binnenkomende aanroepen naar het eindpunt op een aanvraagtrigger kunnen slechts één autorisatieschema gebruiken, SAS of OAuth 2.0 met Microsoft Entra-id. Hoewel het gebruik van een schema het andere niet uitschakelt, genereert Azure Logic Apps een fout als u beide schema's tegelijk gebruikt, omdat de service niet weet welk schema u moet kiezen.

Als u een werkstroom Verbruik hebt die begint met de aanvraagtrigger , kunt u SAS-verificatie uitschakelen. Deze optie werkt zelfs als u ook autorisatie beperkt om alleen OAuth 2.0 te gebruiken met Microsoft Entra-id. Voor Standaardwerkstromen kunt u andere verificatietypen gebruiken zonder SAS uit te schakelen.

Zie de volgende secties in deze handleiding voor meer informatie over beveiliging wanneer u een SAS-sleutel gebruikt:

Toegangssleutels opnieuw genereren
Verlopende callback-URL's maken
URL's maken met primaire of secundaire sleutel

Sas-verificatie (Shared Access Signature) uitschakelen (alleen verbruik)

Voor een op aanvragen gebaseerde trigger is standaard SAS-verificatie ingeschakeld. De eindpunt-URL van de trigger bevat een SAS, te beginnen met de queryparameters, sp-<permissions>sv-<SAS-version>sig=<signature>bijvoorbeeld:

Als uw verbruikswerkstroom begint met de aanvraagtrigger en u OAuth wilt gebruiken met Microsoft Entra-id, kunt u SAS-verificatie uitschakelen om fouten en problemen met het uitvoeren van uw werkstroom te voorkomen. U voegt ook een beveiligingslaag toe door de afhankelijkheid van geheimen te verwijderen, wat het risico vermindert dat geheimen zijn geregistreerd of gelekt.

Deze optie werkt zelfs als u OAuth 2.0 ook inschakelt met Microsoft Entra-id als enige optie om een op aanvragen gebaseerd eindpunt aan te roepen. Voor Standaardwerkstromen kunt u andere verificatietypen gebruiken zonder SAS uit te schakelen.

Notitie

Met deze actie wordt SAS-verificatie uitgeschakeld voor binnenkomende aanvragen en wordt voorkomen dat bestaande SAS-sleutels of handtekeningen werken. Uw SAS-sleutels of handtekeningen blijven echter geldig en werken nog steeds als u SAS-verificatie opnieuw inschakelt. Zie Toegangssleutels opnieuw genereren om SAS-sleutels en handtekeningen uit te schakelen door nieuwe versies te maken.

Nadat u SAS-verificatie hebt uitgeschakeld, bevat de eindpunt-URL voor de aanvraagtrigger bijvoorbeeld niet meer de SAS-sleutel:

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01

Vereisten

Voor deze taak hebt u een hulpprogramma nodig om REST API-aanroepen te verzenden, bijvoorbeeld:

Let op

Voor scenario's waarin u gevoelige gegevens hebt, zoals referenties, geheimen, toegangstokens, API-sleutels en andere vergelijkbare informatie, moet u een hulpprogramma gebruiken waarmee uw gegevens worden beveiligd met de benodigde beveiligingsfuncties, offline of lokaal werken, uw gegevens niet worden gesynchroniseerd met de cloud en u zich niet hoeft aan te melden bij een onlineaccount. Op deze manier vermindert u het risico dat gevoelige gegevens openbaar worden gemaakt voor het publiek.

Controleren op triggers waarvoor SAS is ingeschakeld of uitgeschakeld

Wanneer SAS-verificatie is uitgeschakeld, bevat de eindpunt-URL van de trigger de SAS-sleutel niet meer. De definitie van de verbruikswerkstroom bevat ook het JSON-object sasAuthenticationPolicy . Dit object heeft een statuseigenschap die is ingesteld op Uitgeschakeld, bijvoorbeeld:

"properties": {
    "accessControl": {
        "triggers": {
            "sasAuthenticationPolicy": {
                "state": "Disabled"
            }
        }
    }
}

Als u wilt zoeken naar verbruikswerkstromen waarvoor SAS is ingeschakeld of uitgeschakeld, controleert u of de werkstroomdefinitie het sasAuthenticationPolicy-object bevat waarvoor de statuseigenschap is ingesteld op Uitgeschakeld.

Met uw hulpprogramma waarmee REST API-aanroepen worden verzonden, haalt u informatie over uw werkstroom op door de werkstromen - Bewerking ophalen uit te voeren met behulp van de volgende GET-aanvraag, bijvoorbeeld:

GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Neem de uitvoer van de werkstromen - Get-bewerking en controleer of het object sasAuthenticationPolicy bestaat als de statuseigenschap is ingesteld op Uitgeschakeld.

De eigenschap sasAuthenticationPolicy toevoegen aan uw werkstroomdefinitie

Voer de volgende stappen uit voor verbruikswerkstromen waarvoor u SAS-verificatie wilt uitschakelen:

Als u dit nog niet hebt gedaan, haalt u informatie over uw werkstroom op door de werkstromen uit te voeren: bewerking ophalen met behulp van de volgende GET-aanvraag, bijvoorbeeld:

GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Neem de uitvoer van de werkstromen - Get-bewerking en voeg handmatig de volgende elementen toe:
1. Voeg in het properties object een accessControl object toe dat een triggers object bevat, als er geen object bestaat.
2. Voeg in het triggers object een sasAuthenticationPolicy object toe dat de state eigenschap bevat die is ingesteld op Disabled.
Wanneer u klaar bent, ziet het bewerkte gedeelte eruit als in het volgende voorbeeld:
```
"properties": {
    "accessControl": {
        "triggers": {
            "sasAuthenticationPolicy": {
                "state": "Disabled"
            }
        }
    }
}
```
Verzend een andere aanvraag om uw werkstroom bij te werken met de bewerkte uitvoer, die u als invoer in de aanvraagtekst gebruikt, door de werkstromen - Updatebewerking uit te voeren met behulp van de volgende PATCH-aanvraag, bijvoorbeeld:

PATCH https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Ga in Azure Portal naar uw werkstroom Verbruik in de ontwerpfunctie en controleer of de URL van de aanvraagtrigger de SAS niet meer bevat.
Als u Oauth 2.0 wilt inschakelen met Microsoft Entra ID, voegt u op resourceniveau van de logische app een autorisatiebeleid toe voor OAuth met Microsoft Entra-id.

Zie OAuth 2.0 inschakelen met Microsoft Entra-id voor meer informatie.

Toegangssleutels regenereren

Als u de beveiliging wilt behouden en de toegang tot de werkstroom van uw logische app wilt beveiligen, genereert u regelmatig toegangssleutels, omdat ze mogelijk moeten voldoen aan beveiligingsbeleid of dat ze gecompromitteerd moeten worden. Op deze manier kunt u ervoor zorgen dat alleen geautoriseerde aanvragen uw werkstroom kunnen activeren, waardoor uw gegevens en processen worden beschermd tegen onbevoegde toegang.

Als u op elk gewenst moment een nieuwe toegangssleutel wilt genereren, gebruikt u de Azure REST API of Azure Portal. Alle eerder gegenereerde URI's of URL's die gebruikmaken van de oude sleutel, zijn ongeldig en hebben geen autorisatie meer om uw werkstroom voor logische apps te activeren. De URI's die u na regeneratie ophaalt, worden ondertekend met de nieuwe toegangssleutel.

Open in Azure Portal de resource van de logische app die gebruikmaakt van de sleutel die u opnieuw wilt genereren.
Selecteer toegangssleutels in het resourcemenu van de logische app onder Instellingen.
Selecteer de sleutel die u opnieuw wilt genereren en voltooi het proces.

Belangrijk

Zorg ervoor dat u uw toegangssleutel beveiligt, net zoals u een accountsleutel beveiligt tegen onbevoegd gebruik. Stel een plan in of heb een plan voor het intrekken van een gecompromitteerde toegangssleutel. Gebruik discretie wanneer u URI's distribueert die gebruikmaken van toegangssleutels en distribueer deze URI's alleen via een beveiligde verbinding, zoals HTTPS. Zorg ervoor dat u alleen bewerkingen uitvoert die gebruikmaken van een toegangssleutel via een HTTPS-verbinding. Iedereen met een URI met een geldige sleutel heeft toegang tot de bijbehorende resource.

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/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01

Neem in de hoofdtekst de NotAfter eigenschap 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 Azure Logic Apps, bijvoorbeeld:

POST /subscriptions/{subscription-ID}/resourceGroups/{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.

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 een aanvraag heeft met behulp van de werkstroomtriggers - bewerkingsaanvraag uitvoeren of met 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

Portal
Resource Manager-sjabloon

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 werkstroom - Bewerking maken of bijwerken in de REST API van Azure Logic Apps.

Werkstromen voor verbruik

Open uw logische app Verbruik in Azure Portal in de ontwerpfunctie voor werkstromen.
Selecteer werkstroominstellingen in het menu van de logische app onder Instellingen.
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
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

Open uw resource voor de logische standaard-app in Azure Portal.
Selecteer Netwerken in het menu van de logische app onder Instellingen.
Selecteer in de sectie Voor binnenkomend verkeer, naast openbare netwerktoegang, ingeschakeld zonder toegangsbeperking.
Selecteer op de pagina Toegangsbeperkingen onder App-toegang de optie Ingeschakeld in de geselecteerde virtuele netwerken en IP-adressen.
Voeg onder Sitetoegang en -regels op het tabblad Hoofdsite een of meer regels toe om aanvragen van specifieke IP-bereiken toe te staan of te weigeren . 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).

Werkstromen voor verbruik

Geef in uw ARM-sjabloon de toegestane binnenkomende IP-adresbereiken op in de resourcedefinitie van uw logische app met behulp van de accessControl sectie. In deze sectie gebruikt u de triggers, actionsen de optionele contents secties, indien van toepassing door de allowedCallerIpAddresses sectie met de addressRange eigenschap op te tellen en de eigenschapswaarde in te stellen op het toegestane IP-bereik in x.x.x.x/x of x.x.x.x.x.x.x .

Als uw geneste logische app-werkstroom gebruikmaakt van de optie Alleen andere Logic Apps , waardoor binnenkomende aanroepen alleen worden toegestaan vanuit andere logische app-werkstromen die gebruikmaken van de ingebouwde Azure Logic Apps-actie, stelt u de allowedCallerIpAddresses eigenschap in op een lege matrix ([]) en laat u de addressRange eigenschap weg.
Als uw werkstroom voor geneste logische apps gebruikmaakt van de optie Specifieke IP-bereiken voor andere binnenkomende aanroepen, zoals andere werkstromen voor logische apps die gebruikmaken van de HTTP-actie, neemt u de allowedCallerIpAddresses sectie op en stelt u de addressRange eigenschap in op het toegestane IP-bereik.

In dit voorbeeld ziet u een resourcedefinitie voor een logische app voor een geneste werkstroom waarmee alleen binnenkomende aanroepen van andere logische app-werkstromen worden toegestaan die gebruikmaken van de ingebouwde Azure Logic Apps-actie:

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

In dit voorbeeld ziet u een resourcedefinitie van een logische app voor een geneste werkstroom die binnenkomende aanroepen van logische app-werkstromen toestaat die gebruikmaken van de HTTP-actie:

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

Standaardwerkstromen

{
   "type": "Microsoft.Web/sites/config",
   "apiVersion": "2022-09-01",
   "name": "[concat(parameters('sites_My_Standard_Logic_App_name'), '/web')]",
   "location": "West US",
   "dependsOn": [
      "[resourceId('Microsoft.Web/sites', parameters('sites_My_Standard_Logic_App_name'))]"
   ],
   "tags": {
      "hidden-link: /app-insights-resource-id": "/subscriptions/{subscriptionID}/resourceGroups/Standard-RG/providers/Microsoft.Insights/components/My-Standard-Logic-App"
   },
   "properties": {
      "numberOfWorkers": 1,
      "defaultDocuments": [
         "Default.htm",
         "Default.html",
         "Default.asp",
         "index.htm",
         "index.html",
         "iisstart.htm",
         "default.aspx",
         "index.php"
      ],
      "netFrameworkVersion": "v6.0",
      "requestTracingEnabled": false,
      "remoteDebuggingEnabled": false,
      "httpLoggingEnabled": false,
      "acrUseManagedIdentityCreds": false,
      "logsDirectorySizeLimit": 35,
      "detailedErrorLoggingEnabled": false,
      "publishingUsername": "$My-Standard-Logic-App",
      "scmType": "None",
      "use32BitWorkerProcess": false,
      "webSocketsEnabled": false,
      "alwaysOn": false,
      "managedPipelineMode": "Integrated",
      "virtualApplications": [
         {
            "virtualPath": "/",
            "physicalPath": "site\\wwwroot",
            "preloadEnabled": false
         }
      ],
      "loadBalancing": "LeastRequests",
      "experiments": {
         "rampUpRules": []
      },
      "autoHealEnabled": false,
      "vnetRouteAllEnabled": false,
      "vnetPrivatePortsCount": 0,
      "publicNetworkAccess": "Enabled",
      "cors": {
         "supportCredentials": false
      },
      "localMySqlEnabled": false,
      "managedServiceIdentityId": 3065,
      "ipSecurityRestrictions": [
         {
            "ipAddress": "208.130.0.0/16",
            "action": "Deny",
            "tag": "Default",
            "priority": 100,
            "name": "Ports"
         },
         {
            "ipAddress": "Any",
            "action": "Deny",
            "priority": 2147483647,
            "name": "Deny all",
            "description": "Deny all access"
         }
      ],
      "ipSecurityRestrictionsDefaultAction": "Deny",
      "scmIpSecurityRestrictions": [
         {
            "ipAddress": "Any",
            "action": "Allow",
            "priority": 2147483647,
            "name": "Allow all",
            "description": "Allow all access"
         }
      ],
      "scmIpSecurityRestrictionsDefaultAction": "Allow",
      "scmIpSecurityRestrictionsUseMain": false,
      "http20Enabled": false,
      "minTlsVersion": "1.2",
      "scmMinTlsVersion": "1.2",
      "ftpsState": "FtpsOnly",
      "preWarmedInstanceCount": 1,
      "functionAppScaleLimit": 0,
      "functionsRuntimeScaleMonitoringEnabled": true,
      "minimumElasticInstanceCount": 1,
      "azureStorageAccounts": {}
   }
},

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

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 geavanceerde parameters en selecteert u Verificatie.

Belangrijk

Als u gevoelige informatie wilt beveiligen die door de werkstroom van 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

Voor HTTP-aanroepen maakt basisverificatie gebruik van een met base64 gecodeerde tekenreeks die een gebruikersnaam en wachtwoord bevat om een aanvraag te doen. Deze methode verzendt referenties zonder versleuteling en vormt verhoogde beveiligingsrisico's, tenzij u deze optie gebruikt met het HTTPS/SSL-protocol.

Belangrijk

Als de optie Basic beschikbaar is en is geselecteerd, 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": {}
}

Clientverificatie via certificaat

Met clientcertificaatverificatie kunnen gebruikers zich rechtstreeks verifiëren met X.509-certificaten op basis van hun Microsoft Entra-id voor toepassingen en browseraanmelding. Met deze mogelijkheid kunt u een phishingbestendige verificatie toepassen en verifiëren met een X.509-certificaat op basis van uw PKI (Public Key Infrastructure).

Belangrijk

Als de optie Clientcertificaat beschikbaar is en is geselecteerd, 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:

Verwijder alle OpenSSL-exemplaren.
Installeer OpenSSL versie 1.1.1t.
Uw certificaat opnieuw toewijzen met behulp van de nieuwe update.
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 Entra-platform

Op de aanvraagtrigger kunt u het Microsoft Entra-platform gebruiken om binnenkomende oproepen te verifiëren nadat u Microsoft Entra-autorisatiebeleid voor uw logische app hebt ingesteld.

Belangrijk

Geef voor alle andere triggers en acties die ondersteuning bieden voor het verificatietype Active Directory OAuth (OAuth 2.0 met Microsoft Entra ID) de volgende eigenschapswaarden op:

Eigenschap (ontwerper)	Eigenschap (JSON)	Vereist	Weergegeven als	Beschrijving
Verificatie	`type`	Ja	Active Directory OAuth (OAuth 2.0 met Microsoft Entra-id) 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 de toegangssleutel biedt, 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
Audiëntie	`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 hebt in Azure Logic Apps met één tenant en u een HTTP-bewerking wilt gebruiken met een TSL/SSL-certificaat, clientcertificaat of Microsoft Entra ID OAuth met het Certificate referentietype, moet u de extra installatiestappen voor dit verificatietype voltooien. Anders mislukt de aanroep. Zie 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.

Belangrijk

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.

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.
Voordat een Azure-functie een beheerde identiteit kan gebruiken, moet u eerst verificatie voor Azure-functies inschakelen.

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.
Audiëntie	`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 geavanceerde parameters 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.
Standaardwerkstromen voor logische apps kunnen privé en veilig communiceren met een virtueel Azure-netwerk via privé-eindpunten die u instelt voor inkomend verkeer en integratie van virtuele netwerken voor uitgaand verkeer. Raadpleeg Verkeer beveiligen tussen virtuele netwerken en Azure Logic Apps met één tenant met behulp van privé-eindpunten voor meer informatie.
Als u uw eigen code wilt uitvoeren of XML-transformatie wilt uitvoeren, maakt en roept u een Azure-functie aan, in plaats van de inlinecodemogelijkheid te gebruiken of assembly's te bieden die u als toewijzingen wilt gebruiken. Stel ook de hostingomgeving in voor uw functie-app om te voldoen aan uw isolatievereisten.

Als u bijvoorbeeld wilt voldoen aan de vereisten voor Impact Level 5, maakt u uw functie-app met het App Service-plan met behulp van de geïsoleerde prijscategorie , samen met een App Service Environment (ASE) die ook gebruikmaakt van de geïsoleerde prijscategorie. In deze omgeving worden functie-apps uitgevoerd op toegewezen virtuele Azure-machines en toegewezen virtuele Azure-netwerken, die netwerkisolatie bieden boven op rekenisolatie voor uw apps en maximale uitschaalmogelijkheden.

Raadpleeg de volgende documentatie voor meer informatie:

Raadpleeg de volgende documentatie voor meer informatie over isolatie:

Share via

Beveiligde toegang en gegevens voor werkstromen in Azure Logic Apps

Toegang tot bewerkingen van logische apps

Werkstromen voor verbruik

Standaardwerkstromen

Toegang tot uitvoeringsgeschiedenisgegevens

Toegang beperken per IP-adresbereik

Werkstromen voor verbruik

Standaardwerkstromen

Gegevens in de uitvoeringsgeschiedenis beveiligen met behulp van verdoofing

Overwegingen voor het beveiligen van invoer en uitvoer

Invoer en uitvoer beveiligen in de ontwerpfunctie

Invoer en uitvoer beveiligen in de codeweergave

Toegang tot parameterinvoer

Beveiligde parameters in werkstroomdefinities (werkstroom verbruik)

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

Verificatietypen voor connectors die verificatie ondersteunen

Toegang voor inkomende aanroepen naar triggers op basis van aanvragen

OAuth 2.0 inschakelen met Microsoft Entra-id

Overwegingen voordat u OAuth 2.0 inschakelt met Microsoft Entra-id

OAuth 2.0 met Microsoft Entra-id inschakelen als enige optie om een aanvraageindpunt aan te roepen (alleen verbruik)

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

OAuth inschakelen met Microsoft Entra-id voor de resource van de logische app Verbruik

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

Een SAS-sleutel (Shared Access Signature) of -token genereren

Sas-verificatie (Shared Access Signature) uitschakelen (alleen verbruik)

Vereisten

Controleren op triggers waarvoor SAS is ingeschakeld of uitgeschakeld

De eigenschap sasAuthenticationPolicy toevoegen aan uw werkstroomdefinitie

Toegangssleutels regenereren

Verlopende callback-URL's maken

URL's maken met primaire of secundaire geheime sleutel

Uw werkstroom voor logische apps beschikbaar maken met Azure API Management

Binnenkomende IP-adressen beperken

Werkstromen voor verbruik

Standaardwerkstromen

Toegang voor uitgaande aanroepen naar andere services en systemen

Verificatie toevoegen aan uitgaande oproepen

Basisverificatie

Clientverificatie via certificaat

Microsoft Entra-platform

Onbewerkte verificatie

Verificatie van beheerde identiteit

Blok dat verbindingen maakt

Isolatierichtlijnen voor logische apps

Gerelateerde inhoud

Feedback

Aanvullende resources