Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Miroslav Šilhavý

Stran: 1 ... 79 80 [81] 82 83 ... 206
1201
Pokud umíte správně používat SQL, pak je rozdělení na místě - rozdělit dopředu, sloučit se to dá vždycky. Opačně se to dělá hůř.

Co se týče správného použití SQL, tak tam mám snad jen poznámku k tomu, že SQL se používá pro maximální optimalizaci práce s daty, a aby se přenášelo minimum dat - pak nevadí ani oddělený server. Bohužel, MySQL se dá optimalizovat jen velmi omezeně - spíš se používá na mnoho malých selectů než na jeden velký. V takovém případě se oddělení serverů projeví poklesem výkonnosti. (U ERP systémů není nic divného mít select na tři stránky, dvanáct joinů, pět subselectů apod., ale s tím Vám MySQL nepomůže).

Takže odpověď zní: při správném použití to smysl dává. Při nesprávném (které díky výběru technologií trochu předpokládám) to ubere na výkonu.

1202
Software / Re:Konverze archivu ze zip do 7z
« kdy: 02. 09. 2019, 19:02:28 »
Tak tar asi taky nemusi nacitat .tar celý celý - to by odporovalo jeho použití na páskách, ne? Ale nevím, zda to funguje s kompresí.

Je to přesně tak. Tar+komprese je vlastně solid archiv, proto i tar+gzip komprimoval vždy lépe, než samotný zip.
Rar, pokud se pamatuji, přišel se solid archivem a taky s archivací podle přípony (na dosu), čímž docílil toho, že podobné soubory se komprimovaly blízko sebe a tím docílil lepší komprese - něco tak na čtvrtině cesty mezi kompresí a kompresí s deduplikací.

Archivátor s vnitřní deduplikací neznám, ale docela by to mohlo být zajímavé, jen by asi bylo těžké určit velikost bloku pro deduplikaci. Malý blok = hodně režie. Velký blok = menší šance zásahu.

1203
Software / Re:Konverze archivu ze zip do 7z
« kdy: 02. 09. 2019, 17:20:48 »
ta solid archivace tam sla zapnout/vypnout.

info treba zde https://sourceforge.net/p/sevenzip/discussion/45797/thread/feb72a3e/

To je pravda, ale pak nebude přínos komprese proti ZIP tak výrazný, zejm. ne na malých souborech u kterých bývá problém extrahovat jednotlivě.

1204
Software / Re:Konverze archivu ze zip do 7z
« kdy: 02. 09. 2019, 15:59:03 »
Jsou to stovky GB velke archivy a zip ma na rozdil od tar moznost rychle zobrazit obsah archivu a extrahovat jednotlive soubory/adresare bez cteni celeho taru od zacatku. Obavam se, ze nic jineho nez zip, to byt nemuze.

Jenže 7z nebo XZ takovou výhodu už nemají - mají solid archivaci, tj. je potřeba rozbalit vše před tím, než můžete seeknout k jednotlivému souboru. Pokud potřebujete tuto funkci, pak nemáte jinou možnost, než zůstat u běžného ZIPU.

1205
Software / Re:Konverze archivu ze zip do 7z
« kdy: 02. 09. 2019, 15:49:47 »
Tak tmpfs by nebyl spatny napad, ale archivy maji stovky GB. Server ktery ma TB RAM mam jen jeden a na tohle ho vyuzit nemuzu 8). Neda se nic delat, bude to muset po jednom rozbalit na disk a zase zabalit.

Možná by bylo na zváženou zabalit to při té příležitosti do taru a pak komprimovat. Maličko si asi uškodíte v kompresním poměru, ale v budoucnu se Vám podobná operace bude dělat líp - právě bez rozbalování na disk.

1206
Ja ti to za 200 prevezu - ale jen v pripade ze odesilatel i prijemce bude spolehlivy a nebudu ani na jednoho nikdy cekat, zaroven mi bude tolerovano zpozdeni dopravni situaci ve meste, protoze jste si vybrali zrovna cas spicky. Ja muzu 24/7. Deal?

Já Vás hned beru, volejte 602301701.

1207
Software / Re:Konverze archivu ze zip do 7z.
« kdy: 02. 09. 2019, 11:16:15 »
Souhlas, tmpfs je jediné rozumné řešení, nicméně i to je svým způsobem "na disk".
Přebalit to jen jako proud dat - jako např. u tarovaných archivů - zip opravdu nejde.
7zip navíc umí využít víc jader (s malou penalizací na kompresním poměru) - a k tomu potřebuje mít možnost přistupovat k vícero souborům naráz.

1208
Spolehlivost je problém. Všechny tyto firmy - mluvím ze zkušenosti - mají obrovský problém s lidmi. Lidi jsou drazí a nespolehliví. Proto jsou ceny spíš vyšší (a porostou dál) a spolehlivost dost bídná. Dokonce i dříve naprosto spolehlivé expresní kurýrní služby v Praze fungují jen jakš takš.

Co byste si představoval, že se stane, když nedodrží smluvené podmínky? Nějakou pokutu? Tu by možná některé byly ochotny podepsat - ale určitě ne za 200 Kč / zásilka. Nebo náhradu škody? Tu už asi nikdo nepodepíše, a když tak za opravdu jiné ceny.

1209
Windows jsou na to připraveny. Když nainstalujete vmware tools, tak začne fungovat RAM balooning: https://searchservervirtualization.techtarget.com/definition/memory-ballooning. Tedy VM si vezmou maximum RAM, ale taky ji ochotně uvolní, pokud ji někdo jiný potřebuje.

Naopak bylo by plýtváním, kdyby si VM nevzala maximum RAM a nevyužila ji na cache.

1210
Když si půjdete založit účet na pobočku, taky si občanku naskenují a založí. Takže rozdíl je nulový.

V tomto případ musíte důvěřovat aplikaci a přenosu, že jsou zabezpečené. To bych docela důvěřoval, protože odchytit zrovna z jedné apky, když odesílá ausgerechnet tu fotku, to by byla náhoda.

Víc bych se skoro bál, že úředník v bance si může z mé občanky udělat kopie dvě, a na jejich základě udělat něco nekalého. To riziko selhání jednotlivce mi přijde vyšší.

1211
Server / Re:Kolik logů vlastně potřebujeme
« kdy: 30. 08. 2019, 09:20:45 »
A lze se ptát i zakázala umožnila připojovat si do sítě kdejaké zařízení (telefon)?

To už poškozeného vůbec nezajímá. Podle GDPR je vždy správce dat odpovědný. Může však prokázat, že ke zneužití došlo, ačkoliv udělal, co mohl.

Dívejte se na to z pohledu poškozeného. Někdo Vám zavolá nebo napíše e-mail a bude zřejmé, že v něm jsou informace, které o Vás věděl např. pouze e-shop, ve kterém jste před měsícem nakupoval. Bude tedy jasné, že data unikla touto cestou. V ten okamžik máte jako poškozený možnost žádat odškodnění. Vás pak vůbec nezajímá, jestli k úniku dat došlo vinou zaměstnance, nebo jestli je sprostě prodali, nebo jestli data vytáhl ze sítě nějaký vir. Vy jste prostě poškozený a oni jsou objektivně odpovědní.

Pokud se chtějí z odpovědnosti vyvinit, pak je na nich, aby ONI prokázali, že udělali vše, co lze požadovat. Pokud neprokážou, mají smůlu, nesou odpovědnost.

----

Proto radím každému, kdo za data odpovědnost nese, že první opatření je vůbec uvažovat o tom, jestli data potřebuju a jestli mi to stojí za ty rizika.

1212
Server / Re:Kolik logů vlastně potřebujeme
« kdy: 30. 08. 2019, 06:07:08 »
instituce by mely byt do jiste miry za data zodpovedne a nakladat s nimi opatrne. Jenze v praxi to muze a casto i je pomerne nakladna zalezitost. Nekdy i drasticka zmena firemnich procesu.

To si zase nemyslím. GDPR se zavádí roky, dlouho dopředu bylo avizované. Celá směrnice směřuje k poměrně jednoduchému cíli: data chránit, segregovat oprávnění, mít ve firmě pořádek. Objektivní odpovědnost byla stanovena, protože se jinak nikdo nemohl domoci práva.

Krome toho, ze logy drzim jenom jeden den, protoze proste vic si nemuzu dovolit ukladat. Kvalitativne prokazu, ze jsem udelal maximum pro naplneni GDPR. Ale proste nemam logy soudruzi, jako sorry jako.

Na logy existuje řešení mnohem víc. Spousta logů neobsahuje citlivé informace. Některé obsahují IP adresu, ale pokud např. není spojena spojitelná s query a dalšími informacemi, není to a priori citlivá informace. (Zde musí odpovědná osoba zjistit stav a tomu se přizpůsobit). Někdy stačí některá data anonymizovat, někdy stačí dostatečně bezpečně oddělit administrátora od dat a těch, kteří mohou logované informace spojit s konkrétními osobami. Cest je prostě mnoho.

Ocekava se, ze teda nejakej /mnt/hr/report/soubor.xlsx by mel byt proste logovanej kazda aktivita nad souborem. Protoze teoreticky ho mohl nekdo skopirovat pred rokem, dalsi rok potrva nez si toho nekdo nekde vsimne a pak prijde GDPR a rekne co? Chci 3 roky stary logy kdo pristupoval k tomuhle souboru, bo jinak neverim, ze to je bezpecny?

To je absolutně špatné pojetí GDPR, přesně to, co jsem říkal, že si firmy vyložili zcela naruby. Pokud se stane incident, v první řadě bude firma prokazovat, že jsou zaměstnanci poučeni jak se má s daty zacházet, jestli hned při nástupu do práce atd. Jestli probíhají pravidelné obnovy školení a jestli jsou nastaveny kontroly. To je úplně stejné, jako s pracovními úrazy: když se stane, tak firma musí prokázat vstupní lékařskou prohlídku, školení BOZP, doškolování BOZP, následně se zjišťuje, jestli je v praxi dodržováno. Když má zaměstnanec autonehodu a dojde ke zranění, zjišťuje se proškolení řidičů a jestli firma řidičskou kázeň kontrolovala (nebo jestli to nechala "prostě být").

Takže žádný log. Prokazovat budete, že máte ve firmě pořádek.

Co kdyz se stane, ze zamestnanec si nahral ten soubor na svym android, zazalohoval si to omylem ke googlu i s telefonem a kontaktama a uteklo to ve finale pres jeho ucet? Rozdil v tom jestli drzim logy den nebo 6 mesicu by asi nebyl. Drzet to jak ucetnictvi? 5-7 let bo kolik?

V první řadě se bude řešit: 1) co v souboru bylo za data, 2) proč bylo tolik dat v jednom souboru, 3) proč k němu měl zaměstnanec přístup (potřeboval to ke své práci?), 4) byl poučen, že nesmí data z firmy kopírovat?, 5) umožnila firma připojovat si do sítě kdejaké zařízení (telefon)? (není myšleno technicky umožnila, ale předpisem), 6) konrolovalo se to v praxi? (mnoho firem má předpisy na papíře, ale v praxi se nedodržují).

Účetnictví a zjeména mzdové účetnictví je ideální příklad. Mzdové záznamy se archivují 30 let. Od nepaměti každá zodpovědná firma (už snad od Rakouska-Uherska) měla mzdovou účtárnu zcela oddělenou. Osobní složky zaměstnanců byly pod dvěma zámky. Oddělení odemykal ráno šéf, běžní účetní chodili až po něm. --- To je odpovědný přístup v praxi. Dnes se na to pouze začalo kašlat, ale možné to bylo už před sto lety. (Dnes je to horší, že data nám uletí rychlostí světla).

Hezkým GDPR příkladem jsou e-shopy, které dodnes zcela zbytečně sbírají na doklady (faktury) jmnéno, adresu, ... Zcela zbytečně. Pak musí 10 let tyto doklady archivovat, tedy 10 let musí dbát na jejich ochranu. E-shop, který to má v hlavě v pořádku, vystavuje doklady bez jména. A údaje doplňuje jen na 10000 Kč a jen na požádání. Příkladem je IKEA - tam můžete pokladnou projet s nákupem za 60.000 Kč a vyjede jen paragon. Pro účely reklamace to stačí. Pokud chcete víc (do účetnictví), musíte na zákaznické služby a teprve tam Vám údaje doplní do faktury.

Soudruh politik to IT vidi a chape asi jako prumerny american mapu sveta. =/

To si nemyslím. Zrovna Vaše otázky ukazují, jak GDPR technici nerozumí a jak ho překrucují do úplně něčeho jiného, než je. Pokud jste zaměstnaný, tak to není Vaše chyba. Poučit Vás měl zaměstnavatel. Jestli to neudělal (neřešil), pak je to zase selhání. (A vím, že firmy často GDPR házejí na hrb ajťákům, kteří s tím mají pramálo co do činění).

1213
Server / Re:Kolik logů vlastně potřebujeme
« kdy: 29. 08. 2019, 20:39:33 »
Hypoteticky, kdyz budu uchovavat logy den, co na to GDPR? Co kdyz bych delal updaty treba tydne, ale proste bych si nevsiml, ze tam nekde bezi neco navic (cili splnil bych nejakej ten best effort na updaty). Kdyz nebude log, jak to kdo prokaze (resp. nebude se dat dopatrat). Co pak s tim?Je to jak s ISP/Operatorama? Uchovavat vsechno aspon 6 mesicu? A co na to firemni router/firewall? :)

GDPR pravidla si musí nadefinovat provozovatel systému. Ty nejprve začínají u osob, oprávnění a oprávněných technických požadavků. Výsledné technické řešení může GDPR naprosto vyhovovat i v případě, že logy archivujete deset let, pokud na to bude mít firma nastavené procesy.

V praxi jsem ale moc firem, které by GDPR chápaly, nepotkal. Většinou si myslí, že GDPR je nějaké technické opatření, vůbec nerozumí tomu, že je to zejména organizační opatření. Proto, při pohledu na praxi, doporučuju každému uchovávat co nejméně, protože tím se aspoň trochu kompenzuje tento přístup.

U GDPR také není kdo by co prokazoval. GDPR nefunguje na principu prohřešek-pokuta. Vy vlastně data nemusíte chránit vůbec, ale jakmile dojde k průšvihu (unikne něco), karta se obrací. V tu chvíli bude položen předpoklad odpovědnosti provozovatele, a je to naopak provozovatel, který musí prokázat, že jak vnitřními směrnicemi, tak proškolením personálu, tak technickými opatřeními udělal vše pro to, aby k úniku nedošlo. Pokud to neprokáže, je za únik odpovědný a bude platit odškodnění. Pokud tedy snížíte dobu uchovávání logů na minimum, je to jednoznačně plus do této skládačky.

1214
Server / Re:Prioritizace lokálních účtů vůči doménovým
« kdy: 28. 08. 2019, 14:02:14 »
Já jen dodám, že z bezpečnostního hlediska není dobrý nápad stejná konta v AD stínovat lokálními účty. Technicky vzato to jsou jiné účty, jen propojené (třeba loginem) a to otevírá potenciál pro průšvihy.

Doporučil bych zřídit si repliku AD na místě. Replikace AD je jednoduchá a funkční, a budete mít vždy při ruce domain controller, který odpoví.

Tak by se to mělo řešit.

1215
Odkladiště / Re:Streaming TV do webu
« kdy: 27. 08. 2019, 17:21:16 »
jediná podmínka je, že tam YT umístí reklamy.

Podmínka YT je, že to můžou kdykoliv odvolat a embedding dočasně i trvale zatrhnout.
Prostě je to dočasně udělené právo embedovat, jakmile se YT rozmyslí, máte smůlu, žádný nárok nevzniká.

Stran: 1 ... 79 80 [81] 82 83 ... 206