--- title: "Cum securizați API-urile cu date sensibile sau reglementate" description: "Controale practice pentru API-uri cu date bancare, energetice sau de utilități: model de amenințări, autorizare, privilegiu minim, minimizare, secrete, audit." canonical: https://sdk.enterprises/ro/insights/securing-regulated-data-apis language: ro --- # Cum securizați API-urile cu date sensibile sau reglementate Actualizat: 2026-09-25 > Securizați un API cu date reglementate modelând cine l-ar putea folosi abuziv, verificând autorizarea pentru fiecare obiect și fiecare câmp, colectând și returnând cât mai puține date și ținând secretele și jurnalele de audit sub control strict. Slăbiciunile care contează cel mai mult în practică sunt lacunele de autorizare și răspunsurile care expun prea multe date, nu criptarea compromisă. ## Începeți cu un model al amenințărilor pentru date, nu pentru framework Înainte de a alege instrumentele, scrieți ce expune API-ul și cine l-ar putea folosi abuziv. Pentru o bancă, asta înseamnă datele conturilor și ale tranzacțiilor; pentru o companie din energie sau utilități, poate însemna date de contorizare, contractele clienților și citiri operaționale din rețea. Un model al amenințărilor util este scurt. Enumeră datele sensibile, fiecare apelant care poate ajunge la ele, acțiunile pe care ar trebui să le poată face fiecare apelant și ce se întâmplă dacă unul dintre ei este compromis. Acest document ghidează apoi fiecare control de mai jos și le spune recenzenților ce să testeze. - Ce date sunt personale, confidențiale sau reglementate și unde sunt stocate. - Fiecare consumator al API-ului: servicii interne, parteneri, aplicații mobile și administratori. - Ce are voie fiecare consumator să citească, să modifice sau să declanșeze. - Impactul unui token scurs, al unei persoane rău intenționate din interior sau al unui sistem compromis al unui partener. ## Autentificați fiecare apelant, apoi autorizați fiecare obiect Folosiți un protocol standard precum OAuth 2.0 cu OpenID Connect pentru utilizatori și tokenuri de scurtă durată sau TLS mutual pentru apelurile între servicii. Evitați cheile API partajate de lungă durată, pentru că nimeni nu poate spune ce sistem le-a folosit și nu pot fi revocate fără a-i bloca pe ceilalți. Autentificarea dovedește doar cine apelează. Primul punct din OWASP API Security Top 10 este autorizarea defectuoasă la nivel de obiect (broken object level authorization): un utilizator valid schimbă un identificator în cerere și citește înregistrarea altcuiva. Verificați pe server proprietatea sau apartenența la client (tenant) pentru fiecare obiect, fiecare funcție și fiecare câmp sensibil și nu aveți niciodată încredere într-un identificator sau un rol trimis de client. ## Dați fiecărui client și serviciu privilegiul minim de care are nevoie Privilegiul minim limitează pagubele atunci când ceva merge prost. Emiteți credențiale separate pentru fiecare consumator, limitați tokenurile la operațiuni precise și țineți endpointurile administrative pe o cale separată, cu verificări mai stricte. Aplicați aceeași regulă sub API. Contul de serviciu care citește datele contoarelor nu ar trebui să le poată șterge, iar un job de raportare ar trebui să se conecteze cu un rol de bază de date doar pentru citire. Revizuiți permisiunile periodic, pentru că accesul acordat pentru o sarcină punctuală tinde să rămână pentru totdeauna. ## Colectați mai puțin, returnați mai puțin și păstrați mai puțin timp Minimizarea datelor este atât un principiu RGPD, cât și un control de securitate puternic: datele pe care nu le stocați niciodată nu se pot scurge. Întrebați-vă pentru fiecare câmp dacă serviciul are cu adevărat nevoie de el și eliminați sau pseudonimizați ce nu îi trebuie. Aplicați aceeași disciplină răspunsurilor. Definiți scheme de răspuns explicite în loc să serializați obiecte întregi din baza de date, mascați identificatorii precum numerele de cont acolo unde valoarea completă nu este necesară și stabiliți perioade de păstrare, astfel încât înregistrările vechi să fie șterse. Documentați temeiul legal pentru fiecare scop al prelucrării și semnați acorduri de prelucrare cu fiecare furnizor care manipulează datele. Aceasta este practică de inginerie, nu consultanță juridică, așa că implicați responsabilul cu protecția datelor sau consilierul juridic pentru evaluarea juridică. ## Validați fiecare intrare și limitați cât poate consuma un apelant Tratați fiecare cerere ca ostilă până la validare. Impuneți o schemă pentru fiecare endpoint, respingeți câmpurile necunoscute și folosiți interogări parametrizate, pentru ca intrarea să nu devină niciodată parte dintr-o comandă de bază de date. Mai multe riscuri API din lista OWASP provin din limite lipsă, nu din cod prost. Limitați rata de cereri pentru fiecare client, plafonați dimensiunea paginilor și a payloadurilor și protejați fluxurile de business sensibile, precum plățile sau modificările de contract, împotriva abuzului automatizat. Dacă API-ul preia URL-uri la distanță în numele apelanților, restricționați destinațiile pentru a preveni falsificarea cererilor pe partea de server (server-side request forgery). ## Țineți secretele în afara codului, a imaginilor și a jurnalelor Parolele bazelor de date, cheile de semnare și credențialele partenerilor își au locul într-un manager de secrete dedicat, injectate la rulare și rotite periodic. Scanați depozitele de cod și imaginile de container după secrete în pipeline-ul de build și considerați compromis orice secret care ajunge în sistemul de versionare. Separați secretele pe medii, pentru ca o credențială de test scursă să nu deschidă niciodată producția. Restricționați cine poate citi secretele în producție și jurnalizați fiecare acces la ele. ## Jurnalizați pentru audit și proiectați pentru mai puține incidente Mediile reglementate trebuie să poată răspunde ulterior la o întrebare simplă: cine a accesat ce date, când și prin ce client. Înregistrați asta pentru fiecare citire și scriere sensibilă, stocați jurnalele acolo unde operatorii aplicației nu le pot modifica și țineți datele personale în afara mesajelor din jurnale. Asociați jurnalizarea cu alerte la tipare neobișnuite, precum un client care citește mult mai multe înregistrări decât de obicei, și cu un plan de răspuns la incidente testat. Prin Sopra Steria, inginerii noștri au construit API-uri securizate pentru date sensibile de utilități, în condiții de reglementare stricte, și au condus un instrument de supraveghere operațională în care standardele de securitate impuse au mers mână în mână cu mai puține incidente în producție. SDK Enterprises aplică astăzi aceleași practici în proiectele clienților. ## De reținut - Un model al amenințărilor scurt și scris pentru date ar trebui să ghideze fiecare control de securitate al API-ului. - Verificați autorizarea pe server pentru fiecare obiect, funcție și câmp sensibil, nu doar la autentificare. - Privilegiul minim se aplică deopotrivă tokenurilor, conturilor de serviciu și rolurilor din baza de date. - Minimizarea datelor reduce atât expunerea RGPD, cât și impactul oricărei breșe. - Jurnalele de audit trebuie să arate cine a accesat ce și când, fără să scurgă ele însele date personale. ## Întrebări frecvente ### Este HTTPS suficient pentru a securiza un API? Nu. TLS protejează datele în tranzit, dar multe breșe ale API-urilor implică apelanți autentificați care ajung la date pe care nu ar trebui să le vadă. Verificările de autorizare, validarea intrărilor, limitele de rată și jurnalizarea pentru audit rămân necesare. ### Ce este broken object level authorization? Este o vulnerabilitate în care API-ul verifică dacă apelantul este autentificat, dar nu și dacă înregistrarea cerută îi aparține. Schimbarea unui identificator în URL sau în corpul cererii expune atunci datele altor utilizatori. Soluția este o verificare a proprietății sau a apartenenței la client (tenant), pe server, pentru fiecare obiect. ### Impune RGPD controale de securitate precise pentru API-uri? RGPD cere măsuri tehnice și organizatorice adecvate riscului, fără a impune instrumente anume. Controale precum restricționarea accesului, minimizarea, pseudonimizarea și jurnalizarea sunt modalități uzuale de a îndeplini această cerință, iar consilierii dumneavoastră juridici ar trebui să confirme ce se aplică în cazul dumneavoastră. ## Servicii conexe - [Securitatea aplicațiilor](https://sdk.enterprises/ro/services/secure-systems)