Una sessione autenticata può essere utilizzata in modo inatteso: un account abitualmente impiegato per modificare pochi documenti avvia improvvisamente una sequenza continua di esportazioni. Le credenziali risultano valide, ma il ritmo e il tipo delle operazioni richiedono una valutazione ulteriore.
L’autenticazione adattiva consente di collegare la verifica dell’utente al contesto della richiesta. Qui proponiamo un modello sperimentale che utilizza anche l’analisi spettrale dei segnali prodotti dall’applicazione. L’obiettivo è individuare scostamenti utili a decidere quando sospendere un’operazione e richiedere una conferma dell’identità.
Questo primo articolo sviluppa l’architettura del modello; il successivo ne descriverà lo pseudocodice. La combinazione proposta deve ancora essere validata: non vengono presentati risultati sperimentali né rivendicazioni di superiorità rispetto a sistemi esistenti.
Il perimetro della protezione
Il caso considerato è un’applicazione nella quale un soggetto esterno può inviare richieste e osservarne le risposte. Potrebbe anche disporre di una sessione sottratta all’utente. Si assume però che non controlli il servizio che valuta il comportamento, l’archivio dei profili o il componente che applica i permessi.
Se questi componenti vengono compromessi, l’attaccante può alterare i dati o aggirare le decisioni. Il modello non fornisce una garanzia contro tale scenario. Anche il dispositivo locale deve essere verificato secondo le regole del sistema: la sola provenienza dal computer abituale non rende attendibile una richiesta.
L’architettura comprende un raccoglitore di eventi, un estrattore di caratteristiche, un archivio di riferimento, un valutatore e un punto di controllo delle operazioni. In un sito, quest’ultimo deve agire sul server. In un’applicazione locale può essere un servizio isolato, con permessi distinti dall’interfaccia. Una funzione JavaScript nel browser non costituisce una barriera di autorizzazione.
Trasformare le operazioni in segnali confrontabili
Per rendere concreta la proposta, dividiamo l’attività in finestre temporali di durata fissa. Ogni finestra contiene N intervalli, ciascuno lungo Δt. Per ogni categoria di operazione c, definiamo x c [n] come il numero di eventi osservati nell’intervallo n.
Un canale può rappresentare l’apertura di documenti, un altro i salvataggi e un terzo le esportazioni. A titolo illustrativo, 64 intervalli da un secondo producono una finestra di 64 secondi. Sono parametri didattici, non valori raccomandati per un sistema reale.
Si registrano categoria e tempi degli eventi, evitando contenuti dei documenti, password o testo digitato. Preferiamo eventi osservati dal servizio; la telemetria inviata dal client può essere falsificata e deve avere un peso coerente con questa limitazione. Anche gli eventi ricevuti dal server descrivono richieste, non provano chi le abbia originate.
Una finestra senza attività e una finestra con dati mancanti sono casi differenti. Il secondo richiede un indicatore di qualità: riempire automaticamente ogni lacuna con zeri trasformerebbe un problema di raccolta in un comportamento apparentemente reale. Conservazione limitata e accesso ristretto ai dati fanno parte della progettazione.
Ampiezza e fase nella descrizione del comportamento
Su ogni canale si può calcolare una trasformata discreta di Fourier. Con la convenzione qui adottata:
X c [k] = Σ n=0 N−1 x c [n] e −i2πkn/N
Gli indici n e k vanno da 0 a N−1 e i è l’unità immaginaria. Per le componenti a frequenza non negativa, f k = k/(NΔt). Il coefficiente si esprime anche come:
X c [k] = A c [k] e iφ c [k]
Il modulo A descrive il peso della componente e la fase φ il suo allineamento temporale. La componente k = 0 contiene la somma dei campioni. Sottrarre la media o applicare una finestra di pesatura modifica ciò che viene analizzato: la stessa elaborazione deve essere usata nei dati di riferimento e nelle nuove sessioni.
Per il modello proposto, lo spettro è una descrizione numerica dell’attività. Non è una funzione d’onda fisica e non introduce il principio di indeterminazione o l’impossibilità quantistica di copiare uno stato. Le componenti conservate e la loro utilità devono essere scelte e misurate sui dati dell’applicazione.
Usare la fase senza confonderla con un’identità
Una fase assoluta dipende dall’origine temporale. Spostare la finestra può cambiare i coefficienti anche quando la sequenza di operazioni è simile. Per questo, nel modello sperimentale consideriamo soprattutto relazioni tra canali osservati nella stessa finestra:
Δφ ab [k] = arg(X a [k] X b [k] * )
L’asterisco indica il complesso coniugato. La quantità descrive la differenza di fase tra due categorie di eventi alla stessa frequenza. Potrebbe, per esempio, contribuire a descrivere la relazione temporale tra apertura e salvataggio dei documenti.
La cancellazione dell’effetto di uno spostamento comune vale esattamente nel caso ideale di una traslazione circolare degli stessi campioni. Finestre reali includono ed escludono eventi ai bordi: non si deve presumere un’invarianza generale.
Gli angoli sono inoltre periodici. Per evitare che valori vicini a −π e π siano trattati come lontani, proponiamo di rappresentare ogni differenza mediante cos(Δφ) e sin(Δφ). Le fasi delle componenti con modulo nullo non sono definite; quelle con modulo troppo piccolo vengono escluse con una regola stabilita prima della valutazione.
Costruire il profilo e misurare lo scostamento
Le caratteristiche selezionate formano un vettore reale v: può includere conteggi, ampiezze trasformate e coppie seno-coseno delle differenze di fase. Il profilo conserva distribuzioni di riferimento per l’utente e, quando i dati lo consentono, per il contesto operativo. Una sessione di sola lettura non dovrebbe essere confrontata indiscriminatamente con una sessione di elaborazione intensiva.
Come punto di partenza proponiamo una distanza standardizzata. Per ogni caratteristica j stimiamo media μ j e deviazione standard σ j sui dati di addestramento:
d j = (v j − μ j ) / max(σ j , ε j )
S = (Σ j∈J w j d j 2 ) / (Σ j∈J w j )
Il termine ε j è un minimo positivo nella scala della caratteristica, w j è un peso positivo e J contiene le caratteristiche utilizzabili. Se non c’è copertura sufficiente, il punteggio non viene emesso: l’esito è «dati insufficienti». Soglie e confronti devono tenere conto delle caratteristiche effettivamente disponibili.
Questa distanza è un riferimento semplice, non una soluzione ottimale. Può contare più volte informazioni correlate e rappresentare male abitudini con più modalità. S misura uno scostamento; non è la probabilità che l’utente sia un intruso. Trasformarlo arbitrariamente in una percentuale di rischio darebbe una precisione priva di fondamento.
Dal punteggio alla decisione di accesso
La decisione combina qualità dei dati, scostamento, stato della sessione e sensibilità dell’operazione. L’analisi comportamentale interviene all’interno dei controlli di autenticazione e autorizzazione, senza assegnare nuovi permessi.
- Permesso assente: l’operazione viene negata indipendentemente dal punteggio.
- Sessione valida e comportamento compatibile: si applicano le regole ordinarie; le operazioni che richiedono sempre una conferma mantengono quel requisito.
- Scostamento elevato o osservazione insufficiente: una richiesta sensibile resta sospesa fino alla verifica prevista dalla politica di sicurezza.
- Verifica fallita, scaduta o sessione revocata: la richiesta non viene eseguita e si applicano i limiti ai tentativi.
Una verifica aggiuntiva può usare un autenticatore già registrato, per esempio una passkey o un codice temporaneo secondo la configurazione del servizio. Ripetere la stessa password non equivale a introdurre un fattore indipendente; un codice temporaneo non ha automaticamente la resistenza al phishing di un autenticatore progettato per offrirla.
La conferma va associata alla sessione e all’operazione sospesa, con scadenza e protezione dal riutilizzo. I permessi devono essere ricontrollati prima dell’esecuzione. Un guasto del valutatore non deve autorizzare automaticamente operazioni sensibili: occorre un percorso esplicito di verifica o sospensione.
Che cosa riceve il soggetto esterno
Il servizio di analisi può restituire al componente autorizzativo soltanto un esito operativo, mantenendo profilo e dettagli diagnostici in un’area riservata. L’interfaccia dell’utente comunica, per esempio, che occorre una verifica, senza esporre coefficienti, soglie o distanze.
Un soggetto non autorizzato riceve il diniego previsto dal protocollo. Una risposta casuale, da sola, non impedisce l’accesso: la protezione consiste nel bloccare effettivamente la lettura o la modifica della risorsa.
Messaggi e tempi di risposta possono comunque fornire indizi. Ridurre differenze inutili e limitare interrogazioni ripetute serve a contenere questa esposizione. L’eventuale casualità nei protocolli deve avere uno scopo preciso, come la generazione sicura di sfide imprevedibili, e non sostituire una decisione di autorizzazione.
Nascondere il profilo riduce l’informazione disponibile all’esterno, ma non dimostra che sia impossibile copiarlo o inferirne proprietà. La rappresentazione complessa non è una chiave crittografica; il sistema deve restare difendibile anche quando il metodo di calcolo è noto.
Aggiornare il profilo senza normalizzare un attacco
Il comportamento cambia nel tempo. Nel modello proposto, l’aggiornamento è separato dalla valutazione della richiesta: una finestra non viene prima incorporata nel profilo per poi giudicare la propria normalità.
Le nuove osservazioni candidate provengono da sessioni con verifiche adeguate, vengono sottoposte a controlli di qualità e incidono sul riferimento in modo limitato. Una conferma riuscita è un elemento favorevole, non una prova assoluta che tutti gli eventi della sessione siano affidabili.
Versionare i profili permette di confrontare gli effetti di un aggiornamento e ripristinare una configurazione precedente. All’avvio, quando manca uno storico sufficiente, rimangono attivi i controlli ordinari. Cambiamenti di dispositivo o strumenti di accessibilità richiedono percorsi di ricalibrazione che non penalizzino automaticamente l’utente.
Una prova che distingua utilità e complessità
La verifica sperimentale deve confrontare almeno tre configurazioni: regole ordinarie senza spettro, regole con caratteristiche di ampiezza e regole con ampiezza e fase relativa. Solo questo confronto permette di attribuire un eventuale miglioramento alla componente aggiunta.
Addestramento, scelta delle soglie e valutazione finale devono usare insiemi distinti. Finestre sovrapposte o appartenenti alla stessa sessione non devono essere distribuite casualmente tra addestramento e prova, perché condividerebbero informazioni. Un confronto temporale, su sessioni successive, aiuta a misurare il cambiamento delle abitudini.
Vanno misurati i falsi allarmi, gli accessi illeciti non fermati prima dell’operazione, le verifiche richieste agli utenti legittimi e la latenza. Le prove devono includere imitazione dei ritmi, automazioni legittime, sessioni sottratte e telemetria manipolata, precisando quali scenari siano stati effettivamente simulati.
Il contributo da dimostrare è circoscritto: a parità di disturbo per l’utente, le caratteristiche spettrali consentono di fermare più operazioni illecite, oppure riducono le verifiche superflue a parità di efficacia? Finché mancano questi dati, l’architettura resta una proposta sperimentale. Lo pseudocodice dovrà tradurre questi vincoli in passaggi espliciti, compresi dati insufficienti, errori e verifiche fallite.