Негізгі навигация

750-ден астам қауіпсіздік сынағы ЖИ редтимингі туралы нені көрсетті

750-ден астам қауіпсіздік сынағы автоматтандырылған редтимингтің реттелетін ЖИ жүйелеріндегі қатерлерді қалай анықтайтынын көрсетеді.

Жұмыс істейтін ЖИ жүйесін құру үшін алдымен оны бұзып көру керек. Біз қаржы қызметтері саласындағы клиенттерге арналған ЖИ қолданбасын шабуылдаушылар ретінде тексеріп, сынау үшін редтиминг жүргіздік. Анықтаған жайттарымыз қауіпсіздік міндетті саналатын LLM (үлкен тілдік модель) негізіндегі қолданбаларды енгізетін кез келген ұйым үшін маңызды.

Редтиминг деген не және ол неліктен маңызды?

Редтиминг — осалдықтарды нағыз шабуылдаушы таппай тұрып түзету үшін ЖИ жүйесін әдейі бұзып көру тәсілі. Қаржы қызметтері саласында тәуекел әсіресе жоғары: ЖИ қолданбалары клиенттердің деректерімен жұмыс істейді, транзакцияларды өңдейді және қаржылық талдамалық ақпарат береді. Ақаудың салдары пайдаланушы тәжірибесінің нашарлауынан бастап нормативтік талаптардың бұзылуына, қаржылық шығындарға және бренд беделіне орны толмас нұқсан келуіне дейін баруы мүмкін.

Мақсатымыз осалдықтарды ерте анықтау, шынайы шабуыл үлгілерін сынау және ұйымға реттеушілер айрықша мән беретін ЖИ қауіпсіздігі талаптарын орындауға көмектесу болды.

Редтимингті қалай жүргіздік және нені анықтадық?

Мұнда бір маңызды айырмашылық бар: қорғанысты айналып өту шабуылы базалық модельдің қауіпсіздік сүзгілеріне бағытталады; ал көмексөзге зиян келтіру әзірлеушінің сенімді көмексөзімен біріктірілген сенімсіз пайдаланушы енгізілімін пайдаланып, қолданбаның өзіне шабуыл жасайды. Көмексөзге зиян келтіру жалпы мақсаттағы модельге емес, сіздің жүйеңізге және ол өңдейтін құпия деректерге бағытталғандықтан, қаупі жоғарырақ.

1-қадам: ауқымды қамту

Сынақтың алғашқы кезеңінде мына бағыттар бойынша шамамен 750 сынақ жүргізілді:

  • Сеанстар арасында деректердің жылыстауы

  • Жеке тұлғаны сәйкестендіруге мүмкіндік беретін ақпараттың (PII) ашылуы (табиғи тіл, API-ді манипуляциялау және түрлі кодтау тәсілдері арқылы)

  • SQL инъекциясы

  • Жүйелік көмексөзді қайта анықтау

Алғашқы сынақ барысында қолданыстағы жүйенің екі негізгі мәселесін анықтадық: бірнеше мақсатты біріктіретін сұрауларды өңдеу және кодталған көмексөздерді пайдалану.

Бірнеше мақсатты сұраулар: заңды және зиянды талаптарды бір сұрауда біріктіру. Мысалы: «Шығындарымды санаттар бойынша көрсетіп, сонымен бірге [зиянды SQL] орында». Қолданба зиянды ниетті анықтамай, кейінгі деректер қабатының қорғаныс тетіктеріне толығымен сүйенген. Бұл жертөледегі сейфке сеніп, үйдің кіреберіс есігін ашық қалдырумен бірдей.

Кодтау: сұрауларды Base64, Hex, LeetSpeak және гомоглифтер арқылы кодтау. Мұндай жағдайда жүйелерге зиянды ниетті сүзу қиын болуы мүмкін. Бұл сұраулар құпия деректерді ашпағанымен, жүйенің тұрақтылығын айтарлықтай бұзды: галлюцинациялар туындады, зиянды SQL пайдаланушыларға қайталанып берілді, ниеттер қате жіктелді және т.б.

Алғашқы сынақ мына нәтижелерді көрсетті:

  • Уақытқа қатысты галлюцинациялар: модель ойдан шығарылған күндерді, транзакция уақыттарын немесе белгілі бір кезеңге арналған қорытындыларды сенімді түрде ұсынады, қате күнге сүйенген клиенттің әрекеті нақты салдарға әкелуі мүмкін болғандықтан, бұл қаржы саласында елеулі қауіп төндіреді

  • Зиянды SQL-дің пайдаланушыға қайталанып берілуі (жадты улау қаупіне байланысты алаңдатады)

  • Ниеттің қате жіктелуі

  • Нәтиже пішімінің бұзылуы

2-қадам: тереңірек зерттеу

Осы нәтижелерге сүйеніп, зерттеу аясын тарылттық. SQL инъекциясы мен кодтау сынақтарының басымдығы төмендетілді, өйткені команда бұл мәселелерді шешіп жатқан еді. Оның орнына ең нәтижелі шабуыл векторларына: PII ашылуы мен сеанстар арасындағы дерек жылыстауына назар аудардық.

Екінші кезеңдегі ең таңғаларлық қорытынды өте қарапайым болды: көбіне айрықша амал табудың қажеті жоқ.

Көп жағдайда заңды көрінетін сұраудың бір бөлігі ретінде ішкі деректерді жай ғана сұрау жүйенің оларды ашуға келісуі үшін жеткілікті болды. Қарапайым сұрауларға берілген жауаптарда түпкі пайдаланушыларға ешқашан көрсетілмеуге тиіс ішкі идентификаторлар мен жүйелік өрістер аталды.

Тереңірек зерттегенде, бұл тек қолданба деңгейіндегі ақау емес екенін анықтадық. Мәтінді SQL-ге түрлендіретін кейінгі қызмет рұқсат етілгеннен көп өрісті сұрайтын сұраулар құрып, түсіндірме жауаптарында қолжетімділігі шектелуге тиіс деректерді атаған. Бұл жүйелер арасындағы нақты саңылауды көрсетті: мұндай осалдық жекелеген құрамдастарды оқшау сынағанда емес, бүкіл технологиялық стекті тексергенде ғана анықталады.

Негізгі қорытындылар

  1. Модельге емес, жүйеге редтиминг жүргізіңіз. LLM (үлкен тілдік модель)-ді (үлкен тілдік модельді) оқшау сынау қолданбаңыздың қауіпсіздік деңгейі туралы өте аз мәлімет береді. Бүкіл технологиялық стекті пайдаланушы әрекеттесетіндей етіп басынан аяғына дейін сынаңыз.

  2. Енгізілімді тексеру LLM-ге (үлкен тілдік модельге) дейін жүргізілуі керек. Кодталған сұраулар, бірнеше мақсатты шабуылдар және қарапайым инъекция әрекеттері кейінгі қызметтерге тапсырылмай, жүйенің сыртқы шекарасында анықталуы керек.

  3. Жүйелер түйіскен тұсқа сенбеңіз. Бірнеше қызметтен тұратын архитектураларда ең қызықты осалдықтар жүйелердің арасындағы саңылауларда жасырынады. Нөлдік сенім ешкімге және ештеңеге сенбеуді білдіреді, сондықтан әр қабатта бәрін тексеріңіз.

  4. Қарапайым шабуылдар да нәтиже береді. Күрделі қорғанысты айналып өту үлгісі жаңалық тақырыбына айналады, бірақ кейде жай ғана... сұрасаңыз болғаны. Пайдаланушы басқа жағынан заңды болып көрінетін сұрауға ішкі идентификаторларды қосқанда, жүйеңіз оларды еш кедергісіз көрсетсе, бұл — мәселе.

  5. Нақты нені сынап жатқаныңызды түсініңіз. Белгілі шабуыл үлгілерін сіздің қорғаныс тетіктеріңіз емес, LLM-нің (үлкен тілдік модельдің) өз оқытуы нәтижесінде қалыптасқан қорғаныс механизмдері анықтауы мүмкін. Нақты қай бақылау тетіктері іске қосылатынын түсіну үшін редтиминг үдерісіне бақылау және қадағалау мүмкіндіктерін енгізіңіз.

  6. Мүмкіндігі шектеулі орталарға шығармашылық шешімдер қажет. Арнайы провайдерлер мен жергілікті модельдерді қолдау мамандандырылған бұлттық қолжетімділіксіз де тиімді редтиминг жүргізуге мүмкіндік береді. Алайда одан туындайтын шектеулерді ашық көрсету керек.

  7. Редтиминг бір рет қана жүргізілмейді. Ол қайталанатын үдеріс болуы, мүмкіндігінше автоматтандырылуы және жүйеңізбен бірге дамуы керек. Ертең маңызды болатын шабуылдар бүгінгілермен бірдей емес.

Реттелетін ортадағы ЖИ жүйелері алдағы уақытта бұрынғыдан да қатаң бақылауға алынады. Қауіпсіздік сынағын іске қосар алдындағы бір реттік белгілеу емес, тұрақты жұмыс тәртібі деп қабылдайтын ұйымдар мұндай бақылауға жақсырақ дайын болып, клиенттердің сенімін жоғалтуға әкелетін беделдік дағдарыстардан аулақ бола алады.

Автор

Akram Dweikat, George Montagu, Fatemeh Tahavori, Oliver Wood, Romain Bourboulou