Gestione delle identità e degli accessi delle applicazioni

  • Articolo

Questo articolo descrive considerazioni e consigli che i proprietari e gli sviluppatori di applicazioni possono usare per progettare la gestione delle identità e degli accessi per le applicazioni native del cloud.

Se il team esegue la migrazione o crea applicazioni native del cloud, è necessario considerare i requisiti di autenticazione e accesso per le applicazioni. Questi requisiti determinano il modo in cui gli utenti eseguono l'autenticazione alle applicazioni e il modo in cui le risorse dell'applicazione eseguono l'autenticazione tra loro, ad esempio quando un'applicazione Web accede a un database SQL.

Nell'area di progettazione di automazione della piattaforma e DevOps è consigliabile che il team dell'applicazione passi i carichi di lavoro a vendita di abbonamenti. Come parte del processo di distribuzione automatica delle sottoscrizioni, il team dell'applicazione deve fornire i requisiti di identità e accesso al team della piattaforma in modo da poter creare le sottoscrizioni appropriate. I proprietari delle applicazioni sono responsabili della gestione delle identità e degli accessi delle singole applicazioni. Devono gestire l'applicazione usando i servizi centralizzati forniti dal team della piattaforma.

Considerazioni relative alla progettazione

Per ridurre il rischio di accesso non autorizzato alle applicazioni, incorporare le considerazioni seguenti nella progettazione.

  • Esistono diversi standard di autenticazione e autorizzazione, ad esempio OAuth 2.0, OpenID Connessione, token Web JSON (JWT) e SAML (Security Assertion Markup Language). Determinare quali standard di autenticazione e autorizzazione usare per l'applicazione.

  • Quando si richiede una zona di destinazione dell'applicazione dal team della piattaforma, è possibile assicurarsi che creino le sottoscrizioni appropriate ponendo loro le domande seguenti:

    • In che modo gli utenti finali eseguono l'autenticazione e accedono all'applicazione?

    • Chi necessita delle autorizzazioni di controllo degli accessi in base al ruolo per le risorse e i servizi usati dall'applicazione?

    • I ruoli predefiniti esistenti coprono i requisiti di accesso del controllo degli accessi in base al ruolo sia per l'accesso al piano di controllo che per l'accesso al piano dati oppure è necessario creare nuovi ruoli personalizzati?

    • Il team della piattaforma ha implementato i criteri di conformità che potrebbero causare problemi con l'applicazione?

    • Quali componenti dell'applicazione devono comunicare tra loro?

    • Esistono requisiti per l'accesso alle risorse condivise, ad esempio Microsoft Entra Domain Services, distribuite nell'area di destinazione della piattaforma?

Azure Key Vault e identità gestite

  • Le violazioni della sicurezza delle risorse del cloud pubblico spesso derivano da credenziali perse incorporate nel codice o in altro testo. È possibile usare identità gestite e Key Vault per implementare l'accesso a livello di codice e ridurre il rischio di furto di credenziali.

  • Se l'applicazione o il carico di lavoro richiede un servizio per archiviare in modo sicuro le credenziali, è possibile usare Key Vault per gestire segreti, chiavi e certificati.

  • Per evitare di avere credenziali nel codice, è possibile usare le identità gestite con le macchine virtuali di Azure per eseguire l'autenticazione a qualsiasi servizio che supporti l'autenticazione con ID Microsoft Entra. Per altre informazioni, vedere Usare le identità gestite per le risorse di Azure in una macchina virtuale per acquisire un token di accesso.

  • Le identità gestite forniscono un'entità di identità gestita automaticamente che le applicazioni e le risorse usano quando si connettono alle risorse che supportano l'autenticazione con ID Microsoft Entra. Le applicazioni possono usare identità gestite per ottenere i token ID di Microsoft Entra senza dover gestire le credenziali.

    • È possibile usare identità gestite assegnate dal sistema o assegnate dall'utente.

    • È facile confondere il modo in cui le entità servizio e le identità gestite accedono alle risorse di Azure. Per comprendere la differenza tra i due, vedere Demystifying service principals- Managed identities (Demystifying Service Principals- Managed Identities).

    • Se possibile, usare le identità gestite per supportare l'autenticazione anziché usare entità servizio e registrazioni dell'app Microsoft Entra ID. Per creare entità servizio e registrazioni di app, è necessario disporre dei ruoli Application Amministrazione istrator o Application Developer RBAC. Questi ruoli con privilegi vengono in genere assegnati al team della piattaforma o al team di identità. Usare le identità gestite per eliminare la necessità del team della piattaforma di creare entità servizio e registrazioni di app per il team dell'applicazione.

    • È possibile usare le identità gestite per eseguire l'autenticazione a qualsiasi servizio che supporti l'autenticazione di Microsoft Entra. Tuttavia, non tutti i servizi supportano le identità gestite per accedere ad altri servizi. Per alcuni servizi, potrebbe essere necessario archiviare le credenziali. È consigliabile archiviare le credenziali in modo sicuro, evitare di condividere le credenziali con altri servizi e seguire il principio dei privilegi minimi. Per altre informazioni, vedere Servizi di Azure che possono usare identità gestite per accedere ad altri servizi.

    • È possibile usare le identità gestite con macchine virtuali (VM) di Azure per eseguire l'autenticazione a qualsiasi servizio che supporti l'autenticazione con ID Entra di Microsoft. Per altre informazioni, vedere Usare le identità gestite per le risorse di Azure in una macchina virtuale per acquisire un token di accesso.

    • Esistono restrizioni per lo spostamento di risorse con identità gestite tra sottoscrizioni e aree. Ad esempio, è possibile spostare le risorse tra sottoscrizioni o aree per una fusione, un'acquisizione o un ricollocamento delle risorse per motivi di sovranità dei dati.

      Se una risorsa di Azure ha identità assegnate dall'utente o assegnate dal sistema, non è possibile trasferire la risorsa in un'altra sottoscrizione o area di Azure. È necessario eliminare le identità gestite prima di spostare la risorsa. Dopo lo spostamento, è necessario ricreare le identità gestite e assegnarle alla risorsa. Per altre informazioni, vedere Spostare le risorse in un gruppo di risorse o una sottoscrizione nuovi.

    • Se si sposta una sottoscrizione da una directory a un'altra, le identità gestite non vengono mantenute. È necessario spostare la risorsa e quindi ricreare manualmente le identità gestite.

    • Analogamente alle assegnazioni di ruolo controllo degli accessi in base al ruolo degli utenti, seguire il principio dei privilegi minimi quando si concede a una risorsa l'accesso a un'identità gestita.

Utenti esterni

È possibile valutare gli scenari che comportano la configurazione di utenti, clienti o partner esterni in modo che possano accedere alle risorse. Determinare se questi scenari coinvolgono configurazioni di Microsoft Entra B2B o Azure Active Directory B2C (Azure AD B2C). Per altre informazioni, vedere Panoramica delle Microsoft Entra per ID esterno.

Suggerimenti per la progettazione

Quando si progettano l'identità e la gestione degli accessi delle applicazioni, prendere in considerazione i consigli seguenti.

OpenID Connect

Se il team dell'applicazione usa pipeline di integrazione continua e recapito continuo (CI/CD) per distribuire applicazioni a livello di codice, configurare OpenID Connessione l'autenticazione nei servizi di Azure. OpenID Connessione usa un token temporaneo senza credenziali per l'autenticazione nei servizi di Azure. Per altre informazioni, vedere Federazione dell'identità del carico di lavoro.

Se OpenID Connessione non è supportato, creare un'entità servizio e assegnare le autorizzazioni necessarie per consentire la distribuzione dell'infrastruttura o del codice dell'applicazione. Per altre informazioni, vedere il modulo di training Autenticare la pipeline di distribuzione di Azure usando le entità servizio.

Controllo degli accessi in base agli attributi

Per limitare ulteriormente l'accesso e impedire l'accesso non autorizzato ai dati, usare il controllo degli accessi in base all'attributo, se supportato, ad esempio con Archiviazione BLOB di Azure.

Accesso alle macchine virtuali

Laddove possibile, usare le identità id di Microsoft Entra per controllare l'accesso alle macchine virtuali di Azure. Usare Microsoft Entra ID anziché l'autenticazione locale per fornire l'accesso alle macchine virtuali, sfruttando l'accesso condizionale Microsoft Entra, la registrazione di controllo e l'autenticazione a più fattori (MFA) di Microsoft Entra. Questa configurazione riduce il rischio di attacchi che sfruttano i servizi di autenticazione locale non sicuri. Per altre informazioni, vedere Accedere a una macchina virtuale Linux in Azure usando Microsoft Entra ID e OpenSSH e Accedere a una macchina virtuale Windows in Azure usando l'ID Microsoft Entra, incluso l'ID senza password.

Microsoft Identity Platform

  • Quando gli sviluppatori creano un'applicazione nativa del cloud, devono usare il Microsoft Identity Platform per sviluppatori come provider di identità per le applicazioni. Microsoft Identity Platform fornisce un openID Connessione servizio di autenticazione conforme allo standard che gli sviluppatori possono usare per autenticare diversi tipi di identità, tra cui:

    • Account aziendali o degli istituti di istruzione, di cui viene effettuato il provisioning tramite Microsoft Entra ID

    • Account Microsoft personali (Skype, Xbox, Outlook.com)

    • Account di social networking o locali tramite Microsoft Entra ID

  • L'elenco di controllo delle procedure consigliate e delle raccomandazioni di Microsoft Identity Platform fornisce indicazioni sull'integrazione efficace dell'applicazione con Microsoft Identity Platform.

Identità gestite

  • Per abilitare l'accesso tra le risorse di Azure che non devono usare le credenziali, usare le identità gestite.

  • Non è consigliabile condividere credenziali o identità gestite tra diversi ambienti o applicazioni. Ad esempio, non usare le identità per le risorse di produzione e anche nelle risorse di sviluppo/test, anche per la stessa applicazione. Creare credenziali separate per ogni istanza di un'applicazione per ridurre la probabilità che un'istanza di test compromessa influisca sui dati di produzione. Le credenziali separate semplificano anche la revoca delle credenziali quando non sono più necessarie.

  • Quando è necessario usare le identità gestite su larga scala, usare un'identità gestita assegnata dall'utente per ogni tipo di risorsa in ogni area. Questo approccio impedisce una varianza delle identità. Ad esempio, l'agente di Monitoraggio di Azure richiede un'identità gestita nelle macchine virtuali di Azure monitorate, che può causare la creazione e l'eliminazione di un numero considerevole di identità da parte di Microsoft Entra ID. È possibile creare identità gestite assegnate dall'utente una sola volta e condividerle tra più macchine virtuali. Usare Criteri di Azure per implementare questa raccomandazione.

Key Vault

  • È possibile usare Key Vault per gestire segreti, chiavi, certificati usati dalle applicazioni.

  • È consigliabile usare insiemi di credenziali delle chiavi separati per ogni ambiente dell'applicazione (sviluppo, preproduzione, produzione) in ogni area. Usare il controllo degli accessi in base al ruolo per gestire l'accesso a segreti, chiavi e certificati (operazioni del piano dati) e l'accesso a Key Vault (piano di controllo). Distribuire insiemi di credenziali delle chiavi con segreti dell'applicazione nelle zone di destinazione dell'applicazione.

Proxy dell’applicazione di Microsoft Entra

  • Per accedere alle applicazioni che usano l'autenticazione locale in remoto tramite Microsoft Entra ID, usare il proxy dell'applicazione Microsoft Entra. Microsoft Entra application proxy fornisce accesso remoto sicuro alle applicazioni Web locali, incluse le applicazioni che usano protocolli di autenticazione meno recenti. Dopo un accesso Single Sign-On a Microsoft Entra ID, gli utenti possono accedere alle applicazioni cloud e locali tramite un URL esterno o un portale applicazioni interno.

    • È possibile distribuire microsoft Entra application proxy come singola istanza in un tenant di Microsoft Entra ID. Per la configurazione è necessario che i ruoli id Microsoft Entra id Amministrazione istrator o globale Amministrazione istrator con privilegi. Se l'organizzazione usa la democratizzazione delle sottoscrizioni come modello di assegnazione di ruolo, i proprietari di applicazioni potrebbero non avere le autorizzazioni necessarie per configurare il proxy dell'applicazione Microsoft Entra. In questo caso, il team della piattaforma deve configurare il proxy dell'applicazione Microsoft Entra per il proprietario dell'applicazione.

    • Se si usano pipeline di distribuzione CI/CD con autorizzazioni sufficienti, i proprietari di applicazioni possono configurare il proxy dell'applicazione Microsoft Entra usando l'API Microsoft Graph.

  • Se l'applicazione usa protocolli legacy, ad esempio Kerberos, assicurarsi che la zona di destinazione dell'applicazione disponga della connettività di rete ai controller di dominio nella sottoscrizione di Microsoft Identity Platform.

Passaggi successivi

Organizzazione delle risorse