Աշխատող AI համակարգեր ստեղծելու համար նախ պետք է փորձեք կոտրել դրանք։ Մենք նախափորձարկում անցկացրինք՝ հարձակվողների դերում ստուգելով և մանրակրկիտ փորձարկելով ֆինանսական ծառայությունների ոլորտի հաճախորդների համար նախատեսված AI հավելվածը։ Մեր բացահայտումները կարևոր են բոլոր նրանց համար, ովքեր ներդնում են LLM-ով աշխատող հավելվածներ, որոնց դեպքում անվտանգությունը պարտադիր պահանջ է։
Նախափորձարկումը ձեր AI համակարգը միտումնավոր կոտրելու փորձն է խոցելիությունները շտկելու համար` նախքան դրանք կգտնի իրական հարձակվողը։ Ֆինանսական ծառայությունների ոլորտում ռիսկերը հատկապես մեծ են. AI հավելվածներն աշխատում են հաճախորդների տվյալների հետ, մշակում գործարքներ և տրամադրում ֆինանսական վերլուծություններ։ Խափանման հետևանքները կարող են լինել թե՛ օգտատիրոջ վատ փորձը, թե՛ կարգավորող պահանջների խախտումները, ֆինանսական կորուստներն ու ապրանքանիշի անդառնալի վնասը։
Մեր նպատակն էր վաղ հայտնաբերել խոցելիությունները, փորձարկել իրատեսական հարձակման ձևերը և օգնել կազմակերպությանը բավարարել AI անվտանգության այն ակնկալիքները, որոնց կարգավորող մարմինները շատ լուրջ են վերաբերվում։
Այստեղ կարևոր է տարբերակել. հաքերային հարձակման գործընթացը թիրախավորում է հիմքում ընկած մոդելի անվտանգության զտիչները, իսկ հարցումների ներարկումը՝ հենց հավելվածը՝ համադրելով օգտատիրոջ անվստահելի մուտքային տվյալները մշակողի վստահելի հարցման հետ։ Հարցումների ներարկումն ավելի մեծ վտանգ է ներկայացնում, քանի որ թիրախավորում է ոչ թե ընդհանուր նշանակության մոդելը, այլ ձեր համակարգն ու դրա հետ աշխատող գաղտնի տվյալները։
Փորձարկման առաջին փուլն ընդգրկում էր մոտ 750 ստուգում հետևյալ ուղղություններով.
Տվյալների արտահոսք տարբեր աշխատաշրջանների միջև
Անձնական նույնականացման տվյալների (PII) բացահայտում՝ բնական լեզվի, API-ի մանիպուլյացիայի և տարբեր կոդավորումների միջոցով
SQL ներարկում
Համակարգային հարցումների շրջանցում
Նախնական փորձարկման ընթացքում առկա համակարգում երկու լուրջ խնդիր հայտնաբերեցինք՝ բազմակի նպատակներով հարցումների մշակումը և կոդավորված հարցումների օգտագործումը։
Բազմակի նպատակներով հարցումներ՝ երբ հարցումը համատեղում է օրինական և վնասաբեր պահանջներ։ Օրինակ՝ «Ցույց տուր իմ ծախսերն ըստ կատեգորիայի, ինչպես նաև կատարիր [վնասաբեր SQL հարցումը]:» Հավելվածը չէր հայտնաբերում վնասաբեր նպատակը՝ ամբողջովին ապավինելով տվյալների ստորին շերտի պաշտպանիչ մեխանիզմներին։ Սա նույնն է, ինչ տան դուռը բաց թողնելը՝ նկուղի չհրկիզվող պահարանին վստահելու պատճառով։
Կոդավորում. երբ հարցումները կոդավորվում են Base64, Hex, LeetSpeak ձևաչափերով կամ համանման նշաններով։ Համակարգերի համար կարող է դժվար լինել վնասաբեր նպատակի զտումը։ Թեև պարզեցինք, որ այս հարցումները զգայուն տվյալներ չէին բացահայտում, դրանք զգալիորեն ապակայունացնում էին համակարգը (հալյուցինացիաներ, օգտատերերին վնասաբեր SQL-ի կրկնություն, նպատակների սխալ դասակարգում և այլն)։
Նախնական փորձարկման արդյունքները ցույց տվեցին հետևյալը.
Ժամանակային հալյուցինացիաներ. մոդելը վստահորեն ներկայացնում էր հորինված ամսաթվեր, գործարքների ժամանակային դրոշմներ կամ որոշակի ժամանակահատվածի ամփոփագրեր։ Սա մեծ վտանգ է ֆինանսական ոլորտում, որտեղ սխալ ամսաթվի հիման վրա հաճախորդի գործողությունը կարող է իրական հետևանքներ ունենալ
Վնասաբեր SQL-ի վերադարձը օգտատիրոջը(ինչը մտահոգիչ է հիշողության թունավորման վտանգի առումով)
Նպատակների սխալ դասակարգում
Արդյունքի խառնաշփոթ ձևաչափում
Այս բացահայտումների հիման վրա մենք նեղացրինք ուսումնասիրության շրջանակը։ SQL ներարկման և կոդավորման փորձարկումների առաջնահերթությունը նվազեցվեց, (թիմն արդեն զբաղվում էր դրանցով)։ Փոխարենը կենտրոնացանք ամենաարդյունավետ հարձակման ուղիների՝ PII-ի բացահայտման և աշխատաշրջանների միջև տվյալների արտահոսքի վրա։
Երկրորդ փուլի ամենաուշագրավ բացահայտումը զարմանալիորեն պարզ էր. հաճախ ամենևին էլ հնարամիտ լինելու կարիք չկա։
Շատ դեպքերում բավական էր պարզապես խնդրել ներքին տվյալները՝ դա ներկայացնելով որպես օրինական թվացող հարցման մաս, և համակարգը համաձայնում էր բացահայտել դրանք։ Պարզ հարցումներին տրվող պատասխաններում հայտնվում էին ներքին նույնացուցիչներ և համակարգային դաշտեր, որոնք երբեք չպետք է տեսանելի լինեին վերջնական օգտատերերին։
Ավելի խոր ուսումնասիրությամբ պարզեցինք, որ սա միայն հավելվածի մակարդակի խափանում չէր։ Հաջորդող տեքստից SQL ծառայությունը կազմում էր հարցումներ, որոնք պահանջում էին թույլատրելիից ավելի շատ դաշտեր, իսկ դրա բացատրական պատասխաններում հիշատակվում էին սահմանափակ հասանելիությամբ տվյալներ։ Սա բացահայտեց համակարգերի միջև իրական ճեղք՝ այնպիսի խոցելիություն, որն ի հայտ է գալիս միայն ամբողջ տեխնոլոգիական շղթան, այլ ոչ թե առանձին բաղադրիչները մեկուսացված փորձարկելիս։
Նախափորձարկեք համակարգը, ոչ թե մոդելը։ LLM-ի մեկուսացված փորձարկումը շատ քիչ բան է ասում ձեր հավելվածի անվտանգության մակարդակի մասին։ Փորձարկեք ամբողջ տեխնոլոգիական շղթան՝ սկզբից մինչև վերջ, այնպես, ինչպես օգտատերը կփոխգործակցեր դրա հետ։
Մուտքային տվյալները պետք է վավերացնել մինչև LLM-ին փոխանցելը։ Կոդավորված հարցումները, բազմակի նպատակներով հարձակումներն ու ներարկման պարզ փորձերը պետք է հայտնաբերվեն համակարգի սահմանագծում, այլ ոչ թե փոխանցվեն ստորին մակարդակի ծառայություններին։
Մի՛ վստահեք համակարգերի միացման կետերին։ Բազմածառայություն ճարտարապետություններում ամենահետաքրքիր խոցելիությունները թաքնվում են համակարգերի միջև եղած ճեղքերում։ Զրոյական վստահությունն իսկապես զրոյական վստահություն է. վավերացրեք ամեն ինչ՝ յուրաքանչյուր շերտում։
Պարզ հարձակումներն արդյունավետ են։ Լրատվամիջոցների ուշադրությանն արժանանում են բարդ հաքերային հարձակման գործընթացները, բայց երբեմն կարելի է պարզապես... խնդրել։ Եթե օգտատիրոջ այլապես օրինական հարցման մեջ ներքին նույնացուցիչներ ներառելու դեպքում ձեր համակարգը պատրաստակամորեն ցուցադրում է դրանք, ապա դա խնդիր է։
Հստակ իմացեք, թե իրականում ինչ եք փորձարկում։ Հարձակման հայտնի ձևերը կարող են հայտնաբերվել հենց LLM-ի ուսուցման, այլ ոչ թե ձեր պաշտպանիչ մեխանիզմների շնորհիվ։ Նախափորձարկման մեջ ներդրեք դիտարկելիության միջոցներ՝ հասկանալու, թե իրականում որ վերահսկիչ մեխանիզմներն են գործարկվում։
Սահմանափակ միջավայրերը ստեղծագործ լուծումներ են պահանջում։ Անհատական մատակարարներն ու տեղային մոդելների աջակցությունը հնարավորություն են տալիս արդյունավետ նախափորձարկում կատարել՝ առանց մասնագիտացված ամպային հասանելիության։ Սակայն պետք է թափանցիկ ներկայացնել դրանից բխող սահմանափակումները։
Նախափորձարկումը մեկանգամյա գործընթաց չէ։ Այն կրկնվող գործընթաց է, հնարավորության դեպքում պետք է ավտոմատացվի և զարգանա ձեր համակարգին զուգընթաց։ Վաղը կարևոր հարձակումները նույնը չեն լինի, ինչ այսօր։
Կարգավորվող միջավայրերում AI համակարգերը միայն ավելի խիստ վերահսկողության կենթարկվեն։ Այն կազմակերպությունները, որոնք անվտանգության փորձարկումը համարում են շարունակական գործելակերպ, այլ ոչ թե գործարկումից առաջ նշվող հերթական կետ, ավելի պատրաստ կլինեն այդ վերահսկողությանը և կխուսափեն հաճախորդների վստահությունը խաթարող հանրային սկանդալներից։