Esclusivo: Google prevede di allentare gli aggiornamenti di sicurezza per Android Enterprise Recommendation

Mentre Android è il sistema operativo per smartphone complessivamente dominante secondo i dati di IDC, iOS di Apple è il sistema operativo preferito dalla maggior parte delle aziende. È facile capire perché: Apple aggiorna i suoi dispositivi iOS generalmente molto più a lungo e in modo più coerente rispetto alla maggior parte dei produttori di dispositivi Android aggiornare i propri smartphone, gli iPhone sono semplici da configurare e gestire e ci sono molti meno SKU da supportare se un'azienda sceglie Mela. Ma ci sono anche ragioni che spingono le aziende a scegliere un dispositivo Android, tra cui costi ridotti e maggiore flessibilità nell'hardware. Per rendere Android ancora più allettante per il posto di lavoro, all'inizio del 2015 Google ha lanciato "Android for Work" (successivamente rinominato "Android Enterprise"

alla fine del 2016). Poi, all’inizio del 2018, Google ha lanciato il Programma Android Enterprise Consigliato (AER). per certificare i dispositivi per uso aziendale. Google ha codificato una serie di requisiti che i dispositivi devono soddisfare per essere "Android Enterprise Recommendations", tra cui specifiche hardware minime, supporto per l'implementazione in blocco, disponibilità di dispositivi sbloccati, coerenza del comportamento delle app in esecuzione nei profili gestiti e consegna degli aggiornamenti di sicurezza Android entro 90 giorni dal rilascio per un minimo di tre anni.

Tuttavia, i documenti scoperti dallo sviluppatore Android @deletescape che sono stati recensiti da Sviluppatori XDA rivelano che Google sta pianificando di allentare i requisiti di aggiornamento della sicurezza per i dispositivi Android Enterprise Recommendation. Invece, Google sta spingendo affinché i fornitori siano più trasparenti su come gestiscono gli aggiornamenti di sicurezza. Secondo @deletescape, questi documenti sono stati condivisi con i fornitori negli ultimi 15 giorni. Pertanto, anche se non possiamo garantire che queste modifiche proposte ad Android Enterprise Recommendation si facciano strada nell'elenco finale dei requisiti, possiamo almeno confermare che Google li ha presi in considerazione molto recentemente i cambiamenti.

attualmente ci sono 170 diversi dispositivi Android che sono consigliati per Android Enterprise. HMD globale, Sony, Motorola, OPPO, e naturalmente, Google, offrono dispositivi AER. Anche OnePlus sta valutando la possibilità di certificare i propri dispositivi nell'ambito del programma. Tuttavia, i noti marchi di smartphone di consumo non sono le uniche aziende a vendere dispositivi Android Enterprise Recommendation. Smartphone robusti di aziende come Zebra, Honeywell, Sonim e altre sono incluse nel programma, e ora anche i vettori può vendere dispositivi AER direttamente alle aziende, a condizione che approvino rapidamente le versioni di manutenzione della sicurezza.

Il flusso di provisioning del dispositivo in Android 10. Fonte: Jason Bayton

IL elenco dei requisiti necessario per entrare in AER non è così ampio: molti più dispositivi Android avrebbero potuto essere inclusi nell'elenco dati i bassi requisiti hardware di base. Anche i requisiti software di AER non richiedono molte modifiche da parte dei fornitori, come sottolineato da diversi documenti interni di Google. Uno dei documenti descrive come i fornitori devono progettare badge icona per le app nel profilo di lavoro, aggiungere una scheda dedicata per le app del profilo di lavoro nel Avvio applicazioni, destinazioni di condivisione separate per le app nel profilo personale e di lavoro, precaricare alcune applicazioni Google e gestire i dati di più profili comunicazione. Un altro documento descrive i requisiti UX per la scheda di avvio del profilo di lavoro, Impostazione rapida del profilo di lavoro riquadro, finestre di dialogo del profilo di lavoro, messaggi didattici di avvio, cambio di contesto e altre progettazioni di sistema elementi. Questi requisiti mirano a promuovere uno standard minimo di hardware accettabile e la coerenza dell'esperienza utente del software tra i dispositivi Android Enterprise Recommendation.

Tuttavia, sembra che i dispositivi siano tenuti a ricevere rapidamente aggiornamenti mensili delle patch di sicurezza Bollettino sulla sicurezza Android (ASB) ha dimostrato di essere una barriera troppo alta per molti fornitori.

Google spinge per la trasparenza degli aggiornamenti per Android Enterprise Recommendations

Sviluppatore Android @deletescape, che ha recentemente condiviso una bozza trapelata di Documento di definizione della compatibilità di Google per Android 11, ha ottenuto una bozza trapelata dei nuovi requisiti Android Enterprise Recommendation per i dispositivi con Android 11. Sotto il "Sicurezza del dispositivo", che riproduciamo di seguito, Google propone la rimozione di una serie di requisiti per il programma AER. In base a queste nuove regole proposte, ai dispositivi AER non sarà più garantita la ricezione degli aggiornamenti delle patch di sicurezza entro 90 giorni da un ASB. È interessante notare che una delle righe nel grafico suggerisce che Google abbia effettivamente ridotto questo requisito da 90 giorni a 30 giorni con il passaggio ad Android 10, ma Google non ha ancora aggiornato i requisiti. elenco pubblico dei requisiti per riflettere questo cambiamento. Tuttavia, in base alle modifiche proposte, questo requisito non si applicherà più ai dispositivi Android Enterprise Recommendation con Android 11. Inoltre, i fornitori non saranno più tenuti a fornire 3 anni di aggiornamenti di sicurezza regolari per i dispositivi AER. Saranno comunque tenuti a fornire gli aggiornamenti "Emergency Security Maintenance Release" (ESMR), il che presumibilmente significa che devono solo implementare aggiornamenti contenenti correzioni per la sicurezza critica vulnerabilità.

Android 10 e Android 11: requisiti di sicurezza del dispositivo per Android Enterprise consigliati

Categoria	Numero di serie	DEVONO/MAGGIO	Attributo e implementazione	Commenti
Q (Android 10)	R (Android 11)
Sicurezza del dispositivo	1	MAGGIO	Gestire un programma di premi per la vulnerabilità OEM (VRP)	Gestire un programma di premi per la vulnerabilità OEM (VRP)
2	MAGGIO	Supporto StrongBox	Supporto StrongBox
3	MAGGIO	Supporto per l'archivio chiavi supportato da hardware	Supporto per l'archivio chiavi supportato da hardware
4	MAGGIO	Supporto per l'attestazione dell'ID dispositivo	Supporto per l'attestazione dell'ID dispositivo
5	MAGGIO	Supporto per l'attestazione chiave	Supporto per l'attestazione chiave
6	Aggiornamenti di sicurezza di 30 giorni	Requisito rimosso	Sostituito con il requisito di trasparenza della sicurezza
7	DOVERE	3 anni di supporto per il rilascio di mantenimento della sicurezza di emergenza (ESMR)	3 anni di supporto per il rilascio di mantenimento della sicurezza di emergenza (ESMR)	Sostituito con il requisito di trasparenza della sicurezza
8	Crittografia basata su file: attivata per impostazione predefinita. Utilizza l'implementazione AOSP.	Requisito rimosso	Questo è un requisito GMS applicato a tutti i dispositivi
9	Aggiornamenti di sicurezza di 90 giorni	Requisito rimosso	Sostituito con il requisito di trasparenza della sicurezza
10	Supporto per aggiornamenti di sicurezza di 3 anni (può essere inferiore al 3° anno ESMR)	Requisito rimosso	Sostituito con il requisito di trasparenza della sicurezza
11	Pubblica l'ultimo livello di patch di sicurezza	Requisito rimosso	Sostituito con il requisito di trasparenza della sicurezza

Per saperne di più

Come accennato nel grafico, Google propone di sostituire molti di questi requisiti con nuovi requisiti di “trasparenza”. Infatti, Google propone l'aggiunta di una nuova sezione intitolata "Trasparenza degli aggiornamenti di sicurezza/sistema operativo." I nuovi requisiti descrivono in dettaglio come i fornitori saranno tenuti a pubblicare informazioni quali la data di fine vita delle versioni di manutenzione della sicurezza, l'ultima patch di sicurezza disponibili, la frequenza con cui il dispositivo riceverà gli aggiornamenti, le correzioni contenute in ciascun aggiornamento, la spedizione e gli aggiornamenti software pianificati del dispositivo e altro ancora. È interessante notare che Google richiede anche che i dispositivi Android 11 siano sottoposti a test di certificazione da parte di Alleanza ioXt prima che possano diventare Android Enterprise Recommendations. La ioXt Alliance è un'alleanza di aziende il cui obiettivo è migliorare la sicurezza dei prodotti IoT. I suoi membri includono Amazon, Facebook, Google, NXP e altri. Google afferma che avere questa certificazione aumenterà la trasparenza, presumibilmente poiché darà alle aziende un parametro indipendente della sicurezza di un particolare dispositivo e non solo quello di Google assicurazione.

Requisiti di trasparenza degli aggiornamenti di sicurezza/sistema operativo (nuovi) per Android Enterprise consigliati

Categoria	Numero di serie	DEVONO/MAGGIO	Attributo e implementazione	Commenti
Q (Android 10)	R (Android 11)
Trasparenza degli aggiornamenti di sicurezza/sistema operativo	1	DOVERE	DEVE pubblicare le seguenti informazioni sugli aggiornamenti sul sito Web OEM - Data di fine del supporto SMR (ultima data in cui il dispositivo riceverà SMR) - Più recente patch di sicurezza disponibile - Frequenza degli aggiornamenti che il dispositivo riceverà - Correzioni contenute nella patch di sicurezza, incluse quelle specifiche dell'OEM correzioni	Modifica del requisito dal supporto SMR alla trasparenza SMR/patch/aggiornamenti
2	DOVERE	DEVE pubblicare le seguenti informazioni sul sistema operativo sul sito Web dell'OEM: sistema operativo con cui viene fornito il dispositivo, versione principale del sistema operativo corrente, tutti gli aggiornamenti della versione principale del sistema operativo che il dispositivo riceverà	Modifica dei requisiti dal supporto alla trasparenza, ad esempio: Pixel 3- Versione spedita - Android 9- Versione corrente - Android 10- Versione principale prevista - Android 11
3	DOVERE	Sottoporre il dispositivo alla certificazione IoXT	Il punteggio IoXT aumenta la trasparenza

Per saperne di più

Non è un segreto che i fornitori abbiano difficoltà a tenere il passo con l'implementazione degli aggiornamenti mensili delle patch di sicurezza. Ci sono moltissime ragioni per cui è così: ritardi nella certificazione dell'operatore, attesa di patch dal chipset e altro fornitori, la difficoltà di applicare patch a build di framework Android fortemente modificati e kernel Linux fuori struttura e Di più. Alcuni utenti Android hanno persino notato come alcuni fornitori non soddisfano i requisiti AER. Mentre gli sforzi di sviluppo e gli accordi di licenza di Google lo hanno fatto ha contribuito a migliorare Con la rapidità con cui vengono distribuiti gli aggiornamenti di sicurezza per molti dispositivi, chiaramente non sono stati in grado di sostenere gli attuali requisiti delle patch di sicurezza per il programma Android Enterprise Recommendation. Allentare questi requisiti a favore di una maggiore trasparenza contribuirà a rendere il programma più accessibile ai fornitori e dare alle aziende maggiore fiducia nel particolare dispositivo che scelgono per i propri clienti lavoratori.

Naturalmente, il proposto allentamento degli aggiornamenti delle patch di sicurezza non è l'unico cambiamento che potrebbe arrivare al programma Android Enterprise Recommendation per Android 11. Google prevede inoltre di aumentare i requisiti hardware minimi da 2 GB di RAM a 3 GB di RAM, restringere i requisiti di formazione e implementare una nuova serie di requisiti per il profilo di lavoro UX. La maggior parte di questi cambiamenti, tuttavia, non avrà alcun impatto sui lavoratori della conoscenza. Android in ambito aziendale è cresciuto molto sin dai suoi esordi. Se sei interessato a saperne di più sulla sua storia, ti consiglio di leggerlo questo eccellente articolo di Jason Bayton.