Securitate în cloud: ce responsabilități rămân la tine

„Suntem în cloud, deci suntem securizați" este una dintre cele mai costisitoare presupuneri din IT-ul modern. Furnizorii mari de cloud (AWS, Azure, Google Cloud) investesc masiv în securitatea infrastructurii lor fizice — dar asta acoperă doar o parte din ecuație.

Modelul de responsabilitate partajată

Furnizorul de cloud răspunde de securitatea „cloud-ului" — centrele de date, hardware-ul, rețeaua fizică. Compania rămâne responsabilă de securitatea „în cloud" — cum sunt configurate serviciile, cine are acces la ce date, cum sunt criptate informațiile, și dacă aplicațiile construite pe acea infrastructură au vulnerabilități proprii.

Unde apar cele mai multe breșe reale

Aproape niciodată prin compromiterea infrastructurii furnizorului — ci prin configurări greșite făcute de client: un bucket de stocare lăsat public din greșeală, permisiuni de acces prea largi acordate „temporar" și niciodată revocate, sau chei de API expuse accidental în cod public.

Întrebări pe care merită să ți le pui

Cine din companie are acces administrativ la conturile cloud, și e activ MFA pentru toate? Sunt datele sensibile criptate atât în tranzit, cât și în repaus? Există vizibilitate reală asupra cine accesează ce date, sau accesul e acordat o dată și niciodată revizuit?

Cloud, hibrid sau on-premise — decizia corectă

Pentru multe companii, răspunsul nu e „totul în cloud" sau „totul on-premise", ci o arhitectură hibridă: date sensibile sau reglementate păstrate pe infrastructură controlată direct, în timp ce servicii mai puțin critice folosesc cloud public pentru flexibilitate și cost redus. Aceeași logică se aplică și în alegerea între un LLM găzduit privat și un API cloud pentru sisteme AI.

O evaluare a configurării actuale în cloud face parte firească dintr-un audit de securitate cibernetică complet — deseori acolo se găsesc cele mai simple și mai urgente corecții de făcut.