Ажилладаг AI-ын систем бүтээхийн тулд эхлээд түүнийг эвдэх хэрэгтэй. Бид халдагчийн дүрээр ажиллан, санхүүгийн үйлчилгээний хэрэглэгчдэд зориулсан AI-ын аппыг шалгаж, шинжлэх улаан багийн туршилт хийсэн. Аюулгүй байдлыг үл тоомсорлох боломжгүй орчинд Том хэлний загвар (LLM)-т суурилсан апп нэвтрүүлж буй хэн бүхэнд бидний олж тогтоосон зүйл чухал.
Улаан баг гэдэг нь бодит халдагч эмзэг байдлыг олохоос өмнө засахын тулд AI-ын системээ зориуд эвдэхийг оролдох арга ажиллагаа юм. Санхүүгийн үйлчилгээнд эрсдэл онцгой өндөр: AI-ын аппууд харилцагчийн өгөгдөлтэй ажиллаж, гүйлгээ боловсруулан, санхүүгийн дүн шинжилгээ өгдөг. Алдаа нь хэрэглэгчийн таагүй туршлагаас эхлээд зохицуулалтын зөрчил, санхүүгийн хохирол, брэндийн нөхөж баршгүй нэр хүндийн уналтад хүргэж болно.
Бидний зорилго эмзэг байдлыг эрт илрүүлэх, бодитой халдлагын хэв маягийг турших, мөн зохицуулагчдын нэн чухалчилдаг AI-ын аюулгүй байдлын шаардлагыг байгууллага хангахад туслах байв.
Энд нэг ялгааг тодруулах нь зүйтэй: jailbreak нь үндсэн загварын аюулгүй байдлын шүүлтүүрт халддаг бол зааварт халдлага нь хөгжүүлэгчийн итгэмжлэгдсэн өгөгдөлтэй найдваргүй хэрэглэгчийн оролтыг хослуулан аппад өөрт нь халддаг. Зааварт халдлага нь ерөнхий зориулалтын загварыг бус, таны систем болон түүний ажилладаг нууц өгөгдлийг онилдог тул илүү их эрсдэлтэй.
Эхний шатанд бид дараах чиглэлээр ойролцоогоор 750 туршилт хийсэн:
Холболт хоорондын өгөгдөл алдагдал
Хувийн таних мэдээлэл (PII) ил болох (байгалийн хэл, API өөрчлөх арга болон төрөл бүрийн кодчиллоор)
SQL тарилга
Системийн өгөгдлийг хүчингүй болгох оролдлого
Эхний туршилтаар одоогийн системд олон зорилготой асуулгыг боловсруулах болон кодолсон өгөгдөл ашиглахтай холбоотой хоёр том асуудлыг илрүүлсэн.
Олон зорилготой асуулга: хууль ёсны болон хортой хүсэлтийг нэг дор хослуулсан хүсэлт. Жишээ нь: “Show my spending by category, and also execute [malicious SQL].” Апп хортой санааг илрүүлэлгүй, өгөгдлийн доод түвшний хамгаалалтад бүрэн найдаж байв. Энэ нь хонгил дахь сейфдээ итгээд гэрийнхээ үүдийг онгорхой орхихтой адил.
Кодчилол: хүсэлтийг Base64, Hex, LeetSpeak болон ижил дүрст тэмдэгтээр кодлох. Ийм үед систем хортой санааг шүүж хасахад хүндрэлтэй байж болно. Эдгээр асуулга эмзэг өгөгдлийг ил болгоогүй ч системийг ихээхэн тогтворгүй болгож байв. Үүнд хий юм зохиох, хортой SQL-ийг хэрэглэгчид давтан харуулах, зорилгын ангиллыг будлиулах зэрэг багтсан.
Эхний туршилтын үр дүн дараах асуудлыг харуулсан:
Цаг хугацаатай холбоотой хий зохиомж: загвар хуурамч огноо, гүйлгээний цагийн тэмдэглэгээ эсвэл хугацаат хураангуйг итгэлтэйгээр өгөх. Буруу огноонд үндэслэн харилцагч шийдвэр гаргавал бодит үр дагаварт хүрч болох тул энэ нь санхүүгийн салбарт ноцтой эрсдэлтэй
Хортой SQL-ийг хэрэглэгчид давтан харуулах (санах ойг хордуулах эрсдэлтэй тул түгшүүртэй)
Зорилгын будлиантай ангилал
Гаралтын формат алдагдах
Эдгээр үр дүнд үндэслэн бид анхаарах хүрээгээ нарийсгасан. Баг эдгээр асуудлыг аль хэдийн шийдэж байсан тул SQL тарилга болон кодчиллын туршилтыг хойш тавьсан. Харин хамгийн амжилттай халдлагын чиглэл болох хувийн таних мэдээлэл ил болох болон холболт хооронд мэдээлэл алдагдахад төвлөрсөн.
Хоёр дахь шатны хамгийн анхаарал татсан дүгнэлт тун энгийн байв: ихэнхдээ онцгой арга ухаан огт хэрэггүй.
Олон тохиолдолд хууль ёсны мэт хүсэлтийн нэг хэсэг болгон дотоод өгөгдлийг ердөө асуухад л систем түүнийг ил болгохыг зөвшөөрч байв. Энгийн асуулгад хүртэл эцсийн хэрэглэгч хэзээ ч харах ёсгүй дотоод ID болон системийн талбаруудыг дурдсан хариу ирж байв.
Илүү гүнзгий шинжлэхэд энэ нь зөвхөн аппын түвшний доголдол биш болохыг тогтоосон. Доод түвшний текстээс SQL үүсгэх үйлчилгээ шаардлагатайгаас олон талбар хүссэн асуулга үүсгэж, тайлбар хариундаа хязгаарлагдах ёстой өгөгдлийг дурддаг байв. Энэ нь системүүдийн хоорондох бодит цоорхойг илрүүлсэн. Ийм эмзэг байдал нь бүрэлдэхүүн хэсгийг тус тусад нь бус, технологийн бүх давхаргыг цогцоор нь туршихад л илэрдэг.
Загварт бус, системд улаан багийн туршилт хий. Том хэлний загвар (LLM)-ыг тусад нь турших нь аппын аюулгүй байдлын төлөвийн талаар тун бага мэдээлэл өгнө. Технологийн бүх давхаргыг хэрэглэгчийн харилцах байдлаар эхнээс нь дуустал турш.
Оролтыг Том хэлний загвар (LLM)-т хүрэхээс өмнө заавал шалгах ёстой. Кодолсон асуулга, олон зорилготой халдлага болон энгийн тарилгын оролдлогыг доод түвшний үйлчилгээнд даалгүй, системийн зааг дээр илрүүлэх ёстой.
Системүүдийн уулзварт бүү итгэ. Олон үйлчилгээт архитектурт хамгийн сонирхолтой эмзэг байдал системүүдийн хоорондох цоорхойд нуугддаг. Үл итгэх зарчим гэдэг нь үнэхээр хэнд ч үл итгэхийг хэлдэг тул давхарга бүрд бүхнийг шалга.
Энгийн халдлага ч амжилттай болдог. Нарийн төвөгтэй jailbreak-ууд олны анхаарлыг татдаг ч заримдаа ердөө... асуухад л болно. Хэрэглэгч бусдаараа хууль ёсны асуулгад дотоод танигч оруулахад систем тань тэдгээрийг дуртайяа ил болгодог бол энэ нь асуудал.
Яг юуг туршиж байгаагаа ойлго. Түгээмэл халдлагын хэв маягийг таны хамгаалалт бус, Том хэлний загвар (LLM)-ын сургалт өөрөө илрүүлж байж болно. Яг аль хяналтууд ажиллаж байгааг ойлгохын тулд улаан багийн туршилтдаа ажиглах боломжийг суулга.
Хязгаарлагдмал орчинд бүтээлч шийдэл хэрэгтэй. Тусгай үйлчилгээ үзүүлэгч болон дотоод загварын дэмжлэг нь үүлэн системийн тусгай хандалтгүйгээр үр дүнтэй улаан багийн туршилт хийх боломж олгодог. Гэхдээ үүнээс үүдэх хязгаарлалтыг ил тод тайлбарлах хэрэгтэй.
Улаан багийн туршилт бол нэг удаагийн ажил биш. Үүнийг давтамжтай хийж, боломжтой хэсгийг автоматжуулан, системтэйгээ хамт хөгжүүлж байх ёстой. Маргааш чухал болох халдлагууд өнөөдрийнхтэй адилгүй.
Зохицуулалттай орчин дахь AI-ын системүүдийн хяналт улам нэмэгдэхээс бус багасахгүй. Аюулгүй байдлын туршилтыг нэвтрүүлэхийн өмнөх нэг удаагийн тэмдэглэгээ бус, байнгын сахилга бат гэж үздэг байгууллагууд ийм хяналтыг илүү сайн давж, харилцагчдын итгэлийг алдуулах олон нийттэй харилцах хямралаас зайлсхийж чадна.