Într–o eră digitală în continuă expansiune, amenințările informatice devin tot mai sofisticate și răspândite, subminând securitatea informațiilor personale și a organizațiilor. De la malware și atacuri de tip ransomware până la breșe de date, provocările cu care ne confruntăm sunt diverse și imprevizibile. În acest context, backup–ul se conturează ca ultima linie de apărare esențială, protejând datele împotriva pierderilor accidentale și atacurilor cibernetice, asigurându–se că informațiile critice pot fi recuperate rapid și eficient. Recent, adoptarea Directivei NIS2 (Network and Information Systems Directive) și a regulamentului DORA (Digital Operational Resilience Act) subliniază importanța unei infrastructuri de securitate robuste, care să includă măsuri adecvate de backup. Aceste reglementări pun accent pe necesitatea de a proteja sistemele și datele împotriva incidentelor cibernetice și de a garanta continuitatea activităților în fața diverselor amenințări.

Implementarea unei soluții de backup nu garantează întotdeauna îndeplinirea scopului ei. Pentru aceasta, voi evidenția anumiți factori care pot influența o implementare de succes.

Primul pas care ar trebui făcut este definirea clară a design–ului implementării soluției, prin care se identifică resursele disponibile, se stabilesc cerințele, constrângerile și se elimină presupunerile. Se identifică infrastructura care va fi protejată:

• Centrele de date (locațiile fizice)
• Infrastructura virtuală (vSphere, Hyper–V, AHV, RHV, etc.)
• Mașinile fizice
• Mașinile din cloud
• Date nestructurate (File share–uri, NAS, object storage)
• Baze de date

Cerințele implementării urmăresc nevoile de afaceri sau nevoile tehnice și se transpun în cerințe funcționale sau non–funcționale, care trebuie documentate:

• Service Level Agreements (SLA) și Service Level Objectives (SLO)
• Recovery Point Objectives (RPO) și Recovery Time Objectives (RTO) – exemple:  baze de date, RPO – 0.5 TB pe oră; NAS, RTO un singur fișier < 1 oră; server (fizic sau virtual), RTO< 24 ore
• Retenție – perioada de timp disponibilă pentru restaurare
• Consistența – backup consistent al aplicațiilor: MS–SQL, Oracle, AD, etc.
• Imutabilitate – posibilitatea de a stoca backup–ului date fără posibilitatea de a fi modificate sau șterse
• Regula 3–2–1 – strategie de backup pentru a avea 3 copii ale datelor, 2 medii de backup diferite (disk, tape, cloud), 1 copie backup offsite
• Fereastra de backup – siguranța ca backup–ul se realizează într–o perioadă determinată de timp
• Criptarea backup-ului – în timpul stocării și transportului prin rețea
• Backup rezilient – copia datelor pe medii reziliență, de încredere, redundante cu suport de la furnizor
• Compresie și deduplicare
• Ransomware / malware mitigation – funcții implementate pentru a reduce riscurile și impactul atacurilor cibernetice
• Replicare – replicare pentru sistemele critice
• Cerințe de securitate – MFA pentru conectarea în consola de backup, acces restricționat la server de backup, etc.

O altă componentă a design–ului soluției o reprezintă constrângerile, care apar la nivel de descriere, implementare sau operare:

• Infrastructura de rețea – capacitatea de transport determinată de echipamentele de comunicație sau furnizorul de comunicație
• Echipamentele de stocare backup – nu trebuie să fie EOL pentru a beneficia de suport de la producător
• Ora de începere a operațiunilor de backup, pentru a nu perturba activitatea de producție
• Capacitatea de stocare existentă
• Bugetul disponibil
• Timpul de implementare
• Experiența și competența echipei de implementare

Pe lângă toate acestea mai sunt elemente care trebuie luate în calcul în realizarea design–ului, dar care vor fi presupuse:

• Rata de modificare a bazelor de date
• Rata de creștere a mașinilor virtuale
• Rata de deduplicare
• Rata de compresie a datelor
• Mărirea benzii de rețea internet

Implementarea unei soluții de backup poate veni și cu anumite riscuri care trebuie luate în considerare. Iată câteva dintre riscurile potențiale:

• Termene de implementare scurte
• Estimare necesar echipament de stocare greșită, bazată pe compresie și deduplicare
• Termene de livrare echipamente depășite
• Implementare soluție pe hardware învechit

Următorul pas, după realizarea design–ului conceptual, este realizarea design–ului logic. Acesta are ca scop alegerea  componentele aplicației bazată pe cerințele specificate anterior și se finalizează prin crearea unui HLD (High Level Design), în care vor fi documentate componentele aplicației de Backup & Restore, precum și dimensionarea lor.

Exemplu de arhitectură

În general o soluție de backup trebuie sa aibă cel puțin componente enumerate mai jos, în funcție de necesități.

Server backup, care poate fi server fizic sau virtual, instalabil pe diverse sisteme de operare, cu CPU, RAM în funcție de dimensiunea soluției de backup. Pentru serverul de backup trebuie urmărite câteva aspecte:

• Restricționarea accesului la server, incluzând tool–urile de acces de la distanță
• Să nu aparțină aceluiași domeniu ca si mașinile pentru care realizează copii
• Să nu conțină alte aplicații neesențiale
• Consola de acces la aplicația de backup să nu fie instalată direct pe serverul de backup, ci pe un server auxiliar, pentru a evita accesul RDP
• Să aibă mecanism multi–factor authentication (MFA)
• Să aibă activă autorizarea four–eyes, în sensul în care modificările efectuate asupra configurației și a joburilor de backup să fie aprobate de 2 persoane
• Să fie permise doar porturile necesare aplicației
• Să fie configurată și criptată copia de backup a configurației aplicației
• Să fie dezactivate versiunile SSL (SSL 1.0, 2.0, 3.0) și TLS ( TLS 1.1) învechite

Backup server database, care poate exista pe același server cu aplicația sau pe alt server dedicat pentru baza de date, instalabilă pe diverse sisteme de operare, cu CPU, RAM in funcție de dimensiunea soluției de backup. Aceasta componentă trebuie securizată ca si serverul de backup.

Componenta rețea: adresare IP, DNS, criptare trafic, segmentare rețea pentru componentele aplicației.

Backup Repository, echipamentul de stocare destinat pentru copiile de siguranță. În funcție de necesități poate fi FC SAN, Shared SAS, iSCI SAN, NFS, vSAN, vVOLs, object storage sau local storage. Un aspect important îl constituie dimensionarea acestei componente:

• Din punct de vedere al resursele de compute:

CPU cores = RoundUp (Proxy Cores /3), unde proxy core poate fi proxy pentru Vmware, CDP sau pentru fiecare agent fizic (fiecare agent fizic acționează ca propriul proxy)

RAM în GB = Required Repository CPU cores * 4

• Din punct de vedere al spațiului fiecare aplicație are propriul tool de calcul.

Pentru full backup: capacity = Size of Full Backup TB * (Total Instances * Full Backups Per week) * Annual Growth Rate

Pentru backup incremental: capacity= number of inc per week * IncSizeGB / 1024 (GB to TB) * compression formula

Backup Proxy, componenta a infrastructurii de backup care gestionează traficul de backup și restaurare, optimizând procesul pentru a reduce impactul asupra resurselor sistemului. Acesta poate fi configurat pentru a efectua compresia și criptarea datelor, precum și pentru a direcționa traficul de backup către destinația corespunzătoare. Pentru estimare dimensionare proxy:

• Pentru CPU: Required Incremental Proxy CPU cores = ((Source Data Size MB * Change Rate) / Backup Window Sec) / Throughput per Task MBps

• Pentru RAM: Required RAM in GB = Required Incremental Proxy CPU cores * 2

Gateway Server, componentă auxiliară a infrastructurii de backup care facilitează accesul de la serverul de backup către storage–urile de backup, unde serverul de backup nu poate ajunge direct (exemplu, accesul la object storage din cloud).

Mount Server, componentă a infrastructurii de backup care gestionează montarea și accesul la fișierele din backup pentru restaurare sau verificare. Acesta permite utilizatorilor să exploreze și să recupereze datele din punctele de restaurare fără a fi nevoie să descarce întregul backup.

Următorul pas este implementarea soluției, urmărind documentul de instalare al fiecărui producător. Echipa de implementare trebuie să verifice funcționarea soluției conform testelor proiectate.

Testele de validare trebuie să includă acțiuni specifice, componente implicate, parametrii de testare și rezultatele așteptate. Printre aspectele ce trebuie testate se numără:

• Accesul utilizatorilor (permisiuni)
• Executarea job–urilor (durata)
• Protecția workload–urilor
• Notificările primite
• Locația fișierelor de backup (respectarea regulii 3–2–1)
• RPO (Recovery Point Objective)

Implementarea nu este finalizată până nu validăm și componenta de restaurare. Se restaurează:

• Elemente ale aplicațiilor
• Fișiere și foldere ale sistemului de operare guest
• Mașini virtuale
• Backup–uri ale agenților
• Failover și failback de replică
• Fișiere, foldere și dispozitive din stocarea NAS/obiect
• Recuperabilitatea mașinilor virtuale
• Recuperabilitatea aplicațiilor
• Dependențele aplicațiilor
• Integritatea fișierelor de backup
• Conținutul backup–ului (scanare malware)

Salvarea datelor și protecția lor este un proces continuu. Sunt o serie de pași strategici pentru revizuirea și actualizarea proceselor de implementare:

• Revizuirea notelor din deployment. Se verifică notițele înregistrate din implementările anterioare pentru a identifica problemele apărute și modificările necesare la nivelul designului fizic.
• Actualizarea documentației. Se completează documentația existentă adăugând pașii omiși sau recomandările pentru depășirea provocărilor de mediu întâmpinate în timpul implementării.
• Evaluarea periodică a stării mediului. Se colaborează cu echipa de administrare pentru a monitoriza periodic starea mediului, asigurându–ne că totul funcționează conform așteptărilor și identificând eventuale zone de îmbunătățire.
• Identificarea noilor inițiative și modificări. Atenție la inițiativele noi sau schimbările din mediul de operare care ar putea declanșa necesitatea unui nou ciclu de implementare.
• Revizuirea modificărilor în suita de produse. Se evaluează periodic dacă actualizările aduse suitei de produse răspund provocărilor noi sau existente ale afacerii, determinând astfel zonele care necesită optimizare sau adoptarea celor mai bune practici.

Acești pași contribuie la menținerea și îmbunătățirea continuă a implementărilor existente, asigurând adaptarea lor la dinamica mediului organizațional și tehnologic. Dacă doriți să discutăm mai detaliat despre cum pot fi integrate aceste practici în contextul profesional al afacerii dumneavoastră, Arctic Stream este aici să continuăm conversația! Ne puteți contacta la: [email protected].