Niet persoonsgebonden account

In veel organisaties bestaan er accounts die niet aan een specifieke persoon zijn gekoppeld maar worden gedeeld door meerdere medewerkers of worden gebruikt door systemen en applicaties voor geautomatiseerde processen. Deze niet persoonsgebonden accounts, ook wel NPA's, shared accounts of functionele accounts genoemd, vormen een aanzienlijk beveiligingsrisico dat vaak wordt onderschat. Wanneer meerdere mensen dezelfde inloggegevens gebruiken, wordt het onmogelijk om te achterhalen wie welke handeling heeft uitgevoerd op welk moment. Dit gebrek aan accountability maakt niet persoonsgebonden accounts tot een geliefd doelwit voor zowel interne als externe dreigingen en een veelvoorkomende zwakke schakel in de beveiligingsketen van organisaties.

Er zijn twee hoofdtypen niet persoonsgebonden accounts die elk hun eigen kenmerken en risico's hebben. Niet-interactieve NPA's worden gebruikt door systemen en applicaties voor geautomatiseerde processen, zoals een serviceaccount dat een database raadpleegt of een applicatieaccount dat API-calls uitvoert. Interactieve NPA's zijn accounts die door meerdere personen worden gebruikt om in te loggen op systemen, zoals een gedeeld beheerdersaccount voor serverbeheer of een teamaccount voor een specifieke applicatie. Beide typen brengen specifieke beveiligingsrisico's met zich mee, maar interactieve NPA's vormen het grootste gevaar omdat ze direct door mensen worden gebruikt zonder individuele verantwoording.

Waarom zijn niet persoonsgebonden accounts belangrijk voor cybersecurity?

Het belangrijkste en meest fundamentele risico van niet persoonsgebonden accounts is het verlies van accountability. Als drie beheerders hetzelfde admin-account gebruiken en er een ongeautoriseerde configuratiewijziging wordt aangetroffen, is het onmogelijk om vast te stellen wie de wijziging heeft doorgevoerd en met welke intentie. Dit bemoeilijkt zowel het forensisch onderzoek bij beveiligingsincidenten als de dagelijkse controle op bevoegd gebruik van systemen en data.

Niet persoonsgebonden accounts worden vaak beveiligd met zwakkere wachtwoorden die minder frequent worden gewijzigd dan persoonlijke accounts. Wanneer een wachtwoord wordt gedeeld met meerdere personen, is de kans aanzienlijk groter dat het op onveilige manieren wordt gecommuniceerd, zoals via onversleutelde e-mail, chatberichten of zelfs post-its op het beeldscherm. Bij het vertrek van een medewerker die toegang had tot een gedeeld account moet het wachtwoord worden gewijzigd en aan alle overige gebruikers worden gecommuniceerd, een arbeidsintensief proces dat in de praktijk regelmatig wordt vergeten of uitgesteld.

Vanuit compliance-perspectief zijn niet persoonsgebonden accounts problematisch voor elke organisatie die moet voldoen aan regelgeving. De AVG en diverse branchespecifieke regelgeving vereisen dat toegang tot systemen en data herleidbaar is tot individuele personen. Auditors beschouwen niet persoonsgebonden accounts consequent als een risicofactor en kunnen organisaties hierop afrekenen bij certificeringsaudits voor standaarden zoals ISO 27001. Het ontbreken van individuele herleidbaarheid kan leiden tot bevindingen die de certificering in gevaar brengen.

Het NCSC beveelt in zijn basisprincipes voor cybersecurity expliciet aan om het gebruik van niet persoonsgebonden accounts te minimaliseren en waar mogelijk volledig te elimineren. In de basismaatregelen stelt het NCSC dat elke medewerker een eigen gebruikersaccount moet hebben, zodat activiteiten traceerbaar zijn en toegangsrechten individueel kunnen worden beheerd en ingetrokken. Dit sluit aan bij het Least Privilege-principe, dat stelt dat toegang moet worden beperkt tot het minimum dat nodig is voor de functie-uitoefening.

Hoe ga je om met niet persoonsgebonden accounts?

De eerste en meest cruciale stap is het inventariseren van alle niet persoonsgebonden accounts in je organisatie. Dit omvat zowel interactieve accounts die door medewerkers worden gebruikt als serviceaccounts die door applicaties worden ingezet. Doorzoek Active Directory, lokale systemen, cloudomgevingen en applicaties systematisch op accounts die niet aan een individuele persoon zijn gekoppeld. Vaak ontdekken organisaties bij deze inventarisatie dat er aanzienlijk meer NPA's bestaan dan verwacht, inclusief verouderde accounts die niet meer actief worden beheerd maar nog wel functioneel zijn.

Elimineer interactieve NPA's waar mogelijk door ze te vervangen door persoonlijke accounts. In de meeste gevallen kunnen gedeelde accounts worden vervangen door individuele accounts met de juiste autorisatie. Als een team van drie beheerders toegang nodig heeft tot een specifiek systeem, geef dan elk teamlid een persoonlijk account met de benodigde rechten in plaats van een gedeeld beheerdersaccount. De investering in extra licenties weegt niet op tegen de beveiligingsrisico's en compliance-problemen van gedeelde accounts.

Voor serviceaccounts en technische NPA's die niet kunnen worden geelimineerd, implementeer strikte beveiligingsmaatregelen die het risico minimaliseren. Gebruik lange, complexe wachtwoorden van minimaal dertig tekens die automatisch worden geroteerd via een Privileged Access Management (PAM)-oplossing. Beperk de rechten van serviceaccounts tot het absolute minimum dat nodig is voor hun specifieke functie en monitor het gebruik actief op afwijkingen van het verwachte gedragspatroon.

Implementeer een formeel goedkeuringsproces voor het aanmaken van nieuwe niet persoonsgebonden accounts dat voorkomt dat NPA's ongecontroleerd groeien. Elke NPA moet een gedocumenteerde eigenaar hebben die verantwoordelijk is voor het beheer, de beveiliging en de periodieke evaluatie van het account. De eigenaar beoordeelt regelmatig of het account nog nodig is en of de toegangsrechten nog passend zijn voor het huidige gebruik. Stel een maximale geldigheidsduur in waarna het account automatisch wordt uitgeschakeld tenzij het actief wordt verlengd door de eigenaar.

Log alle activiteiten van niet persoonsgebonden accounts uitgebreid en analyseer deze regelmatig op afwijkingen. Hoewel individuele identificatie niet altijd mogelijk is bij gedeelde accounts, kan afwijkend gedrag zoals inlogpogingen buiten kantooruren, toegang vanaf onbekende IP-adressen of ongebruikelijke datatoegangpatronen wel worden gedetecteerd en onderzocht. Koppel waar mogelijk aanvullende identificatiemethoden, zoals IP-adresbeperkingen of multifactor authenticatie, aan niet persoonsgebonden accounts om het risico op misbruik te verkleinen.

In de praktijk

In veel organisaties zijn niet persoonsgebonden accounts historisch gegroeid over jaren heen en vormen ze een verborgen beveiligingsrisico dat pas zichtbaar wordt bij een audit of incident. Een veelvoorkomend scenario: een IT-afdeling gebruikt een gedeeld admin-account om servers te beheren. Wanneer een van de drie beheerders de organisatie verlaat, wordt het wachtwoord niet direct gewijzigd omdat de andere twee beheerders het account dagelijks gebruiken en een wachtwoordwijziging lastig te coordineren is. De voormalige medewerker behoudt hierdoor potentieel maandenlang toegang tot kritieke systemen, een risico dat met individuele accounts eenvoudig zou worden voorkomen door het deactiveren van het account op de laatste werkdag.

Bij een beveiligingsaudit ontdekte een financiele instelling meer dan tweehonderd niet persoonsgebonden accounts in hun Active Directory, waarvan een kwart niet meer actief werd beheerd of gereviewd. Sommige accounts hadden al meer dan drie jaar hetzelfde wachtwoord en waren oorspronkelijk gekoppeld aan medewerkers die de organisatie al lang hadden verlaten. Het opschonen en beveiligen van deze accounts werd een prioriteitsproject dat meerdere maanden in beslag nam en significante IT-resources vereiste.

Organisaties die een PAM-oplossing implementeren, kiezen er steeds vaker voor om ook niet persoonsgebonden accounts centraal te beheren via deze oplossing. De PAM-oplossing slaat de wachtwoorden van NPA's op in een beveiligde digitale kluis, roteert ze automatisch volgens een vast schema en registreert nauwkeurig wie wanneer een wachtwoord heeft uitgecheckt en voor welk doel. Dit herstelt een mate van accountability bij gedeelde accounts en vermindert het risico op wachtwoordlekken aanzienlijk, terwijl het ook een compleet auditspoor oplevert.

In DevOps-omgevingen en moderne cloudarchitecturen zijn serviceaccounts bijzonder prevalent en nemen ze snel in aantal toe. CI/CD-pipelines, containerorkestratiesystemen zoals Kubernetes en clouddiensten maken intensief gebruik van serviceaccounts voor geautomatiseerde processen. Best practice is om deze accounts te beveiligen met kortstondige tokens die automatisch verlopen in plaats van statische wachtwoorden, en om de rechten te beperken tot precies die acties die noodzakelijk zijn voor het geautomatiseerde proces via fijnmazige IAM-policies.

Veelgestelde vragen

Mag je niet persoonsgebonden accounts gebruiken volgens de AVG?

De AVG vereist herleidbaarheid, dus NPA's zijn alleen acceptabel met aanvullende controlemaatregelen.

Wat is het verschil tussen een serviceaccount en een shared account?

Een serviceaccount wordt door systemen gebruikt, een shared account door meerdere personen.

Hoe vaak moet het wachtwoord van een NPA worden gewijzigd?

Minimaal bij elk personeelsverloop en periodiek, bij voorkeur automatisch via een PAM-oplossing.

Kan ik niet persoonsgebonden accounts volledig elimineren?

Interactieve NPA's kunnen meestal worden vervangen, serviceaccounts blijven vaak technisch noodzakelijk.

Hoe documenteer ik niet persoonsgebonden accounts correct?

Registreer eigenaar, doel, rechten, wachtwoordrotatie en gebruikers in een centraal register.

Wil je meer weten over accountbeveiliging en toegangsbeheer? Verken het volledige cyberwoordenboek op IBgidsNL.