Публичен AI чатбот срещу клиентски портал: Безопасно разделяне на самоличност и достъп до данни

Чатботът на публичен уебсайт може да отговаря на въпроси за продукти, да обяснява работното време или да пренасочва към съответната страница за услуги. Но щом трябва да преглежда статус на поръчки, договори, фактури или поддръжка в клиентския портал, се променя не само съдържанието. Възниква нова граница на сигурност. Един автентифициран AI чатбот трябва ясно да разделя самоличността, правата за достъп, сесията и конкретното действие.

Затова най-важното архитектурно решение не е: „Кой модел да използваме?“, а: „Коя информация и кое действие са позволени в съответната зона на доверие?“ Всеки, който отговори на този въпрос преди проектирането на системния промпт, намалява риска от изтичане на данни, погрешно свързване на профили и нежелани действия. Следното ръководство предлага техническа и организационна ориентация, а не индивидуална правна консултация.

Защо публичният и автентифицираният режим са два различни начина на работа

В публичния чат потребителят първоначално е неизвестен. Системата може най-много да знае контекста на разговора, избрания език и технически необходимите данни за сесията. Затова отговорите трябва да се ограничават до одобрени, общодостъпни източници. Въведен имейл адрес, номер на поръчка или твърдение като „Това е моят договор“ все още не са доказателство за права на достъп.

В клиентския портал обаче съществува влязла в системата сесия. Но дори и там важи следното: влизането не означава автоматично, че всеки ресурс и всяко действие са разрешени. Документът OWASP Authentication Cheat Sheet разграничава автентификация, проверка на самоличността и управление на сесиите. Актуалните NIST Digital Identity Guidelines, Revision 4 също разглеждат проверката на самоличност, автентификацията и федерацията като отделни елементи. За екипите, поддържащи уебсайтове, от това следва: чатботът може да използва само тези сигнали за доверие, които заобикалящата го система доказуемо предоставя.

Три зони вместо един всемогъщ чатбот

Едно стабилно решение разделя знанията и инструментите най-малко на три зони:

• Публична зона: одобрено съдържание от уебсайта, обща информация за продукти, процеси, контакти и общо съдействие.
• Автентифицирана зона: данни и процеси, свързани с влезлия профил, организация, роля или право на достъп.
• Особено защитена зона: чувствителни промени, плащания, сключване на договори, нови адреси за доставка, промяна на права или други действия, изискващи допълнително потвърждение или преглед от човек.

Тези зони не трябва да съществуват само в системния промпт. Те трябва да бъдат отразени в източниците на данни, API интерфейсите, ролите, правата за достъп до инструменти и проверките от страна на сървъра. Промптът може да насочва поведението, но не е контрол на достъпа. Същото важи и за RAG: търсенето в публични и частни документи в общ, филтриран индекс създава излишно широка повърхност за атака.

Автентификацията не е авторизация

Най-просто казано, автентификацията отговаря на въпроса: „Коя дигитална самоличност е влязла в системата?“. Авторизацията отговаря на: „Има ли право тази самоличност да чете точно този обект или да изпълнява тази функция?“. В чата тази разлика лесно се замъглява, защото потребителите естествено формулират номера на обекти: „Покажи ми фактура 4711“ или „Промени адреса за поръчка 815“.

Препоръките на OWASP срещу IDOR изискват проверка на правата на ниво обект, дори ако идентификаторите са трудни за отгатване. На практика това означава: сървърът извлича текущия профил от защитената сесия и проверява при всяка заявка дали фактурата, поръчката или тикетът принадлежат към този позволен пространство от данни. Езиковият модел не трябва да приема свободно въведен клиентски или обектен ID като надежден източник.

Какво може да отговаря публичният чат на уебсайта

За публичната зона списъкът с позволени неща (белият списък) е за предпочитане пред дългия списък със забрани. Разрешени могат да бъдат например срокове за връщане, региони за доставка, характеристики на продуктите, инструкции, обща ценова логика или стъпките за влизане в профила. Не са разрешени индивидуални статуси на поръчки, детайли по договори, лични срещи, вътрешни бележки или потвърждение дали определен профил изобщо съществува.

Дори наглед безвредни отговори могат да разкрият информация. Изречение като „Няма профил с този имейл адрес“ потвърждава опит за проверка. Неутрален отговор като „Влезте в клиентския портал, за да видите информация за профила си“ запазва стабилна границата. За опити за манипулация са необходими допълнителни мерки за защита, описани в статията Prompt Injection при чатботове за уебсайтове.

Какво допълнително е необходимо за автентифицирания AI чатбот

След влизане асистентът може да прави повече неща, но само в рамките на контекста, определен от сървъра. Подходящи входящи данни са вътрешна референция за сесията, позволената организация или клиентски акаунт (tenant), ролите и строго дефинираният обхват от функции. Необработени данни за достъп, пароли, пълни токени за сесия или излишни лични данни нямат място в контекста на модела.

Документът OWASP Authorization Cheat Sheet препоръчва проверки на правата за всеки конкретен ресурс и функция. За повикването на инструменти това означава: не моделът решава дали дадена фактура е видима. Той заявява позволената информация от услуга; услугата проверява отново сесията, ролята, акаунта и обекта. След това чатът получава само полетата, необходими за отговора.

Практическо дефиниране на границите на данните и инструментите

Четенето и писането трябва да бъдат отделни инструменти. Инструмент като „Управление на клиентски профил“ е твърде широк. По-добре е да използвате малки функции като „Изброй собствените отворени поръчки“, „Прочети статуса на позволена поръчка“ или „Подготви заявка за поддръжка“. Всяка функция получава минимална входна схема, проверка на правата от сървъра, проследими случаи на грешки и ограничена изходна информация.

За RAG се препоръчва същата логика: публичните източници отиват в публично пространство за търсене, а свързаните с профила документи — в пространство за търсене, филтрирано според акаунта и ролята. Филтрите се съставят от сървъра въз основа на сесията, а не от свободно формулирани данни в чата. Промените по източници, роли и одобрения трябва да следват документирана процедура; шаблон за това предоставя статията за Content Governance и Change Control.

Отчитане на изтичането на сесията, излизането от профила и споделените устройства

Чат интерфейсът не трябва да създава впечатление, че дадена правомощ остава неограничена във времето. Документът OWASP Session Management Cheat Sheet описва сесията като връзка между автентификация, HTTP трафик и контрол на достъпа. Ако сесията изтече, следващото извличане на лични данни трябва гарантирано да се провали. Стар отговор във видимата история не трябва да се интерпретира като ново право за достъп.

Екипите трябва също да тестват излизане от профила, смяна на профила, промяна на ролята и споделени устройства. Личната история на разговорите не трябва да се появява в следващия профил след превключване. При изтекла сесия асистентът трябва ясно да упътва към повторно влизане, без да повтаря чувствителни детайли от предишната сесия. За логовете и анализите важи принципът за минимизиране на данните; статията за аналитика на чатботове с минимизиране на данните показва подходящи граници за събития и съхранение.

Чувствителните действия изисква отделно потвърждение

Влизането в портала не е задължително достатъчно за всяко действие. Ако чатът променя адрес за доставка, потвърждава договор или инициира плащане, системата трябва да изисква ясно разпознаваемо потвърждение, свързано с конкретното действие. Документът OWASP Transaction Authorization Cheat Sheet разделя влизането от одобряването на транзакцията и изисква проверки от страна на сървъра, както и преглед на основните данни за транзакцията.

Сигурен модел е следният: чатът събира заявката, показва разбираемо резюме, порталът проверява текущите права и при необходимост изисква повторна автентификация или втори фактор. Едва след това услуга от страна на сървъра изпълнява точно потвърденото действие. Ако крайната цел, сумата или други основни данни се променят, предишното одобрение става невалидно.

Пример: Връщане на стока без изтичане на данни

Анонимен потребител пита: „Мога ли да върна поръчката си?“. Публичният чат обяснява общата логика за връщане и пренасочва с връзка към портала. Той не иска пълен адрес или данни за плащане. След влизане в профила чатът в портала може да изброи собствените поръчки, които подлежат на връщане, чрез инструмент за четене. Ако потребителят избере поръчка, сървърът отново проверява правата за обекта и приложимите правила.

За същинското връщане отделен инструмент за действия генерира резюме. Потребителят потвърждава артикулите и опцията за вземане в интерфейса на портала. Ако проверката се провали, чатът не съобщава вътрешни сигнали за риск, а предлага сигурна следваща стъпка. Ако е необходимо изясняване от човек, следва контролирано прехвърляне към оператор (Human Handoff) само с необходимия, одобрен контекст.

Матрица за тестване преди пускане в експлоатация (Go-live)

Тестовата матрица не трябва да проверява само стандартните сценарии (happy path). Използвайте поне два профила с сходни роли и отделни данни и тествайте следните случаи:

• Анонимна заявка за обща информация и за лични данни на профил.
• Влязъл профил A чете собствен обект и след това опитва идентификатор на обект на профил B.
• Изтекла сесия, излизане, смяна на профил и отнемане на роля по време на активен чат.
• Смяна на езика по средата на процеса, без да се променя пространството от данни или правата.
• Prompt Injection в потребителските въводи и в извлечените документи.
• Отказ на инструмент за четене, изтичане на времето (timeout) и противоречиви данни в бекенда.
• Действие за запис/промяна без потвърждение, с променени данни и с изтекъл срок на потвърждение.
• Прехвърляне към човек с минимален, проследим контекст на разговора.

Очакваните резултати трябва предварително да са включени в теста: Кой отговор е публично допустим? Каква HTTP грешка възниква от страна на сървъра? Коя информация може да бъде видима в чата? Кое събитие се записва в лога без поверително съдържание? Планираният "Degraded Mode" помага, когато услугите за самоличност или бекендът отпаднат; за това има отделно ръководство за реагиране при инциденти (Incident Response) и възстановяване (Rollback).

Чеклист за надеждна граница на портала

• Документирайте публичната, автентифицираната и особено защитената зона.
• Моделирайте отделно автентификацията, авторизацията и одобряването на транзакции.
• Извличайте профила и акаунта (tenant) от сигурната сесия.
• Проверявайте правата върху обекти от страна на сървъра при всяко четене и писане.
• Разделете технически и филтрирайте публичните и личните източници за RAG.
• Ограничете максимално правата на инструментите; разделете четенето от писането.
• Съобразете в чата изтичането на сесията, излизането, смяната на профила и промените на роли.
• Описвайте разбираемо чувствителните действия и изисквайте целево потвърждение.
• Ограничете прехвърлянето към човек и логването до строго необходимите данни.
• Тествайте възпроизводимо опитите за хоризонтален достъп с поне два профила.

Автентифицираният AI чатбот не става сигурен просто защото е поставен зад вход с парола. Сигурността възниква тогава, когато всяка информация и всяко действие имат проверима граница. Затова започнете с картата на зоните и матрицата за тестване, преди да свързвате лични източници на данни или инструменти с права за запис. Така публичният чат остава полезен, а порталният чат — функционален, без да се смесват двете зони на доверие.

Източници

• 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