Compliance is zo’n woord dat bij veel sysadmins een lichte kramp veroorzaakt. Niet omdat je er niets om geeft, maar omdat het altijd net op het verkeerde moment opduikt — vlak voor een grote rollout, of als iemand van Legal ineens vragen begint te stellen over welke data je eigenlijk verzamelt. En als je met SCCM werkt, raak je die vragen sneller dan je denkt. Want Configuration Manager doet zijn werk goed, misschien zelfs té goed: het verzamelt, rapporteert en logt van alles. Handig. Maar ook een AVG-aandachtspunt.
Wat heeft SCCM eigenlijk met de AVG te maken?
Meer dan je op het eerste gezicht zou denken. SCCM verzamelt standaard een behoorlijke hoeveelheid hardware- en software-inventory van alle beheerde endpoints. Denk aan geïnstalleerde applicaties, serienummers, gebruikersnamen, inlogtijden, locatiegegevens als je met co-management werkt, en ga zo maar door. Dat is allemaal nuttig voor je dagelijks beheer, maar het zijn ook persoonsgegevens of gegevens die herleidbaar zijn tot een persoon.
De AVG — officieel de Algemene Verordening Gegevensbescherming — stelt eisen aan hoe je met die data omgaat. Je moet kunnen aantonen dat je alleen verzamelt wat je nodig hebt, dat je data beveiligd opslaat, en dat je weet waar het naartoe gaat. Klinkt abstract, maar in de praktijk betekent het dat je even goed moet nadenken over wat je in je hardware-inventory-klassen hebt aangevinkt, en of je dat allemaal echt gebruikt.
Inventory: minder is meer
Dit is het moment waarop ik even eerlijk moet zijn: de standaard hardware-inventory in SCCM is royaal. Heel royaal. Microsoft heeft een lange lijst met inventory-klassen klaarstaan, en de verleiding is groot om ze allemaal aan te zetten. Want stel dat je het later nodig hebt, toch?
Doe dat niet. Of in elk geval: doe het niet zonder bewuste keuze.
Ga door je Hardware Inventory Classes heen en vraag jezelf per klasse af:
- Gebruik ik deze data actief in reports of collections?
- Is er een operationele reden om dit te verzamelen?
- Kan deze data herleid worden tot een individuele gebruiker?
Als het antwoord op de eerste twee vragen “nee” is en op de derde “ja”, dan heb je een probleem. Klassen zoals SMS_SystemConsoleUsage of Win32_UserProfile bevatten informatie die direct aan personen te koppelen is. Die schakel je uit tenzij je er een concrete, gedocumenteerde reden voor hebt.
Hetzelfde geldt voor Software Metering. Het is verleidelijk om bij te houden wie welke applicatie wanneer gebruikt — en soms is dat legitiem, bijvoorbeeld voor licentieoptimalisatie. Maar zorg dat je dat kunt verantwoorden, en leg het vast in je verwerkingsregister.
Wat zegt de wet, en waar vind je dat terug?
Je hoeft het wiel niet zelf uit te vinden. De informatie van de Rijksoverheid over de AVG legt helder uit welke verplichtingen er gelden voor organisaties die persoonsgegevens verwerken — inclusief de verplichting om een verwerkingsregister bij te houden en passende technische maatregelen te treffen. Dat laatste is precies het domein waar jij als sysadmin een directe rol speelt.
“Passende technische maatregelen” klinkt vaag, maar in SCCM-termen is het concreet: toegang tot de SCCM-console beperken via Role-Based Administration, audit logging inschakelen, data minimaliseren in je inventory, en zorgen dat je SQL-database niet voor iedereen open staat. Dat zijn geen nice-to-haves. Dat zijn dingen die je Functionaris Gegevensbescherming — als je die hebt — zou moeten kunnen aanwijzen als bewijs dat je het serieus neemt.
En als je geen FG hebt? Dan ben je waarschijnlijk zelf degene die dit moet uitleggen als er ooit een audit komt. Fijn vooruitzicht. Reden te meer om het nu goed te regelen.
Role-Based Administration: je eerste verdedigingslinie
Een van de krachtigste AVG-tools in SCCM is er al ingebouwd: Role-Based Administration, of RBA. Het idee is simpel — niet iedereen hoeft alles te zien of te doen. In de praktijk kom je echter genoeg omgevingen tegen waar iedereen Full Administrator is, want “het is makkelijker”. Dat snap ik. Maar het is ook een AVG-risico en een security-risico in één.
Stel jezelf de vraag: wie heeft er in jouw omgeving toegang tot de SCCM-console, en wat kunnen ze daarmee?
Een helpdesk-medewerker die remote control nodig heeft, hoeft geen collections aan te maken of software te deployen. Een applicatiebeheerder die packages maakt, hoeft geen volledige hardware-inventory in te zien. RBA laat je dat netjes scheiden via security roles en security scopes. Ja, het kost tijd om goed in te richten. Maar het is de investering waard, zowel voor compliance als voor je eigen gemoedsrust als er eens iets misgaat.
Een paar praktische tips voor RBA in een AVG-context:
- Gebruik de ingebouwde rollen als startpunt, maar pas ze aan op wat je organisatie écht nodig heeft
- Koppel security scopes aan collections, zodat beheerders alleen zien wat relevant is voor hun scope
- Auditeer regelmatig wie welke rol heeft — mensen wisselen van functie, maar hun SCCM-rechten worden niet altijd mee-aangepast
- Documenteer je rollenstructuur, zodat je bij een audit niet staat te improviseren
Dat laatste punt is serieuzer dan het klinkt. “We hebben het zo ingesteld” is geen antwoord. “We hebben het zo ingesteld, omdat…” — dat is een antwoord.
Deployments en data: denk na voor je uitrolt
Even terug naar deployments, want ook daar zitten AVG-aspecten die makkelijk over het hoofd worden gezien. Stel je voor: je deployt een stuk software dat zelf ook data verzamelt — een monitoring-agent, een communicatietool, een HR-applicatie. Dan ben jij als beheerder medeverantwoordelijk voor wat er na die deployment gebeurt.
Dat betekent niet dat je elk stuk software zelf moet doorlichten — dat is de taak van je privacy-officer of FG. Maar het betekent wel dat je als sysadmin een signalerende rol hebt. Als je een deployment voorbereidt voor een applicatie die je niet kent, is het geen overbodige luxe om even te vragen: is dit ding al langs Legal geweest?
Hetzelfde geldt voor je deployment-configuraties zelf. Denk aan:
- Run as user vs. run as system: als een deployment draait onder gebruikerscontext, worden er andere gegevens gelogd dan bij system-context. Weet je wat er gelogd wordt?
- Deadline-gedrag: forceer je een herstart buiten kantooruren? Dan weet je impliciet wanneer mensen aan het werk zijn. Niet dramatisch, maar het is data.
- Foutmeldingen en logging: SCCM-logs bevatten soms meer dan je denkt. Zorg dat je logbestanden niet onbeperkt groeien en niet voor iedereen toegankelijk zijn.
Dit zijn geen redenen om niet te deployen. Het zijn redenen om even na te denken voor je op “Deploy” klikt. Wat toch al een goed idee is, want wie heeft er nou niet een keer een verkeerde collection getarget en ineens 3.000 machines een reboot ingeschoten. Compliance of niet, dat wil je voorkomen.
Tot slot: compliance is geen project, het is een houding
Het grootste misverstand over AVG-compliance in een SCCM-omgeving is dat het een eenmalig project is. “We hebben er een keer naar gekeken, we zitten goed.” Nee. Je omgeving verandert, je organisatie verandert, de wetgeving verandert, en Configuration Manager zelf verandert met elke Current Branch-update.
Compliance is iets wat je inbouwt in je werkwijze, niet iets wat je er achteraf op plakt. Dat klinkt zwaar, maar in de praktijk zijn het kleine gewoontes:
- Bij elke nieuwe inventory-klasse die je inschakelt: waarom doe ik dit?
- Bij elke nieuwe rol in RBA: heeft deze persoon dit echt nodig?
- Bij elke deployment van een nieuwe applicatie: is dit ding al gescreend?
- Periodiek: wie heeft nog toegang tot wat, en klopt dat nog?
Als je die vragen onderdeel maakt van je normale workflow, ben je al een heel eind. Je hoeft geen AVG-expert te zijn. Je hoeft alleen maar de juiste vragen te stellen op het juiste moment — en bereid te zijn om het antwoord serieus te nemen, ook als dat betekent dat je iets moet uitschakelen of aanpassen.
SCCM is een krachtig platform. Dat is precies waarom je er bewust mee moet omgaan. Niet uit angst voor boetes, maar omdat je het gewoon goed wil doen. En omdat je collega’s — en hun data — dat verdienen.