Én identitet for mennesker og agenter: hvem må hvad

En leverandørs bankkonto ændres i stamdata en torsdag eftermiddag. Betalingskørslen om fredagen bruger den nye konto. Den følgende tirsdag ringer leverandøren for at spørge, hvor pengene er, og økonomiteamet åbner revisionsloggen for at se, hvem der lavede ændringen.

Loggen siger: INTEGRATION_SVC. Den konto tilhører middlewaren. Gennem den kører webshop-synkroniseringen, lager-connectoren, et planlagt oprydningsscript og, siden foråret, to agenter, der opdaterer stamdata, når et bekræftet dokument siger, de skal. Seks processer, ét navn, én adgangskode, der er gemt tre steder. Ændringen blev lavet af en af dem, på vegne af nogen, af en grund, og posten kan ikke sige hvilken, for hvem eller hvorfor.

Det er ikke et sikkerhedsbrud. Hver proces gjorde det, den var konfigureret til. Det er et identitetsproblem: virksomheden gav sin software ét fælles ansigt, og et fælles ansigt kan man ikke stille spørgsmål til. I det øjeblik agenter begynder at handle, mangedobles antallet af handlinger, det ansigt udfører, og hver eneste af dem er anonym af konstruktion.

Hvad en delt servicekonto skjuler

Aktøren. Seks processer bag ét navn betyder, at loggen registrerer, at noget skete, og ikke hvad der gjorde det. Et menneskes fejl, et scripts bug og en agents fejlvurdering ser ens ud og rettes på samme måde: langsomt.

Opdragsgiveren. En agent, der opdaterer en leverandør, gør det, fordi et menneskes rolle bad om det, eller fordi en proces tillod det. Servicekontoen bærer intet spor af den kæde, så spørgsmålet “hvem blev det her gjort for” har heller intet svar.

Omfanget. En servicekonto samler rettigheder. Hver integration havde brug for én tabel mere, ét endpoint mere, og ingen fjernede dem, der ikke længere bruges. Agenten, der blev tilføjet sidste år, arvede dem alle, inklusive retten til at ændre en bankkonto, den aldrig havde brug for.

Tiden. Kontoen har været gyldig, siden den blev oprettet. Et menneskes adgang ophører, når vedkommende stopper; en delegeret opgave ophører, når den er løst. Den delte konto ophører aldrig, så en legitimation, der er lækket én gang, er lækket for altid.

Grænsen mellem at læse og at skrive. Den konto, der læser ordrer til en rapport, er den samme, der skriver en betalingsfil. Ét kompromitteret script, én forkert konfigureret prompt, og læsevejen bliver en skrivevej. Hvorfor skrivningen er den farlige halvdel, argumenteres i en agent der skriver til ERP.

Rettigheder bundet til tabeller. Databaseroller giver adgang til en tabel, ikke til en kunde. En agent, der må læse ordretabellen, læser hver eneste ordre, også dem for den kundegruppe, dens rolle aldrig burde se. Skærmbilledet plejede at skjule dem; agenten bruger ikke skærmbilledet.

Hvordan en agents identitet skal se ud

Sit eget navn. Hver agent er en principal i kataloget, ligesom et menneske og i modsætning til en adgangskode i en konfigurationsfil. Loggen navngiver så agenten, og en omstridt ændring kan spores til én proces frem for til en pulje på seks.

Delegeret fra et menneske eller en rolle. En agent har ikke egne rettigheder; den handler for nogen. Indkøbsagenten handler under indkøbsrollen, inden for det, den rolle må, og posten viser agenten og rollen sammen. Hvis mennesket bag rollen stopper, ophører delegeringen med vedkommende.

Omfang, der udløber. En delegering gælder en opgave, et område og en periode. At læse åbne fakturaer de næste tredive dage er et omfang; at læse alt for evigt er en servicekonto under et andet navn. Når omfanget udløber, spørger agenten igen, og spørgsmålet registreres.

Rettigheder på forretningsobjekter, ikke tabeller. Det er her, ontologien gør sig fortjent til sin plads. Modellen definerer en kunde, en ordre, en leverandør, en bankkonto og de handlinger, der findes på hver af dem: læse, foreslå, ændre, godkende. En rettighed siger så, at serviceagenten må læse reklamationer for kunderne i én region og foreslå svar, ikke at den må lave select fra tre tabeller. Samme regel gælder for mennesker, så et menneske og en agent i samme rolle ser præcis det samme.

Håndhævet på serveren, læsbar for alle. Rettigheden lever under agenten, i det lag, der tjekker hver forespørgsel, ikke i agentens instruktioner. En prompt kan ikke give sig selv adgang, og et menneske, der læser modellen, kan se, hvad hver agent må, uden at læse en linje kode.

Det samme svar for et menneske og en agent. “Hvem gjorde det her, for hvem, på hvilket grundlag, og hvem godkendte det” besvares på samme måde, uanset om aktøren var en medarbejder eller en proces. Hvis posten kan svare for personalet og ikke for agenterne, er agenterne et hul i revisionen, ikke en del af den.

En test du kan lave i dag

Åbn revisionsloggen i jeres ERP- eller økonomisystem, og filtrer den seneste måned på de tekniske konti: integrationsbrugeren, API-brugeren, alt med “svc”, “sync” eller “system” i navnet. Tæl ændringerne. Tag derefter fem af dem tilfældigt, og prøv for hver af dem at svare på, hvilken proces der lavede ændringen, og hvilket menneske eller hvilken rolle den blev lavet for.

Hvis I ikke kan svare inden for få minutter ud fra posten alene, uden at spørge IT-afdelingen, er hver eneste af de ændringer anonym. List nu de processer, der deler hver teknisk konto, og de rettigheder, kontoen har. Forskellen mellem det, hver proces har brug for, og det, kontoen har, er den angrebsflade, I har kørt med hele tiden, og det er den flade, en agent ville arve fra dag ét.

I Hurukan når hver forespørgsel serveren med en identitet: et menneske, en agent, der handler for et menneske eller en proces, eller systemet selv. Rettigheder tjekkes dér, på serveren, mod de roller og regler, som ontologien definerer på forretningsobjekter, og hver ændring registreres med sin ophavstype, hvad der blev ændret, og på hvis godkendelse. Det er det, der gør en agent ansvarlig i samme sætning som en medarbejder, og det er grundlaget i Hurukan, beskrevet i suverænitet er en arkitekturbeslutning.