Exkluzív: A Google azt tervezi, hogy enyhíti az Android Enterprise Recommended biztonsági frissítéseit

Míg az Android az összességében domináns okostelefon operációs rendszer az adatok szerint IDC, az Apple iOS a választott operációs rendszer a legtöbb vállalat számára. Könnyen belátható, miért: az Apple általában sokkal hosszabb ideig és következetesebben frissíti iOS-eszközeit, mint a legtöbb Android-eszközgyártó frissítik okostelefonjaikat, az iPhone készülékek konfigurálása és kezelése egyszerű, és sokkal kevesebb SKU-t kell támogatni, ha egy vállalat választ. Alma. De vannak olyan okok is, amelyek miatt a vállalkozások Android-eszközt választanak, beleértve az alacsonyabb költségeket és a nagyobb rugalmasságot a hardverben. Annak érdekében, hogy az Android még vonzóbbá tegye a munkahelyet, a Google 2015 elején elindította az "Android for Work" nevű programot (később Android Enterprise néven átkeresztelve). 2016 végén). Aztán 2018 elején a Google elindította a

Android Enterprise Recommended (AER) program üzleti használatra szánt eszközök tanúsítására. A Google kódolt egy sor követelményt, amelyeknek az eszközöknek meg kell felelniük ahhoz, hogy „Android Enterprise Recommended” kategóriába tartozzanak, beleértve a minimális hardverspecifikációkat, a tömeges telepítés támogatását, a feloldott eszközök elérhetősége, a kezelt profilokban futó alkalmazások működésének konzisztenciája, valamint az Android biztonsági frissítéseinek kézbesítése a kiadástól számított 90 napon belül legalább három évek.

Azonban a @ Android fejlesztő által feltárt dokumentumokdeletescape amelyeket áttekintett XDA-fejlesztők kiderül, hogy a Google azt tervezi, hogy lazít a biztonsági frissítési követelményeken az Android Enterprise Recommended eszközökön. Ehelyett a Google azt szorgalmazza, hogy a gyártók átláthatóbban kezeljék a biztonsági frissítéseket. A @deletescape szerint ezeket a dokumentumokat az elmúlt 15 napon belül megosztották a szállítókkal. Így bár nem tudjuk garantálni, hogy az Android Enterprise Recommended programban javasolt változtatások be fognak vezetni a követelmények végső listájába, legalább megerősíthetjük, hogy a Google nemrég vette figyelembe ezeket változtatások.

Jelenleg vannak 170 különböző Android készülék amelyek Android Enterprise által ajánlottak. HMD Global, Sony, Motorola, OPPO, és természetesen, Google, olyan eszközöket kínálnak, amelyek AER. Még a OnePlus is fontolgatja, hogy eszközeit tanúsítsa a program keretében. A jól ismert fogyasztói okostelefon-márkák azonban nem az egyetlen cégek, amelyek Android Enterprise Recommended eszközöket árulnak. Masszív okostelefonok olyan cégektől, mint a Zebra, Honeywell, Sonim és mások szerepelnek a programban, és most akár fuvarozók Az AER eszközöket közvetlenül a vállalkozásoknak értékesíthetik, feltéve, hogy gyorsan jóváhagyják a biztonsági karbantartási kiadásokat.

Az eszköz-kiépítési folyamat az Android 10 rendszerben. Forrás: Jason Bayton

A követelmények listája Az AER-be való belépéshez szükséges mennyiség nem olyan kiterjedt – az alacsony hardverkövetelmények miatt sokkal több Android-eszköz is felkerülhetett volna a listára. Még az AER szoftverkövetelményei sem igényelnek sok változtatást a szállítóktól, amint azt számos belső Google-dokumentum is felvázolja. Az egyik dokumentum felvázolja, hogy a szállítóknak hogyan kell ikonjelvényeket tervezniük a munkaprofilban lévő alkalmazásokhoz, és hozzá kell adniuk egy külön lapot a munkaprofil-alkalmazásokhoz a indító, külön megosztási célok a személyes és a munkahelyi profilban lévő alkalmazásokhoz, bizonyos Google-alkalmazások előzetes betöltése és profilok közötti adatok kezelése kommunikáció. Egy másik dokumentum felvázolja a munkaprofil-indító lap UX-követelményeit, a munkaprofil gyorsbeállítását csempe, munkaprofil párbeszédpanelek, indító oktatási üzenetek, kontextusváltás és egyéb rendszertervezés elemeket. Ezeknek a követelményeknek az a célja, hogy előmozdítsák az elfogadható hardver és szoftver UX konzisztenciáját az Android Enterprise Recommended eszközök között.

Úgy tűnik azonban, hogy az eszközöknek minden hónap után gyorsan meg kell kapniuk a biztonsági javításokat Android biztonsági közlemény (ASB) túl nagy akadálynak bizonyult sok eladó számára.

A Google Pushes for Update Transparency for Android Enterprise – ajánlott

Android fejlesztő @deletescape, aki nemrégiben megosztotta a kiszivárgott piszkozatot A Google kompatibilitási definíciós dokumentuma Android 11-hez, megszerezte az Android 11 rendszert futtató eszközökre vonatkozó új Android Enterprise Recommended követelmények kiszivárgott vázlatát. Alatt "Eszközbiztonság" szakaszban, amelyet alább bemutatunk, a Google az AER program számos követelményének eltávolítását javasolja. Ezen új javasolt szabályok értelmében az AER-eszközök többé nem kapnak garanciát a biztonsági javítások frissítésére az ASB-t követő 90 napon belül. Érdekes módon a diagram egyik sora azt sugallja, hogy a Google az Android 10-re való átállással 90 napról 30 napra szigorította ezt a követelményt, de a Google még mindig nem frissítette a nyilvános követelmények listája hogy tükrözze ezt a változást. Ennek ellenére a javasolt változtatások értelmében ez a követelmény többé nem vonatkozik az Android Enterprise Recommended Android 11-et futtató eszközökre. Ezen túlmenően a szállítóknak nem kell többé 3 éven át rendszeres biztonsági frissítéseket szolgáltatniuk az AER-eszközökhöz. Mindazonáltal továbbra is szükségük lesz az „ESMR vészhelyzeti biztonsági karbantartási kiadás” (Emergency Security Maintenance Release) frissítésére, ami feltehetően azt jelenti, hogy csak a kritikus biztonságot szolgáló javításokat tartalmazó frissítéseket kell kiadniuk sebezhetőségek.

Android 10 versus Android 11 – Eszközbiztonsági követelmények az Android Enterprise számára ajánlott

Kategória	Sorozatszám	KELL / MÁJUS	Attribútum és megvalósítás	Hozzászólások
Q (Android 10)	R (Android 11)
Eszközbiztonság	1	LEHET	OEM Vulnerability Rewards Program (VRP) működtetése	OEM Vulnerability Rewards Program (VRP) működtetése
2	LEHET	StrongBox támogatás	StrongBox támogatás
3	LEHET	Hardverrel támogatott Keystore támogatás	Hardverrel támogatott Keystore támogatás
4	LEHET	Eszközazonosító tanúsítás támogatása	Eszközazonosító tanúsítás támogatása
5	LEHET	Kulcs tanúsítvány támogatás	Kulcs tanúsítvány támogatás
6	30 napos biztonsági frissítések	Követelmény eltávolítva	Felváltotta a biztonsági átláthatósági követelmény
7	KELL	3 éves támogatás az Emergency Security Maintenance Release (ESMR) számára	3 éves támogatás az Emergency Security Maintenance Release (ESMR) számára	Felváltotta a biztonsági átláthatósági követelmény
8	Fájlalapú titkosítás – alapértelmezés szerint be van kapcsolva. AOSP implementációt használ.	Követelmény eltávolítva	Ez minden eszközre érvényes GMS-követelmény
9	90 napos biztonsági frissítések	Követelmény eltávolítva	Felváltotta a biztonsági átláthatósági követelmény
10	3 éves biztonsági frissítés-támogatás (a 3. év alatti ESMR)	Követelmény eltávolítva	Felváltotta a biztonsági átláthatósági követelmény
11	Tegye közzé a legújabb biztonsági javítási szintet	Követelmény eltávolítva	Felváltotta a biztonsági átláthatósági követelmény

Olvass tovább

Amint az a diagramon szerepel, a Google azt javasolja, hogy e követelmények nagy részét új „átláthatósági” követelményekkel cseréljék fel. Valójában a Google egy új szakasz hozzáadását javasolja "Biztonság/OS frissítések átláthatóságaAz új követelmények részletezik, hogy a szállítóknak miként kell közzétenniük az olyan információkat, mint például a biztonsági karbantartási kiadások élettartamának végi dátuma, a legújabb biztonsági javítás amely elérhető, milyen gyakran kap frissítéseket az eszköz, milyen javításokat tartalmaznak az egyes frissítések, az eszköz szállítási és tervezett szoftverfrissítései stb. Érdekes módon a Google azt is megköveteli, hogy az Android 11-es eszközöket tanúsítási tesztelésnek vetessék alá ioXt Szövetség mielőtt Android Enterprise Recommended szolgáltatássá válhatnak. Az ioXt Alliance olyan vállalatok szövetsége, amelyek célja az IoT-termékek biztonságának javítása. Tagjai közé tartozik az Amazon, a Facebook, a Google, az NXP és még sok más. A Google azt állítja, hogy ez a tanúsítvány növeli az átláthatóságot, valószínűleg mivel ad egy független mérőszám arra vonatkozóan, hogy egy adott eszköz mennyire biztonságos, nem csak a Googleé biztosíték.

Biztonsági/OS frissítések átláthatósági (új) követelményei az Android Enterprise számára ajánlott

Kategória	Sorozatszám	KELL / MÁJUS	Attribútum és megvalósítás	Hozzászólások
Q (Android 10)	R (Android 11)
Biztonság/OS frissítések átláthatósága	1	KELL	KÖTELEZŐ közzétenni a következő frissítési információkat az OEM webhelyén - SMR támogatás befejezési dátuma (utolsó dátum, amikor az eszköz megkapja az SMR-t) - Legújabb biztonsági javítás elérhető – Az eszköz által fogadott frissítések gyakorisága – A biztonsági javításban található javítások, beleértve az OEM-specifikusakat is javít	A követelmény módosítása SMR támogatásról SMR/javítások/frissítések átláthatóságra
2	KELL	KÖTELEZŐ közzétenni az alábbi operációs rendszerre vonatkozó információkat az OEM webhelyén - Az eszközzel szállított operációs rendszer - Az aktuális fő operációs rendszer verziója - Az összes főbb operációs rendszer verziófrissítés, amelyet az eszköz megkap	A követelmény módosítása támogatásról átláthatóságra pl.: Pixel 3 – Kiszállítási verzió – Android 9 – Jelenlegi Verzió – Android 10 – Várható főverzió – Android 11
3	KELL	Nyújtsa be az eszközt az IoXT tanúsítványhoz	Az IoXT pontozás növeli az átláthatóságot

Olvass tovább

Nem titok, hogy a gyártók nehezen tudnak lépést tartani a havi biztonsági javítások frissítésével. Ennek sok-sok oka van: késések a szolgáltatói tanúsításnál, a lapkakészlet javításaira való várakozás és egyéb a gyártók, a javítások alkalmazásának nehézségei az erősen módosított Android keretrendszer-felépítésekre és a fán kívüli Linux kernelekre, és több. Néhány Android-felhasználó még azt is észrevette, hogy egyes gyártók hogyan nem felel meg az AER követelményeknek. Míg a Google fejlesztési erőfeszítései és licencszerződései segített javítani Milyen gyorsan jelennek meg a biztonsági frissítések sok eszközön, nyilvánvalóan nem tudták fenntartani az Android Enterprise Recommended program jelenlegi biztonsági javítási követelményeit. E követelmények lazítása a nagyobb átláthatóság javára egyaránt elősegíti a program hozzáférhetőbbé tételét a gyártóknak, és nagyobb bizalmat ad a vállalkozásoknak az általuk választott eszközben dolgozók.

Természetesen nem a biztonsági javítások frissítéseinek javasolt enyhítése az egyetlen változás, amely az Android Enterprise Recommended programban érkezhet Android 11-hez. A Google azt is tervezi, hogy a minimális hardverkövetelményeket 2 GB RAM-ról 3 GB RAM-ra emeli, szigorítja a képzési követelményeket, és új követelményrendszert vezet be az UX munkaprofilra vonatkozóan. A legtöbb változás azonban nem érinti a tudásmunkásokat. Az Android a vállalaton belül sokat fejlődött a kezdetek óta. Ha többet szeretne megtudni a történetéről, ajánlom figyelmébe ez a kiváló cikk Jason Baytontól.