Resilienza tramite le procedure consigliate per i developer

  • Articolo

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 letture e le scritture della directory

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

Come ottimizzare le letture e le scritture della directory

  • Evitare di scrivere funzioni nella directory all'accesso: non eseguire mai un accesso di scrittura senza una precondizione (clausola se) nei criteri personalizzati. Un caso d'uso che richiede una scrittura in un accesso è la migrazione JIT delle password utente. Non richiedere una 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 un POST per i nuovi utenti o PUT per gli utenti correnti.
    • Un criterio personalizzato che crea o aggiorna un utente in ogni accesso può potenzialmente raggiungere un limite di frequenza 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, prendere in esame le letture per mantenere minimo il numero di letture in ogni accesso.
    • Stimare il carico di picco per stimare la frequenza di scritture di 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. È possibile che Azure AD B2C possa gestire il carico senza limitazioni, quando le applicazioni o i servizi downstream non verranno gestiti.
    • 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. Assicurarsi che rimanga al di sotto della soglia per tenant.
    • Comprendere gli effetti del processo di migrazione in altre applicazioni. Prendere in considerazione il traffico live gestito da altre applicazioni relying per assicurarsi di non causare limitazioni a livello di tenant e di fame di risorse per l'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 desiderato determineranno la frequenza di aggiornamento dei token per le applicazioni Web e a pagina singola.

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 applicazioni a pagina singola, è consigliabile usare il flusso del codice di autorizzazione con il flusso Proof Key for Code Exchange (PKCE) come opzione per consentire all'utente di continuare a usare 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.
    • Compilare l'applicazione per usare un gateway API come proxy di autenticazione. In questa configurazione, l'applicazione a pagina singola viene caricata senza alcuna 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 usa il token ottenuto dal gateway API o un altro metodo di autenticazione diretta, ad esempio certificati, credenziali client o chiavi API.
    • Passare all'opzione consigliata. Passare la SPA dalla concessione implicita al flusso di concessione del codice di autorizzazione con il supporto di Proof Key for Code Exchange (PKCE) e Cross-origin Resource Sharing (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.

Single Sign-On

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 recapito continuo (CICD) contribuisce a distribuire rapidamente su larga scala e riduce gli errori umani durante i test e la distribuzione nell'ambiente di produzione. Adottare CICD per ridurre, efficienza e coerenza degli errori. Azure Pipelines è un esempio di CICD.

Protezione dai bot

Proteggere le applicazioni da vulnerabilità note, ad esempio attacchi Distributed Denial of Service (DDoS), iniezioni SQL, scripting intersito, esecuzione di codice remoto e altri come documentato 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 scadenza e ruotare i segreti prima della scadenza.

Impelentare 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 i 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).
  • Usando CICD, ruotare i segreti che stanno per scadere entro due mesi dalla stagione di punta prevista. Il cryptoperiod massimo consigliato delle chiavi private associate a un certificato è 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 usare solo test di percorso soddisfatti e verificare che l'API gestisca correttamente gli scenari di problemi.

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