Pse Aktivizimi i Object Lock Mund të Mos i Mbrojë Rezervimet Tuaja të Vjetra
Object lock, mekanizmi pas rezervimeve të pandryshueshme në ruajtjen e objekteve në cloud, është një nga kontrollet e sigurisë më të keqkuptuara. Duke shkruar në blogun e Backblaze, Kari Wilson, një menaxhere e lartë e marketingut të produkteve në Backblaze, përshkruan hendekun midis aktivizimit të një çelësi object lock dhe mbrojtjes aktuale të të dhënave. Diskutimi bazohet në çështje reale që dalin në bisedat teknike me administratorët e IT-së dhe arkitektët e sistemeve, pasi dokumentacioni është lexuar por para se konfigurimi të besohet plotësisht.
Një nga konfuzionet e para është ndryshimi midis pandryshueshmërisë dhe enkriptimit. Enkriptimi mbron njerëzit nga shikimi i të dhënave tuaja. Object lock mbron njerëzit nga fshirja e tyre. Një rezervim i enkriptuar që një sulmues mund ta fshijë nuk është një opsion rikuperimi. Një rezervim i pandryshueshëm që një sulmues mund ta lexojë në tekst të thjeshtë është ende një pikë rikuperimi e përdorshme. Të dyja kanë rëndësi, por shërbejnë funksione të ndryshme. Trajtimi i tyre si të këmbyeshme është mënyra se si organizatat përfundojnë me boshllëqe në një drejtim ose tjetrin.
Një shqetësim i lidhur është se të dhënat e pandryshueshme do të jenë të vështira për t'u rikuperuar. Nuk do të jenë. Të dhënat e pandryshueshme mbeten plotësisht të lexueshme dhe të shkarkueshme gjatë gjithë periudhës së pandryshueshmërisë. Mund të rikuperoni prej tyre, të aksesoni skedarë individualë dhe të ngarkoni versione të reja krahas atyre të mbrojtura. E vetmja gjë që object lock parandalon është modifikimi dhe fshirja para se të skadojë periudha e pandryshueshmërisë. Kjo është e gjithë pika.
Me Backblaze B2, object lock mund të aktivizohet në krijimin e bucket-it ose të shtohet në një bucket ekzistues më vonë. Pasi aktivizohet, nuk mund të çaktivizohet, kështu që ndryshimi është i përhershëm në atë drejtim. Megjithatë, aktivizimi i object lock në një bucket ekzistues nuk mbron në mënyrë retroaktive skedarët që ndodhen tashmë në të. Vetëm skedarët e ngarkuar ose kopjuar në bucket pasi object lock është aktivizuar janë të pranueshëm për t'u kyçur. Skedarët që ishin atje më parë nuk preken. Implikimi praktik është i qartë: nëse shtoni object lock në një bucket me rezervime ekzistuese, mos supozoni se ata skedarë të vjetër janë tani të mbrojtur. Rezervimet e reja të shkruara pas ndryshimit do të mbrohen, por çdo gjë që ndodhet tashmë në bucket kërkon cilësime individuale të kyçjes të aplikohen manualisht.
Ekziston gjithashtu një supozim i zakonshëm se pandryshueshmëria konfigurohet në nivel bucket-i. Për shumë aplikacione rezervimi, kjo është vetëm gjysma e figurës. Kur përdorni Veeam ose mjete të ngjashme të ndërmarrjeve, aplikacioni i rezervimit menaxhon object lock në bazë të çdo skedari. Bucket-i duhet të ketë object lock të aktivizuar si aftësi, por aplikacioni kontrollon se cilët skedarë kyçen dhe për sa kohë. Mendoni për cilësimin e bucket-it si hapja e derës; softueri i rezervimit vendos se çfarë kalon nëpër të. Të dyja anët duhet të konfigurohen: object lock i aktivizuar në bucket, dhe pandryshueshmëria e aktivizuar brenda aplikacionit të rezervimit. Njëra pa tjetrën nuk bën asgjë.
Periudha e ruajtjes dhe periudha e pandryshueshmërisë janë cilësime të ndara që veprojnë në mënyrë të pavarur. Një politikë ruajtjeje katërvjeçare do të thotë që aplikacioni juaj i rezervimit i mban të dhënat për katër vjet. Një periudhë pandryshueshmërie 14-ditore do të thotë që skedarët nuk mund të fshihen ose modifikohen për 14 ditë pasi të shkruhen. Pasi skadojnë 14 ditët, object lock lirohet. Skedari është ende atje, i qeverisur nga politika juaj e ruajtjes, por nuk është më i pandryshueshëm. Të dy cilësimet nuk kanë nevojë të përputhen. Një konfigurim tipik përdor një politikë të gjatë ruajtjeje me një dritare më të shkurtër pandryshueshmërie, duke mbuluar periudhën kur ransomware ose një aktor keqdashës ka më shumë gjasa të tentojë fshirjen.
Sa e gjatë duhet të jetë periudha e pandryshueshmërisë? Rekomandimi më i zakonshëm është 7 deri në 14 ditë, me 14 ditë si një parazgjedhje e arsyeshme për shumicën e mjediseve. Logjika është se nëse ransomware ose një sulm godet mjedisin tuaj, ju do ta dini brenda disa orësh, ndoshta disa ditësh. Periudha e pandryshueshmërisë nuk ka nevojë të mbulojë muaj kompromisi të mundshëm. Ajo duhet të mbulojë dritaren midis momentit kur ndodh një sulm dhe kur ju e zbuloni dhe i përgjigjeni atij. Ekipet e sigurisë që kanë testuar rrjedhat e tyre të punës së reagimit ndaj incidenteve shpesh gjejnë se 7 ditë funksionojnë mirë. Çështja është të përafroni periudhën me aftësinë tuaj të zbulimit, jo ta maksimizoni atë në mënyrë arbitrare.
Ekziston gjithashtu një kënd kostoje që është e lehtë të humbasësh. Çdo herë që softueri i rezervimit shkruan ose rinovon një object lock, ai bën një thirrje API të klasës PUT për të përditësuar metadata-n e ruajtjes në atë objekt. Në AWS S3, ato thirrje faturohen si kërkesa standarde PUT me 0,005 dollarë për 1,000. Në mjedise të mëdha me punë të shpeshta rezervimi, ato tarifa transaksioni grumbullohen. Backblaze B2 nuk ngarkon për kërkesat PUT, kështu që shkrimet dhe rinovimet e kyçjes përfshihen me ruajtjen tuaj. Në praktikë, kjo do të thotë se dritaret më të shkurtra të pandryshueshmërisë nuk mbartin një penalitet kostoje në B2, dhe nuk ka nxitje për të minimizuar rinovimet e kyçjes për të ulur faturën tuaj API.
Nëse konfiguroni një periudhë pandryshueshmërie 7-ditore në Veeam dhe pastaj kontrolloni datat aktuale të skadimit të kyçjes në bucket-in tuaj, mos u habitni të shihni skedarë të kyçur deri në ditën 10, 14, apo edhe 17. Veeam shton ditë shtesë në periudhën e pandryshueshmërisë përtej çfarëdo që konfiguroni. Kjo është sjellje e qëllimshme. Veeam mbron kundër skenarit ku një skedar shkruhet vonë në një punë rezervimi, dhe një operacion pastrimi i ruajtjes do të përpiqej ta fshinte atë para se periudha e pandryshueshmërisë të ketë kaluar plotësisht. Ditët shtesë krijojnë një tampon. Implikimi praktik është planifikimi i kapacitetit të ruajtjes: nëse buxhetoni për 7 ditë ruajtje të pandryshueshme, mund t'ju duhet të llogarisni për afër 14 ditë të dhënash që nuk mund të fshihen në çdo moment të caktuar. Planifikoni për atë variancë.
Rregullat e ciklit jetësor në nivel bucket-i që fshijnë automatikisht të dhënat bazuar në moshë ose kritere të tjera do të bien ndesh me mënyrën se si aplikacionet e rezervimit menaxhojnë ciklin e tyre jetësor të të dhënave. Kur lejoni Veeam ose një aplikacion tjetër të trajtojë zinxhirin tuaj të rezervimit, ai aplikacion gjurmon se cilët skedarë janë aktivë, cilët kanë skaduar dhe kur secili duhet të hiqet. Nëse vendosni një rregull cikli jetësor në bucket që fshin skedarët pas 30 ditësh, dhe aplikacioni juaj i rezervimit ende i referohet një skedari që është 32 ditë i vjetër, ju keni thyer zinxhirin. Qasja e duhur është të lini rregullat e ciklit jetësor të bucket-it të qetë dhe të lejoni softuerin e rezervimit të trajtojë të gjithë menaxhimin e të dhënave. Nëse aplikacioni juaj i rezervimit po funksionon si duhet, nuk ka nevojë për rregulla fshirjeje në nivel bucket-i. Nëse diçka nuk po funksionon si duhet, një rregull cikli jetësor do ta përkeqësojë problemin.
Jo i gjithë softueri i rezervimit mbështet object lock. Mjetet e sinkronizimit të konsumatorëve dhe aplikacionet bazë të rezervimit të skedarëve në përgjithësi nuk mbështesin rezervime të pandryshueshme. Kur hasin një objekt të pandryshueshëm, operacioni i shkrimit për ta fshirë ose modifikuar atë do të dështojë, gjë që prish punën e rezervimit. Aplikacionet e rezervimit të ndërmarrjeve si Veeam dhe Commvault kanë mbështetje vendase për object lock. Ata dinë të shkruajnë flamujt e pandryshueshmërisë, të menaxhojnë periudhat e ruajtjes dhe të trajtojnë thirrjet API S3 në mënyrë korrekte. Nëse mjeti juaj aktual i rezervimit nuk është në listën e ndërmarrjeve, kontrolloni dokumentacionin para se të supozoni se pandryshueshmëria do të funksionojë. Një zinxhir rezervimi që dështon në heshtje për shkak të trajtimit të papajtueshëm të object lock nuk po mbron asgjë.
Pasi një objekt kyçet me një datë specifike skadimi, ajo datë mund të lëvizë vetëm përpara. Mund ta zgjasni periudhën e pandryshueshmërisë, por nuk mund ta shkurtoni atë. Ky është një kufizim i qëllimshëm i dizajnit: e gjithë vlera e pandryshueshmërisë është se ajo nuk mund të dobësohet në mënyrë retroaktive. Nëse një llogari e komprometuar ose një aktor keqdashës mund të shkurtonte ose hiqte kyçjen, mbrojtja do të ishte e pakuptimtë. I njëjti parim vlen për konfigurimet e modalitetit të qeverisjes kundrejt modalitetit të pajtueshmërisë. Modaliteti i pajtueshmërisë e bën fshirjen e të dhënave të pamundur edhe për administratorët e llogarisë gjatë periudhës së ruajtjes. Modaliteti i qeverisjes lejon disa përdorues të privilegjuar të modifikojnë kyçjen. Për mbrojtje serioze kundër ransomware, modaliteti i pajtueshmërisë është përgjithësisht zgjedhja më e fortë.
Object lock parandalon çdo individ nga fshirja e objekteve të pandryshueshme brenda llogarisë suaj. Edhe një administrator me leje të plota nuk mund të fshijë një objekt të kyçur para se të skadojë periudha e tij e ruajtjes. Megjithatë, nëse dikush me akses në nivel llogarie fshin të gjithë llogarinë, ajo mbrojtje nuk i shpëton të dhënat. Kjo vlen për çdo ofrues të ruajtjes në cloud, jo vetëm Backblaze. Nuk është një boshllëk në object lock, është një sipërfaqe sulmi krejtësisht e ndryshme. Zbutja është siguria e llogarisë: autentifikimi me dy faktorë, privilegje të kufizuara administrative dhe monitorim për aktivitet të pazakontë të llogarisë. Object lock dhe siguria e llogarisë punojnë së bashku. Asnjëra nuk e bën tjetrën të tepërt.
Me Backblaze B2, pandryshueshmëria përfshihet si pjesë e abonimit standard të ruajtjes. Disa ofrues të ruajtjes ngarkojnë veçmas për thirrjet API të object lock, duke përfshirë kërkesat PUT që rinovojnë ose shkruajnë metadata-n e kyçjes. Ato tarifa transaksioni mund të grumbullohen ndjeshëm në mjedise me numër të lartë skedarësh ose rinovime të shpeshta të kyçjes. Me B2, ju paguani për ruajtjen që përdorni, duke përfshirë çdo ruajtje shtesë të konsumuar nga të dhënat që nuk mund të fshihen gjatë periudhës së tyre të pandryshueshmërisë. Vetë veçoria nuk ka shtesë. Nëse aktivizoni versionimin krahas pandryshueshmërisë, të gjitha versionet e një skedari llogariten në përdorimin tuaj të ruajtjes, jo vetëm ai aktual. Nëse një skedar është modifikuar 50 herë dhe po ruani 50 versione, ju po paguani për të gjitha 50 pavarësisht se sa prej tyre janë aktualisht të pandryshueshme. Konfigurimi i duhur i versionimit varet nga objektivat tuaj të rikuperimit dhe buxheti juaj. Mbajtja e çdo versioni pafundësisht është rrallë e nevojshme, dhe shumica e aplikacioneve të rezervimit ju japin kontroll mbi sa versione të ruani.
Para se të vendosni object lock në prodhim, Wilson rekomandon një listë të shkurtër kontrolli. Verifikoni që aplikacioni juaj i rezervimit ka mbështetje vendase për object lock dhe se keni aktivizuar pandryshueshmërinë brenda cilësimeve të aplikacionit, jo vetëm në nivel bucket-i. Krijoni bucket-in tuaj me object lock të aktivizuar edhe nëse nuk planifikoni ta përdorni në ditën e parë, sepse nuk mund të ktheheni dhe ta aktivizoni më vonë. Kapërceni rregullat e ciklit jetësor të bucket-it nëse softueri juaj i rezervimit po menaxhon ciklin jetësor të të dhënave. Llogarisni ditët shtesë të Veeam kur planifikoni kapacitetin e ruajtjes, sepse dritarja aktuale e kyçur do të jetë më e gjatë se ajo që konfiguroni. Së fundi, rishikoni periudhën tuaj të pandryshueshmërisë në kontekstin e aftësisë suaj të zbulimit të incidenteve. Një dritare pandryshueshmërie 30-ditore nuk është më e sigurt se një dritare 14-ditore nëse ekipi juaj i sigurisë mund të zbulojë një incident brenda 48 orësh. Object lock është një nga mjetet më të besueshme të disponueshme për mbrojtjen e të dhënave të rezervimit kundër ransomware, por shumica e gabimeve të zbatimit janë të lehta për t'u korrigjuar pasi e dini se ku të shikoni. Për ekipet që preferojnë të mos menaxhojnë cilësimet e object lock nëpër mjete të shumta rezervimi, një ofrues evropian i menaxhuar i cloud dhe infrastrukturës së të dhënave si AEU Data ofron rezervime të automatizuara, ruajtje të enkriptuar dhe monitorim që mund të zvogëlojë këto boshllëqe konfigurimi.