Na zabezpečení "z venka dovnitř" potřebuješ mít hlavně pořádný firewall, tím nemyslím že musí být drahý, ale který monitoruješ, který je konfigurovatelný a který hlavně umíš nastavit, toto je to nejdůležitější.
A musíš mít čas na sledování a vyhodnocení logů, ev. nějaký honeypot.
Ideál, pro nízké rozpočty, je pfsense.
Na data "uvnitř" je nejlepší ochrana záloha (GFS, 3-2-1, snapshot atd.)
Běžný prvky bezpečnosti jako hesla apod. považuji za samozřejmost a toto vůbec nemá cenu rozebírat.
Myslím si, že nějaká kouzla na úrovni DB a aplikace jsou spíše otázkou bezpečnosti pro napadení "zevnitř", tzn. důvěryhodným a plně autorizovaným uživatelem. A to je otázka spíše procesů, návrhu app. apod.
Záleží na tom, co myslíte „kouzly na úrovni aplikace“.
Hlavně je potřeba mít bezpečnou aplikaci. Tj. aplikace musí kontrolovat oprávnění, veškeré kontroly provádět na backendu (i když je třeba stejná kontrola v klientovi). Musí pracovat se strukturovanými daty, pokud je to alespoň trochu možné (binding proměnných v SQL dotazech, tam je to bez diskuse; používat DOM pro generování HTML výstupu, pokud to jde); pokud to není možné, tak alespoň používat správné escapování (např. to HTML, když ho nejde generovat ze strukturovaných dat). Používat konstrukce, framework nebo ideálně jazyk, který brání určitým typům chyb (třeba automatickou správu paměti, která brání chybám buffer overflow).
Dobré je mít na to testy, to bych nazval jedenapůltou vrstvou zabezpečení.
Aplikační firewall (např. WAF pro webové aplikace) je až druhá, volitelná vrstva zabezpečení – a rozhodně na ni nelze spoléhat, pokud máte díry ve vrstvě první. Pokud se jedná o web, pak bych asi ještě jako vrstvu 1,9 zařadil pozapínání různých bezpečnostních funkcí prohlížečů pomocí hlaviček. Oproti WAF je extrémně snadné to nastavit a používat; když to jednou nastavíte, je extrémně nízká pravděpodobnost false-positive vyhodnocení (což o WAF rozhodně neplatí) a o případné chybě se tak můžete dozvědět brzy.
Pokud je to one-man show, po té, co budete mít pořádně první krok, už nebudete mít čas ani prostředky řešit druhý krok (aplikační firewall). Řešit ochranu dat v případě, že se útočník už dostane do aplikace, by byl až třetí krok – a rozhodně nemá smysl se tím zabývat před tím, než budete mít vyřešené kroky 1 (včetně 1,5 a 1,9) a 2. Jedinou výjimkou je hashování hesel – to se nedělá kvůli bezpečnosti, ale kvůli PR. Prostě kdyby vám hesla utekla a zjistilo se, že jste je nehashoval, budete mít ostudu. Že je to z hlediska bezpečnosti jedno, protože chyba je v tom, že prohlížeč vůbec uživatelské heslo někomu vydá, to nikoho nezajímá. Zároveň to hashování hesel je triviální udělat, zejména když se nebudete snažit vynalézat kolo. Když použijete nějakou funkci pro hashování hesel (Argon2, Scrypt, PbKDF2 – na cokoli z toho použít už hotovou knihovnu, která bude používat i sůl) a hesla vám uniknou, nikdo vám nic neřekne. (Já bych ukládání hesel řešil jinak, protože když už se to dělá, snažil bych se řešit hlavně tu bezpečnost, ne to dělat jen na efekt – ale nedoporučuju to ostatním, moje doporučení je udělat to na efekt tak, jak je to doporučováno bezpečnostními odborníky.)
Zobrazit příspěvky
