plan de continuitate a activității - rmu.ro de continuare a activitatii... · plan de...

Plan de Continuitate a Activității

Asocierea S.C. CCT S.R.L. și S.C. Indaco Systems S.R.L.

Unitatea Executivă pentru FinanŃarea ÎnvăŃământului Superior, Cercetării, Dezvoltării și Inovării (UEFISCDI)

Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 2

Controlul Documentului

Istoricul versiunilor:

Versiune Data Autori

1 03.12.2010 CCT S.R.L. și INDACO Systems S.R.L.

1.1 12.09.2011 CCT S.R.L. și INDACO Systems S.R.L.

Istoricul autorizărilor:

Verificat de: Aprobat și impus de:

Gabriela Jitaru Manager de Proiect RMU

Manager RMU

Ion Gh. ROŞCA

Coordonator Dezvoltare Sistem Informatic RMU

Gabriel Şutac Manager Proiect de Dezvoltare Aplicație

Marius Nicolaescu Coordonator IT UEFISCDI

Rezumatul schimbărilor:

Versiune Descriere

1 Prima versiune a Planului de Continuitate a Activității aferent sistemului RMU.

1.1 Versiunea actualizată în urma finalizării implementării sistemului RMU

Distribuție:

Tip Către

Intern Toate departamentele

Grup Persoanele autorizate, cu nivel de acces >= C2 sau cu aprobarea explicită a Managerului RMU.

Extern Furnizori de servicii, cu nivel de acces aprobat și validat prin NDA >= C2.


Cuprins

1 Scop 4

2 Domeniu de aplicabilitate 4

3 Definiții 4

3.1 Descrierea Planului de Continuitate a Activității și a conceptelor cheie 5

4 Descrierea sistemelor critice 6

4.1 Descrierea generală a Portalului central RMU 6

4.1.1 Descriere roluri utilizatori la nivel central 7

4.1.2 Prezentarea fluxurilor informaționale specifice nivelului central, coroborate cu prelucările locale, de la nivelul universității 8

5 Resurse și impactul lor 11

5.1 Echipamente hardware existente la nivelul fiecărui sistem 11

5.1.1 Infrastructură la nivel central 11

5.1.2 Infrastructura de rețea pe care se face replicarea la nivelul DRC 14

5.2 Resurse umane 14

5.3 Clasificarea resurselor în funcție de impact și de sistemul/aplicația instalată 15

6 Impactul riscurilor și întreruperea activităților cheie 15

6.1 Introducere 15

6.2 Evaluări 16

6.2.1 Tabelul riscurilor analizate 16

6.2.2 Analiza impactului financiar zilnic/sistem 16

6.2.4 Timpul maxim în care trebuie realizată recuperarea 17

6.3 Analiza de impact asupra activității curente 18

6.4 Concluziile analizei impactului asupra activității curente 22

7 Condiții contractuale și parteneri și colaboratori cheie pentru apel în caz de dezastre 23

8 Planul BCP (Business Continuity Plan) 25

8.1 Verificări preliminare în timpul realizării / actualizării BCP-ului 28

8.2 Decizia de activare a planului BCP 29

8.3 Sosirea echipei de recuperare în locația de protecție pentru situații de dezastru 29

8.4 Punerea în funcțiune a serviciului de tip Help Desk (serviciu suport) 29

8.5 Comutarea 30

8.5.1 Semnarea procesului verbal de constatare a comutării manuale 31

8.6 Replicarea 31

8.7 Echipamente ”single point of failure” 33

9 Neconformare 33

10 Revizuirea Planului de Continuitate a Activității 34


1 Scop

Scopul acestui document este de a prezenta planul de acțiuni ce trebuiesc întreprinse de către personalul desemnat din cadrul Structurii RMU în cazul apariției unei situații categorisite drept dezastru ce impune transferarea activității operaționale în locația centrului de recuperare pentru situații de dezastru.

Documentul este structurat astfel:

- identificarea aplicațiilor critice a căror replicare este necesară în cadrul centrului de recuperare;

- descrierea infrastructurii IT din cadrul sistemului Registrul Matricol Unic; - descrierea sistemului de disaster recovery implementat (soluția de tip ”hot-site”

recomandată); - descrierea personalului disponibil; - analiza de riscuri și impactul acestora; - definirea de linii directoare pentru încheierea Service Level Agreements (SLA) în

vederea asigurării QoS (Quality of Service) atât cu furnizorii de echipamente, cât și cu furnizorii de Internet;

- descrierea modului de monitorizare a sistemului de disaster recovery în operarea curentă;

- definirea evenimentelor critice de tip dezastru; - definirea activităților, a pașilor și a procedurilor ce compun planul BCP (Business

Continuity Plan – Plan de Continuitate a Activității).

2 Domeniu de aplicabilitate

Măsurile detaliate în acest document fac referire la sistemul RMU și prezintă o modalitate integrată de asigurare a continuității operaționale în caz de dezastru.

3 Definiții

Dezastrele informatice și, prin extensie, cele de afaceri pot fi preîntâmpinate prin soluțiile de continuitate și recuperare în caz de dezastru. Continuitatea activităŃii în caz de avarie, necesita realizarea unui Centru Recuperare în caz de Dezastru (DRC – Disaster Recovery Center) denumit în continuare DRC. În ceea ce privește condiția de continuitate a activității sistemelor în cazul întreruperii funcționării centrului primar s-a luat în considerare un centru de procesare alternativ, astfel încât operarea să poată fi reluată într-un interval de timp foarte scurt, care să nu perturbe activitatea serviciilor curente întreprinse în cadrul sistemului RMU. DRC-ul va asigura continuitatea operării tuturor sistemelor informatice critice existente. Mecanismul utilizat este de replicare a datelor între cele două locații astfel încât în ambele centre să existe aceeași informație.

Pierderea datelor/funcționalității locației principale are implicații majore:

- Cheltuieli suplimentare asociate restaurării datelor, întârzierilor în raportare; - Risc de fraudă ridicat sau posibila corupere a datelor existente; - Reputație afectată ca sistem unic care centralizează la nivel național istoricul și traseul

educațional al fiecărui student / absolvent;


3.1 Descrierea Planului de Continuitate a Activității și a conceptelor cheie

Scopul unui Plan de Continuitate a Activități - BCP (Business Continuity Plan) este de a asigura reluarea operațiilor Structurii RMU în cazul apariției unui eveniment major cauzat de un dezastru natural, de intervenția omului sau chiar de probleme tehnologice. Cauzele care pot conduce la un eveniment major sunt dintre cele mai diverse: incendiu, cutremur, inundație, furtună, dezastru cauzat de o bombă, amenințare cu bombă, vandalism, defectarea echipamentelor de răcire din locația / site-ului principal, defectarea echipamentelor care asigură alimentarea cu energie electrică, etc.

Planul BCP:

- administrează riscurile potențiale care pot conduce la producerea unui eveniment de dezastru și astfel micșorează probabilitatea ca evenimentul să se producă;

- reduce timpul necesar reluării operațiunilor organizației prin definirea pașilor și a procedurilor ce se vor executa în cazul apariției unui eveniment de tip dezastru;

- minimizează riscurile ce pot apărea în procesul de reluare a operațiunilor organizației prin stabilirea pașilor și a deciziilor în avans în condiții normale și nu sub presiune și stres.

Planificarea proceselor în scopul asigurării continuității operaționale

Deciziile luate sub presiune și stres datorate apariției unui eveniment major au un potențial ridicat de risc, de a fi greșite, ineficiente sau cu costuri foarte ridicate pentru Structura RMU. Deși probabilitatea apariției unui eveniment major de tip dezastru este mică, apariția unui astfel de eveniment nu poate fi exclusă și poate avea loc în orice moment. Pentru limitarea pagubelor umane, materiale și de imagine se impune definirea planului BCP pentru identificarea și rezolvarea eventualelor neconformități, precum și demersul care trebuie întreprinse în vederea recuperării și întoarcerea la site-ul principal în condițiile în care locația primară a devenit inoperabilă.

Principalele aspecte care trebuie luate în considerare în cadrul planului BCP sunt:

Înaltă Disponibilitate (High availability) este capacitatea de a asigura accesul la aplicații indiferent de defecțiunile locale, chiar dacă aceste probleme sunt în procese organizaționale, în utilități sau în echipamentele hardware sau software; acest concept a fost luat în considerare la proiectarea soluŃiei tehnice la nivelul echipamentelor și al infrastructurii;

Continuitatea operațiunilor este capacitatea de a menține lucrurile să ruleze atunci când totul funcționează corespunzător; excepții pot face operațiunile planificate de mentenanță sau de backup;

Recuperarea în caz de dezastru (Disaster Recovery) este capacitatea de a recupera un centru de date prin intermediul unui site diferit situat într-o locație geografică diferită, dacă un dezastru distruge site-ul

Prioritizarea operațiunilor

•Analiza riscurilor

•Analiza de impact a riscurilor

•Evaluare BCP

Integrarea în cadrul infrastructurii

•Design BCP

•Design strategie IT

•Implementare

Management

•Validarea programelor

•Gestionarea procesului de recuperare


primar care devine astfel inoperabil. Specificul unei soluții de recuperare în caz de dezastru presupune continuarea activităților într-o altă locație și pe un hardware diferit.

Elementele implicate în cadrul unui plan BCP sunt:

- Strategia; - Personalul; - Procesele; - Tehnologiile utilizate și echipamente hardware pe care sunt instalate aplicațiile; - Datele stocate în sistem; - Utilități.

4 Descrierea sistemelor critice

În continuare este prezentată componenta critică a sistemului RMU vizată în cadrul planului BCP – Portalul central RMU. Aplicația locală instalată la nivelul fiecărui universități nu face obiectul prezentei proceduri, fiecare universitate fiind responsabilă de buna funcționare a acestei componente, implicit de confidențialitatea, disponibilitatea și integritatea datelor proprii.

4.1 Descrierea generală a Portalului central RMU

Scopul principal al Portalului RMU presupune realizarea unei baze de date comună cu toate persoanele din învățământul superior și identificarea în mod unic a persoanelor, prin atribuirea și implicit generarea unui Număr Matricol Unic la nivelul RMU.

Portalul central RMU își propune colectarea informațiilor furnizate de universități și expunerea acestora în diverse formate de raportare. Pentru realizarea bazei de date centralizate, Portalul RMU extrage datele despre studenți/masteranzi/doctoranzi de la fiecare universitate acreditată sau autorizate să funcționeze provizoriu.

Abatere și consolidare

Adaptare și optimizare

Protectie și conservare

Control și conformitate

Anticipare și detectare


Portalul poate fi accesat atât de utilizatorii publici (fără niciun fel de autentificare), precum și de utilizatorii privați (cei care accesează aplicația cu nume de utilizator și parolă). Utilizatorii privați vor avea acces, în funcție de rolul fiecăruia în sistem, la diferite funcționalități ale aplicație.

La nivel de categorii de utilizitatori, fiecare student va beneficia, la cerere, de un cont de acces în Portalul RMU. Totodată, fiecare universitate va avea în mod obligatoriu un cont în Portalul RMU care va fi utilizat și pentru exportul datelor despre studenți din aplicațiile locale către Portalul RMU.

Portalul central RMU este interconectat cu toate aplicațiile locale RMU de culegere și validare a datelor, iar schimbul de informații se realizează biunivoc:

- Portalul central RMU va expune către aplicațiile locale versiunile nomenclatoarelor ce vor utilizate pentru exportul datelor către centru;

- Aplicațiile locale vor exporta datele către Portalul central RMU (exportul datelor se va realiza folosind conturile universității respective).

4.1.1 Descriere roluri utilizatori la nivel central

Rolurile sistemului vor asigura accesul la anumite categorii de informații. Fiecare utilizator din sistem va avea un rol predefinit de administratorul RMU. În momentul în care se generează un nou utilizator, administratorul RMU va selecta rolul acestui utilizator în sistem.

Sistemul va avea următoarele roluri:

- administratorul – are acces la secțiunea de administrare a portalului RMU; editează zonele publice din Portalul RMU; operatorii vor edita sectiunea de informaŃii generale şi secŃiunea cu fişiere care vor fi afișate în zona publică a Portalului RMU;

- manager – acces să vizualizeze toate datele (accesul se va realiza prin intermediul rapoartelor puse la dispoziție de administratorul RMU și publicate prin Oracle BI);

- student – acces numai la datele personale; - universitate – acces numai la datele raportate de universitatea respectivă; În cadrul

aceste categorii se disting două sub-categorii: manager și operator universitate, fiecare cu funcționalitățile aferene;

- acces instituții – acces numai la setul de date pus la dispoziție de administratorul RMU prin intermediul rapoartelor.

Aceste roluri sunt gestionate de administratorul RMU și vor fi atribuite utilizatorilor în momentul în care se face un nou cont de utilizator.


Utilizatorii vor accesa sistemul prin următoarele posibilități:

- Acces liber în secțiunile publice ale Portalului; - Acces pe baza unui nume de utilizator și a unei parole (în zonele de editare informații, în cele de administrare și în cele de vizualizare informații raportate de către universități).

4.1.2 Prezentarea fluxurilor informaționale specifice nivelului central, coroborate cu prelucările locale, de la nivelul universității

Fluxul informatic la nivel central RMU este următorul:

Pe lângă fluxul informatic general, la nivel central sunt prezente și următoarele fluxuri:

Administrator

Are acces la secțiunea de administrare a portalului RMU; Editează zonele publice din Portalul RMU; operatorii vor edita sectiunea de informaţii generale şi secţiunea cu fişiere care vor fi

afisate in zona publică a Portalului RMU

Universitate

Acces numai la datele raportate de universitatea respectivă

Manager / Operator

Student

Acces numai la datele personale

Acces institutii

Acces numai la setul de date pus la dispoziție de administratorul RMU prin

intermediul rapoartelor


4.1.2.1 Fluxul de gestiune a nomenclatoarelor

4.1.2.2 Fluxul pentru exportul datelor din aplicațiile locale către portalul RMU


4.1.2.3 Fluxul pentru deschiderea unei perioade de raportare

4.1.2.4 Fluxul pentru restaurarea unui set de date


5 Resurse și impactul lor

5.1 Echipamente hardware existente la nivelul fiecărui sistem

5.1.1 Infrastructură la nivel central

La nivel central există mai multe aplicații instalate, fiecare fiind responsabilă de anumite funcționalități ale RMU. Principalele module la nivel logic care alcătuiesc componenta centrală din RMU sunt:

- Oracle Business Intelligence Suite Enterprise Edition Plus; - Internet Application Server Enterprise Edition; - Oracle Portal; - Oracle Access Management; - Oracle Enterprise Manager Grid Control; - Oracle Database Enterprise Edition:

� Real Application Cluster; � Partitioning Pack; � Advance Security Pack; � Diagnostic Pack; � Management Pack.

Pentru a asigura redundanța și no single point of failure la nivel de servere, fiecare modul este instalat pe câte două mașini fizice identice:

Nume Rol Descriere

Db1 Nod 1 Baze de date:prod CPU: 2 x Intel Xeon x5670 2.93GHz

Memorie: 72 Gb DDR3 PC3-10600 (1333MHz)

OS: RHEL 5

Storage: -local :/oracle

-SAN : /DATA, /LOG,/CRS

Db2 Nod 2 Baze de date:prod CPU: 2 x Intel Xeon x5670 2.93GHz


OS: RHEL 5


-SAN : /DATA, /LOG,/CRS

Ias1 Server aplicatie central.rmu.ro, server OID LDAP, OAM (Oracle Access

Manager)

CPU: 2 x Intel Xeon x5670 2.93GHz


OS: RHEL 5


Ias2 Server aplicatie central.rmu.ro, server OID



Nume Rol Descriere

LDAP, OAM (Oracle Access Manager)


OS: RHEL 5


www1 Server aplicatie portal.rmu.ro , OAM

(Oracle Access Manager)



OS: RHEL 5


www2 Server aplicatie portal.rmu.ro , OAM

(Oracle Access Manager)



OS: RHEL 5


mon1 Server Monitoring CPU: Intel Xeon x5670 2.93GHz


OS: RHEL 5


mon2 Server Monitoring CPU: Intel Xeon x5670 2.93GHz


OS: RHEL 5


mon3 Server Access Management

(ORACLE BI)

CPU: Intel Xeon x5670 2.93GHz


OS: WIN 2008 Server X64 R2


mon4 Server Access Management

(ORACLE BI)

CPU: Intel Xeon x5670 2.93GHz




mon5 Server Reporting CPU: Intel Xeon x5670 2.93GHz




Nume Rol Descriere

Storage: -local

mon6 Server Reporting CPU: Intel Xeon x5670 2.93GHz



Storage: -local

Următoarea diagramă prezintă în detaliu infrastructura centrală RMU:

Workstation Workstation

portal.rmu.ro central.rmu.ro

OHS

PROD RAC

DATABASE

Identity

Server

Access

Manager

OHS

Identity

Server

WebGate

OHS

OID LDAP

Access

Server

OHS

OID LDAP

Access Server

HTTP:80 HTTPS:443

LBR

WebGate

WebPass

OC4J_RMU

WebPass

OC 4J_RMU

WWW1 WWW2

WebGate

OC4J_CENT

RAL

ias1 ias2

WebGate

OC4J_CENT

RAL

db1 db2

7777/7778 7778/7779

1521

prod1 prod2

OHS

BI SUITE

OHS

BI SUITE

mon3 mon4

bi.rmu.ro

7777/7778


5.1.2 Infrastructura de rețea pe care se face replicarea la nivelul DRC

În cadrul locației DRC este recomandat ca serverele să fie identice din perspectiva numărului și a capacității de stocare; restul de specificații tehnice ale echipamentelor trebuie să asigure buna funcționare a sistemului RMU în cazul în care locația de recuperare în caz de dezastru preia în întregime încărcarea site-ului principal.

Este recomandată utilizarea unei infrastructuri de rețea redundante din prisma firewall-ului, switch-ului și a load-balancer-ului și a ruterelor care trebuie să suporte otocolul BGPv4 pentru o comutare optimă între cele 2 locații.

5.2 Resurse umane

La nivelul Structurii RMU este recomandat să fie înființate minim următoarele poziții:

Denumirea departamentului / funcției Număr de posturi

Locația principală

Manager RMU 1

Departament IT

- Manager tehnic RMU

- Responsabil cu securitatea informațiilor

- Responsabil aplicații universități

- Responsabil baze de date

- Responsabil hardware

- Responsabil politici

6

1

1

1

1

1

1

Departament nomenclatoare și rapoarte RMU

- Manager științific RMU

- Responsabil nomenclatoare

- Responsabil rapoarte central (inclusiv ministere și alte agenții care au

drept de acces)

- Responsabil rapoarte universități și rapoarte zona publică

4

1

1

1

1

TOTAL POSTURI 11

Persoanele desemnate la nivelul locației principale vor ocupa aceleași funcții și la nivelul locației de recuperare în caz de dezastru.


5.3 Clasificarea resurselor în funcție de impact și de sistemul/aplicația instalată

În continuare sunt sintetizate informațiile prezentate anterior, permițând astfel o clasificare a resurselor în funcție de impact:

Aplicația Componenta

Registrul Matricol Unic – aplicația centrală

Aplicația Internet Application Server Enterprise Edition – 2 servere (ias 1 și 2) Oracle Portal – 2 servere (www 1 și 2)

Raportare Oracle Business Intelligence – 2 servere (mon 3 și mon 4)

Monitorizare Mon 1, 2, 5 și 6

Baza de date Oracle Database Enterprise Edition – 2 servere + SAN (db1 și 2)

Infrastructura de rețea 1 firewall 1 switch

1 load-balancer

Facilități și locația fizică Locația desemnată de UEFISCDI

Numărul de persoane alocate Minim 11

Impactul 4

Rang 1 - critic

Impactul este cuantificat conform schemei de clasificare și prezintă, dintr-o perspectivă business, necesitatea și utilitatea sistemului, precum și imaginea organizației și vizibilitatea serviciului.

Rangul este o estimare a importanței globale a aplicației/sistemului luând în considerare toți factorii identificați în tabel. Pe baza rangului se poate realiza o clasificare eficientă a resurselor.

6 Impactul riscurilor și întreruperea activităților cheie

6.1 Introducere

Obiectivul central al analizei de impact este de a permite identificarea sistemelor, a operațiilor și a proceselor esențiale continuității activității curente. Analiza de impact facilitează cuantificarea timpului în care trebuie realizată recuperarea în cazul apariției unui dezastru.

Analiza de impact își propune următoarele:

- Estimarea impactului financiar pentru sistemul central RMU în caz de dezastru; - Estimarea tipurilor de impact intangibil pentru sistemul analizat. - Estimarea timpului maxim în care trebuie realizată recuperarea.

Domeniul prezentei analize de impact este reprezentat de următoarele sisteme:

Sistem Descriere

Portalul RMU Scopul principal al Portalului RMU este realizarea unei baze de date comună cu toate persoanele din învățământul superior și identificarea în mod unic a persoanelor, prin atribuirea și implicit generarea unui Număr


Matricol Unic la nivelul RMU. Portalul central RMU colectează informațiile furnizate de universități și le expune în diverse formate de raportare.

6.2 Evaluări

6.2.1 Tabelul riscurilor analizate

Matricea de punctare a riscurilor în funcție de coeficienții de impact este următoarea:

Valoare Impact

1 Minim

2 Semnificativ

3 Major

4 Critic

Risc posibil Impact Recuperare on-site

Recuperare off-site

Coeficient impact

Inundații Major NU DA 3

Căderi IT Major DA DA 3

Căderi energie electrică

Semnificativ DA DA 2

Pierderi de personal

Critic DA DA 4

Pierderi de informații critice

Critic DA NU 4

Incendii Critic NU DA 4

Cutremur Critic NU DA 4

6.2.2 Analiza impactului financiar zilnic/sistem

În cadrul calcului financiar trebuie inclusă o estimare a pierderilor pe zi în cazul în care sistemul nu este disponibil.

Sistem Estimarea financiară zilnică

Portal RMU 0 Lei întrucât proiectul nu este generator de venituri și nu se percep penalități pentru indisponibilitatea serviciilor

Indiferent de orizontul de timp considerat, nu există pierderi financiare generate de indisponibilitatea sistemului.

6.2.3 Estimarea tipurilor de impact intangibil

Spre deosebire de analiza impactului financiar în cadrul căreia nu au putut fi identificate costuri și cheltuieli, în cadrul analizei de impact intangibil s-au luat în considerare următoarele categorii:

- Imaginea organizației în raport cu utilizatorii și cu instituțiile implicate în proiect; - Asigurarea serviciilor din perspectivă operațională;


- Satisfacția utilizatorilor; - Relația cu instituțiile implicate în proiect, partenere sau de reglementare.

Sistem / Impact Imagine Operațional Satisfacție utilizatori

Instituții partenere sau de

reglementare

Indisponibilitate

1 h

1/2

d

1 d

3 d

5 d

1 h

1/2

d

1 d

3 d

5 d

1 h

1/2d

1 d

3 d

5 d

1 h

1/2d

1 d

3 d

5 d

Portal RMU

Nivel de impact Reprezentare

Minim

Semnificativ

Major

Critic

6.2.4 Timpul maxim în care trebuie realizată recuperarea

Pentru limitarea impactului, recuperarea în cazul apariției dezastrelor prevăzute se va realiza după următoarele coordonate în vederea evitării situațiilor cu impact major și/sau critic:

Aplicație Timp recuperare

Portal RMU < ½ zi

Pornind de la valorile identificate pentru portalul RMU se determina timpul de recuperare maxim în cazul producerii unui dezastru care trebuie să fie de ordinul orelor, sau în cel mai rău caz 1 zi, pentru a evita neplăcerile aduse utilizatorilor / instituțiilor partenere sau de reglementare și pentru a minimiza impactul asupra bunei funcționări a sistemului RMU.

CRITIC

MAJOR

SEMNIFICATIV

MINIM


6.3 Analiza de impact asupra activității curente

În continuare se regăsește extinderea analizei de impact și asupra activităților / fluxurilor informaționale existente în cadrul sistemului RMU:

Funcționalitate asigurată Departament responsabil

Responsabil (funcție și

nume)

Repartizarea în timp

Ore critice Impact Implica

penalități?

Timp maxim de indisponibilitate

(RTO)

Nivelul de refacere

după accident

(RPO)

Modulul public

Vizualizare informații generale Portal Departament IT Manager tehnic continuu - 1 nu 1 săptămână total

Vizualizare actualizare situații statistice Departament IT Manager tehnic continuu - 2 nu 1 zi total

Vizualizare profil student pe baza unei chei de acces de către o terță entitate

Departament IT Manager tehnic continuu - 3 nu ½ zi total

Înscriere utilizatori privați Departament IT Manager tehnic continuu - 2 nu 1 zi total

Modulul cu acces restricționat

Secțiune destinată fiecărui student

Modificare profil student Departament IT Manager tehnic continuu - 2 nu 1 zi total

Vizualizare informații personale cu privire la traseul educațional

Departament IT Manager tehnic continuu - 2 nu 1 zi total

Crearea unui cont temporar pentru vizualizarea informațiilor puse la dispoziție de către student


Secțiune destinată fiecărui universități

Modificare date de contact și date aferente contului universității

Departament Rapoarte și Nomenclatoare

Manager științific continuu - 2 nu 1 zi total

Vizualizare informații raportate din aplicația locală

Departament Rapoarte și



Nomenclatoare

Introducere și generare conturi destinate studenților

Departament IT Manager tehnic zilnic 8-17 2 nu 1 zi total

Secțiune destinată operatorilor

Modificare date de contact și date aferente contului de operator


Introducere/modificare date afișate în secțiunile publice ale Portalului


Manager științific continuu - 3 nu ½ zi total

Secțiune destinată managerilor

Modificare date de contact și date aferente contului de manager


Vizualizarea tuturor datelor raportate de către universități



Secțiune destinată utilizatorilor proveniți din alte instituții

Modificare date de contact și date aferente contului aferent unei instituții


Vizualizare rapoarte puse la dispoziție de administratorul RMU



Secțiune destinată exportului de informații către alte aplicații

Publicare rapoarte sub forma unor fișiere export (.pdf, .xls, .csv, .xml)



Export nomenclatoare sub forma unor servicii web



Modulul de administrare

Gestiune (adăugare, modificare, ștergere) Departament IT Manager tehnic zilnic 8-17 3 nu ½ zi total


Descriere coloane

Nume coloană Descriere

(1) Funcționalitate asigurată Funcționalitățile care sunt prezentate utilizatorilor autentificați în modulul respectiv

(2) Departament responsabil Departamentul care răspunde de îndeplinirea activităților care stau la baza fluxului

(3) Responsabil Persoana responsabilă (funcție + nume) din cadrul departamentului însărcinat de îndeplinirea respectivelor activități;

(4) Repartizarea în timp Modul în care este repartizată în timp activitatea (continuu pe durata zilei, la anumite ore, etc.)

(5) Ore critice Orele din timpul zilei în care activitatea respectivă trebuie să se poată desfășura; altfel sistemul devine nefuncțional în ansamblul sau exista constrângeri externe (ale altor instituții) în caz de nefuncționare

utilizatori RMU în conformitate cu cele 4 tipuri de conturi (studenți, responsabili universități, acces de la instituții, acces la servicii web)

Gestiunea exportului (normal sau corector) din aplicația locală instalată la universități

Departament IT Manager tehnic continuu în perioadele de raportare sau excepții în cazul exportului corector

- 4 nu 2 ore total

Restaurare set de date exportat anterior Departament IT Manager tehnic continuu - 3 nu ½ zi total

Generarea de rapoarte și atribuirea acestora pe roluri


Manager științific continuu - 2 nu 2 ore total

Configurare export de date din RMU către alte instituții



Logare informații și inspectarea periodică a logurilor sub formă de rapoarte

Departament IT Manager tehnic continuu - 3 nu ½ zi total

Generare număr matricol unic Departament IT Manager tehnic continuu - 3 nu ½ zi total


(6) Impact Valori posibile: 1 - Minim - sistemul per ansamblu este funcțional și fără activitatea descrisă și nu există alte constrângeri

2 – Semnificativ – performanța sistemului este afectată, funcționalitatea unor componente este compromisă

3 – Major – performanța sistemului este grav afectată, doar puține funcționalități sunt disponibile 4 – Critic - sistemul este complet nefuncțional

(7) Implica penalități Dacă indisponibilitatea acelei activități implică penalități pentru organizație

(8) Timp maxim de indisponibilitate (RTO)

Care este timpul maxim permis de indisponibilitate al activității pentru organizație?

(9) Nivelul de refacere după accident (RPO)

De specificat nivelul minim necesar de reluare al activității respective: total sau parțial (dacă parțial atunci de detaliat nivelul de atins)


6.4 Concluziile analizei impactului asupra activității curente

În urma analizei impactului riscurilor se pot trage următoarele concluzii:

1. Definirea evenimentelor critice

Soluția și serviciile de protecție pentru situații de dezastru vor acoperi următoarele evenimente:

- dezastru natural: cutremur (mai mic de 8.5 grade Richter) care conduce la prăbușirea parțială sau totală a locației primare RMU, inundații, incendiu care conduce la distrugerea centrului de date;

- căderi energie electrică; - căderi echipamente IT; - pierderi de personal; - pierderi de informații critice.

2. Identificarea aplicațiilor critice din cadrul sistemului RMU: Portalul central RMU

3. Disponibilitatea sistemului

Sistemul și serviciile de protecție pentru situații de dezastru trebuie să asigure reducerea riscurilor de indisponibilitate a sistemelor de producție cu o recuperare completă a funcționalității sistemelor informatice într-un interval orar de ordinul orelor.

4. Toleranța la dezastru

Toleranța la dezastru este asigurată prin tehnologia și serviciile cu grad înalt de disponibilitate care determina continuarea operării sistemelor critice în cazul unui dezastru – în cadrul sistemelor RMU aceasta toleranță trebuie să fie mică pentru garantarea continuității operaționale (trebuie asigurat un grad cât mai ridicat de toleranță la defecte).

5. Restaurarea serviciilor (RTO - Recovery Time Objective)

Timpul de restaurare a serviciilor reprezintă timpul scurs între producerea incidentului critic care a determinat inoperabilitatea site-ului principal și reluarea funcționalității sistemului de către locația de recuperare.

În cadrul arhitecturii existente, timpul estimat este de 1 oră în cazul comutării totale datorită constrângerilor impuse de tehnologii, identificarea riscului și a măsurilor necesare, convocarea persoanelor responsabile și asigurarea întregii funcționalități la nivelul centrului de recuperare.

În cazul comutării manuale în care este necesară și identificarea incidentului, timpul estimat de recuperare este de 15 minute.

În anumite circumstanțe, în condițiile în care comutarea se realizează automat și nu s-a produs un incident major, timp de recuperare poate fi redus substanțial.

6. Pierderile de date (RPO - Recovery Point Objective)

Pierderile de date reprezintă valoarea reală a pierderilor de date din momentul producerii incidentului până la recuperarea acestuia, sau volumul de date care trebuie recreat pentru a se asigura integritatea datelor.

Cantitatea de date acceptate a fi pierdute în cazul unui dezastru depind de următorii factori:

- cantitatea de date modificate (mediu/maxim) pe unitatea de timp; - interdependența dintre aplicațiile care compun sistemul informatic;


- calitatea, mediul și lățimea de bandă a conexiunilor dintre cele doua locații.

Pe baza arhitecturii propuse se poate estima diferența dintre locația principală și cea de recuperare care este de ordinul minutelor (5-10 minute) datorită latenței legăturii, echipamentelor de interconectare între cele două locații și încărcarea cozii de replicare.

7 Condiții contractuale și parteneri și colaboratori cheie pentru apel în caz de dezastre

Din punctul de vedere al furnizorilor de echipamente și al furnizorilor de servicii de Internet vor fi definite Service Level Agreements (SLA) prin care sunt specificate mecanismele utilizate pentru gestionarea contractului cadru și a contractelor specifice bazate pe el. În plus, acesta oferă indicatori de nivel de serviciu și parametri de calitate legate de serviciu.

Un SLA include definirea listei de servicii oferite clientului, acoperirea, organizarea, gestionarea și nivelul cerințelor de serviciu; de asemenea se stabilește un nivel minim garantat.

Recomandări pentru un SLA:

- Definirea disponibilității sistemului și a serviciului: o În cazul furnizorilor la Internet următorii factori trebuie luați în considerare:

procent uptime conexiune de preferat la nivel de lună (99,9%), lățimea de bandă garantată și timpul de intervenție în cazul pierderii conectivității (2-3 ore pentru intervenție și soluționare);

o În cazul furnizorilor de echipamente este recomandată: garanția tuturor echipamentelor de minim 2 ani conform legislației în vigoare, specificarea numărului de echipamente și configurația lor garantate pe stoc, timpul de intervenție și de schimb al echipamentelor cu unele noi în cazul unei distrugeri totale (8 ore pentru intervenție de la sesizare, cu minim 2 experți în funcție de necesitatea intervenției și 12 ore pentru remedierea defectului);

o Garanția software care să acopere următoarele: testarea și instalarea de patch-uri de securitate, dezvoltarea de actualizări software în vederea asigurării conformității cu specificațiile funcționale, în cazul în care sistemul devine neconform din cauza independente de beneficiar, instalarea patch-urilor funcționale din partea producătorilor software-ului de bază dacă sunt necesare pentru funcționarea aplicațiilor, disponibilitatea de a dezvolta, în cadrul unor proiecte separate, funcționalități suplimentare;

- Definirea cât mai clară a interfețelor, rolurilor și responsabilităților; - Realizarea monitorizării serviciilor și a echipamentelor; - Notificările generate în urma monitorizării echipamentelor / conexiunii la Internet; - Procedurile de comunicare în cazul producerii incidentelor, persoanele de contact,

cererile de urgență, escaladare; - Clasificare probleme în funcție de gravitate, garantarea timpului maxim de răspuns și

definire follow-up pentru revizuire și monitorizare ulterioară; - Confidențialitatea datelor și a informațiilor, caracterul clasificat al acestora; - Asigurarea politicilor de QoS și o disponibilitate ridicată a serviciilor; - Definirea de penalități în cazul nerespectării clauzelor contractuale.


De asemenea, pe parcursul fazei de operare trebui asigurat din partea Dezvoltatorului un nivel minim al disponibilității serviciului astfel (contractual pe o perioadă de 3 ani de la finalizarea implementări):

- Timp de intervenție on-site: maxim 1 oră pentru probleme cu un nivel de gravitate între 1 și 3 , respectiv maxim 4 ore pentru nivelul 4;

- Remediere incident Nivel 3 - 72 ore; - Remediere incident Nivel 2 - 24 ore; - Remediere incident Nivel 1 - 8 ore;

Pentru orice alt tip de problemă semnalată şi pentru care activitatea se desfășoară aproape normal (cu impedimente minore sau fără),timpul de soluționare a problemei va fi de maximum 72 de ore de la semnalare (în timpul orelor de program).

Prioritățile pentru incidentele semnalate sunt următoarele:

Nivel de gravitate Prioritate Descriere

Nivel 1 Critică Funcționalitățile de bază ale sistemului se opresc complet și constant sau lipsesc și sistemul RMU nu este funcțional; sunt afectați toți utilizatorii sistemului.

Nivel 2 Majoră

Funcționalitățile de importanță majoră ale sistemului lipsesc sau nu sunt conforme cu specificațiile, sistemul funcționând eronat în mod constant sau continuu. Sunt afectați un număr mare de utilizatorii ai sistemului. În acest scenariu unele funcții sau componente RMU nu sunt funcționale

Nivel 3 Medie

Funcții de importanță medie, dar care nu sunt vitale sau critice pentru utilizarea sistemului, lipsesc sau sunt afectate de defecte în mod continuu sau repetat. Sunt afectați un număr mic de utilizatorii ai sistemului. De asemenea unele funcții sunt limitate, dar sistemul este operaționale per total.

Nivel 4 Mică Sistemul funcționează normal cu impedimente minore. Nu sunt afectați utilizatorii sistemului, existând exclusiv probleme minore; sistemul RMU este operațional.

De asemenea, documentația de mentenanță va cuprinde, pentru fiecare categorie, cel puțin următoarele capitole:

- Mentenanță periodică: proceduri de întreținere; - Testarea periodică a funcționalităților; - Verificarea logurilor, praguri de atenție și de alarmă pentru cei mai importanți parametrii

de sistem; - Remedierea celor mai frecvente erori.

Printre partenerii și colaboratorii la care Structura RMU poate / trebuie să apeleze în condițiile unor dezastre se numără:

- Serviciul Pompieri și serviciul SMURD; - Serviciul Ambulanță; - Poliția și Jandarmeria Română.


8 Planul BCP (Business Continuity Plan)

Pentru definirea planului BCP trebuie luați în considerare următorii factori:

- reducerea riscurilor; - planul de urgență (Emergency Plan).

Reducerea riscurilor implică în primul rând identificarea lor, a impactului evenimentelor asupra departamentelor sau a locației centrale ceea ce ar putea conduce prin escaladare la generarea unui eveniment major de tip dezastru.

Planul de urgență (Emergency Plan) înseamnă în primul rând administrarea situației de criza (procesul Incident Management). La producerea unui eveniment trebuie avut în vedere prevenirea extinderii acestuia și prin escaladare generarea unui eveniment major de tip dezastru.

În funcție de tipul incidentului și de gravitatea acestuia, o prima măsură de luat în considerare este evacuarea personalului dacă situația o impune, însă trebuie avut în vedere salvarea și a informațiilor esențiale și a mediilor pe care acestea se găsesc fără a risca integritatea și sănătatea personalului respectiv.

Funcția Incident Management este de definire a răspunsului la un eveniment de criză ce poate apărea în locația primară. Astfel vor fi asigurate:

- prevenirea accidentelor; - distribuirea de materiale de protecție, evacuarea în ordine a personalului dacă situația o

impune (cazul producerii unui dezastru natural); - prevenirea extinderii evenimentului într-un eveniment major; - reducere și control a efectelor incidentului; - asigurarea pornirii procesului de salvare și reparare.

Funcția Incident Management lucrează în strânsă legătura cu serviciile de urgență dacă tipul evenimentului implica acest lucru. Exemplu: în cazul unui incendiu se va escalada imediat serviciul de pompieri, funcția Incident Management fiind obligată să conlucreze cu aceștia pentru rezolvarea evenimentului.

Câteva dintre caracteristicile incidentelor de care trebuie ținut cont sunt:

- Se poate declanșa în orice moment inclusiv în momente de timp nelucrative; - Este impredictibil, nu se poate ști cu precizie când se va întâmpla, ce forma va lua, cât de

mari vor fi pagubele produse și cu ce impact asupra imaginii sistemului RMU; - Necesită un răspuns de urgență inițial; - S-ar putea să perturbe în mod semnificativ operațiunile din cadrul Structurii RMU; - S-ar putea să reducă credibilitatea și gradul de încredere al utilizatorilor sistemului RMU; - Ar putea avea efect și asupra activităților unor terți.

Impactul pe care îl poate produce un eveniment variază foarte mult de la distrugerea totală a sediului central, a infrastructurii și a datelor senzitive, la distrugere parțială care face inoperabil locația primară, la niciun fel de distrugere însă accesul în sediul central este restricționat din cauza unei alerte (de exemplu: alertă cu bombă) sau la pierderea ambelor conexiuni la Internet din locația primară. Scopul planului BCP

nu este de a trata cauzele evenimentelor ci impactul pe care acestea îl pot provoca.

Fazele critice ale incidentelor presupun gestionarea rolurilor, activităților și responsabilităților diferitelor faze ale incidentelor. În cazul producerii unui incident următoarele faze critice sunt identificate:


Faza de răspuns imediat la incidentul critic este demarată o dată cu generarea evenimentului sau de la identificarea apariției unui incident și stabilirea posibilității propagării lui. În funcție de tipul evenimentului sau a incidentului vor fi aplicate procedurile prestabilite tipului de eveniment respectiv incident. Exemplu: în cazul depistării apariției unui incendiu la nivelul locației centrale grupul va aplica procedurile aferente acestui tip de eveniment (escaladare la serviciul de pompieri, evacuarea clădirii pentru salvarea vietilor personalului, etc).

Faza de gestionare a crizelor din perioada critică a incidentului începe imediat după faza de răspuns imediat la incidentul critic. Se va identifica situația din teren și în funcție de tipul incidentului se va decide activarea planului BCP. Este posibil activarea planului BCP chiar dacă nu s-a întâmplat un incident major la nivelul locației principale RMU, însă a fost identificată o cauză care poate conduce la un eveniment critic.

Faza de recuperare poate dura de la câteva ore, la câteva zile sau chiar săptămâni după producerea evenimentului, ea terminându-se în momentul în care sistemul reintră în operarea normală în sediul central sau în altă locație. În această faza se restaurează sistemele și aplicațiile vitale.

Faza de restaurare, evaluare și review după incident asigura reintrarea în operarea normală și evitarea producerii unui eveniment asemănător în viitor. Ea pornește prin identificarea pagubelor provocate de către eveniment și identifica mecanismele și resursele necesare reintrării în operarea normală. De asemenea se realizează o evaluare pentru revizuirea procedurilor existente cu scopul evitării reproducerii incidentului sau îmbunătățirea performanțelor din punctul de vedere al timpului necesar recuperării, persoanele implicate și resursele utilizate.

De asemenea elementele de bază ale planului BCP sunt următoarele:

- locația cu rol de protecție pentru situații de dezastru;

- infrastructura IT necesară: soluția de disaster recovery;

- resursele umane ce vor realiza operațiile de repunere în operare a sistemelor și aplicațiilor critice.

Faza1• Răspuns imediat la incidentul critic

Faza 2• Gestionarea crizelor din perioada critică a incidentului

Faza 3• Recuperarea după incident

Faza 4• Evaluarea și review-ul după incident


Lista de notificare în cazul producerii unui dezastru este următoarea:

Nr. Crt. Nume Prenume Adresă Număr Telefon Funcție Departament

1. Manager RMU

2. Manager tehnic RMU

3. Manager științific RMU

4. Responsabil cu securitatea informațiilor

5.

6.


8.1 Verificări preliminare în timpul realizării / actualizării BCP-ului

- Verificarea existenței planului de evacuare a personalului în caz de incendiu; - Verificarea existenței echipamentelor de protecție și de stingere a incendiilor la nivelul

camerei centrului de date; - Verificarea existenței echipamentelor de protecție și stingere a incendiilor la nivelul

camerelor și a holurilor locației centrale; - Verificarea existenței planului de testare și a raportului echipamentelor de protecție și

de stingere a incendiilor; - Verificarea existenței planului de evacuare a personalului în cazul unei amenințări cu

bombă; - Verificarea existenței listei de furnizori pentru reparații pentru situații de urgență

(conducte de apă, instalație electrică, etc.); - Verificarea existenței politicii de backup pentru sistemele Portalului central RMU; - Verificarea politicii de stocare a datelor în afara sediului locației principale; - Verificarea accesului și că nu existentă holuri blocate cu echipamente voluminoase; - Verificarea accesului către și dinspre clădire, dacă sunt mașini parcate în fața intrării

și respectiv a ieșirilor de urgență; - Verificarea gradului de uzură al clădirii; - Verificarea gradului de uzură al infrastructurii de apă a clădirii; - Verificarea gradului de uzură al infrastructurii electrice a clădirii.; - Verificarea existenței împământării corecte a infrastructurii electrice a clădirii; - Verificarea existenței echipamentului de protecție la trăsnet;

Pentru limitarea riscurilor se vor lua următoarele măsuri:

- acces restricționat în incinta centrului de date. Accesul în incinta centrului de date pentru personalul administrativ se realizează numai pe baza de listă de acces cu cod unic. Pentru intervenții executate de către furnizori externi accesul în centrul de date se face numai însoțit de către o persoana cu drept de acces în incintă și pe toata durata intervenției;

- acces restricționat la echipamentele IT critice componentelor aplicației. Accesul la echipamentele IT critice componente ale Portalului RMU se realizează numai pe baza de lista de acces cu cont și parolă unică. Intervențiile executate de către furnizori externi se vor realiza numai în prezența unui reprezentant desemnat din partea Structurii RMU cu drept de acces la echipamentul respectiv, intervenția executându-se în prezența acestuia pe toată durata ei;

- verificarea periodică a echipamentelor de protecție pentru căderi ale surselor de tensiune. Se vor verifica periodic (minim o data pe luna) atât echipamentele de tip UPS cât și generatorul de energie electrică;

- verificarea periodică a stării infrastructurii electrice a clădirii în vederea identificării unor posibile defecțiuni ce pot conduce la incendii sau căderi ale surselor de energie electrică;

- verificarea periodică a stării infrastructurii de protecție la trăsnet și a împământării clădirii;

- verificarea periodică a echipamentelor componente infrastructurii aplicației critice: servere, echipamente de comunicații, echipamente de backup, etc.;

- verificarea periodică a politicii de backup cu restaurare a datelor; - verificarea periodică a accesului ușor pe holurile clădirii pentru situații de urgență.

Obiectele voluminoase vor fi îndepărtate și stocate în locuri special amenajate pentru a se permite un flux ușor personalului organizației pe holurile și la ieșirile de urgență.


Elementele depistate cu grad de deterioare vor fi imediat înlocuite cu unele noi, intervențiile fiind anunțate responsabilului cu securitatea informațiilor pentru identificarea unor posibile riscuri și limitarea apariției unor evenimente nedorite.

8.2 Decizia de activare a planului BCP

Decizia de activare a planului BCP este luată de către responsabilul cu securitatea informațiilor după constituirea acesteia și verificarea notificării sau eminentei apariții a unui incident ce poate deveni major de tip dezastru. Astfel se decide dacă evenimentul este de tip dezastru și dacă se impune activarea planului BCP. De asemenea, după terminarea evenimentului și reconstrucția locației principale și a aplicațiilor critice se anunță terminarea planului BCP și reoperarea pe locația nouă de producție.

8.3 Sosirea echipei de recuperare în locația de protecție pentru situații de dezastru

Adresa locației secundare (de recuperare i cu rol de protecție pentru situații de dezastru este [DE DEFINIT].

La sosirea echipei de recuperare în locația de protecție pentru situații de dezastru se vor verifica următoarele:

- personalul, starea acestuia și componența echipei/echipelor de recuperare; - în funcție de numărul și calificarea personalului sosit în centrul de protecție pentru

situații de dezastru se decide dacă se așteaptă sosirea și a celorlalți membri sau se pot porni activitățile de recuperare conform planului BCP;

- se verifica dacă documentele necesare realizării pașilor planului BCP au sosit sau există în locație (documentul cu parolele conturilor administrator, procedura de recuperare, etc);

- se verifica accesul la echipamentele soluției de disaster recovery, integritatea bazelor de date.

După luarea deciziei de realizare a pașilor pentru recuperarea activităŃii pe locația de protecție pentru situații de dezastru echipa de recuperare realizează pașii și procedurile respective.

8.4 Punerea în funcțiune a serviciului de tip Help Desk (serviciu suport)

Managerul RMU împreună cu responsabilul cu securitatea informațiilor au obligația de a realiza și de a pune în operare serviciul de tip Help Desk conform standardelor și procedurilor Structurii RMU și de a realiza interfața între utilizatori și locația cu rol de recuperarea în caz de dezastru. Acest lucru este necesar pentru asigurarea comunicării corecte și la timp a activităților și a stării acestora între instituțiile implicate și noul centru de date.

Recomandarea este ca în momentul implementării să fie definitivată o listă cu persoanele care vor fi asignate acestui centru de tip serviciu suport.


8.5 Comutarea

Comutarea între locația primară și cea de recuperare în caz de dezastru trebuie să se poată realiza în 2 moduri: Manual și Automat.

Comutarea controlată se realizează în următoarele cazuri:

- mentenanță pe serverele principale; - probleme cu site-ul principal; - verificarea anuală a comutării controlate;

Pentru aceasta procedura sunt implicate serviciile:

- Comunicații; - Sisteme de operare; - Baze de date; - Aplicații.

Procedura de comutare controlată se va efectua în următoarele etape:

- Procedura pentru comutarea aplicațiilor; - Comutarea controlată din punctul de vedere al comunicației; - Comutarea controlată din punctul de vedere al sistemelor de operare; - Comutarea controlată din punctul de vedere al bazei de date.

Detalii referitoare la procedura de replicare și la cea de comutare se vor regăsi separat documentate.

Comutarea automată de pe site-ul principal pe locația de recuperare este recomandat să se realizeze prin configurarea protocolului BGP pe ruterele RMU. Sistemul autonom al RMU va fi anunțat atât din București cât și din DRC, cu o prioritate mai mare pentru locația principala. În cazul unui dezastru, sau în cazul în se pierde conexiunea cu ambii furnizori de servicii Internet din București, clienții vor fi rutați automat de către ISP-ul propriu către DRC. Aici se vor face mapările adreselor publice cunoscute și anunțate în DNS către adresele IP interne ale serverelor corespunzătoare din DRC. Toate ruterele sistemului RMU (București + 2 DRC) vor rula protocolul BGPv4 cu câte un furnizor de servicii Internet diferit. Trebuie luat în considerare ca cei doi furnizori din locația de recuperare să nu folosească același unic transportator către București.

Comutarea automată este doar totală și presupune indisponibilitatea accesului din exterior la Portalul central RMU din locația principală (ex. compromiterea legăturilor la Internet din partea furnizorilor din București, compromiterea ruterelor de acces din București).

În cazul comutării automate, revenirea la locația primară nu trebuie să fie automată, deoarece pe perioada de indisponibilitate a locației primare pot să apară inconsistențe la nivelul bazelor de date și este necesară o perioadă pentru replicarea în sens invers între locația de recuperare și locația primară.

Comutarea manuală presupune configurarea echipamentelor de către administratori sau de persoane desemnate de Structura RMU.

Comutarea manuală se va putea realiza la 2 nivele:

- Comutarea manuală totală realizată de administrator prin schimbarea metricilor și forțarea comutării pe locația de recuperare și invers pentru întoarcerea la locația primară;


- Comutarea manuală selectivă – se va realiza la nivelul unuia sau mai multor subsisteme prin intermediul aplicației oferite și prin configurarea la nivelul firewall-urilor care în mod default preferă echipamentele locale; cererile vor sosi tot în București și vor fi rutate prin VPN în locația de recuperare; răspunsurile vor fi rutate tot la nivel de firewall-uri prin VPN înapoi în București, astfel asigurând transparența la nivelul utilizatorilor.

În momentul implementării soluției de recuperare în caz de dezastru vor fi anexate procedurile detaliate cu instrucțiunile necesare la nivelul fiecărui echipament sau prezentarea scripturilor care eficientizează / facilitează comutarea manuală între cele 2 locații.

De asemenea va fi posibila modificarea configurației la nivelul switch-urilor de layer 3 din București pentru rutarea traficului primit pe site-ul primar prin conexiunile VPN către locația de recuperare și rezolvarea cererilor remote.

Un alt aspect important care trebuie luat în considerare este adresarea IP a sistemelor din DRC care va fi identică în ceea ce privește porțiunea de host, însă diferită în zona de rețea. Astfel se asigura comunicația de replicare peste conexiunile VPN. Se recomandă ca totalitatea subnet-urilor dintr-un site să poată fi agregate pentru a putea folosi facilitățile de sumarizare și rute statice. De asemenea, se recomandă ca translatarea de adrese (NAT public�privat) să fie făcută pe switch-urile de layer 3 sau pe firewall-uri/VPN-uri pentru a permite comutarea manuală a unui singur sistem.

8.5.1 Semnarea procesului verbal de constatare a comutării manuale

La finalul execuției operațiunilor de comutare manuală pe locația de recuperare pentru situații de dezastru se va semna procesul verbal de constatare a comutării. Procesul verbal va conține minim următoarele date:

- ora la care a fost lansat ordinul de comutare; - ora la care a fost disponibilă echipa de recuperare în locația de recuperare pentru

situații de dezastru; - ora la care s-a încheiat procesul de comutare a conexiunilor; - ora la care s-a încheiat procesul de comutare; - starea operațională a sistemului din locația de protecție pentru situații de dezastru; - propuneri de modificare a procedurilor de comutare pentru eliminarea eventualelor

neconformități descoperite la nivelul celor două locații; - observații.

8.6 Replicarea

Replicarea în timp real se va realiza la nivelul fiecărei componente a Portalului central RMU la nivel de sistem de fișiere (byte-level replication) și la nivel de baza de date unde acest lucru este considerat oportun.

Update-ul aplicațiilor se va face automat prin procesul de replicare. Trebuie definite regiunile care vor fi sincronizate automat împreună cu Dezvoltatorul, precum și o procedură în cazul unor update-uri ce conțin informații specifice unei locații (cum ar fi elemente de adresare IP codate în aplicație, adăugarea unor servicii externe aplicației care nu sunt disponibile încă în DRC, etc.). Unele sisteme vor necesita reconstrucția de la zero (ex. configurațiile echipamentelor de rețea – firewall, switch-uri, rutere).

Este recomandat ca replicarea să se realizeze folosind o soluție software de replicare integrată. Pentru toate serverele Windows aplicația va realiza replicarea asincronă la nivel de octet (byte-level


replication) pentru zonele definite, protecție completă a serverului cu funcție de comutare pe serverul secundar ce poate prelua numele, adresa IP și configurația mașinii sursa. Toate serverele identificate în tabelul de replicare se vor afla sub aceeași umbrelă.

Aplicația de replicare va permite replicarea în ambele sensuri. Astfel recuperarea locației principale în caz de incident critic va fi realizată prin intermediul aceleași aplicații, dar va fi necesară o perioadă pentru sincronizarea datelor și pentru asigurarea integrității la nivelul locației primare.

De asemenea, pentru a evita compromiterea informațiilor (coruperea datelor din cauza virușilor, hacking, etc), soluția de replicare va permite realizarea de shadow copies / snapshot-uri în timp real sau alte mecanisme similare la nivelul bazelor de date.

Din punct de vedere al serverelor, arhitectura se bazează pe replicare automată de la serverul sursă (de producție) la server fizic destinație; la comanda administratorului sistemului se poate realiza și comutarea manuală (serverul destinație poate prelua numele, configurația IP, etc). Utilizatorii se vor conecta la fel ca înainte datorită transparenței oferite de nivelul de comunicații. Soluția ar trebui să ofere posibilitatea contopirii suitelor de câte două clustere din ambele site-uri în geo-clustere multi-nod pentru distribuția încărcării către DRC, datorită replicării transparente a storage-ului. Replicarea se va realiza prin conexiunile VPN peste rețeaua IP existentă, soluția oferind posibilitatea de setare a lățimii de bandă maxime pe care o utilizează (bandwidth throttling).

Este recomandat ca soluția de replicare automată a datelor să asigure:

- funcție de comutare (failover) a serverului de producție plecând de la nivelul sistemului de operare cu configurația acestuia, a aplicațiilor ce rulează pe acesta precum și a datelor către serverul destinație;

- funcția de comutare (failover) este de tip minim conexiune server sursa – server destinația (unu la unu) pentru servere de tip 32bit și 64bit;

- funcția de comutare (failover) asigură comutarea serverelor sursă pe servere destinație diferite din punct de vedere hardware (independența față de hardware) atât în mediu LAN cât și WAN;

- utilizează protocol standard TCP/IP fără limitare de distanță și tip de rețea: LAN, WAN, VPN sau NAT;

- oferă extensie către protecție de tip many-to-one; - oferă suport pentru compresia datelor pentru micșorarea costurilor liniilor de

comunicație; - oferă suport pentru replicare de tip asincron pentru un impact minim asupra mediului

de producției. Procesul de replicare va transfera doar modificările de la nivel de byte ale fișierului și nu tot blocul fizic sau logic sau fișierul întreg;

- permite reglarea lățimii de bandă WAN utilizată pentru replicare; - permite stabilirea intervalelor de timp pentru replicare pentru optimizarea utilizării

canalului de comunicație WAN; - restabilirea copiei în cazul întreruperii canalului de comunicație WAN se realizează la

nivel de bloc prin tehnologie de tip „block checksum”. Restabilirea copiei se realizează în mod automat la repunerea în operare a canalului de comunicații WAN dintre serverul sursă și serverul destinație;

- posibilitatea alegerii datelor ce vor fi replicate atât la nivel de director cât și la nivel de fișier;

- asigure replicarea atât a datelor criptate, compresate, fișiere cu nume foarte lungi, etc.;

- mecanism de verificare a faptului că datele destinație sunt identice cu cele sursă, la intervale de timp prestabilite sau la cerere;

- posibilitatea de execuție de scripturi pentru personalizarea și integrarea soluției; - transmiterea evenimentelor de stare prin e-mail administratorilor sistemului;


- posibilitatea administrării folosind o interfață grafică, web sau în linie de comandă pentru un grad ridicat de flexibilitate;

- protecție la erori umane, coruperi datorate programelor software de tip „virus” (ca funcție built-in sau prin integrare cu servicii existente în sistemul de operare);

- posibilitatea integrării cu aplicații de tip system management (folosind de exemplu SNMP sau syslog);

- monitorizare centralizată a proceselor de replicare și a celor de comutare (failover); - statistici și rapoarte despre procesele de replicare, starea acestora, starea sistemelor,

etc.;

Pentru asigurarea conectivității în vederea replicării datelor este necesară interconectarea la nivel 3 a subnet-urilor corelate configurate pentru replicare între cele două locații. La nivel fizic recomandăm configurarea switch-urilor de Layer 3 și a firewall-urilor folosind politici de securitate stricte. Aceste politici implică configurarea unor liste de acces care să permită doar traficul de replicare între adresele punctuale ale serverelor configurate în redundanță.

Nu se consideră o necesitate existența unor echipamente și proceduri de backup a datelor în locația de recuperare datorită caracterului permanent al liniilor de replicare. De asemenea, transportul imaginilor de backup de la București către locația secundară nu este o necesitate deoarece, datorită diferenței de timp dintre momentul creării informației și până la recuperarea acesteia în DRC, datele recuperate ar fi oricum inutile, o copie mai recentă a acestora existând deja în locația secundară.

8.7 Echipamente ”single point of failure”

La nivelul locației primare s-au identificat următoarele echipamente ”single point of failure”:

Nr. Crt. Subsistem Echipament

1. - Server virtualizare – în principal este folosit pentru testare și nu reprezintă o componentă critică în cadrul sistemului RMU

2 RMU Firewall

3. RMU Switch

4. RMU Load-balancer

La nivelul locației de recuperare în caz de dezastru s-au identificat următoarele echipamente ”single point of failure”:

Nr. Crt. Subsistem Echipament

1. - Server virtualizare – în principal este folosit pentru testare și nu reprezintă o componentă critică în cadrul sistemului RMU

9 Neconformare

Încălcarea prevederilor din cadrul acestei politici vor fi sancționate prin măsuri disciplinare în conformitate cu reglementările interne ale Structurii RMU.

Toate acțiunile care contravin legilor vor fi raportate organelor competente.


10 Revizuirea Planului de Continuitate a Activității

Planul de Continuitate a Activității trebuie să fie supus unei analize anuale urmând ca rezultatul acesteia să fie prezentat spre analiză și avizare către Managerului Structurii RMU. Documentul va fi revizuit și actualizat ori de câte ori situația de fapt a organizației, condițiile conjuncturale externe sau reglementările legislative o impun.

Revizuirea trebuie să includă evaluarea necesităților de control al accesului la informații în cadrul sistemului RMU, dar și demersurile de coordonare a securității informației în concordanță cu schimbările de mediu, circumstanțele de business, condițiile legale, standardele în vigoare sau mediul tehnologic.

plan de continuitate a activității - rmu.ro de continuare a activitatii... · plan de...

Documents