Openbare AI-chatbot vs. klantenportaal: Identiteit en datatoegang veilig scheiden

Een chatbot op een openbare website mag vragen over producten beantwoorden, openingstijden uitleggen of naar de juiste servicepagina verwijzen. Zodra deze in het klantenportaal de bestelstatus, contracten, facturen of supportcases moet inzien, verandert er echter meer dan alleen de inhoud. Er ontstaat een جديدة veiligheidsgrens. Een geauthenticeerde AI-chatbot moet identiteit, autorisatie, sessie en concrete acties strikt van elkaar scheiden.

De belangrijkste architectuurbeslissing luidt daarom niet: „Welk model gebruiken we?“, maar: „Welke informatie en welke actie is in welk vertrouwensdomein toegestaan?“ Wie deze vraag vóór het prompt-design beantwoordt, vermindert datalekken, onjuiste accountkoppelingen en ongewenste acties. De volgende handleiding is een technische en organisatorische oriëntatie, geen individueel juridisch advies.

Waarom openbaar en geauthenticeerd twee verschillende bedrijfsmodi zijn

In een openbare chat is de persoon in eerste instantie onbekend. Het systeem kent hoogstens de gesprekscontext, de gekozen taal en technisch noodzakelijke sessiegegevens. Antwoorden moeten zich daarom beperken tot vrijgegeven, algemeen toegankelijke bronnen. Een ingevoerd e-mailadres, bestelnummer of een bewering als „Dit is mijn contract“ is nog geen autorisatiebewijs.

In het klantenportaal bestaat daarentegen een ingelogde sessie. Maar ook daar geldt: inloggen betekent niet automatisch dat elke bron en elke actie is toegestaan. De OWASP Authentication Cheat Sheet maakt onderscheid tussen authenticatie, identiteitsverificatie en sessiebeheer. De actuele NIST Digital Identity Guidelines, Revision 4 behandelen identiteitsverificatie, authenticatie en federatie eveneens als afzonderlijke bouwstenen. Voor websiteteams volgt hieruit: de chat mag alleen de vertrouwenssignalen gebruiken die het omringende systeem aantoonbaar levert.

Drie zones in plaats van één almachtige chatbot

Een robuuste oplossing verdeelt kennis en tools in minimaal drie zones:

• Openbare zone: vrijgegeven website-inhoud, algemene productinformatie, processen, contactmogelijkheden en vrijblijvende ondersteuning.
• Geauthenticeerde zone: gegevens en processen die gekoppeld zijn aan het ingelogde account, een organisatie, rol of machtiging.
• Extra beschermde zone: gevoelige wijzigingen, uitbetalingen, contractafsluitingen, nieuwe bezorgadressen, rolwijzigingen of andere acties die aanvullende bevestiging of menselijke controle vereisen.

Deze zones moeten niet alleen in de system prompt staan. Ze moeten verankerd zijn in databronnen, API's, rollen, tool-machtigingen en server-side controles. Een prompt kan gedrag sturen, maar is geen toegangscontrole. Hetzelfde geldt voor RAG: een zoekopdracht over openbare en private documenten in een gezamenlijke, ongefilterde index creëert een onnodig groot aanvalsoppervlak.

Authenticatie is geen autorisatie

Authenticatie beantwoordt simpel gezegd: „Welke digitale identiteit is ingelogd?“ Autorisatie beantwoordt: „Mag deze identiteit precies dit object lezen of deze functie uitvoeren?“ Het verschil vervaagt in chats snel, omdat gebruikers objectnummers natuurlijk formuleren: „Laat me factuur 4711 zien“ of „Wijzig het adres voor bestelling 815“.

De OWASP-aanbevelingen tegen IDOR vereisen een objectgerichte autorisatiecontrole, zelfs als id's moeilijk te raden zijn. In de praktijk betekent dit: de server leidt het huidige account af uit de beschermde sessie en controleert bij elk verzoek of de factuur, bestelling of ticket tot dit toegestane datadomein behoort. Het taalmodel mag geen vrij ingevoerd klant- of object-ID als vertrouwensanker overnemen.

Wat de openbare website-chat mag beantwoorden

Voor het openbare gedeelte is een whitelist beter dan een lange lijst met verboden. Vrijgegeven kunnen bijvoorbeeld retourtermijnen, leveringsregio's, productkenmerken, handleidingen, algemene prijslogica of de weg naar de login zijn. Niet vrijgegeven zijn individuele bestelstatussen, contractdetails, persoonlijke afspraken, interne notities of het antwoord op de vraag of een bepaald account überhaupt bestaat.

Ook ogenschijnlijk onschuldige antwoorden kunnen informatie prijsgeven. „Er bestaat geen account met dit e-mailadres“ bevestigt een controlepoging. Een neutraal antwoord zoals „Log in op het klantenportaal om accountgerelateerde informatie op te vragen“ houdt de grens intact. Voor manipulatiepogingen zijn aanvullende beschermingsmaatregelen nodig, zoals beschreven in het artikel Prompt Injection bei Website-Chatbots.

Wat de geauthenticeerde AI-chatbot bovendien nodig heeft

Na de login mag de assistent meer, maar alleen binnen de server-side vastgestelde context. Zinnige invoergegevens zijn een interne sessiereferentie, de toegestane organisatie of tenant, rollen en een nauw gedefinieerde functionaliteit. Ruwe inloggegevens, wachtwoorden, vollständige sessietokens of onnodige persoonsgegevens horen niet thuis in de modelcontext.

De OWASP Authorization Cheat Sheet adviseert autorisatiecontroles voor elke concrete bron en functie. Voor tool-calls betekent dit: niet het model beslist of een factuur zichtbaar is. Het vraagt een dienst om de toegestane informatie; de dienst controleert opnieuw de sessie, rol, tenant en het object. De chat ontvangt vervolgens alleen de velden die nodig zijn voor het antwoord.

Data- en toolgrenzen praktisch afbakenen

Lezen en schrijven moeten gescheiden tools zijn. Een tool „klantenaccount beheren“ is te breed. Beter zijn kleine functies zoals „eigen openstaande bestellingen tonen“, „status van een toegestane bestelling lezen“ of „supportcase voorbereiden“. Elke functie krijgt een minimaal invoerschema, een server-side autorisatiecontrole, duidelijke foutscenario's en een beperkte uitvoer.

Voor RAG wordt dezelfde logica aanbevolen: openbare bronnen in een openbare zoekruimte, accountgerelateerde documenten in een tenant- en rolgefilterde zoekruimte. Filters worden server-side opgesteld uit de sessie, niet uit vrij geformuleerde chat-invoer. Wijzigingen in bronnen, rollen en goedkeuringen horen thuis in een gedocumenteerd proces; een template hiervoor biedt het artikel over Content Governance und Change Control.

Rekening houden met sessieverloop, uitloggen en gedeelde apparaten

Een chatinterface mag niet de indruk wekken dat een autorisatie onbeperkt geldig blijft. De OWASP Session Management Cheat Sheet beschrijft de sessie als de verbinding tussen authenticatie, HTTP-verkeer en toegangscontrole. Verloopt de sessie, dan moet het volgende ophalen van privégegevens veilig mislukken. Een oud antwoord in de zichtbare geschiedenis mag niet als nieuwe autorisatie worden geïnterpreteerd.

Teams moeten bovendien uitloggen, accountwissels, rolwijzigingen en gedeelde apparaten testen. Private gespreksgeschiedenissen mogen na een wissel niet bij het volgende account verschijnen. De assistent moet bij een verlopen sessie duidelijk naar een hernieuwde login leiden, zonder gevoelige details uit de vorige sessie te herhalen. Voor logging en analyse geldt dataminimalisatie; het artikel over datensparsamer Chatbot-Analytics toont passende event- en bewaargrenzen.

Gevoelige acties vereisen een eigen bevestiging

Inloggen op het portaal is niet per se voldoende voor elke actie. Als de chat een bezorgadres wijzigt, een contract bevestigt of een betaling in gang zet, moet het systeem een duidelijk herkenbare, actiegerichte bevestiging vragen. De OWASP Transaction Authorization Cheat Sheet scheidt inloggen van transactiegoedkeuring en vereist server-side controles en een controle van de essentiële transactiegegevens.

Een veilig patroon luidt: de chat verzamelt het verzoek, toont een duidelijke samenvatting, het portaal controleert de huidige autorisatie en vraagt zo nodig om hernieuwde authenticatie of een tweede factor. Pas daarna voert een server-side dienst de exact bevestigde actie uit. Veranderen het doel, het bedrag of andere essentiële gegevens, dan vervalt de eerdere goedkeuring.

Voorbeeld: Retourneren zonder datalek

Een anoniem persoon vraagt: „Kan ik mijn bestelling retourneren?“ De openbare chat legt de algemene retourlogica uit en linkt naar het portaal. De chat vraagt niet om een volledig adres of betalingsgegevens. Na het inloggen kan de portaalchat de eigen, te retourneren bestellingen tonen via een lees-tool. Kiest de persoon een bestelling, dan controleert de server nogmaals de objectautorisatie en de geldende regels.

Voor de daadwerkelijke retourzending genereert een afzonderlijke actietool een samenvatting. De persoon bevestigt de artikelen en de ophaaloptie in de portaalinterface. Mislukt de controle, dan noemt de chat geen interne risicosignalen, maar biedt een veilige volgende stap. Is menselijke tussenkomst nodig, dan volgt een gecontroleerde Human Handoff met alleen de noodzakelijke, vrijgegeven context.

Testmatrix vóór de go-live

Een testmatrix moet niet alleen happy paths testen. Gebruik minimaal twee accounts met vergelijkbare rollen en gescheiden gegevens, en test de volgende scenario's:

• Anonieme aanvraag voor algemene informatie en voor private accountgegevens.
• Ingelogd account A leest een eigen object en probeert vervolgens de ID van een object van account B.
• Verlopen sessie, uitloggen, accountwissel en intrekken van rollen tijdens een lopende chat.
• Taalwissel halverwege het proces, zonder dat de dataruimte of autorisatie verandert.
• Prompt Injection in gebruikersinvoer en in opgehaalde documenten.
• Uitval van een lees-tool, timeout en tegenstrijdige backend-gegevens.
• Schrijfactie zonder bevestiging, met gewijzigde gegevens en met een verlopen bevestiging.
• Handoff naar een medewerker met minimale, begrijpelijke gesprekscontext.

Verwachte resultaten horen vooraf in de test te staan: Welk antwoord is openbaar toegestaan? Welke HTTP-fout ontstaat server-side? Welke informatie mag in de chat zichtbaar zijn? Welk event wordt zonder vertrouwelijke inhoud gelogd? Een geplande Degraded Mode helpt wanneer identiteits- of backend-diensten uitvallen; daarvoor is er een eigen Incident-Response- und Rollback-Leitfaden.

Checklist voor een robuuste portaalgrens

• Openbare, geauthenticeerde en extra beschermde zone documenteren.
• Authenticatie, autorisatie en transactiegoedkeuring gescheiden modelleren.
• Account en tenant afleiden uit de veilige sessie.
• Objectautorisatie bij elke lees- en schrijfactie server-side controleren.
• Openbare en private RAG-bronnen technisch scheiden en filteren.
• Tool-machtigingen minimaal afbakenen; lezen en schrijven scheiden.
• Rekening houden met sessieverloop, uitloggen, accountwissels en rolwijzigingen in de chat.
• Gevoelige acties duidelijk samenvatten en gericht laten bevestigen.
• Handoff en logging beperken tot de noodzakelijke gegevens.
• Horizontale toegangspogingen reproduceerbaar testen met minimaal twee accounts.

Een geauthenticeerde AI-chatbot wordt niet veilig door simpelweg achter een login te staan. Veiligheid ontstaat wanneer elke informatie en elke actie een controleerbare grens heeft. Begin daarom met de zonemap en de testmatrix voordat u private databronnen of schrijvende tools koppelt. Zo blijft de openbare chat nuttig en de portaalchat slagvaardig, zonder beide vertrouwensdomeinen door elkaar te halen.

Bronnen

• 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