Ta članek je tretji v seriji člankov z naslovom »Kako prevzeti nadzor nad svojo omrežno infrastrukturo«. Vsebino vseh člankov v seriji in povezave najdete tukaj.

Ni smiselno govoriti o popolni odpravi varnostnih tveganj. Ne moremo jih zmanjšati na nič. Razumeti moramo tudi, da s prizadevanji za vedno večjo varnost omrežja postajajo naše rešitve vse dražje. Bistveno je najti razumen kompromis med stroški, kompleksnostjo in varnostjo vašega omrežja.

Seveda je varnostna zasnova organsko vključena v celotno arhitekturo, uporabljene varnostne rešitve pa vplivajo na skalabilnost, zanesljivost, upravljivost, ... omrežne infrastrukture, kar je treba prav tako upoštevati.

Naj vas spomnim, da zdaj ne govorimo o ustvarjanju omrežja. V skladu z našim začetni pogoji Izbrali smo že zasnovo, opremo in ustvarili infrastrukturo, na tej stopnji pa bi morali, če je le mogoče, »živeti« in najti rešitve v kontekstu prej izbranega pristopa.

Naša naloga je zdaj prepoznati tveganja, povezana z varnostjo na ravni omrežja, in jih zmanjšati na razumno raven.

Revizija omrežne varnosti

Če je vaša organizacija uvedla procese ISO 27k, bi morali biti varnostni pregledi in spremembe omrežja brezhibno vključeni v celotne procese v okviru tega pristopa. Vendar pa ti standardi ne govorijo o specifičnih rešitvah, konfiguraciji ali zasnovi ... Ni dokončnih priporočil, ni standardov, ki bi podrobno določali, kako naj bi vaše omrežje izgledalo, in to je lepota in kompleksnost te naloge.

Izpostavil bi nekaj možnih pregledov omrežne varnosti:

revizija (utrjevanje) konfiguracije strojne opreme
revizija varnostne zasnove
revizija dostopa
revizija procesov

Revizija konfiguracije opreme (kaljenje)

V večini primerov se zdi, da je to najboljše izhodišče za revizijo in izboljšanje varnosti omrežja. Po mojem mnenju je to dober primer Paretovega načela (20 % truda prinese 80 % rezultatov, preostalih 80 % truda pa le 20 % rezultatov).

Bistvo je, da imamo običajno priporočila prodajalcev glede "najboljših praks" za varnost pri konfiguriranju strojne opreme. Temu pravimo "utrjevanje".

Pogosto lahko najdete tudi vprašalnik (ali ustvarite svojega) na podlagi teh priporočil, ki vam bo pomagal ugotoviti, kako dobro je konfiguracija vaše opreme skladna s temi "najboljšimi praksami", in ustrezno spremeniti svoje omrežje. To vam bo omogočilo, da precej enostavno in praktično brez stroškov znatno zmanjšate varnostna tveganja.

Nekaj primerov za nekatere operacijske sisteme Cisco.
Okrepitev konfiguracije Cisco IOS
Okrepitev konfiguracije Cisco IOS-XR
Okrepitev konfiguracije Cisco NX-OS
Osnovni varnostni kontrolni seznam Cisco
Na podlagi teh dokumentov je mogoče ustvariti seznam konfiguracijskih zahtev za vsako vrsto opreme. Na primer, za Cisco N7K VDC bi lahko te zahteve izgledale takole: Tako.

Na ta način je mogoče ustvariti konfiguracijske datoteke za različne vrste aktivne opreme v vaši omrežni infrastrukturi. Te konfiguracijske datoteke lahko nato naložite ročno ali z avtomatizacijo. Avtomatizacija tega postopka bo podrobneje obravnavana v drugi seriji člankov o orkestraciji in avtomatizaciji.

Revizija varnostne zasnove

Običajno poslovno omrežje vsebuje naslednje segmente v takšni ali drugačni obliki:

DC (javne storitve DMZ in intranetni podatkovni center)
Dostop do interneta
VPN za oddaljeni dostop
rob WAN
Branch
Kampus (pisarna)
Core

Imena so vzeta iz Cisco VARNO modelov, seveda pa se ni treba držati teh imen ali tega modela posebej. Vseeno pa želim govoriti o bistvu in se ne utapljati v formalnostih.

Za vsak od teh segmentov se bodo varnostne zahteve, tveganja in s tem povezane rešitve razlikovale.

Oglejmo si vsakega od teh posebej in poiščimo morebitne izzive pri načrtovanju varnosti. Seveda bom ponovil, da ta članek nikakor ni izčrpen, saj je to v tej resnično poglobljeni in večplastni temi težko (če ne celo nemogoče), vendar odraža moje osebne izkušnje.

Popolne rešitve ni (vsaj zaenkrat). Vedno gre za kompromis. Vendar je pomembno, da se odločitev za uporabo enega ali drugega pristopa sprejme zavestno, z razumevanjem njegovih prednosti in slabosti.

Podatkovno središče

Z varnostnega vidika najbolj kritičen segment.
In kot ponavadi tudi tukaj ni univerzalne rešitve. Vse je močno odvisno od vaših omrežnih zahtev.

Je požarni zid potreben ali ne?

Odgovor se morda zdi očiten, vendar ni tako preprost, kot se morda zdi. Na vašo izbiro lahko vplivajo ne le Cena.

Primer 1. Zamude.
Če je nizka latenca kritična zahteva med določenimi omrežnimi segmenti, kot je to na primer v primeru centrale, potem med temi segmenti ne bomo mogli uporabljati požarnih zidov. Raziskave o latenci požarnega zidu je težko najti, vendar le malo modelov stikal lahko zagotovi latenco pod ali v vrstnem redu 1 mikrosekunde, zato menim, da če so vam mikrosekunde pomembne, požarni zidovi niso za vas.

Primer 2. Zmogljivost.
Pretočnost vrhunskih stikal L3 je običajno za velikostni razred višja od pretočnosti najmočnejših požarnih zidov. Če imate torej promet z visoko intenzivnostjo, ga boste verjetno morali usmeriti mimo požarnih zidov.

Primer 3. Zanesljivost.
Požarni zidovi, zlasti sodobni NGFW (požarni zidovi naslednje generacije), so kompleksne naprave. So bistveno bolj kompleksni kot stikala 3. in 2. sloja. Ponujajo veliko število storitev in možnosti konfiguracije, zato ni presenetljivo, da je njihova zanesljivost bistveno manjša. Če je za omrežje ključnega pomena neprekinjenost storitev, boste morda morali izbirati med varnostjo požarnega zidu in preprostostjo omrežja, zgrajenega na stikalih (ali različnih tkaninah) z uporabo standardnih ACL-jev.

V zgornjih primerih boste verjetno (kot običajno) morali najti kompromis. Razmislite o naslednjih rešitvah:

Če se odločite, da v podatkovnem centru ne boste uporabljali požarnih zidov, morate razmisliti, kako čim bolj omejiti dostop vzdolž oboda. Na primer, lahko odprete le potrebna vrata iz interneta (za promet odjemalcev) in omejite administratorski dostop do podatkovnega centra le iz gostiteljskih strežnikov. Na gostiteljskih strežnikih izvedite vsa potrebna preverjanja (avtentikacija/avtorizacija, protivirusna zaščita, beleženje itd.).
Uporabite lahko logično particioniranje omrežja podatkovnega centra na segmente, podobno shemi, opisani v PSEFABRIC. primer p002Usmerjanje je treba konfigurirati tako, da promet, občutljiv na zakasnitev ali visoko intenzivnost, ostane znotraj enega samega segmenta (v primeru p002, VRF) in ne prehaja skozi požarni zid. Promet med različnimi segmenti bo še vedno prehajal skozi požarni zid. Puščanje poti med VRF-ji se lahko uporabi tudi za preprečevanje preusmeritve prometa skozi požarni zid.
Požarni zid lahko uporabljate tudi v transparentnem načinu in samo za tista VLAN-a, kjer ti dejavniki (latenca/zmogljivost) niso pomembni. Vendar pa morate natančno preučiti omejitve, povezane z uporabo tega načina, za vsakega ponudnika.
Morda bi lahko razmislili o uporabi arhitekture verige storitev. To bi vam omogočilo, da skozi požarni zid usmerite le potreben promet. V teoriji se sliši dobro, vendar te rešitve v produkciji še nisem videl. Verigo storitev smo testirali za Cisco ACI/Juniper SRX/F5 LTM pred približno tremi leti, vendar se nam je takrat zdela "surova" rešitev.

Stopnja zaščite

Zdaj se morate odločiti, katera orodja želite uporabiti za filtriranje prometa. Tukaj je nekaj funkcij, ki jih običajno najdemo v NGFW-jih (na primer tukaj):

požarni zid s spremljanjem stanja (privzeto)
požarni zid aplikacije
preprečevanje groženj (protivirusna, protivohunska programska oprema in ranljivost)
Filtriranje URL-jev
filtriranje podatkov (filtriranje vsebine)
blokiranje datotek (blokiranje vrst datotek)
zaščita pred DOS-om

In tudi ni vse tako jasno. Zdi se, da višja kot je raven zaščite, tem bolje. Vendar morate upoštevati tudi to

Več kot uporabljate zgoraj omenjene funkcije požarnega zidu, dražji bo (licence, dodatni moduli).
Uporaba nekaterih algoritmov lahko znatno zmanjša prepustnost požarnega zidu in poveča zakasnitev, glej na primer tukaj
Kot pri vsaki kompleksni rešitvi lahko tudi uporaba kompleksnih varnostnih metod zmanjša zanesljivost vaše rešitve. Na primer, pri uporabi požarnega zidu aplikacij sem naletel na blokiranje nekaterih precej standardnih aplikacij (DNS, SMB).

Kot vedno morate najti optimalno rešitev za svoje omrežje.

Nemogoče je dokončno odgovoriti na vprašanje, katere varnostne funkcije so morda potrebne. Prvič, odvisno je od podatkov, ki jih prenašate ali shranjujete in jih želite zaščititi. Drugič, izbira varnostnih orodij je pogosto stvar vere in zaupanja v prodajalca. Ne poznate algoritmov, ne veste, kako učinkoviti so, in jih ne morete v celoti preizkusiti.

Zato je na kritičnih območjih dobra rešitev lahko uporaba ponudb različnih podjetij. Na primer, lahko omogočite protivirusno programsko opremo na požarnem zidu, hkrati pa lokalno na svojih strežnikih uporabljate protivirusno zaščito (drugega prodajalca).

Segmentacija

Govorimo o logični segmentaciji omrežja podatkovnega centra. Na primer, delitev na VLAN-e in podomrežja je prav tako logična segmentacija, vendar je tukaj ne bomo obravnavali, ker je očitna. Zanimiva je segmentacija, ki upošteva entitete, kot so varnostne cone vdelane programske opreme, VRF-ji (in njihovi ustrezniki, specifični za prodajalce), logične naprave (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant itd.) in drugo.

Primer takšne logične segmentacije in trenutno iskane zasnove podatkovnega centra je podan v p002 projekta PSEFABRIC.

Ko definirate logične dele omrežja, lahko opišete, kako promet teče med različnimi segmenti, katere naprave bodo filtrirane in na kakšen način.

Če v vašem omrežju ni jasne logične delitve in pravila za uporabo varnostnih politik za različne tokove podatkov niso formalizirana, to pomeni, da ste pri odpiranju določenega dostopa prisiljeni rešiti to težavo in najverjetneje jo boste vsakič rešili drugače.

Pogosto segmentacija temelji izključno na varnostnih conah vdelane programske opreme. V tem primeru morate odgovoriti na naslednja vprašanja:

Katera varnostna območja potrebujete?
kakšno raven zaščite želite uporabiti za vsako od teh območij
Ali bo promet znotraj območja privzeto dovoljen?
Če ne, katere politike filtriranja prometa bodo uporabljene znotraj posameznega območja?
katere politike filtriranja prometa bodo uporabljene za vsak par con (vir/cilj)

TCAM

Premajhen TCAM (Ternary Content Addressable Memory) je pogosta težava, tako pri usmerjanju kot pri dostopu. Po mojem mnenju je to eden najpomembnejših dejavnikov pri izbiri strojne opreme, zato je treba k temu pristopiti previdno.

Primer 1. Tabela posredovanja TCAM.
Poglejmo si Palo Alto 7k požarni zid.
Vidimo, da je velikost tabele za posredovanje IPv4* = 32K
Poleg tega je to število poti skupno za vse VSYS-je.
Predpostavimo, da se v skladu z vašo zasnovo odločite za uporabo 4 VSYS.
Vsak od teh VSYS-ov je prek BGP-ja povezan z dvema PE MPLS vozliščema v oblaku, ki ju uporabljate kot BB. Tako si štirje VSYS-i izmenjujejo vse specifične poti med seboj in imajo tabelo posredovanja s približno enakim naborom poti (vendar različnimi NH-ji). Ker ima vsak VSYS dve seji BGP (z enakimi nastavitvami), ima vsaka pot, prejeta prek MPLS-a, dva NH-ja in s tem dva vnosa FIB v tabeli posredovanja. Ob predpostavki, da je to edini požarni zid v podatkovnem centru in mora poznati vse poti, to pomeni, da skupno število poti v našem podatkovnem centru ne sme presegati 32K/(4 * 2) = 4K.
Če predpostavimo, da imamo dva podatkovna centra (z identično zasnovo) in želimo uporabiti VLAN-e, ki so "raztegnjeni" med njima (na primer za vMotion), moramo za rešitev problema usmerjanja uporabiti poti, ki temeljijo na gostiteljih. To pa pomeni, da bomo imeli v dveh podatkovnih centrih največ 4096 možnih gostiteljev, kar seveda morda ne bo dovolj.

Primer 2. TCAM ACL.
Če nameravate filtrirati promet na stikalih L3 (ali drugih rešitvah, ki uporabljajo stikala L3, kot je Cisco ACI), bodite pri izbiri opreme pozorni na sezname ACL TCAM.
Predpostavimo, da želite nadzorovati dostop do SVI vmesnikov Cisco Catalyst 4500. Potem, kot je razvidno iz ta članekZa nadzor odhodnega (in dohodnega) prometa na vmesnikih lahko uporabite le 4096 linij TCAM. Z uporabo TCAM3 to pomeni približno 4000 ACE-jev (vrstic ACL).

Če naletite na nezadosten TCAM, je prvi korak seveda razmisliti o optimizaciji. Če je na primer težava velikost tabele za posredovanje, razmislite o združevanju poti. Če je težava velikost TCAM za dostope, razmislite o reviziji dostopov, odstranjevanju zastarelih in prekrivajočih se vnosov ter morebitni reviziji postopka avtorizacije dostopa (to bo podrobneje obravnavano v poglavju o reviziji dostopa).

Visoka dostopnost

Vprašanje je, ali uporabiti visoko razpoložljivost za požarne zidove ali namestiti dve neodvisni napravi "vzporedno" in v primeru okvare ene od njiju promet usmeriti skozi drugo?

Zdi se, da je odgovor očiten: uporaba visoke razpoložljivosti (HA). Razlog, zakaj se to vprašanje še vedno pojavlja, je ta, da se teoretične in oglaševane številke 99-odstotne razpoložljivosti in nekaj devetk za decimalno vejico v praksi žal izkažejo za veliko manj rožnate. HA je logično zapletena stvar in naleteli smo na težave, hrošče in izpade storitev na različni strojni opremi in pri različnih prodajalcih (brez izjem).

Uporaba visoke razpoložljivosti (HA) vam omogoča, da izklopite posamezna vozlišča in preklapljate med njimi, ne da bi pri tem prekinili storitev, kar je pomembno na primer med nadgradnjami. Vendar pa tvegate tudi, da obe vozlišči odpoveta hkrati, in možnost, da naslednja nadgradnja ne bo potekala tako gladko, kot obljublja prodajalec (tej težavi se je mogoče izogniti, če imate možnost preizkusiti nadgradnjo na laboratorijski opremi).

Če ne uporabljate visoke razpoložljivosti (HA), je tveganje za dvojno napako bistveno manjše (ker imate dva neodvisna požarna zidova), vendar ker seje niso sinhronizirane, boste vsakič, ko boste preklapljali med tema požarnima zidovoma, izgubili promet. Seveda lahko uporabite požarni zid brez stanja, vendar je potem smisel uporabe požarnega zidu v veliki meri izničen.

Če torej vaša revizija razkrije izolirane požarne zidove in razmišljate o povečanju zanesljivosti svojega omrežja, je visoka razpoložljivost zagotovo ena od priporočenih rešitev, vendar morate upoštevati tudi slabosti, povezane s tem pristopom, in morda bi bila za vaše omrežje primernejša druga rešitev.

Upravljivost

Visoka varnost (HA) je v osnovi namenjena upravljanju. Namesto da bi konfigurirali dve napravi ločeno in se ukvarjali s težavami s sinhronizacijo konfiguracije, ju upravljate podobno, kot če bi imeli eno samo napravo.

Morda pa imate več podatkovnih centrov in več požarnih zidov, potem to vprašanje dobi povsem novo raven. In ne gre le za vprašanje konfiguracije, ampak tudi za