PAM zonder PAM

Veel organisaties zijn bezig met het beter inrichten van het beheer van hun risicovolle rechten en de accounts die daar gebruik van maken. Vaak richten ze zich hierbij in eerste instantie op de beheeraccounts van leveranciers en de beheeraccounts van de eigen beheerders.



Niet zelden wordt er snel gekeken naar PAM-tooling. Dit is niet vreemd, omdat de leveranciers van PAM-functionaliteit adverteren dat ‘hun’ tool alle PAM-problemen oplossen. Dit is niet geheel waar. Veelal kunnen PAM-tools ondersteunen bij het versterken van de veiligheid en controleerbaarheid van risicovolle accounts, maar er is veel voorwerk te doen voordat een gespecialiseerd PAM-tool significante toegevoegde waarde gaat leveren.

 

Tussen het besef dat je organisatie een risico loopt vanwege ongecontroleerde risicovolle rechten en de aanschaf van een PAM-tool zijn allerlei activiteiten uit te voeren die de veiligheid verhogen en er tevens voor zorgen dat het PAM-tool dat uiteindelijk wordt aangeschaft ook aansluit bij de organisatie.

 

Boekjeswijsheid zal zeggen dat er moet worden begonnen met beleid en risicoanalyse. Dat is een mooi startpunt, maar dat leidt vaak tot algemeenheden en open deuren. Deze moeten zeker vastgelegd worden, maar terwijl de staf daarmee bezig is kunnen de werkers alvast veel werk verzetten.

 

Een goede eerste stap is om per systeem vast te leggen over welke risicovolle rechten het nou eigenlijk gaat en wie daar allemaal toegang toe heeft. De meeste systeembeheerders zijn prima in staat om zulke overzichten voor ‘hun’ systeem op te leveren. Als die informatie op een inzichtelijke manier wordt vastgelegd – bijvoorbeeld in een autorisatiematrix – dan kan dat gebruikt worden om de systeemeigenaren te laten nadenken of dit is wat zij ook willen, of het mag van wet- en regelgeving en of het wel nodig is. Veelal leidt zo’n actie tot het opruimen van talloze niet meer gebruikte accounts en het opschonen van vele overvolle beheerdersaccounts.

 

Een andere stap is het identificeren van de gebruikers en/of eigenaars voor alle andere risicovolle accounts. De persoonlijke beheeraccounts zijn meestal makkelijk te herleiden naar de gebruiker ervan. Maar voor generieke beheeraccounts (bijvoorbeeld domain admins): is daarvan bekend wie er allemaal gebruik van maakt, en kan maken, en is er één eigenaar die daar verantwoording over neemt? Iets vergelijkbaars geldt voor de serviceaccounts. Is bekend welke er zijn, wat die doen en wie ervoor verantwoordelijk is? Ook deze inventarisaties zullen leiden tot opschoning en rationalisaties.

 

Als de organisatie al een IAM-oplossing heeft kan die prima gebruikt worden om deze bijzondere accounts in op te nemen. Het grote voordeel is dat ze dan gekoppeld worden aan de identiteiten van de gebruikers en/of eigenaren. Als met zo’n gekoppeld persoon iets gebeurt – bijvoorbeeld vertrek – worden automatisch ook de juiste acties voor de aan die persoon gekoppelde beheer- of serviceaccounts uitgevoerd. Denk bijvoorbeeld aan het intrekken van persoonlijke beheeraccounts of het wijzigen van wachtwoorden van generieke beheeraccounts. Ook kan gebruik worden gemaakt van de aanvraag-, beoordelings- en controleprocessen die reeds zijn ingericht voor ‘gewone’ rechten.

 

Natuurlijk, een PAM-oplossing biedt allerlei features als JIT-credentials en session replay die er prachtig uitzien in demonstraties. Maar eerst de basis op orde brengen is altijd een goed idee voordat je een duur tool aanschaft. Het is ook slim om eerst het zandpad naar je huis te bestraten voordat je een Maserati koopt.