Vraag een willekeurige organisatie wie toegang heeft tot het financiële systeem, en u krijgt zelden binnen een dag antwoord. Vraag daarna waarom die mensen toegang hebben, en het wordt stil. Dat is geen teken van slordigheid. Het is het voorspelbare gevolg van jarenlang toegang uitdelen zonder een systeem dat bijhoudt waarom.
Identity & Access Management, kortweg IAM, is het geheel aan processen en techniek dat antwoord geeft op vier vragen: wie is iemand, waar mag die persoon bij, waarom is dat zo, en wie heeft dat goedgekeurd. De eerste vraag is techniek. De andere drie zijn organisatie.
Authenticatie is niet hetzelfde als autorisatie
Twee begrippen worden voortdurend door elkaar gehaald, terwijl het onderscheid het fundament van IAM vormt.
Authenticatie beantwoordt de vraag: bent u wie u zegt dat u bent? Een wachtwoord, een vingerafdruk, een code uit een app. Dit is het slot op de voordeur.
Autorisatie beantwoordt de vraag: en wat mag u vervolgens? Welke systemen, welke gegevens, lezen of ook wijzigen. Dit bepaalt welke deuren binnen het gebouw voor u opengaan.
Organisaties investeren doorgaans fors in het eerste en verwaarlozen het tweede. Multifactorauthenticatie wordt uitgerold, en dat is goed — maar als iedereen na het inloggen alsnog bij alles kan, is de winst beperkt. Een aanvaller die één account overneemt, erft dan meteen het volledige rechtenpakket van die medewerker.
De levenscyclus: instroom, doorstroom, uitstroom
Elk account doorloopt drie fasen. Bij twee daarvan gaat het meestal goed.
Instroom
Een nieuwe medewerker begint en heeft toegang nodig. Dit gaat vrijwel altijd goed, om een simpele reden: iemand die niet kan werken, meldt zich. Er is een luide, directe terugkoppeling wanneer dit misgaat.
Uitstroom
Een medewerker vertrekt en de toegang moet stoppen. Dit gaat redelijk, omdat de meeste organisaties een uitdienstprocedure hebben. Toch is dit de fase waar de zichtbaarste incidenten ontstaan: het account van een oud-medewerker dat maanden na vertrek nog actief blijkt. Niemand merkt het, want niemand klaagt over toegang die hij niet meer nodig heeft.
Doorstroom
Hier gaat het structureel mis. Een medewerker verandert van functie of afdeling. De nieuwe rechten worden toegekend — want anders kan zij niet werken — maar de oude worden zelden ingetrokken. Er is immers geen enkel signaal dat daartoe aanzet.
Dit heet rechtenstapeling, en het is het meest onderschatte risico in toegangsbeheer. Een medewerker die in tien jaar drie keer van functie wisselde, heeft vaak de rechten van alle vier de functies. Formeel voldoet zij aan het beleid: elke toekenning is ooit goedgekeurd. Feitelijk heeft zij een rechtenpakket dat niemand bewust zou hebben uitgedeeld.
Waarom rollen helpen, en waarom ze ook misgaan
De gebruikelijke oplossing is rolgebaseerd toegangsbeheer (RBAC): rechten worden niet aan personen toegekend, maar aan rollen. Een rol bundelt de rechten die bij een functie horen. Wie van functie verandert, wisselt van rol — en daarmee vervallen de oude rechten vanzelf.
Het principe is elegant. De uitvoering struikelt meestal over één van twee uitersten:
- Te grof. Er komt één rol "Finance" waar iedereen op de afdeling in valt. De junior medewerker krijgt dezelfde rechten als de controller. Beheersbaar, maar het principe van minimale rechten is losgelaten.
- Te fijn. Er komen honderden rollen, voor elke denkbare combinatie één. Op papier perfect. In de praktijk weet niemand meer welke rol waarvoor dient, en vraagt men bij twijfel gewoon de ruimste aan.
Een werkbaar model zit ertussenin: een beperkt aantal basisrollen die het merendeel van de toegang dekken, aangevuld met losse toekenningen voor uitzonderingen — met een houdbaarheidsdatum.
Toegang die niemand controleert, groeit
Zonder periodieke controle dijt elk rechtenlandschap uit. Toekenningen komen erbij, intrekkingen gebeuren zelden. Daarom hoort bij IAM een terugkerende access review: leidinggevenden krijgen periodiek de vraag of hun medewerkers de toegang die zij hebben ook daadwerkelijk nodig hebben.
Zo'n review is alleen zinvol als de vraag beantwoordbaar is. Een lijst met tweehonderd technische rechtnamen als SAP_FI_DISP_ALL levert één reactie op: alles goedkeuren. Een lijst met begrijpelijke omschrijvingen levert echte beslissingen op. De kwaliteit van uw review staat of valt met de leesbaarheid van uw rollen.
De accounts zonder gezicht
Naast medewerkers bestaan er accounts zonder mens erachter: serviceaccounts, koppelingen tussen systemen, geautomatiseerde processen. Ze vormen in veel omgevingen het grootste risico, om drie redenen die elkaar versterken.
Ze hebben vaak brede rechten, omdat bij de inrichting niemand precies wist wat minimaal nodig was. Ze kennen zelden een eigenaar, want degene die ze aanmaakte is allang vertrokken. En hun wachtwoorden verlopen nooit, omdat een verlopen wachtwoord de koppeling zou breken.
Het resultaat is een account met vergaande rechten dat jarenlang draait, waar niemand verantwoordelijk voor is, en dat op geen enkele uitdiensttlijst voorkomt. Precies wat een aanvaller zoekt.
Waar u kunt beginnen
IAM oplossen is geen project van een paar weken. Maar u hoeft ook niet alles tegelijk aan te pakken. Een verstandige volgorde:
- Breng in kaart wat er is. Welke systemen, welke accounts, welke rechten. Zonder overzicht is elke maatregel een gok.
- Begin bij de hoogste risico's. Beheerdersaccounts en serviceaccounts met brede rechten. Daar is de schade het grootst en het aantal accounts het kleinst.
- Regel uitstroom sluitend. Koppel het vertrek van een medewerker aan het automatisch intrekken van toegang. Dit is de maatregel met de beste verhouding tussen inspanning en resultaat.
- Pak daarna pas rollen aan. Een rollenmodel bouwen zonder de eerste drie stappen is een model op drijfzand.
Goed toegangsbeheer is geen eindtoestand die u een keer bereikt. Het is een proces dat blijft draaien, omdat uw organisatie ook blijft veranderen. De vraag is niet of u ooit klaar bent, maar of u op elk moment kunt uitleggen waarom iemand ergens bij kan.