Implementowanie mechanizmów kontroli zabezpieczeń dla aplikacji logiki

Przepływy pracy usługi Azure Logic Apps podlegają takim samym trójwarstwowym wymaganiom dotyczącym zabezpieczeń jak aplikacje Function App: kontroli tego, kto może wywołać wyzwalacz przepływu pracy, jakiej tożsamości używa przepływ pracy podczas uwierzytelniania względem łączników oraz którą ścieżką sieciową można dotrzeć do punktu końcowego wyzwalacza. Dostępne kontrolki i sposób ich konfigurowania zależą od wybranego planu hostingu usługi Logic Apps. Wybór planu jest decyzją o bezpieczeństwie, a nie tylko kosztem lub decyzją o skali.

Wybierz między planem Zużycie a planem Standardowym

Przepływy pracy Logic Apps w modelu Consumption działają we współdzielonym środowisku wielodostępnym zarządzanym przez firmę Microsoft. Standardowe przepływy pracy działają w dedykowanym środowisku dla jednego dzierżawcy. Ta różnica w architekturze ma bezpośredni wpływ na zabezpieczenia, które mają wpływ na mechanizmy kontroli, które można zastosować.

Plan Zużycie oferuje ograniczone mechanizmy kontroli sieci. Ograniczenia adresów IP dotyczące punktu końcowego wyzwalacza można skonfigurować i ograniczyć dostęp do historii uruchamiania, ale integracja sieci wirtualnej i prywatne punkty końcowe nie są obsługiwane. Jeśli przepływ pracy w warstwie Consumption ma wywoływać zasoby prywatne — serwer SQL Server bez dostępu publicznego lub konto usługi Storage ograniczone do określonych podsieci sieci wirtualnej — potrzebne są usługi pośredniczące, takie jak Azure API Management lub lokalna brama danych (on-premises data gateway), aby zniwelować lukę sieciową.

Plan standardowy obsługuje pełny zestaw mechanizmów kontroli sieci dostępnych w Azure App Service: integracja sieci wirtualnej dla wywołań łącznika wychodzącego, prywatne punkty końcowe dla żądań wyzwalacza przychodzącego i ten sam model ograniczeń dostępu używany w Azure Functions. Przepływy pracy w planie Standard działają również w izolacji od przepływów pracy innych dzierżaw.

W przypadku przepływów pracy obsługujących dane osobowe (dane osobowe), dane finansowe, tokeny uwierzytelniania lub wywołania zasobów prywatnych, plan standardowy jest odpowiednim wyborem. Ograniczenia sieciowe planu Consumption stanowią istotną lukę w zabezpieczeniach dla tych obciążeń roboczych, a nie drobną niedogodność.

Używanie tożsamości zarządzanej do uwierzytelniania łącznika

Łączniki usługi Logic Apps używają zasobów połączeń na potrzeby uwierzytelniania w usługach zewnętrznych. Domyślnie te zasoby połączeń przechowują poświadczenia — nazwę użytkownika i hasło, klucz API lub klucz tajny klienta OAuth — które są przechowywane w konfiguracji połączenia i widoczne dla każdej osoby mającej dostęp do zasobu aplikacji logiki.

Uwierzytelnianie tożsamości zarządzanej dla łączników zastępuje przechowywane poświadczenia tożsamością zarządzaną Azure. Aplikacja logiki używa przypisanej przez system lub przypisanej przez użytkownika tożsamości zarządzanej do uwierzytelniania w obsługiwanych usługach Azure za pośrednictwem łączników. Obsługiwane łączniki obejmują Azure Blob Storage, Azure Service Bus, azure SQL Server, Azure Cosmos DB i Azure Key Vault.

Aby skonfigurować tożsamość zarządzaną dla łącznika:

1. Włącz tożsamość zarządzaną w aplikacji logiki — przejdź do pozycji Tożsamość i włącz tożsamość przypisaną przez system (Włączone) lub skonfiguruj tożsamość przypisaną przez użytkownika.
2. Podczas dodawania lub edytowania akcji łącznika w projektancie przepływu pracy wybierz pozycję Tożsamość zarządzana jako typ uwierzytelniania.
3. Przypisz tożsamości zarządzanej odpowiednią rolę w zasobie docelowym, na przykład Storage Blob Data Contributor, aby uzyskać dostęp do usługi Azure Blob Storage.

Nie każdy łącznik usługi Logic Apps obsługuje uwierzytelnianie tożsamości zarządzanej. Przed zaprojektowaniem przepływu pracy wokół tego wzorca sprawdź, czy wymagane łączniki go obsługują. W przypadku łączników, które nie obsługują tożsamości zarządzanej, przechowuj poświadczenia w Azure Key Vault i odwołują się do nich z konfiguracji zasobu połączenia, zamiast wprowadzać poświadczenia bezpośrednio do połączenia.

Ograniczanie dostępu do wyzwalacza przy użyciu list dozwolonych adresów IP

Wyzwalacze punktów końcowych dla usługi Logic Apps to punkty końcowe HTTP. Można ograniczyć, które adresy IP mogą wywoływać wyzwalacz, konfigurując listy dozwolonych adresów IP, blokując wszystkie inne adresy źródłowe przed uruchomieniem przepływu pracy.

W przypadku przepływów pracy w planie Zużycie skonfiguruj ograniczenia dostępu wyzwalania w Ustawieniach przepływu pracy w sekcji Konfiguracja kontroli dostępu. Określ zakresy adresów IP dozwolone do wywołania wyzwalacza. Wszystkie inne źródłowe adresy IP są odrzucane.

W przypadku przepływów pracy planu standardowego skonfiguruj ograniczenia dostępu w Networking>Ograniczenia dostępu przy użyciu tego samego interfejsu co Azure Functions. Możesz zezwolić na określone zakresy adresów IP, bloki CIDR lub tagi usług platformy Azure.

Reguły tagów usługi są przydatne w przypadku aplikacji logiki, które obsługują tylko zdarzenia z określonych usług Azure. Na przykład ograniczenie wyzwalacza do tagu usługi AzureEventGrid oznacza, że tylko wywołania pochodzące z usługi Azure Event Grid mogą uruchamiać przepływ pracy — dowolne żądania HTTP z innych źródeł będą blokowane niezależnie od używanego adresu URL.

Konfigurowanie prywatnych punktów końcowych i integracji sieci wirtualnej dla planu standardowego

Aplikacje logiki w planie Standard obsługują ten sam model prywatnych punktów końcowych i integracji z siecią wirtualną co aplikacje funkcji w planie Elastic Premium. Te kontrolki są konfigurowane na poziomie zasobu aplikacji logiki (Standardowa) i mają zastosowanie do wszystkich przepływów pracy w tym zasobie.

Prywatny punkt końcowy aplikacji logiki w warstwie Standard przypisuje punktowi końcowemu wyzwalacza przepływu pracy prywatny adres IP w obrębie Twojej sieci wirtualnej. Osoby wywołujące zewnętrzne nie mogą uzyskać dostępu do adresu URL wyzwalacza z publicznego Internetu. Tylko zasoby w obrębie sieci wirtualnej — lub w sieciach połączonych za pośrednictwem parowania sieci albo usługi ExpressRoute — mogą wywołać przepływ pracy. Jest to prawidłowa konfiguracja przepływów pracy, które przetwarzają poufne dane i powinny być dostępne tylko z systemów wewnętrznych.

Integracja sieci wirtualnej dla wywołań wychodzących umożliwia aplikacji logiki wykonywanie wywołań łącznika do zasobów, które nie są publicznie dostępne. Po włączeniu integracji z siecią wirtualną dla aplikacji logiki Standard akcje łączników mogą uzyskiwać dostęp do serwera SQL Server bez publicznego punktu końcowego, konta usługi Storage ograniczonego do określonej podsieci lub prywatnego interfejsu API REST hostowanego wewnętrznie — są to te same możliwości komunikacji wychodzącej, które są dostępne dla aplikacji funkcji Elastic Premium.

Ochrona poufnych danych w historii uruchamiania

Usługa Logic Apps przechowuje dane wejściowe i wyjściowe każdej akcji w historii uruchamiania, która jest widoczna w portalu Azure. To domyślne zachowanie jest przydatne podczas debugowania, ale w przypadku akcji, które przetwarzają poufne dane — hasła, tokeny uwierzytelniania, dane osobowe lub poświadczenia — uwidacznia te dane każdemu, kto ma dostęp do odczytu do zasobu aplikacji logiki.

Ustawienia Bezpieczne dane wejściowe i Bezpieczne dane wyjściowe dla poszczególnych akcji zaciemniają przechowywane wartości w historii uruchamiania. Po włączeniu portal wyświetla [Redacted] zamiast rzeczywistej zawartości. Przepływ pracy nadal przetwarza dane w czasie działania — wpływa to tylko na przechowywanie tych danych w historii uruchomień.

Włącz bezpieczne dane wejściowe i wyjściowe dla dowolnej akcji, która obsługuje:

• Tokeny uwierzytelniania lub klucze interfejsu API przekazywane między krokami
• Dane osobowe pobierane z baz danych lub systemów zewnętrznych
• Poświadczenia przywołyne z połączeń Key Vault
• Pola wrażliwe w treści żądania HTTP lub odpowiedzi

Wymaganie uwierzytelniania OAuth 2.0 dla wyzwalaczy HTTP (plan standardowy)

Przepływy pracy usługi Logic Apps w planie Standard obsługują weryfikację tokenów OAuth 2.0 w wyzwalaczach HTTP za pośrednictwem usługi Microsoft Entra ID. Po skonfigurowaniu wyzwalacz wymaga prawidłowego tokenu dostępu Microsoft Entra, zanim przepływ pracy się rozpocznie — jest to ten sam model wymuszania co w przypadku usługi EasyAuth w aplikacjach funkcji.

Aby włączyć protokół OAuth 2.0 w wyzwalaczu HTTP planu standardowego, skonfiguruj zasady autoryzacji na wyzwalaczu. Dodaj zasadę autoryzacji Microsoft Entra ID określającą dozwolonych odbiorców — identyfikator aplikacji (klienta) rejestracji aplikacji — oraz wymaganego dzierżawcę. Żądania bez prawidłowego tokenu okaziciela zgodnego z zasadą są odrzucane, zanim zostanie uruchomiona jakakolwiek akcja przepływu pracy.

Ta konfiguracja jest przydatna w przypadku przepływów pracy w planie Standard udostępnianych jako punkty końcowe API, które mogą być wywoływane wyłącznie przez określone aplikacje lub tożsamości zarejestrowane w Microsoft Entra. Po połączeniu konfiguracji z ograniczeniami adresów IP lub prywatnym punktem końcowym weryfikacja tokenu OAuth 2.0 na wyzwalaczu powoduje utworzenie dwóch niezależnych barier uwierzytelniania.