Én identitet for mennesker og agenter: hvem får gjøre hva

En leverandørs bankkonto endres i grunndataene en torsdag ettermiddag. Betalingskjøringen på fredag bruker den nye kontoen. Tirsdagen etter ringer leverandøren for å spørre hvor pengene er, og økonomiteamet åpner revisjonsloggen for å se hvem som gjorde endringen.

Loggen sier: INTEGRATION_SVC. Den kontoen tilhører mellomvaren. Gjennom den går nettbutikk-synkroniseringen, lagerkoblingen, et planlagt oppryddingsskript og, siden våren, to agenter som oppdaterer grunndata når et bekreftet dokument sier de skal. Seks prosesser, ett navn, ett passord som er lagret tre steder. Endringen ble gjort av en av dem, på vegne av noen, av en grunn, og posten kan ikke si hvilken, for hvem eller hvorfor.

Dette er ikke et sikkerhetsbrudd. Hver prosess gjorde det den var konfigurert til. Det er et identitetsproblem: virksomheten ga programvaren sin ett felles ansikt, og et felles ansikt kan man ikke stille spørsmål til. I det øyeblikket agenter begynner å handle, mangedobles antallet handlinger det ansiktet utfører, og hver eneste av dem er anonym av konstruksjon.

Hva en delt tjenestekonto skjuler

Aktøren. Seks prosesser bak ett navn betyr at loggen registrerer at noe skjedde, og ikke hva som gjorde det. Et menneskes feil, et skripts bug og en agents feilvurdering ser like ut og rettes på samme måte: sakte.

Oppdragsgiveren. En agent som oppdaterer en leverandør, gjør det fordi et menneskes rolle ba om det, eller fordi en prosess tillot det. Tjenestekontoen bærer ikke spor av den kjeden, så spørsmålet “hvem ble dette gjort for” har heller ikke noe svar.

Omfanget. En tjenestekonto samler opp rettigheter. Hver integrasjon trengte én tabell til, ett endepunkt til, og ingen fjernet dem som ikke lenger brukes. Agenten som ble lagt til i fjor, arvet alle sammen, inkludert retten til å endre en bankkonto den aldri trengte.

Tiden. Kontoen har vært gyldig siden den ble opprettet. Et menneskes tilgang opphører når vedkommende slutter; en delegert oppgave opphører når den er gjort. Den delte kontoen opphører aldri, så en legitimasjon som er lekket én gang, er lekket for godt.

Grensen mellom å lese og å skrive. Kontoen som leser ordrer til en rapport, er den samme som skriver en betalingsfil. Ett kompromittert skript, én feilkonfigurert prompt, og leseveien blir en skrivevei. Hvorfor skrivingen er den farlige halvdelen, argumenteres i en agent som skriver til ERP.

Rettigheter knyttet til tabeller. Databaseroller gir tilgang til en tabell, ikke til en kunde. En agent som får lese ordretabellen, leser hver eneste ordre, også dem for kundegruppen rollen dens aldri skulle se. Skjermbildet pleide å skjule dem; agenten bruker ikke skjermbildet.

Hvordan en agents identitet må se ut

Sitt eget navn. Hver agent er en principal i katalogen, som et menneske og ulikt et passord i en konfigurasjonsfil. Loggen navngir da agenten, og en omstridt endring kan spores til én prosess i stedet for til en pulje på seks.

Delegert fra et menneske eller en rolle. En agent har ikke egne rettigheter; den handler for noen. Innkjøpsagenten handler under innkjøpsrollen, innenfor det den rollen får gjøre, og posten viser agenten og rollen sammen. Slutter mennesket bak rollen, opphører delegeringen med vedkommende.

Omfang som utløper. En delegering gjelder en oppgave, et område og en periode. Å lese åpne fakturaer de neste tretti dagene er et omfang; å lese alt for alltid er en tjenestekonto under et annet navn. Når omfanget utløper, spør agenten igjen, og spørsmålet registreres.

Rettigheter på forretningsobjekter, ikke tabeller. Det er her ontologien gjør seg fortjent til plassen sin. Modellen definerer en kunde, en ordre, en leverandør, en bankkonto og handlingene som finnes på hver av dem: lese, foreslå, endre, godkjenne. En rettighet sier da at serviceagenten får lese reklamasjoner for kundene i én region og foreslå svar, ikke at den får gjøre select fra tre tabeller. Samme regel gjelder for mennesker, så et menneske og en agent i samme rolle ser nøyaktig det samme.

Håndhevet på serveren, lesbar for alle. Rettigheten lever under agenten, i laget som sjekker hver forespørsel, ikke i agentens instruksjoner. En prompt kan ikke gi seg selv tilgang, og et menneske som leser modellen, kan se hva hver agent får gjøre uten å lese kode.

Samme svar for et menneske og en agent. “Hvem gjorde dette, for hvem, på hvilket grunnlag, og hvem godkjente det” besvares på samme måte enten aktøren var en saksbehandler eller en prosess. Kan posten svare for ansatte og ikke for agenter, er agentene et hull i revisjonen, ikke en del av den.

En test du kan gjøre i dag

Åpne revisjonsloggen i ERP- eller regnskapssystemet deres og filtrer den siste måneden på de tekniske kontoene: integrasjonsbrukeren, API-brukeren, alt med “svc”, “sync” eller “system” i navnet. Tell endringene. Ta så fem av dem tilfeldig og prøv å svare, for hver av dem, på hvilken prosess som gjorde endringen og hvilket menneske eller hvilken rolle den ble gjort for.

Hvis dere ikke kan svare i løpet av noen minutter ut fra posten alene, uten å spørre IT-avdelingen, er hver eneste av de endringene anonym. List nå opp prosessene som deler hver tekniske konto, og rettighetene kontoen har. Forskjellen mellom det hver prosess trenger og det kontoen har, er angrepsflaten dere har kjørt med hele tiden, og det er flaten en agent ville arvet fra dag én.

I Hurukan når hver forespørsel serveren med en identitet: et menneske, en agent som handler for et menneske eller en prosess, eller systemet selv. Rettigheter sjekkes der, på serveren, mot rollene og reglene som ontologien definerer på forretningsobjekter, og hver endring registreres med opphavstypen sin, hva som ble endret og på hvis godkjenning. Det er det som gjør en agent ansvarlig i samme setning som en ansatt, og det er grunnlaget i Hurukan, beskrevet i suverenitet er en arkitekturbeslutning.