Katasztrófa-elhárítási és üzletmenet-folytonossági terv

1. Katasztrófa-elhárítási és üzletmenet-folytonossági terv BME MIT Budapest, 2007. április

2. Motiváció • Cégek mind erősebben függenek az informatikától • Kötelező több területen • Bankok, biztosítók • PSZÁF megköveteli • ITIL része • USA • egészségügy (HIPAA) • Sarbanes-Oxley (SOX) előírások Budapest, 2007. április

3. Milyen tervek léteznek? • Disaster Recovery Plan • Business Continuity Plan • Business Contingency Plan • Nem teljesen egységes szakirodalom • Függ országtól, szakterülettől, stb. • A tervek nagy része táblázat • Beszállítók • Tevékenységek listája (checklist) … Budapest, 2007. április

4. Mi a katasztrófa? • NEM csak valamilyen hirtelen bekövetkező természeti csapás… • „Fennakadás a rendszer működésében, mely visszafordíthatatlan, elviselhetetlen károkat okoz” • „Intézmény vagy cég érdekeinek sérelme” • „Megfelelő szolgáltatás meghiúsulása” Budapest, 2007. április

5. Katasztrófák hatásai • A kisvállalatok 40%-a megszűnik, ha egy napon belül nem nyerik vissza adataikat • Gartner • A tűzesetek által sújtott vállalatok • 43%-a csődbe megy egy éven belül • további 35%-a 3 éven belül • U.S. National Fire Protection Agency Budapest, 2007. április

6. Terminológia (angol alapfogalmak) • Charter, Plan, Recovery Procedures • PPRT – People, Process, Resources, Technology • Classification: Type, Scope, Duration, Impact • Declaration: Legal and Financial Implications • Likelihood, Frequency, MTBF • RTO: Recovery Time Objective • RPO: Recovery Point Objective • Hot, Warm, and Cold Recovery • On-Site versus Off-Site (Escrow) • Failover versus Recovery Budapest, 2007. április

7. DRP részei • Rendszer leírása • Hivatkozásokkal rendszertérképre, üzleti folyamatokra, erőforrás táblázatokra, alkalmazottak, beszállítók, partnerek elérhetőségére, … • Elvárt rendelkezésre állás meghatározásával • Katasztrófák leírása • Megelőző intézkedések • Katasztrófa idején elvégzendő tevékenységek • Helyreállítás • Javítási javaslatok • Karbantartásra, tesztelésre vonatkozó előírások Budapest, 2007. április

8. Egy lehetséges metodika • Üzleti folyamatokból indulunk ki • Meghatározzuk a szükséges informatikai szolgáltatásokat • Meghatározzuk az ezekhez szükséges informatikai erőforrásokat • Eddig „top-down” • Felírjuk az esetleges katasztrófákat • Meghatározzuk az erőforrásokra és ezen keresztül a szolgáltatásokra gyakorolt hatást • Megnézzük, mi minősül kritikus eseménynek • Valóban katasztrófa • Idáig „bottom-up” Budapest, 2007. április

9. A folyamatok meghatározása • 1. Milyen üzleti folyamatok vannak a cégnél? • Pl. számlázás, online rendelésfelvétel, könyvelés, ügyfelek regisztrációja, adóbevallás elkészítése, új szerződések elkészítése, … • 2. Mi a folyamatok kiesésének következménye? • Adott szempontból • Felhasználók, ügyfelek, pénzügyi, jogi • Adott időtartamokra (1 nap - 1 hét - 1 hónap) • Adott súlyossággal (pl. skála 1-5) • „Worst case” elv (pl. adóbevallás esetén) • 3. Melyek lesznek a kritikusfolyamatok? • Hatás súlyossága meghalad egy értéket • Üzleti elemzés • MKB: 270 üzleti folyamat Budapest, 2007. április

10. Az informatikai szolgáltatások meghatározása • Milyen technológiai folyamatok vannak? • Levélküldés, fájlok elérése, archívum, szkennelt dokumentumok elérése, faxküldés, belső kommunikációs rendszer, vállalati portál, könyvelő rendszer, felhasználónyilvántartás, … • A komponensek rövid leírása • Mi a célja a működésnek? • Pl. „a korábbi szerződések gyors elérése” • IT határozza meg Budapest, 2007. április

11. Üzleti szolgáltatások – IT kapcsolat • A kritikus üzleti folyamatok milyen informatikai erőforrásokat használnak? • Ezzel szűkítjük a kört, de a cél nem az abszolút biztonság (ami nem érhető el), hanem az előírt biztonság • Üzlet és IT részleg közösen • Egy üzleti folyamat több informatikai szolgáltatást is használhat → Ezek lesznek a kritikus IT szolgáltatások • Maximum engedélyezett kiesés • Az üzleti folyamatok által tolerálható minimum • Pl. Számlázás használja (1 hét kiesés tolerálható) • Ügyfélregisztráció használja (1 hónap tolerálható) Budapest, 2007. április

12. Példa: üzlet – IT kapcsolat Budapest, 2007. április

13. IT erőforrások meghatározása • Szolgáltatásokból kiindulva • Hardver • Pl. XXX szerver • Szoftver • Windows 2003 SR2 szerver • Képfeldogozó alkalmazás • Egyéb • Pl. Kábelek • „Melléktermék”: elavult, felesleges erőforrások • Rendszer térképpel összevetve • „Mire használjuk ezt a 10 éves Sun Solaris szervert?” Budapest, 2007. április

14. Humán és egyéb erőforrások • Szerepkörök megnevezése • Szükséges vizsgákkal • Pl. „CISCO Certified” hálózati mérnök • Aktuális alkalmazottak • Elérhetőséggel • Munkaidő adataival • Ld. Szerepkör alapú rendszermenedzsment • Pl. IBM Tivoli Identity Manager • Elérhető külső support • Pl. XXX cég biztosít CISCO mérnököt Budapest, 2007. április

15. Tartalék erőforrások • Hardver erőforrások • Pl. switch, szalagos egység, szervergép • (Szerver) szoftver erőforrások • Pl. tartalék Windows 2003 szerver feltelepítve • Alkalmazások hideg tartalékai • Pl. képfeldolgozó alkalmazás a Windows2003 szerveren • Különbségek: • Hely: fizikailag elkülönítve (pl. szerverszoba) • Lehetséges, hogy nem lesz elég (pl. Windows 2003 szerver), kiderül az analízis során Budapest, 2007. április

16. Rendszertérkép felírása • A rendszer komponensei függőségekkel • Egy-egy komponens egy IT szolgáltatás • Szerverek megnevezve Budapest, 2007. április

17. Példa Budapest, 2007. április

18. Interfészek felírása • Az egyes komponensek hogyan kapcsolódnak egymáshoz • Pl. tárolt eljárások, adatbázis táblák, konverter programok, batch programok, reportok, Webszolgáltatások • Mire van szükségünk, hogy a külön-külön helyreállított komponensek együttesen is működjenek Budapest, 2007. április

19. IT erőforrásigény • A kritikus üzleti folyamatokat kiszolgáló IT alkalmazások igényei • Az előbb leírt erőforrásokra Budapest, 2007. április

20. Példa (erőforrások leírása) Budapest, 2007. április

21. Hibafa elemzés • Komponensek hibája • Egyszerűség kedvéért egy SRU kiesése • „VAGY” kapuk • „ÉS” kapuk Budapest, 2007. április

22. Példa • Exchange szerver hibafája • Több szerver feltételezve… • Eddig: rendszer leírása • Innentől: környezetet is figyelembe vesszük Budapest, 2007. április

23. Katasztrófák felírása • Fajták szerint • Természeti katasztrófák • Tűz, villám, stb. • Műszaki katasztrófák • Áramkorlátozás, vírusok, épület klímája kikapcsol, stb. • Humán katasztrófák • Szándékos rongálás, sztrájk, stb. Budapest, 2007. április

24. Katasztrófák hatása az erőforrásokra • Adott katasztrófa milyen erőforrásokra hat • „Worst case” elv • Minden leég az adott épületrészben • Azonos hatású katasztrófákat a továbbiakban együttesen kezeljük • Pl. épület leégése = földrengés (hatás) Budapest, 2007. április

25. Helyreállítás lépései • Azonnali reakciók • Környezeti helyreállítás • Funkcionális helyreállítás • Áttelepülés • Normalizáció Budapest, 2007. április

26. Riasztási lánc definiálása Budapest, 2007. április

27. Helyreállításhoz szükséges lépések • Példa: Exchange szerver helyreállítása • Előfeltétel: működőképes Windows szerver • Pl. tartalék a másik telephelyen • Előfeltétel2: felhasználói adatok elérhetőek • Pl. tartalék Domain Controller • Tartalék Exchange szerver beüzemelése • Autentikáció a tartalék Domain Controllerrel • Felhasználói accountok létrehozása • Adatok visszatöltése Budapest, 2007. április

28. Az előbbi lépések kiegészítése • Végrehajtási idő • Pl. várhatóan legalább 2 óra • Végrehajtáshoz szükséges személyzet • Pl. 1 operátor, 1 MS### vizsgával rendelkező mérnök • Egyéb szükséges adatok • Pl. szalagos mentés • Helyreállítás korlátai • Pl. utolsó X nap levelei elveszhetnek Budapest, 2007. április

29. Megfelelünk-e a követelményeknek? • Lehetséges-e • az adott rendszerkonfigurációban • az összes katasztrófa esetén • az összes (kritikus) erőforrás helyreállítása • a maximálisan tolerált kiesési idő alatt? • Ha nem • Mit kell módosítani a rendszeren? • Konfiguráción? • Alkalmazásokon? • Mennyi idő/pénz kell ehhez? • Milyen egyéb (szervezeti) változások kellenek? • Ha igen: ? Budapest, 2007. április

30. DRP-vel kapcsolatos teendők • Betanítás • Mit kell tudnia a „normál” személyzetnek? • Humán tartalékok felkészítése • Tesztelés • Végrehajthatóak-e a forgatókönyvek? • Karbantartás • Rendszeres időközönként • Pl. évente be kell újra adni • Adott események/változások hatására • A normál „változás menedzsment” része Budapest, 2007. április

31. Példa DRP (más metodika) • Section 1 Introduction • Section 2 Document Control • Section 3 Recovery Phase 1 Vigilance, Identification, Categorization and Declaration • Section 3 Recovery Phase 2 Initial Recovery – Partial Capacity • Section 3 Recovery Phase 3 Full Recovery – Full or Required Capacity • Section 3 Recovery Phase 4 Stand Down – Return to Normal Operations, Deactivation of Recovery • Section 3 Recovery Phase 5 After Action Review and Plan Revision • Section 4 References and Resources • Section 5 Directory of Appendices • Section 5-1 Appendix 1 Staff Contact List – and Kris-Cross Calling Tree • Section 5-2 Appendix 2 Vendor Contacts • Section 5-3 Appendix 3 Communication Plan • Section 5-4 Appendix 4 Platform Specifications and Vendor Re-Order Forms • Section 5-5a Appendix 5a Platform Description – Install and Configuration • Section 5-5b Appendix 5b 2K3 Server – Install and Configuration • Section 5-5c Appendix 5c DB Server – Install and Configuration • Section 5-5d Appendix 5d Web Server – Install and Configuration • Section 5-5e Appendix 5e Rpt Server – Install and Configuration • Section 5-5f Appendix 5f Application – Install and Configuration • Section 5-6 Appendix 6 Back Up and Restore Schema • Section 5-7 Appendix 7 Network Schema Budapest, 2007. április

32. BCP feladata • Üzletmenet folytonosságának garantálása • Amivel több, mint DRP: üzleti szinten kínál alternatívát • Pl. ne vigyük fel a rendeléseket a rendszerbe, gyűjtsük papíron • Előny: • Kifele kevesebb kiesési idő • Csökkentett módú működés biztosítható • Hátrány: • Szinkronizáció szükséges a visszaállításkor • Erőforrásigény Budapest, 2007. április

33. Milyen károkat próbál csökkenteni? • Üzleti folyamat hibái • Ellenőrizetlen folyamatok • Ügyfélszolgálat leállása • Cég jó hírnevének csorbulása • Bevételkiesés • Nem csak informatikai szempontok… Budapest, 2007. április

34. Technológiai kitekintés • Disaster Recovery megoldások • IBM Tivoli Disaster Preparation Solution • Continous Data Protection for Files • Storage Manager Extended Edition • Elsődlegesen adatok védelme • IBM Tivoli Identity Manager • Szerep alapú hozzáféréskezelés • Workflow lehetőség • Pl. ha nincs DatabaseManager, szól az adminisztrátornak • Emberi erőforrások átcsoportosítása támogatható Budapest, 2007. április

35. Technológiai kitekintés 2. • DRP támogatás szerver virtualizációval • VMWare • Virtouzzo • Xen • Virtual server • Solaris Containers • Double Take • Windows 2000 szerver megoldás • SunGard Paragon család • Klaszter megoldások • …. Budapest, 2007. április

36. Források • The Disaster Recovery Handbook: A Step-by-Step Plan to Ensure Business Continuity and Protect Vital Operations, Facilities, and Assets (Hardcover) by Michael Wallace, Lawrence Webber. ISBN: 0814472400 • http://biztostu.hu/ • Katasztrófa-elhárítás munkafolyamatokban. BME tanulmány. • Business ContinuityandDisaster Recovery. Pres. Of Mike Wade, Southern Polytechnic State University • Az informatikai biztonság irányításának követelményrendszere. Információs Társadalom Koordinációs Tárcaközi Bizottság ajánlása, 2004. • Disaster Recovery Journal. • http://www-306.ibm.com/software/tivoli/solutions/disaster/ • http://www.availability.sungard.com/ • http://www.swsoft.com/ • http://www.lyonware.co.uk/Disaster-Recovery-Software/Disaster-Recovery-Software.htm Budapest, 2007. április