Un’app Android su tre e più della metà delle app iOS divulgano dati sensibili. Oltre a mettere in luce le debolezze nella sicurezza delle applicazioni, questi risultati sollevano un importante interrogativo sull’efficacia con cui le app mobili proteggono le operazioni sensibili quando le condizioni di rischio cambiano durante una sessione autenticata.

Si consideri il caso di un cliente bancario che effettua l’accesso da un dispositivo affidabile, ma che in seguito avvia una transazione di elevato valore in circostanze sospette. Sebbene la sessione esistente rimanga autenticata, eventuali modifiche all’integrità del dispositivo o al comportamento dell’utente potrebbero richiedere un’ulteriore verifica. È qui che entra in gioco l’autenticazione adattiva. Le app diventano rilevanti. Invece di affidarsi esclusivamente all’autenticazione iniziale, le app possono valutare i segnali di rischio contestuali e avviare risposte basate su policy. A seconda del rischio valutato, possono consentire l’accesso, richiedere un’autenticazione aggiuntiva o limitare l’operazione.

L’implementazione di queste decisioni basate sul rischio nelle app per dispositivi mobili, senza introdurre inutili complicazioni nell’autenticazione, richiede un attento coordinamento tra le app e i sistemi di sicurezza di back-end. Questo articolo esamina il funzionamento della sicurezza adattiva, i requisiti di implementazione e le considerazioni ingegneristiche coinvolte.

Come funziona l’autenticazione adattiva nelle app per dispositivi mobili?

La sicurezza adattiva funziona come un ciclo continuo, non come un singolo controllo di accesso. Ogni fase alimenta la successiva, trasformando il contesto grezzo del dispositivo e dell’utente in una decisione di accesso chiara e proporzionata.

Raccolta del segnale

La sicurezza adattiva inizia con la raccolta di informazioni contestuali sull’utente e sulla sua sessione corrente. Queste includono l’integrità del dispositivo, la versione del sistema operativo, il tipo di rete, la geolocalizzazione e l’orario di accesso. I segnali comportamentali, come il ritmo di digitazione e gli schemi di scorrimento, forniscono ulteriore contesto, mentre gli indicatori di manomissione aiutano a identificare ambienti applicativi potenzialmente compromessi.

Punteggio di rischio

I segnali raccolti vengono quindi analizzati congiuntamente utilizzando modelli di machine learning integrati nel dispositivo o motori di valutazione del rischio lato server per determinare il livello di rischio della sessione. Ad esempio, accedere a un’app da una nuova posizione potrebbe non essere sospetto. Tuttavia, se combinato con un dispositivo rootato e schemi di digitazione insoliti, la stessa attività potrebbe indicare un rischio per la sicurezza più elevato.

Decisione politica

Il livello di rischio valutato determina quali politiche di accesso devono essere applicate all’azione richiesta. Un motore di policy confronta il punteggio di rischio con regole predefinite, consentendo l’elaborazione delle richieste a basso rischio e richiedendo una verifica aggiuntiva per le attività a rischio medio-alto. Le richieste che superano le soglie di rischio accettabili possono essere rifiutate e le policy di back-end possono essere modificate in base all’evoluzione dei requisiti di sicurezza.

Risposta adattiva

Una volta determinata la policy applicabile, l’applicazione regola di conseguenza l’accesso dell’utente. Può consentire l’azione richiesta, avviare l’autenticazione a più fattori, limitare determinate funzionalità o impedire l’accesso a informazioni sensibili. L’esito fornisce inoltre informazioni utili per le successive valutazioni del rischio, consentendo l’adattamento dei requisiti di sicurezza al variare delle condizioni della sessione.

Come creare un’app mobile con autenticazione adattiva che consenta alle app di impostare le proprie politiche di accesso?

L’implementazione della sicurezza adattiva richiede più della semplice integrazione degli SDK di autenticazione. Pertanto, le organizzazioni dovrebbero Assumere sviluppatori di app per dispositivi mobili per stabilire segnali affidabili sui dispositivi, proteggere le operazioni sensibili e coordinare le decisioni di accesso basate sul rischio tra applicazioni mobili e infrastrutture di back-end.

1. Verifica l’integrità dell’app e del dispositivo tramite l’attestazione della piattaforma.

Prima di affidarsi ai segnali generati dal dispositivo, gli esperti di sviluppo di app per dispositivi mobili necessitano di meccanismi per valutare se un’app opera in un ambiente affidabile. L’attestazione della piattaforma fornisce prove crittograficamente verificabili a supporto di questa valutazione.

Su Android, l’ API Play Integrity fornisce valutazioni sull’autenticità delle applicazioni, sull’integrità del dispositivo e sullo stato della licenza di Google Play. Su iOS, App Attest utilizza chiavi crittografiche per aiutare i server a verificare che le richieste provengano da istanze di applicazioni legittime.

Inoltre, il backend deve verificare queste risposte prima di integrarle nelle decisioni di accesso. Poiché l’attestazione non può garantire la completa sicurezza del dispositivo, è necessario valutare i risultati insieme ad altri indicatori di rischio.

2. Rafforzare l’ambiente di runtime con RASP e protezione anti-manomissione.

La protezione automatica delle applicazioni in fase di esecuzione (RASP) rileva le minacce durante l’esecuzione dell’app, inclusi debugger, strumenti di hooking come Frida, emulatori e dispositivi con root o jailbreak. Verifica inoltre la firma e l’integrità del codice dell’app stessa, individuando le build riconfezionate. Gli sviluppatori di app per dispositivi mobili possono anche combinare RASP con l’offuscamento del codice per rendere più difficile agli aggressori individuare e disabilitare questi controlli di sicurezza.

Tuttavia, hacker determinati possono comunque aggirare qualsiasi controllo lato client, quindi l’app non dovrebbe mai agire basandosi esclusivamente sui propri rilevamenti. Deve invece segnalarli al backend come segnali firmati che aumentano il punteggio di rischio della sessione. In questo modo, il motore delle policy può scegliere una risposta proporzionata, anziché causare il blocco dell’app.

3. Proteggi chiavi e token con un sistema di archiviazione basato su hardware.

Su iOS, i token di sessione vengono memorizzati nel Portachiavi con la classe di accessibilità “ThisDeviceOnly” , in modo che non vengano trasferiti su un altro dispositivo tramite i backup. Secure Enclave supporta solo chiavi private a curva ellittica P-256 , che genera internamente e non esporta mai. Su Android, le chiavi vengono generate all’interno di Android Keystore. Per una maggiore protezione, gli sviluppatori dovrebbero utilizzare StrongBox sui dispositivi supportati, in quanto offre un’archiviazione delle chiavi dedicata con supporto hardware. Su altri dispositivi, è possibile utilizzare Trusted Execution Environment (TEE) con supporto hardware, ove disponibile.

Evitate di includere segreti API di lunga durata nel file binario dell’app, poiché il reverse engineering può estrarli. Emettete invece token di breve durata dopo l’attestazione della piattaforma. Idealmente, associate ogni token a una chiave del dispositivo, in modo che un token rubato risulti inutilizzabile su qualsiasi altro dispositivo.

4. Applicare le politiche di accesso tramite un motore di gestione del rischio back-end

I segnali di sicurezza raccolti dall’app mobile di autenticazione adattiva devono essere valutati rispetto ai requisiti di accesso definiti prima di consentire operazioni sensibili. Un motore di rischio back-end esegue questa valutazione combinando i risultati relativi all’integrità del dispositivo con il comportamento della sessione, le autorizzazioni dell’utente e la sensibilità delle transazioni. In base al rischio valutato, un motore di policy determina se consentire la richiesta, richiedere un’autenticazione aggiuntiva o negare l’accesso.

Framework come Open Policy Agent aiutano gli sviluppatori a gestire queste policy indipendentemente dal codice dell’applicazione. Poiché gli aggressori possono manipolare il comportamento lato client, il backend deve applicare le decisioni di autorizzazione e conservare i registri per audit e indagini sulla sicurezza.

5. Aggiungi l’apprendimento automatico sul dispositivo per segnali comportamentali rapidi e rispettosi della privacy.

Core ML su iOS e LiteRT (precedentemente TensorFlow Lite) su Android eseguono modelli comportamentali direttamente sul dispositivo. Analizzano localmente il ritmo di digitazione e gli schemi di scorrimento, inviando poi al server solo un punteggio compatto o un riepilogo delle caratteristiche. Questo approccio riduce la latenza e supporta la minimizzazione dei dati, un principio fondamentale del GDPR.

Tuttavia, i dati comportamentali possono comunque essere considerati dati personali o biometrici, quindi è necessario ottenere un consenso esplicito e documentare come vengono utilizzati. Il punteggio ottenuto sul dispositivo va considerato come un input tra i tanti, poiché un dispositivo compromesso potrebbe manometterlo. Entrambi i framework possono caricare modelli aggiornati scaricati in fase di esecuzione, consentendo così un’evoluzione del sistema di rilevamento anche senza il rilascio completo dell’app.

6. Utilizzare le chiavi di accesso e l’autenticazione crittografica a più fattori.

Quando il motore delle policy determina che è necessaria un’ulteriore verifica dell’identità, le passkey offrono un metodo sicuro per autenticare gli utenti senza dover ricorrere alle password. Basate sugli standard FIDO2 e WebAuthn , le passkey contrastano il phishing associando le credenziali a una specifica entità affidabile. Le app per dispositivi mobili stabiliscono questa associazione tramite i domini associati su iOS e i collegamenti alle risorse digitali su Android.

Per le azioni a rischio più elevato, gli sviluppatori possono estendere questo approccio richiedendo una nuova asserzione della chiave di accesso con verifica dell’utente, che il backend convalida crittograficamente. Quando le chiavi di accesso non sono disponibili, gli sviluppatori possono utilizzare chiavi crittografiche protette biometricamente memorizzate nel Portachiavi iOS o nel Keystore Android per firmare una sfida emessa dal server. Su Android, BiometricPrompt con CryptoObject supporta questo processo collegando l’autenticazione biometrica a un’operazione crittografica. In entrambi gli approcci, il server verifica la prova risultante prima di autorizzare l’azione sensibile.

7. Verificare continuamente la sicurezza rispetto a OWASP MASVS

Ogni controllo descritto finora necessita di test regolari e lo standard OWASP Mobile Application Security Verification Standard (MASVS) offre un approccio strutturato. Raggruppa i suoi controlli in otto aree: archiviazione, crittografia, autenticazione, rete, piattaforma, codice, resilienza e privacy. Parallelamente, la Mobile Application Security Testing Guide (MASTG) trasforma ciascun controllo in casi di test concreti.

Questi test funzionano meglio se eseguiti in modo continuativo piuttosto che come audit una tantum. Automatizzate l’analisi statica e dinamica nella vostra pipeline CI/CD, quindi aggiungete test di penetrazione manuali prima delle release principali. Oltre ai controlli standard, testate la logica adattiva stessa riproducendo vecchi token di attestazione, integrando l’app con Frida ed eseguendola su dispositivi con root. Questi test mostrano se il sistema rileva gli attacchi e dovrebbero anche misurare con quale frequenza segnala gli utenti legittimi.

Il futuro consiste nel costruire una sicurezza mobile adattiva per le minacce in continua evoluzione.

Mentre le password e l’intelligenza artificiale integrata nei dispositivi consentono un’autenticazione più reattiva, gli attacchi assistiti dall’IA e i requisiti emergenti dell’era post-quantistica stanno modificando le priorità della sicurezza mobile. La sfida non si limita all’identificazione delle minacce, ma si estende alla definizione di come un’app mobile con autenticazione adattiva debba reagire senza interrompere l’esperienza degli utenti legittimi.

Per chi prende le decisioni, ciò rende essenziale definire obiettivi di sicurezza misurabili prima di investire in funzionalità aggiuntive. Le organizzazioni devono identificare quali operazioni richiedono una verifica più rigorosa, dove è necessario un intervento immediato e come bilanciare i requisiti di sicurezza con l’esperienza utente.

Queste priorità dovrebbero anche guidare le decisioni architettoniche, garantendo che le applicazioni possano adattarsi alle minacce in evoluzione senza una riprogettazione estesa. Pertanto, le organizzazioni devono dare priorità agli investimenti in Servizi di sviluppo di app mobile con esperienza in app di autenticazione adattiva, architetture di sicurezza, monitoraggio continuo dei rischi e manutenibilità a lungo termine. In definitiva, una sicurezza adattiva efficace consiste nel prendere decisioni di accesso proporzionate che proteggano le operazioni sensibili preservando al contempo l’affidabilità e l’usabilità dell’applicazione.

Biografia dell’autore

Amelia Swank è una specialista di marketing digitale esperta presso Amelia lavora presso SunTec India e vanta oltre otto anni di esperienza nel settore IT. Eccelle in SEO, PPC e content marketing, ed è esperta nell’utilizzo di Google Analytics, SEMrush e HubSpot. È una specialista in sviluppo di applicazioni, ingegneria del software, IA/ML, test QA, gestione del cloud, DevOps e fornitura di personale (sviluppatori di app mobile, sviluppatori WordPress, sviluppatori full stack, ecc.). Amelia si tiene aggiornata sulle tendenze del settore e ama sperimentare nuove tecniche di marketing.