LLM integrāciju drošība: kāpēc ar aizsardzības barjerām vien nepietiek

Tērzēšanas robots, kas tikai pārfrāzē tekstu, ir pārvaldāms risks. Tiklīdz tas pats robots tiek pieslēgts zināšanu bāzei un saņem tiesības izveidot pieteikumu vai izsaukt API, tas vairs nav tērzēšanas robots, bet jauna uzbrukuma virsma ar piekļuvi uzņēmuma sistēmām. Pēdējos divos gados šis lēciens ir noticis gandrīz katrā organizācijā, un parasti ātrāk, nekā tam paspēja sekot LLM integrāciju ielaušanās testēšana.

Šajā rakstā apkopoti uzbrukuma veidi, kas LLM integrācijās sastopami praksē, iemesli, kāpēc parastie drošības pasākumi tos nenoķer, kā arī tas, ko MI un LLM integrāciju ielaušanās testēšanā pārbaudām un ko organizācijai sagatavot iepriekš.

Kāpēc LLM lietotnes testēšana ir atsevišķa disciplīna

Parastā lietotnē robeža ir skaidra: kods ir norādījums, ievaddati ir dati. SQL injekcija darbojas tieši tāpēc, ka vienā vietā šī robeža nejauši pazuda, un ar sagatavotiem vaicājumiem to var strukturāli atjaunot.

Valodas modelī tādas robežas principā nav. Sistēmas uzvedne, lietotāja jautājums, no indeksa izgūtie dokumenti un rīku atbildes nonāk vienā konteksta logā kā viena teksta plūsma. Modelis tos sver statistiski, bet nevienu noteikumu neievieš piespiedu kārtā. Sagatavotam vaicājumam šeit nav līdzinieka.

No tā izriet viens teikums, kas apkopo visu disciplīnu: katrs teksts, kas nonāk kontekstā, ir potenciāls norādījums. Augšupielādēts PDF, apstrādāts e-pasts, komentārs pieteikumā, lejupielādēta tīmekļa lapa, ieraksts vektoru datubāzē.

Uzbrukuma veidi, kas atkārtojas praksē

Prompt injection jeb ļaunprātīga uzvedne

Tiešais variants ir pazīstams: lietotājs raksta „ignorē visus iepriekšējos norādījumus“ un pārbauda formulējumu pēc formulējuma, līdz kāds iziet cauri. Salīdzinājums ar SQL injekciju ir noderīgs, taču nepilnīgs. Datubāzei ir gramatika un interpretators; valodas modelis saņem tekstu vienā plūsmā, un tajā nav loģiska nosacījuma, pie kura tas varētu apstāties.

Bīstamāks ir netiešais variants (indirect prompt injection). Norādījums nav lietotāja ievadē, bet saturā, ko sistēma izvelk pati: augšupielādētā dzīves aprakstā, ienākoša e-pasta parakstā, produkta aprakstā, tīmekļa lapā, ko aģents lejupielādē. Lietotājs neko ļaunprātīgu nav ievadījis. Viņš uzdod nevainīgu jautājumu, bet modelis izpilda trešās puses norādījumu.

Ka tā nav teorija, rāda dokumentēts gadījums. Profesors Marks Rīdls (Mark Riedl) savā profila lapā baltiem burtiem uz balta fona ierakstīja norādījumu meklēšanas modelim apgalvot, ka viņš esot laika ceļojumu eksperts. Bing modelis atbildē par viņu to tiešām apgalvoja. Uzbrucējam pietiek sagatavot norādījumu iepriekš: HTML komentārā, attēla metadatos, alternatīvajā tekstā vai citā laukā, kurā parasti neviens neieskatās. Šīs kategorijas detaļas apkopotas vikilapā par prompt injection, bet paņēmiens, ar kuru sarunas saturs tiek izvadīts uz svešu domēnu attēla adreses formā, aprakstīts lapā Markdown Exfiltration Channels.

Jailbreak un aizsardzības barjeru apiešana

Jailbreak ir prompt injection galējais gadījums: sagatavotā ievade apiet nevis vienu noteikumu, bet visus uzreiz. Modelis pārstāj filtrēt saturu, iziet no tam noteiktajiem ierobežojumiem un uzraksta arī to, kas tam ir tieši aizliegts.

Cik trausli šie ierobežojumi ir, rāda 2025. gada pārbaude. Drošības pētnieki DeepSeek R1 modelim izmēģināja 50 dažādas jailbreak uzvednes, un izdevās visas 50, proti, tika pārkāpti 100% drošības noteikumu. Ātri publicētiem atvērtā pirmkoda modeļiem iebūvētais ierobežojums bieži ir drīzāk izskats nekā aizsardzība, un to ir vērts zināt jau tad, kad modeli izvēlas.

Datu noplūde no RAG avotiem

Biežākais reālais konstatējums uzņēmumu risinājumos ir arī visneiespaidīgākais: piekļuves tiesības piemēro pēc meklēšanas, nevis pirms tās. Vektoru indeksā glabājas visu nodaļu dokumenti, bet filtrēšana notiek tikai rezultātu sarakstā vai nenotiek nemaz. RAG (retrieval-augmented generation) risinājumā tieši meklēšana izšķir, kas nonāks kontekstā, tāpēc piekļuves loģikai jāstrādā turpat.

Darbinieks neprasa dokumentu, kuram viņam nav piekļuves. Viņš pajautā: „Apkopo, kādas atalgojuma robežas attiecas uz nodaļu vadītājiem.“ Un saņem atbildi. Neviens piekļuves žurnāls pārkāpumu neuzrāda, jo formāli tāda arī nebija.

Tajā pašā kategorijā ir sistēmas uzvednes noplūde. Bing Chat agrīnā versija, kas pazīstama ar nosaukumu Sydney, savu slepeno sistēmas uzvedni kopā ar iekšējiem noteikumiem izdeva pēc viena norādījuma atklāt iepriekšējo instrukciju saturu. Piemērs parādīja, ka arī Microsoft mēroga piegādātājam iekšējos norādījumus var izvilkt ar vienu triku. Ja sistēmas uzvednē ir ierakstītas API atslēgas vai galapunkti, kopā ar to noplūst arī tie; sīkāk par to vikilapās System Prompt Extraction un Cross-Session Context Bleed.

Otrs slānis ir apmācības dati un uzņēmuma konteksts. Ja modelis ir papildus apmācīts ar iekšējiem dokumentiem, uzbrucējs ar jautājumu virkni var mēģināt atjaunot to fragmentus; to sauc par inference attack jeb model inversion. Beigās ārpusē var nonākt pirmkoda fragments, API atslēga vai personas dati, kuriem organizācijas sistēmas nekad nebija jāatstāj. OWASP Top 10 for LLM Applications sarakstā šī kategorija ir nosaukta atsevišķi kā Sensitive Information Disclosure.

Pārāk plašas MI aģenta tiesības

Ekonomiski smagākā kategorija. Asistents, kas apstrādā rēķinus, saņem rakstīšanas tiesības grāmatvedības sistēmā. Klientu atbalsta aģents saņem tiesības atiestatīt paroles. Kamēr modelis saņem tikai tos norādījumus, kurus izstrādātājs ir paredzējis, viss darbojas. Tiklīdz kāds caur svešu saturu ieraksta tur savu norādījumu, sistēma izpilda viņa nodomu ar jūsu tiesībām.

Šeit pieder arī SSRF. Ja asistents drīkst izsaukt iekšējo API, piemēram, fonā nosūtīt uzaicinājumu jaunam lietotājam, tad labi formulēts norādījums to pagriež pret citiem, jutīgākiem galapunktiem: liek mainīt lomas vai dzēst kontus. Aģents tādā brīdī iziet no savas lomas un izdara to, ko neviens tam nav atļāvis.

Pārbaudes jautājums nekad nav „vai modeli var ietekmēt“, jo var vienmēr. Jautājums ir cits: kas ir ļaunākais, ko veiksmīga ietekmēšana spēj palaist? Par to vikilapas Excessive Agency un Approval Gate Bypass.

Modeļa atbildes nedroša tālāka apstrāde

Modeļa atbildi ikdienā uztver par uzticamu rezultātu un tad attēlo saskarnē, ievieto datubāzes vaicājumā vai izpilda kā kodu. Līdz ar to atgriežas klasiskā injekcija, tikai modelis ir starpstacija: ja modeli var piespiest izvadīt <script> birku vai ; DROP TABLE, atliek vienīgi jautājums, ko ar to izdara nākamā sistēma. Tas pats attiecas uz kodu, ko modelis uzraksta izstrādātājam un ko kāds palaiž bez pārskatīšanas. Detaļas vikilapās Improper Output Handling un Insecure AI-Generated Code.

Indeksa saindēšana un manipulētas atbildes

Ja sistēma indeksē saturu automātiski, piemēram, koplietotas mapes, ienākošos e-pastus vai publiskas lapas, uzbrucējs var ievietot saturu, kas indeksā paliek un turpmākajos vaicājumos parādās kā konteksts. Uzbrukumu izdara vienreiz, bet tas iedarbojas atkārtoti. Šo kategoriju apraksta vikilapa RAG Index Poisoning.

No tā izaug smalkāka manipulācija, ko tirgū sauc par LLM-SEO. Interneta veikals savā lapā paslēpj teikumu par to, ka MI sagatavotā produktu apskatā jāuzsver tieši šī veikala prece; modelis paslēpto norādījumu uzsūc, un klients saņem izkropļotu salīdzinājumu. Smagāks gadījums ir tad, kad uzņēmuma tērzēšanas robotu piespiež uzrakstīt kaitīgu vai aizskarošu atbildi: organizācija riskē ar savu reputāciju, un blakus stāv arī juridiskie jautājumi, piemēram, ja tās pašas asistents dod padomu prettiesiskai darbībai.

Neierobežots patēriņš

Mazāk par konfidencialitāti un vairāk par rēķinu. Vaicājumi, kas modelim liek ģenerēt maksimāli garas atbildes, rekursīvi izsaukt rīkus vai atkārtot meklēšanu, dzen patēriņu augšup, bet neviens brīdinājums neiedegas. Tirgū to sauc par denial of wallet; mehānismu apraksta vikilapa Denial-of-Wallet Loops.

Kāpēc ar parastajiem drošības pasākumiem nepietiek

Atšķirība no parastās programmatūras ir principiāla. Klasiskai programmai loģika ir noteikta iepriekš: ja X, tad Y. Modeļa uzvedība veidojas no apgūtajām sakarībām un konkrētās uzvednes, tāpēc, ja kontekstā iekļūst ļaunprātīgs norādījums, lietotnē nav nosacījuma, kas to apturētu. Aizsardzības paņēmieni, kas darbotos visos apstākļos, šobrīd nav zināmi. Arī daudzslāņaina sistēmas uzvedne un detalizēts noteikumu saraksts lūst pie vienas veiksmīgas pavēles, kā to parādīja Sydney gadījums.

Cik izplatīta problēma ir, rāda arī tirgus dati. Pēc Kroll apkopojuma 92% MI sistēmu ielaušanās testu atklāja, ka pārbaudītais modelis ir ievainojams pret kādu prompt injection formu, un 80% no atrastajām kļūdām ir novērtētas kā vidēji smagas vai smagākas. Praktiski katrā pārbaudītajā risinājumā tātad bija sprauga, caur kuru modeļa noteikumus varēja salauzt.

Doma nav tāda, ka uzskaitītie pasākumi būtu lieki. Doma ir tāda, ka tie visi darbojas teksta līmenī, bet teksta līmenī šo robežu ieviest nevar. Ieviest to var vienu līmeni zemāk: tiesībās, ar kurām rīks tiek palaists.

Ko pārbauda LLM integrācijas ielaušanās testā

Pārklājuma secību ņemam no OWASP Top 10 for LLM Applications, bet faktisko tvērumu nosaka jūsu arhitektūra: no kurienes modelis saņem tekstu, kam tas var piekļūt un kas ar atbildi notiek tālāk. Atsevišķas kategorijas kopā ar tehnisko aprakstu un risinājumu apkopotas LLM vikilapās.

Gaita ir tāda pati kā parastā ielaušanās testā: tvēruma un noteikumu saskaņošana, izlūkošana, testu izpilde ar pierādījumiem, padziļināšana, ziņojums un atkārtota pārbaude. Norobežotas sarunas saskarnes vai RAG risinājuma pārbaude parasti aizņem piecas līdz desmit darba dienas. Aģentu risinājumi ar vairākiem rīkiem un deleģēšanu citiem aģentiem prasa vairāk, jo katra rīka tiesības pārbauda atsevišķi. Ziņojumā konstatējumi ir sakārtoti pēc riska: ko izdevās panākt, kā to atkārtot un ar kādām izmaiņām to novērst.

Ko par to saka Latvijas regulējums

Latvijas kiberdrošības regulējums mākslīgo intelektu neizceļ atsevišķi, taču drošības prasības attiecas uz visiem informācijas sistēmas komponentiem. Nacionālās kiberdrošības likuma (turpmāk – NKDL) 25. panta piektās daļas 2. punkts uzliek kiberdrošības pārvaldniekam pienākumu ne retāk kā reizi gadā veikt informācijas un komunikācijas tehnoloģiju drošības pārbaudi un atbilstoši tās rezultātiem organizēt konstatēto trūkumu novēršanu. Ministru kabineta noteikumu Nr. 397 „Minimālās kiberdrošības prasības“ 131. punkts A klases informācijas sistēmai prasa ielaušanās testu pirms nodošanas ekspluatācijā un pēc tam vismaz reizi trijos gados.

Ja modelis piekļūst šādas sistēmas datiem, integrācija nav izņēmums: tā ir tāda pati pārbaudāmā virsma kā API vārteja vai iekšējs serveris. Uz ko un cik bieži šis pienākums attiecas, apskatīts atsevišķi rakstā par to, vai ielaušanās testēšana ir obligāta.

Ja modelis var piekļūt personas datiem, jautājums pārceļas uz datu aizsardzības pusi. Vispārīgās datu aizsardzības regulas (VDAR) 32. panta 1. punkta d) apakšpunkts prasa regulāri testēt, izvērtēt un novērtēt drošības pasākumu efektivitāti, bet nenosaka, kādai tieši pārbaudei ir jābūt. Noplūde caur asistentu savukārt ir personas datu aizsardzības pārkāpums, un tam seko attiecīgie paziņošanas termiņi, tostarp paziņošana Datu valsts inspekcijai.

Trešais dokuments ir Eiropas Parlamenta un Padomes regula (ES) 2024/1689 jeb MI akts. Tās 50. pants, ko piemēro no 2026. gada 2. augusta, prasa caurskatāmību: cilvēkam ir jāzina, ka viņš sarunājas ar MI sistēmu, un mākslīgi radīts saturs ir jāmarķē. Tā nav drošības prasība, tomēr tā skar tieši to slāni, kuru pārbauda tests: ja prompt injection spēj piespiest tērzēšanas robotu noliegt savu mašīnisko dabu vai izlaist marķējumu, tehniska kļūda pārtop par regulējuma jautājumu.

Vienu lietu ir vērts pateikt uzreiz. HAXORIS ir Slovākijas uzņēmums, un NKDL 44. pantā noteikto atbilstības auditu neveicam; to veic neatkarīgs kiberdrošības auditors. Strādājam tehniskajā pusē, proti, testējam sistēmas un sagatavojam ziņojumu, kuru auditors var pārbaudīt. Kā šī procedūra norit un kurš to drīkst veikt, aprakstīts rakstā par kiberdrošības auditu.

Ko sagatavot pirms testa

Sagatavošanās nosaka, cik dziļi testā vispār var tikt. Praksē noder pieci punkti.

• Piekļuve vismaz diviem lietotājiem ar dažādām tiesībām. Tas nav ērtības jautājums, bet priekšnosacījums, lai autorizācijas kļūdas vispār varētu pierādīt. Bez otra lietotāja biežākā smago konstatējumu grupa paliek nepārbaudīta.


• Pieslēgto rīku un datu avotu saraksts kopā ar tiesībām, ar kurām tie darbojas. Tieši šis saraksts nosaka, cik daudz darba prasīs aģentu daļa.


• Sistēmas uzvedne, ja to ir iespējams nodot. Ja nodot to nevarat, parasti izlasām to tāpat, un tad tas ir pirmais konstatējums.


• Testa vide ar reālistiskiem, bet ne īstiem datiem. Modeļa uzvedība ir atkarīga no satura, tāpēc tukša vide dod tukšus rezultātus.


• Rakstiski saskaņots tvērums un darbību laiks. Lielākas slodzes testus saskaņojam iepriekš, lai tie nesakristu ar produkcijas pīķiem.

Ko ieviest neatkarīgi no testa

• Tiesības rīka līmenī, nevis uzticēšanās tekstam. Rīks strādā ar jautātāja tiesībām, nevis ar lietotnes tiesībām. Viss pārējais ir aizsardzība nepareizā līmenī. Ja aģents strādā ar datubāzi, piešķiriet lasīšanas tiesības konkrētiem datiem, nevis visam kopumam.


• Autorizācija pirms meklēšanas. Vektoru indekss drīkst atgriezt tikai to, ko jautātājs redzētu tāpat. Filtrēšana pēc meklēšanas nav piekļuves kontrole.


• Apstiprinājums visam neatgriezeniskajam. Maksājumi, dzēšana, izejošie ziņojumi, tiesību maiņa: apstiprina cilvēks, un apstiprinājums parāda, kas tieši notiks.


• Slāņota uzvedne un ievades izolācija. Sistēmas norādījumi, izstrādātāja norādījumi un lietotāja ievade dzīvo atsevišķi. Neapstrādāta lietotāja ievade nekad nenonāk sistēmas uzvednes priekšā. Slāņošana nav necaursitama, bet tā ir pirmā aizsardzības līnija; noderīgi ir arī ierobežot ievades garumu un formātu.


• Modeļa atbilde ir neuzticami ievaddati. Izturieties pret to tā visur, kur to attēlo, izpilda vai ievieto vaicājumā. Ģenerētu kodu vispirms izlaidiet caur statisko analīzi un palaidiet tikai izolētā vidē; vaicājumā meklējiet negaidītu komandu, jo SELECT nedrīkst pēkšņi kļūt par DELETE.


• Pierakstiet to, ko modelis ierosināja, nevis tikai to, ka tas atbildēja. Bez šīs pēdas incidentu atjaunot nevar, un tieši pieraksti ļauj savlaicīgi pamanīt atkārtotus injekcijas mēģinājumus.


• Nekādu noslēpumu sistēmas uzvednē. Tā nav droša glabātuve, bet konteksts.


• Apmācības un skaidri noteikumi komandai. LLM riskus saprot ne tikai drošības speciālisti, bet arī izstrādātāji un produktu īpašnieki. Nosakiet, kādus datus modelim drīkst nodot un kā tā atbildi izmanto tālāk; kritiskiem lēmumiem prasiet cilvēka apstiprinājumu.

Drošība nav vienreizējs stāvoklis. Modeli un vidi ap to ir vērts pārbaudīt atkārtoti pēc katras būtiskas izmaiņas: nomainot vai atjauninot modeli, pieslēdzot jaunu datu avotu, pievienojot rīku vai mainot tiesības. OWASP iesaka, lai šāda testēšana būtu konsekventa un sekotu katrai nozīmīgai modeļa izmaiņai.

Kopsavilkums

MI ieviešana dod iespējas un vienlaikus ienes ievainojamību klasi, kādu parastajās lietotnēs nepazinām. Uzbrukums pienāk kā nevainīgs teksts un iziet cauri visiem ugunsmūriem, tāpēc drošību plāno projekta sākumā, nevis pielīmē beigās. Neviens atsevišķs noteikums un neviens atsevišķs filtrs nepasargā no visa; nostrādā slāņi, un svarīgākais no tiem ir tas, ar kādām tiesībām rīks darbojas. Sagatavošanās un pārbaude izmaksā daudzkārt mazāk nekā incidenta seku novēršana.

HAXORIS šajā jomā strādā tehniskajā pusē. Veicam MI un LLM integrāciju ielaušanās testēšanu, ap modeli esošās tīmekļa lietotnes ielaušanās testēšanu atbilstoši OWASP WSTG vadlīnijām, bet gatavību NKDL un NIS2 prasībām novērtējam atsevišķi, kā aprakstīts NIS2 ielaušanās testēšanas lapā. Ja MI funkcijas jau ir produkcijā vai tuvojas palaišanai, piesakieties bezmaksas konsultācijai, un kopā ar jūsu komandu saskaņosim tvērumu.

LLM integrāciju testēšana – biežāk uzdotie jautājumi

Avoti: raksta ieteikumi un piemēri balstīti publiski pieejamos avotos, tostarp OWASP Top 10 for LLM Applications sarakstā, drošības uzņēmumu analīzēs un plašsaziņas līdzekļos dokumentētos incidentos. No visiem izriet viens un tas pats: MI drošība nav teorētisks jautājums, bet ikdienas darbs, kurā sagatavošanās, pārbaude un speciālistu iesaiste kopā notur risku noteiktās robežās.

Saistītie Haxoris pakalpojumi: MI un LLM integrāciju ielaušanās testēšana