Acquisire l'autorizzazione per accedere alle risorse

Questo articolo aiuta, in qualità di sviluppatore, a comprendere come garantire al meglio Zero Trust durante l'acquisizione delle autorizzazioni di accesso alle risorse per l'applicazione. Per accedere a risorse protette come posta elettronica o dati del calendario, l'applicazione necessita dell'autorizzazione del proprietario della risorsa. Il proprietario della risorsa può fornire il consenso o negare la richiesta dell'app. L'app riceve un token di accesso quando il proprietario della risorsa concede il consenso; l'app non riceve un token di accesso quando il proprietario della risorsa nega l'accesso.

Revisione concettuale

È possibile usare Microsoft Identity Platform per autenticare e autorizzare le applicazioni e gestire autorizzazioni e consenso. Si inizierà con alcuni concetti:

• L'autenticazione (talvolta abbreviata in AuthN) è il processo di dimostrazione che l'identità richiesta è accurata. Microsoft Identity Platform usa il protocollo OpenID Connessione per la gestione dell'autenticazione. L'autorizzazione (talvolta abbreviata in AuthZ) concede a un'entità autenticata l'autorizzazione per eseguire un'operazione. Specifica i dati a cui l'entità autenticata può accedere. Microsoft Identity Platform usa il protocollo OAuth2.0 per la gestione dell'autorizzazione. Le opzioni di autorizzazione includono elenchi di controllo di accesso (ACL), controllo degli accessi in base al ruolo e controllo di accesso degli attributi. L'autenticazione è spesso un fattore di autorizzazione.

• L'accesso delegato (che agisce per conto di un utente connesso) o l'accesso diretto (che agisce solo come identità dell'applicazione) consente all'applicazione di accedere ai dati. L'accesso delegato richiede autorizzazioni delegate (note anche come ambiti); il client e l'utente devono essere autorizzati separatamente per effettuare la richiesta. L'accesso diretto potrebbe richiedere autorizzazioni dell'applicazione (note anche come ruoli dell'app). Quando i ruoli dell'app vengono concessi alle applicazioni, possono essere chiamate autorizzazioni per le applicazioni.

• Le autorizzazioni delegate, usate con accesso delegato, consentono a un'applicazione di agire per conto di un utente, accedendo solo a ciò che l'utente può accedere. L'autorizzazione dell'applicazione, usata con accesso diretto, consente a un'applicazione di accedere ai dati a cui è associata l'autorizzazione. Solo gli amministratori e i proprietari delle entità servizio possono fornire il consenso alle autorizzazioni dell'applicazione.

• Il consenso è il modo in cui le applicazioni ricevono le autorizzazioni. Gli utenti o gli amministratori autorizzano un'applicazione ad accedere a una risorsa protetta. Una richiesta di consenso elenca le autorizzazioni richieste dall'applicazione insieme alle informazioni sull'editore.

• La preautenticazione è il modo in cui i proprietari delle applicazioni delle risorse concedono l'accesso alle app client. Possono farlo nel portale di Azure o usando PowerShell e API come Microsoft Graph. Possono concedere autorizzazioni per le risorse senza richiedere agli utenti di visualizzare una richiesta di consenso per il set di autorizzazioni pre-autorizzate .

Differenza tra l'autorizzazione delegata e l'autorizzazione dell'applicazione

Le applicazioni funzionano in due modalità: quando un utente è presente (autorizzazione delegata) e quando non è presente alcun utente (autorizzazione dell'applicazione). Quando c'è un utente davanti a un'applicazione, è necessario agire per conto dell'utente; non si dovrebbe agire per conto dell'applicazione stessa. Quando un utente indirizza l'applicazione, funge da delegato per tale utente. Si ottiene l'autorizzazione per agire per conto dell'utente identificato dal token.

Le applicazioni di tipo di servizio (attività in background, daemon, processi da server a server) non hanno utenti che possono identificarsi o digitare una password. Richiedono un'autorizzazione dell'applicazione per agire per conto di se stesso (per conto dell'applicazione di servizio).

Procedure consigliate per l'autorizzazione dell'applicazione Zero Trust

L'approccio di autorizzazione ha l'autenticazione come componente quando ci si connette a un utente presente all'applicazione e alla risorsa che si sta chiamando. Quando l'applicazione agisce per conto di un utente, non è attendibile un'applicazione chiamante per indicare chi è l'utente o lasciare che l'applicazione decida chi è l'utente. Microsoft Entra ID verifica e fornisce direttamente informazioni sull'utente nel token.

Quando è necessario consentire all'applicazione di chiamare un'API o autorizzare l'applicazione in modo che l'applicazione possa accedere a una risorsa, gli schemi di autorizzazione moderni possono richiedere l'autorizzazione tramite un framework di autorizzazione e consenso. Procedure consigliate per la sicurezza di riferimento per le proprietà dell'applicazione che includono URI di reindirizzamento, token di accesso (usati per flussi impliciti), certificati e segreti, URI ID applicazione e proprietà dell'applicazione.

Passaggi successivi

• Personalizzare i token descrive le informazioni che è possibile ricevere nei token di Microsoft Entra. Spiega come personalizzare i token per migliorare la flessibilità e il controllo aumentando al contempo la sicurezza senza attendibilità delle applicazioni con privilegi minimi.
• Configurare le attestazioni di gruppo e i ruoli dell'app nei token illustra come configurare le app con definizioni di ruolo dell'app e assegnare gruppi di sicurezza ai ruoli dell'app. Questi metodi consentono di migliorare la flessibilità e il controllo aumentando la sicurezza senza attendibilità delle applicazioni con privilegi minimi.
• Sviluppare una strategia di autorizzazioni delegate consente di implementare l'approccio migliore per gestire le autorizzazioni nell'applicazione e sviluppare usando i principi Zero Trust.
• Sviluppare una strategia di autorizzazioni per le applicazioni consente di decidere l'approccio alle autorizzazioni dell'applicazione per la gestione delle credenziali.
• Fornire le credenziali di identità dell'applicazione quando non è presente alcun utente spiega perché le identità gestite per le risorse di Azure sono le procedure consigliate per le credenziali client per i servizi (applicazioni non utente) in Azure.
• Le procedure consigliate per l'autorizzazione consentono di implementare i modelli di autorizzazione, autorizzazione e consenso ottimali per le applicazioni.
• Usare le procedure consigliate per lo sviluppo di identità Zero Trust e di gestione degli accessi nel ciclo di vita di sviluppo delle applicazioni per creare applicazioni sicure.
• La creazione di app con un approccio Zero Trust all'identità continua dall'articolo Procedure consigliate per lo sviluppo di identità e gestione degli accessi Zero Trust per usare un approccio Zero Trust all'identità nel ciclo di vita dello sviluppo software (SDLC).