Condividi tramite


Sviluppare una strategia di autorizzazioni per le applicazioni

Come si apprenderà a sviluppare usando i principi Zero Trust, fare riferimento a questo articolo dopo aver esaminato Acquisire l'autorizzazione per accedere alle risorse e Sviluppare la strategia di autorizzazione delegata. Definire l'approccio alle autorizzazioni dell'applicazione per la gestione delle credenziali quando si usa Microsoft Identity Platform per autenticare e autorizzare le applicazioni e gestire autorizzazioni e consenso.

Quando non è coinvolto alcun utente, non si dispone di un modello di autorizzazione efficace perché l'applicazione riceve sempre le autorizzazioni preassegnate.

  • L'app dimostra che è l'app che richiede l'autorizzazione. L'applicazione dimostra la propria identità con uno dei metodi seguenti:

  • L'app richiede sempre il consenso dell'amministratore anticipato. L'applicazione richiede questa autorizzazione con l'ambito .default . Richiede le autorizzazioni assegnate dall'amministratore all'applicazione.

  • Funzionalità trans utente. Per impostazione predefinita, User.ReadWrite.All consente all'applicazione di aggiornare il profilo di ogni utente. Come autorizzazione dell'applicazione, consente all'applicazione di leggere e aggiornare il profilo di ogni utente nel tenant.

  • Le autorizzazioni concesse all'app sono sempre le autorizzazioni usate. A differenza di un'autorizzazione delegata, le autorizzazioni dell'applicazione non sono vincolate da ciò che può fare qualsiasi utente specifico.

Limitare le autorizzazioni dell'applicazione

Esistono tre modi per limitare un'applicazione a un accesso inferiore a quello globale.

  • Le app di Microsoft Teams hanno il consenso specifico delle risorse (RSC) che consente a un'applicazione di accedere a un team specifico anziché accedere a tutti i team dell'organizzazione. RSC è un'integrazione dell'API Microsoft Teams e Microsoft Graph che consente all'app di usare endpoint API e gestire risorse specifiche. Il modello di autorizzazioni consente ai proprietari di Teams e Chat di concedere all'applicazione il consenso per accedere e modificare i dati di Teams e Chat.

  • Per limitare l'accesso delle app a cassette postali specifiche con uno script di PowerShell, gli amministratori di Microsoft Exchange possono creare criteri delle applicazioni di Exchange. Possono limitare una determinata applicazione a cassette postali specifiche con Calendar.Read o Mail.Read accesso. Ciò consente, ad esempio, di creare un'automazione in grado di leggere solo una cassetta postale o di inviare messaggi solo da una cassetta postale e non da tutti gli utenti dell'organizzazione.

  • Per consentire autorizzazioni granulari per l'accesso a SharePoint con un'applicazione, SharePoint dispone di Sites.Selected come ambito specifico. Scegliere Sites.Selected per l'applicazione anziché uno degli altri risultati delle autorizzazioni, per impostazione predefinita, nelle applicazioni senza accesso alle raccolte siti di SharePoint. L'amministratore usa l'endpoint delle autorizzazioni del sito per concedere le autorizzazioni di lettura, di scrittura o di lettura e scrittura all'applicazione.

Gestire le credenziali delle applicazioni

L'igiene delle credenziali può garantire che l'applicazione si ripristini rapidamente da una potenziale violazione. Le procedure consigliate seguenti consentono di sviluppare applicazioni che eseguono il rilevamento e la correzione evitando tempi di inattività e interessando utenti legittimi. Queste raccomandazioni supportano il principio Zero Trust di presupporre la violazione per preparare l'utente a rispondere a un evento imprevisto di sicurezza.

  • Rimuovere tutti i segreti dal codice e dalla configurazione. Quando si usa la piattaforma Azure, inserire i segreti in Key Vault e accedervi tramite identità gestite per le risorse di Azure. Assicurati che il tuo codice sia resiliente per gestire i cambiamenti dei segreti in caso di compromissione. Gli amministratori IT possono rimuovere e ruotare segreti e certificati senza arrestare l'applicazione o influire sugli utenti legittimi.

  • Usare i certificati anziché i segreti client, a meno che non sia presente un processo sicuro per gestire i segreti. Gli utenti malintenzionati sanno che i segreti client tendono a essere gestiti in modo meno sicuro e che l'utilizzo dei segreti trapelati è difficile da monitorare. I certificati possono essere gestiti meglio e revocati se compromessi. Quando si utilizzano segreti (dati sensibili), creare o utilizzare una distribuzione sicura senza intervento manuale e un processo di aggiornamento continuo per tali segreti. Usare i segreti con un periodo di scadenza impostato (ad esempio, un anno, due anni) ed evitare di non scadere mai.

  • Eseguire regolarmente il rollover di certificati e segreti per creare resilienza nell'applicazione ed evitare interruzioni a causa di un rollover di emergenza.

Passaggi successivi