MI un LLM integrāciju ielaušanās testēšana
MI un LLM integrāciju ielaušanās tests jeb pentests ir kontrolēts uzbrukums lietotnei, kurā savu darbu dara mākslīgais intelekts (MI) un LLM. Modelis saņem tekstu un saņemto tekstu uztver par norādījumu, tāpēc prompt injection jeb ļaunprātīga uzvedne, jailbreak, datu noplūde un piekļuves tiesību apiešana nav teorētiski riski, bet izmantojami uzbrukuma ceļi.
Testējam atbilstoši OWASP Top 10 for LLM metodoloģijai, un uzbrukuma scenārijus izspēlējam ar rokām: automatizēts rīks neredz to, kas izšķiras uzvednes tekstā un modeļa atbildē. LLM integrāciju ielaušanās testēšana aptver pašu modeli, MI aģentus un RAG, API un visu integrācijas vidi – identitāti, piekļuves loģiku un aizsardzības barjeras.
Testējam gan lietotnes, kurās modelis atbild klientam, gan iekšējos risinājumus, kuros MI apstrādā dokumentus un sagatavo atbildes darbiniekiem. Tvērumu un mērķus saskaņojam rakstiski pirms darba sākuma.
Mums uzticas
Kas ir MI un LLM integrāciju ielaušanās testēšana un kāpēc tā ir svarīga?
Lietotne, kas izmanto LLM, tekstu saņem vienlaikus no vairākiem avotiem: no lietotāja, no RAG indeksā ielādētajiem dokumentiem un no ārējo API atbildēm. Jebkurā no tiem var paslēpt norādījumu, ko modelis izpildīs. Pārbaudām, cik tālu šāds norādījums tiek: vai noplūst dati, vai izdodas apiet piekļuves tiesības un vai iedarbojas rīks, kas lietotāja rokās nekad nebija paredzēts.
Darba beigās saņemat ziņojumu, kurā konstatējumi sakārtoti pēc riska: ko izdevās panākt, kā to atkārtot un ar kādām izmaiņām to novērst. Vislielāko labumu pārbaude dod pirms palaišanas produkcijā, kamēr arhitektūru vēl var mainīt.
Pieredze
Testējam LLM integrācijas, kas jau strādā produkcijā, nevis demonstrācijas piemērus. Uzbrukuma paņēmienus, ko izmantojam, aprakstām un uzturam savā publiskajā zināšanu bāzē par OWASP Top 10 for LLM (angļu valodā).
Caurskatāmība
Tvērumu un testa mērķus fiksējam pirms darba sākuma. Testēšanas laikā jebkurā brīdī zināt, kurā posmā esam un kas līdz šim atrasts.
Sadarbība
Strādājam kopā ar to komandu, kas lietotni izstrādā. Par kritisku konstatējumu ziņojam tajā pašā dienā, nevis noslēguma ziņojumā.
Profesionalitāte
Strādājam ar rakstisku atļauju un iepriekš saskaņotā tvērumā. Katru soli protokolējam tā, lai to varētu atkārtot, un ārpus tvēruma neizejam.
Testēšanas gaita
Kā notiek MI un LLM integrāciju ielaušanās tests?
Sākam ar draudu modelēšanu (threat modeling) konkrētajā arhitektūrā, un pēc tam praksē izspēlējam to, kas modelēts. Produkcijas vidē neveicam darbības, kas varētu izraisīt pārtraukumu, un lielākas slodzes testus saskaņojam iepriekš.
Tvērums un arhitektūra
Kartējam datu plūsmas un integrācijas punktus: no kurienes modelis saņem tekstu un kam tas var piekļūt.
Uzvedņu, API un integrāciju pārbaude
Ejam cauri ievaddatiem, piekļuves loģikai un aizsardzības barjerām.
Uzbrukuma scenāriju izspēle
Noskaidrojam, cik izturīga ir ap modeli uzbūvētā aizsardzība: jailbreak, datu izvilkšana, ļaunprātīga rīcība ar MI aģenta rīkiem.
Ziņojums, ieteikumi un atkārtota pārbaude
Katram konstatējumam pievienojam strādājošu pierādījumu (PoC), un pēc labojumiem veicam atkārtotu pārbaudi.
Tvērums
Ko pārbaudām MI un LLM integrācijās?
Skatāmies visu ķēdi: pašu modeli, tajā ielādētos datus, MI aģentam pieejamos rīkus, aizsardzības barjeras un notikumu pierakstus.
LLM integrācijas
OpenAI un Azure OpenAI, Anthropic, Mistral, kā arī lokāli darbināti modeļi.
RAG un zināšanu bāze
Datu ielāde, indeksēšana, meklēšana un vektoru datubāzes, tostarp indeksā iepludināti saindēti dokumenti.
MI aģenti un rīki
Rīku izsaukšana (tool use, function calling), spraudņi un darbplūsmu vadība.
API un autentifikācija
OAuth2/OIDC, API atslēgas, pieprasījumu skaita ierobežojumi un webhook izsaukumi.
Uzvednes un aizsardzības barjeras
Sistēmas uzvedne, filtri, moderācija un politikas noteikumi, proti, viss tas slānis, ko testā mēģinām apiet.
Žurnāli un uzbrukuma pamanīšana
Notikumu pieraksti, brīdinājumi un ļaunprātīgas izmantošanas atpazīšana: vai kāds uzbrukumu vispār pamana.
Metodika
Ko dod OWASP Top 10 for LLM?
OWASP Top 10 for LLM ir saraksts ar biežākajām ievainojamībām LLM lietotnēs, un to uztur pati nozare. No tā ņemam riska secību, taču faktisko pārklājumu nosaka konkrētā arhitektūra: no kurienes modelis saņem tekstu, kam tas var piekļūt un kas ar atbildi notiek tālāk.
Saraksta pirmajā vietā ir prompt injection, un praksē visvairāk problēmu sagādā tā netiešā forma (indirect prompt injection): norādījums, kas paslēpts dokumentā, tīmekļa lapā vai e-pastā, ko modelis izlasa pats. Lietotājs neko ļaunprātīgu nav ievadījis, bet modelis norādījumu izpilda.
Otra puse ir tas, ko modelis drīkst darīt. Ja MI aģentam ir pieejams rīks, kas sūta e-pastu, veic maksājumu vai lasa datubāzi, veiksmīga injekcija vairs nav teksta problēma, bet darbība sistēmā. Tāpēc pārbaudām ne tikai modeļa atbildes, bet arī piešķirtās tiesības un to, vai kāds tās pārbauda pirms izpildes.
RAG risinājumos sekojam datu ceļam: kas dokumentus ievieto indeksā, vai indeksā nonāk saturs no ārpuses un vai meklēšana ievēro to pašu piekļuves tiesību modeli, kas pārējā sistēmā. Tipiskākā kļūda ir viens kopīgs indekss visiem lietotājiem: atbilde tad var atklāt to, kam konkrētais lietotājs nekad nav drīkstējis piekļūt.
OWASP nav standarts, ko varētu sertificēt, un apliecinājumu par to neviens neizsniedz. Tā ir atklāta metodika, un tieši tāpēc tā der par kopīgu valodu: gan izstrādātājs, gan pasūtītāja drošības komanda saprot, uz ko ziņojumā ir atsauce.
Pakalpojumu salīdzinājums
MI integrācijas tests vai parasts lietotņu ielaušanās tests?
Parasts lietotņu tests skatās kodu, konfigurāciju un lietotnes slāni. MI integrācijas pārbaude iet soli tālāk: tā vēro, kā uzvedas pats modelis un tam pieejamie rīki.
| Kritērijs | MI un LLM integrāciju tests | Parasts lietotņu ielaušanās tests |
|---|---|---|
| Uzmanības centrā | Uzvednes, MI aģenti, RAG un modeļa loģika | Tīmekļa un mobilās lietotnes ar aizmugursistēmu |
| Tipiskie draudi | Prompt injection, jailbreak, datu noplūde | SQL injekcijas, XSS, CSRF, autentifikācijas apiešana |
| Metodika | Draudu modelēšana un uzbrukuma scenāriji | OWASP testēšana un zināmās uzbrukumu metodes |
| Rezultāts | MI risinājumam pielāgoti novēršanas ieteikumi un atkārtota pārbaude | Ziņojums par lietotnes ievainojamībām |
Neesat pārliecināti, kura pārbaude ir vajadzīga? Rakstiet mums.
Klientu atsauksmes
Ko par mums saka klienti
Biežāk uzdotie jautājumi (BUJ)
01 Kas ietilpst LLM integrācijas ielaušanās testā?
Pārbaudām lietotni, kas izmanto LLM, MI aģentus un RAG. Skatāmies, cik labi tā iztur prompt injection un jailbreak mēģinājumus, vai šādā ceļā no tās var izvilkt datus un vai uzbrucējs var ļaunprātīgi izmantot rīkus, kuriem modelis piekļūst.
02 Kādus draudus pārbaudāt MI integrācijās?
Prompt injection, tostarp netiešo injekciju caur dokumentiem, jailbreak, sistēmas uzvednes noplūdi, datu noplūdi, piekļuves tiesību apiešanu caur MI aģentu, saindētus datus RAG indeksā, kā arī DoS un denial of wallet, proti, apzinātu pieprasījumu limita iztukšošanu.
03 Kādus modeļus un platformas testējat?
OpenAI un Azure OpenAI, Anthropic, Google Vertex AI, Mistral, Llama, kā arī lokāli darbinātus modeļus. Lietotnes pusē skatāmies LangChain un LlamaIndex ietvarus, RAG risinājumus un vektoru datubāzes.
04 Cik maksā MI un LLM integrācijas ielaušanās tests?
Cenu nosaka tvērums: cik integrācijas punktu ir risinājumā, cik rīku ir pieejams MI aģentam, vai testā ietilpst arī RAG indekss un aiz tā esošie dati un vai vajadzīga atkārtota pārbaude. Lietotne ar vienu sarunas saskarni un vienu modeli izmaksā būtiski mazāk nekā aģentu risinājums ar desmit rīkiem. Pēc īsas sarunas par tvērumu sagatavojam fiksētu piedāvājumu, kas jūs ne pie kā nesaista.
05 Ko saņemat pēc testa un kā notiek atkārtota pārbaude?
Tehnisku ziņojumu ar pierādījumiem un ieteikumiem, kā arī kopsavilkumu vadībai. Rezultātus pārrunājam noslēguma sanāksmē kopā ar jūsu komandu, un pēc labojumiem veicam atkārtotu pārbaudi, kurā rakstiski fiksējam, kuri konstatējumi ir novērsti.
