Határozza meg a kritikus folyamatokat, valamint a helyreállítási idő és a helyreállítási pont célértékeit, térképezze fel az összes függőséget, készítsen független biztonsági mentéseket és pontos runbookot. A helyreállítást rendszeresen gyakorolja izolált környezetben, ellenőrizze az adatok integritását és a hozzáféréseket, incidens után pedig szervezetten kommunikáljon, váltson át, és értékelje a tapasztalatokat.
A katasztrófa utáni helyreállítás azokra a helyzetekre ad megoldást, amikor egy szokásos újraindítás vagy egy javítás telepítése nem elegendő. Ilyen lehet a sérült adat, egy elérhetetlen régió, a hibás konfiguráció, egy fiók elvesztése vagy egy nagyobb biztonsági incidens. A mentés puszta léte nem jelenti azt, hogy az alkalmazás a cég számára szükséges sorrendben, időn belül és minőségben helyreállítható.
A disaster recovery terv összekapcsolja az üzleti prioritásokat a technikai valósággal. Meghatározza, mely képességek állnak helyre elsőként, a legutóbbi adatok mekkora vesztesége elfogadható, ki dönt, és hogyan ellenőrizhető a szolgáltatás helyes működése. Ki kell terjednie az identitásokra, a titkokra, a külső integrációkra, a domainekre, a kommunikációs csatornákra és az emberekre is, nem csak az adatbázisra és az alkalmazás kódjára.
Fordítsa le a kiesés hatását helyreállítási célokra
Először derítse ki, mely felhasználói és belső tevékenységek időkritikusak. A bejelentkezésnek, a rendelés fogadásának és egy historikus riportnak nem feltétlenül azonos a prioritása. A Recovery Time Objective a képesség helyreállításának célidejét fejezi ki, a Recovery Point Objective pedig azt az elfogadható pontot, ameddig az adatok visszaállíthatók. Az értékek a hatásból és a lehetőségekből fakadnak, nem egy univerzális sablonból.
Különböztesse meg a minimális vészüzemet a teljes helyreállítástól. Előfordulhat, hogy a cégnek először az új kérések biztonságos fogadására van szüksége, és csak később a kevésbé fontos jelentések elérhetővé tételére. Minden célhoz rendeljen felelőst és ellenőrzési módot. Ha egy követelmény nem összeegyeztethető az architektúrával vagy a költségvetéssel, oldja fel az ellentmondást még az incidens előtt, és nyíltan dokumentálja a fennmaradó kockázatot.
Térképezze fel a komponenseket és a rejtett függőségeket
A leltár kiterjed az alkalmazásra, az adatbázisra, a fájlokra, a sorokra, a keresési indexre, a konfigurációra, a DNS-re, a tanúsítványokra, az identitásokra, a titkokra és a monitoringra. Minden tételnél adja meg a létrehozás, a mentés és a helyreállítás módját, valamint a szükséges jogosultságot. A külső szolgáltató elérhető lehet, de az Ön fiókja, webhookja vagy engedélyezett címe a helyreállítás után nem feltétlenül működik.
Határozza meg a sorrendet. Az adatbázis előtt elindított alkalmazás hibás feladatokat hozhat létre, a titkok visszaállítása előtt elindított integráció pedig elárasztja a várakozási sort. A kódban definiált infrastruktúra segít a környezet helyreállításában, de védett repozitóriumot és a sérült fióktól független hozzáférést igényel. A kritikus kapcsolattartók és a dokumentáció nem lehetnek elérhetők kizárólag azon a rendszeren keresztül, amelyet éppen helyreállít.
- adatok, fájlok és állapotfüggő szolgáltatások
- fiókok, jogosultságok, tanúsítványok és titkok
- domainek, hálózat és külső integrációk
- monitorozás, dokumentáció és kommunikációs kapcsolattartók
Tervezze a mentéseket a visszaállítás részeként
A mentéshez meghatározott terjedelem, gyakoriság, titkosítás, megőrzési idő és az elsődleges környezettől való elkülönítés szükséges. Védje meg ugyanattól a hibától vagy kompromittálódástól, amely az éles környezetet érinti. Ne csak a feladat elindulását ellenőrizze, hanem a befejezését és az olvashatóságot is. Több visszaállítási pont megőrzése segít, ha a sérülést csak később veszik észre.
A visszaállított adatbázisnak meg kell felelnie az alkalmazás verziójának és a sémamigrációknak. A fájlok, a keresési index és a sorban lévő események eltérő időpontból származhatnak, ezért a tervnek foglalkoznia kell az összehangolásukkal. Az érzékeny mentéseket megfelelő védelem nélkül ne használja rutinszerű tesztelésre. Az életciklus végén történő biztonságos törlés ugyanennek a folyamatnak a része.
Írjon runbookot, és végezzen visszaállítási próbát
A runbook tartalmazza az indítási feltételeket, a döntési szerepköröket, a pontos lépéseket, a szükséges hozzáféréseket, az ellenőrzéseket és azokat a pontokat, ahol az eljárás leállítható. A parancsokat és hivatkozásokat az adott komponenseknél tartsa nyilván. Számoljon azzal, hogy a fő adminisztrátor nem feltétlenül lesz elérhető. Az érzékeny értékeket ne írja közvetlenül a dokumentumba; adja meg a beszerzésük biztonságos módját.
A próba célja, hogy a szolgáltatást valós típusú mentésből egy izolált környezetbe állítsa helyre. Mérje a folyamat időtartamát a belső tervezéshez, de főként ellenőrizze a bejelentkezést, a kulcsfolyamatokat, a jogosultságokat, az adatok konzisztenciáját és a kapcsolódásokat. A teszt kudarca hasznos megállapítás, ha az eljárás javításához vezet. Az asztali gyakorlat nem helyettesíti a technikai helyreállítást, de próbára teszi a döntéshozatalt és a kommunikációt.
Kezelje az incidenst, a visszaállítást és az utólagos felülvizsgálatot
Incidens idején vezessen egyetlen megbízható nyilvántartást a döntésekről, a felelősökről és az aktuális állapotról. A felhasználóknak szóló kommunikáció legyen tárgyszerű, és ne ígérjen olyan határidőt, amelyet a csapat nem tud alátámasztani. Az üzem újraindítása előtt ellenőrizze a biztonságot, az integritást és az ügyfélszolgálat felkészültségét. A helyreállított szolgáltatás átmenetileg korlátozásokkal működhet, amelyeket láthatóan meg kell nevezni és nyomon kell követni.
A stabilizálás után egyeztesse a tartalék üzemmódban keletkezett eseményeket, állítsa helyre a védelmi mechanizmusokat, és ellenőrizze a szokatlan hozzáféréseket. Az utólagos felülvizsgálat elkülöníti az okot, a hatást és a helyreállítás gyengeségeit. Frissítse a runbookot, az architektúrát, a kapcsolattartókat és a képzést is. A terv csak addig érvényes, amíg megfelel a mai szolgáltatásnak, és a csapat képes végrehajtani.
Gyakori kérdések
Ugyanaz a katasztrófa utáni helyreállítás, mint a magas rendelkezésre állás?
Nem. A magas rendelkezésre állás a szokásos meghibásodások hatását korlátozza, míg a disaster recovery a súlyos esemény utáni helyreállítással foglalkozik. Kiegészíthetik egymást, de eltérő forgatókönyveik, döntéseik és tesztjeik vannak.
Elég rendszeresen ellenőrizni, hogy elkészült-e a biztonsági mentés?
Nem. Ellenőrizni kell az olvashatóságot, és el kell végezni a visszaállítást, beleértve az alkalmazást, a hozzáféréseket és a függőségeket. Egy sikeres mentési fájl még nem igazolja sem az adatok konzisztenciáját, sem a működő felhasználói folyamatot.
Milyen gyakran kell tesztelni a webalkalmazás helyreállítását?
Az intervallum a kockázatból, a változások gyakoriságából és az elvárt célokból adódik. A tesztet ismételje meg az architektúra, a szolgáltató, az adatmodell vagy a felelős csapat jelentős változása után is.
Források és további olvasnivaló
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
