Granturile OAuth se acumulează mult mai repede decât le poate revizui orice echipă de securitate, pentru că fiecare click pe „Allow" creează o relație de încredere permanentă între două aplicații. Un singur token compromis, uitat luni de zile, poate deschide calea către datele corporative, fără să treacă prin SSO sau MFA. Problema nu e dacă angajații conectează aplicații, ci câte rămân invizibile.

De ce OAuth nu se comportă ca restul accesului

Prima confuzie, și cea mai costisitoare, este să crezi că un grant OAuth moștenește automat controalele construite în jurul identității utilizatorului. Nu o face. SSO guvernează modul în care un om își dovedește identitatea. MFA adaugă frecare la acel proces. Un grant OAuth nu este nici una, nici alta. Este un protocol separat, cu propriul ciclu de viață, care nu se supune regulilor pe care le-ai impus în jurul conturilor.

Mai rău, granturile supraviețuiesc credențialelor celor care le-au creat. Dezactivezi un utilizator în Google Workspace sau Microsoft 365 și suspendă doar granturile care au plecat din acea platformă. Cele emise de aplicații terțe continuă să funcționeze nestingherite. Rămân valide luni întregi, fără să producă vreo intrare în log, dar perfect exploatabile în momentul în care cineva decide să le folosească.

Atacatorii știu asta. Într-un incident recent, cauza rădăcină a fost un token OAuth compromis de la un tool AI terț, pe care un angajat îl conectase la contul enterprise de Google Workspace cu luni înainte. Un singur punct de consimțământ a fost suficient pentru a intra. Cifrele explică de ce se repetă: în medie 88 de granturi OAuth per angajat, dintre care 31 au permisiuni la nivel de date. La o companie de 1.000 de oameni, asta înseamnă 88.000 de căi de acces, dintre care 31.000 au linie directă către date sensibile.

Matematica revizuirii manuale nu iese

Un audit temeinic al unui singur grant arată cam așa: tragi profilul aplicației, verifici dacă echipa de securitate a evaluat-o deja, dacă vendorul are un program real de securitate și conformitate, dacă a anunțat un incident în ultimele 12 luni. Te uiți la rolul celui care a acordat grantul, ca să vezi dacă s-au delegat drepturi de admin. Compari scope-urile cerute cu ce e tipic pentru acel tip de integrare și cu politica ta de partajare a datelor. Contactezi persoana care a creat grantul ca să înțelegi nevoia de business și verifici statusul MFA.

Un verdict pe un singur grant poate lua 45 de minute. Patruzeci și cinci de minute sunt rezonabile pentru un grant. Sunt imposibile pentru zeci de mii. Nicio cantitate de expertiză nu face munca manuală mai rapidă și nicio echipă de securitate nu are oamenii necesari ca să țină pasul. Aici apare tentația de a pune un agent AI să trieze totul. Și aici trebuie să fim precisi: un agent bun poate scurta dramatic timpul de triaj, dar verdictul final, cel care decide dacă tai accesul cuiva la date, rămâne o decizie umană cu responsabilitate.

Inventarul e primul pas, nu ultimul

Nu poți evalua un grant pe care nu știi că există. Descoperirea completă a granturilor și a integrărilor app-to-app din ecosistemul SaaS, inclusiv a celor create mult înainte de a instala vreun tool de guvernanță, este condiția de bază. O observație importantă: descoperirea nu ar trebui să depindă doar de logurile de activitate, altfel granturile dormante și cele doar de identitate, gen „Sign in with Google", rămân invizibile exact pentru că nu produc trafic.

Pe lângă granturile clasice, inventarul trebuie să acopere chei API, conturi de serviciu și conexiuni la servere MCP, care alimentează tool-urile și agenții AI. Pentru fiecare grant, întrebările sunt simple: ce aplicație și ce vendor primesc acces, cine a creat grantul, ce permisiuni exacte s-au acordat, la ce aplicații și date corporative ajunge grantul.

Un punct de verificare pe care mulți îl ratează: dacă nu vezi un grant într-un tool, asta nu dovedește că nu există. Înseamnă doar că instrumentul folosit nu l-a descoperit. O verificare incompletă nu e o dovadă de absență. Recomandarea fermă este să confirmi acoperirea prin mai multe surse (browser, inbox, identity provider, aplicații conectate) înainte să tragi concluzia că un ecosistem e curat.

Ce semnale de risc contează cu adevărat

O listă de granturi e utilă doar dacă știi pe care să te îngrijorezi. Semnalele care merită urmărite: permisiuni excesive sau overprivileged, domenii suspecte, aplicații folosite frecvent de atacatori pentru exfiltrare, conexiuni cu acces larg și persistent la date sensibile precum email, fișiere și depozite de cod, plus servere MCP care acționează ca intermediari între tool-urile AI și datele corporative. Semnalele pozitive, aplicații populare și publisheri verificați, ajută la separarea rutinei de excepție.

Un detaliu subtil, dar decisiv: cine a creat grantul contează la fel de mult ca ce poate face grantul. Un angajat nou, în prima săptămână, care acordă un grant de dezvoltator cu risc ridicat, este o combinație pe care un scor simplu o ratează. Contextul de rol și vechime schimbă verdictul.

Ce înseamnă pentru tine

Dacă ești antreprenor sau marketer în România și coordonezi un stack de 15-30 de tool-uri SaaS, ai deja sute de granturi OAuth active fără să știi. Fiecare integrări între CRM, newsletter, analytics, helpdesk și unelte AI creează o punte de date. Nu ai nevoie de un departament de securitate ca să începi. Ai nevoie de un inventar, o listă scurtă de întrebări și o regulă clară.

Recomandarea practică, separat de orice afirmație din sursă: o dată pe trimestru, extrage toate aplicațiile conectate la Google Workspace sau Microsoft 365 și pune trei întrebări pentru fiecare. Mai folosim aplicația? Cine are acces la ea? Ce date poate citi sau scrie? Ce nu trece testul, se revocă. Când un angajat pleacă, revizuirea granturilor create de el trebuie să fie parte din offboarding, nu un gând de după.

Nu afirma că ai pierdut bani sau că ai fost atacat doar pentru că un tool ți-a semnalat un grant suspect. Un semnal de risc este un motiv de verificare, nu o dovadă de breșă. Verifică, documentează, apoi acționează.

FAQ

Un grant OAuth vechi, inactiv, mai e periculos? Da. Un grant dormant poate rămâne valid luni de zile fără să producă vreo intrare în log, dar poate fi folosit oricând. Inactivitatea nu înseamnă lipsa accesului.

Dezactivarea utilizatorului rezolvă problema? Nu complet. Suspendarea unui cont într-o platformă oprește doar granturile originare din acea platformă. Cele emise de aplicații terțe pot continua să funcționeze.

Are nevoie firma mea mică de așa ceva? Dacă folosești SaaS și integrări, ai deja granturi. Nu ai nevoie de un proces enterprise, ai nevoie de un inventar și de o rutină de revizuire. Începe mic, dar începe.

Concluzia ALLSoft: AI-ul triază, omul decide, agenția execută

Instrumentele AI sunt excelente la triaj: citesc sute de granturi, compară scope-uri, semnalează anomalii și îți economisesc ore întregi de muncă manuală. Dar decizia de a revoca accesul cuiva la date, de a judeca dacă riscul depășește valoarea de business, rămâne umană. Niciun agent nu-și asumă consecința unei integrări rupte. Un media buyer sau un operator senior știe contextul, știe ce tool-uri contează pentru venit și ce poate fi tăiat fără să strice campaniile.

Pasul concret îl face echipa: definim ce date sunt critice, construim rutina de revizuire și integrăm verificarea OAuth în fluxul lunar de operare. Dacă vrei să pui ordine în stack-ul tău de tool-uri și să nu mai lași accesul la date pe pilot automat, discută cu noi la ALLSoft Agency și stabilim împreună pașii.

Dacă lucrezi pe zona de conținut și SEO, vezi și ce schimbă programul Google UGC pentru date proaspete, iar dacă administrezi un site WordPress, update-ul Jetpack 16.3 merită verificat înainte de a lăsa integrări noi active.