Industriële VPN versus TeamViewer: waarom tools voor consumenten niet volstaan in een OT-omgeving
Bij projecten op het gebied van industriële toegang op afstand komt deze vraag regelmatig terug: "Waarom gebruiken we niet gewoon TeamViewer? Dat doen we toch al voor IT-ondersteuning."
Het korte antwoord: OT-netwerken zijn geen IT-netwerken. De besturingssystemen die daarop draaien, sturen fysieke machines aan — een foutieve opdracht of een inbraak kan industriële of zelfs menselijke gevolgen hebben. Consumententools zijn ontworpen voor een totaal andere context.
Dit artikel gaat verder dan een kort antwoord. Het geeft uitleg over het daadwerkelijke dreigingsmodel, beschrijft in detail wat de norm IEC 62443 voorschrijft en presenteert de technische criteria voor het beoordelen van een oplossing voor industriële toegang op afstand.
1. Het Purdue-model en de OT-betrouwbaarheidsniveaus
Om te begrijpen waarom OT-toegang op afstand anders is, moet men bekend zijn met het Purdue-model (Purdue Enterprise Reference Architecture), de internationale standaard voor de segmentatie van industriële netwerken.
Niveau 5 : Réseau d'entreprise (ERP, email, bureautique)
─────────────────────────────────────────────
Niveau 4 : Réseau IT de site (serveurs, SGBD, Active Directory)
─────────────────────────────────────────────
Niveau 3 : Réseau supervision (SCADA, MES, historiens)
─────────────────────────────────────────────
Niveau 2 : Réseau contrôle (IHM, ingénierie)
─────────────────────────────────────────────
Niveau 1 : Réseau terrain (automates, variateurs, capteurs)
─────────────────────────────────────────────
Niveau 0 : Process physique (capteurs, actionneurs, moteurs)
Industriële toegang op afstand heeft doorgaans betrekking op niveau 1 en 2 — de PLC’s en engineeringtools. Deze niveaus mogen nooit zonder controle rechtstreeks toegankelijk zijn vanuit hogere niveaus, en al helemaal niet via het internet.
De segmentering tussen de niveaus vormt de eerste verdedigingslinie. Toegang op afstand gaat per definitie door deze segmentering heen — vandaar de strengere beveiligingseisen.
2. De reële risico’s van ongecontroleerde toegang tot het OT-netwerk
Wat er op een industrieel OT-netwerk wordt weergegeven
Een typisch OT-netwerk omvat:
- Programmeerbare logische controllers (S7, M340, CompactLogix) die de machines aansturen
- Frequentieregelaars die de motoren regelen
- Industriële HMI’s voor bewaking en instelling
- SCADA-systemen die het gehele proces bewaken
- meetinstrumenten (druk-, temperatuur- en debietsensoren)
Deze apparatuur is ontworpen om betrouwbaar te functioneren in afgelegen omgevingen, niet om netwerkaanvallen te weerstaan. Het Modbus-protocol voorziet niet in authenticatie. S7Comm (Siemens) beschikte van oudsher niet over versleuteling. Profinet, EtherNet/IP — de meeste industriële protocollen gaan uit van een vertrouwd netwerk.
Hoe een aanval op een slecht beveiligde OT-toegang op afstand in zijn werk gaat
Zo verloopt doorgaans een aanval op een onbeveiligde industriële toegang op afstand:
Fase 1 — Verkenning (automatisch, passief): Een automatische scanner (Shodan, Censys of een aangepast script) identificeert het openbare IP-adres van de fabriek en ontdekt een open poort (klassieke VPN op UDP 1194, Modbus-poort 502, S7Comm-poort 102). Deze fase genereert geen verdachte logbestanden en duurt enkele seconden.
Fase 2 — Misbruik van de toegang: Als het VPN alleen door een zwak wachtwoord wordt beveiligd (of als de inloggegevens via phishing zijn gestolen), krijgt de aanvaller toegang. Als het om een direct blootgestelde Modbus-poort gaat, kan hij zonder enige authenticatie lezen en schrijven.
Fase 3 — Interne verkenning: Zodra de aanvaller toegang heeft verkregen, brengt hij het OT-netwerk in kaart: welke PLC’s zijn toegankelijk, welke variabelen kunnen worden uitgelezen, welke proceszones worden aangestuurd.
Fase 4 — Kwaadwillige actie: De acties kunnen onmiddellijk plaatsvinden (stopzetting van de productie, wijziging van parameters) of onopvallend (geleidelijke aanpassing van instelwaarden om de productkwaliteit te verslechteren zonder dat er een alarm afgaat).
De gevaarlijkste aanvallen zijn niet de meest spectaculaire. Een afwijking van ±5 % van een doseringsinstelling in een chemische of farmaceutische installatie kan dagenlang onopgemerkt blijven, met mogelijk rampzalige gevolgen voor de kwaliteit van het eindproduct.
Gedocumenteerde incidenten
De ANSSI en het CISA (Cybersecurity and Infrastructure Security Agency, Verenigde Staten) brengen regelmatig incidenten in kaart met betrekking tot onvoldoende beveiligde industriële toegang op afstand:
- TeamViewer op een watercontrolepost (Florida, 2021): een aanvaller heeft de niveaus van de chemische behandeling gewijzigd via TeamViewer dat was geïnstalleerd op het SCADA-systeem van een drinkwaterzuiveringsinstallatie. De aanval werd door de operator ter plekke opgemerkt, maar had onopgemerkt kunnen blijven.
- VPN zonder MFA in de energiesector: er zijn meerdere incidenten gedocumenteerd waarbij gestolen VPN-inloggegevens toegang gaven tot regionale elektriciteitsnetwerken in Europa.
- Modbus-poortdoorsturing: beveiligingsonderzoekers hebben herhaaldelijk aangetoond dat ze instellingen van industriële PLC’s kunnen wijzigen die rechtstreeks via internet toegankelijk zijn.
3. Open poorten versus uitgaande tunnel: het fundamentele verschil
Architectuur met „blootgestelde inkomende poort“
[Internet] ──→ [Pare-feu usine : port ouvert] ──→ [Réseau OT] ──→ [Automate]
Dit model biedt een toegangspunt tot het internet. Of het nu gaat om een VPN-poort (UDP 1194 voor OpenVPN, UDP 500/4500 voor IPsec) of een applicatiepoort (502, 102, 443), deze poort wordt voortdurend gecontroleerd.
Levenscyclus van een kwetsbare poort:
- Openstelling van de poort → indexering door Shodan binnen 24-48 uur
- Eerste scanpogingen → enkele dagen na het blootstellen
- Geautomatiseerde exploitatiepogingen → zodra een bekende handtekening wordt geïdentificeerd
- Gerichte exploitatie → als de installatie wordt geïdentificeerd als kritiek of interessant
Architectuur „alleen uitgaande tunnel“
[Réseau OT] ──→ [Gateway : connexion sortante] ──→ [Cloud] ←── [Opérateur]
Wat er fundamenteel verandert:
- De verbinding wordt van binnenuit tot stand gebracht — net als bij een webbrowser
- Vanuit het perspectief van de fabrieksfirewall: uitgaand HTTPS-verkeer naar een bekend IP-adres
- Geen inkomende poorten die moeten worden geopend, geen firewallregels die moeten worden aangepast
- Geen blootgestelde poorten = geen aanvalsoppervlak voor het netwerk aan de kant van de fabriek
Mocht de cloudinfrastructuur van Eziwan worden gecompromitteerd (hypothetisch scenario), dan zou een aanvaller niet door kunnen dringen naar het netwerk van de fabriek — de verbinding is vanuit het oogpunt van het initiëren ervan eenrichtingsverkeer.
Waarom TeamViewer niet „net zo veilig“ is als OpenVPN
TeamViewer maakt weliswaar gebruik van een cloud-relay (er is geen directe verbinding tussen de aanvaller en de fabriek), maar de structurele problemen liggen elders:
| Probleem | Uitleg |
|---|---|
| Infrastructuur van derden | De sessies lopen via TeamViewer-servers. Als TeamViewer wordt gehackt (zoals in 2016), zijn uw sessies dat ook. |
| Traceerbaarheid afhankelijk van het abonnement | Volledige logbestanden zijn alleen beschikbaar bij premiumabonnementen. In de gratis versie zijn er geen exporteerbare logbestanden. |
| Ongeschikt authenticatiemodel | Een 9-cijferige code die via e-mail wordt uitgewisseld, is geen sterke authenticatie. |
| Geen OT-isolatie | TeamViewer geeft toegang tot de Windows-computer waarop het programma draait — en vanaf die computer mogelijk tot het gehele OT-netwerk. |
4. Wat IEC 62443 en ANSSI zeggen
IEC 62443 — de referentienorm
De norm IEC 62443 beschrijft de cyberbeveiligingseisen voor industriële systemen. Voor toegang op afstand stelt Security Level 2 (SL2) — het aanbevolen niveau voor de meeste industriële installaties — de volgende eisen:
SR 1.1 — Identificatie en authenticatie van gebruikers: Elke gebruiker die toegang krijgt tot het systeem moet individueel worden geïdentificeerd en geauthenticeerd. Gedeelde accounts (één enkel „onderhoudsaccount” voor het hele team) zijn uitdrukkelijk uitgesloten.
SR 1.7 — Versterkte authenticatie (Enhancement SL2): Voor toegang op afstand op SL2-niveau is tweefactorauthenticatie (MFA) vereist. Een wachtwoord alleen is niet voldoende.
SR 2.6 — Toegang via onbetrouwbare netwerken: Elke toegang vanaf het internet tot het OT-netwerk moet worden versleuteld, geauthenticeerd en geregistreerd. Deze eis is de normatieve vertaling van de uitgaande tunnel + MFA + auditlogs.
SR 6.2 — Continue monitoring: Toegang op afstand moet continu worden geregistreerd — wie er inlogde, wanneer, vanaf welk adres en hoe lang.
Aanbevelingen van ANSSI
De ANSSI publiceert specifieke richtlijnen voor industriële systemen. Haar vijf principes voor industriële toegang op afstand:
- Segmentatie: externe toegangen mogen niet rechtstreeks via het OT-netwerk lopen — ze moeten via een industriële DMZ verlopen
- Sterke authenticatie: MFA is verplicht voor elke externe toegang tot apparatuur van niveau 1 of 2
- Versleuteling: alle communicatie op afstand moet worden versleuteld met recente algoritmen
- Logboekregistratie: volledige, exporteerbare logboeken met tijdstempels, die minimaal 3 maanden worden bewaard
- Minimale rechten: elke technicus heeft alleen toegang tot de apparatuur binnen zijn bevoegdheidsgebied
Het ANSSI publiceert deze aanbevelingen in zijn gids „Beheersing van digitale risico’s in verband met industriële systemen”, die gratis kan worden gedownload op ssi.gouv.fr. Het wordt aanbevolen dat elke verantwoordelijke voor industrieel onderhoud deze gids doorleest.
5. OpenVPN versus IPSec versus L2TP in een industriële context
Niet alle VPN’s zijn even geschikt voor ingebouwde gateways op ARM-CPU’s met beperkingen op het gebied van herverbinding en geheugen.
Gedetailleerde vergelijkende analyse
| Criterium | OpenVPN | IPSec (IKEv2) | L2TP / PPTP |
|---|---|---|---|
| Transport | UDP of TCP 443 | UDP 500/4500 (ESP/IKE) | UDP 1701 / TCP 1723 |
| Firewall-/NAT-doorvoer | Uitstekend (TCP 443 komt overal door) | Gemiddeld (NAT-T vereist) | Variabel |
| Herstel van verbinding na 4G-onderbreking | Snel (persist-tun, ~2-5 s) | Uitstekend (MOBIKE, vrijwel transparant) | Traag (15-60 s) |
| Cryptografische primitieven | TLS, AES-256-GCM | AES-256, SHA-2 (IKEv2) | Zwak (PPTP/MS-CHAPv2 afgeraden) |
| Authenticatie | X.509-certificaat per client | PSK of X.509-certificaten | Gebruikersnaam / wachtwoord |
| CPU-belasting (ARM Cortex-A) | Matig | Laag (hardwareversnelling mogelijk) | Laag |
| Rijpheid / certificeringen | Uitgebreid getest, wijdverbreid | FIPS 140-2-gecertificeerd | Verouderd (PPTP te vermijden) |
OpenVPN: de standaardkeuze van Eziwan voor ingebouwde gateways
Het belangrijkste punt voor de industriële gebruiker: het passeren van firewalls en het opnieuw verbinden na een 4G-onderbreking. OpenVPN kapselt de tunnel in TLS op TCP-poort 443 — dezelfde als die voor HTTPS — waardoor deze door kan dringen waar andere protocollen worden geblokkeerd (firewall van de provider, bedrijfsproxy). In combinatie met persist-tun wordt de tunnel binnen enkele seconden hersteld na een Dual SIM-overschakeling, zonder dat er een volledige heronderhandeling nodig is.
Elke technicus beschikt over een eigen X.509-certificaat, dat afzonderlijk kan worden ingetrokken via het clouddashboard — een belangrijke vereiste voor de traceerbaarheid volgens NIS2.
IPSec (IKEv2) voor omgevingen waarvoor dit vereist is
IPSec blijft de standaard in bedrijfsomgevingen en in gereguleerde industriële omgevingen waar FIPS 140-2-gecertificeerde protocollen vereist zijn. Het MOBIKE-mechanisme zorgt voor een vrijwel transparante afhandeling van IP-adreswisselingen — wat bijzonder geschikt is voor Dual SIM-failover. De configuratie is complexer (PKI, X.509-certificaten, SA-beleidsregels), maar de interoperabiliteit met bestaande netwerkapparatuur is maximaal. De Eziwan Gateway ondersteunt ook L2TP, PPTP en GRE voor gevallen waarin compatibiliteit met oudere systemen vereist is.
6. Hoe Eziwan het ‘zero-port-exposed’-principe implementeert
De Eziwan-architectuur past de bovengenoemde principes systematisch toe:
Verbindingsarchitectuur
- De gateway in de fabriek initieert de OpenVPN-verbinding met de Eziwan-cloudinfrastructuur via UDP 1194
- De verbinding wordt geauthenticeerd door middel van X.509-certificaten die tijdens de provisioning zijn gegenereerd
- Er is geen enkele inkomende poort geopend op het fabrieksnetwerk
- De toegang voor operators verloopt via de Eziwan-cloud, met geïntegreerde MFA (TOTP of pushmelding)
- Elke sessie wordt gelogd: gebruiker, tijdstempel, duur, uitgevoerde acties
Migratieproces vanuit TeamViewer
Als u TeamViewer momenteel gebruikt op industriële bewakingsstations, volgt hier een stapsgewijze migratieprocedure:
Fase 1 — Parallelle implementatie (week 1-4):
- De Eziwan-gateways installeren op 5 tot 10 proeflocaties
- TeamViewer tijdens de testfase parallel actief laten blijven
- De teams opleiden in het gebruik van de Eziwan VPN-client en het dashboard
Fase 2 — Geleidelijke overgang (week 5-8):
- TeamViewer op de proeflocaties uitschakelen na validatie
- Uitrollen naar de overige locaties in groepen van 10-20 locaties
- Controleren of de Eziwan-auditlogboeken voldoen aan de behoeften van de teams
Fase 3 — Verwijdering en opschoning (week 9+):
- TeamViewer van alle beheercomputers verwijderen
- De TeamViewer-licenties intrekken
- Indien nodig de oude TeamViewer-logbestanden archiveren om aan de nalevingsvereisten te voldoen
Checklist voor validatie na implementatie
Controleer na de implementatie van Eziwan de volgende punten:
- Geen enkele inkomende TCP/UDP-poort geopend op de firewall van de fabriek (scan vanaf het internet)
- MFA ingeschakeld voor alle accounts voor toegang op afstand
- Op naam gestelde accounts aangemaakt voor elke technicus (geen gedeelde accounts)
- Toegangsrechten per gebied gecontroleerd (technicus X ziet alleen zijn eigen locaties)
- SMS-/e-mailwaarschuwing getest om het meldingskanaal te valideren
- Export van auditlogboeken getest (voor toekomstige audit)
- Procedure voor het intrekken van toegangsrechten gedocumenteerd en getest
Definitieve vergelijkingstabel
| Criterium | TeamViewer / AnyDesk | Klassieke VPN (site-to-site) | Eziwan |
|---|---|---|---|
| Openstaande inkomende poorten | Nee (cloudrelay van derden) | Ja | Nee |
| Traceerbaarheid van sessies | Gedeeltelijk (abonnement) | Afhankelijk van de apparatuur | Volledig + export |
| Naleving van IEC 62443 SL2 | ✗ | Gedeeltelijk | ✓ |
| Conformiteit met ANSSI-aanbevelingen | ✗ | Gedeeltelijk | ✓ |
| Geïntegreerde MFA-authenticatie | Optioneel | Optioneel | Geïntegreerd |
| Netwerkinterventie ter plaatse | Nee | Ja | Nee |
| Volledige OT-isolatie | ✗ | Gedeeltelijk | ✓ |
| Exporteerbare auditlogs | Premium-abonnement | Afhankelijk van de apparatuur | Standaard |
| Herverbinding na 4G-onderbreking | 30–60 s | 5–30 s | < 2 s (OpenVPN) |
| Implementatie zonder netwerkkennis | Ja | Nee | Ja (ZTP) |
Voor een concrete implementatie op een Siemens S7-PLC, zie Hoe sluit je een S7 op afstand aan zonder een poort te openen. Voor gedetailleerde informatie over de IEC 62443-vereisten, zie IEC 62443 en industriële toegang op afstand.
Veelgestelde vragen — Industriële VPN versus TeamViewer
Is TeamViewer niet voldoende als men alleen toegang heeft tot een bewakingsstation en niet rechtstreeks tot de PLC?
Niet per se. De supervisiepost heeft doorgaans toegang tot het niveau 1-netwerk (PLC's) via de SCADA-software. Als de supervisiepost wordt gehackt – of dat nu via TeamViewer is of via een ander beveiligingslek – geeft dat indirect toegang tot de PLC's. OT-isolatie moet worden bekeken vanuit het perspectief van het netwerk, niet vanuit dat van de applicatie.
Is WireGuard een haalbaar alternatief voor OpenVPN voor industriële gateways?
WireGuard biedt betere prestaties en een kleinere (beter gecontroleerde) codebase, maar heeft één beperking: het werkt uitsluitend via UDP, zonder TCP-optie. In netwerken waar UDP wordt gefilterd (bij sommige mobiele providers, bedrijfsproxys), kan WireGuard falen terwijl OpenVPN via TCP 443 wel zou werken. Voor industriële 4G-gateways met mogelijk onbetrouwbare verbindingen blijft OpenVPN de meest universele keuze.
Is het mogelijk om een bestaande IPsec-VPN-oplossing van het bedrijf te gebruiken in plaats van Eziwan?
Ja, mits de bestaande oplossing voldoet aan de criteria van IEC 62443 SL2 (op naam gestelde accounts, MFA, exporteerbare logbestanden, principe van minimale rechten). Het terugkerende probleem bij site-to-site VPN’s van bedrijven die worden toegepast in de OT, is het gebrek aan granulariteit: de VPN geeft toegang tot een heel netwerksegment in plaats van tot een specifiek apparaat. Eziwan kan een bedrijfs-VPN-oplossing aanvullen door granulariteit en auditlogboeken toe te voegen.
Heeft de ANSSI een lijst met goedgekeurde oplossingen voor toegang op afstand voor de OT?
De ANSSI publiceert geen lijst met „goedgekeurde” oplossingen, maar wel beoordelingscriteria. Voor OIV’s en OSE’s kunnen PRIS-gecertificeerde dienstverleners (dienstverleners voor de afhandeling van beveiligingsincidenten) een formele beoordeling uitvoeren. De ANSSI-criteria komen overeen met de IEC 62443 SL2-eisen die in dit artikel worden beschreven.
Hoe lang duurt het om over te stappen van TeamViewer naar een industriële VPN-oplossing?
Bij een netwerk van minder dan 20 locaties kan de migratie binnen 2 tot 4 weken worden voltooid: parallelle implementatie, training van de teams, geleidelijke omschakeling. Het belangrijkste punt is de training van de technici in het gebruik van de VPN-client — reken op 1 tot 2 uur per persoon. Het proces wordt gedetailleerd beschreven in paragraaf 6 van dit artikel.
Gebruikt uw organisatie momenteel TeamViewer of een traditionele VPN-verbinding op een OT-netwerk?
Download het whitepaper over OT-cyberbeveiliging →
Het document beschrijft de aanbevolen doelarchitectuur, de migratieprocedure vanuit een bestaande omgeving en de beoordelingscriteria voor een oplossing die voldoet aan IEC 62443.
