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 Connect 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 permessi delegati (noti anche come scopes). Il client e l'utente devono essere autorizzati separatamente per effettuare la richiesta. L'accesso diretto potrebbe richiedere le autorizzazioni dell'applicazione (note anche come ruoli dell'app). Quando le applicazioni ricevono ruoli dell'app, 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 dei principali di servizio possono concedere il consenso ai permessi applicativi.

• 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 con 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 è presente un utente davanti a un'applicazione, è necessario agire per conto di tale 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 applicativa per agire per conto proprio (per conto del servizio applicativo).

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 un'applicazione agisce per conto di un utente, non ci fidiamo di un'applicazione chiamante per dirci chi sia l'utente né di permettere che sia l'applicazione a decidere chi sia 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 Zero Trust dell'applicazione con privilegi minimi.
• Configurare le attestazioni di gruppo e i ruoli dell'app nei token illustra come configurare le app con definizioni di ruoli applicativi e assegnare gruppi di sicurezza ai ruoli applicativi. Questi metodi consentono di migliorare la flessibilità e il controllo aumentando la sicurezza zero trust dell'applicazione con privilegi minimi.
• Sviluppare una strategia di autorizzazioni delegate consente di implementare l'approccio migliore per la gestione delle autorizzazioni nell'applicazione e lo sviluppo con 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.
• Utilizzare le migliori pratiche di sviluppo per la gestione delle identità e degli accessi Zero Trust nel ciclo 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).