Bezpečnost webových aplikací a vícevrstvá architektura
Cílem tohoto příspěvku je navrhnout taková bezpečnostní opatření, která minimalizují riziko průniku do systému a možné narušení důvěrnosti, integrity a dostupnosti.
Je zřejmé, že budeme usilovat o tzv. security in depth přístup, protože jedině tak lze zajistit, že i v okamžiku, kdy jedno bezpečností opatření selže, tak další opatření v řadě úspěšnému průniku zabrání. Vzhledem k tomu, že útok může být veden jak z venku, tak i zevnitř organizace, musíme navrhnout taková opatření, která budou skutečně účinná.
Rozdělte aplikaci do vrstev
Popis jednotlivých vrstev, z kterých se typická vícevrstvá webová aplikace skládá, je uveden zde. Aplikaci rozdělte na vrstvu prezentační, aplikační a datovou, přičemž každou vrstvu umístěte do samostatné demilitarizované zóny (Demilitarized Zone, zkr. DMZ). V první DMZ bude umístěn webový server, ve druhé DMZ bude umístěn aplikační server a ve třetí DMZ bude umístěn databázový server, který bude od lokální uživatelské sítě též oddělen firewallem.
Komunikace mezi vrstvami
Zaveďte pravidlo, že každá vrstva smí komunikovat pouze se svou sousední vrstvou. To znamená, že není např. možné, aby server, který se nachází v první DMZ, navázal přímou komunikaci se serverem umístěným ve třetí DMZ. Komunikace mezi dvěma sousedními vrstvami bude v takovém případě probíhat přes firewall, na kterém bude nastaveno odpovídající pravidlo.
Dostupnost z internetu
Z internetu by měla být dostupná pouze první vrstva, ve které se zpravidla nachází webový server, na kterém běží prezentační vrstva aplikace. Do této vrstvy též můžeme umístit i webový aplikační firewall (Web Application Firewall, zkr. WAF), který by měl poskytovat ochranu před známými útoky zneužívajícím zranitelnosti umožňující XSS, SQL injection atd. Stejně tak se zde může nacházet sytém detekce průniku (Intrusion Detection System zkr. IDS), což je prvek detekující útoky na OS, framework a další aplikace jako je třeba Apache, JAVA apod. na základě signatur.
Hardening serveru
Na serveru by měla být nainstalována aktuální verze operačního systému a aplikací, a pokud dodavatel OS nebo aplikace uvolnil nějaké bezpečnostní záplaty, tak ty by měly být po řádném otestování též nasazeny. Na serveru by měly běžet s omezenými právy pouze nezbytně nutné služby a ty nepoužívané by měly být zastaveny, ideálně odinstalovány. Dále je nutné změnit defaultní hesla a oprávnění na adresáře, ve kterých se nachází webová aplikace. Na serveru by se též neměly nacházet žádné zdrojové kódy, ze kterých byla aplikace zkompilována. Tato doporučení je vhodné dodržet především u kritických aplikací běžících na serverech dostupných z internetu.
Šifrování
Pokud webová aplikace umožňuje svým uživatelům přístup k citlivým datům, měla by být komunikace mezi servery šifrována. To lze realizovat na síťové úrovni např. pomocí IPsec nebo na aplikační pomocí SSL. Tím je zajištěno, že i pro osobu, která se nachází ve stejném síťovém segmentu, zůstane obsah přenášených dat utajen. Nezapomínejte, že komunikace mezi klientem a serverem přes internet je sice šifrována pomocí SSL, ale někde v DMZ bývá zpravidla terminována a dále by pak probíhala nešifrovaně.
Autentizace
Servery, na kterých jednotlivé vrstvy běží, se musí vůči sobě nějak autentizovat. U nekritických aplikací je možné použít klasickou autentizaci jménem a heslem, u kritických aplikací však doporučuji provádět oboustrannou autentizaci (Mutual Authentication, zkr. MA). Na každém serveru je vygenerován pár klíčů. Privátní klíč je uložen na serveru v adresáři s řízeným přístupem a veřejný klíč, ke kterému je vydán certifikát podepsaný důvěryhodnou certifikační autoritou, je nahrán na druhý server. Je třeba zajistit, aby privátní klíč nemohl být jednoduše zkopírován, v opačném případě by mohlo dojít ke zcizení identity.
Validace dat
Každá vrstva by si měla kontrolovat data, která na svém vstupu přijímá, protože pokud toto nebude provádět, a dojde ke kompromitaci sousední vrstvy, mohou jí být podvržena jakákoliv data. Z tohoto důvodu nestačí jen kontrolovat, zda jsou data podepsána, ale i jaká je jejich velikost, struktura a obsah. Pokus o zpracování příliš velkého nebo jinak strukturovaného souboru, podstrčeného útočníkem, by mohl vést i k odepření služby ostatním uživatelům (Denial of Services, zkr. DoS).
Administrace
Správa samotné aplikace i jednotlivých serverů, které se nacházejí v různých zónách, by měla být umožněna pouze z vybraných administrátorských stanic. Zvažte, zda přístup na tyto servery a do administračního rozhraní aplikace neumožnit jen z vybraného IP adresního rozsahu poté, co se uživatel dvoufaktorově autentizuje, a zda nepřejmenovat defaultní stránku, na které je administrace dostupná, a neodstranit z nabídky volbu „administrace“.
Auditing
Na všech serverech by mělo být zapnuto auditní protokolování. Zaznamenávány by měly být minimálně tyto události: shození a nahození auditu, změna bezpečnostních parametrů, správa účtů a skupin, změna nastavení práv na objektech, úspěšná a neúspěšná autentizace, spouštění procesů.
Monitoring
Vybrané události by měly být zasílány do nějakého SIEM nástroje nebo alespoň pravidelně vyhodnocovány, aby byly nežádoucí aktivity v systému včas odhaleny.
Oddělení pravomocí
Rozdělte odpovědnosti za jednotlivé vrstvy, OS, aplikaci, DB a infrastrukturu mezi několik správců, tím bude zajištěno, že nikdo nebude mít pod kontrolou celou aplikaci a datový tok od začátku až dokonce.
Závěr: Rozdělení aplikace do několika vrstev a jejich umístění v oddělených DMZ, spolu s nastavením pravidel komunikace, provedením hardeningu, zavedením autentizace, šifrování, validace, auditingu, monitoringu a oddělení pravomocí, by mělo učinit útok obtížným a zároveň snáze detekovatelným.
Štítky: n-tier
K článku “Bezpečnost webových aplikací a vícevrstvá architektura” se zde nenachází žádný komentář - buďte první.
Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.
