Naplánování nasazení proxy aplikací služby Azure AD

Azure Active Directory (Azure AD) proxy aplikací je bezpečné a nákladově efektivní řešení vzdáleného přístupu pro místní aplikace. Poskytuje okamžitou cestu přechodu pro organizace "Cloud First" pro správu přístupu ke starším místním aplikacím, které ještě nejsou schopné používat moderní protokoly. Další úvodní informace najdete v tématu Co je proxy aplikací.

proxy aplikací se doporučuje poskytnout vzdáleným uživatelům přístup k interním prostředkům. proxy aplikací nahrazuje potřebu sítě VPN nebo reverzního proxy serveru pro tyto případy použití vzdáleného přístupu. Není určena pro uživatele, kteří jsou v podnikové síti. Tito uživatelé, kteří používají proxy aplikací pro intranetový přístup, můžou mít nežádoucí problémy s výkonem.

Tento článek obsahuje prostředky, které potřebujete k plánování, provozu a správě proxy aplikací Azure AD.

Plánování implementace

Následující část nabízí široký pohled na hlavní prvky plánování, které vám zajistí efektivní prostředí pro nasazování.

Požadavky

Před zahájením implementace budete muset splnit následující požadavky. Další informace o nastavení prostředí, včetně těchto požadavků, najdete v tomto kurzu.

  • Konektory: Konektory jsou odlehčené agenty, na které můžete nasadit:

    • Fyzický hardware místně
    • Virtuální počítač hostovaný v jakémkoli řešení hypervisoru
    • Virtuální počítač hostovaný v Azure, který umožňuje odchozí připojení ke službě proxy aplikací.
  • Podrobnější přehled najdete v tématu Vysvětlení konektorů proxy aplikací Azure AD .

    • Počítače konektorů musí být povolené pro protokol TLS 1.2 před instalací konektorů.

    • Pokud je to možné, nasaďte konektory ve stejné síti a segmentu jako back-endové webové aplikační servery. Po dokončení zjišťování aplikací je nejlepší nasadit konektory.

    • Pro zajištění vysoké dostupnosti a škálování doporučujeme, aby každá skupina konektorů měla alespoň dva konektory. Mít tři konektory je optimální v případě, že budete možná potřebovat obsluhovat počítač v libovolném okamžiku. Projděte si tabulku kapacity konektoru , která vám pomůže s rozhodováním, na jaký typ počítače se mají konektory nainstalovat. Čím větší bude počítač, tím větší bude vyrovnávací paměť a provede konektor.

  • Nastavení přístupu k síti: Konektory azure AD proxy aplikací se připojují k Azure přes PROTOKOL HTTPS (port TCP 443) a HTTP (port TCP 80).

    • Ukončování provozu PROTOKOLU TLS konektoru se nepodporuje a zabrání konektorům vytvořit zabezpečený kanál s příslušnými koncovými body proxy serveru Aplikace Azure.

    • Vyhněte se všem formám vložené kontroly odchozí komunikace TLS mezi konektory a Azure. Interní kontrola mezi konektorem a back-endovými aplikacemi je možná, ale může snížit uživatelské prostředí a proto se nedoporučuje.

    • Vyrovnávání zatížení samotných konektorů se také nepodporuje nebo dokonce nevyžaduje.

Důležité informace před konfigurací služby Azure AD proxy aplikací

Aby bylo možné nakonfigurovat a implementovat azure AD proxy aplikací, musí být splněny následující základní požadavky.

  • Onboarding Azure: Před nasazením proxy aplikací musí být identity uživatelů synchronizované z místního adresáře nebo vytvořené přímo ve vašich tenantech Azure AD. Synchronizace identit umožňuje službě Azure AD předem ověřovat uživatele před udělením přístupu k publikovaným aplikacím proxy aplikací a mít potřebné informace o identifikátoru uživatele k provedení jednotného přihlašování (SSO).

  • Požadavky podmíněného přístupu: Nedoporučujeme používat proxy aplikací pro intranetový přístup, protože tím se zvyšuje latence, která ovlivní uživatele. Doporučujeme používat proxy aplikací se zásadami předběžného ověřování a podmíněného přístupu pro vzdálený přístup z internetu. Přístup k poskytování podmíněného přístupu pro intranetové použití spočívá v modernizaci aplikací, aby bylo možné je přímo ověřit pomocí AAD. Další informace najdete v tématu Zdroje informací o migraci aplikací na AAD.

  • Limity služeb: Pro ochranu proti nadměrnému využití prostředků podle jednotlivých tenantů existují omezení nastavená na aplikaci a tenanta. Pokud chcete tyto limity zobrazit, přečtěte si omezení a omezení služby Azure AD. Tato omezení omezování jsou založená na srovnávacím testu nad obvyklým objemem využití a poskytuje dostatek vyrovnávací paměti pro většinu nasazení.

  • Veřejný certifikát: Pokud používáte vlastní názvy domén, musíte si opatřet certifikát TLS/SSL. V závislosti na požadavcích vaší organizace může získání certifikátu nějakou dobu trvat a doporučujeme začít proces co nejdříve. Aplikace Azure Proxy podporuje standardní, zástupné dokumentace nebo certifikáty založené na síti SAN. Další podrobnosti najdete v tématu Konfigurace vlastních domén pomocí služby Azure AD proxy aplikací.

  • Požadavky na doménu: Jednotné přihlašování k publikovaným aplikacím pomocí omezeného delegování protokolu Kerberos (KCD) vyžaduje, aby server s konektorem a serverem, na kterém běží aplikace, byly připojené k doméně a součástí stejné domény nebo důvěryhodných domén. Podrobné informace o tématu najdete v tématu KCD pro jednotné přihlašování pomocí proxy aplikací. Služba konektoru běží v kontextu místního systému a neměla by být nakonfigurovaná tak, aby používala vlastní identitu.

  • Záznamy DNS pro adresy URL

    • Před použitím vlastních domén v proxy aplikací musíte vytvořit záznam CNAME ve veřejném DNS, což klientům umožňuje přeložit vlastní definovanou externí adresu URL na předdefinovanou proxy aplikací adresu. Při vytváření záznamu CNAME pro aplikaci, která používá vlastní doménu, se nedaří vytvořit záznam CNAME, zabrání vzdáleným uživatelům v připojení k aplikaci. Kroky potřebné k přidání záznamů CNAME se můžou lišit od poskytovatele DNS po zprostředkovatele, takže zjistěte, jak spravovat záznamy a sady záznamů DNS pomocí Azure Portal.

    • Podobně hostitelé konektorů musí být schopni přeložit interní adresu URL publikovaných aplikací.

  • Práva a role pro správu

    • Instalace konektoru vyžaduje oprávnění místního správce k serveru Windows, na který se instaluje. Vyžaduje také minimálně roli správce aplikace k ověření a registraci instance konektoru do tenanta Azure AD.

    • Publikování a správa aplikací vyžadují roli Správce aplikací . Správci aplikací můžou spravovat všechny aplikace v adresáři, včetně registrací, nastavení jednotného přihlašování, přiřazení uživatelů a skupin a licencování, nastavení proxy aplikací a souhlasu. Neuděluje možnost spravovat podmíněný přístup. Role Správce cloudových aplikací má všechny možnosti správce aplikace, s výjimkou toho, že neumožňuje správu nastavení proxy aplikací.

  • Licencování: proxy aplikací je k dispozici prostřednictvím předplatného Azure AD Premium. Úplný seznam možností licencování a funkcí najdete na stránce Azure Active Directory Ceny.

Zjišťování aplikací

Zkompilujte inventář všech aplikací v oboru, které se publikují prostřednictvím proxy aplikací shromažďováním následujících informací:

Typ informací Informace ke shromažďování
Typ služby Příklad: SharePoint, SAP, CRM, Custom Web Application, API
Aplikační platforma Příklad: Windows IIS, Apache v Linuxu, Tomcat, NGINX
Členství domény Plně kvalifikovaný název domény webového serveru (FQDN)
Umístění aplikace Umístění webového serveru nebo farmy ve vaší infrastruktuře
Interní přístup Přesná adresa URL použitá při interním přístupu k aplikaci.
Pokud se farma používá, jaký typ vyrovnávání zatížení se používá?
Určuje, zda aplikace nakreslí obsah z jiných zdrojů, než je samotný.
Určete, jestli aplikace funguje přes WebSockets.
Externí přístup Řešení dodavatele, které už aplikace může být vystavena externě.
Adresa URL, kterou chcete použít pro externí přístup. Pokud SharePoint, ujistěte se, že jsou na základě těchto pokynů nakonfigurovaná mapování alternativních přístupů. Pokud ne, budete muset definovat externí adresy URL.
Veřejný certifikát Pokud používáte vlastní doménu, vytvořte certifikát s odpovídajícím názvem subjektu. pokud certifikát existuje, poznamenejte si sériové číslo a umístění, odkud ho lze získat.
Typ ověřování Typ ověřování podporovaný podporou aplikace, jako je Basic, Windows Integration Authentication, forms-based, header-based a claims.
Pokud je aplikace nakonfigurovaná tak, aby běžela pod konkrétním účtem domény, poznamenejte si plně kvalifikovaný název domény (FQDN) účtu služby.
Pokud je založený na SAML, identifikátor a adresy URL odpovědí.
Pokud je založené na hlavičce, řešení dodavatele a konkrétní požadavek na zpracování typu ověřování.
Název skupiny konektorů Logický název skupiny konektorů, které budou určené k poskytování konduitů a jednotného přihlašování k této back-endové aplikaci.
Přístup uživatelů/skupin Uživatelům nebo skupinám uživatelů, kterým bude udělen externí přístup k aplikaci.
Další požadavky Poznamenejte si všechny další požadavky na vzdálený přístup nebo zabezpečení, které by se měly zohlednit při publikování aplikace.

Tuto tabulku inventáře aplikací si můžete stáhnout a inventarizaci aplikací.

Definování požadavků organizace

Tady jsou oblasti, pro které byste měli definovat obchodní požadavky vaší organizace. Každá oblast obsahuje příklady požadavků.

Přístup

  • Vzdálení uživatelé s připojenými k doméně nebo zařízeními připojenými k Azure AD můžou bezpečně přistupovat k publikovaným aplikacím s bezproblémovým jednotným přihlašováním (SSO).

  • Vzdálení uživatelé se schválenými osobními zařízeními můžou bezpečně přistupovat k publikovaným aplikacím za předpokladu, že jsou zaregistrovaní v MFA, a zaregistrovali Microsoft Authenticator aplikaci na svém mobilním telefonu jako metodu ověřování.

Zásady správného řízení

  • Správci můžou definovat a monitorovat životní cyklus přiřazení uživatelů k aplikacím publikovaným prostřednictvím proxy aplikací.

Zabezpečení

  • K aplikacím přiřazeným prostřednictvím členství ve skupině nebo k těmto aplikacím mají přístup jenom uživatelé přiřazení jednotlivě.

Výkon

  • Ve srovnání s přístupem k aplikaci z interní sítě nedojde ke snížení výkonu aplikace.

Uživatelské prostředí

  • Uživatelé vědí, jak získat přístup k aplikacím pomocí známých adres URL společnosti na libovolné platformě zařízení.

Auditování

  • Správci můžou auditovat aktivitu přístupu uživatelů.

Osvědčené postupy pro pilotní nasazení

Určete dobu a úsilí potřebné k úplnému zadání jedné aplikace pro vzdálený přístup pomocí jednotného přihlašování (SSO). Provedete to spuštěním pilotního nasazení, který považuje počáteční zjišťování, publikování a obecné testování. Použití jednoduché webové aplikace založené na službě IIS, která je již předem nakonfigurovaná pro integrované ověřování Windows (IWA), by pomohla vytvořit směrný plán, protože toto nastavení vyžaduje minimální úsilí pro úspěšné pilotní nasazení vzdáleného přístupu a jednotného přihlašování.

Následující prvky návrhu by měly zvýšit úspěšnost pilotní implementace přímo v produkčním tenantovi.

Správa konektorů:

  • Konektory hrají klíčovou roli při poskytování místních služeb aplikacím. Použití výchozí skupiny konektorů je vhodné pro počáteční pilotní testování publikovaných aplikací před jejich uvedením do produkčního prostředí. Úspěšně otestované aplikace je pak možné přesunout do skupin produkčních konektorů.

Správa aplikací:

  • Vaši pracovníci si pravděpodobně zapamatuje, že externí adresa URL je známá a relevantní. Vyhněte se publikování aplikace pomocí předdefinovaných msappproxy.net nebo přípon onmicrosoft.com. Místo toho zadejte známou ověřenou doménu nejvyšší úrovně s předponou logického názvu hostitele, jako je intranet.<>customers_domain.com.

  • Omezit viditelnost ikony pilotní aplikace na pilotní skupinu skrytím jeho ikony spuštění ve formě portálu Azure MyApps. Až budete připraveni na produkční prostředí, můžete aplikaci nastavit na cílovou skupinu, a to buď ve stejném předprodukčním tenantovi, nebo publikováním aplikace ve vašem produkčním tenantovi.

Nastavení jednotného přihlašování: Některá nastavení jednotného přihlašování mají specifické závislosti, které můžou chvíli trvat, takže se vyhněte zpoždění řízení změn tím, že zajistíte, aby se závislosti vyřešily předem. Patří sem hostitelé konektoru pro připojení k doméně, kteří provádějí jednotné přihlašování pomocí omezeného delegování protokolu Kerberos (KCD) a starají se o další časově náročné aktivity. Pokud například potřebujete jednotné přihlašování založené na hlavičce, nastavte instanci přístup ping.

TLS Between Connector Host and Target Application: Zabezpečení je nejdůležitější, takže protokol TLS mezi hostitelem konektoru a cílovými aplikacemi by se měl vždy používat. Zejména pokud je webová aplikace nakonfigurovaná pro ověřování pomocí formulářů (FBA), protože přihlašovací údaje uživatele se pak efektivně přenášejí ve formátu prostého textu.

Implementujte přírůstkově a otestujte jednotlivé kroky. Po publikování aplikace proveďte základní funkční testování, abyste zajistili splnění všech požadavků na uživatele a firmy podle následujících pokynů:

  1. Otestujte a ověřte obecný přístup k webové aplikaci pomocí zakázaného předběžného ověřování.
  2. Pokud úspěšné povolení předběžného ověřování a přiřazení uživatelů a skupin Otestujte a ověřte přístup.
  3. Pak přidejte metodu jednotného přihlašování pro vaši aplikaci a otestujte znovu, abyste ověřili přístup.
  4. Podle potřeby použijte zásady podmíněného přístupu a vícefaktorového ověřování. Otestujte a ověřte přístup.

Nástroje pro řešení potíží: Při řešení potíží vždy začněte ověřováním přístupu k publikované aplikaci z prohlížeče na hostiteli konektoru a ověřte, že aplikace funguje podle očekávání. Jednodušší nastavení, jednodušší určení původní příčiny, proto zvažte pokus o reprodukci problémů s minimální konfigurací, jako je použití pouze jednoho konektoru a bez jednotného přihlašování. V některých případech můžou být nástroje pro ladění webu, jako je Fiddler společnosti Telerik, nezbytné k řešení problémů s přístupem nebo obsahem v aplikacích, ke kterým se přistupuje prostřednictvím proxy serveru. Fiddler může také fungovat jako proxy server, který pomáhá trasovat a ladit provoz pro mobilní platformy, jako je iOS a Android, a prakticky cokoli, co je možné nakonfigurovat pro směrování přes proxy server. Další informace najdete v průvodci odstraňováním potíží .

Implementace řešení

Nasazení proxy aplikací

Postup nasazení proxy aplikací najdete v tomto kurzu pro přidání místní aplikace pro vzdálený přístup. Pokud instalace není úspěšná, vyberte na portálu řešení potíží proxy aplikací nebo použijte průvodce odstraňováním potíží s instalací konektoru agenta proxy aplikací.

Publikování aplikací pomocí proxy aplikací

Publikování aplikací předpokládá, že jste splnili všechny požadavky a že máte několik konektorů, které se na stránce proxy aplikací zobrazují jako registrované a aktivní.

Aplikace můžete publikovat také pomocí PowerShellu.

Níže najdete některé osvědčené postupy pro publikování aplikace:

  • Použití skupin konektorů: Přiřaďte skupinu konektorů určenou pro publikování každé příslušné aplikace. Pro zajištění vysoké dostupnosti a škálování doporučujeme, aby každá skupina konektorů poskytovala alespoň dva konektory. Mít tři konektory jsou optimální pro případ, že budete muset počítač v libovolném okamžiku obsluhovat. Další informace najdete v tématu Publikování aplikací v samostatných sítích a umístěních pomocí skupin konektorů a zjistěte, jak můžete skupiny konektorů použít k segmentování konektorů podle sítě nebo umístění.

  • Nastavení časového limitu back-endové aplikace: Toto nastavení je užitečné ve scénářích, kdy aplikace může vyžadovat zpracování klientské transakce déle než 75 sekund. Například když klient odešle dotaz do webové aplikace, která funguje jako front-end do databáze. Front-end odešle tento dotaz na back-endový databázový server a čeká na odpověď, ale jakmile obdrží odpověď, vyprší časový limit klientské strany konverzace. Nastavení časového limitu na Long poskytuje 180 sekund pro dokončení delších transakcí.

  • Použít vhodné typy souborů cookie

    • Soubor cookie pouze HTTP: Poskytuje další zabezpečení tím, že proxy aplikací zahrnout příznak HTTPOnly do hlaviček odpovědi HTTP set-cookie. Toto nastavení pomáhá zmírnit zneužití, jako je skriptování mezi weby (XSS). U klientů a uživatelských agentů, kteří vyžadují přístup k souboru cookie relace, ponechte tuto možnost nastavenou na Hodnotu Ne. Například klient RDP/MTSC, který se připojuje k bráně vzdálené plochy publikované prostřednictvím proxy aplikací.

    • Zabezpečený soubor cookie: Pokud je soubor cookie nastavený s atributem Secure, bude uživatelský agent (aplikace na straně klienta) obsahovat soubor cookie pouze v požadavcích HTTP, pokud se požadavek přenáší přes zabezpečený kanál TLS. To pomáhá zmírnit riziko napadení souborů cookie přes jasné textové kanály, proto by se mělo povolit.

    • Trvalý soubor cookie: Umožňuje souboru cookie relace proxy aplikací zachovat mezi zavřením prohlížeče zbývající platností, dokud nevyprší platnost nebo se odstraní. Používá se pro scénáře, kdy bohatá aplikace, jako je office, přistupuje k dokumentu v rámci publikované webové aplikace, aniž by se uživatel znovu zobrazoval výzvy k ověření. Buďte opatrní, protože trvalé soubory cookie můžou v konečném důsledku opustit službu rizikem neoprávněného přístupu, pokud se nepoužívá ve spojení s jinými kompenzačními ovládacími prvky. Toto nastavení by se mělo používat jenom pro starší aplikace, které nemůžou sdílet soubory cookie mezi procesy. Je lepší aktualizovat aplikaci tak, aby zpracovávala soubory cookie sdílení mezi procesy místo použití tohoto nastavení.

  • Překlad adres URL v hlavičkách: Tuto možnost povolíte ve scénářích, ve kterých se interní DNS nedá nakonfigurovat tak, aby odpovídaly veřejnému oboru názvů organizace (a.k.a Split DNS). Pokud vaše aplikace nevyžaduje v požadavku klienta původní hlavičku hostitele, ponechte tuto hodnotu nastavenou na Ano. Alternativou je mít konektor, který používá plně kvalifikovaný název domény v interní adrese URL pro směrování skutečného provozu, a plně kvalifikovaný název domény v externí adrese URL jako hlavičku hostitele. Ve většiněpřípadůch &

  • Přeložit adresy URL v textu aplikace: Pokud chcete, aby odkazy z této aplikace byly přeloženy zpět na klienta, zapněte překlad textu aplikace. Pokud je tato funkce povolená, jedná se o pokus o překlad všech interních odkazů, které proxy aplikace najde v odpovědích HTML a CSS, které se vrací klientům. Je užitečné, když publikujete aplikace, které obsahují pevně zakódované odkazy na absolutní název nebo odkazy netBIOS na krátký název v obsahu, nebo aplikace s obsahem, který odkazuje na jiné místní aplikace.

Ve scénářích, kdy publikovaná aplikace odkazuje na jiné publikované aplikace, povolte překlad odkazů pro každou aplikaci, abyste měli kontrolu nad uživatelským prostředím na úrovni jednotlivých aplikací.

Předpokládejme například, že máte tři aplikace publikované prostřednictvím proxy aplikací, které se vzájemně propojují: výhody, výdaje a cestování, plus čtvrtá aplikace Feedback, která se nepublikuje prostřednictvím proxy aplikací.

Picture 1

Když povolíte překlad odkazů pro aplikaci Výhody, odkazy na výdaje a cestování se přesměrují na externí adresy URL pro tyto aplikace, aby k nim uživatelé přistupovali mimo podnikovou síť. Odkazy z výdajů a cestování zpět na výhody nefungují, protože překlad odkazů pro tyto dvě aplikace není povolený. Odkaz na zpětnou vazbu není přesměrován, protože neexistuje žádná externí adresa URL, takže uživatelé, kteří používají aplikaci Výhody, nebudou mít přístup k aplikaci pro zpětnou vazbu mimo podnikovou síť. Podrobné informace o překladu odkazů a dalších možnostech přesměrování

Přístup k aplikaci

Existuje několik možností pro správu přístupu k publikovaným prostředkům proxy aplikací, takže zvolte tu nejvhodnější pro váš scénář a potřeby škálovatelnosti. Mezi běžné přístupy patří: použití místních skupin, které se synchronizují prostřednictvím služby Azure AD Připojení, vytváření dynamických skupin v Azure AD na základě atributů uživatelů, používání skupin samoobslužných služeb spravovaných vlastníkem prostředku nebo kombinace všech těchto možností. Výhody jednotlivých zdrojů najdete v propojených zdrojích.

Nejpřímější způsob přiřazení přístupu uživatelů k aplikaci je přechod do možností Uživatelé a skupiny v levém podokně publikované aplikace a přímé přiřazování skupin nebo jednotlivců.

Picture 24

Uživatelům můžete také povolit samoobslužný přístup k vaší aplikaci tím, že přiřadíte skupinu, která není aktuálně členem a konfiguruje možnosti samoobslužné služby.

Picture 25

Pokud je tato možnost povolená, uživatelé se pak budou moct přihlásit k portálu MyApps a požádat o přístup a buď budou automaticky schváleni a přidáni do již povolené samoobslužné skupiny, nebo potřebují schválení od určeného schvalovatele.

Uživatelům typu host je také možné pozvat přístup k interním aplikacím publikovaným prostřednictvím proxy aplikací prostřednictvím Azure AD B2B.

U místních aplikací, které jsou normálně přístupné anonymně a nevyžadují žádné ověřování, můžete raději zakázat možnost umístěnou ve vlastnostech aplikace.

Picture 26

Pokud tuto možnost necháte nastavenou na hodnotu Ne, umožní uživatelům přistupovat k místní aplikaci přes Proxy aplikací Azure AD bez oprávnění, proto je používejte s opatrností.

Po publikování aplikace by měla být přístupná zadáním jeho externí adresy URL v prohlížeči nebo jeho ikonou na adrese https://myapps.microsoft.com.

Povolení předběžného ověřování

Ověřte, že je vaše aplikace přístupná prostřednictvím proxy aplikací přístupu přes externí adresu URL.

  1. Přejděte na Azure Active Directory>Enterprise aplikaceAll>a zvolte aplikaci, kterou chcete spravovat.

  2. Vyberte proxy aplikací.

  3. V poli Předběžné ověřování vyberte Azure Active Directory pomocí rozevíracího seznamu a vyberte Uložit.

Když je povolené předběžné ověřování, Azure AD nejprve vyzve uživatele k ověření a pokud je nakonfigurované jednotné přihlašování, back-endová aplikace před udělením přístupu k aplikaci také ověří uživatele. Změna režimu předběžného ověřování z předávání do Azure AD také nakonfiguruje externí adresu URL pomocí protokolu HTTPS, takže každá aplikace, která je původně nakonfigurovaná pro PROTOKOL HTTP, bude teď zabezpečená pomocí protokolu HTTPS.

Povolení jednoho Sign-On

Jednotné přihlašování poskytuje nejlepší možné uživatelské prostředí a zabezpečení, protože uživatelé se musí při přístupu k Azure AD přihlásit jenom jednou. Po předběžném ověření uživatele se jednotné přihlašování provádí konektorem proxy aplikací, který se ověřuje v místní aplikaci jménem uživatele. Back-endová aplikace zpracuje přihlášení, jako by se jednalo o samotného uživatele.

Volba možnosti Passthrough umožňuje uživatelům přistupovat k publikované aplikaci, aniž by se museli ověřovat ve službě Azure AD.

Jednotné přihlašování je možné jenom v případě, že Azure AD dokáže identifikovat uživatele, který žádá o přístup k prostředku, takže vaše aplikace musí být nakonfigurovaná tak, aby se uživatelé s Azure AD předem ověřili při přístupu k jednotnému přihlašování k fungování, jinak budou možnosti jednotného přihlašování zakázané.

Čtení jednotného přihlašování k aplikacím v Azure AD , které vám pomůžou při konfiguraci aplikací zvolit nejvhodnější metodu jednotného přihlašování.

Práce s jinými typy aplikací

Azure AD proxy aplikací může také podporovat aplikace vyvinuté tak, aby používaly knihovnu MSAL (Microsoft Authentication Library). Podporuje nativní klientské aplikace využíváním vydaných tokenů Azure AD přijatých v hlavičce požadavku klienta na provedení předběžného ověřování jménem uživatelů.

Přečtěte si o dostupných konfiguracích proxy aplikací publikování nativních a mobilních klientských aplikací a aplikací založených na deklaracích identity.

Posílení zabezpečení pomocí podmíněného přístupu

Zabezpečení aplikací vyžaduje pokročilou sadu možností zabezpečení, které můžou chránit před složitými hrozbami místně i v cloudu a reagovat na ně. Útočníci nejčastěji získávají přístup k podnikové síti prostřednictvím slabých, výchozích nebo odcizených přihlašovacích údajů uživatele. Zabezpečení řízené identitou Microsoftu snižuje používání odcizených přihlašovacích údajů tím, že spravuje a chrání privilegované i neprivilegované identity.

K podpoře služby Azure AD proxy aplikací je možné použít následující možnosti:

  • Podmíněný přístup založený na uživateli a umístění: Udržujte citlivá data chráněná omezením přístupu uživatelů na základě geografického umístění nebo IP adresy pomocí zásad podmíněného přístupu na základě polohy.

  • Podmíněný přístup založený na zařízeních: Ujistěte se, že k podnikovým datům s podmíněným přístupem založeným na zařízeních mají přístup jenom zaregistrovaná, schválená a kompatibilní zařízení.

  • Podmíněný přístup založený na aplikaci: Práce se nemusí zastavit, když uživatel není v podnikové síti. Zabezpečte přístup k podnikovému cloudu a místním aplikacím a udržujte kontrolu pomocí podmíněného přístupu.

  • Podmíněný přístup založený na riziku: Chraňte svá data před škodlivými hackery pomocí zásad podmíněného přístupu na základě rizik , které se dají použít pro všechny aplikace a všechny uživatele, ať už místně nebo v cloudu.

  • Azure AD Moje aplikace: S nasazenou službou proxy aplikací a bezpečně publikovanými aplikacemi můžete uživatelům nabídnout jednoduché centrum pro zjišťování a přístup ke všem aplikacím. Zvyšte produktivitu pomocí samoobslužných funkcí, jako je možnost požádat o přístup k novým aplikacím a skupinám nebo spravovat přístup k těmto prostředkům jménem ostatních prostřednictvím Moje aplikace.

Správa implementace

Požadované role

Microsoft doporučuje udělit nejnižší možné oprávnění k provádění potřebných úloh pomocí Azure AD. Projděte si různé role Azure, které jsou k dispozici , a zvolte tu správnou, která bude řešit potřeby jednotlivých osob. Po dokončení nasazení může být potřeba některé role dočasně použít a odebrat.

Obchodní role Obchodní úkoly Role Azure AD
Správce helpdesku Obvykle se omezuje na opravňující problémy nahlášené koncovým uživatelem a provádění omezených úloh, jako je změna hesel uživatelů, zrušení platnosti obnovovacích tokenů a monitorování stavu služby. Správce helpdesku
Správce identit Přečtěte si sestavy přihlášení a protokoly auditu Azure AD, abyste mohli ladit problémy související s proxy aplikací. Čtenář zabezpečení
Vlastník aplikace Vytvářejte a spravujte všechny aspekty podnikových aplikací, registrací aplikací a nastavení proxy aplikací. Správce aplikace
Správce infrastruktury Vlastník vrácení certifikátu Správce aplikace

Minimalizace počtu lidí, kteří mají přístup k zabezpečeným informacím nebo prostředkům, pomůže snížit riziko neoprávněného přístupu objektu actor se zlými úmysly nebo neúmyslně ovlivnění citlivého prostředku autorizovaným uživatelem.

Uživatelé ale stále potřebují provádět každodenní privilegované operace, takže vynucování zásad založených na Privileged Identity Management (JUST-in-Time) za účelem zajištění privilegovaného přístupu k prostředkům Azure na vyžádání a Azure AD je náš doporučený přístup k efektivní správě přístupu a auditování správy.

Sledování a vytváření sestav

Azure AD poskytuje další přehled o využití aplikací a provozním stavu vaší organizace prostřednictvím protokolů auditu a sestav. proxy aplikací také usnadňuje monitorování konektorů z portálu Azure AD a protokolů událostí Windows.

Protokoly auditu aplikací

Tyto protokoly poskytují podrobné informace o přihlášeních k aplikacím nakonfigurovaným s proxy aplikací a zařízením a uživatelem, kteří k aplikaci přistupují. Protokoly auditu se nacházejí v Azure Portal a v rozhraní API auditu pro export. Kromě toho jsou pro vaši aplikaci k dispozici také sestavy využití a přehledů .

monitorování konektoru proxy aplikací

Konektory a služba se postará o všechny úlohy s vysokou dostupností. Stav konektorů můžete monitorovat na stránce proxy aplikací na portálu Azure AD. Další informace o údržbě konektoru najdete v tématu Vysvětlení konektorů azure AD proxy aplikací Connectors.

Example: Azure AD Application Proxy connectors

Windows protokoly událostí a čítače výkonu

Konektory mají protokoly správců i relací. Protokoly správce zahrnují klíčové události a jejich chyby. Protokoly relace zahrnují všechny transakce a podrobnosti o jejich zpracování. Protokoly a čítače jsou umístěné v protokolech událostí Windows, kde najdete další informace v tématu Vysvětlení konektorů služby Azure AD proxy aplikací. Podle tohoto kurzu nakonfigurujte zdroje dat protokolu událostí ve službě Azure Monitor.

Průvodce odstraňováním potíží a kroky

Přečtěte si další informace o běžných problémech a jejich řešení pomocí našeho průvodce odstraňováním chybových zpráv.

Následující články popisují běžné scénáře, které je možné použít také k vytvoření průvodců odstraňováním potíží pro vaši organizaci podpory.