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

Artykuł
10/15/2024

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:

Dostęp do operacji aplikacji logiki
Dostęp do danych wejściowych i wyjściowych historii uruchamiania
Dostęp do danych wejściowych parametrów
Typy uwierzytelniania wyzwalaczy i akcji obsługujących uwierzytelnianie
Dostęp dla wywołań przychodzących do wyzwalaczy opartych na żądaniach
Dostęp dla wywołań wychodzących do innych usług i systemów
Blokuj tworzenie połączeń dla określonych łączników
Wskazówki dotyczące izolacji dla aplikacji logiki
Punkt odniesienia zabezpieczeń platformy Azure dla usługi Azure Logic Apps

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ń, zobacz Konfiguracja połączenia w usłudze Azure Logic Apps i Zabezpieczenia połączeń i szyfrowanie.

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:

Ogranicz dostęp według zakresu adresów IP.

Ta opcja pomaga zabezpieczyć dostęp do historii uruchamiania na podstawie żądań z określonego zakresu adresów IP.
Zabezpieczanie danych w historii uruchamiania przy użyciu zaciemnienia.

W wielu wyzwalaczach i akcjach można zabezpieczyć dane wejściowe, wyjściowe lub oba te elementy w historii uruchamiania aplikacji logiki.

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 aplikacji logiki Zużycie lub Standardowa w witrynie Azure Portal lub szablonie usługi Azure Resource Manager:

Portal
Szablon usługi Resource Manager

Przepływy pracy użycia

W witrynie Azure Portal otwórz przepływ pracy aplikacji logiki Zużycie w projektancie.
W menu aplikacji logiki w obszarze Ustawienia wybierz pozycję Ustawienia przepływu pracy.
W sekcji Konfiguracja kontroli dostępu w obszarze Dozwolone adresy IP dla ruchu przychodzącego z listy opcji Wyzwalaj dostęp wybierz pozycję Określone zakresy adresów IP.
W polu 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

W witrynie Azure Portal otwórz zasób standardowej aplikacji logiki.
W menu aplikacji logiki w obszarze Ustawienia wybierz pozycję Sieć.
W sekcji Konfiguracja ruchu przychodzącego obok pozycji Dostęp do sieci publicznej wybierz pozycję Włączone bez ograniczeń dostępu.
Na stronie Ograniczenia dostępu w obszarze Dostęp do aplikacji wybierz pozycję Włączone z wybranych sieci wirtualnych i adresów IP.
W obszarze Dostęp do witryny i reguły na karcie Witryna główna dodaj co najmniej jedną regułę do opcji Zezwalaj lub Odmawiaj żą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).

Przepływy pracy użycia

W szablonie usługi ARM określ zakresy adresów IP przy użyciu accessControl sekcji z sekcją contents w definicji zasobów aplikacji logiki, na przykład:

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

Standardowe przepływy pracy

W szablonie usługi ARM określ dozwolone zakresy adresów IP dla ruchu przychodzącego w definicji zasobów aplikacji logiki przy użyciu Microsoft.Web/sites/config sekcji . W tej sekcji w obszarze propertiesdodaj sekcję ipSecurityRestrictions i użyj ipAddresssekcji , action="Deny" | "Allow", tag=Default, priorityi name="Ports" , aby zdefiniować regułę i ustawić ipAddress dozwolony zakres adresów IP w formacie x.x.x.x/x lub x.x.x.x.x.x , na przykład:

{
   "type": "Microsoft.Web/sites/config",
   "apiVersion": "2022-09-01",
   "name": "[concat(parameters('sites_My_Standard_Logic_App_name'), '/web')]",
   "location": "West US",
   "dependsOn": [
      "[resourceId('Microsoft.Web/sites', parameters('sites_My_Standard_Logic_App_name'))]"
   ],
   "tags": {
      "hidden-link: /app-insights-resource-id": "/subscriptions/{subscriptionID}/resourceGroups/Standard-RG/providers/Microsoft.Insights/components/My-Standard-Logic-App"
   },
   "properties": {
      "numberOfWorkers": 1,
      "defaultDocuments": [
         "Default.htm",
         "Default.html",
         "Default.asp",
         "index.htm",
         "index.html",
         "iisstart.htm",
         "default.aspx",
         "index.php"
      ],
      "netFrameworkVersion": "v6.0",
      "requestTracingEnabled": false,
      "remoteDebuggingEnabled": false,
      "httpLoggingEnabled": false,
      "acrUseManagedIdentityCreds": false,
      "logsDirectorySizeLimit": 35,
      "detailedErrorLoggingEnabled": false,
      "publishingUsername": "$My-Standard-Logic-App",
      "scmType": "None",
      "use32BitWorkerProcess": false,
      "webSocketsEnabled": false,
      "alwaysOn": false,
      "managedPipelineMode": "Integrated",
      "virtualApplications": [
         {
            "virtualPath": "/",
            "physicalPath": "site\\wwwroot",
            "preloadEnabled": false
         }
      ],
      "loadBalancing": "LeastRequests",
      "experiments": {
         "rampUpRules": []
      },
      "autoHealEnabled": false,
      "vnetRouteAllEnabled": false,
      "vnetPrivatePortsCount": 0,
      "publicNetworkAccess": "Enabled",
      "cors": {
         "supportCredentials": false
      },
      "localMySqlEnabled": false,
      "managedServiceIdentityId": 3065,
      "ipSecurityRestrictions": [
         {
            "ipAddress": "208.130.0.0/16",
            "action": "Deny",
            "tag": "Default",
            "priority": 100,
            "name": "Ports"
         },
         {
            "ipAddress": "Any",
            "action": "Deny",
            "priority": 2147483647,
            "name": "Deny all",
            "description": "Deny all access"
         }
      ],
      "ipSecurityRestrictionsDefaultAction": "Deny",
      "scmIpSecurityRestrictions": [
         {
            "ipAddress": "Any",
            "action": "Allow",
            "priority": 2147483647,
            "name": "Allow all",
            "description": "Allow all access"
         }
      ],
      "scmIpSecurityRestrictionsDefaultAction": "Allow",
      "scmIpSecurityRestrictionsUseMain": false,
      "http20Enabled": false,
      "minTlsVersion": "1.2",
      "scmMinTlsVersion": "1.2",
      "ftpsState": "FtpsOnly",
      "preWarmedInstanceCount": 1,
      "functionAppScaleLimit": 0,
      "functionsRuntimeScaleMonitoringEnabled": true,
      "minimumElasticInstanceCount": 1,
      "azureStorageAccounts": {}
   }
},

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 operacje nie 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 Nawrót 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 Nawrót Odpowiedź Zakres Ustawianie zmiennej Przełącznik Zakończyć Aż 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.

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.

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łącza bezpiecznych danych wejściowych w tej akcji i nie ukrywa danych wyjściowych tej 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.

Zabezpieczanie danych wejściowych i wyjściowych w projektancie

W witrynie Azure Portal otwórz przepływ pracy aplikacji logiki w projektancie.
W projektancie wybierz wyzwalacz lub akcję, w której chcesz zabezpieczyć poufne dane.
W otwartym okienku informacji wybierz pozycję Ustawienia i rozwiń pozycję Zabezpieczenia.
Włącz bezpieczne dane wejściowe, bezpieczne dane wyjściowe lub obie te opcje.

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

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:

Bezpieczne parametry w definicjach przepływu pracy
Zabezpieczanie danych w historii uruchamiania przy użyciu zaciemnienia

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:

Przekazywanie poufnych wartości podczas wdrażania przy użyciu usługi Azure Key Vault
Zabezpieczanie parametrów w szablonach usługi Azure Resource Manager w dalszej części tego tematu

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 .

Ważne

Aby uzyskać optymalne zabezpieczenia, firma Microsoft zaleca używanie identyfikatora Entra firmy Microsoft z tożsamościami zarządzanymi do uwierzytelniania, jeśli to możliwe. Ta opcja zapewnia doskonałe zabezpieczenia bez konieczności podawania poświadczeń. Platforma Azure zarządza tą tożsamością i pomaga zapewnić bezpieczeństwo informacji uwierzytelniania, aby nie trzeba było zarządzać tymi poufnymi informacjami. Aby skonfigurować tożsamość zarządzaną dla usługi Azure Logic Apps, zobacz Uwierzytelnianie dostępu i połączeń z zasobami platformy Azure przy użyciu tożsamości zarządzanych w usłudze Azure Logic Apps.

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

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.

Ważne

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:

Typ uwierzytelniania	Aplikacje logiki i obsługiwane łączniki
Podstawowa	Azure API Management, aplikacja systemu Azure Service, HTTP, HTTP + Swagger, HTTP Webhook
Certyfikat klienta	Azure API Management, aplikacja systemu Azure Service, HTTP, HTTP + Swagger, HTTP Webhook
OAuth usługi Active Directory (OAuth 2.0 z identyfikatorem Entra firmy Microsoft)	- Użycie: Azure API Management, aplikacja systemu Azure Service, Azure Functions, HTTP, HTTP + Swagger, HTTP webhook - Standardowa: Azure Automation, Azure Blob Storage, Azure Event Hubs, Azure Queues, Azure Service Bus, Azure Tables, HTTP, HTTP Webhook, SQL Server
Surowy	Azure API Management, aplikacja systemu Azure Service, Azure Functions, HTTP, HTTP + Swagger, HTTP, HTTP webhook
Tożsamość zarządzana	Wbudowane łączniki: - Użycie: Azure API Management, aplikacja systemu Azure Service, 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

Ważne

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.

Uwaga

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

Ważne

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 w usłudze 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 sposoby ograniczania dostępu do wyzwalaczy odbierających wywołania przychodzące do przepływu pracy aplikacji logiki, dzięki czemu tylko autoryzowani klienci mogą wywoływać przepływ pracy:

Włączanie uwierzytelniania OAuth przy użyciu identyfikatora entra firmy Microsoft
Generowanie kluczy lub tokenów sygnatury dostępu współdzielonego
Wyłączanie uwierzytelniania sygnatury dostępu współdzielonego (SAS)
Ograniczanie przychodzących adresów IP
Uwidacznianie aplikacji logiki za pomocą usługi Azure API Management

Włączanie protokołu OAuth 2.0 przy użyciu identyfikatora Entra firmy Microsoft

W przepływie pracy Zużycie rozpoczynającym się od wyzwalacza opartego na żądaniach można uwierzytelnić i autoryzować wywołania przychodzące wysyłane do punktu końcowego utworzonego przez ten wyzwalacz, włączając protokół OAuth 2.0 za pomocą identyfikatora Entra firmy Microsoft. Aby skonfigurować to uwierzytelnianie, zdefiniuj lub dodaj zasady autoryzacji na poziomie zasobu 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 standardowym przepływie pracy rozpoczynającym się od wyzwalacza żądania (ale nie wyzwalacza elementu webhook) możesz użyć aprowizacji usługi Azure Functions do uwierzytelniania wywołań przychodzących wysyłanych do punktu końcowego utworzonego przez wyzwalacz żądania 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 2.0 przy użyciu identyfikatora Entra firmy Microsoft

Aby uzyskać optymalne zabezpieczenia, firma Microsoft zaleca używanie identyfikatora Entra firmy Microsoft z tożsamościami zarządzanymi do uwierzytelniania, jeśli to możliwe. Ta opcja zapewnia doskonałe zabezpieczenia bez konieczności podawania poświadczeń. Platforma Azure zarządza tą tożsamością i pomaga zapewnić bezpieczeństwo informacji uwierzytelniania, aby nie trzeba było zarządzać tymi poufnymi informacjami. Aby skonfigurować tożsamość zarządzaną dla usługi Azure Logic Apps, zobacz Uwierzytelnianie dostępu i połączeń z zasobami platformy Azure przy użyciu tożsamości zarządzanych w usłudze Azure Logic Apps.
W przepływach pracy Zużycie wywołania przychodzące do adresu URL punktu końcowego dla wyzwalacza opartego na żądaniach mogą używać tylko jednego schematu autoryzacji( OAuth 2.0 z identyfikatorem Entra firmy Microsoft lub sygnaturą dostępu współdzielonego (SAS). Chociaż użycie jednego schematu nie powoduje wyłączenia drugiego schematu, jeśli używasz obu schematów w tym samym czasie, usługa Azure Logic Apps generuje błąd, ponieważ usługa nie wie, który schemat należy wybrać. Jeśli przepływ pracy Zużycie rozpoczyna się od wyzwalacza Żądanie, możesz wyłączyć uwierzytelnianie SAS, a także ograniczyć autoryzację do używania tylko protokołu OAuth 2.0 z identyfikatorem Entra firmy Microsoft. W przypadku przepływów pracy w warstwie Standardowa można używać innych typów uwierzytelniania bez wyłączania sygnatury dostępu współdzielonego.
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 Zużycie 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 wystawca identyfikatora 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": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
    "unique_name": "SophiaOwen@fabrikam.com",
    "upn": "SophiaOwen@fabrikam.com",
    "uti": "TPJ7nNNMMZkOSx6_uVczUAA",
    "ver": "1.0"
}

Włącz protokół OAuth 2.0 z identyfikatorem Entra firmy Microsoft jako jedyną opcją wywoływania punktu końcowego żądania (tylko zużycie)

W przypadku punktów końcowych opartych na żądaniach można ograniczyć autoryzację do używania tylko protokołu OAuth 2.0 z identyfikatorem Entra firmy Microsoft. Ta opcja działa nawet w przypadku wyłączenia uwierzytelniania sygnatury dostępu współdzielonego (SAS).

W przypadku przepływu pracy Zużycie skonfiguruj wyzwalacz żądania lub wyzwalacz elementu webhook HTTP z możliwością sprawdzania tokenu dostępu OAuth, wykonując kroki uwzględnienia 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.
W witrynie Azure Portal otwórz przepływ pracy Zużycie w projektancie.
W projektancie wybierz wyzwalacz. W otwartym okienku informacji wybierz pozycję Ustawienia.
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 Zużycie, 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, wykonaj kroki konfigurowania protokołu OAuth przy użyciu identyfikatora Entra firmy Microsoft.

Włączanie uwierzytelniania OAuth przy użyciu identyfikatora Entra firmy Microsoft dla zasobu aplikacji logiki Zużycie

Aby dodać zasady autoryzacji do aplikacji logiki Zużycie, wykonaj kroki dla witryny Azure Portal lub szablonu usługi Azure Resource Manager:

Portal
Szablon usługi Resource Manager

W witrynie Azure Portal otwórz aplikację logiki Zużycie i przepływ pracy w projektancie.
W menu aplikacji logiki w obszarze Ustawienia wybierz pozycję Autoryzacja.
Na stronie Autoryzacja wybierz pozycję Dodaj zasady.

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 :

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 - Audiencja - 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:

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": "aaaabbbb-0000-cccc-1111-dddd2222eeee".
Aby dodać kolejne zasady autoryzacji, wybierz pozycję Dodaj zasady. Powtórz poprzednie kroki, aby skonfigurować zasady.
Po zakończeniu wybierz opcję Zapisz.
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.

W szablonie usługi ARM zdefiniuj zasady autoryzacji, wykonując poniższe kroki i składnię:

properties W sekcji definicji zasobu aplikacji logiki dodaj accessControl obiekt, jeśli nie istnieje, który zawiera triggers obiekt.

Aby uzyskać więcej informacji na temat obiektu, zapoznaj się z tematem Ograniczanie zakresów adresów IP dla ruchu przychodzącego accessControl w szablonie usługi Azure Resource Manager i dokumentacji szablonu przepływów pracy usługi Microsoft.Logic.
triggers W obiekcie dodaj openAuthenticationPolicies obiekt zawierający obiekt, policies w którym definiujesz co najmniej jedną zasady autoryzacji.
Podaj nazwę zasad autoryzacji, ustaw typ zasad na AAD, i dołącz tablicę claims , w której określisz jeden lub więcej typów oświadczeń.

Co najmniej tablica claims musi zawierać typ oświadczenia wystawcy, w którym ustawiono właściwość oświadczenia name na wartość i ustawić iss wartość na początek https://sts.windows.net/ value lub https://login.microsoftonline.com/ jako identyfikator wystawcy Entra firmy Microsoft. Aby uzyskać więcej informacji na temat tych typów oświadczeń, zobacz Oświadczenia w usłudze Microsoft Entra tokenów zabezpieczających. Możesz również określić własny typ oświadczenia i wartość.
Aby dołączyć Authorization nagłówek z tokenu dostępu w danych wyjściowych wyzwalacza opartego na żądaniach, zobacz Dołączanie nagłówka "Autoryzacja" w danych wyjściowych wyzwalacza żądania.

Oto składnia, która ma być następująca:

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

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:

Generowanie klucza lub tokenu sygnatury dostępu współdzielonego

Gdy przepływ pracy rozpoczyna się od wyzwalacza opartego na żądaniach i zapisujesz ten przepływ pracy po raz pierwszy, usługa Azure Logic Apps tworzy wywoływany punkt końcowy w tym wyzwalaczu. Ten punkt końcowy ma adres URL, który może odbierać wywołania przychodzące lub żądania uruchamiania przepływu pracy. Adres URL zawiera sygnaturę dostępu współdzielonego (SAS), która jest kluczem lub tokenem, który przyznaje uprawnienia, na przykład usługom magazynu. Ten adres URL punktu końcowego używa następującego formatu:

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

Aby na przykład wyświetlić ten adres URL w wyzwalaczu żądania, znajdź właściwość ADRESU URL HTTP wyzwalacza:

Zrzut ekranu przedstawiający witrynę Azure Portal, projektant przepływu pracy użycia i adres URL punktu końcowego wyzwalacza żądania.

Pełny adres URL wygląda następująco:

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

Sygnatura dostępu współdzielonego w adresie URL zawiera parametry zapytania, które opisano w poniższej 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 przechowywany w tajemnicy i 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.

Ważne

Upewnij się, że klucz sygnatury dostępu współdzielonego jest chroniony tak samo jak klucz konta przed nieautoryzowanym użyciem. Skonfiguruj lub masz plan odwołwania naruszonego klucza dostępu. Użyj uznania podczas dystrybucji identyfikatorów URI korzystających z kluczy dostępu i dystrybuowania tylko takich identyfikatorów URI za pośrednictwem bezpiecznego połączenia, takiego jak HTTPS. Pamiętaj, aby wykonywać tylko operacje używające klucza dostępu za pośrednictwem połączenia HTTPS. Każdy, kto ma identyfikator URI z prawidłowym kluczem, może uzyskać dostęp do skojarzonego zasobu. Aby zachować bezpieczeństwo i chronić dostęp do przepływu pracy aplikacji logiki, ponownie wygeneruj klucze dostępu zgodnie z harmonogramem, ponieważ mogą one wymagać zachowania zgodności z zasadami zabezpieczeń lub naruszenia zabezpieczeń. Dzięki temu możesz upewnić się, że tylko autoryzowane żądania mogą wyzwalać przepływ pracy, co chroni dane i procesy przed nieautoryzowanym dostępem.

Jeśli używasz klucza sygnatury dostępu współdzielonego do uzyskiwania dostępu do usług magazynu, firma Microsoft zaleca utworzenie sygnatury dostępu współdzielonego delegowania użytkownika, która jest zabezpieczona za pomocą identyfikatora Entra firmy Microsoft, a nie klucza konta.

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

Jeśli masz przepływ pracy Zużycie rozpoczynający się od wyzwalacza Żądania , możesz wyłączyć uwierzytelnianie SAS. Ta opcja działa, nawet jeśli ograniczasz autoryzację do używania tylko protokołu OAuth 2.0 z identyfikatorem Entra firmy Microsoft. W przypadku przepływów pracy w warstwie Standardowa można używać innych typów uwierzytelniania bez wyłączania sygnatury dostępu współdzielonego.

Aby uzyskać więcej informacji na temat zabezpieczeń podczas korzystania z klucza sygnatury dostępu współdzielonego, zobacz następujące sekcje w tym przewodniku:

Ponowne generowanie kluczy dostępu
Tworzenie wygasających adresów URL wywołania zwrotnego
Tworzenie adresów URL przy użyciu klucza podstawowego lub pomocniczego

Wyłączanie uwierzytelniania sygnatury dostępu współdzielonego (tylko użycie)

Domyślnie wyzwalacz oparty na żądaniach ma włączone uwierzytelnianie SAS. Adres URL punktu końcowego wyzwalacza zawiera sygnaturę dostępu współdzielonego rozpoczynającą się od parametrów zapytania , sp-<permissions>sv-<SAS-version>sig=<signature>na przykład:

Jeśli przepływ pracy Zużycie rozpoczyna się od wyzwalacza Żądania i chcesz użyć protokołu OAuth z identyfikatorem Entra firmy Microsoft, możesz wyłączyć uwierzytelnianie SYGNATURy dostępu współdzielonego, aby uniknąć błędów i problemów z uruchamianiem przepływu pracy. Należy również dodać warstwę zabezpieczeń, usuwając zależność od wpisów tajnych, co zmniejsza ryzyko zarejestrowania lub wycieku wpisów tajnych.

Ta opcja działa, nawet jeśli włączysz również protokół OAuth 2.0 z identyfikatorem Entra firmy Microsoft jako jedyną opcją wywoływania punktu końcowego opartego na żądaniach. W przypadku przepływów pracy w warstwie Standardowa można używać innych typów uwierzytelniania bez wyłączania sygnatury dostępu współdzielonego.

Uwaga

Ta akcja wyłącza uwierzytelnianie sygnatury dostępu współdzielonego dla żądań przychodzących i blokuje działanie istniejących kluczy sas lub podpisów. Jednak klucze sas lub podpisy pozostają prawidłowe i nadal działają, jeśli ponownie włączysz uwierzytelnianie sas. Aby wyłączyć klucze sas i podpisy, tworząc nowe wersje, zobacz Ponowne generowanie kluczy dostępu.

Po wyłączeniu uwierzytelniania sygnatury dostępu współdzielonego adres URL punktu końcowego wyzwalacza żądania nie zawiera już klucza sygnatury dostępu współdzielonego, na przykład:

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

Wymagania wstępne

W tym zadaniu potrzebne jest narzędzie do wysyłania wywołań interfejsu API REST, na przykład:

Uwaga

W przypadku scenariuszy, w których masz poufne dane, takie jak poświadczenia, wpisy tajne, tokeny dostępu, klucze interfejsu API i inne podobne informacje, upewnij się, że używasz narzędzia chroniącego dane przy użyciu niezbędnych funkcji zabezpieczeń, działa w trybie offline lub lokalnie, nie synchronizuje danych z chmurą i nie wymaga zalogowania się do konta online. Dzięki temu można zmniejszyć ryzyko ujawnienia poufnych danych publicznie.

Sprawdzanie wyzwalaczy z włączoną lub wyłączoną sygnaturą dostępu współdzielonego

Po wyłączeniu uwierzytelniania sygnatury dostępu współdzielonego adres URL punktu końcowego wyzwalacza nie zawiera już klucza sygnatury dostępu współdzielonego. Ponadto definicja przepływu pracy Zużycie zawiera obiekt sasAuthenticationPolicy JSON. Ten obiekt ma właściwość stanu ustawioną na wartość Wyłączone, na przykład:

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

Aby znaleźć przepływy pracy Zużycie, w których sygnatura dostępu współdzielonego jest włączona lub wyłączona, sprawdź, czy definicja przepływu pracy zawiera obiekt sasAuthenticationPolicy , w którym właściwość stanu jest ustawiona na Wyłączone.

Za pomocą narzędzia, które wysyła wywołania interfejsu API REST, uzyskaj informacje o przepływie pracy, uruchamiając przepływy pracy — pobierz operację przy użyciu następującego żądania GET , na przykład:

GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Pobierz dane wyjściowe z przepływów pracy — pobierz operację i sprawdź, czy obiekt sasAuthenticationPolicy istnieje, gdzie właściwość stanu jest ustawiona na wartość Wyłączone.

Dodawanie właściwości sasAuthenticationPolicy do definicji przepływu pracy

W przypadku przepływów pracy Zużycie, w których chcesz wyłączyć uwierzytelnianie SAS, wykonaj następujące kroki:

Jeśli jeszcze tego nie zrobiono, uzyskaj informacje o przepływie pracy, uruchamiając przepływy pracy — Pobierz operację przy użyciu następującego żądania GET , na przykład:

GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Pobierz dane wyjściowe z przepływów pracy — Pobierz operację i ręcznie dodaj następujące elementy:
1. properties W obiekcie dodaj accessControl obiekt zawierający triggers obiekt, jeśli żaden z nich nie istnieje.
2. triggers W obiekcie dodaj sasAuthenticationPolicy obiekt zawierający właściwość ustawioną state na Disabled.
Po zakończeniu edytowana część wygląda jak w poniższym przykładzie:
```
"properties": {
    "accessControl": {
        "triggers": {
            "sasAuthenticationPolicy": {
                "state": "Disabled"
            }
        }
    }
}
```
Wyślij kolejne żądanie, aby zaktualizować przepływ pracy przy użyciu edytowanych danych wyjściowych, które są używane jako dane wejściowe w treści żądania, uruchamiając operację Przepływy pracy — aktualizowanie przy użyciu następującego żądania PATCH, na przykład:

PATCH https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
W witrynie Azure Portal przejdź do przepływu pracy Zużycie w projektancie i upewnij się, że adres URL wyzwalacza żądania nie zawiera już sygnatury dostępu współdzielonego.
Aby włączyć protokół Oauth 2.0 z identyfikatorem Entra firmy Microsoft, na poziomie zasobu aplikacji logiki dodaj zasady autoryzacji dla protokołu OAuth z identyfikatorem Entra firmy Microsoft.

Aby uzyskać więcej informacji, zobacz Enable OAuth 2.0 with Microsoft Entra ID (Włączanie protokołu OAuth 2.0 przy użyciu identyfikatora Entra firmy Microsoft).

Generowanie ponowne kluczy dostępu

Aby zachować bezpieczeństwo i chronić dostęp do przepływu pracy aplikacji logiki, ponownie wygeneruj klucze dostępu zgodnie z harmonogramem, ponieważ mogą one wymagać zachowania zgodności z zasadami zabezpieczeń lub naruszenia zabezpieczeń. Dzięki temu możesz upewnić się, że tylko autoryzowane żądania mogą wyzwalać przepływ pracy, co chroni dane i procesy przed nieautoryzowanym dostępem.

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

W witrynie Azure Portal otwórz zasób aplikacji logiki, który używa klucza, który chcesz ponownie wygenerować.
W menu zasobów aplikacji logiki w obszarze Ustawienia wybierz pozycję Klucze dostępu.
Wybierz klucz, który chcesz ponownie wygenerować i zakończyć proces.

Ważne

Upewnij się, że klucz dostępu jest chroniony tak samo jak klucz konta przed nieautoryzowanym użyciem. Skonfiguruj lub masz plan odwołwania naruszonego klucza dostępu. Użyj uznania podczas dystrybucji identyfikatorów URI korzystających z kluczy dostępu i dystrybuowania tylko takich identyfikatorów URI za pośrednictwem bezpiecznego połączenia, takiego jak HTTPS. Pamiętaj, aby wykonywać tylko operacje używające klucza dostępu za pośrednictwem połączenia HTTPS. Każdy, kto ma identyfikator URI z prawidłowym kluczem, może uzyskać dostęp do skojarzonego zasobu.

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/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01

W treści dołącz NotAfter wł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 Azure Logic Apps, na przykład:

POST /subscriptions/{subscription-ID}/resourceGroups/{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ń.

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.

Niezależnie od adresów IP, które określisz, nadal można uruchomić przepływ pracy aplikacji logiki, który ma wyzwalacz oparty na żądaniach przy użyciu wyzwalaczy przepływu pracy — uruchom żądanie operacji 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

Portal
Szablon usługi Resource Manager

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 operacji Przepływ pracy — tworzenie lub aktualizowanie w interfejsie API REST usługi Azure Logic Apps.

Przepływy pracy użycia

W witrynie Azure Portal otwórz aplikację logiki Zużycie w projektancie przepływu pracy.
W menu aplikacji logiki w obszarze Ustawienia wybierz pozycję Ustawienia przepływu pracy.
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
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

W witrynie Azure Portal otwórz zasób standardowej aplikacji logiki.
W menu aplikacji logiki w obszarze Ustawienia wybierz pozycję Sieć.
W sekcji Konfiguracja ruchu przychodzącego obok pozycji Dostęp do sieci publicznej wybierz pozycję Włączone bez ograniczeń dostępu.
Na stronie Ograniczenia dostępu w obszarze Dostęp do aplikacji wybierz pozycję Włączone z wybranych sieci wirtualnych i adresów IP.
W obszarze Dostęp do witryny i reguły na karcie Witryna główna dodaj co najmniej jedną regułę do opcji Zezwalaj lub Odmawiaj żądań z określonych zakresów adresów IP. 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).

Przepływy pracy użycia

W szablonie usługi ARM określ dozwolone zakresy adresów IP dla ruchu przychodzącego w definicji zasobów aplikacji logiki przy użyciu accessControl sekcji . W tej sekcji użyj triggersodpowiednich sekcji , actionsi opcjonalnychcontents, uwzględniając allowedCallerIpAddresses sekcję z właściwością addressRange i ustaw wartość właściwości na dozwolony zakres adresów IP w formacie x.x.x.x/x lub x.x.x.x.x.

Jeśli zagnieżdżony przepływ pracy aplikacji logiki używa opcji Tylko inne aplikacje logiki, która zezwala na wywołania przychodzące tylko z innych przepływów pracy aplikacji logiki korzystających z wbudowanej akcji usługi Azure Logic Apps, ustaw allowedCallerIpAddresses właściwość na pustą tablicę ([]) i pomiń addressRange właściwość.
Jeśli zagnieżdżony przepływ pracy aplikacji logiki używa opcji Określone zakresy adresów IP dla innych wywołań przychodzących, takich jak inne przepływy pracy aplikacji logiki używające akcji HTTP, dołącz allowedCallerIpAddresses sekcję i ustaw addressRange właściwość na dozwolony zakres adresów IP.

W tym przykładzie przedstawiono definicję zasobu aplikacji logiki dla zagnieżdżonego przepływu pracy, który zezwala na wywołania przychodzące tylko z innych przepływów pracy aplikacji logiki korzystających z wbudowanej akcji usługi Azure Logic Apps:

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

W tym przykładzie przedstawiono definicję zasobu aplikacji logiki dla zagnieżdżonego przepływu pracy, który zezwala na wywołania przychodzące z przepływów pracy aplikacji logiki korzystających z akcji HTTP:

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

Standardowe przepływy pracy

{
   "type": "Microsoft.Web/sites/config",
   "apiVersion": "2022-09-01",
   "name": "[concat(parameters('sites_My_Standard_Logic_App_name'), '/web')]",
   "location": "West US",
   "dependsOn": [
      "[resourceId('Microsoft.Web/sites', parameters('sites_My_Standard_Logic_App_name'))]"
   ],
   "tags": {
      "hidden-link: /app-insights-resource-id": "/subscriptions/{subscriptionID}/resourceGroups/Standard-RG/providers/Microsoft.Insights/components/My-Standard-Logic-App"
   },
   "properties": {
      "numberOfWorkers": 1,
      "defaultDocuments": [
         "Default.htm",
         "Default.html",
         "Default.asp",
         "index.htm",
         "index.html",
         "iisstart.htm",
         "default.aspx",
         "index.php"
      ],
      "netFrameworkVersion": "v6.0",
      "requestTracingEnabled": false,
      "remoteDebuggingEnabled": false,
      "httpLoggingEnabled": false,
      "acrUseManagedIdentityCreds": false,
      "logsDirectorySizeLimit": 35,
      "detailedErrorLoggingEnabled": false,
      "publishingUsername": "$My-Standard-Logic-App",
      "scmType": "None",
      "use32BitWorkerProcess": false,
      "webSocketsEnabled": false,
      "alwaysOn": false,
      "managedPipelineMode": "Integrated",
      "virtualApplications": [
         {
            "virtualPath": "/",
            "physicalPath": "site\\wwwroot",
            "preloadEnabled": false
         }
      ],
      "loadBalancing": "LeastRequests",
      "experiments": {
         "rampUpRules": []
      },
      "autoHealEnabled": false,
      "vnetRouteAllEnabled": false,
      "vnetPrivatePortsCount": 0,
      "publicNetworkAccess": "Enabled",
      "cors": {
         "supportCredentials": false
      },
      "localMySqlEnabled": false,
      "managedServiceIdentityId": 3065,
      "ipSecurityRestrictions": [
         {
            "ipAddress": "208.130.0.0/16",
            "action": "Deny",
            "tag": "Default",
            "priority": 100,
            "name": "Ports"
         },
         {
            "ipAddress": "Any",
            "action": "Deny",
            "priority": 2147483647,
            "name": "Deny all",
            "description": "Deny all access"
         }
      ],
      "ipSecurityRestrictionsDefaultAction": "Deny",
      "scmIpSecurityRestrictions": [
         {
            "ipAddress": "Any",
            "action": "Allow",
            "priority": 2147483647,
            "name": "Allow all",
            "description": "Allow all access"
         }
      ],
      "scmIpSecurityRestrictionsDefaultAction": "Allow",
      "scmIpSecurityRestrictionsUseMain": false,
      "http20Enabled": false,
      "minTlsVersion": "1.2",
      "scmMinTlsVersion": "1.2",
      "ftpsState": "FtpsOnly",
      "preWarmedInstanceCount": 1,
      "functionAppScaleLimit": 0,
      "functionsRuntimeScaleMonitoringEnabled": true,
      "minimumElasticInstanceCount": 1,
      "azureStorageAccounts": {}
   }
},

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.
- Nawiązywanie połączenia 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:
  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.
  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ą.

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ę Zaawansowane parametry i wybierz pozycję Uwierzytelnianie.

Ważne

Aby chronić poufne informacje obsługiwane przez przepływ pracy aplikacji 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

W przypadku wywołań HTTP uwierzytelnianie podstawowe używa ciągu zakodowanego w formacie base64, który zawiera nazwę użytkownika i hasło, aby wysłać żądanie. Ta metoda przesyła poświadczenia bez szyfrowania i stwarza zwiększone ryzyko bezpieczeństwa, chyba że ta opcja jest używana z protokołem HTTPS/SSL.

Ważne

Jeśli opcja Podstawowa jest dostępna i wybrana, 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 certyfikatów klientów

Uwierzytelnianie certyfikatu klienta zezwala lub wymaga od użytkowników uwierzytelniania bezpośrednio przy użyciu certyfikatów X.509 względem identyfikatora Entra firmy Microsoft dla aplikacji i logowania przeglądarki. Ta funkcja ułatwia wdrażanie uwierzytelniania odpornego na wyłudzanie informacji i uwierzytelniania za pomocą certyfikatu X.509 względem infrastruktury kluczy publicznych (PKI).

Ważne

Jeśli opcja Certyfikat klienta jest dostępna i wybrana, 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:

Odinstaluj wszystkie wystąpienia protokołu OpenSSL.
Zainstaluj program OpenSSL w wersji 1.1.1t.
Rezygnacja z certyfikatu przy użyciu nowej aktualizacji.
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 Microsoft Entra

W wyzwalaczu Żądanie możesz użyć platformy Microsoft Entra do uwierzytelniania połączeń przychodzących po skonfigurowaniu zasad autoryzacji firmy Microsoft Entra dla aplikacji logiki.

Ważne

We wszystkich innych wyzwalaczach i akcjach obsługujących uwierzytelnianie OAuth usługi Active Directory (OAuth 2.0 z identyfikatorem Entra firmy Microsoft) 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	OAuth usługi Active Directory (OAuth 2.0 z identyfikatorem Entra firmy Microsoft) lub `ActiveDirectoryOAuth`	Typ uwierzytelniania do użycia. Usługa Azure Logic Apps jest obecnie zgodna z protokołem OAuth 2.0.
Autorytet	`authority`	Nie.	<Adres URL-for-authority-token-issuer>	Adres URL urzędu, który udostępnia klucz 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
Audiencja	`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 aplikacji logiki w warstwie Standardowa w usłudze Azure Logic Apps z jedną dzierżawą i chcesz użyć operacji HTTP z certyfikatem TSL/SSL, certyfikatem klienta lub protokołem OAuth identyfikatora Entra firmy Microsoft z Certificate typem poświadczeń, pamiętaj o wykonaniu dodatkowych kroków konfiguracji 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.

Ważne

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

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.
Zanim funkcja platformy Azure będzie mogła używać tożsamości zarządzanej, najpierw włącz uwierzytelnianie dla usługi Azure Functions.

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.
Audiencja	`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ę Parametry zaawansowane 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.
Standardowe przepływy pracy aplikacji logiki mogą prywatnie i bezpiecznie komunikować się z siecią wirtualną platformy Azure za pośrednictwem prywatnych punktów końcowych skonfigurowanych na potrzeby ruchu przychodzącego i integracji sieci wirtualnej dla ruchu wychodzącego. Aby uzyskać więcej informacji, zobacz Zabezpieczanie ruchu między sieciami wirtualnymi i usługą Azure Logic Apps z jedną dzierżawą przy użyciu prywatnych punktów końcowych.
Aby uruchomić własny kod lub wykonać transformację XML, utwórz i wywołaj funkcję platformy Azure, a nie użyj wbudowanej funkcji kodu lub zapewnij zestawy do użycia odpowiednio jako mapy. Ponadto skonfiguruj środowisko hostingu dla aplikacji funkcji, aby spełnić wymagania dotyczące izolacji.

Aby na przykład spełnić wymagania dotyczące poziomu Impact Level 5, utwórz aplikację funkcji z planem usługi App Service przy użyciu warstwy cenowej Izolowana wraz ze środowiskiem App Service Environment (ASE), który również korzysta z warstwy cenowej Izolowana. W tym środowisku aplikacje funkcji działają na dedykowanych maszynach wirtualnych platformy Azure i dedykowanych sieciach wirtualnych platformy Azure, które zapewniają izolację sieci na podstawie izolacji obliczeniowej dla aplikacji i maksymalnych możliwości skalowania w poziomie.

Aby uzyskać więcej informacji, zapoznaj się z następującą dokumentacją:

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

Udostępnij za pośrednictwem

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

Dostęp do operacji aplikacji logiki

Przepływy pracy użycia

Standardowe przepływy pracy

Dostęp do danych historii uruchamiania

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

Przepływy pracy użycia

Standardowe przepływy pracy

Zabezpieczanie danych w historii uruchamiania przy użyciu zaciemnienia

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

Zabezpieczanie danych wejściowych i wyjściowych w projektancie

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

Dostęp do danych wejściowych parametrów

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

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

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

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

Włączanie protokołu OAuth 2.0 przy użyciu identyfikatora Entra firmy Microsoft

Zagadnienia przed włączeniem protokołu OAuth 2.0 przy użyciu identyfikatora Entra firmy Microsoft

Włącz protokół OAuth 2.0 z identyfikatorem Entra firmy Microsoft jako jedyną opcją wywoływania punktu końcowego żądania (tylko zużycie)

Uzyskiwanie tokenu Dowodu posiadania (PoP)

Włączanie uwierzytelniania OAuth przy użyciu identyfikatora Entra firmy Microsoft dla zasobu aplikacji logiki Zużycie

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

Generowanie klucza lub tokenu sygnatury dostępu współdzielonego

Wyłączanie uwierzytelniania sygnatury dostępu współdzielonego (tylko użycie)

Wymagania wstępne

Sprawdzanie wyzwalaczy z włączoną lub wyłączoną sygnaturą dostępu współdzielonego

Dodawanie właściwości sasAuthenticationPolicy do definicji przepływu pracy

Generowanie ponowne kluczy dostępu

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

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

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

Ograniczanie przychodzących adresów IP

Przepływy pracy użycia

Standardowe przepływy pracy

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

Dodawanie uwierzytelniania do wywołań wychodzących

Uwierzytelnianie podstawowe

Uwierzytelnianie certyfikatów klientów

Platforma Microsoft Entra

Nieprzetworzone uwierzytelnianie

Uwierzytelnianie tożsamości zarządzanej

Blokowanie tworzenia połączeń

Wskazówki dotyczące izolacji dla aplikacji logiki

Powiązana zawartość

Opinia

Dodatkowe zasoby