Belangrijkste punten
- Runtime permissions kunnen leiden tot inconsistente app-configuraties op verschillende devices en vergroten het risico voor organisaties wanneer gebruikers te veel toegang goedkeuren.
- App-updates kunnen geleidelijk permission creep veroorzaken: uitgebreide toegang tot locatie op de achtergrond, opslag of sensoren kan zonder gestructureerde beoordeling verder gaan dan de oorspronkelijke risicobeoordeling.
- Apps met te veel rechten stellen bedrijfsgegevens bloot (vertrouwelijke bestanden, contactlijsten, locatiepatronen, live audio of video) waardoor permissies een belangrijk governance-vraagstuk worden.
- Effectieve governance van Android-permissies vereist het screenen van apps, geplande audits, role-based access controls (RBAC) en beveiligingsbeleid dat rekening houdt met de compliance-status van een device.
- Zelfs met de beveiligingsmaatregelen van Android blijven overmatige en verouderde permissies een mogelijke aanvalsroute binnen organisaties.
Android runtime permissions zijn beveiligingsmaatregelen die apps verplichten om gebruikers toestemming te vragen voor toegang tot gevoelige gegevens en functies van een device. Dit permissiemodel verbetert de privacy op het device, maar zorgt ook voor uitdagingen op het gebied van governance bij organisaties die grote aantallen devices beheren.
Het Android runtime-permissiemodel: overzicht en risico’s
In de begindagen van Android werden app-permissies afgehandeld via een permissiemodel op installatiemoment. Dat model kende statische permissies toe bij de installatie, waardoor brede toegang werd verleend zonder dat gebruikers eerst begrepen wat de gevolgen waren.
Met de introductie van Android 6.0 (Marshmallow) maakten runtime permissions contextuele goedkeuring mogelijk voor toegang tot gevoelige bronnen op een device, zoals de camera, microfoon, locatie en contacten.
Met runtime permissions kunnen gebruikers applicaties de volgende toegangsrechten verlenen:
- Toestaan: geeft apps doorlopende toegang tot de gevraagde bron op het device
- Weigeren: blokkeert de toegang van de app tot de gevraagde bron, al kan de app later opnieuw vragen
- Alleen toestaan tijdens gebruik van de app: verleent alleen toegang wanneer de app actief wordt gebruikt en beperkt toegang op de achtergrond
- Eenmalige toegang verlenen: staat tijdelijke toegang tot een bron toe voor één sessie
- Niet meer vragen / permanent weigeren: blokkeert de toegang en voorkomt verdere meldingen tenzij de gebruiker dit handmatig wijzigt
Omdat runtime permissions door de gebruiker worden gestart, kan dit leiden tot uiteenlopende configuraties per device binnen een omgeving.
Permission creep en lifecycle-risico bij app-permissies
Applicaties krijgen doorgaans talloze updates, zeker wanneer ze strikte software development lifecycles volgen. Bij elke update kunnen de permissievereisten van applicaties uitbreiden en soms gebeurt dat zo subtiel dat organisaties het zonder grondige beoordeling missen.
Omdat runtime permissions pas worden verleend wanneer een app voor het eerst toegang zoekt tot een bron, weerspiegelen de oorspronkelijke goedkeuring en risicobeoordeling na een update mogelijk niet meer wat een app werkelijk aan gegevens kan benaderen. Permissiewijzigingen lijken misschien klein, maar ze stapelen zich na verloop van tijd op en leiden tot een aanzienlijk blootstellingsrisico.
Om te begrijpen hoe permission creep de risicopositie van een organisatie verandert, is het belangrijk om te kijken waar permission creep meestal ontstaat.
Toegang tot locatie op de achtergrond
Sommige applicaties, zoals HR-platformen, vragen soms om geo-tracking op de voorgrond, waarbij locatiediensten alleen worden geactiveerd wanneer de app in gebruik is. App-updates kunnen echter verzoeken introduceren voor locatietoegang op de achtergrond, wat tot overmatige locatierechten kan leiden als die niet op tijd worden ingetrokken.
Uitgebreide toegang tot opslag of media
Bij runtime permissions kunnen updates om uitgebreide opslagtoegang vragen, waardoor apps onbedoeld te veel toegang krijgen tot opslag met gevoelige documenten. Zonder goede beoordeling verruimt permission creep bij opslag ongemerkt de toegangscontrole op gegevens binnen een organisatie.
Meer gegevensverzameling
Android runtime permissions vragen toegang tot gegevens of bronnen op het device, waaronder contacten, belgeschiedenis, bestanden, opslag, camera en microfoon. Elke verleende permissie vergroot de mogelijkheden van een app, maar vergroot ook het aanvalsoppervlak van een organisatie.
In zakelijke omgevingen vereisen Android runtime permissions daarom doorlopende monitoring, waarschuwingen bij permissies met een hoog risico en periodieke herbeoordeling van verleende permissies.
Android runtime permissions als governance-vraagstuk rond gegevens
Het verlenen van permissies helpt applicaties om efficiënt te werken. Permissies vormen echter ook mogelijke routes naar beschermde bedrijfsgegevens, omdat ze het risico op gegevensblootstelling van een device vergroten.
Enkele risico’s zijn:
- Risico op afluisteren: toegang tot de microfoon kan vertrouwelijke gesprekken naar buiten doorsturen.
- Visueel risico: cameratoegang kan worden gebruikt om gevoelige documenten of apparatuur in afgeschermde bedrijfsruimtes vast te leggen.
- Omgevingsverkenning: aanvallers kunnen Bluetooth-permissies misbruiken om devices in de buurt te detecteren en zo de interne infrastructuur in kaart te brengen.
Het runtime-model van Android draait om goedkeuring door de gebruiker. Wanneer meldingen zich herhalen, leidt gewenning tot automatisme, waardoor goedkeuringen na verloop van tijd eerder reflexmatig dan weloverwogen worden gegeven.
Bovendien betekent toestemming niet dat iemand het risico begrijpt: vage verzoeken zoals “Toegang tot microfoon toestaan” maken de mogelijke gevolgen voor de bedrijfsbeveiliging niet duidelijk.
Governance van Android runtime permissions binnen organisaties
Omdat permissies door Android-app-updates na verloop van tijd verouderd kunnen raken, moeten ze worden opgenomen in bredere governance-programma’s.
Screening en goedkeuring van apps
Voordat een applicatie in gebruik wordt genomen, moet die een beoordelingsproces doorlopen waarin de permissies worden getoetst aan de verwachte functie. Het goedkeuringsproces moet het volgende omvatten:
- Beoordeling van de opgegeven permissies vóór uitrol.
- Afstemming tussen de functie van de app en de gevraagde toegang.
- Risicoscores op basis van de gevoeligheid van de gevraagde toegang tot bronnen.
- Afwijzing van applicaties met te veel rechten.
Periodieke permissie-audits
Zonder regelmatige audits kunnen applicaties geleidelijk te veel permissies verzamelen naarmate er updates worden doorgevoerd. Organisaties moeten beoordelingen van verleende permissies inplannen, doorlopend controleren op nieuw aangevraagde toegang met een hoog risico en dit toetsen aan de goedgekeurde risicobereidheid.
Idealiter voeren technici deze beoordelingen uit tijdens de onboarding van een app, na grote app-updates of minimaal elk kwartaal als onderdeel van de reguliere permissie-governance.
Role-based toegangsbeleid voor mobiele devices
Niet alle medewerkers hebben hetzelfde niveau van toegangsrechten nodig, omdat de toegangsbehoefte per rol en verantwoordelijkheid verschilt. Organisaties moeten bepaalde permissies beperken voor rollen met een hoger risico en de toegang tot gevoelige bronnen inperken volgens het principe van minste voorrecht.
Voorwaardelijke toegang op basis van de status van het device
Runtime permissions moeten aansluiten op bredere kaders voor apparaatgezondheid en compliance. Een device dat riskante app-toegang toestaat hoort bijvoorbeeld beperkte toegang te krijgen tot gevoelige bedrijfsinformatie. Zo zorgt u ervoor dat alleen veilige en compliant devices toegang hebben tot belangrijke bedrijfssystemen.
Beveiligingsmaatregelen die verder gaan dan het beheer van app-permissies
Runtime permissions vormen slechts een deel van de bredere beveiligingsarchitectuur van Android. De meeste moderne Android-devices bevatten meerdere ingebouwde beschermingsmaatregelen die zijn ontworpen om systeemcompromittering te beperken, applicaties te isoleren en gevoelige gegevens te beschermen.
App-sandboxing
Android gebruikt sandboxes om elke applicatie te isoleren, wat de toegang tussen applicaties beperkt. Apps draaien dus in afzonderlijke processen en directe toegang tot de gegevens van een andere app is beperkt, maar sandboxing beperkt niet wat een app met te veel rechten kan benaderen.
Scoped storage
Scoped storage beperkt de onbeperkte zichtbaarheid van gedeelde opslag. Via scoped storage hebben apps alleen toegang tot hun eigen mappen en vereist toegang tot gedeelde media expliciete toestemming. Opslagpermissies die door de gebruiker worden verleend verruimen deze beschermende grens echter.
Hardwarematig ondersteunde keystore
De keystore van Android dient als opslag voor encryptiesleutels binnen een veilige hardware-omgeving. Dit beschermt referenties en cryptografische sleutels tegen diefstal of exfiltratie door gevoelig sleutelmateriaal te isoleren en de blootstelling aan aanvallen en malware te verkleinen.
Verified boot
Android Verified Boot (AVB) valideert de integriteit van het systeem en controleert of het besturingssysteem van een device tijdens het opstarten niet is gemanipuleerd. Houd er rekening mee dat AVB compromittering op rootniveau helpt voorkomen, maar geen oordeel velt over permissiebeslissingen op applicatieniveau.
Deze maatregelen versterken de integriteit van het platform, maar nemen niet het risico weg dat bedrijfsgegevens worden blootgesteld via vertrouwde applicaties met te veel rechten.
Hoewel de beveiligingsmaatregelen van Android bijzonder bestand zijn tegen systeemcompromittering, komen apps in veel omgevingen van vertrouwde leveranciers en houden organisaties hun devices beveiligd. Datalekken binnen organisaties ontstaan doorgaans door overmatige permissies op applicaties en door verouderde permissies die aan de governance-controles zijn ontsnapt.
Beheer runtime permissions op Android-devices met NinjaOne
NinjaOne biedt beleidsgebaseerd beheer voor permissies van Android-apps, waarmee beheerders de runtime permissions van elke Android-applicatie afzonderlijk kunnen beheren.
- Permissie-overrides per app: met NinjaOne staat u specifieke permissies per app toe, weigert u ze of laat u erom vragen, waarmee u globale instellingen overschrijft.
- Overrides voor gedelegeerde bevoegdheden: ken applicaties extra bevoegdheden toe, zoals het installeren van certificaten of toegang tot beheerde configuraties.
- Beheerde configuraties: rol specifieke instellingen voor apps uit om consistent app-gedrag op alle beheerde Android-devices te waarborgen.
Goede governance van Android runtime permissions verkleint het risico
Android runtime permissions verschuiven de goedkeuring van app-verzoeken van een model op installatiemoment naar een model waarin de gebruiker het initiatief neemt. In zakelijke omgevingen kan sterke afhankelijkheid van runtime permissions echter governance-gaten veroorzaken.
Naarmate applicaties updates krijgen en gebruikers app-verzoeken goedkeuren, wordt permissie-governance een cruciaal onderdeel van uw beveiligingsstrategie om verouderde permissies te voorkomen. Door permissie-audits, lifecycle-beoordelingen en beleidshandhaving op te nemen in programma’s voor device management beperkt u de blootstelling van gegevens en behoudt u compliance.
Gerelateerde onderwerpen:
