Blog
Amenințări și incidente20 septembrie 20269 min de citit

Contul rămas deschis după plecare: 170 de depozite copiate și, separat, o amendă de 700.000 de dolari

CrowdSec a lăsat deschis contul GitHub al unui angajat plecat. În aceeași săptămână, un regulator a amendat exact această lipsă de procedură.

În aceeași săptămână din septembrie 2026 au apărut două documente fără nicio legătură între ele, care spun exact același lucru. Unul este raportul unei companii de securitate despre propria breșă. Celălalt este acordul de sancționare al unui regulator american. Ambele se învârt în jurul unei singure omisiuni: cineva a plecat din organizație, dar accesul lui nu a fost retras.

Cazul unu: o companie de securitate, 170 de depozite private

CrowdSec, companie franceză de securitate, a publicat pe 17 septembrie o primă declarație și pe 18 septembrie un raport detaliat care corecta afirmații anterioare. Pe scurt: un atacator a copiat aproximativ 170 dintre depozitele private de cod ale companiei, pe 22 mai 2026, folosind contul de GitHub al unui angajat care plecase deja.

Motivul pentru care contul era încă activ nu este neglijență pură, ci exact scuza rezonabilă pe care o auzi în orice organizație: i s-a păstrat accesul ca să termine o lucrare rămasă în coadă. Este o decizie de manager, luată cu bună-credință, într-o discuție de două minute.

Credențialele fostului angajat fuseseră compromise în atacul asupra lanțului de aprovizionare al pachetelor TanStack din mai 2026. Pe 11 mai, într-un interval de câteva minute, au fost publicate pe npm 84 de versiuni malițioase pentru 42 de pachete din familia TanStack, incident urmărit ca CVE-2026-45321. Codul rulat la instalare fura tokenuri GitHub și npm, credențiale de cloud și chei SSH de pe mașina respectivă. Pachetele afectate au fost retrase din registru în aceeași seară.

O precizare utilă pentru echipele de dezvoltare: potrivit analizei publicate de TanStack, a fost afectat doar monorepoul Router/Start. Familia Query — deci și pachetul folosit pe scară largă pentru gestionarea stării de server — este listată explicit ca neafectată, alături de DB, Store, Table, Form și altele. Dacă ați instalat totuși o versiune afectată pe 11 mai 2026, recomandarea producătorului este rotirea credențialelor accesibile de pe acea mașină.

Cronologia care doare

  • 11 mai 2026 — apar pachetele malițioase; laptopul fostului angajat este compromis.
  • 22 mai 2026 — la unsprezece zile distanță, aproximativ 170 de depozite private sunt copiate.
  • 16–17 septembrie 2026 — CrowdSec rotește credențialele expuse.
  • 17–18 septembrie 2026 — compania publică declarația și apoi raportul detaliat.

Între copierea depozitelor și comunicarea publică au trecut aproape patru luni. Nu ca reproș — investigațiile durează — ci ca element de calibrare pentru propriile așteptări: dacă vi se întâmplă, nu veți afla luni.

Ce a fost expus, potrivit companiei: consola web, scripturi și modele de analiză de date, scripturi de automatizare și algoritmul de consens care decide ce adrese IP ajung pe listele de blocare. Separat, arhiva conținea adresele de email a 83 de utilizatori și numele, adresele și contextul de investiție a 51 de potențiali investitori din 2020. CrowdSec afirmă că infrastructura și bazele de date nu au fost accesate, că nu s-a modificat cod și că nu au fost expuse date de client, nume de utilizator sau parole. Sunt afirmațiile companiei, nu constatări independente.

Compania a mai comunicat o schimbare care spune mult: până acum nu impunea software de protecție pe laptopurile dezvoltatorilor. Acum îl rulează pe stațiile celor care lucrează cu codul și sistemele sale.

Cazul doi: un regulator care amendează exact această lipsă

Pe 17 septembrie 2026, Oficiul pentru Drepturi Civile din cadrul Departamentului american al Sănătății a anunțat un acord cu Ambry Genetics, companie de testare genetică. Punctul de plecare: în ianuarie 2020, contul de email al unui angajat a fost compromis printr-un atac de phishing, iar datele medicale a 225.370 de persoane au fost potențial exfiltrate. Compania a plătit 700.000 de dolari și a acceptat un plan de măsuri corective monitorizat timp de doi ani.

Partea relevantă nu este suma, ci ce anume a constatat regulatorul. Printre posibilele încălcări enumerate în comunicat se află trei lucruri:

  • lipsa unei analize de risc corecte și complete asupra datelor medicale electronice deținute;
  • lipsa unor proceduri de retragere a accesului la aceste date atunci când încetează raportul de muncă sau când accesul nu mai este justificat;
  • lipsa atribuirii unui nume sau număr unic pentru identificarea și urmărirea identității utilizatorilor în sistemele care conțin astfel de date.
A doua constatare este, cuvânt cu cuvânt, problema din cazul CrowdSec. A treia explică de ce prima nu se poate rezolva: într-o organizație cu conturi partajate, nu ai cum să retragi accesul unei persoane, pentru că nu există „accesul unei persoane”. Există o parolă pe care o știe toată lumea.

Directoarea oficiului, Paula M. Stannard, rezumă astfel: „Phishingul prin email este un atac cibernetic obișnuit care poate duce la o breșă și poate dezvălui deficiențe de securitate.” Reține verbul: dezvăluie. Atacul nu creează problema, o scoate la suprafață.

Încă un detaliu de calibrare: incidentul a fost raportat în martie 2020, iar acordul a fost anunțat în septembrie 2026. Șase ani. Consecința unui singur cont de email compromis nu se încheie când se închide tichetul de incident.

Ce nu susțin sursele

  • Cele două cazuri nu au nicio legătură între ele. Sunt organizații, țări și sectoare diferite; singura legătură este tema.
  • HIPAA este legislație americană. Nu se aplică în România și nu este echivalentă cu GDPR sau NIS2. Este citată aici pentru constatările regulatorului, nu ca obligație locală.
  • Nu se știe public ce pachet malițios anume a ajuns pe laptopul fostului angajat CrowdSec, nici momentul exact al compromiterii.
  • Afirmațiile despre lipsa accesului la infrastructură aparțin CrowdSec și nu au fost confirmate independent public.

Procedura de offboarding care chiar funcționează

Majoritatea organizațiilor au un proces de plecare. Puține au unul care rezistă la excepții, iar excepția este întotdeauna aceeași: „mai are puțin de terminat".

  • Retragerea accesului se face la data plecării, nu când cineva își amintește. Dacă mai are de finalizat o lucrare, aceea devine contract de colaborare cu acces limitat, pe termen fix și cu dată de expirare tehnică — nu prelungirea tăcută a contului vechi.
  • Lista de sisteme nu se construiește din memorie. Include tot ce nu trece prin directorul central: GitHub, npm, registre de pachete, furnizorul de cloud, uneltele SaaS plătite cu cardul echipei, VPN-ul, stațiile de lucru, telefonul.
  • Tokenurile și cheile nu dispar odată cu contul. Tokenurile personale de acces, cheile SSH, cheile de API și sesiunile active se revocă explicit, pentru că supraviețuiesc dezactivării unui cont.
  • Fără conturi partajate. Dacă trei oameni folosesc același cont, plecarea unuia nu poate fi tratată. Este exact constatarea a treia a regulatorului.
  • Cine confirmă că s-a făcut? Offboardingul se încheie cu o dovadă — o listă bifată, cu nume și dată — nu cu un email de la HR.
  • Reverificare periodică: o dată pe trimestru, cineva compară lista de conturi active din fiecare sistem important cu lista de angajați. Diferența este întotdeauna instructivă.

Exercițiul: 45 de minute

  • Injectul 1 — un dezvoltator pleacă vineri, dar cere acces încă două săptămâni ca să predea o migrare. Cine aprobă, pe ce formă și cu ce dată de expirare tehnică?
  • Injectul 2 — la trei luni după plecare, apare o autentificare cu contul lui. Cine observă, în cât timp și de unde ar veni semnalul?
  • Injectul 3 — se constată că prin acel cont s-au copiat depozite private. Ce faceți în primele două ore și ce anume nu atingeți, ca să păstrați dovezile?
  • Injectul 4 — trebuie să decideți dacă și cui comunicați. Ce spuneți când încă nu știți amploarea și ce nu afirmați niciodată înainte de verificare?

Ce măsori

  • Timpul median dintre ultima zi de lucru și retragerea efectivă a accesului, pe fiecare sistem important.
  • Numărul de conturi active aparținând unor persoane care nu mai sunt în organizație — ideal zero, măsurat trimestrial.
  • Numărul de conturi partajate rămase și un termen pentru eliminarea fiecăruia.
  • Numărul de tokenuri și chei revocate la plecare, comparat cu numărul de conturi dezactivate. Dacă al doilea e mai mare, aveți o problemă.
  • Existența unei dovezi scrise de finalizare a offboardingului, cu responsabil și dată.
  • Timpul până la detectarea unei autentificări cu un cont care ar fi trebuit să fie închis.

Lecția comună a celor două documente nu este că oamenii rău-intenționați fură conturi. Este că accesul supraviețuiește relației de muncă, tăcut, pentru că nimeni nu are sarcina explicită de a-l încheia. O companie de securitate a descoperit asta pe propriul cod, iar un regulator a pus un preț pe ea. Ambele în aceeași săptămână, fără să știe una de cealaltă.

#offboarding#retragerea accesului#GitHub#lanț de aprovizionare#conturi partajate#HIPAA#guvernanță#awareness#tabletop