Eksklusivt: Google planlegger å slappe av med sikkerhetsoppdateringer for Android Enterprise Recommended

Mens Android er det totalt dominerende operativsystemet for smarttelefoner i henhold til data fra IDC, Apples iOS er det foretrukne operativsystemet for de fleste bedrifter. Det er lett å se hvorfor: Apple oppdaterer iOS-enhetene sine generelt mye lenger og mer konsekvent enn de fleste produsenter av Android-enheter oppdater smarttelefonene sine, iPhones er enkle å konfigurere og administrere, og det er langt færre SKU-er å støtte hvis et selskap velger Eple. Men det er også grunner for bedrifter til å velge en Android-enhet, inkludert reduserte kostnader og mer fleksibilitet i maskinvare. For å gjøre Android enda mer fristende for arbeidsplassen, lanserte Google "Android for Work" tidlig i 2015 (senere omdøpt til "Android Enterprise" på slutten av 2016). Så tidlig i 2018 lanserte Google Android Enterprise Recommended (AER) program å sertifisere enheter for forretningsbruk. Google kodifiserte et sett med krav som enheter må oppfylle for å være «Android Enterprise Recommended», inkludert minimums maskinvarespesifikasjoner, støtte for massedistribusjon, tilgjengelighet av ulåste enheter, konsistent appatferd som kjører i administrerte profiler, og levering av Android-sikkerhetsoppdateringer innen 90 dager etter utgivelse for minst tre år.

Imidlertid, dokumenter avdekket av Android-utvikler @deletescape som ble anmeldt av XDA-utviklere avsløre at Google planlegger å løsne kravene til sikkerhetsoppdateringer for Android Enterprise-anbefalte enheter. I stedet presser Google på for at leverandører skal være mer transparente om hvordan de håndterer sikkerhetsoppdateringer. I følge @deletescape ble disse dokumentene delt med leverandører i løpet av de siste 15 dagene. Selv om vi ikke kan garantere at disse foreslåtte endringene i Android Enterprise Recommended vil gjøre deres vei inn i den endelige listen over krav, kan vi i det minste bekrefte at Google nylig har vurdert disse Endringer.

Det er for tiden 170 forskjellige Android-enheter som er Android Enterprise anbefalt. HMD Global, Sony, Motorola, OPPO, og selvfølgelig, Google, tilbyr enheter som er AER. Til og med OnePlus vurderer å få enhetene sine sertifisert under programmet. Kjente forbrukermerker for smarttelefoner er imidlertid ikke de eneste selskapene som selger Android Enterprise-anbefalte enheter. Robuste smarttelefoner fra selskaper som Zebra, Honeywell, Sonim og andre er inkludert i programmet, og nå selv transportører kan selge AER-enheter direkte til bedrifter, forutsatt at de raskt godkjenner utgivelser av sikkerhetsvedlikehold.

Enhetsklargjøringsflyten i Android 10. Kilde: Jason Bayton

De liste over krav nødvendig for å komme inn i AER er ikke så omfattende - mange flere Android-enheter kunne ha kommet på listen gitt de lave grunnleggende maskinvarekravene. Selv AERs programvarekrav krever ikke mange endringer fra leverandører, som skissert av flere interne Google-dokumenter. Et av dokumentene skisserer hvordan leverandører må designe ikonmerker for apper i jobbprofilen, legg til en dedikert fane for jobbprofilapper i launcher, separate delingsmål for apper i den personlige profilen og jobbprofilen, forhåndslaste visse Google-applikasjoner og administrer data på tvers av profiler kommunikasjon. Et annet dokument skisserer UX-kravene for startfanen for arbeidsprofil, hurtiginnstilling for arbeidsprofil fliser, dialogbokser for arbeidsprofiler, opplæringsmeldinger for lansering, kontekstbytte og annen systemdesign elementer. Disse kravene er rettet mot å fremme en minimumsstandard for akseptabel maskinvare samt programvare UX-konsistens mellom Android Enterprise-anbefalte enheter.

Imidlertid ser det ut til at kravet om at enheter raskt skal få sikkerhetsoppdateringer etter hver månedlig Android Security Bulletin (ASB) har vist seg å være en for høy barriere for mange leverandører.

Google Pushes for Update Transparency for Android Enterprise anbefales

Android-utvikler @deletescape, som nylig delte et lekket utkast av Googles kompatibilitetsdefinisjonsdokument for Android 11, fikk et lekket utkast til de nye Android Enterprise Recommended-kravene for enheter som kjører Android 11. Under "Enhetssikkerhet"-delen, som vi har gjengitt nedenfor, foreslår Google fjerning av en rekke krav for AER-programmet. I henhold til disse nye foreslåtte reglene vil AER-enheter ikke lenger være garantert å motta sikkerhetsoppdateringer innen 90 dager etter en ASB. Interessant nok antyder en av radene i diagrammet at Google faktisk skjerpet dette kravet fra 90 dager til 30 dager med overgangen til Android 10, men Google har fortsatt ikke oppdatert offentlig liste over krav for å gjenspeile denne endringen. Ikke desto mindre, under de foreslåtte endringene, vil dette kravet ikke lenger gjelde for Android Enterprise Recommended-enheter som kjører Android 11. Videre vil leverandører heller ikke lenger være pålagt å gi 3 år med regelmessige sikkerhetsoppdateringer for AER-enheter. De vil imidlertid fortsatt være pålagt å gi "Emergency Security Maintenance Release" (ESMR)-oppdateringer, som antagelig betyr at de bare trenger å rulle ut oppdateringer som inneholder rettelser for kritisk sikkerhet sårbarheter.

Android 10 versus Android 11 – Enhetssikkerhetskrav for Android Enterprise anbefales

Kategori	Serienummer	MÅ / MAI	Attributt og implementering	Kommentarer
Q (Android 10)	R (Android 11)
Enhetssikkerhet	1	KAN	Drive et OEM Vulnerability Rewards Program (VRP)	Drive et OEM Vulnerability Rewards Program (VRP)
2	KAN	StrongBox-støtte	StrongBox-støtte
3	KAN	Maskinvarestøttet Keystore-støtte	Maskinvarestøttet Keystore-støtte
4	KAN	Støtte for attestering av enhets-ID	Støtte for attestering av enhets-ID
5	KAN	Støtte for nøkkelattest	Støtte for nøkkelattest
6	30-dagers sikkerhetsoppdateringer	Kravet fjernet	Erstattet med krav til sikkerhetsgjennomsiktighet
7	MÅ	3 års støtte for Emergency Security Maintenance Release (ESMR)	3 års støtte for Emergency Security Maintenance Release (ESMR)	Erstattet med krav til sikkerhetsgjennomsiktighet
8	Filbasert kryptering - på som standard. Bruker AOSP-implementering.	Kravet fjernet	Dette er et GMS-krav som håndheves for alle enheter
9	90-dagers sikkerhetsoppdateringer	Kravet fjernet	Erstattet med krav til sikkerhetsgjennomsiktighet
10	3 års støtte for sikkerhetsoppdatering (kan være under 3. år ESMR)	Kravet fjernet	Erstattet med krav til sikkerhetsgjennomsiktighet
11	Publiser siste sikkerhetsoppdateringsnivå	Kravet fjernet	Erstattet med krav til sikkerhetsgjennomsiktighet

Les mer

Som nevnt i diagrammet, foreslår Google å erstatte mange av disse kravene med nye krav til "gjennomsiktighet". Faktisk foreslår Google å legge til en ny seksjon med tittelen "Sikkerhet/OS-oppdateringer åpenhet." De nye kravene beskriver hvordan leverandører vil bli pålagt å publisere informasjon som sluttdatoen for sikkerhetsvedlikeholdsutgivelser, den siste sikkerhetsoppdateringen som er tilgjengelig, hvor ofte enheten vil motta oppdateringer, hvilke rettelser som finnes i hver oppdatering, frakt og planlagte programvareoppdateringer for enheten, og mer. Interessant nok krever Google også at Android 11-enheter gjennomgår sertifiseringstesting av ioXt Alliance før de kan bli Android Enterprise Recommended. ioXt Alliance er en allianse av selskaper som har som mål å forbedre sikkerheten til IoT-produkter. Medlemmene inkluderer Amazon, Facebook, Google, NXP og mer. Google sier at å ha denne sertifiseringen vil bidra til åpenhet, antagelig siden det vil gi bedrifter en uavhengig beregning av hvor sikker en bestemt enhet er i stedet for bare Googles forsikring.

Sikkerhets-/OS-oppdateringer Krav til åpenhet (nye) for Android Enterprise anbefales

Kategori	Serienummer	MÅ / MAI	Attributt og implementering	Kommentarer
Q (Android 10)	R (Android 11)
Sikkerhet/OS-oppdateringer åpenhet	1	MÅ	MÅ publisere følgende oppdateringsinformasjon på OEM-nettstedet - Sluttdato for SMR-støtte (siste dato når enheten vil motta SMR) - Siste sikkerhetsoppdatering tilgjengelig- Frekvens av oppdateringer enheten vil motta- Rettelser i sikkerhetsoppdateringen, inkludert alle OEM-spesifikke fikser	Endring av kravet fra SMR-støtte til SMR/patcher/oppdateringer åpenhet
2	MÅ	MÅ publisere følgende OS-informasjon på OEM-nettstedet- OS som enheten leveres med- Gjeldende hoved OS-versjon- Alle større OS-versjonsoppdateringer som enheten vil motta	Endring av kravet fra støtte til åpenhet, f.eks.: Pixel 3 - Sendt versjon - Android 9 - Nåværende versjon - Android 10 - Forventet hovedversjon - Android 11
3	MÅ	Send inn enheten til IoXT-sertifisering	IoXT-scoring bidrar til åpenhet

Les mer

Det er ingen hemmelighet at leverandører har problemer med å holde tritt med å rulle ut månedlige sikkerhetsoppdateringer. Det er mange, mange grunner til at det er tilfelle: forsinkelser i operatørsertifisering, venting på patcher fra brikkesett og annet leverandører, vanskeligheten med å bruke oppdateringer til sterkt modifiserte Android-rammeverk og Linux-kjerner utenfor treet, og mer. Noen Android-brukere har til og med lagt merke til hvordan enkelte leverandører ikke oppfyller AER-kravene. Mens Googles utviklingsarbeid og lisensavtaler har bidratt til å forbedre hvor raskt sikkerhetsoppdateringer rulles ut for mange enheter, har de tydeligvis ikke vært i stand til å opprettholde gjeldende sikkerhetsoppdateringskrav for Android Enterprise Recommended-programmet. Å løsne på disse kravene til fordel for mer åpenhet vil både bidra til å gjøre programmet mer tilgjengelig til leverandører og gir også bedrifter mer tillit til den bestemte enheten de velger for sin arbeidere.

Den foreslåtte lempelsen av sikkerhetsoppdateringer er ikke den eneste endringen som kan komme til Android Enterprise Recommended-programmet for Android 11, selvfølgelig. Google planlegger også å øke minimumskravene til maskinvare fra 2 GB RAM til 3 GB RAM, skjerpe opplæringskravene og implementere et nytt sett med krav til arbeidsprofilen UX. De fleste av disse endringene vil imidlertid ikke påvirke kunnskapsarbeidere. Android i bedriften har vokst mye siden de første dagene. Hvis du er interessert i å lære mer om historien, anbefaler jeg å lese denne utmerkede artikkelen fra Jason Bayton.