Epe kon worden gehackt doordat een noodtoegangsaccount slecht was beveiligd

Het datalek bij de Nederlandse gemeente Epe eerder dit jaar kon plaatsvinden nadat aanvallers een noodtoegangsaccount konden misbruiken. Ze wisten een beheerderswachtwoord te kraken, schrijft de gemeente in een evaluatierapport. Bij de hack werden de bsn's van alle inwoners gestolen.

De gemeente Epe heeft een evaluatie online gezet van het datalek dat in april dit jaar plaatsvond. Na de hack kwamen de namen, adressen, geboortedata en burgerservicenummers van alle inwoners van de gemeente op straat te liggen. De gemeente verving daarop duizend ID-bewijzen zonder kosten.

Er waren al wel wat details over de hack bekend, maar met de huidige evaluatie wordt nog duidelijker hoe de criminelen de ruim 525.000 documenten wisten te stelen. Zo was al duidelijk dat de criminelen binnenkwamen door een werknemer om de tuin te leiden, die malware te laten downloaden en diens multifactorauthenticatiegegevens te onderscheppen.

Nu is ook duidelijk dat de criminelen vervolgens hogere gebruikersrechten op het systeem kregen 'doordat een beheerderswachtwoord kon worden gekraakt'. De gemeente schrijft ook: "Een break-glass-account, bedoeld als noodtoegang, had onvoldoende aanvullende beveiligingsmaatregelen, waardoor de aanvaller hiermee vergaande rechten kon verkrijgen." Daarover geeft de gemeente ook geen details, maar onder andere Microsoft noemt Globale Beheerder-accounts zo in Entra ID.

Ook opvallend in de evaluatie is dat de gemeente schrijft hoeveel het datalek de gemeente kostte. Die informatie wordt zelden genoemd bij hacks, maar Epe is daar open over: het datalek kostte bijna 350.000 euro. Het technisch onderzoek kostte bijvoorbeeld 120.896 euro, zegt de gemeente. Het inhuren van het incidentresponsbedrijf en 'externe projectleiding' kostte 79.815 euro. Ook de inzet van communicatiewerknemers kostte geld, net als het afhandelen van AVG- en Woo-verzoeken. De gemeente schrijft daarnaast wat het verzenden van alle brieven en het vervangen van alle identiteitsbewijzen kostte.

Reacties (94)

[Triblade_8472]

Het verbaasd mij dan ook eigenlijk dat een giga bedrijf als MS geen intern lock/unlock systeem heeft voor break-the-glass accounts bij hun enterprise klanten.

Bijvoorbeeld dat je een bepaald MFA-loos account kan aanmaken als een BtG waarna je een code krijgt die je offline moet bewaren. Je daarna naar MS moet bellen die je naar de code vragen om dit account te kunnen ontgrendelen.

Het zijn de extra lagen die ertoe doen.

En als mijn idee niet goed is, dan zullen er vast tonnen goede ideeën zijn.

[The Realone]

Microsoft biedt gewoon 'break-the-glass' accounts die je prima kunt beveiligen waardoor dit nagenoeg onmogelijk was geweest. Een aantal best-practices toepassen zoals zeer lange wachtwoorden (50+ chars voor mijn part), FIDO2 keys koppelen en alerting instellingen op pogingen tot inloggen op dat soort accounts. Vervolgens leg je die wachtwoorden en hardware keys in een kluis en haal je die er alleen maar uit om te testen.

Veel veiliger kun je het haast niet maken.

[Triblade_8472]

Voor mij is een break-the-glass account alleen een BtG wanneer het geen toeters en bellen heeft, zoals FIDO2. Juist daarom lijkt mij een in-system oplossing vanuit MS zo handig.

Alerting enzo lijken mij inderdaad ook een uiterst belangrijke toevoeging.

[The Realone]

Een FIDO2 key zou niet onder "toeters of bellen" moeten vallen. Zolang je dat instelt, er vanaf blijft en consistent test, is dat een vele malen veiligere oplossing. Daar voorkom je in ieder geval mee dat ie wachtwoord brute-forced wordt. Al zou dat eigenlijk al onmogelijk moeten zijn als deze lang genoeg is.

[supersnathan94]

Het probleem met zo’n fysieke key is alleen vaak dat je er geen toegang tot hebt als het echt nodig is. Zoals midden in de nacht of in het weekend.

De systemen waarin ik een dergelijk account had was het vaak nog steeds gekoppeld aan MFA van mijn eigen account plus in sommige gevallen nog een externe 4-eyes goedkeuring. Als ik dan met een manager aan de lijn zat vanwege een incident kon hij met zijn MFA weer goedkeuren.

[Allard]

Maar zo'n BtG account is toch niet bedoeld voor "gewone" emergencies? Daar kun je prima goedbeveiligde beheeraccounts voor gebruiken. Alleen als er serieus iets mis is, of als er een heel structurele wijziging moet worden gedaan zou je zo'n account nodig kunnen hebben, en dan is er vast wel iemand die naar het kantoor kan rijden om die fido2 sleutel uit een kluis te halen.

[supersnathan94]

Maar zo'n BtG account is toch niet bedoeld voor "gewone" emergencies?

Nee klopt.

en dan is er vast wel iemand die naar het kantoor kan rijden om die fido2 sleutel uit een kluis te halen.

Nee want daar heb je veel meer kosten en tijd voor nodig. Als op zaterdagmiddag het betaalverkeer van NL plat ligt, heb je echt 0 tijd om naar kantoor te rijden en daar met het beveiligingsbedrijf af te spreken. In een 4-nines SLA mag je er per jaar 52 minuten uit liggen. “Even” naar kantoor rijden kan dan echt heel snel heel duur worden.

Daar kun je prima goedbeveiligde beheeraccounts voor gebruiken.

Nee want als dat een “shared” account is, is dat niet te auditen. In een RBAC achtige setup wil je toch wel gewoon een role assumen van een beheerder, maar in emergencies is er BtG nodig om ook bij productiedata te kunnen.

[Heroic_Nonsense]

Als je een 4-nines SLA hebt, heb je waakdiensten.

Bij ons zitten die waakdienstmedewerkers op een locatie waar ook één van de kluizen is. In die kluis (eigenlijk meerdere kluisjes) liggen de credentials van de BG-accounts voor de systemen die dat ondersteunen. Die medewerkers hebben ook de beleidsmatige bevoegdheid om in die applicaties in te loggen met dat BG-account.

In geval van nood kunnen zij dus credetnials van andere admins, die niet op locatie zijn bijvoorbeeld, resetten om ze weer toegang te geven.

Maar goed, ik werk ook bij een organisatie waarbij de IT-afdeling alleen al 1000+ FTE is. Ik snap dat dit voor kleinere bedrijven wat lastiger in te schalen is.

[supersnathan94]

In geval van nood kunnen zij dus credetnials van andere admins, die niet op locatie zijn bijvoorbeeld, resetten om ze weer toegang te geven.

Klinkt als een normale beheertaak. Althans voor IT services binnen AD achtige constructie. Niet voor “custom software DevOps team”. Ik denk dat daar de spraakverwarring zit. BtG zal in verschillende domeinen een verschillende betekenis hebben.

Bij mijn klanten vereist de BtG geen inmenging van de AD beheerders. Dit is “gewoon” een assumable role in AWS.

[Heroic_Nonsense]

Nee, de term is hetzelfde. Ik zit zelf ook in een devops teams, zonder waakdienst.

Maar wij kunnen dus een beroep doen op de waakdienst (mensen van één van de teams met een 24/7 rooster in de organisatie) doen, die vervolgens middels het BG-account jouw account weer toegang kunnen geven, of de credentials van het BG-account aan je overdragen (op een veilige, phising-resistant manier uiteraard) zodat je zelf met het BG-account kunt inloggen.

[supersnathan94]

Oke. Bij mijn klanten is het meestal gewoon iemand van het team die de rol kan Assumen (via een vault) met 4-eye van (meestal) een manager of ander bevoegd cq verantwoordelijk persoon. Die rol wordt niet nog weer door een derde uitgeven maar gewoon door het systeem. Wel standby diensten, weinig noodzaak om dat 24/7 te doen op locatie. Zolang je op een belletje reageert, wat is dan het punt om het niet remote te kunnen? Fysiek op locatie en ook nog eens met een kluis? Kost veel te veel.

Den waakdienst is daarmee alleen een standby en dus bijbehorende vergoeding en verlof (piketregeling conform CAO) en daardoor veel goedkoper om te implementeren dan iemand 24/7 in het pand. Nergens voor nodig als je eens in de drie maanden mogelijk een aanspraak zou moeten maken op zo’n rol en je verder gewoon binnen kantoortijden oplossingen kunt bedenken.

Ik heb zelf tijdens corona heel wat nachtdiensten gedraaid (onderhoud buiten kantooruren) en ben maar wat blij dat ik dan niet ook nog 3 uur reistijd had.

[Eusie007]

Ik lees in veel reacties dat bepaalde maatregelen niet worden uitgevoerd omdat ze geld kosten. Dat vind ik opmerkelijk. Je wilt je omgeving toch goed beveiligen en voorkomen dat gevoelige data op straat komt te liggen. In mijn ogen mag dat best wat kosten, zeker gezien de problemen en schade die datalekken en cyberincidenten tegenwoordig kunnen veroorzaken. Kijk bijvoorbeeld naar de ellende die organisaties zoals Odido hebben ervaren. Preventie is uiteindelijk vaak goedkoper dan de gevolgen van een incident.

[supersnathan94]

Je wilt je omgeving toch goed beveiligen en voorkomen dat gevoelige data op straat komt te liggen.

Ja dat klopt. Maar creds in een kluis leggen voorkomt alleen dat iemand er makkelijk bij kan komen, maar het fysieke aspect van security moet je dan óók goed op orde hebben.

Zoals ik eerder ook al aangaf, zodra die credential de kluis verlaat, wie let er dan op? Je hebt dan ineens een niet eenvoudig auditeerbaar proces lopen.

Daarnaast kost het ook veel tijd, als je een bepaalde SLA handhaaft, heb je die extra tijd gewoon niet zomaar. Daarom zijn er ook andere manieren om dit digitaal wel goed te regelen met bijvoorbeeld 4-eye principe vanuit bevoegde manager.

Kijk bijvoorbeeld naar de ellende die organisaties zoals Odido hebben ervaren

Dat is in het begin al compleet fout gegaan en ik denk niet dat een proces zoals dit, dit beter had gemaakt.

[Keypunchie]

Maar bij zoveel nines, heb je geen "break the glass" beheerdersaccount nodig. Je moet dan gewoon voldoende beheerders hebben, zodat je 24/7 bezetting hebt.

BtG is er voor de echte noodgevallen: beheerders zijn samen in een vliegtuig gestapt en dat is neergestort. Het idee is dan ook dat je echt iets ingrijpends/opvallends moet doen (equivalent van een ruitje intikken), waarmee je toegang kan verkrijgen om een noodhandeling uit te voeren.

Maar dan moeten wel alle alarmen afgaan.

Hier lijkt het op dat de gemeente gewoon een "achterdeurtje" had, een makkelijk ingangetje voor beheerders... Tsja.

[supersnathan94]

equivalent van een ruitje intikken

Misschien hebben we het dan over andere dingen. Ik ken Break the glass als “in case of fire, break the glass and pull alarm” and the GTFO.

https://www.idsalliance.org/blog/break-glass-accounts-risk-or-required/

Het schip staat in de fik en de boel moet geblust worden.

Je moet dan gewoon voldoende beheerders hebben, zodat je 24/7 bezetting hebt.

Ben ik het niet per se mee oneens?

Maar die beheerders moeten ook een privilege escalatie pad hebben waar alarmbellen op afgaan.

Dat is bij ons (in een DevOps situatie) vrijwel altijd gewoon iemand van het team.

Maar dan moeten wel alle alarmen afgaan.

Eens. Dat ging bij ons rechtstreeks door naar Ciso en hoofd security.

Maar bij zoveel nines, heb je geen "break the glass" beheerdersaccount nodig.

Daar ben ik het mee oneens. Je moet bij 4 sigma voldoende beheerders hebben, maar ook die moet dus soms wel degelijk iets kunnen doen wat niet de bedoeling is en dus ook absoluut niet kan met hun standaard privs. Dat is een rol privilege wat auditeerbaar is. Dat kan dus nooit een gedeeld account zijn waarvan een key in een kluis ligt en een groepje mensen die toegang heeft tot die kluis.

Ja het is best practise om dat óók te doen, maar het is geen vereist noch de enige horde. Het ligt eraan hoe hard je BtG procedure is en hoe je waakdiensten ingedeeld zijn. Bij veel projecten in NL (met ook echt wel maatschappelijk belang dat shit snel gefixed wordt) is dat “gewoon” een standby dienst met een telefoon naast je bed en een laptop paraat. Meer niet.

Als een waakdienst vereist dat je op kantoor bent, dan vind ik dat een slechte waakdienst. Tenzij er aantoonbaar issues mee zijn geweest (dus incidenten waarbij er na herhaaldelijke pogingen geen antwoord kwam omdat iemand lag te slapen, toch wel op vakantie was, of gewoon laveloos in de kroeg … lag. Bijvoorbeeld).

Anyways. Voor PCI-DSS zijn er best wel wat regeltjes die je moet volgen om compliant te kunnen zijn. Simpelweg een niet persoonsgebonden account gebruiken is bijna niet compliant te krijgen zonder zeer stricte fysieke audit. Je moet dan dis de kluis altijd in observatie hebben, maar ook de set aan credentials en eventueel een key, daarna fysiek kunnen volgen, want zonder dat, weet je eigenlijk nooit of de credentials niet nog een keer zijn gebruikt. En one time use afdwingen en daarna direct een nieuwe vereisen kan ook niet zomaar, want als een inlogpoging mislukt of niet goed gaat, wat dan?

Binnen PCI DSS zijn er andere eisen en best practises. Practises die ik op zich wel achter kan staan. Het is 2026. Fysieke toegang tot iets vereisen als last resort is echt ouderwets in dat opzicht.

https://hoop.dev/blog/understanding-break-glass-access-in-pci-dss

https://www.idsalliance.org/blog/break-glass-accounts-risk-or-required/

Hier lijkt het op dat de gemeente gewoon een "achterdeurtje" had, een makkelijk ingangetje voor beheerders... Tsja.

Tsja. Eens? Zo klinkt het iig wel.

[Heroic_Nonsense]

Een break-glass-account is een account dat niet onderhevig is aan conditional access-achtige constructies.

Dus stel dat er iets gebeurt in de policies waardoor alle admins niet meer kunnen inloggen, dan is het bg-account uitgezonderd en kun je daarmee je actie terugdraaien.

Of stel dat de hele MFA-keten eruit ligt (bijvoorbeeld je authenticatorplatform heeft een storing), dan heeft het bg-account daar geen last van.

Je kunt natuurlijk je admins ook uitsluiten van dat soort policies, maar dat is niet zo'n goed idee.

[Keypunchie]

Een break-glass-account is een account dat niet onderhevig is aan conditional access-achtige constructies.

Klinkt nogal als de Microsoft-definitie ervan :-)

Ik ken het vooral iets functionelere "wat als we onszelf hebben buitengesloten en we *moeten* nu toegang".

De analogie komt voor zover ik weet ik van de "brandbijl" die vaak achter een glazen deurtje zat (later werden dat gewoon noodknoppen, die het brandalarm lieten afgaan, maar dan vaak ook alle deuren ontgrendelden, of er zit vaak ook wel zo'n glashamertje in tegenwoordig).

De digitale equivalent betekent: toegang, maar het *moet* enige moeite kosten, met als belangrijkste voowaarde: het kan niet stilletjes/ongemerkt.

(en nogmaals: dit mag dus gepresenteerd worden als een "btg" account, maar het klinkt gewoon als een onbeveiligd super-admin acccount)

[Reactie gewijzigd door Keypunchie op 6 juni 2026 18:17]

[supersnathan94]

Klinkt nogal als de Microsoft-definitie ervan :-)

Eens 😅

Ik ken het vooral iets functionelere "wat als we onszelf hebben buitengesloten en we moeten nu toegang".

Buiten het “we hebben ons buitengesloten”, wat klinkt als “that’s a skill issue”, hebben wij het vaak ook als er productie data rechtgebreid moet worden of daadwerkelijk gekeken moet worden wat nu een failscenario maakt met Productiedata. Op het moment dat de data echt noodzakelijkerwijs aangeraakt moet worden of er moet een ander dingetje gedaan worden met wat gewoon niet mag met een normaal beheer account, dan heb je de BtG. Het is niet eens zozeer dat er creds gerest moeten worden, het is gewoon de standaard voor een, “hee hier moet achteraf 100 duizond procent wat mee gedaan worden om het correct vast te leggen.”

[david-v]

Bij een 4-nines SLA heb je toch ploegendiensten die 24/7 draaien? Hoe ga je anders een dergelijke SLA halen?

[supersnathan94]

Nee hoor. Gewoon stand-by diensten. Als er eens “een keer” iets omvalt eens in de zoveel maanden dan wordt die persoon buiten kantooruren gebeld.

maar in overheids wezen is een 4 sigma binnen kantooruren ook niet ongebruikelijk. Dat is dan namelijk een 9-5 SLA waar je de klok ook gewoon stopt om 5 uur. Hoe stom dat ook klinkt.

[GertMenkel]

Met een gewone Yubikey of soortgelijke oplossing kun je een letterlijke break-the-glass-oplossing maken. Inclusief alarm als je wil.

Je moet natuurlijk geen passkey aan een Microsoft account koppelen of aan een fysieke laptop-TPM hangen, maar een setje fysieke sleutels die het in elke laptop doen, zijn volgens mij de beste manier om zoiets te doen.

Een lang wachtwoord kan ook, maar in een panieksituatie vijftig karakters can een papiertje moeten overtypen is niet heel bevorderlijk voor de geestelijke gesteldheid van degene die het systeem moet herstellen.

[Triblade_8472]

Is een Yubikey niet gewoon het automatisch typen van een heel lang wachtwoord? Zo ja, dan maakt dat het niet veiliger dan een lang wachtwoord, alleen makkelijker.

Een Yubikey is MFA. Maar wat nou als dat MFA-systeem kapot gaat? Daar is juist een break-the-glass account voor...

[Reactie gewijzigd door Triblade_8472 op 5 juni 2026 22:40]

[GertMenkel]

Yubikey is niet per definitie MFA. Het is gewoon een sleutel (waarvan de implementatie doorgaans via WebAuthn gaat). Dat kan je eerste en enige authenticatiemethode zijn. Bij passkeys is dat vaak al de norm.

Het was een paar jaar terug wel zo dat veel websites ze alleen maar als tweede factor toevoegden, maar Microsoft, Google, en vele andere diensten laten je tegenwoordig met alleen een passkey inloggen zonder ooit een wachtwoord in te typen.

[Reactie gewijzigd door GertMenkel op 6 juni 2026 01:47]

[supersnathan94]

Maar wat nou als dat MFA-systeem kapot gaat?

Dan wacht je even?

Wat moet er zo dringend zijn dat stuk is, dat niet kan wachten op Microsoft?

Als die MFA stuk is, dan is de kans groot dat gewoon helemaal niemand iets kan. Ook je gebruikers niet.

[fRiEtJeSaTe]

Microsoft doet hier al een tijdje vaag over. Eerst moest je de BGA excluden van alle CA policies en geen MFA gebruiken. Toen heeft men op een gegeven moment MFA verplicht gesteld voor GA’s via CA policies. Daarna was het geen probleem meer.

Er zit natuurlijk ook een tegenstrijdigheid in. Wij hebben hem met 2 Yubi key’s beveiligd en ik test af toe de werking ervan. Juist doordat ik ermee test voelt voor mij als verplichting om MFA erop te zetten. Hij wordt daarmee kwetsbaarder voor lekken dan dat hij alleen maar in de kast ligt. (klein risico maar toch)

[Reactie gewijzigd door fRiEtJeSaTe op 6 juni 2026 08:11]

[Padje]

Voor mij is een break-the-glass account alleen een BtG wanneer het geen toeters en bellen heeft, zoals FIDO2. Juist daarom lijkt mij een in-system oplossing vanuit MS zo handig.

Alerting enzo lijken mij inderdaad ook een uiterst belangrijke toevoeging.

Ik zou het beheer maar uitbesteden met dit soort gedachte over FIDO2 en overlaten aan professionals.

[Scriptkid]

Manage emergency access admin accounts - Microsoft Entra ID | Microsoft Learn

[Arfman]

BtG accounts beveilig je met een FIDO2 key die je in een kluis legt. Die FIDO2 key is alles wat je nodig hebt om in te loggen met dat account, en dat account is uitgezonderd van alle Conditional Access policies.

Uiteraard gaan er bij inloggen diverse alarmeringen af, mocht een kwaadwillende toch toegang hebben gekregen tot het account en de key.

[Qwerty-273]

Klinkt leuk voor een compacte organisatie of waar er een echt HQ is en voor de rest slechts kantoren waar niet je kritische IT teams over verspreid zitten. Maar op het moment dat je wel verspreiding van IT hebt en ook waar verplaatsingen plaatsvinden tussen regios, IT teams die van EMEA naar APAC of AMER verhuizen door reorganisaties, dan succes met het vinden van een fysieke locatie van een kluis (met bijbehorende procedures om te openen). Je wilt niet enkele uren moeten wachten omdat de technische persoon moet gaan reizen om bij een fysieke kluis te komen, of moet wachten op de persoon die de kluis kan openen.

[Arfman]

Als ik nu bij de key zou moeten treedt er ook een hele procedure in werking hoor, en ben ik ook uren verder voordat ik ingelogd ben. Dat is de prijs van security.

[supersnathan94]

Hoe kan een BtG procedure nou uren duren? Een 3 9s SLA heeft minder dan 8u speling per jaar. Wat voor SLA draaien jullie dat een Breakglass zolang mag duren? Voor een P2, sure. Maar een breakglass? Dan moet ik bij klanten normaliter binnen 5 minuten in de omgeving zitten. En ja dat is met alle procedures van dien, maar dat loopt allemaal al parallel.

post mortem zal uitwijzen of het ook allemaal terecht was.

[Heroic_Nonsense]

Dat hoeft ook niet.

Als ik de credentials in de kluis nodig heb, en niet op die locatie ben, dan is er een eenvoudige procedure om de wel aanwezige waakdienstmedewerkers de kluis te laten openen en als GA in te laten loggen. Zij kunnen dan de verdere stappen ondernemen om mijn eigen adminaccount de rechten te geven die ik nodig heb.

Die procedure is uiteraard geen telefoontje, maar wel een snelle, traceerbare en spoof-veilige procedure.

Waakdiensten kunnen bij ons op meerdere locaties werken, en op al die locaties zijn de kluisjes aanwezig.

[supersnathan94]

Als ik de credentials in de kluis nodig heb, en niet op die locatie ben, dan is er een eenvoudige procedure om de wel aanwezige waakdienstmedewerkers de kluis te laten openen en als GA in te laten loggen. Zij kunnen dan de verdere stappen ondernemen om mijn eigen adminaccount de rechten te geven die ik nodig heb.

Klinkt als veel papierwerk en veel kans op fouten. Inkt ook iets wat je vaak moet testen en iets wat ontzettend eenvoudig gewoon te automatiseren is met 4-eye principe zonder fysieke kluis.

again als er stront aan de knikker is en het is echt alle hens aan dek (P0) dan moet dit binnen 5 minuten geregeld zijn.

Ik heb voor waakdiensten de laptop klaarstaan, login voor de neus, anderhalve secondes “boot time” en maximaal 60 seconden van first call tot log in. En in die 60 seconden moet ik dan ook de triage hebben gedaan met de bellende manager of BtG nodig is (wat het meestal niet is uiteraard).

Misschien werk je niet met DevOps, maar met andere typen management, waar je nog beheer en development gescheiden hebt bijvoorbeeld, maar de klanten waar ik kom, zijn dit soort processen volledig digitaal geautomatiseerd per sub sub team en auditable. Hun directe PO is bevoegd om de BtG in te zetten en onder 4-eye wordt dit ook vastgelegd. Dit zodat niet 1 persoon de boel kan verpesten.

Enkele set creds in een kluis? Toon maar aan dat diegene die de kluis opende ook daadwerkelijk de persoon was die in productiedata heeft lopen rommelen. Als je die audit niet kunt garanderen heb je 0 poot om op te staan.

Jij hebt (als je er niet fysiek bent) mogelijk een 4eye, maar wat als je er wel bent? Is die orocedure dan ook zo stringent? Hier was dat klaarblijkelijk niet het geval. Dan kun je dus in je eentje de boel stuk hebben gemaakt en al met de noorderzon vertrokken zijn voor iemand het doorheeft.

Volgens mij heeft Tom Scott hier ooit nog een video over gemaakt. Het voorbeeld met “de 3” van Google.

Eentje gaat rogue: everyone fucked.

[AnonymousGerbil]

Klinkt leuk voor een compacte organisatie of waar er een echt HQ is en voor de rest slechts kantoren waar niet je kritische IT teams over verspreid zitten.

Zoals, om maar een willekeurig voorbeeld te noemen, een kleine gemeente als Epe?

[Heroic_Nonsense]

Wij zijn een organsiatie met 11.000+ FTE en hebben het ook op die manier ingeregeld. Die kluisjes zijn toegankelijk voor waakdienstemedewerkers die op de locatie werken waar de kluisjes fysiek zijn. Bij een verhuizing (wat ook bij ons voorkomt) wordt er een kwartiermaker aangesteld om specifiek dat proces in te richten op de nieuwe locatie, en om de procedure tijdens de verhuizing te borgen.

Nu is cybersecurity bij ons verweven met de bedrijfsvoering, dus iedereen snapt het belang wel.

[Tweekzor]

Je kan ook meerdere FIDO2 keys koppelen aan 1 Break Glass account en dan per continent/HQ een sleutel plaatsen. Je wilt BG ook weer niet te bereikbaar maken zodat elke beheerder hierbij kan. Dit moet een procedure zijn die alleen wordt uitgevoerd bij de hoogste noodgevallen.

[Scriptkid]

Hier is het hele process uitgelegd

Manage emergency access admin accounts - Microsoft Entra ID | Microsoft Learn

[Padje]

Waarom zou je geen "strong authentication" of te wel een FIDO2 key gebruiken? Bestaat al jaren en werkt prima zowel voor beheerders als je breakglass accounts.

Nee dat is lastig en duur hoor ik vaak van klanten. Gelukkig door dit soort hacks toont wel aan dat FIDO2 maar een kleine investering is van enkele tientjes die snel terug verdient is tov van de schade 350k.

[Triblade_8472]

Omdat het kapot kan. Een break-the-glass is voor mij een account waarmee je in kan loggen met basis gegevens (usrname/passwd) wanneer al het andere (MFA/FIDO) kapot is.

[Padje]

Omdat het kapot kan. Een break-the-glass is voor mij een account waarmee je in kan loggen met basis gegevens (usrname/passwd) wanneer al het andere (MFA/FIDO) kapot is.

Klopt FIDO2 kan idd kapot daarom is het advies ook om 2 breakglass accounts te gebruiken.

Probeer maar eens een Yubikey te slopen zodat deze niet meer werkt dan heb je toch wel extreme bruteforce nodig. En voor iets wat in een kluis hoort te liggen lijkt het mij vrijwel uitgesloten dat een Yubikey zomaar stuk zou kunnen gaan. Regelmatig testen zou je als proces op kunnen nemen, net zoals iedereen zijn backups test of deze wel te restoren zijn.

Overigens inloggen met FIDO2 is vrijwel hetzelfde als inloggen met een username and password enkel is er een cryptografisch afstemming en is het dus een heel stuk veiliger dan een wachtwoord.

[Triblade_8472]

Ik doelde meer aan de software kant, niet het fysieke ding.

[Padje]

Software kant? FIDO2 is hardware 😎 ik bedoel dus hardware security keys.

[Padje]

Het verbaasd mij dan ook eigenlijk dat een giga bedrijf als MS geen intern lock/unlock systeem heeft voor break-the-glass accounts bij hun enterprise klanten.

Bijvoorbeeld dat je een bepaald MFA-loos account kan aanmaken als een BtG waarna je een code krijgt die je offline moet bewaren. Je daarna naar MS moet bellen die je naar de code vragen om dit account te kunnen ontgrendelen.

Het zijn de extra lagen die ertoe doen.

Introduceer je hiermee niet een bepaalde afhankelijkheid die misbruikt kan worden?

Hoe verifieert Microsoft jouw identiteit enkel op basis van een code? Lijkt mij geen goed plan.

Microsoft adviseert voor break-glass / emergency access accounts:

• Maak minimaal twee noodaccounts.
• Gebruik cloud-only accounts op het *.onmicrosoft.com-domein, dus niet afhankelijk van AD FS, sync of federatie.
• Geef ze permanent actief Global Administrator, niet alleen PIM-eligible.
• Gebruik ze alleen bij noodsituaties, niet voor normaal beheer.
• Sluit ze uit van blokkerende Conditional Access policies, zoals MFA-, compliant-device- of locatie-eisen.
• Gebruik wél sterke/phishing-resistant authenticatie, bij voorkeur FIDO2 security key of certificaatgebaseerde authenticatie.
• Bewaar credentials/FIDO2-sleutels veilig, gescheiden en fysiek beschermd.
• Monitor elk gebruik met alerts op sign-ins en auditlogs.
• Test minimaal elke 90 dagen of ze nog werken.
• Gebruik bij voorkeur een PAW/secure admin workstation voor aanmelding.

Belangrijk nuancepunt: Microsoft zegt dus niet meer simpelweg “geen MFA op break-glass”. Het advies is: niet afhankelijk maken van Conditional Access of reguliere MFA-processen, maar wel sterke, robuuste authenticatie gebruiken die ook werkt als je normale CA/MFA-configuratie stuk is.

[Triblade_8472]

Dit zijn adviezen, niet per sè de beste manier. (en nee, ik zeg niet dat er iets slechts tussen zit)

Ik ken dit riddeltje. Ik vindt het alleen niet heilig. Nogmaals, voor mij is een BtG account juist voor als mfa en/of FIDO enz softwarematig kapot zijn.

[Padje]

Zou je eens een situatie willen schetsen? Het is voor mij niet duidelijk wat je bedoelt met de software kant? Bedoel je het webauth protocol?

[Mushroomician]

Gebeurt wel vaker.

Ik stelde leidinggevende voor om Shamir’s Secret Sharing algoritme te gebruiken voor het breakglass account. Krijg ik glazen ogen gevolgd door een mededeling dat de MSP (leverancier) dat moet beheren. Zij bewaren het in een ticketsysteem, in plain tekst!

Maar volgens de accountant zijn zij wel ISO27001 gecertificeerd dus het zal wel goed zijn!

[Reactie gewijzigd door Mushroomician op 5 juni 2026 20:57]

[Triblade_8472]

Als je MSP dit plain text bewaard, dan zou ik per direct een andere MSP zoeken!
Minimaal een klacht indienen bij hun CISO oid.

Ik neem aan dat ze ISO27001 gecertificeerd zijn, wat zou betekenen dat dit absoluut niet kan. Kan je ook meteen klagen bij degene die het certificaat heeft uitgegeven.

[laurens0619]

Iso27001 gaat veelal over het proces niet de inhoud

Secure want compliant komt niet vaak voor helaas

[Triblade_8472]

ISO27001 vraagt van je dat je weet wat je doet, dat je het goed gedocumenteerd hebt en je hieraan houd.

Ja, je mag je eigen regels bepalen, maar alleen als dit kloppen met je business. Bijvoorbeeld: als je je eigen regels opstelt dat je geen backup nodig hebt, dan zal een auditor dit afkeuren. Want er is tegenwoordig geen enkel bedrijf meer dat geen schade ondervindt van verlies van data.

Datzelfde geldt ook voor MSP's die wachtwoorden van klanten hebben. Geen enkele auditor zal goedkeuren dat je plain text wachtwoorden opslaat, dit strookt namelijk niet met de verplichte risico-analyse die je moet maken.

[laurens0619]

Goed om te lezen dat jij meer vertrouwen hebt in iso certificeringen dan ik

[Triblade_8472]

Niet bepaald, ik beschrijf alleen wat het zou moeten doen.

In werkelijkheid merk ik een peperdure papieren tijger waar men de auditor naar de mond schrijft maar in werkelijkheid iets anders doet omdat dat veel gemakkelijker is.

Certificeringen zijn er om de klant tevreden te houden, niets meer of minder.

Daarom blijf ik klagen in fora zoals deze over auditors die hun werk niet goed doen. Het helpt ook niet dat de opdrachtgever degene is die ze moeten controleren, die ga je niet afkeuren natuurlijk, dan verlies je de klus. Al dan niet toekomstige audits bij hen.

Bij elke hack bij IT clubs gebeurt er iets onbenulligs terwijl ze 9/10 keer gecertificeerd zijn en dit hadden kunnen voorkomen.
Ik wordt altijd kwaad als auditors niet aangepakt worden voor dit soort, wat ik vermoed, corruptie. Certificeringen zouden per direct ingetrokken moeten worden en het bedrijf die de audit/de betreffende auditor moet ook flink aan de tand gevoeld worden. Wellicht met ernstig falen de licentie verliezen. Zonder maatregelen blijft de, naar mijn idee, corruptie.

[laurens0619]

Ah dan denk ik dat we het meer eens zijn maar ik denk dat iso27001 in theorie ook tekort schiet.

Het doet vooral design effectiveness een beetje operationel effectiveness met dunne sampling.

Zolang jij op papier beschrijft hoe het zou moeten zijn is de praktische waarheid van ondergeschikt belang.

vroeger was soc2 type2 dan een krachtig alternatief maar ook die begint zijn waarde te verliezen. Soms zijn bedrijven drukker in compliant te worden dan secure.

[Triblade_8472]

Soms zijn bedrijven drukker in compliant te worden dan secure.

Mooie quote.

[hans-martijn]

SOC 2 is ongelofelijk veel werk, waarbij voor een klein bedrijfje de kosten vaak hoger zijn dan de opbrengsten. ISO 27001 is verre van perfect, en sterk afhankelijk van de auditor / CI. Helaas is er geen betere oplossing op dit moment om te controleren of een bedrijf iets met IB doet, behalve zelf controleren. Als it-bedrijf zit je alleen ook niet te wachten op alle it-ers van klanten die komen controleren of jij het wel goed doet.

[batjes]

Er zou wel een betere oplossing zijn.

ISO27001 serieus nemen. Bij audits zou er gecontroleerd moeten worden of wat op papier staat ook in de praktijk uitgevoerd wordt.

Ik heb ook ISO27001 certificeringen en audits meegemaakt die wel effectief zijn. Punt x,y,z moet binnen zoveel tijd opgelost zijn of certificering kwijt.

Het probleem is vooral dat de meeste tokos niet zo streng auditen, want anders zoekt de klant wel een ander. En zo heb je een race naar de bodem.

[Mushroomician]

Hun argument is dat het op een server staat die met bitlocker is encrypted. Daarmee is elke leek verkocht. Wat weet die nieuwe 30’er nou wat een bijna gepensioneerde niet weet?

Ik werk er gelukkig niet meer, maar het is een maatschappelijk probleem dat de verkeerde mensen de verkeerde verantwoordelijkheden hebben. En als je voorstelt om het uit te leggen letterlijk claimen: “zij hoeven en willen het niet te begrijpen”

[Reactie gewijzigd door Mushroomician op 5 juni 2026 21:38]

[Triblade_8472]

Brrrr, je hebt gelijk dat het verkeerde mensen (we bedoelen mensen die niet geschikt zijn voor het werk dat ze doen) zijn met verkeerde verantwoordelijkheden.

Ik begrijp goed dat je blij bent er niet meer te werken!

[-Vasa-]

Wat je beschrijft is een mitigatie factor voor een risico dat aanvaard wordt door hun management. Dat is perfect mogelijk binnen ISO27001. Is het goed? Natuurlijk niet, want een server encrypten met bitlocker is sowieso al rotvervelend voor je backups. Al zeker als je meerdere hosts hebt en je vm's moet kunnen shiften.

[batjes]

Een ISO27001 certificering is in de praktijk net zo veel waard als wat het bedrijf er zelf waarde aan hecht.

Ik heb over de jaren dingen gezien waarbij ik mij serieus afvraag hoe dat door een audit heen kan komen. Zelfs bij serieuze grote tokos met een verzameling certificeringen worden er nog wachtwoorden opgeslagen in browsers, mstsc, kitty/putty of anderen. En dat is niet eens een aandachtspunt voor de volgende audit.

Bij de meeste tokos is het 1 dag per jaar nauwelijks meer dan een clean desk policy.

Er wordt echt amper serieus geaudit door de meeste certificeringsinstanties.

[-Vasa-]

ISO27001 zegt niets over de eigenlijke veiligheid, maar enkel over het feit dat er een gedocumenteerd veiligheidsbeleid is, dat men opvolgt en evalueert. Je kan perfect een reeks zaken uitsluiten of letterlijk stellen dat je een bepaald risico aanvaard met eventueel mitigerende maatregelen.

Op zich kan je voor een organisatie die een ISO27001 certificatie gehaald heeft, gerust navragen wat het toepassingsgebied is. Er zijn voldoende organisaties die eigenlijk alles uitsluiten wat moeilijk te beheren is. Niet om slecht over ze te spreken (want ik snap de redenen en kan het volgen waarom ze het doen), maar bijvoorbeeld AFAS heeft een grappig toepassingsgebied, ze sluiten bijvoorbeeld expliciet uit dat het testen van hun software binnen de scope valt, Het maakt ze niet onveilig natuurlijk, maar het is wel grappig dat een software bedrijf bepaalde beheersmaatregelen over software development expliciet wenst uit te sluiten. Natuurlijk is dat eerlijker dan het niet uit te sluiten en het gewoonweg niet, of slecht te doen.

[Reactie gewijzigd door -Vasa- op 6 juni 2026 11:53]

[-Vasa-]

Specifiek over die laatste vermelding zie ik ondertussen zelfs dat dat al immens verbeterd is en mijn comment dus niet meer van toepassing is.

[Iekozz]

Het is inderdaad vrijwel zeker entra id wat gebruikt wordt. Beetje off topic: Maar als je nu denkt goh, hoe zit dat bij mij?

Je kunt gratis met de open source tooling maester heel veel dingen al opsporen en automatisch fixen: https://maester.dev/ - Gemaakt door Merill Fernando de ex program manager van entra bij microsoft.

[Triblade_8472]

Ik ben altijd huiverig om voor mij onbekende script van onbekende sites van onbekende mensen te draaien.
De scope is CurrentUser, en dat betekend dus dat de gemiddelde admin dit met Global Admin aftrapt...
Brrrr.

Zijn er betrouwbare mensen die door de gehele code gegaan zijn om te kijken of het echt betrouwbaar is?

Het zal niet de eerste keer zijn dat er enge dingen gebeuren in vertrouwde tools van vertrouwde mensen.

[Arfman]

Ik mag toch hopen dat de gemiddelde admin niet standaard GA is in zijn tenant ...

[William_H]

Je zal ze de kost geven....
"Nee, we maken slechts 2 mensen GA, dat is veiliger".
Aldus een manager bij één van mijn vorige werkgevers 🤡

[Arfman]

Hoe minder mensen GA kunnen worden, hoe beter, dat klopt wel.

[William_H]

Ja, maar als die collega dan nog gewoon elke dag inlogt met z'n GA account, dan gaat er natuurlijk iets niet goed. Die moet voor het dagelijks werk natuurlijk gewoon een "lager" account hebben. En dat gebeurde niet.
Zelf vond ik het niet erg geen GA meer te hebben, des te minder verantwoordelijkheid, kon ik ook niet verantwoordelijk zijn voor een hack 😅 (zeker hoe ze het hadden ingesteld dus).

[Triblade_8472]

Ik ben bang van wel... Ik heb ~15 jaar overal en nergens als consultant gewerkt, van overheid tot industrie en van zorg tot MKB. Je wil niet weten wat ik allemaal ben tegengekomen.

Waarom denk je dat er zoveel consultants nodig zijn.

[Arfman]

Sorry, maar dan heb je echt je zaakjes niet op orde. Dat is anno 2026 echt niet meer nodig. Scheiding van taken en verantwoordelijkheden, PIM voor privileged access, etc. Half uurtje werk bij wijze van.

[Triblade_8472]

I know, maar ja.

Een van de redenen is gebrek aan ervaring. Als men lang op een plek blijft dan leer je niks. Je moet ècht willen en leergierig zijn. Daarnaast is, iig in wat ik zie, de nieuwere generatie meer geïnteresseerd in de quick wins dan degelijke beveiliging van je werkgever.

[laurens0619]

Ik ook. Ik heb wel vorige week geleerd dat het alleen leesrechten nodig heeft

[WouterL]

Knullig maar wel zeer transparant.

[zeezuiper]

MFA moet ook op break the glass accounts aanstaan. Dan is het gebruik van een FIDO key hiervoor wel het makkelijkst, die je vervolgens weer in de kluis opbergt. Uiteraard periodiek testen en uiteraard ook alerting aanzetten op het moment er mee ingelogd wordt.

[Reactie gewijzigd door zeezuiper op 5 juni 2026 20:45]

[SunnieNL]

Mmm.. Het begon voornamelijk omdat werknemers op hun desktop gewoon windows+r (run) konden gebruiken, cmd.exe konden starten en powershell niet geblokkeerd stond of was ingesteld om alleen vertrouwde scripts te draaien. Die eerste layer of defense was er gewoon niet. Was die defensie er wel geweest (bv via ms applocker, ivanti application control, mss zelfs gpo's) dan was deze hack een stuk lastiger geweest.

[GertMenkel]

Je kunt niet voorkomen dat mensen Windows-executables draaien. Je hebt geen windows+r nodig, het "openen" prompt van kladblok kan namelijk ook gewoon programma's starten. Een clickfix-aanval kan gebruikers net zo goed vertellen om op "openen" te klikken en dan het commando te laten plakken; kwestie van een knopje met klik hier als je geen venster ziet met alternatieve instructies.

Het is slecht dat de antivirusoplossing dit twee dagen lang niet detecteerde, is denk ik de grootste reden dat men het zover heeft kunnen laten komen.

Eerlijk gezegd zijn dit soort aanvallen wel reden om veel personeel Chromebooks en iPads uit te delen. Windows beveiligen tegen iemand die braaf een opdrachtregel plakt en op enter drukt is bijna onmogelijk.

[Reactie gewijzigd door GertMenkel op 5 juni 2026 22:04]

[SunnieNL]

Je kunt zeker wel voorkomen dat personen zomaar cmd.exe of powershell kunnen starten. Cmd.exe beschikbaar hebben voor normale gebruikersaccounts is not done. Dat hebben ze helemaal niet nodig.

Al zou je via kladblok cmd.exe proberen te openen, als die op de block list staat van applocker gaat je dat niet zomaar lukken als gewone gebruiker.

Scripts af trappen gaat je ook niet zomaar lukken met de juiste tools. ClickFix in de basis zeer lastig maken om uit te voeren is helemaal niet zo moeilijk als je een beetje basis cyber hygiene toepast.

Windows beveiligen tegen iemand die braaf een command-line plakt is echt heel, heel erg eenvoudig.

Sterker nog, BIO1 heeft gewoon in de regels staan dat alleen goedgekeurde applicaties gestart mogen worden. In BIO2 staat het niet meer letterlijk, maar kom je op hetzelfde uit.

Applicaties als Applocker, Applocker for business, ivanti application control, threat locker, etc. en het standaard blokkeren van bepaalde apps als cmd.exe, regedit.exe, etc. is een must om te voldoen aan de cbw en alle afgeleiden daarvan en leggen een eerste defense tegen gebruikers die zomaar iets kopieren en plakken omdat ze de executable direct zullen blokkeren als een gewone gebruiker dat doet.

[fuzzyIon]

Waarom werd er geen yubikey gebruikt?

[mr.DJ95]

Als Informatiebeveiliging Officer bij een grote MSP heb ik regelmatig te maken met de inrichting en configuratie van zogenaamde break glass accounts. Hiervoor hanteren wij de volgende uitgangspunten:

• Minimaal twee accounts per tenant om een single point of failure te voorkomen.
• Accounts zijn vanuit Entra ID niet direct herkenbaar als break glass account en volgen de reguliere naamconventie van de klant.
• Accounts zijn voorzien van een uniek, lang en willekeurig gegenereerd wachtwoord dat wordt beheerd in een daarvoor aangewezen wachtwoordkluis.
• MFA wordt ingericht met een oplossing die onafhankelijk is van Microsoft, zodat toegang mogelijk blijft wanneer Microsoft MFA-, Conditional Access- of Entra ID-gerelateerde diensten niet beschikbaar zijn.
• Zodra het account vanuit de wachtwoordkluis wordt ingezien, uitgecheckt, toegepast of gewijzigd, wordt automatisch een melding en ticket aangemaakt voor het SOC. De engineer dient hierbij de noodzaak van het gebruik vast te leggen.
• Op zowel succesvolle als mislukte aanmeldpogingen worden realtime detecties en meldingen gegenereerd richting het SOC.
• Na gebruik wordt het wachtwoord direct geroteerd en wordt beoordeeld of aanvullende maatregelen noodzakelijk zijn.
• Accounts beschikken niet over een mailbox, licenties, Teams-functionaliteit, OneDrive-opslag of andere gebruikersfunctionaliteiten die niet noodzakelijk zijn voor het doel van het account.
• Accounts worden uitgesloten van Conditional Access-beleid, device compliance controles, risico-gebaseerde toegangsmaatregelen en andere configuraties die de beschikbaarheid van het account tijdens een noodsituatie kunnen beperken.
• Accounts worden niet gebruikt voor reguliere beheerwerkzaamheden en uitsluitend ingezet wanneer reguliere beheerdersaccounts geen toegang meer kunnen verkrijgen of wanneer sprake is van een expliciet goedgekeurde noodsituatie.
• Accounts zijn permanent opgenomen in monitoring- en detectieregels binnen het SIEM/SOC-platform.
• Wijzigingen aan wachtwoorden, MFA-methoden, groepslidmaatschappen en toegekende rollen genereren direct een beveiligingsmelding.
• Accounts worden minimaal per kwartaal getest op werking, inclusief aanmelding, MFA-functionaliteit, monitoring en procedures rondom uitgifte vanuit de wachtwoordkluis.
• De accounts worden beschermd tegen automatische uitschakeling, verwijdering of wijzigingen door lifecycle management-processen, identity governance-oplossingen of automatiseringsscripts.
• Gebruik van een break glass account wordt achteraf geëvalueerd en vastgelegd als onderdeel van het security- of incidentmanagementproces.

De beveiliging/inrichting van deze accounts wijzigt regelmatig door nieuw verkregen inzicht uit bijvoorbeeld pentest rapporten of wijzigende best practices zoals CIS en Microsoft.

[IrBaboon79]

Epe - dat vraagt eigenlijk om een bijpassende limerick.

Er was eens een gemeente medewerker uit Epe…

Wie vult hem aan?

[Cooyco]

Een gemeentelijk IT-er in Epe

Had van beveiliging niet veel begrepen

Hij zette de deur zo wijd open

Dat hackers lachend binnen konden lopen

Om heel Epe leeg te screpe

[XiliX]

Die had geen zin om met hardwarekeys te slepe

[wschoonveld]

Wat voor mij de grote vraag is: wie besluit dit op deze manier te doen om dit zo op deze manier te beveiligen? En wie controleert diegene dan? Zo’n besluit neem je niet in je eentje. Bovendien is er een controlerende externe partij? Ik snap dit niet, we hebben het over zo’n bak met gegevens… Het siert de gemeente dat ze transparant willen zijn en dat daarmee bekend wordt wat er mis is gegaan, ondanks de fouten die zijn gemaakt.

[R_Zwart]

Dat zullen onze vakgenoten besloten hebben lijkt me. Het is niet dat de burgemeester of wethouders zeggen dat dit gedaan moet worden. Die vertrouwen er op dat de ITers verstand van zaken hebben.

[pizzafried]

Al is "daar hebben we het budget niet voor" vaak niet ver weg.

[PCG2020]

'We betalen teveel belastingen!'
'Wij van Partij Minder Belastingen horen u! Stem op ons!'
'Wethouder van PMB, we moeten de boel beveiligen!'
'Wat kost dat, IT-ambtenaar?'
'Zo en zoveel, wethouder.'
'Te duur! Dan is er geen geld meer voor het volledig asfalteren van het stadspark!'