AL+

RO EN

Scrieți-ne

Backup pentru datele firmei în cloud: redundanța nu ține loc de copie

În mai 2024, Google Cloud a șters cloudul privat al UniSuper, cu tot cu replici. Păstrați o copie testată a datelor acolo unde furnizorul principal nu ajunge.

. De . Arhitectură și infrastructură

Read this article in English

Redundanța în mai multe zone și regiuni vă protejează când cade un centru de date. Nu vă protejează când furnizorul șterge ce rulați la el și nici de propriile greșeli. Pentru aceste cazuri, orice firmă are nevoie de cel puțin o copie a datelor care poate fi restaurată, ținută într-un cont la care furnizorul principal nu are acces, și de o restaurare pe care a încercat-o efectiv. Incidentul UniSuper din mai 2024 rămâne cel mai clar exemplu al diferenței.

Ce s-a întâmplat

UniSuper este un fond de pensii din Australia. La începutul lui mai 2024, peste o jumătate de milion de membri ai fondului au rămas mai mult de o săptămână fără acces la conturi (The Guardian, 9 mai 2024). Pe 8 mai, directorul general al UniSuper și directorul general al Google Cloud, Thomas Kurian, au publicat o declarație comună: o configurare greșită, făcută din neatenție la crearea serviciilor de cloud privat, a dus în cele din urmă la ștergerea abonamentului Private Cloud al UniSuper.

Partea care îi privește pe toți ceilalți vine imediat după. UniSuper avea datele duplicate în două zone geografice, tocmai ca protecție împotriva întreruperilor și a pierderilor, dar ștergerea abonamentului le-a șters în ambele. Fondul a scăpat pentru că avea backupuri la un alt furnizor, care, potrivit declarației, au redus pierderea de date și au ajutat mult la restaurare. The Register a rezumat situația în aceeași zi: fără backupurile de la celălalt furnizor, lucrurile ar fi putut fi mult mai grave.

Două săptămâni mai târziu, Google și-a publicat propria analiză (pagina Google indică 24 mai 2024; prefața UniSuper datează informațiile suplimentare la 25 mai). La începutul lui 2023, operatorii Google au creat unul dintre cloudurile private Google Cloud VMware Engine ale UniSuper cu un instrument intern și au lăsat necompletat un parametru. Sistemul l-a completat cu o valoare implicită pe care nu o cunoștea nimeni: o durată fixă de un an, urmată de ștergere automată. După un an, cloudul privat a fost șters, fără nicio notificare către client, pentru că ștergerea nu pornise de la o cerere a clientului.

Ce a schimbat analiza ulterioară

Varianta Google e mai îngustă decât titlurile care vorbeau despre un cont șters. Analiza descrie un singur client, o singură regiune și unul dintre mai multe clouduri private ale clientului, întins pe două zone. Contul Google, proiectele și celelalte clouduri private ale clientului nu au fost atinse. Backupurile din Google Cloud Storage din aceeași regiune nu au fost afectate de ștergere și, împreună cu un software de backup terț, au contat mult la restaurare.

Povestea e deci mai puțin spectaculoasă decât „Google a șters un fond de pensii” (merită observată diferența dintre „două zone geografice” din declarația comună și „două zone” din analiza Google), dar mai instructivă. Ștergerea a urmat granița unui singur abonament. Tot ce era în interiorul ei a dispărut, cu ambele copii, pentru că replicarea copiază o ștergere la fel de fidel cum copiază datele. A rămas ce se afla în afara ei: stocarea dintr-un alt serviciu și backupurile ținute la alt furnizor.

Clientul nu și-a ales această graniță. A ales-o un câmp lăsat gol într-un instrument intern. Nu aveți cum să știți dinainte unde va cădea granița următorului incident, iar acesta e argumentul pentru a ține cel puțin o copie acolo unde niciun eveniment de la furnizor nu poate ajunge.

Trei feluri de a pierde date, trei protecții

Ajută să separați felurile în care dispar efectiv datele, pentru că fiecare cere altă protecție.

Cade o zonă sau o regiune. O pană de curent, de răcire sau de rețea scoate din funcțiune o locație. Replicarea în mai multe zone sau regiuni rezolvă bine problema; pentru asta a fost gândită redundanța din cloud.

Furnizorul vă șterge resursele. O ștergere ca la UniSuper, un cont suspendat, o problemă de facturare. În discuția de pe Hacker News despre incident, un utilizator povestea că proiectele Google Cloud ale unei firme s-au oprit în câteva minute după ce departamentul de resurse umane a șters contul unui fost angajat, cont de care era legat profilul de plată. E o întâmplare relatată, nu o statistică, dar arată cât de banal poate fi declanșatorul. Replicarea la același furnizor nu ajută aici. Singura protecție e o copie într-un alt cont, cu facturare și date de acces separate, ideal la alt furnizor.

Greșește chiar echipa firmei. O migrare șterge un tabel, un script golește un bucket de stocare, cineva cu drepturi de administrator cade într-o capcană de phishing. Replicarea copiază paguba în câteva secunde. Protecția sunt copiile cu versiuni, păstrate câteva săptămâni, cu date de acces pe care sistemul de producție nu le are, astfel încât ce șterge producția să nu poată șterge și backupurile.

Pentru cele mai multe firme mici, al treilea caz e, după părerea noastră, mult mai probabil decât al doilea. Vestea bună este că protecția pentru al doilea caz acoperă și mare parte din al treilea, dacă e configurată cum trebuie.

Un plan de recuperare pe care îl poate testa o firmă mică

Nimic din toate acestea nu cere bugetul UniSuper. Pentru o aplicație web obișnuită, stabiliți întâi pierderea maximă acceptabilă de date (RPO) și timpul acceptabil până la reluarea serviciului (RTO). Pașii următori sunt un exemplu, nu un minim universal:

  1. Știți ce nu se poate reface. De obicei, baza de date și fișierele încărcate de utilizatori. Codul stă într-un repository, serverele se pot reconstrui. Notați configurația și secretele de care are nevoie sistemul ca să ruleze și păstrați-le într-un manager de parole controlat de firmă.
  2. Creați puncte coerente de recuperare la alt furnizor. Coordonați copiile bazei de date și ale fișierelor încărcate, astfel încât înregistrările restaurate să trimită la fișiere care există la același punct de recuperare. Folosiți metodele de backup ale bazei de date și o copie compatibilă a fișierelor ori versiuni păstrate ale acestora; două copii independente nu sunt suficiente. Exportul zilnic este doar un exemplu: chiar dacă reușește, permite pierderea a circa o zi de date, iar erorile sau întârzierile o pot mări. Alegeți frecvența după RPO. Firma trebuie să dețină contul, cu date de acces și facturare separate.
  3. Separați păstrarea obligatorie de versionare. Un exemplu de implementare este descris în documentația S3 Object Lock. Versionarea ajută la recuperarea obiectelor vechi, dar nu împiedică singură ștergerea versiunilor de către o persoană autorizată sau un cont compromis. Folosiți reguli de păstrare ori blocarea obiectelor, potrivite riscului, cu drepturi de ștergere controlate separat și inaccesibile sistemului de producție. Verificați ce administratori pot ocoli aceste reguli; versionarea singură nu face copia imposibil de modificat sau șters.
  4. Verificați obiectivele prin restaurare. De exemplu, testați trimestrial și după schimbări importante de arhitectură. Restaurați împreună baza de date și fișierele într-un mediu curat, porniți aplicația și verificați operațiile firmei. Notați punctul de recuperare și timpul până când serviciul poate fi folosit, inclusiv refacerea accesului, a infrastructurii și verificarea. Calendarul testelor nu dovedește RTO; restaurarea măsurată îl verifică.

Dacă un al doilea furnizor e deocamdată prea mult, un cont separat la același furnizor e un prim pas rezonabil. AWS, de exemplu, documentează copierea backupurilor într-un alt cont din aceeași organizație, astfel încât un backup șters într-un cont să poată fi recuperat din celălalt. Asta acoperă propriile greșeli și un cont compromis. Nu acoperă situația în care furnizorul acționează asupra întregii organizații.

Cine răspunde de testul de restaurare

Testul de restaurare îl face inginerul, colaboratorul sau firma care administrează sistemul. Rezultatul îi aparține firmei. Asta înseamnă că firma, nu un programator cu adresa lui personală de e-mail, deține contul de backup, că raportul de restaurare ajunge la cineva care poate decide și că testul e trecut în calendar, nu lăsat la bunăvoința cuiva. Un backup pe care nu l-a restaurat nimeni e doar o speranță. E aceeași idee ca în articolul Software needs an owner (în engleză): treaba nu e gata când un instrument e configurat, ci când cineva răspunde de rezultat.

Dacă plătiți pentru mentenanță software, cereți să vedeți ultimul raport de restaurare. Dacă nu există, de aici începeți.

Cea mai puternică obiecție

Chiar analiza Google este cel mai bun contraargument. Ea spune că a fost primul incident de acest fel, că nu e o problemă sistemică și că backupurile UniSuper din Google Cloud Storage, din aceeași regiune, au supraviețuit și au fost folosite la recuperare. Din acest punct de vedere, o configurare bine făcută la un singur furnizor ar fi fost suficientă, iar un al doilea furnizor aduce costuri, încă un set de date de acces și de chei de criptare de protejat, taxe de transfer al datelor și încă un sistem de monitorizat.

O parte din obiecție e corectă. Riscul e mic, iar un al doilea furnizor configurat neglijent, cu cheile ținute lângă producție sau cu o restaurare pe care n-a încercat-o nimeni, adaugă muncă fără să adauge siguranță. Numai că obiecția se sprijină pe ce știm abia acum despre locul în care s-a oprit ștergerea. O copie independentă există tocmai ca să nu depindeți de faptul că următorul incident va avea aceeași întindere ca ultimul. Iar pentru o bază de date mică, un export zilnic criptat la alt furnizor costă probabil mult mai puțin decât o singură săptămână fără acces la date.

Unde nu se aplică

Recomandarea se potrivește mai puțin în trei situații.

  • Aplicațiile SaaS, cum ar fi un program de contabilitate sau o platformă de magazin online, unde datele stau în sistemul furnizorului. Acolo, protecția e un export regulat, într-un format pe care îl puteți citi fără furnizor, plus o lectură atentă a ce spune contractul despre ștergere.
  • Datele care se pot reface, cum ar fi cache-urile, indexurile de căutare sau rapoartele generate din alte date. Backupul lor e opțional.
  • Datele cu restricții de localizare sau contractuale. Dacă datele personale sau ale clienților trebuie să rămână într-o anumită jurisdicție ori la anumiți furnizori aprobați, al doilea furnizor trebuie să îndeplinească aceleași condiții. E un motiv să îl alegeți cu grijă, nu un motiv să renunțați la el.

La doi ani și jumătate distanță

Incidentul UniSuper e ținut minte mai ales ca greșeala Google, iar Google a schimbat într-adevăr instrumentul și valoarea implicită care l-au provocat. Lecția care rămâne ține însă de decizia UniSuper, luată cu mult înainte de mai 2024, de a păstra backupuri în altă parte. Redundanța vă ține sistemul în funcțiune când cade o locație. O copie testată, în afara furnizorului, vă permite să vă recuperați datele când furnizorul, un coleg sau un script șterge chiar lucrul care era redundant.

Surse