Securitatea în cloud: cum se împart responsabilitățile între furnizor și companie

Ai activat autentificarea multifactor?

Responsabilitățile legate de securitatea digitală nu se distribuie automat între client și prestator, ci variază semnificativ în funcție de natura serviciului achiziționat și de clauzele specifice din contract. În timp ce furnizorul se concentrează asupra apărării infrastructurii fizice și a tehnologiei care susține platforma, o parte substanțială din sarcinile de protecție rămâne în seama organizației tale.

Este crucial să înțelegi exact unde se oprește jurisdicția operatorului și unde începe cea a firmei tale, deoarece acest lucru diferă în funcție de modelul de cloud adoptat.

În mod standard, prestatorul asigură protecția fizică a centrelor de date, a echipamentelor hardware și a întregii infrastructuri care permite funcționarea serviciului. Totuși, responsabilitatea pentru sistemele de operare, aplicațiile instalate și setările de configurare depinde direct de tipul de soluție aleasă.

Dacă optezi pentru închirierea de servere virtuale, ceea ce cunoscut sub denumirea de Infrastructură ca Serviciu (IaaS), furnizorul gestionează hardware-ul fizic și tehnologiile de virtualizare. În absența unui pachet suplimentar de administrare, echipa ta preia controlul asupra sistemului de operare, a aplicațiilor, a procesului de actualizare și a definiției regulilor de acces.

Alegerea unei platforme de dezvoltare, cunoscută drept Platformă ca Serviciu (PaaS), schimbă ecuația. În acest scenariu, prestatorul preia și administrarea anumitor componente software. Dezvoltatorii interni continuă să fie răspunzători pentru codul sursă propriu, pentru modulele integrate în aplicație și pentru configurațiile pe care le pot modifica.

Când discuția virează asupra unei aplicații gata de utilizare, accesibilă prin abonament, precum un sistem CRM, ne aflăm în domeniul Software-ului ca Serviciu (SaaS). Aici, furnizorul se ocupă de întreținerea aplicației și a infrastructurii subiacente. Rolul tău se reduce la stabilirea politicii de acces, definirea permisiilor pentru utilizatori și reglarea modului în care datele sunt partajate. Indiferent de modelul ales, este imperativ să verifici alocarea responsabilităților pentru fiecare serviciu contractat individual, garantând astfel că nicio aspectă critică nu este neglijată.

Menținerea controlului asupra accesului la date reprezintă o provocare majoră pentru orice companie.

Un prestator nu are vizibilitate automată asupra schimbărilor interne din echipa ta, cum ar fi mutarea unui angajat pe alt post sau încheierea colaborării cu o agenție externalizată care administra site-ul web.

De aceea, organizarea ta trebuie să implementeze un flux de lucru clar pentru acordarea, modificarea și revocarea accesului în timp util.

Fiecare individ din echipă ar trebui să dețină un cont unic, dotat cu permisiunile strict necesare pentru activitatea sa.

Utilizarea unui cont de administrator partajat de întreaga echipă complică considerabil procesul de audit, făcând dificilă identificarea persoanei care a efectuat o anumită modificare și încetinind procesul de retragere a accesului pentru un singur membru.

Activarea autentificării multifactor este o măsură esențială, cerând o verificare suplimentară în afară de parola standard, mai ales pentru conturile cu privilegii extinse. Este la fel de important să examini permisiunile aplicațiilor terțe care sunt interconectate. O integrare veche, lăsată activă după finalizarea unui proiect, poate păstra accesul la informații sensibile pe care nu le mai necesită.

Același principiu de prudență se aplică și documentelor. Un folder partajat cu publicul rămâne expus pericolelor, chiar dacă infrastructura furnizorului este robustă și protejată corespunzător. Trebuie verificate separat conturile tehnice și cheile API prin care aplicațiile comunică între ele: ce date sunt accesate, cine le gestionează și cum sunt revocate aceste credențiale când o integrare este retrasă.

Pentru administratorii externi, se impune stabilirea unui acces limitat în timp și înregistrarea tuturor intervențiilor în jurnale de audit. Aceste registre trebuie să permită identificarea clară a persoanei care a intervenit și a naturii modificărilor efectuate.

Gestionarea actualizărilor și a configurației rețelei aduce o altă complexitate.

Multe vulnerabilități exploatează zona de graniță, acolo unde termină atribuțiile furnizorului și încep cele ale companiei tale. Dacă nu clarifici din start cine administrează ce componentă, riscul rămâne neacoperit.

Consideră, de exemplu, o aplicație de facturare care rulează pe un server virtual.

Prestatorul va actualiza infrastructura de virtualizare, dar sistemul de operare de pe serverul tău va rămâne neactualizat dacă nu este inclus în pachetul de servicii. În această situație, sarcina revine echipei interne sau unui partener desemnat. Pentru fiecare componentă, trebuie stabilit cine urmărește vulnerabilitățile, cine aplică patch-urile și cum se verifică funcționarea după intervenție.

Trebuie luat în calcul și termenul de remediere, deoarece o vulnerabilitate critică, exploatată activ, impune un ritm diferit față de o actualizare de rutină. În paralel, se impune controlul conexiunilor permise către aplicații și baze de date. Un serviciu de firewall administrat permite delegarea gestionării regulilor de trafic și a monitorizării asociate, în limitele pachetului ales.

Cine testează, cine verifică și cum se repară erorile?

Echipa ta trebuie să specifice ce conexiuni sunt necesare și cine aprobă schimbările. De pildă, dacă un dezvoltator solicită acces temporar pentru mentenanță, trebuie definit și momentul închiderii acestui acces.

O excepție făcută pentru câteva ore riscă să rămână activă luni întregi dacă nu este monitorizată.

Separarea verificării backup-ului de disponibilitatea serviciului este un aspect des ignorat. Faptul că aplicația rămâne online când se defectează un echipament nu garantează că poți recupera orice fișier șters.

Redundanța ajută serviciul să continue funcționarea, însă ștergerea accidentală sau o modificare greșită se pot propaga și în copiile folosite pentru disponibilitate.

De aceea, este recomandat să verifici separat ce backup ai, ce date include și cât timp sunt păstrate copiile. Unele abonamente includ opțiuni de recuperare limitate, iar altele necesită un serviciu suplimentar.

Solicită și un test de restaurare. Confirmarea că un backup a fost creat nu este suficientă pentru a demonstra că aplicația va porni cu toate informațiile și configurările necesare.

Stabilește clar cine face testul, cine verifică rezultatul și cum sunt corectate problemele identificate.

Definește și obiectivele de recuperare: RPO (Recovery Point Objective) indică intervalul de date pe care accepți să îl pierzi, iar RTO (Recovery Time Objective) reprezintă timpul în care serviciul trebuie restabilit.

Un backup zilnic nu acoperă un RPO de o oră, indiferent de viteza de restaurare.

Verifică și dacă un cont de administrator compromis ar permite ștergerea copiilor. Accesul separat și copiile protejate împotriva modificării sau ștergerii pe durata de păstrare reduc acest risc.

În ceea ce privește delegarea sarcinilor prin servicii administrate, pentru o echipă mică, administrarea zilnică a infrastructurii poate deveni o povară suplimentară. Prin serviciile de găzduire administrată, anumite task-uri de mentenanță, monitorizare și securitate sunt preluate de specialiști, conform contractului.

Când apelezi la astfel de servicii, este esențial să discuți concret despre activitățile preluate de furnizor. Monitorizarea unui server poate însemna doar verificarea funcționării, fără a include investigarea tuturor incidentelor din aplicația instalată. Similar, suportul disponibil non-stop nu garantează rezolvarea imediată a oricărei probleme.

Înainte de a alege pachetul, cere precizări clare:

- Componentele administrate și cele care rămân în responsabilitatea echipei tale - Actualizările incluse și condițiile în care sunt aplicate - Evenimentele monitorizate și persoanele care primesc alertele

- Intervențiile făcute automat și cele ce necesită aprobarea ta - Timpii de În acordul de nivel al serviciului (SLA), verifică separat timpul de Confirmarea preluării unei sesizări nu echivalează cu rezolvarea incidentului.

Pentru alertele de securitate, stabilește cine le investighează, cine poate izola un sistem compromis și ce intervenții necesită aprobarea ta.

Dacă fiecare acțiune așteaptă confirmarea unei persoane indisponibile, monitorizarea permanentă lasă un gol în capacitatea de intervenție.

Alocă și un responsabil intern pentru relația cu furnizorul. Acesta trebuie să cunoască aplicațiile critice pentru firmă și să poată decide, de exemplu, dacă o intervenție urgentă justifică întreruperea temporară a unui serviciu.

Securitatea în cloud devine din ce în ce mai esențială pe măsură ce firma angajează noi oameni, conectează aplicații noi și adaugă servicii. Revizuiește responsabilitățile după toate aceste schimbări și verifică dacă fiecare sarcină are un responsabil și un termen. Astfel, echipa ta și furnizorul vor ști exact ce au de făcut înainte ca un cont menținut activ, o actualizare amânată sau un backup incomplet să afecteze negativ activitatea curentă.