# Cine are cheile proiectului? Identități și secrete pentru aplicații și agenți

> Identități pentru aplicații și agenți, secrete protejate și acces temporar: pași practici pentru infrastructura unui proiect digital.

Sursă: https://i8.ro/blog/cine-are-cheile-proiectului-identitati-si-secrete-pentru-aplicatii-si-agenti

**Seria II: De la infrastructură la proiecte agentice în producție. Episodul 04 din 20.**

În [episodul precedent](https://i8.ro/blog/routere-virtuale-si-retele-separate-cum-limitam-impactul-unui-incident), am separat rețelele portalului B2B fictiv pentru solicitări și documente. O regulă de firewall poate permite API-ului să ajungă la baza de date, dar nu dovedește că procesul care cere acces este chiar API-ul autorizat. Decizia principală a acestui episod este să oferim fiecărui om, serviciu și proces automat o identitate distinctă, apoi să preferăm credențiale temporare în locul cheilor comune și permanente, acolo unde integrarea permite.

## Identitatea nu este secretul

O **identitate de workload** reprezintă un program care rulează, precum API-ul, un job de livrare sau un agent. Workload înseamnă aici o unitate de execuție, nu un utilizator uman. **Autentificarea** verifică identitatea, iar **autorizarea** decide ce poate face acea identitate. Faptul că un serviciu s-a autentificat corect nu îi conferă automat acces la toate datele.

Un **secret** este o valoare care trebuie păstrată confidențială, de exemplu o parolă, o cheie API ori o cheie privată. Un **token temporar** este o credențială cu valabilitate limitată. Expirarea reduce timpul în care o copie furată poate fi folosită, dar nu împiedică abuzul în intervalul valid și nu repară o autorizare prea largă.

Prin urmare, nu numim toate aceste elemente „chei”. Mai întâi identificăm actorul, apoi metoda prin care își dovedește identitatea, resursa permisă și durata accesului.

## Patru actori diferiți în portal

**Scenariu ipotetic:** portalul are un API, un proces care prelucrează documente, un flux CI/CD care livrează versiuni și un agent AI integrat care propune clasificarea unei solicitări. Echipa folosește separat agenți AI de dezvoltare pentru cod și teste.

Operatorii umani intră prin conturi nominale, ideal cu autentificare multifactor și fără cont administrativ comun. API-ul și procesul de documente primesc identități de serviciu diferite, deoarece au sarcini diferite. Jobul CI/CD folosește o identitate valabilă pentru rularea și mediul aprobate. Agentul integrat apelează funcții controlate ale aplicației, nu baza de date cu parola API-ului. Agentul de dezvoltare lucrează în mediul de test și în repository, fără o rută implicită către producție.

Această separare completează [regulile generale despre permisiuni, aprobări și audit](https://i8.ro/blog/permisiuni-aprobari-si-audit-regulile-unui-agent-ai-de-incredere). Aici ne interesează implementarea identității în infrastructură și ciclul de viață al credențialelor.

## Unde păstrăm secretele care rămân necesare

Unele sisteme nu acceptă identități federate sau credențiale dinamice. Pentru ele, un manager de secrete poate stoca valorile criptat, controla cine le citește și înregistra accesul. Alegerea produsului vine după inventar, nu înainte. Un fișier `.env` poate fi convenabil local, însă nu devine seif doar fiindcă este exclus din Git. Poate ajunge într-un backup, într-o imagine de container, într-un director partajat sau pe ecranul unui instrument.

Secretele nu intră în cod, prompturi, exemple, tichete sau loguri. Dacă un agent de dezvoltare are nevoie să ruleze teste, îi oferim date sintetice și credențiale pentru mediul de test, injectate numai la execuție. Nu îi cerem modelului să „țină minte” o cheie. Dacă agentul integrat trebuie să folosească un furnizor extern, procesul său citește secretul printr-un mecanism controlat; secretul nu este inclus în instrucțiunile trimise modelului.

Cercetarea academică asupra repository-urilor publice a arătat că scurgerile de chei și secrete nu sunt un caz marginal. Scanarea automată poate detecta o parte dintre erori, dar nu transformă publicarea accidentală într-un eveniment sigur. O cheie ajunsă în istoric se consideră compromisă: o revocăm sau o rotim la furnizor, investigăm utilizarea și abia apoi curățăm copiile unde este posibil.

## Când ajută OIDC și SPIFFE

**OpenID Connect**, prescurtat OIDC, permite unei părți de încredere să verifice afirmații despre o identitate. În GitHub Actions, de exemplu, un job poate primi un token OIDC, iar un furnizor cloud îl poate schimba cu o credențială de acces de scurtă durată. Astfel, cheia cloud permanentă nu mai trebuie copiată în repository. Politica de încredere trebuie totuși restrânsă după repository, mediu, ramură și audiență, conform capacităților furnizorului. Un token emis oricărui job nu este o îmbunătățire dacă rolul cloud rămâne excesiv.

**SPIFFE** este un set de standarde pentru identitatea workload-urilor în medii dinamice și eterogene. Un serviciu poate primi un document de identitate verificabil, numit SVID, folosit pentru autentificare între servicii. SPIFFE nu este un înlocuitor automat pentru OIDC și nici pentru toate parolele. În plus, documentația sa presupune că workload-urile sunt suficient de bine izolate încât unul să nu fure credențialele altuia; mecanismul acelei izolări rămâne în afara standardului. Segmentarea din episodul anterior continuă să conteze.

Pentru un IMM, regula realistă este să adoptăm întâi mecanismul nativ al platformei deja folosite. OIDC poate elimina cheia permanentă din livrarea cloud. O identitate de workload oferită de orchestrator poate separa API-ul de procesul de documente. SPIFFE merită evaluat când proiectul traversează platforme și are suficientă complexitate operațională. Introducerea unei infrastructuri de identitate mai sofisticate decât sistemul administrat poate muta riscul, nu îl poate elimina.

## Registrul care face accesul verificabil

Înainte de configurare, completăm un registru simplu. Valorile din tabel sunt propuneri pentru scenariul fictiv, nu o configurație certificată.

| Identitate | Resursă și scop | Credențială | Durată / revocare | Proprietar |
| --- | --- | --- | --- | --- |
| API producție | Baza de date, operații ale aplicației | Identitate de serviciu sau secret dedicat | Temporară ori rotație planificată | Responsabil aplicație |
| Job de livrare | Mediul de producție, doar deploy | OIDC și token cloud temporar | O rulare; revocarea relației de încredere | DevOps |
| Agent integrat | API de clasificare și serviciu model | Identitate separată și secret controlat | Sesiune sau rotație documentată | Responsabil produs |
| Agent de dezvoltare | Repository și mediu de test | Cont tehnic limitat | Pe sarcină; revocare la încheiere | Lider tehnic |

Pentru fiecare rând verificăm cine aprobă accesul, unde apare în loguri, ce dependență îl emite și cum îl anulăm. Testăm atât operația permisă, cât și una care trebuie refuzată. Rotația se probează înainte de incident: serviciul trebuie să preia noua credențială fără ca valoarea veche să rămână activă necontrolat. Păstrăm separat procedura de recuperare pentru indisponibilitatea managerului de secrete, protejată și accesibilă numai persoanelor desemnate.

Rezultatul este un registru al identităților și secretelor, cu proprietar, scop, durată și procedură de revocare. El arată unde mai există credențiale permanente și oferă o ordine de reducere a lor. 

În episodul următor vom transpune o parte dintre aceste reguli în infrastructură ca cod, pentru ca mediile să poată fi reconstruite și verificate.

## Surse

- [SPIFFE, *Overview* și *Concepts*](https://spiffe.io/docs/latest/spiffe-about/overview/), documentație oficială despre identitatea workload-urilor și SVID, consultată la 6 octombrie 2026.
- [GitHub Docs, *OpenID Connect*](https://docs.github.com/en/actions/concepts/security/openid-connect), despre schimbul identității unui job cu un token cloud temporar.
- [OWASP Cheat Sheet Series, *Secrets Management*](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html), despre stocare, durată, rotație, logare și răspuns la incidente.
- [Meli, McNiece și Reaves, *How Bad Can It Git?*, NDSS 2019](https://www.ndss-symposium.org/ndss-paper/how-bad-can-it-git-characterizing-secret-leakage-in-public-github-repositories/), studiu academic despre scurgerea secretelor în repository-uri publice.

## Următorul pas

Vrei să reduci accesul permanent și cheile răspândite prin proiecte? [Discută cu i8 despre un registru de identități și un plan de migrare](https://i8.ro/contact).