Ko v podjetju govorimo o varnosti IT sistemov, večinoma razmišljamo o antivirusih, varnostnih kopijah in dostopih. Le redki pa si postavijo vprašanje: Kaj se zgodi, če nam odpove ključna infrastruktura? Torej tisto, brez česar ne deluje prav nič več?
To vprašanje marsikoga pripelje vsaj do razmišljanja o izvedbi stresnega testa IT okolja s poudarkom na izpadu ključnih sistemskih komponent.
Kaj pomeni "izpad ključne infrastrukture"?
Gre za simulacijo situacij, kjer odpove nekaj res bistvenega: strežnik, centralna podatkovna baza, požarni zid, strežniška mrežna povezava, DNS strežnik … tiste komponente, ki jih večina uporabnikov sicer nikoli ne vidi, a brez njih nič več ne deluje.
Zakaj bi se odločili za ta test?
Kljub temu, da je naš sistem dobro zastavljen (virtualizacija, backupi, nadzor, redundanca, torej vse po pravilih), se lahko zgodi, da se nekaj sesuje. Ali vemo, kako hitro in učinkovito lahko ukrepamo? Ali smo res preverili, kako delujejo naši mehanizmi za odpornost in obnovo v praksi, ne samo na papirju?
Kako testiramo?
Začnemo z analizo stanja: katere komponente bi ob izpadu povzročile največji operativni šok? Pogosto se izkaže, da lahko imamo kar nekaj "točk enega odpovednega mesta", kljub temu da smo prepričani, da jih nimamo.
Nato lahko v nadzorovanem okolju simuliramo:
- izpad centralnega podatkovnega strežnika,
- nedostopnost glavnega DNS strežnika,
- izklop enega od ključnih fizičnih strežnikov (vključno z njegovo omrežno kartico),
- izpad internetne povezave na lokaciji, kjer gostimo zaledni sistem.
Test se seveda izvaja z določenimi varovalkami, vendar čim bližje realnemu scenariju.
Kaj lahko s takšnim testom ugotovimo?
Marsikaj, česar si ne bi želeli ugotavljati med pravim incidentom.
- Ali avtomatski preklopi delujejo kot bi morali.
- Čas, ki ga potrebujemo za identifikacijo problema.
- Ali je dokumentacija popolna in ažurna.
- Kakšna je komunikacija med odgovornimi.
In to je poanta stresnega testa – razkriti ranljivosti, preden to stori realnost.
Povezava z načrtom za obnovo po nesreči (Disaster Recovery Plan)
Stresni test izpada infrastrukture ni ločen od strategije za kibernetsko varnost, v bistvu je neposredno orodje za preverjanje učinkovitosti Disaster Recovery Plana (DRP).
Veliko podjetij sicer ima DR načrt – pogosto skrbno pripravljen dokument, ki opisuje, kaj naj bi se zgodilo ob momentu katastrofe. Je pa res, da kot vsaka druga stvar - brez prakse in brez testiranja je vse skupaj močno le v teoriji. Že slutite povezavo s stresnim testom?
Katera vprašanja si moramo zastaviti?
- Ali vemo, kako hitro lahko obnovimo kritične storitve?
- Ali res deluje avtomatski failover?
- Ali zaposleni poznajo svoje vloge in postopke?
- So kontaktni podatki v DR načrtu ažurni in dosegljivi?
Stresni test da DR načrtu življenje. Če bi moral izbrati en način s katerim lahko preveriš, če imaš dober načrt za obnovo, bi bil to test izpada – v nadzorovanem okolju, a z realnimi posledicami.
Na stresni test moramo gledati kot na obvezni element IT kulture v podjetju. In to ne kot samo enkratno aktivnost, ampak kot orodje za učenje, za izboljšave in predvsem za preverjanje pripravljenosti.
Saj veste, ko enkrat (bognedaj) padel strežniki, potem ne bomo hoteli ugibati , če bo naš sistem preživel. To bi definitivno radi vedeli vnaprej, kajne? Več o samem Disaster Recovery planu pa v naslednjem blogu.