Best practice per la sicurezza del sistema

Questa sezione contiene consigli per garantire la sicurezza del sistema operativo Android di base e dei dispositivi.

Autenticazione biometrica

Acquisisci, archivia ed elabora con attenzione i dati biometrici per l'autenticazione degli utenti. Al termine del corso dovreste essere in grado di:

  • Imposta il metodo di autenticazione principale prima di utilizzare qualsiasi altra forma di autenticazione (incluse le biometriche).
  • Richiedi una conferma esplicita per indicare l'intenzione quando utilizzi modalità biometriche passive, come il riconoscimento facciale, per le transazioni (ad esempio i pagamenti) che coinvolgono chiavi legate all'autenticazione.
  • Richiedi il metodo di autenticazione principale ogni 72 ore.
  • Utilizza una pipeline completamente sicura per tutti i dati biometrici e la relativa gestione.
  • Non inviare mai i dati biometrici (incluse le misurazioni dei sensori non elaborate e le funzionalità derivate) al di fuori del dispositivo. Se possibile, mantieni questi dati in un ambiente sicuro e isolato, come un Trusted Execution Environment (TEE) o un Secure Element.

I dispositivi con funzionalità biometriche devono supportare l'API BiometricPrompt, che offre un'interfaccia comune e coerente per consentire agli sviluppatori di app di sfruttare l'autenticazione basata sulla biometria nelle loro app. Solo la biometria di BiometricPrompt può essere integrata con BiometricPrompt e le integrazioni devono rispettare le linee guida del Compatibility Definition Document (CDD) di Android.

Per ulteriori linee guida sulla biometria, consulta le linee guida sull'implementazione dell'HAL biometrica.

SELinux

SELinux fornisce la definizione e l'applicazione di gran parte del modello di sicurezza di Android. L'utilizzo corretto di SELinux è fondamentale per la sicurezza dei dispositivi Android e può contribuire a mitigare l'impatto delle vulnerabilità di sicurezza. Per questo motivo, tutti i dispositivi Android devono implementare una norma SELinux solida.

  • Implementa un criterio di privilegio minimo.
  • Evita di concedere le autorizzazioni CAP_DAC_OVERRIDE, CAP_SYS_ADMIN e CAP_NET_ADMIN.
  • Non registrare i dati di sistema sulla scheda SD.
  • Utilizza i tipi forniti per l'accesso del conducente, ad esempio gpu_device, audio_device e così via.
  • Utilizza nomi significativi per processi, file e tipi SELinux.
    • Assicurati che le etichette predefinite non vengano utilizzate e che non venga concesso loro l'accesso.
  • I criteri specifici del dispositivo devono rappresentare il 5-10% dei criteri complessivi in esecuzione su un dispositivo. Le personalizzazioni nell'intervallo superiore al 20%contengono quasi certamente domini con privilegi eccessivi e norme non più valide. Un criterio eccessivamente grande spreca memoria, spazio su disco perché richiede un'immagine di avvio più grande e influisce negativamente sui tempi di ricerca dei criteri di runtime.

Caricamento dinamico del criterio SELinux

Non caricare dinamicamente i criteri SELinux sui dispositivi Android. perché questo potrebbe causare dei problemi, ad esempio:

  • Impedire l'accettazione di patch di sicurezza critiche.
  • Esposizione della possibilità di eseguire il root di un dispositivo tramite il ricaricamento dei criteri.
  • Esposizione di un vettore per attacchi man-in-the-middle contro l'aggiornamento delle norme.
  • Di conseguenza, i dispositivi non possono più essere utilizzati a causa di errori relativi agli aggiornamenti dei criteri.

Backdoor

Le app per Android non devono avere backdoor o modi per accedere al sistema o ai dati che aggirino i normali meccanismi di sicurezza. Sono inclusi l'accesso speciale per diagnostica, debugging, sviluppo o riparazione in garanzia, controllato da secret noti allo sviluppatore. Per evitare backdoor:

  • Esegui la scansione di tutte le app di terze parti utilizzando uno strumento di scansione delle vulnerabilità delle app riconosciuto dal settore.
  • Esegui revisioni del codice di tutto il codice con accesso sensibile, incluse le librerie di terze parti.
  • Utilizza Google Play Protect caricando le app su Google Play per la scansione. Puoi caricare app per la scansione senza pubblicarle su Google Play.
  • Non precaricare strumenti incentrati sulla diagnostica o sulla riparazione nelle build di release. Installa questi strumenti solo su richiesta per risolvere problemi specifici. Inoltre, questi strumenti non devono utilizzare né caricare dati specifici dell'account.

Strumenti di sviluppo

Gli strumenti di sviluppo, come gli strumenti di debug, di test e di diagnostica, spesso possono creare lacune di sicurezza impreviste sul tuo dispositivo rivelando il loro funzionamento e i dati che raccolgono. Per assicurarti che gli strumenti di sviluppo non vengano inclusi nelle build di produzione:

  • Sviluppare una lista nera di hash degli strumenti di debug e test interni e analizzare le build per questi APK prima di utilizzare l'immagine di sistema.
  • Esegui la scansione di tutte le app proprietarie utilizzando uno strumento di scansione delle vulnerabilità delle app riconosciuto dal settore.
  • Rivolgiti a una società di test di sicurezza delle app di terze parti per valutare tutte le app di diagnostica on-device critiche prima di qualsiasi aggiornamento importante, in particolare se l'app è sviluppata da terze parti.
  • Assicurati che solo l'utente possa attivare lo strumento, verbalmente o via chat, durante una sessione di assistenza. Memorizza gli elementi del consenso e disattiva lo strumento dopo aver raccolto le informazioni diagnostiche necessarie.
  • Memorizzare il record di utilizzo di questo strumento in un log accessibile dall'utente nel suo account dell'operatore.
  • Assicurati che tutte le informazioni che consentono l'identificazione personale (PII) o i dati di telemetria del dispositivo raccolti dallo strumento siano soggetti a pratiche di anonimizzazione, conservazione ed eliminazione pertinenti al paese. Devono essere raccolti solo i dati pertinenti per la chiamata di assistenza. Questi dati devono essere eliminati dopo ogni chiamata.
  • Assicurati che le tecniche che possono essere utilizzate per gli spyware, come la registrazione delle sequenze di tasti, l'utilizzo del microfono o della videocamera, non vengano utilizzate senza il consenso esplicito dell'utente. Le app che utilizzano questi metodi potenzialmente invasivi della privacy devono essere comunicate in modo molto chiaro, insieme a norme sulla privacy a cui l'utente deve dare il consenso. App come questa non devono essere attivate senza il consenso esplicito dell'utente.

Ecco alcuni suggerimenti aggiuntivi da consultare per l'implementazione di informative e consenso:

Informativa in-app

  • Mostra il normale utilizzo dell'app direttamente nell'app. Non richiedere all'utente di aprire un menu o le impostazioni.
  • Descrivi il tipo di dati raccolti e spiega come vengono utilizzati.
  • È preferibile non incorporare queste informazioni nelle norme sulla privacy o nei termini di servizio. Non includerla in altre informative non correlate alla raccolta di dati personali o sensibili.
  • Il consenso deve essere affermativo. Non considerare l'uscita dalla finestra contenente l'informativa (ad esempio, tocco fuori dalla finestra oppure pressione del pulsante Home o Indietro) come espressione del consenso.
  • Presenta la finestra di dialogo per il consenso in modo chiaro e inequivocabile.
  • Richiedi un intervento dell'utente (ad esempio tocco per accettazione o comando vocale) per l'accettazione.
  • Non raccogliere dati personali o sensibili prima di ottenere il consenso esplicito.
  • Non utilizzare messaggi con scadenza o chiusura automatica.

Funzionalità integrate in AOSP

L'inserimento di funzionalità aggiuntive in AOSP può spesso avere comportamenti e conseguenze imprevisti. Procedi con cautela.

  • Assicurati che all'utente venga chiesto se vuole utilizzare app predefinite diverse (ad esempio, motore di ricerca, browser web, app di avvio) e comunicagli che i dati verranno inviati al di fuori del dispositivo.
  • Assicurati che gli APK AOSP siano firmati con il certificato AOSP.
  • Esegui test di regressione e tieni un log delle modifiche per determinare se è stato aggiunto codice agli APK AOSP.

Aggiornamenti della sicurezza

I dispositivi Android dovrebbero ricevere assistenza continua per la sicurezza per almeno due anni dal lancio. Ciò include la ricezione di aggiornamenti regolari che risolvono vulnerabilità di sicurezza note.

  • Collabora con i partner hardware, ad esempio i fornitori di SoC, per stipulare contratti di assistenza appropriati per tutti i componenti del tuo dispositivo Android.
  • Assicurati che gli aggiornamenti di sicurezza possano essere installati con un'interazione minima da parte dell'utente per aumentare la probabilità che gli utenti accettino e installino gli aggiornamenti sul proprio dispositivo Android. È vivamente consigliata l'implementazione di Aggiornamenti di sistema senza interruzioni o di una funzionalità di sicurezza equivalente.
  • Assicurati di comprendere il requisito cumulativo del livello patch di sicurezza Android (SPL) come dichiarato nel bollettino sulla sicurezza Android. Ad esempio, i dispositivi che utilizzano il livello della patch di sicurezza 01-02-2018 devono includere tutti i problemi associati a quel livello della patch di sicurezza, nonché le correzioni per tutti i problemi segnalati in tutti i bollettini sulla sicurezza precedenti.

Aggiornamenti dinamici del kernel

Non modificare dinamicamente i componenti di sistema critici. Sebbene alcuni studi suggeriscano che gli aggiornamenti dinamici del kernel contribuiscano a proteggere dalle minacce di emergenza, al momento il costo valutato supera i vantaggi. Crea invece un metodo di aggiornamento OTA solido per distribuire rapidamente le protezioni dalle vulnerabilità.

Gestione delle chiavi

Mantieni buoni criteri e buone pratiche di gestione delle chiavi per garantire la sicurezza delle chiavi di firma.

  • Non condividere le chiavi di firma con terze parti.
  • Se una chiave di firma è compromessa, genera una nuova chiave e firma tutte le app con doppia firma in futuro.
  • Memorizza tutte le chiavi in hardware o servizi di moduli ad alta sicurezza che richiedono molteplici fattori di accesso.

Firma dell'immagine di sistema

La firma dell'immagine di sistema è fondamentale per determinare l'integrità del dispositivo.

  • Non firmare i dispositivi con una chiave nota pubblicamente.
  • Gestisci le chiavi di firma del dispositivo in modo coerente con le pratiche standard di settore per la gestione delle chiavi sensibili, incluso un modulo di sicurezza hardware (HSM) che fornisce un accesso limitato e verificabile.

Bootloader sbloccabili

Molti dispositivi Android supportano lo sblocco, consentendo al proprietario del dispositivo di modificare la partizione di sistema o installare un sistema operativo personalizzato. I casi d'uso comuni includono l'installazione di un'immagine di sistema di terze parti ed eseguire lo sviluppo a livello di sistema sul dispositivo. Ad esempio, per sbloccare l'immagine di sistema su un Google Nexus o Pixel, un utente può eseguire fastboot oem unlock, che mostra questo messaggio:

Come best practice, i dispositivi Android sbloccabili devono cancellare in modo sicuro tutti i dati utente prima di essere sbloccati. La mancata eliminazione corretta di tutti i dati al momento dello sblocco potrebbe consentire a un malintenzionato fisicamente vicino di ottenere accesso non autorizzato ai dati utente riservati di Android. Per impedire la divulgazione dei dati dell'utente, un dispositivo che supporta lo sblocco deve implementarlo correttamente.

  • Dopo che l'utente ha confermato il comando di sblocco, il dispositivo deve avviare un reset dei dati immediato. Il flag unlocked non deve essere impostato fino al completamento dell'eliminazione sicura.
  • Se non è possibile completare un'eliminazione sicura, il dispositivo deve rimanere in stato bloccato.
  • Se supportato dal dispositivo di blocco sottostante, deve essere utilizzato ioctl(BLKSECDISCARD) o un equivalente. Per i dispositivi con MultiMediaCard (eMMC) integrate, significa utilizzare un comando Secure Erase o Secure Trim. Per eMMC 4.5 e versioni successive, significa utilizzare un normale Erase o Trim seguito da un'operazione di Sanitize.
  • Se BLKSECDISCARD non è supportato dal dispositivo di blocco di base, deve essere utilizzato ioctl(BLKDISCARD). Sui dispositivi eMMC, si tratta di un'operazione di Trim normale.
  • Se BLKDISCARD non è supportato, è accettabile sovrascrivere i dispositivi di blocco con tutti gli zeri.
  • Un utente deve avere la possibilità di richiedere l'eliminazione dei dati utente prima di eseguire il flashing di una partizione. Ad esempio, i dispositivi Nexus utilizzano il comando fastboot oem lock per cancellare i dati utente.
  • Un dispositivo può registrare, tramite eFuse o un meccanismo simile, se è stato sbloccato e/o bloccato di nuovo. Tuttavia, ti consigliamo vivamente di bloccare nuovamente il bootloader con il successivo ripristino dei dati di fabbrica per ripristinare la funzionalità completa del dispositivo.

Questi requisiti garantiscono che tutti i dati vengano distrutti al termine di un'operazione di sblocco. La mancata implementazione di queste protezioni è considerata una vulnerabilità di sicurezza di livello moderato.

Un dispositivo sbloccato può essere successivamente bloccato di nuovo utilizzando il comando fastboot oem lock. Il blocco del bootloader offre la stessa protezione dei dati utente con il nuovo sistema operativo personalizzato di quella disponibile con il sistema operativo del produttore del dispositivo originale (ad esempio, i dati utente vengono cancellati se il dispositivo viene sbloccato di nuovo).

Test di penetrazione del dispositivo

I dispositivi devono essere esaminati da un pentester competente prima della spedizione. Il pentest deve stabilire che il dispositivo abbia seguito le linee guida per la sicurezza fornite qui, nonché le linee guida per la sicurezza dell'OEM interno.

Test di sicurezza

Utilizza gli strumenti di test di sicurezza forniti da AOSP. In particolare

  • Utilizza strumenti di sicurezza della memoria durante lo sviluppo: utilizza MTE se supportato (ARMv9 e versioni successive) e HWASan se non è supportato. Esegui il maggior numero possibile di test con questi strumenti attivati.
  • Utilizza GWP-ASan e KFENCE in produzione per il rilevamento probabilistico di problemi di sicurezza della memoria.