Publiczny chatbot AI a portal klienta: jak bezpiecznie odseparować tożsamość i dostęp do danych

Chatbot na publicznej stronie internetowej może odpowiadać na pytania o produkty, wyjaśniać godziny otwarcia lub kierować do odpowiedniej strony serwisu. Jednak gdy w portalu klienta ma sprawdzać status zamówień, umowy, faktury czy zgłoszenia wsparcia, zmienia się nie tylko treść. Powstaje nowa granica bezpieczeństwa. Uwierzytelniony chatbot AI musi wyraźnie oddzielać tożsamość, uprawnienia, sesję i konkretne akcje.

Dlatego najważniejsza decyzja architektoniczna nie brzmi: „Jakiego modelu używamy?”, lecz: „Jaka informacja i jaka akcja jest dozwolona w danej strefie zaufania?”. Kto odpowie na to pytanie przed projektowaniem promptów, ten ograniczy wycieki danych, błędne przypisania kont i niechciane akcje. Poniższy przewodnik ma charakter orientacji technicznej i organizacyjnej, a nie indywidualnej porady prawnej.

Dlaczego tryb publiczny i uwierzytelniony to dwa różne tryby pracy

W czacie publicznym osoba jest początkowo nieznana. System może znać najwyżej kontekst rozmowy, wybrany język oraz technicznie niezbędne dane sesji. Odpowiedzi powinny zatem ograniczać się do zatwierdzonych, ogólnodostępnych źródeł. Wpisany adres e-mail, numer zamówienia czy stwierdzenie typu „To jest moja umowa” nie stanowią jeszcze dowodu uprawnień.

W portalu klienta istnieje natomiast zalogowana sesja. Jednak i tam obowiązuje zasada: zalogowanie nie oznacza automatycznie, że każdy zasób i każda akcja są dozwolone. Dokument OWASP Authentication Cheat Sheet rozróżnia uwierzytelnianie, weryfikację tożsamości i zarządzanie sesją. Aktualne wytyczne NIST Digital Identity Guidelines, Revision 4 traktują weryfikację tożsamości, uwierzytelnianie i federację również jako odrębne elementy. Dla zespołów tworzących strony wynika z tego jedno: czat może używać tylko tych sygnałów zaufania, które otaczający go system jednoznacznie i weryfikowalnie dostarcza.

Trzy strefy zamiast wszechmocnego chatbota

Solidne rozwiązanie dzieli wiedzę i narzędzia co najmniej na trzy strefy:

• Strefa publiczna: zatwierdzone treści strony, ogólne informacje o produktach, procesy, kanały kontaktu i niewiążąca pomoc.
• Strefa uwierzytelniona: dane i procesy powiązane z zalogowanym kontem, organizacją, rolą lub uprawnieniem.
• Strefa szczególnie chroniona: wrażliwe zmiany, wypłaty, zawieranie umów, nowe adresy dostawy, zmiany uprawnień lub inne akcje wymagające dodatkowego potwierdzenia lub weryfikacji przez człowieka.

Strefy te nie powinny znajdować się tylko w prompcie systemowym. Muszą być odzwierciedlone w źródłach danych, API, rolach, uprawnieniach narzędzi i weryfikacjach po stronie serwera. Prompt może kierować zachowaniem, ale nie jest kontrolą dostępu. To samo dotyczy RAG: wyszukiwanie w dokumentach publicznych i prywatnych we wspólnym, nieprzefiltrowanym indeksie stwarza niepotrzebnie szeroką powierzchnię ataku.

Uwierzytelnianie to nie autoryzacja

Uwierzytelnianie odpowiada w uproszczeniu na pytanie: „Jaka tożsamość cyfrowa jest zalogowana?”. Autoryzacja odpowiada na pytanie: „Czy ta tożsamość ma prawo odczytać dokładnie ten obiekt lub wykonać tę funkcję?”. Różnica ta w czacie łatwo ulega zatarciu, ponieważ użytkownicy naturalnie formułują numery obiektów: „Pokaż mi fakturę 4711” lub „Zmień adres dla zamówienia 815”.

Zalecenia OWASP dotyczące zapobiegania podatnościom IDOR wymagają weryfikacji uprawnień dla każdego obiektu z osobna, nawet jeśli identyfikatory są trudne do odgadnięcia. W praktyce oznacza to: serwer ustala bieżące konto na podstawie chronionej sesji i przy każdym zapytaniu sprawdza, czy faktura, zamówienie lub zgłoszenie należą do tego dozwolonego obszaru danych. Model językowy nie może przyjmować dowolnie wpisanego identyfikatora klienta ani obiektu jako punktu odniesienia dla zaufania.

Na co może odpowiadać publiczny chat na stronie

Dla strefy publicznej biała lista jest lepsza niż długa lista zakazów. Zatwierdzone mogą być na przykład terminy zwrotów, regiony dostawy, cechy produktów, instrukcje, ogólna logika cenowa czy droga do logowania. Nie są zatwierdzone indywidualne statusy zamówień, szczegóły umów, osobiste terminy, wewnętrzne notatki czy informacja o tym, czy dane konto w ogóle istnieje.

Nawet pozornie niegroźne odpowiedzi mogą ujawniać informacje. Komunikat „Dla tego adresu e-mail nie istnieje konto” potwierdza próbę weryfikacji. Neutralna odpowiedź typu „Zaloguj się do portalu klienta, aby uzyskać informacje powiązane z kontem” pozwala utrzymać stabilną granicę. Przed próbami manipulacji potrzebne są dodatkowe środki ochrony, takie jak opisane w artykule Prompt Injection bei Website-Chatbots.

Czego dodatkowo potrzebuje uwierzytelniony chatbot AI

Po zalogowaniu asystent może zrobić więcej, ale tylko w ramach kontekstu określonego po stronie serwera. Sensowne dane wejściowe to wewnętrzny identyfikator sesji, dozwolona organizacja lub najemca (tenant), role oraz ściśle zdefiniowany zakres funkcji. Surowe dane logowania, hasła, pełne tokeny sesyjne czy niepotrzebne pola z danymi osobowymi nie powinny trafiać do kontekstu modelu.

Dokument OWASP Authorization Cheat Sheet zaleca sprawdzanie uprawnień dla każdego konkretnego zasobu i funkcji. W przypadku wywołań narzędzi oznacza to: to nie model decyduje, czy faktura jest widoczna. Prosi on usługę o dozwolone informacje, a usługa ponownie weryfikuje sesję, rolę, najemcę i obiekt. Następnie czat otrzymuje tylko pola niezbędne do udzielenia odpowiedzi.

Praktyczny podział granic danych i narzędzi

Odczyt i zapis powinny być osobnymi narzędziami. Narzędzie typu „Zarządzaj kontem klienta” jest zbyt szerokie. Lepsze są małe funkcje, takie jak „Wyświetl własne otwarte zamówienia”, „Odczytaj status dozwolonego zamówienia” czy „Przygotuj zgłoszenie wsparcia”. Każda funkcja otrzymuje minimalny schemat wejściowy, weryfikację uprawnień po stronie serwera, przewidywalne przypadki błędów oraz ograniczony wynik.

W przypadku RAG zaleca się tę samą logikę: źródła publiczne do publicznej przestrzeni wyszukiwania, a dokumenty powiązane z kontem do przestrzeni filtrowanej według najemców i ról. Filtry są tworzone po stronie serwera na podstawie sesji, a nie na podstawie swobodnie sformułowanych danych w czacie. Zmiany w źródłach, rolach i uprawnieniach powinny podlegać udokumentowanej procedurze; szablon udostępnia artykuł na temat Content Governance und Change Control.

Uwzględnienie wygaśnięcia sesji, wylogowania i współdzielonych urządzeń

Interfejs czatu nie może sprawiać wrażenia, że uprawnienia obowiązują bezterminowo. Dokument OWASP Session Management Cheat Sheet opisuje sesję jako połączenie między uwierzytelnianiem, ruchem HTTP a kontrolą dostępu. Gdy sesja wygaśnie, kolejna próba pobrania prywatnych danych musi się zakończyć niepowodzeniem. Stara odpowiedź widoczna w historii nie może być interpretowana jako nowe uprawnienie.

Zespoły powinny również przetestować wylogowanie, zmianę konta, zmianę ról i współdzielone urządzenia. Prywatne historie rozmów nie mogą pojawiać się na kolejnym koncie po przełączeniu. Przy wygasłej sesji asystent powinien wyraźnie kierować do ponownego zalogowania, nie powtarzając wrażliwych szczegółów z poprzedniej sesji. W zakresie logowania i analizy obowiązuje zasada minimalizacji danych; artykuł na temat datensparsamer Chatbot-Analytics pokazuje odpowiednie granice zdarzeń i retencji.

Wrażliwe akcje wymagają osobnego potwierdzenia

Samo zalogowanie do portalu niekoniecznie wystarcza do wykonania każdej akcji. Jeśli czat zmienia adres dostawy, potwierdza umowę lub inicjuje płatność, system powinien wymagać jednoznacznego, powiązanego z akcją potwierdzenia. Dokument OWASP Transaction Authorization Cheat Sheet rozdziela logowanie od autoryzacji transakcji i wymaga kontroli po stronie serwera oraz weryfikacji kluczowych danych transakcji.

Bezpieczny wzorzec wygląda następująco: czat zbiera żądanie, pokazuje zrozumiałe podsumowanie, portal weryfikuje aktualne uprawnienia i w razie potrzeby wymaga ponownego uwierzytelnienia lub drugiego składnika. Dopiero potem usługa po stronie serwera wykonuje dokładnie zatwierdzoną akcję. Jeśli zmieni się cel, kwota lub inne istotne dane, poprzednie zatwierdzenie traci ważność.

Przykład: Zwrot towaru bez wycieku danych

Anonimowa osoba pyta: „Czy mogę zwrócić moje zamówienie?”. Publiczny czat wyjaśnia ogólną logikę zwrotów i odsyła do portalu. Nie pyta o pełny adres ani dane płatnicze. Po zalogowaniu czat w portalu może wyświetlić własne zamówienia kwalifikujące się do zwrotu za pomocą narzędzia odczytu. Gdy osoba wybierze zamówienie, serwer ponownie weryfikuje uprawnienia do obiektu oraz obowiązujące reguły.

Dla właściwego zwrotu osobne narzędzie akcji generuje podsumowanie. Użytkownik potwierdza artykuły i opcję odbioru w interfejsie portalu. Jeśli weryfikacja zakończy się niepowodzeniem, czat nie podaje wewnętrznych sygnałów ryzyka, lecz oferuje bezpieczny kolejny krok. Jeśli konieczne jest wyjaśnienie przez człowieka, następuje kontrolowany Human Handoff zawierający jedynie niezbędny, zatwierdzony kontekst.

Macierz testów przed wdrożeniem produkcyjnym

Macierz testów nie powinna sprawdzać tylko optymistycznych scenariuszy. Użyj co najmniej dwóch kont o podobnych rolach z odrębnymi danymi i przetestuj następujące przypadki:

• Anonimowe zapytanie o ogólne informacje oraz o prywatne dane konta.
• Zalogowane konto A odczytuje własny obiekt, a następnie próbuje podać identyfikator obiektu należącego do konta B.
• Wygaśnięcie sesji, wylogowanie, zmiana konta i odebranie ról w trakcie trwającego czatu.
• Zmiana języka w trakcie procesu bez zmiany obszaru danych ani uprawnień.
• Prompt injection w danych wejściowych użytkownika i w pobieranych dokumentach.
• Awaria narzędzia odczytu, przekroczenie limitu czasu (timeout) i sprzeczne dane w backendzie.
• Akcja zapisu bez potwierdzenia, ze zmienionymi danymi oraz z wygasłym potwierdzeniem.
• Przekazanie rozmowy człowiekowi (handoff) z minimalnym, przejrzystym kontekstem rozmowy.

Oczekiwane wyniki należy określić z góry w teście: Jaka odpowiedź jest dozwolona publicznie? Jaki błąd HTTP powstaje po stronie serwera? Jaka informacja może być widoczna w czacie? Jakie zdarzenie jest logowane bez poufnych treści? Planowany tryb ograniczonej funkcjonalności (degraded mode) pomaga w przypadku awarii usług tożsamości lub backendu; służy do tego osobny ki-chatbot-incident-response-degraded-mode-rollback.

Lista kontrolna solidnej granicy portalu

• Udokumentowanie strefy publicznej, uwierzytelnionej i szczególnie chronionej.
• Odrębne modelowanie uwierzytelniania, autoryzacji i zatwierdzania transakcji.
• Określanie konta i najemcy na podstawie bezpiecznej sesji.
• Weryfikowanie uprawnień do obiektów po stronie serwera przy każdym odczycie i zapisie.
• Techniczne rozdzielenie i filtrowanie publicznych oraz prywatnych źródeł RAG.
• Minimalne definiowanie uprawnień narzędzi; rozdzielenie odczytu i zapisu.
• Uwzględnienie wygaśnięcia sesji, wylogowania, zmiany konta i zmian ról w czacie.
• Przejrzyste podsumowanie wrażliwych akcji i ich celowe potwierdzanie.
• Ograniczenie przekazania rozmowy (handoff) i logowania do niezbędnych danych.
• Powtarzalne testowanie próby dostępu horyzontalnego za pomocą co najmniej dwóch kont.

Uwierzytelniony chatbot AI nie staje się bezpieczny samo przez to, że pojawia się po zalogowaniu. Bezpieczeństwo powstaje wtedy, gdy każda informacja i każda akcja posiada weryfikowalną granicę. Dlatego zacznij od mapy stref i macierzy testów, zanim podłączysz prywatne źródła danych lub narzędzia wykonujące zapis. Dzięki temu publiczny czat pozostanie pomocny, a czat w portalu – sprawny do działania, bez mieszania obu stref zaufania.

Źródła

• 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