Beveiligde toegang en gegevens voor werkstromen in Azure Logic Apps

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 gegevens in rusttoestand 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 logische app-bewerkingen
• Toegang tot invoer en uitvoer van uitvoeringsgeschiedenis
• Toegang tot parameterinvoer
• Verificatietypen voor triggers en acties die ondersteuning bieden voor verificatie
• Toegang voor inkomende oproepen naar aanvraaggebaseerde triggers
• 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:

• Overzicht van Azure-versleuteling
• Versleuteling van data-at-rest in Azure
• Microsoft-benchmark voor cloudbeveiliging

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, afhankelijk van of u een werkstroom voor de logische app Verbruik of Standaard 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 Logic App en werkstromen, inclusief de uitvoeringen van werkstromen 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 Standaard-Medewerker (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 run van een logische app worden alle gegevens versleuteld met behulp van Transport Layer Security (TLS), zowel tijdens transport als 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.

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

Portaal

Werkstromen voor verbruik

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

2. Selecteer werkstroominstellingen in het menu van de logische app onder 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 Netwerken in het menu van de logische app onder Instellingen.

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

Resource Manager-sjabloon

Werkstromen voor verbruik

Geef in uw ARM-sjabloon de IP-bereiken op met behulp van de accessControl-sectie en de contents-sectie in de resourcedefinitie van uw Logic 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 properties de ipSecurityRestrictions sectie toe en gebruik de ipAddress, action="Deny" | "Allow", tag=Default, priority, en name="Ports" secties om een regel te definiëren en stel de ipAddress in op het toegestane IP-bereik in het formaat 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 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 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, 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.

  

  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.

  

  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.

  

  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

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.

   

4. Schakel ofwel 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.

   

5. Nadat de werkstroom is uitgevoerd, kunt u de uitvoeringsgeschiedenis 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 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.

      

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

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. Standaard zijn headers met 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

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.

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:

Verificatietype	Logic App en ondersteunde connectors
Basisch	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-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

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.

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.

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
• Shared Access Signature (SAS)-sleutels 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 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 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 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 Issuer-claim bevatten, die een waarde heeft die begint met ofwel https://sts.windows.net/ of https://login.microsoftonline.com/ (OAuth V2) als de uitgever voor Microsoft Entra ID.

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

1. Voor uw consumptiewerkstroom stelt u uw verzoektrigger of HTTP-webhooktrigger in met de mogelijkheid om het OAuth-toegangstoken te controleren door de stappen te volgen om de 'Autorisatie'-header op te nemen in de uitvoer van de verzoek- of HTTP-webhooktrigger.

   Notitie

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

2. In de Azure portal opent u uw verbruikswerkstroom 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 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 logische appwerkstroom Consumption die u wilt aanroepen een PoP-token nodig is, kunt u dit token ophalen met behulp van de MSAL-bibliotheken. In de volgende voorbeelden ziet u hoe u PoP-tokens kunt verkrijgen:

• Een .NET Core daemon-consoletoepassing die een beveiligde web-API aanroept met een eigen identiteit

• SignedHttpRequest, ook wel bekend als PoP (Proof of Possession)

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.

Portaal

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

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

3. Selecteer Beleid toevoegen op de pagina Autorisatie.

   

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 :

   

   Vastgoed	Verplicht	Typologie	Beschrijving
   Beleidsnaam	Ja	Snaar / Touwtje	De naam die u wilt gebruiken voor het autorisatiebeleid
   Beleidstype	Ja	Snaar / Touwtje	AAD voor bearertokens of AADPOP voor proof-of-possession-tokens.
   Aanspraken	Ja	Snaar / Touwtje	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 claimlijst de Issuer-claim bevatten, die een waarde heeft die begint met https://sts.windows.net/ of https://login.microsoftonline.com/ als de Microsoft Entra-uitgevende ID. - 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. Voor meer informatie over deze claimtypen, raadpleeg Claims in Microsoft Entra-beveiligingstokens. U kunt ook uw eigen claimtype en -waarde opgeven.

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

   

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. Selecteer Opslaan als u klaar bent.

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.

Resource Manager-sjabloon

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

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

   Raadpleeg voor meer informatie over het accessControl object Inkomende IP-bereiken beperken in Azure Resource Manager-sjabloon en Microsoft.Logic workflows template referentie.

2. Voeg in het triggers object een openAuthenticationPolicies object toe dat het policies object bevat waarin u een of meer autorisatiebeleidsregels definieert.

3. 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 array moet minimaal het claimtype Issuer bevatten waarbij u de eigenschap van claims instelt en stel de waarde van name in om te beginnen met iss of value als de ID van de Microsoft Entra-issuer. Voor meer informatie over deze claimtypen, zie 'Claims in Microsoft Entra-beveiligingstokens'. U kunt ook uw eigen claimtype en -waarde opgeven.

4. Zie Authorization om de header van het 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 '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"
   }
}

Raadpleeg de volgende onderwerpen voor meer informatie:

• Schemaverwijzing voor trigger- en actietypen - Trigger aanvragen
• Schemaverwijzing voor trigger- en actietypen - HTTP Webhook-trigger
• Schemaverwijzing voor trigger- en actietypen - Bewerkingsopties

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:

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	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. Om de beveiliging te handhaven en de toegang tot de werkstroom van uw logische app te beschermen, regenereer regelmatig de toegangssleutels, omdat deze moeten voldoen aan beveiligingsbeleid of mogelijk gecompromitteerd kunnen 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 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 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:

• 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, 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 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

Vereiste voorwaarden

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

• Visual Studio Code met een extensie van Visual Studio Marketplace
• PowerShell Invoke-RestMethod
• Microsoft Edge - Hulpprogramma voor netwerkconsole
• Bruno
• krul

Waarschuwing

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.

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.

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

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

Voor meer informatie raadpleegt u de volgende documentatie:

• Meer informatie over API Management
• Een web-API-back-end beveiligen in Azure API Management met behulp van OAuth 2.0-autorisatie met Microsoft Entra-id
• API's beveiligen met behulp van verificatie van clientcertificaten in API Management
• API Management-verificatiebeleid

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

Portaal

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. In de Azure portal opent u uw Verbruik logische app in de werkstroomontwerper.

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

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

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

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

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

     Notitie

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

   • Voor scenario's waarin u binnenkomende 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 indelingen: x.x.x.x/x of x.x.x.x-x.x.x.x

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

Standaardwerkstromen

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

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

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

Resource Manager-sjabloon

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, actions en de optionele contents secties, indien van toepassing, door de allowedCallerIpAddresses sectie met de addressRange eigenschap inclusief op te nemen 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.x formaat.

• 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

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 properties de ipSecurityRestrictions sectie toe en gebruik de ipAddress, action="Deny" | "Allow", tag=Default, priority, en name="Ports" secties om een regel te definiëren en stel de ipAddress in op het toegestane IP-bereik in het formaat 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": {}
   }
},

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

  • Basisverificatie

  • Verificatie van clientcertificaten

  • Verificatie van Active Directory OAuth (OAuth 2.0 met Microsoft Entra ID)

  • Verificatie van beheerde identiteit

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

  • Lokale 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 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:

       • Trekker:

         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 Kies een Azure API Management-trigger 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. Kies Kies een Azure API Management-actie 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.

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.

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

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.

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

Eigenschap (ontwerper)	Eigenschap (JSON)	Verplicht	Waarde	Beschrijving
Verificatie	type	Ja	Eenvoudig	Het te gebruiken verificatietype
Gebruikersnaam	username	Ja	< gebruikersnaam>	De gebruikersnaam voor het verifiëren van toegang tot het doelservice-eindpunt
Wachtwoord	password	Ja	< 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": {}
}

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

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.

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

Eigenschap (ontwerper)	Eigenschap (JSON)	Verplicht	Waarde	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-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	Nee	< Wachtwoord-voor-PFX-bestand>	Het wachtwoord voor toegang tot het PFX-bestand

Notitie

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

BadRequest: Could not load private key

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

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

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

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

Belangrijk

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

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

• De beveiliging voor API's verbeteren met behulp van verificatie van clientcertificaten in Azure API Management
• De beveiliging voor back-endservices verbeteren met behulp van verificatie van clientcertificaten in Azure API Management
• De beveiliging voor uw RESTful-service verbeteren met behulp van clientcertificaten
• Certificaatreferenties voor toepassingsverificatie
• Een TLS/SSL-certificaat gebruiken in uw code in Azure App Service

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

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.

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)	Verplicht	Waarde	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-voor-autoriteit-token-uitgever>	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.
Huurder	tenant	Ja	< tenant-id>	De tenant-id voor de Microsoft Entra-tenant
Audiëntie	audience	Ja	< resource te autoriseren>	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	< 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": {}
}

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.

Ruwe 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

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 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)	Verplicht	Waarde	Beschrijving
Verificatie	type	Ja	Rauw	Het te gebruiken verificatietype
Waarde	value	Ja	< authorization-header-waarde>	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 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.

  Notitie

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

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

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

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

   Ingebouwde triggers en acties

   Eigenschap (ontwerper)	Eigenschap (JSON)	Verplicht	Waarde	Beschrijving
   Verificatie	type	Ja	Beheeridentiteit of ManagedServiceIdentity	Het te gebruiken verificatietype
   Beheeridentiteit	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	< doel-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 alle vereiste afsluitende schuine strepen. 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 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)	Verplicht	Waarde	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 voor het maken van verbindingen

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

• U kunt Azure Logic Apps in Azure Government gebruiken die alle impactniveaus ondersteunen in de regio's zoals beschreven in de Azure Government Impact Level 5 Isolation Guidance. 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 of een XML-transformatie wilt uitvoeren, maakt en roept u een Azure-functie aan in plaats van de inline-codefunctie te gebruiken of assembly's te leveren om als mappings te 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:

  • Azure-app Service-abonnementen
  • Netwerkopties van Azure Functions
  • Azure Dedicated Hosts voor virtuele machines
  • Isolatie van virtuele machines in Azure
  • Toegewezen Azure-services implementeren in virtuele netwerken

Raadpleeg de volgende documentatie voor meer informatie over isolatie:

• Isolatie in de openbare Azure-cloud
• Beveiliging voor zeer gevoelige IaaS-apps in Azure

Gerelateerde inhoud

• Azure-beveiligingsbasislijn voor Azure Logic Apps
• Implementatie automatiseren voor Azure Logic Apps
• Logische apps controleren