Een identiteit voor mensen en agents: wie wat mag doen

Op een donderdagmiddag verandert het bankrekeningnummer van een leverancier in de stamgegevens. De betaalrun op vrijdag gebruikt de nieuwe rekening. De dinsdag erna belt de leverancier om te vragen waar het geld blijft, en het financiële team opent het auditlog om te zien wie de wijziging heeft gemaakt.

Het log zegt: INTEGRATION_SVC. Dat account is van de middleware. Daar lopen de webshopsync, de magazijnconnector, een gepland opschoonscript en, sinds het voorjaar, twee agents doorheen die stamgegevens bijwerken wanneer een bevestigd document zegt dat het moet. Zes processen, een naam, een wachtwoord dat op drie plekken is opgeslagen. De wijziging is gemaakt door een van hen, namens iemand, om een reden, en het record kan niet zeggen welke, voor wie of waarom.

Dit is geen beveiligingsincident. Elk proces deed waarvoor het was geconfigureerd. Het is een identiteitsprobleem: het bedrijf gaf zijn software een gedeeld gezicht, en aan een gedeeld gezicht kun je geen vragen stellen. Zodra agents gaan handelen, vermenigvuldigt het aantal acties van dat gezicht, en elk ervan is anoniem van ontwerp.

Wat een gedeeld serviceaccount verbergt

De actor. Zes processen achter een naam betekent dat het log vastlegt dat er iets is gebeurd en niet wat het deed. De fout van een mens, de bug van een script en de misrekening van een agent zien er identiek uit en worden op dezelfde manier gecorrigeerd: traag.

De opdrachtgever. Een agent die een leverancier bijwerkt, doet dat omdat de rol van een mens erom vroeg of omdat een proces het toestond. Het serviceaccount draagt geen spoor van die keten, dus ook de vraag “voor wie is dit gedaan” heeft geen antwoord.

De reikwijdte. Een serviceaccount stapelt rechten op. Elke integratie had nog een tabel nodig, nog een endpoint, en niemand haalde weg wat niet meer wordt gebruikt. De agent die vorig jaar werd toegevoegd, erfde ze allemaal, inclusief het recht om een bankrekening te wijzigen dat hij nooit nodig had.

De tijd. Het account is geldig sinds het werd aangemaakt. De toegang van een mens eindigt bij vertrek; een gedelegeerde taak eindigt als ze klaar is. Het gedeelde account eindigt nooit, dus een credential die een keer is gelekt, is voorgoed gelekt.

De grens tussen lezen en schrijven. Het account dat orders leest voor een rapport is hetzelfde dat een betaalbestand schrijft. Een gecompromitteerd script, een verkeerd geconfigureerde prompt, en het leespad wordt een schrijfpad. Waarom het schrijven de gevaarlijke helft is, wordt beargumenteerd in een agent die naar het ERP schrijft.

Rechten gekoppeld aan tabellen. Databaserollen geven toegang tot een tabel, niet tot een klant. Een agent die de ordertabel mag lezen, leest elke order, inclusief die van de klantgroep die zijn rol nooit zou mogen zien. Het scherm verborg ze vroeger; de agent gebruikt het scherm niet.

Hoe de identiteit van een agent eruit moet zien

Een eigen naam. Elke agent is een principal in de directory, zoals een mens en anders dan een wachtwoord in een configuratiebestand. Het log noemt dan de agent, en een betwiste wijziging is terug te voeren op een proces in plaats van op een pool van zes.

Gedelegeerd door een mens of een rol. Een agent heeft geen eigen rechten; hij handelt voor iemand. De inkoopagent handelt onder de inkooprol, binnen wat die rol mag, en het record toont de agent en de rol samen. Vertrekt de mens achter de rol, dan eindigt de delegatie met hem.

Reikwijdtes die verlopen. Een delegatie geldt voor een taak, een domein en een periode. Openstaande facturen lezen gedurende de komende dertig dagen is een reikwijdte; alles voor altijd lezen is een serviceaccount onder een andere naam. Verloopt de reikwijdte, dan vraagt de agent opnieuw, en het vragen wordt vastgelegd.

Rechten op bedrijfsobjecten, niet op tabellen. Hier verdient de ontologie haar plaats. Het model definieert een klant, een order, een leverancier, een bankrekening, en de acties die op elk bestaan: lezen, voorstellen, wijzigen, goedkeuren. Een recht zegt dan dat de serviceagent klachten van de klanten van een regio mag lezen en antwoorden mag voorstellen, niet dat hij uit drie tabellen mag selecteren. Dezelfde regel geldt voor mensen, zodat een mens en een agent in dezelfde rol precies hetzelfde zien.

Afgedwongen op de server, leesbaar voor iedereen. Het recht leeft onder de agent, in de laag die elk verzoek controleert, niet in de instructies van de agent. Een prompt kan zichzelf geen toegang geven, en een mens die het model leest, ziet wat elke agent mag zonder code te lezen.

Hetzelfde antwoord voor een mens en een agent. “Wie deed dit, voor wie, op welk bewijs, en wie keurde het goed” wordt op dezelfde manier beantwoord, of de actor nu een medewerker of een proces was. Als het record dat wel voor personeel kan beantwoorden en niet voor agents, zijn agents een gat in de audit, geen onderdeel ervan.

Een test die u vandaag kunt doen

Open het auditlog van uw ERP of uw boekhoudprogramma en filter de afgelopen maand op de technische accounts: de integratiegebruiker, de API-gebruiker, alles met “svc”, “sync” of “system” in de naam. Tel de wijzigingen. Neem er dan vijf willekeurig uit en probeer voor elk te beantwoorden welk proces de wijziging maakte en voor welke mens of rol dat gebeurde.

Kunt u dat niet binnen een paar minuten beantwoorden vanuit het record alleen, zonder het IT-team te vragen, dan is elk van die wijzigingen anoniem. Maak nu een lijst van de processen die elk technisch account delen en van de rechten die het account heeft. Het verschil tussen wat elk proces nodig heeft en wat het account bezit, is het aanvalsoppervlak waarmee u al die tijd hebt gedraaid, en het is het oppervlak dat een agent op dag een zou erven.

In Hurukan bereikt elk verzoek de server met een identiteit: een mens, een agent die handelt voor een mens of een proces, of het systeem zelf. Rechten worden daar gecontroleerd, op de server, tegen de rollen en regels die de ontologie op bedrijfsobjecten definieert, en elke wijziging wordt vastgelegd met het type auteur, wat er veranderde en op wiens goedkeuring. Dat maakt een agent in dezelfde zin aanspreekbaar als een medewerker, en het is de basislaag van Hurukan, beschreven in soevereiniteit is een architectuurkeuze.