RAG-käyttöoikeudet verkkosivuston chatboteissa: Dokumenttien käyttöoikeuksien turvallinen hallinta

Verkkosivuston chatbot voi yhdistää vastauksia UKK-sivuilta, tuotedokumenteista ja sisäisistä tietolähteistä. Tämä on hyödyllistä – kunnes sama tietopohja sisältää sisältöä, jota ei ole tarkoitettu kaikille. Tällöin turvallista vastausta ei ratkaise pelkästään kielimallin laatu, vaan sitä edeltävä hakuvaihe (Retrieval): Mitä dokumentteja tämä tietty kysely saa yleensäkin nähdä?

RAG-käyttöoikeudet yhdistävät vahvistetut identiteetit, roolit tai ryhmät dokumenttien metadataan. Chatbot saa käyttöönsä vain valmiiksi suodatettuja lähteitä. Tavoite on tietoisesti rajattu: Mallin ei tule päättää kehotteen perusteella, onko jokin asia luottamuksellista. Sovellus rajaa sallitun kontekstin, dokumentoi tämän päätöksen ja valitsee epäselvissä tilanteissa turvallisen varavaihtoehdon (fallback).

Miksi kehotesäännöt eivät korvaa käyttöoikeuksien hallintaa

Järjestelmäohje kuten ”Älä anna sisäisiä tietoja” on hyödyllinen, mutta se ei ole käyttöoikeuskerros. Jos luvaton dokumentti pääsee kontekstiin, vastaus voi tiivistää sen, paljastaa sen epäsuorasti tai rakentaa sen uudelleen jatkokysymyksellä. Myös myöhempi tekstintarkistus on liian myöhäistä ja altista virheille. Turvallisuus alkaa siksi ennen generointia ja ihanteellisesti ennen tulosten järjestämistä paremmuusjärjestykseen.

Azure AI Search kuvailee Security Trimming -toimintoa suodatusmallina: Dokumentit sisältävät identiteetti- tai ryhmäarvoja; kysely sisältää vain pyynnön tekijän määritteet (Principals). Amazon Bedrock huomauttaa samalla tavoin, että ACL-tietoiset haku-suodattimet eivät korvaa tunnistautumista. Sovelluksesi on ensin itse luotettavasti tarkistettava identiteetti ja välitettävä vain vahvistettu konteksti.

Kestävän ratkaisun neljä rakennuspalikkaa

1. Vahvista identiteetti ja istunto palvelimen puolella

Julkisella chat-ikkunalla ei yleensä ole dokumenttioikeuksia. Se saa käyttää vain julkisia lähteitä. Asiakasportaalissa tai henkilöstöalueella henkilö sen sijaan tunnistetaan olemassa olevan kirjautumisen kautta. Lue rooli, organisaatio ja asiaankuuluvat ryhmät palvelimen puolella istunnosta tai allekirjoitetusta tokenista. Älä koskaan luota selaimen vapaasti lähettämään kenttään, kuten role=admin, tai chat-viestiin, joka väittää tiettyä jäsenyyttä.

2. Ylläpidä käyttöoikeusmetadataa jokaisen lähteen mukana

Jokainen tekstitakalo (Chunk) tarvitsee tekstin, URL-osoitteen ja päivämäärän lisäksi selkeän käyttöoikeustiedon: esimerkiksi audience=public, asiakasorganisaation tunnisteen (Tenant ID), sallittujen ryhmien luettelon tai luokituksen. Tämän metadatan on oltava peräisin samasta liiketoiminnallisesta lähteestä kuin dokumentin käyttöoikeuden. Erillinen taulukko, jota ylläpidetään vain satunnaisesti, aiheuttaa vaarallisia poikkeamia. Uusien dokumenttien ja ryhmäoikeuksien muutosten yhteydessä metadatan synkronointi kuuluukin julkaisu- tai crawl-työvoohon.

3. Suodata ennen paremmuusjärjestykseen asettamista (Ranking)

Kysely muodostaa suodattimen vahvistetusta kontekstista. Vasta tämän jälkeen arvioidaan semanttiset tai hybridiosumat. Näin luottamuksellinen käsikirja ei voi voittaa osuvimpana tuloksena tullakseen poistetuksi vasta myöhemmin. Useiden asiakasorganisaatioiden (Multi-tenancy) kohdalla Tenant ID on pakollinen suodatin, ei pelkkä ranking-signaali. Henkilötiedoille tai erityisen suojatuille tiedoille suositellaan lisäksi omaa tietoluokkaa yhdistetyn, vain loogisesti suodatetun kokoelman sijaan.

4. Kirjaa lähteet ja päätökset lokiin

Tukipalvelua ja vaaratilanteiden analysointia varten pelkät chat-transkriptiot eivät riitä. Jokaisesta pyynnöstä pitäisi pystyä jäljittämään, mitä ei-herkkiä identiteettiattribuutteja suodattimen muodostamiseen käytettiin, mikä suodatusluokka oli voimassa, kuinka monta osumaa suodattimen jälkeen jäi jäljelle ja mitkä lähteet päätyivät todellisuudessa kehotteeseen. Älä tallenna tarpeettomia kokonaissisältöjä tai tokeneita. Tietoja säästävä auditointitapahtuma tekee virheistä jäljitettäviä ilman, että valvonnasta muodostuu toinen tietovuoto.

Käytännön toimintamalli verkkosivustotiimeille

1. Määritä jokainen tietolähde selkeälle kohderyhmälle: julkinen, asiakas, kumppani, sisäinen tiimi tai tietty asiakasorganisaatio.
2. Määritä, mitkä istuntoväittämät (Session Claims) todistavat tämän kohderyhmän. Identiteettijärjestelmän ryhmät ovat luotettavampia kuin vapaasti valittavat lomakesyötteet.
3. Siirrä nämä väittämät palvelinpuolella hakusuodattimeen ja salli vain pieni, tunnettu määrä suodatinkenttiä.
4. Suorita vertailu jokaisen crawlin yhteydessä: uudet, muuttuneet ja poistetut dokumentit tarvitsevat myös päivitetyt käyttöoikeusmetatiedot.
5. Anna mallille vain suodatetut osumat sekä selkeä ohje olla arvailematta puuttuvia tietoja.
6. Jos osumia ei löydy, lähteet ovat ristiriitaisia tai käyttöoikeus on epäselvä, ohjaa käyttäjä turvalliseen yhteydenottotapaan.

Tämä toimintamalli täydentää artikkelissamme