Produktneuigkeiten

Einführung der AndroidX Security State-Bibliotheken: Eine ganzheitliche Übersicht der Gerätesicherheit

Lesezeit: 4 Minuten
3 Autoren
Maunik Shah, Alec Garcia, Joseph Yong

Wir bei Android arbeiten ständig daran, Entwicklern und Unternehmenspartnern die Daten zur Verfügung zu stellen, die sie zum Schutz von Geräten benötigen. Heute freuen wir uns, die stabile Version 1.1.0 der AndroidX Security State-Bibliothek und die Version 1.0.0 der Security State Provider-Bibliothek anzukündigen. Diese Bibliotheken bieten einen zentralen Mechanismus, der für mehr Transparenz in Bezug auf den umfassenden Sicherheitsstatus und ausstehende Updates im gesamten Android-Ökosystem sorgt.

Unabhängig davon, ob Sie sicherheitskritische, kundenorientierte Apps (z. B. für Banking, Fintech oder Gesundheitswesen) oder Lösungen für die Mobilgeräteverwaltung (Mobile Device Management, MDM) entwickeln, können Sie mit diesen Bibliotheken den Sicherheitsstatus des Geräts pro Komponente programmatisch überprüfen. Anstatt sich auf ein grobes, monolithisches Sicherheitspatch-Level (SPL) zu verlassen, können Sie über die Bibliothek androidx.security.state den tatsächlichen Schutz auf Komponentenebene und den Status von Abhilfemaßnahmen bewerten. Für OEMs und Entwickler von OTA-Clients (Over-The-Air) bietet die zugehörige Bibliothek androidx.security.state.provider die Möglichkeit, die Verfügbarkeit von Updates über standardisierte Mechanismen offenzulegen.

Sicherheitspatch-Level (SPL)

Android hat sich weiterentwickelt und bietet jetzt schnelle, unabhängige Komponentenupdates über modulare Systeme wie Google Play-Systemupdates. Daher ist es nicht mehr die beste Methode, sich auf ein einzelnes SPL-Build-Attribut zu verlassen, um den tatsächlichen Sicherheitsstatus eines Geräts zu bestimmen. Um die Sichtbarkeit auf Komponentenebene zu ermöglichen, bieten die Security State-Bibliotheken APIs für drei verschiedene Patch-Level:

  • Geräte-SPL (DSPL): Das Sicherheitspatch-Level, das derzeit auf dem Gerät für bestimmte Systemkomponenten installiert ist und ausgeführt wird. Es wird aus den Geräteeigenschaften und ‑konfigurationen ohne Netzwerkaufrufe abgefragt.
  • Veröffentlichtes SPL (PSPL): Das neueste Patch-Level, das offiziell im Sicherheitsbulletin für Android für diese Komponenten veröffentlicht wurde.
  • Verfügbares SPL (ASPL): Das Patch-Level, das heruntergeladen und auf dem jeweiligen Gerät installiert werden kann. Es wird asynchron über die Interprozesskommunikation (IPC) mit Update-Clients auf dem Gerät abgefragt.

Die Security State-Bibliotheken verfolgen diese Patch-Level für die folgenden Komponenten:

  • System : Das Android-Betriebssystem, das über Standard-/OEM-System-Over-the-air-Updates aktualisiert wird.
  • Systemmodule : Modulare Betriebssystem-Subsysteme, die im Hintergrund über Google Play-Systemupdates (Project Mainline) aktualisiert werden.
  • Kernel : Die grundlegende Ebene, die die Hardware und Software des Geräts verbindet. Er wird anhand von Langzeitsupport-Release-Versionen (z. B. 5.15.159 oder 6.1.91) und nicht anhand von monatlichen Kalenderdaten bewertet.

Durch die Darstellung dieser drei verschiedenen Patch-Level auf Komponentenebene können Entwickler und Unternehmen jetzt genau nachvollziehen, wie sicher ein Gerät ist, fehlende Patches identifizieren und proaktive Maßnahmen ergreifen. Eine Möglichkeit dazu sehen Sie im Beispiel unten.

Anstatt beim Gerätezugriff einen Alles-oder-Nichts-Ansatz zu verfolgen, können Entwickler und Unternehmen DSPL, PSPL und ASPL kombinieren, um intelligente, kontextbezogene Sicherheitsentscheidungen zu treffen. Beispielsweise kann eine Banking- oder Unternehmens-App den aktuellen Sicherheitspatch (DSPL) eines Geräts mit ausstehenden Updates (ASPL) vergleichen, bevor sensible Workflows wie Zahlungen mit hohem Wert oder die Registrierung von Anmeldedaten initiiert werden. Wenn ein Update installiert werden muss, können Entwickler und Unternehmen festlegen, dass der Nutzer zuerst sein Gerät aktualisieren muss. Für eine noch genauere Kontrolle können Entwickler und Unternehmen abfragen, ob bestimmte Sicherheitslücken mit hohem Risiko (CVEs) auf dem Gerät behoben wurden. So können sie beispielsweise prüfen, ob kritische NFC- oder Bluetooth-Fehler behoben wurden, bevor sie das Bezahlen per Smartphone oder die Weitergabe von Daten in der Nähe autorisieren.

Allgemeiner Ablauf

blog_effective_security_state.png

Für App-Entwickler und Unternehmensverwaltung

Clientanwendungen können die Bibliothek androidx.security.state verwenden, um fundierte, kontextbezogene Entscheidungen zu treffen:

  • Synchronous Posture Checks (DSPL): Apps können beim Start sofort die installierten Patch-Level des Systems, der Systemmodule und des Kernels prüfen und mit dem PSPL vergleichen, um zu prüfen, ob das Gerät die erforderliche Sicherheitsgrundlage einer Organisation erfüllt, bevor sensible Unternehmensressourcen oder der biometrische Zugriff freigegeben werden.
  • Aufforderung zu ausstehenden Updates (ASPL): Anstatt einen Mitarbeiter, dessen Gerät leicht hinter den Patches zurückliegt, sofort zu blockieren, können Unternehmens-Apps die ASPL abfragen, um zu prüfen, ob ein ausstehendes Systemupdate oder Google Play-Systemupdate bereitgestellt und zur Installation bereit ist. In diesem Fall können Apps eine personalisierte In-App-Anleitung anzeigen, die den Nutzer zu den Systemeinstellungen weiterleitet, um die Installation abzuschließen.
  • Prüfung auf Sicherheitslückenebene (CVEs): Für Anwendungsfälle mit hoher Sicherheit bietet die Bibliothek die Möglichkeit, gerätespezifische Berichte zu Sicherheitslücken von Open Source Vulnerabilities (OSV) herunterzuladen, um programmatisch zu prüfen, ob bestimmte kritische CVEs auf dem Gerät behoben wurden.

Für OEMs und Update-Clients: Standardisierung der Update-Verfügbarkeit

Die zugehörige Bibliothek androidx.security.state.provider stellt einen standardisierten Android-IPC-Mechanismus bereit, mit dem Update-Clients die Verfügbarkeit von Updates direkt auf dem Gerät melden können. In der Vergangenheit waren diese Informationen, selbst wenn proprietäre OTA-Clients die Verfügbarkeit von Updates anzeigten, isoliert und konnten nicht von Drittanbieteranwendungen abgefragt werden. In Zukunft können Apps über eine einzige, einheitliche API auf ASPL-Details zugreifen, unabhängig davon, ob das Update über den dedizierten OTA-Client eines OEMs oder über Google Play bereitgestellt wird, solange es vom Update-Client bereitgestellt wird.

  • Google Play-Systemupdates stellen bereits ASPL auf GMS-Android-Geräten bereit.
  • Google Over-The-Air (GOTA) wurde ebenfalls integriert und wir arbeiten mit OEMs weltweit zusammen, um ihre OTA-Clients in dieses standardisierte Framework einzubinden.

Daten auf Bulletin-Ebene einbeziehen

Die Security State-Bibliotheken bieten mehr als nur einen einzelnen SPL-String. Sie geben Aufschluss darüber, was das Patch-Level tatsächlich für das Gerät bedeutet. Durch die Einbindung der OSV-Datenbank (Open Source Vulnerabilities) zum Abrufen von Daten aus dem Sicherheitsbulletin für Android können die Bibliotheken tiefer als je zuvor blicken. Anstatt nur zu fragen, ob eine bestimmte Bedrohung, z. B. ein CVE-Eintrag, blockiert wird, können die Bibliotheken anhand dieser Daten auch den „effektiven“ und detaillierten Sicherheitsstatus des Geräts angeben.

Dieser Ansatz bietet Unternehmen und Android-OEMs zwei Vorteile:

  • Manchmal enthält ein monatliches Sicherheitsupdate keine neuen Bedrohungen für eine bestimmte Komponente. In diesem Fall erhöhen die Bibliotheken automatisch das Sicherheitsniveau für diese Komponente, um den „effektiven“ Sicherheitsstatus widerzuspiegeln. So wird sichergestellt, dass ein Gerät korrekt als vollständig geschützt gegen alle bekannten Sicherheitsbedrohungen eingestuft wird.
  • Eine neue Funktion in Android 17 ermöglicht es OEMs, bestimmte Sicherheitskorrekturen, die über das SPL hinaus angewendet wurden, über eine XML-Datei für zusätzliche Patches zu deklarieren. Mit dieser Funktion können OEMs, die bestimmte Sicherheitskorrekturen rückportieren, die Geräte-Compliance sofort nachweisen, ohne auf eine vollständige monolithische SPL-Erhöhung warten zu müssen. So wird sichergestellt, dass kontinuierliche Patching-Maßnahmen ordnungsgemäß berücksichtigt werden. Die Security State-Bibliotheken stellen diese detaillierten Informationen Apps und Diensten zur Verfügung, sodass kontinuierliche Patching-Maßnahmen sofort nach der Implementierung erkannt werden.

Jetzt starten

Die Security State Libraries wurden entwickelt, um das gesamte Android-Ökosystem zu unterstützen.

Deine Meinung ist uns wichtig und wir freuen uns immer über Feedback. Probieren Sie die Bibliotheken aus und teilen Sie uns Ihre Meinung mit oder melden Sie Probleme im öffentlichen Android Issue Tracker.

Verfasst von:
Weiterlesen