NOVINKA - Online rekvalifikační kurz Python programátor. Oblíbená a studenty ověřená rekvalifikace - nyní i online.
Hledáme nové posily do ITnetwork týmu. Podívej se na volné pozice a přidej se do nejagilnější firmy na trhu - Více informací.
Avatar
Juraj Mlich
Tvůrce
Avatar
Juraj Mlich:28.12.2014 14:59

Zdravím programátori,

budujeme aplikáciu (teda zatiaľ iba navrhujeme) a narazili sme na jeden kritický problém. Nenapadá nás takmer žiadne riešenie, až na jedno, ktoré sa nám pravdu povediac nepripadá práve najlepšie a zabralo by nám mnoho času.

Pod našou aplikáciou si predstavte jednoduchý blogovací systém. Obsahuje dve tabuľky - sekcia a článok (väzba M:N). My však potrebujeme, aby sekcie boli uložené v jednom súbore a ďalej, aby tabuľka s článkami bola uložená v samostatných súboroch podľa sekcií (články v sekcií A budú uložené v súbore A). Avšak naš problém spočíva v tom, že potrebujeme vykonávať dotazy nad všetkými článkami, čiže potrebujeme tieto časti dát neskôr spojiť do jednej veľkej tabuľky.

Oddelenie dát do súborov je nutné kvôli šifrovaniu.

Nenapadá nás žiaden efektívny spôsob, ako takéto niečo uskutočniť. Ako databázu plánujeme použiť HyperSQL, čiže jediná cesta, ktorá ma napadla, bola dopísať si potrebnú funkcionalitu priamo do databáze. Ale to by zabralo ďalší čas (potrebný na testovanie celej databáze, implementáciu a vôbec zorientovanie sa v kóde danej DB).

Napadá Vás nejaké riešenie tohoto problému?

Ďakujeme :-)

(Aplikácia samozrejme nie je o nejakom blogovom systéme, ide o omnoho komplexnejší systém)

 
Odpovědět
28.12.2014 14:59
Avatar
Martin Dráb
Tvůrce
Avatar
Odpovídá na Juraj Mlich
Martin Dráb:28.12.2014 16:42

Zdravím,

Oddelenie dát do súborov je nutné kvôli
šifrovaniu.

jestli to chápu dobře, tak chcete část informací o článkách (některé články) šifrovat. Co je přesně cílem tohoto šifrování? Ochránit daný obsah pro případ, že se někomu podaří dostat na disk serveru, nebo i zabránit dotazy nad ním, nebude-li mít uživatel (ten, kdo dotazy posílá) dostatek oprávnění?

Bude takovýchto šifrovaných částí více druhů, nebo lze články rozdělit pouze na druhy dva – šifrované a nešifrované?

Editováno 28.12.2014 16:43
Nahoru Odpovědět
28.12.2014 16:42
2 + 2 = 5 for extremely large values of 2
Avatar
mkub
Tvůrce
Avatar
Odpovídá na Juraj Mlich
mkub:28.12.2014 17:08

tak na ukladanie dat do suboru zabudnite, idelanejsim sposobom je pouzivat na udaje rovno databazu a vyhoda pouzitia databazy je aj v tom, ze je optimalizovana na ukladanie a vyhladavanie dat, nez je samotna praca so subormi...
keby ste to riesili pomocou suborov, tak by ste museli si vytvorit format suborov, kde zacinaju a kde koncia samotne udaje a vytvarat zvlast subor pre kazdy zaznam nie je to prave orechove - mohlo by sa stat, ze sa ulozisko dat zaplni mnozstvom niekolkobajtovych suborov a dojde volne miesto

a co sa tyka oddelovania dat do suborov kvoli sifrovaniu, podla mna je uplna hlupost

Editováno 28.12.2014 17:09
 
Nahoru Odpovědět
28.12.2014 17:08
Avatar
mkub
Tvůrce
Avatar
Odpovídá na Juraj Mlich
mkub:28.12.2014 17:15

a dalsia vec... ukladanie udajov do suborov nie je bezpecne ako do databazy, lebo databaza pouziva viacero mechanizmov, ako zabranit strate dat (napr. zamykanie na citanir, resp. na zapis; transakcie,...) a takisto ukladanie dat do suborov zvysuje aj odcudzenie dat, kedze sa vsetky udaje ukladaju na webovy server a nie na db stroj

 
Nahoru Odpovědět
28.12.2014 17:15
Avatar
Juraj Mlich
Tvůrce
Avatar
Odpovídá na Martin Dráb
Juraj Mlich:28.12.2014 17:45

No v skutočnosti je to omnoho komplikovanejšie, ale vo svojej podstate, šifrovanie je tam len kvôli zabráneniu prístupu dát pre užívateľa, ktorý by tie dáta nejakým spôsobom získal.

Čiže - "Ochránit daný obsah pro případ, že se někomu podaří dostat na disk serveru".

Viacero druhov nebude, dáta budú buď nešifrované, alebo šifrované.

 
Nahoru Odpovědět
28.12.2014 17:45
Avatar
Juraj Mlich
Tvůrce
Avatar
Odpovídá na mkub
Juraj Mlich:28.12.2014 17:48

Premyslené to máme dobre, je tam viacero faktorov. Samotné šifrovací proces sme ešte nepremysleli, ale to je v tejto chvíli nepodstatné.

Napísal som niekedy, že dáta ukladáme do súborov bez použitia databáz? Databáza použitá bude, nebude ale použitá "in-file" databáza (HyperSQL pravdepodobne).

Prosím držme sa témy, nie sme žiadny začiatočníci a presne som napísal, čo potrebujeme, zvážili sme všetky iné možnosti.

 
Nahoru Odpovědět
28.12.2014 17:48
Avatar
Martin Dráb
Tvůrce
Avatar
Odpovídá na Juraj Mlich
Martin Dráb:28.12.2014 20:15

No, pokud budou všechna data buď šifrovaná, nebo nešifrovaná, tak mi přijde, že tabulku Články nemusíte do více souborů rozkládat; prostě budete všechny údaje šifrovat.

V databázích se moc nevyznám, z rychlíku jsem viděl snad jenom MySQL a ostatní DB ani dalekohledem z rychlovlaku, ale pokud se dobře pamatuji, MySQL (alespoň v nějakém nastavení) ukládá data jedná tabulky do jednoho souboru. Samozřejmě, indexy asi budou někde jinde, to je pravda.

Pak bych se spíš soustředil na to, jak samotný proces šifrování a dešifrování bude probíhat. Přijde mi, že by se vám hodilo, aby soubory dané tabulky byly na disku uložené v šifrované podobě, přičemž při načítání jejich obsahu databázovým enginem bude docházet k transparentnímu dešifrování (a při ukládání dat k transparentnímu šifrování). Tohle by se možná dalo implementovat i relativně snadno, pokud má daná databáze unifikovaný přístup k disku/souborům – tzn. používá na to několik málo procedur.

Výsledek pak bude takový, že data se budou nacházet v otevřené podobě pouze v paměti procesů databáze, takže nad nimi bude možné provádět dotazy. Nevím, jak je na *NIXech při útoku realistické číst paměť cizích procesů, tudíž se třeba útočník může do té paměti podívat a ta data si odtud vytáhnout. Ale pořád to bude lepší, než je nechat v souborech nešifrovaná.

HTH

Nahoru Odpovědět
28.12.2014 20:15
2 + 2 = 5 for extremely large values of 2
Avatar
mkub
Tvůrce
Avatar
Odpovídá na Juraj Mlich
mkub:28.12.2014 20:32

to, co ma byt sifrovane (napr. prihlasovacia stranka a stranka s osobnymi udajmi) by mala byt riesena na urovni SSL s certifikatom, co sa tyka hesiel, tak tie by sa mali sifrovat na strane WEB servera a ukladane do databazy na DB serveri spolu s registracnymi a osobnymi udajmi a opravneniami uzivatelov daneho portalu a subory, kedze vyhladavanie v suboroch je narocnejsia, nez vyhladavanie v databaze, tak by som pouzil maximalne na systemove logy, kde by sa logovalo napr. zlyhanie spojenia s databazou, resp. pokusy o prienik a podobne menej narocne udaje na vyhladavanie, kde sa castejsie zapisuje a menej casto sa v nich vyhladava

napr. na vyhladanie urciteho zaznamu v SQL databaze staci iba jednu poziadavku a SQL server tu poziadavku spracuje a sam si vyhlada vo svojich suboroch potrebne info a vrati to spat v podobe odpovede... a okrem toho je ovela vykonejsi, nez WWW server
a WWW server by sa nemal zaoberat s ukladanim a citanim udajov z filesystemu, mal by prijat od browsera poziadavku, spracovat ju a poslat odpoved... to by mala byt jeho prvomrada uloha, nie ukladanie dat...

a co sa tyka zabezpeceniu dat sifrovanim, tak sa treba pripravit, ze kazde sifrovanie nieco stoji a cim viac bude uzivatelov, tym bude dany system vytazeny a bude hrozit, ze web server uz zacne odmietat poskytovat sluzbu (tzv Denial of Service)

 
Nahoru Odpovědět
28.12.2014 20:32
Avatar
Matúš Petrofčík
Tvůrce
Avatar
Odpovídá na Juraj Mlich
Matúš Petrofčík:28.12.2014 20:33

Neviem presne o akú databázu sa týka (nikdy som o nej nepočul) a neviem či sa jedná 100% o webový projekt alebo je to niečo iné. Každopádne predpokladám že databázy funguju na rovnakom princípe, a predpokladám že budete používať relačnú databázu (tabuľky, nie celé objekty).

Vtedy mi príde riešenie jednoduché:
Ak chcete ukladať články, ale niektoré z nich majú byť šifrované, tak vám stačí stále jedna tabuľka pre všetky články. Tá tabuľka bude mať tieto atribúty: id_clanku, nazov_clanku, obsah_clanku, .... a sifrovany_clanok. Ten posledný atribút sifrovaný_clanok bude typu boolean (pravda/nepravda) a slúži na odlíšenie šifrovaných článkov od nešifrovaných.

Logika pri vypisovaní bude jednoduchá:

  1. Ak má daný článok, ktorý chceme vypísať v atribúte sifrovany_clanok pravdu (true), tak ho najprv odšifrujeme našou odšifrovacou funkciou, a až tak vypíšeme, pretože bol šifrovaný.
  2. Ak má článok v atribúte nepravdu (false), tak ho rovno vypíšeme, lebo vieme že neni šifrovaný.

S ukladaním článkov je to rovnaké:

  1. Chceme článok šifrovať? tak ho zašifujeme našou šifrovaciou funkciou, uložíme do DB s tým, že atribút sifrovany_clanok bude pravda (true).
  2. nechceme článok šifrovať? tak ho rovno uložíme do DB s atribútom sifrovany_clanok, ktorý bude mať hodnotu nepravda (false)

Samozrejme je vhodné šifrovať len obsah článku, zbytočne šifrovať názov, dátum a podobne.

Ak raz články budeme nejakým spôsobom šifrovať, tak si musíme zabezpečiť funkciu, ktorá nám to aj rozšifruje, a v budúcnosti ju nemeniť, inak sa k článkom sami nemusíme dostať.

Jo a používať cézarovú šifru neodporúčam :D
dúfam že som pomohol, ak som mimo problematiku, ospravedlnujem sa

//edit1:
"aby tabuľka s článkami bola uložená v samostatných súboroch podľa sekcií (články v sekcií A budú uložené v súbore A)" ... stačí jedna tabuľka ktorá bude mať v sebe ďalší atribút napr. sekcia_id ktorý bude cudzím kľúčom na danú sekciu
tak stačia 2 tabuľky: 1 na sekcie a 1 na články... ľahšie sa tak budú pridávať sekcie, lebo nemusíte vytvárať novú tabuľku pre novú sekciu

//edit2:
v akom prog. jazyku píšete tú vašu aplikáciu? nejaké bližšie info?

Editováno 28.12.2014 20:38
Nahoru Odpovědět
28.12.2014 20:33
obsah kocky = r^2 ... a preto vlak drnká
Avatar
Jindřich Máca
Tvůrce
Avatar
Jindřich Máca:28.12.2014 22:09

Ahoj všem,

já se také částečně podílím na zmíněném projektu a co jsem to tak pročítal, tak to kolega nevysvětlil úplně nejlépe, takže to zkusím říct trochu jinak. :)

Zapomeňte teď na vnitřní architekturu databází, nám jde čistě o fyzický způsob ukládání dat a jeho zabezpečení například při fyzickém odcizení disků.

Příklad mluvící za vše - MySQL si ukládá data do 3 druhů souborů:
.frm – definice tabulky
.MYD – data tabulky
.MYI – klíče tabulky
viz. http://cs.wikipedia.org/wiki/MySQL

A v podstatě, když se dostanete na disk a najdete soubor s koncovkou .MYD, tak z něj můžete vesele číst data. A přesně o zajištění této bezpečnosti nám jde, tzn. jak nejlépe docílit toho, aby tato data byla nějakým způsobem šifrovaná a zároveň, aby k nim byl klasický databázový přístup.

Pozn.: Ano, když data zašifrujete uvnitř databáze, tak budou šifrovaná i uvnitř těchto souborů, ale my nad daty zároveň chceme provádět operace jako např. řazení a vyhledávání podle názvu atd.

Pozn.2: @Martin Dráb Ano, zatím u nás vede metoda transparentnímu šifrování a dešifrování pro jednotlivé soubory, ale chtěli jsme právě slyšet názor více lidí a lidí z venku, jestli třeba neznají něco lepšího nebo nějaké hotové řešení, protože tohle budeme muset nejspíše programovat sami. ;)

Doufám, že už je to teď jasnější a předem děkuji za odpovědi! ;)

Editováno 28.12.2014 22:15
 
Nahoru Odpovědět
28.12.2014 22:09
Avatar
Martin Dráb
Tvůrce
Avatar
Odpovídá na Jindřich Máca
Martin Dráb:28.12.2014 22:55

Pozn.2: @Vrtule Ano, zatím u nás vede
metoda transparentnímu šifrování a
dešifrování pro jednotlivé soubory, ale
chtěli jsme právě slyšet názor více lidí > a lidí z venku, jestli třeba neznají
něco
lepšího nebo nějaké hotové řešení,
protože
tohle budeme muset nejspíše programovat
sami.

Když nad tím přemýšlím, tak většina normálních databází asi ty soubory přímo nečte, ale mapuje do paměti. Což vám opravdu nezávidím, minimálně pokud vaše řešení má fungovat na Windows.

Další teoretickou možností by bylo umístit fyzická data na jiný stroj na šifrovaný souborový systém a databázový engine by si je tahal přes něco jako síťový disk. Pak by "nevadilo", když by si někdo domů odnesl ten stroj s fyzickými daty. Ale musela by se nějak vhodně vyřešit autentizace DB enginu. Pak by bylo nutné:

  1. detekovat, že se něco neblahého děje (stroj s DB enginem je kompromitován),
  2. dávat pozor na to, zda se někdo v rámci procesů DB enginu nesnaží vykonat nepatřičný kód (za předpokladu, že k síťovému disku by neměl nikdo jiný přístup než DB engine).

Ale je to spíš taková variace na předchozí téma, než že by tato metoda přinášela nějaké zásadní novinky.

Nahoru Odpovědět
28.12.2014 22:55
2 + 2 = 5 for extremely large values of 2
Avatar
mkub
Tvůrce
Avatar
Odpovídá na Jindřich Máca
mkub:29.12.2014 8:15

myslim, ze asi riesenim by bolo ukladat udaje do databazy a databaza by bola na sifrovanej particii (idealne by bolo asi pouzitie dm-crypt v spojeni s Linuxom), ali pri sifrovani particie s udajmi treba pocitat aj so znizenim vykonu pri kazdej manipulacii s databazou

 
Nahoru Odpovědět
29.12.2014 8:15
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 12 zpráv z 12.