Cheile Google API nu erau secrete, dar apoi Gemenii au schimbat regulile

Când „Public prin design” devine o răspundere de securitate

Timp de aproape două decenii, dezvoltatorii care se bazează pe ecosistemul Google au învățat o lecție subtilă, dar importantă: cheile API Google nu sunt cu adevărat secrete. Dacă ați încorporat o cheie YouTube Data API într-un fișier JavaScript, Google nu a fost alarmat. Dacă cheia dvs. API Maps a apărut într-un depozit public GitHub, răspunsul de securitate a fost în esență o ridicare din umeri și un memento pentru a seta restricții de domeniu. Întregul model a fost construit în baza ipotezei că aceste chei ar locui în codul clientului, expus oricărei persoane care a deschis DevTools.

Acea filozofie a avut sens pentru o lungă perioadă de timp. O cheie API Maps expusă fără restricții de domeniu ar putea acumula o factură surpriză, dar nu avea să compromită înregistrările pacienților sau să epuizeze un cont bancar. Raza exploziei era financiară și gestionabilă. Instrumentele Google — restricții de referință, lista albă IP, limite de cotă — au fost concepute pentru a limita daunele, nu pentru a preveni complet expunerea.

Apoi au sosit Gemenii, iar regulile s-au schimbat. Problema este că milioane de dezvoltatori nu au primit nota.

Modelul mental moștenit care acum îi dă pe dezvoltatori arși

Vechea experiență de dezvoltator Google a fost în mod deliberat permisivă. Când ați creat o cheie API JavaScript Maps, practic, documentația v-a încurajat să o plasați direct în HTML. Modelul de securitate nu era secret, ci restricție. Veți bloca cheia domeniului dvs., veți seta alerte de cotă și veți merge mai departe. Aceasta a fost o inginerie pragmatică: aplicațiile la nivelul clientului cu adevărat nu pot păstra secrete de la utilizatorii hotărâți, așa că Google a creat un sistem care a recunoscut această realitate.

Aceasta a creat o generație de dezvoltatori – și, mai important, o generație de obiceiuri instituționale – în care cheile API Google ocupau o categorie mentală diferită de, de exemplu, o cheie secretă Stripe sau o acreditări de acces AWS. Nu ați lipi cheia secretă Stripe într-un depozit public. Dar cheia dvs. Maps? Aceasta a fost practic o valoare de configurare, nu un secret. Multe echipe le-au stocat în fișiere de configurare destinate publicului, fișiere README, chiar și în variabile de mediu la nivelul clientului prefixate cu NEXT_PUBLIC_ sau REACT_APP_ fără să vă gândiți.

Cercetătorii în securitate care scanează GitHub în căutarea acreditărilor expuse au învățat să trateze și cheile API Google în mod diferit. O cheie Hărți scurs a fost o constatare de severitate scăzută. O cheie Gemeni scursă este o conversație complet diferită.

Ce s-a schimbat cu Gemeni – și de ce contează

Google Gemini API nu respectă vechiul manual de joc. Când generați o cheie API Gemini prin Google AI Studio, creați o acreditare cu un profil de risc fundamental diferit de o cheie Maps sau YouTube. Cheile Gemini autentifică accesul la inferența modelului de limbaj mare — un serviciu care costă resursele reale de calcul Google și care te facturează prin simbol, nu prin vizualizarea de pagină.

Mai critic, cheile Gemini API nu au aceleași mecanisme de restricție a domeniului încorporate care au făcut ca expunerea altor chei Google să poată supraviețui. Nu există un control simplu „blocați acest lucru în domeniul site-ului meu” care să împiedice un atacator care a găsit cheia dvs. într-un depozit public să-și dezvolte propria aplicație și să vă consume cota – sau limita de facturare – de la un server dintr-o altă țară.

Pericolul nu este doar financiar. O cheie Gemini expusă poate fi utilizată pentru a genera conținut dăunător, pentru a efectua atacuri cu injecție promptă sau pentru a construi instrumente care încalcă termenii și condițiile Google, toate facturate în contul dvs. și urmăribile până la identitatea dvs.

În 2024, cercetătorii de securitate au identificat mii de chei API Gemini expuse numai pe GitHub, multe dintre ele în depozite care găzduiseră anterior alte chei API Google fără incidente. Dezvoltatorii nu erau nesăbuiți în raport cu propriile standarde istorice – aplicau un model mental pe care Google însuși i-a antrenat să-l folosească. Mediul s-a schimbat mai repede decât obiceiurile.

Anatomia unei expuneri accidentale

Înțelegerea modului în care se întâmplă aceste expuneri este primul pas către prevenirea lor. Modurile de eșec sunt remarcabil de consistente între echipe de toate dimensiunile:

• Clasificare greșită a variabilelor de mediu: dezvoltatorii obișnuiau să prefixeze cheile Google Maps cheilor Gemini cu NEXT_PUBLIC_ sau VITE_, expunându-le instantaneu în codul grupat la nivelul clientului.
• Contaminarea istoricului depozitului: o cheie este adăugată la un fișier de configurare, comisă, apoi eliminată, dar istoricul git rămâne căutat pe o perioadă nedeterminată. Atacatorii folosesc instrumente precum truffleHog și gitleaks special pentru a extrage această istorie.
• Scurgeri de notebook-uri și prototipuri: Oamenii de știință de date care prototipează integrările Gemini în notebook-urile Jupyter împing aceste notebook-uri în GitHub cu chei încorporate în ieșirile celulelor.
• Configurare greșită CI/CD: cheile stocate ca secrete de depozit sunt repetate accidental în jurnalele de compilare care sunt vizibile public pe GitHub Actions sau pe platforme similare.
• Extinderea serviciilor de la terțe părți: dezvoltatorii lipesc cheile în tablouri de bord de analiză, instrumente fără cod sau platforme de integrare fără a revizui pozițiile de securitate ale acestor platforme.
• Canale de comunicare în echipă: cheile partajate prin Slack, Discord sau e-mail ajung în istoriile de mesaje care pot fi căutate, care depășesc programul de rotație.

Firul comun nu este neglijența, ci colapsul contextului. Comportamentele care erau sigure într-un context (dezvoltarea Google Maps) sunt periculoase în altul (dezvoltarea Gemini), iar similitudinea vizuală a acreditărilor face distincția ușor de ratat.

Construirea unei culturi de management a secretelor care să se extindă

Situația Gemeni este o funcție de forțare utilă pentru ceva ce multe echipe de dezvoltare au amânat: construirea unei infrastructuri reale de gestionare a secretelor, mai degrabă decât abordări ad-hoc. Pentru echipele mici, acest lucru s-ar putea simți ca o suprainginerire, dar costul expunerii acreditărilor - fraudă de facturare, suspendarea contului, notificări privind încălcarea datelor - depășește cu mult efortul de a face acest lucru corect.

Gestionarea modernă a secretelor urmează o abordare pe niveluri. La nivel de infrastructură, instrumente precum HashiCorp Vault, AWS Secrets Manager sau Google Secret Manager oferă stocare centralizată, auditabilă a acreditărilor, cu capabilități de rotație automată. Acestea nu sunt doar pentru întreprinderile mari, ci servicii precum Doppler și Infisical aduc aceleași modele echipelor de doi sau trei dezvoltatori la prețuri accesibile.

La nivel de cod, disciplina este mai simplă: acreditările nu ating niciodată codul sursă. Punct. Nu în rânduri comentate, nu în fișiere de exemplu, nu în dispozitive de testare cu valori false care se dovedesc a fi reale. Cârligele de pre-commit care rulează instrumente precum detect-secrets sau gitleaks captează încălcările înainte ca acestea să ajungă în depozitele de la distanță. Aceste cârlige durează câteva minute pentru a fi configurate și ani în afara anxietății de răspuns la incident.

Pentru organizațiile care rulează stive operaționale complexe – gestionând totul, de la fluxurile de lucru CRM până la integrări de salarizare până la sisteme de rezervare orientate către clienți – gestionarea centralizată a acreditărilor devine și mai critică. Platforme precum Mewayz, care unifică 207 module de afaceri sub o singură umbrelă operațională, sunt construite cu acest principiu în esență: acreditările și integrările API sunt gestionate la nivel de platformă, nu împrăștiate în module individuale sau medii individuale ale dezvoltatorilor. Când o cheie trebuie rotită, se întâmplă o dată, într-un singur loc, nu în șaptesprezece puncte de integrare diferite.

Vectorul atacului de facturare: un model de amenințare subestimat de dezvoltatori

Discuțiile despre securitate se concentrează adesea pe încălcarea datelor și accesul neautorizat. Problema expunerii Gemeni adaugă un al treilea model de amenințare care merită aceeași atenție: frauda de facturare la scară.

Inferența unui model de limbaj mare este costisitoare. GPT-4 și Gemini Ultra procesează jetoane la fracțiuni de un cent fiecare, dar la scară — mii de solicitări, milioane de jetoane — acele fracții se adună foarte repede la mii de dolari. Atacatorii care descoperă chei API AI expuse nu doresc neapărat datele dvs. Ei vor calcula gratuit. Îți vor folosi acreditările pentru a-și rula propriile servicii de inteligență artificială, pentru a revinde capacitatea de inferență sau pentru a-și testa aplicațiile – totul în timp ce factura revine la tine.

Un dezvoltator a documentat trezirea cu o factură de 23.000 USD de la o cheie Gemini expusă într-un depozit public pentru mai puțin de șase ore. Atacatorul automatizase imediat exploatarea, executând continuu sarcini de generare cu randament ridicat până când detectarea fraudei de către Google a surprins-o. În cele din urmă, dezvoltatorul a obținut taxele inversate după un proces îndelungat de dispută, dar contul a fost suspendat în acea perioadă, renunțând la serviciile de producție.

De aceea alertele de facturare și limitele de cotă nu sunt un substitut pentru gestionarea corectă a secretelor - sunt o ultimă linie de apărare de care sperați că nu aveți nevoie niciodată. Stabilirea unor limite de cheltuieli lunare stricte pentru conturile AI API este miza de masă acum, dar adevărata protecție este să ne asigurăm că acele acreditări nu se scurg niciodată.

Pași practici pentru echipele care fac tranziția

Dacă echipa dvs. a construit integrări Google API sub vechiul model mental și acum adaugă Gemini la stivă, iată o listă de verificare realistă pentru remediere:

1. Auditați imediat depozitele existente. Rulați truffleHog sau gitleaks cu istoricul git complet, nu doar cu HEAD-ul actual. Concentrați-vă în special asupra oricărui depozit care a fost utilizat în trecut cheie API Google.
2. Rotiți toate cheile expuse. Dacă o cheie Gemeni a apărut vreodată într-un comit, presupuneți că este compromisă. Revocați-l și generați unul nou. Nu încercați să evaluați dacă cineva a găsit-o „de fapt”.
3. Implementați scanarea pre-comitare. Instalați cârlige de detectare secretă pe computerul fiecărui dezvoltator și în conductele CI/CD ca o poartă care nu poate fi ocolită.
4. Stabiliți un inventar cheie. Aflați ce servicii au ce acreditări, cine le deține, când au fost schimbate ultima dată și unde sunt utilizate. O foaie de calcul este un bun punct de plecare; un manager de secrete este destinația.
5. Setați alerte de facturare și limite stricte. Pe fiecare cont AI API, configurați alerte la 50% și 80% din cheltuielile lunare estimate și setați limite stricte care ar preveni evenimentele catastrofale de facturare.
6. Documentați noul model mental în mod explicit. Actualizați materialele de încorporare și manualul de inginerie al echipei dvs. pentru a afirma în mod explicit că cheile API Gemini sunt acreditări de mare sensibilitate care necesită același tratament ca secretele procesatorului de plăți.

Lecția mai largă pentru companiile dependente de platformă

Situația Gemeni ilustrează un tipar care afectează orice afacere profund integrată cu platformele terțe: platformele evoluează, iar cerințele privind postura de securitate evoluează odată cu acestea, dar obiceiurile instituționale ale echipelor care folosesc acele platforme nu țin adesea pasul. Ceea ce a fost sigur ieri este periculos astăzi, iar decalajul dintre aceste două state este locul în care au loc încălcări.

Acest lucru este deosebit de grav pentru companiile care rulează stive operaționale complexe. O companie care folosește funcții bazate pe inteligență artificială în serviciile pentru clienți, analiză, generarea de conținut și recomandări de produse ar putea avea integrări Gemini într-o duzină de contexte diferite - fiecare un potențial punct de expunere dacă acreditările sunt gestionate inconsecvent. Soluția nu este doar obiceiurile individuale mai bune pentru dezvoltatori; este arhitectural. Accesul la acreditări trebuie să fie centralizat, auditat și guvernat la nivel de platformă.

Sistemele de operare moderne de afaceri sunt proiectate din ce în ce mai mult având în vedere acest lucru. Când Mewayz integrează capabilități AI în suita sa – de la fluxuri de lucru inteligente CRM până la analize automate în ecosistemul său de 207 module – gestionarea acreditărilor este gestionată la nivelul infrastructurii, nu la nivelul aplicației. Dezvoltatorii de module individuale nu se ocupă de cheile API brute; aceștia accesează capabilități prin straturi de abstractizare care impun politici de rotație, auditează accesul și limitează raza exploziei dacă ceva nu merge bine. Aceasta este arhitectura pe care o cere epoca Gemeni: nu doar obiceiuri mai bune, ci sisteme mai bune care fac din obiceiul potrivit singura opțiune disponibilă.

Google nu a făcut o greșeală creând un model de cheie API permisiv pentru Maps și YouTube. Acest model era potrivit pentru acele servicii. Dar, pe măsură ce capabilitățile și profilurile de cost ale API-urilor evoluează dramatic - și deoarece API-urile AI reprezintă poate cel mai ascuțit punct de inflexiune din această evoluție - întreaga industrie trebuie să-și reseteze valorile implicite. Dezvoltatorii care prosperă în acest mediu nu vor fi cei care au învățat cel mai bine vechile reguli, ci cei care recunosc când regulile s-au schimbat fundamental.

Întrebări frecvente

De ce cheile API Google au fost considerate în mod istoric sigur pentru a fi expuse public?

Google a proiectat multe dintre API-urile sale — Hărți, YouTube, Locații — pentru utilizare de partea clientului, ceea ce înseamnă că cheile au fost încorporate intenționat în codul front-end vizibil pentru oricine. Modelul de securitate s-a bazat mai degrabă pe restricții de utilizare, cum ar fi listele permise de domenii și verificările referințelor, mai degrabă decât secretul cheii. Ani de zile, o cheie expusă a fost considerată o problemă de configurare, nu o vulnerabilitate critică care necesită rotație imediată.

Ce s-a schimbat când Google a introdus cheile Gemini API?

Spre deosebire de vechile API-uri Google, cheile Gemini API funcționează mai degrabă ca secretele tradiționale – expunerea unuia poate duce la debitări neautorizate pentru contul dvs. de facturare, abuz de model sau epuizarea cotelor fără restricții de domeniu încorporate pentru a vă salva. Schimbarea înseamnă că dezvoltatorii trebuie să trateze acum cheile Gemini cu aceeași disciplină ca și acreditările AWS sau cheile secrete Stripe, stocându-le pe partea de server și niciodată în cod orientat către client.

Cum ar trebui dezvoltatorii să gestioneze în mod sigur cheile API pentru serviciile AI astăzi?

Cea mai bună practică este să stocați toate cheile API AI ca variabile de mediu pe server, niciodată în fișiere controlate de versiune sau pachete de clienți. Utilizați un manager de secrete, rotiți cheile în mod regulat și stabiliți limite de cheltuieli la nivel de furnizor. Platforme precum Mewayz – un sistem de operare de afaceri cu 207 module la 19 USD/lună disponibil la app.mewayz.com – gestionează gestionarea acreditărilor API în cadrul infrastructurii lor, astfel încât echipele să nu jongleze manual cu cheile între servicii.

Ce ar trebui să fac dacă am expus deja accidental o cheie API Gemini?

Revocați imediat cheia compromisă prin Google Cloud Console și generați o înlocuire înainte de a face orice altceva. Auditează-ți tabloul de bord de facturare pentru vârfuri neașteptate de utilizare care ar putea indica faptul că cheia a fost recoltată. Apoi examinați baza de cod, variabilele de mediu CI/CD și orice arhive publice pentru alte acreditări scurse. Tratați incidentul ca orice acreditări de plată expuse - presupuneți că a fost găsit și acționați în consecință.