Resilienza tramite le procedure consigliate per i developer

Articolo
07/02/2024

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

Libreria di Autenticazione Microsoft

Microsoft Authentication Library (MSAL) e Microsoft Identity Web Authentication Library per ASP.NET semplificare l'acquisizione, la gestione, la memorizzazione nella cache e l'aggiornamento dei token per le applicazioni. Queste librerie sono ottimizzate per supportare Microsoft Identity, incluse le funzionalità che migliorano la resilienza delle applicazioni.

Gli sviluppatori possono 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 una frequenza elevata 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: evitare di eseguire un accesso di scrittura senza precondizione (se clausola) 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: la directory implementa regole di limitazione a livello di applicazione e tenant. Esistono più 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ò 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 il sistema Azure AD B2C e l'applicazione per il picco del traffico. Azure AD B2C può gestire il carico senza limitazioni, quando le applicazioni o i servizi downstream non lo saranno.
- Comprendere e pianificare la sequenza temporale della migrazione. Quando si prevede di eseguire la migrazione degli utenti ad Azure AD 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 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 garantire che non vengano limitate a livello di tenant e di fame delle risorse per l'applicazione in tempo reale. 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.
- Altre informazioni sui limiti e sulle restrizioni del servizio Azure AD B2C.

Durate dei token

Se il servizio di autenticazione di Azure AD B2C non riesce a completare nuovi accessi e accessi, fornire una mitigazione per gli utenti che hanno eseguito l'accesso. Con la configurazione, gli utenti che hanno eseguito l'accesso possono usare l'applicazione senza interruzioni fino a quando non escono dall'applicazione o che la sessione raggiunge il timeout dall'inattività.

I requisiti aziendali e l'esperienza dell'utente finale determinano 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 come 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 AD B2C. Per le applicazioni a pagina singola, sono disponibili alcune opzioni per consentire all'utente di continuare a usare 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 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, in base a un criterio e autentica l'utente. La sessione di autenticazione tra il gateway API e il client viene mantenuta 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. Eseguire la migrazione dell'applicazione a pagina singola dalla concessione implicita al flusso di concessione del codice di autorizzazione con il supporto di Proof Key for Code Exchange (PKCE) e condivisione di risorse tra le origini (CORS).
- Per le applicazioni per dispositivi mobili, estendere la durata dei token di aggiornamento e di accesso.
Applicazioni back-end o microservizi: le applicazioni back-end (daemon) non sono interattive e non si trovano in un contesto utente, pertanto la prospettiva del furto di token è diminuita. È consigliabile trovare un equilibrio tra sicurezza e durata e impostare una lunga durata 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 AD B2C rende persistente una sessione basata su cookie.

Dopo le richieste di autenticazione successive, Azure AD 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 richiede 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 per l'autenticazione aggiornata.

Procedure di distribuzione sicure

Le interruzioni più comuni del servizio sono le modifiche al codice e alla configurazione. L'adozione di processi di integrazione continua e recapito continuo (CICD) consente la distribuzione su larga scala e riduce gli errori umani durante i test e la distribuzione. 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 DDoS (Distributed Denial of Service), attacchi SQL injection, scripting tra siti, esecuzione di codice remoto e altri documentati in OWASP Top-10. Distribuire un web application firewall (WAF) per difendersi da exploit e vulnerabilità comuni.

Usare Azure WAF, che fornisce protezione centralizzata dagli attacchi.
Usare WAF con Microsoft Entra Identity Protection e l'Accesso condizionale per fornire protezione multi-layer quando si usa Azure Active Directory B2C.
Resistenza del build alle iscrizioni guidate dai bot grazie all'integrazione con un sistema CAPTCHA.

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.

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 AD 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 scadono entro due mesi dalla stagione di punta prevista. Il cryptoperiod massimo consigliato delle chiavi private associate a un certificato è un anno.
Monitorare e ruotare le credenziali di accesso all'API, ad esempio password e certificati.

Test dell'API REST

Per la resilienza, i test delle API REST devono includere la verifica di 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 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 dell'API e rete per la distribuzione di contenuti (RETE CDN) in un ambiente di sviluppo, non nell'ambiente di produzione.

Condividi tramite