IAM. Who may do what, and who checks. IAM. Wie wat mag, en wie dat controleert.

Most identities in a company are not people. Service accounts run the backups and the payroll, API keys connect systems, scripts log in on a schedule. They were created by someone who has since left, their passwords never expire because expiring would break the job, and their rights were set generously once so nobody would be called at night. Nobody is paid to look at them, and they outnumber the staff.

Example: a service account called svc_payroll, created in 2016, password unchanged since, member of Domain Admins because the payroll software “needed it” for one installation step years ago. The password sits in a script on a shared drive. Whoever reads that script owns the company. Business impact: the account nobody owns is the account nobody notices being abused, and the first thing an attacker looks for.

De meeste identiteiten in een bedrijf zijn geen mensen. Serviceaccounts draaien de back-ups en de salarisrun, API-sleutels verbinden systemen, scripts loggen volgens schema in. Ze zijn aangemaakt door iemand die inmiddels weg is, hun wachtwoorden verlopen nooit omdat verlopen de taak zou breken, en hun rechten zijn ooit ruim gezet zodat niemand ’s nachts gebeld zou worden. Niemand wordt betaald om ernaar te kijken, en ze zijn talrijker dan het personeel.

Voorbeeld: een serviceaccount met de naam svc_payroll, aangemaakt in 2016, wachtwoord sindsdien ongewijzigd, lid van Domain Admins omdat de salarissoftware dat jaren geleden “nodig had” voor één installatiestap. Het wachtwoord staat in een script op een gedeelde schijf. Wie dat script leest, is eigenaar van het bedrijf. Bedrijfsimpact: het account zonder eigenaar is het account waarvan niemand het misbruik opmerkt, en het eerste waar een aanvaller naar zoekt.

Cloud platforms and business systems come with a fine-grained rights model. Nobody uses it under time pressure. A role gets a wildcard because the precise list was long, and the role is copied to the next team because it “works”. Years later every developer can read every database, the helpdesk can reset the CEO’s password, and nobody remembers deciding any of it.

Example: an AWS IAM policy with "Action": "*", "Resource": "*" attached to the whole developer group; in Entra ID, Global Administrator handed to the service desk because password resets “needed it”. Business impact: one phished developer laptop equals the entire data estate. With narrow roles the same laptop equals one application.

Cloudplatforms en bedrijfssystemen hebben een fijnmazig rechtenmodel. Onder tijdsdruk gebruikt niemand het. Een rol krijgt een wildcard omdat de precieze lijst lang was, en de rol wordt gekopieerd naar het volgende team omdat hij “werkt”. Jaren later kan elke developer elke database lezen, kan de servicedesk het wachtwoord van de CEO resetten, en herinnert niemand zich dat ooit te hebben besloten.

Voorbeeld: een AWS IAM-policy met "Action": "*", "Resource": "*" gekoppeld aan de hele developergroep; in Entra ID de rol Global Administrator uitgedeeld aan de servicedesk omdat wachtwoordresets dat “nodig hadden”. Bedrijfsimpact: één gephishte developerlaptop staat gelijk aan het volledige databestand. Met smalle rollen staat dezelfde laptop gelijk aan één applicatie.

Some rights are harmless alone and dangerous together. Creating a supplier is fine. Releasing a payment is fine. The same account doing both means one person, or one attacker holding that account, can invent a vendor and pay it. Every system allows this unless someone deliberately configures it to say no, and most systems were never asked.

Example: a finance employee moves teams and keeps the “vendor master” role from the old job while gaining “payment release” in the new one. Eighteen months later a phished password is used to create a supplier with a familiar name and a foreign IBAN, and to approve an invoice of €340,000. Both actions are logged, both look legitimate. Business impact: direct financial loss, plus an audit finding that the conflict had been visible in the rights table all along.

Sommige rechten zijn apart onschuldig en samen gevaarlijk. Een leverancier aanmaken is prima. Een betaling vrijgeven is prima. Hetzelfde account dat beide doet, betekent dat één persoon, of één aanvaller met dat account, een leverancier kan verzinnen en betalen. Elk systeem staat dit toe tenzij iemand het bewust instelt om nee te zeggen, en de meeste systemen is dat nooit gevraagd.

Voorbeeld: een medewerker van finance wisselt van team en houdt de rol “leveranciersstamgegevens” uit de oude functie, terwijl hij in de nieuwe “betaling vrijgeven” krijgt. Achttien maanden later wordt met een gephisht wachtwoord een leverancier met een vertrouwde naam en een buitenlands IBAN aangemaakt, en een factuur van € 340.000 goedgekeurd. Beide handelingen staan in het logboek, beide zien er legitiem uit. Bedrijfsimpact: direct financieel verlies, plus een auditbevinding dat het conflict al die tijd zichtbaar was in de rechtentabel.

A team of four uses one administrator account. The password lives in a spreadsheet, a chat thread and a sticky note. When someone leaves, it is not changed, because everyone else would need the new one. When something breaks, or disappears, the log says “admin” did it. Nobody did it. And the intern from last summer can still log in.

Example: a shared admin@ account for the Microsoft 365 tenant, used by IT, an external consultant and a former intern. Multi-factor authentication is switched on, but the code goes to a shared phone in a drawer. When every mailbox is exported to an unknown address at 02:00, the investigation ends at the word “admin”. Business impact: no accountability, no forensic trail, no way to revoke one person, and an insurer asking why the basic rule was not followed.

Een team van vier gebruikt één beheerdersaccount. Het wachtwoord staat in een spreadsheet, een chatgesprek en op een geeltje. Als iemand vertrekt, wordt het niet gewijzigd, want dan moet iedereen het nieuwe hebben. Als er iets stukgaat, of verdwijnt, zegt het logboek dat “admin” het heeft gedaan. Niemand heeft het gedaan. En de stagiair van afgelopen zomer kan nog steeds inloggen.

Voorbeeld: een gedeeld admin@-account voor de Microsoft 365-tenant, gebruikt door IT, een externe consultant en een oud-stagiair. Multifactorauthenticatie staat aan, maar de code komt binnen op een gedeelde telefoon in een la. Als om 02:00 elke mailbox naar een onbekend adres wordt geëxporteerd, eindigt het onderzoek bij het woord “admin”. Bedrijfsimpact: geen verantwoording, geen forensisch spoor, geen manier om één persoon de toegang te ontnemen, en een verzekeraar die vraagt waarom de basisregel niet is gevolgd.