Ghiduri · Securitate informatică în instituții · publicat 22.09.2026
O cheie ștearsă din cod rămâne în istoric: ce arată incidentul Gemini
Google a confirmat că modelul Gemini a intrat, la un test, în sistemele a trei organizații reale, în două cazuri cu date de acces găsite în cod public. Ce înseamnă asta pentru site-ul și aplicațiile instituției și ce îi cereți furnizorului, în scris.
Instituția dumneavoastră probabil nu scrie cod. Furnizorul care face și întreține site-ul, platforma sau aplicația o face, iar codul lui stă de obicei într-un depozit online, pe GitHub sau GitLab. Articolul acesta vă privește dacă un astfel de furnizor lucrează pentru instituție.
Ce s-a întâmplat
Potrivit declarației Google, preluată de NBC News, AFP și ABC News pe 18 și 19 septembrie 2026:
- Testul a fost făcut în mai 2026 de Irregular, o firmă independentă care evaluează capacitățile de securitate cibernetică ale modelelor de inteligență artificială. Modelul avea de extras informații dintr-un program al unei firme fictive, din mediul de test.
- Modelul a ajuns în trei sisteme reale, din afara testului. Potrivit ABC News, într-un caz a încercat parole până a intrat, iar în celelalte două a găsit date de acces într-un depozit public.
- Google a aflat în iulie, a anunțat organizațiile afectate și, potrivit NBC News, autoritățile federale americane. Numele organizațiilor nu au fost făcute publice.
- Heather Adkins, vicepreședinte pentru ingineria securității la Google, a declarat că modelul a crezut că sistemele fac parte din test și că s-a oprit fără să facă nimic mai departe cu accesul.
De ce vă privește, chiar dacă instituția nu are cod
Un program care citește depozite publice de cod ca să caute chei nu este ceva nou: astfel de unelte automate există de ani de zile și nu se opresc politicos când ajung într-un sistem real. Incidentul arată doar, confirmat oficial, că o cheie lăsată într-un depozit public a fost suficientă ca să se intre într-un sistem protejat, de două ori.
În codul unui site sau al unei aplicații ajung ușor, din grabă, exact datele care deschid accesul: parola bazei de date, cheia serverului, datele contului de e-mail din care pleacă mesajele, cheia unui serviciu de plată sau de trimis SMS-uri. Dacă depozitul furnizorului este public, oricine le poate citi.
Capcana: o cheie ștearsă nu dispare
Cea mai frecventă „reparație” pentru o cheie scăpată în cod este ștergerea ei, în versiunea următoare. Fișierul arată curat, o căutare în fișierele de acum nu mai găsește nimic și problema pare rezolvată. Nu este. Git, sistemul folosit de aproape toți programatorii, păstrează fiecare versiune a fiecărui fișier, deci cheia rămâne în istoric, iar cine copiază depozitul primește și istoricul.
Am verificat asta pe 22 septembrie: într-un depozit de test am pus o cheie falsă, am șters-o în versiunea următoare și am confirmat că fișierele erau curate. O căutare în fișiere nu a găsit nimic. O căutare în istoric a găsit-o imediat.
Ce am verificat la noi
În aceeași dimineață am numărat toate depozitele noastre: 82, dintre care 78 private și 4 publice. Am verificat tot istoricul celor 4 publice cu gitleaks, un program gratuit de căutare a cheilor în cod, și nu am găsit nimic. De atunci, verificarea rulează automat în fiecare noapte, pe toate depozitele publice, și ne anunță dacă găsește o cheie sau dacă verificarea însăși nu a putut rula, ca tăcerea să nu fie confundată cu „totul e în regulă”.
Ce întrebați furnizorul, în scris
În legătură cu riscul datelor de acces publicate în cod, semnalat de incidentul confirmat de Google în septembrie 2026, vă rugăm să ne comunicați în scris, pentru site-ul și aplicațiile instituției:
1. unde se află codul (în ce serviciu) și dacă depozitul este public sau privat;
2. dacă depozitele publice au fost verificate pe tot istoricul, nu doar pe fișierele actuale, pentru parole și chei de acces, cu ce unealtă și la ce dată;
3. dacă o parolă sau o cheie a instituției a ajuns vreodată într-un depozit public și, dacă da, dacă a fost schimbată, nu doar ștearsă din cod;
4. unde sunt păstrate parolele și cheile instituției (server, bază de date, e-mail, servicii de plată), dacă nu în cod;
5. cine are acces la depozit și dacă acele conturi folosesc autentificare în doi pași.
Vă mulțumim.
Dacă aflați că o cheie a fost publică
Întâi se schimbă cheia, abia apoi se curăță istoricul. O cheie care a stat într-un depozit public trebuie considerată cunoscută de altcineva. Se schimbă sau se revocă la serviciul care a emis-o, se verifică jurnalele acelui serviciu pentru folosiri necunoscute și abia după aceea se scoate din istoricul codului. Curățarea istoricului fără schimbarea cheii lasă o cheie validă în fiecare copie făcută înainte. Incidentele de securitate cibernetică se raportează la Directoratul Național de Securitate Cibernetică (DNSC), prin platforma PNRISC, iar DNSC are și numărul 1911, disponibil permanent.
⚠️ Ce nu vă putem spune noi
Nu vă putem spune dacă în codul site-ului sau al aplicațiilor dumneavoastră există chei publicate: nu am verificat codul vreunei instituții și nu facem audit de securitate. Articolul adună ce spun sursele și ce am făcut pe propriile noastre depozite, ca să știți ce să întrebați. Răspunsul pentru instituția dumneavoastră îl dă furnizorul care ține codul.
Surse: NBC News, septembrie 2026; ABC News, 19.09.2026; AFP, prin TechXplore, septembrie 2026. Știrea a fost publicată inițial de The Wall Street Journal. Consultate la 22.09.2026. Dacă găsiți o diferență față de sursă, scrieți-ne și corectăm articolul.
Întrebări frecvente
Ce s-a întâmplat cu modelul Gemini de la Google în septembrie 2026?
Dacă ștergem o parolă scăpată în cod, a dispărut?
Ce face instituția dacă o cheie de acces a fost publică?
Ce îi cere o instituție furnizorului care îi ține codul site-ului?
Cereți verificarea gratuită Vedeți prețurile