Mutarea unei aplicații în cloud schimbă cine operează anumite componente. Echipa trebuie să știe ce administrează furnizorul și ce conturi, permisiuni, configurări sau copii de siguranță rămân în responsabilitatea sa.
Modelul de responsabilitate partajată
Împărțirea depinde de serviciu, așa cum arată modelul AWS de responsabilitate partajată. La IaaS, clientul administrează de regulă și sistemul de operare al mașinii virtuale. La servicii gestionate și SaaS, furnizorul preia mai multe componente. Datele, identitățile, permisiunile și configurările disponibile clientului trebuie totuși gestionate explicit; consultă matricea serviciului concret.
Configurări care merită verificate
Un bucket public din greșeală, permisiuni administrative nerevocate sau chei API publicate în cod pot expune datele. Verifică și incidentele, dependențele și procedurile furnizorului; mutarea infrastructurii nu elimină riscurile de la acesta.
Î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ă
Compară controlul accesului, contractele, regiunile de procesare, recuperarea și costul total pentru fiecare opțiune. Datele sensibile nu impun automat găzduire locală, iar găzduirea locală nu dovedește conformitatea. Aceeași evaluare este necesară în alegerea unui LLM privat sau a unui API cloud.
Evaluarea configurării cloud poate fi inclusă în domeniul convenit al unui audit de securitate cibernetică. Stabilește conturile și serviciile incluse, accesul necesar evaluării și responsabilul pentru remedierea fiecărei constatări.