ISO 27031: Tehnologija, podaci, procesi i dobavljači (9.2.4–9.2.7)

9.2.4 – Tehnologija

IT servisi od kojih zavise prioritetni procesi treba da budu dostupni unapred, pre nego što se dependentne poslovne aktivnosti vrate u pogon – rešenja moraju da obezbede dostupnost aplikacija u okviru RTO vrednosti određenih kroz BIA. Standard nabraja trinaest faktora koje treba razmotriti pri izboru tehnološke IRBC strategije:

• RTO i RPO vrednosti za kritične IT servise
• lokacija i udaljenost između tehnoloških lokacija
• broj tehnoloških lokacija
• udaljeni pristup sistemima
• zahtevi hlađenja
• zahtevi napajanja
• bezbednosni zahtevi
• korišćenje neposedovanih ("mračnih") lokacija naspram lokacija sa osobljem
• telekomunikaciona povezanost i redundantno rutiranje
• priroda "failback-a" – da li je za aktivaciju alternativnog IT rešenja potrebna ručna intervencija ili se to dešava automatski
• potreban nivo automatizacije
• zastarelost tehnologije
• povezanost eksternog pružaoca usluga i druge spoljne veze

Ova lista je vredna jer prisiljava na pitanja koja se inače retko postavljaju eksplicitno – posebno pitanje "failback-a": čak i kad je failover (prelazak na alternativu) dobro isplaniran, retko ko unapred definiše da li je povratak na primarni sistem ručan ili automatski, a razlika značajno menja i rizik i potrebnu obuku osoblja.

Primer: Kod VoxServis-ove zavisnosti identiteta, udaljenost između lokacija (Beograd i Novi Sad) je dovoljno razdvojena geografski, ali nikad nije provereno da li dele istog telekom operatera na poslednjoj milji. Telekomunikaciona povezanost i redundantno rutiranje: VoxServis trenutno ima jednu vezu između lokacije i cloud okruženja – tačno faktor koji ovaj deo standarda eksplicitno traži da se razmotri, a koji je do sad ostao nerazmotren. Priroda failback-a: čak i kad bi VoxServis uveo drugi domenski kontroler u Novom Sadu, nikad nije definisano da li bi povratak primarne uloge Beogradu bio automatski (rizičnije, ali brže) ili bi zahtevao svesnu odluku administratora (sporije, ali sigurnije) – ovo pitanje trenutno nema odgovor, jer scenario nikad nije ni postojao.

Šta treba uraditi

• Za svaku kritičnu tehnološku komponentu proći kroz relevantne od trinaest faktora i zapisati odgovor za svaki – posebno broj i udaljenost lokacija, redundansu telekomunikacione veze, i da li je failback ručan ili automatski, sa jasnim obrazloženjem izbora.
• Konkretno proveriti da li dve "razdvojene" lokacije dele istog telekom dobavljača za vezu ka spoljnom svetu – redundansa servera ne pomaže ako je veza jedinstvena tačka otkaza.
• Doneti eksplicitnu odluku o failback-u pre nego što scenario stvarno nastupi – ne prepustiti tu odluku administratoru da je improvizuje usred krize.
• Izbegavati najčešću grešku – da redundantna infrastruktura postoji na dve lokacije, ali obe dele istu mrežnu vezu ili istog telekom dobavljača, pa jedna tanka veza i dalje predstavlja jedinstvenu tačku otkaza za ceo sistem.

9.2.5 – Podaci

Prioritetni procesi zavise od ažurnih ili skoro ažurnih podataka, pa rešenja za kontinuitet podataka treba da budu dizajnirana da ispune RPO svake prioritetne poslovne aktivnosti. Izabrane IRBC opcije treba da obezbede kontinuiranu poverljivost, integritet i dostupnost podataka koji podržavaju kritične aktivnosti. Strategije skladištenja podataka treba da uzmu u obzir:

• zahteve za ICT RPO
• način na koji se podaci skladište (disk, traka, optički medij), uz odgovarajuće mehanizme bekapa i restauracije koji obezbeđuju da su podaci bezbedni i u sigurnom okruženju
• gde se informacije skladište, transportuju ili prenose – udaljenost, lokacija, mrežne veze (na lokaciji, van lokacije, ili kod treće strane) i očekivano vreme za preuzimanje bekap medija
• vreme potrebno za restauraciju, koje zavisi od količine podataka, načina skladištenja i složenosti tehničkog procesa restauracije, zajedno sa zahtevima korisnika usluge i potrebama organizacionog kontinuiteta

Razumevanje "od-kraja-do-kraja" upotrebe podataka kroz celu organizaciju je ključno – uključujući tokove informacija ka i od trećih strana. Priroda, status ažurnosti i vrednost podataka enormno variraju unutar jedne organizacije. To razumevanje je tačno ono što nedostaje kad se bekap posmatra izolovano, po sistemu – cloud provajderova replikacija savršeno vredno replicira i grešku, jer prati tok podataka samo unutar sopstvene platforme, ne kroz ceo lanac koji uključuje i on-premise stranu.

Primer: Za podatke domenskog kontrolera kod VoxServis-a (baza naloga, bezbednosne politike), trenutno nije jasno da li se konfiguracija bekapuje odvojeno od operativnih podataka, ni koliko bi tačno trajala restauracija u praksi – RTO od dva sata je procena, ne izmereno vreme restauracije zasnovano na stvarnoj količini podataka. Uz to, tok podataka o klijentima ide od-kraja-do-kraja kroz više sistema: agent unosi podatak u CRM (cloud), koji se delom sinhronizuje sa lokalnim sistemima radi izveštavanja, dok se snimci poziva čuvaju lokalno na PBX platformi. Niko nikad nije mapirao taj kompletan tok da bi utvrdio gde je RPO najranjiviji.

Šta treba uraditi

• Za svaki tip podataka (podaci naloga, podaci klijenata, snimci poziva) definisati RPO zahtev i mapirati od-kraja-do-kraja tok kroz sve sisteme koje dodiruje.
• Izmeriti, ne proceniti, stvarno vreme restauracije za svaki tip podataka – zasnovano na stvarnoj količini podataka, ne na pretpostavci.
• Zapisati lokaciju skladištenja bekapa i očekivano vreme preuzimanja ako je van lokacije.
• Izbegavati najčešću grešku – posmatranje bekapa kao binarnog stanja ("imamo bekap" ili "nemamo") bez ikad izmerenog stvarnog vremena restauracije, tako da RPO i RTO za podatke ostaju procena umesto izmerene činjenice.

9.2.6 – Procesi

Pri izboru IRBC strategije, organizacija treba da razmotri procese neophodne da bi ta strategija bila održiva – uključujući one potrebne za prevenciju incidenata, detekciju incidenata, odgovor na incidente i oporavak od katastrofe. Organizacija treba i da identifikuje faktore neophodne za efektivno sprovođenje tih pojedinačnih procesa – na primer, ključne skupove veština, kritične podatke, ključne omogućavajuće tehnologije, ili kritičnu opremu i objekte.

Ovo je podsetnik da tehnička strategija – recimo, "drugi domenski kontroler u Novom Sadu" – ne funkcioniše sama od sebe. Treba joj proces koji kaže ko je aktivira, kada, i kojim koracima. Bez tog procesa, i najbolja tehnička odluka ostaje neupotrebljiva u trenutku krize.

Primer: Ako VoxServis uvede drugi domenski kontroler u Novom Sadu, sama ta odluka ne rešava ništa dok ne postoji proces koji kaže ko ima ovlašćenje da promoviše sekundarni kontroler u primarnu ulogu, kojim tačno koracima, i sa kojom listom provere pre i posle. Bez tog procesa, drugi kontroler je skup komad opreme koji niko ne zna kako da aktivira pod pritiskom.

Šta treba uraditi

• Za svaku izabranu tehničku strategiju, napisati pripadajući proces aktivacije – ko ima ovlašćenje, kojim koracima, sa kojom listom provere.
• Zapisati spisak faktora (veštine, podaci, tehnologija, oprema) neophodnih da taj proces stvarno funkcioniše, ne samo da tehnički postoji.
• Izbegavati najčešću grešku – da se tehnička strategija implementira (kupljena oprema, potpisan ugovor), ali proces koji definiše ko je i kako aktivira nikad ne bude napisan.

9.2.7 – Dobavljači

Organizacija treba da identifikuje i dokumentuje eksterne zavisnosti koje podržavaju pružanje IT usluga, i preduzme adekvatne korake da obezbedi da kritična oprema i usluge mogu biti isporučene od dobavljača u unapred određenim i dogovorenim rokovima. Takve zavisnosti mogu postojati za hardver, softver, telekomunikacije, aplikacije, usluge hostinga trećih strana, komunalne usluge, i pitanja životne sredine poput klimatizacije, monitoringa okruženja i protivpožarne zaštite. Strategije za ove usluge mogu uključivati:

• skladištenje dodatne opreme i kopija softvera na drugoj lokaciji
• dogovore sa dobavljačima o isporuci zamenske opreme na kratak rok
• brzu popravku ili zamenu neispravnih delova
• dvostruko snabdevanje komunalnim uslugama poput struje i telekomunikacija
• opremu za rezervno napajanje
• identifikaciju alternativnih/zamenskih dobavljača

Organizacija treba da uključi zahteve za IT i upravljanje kontinuitetom poslovanja u ugovore sa partnerima i pružaocima usluga – prilozi uz ugovor treba da referenciraju obaveze svake strane, dogovorene nivoe usluge, odgovor na veće incidente, raspodelu troškova, učestalost vežbanja, i korektivne akcije. Ovo pretvara u konkretan zahtev ono što je ranije u seriji opisano kao analiza jaza između sposobnosti dobavljača i ugovorenog RTO – sad standard kaže i šta konkretno treba da stoji u ugovoru da bi ta analiza uopšte imala osnov. Retko koji ugovor sa cloud ili SaaS dobavljačem uopšte pominje da li i koliko često dobavljač testira sopstvenu spremnost.

Primer: Ugovor VoxServis-a sa cloud CRM provajderom sadrži standardnu SLA klauzulu o dostupnosti platforme, ali ne sadrži nijednu od stavki koje ova klauzula standarda traži: nema eksplicitnog pominjanja odgovora dobavljača na veće incidente, nema učestalosti vežbanja koju bi dobavljač bio dužan da deli, i nema jasne raspodele troškova ako dođe do produženog prekida. VoxServis bi, pri sledećem obnavljanju ugovora, mogao da traži da se ove stavke eksplicitno dodaju – ne kao formalnost, nego zato što bez njih nema ničega opipljivog na šta bi se pozvao ako dobavljač ne isporuči ono što je prećutno očekivano.

Šta treba uraditi

• Napraviti spisak kritičnih dobavljača sa dogovorenim rokovima isporuke opreme ili usluga.
• Proveriti da ugovori sadrže sve relevantne odredbe – obaveze, nivoe usluge, odgovor na incidente, raspodelu troškova i učestalost vežbanja – ne samo cenu i redovnu dostupnost.
• Identifikovati alternativne dobavljače za slučaj da primarni ne može da isporuči na vreme.
• Izbegavati najčešću grešku – ugovor koji pokriva redovno poslovanje (cena, funkcionalnost, uobičajena dostupnost), ali nikad scenario prekida: šta se tačno dešava, ko šta radi i za koliko vremena, ako dobavljač doživi sopstveni veći incident.