Două incidente din 21 octombrie au vizat cheile API ale firmelor. Ce faci acum (inventar, rotire fără întreruperi) și ce schimbi ca o scurgere să nu mai coste.
Pe 21 octombrie 2026 s-au petrecut două incidente care au aceeași lecție. Railway, o platformă de găzduire folosită de mulți dezvoltatori, a anunțat că un atacator ar fi putut accesa variabilele de mediu ale clienților, iar pentru unele chiar conținutul decriptat. În aceeași zi, versiunea 1.107.0 a LiteLLM, o bibliotecă populară pentru conectarea aplicațiilor la modele AI, a fost publicată compromisă, cu un program care fura credențiale. În ambele cazuri, ținta erau cheile: cheile API ale serviciilor AI, ale plăților, ale bazelor de date și ale cloud-ului.
Articolul e pentru managerii de firme care folosesc servicii AI, Stripe sau cloud, și pentru echipa tehnică de lângă ei. Nu trebuie să știi să programezi ca să pui întrebările potrivite.
Ce e o cheie API, pe înțeles
O cheie API e o parolă lungă pe care o aplicație o folosește ca să vorbească cu alt serviciu, de exemplu cu un model AI, cu procesatorul de plăți sau cu baza de date. Spre deosebire de parola unui om, nu cere confirmare pe telefon și nu obosește. Cine are cheia poate face, în numele firmei tale, tot ce îi permite ea: să trimită cereri plătite, să citească date sau să emită rambursări.
Din acest motiv, o cheie scursă nu e o problemă de mâine. Serviciile AI se facturează după consum, iar o cheie furată poate fi folosită automat, fără pauză, până când cineva o revocă sau până la limita de cheltuieli. Railway a spus explicit că atacul face parte dintr-o serie care vizează platformele de găzduire ca să ajungă la furnizorii de inferență AI, adică la cheile lor.
Ce s-a întâmplat la Railway și la LiteLLM
Railway a detectat activitatea anormală în dimineața zilei de 21 octombrie, în sistemele care stochează variabilele de mediu. Recomandarea către toți clienții a fost să schimbe imediat toate variabilele de mediu, inclusiv cheile API, să schimbe credențialele registrelor private de imagini și să verifice jurnalele serviciilor respective. Railway a cerut și furnizorilor de AI să revoce preventiv cheile expuse și a oprit toate deploy-urile pe durata investigației.
LiteLLM 1.107.0 a fost disponibil pe PyPI, depozitul de pachete Python, timp de aproximativ două ore, după analiza Datadog. Au fost afectate și imaginile Docker oficiale, inclusiv eticheta latest. Programul malițios pornea la orice lansare de Python din mediul respectiv, chiar dacă LiteLLM nu era folosit, și căuta credențiale cloud, chei SSH, tokenuri de dezvoltare, chei ale furnizorilor AI și parole salvate în browser. Ștergerea pachetului nu ajungea: fișierele adăugate rămâneau pe disc.
Ce faci acum
1. Fă inventarul cheilor
Nu poți proteja ce nu știi că ai. Cere echipei sau furnizorului tău o listă simplă: ce chei există, la ce serviciu, în ce aplicație și pe ce server sunt folosite, cine le-a creat și când. Locurile obișnuite sunt variabilele de mediu de pe platformele de găzduire, fișierele de configurare, sistemele de CI/CD și, din păcate, uneori codul sau mesajele de chat.
2. Rotește cheile expuse, fără întreruperi
Dacă aplicația ta rula pe Railway sau a instalat LiteLLM 1.107.0, presupune că cheile la care avea acces sunt compromise. Rotirea se face în trei pași, ca să nu oprești serviciul:
- creezi o cheie nouă la furnizor;
- pui cheia nouă în aplicație și faci deploy;
- revoci cheia veche doar după ce ai confirmat că aplicația merge cu cea nouă.
OpenAI recomandă exact această ordine în ghidul său de bune practici: înlocuitorul întâi, revocarea la final. Pentru LiteLLM, Datadog recomandă ca rotirea să se facă de pe o mașină curată, nu de pe cea posibil infectată.
3. Verifică jurnalele și facturile
Uită-te în consolele furnizorilor la consumul din ultimele zile: cereri la ore neobișnuite, modele pe care nu le folosești, creșteri bruște. Verifică și jurnalele bazelor de date și ale cloud-ului pentru accesări de unde nu te aștepți. Dacă găsești ceva, păstrează dovezile înainte să ștergi orice.
Ce schimbi pe termen lung
Un manager de secrete în locul variabilelor răspândite
Cheile stau mai bine într-un singur loc controlat, un manager de secrete, decât copiate prin zeci de fișiere și platforme. Ghidul OWASP pentru gestionarea secretelor recomandă centralizarea, accesul restrâns, jurnalizarea fiecărei citiri și rotirea regulată. Avantajul practic: când trebuie schimbată o cheie, știi unde e și cine o folosește.
O cheie pentru fiecare aplicație și fiecare mediu
O singură cheie folosită peste tot înseamnă că o scurgere oriunde le compromite pe toate. Separă cheile pe medii (test, producție) și pe aplicații. OpenAI sugerează proiecte separate pentru test și producție, cu limite proprii. Când o cheie se scurge, știi exact ce afectează și o revoci fără să oprești restul.
Limite de cheltuieli și alerte la furnizori
Furnizorii mari de AI permit limite de cost. În consola Anthropic poți seta o limită lunară proprie, sub plafonul contului, iar la atingerea ei cererile se opresc. OpenAI permite alerte de cheltuieli și limite ferme care opresc traficul la pragul ales. Setează-le pe fiecare proiect: o limită care oprește un serviciu e enervantă, o factură neplafonată după o scurgere e mult mai rea.
Privilegii minime
O cheie trebuie să poată face doar ce are nevoie aplicația. O cheie de citire nu trebuie să poată scrie, iar o cheie pentru plăți nu trebuie să poată face rambursări dacă aplicația nu le face. La Stripe, la furnizorii de cloud și la multe servicii AI se pot crea chei restricționate.
Versiuni fixate și pachete verificate
Cazul LiteLLM arată de ce „ultima versiune” nu e o strategie pentru producție. Aplicațiile care instalau automat ultima versiune sau foloseau eticheta latest a imaginii Docker au primit codul compromis fără ca cineva să decidă asta. Ce ajută:
- versiuni fixate în fișierele de dependențe și în imaginile de container;
- actualizări făcute intenționat, după o scurtă perioadă de așteptare și verificare;
- unelte care scanează pachetele la build și semnalează versiunile retrase sau suspecte;
- servere de build care nu au acces la cheile de producție.
Pe scurt
- Fă lista cheilor: unde sunt, ce deschid, cine le folosește.
- Dacă ai fost pe Railway sau ai instalat LiteLLM 1.107.0, rotește tot: cheie nouă, deploy, apoi revocarea celei vechi.
- Verifică consumul și jurnalele din ultimele zile.
- Mută cheile într-un manager de secrete, câte una pe aplicație și pe mediu.
- Pune limite de cheltuieli și alerte la fiecare furnizor.
- Fixează versiunile dependențelor și nu folosi latest în producție.
La ME Digital lucrăm zilnic cu integrări AI și cu chei de API: le punem într-un singur loc, le separăm pe aplicații și pe medii, setăm limitele de cost și configurăm integrările astfel încât datele să nu fie folosite la antrenare. Dacă vrei să facem împreună inventarul și rotirea, vezi implementarea AI și securitate și actualizări sau scrie-ne.
