← Referenční architektury / reference-architecture / design-guides

Zjednodušené nasazení WAF napříč zónami a aplikacemi

Bezpečnostní perimetry jsou dnes méně jasně vymezené než tradiční nasazení typu „hrad a příkop“, které bylo v minulosti oblíbené. V rámci pevně daného perimetru bylo poměrně snadné zabezpečit více aplikací pomocí jediného nasazení Web Application Firewall (WAF) uvnitř datacentra. Dnes už tento přístup neposkytuje dostatečnou flexibilitu, protože aplikace a služby přesahují hranice tradičního datacentra. Existuje několik dobrých důvodů, proč sítě a služby konfigurovat hybridním způsobem a přecházet na SaaS platformy, a proto se vyplatí přístup k WAF pro tento scénář aktualizovat.

Cloudová řešení WAF dokážou zvládnout rozšiřování perimetru díky flexibilnímu modelu nasazení, který pokrývá aplikace a služby nasazené on-premises, v cloudových prostředích IaaS a PaaS i v hybridních prostředích.

Nesprávná implementace cloudového WAF zároveň může vést k fragmentaci a duplicitě bezpečnostních zásad, což zvyšuje nároky jak na údržbu, tak na monitorování. Kromě zjevného ekonomického dopadu takové neefektivity může nižší efektivita zhoršit i samotný bezpečnostní stav. To může v konečném důsledku vést k bezpečnostním incidentům různé závažnosti podle konkrétního scénáře.

Tento průvodce návrhem je určen bezpečnostním a síťovým administrátorům či architektům, kteří chtějí zavést flexibilní cloudovou konfiguraci zabezpečení WAF. Tato konfigurace může pokrývat více aplikací, domén a služeb nasazených v hybridním prostředí.

Cloudflare nabízí komplexní řešení Application Security & Performance, která zahrnují vysoce konfigurovatelný cloudový Web Application Firewall (WAF).

V tomto průvodci se dozvíte:

• Jak nasadit Cloudflare WAF a zahrnout běžná pravidla.
• Jak snadno zavést společná nastavení napříč více aplikacemi.
• Jak podle potřeby nasadit výjimky a specifická nastavení.
• Jaké jsou osvědčené postupy při nasazování Cloudflare WAF.

Většina zákazníků Cloudflare využívá v rámci jednoho Account (nebo Enterprise Organization) více Cloudflare Zones. Každá Cloudflare Zone je obvykle namapována na doménu druhé úrovně (například example.com), a všechny její subdomény jsou poté zpracovávány v rámci dané zóny Cloudflare (web1.example.com, web2.example.com atd.).

V tomto nastavení funguje Cloudflare jako reverzní proxy založená na DNS. Každý plně kvalifikovaný název domény (FQDN) je nakonfigurován ve své zóně Cloudflare a odkazuje na origin server zákazníka. Cloudflare přitom nijak nerozlišuje, čím nebo kde tento origin server je. Může jít o nasazení on-premises, o virtuální stroj běžící v cloudu, nebo o SaaS službu poskytovanou třetí stranou.

Často více FQDN směřuje na stejnou sdílenou webovou infrastrukturu, ke které se přistupuje například pomocí IP adresy nebo jiného FQDN. Některé FQDN mohou také směřovat na vyhrazenou originovou infrastrukturu nebo na externí SaaS endpoint.

V mnoha případech zákazníci Cloudflare nakonec spravují velké množství zón Cloudflare (například example.com,example.org, myappexample.com a tak dále) v rámci jediného účtu Cloudflare a mnoho FQDN v rámci každé zóny. Mnoho FQDN napříč více zónami přitom často směřuje na sdílenou webovou infrastrukturu v pozadí.

Můžete se například ocitnout v následujícím (nebo podobném) scénáři:

• Většina vašich webových aplikací běží na nově nasazeném interním systému pro správu obsahu (CMS)
• Máte také několik starších webových aplikací běžících na vlastních technologických zásobnících.
• Nakonec můžete mít pro několik aplikací vyhrazenou infrastrukturu spravovanou partnerem.

Příklad tohoto scénáře je znázorněn na diagramu níže:

Z hlediska konfigurace WAF vyvolává tento scénář zajímavé požadavky:

• Vytvoření snadno nasaditelné konfigurace, která před většinu aplikací nasadí standardní konfiguraci pravidel WAF.
• Možnost jemně doladit, která pravidla se nasadí před starší aplikace, jež mohou být náchylnější k falešně pozitivním výsledkům než ostatní.
• Zahrnutí konfigurace typu „catch-all“, která zajistí, že se výchozí nastavení WAF Cloudflare vždy použije na veškerý webový provoz, jenž nespadá do výše uvedených scénářů.
• Minimalizace času potřebného k nastavení a průběžné údržby v případě, že se aplikace postupem času přidávají a odebírají.

V tomto Design Guide se podíváme na to, jak funguje Cloudflare WAF a jaké nástroje jsou k dispozici pro splnění všech výše uvedených architektonických požadavků.

WAF Cloudflare funguje na úrovni zóny i účtu. Existují různé Fáze WAF (http_request_firewall_custom, http_ratelimit a http_request_firewall_managed) které odpovídají Custom Rules, Rate Limiting Rules a Managed Rules. Tyto fáze existují jak na úrovni účtu, tak na úrovni zóny. Další informace najdete další informace najdete v následující dokumentaci. Je důležité si uvědomit, že sady pravidel na úrovni Account se vyhodnocují dříve než sady pravidel na úrovni zóny.

Pro účely tohoto průvodce budeme vycházet z výše uvedeného ukázkového scénáře a požadavků na WAF. Máte jeden Cloudflare Account (nebo Enterprise Organization), ve kterém máte onboardované dvě domény druhé úrovně.

Předpokládejme, že za šesti FQDN ve dvou doménách se skrývá šest aplikací. Pro tyto aplikace chcete uplatnit základní úroveň zabezpečení WAF. U dvou z těchto šesti aplikací je ale potřeba zvláštní přístup:

• Jeden je implementován na starším aplikačním serveru a je náchylný k falešně pozitivním výsledkům.
• Další je realizována třetí stranou na její vlastní infrastruktuře.

Tento scénář znázorňuje následující obrázek:

Použijeme Cloudflare Managed Ruleset jako příklad, přičemž tento postup lze použít i pro další pravidla Cloudflare Managed Rules, Rate Limiting Rules a Custom Rules.

• Pro web1.example.com, web2.example.com, web3.example.com a web5.example.org: chcete použít výchozí sadu WAF Managed Ruleset, kterou už Cloudflare vyladil.
• Pro special4.example.com: chcete použít jinou podmnožinu výchozí sady Managed Ruleset, protože jste již identifikovali několik pravidel, která u starší aplikace způsobují falešně pozitivní výsledky.
• Pro special6.example.org: chcete použít Managed Ruleset v režimu protokolování, protože se jedná o nově zavedenou aplikaci od třetí strany a potřebujete začít hodnotit, jak ji chránit.

Poté můžete zvolit následující postup:

• Nasaďte jednu instanci Cloudflare Managed Ruleset na úrovni Account. Tím se implementuje společná podmnožina pravidel pro všechny čtyři FQDN, které ji vyžadují. Toto řešení se snáze nastavuje a udržuje než čtyřnásobná replikace stejné konfigurace na úrovni Zone.
• Pro special4.example.com a special6.example.org, nasadíte dvě další instance Managed Ruleset s konkrétními úpravami, které vyžadují aplikace stojící za danými FQDN.

V praxi použití Managed rulesets WAF na úrovni účtu, můžete nasadit tři instance našeho Managed Ruleset. Každá instance bude mít vlastní Custom Filter Expression, které ověří, že hostname požadavku HTTPS patří mezi FQDN uvedené v seznamu:

• Pro první seznam (web1.example.com, web2.example.com, web3.example.com a web5.example.org), použijete spravovanou sadu pravidel Cloudflare Managed Ruleset v jejím Default konfigurace.
• Pro special4.example.com, stejná sada pravidel bude nasazena v Default režimu, ale je třeba vypnout konkrétní pravidla, která způsobují falešně pozitivní výsledky. Toho lze dosáhnout pomocí Rule Overrides, a to pomocí dashboardu nebo API. Reálné příklady najdete zde.
• Pro special6.example.org, zopakujete nastavení provedené pro první seznam, tentokrát však instanci Managed Ruleset upravíte tak, aby fungovala v Log režimu namísto Default.

Celou konfiguraci znázorňuje následující diagram:

Toto nastavení poskytne tři instance Managed Ruleset, každou kalibrovanou pro danou skupinu aplikací.

Pokud budete v budoucnu potřebovat chránit další aplikace, stačí přidat FQDN nové aplikace do filtrovacího výrazu. Většinou se aplikace přidávají do standardní instance sady pravidel, která používá doporučenou konfiguraci Cloudflare. Další běžnou strategií je přidávat nové aplikace do Log instanci režimu, aby bylo možné ji monitorovat a případně přejít na Default sadu pravidel režimu nebo v případě potřeby na konkrétnější variantu.

Sady pravidel (rulesets), a zejména Managed Ruleset, jsou už ze strany Cloudflare jemně vyladěny tak, aby se předešlo falešně pozitivním výsledkům. U většiny aplikací je lze nasadit prakticky bez úprav nebo jen s minimálními zásahy. Zákazníci proto ve většině případů pracují přímo s výchozí konfigurací sad pravidel a přizpůsobují ji jen tehdy, když je to potřeba.

Pokud toto odpovídá vaší situaci, můžete výše uvedené nastavení zjednodušit následujícím způsobem pomocí Výjimky:

• Nejprve můžete zjistit, které aplikace (FQDN) vyžadují speciální zacházení, nasazením sady pravidel v Log režimu. Pokud například po testování zjistíte, že special1.example.com vyžaduje vypnutí malé sady spravovaných pravidel a special2.example.org zakázáním podobné, ale odlišné sady pravidel.
• Nasaďte dvě spravované Exceptions s filtrem odpovídajícím jednotlivým FQDN, které pak tato pravidla z Managed Ruleset přeskočí.
• Nakonec nasaďte výchozí (Default) verzi Managed Ruleset, která bude odpovídat všemu ostatnímu, a spusťte doporučená nastavení Cloudflare pro Managed Ruleset.

Tento přístup může být jednodušší, pokud existuje jen málo výjimek z běžného stavu a počáteční kalibrace potvrdí, že jemné doladění, které již Cloudflare provedl za účelem minimalizace falešně pozitivních výsledků, je pro vaši situaci vhodné.

Cloudflare umožňuje vytvářet seznamy hostname. V takovém případě lze Filter expression upravit tak, aby odkazoval na tyto proměnné seznamu.

Seznamy pak můžete přímo upravovat a znovu je používat napříč více rulesety. Stejný seznam můžete použít například pro Cloudflare Managed Rules i pro OWASP Ruleset a Rate Limiting. Vaše filtry bude přímo odkazovat na seznamy, což znamená přehlednější a snáze udržovatelnou konfiguraci.

Při používání seznamů je také mnohem snazší zavést „záchytné pravidlo“, které se vyhodnocuje jako poslední. Tím lze zavést například Default Cloudflare Managed Ruleset, pokud host v požadavku HTTPS není zahrnut v žádném z vašich seznamů. Tím se zajistí, že se vždy uplatní výchozí konfigurace WAF Managed Rules, pro případ, že by některé z vašich aplikací nebyly omylem přidány do seznamů.

Konfiguraci WAF lze spravovat prostřednictvím volání API a Terraform ↗. To se hodí zejména tehdy, když chcete tento přístup rozšířit na mnohem více zón a FQDN a vyhnout se opakovaným ručním úkonům v Dashboardu.

Můžete si například vytvořit výchozí konfigurační soubor Terraform pro definici Rulesets a Lists, který pak podle potřeby udržujete a aplikujete bez nutnosti provádět změny v Cloudflare Dashboard.

Pokud je to možné, Cloudflare doporučuje udržovat konfiguraci na úrovni účtu (Account), zejména pokud bude zóna Cloudflare obsahovat víc záznamů DNS, z nichž každý vyžaduje vlastní konfiguraci.

U WAF na úrovni zóny můžete nasadit jen jednu instanci každé sady pravidel (Managed Rules, OWASP Rules atd.), takže řešení speciálních scénářů na této úrovni může být složitější, nebo dokonce nemožné.

Výše popsaný přístup pro Managed Rules lze použít i na Custom Rulesets a Rate Limiting, čímž se tato flexibilita rozšiřuje na všechny bezpečnostní nástroje WAF, které máte k dispozici.

Pokud vaše konfigurace není specifická pro jednu zónu, Cloudflare doporučuje ji implementovat na úrovni Account.

Další informace najdete v následujících zdrojích:

• Vytvořte Rate Limiting Rule na úrovni Account
• Vytvořte Custom Rulesets na úrovni Account

Závěrem tento návrhový průvodce ukazuje, jak lze implementovat flexibilní konfigurace WAF pokrývající více aplikací a domén. Popsaný přístup snižuje úsilí potřebné k nasazení, údržbě a aktualizaci bezpečnostní konfigurace WAF.