Modelul de responsabilitate partajată

Modelul de responsabilitate partajată este fundamentul oricărei discuții despre securitatea în cloud, definind clar cine este responsabil pentru protejarea infrastructurii și a datelor. În practică, confuzia între responsabilitățile furnizorului de cloud (CSP) și ale clientului este cea mai frecventă cauză a breșelor de securitate, deoarece mulți cred că providerul asigură securitatea totală. Înțelegerea acestui model îți permite să configurezi corect permisiunile, criptarea și accesul, evitând riscurile inutile. Pentru un Cloud Security Engineer, aceasta nu este doar teorie, ci ghidul tău zilnic pentru audituri și remedieri.

Concepte cheie

• Securitatea a cloud-ului: Responsabilitatea exclusivă a furnizorului (AWS, Azure, GCP) de a proteja infrastructura fizică, rețeaua globală și hardware-ul.
• Securitatea în cloud: Responsabilitatea ta de a configura corect serviciile, de a gestiona accesul utilizatorilor și de a proteja datele tale.
• IaaS (Infrastructure as a Service): Furnizorul gestionează hardware-ul și virtualizarea; tu ești responsabil pentru sistemul de operare, patch-uri, firewall-uri și date.
• PaaS (Platform as a Service): Furnizorul gestionează OS-ul și runtime-ul; tu controlezi aplicațiile, datele și configurările de securitate ale platformei.
• SaaS (Software as a Service): Furnizorul gestionează aproape totul; tu ești responsabil doar pentru gestionarea identității utilizatorilor și a accesului la datele din aplicație.
• Criptarea datelor: Deși providerul oferă instrumente, tu ești adesea responsabil pentru generarea și gestionarea cheilor de criptare (KMS).
• Gestiunea identității și accesului (IAM): Este întotdeauna responsabilitatea clientului să definească cine poate accesa ce resurse și cu ce privilegii.

Exemplu practic

Să presupunem că folosești Amazon S3 pentru a stoca fișiere sensibile. Conform modelului, AWS asigură că serverele fizice sunt sigure și că discul dur nu se strică. Tu, însă, trebuie să te asiguri că bucket-ul S3 nu este public.

Dacă nu setezi explicit politica de acces, un developer poate lăsa accidental PublicRead. În acest caz, datele tale sunt expuse, iar vina aparține ție, nu lui AWS.

// Politică greșită - Acces public (Vina ta)
{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::bucket-sensibil/*"
}

// Politică corectă - Doar entități autorizate (Responsabilitatea ta)
{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::bucket-sensibil", "arn:aws:s3:::bucket-sensibil/*"],
  "Condition": {
    "Bool": { "aws:SecureTransport": "false" }
  }
}

Greșeli frecvente

1. Presupunerea că providerul criptează automat toate datele: Multe servicii au criptarea oprită implicit sau folosesc chei gestionate de provider, ceea ce poate fi un risc conform anumitor standarde de compliance.
2. Ignorarea responsabilității pentru patch-uri în IaaS: Într-un EC2, dacă nu instalezi actualizările de securitate pentru Linux/Windows, serverul va fi compromis, iar tu vei fi vinovat.
3. Confundarea securității rețelei: Providerul protejează data center-ul, dar tu trebuie să configurezi corect Security Groups și Network ACLs pentru a bloca traficul neautorizat.
4. Lipsa monitorizării: Crezi că ești sigur pentru că nu ai avut incidente recent, dar fără logging activ (ex: CloudTrail), nu vezi când cineva încearcă să acceseze resursele ilegal.

Întrebări de interviu

Întrebare: Cine este responsabil pentru securitatea sistemului de operare într-un serviciu EC2? Răspuns: Clientul. Furnizorul oferă imaginea de bază, dar tu ești responsabil pentru patch-uri, hardening și configurarea firewall-ului la nivel de OS.

Întrebare: Cum se aplică modelul la un serviciu SaaS precum Office 365? Răspuns: Furnizorul asigură disponibilitatea și securitatea aplicației. Tu ești responsabil pentru gestionarea conturilor utilizatorilor, a autentificării cu doi factori (MFA) și a politicilor de partajare a datelor.

Întrebare: Ce se întâmplă dacă un bucket S3 este public din greșeală? Răspuns: Este o breșă de securitate cauzată de configurarea incorectă a clientului. Providerul nu șterge datele expuse automat; tu trebuie să detectezi și să corectezi politica IAM/S3 Bucket Policy.

Exercițiu

Deschide consola unui provider major (AWS/Azure/GCP) și identifică un serviciu de stocare (ex: S3, Blob Storage). Verifică setările actuale de acces public. Dacă există un bucket public, modifică politica pentru a restricționa accesul doar la IP-uri specifice sau să necesite autentificare. Documentează pașii făcuți și justifică de ce fiecare pas reduce riscul conform modelului de responsabilitate partajată. Timp estimat: 45 minute.