Beveiligde toegang en gegevens voor werkstromen in Azure Logic Apps

Azure Logic Apps slaat data in rust op en versleutelt ze automatisch met behulp van Azure Storage. Deze encryptie beschermt uw gegevens door gebruik te maken van door Microsoft beheerde sleutels en helpt u te voldoen aan uw organisatieverplichtingen op het gebied van veiligheid en naleving. Voor meer informatie, zie Azure Storage-versleuteling voor gegevens in rust.

Deze gids laat zien hoe je gevoelige gegevens verder kunt beveiligen en beschermen in de volgende hoofdgebieden voor Azure Logic Apps:

Task Ga naar
Bepaal wie workflows mag beheren of bewerken Beveiligde Logic Apps-bewerkingen
Verberg invoer, output, wachtwoorden en geheimen in de rungeschiedenis Veilige uitvoeringsgeschiedenisgegevens
Bescherm parameterwaarden over omgevingen heen Veilige parameterinvoer
Begrijpen authenticatietypen Bekijk authenticatietypen voor workflowoperaties
Verifieer aanroepen waarmee je workflow wordt gestart Beveiligde inkomende oproepen
Authenticeer oproepen die je workflow verstuurt Beveilig uitgaande gesprekken
Blokspecifieke connectoren Verbindingen blokkeren
Voldoen aan isolatie-eisen Isolatierichtlijn
Bekijk de beveiligingsbaseline Azure-beveiligingsbasislijn voor Azure Logic Apps

Voor informatie over Azure-brede beveiliging, zie:

Beveilig de toegang tot bewerkingen van de logische app via Azure RBAC

In Azure bepaalt rolgebaseerde toegangscontrole (RBAC) wie toegang en rechten heeft om met resources te werken. Voordat anderen logische apps, workflows en verbindingen kunnen maken of beheren, moet je hen een rol toewijzen die de benodigde rechten biedt. Je kunt permissies zo instellen dat alleen specifieke gebruikers of groepen specifieke taken kunnen uitvoeren, zoals het beheren, bewerken en bekijken van logica-apps. Om hun rechten te beheren, wijs je ingebouwde of aangepaste rollen toe aan leden die toegang hebben tot je Azure-abonnement.

Important

Om je aanvalsoppervlak te verkleinen, wijs je altijd rollen toe op basis van het principe van het minste privilege.

Voordat je een functie toewijst, bekijk de volgende best practices, overwegingen en impact:

  • Laat gebruikers, apps en beheerde identiteitenalleen toegang krijgen tot de data en operaties die ze nodig hebben om hun taken uit te voeren.

  • Wijs rollen op bijdragersniveau of machtigingen voor het bewerken van workflows, volgens het principe van minimale bevoegdheden, alleen toe aan vertrouwde entiteiten.

  • Ken alleen de minimaal noodzakelijke rechten toe voor beheerde identiteiten in Logic App-workflows om hun werk te doen.

  • Bijdrager- of workflowbewerkingsrechten komen overeen met het vasthouden van de rechten voor elke beheerde identiteit die aan die workflow is toegewezen.

  • Iedereen met bijdrager- of workflowbewerkingsrechten kan ingebouwde HTTP-operaties instellen die beheerde identiteiten gebruiken om identiteitsdragertokens voor elk publiek op te vragen. Ze kunnen verzoeken met deze tokens naar elk eindpunt of bestemming sturen. Het platform beperkt de bestemming niet. Bearer-tokens zijn één uur geldig en kunnen toegang krijgen tot elke Azure API waar hun identiteit bij kan komen.

Azure Logic Apps heeft de volgende specifieke rollen, afhankelijk van of je een Consumption- of Standard-workflow hebt:

Werkstromen voor verbruik
Rol Description
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 bijvoorbeeld dat je moet werken met een logica-app-workflow die je niet hebt gemaakt en de verbindingen authenticeren die door die logica-app-workflow worden gebruikt. Uw Azure-abonnement vereist inzendermachtigingen voor de resourcegroep die die logische app-resource bevat. Als je een Logic App-resource maakt, heb je automatisch Contributor-toegang.

Om te voorkomen dat anderen je logica-app-workflow wijzigen of verwijderen, gebruik je Azure Resource Lock. 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
Rol Description
Logic Apps Standard Lezer U hebt alleen-lezentoegang tot alle resources in een Standaard Logic App en werkstromen, inclusief de uitvoeringen van werkstromen en hun geschiedenis.
Logic Apps standaardoperator 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 Ontwikkelaar 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 Standaardbijdrager 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 workflow-uitvoeringsgeschiedenis

Tijdens een workflowuitvoering wordt alle data tijdens het transport versleuteld met Transport Layer Security (TLS) en in rust. Wanneer uw logische app klaar is met uitvoeren, kunt u de geschiedenis voor die uitvoering bekijken, inclusief de stappen die zijn uitgevoerd, samen met de status, duur, de 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.

Om de toegang tot de invoer en uitvoer in je workflow-run history te beheren, gebruik je de volgende opties:

Toegang beperken per IP-adresbereik

U kunt de toegang beperken tot de invoer en uitvoer in de uitvoeringsgeschiedenis van uw logic app-werkstromen, 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 formaten: 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 Consumption of Standard logische app in de Azure Portal of uw Azure Resource Manager-sjabloon:

Werkstromen voor verbruik

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

  2. Selecteer in de zijbalk van de Logic App onder InstellingenWorkflow-instellingen.

  3. Selecteer in de sectie Configuratie van toegangsbeheer onder Toegestane binnenkomende IP-adressen in de lijst met opties voor triggertoegang specifieke IP-bereiken.

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

Standaardwerkstromen

  1. Open in de Azure portal uw standaard logische app-resource.

  2. Selecteer in de zijbalk van de logica-app onder InstellingenNetwerken.

  3. Selecteer in de sectie ‘Binnenkomend verkeer’, naast openbare netwerktoegang, Inschakelen zonder toegangsbeperking.

  4. Selecteer op de pagina Toegangsbeperkingen onder App-toegang de optie Ingeschakeld in de geselecteerde virtuele netwerken en IP-adressen.

  5. 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 formaten: 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).

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 array-variabele
Toevoegen aan tekenreeksvariabele
Variabele voor verlagen
Voor elke
Als
Incrementele variabele
Variabele initialiseren
Terugkeerpatroon
Draagwijdte
Variabele instellen
Schakelaar
Beëindigen
Totdat		 Toevoegen aan array-variabele
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
Wait

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, verbergt Azure Logic Apps deze uitvoer 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.

    Diagram dat laat zien hoe beveiligde uitvoer de zichtbaarheid beïnvloedt als verborgen invoer voor daaropvolgende acties in de uitvoeringsgeschiedenis van de workflow.

    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 niet de instelling Beveiligde invoer van deze acties 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.

    Diagram dat laat zien hoe beveiligde uitvoer de zichtbaarheid beïnvloedt als invoer voor de Compose-, Parse JSON- en Response-acties.

    Instelling Voor beveiligde invoer

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

    Diagram dat laat zien hoe beveiligde trigger- of actie-invoer de zichtbaarheid beïnvloeden als invoer voor downstream workflow-acties.

    Als de acties Compose, Parse JSON en Response expliciet de zichtbare uitvoer gebruiken van de trigger of actie die beveiligde invoer gebruikt, verbergt Azure Logic Apps de invoer en uitvoer van deze acties, maar schakelt voor deze acties de instelling Secure Inputs 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.

    Diagram dat laat zien hoe beveiligde invoer de Compose, Parse JSON en Response workflowacties beïnvloeden.

Invoer en uitvoer beveiligen in de ontwerpfunctie

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

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

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

    Screenshot die het Azure-portaal, workflow-ontwerper en trigger of actie toont met geopende instellingen.

  4. Schakel ofwel Beveiligde Invoer, Beveiligde Uitvoer of beide in.

    Screenshot die een workflow toont met de Secure Inputs- of Secure Outputs-instellingen van een actie ingeschakeld.

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

    Screenshot die een workflow toont met de dynamische contentlijst van een volgende actie open, en het token van de vorige actie voor beveiligde uitvoer met een vergrendelingsicoon.

  5. Nadat de werkstroom is uitgevoerd, kunt u de uitvoeringsgeschiedenis bekijken.

    1. Selecteer Overzicht in de zijbalk van de logische app.

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

    3. Selecteer in het deelvenster voor de uitvoeringsgeschiedenis van de werkstroom de acties die u wilt bekijken.

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

      Schermafbeelding van de weergave van de uitvoeringsgeschiedenis van een Standard-workflow met verborgen invoer en uitvoer.

Invoer en uitvoer beveiligen in de codeweergave

Voeg in de onderliggende trigger- of actiedefinitie de array toe of werk deze bij met een of beide waarden:

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

Veilige toegang tot parameterinvoer in omgevingen

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. Door een Azure Resource Manager-sjabloon te gebruiken om je logica-app uit te rolën, kun je hardgecodeerde data vermijden, gevoelige gegevens beschermen door beveiligde parameters te definiëren, en die data als aparte invoer via de parameters van het sjabloon doorgeven 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.

Note

Als je een parameter gebruikt in een requestheader of body, kan deze parameter zichtbaar zijn wanneer je de run-geschiedenis en het uitgaande HTTP-verzoek van je workflow 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.

Standaard zijn headers met Authorization niet zichtbaar via invoer of uitvoer. Als je daar een geheim gebruikt, kun je dat geheim niet terughalen.

Voor meer informatie, zie de volgende secties in dit artikel:

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. Ga voor meer informatie naar:

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 bijvoorbeeld dat je een HTTP-actie hebt die basisauthenticatie 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.

Important

Voor optimale beveiliging gebruik je Microsoft Entra ID met beheerde identiteiten voor authenticatie wanneer mogelijk. Deze optie biedt superieure beveiliging zonder dat er inloggegevens nodig zijn. 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.

Important

Voor optimale beveiliging gebruik je Microsoft Entra ID met beheerde identiteiten voor authenticatie wanneer mogelijk. Deze optie biedt superieure beveiliging zonder dat er inloggegevens nodig zijn. 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.

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

Verificatietype Logica-app en ondersteunde connectoren
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
Raw 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-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-tabelopslag, Azure VM, HTTP met Microsoft Entra ID, SQL Server

Important

Voor optimale beveiliging gebruik je Microsoft Entra ID met beheerde identiteiten voor authenticatie wanneer mogelijk. Deze optie biedt superieure beveiliging zonder dat er inloggegevens nodig zijn. 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.

Toegang voor inkomende aanroepen naar triggers op basis van aanvragen

Inkomende oproepen die een logische app ontvangt via een verzoekgestuurde trigger, zoals de Verzoek trigger of de HTTP-webhook trigger, ondersteunen versleuteling en worden minimaal beveiligd met Transport Layer Security (TLS) 1.2, voorheen bekend als Secure Sockets Layer (SSL). 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.

Note

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.

Important

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 2.0 inschakelen met Microsoft Entra-id

In een verbruikswerkstroom die begint met een trigger op basis van aanvragen, kunt u binnenkomende aanroepen authenticeren 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 u aan Om Microsoft Entra ID te gebruiken met beheerde identiteiten voor verificatie, indien mogelijk. Deze optie biedt superieure beveiliging zonder dat er inloggegevens nodig zijn. 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 consumptie-werkstroom begint met de aanvraagtrigger, kunt u de SAS-verificatie uitschakelen en de autorisatie beperken tot het gebruik van alleen OAuth 2.0 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 het proof-of-possession-type (alleen voor verbruikslogica apps) autorisatieschema voor OAuth-toegangstokens voor Microsoft Entra ID. De Authorization header voor het toegangstoken moet echter het type Bearer of het type PoP specificeren. Zie Proof of Possession (PoP) token ophalen voor meer informatie over het verkrijgen en gebruiken van een PoP-token.

  • Een resource van de Consumption-logische app is beperkt in het maximum aantal autorisatiebeleidsregels. Elk autorisatiebeleid heeft ook een maximaal aantal claims. Zie Informatie over limieten en configuratie voor Azure Logic Apps voor meer informatie.

  • Een autorisatiebeleid moet ten minste de claims van de Uitgever en de Publiek omvatten. De claim van de uitgever heeft een waarde die begint met ofwel https://sts.windows.net/ of https://login.microsoftonline.com/ (OAuth V2) als uitgever voor Microsoft Entra ID. De Audience-claim heeft een waarde die de verwachte audience is voor je logica-app resource.

    Stel dat uw logische app-resource een autorisatiebeleid heeft waarvoor twee claimtypen, doelgroep en verlener vereist zijn. Dit voorbeeld payloadgedeelte voor een gedecodeerd toegangstoken bevat zowel claimtypen als waar aud de waarde van de Audience is en iss de waarde van de Issuer is.

    {
    "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 inschakelen met Microsoft Entra ID als enige optie om een aanvraageindpunt aan te roepen

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.

  1. Stel voor uw werkstroom uw aanvraagtrigger of HTTP-webhooktrigger in met de mogelijkheid om het OAuth-toegangstoken te controleren door de stappen uit te voeren om de header Autorisatie op te nemen in de uitvoer van de aanvraag- of HTTP-webhooktrigger.

    Note

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

  2. Open uw werkstroom in de Azure-portal in de ontwerpfunctie.

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

  4. Onder Algemene>triggervoorwaarden, selecteer Toevoegen. 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 je het trigger-eindpunt aanroept zonder de juiste autorisatie, wordt de trigger in de uitvoeringsgeschiedenis als Skipped weergegeven, zonder enig 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 de Consumption logic app-workflow die je wilt aanroepen een PoP-token vereist, kun je dit token verkrijgen door gebruik te maken 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 Verbruik-logische app, volgt u de stappen voor het instellen van OAuth met Microsoft Entra ID.

OAuth inschakelen met Microsoft Entra ID voor uw Consumptielogische app-resource

Als u een toegangsbeleid wilt toevoegen aan uw Verbruiks-logische app, volgt u het proces voor de Azure-portal of Azure Resource Manager template.

  1. Open in het Azure portal uw verbruikslogische app en werkstroom in de ontwerpweergave.

  2. Selecteer in de zijbalk van de logica-app onder InstellingenAutorisatie.

  3. Selecteer Beleid toevoegen op de pagina Autorisatie.

    Screenshot die het Azure-portaal, de autorisatiepagina en de geselecteerde knop om beleid toe te voegen toont.

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

    Screenshot die het Azure-portaal, de autorisatiepagina en de details van het autorisatiebeleid toont.

    Property Required Typ Description
    Beleidsnaam Yes String De naam die u wilt gebruiken voor het autorisatiebeleid
    Beleidstype Yes String AAD voor bearertokens of AADPOP voor proof-of-possession-tokens.
    Claims Yes 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:

    - Uitgever
    - Audiëntie
    - Onderwerp
    - JWT-id (JSON-webtoken-id)

    Eisen:

    - Minimaal moet de lijst Claims de volgende claimtypen bevatten:

    -- Uitgever: Stel de waarde zo in dat deze begint met https://sts.windows.net/ of https://login.microsoftonline.com/ als de uitgever-id van Microsoft Entra.
    -- Doelgroep: De waarde is ingesteld op de verwachte doelgroep voor uw logische app-resource.

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

    U kunt ook uw eigen claimtype en -waarde opgeven. Voor meer informatie over deze claimtypen, zie 'Claims in Microsoft Entra-beveiligingstokens'.

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

    Screenshot die het Azure-portaal, de autorisatiepagina en de bewijs-van-bezit-beleidsinformatie toont.

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

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

  7. Wanneer u klaar bent, selecteert u Opslaan.

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

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

De 'Authorization'-header opnemen in de uitvoer van request- 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"
   }
}

Ga voor meer informatie naar:

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

Wanneer een workflow begint met een aanvraag-gebaseerde trigger en u die workflow voor de eerste keer opslaat, maakt Azure Logic Apps een aanroepbaar eindpunt aan 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:

Screenshot die het Azure-portaal, de Consumption-workflow en de Request trigger endpoint-eigenschap toont met de naam HTTP URL.

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:

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

Important

Bescherm je SAS-sleutel net zoals je een accountsleutel beschermt tegen ongeoorloofd 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.

Om de beveiliging te behouden en de toegang tot je workflow te beschermen, genereer je toegangssleutels op een regelmatig schema, omdat ze mogelijk aan beveiligingsbeleid moeten voldoen of gecompromitteerd raken. 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 je een SAS-sleutel gebruikt om toegang te krijgen tot opslagdiensten, maak dan een gebruikersdelegatie-SAS aan, die beveiligd is met een Microsoft Entra ID, in plaats van een accountsleutel.

Voor optimale beveiliging gebruik Microsoft Entra ID met beheerde identiteiten voor authenticatie waar mogelijk. Deze optie biedt superieure beveiliging zonder dat er inloggegevens nodig zijn. 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 consumptiewerkstroom 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:

Sas-verificatie (Shared Access Signature) uitschakelen

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

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

Als uw werkstroom 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.

Note

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 het uitschakelen van SAS-authenticatie

Om SAS-authenticatie op een verzoekgebaseerde trigger uit te schakelen, heb je een tool nodig om REST API-aanroepen te verzenden, bijvoorbeeld:

Caution

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. Het hulpprogramma moet offline of lokaal werken en u hoeft zich niet aan te melden bij een onlineaccount of gegevens naar de cloud te synchroniseren. Wanneer u een hulpprogramma met deze kenmerken gebruikt, 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 consumptiewerkstroom 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.

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

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

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

  2. 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 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"
            }
        }
    }
}

  3. 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 PUT-aanvraag, bijvoorbeeld:

    PUT https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

  4. Ga in Azure Portal naar uw werkstroom Verbruik in de ontwerpfunctie en controleer of de URL van de aanvraagtrigger de SAS niet meer bevat.

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

Om de beveiliging te handhaven en de toegang tot uw Logic App-werkstroom te beveiligen, regenereert u regelmatig toegangssleutels, aangezien ze mogelijk moeten voldoen aan beveiligingsbeleid of kunnen worden gecompromitteerd. 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.

  1. Open in de Azure portal de resource van de logische app die gebruikmaakt van de sleutel die u opnieuw wilt genereren.

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

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

Important

Bescherm je toegangssleutel net zoals je een accountsleutel beschermt tegen ongeoorloofd 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 kan toegang krijgen tot de bijbehorende bron.

Als je een SAS-sleutel gebruikt om toegang te krijgen tot opslagdiensten, maak dan een gebruikersdelegatie-SAS aan, die beveiligd is met een Microsoft Entra ID, in plaats van een accountsleutel.

Voor optimale beveiliging gebruik je Microsoft Entra ID met beheerde identiteiten voor authenticatie wanneer mogelijk. Deze optie biedt superieure beveiliging zonder dat er inloggegevens nodig zijn. 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.

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. Met deze aanpak kun je naadloos toetsen rollen of de toegang beperken tot het activeren van je logica-app op basis van een specifieke tijdsperiode. 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 eigenschap KeyType op als Primary of Secondary. 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.

Ga voor meer informatie naar:

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 formaten: x.x.x.x/x of x.x.x.x-x.x.x.x.

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

Werkstromen voor verbruik

  1. Open in het Azure portal uw verbruikslogische app en werkstroom in de ontwerpweergave.

  2. Selecteer in de zijbalk van de Logic App onder InstellingenWorkflow-instellingen.

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

    • Om je workflow aanroepbaar te maken met de Azure Logic Apps-ingebouwde actie, maar alleen als een geneste workflow, selecteer je 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.

    • Om uw workflow aanroepbaar te maken met behulp van de HTTP-actie, maar alleen als een geneste workflow, 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 formaten: x.x.x.x/x of x.x.x.x-x.x.x.x.

      Note

      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 oproepen van andere IP-adressen wilt beperken, geeft u de IP-adresbereiken op die door de trigger worden geaccepteerd wanneer het veld IP-bereiken voor triggers verschijnt. Een geldig IP-bereik gebruikt deze formaten: x.x.x.x/x of x.x.x.x-x.x.x.x.

  4. Optioneel, onder Beperk oproepen om invoer- en uitvoerberichten van de rungeschiedenis naar de opgegeven IP-adressen te krijgen, specificeer je de IP-adresbereiken voor inkomende gesprekken die toegang hebben tot invoer- en outputberichten in de run history.

Standaardwerkstromen

  1. Open in de Azure portal uw standaard logische app-resource.

  2. Selecteer in de zijbalk van de logica-app onder InstellingenNetwerken.

  3. Selecteer in de sectie ‘Binnenkomend verkeer’, naast openbare netwerktoegang, Inschakelen zonder toegangsbeperking.

  4. Selecteer op de pagina Toegangsbeperkingen onder App-toegang de optie Ingeschakeld in de geselecteerde virtuele netwerken en IP-adressen.

  5. 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 formaten: x.x.x.x/x of x.x.x.x-x.x.x.x.

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

Toegang voor uitgaande aanroepen naar andere services en systemen

Afhankelijk van de capaciteit van het doel-endpoint ondersteunen uitgaande aanroepen die door de HTTP-trigger of HTTP-actie worden verzonden encryptie en zijn beveiligd met Transport Layer Security (TLS) 1.0, 1.1, 1.2 of 1.3, voorheen bekend als Secure Sockets Layer (SSL). Azure Logic Apps onderhandelt met het doeleindpunt over het gebruik van de hoogst mogelijke versie die wordt ondersteund. Als het doeleindpunt bijvoorbeeld 1.3 ondersteunt, gebruikt de HTTP-trigger of -actie eerst 1.3. 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. Voor meer informatie, zie Clientcertificaat of OAuth met Microsoft Entra ID met het referentietype "Certificaat" voor één-tenant Azure Logic Apps.

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 als beveiligd uitgaand verkeer afkomstig van de gatewayagent. Meer informatie over hoe de on-premises gegevensgateway werkt.

    • Maak verbinding 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.

      Note

      De connector toont alleen de API Management-services waarvoor u de rechten hebt om ze te bekijken en ermee te verbinden, maar toont geen op verbruik gebaseerde API Management-services.

      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: Voeg de trigger toe genaamd Choose an Azure API Management Trigger door de algemene stappen te volgen.

        • Actie: Voeg de actie toe genaamd Choose an Azure API Management action door de algemene stappen te volgen.

      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. Voeg in de workflowontwerper de actie toe genaamd Call an Azure API Management API door de algemene stappen te volgen.

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

        Screenshot die het Azure-portaal, de standaard workflowdesigner en de geselecteerde API toont die aangeroepen moet worden.

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.

Important

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.

Voor optimale beveiliging gebruik je Microsoft Entra ID met beheerde identiteiten voor authenticatie wanneer mogelijk. Deze optie biedt superieure beveiliging zonder dat er inloggegevens nodig zijn. 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.

Basic authentication

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.

Important

Voor optimale beveiliging gebruik je Microsoft Entra ID met beheerde identiteiten voor authenticatie wanneer mogelijk. Deze optie biedt superieure beveiliging zonder dat er inloggegevens nodig zijn. 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.

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

Eigenschap (ontwerper) Eigenschap (JSON) Required Value Description
Authentication type Yes Basic Het te gebruiken verificatietype
Gebruikersnaam username Yes < gebruikersnaam> De gebruikersnaam voor het verifiëren van toegang tot het doelservice-eindpunt
Wachtwoord password Yes < wachtwoord> Het wachtwoord voor het verifiëren van toegang tot het doelservice-eindpunt

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

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

Verificatie van clientcertificaten

Met clientcertificaatverificatie kunnen gebruikers zich rechtstreeks verifiëren met X.509-certificaten op basis van hun Microsoft Entra-id voor toepassingen en browseraanmelding. Deze mogelijkheid helpt u een phishingbestendige authenticatie te adopteren en te authenticeren met een X.509-certificaat tegen uw Public Key Infrastructure (PKI).

Important

Voor optimale beveiliging gebruik je Microsoft Entra ID met beheerde identiteiten voor authenticatie wanneer mogelijk. Deze optie biedt superieure beveiliging zonder dat er inloggegevens nodig zijn. 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.

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

Eigenschap (ontwerper) Eigenschap (JSON) Required Value Description
Authentication type Yes 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 Yes < gecodeerde-pfx-bestandinhoud> 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

Nadat u de met base64 gecodeerde tekenreeks voor het geconverteerde PFX-bestand van het certificaat heeft verkregen, werkt deze nu in Azure Logic Apps.
Wachtwoord password No < Wachtwoord-voor-PFX-bestand> Het wachtwoord voor toegang tot het PFX-bestand

Note

Als je probeert te authenticeren met een clientcertificaat via OpenSSL, kun je de volgende foutmelding krijgen:

BadRequest: Could not load private key

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

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

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

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

Important

Als je een standaard logic app-resource hebt in single-tenant Azure Logic Apps, en je wilt een HTTP-operatie gebruiken met een TLS/SSL-certificaat, clientcertificaat of Microsoft Entra ID OAuth met het Certificate credentialtype, zorg dan dat je de extra installatiestappen voor dit authenticatietype voltooit. Anders mislukt de aanroep. Zie Verificatie in een omgeving met één tenant voor meer informatie.

Voor meer informatie over het beveiligen van diensten door gebruik te maken van clientcertificaatauthenticatie, zie:

Active Directory OAuth (OAuth 2.0 met Microsoft Entra ID) authenticatie

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.

Important

Voor optimale beveiliging gebruik je Microsoft Entra ID met beheerde identiteiten voor authenticatie wanneer mogelijk. Deze optie biedt superieure beveiliging zonder dat er inloggegevens nodig zijn. 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.

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) Required Value Description
Authentication type Yes 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 No < URL-voor-token-verlenende-autoriteit> De URL voor de instantie die de toegangssleutel biedt, zoals https://login.microsoftonline.com/ voor globale Azure-serviceregio's. Raadpleeg voor andere nationale clouds Microsoft Entra-verificatie-eindpunten - uw identiteitsinstantie kiezen.
Tenant tenant Yes < tenant-id> De tenant-id voor de Microsoft Entra-tenant
Doelgroep audience Yes < resource te autoriseren> De resource die u wilt gebruiken voor autorisatie, bijvoorbeeld https://management.core.windows.net/
Client-ID clientId Yes < client-id> De client-id voor de app die autorisatie aanvraagt
Referentietype credentialType Yes 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 < Klant-geheim> Het clientgeheim voor het aanvragen van autorisatie
Pfx pfx Ja, maar alleen voor het referentietype Certificaat < gecodeerde-pfx-bestandinhoud> De base64-gecodeerde inhoud uit een PFX-bestand (Personal Information Exchange)
Wachtwoord password Ja, maar alleen voor het referentietype Certificaat < Wachtwoord-voor-PFX-bestand> 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": {}
}

Important

Als je een standaard logic app-resource hebt in single-tenant Azure Logic Apps, en je wilt een HTTP-operatie gebruiken met een TLS/SSL-certificaat, clientcertificaat of Microsoft Entra ID OAuth met het Certificate credentialtype, zorg dan dat je de extra installatiestappen voor dit authenticatietype voltooit. Anders mislukt de aanroep. Zie Verificatie in een omgeving met één tenant voor meer informatie.

Ruwe verificatie

Als de Raw-optie beschikbaar is, gebruik dan dit type authenticatie wanneer je authenticatieschema's nodig hebt die het OAuth 2.0-protocol niet volgen. 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.

Important

Voor optimale beveiliging gebruik je Microsoft Entra ID met beheerde identiteiten voor authenticatie wanneer mogelijk. Deze optie biedt superieure beveiliging zonder dat er inloggegevens nodig zijn. 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 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"

In de trigger of actie die ruwe authenticatie ondersteunt, geef de volgende eigenschapswaarden op:

Eigenschap (ontwerper) Eigenschap (JSON) Required Value Description
Authentication type Yes Onbewerkt Het te gebruiken verificatietype
Waarde value Yes < autorisatie-header-waarde> De waarde van de autorisatieheader die moet worden gebruikt voor verificatie

Wanneer je beveiligde parameters gebruikt om gevoelige informatie te verwerken en te beveiligen, zoals in een Azure Resource Manager-sjabloon voor het automatiseren van deployment, kun je expressies gebruiken om deze parameterwaarden tijdens runtime te benaderen. 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 voor beheerde identiteit beschikbaar is op de trigger of actie die beheerde identiteitsauthenticatie ondersteunt, kan je logica-app deze identiteit gebruiken om toegang te authenticeren tot Azure-bronnen die beschermd zijn door Microsoft Entra ID, in plaats van inloggegevens, geheimen of Microsoft Entra-tokens te gebruiken. 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 door de gebruiker handmatig 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.

    Note

    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 je deze identiteit uitschakelt, werken de verbindingen niet tijdens runtime. Om deze instelling te bekijken, kies in de zijbalk van je Logic-app onder InstellingenIdentiteit.

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

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

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

    Ingebouwde triggers en acties

    Eigenschap (ontwerper) Eigenschap (JSON) Required Value Description
    Authentication type Yes Beheeridentiteit
    of
    ManagedServiceIdentity    		 Het te gebruiken verificatietype
    Beheeridentiteit identity No < 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.
    Doelgroep audience Yes < 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. Om deze resource-id's te vinden, bekijkt u de Azure-services die ondersteuning bieden voor Microsoft Entra-id.

    Wanneer je beveiligde parameters gebruikt om gevoelige informatie te verwerken en te beveiligen, zoals in een Azure Resource Manager-sjabloon voor het automatiseren van deployment, kun je expressies gebruiken om deze parameterwaarden tijdens runtime te benaderen. 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) Required Value Description
    Verbindingsnaam Yes < verbindingsnaam>
    beheerde identiteit Yes Door het systeem toegewezen beheerde identiteit
    of
    < door de gebruiker toegewezen beheerde identiteit-naam>    		 Het te gebruiken verificatietype

Blokverbindingen gemaakt door specifieke connectoren

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 de door specifieke connectors in Azure Logic Apps gecreëerde verbindingen blokkeren voor meer informatie.

Isolatierichtlijnen voor logische apps

Voor meer informatie over isolatie, zie:

Verwante onderwerpen

  • Last updated on