Skip to main content
#
17 april 2021
Samenvatting
Office 365 biedt verschillende mogelijkheden voor het beheren van mobiele apparaten. In deze blog onderscheid ik de (on)mogelijkheden op vier niveaus.
Volg qeep

Mobile Device Management: MDM, MAM en Windows 10

Inzicht in de verschillende mogelijkheden van mobiele apparaten beheren
17 april 2021

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

Voor Android en 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.

“Windows apparaten kunnen worden gekoppeld aan (Azure) Active Directory (AAD); dit is niet mogelijk bij Android of iOS apparaten.”

Vier smaken op rij

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

Het verschil tussen AD registered en AD joined

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

Welke gerechten wil je aanbieden?

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.

 

“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.”

Conditional Access, IRM en DLP

Nog meer mogelijkheden

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.


Senior Adviseur Security & Privacy bij qeep IT safe.
r.schoemaker@qeep.nl