Julkinen tekoäly-chatbot vs. asiakasportaali: Erota henkilöllisyys ja datan käyttöoikeudet turvallisesti

Verkkosivuston julkinen chatbot voi vastata tuotekysymyksiin, kertoa aukioloajoista tai ohjata oikealle palvelusivulle. Kun sen pitäisi asiakasportaalissa näyttää tilausyhteenvetoja, sopimuksia, laskuja tai tukipyyntöjä, kyse ei ole enää pelkästä sisällön muuttumisesta. Tilanteeseen muodostuu uusi turvallisuusraja. Tunnistautuneen tekoäly-chatbotin on erotettava selkeästi toisistaan henkilöllisyys, käyttöoikeudet, istunto ja yksittäiset toiminnot.

Tärkein arkkitehtuuripäätös ei siksi kuulu: ”Mitä mallia käytämme?”, vaan: ”Mikä tieto ja mikä toiminto on sallittu milläkin luottamusalueella?” Kun tähän kysymykseen vastataan ennen kehotteiden suunnittelua, minimoidaan tietovuodot, väärät tiliyhdistämiset ja tahattomat toiminnot. Seuraava opas tarjoaa teknistä ja organisatorista ohjeistusta, eikä se ole yksilöllistä oikeudellista neuvontaa.

Miksi julkinen ja tunnistautunut ovat kaksi eri toimintatilaa

Julkisessa chatissa käyttäjä on aluksi tuntematon. Järjestelmä voi korkeintaan tietää keskustelukontekstin, valitun kielen ja teknisesti välttämättömät istuntotiedot. Vastausten tulisikin rajoittua vain julkaistuihin ja yleisesti saatavilla oleviin lähteisiin. Syötetty sähköpostiosoite, tilausnumero tai väite kuten ”Tämä on minun sopimukseni” ei ole vielä osoitus käyttöoikeudesta.

Asiakasportaalissa sen sijaan on käynnissä kirjautunut istunto. Mutta sielläkin pätee sääntö: kirjautuminen ei tarkoita automaattisesti, että jokainen resurssi ja toiminto olisi sallittu. OWASP Authentication Cheat Sheet erottaa toisistaan tunnistautumisen, henkilöllisyyden varmentamisen ja istunnon hallinnan. Myös tuoreet NIST Digital Identity Guidelines, Revision 4 käsittelevät henkilöllisyyden vahvistamista, tunnistautumista ja federaatiota erillisinä palikoina. Verkkosivutiimeille tämä tarkoittaa: chat saa käyttää vain niitä luottamussignaaleja, joita ympäröivä järjestelmä todistetusti tarjoaa.

Kolme vyöhykettä kaikkivoivan chatbotin sijaan

Vankka ratkaisu jakaa tiedon ja työkalut vähintään kolmeen vyöhykkeeseen:

• Julkinen vyöhyke: julkaistut verkkosivuston sisällöt, yleiset tuotetiedot, prosessit, yhteydenottotavat ja sitomaton opastus.
• Tunnistautunut vyöhyke: tiedot ja toiminnot, jotka on sidottu kirjautuneeseen tiliin, organisaatioon, rooliin tai käyttöoikeuteen.
• Erityissuojattu vyöhyke: kriittiset muutokset, maksut, sopimusten tekeminen, uudet toimitusosoitteet, käyttöoikeuksien muuttaminen tai muut toiminnot, jotka vaativat lisävahvistusta tai ihmisen suorittamaa tarkistusta.

Näiden vyöhykkeiden ei tulisi olla olemassa vain järjestelmäkehotteessa. Niiden on näyttävä tietolähteissä, rajapinnoissa (API), rooleissa, työkalujen käyttöoikeuksissa ja palvelinpään tarkistuksissa. Kehotteella voidaan ohjata käyttäytymistä, mutta se ei ole pääsynhallintamekanismi. Sama koskee RAG-hakua: haku julkisista ja yksityisistä dokumenteista samasta, suodattamattomasta indeksistä luo tarpeettoman laajan hyökkäyspinta-alan.

Tunnistautuminen ei ole valtuutusta

Tunnistautuminen vastaa yksinkertaistettuna kysymykseen: ”Mikä digitaalinen identiteetti on kirjautuneena?” Valtuutus puolestaan vastaa: ”Saako tämä identiteetti lukea juuri tämän kohteen tai suorittaa tämän funktion?” Ero hämärtyy helposti chatissa, koska käyttäjät muotoilevat kohdenumerot luonnollisesti: ”Näytä minulle lasku 4711” tai ”Muuta tilauksen 815 osoite”.

OWASP-suositukset IDOR-haavoittuvuuksien ehkäisemiseksi vaativat kohdekohtaista käyttöoikeustarkistusta, vaikka tunnisteet olisivatkin vaikeasti arvattavissa. Käytännössä tämä tarkoittaa: palvelin päättelee nykyisen tilin suojatusta istunnosta ja tarkistaa jokaisessa pyynnössä, kuuluuko lasku, tilaus tai tukipyyntö tälle sallitulle data-alueelle. Kielimalli ei saa käyttää vapaasti syötettyä asiakas- tai kohde-ID:tä luottamuksen ankkurina.

Mitä julkinen verkkosivuchat saa vastata

Julkisella alueella sallittujen asioiden lista on parempi kuin pitkä kieltolista. Sallittuja voivat olla beispielsweise palautusajat, toimitusalueet, tuote-ominaisuudet, ohjeet, yleinen hinnoittelulogikka tai reitti kirjautumiseen. Sallittuja eivät sen sijaan ole yksittäiset tilaustiedot, sopimusehdot, henkilökohtaiset tapaamiset, sisäiset muistiinpanot tai tieto siitä, onko tiettyä tiliä edes olemassa.

Myös näennäisesti harmittomat vastaukset voivat paljastaa tietoa. ”Tälle sähköpostiosoitteelle ei löydy tiliä” vahvistaa kysely-yrityksen. Neutraali vastaus, kuten ”Kirjaudu asiakasportaaliin tarkastellaksesi tiliin liittyviä tietoja”, pitää rajan vakaana. Manipulointiyrityksiä vastaan tarvitaan lisäksi suojatoimia, joita kuvaillaan artikkelissa Prompt Injection bei Website-Chatbots.

Mitä tunnistautunut tekoäly-chatbot tarvitsee lisäksi

Kirjautumisen jälkeen avustaja saa tehdä enemmän, mutta vain palvelinpäässä määritellyn kontekstin puitteissa. Järkeviä syötetietoja ovat sisäinen istuntoviite, sallittu organisaatio tai asiakkuus (tenant), roolit sekä tarkasti rajattu toimintalaajuus. Raa'at kirjautumistiedot, salasanat, täydelliset istuntotokenit tai tarpeettomat henkilötietokentät eivät kuulu mallin kontekstiin.

OWASP Authorization Cheat Sheet suosittelee käyttöoikeustarkistuksia jokaiselle yksittäiselle resurssille ja funktiolle. Tämä tarkoittaa työkalukutsuissa: malli ei päätä, onko lasku näkyvillä. Se pyytää palvelulta sallittua tietoa, ja palvelu tarkistaa jälleen istunnon, roolin, asiakkuuden ja kohteen. Chat saa sen jälkeen vain vastaukseen tarvittavat kentät.

Data- ja työkalurajojen käytännön rajaaminen

Lukemisen ja kirjoittamisen tulisi olla erillisiä työkaluja. Työkalu ”hallinnoi asiakastiliä” on liian laaja. Parempi vaihtoehto ovat pienet funktiot, kuten ”listaa omat avoimet tilaukset”, ”lue sallitun tilauksen tila” tai ”valmistele tukipyyntö”. Jokainen funktio saa minimaalisen syötekaavan, palvelinpään käyttöoikeustarkistuksen, selkeät virhetilanteet ja rajoitetun tulosteen.

RAG-haulle suositellaan samaa logiikkaa: julkiset lähteet julkiseen hakutilaan ja tiliin liittyvät dokumentit asiakkuus- ja roolikohtaisesti suodatettuun hakutilaan. Suodattimet muodostetaan palvelinpäässä istunnosta, ei vapaasti muotoilluista chat-syötteistä. Muutokset lähteissä, rooleissa ja hyväksynnöissä kuuluvat dokumentoituun prosessiin; mallipohjan tarjoaa artikkeli Content Governance und Change Control.

Huomioi istunnon vanhentuminen, uloskirjautuminen ja jaetut laitteet

Chat-liittymä ei saa antaa vaikutelmaa, että käyttöoikeus säilyisi ikuisesti. OWASP Session Management Cheat Sheet kuvaa istunnon linkkinä tunnistautumisen, HTTP-liikenteen ja pääsynhallinnan välillä. Kun istunto vanhentuu, seuraavan yksityisen datan haun on epäonnistuttava turvallisesti. Vanhaa vastausta näkyvässä historiassa ei saa tulkita uudeksi käyttöoikeudeksi.

Tiimien tulisi myös testata uloskirjautumista, tilin vaihtoa, roolimuutoksia ja yhteiskäytössä olevia laitteita. Yksityiset keskusteluhistoriat eivät saa näkyä seuraavalle tilille vaihdon jälkeen. Kun istunto on vanhentunut, avustajan tulee ohjata käyttäjä selkeästi kirjautumaan uudelleen ilman, että se toistaa edellisen istunnon arkaluonteisia yksityiskohtia. Lokituksessa ja analysoinnissa pätee tietojen minimointiperiaate; artikkeli aiheesta datensparsamer Chatbot-Analytics esittelee sopivat tapahtuma- ja säilytysrajat.

Arkaluonteiset toiminnot vaativat oman vahvistuksen

Portaaliin kirjautuminen ei välttämättä riitä jokaiseen toimintoon. Jos chat muuttaa toimitusosoitetta, vahvistaa sopimuksen tai käynnistää maksun, järjestelmän tulee vaatia selkeästi tunnistettava, toimintokohtainen vahvistus. OWASP Transaction Authorization Cheat Sheet erottaa kirjautumisen ja tapahtuman hyväksynnän toisistaan ja edellyttää palvelinpään tarkistuksia sekä keskeisten tapahtumatietojen varmistamista.

Turvallinen toimintamalli on seuraava: chat kerää pyynnön, näyttää ymmärrettävän yhteenvedon, portaali tarkistaa nykyisen käyttöoikeuden ja vaatii tarvittaessa uudelleentunnistautumista tai toista tunnistautumistekijää. Vasta tämän jälkeen palvelinpään palvelu suorittaa täsmällisesti vahvistetun toiminnon. Jos kohde, summa tai muut keskeiset tiedot muuttuvat, aiempi hyväksyntä raukeaa.

Esimerkki: Palautus ilman tietovuotoa

Anonyymi henkilö kysyy: ”Voinko palauttaa tilaukseni?” Julkinen chat selittää yleisen palautuslogiikan ja ohjaa portaaliin. Se ei kysy täydellistä osoitetta tai maksutietoja. Kirjautumisen jälkeen portaalichat voi listata lukutyökalun avulla käyttäjän omat, palautuskelpoiset tilaukset. Kun henkilö valitsee tilauksen, palvelin tarkistaa uudelleen kohdekohtaisen käyttöoikeuden ja sovellettavat säännöt.

Varsinaista palautusta varten erillinen toimintatyökalu luo yhteenvedon. Henkilö vahvistaa tuotteet ja noutovaihtoehdon portaalin käyttöliittymässä. Jos tarkistus epäonnistuu, chat ei paljasta sisäisiä riskisignaaleja, vaan tarjoaa turvallisen seuraavan vaiheen. Jos tarvitaan ihmisen selvitystä, seuraa hallittu Human Handoff vain välttämättömällä ja hyväksytyllä kontekstilla.

Testausmatriisi ennen julkaisua (Go-live)

Testausmatriisin ei pitäisi testata vain ihannetapauksia. Käytä vähintään kahta tiliä, joilla on samanlaiset roolit mutta erilliset tiedot, ja testaa seuraavat tapaukset:

• Anonyymi pyyntö yleisistä tiedoista ja yksityisistä tilitiedoista.
• Kirjautunut tili A lukee oman kohteensa ja yrittää sen jälkeen tili B:n kohteen tunnistetta.
• Vanhentunut istunto, uloskirjautuminen, tilin vaihto ja roolin poistaminen kesken käynnissä olevan chatin.
• Kielen vaihtaminen kesken prosessin siten, että data-alue tai käyttöoikeudet eivät muutu.
• Prompt Injection -hyökkäys käyttäjän syötteissä ja haetuissa dokumenteissa.
• Lukutyökalun toimintahäiriö, aikakatkaisu ja ristiriitaiset taustajärjestelmän (backend) tiedot.
• Kirjoitustoiminto ilman vahvistusta, muutetuilla tiedoilla ja vanhentuneella vahvistuksella.
• Siirto ihmiselle (handoff) minimoidulla ja ymmärrettävällä keskustelukontekstilla.

Odotetut tulokset kuuluvat testiin jo etukäteen: Mikä vastaus on julkisesti sallittu? Mikä HTTP-virhe syntyy palvelinpäässä? Mikä tieto saa olla näkyvissä chatissa? Mikä tapahtuma lokitetaan ilman luottamuksellista sisältöä? Suunniteltu supistettu toimintatila (Degraded Mode) auttaa, kun tunnistautumis- tai taustajärjestelmäpalvelut epäonnistuvat; tätä varten on oma Incident-Response- und Rollback-Leitfaden.

Tarkistuslista kestävälle portaalirajalle

• Dokumentoi julkinen, tunnistautunut ja erityissuojattu vyöhyke.
• Mallinna tunnistautuminen, valtuutus ja tapahtumahyväksyntä erillään.
• Päättele tili ja asiakkuus (tenant) suojatusta istunnosta.
• Tarkista kohdekohtaiset käyttöoikeudet palvelinpäässä jokaisen luku- ja kirjoituskerran yhteydessä.
• Erota ja suodata teknisesti julkiset ja yksityiset RAG-lähteet.
• Rajaa työkalujen oikeudet minimiin; erota lukeminen ja kirjoittaminen.
• Huomioi chatissa istunnon vanhentuminen, uloskirjautuminen, tilin vaihto ja roolimuutokset.
• Tiivistä arkaluonteiset toiminnot selkeästi ja pyydä niille erillinen vahvistus.
• Rajoita siirto ihmiselle (handoff) ja lokitus vain välttämättömiin tietoihin.
• Testaa horisontaalisia pääsy-yrityksiä toistettavasti vähintään kahdella tilillä.

Tunnistautunut tekoäly-chatbot ei muutu turvalliseksi vain siksi, että se näkyy kirjautumisen takana. Turvallisuus syntyy siitä, että jokaisella tiedolla ja toiminnolla on todennettavissa oleva raja. Aloita siksi vyöhykekartasta ja testausmatriisista ennen kuin yhdistät yksityisiä tietolähteitä tai kirjoittavia työkaluja. Näin julkinen chat pysyy hyödyllisenä ja portaalichat toimintakykyisenä ilman, että molempia luottamusalueita sekoitetaan keskenään.

Lähteet

• 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