Kennisbank · Techniek
Gedeelde beheeraccounts op routers afschaffen: zo pakt u het aan
Gedeelde beheeraccounts zijn makkelijk, tot u moet uitzoeken wie wat heeft gewijzigd. De Regeling cyberbeveiliging EZK vraagt daarom om geïndividualiseerde voorrechten. In dit artikel leest u hoe u de overstap maakt zonder uzelf buiten te sluiten.
Wat staat er precies?
Artikel 6, tweede lid, van de regeling zegt dat voorrechten voor systeembeheer "zoveel mogelijk geïndividualiseerd en beperkt" worden toegekend. De toelichting geeft de reden: zo is misbruik beter te herleiden tot een bepaald account. Dezelfde bepaling vraagt sterke authenticatie en zegt dat beheerrechten alleen voor beheer worden gebruikt.
"Zoveel mogelijk" is geen vrijbrief. Het betekent dat een uitzondering kan, als u kunt uitleggen waarom het niet anders gaat. Dat een gedeeld account handig is, is daarvoor geen goede reden. Ook artikel 15 van het Cbb helpt: u controleert identiteiten en rechten periodiek op noodzaak en juistheid. Bij een gedeeld account weet u niet eens wie er gebruik van maakt.
Deze regeling geldt voor aanbieders van openbare telecomnetwerken en -diensten en internetknooppunten. Voor MSP's en hosters geldt Uitvoeringsverordening (EU) 2024/2690. De algemene basis voor beheertoegang staat in MFA en beheertoegang. Hier gaat het om de overstap zelf.
Stap 1: tel wat er echt op de apparatuur staat
Haal per apparaat de lokale gebruikers op. Trek dit uit de configuraties, niet uit uw geheugen. Noteer ook:
- accounts die in scripts, monitoring en back-upsystemen zitten;
- accounts die oud-collega's of leveranciers kennen;
- gedeelde geheimen zoals SNMP-community's en RADIUS-sleutels. Dat zijn geen accounts, maar ze hebben hetzelfde probleem.
Stap 2: kies centrale authenticatie
Met een centrale server beheert u accounts op één plek. Vertrekt iemand, dan zet u één account uit. RADIUS en TACACS+ doen dat allebei, met verschillen:
| Punt | RADIUS (RFC 2865) | TACACS+ (RFC 8907) |
|---|---|---|
| Rechten per opdracht | Meestal grof, via een rol | Kan per opdracht worden toegestaan of geweigerd |
| Logging van opdrachten | Afhankelijk van de apparatuur | Accounting per opdracht is gebruikelijk |
| Bescherming onderweg | Alleen het wachtwoordveld is verborgen | Verhulling van het pakket; RFC 8907 noemt dit bewust geen versleuteling |
Omdat beide protocollen zelf beperkte bescherming bieden, loopt dit verkeer het best alleen over uw beheernetwerk. RFC 9887 beschrijft TACACS+ over TLS 1.3. Gebruik dat als uw apparatuur het ondersteunt. Welk protocol u kiest, is uw eigen keuze. De regels noemen geen van beide. Kijk vooral wat al uw merken goed ondersteunen.
Koppel de server aan uw bestaande gebruikersbeheer als dat kan, met een tweede factor. Draai bij voorkeur twee servers op verschillende locaties.
Stap 3: regel het noodaccount
Als de centrale server onbereikbaar is, moet u er nog steeds in kunnen. De regels verbieden een noodaccount niet. Het is dan wel de uitzondering die u moet kunnen uitleggen. Zo beperkt u het risico:
- Eén lokaal account per apparaat, met een eigen lang wachtwoord per apparaat of per groep.
- Het wachtwoord staat in een kluis en wordt daaruit opgevraagd, met een logregel.
- Elk gebruik geeft een alarm en krijgt een korte notitie: wie, wanneer, waarom.
- Na gebruik wijzigt u het wachtwoord.
Test per merk wanneer het apparaat terugvalt op lokale login. Op sommige apparatuur werkt dat alleen als de server niet reageert, op andere ook bij een geweigerde login. Dat laatste wilt u niet.
Stap 4: wissel over zonder uitsluiting
- Begin op een apparaat dat niet kritiek is, of in uw lab.
- Zorg voor een tweede toegang, zoals een console, en plan het als onderhoud. Dat werkt net als bij patchen met een weg terug.
- Houd een sessie open terwijl u test met een tweede sessie.
- Gebruik een automatische terugdraaifunctie als uw apparatuur die heeft.
- Rol uit per groep, en verwijder het gedeelde account als laatste.
Geef scripts en monitoring een eigen serviceaccount met minimale rechten. Een back-upscript hoeft configuraties alleen te lezen. Sla het geheim op in een kluis, niet in de code.
Oude apparatuur en externe partijen
Ondersteunt een apparaat geen centrale login, maak dan aparte lokale accounts als dat kan. Kan ook dat niet, laat het apparaat alleen bereikbaar zijn via een jumphost met persoonlijke login en sessielog. Schrijf op waarom dit zo is en wanneer het vervangen wordt.
Werkt een externe partij op uw netwerk? Geef dan elke technicus een eigen account, niet één account voor het bedrijf. Maak toegang tijdelijk waar dat kan en neem dit op in uw contract.
Wilt u weten waar u verder nog staat? Doe de gratis zelfscan. In het portaal kunt u 30 dagen gratis uw maatregelen en bewijs bijhouden, zonder betaalgegevens.
Veelgestelde vragen
Moet dit ook met maar drie beheerders?
De regeling kent geen ondergrens. Een klein team kan het eenvoudig houden, maar drie mensen kunnen ook drie accounts hebben. Zelfs lokale persoonlijke accounts zijn al beter dan één gedeeld account.
Is een SNMP-community ook een gedeeld account?
Formeel niet, maar het is wel een gedeeld geheim. SNMPv3 werkt met gebruikers. Kunt u nog niet overstappen, beperk de toegang dan tot uw monitoringserver en geef alleen leesrechten.
Hoe vaak wijzig ik het wachtwoord van het noodaccount?
De regels noemen geen frequentie. Een logische afspraak is: na elk gebruik en als iemand met toegang tot de kluis vertrekt.
Bronnen
- Regeling cyberbeveiliging EZK, Stcrt. 2026, 25627
- Cyberbeveiligingsbesluit, Stb. 2026, 189
- RFC 8907, TACACS+
- RFC 9887, TACACS+ over TLS 1.3
- RFC 2865, RADIUS
Geraadpleegd op 5 november 2026. Deze site, de kennisbank en de zelfscan geven algemene informatie en zijn geen juridisch advies. Stand van de wetgeving: november 2026.
Weet in 15 minuten waar u staat
Doe de gratis zelfscan voor telecom-, VoIP- en internetaanbieders. U krijgt direct een rapport met actiepunten. Daarna kunt u 30 dagen gratis verder in het portaal.