Exclusiv: Google intenționează să relaxeze actualizările de securitate pentru Android Enterprise Recommended

În timp ce Android este sistemul de operare dominant pentru smartphone-uri, conform datelor de la IDC, iOS-ul Apple este sistemul de operare ales pentru majoritatea întreprinderilor. Este ușor de înțeles de ce: Apple își actualizează dispozitivele iOS, în general, mult mai mult și mai constant decât majoritatea producătorilor de dispozitive Android își actualizează smartphone-urile, iPhone-urile sunt ușor de configurat și gestionat și există mult mai puține SKU de suportat dacă o companie alege Măr. Dar există și motive pentru care întreprinderile să aleagă un dispozitiv Android, inclusiv costuri reduse și mai multă flexibilitate în hardware. Pentru a face Android și mai atrăgător pentru locul de muncă, Google a lansat „Android for Work” la începutul anului 2015 (denumit ulterior „Android Enterprise” la sfarsitul lui 2016). Apoi, la începutul lui 2018, Google a lansat

Programul Android Enterprise Recommended (AER). pentru a certifica dispozitivele pentru uz comercial. Google a codificat un set de cerințe pe care trebuie să le îndeplinească dispozitivele pentru a fi „Android Enterprise Recommended”, inclusiv specificații hardware minime, suport pentru implementarea în bloc, disponibilitatea dispozitivelor deblocate, consecvența comportamentului aplicației care rulează în profilurile gestionate și livrarea actualizărilor de securitate Android în 90 de zile de la lansare pentru cel puțin trei ani.

Cu toate acestea, documentele descoperite de dezvoltatorul Android @deletescape care au fost revizuite de XDA-Developers dezvăluie că Google intenționează să slăbească cerințele de actualizare de securitate pentru dispozitivele Android Enterprise Recommended. În schimb, Google face eforturi ca furnizorii să fie mai transparenți cu privire la modul în care gestionează actualizările de securitate. Potrivit @deletescape, aceste documente au fost partajate cu furnizorii în ultimele 15 zile. Astfel, deși nu putem garanta că aceste modificări propuse la Android Enterprise Recommended își vor face drumul în lista finală de cerințe, putem confirma cel puțin că Google le-a luat în considerare foarte recent schimbări.

Există în prezent 170 de dispozitive Android diferite care sunt Android Enterprise Recommended. HMD Global, Sony, Motorola, OPPO, și, desigur, Google, oferă dispozitive care sunt AER. Chiar și OnePlus are în vedere certificarea dispozitivelor în cadrul programului. Cu toate acestea, mărcile de smartphone-uri cunoscute pentru consumatori nu sunt singurele companii care vând dispozitive Android Enterprise Recommended. Smartphone-uri robuste de la companii precum Zebra, Honeywell, Sonim și altele sunt incluse în program și acum chiar și transportatorii pot vinde dispozitive AER direct companiilor, cu condiția ca acestea să aprobe rapid versiunile de întreținere a securității.

Fluxul de furnizare a dispozitivului în Android 10. Sursă: Jason Bayton

The lista de cerințe necesare pentru intrarea în AER nu este atât de extinsă – multe alte dispozitive Android ar fi putut face listă, având în vedere cerințele hardware de bază reduse. Nici măcar cerințele software ale AER nu necesită multe modificări de la furnizori, așa cum se subliniază în mai multe documente interne Google. Unul dintre documente subliniază modul în care vânzătorii trebuie să creeze insigne cu pictograme pentru aplicațiile din profilul de lucru, să adauge o filă dedicată pentru aplicațiile din profilul de lucru în lansator, ținte de partajare separate pentru aplicațiile din profilul personal și de serviciu, preîncărcarea anumitor aplicații Google și gestionarea datelor între profiluri comunicare. Un alt document subliniază cerințele UX pentru fila Lansatorul profilului de lucru, Setarea rapidă a profilului de lucru țiglă, dialoguri de profil de lucru, mesaje educaționale pentru lansare, comutare de context și alte designuri de sistem elemente. Aceste cerințe au ca scop promovarea unui standard minim de hardware acceptabil, precum și a coerenței UX software între dispozitivele Android Enterprise Recommended.

Cu toate acestea, se pare că este necesar ca dispozitivele să primească rapid actualizări ale corecțiilor de securitate după fiecare lună Buletin de securitate Android (ASB) s-a dovedit a fi o barieră prea mare pentru mulți furnizori.

Google solicită transparența actualizării pentru Android Enterprise Recomandat

Dezvoltator Android @deletescape, care a împărtășit recent o versiune scursă a lui Documentul de definire a compatibilității Google pentru Android 11, a obținut o schiță divulgată a noilor cerințe Android Enterprise Recommended pentru dispozitivele care rulează Android 11. Sub "Securitatea dispozitivului", pe care am reprodus-o mai jos, Google propune eliminarea unui număr de cerințe pentru programul AER. Conform acestor noi reguli propuse, dispozitivele AER nu vor mai fi garantate să primească actualizări ale corecțiilor de securitate în termen de 90 de zile de la un ASB. Interesant, unul dintre rândurile din grafic sugerează că Google a înăsprit de fapt această cerință de la 90 de zile la 30 de zile odată cu trecerea la Android 10, dar Google încă nu a actualizat lista publică de cerințe pentru a reflecta această schimbare. Cu toate acestea, conform modificărilor propuse, această cerință nu se va mai aplica pentru dispozitivele Android Enterprise Recommended care rulează Android 11. În plus, furnizorii nu vor mai fi obligați să furnizeze 3 ani de actualizări regulate de securitate pentru dispozitivele AER. Cu toate acestea, li se va cere în continuare să furnizeze actualizări „Emergency Security Maintenance Release” (ESMR). ceea ce înseamnă că trebuie doar să lanseze actualizări care conțin remedieri pentru securitatea critică vulnerabilități.

Android 10 versus Android 11 - Cerințe de securitate pentru dispozitive pentru Android Enterprise recomandate

Categorie	Număr de serie	TREBUIE / MAI	Atribut și implementare	Comentarii
Q (Android 10)	R (Android 11)
Securitatea dispozitivului	1	MAI	Operați un program de recompense pentru vulnerabilități OEM (VRP)	Operați un program de recompense pentru vulnerabilități OEM (VRP)
2	MAI	Suport StrongBox	Suport StrongBox
3	MAI	Suport pentru Keystore cu suport hardware	Suport pentru Keystore cu suport hardware
4	MAI	Suport pentru atestarea ID dispozitivului	Suport pentru atestarea ID dispozitivului
5	MAI	Suport pentru atestarea cheie	Suport pentru atestarea cheie
6	Actualizări de securitate de 30 de zile	Cerința a fost eliminată	Înlocuit cu cerința de transparență de securitate
7	TREBUIE SA	Asistență de 3 ani pentru lansarea de întreținere a securității de urgență (ESMR)	Asistență de 3 ani pentru lansarea de întreținere a securității de urgență (ESMR)	Înlocuit cu cerința de transparență de securitate
8	Criptare pe bază de fișiere - activată implicit. Utilizează implementarea AOSP.	Cerința a fost eliminată	Aceasta este o cerință GMS aplicată pentru toate dispozitivele
9	Actualizări de securitate de 90 de zile	Cerința a fost eliminată	Înlocuit cu cerința de transparență de securitate
10	Suport pentru actualizare de securitate de 3 ani (mai sub al treilea an ESMR)	Cerința a fost eliminată	Înlocuit cu cerința de transparență de securitate
11	Publicați cel mai recent nivel de corecție de securitate	Cerința a fost eliminată	Înlocuit cu cerința de transparență de securitate

citeşte mai mult

După cum se menționează în grafic, Google propune înlocuirea multora dintre aceste cerințe cu noi cerințe de „transparență”. Într-adevăr, Google propune adăugarea unei noi secțiuni intitulate „Securitate/OS Actualizări transparență.” Noile cerințe detaliază modul în care furnizorii vor fi obligați să publice informații, cum ar fi data de sfârșit de viață pentru versiunile de întreținere a securității, cel mai recent patch de securitate care este disponibil, cât de des va primi dispozitivul actualizări, ce remedieri sunt conținute în fiecare actualizare, livrarea și actualizările software planificate ale dispozitivului și multe altele. Interesant este că Google solicită, de asemenea, ca dispozitivele Android 11 să fie supuse testării de certificare de către Alianța ioXt înainte ca acestea să devină Android Enterprise Recommended. Alianța ioXt este o alianță de companii al căror scop este îmbunătățirea securității produselor IoT. Printre membrii săi se numără Amazon, Facebook, Google, NXP și multe altele. Google spune că deținerea acestei certificări va spori transparența, probabil din moment ce va oferi întreprinderilor o măsură independentă a cât de sigur este un anumit dispozitiv, mai degrabă decât doar Google asigurare.

Actualizări de securitate/OS Cerințe de transparență (nou) pentru Android Enterprise Recomandat

Categorie	Număr de serie	TREBUIE / MAI	Atribut și implementare	Comentarii
Q (Android 10)	R (Android 11)
Securitate/OS Actualizări transparență	1	TREBUIE SA	TREBUIE să publice următoarele informații de actualizare pe site-ul OEM - Data de încheiere a suportului SMR (ultima dată la care dispozitivul va primi SMR) - Cel mai recent Patch de securitate disponibil- Frecvența actualizărilor pe care le va primi dispozitivul- Remedieri conținute în patch-ul de securitate, inclusiv orice corecție specifică OEM remedieri	Schimbarea cerinței de la suportul SMR la transparența SMR/patch-uri/actualizări
2	TREBUIE SA	TREBUIE să publice următoarele informații despre sistemul de operare pe site-ul web OEM - SO cu care este livrat dispozitivul - Versiunea actuală a sistemului de operare majoră - Toate actualizările majore ale versiunii OS pe care dispozitivul le va primi	Schimbarea cerinței de la asistență la transparență, de exemplu: Pixel 3- Versiune expediată - Android 9- Versiune curentă - Android 10- Versiune majoră așteptată - Android 11
3	TREBUIE SA	Trimiteți dispozitivul la certificarea IoXT	Scorul IoXT adaugă transparență

citeşte mai mult

Nu este un secret pentru nimeni că vânzătorii au probleme în a ține pasul cu lansarea de actualizări lunare ale corecțiilor de securitate. Există multe, multe motive pentru care acesta este cazul: întârzieri în certificarea operatorului, așteptarea patch-urilor de la chipset și alte furnizorilor, dificultatea de a aplica patch-uri la build-uri de framework Android puternic modificate și kernel-uri Linux în afara arborelui și Mai mult. Unii utilizatori de Android chiar au luat în seamă modul în care unii furnizori nu îndeplinește cerințele AER. În timp ce eforturile de dezvoltare ale Google și acordurile de licență au a ajutat la îmbunătățirea cât de repede se lansează actualizările de securitate pentru multe dispozitive, în mod clar nu au reușit să susțină cerințele actuale de corecție de securitate pentru programul Android Enterprise Recommended. Slăbirea acestor cerințe în favoarea unei mai mari transparențe va contribui atât la a face programul mai accesibil furnizorilor și, de asemenea, oferă întreprinderilor mai multă încredere în dispozitivul ales pentru ele muncitorii.

Relaxarea propusă a actualizărilor de corecție de securitate nu este singura modificare care ar putea veni în programul Android Enterprise Recommended pentru Android 11, desigur. De asemenea, Google intenționează să crească cerințele minime de hardware de la 2 GB de RAM la 3 GB de RAM, să înăsprească cerințele de instruire și să implementeze un nou set de cerințe pentru profilul de lucru UX. Cu toate acestea, majoritatea acestor schimbări nu vor afecta lucrătorii cunoștințe. Android în întreprindere a crescut foarte mult de la începuturile sale. Dacă sunteți interesat să aflați mai multe despre istoria sa, vă recomand să citiți acest articol excelent de la Jason Bayton.