Adatközpont háborús övezetben: a felhő sem véd meg a geopolitikai kockázattól

Hogyan térképezheti fel egy hazai vállalat a felhős infrastruktúra rejtett függőségeit, és mikor indokolt a több régiós működés?

Adatközpont háborús övezetben: a felhő sem véd meg a geopolitikai kockázattól

Sokáig tartotta magát a hazai üzleti döntéshozók körében az a kényelmes vélekedés, miszerint ha egy vállalat a saját irodai szerverszobájából átköltözteti a rendszereit valamelyik globális felhőszolgáltatóhoz, azzal automatikusan meg is oldotta az infrastruktúra fizikai védelmét. Egy dinamikusan növekvő, digitális kereskedelemmel és logisztikával foglalkozó magyar középvállalat vezetése is pontosan ezzel a megnyugvással tekintett az informatikai háttérre, miután a vállalatirányítási rendszert, a webáruházat és a számlázást egyetlen nyugat-európai felhőrégióba konszolidálta. Az éves ellenőrzések során a menedzsment megelégedett azzal a formális információval, hogy az adatok az Európai Unió határain belül találhatók, a szolgáltatási szerződés pedig papíron kilencvenkilenc egész kilenc tized százalékos rendelkezésre állást garantál. Amikor azonban a nemzetközi hírekben megszaporodtak a kritikus energetikai hálózatokat, tenger alatti adatkábeleket és távközlési csomópontokat érintő fenyegetések, a cégvezetés kénytelen volt szembesülni a ténnyel, hogy valójában fogalmuk sincs, pontosan hol és milyen fizikai függőségek mentén üzemel a vállalat teljes digitális vagyona.

A felhő valójában nem egy földrajztól független, absztrakt tér, hanem nagyon is kézzelfogható, betonból és acélból épült adatközpontok összessége, amely éppúgy ki van téve a fizikai világ fenyegetéseinek, mint bármely hagyományos ipari létesítmény. A World Economic Forum Global Risks Report kétezer-huszonötös felmérésében a nemzetközi szakértők az államalapú fegyveres konfliktusokat jelölték meg a legjelentősebb közvetlen globális kockázatként, miközben az Európai Unió Kiberbiztonsági Ügynöksége, az ENISA legfrissebb fenyegetettségi elemzése is hangsúlyozza, hogy a geopolitikai feszültségek közvetlenül alakítják a kritikus infrastruktúrák és digitális ellátási láncok sebezhetőségét. Bár a vezető szolgáltatók, mint az Amazon Web Services, a felhőrégióikat több, fizikailag különálló rendelkezésre állási zónára osztják, ez az architektúra elsősorban a lokális hardverhibák és elszigetelt létesítményi zavarok ellen nyújt védelmet. Egy kiterjedt háborús konfliktus, egy regionális szintű áramellátási katasztrófa vagy a gerinchálózati optikai összeköttetések elvágása egy teljes felhőrégió elérhetetlenségét okozhatja, ami ellen a zónák közötti megosztás önmagában nem nyújt érdemi védelmet.

A bemutatott hazai vállalatnál az első komoly ébresztőt az jelentette, amikor az IT-vezetés egy kockázati szimuláció során felvázolta, milyen következményekkel járna a választott európai régió többnapos leállása. A menedzsment korábban abban a hitben élt, hogy baj esetén legfeljebb néhány órás kieséssel kell számolniuk, a részletes átvilágítás azonban rámutatott, hogy semmilyen működő forgatókönyv nem áll rendelkezésre egy teljes régiós kiesés kezelésére. A napi több ezer megrendelést kezelő webshop leállása nem csupán közvetlen árbevétel-kiesést eredményezett volna, hanem a raktári kiszolgálás és a számlázás blokkolásával órák alatt megbénította volna a partnerekkel és vásárlókkal fenntartott teljes kapcsolatot. A reputációs és pénzügyi veszteségek minimalizálása érdekében a cégvezetés elrendelte a digitális infrastruktúra teljes felülvizsgálatát, azzal a céllal, hogy a papíron létező feltételezéseket valós üzletmenet-folytonossági képességekre cseréljék.

A folyamat a kritikus alkalmazások szigorú üzleti auditjával indult, amely során a rendszereket bevételkritikus, ügyfélkiszolgálási és adminisztratív kategóriákba sorolták. Minden egyes szoftverkomponenshez pontosan meghatározták a megengedhető leállási időt, az úgynevezett RTO-t, valamint a még tolerálható adatvesztés maximális mértékét, az RPO-t. Ez a lépés rávilágított arra, hogy a cégnek felesleges lenne minden adatbázist másodpercre pontosan tükröznie, viszont a rendeléskezelő és fizetési moduloknál a két órán túli leállás már elviselhetetlen üzleti kárt okozna. A technikai feltárás során felszínre kerültek a korábban láthatatlan közös hibapontok is. Kiderült, hogy bár a virtuális gépek több zónában futottak, az alkalmazások ugyanarra az egyetlen identitáskezelő szolgáltatásra és ugyanarra a külső DNS-konfigurációra támaszkodtak, vagyis egy központi hálózati probléma esetén a tartalékként beállított kapacitások is elérhetetlenné váltak volna.

A kockázatok kezelésére a vállalatnak ki kellett választania a leginkább arányos katasztrófa-helyreállítási modellt, elkerülve a feleslegesen túlbonyolított, gazdaságtalan megoldásokat. Az AWS katasztrófa-helyreállítási keretrendszere négy alapvető szintet különböztet meg: a biztonsági mentésre és visszaállításra épülő modellt, a minimális maginfrastruktúrát készenlétben tartó őrláng megközelítést, a csökkentett kapacitással folyamatosan futó meleg készenlétet, valamint a teljes mértékben párhuzamos, több régiós aktív-aktív architektúrát. Bár a teljesen redundáns, folyamatosan szinkronizált kétoldali működés nyújtaná a legkisebb leállási időt, ennek fenntartása a licenccsomagok és a folyamatos adatforgalmi díjak miatt megduplázta volna az informatikai költségvetést. A döntéshozók ezért az őrláng stratégia mellett tették le a voksukat, amely a kritikus adatbázisokat folyamatosan replikálja egy földrajzilag távoli második európai régióba, de a kiszolgáló szervereket csak egy tényleges katasztrófa esetén indítja el automatizáltan.

A másodlagos régió kiépítése során a mérnökcsapatnak számos technológiai és szabályozási akadályt kellett leküzdenie. Nem volt elegendő pusztán az adatbázisok másolatát átküldeni a célrégióba, hanem biztosítani kellett a teljes infrastruktúra kódként történő leírását is, hogy a hálózati útválasztók, tűzfalak és konténerek percek alatt felépülhessenek emberi beavatkozás nélkül. Szigorú figyelmet követelt az adatlokalizációs és megfelelőségi követelmények betartása, hiszen az Európai Unión belüli adatvédelmi szabályok korlátozzák, hogy az ügyfelek személyes adatai mely joghatóságok alá tartozó adatközpontokba másolhatók. Emellett gondoskodni kellett a titkosítási kulcsok, a hitelesítési tanúsítványok és a belső jogosultsági rendszerek biztonságos szinkronizációjáról is a két régió között, mivel ezen komponensek hiányában a felálló szerverkörnyezet képtelen lett volna hitelesíteni a beérkező tranzakciókat.

A bevezetés másik kritikus eleme az automatizált forgalomirányítás kialakítása volt, amely biztosítja, hogy egy kiesés esetén a felhasználók zökkenőmentesen a másodlagos környezethez jussanak el. A projektcsapat olyan független DNS-failover mechanizmust épített ki, amely folyamatos egészségügyi ellenőrzésekkel figyeli az elsődleges régió válaszidejét, és hiba esetén automatikusan átirányítja a webes forgalmat a tartalék infrastruktúrára. Felmerült a több különböző felhőszolgáltató párhuzamos használatának gondolata is, azonban az alapos elemzés rávilágított, hogy a multi-cloud környezet drasztikusan növelte volna az integrációs bonyolultságot, a biztonsági kockázatokat és a szükséges szakértői csapat méretét. A vállalat ezért a jól kontrollálható, egyetlen szolgáltatón belüli, de két teljesen független európai zónacsoportra épülő struktúra mellett maradt.

A megvalósítás igazi próbáját az első tervezett katasztrófa-szimuláció jelentette, amely azonnal rávilágított az elmélet és a gyakorlat közötti szakadékra. A teszt során a mérnökök szimulálták az elsődleges régió teljes lekapcsolását, és bár a felhőszolgáltató szerződéses rendelkezésre állási mutatói papíron tökéletesek maradtak, a belső alkalmazások újraindítása az előre kalkulált egy óra helyett közel öt órát vett igénybe. Néhány elfelejtett függőség és egy elavult konfigurációs fájl megakasztotta az automatikus telepítést, ami éles helyzetben súlyos fennakadást okozott volna az értékesítésben. A hibák kijavítása és az automatizációs parancsfájlok finomhangolása után végrehajtott második teszt során azonban a kritikus rendszerek harmincöt perc alatt hibátlanul átálltak a másodlagos régióra, az adatvesztés mértéke pedig nem haladta meg a tizenöt percet, ami már tökéletesen megfelelt a vezetőség által elfogadott üzleti tűréshatárnak.

A tapasztalatok egyértelműen megmutatták, hogy a felhőalapú működés nem szünteti meg az infrastruktúra fizikai sérülékenységét és a geopolitikai kitettséget, csupán más szintre helyezi a védekezés feladatait. A hazai kkv-k számára a legfontosabb lépés nem a legdrágább technológiai megoldások azonnali megvásárlása, hanem a kritikus rendszerek pontos feltérképezése, az üzletileg indokolt helyreállítási célok kitűzése és a rejtett függőségek felszámolása. Egy dokumentált és rendszeresen elpróbált mentési és visszaállítási protokoll nagyságrendekkel több üzleti biztonságot nyújt, mint a szolgáltatói szerződésekben szereplő, papíron létező rendelkezésre állási garanciák. A modern informatikai ellenálló képesség nem technológiai luxus, hanem a felelős vállalatvezetés alapvető eszköze, amely garantálja, hogy a vállalat a globális digitális környezet váratlan megrázkódtatásai közepette is megőrizze működőképességét.

Megosztás

Kíváncsi, hogyan segíthetünk?


Ismerje meg saját fejlesztésű megoldásainkat, vagy beszéljük át a projektjét.

CraneFlow ERP Document Recognition Tool Szolgáltatások Kapcsolatfelvétel