Sdílet prostřednictvím


Vývoj strategie oprávnění aplikací

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 žádný uživatel není zapojen, nemáte efektivní model oprávnění, protože aplikace má vždy udělená předem přiřazená oprávnění.

  • 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
    • Při vývoji služeb v Azure použijte spravované identity pro prostředky Azure, projděte si 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.

  • Funkce transuživatele. Ve výchozím nastavení User.ReadWrite.All umožňuje aplikaci aktualizovat profil každého uživatele. Jako oprávnění aplikace umožňuje vaší aplikaci číst a aktualizovat profil 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, jak aplikaci omezit 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 pro aplikaci místo jednoho z ostatních výsledků oprávnění ve vaší aplikaci nemá 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í legitimní 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