Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Sicurezza delle applicazioni

Elementi di applicazioni

Android offre una piattaforma open source e un ambiente applicativo per dispositivi mobili. Il sistema operativo principale si basa sul kernel Linux. Le applicazioni Android sono spesso scritte nel linguaggio di programmazione Java ed eseguite nella macchina virtuale Dalvik. Tuttavia, le applicazioni possono anche essere scritte in codice nativo. Le applicazioni vengono installate da un singolo file con l'estensione .apk.

I principali elementi costitutivi dell'applicazione Android sono:

  • AndroidManifest.xml : il file AndroidManifest.xml è il file di controllo che indica al sistema cosa fare con tutti i componenti di livello superiore (in particolare attività, servizi, ricevitori di trasmissione e provider di contenuti descritti di seguito) in un'applicazione. Questo specifica anche quali autorizzazioni sono necessarie.

  • Attività: Un attività è, in generale, il codice per una singola, task utente-concentrato. Di solito include la visualizzazione di un'interfaccia utente per l'utente, ma non è necessario: alcune attività non visualizzano mai l'interfaccia utente. In genere, una delle attività dell'applicazione è il punto di ingresso a un'applicazione.

  • Servizi : un servizio è un corpo di codice che viene eseguito in background. Può essere eseguito nel proprio processo o nel contesto del processo di un'altra applicazione. Altri componenti "si legano" a un servizio e invocano metodi su di esso tramite chiamate di procedura remote. Un esempio di servizio è un lettore multimediale: anche quando l'utente esce dall'interfaccia utente di selezione multimediale, è probabile che l'utente continui ancora a riprodurre musica. Un servizio mantiene attiva la musica anche quando l'interfaccia utente è stata completata.

  • Broadcast Receiver : BroadcastReceiver è un oggetto che viene istanziato quando un sistema IPC noto come Intent viene emesso dal sistema operativo o da un'altra applicazione. Un'applicazione può registrare un ricevitore per il messaggio di batteria scarica, ad esempio, e modificarne il comportamento in base a tali informazioni.

Modello di autorizzazione Android: accesso alle API protette

Tutte le applicazioni su Android vengono eseguite in una sandbox dell'applicazione . Per impostazione predefinita, un'applicazione Android può accedere solo a una gamma limitata di risorse di sistema. Il sistema gestisce l'accesso delle applicazioni Android a risorse che, se utilizzate in modo errato o dannoso, potrebbero influire negativamente sull'esperienza dell'utente, sulla rete o sui dati sul dispositivo.

Queste restrizioni sono implementate in una varietà di forme diverse. Alcune funzionalità sono limitate da una mancanza intenzionale di API alla funzionalità sensibile (ad esempio non esiste un'API Android per manipolare direttamente la scheda SIM). In alcuni casi, la separazione dei ruoli fornisce una misura di sicurezza, come per l'isolamento dello storage per applicazione. In altri casi, le API sensibili sono destinate all'uso da parte di applicazioni attendibili e protette tramite un meccanismo di sicurezza noto come Autorizzazioni.

Queste API protette includono:

  • Funzioni della fotocamera
  • Dati sulla posizione (GPS)
  • Funzioni Bluetooth
  • Funzioni di telefonia
  • Funzioni SMS / MMS
  • Connessioni di rete / dati

Queste risorse sono accessibili solo attraverso il sistema operativo. Per utilizzare le API protette sul dispositivo, un'applicazione deve definire le funzionalità di cui ha bisogno nel suo manifest. Tutte le versioni di Android 6.0 e successive utilizzano un modello di autorizzazioni di runtime . Se un utente richiede una funzionalità da un'app che richiede un'API protetta, il sistema visualizza una finestra di dialogo che richiede all'utente di negare o consentire l'autorizzazione.

Una volta concesse, le autorizzazioni vengono applicate all'applicazione purché sia ​​installata. Per evitare confusione dell'utente, il sistema non notifica nuovamente all'utente le autorizzazioni concesse all'applicazione e le applicazioni incluse nel sistema operativo principale o raggruppate da un OEM non richiedono autorizzazioni all'utente. Le autorizzazioni vengono rimosse se un'applicazione viene disinstallata, quindi una reinstallazione successiva comporterà nuovamente la visualizzazione delle autorizzazioni.

All'interno delle impostazioni del dispositivo, gli utenti sono in grado di visualizzare le autorizzazioni per le applicazioni che hanno precedentemente installato. Gli utenti possono anche disattivare alcune funzionalità a livello globale quando lo desiderano, come disabilitare GPS, radio o Wi-Fi.

Nel caso in cui un'applicazione tenti di utilizzare una funzione protetta che non è stata dichiarata nel manifest dell'applicazione, l'errore di autorizzazione in genere comporterà il ritorno all'eccezione di un'eccezione di sicurezza. I controlli delle autorizzazioni dell'API protetta vengono applicati al livello più basso possibile per prevenire l'elusione. Un esempio di messaggistica utente quando viene installata un'applicazione mentre si richiede l'accesso alle API protette è mostrato nella Figura 2 .

Le autorizzazioni predefinite del sistema sono descritte su https://developer.android.com/reference/android/Manifest.permission.html . Le applicazioni possono dichiarare le proprie autorizzazioni per altre applicazioni da utilizzare. Tali autorizzazioni non sono elencate nella posizione sopra.

Quando si definisce un'autorizzazione, un attributo protectionLevel indica al sistema in che modo l'utente deve essere informato delle applicazioni che richiedono l'autorizzazione o chi è autorizzato a detenere un'autorizzazione. I dettagli sulla creazione e l'utilizzo delle autorizzazioni specifiche dell'applicazione sono descritti all'indirizzo https://developer.android.com/guide/topics/security/security.html .

Esistono alcune funzionalità del dispositivo, come la possibilità di inviare intenti di trasmissione SMS, che non sono disponibili per le applicazioni di terze parti, ma che possono essere utilizzate da applicazioni preinstallate dall'OEM. Queste autorizzazioni utilizzano l'autorizzazione signatureOrSystem.

In che modo gli utenti comprendono le applicazioni di terze parti

Android si impegna a chiarire agli utenti quando interagiscono con applicazioni di terze parti e informare l'utente delle capacità di tali applicazioni. Prima dell'installazione di qualsiasi applicazione, all'utente viene mostrato un messaggio chiaro sulle diverse autorizzazioni richieste dall'applicazione. Dopo l'installazione, all'utente non viene richiesto nuovamente di confermare alcuna autorizzazione.

Esistono molti motivi per mostrare le autorizzazioni immediatamente prima del tempo di installazione. Questo è quando l'utente sta attivamente rivedendo le informazioni sull'applicazione, lo sviluppatore e la funzionalità per determinare se soddisfa le loro esigenze e aspettative. È anche importante che non abbiano ancora stabilito un impegno mentale o finanziario per l'app e possano facilmente confrontare l'applicazione con altre applicazioni alternative.

Alcune altre piattaforme utilizzano un approccio diverso alla notifica dell'utente, richiedendo l'autorizzazione all'inizio di ogni sessione o mentre le applicazioni sono in uso. La visione di Android è di consentire agli utenti di passare da un'applicazione all'altra senza soluzione di continuità. Fornire conferme ogni volta rallenterebbe l'utente e impedirebbe ad Android di offrire un'esperienza utente eccezionale. Avere le autorizzazioni di revisione dell'utente al momento dell'installazione offre all'utente la possibilità di non installare l'applicazione se si sentono a disagio.

Inoltre, molti studi sull'interfaccia utente hanno dimostrato che l'eccessiva richiesta dell'utente fa sì che l'utente inizi a dire "OK" a qualsiasi finestra di dialogo visualizzata. Uno degli obiettivi di sicurezza di Android è quello di trasmettere in modo efficace all'utente importanti informazioni sulla sicurezza, cosa che non può essere fatta utilizzando le finestre di dialogo che l'utente verrà addestrato a ignorare. Presentando le informazioni importanti una volta e solo quando è importante, è più probabile che l'utente pensi a cosa stanno accettando.

Alcune piattaforme scelgono di non mostrare alcuna informazione sulla funzionalità dell'applicazione. Tale approccio impedisce agli utenti di comprendere e discutere facilmente le funzionalità dell'applicazione. Sebbene non sia possibile per tutti gli utenti prendere sempre decisioni pienamente informate, il modello di autorizzazioni Android rende le informazioni sulle applicazioni facilmente accessibili a una vasta gamma di utenti. Ad esempio, richieste di autorizzazioni impreviste possono indurre gli utenti più sofisticati a porre domande critiche sulla funzionalità dell'applicazione e condividere le loro preoccupazioni in luoghi come Google Play in cui sono visibili a tutti gli utenti.

Autorizzazioni all'installazione dell'applicazione - Google Maps Autorizzazioni di un'applicazione installata - Gmail
Autorizzazioni all'installazione dell'applicazione - Google MapsAutorizzazioni di un'applicazione installata - Gmail

Figura 1. Visualizzazione delle autorizzazioni per le applicazioni

Comunicazione tra processi

I processi possono comunicare usando uno qualsiasi dei tradizionali meccanismi di tipo UNIX. Gli esempi includono il filesystem, i socket locali o i segnali. Tuttavia, le autorizzazioni di Linux si applicano ancora.

Android offre anche nuovi meccanismi IPC:

  • Raccoglitore : un meccanismo di chiamata di procedura remota leggero basato su funzionalità progettato per prestazioni elevate durante l'esecuzione di chiamate in-process e tra processi. Binder è implementato usando un driver Linux personalizzato. Vedi https://developer.android.com/reference/android/os/Binder.html .

  • Servizi : i servizi (discussi sopra) possono fornire interfacce direttamente accessibili tramite il raccoglitore.

  • Intenti : un Intento è un semplice oggetto messaggio che rappresenta una "intenzione" di fare qualcosa. Ad esempio, se l'applicazione desidera visualizzare una pagina Web, esprime il suo "Intento" per visualizzare l'URL creando un'istanza Intento e consegnandola al sistema. Il sistema individua un altro pezzo di codice (in questo caso, il Browser) che sa come gestire quell'Intento e lo esegue. Gli intenti possono anche essere utilizzati per trasmettere eventi interessanti (come una notifica) a livello di sistema. Vedi https://developer.android.com/reference/android/content/Intent.html .

  • ContentProviders : ContentProvider è un data store che fornisce l'accesso ai dati sul dispositivo; l'esempio classico è ContentProvider utilizzato per accedere all'elenco dei contatti dell'utente. Un'applicazione può accedere ai dati esposti da altre applicazioni tramite ContentProvider e un'applicazione può anche definire i propri ContentProviders per esporre i propri dati. Vedi https://developer.android.com/reference/android/content/ContentProvider.html .

Sebbene sia possibile implementare IPC utilizzando altri meccanismi come socket di rete o file scrivibili in tutto il mondo, questi sono i framework IPC Android consigliati. Gli sviluppatori Android saranno incoraggiati a utilizzare le migliori pratiche per proteggere i dati degli utenti ed evitare l'introduzione di vulnerabilità della sicurezza.

API sensibili ai costi

Un'API sensibile ai costi è qualsiasi funzione che potrebbe generare un costo per l'utente o la rete. La piattaforma Android ha inserito le API sensibili ai costi nell'elenco delle API protette controllate dal sistema operativo. L'utente dovrà concedere l'autorizzazione esplicita alle applicazioni di terzi che richiedono l'utilizzo di API sensibili ai costi. Queste API includono:

  • Telefonia
  • SMS / MMS
  • Rete / dati
  • Fatturazione in-app
  • Accesso NFC

Android 4.2 aggiunge ulteriore controllo sull'uso degli SMS. Android fornirà una notifica se un'applicazione tenta di inviare SMS a un codice funzione che utilizza servizi premium che potrebbero causare costi aggiuntivi. L'utente può scegliere se consentire all'applicazione di inviare il messaggio o bloccarlo.

Accesso alla carta SIM

L'accesso di basso livello alla carta SIM non è disponibile per le app di terze parti. Il sistema operativo gestisce tutte le comunicazioni con la carta SIM, incluso l'accesso alle informazioni personali (contatti) sulla memoria della carta SIM. Inoltre, le applicazioni non possono accedere ai comandi AT, poiché sono gestite esclusivamente da Radio Interface Layer (RIL). RIL non fornisce API di alto livello per questi comandi.

Informazione personale

Android ha inserito le API che forniscono l'accesso ai dati degli utenti nel set di API protette. Con il normale utilizzo, i dispositivi Android accumuleranno anche i dati degli utenti all'interno di applicazioni di terzi installate dagli utenti. Le applicazioni che scelgono di condividere queste informazioni possono utilizzare i controlli delle autorizzazioni del sistema operativo Android per proteggere i dati da applicazioni di terze parti.

Accesso a dati sensibili dell'utente disponibili solo tramite API protette

Figura 2. L'accesso ai dati sensibili dell'utente è disponibile solo tramite API protette

I fornitori di contenuti di sistema che probabilmente contengono informazioni personali o identificabili come contatti e calendario sono stati creati con autorizzazioni chiaramente identificate. Questa granularità fornisce all'utente una chiara indicazione dei tipi di informazioni che possono essere fornite all'applicazione. Durante l'installazione, un'applicazione di terze parti può richiedere l'autorizzazione per accedere a queste risorse. Se viene concessa l'autorizzazione, l'applicazione può essere installata e avrà accesso ai dati richiesti in qualsiasi momento al momento dell'installazione.

Tutte le applicazioni che raccolgono informazioni personali avranno, per impostazione predefinita, tali dati limitati solo alla specifica applicazione. Se un'applicazione sceglie di rendere i dati disponibili per altre applicazioni tramite IPC, l'applicazione che concede l'accesso può applicare autorizzazioni al meccanismo IPC che vengono applicate dal sistema operativo.

Dispositivi di input di dati sensibili

I dispositivi Android forniscono frequentemente dispositivi di input di dati sensibili che consentono alle applicazioni di interagire con l'ambiente circostante, come videocamera, microfono o GPS. Affinché un'applicazione di terze parti possa accedere a questi dispositivi, deve prima essere esplicitamente fornita all'utente l'accesso tramite l'uso delle autorizzazioni del sistema operativo Android. Al momento dell'installazione, il programma di installazione richiederà all'utente di richiedere l'autorizzazione al sensore per nome.

Se un'applicazione desidera conoscere la posizione dell'utente, l'applicazione richiede un'autorizzazione per accedere alla posizione dell'utente. Al momento dell'installazione, il programma di installazione richiederà all'utente che chiede se l'applicazione può accedere alla posizione dell'utente. In qualsiasi momento, se l'utente non desidera che alcuna applicazione acceda alla propria posizione, l'utente può eseguire l'applicazione "Impostazioni", andare su "Posizione e sicurezza" e deselezionare "Usa reti wireless" e "Abilita satelliti GPS" . Ciò disabiliterà i servizi basati sulla posizione per tutte le applicazioni sul dispositivo dell'utente.

Device Metadata

Android si impegna inoltre a limitare l'accesso ai dati che non sono intrinsecamente sensibili, ma che possono rivelare indirettamente caratteristiche sull'utente, le preferenze dell'utente e il modo in cui utilizzano un dispositivo.

Per impostazione predefinita, le applicazioni non hanno accesso ai registri del sistema operativo, alla cronologia del browser, al numero di telefono o alle informazioni di identificazione hardware / di rete. Se un'applicazione richiede l'accesso a queste informazioni al momento dell'installazione, il programma di installazione richiederà all'utente che chiede se l'applicazione può accedere alle informazioni. Se l'utente non concede l'accesso, l'applicazione non verrà installata.

Autorità di certificazione

Android include una serie di autorità di certificazione del sistema installate, affidabili a livello di sistema. Prima di Android 7.0, i produttori di dispositivi potevano modificare il set di CA spedite sui loro dispositivi. Tuttavia, i dispositivi con 7.0 e versioni successive disporranno di un set uniforme di CA di sistema poiché non sono più consentite modifiche da parte dei produttori di dispositivi.

Per essere aggiunta come nuova CA pubblica al set di azioni Android, la CA deve completare il processo di inclusione della CA Mozilla e quindi presentare una richiesta di funzione su Android ( https://code.google.com/p/android/issues/entry ) per aggiungere la CA alla CA Android di serie impostata nel progetto Android Open Source (AOSP).

Esistono ancora CA che sono specifiche del dispositivo e non dovrebbero essere incluse nel set principale di CA AOSP, come le CA private dei gestori che potrebbero essere necessarie per accedere in modo sicuro ai componenti dell'infrastruttura del corriere, come i gateway SMS / MMS. I produttori di dispositivi sono invitati a includere le CA private solo nei componenti / app che devono fidarsi di queste CA. Per ulteriori dettagli, consultare Configurazione della sicurezza di rete .

Firma dell'applicazione

La firma del codice consente agli sviluppatori di identificare l'autore dell'applicazione e di aggiornare la propria applicazione senza creare interfacce e autorizzazioni complicate. Ogni applicazione che viene eseguita sulla piattaforma Android deve essere firmata dallo sviluppatore. Le applicazioni che tentano di installare senza essere firmate vengono rifiutate da Google Play o dal programma di installazione del pacchetto sul dispositivo Android.

Su Google Play, la firma delle applicazioni collega la fiducia che Google ha con lo sviluppatore e la fiducia che lo sviluppatore ha con la sua applicazione. Gli sviluppatori sanno che la loro applicazione è fornita, non modificata sul dispositivo Android; e gli sviluppatori possono essere ritenuti responsabili per il comportamento della loro applicazione.

Su Android, la firma dell'applicazione è il primo passo per posizionare un'applicazione nella sua Sandbox applicazione. Il certificato dell'applicazione firmato definisce quale ID utente è associato a quale applicazione; diverse applicazioni vengono eseguite con ID utente diversi. La firma dell'applicazione garantisce che un'applicazione non possa accedere ad altre applicazioni se non tramite IPC ben definito.

Quando un'applicazione (file APK) è installata su un dispositivo Android, Gestione pacchetti verifica che l'APK sia stato correttamente firmato con il certificato incluso in quell'APK. Se il certificato (o, più precisamente, la chiave pubblica nel certificato) corrisponde alla chiave utilizzata per firmare qualsiasi altro APK sul dispositivo, il nuovo APK ha la possibilità di specificare nel manifest che condividerà un UID con l'altro in modo simile APK firmati.

Le domande possono essere firmate da terzi (OEM, operatore, mercato alternativo) o autofirmate. Android fornisce la firma del codice utilizzando certificati autofirmati che gli sviluppatori possono generare senza assistenza o autorizzazione esterne. Le domande non devono essere firmate da un'autorità centrale. Android attualmente non esegue la verifica della CA per i certificati dell'applicazione.

Le applicazioni sono anche in grado di dichiarare le autorizzazioni di sicurezza a livello di protezione della firma, limitando l'accesso solo alle applicazioni firmate con la stessa chiave mantenendo UID e sandbox dell'applicazione distinti. Una relazione più stretta con un Sandbox applicazione condiviso è consentita tramite la funzione UID condivisa in cui due o più applicazioni firmate con la stessa chiave sviluppatore possono dichiarare un UID condiviso nel loro manifest.

Verifica dell'applicazione

Android 4.2 e versioni successive supportano la verifica dell'applicazione. Gli utenti possono scegliere di abilitare "Verifica app" e far valutare le applicazioni da un verificatore dell'applicazione prima dell'installazione. La verifica dell'app può avvisare l'utente se tentano di installare un'app che potrebbe essere dannosa; se un'applicazione è particolarmente dannosa, può bloccare l'installazione .

gestione dei diritti digitali

La piattaforma Android offre un framework DRM estensibile che consente alle applicazioni di gestire i contenuti protetti dai diritti in base ai vincoli di licenza associati al contenuto. Il framework DRM supporta molti schemi DRM; quali schemi DRM supportati da un dispositivo sono lasciati al produttore del dispositivo.

Il framework Android DRM è implementato in due livelli architettonici (vedi figura sotto):

  • Un'API del framework DRM, che è esposta alle applicazioni tramite il framework delle applicazioni Android e che esegue la VM Dalvik per applicazioni standard.

  • Un gestore DRM di codice nativo, che implementa il framework DRM ed espone un'interfaccia per plug-in (agenti) DRM per gestire la gestione dei diritti e la decrittazione per vari schemi DRM

Architettura di Digital Rights Management su piattaforma Android

Figura 3. Architettura della gestione dei diritti digitali su piattaforma Android