Toegangscontrole (Access Control)

Beschrijving van de maatregel volgens ISO 27001/27002

Control A.5.15 eist dat een organisatie regels en processen invoert voor het beheersen van zowel fysieke als logische toegang tot informatie en andere bedrijfsmiddelen[1]. Het doel is een preventieve beveiligingsmaatregel te implementeren die ervoor zorgt dat alleen geautoriseerde individuen en entiteiten (zoals softwarediensten of machines) toegang krijgen tot gevoelige data, systemen en faciliteiten[1]. Toegangscontrole betekent in de praktijk dat toegang wordt gebaseerd op zakelijke behoefte en informatiebeveiligingseisen[1].

Volgens ISO 27002:2022 omvat A.5.15 verschillende vormen van toegangsbeheersing: onder meer mandatory access control (MAC, centraal beheerd door één autoriteit), discretionary access control (DAC, waarbij eigenaren zelf rechten doorgeven), role-based access control (RBAC, op basis van gedefinieerde rollen/functies) en attribute-based access control (ABAC, op basis van beleidsregels die kenmerken combineren)[2][3]. Ongeacht de gekozen methode benadrukt de norm dat toegang tot middelen alleen mag worden verleend of aangepast op basis van concrete zakelijke behoeften en beveiligingsvereisten[4]. Dit houdt meestal in dat het least privilege-principe wordt toegepast: gebruikers en systemen krijgen uitsluitend toegangsrechten die nodig voor hun functie of taak[5].

Concreet moet er een toegangscontrolebeleid zijn dat de regels beschrijft voor het verlenen, intrekken en periodiek herzien van toegang[6]. Alle relevante assets (informatie, systemen) moeten bekend zijn en geclassificeerd, zodat men toegang kan koppelen aan de asset-registratie en classificatie (onder meer A.5.9 en A.5.12)[7]. Toegang wordt bepaald op basis van need-to-know (functionele rol) of need-to-use (taakspecifiek) om te voorkomen dat iemand onnodige rechten heeft[8]. Rollen en rolgebaseerde toegang zijn aanbevolen om efficiëntie en consistentie te bevorderen (bijvoorbeeld een standaardprofiel voor “HR-manager”)[9]. Niet alleen mensen vallen onder deze controle, maar ook niet-menselijke identiteiten zoals service-accounts, API’s en IoT/apparaten moeten onder toegangscontrole vallen[10]. Verder vereist A.5.15 continue periodieke herziening van toegangsrechten (bijv. jaarlijks of vaker) om privilege creep te voorkomen – het verschijnsel dat gebruikers over tijd ongemerkt extra rechten accumuleren die niet langer nodig zijn[11]. Tot slot benadrukken de richtlijnen dat toegang niet permanent en zonder evaluatie mag blijven bestaan: met regelmaat moet worden gecontroleerd of iemands toegangsrechten nog gerechtvaardigd zijn.

Relevantie voor MKB zonder eigen securityteam

Ook voor kleine en middelgrote organisaties is toegangscontrole een fundamentele beveiligingsmaatregel. Juist organisaties zonder dedicated security team of SOC lopen het risico dat toegangsbeheer informeel of ad-hoc gebeurt. Dit kan leiden tot situaties waarin (oud-)medewerkers, leveranciers of systemen te ruime of ongecontroleerde toegang hebben. In MKB-omgevingen vervullen medewerkers vaak meerdere rollen, en zonder strak beleid kan men geneigd zijn gebruikers “voor de zekerheid” brede rechten te geven. Dat druist in tegen het least privilege-principe en vergroot de kans op incidenten.

Daarnaast hebben MKB’s vaak beperkte IT-staf, waardoor formele procedures (zoals aantoonbare autorisatie bij het verlenen van rechten, of regelmatige review van accounts) minder vanzelfsprekend zijn. Toch zijn deze controles net zo belangrijk voor MKB: veel datalekken en beveiligingsincidenten komen juist voort uit eenvoudige toegangsissues zoals ongeautoriseerde accounts of teveel mensen met admin-rechten. Volgens het Verizon Data Breach Investigations Report blijven gecompromitteerde toegangsgegevens de hoofdoorzaak van inbraken – in 2023 waren gestolen credentials betrokken bij ongeveer 50% van de onderzochte breaches[12]. Dit soort statistieken geldt niet alleen voor multinationals, maar ook voor kleinere bedrijven: een aanvaller zal waar mogelijk misbruik maken van slecht beheerde accounts of brede toegangsrechten.

Omdat MKB-organisaties vaak niet de middelen hebben voor geavanceerde detectie, is preventie via goed toegangsbeheer extra belangrijk. Het voorkomt niet alleen externe aanvallen (een hacker die een ongebruikt account vindt), maar ook interne incidenten (een onbevoegde medewerker die gevoelige gegevens bekijkt, of mogelijk zelfs steelt). Bovendien vragen klanten, partners en auditors steeds vaker om bewijs dat ook kleinere organisaties hun toegang adequaat beheersen. Een helder, eenvoudig toegangsbeleid en disciplinaire uitvoering daarvan kan bij een audit vertrouwen wekken, zelfs zonder gespecialiseerd team. Kortom, toegangscontrole vormt een eerste verdedigingslinie die voor elk bedrijf – groot of klein – onmisbaar is.

Veelvoorkomende tekortkomingen en over het hoofd geziene punten

Gebrekkige formele procedures: Een vaak gezien gebrek is het ontbreken van een formeel toegangscontrolebeleid of -proces. In kleine organisaties wordt toegang geregeld “op verzoek via e-mail of een telefoontje” zonder duidelijke autorisatie of documentatie. Hierdoor ontbreekt een audit-trail: men kan niet aantonen wie goedkeuring gaf of of een recht nog nodig is. Ook training van personeel in deze procedures schiet tekort, waardoor men regels omzeilt of vergeet.

Niet intrekken van rechten bij vertrek: De grootste fout is dat accounts van vertrokken medewerkers of ex-derden blijven bestaan[13][14]. Auditors noemen dit vaak als gotcha: bijvoorbeeld als men vraagt om een lijst van vertrokken werknemers en aantreft dat hun VPN- of applicatieaccounts nog actief zijn[15]. Het niet volgen van een “leaver-proces” leidt ertoe dat oud-medewerkers soms maanden later nog toegang hebben[16][13]. Dit is een ernstig beveiligingslek én laaghangend fruit voor auditors om afkeuring op te baseren. Daarnaast betaalt de organisatie mogelijk nog voor accounts die niet meer actief hoeven te zijn.

Privilege creep door accountkopieën: Een andere fout is het klonen van accounts bij nieuwe medewerkers (“geef persoon X dezelfde rechten als Y, want vergelijkbare functie”). Dit leidt vaak tot geleidelijke privilege creep, waarbij nieuwe gebruikers onnodig alle rechten van hun voorganger erven, inclusief die niet relevant zijn[17][18]. Zeker bij functiewisselingen intern blijft men soms oude rechten behouden als die niet expliciet worden ingetrokken bij rolwijziging. Zulke cumulatieve rechten worden gemakkelijk over het hoofd gezien, comprommitatie van een dergelijk account is een security drama

Altijd actieve derde-partij accounts: Toegang voor leveranciers of IT-support wordt regelmatig permanent actief gelaten, ook nadat de taak is afgerond. Bijvoorbeeld: een externe IT-partner krijgt een generiek account voor onderhoud en dit wordt nooit uitgeschakeld. Reguliere audits missen dit soms, omdat men focus legt op personeel, terwijl third-party access ook periodiek gesloten of opnieuw geautoriseerd zou moeten worden[19][20]. Het is een slecht teken als externe consultants die maanden geleden klaar waren, nog steeds inlogmogelijkheden hebben.

Te ruime admin-toegang: In kleinere bedrijven ziet men vaak dat een handvol gebruikers (of zelfs iedereen) lokale admin op hun PC heeft, of dat voor het gemak meerdere mensen Domain Admin-rechten krijgen. Dit ondermijnt segregatie van bevoegdheden. Bovendien wordt zelden gelogd wie admin-acties uitvoert; vaak worden beheeraccounts gedeeld (bijv. iedereen gebruikt “Administrator” account). Auditors vragen soms: “Toon de leden van de administratorsgroep en leg uit wie ze zijn.” In 9 van de 10 gevallen komen er adminaccounts naar voren die men vergeten was, van ex-medewerkers of accounts waarvan men zelf de oorsprong niet meer weet[21]. Zulke “wees-accounts” of onverklaarde adminprofielen vormen een onmiddellijk probleem[21].

Lacunes in periodieke reviews: Hoewel het beleid vaak voorschrijft dat toegangsrechten jaarlijks of per kwartaal herzien moeten worden, schiet dit er in de praktijk bij in. Zeker zonder SOC is er geen continue monitoring, en reviews worden soms pro forma of helemaal niet uitgevoerd. Hierdoor blijven outdated privileges onopgemerkt. Wat vaak over het hoofd wordt gezien, is de koppeling tussen informatieclassificatie en toegang: als er geen actueel classificatieschema is (A.5.12), weet men niet welke informatie streng beperkt zou moeten zijn (A.8.3). In audits komt dit naar voren als er bijvoorbeeld vertrouwelijke dossiers blijken te staan op gedeelde schijven toegankelijk voor “Alle Medewerkers”, wat indruist tegen het need-to-know principe.

Voorbeelden van gerelateerde incidenten en kwetsbaarheden

Ex-medewerker met toegang saboteert systemen: Een schrijnend voorbeeld van het niet intrekken van toegang is de zaak van IT-beheerder Levi Delgado. Deze systeembeheerder werd ontslagen bij een medisch centrum, maar behield klaarblijkelijk zijn inloggegevens of een achterdeur. Enkele maanden na vertrek logde hij in op het netwerk van zijn ex-werkgever, verwijderde grote hoeveelheden data en schakelde gebruikersaccounts uit[22][23]. Dit incident laat zien hoe desastreus het kan zijn als een vertrokken medewerker nog toegang heeft: bedrijfsprocessen lagen stil en gevoelige medische gegevens waren mogelijk verdwenen. Zulke wraakaanvallen door oud-medewerkers komen helaas regelmatig voor als de leaver-procedure faalt.

Onbeveiligde LDAP-toegang en anonieme queries: In sommige netwerkomgevingen staat LDAP (directory service) toe dat anonieme gebruikers queries uitvoeren. Dit is vaak een fabrieksinstelling die niet uitgeschakeld is. Aanvallers kunnen dergelijke anonieme LDAP-binds misbruiken voor reconnaissance – ze vergaren lijstjes van gebruikers, groepen en computers, wat kan helpen bij gerichte aanvallen[24][25]. In het ergste geval betekent dit ook al direct een datalek omdat persoonlijke gegevens van gebruikers gelukt kunnen zijn. Ransomware-groepen (zoals BlackCat, LockBit e.a.) maken hier gebruik van door tools als AdFind of SharpHound te draaien tegen Active Directory, vaak in een vroeg stadium van de aanval[26][27]. Als LDAP anoniem of met een laag auth-niveau toegankelijk is, wordt zo’n verkenning wel erg makkelijk. Dit voorbeeld benadrukt dat beperking van toegang tot informatie (A.8.3) niet alleen op bestanden slaat, maar ook op directory-informatie: men moet ongeautoriseerde uitlezing van accounts voorkomen.

Misbruik van adminrechten door malware: Veel succesvolle cyberaanvallen escaleren doordat aanvallers snel beheerrechten weten te verkrijgen. In Windows-omgevingen bijvoorbeeld proberen aanvallers Domain Admin of lokale adminrechten te bemachtigen om lateral movement en massale schade mogelijk te maken. Zo bleek uit onderzoek dat in 2023 meerdere ransomwaregroepen (o.a. Akira, BlackSuit, BlackByte) tools als SharpHound en AdFind gebruikten om Active Directory af te speuren naar hooggeprivilegieerde accounts en hun permissies[28][27]. Eenmaal gevonden, worden die accounts overgenomen of misbruikt voor verdere infiltratie. Dit onderstreept het belang van A.8.2 (beperken en monitoren van bevoorrechte toegang): elke admin-account is een kroonjuweel voor aanvallers. Daarnaast tonen interne incidenten zoals de San Francisco netwerk gijzeling aan dat ontevreden IT-admins systemen kunnen “gijzelen” door wachtwoorden niet vrij te geven of wijzigingen te saboteren[29]. Het risico is reëel als er geen beleid is voor het afschermen van kritieke admincreds of voor 4-ogen-principe bij gevoelige wijzigingen.

Privégegevens openbaar door ontbreken need-to-know: Een ander type incident betreft het onvoldoende beperken van toegang tot vertrouwelijke informatie (A.8.3). Een recent voorbeeld is een overheidsinstantie in Illinois die interne plattegrondbestanden met persoonsgegevens op een publiek toegankelijke website had staan. Door onjuiste privacy-instellingen waren van 2021 tot 2025 gevoelige gegevens van 700.000 burgers openbaar toegankelijk zonder authenticatie[30][31]. Pas na jaren werd dit ontdekt en de toegang beperkt. Dergelijke blootstellingen komen ook in bedrijfscontext voor, bijvoorbeeld een HR-map op het netwerk die per abuis openstaat voor iedereen, of een klantendatabase in de cloud die niet afgeschermd is. Zulke incidenten zijn vaak het gevolg van het nalaten van het need-to-know-principe: men heeft niet expliciet ingesteld wie wat niet mag zien, waardoor de default “iedereen mag alles” blijft gelden.

Open S3-buckets en datalekken: Veel organisaties gebruiken cloudopslag (zoals Amazon S3, Azure Blob) maar configureren de toegangsrechten incorrect. Een berucht geval betrof het Britse outsourcingsbedrijf Capita in 2023. Capita liet een Amazon S3 bucket met ca. 655 GB aan gegevens zeven jaar lang onbeveiligd op het internet staan[32]. Er was geen wachtwoord of toegangsrestrictie op deze cloudopslag, waardoor iedereen die de URL kende bij de bestanden kon. De blootgestelde data bevatte o.a. software-images, talloze Excel- en tekstbestanden en zelfs inloggegevens voor interne systemen[33][34]. Dit incident toont een pijnlijk eenvoudig lek: gebrek aan basismaatregelen om gevoelige bestanden af te schermen. Het illustreert direct de geest van controle A.8.3 (Beperking toegang tot informatie): zorg dat informatie niet anoniem of publiek toegankelijk is als het niet expliciet voor publicatie bedoeld is[35]. Publieke cloud misconfigurations zoals deze hebben bij meerdere bedrijven tot datalekken geleid en zijn een favoriet doelwit van opportunistische aanvallers.

Broncode-diefstal door insider threat: Waar broncode het belangrijkste intellectuele eigendom is (bij softwarebedrijven), kan ongecontroleerde toegang daartoe rampzalig zijn. Een voorbeeld is de aanval op een groot softwarebedrijf waarbij een hackerteam (LAPSUS$) interne ontwikkelaccounts wist over te nemen. In 2022 drong LAPSUS$ binnen bij Microsoft via een gestolen inlog van een medewerker en verkreeg leesrechten op talloze interne Git-repositories. Zij lekten vervolgens de broncode van o.a. Bing en Cortana online[36][37]. Hoewel Microsoft aangaf dat er geen verhoogd risico ontstond door inzage in de code, illustreert dit wel dat een enkele gecompromitteerde identiteit zonder strikte toegangsafbakening tot enorme hoeveelheden waardevolle broncode toegang kon krijgen. LAPSUS$ pleegde vergelijkbare aanvallen op andere techbedrijven (Okta, NVIDIA, Samsung), waarbij soms tientallen tot honderden gigabytes aan gevoelige broncode en gegevens werden buitgemaakt[38][39]. Deze incidenten verbinden direct met A.8.4 (toegangsbeveiliging op broncode): onvoldoende beperking en monitoring van toegang tot code maakt het mogelijk dat een insider of externe aanvaller bedrijfskritische software manipuleert of steelt. Ook supply-chain aanvallen hangen hiermee samen – denk aan de SolarWinds-aanval, waar vermoedelijk een eenvoudig wachtwoord op een update-server  en het ontbreken van code-integriteitscontroles bijdroegen aan het kunnen injecteren van kwaadaardige code in hun product[40]. Kortom, als de broncodebeveiliging faalt, kan dit leiden tot sabotage (malware in codebasis) of diefstal van intellectueel eigendom met grote schade voor de organisatie en haar klanten.

Onvoldoende veilige loginprocedures: Veel aanvallen beginnen bij zwakke authenticatie. Een klassiek voorbeeld is de hack op Colonial Pipeline in 2021. De aanvallers verkregen toegang tot de infrastructuur via een oud VPN-account dat nog actief was zonder multi-factor authenticatie (MFA)[41]. Hoewel het wachtwoord op zich complex was (dus niet “Colonial123”), volstond één enkel gelekt wachtwoord om binnen te komen omdat een tweede verificatiestap ontbrak[41][42]. Dit incident onderstreept dat secure authentication (A.8.5) meer omvat dan een sterk wachtwoord afdwingen – zonder MFA of andere aanvullende controles is een gestolen wachtwoord vaak genoeg om een crisis te veroorzaken.

Ook op kleinere schaal zien we dit patroon: veel ransomwaregroepen richten hun pijlen op RDP (Remote Desktop Protocol) of VPN van MKB-bedrijven, omdat deze vaak alleen met gebruikersnaam/wachtwoord beveiligd zijn. Met eenvoudige password spraying of via wachtwoordlekken weten criminelen geregeld toegang te krijgen tot zulke systemen. Volgens security-onderzoek is het gros van succesvolle ransomware-inbraken te herleiden tot zwakke of gestolen inloggegevens (samen met phishing)[12][43]. In een compliance-onderzoek in 2025 werd zelfs geconstateerd dat bij ~70% van de onderzochte cloudomgevingen het vereiste van MFA op admin-accounts niet goed was ingevoerd[44][45]. Het gevolg is dat Control 5.17 (Authentication information) – waarin sterke authenticatie voor o.a. beheerdersaccounts is opgenomen – één van de meest geschonden normen was[45]. Met andere woorden: het niet hebben van bijv. MFA op beheerders is tegenwoordig een directe afwijking van de norm en een open deur voor aanvallers. Dit is een duidelijk signaal dat zelfs basale verbeteringen in loginbeveiliging (zoals MFA) een groot verschil kunnen maken in het dreigingsniveau.

Aanbevelingen voor pragmatische implementatie (MKB)

Voor MKB-organisaties is het belangrijk de bovenstaande controls pragmatisch en stapsgewijs in te voeren. Hieronder geven we per thema aanbevelingen, gericht op effectiviteit met beperkte middelen:

• Formuleer een beknopt Toegangsbeleid: Stel een eenvoudig maar duidelijk toegangscontrolebeleid op (A.5.15) dat past bij de schaal van uw bedrijf. Leg hierin vast hoe accounts worden aangevraagd en goedgekeurd, wie autorisaties mag verlenen (bijv. managers voor hun teamleden), hoe vaak toegangsrechten herzien worden (minimaal jaarlijks) en hoe bij vertrek toegang wordt ingetrokken. Houd het beknopt – een one-pager met rolgebaseerde toegangsmatrix en procedures volstaat vaak. Belangrijk is dat het management dit beleid steunt en uitdraagt, zodat iedereen weet: toegang verlenen is een bewuste, gedocumenteerde handeling, geen ad-hoc gunst.
  
  

• Inrichten van identiteits- en toegangsbeheerprocessen: Implementeer het Joiner-Mover-Leaver principe (A.5.16 & A.5.18) met bestaande middelen. Vaak kan HR of administratie een lijst bijhouden van nieuwe starters, interne functiewijzigingen en vertrekkers, die periodiek (wekelijks, maandelijks, kwartaalijks, afhankelijk van de organisatie grootte) met IT wordt doorgenomen. Voor elke nieuwe medewerker (Joiner) bepaalt men vóór dag 1 welke toegangen nodig zijn, en deze worden door IT ingericht na goedkeuring van de leidinggevende. Bij functie- of rolwijzigingen (Mover) trekt men oude rechten in voordat nieuwe worden toegekend. En bij uitdiensttreding (Leaver) zorgt men dat op de laatste werkdag alle toegang wordt gedeactiveerd (of zelfs binnen een uur na uitdienst, afhankelijk van de gevoeligheid)[46]. Onderstaande tabel geeft een voorbeeld van zulke levenscyclus-acties en timing:

Praktijkvoorbeeld levenscyclus beheer van toegangsrechten (Joiner-Mover-Leaver)[46].

• Tools voor identiteitsbeheer: Maak gebruik van bestaande platformen voor basaal identiteitsbeheer. Veel MKB’s gebruiken Microsoft 365 of Google Workspace – hierin zitten al functies voor gebruikers- en groepsbeheer. Azure AD (voor MS365) of Google Directory laten toe om accounts centraal te beheren en toegang tot gekoppelde apps te regelen. Profiteer van deze suites: definieer in Azure AD groepen per functie (bv. “Sales” krijgt CRM toegang) en laat HR mutaties doorgeven aan IT zodat de juiste groepstoekenningen worden gedaan. Overweeg voor Windows-netwerken Active Directory lokaal, eventueel gekoppeld met Azure AD voor cloudresourcen, zodat offboarding via één proces werkt. Voor zeer kleine organisaties kan een eenvoudige accountlijst in Excel tegen HR-gegevens al helpen om niets te missen bij vertrek. Het belangrijkste is overzicht: weet welke accounts bestaan (mens en vergeet vooral ook geen niet-mens) en in welke systemen, zodat geen “verborgen” accounts blijven rondzwerven.
  
  

• Strikte beheersing van admin- en speciale rechten: Stel specifieke regels op voor bevoorrechte accounts (A.8.2). Beperk het aantal gebruikers met adminrechten tot een absoluut minimum en hanteer het principe van scheiding van taken: de persoon die een bepaalde toegang aanvraagt of nodig heeft, is niet dezelfde als die toegang toekent[47]. Geef normale gebruikers geen admin-rechten op hun eigen werkstation als het niet noodzakelijk is. Gebruik waar mogelijk een apart administrator-account per persoon naast het normale gebruikersaccount, en werk alleen met het admin-account voor specifieke beheerhandelingen. Zo’n scheiding (admin vs. user context) verkleint de kans dat een phishingmail meteen volledige systeemrechten oplevert.
  
  

• Just-In-Time en monitoring: Overweeg voor incidentele beheerstaken om tijdelijke toegang te verlenen die automatisch vervalt. In Microsoft Azure AD is er bijvoorbeeld Privileged Identity Management (PIM) voor just-in-time adminrechten (beschikbaar in bepaalde licenties) – dit is wellicht te geavanceerd of duur voor sommige MKB, maar het principe kan men handmatig nabootsen: geef een externe beheerder slechts een account dat men aanzet wanneer nodig en direct daarna weer uitzet[48]. Zorg ook dat alle aanmeldingen op (domain) admin accounts gelogd worden. Schakel in Windows het loggen van Privilege Use events in en verzamel logboeken (desnoods gewoon periodiek handmatig bekijken of via een goedkope log oplossing). Als een admin-account om 3 uur ’s nachts inlogt, wil men dat snel opmerken. Voor kritieke systemen kan men aanmeldingsalerts instellen (bijv. een mailtje of notificatie als de admin inlogt).
  
  

• Lokaal beheer wachtwoorden beveiligen: Een praktisch hulpmiddel voor Windows-omgevingen is LAPS (Local Administrator Password Solution) van Microsoft, een gratis tool die lokaal beheerderswachtwoorden (bijv. van de “Administrator” account op elke PC) uniek houdt en opslaat in AD, zodat niet overal hetzelfde admin-wachtwoord staat. Dit voorkomt dat één gelekt wachtwoord tot volledige domeinovername leidt. LAPS is een eenvoudige maatregel die bij audits aantoont dat men bewust met admin-creds omgaat (relevant voor A.5.17 en A.8.2).
  
  

• Beperken van informatie-toegang: Pas het need-to-know-principe breed toe (A.8.3). Loop na welke gedeelde mappen, databases en applicaties er zijn en welke gevoelige data ze bevatten. Vervolgens: segmenteer toegangen. Bijvoorbeeld: financiële administratiebestanden alleen toegankelijk voor Finance medewerkers; HR dossiers alleen voor HR, etc. In cloud-opslag (OneDrive/SharePoint, Google Drive) gebruik groepen of gedeelde drives om per afdeling te scheiden. Schakel functies uit die data onbeheerd openbaar delen: verbied bijvoorbeeld het delen van links “voor iedereen met de link” voor interne gevoelige documenten – kies in plaats daarvan “alleen geauthenticeerde interne gebruikers”. Controleer publieke kant van de website en cloud of er geen bestanden of API’s open staan die niet open horen. Tip: voer regelmatig een simpele open directory scan uit (of Google search op uw domeinnaam en veelvoorkomende bestandsnamen) om te detecteren of interne info via zoekmachines vindbaar is. Tevens, koppel de maatregel aan classificatie: label vertrouwelijke documenten als zodanig en implementeer technische restricties (bijv. DLP – Data Loss Prevention regels die voorkomen dat “Intern Vertrouwelijk” documenten naar externe e-mail worden gestuurd of op USB gezet). Hoewel DLP tooling kostbaar kan zijn, bieden Microsoft 365 en Google basispolicies aan in sommige abonnementen waarmee je al een begin kunt maken (zoals waarschuwingen bij extern delen van veel persoonsgegevens).
  
  

• Broncode veilig opslaan en controleren: Voor A.8.4 (toegang tot broncode) is het advies om allereerst een versiebeheersysteem te gebruiken (bijvoorbeeld git met een platform als GitHub, GitLab of Bitbucket) in plaats van code op netwerkschijven of losse computers te bewaren. Een cloud-gebaseerde repo (privé) biedt meteen mogelijkheden om rechten te beheren (alleen geautoriseerde ontwikkelaars toegang) en acties te loggen. Activeer MFA op het repository-platform voor alle gebruikers – GitHub verplicht dit inmiddels voor organisaties. Richt in de repository rolverdeling in: niet iedere ontwikkelaar hoeft write-toegang tot alle projecten; gebruik read-only rechten waar van toepassing, en bescherm kritieke branches (zoals de main/master branch) tegen directe commits door verplichte code reviews in te schakelen. Code review door minstens 2 personen vangt niet alleen bugs, maar kan ook malafide code-insluitsels of ongeoorloofde wijzigingen detecteren (vier-ogen-principe). Overweeg het gebruik van digitale handtekeningen (code signing) voor builds of scripts, zodat wijzigingen achteraf traceerbaar en betrouwbaar zijn[49]. Voor software die u uitgeeft: gebruik build pipelines die auth controleren (ci/cd systemen met beperkte toegang) en teken eindbinaries. Tevens is het verstandig om toegang van externen tot code zeer beperkt in tijd en scope te geven. Als u freelance ontwikkelaars inschakelt, maak per persoon een account aan en verwijder dat zodra de samenwerking eindigt. Log uitcheck- en commit-activiteit – veel platforms bieden audit logs of tenminste een historie per gebruiker. Mocht een incident zich voordoen (bijv. plotselinge massa code exfiltratie), dan wilt u dit kunnen zien en de account direct blokkeren. Tenslotte, sla geen secrets (wachtwoorden, API keys) in code op – gebruik een aparte secret vault of op zijn minst environment configurations buiten de code repository. Dit voorkomt situaties zoals bij SolarWinds waar een zwak wachtwoord in een repo stond[40]. Er zijn gratis tools (bijv. git-secrets of TruffleHog) die automatisch repos scannen op gelekte secrets; die kunt u integreren in uw ontwikkelproces als extra zekerheid.

• Versterk authenticatieprocedures: Implementeer beveiligde authenticatie (A.8.5) op al uw systemen met prioriteit voor extern toegankelijke diensten en beheertoegang. Concreet betekent dit: Multi-factor authenticatie inschakelen voor alle VPN, RDP, e-mail, cloud en beheertools. Voor MKB die Microsoft 365 gebruiken is dit eenvoudig te activeren via Azure AD security defaults of Conditonele Toegang (MFA verplicht stellen voor alle gebruikers of ten minste beheerders). Veel diensten bieden gratis MFA-opties (mobile authenticator apps) die men alleen hoeft aan te zetten. MFA is een snelle winst omdat het meer dan 90% van de aanvallen met alleen wachtwoorden blokkeert[50]. Zeker voor admin-accounts geldt: MFA is feitelijk vereist voor compliance[51][52].

Daarnaast, implementeer basis accountbeveiliging: forceer waar mogelijk account-lockout na een aantal mislukte inlogpogingen om brute-force te voorkomen. Schakel verouderde, onveilige protocollen uit (bijv. POP3/IMAP zonder SSL of oude NTLMv1 logons) en sta alleen versleutelde verbindingen toe. Gebruik waar mogelijk SSO (Single Sign-On) oplossingen zodat gebruikers niet overal aparte wachtwoorden hebben – dit maakt het beheer van authenticatie centraler en veiliger. Bijvoorbeeld, stel uw bedrijfs-Google of Microsoft-account in als federatie voor externe applicaties die het ondersteunen, zodat medewerkers met één vertrouwde identiteit overal kunnen inloggen (en dus overal profiteren van MFA en beleid).

·         Wachtwoordbeheer en -beleid: Hoewel MFA veel risico’s wegneemt, blijft goed wachtwoordbeheer essentieel (A.5.17). Hanteer een sterk wachtwoordbeleid dat ten minste omvat: minimale lengte (bij voorkeur ≥12 tekens), verbod op veelgebruikte wachtwoorden (gebruik eventueel lijsten van gelekte wachtwoorden), en gebruikers stimuleren om passphrases te gebruiken in plaats van moeilijke korte wachtwoorden. Vermijd te frequente verplichte resets (te frequente wissels leiden tot zwakkere wachtwoorden of hergebruik-patronen); focus liever op unieke, lange wachtwoorden en reset alleen bij vermoeden van compromis. Voorzie medewerkers van een Password Manager – er zijn betaalbare oplossingen zoals LastPass Teams, 1Password Business, maar ook open source (Bitwarden). Dit helpt hen sterke, unieke wachtwoorden te genereren en veilig op te slaan in plaats van op papiertjes of in ongecodeerde bestanden. Instrueer ook duidelijke do’s and don’ts rondom wachtwoordgebruik, bijvoorbeeld via een gebruikersrichtlijn of checklist.

Een voorbeeld van zo’n checklist staat hieronder, met goede en slechte praktijken voor gebruikersauthenticatie:

Checklist voor veilig omgaan met authenticatie-informatie[53].

Deze afspraken kunnen als bijlage bij het beveiligingsbeleid of als korte e-learning aan personeel worden meegegeven. Voor MKB is bewustwording namelijk net zo belangrijk als technische maatregelen: één medewerker die zijn wachtwoord op phishing invoert of een onbekende MFA-prompt accepteert, kan de hele keten doorbreken. Training en simulaties (bijv. af en toe een phishingtest) helpen gebruikers alerter te zijn.

• Change default credentials: Zorg dat standaardwachtwoorden en -accounts van alle apparaten en software onmiddellijk bij ingebruikname worden gewijzigd of uitgeschakeld (A.5.17 eis). Veel MKB-apparatuur (routers, NAS, camera’s) komt met admin/admin of een vaste PIN. Inventariseer bij aanschaf alle default logins (de handleiding of een eenvoudige google-zoektocht vermeldt deze meestal) en pas ze direct aan naar een uniek, sterk wachtwoord. Maak dit onderdeel van de installatiestappen (bijv. een checklist die door de IT-reseller of interne IT wordt afgevinkt)[54][55]. Zwakke of default credentials vormen een enorm risico en zijn eenvoudig te vermijden door diligence bij installatie.

• Prioriteiten stellen: Voor MKB zonder uitgebreid team is het ondoenlijk alles in één keer perfect te regelen. Stel daarom prioriteiten op basis van risico.

  • Hoogste prioriteit: sluit de grootste gaten eerst. Dit betekent: alle privileged accounts beveiligen met MFA (direct doen, kost weinig), alle overbodige accounts disablen/verwijderen (meteen lijst doornemen, grote schoonmaak), alle standaardwachtwoorden wijzigen. Dit zijn acties die binnen dagen in gang gezet kunnen worden en direct het risico drastisch verlagen.

  • Tweede prioriteit: implementeer formele processen (joiner/leaver, periodieke review) en leg verantwoordelijkheid vast (wie doet wat bij onboarding/offboarding). Dit vergt wat overleg en documentatie, maar voorkomt langdurig dat er gaten vallen.

  • Derde prioriteit: verdere verfijning zoals het opzetten van rolgebaseerde toegangsprofielen, het invoeren van een geautomatiseerd IAM-oplossing als de schaal dat vraagt, of hulpmiddelen als een SIEM-light voor logmonitoring van kritieke accounts. Deze kunnen in een later stadium of bij groei van de organisatie worden opgepakt.

Cruciaal is om beheersmaatregelen inbed in de normale bedrijfsprocessen. Als HR standaard bij vertrek een checklist heeft die ICT-instellingen omvat, zal uitschakelen van accounts niet worden gemist. Als leidinggevenden elke kwartaal een e-mail krijgen met “controleer of jouw medewerkerslijst en hun rechten nog kloppen” en ze hoeven alleen bijzonderheden terug te koppelen, dan is de review praktisch uitvoerbaar. Zoek ook synergie: een kleine IT-servicedesk tool of zelfs een SharePoint-lijst kan worden gebruikt om toegangsaanvragen en approvals bij te houden, zodat je bewijs hebt voor audits.

Tot slot, onderschat niet de waarde van externe hulp op maat: ook zonder eigen SOC kan een MKB een externe partij vragen om periodiek de gebruikerslijst en rechten door te lichten of een simpele audit te doen. Dit hoeft niet duur te zijn en brengt een objectieve check. Sommige managed service providers bieden “AD gebruikers opschoning” of security quickscans die precies deze controles uitvoeren. Het signaleren van bijvoorbeeld een vergeten admin-account door een frisse blik, kan een toekomstige grote kwetsbaarheid voorkomen.

Door bovengenoemde maatregelen gefaseerd in te voeren, kan een MKB-organisatie effectief voldoen aan de ISO 27001:2022-controles op het gebied van logische toegang. Het resultaat is niet alleen compliance “op papier”, maar ook een aantoonbaar verbeterde security: minder accounts die rondzwerven, scherpere afbakening van wie bij welke informatie mag, en sterk gereduceerde kans dat een simpele wachtwoordcompromittering leidt tot een ernstig incident. Deze investeringen in toegangsbeveiliging zijn voor kleinere organisaties zeer renderend, gezien de potentiële schade van één incident vele malen groter kan zijn dan de kosten en moeite om basismaatregelen op orde te hebben.

Bronnen: De inhoud en aanbevelingen in dit rapport zijn gebaseerd op de ISO/IEC 27001:2022 en ISO/IEC 27002:2022 standaarden en aanvullende bronnen en casussen, waaronder best practice gidsen[1][56], security-onderzoeken[12][45] en gerapporteerde beveiligingsincidenten uit de praktijk[32][22]. Deze referenties zijn in de tekst opgenomen ter verificatie en verdieping.

[1] [5] [6] [7] [8] [9] [10] [11] [13] [15] [16] [19] [20] ISO 27001 Annex A 5.15 Guide | Access Control

https://hightable.io/iso-27001-annex-a-5-15-access-control/

[2] [3] [4] ISO 27002, Control 5.15, Access Control | ISMS.online

https://www.isms.online/iso-27002/control-5-15-access-control/

[12] [43] Top 5 Insights from the Verizon DBIR 2023 - Axiom Security

https://axiom.security/top-5-insights-from-the-verizon-dbir-2023/

[14] [17] [18] [21] [46] [47] [48] [56] ISO 27001 Annex A 5.18 Guide | Access Rights & JML

https://hightable.io/iso-27001-annex-a-5-18-access-rights/

[22] [23] IT professional carries out a cyber-attack against former employer

https://cyfor.co.uk/it-professional-carries-out-a-cyber-attack-against-former-employer/

[24] [25] [26] [27] [28] LDAP Reconnaissance Explained | Semperis Identity Attack Catalog

https://www.semperis.com/blog/ldap-reconnaissance-explained/

[29] San Francisco Held Cyber-Hostage? Disgruntled Techies ... - WIRED

https://www.wired.com/2008/07/insider-tech-at/

[30] Illinois state agency exposed personal data of 700000 people

https://therecord.media/illinois-agency-exposed-data

[31] Illinois DHS reports data exposure from publicly accessible planning ...

https://chambanatoday.com/news/298892-illinois-dhs-reports-data-exposure-from-publicly-accessible-planning-maps/

[32] [33] [34] Security researcher finds trove of Capita data exposed online | TechCrunch

https://techcrunch.com/2023/05/05/security-researcher-finds-trove-of-capita-data-exposed-online/

[35] ISO27002:2022 - Controls - OnePager

https://asphalia-analytics.com/blog/posts/pdf/8.03%20-%20Information%20access%20restriction%20-%20OnePager.pdf

[36] [37] [38] [39] Microsoft Breach 2022! Product Source Code Compromised

https://www.stealthlabs.com/news/it-giant-microsoft-breached-products-source-code-compromised/

[40] SolarWinds hack explained: Weak password cause of SolarWinds Hack

https://specopssoft.com/blog/solarwinds-hack-weak-password-solarwinds123-cause/

[41] [42] One password allowed hackers to disrupt Colonial Pipeline, CEO tells senators | Reuters

https://www.reuters.com/business/colonial-pipeline-ceo-tells-senate-cyber-defenses-were-compromised-ahead-hack-2021-06-08/

[44] [45] [50] [51] [52] ISO 27002 - 5.17 : Why MFA for Cloud Admins Can’t Wait

https://www.unosecur.com/blog/iso-27002---5-17-the-mfa-rule-68-of-cloud-teams-still-fail

[49] 8.4 Access to Source Code for ISO 27002:2022

https://www.avisoconsultancy.co.uk/iso-27001-2022-annex-a/8-4-access-to-source-code

[53] [54] [55] ISO 27001 Annex A 5.17 Guide | Authentication Secrets

https://hightable.io/iso-27001-annex-a-5-17-authentication-information/