Wat is een Software Defined Perimeter (SDP)?
Een Software Defined Perimeter (SDP) is een beveiligingsarchitectuur waarin een systeem pas zichtbaar en bereikbaar wordt nadat de identiteit van de gebruiker en de staat van zijn apparaat zijn gecontroleerd, en waarin elke toegestane verbinding een eigen versleutelde tunnel naar precies die ene bron krijgt. In plaats van één statische netwerkgrens met een Firewall trekt een SDP per gebruiker en per sessie een kleine, dynamische perimeter om de bronnen die hij nodig heeft. De Cloud Security Alliance (CSA) publiceerde de eerste SDP-specificatie in april 2014 en versie 2.0 in maart 2022.
In OT-omgevingen voorkomt een SDP dat onbevoegde gebruikers, apparaten of scanners zelfs maar kunnen zien dat systemen zoals SCADA, PLC’s of een Historian bestaan.
🧠 Welke principes liggen onder een SDP?
Het idee komt uit de “need-to-know”-netwerken van het Amerikaanse ministerie van Defensie, waar infrastructuur die niet gezien hoeft te worden ook niet zichtbaar is (“black” netwerken). De CSA vertaalde dat naar een open specificatie voor bedrijven. Vijf principes keren steeds terug:
- Verbergen als standaard - bronnen en zelfs de gateways reageren niet op verkeer van onbekende afzenders. Een poortscan ziet niets.
- Eerst authenticeren, dan verbinden - gebruiker en apparaat worden geverifieerd vóórdat er een netwerkverbinding ontstaat, niet erna zoals bij een klassieke login.
- Dynamisch beleid - toegang hangt af van identiteit, rol, apparaatstatus, locatie en tijd, en wordt per sessie bepaald volgens Least Privilege.
- Wederzijdse authenticatie en versleuteling - client en gateway bewijzen elkaar hun identiteit met certificaten, meestal via mutual TLS (in sommige modellen IKE/IPsec).
- Volledige zichtbaarheid - elke toegang wordt gelogd en is herleidbaar tot een persoon en apparaat.
Daarmee is SDP een concrete uitwerking van Zero Trust: vertrouw niets op basis van netwerklocatie en controleer elke verbinding opnieuw.
🔧 Hoe werkt een SDP technisch?
De CSA-specificatie onderscheidt een controlvlak en een datavlak. Het controlvlak beslist wie waarheen mag; het datavlak transporteert pas daarna het eigenlijke verkeer.
| Component | CSA-term | Functie |
|---|---|---|
| SDP Controller | Controller (Policy Decision Point) | Verwerkt authenticatie, koppelt aan IAM en MFA, bepaalt welke bronnen een client mag bereiken |
| SDP Client | Initiating Host (IH) | Draait op de laptop van de technicus of op een apparaat; levert identiteit en apparaatstatus aan |
| SDP Gateway | Accepting Host (AH), Policy Enforcement Point | Staat vlak voor de beschermde bron en laat alleen geautoriseerde sessies door |
| Beleidsregels | Onderdeel van de controller | Regels op basis van rol, apparaat, locatie, tijdvenster en risico |
| Tunnel | mTLS-verbinding (of IKE/IPsec) | Versleutelde verbinding tussen client en gateway, per sessie opgebouwd |
De verbinding komt in een vaste volgorde tot stand:
- De controller komt online en koppelt aan de identiteits- en autorisatiediensten.
- De gateways (accepting hosts) melden zich bij de controller en negeren vanaf dat moment al het niet-aangemelde verkeer.
- Een client meldt zich bij de controller en authenticeert gebruiker en apparaat.
- De controller bepaalt welke gateways en bronnen deze client mag bereiken.
- De controller instrueert die gateways om de client toe te laten.
- De client krijgt de lijst met toegestane bronnen en bouwt per bron een wederzijds geauthenticeerde tunnel op.
Het verbergen gebeurt met Single Packet Authorization (SPA). Voordat een gateway of controller überhaupt een TCP-verbinding accepteert, moet de client één cryptografisch geauthenticeerd pakket sturen, in de specificatie over UDP. In versie 1.0 bevat dat pakket onder meer een eenmalige code op basis van HOTP (RFC 4226), een op HMAC gebaseerd algoritme, zodat de gateway pakketten zonder geldige code negeert. Zonder geldig SPA-pakket reageert de poort niet, zodat scanners en botnets geen open dienst vinden. Versie 2.0 breidde het SPA-berichtformaat en de alternatieven daarvoor uit en voegde een eerste uitwerking voor IoT-apparaten toe.
🔄 Wat is het verschil tussen een SDP en een VPN?
| Kenmerk | Klassieke VPN | SDP |
|---|---|---|
| Zichtbaarheid | VPN-concentrator staat open op internet en is scanbaar | Gateway is onzichtbaar zonder geldig SPA-pakket |
| Moment van authenticatie | Eerst verbinden, dan inloggen | Eerst authenticeren, dan pas verbinden |
| Toegangsbereik | Vaak een heel netwerksegment | Alleen de toegewezen applicaties of systemen |
| Beleid | Statisch, per groep of IP-bereik | Dynamisch, per gebruiker, apparaat en sessie |
| Laterale beweging | Na inloggen veel vrij bereik | Sterk beperkt, want er is geen route naar niet-toegewezen systemen |
| Gevolg van gestolen inloggegevens | Directe toegang tot het segment | Ook apparaatcertificaat en apparaatstatus zijn nodig |
Een SDP beperkt laterale beweging sterk, maar elimineert die niet: een geautoriseerde laptop die zelf is gecompromitteerd, kan nog steeds de systemen bereiken waartoe hij toegang heeft. Daarom blijft Netwerksegmentatie binnen het OT-netwerk nodig.
🧱 Welke SDP-implementatiemodellen bestaan er?
Specificatie 2.0 beschrijft zes implementatiemodellen. Ze verschillen in topologie, maar handhaven allemaal hetzelfde principe.
| Model | Werking | OT-toepassing |
|---|---|---|
| Client-naar-gateway | Gateway beschermt één of meer servers die zelf niet worden aangepast | Externe toegang tot een HMI, engineering-station of Jump Server |
| Client-naar-server | De server draait zelf SDP-software en is zijn eigen gateway | Moderne servers zoals een historian of MES-server |
| Server-naar-server | Alle verbindingen tussen servers zijn versleuteld en de servers zijn verborgen | Koppeling tussen OT-historian en cloudplatform |
| Client-naar-server-naar-client | Verkeer loopt via een verborgen tussenserver | Spraak, chat en videoverbindingen voor ondersteuning op afstand |
| Client-naar-gateway-naar-client | Peer-to-peer verkeer, met afgedwongen beleid via een verborgen gateway | Directe verbindingen tussen geautoriseerde apparaten |
| Gateway-naar-gateway | Verborgen gateways beschermen verbindingen tussen locaties of IoT-apparaten | Verbinden van buitenstations of IoT-netwerken; nieuw in 2.0 |
Voor OT is het client-naar-gateway-model verreweg het belangrijkste: een PLC of oudere SCADA-server kan geen SDP-software draaien. Let op dat de versleuteling dan bij de gateway eindigt. Het laatste stuk tussen gateway en PLC blijft onversleuteld verkeer zoals Modbus, dus de gateway hoort zo dicht mogelijk bij het asset te staan, in dezelfde zone.
🏭 Waarom is een SDP nuttig in OT?
| OT-uitdaging | Bijdrage van een SDP |
|---|---|
| Legacy-systemen zonder versleuteling | Tunnel tot aan de gateway; geen open poorten van het legacy-systeem richting IT of internet |
| Externe toegang voor leveranciers | Alleen vooraf goedgekeurde technici, alleen tijdens goedgekeurde tijdvensters, alleen naar het eigen systeem |
| Onbekende scans en verkenning | Assets en gateways zijn onzichtbaar voor ongeautoriseerde scanners |
| Overbrugging van IT- en OT-segmenten | Toegang zonder port forwarding of brede firewallregels in de DMZ |
| Noodtoegang bij incidenten | Tijdelijke, gelogde toegang tot specifieke PLC’s of de historian voor forensisch onderzoek |
| IIoT-verbindingen | Sensoren en edge-gateways sturen data naar een cloudplatform zonder open inkomende poorten in het OT-netwerk |
Een SDP ondersteunt zo verschillende eisen uit IEC 62443, zoals beperkte datastromen tussen zones en conduits (Zone and Conduits-model) en gecontroleerde toegang via onbetrouwbare netwerken. Ook in het Purdue Model past het goed: de gateway staat in de DMZ of direct in de doelzone, de controller in de DMZ of in een beheerde (cloud)omgeving buiten de productiezones.
🧭 Hoe voert u een SDP stapsgewijs in OT in?
- Inventariseer toegangsbehoeften - begin met een actuele asset-inventaris en leg per leverancier en medewerker vast welke systemen hij nodig heeft.
- Kies het model - voor PLC’s en oudere systemen het client-naar-gateway-model, voor moderne servers eventueel client-naar-server.
- Koppel identiteit - verbind de controller met uw IAM-omgeving en verplicht MFA en apparaatcertificaten.
- Plaats gateways dichtbij - zet gateways in de doelzone of de DMZ, nooit centraal in het IT-netwerk.
- Begin met één use case - typisch onderhoud op afstand door een leverancier (Remote Maintenance), met tijdvensters en goedkeuring per sessie.
- Log en bewaak - stuur alle sessiegegevens naar uw SIEM en controleer periodiek welke toegangen nog nodig zijn.
- Bouw uit - vervang stap voor stap brede VPN-toegang en vaste firewallregels.
In Nederland is dit relevant voor organisaties onder de Cyberbeveiligingswet (van kracht sinds 15 augustus 2026), die passende maatregelen voor toegangsbeheer en leveranciersrisico’s moeten aantonen. Een SDP is geen wettelijke eis, maar wel een goed verdedigbare maatregel voor toegang op afstand.
❓ Veelgestelde vragen
Is een Software Defined Perimeter hetzelfde als ZTNA?
Software Defined Perimeter en Zero Trust Network Access (ZTNA) beschrijven grotendeels hetzelfde idee: toegang per applicatie na controle van identiteit en apparaat. SDP is de open architectuurspecificatie van de Cloud Security Alliance, terwijl ZTNA de marktterm is voor producten die dit principe leveren; Gartner publiceerde er in 2019 zijn eerste marktgids voor.
Hoe verhoudt een SDP zich tot NIST SP 800-207?
NIST SP 800-207 uit augustus 2020 noemt de software defined perimeter expliciet als een van drie benaderingen om een Zero Trust-architectuur te bouwen, naast verbeterd identiteitsbeheer en microsegmentatie. De publicatie verwijst daarbij naar de CSA-specificatie 1.0.
Kan een PLC zelf een SDP-client of SDP-gateway zijn?
Een klassieke PLC kan geen SDP-software draaien en krijgt dus een gateway voor zich. De SDP-gateway beschermt de PLC dan als accepting host, terwijl het verkeer tussen gateway en PLC onversleuteld blijft en daarom binnen dezelfde zone moet lopen.
Wat is Single Packet Authorization?
Single Packet Authorization (SPA) is de techniek waarmee een SDP-gateway onzichtbaar blijft: de gateway reageert pas nadat de client één cryptografisch ondertekend pakket heeft gestuurd. Zonder dat geldige pakket ziet een scanner geen open poort, waardoor aanvallen op de toegangsdienst zelf veel moeilijker worden.
Vervangt een SDP de firewall in OT?
Een SDP vervangt de firewall niet, maar vult die aan. De firewall blijft verkeer tussen zones filteren, terwijl de SDP bepaalt welke gebruiker op welk moment welk systeem mag bereiken.
Wat zijn de nadelen van een SDP in OT?
Een SDP vraagt om een goed werkend identiteitsbeheer en een beschikbare controller; valt de controller uit, dan kan niemand nieuwe sessies opzetten. Daarnaast zijn commerciële SDP- en ZTNA-producten vaak onderling niet uitwisselbaar, wat de afhankelijkheid van één leverancier vergroot; plan daarom redundante controllers en een gedocumenteerde noodprocedure.
📌 Samengevat
Een Software Defined Perimeter maakt OT-systemen onzichtbaar en geeft alleen geverifieerde gebruikers en apparaten per sessie toegang tot precies de systemen die zij nodig hebben.
Een SDP scheidt beslissen (controller) van doorlaten (gateway), verbergt diensten met Single Packet Authorization en versleutelt elke sessie, meestal met mutual TLS. In OT werkt het vooral als client-naar-gateway-oplossing voor externe toegang en leveranciersonderhoud, als aanvulling op segmentatie en firewalls binnen een Zero Trust-strategie.