Öffentlicher KI-Chatbot vs. Kundenportal: Identität und Datenzugriff sicher trennen

Ein Chatbot auf einer öffentlichen Website darf Produktfragen beantworten, Öffnungszeiten erklären oder zur passenden Serviceseite führen. Sobald er im Kundenportal Bestellstatus, Verträge, Rechnungen oder Supportfälle einsehen soll, ändert sich jedoch nicht nur der Inhalt. Es entsteht eine neue Sicherheitsgrenze. Ein authentifizierter KI-Chatbot muss Identität, Berechtigung, Sitzung und konkrete Aktion sauber voneinander trennen.

Die wichtigste Architekturentscheidung lautet deshalb nicht: „Welches Modell verwenden wir?“ Sie lautet: „Welche Information und welche Aktion ist in welchem Vertrauensbereich erlaubt?“ Wer diese Frage vor dem Prompt-Design beantwortet, reduziert Datenlecks, falsche Kontozuordnungen und ungewollte Aktionen. Der folgende Leitfaden ist eine technische und organisatorische Orientierung, keine individuelle Rechtsberatung.

Warum öffentlich und authentifiziert zwei Betriebsarten sind

Im öffentlichen Chat ist die Person zunächst unbekannt. Das System kann höchstens den Gesprächskontext, die gewählte Sprache und technisch notwendige Sitzungsdaten kennen. Antworten sollten sich deshalb auf freigegebene, allgemein zugängliche Quellen beschränken. Eine eingegebene E-Mail-Adresse, Bestellnummer oder Behauptung wie „Das ist mein Vertrag“ ist noch kein Berechtigungsnachweis.

Im Kundenportal existiert dagegen eine angemeldete Sitzung. Aber auch dort gilt: Anmeldung bedeutet nicht automatisch, dass jede Ressource und jede Aktion erlaubt ist. Die OWASP Authentication Cheat Sheet unterscheidet Authentifizierung, Identitätsprüfung und Sitzungsverwaltung. Die aktuellen NIST Digital Identity Guidelines, Revision 4 behandeln Identitätsprüfung, Authentifizierung und Föderation ebenfalls als eigene Bausteine. Für Website-Teams folgt daraus: Der Chat darf nur die Vertrauenssignale verwenden, die das umgebende System nachweisbar liefert.

Drei Zonen statt eines allmächtigen Chatbots

Eine robuste Lösung teilt Wissen und Werkzeuge mindestens in drei Zonen:

• Öffentliche Zone: freigegebene Website-Inhalte, allgemeine Produktinformationen, Prozesse, Kontaktwege und unverbindliche Hilfestellung.
• Authentifizierte Zone: Daten und Vorgänge, die an das angemeldete Konto, eine Organisation, Rolle oder Berechtigung gebunden sind.
• Besonders geschützte Zone: sensible Änderungen, Auszahlungen, Vertragsabschlüsse, neue Zustelladressen, Berechtigungswechsel oder andere Aktionen, die zusätzliche Bestätigung oder menschliche Prüfung verlangen.

Diese Zonen sollten nicht nur im Systemprompt stehen. Sie müssen in Datenquellen, APIs, Rollen, Toolberechtigungen und serverseitigen Prüfungen abgebildet sein. Ein Prompt kann Verhalten lenken, ist aber keine Zugriffskontrolle. Dasselbe gilt für RAG: Eine Suche über öffentliche und private Dokumente in einem gemeinsamen, ungefilterten Index schafft eine unnötig breite Angriffsfläche.

Authentifizierung ist nicht Autorisierung

Authentifizierung beantwortet vereinfacht: „Welche digitale Identität ist angemeldet?“ Autorisierung beantwortet: „Darf diese Identität genau dieses Objekt lesen oder diese Funktion ausführen?“ Der Unterschied wird im Chat leicht verwischt, weil Nutzer Objektnummern natürlich formulieren: „Zeig mir Rechnung 4711“ oder „Ändere die Adresse für Auftrag 815“.

Die OWASP-Empfehlungen gegen IDOR verlangen eine objektbezogene Berechtigungsprüfung, selbst wenn Kennungen schwer zu erraten sind. Praktisch bedeutet das: Der Server leitet das aktuelle Konto aus der geschützten Sitzung ab und prüft bei jeder Anfrage, ob Rechnung, Bestellung oder Ticket zu diesem erlaubten Datenraum gehört. Das Sprachmodell darf keine frei eingegebene Kunden- oder Objekt-ID als Vertrauensanker übernehmen.

Was der öffentliche Website-Chat beantworten darf

Für den öffentlichen Bereich ist eine Positivliste besser als eine lange Verbotsliste. Freigegeben sein können beispielsweise Rückgabefristen, Lieferregionen, Produktmerkmale, Anleitungen, allgemeine Preislogik oder der Weg zum Login. Nicht freigegeben sind individuelle Bestellstände, Vertragsdetails, persönliche Termine, interne Notizen oder die Aussage, ob ein bestimmtes Konto überhaupt existiert.

Auch scheinbar harmlose Antworten können Informationen verraten. „Zu dieser E-Mail-Adresse gibt es kein Konto“ bestätigt einen Prüfversuch. Eine neutrale Antwort wie „Melden Sie sich im Kundenportal an, um kontobezogene Informationen abzurufen“ hält die Grenze stabil. Für Manipulationsversuche braucht es zusätzlich Schutzmaßnahmen, wie sie der Beitrag Prompt Injection bei Website-Chatbots beschreibt.

Was der authentifizierte KI-Chatbot zusätzlich braucht

Nach dem Login darf der Assistent mehr, aber nur innerhalb des serverseitig bestimmten Kontexts. Sinnvolle Eingangsdaten sind eine interne Sitzungsreferenz, die erlaubte Organisation oder Mandantschaft, Rollen sowie ein eng definierter Funktionsumfang. Rohe Zugangsdaten, Passwörter, vollständige Sitzungstoken oder unnötige personenbezogene Felder gehören nicht in den Modellkontext.

Die OWASP Authorization Cheat Sheet empfiehlt Berechtigungsprüfungen für jede konkrete Ressource und Funktion. Das heißt für Toolaufrufe: Nicht das Modell entscheidet, ob eine Rechnung sichtbar ist. Es bittet einen Dienst um die erlaubte Information; der Dienst prüft Sitzung, Rolle, Mandant und Objekt erneut. Der Chat erhält anschließend nur die für die Antwort nötigen Felder.

Daten- und Toolgrenzen praktisch schneiden

Lesen und Schreiben sollten getrennte Werkzeuge sein. Ein Tool „Kundenkonto verwalten“ ist zu breit. Besser sind kleine Funktionen wie „eigene offene Bestellungen auflisten“, „Status einer erlaubten Bestellung lesen“ oder „Supportfall vorbereiten“. Jede Funktion bekommt ein minimales Eingabeschema, eine serverseitige Berechtigungsprüfung, nachvollziehbare Fehlerfälle und eine begrenzte Ausgabe.

Für RAG empfiehlt sich dieselbe Logik: öffentliche Quellen in einen öffentlichen Suchraum, kontobezogene Dokumente in einen mandanten- und rollenbezogen gefilterten Suchraum. Filter werden serverseitig aus der Sitzung gebildet, nicht aus frei formulierten Chatangaben. Änderungen an Quellen, Rollen und Freigaben gehören in ein dokumentiertes Verfahren; eine Vorlage liefert der Artikel über Content Governance und Change Control.

Sitzungsablauf, Logout und geteilte Geräte berücksichtigen

Eine Chatoberfläche darf nicht so wirken, als bliebe eine Berechtigung unbegrenzt bestehen. Die OWASP Session Management Cheat Sheet beschreibt die Sitzung als Verbindung zwischen Authentifizierung, HTTP-Verkehr und Zugriffskontrolle. Läuft die Sitzung ab, muss der nächste private Datenabruf sicher scheitern. Eine alte Antwort im sichtbaren Verlauf darf nicht als neue Berechtigung interpretiert werden.

Teams sollten außerdem Logout, Kontowechsel, Rollenänderung und gemeinsam genutzte Geräte testen. Private Gesprächsverläufe dürfen nach dem Wechsel nicht beim nächsten Konto erscheinen. Der Assistent sollte bei abgelaufener Sitzung klar zum erneuten Login führen, ohne sensible Details aus der vorherigen Sitzung zu wiederholen. Für Protokollierung und Auswertung gilt Datensparsamkeit; der Beitrag zu datensparsamer Chatbot-Analytics zeigt passende Ereignis- und Aufbewahrungsgrenzen.

Sensible Aktionen brauchen eine eigene Bestätigung

Eine Anmeldung am Portal reicht nicht zwingend für jede Aktion. Wenn der Chat eine Lieferadresse ändert, einen Vertrag bestätigt oder eine Zahlung auslöst, sollte das System eine klar erkennbare, aktionsbezogene Bestätigung verlangen. Die OWASP Transaction Authorization Cheat Sheet trennt Anmeldung und Transaktionsfreigabe und fordert serverseitige Kontrollen sowie eine Prüfung der wesentlichen Transaktionsdaten.

Ein sicheres Muster lautet: Der Chat sammelt den Wunsch, zeigt eine verständliche Zusammenfassung, das Portal prüft die aktuelle Berechtigung und verlangt bei Bedarf erneute Authentifizierung oder einen zweiten Faktor. Erst danach führt ein serverseitiger Dienst die exakt bestätigte Aktion aus. Ändern sich Ziel, Betrag oder andere wesentliche Daten, verfällt die vorherige Freigabe.

Beispiel: Rückgabe ohne Datenleck

Eine anonyme Person fragt: „Kann ich meine Bestellung zurückgeben?“ Der öffentliche Chat erklärt die allgemeine Rückgabelogik und verlinkt zum Portal. Er fragt nicht nach vollständiger Adresse oder Zahlungsdaten. Nach dem Login kann der Portal-Chat die eigenen, rückgabefähigen Bestellungen über ein Lesetool auflisten. Wählt die Person eine Bestellung, prüft der Server nochmals die Objektberechtigung und die geltenden Regeln.

Für die tatsächliche Rückgabe erzeugt ein separates Aktionstool eine Zusammenfassung. Die Person bestätigt Artikel und Abholoption in der Portaloberfläche. Scheitert die Prüfung, nennt der Chat keine internen Risikosignale, sondern bietet einen sicheren nächsten Schritt. Ist menschliche Klärung nötig, folgt ein kontrollierter Human Handoff mit nur dem notwendigen, freigegebenen Kontext.

Testmatrix vor dem Go-live

Eine Testmatrix sollte nicht nur glückliche Pfade prüfen. Nutzen Sie mindestens zwei Konten mit ähnlichen Rollen sowie getrennten Daten und testen Sie folgende Fälle:

• Anonyme Anfrage nach allgemeinen Informationen und nach privaten Kontodaten.
• Angemeldetes Konto A liest ein eigenes Objekt und versucht anschließend die Kennung eines Objekts von Konto B.
• Abgelaufene Sitzung, Logout, Kontowechsel und Rollenentzug während eines laufenden Chats.
• Sprachwechsel mitten im Vorgang, ohne dass Datenraum oder Berechtigung wechseln.
• Prompt Injection in Nutzereingaben und in abgerufenen Dokumenten.
• Ausfall eines Lesetools, Zeitüberschreitung und widersprüchliche Backend-Daten.
• Schreibaktion ohne Bestätigung, mit veränderten Daten und mit abgelaufener Bestätigung.
• Handoff an Menschen mit minimalem, nachvollziehbarem Gesprächskontext.

Erwartete Ergebnisse gehören vorab in den Test: Welche Antwort ist öffentlich zulässig? Welcher HTTP-Fehler entsteht serverseitig? Welche Information darf im Chat sichtbar sein? Welches Ereignis wird ohne vertraulichen Inhalt protokolliert? Ein geplanter Degraded Mode hilft, wenn Identitäts- oder Backend-Dienste ausfallen; dafür gibt es einen eigenen Incident-Response- und Rollback-Leitfaden.

Checkliste für eine belastbare Portalgrenze

• Öffentliche, authentifizierte und besonders geschützte Zone dokumentieren.
• Authentifizierung, Autorisierung und Transaktionsfreigabe getrennt modellieren.
• Konto und Mandant aus der sicheren Sitzung ableiten.
• Objektberechtigung bei jedem Lesen und Schreiben serverseitig prüfen.
• Öffentliche und private RAG-Quellen technisch trennen und filtern.
• Toolrechte minimal schneiden; Lesen und Schreiben separieren.
• Sitzungsablauf, Logout, Kontowechsel und Rollenänderungen im Chat berücksichtigen.
• Sensible Aktionen verständlich zusammenfassen und gezielt bestätigen lassen.
• Handoff und Protokollierung auf notwendige Daten begrenzen.
• Mit mindestens zwei Konten horizontale Zugriffsversuche reproduzierbar testen.

Ein authentifizierter KI-Chatbot wird nicht dadurch sicher, dass er hinter einem Login erscheint. Sicherheit entsteht, wenn jede Information und jede Aktion eine nachprüfbare Grenze besitzt. Beginnen Sie daher mit der Zonenkarte und der Testmatrix, bevor Sie private Datenquellen oder schreibende Tools anbinden. So bleibt der öffentliche Chat hilfreich und der Portal-Chat handlungsfähig, ohne beide Vertrauensbereiche zu vermischen.

Quellen

• 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