Schützen des Zugriffs und der Daten für Workflows in Azure Logic Apps

Artikel
10/15/2024

Azure Logic Apps nutzt Azure Storage zum Speichern und automatischen Verschlüsseln von ruhenden Daten. Diese Verschlüsselung schützt Ihre Daten und unterstützt Sie beim Einhalten der Sicherheits- und Complianceanforderungen Ihrer Organisation. Azure Storage verwendet standardmäßig von Microsoft verwaltete Schlüssel, um Ihre Daten zu verschlüsseln. Weitere Informationen finden Sie unter Azure Storage-Verschlüsselung für ruhende Daten.

Für eine stärkere Steuerung des Zugriffs und einen verbesserten Schutz von vertraulichen Daten in Azure Logic Apps können Sie in den folgenden Bereichen zusätzliche Sicherheit einrichten:

Zugriff auf Logik-App-Vorgänge
Zugriff auf Eingaben und Ausgaben von Ausführungsverläufen
Zugriff auf Parametereingaben
Authentifizierungstypen für Trigger und Aktionen, die die Authentifizierung unterstützen
Zugriff für eingehende Aufrufe anforderungsbasierter Trigger
Zugriff für ausgehende Aufrufe anderer Dienste und Systeme
Blockieren des Erstellens von Verbindungen für bestimmte Connectors
Isolationsanleitung für Logik-Apps
Azure-Sicherheitsbaseline für Azure Logic Apps

Weitere Informationen zur Sicherheit in Azure finden Sie in diesen Themen:

Zugriff auf Logik-App-Vorgänge

Damit Sie Logik-Apps und ihre Verbindungen erstellen oder verwalten können, benötigen Sie nur bei verbrauchsbasierten Logik-Apps bestimmte Berechtigungen. Diese werden durch Rollen über die rollenbasierte Azure-Zugriffssteuerung (Azure RBAC (Role-Based Access Control)) bereitgestellt. Sie können auch Berechtigungen einrichten, sodass nur bestimmte Benutzer oder Gruppen bestimmte Aufgaben ausführen können, z. B. das Verwalten, Bearbeiten und Anzeigen von Logik-Apps. Zum Steuern der Berechtigungen können Sie Mitgliedern, die Zugriff auf Ihr Azure-Abonnement haben, integrierte oder benutzerdefinierte Rollen zuweisen. Azure Logic Apps verfügt über die folgenden spezifischen Rollen, je nachdem, ob Sie über einen Workflow für Verbrauchs- oder Standardlogik-App verfügen:

Verbrauchsworkflows

Role	Beschreibung
Logik-App-Mitwirkender	Sie können die Workflows der Logik-App verwalten, aber Sie können den Zugriff auf sie nicht ändern.
Logik-App-Operator	Sie können Logic App-Workflows lesen, aktivieren und deaktivieren, aber Sie können sie nicht bearbeiten oder aktualisieren.
Mitwirkender	Sie haben vollen Zugriff auf die Verwaltung aller Ressourcen, aber Sie können keine Rollen in Azure RBAC zuweisen, Zuweisungen in Azure Blueprints verwalten oder Bildergalerien freigeben.

Nehmen wir zum Beispiel an, Sie müssen mit einem Logik-App-Workflow arbeiten, den Sie nicht erstellt haben, und die von diesem Logic-App-Workflow verwendeten Verbindungen authentifizieren. Ihr Azure-Abonnement erfordert Mitwirkender-Berechtigungen für die Ressourcengruppe, die diese Logik-App-Ressource enthält. Wenn Sie eine Logik-App-Ressource erstellen, haben Sie automatisch Zugriff als Mitwirkender.

Um zu verhindern, dass andere Ihren Logik-App-Workflow ändern oder löschen, können Sie Azure Resource Lock verwenden. Diese Funktion verhindert, dass andere Personen Produktionsressourcen ändern oder löschen. Weitere Informationen zur Verbindungssicherheit finden Sie unter Verbindungskonfiguration in Azure Logic Apps und Verbindungssicherheit und Verschlüsselung.

Workflows vom Typ „Standard“

Hinweis

Diese Funktion befindet sich in der Vorschauphase und unterliegt den Zusätzlichen Nutzungsbedingungen für Microsoft Azure-Vorschauversionen.

Role	Beschreibung
Logic Apps Standard Reader (Preview)	Sie haben schreibgeschützten Zugriff auf alle Ressourcen in einer Standard-Logik-App und -Workflows, einschließlich der Ausführung des Workflows und deren Verlauf.
Logic Apps Standard Operator (Preview)	Sie haben Zugriff auf die Aktivierung, Wiedervorlage und Deaktivierung von Workflows sowie auf die Erstellung von Verbindungen zu Diensten, Systemen und Netzwerken für eine Standard-Logik-App. Die Operatorrolle kann Verwaltungs- und Supportaufgaben auf der Azure Logic Apps-Plattform ausführen, verfügt jedoch nicht über Berechtigungen zum Bearbeiten von Workflows oder Einstellungen.
Logic Apps Standard Developer (Preview)	Sie haben Zugriff auf das Erstellen und Bearbeiten von Workflows, Verbindungen und Einstellungen für eine Standard-Logik-App. Die Rolle „Developer (Entwickler)“ hat keine Berechtigung, Änderungen außerhalb von Workflows vorzunehmen, z. B. anwendungsweite Änderungen wie die Konfiguration der Integration virtueller Netzwerke. App-Servicepläne werden nicht unterstützt.
Logic Apps Standard Contributor (Preview)	Sie haben Zugriff auf alle Aspekte einer Standard-Logik-App, aber Sie können den Zugriff oder das Eigentum nicht ändern.

Zugriff auf Ausführungsverlaufsdaten

Während der Ausführung einer Logik-App werden alle Daten bei der Übertragung mithilfe von Transport Layer Security (TLS) sowie im Ruhezustand verschlüsselt. Wenn Ihre Logik-App die Ausführung beendet hat, können Sie den Verlauf für diese Ausführung anzeigen, einschließlich der ausgeführten Schritte sowie Status, Dauer, Eingaben und Ausgaben für die einzelnen Aktionen. Diese umfangreichen Informationen geben einen Einblick in die Funktionsweise Ihrer Logik-App und zeigen, wo Sie bei der Problembehandlung ansetzen können.

Wenn Sie den Ausführungsverlauf Ihrer Logik-App anzeigen, authentifiziert Azure Logic Apps Ihren Zugriff und stellt dann Links zu den Ein- und Ausgaben für die Anforderungen und Antworten für jede Ausführung bereit. Bei Aktionen, die Kennwörter, Geheimnisse, Schlüssel oder andere sensible Informationen verarbeiten, sollten Sie jedoch verhindern, dass andere Personen diese Daten einsehen und darauf zugreifen. Wenn Ihre Logik-App beispielsweise ein Geheimnis aus Azure Key Vault erhält, das bei der Authentifizierung einer HTTP-Aktion verwendet werden soll, sollten Sie dieses Geheimnis ausblenden.

Um den Zugriff auf die Ein- und Ausgaben im Ausführungsverlauf Ihrer Logik-App zu steuern, stehen Ihnen folgende Optionen zur Verfügung:

Beschränken des Zugriffs nach IP-Adressbereich.

Mit dieser Option können Sie den Zugriff auf den Ausführungsverlauf basierend auf den Anforderungen aus einem bestimmten IP-Adressbereich schützen.
Schützen von Daten im Ausführungsverlauf mittels Obfuskation.

In vielen Triggern und Aktionen können Sie Eingaben, Ausgaben oder beides im Ausführungsverlauf einer Logik-App schützen.

Beschränken des Zugriffs nach IP-Adressbereich

Sie können den Zugriff auf die Eingaben und Ausgaben im Ausführungsverlauf für Ihre Logik-App-Workflows einschränken, sodass nur Anforderungen von bestimmten IP-Adressbereichen diese Daten anzeigen können.

Um beispielsweise den Zugriff auf Ein- und Ausgaben zu verhindern, geben Sie einen IP-Adressbereich wie z. B. 0.0.0.0-0.0.0.0 an. Nur Personen mit Administratorberechtigungen können diese Einschränkung aufheben, wodurch „Just-In-Time“-Zugriff auf Daten in Ihren Logik-App-Workflows ermöglicht wird. Gültige IP-Adressbereiche verwenden die Formate x.x.x.x/x oder x.x.x.x-x.x.x.x.

Führen Sie die folgenden Schritte für Ihre Verbrauchs- oder Standardlogik-App im Azure-Portal oder Ihrer Azure Resource Manager-Vorlage aus, um die zulässigen IP-Bereiche anzugeben:

Portal
Resource Manager-Vorlage

Verbrauchsworkflows

Öffnen Sie im Azure-Portal Ihren Verbrauchs-Logik-App-Workflow im Designer.
Wählen Sie im Menü der Logik-App unter Einstellungen die Option Workfloweinstellungen.
Wählen Sie im Abschnitt Konfiguration der Zugriffssteuerung unter zulässige eingehenden IP-Adressen in der Liste die Option „Zugriff auslösen“ und dann Bestimmte IP-Bereiche aus.
Geben Sie im Feld IP-Bereiche für Inhalte die IP-Adressbereiche an, die von Eingaben und Ausgaben auf Inhalte zugreifen können.

Workflows vom Typ „Standard“

Öffnen Sie im Azure-Portal Ihre Ressource vom Typ „Logic App (Standard)“.
Wählen Sie im Logik-App-Menü unter Einstellungen die Option Netzwerk aus.
Wählen Sie im Abschnitt Konfiguration des eingehenden Datenverkehrs neben Öffentlicher Netzwerkzugriff Aktiviert ohne Zugriffseinschränkung aus.
Wählen Sie auf der Seite Zugriffsbeschränkungen unter App-Zugriff Aus den ausgewählten virtuellen Netzwerken und IP-Adressen aktiviert aus.
Fügen Sie unter Websitezugriff und -regeln auf der Registerkarte Hauptwebsite eine oder mehrere Regeln entweder zu Anforderungen Zulassen oder Verweigern aus bestimmten IP-Bereichen hinzu. Sie können auch die HTTP-Headerfiltereinstellungen und Weiterleitungseinstellungen verwenden. Gültige IP-Adressbereiche verwenden die Formate x.x.x.x/x oder x.x.x.x-x.x.x.x.

Weitere Informationen finden Sie unter Blockieren eingehender IP-Adressen in Azure Logic Apps (Standard).

Verbrauchsworkflows

Geben Sie in Ihrer ARM-Vorlage die IP-Adressbereiche an, indem Sie den Abschnitt accessControl zusammen mit dem Abschnitt contents in der Ressourcendefinition ihrer Logik-App verwenden, z. B.:

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

Workflows vom Typ „Standard“

Geben Sie in Ihrer ARM-Vorlage die zulässigen eingehenden IP-Adressbereiche in der Ressourcendefinition ihrer Logik-App an, indem Sie den Abschnitt Microsoft.Web/sites/config verwenden. Fügen Sie in diesem Abschnitt unter properties den Abschnitt ipSecurityRestrictions hinzu und verwenden Sie die Abschnitte ipAddress, action="Deny" | "Allow", tag=Default, priority und name="Ports", um eine Regel zu definieren. Legen Sie ipAddress auf den zulässigen IP-Bereich im Format x.x.x.x/x oder x.x.x.x-x.x.x.x fest:

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

Schützen von Daten im Ausführungsverlauf mittels Obfuskation

Bei vielen Triggern und Aktionen stehen Einstellungen zur Verfügung, um Eingaben, Ausgaben oder beides im Ausführungsverlauf einer Logik-App zu schützen. Alle verwalteten Connectors und benutzerdefinierten Connectors unterstützen diese Optionen. Die folgenden integrierten Vorgänge unterstützen diese Optionen jedoch nicht:

Sichere Eingaben – Nicht unterstützt	Sichere Ausgaben – Nicht unterstützt
An Arrayvariable anfügen An Zeichenfolgenvariable anfügen Verringern eines Variablenwerts For each Wenn Erhöhen eines Variablenwerts Initialisieren einer Variablen Serie `Scope` Festlegen der Variablen Schalter Terminate Until	An Arrayvariable anfügen An Zeichenfolgenvariable anfügen Compose Verringern eines Variablenwerts For each Wenn Erhöhen eines Variablenwerts Initialisieren einer Variablen JSON-Analyse Serie Antwort `Scope` Festlegen der Variablen Schalter Terminate Until Warten

Überlegungen im Zusammenhang mit dem Schützen von Ein- und Ausgaben

Bevor Sie diese Einstellungen verwenden, um entsprechende Daten zu schützen, berücksichtigen Sie diese Aspekte.

Wenn Sie die Ein- oder Ausgaben für einen Trigger oder eine Aktion verbergen, sendet Azure Logic Apps die geschützten Daten nicht an Azure Log Analytics. Außerdem können Sie diesem Auslöser oder dieser Aktion keine nachverfolgten Eigenschaften zur Überwachung hinzufügen.
Die Azure Logic Apps-API zur Verarbeitung des Workflowverlaufs gibt keine sicheren Ausgaben zurück.
Um Ausgaben einer Aktion zu schützen, die Eingaben verbirgt oder explizit Ausgaben verbirgt, aktivieren Sie in dieser Aktion Sichere Ausgaben manuell.
Stellen Sie sicher, dass Sie Sichere Eingaben oder Sichere Ausgaben in nachfolgenden Aktionen aktivieren, bei denen Sie erwarten, dass die Daten im Ausführungsverlauf verborgen werden.

Einstellung „Sichere Ausgaben“

Wenn Sie Sichere Ausgaben in einem Trigger oder einer Aktion manuell aktivieren, blendet Azure Logic Apps diese Ausgaben im Ausführungsverlauf aus. Wenn eine nachfolgende Aktion diese sicheren Ausgaben explizit als Eingaben verwendet, blendet Azure Logic Apps die Eingaben dieser Aktion im Ausführungsverlauf aus, aktiviert aber nicht die Einstellung Sichere Eingaben der Aktion.

Die Aktionen „Erstellen“, „JSON analysieren“ und „Antwort“ weisen nur die Einstellung Sichere Eingaben auf. Wenn diese aktiviert wird, blendet diese Einstellung auch die Ausgaben dieser Aktionen aus. Wenn diese Aktionen explizit die sicheren Upstreamausgaben als Eingaben verwenden, blendet Azure Logic Apps die Ein- und Ausgaben dieser Aktionen aus, aktiviert aber nicht die Einstellung Sichere Eingaben dieser Aktionen. Wenn eine nachfolgende Aktion explizit die ausgeblendeten Ausgaben der Aktionen „Erstellen“, „JSON analysieren“ oder „Antwort“ als Eingaben verwendet, blendet Azure Logic Apps die Ein- oder Ausgaben dieser nachfolgenden Aktion nicht aus.

Einstellung „Sichere Eingaben“

Wenn Sie Sichere Eingaben in einem Trigger oder einer Aktion manuell aktivieren, blendet Azure Logic Apps diese Eingaben im Ausführungsverlauf aus. Wenn eine nachfolgende Aktion explizit die sichtbaren Ausgaben dieses Triggers oder dieser Aktion als Eingaben verwendet, blendet Azure Logic Apps die Eingaben dieser nachfolgenden Aktion im Ausführungsverlauf aus, aktiviert aber nicht die Option Sichere Eingaben in dieser Aktion und blendet die Ausgaben dieser Aktion nicht aus.

Wenn die Aktionen „Erstellen“, „JSON analysieren“ und „Antwort“ explizit die sichtbaren Ausgaben des Triggers oder der Aktion mit den sicheren Eingaben verwenden, blendet Azure Logic Apps die Ein- und Ausgaben dieser Aktionen, aktiviert aber nicht die Einstellung Sichere Eingaben der jeweiligen Aktion. Wenn eine nachfolgende Aktion explizit die ausgeblendeten Ausgaben der Aktionen „Erstellen“, „JSON analysieren“ oder „Antwort“ als Eingaben verwendet, blendet Azure Logic Apps die Ein- oder Ausgaben dieser nachfolgenden Aktion nicht aus.

Schützen von Ein- und Ausgaben im Designer

Öffnen Sie im Azure-Portal den Logik-App-Workflow im Designer.
Wählen Sie im Designer den Trigger oder die Aktion aus, bei dem/der Sie vertrauliche Daten schützen möchten.
Wählen Sie im daraufhin geöffneten Informationsbereich Einstellungen aus und erweitern Sie Sicherheit.
Aktivieren Sie entweder Sichere Eingaben, Sichere Ausgaben oder beides.

Der Trigger oder die Aktion zeigt jetzt ein Schlosssymbol in der Titelleiste an. Alle Token, die sichere Ausgaben aus früheren Aktionen darstellen, zeigen ebenfalls Schlosssymbole an. Wenn Sie beispielsweise in einer nachfolgenden Aktion ein Token für eine gesicherte Ausgabe aus der Liste mit dynamischen Inhalten ausgewählt haben, zeigt dieses Token ein Schlosssymbol an.
Nachdem der Workflow ausgeführt wurde, können Sie den Verlauf für diese Ausführung anzeigen.
1. Wählen Sie entweder im Menü der Verbrauchslogik-App oder im Standardworkflowmenü Übersicht aus.
2. Wählen Sie unter Ausführungsverlauf die Ausführung aus, die Sie anzeigen möchten.
3. Wählen Sie im Bereich „Workflowausführungsverlauf“ die Aktionen aus, die Sie überprüfen möchten.
  
  Wenn Sie sowohl die Ein- als auch die Ausgaben für die Absicherung ausgewählt haben, werden diese Werte jetzt ausgeblendet.

Schützen von Ein- und Ausgaben in der Codeansicht

Fügen Sie in der zugrunde liegenden Trigger- oder Aktionsdefinition das Array runtimeConfiguration.secureData.properties mit einem der folgenden Werte (oder mit beiden Werten) hinzu, oder aktualisieren Sie es entsprechend:

"inputs": Schützt Eingaben im Ausführungsverlauf.
"outputs": Schützt Ausgaben im Ausführungsverlauf.

"<trigger-or-action-name>": {
   "type": "<trigger-or-action-type>",
   "inputs": {
      <trigger-or-action-inputs>
   },
   "runtimeConfiguration": {
      "secureData": {
         "properties": [
            "inputs",
            "outputs"
         ]
      }
   },
   <other-attributes>
}

Zugriff auf Parametereingaben

Wenn Sie Bereitstellungen in verschiedenen Umgebungen durchführen, sollten Sie die Werte in Ihrer Workflowdefinition parametrisieren, die je nach Umgebung variieren. Auf diese Weise können Sie hartcodierte Daten vermeiden, indem Sie eine Azure Resource Manager-Vorlage verwenden, um Ihre Logikanwendung bereitzustellen, sensible Daten durch die Definition abgesicherter Parameter zu schützen und diese Daten als separate Eingaben durch die Parameter der Vorlage mithilfe einer Parameterdatei zu übergeben.

Wenn Sie z. B. HTTP-Aktionen mit OAuth mit Microsoft Entra ID authentifizieren, können Sie die Parameter definieren und verbergen, welche die Client-ID und das Clientgeheimnis akzeptieren, die für die Authentifizierung verwendet werden. Um diese Parameter im Workflow Ihrer Logik-App zu definieren, verwenden Sie den Abschnitt parameters innerhalb der Workflowdefinition Ihrer Logik-App und eine Resource Manager-Vorlage zur Bereitstellung. Um die Parameterwerte zu schützen, die beim Bearbeiten der Logik-App oder beim Anzeigen des Ausführungsverlaufs nicht angezeigt werden sollen, können Sie Parameter des Typs securestring oder secureobject definieren und bei Bedarf codieren. Parameter dieses Typs werden nicht mit der Ressourcendefinition zurückgegeben und sind beim Anzeigen der Ressource nach der Bereitstellung nicht zugänglich. Um zur Laufzeit auf diese Parameterwerte zuzugreifen, verwenden Sie den Ausdruck @parameters('<parameter-name>') in Ihrer Workflowdefinition. Dieser Ausdruck wird nur zur Laufzeit ausgewertet und durch die Workflowdefinitionssprache beschrieben.

Hinweis

Wenn Sie einen Parameter im Anforderungsheader oder -text verwenden, kann dieser Parameter sichtbar sein, wenn Sie den Ausführungsverlauf Ihres Workflows und die ausgehende HTTP-Anforderung anzeigen. Achten Sie darauf, Ihre Richtlinien für den Zugriff auf Inhalte entsprechend festzulegen. Sie können auch Obfuskation verwenden, um Ein- und Ausgaben im Ausführungsverlauf auszublenden. Standardmäßig sind Authorization-Header nicht über Eingaben oder Ausgaben sichtbar. Wenn hier ein Geheimnis verwendet wird, ist dieses daher nicht abrufbar.

Weitere Informationen finden in diesem Artikel in diesen Abschnitten:

Schützen von Parameter in Workflowdefinitionen
Sichern von Daten im Ausführungsverlauf mittels Obfuskation

Wenn Sie die Bereitstellung für Logik-Apps mithilfe von Resource Manager-Vorlagen automatisieren, können Sie geschützte Vorlagenparameter definieren, die beim Bereitstellen ausgewertet werden, indem Sie die Typen securestring und secureobject verwenden. Um Vorlagenparameter zu definieren, verwenden Sie den Abschnitt parameters auf der obersten Ebene Ihrer Vorlage, der vom Abschnitt parameters Ihrer Workflowdefinition getrennt ist und anders lautet. Um die Werte für Vorlagenparameter bereitzustellen, verwenden Sie eine separate Parameterdatei.

Wenn Sie beispielsweise Geheimnisse verwenden, können Sie sichere Vorlagenparameter definieren und verwenden, die diese Geheimnisse bei der Bereitstellung aus Azure Key Vault abrufen. Anschließend können Sie auf den Schlüsseltresor und das Geheimnis in Ihrer Parameterdatei verweisen. Weitere Informationen finden Sie in diesen Themen:

Übergeben vertraulicher Werte bei der Bereitstellung mithilfe von Azure Key Vault
Sichere Parameter in Azure Resource Manager-Vorlagen weiter unten in diesem Thema

Schützen von Parameter in Workflowdefinitionen (Verbrauchsworkflow)

Zum Schützen sensibler Informationen in der Workflowdefinition der Logik-App verwenden Sie sichere Parameter, damit diese Informationen nach dem Speichern des Logik-App-Workflows nicht sichtbar sind. Angenommen, Sie verwenden eine HTTP-Aktion, die eine Standardauthentifizierung mit Benutzernamen und Kennwort erfordert. In der Workflowdefinition definiert der Abschnitt parameters die Parameter basicAuthPasswordParam und basicAuthUsernameParam über den Typ securestring. Die Aktionsdefinition verweist dann auf diese Parameter im Abschnitt authentication.

Wichtig

Um optimale Sicherheit zu gewährleisten, empfiehlt Microsoft, nach Möglichkeit Microsoft Entra ID mit verwalteten Identitäten für die Authentifizierung zu verwenden. Diese Option bietet mehr Sicherheit, ohne Anmeldeinformationen angeben zu müssen. Azure verwaltet diese Identität und hilft, die Sicherheit von Authentifizierungsinformationen zu bewahren, damit Sie diese sensiblen Daten nicht verwalten müssen. Weitere Informationen zum Einrichten einer verwalteten Identität für Azure Logic Apps finden Sie unter Authentifizieren des Zugriffs auf und der Verbindungen mit Azure-Ressourcen mithilfe verwalteter Identitäten in 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": {}
}

Schützen von Parametern in Azure Resource Manager-Vorlagen (Verbrauchsworkflow)

Eine Resource Manager-Vorlage für eine Logik-App-Ressource und einen -Workflow enthält mehrere parameters-Abschnitte. Um Kennwörter, Schlüssel, Geheimnisse und andere sensible Informationen zu schützen, definieren Sie sichere Parameter auf Vorlagen- und Workflowdefinitionsebene mit dem Typ securestring oder secureobject. Sie können diese Werte dann in Azure Key Vault speichern und die Parameterdatei verwenden, um auf den Schlüsselspeicher und das Geheimnis zu verweisen. Ihre Vorlage ruft diese Informationen dann bei der Bereitstellung ab. Weiter Informationen finden Sie unter Übergeben vertraulicher Werte bei der Bereitstellung mithilfe von Azure Key Vault.

Wichtig

Diese Liste enthält weitere Informationen zu diesen parameters-Abschnitten:

Auf der obersten Ebene der Vorlage definiert ein parameters-Abschnitt die Parameter für die Werte, die von der Vorlage bei der Bereitstellung verwendet werden. Diese Werte können beispielsweise Verbindungszeichenfolgen für eine bestimmte Bereitstellungsumgebung beinhalten. Sie können diese Werte dann in einer separaten Parameterdatei speichern, was das Ändern dieser Werte erleichtert.
Innerhalb der Ressourcendefinition Ihrer Logik-App, aber außerhalb Ihrer Workflowdefinition, gibt der Abschnitt parameters die Werte für die Parameter Ihrer Workflowdefinition an. In diesem Abschnitt können Sie diese Werte anhand von Vorlagenausdrücken zuweisen, die auf die Parameter Ihrer Vorlage verweisen. Diese Ausdrücke werden bei der Bereitstellung ausgewertet.
Innerhalb Ihrer Workflowdefinition definiert der Abschnitt parameters die Parameter, die von Ihrem Logik-App-Workflow zur Laufzeit verwendet werden. Sie können auf diese Parameter dann innerhalb des Workflows Ihrer Logik-App verweisen, indem Sie Workflowdefinitionsausdrücke verwenden, die zur Laufzeit ausgewertet werden.

Diese Beispielvorlage weist mehrere sichere Parameterdefinitionen auf, die den Typ securestring verwenden:

Parametername	BESCHREIBUNG
`TemplatePasswordParam`	Ein Vorlagenparameter, der ein Kennwort akzeptiert, das anschließend an den `basicAuthPasswordParam`-Parameter der Workflowdefinition übergeben wird
`TemplateUsernameParam`	Ein Vorlagenparameter, der einen Benutzernamen akzeptiert, der dann an den `basicAuthUserNameParam`-Parameter der Workflowdefinition übergeben wird
`basicAuthPasswordParam`	Ein Workflowdefinitionsparameter, der das Kennwort für die Standardauthentifizierung in einer HTTP-Aktion akzeptiert
`basicAuthUserNameParam`	Ein Workflowdefinitionsparameter, der den Benutzernamen für die Standardauthentifizierung in einer HTTP-Aktion akzeptiert

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

Authentifizierungstypen für Connectors, die die Authentifizierung unterstützen

In der folgenden Tabelle werden die Authentifizierungstypen aufgeführt, die für die Connectorvorgänge verfügbar sind, bei denen Sie einen Authentifizierungstyp auswählen können:

Authentication type	Logik-App und unterstützte Connectors
Grundlegend	Azure API Management, Azure App Service, HTTP, HTTP + Swagger, HTTP-Webhook
Clientzertifikat	Azure API Management, Azure App Service, HTTP, HTTP + Swagger, HTTP-Webhook
Active Directory OAuth (OAuth 2.0 mit Microsoft Entra ID)	- Verbrauch: 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 Webhook, SQL Server
Raw	Azure API Management, Azure App Service, Azure Functions, HTTP, HTTP + Swagger, HTTP-Webhook
Verwaltete Identität	Integrierte Connectors: - Verbrauch: 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 Webhook, SQL Server Hinweis: Derzeit unterstützen die meisten integrierten, dienstanbieterbasierten Connectors die Auswahl benutzerseitig zugewiesener verwalteter Identitäten für die Authentifizierung nicht. Verwaltete 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 mit Microsoft Entra ID, SQL Server

Wichtig

Zugriff für eingehende Aufrufe anforderungsbasierter Trigger

Eingehende Aufrufe, die eine Logik-App über einen anforderungsbasierten Trigger wie den Anforderungstrigger oder den HTTP-Webhooktrigger empfängt, unterstützen die Verschlüsselung und werden mindestens mit TLS 1.2 (Transport Layer Security) geschützt (ehemals als Secure Sockets Layer (SSL) bezeichnet). Azure Logic Apps erzwingt diese Version beim Empfang eines eingehenden Aufrufs des Anforderungstriggers oder eines Rückrufs an den HTTP-Webhooktrigger bzw. die entsprechende Aktion.

Hinweis

Wenn TLS-Handshakefehler auftreten, sollten Sie sicherstellen, dass Sie TLS 1.2 verwenden. Weitere Informationen finden Sie unter Lösen des TLS 1.0-Problems.

Verwenden Sie für eingehende Aufrufe die folgenden Sammlungen für Verschlüsselungsverfahren:

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

Wichtig

Azure Logic Apps unterstützt für die Abwärtskompatibilität derzeit einige ältere Sammlungen von Verschlüsselungsverfahren. Verwenden Sie jedoch keine älteren Verschlüsselungsverfahrenssammlungen, wenn Sie neue Apps entwickeln, da derartige Sammlungen möglicherweise künftig nicht unterstützt werden.

Möglicherweise werden beispielsweise die folgenden Sammlungen von Verschlüsselungsverfahren angezeigt, wenn Sie in Azure Logic Apps oder mit einem Sicherheitstool die TLS-Handshakenachrichten für die URL Ihrer Logik-App untersuchen. Diese älteren Sammlungen sollten nicht verwendet werden:

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

In der folgenden Liste finden Sie Möglichkeiten für eine Einschränkung des Zugriffs auf Trigger, die eingehende Aufrufe Ihres Logik-App-Workflows empfangen, sodass nur autorisierte Clients Ihren Workflow aufrufen können:

Aktivieren von OAuth mit Microsoft Entra ID
Generieren von SAS-Schlüsseln (Shared Access Signature) oder -Token
Deaktivieren der SAS-Authentifizierung (Shared Access Signature)
Einschränken eingehender IP-Adressen
Verfügbarmachen Ihrer Logik-App mit Azure API Management

Aktivieren von OAuth 2.0 mit Microsoft Entra ID

In einem Verbrauchsworkflow, der von einem anforderungsbasierten Trigger ausgelöst wird, können Sie eingehende Aufrufe an den Endpunkt, der durch diesen Trigger erstellt wurde, authentifizieren, indem Sie OAuth 2.0 mit Microsoft Entra ID aktivieren. Um diese Authentifizierung einzurichten, definieren Sie eine Autorisierungsrichtlinie auf Ebene der Logik-App-Ressource oder fügen eine hinzu. Auf diese Weise verwenden eingehende Aufrufe OAuth-Zugriffstoken für die Autorisierung.

Wenn Ihr Logik-App-Workflow eine eingehende Anforderung mit einem OAuth-Zugriffstoken empfängt, vergleicht der Azure Logic Apps-Dienst die Ansprüche des Tokens mit den in den einzelnen Autorisierungsrichtlinien angegebenen Ansprüchen. Wenn eine Übereinstimmung zwischen den Ansprüchen des Tokens und allen Ansprüchen in mindestens einer Richtlinie vorliegt, ist die Autorisierung für die eingehende Anforderung erfolgreich. Das Token kann mehr Ansprüche als von der Autorisierungsrichtlinie angegeben aufweisen.

In einem Standardworkflow, der vom Anforderungstrigger ausgelöst wird (aber keinem Webhooktrigger), können Sie die Azure Functions-Bereitstellung für die Authentifizierung eingehender Aufrufe, die an den durch diesen Anforderungstrigger erstellten Endpunkt gesendet wurden, mithilfe einer verwalteten Identität verwenden. Diese Bereitstellung wird auch als „Easy Auth“ (einfache Authentifizierung) bezeichnet. Weitere Informationen hierzu finden Sie unter Auslösen von Workflows in Standard-Logik-Apps mit Easy Auth.

Überlegungen vor der Aktivierung von OAuth 2.0 mit Microsoft Entra ID

Um optimale Sicherheit zu gewährleisten, empfiehlt Microsoft, nach Möglichkeit Microsoft Entra ID mit verwalteten Identitäten für die Authentifizierung zu verwenden. Diese Option bietet mehr Sicherheit, ohne Anmeldeinformationen angeben zu müssen. Azure verwaltet diese Identität und hilft, die Sicherheit von Authentifizierungsinformationen zu bewahren, damit Sie diese sensiblen Daten nicht verwalten müssen. Weitere Informationen zum Einrichten einer verwalteten Identität für Azure Logic Apps finden Sie unter Authentifizieren des Zugriffs auf und der Verbindungen mit Azure-Ressourcen mithilfe verwalteter Identitäten in Azure Logic Apps.
Bei Verbrauchsworkflows können eingehende Aufrufe an die Endpunkt-URL für einen anforderungsbasierten Trigger nur ein Autorisierungsschema verwenden: entweder OAuth 2.0 mit Microsoft Entra ID oder SAS (Shared Access Signature). Durch die Verwendung eines Schemas wird das andere Schema nicht deaktiviert, die gleichzeitige Verwendung beider Schemas führt jedoch zu einem Fehler, da Azure Logic Apps nicht weiß, welches Schema ausgewählt werden soll. Wenn Ihr Verbrauchsworkflow mit dem Anforderungstrigger ausgelöst wird, können Sie die SAS-Authentifizierung deaktivieren und die Autorisierung auf OAuth 2.0 mit Microsoft Entra ID beschränken. Für Standardworkflows können Sie andere Authentifizierungstypen verwenden, ohne SAS zu deaktivieren.
Azure Logic Apps unterstützt entweder den Bearer-Typ oder den Proof-of-Possession-Typ (nur Verbrauchslogik-App) für Microsoft Entra ID-OAuth-Zugriffstoken. Der Authorization-Header für das Zugriffstoken muss jedoch entweder den Bearer-Typ oder den PoP-Typ angeben. Weitere Informationen zum Abrufen und Verwenden eines PoP-Tokens finden Sie unter Abrufen eines Proof-of-Possession(PoP)-Tokens.
Ihre Logik-App-Verbrauchsressource ist auf eine maximale Anzahl von Autorisierungsrichtlinien beschränkt. Jede Autorisierungsrichtlinie verfügt auch über eine maximale Anzahl von Ansprüchen. Weitere Informationen finden Sie unter Grenzwerte und Konfiguration für Azure Logic Apps.

Eine Autorisierungsrichtlinie muss mindestens den Anspruch Aussteller enthalten, der für den Microsoft Entra ID-Aussteller einen Wert hat, der entweder mit https://sts.windows.net/ oder mit https://login.microsoftonline.com/ (OAuth V2) beginnt.

Angenommen, Ihre Logik-App-Ressource verfügt über eine Autorisierungsrichtlinie, die zwei Anspruchstypen erfordert, Zielgruppe und Aussteller. Dieser Beispielpayloadabschnitt für ein decodiertes Zugriffstoken umfasst beide Anspruchstypen, wobei aud der Wert Zielgruppe und iss der Wert Aussteller ist:

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

Aktivieren von OAuth 2.0 mit Microsoft Entra ID als einziger Option zum Aufrufen eines Anforderungsendpunkts (nur Verbrauch)

Für anforderungsbasierte Endpunkte können Sie die Autorisierung auf OAuth 2.0 mit Microsoft Entra ID beschränken. Diese Option funktioniert auch, wenn Sie auch die SAS-Authentifizierung (Shared Access Signature) deaktivieren.

Richten Sie für Ihren Verbrauchsworkflow Ihren Anforderungs- oder HTTP-Webhooktrigger mit der Möglichkeit ein, das OAuth-Zugriffstoken zu überprüfen, indem Sie die Schritte ausführen, um den „Authorization“-Header in die Ausgaben des Anforderungs- oder HTTP-Webhooktriggers einzuschließen.

Hinweis

Durch diesen Schritt wird der Authorization-Header im Ausführungsverlauf des Workflows und in den Ausgaben des Triggers sichtbar.
Öffnen Sie im Azure-Portal Ihren Verbrauchsworkflow im Designer.
Wählen Sie im Designer den Trigger aus. Wählen Sie im daraufhin geöffneten Informationsbereich Einstellungen aus.
Wählen Sie unter Allgemein>Triggerbedingungen die Option Hinzufügen aus. Geben Sie im Feld „Triggerbedingung“ basierend auf dem Tokentyp, den Sie verwenden möchten, einen der folgenden Ausdrücke ein:

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

Oder

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

Wenn Sie den Triggerendpunkt ohne die richtige Autorisierung aufrufen, wird der Trigger im Ausführungsverlauf nur als Skipped angezeigt, ohne eine Meldung, dass die Triggerbedingung fehlgeschlagen ist.

Abrufen eines Proof-of-Possession(PoP)-Tokens

Die Microsoft Authentication Library(MSAL)-Bibliotheken stellen PoP-Token bereit, die Sie verwenden können. Wenn der Logik-App-Verbrauchsworkflow, den Sie aufrufen möchten, ein PoP-Token erfordert, können Sie dieses Token mithilfe der MSAL-Bibliotheken abrufen. Die folgenden Beispiele zeigen, wie PoP-Token abgerufen werden:

Wenn Sie das PoP-Token mit Ihrem Logik-App-Verbrauchsworkflow verwenden möchten, befolgen Sie die Schritte zum Einrichten von OAuth mit Microsoft Entra ID.

Aktivieren von OAuth mit Microsoft Entra ID für Ihre Logik-App-Verbrauchsressourcen

Um Ihrer Verbrauchs-Logik-App eine Autorisierungsrichtlinie hinzuzufügen, führen Sie die Schritte für das Azure-Portal oder für eine Azure Resource Manager-Vorlage aus:

Portal
Resource Manager-Vorlage

Öffnen Sie im Azure-Portal Ihre Verbrauchslogik-App und deren Workflow im Workflow-Designer.
Wählen Sie im Menü der Logik-App unter Einstellungen die Option Autorisierung aus.
Wählen Sie auf der Seite Autorisierung die Option Richtlinie hinzufügen aus.

Geben Sie Informationen zur Autorisierungsrichtlinie an, indem Sie die Anspruchstypen und Werte angeben, die Ihre Logik-App im Zugriffstoken erwartet, das von jedem eingehenden Aufruf dem Anforderungstrigger präsentiert wird:

Eigenschaft	Erforderlich	Type	BESCHREIBUNG
Richtlinienname	Ja	String	Der Name, den Sie für die Autorisierungsinstanz verwenden möchten
Richtlinientyp	Ja	String	Entweder AAD für Token des Bearer-Typs oder AADPOP für Token des Proof-of-Possession-Typs.
Ansprüche	Ja	String	Ein Schlüssel-Wert-Paar, das den Anspruchstyp und den Wert angibt, den der Anforderungstrigger des Workflows in dem Zugriffstoken erwartet, das von jedem eingehenden Aufruf des Triggers angezeigt wird. Sie können einen beliebigen Standardanspruch hinzufügen, indem Sie Standardanspruch hinzufügen auswählen. Um einen Anspruch hinzuzufügen, der für ein PoP-Token spezifisch ist, wählen Sie Benutzerdefinierten Anspruch hinzufügen aus. Verfügbare Standardanspruchstypen: - Aussteller - Zielgruppe - Betreff - JWT-ID (JSON Web Token-Bezeichner) Anforderungen: - Die Liste der Ansprüche muss mindestens den Anspruch Aussteller enthalten, dem als Microsoft Entra-Aussteller-ID ein Wert zugeordnet ist, der mit `https://sts.windows.net/` oder `https://login.microsoftonline.com/` beginnt. - Jeder Anspruch muss ein einzelner Zeichenfolgenwert sein, kein Array von Werten. Sie können beispielsweise einen Anspruch mit Role (Rolle) als Typ und Developer (Entwickler) als Wert haben. Sie können keinen Anspruch haben, dessen Typ Role (Rolle) ist, und bei dem die Werte auf Developer (Entwickler) und Program Manager (Programm-Manager) festgelegt sind. - Der Anspruchswert ist auf eine maximale Anzahl von Zeichen beschränkt. Weitere Informationen zu diesen Anspruchstypen finden Sie unter Ansprüche in Sicherheitstoken von Microsoft Entra. Sie können auch Ihren eigenen Anspruchstyp und -wert angeben.

Das folgende Beispiel zeigt die Informationen für ein PoP-Token an:

Zum Hinzufügen eines weiteren Anspruchs wählen Sie eine der folgenden Optionen aus:
- Um einen weiteren Anspruchstyp hinzuzufügen, wählen Sie Standardanspruch hinzufügen aus und geben den Anspruchswert an.
- Um Ihren eigenen Anspruch hinzuzufügen, wählen Sie Benutzerdefinierten Anspruch hinzufügen aus. Weitere Informationen finden Sie unter Bereitstellen optionaler Ansprüche für Ihre Azure AD-App. Ihr benutzerdefinierter Anspruch wird dann als Teil ihrer JWT-ID gespeichert. Beispiel: "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee".
Zum Hinzufügen einer weiteren Autorisierungsrichtlinie wählen Sie Richtlinie hinzufügen aus. Wiederholen Sie die vorherigen Schritte, um die Richtlinie einzurichten.
Klicken Sie auf Speichern, wenn Sie fertig sind.
Informationen, wie Sie den Authorization-Header aus dem Zugriffstoken in die anforderungsbasierten Triggerausgaben aufnehmen, finden Sie unter Aufnehmen des Autorisierungsheaders in die Ausgaben des Anforderungs- oder HTTP-Webhooktriggers.

Workfloweigenschaften wie Richtlinien werden nicht in der Codeansicht Ihres Workflows im Azure-Portal angezeigt. Rufen Sie für einen programmgesteuerten Zugriff auf Ihre Richtlinien die folgende API über Azure Resource Manager auf: 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. Stellen Sie sicher, dass Sie die Platzhalterwerte für Ihre Azure-Abonnement-ID, den Ressourcengruppennamen und den Workflownamen ersetzen.

Definieren Sie in ihrer ARM-Vorlage eine Autorisierungsrichtlinie mithilfe der folgenden Schritte und Syntax:

Fügen Sie im Abschnitt properties für die Ressourcendefinition Ihrer Logik-App ein accessControl-Objekt hinzu, falls keines vorhanden ist, das ein triggers-Objekt enthält.

Weitere Informationen zum accessControl-Objekt finden Sie unter Einschränken eingehender IP-Adressbereiche in Azure Resource Manager-Vorlagen und Microsoft.Logic-Workflows-Vorlagenreferenz.
Fügen Sie im triggers-Objekt ein openAuthenticationPolicies-Objekt hinzu, das das policies-Objekt enthält, in dem Sie eine oder mehrere Autorisierungsrichtlinien definieren.
Geben Sie einen Namen für die Autorisierungsrichtlinie an, legen Sie den Richtlinientyp auf AAD fest, und schließen Sie ein claims-Array ein, in dem Sie einen oder mehrere Anspruchstypen angeben.

Das claims-Array muss mindestens den Anspruchstyp „Aussteller“ enthalten, wobei Sie die name-Eigenschaft des Anspruchs auf iss festlegen und den Anfang des value auf https://sts.windows.net/ oder https://login.microsoftonline.com/ als Microsoft Entra-Aussteller-ID festlegen. Weitere Informationen zu diesen Anspruchstypen finden Sie unter Ansprüche in Sicherheitstoken von Microsoft Entra. Sie können auch Ihren eigenen Anspruchstyp und -wert angeben.
Informationen, wie Sie den Authorization-Header aus dem Zugriffstoken in die anforderungsbasierten Triggerausgaben aufnehmen, finden Sie unter Aufnehmen des „Authorization“-Headers in Anforderungstriggerausgaben.

Dies ist die einzuhaltende Syntax:

"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
],

Einschließen des Autorisierungsheaders in die Ausgaben des Anforderungs- oder HTTP-Webhooktriggers

Für Logik-Apps, die OAuth mit Microsoft Entra ID zum Autorisieren eingehender Aufrufe für den Zugriff auf anforderungsbasierte Trigger aktivieren, können Sie den Authorization-Header aus dem OAuth-Zugriffstoken in die Ausgaben vom Anforderungstrigger oder HTTP-Webhooktrigger einschließen. Fügen Sie in der zugrunde liegenden JSON-Definition die Eigenschaft IncludeAuthorizationHeadersInOutputs hinzu, und legen Sie sie auf operationOptions fest. Hier sehen Sie ein Beispiel für den Anforderungstrigger:

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

Weitere Informationen finden Sie in diesen Themen:

Generieren eines SAS-Schlüssels (Shared Access Signature) oder -Tokens

Wenn ein Workflow von einem anforderungsbasierten Trigger ausgelöst wird und Sie diesen Workflow zum ersten Mal speichern, erstellt Azure Logic Apps einen aufrufbaren Endpunkt für diesen Trigger. Dieser Endpunkt verfügt über eine URL, die eingehende Aufrufe oder Anforderungen zum Starten des Workflows empfangen kann. Die URL enthält eine SAS (Shared Access Signature), bei der es sich um einen Schlüssel oder ein Token handelt, der oder das die Berechtigungen erteilt, z. B. für Speicherdienste. Diese Endpunkt-URL hat folgendes Format:

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

Um diese URL beispielsweise in einem Anforderungstrigger anzuzeigen, suchen Sie die HTTP-URL-Eigenschaft des Triggers:

Screenshot des Verbrauchsworkflow-Designers und der Endpunkt-URL des Anforderungstriggers im Azure-Portal

Die vollständige URL ähnelt dem folgenden Beispiel:

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

Die SAS in der URL enthält Abfrageparameter, die in der folgenden Tabelle beschrieben werden:

Query parameter (Abfrageparameter)	BESCHREIBUNG
`sp`	Gibt Berechtigungen für die zulässigen HTTP-Methoden an.
`sv`	Gibt die SAS-Version an, die zum Generieren der Signatur verwendet werden soll.
`sig`	Gibt die Signatur an, die für die Authentifizierung des Zugriffs auf den Trigger verwendet werden soll. Diese Signatur wird mit dem SHA256-Algorithmus mit einem geheimen Zugriffsschlüssel für alle URL-Pfade und -Eigenschaften generiert. Dieser Schlüssel bleibt geheim und verschlüsselt. Er wird mit der Logik-App gespeichert und nie offengelegt oder veröffentlicht. Die Logik-App autorisiert nur Trigger, die eine gültige, mit dem geheimen Schlüssel erstellte Signatur enthalten.

Wichtig

Stellen Sie sicher, dass Sie Ihren SAS-Schlüssel genauso schützen, wie Sie einen Kontoschlüssel vor nicht autorisierter Verwendung schützen. Richten Sie einen Plan zum Widerrufen eines kompromittierten Zugriffsschlüssels ein oder haben Sie einen Plan. Handeln Sie mit Umsicht, wenn Sie URIs verteilen, die Zugriffsschlüssel verwenden, und verteilen Sie diese URIs nur über eine sichere Verbindung wie HTTPS. Führe Sie Vorgänge nur mit einem Zugriffsschlüssel über eine HTTPS-Verbindung aus. Jeder Benutzer, der über einen URI mit gültigem Schlüssel verfügt, kann auf die zugehörige Ressource zugreifen. Um den Zugriff auf Ihren Logik-App-Workflow aufrechtzuerhalten und zu schützen, sollten Sie Ihre Zugriffsschlüssel regelmäßig neu generieren, da sie möglicherweise Sicherheitsrichtlinien einhalten müssen oder kompromittiert werden. Auf diese Weise können Sie sicherstellen, dass nur autorisierte Anforderungen Ihren Workflow auslösen können, wodurch Ihre Daten und Prozesse vor unbefugtem Zugriff geschützt werden.

Wenn Sie einen SAS-Schlüssel für den Zugriff auf Speicherdienste verwenden, empfiehlt Microsoft, anstelle eines Kontoschlüssels eine Benutzerdelegierung für SAS zu erstellen, die mit Microsoft Entra ID geschützt ist.

Eingehende Aufrufe an den Endpunkt für einen anforderungsbasierten Trigger können nur ein Autorisierungsschema verwenden: entweder SAS oder OAuth 2.0 mit Microsoft Entra ID. Durch die Verwendung eines Schemas wird das andere Schema nicht deaktiviert, die gleichzeitige Verwendung beider Schemas führt jedoch zu einem Fehler, da Azure Logic Apps nicht weiß, welches Schema ausgewählt werden soll.

Wenn Sie einen Verbrauchsworkflow haben, der mit dem Anforderungstrigger ausgelöst wird, können Sie die SAS-Authentifizierung deaktivieren. Diese Option funktioniert auch, wenn Sie die Autorisierung auf OAuth 2.0 mit Microsoft Entra ID beschränken. Für Standardworkflows können Sie andere Authentifizierungstypen verwenden, ohne SAS zu deaktivieren.

Weitere Informationen zur Sicherheit bei Verwendung eines SAS-Schlüssels finden Sie in den folgenden Abschnitten in diesem Leitfaden:

Erneutes Generieren von Zugriffsschlüsseln
Erstellen von ablaufenden Rückruf-URLs
Erstellen von URLs mit Primär- oder Sekundärschlüssel

Deaktivieren der SAS-Authentifizierung (Shared Access Signature; nur Verbrauch)

Standardmäßig ist bei anforderungsbasierten Triggern die SAS-Authentifizierung aktiviert. Die Endpunkt-URL des Triggers enthält eine SAS, die z. B. mit den Abfrageparametern (sp-<permissions>sv-<SAS-version>sig=<signature>) beginnt:

Wenn Ihr Verbrauchsworkflow mit dem Anforderungstrigger ausgelöst wird und Sie OAuth mit Microsoft Entra ID verwenden möchten, können Sie die SAS-Authentifizierung deaktivieren, um Fehler und Probleme bei der Ausführung Ihres Workflows zu verhindern. Außerdem fügen Sie eine zusätzliche Sicherheitsebene hinzu, indem Sie die Abhängigkeit von Geheimnissen aufheben und damit das Risiko reduzieren, dass Geheimnisse protokolliert oder offengelegt werden.

Diese Option funktioniert auch, wenn Sie OAuth 2.0 mit Microsoft Entra ID als einzige Option zum Aufrufen eines anforderungsbasierten Endpunkts aktivieren. Für Standardworkflows können Sie andere Authentifizierungstypen verwenden, ohne SAS zu deaktivieren.

Hinweis

Diese Aktion deaktiviert die SAS-Authentifizierung für eingehende Anforderungen und blockiert vorhandene SAS-Schlüssel oder Signaturen. Ihre SAS-Schlüssel oder Signaturen bleiben jedoch gültig und funktionieren weiterhin, wenn Sie die SAS-Authentifizierung erneut aktivieren. Informationen zum Deaktivieren von SAS-Schlüsseln und Signaturen durch Erstellen neuer Versionen finden Sie unter Neugenerieren von Zugriffsschlüsseln.

Nachdem Sie die SAS-Authentifizierung deaktiviert haben, enthält die Endpunkt-URL für den Anforderungstrigger nicht mehr den SAS-Schlüssel, z. B.:

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

Voraussetzungen

Für diese Aufgabe benötigen Sie ein Tool zum Senden von REST-API-Aufrufen, z. B.:

Achtung

Für Szenarien, in denen Sie über vertrauliche Daten wie Anmeldeinformationen, Geheimnisse, Zugriffstoken, API-Schlüssel und andere ähnliche Informationen verfügen, sollten Sie ein Tool verwenden, das Ihre Daten mit den erforderlichen Sicherheitsfunktionen schützt, offline oder lokal funktioniert, Ihre Daten nicht mit der Cloud synchronisiert und keine Anmeldung bei einem Onlinekonto erfordert. Auf diese Weise verringern Sie das Risiko, dass vertrauliche Daten an die Öffentlichkeit gelangen.

Suchen nach Triggern mit aktivierter oder deaktivierter SAS

Wenn die SAS-Authentifizierung deaktiviert ist, enthält die Endpunkt-URL des Triggers nicht mehr den SAS-Schlüssel. Außerdem enthält die Definition des Verbrauchsworkflows das JSON-Objekt sasAuthenticationPolicy. Dieses Objekt verfügt über eine state-Eigenschaft, die auf Disabledfestgelegt ist, z. B.:

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

Wenn Sie nach Verbrauchsworkflows suchen möchten, in denen die SAS aktiviert oder deaktiviert ist, überprüfen Sie, ob die Workflowdefinition das sasAuthenticationPolicy-Objekt enthält, in dem die state-Eigenschaft auf Disabled festgelegt ist.

Rufen Sie mit Ihrem Tool, das die REST-API-Aufrufe sendet, Informationen zu Ihrem Workflow ab, indem Sie den Vorgang Workflows – abrufen mithilfe der folgenden GET-Anforderung ausführen, z. B.:

GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Überprüfen Sie in der Ausgabe des Vorgangs Workflows – abrufen, ob das sasAuthenticationPolicy-Objekt vorhanden und die state-Eigenschaft auf Disabled festgelegt ist.

Hinzufügen der sasAuthenticationPolicy-Eigenschaft zur Workflowdefinition

Führen Sie die folgenden Schritte für Verbrauchsworkflows aus, bei denen Sie die SAS-Authentifizierung deaktivieren möchten:

Wenn Sie dies noch nicht getan haben, rufen Sie Informationen zu Ihrem Workflow ab, indem Sie den Vorgang Workflows – abrufen mithilfe der folgenden GET-Anforderung abrufen, z. B.:

GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Verwenden Sie die Ausgabe des Vorgangs Workflows – abrufen, und fügen Sie die folgenden Elemente manuell hinzu:
1. Fügen Sie im properties-Objekt ein accessControl-Objekt hinzu, das ein triggers-Objekt enthält (sofern noch nicht vorhanden).
2. Fügen Sie im triggers-Objekt ein sasAuthenticationPolicy-Objekt hinzu, bei dem die state-Eigenschaften auf Disabled festgelegt ist.
Wenn Sie fertig sind, ähnelt der bearbeitete Teil folgendem Beispiel:
```
"properties": {
    "accessControl": {
        "triggers": {
            "sasAuthenticationPolicy": {
                "state": "Disabled"
            }
        }
    }
}
```
Senden Sie eine weitere Anforderung zum Aktualisieren Ihres Workflows mit der bearbeiteten Ausgabe, die Sie als Eingabe im Anforderungstext verwenden. Führen Sie dazu den Vorgang Workflow – aktualisieren mit der folgenden PATCH-Anforderung aus, z. B.:

PATCH https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Wechseln Sie im Azure-Portal im Designer zu Ihrem Verbrauchsworkflow, und vergewissern Sie sich, dass die URL des Anforderungstriggers nicht mehr die SAS enthält.
Um Oauth 2.0 mit Microsoft Entra ID zu aktivieren, fügen Sie auf Ressourcenebene der Logik-App eine Autorisierungsrichtlinie für OAuth mit Microsoft Entra ID hinzu.

Weitere Informationen finden Sie unter Aktivieren von OAuth 2.0 mit Microsoft Entra ID.

Erneutes Generieren von Zugriffsschlüsseln

Um den Zugriff auf Ihren Logik-App-Workflow aufrechtzuerhalten und den Zugriff zu schützen, generieren Sie Zugriffsschlüsseln regelmäßig neu, da sie möglicherweise Sicherheitsrichtlinien einhalten müssen oder kompromittiert werden. Auf diese Weise können Sie sicherstellen, dass nur autorisierte Anforderungen Ihren Workflow auslösen können, wodurch Ihre Daten und Prozesse vor unbefugtem Zugriff geschützt werden.

Über die Azure-REST-API oder das Azure-Portal können Sie jederzeit einen neuen Zugriffsschlüssel generieren. Alle zuvor generierten URIs oder URLs, die den alten Schlüssel verwenden, werden ungültig und sind nicht mehr berechtigt, Ihren Logik-App-Workflow auszulösen. Die URLs, die Sie nach der erneuten Generierung abrufen, werden mit dem neuen Zugriffsschlüssel signiert.

Öffnen Sie im Azure-Portal die Logik-App-Ressource, die den Schlüssel verwendet, den Sie erneut generieren möchten.
Wählen Sie im Menü Ihrer Logik-App-Ressource unter Einstellungen die Option Zugriffsschlüssel aus.
Wählen Sie den Schlüssel aus, den Sie erneut generieren möchten, und schließen Sie den Vorgang ab.

Wichtig

Stellen Sie sicher, dass Sie einen Zugriffsschlüssel genauso wie einen Kontoschlüssel vor nicht autorisierter Verwendung schützen. Richten Sie einen Plan zum Widerrufen eines kompromittierten Zugriffsschlüssels ein oder haben Sie einen Plan. Handeln Sie mit Umsicht, wenn Sie URIs verteilen, die Zugriffsschlüssel verwenden, und verteilen Sie diese URIs nur über eine sichere Verbindung wie HTTPS. Führe Sie Vorgänge nur mit einem Zugriffsschlüssel über eine HTTPS-Verbindung aus. Jeder Benutzer, der über einen URI mit gültigem Schlüssel verfügt, kann auf die zugehörige Ressource zugreifen.

Erstellen ablaufender Rückruf-URLs

Wenn Sie die Endpunkt-URL eines anforderungsbasierten Triggers für andere Parteien freigeben, können Sie Rückruf-URLs mit bestimmten Schlüsseln und Ablaufdaten generieren. So können Sie nahtlos rollierende Schlüssel bereitstellen oder den Zugriff für das Auslösen Ihrer Logik-App auf einen bestimmten Zeitraum einschränken. Über die Azure Logic Apps-REST-API können Sie ein Ablaufdatum für eine URL angeben. Beispiel:

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

Verwenden Sie im Text die NotAfter-Eigenschaft mit einer JSON-Datumszeichenfolge. Diese Eigenschaft gibt eine Rückruf-URL zurück, die nur bis zum Datum und der Uhrzeit in NotAfter gültig ist.

Erstellen von URLs mit einem primären oder sekundären geheimen Schlüssel

Beim Generieren oder Auflisten von Rückruf-URLs für anforderungsbasierte Trigger können Sie den Schlüssel zum Signieren der URL angeben. Um eine URL zu generieren, die von einem bestimmten Schlüssel signiert wird, verwenden Sie die Azure Logic Apps-REST-API, z. B.:

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

Schließen Sie in den Textkörper die KeyType-Eigenschaft als Primary oder als Secondary ein. Diese Eigenschaft gibt eine URL zurück, die mit dem angegebenen Sicherheitsschlüssel signiert ist.

Verfügbarmachen Ihrer Logik-App-Workflow mit Azure API Management

Für weitere Authentifizierungsprotokolle und Optionen sollten Sie Ihren Logik-App-Workflow mithilfe von Azure API Management als API verfügbar machen. Dieser Dienst bietet umfangreiche Funktionen für Überwachung, Sicherheit, Richtlinien und Dokumentation für alle Endpunkte. Mit API Management können Sie einen öffentlichen oder privaten Endpunkt für die Logik-App verfügbar machen. Um den Zugriff auf diesen Endpunkt zu autorisieren, können Sie OAuth mit Microsoft Entra ID, ein Clientzertifikat oder einen anderen Sicherheitsstandards verwenden. Wenn API Management eine Anforderung empfängt, wird diese an Ihre Logik-App gesendet, wobei alle erforderlichen Transformationen oder Einschränkungen umgesetzt werden. Damit nur API Management Ihren Logik-App-Workflow aufrufen kann, können Sie die eingehenden IP-Adressen Ihrer Logik-App einschränken.

Weitere Informationen finden Sie in der folgenden Dokumentation:

Einschränken eingehender IP-Adressen

Zusätzlich zur Shared Access Signature (SAS) empfiehlt es sich, spezifisch die Clients einzuschränken, die Ihren Logik-App-Workflow aufrufen können. Beispiel: Wenn Sie den Anforderungsendpunkt mit Azure API Management verwalten, können Sie für den Logik-App-Workflow festlegen, dass er Anforderungen nur von der IP-Adresse der von Ihnen erstellten API Management-Dienstinstanz annimmt.

Unabhängig von den von Ihnen angegebenen IP-Adressen können Sie einen Logik-App-Workflow mit einem anforderungsbasierten Trigger ausführen, indem Sie die Anforderung für den Vorgang Workflowtrigger – ausführen oder API Management verwenden. In diesem Szenario ist jedoch weiterhin eine Authentifizierung über die Azure-REST-API erforderlich. Alle Ereignisse werden im Azure-Überwachungsprotokoll angezeigt. Achten Sie darauf, die Richtlinien für die Zugriffssteuerung entsprechend festzulegen.

Um die eingehenden IP-Adressen für Ihren Logik-App-Workflow einzuschränken, führen Sie die entsprechenden Schritte für das Azure-Portal oder für Ihre Azure Resource Manager-Vorlage aus. Gültige IP-Adressbereiche verwenden die Formate x.x.x.x/x oder x.x.x.x-x.x.x.x.

Portal
Resource Manager-Vorlage

Im Azure-Portal wirkt sich die IP-Adresseinschränkung auf Trigger und Aktionen aus, entgegen der Beschreibung im Portal unter Zulässige eingehende IP-Adressen. Um diesen Filter jeweils gesondert für Trigger und Aktionen einzurichten, verwenden Sie das accessControl-Objekt in einer Azure Resource Manager-Vorlage für Ihre Logik-App-Ressource oder den Vorgang Workflow – erstellen oder aktualisieren der Azure Logic Apps-REST-API.

Verbrauchsworkflows

Öffnen Sie im Azure-Portal Ihre Verbrauchslogik-App im Workflow-Designer.
Wählen Sie im Menü der Logik-App unter Einstellungen die Option Workfloweinstellungen.
Wählen Sie im Abschnitt Konfiguration der Zugriffssteuerung unter Zulässige eingehende IP-Adressen den Pfad für Ihr Szenario aus:
- Um Ihren Workflow mithilfe der integrierten Azure Logic Apps-Aktion aufrufbar zu machen (aber nur als geschachtelten Workflow), wählen Sie Nur andere Logik-Apps aus. Diese Option funktioniert nur, wenn Sie die Azure Logic Apps-Aktion verwenden, um den geschachtelten Workflow aufzurufen.
  
  Diese Option schreibt ein leeres Array in Ihre Logik-App-Ressource und erfordert, dass nur Aufrufe von übergeordneten Workflows, die die integrierte Azure Logic Apps-Aktion verwenden, den geschachtelten Workflow auslösen können.
- Wählen Sie Bestimmte IP-Bereiche aus, um Ihren Workflow mithilfe der HTTP-Aktion aufrufbar zu machen (aber nur als geschachtelten Workflow). Wenn das Feld IP-Bereiche für Trigger angezeigt wird, geben Sie die ausgehenden IP-Adressen des übergeordneten Workflows ein. Gültige IP-Adressbereiche verwenden die Formate x.x.x.x/x oder x.x.x.x-x.x.x.x.
  
  Hinweis
  
  Wenn Sie die Option Nur andere Logik-Apps und die HTTP-Aktion zum Aufrufen Ihres geschachtelten Workflows verwenden, wird der Aufruf blockiert, und Sie erhalten einen Fehler des Typs „401 – nicht autorisiert“.
- In Szenarien, in denen Sie eingehende Aufrufe von anderen IP-Adressen beschränken möchten, geben Sie im Feld IP-Bereiche für Trigger die IP-Adressbereiche ein, die vom Trigger akzeptiert werden. Gültige IP-Adressbereiche verwenden die Formate x.x.x.x/x oder x.x.x.x-x.x.x.x.
Optional können Sie unter Aufrufe auf den Empfang von Eingabe- und Ausgabemeldungen vom Ausführungsverlauf an die angegebenen IP-Adressen beschränken die IP-Adressbereiche für eingehende Aufrufe angeben, die auf Eingabe- und Ausgabemeldungen im Ausführungsverlauf zugreifen können.

Workflows vom Typ „Standard“

Öffnen Sie im Azure-Portal Ihre Ressource vom Typ „Logic App (Standard)“.
Wählen Sie im Logik-App-Menü unter Einstellungen die Option Netzwerk aus.
Wählen Sie im Abschnitt Konfiguration des eingehenden Datenverkehrs neben Öffentlicher Netzwerkzugriff Aktiviert ohne Zugriffseinschränkung aus.
Wählen Sie auf der Seite Zugriffsbeschränkungen unter App-Zugriff Aus den ausgewählten virtuellen Netzwerken und IP-Adressen aktiviert aus.
Fügen Sie unter Websitezugriff und -regeln auf der Registerkarte Hauptwebsite eine oder mehrere Regeln entweder zu Anforderungen Zulassen oder Verweigern aus bestimmten IP-Bereichen hinzu. Gültige IP-Adressbereiche verwenden die Formate x.x.x.x/x oder x.x.x.x-x.x.x.x.

Weitere Informationen finden Sie unter Blockieren eingehender IP-Adressen in Azure Logic Apps (Standard).

Verbrauchsworkflows

Geben Sie in Ihrer ARM-Vorlage die zulässigen eingehenden IP-Adressbereiche in der Ressourcendefinition ihrer Logik-App an, indem Sie den Abschnitt accessControl verwenden. Verwenden Sie dort die Abschnitte für triggers, actions und optional contents, indem Sie den Abschnitt allowedCallerIpAddresses mit der Eigenschaft addressRange einschließen und den Eigenschaftswert auf den zulässigen IP-Adressbereich im Format x.x.x.x/x oder x.x.x.x-x.x.x.x festlegen.

Wenn Ihr geschachtelter Logik-App-Workflow die Option Nur andere Logik-Apps verwendet, die eingehende Aufrufe nur von anderen Logik-App-Workflows mit der integrierten Azure Logic Apps-Aktion zulässt, legen Sie die Eigenschaft allowedCallerIpAddresses auf ein leeres Array ([]) fest, und lassen Sie die Eigenschaft addressRangeaus.
Wenn Ihr geschachtelter Logik-App-Workflow die Option Spezifische IP-Bereiche für andere eingehende Aufrufe verwendet (beispielsweise durch andere Logik-App-Workflows, die die HTTP-Aktion verwenden), schließen Sie den Abschnitt allowedCallerIpAddresses ein, und legen Sie die Eigenschaft addressRange auf den zulässigen IP-Adressbereich fest.

Dieses Beispiel zeigt eine Logik-App-Ressourcendefinition für einen geschachtelten Workflow, der eingehende Aufrufe nur von anderen Logik-App-Workflows zulässt, die die integrierte Azure Logic Apps-Aktion verwenden:

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

Dieses Beispiel zeigt eine Logik-App-Ressourcendefinition für einen geschachtelten Workflow, der eingehende Aufrufe von Logik-App-Workflows erlaubt, die die HTTP-Aktion verwenden:

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

Workflows vom Typ „Standard“

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

Zugriff für ausgehende Aufrufe anderer Dienste und Systeme

Basierend auf den Funktionen des Zielendpunkts unterstützen ausgehende Aufrufe, die vom HTTP-Trigger oder der HTTP-Aktion gesendet werden, Verschlüsselung und sind mit TLS (Transport Layer Security) 1.0, 1.1 oder 1.2 (zuvor als Secure Sockets Layer (SSL) bezeichnet) geschützt. Azure Logic Apps handelt mit dem Zielendpunkt die Verwendung der höchstmöglichen unterstützten Version aus. Wenn der Zielendpunkt z. B. 1.2 unterstützt, verwendet der HTTP-Trigger bzw. die HTTP-Aktion zuerst 1.2. Andernfalls verwendet der Connector die nächsthöhere unterstützte Version.

Diese Liste enthält Informationen zu selbstsignierten TLS/SSL-Zertifikaten:

Für verbrauchsorientierte Logik-App-Workflows in der mehrinstanzenfähigen Azure Logic Apps-Umgebung lassen HTTP-Vorgänge keine selbstsignierten TLS/SSL-Zertifikate zu. Wenn Ihre Logik-App per HTTP einen Server aufruft und ein selbstsigniertes TLS/SSL-Zertifikat vorlegt, schlägt der HTTP-Aufruf mit einem TrustFailure-Fehler fehl.
Für Logik-App-Standardworkflows in der Azure Logic Apps-Umgebung mit nur einem Mandanten unterstützen HTTP-Vorgänge selbstsignierte TLS/SSL-Zertifikate. Für diesen Authentifizierungstyp sind jedoch einige zusätzliche Schritte erforderlich. Andernfalls tritt bei dem Aufruf ein Fehler auf. Weitere Informationen finden Sie unter TLS/SSL-Zertifikatauthentifizierung für Azure Logic Apps mit nur einem Mandanten.

Wenn Sie stattdessen Clientzertifikate oder OAuth mit Microsoft Entra ID mit dem Anmeldeinformationstyp Zertifikat verwenden möchten, müssen Sie dennoch einige zusätzliche Schritte für diesen Authentifizierungstyp ausführen. Andernfalls tritt bei dem Aufruf ein Fehler auf. Weitere Informationen finden Sie unter Clientzertifikat oder OAuth mit Microsoft Entra ID mit dem Anmeldeinformationstyp „Zertifikat“ für Azure Logic Apps für einen einzelnen Mandanten.

Im Folgenden finden Sie weitere Möglichkeiten, wie Sie Endpunkte, die Aufrufe von Ihrem Logik-App-Workflow verarbeiten, besser schützen können:

Fügen Sie für ausgehende Anforderungen eine Authentifizierung hinzu.

Wenn Sie den HTTP-Trigger bzw. die HTTP-Aktion zum Senden ausgehender Aufrufe verwenden, können Sie der von Ihrer Logik-App gesendeten Anforderung eine Authentifizierung hinzufügen. Beispielsweise können Sie diese Authentifizierungstypen auswählen:
Schränken Sie den Zugriff von IP-Adressen von Logik-App-Workflows ein.

Alle Aufrufe von Logik-App-Workflows an Endpunkte stammen von bestimmten IP-Adressen, die auf den Regionen Ihrer Logik-App basieren. Sie können Filter hinzufügen, die Anforderungen nur von diesen IP-Adressen akzeptieren. Weitere Informationen zu diesen IP-Adressen finden Sie unter Grenzwert- und Konfigurationsinformationen für Azure Logic Apps.
Erhöhen der Sicherheit für Verbindungen mit lokalen Systemen.

Azure Logic Apps bietet eine Integration mit diesen Diensten, um eine sicherere und zuverlässigere lokale Kommunikation bereitzustellen.
- Lokales Datengateway
  
  Viele verwaltete Connectors in Azure Logic Apps nutzen sichere Verbindungen mit lokalen Systemen wie dem Dateisystem, SQL, SharePoint und DB2. Das Gateway sendet Daten von lokalen Quellen durch verschlüsselte Kanäle über Azure Service Bus. Der gesamte Datenverkehr stammt als sicherer ausgehender Datenverkehr vom Gateway-Agent. Erfahren Sie, wie das lokale Datengateway funktioniert.
- Verbindung über Azure API Management
  
  Azure API Management bietet lokale Konnektivitätsoptionen wie die Integration von Site-to-Site-VPN und ExpressRoute für geschützte Proxys und die Kommunikation mit lokalen Systemen. Wenn Sie über eine API verfügen, die Zugriff auf Ihr lokales System bietet, und Sie diese API durch das Erstellen einer API Management-Dienstinstanz verfügbar gemacht haben, können Sie diese API vom Workflow ihrer Logik-App aufrufen, indem Sie den entsprechenden API Management-Vorgang im Workflow-Designer auswählen.
  
  Hinweis
  
  Der Connector zeigt nur die API Management-Dienste an, für die Sie über Berechtigungen zum Anzeigen und Verbinden verfügen, aber keine verbrauchsbasierten API Management Dienste.
  
  Führen Sie basierend auf dem Ressourcentyp Ihrer Logik-App die entsprechenden Schritte aus:
  
  Verbrauchsworkflows
  1. Je nachdem, ob Sie einen API Management-Trigger oder eine Aktion hinzufügen, führen Sie die folgenden Schritte aus:
    - Abzug:
      1. Wählen Sie im Workflow-Designer die Option Trigger hinzufügen aus.
      2. Nachdem der Bereich Trigger hinzufügen geöffnet wurde, geben Sie im Suchfeld API Management ein.
      3. Wählen Sie aus der Trigger-Ergebnisliste Azure API Management-Trigger auswählen aus.
    - Aktion:
      1. Wählen Sie im Workflow-Designer an dem Ort das Pluszeichen (+) aus, an dem Sie die Aktion hinzufügen möchten.
      2. Nachdem der Bereich Aktion hinzufügen geöffnet wurde, geben Sie im Suchfeld API Management ein.
      3. Wählen Sie aus der Aktions-Ergebnisliste Azure API Management-Aktion auswählen aus.
    Das folgende Beispiel zeigt, wie Sie einen Azure-API Management-Trigger finden:
  2. Wählen Sie in der Liste der API Management-Dienstinstanzen Ihre zuvor erstellte API Management-Dienstinstanz aus.
  3. Wählen Sie in der API-Vorgangsliste den API-Vorgang aus, der aufgerufen werden soll, und wählen Sie dann Aktion hinzufügen aus.
  Workflows vom Typ „Standard“
  
  Bei Standardworkflows können Sie nur API Management-Aktionen hinzufügen, keine Trigger.
  1. Wählen Sie im Workflow-Designer an dem Ort das Pluszeichen (+) aus, an dem Sie die Aktion hinzufügen möchten.
  2. Nachdem der Bereich Aktion hinzufügen geöffnet wurde, geben Sie im Suchfeld API Management ein.
  3. Wählen Sie aus der Aktions-Ergebnisliste Azure API Management-Aktion aufrufen aus.
  4. Wählen Sie in der Liste der API Management-Dienstinstanzen Ihre zuvor erstellte API Management-Dienstinstanz aus.
  5. Wählen Sie in der API-Vorgangsliste den API-Vorgang aus, der aufgerufen werden soll, und wählen Sie dann Neu erstellen aus.

Hinzufügen der Authentifizierung zu ausgehenden Aufrufen

HTTP- und HTTP-Endpunkte unterstützen verschiedene Arten der Authentifizierung. Bei einigen Triggern und Aktionen, die Sie zum Senden ausgehender Aufrufe oder Anforderungen an diese Endpunkte verwenden, können Sie einen Authentifizierungstyp angeben. Im Workflow-Designer besitzen Trigger und Aktionen, die die Auswahl eines Authentifizierungstyps unterstützen, eine Eigenschaft Authentifizierung. Diese Eigenschaft wird jedoch möglicherweise nicht immer standardmäßig angezeigt. In diesen Fällen öffnen Sie für den Trigger oder die Aktion die Liste Erweiterte Parameter und wählen Authentifizierung aus.

Wichtig

Um vertrauliche Informationen zu schützen, die Ihr Logik-App-Workflow verarbeitet, verwenden Sie geschützte Parameter und verschlüsseln die Daten nach Bedarf. Weitere Informationen zum Verwenden und Absichern von Parametern finden Sie unter Zugriff auf Parametereingaben.

Standardauthentifizierung

Bei HTTP-Aufrufen verwendet die Standardauthentifizierung für eine Anforderung eine Base64-codierte Zeichenfolge, die einen Benutzernamen und ein Kennwort enthält. Bei dieser Methode werden die Anmeldeinformationen ohne Verschlüsselung übertragen. Dies stellt ein erhöhtes Sicherheitsrisiko dar, sofern Sie diese Option nicht mit dem HTTPS/SSL-Protokoll verwenden.

Wichtig

Wenn die Option Standard verfügbar ist und ausgewählt wurde, geben Sie die folgenden Eigenschaftenwerte an:

Eigenschaft (Designer)	Eigenschaft (JSON)	Erforderlich	Wert	BESCHREIBUNG
Authentifizierung	`type`	Ja	Basic	Der zu verwendende Authentifizierungstyp
Benutzername	`username`	Ja	<user-name>	Der Benutzername, der verwendet wird, um den Zugriff auf den Ziel-Dienstendpunkt zu authentifizieren
Kennwort	`password`	Ja	<password>	Das Kennwort, das verwendet wird, um den Zugriff auf den Ziel-Dienstendpunkt zu authentifizieren

Wenn Sie abgesicherte Parameter verwenden, um vertrauliche Informationen zu verarbeiten und zu schützen, z. B. in einer Azure Resource Manager-Vorlage zur Automatisierung der Bereitstellung, können Sie zur Runtime mit Ausdrücken auf diese Parameterwerte zugreifen. In dieser Beispieldefinition einer HTTP-Aktion werden der type der Authentifizierung als Basic angegeben und die Funktion parameters() verwendet, um die Parameterwerte abzurufen:

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

Clientzertifikatsauthentifizierung

Mit der Clientzertifikatauthentifizierung können Sie zulassen oder verlangen, dass sich Benutzer direkt mit X.509-Zertifikaten Ihrer Microsoft Entra ID-Identitäten für Anwendungen und Browseranmeldungen authentifizieren. Mit dieser Funktion können Sie eine Authentifizierung verwenden, die sicher gegen Phishing ist, und sich mit einem X.509-Zertifikat in Ihrer Public Key-Infrastruktur (PKI) authentifizieren.

Wichtig

Wenn die Option Clientzertifikat verfügbar ist und ausgewählt wurde, geben Sie die folgenden Eigenschaftenwerte an:

Eigenschaft (Designer)	Eigenschaft (JSON)	Erforderlich	Wert	BESCHREIBUNG
Authentifizierung	`type`	Ja	Clientzertifikat oder `ClientCertificate`	Der zu verwendende Authentifizierungstyp. Sie können Zertifikate mit Azure API Management verwalten. Hinweis: Benutzerdefinierte Connectors unterstützen sowohl für eingehende als auch für ausgehende Aufrufe keine zertifikatbasierte Authentifizierung.
Pfx	`pfx`	Ja	<encoded-pfx-file-content>	Der base64-codierte Inhalt aus einer Personal Information Exchange-Datei (PFX) Zum Konvertieren der PFX-Datei in ein base64-codiertes Format können Sie PowerShell 7 verwenden, indem Sie die folgenden Schritte ausführen: 1. Speichern Sie den Zertifikatsinhalt in einer Variablen: `$pfx_cert = [System.IO.File]::ReadAllBytes('c:\certificate.pfx')` 2. Konvertieren Sie den Zertifikatsinhalt mithilfe der `ToBase64String()`-Funktion, und speichern Sie den Inhalt in einer Textdatei: `[System.Convert]::ToBase64String($pfx_cert) \| Out-File 'pfx-encoded-bytes.txt'` Problembehandlung: Wenn Sie den Befehl `cert mmc/PowerShell` verwenden, erhalten Sie möglicherweise folgenden Fehler: `Could not load the certificate private key. Please check the authentication certificate password is correct and try again.` Um diesen Fehler zu beheben, versuchen Sie, die PFX-Datei in eine PEM-Datei und zurück zu konvertieren, indem Sie den Befehl `openssl` verwenden: `openssl pkcs12 -in certificate.pfx -out certificate.pem` `openssl pkcs12 -in certificate.pem -export -out certificate2.pfx` Anschließend, wenn Sie die base64-codierte Zeichenfolge für die neu konvertierte PFX-Datei des Zertifikats erhalten, funktioniert die Zeichenfolge nun in Azure Logic Apps.
Kennwort	`password`	Nein	<password-for-pfx-file>	Der Parameter für den Zugriff auf die PFX-Datei

Hinweis

Wenn Sie versuchen, sich mit einem Clientzertifikat mit OpenSSL zu authentifizieren, wird möglicherweise die folgende Fehlermeldung angezeigt:

BadRequest: Could not load private key

Um diesen Fehler zu beheben, führen Sie folgende Schritte aus:

Deinstallieren Sie alle OpenSSL-Instanzen.
Installieren Sie OpenSSL, Version 1.1.1t.
Signieren Sie Ihr Zertifikat mithilfe des neuen Updates neu.
Fügen Sie das neue Zertifikat zum HTTP-Vorgang hinzu, wenn Sie die Clientzertifikatauthentifizierung verwenden.

Wenn Sie abgesicherte Parameter verwenden, um vertrauliche Informationen zu verarbeiten und zu schützen, z. B. in einer Azure Resource Manager-Vorlage zur Automatisierung der Bereitstellung, können Sie zur Runtime mit Ausdrücken auf diese Parameterwerte zugreifen. In dieser Beispieldefinition einer HTTP-Aktion werden der type der Authentifizierung als ClientCertificate angegeben und die Funktion parameters() verwendet, um die Parameterwerte abzurufen:

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

Wichtig

Wenn Sie über eine Standardlogik-App-Ressource in Azure Logic Apps mit einem Mandanten verfügen und einen HTTP-Vorgang mit einem TSL/SSL-Zertifikat, einem Clientzertifikat oder einer Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) mit dem Certificate-Anmeldeinformationstyp verwenden möchten, stellen Sie sicher, dass Sie die zusätzlichen Einrichtungsschritte für diesen Authentifizierungstyp ausführen. Andernfalls tritt bei dem Aufruf ein Fehler auf. Weitere Informationen finden Sie unter Authentifizierung in einer Einzelmandantenumgebung.

Weitere Informationen zum Absichern von Diensten mithilfe der Clientzertifikatauthentifizierung finden Sie in den folgenden Themen:

Microsoft Entra-Plattform

Beim Anforderungstrigger können Sie die Microsoft Entra-Plattform verwenden, um eingehende Aufrufe zu authentifizieren, nachdem Sie Microsoft Entra-Autorisierungsrichtlinien für Ihre Logik-App eingerichtet haben.

Wichtig

Geben Sie für alle anderen Trigger und Aktionen, die den Active Directory OAuth-Authentifizierungstyp (OAuth 2.0 mit Microsoft Entra ID) unterstützen, die folgenden Eigenschaftenwerte an:

Eigenschaft (Designer)	Eigenschaft (JSON)	Erforderlich	Wert	BESCHREIBUNG
Authentifizierung	`type`	Ja	Active Directory OAuth (OAuth 2.0 mit Microsoft Entra ID) oder `ActiveDirectoryOAuth`	Der zu verwendende Authentifizierungstyp. Azure Logic Apps befolgt derzeit das Protokoll OAuth 2.0.
Autoritative Stelle	`authority`	Nein	<URL-for-authority-token-issuer>	Dies ist die URL für die Autorität, die den Zugriffsschlüssel bereitstellt (z. B. `https://login.microsoftonline.com/` für globale Regionen für Azure-Dienste). Informationen zu anderen nationalen Clouds finden Sie im Artikel Microsoft Entra-Authentifizierungsendpunkte - Wählen Sie Ihre Identitätsstelle aus.
Mandant	`tenant`	Ja	<Mandanten-ID>	Die Mandanten-ID den Microsoft Entra-Mandanten
Zielgruppe	`audience`	Ja	<resource-to-authorize>	Die Ressource, die Sie für die Autorisierung verwenden möchten, z. B. `https://management.core.windows.net/`
Client-ID	`clientId`	Ja	<client-ID>	Die Client-ID für die App, die eine Autorisierung anfordert
Typ der Anmeldeinformationen	`credentialType`	Ja	Zertifikat oder `Secret`	Der Anmeldeinformationstyp, den der Client zum Anfordern der Autorisierung verwendet. Diese Eigenschaft und dieser Wert tauchen nicht in der zugrunde liegenden Definition Ihrer Logik-App auf, sondern bestimmen die Eigenschaften, die für den ausgewählten Anmeldeinformationstyp angezeigt werden.
Geheimnis	`secret`	Ja, aber nur für den Anmeldeinformationstyp „Geheimnis“	<client-secret>	Der geheime Clientschlüssel zum Anfordern der Autorisierung
Pfx	`pfx`	Ja, aber nur für den Anmeldeinformationstyp „Zertifikat“	<encoded-pfx-file-content>	Der base64-codierte Inhalt aus einer Personal Information Exchange-Datei (PFX)
Kennwort	`password`	Ja, aber nur für den Anmeldeinformationstyp „Zertifikat“	<password-for-pfx-file>	Der Parameter für den Zugriff auf die PFX-Datei

Wenn Sie abgesicherte Parameter verwenden, um vertrauliche Informationen zu verarbeiten und zu schützen, z. B. in einer Azure Resource Manager-Vorlage zur Automatisierung der Bereitstellung, können Sie zur Runtime mit Ausdrücken auf diese Parameterwerte zugreifen. In dieser Beispieldefinition einer HTTP-Aktion werden der type der Authentifizierung als ActiveDirectoryOAuth, der Anmeldeinformationstyp als Secret angegeben und die Funktion parameters() verwendet, um die Parameterwerte abzurufen:

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

Wichtig

Wenn Sie über eine Logik-App-Standardressource in Azure Logic Apps mit einem Mandanten verfügen und einen HTTP-Vorgang mit einem TSL/SSL-Zertifikat, einem Clientzertifikat oder Microsoft Entra ID OAuth mit dem Anmeldeinformationstyp Certificate verwenden möchten, stellen Sie sicher, dass Sie die zusätzlichen Einrichtungsschritte für diesen Authentifizierungstyp ausführen. Andernfalls tritt bei dem Aufruf ein Fehler auf. Weitere Informationen finden Sie unter Authentifizierung in einer Einzelmandantenumgebung.

Raw-Authentifizierung

Sofern die Option Raw verfügbar ist, können Sie diesen Authentifizierungstyp verwenden, wenn Sie Authentifizierungsschemas verwenden müssen, die nicht das Protokoll OAuth 2.0 befolgen. Bei diesem Typ legen Sie den Wert des Autorisierungsheaders, den Sie mit der ausgehenden Anforderung senden, manuell fest und geben diesen Headerwert in Ihrem Trigger oder Ihrer Aktion an.

Wichtig

Im folgenden Beispiel wird ein Beispielheader für eine HTTPS-Anforderung gezeigt, die das Protokoll OAuth 1.0 befolgt:

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"

Geben Sie in dem Trigger oder der Aktion, die die Raw-Authentifizierung unterstützt, diese Eigenschaftswerte an:

Eigenschaft (Designer)	Eigenschaft (JSON)	Erforderlich	Wert	BESCHREIBUNG
Authentifizierung	`type`	Ja	Raw	Der zu verwendende Authentifizierungstyp
Wert	`value`	Ja	<authorization-header-value>	Der für die Authentifizierung zu verwendende Wert des Autorisierungsheaders

Wenn Sie abgesicherte Parameter verwenden, um vertrauliche Informationen zu verarbeiten und zu schützen, z. B. in einer Azure Resource Manager-Vorlage zur Automatisierung der Bereitstellung, können Sie zur Runtime mit Ausdrücken auf diese Parameterwerte zugreifen. In dieser Beispieldefinition einer HTTP-Aktion werden der type der Authentifizierung als Raw angegeben und die Funktion parameters() verwendet, um die Parameterwerte abzurufen:

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

Authentifizierung der verwalteten Identität

Wenn die Option Verwaltete Identität für einen Trigger oder eine Aktion verfügbar ist, der oder die die Authentifizierung der verwalteten Identitäten unterstützt, kann Ihre Logik-App die systemseitig zugewiesene Identität oder eine einzelne manuell erstellte, benutzerseitig zugewiesene Identität verwenden, um den Zugriff auf Azure-Ressourcen, die von Microsoft Entra ID und nicht durch Anmeldeinformationen, Geheimnisse oder Microsoft Entra-Token geschützt werden, ohne Anmeldung zu authentifizieren. Azure verwaltet diese Identität für Sie und erleichtert den Schutz Ihrer Anmeldeinformationen, da Sie weder Geheimnisse verwalten noch Microsoft Entra-Token direkt verwenden müssen. Erfahren Sie mehr zu Azure-Diensten, die verwaltete Identitäten für die Microsoft Entra-Authentifizierung unterstützen.

Eine Ressource der Verbrauchslogik-App kann die vom System zugewiesene Identität oder eine einzelne manuell erstellte benutzerbasierte Identität verwenden.
Eine Standardlogik-App-Ressource unterstützt, dass die vom System zugewiesenen verwalteten Identitäten und mehrere vom Benutzer zugewiesene verwaltete Identitäten gleichzeitig aktiviert werden, obwohl Sie immer noch nur eine Identität auswählen können, die zu einem Zeitpunkt verwendet werden soll.

Hinweis

Standardmäßig ist die systemseitig zugewiesene Identität bereits für die Authentifizierung von Verbindungen zur Laufzeit aktiviert. Diese Identität unterscheidet sich von den Anmeldeinformationen für die Authentifizierung oder der Verbindungszeichenfolge, die Sie verwenden, wenn Sie eine Verbindung herstellen. Wenn Sie diese Identität deaktivieren, funktionieren Verbindungen zur Laufzeit nicht. Wählen Sie zum Anzeigen dieser Einstellung im Menü Ihrer Logik-App unter Einstellungen die Option Identität aus.

Bevor Ihre Logik-App eine verwaltete Identität verwenden kann, führen Sie die Schritte in Authentifizieren und Zugreifen auf Ressourcen mit verwalteten Identitäten in Azure Logic Apps aus. Diese Schritte aktivieren die verwaltete Identität in Ihrer Logik-App und richten den Zugriff dieser Identität auf die Zielressource in Azure ein.
Bevor eine Azure-Funktion eine verwaltete Identität verwenden kann, aktivieren Sie zuerst die Authentifizierung für Azure-Funktionen.

Geben Sie im Trigger oder der Aktion mit Unterstützung der Verwendung einer verwalteten folgende Informationen an:

Integrierte Trigger und Aktionen

Eigenschaft (Designer)	Eigenschaft (JSON)	Erforderlich	Wert	BESCHREIBUNG
Authentifizierung	`type`	Ja	Verwaltete Identität oder `ManagedServiceIdentity`	Der zu verwendende Authentifizierungstyp
Verwaltete Identität	`identity`	Nein	<user-assigned-identity-ID>	Die zu verwendende, benutzerseitig zugewiesene verwaltete Identität. Hinweis: Schließen Sie diese Eigenschaft nicht ein, wenn Sie die systemseitig zugewiesene verwaltete Identität verwenden.
Zielgruppe	`audience`	Ja	<target-resource-ID>	Die Ressourcen-ID der Zielressource, auf die Sie zugreifen möchten. Beispielsweise macht `https://storage.azure.com/` die Zugriffstoken für die Authentifizierung für alle Speicherkonten gültig. Sie können jedoch auch für ein bestimmtes Speicherkonto eine Stammdienst-URL angeben, z. B. `https://fabrikamstorageaccount.blob.core.windows.net`. Hinweis: Die Eigenschaft Zielgruppe kann in einigen Triggern oder Aktionen ausgeblendet sein. Um diese Eigenschaft einzublenden, öffnen Sie für den Trigger oder die Aktion die Liste Erweiterte Parameter, und wählen Sie Zielgruppe aus. Wichtig: Vergewissern Sie sich, dass die Zielressourcen-ID genau dem Wert entspricht, der in Microsoft Entra ID erwartet wird, einschließlich aller erforderlichen nachgestellten Schrägstriche. Daher erfordert die `https://storage.azure.com/`-Ressourcen-ID für alle Azure Blob Storage-Konten einen nachgestellten Schrägstrich. Allerdings erfordert die Ressourcen-ID für ein bestimmtes Speicherkonto keinen nachgestellten Schrägstrich. Informationen zum Auffinden dieser Ressourcen-IDs finden Sie unter Azure-Dienste, die MIcrosoft Entra ID unterstützen.

Wenn Sie abgesicherte Parameter verwenden, um vertrauliche Informationen zu verarbeiten und zu schützen, z. B. in einer Azure Resource Manager-Vorlage zur Automatisierung der Bereitstellung, können Sie zur Runtime mit Ausdrücken auf diese Parameterwerte zugreifen. In dieser Beispieldefinition einer HTTP-Aktion werden der type der Authentifizierung als ManagedServiceIdentity angegeben und die parameters()-Funktion verwendet, um die Parameterwerte abzurufen:

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

Verwaltete Connectors als Trigger und Aktionen

Eigenschaft (Designer)	Erforderlich	Wert	BESCHREIBUNG
Verbindungsname	Ja	<connection-name>
Verwaltete Identität	Yes	Systemseitig zugewiesene verwaltete Identität oder <user-assigned-managed-identity-name>	Der zu verwendende Authentifizierungstyp

Blockieren der Verbindungserstellung

Falls Ihre Organisation das Herstellen einer Verbindung mit bestimmten Ressourcen mithilfe der Connectors in Azure Logic Apps nicht erlaubt, können Sie mithilfe von Azure Policy für bestimmte Connectors in Logik-App-Workflows die Funktion zum Erstellen dieser Verbindungen blockieren Weitere Informationen finden Sie unter Blockieren der von Connectors in Azure Logic Apps erstellten Verbindungen.

Isolationsanleitung für Logik-Apps

Sie können Azure Logic Apps in Azure Government verwenden, wobei alle Auswirkungsstufen in den Regionen unterstützt werden, die im Isolationsleitfaden für die Auswirkungsstufe 5 in Azure Government beschrieben werden. Um diese Anforderungen zu erfüllen, bietet Ihnen Azure Logic Apps die Möglichkeit, Workflows in einer Umgebung mit dedizierten Ressourcen zu erstellen und auszuführen, damit Sie die Leistungsauswirkungen durch andere Azure-Mandanten auf Ihre Logik-Apps verringern und die Freigabe von Computingressourcen für andere Mandanten vermeiden können.
Standard-Logik-App-Workflows können privat und sicher mit einem virtuellen Azure-Netzwerk kommunizieren, und zwar über private Endpunkte, die Sie für eingehenden Datenverkehr einrichten, und über die Integration des virtuellen Netzwerks für ausgehenden Datenverkehr. Weitere Informationen finden Sie unter Schützen des Datenverkehrs zwischen virtuellen Netzwerken und Workflows mit nur einem Mandanten in Azure Logic Apps mithilfe privater Endpunkte.
Um Ihren eigenen Code auszuführen oder eine XML-Transformation auszuführen, erstellen und rufen Sie eine Azure-Funktion auf, anstatt die Inlinecodefunktion zu verwenden, oder stellen Sie als Zuordnungen zu verwendende Assemblys bereit. Richten Sie außerdem die Hostingumgebung für ihre Funktions-App so ein, dass Sie Ihren Isolationsanforderungen entspricht.

Um z. B. Anforderungen der Auswirkungsstufe 5 zu erfüllen, erstellen Sie Ihre Funktions-App mit dem App Service Plan, der den Tarif Isoliert zusammen mit einer App Service-Umgebung (ASE) verwendet, die ebenfalls den Tarif Isoliert verwendet. In dieser Umgebung werden Funktions-Apps auf dedizierte Azure-VMs und in dedizierten virtuellen Azure-Netzwerken ausgeführt, die zusätzlich zur Computeisolation eine Netzwerkisolation für Ihre Apps bieten sowie maximale horizontale Skalierungsmöglichkeiten.

Weitere Informationen finden Sie in der folgenden Dokumentation:

Weitere Informationen finden Sie in der folgenden Dokumentation:

Teilen über

Schützen des Zugriffs und der Daten für Workflows in Azure Logic Apps

Zugriff auf Logik-App-Vorgänge

Verbrauchsworkflows

Workflows vom Typ „Standard“

Zugriff auf Ausführungsverlaufsdaten

Beschränken des Zugriffs nach IP-Adressbereich

Verbrauchsworkflows

Workflows vom Typ „Standard“

Schützen von Daten im Ausführungsverlauf mittels Obfuskation

Überlegungen im Zusammenhang mit dem Schützen von Ein- und Ausgaben

Schützen von Ein- und Ausgaben im Designer

Schützen von Ein- und Ausgaben in der Codeansicht

Zugriff auf Parametereingaben

Schützen von Parameter in Workflowdefinitionen (Verbrauchsworkflow)

Schützen von Parametern in Azure Resource Manager-Vorlagen (Verbrauchsworkflow)

Authentifizierungstypen für Connectors, die die Authentifizierung unterstützen

Zugriff für eingehende Aufrufe anforderungsbasierter Trigger

Aktivieren von OAuth 2.0 mit Microsoft Entra ID

Überlegungen vor der Aktivierung von OAuth 2.0 mit Microsoft Entra ID

Aktivieren von OAuth 2.0 mit Microsoft Entra ID als einziger Option zum Aufrufen eines Anforderungsendpunkts (nur Verbrauch)

Abrufen eines Proof-of-Possession(PoP)-Tokens

Aktivieren von OAuth mit Microsoft Entra ID für Ihre Logik-App-Verbrauchsressourcen

Einschließen des Autorisierungsheaders in die Ausgaben des Anforderungs- oder HTTP-Webhooktriggers

Generieren eines SAS-Schlüssels (Shared Access Signature) oder -Tokens

Deaktivieren der SAS-Authentifizierung (Shared Access Signature; nur Verbrauch)

Voraussetzungen

Suchen nach Triggern mit aktivierter oder deaktivierter SAS

Hinzufügen der sasAuthenticationPolicy-Eigenschaft zur Workflowdefinition

Erneutes Generieren von Zugriffsschlüsseln

Erstellen ablaufender Rückruf-URLs

Erstellen von URLs mit einem primären oder sekundären geheimen Schlüssel

Verfügbarmachen Ihrer Logik-App-Workflow mit Azure API Management

Einschränken eingehender IP-Adressen

Verbrauchsworkflows

Workflows vom Typ „Standard“

Zugriff für ausgehende Aufrufe anderer Dienste und Systeme

Hinzufügen der Authentifizierung zu ausgehenden Aufrufen

Standardauthentifizierung

Clientzertifikatsauthentifizierung

Microsoft Entra-Plattform

Raw-Authentifizierung

Authentifizierung der verwalteten Identität

Blockieren der Verbindungserstellung

Isolationsanleitung für Logik-Apps

Zugehöriger Inhalt

Feedback

Zusätzliche Ressourcen