Názory k článku Regulace podle NIS2: Útok na slovenský katastr ochromil trh s byty i hypotékami
-
nj. holt firmy dělají jen minimum, co po nich zákon požaduje a očividně dnes pro ně bezpečná a stabilní infrastruktura zatím není konkurenční výhoda, aby do toho investovali vlastní prostředky. Pak na efektivitu netlačí ani management.
Ano, ty požadavky na schopnost vyměnit i starý HW dost prodražují infrastrukturu. Běžně se kupuje HW s tím, že vendor po dobu jeho podpory (zpravidla 5 let na projektech, co dělám) musí držet spare HW na opravy. Ze stejného důvodu se pak ten HW po 5 letech mění, ikdyž je plně funkční, už se prostě nesežene smlouva na někoho, kdo zaručí okamžitou výměnu.
Pak to prostě stojí miliony. Stát má na to ještě přísnější pravidla a my se divíme, proč platil na třeba nový systém na katastry nějakých 180 milionů jen za HW.
-
V kritické infrastruktuře se zpravidla vše kupuje dvakrát a do DR lokality se opravdu dává totožný HW.
Dnes někteří pracují právě i s tím, že se to kupuje 3x, aby bylo jedno prostředí na DR pravidelné testy a zároveň se tím zvyšuje odolnost proti dvojitému DR (aneb mám-li primární lokalitu dole, do jaké míry si mohu dovolit provozovat celou infrastrukturu ze záložní a bez druhého jistění?).
-
Posledni odstavec - a prave proto se DR cviceni dela aby je odhalilo.
Prave resi i ty externi zavislosti. Pokud se treba projevi zavislost jako vysoce rizikova (ze by mohla selhat) tak je na uvazeni managementu se ji zbavit nebo zavest zalozni plan. Zalozni konektivitu si nedrzime pro srandu kralikum. A plan kdy musime treba signalizaci od signalizacniho bodu tunelovat pres IP protoze se ceka nez prileti karta (kterou mame i spare skladem) tez stoji penize. Maly sklad na kriticke soucasti tez stoji penize. Stejne jako skladnik a i clovek ktery monitoruje trh s obsolete HW.
Takove rizikove zavislosti je samozrejme idealni nezavadet. Ze je to pak drazsi? Ano a prave proto to zapocitavate do ceny sluzby. A na to mate mit penize.
Pokud nemohu nabizet sluzbu v nejake pozadovane kvalite tak ji proste nenabizim a zakaznikovi reknu pocitejte s tim ze to muze tyden nejit.15. 1. 2025, 16:57 editováno autorem komentáře
-
a to je přesně ono, pokud to trvá dny, je to drahé na lidskou práci a potřebuji k tomu spousty seniorních lidí, jak asi bude vypadat situace, kdy to budu opravdu v kritické situaci potřebovat?
Jasně, pokud s tím takhle počítám, mám odpovídajícím způsobem vyčíslené RTO, RPO a bez infrastruktury/systému/systémů se obejdu, je to asi v pořádku. Bohužel takhle nějak to vypadá i v kritické infrastruktuře, představa, že banka na pár dní zavře protože obnovuje ze zálohy je vtipná a velice nebezpečná.
Viděl jsem to při covidu, ona stačí maličkost, seniorní část týmů onemocní, stane se problém a najednou ho nemá kdo vyřešit a pokus o řešení vede k daleko většímu výpadku. Bus factor je jedna z věcí, která se v rámci NIS2 a naší ZoKB(2) má také vyčíslit a ošetřit.
Pro mě DR, kde potřebuji autobus seniorů na dva týdny není DR. Mám rád, když proces obnovy je hladný, rychlý a pravidelně testovaný. Dokud jsme u některých zákazníků dělali DR jednou za dva roky, stálo to 500 MD, jakmile se přešlo na 2 měsíční cykly, stojí to 10 MD (ano celkové člověkonáhlady zůstaly stejné, tj. není to dražší, ale RTO je najednou v hodinách a ne týdnech).
-
Tak on problém je v tom, že udělat DR test všeho z pásek i kdyby to bylo jen do testu nikoliv do produkce, sežere ve většině orgnizací velké množství času. Musí na tom dělat více lidí a bude to trvat dny. Často potřeba testovat mimo pracovní dobu, takže k tomu to jsou přesčasy.
Výsledek je takový, že test je drahý utilizuje mnoho klíčových lidí, kteří na to nemají čas a málo kdo je ochoten do toho tolik investovat.
15. 1. 2025, 08:15 editováno autorem komentáře
-
O tom mluvím, až příliš často se sektávám s tím, že DR testy jsou jen přepnutí na záložní lokalitu a nikoliv obnova celé infrastruktury ze zálohy. Nějaký full DR test se nedělá příliš často.
Snapshot ber jako konzistentní stav na zdroji, tj. locknutá databáze, btrfs/zfs snapshot, dump běžícího VM a jeho disku atd. To, jestli uděláš full backup nebo rozdílovou proti posledním snapshotu jsem neřešil.
To je právě ten problém, na jedné straně máš živý systém/aplikaci a na druhé straně zálohu. Jak zjistíš, že jsi zazálohoval všechna data, proti čemu to budeš porovnávat? Jak víš, že jsou všechna data na správném místě na filesystému? Jak zjistíš, že nezálohuješ živé soubory? Tohle musíš dělat na míru technologie/aplikaci, kterou používáš a občas se stane, že ta aplikace se lehce změní a ty neupravíš zálohovací procedury. Tu změnu zpravidla udělá dodavatel či další osoba (jak už to tak v korporátech probíhá). Rozpoznat, že se tím rozbily zálohy je těžké, když prochází, ale třeba obsahují nevalidní, neúplná či částečná data.
To se bavíme o firmách, kde RPO/RTO u DR nejsou neznámé termíny, které už nějakou dobu jsou pod ZoKB a mají na to lidi i procesy. Jen pak v praxi s tím je stejně fůra práce a chyb. Obnova všeho(!) z pásek je zatím hodně neprobádané území.
Sice můžeš mít IaC, ale pak tam stejně máš některé externí závislosti, hardcodované systémy, IDM či máš třeba Azure účet, který je vázán k nějakým smlouvám a pravidlům, v případě jeho znefunkčnění nejsi schopný obratem nový vytvořit a starý je z nějakého důvodu (hacku, limitů atd. nepoužitelný). Nebo to slavné IaC ti skončí na tom, že v AWS nejsou dostupné zdroje a prostě tam tady a teď tu infrastrukturu nepostavíš, to pak ti je odzkoušený DR k ničemu, že jo.
Ano, bavíme se už o tom, jaké to je, když máš DR, pár let ho děláš a začínáš to brát vážněji.
-
Proto jsou DR testy aby odhalily procesni nedostatky. Napriklad nefunkcni validaci zaloh. Pokud se s tim nic nedela pak je to jiste zaprotokolovano. Prave kvuli takovym slendrianum se musi delat pravni ramec ktery nas odvadi od uzitecne prace.
Jen na snapshot se nelze spolehat. Musite obcas delat i uplne zalohy. Protoze snapshot bez pocatecniho stavu vam neni nic platny. A i to ze zvolite nahodne zalohu a zkusite obnovit neni uplne marne. Byt ne systemove reseni.
Jak je mozne ze nedokazete porovnat data v zaloze s tim co potrebujete? Vy nevite co zalohujete? Nemate katalog/index zaloh?
Jak je mozne ze nemate alespon minimalni plan na test zaloh?Pro rychlou obnovu mate IaC a zalozni pronajate kapacity. A nebo nemate a pak absorbuje nizke parametry SLA a cena koncove sluzby
Jsou holt organizace dobre a spatne.A pak takove kterym postupy kontroluji certifikacni autority a na kterych vydelavame.
14. 1. 2025, 14:28 editováno autorem komentáře
-
no, na doma si LTO6 kupovat nebudu :).
Diverzifikace je řešením, více samostatných cest. Proti smazání tě mají chránit pravidelné velké snapshoty, proto jsem se ptal, že by bylo super, kdyby mi poslali pásku nebo flashku...
S fyzickou bezpečností a odolností proti sabotáži se třeba běžně pracuje v bankách, .zařízení na pásky se nakupují po párech a střídají se, v DC se řeší fyzická bezpečnost a nikdy všechny pásky nemůžeš mít v jedné budově atd. atd.
S čím ale bývá obvykle největší problém je obnova, málokdo už plnohodnotně data z pásky zkouší pravidelně obnovovat, často není ani kam, někdy se obnovují jen vzorky, někdy se ověřují jen kontrolní součty. Stejně tak bývá problém ověřit, že zálohu opravdu aktuální data a ne pořád ta stejná stará (např. je běžné, že se zálohují snapshoty, pokud ale se přestanou snapshoty tvořit nebo mají nově jiný formát názvu, je možné, že je zálohovací SW nechytne správně...).
Se stavem, kdy se každý týden celá infrastruktura obnovila ze zálohy jsem se setkal pouze jedenkrát. Např. varianta, kdy mám 3 lokality, primární, záložní a záložní obnovovanou ze zálohy je zatím velice málo nasazovaná a to i v prostředí cloudů.
Stejně tak, když už teda mám dobře zpracované zálohování, tak mi vlastně chybí procesy a znalosti, jak zálohu plně obnovit (pamatuji Casablancu, kdy sice zálohu super, ale v reálném čase jim nebyly schopní obnovit) nebo jak vlastně rychle připravit infrastrukturu do které jí obnovit (když jsem přišel třeba o servery nebo se musí nainstalovat). V cloudech zase zpravidla chybí přesná dokumentace, jak to celé postavit na novém účtu od nuly (a když už něco je, tak to rozhodně není ve formě, ve které to mohu hned obnovit).
-
V pripade LTO by mela byt zpetna kompabilita, pro cteni obvykle o dve generace. Takze na precteni LTO4 by mela postacit i LTO6 mechanika. Jo, neni to uplne levny... na druhou stranu, statni sprava na podobne reseni zdroji rozhodne disponuje.
Digitalni archivy v cloudech maji tu nepeknou vlastnost, ze tam porad nekde byva moznost ulozene data i smazat. A odlisit, kdy jde o legitimni pozadavek a kdy o utok neni trivialni. Jasne, zaskodnik zevnitr organizace muze znicit i tu pasku... ale takovy se bude dohledavat snaz, nez nekdo, kdo prislusne pokyny vyda z nejakeho hacknuteho pocitace neznamo kde.
-
a já zase pamatuji dobu, kdy jsem sháněl jak LTO4 připojit k novému počítači. Pásky jsou super, ale jsou strašně problematické a drahé i pro firmy, natož pro lidi.
Častěji dnes vidím snaho o digitální archivaci někde v cloudech.
Kdoví, jestli existuje služba, která by mi poskytla cloudovou zálohu a každý měsíc (půl rok, whatever) mi poslala pásku s danou zálohou.