De term ‘PAM’ wordt door verschillende personen, en door verschillende bedrijven, op een andere manier uitgelegd. Over de ‘P’ en ‘M’ is iedereen het wel eens: ‘Privileged’ en ‘Management’. Maar de waarde en betekenis van de ‘A’ wil nogal eens verschillen: ‘Account’, ‘Access’, ‘Authorisation’, … Deze zijn alle correct en logisch, maar het is handig om - voordat een dure tool gekocht wordt - eerst na te denken over wat voor de organisatie nodig is.
Het idee van PAM
Het idee achter PAM is om risico’s voor de organisatie te beperken door te zorgen voor een aantal zaken:
- Het toekennen van risicovolle rechten op het moment dat deze voor een bepaalde taak noodzakelijk zijn en het intrekken als de taak is uitgevoerd.
- Het vastleggen van de reden van de uitgifte van risicovolle rechten, zodat achteraf te achterhalen is waarom het recht is uitgegeven.
- Het vastleggen van transacties die uitgevoerd zijn met risicovolle rechten, zodat achteraf te achterhalen is wie wat wanneer gedaan heeft.
De veiligheid wordt hierdoor verhoogd omdat de gebruiker zich telkens terdege bewust is dat er gebruik wordt gemaakt van een risico-recht en weet dat achteraf te achterhalen is wat ermee is gedaan. Door het gebruik van autorisaties op deze wijze strikt te bewaken is het mogelijk direct inzicht te krijgen in misbruik.
PUM, PIM en PRM
Er zijn in grote lijnen drie gezichtspunten waarop je naar PAM kan kijken:
- Privileged User Management (PUM)
- Privileged Identity Management (PIM)
- Privileged Rights Management (PRM)
PUM
Privileged User Management richt zich op de personen die door hun privileges een verhoogd risico voor de organisatie betekenen. Dit kan zijn omdat deze personen (privileged users, PU’s) veel rechten hebben of combinaties van rechten die risicovol zijn, terwijl de rechten op zich niet risicovol zijn. Een goed voorbeeld hiervan is Nick Leeson – die door een combinatie van op zich onschuldige rechten in staat was een bank ten val te brengen.
PIM
Privileged Identity Management richt zich op digitale identiteiten, veelal accounts, met hoge rechten (Privileged Identities, PI’s). Meest voorkomende voorbeeld hiervan zijn de beheeraccounts. Deze hebben in zich vele risicovolle autorisaties gecombineerd. Andere PI’s die niet moeten worden vergeten zijn:
- Functionele systeemaccounts – accounts die onderling tussen systemen worden gebruikt.
- Leveranciersaccounts – accounts die door externe beheerpartijen worden gebruikt om toegang te krijgen tot hun beheerobjecten.
PRM
Privileged Rights Management zou beter Privileged Authorisation Management heten, maar dan komt die verwarrende ‘A’ weer terug. PRM richt zich op de autorisaties in applicaties welke een hoog risico met zich mee brengen.
Waarom PRM?
PRM is de strengste vorm van PAM. Door op autorisatieniveau risicovolle rechten uit te geven en in te trekken wordt verzekerd dat alleen die rechten beschikbaar zijn die nodig zijn voor de taak. Zodra deze reden niet meer actueel is wordt dit recht weer ingetrokken. Het grootste voordeel is dat alleen de rechten worden uitgegeven welke werkelijk nodig zijn, dus de kans op vergissingen en misbruik wordt aanzienlijk beperkt. Een nadeel is dat PRM een administratieve organisatie vergt die snel en accuraat deze rechten kan uitgeven en intrekken. Met name in geval van verstoringen en calamiteiten kan zo’n werkwijze de snelheid van handelen negatief beïnvloeden.
Wanneer PIM?
PIM geeft een lager veiligheidsniveau, maar een hogere snelheid. Door risicovolle rechten te bundelen in Privileged Identities kunnen, in plaats van voor elke taak te bepalen welke rechten nodig zijn, veel voorkomende combinaties in een Privileged Identity worden gebundeld. Hierdoor wordt het bepalen van welke toegang een persoon nodig heeft voor een taak eenvoudiger, omdat de keuze kleiner is. Een voorbeeld is een PI met de rechten die nodig zijn voor een bepaalde reguliere onderhoudstaak. PI’s zouden altijd functioneel moeten zijn, persoonlijke PI’s moeten worden voorkomen. Het heeft geen toegevoegde waarde om identiteiten met een hoge privileges permanent aan één persoon te koppelen. Het resultaat zal zijn dat elke beheerder een eigen persoonlijk PI heeft, waaraan een heel diverse set aan rechten is toegekend, een deel ‘omdat zij dat een keertje nodig had’. Het bewaken en beheren van deze persoonlijke PI’s is een onnodig zware belasting voor de administratieve organisatie en risicovolle combinaties zijn niet uitgesloten.
En PUM dan?
Om het stapelen van op zich onschuldige rechten tot een risicovolle combinatie te voorkomen moet inzichtelijk worden gemaakt wat de risicovolle combinaties zijn en welke tegenmaatregelen van toepassing zijn. Dergelijke controles en analyses kunnen voortkomen uit het reguliere IAM-proces. Regels voor functiescheiding en de risico-inschatting van bepaalde ‘gewone’ rechten worden daarin vastgelegd zodat de informatie in het IAM-systeem kan worden geanalyseerd en deze PU’s in zicht komen. Wat, en of, daar iets mee gedaan moet worden is een menselijke beslissing en zal per situatie verschillen.
Tot slot
Zoals bij elk project binnen IAM (en daar buiten) is het van belang om vooraf goed te definiëren wat de organisatie wil bereiken en waar haar risico’s liggen. Met dat helder in beeld kan gekeken worden wat er aan PAM gedaan dient te worden, en of dat met PUM, PIM of PRM wordt gerealiseerd.
©Steven van der Linden, maart 2020
