Wat is PAM (Privileged Access Management)?

Dit is precies het scenario waar Privileged Access Management (PAM) voor bestaat. En het is waarschijnlijk de reden dat je dit artikel leest.

Het probleem zit niet bij de gewone gebruiker

In de meeste organisaties is identity management voor de doorsnee medewerker inmiddels redelijk op orde. Mensen loggen in via single sign-on, MFA staat aan, joiners-movers-leavers loopt grotendeels via HR-data. IT Ops weet hoe het werkt en de CISO heeft er grip op.

Maar dan zijn er die andere accounts. De domeinbeheerder. De service-account waarmee de backup-software draait. Het lokale admin-wachtwoord op 800 werkstations dat op alle 800 hetzelfde is. De break-glass-account voor als alles plat ligt. De externe leverancier die elke maandagochtend even moet inloggen op het ERP om een job te draaien.

Die accounts vallen vaak buiten het reguliere identity-proces. En precies die accounts zijn wat aanvallers zoeken. Een phishing-mail die een gewoon account compromitteert is vervelend. Een phishing-mail die een domain admin compromitteert is een datalek.

Waarom de huidige aanpak tekortschiet

De meeste organisaties beheren bevoegde accounts op drie manieren tegelijk, en geen van die manieren werkt goed.

De eerste laag is een wachtwoordkluis, vaak iets als KeePass of een gedeeld 1Password-vault. Werkt prima voor één persoon, breekt zodra je met vier mensen tegelijk hetzelfde admin-wachtwoord moet gebruiken. Wachtwoorden roteren gebeurt zelden, omdat niemand weet welke scripts erop leunen.

De tweede laag is hopen dat het goed komt. Domeinbeheerders krijgen vaste accounts met permanente rechten, omdat het uitdelen en intrekken van tijdelijke rechten te omslachtig voelt. Just-in-time access staat in elk auditrapport sinds 2018, maar in de praktijk loggen vier mensen elke dag in als enterprise admin omdat dat nu eenmaal handig is.

De derde laag is de hoop dat logging werkt. Op papier registreert Active Directory wie wat doet. In de praktijk staat de log-retentie op 30 dagen, niemand kijkt erin tenzij er iets misgaat, en gedeelde accounts maken het sowieso onmogelijk om een actie aan een persoon te koppelen.

Het echte probleem is niet dat er geen tools zijn. Het probleem is dat bevoegde toegang in de meeste organisaties als een uitzondering wordt behandeld, terwijl het in de praktijk dagelijkse routine is. Een PAM-strategie behandelt het als wat het is: een proces dat continu loopt en zichzelf moet kunnen verantwoorden.

Wat doet PAM eigenlijk?

PAM staat voor Privileged Access Management. Sommige bronnen gebruiken ook Privileged Account Management. In de praktijk dekt de term beide ladingen: het beheren van de accounts zelf én het managen van wat die accounts mogen, wanneer, en met welke verificatie.

Een volwassen PAM-aanpak combineert vier elementen.

Vaulting van credentials. Wachtwoorden, SSH-keys en API-tokens voor bevoegde accounts staan in een centrale, versleutelde kluis. Niemand kent het werkelijke wachtwoord. Je checkt het uit, gebruikt het, en het wordt direct daarna geroteerd. In de Microsoft-terminologie heet dit geautomatiseerd wachtwoordbeheer.

Just-in-time access. Iemand heeft niet permanent admin-rechten. Iemand vraagt rechten aan, krijgt ze voor een afgebakende periode (een uur, een werkdag, een specifieke change-window), en daarna vervallen ze automatisch.

Sessie-monitoring en opname. Elke sessie waarin verhoogde rechten worden gebruikt, wordt vastgelegd. Niet alleen welk commando, maar de volledige sessie. Bij een incident hoef je niet te reconstrueren wat er gebeurd is, je kunt het terugkijken.

MFA op alles wat bevoegd is. Geen uitzonderingen voor service-accounts of break-glass. MFA is altijd aan, altijd verplicht.

Wat dit oplost voor jou als CISO is geen technologisch probleem. Het lost een verantwoordingsprobleem op. Bij een audit kun je laten zien wie wanneer welke rechten heeft gebruikt, met welke onderbouwing, en wat er tijdens die sessie is gebeurd. Dat is de scope van bijvoorbeeld ISO 27001 en NEN 7510, twee frameworks die expliciete eisen stellen aan het beheer van bevoegde toegang.

Welke accounts vallen onder PAM?

Een misverstand: PAM gaat niet alleen over IT-personeel. Microsoft onderscheidt acht categorieën bevoegde accounts. Een paar daarvan zien organisaties nog wel: domeinbeheerders en lokale beheerders, toepassingsbeheerders met volledige toegang tot een applicatie en de bijbehorende data, superuser-accounts met onbeperkte rechten.

Maar deze worden vaak vergeten:

• Service-accounts. Applicaties die met elkaar praten via accounts met vaste credentials. Vaak nooit geroteerd, vaak gebruikt door meerdere systemen tegelijk, vaak met meer rechten dan nodig.
• Noodaccounts (break-glass). Bedoeld voor het moment waarop alle andere toegang faalt. Mogen nooit dagelijks gebruikt worden, maar als er geen monitoring op zit weet je niet of dat zo is.
• Externe leveranciers en consultants. Die ZZP'er die elke maand even moet inloggen voor onderhoud. Heeft die nog rechten als de samenwerking eindigt? In hoeveel organisaties wordt dat structureel bijgehouden?
• Zakelijke bevoegde accounts. Een financieel directeur met goedkeuringsrechten op betalingen. Is technisch geen IT-account, maar functioneel net zo bevoegd.

Het eerste wat we doen bij een PAM-traject is dit in kaart brengen. Vrijwel altijd komen er accounts aan het licht waarvan niemand wist dat ze bestonden, of die op naam staan van iemand die er drie jaar geleden is vertrokken.

Hoe wij PAM aanpakken

We zijn geen PAM-leverancier. We zijn 18 jaar Identity-architect en Okta Apex Partner, het hoogste partnerniveau in de Benelux. In 2025 zijn we uitgeroepen tot Okta Partner of the Year voor de Benelux. We implementeren PAM op basis van wat we in onze 40+ identity-implementaties hebben zien werken en niet werken.

Onze aanpak voor PAM staat op vier pijlers.

Eerst inventariseren, dan tooling. Een PAM-tool installeren zonder eerst te weten welke accounts er zijn, levert een dure illusie van controle op. We beginnen met een inventarisatie: welke privileged accounts bestaan er, wie gebruikt ze, waarvoor, met welke frequentie, en wat zijn de afhankelijkheden. Pas daarna kiezen we welke accounts in scope gaan voor de eerste fase.

Start met de hoogste-impact accounts. Niet alles tegelijk. We beginnen meestal met domain admins en service-accounts in de productieomgeving. Daar zit het meeste risico en de meeste audit-druk. De rest fasen we in.

Just-in-time waar het kan, vault waar het moet. Voor menselijke gebruikers gaan we zoveel mogelijk naar tijdelijke rechten. Voor service-accounts en gedeelde accounts gaat het vaker om vaulting met automatische rotatie. We kiezen per accounttype wat past, niet één model voor alles.

Integratie met je bestaande IGA-proces. PAM staat niet los van de rest van je identity-landschap. Joiners-movers-leavers, access reviews, certificatie. Dat moet allemaal samenwerken. Daarom hangen we PAM aan dezelfde brondata (HR, contractmanagement) als de rest van je identity governance administration. Één workflow, één review-proces, één auditspoor.

Voor klanten die op Okta zitten is Okta Privileged Access vaak de logische keuze. Het integreert met de bestaande Okta-tenant, gebruikt dezelfde MFA-policies, en biedt JIT-access voor servers, vaulting voor accounts, en sessie-opname voor compliance. Voor klanten met een andere stack kijken we breder. Het draait niet om een product, het draait om of de oplossing past bij je infrastructuur en je proces.

We werken binnen MVP-cycli van 10 tot 30 dagen, dezelfde aanpak als bij onze Okta-implementaties. Geen jaarprogramma's, geen Big Bang. Eerst een afgebakende scope live, dan de volgende.

Wat dit oplevert

Wat we in de praktijk zien bij organisaties die PAM goed inrichten:

• Audit-bewijs zonder spitwerk. Een vraag van de auditor over wie er drie maanden geleden tussen 20:00 en 22:00 op de productieserver zat, beantwoord je in vijf minuten in plaats van vijf dagen. Inclusief sessie-opname.
• Werkbare just-in-time-flows. Mensen vragen rechten aan via een proces dat 30 seconden duurt, niet via een ticket dat een week blijft liggen. Permanente admin-rechten verdwijnen, zonder dat het werk vastloopt.
• Compliance-claims die kloppen. ISO 27001 hoofdstuk 9 (toegangsbeheer) en NEN 7510 voor de zorg krijgen daadwerkelijke onderbouwing in plaats van een procedure-document dat niemand naleeft.
• Service-accounts onder controle. Wachtwoorden roteren automatisch, niemand kent ze meer in plaintext, en als een script ergens een account gebruikt zie je dat in het auditspoor.
• Een werkbaar leveranciersproces. Externen krijgen tijdelijke rechten via een aanvraag-flow, gebruiken die voor de afgesproken klus, en zien hun rechten daarna automatisch vervallen.

Wanneer is dit iets om nu serieus te nemen?

Er zijn een paar situaties waarin we adviseren niet langer te wachten. De meest concrete is een aangekondigde audit waarin je weet dat de huidige logging op privileged accounts onvoldoende bewijs oplevert. Een tweede situatie is een recent incident waarbij een bevoegd account betrokken was, of een sector-incident dat je raakt en waar je je bestuur niet langer mee kunt aanhouden. Een derde, en misschien de meest voorkomende, is een cloud-migratie. De bevoegde accounts in een hybride omgeving zijn complexer dan in een puur on-prem situatie, en de oude controles werken vaak niet meer in een wereld van dynamische infrastructuur.

Heb je het idee dat PAM bij je hoort, maar weet je niet waar je moet beginnen? Plan een call. We kijken naar je situatie en geven een eerlijke inschatting van wat haalbaar is en in welke volgorde, zoals we dat met al onze klanten doen, at the speed of business.