Mobile Device Management: MDM, MAM en Windows 10


Veel gemeenten in Nederland maken gebruiken van Office 365 en als onderdeel van de veel afgenomen E3 licentie (de zgn. VNG werkplek) hebben diezelfde gemeenten ook Intune tot hun beschikking voor het beheren van mobiele apparaten. Uiteraard bestaan er andere softwarepakketten, maar in deze blog refereer ik vooral naar Intune cq Endpoint Manager. Wanneer gebruik je nu MDM en wanneer MAM, en hoe zit dat met Windows 10 apparaten?

Vier niveaus (Android/iOS)

Welbeschouwd kan je informatie op mobiele apparaten op vier niveaus beveiligen. Allereerst kan je het volledige beheer van het apparaat vereisen alvorens informatie mag worden ingezien op dat apparaat. We noemen dat (Mobile) Device Management, ofwel MDM. Dit is echter problematisch wanneer het een BYOD apparaat is, er vanuit gaande dat dit wordt ondersteund door de IT afdeling natuurlijk. In dat geval wordt er vaak gekozen voor het (softwarematig) beheren van een deel van het apparaat: een zogenaamde, afschermde en logisch gescheiden container. Binnen die container mag informatie worden ingezien, daarbuiten niet. Dat noemen we (Mobile) Application Management, ofwel MAM.

So far so good. Wat mij betreft is het zinvol om in deze context twee andere niveaus toe te voegen. Zo ís het ook mogelijk om binnen één app een beperkt beveiligingsbeleid af te dwingen, zoals (MFA) authenticatie. Dat hoeft dus niet op een beheerd apparaat (MDM) of van MAM (container) voorzien BYOD apparaat te zijn, maar kán ook op een apparaat dat, zogezegd, 100% privé is qua hard- en software. Tot slot is informatie ook op het documentniveau te beveiligen middels de zgn. ‘gevoeligheidslabels’. Via Information Right Management (IRM) is te configureren of informatie mag worden ingezien, bewerkt, afgedrukt, doorgestuurd of gekopieerd en onder welke condities dat dan mag.

Het komt dus op het onderstaande neer, waarbij de eerste drie onder Enterprise Mobility Management vallen en de laatste onder Information Right Management. Niveau 4 is dus qua technologie wezenlijk anders. Informatie (4) open je veelal in een applicatie (3), en die applicatie draait – eventueel in een container (2) – op een apparaat (1).

  1. Beveiligen op apparaatniveau (fully managed, enrolled, MDM)
  2. Beveiligen op containerniveau (BYOD, registered, MAM)
  3. Beveiligen op applicatieniveau (BYOD, MAM-WE)
  4. Beveiligen op documentniveau (sensitivity labels, IRM)

Windows 10

Uiteraard gaat het niet alleen om mobiele apparaten met Android of iOS als besturingssysteem, maar ook om (veelal) laptops met daarop Windows 10. Zelf werk ik nooit met MacOS dus om het mijzelf niet te moeilijk te maken, laat ik die verder buiten beschouwing. Windows apparaten kunnen worden gekoppeld aan (Azure) Active Directory (AAD); dit is niet mogelijk bij Android of iOS apparaten. Windows 10 apparaten die volledig in beheer zijn, zijn ‘AD joined’ (zie 1. hierboven) terwijl apparaten die alleen geregistreerd zijn in de AAD ‘AD registered’ zijn (zie 2. hierboven).

Maar ook niveau 3 en 4 zijn mogelijk op een Windows 10 apparaat. Wanneer iemand bijvoorbeeld een Sharepoint of OneDrive link naar een vertrouwd document met je deelt, moet je doorgaans authentiseren – hopelijk met MFA – wanneer je opent van een vanaf een niet-AD-joined apparaat. De applicatie dwingt dat af en dus zit je op niveau 3 . Tot slot werkt IRM (niveau 4) niet alleen óók op Windows 10 apparaten; het werkt voorál op Windows 10 apparaten. (Mocht je als gemeente bezig zijn met de implementatie van Microsoft Information Protection of Azure Information Protection, dan kom ik graag met je in contact.)

De menukaart

Vanzelfsprekend dient iedere gemeente te bedenken welke gerechten er op de menukaart komen te staan. Sommige gemeenten doen qua Android/iOS alleen 1 – MDM, maar in mijn persoonlijke ervaring kiest het merendeel voor 2 – MAM, al dan niet in combinatie met MDM. Op deze manier heb je namelijk ook een antwoord op de BYOD behoefte. Gerecht 4 – IRM heb ik nog niet in productie zien werken, enkele tests daargelaten. En 3 is nu eenmaal beperkte qua mogelijkheden en derhalve eigenlijk alleen een bij- of tussengerecht.

Maar hoe zit dat op Windows 10 laptops? Daar bestaat de MAM container oplossing immers niet als zodanig. Een laptop die AD registered is, is nog steeds wezenlijk anders in beheer dan een mobiele telefoon voorzien van MAM. Mijn waarneming is natuurlijk beperkt, maar ik zie dat het bij Windows 10 apparaten vaak gaat om ofwel 1 (AD joined, niveau 4) voor laptops die eigendom van de gemeente zijn, ofwel 3 als het gaat om BYOD laptops. Maar dus géén AD registered terwijl je dat wel zou verwachten wanneer je kijkt wat werknemers op een BYOD laptop eigenlijk allemaal mogen onder niveau 3. Via niveau 2 is het namelijk mogelijk een beveiligingsbeleid af te dwingen op het apparaat. Natuurlijk is dat beleid beperkter dan het MDM beleid bij niveau 1, maar wel degelijk uitgebreider dan het beveiligingsbeleid op de applicatie van niveau 3.

Conditional Access, IRM en DLP

Zodra je menukaart gereed is, kan je middels voorwaardelijke toegang – of gewoon: Conditional Access, CA – bepalen welke apparaten en applicaties verbinding mogen maken met zaken als e-mail (Exchange) en bedrijfsgegevens (Sharepoint, OneDrive, Teams etc.). En dan vooral, zoals de naam al doet vermoeden, onder welke voorwaarden dat dan mag. Middels CA kan je voorwaarden stellen aan de gebruiker (bijv. locatie, groups), zijn/haar apparaat en de applicaties daarop. Op basis daarvan kan CA irt AAD toegang verlenen, blokkeren of MFA afdwingen voor extra zekerheid.

IRM is wat dat aangaat meer recht-toe-recht-aan: op documentniveau staat gewoonweg middels een label gedefinieerd wat wel en niet mag. En heel belangrijk hier: of er encryptie moet worden toegepast op het document. En daar wordt het al lastiger met al die (niet-Windows) apparaten, zeker als het gaat om e-mail. Dat voert voor hier echter te ver. Maar het wordt pas echt leuk wanneer je de verschillende vormen van EMM (1-3) koppelt aan CA en via CA aan IRM (4). En uiteraard houd je dat alles netjes in de gaten via Data Leak Prevention (DLP). En natuurlijk hoeft dat geenszins met Microsoft producten. Gelukkig is er keuze.

Ps. de IBD bracht al in 2013 een Handreiking Mobile Device Management uit.

Renco Schoemaker
Laatste berichten van Renco Schoemaker (alles zien)

Lees ons boek

Gemeenten. Bewustzijn. Privacy.

Het handboek voor informatiebewustzijn bij de lokale overheid.

Bijeenkomsten

Alleen voor CISO’s van de (lokale) overheid!

Bekijk wanneer de volgende bijeenkomst is.

Alleen voor Privacy Officers van de (lokale) overheid!

Bekijk wanneer de volgende bijeenkomst is.

Meer blogs lezen

Security by Design concreet gemaakt

Met de komst van de AVG in 2018, is er ook veel aandacht voor de begrippen ‘Privacy by Design’ en ‘Security by Design’. Maar wat wordt hier nu eigenlijk mee bedoeld en waarom is het zo belangrijk? In deze blog wil ik graag specifiek ingaan op Secu…

Mobile Device Management: MDM, MAM en Windows 10

Vanuit de BIO is het helder dat je een vorm van beheer dient te voeren op apparaten, waaronder mobiele apparaten als telefoons, tablets en laptops. Welke mogelijkheden heb je daar eigenlijk tot je beschikking voor iOS, Android en Windows 10?

De BIO en het toepassen van encryptie; wat moet je weten?

Encryptie is een serieus onderdeel geworden binnen veel organisaties. Niet voor niets worden er in BIO eisen benoemd als het gaat om encryptie. Welke eisen zijn dit en wat moet je hier als CISO over weten?

De ingrediënten van een jaarverslag

In gemeenteland komt het jaarverslag er weer aan. Schrijf jij als CISO of FG al een separaat jaarverslag over informatiebeveiliging of privacy? Zeker doen!

Het bijhouden van een verwerkingsregister, hoe doe je dat?

Hoe zorg je er voor dat het bijhouden van het verwerkingsregister op een juiste en consistente wijze gebeurt?

Ont-Googlen en terughoudendheid met de cloud

Welke keuzes maak je zelf als het gaat om producten en diensten van de tech-giganten? In hoeverre weeg jij zelf informatiebeveiliging en privacy mee? Vandaag een blog met de persoonlijke reis van Renco.