Biztonsági mentés

A biztonsági mentés fontosságát egy ismerősöm, Pál példáján szeretném bemutatnia, aki egy más témájú kellemes beszélgetés során kérdezett rá, hogy az általuk alkalmazott biztonsági mentés megfelelő-e. A példa azért is kiváló, mert megmutatja, hogy a biztonsági mentés kapcsán mely szempontokat tart fontosnak egy lelkiismeretes, de nem IT biztonsági szakember és mely veszélyforrások kezelése sikkad el különböző okból.

Pali mérnök és mellette közgazdász végzettséggel is rendelkezik. Az édesapja által indított könyvelő vállalkozásukat már több, mint egy évtizede ő vezeti, irányítja, azaz a családi vállalat sikeresen túlélt egy generációváltást sőt most sikeresebb, mint korábban bármikor. A minőségi, szorgos munka eredményeként a kb. másfél tucatnyi munkavállaló számára biztos hátteret jelentő vállalat számos elégedett ügyfélnek nyújt szolgáltatást.

A vállalat infrastruktúrája szépen fejlődött, fejlődik. Új irodájuk kialakítása folyamatban, az üvegajtós és üvegfalú dizájnos irodába beléptetőrendszer szabályozza a belépést, az informatikai rendszer üzemeltetéséről, az adatok mentéséről külön (részmunkaidős) informatikus gondoskodik, aki hetente meglátogatja őket és intéz minden, informatikával kapcsolatos feladatot, komoly mértékben tehermentesítve a könyvelő cég tulajdonosát, alkalmazottait. Az adatokat az irodában elhelyezett központi szerveren tárolják, amelyben két tükrözött merevlemez dolgozik (RAID1). A szerverről az új adatok naponta, a teljes adatmennyiség hetente a szerverhez kapcsolt lemezes adattárolóra (NAS, Network-attached storage) kerül másolásra.

Pál elégedett: az adataik biztonságban vannak („Négy merevlemezen tárolunk mindent, ez már több, mint elégséges biztonság!” – mondja), a kapcsolódó költségek számára vállalható mértékűek, az informatika adottságként és nem problémaként jelenik meg számukra.

Az adataik valóban biztonságban vannak?

A leírt adattárolási mód valóban sok veszélyforrás kockázatát csökkenti. Lássuk, miért nem kell (túlzottan) aggódnia Palinak:

• Ha meghibásodik a szerverbe szerelt egyik merevlemez, a tükrözésnek (RAID1 struktúra) köszönhetően a másik, épségben maradt merevlemezről az adatok helyreállíthatóak.
• Ha mindegyik merevlemez egyszerre meghibásodik, a lemezes adattárolóra mentett adatokból a fájlok, adatbázisok majdnem teljes mértékben helyreállíthatóak, legfeljebb egy napnyi adatot kell ismételten rögzíteni, betölteni.
• Ha a biztonsági mentés nem sikerül, az adatok a szerveren továbbra is rendelkezésre állnak.
• Ha a lemezes adattároló tönkremegy, az adatok a szerveren továbbra is rendelkezésre állnak.

Látható tehát, ha az infrastruktúrából bármelyik komponens az említett módon (!) kiesik, meghibásodik, az adatok továbbra is rendelkezésre fognak állni, a vállalkozás működése túl nagy zavart nem szenved, az ügyfelek jó esetben észre sem veszik, hogy bármi gond történt a könyvelő cégben.

A pozitívumok után tekintsük át, mely esetekben szembesülhetnek problémával a könyvelőcégnél.

Ha a használt adatbázisokban (bármilyen üzemeltetési vagy egyéb okból) belső szerkezeti hiba, logikai ellentmondás keletkezik, az a szerver mindegyik merevlemezén megjelenik, ugyanis a RAID1-es tükrözés független a merevlemezekre másolt adatoktól, a RAID1 mindent tükröz, az adatbázis hibáit is. Ha az adatbázisok már működésképtelenek is, a RAID1 tükrözése még működik (és működni is fog – ez technikailag független a merevlemezeken tárolt bármilyen adattól, adatbázistól) és a hibák mindegyik merevlemezen leképezésre kerülnek. A hiba előfordulási valószínűségét különböző üzemeltetési módszerekkel lehet csökkenteni, de az adott kisvállalatban alkalmazott szoftverkörnyezet és üzemeltetési lehetőségek alapján tízévente egy eset reális becslésnek tűnik.

A logikai hiba jellegéből adódóan a szerverhez kapcsolt lemezes adattárolóra is kiterjedne, mivel (a másolás jellegétől függően) a logikailag hibás adatbázis hibamentes adatmásolással kiírásra kerülne a lemezes adattárolóra, azaz lenne egy hibátlan de használhatatlan másolat az adattárolón vagy (másolási technikától függően) az adatbázis másolása teljes mértékben sikertelen lenne – amely a végeredmény szempontjából ugyanazt jelenti: nincsen megfelelő biztonsági másolat, amelyről a hibamentes adatbázis helyreállítható lenne. (Jó esetben a korábbi napok adatmásolása sikeres volt, azaz egy napnyi adatmennyiség ismételt rögzítésével, előállításával helyrehozhatják a kárt.)

A szerver és a hozzá kapcsolt hálózati adattároló logikailag és fizikailag egy egységet alkot, azaz ha a mostanában divatos „titkosító, zsaroló” (randomware) kártevők valamelyike (Cryptolocker, CTB-locker stb.) megfertőzné Pál könyvelőirodai hálózatát, Pali elveszítené a szerverén és a hálózati adattárolóján tárolt valamennyi adatát. Nem csak az adatbázisaiban tárolt adatokat, hanem valamennyi Word dokumentumát, Excel táblázatát, szkennelt dokumentumait, korábbi levelezését – mindent!

Elméleti esély? Sajnos nem, már egy évvel ezelőtt hatszázezer felett volt az ismert esetek száma világszerte, hazánkat tekintve fél évvel ezelőtt már ötszáz feletti eset került a szekértők fókuszába. (Az ilyen fertőzések jellemzője, hogy a kártevő az általa elérhető valamenyni merevlemez teljes tartalmát titkosítja és a felhasználónak 24-72 órát ad arra, hogy a 300-3000 USD összegű „visszafejtési díjat” elutalja, jellemzően Bitcoinban. Ha ez nem történik meg, a titkosított merevlemeztartalom örökre hozzáférhetetlen marad a felhasználó számára.) Megfelelő védelmi eszközökkel a randomware fertőzés esélye csökkenthető, de az esetek száma és a tendencia alapján kb. minden ötszázötvenedik vállalkozás számíthat ilyen problémára. (A blogbejegyzés végén megtalálhatóak ennek és a további kalkulációknak az alapadatai és a számítási módszerek.) Az egyetlen valódi segítséget a rendszeres biztonsági mentés jelenti, amelyből az adatok ilyen esetben visszaállíthatóak.

Lehet mondani, hogy az „egy az ötszázötvenhez” elenyésző valószínűség – ez a kis esély mégis azt jelenti, hogy Pali vállalkozása kétszer akkora valószínűséggel fog zsaroló vírus áldozatává válni, mint amekkora eséllyel Pál súlyos vagy halálos közlekedési balesetet szenved Budapesten! Ilyen módon nézve a problémát máris kevésbé örömteli a kép.

Probléma továbbá, hogy a szerverről hálózati adattárolóra másolásról, a másolás sikerességéről vagy sikertelenségéről Pál nem kap visszajelzést. A könyvelőiroda informatikusa Pál „bizalmi embere”: hetente egyszer meglátogatja az irodát, meghallgatja és teljesíti a dolgozók kéréseit és ekkor ellenőrzi az adatok másolását is. Pál tudomása szerint az informatikai rendszereik üzemeltetése során nem fordult elő ilyen probléma sohasem.

Az „üzemeltetési módszertan”okozta kisebbik gond, hogy az esetleges sikertelen adatmásolásokra lehet, csak egy hét elteltével derül fény, azaz ha ilyenkor következne be valamilyen adathiba, akkor nem egy nap, hanem egy hét adatmennyiségét kellene reprodukálni. Nagyobb probléma lehet, ha az informatikus a vezetői kontroll teljes hiánya miatt nem is ellenőrzi a másolások sikerességét ezért akár több hónapnyi vagy évnyi adat sem kerülhetett át a szerverről a hálózati adattárolóra. (A napi munkavégzés során ezt Paliék nem vennék észre, mivel a munka során a szerverről dolgoznak, a hálózati adattárolót „biztonsági mentés” céljából vásárolták anno.) Ha az adatmásolás valóban több hónapig, évig elmarad, hiba esetén ezt a több hónapnyi, évnyi adatot kellene újra rögzíteni, reprodukálni. Belegondolni is rossz…

További probléma, hogy a szerverek és a hálózati adattároló ugyanabból az elektromos hálózatból kapja az energiát. Az irodaépület üzemeltetője szerződésben vállalta a hálózat villámvédelmét, ezért Pál nem telepített sem túlfeszültségvédőt sem szünetmentes tápegységet (mondván, áramszünet esetén egyébként sem tudnának dolgozni).

A legjobbat feltételezve nem fog túlfeszültség megjelenni az elektromos hálózatban, „csak” energiakiesés. Ha ez „biztonsági mentés” (adatmásolás) során történik, az adott másolás sikertelen lesz – de ez a kisebbik gond. Ha az áramszünet a szerveren levő adatbázisok használata közben következik be, akár az adatbázis is megsérülhet – ez már komolyabb problémát okozhat a vállalkozás életében.

Ha ismerősöm csalatkozik az épület üzemeltetőjében (mivel az nem megfelelően védi az elektromos hálózatot) a villámcsapás stb. miatti túlfeszültség egy időben teheti tönkre a szervert és a lemezes adattárolót. Nyilván jogi eljárást indíthat és nagy valószínűséggel a bíróság igazat is fog neki adni – néhány év múlva, ami vajmi keveset fog segíteni rajta és ügyfelein, a határidős adó- és járulékbevallásokban. (A kártérítés mértékének megállapításával és behajtásával kapcsolatos eljárást, mizériát nem is említem.)

Az irodai környezet és a lokáció ismeretében úgy becsülöm, Paliék túlfeszültség vagy áramkimaradás miatti problémával legalább tízévente egyszer szembesülni fognak.

Pál egy korábbi rossz tapasztalata miatt nem kívánt automatikus tűzoltóberendezést telepíttetni az iroda területére – élénken emlékszik, amikor a tévesen beindult sprinklerek az alig fél éve beszerzett teljes informatikai és irodatechnikai berendezés-garnitúrát eláztatták, tönkretették egy kellemes tavaszi hétvégén, amikor senki sem tartózkodott az irodában. Az automatikus oltóberendezés nélküli „csak” tűzjelzős megoldás növeli az esélyét annak, hogy egy irodatűzben valamennyi adatuk megsemmisül. Nyilvánvalóan a szerver és a NAS elázása sem sokkal jobb, mint elégése – mindkét esetben az a probléma, hogy a könyvelőiroda teljes adatmennyisége megsemmisül és a cég tevékenységének folytatása komoly kihívást fog jelenteni.

Költséghatékonysági okból a szerver és a hálózati adattároló az ügyfelek által is látogatható térben van elhelyezve, külön fizikai védelem nélkül (a belsőépítész még fel is használta őket dizájnelemként). Ha egy nem kívánt látogató túljut a beléptetőrendszeren, könnyen eltulajdoníthatja a szervernél lényegesen kisebb méretű hálózati adattárolót a rajta levő teljes ügyféladat-mennyiséggel. Mivel a napi munka során Paliék nem a NAS-ra másolt adatokkal dolgoznak, a NAS hiánya akár csak órák, napok múlva tűnne fel nekik.

Az adatok az adattárolón és a szerveren egyaránt titkosítás nélkül kerülnek tárolásra, ezért Paliék kisebb gondja lenne, hogy az adatbázisok helyreállítása hatalmas erőfeszítést és költséget jelentene, illetve az ügyfelek adatszolgáltatásai, bevallásai jelentős késedelemmel kerülnének elküldésre, ha a szerver éppen akkor menne tönkre, amikor ellopják a hálózati adattárolót; jelentősebb probléma lenne számukra, ha az eltulajdonított eszközön levő adatokat illetéktelenül felhasználják, ezzel kárt okozva az ügyfeleknek és Paliék könyvelő cégének. 

Ha a kisebbik rossz következik be és „csak” határidőt túllépve készülnek el a bevallások, a cég az ügyfeleknek nyújtott kártérítések miatti visszaesésből még felállhat, viszont ha a teljes adatmennyiséget ellopják és felhasználják, a könyvelő cég nem élheti túl a hírnévromlást és az ellene indított kártérítési eljárásokat.

Érdekesség, hogy Paliék jelenlegi irodájából egy hordozható számítógépüket és három mobiltelefonjukat már ellopták (több, egymástól független időpontban), ezért is építettek ki a hamarosan használatba  vehető új irodában beléptetőrendszert. Pál cégének sajátosságait és az iroda elhelyezkedését, kialakítását tekintve valószínűsítem, hogy az „irodai szarkák” a jövőben sem fogják kímélni őket, különös tekintettel arra, hogy kamerás megfigyelőrendszer szándékosan nem került telepítésre.

Mi a megoldás mindezekre?

Néhány egyszerű intézkedéssel jelentősen megbízhatóbb lenne a biztonsági mentés – sőt néhány intézkedéssel tényleges biztonsági mentés lenne bevezetve Pál vállalkozásában:

• A szerverhez és a hálózati adattárolóhoz szünetmentes energiaellátást kellene telepíteni (egyben megoldva a túlfeszültségvédelmet).
• Ha ragaszkodnak a kiépített infrastruktúrához (szerver + NAS) a hálózati adattárolóra az adatokat nem csak a nap végén, hanem napközben is másolni kellene – fél óránként legalább, a sikeres és sikertelen másolásokról pedig e-mailben értesítést/riasztást kellene kapnia az informatikusnak és néhány belső munkavállalónak is.
• A szerveren és a hálózati adattárolón tárolt adatokat titkosítva kellene tárolni.
• A hálózati adattároló mellé mentőegységet kellene telepíteni és az adatokat önálló adathordozóra naponta ténylegesen menteni kellene (ideális esetben két példányban).
• A biztonsági mentésekből egy-egy (titkosított) példányt az irodától távol, jól védett helyen kellene tárolni (azt, hogy ez mit jelent, egy későbbi bejegyzésben járjuk körbe).
• A biztonsági mentések mellett be kellene vezetniük az archiválást is – amelyre egyébként jogszabály kötelezi őket. (A biztonsági mentés és az archivált adatok közötti különbséget egy későbbi cikkben tervezzük bemutatni.)
• A szervert és a hálózati adattárolót (valamint a telepítendő mentőegységet) ügyfelek által nem látogatott helyen kellene tárolni, megfelelő körülmények között (erről szintén külön bejegyzést tervezünk írni).
• Rendszeresen tesztelni kellene, hogy vissza tudják-e állítani a biztonsági mentésekből az üzemi rendszereiket (erről szintén egy későbbi blogbejegyzésben fogunk részletesebben írni).

Mennyi lenne mindennek a költsége?

Pál alkalmazottainak jellemző javadalmazásával kalkulálva egy munkavállaló egyhavi átlagos munkabérével összemérhető kiadást jelentene a leírtak megvalósítása, a megfelelő biztonsági mentés megvalósítása.

Megítélés kérdése, hogy ez sok vagy kevés egy több évtizedes múltra visszatekintő, másfél tucatnyi munkavállalónak megélhetést, néhány száz ügyfélnek számviteli szolgáltatást nyújtó vállalat adatainak biztonságos mentéséért; az viszont biztos, hogy a megfelelő biztonsági mentés megvalósításának költsége jelentősen alacsonyabb összeg, mint a korábban említett bármelyik hiba következményeinek megszüntetése.

Fontos hangsúlyozni, hogy a leírt szempontok nem jelentik a biztonsági mentés témakör teljes áttekintését, de szeretnénk egy tea/kávé elfogyasztási idején belül tartani egy-egy blogbejegyzés olvasási idejét. Hasonlóan kiemelendő, hogy az ajánlott intézkedések nem jelentik a teljes körű vagy kizárólagosan megfelelő védelmet: a javaslatokat Pál vállalkozásának ismeretében tettük, a tevékenységi kör, elhelyezkedés, ügyfélállomány és nem utolsó sorban Pali kockázatvállalási hajlandósága és költségérzékenységi szintje alapján.

Ha Pali informatikai fejlesztéssel, gépészeti tervezéssel, tejfeldolgozással, telekommunikációs szolgáltatással, kiskereskedelemmel stb. foglalkozó vállalkozást irányítana, vagy a munkavállalók száma lényegesen több (esetleg kevesebb) lenne esetleg a tulajdonosi struktúra eltérő lenne, tanácsaink is (részben) másként szóltak volna.

Önök hogyan mentik az adataikat? Ügyfeleik számítanak Önökre – bizonyos benne, hogy probléma esetén helyre tudnák állítani az adatbázisaikat, fájlaikat és folytatni tudják tevékenységüket?

Lépjünk kapcsolatba most és örömmel áttekintjük az Önök mentési, archiválási megoldását, visszajelzést adunk a megfelelőségekről és javaslatokat teszünk a fejlesztésre (ha szükséges). 

KAPCSOLATFELVÉTEL

REFERENCIÁINK

A cikkünkben említett kalkulációk részletei (adatok és számítási módszer):

• A „zsaroló, titkosító” kártevők kapcsán:
  • Magyarország lakossága 2014.01.01-én: 9.877.365 (https://hu.wikipedia.org/wiki/Magyarorsz%C3%A1g_n%C3%A9pess%C3%A9ge)
  • az internetet rendszeresen használók aránya 2014-ben: a népesség 75 százaléka (https://www.ksh.hu/docs/hun/eurostat_tablak/tabl/tin00091.html)
  • az internethasználókból 18 fő Pál irodájában dolgozik (a Palival folytatott beszélgetés alapján)
  • a blogbejegyzés publikálásáig 750 hazai Cryptolocker fertőzés fordult elő (írott sajtóban az utóbbi hónapban olvastam 500-1000 eddigi hazai esetről – ezek átlaga 750)
  • 9.877.365 x 0,75 : 750 : 18 = 549 (egészre kerekítve) azaz egy az ötszáznegyvenkilenchez az esélye, hogy Paliék vállalkozása valamely zsaroló, adattitkosító kártevő áldozatául esik.

• Közlekedési balesetek bekövetkezési esélye:
  • Budapest népessége 2014.01.01-én: 1.744.665 (http://www.geoindex.hu/uzleti-szolgaltatasok/elemzes/magyar-telepulesek-nepessege-2014-evi-adatokkal/)
  • súlyos és halálos közlekedési balesetek száma Budapesten 2014-ben: 731 + 50 = 781 (http://www.ksh.hu/docs/hun/xstadat/xstadat_evkozi/e_feb002.html)
  • egy balesetben két sérülttel számoltunk
  • 1.744.665 : 781 : 2 = 1117 (egészre kerekítve) azaz egy az ezeregyszáztizenhéthez az esélye, hogy budapesti lakos súlyos közlekedési balesetet szenvedjen

Elnézést a példáért, kívánom minden olvasónak, hogy elkerülje a balszerencse, viszont hadd hangsúlyozzuk ismételten: egy másfél tucatnyi munkavállalót foglalkoztató vállalkozásnak kétszer akkora esélye van „zsaroló, titkosító” kártevő áldozatává válni, mint arra, hogy a budapesti cégvezetőt komoly közlekedési baleset éri. Előbbi esemény bekövetkezési valószínűségét illetve az esetleges fertőzéskor a kár nagyságát tudjuk csökkenteni – lépjünk kapcsolatba most, kezdjünk dolgozni vállalata biztonsága érdekében mihamarabb!

KAPCSOLATFELVÉTEL

REFERENCIÁINK