Android Enterprise Recommended-programmet kan se avslappnade säkerhetsuppdateringskrav, enligt ett läckt dokument som granskats av XDA.
Medan Android är det övergripande dominerande operativsystemet för smartphones enligt data från IDC, Apples iOS är det valda operativsystemet för de flesta företag. Det är lätt att se varför: Apple uppdaterar sina iOS-enheter i allmänhet mycket längre och mer konsekvent än de flesta Android-enhetstillverkare uppdatera sina smartphones, iPhones är enkla att konfigurera och hantera, och det finns mycket färre SKU: er att stödja om ett företag väljer Äpple. Men det finns också skäl för företag att välja en Android-enhet, inklusive minskade kostnader och mer flexibilitet i hårdvaran. För att göra Android ännu mer lockande för arbetsplatsen lanserade Google "Android for Work" i början av 2015 (senare omdöpt till "Android Enterprise" i slutet av 2016). Sedan i början av 2018 lanserade Google Android Enterprise Recommended (AER) program att certifiera enheter för affärsbruk. Google kodifierade en uppsättning krav som enheter måste uppfylla för att vara "Android Enterprise Recommended", inklusive lägsta hårdvaruspecifikationer, stöd för massdistribution, tillgänglighet av olåsta enheter, konsekvent appbeteende som körs i hanterade profiler och leverans av Android-säkerhetsuppdateringar inom 90 dagar efter lanseringen för minst tre år.
Dokument som upptäckts av Android-utvecklaren @deletescape som granskades av XDA-utvecklare avslöjar att Google planerar att minska kraven på säkerhetsuppdateringar för enheter som rekommenderas av Android Enterprise. Istället trycker Google på för att leverantörer ska vara mer transparenta om hur de hanterar säkerhetsuppdateringar. Enligt @deletescape har dessa dokument delats med leverantörer inom de senaste 15 dagarna. Så även om vi inte kan garantera att dessa föreslagna ändringar av Android Enterprise Recommended kommer att göra sin väg i den slutliga listan med krav kan vi åtminstone bekräfta att Google nyligen har övervägt dessa ändringar.
Det finns för närvarande 170 olika Android-enheter som är Android Enterprise Recommended. HMD Global, Sony, Motorola, OPPO, och naturligtvis, Google, erbjuda enheter som är AER. Till och med OnePlus överväger att låta sina enheter certifieras enligt programmet. Välkända konsumentsmartphonemärken är dock inte de enda företagen som säljer Android Enterprise Recommended-enheter. Robusta smartphones från företag som Zebra, Honeywell, Sonim och andra ingår i programmet, och nu även transportörer kan sälja AER-enheter direkt till företag, förutsatt att de snabbt godkänner säkerhetsunderhållsreleaser.
Enhetsadministrationsflödet i Android 10. Källa: Jason Bayton
De kravlista som behövs för att komma in i AER är inte så omfattande – många fler Android-enheter kunde ha gjort listan med tanke på de låga hårdvarukraven. Även AER: s programvarukrav kräver inte många förändringar från leverantörer, vilket beskrivs i flera interna Google-dokument. Ett av dokumenten beskriver hur leverantörer måste designa ikonmärken för appar i jobbprofilen, lägg till en särskild flik för jobbprofilappar i startprogram, separata delmål för appar i den personliga profilen och jobbprofilen, förladda vissa Google-appar och hantera data över flera profiler kommunikation. Ett annat dokument beskriver UX-kraven för startfliken för arbetsprofil, snabbinställning för arbetsprofil brickor, dialogrutor för arbetsprofiler, utbildningsmeddelanden i startprogrammet, kontextbyte och annan systemdesign element. Dessa krav syftar till att främja en lägsta standard av acceptabel hårdvara såväl som mjukvaru-UX-konsistens mellan Android Enterprise Recommended-enheter.
Det verkar dock som kravet på enheter att snabbt få säkerhetsuppdateringar efter varje månad Android Security Bulletin (ASB) har visat sig vara en för hög barriär för många leverantörer.
Google Pushes for Update Transparency för Android Enterprise Rekommenderas
Android-utvecklare @deletescape, som nyligen delade ett läckt utkast till Googles kompatibilitetsdefinitionsdokument för Android 11, fick ett läckt utkast till de nya Android Enterprise Recommended-kraven för enheter som kör Android 11. Under "Enhetssäkerhet", som vi har återgett nedan, föreslår Google att ett antal krav för AER-programmet tas bort. Enligt dessa nya föreslagna regler kommer AER-enheter inte längre att garanteras att ta emot säkerhetsuppdateringar inom 90 dagar efter en ASB. Intressant nog antyder en av raderna i diagrammet att Google faktiskt skärpte detta krav från 90 dagar till 30 dagar med övergången till Android 10, men Google har fortfarande inte uppdaterat offentliga kravlistan för att återspegla denna förändring. Icke desto mindre, under de föreslagna ändringarna, kommer detta krav inte längre att gälla för Android Enterprise Recommended-enheter som kör Android 11. Dessutom kommer leverantörer inte längre att behöva tillhandahålla 3 års regelbundna säkerhetsuppdateringar för AER-enheter. De kommer dock fortfarande att behöva tillhandahålla "Emergency Security Maintenance Release" (ESMR) uppdateringar, vilket förmodligen innebär att de bara behöver rulla ut uppdateringar som innehåller korrigeringar för kritisk säkerhet sårbarheter.
Android 10 kontra Android 11 - Enhetssäkerhetskrav för Android Enterprise Rekommenderas
Kategori |
Serienummer |
MÅSTE/MAJ |
Attribut och implementering |
Kommentarer |
Q (Android 10) |
R (Android 11) |
|||
Enhetssäkerhet |
1 |
MAJ |
Driv ett OEM Vulnerability Rewards Program (VRP) |
Driv ett OEM Vulnerability Rewards Program (VRP) |
2 |
MAJ |
StrongBox-stöd |
StrongBox-stöd |
|
3 |
MAJ |
Hårdvarustödd Keystore-stöd |
Hårdvarustödd Keystore-stöd |
|
4 |
MAJ |
Stöd för attestering av enhets-ID |
Stöd för attestering av enhets-ID |
|
5 |
MAJ |
Stöd för nyckelbevis |
Stöd för nyckelbevis |
|
6 |
30-dagars säkerhetsuppdateringar |
Kravet borttaget |
Ersatt med krav på säkerhetstransparens |
|
7 |
MÅSTE |
3 års support för Emergency Security Maintenance Release (ESMR) |
3 års support för Emergency Security Maintenance Release (ESMR) |
Ersatt med krav på säkerhetstransparens |
8 |
Filbaserad kryptering - på som standard. Använder AOSP-implementering. |
Kravet borttaget |
Detta är ett GMS-krav som tillämpas för alla enheter |
|
9 |
90-dagars säkerhetsuppdateringar |
Kravet borttaget |
Ersatt med krav på säkerhetstransparens |
|
10 |
3 års support för säkerhetsuppdatering (kan under 3:e året ESMR) |
Kravet borttaget |
Ersatt med krav på säkerhetstransparens |
|
11 |
Publicera senaste säkerhetskorrigeringsnivån |
Kravet borttaget |
Ersatt med krav på säkerhetstransparens |
Läs mer
Som nämnts i diagrammet föreslår Google att många av dessa krav ersätts med nya krav på "transparens". Faktum är att Google föreslår tillägget av ett nytt avsnitt med titeln "Säkerhet/OS-uppdateringar transparens." De nya kraven beskriver hur leverantörer kommer att behöva publicera information som slutdatumet för säkerhetsunderhållsversioner, den senaste säkerhetskorrigeringen det är tillgängligt, hur ofta enheten kommer att ta emot uppdateringar, vilka korrigeringar som finns i varje uppdatering, leveransen och planerade programuppdateringar för enheten med mera. Intressant nog kräver Google också att Android 11-enheter genomgår certifieringstestning av ioXt Alliance innan de kan bli Android Enterprise Recommended. ioXt Alliance är en allians av företag vars mål är att förbättra säkerheten för IoT-produkter. Dess medlemmar inkluderar Amazon, Facebook, Google, NXP och mer. Google säger att att ha denna certifiering kommer att öka transparensen, förmodligen eftersom det kommer att ge företag ett oberoende mått på hur säker en viss enhet är snarare än bara Googles försäkran.
Säkerhets-/OS-uppdateringar Transparens (nya) krav för Android Enterprise Rekommenderas
Kategori |
Serienummer |
MÅSTE/MAJ |
Attribut och implementering |
Kommentarer |
Q (Android 10) |
R (Android 11) |
|||
Säkerhet/OS-uppdateringar transparens |
1 |
MÅSTE |
MÅSTE publicera följande uppdateringsinformation på OEM-webbplatsen - Slutdatum för SMR-support (sista datum när enheten kommer att ta emot SMR) - Senaste säkerhetskorrigering tillgänglig - Frekvens för uppdateringar som enheten kommer att ta emot - korrigeringar i säkerhetskorrigeringen, inklusive alla OEM-specifika fixar |
Ändra kravet från SMR-stöd till SMR/patchar/uppdateringar transparens |
2 |
MÅSTE |
MÅSTE publicera följande OS-information på OEM-webbplatsen- OS som enheten levereras med- Aktuella större OS-versioner- Alla större OS-versionsuppdateringar som enheten kommer att få |
Ändra kravet från support till transparens, t.ex.: Pixel 3 - Levererad version - Android 9 - Aktuell version - Android 10 - Förväntad huvudversion - Android 11 |
|
3 |
MÅSTE |
Skicka in enheten till IoXT-certifiering |
IoXT-poäng ökar transparensen |
Läs mer
Det är ingen hemlighet att leverantörer har problem med att rulla ut månatliga säkerhetsuppdateringar. Det finns många, många anledningar till att det är fallet: förseningar i operatörscertifiering, väntan på patchar från chipset och annat leverantörer, svårigheten att applicera patchar på kraftigt modifierade Android-ramverk och Linux-kärnor utanför trädet, och Mer. Vissa Android-användare har till och med lagt märke till hur vissa leverantörer inte uppfyller AER-kraven. Medan Googles utvecklingsinsatser och licensavtal har hjälpte till att förbättra hur snabbt säkerhetsuppdateringar rullar ut för många enheter, har de uppenbarligen inte kunnat upprätthålla de nuvarande kraven för säkerhetskorrigering för Android Enterprise Recommended-programmet. Att lätta på dessa krav till förmån för mer transparens kommer både att bidra till att göra programmet mer tillgängligt till leverantörer och ger även företag mer förtroende för den specifika enhet de väljer för sin arbetare.
Den föreslagna uppmjukningen av säkerhetsuppdateringar är inte den enda förändringen som kan komma till Android Enterprise Recommended-programmet för Android 11, naturligtvis. Google planerar också att öka minimikraven för hårdvara från 2 GB RAM till 3 GB RAM, skärpa utbildningskraven och implementera en ny uppsättning krav för arbetsprofilens UX. De flesta av dessa förändringar kommer dock inte att påverka kunskapsarbetare. Android i företaget har vuxit mycket sedan dess tidiga dagar. Om du är intresserad av att lära dig mer om dess historia rekommenderar jag att du läser denna utmärkta artikel från Jason Bayton.