Circuit breaker per OTP via SMS: soglie, stati e ripristino sicuro

Quale problema risolve un circuit breaker nei flussi OTP via SMS

Un circuit breaker per OTP via SMS è un controllo operativo che riduce o modifica temporaneamente gli invii quando emergono segnali di degrado in un segmento specifico. Il suo scopo è proteggere la continuità del flusso di autenticazione, limitare l’impatto di una rotta o di una destinazione interessata ed evitare che un incidente amplifichi ritenti, duplicati e scadenze dei codici.

Non sostituisce i controlli di sicurezza dell’OTP. Il limite dei tentativi di verifica del codice, la durata del segreto, il monouso e le difese contro gli abusi sono controlli distinti. Il circuit breaker agisce sulla decisione di inviare o gestire richieste di messaggistica; non deve reimpostare i limiti di autenticazione semplicemente perché viene emesso un nuovo codice.

In un flusso fuori banda via SMS, il segreto a breve durata viene generato per un’operazione di autenticazione e trasportato tramite un canale secondario. Di conseguenza, un problema di consegna può impedire il completamento di un’autenticazione legittima, ma la soluzione non consiste necessariamente nel fermare tutto il traffico. Occorre isolare il segmento interessato e applicare una risposta proporzionata.

• Obiettivo: limitare il raggio di impatto del degrado.
• Ambito: decisioni di invio, coda, velocità di invio, rotta o autenticatore alternativo consentito.
• Non è: una prova di frode, un sostituto del rate limiting di verifica né una garanzia di consegna.
• Principio operativo: decisioni reversibili, segmentate e verificabili.

Perché un aumento dei DLR negativi non basta per bloccare automaticamente gli invii

Un identificatore restituito durante la presentazione di un messaggio a un’API, a un fornitore o a un SMSC conferma l’accettazione di tale presentazione in base al protocollo o all’integrazione; non conferma che il telefono abbia ricevuto l’OTP. La consegna è una fase successiva e deve essere osservata separatamente tramite gli stati disponibili.

Non è inoltre opportuno trattare qualsiasi DLR negativo come causa sufficiente per aprire un circuito globale. In SMPP esistono stati intermedi, come ENROUTE, e stati finali come DELIVERED, EXPIRED, DELETED o UNDELIVERABLE. Un messaggio in stato intermedio può essere ancora in elaborazione o in ritento prima di raggiungere uno stato finale.

Anche l’assenza di DLR non equivale automaticamente a mancata consegna. La restituzione delle ricevute dipende dalla configurazione di registered_delivery e dall’implementazione del centro messaggi o del fornitore. Una politica solida definisce quale assenza di stato finale sia rilevante, per quanto tempo e per quali coorti, invece di presumere che ogni silenzio sia un errore.

• Separare l’accettazione dell’invio, lo stato di consegna e la corretta verifica dell’OTP.
• Classificare ENROUTE come stato intermedio, non come risultato finale.
• Valutare i DLR negativi nel contesto di volume, tempo, destinazione e rotta.
• Trattare la mancanza di DLR come incertezza di osservabilità, non come prova di mancata ricezione.
• Non presumere che un DLR DELIVERED dimostri in modo indipendente la ricezione o la lettura da parte dell’utente.

I segnali da mantenere separati

Il circuito non deve essere alimentato da un’unica metrica aggregata. Ogni segnale descrive una fase diversa e può richiedere un’azione differente. Combinare, ad esempio, errori API e DLR tardivi può nascondere se l’incidente si trova nell’integrazione, prima dell’accettazione, nell’osservabilità degli stati o in una rotta di consegna.

Definite eventi normalizzati e una tassonomia stabile prima di fissare le soglie. Il valore del meccanismo dipende dal fatto che la stessa condizione produca la stessa classificazione, anche quando cambia il team di reperibilità o l’implementazione di una rotta.

• Errori di integrazione o trasporto: errori di autenticazione, connettività, timeout ed errori di protocollo tra l’applicazione e il punto di invio.
• Rifiuti precedenti all’accettazione: richieste non accettate dall’interfaccia di invio. Devono essere distinti da un messaggio accettato che successivamente non raggiunge uno stato finale favorevole.
• Stati finali negativi: risultati finali comunicati successivamente per messaggi accettati.
• Stati intermedi: messaggi ancora in elaborazione; non devono essere sommati automaticamente ai fallimenti finali.
• Latenza: tempo dalla presentazione accettata allo stato finale disponibile, analizzato per coorte.
• Assenza di stato finale: messaggi privi di stato finale entro il termine definito dalla policy.
• Comportamento di reinvio: richieste ripetute, potenziali duplicati, nuovi OTP emessi e verifiche successive.

Modello a tre stati: chiuso, aperto e prova di ripristino controllata

Il modello più semplice e tracciabile utilizza tre stati. Nello stato chiuso, il segmento opera secondo la policy normale e i segnali vengono osservati. Nello stato aperto, viene applicata l’azione di protezione definita per quel segmento. Nella prova di ripristino controllata, viene rilasciata una quota limitata ed esplicitamente governata del traffico per verificare se il degrado sia scomparso.

Non esistono una percentuale, una durata o un tasso di errore universali validi per tutte le destinazioni. Questi valori devono essere parametri di policy approvati dal team responsabile e adattati al volume, alla validità dell’OTP, alle alternative disponibili e al rischio di influire sugli utenti legittimi.

La transizione deve essere deterministica. Specificare quali segnali aprono il circuito, per quanto tempo rimane inizialmente aperto, quando può entrare in prova e quale condizione lo riporta allo stato aperto. Evitare modifiche manuali senza registrazione, poiché impediscono di ricostruire il motivo di una decisione.

• Chiuso: invio normale e raccolta dei segnali per segmento.
• Aperto: pausa, limitazione, coda condizionata o alternativa consentita secondo policy.
• Prova controllata: rilascio limitato e osservato prima del ripristino del funzionamento normale.
• Riapertura: ritorno immediato allo stato aperto se ricompaiono i segnali definiti.
• Chiusura: ripristino solo dopo aver soddisfatto criteri di stabilità e volume sufficiente.

Come definire soglie con volume minimo, finestra temporale e segmentazione

Calcolate le soglie su coorti operative coerenti. Come minimo, segmentate per Paese o piano di numerazione. Quando la telemetria è affidabile, aggiungete operatore di destinazione e rotta. Una media globale può nascondere un degrado localizzato oppure, al contrario, aprire un blocco esteso a causa del comportamento di una piccola parte del traffico.

Ogni soglia deve dichiarare tre elementi: una finestra temporale, un volume minimo di osservazioni e una condizione di degrado. Senza volume minimo, un campione ridotto può generare un tasso estremo e instabile. Senza finestra temporale, un evento vecchio può influire troppo a lungo oppure un picco breve può provocare una reazione eccessiva.

Mantenete separate le soglie di integrazione, rifiuto, risultato finale, latenza e assenza di stato finale. È inoltre opportuno stabilire una policy per segmenti nuovi o a basso volume: invece di dedurre un tasso conclusivo, si può richiedere una revisione operativa o applicare un’azione più conservativa e reversibile.

• Segmento consigliato: destinazione di numerazione; estendere per operatore e rotta quando sono disponibili dati affidabili.
• Finestra: esprimere il periodo esatto di calcolo e il relativo metodo di aggiornamento.
• Volume minimo: non valutare tassi di apertura prima di raggiungere il minimo approvato.
• Condizione: definire quale combinazione di segnale, proporzione e persistenza attiva la transizione.
• Esclusioni: documentare manutenzioni, modifiche pianificate o eventi di strumentazione che invalidano la lettura.
• Versione: assegnare una versione a ogni insieme di soglie e conservarne lo storico.

Quali azioni applicare quando il circuito si apre

Aprire un circuito non implica necessariamente scartare ogni richiesta. L’azione deve rispettare la validità dell’OTP e l’impatto sull’utente. Una coda è utile solo se il codice rimarrà valido e se il ritardo non spinge la persona a richiedere ripetutamente nuovi messaggi. Se non conserva più utilità, è preferibile non riattivare la richiesta precedente.

Le alternative di autenticazione devono essere abilitate e approvate prima di un incidente. Non improvvisate un canale alternativo il cui utilizzo non sia autorizzato dalla policy di autenticazione. In particolare, l’e-mail non deve essere usata per l’autenticazione fuori banda secondo NIST, anche se può avere utilizzi diversi, come la conferma dell’indirizzo o il recupero, nell’ambito della propria policy.

La decisione può variare in base alla gravità. Un errore di integrazione completo può richiedere una pausa immediata nell’ambito interessato. Un aumento della latenza o dell’incertezza dei DLR può giustificare una limitazione della velocità di invio o una prova di rotte autorizzate, purché l’organizzazione disponga di tali opzioni e possa osservarne i risultati.

• Sospendere nuovi invii per il segmento interessato.
• Limitare la velocità di invio per ridurre l’amplificazione di un degrado.
• Accodare solo le richieste che possono essere completate entro la validità utile dell’OTP.
• Deviare, secondo una policy precedentemente approvata, verso un’alternativa o una rotta disponibile.
• Presentare all’utente un metodo di autenticazione alternativo già consentito e configurato.
• Non riutilizzare OTP già consumati né riattivare indiscriminatamente richieste vecchie.

Come evitare un blocco per gli utenti legittimi

Un circuit breaker segmentato in modo inadeguato può trasformare un degrado localizzato in una negazione dell’accesso per utenti legittimi. Per ridurre questo rischio, limitate l’ambito iniziale, preferite azioni reversibili e valutate gli effetti negativi del controllo insieme alla sua efficacia operativa.

Non consentite che il reinvio diventi una via d’uscita senza limiti. Quando l’utente non riceve un OTP, i ritenti possono aumentare il volume, provocare duplicati e generare codici con validità sovrapposta. Il flusso deve prevedere regole chiare per correlare le richieste, mantenere i limiti di autenticazione e decidere quale segreto resti valido secondo la policy.

SMS/PSTN presenta limiti e rischi propri, inclusi phishing, SIM swap, portabilità e reindirizzamento del servizio. Il circuit breaker può migliorare la continuità dell’invio, ma non elimina questi rischi. Le decisioni di autenticazione devono mantenere i propri controlli di rischio e autenticatore alternativi indipendentemente dallo stato di consegna.

• Applicare il circuito al segmento più ristretto spiegato dai segnali.
• Misurare abbandoni, ritenti e fallimenti di verifica dopo ogni attivazione.
• Non reimpostare i limiti dei fallimenti di autenticazione con l’emissione di un nuovo segreto.
• Offrire percorsi di recupero e autenticatore alternativi a chi non può utilizzare PSTN.
• Distinguere un problema di messaggistica da un segnale di frode o da un errore di verifica.

Progettazione del ripristino: prove graduali, chiusura e rollback

Il ripristino deve essere esplicito quanto l’apertura. Dopo il periodo iniziale in stato aperto, il sistema può passare alla prova controllata se sono soddisfatti i requisiti della policy. Tale prova deve avere un ambito limitato, osservazione rafforzata e criteri di interruzione immediati se ricompaiono i segnali di degrado.

Non chiudete il circuito soltanto perché è trascorso del tempo. Richiedete evidenze nella stessa coorte interessata: volume sufficiente, comportamento di accettazione previsto, risultati di consegna disponibili entro il termine applicabile e assenza della condizione che ha causato l’apertura. Se l’osservabilità dei DLR è incompleta, non dichiarate un ripristino della consegna basandovi soltanto sulla mancanza di errori.

Un rollback sicuro evita che un incidente oscillante trasformi il sistema in una sequenza poco spiegabile di aperture e chiusure. Mantenete una durata iniziale di apertura, regole di rientro in prova e una condizione chiara di riapertura. Registrate ogni transizione.

• Entrare in prova solo con criteri preventivi e documentati.
• Rilasciare traffico limitato nella coorte esatta oggetto di verifica.
• Osservare gli stessi segnali che hanno motivato l’apertura, non solo una metrica favorevole.
• Chiudere dopo la stabilità e il volume sufficiente definiti dalla policy.
• Tornare allo stato aperto se ricompare la condizione di degrado.
• Rivedere la configurazione se il circuito oscilla ripetutamente.