Exclusief: Google is van plan beveiligingsupdates voor Android Enterprise Aanbevolen te versoepelen

Terwijl Android het over het algemeen dominante smartphonebesturingssysteem is volgens gegevens van IDCis iOS van Apple het favoriete besturingssysteem voor de meeste bedrijven. Het is gemakkelijk te begrijpen waarom: Apple werkt zijn iOS-apparaten over het algemeen veel langer en consistenter bij dan de meeste fabrikanten van Android-apparaten hun smartphones updaten, iPhones zijn eenvoudig te configureren en te beheren, en er zijn veel minder SKU’s die moeten worden ondersteund als een bedrijf kiest Appel. Maar er zijn ook redenen voor bedrijven om voor een Android-apparaat te kiezen, waaronder lagere kosten en meer flexibiliteit op het gebied van hardware. Om Android nog aantrekkelijker te maken voor de werkplek, lanceerde Google begin 2015 'Android for Work' (later omgedoopt tot 'Android Enterprise' eind 2016). Vervolgens lanceerde Google begin 2018 de

Android Enterprise Aanbevolen (AER)-programma om apparaten te certificeren voor zakelijk gebruik. Google heeft een reeks vereisten vastgelegd waaraan apparaten moeten voldoen om 'Android Enterprise Aanbevolen' te zijn, inclusief minimale hardwarespecificaties, ondersteuning voor bulkimplementatie, beschikbaarheid van ontgrendelde apparaten, consistentie van app-gedrag in beheerde profielen en levering van Android-beveiligingsupdates binnen 90 dagen na release gedurende minimaal drie jaren.

Documenten ontdekt door Android-ontwikkelaar @verwijderscape die zijn beoordeeld door XDA-ontwikkelaars onthullen dat Google van plan is de vereisten voor beveiligingsupdates voor Android Enterprise Rated-apparaten te versoepelen. In plaats daarvan dringt Google erop aan dat leveranciers transparanter zijn over hoe zij omgaan met beveiligingsupdates. Volgens @deletescape zijn deze documenten de afgelopen 15 dagen met leveranciers gedeeld. Hoewel we dus niet kunnen garanderen dat deze voorgestelde wijzigingen in Android Enterprise Aanbevolen hun zin zullen krijgen in de definitieve lijst met vereisten kunnen we in ieder geval bevestigen dat Google deze zeer recentelijk heeft overwogen veranderingen.

Er zijn momenteel 170 verschillende Android-apparaten die Android Enterprise Aanbevolen zijn. HMD Global, Sony, Motorola, OPPO, en natuurlijk, Googlen, bied apparaten aan die AER zijn. Zelfs OnePlus overweegt zijn apparaten te laten certificeren onder het programma. Bekende consumentensmartphonemerken zijn echter niet de enige bedrijven die Android Enterprise Rated-apparaten verkopen. Robuuste smartphones van bedrijven als Zebra, Honeywell, Sonim en anderen zijn opgenomen in het programma, en nu zelfs dragers kunnen AER-apparaten rechtstreeks aan bedrijven verkopen, op voorwaarde dat zij snel beveiligingsonderhoudsreleases goedkeuren.

De inrichtingsstroom voor apparaten in Android 10. Bron: Jason Bayton

De lijst met vereisten die nodig zijn voor toegang tot AER is niet zo uitgebreid: veel meer Android-apparaten hadden op de lijst kunnen staan, gezien de lage basishardwarevereisten. Zelfs de softwarevereisten van AER vereisen niet veel veranderingen van leveranciers, zoals uiteengezet in verschillende interne Google-documenten. In een van de documenten wordt uiteengezet hoe leveranciers pictogrambadges moeten ontwerpen voor apps in het werkprofiel, een speciaal tabblad moeten toevoegen voor werkprofiel-apps in de launcher, afzonderlijke deeldoelen voor apps in het persoonlijke en werkprofiel, bepaalde Google-applicaties vooraf laden en cross-profile gegevens beheren communicatie. Een ander document schetst de UX-vereisten voor het tabblad werkprofielstarter, werkprofiel Snelle instelling tegel, werkprofieldialogen, educatieve berichten over het opstartprogramma, contextwisseling en ander systeemontwerp elementen. Deze vereisten zijn gericht op het bevorderen van een minimumstandaard voor aanvaardbare hardware en software-UX-consistentie tussen Android Enterprise Rated-apparaten.

Het lijkt er echter op dat apparaten na elke maand snel beveiligingspatch-updates moeten krijgen Android-beveiligingsbulletin (ASB) is voor veel leveranciers een te hoge drempel gebleken.

Google dringt aan op transparantie van updates voor Android Enterprise Aanbevolen

Android-ontwikkelaar @verwijderscape, die onlangs een gelekte versie van deelde Google's compatibiliteitsdefinitiedocument voor Android 11, heeft een uitgelekt concept verkregen van de nieuwe Android Enterprise Rated-vereisten voor apparaten met Android 11. Onder de "Apparaatbeveiliging", die we hieronder hebben weergegeven, stelt Google voor een aantal vereisten voor het AER-programma te verwijderen. Volgens deze nieuwe voorgestelde regels is het niet langer gegarandeerd dat AER-apparaten beveiligingspatchupdates ontvangen binnen 90 dagen na een ASB. Interessant genoeg suggereert een van de rijen in de grafiek dat Google deze eis daadwerkelijk heeft aangescherpt van 90 dagen naar 30 dagen met de overstap naar Android 10, maar Google heeft de openbare lijst met vereisten om deze verandering weer te geven. Desalniettemin zal deze vereiste onder de voorgestelde wijzigingen niet langer van toepassing zijn op Android Enterprise Rated-apparaten met Android 11. Bovendien zijn leveranciers ook niet langer verplicht om drie jaar lang regelmatig beveiligingsupdates voor AER-apparaten te leveren. Ze zullen echter nog steeds verplicht zijn om "Emergency Security Maintenance Release" (ESMR)-updates te leveren, wat vermoedelijk betekent dat ze alleen updates hoeven uit te rollen met oplossingen voor kritieke beveiliging kwetsbaarheden.

Android 10 versus Android 11 - Apparaatbeveiligingsvereisten voor Android Enterprise aanbevolen

Categorie	Serienummer	MOET / MAG	Kenmerk en implementatie	Opmerkingen
V (Android 10)	R (Android 11)
Apparaatbeveiliging	1	KUNNEN	Voer een OEM Vulnerability Rewards Program (VRP) uit	Voer een OEM Vulnerability Rewards Program (VRP) uit
2	KUNNEN	StrongBox-ondersteuning	StrongBox-ondersteuning
3	KUNNEN	Door hardware ondersteunde Keystore-ondersteuning	Door hardware ondersteunde Keystore-ondersteuning
4	KUNNEN	Ondersteuning voor attest van apparaat-ID	Ondersteuning voor attest van apparaat-ID
5	KUNNEN	Ondersteuning voor belangrijke attesten	Ondersteuning voor belangrijke attesten
6	Beveiligingsupdates van 30 dagen	Vereiste verwijderd	Vervangen door vereiste voor beveiligingstransparantie
7	MOETEN	3 jaar ondersteuning voor Emergency Security Maintenance Release (ESMR)	3 jaar ondersteuning voor Emergency Security Maintenance Release (ESMR)	Vervangen door vereiste voor beveiligingstransparantie
8	Op bestanden gebaseerde codering - standaard ingeschakeld. Maakt gebruik van AOSP-implementatie.	Vereiste verwijderd	Dit is een GMS-vereiste die voor alle apparaten geldt
9	Beveiligingsupdates van 90 dagen	Vereiste verwijderd	Vervangen door vereiste voor beveiligingstransparantie
10	3 jaar ondersteuning voor beveiligingsupdates (mogelijk na het 3e jaar ESMR)	Vereiste verwijderd	Vervangen door vereiste voor beveiligingstransparantie
11	Publiceer het nieuwste beveiligingspatchniveau	Vereiste verwijderd	Vervangen door vereiste voor beveiligingstransparantie

Lees verder

Zoals vermeld in het diagram, stelt Google voor om veel van deze vereisten te vervangen door nieuwe 'transparantie'-vereisten. Google stelt inderdaad de toevoeging voor van een nieuwe sectie met de titel "Transparantie van beveiligings-/OS-updates." De nieuwe vereisten beschrijven hoe leveranciers informatie moeten publiceren, zoals de einddatum van beveiligingsonderhoudsreleases, de nieuwste beveiligingspatch die beschikbaar is, hoe vaak het apparaat updates ontvangt, welke oplossingen in elke update zitten, de verzending en geplande software-updates van het apparaat, en meer. Interessant is dat Google ook vereist dat Android 11-apparaten certificeringstests ondergaan door de ioXt Alliantie voordat ze Android Enterprise Aanbevolen kunnen worden. De ioXt Alliance is een alliantie van bedrijven met als doel de veiligheid van IoT-producten te verbeteren. Tot de leden behoren Amazon, Facebook, Google, NXP en meer. Google zegt dat het hebben van deze certificering zal bijdragen aan de transparantie, vermoedelijk omdat het dit zal opleveren bedrijven een onafhankelijke maatstaf krijgen van hoe veilig een bepaald apparaat is, in plaats van alleen dat van Google zekerheid.

Beveiligings-/OS-updates Transparantie (nieuw) Vereisten voor Android Enterprise Aanbevolen

Categorie	Serienummer	MOET / MAG	Kenmerk en implementatie	Opmerkingen
V (Android 10)	R (Android 11)
Transparantie van beveiligings-/OS-updates	1	MOETEN	MOET de volgende update-informatie publiceren op de OEM-website - Einddatum SMR-ondersteuning (laatste datum waarop het apparaat SMR zal ontvangen) - Laatste beveiligingspatch beschikbaar - Frequentie van updates die het apparaat zal ontvangen - Oplossingen in de beveiligingspatch, inclusief eventuele OEM-specifieke oplossingen	De vereiste wijzigen van SMR-ondersteuning naar SMR/patches/updates-transparantie
2	MOETEN	MOET de volgende OS-informatie publiceren op de OEM-website - Besturingssysteem waarmee het apparaat wordt geleverd - Huidige grote besturingssysteemversie - Alle belangrijke OS-versie-updates die het apparaat zal ontvangen	De vereiste wijzigen van ondersteuning naar transparantie, bijvoorbeeld: Pixel 3- Verzonden versie - Android 9 - Huidige versie - Android 10 - Verwachte grote versie - Android 11
3	MOETEN	Dien het apparaat in voor IoXT-certificering	IoXT-scores dragen bij aan de transparantie

Lees verder

Het is geen geheim dat leveranciers moeite hebben met het uitrollen van maandelijkse beveiligingspatchupdates. Er zijn heel veel redenen waarom dat het geval is: vertragingen bij de certificering van providers, wachten op patches van de chipset en andere leveranciers, de moeilijkheid om patches toe te passen op sterk gewijzigde Android-framework-builds en out-of-tree Linux-kernels, en meer. Sommige Android-gebruikers hebben zelfs opgemerkt hoe sommige leveranciers dat doen niet voldoen aan de AER-eisen. Terwijl de ontwikkelingsinspanningen en licentieovereenkomsten van Google dat wel hebben gedaan hielp verbeteren Hoe snel beveiligingsupdates voor veel apparaten worden uitgerold, ze zijn duidelijk niet in staat geweest om aan de huidige vereisten voor beveiligingspatches voor het Android Enterprise Rated-programma te voldoen. Het versoepelen van deze vereisten ten gunste van meer transparantie zal er beide toe bijdragen dat het programma toegankelijker wordt aan leveranciers en geven bedrijven ook meer vertrouwen in het specifieke apparaat dat zij voor hun kiezen werknemers.

De voorgestelde versoepeling van beveiligingspatchupdates is uiteraard niet de enige verandering die zou kunnen komen in het Android Enterprise Rated-programma voor Android 11. Google is ook van plan om de minimale hardwarevereisten te verhogen van 2 GB RAM naar 3 GB RAM, de trainingsvereisten aan te scherpen en een nieuwe reeks vereisten voor het werkprofiel UX te implementeren. De meeste van deze veranderingen zullen echter geen gevolgen hebben voor kenniswerkers. Android in de onderneming is sinds de begindagen enorm gegroeid. Als je meer wilt weten over de geschiedenis ervan, raad ik je aan om het te lezen dit uitstekende artikel van Jason Bayton.