Laut einem durchgesickerten Dokument, das von XDA überprüft wurde, gelten für das von Android Enterprise empfohlene Programm möglicherweise gelockerte Sicherheitsupdate-Anforderungen.
Während Android laut Daten von das insgesamt dominierende Smartphone-Betriebssystem ist IDC, Apples iOS ist für die meisten Unternehmen das Betriebssystem der Wahl. Es ist leicht zu erkennen, warum: Apple aktualisiert seine iOS-Geräte im Allgemeinen viel länger und konsistenter als die meisten Android-Gerätehersteller Aktualisieren Sie ihre Smartphones, iPhones sind einfach zu konfigurieren und zu verwalten und es gibt weitaus weniger zu unterstützende SKUs, wenn ein Unternehmen sich dafür entscheidet Apfel. Es gibt aber auch Gründe für Unternehmen, sich für ein Android-Gerät zu entscheiden, darunter geringere Kosten und mehr Flexibilität bei der Hardware. Um Android für den Arbeitsplatz noch attraktiver zu machen, führte Google Anfang 2015 „Android for Work“ ein (später umbenannt in „Android Enterprise“).
Allerdings wurden vom Android-Entwickler @ aufgedeckte Dokumentedeletescape die überprüft wurden von XDA-Entwickler offenbaren, dass Google plant, die Anforderungen an Sicherheitsupdates für Android Enterprise-empfohlene Geräte zu lockern. Stattdessen drängt Google darauf, dass die Anbieter transparenter darüber werden, wie sie mit Sicherheitsupdates umgehen. Laut @deletescape wurden diese Dokumente innerhalb der letzten 15 Tage an Anbieter weitergegeben. Daher können wir nicht garantieren, dass diese vorgeschlagenen Änderungen an Android Enterprise Recommended umgesetzt werden In die endgültige Liste der Anforderungen können wir zumindest bestätigen, dass Google diese erst kürzlich berücksichtigt hat Änderungen.
Derzeit gibt es 170 verschiedene Android-Geräte die von Android Enterprise empfohlen werden. HMD Global, Sony, Motorola, OPPO, und natürlich, Google, bieten Geräte an, die AER sind. Sogar OnePlus erwägt, seine Geräte im Rahmen des Programms zertifizieren zu lassen. Allerdings sind bekannte Verbraucher-Smartphone-Marken nicht die einzigen Unternehmen, die Geräte mit Android Enterprise-Empfehlung verkaufen. Robuste Smartphones von Unternehmen wie Zebra, Honeywell, Sonim und anderen sind jetzt im Programm enthalten sogar Träger können AER-Geräte direkt an Unternehmen verkaufen, vorausgesetzt, sie genehmigen schnell Sicherheitswartungsversionen.
Der Gerätebereitstellungsablauf in Android 10. Quelle: Jason Bayton
Der Liste der Anforderungen Die für den Einstieg in die AER benötigten Geräte sind nicht so umfangreich – aufgrund der geringen Basis-Hardwareanforderungen hätten viel mehr Android-Geräte in die Liste aufgenommen werden können. Selbst die Softwareanforderungen von AER erfordern keine großen Änderungen seitens der Anbieter, wie aus mehreren internen Google-Dokumenten hervorgeht. In einem der Dokumente wird dargelegt, wie Anbieter Symbolabzeichen für Apps im Arbeitsprofil entwerfen und eine eigene Registerkarte für Arbeitsprofil-Apps hinzufügen müssen Launcher, trennen Sie Freigabeziele für Apps im persönlichen und geschäftlichen Profil, laden Sie bestimmte Google-Anwendungen vor und verwalten Sie profilübergreifende Daten Kommunikation. In einem weiteren Dokument werden die UX-Anforderungen für die Arbeitsprofil-Startregisterkarte „Arbeitsprofil-Schnelleinstellung“ beschrieben Kachel, Arbeitsprofildialoge, Launcher-Schulungsmeldungen, Kontextwechsel und anderes Systemdesign Elemente. Diese Anforderungen zielen darauf ab, einen Mindeststandard akzeptabler Hardware- und Software-UX-Konsistenz zwischen Android Enterprise-empfohlenen Geräten zu fördern.
Es scheint jedoch, dass die Anforderung an Geräte, jeden Monat schnell Sicherheitspatch-Updates zu erhalten, besteht Android-Sicherheitsbulletin (ASB) hat sich für viele Anbieter als zu hohe Hürde erwiesen.
Google drängt auf Update-Transparenz für Android Enterprise Empfohlen
Android-Entwickler @deletescape, der kürzlich einen durchgesickerten Entwurf von geteilt hat Googles Kompatibilitätsdefinitionsdokument für Android 11, erhielt einen durchgesickerten Entwurf der neuen empfohlenen Android Enterprise-Anforderungen für Geräte mit Android 11. Unter dem "Gerätesicherheit„Abschnitt, den wir unten wiedergegeben haben, schlägt Google die Streichung einer Reihe von Anforderungen für das AER-Programm vor. Nach diesen neuen vorgeschlagenen Regeln wird nicht mehr garantiert, dass AER-Geräte innerhalb von 90 Tagen nach einem ASB Sicherheitspatch-Updates erhalten. Interessanterweise deutet eine der Zeilen im Diagramm darauf hin, dass Google diese Anforderung mit der Umstellung auf Android 10 tatsächlich von 90 Tagen auf 30 Tage verschärft hat, Google dies jedoch immer noch nicht aktualisiert hat öffentliche Anforderungsliste um diesen Wandel widerzuspiegeln. Allerdings gilt diese Anforderung im Rahmen der vorgeschlagenen Änderungen nicht mehr für Android Enterprise-empfohlene Geräte mit Android 11. Darüber hinaus sind Anbieter nicht mehr verpflichtet, drei Jahre lang regelmäßige Sicherheitsupdates für AER-Geräte bereitzustellen. Sie müssen jedoch weiterhin ESMR-Updates (Emergency Security Maintenance Release) bereitstellen. was vermutlich bedeutet, dass sie nur Updates mit Korrekturen für kritische Sicherheitsbereiche einführen müssen Schwachstellen.
Android 10 im Vergleich zu Android 11 – Gerätesicherheitsanforderungen für Android Enterprise empfohlen
Kategorie |
Seriennummer |
MUSS/KANN |
Attribut und Implementierung |
Kommentare |
Q (Android 10) |
R (Android 11) |
|||
Gerätesicherheit |
1 |
MAI |
Betreiben Sie ein OEM Vulnerability Rewards Program (VRP) |
Betreiben Sie ein OEM Vulnerability Rewards Program (VRP) |
2 |
MAI |
StrongBox-Unterstützung |
StrongBox-Unterstützung |
|
3 |
MAI |
Hardwaregestützte Keystore-Unterstützung |
Hardwaregestützte Keystore-Unterstützung |
|
4 |
MAI |
Unterstützung für den Geräte-ID-Nachweis |
Unterstützung für den Geräte-ID-Nachweis |
|
5 |
MAI |
Unterstützung der Schlüsselbescheinigung |
Unterstützung der Schlüsselbescheinigung |
|
6 |
30-tägige Sicherheitsupdates |
Anforderung entfernt |
Ersetzt durch Sicherheitstransparenzanforderung |
|
7 |
MUSS |
3 Jahre Support für Emergency Security Maintenance Release (ESMR) |
3 Jahre Support für Emergency Security Maintenance Release (ESMR) |
Ersetzt durch Sicherheitstransparenzanforderung |
8 |
Dateibasierte Verschlüsselung – standardmäßig aktiviert. Verwendet die AOSP-Implementierung. |
Anforderung entfernt |
Dies ist eine GMS-Anforderung, die für alle Geräte gilt |
|
9 |
90-Tage-Sicherheitsupdates |
Anforderung entfernt |
Ersetzt durch Sicherheitstransparenzanforderung |
|
10 |
3 Jahre Support für Sicherheitsupdates (evtl. 3 Jahre ESMR) |
Anforderung entfernt |
Ersetzt durch Sicherheitstransparenzanforderung |
|
11 |
Veröffentlichen Sie die neueste Sicherheitspatch-Stufe |
Anforderung entfernt |
Ersetzt durch Sicherheitstransparenzanforderung |
mehr lesen
Wie in der Tabelle erwähnt, schlägt Google vor, viele dieser Anforderungen durch neue „Transparenz“-Anforderungen zu ersetzen. Tatsächlich schlägt Google die Hinzufügung eines neuen Abschnitts mit dem Titel „Transparenz bei Sicherheits-/Betriebssystemaktualisierungen.“ In den neuen Anforderungen wird detailliert beschrieben, wie Anbieter verpflichtet werden, Informationen wie das End-of-Life-Datum für Sicherheitswartungsversionen und den neuesten Sicherheitspatch zu veröffentlichen verfügbar sind, wie oft das Gerät Updates erhält, welche Korrekturen in jedem Update enthalten sind, wie lange die Software ausgeliefert wird und welche Software-Updates für das Gerät geplant sind und vieles mehr. Interessanterweise verlangt Google auch, dass Android 11-Geräte Zertifizierungstests durch das Unternehmen durchlaufen ioXt-Allianz bevor sie von Android Enterprise empfohlen werden können. Die ioXt Alliance ist ein Zusammenschluss von Unternehmen, deren Ziel es ist, die Sicherheit von IoT-Produkten zu verbessern. Zu seinen Mitgliedern zählen Amazon, Facebook, Google, NXP und mehr. Google sagt, dass diese Zertifizierung die Transparenz erhöhen wird, vermutlich weil sie mehr Transparenz bietet Unternehmen eine unabhängige Messgröße dafür, wie sicher ein bestimmtes Gerät ist, und nicht nur das von Google Sicherheit.
Transparenzanforderungen für Sicherheits-/Betriebssystemupdates (neu) für Android Enterprise empfohlen
Kategorie |
Seriennummer |
MUSS/KANN |
Attribut und Implementierung |
Kommentare |
Q (Android 10) |
R (Android 11) |
|||
Transparenz bei Sicherheits-/Betriebssystemaktualisierungen |
1 |
MUSS |
Folgende Aktualisierungsinformationen MÜSSEN auf der OEM-Website veröffentlicht werden – Enddatum der SMR-Unterstützung (letztes Datum, an dem das Gerät SMR erhält) – aktuell Sicherheitspatch verfügbar – Häufigkeit der Aktualisierungen, die das Gerät erhält – Im Sicherheitspatch enthaltene Korrekturen, einschließlich aller OEM-spezifischen behebt |
Änderung der Anforderung von SMR-Unterstützung zu SMR/Patches/Updates-Transparenz |
2 |
MUSS |
Die folgenden Betriebssysteminformationen MÜSSEN auf der OEM-Website veröffentlicht werden: Betriebssystem, mit dem das Gerät geliefert wird, aktuelle Hauptversion des Betriebssystems, Aktualisierung aller wichtigen Betriebssystemversionen, die das Gerät erhalten wird |
Änderung der Anforderung von Unterstützung zu Transparenz, z. B.: Pixel 3 – Ausgelieferte Version – Android 9 – Aktuelle Version – Android 10 – Erwartete Hauptversion – Android 11 |
|
3 |
MUSS |
Senden Sie das Gerät zur IoXT-Zertifizierung |
IoXT-Scoring sorgt für mehr Transparenz |
mehr lesen
Es ist kein Geheimnis, dass Anbieter Schwierigkeiten haben, mit der Einführung monatlicher Sicherheitspatch-Updates Schritt zu halten. Dafür gibt es viele, viele Gründe: Verzögerungen bei der Netzbetreiberzertifizierung, Warten auf Patches vom Chipsatz und andere Anbieter, die Schwierigkeit, Patches auf stark modifizierte Android-Framework-Builds und Out-of-Tree-Linux-Kernel anzuwenden, und mehr. Einige Android-Benutzer haben sogar bemerkt, wie einige Anbieter die AER-Anforderungen nicht erfüllen. Während die Entwicklungsbemühungen und Lizenzvereinbarungen von Google dies getan haben geholfen, sich zu verbessern Wie schnell Sicherheitsupdates für viele Geräte bereitgestellt werden, ist es ihnen offensichtlich nicht gelungen, die aktuellen Sicherheitspatch-Anforderungen für das Android Enterprise Recommended-Programm aufrechtzuerhalten. Die Lockerung dieser Anforderungen zugunsten von mehr Transparenz wird dazu beitragen, das Programm leichter zugänglich zu machen für Anbieter und gibt Unternehmen auch mehr Vertrauen in das jeweilige Gerät, für das sie sich entscheiden Arbeitskräfte.
Die vorgeschlagene Lockerung der Sicherheitspatch-Updates ist natürlich nicht die einzige Änderung, die am Android Enterprise Recommended-Programm für Android 11 vorgenommen werden könnte. Google plant außerdem, die Mindesthardwareanforderungen von 2 GB RAM auf 3 GB RAM zu erhöhen, die Schulungsanforderungen zu verschärfen und neue Anforderungen für die Arbeitsprofil-UX einzuführen. Die meisten dieser Änderungen werden sich jedoch nicht auf Wissensarbeiter auswirken. Android im Unternehmen ist seit seinen Anfängen stark gewachsen. Wenn Sie mehr über seine Geschichte erfahren möchten, empfehle ich die Lektüre dieser ausgezeichnete Artikel von Jason Bayton.