Tento článek je třetím ze série článků „Jak převzít kontrolu nad svou síťovou infrastrukturou“. Obsah všech článků v seriálu a odkazy naleznete .
O úplném odstranění bezpečnostních rizik nemá smysl mluvit. V zásadě je nemůžeme snížit na nulu. Musíme také chápat, že jak se snažíme o to, aby byla síť stále bezpečnější, naše řešení jsou stále dražší a dražší. Musíte najít kompromis mezi cenou, složitostí a zabezpečením, který má pro vaši síť smysl.
Návrh zabezpečení je samozřejmě organicky integrován do celkové architektury a použitá bezpečnostní řešení ovlivňují škálovatelnost, spolehlivost, ovladatelnost, ... síťové infrastruktury, což je také nutné vzít v úvahu.
Dovolte mi však připomenout, že nyní nehovoříme o vytvoření sítě. Podle našeho již jsme zvolili design, vybrali zařízení, vytvořili infrastrukturu a v této fázi bychom pokud možno měli „žít“ a hledat řešení v kontextu dříve zvoleného přístupu.
Naším úkolem je nyní identifikovat rizika spojená se zabezpečením na úrovni sítě a snížit je na rozumnou úroveň.
Audit zabezpečení sítě
Pokud vaše organizace zavedla procesy ISO 27k, měly by bezpečnostní audity a změny sítě hladce zapadat do celkových procesů v rámci tohoto přístupu. Ale tyto standardy stále nejsou o konkrétních řešeních, ani o konfiguraci, ani o designu... Neexistují žádné jasné rady, žádné standardy, které by podrobně diktovaly, jak by vaše síť měla být, v tom je složitost a krása tohoto úkolu.
Zdůraznil bych několik možných auditů zabezpečení sítě:
- audit konfigurace zařízení (kalení)
- audit bezpečnostního designu
- přístupový audit
- procesní audit
Audit konfigurace zařízení (kalení)
Zdá se, že ve většině případů je to nejlepší výchozí bod pro audit a zlepšení zabezpečení vaší sítě. IMHO je to dobrá ukázka Paretova zákona (20% úsilí produkuje 80% výsledku a zbývajících 80% úsilí produkuje pouze 20% výsledku).
Pointa je, že obvykle máme doporučení od dodavatelů týkající se „nejlepších postupů“ pro bezpečnost při konfiguraci zařízení. Tomu se říká „tvrdnutí“.
Na základě těchto doporučení můžete také často najít dotazník (nebo si jej sami vytvořit), který vám pomůže určit, jak dobře konfigurace vašeho zařízení vyhovuje těmto „nejlepším postupům“, a v souladu s výsledkem provést změny ve vaší síti. . To vám umožní výrazně snížit bezpečnostní rizika poměrně snadno, prakticky bez nákladů.
Několik příkladů pro některé operační systémy Cisco.
Na základě těchto dokumentů lze vytvořit seznam požadavků na konfiguraci pro každý typ zařízení. Například pro Cisco N7K VDC mohou tyto požadavky vypadat .
Tímto způsobem lze vytvářet konfigurační soubory pro různé typy aktivních zařízení ve vaší síťové infrastruktuře. Dále, ručně nebo pomocí automatizace, můžete tyto konfigurační soubory „nahrát“. Jak tento proces automatizovat, bude podrobně probráno v jiné sérii článků o orchestraci a automatizaci.
Audit bezpečnostního designu
Podniková síť obvykle obsahuje následující segmenty v té či oné podobě:
- DC (Veřejné služby DMZ a intranetové datové centrum)
- Přístup k internetu
- Vzdálený přístup VPN
- Okraj WAN
- Větev
- kampus (kancelář)
- Jádro
Tituly převzaty z model, ale není samozřejmě nutné se přesně k těmto jménům a tomuto modelu vázat. Přesto chci mluvit o podstatě a nezabřednout do formalit.
Pro každý z těchto segmentů se budou požadavky na zabezpečení, rizika a podle toho i řešení lišit.
Podívejme se na každý z nich zvlášť na problémy, se kterými se můžete setkat z hlediska návrhu zabezpečení. Samozřejmě znovu opakuji, že tento článek v žádném případě nepředstírá, že je úplný, čehož není snadné (ne-li nemožné) dosáhnout v tomto skutečně hlubokém a mnohostranném tématu, ale odráží mou osobní zkušenost.
Dokonalé řešení neexistuje (alespoň zatím). Vždy jde o kompromis. Je však důležité, aby rozhodnutí použít ten či onen přístup bylo učiněno vědomě, s pochopením jeho pro i proti.
Data Center
Z bezpečnostního hlediska nejkritičtější segment.
A jak už to tak bývá, ani zde neexistuje univerzální řešení. Vše velmi závisí na požadavcích sítě.
Je firewall nutný nebo ne?
Zdálo by se, že odpověď je zřejmá, ale vše není tak jasné, jak by se mohlo zdát. A nejen váš výběr lze ovlivnit cena.
Příklad 1. Zpoždění.
Pokud je mezi některými segmenty sítě zásadním požadavkem nízká latence, což je například pravda v případě výměny, pak mezi těmito segmenty nebudeme moci používat firewally. Je těžké najít studie o latenci ve firewallech, ale jen málo modelů přepínačů dokáže poskytnout latenci menší nebo v řádu 1 mksec, takže si myslím, že pokud jsou pro vás důležité mikrosekundy, firewally pro vás nejsou.
Příklad 2. Výkon.
Propustnost špičkových L3 přepínačů je obvykle o řád vyšší než propustnost nejvýkonnějších firewallů. Proto v případě vysoké intenzity provozu budete také s největší pravděpodobností muset tomuto provozu povolit obcházení firewallů.
Příklad 3. Spolehlivost.
Firewally, zejména moderní NGFW (Next-Generation FW) jsou složitá zařízení. Jsou mnohem složitější než přepínače L3/L2. Poskytují velké množství služeb a možností konfigurace, a tak není divu, že jejich spolehlivost je mnohem nižší. Pokud je pro síť kritická kontinuita služeb, možná si budete muset vybrat, co povede k lepší dostupnosti – zabezpečení pomocí firewallu nebo jednoduchost sítě postavené na přepínačích (nebo různých typech struktur) využívajících běžné ACL.
V případě výše uvedených příkladů budete muset s největší pravděpodobností (jako obvykle) najít kompromis. Podívejte se na následující řešení:
- pokud se rozhodnete nepoužívat firewally uvnitř datového centra, pak musíte přemýšlet o tom, jak co nejvíce omezit přístup po obvodu. Můžete například otevřít pouze nezbytné porty z internetu (pro klientský provoz) a administrativní přístup do datového centra pouze z hostitelů skoků. U skokových hostitelů proveďte všechny potřebné kontroly (autentizace/autorizace, antivirus, protokolování, ...)
- můžete použít logické rozdělení sítě datového centra na segmenty, podobně jako schéma popsané v PSEFABRIC . V tomto případě musí být směrování nakonfigurováno tak, aby provoz citlivý na zpoždění nebo vysoce intenzivní provoz procházel „v rámci“ jednoho segmentu (v případě p002, VRF) a neprocházel firewallem. Provoz mezi různými segmenty bude i nadále procházet bránou firewall. Můžete také použít únik trasy mezi VRF, abyste se vyhnuli přesměrování provozu přes firewall
- Firewall můžete také použít v transparentním režimu a pouze pro ty VLAN, kde tyto faktory (latence/výkon) nejsou významné. Musíte si ale pečlivě prostudovat omezení spojená s používáním tohoto modu u každého dodavatele
- možná budete chtít zvážit použití architektury řetězce služeb. To umožní, aby přes firewall procházel pouze nezbytný provoz. Teoreticky to vypadá hezky, ale nikdy jsem toto řešení ve výrobě neviděl. Zhruba před 5 lety jsme testovali servisní řetězec pro Cisco ACI/Juniper SRX/F3 LTM, ale v té době se nám toto řešení zdálo „hrubé“.
Úroveň ochrany
Nyní si musíte odpovědět na otázku, jaké nástroje chcete používat k filtrování provozu. Zde jsou některé z funkcí, které jsou obvykle přítomny v NGFW (např. ):
- stavový firewall (výchozí)
- aplikační firewall
- prevence hrozeb (antivirus, anti-spyware a zranitelnost)
- filtrování URL
- filtrování dat (filtrování obsahu)
- blokování souborů (blokování typů souborů)
- dos ochranu
A také není vše jasné. Zdálo by se, že čím vyšší úroveň ochrany, tím lépe. Ale i to je potřeba zvážit
- Čím více z výše uvedených funkcí firewallu použijete, tím bude samozřejmě dražší (licence, doplňkové moduly)
- použití některých algoritmů může výrazně snížit propustnost firewallu a také zvýšit zpoždění, viz např
- jako každé komplexní řešení může použití komplexních metod ochrany snížit spolehlivost vašeho řešení, například při použití aplikačního firewallu jsem se setkal s blokováním některých zcela standardně fungujících aplikací (dns, smb)
Jako vždy musíte najít nejlepší řešení pro vaši síť.
Není možné definitivně odpovědět na otázku, jaké ochranné funkce mohou být vyžadovány. Za prvé, protože to samozřejmě závisí na datech, která přenášíte nebo ukládáte a snažíte se chránit. Za druhé, ve skutečnosti je výběr bezpečnostních nástrojů často otázkou důvěry a důvěry v dodavatele. Neznáte algoritmy, nevíte, jak jsou účinné, a nemůžete je plně otestovat.
V kritických segmentech proto může být dobrým řešením využití nabídek od různých společností. Můžete například povolit antivir na firewallu, ale také použít antivirovou ochranu (od jiného výrobce) lokálně na hostitelích.
Segmentace
Hovoříme o logické segmentaci sítě datových center. Například rozdělení do VLAN a podsítí je také logická segmentace, ale nebudeme ji uvažovat kvůli její samozřejmosti. Zajímavá segmentace zohledňující takové entity, jako jsou bezpečnostní zóny FW, VRF (a jejich analogy ve vztahu k různým prodejcům), logická zařízení (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...
Příklad takové logické segmentace a v současnosti žádaný návrh datového centra je uveden v .
Po definování logických částí vaší sítě můžete popsat, jak se provoz pohybuje mezi různými segmenty, na kterých zařízeních se bude provádět filtrování a jakými prostředky.
Pokud vaše síť nemá jasný logický oddíl a pravidla pro aplikaci bezpečnostních politik pro různé datové toky nejsou formalizována, znamená to, že když otevřete ten či onen přístup, jste nuceni tento problém vyřešit a s vysokou pravděpodobností vyřeší to pokaždé jinak.
Často je segmentace založena pouze na bezpečnostních zónách FW. Pak musíte odpovědět na následující otázky:
- jaké bezpečnostní zóny potřebujete
- jakou úroveň ochrany chcete použít pro každou z těchto zón
- bude ve výchozím nastavení povolen provoz uvnitř zóny?
- pokud ne, jaké zásady filtrování provozu budou použity v každé zóně
- jaké zásady filtrování provozu budou použity pro každou dvojici zón (zdroj/cíl)
TCAM
Častým problémem je nedostatečná TCAM (Ternary Content Addressable Memory), a to jak pro směrování, tak pro přístupy. IMHO je to jedna z nejdůležitějších otázek při výběru vybavení, takže je třeba se této záležitosti věnovat s patřičnou mírou péče.
Příklad 1. Tabulka přesměrování TCAM.
Pojďme se podívat na firewall
Vidíme, že velikost tabulky předávání IPv4* = 32 kB
Navíc je tento počet tras společný pro všechny VSYS.Předpokládejme, že se podle vašeho návrhu rozhodnete použít 4 VSYS.
Každý z těchto VSYS je připojen přes BGP ke dvěma MPLS PE v cloudu, které používáte jako BB. 4 VSYS si tedy vyměňují všechny specifické cesty mezi sebou a mají přesměrovací tabulku s přibližně stejnými sadami cest (ale různými NH). Protože každý VSYS má 2 BGP relace (se stejným nastavením), pak každá cesta přijatá přes MPLS má 2 NH a podle toho 2 FIB záznamy v tabulce předávání. Pokud předpokládáme, že se jedná o jediný firewall v datovém centru a ten musí vědět o všech trasách, pak to bude znamenat, že celkový počet tras v našem datovém centru nemůže být větší než 32K/(4 * 2) = 4K.Nyní, pokud předpokládáme, že máme 2 datová centra (se stejným designem) a chceme použít VLAN „roztažené“ mezi datovými centry (například pro vMotion), pak k vyřešení problému se směrováním musíme použít hostitelské trasy. . To ale znamená, že pro 2 datová centra nebudeme mít více než 4096 možných hostitelů a to samozřejmě nemusí stačit.
Příklad 2. ACL TCAM.
Pokud plánujete filtrovat provoz na přepínačích L3 (nebo jiných řešeních, která používají přepínače L3, například Cisco ACI), měli byste při výběru zařízení věnovat pozornost TCAM ACL.
Předpokládejme, že chcete řídit přístup k SVI rozhraním Cisco Catalyst 4500. Poté, jak je vidět z , k řízení odchozího (i příchozího) provozu na rozhraních můžete použít pouze 4096 linek TCAM. Což vám při použití TCAM3 dá asi 4000 tisíc ACE (řádky ACL).
Pokud se potýkáte s problémem nedostatečného TCAM, pak samozřejmě musíte nejprve zvážit možnost optimalizace. Takže v případě problému s velikostí tabulky přesměrování je třeba zvážit možnost agregace tras. V případě problému s velikostí TCAM pro přístupy auditujte přístupy, odstraňte zastaralé a překrývající se záznamy, případně revidujte postup otevírání přístupů (podrobně bude probráno v kapitole auditování přístupů).
Vysoká dostupnost
Otázka zní: mám použít HA pro firewally nebo nainstalovat dva nezávislé boxy „paralelně“ a pokud jeden z nich selže, směrovat provoz přes druhý?
Zdá se, že odpověď je zřejmá - použijte HA. Důvodem, proč tato otázka stále vyvstává, je, že bohužel teoretická a reklamní 99 a několik desetinných procent přístupnosti v praxi zdaleka nejsou tak růžové. HA je logicky docela složitá věc a na různých zařízeních a u různých prodejců (nebyly výjimky) jsme zachytili problémy a chyby a zastavovali se.
Pokud používáte HA, budete mít možnost vypínat jednotlivé uzly, přepínat mezi nimi bez zastavení služby, což je důležité například při upgradech, ale zároveň máte zdaleka nulovou pravděpodobnost, že oba uzly se současně porouchá a také, že další upgrade nepůjde tak hladce, jak dodavatel slibuje (tomuto problému se lze vyhnout, pokud máte možnost vyzkoušet upgrade na laboratorním vybavení).
Pokud nepoužíváte HA, tak z pohledu dvojitého selhání jsou vaše rizika mnohem nižší (jelikož máte 2 nezávislé firewally), ale jelikož... relace nejsou synchronizovány, pak při každém přepnutí mezi těmito firewally ztratíte provoz. Můžete samozřejmě použít bezstavový firewall, ale pak se smysl použití firewallu do značné míry ztrácí.
Pokud jste tedy v důsledku auditu objevili osamělé firewally a uvažujete o zvýšení spolehlivosti vaší sítě, pak je HA samozřejmě jedním z doporučených řešení, ale měli byste vzít v úvahu také nevýhody s tímto přístupem a možná konkrétně pro vaši síť by bylo vhodnější jiné řešení.
Ovladatelnost
HA je v principu i o ovladatelnosti. Místo toho, abyste konfigurovali 2 boxy samostatně a řešili problém synchronizace konfigurací, spravujete je podobně, jako byste měli jedno zařízení.
Ale možná máte mnoho datových center a mnoho firewallů, pak tato otázka vyvstává na nové úrovni. A otázka není jen o konfiguraci, ale také o
- záložní konfigurace
- aktualizace
- upgrady
- sledování
- protokolování
A to vše mohou vyřešit centralizované systémy řízení.
Pokud tedy například používáte firewally Palo Alto, pak je takové řešení.
Je třeba pokračovat.
Zdroj: www.habr.com