Šifrování existující databáze

[ZAJDAN]

Zdar...
mam již existující MySQL databázi a rozhoduju se jakou metodou ji začít šifrovat.
Nechám si doporučit od zkušených, tak když by někdo doporučil/poradil, budu rád.
Chtěl bych zachovat čitelnost DB pro různé aplikace(dle mé potřeby).
Proto nechci šifrovat na úrovni jazyka, který tam bude sypat data, ale přímo na úrovni DB.

UPDATE user SET EMAIL = AES_ENCRYPT(EMAIL, 'password');
šifrujete jen citlivé sloupce nebo celou DB?


díky

[Reklama]

[Jenda]

Nebylo by rozumnější zašifrovat disk, na kterém to běží, například LUKS/dm-crypt? Individuální šifrování takto krátkých políček podle mě bude mít velikostní (16 bajtů IV + zarovnání na 16 bajtů bloku AES v blokovém módu + 16 v případě AEAD) i výkonnostní overhead.

[MP]

Kdyz jsem videl moznosti/slozitost sifrovani databazi na urovni postgresql, tak pochybuji, ze na mysql to bude vyrazne lepsi. Jedina cesta je pak sifrovat na urovni disku/fs.

[Vilith]

Nejprve by chtelo poradne vedet, o co se vlastne tazatel snazi, co ma byt cilem jeho snazeni
A az nasledne hledat vhodna reseni

[ZAJDAN]

Nejprve by chtelo poradne vedet, o co se vlastne tazatel snazi, co ma byt cilem jeho snazeni
A az nasledne hledat vhodna reseni

ochránit data při odcizení DB

[Reklama]

[Vilith]

Pred kradezi disku?
Sifrovat filesystem a nemit desifrovaci klic na serveru (komplikovanejsi spousteni severu). Zajistit fyzickou bezpecnost serveru

Kradezi z bezici DB to ale nezabrani....

[Cek]

Nejprve by chtelo poradne vedet, o co se vlastne tazatel snazi, co ma byt cilem jeho snazeni
A az nasledne hledat vhodna reseni

ochránit data při odcizení DB

A odcizenim DB myslis zkopirovani, kradez disku nebo co vlastne?

[ZAJDAN]

A odcizenim DB myslis zkopirovani, kradez disku nebo co vlastne?

odcizení/průnik zvenčí do běžícího stroje/databáze
jak říkám, nechám si doporučit, třeba je řešení, u kterého není potřeba šifrovat DB
šifrování disku dle mne řeší fyzické odcizení/krádež...to já řešit nepotřebuji

[Vilith]

Utok zvenci je zakazat pristup do DB zvenci na port 3306
Pokud pristup tak sifrovat (naco jako http://www.stuartellis.name/articles/mysql-remote-access/) a nebo jen z localhostu a pres VPN treba

[Miroslav Šilhavý]

mam již existující MySQL databázi a rozhoduju se jakou metodou ji začít šifrovat.
---
šifrujete jen citlivé sloupce nebo celou DB?

Popište spíš, co řešíte za problém. Tedy jaká data, v jakém režimu a před kým chcete chránit. Jaká identifikujete rizika, která chcete eleminovat.

Váš dotaz je ve stádiu výběru řešení, ale popsaná situace spíš ukazuje, že jste ve stádiu identifikace rizik.

[ZAJDAN]

Váš dotaz je ve stádiu výběru řešení, ale popsaná situace spíš ukazuje, že jste ve stádiu identifikace rizik.

máte pravdu!
mám dva formulaře veřejně dostupné a z nich padají data do DB
- jeden je v PHP(PDO)
- druhej RubyOnRails
jsou tam data jako maily, IBAN,BIC, přibudou tam kódy k zámkům(boxy, kontajnery)

Samozřejmě bezpečnost celého serveru je první co řeším(ať už nastaveni web serveru, firewall, etc).
Ale tak i tak se může útočníkovi podařit proniknout dovnitř a mě zajímá jak nejlépe utajit data v DB.

[Vilith]

Zabezpecit aplikaci - HTTPS, validni kod, povolit vstup pouze autorizovanym uzivatelum do aplikace, zakazat remote acces do DB

Nebo resit pristup do aplikace z povolenych IP, pouze VPN

[Miroslav Šilhavý]

jsou tam data jako maily, IBAN,BIC, přibudou tam kódy k zámkům(boxy, kontajnery)
...
Ale tak i tak se může útočníkovi podařit proniknout dovnitř a mě zajímá jak nejlépe utajit data v DB.

Pokud se dostane do běžícího serveru, tak žádné šifrování, ani na úrovni filesystému Vám nepomůže. Data budou přimountovaná a viditelná. Šifrování filesystému ochrání po odcizení serveru, kdy se vypne a bez rozšifrování data neuvidí. Je potřeba ale také pohlídat swap a veškeré tempy - v nich mohou zůstat jak nesmazané soubory s daty, tak na samotném disku bloky dat s informacemi.

Pokud se jedná o kódy, tak tam si musíte položit otázku, jestli potřebujete mít samotný kód šifrovaný reverzibilně (tedy se správným klíčem se dostanete k původnímu kódu), nebo jestli uložíte jen osolený otisk. Otisk má výhodu v tom, že můžete ověřit, že "kdosi" má v ruce správný kód, ale nedokážete zpětně rozšifrovat, jaký je (leda hrubou silou). To už je ale věc návrhu architektury, ne šifrování dat.

No a samozřejmě, platí pravidlo oddělování. Databáze na jiném stroji než web, web za reverzní proxy, virtualhosty oddělené a podle  účelu mít na virtualhostech co nejnižší limity (timeouty, paměť, ...). Pokud to namrskáte na jednu virtuálku u nějakého hostéra, DB bude přímo na webseveru, atd., atd., pak nepřemýšlejte ani o šifrování. Je to zbytečný výdaj energie, který nemůže napravit špatně postavené základy.

[ZAJDAN]

No a samozřejmě, platí pravidlo oddělování. Databáze na jiném stroji než web, web za reverzní proxy, virtualhosty oddělené a podle  účelu mít na virtualhostech co nejnižší limity (timeouty, paměť, ...). Pokud to namrskáte na jednu virtuálku u nějakého hostéra, DB bude přímo na webseveru, atd., atd., pak nepřemýšlejte ani o šifrování. Je to zbytečný výdaj energie, který nemůže napravit špatně postavené základy.

děkuji za Vaše rady!
Přinutil jste mne rozumným názorem začít provádet jednotlivé kroky. Nemám public hosting, fyzickej stroj mam u sebe.
- jako první věc jsem před Apache2(web server) nahodil Nginx jako reverzní Proxy
- jako druhou věc přesunu DB na jinou virtuálku
- pak začnu dělat to další

díky

[Ondrej Nemecek]

No a samozřejmě, platí pravidlo oddělování. Databáze na jiném stroji než web, web za reverzní proxy, virtualhosty oddělené a podle  účelu mít na virtualhostech co nejnižší limity (timeouty, paměť, ...). Pokud to namrskáte na jednu virtuálku u nějakého hostéra, DB bude přímo na webseveru, atd., atd., pak nepřemýšlejte ani o šifrování. Je to zbytečný výdaj energie, který nemůže napravit špatně postavené základy.

děkuji za Vaše rady!
Přinutil jste mne rozumným názorem začít provádet jednotlivé kroky. Nemám public hosting, fyzickej stroj mam u sebe.
- jako první věc jsem před Apache2(web server) nahodil Nginx jako reverzní Proxy
- jako druhou věc přesunu DB na jinou virtuálku
- pak začnu dělat to další

díky

Proxy či přesun databáze na jinou virtuálku vás ani omylem nezachrání. Musíte si uvědomit, kudy se lze k datům dostat a cíleně tomu zamezit. A tam, kde to lze, omezit i okruh potenciálních útočníků.

Takže zakažte na virtuálce všechny nepotřebné služby a porty, otevřete jen port pro ty webové aplikace. Pokud to lze, tak jen pro vybrané IP adresy nebo pouze prostřednictvím VPN.

Pak zůstane největší dírou ta samotná aplikace, resp. ty dvě aplikace. Pokud si aplikace někde uchovává heslo k té databázi, pak kdokoli hackne aplikaci má i databázi. V tom případě je už úplně jedno, kde databáze běží a zda je šifrovaná. Takže se nejprve věnujte aplikaci.

Pokud aplikace poběží vynuceně přes https (HSTS), nebude možné odposlechnout komunikaci prohlížeč - aplikace. Pokud pro aplikaci nastavíte přístup přes klientské certifikáty, nedostane se do aplikace nikdo bez těch certifikátů. Bude si ty certifikáty muset nainstalovat, aby se na aplikaci dostal. Tím omezujete okruh útočníků.

Pak se musíte podívat na samotné uživatele té aplikace, zda mohou někomu prozradit hesla nebo předat certifikáty. Pokud ano, musíte to ošetřit smluvně, je dobré omezit platnost certifikátů, aby po určité době únik přístupových údajů přestal vadit. Tím omezíte dobu, kdy lze provádět útok.

Pokud budete mít tohle zmáknuté, pak teprve můžete řešit, zda šifrovat databázi nebo třeba celý souborový systém. Tím se totiž bráníte přímému odcizení disku nebo databázových souborů - pro start databáze bude potřeba zadat heslo resp. šifrovací klíč, takže pokud někdo disk nebo počítač ve vypnutém stavu ukradne, nebude moci přečíst data z databáze nebo souborového systému. Ale pokud běží server v serverovně, je asi zamčený v racku a tahle krádež není moc pravděpodobná. Samozřejmě pokud by aplikace běžela na mobilních zařízeních, je situace zas úplně jiná.

Pokud na tom záleží, nechte si to zkontrolovat od někoho, kdo se tím rutinně zabývá. Jako laik v té oblasti nemáte šanci domyslet všechny úskalí.