Zaštita podataka u cloud rezervnim kopijama: brisanje, obnova i dokaz

Brisanje u cloud okruženju je provjerljivo tek kada organizacija zajedno posmatra produkcijski sistem, rezervne kopije i obnovu. GDPR ne propisuje jedan rok prepisivanja za svaku kopiju. Zahtijeva rješenje zasnovano na riziku i dokumentaciji koje sprečava nepotrebno čuvanje i nekontrolisano vraćanje obrisanih podataka.

Ovaj tekst objašnjava kako izgraditi koncept brisanja za rezervne kopije. U središtu su razlika između aktivnog sistema i kopija, tehnička ograničenja, postupak obnove i dokaz za internu provjeru ili nadzorni organ. Prvo određivanje materijalnog roka čuvanja podataka klijenata, kandidata ili zaposlenih je poseban korak.

Sadržaj kopije određuje njenu važnost za zaštitu podataka. Backup, snapshot, arhivski izvoz i replika mogu sadržavati lične podatke iako u svakodnevnom radu nisu vidljivi kao dio aplikacije. Popišite sisteme, mjesta čuvanja, vrste kopija i odgovornosti. Važno je da li se podaci još mogu povezati sa osobom.

Rezervna kopija ima drugačiju funkciju od produkcijskog sistema. Obično štiti dostupnost i mogućnost obnove. Ta funkcija ne ukida potrebu da se čuvanje ograniči i pristup zaštiti. Prema članovima 25 i 32 GDPR-a arhitektura i sigurnosne mjere moraju odgovarati svrsi i riziku obrade.

Prvo pitanje zato glasi šta kopija sadrži i zašto je potrebna. Odluka o prvom roku čuvanja produkcijskih podataka ostaje odvojena. Tek tada se može odlučiti da li kopiju treba odmah obrisati, izolovati do redovnog prepisivanja ili zadržati uz posebno dokumentovan izuzetak.

Kada se lični podaci obrišu u produkcijskom sistemu, postupak mora obuhvatiti povezane rezervne kopije. Član 17 GDPR-a treba procijeniti u konkretnom slučaju. Ako postoji obaveza brisanja i nema izuzetka, organizacija ne smije backup koristiti kao trajnu zamjensku arhivu za isti skup podataka.

Trenutna izmjena svake datoteke u svakoj nepromjenjivoj kopiji nije moguća u svakoj arhitekturi. Tada odbranjivo rješenje može biti kombinacija zabrane produkcijskog pristupa, strogo ograničene obnove i određenog procesa prepisivanja. Kopija se u tom periodu ne smije koristiti za nove svrhe. Razlog i primjerenost rješenja treba dokumentovati.

Provjerite i sporedne puteve: ručne izvoze, testna okruženja, lokalna preuzimanja i kopije kod pružaoca. Proces koji obuhvata samo vidljivu bazu ostavlja nepotpun dokaz. Tekst o konceptu brisanja podataka klijenata i leadova obrađuje prethodnu provjeru svrhe i čuvanja.

Pouzdan životni ciklus backupa povezuje svrhu zaštite sa provjerljivim ciklusom prepisivanja. Rečenica poput „backup se briše nakon sedam godina“ ne zamjenjuje provjeru ako ciklus ne odgovara svrsi i riziku. Ni tehnički ciklus ne smije bez razloga čuvati podatke neograničeno.

Odredite koje uloge smiju čitati, izvoziti, brisati ili obnavljati kopije. Redovni pristup treba ograničiti i evidentirati. Enkripcija, odvojene dozvole i kontrola u dva koraka mogu biti primjerene zavisno od rizika. Potrebna mjera zavisi od konkretnog okruženja.

Povežite ciklus sa obnovom. Stara kopija koja se u svakom trenutku može u cijelosti vratiti drugačije se procjenjuje od šifrovane i tehnički izolovane kopije. Provjerite čuva li pružalac immutable snapshot kopije, geografske replike ili vlastitu kantu za otpad. Kada je relevantno, ove funkcije uključite u evidenciju aktivnosti obrade i tehničke i organizacijske mjere.

Obnova može unijeti starije stanje podataka u novo okruženje. Prije aktiviranja utvrdite da li sadrži obrisane, ispravljene ili ograničene podatke. Odredite odobrenje sa razlogom, obimom, ciljnim sistemom i odgovornom osobom. Hitnost može tražiti brzinu, ali ne smije sakriti provjeru zaštite podataka.

Odvojeno okruženje za obnovu korisno je za prvu provjeru i čišćenje. Uporedite oznake brisanja, liste ograničenja i ispravke urađene nakon nastanka kopije. U aktivni rad treba prenijeti samo potreban dio. Podatke koji nisu potrebni za obnovu uklonite.

Poslije obnove zabilježite koja je kopija korištena, šta je provjereno, koje je čišćenje izvršeno i ko je odobrio aktiviranje. To podržava odgovornost prema članu 5 stav 2 GDPR-a. Tekst o dokumentovanju tehničkih i organizacijskih mjera pokazuje kako kontrole i odgovornosti mogu biti provjerljive.

Član 18 GDPR-a može zahtijevati ograničenje, na primjer kada je tačnost osporena, kada je obrada nezakonita pa lice umjesto brisanja traži ograničenje ili kada su podaci potrebni za pravne zahtjeve. Ograničenje je konkretna pravna odluka. Ne može se izjednačiti sa samim postojanjem backupa.

Za ograničenu backup kopiju moraju biti jasni svrha, obim i pristup. Podaci se tada mogu dalje obrađivati samo pod uslovima člana 18 stav 2 GDPR-a. Tehničko ograničenje treba ponovo primijeniti u procesu obnove. Obnova ne smije ograničene podatke tretirati kao slobodan produkcijski skup.

Zabilježite kada ograničenje počinje, koji događaj ga završava i ko obavlja provjeru. Kada se okolnosti promijene, lice se uglavnom mora obavijestiti prije ukidanja ograničenja. Ograničenje je zato poseban status sa posebnom kontrolom, a ne opšti razlog za neograničeno čuvanje svih kopija.

Koristan dokaz povezuje pravnu odluku, tehničku konfiguraciju i stvarno izvršenje. Uključite popis kopija, kategorije podataka, status brisanja ili ograničenja i opis prepisivanja. Dodajte uloge, kontrole pristupa i proces obnove. Sama politika bez kontrolnog zapisa uglavnom nije dovoljna za odgovornost.

Proporcionalnim uzorkom provjerite da li je obrisani zapis uklonjen iz aktivnog sistema, da li je kopija dostupna samo ovlaštenim ulogama i da li testna obnova primjenjuje logiku brisanja i ograničenja. Kada produkcijska obnova nije potrebna, koristite odgovarajuće testne podatke. Za svaki test zabilježite razlog, rezultat i korektivni korak.

Odstupanja razvrstajte prema riziku. Stari korisnički nalog, nedokumentovani snapshot ili obnova bez odobrenja mogu tražiti različite reakcije. Zapis treba objasniti odluku i pokazati sljedeći termin provjere. Tako arhitektura ostaje razumljiva kod promjene pružaoca ili migracije sistema.

Ako cloud ili backup pružalac obrađuje lične podatke u ime organizacije, njegovu ulogu treba procijeniti prema članu 28 GDPR-a. Ugovor treba prikazati funkcije backupa, podizvršioce, mjesta čuvanja, pristup i pomoć kod brisanja i ograničenja. Standardne uslove uporedite sa stvarno ugovorenom arhitekturom.

Pitajte koje kopije postoje izvan vidljivog backupa. Snapshots, replike, kante za otpad, support kopije i tehnički logovi mogu biti važni. Razjasnite kako će se status brisanja ili ograničenja poštovati kod obnove. Obećanje da će se „obrisane datoteke“ ukloniti iz primarnog prostora ne odgovara na sva ova pitanja.

Unutar organizacije odredite ko procjenjuje zahtjev, daje nalog pružaocu i provjerava njegov odgovor. Stranica o izvršiocima obrade i pružaocima usluga pomaže pri raspodjeli odgovornosti. Kod važne promjene arhitekture ažurirajte i evidenciju aktivnosti obrade.

Počnite sa jednim konkretnim slučajem brisanja i pratite ga kroz arhitekturu. Koja aplikacija je obrisala podatke? Koje kopije su poslije nastale? Koje kopije su i dalje dostupne? Odgovori pokazuju da li proces prati stvarni tok podataka ili opisuje samo produkcijski sistem.

Zatim testirajte obnovu u kontrolisanom scenariju. Test treba pokazati primjenjuju li se oznake brisanja i ograničenja prije aktiviranja, funkcionišu li dozvole i evidentira li se izvršenje. Stranica o zapisima pristupa i granicama dokaza može pomoći pri provjeri pristupa.

Na kraju svakom otvorenom pitanju dodijelite odgovornu ulogu i datum provjere. Tema usklađenosti i upravljanja privatnošću pomaže pri razumijevanju principa. Dokumentacija backupa je potpuna kada povezuje odluku, tehničku kontrolu, ponašanje obnove i dokaz.