Z dokumentu, który wyciekł i który został sprawdzony przez XDA, wynika, że w programie Android Enterprise zalecane mogą obowiązywać złagodzone wymagania dotyczące aktualizacji zabezpieczeń.
Chociaż według danych z witryny Android jest ogólnie dominującym systemem operacyjnym dla smartfonów IDC, iOS firmy Apple jest systemem operacyjnym wybieranym przez większość przedsiębiorstw. Łatwo zrozumieć, dlaczego: Apple aktualizuje swoje urządzenia iOS na ogół znacznie dłużej i bardziej konsekwentnie niż większość producentów urządzeń z Androidem aktualizować swoje smartfony, iPhone'y są proste w konfiguracji i zarządzaniu, a jeśli firma wybierze, jest znacznie mniej jednostek SKU do obsługi Jabłko. Istnieją jednak również powody, dla których przedsiębiorstwa wybierają urządzenia z systemem Android, na przykład obniżony koszt i większa elastyczność sprzętu. Aby uczynić Androida jeszcze bardziej atrakcyjnym w miejscu pracy, na początku 2015 roku Google uruchomił „Android for Work” (później przemianowany na „Android Enterprise”)
pod koniec 2016 roku). Następnie na początku 2018 roku Google uruchomił usługę Program Android Enterprise Rekomendowany (AER). do certyfikacji urządzeń do użytku biznesowego. Firma Google skodyfikowała zestaw wymagań, jakie muszą spełniać urządzenia, aby mogły zostać uznane za „zalecane rozwiązanie Android Enterprise”, w tym minimalne specyfikacje sprzętu, obsługę wdrożeń zbiorczych, dostępność odblokowanych urządzeń, spójność zachowania aplikacji działających w zarządzanych profilach oraz dostarczanie aktualizacji zabezpieczeń Androida w ciągu 90 dni od wydania przez co najmniej trzy lata.Jednak dokumenty odkryte przez programistę Androida @usuń krajobraz które zostały sprawdzone przez Programiści XDA ujawniają, że Google planuje poluzować wymagania dotyczące aktualizacji zabezpieczeń dla urządzeń z systemem Android Enterprise Rekomendowane. Zamiast tego Google nalega, aby dostawcy zapewniali większą przejrzystość w zakresie sposobu obsługi aktualizacji zabezpieczeń. Według @deletescape dokumenty te zostały udostępnione dostawcom w ciągu ostatnich 15 dni. Dlatego chociaż nie możemy zagwarantować, że proponowane zmiany w systemie Android Enterprise zalecane zostaną wprowadzone na ostateczną listę wymagań, możemy przynajmniej potwierdzić, że Google niedawno je rozważył zmiany.
Aktualnie jest 170 różnych urządzeń z Androidem które są zalecane dla systemu Android Enterprise. HMD Global, Sony, Motorola, OPPO, i oczywiście, Google, oferują urządzenia, które są AER. Nawet OnePlusa rozważa certyfikowanie swoich urządzeń w ramach programu. Jednak znane marki smartfonów konsumenckich nie są jedynymi firmami sprzedającymi urządzenia z systemem Android Enterprise Rekomendowane. Wytrzymałe smartfony takich firm jak Zebra, Honeywell, Sonim i innych są teraz objęte programem nawet przewoźnicy może sprzedawać urządzenia AER bezpośrednio firmom, pod warunkiem, że szybko zatwierdzą one aktualizacje dotyczące konserwacji zabezpieczeń.
Przepływ udostępniania urządzeń w systemie Android 10. Źródło: Jasona Baytona
The lista wymagań potrzebne do wejścia do AER nie jest zbyt obszerne – na liście mogło znaleźć się znacznie więcej urządzeń z Androidem, biorąc pod uwagę niskie wymagania sprzętowe. Nawet wymagania oprogramowania AER nie wymagają wielu zmian od dostawców, jak opisano w kilku wewnętrznych dokumentach Google. Jeden z dokumentów opisuje, w jaki sposób dostawcy muszą projektować plakietki ikon dla aplikacji w profilu do pracy, dodawać dedykowaną kartę dla aplikacji w profilu do pracy w profilu launcher, oddzielne cele udostępniania aplikacji w profilu osobistym i służbowym, wstępne ładowanie niektórych aplikacji Google i zarządzanie danymi w wielu profilach Komunikacja. Kolejny dokument opisuje wymagania UX dotyczące karty uruchamiania profilu służbowego, Szybkie ustawienia profilu służbowego kafelki, okna dialogowe profili służbowych, komunikaty edukacyjne programu uruchamiającego, przełączanie kontekstu i inne projekty systemu elementy. Wymagania te mają na celu promowanie minimalnego standardu akceptowalnego sprzętu i spójności oprogramowania między urządzeniami z systemem Android Enterprise Rekomendowane.
Wydaje się jednak, że wymóg, aby urządzenia szybko otrzymywały aktualizacje poprawek bezpieczeństwa co miesiąc Biuletyn dotyczący bezpieczeństwa Androida (ASB) okazała się dla wielu dostawców zbyt wysoką barierą.
Google nalega na przejrzystość aktualizacji dla systemu Android Enterprise. Zalecane
Programista Androida @usuń krajobraz, który niedawno udostępnił wersję roboczą, która wyciekła Dokument definicji zgodności Google dla Androida 11uzyskał wyciekłą wersję roboczą nowych wymagań Android Enterprise Rekomendowanych dla urządzeń z systemem Android 11. Pod "Bezpieczeństwo urządzenia”, którą zamieściliśmy poniżej, Google proponuje usunięcie szeregu wymagań programu AER. Zgodnie z tymi nowymi proponowanymi przepisami urządzenia AER nie będą już mieć gwarancji otrzymania aktualizacji poprawek zabezpieczeń w ciągu 90 dni od ASB. Co ciekawe, jeden z wierszy na wykresie sugeruje, że Google faktycznie zaostrzył ten wymóg z 90 dni do 30 dni wraz z przejściem na Androida 10, ale Google nadal nie zaktualizował publiczna lista wymagań aby odzwierciedlić tę zmianę. Niemniej jednak w ramach proponowanych zmian wymóg ten nie będzie już miał zastosowania w przypadku urządzeń z systemem Android Enterprise Rekomendowane z systemem Android 11. Co więcej, dostawcy nie będą już zobowiązani do zapewniania regularnych aktualizacji zabezpieczeń dla urządzeń AER przez 3 lata. Będą jednak nadal zobowiązani do dostarczania aktualizacji „Emergency Security Maintenance Release” (ESMR), co prawdopodobnie oznacza, że muszą jedynie wdrażać aktualizacje zawierające poprawki dotyczące krytycznych zabezpieczeń luki w zabezpieczeniach.
Android 10 a Android 11 — zalecane wymagania dotyczące bezpieczeństwa urządzenia dla systemu Android Enterprise
Kategoria |
Numer seryjny |
MUSI / MOŻE |
Atrybut i implementacja |
Uwagi |
P (Android 10) |
R (Android 11) |
|||
Bezpieczeństwo urządzenia |
1 |
MÓC |
Prowadź program nagród za luki w zabezpieczeniach OEM (VRP) |
Prowadź program nagród za luki w zabezpieczeniach OEM (VRP) |
2 |
MÓC |
Wsparcie StrongBoxa |
Wsparcie StrongBoxa |
|
3 |
MÓC |
Sprzętowa obsługa magazynu kluczy |
Sprzętowa obsługa magazynu kluczy |
|
4 |
MÓC |
Obsługa poświadczenia identyfikatora urządzenia |
Obsługa poświadczenia identyfikatora urządzenia |
|
5 |
MÓC |
Kluczowe wsparcie w zakresie atestów |
Kluczowe wsparcie w zakresie atestów |
|
6 |
30-dniowe aktualizacje zabezpieczeń |
Wymóg usunięty |
Zastąpione wymogiem przejrzystości zabezpieczeń |
|
7 |
MUSIEĆ |
3-letnie wsparcie dla wersji Emergency Security Maintenance Release (ESMR) |
3-letnie wsparcie dla wersji Emergency Security Maintenance Release (ESMR) |
Zastąpione wymogiem przejrzystości zabezpieczeń |
8 |
Szyfrowanie oparte na plikach — domyślnie włączone. Wykorzystuje implementację AOSP. |
Wymóg usunięty |
Jest to wymóg GMS obowiązujący na wszystkich urządzeniach |
|
9 |
90-dniowe aktualizacje zabezpieczeń |
Wymóg usunięty |
Zastąpione wymogiem przejrzystości zabezpieczeń |
|
10 |
3-letnia pomoc w zakresie aktualizacji zabezpieczeń (może być niższa niż 3 rok ESMR) |
Wymóg usunięty |
Zastąpione wymogiem przejrzystości zabezpieczeń |
|
11 |
Opublikuj najnowszy poziom poprawek zabezpieczeń |
Wymóg usunięty |
Zastąpione wymogiem przejrzystości zabezpieczeń |
Czytaj więcej
Jak wspomniano na wykresie, Google proponuje zastąpienie wielu z tych wymagań nowymi wymogami dotyczącymi „przejrzystości”. Rzeczywiście Google proponuje dodanie nowej sekcji zatytułowanej „Przejrzystość aktualizacji zabezpieczeń/systemu operacyjnegoNowe wymagania szczegółowo określają, w jaki sposób dostawcy będą zobowiązani do publikowania informacji, takich jak data wygaśnięcia aktualizacji aktualizacji zabezpieczeń, ostatnia poprawka zabezpieczeń jakie są dostępne, jak często urządzenie będzie otrzymywać aktualizacje, jakie poprawki zawiera każda aktualizacja, informacje o wysyłce i planowanych aktualizacjach oprogramowania urządzenia i nie tylko. Co ciekawe, Google wymaga również, aby urządzenia z Androidem 11 przechodziły testy certyfikacyjne przeprowadzane przez Sojusz ioXt zanim uzyskają status Android Enterprise Rekomendowane. ioXt Alliance to sojusz firm, którego celem jest poprawa bezpieczeństwa produktów IoT. Do jej członków należą Amazon, Facebook, Google, NXP i nie tylko. Google twierdzi, że posiadanie tego certyfikatu zwiększy przejrzystość, prawdopodobnie dlatego, że da przedsiębiorstwom niezależny wskaźnik poziomu bezpieczeństwa konkretnego urządzenia, a nie tylko urządzenia Google zapewnienie.
Wymagania dotyczące przejrzystości aktualizacji zabezpieczeń/systemu operacyjnego (nowe) dla systemu Android Enterprise Zalecane
Kategoria |
Numer seryjny |
MUSI / MOŻE |
Atrybut i implementacja |
Uwagi |
P (Android 10) |
R (Android 11) |
|||
Przejrzystość aktualizacji zabezpieczeń/systemu operacyjnego |
1 |
MUSIEĆ |
MUSI publikować informacje o kolejnych aktualizacjach na stronie internetowej OEM – data końcowa wsparcia SMR (ostatnia data, kiedy urządzenie otrzyma SMR) – najnowsza dostępna poprawka zabezpieczeń — Częstotliwość aktualizacji, które otrzyma urządzenie — Poprawki zawarte w łatce zabezpieczeń, w tym wszelkie poprawki specyficzne dla OEM poprawki |
Zmiana wymagania z obsługi SMR na przejrzystość SMR/poprawek/aktualizacji |
2 |
MUSIEĆ |
MUSI opublikować następujące informacje o systemie operacyjnym w witrynie OEM — system operacyjny, z którym dostarczane jest urządzenie — bieżąca główna wersja systemu operacyjnego — wszystkie główne aktualizacje wersji systemu operacyjnego, które otrzyma urządzenie |
Zmiana wymagań z obsługi na przezroczystośćnp.: Pixel 3 – wersja dostarczona – Android 9 – bieżąca wersja – Android 10 – oczekiwana wersja główna – Android 11 |
|
3 |
MUSIEĆ |
Prześlij urządzenie do certyfikacji IoXT |
Punktacja IoXT zwiększa przejrzystość |
Czytaj więcej
Nie jest tajemnicą, że dostawcy mają problemy z nadążaniem za wprowadzaniem comiesięcznych aktualizacji poprawek zabezpieczeń. Powodów takiego stanu rzeczy jest wiele, wiele: opóźnienia w certyfikacji przewoźnika, oczekiwanie na łatki z chipsetu i inne dostawców, trudność w stosowaniu poprawek do mocno zmodyfikowanych kompilacji platformy Android i jąder Linuksa znajdujących się poza drzewem oraz więcej. Niektórzy użytkownicy Androida nawet zauważyli, jak niektórzy dostawcy nie spełniają wymagań AER. Chociaż wysiłki Google na rzecz rozwoju i umowy licencyjne mają pomogło poprawić jak szybko aktualizacje zabezpieczeń są wdrażane dla wielu urządzeń, najwyraźniej nie są one w stanie spełnić bieżących wymagań dotyczących poprawek zabezpieczeń w programie Android Enterprise zalecane. Łagodzenie tych wymogów na rzecz większej przejrzystości pomoże zwiększyć dostępność programu dostawcom, a także dają przedsiębiorstwom większe zaufanie do konkretnego urządzenia, które wybierają dla siebie pracownicy.
Proponowane złagodzenie aktualizacji poprawek zabezpieczeń to oczywiście nie jedyna zmiana, która może pojawić się w programie Android Enterprise Rekomendowanym dla Androida 11. Google planuje także zwiększyć minimalne wymagania sprzętowe z 2 GB RAM do 3 GB RAM, zaostrzyć wymagania szkoleniowe i wdrożyć nowy zestaw wymagań dla profilu do pracy UX. Większość tych zmian nie będzie miała jednak wpływu na pracowników umysłowych. Android w przedsiębiorstwach bardzo się rozwinął od jego początków. Jeśli chcesz dowiedzieć się więcej o jego historii, polecam lekturę ten znakomity artykuł Jasona Baytona.