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.
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 3
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
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 4
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;
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 5
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
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 6
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
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 7
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.
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 8
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
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 9
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
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 10
4.1.2.3 Fluxul pentru deschiderea unei perioade de raportare
4.1.2.4 Fluxul pentru restaurarea unui set de date
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 11
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
Memorie: 72 Gb DDR3 PC3-10600 (1333MHz)
OS: RHEL 5
Storage: -local :/oracle
-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
Memorie: 48 Gb DDR3 PC3-10600 (1333MHz)
OS: RHEL 5
Storage: -local :/oracle
Ias2 Server aplicatie central.rmu.ro, server OID
CPU: 2 x Intel Xeon x5670 2.93GHz
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 12
Nume Rol Descriere
LDAP, OAM (Oracle Access Manager)
Memorie: 48 Gb DDR3 PC3-10600 (1333MHz)
OS: RHEL 5
Storage: -local :/oracle
www1 Server aplicatie portal.rmu.ro , OAM
(Oracle Access Manager)
CPU: 2 x Intel Xeon x5670 2.93GHz
Memorie: 24 Gb DDR3 PC3-10600 (1333MHz)
OS: RHEL 5
Storage: -local :/oracle
www2 Server aplicatie portal.rmu.ro , OAM
(Oracle Access Manager)
CPU: 2 x Intel Xeon x5670 2.93GHz
Memorie: 24 Gb DDR3 PC3-10600 (1333MHz)
OS: RHEL 5
Storage: -local :/oracle
mon1 Server Monitoring CPU: Intel Xeon x5670 2.93GHz
Memorie: 12 Gb DDR3 PC3-10600 (1333MHz)
OS: RHEL 5
Storage: -local :/oracle
mon2 Server Monitoring CPU: Intel Xeon x5670 2.93GHz
Memorie: 12 Gb DDR3 PC3-10600 (1333MHz)
OS: RHEL 5
Storage: -local :/oracle
mon3 Server Access Management
(ORACLE BI)
CPU: Intel Xeon x5670 2.93GHz
Memorie: 12 Gb DDR3 PC3-10600 (1333MHz)
OS: WIN 2008 Server X64 R2
Storage: -local :/oracle
mon4 Server Access Management
(ORACLE BI)
CPU: Intel Xeon x5670 2.93GHz
Memorie: 12 Gb DDR3 PC3-10600 (1333MHz)
OS: WIN 2008 Server X64 R2
Storage: -local :/oracle
mon5 Server Reporting CPU: Intel Xeon x5670 2.93GHz
Memorie: 12 Gb DDR3 PC3-10600 (1333MHz)
OS: WIN 2008 Server X64 R2
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 13
Nume Rol Descriere
Storage: -local
mon6 Server Reporting CPU: Intel Xeon x5670 2.93GHz
Memorie: 12 Gb DDR3 PC3-10600 (1333MHz)
OS: WIN 2008 Server X64 R2
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
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 14
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.
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 15
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
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 16
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ă;
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 17
- 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
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 18
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
Departament IT Manager tehnic continuu - 2 nu 1 zi total
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
Manager științific continuu - 2 nu 1 zi total
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 19
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
Departament IT Manager tehnic continuu - 2 nu 1 zi total
Introducere/modificare date afișate în secțiunile publice ale Portalului
Departament Rapoarte și Nomenclatoare
Manager științific continuu - 3 nu ½ zi total
Secțiune destinată managerilor
Modificare date de contact și date aferente contului de manager
Departament IT Manager tehnic continuu - 2 nu 1 zi total
Vizualizarea tuturor datelor raportate de către universități
Departament Rapoarte și Nomenclatoare
Manager științific continuu - 3 nu ½ zi total
Secțiune destinată utilizatorilor proveniți din alte instituții
Modificare date de contact și date aferente contului aferent unei instituții
Departament IT Manager tehnic continuu - 2 nu 1 zi total
Vizualizare rapoarte puse la dispoziție de administratorul RMU
Departament Rapoarte și Nomenclatoare
Manager științific continuu - 3 nu ½ zi total
Secțiune destinată exportului de informații către alte aplicații
Publicare rapoarte sub forma unor fișiere export (.pdf, .xls, .csv, .xml)
Departament Rapoarte și Nomenclatoare
Manager științific continuu - 2 nu 1 zi total
Export nomenclatoare sub forma unor servicii web
Departament Rapoarte și Nomenclatoare
Manager științific continuu - 3 nu ½ zi total
Modulul de administrare
Gestiune (adăugare, modificare, ștergere) Departament IT Manager tehnic zilnic 8-17 3 nu ½ zi total
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 20
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
Departament Rapoarte și Nomenclatoare
Manager științific continuu - 2 nu 2 ore total
Configurare export de date din RMU către alte instituții
Departament Rapoarte și Nomenclatoare
Manager științific continuu - 3 nu ½ zi total
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
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 21
(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)
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 22
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;
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 23
- 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.
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 24
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ă.
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 25
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:
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 26
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
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 27
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.
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 28
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ță.
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 29
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.
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 30
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ă;
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 31
- 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
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 32
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;
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 33
- 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.
Proiect co-finanŃat din Fondul Social European prin Programul OperaŃional Sectorial pentru Dezvoltarea Resurselor Umane 2007-2013 34
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.