Գաղտնի տվյալը մի՛ տեղադրեք ԱԲ prompt-ում․ պաշտպանեք նաև հիշողությունն ու մատյանները

Աշխատանքային ԱԲ գործիքով առաջադրանք կատարելիս նախ դասակարգեք տվյալը, ընտրեք կազմակերպության հաստատած ծառայությունը և հարցման մեջ փոխանցեք միայն անհրաժեշտ, հնարավորության դեպքում դիմակավորված հատվածը։ Պաշտպանությունը պետք է ընդգրկի նաև տվյալից մնացած հետքերը. Microsoft-ի սպառնալիքների նկարագրությունը արտահոսքի հնարավոր ուղիների թվում նշում է զրույցների պատմությունը, գործակալի հիշողությունը, որոնման ինդեքսները, գործիքների արդյունքներն ու մատյանները։

Աշխատակիցը մինչև հարցումն ուղարկելը պետք է պարզի՝ որ տեղեկությունն է իսկապես անհրաժեշտ, ինչ աղբյուրներ են միացված գործիքին և ով կարող է տեսնել պատասխանը։ ՏՏ ղեկավարը նույն ճանապարհը պետք է վերահսկի թույլտվություններով, պահման ժամկետներով, տվյալների կորստի կանխարգելմամբ (DLP) և միջադեպի արձագանքման կարգով։ Հարցման տեքստը մաքրելու կանոնը չի սահմանափակում այն տեղեկությունը, որը գործիքը կարող է հետագայում գտնել միացված պահոցում կամ վերարտադրել պահպանված հիշողությունից։

Աշխատակցի ստուգաթերթը՝ մինչև հարցումն ուղարկելը

Սկսեք առաջադրանքի համար անհրաժեշտ տվյալից։ Եթե խնդիրը լուծվում է առանց իրական հաճախորդի գրառման, վճարման տվյալների կամ ծրագրային գաղտնիքի, օգտագործեք հորինված կամ դիմակավորված օրինակ։ Իրական տվյալ պահանջող աշխատանքի դեպքում նախ համոզվեք, որ տվյալ տեսակի մշակումը թույլատրված է հենց այդ գործիքում և միացված միջավայրում։

• Դասակարգում. Տարբերակեք հրապարակային տեղեկությունը ներքին նյութից և սահմանափակ հասանելիությամբ տվյալից։ Հաճախորդի նույնականացնող տվյալը, չհրապարակված ֆինանսական ցուցանիշը, գաղտնի բանալի պարունակող կոդը կամ մուտքի նշանը մի՛ պատճենեք հարցման մեջ։ Եթե տվյալների դասը հստակ չէ, ճշտեք այն տվյալների սեփականատիրոջ կամ անվտանգության պատասխանատուի հետ։
• Հաստատված գործիք. Օգտագործեք կազմակերպության թույլատրած հաշիվն ու աշխատանքային միջավայրը։ Առանձին ստուգեք՝ թույլատրված են արդյոք ֆայլերի վերբեռնումը, զրույցների պահպանումը, հիշողությունը և արտաքին միացումները տվյալների այս դասի համար։ Գործիքի հաստատումը ինքնաբերաբար չի ընդգրկում դրա բոլոր միացումները կամ անձնական հաշիվը։
• Նվազագույն տվյալ և դիմակավորում. Ամբողջ աղյուսակի փոխարեն փոխանցեք առաջադրանքի համար պետք եկող սյունակներն ու տողերը։ Անունը, հեռախոսահամարը, հաշվի համարը կամ բանալին փոխարինեք չեզոք նշիչով, եթե իրական արժեքը պատասխանի համար անհրաժեշտ չէ։ Պատասխանում ևս ուշադրություն դարձրեք զգայուն դաշտերին. միացված աղբյուրը կարող է այնտեղ բերել տվյալ, որը հարցման մեջ չկար։
• Մուտք և պահպանված հետք. Մի՛ կցեք ամբողջ թղթապանակը, եթե պետք է միայն մեկ թույլատրված փաստաթուղթ։ Ստուգեք զրույցի և դրա համօգտագործվող հղման հասանելիությունը, ապա հետևեք կազմակերպության հաստատած ջնջման կարգին։ Միայն զրույցը սեփական տեսքից հեռացնելը բավարար տեղեկություն չի տալիս հիշողության, որոնման ինդեքսի կամ մատյանի վիճակի մասին։

Որտեղ կարող է մնալ տվյալը հարցումից հետո

Կարճ հարցումից տեղեկությունը կարող է անցնել ամփոփման, գործակալի երկարաժամկետ հիշողության, որոնման ինդեքսի կամ տեխնիկական մատյանի մեջ։ Յուրաքանչյուր պահոցի համար պետք է որոշել՝ ինչ տեղեկություն է թույլատրվում գրել, ով կարող է այն կարդալ և երբ է այն ջնջվում։ Նույն սահմանները վերաբերում են նաև գործակալների միջև փոխանցվող համատեքստին. մեկ առաջադրանքի հասանելիությունը չպետք է ինքնաբերաբար տարածվի մյուսի վրա։

Փաստաթղթեր որոնող օգնականում թույլտվությունը պետք է գործի նաև որոնման պահին, երբ ինդեքսավորված հատվածը հայտնվում է պատասխանի համատեքստում։ OWASP-ի վեկտորային որոնման ուղեցույցը նկարագրում է, թե ինչպես կարող է ընդհանուր պահոցում թույլ մուտքի վերահսկումը մի խմբի զգայուն տեղեկությունը բացել մյուսի համար։ Ինդեքսավորված նյութի հասանելիությունը կապեք սկզբնական փաստաթղթի թույլտվության հետ և թարմացրեք ինդեքսը, երբ այդ թույլտվությունը փոխվում է կամ նյութը հեռացվում է։

Արտաքին գործիքի պատասխանը, որոնումից վերցված հատվածը կամ գործակալի միջանկյալ ամփոփումը կարող է վերադառնալ հաջորդ հարցման համատեքստ։ Ուստի գործակալի հիշողության պաշտպանությունը կապեք յուրաքանչյուր աղբյուրի և փոխանցման առանձին թույլտվության հետ։ Մատյաններում գրանցեք հետաքննությանը պետք եկող իրադարձությունները, բայց սահմանափակեք ամբողջական հարցումների, պատասխանների և գաղտնի դաշտերի պահպանումը։

ՏՏ ղեկավարի ստուգաթերթը՝ պահոցներից մինչև DLP

Յուրաքանչյուր տվյալների դասի համար սահմանեք թույլատրված գործիքները, միացվող աղբյուրները, մուտքի շրջանակը և պահպանման ժամկետը։ Կարգավորումները գնահատեք կոնկրետ ծառայության ու հաշվի համար. կազմակերպական և անձնական տարբերակների վերահսկումները կարող են տարբեր լինել։ Այդ որոշումները ձևակերպեք որպես կիրառվող կանոններ, որպեսզի աշխատակիցը ստիպված չլինի յուրաքանչյուր հարցման ժամանակ ինքնուրույն կռահել սահմանը։

• Պիտակներ և նվազագույն մուտք. Դասակարգեք զգայուն ֆայլերն ու պահոցները, իսկ օգտատիրոջը, գործակալին և ծառայողական հաշվին տվեք միայն առաջադրանքի համար անհրաժեշտ իրավասությունները։ Որոնման ինդեքսում պահպանեք աղբյուրի թույլտվությունները և վերանայեք միացումների հասանելիությունը, երբ փոխվում է աշխատակցի դերը։ Միայն ֆայլը պիտակավորելը բավարար չէ, եթե միացման հաշիվը շարունակում է կարդալ ամբողջ պահոցը։
• Պահպանման ժամկետ. Առանձին կանոն սահմանեք զրույցների պատմության, մշտական հիշողության, որոնման պատճենների և մատյանների համար։ Նշեք, թե ով է պատասխանատու ջնջման, ինդեքսի թարմացման և հետաքննության համար անհրաժեշտ տվյալների պահպանման համար։ Այն առաջադրանքներում, որոնց պետք չէ երկարաժամկետ հիշողություն, օգտագործեք կարճատև համատեքստ։
• Դիմակավորում և DLP. Վերահսկեք մուտքային հարցումները, ելքային պատասխանները, հիշողության գրառումները և գործիքների արդյունքները։ Կանոնը կարող է զգուշացնել, դիմակավորել կամ արգելել փոխանցումը՝ ըստ տվյալների տեսակի և ուղղության։ Microsoft Purview-ի փաստաթղթավորումը նկարագրում է գաղտնագրմամբ զգայունության պիտակների իրավասության ստուգումը և այն, որ Purview-ին միացված Windows համակարգիչներում Endpoint DLP կանոնները կարող են զգուշացնել կամ արգելել զգայուն տվյալների փոխանցումը զննարկիչով բացված արտաքին ԱԲ կայքերին։ Այս հնարավորությունների կիրառումը կախված է աջակցվող միջավայրից և ընտրված կարգավորումներից։
• Դիտարկում և մատյանների մուտք. Գրանցեք հիշողության ընթերցումները, որոնումները, գործիքների կանչերն ու արգելափակված փոխանցումները, որպեսզի հնարավոր լինի պարզել՝ որ օգտատերը կամ գործակալը ինչ տվյալ է ստացել։ Սահմանափակեք նաև մատյանները դիտելու իրավունքը. իրադարձության գրառումը կարող է պարունակել նույն զգայուն տեղեկության հատվածը։ Ստուգեք՝ արդյոք դիտարկման համար պահվող տվյալը իսկապես անհրաժեշտ է հետաքննությանը։

Եթե գաղտնի տվյալն արդեն փոխանցվել է

Աշխատակիցը պետք է անհապաղ տեղեկացնի անվտանգության կամ ՏՏ պատասխանատուին՝ նշելով գործիքը, հաշիվը, փոխանցման ժամանակը, տվյալների տեսակը և միացված աղբյուրները։ Նույն տվյալը կրկին մի՛ ուղարկեք միջադեպը ստուգելու նպատակով։ Եթե փոխանցվել է գաղտնաբառ, բանալի կամ մուտքի նշան, պատասխանատու թիմը պետք է գնահատի այն փոխարինելու և համապատասխան մուտքը սահմանափակելու անհրաժեշտությունը։

ՏՏ թիմը պետք է պահպանի հետաքննությանը անհրաժեշտ իրադարձությունները և պարզի՝ տվյալը մնացել է արդյոք պատմության, հիշողության, ինդեքսի, գործիքի արդյունքի կամ մատյանի մեջ։ Այնուհետև ստուգեք, թե ովքեր են հասել այդ պահոցներին, կիրառեք համապատասխան ջնջման կամ մեկուսացման կարգը և ուղղեք փոխանցումը թույլ տված կանոնը։ Այդպես միջադեպի սահմանը որոշվում է տվյալների անցած ամբողջ ճանապարհով, ոչ միայն տեսանելի զրույցով։

Կարդացեք նաև:

• Prompt injection-ը filter-ով չի փակվում․ պաշտպանեք նաև գործակալի հիշողությունը
• Prompt cache-ը խնայում է մինչև 80%, եթե գործիքները չեն կոտրում prefix-ը
• Ollama թե LM Studio․ նույն մոդելի արագությունը որոշում է նաև build-ը