PLAN
KONTINUITETA POSLOVANJA ZA IKT PLATFORMU

("Sl. glasnik Grada Vranja", br. 19/2021)

 

1. UVODNE NAPOMENE

Ovaj Plan treba da omogući kontinuitet servisa u slučaju značajnog prekida rada. Plan opisuje pristup proceni prekida, planiranje oporavka od prekida i stalno praćenje oporavka.

Procesi opisani u ovom dokumentu razvijeni su da umanje posledice i postave osnovu za nastavak rada i oporavak od neplaniranih prekida poslovnih funkcija. Plan za obezbeđivanje kontinuiteta poslovanja (BCP) koristi se kao podrška procesu odlučivanja u slučaju nekog prekida koji može eskalirati od nivoa Problema do proglašavanja Katastrofe.

1.1. Cilj

Cilj (BCP) za IKT platformu je da:

- dokumentuje kako IKT služba treba da procenjuje prekid rada IKT platforme uključujući i razumevanje opsega i posledica;

- opiše kako tim treba da reaguje na proglašavanje Katastrofe uključujući i planiranje i postavljanje prioriteta aktivnosti oporavka;

- obezbedi proces za procenu odziva tima nakon Katastrofalnog događaja;

- pruži odrednice tehničkim timovima za oporavak - šta bi trebalo da uključe tehnički planovi;

- pruži odrednice timu za Upravljanje incidentima kako da pristupe oporavku ukoliko je tim ugrožen direktno (pandemija ili katastrofalni događaj) ili indirektno (gubitak konektivnosti).

1.2. Opseg

Opseg Plana je fokusiran na kontinuitet tehničke i poslovne operativnosti IKT servisa.

Dokument se ne bavi kontinuitetom platformi koje su u vlasništvu službi izvan IKT-a nad kojima su servisi nadgrađeni. Plan kontinuiteta ovih platformi i infrastrukturnih servisa je odgovornost njihovih tehničkih i poslovnih timova. Za utvrđene međuzavisnosti, IKT tim će raditi sa tim timovima ukoliko je neophodno, u cilju što bržeg oporavka ovih servisa.

Opseg ovog Plana jeste samo kontinuitet poslovanja i planiranje aktivnosti oporavka na višem nivou. Za svaki pojedinačni servis, odnosno funkciju, očekuje se da postoji pripremljen dodatni dokument "Tehnički ili oporavak od katastrofalnih događaja" i koji je vlasništvo svakog pojedinačnog servisa, odnosno funkcije.

2. PLAN ZA KONTINUITET POSLOVANJA

2.1 Pregled

BCP za IKT platformu definiše okvir i osnovne procese za procenu posledica i odziva na prekid poslovne operativnosti.

Veoma je bitno prvo sagledati i razumeti kako postupiti kada se otkrije ili je prijavljen prekid. Nakon razumevanja opsega prekida, moraju se doneti odluke o daljim koracima. Za sve prijavljene prekide, potreban je plan za pregled aktivnosti odziva kako bi se obezbedio napredak procesa.

2.2 Prijavljivanje prekida servisa

Odmah po prepoznavanju prekida servisa, ta osoba mora to prijaviti rukovodstvu korišćenjem najprimerenijeg metoda za konkretnu situaciju.

- za manje ozbiljne prekide - e-pošta, eventualno interni chat;

- za ozbiljne prekide - telefon, eventualno interni chat.

Lista osoba kojima se prijavljuje i chat grupa nalaze se u prilozima dokumenta.

2.2.1 Prijavljivanje nedostupnosti ljudstva

Značajna nedostupnost ljudstva treba da bude prijavljena odmah Koordinatoru za kontinuitet poslovanja i rukovodstvu IKT-a.

Ukoliko je dostupna bilo informacija o prekidima i nedostupnosti, ozbiljnosti posledica na ljudstvo koje je uključeno u konkretnu situaciju i potencijalne posledice na poslovnu operativnost istu treba uključiti u ovu komunikaciju.

2.2.2 Prijavljivanje prekida u servisima

Ukoliko se desi tehnički prekid, osoba koja prepozna ovakvu situaciju treba bez odlaganja da: Prijavi prekid timu nadležnom za servis prethodno dogovorenom metodom.

Kontaktira vođu tima za Upravljanje incidentima ili nadležnu osobu za servis.

Nadležna osoba za servis će izvršiti preliminarnu procenu prijavljenog prekida i odlučiti o potrebi za dalju eskalaciju. Inicijalna procena treba da sadrži sledeće informacije:

Uticaj na konstituente (ev. listu pogođenih konstituenata):

- koja je lokacija pogođena;

- platforma koja je pogođena;

- datum i vreme uočavanja, odnosno prijave prekida;

- prvi utisak o prekidu i potencijalnim posledicama;

- preduzete aktivnosti do tog trenutka.

Ukoliko ova situacija eskalira, kontaktira se Koordinator za kontinuitet poslovanja. Koordinator tada inicira BCP proces.

2.3 Procena situacije-prekida

Tokom ove faze, vrši se procena prekida kako bi se odredile i kategorisale posledice. Posledice mogu biti ekstremne u slučaju nekih prirodnih katastrofa (pandemija, zemljotres, poplave, uraganski vetar), ali mogu se pojaviti i zbog drugih događaja kao što su nezgode (gubitak veze sa internetom, kvar, ljudska greška, pucanje cevi, druge nepredviđene situacije) i maliciozna dela (bezbednosni proboj, paljevine, teroristički napad).

Lista za pomoć u proceni data je u Prilogu 3. Koordinator BCP za IKT platformu koristiće ovu listu kako bi se obezbedilo da se BCP proces prati i dokumentuje.

Namera procene i kategorisanja obima prekida jeste da se odredi kako IKT treba da reaguje.

- Ukoliko je procena da su posledice prekida niske (otkaz koji traje manje od 4 sata), Uprava može odlučiti da prođe uzrok i prihvati druge potencijalne posledice (neispunjavanje obaveze izveštavanja, troškovi) zbog neispunjavanja dogovorenog nivoa servisa.

- Ukoliko je procena da su posledice veće i da prekid može trajati duže, Uprava će odlučiti o tome da li je neophodno proglasiti "katastrofalnu situaciju".

Svi ovi faktori moraju se posmatrati u svetlu procenjenih troškova i vremena u slučaju proglašavanja Katastrofe i odluke da se pređe na drugu lokaciju.

Za potrebe ovog plana, Katastrofa se definiše kao tačka u kojoj gubitak sistema ili resursa koji podržavaju aplikacije i poslovne procese postaje kritičan po kontinuitet operativnosti IKT platforme.

2.3.1 Sazivanje tima za procenu situacije

Tim za procenu prekida kritičan je za dalje razumevanje posledica prekida poslovnih servisa. Tim treba da sačinjavaju sledeći predstavnici:

- koordinator BCP za IKT platformu;

- predstavnici pogođenog servisa;

- predstavnici sektora za bezbednost;

- predstavnici pružaoca usluga za platformu nad kojom je nadgrađen servis (ako je primenljivo).

Tim za procenu situacije sa svim ključnim kontakt detaljima naveden je Prilogu 2.

2.3.2 Procena nedostupnosti ljudstva

Naredna tabela daje uzorak razloga nedostupnosti ljudstva.

Događaj

Preporučeni odziv

Gubitak konektivnosti na primarnoj lokaciji.

Uputiti ljudstvo na rad od kuće.

Pandemija koja utiče na mogućnost tima za upravljanje incidentima da rade sa primarne lokacije.

Tražiti da ljudstvo radi od kuće.

Pandemija koja direktno utiče na tim za upravljanje incidentima zbog nedostatka neophodnih ljudi.

Periodično proveravati stanje i dostupnost ljudstva.
Realocirati ljudstvo iz drugih timova ili sa drugih lokacija kako bi se privremeno prevazišao problem.

2.3.3 Procena nedostupnosti servisa

Detaljna procena se dovršava. Procena sadrži detaljne informacije od ljudi sa terena.

Rukovodstvo IKT-a mora sagledati i razumeti posledice prekida pregledanjem dobijenih detaljnih informacija. Tim za procenu saziva se i biće odgovoran za ovu procenu. Članovi tima se uzimaju iz sektora za bezbednost, upravljanja incidentima i timova koji su pogođeni prekidom. Tim za procenu će:

- dovršiti inicijalnu procenu posledica;

- identifikovati nivo prekida i servise, odnosno konstituente na koje ovo utiče;

- raditi sa odgovarajućim resursima iz timova za upravljanje platformama kako bi se procenili uticaji i posledice;

- proceniti vreme potrebno za oporavak osnovne infrastrukture, platformi od kojih postoji zavisnost, servisa i drugih povezanih oblasti;

- identifikovati alternativna rešenja;

- dati preporuke.

Obično, nedostupnost ljudstva ne utiče direktno na dostupnost poslovnih servisa. Ljudstvo je kritično da bi se osigurala kontinualna dostupnost i stabilnost poslovnih servisa.

Tim za procenu će dodeliti nivo ozbiljnosti na osnovu svoje procene. Inicijalna procena mora biti završena i pregledana od strane odgovarajućeg rukovodstva u roku od 1-2 sata od prijave.

Prekid jednog servisa potencijalno može uticati na stabilnost IKT platforme za koju je definisan ciljani nivo dostupnosti od 99.9%. Kritično je da procena bude završena što je pre moguće, kako bi drugi timovi mogli što pre krenuti sa svojim aktivnostima u slučaju proglašenja Katastrofe.

Nivo ozbiljnosti

Opis

NIZAK

Očekivani prekid < 4 sata

Potrebne neke izmene u radu, odnosno raspoređivanju poslova. Nema ili je potrebna vrlo mala mobilizacija iz domena koji se odnosi na oporavak od katastrofalnih događaja.

(očekivan manji uticaj, odnosno posledice)

UMEREN

Ozbiljan problem i oporavak poslovnih funkcija i/ili IKT servisa može potrajati > 4 sata; može biti potrebe za implementacijom na lokacijama za oporavak.

Potrebne su izmene u radu, odnosno raspoređivanju poslova, kako bi se obezbedilo da prioritetne poslovne funkcije i aplikacije mogu proraditi što je pre moguće. Može biti potrebe za delimičnom ili potpunom mobilizacijom odgovarajućih resursa (tim za upravljanje infrastrukturom i lokacijama).

Zavisno od opsega štete, izvode se aktivnosti oporavka za neke od sistema i produkcionih aplikacija. Većina poslovnih funkcija i/ili servisa radiće uobičajeno nakon oporavaka.

(očekivan umeren uticaj, odnosno posledice)

VISOK

Problem je ozbiljan, oporavak poslovnih funkcija i/ili IKT servisa može potrajati i više od 24 sata i sprovešće se na alternativnoj lokaciji (za oporavak) - prema definisanom rasporedu prioretizacije za svaki servis kroz definisane planove za oporavak od katastrofalnih situacija.

Potrebna je potpuna mobilizacija resursa za oporavak. Proglašava se katastrofa i sve poslovne funkcije, informacioni servisi i druge funkcije za podršku rade u Režimu oporavka.

(potpuni prekid)

2.3.4 Pregled uticaja-posledica prekida servisa

Koriste se odrednice iz prethodne tabele i Uputstva za procenu uticaja (iz priloga) kako bi Uprava odredila nivo ozbiljnosti i primenila adekvatne planove.

Donošenje odluke o proglašenju Katastrofe nije neophodno ako Tim za procenu smatra da oporavak od prekida neće trajati duže od 48 sati.

Za ozbiljnije prekide - očekivano preko 48 sati - akcija koja će se primeniti u slučaju prekida poslovne operativnosti mora primarno biti bazirana na proceni procenjenog trajanja prekida u odnosu na definisani RTO (Recovery Time Objective) - ciljno vreme oporavka.

- Ukoliko je razlika u vremenu između RTO i očekivanog vremena oporavka veća od 48 sati, proglašava se Katastrofa i obaveštavaju se tehnički timovi za oporavak da započnu sa svojim aktivnostima oporavka na alternativnoj lokaciji;

- Ukoliko je razlika u vremenu između RTO i očekivanog vremena oporavka između 24 sata i 48 sati, Tim za upravljanje kontinuitetom poslovanja može odlučiti da li će čekati razrešenje prekida ili proglasiti Katastrofu;

- Ukoliko je odluka da se sačeka razrešenje prekida, a prekid se nastavi i nakon dozvoljenog perioda, Uprava odlučuje o tome da li će biti proglašena Katastrofa;

- Tim za procenu prati aktuelnu situaciju, imajući u vidu da ista može eskalirati do višeg nivoa ozbiljnosti.

Odobrenje Uprave IKT-a nije neophodno za proglašavanje Katastrofe, u slučaju da :

- pogođeni su svi poslovni procesi i/ili aplikacije (bilo da nije moguće ispuniti predviđeni nivo servisa ili neki sistemi povremeno nisu dostupni);

- tim za procenu smatra da je prekid šireg razmera i da neće biti moguće vraćanje na "normalno" stanje na primarnoj lokaciji unutar definisanog RTO perioda;

- šteta je tolika da je jasno da nije potrebna neposredna procena;

- neophodno ljudstvo iz Tima za upravljanje incidentima nije više dostupno.

Po proglašavanju Katastrofe, Uprava će:

- autorizovati proces oporavka od katastrofa;

- pokrenuti plan komunikacije - interni, za konstituente i za javnost.

2.3.5 Komuniciranje odluke nakon procene

Bez obzira na proglašavanje Katastrofe ili ne, verovatno je da će osobe zadužene za komunikaciju sa konstituentima i korisnička podrška biti opterećeni dodatnim upitima zbog problema u korišćenju servisa.

Da bi se osigurao koordinirani pristup, potrebno je izvršiti sledeće korake:

- koordinator za komunikaciju koordinira i upravlja komunikaciju ka konstituentima, internim i eksternim timovima, drugim relevantnim institucijama;

- koordinator za komunikaciju saopštava pogođenim timovima stanje i aktivnosti koje treba da preduzmu;

- koordinator za komunikaciju saopštava konstituentima stanje pogođenih servisa i da li je proglašena Katastrofa -

• saopštava konstituentima aktuelno stanje;

• nagoveštava kada će uslediti naredna komunikacija;

• pojašnjava i daje više detalja o prekidima poslovne operativnosti;

• pojašnjava koji su naredni koraci.

Kontakt informacije tima za Kontinuitet poslovanja i drugi neophodni kontakti objavljeni su na bezbednoj lokaciji, tako da informacije koje nisu javne ne bi dospele u javnost. U okvirima svakog od servisa, navedena je tehnička dokumentacija potrebna za oporavak i lista nadležnih kontakata (uključujući i Upravu) koji treba da budu obavešteni o proglašenju katastrofe.

2.4 Odziv za proglašenje Katastrofe

2.4.1 Odziv na proglašenje Katastrofe za ljudstvo

Uprava mora da odredi kako najbolje odgovoriti na situacije koje se odnose na ljudstvo u Timu za upravljanje incidentima. Minimalno, potrebno je kontaktirati:

- Kadrovsku službu,

- Upravu GU Vranje,

- Rukovodstvo IKT-a,

- Nadležno ministarstvo.

Kako bi se ublažile potencijalne posledice nedostupnosti ljudstva, moguće je:

- tražiti od raspoloživog ljudstva da preuzme dodatne obaveze i zadatke na sebe,

- prerasporediti deo ljudstva iz drugih servisa da "uskoče",

- tražiti druge tehničke resurse koji bi pomogli po potrebi.

Odluka treba jasno da bude komunicirana svim uključenim stranama - direktno ili indirektno.

2.4.2 Odziv na proglašenje Katastrofe za tehničke servise

Imenuje se Tim za odziv koji će odrediti kako je najbolje reagovati na proglašenje katastrofe. Članovi Tima za odziv su:

- koordinator kontinuiteta poslovanja;

- dodeljena osoba iz Uprave;

- koordinator za komunikaciju;

- predstavnici pogođenih servisa.

Tim za odziv prvo određuje kakve i koje akcije će se primeniti. Razvija se plan koji se komunicira kako unutar institucije tako i (glavnim) konstituentima preko Koordinatora za komunikaciju. Tim je takođe odgovoran za praćenje statusa tehničkog oporavka.

2.4.2.1 Planiranje i postavljanje prioriteta

Tim prvo utvrđuje koji servisi su pogođeni. Informacije koje su potrebne Timu za oporavak su:

- koja je lokacija pogođena;

- koji servisi su pogođeni;

- da li postoje neka regulatorna ograničenja i zahtevi koji se odnose na oporavak servisa.

Sa ovim prikupljenim informacijama, Tim za odziv priprema Plan prioriteta oporavka servisa.

Tim za odziv mora da razume osnovnu arhitekturu pogođenih servisa i prepozna da li postoji neka deljena, odnosno zajednička platforma ili infrastruktura koja je potrebna pre nego se oporavljaju pojedinačni servisi. Plan treba da uzme u obzir napore i vreme potrebno za oporavak različitih okruženja.

Fokus je na oporavku instanci servisa koje koriste spoljašnji korisnici. Ukoliko je primarni data centar značajno pogođen, potrebno je razmotriti i oporavak ne-produkcionih instanci.

Odluka o ovome se odlaže dok se ne završi oporavak svih produkcionih instanci.

Po završetku pripreme Plana oporavka, isti se pregleda i odobrava od strane Uprave.

2.4.2.2 Komunikacija

Uz odobreni Plan oporavka, izvršava se i Plan za komunikaciju sa konstituentima, drugim relevantnim institucijama i sa Upravom. Koordinator komunikacije prikuplja informacije, kako bi se omogućila adekvatna komunikacija uzevši u obzir i:

- potrebne kapacitete za hardware (serveri, storage, mrežni uređaji) i propusni opseg za svaki data centar;

- procenjeno vreme oporavka - za konstituente i za timove za podršku odnosno one koji komuniciraju sa eksternim stranama;

- Plan oporavka za pogođene timove;

- Plan oporavka za Upravu.

2.4.2.3 Tehnički oporavak

Po proglašavanju katastrofe, Plan oporavka se komunicira svakom tehničkom timu za oporavak.

Ovi timovi - koji su odgovorni za tehnički oporavak - identifikovani su pri tehničkoj dokumentaciji za svaki pojedinačni servis.

Lista za proveru oporavka priprema se za svaki od servisa i prati tokom procesa oporavka.

Izmene se unose u dokumentaciju i stalno komuniciraju Upravi i koordinatoru za kontinuitet.

Ukoliko postoje zajednički, odnosno deljeni servisi, isti se moraju uzeti u obzir i njih rasporediti tako da prethode drugim pojedinačnim servisima.

Po tehničkom oporavku svakog od servisa IKT platforme, izvodi se osnovna provera funkcionalne ispravnosti. Ažurne informacije o uspešnom oporavku svakog od servisa se komuniciraju Timu za kontinuitet.

Svi tehnički timovi ostaju na svojim mestima dok se stanje komunicira ka konstituentima i drugim eksternim korisnicima i počinju da koriste ove servise.

2.4.2.4 Završetak

Kako se zaključuje prekid operativnosti, postoji više aktivnosti koje treba sprovesti.

Odgovorni tim:

- komunicira stanje oporavka konstituentima;

- sprovodi analizu uzroka prekida i komunicira rezultate odgovarajućim timovima (koji su bili pogođeni, rukovodstvu);

- komunicira sa timovima internih servisa i servisa za podršku o stanju oporavka;

- komunicira sa Upravom o statusu oporavka uključujući i parametre o broju pogođenih servisa i strana, obaveštenih institucija.

Događaj se zatvara i sva dokumentacija se odlaže na predviđenu lokaciju.

2.5 Pregled odziva

Po uspostavljanju operativnog stanja, ceo proces se ponovno pregleda i analizira kako bi se unapredila reakcija u budućnosti. Priprema se dokument sa formalnim nalazima ('lessons learned'- naučena lekcija) ili sastanak, gde se diskutuju načini unapređenja proizašli iz ove aktivnosti.

2.5.1 Sprovođenje pregleda nakon događaja

Prvenstvena namera je da se identifikuje:

- Šta je bio osnovni uzrok prekida?

- Šta je dobro funkcionisalo?

- Šta je moglo biti bolje?

- Šta smo naučili?

Kako možemo unaprediti svoje servise uključujući i uputstva, procese za oporavak?

Fokus je na unapređenju procesa kontinuiteta poslovanja i tehničkog oporavka. Ulazni podaci za ovaj pregled jesu informacije prikupljene od timova koji su učestvovali u oporavku, kao i popunjena Lista za pomoć u proceni.

Po kompletiranju izveštaja ili održanom sastanku, predlozi za izmene se šalju nadležnom rukovodstvu.

2.5.2 Ažuriranje planova kontinuiteta i tehničkih planova za oporavak

Sve preporučene izmene se inkorporiraju i ponovno pregledaju. Po odobrenju promena, nove verzije dokumenata se objavljuju i smeštaju na predviđenim lokacijama.

2.6 Uloge i odgovornosti

U tabeli je predstavljen Tim za oporavak i uloge u procesu Kontinuiteta poslovanja/ Oporavka od katastrofalnih situacija. Samo jedan tim ili osoba može biti odgovorna za određenu oblast tokom ovog procesa.

Uloga
Odgovornost

Koordinator BCP

Rukovodstvo

Tim po platformi

Tim za upr. inc.

Data centar (provajder)

Koordinator komunikacije

Prijava prekida

A

I

C

R

C

I

Pokretanje BCP

A

I

I

R

I

I

Procena prekida

A

I

C

R

C

I

Komunikacija o katastrofi

A

R

C

R

C

I

Plan i prioretizacija oporavka

A

 

I

I

I

R

Plan i prioretizacija oporavka

A

I

C

R

C

I

Tehnički oporavak

A

I

C

R

C

I

Praćenje tehničkog oporavka

A

I

I

R

I

 

Validacija tehničkog oporavka

A

I

C

R

C

 

Komunikacija o oporavku

A

I

I

I

I

R

Pregled

R

A

C

R

I

I

Legenda:

R - responsible = ko izvršava

A - accountable= ko donosi odluku

C - consulted = ko se konsultuje pre donošenja odluke ili preduzimanja akcije

I - informed = ko se obaveštava da je odluka doneta ili aktivnost izvršena

3. POVRATAK NA PRIMARNU LOKACIJU

Po prestanku prekida, odnosno događaja koji su doveli do prekida operativnosti na primarnoj lokaciji, Tim za kontinuitet treba da odredi da li je potreban prelazak na primarnu lokaciju (primarni data centar).

3.1 Procena potrebe tranzicije (povratka) na primarnu lokaciju

Tim za procenu se sastaje kako bi procenio potrebu za povratak na primarnu lokaciju.

Kriterijumi koji se koriste za procenu uključuju:

- blizina i dostupnost platformi i/ili infrastrukturnih servisa koji su potrebni,

- moguća ograničenja u domenu kapaciteta na alternativnoj lokaciji,

- zahtevi konstituenata,

- regulatorni i slični zahtevi.

Ukoliko se donese odluka o povratku, aktivnosti treba sprovesti u koordinaciji sa konstituentima koliko je to moguće. Timovi za tehnički oporavak se obaveštavaju kada aktivnosti mogu započeti i sprovode sve aspekte ovih aktivnosti.

3.2 Pokretanje tranzicije natrag na primarnu lokaciju

Sve relevantne strane se obaveštavaju o planiranoj tranziciji.

Vreme se usaglašava i formalni zahtevi za promene se beleže u sistemu pre izvođenja aktivnosti.

Tehnički timovi za oporavak izvode tehničke procedure i validiraju uspešnost po završetku.

Sve strane koje mogu biti "pogođene" ovim, Koordinator za komunikaciju obaveštava o završetku aktivnosti.

3.3 Praćenje tranzicije

Tokom procesa povratka (failback-neuspešan povratak), Tim za kontinuitet prati progres i ostaje dostupan za slučaj eskalacije ili pojave drugih problema.

3.4 Završetak tranzicije

Po završetku tranzicije natrag na primarnu lokaciju, smatra se da su aktivnosti završene. Priprema se izveštaj i distribuira nadležnom rukovodstvu, indicirajući da je tranzicija pokrenuta i završena.

4. ODRŽAVANJE PLANA ZA KONTINUITET POSLOVANJA I TEHNIČKIH PLANOVA OPORAVKA

Plan za kontinuitet i tehnički planovi se pregledaju i ponovno procenjuju na godišnjem nivou. Pored toga, novi servisi ili promene u implementaciji servisa zahtevaju da se tehnički planovi pregledaju i ažuriraju.

4.1 Upravljanje Planom kontinuiteta poslovanja

Održavanje Plana je od izuzetne važnosti za validaciju aktuelnosti procedura koje rukovode procesom oporavka. Sve poslovne promene moraju se razmotriti pri ažuriranju Plana.

4.1.1 Pregled i ažuriranje Plana kontinuiteta poslovanja

Plan se održava aktuelnim i sinhronizovan sa poslovnim promenama. Sve poslovne promene moraju se razmotriti pri ažuriranju Plana.

Plan za kontinuitet poslovanja i planovi za oporavak servisa pregledaju se godišnje. Cilj je identifikovati i inkorporirati u poslovne funkcije ili proces oporavka promene koje su se pojavile od prethodnog pregleda. Elementi koje treba pregledati pri razmatranju ažuriranja Plana uključuju:

- poslovni zahtevi i prioriteti;

- opseg, pretpostavke i promene misije;

- procedure testiranja;

- nove bezbednosne kontrole;

- promene tehničkih planova;

- procedure kontinuiteta i oporavka;

- promene u ljudstvu.

4.1.2 Testni scenariji

Kao deo godišnjeg testiranja Plana kontinuiteta, treba razmotriti i ove scenarije. Čak i u slučaju da se rade tzv. "papirni" testovi, bitno je proveriti kakav bi mogao biti odziv na događaje koji bi doveli do prekida u poslovnoj operativnosti.

rb.

Scenario

Opis

1

Nedostupnost glavne lokacije

Nije moguć pristup ili je lokacija neupotrebljiva

2

Nedostupnost ljudstva

Više od 50% ljudstva je sprečeno-nedostupno

3

Nedostupnost IKT servisa

Jedan ili više od kritičnih zajedničkih servisa nije dostupan

4

Regionalna katastrofa

Događaj širih razmera koji sprečava kritičnom ljudstvu pristup radnoj lokaciji i kritičnim IKT sistemima

4.2 Upravljanje tehničkim planovima

Tehnički planovi oporavka prave se za svaki servis. Okvir se održava konzistentnim za sve servise.

Ovde se daju smernice šta treba da bude uključeno u svaki tehnički plan oporavka.

4.2.1 Period pregleda

Tehnički planovi se pregledaju na godišnjem nivou i ažuriraju po potrebi.

4.2.2 Identifikovanje RTO i RPO

Recovery Time Objective (RTO) definiše se kao ciljano vreme (i nivo servisa) tokom kojeg poslovni proces mora biti ponovo uspostavljen nakon katastrofalnog događaja (ili prekida) kako bi se izbegle neprihvatljive posledice povezane sa prekidom kontinuiteta poslovanja.

Recovery Point Objective (RPO) definiše se kao maksimalno ciljano vreme za koje je moguće izgubiti podatke za neki IKT servis zbog nekog značajnog incidenta.

IKT ima definisane polazne RTO i RPO i svi timovi su u obavezi da budu u skladu (ili bolji) sa ovim zahtevima:

Recovery Time Objective (RTO) = 24 sata

Recovery Point Objective (RPO) = 8 sati

4.2.3 Identifikovanje ključnih kontakata

Identifikovanje kontakata koji treba da budu (ili može biti potrebno) da se uključe u tehnički oporavak. Lista treba da bude na lokaciji koja je lako dostupna autorizovanim osobama.

4.2.4 Sprovođenje pregleda i postavljanja prioriteta poslovnih procesa i servisa (funkcija)

Tim odgovoran za servis mora pregledati inventar rešenja kako bi razumeli koji procesi su kritični za "opstanak".

Tim odgovoran za servis mora odrediti komponente koje treba odmah oporaviti, a koje mogu biti naknadno uspostavljene po uspostavljanju poslovnog servisa.

Tim odgovoran za servis mora dokumentovati redosled oporavka komponenti, odnosno koje komponente treba oporaviti da bi se moglo smatrati da je servis oporavljen.

4.2.5 Dokumentovanje tehničkog oporavka

Tehnički plan oporavka sastoji se od ovih osnovnih odeljaka:

- oporavak mrežnih komponenti;

- identifikovanje i oporavak minimalnih bezbednosnih zahteva.

Tim odgovoran za servis identifikuje minimalne zahteve kako bi se smanjila izloženost. Ovo minimalno uključuje firewall-e, konfiguraciju mrežnih zona i gateway-a, proveru usklađenosti sa regulatornim zahtevima.

- oporavak osnovne infrastrukture

Dokument mora da zabeleži bilo koje konfiguracije specifične za određeni servis.

Timovi nadležni za servis treba ovo da identifikuju u svojim tehničkim dokumentima.

- oporavak pomoćnih komponenti

U ovom odeljku nalaze se detalji vezani za dodatne mrežne komponente, backup i slično.

Kako neke od pomoćnih komponenti nisu zahtevane za inicijalni oporavak, tehnički planovi dokumentuju koje su komponente neophodne, a za koje oporavak može biti odložen (i koliko dugo), kao i koje komponente uopšte ne moraju biti obnovljene.

- oporavak osnovnih (ključnih) aplikacija

Oporavak aplikacija teži da tesno prati inicijalnu postavku servisa i kako se uobičajeno aplikacije i serveri instaliraju.

U tehničkom planu, za svaki servis dokumentovani su svi koraci potrebni za oporavak aplikacija uključujući i podatke i konfiguraciju aplikacija.

- implementacija specifičnih ekstenzija ili integracija

Kako neki servisi mogu uključivati i korišćenje specifičnih, to je i jedan od poslednjih koraka u procesu tehničkog oporavka. Implementacija i validacija ovih ekstenzija može zahtevati dodatno uključivanje dodatnih specifičnih timova za njihovu implementaciju i podešavanje.

Tehnički dokument sadrži i listu za proveru koja se može koristiti za proveru da li su svi potrebni koraci izvršeni pravilnim redosledom. Lista sadrži imena i uloge neophodne za kompletiranje tih zadataka.

4.2.6 Validacija tehničkog oporavka

Po uspešnom oporavku, osnovni testovi validacije se izvršavaju na servisima pre komuniciranja o statusu oporavka. Ovi osnovni testovi obično se koriste za proveru i demonstraciju mogućnosti pristupa aplikaciji, ulaska u aplikaciju uz dodatne specifične testove koji potvrđuju da je okruženje funkcionalno i spremno za upotrebu.

4.2.7 Povratak na primarnu lokaciju

Po razrešenju problema koji su uzrokovali prelazak, može biti neophodno uraditi tranziciju natrag na primarnu lokaciju. Ukoliko se tranzicija razlikuje na neki način od tehničkih planova oporavka, ove razlike treba naglasiti u tehničkim dokumentima za oporavak ili dokumentima za oporavak od katastrofa (DR).

4.2.8 Istorija rezultata godišnjeg testiranja

Nalazi i rezultati godišnjih DR testova treba da se čuvaju najmanje 3 godine.

5. TESTIRANJE PLANA KONTINUITETA POSLOVANJA

Plan kontinuiteta - koji se odnosi na minimum jedan servis - mora se testirati bar jednom godišnje. Dodatno, godišnje, za svaki servis treba testirati tehnički plan oporavka.

Koordinator kontiuiteta mora biti uključen u bilo koje testiranje.

Za svaki test koji se sprovodi (BCP, tehnički DR plan) mora biti pripremljena i objavljena lista koja sadrži opseg; rezultati moraju biti dostupni. Svaki plan testiranja mora da sadrži:

5.1 Ciljevi testiranja:

- lista primarnih ciljeva vežbe i očekivanih rezultata;

- lista sekundarnih ciljeva vežbe i očekivanih rezultata;

- postavljeno vremensko ograničenje za postizanje ciljeva.

5.2 Parametri testiranja:

- učesnici;

- plan obaveštavanja;

- sistemi i podaci koje treba oporaviti;

- mrežna konfiguracija;

- učešće korisnika;

- poslovne funkcije koje treba oporaviti.

5.3 Vrednosti koji se prate:

- zabeleženi početak i završetak vežbe i zadataka;

- dokumentovanje problema na koje se naišlo;

- odstupanja od plana testiranja.

5.4 Pregled po završetku:

- Da li su parametri korektni?

- Da li su postignuti ciljevi?

- Da li su kriterijumi merenja korektni?

- identifikovane problematične oblasti, dobre strane, odstupanja od plana;

- preporuke za unapređenje.

Detaljni Izveštaj sa testiranja smatra se poverljivim.

6. PRILOG 1: DEFINICIJE

- BCP, Business Continuity Plan

- DR, Disaster Recovery Plan

- kritični servisi - servisi označeni prvim prioritetom u Analizi uticaja na poslovanje (Business Impact Analysis, BIA).

- IKT, informaciona komunikaciona tehnologija

7. ZAVRŠNE ODREDBE

Ovaj Plan stupa na snagu osmog dana od dana objavljivanja u "Službenom glasniku grada Vranja".