Securitatea este partea din arhitectură pe care majoritatea echipelor o tratează ca treaba altcuiva, până în ziua când nu mai e. Echipa de cloud security scrie politicile, echipa de platformă rulează IAM-ul, data engineer-ii leagă pipeline-uri și presupun că orice permisiune au nevoie va fi acordată la cerere. Rezultatul e un sistem în care nicio persoană nu are un model mental cap-coadă despre cine poate citi ce, iar o mică misconfigurare undeva produce o știre la televizor.
Cadrul pe care această lecție îl ia este că securitatea este arhitectură de portanță, la fel cum consistența, partiționarea și replicarea sunt de portanță. Nu e un strat care se atașează la final; este un set de constrângeri care formează fiecare componentă. O platformă de date construită pe presupuneri greșite despre identitate și permisiuni va petrece ani retrofit-ând controale care ar fi trebuit să fie acolo de la început.
Vestea bună e că principiile sunt puține și tiparele sunt bine înțelese. Munca este în aplicarea lor consistentă, nu în inventarea lor.
Trei principii
Trei principii acoperă majoritatea a ceea ce trebuie să interiorizeze un arhitect funcțional. Se întăresc reciproc, iar un sistem căruia îi lipsește oricare dintre ele are o postură fragilă.
Least privilege. Fiecare actor din sistem, fie că e un utilizator uman, un cont de service sau un rol asumat de un workload, primește exact permisiunile de care are nevoie pentru a-și face treaba și nimic mai mult. Default-ul e nimic; permisiunile se acordă explicit. Sintagma care contează este „default deny”: dacă o permisiune nu a fost acordată explicit, acțiunea e interzisă. Asta sună birocratic până în ziua când un cont de service e compromis și raza de explozie e exact mica mulțime de acțiuni pe care era autorizat să le facă, în loc de întregul cont AWS.
Versiunea practică e că fiecare rol IAM începe gol și crește prin acumulare pe măsură ce echipa identifică ce face efectiv workload-ul. Permisiunile wildcard precum Action: * sunt tentante pentru că elimină o clasă de mici frecări, dar înlocuiesc acele frecări cu un singur risc enorm. Un rol care poate face orice este un rol care, când e furat, poate face orice.
Defense in depth. Presupune că orice strat unic al arhitecturii de securitate poate fi spart. Sistemul rămâne în siguranță pentru că există mai multe straturi între atacator și bijuteriile coroanei. Un firewall de perimetru, plus autentificare pe fiecare cerere internă, plus autorizare pe fiecare operație, plus encryption at rest, plus logging de audit care înregistrează cine a făcut ce. Un atacator care trece de firewall mai trebuie să se autentifice; un atacator care fură o credențială mai trebuie să găsească o cale de a o folosi pe care log-ul de audit n-o va semnala; un atacator care exfiltrează date găsește în continuare datele criptate cu chei la care nu poate ajunge.
Principiul este onest cu privire la limitele umane. Fiecare strat va avea bug-uri. Fiecare strat va fi misconfigurat ocazional. Întrebarea e dacă un singur bug sau o singură misconfigurare e suficientă pentru a compromite sistemul, sau dacă mai multe ar trebui să se alinieze. Defense in depth face al doilea caz mai probabil decât primul.
Zero trust. Modelul clasic de securitate presupunea că cererile care provin din rețeaua corporativă internă sunt de încredere și cererile din afară nu sunt, iar firewall-ul era linia care le separa. Zero trust respinge asta. Locația în rețea nu este o credențială. Fiecare cerere, fie că vine de pe un laptop pe Wi-Fi-ul biroului sau de pe un telefon mobil pe rețeaua unei cafenele, trebuie autentificată și autorizată pe meritele sale proprii. Asta devine deosebit de important odată ce workload-urile sunt răspândite peste regiuni cloud, data center-uri on-prem, SaaS-uri de furnizori și laptop-uri de contractori, toate cu posturi de rețea diferite.
Consecința arhitecturală e mTLS între servicii, proxy-uri identity-aware în fața aplicațiilor interne și politici de acces condiționat care iau în considerare postura dispozitivului, locația și comportamentul, nu doar apartenența la rețea.
Piesele arhitecturale
Principiile au nevoie de implementări. Componentele de mai jos sunt piesele pe care fiecare platformă de date serioasă le are, într-o formă sau alta, iar o platformă căreia îi lipsește oricare dintre ele e expusă într-un mod despre care echipa ar trebui să fie onestă.
Identity and access management. IAM este sistemul de evidență despre cine există și ce poate face. Fiecare cloud are propriul (AWS IAM, Azure Entra ID, GCP IAM); fiecare întreprindere are de obicei un identity provider central deasupra, adesea Okta sau Azure Entra, care emite token-uri folosite în sistemele cloud și SaaS prin SAML sau OIDC. Scopul arhitectural este o singură sursă de adevăr pentru identitate, federată peste tot, cu single sign-on pentru oameni și credențiale cu durată scurtă pentru workload-uri.
Partea cu „credențiale cu durată scurtă pentru workload-uri” merită accent. Cheile de acces cu durată lungă coapte în fișiere de config sunt o sursă perpetuă de breșă. Tiparul modern este ca workload-urile să-și asume roluri în virtutea locului unde rulează: o instanță EC2 își asumă un rol prin instance metadata service; un pod Kubernetes își asumă un rol prin IRSA sau Workload Identity; un runner CI își asumă un rol prin federație OIDC cu furnizorul de control al sursei. Credențiala există doar în interiorul workload-ului, doar pe durata sarcinii sale, și nu apare niciodată în vreo formă persistată.
Segmentare de rețea. Chiar și cu zero trust ca principiu, controalele de rețea sunt un strat suplimentar util. VPC-uri de producție separate de cele de dezvoltare. Subnet-uri segmentate pe nivel, cu security groups care permit doar traficul de care fiecare nivel are nevoie. Network policies Kubernetes care impun default-deny între namespace-uri și reguli explicite de allow între servicii care trebuie să comunice. Scopul nu e să facem rețeaua granița de securitate; e să ne asigurăm că un atacator care ajunge într-o parte a rețelei nu a ajuns automat în orice altă parte.
Managementul secretelor. Secretele sunt credențiale, chei API, chei de semnătură, material de criptare. Nu aparțin în control source, în variabile de mediu coapte în imagini Docker sau în spreadsheet-uri partajate. Aparțin într-un secret store dedicat: AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, sau una dintre opțiunile SaaS precum Doppler sau Infisical. Store-ul oferă versionare, rotație, logging de audit și control de acces granular. Workload-urile trag secretele la pornire, niciodată nu le scriu pe disc, și le rotesc pe un program pe care echipa de securitate îl poate verifica.
Anti-tiparul clasic e parola de producție comisă într-un repository privat. Repo-urile private scurg. Backup-urile repo-urilor private scurg. Fork-urile făcute pentru debug scurg. Orice e într-un git history este, pe un timeline suficient de lung, public.
Log de audit. Fiecare acțiune administrativă și fiecare acces la date sensibile scrie într-un log care e append-only, imutabil și stocat separat de mediul de producție. CloudTrail, GCP Audit Logs, log-urile de activitate Azure Monitor, plus evenimente de audit la nivel de aplicație pentru data plane. Log-ul răspunde la întrebări la care echipa va trebui eventual să răspundă: cine a șters această resursă, când a accesat acest utilizator datele acestui client, ce rol IAM a făcut acest API call. O platformă care nu poate răspunde la acestea nu este în conformitate cu majoritatea cadrelor de reglementare, și este de asemenea incapabilă să-și investigheze propriile incidente.
Partea cu „stocat separat” contează. Un atacator care ajunge în producție n-ar trebui să ajungă și la log-ul de audit, sau va șterge urma în spatele său. Tiparul standard e expedierea log-urilor de audit într-un cont diferit, adesea cu credențiale write-only din producție către contul de log.
Modelul shared-responsibility
Cloud-ul schimbă granița de securitate în feluri pe care echipele uneori le înțeleg greșit. Modelul shared-responsibility e contractul explicit dintre furnizorul cloud și client: furnizorul securizează părțile pe care le controlează el; clientul securizează părțile pe care le controlează el; granița depinde de serviciu.
Pentru infrastructură brută (IaaS, ca EC2): furnizorul securizează data center-ul fizic, hipervizorul, fabrica de rețea. Clientul securizează sistemul de operare, codul aplicației, datele de pe volume, IAM-ul care acordă acces la toate.
Pentru platforme gestionate (PaaS, ca RDS sau BigQuery): furnizorul securizează în plus motorul de bază de date, sistemul de operare de dedesubt, patching-ul și backup-urile motorului. Clientul tot securizează datele din interiorul bazei de date, IAM-ul care acordă acces, controalele de rețea din față, codul aplicației care emite query-uri.
Pentru SaaS (ca Snowflake, GitHub, Datadog): furnizorul securizează cea mai mare parte a stivei. Clientul e responsabil de IAM (cine din organizația lui se poate loga și ca ce), clasificarea datelor (ce încarcă) și controalele de integrare (cum se conectează SaaS-ul la celelalte sisteme ale lor).
Greșeala pe care echipele o fac e să presupună că responsabilitatea furnizorului cloud se extinde mai departe decât o face. Un „encrypted by default” al furnizorului înseamnă de obicei encryption at rest folosind cheia lor, ceea ce protejează împotriva unui disc furat, nu împotriva unui atacator care a furat credențiale IAM și poate cere serviciului să decripteze. Controalele de securitate de rețea ale unui furnizor nu opresc bucket-uri publice misconfigurate. Responsabilitățile clientului există, iar echipa trebuie să știe care se aplică la care serviciu.
Defense in depth, desenat
flowchart LR
A[Attacker]
P[Public surface<br/>WAF, DDoS, rate limiting]
AU[Authentication<br/>SSO, MFA, mTLS]
AZ[Authorization<br/>IAM, RBAC, ABAC]
N[Network controls<br/>VPC, subnets, security groups]
E[Encryption<br/>at rest, in transit]
S[Sensitive resource<br/>customer data]
L[Audit log]
A --> P --> AU --> AZ --> N --> E --> S
P -.events.-> L
AU -.events.-> L
AZ -.events.-> L
N -.events.-> L
E -.events.-> L
S -.events.-> LPunctul vizual e că resursa sensibilă stă în spatele mai multor controale, fiecare independent de celelalte. Un atacator trebuie să le învingă pe rând. Fiecare control scrie într-un log de audit separat pe care un investigator îl poate folosi pentru a reconstrui ce s-a întâmplat. O breșă a oricărui strat unic nu compromite resursa de unul singur.
Tipare arhitecturale de interiorizat
O scurtă listă de tipare care ar trebui să fie default în 2026, nu excepții rezervate pentru cele mai reglementate sisteme.
Encryption at rest și in transit, by default. Fiecare bază de date criptată pe disc. Fiecare conexiune între servicii folosind TLS. Fiecare backup criptat în bucket. Costul e aproximativ zero în serviciile cloud moderne și beneficiul, în ziua când un disc e furat sau un network tap e instalat, e enorm.
Mutual TLS între servicii. Fiecare serviciu autentifică fiecare alt serviciu cu un certificat de client, nu doar o cheie API. Service mesh-urile (Istio, Linkerd, Consul) oferă mTLS automat. Mesh-ul îndepărtează tentația de a sări peste muncă pentru că era greu de configurat manual.
Credențiale cu durată scurtă, niciodată coapte. Fără chei de acces în variabile de mediu coapte în imagini. Workload-urile își asumă roluri la runtime; token-urile expiră în minute până la ore. Rotația se întâmplă automat, nu ca un proiect trimestrial.
Log-ul de audit copiat de rezervă separat. Producția nu poate ajunge la arhiva de log. Arhiva de log nu poate fi modificată, doar adăugată. Retenția se potrivește cu cea mai lungă cerință de reglementare la care e supusă afacerea.
Greșeli arhitecturale comune
Imaginea în oglindă a tiparelor. Fiecare dintre acestea a produs o breșă publică în ultimii ani; niciuna nu e rară; toate sunt prevenibile.
IAM cu wildcard. Un rol cu Action: * pe Resource: * pentru că cineva trebuia să livreze și setul mai mic de permisiuni era greu de calculat. Rolul e furat și atacatorul are întregul cont. Prevenire: tooling care deduce permisiunile necesare din utilizarea reală, plus porți de review pe politicile largi.
Bucket-uri S3 publice. Un bucket marcat citibil public pentru că era cea mai ușoară cale de a partaja un fișier cu un contractor. Bucket-ul conține de asemenea, trei ani mai târziu, o copie a unui backup pe care nimeni nu și-l mai amintea. Prevenire: setări block-public-access la nivel de cont și tooling care scanează după bucket-uri care le ocolesc.
Credențiale default. O parolă de admin pentru bază de date setată ca ceva memorabil când a fost provizionat clusterul și niciodată rotită. Un panou de admin accesibil pe internetul public cu admin / admin. Prevenire: automatizare de provizionare care generează parole aleatoare stocate în secret manager, și default-uri lizibile uman făcute imposibile prin configurație.
Secrete în git. Chei API în fișiere .env comise accidental. Chei private SSH check-in-uite pentru „comoditate”. Prevenire: pre-commit hooks care scanează după tipare de secrete, scanare de repository de către furnizorul de control al sursei și proceduri de rotație pentru orice secret care a apărut vreodată într-un commit.
Tiparul în toate cele patru greșeli e același: o mică scurtătură luată sub presiunea unui deadline, într-un context unde consecința era abstractă. Apărarea arhitecturală e să faci scurtăturile mai greu de luat decât calea corectă.
Cum arată ce e bine
O echipă cu o postură de securitate sănătoasă are IAM ca sistem de evidență pentru identitate, federat printr-un provider central, cu workload-uri folosind credențiale cu durată scurtă și oameni folosind SSO cu MFA. Segmentare de rețea între medii, cu reguli default-deny și liste explicite de allow. Un secret manager cu rotație impusă. Un log de audit expediat într-un cont separat, copiat de rezervă și interogat regulat. Encryption pornită by default pentru fiecare data store și fiecare conexiune. Un threat model documentat pe care echipa îl revizitează când arhitectura se schimbă.
Asta nu e treaba unei singure echipe de securitate. E o proprietate a platformei, menținută de proprietarii platformei ca parte din rularea ei. Discuția despre infrastructure-as-code din lecția 53 se conectează direct: fiecare politică IAM, fiecare regulă de rețea, fiecare configurație de secret-store aparține în cod, revizuită și ținută în version control. Configurația de securitate care trăiește doar în consola cloud e configurație de securitate care driftează.
Lecția următoare e despre cadrele de reglementare care transformă multe dintre aceste tipare din „bună practică” în obligație legală: GDPR, CCPA, legile de privacy care au implicații arhitecturale pe care majoritatea echipelor le subestimează până la primul email de la regulator.
Citări și lecturi suplimentare
- NIST SP 800-207, “Zero Trust Architecture”,
https://csrc.nist.gov/publications/detail/sp/800-207/final(consultat 2026-05-01). Documentul de referință pentru zero trust ca model arhitectural formal. - NIST Cybersecurity Framework 2.0,
https://www.nist.gov/cyberframework(consultat 2026-05-01). Cadrul la nivel înalt care leagă identitatea, protecția, detecția, răspunsul și recuperarea. - CIS Controls v8,
https://www.cisecurity.org/controls/v8(consultat 2026-05-01). Lista practică, prioritizată de controale pe care fiecare organizație ar trebui să le implementeze, aproximativ în ordinea în care ar trebui să le implementeze. - AWS, “Best practices for IAM”,
https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html(consultat 2026-05-01). Sfatul AWS canonic despre IAM, inclusiv avertismentul despre permisiunile wildcard și tiparele de credențiale pentru workload-uri referențiate mai sus. - OWASP Top 10,
https://owasp.org/www-project-top-ten/(consultat 2026-05-01). Oglinda la nivel de aplicație a preocupărilor de la nivel de platformă acoperite aici.