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

  • Artikel

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:

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

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.

Um die zulässigen IP-Adressbereiche anzugeben, führen Sie die folgenden Schritte für das Azure-Portal oder für Ihre Azure Resource Manager-Vorlage aus:

Verbrauchsworkflows

  1. Öffnen Sie im Azure-Portal den Logik-App-Workflow im Designer.

  2. Wählen Sie im Menü Ihrer Logik-App unter Einstellungen die Option Workfloweinstellungen aus.

  3. Wählen Sie unter Konfiguration der Zugriffssteuerung>Zulässige eingehende IP-Adressen die Option Spezifische IP-Bereiche aus.

  4. Geben Sie unter IP-Bereiche für Inhalte die IP-Adressbereiche an, die auf Inhalte von Eingaben und Ausgaben zugreifen können.

Workflows vom Typ „Standard“

  1. Öffnen Sie Ihre Logik-App-Ressource im Azure-Portal.

  2. Wählen Sie im Logik-App-Menü unter Einstellungen die Option Netzwerk aus.

  3. Wählen Sie im Abschnitt Eingehender Datenverkehr die Option Zugriffseinschränkung aus.

  4. Erstellen Sie mindestens eine Regel, um Anforderungen aus bestimmten IP-Adressbereichen entweder zuzulassen oder zu verweigern. Sie können auch die HTTP-Headerfiltereinstellungen und Weiterleitungseinstellungen verwenden.

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

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ängeunterstü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.

    Sichere Ausgaben als Eingaben und nachgeschaltete Auswirkungen auf die meisten Aktionen

    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.

    Sichere Ausgaben als Eingaben mit nachgeschalteten Auswirkungen auf bestimmte Aktionen

    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.

    Sichere Eingaben und nachgeschaltete Auswirkungen auf die meisten Aktionen

    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.

    Sichere Eingaben und nachgeschaltete Auswirkungen auf bestimmte Aktionen

Schützen von Ein- und Ausgaben im Designer

  1. Öffnen Sie im Azure-Portal den Logik-App-Workflow im Designer.

  2. Wählen Sie im Designer den Trigger oder die Aktion aus, bei dem/der Sie vertrauliche Daten schützen möchten.

  3. Wählen Sie im daraufhin geöffneten Informationsbereich Einstellungen aus und erweitern Sie Sicherheit.

    Screenshot: Azure-Portal, Workflow-Designer und der Trigger oder die Aktion mit geöffneten Einstellungen.

  4. Aktivieren Sie entweder Sichere Eingaben, Sichere Ausgaben oder beides.

    Screenshot: Workflow mit aktivierten Einstellungen für sichere Eingaben oder sichere Ausgaben für eine Aktion.

    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.

    Screenshot: Workflow mit der geöffneten Liste der dynamischen Inhalte einer nachfolgenden Aktion und dem Token der vorherigen Aktion für die gesicherte Ausgabe mit dem Schlosssymbol.

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

      Screenshot: Ansicht des Standardworkflowverlaufs mit ausgeblendeten Eingaben und Ausgaben.

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:

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:

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.

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

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 Services, HTTP, HTTP + Swagger, HTTP Webhook
Clientzertifikat Azure API Management, Azure App Services, HTTP, HTTP + Swagger, HTTP Webhook
Active Directory OAuth - Verbrauch: Azure API Management, Azure App Services, 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 Services, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
Verwaltete Identität Integrierte Connectors:

- Verbrauch: Azure API Management, Azure App Services, 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

Zugriff für eingehende Aufrufe anforderungsbasierter Trigger

Eingehende Aufrufe, die eine Logik-App über einen anforderungsbasierten Trigger wie Anforderung oder HTTP-Webhook empfängt, unterstützen Verschlüsselung und werden mit TLS 1.2 (Transport Layer Security) (zuvor als Secure Sockets Layer (SSL) bezeichnet) geschützt. 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. 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

Hinweis

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 bei Verwendung des Azure Logic Apps-Diensts oder eines Sicherheitstools für die URL Ihrer Logik-App die TLS-Handshakenachrichten 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 weitere Möglichkeiten für eine Einschränkung des Zugriffs auf Trigger, die eingehende Aufrufe Ihrer Logik-App empfangen, sodass nur autorisierte Clients Ihre Logik-App aufrufen können:

Generieren von Shared Access Signatures (SAS)

Jeder Anforderungsendpunkt für eine Logik-App weist in der URL des Endpunkts eine Shared Access Signature (SAS) im folgenden Format auf:

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

Jede URL enthält die Abfrageparameter sp, sv und sig, wie in dieser Tabelle beschrieben:

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 verschlüsselt, wird mit der Logik-App gespeichert und wird nie verfügbar gemacht oder veröffentlicht. Die Logik-App autorisiert nur Trigger, die eine gültige, mit dem geheimen Schlüssel erstellte Signatur enthalten.

Eingehende Anrufe an einen Anforderungsendpunkt können nur ein Autorisierungsschema verwenden, entweder SAS oder OAuth 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 der Dienst nicht weiß, welches Schema ausgewählt werden soll.

Weitere Informationen zum Schützen des Zugriffs mit einer SAS (Shared Access Signature) finden Sie in den folgenden Abschnitten in diesem Thema:

Erneutes Generieren von Zugriffsschlüsseln

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

  1. Öffnen Sie im Azure-Portal die Logik-App mit dem Schlüssel, den Sie erneut generieren möchten.

  2. Wählen Sie im Menü Ihrer Logik-App-Ressource unter Einstellungen die Option Zugriffsschlüssel aus.

  3. Wählen Sie den Schlüssel aus, den Sie erneut generieren möchten, und schließen Sie den Vorgang ab.

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/<Azure-subscription-ID>/resourceGroups/<Azure-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 Logic Apps-REST-API. Beispiel:

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

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.

Microsoft Entra ID Open Authentication aktivieren (Microsoft Entra ID OAuth)

In einem Workflow der Verbrauchs-Logik-App, der mit einem anforderungsbasierten Trigger beginnt, können Sie eingehende Aufrufe, die an den Endpunkt gesendet wurden, der durch diesen Trigger erstellt wurde, authentifizieren, indem Sie Microsoft Entra ID OAuth aktivieren. Um diese Authentifizierung einzurichten, definieren Sie eine Autorisierungsrichtlinie auf Logik-App-Ebene 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 Standard-Logik-App-Workflow, der mit dem Anforderungstrigger beginnt (aber keinem Webhooktrigger), können Sie die Azure Functions-Bereitstellung für die Authentifizierung eingehender Aufrufe, die an den Endpunkt gesendet wurden, der durch diesen Trigger erstellt wurde, 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 Microsoft Entra ID OAuth

  • Bei einem eingehenden Aufruf an den Anforderungsendpunkt kann nur ein Autorisierungsschema verwendet werden, entweder OAuth mit Microsoft Entra ID oder Shared Access Signature (SAS). 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.

  • 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-Ressource 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 einen Wert als Microsoft Entra-Aussteller-ID 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": "72f988bf-86f1-41af-91ab-2d7cd011db47",
    "unique_name": "SophiaOwen@fabrikam.com",
    "upn": "SophiaOwen@fabrikam.com",
    "uti": "TPJ7nNNMMZkOSx6_uVczUAA",
    "ver": "1.0"
}

Aktivieren von Microsoft Entra ID OAuth als einzige Option zum Aufrufen eines Anforderungsendpunkts

  1. Richten Sie 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 aufzunehmen.

    Hinweis

    Durch diesen Schritt wird der Authorization-Header im Ausführungsverlauf des Workflows und in den Ausgaben des Triggers sichtbar.

  2. Öffnen Sie im Azure-Portal Ihren Verbrauchs-Logik-App-Workflow im Designer.

  3. Wählen Sie im Designer den Trigger aus. Wählen Sie im daraufhin geöffneten Informationsbereich Einstellungen aus.

  4. 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-Workflow, 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 Ihrer Verbrauchslogik-App-Workflow verwenden möchten, folgen Sie dem nächsten Abschnitt, um OAuth mit Microsoft Entra ID einzurichten.

Aktivieren von Microsoft Entra ID-OAuth für Ihre Ressourcen der Verbrauchslogik-App

Führen Sie die folgenden Schritte für das Azure-Portal oder für Ihre Azure Resource Manager-Vorlage aus:

Fügen Sie im Azure-Portal mindestens eine Autorisierungsrichtlinie zu Ihrer Verbrauchslogik-App-Ressource hinzu:

  1. Öffnen Sie im Azure-Portal Ihre Verbrauchslogik-App im Workflow-Designer.

  2. Wählen Sie im Menü Ihrer Logik-App-Ressource unter Einstellungen die Option Autorisierung aus. Sobald der Bereich „Autorisierung“ geöffnet ist, wählen Sie Richtlinie hinzufügen aus.

    Screenshot, der das Azure-Portal, die Seite „Verbrauchslogik-App | Autorisierung“ und die ausgewählte Schaltfläche „Richtlinie hinzufügen“ anzeigt.

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

    Screenshot, der das Azure-Portal, die Seite „Verbrauchslogik-App | Autorisierung“ und die Informationen für die Autorisierungsrichtlinie anzeigt.

    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:

    Screenshot, der das Azure-Portal, die Seite „Verbrauchslogik-App | Autorisierung“ und die Informationen für die Proof-of-Profession-Richtlinie anzeigt.

  4. 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": "72f988bf-86f1-41af-91ab-2d7cd011db47".

  5. Zum Hinzufügen einer weiteren Autorisierungsrichtlinie wählen Sie Richtlinie hinzufügen aus. Wiederholen Sie die vorherigen Schritte, um die Richtlinie einzurichten.

  6. Klicken Sie auf Speichern, wenn Sie fertig sind.

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

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 Anforderungstrigger oder die HTTP-Webhook-Triggerausgabe aktivieren, um den Authorization-Header aus dem OAuth-Zugriffstoken einzuschließ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:

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, der einen anforderungsbasierten Trigger hat, mithilfe der Anforderung Logic Apps-REST-API: Workflowtrigger – Ausführen oder über API Management weiterhin ausführen. 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.

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 die Azure Logic Apps-REST-API: Workflow – Vorgang erstellen oder aktualisieren.

Verbrauchsworkflows

  1. Öffnen Sie im Azure-Portal Ihre Verbrauchslogik-App im Workflow-Designer.

  2. Wählen Sie im Menü der Logik-App unter Einstellungen die Option Workfloweinstellungen.

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

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

  1. Öffnen Sie Ihre Logik-App-Ressource im Azure-Portal.

  2. Wählen Sie im Logik-App-Menü unter Einstellungen die Option Netzwerk aus.

  3. Wählen Sie im Abschnitt Eingehender Datenverkehr die Option Zugriffseinschränkung aus.

  4. Erstellen Sie mindestens eine Regel, um Anforderungen aus bestimmten IP-Adressbereichen entweder zuzulassen oder zu verweigern. 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).

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:

        Screenshot: Azure-Portal, Verbrauchs-Workflow-Designer und Finden eines Azure API Management-Triggers.

      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.

        Screenshot: Azure-Portal, Standard-Workflow-Designer und Azure API Management-Aktion.

      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.

        Screenshot: Azure-Portal, Standard-Workflow-Designer und die ausgewählte API, die aufgerufen werden soll.

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 Neuen Parameter hinzufügen, und wählen Sie Authentifizierung aus.

Wichtig

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

Standardauthentifizierung

Wenn die Option Standard verfügbar ist, geben Sie die folgenden Eigenschaftswerte 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": {}
}

Authentifizierung mit Clientzertifikat

Wenn die Option Clientzertifikat verfügbar ist, geben Sie die folgenden Eigenschaftswerte 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:

  1. Deinstallieren Sie alle OpenSSL-Instanzen.
  2. Installieren Sie OpenSSL, Version 1.1.1t.
  3. Signieren Sie Ihr Zertifikat mithilfe des neuen Updates neu.
  4. 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 Identity Platform

Bei Anforderungstriggern können Sie die Microsoft Identity Platform verwenden, um eingehende Anrufe zu authentifizieren, nachdem Sie Microsoft Entra-Autorisierungsrichtlinien für Ihre Logik-App eingerichtet haben. Geben Sie für alle anderen Trigger und Aktionen, die Ihnen den Active Directory OAuth-Authentifizierungstyp zur Auswahl bereitstellen, die folgenden Eigenschaftswerte an:

Eigenschaft (Designer) Eigenschaft (JSON) Erforderlich Wert BESCHREIBUNG
Authentifizierung type Ja Active Directory OAuth
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 das Zugriffstoken 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 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.

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.

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.

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

  2. Bevor eine Azure-Funktion eine verwaltete Identität verwenden kann, aktivieren Sie zuerst die Authentifizierung für Azure-Funktionen.

  3. 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 Neuen Parameter hinzufügen, 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.

Weitere Informationen finden Sie in der folgenden Dokumentation:

Nächste Schritte