Nyilvános AI-chatbot vs. ügyfélportál: Az identitás és az adatelérés biztonságos elkülönítése

Egy nyilvános weboldalon található chatbot válaszolhat termékekkel kapcsolatos kérdésekre, ismertetheti a nyitvatartási időt, vagy elirányíthat a megfelelő szolgáltatási oldalra. Amint azonban az ügyfélportálon kell megtekintenie a rendelési státuszt, a szerződéseket, a számlákat vagy a támogatási jegyeket, nemcsak a tartalom változik meg. Új biztonsági határ jön létre. Egy hitelesített AI-chatbotnak tisztán el kell különítenie egymástól az identitást, a jogosultságot, a munkamenetet és a konkrét műveletet.

A legfontosabb architektúrabéli döntés ezért nem az: „Melyik modellt használjuk?”, hanem az: „Melyik információ és melyik művelet engedélyezett az adott bizalmi zónában?” Aki a promptok tervezése előtt megválaszolja ezt a kérdést, csökkenti az adatszivárgás, a hibás fióktársítások és a nem kívánt műveletek kockázatát. Az alábbi útmutató technikai és szervezési iránymutatásként szolgál, nem egyéni jogi tanácsadás.

Miért jelent két külön működési módot a nyilvános és a hitelesített

A nyilvános chaten a személy kezdetben ismeretlen. A rendszer legfeljebb a beszélgetés kontextusát, a kiválasztott nyelvet és a technikailag szükséges munkamenet-adatokat ismerheti. A válaszoknak ezért a jóváhagyott, nyilvánosan elérhető forrásokra kell korlátozódniuk. A megadott e-mail-cím, rendelési szám vagy az olyan állítások, mint a „Ez az én szerződésem”, még nem képezik a jogosultság igazolását.

Az ügyfélportálon ezzel szemben egy bejelentkezett munkamenet létezik. De ott is érvényes: a bejelentkezés nem jelenti automatikusan azt, hogy minden erőforrás és minden művelet engedélyezett. Az OWASP Authentication Cheat Sheet megkülönbözteti a hitelesítést, az identitásellenőrzést és a munkamenet-kezelést. A legújabb NIST Digital Identity Guidelines, Revision 4 szintén külön építőelemként kezeli az identitásellenőrzést, a hitelesítést és a federációt. A weboldal-csapatok számára ebből az következik: a chat csak azokat a bizalmi jeleket használhatja fel, amelyeket a környező rendszer igazolhatóan biztosít.

Három zóna egy mindenható chatbot helyett

Egy robusztus megoldás a tudást és az eszközöket legalább három zónára osztja fel:

• Nyilvános zóna: jóváhagyott weboldaltartalmak, általános termékinformációk, folyamatok, elérhetőségek és kötelezettségmentes segítségnyújtás.
• Hitelesített zóna: a bejelentkezett fiókhoz, szervezethez, szerepkörhöz vagy jogosultsághoz kötött adatok és folyamatok.
• Kiemelten védett zóna: érzékeny módosítások, kifizetések, szerződéskötések, új szállítási címek, jogosultságváltások vagy más olyan műveletek, amelyek további megerősítést vagy emberi ellenőrzést igényelnek.

Ezeknek a zónáknak nem szabad csak a rendszerpromptban létezniük. Le kell képezni őket az adatforrásokban, API-kban, szerepkörökben, eszközjogosultságokban és a szerveroldali ellenőrzésekben. A prompt irányíthatja a viselkedést, de nem jelent hozzáférés-vezérlést. Ugyanez vonatkozik a RAG-ra is: a nyilvános és privát dokumentumok közötti keresés egy közös, szűretlen indexben feleslegesen széles támadási felületet hoz létre.

A hitelesítés nem azonos a felhatalmazással

Egyszerűsítve: a hitelesítés arra ad választ: „Melyik digitális identitás van bejelentkezve?” A felhatalmazás arra ad választ: „Olvashatja-e ez az identitás pontosan ezt az objektumot, vagy végrehajthatja-e ezt a funkciót?” A különbség a chaten könnyen elmosódik, mert a felhasználók természetes módon fogalmazzák meg az objektumszámokat: „Mutasd a 4711-es számlát” vagy „Módosítsd a címet a 815-ös megrendelésnél”.

Az IDOR elleni OWASP-ajánlások objektumalapú jogosultságellenőrzést írnak elő, még akkor is, ha az azonosítókat nehéz kitalálni. Gyakorlati szempontból ez azt jelenti: a szerver a védett munkamenetből származtatja az aktuális fiókot, és minden kérésnél ellenőrzi, hogy a számla, megrendelés vagy jegy ehhez az engedélyezett adatterülethez tartozik-e. A nyelvi modell nem fogadhat el szabadon megadott ügyfél- vagy objektum-ID-t bizalmi horgonyként.

Mit válaszolhat meg a nyilvános weboldali chat

A nyilvános terület számára a pozitív lista jobb, mint egy hosszú tiltólista. Engedélyezettek lehetnek például a visszaküldési határidők, a szállítási régiók, a termékjellemzők, az útmutatók, az általános árazási logika vagy a bejelentkezéshez vezető út. Nem engedélyezettek az egyéni rendelési státuszok, a szerződéses részletek, a személyes időpontok, a belső megjegyzések vagy annak közlése, hogy létezik-e egyáltalán egy adott fiók.

Még az ártalmatlannak tűnő válaszok is kiadhatnak információkat. A „Ehhez az e-mail-címhez nem tartozik fiók” válasz megerősíti a próbálkozást. Egy semleges válasz, mint például a „Jelentkezzen be az ügyfélportálra a fiókkal kapcsolatos információk lekéréséhez”, stabilan tartja a határt. A manipulációs kísérletek ellen további védelmi intézkedésekre van szükség, amelyeket a Prompt Injection bei Website-Chatbots című cikk ismertet.

Mire van még szüksége a hitelesített AI-chatbotnak

A bejelentkezés után az asszisztens többet tehet meg, de csak a szerveroldalon meghatározott kontextuson belül. Értelmes bemeneti adatok egy belső munkamenet-referencia, az engedélyezett szervezet vagy bérlő, a szerepkörök, valamint egy szűken meghatározott funkciókészlet. A nyers hozzáférési adatok, jelszavak, teljes munkamenet-tokenek vagy felesleges személyes mezők nem tartoznak a modell kontextusába.

Az OWASP Authorization Cheat Sheet minden konkrét erőforrásra és funkcióra vonatkozóan jogosultságellenőrzést javasol. Az eszközhívások esetében ez azt jelenti: nem a modell dönti el, hogy egy számla látható-e. A modell információt kér egy szolgáltatástól, a szolgáltatás pedig ismételten ellenőrzi a munkamenetet, a szerepkört, a bérlőt és az objektumot. A chat ezt követően csak a válaszhoz szükséges mezőket kapja meg.

Az adat- és eszközhatárok gyakorlati kijelölése

Az olvasásnak és az írásnak különálló eszközöknek kell lenniük. Egy „Ügyfélfiók kezelése” nevű eszköz túl tág. Jobbak a kis funkciók, mint például a „saját nyitott rendelések listázása”, „egy engedélyezett rendelés státuszának olvasása” vagy „támogatási jegy előkészítése”. Minden funkció minimális bemeneti sémát, szerveroldali jogosultságellenőrzést, érthető hibakezelést és korlátozott kimenetet kap.

A RAG esetében ugyanez a logika ajánlott: nyilvános források egy nyilvános keresési térbe, a fiókhoz kapcsolódó dokumentumok pedig egy bérlő- és szerepkör-alapon szűrt keresési térbe kerülnek. A szűrők szerveroldalon jönnek létre a munkamenetből, nem pedig a szabadon megfogalmazott chat-bejegyzésekből. A források, szerepkörök és jóváhagyások módosításai dokumentált eljárás részét kell képezzék; egy sablont a KI-Chatbot Content Governance und Change Control című cikk biztosít.

Munkamenet lejáratának, kijelentkezésnek és közös eszközöknek a figyelembevétele

A chat felülete nem keltheti azt a benyomást, mintha a jogosultság határozatlan ideig megmaradna. Az OWASP Session Management Cheat Sheet a munkamenetet a hitelesítés, a HTTP-forgalom és a hozzáférés-vezérlés közötti kapcsolatként írja le. Ha a munkamenet lejár, a következő privát adatlekérésnek biztonságosan meg kell hiúsulnia. A látható előzményekben található régi válasz nem értelmezhető új jogosultságként.

A csapatoknak tesztelniük kell továbbá a kijelentkezést, a fiókváltást, a szerepkör-módosítást és a közösen használt eszközöket is. A privát beszélgetési előzmények a váltás után nem jelenhetnek meg a következő fióknál. Lejárt munkamenet esetén az asszisztensnek egyértelműen az újbóli bejelentkezéshez kell vezetnie a felhasználót anélkül, hogy megismételné az előző munkamenet érzékeny részleteit. A naplózásra és az elemzésre az adattakarékosság elve vonatkozik; az adattakarékos chatbot-analitika témájú cikk bemutatja a megfelelő esemény- és megőrzési határokat.

Az érzékeny műveletekhez külön megerősítés szükséges

A portálra való bejelentkezés nem feltétlenül elegendő minden művelethez. Ha a chat módosítja a szállítási címet, megerősít egy szerződést vagy fizetést indít el, a rendszernek egyértelműen felismerhető, műveletspecifikus megerősítést kell kérnie. Az OWASP Transaction Authorization Cheat Sheet elkülöníti a bejelentkezést a tranzakció jóváhagyásától, és szerveroldali ellenőrzéseket, valamint az alapvető tranzakciós adatok ellenőrzését írja elő.

Egy biztonságos minta a következő: a chat összegyűjti a kérést, megjelenít egy érthető összefoglalót, a portál ellenőrzi az aktuális jogosultságot, és szükség esetén újbóli hitelesítést vagy második faktort kér. A szerveroldali szolgáltatás csak ezután hajtsa végre a pontosan megerősített műveletet. Ha a cél, az összeg vagy más lényeges adat megváltozik, a korábbi jóváhagyás érvényét veszti.

Példa: Visszaküldés adatszivárgás nélkül

Egy névtelen személy megkérdezi: „Visszaküldhetem a rendelésemet?” A nyilvános chat elmagyarázza az általános visszaküldési logikát, és a portálra mutató hivatkozást ad. Nem kér teljes címet vagy fizetési adatokat. A bejelentkezés után a portál-chat egy olvasási eszköz segítségével kilistázhatja a saját, visszaküldhető rendeléseket. Ha a személy kiválaszt egy rendelést, a szerver ismételten ellenőrzi az objektumjogosultságot és az érvényes szabályokat.

A tényleges visszaküldéshez egy külön akcióeszköz hoz létre egy összefoglalót. A felhasználó megerősíti a cikkeket és az átvételi opciót a portál felületén. Ha az ellenőrzés meghiúsul, a chat nem közöl belső kockázati jeleket, hanem egy biztonságos következő lépést kínál. Ha emberi tisztázásra van szükség, egy ellenőrzött Human Handoff következik, amely csak a szükséges, jóváhagyott kontextust tartalmazza.

Tesztmátrix az élesítés (Go-live) előtt

A tesztmátrixnak nem csak az ideális eseteket kell vizsgálnia. Használjon legalább két, hasonló szerepkörrel rendelkező, de elkülönített adatokkal bíró fiókot, és tesztelje a következő eseteket:

• Névtelen kérés általános információkra, valamint privát fiókadatokra vonatkozóan.
• A bejelentkezett „A” fiók elolvassa a saját objektumát, majd megpróbálja elérni a „B” fiók objektumazonosítóját.
• Lejárt munkamenet, kijelentkezés, fiókváltás és szerepkör-visszavonás egy folyamatban lévő chat során.
• Nyelvváltás a folyamat közepén, anélkül, hogy az adatterület vagy a jogosultság megváltozna.
• Prompt injection a felhasználói bevitelekben és a lekért dokumentumokban.
• Egy olvasási eszköz leállása, időtúllépés és ellentmondásos háttérrendszer-adatok.
• Írási művelet megerősítés nélkül, módosított adatokkal és lejárt megerősítéssel.
• Emberi kollégának történő átadás (handoff) minimális, nyomon követhető beszélgetési kontextussal.

Az elvárt eredményeket előre be kell építeni a tesztbe: Melyik válasz megengedett nyilvánosan? Milyen HTTP-hiba keletkezik szerveroldalon? Melyik információ lehet látható a chaten? Melyik esemény kerül naplózásra bizalmas tartalom nélkül? Egy tervezett csökkentett működési mód (Degraded Mode) segít, ha az identitás- vagy backend-szolgáltatások leállnak; ehhez egy külön Incident-Response- und Rollback-Leitfaden áll rendelkezésre.

Ellenőrzőlista a megbízható portálhatárhoz

• A nyilvános, a hitelesített és a kiemelten védett zóna dokumentálása.
• A hitelesítés, a felhatalmazás és a tranzakció-jóváhagyás különálló modellezése.
• A fiók és a bérlő származtatása a biztonságos munkamenetből.
• Az objektumjogosultság szerveroldali ellenőrzése minden olvasási és írási műveletnél.
• A nyilvános és privát RAG-források technikai elkülönítése és szűrése.
• Az eszközjogosultságok minimálisra csökkentése; az olvasás és az írás szétválasztása.
• A munkamenet lejárata, a kijelentkezés, a fiókváltás és a szerepkör-változások figyelembevétele a chaten.
• Az érzékeny műveletek érthető összefoglalása és célzott megerősíttetése.
• Az átadás (handoff) és a naplózás korlátozása a szükséges adatokra.
• A horizontális hozzáférési kísérletek reprodukálható tesztelése legalább két fiókkal.

Egy hitelesített AI-chatbot nem attól válik biztonságossá, hogy egy bejelentkezés mögött jelenik meg. A biztonság akkor jön létre, ha minden információnak és minden műveletnek ellenőrizhető határa van. Ezért kezdje a zónatérképpel és a tesztmátrixszal, mielőtt privát adatforrásokat vagy írási funkciójú eszközöket csatlakoztatna. Így a nyilvános chat hasznos, a portál-chat pedig cselekvőképes marad anélkül, hogy a két bizalmi terület összekeveredne.

Források

• 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