U těch zdravotnických zařízení je problém, že pojišťovny a další na ně navazující instituce striktně požadují proprietální řešení na Windows, která z podstaty věci (této parodie na OS) nemohou být bezpečná.
Pokud by se podařilo "naředit" tuhle supercitlivou monokulturu, tak by významná část problémů zmizela.
Navíc jsou u některých proprietálních databází a pod. problémy se zálohováním (nelze je zalohovat prostým okopírováním souborů na zálohovací médium), to zase zvyšuje riziko úspěšnosti takového útoku.
Druhou takovou věcí je, že stát se IMHO chová velmi laxně k těm, kdo ty peníze za výpalné inkasují.
Takovéhle věci se běžně dělají, stačí používat databáze/filesystémy s COW, např. zfs nad Solarisem, pak lze zálohovat Oracle databázi opravdu jen odkopírováním datového souboru pryč :)
V současné době už běžně nasazujeme podobné technologie i do středních firem, výhody jsou podstatné.
Neprekvapive vskutku nelze, protoze vy potrebujete zajistit, ze ten soubor, ktery kopirujete, je datove konzistetni, a to sebelepsi filesystem nezajistuje a ani zajistit nemuze, protoze nema poneti o tom, jake transakce prave v databazi probihaji, takze vase kopie (napriklad) vyrobi to, ze budete mit v databazi milion hlavicek faktur, bez polozek, protoze ta druha cast transakce v okamzik kopie nebyla dokoncena a tudiz ani zapsana.
Proto vsechny pouzitelne databaze maji vlastni system zalohovani, pripadne API zavolatelne aplikaci treti strany, coz zajisti prave presne transakcni konzitenci dat (a ani to samo o sobe nemusi vzdy stacit, nebot to jeste stane neznamena, ze ta data jsou konzistentni i aplikacne).
COW resi zcela odlisny problem, resi poskozeni dat v pripade, ze by pri prepisu nebyl zapis z nejakeho duvodu dokoncen = zustava zachovana puvodni podoba souboru.
> Neprekvapive vskutku nelze, protoze vy potrebujete zajistit, ze ten soubor, ktery kopirujete, je datove konzistetni
A to u transakční databáze je. V případě, kdy zálohuju atomicky vytvořený snapshot, je to pro ni stejná situace, jako když náhle vypadne proud/zatuhne systém/shoří procesor. Vaše databáze se neumí srovnat s výpadkem proudu? Pak máte větší problém a potřebujete si přečíst o ACID podmínkách.
Vskutku uzasny zpusob zalohovani databaze "jako kdyz vytrhnete elektrinu" ... z toho budou jiste vsichni provozovatele databazi nadsenim bez sebe.
To ze neco takoveho databaze prezije, vubec neznamena, ze nedojde ke ztrate dat, naopak, v takovem pripade se zcela 100% jistotou k nejake ztrate dat dojde. Mate zjevne hodne velky problem s chapanim toho, jak databaze funguji.
Jisteze, uz se tesim, jak budete financni sprave vysvetlovat, ze vam nesedi ma dati vs dal ... takova drobna nekonzistence v databazi. Nemluve o tom, ze na teto planete neexistuje ani jedna databaze, ktera by garantovala ze neco takoveho prezije, naopak, existuje spousta takovych, ktere to zarucene nepreziji. Ony se UPS, agregaty a spousta dalsich opatreni zjevne plati jen tak pro srandu.
No, tou ztrátou dat způsobenou nekonzistencí jsem myslel (pardon za nepřesné vyjádření), že se musí nějaké transakce odrolovat, aby se databáze dostala do konzistentního stavu, ne že po obnovění z archivu nebude sedět má dati / dal.
Že žádná databáze negarantuje, že přežije odpojení elektřiny, není nic překvapivého. Možná už jste si všimnul, že ve světě IT negarantuje nikdo nic, ani to, že kalkulačka opravdu spočítá, že 1 + 1 = 2. Ale třeba Informix zcela jistě v drtivé většině případů takovou událost přežije, a pokud nemáte cachované logy, tak nepřijdete ani o bit dat. A jsou databáze, které dokonce jiný způsob archivace než kopírování raw dat neposkytují, třeba Postgress (aspoň do nedávna, neznám poslední verze).
A proč se používajím UPS a pod.? No, protože byť i krátký výpadek může způsobovat dost potíží a taky protože nejen v databázích jsou uložená důležitá data.
> v takovem pripade se zcela 100% jistotou k nejake ztrate dat dojde
Dojde ke ztrátě dat, pokud běží nějaká transakce, která ještě neudělala commit. Vzhledem k tomu, že transakce běží typicky pár sekund (nebavíme se o petabajtové databázi, tam se to bude řešit jinak) a zálohu dělám jednou denně, tak mi to žíly netrhá.
Nevím jak teď v 2016 ale 2012 R2 umožňovala nainstalovat core verzi WS 2012 R2, na ní nasadit Hyper-V a virtuálně dvě mašiny s plnohodnotným WS 2012 R2 pod jednou koupenou licencí. Pokud někomu nevyhovuje Hyper-V může jako hypervizora použít i ESXi a zase dva servery WS 2012 R2. Pro začínající firmu dobrej deal. Hardware se koupit stejně musí. A pokud se rozroste není problém rozšiřovat.
Zajímavé, používám Windows a zkusil jsem si teď otevřít soubor v MS Word, LibreOffice Writer, gVim, Notepad++ a Notepad2-mod a pokaždé editovaný soubor bokem zkopírovat... A světe div se, ve všech případech mi to prošlo, zkopírovala se vždy poslední uložená verze.
Opravdu trváte na tom, že je-li nějaký editovaný soubor blokován, jde o vlastnost OS Windows? To budete mít asi nějakou hodně speciální edici a chápu Vaši frustraci, to bych také nechtěl.
Není to úplně pravda, záleží na aplikaci. Zrovna jste trefil ty co nezamykají :), nebo zamykají nestandardně (Office).
Jde o to, že Windows standardně vynucuje zámky. Zjednodušeně řečeno, když si aplikace otevře soubor a dá si na něj zámek, ostatní jej mohou otevřít jen pro čtení, případně vůbec. Hezky se to dá vyzkoušet třeba na datových souborech MS SQL, což je taky důvod, proč je vir ze stanice nemůže na serveru přepsat, pokud SQL server jede.
Naproti tomu Linux standardně zámky nevynucuje a je to Váš problém, pokud si zkopírujete bokem něco, co je zamknuté. Opět třeba nějakou SQL DB.
Problém vidím v tom, že pokud by to bylo zamknuté, tak by pokus o čtení toho souboru jiným programem měl skončit chybou ve smyslu "nemohu číst soubor XYZ". Takhle se ale pořád načítá do zpracovávajícího programu stará verze textu, bez jakéhokoli varování. Je docela možné, že win dělají ty opravy do nějakého temp souboru a ten ukládají na patříčné místo na disku až po vypnutí editoru, nicméně je to idiotština.
A protože nehodlám věštit, jaké idiotství zrovna vymyslel ten či onen autor toho či onoho SW, tak jsem migroval k Linuxu. Stoprocentní to jistě není, ale idiotismů tohoto typu je zde podstatně méně.
Víte, existují operační systémy, které poskutují od svého začátku dobré systémové služby, takže každý vývojář SW je rád použije. Na takových systémech se pak (téměř) všechny aplikace chovají slušně a konzistentně.
A existují operační systémy, jejichž systémové služby byly udělané tak otřesně, že se pro vývoj aplikací použít nedaly. Pak si každý vývojář musel pro svou aplikaci vlastně vyvinou i pořádně napsané služby OS, a aby je mohl používat, musela aplikace běhat v privilegovaném režimu. A samozřejmě, když později byly do systému přidané jakž takž použitelné služby, tak už tu aplikaci nikdo nepřepisoval, protože to už by nikdo nezaplatil.
V druhém případě je samozřejmě zcela na místě spílat autorům operačního systému, protože autoři aplikací byly k psaní aplikací, které se chovají každá jinak a vyžadují nesmyslně vysoká opravánění, donuceni právě jimi.
Už dlouho na win nedělám, ale opakovaně se mi stávalo, až po verzi XP, že zdrojový text pro nějaký program (třeba TeX nebo nějaké programování) nebyl dostupný pro daný interpret / překladač, dokud jsem neukončil příslušný textový editor. Po soubor - uložit byla pořád na disku stará verze. Jedině pomohlo "uložit jako", v tom případě se pod novým jménem uložila aktuální verze. Nicméně po další opravě se muselo dát nové jméno, po další nové a disk se utěšeně plnil.
Po dlouhém popírání tohoto faktu ze strany windows guru (nakonec pomohlo přitažení za ucho k počítači a předvedení) jsem byl ujišťován, že se nejedná o chybu, ale "feature". Takže jsem raději přešel na OS, který tyto "feature" nemá.
Čili předpokládám, že ta blbě uložená databáze je prostě dále neřešená "feature" windows, a už kvůli ní má cenu přejít na něco, co je plnohodnotně funkční a umožňuje zálohovat pouhým překopírováním souborů.
Neviděl bych to tak černě - pokud provedu provedu běžnou zálohu prostředky SQL serveru (záloha dat do souboru + zkrácení log souboru) a poté ještě kompletní zálohu serveru, budou v tu chvíli soubory celkem konzistentní, navíc když toto celé proběhne během noci. Rozhodně je lepší mít alespoň nějaká data, než žádná.
Na Linuxu nebo jiném unix-like systému mohu mít nastavená práva tak, že se mi ten ransomware prostě nespustí. Potom zbývá minimálně "sociální inženýring" abych si to spustil pod svými právy sám.
Mimochodem, budu-li mít na disku rootovský adresář, kam budu databáze apod. s právy roota zálohovat, tak je to jednodušší než nějaké explicitní externí zálohy. A dá se to nastavit i tak (v tom je výhoda unix-like systémů), že se to udělá při vypínání počítače automaticky (protože na to mohu mít démona s rootovskými právy, který to udělá v rámci procesu vypínání).
A jsem-li paranoidní, mohu celou databázi provozovat jako uživatel se sníženými právy, který ani nesmí moc nakukovat mimo svůj adresář na /home.
To jsou věci, které na win prostě nejdou, většinou na nich ani nelze složitější programy plnohodnotně provozovat bez práv superuživatele, jemuž pak ovšem mohou jím spuštěné aplikace udělat cokoli.
> Na Linuxu nebo jiném unix-like systému mohu mít nastavená práva tak, že se mi ten ransomware prostě nespustí.
Fakt? Jak práva pomůžou třeba proti 0dayi na Firefox? Můžeš leda tak Firefox spustit pod jiným uživatelem a doufat (a _nějak_ vyřešit izolaci v rámci Xek, kde si X klienti můžou navzájem posílat eventy a nejde s tím nic moc dělat).
To vůbec není o windows, ale o diletanství tamnějšího IT.
1. stanice jako server - je to licenčně špatně, v případě kontroly by to bylo jako mít OS pirátsky
2. uživatel má přímý přístup k databázi na urovni soborů
Všichni si myslí, že to musí stát kdovíjaký prachy, ale na tyhle věci stačí bohatě nějakej microserver s raid diskama, s win server foundation a usb diskem na zálohy, vejde se do nějakých 11-12k bez DPH
Naprostý souhlas v obou bodech.
Osobně ale raději namísto "značkového serveru" HP, Dell atp. a WinFoundation sáhnu po "neznačkovém serveru" a dám tam Win Essentials. Nejde často ani tak o větší počet licencovaných uživatelů, jako o to, že je můžu virtualizovat. Finančně to vychází +- stejně (HW+licence).
Výsledek vypadá tak, že na HW jede v Linuxu KVM virtualizace a v ní MS Windows s MS SQL na jedné virtuálce a ve druhé Linux, který mi dělá doménu, poštu, zálohování atp. Stroj s MS SQL není nejčastěji ani v žádné doméně, neboť většina tvůrců IS se do DB přihlásí účtem "sa" a jména/hesla si šmrdlají ve vlastní režii.
Teď jste mne trochu dostal, mám tu informaci od mládenců z HW :)
Ale podíval jsem se na poslední dodávaný server, kde Win Essential byly a cenovka byla 34.000 bez DPH. Když jsem si na Alze vyfiltroval stejné parametry, zbyl mi tam jediný server a ten byl za 32.000. Bez Foundation.
Bude to tím, že HW pro Foundation servery je většinou "takové lepší stolní PC".
Takže nejšitovější Xeon, 8GB RAM (což by šlo) a 2x SATA disk v HW RAIDu (o jehož schopnostech také raději pomlčím), což je už trochu problém, protože s tím nemáte kam zálohovat. To pak znamená přikoupit 2xSSD (systém, DB, tmp, cache, atp.), SATA na data + další patřičně velké SATA na zálohy (+ zaplacení externího disku na off-site zálohy u nějakého poskytovatele nebo vlastní řešení). A jsme rázem z 19.000 za nejlevnější HW s Foundation z Alzy na stejné ceně, jako je uvedena výše.
Je to prvni nalezeny odkaz ... https://www.stolnipocitace.cz/1-cpu-servery/134031-hp-proliant-microserver-gen8-server-bez-os-intel-g1620t-23ghz-ram-1x4gb-bez-hdd-sata-nhp-lff-operacni-system-win-server-f.html
Nejsou tam disky (zadne) tzn rekneme +4k za dva. Do 10k bez dane zcela jiste. Na soho zcela dostatecne reseni. Do 15 uzivatelu (nelze rozsirit - tedy licencne).
Pokud se hodně nepletu, tak Essentials vyžadují doménu. Takže si udělám doménu, například dramon-win.local, nastavím MS SQL a pokud nemusím, tak tam už nelezu :). Takže nějaký Dashboard neřeším, ale ani nepoužívám.
Všechno ostatní řeším na Linuxu, včetně skutečně používaného Active Directory pomocí Samby v4.