Planowanie wdrożenia serwera proxy aplikacji Microsoft Entra

Artykuł
02/08/2024

Serwer proxy aplikacji Firmy Microsoft Entra to bezpieczne i ekonomiczne rozwiązanie dostępu zdalnego dla aplikacji lokalnych. Zapewnia ona natychmiastową ścieżkę przejścia dla organizacji "Cloud First" w celu zarządzania dostępem do starszych aplikacji lokalnych, które nie są jeszcze w stanie korzystać z nowoczesnych protokołów. Aby uzyskać dodatkowe informacje wprowadzające, zobacz Co to jest serwer proxy aplikacji.

Serwer proxy aplikacji jest zalecany do zapewniania użytkownikom zdalnym dostępu do zasobów wewnętrznych. Serwer proxy aplikacji zastępuje potrzebę sieci VPN lub zwrotnego serwera proxy dla tych przypadków użycia dostępu zdalnego. Nie jest przeznaczona dla użytkowników, którzy znajdują się w sieci firmowej. Ci użytkownicy, którzy korzystają z serwera proxy aplikacji na potrzeby dostępu intranetowego, mogą napotkać niepożądane problemy z wydajnością.

Ten artykuł zawiera zasoby potrzebne do planowania, obsługi i zarządzania serwerem proxy aplikacji Firmy Microsoft Entra.

Planowanie implementacji

W poniższej sekcji przedstawiono szczegółowe omówienie kluczowych elementów planowania, które umożliwią wydajne wdrożenie.

Wymagania wstępne

Przed rozpoczęciem implementacji musisz spełnić następujące wymagania wstępne. Więcej informacji na temat konfigurowania środowiska, w tym wymagań wstępnych, można znaleźć w tym samouczku.

Połączenie ors: Połączenie ors to uproszczoni agenci, na których można wdrożyć:
- Sprzęt fizyczny w środowisku lokalnym
- Maszyna wirtualna hostowana w dowolnym rozwiązaniu funkcji hypervisor
- Maszyna wirtualna hostowana na platformie Azure w celu włączenia połączenia wychodzącego z usługą serwera proxy aplikacji.
Aby uzyskać bardziej szczegółowe omówienie, zobacz Omówienie łączników sieci prywatnych firmy Microsoft Entra.
- przed zainstalowaniem łączników należy włączyć maszyny Połączenie or dla protokołu TLS 1.2.
- Jeśli to możliwe, wdróż łączniki w tej samej sieci i segmencie co serwery aplikacji internetowych zaplecza. Najlepiej wdrożyć łączniki po zakończeniu odnajdywania aplikacji.
- Zalecamy, aby każda grupa łączników miała co najmniej dwa łączniki, aby zapewnić wysoką dostępność i skalę. Posiadanie trzech łączników jest optymalne w przypadku konieczności obsługi maszyny w dowolnym momencie. Przejrzyj tabelę pojemności łącznika, aby ułatwić podjęcie decyzji o typie maszyny do zainstalowania łączników. Większa maszyna tym bardziej buforuje i wykonuje łącznik.
Ustawienia dostępu do sieci: łączniki sieci prywatnej firmy Microsoft łączą się z platformą Azure za pośrednictwem protokołu HTTPS (port TCP 443) i protokołu HTTP (port TCP 80).
- Przerywanie ruchu TLS łącznika nie jest obsługiwane i uniemożliwi łącznikom ustanawianie bezpiecznego kanału przy użyciu odpowiednich punktów końcowych serwera proxy aplikacji firmy Microsoft Entra.
- Unikaj wszystkich form wbudowanej inspekcji komunikacji wychodzącej TLS między łącznikami i platformą Azure. Możliwa jest wewnętrzna inspekcja między łącznikiem i aplikacjami zaplecza, ale może obniżyć środowisko użytkownika i w związku z tym nie jest zalecana.
- Równoważenie obciążenia samych łączników nie jest również obsługiwane, a nawet konieczne.

Ważne zagadnienia przed skonfigurowaniem serwera proxy aplikacji Firmy Microsoft Entra

Aby skonfigurować i zaimplementować serwer proxy aplikacji Firmy Microsoft Entra, należy spełnić następujące podstawowe wymagania.

Dołączanie platformy Azure: przed wdrożeniem serwera proxy aplikacji tożsamości użytkowników muszą być synchronizowane z katalogu lokalnego lub tworzone bezpośrednio w dzierżawach firmy Microsoft Entra. Synchronizacja tożsamości umożliwia usłudze Microsoft Entra ID wstępne uwierzytelnianie użytkowników przed udzieleniem im dostępu do aplikacji proxy opublikowanych aplikacji oraz posiadanie niezbędnych informacji o identyfikatorze użytkownika w celu przeprowadzenia logowania jednokrotnego.
Wymagania dotyczące dostępu warunkowego: nie zalecamy używania serwera proxy aplikacji na potrzeby dostępu intranetowego, ponieważ spowoduje to dodanie opóźnienia, które wpłynie na użytkowników. Zalecamy używanie serwera proxy aplikacji z zasadami uwierzytelniania wstępnego i dostępu warunkowego na potrzeby dostępu zdalnego z Internetu. Podejściem do zapewnienia dostępu warunkowego do użytku intranetowego jest modernizacja aplikacji, dzięki czemu mogą bezpośrednio uwierzytelniać się za pomocą identyfikatora Entra firmy Microsoft. Aby uzyskać więcej informacji, zobacz Resources for migring applications to Microsoft Entra ID (Zasoby dotyczące migrowania aplikacji do identyfikatora Entra firmy Microsoft).
Limity usług: aby chronić przed nadmierną ilością zasobów przez poszczególne dzierżawy, istnieją limity ograniczania przepustowości ustawione dla aplikacji i dzierżawy. Aby zobaczyć te limity, zapoznaj się z limitami i ograniczeniami usługi Entra firmy Microsoft. Te limity ograniczania przepływności są oparte na benchmarku znacznie powyżej typowego woluminu użycia i zapewniają duży bufor dla większości wdrożeń.
Certyfikat publiczny: jeśli używasz niestandardowych nazw domen, musisz uzyskać certyfikat TLS/SSL. W zależności od wymagań organizacji uzyskanie certyfikatu może zająć trochę czasu i zalecamy rozpoczęcie procesu tak szybko, jak to możliwe. Serwer proxy aplikacji platformy Azure obsługuje standardowe, wieloznaczne lub oparte na sieci SAN certyfikaty. Aby uzyskać więcej informacji, zobacz Configure custom domains with Microsoft Entra application proxy (Konfigurowanie domen niestandardowych przy użyciu serwera proxy aplikacji firmy Microsoft Entra).
Wymagania dotyczące domeny: logowanie jednokrotne do opublikowanych aplikacji przy użyciu ograniczonego delegowania Protokołu Kerberos (KCD) wymaga, aby serwer z uruchomionym Połączenie or i serwerem z uruchomioną aplikacją zostały przyłączone do domeny i częścią tej samej domeny lub domen zaufanych. Aby uzyskać szczegółowe informacje na temat tematu, zobacz KCD for single sign-on with application proxy (Usługa KCD na potrzeby logowania jednokrotnego z serwerem proxy aplikacji). Usługa łącznika jest uruchamiana w kontekście systemu lokalnego i nie powinna być skonfigurowana do używania tożsamości niestandardowej.
Rekordy DNS dla adresów URL
- Przed użyciem domen niestandardowych na serwerze proxy aplikacji należy utworzyć rekord CNAME w publicznym systemie DNS, co umożliwia klientom rozpoznawanie niestandardowego zdefiniowanego zewnętrznego adresu URL do wstępnie zdefiniowanego adresu proxy aplikacji. Nie można utworzyć rekordu CNAME dla aplikacji korzystającej z domeny niestandardowej, uniemożliwi użytkownikom zdalnym łączenie się z aplikacją. Kroki wymagane do dodania rekordów CNAME mogą się różnić od dostawcy DNS do dostawcy, dlatego dowiedz się, jak zarządzać rekordami i zestawami rekordów DNS przy użyciu centrum administracyjnego firmy Microsoft Entra.
- Podobnie hosty łączników muszą mieć możliwość rozpoznawania wewnętrznego adresu URL publikowanych aplikacji.
Administracja istracyjne prawa i role
- Połączenie or instalacja wymaga uprawnień administratora lokalnego do serwera z systemem Windows, na którym jest instalowany. Wymaga to również minimalnej roli Administracja istratora aplikacji do uwierzytelniania i rejestrowania wystąpienia łącznika w dzierżawie usługi Microsoft Entra.
- Publikowanie aplikacji i administrowanie nimi wymagają roli Administracja istrator aplikacji. Administracja istratory aplikacji mogą zarządzać wszystkimi aplikacjami w katalogu, w tym rejestracjami, ustawieniami logowania jednokrotnego, przypisaniami użytkowników i grup oraz licencjonowaniem, ustawieniami serwera proxy aplikacji i zgodą. Nie udziela możliwości zarządzania dostępem warunkowym. Rola Administracja istrator aplikacji w chmurze ma wszystkie możliwości Administracja istratora aplikacji, z tą różnicą, że nie zezwala na zarządzanie ustawieniami serwera proxy aplikacji.
Licencjonowanie: serwer proxy aplikacji jest dostępny za pośrednictwem subskrypcji Microsoft Entra ID P1 lub P2. Aby uzyskać pełną listę opcji licencjonowania i funkcji, zapoznaj się ze stroną cennika firmy Microsoft Entra.

Odnajdywanie aplikacji

Skompiluj spis wszystkich aplikacji w zakresie, które są publikowane za pośrednictwem serwera proxy aplikacji, zbierając następujące informacje:

Typ informacji	Informacje do zebrania
Typ usługi	Na przykład: SharePoint, SAP, CRM, Niestandardowa aplikacja internetowa, interfejs API
Platforma aplikacji	Na przykład: Windows IIS, Apache on Linux, Tomcat, NGINX
Członkostwo w domenie	W pełni kwalifikowana nazwa domeny serwera sieci Web (FQDN)
Lokalizacja aplikacji	Gdzie serwer internetowy lub farma znajduje się w infrastrukturze
Dostęp wewnętrzny	Dokładny adres URL używany podczas uzyskiwania dostępu do aplikacji wewnętrznie. Jeśli farma, jakiego typu równoważenie obciążenia jest używane? Czy aplikacja pobiera zawartość ze źródeł innych niż sama. Ustal, czy aplikacja działa za pośrednictwem obiektów WebSocket.
Dostęp zewnętrzny	Rozwiązanie dostawcy, za pomocą którego aplikacja może być już uwidoczniona na zewnątrz. Adres URL, którego chcesz użyć do uzyskiwania dostępu zewnętrznego. Jeśli program SharePoint, upewnij się, że mapowania dostępu alternatywnego są skonfigurowane zgodnie z tym wskazówkami. Jeśli nie, musisz zdefiniować zewnętrzne adresy URL.
Certyfikat publiczny	W przypadku korzystania z domeny niestandardowej należy uzyskać certyfikat z odpowiednią nazwą podmiotu. jeśli certyfikat istnieje, zanotuj numer seryjny i lokalizację, z której można go uzyskać.
Authentication type	Typ uwierzytelniania obsługiwanego przez obsługę aplikacji, np. Podstawowa, Uwierzytelnianie integracji systemu Windows, oparte na formularzach, oparte na nagłówkach i oświadczenia. Jeśli aplikacja jest skonfigurowana do uruchamiania w ramach określonego konta domeny, zanotuj w pełni kwalifikowaną nazwę domeny (FQDN) konta usługi. Jeśli jest oparty na protokole SAML, identyfikator i adresy URL odpowiedzi. Jeśli jest oparty na nagłówku, rozwiązanie dostawcy i określone wymaganie dotyczące obsługi typu uwierzytelniania.
nazwa grupy Połączenie or	Nazwa logiczna grupy łączników, która zostanie wyznaczona do zapewnienia kanału i logowania jednokrotnego do tej aplikacji zaplecza.
Dostęp użytkowników/grup	Użytkownicy lub grupy użytkowników, którym udzielono dostępu zewnętrznego do aplikacji.
Wymagania dodatkowe	Należy pamiętać o wszelkich dodatkowych wymaganiach dotyczących dostępu zdalnego lub zabezpieczeń, które należy uwzględnić w publikowaniu aplikacji.

Możesz pobrać ten arkusz kalkulacyjny spisu aplikacji w celu spisu aplikacji.

Definiowanie wymagań organizacyjnych

Poniżej przedstawiono obszary, dla których należy zdefiniować wymagania biznesowe organizacji. Każdy obszar zawiera przykłady wymagań

Uzyskaj dostęp

Użytkownicy zdalni z urządzeniami przyłączonym do domeny lub urządzeniami dołączonymi do firmy Microsoft mogą bezpiecznie uzyskiwać dostęp do opublikowanych aplikacji przy użyciu bezproblemowego logowania jednokrotnego (SSO).
Użytkownicy zdalni z zatwierdzonymi urządzeniami osobistymi mogą bezpiecznie uzyskiwać dostęp do opublikowanych aplikacji, pod warunkiem, że są zarejestrowani w usłudze MFA i zarejestrowali aplikację Microsoft Authenticator na telefonie komórkowym jako metodę uwierzytelniania.

Nadzór

Administracja istratory mogą definiować i monitorować cykl życia przypisań użytkowników do aplikacji opublikowanych za pośrednictwem serwera proxy aplikacji.

Bezpieczeństwo

Tylko użytkownicy przypisani do aplikacji za pośrednictwem członkostwa w grupie lub indywidualnie mogą uzyskiwać dostęp do tych aplikacji.

Wydajność

Nie ma obniżenia wydajności aplikacji w porównaniu do uzyskiwania dostępu do aplikacji z sieci wewnętrznej.

Środowisko użytkownika

Użytkownicy wiedzą, jak uzyskiwać dostęp do swoich aplikacji przy użyciu znanych adresów URL firmy na dowolnej platformie urządzeń.

Inspekcja

Administracja istratory mogą przeprowadzać inspekcję aktywności dostępu użytkowników.

Najlepsze rozwiązania dotyczące pilotażu

Określ ilość czasu i nakładu pracy potrzebnego do pełnej prowizji pojedynczej aplikacji na potrzeby dostępu zdalnego przy użyciu logowania jednokrotnego (SSO). W tym celu należy uruchomić pilotaż, który uwzględnia wstępne odnajdywanie, publikowanie i testowanie ogólne. Użycie prostej aplikacji internetowej opartej na usługach IIS, która jest już wstępnie skonfigurowana do zintegrowanego uwierzytelniania systemu Windows (IWA), pomoże ustalić punkt odniesienia, ponieważ ta konfiguracja wymaga minimalnego nakładu pracy w celu pomyślnego pilotowania dostępu zdalnego i logowania jednokrotnego.

Poniższe elementy projektu powinny zwiększyć sukces wdrożenia pilotażowego bezpośrednio w dzierżawie produkcyjnej.

zarządzanie Połączenie orami:

Połączenie or odgrywają kluczową rolę w dostarczaniu lokalnego kanału dla aplikacji. Użycie domyślnej grupy łączników jest odpowiednie do początkowego testowania pilotażowego opublikowanych aplikacji przed ich uruchomieniem w środowisku produkcyjnym. Pomyślnie przetestowane aplikacje można następnie przenieść do grup łączników produkcyjnych.

Zarządzanie aplikacjami:

Pracownicy najprawdopodobniej zapamiętają zewnętrzny adres URL, który jest znany i odpowiedni. Unikaj publikowania aplikacji przy użyciu wstępnie zdefiniowanych msappproxy.net lub onmicrosoft.com sufiksów. Zamiast tego podaj znaną domenę zweryfikowaną na najwyższym poziomie, poprzedzoną logiczną nazwą hosta, taką jak intranet.<>customers_domain.com.
Ogranicz widoczność ikony aplikacji pilotażowej do grupy pilotażowej, ukrywając ikonę uruchamiania z portalu Azure MyApps. Gdy wszystko będzie gotowe do produkcji, możesz ograniczyć zakres aplikacji do odpowiednich docelowych odbiorców w tej samej dzierżawie przedprodukcyjnej lub przez opublikowanie aplikacji w dzierżawie produkcyjnej.

Ustawienia logowania jednokrotnego: niektóre ustawienia logowania jednokrotnego mają określone zależności, które mogą zająć trochę czasu, więc unikaj opóźnień kontroli zmian, zapewniając, że zależności są rozwiązywane przed upływem czasu. Obejmuje to dołączanie hostów łącznika domeny do przeprowadzania logowania jednokrotnego przy użyciu ograniczonego delegowania Protokołu Kerberos (KCD) i dbanie o inne czasochłonne działania.

Protokół TLS między hostem Połączenie or a aplikacją docelową: bezpieczeństwo jest najważniejsze, dlatego protokół TLS między hostem łącznika i aplikacjami docelowymi powinien być zawsze używany. Szczególnie jeśli aplikacja internetowa jest skonfigurowana do uwierzytelniania opartego na formularzach (FBA), ponieważ poświadczenia użytkownika są następnie skutecznie przesyłane w postaci zwykłego tekstu.

Zaimplementuj przyrostowo i przetestuj każdy krok. Przeprowadź podstawowe testy funkcjonalne po opublikowaniu aplikacji, aby upewnić się, że wszystkie wymagania użytkownika i firmy są spełnione, postępując zgodnie z poniższymi instrukcjami:

Przetestuj i zweryfikuj ogólny dostęp do aplikacji internetowej z wyłączonym uwierzytelnianiem wstępnym.
W przypadku pomyślnego włączenia wstępnego uwierzytelniania i przypisania użytkowników i grup. Przetestuj i zweryfikuj dostęp.
Następnie dodaj metodę logowania jednokrotnego dla aplikacji i przetestuj ją ponownie, aby zweryfikować dostęp.
Zastosuj dostęp warunkowy i zasady uwierzytelniania wieloskładnikowego zgodnie z wymaganiami. Przetestuj i zweryfikuj dostęp.

Narzędzia do rozwiązywania problemów: podczas rozwiązywania problemów zawsze rozpocznij od zweryfikowania dostępu do opublikowanej aplikacji z przeglądarki na hoście łącznika i upewnij się, że aplikacja działa zgodnie z oczekiwaniami. Prostsza konfiguracja, łatwiejsza do określenia głównej przyczyny, dlatego rozważ próbę odtworzenia problemów z minimalną konfiguracją, taką jak używanie tylko jednego łącznika i bez logowania jednokrotnego. W niektórych przypadkach narzędzia do debugowania internetowego, takie jak Fiddler firmy Telerik, mogą okazać się niezbędne do rozwiązywania problemów z dostępem lub zawartością w aplikacjach dostępnych za pośrednictwem serwera proxy. Program Fiddler może również działać jako serwer proxy, aby ułatwić śledzenie i debugowanie ruchu dla platform mobilnych, takich jak iOS i Android, oraz praktycznie wszystko, co można skonfigurować do kierowania za pośrednictwem serwera proxy. Aby uzyskać więcej informacji, zobacz przewodnik rozwiązywania problemów.

Implementowanie rozwiązania

Wdrażanie serwera proxy aplikacji

Kroki wdrażania serwera proxy aplikacji zostały omówione w tym samouczku na potrzeby dodawania aplikacji lokalnej na potrzeby dostępu zdalnego. Jeśli instalacja nie powiedzie się, wybierz pozycję Rozwiązywanie problemów z serwerem proxy aplikacji w portalu lub skorzystaj z przewodnika rozwiązywania problemów z instalacją agenta serwera proxy aplikacji Połączenie or.

Publikowanie aplikacji za pośrednictwem serwera proxy aplikacji

Aplikacje do publikowania zakładają, że spełniono wszystkie wymagania wstępne i że masz kilka łączników wyświetlanych jako zarejestrowane i aktywne na stronie serwera proxy aplikacji.

Aplikacje można również publikować przy użyciu programu PowerShell.

Poniżej przedstawiono kilka najlepszych rozwiązań, które należy zastosować podczas publikowania aplikacji:

Użyj grup Połączenie or: przypisz grupę łączników wyznaczoną do publikowania każdej odpowiedniej aplikacji. Zalecamy, aby każda grupa łączników miała co najmniej dwa łączniki, aby zapewnić wysoką dostępność i skalę. Posiadanie trzech łączników jest optymalne w przypadku konieczności obsługi maszyny w dowolnym momencie. Ponadto zobacz Omówienie grup łączników sieci prywatnej firmy Microsoft Entra, aby zobaczyć, jak można również używać grup łączników do segmentowania łączników według sieci lub lokalizacji.
Ustaw limit czasu aplikacji zaplecza: to ustawienie jest przydatne w scenariuszach, w których aplikacja może wymagać więcej niż 75 sekund na przetworzenie transakcji klienta. Na przykład gdy klient wysyła zapytanie do aplikacji internetowej, która działa jako fronton do bazy danych. Fronton wysyła to zapytanie do serwera bazy danych zaplecza i czeka na odpowiedź, ale do czasu odebrania odpowiedzi po stronie klienta konwersacji upłynął limit czasu. Ustawienie limitu czasu na wartość Long zapewnia 180 sekund na ukończenie dłuższych transakcji.
Użyj odpowiednich typów plików cookie
- Plik cookie tylko http: zapewnia dodatkowe zabezpieczenia, ponieważ serwer proxy aplikacji zawiera flagę HTTPOnly w nagłówkach odpowiedzi HTTP set-cookie. To ustawienie pomaga ograniczyć luki w zabezpieczeniach, takie jak wykonywanie skryptów między witrynami (XSS). Pozostaw wartość Nie dla klientów/agentów użytkowników, którzy wymagają dostępu do pliku cookie sesji. Na przykład klient RDP/MTSC łączący się z bramą usług pulpitu zdalnego opublikowanym za pośrednictwem serwera proxy aplikacji.
- Bezpieczny plik cookie: po ustawieniu pliku cookie z atrybutem Secure agent użytkownika (aplikacja po stronie klienta) będzie zawierać tylko plik cookie w żądaniach HTTP, jeśli żądanie jest przesyłane za pośrednictwem zabezpieczonego kanału TLS. Pomaga to ograniczyć ryzyko naruszenia bezpieczeństwa pliku cookie w kanałach zwykłego tekstu, dlatego należy je włączyć.
- Trwały plik cookie: umożliwia utrwalanie pliku cookie sesji serwera proxy aplikacji między zamknięciem przeglądarki przez pozostanie prawidłowe do momentu jego wygaśnięcia lub usunięcia. Używany w scenariuszach, w których bogata aplikacja, taka jak office, uzyskuje dostęp do dokumentu w opublikowanej aplikacji internetowej, bez ponownego monitowania użytkownika o uwierzytelnienie. Należy jednak zachować ostrożność, ponieważ trwałe pliki cookie mogą ostatecznie narażać usługę na nieautoryzowany dostęp, jeśli nie jest używany w połączeniu z innymi mechanizmami kontroli wyrównywającej. To ustawienie powinno być używane tylko w przypadku starszych aplikacji, które nie mogą udostępniać plików cookie między procesami. Lepiej zaktualizować aplikację w celu obsługi udostępniania plików cookie między procesami zamiast używania tego ustawienia.
Translacje adresów URL w nagłówkach: włącz tę opcję w scenariuszach, w których nie można skonfigurować wewnętrznego systemu DNS tak, aby był zgodny z publiczną przestrzenią nazw organizacji (np. Split DNS). Jeśli aplikacja nie wymaga oryginalnego nagłówka hosta w żądaniu klienta, pozostaw tę wartość ustawioną na Tak. Alternatywą jest użycie nazwy FQDN w wewnętrznym adresie URL do routingu rzeczywistego ruchu, a nazwa FQDN w zewnętrznym adresie URL jako nagłówek hosta. W większości przypadków ta alternatywa powinna zezwalać aplikacji na normalne działanie, gdy dostęp jest uzyskiwany zdalnie, ale użytkownicy tracą korzyści wynikające z dopasowania wewnątrz i na zewnątrz adresu URL.
Tłumaczenie adresów URL w treści aplikacji: włącz tłumaczenie linku Treść aplikacji dla aplikacji, gdy chcesz, aby linki z tej aplikacji zostały przetłumaczone w odpowiedziach z powrotem na klienta. Jeśli ta funkcja jest włączona, zapewnia najlepszą próbę tłumaczenia wszystkich linków wewnętrznych, które serwer proxy aplikacji znajdzie w odpowiedziach HTML i CSS zwracanych do klientów. Jest to przydatne w przypadku publikowania aplikacji, które zawierają zakodowane na twardo linki bezwzględne lub krótkie nazwy NetBIOS w zawartości, albo aplikacje z zawartością, która łączy się z innymi aplikacjami lokalnymi.

W scenariuszach, w których opublikowana aplikacja łączy się z innymi opublikowanymi aplikacjami, włącz tłumaczenie linków dla każdej aplikacji, aby mieć kontrolę nad środowiskiem użytkownika na poziomie poszczególnych aplikacji.

Załóżmy na przykład, że masz trzy aplikacje opublikowane za pośrednictwem serwera proxy aplikacji, które łączą się ze sobą: Korzyści, Wydatki i Podróż oraz czwarta aplikacja Opinia, która nie jest publikowana za pośrednictwem serwera proxy aplikacji.

Ilustracja 1

Po włączeniu tłumaczenia linków dla aplikacji Korzyści linki do pozycji Wydatki i Podróż są przekierowywane do zewnętrznych adresów URL dla tych aplikacji, dzięki czemu użytkownicy uzyskują dostęp do aplikacji spoza sieci firmowej. Linki z wydatków i podróży z powrotem do korzyści nie działają, ponieważ tłumaczenie linków nie zostało włączone dla tych dwóch aplikacji. Link do aplikacji Opinia nie jest przekierowywany, ponieważ nie ma zewnętrznego adresu URL, więc użytkownicy korzystający z aplikacji Korzyści nie będą mogli uzyskać dostępu do aplikacji opinii spoza sieci firmowej. Zobacz szczegółowe informacje na temat tłumaczenia linków i innych opcji przekierowania.

Uzyskiwanie dostępu do aplikacji

Istnieje kilka opcji zarządzania dostępem do opublikowanych zasobów serwera proxy aplikacji, więc wybierz najbardziej odpowiednie dla danego scenariusza i potrzeb dotyczących skalowalności. Typowe podejścia obejmują: używanie grup lokalnych, które są synchronizowane za pośrednictwem Połączenie firmy Microsoft, tworzenie grup dynamicznych w usłudze Microsoft Entra ID na podstawie atrybutów użytkownika, używanie grup samoobsługi zarządzanych przez właściciela zasobu lub kombinację wszystkich z nich. Zapoznaj się z połączonymi zasobami, aby uzyskać korzyści z każdej z nich.

Najprostszym sposobem przypisywania użytkownikom dostępu do aplikacji jest przejście do opcji Użytkownicy i grupy w okienku po lewej stronie opublikowanej aplikacji i bezpośrednie przypisywanie grup lub osób.

Ilustracja 24

Możesz również zezwolić użytkownikom na samoobsługowy dostęp do aplikacji, przypisując grupę, do której obecnie nie należą, i konfigurując opcje samoobsługi.

Ilustracja 25

Jeśli to ustawienie jest włączone, użytkownicy będą mogli logować się do portalu MyApps i żądać dostępu, a następnie automatycznie zatwierdzać je i dodawać do już dozwolonej grupy samoobsługi lub wymagać zatwierdzenia od wyznaczonego osoby zatwierdzającej.

Użytkownicy-goście mogą również być zapraszani do uzyskiwania dostępu do aplikacji wewnętrznych publikowanych za pośrednictwem serwera proxy aplikacji za pośrednictwem usługi Microsoft Entra B2B.

W przypadku aplikacji lokalnych, które są zwykle dostępne anonimowo, nie wymagają uwierzytelniania, wolisz wyłączyć opcję znajdującą się we właściwościach aplikacji.

Ilustracja 26

Pozostawienie tej opcji na wartość Nie umożliwia użytkownikom uzyskiwanie dostępu do aplikacji lokalnej za pośrednictwem serwera proxy aplikacji Microsoft Entra bez uprawnień, dlatego należy zachować ostrożność.

Po opublikowaniu aplikacji powinna być dostępna przez wpisanie zewnętrznego adresu URL w przeglądarce lub za pomocą ikony pod https://myapps.microsoft.comadresem .

Włączanie uwierzytelniania wstępnego

Sprawdź, czy aplikacja jest dostępna za pośrednictwem serwera proxy aplikacji, który uzyskuje do niej dostęp za pośrednictwem zewnętrznego adresu URL.

Przejdź do pozycji Aplikacje dla przedsiębiorstw Tożsamości>>Wszystkie aplikacje> i wybierz aplikację, którą chcesz zarządzać.
Wybierz pozycję Serwer proxy aplikacji.
W polu Wstępne uwierzytelnianie użyj listy rozwijanej, aby wybrać pozycję Microsoft Entra ID, a następnie wybierz pozycję Zapisz.

Po włączeniu wstępnego uwierzytelniania identyfikator Entra firmy Microsoft będzie najpierw kwestionować użytkowników na potrzeby uwierzytelniania, a jeśli logowanie jednokrotne jest skonfigurowane, aplikacja zaplecza sprawdzi również użytkownika przed udzieleniem dostępu do aplikacji. Zmiana trybu wstępnego uwierzytelniania z przekazywania do identyfikatora Entra firmy Microsoft również konfiguruje zewnętrzny adres URL przy użyciu protokołu HTTPS, więc każda aplikacja początkowo skonfigurowana dla protokołu HTTP będzie teraz zabezpieczona przy użyciu protokołu HTTPS.

Włączanie logowania jednokrotnego

Logowanie jednokrotne zapewnia najlepsze możliwe środowisko użytkownika i zabezpieczenia, ponieważ użytkownicy muszą logować się tylko raz podczas uzyskiwania dostępu do identyfikatora Entra firmy Microsoft. Po wstępnie uwierzytelnieniu użytkownika logowanie jednokrotne jest wykonywane przez łącznik sieci prywatnej uwierzytelniający się w aplikacji lokalnej w imieniu użytkownika. Aplikacja zaplecza przetwarza dane logowania tak, jakby była to sama użytkownik.

Wybranie opcji Przekazywanie umożliwia użytkownikom dostęp do opublikowanej aplikacji bez konieczności uwierzytelniania w usłudze Microsoft Entra ID.

Wykonywanie logowania jednokrotnego jest możliwe tylko wtedy, gdy identyfikator entra firmy Microsoft może zidentyfikować użytkownika żądającego dostępu do zasobu, więc aplikacja musi być skonfigurowana do wstępnego uwierzytelniania użytkowników przy użyciu identyfikatora Entra firmy Microsoft po dostępie do logowania jednokrotnego do działania. W przeciwnym razie opcje logowania jednokrotnego zostaną wyłączone.

Przeczytaj artykuł Logowanie jednokrotne do aplikacji w usłudze Microsoft Entra ID , aby ułatwić wybór najbardziej odpowiedniej metody logowania jednokrotnego podczas konfigurowania aplikacji.

Praca z innymi typami aplikacji

Serwer proxy aplikacji Firmy Microsoft Entra może również obsługiwać aplikacje opracowane do korzystania z biblioteki Microsoft Authentication Library (MSAL). Obsługuje ona natywne aplikacje klienckie, korzystając z identyfikatora Entra firmy Microsoft wystawionych tokenów odebranych w nagłówku żądania klienta w celu przeprowadzenia wstępnego uwierzytelniania w imieniu użytkowników.

Przeczytaj artykuł Publikowanie natywnych i mobilnych aplikacji klienckich oraz aplikacji opartych na oświadczeniach, aby dowiedzieć się więcej o dostępnych konfiguracjach serwera proxy aplikacji.

Używanie dostępu warunkowego w celu wzmocnienia zabezpieczeń

Zabezpieczenia aplikacji wymagają zaawansowanego zestawu funkcji zabezpieczeń, które mogą chronić przed złożonymi zagrożeniami i reagować na nie lokalnie i w chmurze. Użyj zasad dostępu warunkowego, aby kontrolować dostęp do aplikacji na podstawie wielu warunków, takich jak lokalizacja, ryzyko, typ urządzenia, zgodność urządzenia i inne. Przykłady zasad, które można wdrożyć, zobacz artykuł Szablony dostępu warunkowego.

Następujące możliwości mogą służyć do obsługi serwera proxy aplikacji Firmy Microsoft Entra:

Dostęp warunkowy oparty na użytkownikach i lokalizacji: zachowaj ochronę poufnych danych, ograniczając dostęp użytkowników na podstawie lokalizacji geograficznej lub adresu IP z zasadami dostępu warunkowego opartego na lokalizacji.
Dostęp warunkowy oparty na urządzeniach: upewnij się, że tylko zarejestrowane, zatwierdzone i zgodne urządzenia mogą uzyskiwać dostęp do danych firmowych przy użyciu dostępu warunkowego opartego na urządzeniach.
Dostęp warunkowy oparty na aplikacji: praca nie musi być zatrzymywana, gdy użytkownik nie znajduje się w sieci firmowej. Zabezpieczanie dostępu do chmury firmowej i aplikacji lokalnych oraz utrzymywanie kontroli przy użyciu dostępu warunkowego.
Dostęp warunkowy oparty na ryzyku: chroń dane przed złośliwymi hakerami za pomocą zasad dostępu warunkowego opartego na ryzyku, które można zastosować do wszystkich aplikacji i wszystkich użytkowników, zarówno lokalnych, jak i w chmurze.
Microsoft Entra Moje aplikacje: dzięki wdrożonej usłudze serwera proxy aplikacji i bezpiecznie opublikowanym aplikacjom możesz zaoferować użytkownikom proste centrum do odnajdywania i uzyskiwania dostępu do wszystkich aplikacji. Zwiększ produktywność dzięki możliwościom samoobsługi, takim jak możliwość żądania dostępu do nowych aplikacji i grup lub zarządzanie dostępem do tych zasobów w imieniu innych osób za pośrednictwem Moje aplikacje.

Zarządzanie implementacją

Wymagane role

Firma Microsoft opowiada się za zasadą udzielania najmniej możliwych uprawnień do wykonywania wymaganych zadań za pomocą identyfikatora Entra firmy Microsoft. Zapoznaj się z różnymi dostępnymi rolami platformy Azure i wybierz odpowiednie role, aby zaspokoić potrzeby każdej osoby. Niektóre role mogą być stosowane tymczasowo i usuwane po zakończeniu wdrażania.

Rola biznesowa	Zadania biznesowe	Role Microsoft Entra
Administrator pomocy technicznej	Zazwyczaj ograniczone do kwalifikowania użytkowników końcowych zgłaszały problemy i wykonywały ograniczone zadania, takie jak zmiana haseł użytkowników, unieważnienie tokenów odświeżania i monitorowanie kondycji usługi.	Pomoc techniczna Administracja istrator
Administrator tożsamości	Przeczytaj raporty logowania i dzienniki inspekcji firmy Microsoft, aby debugować problemy związane z serwerem proxy aplikacji.	Czytelnik zabezpieczeń
Właściciel aplikacji	Utwórz wszystkie aspekty aplikacji dla przedsiębiorstw, rejestracji aplikacji i ustawień serwera proxy aplikacji i zarządzaj nimi.	Administrator aplikacji
Administrator infrastruktury	Właściciel przerzucania certyfikatu	Administrator aplikacji

Zminimalizowanie liczby osób, które mają dostęp do bezpiecznych informacji lub zasobów, pomoże zmniejszyć prawdopodobieństwo uzyskania nieautoryzowanego dostępu przez złośliwego aktora lub nieumyślnie wpływającego na poufny zasób.

Jednak użytkownicy nadal muszą wykonywać codzienne operacje uprzywilejowane, więc wymuszanie zasad JIT (just in time) opartych na usłudze Privileged Identity Management w celu zapewnienia uprzywilejowanego dostępu na żądanie do zasobów platformy Azure i identyfikatora Entra firmy Microsoft jest naszym zalecanym podejściem do efektywnego zarządzania dostępem administracyjnym i inspekcją.

Raportowanie i monitorowanie

Identyfikator entra firmy Microsoft zapewnia dodatkowe informacje na temat użycia aplikacji i kondycji operacyjnej organizacji za pośrednictwem dzienników inspekcji i raportów. Serwer proxy aplikacji ułatwia również monitorowanie łączników z centrum administracyjnego firmy Microsoft Entra i dzienników zdarzeń systemu Windows.

Dzienniki inspekcji aplikacji

Te dzienniki zawierają szczegółowe informacje o logowaniu do aplikacji skonfigurowanych przy użyciu serwera proxy aplikacji oraz urządzenia i użytkownika, który uzyskuje dostęp do aplikacji. Dzienniki inspekcji znajdują się w centrum administracyjnym firmy Microsoft Entra i w interfejsie API inspekcji na potrzeby eksportu. Ponadto raporty użycia i szczegółowych informacji są również dostępne dla aplikacji.

monitorowanie łącznika sieci prywatnej

Łączniki i usługa zajmują się wszystkimi zadaniami wysokiej dostępności. Stan łączników można monitorować na stronie serwera proxy aplikacji w centrum administracyjnym firmy Microsoft Entra. Aby uzyskać więcej informacji na temat konserwacji łącznika, zobacz Omówienie łączników sieci prywatnych firmy Microsoft.

Dzienniki zdarzeń systemu Windows i liczniki wydajności

Połączenie ory mają zarówno dzienniki administratora, jak i sesji. Dzienniki administratora obejmują kluczowe zdarzenia i ich błędy. Dzienniki sesji obejmują wszystkie transakcje i ich szczegóły przetwarzania. Dzienniki i liczniki znajdują się w dziennikach zdarzeń systemu Windows, aby uzyskać więcej informacji, zobacz Omówienie łączników sieci prywatnej firmy Microsoft Entra. Postępuj zgodnie z tym samouczkiem, aby skonfigurować źródła danych dziennika zdarzeń w usłudze Azure Monitor.

Przewodnik rozwiązywania problemów i kroki

Dowiedz się więcej o typowych problemach i sposobach ich rozwiązywania, zapoznaj się z naszym przewodnikiem rozwiązywania problemów z komunikatami o błędach.

W poniższych artykułach opisano typowe scenariusze, których można również użyć do tworzenia przewodników rozwiązywania problemów dla organizacji pomocy technicznej.