Fórum Root.cz
Ostatní => Odkladiště => Téma založeno: darebacik 13. 01. 2025, 22:24:40
-
Ako je zname, tak slovensky kataster mal udajne hackersky utok typu ransomware. Ak by mali v poriadku zalohy, tak zrejme do niekolkych hodin by to mali nahodene. Po utoku je uz tyzden a stale im to nefunguje.
Zatial nie je za to nikto zodpovedny a predpokladam, ze vinu hodia na opoziciu ako obvikle.
Zaujmaju ma skor technikalie ako sa zalohuje v takychto spolocnostiach, kde sa udaje v databazach menia takmer neustale.
Uvadza sa, ze vzdy musia byt zalohy aspon na 3 miestach. Predpokladam, ze lokalne, dalej na nejakom cloude a na offline mediach.
Vezmime si napr. banky, kde sa vykonava denne 100 000-ce transakcii. To snad ani nejde zalohovat na nejake offline media. Nedajboze by banku postihol ransomware, tak to by bola asi katastrofa a krach banky, keby boli bez zaloh.
Ak sa robia zalohy offline kazdu hodinu, alebo kazdy den, tak tomu samozrejme rozumiem, ale v pripade napadnutia hackermi musi byt aj ta posledna transakcia na offline medii, inak bude stratena.
-
Samozřejmě banka (resp. jakýkoliv subjekt) má více kategorií dat a u každé by pak měla být odpovídající strategie zálohování - včetně RTO (kolik času trvá, než se to obnoví) a RPO (jak stará data ještě můžeš ztratit, aby tě to neohrozilo, např. prezentace z marketingu stačí ze zálohy jeden den zpátky, některá data potřebuješ z poslední hodiny, a jinde je to nula).
Tomu jak to má daný subjekt naplánované tak, aby případná havárie nebo útok neohrozila jeho fungování se obvykle říká BCP, Business Continuity Plan, kde by to mělo být vcelku detailně popsané co a jak dělat včetně třeba i školení obsluhy atp.
Na data v vysoce dostupných transakčních systémech v podstatě nelze použít nic jiného než nějakou formu synchronní replikace (tzn. transakce se nedokončí dokud to není zapsané ve dvou či více systémech) ideálně v součinnosti s CDP (continous data protection) - https://en.wikipedia.org/wiki/Continuous_data_protection kdy se ještě jinam ukládají data včetně kompletního logu všech operací/transakcí a s možností případného návratu zpět (což je nutné v případě nějaké logické chyby, smazání atp).
-
K tomu asi nemám, co dodat, pěkně shrnuté. :)
Ako je zname, tak slovensky kataster mal udajne hackersky utok typu ransomware. Ak by mali v poriadku zalohy, tak zrejme do niekolkych hodin by to mali nahodene.
I pokud mají kompletní zálohy, tak obnovení může být tady na hodně dlouho:
- Ze všeho nejdřív je potřeba zabránit potvorákovi v šíření. Což ale obrovsky zpomalí jakékoliv další kroky s napadenými systémy, protože všechno je vypnuté.
- Pak musíš zjistit, jak se potvorák dostal dovnitř, vykopnout ho ven a zajistit, že se nevrátí vzápětí tím stejným oknem, kterým vlezl předtím.
- Pokud máš dost zdrojů (lidi, stroje, licence, peníze), můžeš startovat paralelní infrastrukturu a chystat ji ze záloh v oddělené lokaci/síti, zatímco napadená síť je pořád dole. Pokud nemáš, musíš počkat na vyčištění napadených strojů.
- Studená instalace a start komplikovaného systému může být práce na dny i pokud ti u toho sedí tým lidí 24 hodin denně na směny a jednou podle kuchařky krok za krokem bez improvizace. Jestli není testovaný recovery plán, a tohle se dělá za pochodu, přičemž lidi, co kdysi něco zavedli už nejsou kolem, a nikdo neví, jaké má co závislosti... Hodně štěstí, uvidíme se za měsíc.
- A v tomhle případě je možná potřeba fyzicky obejít všechny klientské stroje v kancelářích úředníků, což přidává další hromadu práce a času. J
-
Sak RSD taky prisli o vsechny data vcetne zaloh a zodpovedny za to neni nikdo ....
Jinak dela se to jak tu bylo zmineno tak, ze mas treba dve primarni storage, ktery se mezi sebou replikujou. To ti resi ten prvni level (vcetne pripadne umreni storage). Typicky samo budou v jinych lokalitach, takze by te nemela ohrozit ani voda v casablance ... teda pokud si to delas sam, a neveris jim.
Takovej ten prvni level backupu pak muze byt primo na primarni storage v podobe snapshotu. Takze pokud narazis na nejaky rekneme soft problem, muzes to resit rovnou tak, aniz bys muse nejaka data odnekud presunovat.
Zalohovani jako takovy pak samozrejme probiha na nejaky dalsi storage, ktery bezej na jinych systemech, a typicky proste posilas stream diffu. Jedinej zasadnejsi rozdil proti primarnimu storage je ten, ze zaloha defakto generuje vicemene linearni zapis. Tady pochopitelne nema smysl drzet nejakou silenou historii jednoduse proto, ze den stara data muzou byt uz nepouzitelne stara.
Z tyhle zalohy se pak v nejakych intervalech odsypavaji data jeste do archivu, kde drzis nejakou historii.
V kazdym pripade to funguje zcela automaticky a nikdo nic nikam nenosi. Jednoduse proto, ze jakejkoli lidskej faktor = nebude to fungovat.
V kazdym pripade si musis uvedomit, ze cim vic dat mas, tim vetsi problem znamena obnova backupu. Ona totiz zadna konektivita neni dostatecne nekonecna.
-
Vezmime si napr. banky, kde sa vykonava denne 100 000-ce transakcii. To snad ani nejde zalohovat na nejake offline media. Nedajboze by banku postihol ransomware, tak to by bola asi katastrofa a krach banky, keby boli bez zaloh.
Zrovna u bank je objem celkem triviální. Transakce je pár čísel (kdy, od koho, komu, kolik ..). Pochopitelně se musí řešit integrita těch dat atd., ale objem v dnešní době nestojí za zmínku. I ty počty (i kdyby byly o několik řádů jinde) jsou relativně malé (a to i v případě několikaleté historie). Kdejaká malá reklamní síť, monitoring zákaznických zařízení, datový sklad apod. musí řešit větší objemy. Proto mají pokročilejší zálohování mechanismy (přírůstkové, rozdílové zálohování, virtuální fullbackup ad.)
-
Velke databaze jako Oracle, SQL Server anebo Postgre maji transakcni logy ktere se taky zalohuji. Diky tomu je pozny PITR (point in time recovery). Databazi je mozne obnovit k libovolnemu bodu v historii.
Bankovni aplikace maji vlastni "ucetnictvi". Jako za na jedne strane je "ma dati" "dal" (nostro a vostro). Pokud by doslo ke zmene dat v jedne bankovni aplikaci tak by vznikla dikrepance s hodnotami v jine aplikaci anebo s hodnotami z vypisu z uctu i jine banky.
-
Nebudu popisovat principy zálohování, těch je všude plno. Stačí si dohledat Veeam.
Nicméně banky kdysi zálohovaly na WORM média "Write Once, Read Many", dnes existují i SD karty.
Jinak jsem si jist že banky využívají služeb AWS a produkt S3, či podobné.
Největší nebezpečí zcizení dat je totiž ve vlastních zainteresovaných zaměstnancích, než v cizích datacentrech kde jsou data zašifrovaná.
-
sa udaje v databazach menia takmer neustale.
Ty systémy se navrhují tak, aby se data nikdy neměnila a nemazala. Pořád jen přibývají nové transakce. Storno platby nic nemaže - je to nová transakce. Změna adresy klienta nic nemění, je to nová transakce. To zálohování velmi usnadňuje. Aktuální stav můžeš mít někde nacachovaný, ale zálohovat ho nemusíš.
Mimochodem s tím množstvím dat v bankách to není tak hrozné. Velké retaily jako Kaufland třeba jich mají řádově více (celosvětově Walmart a Amazon) . O visa/mastercard nemluvě.
Pokud se bavíme o netransakčních datech, tak samozřejmě YT - jediné czechcloudovo reakční video je větší, než denní datový objem transakcí celé banky ;-)
-
Velke databaze jako Oracle, SQL Server anebo Postgre maji transakcni logy ktere se taky zalohuji. Diky tomu je pozny PITR (point in time recovery). Databazi je mozne obnovit k libovolnemu bodu v historii.
Ne tak uplne, ty si muzes vybrat casovy okamzik mezi transakcemi. A to samo o sobe ale nemusi stacit. Protoze zdaleka ne kazda aplikace transakce pouzivat umi. Tudiz sice muzes mit z pohledu databaze konzisteetni data, ktera ale nebudou konzistentni z pohledu aplikace.
Pricemz je treba si uvedomit i to B. Pokud proste obnovis backup, tak je casova narocnost dana vicemene ciste objemem tech dat. Pokud si zacnes hrat s transakcema, tak ten stroj nedela nic jineho, nez ze na ta data aplikuje kazdou jednu transakci az do vybraneho okamziku. A to pochopitelne obnasi i pripadne veskere vypocty atd atd.
-
Aktuální stav můžeš mít někde nacachovaný, ale zálohovat ho nemusíš.
Viz vejs, kdybys to delal prave takhle, tak ti obnoveni aktualnich dat bude trvat mesice ... ty mesice pobezi aplikovani veskery ty historie.
-
Nazov mojej temy zrejme upravil moderator, ale jej nazov bol povodne iny. Neslo mi o velke data, skor ma zaumali (objemovo) male data. V bankach je podla mna transakcia mala (predpokladam 10-ky bajtov). Taktiez na katastri sa do map ukladali len nejake suradnice (xml) takze tiez radovo 10-ky bajtov).
Nepracujem s databazami, takze neviem, ale je efektivne ukladat velke subory do databaz ?
Skor by som informacie o velkych suboroch (metadata) ukladal do DB, ale samotne subory nie.
-
... nevim jak ve slovenskym katastru ... ale v tom ceskym budes mit ulozeny i vsemozny pdfka ruznych smluv, fotky, ...
A i kdyz se budem bavit ciste o mapovych datech, tak trebas OSM ma aktuelne v rozbaleny podobe +- 2TB. Kdyz do toho zahrnes i nejaky to ulozeni v podobe databaze a indexu, tak to muze mit v pohode 5TB.
Samozrejem zavisi, co kdo chape pod pojmem katastr. V papirove podobe to fungovalo zhruba tak, ze si mel nejakou mapu, na ty mape byly cisla pozemku, a zaznam v katastru defakto obsahoval uz jen cisla tech pozemku. Tzn nasel si tam neco na tema ze pepazdepa vlastni pozemky bb.15787 a bl.7746547.
-
Ak su data dlhodobo poskodzovane, tak aj ked ma clovek zalohy, dat to dokopy je peklo. Ak sa pusti hlupe sifrovanie (ransomware/utocnik ide ako admin), tak je to ten lepsi pripad.
Vsetko off, poslednu zalohu dat zverifikovat a nasadit. Infra podobne, mozes to risknut s co najstarsou zalohou, alebo to postavit nanovo (reinstall app, os).(Zalezi aky je press, resp ci sa da tipnut, ako to asi prebiehalo - dlhodoba ucast v systeme, alebo nasiel som dieru a hned vyuzil).
Ako bolo vyssie spravne spomenute, treba zistit vektor utoku. (Ak to situacia dovoluje, idealne co nie je do netu povolene, je zakazane, tym zamedzi clovek nezelanym connectom, ransomware nevie komunikovat s tvorcom, poslat kryptovaci kluc, ..).
Ukladat binarky do db je podla mna prasarna.(Ale je to moj nazor).
Bud subory drzat mimo db, a len sa cez nu odkazovat na ne, alebo vies vyriesit nieco ako stream, kedy subor je aj nie je sucastou db ..(fyzicky je mimo, ale tvari sa ako jej sucast).
Ak vies vopred rozumne dopredu navrhnut strukturu, v akej sa maju subory nachadzat (v pripade kastra by to mohlo byt napr rok/mesiac/den/cislo-okresu/napr-cislo-konania/nieco.jpg, nieco pdf, nechce sa mi rozmyslat), tak sa v tom da rozumne hrabat suborovym managerom, a zaroven s tym zalohovaci soft nema ziadnu robotu, na rozdiel od mega zlozky, kde su statisice/miliony suborov (ano, aj toto ide zalohovat, file system dostane trochu cez zadek, ale pripadna rucna hrabacka/triedenie/analyza je uz za trest).
(Oba pripady som videl).
-
Ukladat binarky do db je podla mna prasarna.(Ale je to moj nazor).
To dost zalezi na situaci. Uvedom si, ze uz jen reseni prav k tem datum = resit to 2x. Dalsi vec kterou budes resit obratem, jsou protokoly - tzn komunikujes s databazi + s nejakym FS = 2x resit bezpecnost, sifrovani, ...
Ne kazda databaze totiz funguje tak, ze vsichni jsou jeden uzivatel (ackoli to presne takhle vetsina patlalu pouziva, a vysledky tomu presne odpovidaji).
-
V bankach je podla mna transakcia mala (predpokladam 10-ky bajtov).
Ohledně 10-tek bajtů bych byl dost opatrný, určitě to spíše bodou 100-ky, ne li 1000. Ono na transakci není jenom odkud jak a kolik, ale budou tam třeba různé symboly, měna, popis příkazce, popis příjmence. Nedejbože, aby ta transakce byla kartou nebo mezinárodní, to pak přibude spousta dalších atributů.
Jinak taková banka má transakcí miliony denně.
A představovat-si, že data katastru jsou xml se souřadnicemi je podle mě také naivní. To kde parcely jsou je jenom malá část dat. Katastr hlavně vede majitele, celé zástavní smlouvy. Podle mě český eviduje i celé kupní smlouvy. Různé omezení o manilupaci - zástavní smlouvy,...
-
Jde-li konkrétně o banky.
Ono to řešení není tak složité, složité je jen v detailech. Ukázkový příklad, Oracle DB nad replikovaným diskovým polem, replikovaný transakční log, na vstupu se každý požadavek ukládá do auditního logu. Transakce se nejprve uloží do interní fronty a poté se provedou změny v modelu. Vše se striktně spouští v db transakci.
To co tzv. Core (či Core banking system, CBS). Je to databáze a k tomu rozhraní, které se stará o transakce, klienty, účty, účetnictví, číselníky atd. Na Core databázi se zpravidla nikdo z venku (ani aplikace) nepřipojuje, vše se replikuje přes transakční log, který se čte. Core bývá fyzicky, síťově a administračně oddělen od zbytku infrastruktury.
České banky mají Core velký zpravidla několik TB velký, RTO se pohybuje v hodinách. Při obnově se zahodí datová složka, vezme se poslední snapshot/checkpoint a od něho se aplikují jednotlivé transakce z logu (jedna po druhé). To už psali předřečníci.
Naše banky mají zpravidla dvě aktivní lokality, kam se data rovnou replikují. Transakční a auditní logy z core putují na pásky se zpožděním pár desítek minut.
Vedle toho pak nezávislé stojí jiné databáze a datové sklady, které data dále zpracovávají, posílají, zobrazují klientům v bankovnictví, dělají reporty a výstupy do ČNB atd. Aplikací a systémů nad Corem pak může být i několik stovek a to jsou pak systémy, s kterými se potkávají běžní lidé a zaměstnanci. Často ale neobsahují primární data a mohu je obnovit z Core systému. Tam se data zálohují už daleko jednodušejí, snaphosty virtuálů, dumpy dat a vesměs to je věcí týmu, kterému to patří, aby udělal backup and restore implementaci. Obnova se čvičí několikrát ročně a některé banky to mají již plně zautomatizované.
Technicky se ale nedá zabránit všem druhům útoků, důležitou roli hraje dohledový tým a automatizace, která izoluje v případě problémů celé systémy, dohledové centrum funguje nonstop. Díky vysokému tlaku ČNB, jsou naše banky v tomhle hodně progresivní. To už se ale nedá říct o těch systémech nad tím, s kterými se větčina vývojářů a uživatelů setkává.
Kdyby někoho zajímal rozsah, v jednom z Corů vidím třeba 2 000 tabulek a celkově obsahují 300 000 sloupců. K transakcím se ukládají i atributy a metadata, tj. z jakých terminálů transakce vznikla, různé identifikace a seriová čísla, IP adresy, časové známky, podpisy atd. atd.
-
Kdyby někoho zajímal rozsah, v jednom z Corů vidím třeba 2 000 tabulek a celkově obsahují 300 000 sloupců.
A pouziva se to prakticky vse, nebo je to spis dusledek nasazeni nakoupene technologie, ktera byla vytvorena nebo dokonvergovala do univerzalniho reseni, aby zadna zmena schematu v teto casti uz nikdy nebyla potreba (coz rozhodne usnadnuje aktualizace a snizuje moznosti problemu, kdyz jsou vse pouze data a samotna struktura se nemeni).
Nebo je tam i nejaka segmentace dat (sam jsem pouzival ve vykonnem vyhledavaci), to pak pocet klidne narust muze libovolne, a usnadnuje to pak paralelizaci, ono jeden stroj s naivnim schematem databaze bude mit chte nechte sve limity.
-
V bankach je podla mna transakcia mala (predpokladam 10-ky bajtov).
Ohledně 10-tek bajtů bych byl dost opatrný, určitě to spíše bodou 100-ky, ne li 1000. Ono na transakci není jenom odkud jak a kolik, ale budou tam třeba různé symboly, měna, popis příkazce, popis příjmence. Nedejbože, aby ta transakce byla kartou nebo mezinárodní, to pak přibude spousta dalších atributů.
Jinak taková banka má transakcí miliony denně.
Dobre, ale furt su to len nejake znaky (pismena, cisla + nealfanumericke znaky). Aj keby to netrepali do databazy, tak v textakoch to nezabara vela. Samozrejme pri milionoch transakcii je tych dat viac.
A představovat-si, že data katastru jsou xml se souřadnicemi je podle mě také naivní. To kde parcely jsou je jenom malá část dat. Katastr hlavně vede majitele, celé zástavní smlouvy. Podle mě český eviduje i celé kupní smlouvy. Různé omezení o manilupaci - zástavní smlouvy,...
Samozrejme, ze mapy nie su vsetko, ale ide o to co vsekto potrebuju na katastri udrziavat. Mozno to robia sposobom, ze si zmluvy a podobne dokumenty skenuju, ukladaju do png, alebo pdf a potom pre jedneho zakaznika vytvoria aj 100 MB.
Zaujmal ma pricip backupu, kde sa hodne casto zapisuju do DB data. Neslo mi ani tak o velkost dat, ale velmi caste frekvenciie zapisov
-
Kdyby někoho zajímal rozsah, v jednom z Corů vidím třeba 2 000 tabulek a celkově obsahují 300 000 sloupců.
A pouziva se to prakticky vse, nebo je to spis dusledek nasazeni nakoupene technologie, ktera byla vytvorena nebo dokonvergovala do univerzalniho reseni, aby zadna zmena schematu v teto casti uz nikdy nebyla potreba (coz rozhodne usnadnuje aktualizace a snizuje moznosti problemu, kdyz jsou vse pouze data a samotna struktura se nemeni).
Nebo je tam i nejaka segmentace dat (sam jsem pouzival ve vykonnem vyhledavaci), to pak pocet klidne narust muze libovolne, a usnadnuje to pak paralelizaci, ono jeden stroj s naivnim schematem databaze bude mit chte nechte sve limity.
ty data jsou normalizovaná a modelovaná, s validací, datovými typy a vše co si přeješ, dělá se i migrace schémat a dat za provozu. Dokud vše bylo věcí mainframů, byly běžné noční odstávky, kde se dělala údržba, validace. Dnes se přechází na 24/7 provoz, často to běží na věcech jako Oracle Exadata a už potkáš u kubernetes v core infrastruktuře (koukám na to trochu nelibě, ale co).
Zpravidla je core výsledkem dodávky jedné společnosti, partnera nebo vlastní in-house vývoj, nebývá to mišmaš všeho, co koupíš, to jsou až ty vrstvy nad tím. Je tam hodně číselníků, třeba třetina. Každá banka to má jiné, když jsme migrovalii data při slučování bank, tak to jsou tisíce člověkodnů jenom na to, abys ty data propojil a spároval, ikdyž na druhé straně logicky musí být hodně podobné.
Ty systémy jsou rozsáhlé, protože i rozsah služeb a funkcí je vysoký. Třeba PSD2, to jsou desítky nových tabulek jen kvůli tomuhle. Změny se dělají pořád a příprava nových věcí se děje denně, nasazování je pak dána jen tím, jak to má banka vnitřně nastavené, některá je schopná změny dělat skoro denně, jiná si to nechá do velkého balíčku jednou za půl roku. Core nemusí být složen fyzicky z jediné databáze, ale častěji to je soustava několika databází a segmentuje se to.
Jsem architekt, do provozních dat tolik nevidím a ani mě nezajímají, zajímá mě jen jak to je postavené, navrhnuté a jak s tím dál. Stejně tak nemohu sdělovat příliš konkrétní data, protože nevím, co je zveřejnitelné a co ne. Zagoogli si, jestli tě to více zajímá, např. z Komerční banky o tom veřejně mluví Frantisek Kubala.
Zaujmal ma pricip backupu, kde sa hodne casto zapisuju do DB data. Neslo mi ani tak o velkost dat, ale velmi caste frekvenciie zapisov
Zálohují a schraňují se transakční logy, tj. záznam o tom, že proběhla nějaká změna v databázi (insert, update, změna schémat). Počet transakcí jen ovlivňuje to, jak je transakční log velký, jsou to append-only soubory. Stav v databázi je pak až materializace právě těch jednotlivých transakcí, hodně zápisu ti nevadí, vždy máš nějaký point in time (transaction id), ty jsou seřazeny v čase.
-
...potom pre jedneho zakaznika vytvoria aj 100 MB....
Ty ses opravdu velkej naivista, to ti nebude stacit ani na kadibudku. Stavebni urady kterych je katastr soucasti bezne pracuji s GB per jeden projekt.
Zaujmal ma pricip backupu, kde sa hodne casto zapisuju do DB data. Neslo mi ani tak o velkost dat, ale velmi caste frekvenciie zapisov
To je jen otazka vykonu a funkce penez. Proste kdyz mas na vstupu Gbit ... musis zvladat ten Gbit i odesilat. Pokud to nedelas kontinuelne ale jednou za cas, tak pochopitelne nasobne vic.
A pokud bys presah moznosti HW, coz se muze stat, tak proste musis ten provoz rozdelit na vice stroju. Zadna raketova veda.
-
Jsem architekt, do provozních dat tolik nevidím a ani mě nezajímají, zajímá mě jen jak to je postavené, navrhnuté a jak s tím dál. Stejně tak nemohu sdělovat příliš konkrétní data, protože nevím, co je zveřejnitelné a co ne. Zagoogli si, jestli tě to více zajímá, např. z Komerční banky o tom veřejně mluví Frantisek Kubala.
Tak zajima me to prave z architektonickeho hlediska, protoze pripravuji prepsani sveho erp/ucetnictvi (inhouse reseni). At to je cely vlastne primarne insert-only (writeonly, append), a modify se dela jen nad pomocnymi tabulkami pro aktualni stav (primarne z toho duvodu aby to bylo zivy a synchronni ve dvou lokacich). Nejvetsi hruza je ale ze zmen schematu - doposud na te "primitivni" db bylo vse jenom rozsirovano a pridavano, s tim ze to je pak zpetne kompatibilni (tj. nic nezmizi a ani nic nebude jinak), ale pak to casem vytvori neudrzovatelny moloch (asi hodne SAPoidni).
Tak se pidim po tom, jak resit tyhle veci (tj. nejake procesni pristupy, at je schema synchronni s okolnimi "skripty"). Napada me takovej tick-tock pristup, kdy se prvne zmigruje okoli na pouziti obojiho a pak az data. A to jeste bych rad bezvypadkove (treba aukro me neskutecne vytaci hlaskou o odstavce.. tohle v roce 2025 by uz nemelo byt bezne/caste). Z popisu jak hodnotis sektor by me byl blizsi asi pristup vice mensich zmen, ve smyslu mala zmena = mensi sance to podelat, castejsi zmena = stane se z toho rutina, nez ten druhy obcasny s vetsimi upravami.
-
Jinak dela se to jak tu bylo zmineno tak, ze mas treba dve primarni storage, ktery se mezi sebou replikujou. To ti resi ten prvni level (vcetne pripadne umreni storage).
Budu zcela kategoricky nesouhlasit. Replikace ti vůbec neřeší ransomwarový útok, protože napadená data se ti okamžitě replikují do sekundáru, protože samotným smyslem a účelem sekundární repliky je v reálném čase reflektovat změny v primární replice.
Replika NENÍ záloha, replika je opatření pro zajišětění vysoké dostupnosti při TECHNICKÉ ZÁVADĚ.
Z tyhle zalohy se pak v nejakych intervalech odsypavaji data jeste do archivu, kde drzis nejakou historii.
V kazdym pripade to funguje zcela automaticky a nikdo nic nikam nenosi. Jednoduse proto, ze jakejkoli lidskej faktor = nebude to fungovat.
V kazdym pripade si musis uvedomit, ze cim vic dat mas, tim vetsi problem znamena obnova backupu. Ona totiz zadna konektivita neni dostatecne nekonecna.
Další naprosto zásadní věc je správné nastavení PŘÍSTUPOVÝCH PRÁV k zálohám. Protože záloha, kterou ti napadený účet řadového uživatele může přepsat VČETNĚ ARCHIVU je v případě útoku naprosto zbytečná, protože likvidace archivu a záloh je už z principu jedním z prvních kroků, často ještě před samotným útokem na provozní data. Právě proto, aby se obnově ze zálohy zamezilo.
Proto má záloha běžet v kontextu účtu, který má právo k pouze čtení provozních dat a k pouze přidávání dat do zálohy, nikoli k jejich přepisu.
Když tohle zvořeš, uděláš líp když se na to úplně vykašleš a neuděláš to vůbec, protože aspoň ušetříš hromadu prachů A ZÁROVEŇ VÍŠ, že to je potřeba ASAP udělat pořádně.
-
Nebudu popisovat principy zálohování, těch je všude plno. Stačí si dohledat Veeam.
Nicméně banky kdysi zálohovaly na WORM média "Write Once, Read Many", dnes existují i SD karty.
Jinak jsem si jist že banky využívají služeb AWS a produkt S3, či podobné.
Největší nebezpečí zcizení dat je totiž ve vlastních zainteresovaných zaměstnancích, než v cizích datacentrech kde jsou data zašifrovaná.
Jenže tady nejde o primárně krádež informací, nýbrž o jejich zničení / odepření přístupu k nim.
Každé se to řeší jinak, protože jiné jsou cíle jak útočníka, tak organizace.
-
Tak zajima me to prave z architektonickeho hlediska, protoze pripravuji prepsani sveho erp/ucetnictvi (inhouse reseni). At to je cely vlastne primarne insert-only (writeonly, append), a modify se dela jen nad pomocnymi tabulkami pro aktualni stav (primarne z toho duvodu aby to bylo zivy a synchronni ve dvou lokacich). Nejvetsi hruza je ale ze zmen schematu - doposud na te "primitivni" db bylo vse jenom rozsirovano a pridavano, s tim ze to je pak zpetne kompatibilni (tj. nic nezmizi a ani nic nebude jinak), ale pak to casem vytvori neudrzovatelny moloch (asi hodne SAPoidni).
Tak se pidim po tom, jak resit tyhle veci (tj. nejake procesni pristupy, at je schema synchronni s okolnimi "skripty"). Napada me takovej tick-tock pristup, kdy se prvne zmigruje okoli na pouziti obojiho a pak az data. A to jeste bych rad bezvypadkove (treba aukro me neskutecne vytaci hlaskou o odstavce.. tohle v roce 2025 by uz nemelo byt bezne/caste). Z popisu jak hodnotis sektor by me byl blizsi asi pristup vice mensich zmen, ve smyslu mala zmena = mensi sance to podelat, castejsi zmena = stane se z toho rutina, nez ten druhy obcasny s vetsimi upravami.
Udělej mezi tím rozhraní, pohledy, marty, jinou databázi.
Přistup k schématu a databázi jako k vlastnictví. Každé scéma vlastní konkrétní aplikace a nikdo jiný než daná aplikace dané schéma nepoužívá. Pokud potřebuješ data sdílet mezi aplikacemi, exportuj data jako veřejný, stabilní, zaručený interface (ať už formou materializovaných pohledů nebo replikaci do jiné databáze nebo použití nějaké rpc nebo fronty), pak máš prostor, kde můžeš ošetřovat zpětnou kompatilibitu, verzovat či řídit změny bez ohledu na to, jak s schématy zachází její vlastník.
To, jestli jedna aplikace bude celý ERP nebo tam budeš mít jednotlivé služby je na tobě, vždy se při určité velikosti vyplatí to logicky rozdělit.
A pokud jde o řízení změn u konzumentů dat, tak hodně záleží na tom, co konzument dělá. Pokud to je třeba posílač emailů, tak starého omezím pouze na původní verzi schématu a spustím nového nad novým schématem. Stará data doběhnou a nové se začnou posílat jinak.
Nebo udělám nějaký bridge, který bude nové schéma zpětně migrovat do starého, aby původní aplikace plně fungovala beze změn. Tohle je třeba v případě bank častý způsob. Navenek nic není vidět. Až aplikace se upraví, změní se jí link na nové schéma a bude ho konzumovat přímo.
Základem je ale pořád mít nějakou vrstvu, která bude fungovat jako mezičlánek, výstup z té vrstvy je verzovaný interface a o vstup se právě stará majitel schématu a udržuje migrace při změnách. Na začátku třeba začínáš tím, že máš pohledy typu select *, protože nepotřebuješ nic jiného dělat.
Pokud jde o zápis, platí pravidlo výše, pouze jedna aplikace jako vlastník může do schématu zapisovat, ostatní nikoliv, takže na vše mít RPC nebo frontu změn a ty si bude sama aplikace odbavovat, jen ta ví, jaké je správné schéma. Varianta, kdy všichni zapisují do jedné společné databáze, jak je běžně vidět u webových aplikací vede pouze a jen k celkovým odstávkách při aktualizaci.
Pokud jde o bezvýpadkovou aktualizaci a migraci schémat. Buď máš potřebnou obslužnou logiku implementovanou v aplikaci a v jednu dobu zapisuje a čte z dvou různých verzí schémat, což je někdy dost komplikované nebo používáš materializované pohledy a migrace na úrovni databáze, aplikace pak má najednou k dispozici obě verze schémat, nové i staré a může postupně přejít na nové.
Občas se dostaneš do situace, kdy změnu potřebuješ udělat daleko rozsáhlejší, použij verzování route a směruj staré požadavky na starou aplikaci a nové požadavky na novou a v jednu dobu budeš provozovat dvě verze backendu, data z nich sdružovat právě v nějakých martech, veřejných interfaces.
Cest je ale hodně, tohle je jen takové postrčení jak to můžeš řešit. Vše zmíněné zvládne pg, s mariadb nepočítej. Pokud se vzhlédneš v moderních nosql databázích, budeš si to muset nějak implementovat sám.
-
Udělej mezi tím rozhraní, pohledy, marty, jinou databázi.
Tohle ti nebude tak uplne fungovat. Mam bezne pod spravou aplikace do kterych dodavaji moduly ruzni dodavatele. Ten modul ma samozrejme primy pristup k databazi, kde ma typicky nejake sve tabulky, ale zaroven pouziva ty "systemove".
Kazdy API pak ma nejaky svoje omezeni, a ne vzdy lze pres API zrealizovat to, co chces. A naopak, pokud udelas "neomezene" API, narazis na presne stejny problem.
Jakykoli udrzovani kompatability pak vede k presne tomu, co zminil RDa ... neudrzovatelny brajgl.
Priklad. Soudruzi kdysi davno vytvorili policko DIC a pridali ho k zaznamu organizace. Jenze pak se zjistilo, ze jedna oganizace muze mit ruzna DIC v ruznych casovych obdobich ... a tak pridali vazbu. Jenze to puvodni policko uz pouzivalo spoustu dalsich funcionalit, tak ho tam nechali. A voiala, neudrzovatelny bragl je na svete. V zavislosti na tom z kery strany do toho bordelaku vlezes se mozna vyplni jedna nebo druha nebo obe moznosti. A vysledek je ten, ze klildne na ruznych dokladech mas ruzna DIC.
Pokud bys chtel zaridit co pises, tak mas jedine dve varianty. Bud mas 100% pod kontrolou vyvoj vseho co se vsim nejak komunikuje a muzes rozkazem zaridit prislusne zmeny, nebo to proste postavis tak, ze te nejaka kompatabilita nepali, a at se kazdej postara jak umi.
Ono totiz i verzovani API povede k tomu, ze proc by sme to menili, kdyz to funguje. Takze ve vysledku budes mit desitky nebo stovky verzi API ktery budes muset udrzovat, pokud jim to nechces rozbit.
-
Pokud to je modul, je to pořád součástí té aplikace, ne?
Chceš mít schopnost dělat aktualizace bez výpadků a nasazovat změny průběžně? Prostě zapomeň na to, že do jedné databáze zapisuje více samostatných aplikací. Z cizích databází čti pouze z veřejných schémat, přes api nebo odbírej event log. Jedna databáze = jeden vlastník = jeden zapisovatel a cokoliv jiného řeš replikacemi, migracemi, transformacemi. Samozřejmě to je zjednodušení.
Argumentuješ správně, když více dodavatelů používá stejné schéma a databázi, změny musíš koordinovat napříč dodavateli a nasazovat to najednou. To je pak nepořádek, to nikdy nezautomatizuješ.
Neber to absolutně. Urči si kritickou část systémů, kterou máš pod kontrolou, tam zaveď a vynuť nějaká pravidla, aby se ti žilo lépe. V dalších vrstvách můžeš stavidla uvolnit. Banky mají svůj Core, který udržují takhle náročně a přesně, ono se jim to vyplatí, ale pak mají třeba systém na vykazování práce, což je běžná databáze někde v kubernetu, přistupuje do ní několik dalších aplikací vč. koupených pluginů, udržuje to několik týmů, zálohuje se to celé najednou, aktualizace znamená výpadek a restart, s tím se dá žít, uděláš to mimo pracovní dobu, na konci měsíce z toho uděláš report do účetnictví a ten skončí v Core vrstvě.
Musíš si určit co chceš a co ne. Je na tobě, co pustíš do infrastruktury a jaká pravidla musí co splnit. s NIS2 se nám objeví ve spoustě firem povinnost si zmapovat, který systém je jak důležitý pro chod firmy a jak pro nás je bolestný výpadek, tohle ti přesně udělá ten řez. Pokud bez té aplikace nemůžeš ani otevřít dveře, těžko jí můžeš provozovat stylem, že X aplikací od X dodavatelů zapisuje do stejné databáze a aktualizují si schémata jak se jim zachce. Rozumíš kam s tím mířím?
Pokud někdo chce udělat z např. Pohody (pohoda.cz) kritický systém a řekne mi, že tady má webovou aplikaci, která přímo přistupuje do databáze, další která používá api, má tady několik koupených pluginů a třetí strana to aktualizuje sama každý půl rok. Řeknu mu, že bez rozbití těch integrace a jejich oddělení a normalizování datové vrstvy s tím moc neudělám (viz třeba co vše musel udělat AK system, aby měl pohodu distribuovanou). Pak přesně přichází na řadu diskuze, jestli je levnější to předělat nebo koupit flexibilnější účetní systém.
-
Diky za hodnotou inspiraci, tohle je presne co jsem potreboval v teto chvili, aby me to dalo hlavu a patu!
Fakt jsem uvazoval o API/RPC, bez primeho pristupu vyssich aplikaci do DB, ale nevedel jsem jak/k cemu to vyuzit presne, ted chapu ze to budou proste ostruvky a musim pridat dependencies, at te ktere komponente neodriznu vetev ktera ji drzi. Tohle pujde hezky i reportovat a hlidat pri vyvoji a migracich. S rozdrobenim nemam problem, uz nyni je to hodne KISS metoda tady - individualni jednoucelove nastroje/skripty.
Priklad. Soudruzi kdysi davno vytvorili policko DIC a pridali ho k zaznamu organizace. Jenze pak se zjistilo, ze jedna oganizace muze mit ruzna DIC v ruznych casovych obdobich ... a tak pridali vazbu.
Tohle jsem resil ja asi lepe - uz od pocatku jsem to musel brat ze DIC ma platnost od-do, a taky ze existuje vice DIC k jednomu subjektu (klidne v kazdem eu state jedna) a na konkretnim dokladu se nachazi jedno z nich. Pak vznikla "sluzba" (spis volani/metoda), na zjistovani DIC k subjektu X, s kontextem - povinnym parametrem data, ke kteremu se dotaz vaze (vzdy tam muzete poslat dnesek, jestli jde o obecny dotaz). Podobne kontextualni queries mam napr. na dotaz na smenarensky kurz - vaze se ke dni, nebo mesici.
Jinak dela se to jak tu bylo zmineno tak, ze mas treba dve primarni storage, ktery se mezi sebou replikujou. To ti resi ten prvni level (vcetne pripadne umreni storage).
Budu zcela kategoricky nesouhlasit. Replikace ti vůbec neřeší ransomwarový útok, protože napadená data se ti okamžitě replikují do sekundáru, protože samotným smyslem a účelem sekundární repliky je v reálném čase reflektovat změny v primární replice.
Replika NENÍ záloha, replika je opatření pro zajišětění vysoké dostupnosti při TECHNICKÉ ZÁVADĚ.
Tak zas asi zalezi jak ty repliky delate. Pokud je bude delat backend vrstva nad tupejsi databazi (mysql), mimo jine z duvodu, aby se resila mj i moznost behu v rozpojene/degradovane siti (pro ty mene kriticka volani, ktere to snesou, viz napr. vytvoreni objednavky v degradovanem rezimu, potvrzeni objednavky pouze v plne synchronnim, at se nemusi resit dvoji prodej polozek ze skladu a pak omlouvani se), tak je mala sance, ze by utocnik ktery ovlada jen stroje s vyssi logikou, dokazal znicit data na backendu na ktery muze sahat jen skrze API pod RPC. Takoveho pocinu by si hned mela vsimnout logika ktera bude hlidat typicke vyuzivani sluzeb, resp. melo by byt mozne revertnout dane zasahy pokud to jadro bude append-only.
-
Jasně, ale to je furt "jen" vysoká dostupnost, nikoli záloha. Může to vypadat jako nuance, ale je poměrně dost důležitá.