Vývoj strategie oprávnění aplikace

  • Článek

Když se naučíte vyvíjet pomocí zásad nulová důvěra (Zero Trust), přečtěte si tento článek po kontrole získání autorizace pro přístup k prostředkům a vývoji strategie delegovaných oprávnění. Definujte přístup oprávnění aplikace ke správě přihlašovacích údajů, když k ověřování a autorizaci aplikací a správě oprávnění a souhlasu používáte platformu Microsoft Identity Platform.

Pokud se žádný uživatel nezapomene, nebudete mít efektivní model oprávnění, protože aplikace má vždy stejná oprávnění jako konkrétní uživatel vaší aplikace.

  • Aplikace prokáže, že se jedná o aplikaci, která žádá o oprávnění. Vaše aplikace prokáže svou vlastní identitu pomocí jedné z následujících metod:

    • certifikát, který je nejlepší volbou, nebo
    • tajného klíče v sofistikovaném systému správy tajných kódů, nebo
    • Tajný kód při vývoji služeb v Azure a používání spravovaných identit pro prostředky Azure. Viz následující část Správa přihlašovacích údajů aplikace.

  • Aplikace vždy vyžaduje předběžný souhlas správce. Vaše aplikace požádá o toto oprávnění s oborem .default . Požádá o oprávnění, která správce přiřadí k aplikaci. Bez ohledu na pojmenování pro jakýkoli konkrétní obor se tato oprávnění ve výchozím nastavení vztahují na všechny uživatele.

  • Funkce transuživatele. Ve výchozím nastavení User.ReadWrite.All umožňuje vaší aplikaci aktualizovat profil každého uživatele, a to i Calendar.Read. Jako oprávnění aplikace umožňuje aplikaci číst kalendář každého uživatele v tenantovi.

  • Oprávnění udělená aplikaci jsou vždy použitá oprávnění. Na rozdíl od delegovaného oprávnění nejsou oprávnění aplikace svázaná tím, co může konkrétní uživatel dělat.

Omezení oprávnění aplikace

Existují tři způsoby omezení aplikace na méně než globální přístup.

  • Aplikace Microsoft Teams mají souhlas specifický pro prostředky (RSC), který aplikaci umožňuje přístup ke konkrétnímu týmu, a ne ke všem týmům v podniku. RSC je integrace rozhraní Microsoft Teams a rozhraní Microsoft Graph API, která vaší aplikaci umožňuje používat koncové body rozhraní API a spravovat konkrétní prostředky. Jeho model oprávnění umožňuje vlastníkům teams a chatu udělit souhlas pro vaši aplikaci pro přístup k datům teams a chatu a jejich úpravám.

  • Správci Microsoft Exchange můžou vytvářet zásady aplikace Exchange, které omezují přístup aplikací k určitým poštovním schránkám pomocí skriptu PowerShellu. Můžou omezit konkrétní aplikaci na konkrétní poštovní schránky s Calendar.Read přístupem nebo Mail.Read přístup. Díky tomu můžete například vytvořit automatizaci, která může číst jenom jednu poštovní schránku nebo odesílat poštu jenom z jedné poštovní schránky, a ne od všech uživatelů v podniku.

  • SharePoint má weby.Selected as a specific scope to allow granular permissions for accessing SharePoint with an application. Volba Sites.Selected aplikace místo jednoho z ostatních oprávnění ve výchozím nastavení způsobí, že vaše aplikace nebude mít přístup k žádným kolekcím sharepointových webů. Správce používá koncový bod oprávnění webu k udělení oprávnění ke čtení, zápisu nebo čtení a zápisu vaší aplikaci.

Správa přihlašovacích údajů aplikací

Hygiena přihlašovacích údajů může zajistit, aby se vaše aplikace rychle zotavila z potenciálního porušení zabezpečení. Následující osvědčené postupy vás provedou vývojem aplikací, které provádějí detekci a nápravu a zároveň se vyhýbají výpadkům a ovlivňují oprávněné uživatele. Tato doporučení podporují zásadu nulová důvěra (Zero Trust) předpokladu porušení zabezpečení při přípravě reakce na incident zabezpečení.

  • Odeberte všechny tajné kódy z kódu a konfigurace. Když používáte platformu Azure, umístěte tajné kódy do trezoru klíčů a získejte k nim přístup prostřednictvím spravovaných identit pro prostředky Azure. Pokud dojde k ohrožení zabezpečení, vytvořte svůj kód odolný proti obměně tajných kódů. Správci IT můžou odebírat a obměňovat tajné kódy a certifikáty bez odebrání aplikace nebo ovlivnění legitimních uživatelů.

  • Místo tajných klíčů klienta používejte certifikáty, pokud není k dispozici zabezpečený proces pro správu tajných kódů. Útočníci vědí, že tajné kódy klientů mají tendenci být méně bezpečné a nevracené použití tajných kódů je obtížné sledovat. Certifikáty je možné lépe spravovat a odvolat, pokud dojde k ohrožení zabezpečení. Pokud používáte tajné kódy, sestavte nebo použijte zabezpečený proces nasazení bez dotykového ovládání a proces přechodu na ně. Používejte tajné kódy s nastaveným časovým obdobím vypršení platnosti (například jeden rok, dva roky) a vyhněte se nikdy vypršení platnosti.

  • Pravidelně zahrnujte certifikáty a tajné kódy, aby se zajistila odolnost proti chybám ve vaší aplikaci, a vyhnete se výpadku kvůli nouzovému přechodu.

Další kroky