Veřejný klient a důvěrné klientské aplikace
Knihovna MSAL (Microsoft Authentication Library) definuje dva typy klientů; veřejných klientů a důvěrných klientů. Klient je softwarová entita, která má jedinečný identifikátor přiřazený zprostředkovatelem identity. Typy klientů jsou odlišeny schopností zabezpečeného ověřování u autorizačního serveru a uchovávání citlivých informací o ověření identity, aby k nim uživatel neměl přístup ani je v rámci jeho přístupu nepoznal.
| Veřejné klientské aplikace | Důvěrné klientské aplikace |
|---|---|
 Desktopová aplikace |
 Webová aplikace |
 Rozhraní API bez prohlížeče |
 Webové rozhraní API |
 Mobilní aplikace |
Služba nebo proces démon |
Veřejný klient a důvěrná autorizace klienta
Při zkoumání veřejné nebo důvěrné povahy daného klienta vyhodnocujeme schopnost tohoto klienta prokázat jeho identitu autorizačnímu serveru. To je důležité, protože autorizační server musí být schopný důvěřovat identitě klienta, aby mohl vydávat přístupové tokeny.
Veřejné klientské aplikace běží na zařízeních, jako jsou desktopová, bez prohlížečů rozhraní API, mobilní aplikace nebo aplikace prohlížeče na straně klienta. Nemůžou být důvěryhodní, aby bezpečně uchovávali tajné kódy aplikací, takže můžou přistupovat jenom k webovým rozhraním API jménem uživatele. Kdykoli se zdrojový nebo kompilovaný bajtový kód dané aplikace přenáší kdekoli, kde se dá číst, rozebírat nebo jinak kontrolovat nedůvěryhodné strany, je to veřejný klient. Protože také podporují jen toky veřejných klientů a nemůžou uchovávat tajné kódy v době konfigurace, nemůžou mít tajné kódy klienta.
Důvěrné klientské aplikace běží na serverech, jako jsou webové aplikace, aplikace webového rozhraní API nebo aplikace služby/démona. Uživatelé nebo útočníci se považují za obtížně přístupné, a proto mohou odpovídajícím způsobem uchovávat tajné kódy v době konfigurace, aby bylo možné prokázat jeho identitu. ID klienta se vystavuje prostřednictvím webového prohlížeče, ale tajný kód se předává jenom v back channelu a nikdy přímo nezpřístupní.
Kdy byste měli povolit tok veřejného klienta v registraci aplikace?
Po určení typu klientské aplikace, kterou vytváříte, se můžete rozhodnout, jestli chcete povolit tok veřejného klienta v registraci aplikace. Ve výchozím nastavení by se měl povolit tok veřejného klienta v registraci vaší aplikace, pokud vy nebo váš vývojář nevytvářete veřejnou klientskou aplikaci a používáte následující autorizační protokol nebo funkce OAuth:
| Protokol nebo funkce autorizace OAuth | Typ veřejné klientské aplikace | Příklady/poznámky |
|---|---|---|
| Nativní ověřování | Microsoft Entra Externí ID aplikace, která vyžaduje úplné přizpůsobení uživatelského rozhraní, včetně prvků návrhu, umístění loga a rozložení, zajištění konzistentního a značkového vzhledu. | Poznámka: Nativní ověřování je dostupné jenom pro registrace aplikací v Microsoft Entra Externí ID tenantech. Další informace najdete tady. |
| Tok kódu zařízení | Aplikace, které běží na zařízeních s omezeným vstupem, jako je inteligentní TV, zařízení IoT nebo tiskárna | |
| Tok přihlašovacích údajů vlastníka prostředku | Aplikace, které zpracovávají hesla, zadávají uživatele přímo, místo aby přesměrovávají uživatele na přihlašovací web entra hostované a nechaly Entra zpracovávat uživatelské heslo zabezpečeným způsobem. | Microsoft doporučuje nepoužívat tok ROPC. Ve většiněscénářůch |
| Tok integrovaného ověřování windows | Desktopové nebo mobilní aplikace spuštěné ve Windows nebo na počítači připojeném k doméně Windows (připojené k Microsoft Entra ID nebo Microsoft Entra) pomocí integrovaného ověřovacího toku Windows místo správce webových účtů | Desktopová nebo mobilní aplikace, která by se měla automaticky přihlásit po přihlášení uživatele k počítači s Windows pomocí přihlašovacích údajů Microsoft Entra |
Tajné kódy a jejich důležitost při dokazování identity
Tady je několik příkladů, jak může klient prokázat svou identitu autorizačnímu serveru:
- Spravované identity pro prostředky Azure – pro scénáře ověřování jen pro aplikace, vývojáře aplikací a služeb, kteří jsou v Azure stavět, mají možnost přesměrovat správu tajných kódů, obměnu a ochranu na samotnou platformu. U spravovaných identit se identity poskytují a odstraňují s prostředky Azure a nikdo, včetně globálního správce, má přístup k podkladovým přihlašovacím údajům. Pomocí spravovaných identit můžete zabránit riziku úniku tajných kódů a nechat poskytovatele zpracovat zabezpečení za vás.
- ID klienta a tajný klíč – V tomto vzoru se při registraci klienta vygeneruje dvojice hodnot autorizačním serverem. ID klienta je veřejná hodnota, která identifikuje aplikaci, zatímco tajný klíč klienta je důvěrná hodnota použitá k prokázání identity aplikace.
- Prokázání vlastnictví certifikátu – infrastruktura veřejných klíčů (PKI), která zahrnuje standardy, jako je X.509, je základní technologie, která umožňuje zabezpečenou komunikaci přes internet a tvoří páteř ochrany osobních údajů v internetu. Infrastruktura veřejných klíčů se používá k vydávání digitálních certifikátů, které ověřují identitu stran zapojených do online komunikace, a je základní technologií, která využívá protokoly, jako je HTTPS, což se běžně používá k zabezpečení webového provozu. Podobně lze certifikáty použít k zabezpečení komunikace mezi službami (S2S) v Azure povolením vzájemného ověřování mezi službami. To zahrnuje každou službu, která prezentuje certifikát druhému jako prostředek pro prokázání své identity.
- Prezentace podepsaného kontrolního výrazu – Používá se v federaci identit úloh, podepsané kontrolní výrazy umožňují výměnu tokenu zprostředkovatele identity důvěryhodné třetí strany s platformou Microsoft Identity Platform za účelem získání přístupových tokenů pro volání prostředků chráněných microsoftem Entra. Federace identit úloh se dá použít k povolení různých scénářů federace, včetně Azure Kubernetes Service, Amazon Web Services EKS, GitHub Actions a dalších.
Kdy je ověření identity klienta důležité?
Ověření identity klienta záleží, když je potřeba před udělením přístupu k citlivým datům nebo prostředkům ověřit pravost i autorizaci klientské aplikace. Mezi některé příklady patří:
- Řízení přístupu k rozhraní API – Pokud máte rozhraní API, které se měří (například pro fakturaci), nebo zveřejňuje citlivá data nebo prostředky, před udělením přístupu ověříte identitu klienta. To je například důležité při zajišťování přístupu k rozhraní API jenom autorizovaným aplikacím a že se za využití měřeného rozhraní API účtuje správný zákazník.
- Ochrana uživatelů před zosobněním aplikací – pokud máte nasazenou službu, uživatelem řízenou aplikaci (například back-endovou webovou aplikaci), která přistupuje k citlivým datům nebo službám, pomocí tajných kódů klienta k ochraně prostředků používaných touto aplikací může zabránit zosobnění legitimního klienta, aby zosobnil uživatele a exfiltroval přístup k datům nebo zneužití.
- Komunikace S2S – Pokud máte více back-endových služeb (jako jsou podřízená rozhraní API), které spolu potřebují komunikovat, můžete ověřit identitu každé služby, abyste zajistili, že mají oprávnění přistupovat pouze k nezbytným prostředkům, aby mohly provádět svou funkci.
Obecně platí, že ověření identity klienta je důležité, když je potřeba ověřit a autorizovat klienta nezávisle na uživateli nebo také na něm.
Důvěrní klienti: Osvědčené postupy pro správu tajných kódů
Použití spravovaných identit ke zjednodušení nasazení a zabezpečení – Spravované identity poskytují automaticky spravovanou identitu v Microsoft Entra ID pro aplikace, které se mají použít při připojování k prostředkům, které podporují ověřování Microsoft Entra. Aplikace můžou používat spravované identity k získání tokenů jen pro aplikaci Microsoft Entra ID bez nutnosti spravovat přihlašovací údaje. To může odstranit řadu složitostí spojených se správou tajných kódů a zároveň zvýšit zabezpečení a odolnost. Pokud používáte spravované identity, většina z následujících osvědčených postupů se o vás postará.
Používejte zabezpečené úložiště – ukládejte tajné kódy klienta do zabezpečeného umístění, jako je Key Vault nebo šifrovaný konfigurační soubor. Vyhněte se ukládání tajných kódů klienta do prostého textu nebo jako vrácených souborů se změnami do systémů správy verzí.
Omezit přístup – Omezte přístup k tajným kódům klientů jenom autorizovaným pracovníkům. Pomocí řízení přístupu na základě role omezte přístup k tajným klíčům klientů jenom na ty, kteří ho potřebují k provádění svých provozních povinností.
Obměna tajných kódů klienta – obměna tajných kódů klientů podle potřeby nebo podle plánu může minimalizovat riziko zneužití ohroženého tajného klíče k získání neoprávněného přístupu. Při použití je časový rozsah, během kterého se navrhuje, aby klíč zůstal používán, ovlivněn silnou stránkou použitého kryptografického algoritmu nebo dodržováním standardů nebo postupů dodržování právních předpisů.
Používejte dlouhé tajné kódy a silné šifrování – úzce souvisí s předchozím bodem a použití silných šifrovacích algoritmů pro přenášená data (na drátu) i neaktivních uložených dat (na disku) pomáhá zajistit, aby tajné kódy s vysokou entropií zůstaly nepravděpodobné, že by byly vynucené hrubou silou. Algoritmy, jako je AES-128 (nebo vyšší), můžou pomoct chránit neaktivní uložená data, zatímco RSA-2048 (nebo vyšší) pomáhá efektivně chránit přenášená data. Vzhledem k neustále se vyvíjející povaze kybernetické bezpečnosti je vždy vhodné se obrátit na odborníky na zabezpečení a pravidelně kontrolovat výběr algoritmu.
Vyhněte se pevně zakódování tajných kódů – Nezakódujte tajné kódy klienta ve zdrojovém kódu. Zabránění tajným kódům ve zdrojovém kódu může minimalizovat hodnotu chybných herců, kteří získají přístup ke zdrojovému kódu. Může také zabránit tomu, aby se tyto tajné kódy omylem odsílaly do nezabezpečených úložišť nebo byly zpřístupněny přispěvatelům projektu, kteří by měli přístup ke zdroji, ale ne do tajného přístupu.
Monitorujte úložiště pro únik tajných kódů – je to nešťastný fakt, že při práci se zdrojovým kódem dochází ke špatným vrácením se změnami. Háky před potvrzením Gitu představují navrhovaný způsob, jak zabránit náhodnému vrácení se změnami, ale není to ani náhrada za monitorování. Automatizované monitorováníúložišťch kódů dokáže identifikovat úniky tajných kódů a s plánem, který by mohl obměňovat ohrožené přihlašovací údaje, může pomoct snížit bezpečnostní incidenty.
Monitorování podezřelých aktivit – Monitorujte protokoly a záznamy auditu pro podezřelé aktivity související s tajnými klíči klienta. Pokud je to možné, použijte automatizované výstrahy a procesy odezvy k upozorňování pracovníků a definování nepředvídaných aktivit souvisejících s tajnými klíči klienta.
Návrh aplikací s ohledem na klientské tajemství – Váš model zabezpečení je pouze tak silný jako nejslabší propojení v řetězu. Nepředávejte přihlašovací údaje zabezpečení ani tokeny od důvěrných klientů do veřejných klientů, protože by to mohlo přesunout data tajných klíčů klienta do veřejného klienta, což umožňuje zosobnění důvěrného klienta.
Používejte aktuální knihovny a sady SDK z důvěryhodných zdrojů – Platforma Microsoft Identity Platform poskytuje různé sady SDK pro klienty a serverové sady SDK a middleware navržené tak, aby zvýšily vaši produktivitu a současně zajistily zabezpečení vašich aplikací. Knihovny, jako je Microsoft.Identity.Web , zjednodušují přidávání ověřování a autorizace do webových aplikací a rozhraní API na platformě Microsoft Identity Platform. Udržování aktualizací závislostí pomáhá zajistit, aby vaše aplikace a služby využívaly nejnovější inovace a aktualizace zabezpečení.
Porovnání typů klientů a jejich možností
Tady jsou některé podobnosti a rozdíly mezi veřejnými a důvěrnými klientskými aplikacemi:
- Oba typy aplikací udržují mezipaměť tokenů uživatele a můžou získat token bezobslužně (když se token nachází v mezipaměti). Důvěrné klientské aplikace mají také mezipaměť tokenů aplikace pro tokeny získané samotnou aplikací.
- Oba typy aplikací můžou spravovat uživatelské účty a získat účet z mezipaměti tokenů uživatele, získat účet z jeho identifikátoru nebo odebrat účet.
- Ve službě MSAL mají veřejné klientské aplikace čtyři způsoby získání tokenu prostřednictvím samostatných toků ověřování. Důvěrné klientské aplikace mají pouze tři způsoby získání tokenu a jeden způsob, jak vypočítat adresu URL autorizovaného koncového bodu zprostředkovatele identity. ID klienta se předává jednou při sestavování aplikace a při získání tokenu se nemusí znovu předávat. Další informace najdete v tématu získání tokenů.
Veřejné klienty jsou užitečné pro povolení přístupu delegovaného uživatelem k chráněným prostředkům, ale nemůžou prokázat vlastní identitu aplikace. Důvěrné klienty můžou na druhé straně provádět ověřování uživatelů i aplikací a autorizaci a musí být sestaveny s ohledem na zabezpečení, aby se zajistilo, že se jejich tajné kódy nesdílí s veřejnými klienty nebo jinými třetími stranami.
V některýchpřípadechchmuchm klíčům se v některých případech výrazně zjednoduší infrastruktura, jako jsou spravované identity, výrazně pomáhá zjednodušit správu tajných kódů. Pokud se spravované identity nedají použít, je důležité, aby byly zavedeny zásady, preventivní opatření a nepředvídané zabezpečení tajných kódů a reakce na incidenty zabezpečení související s nimi.
Viz také
Další informace o konfiguraci a vytváření instancí aplikace najdete v tématu: