Beveiligde toegang en gegevens in Azure Logic Apps

Azure Logic Apps is afhankelijk van Azure Storage om data-at-rest op te slaan en automatisch te versleutelen. Met deze versleuteling worden uw gegevens beschermd en kunt u voldoen aan de beveiligings- en nalevingsverplichtingen van uw organisatie. Standaard gebruikt Azure Storage door Microsoft beheerde sleutels om uw gegevens te versleutelen. Zie versleuteling Azure Storage data-at-rest voor meer informatie.

Als u de toegang tot en het beveiligen van gevoelige gegevens in Azure Logic Apps, kunt u op deze gebieden meer beveiliging instellen:

• Toegang voor inkomende aanroepen naar triggers op basis van aanvragen
• Toegang tot bewerkingen van logische apps
• Toegang tot invoer en uitvoer van de uitvoer van de uitvoergeschiedenis
• Toegang tot parameterinvoer
• Toegang voor uitgaande aanroepen naar andere services en systemen
• Het maken van verbindingen voor specifieke connectors blokkeren
• Richtlijnen voor isolatie voor logische apps
• Azure-beveiligingsbasislijn voor Azure Logic Apps

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

• Overzicht van Azure-versleuteling
• Azure Data Encryption-at-Rest
• Azure Security-benchmark

Toegang voor inkomende aanroepen naar triggers op basis van aanvragen

Inkomende aanroepen die een logische app ontvangt via een trigger op basis van aanvragen, zoals de trigger Aanvraag of HTTP-webhook, ondersteunen versleuteling en worden beveiligd met Transport Layer Security (TLS) 1.2,voorheen bekend als Secure Sockets Layer (SSL). Logic Apps wordt deze versie afgedwongen bij het ontvangen van een inkomende aanroep naar de aanvraagtrigger of een callback naar de HTTP-webhooktrigger of -actie. Als er TLS-handshakefouten optreden, moet u ervoor zorgen dat u TLS 1.2 gebruikt. Zie Het TLS 1.0-probleem oplossen voor meer informatie.

Gebruik voor binnenkomende aanroepen de volgende coderingssuites:

• 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

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

• Shared Access Signatures (SAS) genereren
• Open Azure Active Directory inschakelen (Azure AD OAuth)
• Uw logische app beschikbaar maken met Azure API Management
• Binnenkomende IP-adressen beperken

Shared Access Signatures (SAS) genereren

Elk aanvraag-eindpunt in een logische app heeft een Shared Access Signature (SAS) in de URL van het eindpunt, die deze indeling volgt:

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

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

Inkomende aanroepen naar een aanvraag-eindpunt kunnen slechts één autorisatieschema gebruiken, SAS of Azure Active Directory Open Authentication. Hoewel met het ene schema het andere schema niet wordt uitgeschakeld, veroorzaakt het gebruik van beide schema's tegelijkertijd een fout omdat de service niet weet welk schema moet worden gekozen.

Zie deze secties in dit onderwerp voor meer informatie over het beveiligen van toegang met SAS:

• Toegangssleutels regenereren
• Verlopende callback-URL's maken
• URL's maken met primaire of secundaire sleutel

Toegangssleutels regenereren

Als u op elk moment een nieuwe beveiligingstoegangssleutel wilt genereren, gebruikt u de Azure-REST API of Azure Portal. Alle eerder gegenereerde URL's die gebruikmaken van de oude sleutel zijn ongeldig en hebben niet langer autorisatie om de logische app te activeren. De URL's die u op haalt na het opnieuw maken, zijn ondertekend met de nieuwe toegangssleutel.

1. Open in Azure Portalde logische app met de sleutel die u opnieuw wilt maken.

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

3. Selecteer de sleutel die u opnieuw wilt maken en rond het proces af.

Verlopende callback-URL's maken

Als u de eindpunt-URL voor een trigger op aanvraag deelt met andere partijen, kunt u callback-URL's genereren die gebruikmaken van specifieke sleutels en vervaldatums hebben. Op die manier kunt u naadloos sleutels rollen 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 Logic Apps REST API, bijvoorbeeld:

POST /subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.Logic/workflows/<workflow-name>/triggers/<trigger-name>/listCallbackUrl?api-version=2016-06-01

Neem in de body de eigenschap NotAfter op met behulp van een JSON-datumreeks. Deze eigenschap retourneert een callback-URL die alleen geldig is tot de NotAfter datum en tijd.

URL's maken met een primaire of secundaire geheime sleutel

Wanneer u callback-URL's genereert of vermeldt voor een trigger op basis van aanvragen, 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 Logic Apps REST API, bijvoorbeeld:

POST /subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.Logic/workflows/<workflow-name>/triggers/<trigger-name>/listCallbackUrl?api-version=2016-06-01

Neem in de body de eigenschap KeyType op als Primary of Secondary . Deze eigenschap retourneert een URL die is ondertekend door de opgegeven beveiligingssleutel.

Open Azure Active Directory inschakelen (Azure AD OAuth)

Voor inkomende aanroepen naar een eindpunt dat is gemaakt door een trigger op basis van aanvragen, kunt u Azure AD OAuth inschakelen door een autorisatiebeleid voor uw logische app te definiëren of toe te voegen. Op deze manier gebruiken inkomende aanroepen OAuth-toegangstokens voor autorisatie.

Wanneer uw logische app een inkomende aanvraag ontvangt die een OAuth-toegangsteken 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 autorisatie voor de binnenkomende aanvraag. Het token kan meer claims hebben dan het nummer dat is opgegeven door het autorisatiebeleid.

Overwegingen voordat u Azure AD OAuth inschakelen

• Een binnenkomende aanroep naar het aanvraag-eindpunt kan slechts één autorisatieschema gebruiken: Azure AD OAuth of Shared Access Signature (SAS). Hoewel met het ene schema het andere schema niet wordt uitgeschakeld, veroorzaakt het gebruik van beide schema's tegelijkertijd een fout omdat de Logic Apps-service niet weet welk schema moet worden gekozen.

• Alleen Bearer-type autorisatieschema's worden ondersteund voor Azure AD OAuth-toegangstokens, wat betekent dat de header voor het Authorization toegangstoken het type moet Bearer opgeven.

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

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

  Stel bijvoorbeeld dat uw logische app een autorisatiebeleid heeft dat twee claimtypen vereist: Doelgroep en Verlener. Dit voorbeeld van een nettoladingsectie voor een gedecodeerd toegang token bevat beide claimtypen, waarbij de aud doelgroepwaarde iss is en de waarde voor Vergever:

  {
      "aud": "https://management.core.windows.net/",
      "iss": "https://sts.windows.net/<Azure-AD-issuer-ID>/",
      "iat": 1582056988,
      "nbf": 1582056988,
      "exp": 1582060888,
      "_claim_names": {
         "groups": "src1"
      },
      "_claim_sources": {
         "src1": {
            "endpoint": "https://graph.windows.net/7200000-86f1-41af-91ab-2d7cd011db47/users/00000-f433-403e-b3aa-7d8406464625d7/getMemberObjects"
         }
      },
      "acr": "1",
      "aio": "AVQAq/8OAAAA7k1O1C2fRfeG604U9e6EzYcy52wb65Cx2OkaHIqDOkuyyr0IBa/YuaImaydaf/twVaeW/etbzzlKFNI4Q=",
      "amr": [
         "rsa",
         "mfa"
      ],
      "appid": "c44b4083-3bb0-00001-b47d-97400853cbdf3c",
      "appidacr": "2",
      "deviceid": "bfk817a1-3d981-4dddf82-8ade-2bddd2f5f8172ab",
      "family_name": "Sophia Owen",
      "given_name": "Sophia Owen (Fabrikam)",
      "ipaddr": "167.220.2.46",
      "name": "sophiaowen",
      "oid": "3d5053d9-f433-00000e-b3aa-7d84041625d7",
      "onprem_sid": "S-1-5-21-2497521184-1604012920-1887927527-21913475",
      "puid": "1003000000098FE48CE",
      "scp": "user_impersonation",
      "sub": "KGlhIodTx3XCVIWjJarRfJbsLX9JcdYYWDPkufGVij7_7k",
      "tid": "72f988bf-86f1-41af-91ab-2d7cd011db47",
      "unique_name": "SophiaOwen@fabrikam.com",
      "upn": "SophiaOwen@fabrikam.com",
      "uti": "TPJ7nNNMMZkOSx6_uVczUAA",
      "ver": "1.0"
  }
  

Azure AD OAuth inschakelen voor uw logische app

Volg deze stappen voor de sjabloon Azure Portal of Azure Resource Manager sjabloon:

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

De header 'Autorisatie' opnemen in de uitvoer van de aanvraagtrigger

Voor logische apps die Azure Active Directory Open Authentication (Azure AD OAuth) inschakelen voor het autoriseren van inkomende aanroepen voor toegang tot triggers op basis van aanvragen, kunt u de uitvoer van de aanvraagtrigger of HTTP Webhook-trigger inschakelen om de header van het OAuth-toegangsteken op te Authorization nemen. Voeg in de onderliggende JSON-definitie van de trigger de eigenschap toe en stel operationOptions deze in op IncludeAuthorizationHeadersInOutputs . Hier is 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 - Aanvraagtrigger
• Schemaverwijzing voor trigger- en actietypen - HTTP-webhooktrigger
• Schemaverwijzing voor trigger- en actietypen - Bewerkingsopties

Uw logische app beschikbaar maken met Azure API Management

Voor meer verificatieprotocollen en -opties kunt u uw logische app beschikbaar maken als een API met behulp van Azure API Management. Deze service biedt uitgebreide mogelijkheden voor bewaking, beveiliging, beleid en documentatie voor elk eindpunt. API Management kunt een openbaar of privé-eindpunt voor uw logische app beschikbaar maken. Als u toegang tot dit eindpunt wilt autorisatie, kunt u Azure Active Directory Open Authentication (Azure AD OAuth), clientcertificaat of andere beveiligingsstandaarden gebruiken. Wanneer API Management een aanvraag ontvangt, verzendt de service de aanvraag naar uw logische app en maakt de service de benodigde transformaties of beperkingen. Als u alleen API Management logische app wilt aanroepen, kunt u de binnenkomende IP-adressen vanuw logische app beperken.

Bekijk de volgende documentatie voor meer informatie:

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

Binnenkomende IP-adressen beperken

Samen met Shared Access Signature (SAS) wilt u mogelijk specifiek de clients beperken die uw logische app kunnen aanroepen. Als u bijvoorbeeld uw aanvraag-eindpunt beheert met behulp van Azure API Management,kunt u uw logische app beperken tot het accepteren van aanvragen alleen vanaf het IP-adres voor het API Management-service-exemplaardat u maakt.

Ongeacht de IP-adressen die u opgeeft, kunt u nog steeds een logische app uitvoeren die een trigger op basis van aanvragen heeft met behulp van de Logic Apps REST API: Werkstroomtriggers - Aanvraag uitvoeren of met behulp van API Management. Dit scenario vereist echter nog steeds verificatie met behulp van de Azure REST API. Alle gebeurtenissen worden weergegeven in het Auditlogboek van Azure. Zorg ervoor dat u het toegangsbeheerbeleid dienovereenkomstig in stelt.

Als u de binnenkomende IP-adressen voor uw logische app wilt beperken, volgt u deze stappen voor de Azure Portal of uw Azure Resource Manager sjabloon:

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

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

Toegang tot bewerkingen van logische apps

U kunt alleen specifieke gebruikers of groepen toestaan specifieke taken uit te voeren, zoals het beheren, bewerken en weergeven van logische apps. Gebruik op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC)om de machtigingen te bepalen. U kunt ingebouwde of aangepaste rollen toewijzen aan leden die toegang hebben tot uw Azure-abonnement. Azure Logic Apps heeft deze specifieke rollen:

• Inzender voor logischeapps: hiermee kunt u logische apps beheren, maar u kunt de toegang tot deze apps niet wijzigen.

• Operator voor logische apps:hiermee kunt u logische apps lezen, inschakelen en uitschakelen, maar u kunt ze niet bewerken of bijwerken.

• Inzender:verleent volledige toegang voor het beheren van alle resources, maar biedt u niet de mogelijkheid om rollen toe te wijzen in Azure RBAC, toewijzingen te beheren in Azure Blueprints of galerieën met afbeeldingen te delen.

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

Als u wilt voorkomen dat anderen uw logische app wijzigen of verwijderen, kunt u Azure Resource Lock gebruiken. Met deze mogelijkheid voorkomt u dat anderen productiebronnen wijzigen of verwijderen. Voor meer informatie over verbindingsbeveiliging, bekijkt u Verbindingsconfiguratie in Azure Logic Apps en Verbindingsbeveiliging en -versleuteling.

Toegang tot gegevens van de run history

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

Wanneer u de uitvoergeschiedenis van uw logische app bekijkt, verifieert Logic Apps uw toegang en geeft het vervolgens koppelingen naar de in- en uitvoer voor de aanvragen en antwoorden voor elke run. Voor acties die wachtwoorden, geheimen, sleutels of andere gevoelige informatie verwerken, wilt u echter voorkomen dat anderen die gegevens weergeven en openen. Als uw logische app bijvoorbeeld een geheim van de Azure Key Vault dat moet worden gebruikt bij het authenticeren van een HTTP-actie, wilt u dat geheim verbergen in de weergave.

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

• Beperk de toegang op IP-adresbereik.

  Met deze optie kunt u de toegang tot de geschiedenis van de run beveiligen op basis van de aanvragen van een specifiek IP-adresbereik.

• Beveilig gegevens in de run history met behulp van obfuscation.

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

Toegang beperken op IP-adresbereik

U kunt de toegang tot de invoer en uitvoer in de uitvoergeschiedenis van uw logische app beperken, zodat alleen aanvragen van specifieke IP-adresbereiken die gegevens kunnen weergeven.

Als u bijvoorbeeld wilt blokkeren 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, waardoor 'Just-In-Time'-toegang tot de gegevens van uw logische app mogelijk is.

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

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

Gegevens in de run history beveiligen met behulp van obfuscation

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

Overwegingen voor het beveiligen van invoer en uitvoer

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

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

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

• Als u uitvoer van een actie wilt beveiligen die invoer verborgen of expliciet verborgen wilt houden, moet u in die actie handmatig Beveiligde uitvoer in- of uit te voeren.

• Zorg ervoor dat u Beveiligde invoer of Beveiligde uitvoer in de downstreamacties in bedrijf hebt, waarbij u verwacht dat de gegevens door de uitvoergeschiedenis worden verborgen.

  Instelling voor beveiligde uitvoer

  Wanneer u beveiligde uitvoer handmatig in een trigger of actie in Logic Apps, worden deze uitvoer in de uitvoergeschiedenis verborgen. Als voor een downstreamactie expliciet deze beveiligde uitvoer wordt gebruikt als invoer, worden de invoer van deze actie in de uitvoergeschiedenis verborgen door 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, verbergt de instelling ook de uitvoer van deze acties. Als deze acties expliciet de upstream beveiligde uitvoer als invoer gebruiken, verbergt Logic Apps de invoer en uitvoer van deze acties, maar wordt de instelling Beveiligde invoer van deze acties niet ingeschakeld. Als voor een downstreamactie expliciet de verborgen uitvoer van de acties Compose, Parse JSON of Response als invoer wordt gebruikt, verbergt Logic Apps de invoer of uitvoer van deze downstreamactie niet.

  

  Instelling voor beveiligde invoer

  Wanneer u handmatig Beveiligde invoer in een trigger of actie in Logic Apps, worden deze invoer verborgen in de geschiedenis van de run. Als voor een downstreamactie expliciet de zichtbare uitvoer van die trigger of actie als invoer wordt gebruikt, verbergt Logic Apps de invoer van deze downstreamactie in de uitvoergeschiedenis, maar worden in deze actie geen beveiligde invoer ingeschakeld en worden de uitvoer van deze actie niet verborgen.

  

  Als de acties Compose, Parse JSON en Response expliciet gebruikmaken van de zichtbare uitvoer van de trigger of actie die de beveiligde invoer heeft, verbergt Logic Apps de invoer en uitvoer van deze acties, maar wordt de instelling Beveiligde invoer van deze actie niet ingeschakeld. Als voor een downstreamactie expliciet de verborgen uitvoer van de acties Compose, Parse JSON of Response als invoer wordt gebruikt, verbergt Logic Apps de invoer of uitvoer van deze downstreamactie niet.

  

Beveiligde invoer en uitvoer in de ontwerpfunctie

1. Open in Azure Portalde logische app in de ontwerpfunctie voor logische apps.

   

2. Selecteer op de trigger of actie waar u gevoelige gegevens wilt beveiligen de knop met het beletselletsel (...) en selecteer vervolgens Instellingen.

   

3. Schakel Beveiligde invoer, Beveiligde uitvoer of beide in. Wanneer u klaar bent, selecteert u Gereed.

   

   De actie of trigger toont nu een vergrendelingspictogram in de titelbalk.

   

   Tokens die beveiligde uitvoer van eerdere acties vertegenwoordigen, tonen ook vergrendelingspictogrammen. Wanneer u bijvoorbeeld een dergelijke uitvoer uit de lijst met dynamische inhoud selecteert voor gebruik in een actie, wordt in dat token een vergrendelingspictogram weergegeven.

   

4. Nadat de logische app is uitgevoerd, kunt u de geschiedenis voor die run bekijken.

   1. Selecteer in het deelvenster Overzicht van de logische app de run die u wilt weergeven.

   2. Vouw in het deelvenster Uitvoeren van logische app de acties uit die u wilt bekijken.

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

      

Beveiligde invoer en uitvoer in codeweergave

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

• "inputs": beveiligt invoer in de run history.
• "outputs": Beveiligt uitvoer in de uitvoergeschiedenis.

"<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 implementeert in verschillende omgevingen, kunt u overwegen de waarden in uw werkstroomdefinitie te parameteriseren die variëren op basis van deze omgevingen. Op die manier kunt u in code gecodeerde gegevens vermijden door een Azure Resource Manager-sjabloon te gebruiken om uw logische app te implementeren, gevoelige gegevens te beveiligen door beveiligde parameters te definiëren en die gegevens als afzonderlijke invoer door te geven via de parameters van de sjabloon met behulp van een parameterbestand.

Als u bijvoorbeeld HTTP-acties verifieert met Azure Active Directory Open Authentication (Azure AD OAuth), 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 in uw logische app wilt definiëren, gebruikt u de sectie in de werkstroomdefinitie van uw logische app en Resource Manager parameters 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 run history, definieert u de parameters met behulp van het type of en gebruikt u zo nodig securestring secureobject codering. Parameters met dit type worden niet geretourneerd met de resourcedefinitie en zijn niet toegankelijk wanneer de resource na de implementatie wordt bekeken. Als u tijdens runtime toegang wilt krijgen tot deze parameterwaarden, gebruikt u @parameters('<parameter-name>') de expressie in uw werkstroomdefinitie. Deze expressie wordt alleen geëvalueerd tijdens runtime en wordt beschreven door de definitietaal van de werkstroom.

Zie deze secties in dit onderwerp voor meer informatie:

• Parameters in werkstroomdefinities beveiligen
• Gegevens in de run history beveiligen met behulp van obfuscation

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

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

• Gevoelige waarden doorgeven tijdens de implementatie met behulp van Azure Key Vault
• Parameters in de Azure Resource Manager verder in dit onderwerp beveiligen

Parameters in werkstroomdefinities beveiligen

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 logische app hebt opgeslagen. Stel dat u een HTTP-actie hebt die basisverificatie vereist, waarbij een gebruikersnaam en wachtwoord worden gebruikt. In de werkstroomdefinitie parameters definieert de sectie de basicAuthPasswordParam parameters en met behulp van het type basicAuthUsernameParam securestring . De actiedefinitie verwijst vervolgens naar deze parameters in de authentication sectie .

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

Parameters in Azure Resource Manager sjablonen beveiligen

Een Resource Manager sjabloon 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 definitieniveau van de werkstroom met behulp van het securestring secureobject type of. U kunt deze waarden vervolgens opslaan in Azure Key Vault en het parameterbestand gebruiken om te verwijzen naar de sleutelkluis en het geheim. De sjabloon haalt die informatie vervolgens op tijdens de implementatie. Zie Pass sensitive values at deployment by using Azure Key Vault (Gevoelige waarden doorgeven tijdens de implementatie met behulp van Azure Key Vault.

Hier vindt u meer informatie over parameters deze secties:

• Op het hoogste niveau van de sjabloon definieert een sectie de parameters voor de waarden die de parameters sjabloon tijdens de implementatie gebruikt. Deze waarden kunnen bijvoorbeeld verbindingsreeksen bevatten voor een specifieke implementatieomgeving. U kunt deze waarden vervolgens opslaan in een afzonderlijk parameterbestand, waardoor u deze waarden gemakkelijker kunt wijzigen.

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

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

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

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

Toegang voor uitgaande aanroepen naar andere services en systemen

Uitgaande aanroepen die worden verzonden door de HTTP-triggerof HTTP-actie, ondersteunen versleuteling op basis van de mogelijkheid van het doel-eindpunt en worden beveiligd met Transport Layer Security (TLS) 1.0, 1.1 of 1.2,voorheen bekend als Secure Sockets Layer (SSL). Logic Apps onderhandelt met het doel-eindpunt over het gebruik van de hoogst mogelijke versie die wordt ondersteund. Als het doel-eindpunt bijvoorbeeld 1.2 ondersteunt, gebruikt de HTTP-trigger of -actie eerst 1.2. Anders gebruikt de connector de op een na hoogste ondersteunde versie.

Hier vindt u informatie over zelf-ondertekende TLS/SSL-certificaten:

• Voor logische apps in de globale omgeving met meerdere tenants Azure Logic Apps, staan HTTP-bewerkingen geen zelf-ondertekende TLS/SSL-certificaten toe. Als uw logische app een HTTP-aanroep naar een server maakt en een zelf-ondertekend TLS/SSL-certificaat presenteert, mislukt de HTTP-aanroep met een TrustFailure fout.

• Voor logische apps in de omgeving met Azure Logic Apps tenant ondersteunen HTTP-bewerkingen zelf-ondertekende TLS/SSL-certificaten. U moet echter een paar extra stappen voor dit verificatietype voltooien. Anders mislukt de aanroep. Bekijk TSL/SSL-certificaatverificatievoor één tenant en Azure Logic Apps.

  Als u in plaats daarvan clientcertificaat of Azure Active Directory Open Authentication (Azure AD OAuth) wilt gebruiken met het referentietype Certificaat, moet u nog enkele extra stappen uitvoeren voor dit verificatietype. Anders mislukt de aanroep. Zie Clientcertificaat of Azure Active Directory Open Authentication (Azure AD OAuth)met het referentietype Certificaat voor één tenant Azure Logic Apps.

• Voor logische apps in een ISE (Integration Service Environment)staat de HTTP-connector zelf-ondertekende certificaten voor TLS/SSL-handshakes toe. U moet echter eerst zelf-ondertekende certificaatondersteuning inschakelen voor een bestaande ISE of nieuwe ISE met behulp van de Logic Apps REST API en het openbare certificaat op de locatie TrustedRoot installeren.

Hier volgen meer manieren waarop u eindpunten kunt beveiligen die aanroepen verwerken die vanuit uw logische app worden verzonden:

• 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

  • Active Directory OAuth-verificatie

  • Verificatie van beheerde identiteit

• Beperk de toegang vanaf IP-adressen van logische apps.

  Alle aanroepen naar eindpunten van logische apps zijn afkomstig van specifieke aangewezen IP-adressen die zijn gebaseerd op de regio's van uw logische apps. U kunt filters toevoegen die alleen aanvragen van deze IP-adressen accepteren. Zie Limieten en configuratie voor Azure Logic Apps om deze IP-adressen op te Azure Logic Apps.

• De beveiliging voor verbindingen met on-premises systemen verbeteren.

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

  • On-premises gegevensgateway

    Veel beheerde connectors in Azure Logic Apps beveiligde verbindingen met on-premises systemen, zoals Bestandssysteem, SQL, SharePoint en DB2. De gateway verzendt gegevens van on-premises bronnen via versleutelde kanalen via de 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-exemplaarte maken, kunt u die API aanroepen in de werkstroom van uw logische app door de ingebouwde API Management-trigger of -actie te selecteren in logic App Designer.

    Notitie

    De connector toont alleen de API Management services waar u machtigingen hebt om weer te geven en verbinding te maken, maar die geen op verbruik gebaseerde API Management weergeven.

    1. Voer in de ontwerpfunctie voor logische apps api management in het zoekvak in. Kies de stap op basis van het toevoegen van een trigger of een actie:

       • Als u een trigger toevoegt, wat altijd de eerste stap in uw werkstroom is, selecteert u Een Azure-trigger API Management selecteren.

       • Als u een actie toevoegt, selecteert u Een Azure-API Management kiezen.

       In dit voorbeeld wordt een trigger toegevoegd:

       

    2. Selecteer het eerder gemaakte API Management service-exemplaar.

       

    3. Selecteer de API-aanroep die u wilt gebruiken.

       

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 logic app designer hebben triggers en acties die ondersteuning bieden voor het kiezen van een verificatietype een verificatie-eigenschap. Deze eigenschap wordt echter mogelijk niet altijd standaard weergegeven. In deze gevallen opent u bij de trigger of actie de lijst Nieuwe parameter toevoegen en selecteert u Verificatie.

Verificatietypen voor triggers en acties die verificatie ondersteunen

Deze tabel identificeert de verificatietypen die beschikbaar zijn voor de triggers en acties waar u een verificatietype kunt selecteren:

Basisverificatie

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

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

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

Verificatie van clientcertificaten

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

Wanneer u beveiligde parameters gebruikt voor het verwerken en beveiligen van gevoelige informatie, bijvoorbeeld in een Azure Resource Manager-sjabloonvoor het automatiseren van de implementatie, kunt u expressies gebruiken om tijdens runtime toegang te krijgen tot deze parameterwaarden. In dit voorbeeld van een HTTP-actiedefinitie wordt de verificatie opgegeven als en wordt de type ClientCertificate 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": {}
}

Zie 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 van uw RESTfuL-service verbeteren met behulp van clientcertificaten
• Certificaatreferenties voor toepassingsverificatie
• Een TLS/SSL-certificaat gebruiken in uw code in Azure App Service

Azure Active Directory Verificatie openen

In Aanvraagtriggers kunt u Azure Active Directory Open Authentication (Azure AD OAuth)gebruiken om binnenkomende aanroepen te authenticeren nadat u Azure AD-autorisatiebeleid hebt ingesteld voor uw logische app. Voor alle andere triggers en acties die het Active Directory OAuth-verificatietype bieden dat u kunt selecteren, geeft u deze eigenschapswaarden op:

Wanneer u beveiligde parameters gebruikt voor het verwerken en beveiligen van gevoelige informatie, bijvoorbeeld in een Azure Resource Manager-sjabloonvoor het automatiseren van de implementatie, kunt u expressies gebruiken om tijdens runtime toegang te krijgen tot deze parameterwaarden. In dit voorbeeld van een HTTP-actiedefinitie wordt de verificatie opgegeven als , het referentietype als en wordt de functie parameters() gebruikt om type ActiveDirectoryOAuth de Secret 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": {}
}

Onbewerkte verificatie

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

Hier volgt bijvoorbeeld een voorbeeldheader voor een HTTPS-aanvraag die het OAuth 1.0-protocol volgt:

Authorization: OAuth realm="Photos",
   oauth_consumer_key="dpf43f3p2l4k3l03",
   oauth_signature_method="HMAC-SHA1",
   oauth_timestamp="137131200",
   oauth_nonce="wIjqoS",
   oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
   oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"

Geef in de trigger of actie die onbewerkte verificatie ondersteunt deze eigenschapswaarden op:

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

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

Verificatie van beheerde identiteit

Wanneer de optie voor beheerde identiteit beschikbaar is in de triggerof actie die verificatie van beheerde identiteiten ondersteunt, kan uw logische app deze identiteit gebruiken voor het verifiëren van toegang tot Azure-resources die worden beveiligd met Azure Active Directory (Azure AD), in plaats van referenties, geheimen of Azure AD-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 Azure AD-tokens hoeft te gebruiken. Meer informatie over Azure-services die beheerde identiteiten ondersteunen voor Azure AD-verificatie.

• Het resourcetype Logische app (verbruik) kan de door het systeem toegewezen identiteit of één handmatig gemaakte door de gebruiker toegewezen identiteit gebruiken.

• Het resourcetype Logische app (Standard) kan alleen gebruikmaken van de door het systeem toegewezen identiteit, die automatisch wordt ingeschakeld. De door de gebruiker toegewezen identiteit is momenteel niet beschikbaar.

1. Voordat uw logische app een beheerde identiteit kan gebruiken, volgt u de stappen in Toegang tot Azure-resources verifiëren met behulp van beheerde identiteiten in Azure Logic Apps. Met deze stappen wordt de beheerde identiteit in uw logische app ingeschakeld en wordt de toegang van die identiteit tot de Azure-doelresource ingesteld.

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

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

   Ingebouwde triggers en acties

   Eigenschap (ontwerper)	Eigenschap (JSON)	Vereist	Waarde	Beschrijving
   Verificatie	type	Yes	Beheerde identiteit of ManagedServiceIdentity	Het te gebruiken verificatietype
   Beheerde identiteit	identity	Yes	* Door het systeem toegewezen beheerde identiteit of SystemAssigned * <user-assigned-identity-ID>	De beheerde identiteit die moet worden gebruikt
   Doelgroep	audience	Yes	<target-resource-ID>	De resource-id voor de doelresource die u wilt openen. Maakt de https://storage.azure.com/ toegangstokens voor verificatie bijvoorbeeld geldig voor alle opslagaccounts. U kunt echter ook een URL voor de hoofdservice opgeven, zoals https://fabrikamstorageaccount.blob.core.windows.net voor een specifiek opslagaccount. Opmerking: De eigenschap Doelgroep is mogelijk verborgen in sommige triggers of acties. Als u deze eigenschap zichtbaar wilt maken, opent u in de trigger of actie de lijst Nieuwe parameter toevoegen en selecteert u Doelgroep. Belangrijk: zorg ervoor dat deze doelresource-id exact overeenkomt met de waarde die Azure AD verwacht, inclusief eventuele vereiste slashes. Voor de https://storage.azure.com/ resource-id voor alle Azure Blob Storage accounts is dus een slash vereist. Voor de resource-id voor een specifiek opslagaccount is echter geen schuine streep nodig. Zie Azure-servicesdie ondersteuning bieden voor Azure AD om deze resource-ID's te vinden.

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

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

   Triggers en acties voor beheerde connectors

   Eigenschap (ontwerper)	Vereist	Waarde	Beschrijving
   Verbindingsnaam	Yes	<connection-name>
   Beheerde identiteit	Yes	Door het systeem toegewezen beheerde identiteit of <user-assigned-managed-identity-name>	Het te gebruiken verificatietype

Het maken van verbindingen blokkeren

Als uw organisatie het maken van verbinding met specifieke resources met behulp van de connectors in Azure Logic Apps niet toestaan, kunt u de mogelijkheid blokkeren om die verbindingen te maken voor specifieke connectors in logic app-werkstromen met behulp van Azure Policy. Zie Verbindingen blokkeren die zijn gemaakt door specifieke connectors in Azure Logic Apps.

Isolatie-richtlijnen voor logische apps

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

• Als u uw eigen code wilt uitvoeren of een XML-transformatie wilt uitvoeren, maakt en roept u een Azure-functieaan in plaats van de functie voor inlinecode te gebruiken of om respectievelijk assemblieste bieden die als kaarten kunnen worden gebruikt. Stel ook de hostingomgeving voor uw functie-app in om te voldoen aan uw isolatievereisten.

  Als u bijvoorbeeld wilt voldoen aan de impactniveau 5-vereisten, maakt u uw functie-app met het App Service-abonnement met behulp van de prijscategorie Isolated, samen met een App Service Environment (ASE) die ook gebruikmaakt van de prijscategorie Isolated. In deze omgeving worden functie-apps uitgevoerd op toegewezen virtuele Azure-machines en toegewezen virtuele Azure-netwerken, die netwerkisolatie bieden naast rekenisolatie voor uw apps en maximale mogelijkheden voor uitschalen.

  Bekijk de volgende documentatie voor meer informatie:

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

• Op basis van het gebruik van multi-tenant of single-tenant Azure Logic Apps,hebt u de volgende opties:

  • Met logische apps op basis van één tenant kunt u privé en veilig communiceren tussen werkstromen van logische apps en een virtueel Azure-netwerk door privé-eindpunten in te stellen voor inkomende verkeer en integratie van virtuele netwerken te gebruiken voor uitgaand verkeer. Lees Verkeer tussen virtuele netwerken en één tenant beveiligen voor Azure Logic Apps privé-eindpunten voor meer informatie.

  • Met logische apps op basis van meerdere tenants kunt u uw logische apps maken en uitvoeren in een ISE (Integration Service Environment). Op die manier worden uw logische apps uitgevoerd op toegewezen resources en hebben ze toegang tot resources die worden beveiligd door een virtueel Azure-netwerk. Voor meer controle over de versleutelingssleutels die door Azure Storage worden gebruikt, kunt u uw eigen sleutel instellen, gebruiken en beheren met behulp van Azure Key Vault. Deze mogelijkheid wordt ook wel 'Bring Your Own Key' (BYOK) genoemd en uw sleutel wordt een 'door de klant beheerde sleutel' genoemd. Zie Door de klant beheerde sleutels instellen voor het versleutelen van data-at-restvoor ISE's (Integration Service Environments) in Azure Logic Apps .

  Belangrijk

  Sommige virtuele Azure-netwerken gebruiken privé-eindpunten(Azure Private Link)voor toegang tot Azure PaaS-services, zoals Azure Storage, Azure Cosmos DB of Azure SQL Database, partnerservices of klantservices die worden gehost in Azure.

  Als uw werkstromen toegang nodig hebben tot virtuele netwerken die gebruikmaken van privé-eindpunten en u deze werkstromen wilt ontwikkelen met behulp van het resourcetype Logische app (verbruik), moet u uw logische apps maken en uitvoeren in een ISE. Als u deze werkstromen echter wilt ontwikkelen met behulp van het resourcetype Logische app (Standard), hebt u geen ISE nodig. In plaats daarvan kunnen uw werkstromen privé en veilig communiceren met virtuele netwerken door gebruik te maken van privé-eindpunten voor inkomende verkeer en integratie van virtuele netwerken voor uitgaand verkeer. Lees Verkeer tussen virtuele netwerken en één tenant beveiligen voor Azure Logic Apps privé-eindpunten voor meer informatie.

Lees de volgende documentatie voor meer informatie over isolatie:

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

Volgende stappen

• Azure-beveiligingsbasislijn voor Azure Logic Apps
• Implementatie voor Azure Logic Apps
• Logische apps bewaken