Je hebt een mooie SCCM-omgeving opgezet, deployments lopen, collections zijn netjes ingedeeld en alles werkt. En dan vraagt iemand van security: “Hoe is jullie netwerk eigenlijk gesegmenteerd?” Goede vraag. Want netwerksegmentatie en SCCM zijn nauwer verweven dan de meeste beheerders beseffen.
Waarom netwerksegmentatie je SCCM-omgeving raakt
SCCM communiceert voortdurend met clients verspreid over je netwerk. De site server, de distribution points, de management points en alle clients sturen constant data heen en weer: inventory, policies, content downloads, status messages. Als je netwerk plat is — alles in één groot subnet — werkt dat technisch prima, maar je loopt risico’s die je liever niet hebt.
Een gecompromitteerde client kan in een plat netwerk in principe communiceren met alle andere clients én met je site server. Dat is geen hypothetisch scenario. Ransomware verspreidt zich graag via lateral movement, en een SCCM-omgeving zonder segmentatie is een uitnodiging om van één besmette machine naar honderd te gaan.
Segmentatie dwingt je ook na te denken over boundaries en boundary groups. In SCCM definieer je boundaries op basis van IP-subnetten, Active Directory-sites of IP-bereiken. Als je netwerk netjes opgesplitst is in logische segmenten, sluit dat vrijwel naadloos aan op hoe SCCM boundaries wil zien. Een plat netwerk maakt boundary-configuratie juist moeilijker en leidt tot onvoorspelbaar content-routinggedrag.
Segmentatie-architectuur die werkt met SCCM
De meest praktische aanpak is een scheiding op basis van functie. Denk aan een apart segment voor servers, één voor werkstations, één voor beheerverkeer en eventueel een apart segment voor OT-apparatuur of kiosksystemen. SCCM past zich daar goed op aan, mits je de infrastructure goed inricht.
Distribution points zijn hierbij de sleutel. Je wilt een distribution point in elk netwerksegment dat clients bedient, of in ieder geval bereikbaar vanuit dat segment via een gecontroleerde route. Content die over een WAN-verbinding of door een firewall heen moet, kost bandbreedte en vertraagt deployments. Een goed geplaatst distribution point lost dat op. Vergeet ook niet de preferred distribution points in je boundary groups te configureren — anders laat SCCM clients zelf zoeken en dat gaat niet altijd goed.
Firewall-regels zijn de andere kant van de medaille. SCCM heeft een flinke lijst poorten nodig: 80 en 443 voor HTTP/HTTPS-communicatie, 10123 voor client notification, 8530/8531 voor WSUS als je software-updates via SCCM distribueert, en nog een handvol andere. Beheerders die bij De koning ICT netwerken ontwerpen en beheren, zien regelmatig dat SCCM-poorten in firewall-rulesets vergeten worden, waarna clients stil vallen zonder duidelijke foutmelding. Zet die poortlijst in je change-documentatie en controleer hem bij elke segmentatiewijziging.
Praktische valkuilen en hoe je ze voorkomt
De meest gemaakte fout is segmentatie doorvoeren zonder de SCCM-boundaries bij te werken. Je verplaatst een subnet, past de firewall aan, en vergeet dat SCCM nog steeds denkt dat die clients in het oude segment zitten. Resultaat: clients vallen buiten elke boundary group, worden niet meer correct beheerd en verdwijnen langzaam uit je console. Niet meteen zichtbaar, maar na een paar weken zie je de heartbeat discovery-data opdrogen.
Een tweede valkuil is het beheernetwerk niet apart nemen. Je SCCM-site server en SQL-backend zijn kritische systemen. Als die in hetzelfde segment zitten als gewone werkstations, is er geen extra drempel voor een aanvaller die al voet aan de grond heeft. Isoleer je beheerinfrastructuur in een apart segment met strikte toegangsregels. Alleen beheerders en geautoriseerde systemen mogen daar verkeer naartoe sturen.
Hieronder de meest voorkomende segmentatie-gerelateerde problemen in SCCM-omgevingen op een rij:
- Clients vallen buiten alle boundary groups na een subnetsplitsing, waardoor content niet meer wordt gevonden
- Software-updates falen omdat WSUS-verkeer door een firewall geblokkeerd wordt op poort 8530 of 8531
- Client notification werkt niet door geblokkeerde poort 10123, waardoor push-acties vanuit de console niet aankomen
- PXE-boot mislukt in gesegmenteerde netwerken zonder IP-helper of DHCP-scope-optie 66/67
- Inventory-data veroudert doordat management point-communicatie intermitterend faalt
- Slow content downloads omdat clients een distribution point in een ver segment gebruiken in plaats van een lokale replica
- CMG-configuratieproblemen bij omgevingen die de Cloud Management Gateway inzetten voor internet-clients
De meeste van deze problemen zijn te voorkomen met een goede voorbereiding. Maak een netwerktekening voordat je segmenteert, markeer alle SCCM-rollen erop en trek lijnen voor elk communicatiepad. Dan zie je vanzelf waar je firewall-regels nodig hebt.
Veelgestelde vragen over netwerksegmentatie en SCCM
Moet ik voor elk subnet een aparte boundary aanmaken?
Niet per se, maar het is wel de meest betrouwbare aanpak. SCCM ondersteunt IP-subnetten, IP-bereiken en Active Directory-sites als boundary-type. Als je netwerk netjes in subnetten is opgedeeld, maak dan voor elk subnet een boundary en voeg die toe aan de juiste boundary group. Zo weet SCCM precies welk distribution point en welk management point een client moet gebruiken. Gebruik je IP-bereiken, let dan op dat je geen overlap creëert — dat geeft onvoorspelbaar gedrag bij content-locatie.
Hoe ga ik om met clients die tussen segmenten bewegen?
Laptops zijn het klassieke voorbeeld: thuis, op kantoor, in een filiaal. SCCM handelt dit af via de boundary group-fallback-configuratie. Je stelt in hoeveel minuten een client mag wachten voordat hij terugvalt op een naburige boundary group of de default site boundary group. Zorg dat je fallback-tijden realistisch zijn — te kort en clients bombarderen andere distribution points, te lang en gebruikers wachten eindeloos op content. Voor internet-clients is de Cloud Management Gateway de aangewezen route, zodat je geen gaten in je firewall hoeft te schieten voor thuiswerkers.
Heeft netwerksegmentatie invloed op mijn SCCM-rapportages?
Indirect wel. Als clients door segmentatieproblemen buiten boundaries vallen of hun management point niet bereiken, stoppen ze met het sturen van inventory en statusberichten. Je rapportages gaan er dan rooskleuriger uitzien dan de werkelijkheid, omdat niet-rapporterende clients simpelweg ontbreken. Check regelmatig de Client Activity-rapporten in de console en vergelijk het aantal actieve clients met wat je in Active Directory verwacht. Een significante afwijking is bijna altijd een signaal dat er iets mis is met de netwerk- of boundary-configuratie.