Punti chiave
- Le autorizzazioni runtime possono generare configurazioni delle app incoerenti tra i dispositivi e aumentare il rischio enterprise quando gli utenti concedono accessi eccessivi.
- Gli aggiornamenti delle app possono introdurre gradualmente un permission creep: l’ampliamento dell’accesso alla posizione in background, all’archiviazione o ai sensori può superare le valutazioni del rischio iniziali in assenza di una revisione strutturata.
- Le app con privilegi eccessivi espongono i dati aziendali (file riservati, rubriche, abitudini di spostamento, audio o video in diretta), rendendo le autorizzazioni una questione importante di governance.
- Una governance efficace delle autorizzazioni Android richiede la verifica delle app, audit pianificati, controlli di accesso basati sui ruoli (RBAC) e policy di sicurezza che tengano conto dello stato di conformità dei dispositivi.
- Anche con i controlli di sicurezza di Android, le autorizzazioni eccessive e obsolete restano un potenziale vettore di attacco per le aziende.
Le autorizzazioni runtime di Android sono controlli di sicurezza che obbligano le app a chiedere agli utenti l’accesso a dati sensibili e funzionalità del dispositivo. Se da un lato questo modello di autorizzazioni migliora la privacy sul dispositivo, dall’altro crea sfide di governance per le aziende che gestiscono flotte di dispositivi di grandi dimensioni.
Modello delle autorizzazioni runtime di Android: panoramica e rischi
Agli albori di Android, le autorizzazioni delle app venivano gestite con un modello basato sul momento dell’installazione. Questo modello concedeva autorizzazioni statiche al momento dell’installazione, fornendo quindi un accesso molto ampio senza che l’utente ne comprendesse prima le implicazioni.
Con l’arrivo di Android 6.0 (Marshmallow), le autorizzazioni runtime hanno introdotto approvazioni contestuali per l’accesso a risorse sensibili del dispositivo come fotocamera, microfono, posizione e contatti.
Con le autorizzazioni runtime, gli utenti possono concedere alle applicazioni i seguenti tipi di accesso:
- Consenti: fornisce all’app un accesso continuativo alla risorsa richiesta del dispositivo
- Nega: blocca l’accesso dell’app alla risorsa richiesta, anche se l’app può riproporre la richiesta in seguito
- Consenti solo durante l’utilizzo dell’app: concede l’accesso solo quando l’app è attivamente in uso, limitando l’accesso in background
- Concedi accesso una tantum: consente l’accesso temporaneo alla risorsa per una sola sessione
- Non chiedere più / Nega definitivamente: blocca l’accesso e impedisce ulteriori richieste, a meno che l’utente non intervenga manualmente
Poiché le autorizzazioni runtime partono dall’utente, le configurazioni possono variare da dispositivo a dispositivo all’interno dello stesso ambiente.
Permission creep e rischi nel ciclo di vita delle richieste di autorizzazione
Di norma le applicazioni ricevono numerosi aggiornamenti, soprattutto quelle che seguono cicli di vita dello sviluppo software rigorosi. A ogni aggiornamento i requisiti di autorizzazione possono ampliarsi, a volte in modo così impercettibile che le organizzazioni non se ne accorgono senza una revisione approfondita.
Dato che le autorizzazioni runtime vengono concesse solo quando l’app accede per la prima volta a una risorsa, l’approvazione iniziale e la relativa valutazione del rischio possono non riflettere più le reali capacità di accesso ai dati dell’app dopo un aggiornamento. Anche se le modifiche alle autorizzazioni sembrano minime, nel tempo si sommano e possono creare un’esposizione significativa.
Per capire in che modo il permission creep modifica la postura di rischio aziendale, è utile osservare dove si verifica più spesso.
Accesso alla posizione in background
Alcune applicazioni, come i portali HR, richiedono talvolta l’accesso al geo-tracking in primo piano, che attiva i servizi di localizzazione solo quando l’app è in uso. Gli aggiornamenti, però, possono introdurre richieste di accesso alla posizione in background, con il rischio di privilegi di localizzazione eccessivi se non vengono rimossi correttamente.
Accesso ampliato ad archiviazione e contenuti multimediali
Con le autorizzazioni runtime, gli aggiornamenti possono richiedere un accesso più ampio all’archiviazione, concedendo involontariamente alle app un accesso eccessivo a spazi che contengono documenti sensibili. Senza una revisione adeguata, il permission creep sull’archiviazione può allargare silenziosamente il perimetro di accesso ai dati dell’organizzazione.
Raccolta dati in aumento
Le autorizzazioni runtime di Android richiedono l’accesso a dati o risorse del dispositivo: contatti, registro chiamate, file, archiviazione, fotocamera e microfono. Ogni autorizzazione concessa aumenta però le capacità dell’app e, allo stesso tempo, amplia la superficie di attacco dell’organizzazione.
Per questo, negli ambienti enterprise le autorizzazioni runtime di Android richiedono monitoraggio continuo, avvisi sulle autorizzazioni ad alto rischio e rivalutazioni periodiche delle approvazioni.
Le autorizzazioni runtime di Android come questione di governance dei dati
Concedere le autorizzazioni permette alle applicazioni di funzionare in modo efficiente. Tuttavia, le autorizzazioni sono anche potenziali vie d’accesso ai dati aziendali protetti, perché aumentano il rischio di esposizione dei dati sul dispositivo.
Tra i rischi rientrano:
- Rischio di sorveglianza: l’accesso al microfono potrebbe trasmettere all’esterno conversazioni riservate.
- Rischio visivo: l’accesso alla fotocamera può essere usato per riprendere documenti o apparecchiature sensibili in aree aziendali ad accesso limitato.
- Mappatura di prossimità: gli attaccanti possono sfruttare le autorizzazioni Bluetooth per rilevare i dispositivi nelle vicinanze e mappare l’infrastruttura interna.
Il modello runtime di Android ruota attorno all’approvazione dell’utente. Quando le richieste si ripetono di continuo, la desensibilizzazione genera assuefazione e con il tempo le approvazioni diventano un gesto automatico anziché una scelta ponderata.
Inoltre, il consenso non implica la comprensione del rischio: richieste generiche come “Consenti l’accesso al microfono” non comunicano con chiarezza le possibili conseguenze per la sicurezza aziendale.
Governance delle autorizzazioni runtime di Android nelle organizzazioni
Poiché gli aggiornamenti delle app Android possono rendere obsolete le autorizzazioni nel tempo, queste devono rientrare in programmi di governance più ampi.
Processi di verifica e approvazione delle app
Prima di essere adottate, le applicazioni dovrebbero passare per un processo di revisione che valuti le autorizzazioni richieste e le confronti con la funzione prevista. Il processo di approvazione dovrebbe includere:
- La valutazione delle autorizzazioni dichiarate prima della distribuzione.
- La coerenza tra la funzione dell’app e gli accessi richiesti.
- Punteggi di rischio basati sulla sensibilità delle risorse a cui si chiede accesso.
- Il rifiuto delle applicazioni con privilegi eccessivi.
Audit periodici delle autorizzazioni
Senza audit regolari, le applicazioni possono accumulare gradualmente autorizzazioni eccessive man mano che vengono applicati gli aggiornamenti. Le organizzazioni dovrebbero pianificare revisioni delle autorizzazioni concesse, monitorare costantemente le nuove richieste di accesso ad alto rischio e verificarle rispetto alla soglia di rischio approvata.
Idealmente, i tecnici dovrebbero effettuare queste revisioni durante l’onboarding delle app, dopo gli aggiornamenti più importanti o almeno ogni trimestre, come parte della normale governance delle autorizzazioni.
Policy di accesso mobile basate sui ruoli
Non tutti i dipendenti hanno bisogno dello stesso livello di autorizzazioni: le esigenze di accesso variano in base al ruolo e alle responsabilità. Le organizzazioni dovrebbero limitare determinate autorizzazioni per i ruoli a rischio più elevato e restringere l’accesso alle risorse sensibili secondo il principio del privilegio minimo.
Accesso condizionale basato sullo stato del dispositivo
Le autorizzazioni runtime dovrebbero essere allineate a framework più ampi di integrità del dispositivo e conformità. Ad esempio, un dispositivo che consente accessi rischiosi alle app dovrebbe avere un accesso limitato alle informazioni aziendali sensibili. In questo modo si garantisce che solo i dispositivi sicuri e conformi possano raggiungere i sistemi business critici.
Controlli di sicurezza oltre la gestione delle richieste di autorizzazione
Le autorizzazioni runtime sono solo una parte di un’architettura di sicurezza Android più ampia. La maggior parte dei dispositivi Android moderni integra diverse protezioni native pensate per limitare la compromissione del sistema, isolare le applicazioni e proteggere i dati sensibili.
Sandboxing delle app
Android utilizza le sandbox per isolare ogni applicazione, riducendo l’accesso incrociato tra app. Le app operano quindi in processi separati e l’accesso diretto ai dati di un’altra app è limitato, ma il sandboxing non riduce ciò a cui può accedere un’app con privilegi eccessivi.
Scoped storage
Lo scoped storage limita la visibilità illimitata dell’archiviazione condivisa. Con questo meccanismo, le app possono accedere solo alle proprie directory e l’accesso ai contenuti multimediali condivisi richiede un’autorizzazione esplicita. Le autorizzazioni di archiviazione concesse dall’utente, però, ampliano questo confine protettivo.
Keystore basato su hardware
Il keystore di Android funge da archivio per le chiavi di crittografia all’interno di ambienti hardware sicuri. Questo aiuta a proteggere credenziali e chiavi crittografiche da furti o esfiltrazioni, isolando il materiale crittografico sensibile e riducendo l’esposizione ad attacchi e malware.
Avvio verificato
Android Verified Boot (AVB) verifica l’integrità del sistema, garantendo che il sistema operativo del dispositivo non sia stato manomesso durante l’avvio. Va ricordato che, sebbene AVB aiuti a prevenire compromissioni a livello di root, non valuta le decisioni sulle autorizzazioni a livello applicativo.
Questi controlli rafforzano l’integrità della piattaforma, ma non eliminano il rischio di esposizione dei dati aziendali legato ad applicazioni affidabili con privilegi eccessivi.
Anche se i controlli di sicurezza di Android sono molto resilienti rispetto alla compromissione del sistema, in molti ambienti le app provengono da fornitori affidabili e le organizzazioni mantengono i dispositivi protetti. In genere, le violazioni aziendali nascono da autorizzazioni eccessive sulle applicazioni e da autorizzazioni obsolete sfuggite ai controlli di governance.
Gestisci le autorizzazioni runtime sui dispositivi Android con NinjaOne
NinjaOne offre una gestione basata su policy per le autorizzazioni delle app Android, permettendo agli amministratori di gestire le autorizzazioni runtime di ogni singola applicazione Android.
- Override delle autorizzazioni per singola app: con NinjaOne puoi consentire, negare o richiedere conferma per autorizzazioni specifiche di ciascuna app, sovrascrivendo le impostazioni globali.
- Override degli ambiti delegati: concedi privilegi aggiuntivi alle applicazioni, come l’installazione di certificati o l’accesso alle configurazioni gestite.
- Configurazioni gestite: distribuisci impostazioni specifiche per le app così da garantire un comportamento coerente su tutti i dispositivi Android gestiti.
Una governance corretta delle autorizzazioni runtime riduce il rischio
Le autorizzazioni runtime di Android spostano l’approvazione delle richieste delle app dal momento dell’installazione a una scelta iniziata dall’utente. Negli ambienti enterprise, però, affidarsi troppo alle autorizzazioni runtime può creare lacune di governance.
Man mano che le applicazioni ricevono aggiornamenti e gli utenti approvano le richieste, la governance delle autorizzazioni diventa un elemento essenziale della strategia di sicurezza per evitare autorizzazioni obsolete. Integrare audit delle autorizzazioni, revisioni del ciclo di vita e applicazione delle policy nei programmi di gestione dei dispositivi mobili aiuta a ridurre l’esposizione dei dati e a mantenere la conformità.
Argomenti correlati:
