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

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:

  • Logik-App-Mitwirkender: Ermöglicht Ihnen die Verwaltung von Logik-Apps, aber nicht die Änderung des App-Zugriffs.

  • Logik-App-Operator: Ermöglicht Ihnen das Lesen, Aktivieren und Deaktivieren von Logik-Apps, die Sie aber nicht bearbeiten oder aktualisieren können.

  • Mitwirkender: Gewährt vollen Zugriff auf die Verwaltung aller Ressourcen, erlaubt aber nicht die Zuweisung von Rollen in Azure RBAC, die Verwaltung von Zuweisungen in Azure Blueprints oder die Freigabe von Bildergalerien.

    Angenommen, Sie müssen mit einer Logik-App arbeiten, die Sie nicht erstellt und keine Verbindungen authentifiziert haben, die vom Workflow dieser Logik-App verwendet werden. Für Ihr Azure-Abonnement ist die Berechtigung „Mitwirkender“ für die Ressourcengruppe erforderlich, 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 Personen Ihre Logik-App ändern oder löschen, können Sie Azure-Ressourcensperren 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.

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 Ein- und Ausgaben im Ausführungsverlauf Ihrer Logik-App so einschränken, dass diese Daten nur für Anforderungen aus bestimmten IP-Adressbereichen einsehbar sind.

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 entfernen und erhalten damit die Möglichkeit für einen Just-In-Time-Zugriff auf die Daten Ihrer Logik-App.

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:

  1. Öffnen Sie im Azure-Portal die Logik-App im Workflow-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.

    Gültige IP-Adressbereiche verwenden die Formate x.x.x.x/x oder x.x.x.x-x.x.x.x.

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

    Secured outputs as inputs and downstream impact on most actions

    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.

    Secured outputs as inputs with downstream impact on specific actions

    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.

    Secured inputs and downstream impact on most actions

    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.

    Secured inputs and downstream impact on specific actions

Schützen von Ein- und Ausgaben im Designer

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

    Open logic app in Logic App Designer

  2. Wählen Sie für den Trigger oder die Aktion, bei dem/der Sie vertrauliche Daten schützen möchten, die Schaltfläche mit den Auslassungspunkten ( ... ) und dann Einstellungen aus.

    Open trigger or action settings

  3. Aktivieren Sie entweder Sichere Eingaben, Sichere Ausgaben oder beides. Klicken Sie auf Fertig, wenn Sie fertig sind.

    Turn on

    Die Aktion oder der Trigger zeigt jetzt ein Schlosssymbol in der Titelleiste an.

    Action or trigger title bar shows lock icon

    Token, die sichere Ausgaben aus früheren Aktionen darstellen, zeigen ebenfalls Schlosssymbole an. Wenn Sie beispielsweise eine solche Ausgabe aus der Liste mit dynamischen Inhalten für eine Aktion auswählen, zeigt das entsprechende Token ein Schlosssymbol an.

    Select token for secured output

  4. Nachdem die Logik-App ausgeführt wurde, können Sie den Verlauf für diese Ausführung anzeigen.

    1. Wählen Sie im Bereich Übersicht der Logik-App die Ausführung aus, die Sie anzeigen möchten.

    2. Erweitern Sie im Bereich Logik-App-Ausführung die Aktionen, die Sie überprüfen möchten.

      Wenn Sie sowohl die Ein- als auch die Ausgaben zum Verbergen ausgewählt haben, werden diese Werte jetzt ausgeblendet.

      Hidden inputs and outputs in run history

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 Azure Active Directory Open Authentication (Azure AD OAuth) authentifizieren, können Sie die Parameter definieren und verbergen, die die Client-ID und das Clientgeheimnis akzeptieren, die für die Authentifizierung verwendet werden. Um diese Parameter für Ihre 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 Ihrer Logik-App 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. Autorisierungsheader sind nie ü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:

Sichere Parameter in Workflowdefinitionen

Zum Schützen sensibler Informationen in der Workflowdefinition der Logik-App verwenden Sie sichere Parameter, damit diese Informationen nach dem Speichern der Logik-App 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": {}
}

Sichere Parameter in Azure Resource Manager-Vorlagen

Eine Resource Manager-Vorlage für eine Logik-App 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 Ihrer Logik-App zur Runtime 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 Trigger und Aktionen, die die Authentifizierung unterstützen

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

Authentifizierungsart Unterstützte Trigger und Aktionen
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 Azure API Management, Azure App Services, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
Raw Azure API Management, Azure App Services, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
Verwaltete Identität Verbrauchs-Logik-App:

- Integriert: Azure API Management, Azure App Services, Azure Functions, HTTP, HTTP-Webhook

- Verwalteter Connector (Vorschau):

--- Einzelauthentifizierung: Azure AD Identity Protection, Azure Automation, Azure Container Instance, Azure Data Explorer, Azure Data Factory, Azure Data Lake, Azure Event Grid, Azure Key Vault, Azure Resource Manager, Microsoft Sentinel, HTTP mit Azure AD

--- Mehrfachauthentifizierung: Azure Blob Storage, Azure Event Hubs, Azure Service Bus, SQL Server

___________________________________________________________________________________________

Standard-Logik-App:

- Integriert: HTTP, HTTP-Webhook

- Verwalteter Connector (Vorschau):

--- Einzelauthentifizierung: Azure AD Identity Protection, Azure Automation, Azure Container Instance, Azure Data Explorer, Azure Data Factory, Azure Data Lake, Azure Event Grid, Azure Key Vault, Azure Resource Manager, Microsoft Sentinel, HTTP mit Azure AD

--- Mehrfachauthentifizierung: Azure Blob Storage, Azure Event Hubs, Azure Service Bus, 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 Aufrufe an einen Anforderungsendpunkt können nur ein Autorisierungsschema verwenden, entweder SAS oder Azure Active Directory Open Authentication. 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ü der Logik-App 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.

Aktivieren der Azure Active Directory Open Authentication (Azure AD 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 Azure AD 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 Ihre Logik-App 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 dem Aktivieren von Azure AD OAuth

  • Bei einem eingehenden Aufruf an den Anforderungsendpunkt kann nur ein Autorisierungsschema verwendet werden, entweder Azure AD OAuth 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.

    Um Azure AD OAuth zu aktivieren, sodass diese Option die einzige Möglichkeit zum Aufrufen des Anforderungsendpunkts ist, führen Sie die folgenden Schritte aus:

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

    2. Wählen Sie in der oberen rechten Ecke des Triggers die Schaltfläche mit den Auslassungspunkten (...) und dann Einstellungen aus.

    3. Wählen Sie unter Triggerbedingungen die Option Hinzufügen aus. Geben Sie im Feld für die Triggerbedingung den folgenden Ausdruck ein, und wählen Sie Fertig aus.

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

    Hinweis

    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.

  • Nur Bearer-artige Autorisierungsschemas werden für Azure AD OAuth-Zugriffstoken unterstützt, was bedeutet, dass im Authorization-Header für das Zugriffstoken der Typ Bearer angegeben werden muss.

  • Ihre Logik-App 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 Azure AD-Aussteller-ID hat, der entweder mit https://sts.windows.net/ oder mit https://login.microsoftonline.com/ (OAuth V2) beginnt.

    Angenommen, Ihre Logik-App 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 Azure AD OAuth für Ihre Logik-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 Logik-App hinzu:

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

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

    Select

  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:

    Provide information for authorization policy

    Eigenschaft Erforderlich BESCHREIBUNG
    Richtlinienname Ja Der Name, den Sie für die Autorisierungsinstanz verwenden möchten
    Ansprüche Ja Die Anspruchstypen und -werte, die ihre Logik-App von eingehenden Aufrufen akzeptiert. Der Anspruchswert ist auf eine maximale Anzahl von Zeichen beschränkt. Im Folgenden finden Sie die verfügbaren Anspruchstypen:

    - Aussteller
    - Zielgruppe
    - Betreff
    - JWT-ID (JSON Web Token-Bezeichner)

    Die Liste der Ansprüche muss mindestens den Anspruch Aussteller enthalten, dem als Azure AD-Aussteller-ID ein Wert zugeordnet ist, der mit https://sts.windows.net/ oder https://login.microsoftonline.com/ beginnt. Weitere Informationen zu diesen Anspruchstypen finden Sie unter Ansprüche in Sicherheitstoken von Azure AD. Sie können auch Ihren eigenen Anspruchstyp und -wert angeben.

  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 „Authorization“-Headers in Anforderungstriggerausgaben.

Workfloweigenschaften wie Richtlinien werden nicht in der Codeansicht Ihrer Logik-App 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 „Authorization“-Headers in Anforderungstriggerausgaben

Für Logik-Apps, die Azure Active Directory Open Authentication (Azure AD OAuth) aktivieren, um den Zugriff eingehender Aufrufe an anforderungsbasierte Trigger zu autorisieren, können Sie die Anforderungstrigger- oder HTTP-Webhook-Triggerausgaben für die die Aufnahme des Authorization-Headers aus dem OAuth-Zugriffstoken aktivieren. 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 mit Azure API Management

Für weitere Authentifizierungsprotokolle und Optionen sollten Sie Ihre Logik-App 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. Zur Autorisierung des Zugriffs auf diesen Endpunkt können Sie Azure Active Directory Open Authentication (Azure AD OAuth), Clientzertifikate oder andere 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 Ihre Logik-App 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 Ihre Logik-App aufrufen können. Beispiel: Wenn Sie den Anforderungsendpunkt mit Azure API Management verwalten, können Sie für die Logik-App festlegen, dass sie 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 eine Logik-App, die 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 Ihre Logik-App einzuschränken, führen Sie die folgenden Schritte für das Azure-Portal oder für Ihre Azure Resource Manager-Vorlage aus:

Im Azure-Portal wirkt sich dieser Filter sowohl auf Trigger als auch auf Aktionen aus, im Gegensatz zur 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 oder die Azure Logic Apps-REST-API: Workflow – Vorgang erstellen oder aktualisieren.

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

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

  3. Wählen Sie im Abschnitt Konfiguration der Zugriffssteuerung unter Zulässige eingehende IP-Adressen den Pfad für Ihr Szenario aus:

    • Damit Ihre Logik-App nur über die integrierte Azure Logic Apps-Aktion als geschachtelte Logik-App aufgerufen werden kann, wählen Sie Nur andere Logik-Apps aus. Dies funktioniert nur, wenn Sie die Azure Logic Apps-Aktion für den Aufruf der geschachtelten Logik-App verwenden.

      Diese Option schreibt ein leeres Array in Ihre Logik-App-Ressource und legt fest, dass nur Aufrufe von übergeordneten Logik-Apps, die die Azure Logic Apps-Aktion verwenden, die geschachtelte Logik-App auslösen können.

    • Damit Ihre Logik-App nur über die HTTP-Aktion als geschachtelte App aufgerufen werden kann, wählen Sie Spezifische IP-Bereiche aus, nichtNur andere Logik-Apps. Wenn das Feld IP-Bereiche für Trigger angezeigt wird, geben Sie die ausgehenden IP-Adressen der übergeordneten Logik-App ein. Ein gültiger IP-Adressbereich 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 Ihrer geschachtelten Logik-App verwenden, wird der Aufruf blockiert, und Sie erhalten einen „401 – nicht autorisiert“-Fehler.

    • 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. Ein gültiger IP-Adressbereich 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.

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:

Im Folgenden finden Sie weitere Möglichkeiten, wie Sie Endpunkte, die Aufrufe von Ihrer Logik-App 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-Apps ein.

    Alle Aufrufe von Logik-Apps 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 im Workflow ihrer Logik-App aufrufen, indem Sie den integrierten API Management-Trigger bzw. die integrierte API Management-Aktion 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.

      1. Geben Sie im Workflow-Designer im Suchfeld api management ein. Wählen Sie den Schritt aus, je nachdem, ob Sie einen Trigger oder eine Aktion hinzufügen:

        • Wenn Sie einen Trigger hinzufügen, bei dem es sich immer um den ersten Schritt in Ihrem Workflow handelt, wählen Sie Azure API Management-Trigger auswählen aus.

        • Wenn Sie eine Aktion hinzufügen, wählen Sie Azure API Management-Aktion auswählen aus.

        Im folgenden Beispiel wird ein Trigger hinzugefügt:

        Add Azure API Management trigger

      2. Wählen Sie Ihre zuvor erstellte API Management-Dienstinstanz aus.

        Select API Management service instance

      3. Wählen Sie den zu verwendenden API-Aufruf aus.

        Select existing API

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 verwenden, indem Sie die folgenden Schritte ausführen:

1. Speichern Sie den Zertifikatsinhalt in einer Variablen:

$pfx_cert = get-content 'c:\certificate.pfx' -Encoding Byte

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

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 Ressource vom Typ Logik-App (Standard) in Azure Logic Apps mit nur einem Mandanten verfügen und einen HTTP-Vorgang mit einem TSL/SSL-Zertifikat, einem Clientzertifikat oder Azure Active Directory Open Authentication (Azure AD OAuth) mit dem Anmeldeinformationstyp Certificate verwenden möchten, müssen Sie weitere Schritte zum Einrichten dieses Authentifizierungstyps 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:

Azure Active Directory Open Authentication

Bei Anforderungstriggern können Sie nach der Einrichtung von Azure AD-Autorisierungsrichtlinien eingehende Anrufe für Ihre Logik-App mit Azure Active Directory Open Authentication (Azure AD OAuth) authentifizieren. 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 Azure AD-Authentifizierungsendpunkte.
Mandant tenant Ja <tenant-ID> Die Mandanten-ID für den Azure AD-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 Ressource vom Typ Logik-App (Standard) in Azure Logic Apps mit nur einem Mandanten verfügen und einen HTTP-Vorgang mit einem TSL/SSL-Zertifikat, einem Clientzertifikat oder Azure Active Directory Open Authentication (Azure AD OAuth) mit dem Anmeldeinformationstyp Certificate verwenden möchten, müssen Sie weitere Schritte zum Einrichten dieses Authentifizierungstyps 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 Azure Active Directory (Azure AD) und nicht durch Anmeldeinformationen, Geheimnisse oder Azure AD-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 Azure AD-Token direkt verwenden müssen. Erfahren Sie mehr zu Azure-Diensten, die verwaltete Identitäten für die Azure AD-Authentifizierung unterstützen.

  • Der Ressourcentyp Logik-App (Verbrauch) unterstützt die Verwendung der systemseitig zugewiesenen Identität oder einer benutzerseitig zugewiesenen einzelnen Identität.

  • Der Ressourcentyp Logik-App (Standard) unterstützt die gleichzeitige Aktivierung der systemseitig zugewiesenen verwalteten Identität und mehrerer benutzerseitig zugewiesener verwalteter Identitäten. Sie können jedoch immer noch jeweils nur eine Identität auswählen.

    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 diese Zielressourcen-ID genau dem Wert entspricht, den Azure AD erwartet, 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 Azure AD 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 zur Isolation finden Sie in der folgenden Dokumentation:

Nächste Schritte