Offentlig AI-chatbot vs. kundeportal: Adskil identitet og dataadgang sikkert

En chatbot på et offentligt websted må gerne besvare produktspørgsmål, forklare åbningstider eller henvise til den relevante serviceside. Så snart den skal kunne tilgå ordrestatus, kontrakter, fakturaer eller supportsager i kundeportalen, ændrer sig dog ikke kun indholdet. Der opstår en ny sikkerhedsgrænse. En autentificeret AI-chatbot skal adskille identitet, rettighed, session og den konkrete handling helt rent.

Den vigtigste arkitekturbeslutning er derfor ikke: „Hvilken model bruger vi?“ Den er i stedet: „Hvilken information og hvilken handling er tilladt i hvilket tillidsområde?“ Den, der besvarer dette spørgsmål før prompt-designet, reducerer datalækager, forkerte kontotilknytninger og utilsigtede handlinger. Følgende guide er en teknisk og organisatorisk orientering, ikke individuel juridisk rådgivning.

Hvorfor offentlig og autentificeret er to forskellige driftstilstande

I den offentlige chat er personen i første omgang ukendt. Systemet kan højst kende samtale-konteksten, det valgte sprog og teknisk nødvendige sessionsdata. Svar bør derfor begrænse sig til godkendte, alment tilgængelige kilder. En indtastet e-mailadresse, et ordrenummer eller en påstand som „Det er min kontrakt“ er endnu ikke et dokumenteret adgangsbevis.

I kundeportalen eksisterer der derimod en logged-ind session. Men også dér gælder det: Login betyder ikke automatisk, at enhver ressource og enhver handling er tilladt. OWASP Authentication Cheat Sheet skelner mellem autentificering, identitetsvalidering og sessionsstyring. De aktuelle NIST Digital Identity Guidelines, Revision 4 behandler ligeledes identitetsvalidering, autentificering og føderation som selvstændige byggeklodser. For website-teams følger det heraf: Chatten må kun anvende de tillidssignaler, som det omgivende system beviseligt leverer.

Tre zoner i stedet for én alsmægtig chatbot

En robust løsning opdeler viden og værktøjer i mindst tre zoner:

• Offentlig zone: godkendt website-indhold, generelle produktinformationer, processer, kontaktveje og uforpligtende hjælp.
• Autentificeret zone: data og processer, der er knyttet til den loggede konto, en organisation, rolle eller rettighed.
• Særligt beskyttet zone: følsomme ændringer, udbetalinger, aftaleindgåelser, nye leveringsadresser, ændringer i rettigheder eller andre handlinger, der kræver yderligere bekræftelse eller menneskelig kontrol.

Disse zoner bør ikke kun stå i systemprompten. De skal være afspejlet i datakilder, API'er, roller, værktøjsrettigheder og kontrolmekanismer på serversiden. En prompt kan styre adfærd, men er ikke en adgangskontrol. Det samme gælder for RAG: En søgning i både offentlige og private dokumenter i et fælles, ufiltreret indeks skaber en unødvendigt stor angrebsflade.

Autentificering er ikke autorisering

Autentificering besvarer i sin enkle form: „Hvilken digital identitet er logget ind?“ Autorisering besvarer: „Må denne identitet læse præcis dette objekt eller udføre denne funktion?“ Forskellen sløres let i en chat, fordi brugere naturligt formulerer objektnumre: „Vis mig faktura 4711“ eller „Ændr adressen for ordre 815“.

OWASP-anbefalingerne mod IDOR kræver en objektrelateret rettighedskontrol, selvom identifikatorer er svære at gætte. I praksis betyder det: Serveren udleder den aktuelle konto fra den beskyttede session og kontrollerer ved enhver anmodning, om faktura, ordre eller sag hører til dette tilladte datarum. Sprogmodellen må ikke bruge et frit indtastet kunde- eller objekt-ID som tillidsanker.

Hvad den offentlige website-chat må besvare

Til det offentlige område er en positivliste bedre end en lang forbudsliste. Godkendt kan for eksempel være returfrister, leveringsområder, produktegenskaber, vejledninger, generel prislogik eller vejen til login. Ikke-godkendt er individuelle ordrestatusser, kontraktdetaljer, personlige aftaler, interne noter eller oplysningen om, hvorvidt en bestemt konto overhovedet eksisterer.

Selv tilsyneladende harmløse svar kan afsløre information. „Der findes ingen konto med denne e-mailadresse“ bekræfter et kontrolforsøg. Et neutralt svar som „Log ind i kundeportalen for at hente kontorelaterede oplysninger“ holder grænsen stabil. Til håndtering af manipulationsforsøg kræves der desuden beskyttelsesforanstaltninger, som beskrevet i artiklen om prompt injection bei website-chatbots.

Hvad den autentificerede AI-chatbot desuden har brug for

Efter login må assistenten gøre mere, men kun inden for den kontekst, der er fastlagt på serversiden. Relevante indgangsdata er en intern sessionsreference, den tilladte organisation eller tenant, roller samt et snævert defineret funktionsomfang. Rå adgangsdata, adgangskoder, fuldstændige sessionstokens eller unødvendige personfølsomme felter hører ikke hjemme i modelkonteksten.

OWASP Authorization Cheat Sheet anbefaler rettighedskontrol for enhver konkret ressource og funktion. Det betyder for værktøjskald: Det er ikke modellen, der afgør, om en faktura er synlig. Den anmoder en tjeneste om den tilladte information; tjenesten tjekker session, rolle, tenant og objekt igen. Chatten modtager bagefter kun de felter, der er nødvendige for svaret.

Definer data- og værktøjsgrænser i praksis

Læsning og skrivning bør være adskilte værktøjer. Et værktøj som „administrer kundekonto“ er for bredt. Det er bedre med små funktioner som „vis egne åbne ordrer“, „læs status på en tilladt ordre“ eller „forbered supportsag“. Enhver funktion får et minimalt input-schema, en rettighedskontrol på serversiden, gennemskuelige fejlscenarier og et begrænset output.

For RAG anbefales den samme logik: offentlige kilder i et offentligt søgeområde, kontorelaterede dokumenter i et søgeområde, der er filtreret efter tenant og rolle. Filtre oprettes på serversiden ud fra sessionen, ikke ud fra frit formulerede oplysninger i chatten. Ændringer i kilder, roller og godkendelser hører til i en dokumenteret proces; en skabelon findes i artiklen om content governance und change control.

Tag højde for udløb af session, logout og delte enheder

En chatgrænseflade må ikke virke som om, at en rettighed forbliver gyldig på ubestemt tid. OWASP Session Management Cheat Sheet beskriver sessionen som forbindelsen mellem autentificering, HTTP-trafik og adgangskontrol. Udløber sessionen, skal det næste private dataopslag fejle sikkert. Et gammelt svar i den synlige historik må ikke fortolkes som en ny rettighed.

Team bør desuden teste logout, kontoskift, ændring af roller og delte enheder. Private samtalehistorikker må efter et skift ikke vises på den næste konto. Assistenten bør ved en udløbet session tydeligt guide til et nyt login uden at gentage følsomme detaljer fra den forrige session. For logning og analyse gælder dataminimering; artiklen om datensparsamer chatbot-analytics viser passende hændelses- og opbevaringsgrænser.

Følsomme handlinger kræver en særskilt bekræftelse

Et login på portalen er nicht nødvendigvis nok til enhver handling. Hvis chatten ændrer en leveringsadresse, bekræfter en kontrakt oder udløser en betaling, bør systemet kræve en tydeligt genkendelig, handlingsrelateret bekræftelse. OWASP Transaction Authorization Cheat Sheet adskiller login og transaktionsgodkendelse og kræver kontrolmekanismer på serversiden samt en validering af de væsentligste transaktionsdata.

Et sikkert mønster er: Chatten indsamler anmodningen, viser et forståeligt resumé, portalen kontrollerer den aktuelle rettighed og kræver om nødvendigt fornyet autentificering eller en anden faktor. Først derefter udfører en tjeneste på serversiden den præcist bekræftede handling. Ændres destination, beløb eller andre væsentlige data, bortfalder den tidligere godkendelse.

Eksempel: Returnering uden datalækage

En anonym person spørger: „Kan jeg returnere min ordre?“ Den offentlige chat forklarer den generelle returlogik og linker til portalen. Den spørger ikke efter fuldstændig adresse eller betalingsoplysninger. Efter login kan portalchatten liste brugerens egne ordrer, der kan returneres, via et læseværktøj. Vælger personen en ordre, kontrollerer serveren endnu en gang objektrettigheden og de gældende regler.

Til den faktiske returnering genererer et separat handlingsværktøj et resumé. Personen bekræfter varer og afhentningsmulighed i portalens brugerflade. Fejler kontrollen, oplyser chatten ingen interne risikosignaler, men tilbyder et sikkert næste skridt. Er der brug for menneskelig afklaring, følger et kontrolleret Human Handoff med kun den nødvendige, godkendte kontekst.

Testmatrix før go-live

En testmatrix bør ikke kun afprøve „happy paths“. Brug mindst to konti med lignende roller samt adskilte data, og test følgende tilfælde:

• Anonym anmodning om generelle oplysninger og om private kontooplysninger.
• Logged-ind konto A læser sit eget objekt og forsøger derefter ID'et på et objekt fra konto B.
• Udløbet session, logout, kontoskift og fratagelse af roller under en igangværende chat.
• Sprogskift midt i processen uden ændring af datarum eller rettigheder.
• Prompt injection i brugerinput og i hentede dokumenter.
• Nedeperiode på et læseværktøj, timeout og modstridende backend-data.
• Skrivehandling uden bekræftelse, med ændrede data og med udløbet bekræftelse.
• Handoff til et menneske med minimal, gennemskuelig samtalekontekst.

Forventede resultater hører på forhånd til i testen: Hvilket svar er offentligt tilladt? Hvilken HTTP-fejl opstår på serversiden? Hvilken information må være synlig i chatten? Hvilken hændelse logges uden fortroligt indhold? En planlagt degraded mode hjælper, hvis identitets- eller backend-tjenester svigter; hertil findes en særskilt guide til incident response og rollback.

Tjekliste til en robust portalgrænse

• Dokumenter offentlig, autentificeret og særligt beskyttet zone.
• Modeler autentificering, autorisering og transaktionsgodkendelse adskilt.
• Udled konto og tenant fra den sikre session.
• Kontroller objektrettigheder på serversiden ved enhver læsning og skrivning.
• Adskil og filtrer offentlige og private RAG-kilder teknisk.
• Minimer værktøjsrettigheder; adskil læsning og skrivning.
• Tag højde for udløb af session, logout, kontoskift og rolleændringer i chatten.
• Opsummer følsomme handlinger forståeligt og få dem målrettet bekræftet.
• Begræns handoff og logning til de nødvendige data.
• Test horisontale adgangsforsøg reproducerbart med mindst to konti.

En autentificeret AI-chatbot bliver ikke sikker af blot at placeres bag et login. Sikkerhed opstår, når enhver information og enhver handling har en efterprøvbar grænse. Start derfor med zonekortet og testmatrixen, før du tilkobler private datakilder eller skriveværktøjer. På den måde forbliver den offentlige chat hjælpsom og portalchatten handlingsdygtig, uden at blande de to tillidsområder sammen.

Kilder

• NIST SP 800-63, Revision 4: Digital Identity Guidelines
• OWASP Authentication Cheat Sheet
• OWASP Authorization Cheat Sheet
• OWASP Session Management Cheat Sheet
• OWASP Insecure Direct Object Reference Prevention Cheat Sheet
• OWASP Transaction Authorization Cheat Sheet