Schlüsselpunkte
- Runtime Permissions können zu uneinheitlichen App-Konfigurationen auf den einzelnen Geräten führen und erhöhen das Unternehmensrisiko, wenn Benutzer:innen zu großzügig Zugriffe freigeben.
- App-Updates können schleichend zu einem Permission Creep führen: Erweiterte Zugriffe auf Standortdaten im Hintergrund, Speicher oder Sensoren gehen dann ohne strukturierte Prüfung über die ursprüngliche Risikobewertung hinaus.
- Apps mit zu weitreichenden Berechtigungen legen Unternehmensdaten offen, etwa vertrauliche Dateien, Kontaktlisten, Bewegungsprofile oder Live-Audio und -Video. Damit werden Berechtigungen zu einem wichtigen Governance-Thema.
- Eine wirksame Governance von Android-Berechtigungen setzt App-Prüfungen, geplante Audits, rollenbasierte Zugriffskontrollen (RBAC) und Sicherheitsrichtlinien voraus, die den Compliance-Status der Geräte berücksichtigen.
- Trotz der Sicherheitsmechanismen von Android bleiben übermäßige und veraltete Berechtigungen ein möglicher Angriffsvektor für Unternehmen.
Android Runtime Permissions sind Sicherheitsmechanismen, mit denen Apps den Zugriff auf sensible Daten und Gerätefunktionen bei den Benutzer:innen anfragen müssen. Dieses Berechtigungsmodell verbessert zwar den Datenschutz auf dem Gerät, bringt für Unternehmen mit großen Geräteflotten aber auch Governance-Herausforderungen mit sich.
Das Modell der Android Runtime Permissions: Übersicht und Risiken
In den frühen Android-Tagen wurden App-Berechtigungen über ein Berechtigungsmodell zur Installationszeit geregelt. Dieses Modell vergab statische Berechtigungen direkt bei der Installation und räumte damit weitreichende Zugriffe ein, ohne dass Benutzer:innen die Tragweite zuvor verstanden hätten.
Mit Android 6.0 (Marshmallow) kamen die Runtime Permissions hinzu. Seitdem werden Zugriffe auf sensible Geräteressourcen wie Kamera, Mikrofon, Standort und Kontakte kontextbezogen freigegeben.
Mit Runtime Permissions können Benutzer:innen Anwendungen folgende Zugriffsrechte erteilen:
- Zulassen: Die App erhält dauerhaften Zugriff auf die angefragte Geräteressource
- Ablehnen: Der App-Zugriff auf die angefragte Ressource wird blockiert, die Anfrage kann aber später erneut erscheinen
- Nur während der Nutzung der App zulassen: Der Zugriff gilt nur bei aktiver Nutzung der App, Zugriffe im Hintergrund bleiben gesperrt
- Einmaligen Zugriff erlauben: Erlaubt den Ressourcenzugriff vorübergehend für eine einzelne Sitzung
- Nicht mehr fragen / dauerhaft ablehnen: Blockiert den Zugriff und unterbindet weitere Abfragen, bis Benutzer:innen die Einstellung manuell ändern
Da Runtime Permissions von den Benutzer:innen selbst erteilt werden, können die Konfigurationen innerhalb einer Umgebung von Gerät zu Gerät stark abweichen.
Permission Creep und Lebenszyklus-Risiko bei App-Berechtigungsanfragen
Anwendungen erhalten in der Regel zahlreiche Updates, besonders solche, die strengen Softwareentwicklungs-Lebenszyklen folgen. Mit jedem Update können die Berechtigungsanforderungen wachsen, manchmal so unauffällig, dass Unternehmen sie ohne gründliche Prüfung schlicht übersehen.
Weil Runtime Permissions erst erteilt werden, wenn eine App zum ersten Mal auf eine Ressource zugreift, bilden die ursprüngliche Freigabe und Risikobewertung nach einem Update unter Umständen nicht mehr ab, auf welche Daten die App tatsächlich zugreifen kann. Einzelne Berechtigungsänderungen wirken zwar klein, summieren sich aber über die Zeit und führen zu einem erheblichen Risiko.
Um zu verstehen, wie Permission Creep die Risikolage eines Unternehmens verändert, lohnt ein Blick darauf, wo er typischerweise entsteht.
Standortzugriff im Hintergrund
Manche Anwendungen, etwa HR-Portale, benötigen den Zugriff auf Geo-Tracking im Vordergrund, wodurch die Standortdienste nur bei aktiver Nutzung der App anlaufen. App-Updates können jedoch zusätzlich Standortzugriff im Hintergrund anfragen. Wird diese Berechtigung nicht wieder entzogen, entstehen schnell übermäßige Standortrechte.
Erweiterter Zugriff auf Speicher oder Medien
Bei Runtime Permissions können Updates einen erweiterten Speicherzugriff anfragen, wodurch Apps ungewollt weitreichenden Zugriff auf Speicherbereiche mit sensiblen Dokumenten erhalten. Ohne saubere Prüfung weitet Permission Creep beim Speicherzugriff die Datenzugriffskontrolle eines Unternehmens still und leise aus.
Zunehmende Datenerfassung
Android Runtime Permissions fragen den Zugriff auf Daten oder Geräteressourcen an, darunter Kontakte, Anrufprotokolle, Dateien, Speicher, Kamera und Mikrofon. Jede erteilte Berechtigung erweitert aber nicht nur die Fähigkeiten einer App, sondern auch die Angriffsfläche des Unternehmens.
In Unternehmensumgebungen brauchen Android Runtime Permissions deshalb eine fortlaufende Überwachung, Alarmierungen bei risikoreichen Berechtigungen und eine regelmäßige Neubewertung der erteilten Freigaben.
Android Runtime Permissions als Frage der Data Governance
Erteilte Berechtigungen sorgen dafür, dass Anwendungen effizient arbeiten. Gleichzeitig sind sie potenzielle Zugangswege zu geschützten Unternehmensdaten, denn sie vergrößern das Risiko der Datenoffenlegung auf einem Gerät.
Zu den Risiken zählen:
- Abhörrisiko: Über den Mikrofonzugriff können vertrauliche Gespräche nach außen übertragen werden.
- Visuelles Risiko: Der Kamerazugriff lässt sich nutzen, um sensible Dokumente oder Geräte in abgesperrten Unternehmensbereichen aufzunehmen.
- Proximity Mapping: Angreifer:innen können über Bluetooth-Berechtigungen Geräte in der Nähe erkennen und so die interne Infrastruktur kartieren.
Das Runtime-Modell von Android basiert auf der Zustimmung der Benutzer:innen. Erscheinen Abfragen immer wieder, führt Abstumpfung zu Gewöhnung, und Freigaben erfolgen mit der Zeit eher automatisiert als nach echter Prüfung.
Hinzu kommt: Zustimmung bedeutet nicht, dass das Risiko verstanden wurde. Vage Anfragen wie „Mikrofonzugriff zulassen“ machen die möglichen Folgen für die Unternehmenssicherheit nicht deutlich.
Governance für Android Runtime Permissions in Unternehmen
Da Android-App-Updates Berechtigungen mit der Zeit veralten lassen, müssen sie Teil umfassenderer Governance-Programme sein.
Prüf- und Freigabeprozesse für Apps
Vor der Einführung sollten Anwendungen einen Prüfprozess durchlaufen, der ihre Berechtigungen bewertet und mit der erwarteten Funktion abgleicht. Der Freigabeprozess sollte Folgendes umfassen:
- Bewertung der deklarierten Berechtigungen vor der Bereitstellung.
- Abgleich zwischen App-Funktion und angefragtem Zugriff.
- Risikobewertungen auf Basis der Sensibilität der angefragten Ressourcenzugriffe.
- Ablehnung von Anwendungen mit zu weitreichenden Berechtigungen.
Regelmäßige Berechtigungs-Audits
Ohne regelmäßige Audits sammeln Anwendungen im Lauf der Updates nach und nach übermäßige Berechtigungen an. Unternehmen sollten Prüfungen der erteilten Berechtigungen fest einplanen, neu angefragte risikoreiche Zugriffe laufend überwachen und alles gegen die freigegebene Risikotoleranz abgleichen.
Im Idealfall führen Techniker:innen diese Prüfungen bei der Einarbeitung einer App, nach größeren App-Updates oder mindestens quartalsweise als Teil der laufenden Berechtigungs-Governance durch.
Rollenbasierte Richtlinien für mobile Zugriffe
Nicht alle Beschäftigten brauchen dasselbe Maß an Zugriffsrechten, denn der Bedarf unterscheidet sich je nach Rolle und Verantwortung. Unternehmen sollten bestimmte Berechtigungen für Rollen mit höherem Risiko einschränken und den Zugriff auf sensible Ressourcen nach dem Prinzip der Minimalprivilegien begrenzen.
Bedingter Zugriff auf Basis des Gerätezustands
Runtime Permissions sollten zu den übergreifenden Frameworks für Gerätezustand und Compliance passen. Ein Gerät, das riskante App-Zugriffe erlaubt, sollte beispielsweise nur eingeschränkt auf sensible Unternehmensinformationen zugreifen dürfen. So stellen Sie sicher, dass nur sichere und Compliance-konforme Geräte Zugang zu wichtigen Geschäftssystemen erhalten.
Sicherheitsmechanismen jenseits der Verwaltung von App-Berechtigungsanfragen
Runtime Permissions sind nur ein Teil der umfassenderen Sicherheitsarchitektur von Android. Die meisten modernen Android-Geräte bringen mehrere integrierte Schutzmechanismen mit, die eine Kompromittierung des Systems eindämmen, Anwendungen isolieren und sensible Daten absichern sollen.
App-Sandboxing
Android nutzt Sandboxes, um jede Anwendung zu isolieren und Berechtigungszugriffe zwischen Apps zu reduzieren. Apps laufen also in getrennten Prozessen, und der direkte Zugriff auf die Daten einer anderen App ist eingeschränkt. Sandboxing begrenzt allerdings nicht, worauf eine App mit zu weitreichenden Berechtigungen zugreifen kann.
Scoped Storage
Scoped Storage schränkt die uneingeschränkte Sichtbarkeit des gemeinsamen Speichers ein. Apps können damit nur auf ihre eigenen Verzeichnisse zugreifen, der Zugriff auf gemeinsam genutzte Medien erfordert eine ausdrückliche Berechtigung. Von Benutzer:innen erteilte Speicherberechtigungen weiten diese Schutzgrenze jedoch wieder auf.
Hardwaregestützter Keystore
Der Keystore von Android dient als Speicher für Verschlüsselungsschlüssel in einer gesicherten Hardwareumgebung. Das schützt Anmeldeinformationen und kryptografische Schlüssel vor Diebstahl oder Exfiltration, indem sensibles Schlüsselmaterial isoliert und die Angriffsfläche gegenüber Angriffen und Malware verringert wird.
Verified Boot
Android Verified Boot (AVB) prüft die Systemintegrität und stellt sicher, dass das Betriebssystem eines Geräts beim Start nicht manipuliert wurde. Beachten Sie dabei: AVB hilft zwar, Kompromittierungen auf Root-Ebene zu verhindern, bewertet aber keine Berechtigungsentscheidungen auf Anwendungsebene.
Diese Mechanismen stärken die Integrität der Plattform, beseitigen aber nicht das Risiko der Datenoffenlegung, das von vertrauenswürdigen Anwendungen mit zu weitreichenden Berechtigungen ausgeht.
Die Sicherheitsmechanismen von Android sind sehr widerstandsfähig gegenüber Systemkompromittierungen, und in vielen Umgebungen stammen Apps von vertrauenswürdigen Anbietern, während Unternehmen ihre Geräte abgesichert halten. Sicherheitsvorfälle in Unternehmen entstehen typischerweise durch übermäßige Berechtigungen in Anwendungen und durch veraltete Berechtigungen, die den Governance-Kontrollen entgangen sind.
Runtime Permissions auf Android-Geräten mit NinjaOne verwalten
NinjaOne bietet eine richtlinienbasierte Verwaltung für Android-App-Berechtigungen und unterstützt Administrator:innen dabei, Runtime Permissions für jede einzelne Android-Anwendung zu steuern.
- Berechtigungs-Overrides pro App: Mit NinjaOne erlauben, verweigern oder erfragen Sie den Zugriff auf bestimmte Berechtigungen für jede App und setzen damit globale Einstellungen außer Kraft.
- Overrides für delegierte Bereiche: Erteilen Sie Anwendungen zusätzliche Rechte, etwa für Zertifikatsinstallationen oder den Zugriff auf verwaltete Konfigurationen.
- Verwaltete Konfigurationen: Stellen Sie spezifische Einstellungen für Apps bereit, damit sich diese auf allen verwalteten Android-Geräten einheitlich verhalten.
Eine saubere Governance der Android Runtime Permissions senkt das Risiko
Android Runtime Permissions verlagern die Freigabe von App-Anfragen vom Installationszeitpunkt hin zu einer Entscheidung der Benutzer:innen. In Unternehmensumgebungen kann eine starke Abhängigkeit von Runtime Permissions jedoch Governance-Lücken erzeugen.
Weil Anwendungen Updates erhalten und Benutzer:innen App-Anfragen freigeben, wird die Berechtigungs-Governance zu einem zentralen Teil Ihrer Sicherheitsstrategie gegen veraltete Berechtigungen. Berechtigungs-Audits, Lebenszyklus-Prüfungen und die Durchsetzung von Richtlinien im Mobile Device Management senken das Risiko der Datenoffenlegung und helfen, die Compliance einzuhalten.
Verwandte Themen:
