ISO 27031: Aktivacija plana i sadržaj IKT plana oporavka (klauzula 10.2–10.3)

10.2 – Aktivacija plana oporavka

Aktivacija IKT plana kontinuiteta je deo šire BCM strukture cele organizacije i primenjuje se kad ozbiljan incident pogodi IT operacije. Odluka o aktivaciji donosi se prema mandatu koji je postavio BCM; IT menadžment aktivira odgovarajući plan zavisno od prirode incidenta prema IRBC-u. Standard opisuje tok odluke:

• upravljanje incidentima utvrđuje da je incident ozbiljan i IT-vezan
• obaveštava IT menadžment i/ili krizni menadžment po potrebi
• ovlašćeni menadžment odlučuje da aktivira IKT plan
• planovi za druge delove organizacije takođe mogu biti aktivirani ako je krizni menadžment već aktivan

Eskalacija od upravljanja incidentima ka IRBC-u je proces koji podiže odgovornost i ovlašćenje na viši nivo, i zavisi od kriterijuma koje postavljaju i upravljanje incidentima i IRBC menadžment zajedno – kriterijumi treba da uzmu u obzir vreme potrebno da se incident reši u odnosu na RTO, i razmeru uticaja na kontinuitet poslovanja. Treba postojati proces koji obezbeđuje brz prenos odgovornosti u oba smera – i eskalaciju i de-eskalaciju. Kad se kriza završi, moguće je da incident još nije formalno rešen, posebno ako su u rešavanju učestvovali spoljni resursi i timovi – koordinator incidenata treba da preuzme kontrolu nazad da bi dovršio izveštaj o incidentu i pripremio preporuke za unapređenje.

Ovo daje konkretan, korak-po-korak odgovor ne samo na pitanje kada se nešto eskalira, nego i kako tačno taj tok izgleda, i, podjednako bitno, kako se odgovornost vraća nazad kad se kriza reši. De-eskalacija se često potpuno zaboravi – firme znaju kako da uđu u krizni režim, ali retko imaju definisan način da iz njega izađu i formalno zatvore incident.

Primer: Kod VoxServis-a, ovaj tok bi trebalo da izgleda ovako: upravljanje incidentima (IT podrška) prepoznaje da agenti masovno ne mogu da se uloguju kao ozbiljan, IT-vezan incident, obaveštava formalno imenovanog IRBC vlasnika, ta osoba, sa unapred datim ovlašćenjem, odlučuje da aktivira IKT plan, koristeći kao kriterijum upravo razliku između ugovorenog RTO (30 minuta) i realnog stanja. Kad se sinhronizacija vrati, formalna de-eskalacija predaje odgovornost nazad koordinatoru incidenata, koji piše izveštaj i predlaže unapređenja – korak koji VoxServis nikad nije formalno sproveo. Bez zapisanog izveštaja, pouke iz incidenta ostaju u nečijem sećanju, ne u sistemu.

Šta treba uraditi

• Definisati tok odluke o aktivaciji sa jasno imenovanim ulogama u svakom koraku – ko prepoznaje, ko obaveštava, ko odlučuje.
• Postaviti kriterijume eskalacije vezane za RTO i razmeru uticaja, ne prepustiti procenu trenutnom osećaju ozbiljnosti.
• Definisati proceduru de-eskalacije sa obaveznim izveštajem o incidentu i predlogom unapređenja – ne samo proceduru ulaska u krizni režim.
• Izbegavati najčešću grešku – jasan način da se "uđe" u krizni režim, ali nikad definisan način da se iz njega formalno "izađe", pa se incident prosto prestane pominjati čim je gašen.

10.3.1 – RPO i RTO planovi za IT

IT RPO i RTO treba uspostaviti za svaki proizvod, uslugu i aktivnost, i umnožiti na više lokacija i u različitim vrstama nosača, tako da svaka osoba sa odgovarajućom odgovornošću ima najprikladniju podršku na raspolaganju kad i ako zatreba.

Plan sačuvan isključivo na serveru koji je upravo otkazao, ili na cloud disku do kog se ne može doći bez sistema koji je upravo nedostupan, jeste čest i skup propust. Standard ga pretvara u eksplicitan zahtev: plan mora biti dostupan nezavisno od toga šta je otkazalo.

Primer: Ako je uputstvo za oporavak domenskog kontrolera kod VoxServis-a sačuvano samo u internom wiki-ju koji zahteva prijavu putem – pogađate – istog tog domenskog kontrolera, plan postaje nedostupan tačno u trenutku kad je najpotrebniji.

Šta treba uraditi

• Za svaki kritičan plan oporavka, obezbediti bar jednu kopiju van lanca zavisnosti koji plan opisuje – odštampanu, na ličnom uređaju odgovorne osobe, ili na sistemu koji ne zavisi od iste autentifikacije koja bi mogla da padne.
• Napraviti spisak lokacija/formata na kojima svaki plan postoji – elektronski na nezavisnom sistemu, štampana kopija, itd.
• Redovno proveravati da li su sve kopije ažurne – zastareo plan na sigurnom mestu je jednako beskoristan kao nepostojeći plan.
• Izbegavati najčešću grešku – plan koji postoji samo na jednom mestu, i to često tačno na sistemu ili nalogu koji zavisi od iste infrastrukture čiji je upravo pao.

10.3.2 i 10.3.3 – Objekti i tehnologija: vrući, topli i hladni standby

Sistemi za oporavak i kritičan bekap podataka treba, gde god je moguće, da budu fizički odvojeni od operativne lokacije, kako ih isti incident ne bi pogodio zajedno sa primarnim sistemom. Tehnološki planovi mogu se osloniti na jedan ili više od pet obrazaca:

• vrući standby – IT infrastruktura se replicira preko dve geografski razdvojene lokacije, spremna da preuzme odmah
• topli standby – oporavak se dešava na sekundarnoj lokaciji gde je IT infrastruktura delimično pripremljena, uz potrebno vreme za dovršenje
• hladni standby – infrastruktura se gradi ili konfiguriše od nule na alternativnoj lokaciji tek kad zatreba
• ship-in aranžmani – spoljni pružaoci usluga isporučuju hardver po potrebi
• kombinovan pristup – meša prethodne obrasce po potrebi za različite servise

Ovo je ista terminologija hladno/toplo/vruće koju smo videli kod planiranja redundanse opreme, samo sad primenjena na nivou cele lokacije, ne pojedinačne komponente. Razlika je bitna: možete imati vrući standby za jedan kritičan server, a hladni standby za celu zgradu u kojoj taj server sedi – izbor na nivou objekta i izbor na nivou komponente su odvojene odluke koje treba svesno da se poklope.

Primer: Za identitetsku zavisnost, VoxServis sad ima jasan izbor pred sobom. Vrući standby (drugi domenski kontroler u Novom Sadu, kontinuirano repliciran) je najbrži, ali i najskuplji – verovatno prekomeran s obzirom na to da ugovoreni RTO od 30 minuta ostavlja malo, ali ne nulto vreme za reakciju. Hladni standby je najjeftiniji, ali definitivno presporo za 30-minutni rok. Topli standby – sekundarni kontroler koji već postoji i radi u ograničenom kapacitetu u Novom Sadu, ali zahteva par minuta da se promoviše u punu ulogu – deluje kao razuman kompromis: dovoljno brzo da ispuni rok, bez plaćanja pune cene vrućeg standby-ja koji možda nije neophodan.

Šta treba uraditi

• Za svaku kritičnu komponentu i lokaciju, izabrati obrazac (vrući/topli/hladni/ship-in/kombinovan) sa eksplicitnim obrazloženjem zašto taj nivo odgovara RTO zahtevu.
• Potvrditi fizičku odvojenost sistema za oporavak od operativne lokacije – ne samo logičku odvojenost u istoj prostoriji.
• Razdvojiti odluku na nivou objekta od odluke na nivou komponente – jedno ne garantuje drugo.
• Izbegavati najčešću grešku – izbor između vrućeg, toplog i hladnog standby-ja donet na osnovu onoga što je "uobičajeno" ili što je prodavac preporučio, a ne na osnovu stvarnog RTO zahteva te konkretne komponente.

10.3.4 – Podaci

Aranžmani za dostupnost identifikovanih podataka treba da budu usklađeni sa IRBC strategijama, uključujući:

• dodatno skladište za podatke u formatu koji obezbeđuje njihovu dostupnost u skladu sa izabranim strategijama
• definisanje alternativnih lokacija za skladištenje podataka, fizičkih ili virtuelnih, uz očuvanu bezbednost i poverljivost – sa odgovarajućim procedurama pristupa, i, ako je aranžman kroz treću stranu, vlasnici informacija treba sami da se uvere da su kontrole tamo adekvatne

Poslednji deo – da se vlasnici informacija sami uvere da su kontrole treće strane adekvatne – je bitan: nije dovoljno pretpostaviti da cloud provajder "sigurno ima to rešeno". Standard eksplicitno traži aktivnu proveru, ne pasivno poverenje.

Primer: Podaci domenskog kontrolera kod VoxServis-a trenutno nemaju definisanu alternativnu lokaciju skladištenja – ako propadne i primarna instanca i njen lokalni bekap istovremeno, nema treće kopije. Za cloud CRM podatke, VoxServis se oslanja na dobavljačevu infrastrukturu bez ikad tražene potvrde da su njihove kontrole pristupa i skladištenja zaista adekvatne za VoxServis-ove potrebe.

Šta treba uraditi

• Definisati alternativnu lokaciju skladištenja za svaki kritičan tip podataka, fizičku ili virtuelnu.
• Za svaku treću stranu koja skladišti podatke u ime firme, aktivno tražiti i pregledati dokaz da su njene kontrole adekvatne – ne osloniti se samo na ugovornu klauzulu.
• Proveriti da li postoji treća kopija podataka za slučaj da i primarna instanca i njen lokalni bekap propadnu istovremeno.
• Izbegavati najčešću grešku – alternativnu lokaciju za podatke koja postoji "u teoriji" (cloud provajder to sigurno radi), bez ikad tražene ili pregledane potvrde da su kontrole tamo stvarno adekvatne.

10.3.5 i 10.3.6 – Procedure odgovora i oporavka, i ljudi

IRBC procedure treba jasno i dovoljno detaljno dokumentovati da omoguće kompetentnom osoblju da ih izvrši – uz napomenu da se neke procedure razlikuju od svakodnevnog rada. Procedure mogu zavisiti od situacije koja se odvija; u praksi ih je moguće prilagoditi s obzirom na razmeru poremećaja (stepen gubitka ili štete), operativne prioritete organizacije, ili zahteve zainteresovanih strana. Uz to, ključno je da organizacija obezbedi neophodne ljudske resurse za izvršavanje kritičnih aktivnosti i pomoć u radu IRBC-a, uz obučeno osoblje koje može da preuzme dodatne dužnosti u trenutku aktivacije IRBC-a.

Ovo je formalna definicija onoga što VoxServis-u nedostaje – "tehnički ispravan, ali potpuno beskoristan" DR plan. Detaljnost bez fleksibilnosti daje krut dokument koji puca čim se stvarnost i najmanje razlikuje od pretpostavljenog scenarija; fleksibilnost bez detaljnosti daje improvizaciju koja liči na ono što se stvarno desilo.

Primer: Ono što se desilo posle pada domenskog kontrolera kod VoxServis-a nije bilo izvršenje dokumentovane procedure – bila je improvizacija ljudi koji su, uz najbolje namere, pokušavali da smisle rešenje u hodu. Ne postoji zapisan, dovoljno detaljan postupak koji bi kompetentna osoba mogla da sledi korak po korak. Isto tako, niko nije formalno oslobođen redovnih obaveza da pomogne – ljudi su radili na incidentu pored svog običnog posla, ne umesto njega, što je usporilo i jedno i