Olukord
Marijampolė toidutootja, ligikaudu 250 töötajat, töötab kahes vahetuses ja varustab jaekettide ranged tarneaknad. IT-taristu on tootmisettevõttele tüüpiline: mitu virtualiseeritud serverit, millel töötavad ERP ja laosüsteemid, eraldi tootmisliinide juhtimisserverid tootmisvõrgus, paarkümmend töökohta, võrguseadmed koos kontori ja tootmise vaheliste VLAN-segmentidega ning Microsoft 365 e-posti ja dokumentide jaoks.
Varukoopiad olid olemas, kuid ainult serveritest: Veeam tegi virtuaalmasinate varukoopiaid kohalikku salvestusse samas serveriruumis. Liinide juhtimisservereid ei varundatud, sest neid hooldas seadmetarnija ja keegi ei olnud kindel, kas see on lubatud. Võrguseadmete seadistusi ei hoitud kusagil mujal kui seadmetes endis. Microsoft 365 peeti „Microsofti murreks“. Taastet ei olnud kunagi testitud.
Meiega võeti ühendust kahel põhjusel. Esiteks küsis jaeketi audit tõendit, et ettevõte suudab pärast intsidenti tegevust jätkata, ning „meil on varukoopiad“ ei olnud piisav vastus. Teiseks seisis ühe võrgulüliti rikke korral tootmisvõrk pool vahetust, kuni selle seadistust mälu järgi taastati. Tootmisjuht esitas lihtsa küsimuse: kui serveriruum oleks homme kadunud, kui kaua läheks aega, enne kui saame uuesti toota?
Mida oli vaja
- Kogu taristu varukoopiad: serverid, liinide juhtimisserverid, töökohad, võrguseadmete seadistused, Microsoft 365.
- Vähemalt üks koopia väljaspool tehast ja ettevõtte võrgust kättesaamatu.
- Kokkulepitud ja testitud taasteaeg kriitilistele süsteemidele, mille järgi saab tootmist planeerida.
- Taastekoht juhuks, kui ettevõtte enda seadmed kaoksid.
- Dokumenteeritud katsed ja aruanne, mida saab audiitoritele anda.
Mida me tegime
Nädalad 1–2: inventuur ja kriitilisuse nimekiri
Kirjutasime üles kõik, millel on IP-aadress, ning koos tootmise, logistika ja rahanduse juhtidega kindlaks, kui kaua ettevõte saab iga süsteemita töötada. Kriitilisteks osutusid kolm: ERP, laosüsteem ja liinide juhtimisserverid. Nende jaoks leppisime kokku 4-tunnise taaste-eesmärgi, ülejäänute jaoks järgmise tööpäeva. See nimekiri sai hiljem katse stsenaariumiks.
Nädalad 3–6: kogu taristu varukoopiad
Kujundasime serverite varundamise ümber 3-2-1 põhimõtte järgi: Veeami varukoopiad kohapeal, teine koopia MDP CLOUD andmekeskuses Leedus ning kolmas koopia, mis on muutumatu ja võrgus nähtamatu ning mille juurde ei pääseks lunavara isegi administraatoriõigustega. Liinide juhtimisseadmete tarnijaga leppisime kokku, et nende servereid varundatakse öise pausi ajal andmebaasi kirjutamine peatatuna. See võttis kõige kauem aega, sest vaja oli tarnija kirjalikku kinnitust.
Alustasime võrguseadmete seadistuste automaatset kogumist igal õhtul samasse varukoopiahoidlasse, koos muudatuste ajalooga. Spetsiaaltarkvaraga töökohtadest (kaalud, siltide printimine) tegime kujutisvarukoopiad. Microsoft 365 e-posti, OneDrive’i ja SharePointi panime eraldi Microsoft 365 varundamisse, sest Microsoft säilitab kustutatud andmeid ainult piiratud aja ega kata kõiki stsenaariume.
Nädalad 7–8: PlanB
Kriitiliste süsteemide jaoks valmistasime ette PlanB: eelseadistatud keskkonna MDP CLOUD pilves, kuhu ERP ja laosüsteemi saab varukoopiatest üles tuua ilma riistvara ostmata. Keskkond ootab väljalülitatuna, kuni seda vaja on; sisselülitamisel ühenduvad töötajad VPN-iga igast asukohast.
Nädalad 9–10: katsed
Esimene katse toimus nädalavahetusel: simuleerisime serveriruumi kadumist ja taastasime kolm kriitilist süsteemi PlanB keskkonnas. Esimene katse võttis veidi üle 4 tunni, sest ERP litsentsifail osutus seotuks vana serveri nimega. Parandasime korra ja kordasime katset kaks nädalat hiljem, ning seekord saavutasime eesmärgi. Eraldi taastasime ühe lüliti seadistuse varuseadmele. See võttis umbes 20 minutit, mitte pool vahetust.
Tulemus
Kriitiliste süsteemide taaste on testitud 4 tunniga, mis ei ole enam eesmärk, vaid katse aruandes fikseeritud fakt. Andsime jaeketi audiitoritele katse aruande, varundamise poliitika ja taastekorrad ning küsimusi ei jäänud.
Kõik võrguseadmete seadistused, 100%, on salvestatud igapäevase ajalooga. Muudatus, mille keegi teisipäeval lülitil tegi, on kolmapäeval nähtav ja vajadusel tagasi pööratav.
Taastekatsed toimuvad kaks korda aastas kokkulepitud ajakava järgi, iga kord erineva stsenaariumiga: serverite kadumine, lunavararünnak, Microsoft 365 konto kustutamine. Iga katse aruanne läheb juhtkonnale ja seda hoitakse auditite jaoks.
„Esimest korda on meil vastus küsimusele „kui kaua läheks aega, enne kui saame uuesti toota“ ja see tuleb aruandest, mitte kellegi peast.“
Mida soovitaksime sarnases olukorras
- Testimata taastega varukoopiad on oletus, mitte kaitse. Esimene test toob peaaegu alati välja midagi, mida te ei teadnud.
- Võtke inventuuri kõik, millel on seadistus, mitte ainult serverid: lülitid, tulemüürid, kaalud, printerid.
- Leppige tootmisseadmete varundamine seadmetarnijaga kirjalikult kokku enne intsidenti.
- Seadke taaste-eesmärk koos tootmise ja rahanduse juhtidega, mitte IT-osakonnas: nemad teavad, mis maksab tund seisakut.
