Je hebt een strak ingerichte SCCM-omgeving, deployments lopen soepel en je collections zijn netjes georganiseerd. En dan komt er een beveiligingsaudit. Plotseling staat iedereen te kijken naar wie er eigenlijk toegang heeft tot wat, welke endpoints niet gepatcht zijn en of je compliance-baselines wel kloppen. Herkenbaar?
IT-beveiliging binnen een Configuration Manager-omgeving is een onderwerp dat veel beheerders bewust voor zich uitschuiven. Niet omdat ze het niet belangrijk vinden, maar omdat het complex is en er altijd wel iets anders brandt. In dit artikel gaan we concreet in op wat je kunt doen om je SCCM-omgeving beter te beveiligen, zonder dat je er een fulltime project van hoeft te maken.
Toegangsbeheer en rolgebaseerde beveiliging in SCCM
Role-Based Administration (RBA) is het fundament van toegangsbeveiliging in Configuration Manager. Je kunt hiermee exact bepalen wie wat mag zien en doen binnen de console. Toch is het in de praktijk verbazingwekkend hoe vaak iedereen gewoon ‘Full Administrator’ heeft. Want dat is makkelijk, dat werkt altijd, en er is nooit tijd om het anders in te richten.
Het probleem is dat brede rechten ook brede risico’s meebrengen. Als een account wordt gecompromitteerd, of als iemand per ongeluk een deployment uitrolt naar de verkeerde collection (want wie heeft er nou niet een keer een verkeerde collection getarget), dan heb je een probleem dat veel groter is dan nodig was. RBA beperkt de blast radius.
Begin met het inventariseren van wie toegang heeft tot de SCCM-console en met welke rechten. Maak daarna een overzicht van de functionele rollen binnen je organisatie: wie doet software distribution, wie beheert compliance, wie kijkt alleen maar mee? Op basis daarvan kun je security scopes en collections combineren om precies de juiste toegang te geven, zonder meer. Microsoft heeft hiervoor een aantal ingebouwde rollen die al een heel eind komen, maar je kunt ook custom rollen aanmaken als je iets specifieks nodig hebt.
Vergeet ook de service-accounts niet. Die draaien vaak al jaren met rechten die ooit ‘even snel’ zijn ingesteld en sindsdien nooit meer zijn herzien. Zet ze op een aparte OU, beperk hun rechten tot wat strikt noodzakelijk is en zorg dat ze vallen onder je wachtwoordbeleid of, beter nog, gebruik Managed Service Accounts (MSA’s) zodat je wachtwoordrotatie automatisch gaat.
Patch management en compliance baselines
SCCM is van origine een krachtig platform voor software updates en patch management. Maar een goed ingericht updateproces is meer dan alleen ADR’s aanmaken en hopen dat alles goed gaat. De combinatie van patch management en compliance monitoring is waar de echte beveiligingswinst zit.
Stel je voor dat je een ADR hebt draaien die elke maand netjes de Patch Tuesday-updates deployt. Prima. Maar wat doe je met de systemen die al weken niet inchecken? Of de servers die uitgesloten zijn van automatische updates omdat er ‘speciale afspraken’ over zijn, maar waar die afspraken nergens zijn gedocumenteerd? Dat zijn de gaten waar aanvallers doorheen kruipen.
Gebruik compliance baselines om te meten of systemen voldoen aan je beveiligingseisen. Je kunt hierin zowel configuratie-items opnemen (zoals specifieke registersleutels, Windows Firewall-instellingen of aanwezigheid van bepaalde software) als update-compliance. Koppel die baselines aan rapportages zodat je altijd een actueel beeld hebt van de staat van je omgeving. Rapportages in SCCM zijn niet de meest sexy feature, maar ze zijn wél de reden dat je bij een audit niet in de stress schiet.
Een punt dat vaak wordt onderschat: houd ook je SCCM-infrastructuur zelf gepatcht. De site servers, de distribution points, de SQL-instanties. Die draaien soms op systemen die worden vergeten in het patchproces, juist omdat ze ‘beheersystemen’ zijn en niet als eindpunt worden gezien. Dat is een blinde vlek die je wilt dichten.
Voor bredere context over hoe patch management past binnen een overkoepelend beveiligingsbeleid, is het nuttig om te kijken naar wat er speelt op het gebied van endpoint- en netwerkbeveiliging (https://www.ictivity.nl/it-security), want SCCM is zelden het enige stuk van de puzzel.
Logging, monitoring en detectie in je SCCM-omgeving
Beveiliging zonder zicht is geen beveiliging. Je kunt nog zulke goede policies hebben ingericht, als je niet weet wat er in je omgeving gebeurt, loop je altijd achter de feiten aan. SCCM genereert enorm veel logdata, maar die data is pas waardevol als je er iets mee doet.
De statusberichten en logbestanden in SCCM zijn een goudmijn voor troubleshooting, maar ook voor detectie van verdacht gedrag. Denk aan onverwachte deployments die ineens actief worden, wijzigingen in collections of boundaries, of accounts die op ongebruikelijke tijden inloggen op de console. Dit soort activiteit valt op als je er actief naar kijkt.
Integreer SCCM-logging waar mogelijk met je SIEM-oplossing. Veel organisaties sturen Windows Event Logs door naar hun SIEM, maar vergeten de SCCM-specifieke logs. De belangrijkste om te monitoren zijn onder andere smsprov.log (alle acties via de SMS Provider, dus ook console-acties), rbac.log (toegangscontrole) en distmgr.log (distribution point-activiteit). Dit zijn de logs die je vertellen wie wat heeft gedaan en wanneer.
Stel ook statusfilterregels in voor kritieke events. SCCM heeft een ingebouwd systeem voor statusberichten waarmee je alerts kunt genereren op basis van specifieke condities. Dat is geen vervanging voor een volwaardige SIEM, maar het is een laagdrempelige manier om basismonitoring in te richten zonder extra tooling.
Tot slot: test je detectie. Het klinkt voor de hand liggend, maar de meeste organisaties weten niet of hun monitoring werkt totdat er iets misgaat. Voer periodiek een gesimuleerde actie uit (bijvoorbeeld een testdeployment naar een lege collection) en controleer of die actie zichtbaar is in je logs en alerts. Zo weet je zeker dat je niet blind vaart.
Veelgestelde vragen over IT-beveiliging in SCCM
Hoe weet ik wie er allemaal toegang heeft tot mijn SCCM-omgeving?
Ga in de SCCM-console naar Administration > Security > Administrative Users. Daar zie je een overzicht van alle gebruikers en groepen met toegang, inclusief hun toegewezen rollen en security scopes. Combineer dit met een export van de groepsleden uit Active Directory als je met AD-groepen werkt, zodat je een volledig beeld hebt van wie er via welke groep toegang heeft. Het is een goed idee om dit overzicht minimaal eens per kwartaal te reviewen.
Wat is het verschil tussen een compliance baseline en een software update group?
Een software update group bevat specifieke patches die je wilt deployen naar systemen. Een compliance baseline meet of systemen voldoen aan bepaalde configuratie-eisen, waaronder ook update-compliance, maar ook instellingen, aanwezige software of registerwaarden. Ze vullen elkaar aan: je deployt updates via een software update group en je meet de naleving via een compliance baseline. De baseline geeft je inzicht, de update group doet het werk.
Moet ik HTTPS afdwingen voor al mijn SCCM-communicatie?
Ja, als je het kunt inrichten wel. Enhanced HTTP (eHTTP) is een goede tussenoplossing als je niet meteen naar volledig PKI-gebaseerde HTTPS wilt, maar voor productieomgevingen is het advies om HTTPS te gebruiken voor alle client-communicatie. Zeker als je clients hebt die buiten het interne netwerk communiceren via een Cloud Management Gateway (CMG), is HTTPS geen optie maar een vereiste. HTTP laat communicatie onversleuteld en maakt je omgeving kwetsbaar voor man-in-the-middle-aanvallen.