Ինչպես պահել API բանալիները անվտանգ ձեր հավելվածում

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

API բանալին ծառայության գաղտնաբառ է։ Ձեր OpenAI բանալին թույլ է տալիս որևէ մեկին ծախսել ձեր գումարը AI-ի վրա, ձեր Stripe գաղտնի բանալին՝ վերադարձներ կատարել, ձեր էլփոստի մատակարարի բանալին՝ նամակներ ուղարկել ձեր անունից։ AI հավելվածի կառուցողները լավ են դրանք միացնելու մեջ, բայց միշտ չէ, որ զգույշ են, թե որտեղ են դրանք հայտնվում, ուստի այս ուղեցույցը ցույց է տալիս, թե ինչպես պահել դրանք անվտանգ և ինչպես ստուգել։

Հրապարակային և գաղտնի բանալիներ

Ոչ բոլոր բանալիներն են գաղտնի։ Այս տարբերությունը իմանալը թույլ է տալիս չանհանգստանալ սխալ բանալու համար և չանտեսել ճիշտը։

Եթե վստահ չեք, թե որ տեսակն է բանալին, ստուգեք մատակարարի փաստաթղթերը։ Երբ կասկածում եք, վարվեք որպես գաղտնի։

Քայլ 1. Պահեք բանալիները որպես գաղտնիքներ, ոչ թե կոդում

Բանալիները պատկանում են ձեր հոստի միջավայրի փոփոխականներին կամ գաղտնիքների կարգավորումներին։ Ձեր կոդը կարդում է դրանք անունով գործարկման ժամանակ (օրինակ՝ process.env.OPENAI_API_KEY), այնպես որ արժեքը երբեք չի հայտնվում ձեր ֆայլերում։ Ֆոնի համար տե՛ս ինչ են միջավայրի փոփոխականներն ու գաղտնիքները։

Տեղափոխեք յուրաքանչյուր API բանալի կոդից միջավայրի փոփոխականների մեջ։ Թվարկեք յուրաքանչյուր գտնված բանալի, թե որ ֆայլում էր և ինչ փոփոխական անուն օգտագործեցիք։ Արժեքները մի ցույց տաք։

Հետո ստուգեք, որ ոչինչ չի մնացել․

Որոնեք ամբողջ նախագիծը, ներառյալ կարգավորման ֆայլերը և ցանկացած .env ֆայլ, ցանկացած բանի համար, որ նման է API բանալու կամ գաղտնաբառի։ Հաղորդեք ֆայլն ու տողը, ոչ թե արժեքը։

Քայլ 2. Օգտագործեք գաղտնի բանալիներ միայն սերվերում

Սա ամենակարևոր կանոնն է։ Այն, ինչ ստանում է բրաուզերը, կարող է կարդալ յուրաքանչյուր այցելու․ էջի աղբյուրը և JavaScript ֆայլերը բոլորը տեսանելի են մշակողի գործիքներում։

Ուստի եթե հավելվածը պետք է կանչի OpenAI, բրաուզերը պետք է կանչի ձեր սերվերը, և ձեր սերվերը կանչի OpenAI՝ բանալիով։ Բանալին երբեք չի թողնում սերվերը։

Զրույցի գործառույթը անմիջապես կանչում է OpenAI-ին բրաուզերից։ Տեղափոխեք այդ կանչը սերվերային API երթուղի, որը կարդում է OPENAI_API_KEY-ը միջավայրից։ Բրաուզերը պետք է կանչի միայն մեր երթուղին։ Երթուղու համար պահանջեք մուտք։

Ուշադրություն դարձրեք մեկ սովորական թակարդի վրա front-end շրջանակներում․ հանրային նախածանց ունեցող փոփոխականները՝ Vite-ում VITE_, Next.js-ում NEXT_PUBLIC_, միտումնավոր կառուցվում են բրաուզերի կոդի մեջ։ Գաղտնի բանալին այդ նախածանցներից մեկով բացահայտված է, թեև այն «միջավայրի փոփոխականի մեջ է»։

Քայլ 3. Ստուգեք, որ ոչինչ չի արտահոսում

Մի վստահեք, որ աշխատեց․ ստուգեք կենդանի կայքը։

1. Բացեք հրապարակված հավելվածը բրաուզերում։
2. Բացեք մշակողի գործիքները, ապա Sources կամ Network ներդիրը։
3. Որոնեք ֆայլերում յուրաքանչյուր գաղտնի բանալու առաջին նիշերը (օրինակ՝ sk_ կամ sk-)։
4. Ստուգեք հավելվածի ցանցային հարցումները։ Հարցում, որ գնում է ուղիղ բրաուզերից դեպի վճարովի AI մատակարար, կարմիր դրոշ է։

Եթե գտնեք գաղտնի բանալի, տեղափոխեք այն սերվեր (քայլ 2) և փոխեք այն (քայլ 6), քանի որ այն արդեն հանրային էր։

Քայլ 4. Սահմանափակեք, թե ինչ կարող է յուրաքանչյուր բանալի

Շատ մատակարարներ թույլ են տալիս սահմանափակել բանալին․

• Սահմանափակված կամ կարգավորված բանալիներ, որոնք կարող են անել միայն այն, ինչ պետք է ձեր հավելվածին։ Օրինակ՝ Stripe-ը աջակցում է սահմանափակված բանալիներին հատուկ թույլտվություններով։
• Տիրույթի կամ IP սահմանափակումներ բանալիների համար, որոնք պետք է հանրային լինեն, օրինակ՝ քարտեզի բանալիներ։
• Առանձին բանալիներ յուրաքանչյուր հավելվածի և միջավայրի համար, որպեսզի մեկ արտահոսքը չբացահայտի ամեն ինչ, և մեկի չեղարկումը չխզի մյուսները։
• Փորձարկման բանալիներ կառուցելու ընթացքում, իսկ իրական բանալիներ միայն հրապարակված հավելվածում։

Քայլ 5. Դրեք վնասի սահման

Եթե նույնիսկ լավ պաշտպանված բանալին կարող է չարաշահվել ձեր հավելվածի միջոցով․ օրինակ՝ մեկը սցենարով հազարավոր անգամ կանչում է ձեր AI գործառույթը։

• Սահմանեք ծախսերի սահմաններ կամ ծանուցումներ յուրաքանչյուր վճարովի մատակարարի մոտ։
• Պահանջեք մուտք յուրաքանչյուր գործառույթի համար, որն արժե գումար յուրաքանչյուր կանչի համար։
• Ավելացրեք օգտատիրոջ մեկ-օգտատիրոջ սահմանափակում։ Տե՛ս ինչ է արագության սահմանափակումը։

Ավելացրեք սահման՝ յուրաքանչյուր օգտատիրոջ համար ժամում 30 AI հարցում /api/chat-ի վրա։ Երբ սահմանը հասնի, վերադարձրեք հստակ հաղորդագրություն։ Մերժեք այն հարցումները, որոնք մուտք չեն գործել։

Քայլ 6. Փոխեք արտահոսած բանալիները

Եթե գաղտնի բանալին հայտնվում է այնտեղ, որտեղ չպետք է՝ չաթի հաղորդագրություն, commit, սքրինշոթ, աջակցության տոմս, բրաուզերի կոդ, ենթադրեք, որ այն վտանգված է։

1. Ստեղծեք նոր բանալի մատակարարի մոտ։
2. Թարմացրեք գաղտնիքը ձեր հավելվածի կարգավորումներում։
3. Նորից տեղադրեք կամ նորից հրապարակեք, որպեսզի կենդանի հավելվածը օգտագործի նոր բանալին։
4. Ջնջեք հին բանալին մատակարարի մոտ։
5. Ստուգեք մատակարարի օգտագործման մատյանները անծանոթ գործունեության համար։

Չաթի հաղորդագրությունը կամ Git commit-ը ջնջելը բավարար չէ։ Git-ի պատմությունը պահպանում է հին տարբերակները, իսկ հանրային ամեն ինչ կարող է արդեն պատճենված լինել։

Սովորական սխալներ

• Բանալին հուշման մեջ տեղադրել։ Այն արդեն չաթի պատմության մեջ է։ Օգտագործեք գաղտնիքների ձև փոխարենը։
• Հանրային նախածանց գաղտնի փոփոխականի վրա։ VITE_OPENAI_API_KEY-ը բանալին ուղարկում է յուրաքանչյուր այցելուին։
• .env ֆայլ commit անելը։ Համոզվեք, որ այն գտնվում է .gitignore-ում մինչև առաջին push-ը։
• Մեկ բանալի ամենուր։ Օգտագործեք առանձին բանալիներ փորձարկման և իրականի համար, և յուրաքանչյուր հավելվածի համար։
• Առանց ծախսերի սահմանի։ Արտահոսած կամ չարաշահված բանալին առանց սահմանի կարող է մեծ հաշիվ ստեղծել, նախքան նկատելը։
• Թաքցնել, այլ ոչ թե փոխել։ Երբ բանալին արտահոսել է, միայն նոր բանալին է լուծում խնդիրը։
• Բանալիներ սքրինշոթներում։ Կտրեք կամ խամրեցրեք կարգավորումների էջերը, նախքան օգնություն խնդրելու համար կիսվելը։

Ստուգաթերթ

• Յուրաքանչյուր բանալի պահված է որպես գաղտնիք կամ միջավայրի փոփոխական, ոչ թե կոդում։
• Ոչ մի .env ֆայլ կամ բանալի commit չի արված Git-ում։
• Գաղտնի բանալիները օգտագործվում են միայն սերվերային կոդում։
• Ոչ մի գաղտնի փոփոխական չունի հանրային նախածանց, ինչպիսին է VITE_ կամ NEXT_PUBLIC_։
• Ես որոնել եմ կենդանի կայքի JavaScript-ը յուրաքանչյուր բանալու նախածանցով և ոչինչ չեմ գտել։
• Բանալիները սահմանափակված կամ կարգավորված են, որտեղ մատակարարը թույլ է տալիս։
• Փորձարկման և իրական բանալիները առանձին են։
• Վճարովի գործառույթները պահանջում են մուտք և ունեն մեկ-օգտատիրոջ սահմանաչափեր։
• Յուրաքանչյուր վճարովի մատակարար ունի ծախսերի սահման կամ ծանուցում։
• Գիտեմ, թե ինչպես փոխել յուրաքանչյուր բանալի, և ցանկացած երբևէ արտահոսած բանալի փոխված է։

Ինչպես պահել բանալիները անվտանգ Mythex-ում

Mythex-ը պահում է բանալիները ձեր կոդից և չաթից դուրս երկու եղանակով․

• Գաղտնիքների հարցման քարտ։ Երբ գործակալը բանալի է պետք, ցույց է տալիս քարտ չաթում, որտեղ դուք մուտքագրում եք արժեքը ձևի դաշտերում, ոչ թե հաղորդագրության դաշտում, և այն պահվում է որպես նախագծի գաղտնիք։ Տե՛ս Գաղտնիքները չաթում։
• Նախագծի կարգավորումներ → Գաղտնիքներ, կամ /secrets չաթում՝ բանալիներ ավելացնելու կամ փոխելու համար ինքներդ։ Տե՛ս Միջավայրի փոփոխականներ և գաղտնիքներ։

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

Գործարկումից առաջ անվտանգության մնացած անցման համար աշխատեք AI-ով կառուցված հավելվածների անվտանգության ստուգաթերթով։ Եթե ավելացնում եք AI գործառույթներ, ինչպես օգտագործել LLM API-ները ավելի խորությամբ է լուսաբանում բանալիները և արժեքները։

Հարցեր