Condividi tramite

Resilienza tramite le procedure consigliate per i developer

Importante

A partire dal 1° maggio 2025, Azure Active Directory B2C (Azure AD B2C) non è più disponibile per l'acquisto di nuovi clienti. Per altre informazioni, vedere Azure AD B2C è ancora disponibile per l'acquisto? nelle domande frequenti.

In questo articolo è possibile trarre vantaggio dalla nostra esperienza di lavoro con clienti di grandi dimensioni. È possibile prendere in considerazione questi consigli nella progettazione e nell'implementazione dei servizi.

Libreria di Autenticazione Microsoft

La Microsoft Authentication Library (MSAL) e la libreria di autenticazione Web di Microsoft Identity per ASP.NET semplificano l'acquisizione, la gestione, la memorizzazione nella cache e l'aggiornamento dei token richiesti da un'applicazione. Queste librerie sono ottimizzate in modo specifico per supportare Microsoft Identity, incluse le funzionalità che migliorano la resilienza delle applicazioni.

I developer devono adottare le versioni più recenti di MSAL e rimanere aggiornati. Vedere come aumentare la resilienza dell'autenticazione e dell'autorizzazione nelle applicazioni. Se possibile, evitare di implementare il proprio stack di autenticazione. Usare invece librerie ben consolidate.

Ottimizzare le operazioni di lettura e scrittura sul directory

Il servizio directory di Azure AD B2C supporta miliardi di autenticazioni al giorno, con un alto tasso di letture al secondo. Ottimizzare le operazioni di scrittura per ridurre al minimo le dipendenze e aumentare la resilienza.

Come ottimizzare le letture e le scritture della directory

  • Evitare operazioni di scrittura nella directory al momento dell'accesso: evitare di eseguire un'operazione di scrittura senza una precondizione (un'istruzione if) nei criteri personalizzati. Un caso d'uso che richiede una scrittura durante un accesso è la migrazione JIT delle password utente. Non richiedere un'operazione di scrittura per ogni accesso. Le precondizioni in un percorso utente sono:

    <Precondition Type="ClaimEquals" ExecuteActionsIf="true"> 
<Value>requiresMigration</Value>
...
<Precondition/>

  • Informazioni sulla limitazione delle richieste: la directory implementa regole di limitazione delle richieste a livello di applicazione e tenant. Esistono ulteriori limiti di frequenza per le operazioni Read/GET, Write/POST, Update/PUT e Delete/DELETE. Ogni operazione presenta limiti diversi.

    • Una scrittura durante l'accesso rientra in una richiesta POST per i nuovi utenti o una richiesta PUT per gli utenti correnti.
    • Una policy personalizzata che crea o aggiorna un utente a ogni accesso dell'utente può raggiungere un limite di velocità PUT o POST a livello di applicazione. Gli stessi limiti si applicano durante l'aggiornamento degli oggetti directory tramite Microsoft Entra ID o Microsoft Graph. Analogamente, esaminare le letture per mantenere il numero di letture al minimo in ogni accesso.
    • Calcolare il carico di picco per stimare la frequenza delle scritture sulla directory ed evitare la limitazione. Le stime del traffico di picco devono includere stime per azioni come l'iscrizione, l'accesso e l'autenticazione a più fattori (MFA). Testare sia il sistema Azure AD B2C sia l'applicazione per il picco del traffico. Azure AD B2C può gestire il carico senza limitazioni, quando le vostre applicazioni o servizi downstream non ne sono in grado.
    • Comprendere e pianificare la sequenza temporale della migrazione. Quando si prevede di eseguire la migrazione degli utenti ad Azure Active Directory B2C usando Microsoft Graph, prendere in considerazione i limiti dell'applicazione e del tenant per calcolare il tempo necessario per completare la migrazione degli utenti. Se si suddivide il processo di creazione utente o lo script usando due applicazioni, è possibile usare il limite per ogni applicazione. Assicurati che rimanga al di sotto della soglia per inquilino.
    • Comprendere gli effetti dell'attività di migrazione su altre applicazioni. Prendere in considerazione il traffico live servito da altre applicazioni dipendenti per assicurarsi di evitare limitazioni al livello di tenant e l'esaurimento delle risorse per la tua applicazione live. Per altre informazioni, vedere le linee guida sulla limitazione delle richieste di Microsoft Graph.
    • Usare un esempio di test di carico per simulare l'iscrizione e l'accesso.
    • Maggiori informazioni sui limiti e sulle restrizioni del servizio Azure AD B2C.

Durate dei token

Se il servizio di autenticazione di Azure AD B2C non è in grado di completare nuove registrazioni e accessi, è comunque possibile fornire una mitigazione per gli utenti che hanno eseguito l'accesso. Con la configurazione, gli utenti che hanno effettuato l'accesso possono utilizzare l'applicazione senza interruzioni fino a quando non effettuano la disconnessione dall'applicazione o la sessione si esaurisce per inattività.

I requisiti aziendali e l'esperienza dell'utente finale determinano la frequenza di aggiornamento dei token per le applicazioni web e applicazioni a pagina singola (SPA).

Estendi durate dei token

  • Applicazioni Web: per le applicazioni Web in cui il token di autenticazione viene convalidato all’accesso, l'applicazione dipende dal cookie di sessione per continuare a estendere la validità della sessione. Consentire agli utenti di rimanere connessi implementando i tempi di sessione in sequenza che si rinnovano in base all'attività dell'utente. Se si verifica un'interruzione del rilascio di token a lungo termine, questi tempi di sessione possono essere aumentati con una configurazione monouso nell'applicazione. Mantenere la durata della sessione al massimo consentito.
  • SPA:un'applicazione a pagina singola può dipendere dai token di accesso per effettuare chiamate alle API. Per le SPA, consigliamo di utilizzare il flusso di codice di autorizzazione con Proof Key for Code Exchange (PKCE) come opzione per consentire all'utente di continuare a utilizzare l'applicazione. Se l'applicazione a pagina singola usa un flusso implicito, valutare la possibilità di eseguire la migrazione al flusso del codice di autorizzazione con PKCE. Eseguire la migrazione dell'applicazione da MSAL.js 1.x a MSAL.js 2.x per ottenere la resilienza delle applicazioni Web. Il flusso implicito non comporta un token di aggiornamento. L'applicazione a pagina singola può usare un elemento nascosto iframe per eseguire nuove richieste di token sull'endpoint di autorizzazione se il browser ha una sessione attiva con Azure Active Directory B2C. Per le SPA, esistono alcune opzioni per consentire all'utente di continuare a utilizzare l'applicazione.
    • Estendere la durata della validità del token di accesso.
    • Costruire la vostra applicazione per utilizzare un API gateway come proxy di autenticazione. In questa configurazione, l'applicazione a pagina singola (SPA) viene caricata senza autenticazione e le chiamate API vengono effettuate al gateway API. Il gateway API invia l'utente tramite un processo di accesso usando una concessione del codice di autorizzazione basata su un criterio e autentica l'utente. La sessione di autenticazione tra il gateway API e il client viene gestita usando un cookie di autenticazione. Il gateway API gestisce le API utilizzando il token ottenuto dal gateway stesso o un altro metodo di autenticazione diretta, come certificati, credenziali del client o chiavi API.
    • Passare all'opzione consigliata. Effettua la migrazione della tua SPA dal sistema di concessione implicita al flusso di codice di autorizzazione, con il supporto per la chiave di prova per lo scambio di codici (PKCE) e la condivisione delle risorse tra origini diverse (CORS).
    • Per le applicazioni per dispositivi mobili, estendere la durata dei token di aggiornamento e di accesso.
  • Applicazioni o microservizi back-end: le applicazioni back-end (daemon) non sono interattive e non si trovano in un contesto utente, pertanto l’eventualità che si verifichino furti di token è diminuita. È consigliabile trovare un equilibrio tra sicurezza e durata e impostare una durata lunga dei token.

Autenticazione unica

Con l'accesso Single Sign-On (SSO), gli utenti accedono una sola volta con un account e ottengono l'accesso alle applicazioni: un'applicazione Web, per dispositivi mobili o un'applicazione a pagina singola, indipendentemente dalla piattaforma o dal nome di dominio. Quando l'utente accede a un'applicazione, Azure Active Directory B2C mantiene una sessione basata su cookie.

Dopo le richieste di autenticazione successive, Azure Active Directory B2C legge e convalida la sessione basata su cookie e rilascia un token di accesso senza chiedere all'utente di eseguire l'accesso. Se l'accesso Single Sign-On è configurato con un ambito limitato in un criterio o in un'applicazione, l'accesso successivo ad altri criteri e applicazioni richiederà un'autenticazione aggiornata.

Configurare SSO

Configurare l'accesso Single Sign-On in modo che sia a livello di tenant (impostazione predefinita) per consentire a diverse applicazioni e flussi utente nel tenant di condividere la stessa sessione utente. La configurazione a livello di tenant offre la massima resilienza all'autenticazione aggiornata.

Procedure di distribuzione sicure

Gli interruzioni più comuni del servizio sono le modifiche al codice e alla configurazione. L'adozione di processi e strumenti di Integrazione Continua e Delivery Continuo (CICD) consente distribuzioni su larga scala e riduce gli errori umani durante il testing e la distribuzione. Adottare CICD per riduzione degli errori, efficienza e coerenza. Azure Pipelines è un esempio di CICD.

Protezione dai bot

Proteggi le tue applicazioni da vulnerabilità note, come attacchi Distributed Denial of Service (DDoS), iniezioni SQL, cross-site scripting, esecuzione di codice remoto e altre documentati in OWASP Top 10. L’implementazione di un Web Application Firewall (WAF) può difendersi da exploit e vulnerabilità comuni.

Segreti

Azure Active Directory B2C usa segreti per applicazioni, API, criteri e crittografia. I segreti proteggono l'autenticazione, le interazioni esterne e l'archiviazione. Il National Institute of Standards and Technology (NIST) si riferisce all'intervallo di tempo di autorizzazione della chiave, usato da entità legittime, come cryptoperiod. Scegliere la lunghezza necessaria di cryptoperiods. Impostare la data di scadenza e aggiornare i segreti prima che scadano.

Implementare la rotazione dei segreti

  • Usare le identità gestite per le risorse supportate per l'autenticazione a qualsiasi servizio che supporti l'autenticazione di Microsoft Entra. Quando si usano le identità gestite, è possibile gestire automaticamente le risorse, inclusa la rotazione delle credenziali.
  • Eseguire un inventario delle chiavi e dei certificati configurati in Azure Active Directory B2C. Questo elenco può includere chiavi usate in criteri personalizzati, API, token ID di firma e certificati per SAML (Security Assertion Markup Language).
  • Utilizzando CICD, ruotare le chiavi segrete che scadranno entro due mesi dalla stagione di punta prevista. Il termine massimo consigliato per il cryptoperiod delle chiavi private associate a un certificato è di un anno.
  • Monitorare e ruotare in modo proattivo le credenziali di accesso all'API, ad esempio password e certificati.

Test dell'API REST

Per la resilienza, il test delle API REST deve includere la verifica dei codici HTTP, payload della risposta, intestazioni e prestazioni. Non utilizzare solo test di percorso positivo e verifica che l'API gestisca correttamente gli scenari problematici.

Piano di test

È consigliabile che il piano di test includa test delle API completi. Per i picchi dovuti a una promozione o a un traffico di festività, rivedere i test di carico con nuove stime. Eseguire test di carico delle API e della rete CDN (Content Delivery Network) in un ambiente di sviluppo e non nell'ambiente di produzione.

Passaggi successivi

  • Last updated on