Zero-Data-Loss Protokoli & Regulativa

Disaster Recovery (DRaaS) i
Zakonska Usklađenost

Osigurajte kontinuitet poslovanja i uskladite sisteme sa novim Zakonom o informacionoj bezbednosti. RSC tehnologija prevodi kompleksne zakonske norme u automatizovanu tehničku realnost.

Tehnička rešenja Zakonske Obaveze (NIS2)
Definicija i koncept

Šta je zapravo DRaaS?

DRaaS (Disaster Recovery as a Service) predstavlja napredni model cloud bezbednosti koji ide korak dalje od klasičnog čuvanja fajlova[cite: 96]. Dok običan backup obezbeđuje samo sirove podatke, DRaaS pravi aktivnu repliku kompletnog vašeg računarskog okruženja[cite: 96].

U slučaju pada primarnog servera, sajber napada ili hardverskog kvara, DRaaS vam omogućava da instant "prebacite" (Failover) celokupno poslovanje na RSC rezervnu infrastrukturu u roku od nekoliko minuta, zadržavajući kontinuitet rada bez gubitka klijenata i novca[cite: 97].

RPO (Recovery Point Objective)

Određuje maksimalnu starost fajlova koje sistem vraća[cite: 70]. Naša arhitektura podržava RPO meren u minutima, što znači da gubite minimalno podataka pre samog incidenta[cite: 70].

RTO (Recovery Time Objective)

Označava vreme potrebno da vaša aplikacija ponovo postane operativna i dostupna na internetu[cite: 70]. Težimo RTO standardu koji skraćuje prekid na apsolutni minimum[cite: 70].

Tehnička implementacija

Kako sprovodimo Disaster Recovery?

Sprovođenje bezbednosnih protokola se odvija kroz četiri precizne inženjerske faze[cite: 71].

01

Analiza i Procena

Identifikujemo sve kritične komponente vašeg sistema (baze podataka, mrežne rute, aplikacije) i definišemo ciljne vrednosti za RPO i RTO[cite: 71].

02

Kontinuirana Replikacija

Podaci se u kriptovanoj formi i realnom vremenu repliciraju sa vašeg primarnog servera na našu sekundarnu, izolovanu cloud lokaciju[cite: 71].

03

Automatski Failover

U momentu prekida rada glavnog sistema, mrežni saobraćaj se automatski preusmerava na aktivne rezervne node-ove unutar RSC mreže[cite: 71].

04

Failback (Povratak)

Nakon što se primarna infrastruktura sanira i popravi, vrši se bezbedna sinhronizacija i saobraćaj se vraća nazad bez ikakvih zastoja[cite: 71].

Strategija upravljanja rizicima

Plan za Kontinuitet Poslovanja

Tehnologija je samo deo rešenja; organizacija i strategija čine razliku između uspeha i kolapsa[cite: 72].

✓

Diversifikacija rizika i geografska otpornost

Uspešan plan podrazumeva skladištenje podataka na lokacijama koje su fizički i geografski udaljene od vašeg primarnog data centra[cite: 72]. RSC obezbeđuje infrastrukturu otpornu na lokalne energetske ili mrežne padove[cite: 72].

✓

Definisane uloge i protokoli reagovanja

Plan jasno definiše ko i na koji način aktivira krizne sisteme[cite: 72]. Automatizacija eliminiše ljudski faktor i paniku u trenucima incidenata, skraćujući vreme reakcije na nulu[cite: 72].

✓

Redovno testiranje i simulacije katastrofa

Neproveren plan je isto što i nepostojeći plan[cite: 72]. Naš inženjerski tim zajedno sa vama sprovodi periodične, kontrolisane simulacije padova sistema kako bi se potvrdilo da infrastruktura reaguje besprekorno[cite: 72].

Pravni Okvir & NIS2 Harmonizacija

Novi krovni Zakon: Bekap i DR su striktna zakonska obaveza

Novi krovni Zakon o informacionoj bezbednosti donosi fundamentalne promene i usklađivanje sa evropskom NIS2 direktivom[cite: 74]. Zakon deli sisteme na prioritetne i važne IKT sisteme od posebnog značaja, gde privatne IT kompanije (pogotovo cloud provajderi, hosting centri i data centri) direktno potpadaju pod stroge zakonske obaveze[cite: 75]. Kada je reč o bekapovima (rezervnim kopijama) i DR-u (Disaster Recovery), zakon više ne posmatra ove sisteme kao opcionu "dobru praksu", već kao striktnu zakonsku obavezu čije neispunjenje povlači ozbiljne pravne i finansijske sankcije[cite: 76].

1

Zakonske obaveze za Bekap i DR

  • Upravljanje kontinuitetom poslovanja (DR): Organizacije moraju imati definisane i testirane procedure za oporavak od katastrofe kako bi obezbedile dostupnost sistema i minimalno vreme prekida rada (RTO/RPO) u slučaju velikih incidenata ili prirodnih nepogoda[cite: 77].
  • Redovna izrada i provera: Zakon nalaže uspostavljanje jasne politike bekapovanja[cite: 78]. Rezervne kopije se moraju raditi redovno, uz obavezu testiranja uspešnosti povrata podataka (restore), kako se ne bi desilo da bekap postoji samo "na papiru"[cite: 79].
  • Enkripcija i bezbednost skladištenja: Podaci u bekapu moraju biti zaštićeni od neovlašćenog pristupa (enkripcija u mirovanju i u prenosu), a lokacije na kojima se bekap čuva moraju ispunjavati standarde fizičke i logičke bezbednosti[cite: 80].
  • Zaštita od ransomware-a: Strategija bekapovanja mora uključivati mere poput offline (air-gapped) kopija ili nepromenljivog (immutable) bekap skladišta, jer savremeni zlonamerni softver ciljano napada i primarni bekap[cite: 81].
2

Akt o proceni rizika i Akt o bezbednosti

Ove tehničke mere ne smeju biti ad-hoc postavljene[cite: 82]. Zakon uvodi obavezu kreiranja zvaničnih internih dokumenata[cite: 83]:

Akt o proceni rizika: Mora se revidirati najmanje jednom godišnje, a u njemu se mapiraju ključna informaciona dobra i procenjuje uticaj potencijalnog gubitka podataka na kontinuitet poslovanja[cite: 83].

Akt o bezbednosti IKT sistema: Detaljno definiše primenjene tehničke mere, uključujući topologiju bekap sistema, lokacije primarnog i sekundarnog DR data centra, učestalost kopiranja i uloge odgovornih lica[cite: 84].

3

Incidenti i prijava u roku od 24 sata

Zakon stavlja akcenat na trostruki stub informacione bezbednosti: poverljivost, integritet i dostupnost[cite: 85]. Ako zbog otkazivanja primarnog sistema ili neuspešnog DR-a sistem ne bude dostupan u predviđenom roku, to se zakonski tretira kao incident[cite: 86].

  • • Rok od 24 sata: Operatori su dužni da prijave svaki značajan incident ili ozbiljnu pretnju nadležnom CERT-u ili Kancelariji za informacionu bezbednost u roku od 24 sata od detekcije[cite: 87].
  • • Nema prikrivanja: Izgovori poput "Nije bilo štete" ili "Rešili smo incident interno" ne oslobađaju organizaciju od odgovornosti[cite: 88]. Nedostatak evidencije o incidentu i preduzetim DR koracima je sam po sebi prekršaj[cite: 89].
4

Oštra Kaznena Politika

Novi zakon značajno pooštrava kaznenu politiku u odnosu na prethodne verzije[cite: 90]. Za nepoštovanje propisanih mera zaštite (gde spadaju i adekvatan bekap i DR planovi), predviđene su sledeće novčane kazne[cite: 91]:

  • • Za operatore važnih IKT sistema: Kazne se kreću u rasponu od 50.000 do 1.000.000 dinara[cite: 91].
  • • Za operatore prioritetnih IKT sistema: Kazne su znatno rigoroznije i mogu ići i do nekoliko miliona dinara, uz potencijalnu ličnu odgovornost i kazne za odgovorna lica u pravnom licu (direktore i IT security oficire)[cite: 92].

Ključni koraci za usklađivanje:

Identifikacija kategorije Proveriti da li vaša organizacija ili vaši klijenti spadaju u prioritetne ili važne sisteme (IT hosting, cloud i data centri su automatski obuhvaćeni)[cite: 93].
Revizija bekap arhitekture Preći sa prostog lokalnog bekapa na 3-2-1 strategiju (ili napredniju) sa obaveznim geografski dislociranim DR-om na RSC-u[cite: 94].
Formalizacija dokumentacije Izraditi ili ažurirati Akt o bezbednosti i uspostaviti jasne procedure za DR testiranje najmanje jednom godišnje[cite: 95].

Uskladite svoje sisteme na vreme

Naš tim inženjera vrši kompletnu tehničku reviziju vaše bekap arhitekture, implementira nepromenljiva (immutable) skladišta i pomaže vam u definisanju Akta o bezbednosti[cite: 102].

Kontakt za više informacija i konsultacije

info@rsc.rs

Odgovorićemo vam u najkraćem mogućem roku sa predlogom rešenja.