2026 թվականին AI գործառույթներ թողարկող կազմակերպությունների մեծ մասն անում է դա ավելի արագ, քան իրենց անվտանգության պրակտիկան հարմարվել է։ Սա անփութություն չէ՝ ճնշումն իրական է, իսկ գործիքակազմը՝ երիտասարդ։ Բայց դա ստեղծում է ճանաչելի օրինաչափություն․ գործառույթը գործարկվում է միջավայրի փոփոխականում պահվող API բանալիով, տողերի միացմամբ կազմված հուշումով, առանց ծագման նշման ներարկված փաստաթղթերով և առանց որևէ թեստի, որը կհարցներ, թե ինչ կլինի, եթե օգտատերը փորձի ստիպել նրան սխալ վարվել։
Secure AI-DLC-ը այս համակարգերի նկատմամբ անվտանգ մշակման կյանքի ցիկլի կարգապահության կիրառումն է։ Սա անվտանգության նոր փիլիսոփայություն չէ։ Սա այն գիտակցումն է, որ AI գործառույթները ներմուծում են երեք բան, որոնք հավելվածային անվտանգության ավանդական մոտեցումը հաշվի չի առնում։
Երեք բան, որոնք իսկապես տարբեր են
1. Կախվածություն, որը չեք կարող կարդալ։ Ելակետային կոդը կարող եք վերանայել։ Մոդելի կշիռները՝ ոչ։ Մոդելը անթափանց արտեֆակտ է մատակարարման շղթայից, որին հիմնականում ստիպված եք վստահել, և ծագման հարցը՝ որտեղի՞ց է այն եկել, փոփոխվե՞լ է, կարո՞ղ եմ ստուգել՝ ավելի թույլ պատասխաններ ունի, քան npm փաթեթի դեպքում։
2. Բաղադրիչ, որի վրա կարող է ազդել իր մուտքը։ Ձեր համակարգի մնացած բոլոր մասերն անում են այն, ինչի համար ծրագրավորվել են։ Լեզվական մոդելն անում է այն, ինչին համոզում է իր համատեքստը, իսկ այդ համատեքստը ներառում է օգտատերերից, փաստաթղթերից, վեբ էջերից և գործիքների արդյունքներից եկած բովանդակություն։ Հրահանգի ալիքը և տվյալների ալիքը նույն ալիքն են։
3. Տվյալների ուղի, որը լքում է Ձեր սահմանը։ Եթե մոդելները չեք աշխատեցնում ինքներդ, յուրաքանչյուր inference տվյալներ է ուղարկում երրորդ կողմի։ Թե ինչ է մտնում այդ հարցման մեջ, և արդյոք որևէ մեկը վերանայել է դա՝ սովորաբար փաստաթղթավորված չէ։
Ստորև բերված ամեն ինչ բխում է այս երեքից։
Մոդելի մատակարարման շղթան
Մոդելի կշիռները դիտարկեք որպես կախվածություն նույն խստությամբ, ինչ ցանկացած այլ երրորդ կողմի բաղադրիչ, ինչը թիմերի մեծ մասի համար նշանակում է զգալիորեն ավելի մեծ խստություն, քան ներկայումս կիրառում են։
Հարցեր, որոնք պահանջում են հիմնավորելի պատասխաններ․
- Որտեղի՞ց են եկել այս կշիռները, և արդյոք աղբյուրը հեղինակավո՞ր է։
- Ամրագրվա՞ծ են դրանք կոնկրետ տարբերակին, թե՞ հղումը լողացող է։
- Եթե հոսթինգային API է, ի՞նչ է մատակարարի փոփոխությունների քաղաքականությունը՝ կարո՞ղ է Ձեր վերջնակետի հետևում գտնվող մոդելը փոխվել առանց ծանուցման, և ի՞նչ է դա անում Ձեր թեստավորած վարքագծի հետ։
- Լիցենզիան համատեղելի՞ է Ձեր օգտագործման հետ։
- Ի՞նչ է գրանցված Ձեր ցանկում։ Մոդելը ակտիվ է։ Աուդիտորները կհարցնեն։
Տարբերակի ամրագրումն արժանի է շեշտադրման։ Թիմերը, որոնք երբեք չէին տեղակայի npm install express առանց
lockfile-ի, կանոնավոր կերպով արտադրությունն ուղղում են մոդելի անվանը, որը լուռ թարմացվում է։ Ձեր prompt
injection թեստերը, ելքի ստուգումը, հապաղման ենթադրությունները՝ բոլորը վավերացվել են կոնկրետ տարբերակի դեմ։
Ամրագրեք այն և թարմացումը դիտարկեք որպես փոփոխություն, որը պահանջում է կրկնակի թեստավորում։
Prompt injection․ ճարտարապետական խնդիր
OWASP Top 10 for LLM Applications-ը prompt injection-ը դնում է առաջին տեղում, և արժե ճշգրիտ լինել, թե ինչու է այն դիմադրում այն լուծումներին, որոնք աշխատեցին ներարկման ավելի վաղ դասերի համար։
SQL ներարկումը լուծվեց կոդը տվյալներից առանձնացնելով։ Պարամետրացված հարցումները նշանակում են, որ օգտատիրոջ մուտքը երբեք չի կարող մեկնաբանվել որպես հրահանգ, քանի որ երկուսը տարբեր ալիքներով են շարժվում։
Լեզվական մոդելը նման առանձնացում չունի։ Համակարգային հուշումը, օգտատիրոջ հաղորդագրությունը և ստացված փաստաթուղթը բոլորը գալիս են որպես տոկենների մեկ հաջորդականություն։ Պարամետրացման պրիմիտիվ չկա։ Կարող եք ներարկումն ավելի դժվարացնել սահմանազատիչներով, հրահանգների հիերարխիայով և ոչ վստահելի բովանդակության համար առանձին մոդելներով, և այս ամենն օգնում է, բայց ոչ մեկը երաշխիք չէ, և նախագծելը այնպես, կարծես լիներ, ի վերջո սխալ կլինի։
Ուստի պաշտպանությունը պետք է լինի ճարտարապետական․
Ենթադրեք, որ մոդելին կարելի է ստիպել արտադրել ցանկացած ելք։ Անվտանգության սահմանը դրեք այն բանի վրա, ինչ համակարգին թույլատրվում է անել այդ ելքի հետ։
Կոնկրետ․
- Մոդելի ինքնությունը օգտատիրոջ ինքնությունը չէ։ Եթե մոդելը կարող է գործիք կանչել, այդ կանչը լիազորվում է օգտատիրոջ իրավունքների դեմ, ստուգվում սերվերի կողմից, ամեն անգամ։ Մոդելը, որին համոզել են պահանջել տվյալներ, որոնց օգտատերը մուտք չունի, պետք է մերժվի լիազորման շերտի, ոչ թե հուշման կողմից։
- Հետևանքներ ունեցող գործողությունները պահանջում են հաստատում մոդելի վերահսկողությունից դուրս։ Նամակ ուղարկելը, գումար տեղափոխելը, գրառումներ ջնջելը՝ մոդելը կարող է առաջարկել․ մարդը կամ դետերմինիստական կանոնը որոշում է։
- Ելքը ոչ վստահելի մուտք է այն սպառողի համար, ով օգտագործում է այն։ HTML-ի տեսքով ներկայացվող մոդելի ելքը XSS ուղի է։ Shell-ին փոխանցված ելքը հրամանի ներարկում է։ Հարցման մեջ օգտագործված ելքը ներարկում է։ Էկրանացրեք և ստուգեք ճիշտ այնպես, ինչպես օգտատիրոջ մուտքը, քանի որ հենց դա էլ այն է։
- Անուղղակի ներարկումն ավելի բարդ դեպքն է։ Հարձակումը պարտադիր չէ, որ գա Ձեր օգտատիրոջից։ Ձեր գիտելիքների բազայի փաստաթուղթը, Ձեր գործակալի բացած վեբ էջը կամ նրա ամփոփած նամակը կարող են հրահանգներ կրել։ Ցանկացած ստացված բան ոչ վստահելի է, և դրա ծագումը պետք է ուղեկցի այն։
- Ինչու ոչ հուշումը
- պարամետրացման միջոց պարզապես չկա
- Մոդելի ինքնությունը
- օգտատիրոջ ինքնությունը չէ
- Անուղղակի ներարկում
- վերցված ամեն ինչ անվստահելի է, և ծագումը ուղեկցում է դրան
Այս դիագրամը՝ տեքստով
- Այս ամենը հասնում է որպես թոքենների մեկ հաջորդականություն
- Համակարգային հուշում
- Օգտատիրոջ հաղորդագրություն — անվստահելի
- Վերցված փաստաթղթեր — անվստահելի, և ավելի դժվար դեպքը
- Մոդելը — հրահանգները տվյալներից չեն բաժանվում — ենթադրեք, որ այն կարող է տալ ցանկացած ելք
- Անվտանգության սահմանը — այն բանի վրա, ինչ թույլատրված է անել ելքին
- Կիրառվում է այստեղ, ամեն անգամ
- Գործիքի կանչերը՝ օգտատիրոջ անունից — սերվերի կողմում, ոչ հուշումով
- Հետևանքային գործողությունները հաստատվում են — մարդ կամ դետերմինիստական կանոն
- Ելքը էկրանավորվում և ստուգվում է — դա անվստահելի մուտք է
Կապեր
- Համակարգային հուշում → Մոդելը
- Օգտատիրոջ հաղորդագրություն → Մոդելը
- Վերցված փաստաթղթեր → Մոդելը
- Մոդելը → Անվտանգության սահմանը — ելք
- Անվտանգության սահմանը → Գործիքի կանչերը՝ օգտատիրոջ անունից
- Անվտանգության սահմանը → Հետևանքային գործողությունները հաստատվում են
- Անվտանգության սահմանը → Ելքը էկրանավորվում և ստուգվում է
Տվյալների սահմանը
Յուրաքանչյուր AI գործառույթի համար որևէ մեկը պետք է կարողանա պատասխանել․ ի՞նչ տվյալ է լքում մեր սահմանը հարցման ժամանակ, և ո՞վ է դա վերանայել։
Գործնականում պատասխանը հաճախ ավելին է, քան նախատեսված էր, քանի որ որոնմամբ հարստացված համակարգերը համատեքստը հավաքում են դինամիկ։ Հուշումը, որը թեստավորման ժամանակ պարունակում էր կարճ հարց, արտադրության մեջ պարունակում է հաճախորդի գրառում, ներքին փաստաթուղթ և զրույցի պատմություն։
Կիրառելի վերահսկողություններ․
- Տվյալների դասակարգում՝ նախքան որոնումը, որպեսզի որոնման շերտը իմանա, թե ինչ կարող է ներառել
- Նվազագույնացում՝ ներառեք այն, ինչ պետք է առաջադրանքին, ոչ թե ամեն ինչ, որը իմաստային առումով նման է
- Նույնացուցիչների քողարկում, որտեղ առաջադրանքին դրանք պետք չեն
- Մուտքի վերահսկում հենց որոնման շերտում՝ պահպանելով հարցնող օգտատիրոջ իրավունքները։ RAG համակարգը, որը ինդեքսավորում է ամեն ինչ և որոնում առանց իրավունքների ստուգման, տվյալների արտահոսք է որոնման ինտերֆեյսով։
- Մատակարարի պայմանագրային և տեղակայման վերանայում, ինչը կարգավորվող հաճախորդների համար հաճախ հենց այն տեղն է, որտեղ ավարտվում է խոսակցությունը․ եթե հաճախորդի տվյալները չեն կարող լքել իրավասությունը, ապա այլ իրավասությունում հոսթինգային մոդելը Ձեզ հասանելի չէ՝ անկախ իր որակից։
Վերջին կետն էլ հենց պատճառն է, թե ինչու AI ռազմավարությունը և ենթակառուցվածքային ռազմավարությունը նույն խոսակցությունն են կարգավորվող կազմակերպությունների համար։ Սեփական ենթակառուցվածքում տեղակայված մոդելները երբեմն ոչ թե նախապատվություն են, այլ միակ իրավաչափ տարբերակը։
Ինչպես թեստավորել ոչ դետերմինիստական բան
Ավանդական թեստավորումը ենթադրում է, որ նույն մուտքը տալիս է նույն ելքը։ Այստեղ այդպես չէ, ինչը մարդկանց ստիպում է եզրակացնել, որ այս համակարգերը չեն կարող թեստավորվել։ Կարող են՝ պարզապես թեստերը այլ բան են պնդում։
| Թեստի տեսակ | Ինչ է պնդում |
|---|---|
| Prompt injection փաթեթ | Հայտնի ներարկման օրինաչափությունների հավաքածու՝ պնդելով, որ համակարգը չի կատարում արգելված գործողությունը |
| Անուղղակի ներարկում | Ներդրված հրահանգներով փաստաթղթեր՝ պնդելով, որ որոնումը չի բարձրացնում իրավունքները |
| Տվյալների արտահոսք | Համակարգային հուշումը, այլ օգտատերերի տվյալները կամ ուսուցողական բովանդակությունը հանելու փորձեր |
| Լիազորում | Մոդելը պահանջում է այն, ինչին օգտատերը մուտք չունի․ համակարգը մերժում է |
| Ելքի մշակում | Հակառակորդական ելքը (HTML, SQL, shell նշաններ) էկրանացվում է սպառողի կողմից |
| Ռեգրեսիա թարմացման ժամանակ | Փաթեթը կրկին կատարվում է մոդելի տարբերակի ցանկացած փոփոխության դեպքում |
Հիմնական տեղաշարժը․ պնդեք համակարգի վարքագծի մասին, ոչ թե մոդելի ելքի։ «Մոդելը մերժում է» փխրուն պնդում է։ «Գործիքի կանչը մերժվում է լիազորման շերտի կողմից» կայուն պնդում է, և հենց դա է իրականում պաշտպանում Ձեզ։
Նաև լոգավորեք բավարար չափով՝ հետաքննության համար․ հուշումներ, ստացված համատեքստի հղումներ, գործիքների կանչեր և ելքեր, պահպանման ժամկետով, որը համապատասխանում է Ձեր միջադեպային և կարգավորող կարիքներին՝ միաժամանակ ապահովելով, որ լոգերն իրենք չդառնան տվյալների արտահոսք, քանի որ այժմ դրանք պարունակում են այն ամենը զգայուն, ինչ անցել է համակարգով։
Ինչպես է սա կապվում չափանիշների հետ
- OWASP Top 10 for LLM Applications՝ ինժեներների համար ամենաուղղակի կիրառելի ցանկը․ սկսեք այստեղից։
- NIST AI RMF (AI 100-1)՝ AI ռիսկերի բացահայտման և կառավարման կառավարչական շրջանակ․ օգտակար է ռիսկերի և իրավաբանական ստորաբաժանումների հետ խոսակցության համար։
- ISO/IEC 42001՝ AI կառավարման համակարգի ստանդարտ, կառուցվածքով նման ISO 27001-ին։ Ակնկալեք, որ հաճախորդներն ու աուդիտորները կսկսեն հարցնել դրա մասին։
Սրանցից ոչ մեկը չի փոխարինում Ձեր գործող հավելվածային անվտանգության պրակտիկան։ AI գործառույթներին դեռ պետք են նույնականացում, լիազորում, մուտքի ստուգում, կախվածությունների սկանավորում, գաղտնիքների կառավարում և լոգավորում։ Secure AI-DLC-ը ընդլայնում է, ոչ թե փոխարինում, և թույլ հիմունքներով թիմը չի փրկվի վրայից ավելացված AI-հատուկ վերահսկողություններով։
Գործնական մեկնարկային հաջորդականություն
- Ցանկ։ Որ գործառույթներն են կանչում մոդել, որ մոդելը և ում API բանալիով։ Թիմերի մեծ մասն այսօր չի կարող պատասխանել սրան։
- Քարտեզագրեք տվյալների ուղին յուրաքանչյուրի համար։ Ի՞նչ է լքում սահմանը։
- Ստուգեք լիազորումը։ Կարո՞ղ է մոդելի նախաձեռնած որևէ գործողություն շրջանցել իրավունքների ստուգումը։ Սա ամենաբարձր կարևորության դասն է և ամենատարածված գտածոն։
- Ամրագրեք մոդելի տարբերակները և փոփոխությունները դիտարկեք որպես փոփոխություն։
- Գրեք prompt injection փաթեթ, թեկուզ փոքր, և կատարեք այն CI-ում։
- Վերանայեք ելքի մշակումը յուրաքանչյուր սպառողի մոտ։
- Սահմանեք AI լոգերի պահպանման և մուտքի կանոնները, քանի որ դրանք այժմ զգայուն են։
3-րդ և 6-րդ քայլերը գտնում են ամենալուրջ խնդիրները նվազագույն ջանքով։ Սկսեք այնտեղից։
Ազնիվ դիտարկում հասունության մասին
Սա նոր ձևավորվող ուղղություն է։ Գործիքակազմն անհաս է, չափանիշները երիտասարդ են, և ցանկացած ոք, ով պնդում է, թե ունի ամբողջական լուծում, գերագնահատում է եղածը։ Այն, ինչ կարելի է անել այսօր, վերը նշված ցանկն է՝ որը հիմնականում արդեն հայտնի սկզբունքների խիստ կիրառումն է այնպիսի բաղադրիչի նկատմամբ, որը վարվում է այլ կերպ, քան մնացած ենթակառուցվածքը։
«ԷՍ ԹԻ ՓԻ»-ն գիտակցաբար կառուցում է այս կարողությունը և նկարագրում է այն այնպես, ինչպես կա․ կարող ենք ցանկագրել Ձեր AI տվյալների ուղիները, վերանայել լիազորման սահմանները և ելքի մշակումը, կառուցել ներարկման թեստային փաթեթներ և նախագծել ենթակառուցվածք սեփական inference-ի համար, երբ տեղակայումը պահանջում է դա։ Նախընտրում ենք ասել, թե որտեղ է ուղղությունը դեռ զարգացման փուլում, քան վաճառել վստահություն, որը դեռ գոյություն չունի։
Ավելին՝ Անվտանգ SDLC և Secure AI-DLC, կամ կապվեք մեզ հետ։