Bezpieczny dostęp i dane dla przepływów pracy w usłudze Azure Logic Apps

  • Artykuł

Usługa Azure Logic Apps korzysta z usługi Azure Storage do przechowywania i automatycznego szyfrowania danych magazynowanych. To szyfrowanie chroni dane i pomaga sprostać wymaganiom w zakresie bezpieczeństwa i zgodności w organizacji. Domyślnie usługa Azure Storage na potrzeby szyfrowania danych używa kluczy zarządzanych przez firmę Microsoft. Aby uzyskać więcej informacji, zobacz Szyfrowanie usługi Azure Storage dla danych nieużywanych.

Aby lepiej kontrolować dostęp i chronić poufne dane w usłudze Azure Logic Apps, możesz skonfigurować więcej zabezpieczeń w następujących obszarach:

Aby uzyskać więcej informacji na temat zabezpieczeń na platformie Azure, zapoznaj się z następującymi tematami:

Dostęp do operacji aplikacji logiki

W przypadku tylko aplikacji logiki zużycie, zanim będzie można tworzyć aplikacje logiki i ich połączenia lub zarządzać nimi, potrzebne są określone uprawnienia, które są udostępniane za pośrednictwem ról przy użyciu kontroli dostępu na podstawie ról (RBAC) platformy Azure. Można również skonfigurować uprawnienia, aby tylko konkretni użytkownicy lub grupy mogli uruchamiać określone zadania, takie jak zarządzanie, edytowanie i wyświetlanie aplikacji logiki. Aby kontrolować ich uprawnienia, możesz przypisać wbudowane lub dostosowane role do członków, którzy mają dostęp do subskrypcji platformy Azure. Usługa Azure Logic Apps ma następujące określone role na podstawie tego, czy masz przepływ pracy aplikacji logiki Zużycie, czy Standardowa:

Przepływy pracy użycia
Rola opis
Współautor aplikacji logiki Możesz zarządzać przepływami pracy aplikacji logiki, ale nie możesz zmienić dostępu do nich.
Operator aplikacji logiki Możesz odczytywać, włączać i wyłączać przepływy pracy aplikacji logiki, ale nie można ich edytować ani aktualizować.
Współautor Masz pełny dostęp do zarządzania wszystkimi zasobami, ale nie możesz przypisywać ról w kontroli dostępu opartej na rolach platformy Azure, zarządzać przypisaniami w usłudze Azure Blueprints ani udostępniać galerii obrazów.

Załóżmy na przykład, że musisz pracować z przepływem pracy aplikacji logiki, który nie został utworzony i uwierzytelniony połączeń używanych przez przepływ pracy aplikacji logiki. Subskrypcja platformy Azure wymaga uprawnień Współautor dla grupy zasobów zawierającej ten zasób aplikacji logiki. Jeśli tworzysz zasób aplikacji logiki, automatycznie masz dostęp współautora.

Aby uniemożliwić innym osobom zmianę lub usunięcie przepływu pracy aplikacji logiki, możesz użyć blokady zasobów platformy Azure. Ta funkcja uniemożliwia innym osobom zmianę lub usunięcie zasobów produkcyjnych. Aby uzyskać więcej informacji na temat zabezpieczeń połączeń, zapoznaj się z konfiguracją Połączenie ion w usłudze Azure Logic Apps i zabezpieczeniami i szyfrowaniem Połączenie ion.

Standardowe przepływy pracy

Uwaga

Ta funkcja jest dostępna w wersji zapoznawczej i podlega dodatkowym warunkom użytkowania wersji zapoznawczej platformy Microsoft Azure.

Rola opis
Czytelnik usługi Logic Apps Standard (wersja zapoznawcza) Masz dostęp tylko do odczytu do wszystkich zasobów w standardowej aplikacji logiki i przepływach pracy, w tym do przebiegów przepływu pracy i ich historii.
Operator usługi Logic Apps w warstwie Standardowa (wersja zapoznawcza) Masz dostęp do włączania, ponownego zapisywania i wyłączania przepływów pracy oraz tworzenia połączeń z usługami, systemami i sieciami dla standardowej aplikacji logiki. Rola Operator może wykonywać zadania administracyjne i pomocnicze na platformie Azure Logic Apps, ale nie ma uprawnień do edytowania przepływów pracy ani ustawień.
Deweloper usługi Logic Apps Standard (wersja zapoznawcza) Masz dostęp do tworzenia i edytowania przepływów pracy, połączeń i ustawień aplikacji logiki w warstwie Standardowa. Rola dewelopera nie ma uprawnień do wprowadzania zmian poza zakresem przepływów pracy, na przykład zmiany w całej aplikacji, takie jak konfigurowanie integracji sieci wirtualnej. Plany usługi App Service nie są obsługiwane.
Współautor usługi Logic Apps Standard (wersja zapoznawcza) Masz dostęp do zarządzania wszystkimi aspektami standardowej aplikacji logiki, ale nie możesz zmienić dostępu ani własności.

Dostęp do danych historii uruchamiania

Podczas uruchamiania aplikacji logiki wszystkie dane są szyfrowane podczas przesyłania przy użyciu protokołu Transport Layer Security (TLS) i magazynowanych. Po zakończeniu działania aplikacji logiki można wyświetlić historię tego przebiegu, w tym kroki, które uruchomiono wraz ze stanem, czasem trwania, danymi wejściowymi i danymi wyjściowymi dla każdej akcji. Ten bogaty szczegół zawiera szczegółowe informacje na temat sposobu uruchamiania aplikacji logiki i rozpoczęcia rozwiązywania wszelkich pojawiających się problemów.

Podczas wyświetlania historii uruchamiania aplikacji logiki usługa Azure Logic Apps uwierzytelnia dostęp, a następnie udostępnia linki do danych wejściowych i wyjściowych dla żądań i odpowiedzi dla każdego przebiegu. Jednak w przypadku akcji obsługujących wszelkie hasła, wpisy tajne, klucze lub inne poufne informacje chcesz uniemożliwić innym osobom wyświetlanie tych danych i uzyskiwanie do nich dostępu. Jeśli na przykład aplikacja logiki pobiera wpis tajny z usługi Azure Key Vault do użycia podczas uwierzytelniania akcji HTTP, chcesz ukryć ten wpis tajny przed wyświetleniem.

Aby kontrolować dostęp do danych wejściowych i wyjściowych w historii uruchamiania aplikacji logiki, dostępne są następujące opcje:

Ograniczanie dostępu według zakresu adresów IP

Możesz ograniczyć dostęp do danych wejściowych i wyjściowych w historii uruchamiania przepływów pracy aplikacji logiki, aby tylko żądania z określonych zakresów adresów IP mogły wyświetlać te dane.

Aby na przykład zablokować wszystkim dostęp do danych wejściowych i wyjściowych, określ zakres adresów IP, taki jak 0.0.0.0-0.0.0.0. Tylko osoba z uprawnieniami administratora może usunąć to ograniczenie, co zapewnia możliwość "just in time" dostępu do danych w przepływach pracy aplikacji logiki. Prawidłowy zakres adresów IP używa tych formatów: x.x.x/x lub x.x.x.x.x.x

Aby określić dozwolone zakresy adresów IP, wykonaj następujące kroki dla witryny Azure Portal lub szablonu usługi Azure Resource Manager:

Przepływy pracy użycia

  1. W witrynie Azure Portal otwórz przepływ pracy aplikacji logiki w projektancie.

  2. W menu aplikacji logiki w obszarze Ustawienia wybierz pozycję Ustawienia przepływu pracy.

  3. W obszarze Konfiguracja>kontroli dostępu Dozwolone adresy IP dla ruchu przychodzącego wybierz pozycję Określone zakresy adresów IP.

  4. W obszarze Zakresy adresów IP dla zawartości określ zakresy adresów IP, które mogą uzyskiwać dostęp do zawartości z danych wejściowych i wyjściowych.

Standardowe przepływy pracy

  1. W witrynie Azure Portal otwórz zasób aplikacji logiki.

  2. W menu aplikacji logiki w obszarze Ustawienia wybierz pozycję Sieć.

  3. W sekcji Ruch przychodzący wybierz pozycję Ograniczenie dostępu.

  4. Utwórz co najmniej jedną regułę, aby zezwolić lub odmówić żądań z określonych zakresów adresów IP. Możesz również użyć ustawień filtru nagłówka HTTP i ustawień przekazywania dalej.

    Aby uzyskać więcej informacji, zobacz Blokowanie przychodzących adresów IP w usłudze Azure Logic Apps (standard).

Zabezpieczanie danych w historii uruchamiania przy użyciu zaciemnienia

Wiele wyzwalaczy i akcji ma ustawienia zabezpieczania danych wejściowych, wyjściowych lub obu z historii uruchamiania aplikacji logiki. Wszystkie zarządzane łączniki i łączniki niestandardowe obsługują te opcje. Jednak następujące wbudowane operacjenie obsługują tych opcji:

Bezpieczne dane wejściowe — nieobsługiwane Bezpieczne dane wyjściowe — nieobsługiwane
Dołączanie do zmiennej tablicowej
Dołączanie do zmiennej ciągu
Zmienna dekrementacji
Dla każdego
Jeśli
Zmienna inkrementacji
Inicjowanie zmiennej
Cyklu
Zakres
Ustawianie zmiennej
Przełącznik
Zakończyć
Until		 Dołączanie do zmiennej tablicowej
Dołączanie do zmiennej ciągu
Komponować
Zmienna dekrementacji
Dla każdego
Jeśli
Zmienna inkrementacji
Inicjowanie zmiennej
Analizowanie kodu JSON
Cyklu
Odpowiedzi
Zakres
Ustawianie zmiennej
Przełącznik
Zakończyć
Do
Wait

Zagadnienia dotyczące zabezpieczania danych wejściowych i wyjściowych

Przed użyciem tych ustawień, aby ułatwić zabezpieczanie tych danych, zapoznaj się z następującymi zagadnieniami:

  • W przypadku zaciemniania danych wejściowych lub wyjściowych wyzwalacza lub akcji usługa Azure Logic Apps nie wysyła zabezpieczonych danych do usługi Azure Log Analytics. Ponadto nie można dodać śledzonych właściwości do tego wyzwalacza ani akcji na potrzeby monitorowania.

  • Interfejs API usługi Azure Logic Apps do obsługi historii przepływu pracy nie zwraca zabezpieczonych danych wyjściowych.

  • Aby zabezpieczyć dane wyjściowe z akcji, która zasłania dane wejściowe lub jawnie zaciemnia dane wyjściowe, włącz ręcznie bezpieczne dane wyjściowe w tej akcji.

  • Upewnij się, że włączysz opcję Bezpieczne dane wejściowe lub Bezpieczne dane wyjściowe w akcjach podrzędnych, w których oczekujesz, że historia uruchamiania będzie ukrywać te dane.

    Ustawienie Zabezpieczanie danych wyjściowych

    Po ręcznym włączeniu bezpiecznych danych wyjściowych w wyzwalaczu lub akcji usługa Azure Logic Apps ukrywa te dane wyjściowe w historii uruchamiania. Jeśli akcja podrzędna jawnie używa tych zabezpieczonych danych wyjściowych jako danych wejściowych, usługa Azure Logic Apps ukrywa dane wejściowe tej akcji w historii uruchamiania, ale nie włącza ustawienia Bezpieczne dane wejściowe akcji.

    Zabezpieczone dane wyjściowe jako dane wejściowe i wpływ podrzędny na większość akcji

    Akcje Redagowanie, Analizowanie kodu JSON i Odpowiedzi mają tylko ustawienie Bezpieczne dane wejściowe . Po włączeniu ustawienie powoduje również ukrycie danych wyjściowych tych akcji. Jeśli te akcje jawnie używają nadrzędnych zabezpieczonych danych wyjściowych jako danych wejściowych, usługa Azure Logic Apps ukrywa dane wejściowe i wyjściowe tych akcji, ale nie włącza ustawienia Bezpieczne dane wejściowe tych akcji. Jeśli akcja podrzędna jawnie używa ukrytych danych wyjściowych z akcji Compose, Parse JSON lub Response jako danych wejściowych, usługa Azure Logic Apps nie ukrywa danych wejściowych lub wyjściowych tej akcji podrzędnej.

    Zabezpieczone dane wyjściowe jako dane wejściowe z wpływem podrzędnym na określone akcje

    Ustawienie Zabezpieczanie danych wejściowych

    Po ręcznym włączeniu bezpiecznych danych wejściowych w wyzwalaczu lub akcji usługa Azure Logic Apps ukrywa te dane wejściowe w historii uruchamiania. Jeśli akcja podrzędna jawnie używa widocznych danych wyjściowych z tego wyzwalacza lub akcji jako danych wejściowych, usługa Azure Logic Apps ukrywa dane wejściowe tej akcji podrzędnej w historii uruchamiania, ale nie włączabezpiecznych danych wejściowych w tej akcji i nie ukrywa danych wyjściowych tej akcji.

    Zabezpieczone dane wejściowe i wpływ podrzędny na większość akcji

    Jeśli akcje Redagowanie, Analizowanie danych JSON i Odpowiedzi jawnie używają widocznych danych wyjściowych z wyzwalacza lub akcji, która ma zabezpieczone dane wejściowe, usługa Azure Logic Apps ukrywa dane wejściowe i wyjściowe tych akcji, ale nie włącza ustawienia Bezpieczne dane wejściowe tej akcji. Jeśli akcja podrzędna jawnie używa ukrytych danych wyjściowych z akcji Compose, Parse JSON lub Response jako danych wejściowych, usługa Azure Logic Apps nie ukrywa danych wejściowych lub wyjściowych tej akcji podrzędnej.

    Zabezpieczone dane wejściowe i wpływ podrzędny na określone akcje

Zabezpieczanie danych wejściowych i wyjściowych w projektancie

  1. W witrynie Azure Portal otwórz przepływ pracy aplikacji logiki w projektancie.

  2. W projektancie wybierz wyzwalacz lub akcję, w której chcesz zabezpieczyć poufne dane.

  3. W otwartym okienku informacji wybierz pozycję Ustawienia i rozwiń pozycję Zabezpieczenia.

    Zrzut ekranu przedstawiający witrynę Azure Portal, projektanta przepływu pracy i wyzwalacz lub akcję z otwartymi ustawieniami.

  4. Włącz bezpieczne dane wejściowe, bezpieczne dane wyjściowe lub obie te opcje.

    Zrzut ekranu przedstawia przepływ pracy z włączonymi ustawieniami Secure Inputs (Bezpieczne dane wejściowe) lub Secure Outputs (Bezpieczne dane wyjściowe).

    Wyzwalacz lub akcja wyświetla teraz ikonę blokady na pasku tytułu. Wszystkie tokeny reprezentujące zabezpieczone dane wyjściowe z poprzednich akcji również pokazują ikony blokady. Na przykład w kolejnej akcji po wybraniu tokenu dla zabezpieczonych danych wyjściowych z listy zawartości dynamicznej token wyświetla ikonę blokady.

    Zrzut ekranu przedstawia przepływ pracy z otwartą listą zawartości dynamicznej kolejnej akcji, a token poprzedniej akcji dla zabezpieczonych danych wyjściowych z ikoną blokady.

  5. Po uruchomieniu przepływu pracy można wyświetlić historię tego przebiegu.

    1. Wybierz pozycję Przegląd w menu aplikacji logiki Zużycie lub w menu standardowego przepływu pracy.

    2. W obszarze Historia przebiegów wybierz przebieg, który chcesz wyświetlić.

    3. W okienku Historia uruchamiania przepływu pracy wybierz akcje, które chcesz przejrzeć.

      Jeśli zdecydujesz się ukryć zarówno dane wejściowe, jak i wyjściowe, te wartości są teraz wyświetlane jako ukryte.

      Zrzut ekranu przedstawiający widok historii uruchamiania przepływu pracy w warstwie Standardowa z ukrytymi danymi wejściowymi i wyjściowymi.

Zabezpieczanie danych wejściowych i wyjściowych w widoku kodu

W podstawowej definicji wyzwalacza lub akcji dodaj lub zaktualizuj tablicę runtimeConfiguration.secureData.properties przy użyciu obu tych wartości:

  • "inputs": zabezpiecza dane wejściowe w historii uruchamiania.
  • "outputs": zabezpiecza dane wyjściowe w historii uruchamiania.
"<trigger-or-action-name>": {
   "type": "<trigger-or-action-type>",
   "inputs": {
      <trigger-or-action-inputs>
   },
   "runtimeConfiguration": {
      "secureData": {
         "properties": [
            "inputs",
            "outputs"
         ]
      }
   },
   <other-attributes>
}

Dostęp do danych wejściowych parametrów

Jeśli wdrażasz w różnych środowiskach, rozważ sparametryzowanie wartości w definicji przepływu pracy, które różnią się w zależności od tych środowisk. W ten sposób można uniknąć zakodowanych danych przy użyciu szablonu usługi Azure Resource Manager w celu wdrożenia aplikacji logiki, ochrony poufnych danych przez zdefiniowanie zabezpieczonych parametrów i przekazania tych danych jako oddzielnych danych wejściowych za pomocą parametrów szablonu przy użyciu pliku parametrów.

Jeśli na przykład uwierzytelnisz akcje HTTP za pomocą protokołu OAuth za pomocą identyfikatora Entra firmy Microsoft, możesz zdefiniować i zasłonić parametry, które akceptują identyfikator klienta i klucz tajny klienta, które są używane do uwierzytelniania. Aby zdefiniować te parametry w przepływie pracy aplikacji logiki, użyj parameters sekcji w definicji przepływu pracy aplikacji logiki i szablonu usługi Resource Manager do wdrożenia. Aby ułatwić zabezpieczanie wartości parametrów, których nie chcesz wyświetlać podczas edytowania aplikacji logiki ani wyświetlania historii uruchamiania, zdefiniuj parametry przy użyciu securestring typu lub secureobject i użyj kodowania zgodnie z potrzebami. Parametry, które mają ten typ, nie są zwracane z definicją zasobu i nie są dostępne podczas wyświetlania zasobu po wdrożeniu. Aby uzyskać dostęp do tych wartości parametrów w czasie wykonywania, użyj @parameters('<parameter-name>') wyrażenia wewnątrz definicji przepływu pracy. To wyrażenie jest oceniane tylko w czasie wykonywania i jest opisane przez język definicji przepływu pracy.

Uwaga

Jeśli używasz parametru w nagłówku lub treści żądania, ten parametr może być widoczny podczas wyświetlania historii uruchamiania przepływu pracy i wychodzącego żądania HTTP. Upewnij się, że zasady dostępu do zawartości są ustawione odpowiednio. Możesz również użyć zaciemnienia , aby ukryć dane wejściowe i wyjściowe w historii uruchamiania. Domyślnie Authorization nagłówki nie są widoczne za pośrednictwem danych wejściowych ani wyjściowych. Więc jeśli klucz tajny jest tam używany, ten wpis tajny nie jest pobierany.

Aby uzyskać więcej informacji, zapoznaj się z tymi sekcjami w tym temacie:

W przypadku automatyzowania wdrażania aplikacji logiki przy użyciu szablonów usługi Resource Manager można zdefiniować parametry szablonu zabezpieczonego, które są oceniane we wdrożeniu securestring przy użyciu typów i secureobject . Aby zdefiniować parametry szablonu, użyj sekcji najwyższego poziomu parameters szablonu, która jest oddzielona i różni się od sekcji definicji parameters przepływu pracy. Aby podać wartości parametrów szablonu, użyj oddzielnego pliku parametrów.

Jeśli na przykład używasz wpisów tajnych, możesz zdefiniować i użyć zabezpieczonych parametrów szablonu, które pobierają te wpisy tajne z usługi Azure Key Vault podczas wdrażania. Następnie możesz odwołać się do magazynu kluczy i wpisu tajnego w pliku parametrów. Aby uzyskać więcej informacji, zapoznaj się z następującymi tematami:

Bezpieczne parametry w definicjach przepływu pracy (przepływ pracy zużycie)

Aby chronić poufne informacje w definicji przepływu pracy aplikacji logiki, użyj zabezpieczonych parametrów, aby te informacje nie są widoczne po zapisaniu przepływu pracy aplikacji logiki. Załóżmy na przykład, że masz akcję HTTP wymaga podstawowego uwierzytelniania, które używa nazwy użytkownika i hasła. W definicji parameters przepływu pracy sekcja definiuje basicAuthPasswordParam parametry i basicAuthUsernameParam przy użyciu securestring typu . Następnie definicja akcji odwołuje się do tych parametrów w authentication sekcji .

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

Bezpieczne parametry w szablonach usługi Azure Resource Manager (przepływ pracy użycia)

Szablon usługi Resource Manager dla zasobu aplikacji logiki i przepływu pracy zawiera wiele parameters sekcji. Aby chronić hasła, klucze, wpisy tajne i inne poufne informacje, zdefiniuj parametry zabezpieczone na poziomie szablonu i definicji przepływu pracy przy użyciu securestring typu lub secureobject . Następnie można przechowywać te wartości w usłudze Azure Key Vault i używać pliku parametrów do odwołowania się do magazynu kluczy i wpisu tajnego. Następnie szablon pobiera te informacje we wdrożeniu. Aby uzyskać więcej informacji, zobacz Przekazywanie poufnych wartości podczas wdrażania przy użyciu usługi Azure Key Vault.

Ta lista zawiera więcej informacji na temat tych parameters sekcji:

  • Na najwyższym poziomie parameters szablonu sekcja definiuje parametry dla wartości używanych przez szablon podczas wdrażania. Na przykład te wartości mogą obejmować parametry połączenia dla określonego środowiska wdrażania. Następnie można przechowywać te wartości w osobnym pliku parametrów, co ułatwia zmianę tych wartości.

  • Wewnątrz definicji zasobu aplikacji logiki, ale poza definicją parameters przepływu pracy, sekcja określa wartości parametrów definicji przepływu pracy. W tej sekcji można przypisać te wartości przy użyciu wyrażeń szablonu odwołujących się do parametrów szablonu. Te wyrażenia są oceniane we wdrożeniu.

  • Wewnątrz definicji przepływu pracy sekcja definiuje parametry używane parameters przez przepływ pracy aplikacji logiki w czasie wykonywania. Następnie można odwoływać się do tych parametrów wewnątrz przepływu pracy aplikacji logiki przy użyciu wyrażeń definicji przepływu pracy, które są oceniane w czasie wykonywania.

Ten przykładowy szablon z wieloma zabezpieczonymi definicjami parametrów, które używają securestring typu:

Nazwa parametru opis
TemplatePasswordParam Parametr szablonu, który akceptuje hasło, które jest następnie przekazywane do parametru basicAuthPasswordParam definicji przepływu pracy
TemplateUsernameParam Parametr szablonu, który akceptuje nazwę użytkownika, która jest następnie przekazywana do parametru basicAuthUserNameParam definicji przepływu pracy
basicAuthPasswordParam Parametr definicji przepływu pracy, który akceptuje hasło do uwierzytelniania podstawowego w akcji HTTP
basicAuthUserNameParam Parametr definicji przepływu pracy, który akceptuje nazwę użytkownika na potrzeby uwierzytelniania podstawowego w akcji HTTP 
{
   "$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": {}
}

Typy uwierzytelniania dla łączników obsługujących uwierzytelnianie

W poniższej tabeli przedstawiono typy uwierzytelniania dostępne w operacjach łącznika, w których można wybrać typ uwierzytelniania:

Authentication type Aplikacje logiki i obsługiwane łączniki
Podstawowa Azure API Management, aplikacja systemu Azure Services, HTTP, HTTP + Swagger, HTTP Webhook
Certyfikat klienta Azure API Management, aplikacja systemu Azure Services, HTTP, HTTP + Swagger, HTTP Webhook
Active Directory OAuth - Użycie: Azure API Management, aplikacja systemu Azure Services, Azure Functions, HTTP, HTTP + Swagger, HTTP, HTTP webhook

- Standardowa: Azure Automation, Azure Blob Storage, Azure Event Hubs, Azure Queues, Azure Service Bus, Azure Tables, HTTP, HTTP Webhook, SQL Server
Raw Azure API Management, aplikacja systemu Azure Services, Azure Functions, HTTP, HTTP + Swagger, HTTP, HTTP Webhook
Tożsamość zarządzana Wbudowane łączniki:

- Użycie: Azure API Management, aplikacja systemu Azure Services, Azure Functions, HTTP, HTTP Webhook

- Standardowa: Azure Automation, Azure Blob Storage, Azure Event Hubs, Azure Queues, Azure Service Bus, Azure Tables, HTTP, HTTP Webhook, SQL Server

Uwaga: Obecnie większość wbudowanych łączników opartych na dostawcy usług nie obsługuje wybierania tożsamości zarządzanych przypisanych przez użytkownika do uwierzytelniania.

Łączniki zarządzane: aplikacja systemu Azure 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, Maszyna wirtualna platformy Azure, protokół HTTP z identyfikatorem Firmy Microsoft, programem SQL Server

Dostęp dla wywołań przychodzących do wyzwalaczy opartych na żądaniach

Wywołania przychodzące odbierane przez aplikację logiki za pośrednictwem wyzwalacza opartego na żądaniach, takiego jak wyzwalacz żądania lub wyzwalacz elementu webhook HTTP, obsługują szyfrowanie i są zabezpieczone przy użyciu protokołu Transport Layer Security (TLS) 1.2 co najmniej znanego jako Secure Sockets Layer (SSL). Usługa Azure Logic Apps wymusza tę wersję podczas odbierania wywołania przychodzącego do wyzwalacza żądania lub wywołania zwrotnego do wyzwalacza lub akcji elementu webhook HTTP. Jeśli wystąpią błędy uzgadniania protokołu TLS, upewnij się, że używasz protokołu TLS 1.2. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemu z protokołem TLS 1.0.

W przypadku wywołań przychodzących użyj następujących zestawów szyfrowania:

  • 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

Uwaga

W celu zapewnienia zgodności z poprzednimi wersjami usługa Azure Logic Apps obecnie obsługuje niektóre starsze zestawy szyfrowania. Nie używaj jednak starszych zestawów szyfrowania podczas tworzenia nowych aplikacji, ponieważ takie pakiety mogą nie być obsługiwane w przyszłości.

Możesz na przykład znaleźć następujące zestawy szyfrowania w przypadku inspekcji komunikatów uzgadniania protokołu TLS podczas korzystania z usługi Azure Logic Apps lub przy użyciu narzędzia zabezpieczeń pod adresem URL aplikacji logiki. Ponownie nie używaj tych starszych pakietów:

  • 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

Poniższa lista zawiera więcej sposobów ograniczania dostępu do wyzwalaczy odbierających wywołania przychodzące do aplikacji logiki, dzięki czemu tylko autoryzowani klienci mogą wywoływać aplikację logiki:

Generowanie sygnatur dostępu współdzielonego (SAS)

Każdy punkt końcowy żądania w aplikacji logiki ma sygnaturę dostępu współdzielonego (SAS) w adresie URL punktu końcowego, który ma następujący format:

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

Każdy adres URL zawiera spparametr , svi sig zapytania zgodnie z opisem w tej tabeli:

Parametr zapytania opis
sp Określa uprawnienia do używania dozwolonych metod HTTP.
sv Określa wersję sygnatury dostępu współdzielonego do użycia do generowania podpisu.
sig Określa podpis używany do uwierzytelniania dostępu do wyzwalacza. Ten podpis jest generowany przy użyciu algorytmu SHA256 z kluczem dostępu tajnego we wszystkich ścieżkach i właściwościach adresu URL. Ten klucz jest szyfrowany, przechowywany w aplikacji logiki i nigdy nie jest ujawniany ani publikowany. Aplikacja logiki autoryzuje tylko te wyzwalacze, które zawierają prawidłowy podpis utworzony za pomocą klucza tajnego.

Wywołania przychodzące do punktu końcowego żądania mogą używać tylko jednego schematu autoryzacji, sygnatury dostępu współdzielonego lub protokołu OAuth z identyfikatorem Entra firmy Microsoft. Chociaż użycie jednego schematu nie powoduje wyłączenia drugiego schematu, użycie obu schematów w tym samym czasie powoduje błąd, ponieważ usługa nie wie, który schemat należy wybrać.

Aby uzyskać więcej informacji na temat zabezpieczania dostępu za pomocą sygnatury dostępu współdzielonego, zapoznaj się z tymi sekcjami w tym temacie:

Generowanie ponowne kluczy dostępu

Aby w dowolnym momencie wygenerować nowy klucz dostępu zabezpieczeń, użyj interfejsu API REST platformy Azure lub witryny Azure Portal. Wszystkie wcześniej wygenerowane adresy URL używające starego klucza są unieważniane i nie mają już autoryzacji do wyzwalania aplikacji logiki. Adresy URL pobierane po rewitalizacji są podpisane przy użyciu nowego klucza dostępu.

  1. W witrynie Azure Portal otwórz aplikację logiki zawierającą klucz, który chcesz ponownie wygenerować.

  2. W menu zasobów aplikacji logiki w obszarze Ustawienia wybierz pozycję Klucze dostępu.

  3. Wybierz klucz, który chcesz ponownie wygenerować i zakończyć proces.

Tworzenie wygasających adresów URL wywołania zwrotnego

Jeśli udostępniasz adres URL punktu końcowego dla wyzwalacza opartego na żądaniach z innymi stronami, możesz wygenerować adresy URL wywołania zwrotnego, które używają określonych kluczy i mają daty wygaśnięcia. Dzięki temu można bezproblemowo wyrzucić klucze lub ograniczyć dostęp do wyzwalania aplikacji logiki na podstawie określonego przedziału czasu. Aby określić datę wygaśnięcia adresu URL, użyj interfejsu API REST usługi Azure Logic Apps, na przykład:

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

W treści dołącz NotAfterwłaściwość przy użyciu ciągu daty JSON. Ta właściwość zwraca adres URL wywołania zwrotnego, który jest prawidłowy tylko do NotAfter daty i godziny.

Tworzenie adresów URL przy użyciu podstawowego lub pomocniczego klucza tajnego

Podczas generowania lub wyświetlania adresów URL wywołania zwrotnego dla wyzwalacza opartego na żądaniach można określić klucz używany do podpisywania adresu URL. Aby wygenerować adres URL podpisany przez określony klucz, użyj interfejsu API REST usługi Logic Apps, na przykład:

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

W treści dołącz KeyType właściwość jako Primary lub Secondary. Ta właściwość zwraca adres URL podpisany przez określony klucz zabezpieczeń.

Włącz uwierzytelnianie otwarte identyfikatora entra firmy Microsoft (Microsoft Entra ID OAuth)

W przepływie pracy aplikacji logiki Zużycie rozpoczynającym się od wyzwalacza opartego na żądaniach można uwierzytelnić wywołania przychodzące wysyłane do punktu końcowego utworzonego przez ten wyzwalacz, włączając funkcję OAuth identyfikatora entra firmy Microsoft. Aby skonfigurować to uwierzytelnianie, zdefiniuj lub dodaj zasady autoryzacji na poziomie aplikacji logiki. W ten sposób wywołania przychodzące używają tokenów dostępu OAuth do autoryzacji.

Gdy przepływ pracy aplikacji logiki odbiera przychodzące żądanie zawierające token dostępu OAuth, usługa Azure Logic Apps porównuje oświadczenia tokenu z oświadczeniami określonymi przez poszczególne zasady autoryzacji. Jeśli istnieje dopasowanie między oświadczeniami tokenu a wszystkimi oświadczeniami w co najmniej jednej zasadach, autoryzacja powiedzie się dla żądania przychodzącego. Token może mieć więcej oświadczeń niż liczba określona przez zasady autoryzacji.

W przepływie pracy aplikacji logiki w warstwie Standardowa rozpoczynającym się od wyzwalacza żądania (ale nie wyzwalacza elementu webhook) można użyć aprowizacji usługi Azure Functions do uwierzytelniania wywołań przychodzących wysyłanych do punktu końcowego utworzonego przez ten wyzwalacz przy użyciu tożsamości zarządzanej. Ta aprowizacja jest również nazywana "Easy Auth". Aby uzyskać więcej informacji, zobacz Wyzwalanie przepływów pracy w aplikacjach logiki w warstwie Standardowa za pomocą usługi Easy Auth.

Zagadnienia przed włączeniem protokołu OAuth identyfikatora entra firmy Microsoft

  • Wywołanie przychodzące do punktu końcowego żądania może używać tylko jednego schematu autoryzacji — OAuth z identyfikatorem Entra firmy Microsoft lub sygnaturą dostępu współdzielonego (SAS). Chociaż użycie jednego schematu nie powoduje wyłączenia drugiego schematu, użycie obu schematów w tym samym czasie powoduje błąd, ponieważ usługa Azure Logic Apps nie wie, który schemat należy wybrać.

  • Usługa Azure Logic Apps obsługuje schematy autoryzacji typu elementu nośnego lub typu dowodu posiadania (tylko aplikacja logiki zużycie) dla tokenów dostępu OAuth identyfikatora OAuth firmy Microsoft. Authorization Jednak nagłówek tokenu dostępu musi określać Bearer typ lub PoP typ. Aby uzyskać więcej informacji na temat uzyskiwania i używania tokenu PoP, zobacz Uzyskiwanie tokenu weryfikacji posiadania (PoP).

  • Zasób aplikacji logiki jest ograniczony do maksymalnej liczby zasad autoryzacji. Każda zasada autoryzacji ma również maksymalną liczbę oświadczeń. Aby uzyskać więcej informacji, zobacz Limity i konfiguracja usługi Azure Logic Apps.

  • Zasady autoryzacji muszą zawierać co najmniej oświadczenie wystawcy , które ma wartość rozpoczynającą się od https://sts.windows.net/ lub https://login.microsoftonline.com/ (OAuth V2) jako identyfikator wystawcy Entra firmy Microsoft.

    Załóżmy na przykład, że zasób aplikacji logiki ma zasady autoryzacji, które wymagają dwóch typów oświadczeń, Odbiorców i Wystawca. Ta przykładowa sekcja ładunku dla zdekodowanego tokenu dostępu zawiera oba typy oświadczeń, gdzie aud jest wartością Odbiorcy i iss jest wartością wystawcy:

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

Włączanie protokołu OAuth identyfikatora Entra firmy Microsoft jako jedynej opcji wywoływania punktu końcowego żądania

  1. Skonfiguruj wyzwalacz elementu webhook żądania lub http z możliwością sprawdzania tokenu dostępu OAuth, wykonując kroki dołączania nagłówka "Authorization" w danych wyjściowych wyzwalacza żądania lub elementu webhook HTTP.

    Uwaga

    Ten krok sprawia, że Authorization nagłówek jest widoczny w historii uruchamiania przepływu pracy i w danych wyjściowych wyzwalacza.

  2. W witrynie Azure Portal otwórz przepływ pracy aplikacji logiki Zużycie w projektancie.

  3. W projektancie wybierz wyzwalacz. W otwartym okienku informacji wybierz pozycję Ustawienia.

  4. W obszarze Ogólne>warunki wyzwalacza wybierz pozycję Dodaj. W polu Warunek wyzwalacza wprowadź jedną z następujących wyrażeń na podstawie typu tokenu, którego chcesz użyć:

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

    — lub —

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

Jeśli wywołasz punkt końcowy wyzwalacza bez poprawnej autoryzacji, historia uruchamiania pokazuje wyzwalacz tak, jak Skipped bez żadnego komunikatu, że warunek wyzwalacza zakończył się niepowodzeniem.

Uzyskiwanie tokenu Dowodu posiadania (PoP)

Biblioteki biblioteki Microsoft Authentication Library (MSAL) udostępniają tokeny PoP do użycia. Jeśli przepływ pracy aplikacji logiki, który chcesz wywołać, wymaga tokenu PoP, możesz uzyskać ten token przy użyciu bibliotek BIBLIOTEK MSAL. W poniższych przykładach pokazano, jak uzyskać tokeny poP:

Aby użyć tokenu PoP z przepływem pracy aplikacji logiki Zużycie, postępuj zgodnie z następną sekcją, aby skonfigurować protokół OAuth z identyfikatorem Microsoft Entra ID.

Włączanie uwierzytelniania OAuth identyfikatora entra firmy Microsoft dla zasobu aplikacji logiki Zużycie

Wykonaj następujące kroki dla witryny Azure Portal lub szablonu usługi Azure Resource Manager:

W witrynie Azure Portal dodaj co najmniej jedną zasady autoryzacji do zasobu aplikacji logiki Zużycie:

  1. W witrynie Azure Portal otwórz aplikację logiki Zużycie w projektancie przepływu pracy.

  2. W menu zasobów aplikacji logiki w obszarze Ustawienia wybierz pozycję Autoryzacja. Po otworze okienka Autoryzacja wybierz pozycję Dodaj zasady.

    Zrzut ekranu przedstawiający witrynę Azure Portal, menu aplikacji logiki Zużycie, stronę autoryzacji i wybrany przycisk dodawania zasad.

  3. Podaj informacje o zasadach autoryzacji, określając typy oświadczeń i wartości oczekiwane przez aplikację logiki w tokenie dostępu przedstawionym przez każde wywołanie przychodzące do wyzwalacza Żądania:

    Zrzut ekranu przedstawiający witrynę Azure Portal, stronę autoryzacji aplikacji logiki zużycie oraz informacje dotyczące zasad autoryzacji.

    Właściwości Wymagania Type Opis
    Nazwa zasad Tak String Nazwa, której chcesz użyć dla zasad autoryzacji
    Typ zasad Tak String Usługa AAD dla tokenów typu elementu nośnego lub AADPOP dla tokenów typu Proof-of-Possession.
    Roszczenia Tak String Para klucz-wartość określająca typ oświadczenia i wartość wyzwalacza Żądanie przepływu pracy oczekuje w tokenie dostępu przedstawionym przez każde wywołanie przychodzące do wyzwalacza. Możesz dodać dowolne oświadczenie standardowe, wybierając pozycję Dodaj oświadczenie standardowe. Aby dodać oświadczenie specyficzne dla tokenu poP, wybierz pozycję Dodaj oświadczenie niestandardowe.

    Dostępne standardowe typy oświadczeń:

    - Emitenta
    - Publiczności
    - Temat
    - Identyfikator JWT (identyfikator tokenu internetowego JSON)

    Wymagania:

    — Co najmniej lista Oświadczenia musi zawierać oświadczenie wystawcy, które ma wartość rozpoczynającą się https://sts.windows.net/ od lub https://login.microsoftonline.com/ jako identyfikator wystawcy Entra firmy Microsoft.

    — Każde oświadczenie musi być jedną wartością ciągu, a nie tablicą wartości. Na przykład możesz mieć oświadczenie z rolą jako typem i deweloperem jako wartością. Nie można mieć oświadczenia, które ma rolę jako typ i wartości ustawione na Developer and Program Manager.

    - Wartość oświadczenia jest ograniczona do maksymalnej liczby znaków.

    Aby uzyskać więcej informacji na temat tych typów oświadczeń, zapoznaj się z tematem Oświadczenia w tokenach zabezpieczających firmy Microsoft Entra. Możesz również określić własny typ oświadczenia i wartość.

    W poniższym przykładzie przedstawiono informacje dotyczące tokenu PoP:

    Zrzut ekranu przedstawiający witrynę Azure Portal, stronę autoryzacji aplikacji logiki zużycie oraz informacje dotyczące zasad weryfikacji posiadania.

  4. Aby dodać kolejne oświadczenie, wybierz z następujących opcji:

    • Aby dodać inny typ oświadczenia, wybierz pozycję Dodaj standardowe oświadczenie, wybierz typ oświadczenia i określ wartość oświadczenia.

    • Aby dodać własne oświadczenie, wybierz pozycję Dodaj oświadczenie niestandardowe. Aby uzyskać więcej informacji, zapoznaj się ze sposobem dostarczania opcjonalnych oświadczeń do aplikacji. Oświadczenie niestandardowe jest następnie przechowywane jako część identyfikatora JWT; na przykład "tid": "72f988bf-86f1-41af-91ab-2d7cd011db47".

  5. Aby dodać kolejne zasady autoryzacji, wybierz pozycję Dodaj zasady. Powtórz poprzednie kroki, aby skonfigurować zasady.

  6. Po zakończeniu wybierz opcję Zapisz.

  7. Aby dołączyć Authorization nagłówek z tokenu dostępu w danych wyjściowych wyzwalacza opartego na żądaniach, zapoznaj się z artykułem Uwzględnij nagłówek "Autoryzacja" w danych wyjściowych wyzwalacza żądania i wyzwalacza elementu webhook HTTP.

Właściwości przepływu pracy, takie jak zasady, nie są wyświetlane w widoku kodu przepływu pracy w witrynie Azure Portal. Aby programowo uzyskać dostęp do zasad, wywołaj następujący interfejs API za pomocą usługi Azure Resource Manager: https://management.azure.com/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group-name}/providers/Microsoft.Logic/workflows/{your-workflow-name}?api-version=2016-10-01&_=1612212851820. Upewnij się, że zastąpisz wartości zastępcze identyfikatora subskrypcji platformy Azure, nazwy grupy zasobów i nazwy przepływu pracy.

Uwzględnij nagłówek "Authorization" w danych wyjściowych wyzwalacza żądania lub elementu webhook HTTP

W przypadku aplikacji logiki, które umożliwiają uwierzytelnianie OAuth z identyfikatorem Entra firmy Microsoft na potrzeby autoryzowania wywołań przychodzących w celu uzyskania dostępu do wyzwalaczy opartych na żądaniach, możesz włączyć wyzwalacz żądania lub dane wyjściowe wyzwalacza elementu webhook HTTP, aby uwzględnić Authorization nagłówek z tokenu dostępu OAuth. W podstawowej definicji JSON wyzwalacza dodaj i ustaw operationOptions właściwość na IncludeAuthorizationHeadersInOutputs. Oto przykład wyzwalacza żądania:

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

Aby uzyskać więcej informacji, zapoznaj się z następującymi tematami:

Uwidacznianie przepływu pracy aplikacji logiki za pomocą usługi Azure API Management

Aby uzyskać więcej protokołów uwierzytelniania i opcji, rozważ ujawnienie przepływu pracy aplikacji logiki jako interfejsu API przy użyciu usługi Azure API Management. Ta usługa zapewnia zaawansowane funkcje monitorowania, zabezpieczeń, zasad i dokumentacji dla dowolnego punktu końcowego. Usługa API Management może uwidocznić publiczny lub prywatny punkt końcowy dla aplikacji logiki. Aby autoryzować dostęp do tego punktu końcowego, możesz użyć protokołu OAuth z identyfikatorem Entra firmy Microsoft, certyfikatem klienta lub innymi standardami zabezpieczeń. Gdy usługa API Management odbiera żądanie, usługa wysyła żądanie do aplikacji logiki i wykonuje wszelkie niezbędne przekształcenia lub ograniczenia po drodze. Aby umożliwić tylko usłudze API Management wywołanie przepływu pracy aplikacji logiki, możesz ograniczyć przychodzące adresy IP aplikacji logiki.

Więcej informacji można znaleźć w następującej dokumentacji:

Ograniczanie przychodzących adresów IP

Oprócz sygnatury dostępu współdzielonego (SAS) warto ograniczyć klientów, którzy mogą wywoływać przepływ pracy aplikacji logiki. Jeśli na przykład zarządzasz punktem końcowym żądania przy użyciu usługi Azure API Management, możesz ograniczyć przepływ pracy aplikacji logiki do akceptowania żądań tylko z adresu IP dla utworzonego wystąpienia usługi API Management.

Bez względu na określone adresy IP można nadal uruchamiać przepływ pracy aplikacji logiki z wyzwalaczem opartym na żądaniach przy użyciu interfejsu API REST usługi Logic Apps: Wyzwalacze przepływu pracy — uruchamianie żądania lub przy użyciu usługi API Management. Jednak ten scenariusz nadal wymaga uwierzytelniania względem interfejsu API REST platformy Azure. Wszystkie zdarzenia są wyświetlane w dzienniku inspekcji platformy Azure. Upewnij się, że odpowiednio ustawiono zasady kontroli dostępu.

Aby ograniczyć przychodzące adresy IP dla przepływu pracy aplikacji logiki, wykonaj odpowiednie kroki dla witryny Azure Portal lub szablonu usługi Azure Resource Manager. Prawidłowy zakres adresów IP używa tych formatów: x.x.x/x lub x.x.x.x.x.x

W witrynie Azure Portal ograniczenie adresu IP dotyczy zarówno wyzwalaczy , jak i akcji, w przeciwieństwie do opisu w portalu w obszarze Dozwolone adresy IP dla ruchu przychodzącego. Aby skonfigurować ten filtr oddzielnie dla wyzwalaczy i akcji, użyj accessControl obiektu w szablonie usługi Azure Resource Manager dla zasobu aplikacji logiki lub interfejsu API REST usługi Azure Logic Apps: Przepływ pracy — tworzenie lub aktualizowanie operacji.

Przepływy pracy użycia

  1. W witrynie Azure Portal otwórz aplikację logiki Zużycie w projektancie przepływu pracy.

  2. W menu aplikacji logiki w obszarze Ustawienia wybierz pozycję Ustawienia przepływu pracy.

  3. W sekcji Konfiguracja kontroli dostępu w obszarze Dozwolone adresy IP dla ruchu przychodzącego wybierz ścieżkę dla danego scenariusza:

    • Aby wywołać przepływ pracy przy użyciu wbudowanej akcji usługi Azure Logic Apps, ale tylko jako zagnieżdżonego przepływu pracy, wybierz pozycję Tylko inne aplikacje logiki. Ta opcja działa tylko wtedy, gdy używasz akcji usługi Azure Logic Apps do wywoływania zagnieżdżonego przepływu pracy.

      Ta opcja zapisuje pustą tablicę do zasobu aplikacji logiki i wymaga, aby wywołania tylko z nadrzędnych przepływów pracy korzystających z wbudowanej akcji usługi Azure Logic Apps mogły wyzwolić zagnieżdżony przepływ pracy.

    • Aby wywołać przepływ pracy przy użyciu akcji HTTP, ale tylko jako zagnieżdżony przepływ pracy, wybierz pozycję Określone zakresy adresów IP. Po wyświetleniu pola Zakresy adresów IP dla wyzwalaczy wprowadź wychodzące adresy IP nadrzędnego przepływu pracy. Prawidłowy zakres adresów IP używa tych formatów: x.x.x/x lub x.x.x.x.x.x

      Uwaga

      Jeśli używasz opcji Tylko inne aplikacje logiki i akcji HTTP w celu wywołania zagnieżdżonego przepływu pracy, wywołanie zostanie zablokowane i zostanie wyświetlony błąd "401 Brak autoryzacji".

    • W przypadku scenariuszy, w których chcesz ograniczyć wywołania przychodzące z innych adresów IP, po wyświetleniu pola Zakresy adresów IP dla wyzwalaczy określ zakresy adresów IP, które akceptuje wyzwalacz. Prawidłowy zakres adresów IP używa tych formatów: x.x.x/x lub x.x.x.x.x.x

  4. Opcjonalnie w obszarze Ogranicz wywołania w celu pobrania komunikatów wejściowych i wyjściowych z historii uruchamiania do podanych adresów IP można określić zakresy adresów IP dla wywołań przychodzących, które mogą uzyskiwać dostęp do komunikatów wejściowych i wyjściowych w historii uruchamiania.

Standardowe przepływy pracy

  1. W witrynie Azure Portal otwórz zasób aplikacji logiki.

  2. W menu aplikacji logiki w obszarze Ustawienia wybierz pozycję Sieć.

  3. W sekcji Ruch przychodzący wybierz pozycję Ograniczenie dostępu.

  4. Utwórz co najmniej jedną regułę, aby zezwolić lub odmówić żądań z określonych zakresów adresów IP. Możesz również użyć ustawień filtru nagłówka HTTP i ustawień przekazywania dalej. Prawidłowy zakres adresów IP używa tych formatów: x.x.x/x lub x.x.x.x.x.x

    Aby uzyskać więcej informacji, zobacz Blokowanie przychodzących adresów IP w usłudze Azure Logic Apps (standard).

Dostęp dla wywołań wychodzących do innych usług i systemów

Na podstawie możliwości docelowego punktu końcowego wywołania wychodzące wysyłane przez wyzwalacz HTTP lub akcję HTTP obsługują szyfrowanie i są zabezpieczone przy użyciu protokołu Transport Layer Security (TLS) 1.0, 1.1 lub 1.2, wcześniej znanego jako Secure Sockets Layer (SSL). Usługa Azure Logic Apps negocjuje z docelowym punktem końcowym za pomocą najwyższej możliwej wersji, która jest obsługiwana. Jeśli na przykład docelowy punkt końcowy obsługuje 1.2, wyzwalacz HTTP lub akcja najpierw używa wartości 1.2. W przeciwnym razie łącznik używa następnej najwyższej obsługiwanej wersji.

Ta lista zawiera informacje o certyfikatach z podpisem własnym tls/SSL:

  • W przypadku przepływów pracy aplikacji logiki zużycie w wielodostępnym środowisku usługi Azure Logic Apps operacje HTTP nie zezwalają na certyfikaty TLS/SSL z podpisem własnym. Jeśli aplikacja logiki wykonuje wywołanie HTTP na serwerze i przedstawia certyfikat z podpisem własnym TLS/SSL, wywołanie HTTP kończy się niepowodzeniem TrustFailure z powodu błędu.

  • W przypadku standardowych przepływów pracy aplikacji logiki w środowisku usługi Azure Logic Apps z jedną dzierżawą operacje HTTP obsługują certyfikaty TLS/SSL z podpisem własnym. Należy jednak wykonać kilka dodatkowych kroków dla tego typu uwierzytelniania. W przeciwnym razie wywołanie nie powiedzie się. Aby uzyskać więcej informacji, zapoznaj się z tematem Uwierzytelnianie certyfikatów TLS/SSL dla usługi Azure Logic Apps z jedną dzierżawą.

    Jeśli zamiast tego chcesz użyć certyfikatu klienta lub protokołu OAuth z identyfikatorem Entra firmy Microsoft z typem poświadczeń certyfikatu , nadal musisz wykonać kilka dodatkowych kroków dla tego typu uwierzytelniania. W przeciwnym razie wywołanie nie powiedzie się. Aby uzyskać więcej informacji, zobacz Certyfikat klienta lub OAuth z identyfikatorem Entra firmy Microsoft z typem poświadczeń "Certyfikat" dla usługi Azure Logic Apps z jedną dzierżawą.

Poniżej przedstawiono więcej sposobów zabezpieczania punktów końcowych obsługujących wywołania wysyłane z przepływów pracy aplikacji logiki:

  • Dodaj uwierzytelnianie do żądań wychodzących.

    Gdy używasz wyzwalacza HTTP lub akcji do wysyłania wywołań wychodzących, możesz dodać uwierzytelnianie do żądania wysłanego przez aplikację logiki. Możesz na przykład wybrać następujące typy uwierzytelniania:

  • Ogranicz dostęp z adresów IP przepływu pracy aplikacji logiki.

    Wszystkie wywołania punktów końcowych z przepływów pracy aplikacji logiki pochodzą z określonych wyznaczonych adresów IP opartych na regionach aplikacji logiki. Możesz dodać filtrowanie, które akceptuje żądania tylko z tych adresów IP. Aby uzyskać te adresy IP, zapoznaj się z artykułem Limity i konfiguracja usługi Azure Logic Apps.

  • Zwiększ bezpieczeństwo połączeń z systemami lokalnymi.

    Usługa Azure Logic Apps zapewnia integrację z tymi usługami, aby zapewnić bardziej bezpieczną i niezawodną komunikację lokalną.

    • Lokalna brama danych

      Wiele łączników zarządzanych w usłudze Azure Logic Apps ułatwia bezpieczne połączenia z systemami lokalnymi, takimi jak System plików, SQL, SharePoint i DB2. Brama wysyła dane ze źródeł lokalnych w zaszyfrowanych kanałach za pośrednictwem usługi Azure Service Bus. Cały ruch pochodzi z zabezpieczonego ruchu wychodzącego z agenta bramy. Dowiedz się , jak działa lokalna brama danych.

    • Połączenie za pośrednictwem usługi Azure API Management

      Usługa Azure API Management udostępnia opcje połączenia lokalnego, takie jak wirtualna sieć prywatna typu lokacja-lokacja i integracja usługi ExpressRoute z zabezpieczonym serwerem proxy i komunikacją z systemami lokalnymi. Jeśli masz interfejs API, który zapewnia dostęp do systemu lokalnego i uwidocznił ten interfejs API, tworząc wystąpienie usługi API Management, możesz wywołać ten interfejs API z przepływu pracy aplikacji logiki, wybierając odpowiednią operację usługi API Management w projektancie przepływu pracy.

      Uwaga

      Łącznik pokazuje tylko te usługi API Management, w których masz uprawnienia do wyświetlania i nawiązywania połączenia, ale nie pokazują usług API Management opartych na użyciu.

      Na podstawie typu zasobu aplikacji logiki wykonaj odpowiednie kroki:

      Przepływy pracy użycia

      1. Na podstawie tego, czy dodajesz wyzwalacz lub akcję usługi API Management, wykonaj następujące kroki:

        • Wyzwalacz:

          1. W projektancie przepływu pracy wybierz pozycję Dodaj wyzwalacz.

          2. Po otworze okienka Dodawanie wyzwalacza w polu wyszukiwania wprowadź ciąg API Management.

          3. Z listy wyników wyzwalacza wybierz pozycję Wybierz wyzwalacz usługi Azure API Management.

        • Czynność:

          1. W projektancie przepływu pracy wybierz znak plus (+), w którym chcesz dodać akcję.

          2. Po otworze okienka Dodawanie akcji w polu wyszukiwania wprowadź ciąg API Management.

          3. Z listy wyników akcji wybierz pozycję Wybierz akcję usługi Azure API Management.

        W poniższym przykładzie pokazano znajdowanie wyzwalacza usługi Azure API Management:

        Zrzut ekranu przedstawiający witrynę Azure Portal, projektanta przepływu pracy użycia i znalezienie wyzwalacza usługi API Management.

      2. Z listy wystąpienia usługi API Management wybierz wcześniej utworzone wystąpienie usługi API Management.

      3. Z listy Operacje interfejsu API wybierz operację interfejsu API do wywołania, a następnie wybierz pozycję Dodaj akcję.

      Standardowe przepływy pracy

      W przypadku przepływów pracy w warstwie Standardowa można dodawać tylko akcje usługi API Management , a nie wyzwalacze.

      1. W projektancie przepływu pracy wybierz znak plus (+), w którym chcesz dodać akcję.

      2. Po otworze okienka Dodawanie akcji w polu wyszukiwania wprowadź ciąg API Management.

      3. Z listy wyników akcji wybierz pozycję Wywołaj interfejs API usługi Azure API Management.

        Zrzut ekranu przedstawiający witrynę Azure Portal, projektanta przepływów pracy w warstwie Standardowa i akcję usługi Azure API Management.

      4. Z listy wystąpienia usługi API Management wybierz wcześniej utworzone wystąpienie usługi API Management.

      5. Z listy Operacje interfejsu API wybierz operację interfejsu API do wywołania, a następnie wybierz pozycję Utwórz nową.

        Zrzut ekranu przedstawiający witrynę Azure Portal, projektanta przepływu pracy w warstwie Standardowa i wybrany interfejs API do wywołania.

Dodawanie uwierzytelniania do wywołań wychodzących

Punkty końcowe HTTP i HTTPS obsługują różne rodzaje uwierzytelniania. W przypadku niektórych wyzwalaczy i akcji używanych do wysyłania wywołań wychodzących lub żądań do tych punktów końcowych można określić typ uwierzytelniania. W projektancie przepływu pracy wyzwalacze i akcje obsługujące wybór typu uwierzytelniania mają właściwość Uwierzytelnianie . Jednak ta właściwość może nie zawsze być wyświetlana domyślnie. W takich przypadkach na wyzwalaczu lub akcji otwórz listę Dodaj nowy parametr i wybierz pozycję Uwierzytelnianie.

Ważne

Aby chronić poufne informacje obsługiwane przez aplikację logiki, w razie potrzeby użyj zabezpieczonych parametrów i zakoduj dane. Aby uzyskać więcej informacji na temat używania parametrów i zabezpieczania ich, zobacz Dostęp do danych wejściowych parametrów.

Uwierzytelnianie podstawowe

Jeśli opcja Podstawowa jest dostępna, określ następujące wartości właściwości:

Właściwość (projektant) Właściwość (JSON) Wymagania Wartość Opis
Uwierzytelnianie type Tak Podstawowy Typ uwierzytelniania do użycia
Nazwa użytkownika username Tak <nazwa użytkownika> Nazwa użytkownika do uwierzytelniania dostępu do docelowego punktu końcowego usługi
Hasło password Tak <Hasło> Hasło do uwierzytelniania dostępu do docelowego punktu końcowego usługi

Jeśli używasz zabezpieczonych parametrów do obsługi i zabezpieczania poufnych informacji, na przykład w szablonie usługi Azure Resource Manager na potrzeby automatyzacji wdrażania, możesz użyć wyrażeń, aby uzyskać dostęp do tych wartości parametrów w czasie wykonywania. W tym przykładzie definicja akcji HTTP określa uwierzytelnianie type jako Basic i używa funkcji parameters() w celu pobrania wartości parametrów:

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

Uwierzytelnianie certyfikatu klienta

Jeśli opcja Certyfikat klienta jest dostępna, określ następujące wartości właściwości:

Właściwość (projektant) Właściwość (JSON) Wymagania Wartość Opis
Uwierzytelnianie type Tak Certyfikat klienta
lub
ClientCertificate		 Typ uwierzytelniania do użycia. Certyfikaty można zarządzać za pomocą usługi Azure API Management.

Uwaga: Łączniki niestandardowe nie obsługują uwierzytelniania opartego na certyfikatach zarówno dla wywołań przychodzących, jak i wychodzących.
Pfx pfx Tak <zakodowana-pfx-file-content> Zawartość zakodowana w formacie base64 z pliku wymiany informacji osobistych (PFX)

Aby przekonwertować plik PFX na format zakodowany w formacie base64, możesz użyć programu PowerShell 7, wykonując następujące kroki:

1. Zapisz zawartość certyfikatu w zmiennej:

$pfx_cert = [System.IO.File]::ReadAllBytes('c:\certificate.pfx')

2. Przekonwertuj zawartość certyfikatu ToBase64String() przy użyciu funkcji i zapisz tę zawartość w pliku tekstowym:

[System.Convert]::ToBase64String($pfx_cert) | Out-File 'pfx-encoded-bytes.txt'

Rozwiązywanie problemów: jeśli używasz cert mmc/PowerShell polecenia , może wystąpić następujący błąd:

Could not load the certificate private key. Please check the authentication certificate password is correct and try again.

Aby rozwiązać ten błąd, spróbuj przekonwertować plik PFX na plik PEM i ponownie, używając openssl polecenia :

openssl pkcs12 -in certificate.pfx -out certificate.pem
openssl pkcs12 -in certificate.pem -export -out certificate2.pfx

Następnie po otrzymaniu ciągu zakodowanego w formacie base64 dla nowo przekonwertowanego pliku PFX certyfikatu ciąg działa teraz w usłudze Azure Logic Apps.
Hasło password Nie. <password-for-pfx-file> Hasło do uzyskiwania dostępu do pliku PFX

Uwaga

Jeśli spróbujesz uwierzytelnić się przy użyciu certyfikatu klienta przy użyciu protokołu OpenSSL, może wystąpić następujący błąd:

BadRequest: Could not load private key

Aby rozwiązać ten problem, wykonaj następujące kroki:

  1. Odinstaluj wszystkie wystąpienia protokołu OpenSSL.
  2. Zainstaluj program OpenSSL w wersji 1.1.1t.
  3. Rezygnacja z certyfikatu przy użyciu nowej aktualizacji.
  4. Dodaj nowy certyfikat do operacji HTTP podczas korzystania z uwierzytelniania certyfikatu klienta.

Jeśli używasz zabezpieczonych parametrów do obsługi i zabezpieczania poufnych informacji, na przykład w szablonie usługi Azure Resource Manager na potrzeby automatyzacji wdrażania, możesz użyć wyrażeń, aby uzyskać dostęp do tych wartości parametrów w czasie wykonywania. W tym przykładzie definicja akcji HTTP określa uwierzytelnianie type jako ClientCertificate i używa funkcji parameters() w celu pobrania wartości parametrów:

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

Ważne

Jeśli masz zasób standardowej aplikacji logiki w usłudze Azure Logic Apps z jedną dzierżawą i chcesz użyć operacji HTTP z certyfikatem TSL/SSL, certyfikatem klienta lub uwierzytelnianiem Open Authentication (Microsoft Entra ID OAuth) z Certificate typem poświadczeń, pamiętaj, aby wykonać dodatkowe kroki instalacji dla tego typu uwierzytelniania. W przeciwnym razie wywołanie nie powiedzie się. Aby uzyskać więcej informacji, zobacz Authentication in single-tenant environment (Uwierzytelnianie w środowisku z jedną dzierżawą).

Aby uzyskać więcej informacji na temat zabezpieczania usług przy użyciu uwierzytelniania certyfikatu klienta, zapoznaj się z następującymi tematami:

Platforma tożsamości firmy Microsoft

W przypadku wyzwalaczy żądania można użyć Platforma tożsamości Microsoft do uwierzytelniania wywołań przychodzących po skonfigurowaniu zasad autoryzacji firmy Microsoft Entra dla aplikacji logiki. Dla wszystkich innych wyzwalaczy i akcji, które zapewniają typ uwierzytelniania OAuth usługi Active Directory do wybrania, określ następujące wartości właściwości:

Właściwość (projektant) Właściwość (JSON) Wymagania Wartość Opis
Uwierzytelnianie type Tak Active Directory OAuth
lub
ActiveDirectoryOAuth		 Typ uwierzytelniania do użycia. Usługa Azure Logic Apps jest obecnie zgodna z protokołem OAuth 2.0.
Organ authority Nie. <Adres URL-for-authority-token-issuer> Adres URL urzędu udostępniającego token dostępu, na przykład https://login.microsoftonline.com/ dla regionów usługi globalnej platformy Azure. W przypadku innych chmur krajowych zapoznaj się z tematem Punkty końcowe uwierzytelniania firmy Microsoft — wybieranie urzędu tożsamości.
Dzierżawca tenant Tak <identyfikator dzierżawy> Identyfikator dzierżawy dzierżawy dla dzierżawy firmy Microsoft Entra
Publiczności audience Tak <autoryzowanie zasobu> Zasób, którego chcesz użyć do autoryzacji, na przykład https://management.core.windows.net/
Client ID clientId Tak <client-ID> Identyfikator klienta aplikacji żądającej autoryzacji
Typ poświadczeń credentialType Tak Certyfikat
lub
Klucz tajny		 Typ poświadczeń używany przez klienta do żądania autoryzacji. Ta właściwość i wartość nie są wyświetlane w podstawowej definicji aplikacji logiki, ale określa właściwości wyświetlane dla wybranego typu poświadczeń.
Wpis tajny secret Tak, ale tylko dla typu poświadczeń "Wpis tajny" <klucz tajny klienta> Klucz tajny klienta do żądania autoryzacji
Pfx pfx Tak, ale tylko dla typu poświadczeń "Certyfikat" <zakodowana-pfx-file-content> Zawartość zakodowana w formacie base64 z pliku wymiany informacji osobistych (PFX)
Hasło password Tak, ale tylko dla typu poświadczeń "Certyfikat" <password-for-pfx-file> Hasło do uzyskiwania dostępu do pliku PFX

Jeśli używasz zabezpieczonych parametrów do obsługi i zabezpieczania poufnych informacji, na przykład w szablonie usługi Azure Resource Manager na potrzeby automatyzacji wdrażania, możesz użyć wyrażeń, aby uzyskać dostęp do tych wartości parametrów w czasie wykonywania. Ta przykładowa definicja akcji HTTP określa uwierzytelnianie type jako , typ poświadczeń jako ActiveDirectoryOAuthSecret, i używa funkcji parameters() w celu pobrania wartości parametrów:

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

Ważne

Jeśli masz zasób standardowej aplikacji logiki w usłudze Azure Logic Apps z jedną dzierżawą i chcesz użyć operacji HTTP z certyfikatem TSL/SSL, certyfikatem klienta lub uwierzytelnianiem Open Authentication (Microsoft Entra ID OAuth) z Certificate typem poświadczeń, pamiętaj, aby wykonać dodatkowe kroki instalacji dla tego typu uwierzytelniania. W przeciwnym razie wywołanie nie powiedzie się. Aby uzyskać więcej informacji, zobacz Authentication in single-tenant environment (Uwierzytelnianie w środowisku z jedną dzierżawą).

Nieprzetworzone uwierzytelnianie

Jeśli opcja Nieprzetworzona jest dostępna, możesz użyć tego typu uwierzytelniania, jeśli musisz użyć schematów uwierzytelniania, które nie są zgodne z protokołem OAuth 2.0. W przypadku tego typu należy ręcznie utworzyć wartość nagłówka autoryzacji, która jest wysyłana za pomocą żądania wychodzącego, i określać tę wartość nagłówka w wyzwalaczu lub akcji.

Poniższy przykład przedstawia przykładowy nagłówek żądania HTTPS, który jest zgodny z protokołem OAuth 1.0:

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"

W wyzwalaczu lub akcji obsługującej nieprzetworzone uwierzytelnianie określ następujące wartości właściwości:

Właściwość (projektant) Właściwość (JSON) Wymagania Wartość Opis
Uwierzytelnianie type Tak Nieprzetworzone Typ uwierzytelniania do użycia
Wartość value Tak <authorization-header-value> Wartość nagłówka autoryzacji do użycia na potrzeby uwierzytelniania

Jeśli używasz zabezpieczonych parametrów do obsługi i zabezpieczania poufnych informacji, na przykład w szablonie usługi Azure Resource Manager na potrzeby automatyzacji wdrażania, możesz użyć wyrażeń, aby uzyskać dostęp do tych wartości parametrów w czasie wykonywania. W tym przykładzie definicja akcji HTTP określa uwierzytelnianie type jako Raw, i używa funkcji parameters(), aby uzyskać wartości parametrów:

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

Uwierzytelnianie tożsamości zarządzanej

Jeśli opcja tożsamości zarządzanej jest dostępna w wyzwalaczu lub akcji obsługującej uwierzytelnianie tożsamości zarządzanej, aplikacja logiki może użyć tej tożsamości do uwierzytelniania dostępu do zasobów platformy Azure chronionych przez identyfikator Entra firmy Microsoft, a nie poświadczeń, wpisów tajnych lub tokenów firmy Microsoft Entra. Platforma Azure zarządza tą tożsamością i pomaga zabezpieczyć poświadczenia, ponieważ nie musisz zarządzać wpisami tajnymi ani bezpośrednio używać tokenów firmy Microsoft Entra. Dowiedz się więcej o usługach platformy Azure, które obsługują tożsamości zarządzane na potrzeby uwierzytelniania firmy Microsoft Entra.

  • Zasób aplikacji logiki Zużycie może używać tożsamości przypisanej przez system lub pojedynczej ręcznie utworzonej tożsamości przypisanej przez użytkownika.

  • Zasób standardowej aplikacji logiki obsługuje włączenie tożsamości zarządzanej przypisanej przez system i wielu tożsamości zarządzanych przypisanych przez użytkownika jednocześnie, ale nadal można wybrać tylko jedną tożsamość do użycia w dowolnym momencie.

    Uwaga

    Domyślnie tożsamość przypisana przez system jest już włączona do uwierzytelniania połączeń w czasie wykonywania. Ta tożsamość różni się od poświadczeń uwierzytelniania lub parametry połączenia używanych podczas tworzenia połączenia. Jeśli wyłączysz tę tożsamość, połączenia nie będą działać w czasie wykonywania. Aby wyświetlić to ustawienie, w menu aplikacji logiki w obszarze Ustawienia wybierz pozycję Tożsamość.

  1. Zanim aplikacja logiki będzie mogła używać tożsamości zarządzanej, wykonaj kroki opisane w artykule Uwierzytelnianie dostępu do zasobów platformy Azure przy użyciu tożsamości zarządzanych w usłudze Azure Logic Apps. Te kroki umożliwiają włączenie tożsamości zarządzanej w aplikacji logiki i skonfigurowanie dostępu tej tożsamości do docelowego zasobu platformy Azure.

  2. Zanim funkcja platformy Azure będzie mogła używać tożsamości zarządzanej, najpierw włącz uwierzytelnianie dla usługi Azure Functions.

  3. W wyzwalaczu lub akcji obsługującej używanie tożsamości zarządzanej podaj następujące informacje:

    Wbudowane wyzwalacze i akcje

    Właściwość (projektant) Właściwość (JSON) Wymagania Wartość Opis
    Uwierzytelnianie type Tak Tożsamość zarządzana
    lub
    ManagedServiceIdentity    		 Typ uwierzytelniania do użycia
    Tożsamość zarządzana identity Nie. <user-assigned-identity-ID> Tożsamość zarządzana przypisana przez użytkownika do użycia. Uwaga: nie dołączaj tej właściwości podczas korzystania z tożsamości zarządzanej przypisanej przez system.
    Publiczności audience Tak <identyfikator zasobu docelowego> Identyfikator zasobu dla zasobu docelowego, do którego chcesz uzyskać dostęp.

    Na przykład sprawia, https://storage.azure.com/ że tokeny dostępu do uwierzytelniania są prawidłowe dla wszystkich kont magazynu. Można jednak również określić adres URL usługi głównej, taki jak https://fabrikamstorageaccount.blob.core.windows.net dla określonego konta magazynu.

    Uwaga: właściwość Audience może być ukryta w niektórych wyzwalaczach lub akcjach. Aby ustawić tę właściwość jako widoczną, w wyzwalaczu lub akcji otwórz listę Dodaj nowy parametr i wybierz pozycję Odbiorcy.

    Ważne: upewnij się, że ten identyfikator zasobu docelowego dokładnie odpowiada wartości oczekiwanej przez identyfikator Entra firmy Microsoft, w tym wszelkich wymaganych ukośników końcowych. https://storage.azure.com/ Dlatego identyfikator zasobu dla wszystkich kont usługi Azure Blob Storage wymaga końcowego ukośnika. Jednak identyfikator zasobu dla określonego konta magazynu nie wymaga końcowego ukośnika. Aby znaleźć te identyfikatory zasobów, zapoznaj się z usługami platformy Azure, które obsługują identyfikator Entra firmy Microsoft.

    Jeśli używasz zabezpieczonych parametrów do obsługi i zabezpieczania poufnych informacji, na przykład w szablonie usługi Azure Resource Manager na potrzeby automatyzacji wdrażania, możesz użyć wyrażeń, aby uzyskać dostęp do tych wartości parametrów w czasie wykonywania. Na przykład ta definicja akcji HTTP określa uwierzytelnianie type jako ManagedServiceIdentity i używa funkcji parameters(), aby uzyskać wartości parametrów:

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

    Wyzwalacze i akcje zarządzanego łącznika

    Właściwość (projektant) Wymagania Wartość Opis
    Nazwa połączenia Tak <nazwa połączenia>
    Tożsamość zarządzana Tak Tożsamość zarządzana przypisana przez system
    lub
    <user-assigned-managed-identity-name>    		 Typ uwierzytelniania do użycia

Blokowanie tworzenia połączeń

Jeśli Twoja organizacja nie zezwala na łączenie się z określonymi zasobami przy użyciu łączników w usłudze Azure Logic Apps, możesz zablokować możliwość tworzenia tych połączeń dla określonych łączników w przepływach pracy aplikacji logiki przy użyciu usługi Azure Policy. Aby uzyskać więcej informacji, zobacz Blokuj połączenia utworzone przez określone łączniki w usłudze Azure Logic Apps.

Wskazówki dotyczące izolacji dla aplikacji logiki

Usługi Azure Logic Apps można używać w usłudze Azure Government, obsługując wszystkie poziomy wpływu w regionach opisanych w artykule Azure Government Impact Level 5 Isolation Guidance (Wskazówki dotyczące izolacji na poziomie 5 dla instytucji rządowych platformy Azure). Aby spełnić te wymagania, usługa Azure Logic Apps obsługuje możliwość tworzenia i uruchamiania przepływów pracy w środowisku z dedykowanymi zasobami, dzięki czemu można zmniejszyć wpływ na wydajność innych dzierżaw platformy Azure w aplikacjach logiki i uniknąć udostępniania zasobów obliczeniowych innym dzierżawcom.

Aby uzyskać więcej informacji na temat izolacji, zobacz następującą dokumentację:

Następne kroki