Google API გასაღებები საიდუმლო არ იყო, მაგრამ შემდეგ Gemini-მ შეცვალა წესები

როდესაც "საზოგადოებრივი დიზაინი" ხდება უსაფრთხოების ვალდებულება

თითქმის ორი ათწლეულის განმავლობაში, Google-ის ეკოსისტემაზე აგებულმა დეველოპერებმა ისწავლეს დახვეწილი, მაგრამ მნიშვნელოვანი გაკვეთილი: Google API გასაღებები ნამდვილად არ არის საიდუმლოებები. თუ თქვენ ჩასვით YouTube Data API გასაღები JavaScript ფაილში, Google არ შეშფოთებულა. თუ თქვენი Maps API გასაღები გამოჩნდა საჯარო GitHub საცავში, უსაფრთხოების პასუხი არსებითად იყო მხრების აჩეჩვა და დომენის შეზღუდვების დაწესების შეხსენება. მთელი მოდელი აშენდა იმ ვარაუდით, რომ ეს გასაღებები იცხოვრებდნენ კლიენტის მხარეს კოდით და ექვემდებარება ყველას, ვინც გახსნა DevTools.

ამ ფილოსოფიას დიდი ხნის განმავლობაში ჰქონდა აზრი. დომენის შეზღუდვების გარეშე გამოვლენილი Maps API კლავიში შესაძლოა მოულოდნელი გადასახადი მოჰყვეს, მაგრამ ის არ აპირებდა პაციენტის ჩანაწერების კომპრომეტირებას ან საბანკო ანგარიშის გაცლას. აფეთქების რადიუსი ფინანსური და მართვადი იყო. Google-ის ინსტრუმენტები — რეფერენტის შეზღუდვები, IP თეთრ სიაში, კვოტების ლიმიტები — შექმნილია იმისთვის, რომ შეიცავდეს ზიანს და არ თავიდან აიცილოს ექსპოზიცია მთლიანად.

შემდეგ ტყუპები მოვიდა და წესები შეიცვალა. პრობლემა ის არის, რომ მილიონობით დეველოპერს არ მიუღია შენიშვნა.

მემკვიდრეობის გონებრივი მოდელი, რომელიც ახლა დეველოპერებს წვავს

Google-ის დეველოპერის ძველი გამოცდილება შეგნებულად ნებადართული იყო. როდესაც თქვენ შექმენით Maps JavaScript API გასაღები, დოკუმენტაცია პრაქტიკულად გიბიძგებთ პირდაპირ თქვენს HTML-ში ჩაგდებაში. უსაფრთხოების მოდელი არ იყო საიდუმლოება - ეს იყო შეზღუდვა. ჩაკეტავდით თქვენი დომენის გასაღებს, დააყენებდით კვოტების გაფრთხილებებს და გააგრძელებდით. ეს იყო პრაგმატული ინჟინერია: კლიენტის მხრიდან აპლიკაციებს ნამდვილად არ შეუძლიათ საიდუმლოების შენახვა განსაზღვრული მომხმარებლებისგან, ამიტომ Google-მა შექმნა სისტემა, რომელიც აღიარებდა ამ რეალობას.

ამან შექმნა დეველოპერების თაობა - და რაც მთავარია, ინსტიტუციური ჩვევების თაობა - სადაც Google API გასაღებები იკავებდნენ განსხვავებულ გონებრივ კატეგორიას, ვიდრე, ვთქვათ, Stripe საიდუმლო გასაღები ან AWS წვდომის სერთიფიკატი. თქვენ არ ჩასვით თქვენი Stripe საიდუმლო გასაღები საჯარო რეპოში. მაგრამ თქვენი Maps გასაღები? ეს იყო პრაქტიკულად კონფიგურაციის მნიშვნელობა და არა საიდუმლო. ბევრი გუნდი ინახავდა მათ საჯარო კონფიგურაციის ფაილებში, README ფაილებში, თუნდაც კლიენტის მხარის გარემოს ცვლადებში, რომელთა პრეფიქსია NEXT_PUBLIC_ ან REACT_APP_ მეორედ დაუფიქრებლად.

უსაფრთხოების მკვლევარებმა, რომლებიც სკანირებენ GitHub-ს გამოვლენილი რწმუნებათა სიგელების გამოსავლენად, ისწავლეს Google API გასაღებების განსხვავებულად გამოყენებაც. გაჟონილი Maps გასაღები დაბალი სიმძიმის აღმოჩენა იყო. გაჟონილი ტყუპების გასაღები სრულიად განსხვავებული საუბარია.

რა შეიცვალა ტყუპებთან - და რატომ აქვს მნიშვნელობა

Google-ის Gemini API არ მიჰყვება ძველ სათამაშო წიგნს. როდესაც აგენერირებთ Gemini API კლავიშს Google AI Studio-ს მეშვეობით, თქვენ ქმნით ავტორიზაციას ფუნდამენტურად განსხვავებული რისკის პროფილით, ვიდრე Maps ან YouTube გასაღები. Gemini კლავიშები ახდენენ წვდომას დიდი ენობრივი მოდელის დასკვნაზე წვდომის ავტორიზაციაზე — სერვისი, რომელიც ღირებს Google-ს რეალურ გამოთვლილ რესურსებზე და რომელიც ანგარიშს გიხდით ნიშნის მიხედვით და არა გვერდის ნახვის მიხედვით.

უფრო კრიტიკულად, Gemini API კლავიშებს არ გააჩნიათ იგივე ჩაშენებული დომენის შეზღუდვის მექანიზმები, რამაც Google-ის სხვა გასაღებების გამოვლენა შესაძლებელი გახადა. არ არსებობს მარტივი კონტროლი „დაბლოკე ეს ჩემი ვებსაიტის დომენზე“, რომელიც ხელს შეუშლის თავდამსხმელს, რომელმაც იპოვა თქვენი გასაღები საჯარო საცავში, არ დაატრიალოს საკუთარი აპლიკაცია და გამოიყენოს თქვენი კვოტა — ან თქვენი ბილინგის ლიმიტი — სხვა ქვეყნის სერვერიდან.

საშიშროება მხოლოდ ფინანსური არ არის. გამოვლენილი Gemini გასაღები შეიძლება გამოყენებულ იქნას მავნე კონტენტის გენერირებისთვის, სწრაფი ინექციის შეტევების განსახორციელებლად ან ინსტრუმენტების შესაქმნელად, რომლებიც არღვევს Google-ის მომსახურების პირობებს — ეს ყველაფერი დარიცხულია თქვენს ანგარიშზე და იდენტიფიცირებულია.

2024 წელს უსაფრთხოების მკვლევარებმა გამოავლინეს ათასობით ღია Gemini API გასაღები მხოლოდ GitHub-ზე, ბევრი მათგანი იმ საცავებში, რომლებშიც მანამდე სხვა Google API გასაღებები ინციდენტის გარეშე იყო განთავსებული. დეველოპერები არ იყვნენ უგუნური საკუთარი ისტორიული სტანდარტებით - ისინი იყენებდნენ მენტალურ მოდელს, რომლის გამოყენებასაც თავად Google-მა ასწავლა. გარემო უფრო სწრაფად შეიცვალა, ვიდრე ჩვევები.

შემთხვევითი ექსპოზიციის ანატომია

გაცნობიერება, თუ როგორ ხდება ეს ზემოქმედება, არის პირველი ნაბიჯი მათი პრევენციისკენ. წარუმატებლობის რეჟიმები საოცრად თანმიმდევრულია ყველა ზომის გუნდში:

• გარემოს ცვლადის არასწორი კლასიფიკაცია: დეველოპერები, რომლებიც იყენებენ Google Maps-ის კლავიშებს, პრეფიქსით უსვამენ Gemini გასაღებებს NEXT_PUBLIC_ ან VITE_, მყისიერად ავლენენ მათ შეფუთულ კლიენტის მხარეს კოდით.
• საცავის ისტორიის დაბინძურება: გასაღები ემატება კონფიგურაციის ფაილს, ჩადენილია, შემდეგ ამოღებულია — მაგრამ git ისტორია რჩება განუსაზღვრელი ვადით საძიებო. თავდამსხმელები იყენებენ ინსტრუმენტებს, როგორიცაა truffleHog და gitleaks სპეციალურად ამ ისტორიის მოსაპოვებლად.
• ნოუთბუქისა და პროტოტიპის გაჟონვა: მონაცემთა მეცნიერები, რომლებიც ქმნიან Gemini-ის ინტეგრაციის პროტოტიპებს Jupyter-ის ნოუთბუქებში, ამ ბლოკნოტებს უბიძგებენ GitHub-ში უჯრედის გამოსავალში ჩასმული კლავიშებით.
• CI/CD არასწორი კონფიგურაცია: საცავის საიდუმლოებად შენახული გასაღებები შემთხვევით ეხმიანება build ჟურნალებს, რომლებიც საჯაროდ ჩანს GitHub Actions-ზე ან მსგავს პლატფორმებზე.
• მესამე მხარის სერვისების გავრცელება: დეველოპერები ათავსებენ გასაღებებს ანალიტიკის საინფორმაციო დაფებში, კოდის გარეშე ინსტრუმენტებში ან ინტეგრაციის პლატფორმებში ამ პლატფორმების უსაფრთხოების პოზების გადახედვის გარეშე.
• გუნდის საკომუნიკაციო არხები: Slack-ის, Discord-ის ან ელფოსტის საშუალებით გაზიარებული კლავიშები მთავრდება საძიებო შეტყობინებების ისტორიაში, რომელიც აჭარბებს როტაციის განრიგს.

საერთო თემა არ არის დაუდევრობა - ეს არის კონტექსტის კოლაფსი. ქცევები, რომლებიც უსაფრთხო იყო ერთ კონტექსტში (Google Maps-ის შემუშავება) საშიშია მეორეში (Gemini-ის განვითარება) და რწმუნებათა სიგელების ვიზუალური მსგავსება აადვილებს განსხვავებას.

საიდუმლოების მართვის კულტურის შექმნა, რომელიც მასშტაბურია

ტყუპების ვითარება სასარგებლო იძულებითი ფუნქციაა იმისთვის, რასაც მრავალი დეველოპერული გუნდი აფერხებდა: საიდუმლოების მართვის რეალური ინფრასტრუქტურის შექმნა და არა ad-hoc მიდგომები. მცირე გუნდებისთვის ეს შეიძლება ზედმეტი ინჟინერიის მსგავსი იყოს, მაგრამ რწმუნებათა სიგელების გაცნობის ღირებულება - ბილინგის თაღლითობა, ანგარიშის შეჩერება, მონაცემთა დარღვევის შეტყობინებები - მნიშვნელოვნად აღემატება ამის სწორად შესრულების ძალისხმევას.

საიდუმლოების თანამედროვე მენეჯმენტი მიჰყვება ეტაპობრივ მიდგომას. ინფრასტრუქტურის დონეზე, ისეთი ხელსაწყოები, როგორიცაა HashiCorp Vault, AWS Secrets Manager ან Google Secret Manager, უზრუნველყოფს ცენტრალიზებულ, აუდიტორულ რწმუნებათა შენახვას ავტომატური ბრუნვის შესაძლებლობებით. ეს არ არის მხოლოდ მსხვილი საწარმოებისთვის — სერვისები, როგორიცაა Doppler და Infisical, ერთსა და იმავე ნიმუშებს მოაქვს ორი ან სამი დეველოპერისგან შემდგარ გუნდებს ხელმისაწვდომ ფასად.

კოდის დონეზე, დისციპლინა უფრო მარტივია: რწმუნებათა სიგელები არასოდეს ეხება წყაროს კოდს. სრული გაჩერება. არა კომენტირებული სტრიქონებში, არც სამაგალითო ფაილებში, არც სატესტო მოწყობილობებში ყალბი გარეგნობის მნიშვნელობებით, რომლებიც რეალური აღმოჩნდება. წინასწარ ჩააბარეთ კაუჭები, რომლებიც მუშაობენ ინსტრუმენტებზე, როგორიცაა detect-secrets ან gitleaks დაფიქსირებულ დარღვევებს მანამ, სანამ ისინი მიაღწევენ დისტანციურ საცავებს. ამ კაკვებს კონფიგურაციას წუთები სჭირდება და წლები აშორებს თქვენს ინციდენტზე რეაგირების შფოთვას.

ორგანიზაციებისთვის, რომლებიც მართავენ რთულ ოპერაციულ დასტას - ყველაფრის მართვა CRM სამუშაო ნაკადებიდან დაწყებული სახელფასო ინტეგრაციებით და მომხმარებელთან დაჯავშნის სისტემებით - ცენტრალიზებული რწმუნებათა მენეჯმენტი კიდევ უფრო მნიშვნელოვანი ხდება. პლატფორმები, როგორიცაა Mewayz, რომელიც აერთიანებს 207 ბიზნეს მოდულს ერთი ოპერაციული ქოლგის ქვეშ, აგებულია ამ პრინციპით: სერთიფიკატები და API ინტეგრაციები იმართება პლატფორმის დონეზე, არ არის მიმოფანტული ცალკეულ მოდულებში ან ცალკეულ დეველოპერების გარემოში. როდესაც გასაღების შეტრიალებაა საჭირო, ეს ხდება ერთხელ, ერთ ადგილას, არა ჩვიდმეტ სხვადასხვა ინტეგრაციის წერტილში.

ბილინგის შეტევის ვექტორი: მოდელის დეველოპერების საფრთხის შეფასება

უსაფრთხოებასთან დაკავშირებული დისკუსიები ხშირად ფოკუსირებულია მონაცემების დარღვევაზე და არაავტორიზებულ წვდომაზე. ტყუპების ზემოქმედების პრობლემა ამატებს საფრთხის მესამე მოდელს, რომელიც თანაბარ ყურადღებას იმსახურებს: ბილინგის თაღლითობა მასშტაბით.

დიდი ენობრივი მოდელის დასკვნა ძვირია. GPT-4 და Gemini Ultra ამუშავებენ ტოკენებს თითოეული ცენტის წილად, მაგრამ მასშტაბით - ათასობით მოთხოვნა, მილიონობით ჟეტონი - ეს ფრაქციები ძალიან სწრაფად აგროვებს ათასობით დოლარს. თავდამსხმელებს, რომლებიც აღმოაჩენენ AI API გასაღებებს, სულაც არ უნდათ თქვენი მონაცემები. მათ სურთ უფასო გამოთვლა. ისინი გამოიყენებენ თქვენს რწმუნებათა სიგელებს საკუთარი ხელოვნური ინტელექტის სერვისების გასაშვებად, დასკვნის შესაძლებლობების გადაყიდვისთვის ან აპლიკაციების სტრესის შესამოწმებლად — ეს ყველაფერი მაშინ, სანამ გადასახადი თქვენს ხელშია.

ერთმა დეველოპერმა დაადასტურა, რომ ექვს საათზე ნაკლები ხნის განმავლობაში საჯარო საცავში გამოფენილი Gemini გასაღებიდან 23,000 აშშ დოლარის კუპიურა გაიღვიძა. თავდამსხმელმა დაუყონებლივ მოახდინა ექსპლუატაციის ავტომატიზაცია, უწყვეტად აწარმოებდა მაღალი გამტარუნარიანობის დავალებებს, სანამ Google-ის თაღლითობის გამოვლენა არ დაფიქსირდა. დეველოპერმა საბოლოოდ გააუქმა გადასახადები ხანგრძლივი დავის პროცესის შემდეგ, მაგრამ ანგარიში შეჩერებული იყო ამ პერიოდის განმავლობაში, რის შედეგადაც გააუქმა წარმოების სერვისები.

სწორედ ამიტომ ბილინგის გაფრთხილებები და კვოტების ლიმიტები არ არის საიდუმლოების სათანადო მართვის შემცვლელი - ისინი თავდაცვის ბოლო ხაზია, რომელიც იმედი გაქვთ, რომ არასდროს დაგჭირდებათ. AI API ანგარიშებზე ყოველთვიური დანახარჯების მკაცრი ლიმიტების დაწესება ახლა ცხრილის ფსონია, მაგრამ რეალური დაცვა არის იმის უზრუნველყოფა, რომ ეს რწმუნებათა სიგელები პირველ რიგში არასოდეს გაჟონოს.

პრაქტიკული ნაბიჯები გუნდებისთვის, რომლებიც ცვლიან

თუ თქვენი გუნდი აშენებდა Google API-ს ინტეგრაციებს ძველი გონებრივი მოდელის მიხედვით და ახლა ამატებს Gemini-ს, აქ არის რემედიაციის რეალისტური ჩამონათვალი:

1. აუდიტირება არსებული საცავების დაუყოვნებლივ. გაუშვით truffleHog ან gitleaks თქვენი სრული git ისტორიის მიხედვით და არა მხოლოდ მიმდინარე HEAD. განსაკუთრებული ყურადღება გაამახვილეთ ნებისმიერ საცავზე, რომელსაც წარსულში ჰქონდა Google API გასაღების გამოყენება.
2. შეატრიალეთ ყველა ღია გასაღები. თუ Gemini გასაღები ოდესმე გამოჩნდა დავალებაში, ჩავთვალოთ, რომ ის კომპრომეტირებულია. გააუქმეთ იგი და შექმენით ახალი. ნუ ეცდებით შეაფასოთ, იპოვა თუ არა ვინმემ ის „რეალურად“.
3. განახორციელეთ წინასწარი სკანირება. დააინსტალირეთ საიდუმლო აღმოჩენის კაკვები ყველა დეველოპერის აპარატზე და CI/CD მილსადენებში, როგორც შეუვალი კარიბჭე.
4. შეადგინეთ ძირითადი ინვენტარი. იცოდეთ, რომელ სერვისებს აქვთ სერთიფიკატები, ვის ეკუთვნის ისინი, როდის მოხდა მათი ბოლო როტაცია და სად გამოიყენება. ცხრილი კარგი საწყისი წერტილია; საიდუმლოების მენეჯერი არის დანიშნულება.
5. დააყენეთ ბილინგის გაფრთხილებები და მკაცრი ლიმიტები. ყოველ AI API ანგარიშზე, დააკონფიგურირეთ გაფრთხილებები თქვენი მოსალოდნელი თვიური ხარჯების 50% და 80%-ზე და დააყენეთ მკაცრი ლიმიტები, რომლებიც თავიდან აიცილებს კატასტროფულ ბილინგის მოვლენებს.
6. ახალი გონებრივი მოდელის ცალსახად დოკუმენტაცია. განაახლეთ თქვენი გუნდის საბორტო მასალები და საინჟინრო სახელმძღვანელო, რათა ცალსახად განაცხადოთ, რომ Gemini API კლავიშები არის მაღალი მგრძნობელობის სერთიფიკატები, რომლებიც საჭიროებენ იგივე მოპყრობას, როგორც გადახდის პროცესორის საიდუმლოებებს.

უფრო ფართო გაკვეთილი პლატფორმაზე დამოკიდებული ბიზნესებისთვის

ტყუპების სიტუაცია ასახავს შაბლონს, რომელიც გავლენას ახდენს ნებისმიერ ბიზნესზე, რომელიც ღრმად არის ინტეგრირებული მესამე მხარის პლატფორმებთან: პლატფორმები ვითარდება და უსაფრთხოების პოზების მოთხოვნები ვითარდება მათთან ერთად, მაგრამ გუნდების ინსტიტუციური ჩვევები, რომლებიც იყენებენ ამ პლატფორმებს, ხშირად არ ინარჩუნებენ ტემპს. ის, რაც გუშინ უსაფრთხო იყო, დღეს საშიშია და ამ ორ სახელმწიფოს შორის არსებული უფსკრული არის ის, სადაც ხდება დარღვევები.

ეს განსაკუთრებით მწვავეა იმ ბიზნესებისთვის, რომლებიც ამუშავებენ რთულ ოპერაციულ დასტას. კომპანიას, რომელიც იყენებს AI-ზე მომუშავე ფუნქციებს მომხმარებელთა მომსახურებაში, ანალიტიკაში, კონტენტის გენერირებასა და პროდუქტის რეკომენდაციებში, შესაძლოა ჰქონდეს Gemini ინტეგრაცია ათეულ სხვადასხვა კონტექსტში – თითოეული მათგანი პოტენციური ექსპოზიციის წერტილია, თუ რწმუნებათა სიგელები არათანმიმდევრულად დამუშავდება. გამოსავალი არ არის მხოლოდ უკეთესი ინდივიდუალური დეველოპერების ჩვევები; ეს არის არქიტექტურული. ავტორიზაციაზე წვდომა უნდა იყოს ცენტრალიზებული, აუდიტი და მართული პლატფორმის დონეზე.

თანამედროვე ბიზნეს ოპერაციული სისტემები სულ უფრო მეტად არის შექმნილი ამის გათვალისწინებით. როდესაც Mewayz აერთიანებს AI შესაძლებლობებს თავის კომპლექტში - ინტელექტუალური CRM სამუშაო ნაკადებიდან ავტომატიზირებულ ანალიტიკამდე მის 207 მოდულ ეკოსისტემაში - სერთიფიკატების მართვა მუშავდება ინფრასტრუქტურის ფენაში და არა აპლიკაციის ფენაში. ინდივიდუალური მოდულის დეველოპერები არ ამუშავებენ დაუმუშავებელ API კლავიშებს; ისინი წვდებიან შესაძლებლობებს აბსტრაქციის ფენების მეშვეობით, რომლებიც ახორციელებენ ბრუნვის პოლიტიკას, აუდიტის წვდომას და ზღუდავენ აფეთქების რადიუსს, თუ რამე არასწორედ მოხდება. ეს არის არქიტექტურა, რომელსაც ითხოვს ტყუპების ეპოქა: არა მხოლოდ უკეთესი ჩვევები, არამედ უკეთესი სისტემები, რომლებიც სწორ ჩვევას ერთადერთ ხელმისაწვდომ ვარიანტად აქცევს.

Google-მა არ დაუშვა შეცდომა Maps-ისა და YouTube-ისთვის ნებადართული API გასაღების მოდელის შექმნისას. ეს მოდელი შესაბამისი იყო ამ სერვისებისთვის. მაგრამ რამდენადაც API-ების შესაძლებლობები და ღირებულების პროფილები მკვეთრად ვითარდება - და რადგან AI API-ები წარმოადგენენ ალბათ ყველაზე მკვეთრ დახრის წერტილს ამ ევოლუციაში - მთელ ინდუსტრიას სჭირდება ნაგულისხმევი პარამეტრების გადატვირთვა. დეველოპერები, რომლებიც აყვავდებიან ამ გარემოში, არ იქნებიან ისინი, ვინც საუკეთესოდ ისწავლეს ძველი წესები, არამედ ისინი, ვინც ხვდებიან, როდის შეიცვალა წესები ძირეულად.

ხშირად დასმული კითხვები

რატომ ითვლებოდა Google API გასაღებები ისტორიულად უსაფრთხოდ საჯარო გასაჯაროებისთვის?

Google-მა დააპროექტა მრავალი API — Maps, YouTube, Places — კლიენტის მხრიდან გამოსაყენებლად, რაც იმას ნიშნავს, რომ გასაღებები განზრახ ჩაშენებული იყო წინა კოდში, რომელიც ხილული იყო ყველასთვის. უსაფრთხოების მოდელი ეყრდნობოდა გამოყენების შეზღუდვებს, როგორიცაა დომენის ნებადართული სიები და რეფერენტის შემოწმება, ვიდრე გასაღების საიდუმლოება. წლების განმავლობაში, ღია გასაღები განიხილებოდა კონფიგურაციის პრობლემად და არა კრიტიკულ დაუცველობად, რომელიც საჭიროებს დაუყოვნებლივ როტაციას.

რა შეიცვალა, როდესაც Google-მა შემოიტანა Gemini API გასაღებები?

განსხვავებით მოძველებული Google API-ებისგან, Gemini API კლავიშები უფრო მეტად ფუნქციონირებს, როგორც ტრადიციული საიდუმლოებები — ამის გამოვლენამ შეიძლება გამოიწვიოს თქვენი ბილინგის ანგარიშის არაავტორიზებული გადასახადები, მოდელის ბოროტად გამოყენება ან კვოტების ამოწურვა დომენის ჩაშენებული შეზღუდვის გარეშე, რათა დაზოგოთ. ეს ცვლა ნიშნავს, რომ დეველოპერებმა ახლა უნდა მოექცნენ Gemini გასაღებებს იგივე დისციპლინის მიხედვით, როგორც AWS რწმუნებათა სიგელები ან Stripe საიდუმლო გასაღებები, შეინახონ ისინი სერვერის მხარეს და არასდროს კლიენტის წინაშე მყოფი კოდით.

როგორ უნდა მართონ დეველოპერებმა დღეს უსაფრთხოდ API გასაღებები AI სერვისებისთვის?

საუკეთესო პრაქტიკა არის ყველა AI API გასაღების შენახვა სერვერზე გარემოს ცვლადებად, არასდროს ვერსიით კონტროლირებულ ფაილებში ან კლიენტის პაკეტებში. გამოიყენეთ საიდუმლოების მენეჯერი, რეგულარულად დააბრუნეთ გასაღებები და დააწესეთ ხარჯვის ლიმიტები პროვაიდერის დონეზე. პლატფორმები, როგორიცაა Mewayz - 207 მოდულიანი ბიზნეს ოპერაციული სისტემა $19/თვეში ხელმისაწვდომია app.mewayz.com - ამუშავებს API სერთიფიკატების მართვას მათი ინფრასტრუქტურის ფარგლებში, რათა გუნდები ხელით არ ახერხებენ ჟონგლირებით გასაღებს სერვისებში.

რა უნდა გავაკეთო, თუ შემთხვევით უკვე გავუმხილე Gemini API გასაღები?

გაუქმეთ გატეხილი გასაღები Google Cloud Console-ის საშუალებით და შექმენით ჩანაცვლება, სანამ რაიმეს გააკეთებთ. შეამოწმეთ თქვენი ბილინგის საინფორმაციო დაფა მოხმარების მოულოდნელ მწვერვალებზე, რაც შეიძლება მიუთითებდეს, რომ გასაღები ამოღებულია. შემდეგ გადახედეთ თქვენს კოდების ბაზას, CI/CD გარემოს ცვლადებს და ნებისმიერ საჯარო საცავებს სხვა გაჟონილი რწმუნებათა სიგელებისთვის. მოექეცით ინციდენტს ისე, როგორც ნებისმიერ მხილებულ გადახდის სერთიფიკატს — ჩათვალეთ, რომ ის ნაპოვნია და იმოქმედეთ შესაბამისად.