Fórum Root.cz
Hlavní témata => Server => Téma založeno: ZAJDAN 20. 06. 2018, 11:06:15
-
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
-
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.
-
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.
-
Nejprve by chtelo poradne vedet, o co se vlastne tazatel snazi, co ma byt cilem jeho snazeni
A az nasledne hledat vhodna reseni
-
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
-
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....
-
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?
-
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
-
Utok zvenci je zakazat pristup do DB zvenci na port 3306 :D
Pokud pristup tak sifrovat (naco jako http://www.stuartellis.name/articles/mysql-remote-access/) a nebo jen z localhostu a pres VPN treba
-
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.
-
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.
-
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
-
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.
-
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
-
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í.
-
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.
...
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í.
Zde, ZAJDANE, souhlasím. Oddělení může snížit jen určitý typ rizik, mimo to byste měl mezi oddělenými stroji vytvořit VLAN a i v rámci ní mít firewall a dokonce i na odchozí spojení. Ani to sice, jak píše pan Němeček, nezabrání 100 % útoků, ale minimálně to dost zkomplikuje život těm, kteří budou útočit jen skrz nějakou slabinu, ale nezíská přímo přístup do celé instalace. Pokud ho získá, otevře si aplikaci, vyčte heslo k databázi a má data tak jako tak.
Pak by měla být zabezpečena i nová odchozí spojení ze serveru, protože tím ztížíte stažení dalších nástrojů, kteřé útočníci využívají. Management (SSH) by měl být dostupný jen z privátní VLAN, do ní přístup např. přes VPN.
Aplikace je samozřejmě základ. Pokud necháte díru v samotné aplikaci, nezachrání Vás nic. Proxy může pomoci např. tím, že ještě dodatečně omezí jak velikost POST requestu, tak i návratu. Tím opět zpomalíte únik dat a zabráníte části automatizovaných scriptů, které hackůjí, aby provedly, co potřebují.
Nedá se do diskuse popsat, co máte udělat, to jsou jen takové tipy, které ve Vás mají nastartovat zamyšlení se nad tématem. Je opravdu nejlepší to svěřit do rukou odborníka, ten to dá nejlépe dohromady s architektem aplikace / řešení.
(Mám ale trochu pocit, že se snažíte dohnat jakousi bezpečnost "šifrováním", ale ve skutečnosti máte běžnou webovou appku nejlépe běžící na apachi, s .htaccessem a mysql, vše v jednom virtual rootu, ... - tam bezpečnost nenaženete a opravdu začněte od appky a její architektury).
-
web za reverzní proxy
Není to málo? Na proxy se nikdy nesmí šetřit. Já bych tam dal minimálně haproxy → nginx → Apache, a zvážil bych hyproxy → Varnish → nginx → Apache. Čím víc proxy, tím víc Addidas!
Máte pravdu v tom, že reverzní proxy se běžně nasazují – ale vždy to má nějaký důvod. A často také vůbec žádný důvod neexistuje, a pak je zbytečné tam reverzní proxy cpát jen tak, aby tam byla.
-
Hoši, zas taková Lamka nejsem...aplikace predevším.
Neříkám, že ji mám zabezpeženou dokonale, ale to, na co jsem se ptal jsou jen další věci, kterými chci ztrpčit život loupežníkům.
Jo a nechci to zařeknout, ale ta reverzni proxina naboostrovala načítání webu...je to znát.
díky
-
Ja bych jeste doporucil si trochu pohrat se SELinuxem. Myslim ze by mohl taky par problemu vyresit.