ეფექტიანი ხელოვნური ინტელექტის სისტემების შესაქმნელად ჯერ მათი მწყობრიდან გამოყვანა უნდა სცადოთ. ჩვენ ჩავატარეთ შეტევითი ტესტირება (red teaming): თავდამსხმელების როლში ფინანსური მომსახურების მომხმარებელზე ორიენტირებული AI აპლიკაცია გამოვცადეთ და სიღრმისეულად შევისწავლეთ. ჩვენი მიგნებები მნიშვნელოვანია ყველასთვის, ვინც LLM-ზე დაფუძნებულ აპლიკაციებს ნერგავს იქ, სადაც უსაფრთხოება აუცილებელი მოთხოვნაა.
შეტევითი ტესტირება (red teaming) გულისხმობს თქვენი AI სისტემის განზრახ მწყობრიდან გამოყვანის მცდელობას, რათა მოწყვლადობები რეალურ თავდამსხმელზე ადრე იპოვოთ და აღმოფხვრათ. ფინანსურ მომსახურებაში რისკი განსაკუთრებით მაღალია: AI აპლიკაციები ეხება მომხმარებელთა მონაცემებს, ამუშავებს ტრანზაქციებს და ფინანსურ ანალიზს აწვდის. ხარვეზის შედეგები შეიძლება მერყეობდეს მომხმარებლის ცუდი გამოცდილებიდან რეგულაციების დარღვევამდე, ფინანსურ ზარალამდე და ბრენდის გამოუსწორებელ დაზიანებამდე.
ჩვენი მიზანი იყო მოწყვლადობების ადრეულ ეტაპზე აღმოჩენა, რეალისტური შეტევის სქემების გამოცდა და ორგანიზაციის დახმარება AI უსაფრთხოების იმ მოთხოვნების დაკმაყოფილებაში, რომლებსაც მარეგულირებლები განსაკუთრებული სერიოზულობით ეკიდებიან.
აქ ერთი განსხვავება უნდა აღინიშნოს: მწარმოებლის შეზღუდვების მოხსნის შეტევა სამიზნედ მოდელის უსაფრთხოების ფილტრებს იღებს, ხოლო პრომპტ ინიექცია — თავად აპლიკაციას და ამისთვის არასანდო მომხმარებლის შეყვანილ მონაცემებს დეველოპერის სანდო მოთხოვნასთან აერთიანებს. პრომპტ ინიექცია უფრო დიდ რისკს ქმნის, რადგან სამიზნედ იღებს არა ზოგადი დანიშნულების მოდელს, არამედ თქვენს სისტემასა და მის მიერ დამუშავებულ კონფიდენციალურ მონაცემებს.
ტესტირების პირველი ეტაპი დაახლოებით 750 ტესტს მოიცავდა შემდეგი მიმართულებებით:
სესიებს შორის მონაცემთა გაჟონვა
პერსონალური საიდენტიფიკაციო ინფორმაციის გამჟღავნება (ბუნებრივი ენის, API-ით მანიპულირებისა და სხვადასხვა კოდირების გზით)
SQL ინიექცია
სისტემური მოთხოვნის ჩანაცვლება
პირველადი ტესტირებისას არსებულ სისტემაში ორი მნიშვნელოვანი პრობლემა აღმოვაჩინეთ: მრავალმიზნობრივი მოთხოვნების დამუშავება და კოდირებული მოთხოვნების გამოყენება.
მრავალმიზნობრივი მოთხოვნები: მოთხოვნები, რომლებიც კანონიერ და მავნე დავალებებს აერთიანებს. მაგალითად: “Show my spending by category, and also execute [malicious SQL].” აპლიკაცია მავნე განზრახვას ვერ ამოიცნობდა და მთლიანად მონაცემთა ქვედა დონის დამცავ მექანიზმებს ეყრდნობოდა. ეს იგივეა, სარდაფში მდგარი სეიფის იმედად სახლის შესასვლელი კარი ღია დატოვოთ.
კოდირება: მოთხოვნები, რომლებიც დაშიფრულია Base64-ით, Hex-ით, LeetSpeak-ითა და ჰომოგლიფებით. სისტემებს შეიძლება გაუჭირდეთ მავნე განზრახვის გაფილტვრა. მართალია, ამ მოთხოვნებს სენსიტიური მონაცემები არ გაუმჟღავნებია, მაგრამ მათ სისტემის მნიშვნელოვანი დესტაბილიზაცია გამოიწვია (ჰალუცინაციები, მომხმარებლებისთვის მავნე SQL-ის გამეორება, განზრახვის არასწორი კლასიფიკაცია და სხვ.).
პირველადი ტესტირების შედეგებმა აჩვენა:
დროითი ჰალუცინაციები: მოდელი დამაჯერებლად წარმოადგენდა გამოგონილ თარიღებს, ტრანზაქციების დროით ნიშნულებს ან კონკრეტულ პერიოდთან დაკავშირებულ შეჯამებებს. ეს მნიშვნელოვანი რისკია ფინანსურ კონტექსტში, სადაც მომხმარებლის მიერ მცდარი თარიღის საფუძველზე მოქმედებას რეალური შედეგები შეიძლება მოჰყვეს
მომხმარებლისთვის მავნე SQL-ის გამეორება (რაც მეხსიერების მოწამვლის რისკის გამო შემაშფოთებელია)
განზრახვის არასწორი კლასიფიკაცია
არეული გამომავალი ფორმატირება
ამ მიგნებების საფუძველზე კვლევის სფერო დავავიწროვეთ. SQL ინიექციისა და კოდირების ტესტებს ნაკლები პრიორიტეტი მიენიჭა, რადგან გუნდი ამ საკითხებზე უკვე მუშაობდა. ამის ნაცვლად, ყურადღება ყველაზე წარმატებულ შეტევის ვექტორებზე გავამახვილეთ: პერსონალური საიდენტიფიკაციო ინფორმაციის გამჟღავნებასა და სესიებს შორის გაჟონვაზე.
მეორე ეტაპის ყველაზე გამაოგნებელი მიგნება საოცრად მარტივი იყო: ხშირად საერთოდ არ არის საჭირო განსაკუთრებული მოხერხებულობა.
ხშირ შემთხვევაში საკმარისი იყო შიდა მონაცემების უბრალოდ მოთხოვნა, ოღონდ ისე, რომ ის ერთი შეხედვით კანონიერ მოთხოვნაში ყოფილიყო მოქცეული — და სისტემა მათ გამჟღავნებას თანხმდებოდა. მარტივ მოთხოვნებზე მიღებულ პასუხებში ჩნდებოდა შიდა იდენტიფიკატორები და სისტემური ველები, რომლებიც საბოლოო მომხმარებლებს არასოდეს უნდა ენახათ.
სიღრმისეული კვლევით დავადგინეთ, რომ ეს მხოლოდ აპლიკაციის დონის ხარვეზი არ იყო. ქვედა დონის ტექსტიდან SQL-ის გენერირების სერვისი ქმნიდა მოთხოვნებს, რომლებიც საჭიროზე მეტ ველს ითხოვდა, ხოლო მის განმარტებით პასუხებში მოხსენიებული იყო მონაცემები, რომლებზე წვდომაც შეზღუდული უნდა ყოფილიყო. ამან სისტემებს შორის რეალური ნაპრალი გამოავლინა — ისეთი მოწყვლადობა, რომელიც მხოლოდ სრული ტექნოლოგიური სტეკის ტესტირებისას ჩანს და არა ცალკეული კომპონენტების იზოლირებულად შემოწმებისას.
შეტევითი ტესტირება სისტემას ჩაუტარეთ და არა მოდელს. LLM-ის იზოლირებულად ტესტირება ძალიან მწირ ინფორმაციას გაძლევთ თქვენი აპლიკაციის უსაფრთხოების მდგომარეობაზე. მთელი ტექნოლოგიური სტეკი თავიდან ბოლომდე გამოცადეთ — ზუსტად ისე, როგორც მას მომხმარებელი გამოიყენებდა.
შეყვანილი მონაცემების ვალიდაცია LLM-მდე უნდა მოხდეს. კოდირებული მოთხოვნები, მრავალმიზნობრივი შეტევები და ინიექციის მარტივი მცდელობები სისტემის პერიმეტრზე უნდა გამოვლინდეს და არა ქვედა დონის სერვისებს გადაეცეს.
სისტემების შეერთების ადგილებს ნუ ენდობით. მრავალსერვისიან არქიტექტურებში ყველაზე საინტერესო მოწყვლადობები სისტემებს შორის არსებულ ნაპრალებში იმალება. ნულოვანი ნდობა მართლაც ნულოვან ნდობას ნიშნავს, ამიტომ ყველა დონეზე ყველაფერი გადაამოწმეთ.
მარტივი შეტევები მუშაობს. რთული მწარმოებლის შეზღუდვების მოხსნის მეთოდები სათაურებში ხვდება, თუმცა ზოგჯერ შეგიძლიათ უბრალოდ... იკითხოთ. თუ მომხმარებლის მიერ სხვა მხრივ კანონიერ მოთხოვნაში შიდა იდენტიფიკატორების ჩართვისას თქვენი სისტემა მათ დაუფიქრებლად ასაჯაროებს, ეს პრობლემაა.
ზუსტად გაიაზრეთ, რას ამოწმებთ. შეტევის ცნობილი სქემები შეიძლება თქვენმა დამცავმა მექანიზმებმა კი არა, თავად LLM-ის წვრთნამ გამოავლინოს. შეტევით ტესტირებაში (red teaming) დაკვირვებადობა თავიდანვე ჩაშენებული უნდა იყოს, რათა გაიგოთ, სინამდვილეში რომელი კონტროლის მექანიზმები მოქმედებს.
შეზღუდულ გარემოებს შემოქმედებითი გადაწყვეტილებები სჭირდება. სპეციალიზებული პროვაიდერები და ლოკალური მოდელების მხარდაჭერა სრულფასოვან შეტევით ტესტირებას (red teaming) სპეციალიზებულ ღრუბლოვან სერვისებზე წვდომის გარეშეც შესაძლებელს ხდის. თუმცა ამ მიდგომით გამოწვეული შეზღუდვები მკაფიოდ უნდა განმარტოთ.
შეტევითი ტესტირება (red teaming) ერთჯერადი პროცესი არ არის. ეს განმეორებითი პროცესია, რომელიც შეძლებისდაგვარად უნდა ავტომატიზდეს და თქვენს სისტემასთან ერთად განვითარდეს. ხვალ მნიშვნელოვანი შეტევები ისეთივე არ იქნება, როგორიც დღესაა.
რეგულირებულ გარემოებში მოქმედი AI სისტემები მომავალში უფრო მკაცრი კონტროლის ქვეშ მოექცევა და არა ნაკლების. ორგანიზაციები, რომლებიც უსაფრთხოების ტესტირებას მუდმივ პრაქტიკად მიიჩნევენ და არა გაშვებამდე მოსანიშნ პუნქტად, უკეთ გაუმკლავდებიან ამ კონტროლს და თავიდან აიცილებენ ისეთ საჯარო სკანდალებს, რომლებიც მომხმარებელთა ნდობას აკარგვინებთ.