Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Osvědčené postupy zabezpečení pro vlastnosti aplikace v Microsoft Entra ID
Zabezpečení je důležitým konceptem při registraci aplikace v Microsoft Entra ID a je důležitou součástí jejího obchodního použití v organizaci. Jakákoli chybná konfigurace aplikace může vést k výpadku nebo ohrožení zabezpečení. V závislosti na oprávněních přidaných do aplikace můžou mít vlivy na celou organizaci.
Vzhledem k tomu, že zabezpečené aplikace jsou pro organizaci nezbytné, můžou mít případné výpadky z důvodu problémů se zabezpečením vliv na firmu nebo na některé důležité službě, na které firma závisí. Proto je důležité přidělit čas a prostředky, aby aplikace vždy zůstaly v dobrém a zabezpečeném stavu. Proveďte pravidelné posouzení zabezpečení a stavu aplikací, podobně jako posouzení modelu ohrožení zabezpečení pro kód. Širší perspektivu týkající se zabezpečení pro organizace najdete v tématu životní cyklus vývoje zabezpečení (SDL).
Tento článek popisuje osvědčené postupy zabezpečení pro následující vlastnosti a scénáře aplikace:
Typ identityt
Pověření
Přesměrovací URI
Implicitní konfigurace toku
URI ID aplikace (také známý jako identifikátor URI)
Verze přístupového tokenu
Zámek instance aplikace
Vlastnictví aplikace
Typ identityt
Pravděpodobně se zde dozvíte o osvědčených postupech zabezpečení pro aplikace Microsoft Entra – označované také jako registrace aplikací nebo objekty aplikací. Existuje ale jiný typ identity, který se dá použít pro přístup k prostředkům chráněným entra, označované jako spravované identity pro prostředky Azure.
Spravované identity Azure jsou ve výchozím nastavení zabezpečené a nevyžadují žádnou průběžnou údržbu ani režii. Pokud jsou splněné všechny následující skutečnosti, zvažte použití spravované identity místo aplikace Microsoft Entra pro vaši identitu aplikace:
Služba běží v cloudu Azure.
Aplikace nemusí přihlašovat uživatele.
Aplikace nemusí fungovat jako prostředek v toku tokenu (nejedná se o webové rozhraní API).
Aplikace nemusí fungovat v několika tenantech.
Poznámka
Spravované identity je možné použít pro přístup k prostředkům mimo Azure, včetně Microsoft Graphu.
Zbytek tohoto článku popisuje osvědčené postupy zabezpečení pro vlastnosti registrací aplikací Entra.
Přihlašovací údaje (včetně certifikátů a tajných kódů)
Přihlašovací údaje jsou důležitou součástí aplikace, když se používají jako důvěrný klient. Na stránce Certifikáty a tajné kódy aplikace na webu Azure Portal je možné přidat nebo odebrat přihlašovací údaje.
Zvažte následující doprovodné materiály související s certifikáty a tajnými kódy:
Pokud je to možné, použijte spravovanou identitu jako přihlašovací údaje. Důrazně se to doporučuje, protože spravované identity jsou nejbezpečnější možností a nevyžadují průběžnou správu přihlašovacích údajů. Podle těchto pokynů nakonfigurujte spravovanou identitu jako přihlašovací údaje. Tato možnost ale může být možná jenom v případě, že služba, ve které se aplikace používá, běží v Azure.
Pokud služba, ve které se aplikace používá, neběží v Azure, ale běží na jiné platformě, která nabízí automatizovanou správu přihlašovacích údajů, zvažte použití identity z této platformy jako přihlašovacích údajů. Pracovní postup GitHub Actions je například možné nakonfigurovat jako přihlašovací údaje, což eliminuje potřebu správy a zabezpečení přihlašovacích údajů pro kanál GitHub Actions. Při tomto přístupu buďte opatrní a nakonfigurujte jenom federované přihlašovací údaje z platforem, kterým důvěřujete. Aplikace je stejně zabezpečená jako platforma identit, která je nakonfigurovaná jako přihlašovací údaje.
Pokud použití spravované identity nebo jiného zabezpečeného externího zprostředkovatele identity není možné, použijte přihlašovací údaje certifikátu.
Nepoužívejte přihlašovací údaje hesla, označované také jako tajné kódy. I když je vhodné používat tajné kódy hesel jako přihlašovací údaje, přihlašovací údaje pro hesla jsou často špatně spravované a dají se snadno ohrozit.
Pokud se certifikát musí používat místo spravované identity, uložte ho do zabezpečeného trezoru klíčů, jako je Azure Key Vault.
Pokud se certifikát musí používat místo spravované identity, použijte certifikát od důvěryhodné certifikační autority (CA) místo certifikátu podepsaného svým držitelem.
Nakonfigurujte zásadu, která zajistí, že certifikáty pocházejí od důvěryhodných autorit. Pokud ale použití důvěryhodné certifikační autority není možné, upřednostňují se u hesel certifikáty podepsané svým držitelem.
Nakonfigurujte zásady správy aplikací pro řízení používání tajných kódů omezením jejich životnosti nebo blokováním jejich použití úplně.
Pokud se aplikace používá jenom jako veřejný nebo nainstalovaný klient (například mobilní nebo desktopové aplikace nainstalované na počítači koncového uživatele), ujistěte se, že objekt aplikace neobsahuje žádné přihlašovací údaje.
Zkontrolujte přihlašovací údaje používané v aplikacích a ověřte jejich aktuálnost a vypršení platnosti. Nepoužívané přihlašovací údaje v aplikaci můžou způsobit narušení zabezpečení. Často se přihlašovací údaje převrácejí a nesdílejí přihlašovací údaje mezi aplikacemi. Nemáte v jedné aplikaci mnoho přihlašovacích údajů.
Monitorujte produkční kanály, abyste zabránili tomu, že se přihlašovací údaje jakéhokoli druhu zapíšou do úložišť kódu.
Credential Scanner je nástroj pro statickou analýzu, který lze použít k detekci přihlašovacích údajů (a dalšího citlivého obsahu) ve zdrojovém kódu a výstupu sestavení.
Přesměrovací URI
Je důležité udržovat identifikátory URI přesměrování vaší aplikace aktuální. V části Ověřování pro aplikaci na webu Azure Portal musí být pro aplikaci vybrána platforma a pak je možné definovat vlastnost Identifikátor URI přesměrování.
Pro identifikátory URI pro přesměrování zvažte následující doprovodné materiály:
Zachovat vlastnictví všech identifikátorů URI. Selhání vlastnictví jednoho z identifikátorů URI přesměrování může vést k ohrožení zabezpečení aplikace.
Ujistěte se, že jsou všechny záznamy DNS pravidelně aktualizovány a monitorovány pro změny.
Nepoužívejte adresy URL odpovědí se zástupnými cardy ani nezabezpečená schémata identifikátorů URI, jako je http nebo URN.
Udržujte seznam malý. Oříznout všechny nepotřebné identifikátory URI. Pokud je to možné, aktualizujte adresy URL z http na https.
Implicitní konfigurace toku
Scénáře, které vyžadují implicitní tok, teď můžou pomocí toku kódu ověřování snížit riziko ohrožení spojeného s implicitními zneužitími toku. V části Ověřování pro aplikaci na webu Azure Portal musí být pro aplikaci vybrána platforma a pak je možné nastavit vlastnost Přístupové tokeny (používané pro implicitní toky ).
Zvažte následující doprovodné materiály související s implicitními toky:
Zjistěte, jestli se vyžaduje implicitní tok. Nepoužívejte implicitní tok, pokud to není explicitně povinné.
Pokud byla aplikace nakonfigurovaná tak, aby přijímala přístupové tokeny pomocí implicitního toku, ale aktivně je nepoužívá, vypněte nastavení pro ochranu před zneužitím.
Pro platné scénáře implicitního toku používejte samostatné aplikace.
URI ID aplikace (také známý jako identifikátor URI)
Vlastnost identifikátoru URI ID aplikace určuje globálně jedinečný identifikátor URI použitý k identifikaci webového rozhraní API. Jedná se o předponu hodnoty oboru v požadavcích na Microsoft Entra. Je to také hodnota deklarace příjemce (aud) v přístupových tokenech verze 1.0. U víceklientských aplikací musí být hodnota také globálně jedinečná. Označuje se také jako identifikátor URI . V části Vystavení rozhraní API pro aplikaci na webu Azure Portal je možné definovat vlastnost identifikátoru URI ID aplikace.
Osvědčené postupy pro definování URI ID aplikace pro identifikaci se mění v závislosti na tom, zda aplikace vydává přístupové tokeny v1.0 nebo v2.0. Pokud si nejste jistí, zda aplikace vydává přístupové tokeny verze v1.0, zkontrolujte manifest aplikace requestedAccessTokenVersion. Hodnota null nebo 1 označuje, že aplikace přijímá přístupové tokeny v1.0. Hodnota 2 označuje, že aplikace přijímá přístupové tokeny v2.0.
Pro aplikace, které používají v1.0 přístupové tokeny, by se měly použít pouze výchozí URI. Výchozí identifikátory URI jsou api://<appId> a api://<tenantId>/<appId>. – Nakonfigurujte nonDefaultUriAddition omezení v zásadách správy aplikací , aby bylo možné tento osvědčený postup vynutit pro budoucí aktualizace aplikací ve vaší organizaci.
U aplikací, jimž jsou vydány přístupové tokeny v2.0, použijte při definování identifikátoru URI ID aplikace následující pokyny:
Doporučují se schémata URI api nebo https. Nastavte vlastnost v podporovaných formátech, aby nedocházelo ke kolizím identifikátorů URI ve vaší organizaci. Nepoužívejte zástupné cardy.
Použijte ověřenou doménu vaší organizace.
Udržujte inventář identifikátorů URI ve vaší organizaci, které pomáhají udržovat zabezpečení.
Podporují se následující formáty rozhraní API a identifikátoru URI ID aplikace založené na schématu HTTP. Nahraďte zástupné hodnoty, jak je popsáno v seznamu za tabulkou.
Podporované ID aplikace Formáty identifikátorů URI
Pokud použijete schéma api:// , přidáte řetězcovou hodnotu přímo za "api://". Například <.> Tato hodnota řetězce může být IDENTIFIKÁTOR GUID nebo libovolný řetězec. Pokud přidáte hodnotu GUID, musí se shodovat s ID aplikace nebo ID tenanta. Pokud použijete řetězcovou hodnotu, musí použít buď ověřenou vlastní doménu, nebo počáteční doménu vašeho tenanta.
Doporučujeme použít api://< appId>.
Důležité
Hodnota identifikátoru URI ID aplikace nesmí končit znakem lomítka "/".
Důležité
Hodnota identifikátoru URI ID aplikace musí být v rámci vašeho tenanta jedinečná.
Verze přístupového tokenu
Tato část se vztahuje pouze na aplikace využívající zdroje – to znamená aplikace, které fungují jako cílová aplikace v přístupových tokenách. Aplikace prostředků jsou obvykle webová rozhraní API. Pokud aplikace funguje jenom jako klient (což znamená, že získává tokeny pro odesílání do prostředků, jako je Microsoft Graph), tato část se nepoužije.
Aplikace prostředků, které mají nakonfigurované vlastní URI identifikátoru, by měly používat formát přístupového tokenu verze 2.0. Pokud chcete zkontrolovat, jestli má aplikace používat přístupové tokeny verze 2.0, podívejte se na identifierUris vlastnost na stránce manifestu registrace aplikací pro aplikaci.
Pokud jsou nakonfigurované nějaké hodnoty, které nejsou ve formátu api://{appId} nebo api://{tenantId}/{appId}, pak by aplikace měla používat přístupové tokeny verze 2.0.
Pokud chcete upgradovat na přístupové tokeny verze 2.0, nejprve se ujistěte, že aplikace dokáže zpracovávat deklarace identity tokenů verze 2.0. Potom pomocí editoru manifestu aktualizujte verzi přístupového tokenu, která aplikace vydá.
Po aktualizaci konfigurace aplikace na použití tokenů v2.0 se ujistěte, že je logika ověření cílové skupiny aplikace upravena tak, aby přijímala pouze její appId.
Zámek vlastností instance aplikace
Pokud má aplikace nakonfigurovaného služebního principála v tenantovi, může tento služební principál přizpůsobit správce tenanta. To platí bez ohledu na to, zda se jedná o domovského tenanta aplikace nebo externího tenanta. Tyto možnosti přizpůsobení můžou umožňovat úpravy, které vlastník aplikace neočekáoval, což vede k rizikům zabezpečení. Do služby lze například přidat přihlašovací údaje, i když by přihlašovací údaje měly být obvykle vlastněny a řízeny vývojářem a vlastníkem aplikace.
Aby se toto riziko snížilo, měly by aplikace nakonfigurovat zámek instance aplikace. Při konfiguraci zámku instance aplikace vždy zamkněte všechny citlivé vlastnosti, které jsou k dispozici. Konfigurace této vlastnosti je obzvláště důležitá pro víceklientských aplikací – to znamená, že aplikace používané v několika tenantech nebo organizacích – ale můžou a měly by být nastaveny všemi aplikacemi.
Povolení
Aplikace může být potřeba udělit oprávnění pro přístup k chráněným prostředkům nebo rozhraním API. Při žádosti o oprávnění vždy zajistěte následující:
Dodržujte zásady nejnižších oprávnění . Požádejte pouze o oprávnění, které uděluje nejmenší přístup potřebný k provedení akce, kterou musí aplikace provést. Pokud voláte Microsoft Graph, pomocí dokumentace k rozhraní API identifikujte nejnižší oprávnění pro dané volání rozhraní API. Pravidelně kontrolujte oprávnění vaší aplikace a zkontrolujte, jestli je k dispozici méně privilegovaná možnost. Pokud už aplikace nepotřebuje oprávnění, odeberte ji.
Vlastníci můžou spravovat všechny aspekty registrované aplikace. Je důležité pravidelně kontrolovat vlastnictví všech aplikací v organizaci. Další informace naleznete v tématu Microsoft Entra access reviews. V části Vlastníci aplikace na webu Azure Portal je možné spravovat vlastníky aplikace.
Zvažte následující pokyny týkající se určení vlastníků aplikací:
Vlastnictví aplikace by mělo být zachováno v minimální skupině lidí v organizaci.
Správce by měl seznam vlastníků zkontrolovat jednou za několik měsíců, aby se ujistil, že vlastníci jsou stále součástí organizace a měli by stále vlastnit aplikaci.
Zkontrolovat doporučení Entra
Funkce doporučení Microsoft Entra pomáhá monitorovat stav vašeho tenanta, takže nemusíte. Tato doporučení pomáhají zajistit, aby váš tenant byl v zabezpečeném a zdravém stavu a zároveň vám pomohl maximalizovat hodnotu funkcí dostupných v Microsoft Entra ID. Pravidelně kontrolujte všechna aktivní doporučení Microsoft Entra, která se týkají vlastností aplikace nebo konfigurace aplikace, aby byl ekosystém vaší aplikace v pořádku.
Váš názor
Byla tato stránka užitečná?
No
Need help with this topic?
Want to try using Ask Learn to clarify or guide you through this topic?
Tento modul se zaměřuje na efektivní správu identit a vylepšení zabezpečení ve službě Microsoft Enterprise Identity a zajišťuje ochranu uživatelů, skupin a externích identit před bezpečnostními hrozbami a neoprávněným přístupem.
