Лични подаци не смеју до LLM-а — маскирање само по себи ипак пропушта

|Аутор: Уредништво QUASA|5 мин читања
Лични подаци не смеју до LLM-а — маскирање само по себи ипак пропушта

Да лични и поверљиви подаци не би стигли до облачног LLM провајдера, сваки одлазни захтев треба да прође кроз локални контролни слој. Он открива осетљиве вредности, замењује их стабилним сурогатима када су односи у тексту потребни за одговор, а захтев задржава локално или одбија ако преостали контекст открива идентитет.

Контрола мора да обухвати цео садржај који се шаље: кориснички упит, историју разговора, прилоге, преузете документе и резултате алата. OWASP-ове смернице препоручују чишћење осетљивог садржаја пре обраде и упозоравају да ограничење записано само у системском упутству може бити заобиђено.

Поставите контролу на излазну тачку

Апликација треба да позива облачни API искључиво преко локалног посредника који проверава коначно састављено тело захтева. Провера само поља у форми није довољна ако други део апликације накнадно дода историју, резултат претраге или садржај датотеке. И поновљени покушаји слања морају да користе исту излазну тачку и исту политику.

Посредник најпре одређује шта задатак захтева, а затим саставља уску листу поља која смеју да напусте апликацију. Ако је кориснику потребна класификација поруке, моделу можда није потребан цео досије из кога је порука преузета. Метаподаци, прилози и раније поруке не треба да уђу у захтев само зато што су доступни у меморији апликације.

Одлука о рути следи после тог избора: садржај без осетљивих података може у облак, препознатљиве вредности се замењују само ако тиме задатак задржава смисао, а ризичан садржај остаје локално или се одбија. Та одлука припада коду посредника и правилима приступа, не тексту који модел може да протумачи као упутство.

Подесите детекцију за домаће и интерне формате

Општи детектор је полазиште; додатни препознавачи треба да одражавају податке које апликација заиста обрађује. У Србији то могу бити ЈМБГ, телефонски бројеви, бројеви рачуна и адресе, али и интерне ознаке корисника, предмета и купаца. Ако запослени помоћу такве ознаке могу да утврде особу, за излазни захтев она је идентификатор и када не личи на име.

За структурирана поља употребите шему података пре претраге слободног текста: вредност у пољу означеном као број рачуна већ има познато значење. У слободном тексту комбинујте обрасце, проверу формата, речнике интерних ознака и препознавање ентитета. Тестови треба да обухвате ћирилицу и латиницу, размаке, цртице и друге облике у којима исти податак може да се појави.

Посебно разврстајте лозинке, приступне кључеве и сличне тајне. Њихова замена сурогатом често не помаже задатку: локални поступак може да провери формат или да објасни грешку без слања саме вредности. Пропуст у детекцији иначе остаје пропуст у одлазном захтеву, ма колико поуздан био оператор који мења већ пронађене вредности.

Сачувајте односе стабилним сурогатима

Када је за одговор важно да се иста особа или исти налог помиње више пута, свако понављање замените истим типизираним токеном у оквиру захтева или овлашћене сесије. Условни пример: два помињања исте имејл адресе постају EMAIL_1, док друга адреса постаје EMAIL_2. Модел тако види да су помињања повезана, а изворне вредности остају у локалној мапи.

Документација Presidio Anonymizer-а описује замену, брисање, маскирање, хеширање и шифровање детектованих ентитета, као и прилагођене операторе. Оператор ради над вредностима које су претходно откривене; сам избор начина замене не поправља промашену детекцију. Документација такође наводи да насумична со код хеширања подразумевано даје различите резултате за исту вредност, па апликација мора посебно да реши очување везе између понављања.

Локалну мапу токена ограничите на потребну сесију и доступном је учините само делу апликације који сме да врати изворну вредност. Мапа, со и кључеви не улазе у облачни захтев. Трајан токен који прати исту особу кроз неповезане кориснике може сам да постане средство повезивања, чак и ако не открива њено име.

Усмерите локално оно што замена не може да очисти

После замене процените цео одлазни текст, укључујући оно што детектор није означио. Опис јединствене улоге, родбинске везе или ретког пословног догађаја може да упути на особу без имена, адресе и броја. Ако су баш ти односи неопходни за задатак, њихово уклањање може да уништи питање; такав захтев треба обрадити локално или одбити.

У истраживању LLM-Redactor са 1.300 синтетичких упита, комбинација локалног рутирања, редиговања и преформулисања имала је 0,6% комбинованог цурења у подскупу од 500 упита са изричитим личним подацима, док је цурење у групи са косвеним идентитетом остало знатно веће. Мерени су енглески, вештачки састављени примери, па тај резултат није стопа коју треба очекивати у апликацији на српском.

Практична одлука је везана за конкретан задатак. Ако локални модел или обично програмско правило могу да га обаве, облачни позив није потребан. Ако облачни модел треба само да реши издвојен део проблема, посредник може да пошаље уже питање са неопходним сурогатима, без изворног документа и сувишне историје. Захтев који и после тога омогућава препознавање особе или поверљивог случаја не треба означити као безбедан само зато што детектор више не налази очигледан идентификатор.

Контролишите повратак и мерите цурење

По пријему одговора, стварне вредности враћајте само у овлашћеној сесији и само на местима која тачно одговарају токенима из њене локалне мапе. Пре приказивања или уписа у други систем проверите да ли је модел поновио преостали осетљив контекст или изменио токен. Ако токен није препознат, немојте нагађати којој вредности припада.

У оперативном логу бележите одлуку правила, врсту откривеног ентитета, верзију препознавача, изабрану руту и разлог одбијања. Изворни упит, замењене вредности, локална мапа и пун одговор нису потребни за уобичајено бројање одлука. Проверите и да ли библиотеке за HTTP позиве, пријаву грешака или поновљене покушаје аутоматски бележе тело захтева пре него што га посредник очисти.

Тест цурења саставите од означених, измишљених улаза који личе на садржај апликације: различити записи истог идентификатора, ћирилица и латиница, приложени текст, интерне ознаке и описи који откривају особу само кроз односе. Проверавајте стварно тело захтева на излазној тачки, затим доследност сурогата, одлуку о рутирању и поступање са одговором. Када тест открије пропуст, додајте његов измишљени еквивалент у скуп примера за следећу измену правила.

Прочитајте и:

Подели:

Претплатите се на наш билтен

Добијајте најновије вести о Web3, AI-у и криптовалутама директно у пријемно сандуче.

0