Waarom IAM misschien wel het gevaarlijkste deel van je cloud is

Vraag iemand waar het risico in de cloud zit, en je krijgt meestal dezelfde antwoorden: blootgestelde databases, verkeerd ingestelde storage buckets, misschien een server die open aan het internet hangt. Dat zijn de dingen waar mensen screenshots van maken, postmortems over schrijven en securitypresentaties mee vullen. Het is alleen niet waar de meeste interessante problemen vandaan komen.

Kijk je lang genoeg naar echte systemen, dan begin je een ander patroon te zien. Er gaat zelden iets mis doordat iemand zich als in een film door lagen infrastructuur heen hackt. Veel vaker was de toegang er gewoon al. Alleen… iets ruimer dan iemand doorhad. Dat is IAM.

Het ongemakkelijke aan identityproblemen is dat vanuit het systeem gezien alles precies werkt zoals bedoeld. Een rol mag lezen uit een storage bucket. Hij leest uit die bucket. Een service account mag een job starten. Hij start die job. Geen rode vlag, geen duidelijk “dit hoort niet”-moment. Prima, tot het dat niet meer is.

Want zodra een identity meer toegang heeft dan zou moeten, hoef je niets kapot te maken. Je hoeft alleen te gebruiken wat er al ligt. Dat is een heel ander soort falen. Stiller, lastiger op te merken, en vaak veel krachtiger. Het verschil tussen een deur forceren en ontdekken dat hij nooit op slot zat.

Niemand begint met het plan om een zooitje van IAM te maken. Meestal start het netjes. Een paar rollen, duidelijke grenzen, misschien zelfs een doordachte naamgeving waardoor iedereen het gevoel heeft dat het onder controle is. En dan komt de werkelijkheid langs. Een nieuwe service heeft toegang nodig, en wel nu. Iemand zet er een recht bij en houdt zichzelf voor dat hij het later opruimt. Een ander team koppelt iets en vraagt om ruimere rechten “gewoon om het werkend te krijgen”. Een tijdelijke oplossing wordt permanent, omdat er niets stukgaat.

Er gaan weken voorbij. Dan maanden. Op een gegeven moment weet niemand meer precies wat een bepaalde rol eigenlijk allemaal mag, maar het werkt al die tijd prima, dus niemand staat te trappelen om eraan te zitten. Zo groeit IAM. Niet door grote fouten, maar door kleine, redelijke beslissingen die zich stilletjes opstapelen.

Bij infrastructuur is risico meestal zichtbaar. Hangt een database open, dan kun je ernaar wijzen en zeggen: “Dat deugt niet.” Bij identity is het abstracter.

Eén rol mag misschien ergens data lezen, ergens anders schrijven, en in een derde systeem processen starten. Op papier lijken die rechten los van elkaar te staan. In de praktijk laten ze zich aan elkaar rijgen op manieren die je niet ziet, tenzij je er gericht naar op zoek gaat. En daar heeft niemand zin in.

Zo ontstaan er onzichtbare verbindingen, waarbij toegang op de ene plek stilletjes gedrag op een andere plek ontsluit. Van bovenaf ziet alles er nog netjes gescheiden uit, maar eronder is het net iets… meer verbonden dan je zou verwachten.

Dit is het stuk dat mensen verrast als ze er voor het eerst in duiken. Mensen zijn niet de hoofdrolspelers in je cloudomgeving. Services zijn dat.

API's die API's aanroepen, achtergrondjobs die data verplaatsen, pipelines die om 2 uur 's nachts iets uitrollen — dat draait allemaal op identities. Keys, tokens, rollen, service accounts. Hoe het platform ze ook noemt, ze dienen hetzelfde doel: het ene stuk van het systeem met het andere laten praten.

En ze stapelen zich snel op. Je maakt er een voor een nieuwe service, nog een voor een pipeline, en een paar extra voor koppelingen. Ze werken, dus je gaat verder. Niemand logt als hen in, niemand klaagt over hun rechten, en er wordt zelden naar omgekeken tenzij er iets stukgaat.

Wat betekent dat ze blijven rondhangen met precies de toegang die ze ooit kregen — plus een beetje extra, voor de zekerheid.

Op een gegeven moment oppert iemand om IAM te auditen. Klinkt overzichtelijk: rollen op een rij, rechten nalopen, te ruime dingen aanhalen. En dan open je de daadwerkelijke policies. Ze liggen verspreid over verschillende services, sommige erven rechten van andere, sommige bevatten voorwaarden die alleen in bepaalde situaties gelden. Een rol die er op het eerste gezicht simpel uitziet, blijkt verrassend ver te reiken zodra je hem uitpluist. Je kúnt het absoluut doen. Het kost alleen tijd, geduld en een flinke bereidheid om dingen ter discussie te stellen die al maanden “prima werken”. Precies waarom het minder vaak gebeurt dan zou moeten.

Over least privilege is iedereen het eens. Het is zo'n principe dat zo redelijk klinkt dat het nauwelijks uitleg behoeft. Geef services alleen de toegang die ze nodig hebben. Niet meer.

In de praktijk wordt het een soort onderhandeling. Je weet niet altijd precies wat een service nodig heeft, zeker in het begin niet. Strakke rechten breken dingen op manieren die lastig te debuggen zijn. Deadlines laten weinig ruimte voor uitproberen. Dus worden de rechten ruimer gezet, voor de zekerheid.

En zodra het werkt, heeft niemand haast om er nog eens naar te kijken. Zo verandert “precies genoeg” gaandeweg in “meer dan nodig”, en dat verschil valt niet altijd op.

AI-tools beginnen te helpen bij IAM. Ze stellen policies voor, leggen configuraties uit en maken het geheel wat minder ondoorzichtig. Dat is nuttig.

Maar ze maken het ook makkelijker om iets te genereren dat er correct uitziet en dan door te gaan. Let je niet op, dan houd je policies over die het probleem technisch oplossen maar nog steeds ruimere toegang geven dan bedoeld — wat, eerlijk gezegd, precies is wat mensen al deden. Alleen nu sneller. Het kernprobleem verdwijnt dus niet. Het schaalt alleen wat efficiënter.

Er is geen net antwoord in de trant van “doe deze drie dingen en je bent veilig”. Zo werkt IAM niet.

Wat wél helpt, gaat minder over tools en meer over gewoontes.

Kortlevende credentials bijvoorbeeld maken verschil — niet omdat ze perfect zijn, maar omdat ze bekorten hoelang een fout kan blijven bestaan. Strakkere rollen met een duidelijk doel helpen ook, ook al voelt het onderhoud in het begin licht irritant. Die irritatie is meestal het signaal dat je grenzen hun werk doen.

Iets wat beter blijkt te werken dan grote audits: klein en continu opruimen. In plaats van te proberen alles in één klap te repareren (wat nooit gebeurt), staan teams die rechten behandelen als iets waar je regelmatig naar terugkeert er structureel beter voor. Niet perfect, maar wel te overzien.

En misschien wel de grootste omslag: behandel IAM als onderdeel van je systeemontwerp, niet als iets wat je aan het eind even instelt. Is toegang een bijzaak, dan zie je dat terug.

IAM-problemen komen zelden voort uit gebrek aan kennis. De meeste teams weten prima hoe “goed” eruitziet. Least privilege, roteren, heldere grenzen — dat is allemaal bekend terrein. Het probleem is dat die dingen tijd kosten, en dat tijd altijd onder druk staat. Dus worden beslissingen richting snelheid genomen, en duiken de gevolgen later op, op manieren die lastig naar één moment terug te leiden zijn.

Infrastructuurstoringen zijn luidruchtig. Er valt iets om, alarmen gaan af, mensen springen erbovenop. Identityproblemen zijn stiller: alles blijft werken, misschien net iets té goed. Dat is wat IAM lastig maakt. Niet dat het fragiel is, maar dat je makkelijk aanneemt dat het wel goed zit.

Als je één ding meeneemt, dan dit: de meeste systemen worden gecompromitteerd doordat iemand meer toegang had dan nodig — en niemand het merkte.