Šis straipsnis yra trečiasis iš straipsnių serijos „Kaip valdyti tinklo infrastruktūrą“. Galima rasti visų serijos straipsnių turinį ir nuorodas čia.

Nėra prasmės kalbėti apie visišką saugumo rizikos pašalinimą. Iš esmės negalime jų sumažinti iki nulio. Taip pat turime suprasti, kad stengiantis, kad tinklas būtų vis saugesnis, mūsų sprendimai vis brangsta. Turite rasti kompromisą tarp kainos, sudėtingumo ir saugumo, kuris tinka jūsų tinklui.

Žinoma, saugos dizainas yra organiškai integruotas į bendrą architektūrą, o naudojami saugumo sprendimai turi įtakos tinklo infrastruktūros masteliui, patikimumui, valdomumui..., į ką taip pat reikia atsižvelgti.

Tačiau priminsiu, kad dabar nekalbame apie tinklo kūrimą. Pagal mūsų pradines sąlygas jau pasirinkome dizainą, išsirinkome įrangą, sukūrėme infrastruktūrą, o šiame etape, esant galimybei, reikėtų „gyventi“ ir ieškoti sprendimų anksčiau pasirinkto požiūrio kontekste.

Dabar mūsų užduotis yra nustatyti riziką, susijusią su saugumu tinklo lygmeniu, ir sumažinti jas iki pagrįsto lygio.

Tinklo saugumo auditas

Jei jūsų organizacija įdiegė ISO 27k procesus, saugos auditas ir tinklo pakeitimai turėtų sklandžiai įsilieti į bendrus procesus pagal šį metodą. Tačiau šie standartai vis tiek nėra susiję su konkrečiais sprendimais, ne apie konfigūraciją, ne apie dizainą... Nėra aiškių patarimų, nėra standartų, nurodančių, koks turi būti jūsų tinklas, tai yra šios užduoties sudėtingumas ir grožis.

Norėčiau pabrėžti keletą galimų tinklo saugumo auditų:

• įrangos konfigūracijos auditas (grūdinimas)
• apsaugos projektavimo auditas
• prieigos auditas
• proceso auditas

Įrangos konfigūracijos auditas (užkietėjimas)

Atrodo, kad daugeliu atvejų tai yra geriausias atskaitos taškas tikrinant ir gerinant tinklo saugumą. IMHO, tai yra geras Pareto dėsnio demonstravimas (20% pastangų sukuria 80% rezultato, o likę 80% pastangų sukuria tik 20% rezultato).

Esmė ta, kad konfigūruodami įrangą paprastai turime rekomendacijų iš pardavėjų, susijusių su „geriausia praktika“. Tai vadinama „sukietėjimu“.

Taip pat dažnai galite rasti klausimyną (arba susikurti jį patys), remdamiesi šiomis rekomendacijomis, kurie padės nustatyti, ar jūsų įrangos konfigūracija atitinka šias „geriausias praktikas“, ir, atsižvelgiant į rezultatus, atlikti pakeitimus tinkle. . Tai leis ženkliai sumažinti saugumo riziką gana lengvai, praktiškai be jokių išlaidų.

Keli kai kurių Cisco operacinių sistemų pavyzdžiai.

Cisco IOS konfigūracijos grūdinimas
Cisco IOS-XR konfigūracijos grūdinimas
Cisco NX-OS konfigūracijos grūdinimas
„Cisco Baseline“ saugos kontrolinis sąrašas

Remiantis šiais dokumentais, galima sudaryti kiekvieno tipo įrangos konfigūracijos reikalavimų sąrašą. Pavyzdžiui, Cisco N7K VDC šie reikalavimai gali atrodyti taip taip.

Tokiu būdu galima sukurti konfigūracijos failus įvairių tipų aktyviajai jūsų tinklo infrastruktūros įrangai. Tada rankiniu būdu arba automatizuodami galite „įkelti“ šiuos konfigūracijos failus. Kaip automatizuoti šį procesą, bus išsamiai aptarta kitoje straipsnių serijoje apie orkestravimą ir automatizavimą.

Apsaugos projektavimo auditas

Paprastai įmonės tinklą viena ar kita forma sudaro šie segmentai:

• DC (viešųjų paslaugų DMZ ir intraneto duomenų centras)
• Interneto ryšys
• Nuotolinės prieigos VPN
• WAN kraštas
• Filialas
• Universitetas (biuras)
• Esmė

Pavadinimai paimti iš Cisco SAFE modelio, tačiau, žinoma, nebūtina prisirišti būtent prie šių pavadinimų ir prie šio modelio. Visgi noriu kalbėti apie esmę ir nesivelti į formalumus.

Kiekvienam iš šių segmentų saugumo reikalavimai, rizika ir atitinkamai sprendimai bus skirtingi.

Pažvelkime į kiekvieną iš jų atskirai, kad sužinotumėte apie problemas, su kuriomis galite susidurti saugumo projektavimo požiūriu. Žinoma, dar kartą kartoju, kad šis straipsnis jokiu būdu nepretenduoja į baigtumą, o tai pasiekti šioje tikrai gilioje ir daugialypėje temoje nėra lengva (jei ne neįmanoma), tačiau jis atspindi mano asmeninę patirtį.

Idealaus sprendimo nėra (bent jau kol kas). Tai visada yra kompromisas. Tačiau svarbu, kad sprendimas naudoti vieną ar kitą metodą būtų priimtas sąmoningai, suvokiant ir jo pliusus, ir minusus.

Duomenų centras

Svarbiausias segmentas saugos požiūriu.
Ir, kaip įprasta, universalaus sprendimo čia taip pat nėra. Viskas labai priklauso nuo tinklo reikalavimų.

Ar ugniasienė reikalinga ar ne?

Atrodytų, atsakymas akivaizdus, ​​bet ne viskas taip aišku, kaip gali atrodyti. Ir jūsų pasirinkimas gali turėti įtakos ne tik kaina.

Pavyzdys 1. Vėlavimai.

Jei mažas delsos laikas yra esminis reikalavimas tarp kai kurių tinklo segmentų, o tai, pavyzdžiui, teisinga mainų atveju, tada negalėsime naudoti užkardos tarp šių segmentų. Sunku rasti užkardų delsos tyrimų, tačiau keli jungiklių modeliai gali užtikrinti mažesnį arba maždaug 1 mksek delsą, todėl manau, kad jei jums svarbios mikrosekundės, tada ugniasienės jums netinka.

Pavyzdys 2. Spektaklis.

Aukščiausių L3 jungiklių pralaidumas paprastai yra eilės tvarka didesnis nei galingiausių ugniasienių. Todėl didelio intensyvumo srauto atveju taip pat greičiausiai turėsite leisti šiam srautui apeiti užkardas.

Pavyzdys 3. Patikimumas.

Ugniasienės, ypač šiuolaikinės NGFW (Next-Generation FW), yra sudėtingi įrenginiai. Jie yra daug sudėtingesni nei L3/L2 jungikliai. Jie suteikia daugybę paslaugų ir konfigūravimo galimybių, todėl nenuostabu, kad jų patikimumas yra daug mažesnis. Jei paslaugų tęstinumas yra labai svarbus tinklui, gali tekti pasirinkti, kas užtikrins geresnį pasiekiamumą – saugumas naudojant užkardą ar tinklo, kuriamo ant jungiklių (ar įvairių tipų audinių), naudojant įprastus ACL, paprastumas.

Aukščiau pateiktų pavyzdžių atveju greičiausiai (kaip įprasta) turėsite rasti kompromisą. Pažvelkite į šiuos sprendimus:

• jei nuspręsite nenaudoti ugniasienės duomenų centro viduje, tuomet turite pagalvoti, kaip kiek įmanoma apriboti prieigą aplink perimetrą. Pavyzdžiui, iš interneto galite atidaryti tik reikalingus prievadus (kliento srautui) ir administracinę prieigą prie duomenų centro tik iš „jump hostų“. „Jump“ prieglobose atlikite visus būtinus patikrinimus (autentifikavimas / autorizacija, antivirusinė, registravimas ir ...)
• galite naudoti loginį duomenų centro tinklo skaidinį į segmentus, panašiai kaip aprašyta PSEFABRIC. pavyzdys p002. Tokiu atveju maršruto parinkimas turi būti sukonfigūruotas taip, kad delsimui jautrus arba didelio intensyvumo srautas eitų „per“ vieną segmentą (p002 atveju VRF), o ne per užkardą. Eismas tarp skirtingų segmentų ir toliau vyks per užkardą. Taip pat galite naudoti maršruto nutekėjimą tarp VRF, kad išvengtumėte srauto nukreipimo per užkardą
• Taip pat galite naudoti ugniasienę skaidriu režimu ir tik tiems VLAN, kur šie veiksniai (delsa / našumas) nėra reikšmingi. Bet jūs turite atidžiai išstudijuoti apribojimus, susijusius su šio modelio naudojimu kiekvienam pardavėjui
• galbūt norėsite apsvarstyti galimybę naudoti paslaugų grandinės architektūrą. Tai leis per užkardą patekti tik būtinam srautui. Teoriškai atrodo gražiai, bet niekada nemačiau tokio sprendimo gamyboje. Prieš maždaug 5 metus išbandėme Cisco ACI/Juniper SRX/F3 LTM paslaugų grandinę, tačiau tuomet šis sprendimas mums atrodė „neapdorotas“.

Apsaugos lygis

Dabar turite atsakyti į klausimą, kokius įrankius norite naudoti srautui filtruoti. Štai keletas funkcijų, kurios paprastai yra NGFW (pvz., čia):

• būsenos užkarda (numatytasis)
• programų ugniasienės
• grėsmių prevencija (antivirusinė, šnipinėjimo programa ir pažeidžiamumas)
• URL filtravimas
• duomenų filtravimas (turinio filtravimas)
• failų blokavimas (failų tipų blokavimas)
• dos apsauga

Ir ne viskas aišku. Atrodytų, kuo aukštesnis apsaugos lygis, tuo geriau. Bet jūs taip pat turite tai apsvarstyti

• Kuo daugiau iš minėtų ugniasienės funkcijų naudosite, tuo natūraliai ji brangs (licencijos, papildomi moduliai)
• kai kurių algoritmų naudojimas gali žymiai sumažinti ugniasienės pralaidumą ir taip pat padidinti delsą, žr., pavyzdžiui čia
• kaip ir bet kuris sudėtingas sprendimas, sudėtingų apsaugos metodų naudojimas gali sumažinti jūsų sprendimo patikimumą, pavyzdžiui, naudojant programų ugniasienę, susidūriau su kai kurių gana standartinių veikiančių programų (dns, smb) blokavimu.

Kaip visada, turite rasti geriausią sprendimą savo tinklui.

Neįmanoma galutinai atsakyti į klausimą, kokių apsaugos funkcijų gali prireikti. Pirma, nes tai, žinoma, priklauso nuo duomenų, kuriuos perduodate arba saugote ir bandote apsaugoti. Antra, iš tikrųjų dažnai saugumo priemonių pasirinkimas yra tikėjimo ir pasitikėjimo pardavėju reikalas. Jūs nežinote algoritmų, nežinote jų efektyvumo ir negalite jų visiškai išbandyti.

Todėl kritiniuose segmentuose geras sprendimas gali būti įvairių įmonių pasiūlymų naudojimas. Pavyzdžiui, galite įjungti antivirusinę užkardoje, bet taip pat naudoti antivirusinę apsaugą (kito gamintojo) vietoje pagrindiniuose kompiuteriuose.

Segmentavimas

Kalbame apie loginį duomenų centrų tinklo segmentavimą. Pavyzdžiui, skaidymas į VLAN ir potinklius taip pat yra loginis segmentavimas, tačiau mes to nenagrinėsime dėl jo akivaizdumo. Įdomus segmentavimas, atsižvelgiant į tokius subjektus kaip FW saugos zonos, VRF (ir jų analogai įvairių tiekėjų atžvilgiu), loginiai įrenginiai (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Pateikiamas tokio loginio segmentavimo ir šiuo metu paklausaus duomenų centro dizaino pavyzdys PSEFABRIC projekto p002.

Apibrėžę logines tinklo dalis, galite aprašyti, kaip srautas juda tarp skirtingų segmentų, kuriuose įrenginiuose ir kokiomis priemonėmis bus atliekamas filtravimas.

Jei jūsų tinkle nėra aiškaus loginio skaidinio ir nėra įformintos saugos politikos taikymo skirtingiems duomenų srautams taisyklės, tai reiškia, kad atidarę tą ar kitą prieigą, būsite priversti išspręsti šią problemą ir labai tikėtina kaskart išspręs kitaip.

Dažnai segmentavimas grindžiamas tik FW saugumo zonomis. Tada turite atsakyti į šiuos klausimus:

• kokių apsaugos zonų jums reikia
• kokio lygio apsaugą norite taikyti kiekvienai iš šių zonų
• ar pagal nutylėjimą bus leidžiamas srautas zonoje?
• jei ne, kokia srauto filtravimo politika bus taikoma kiekvienoje zonoje
• kokia srauto filtravimo politika bus taikoma kiekvienai zonų porai (šaltinis / paskirties vieta)

TCAM

Dažna problema yra nepakankama TCAM (Ternary Content Addressable Memory) tiek maršruto parinkimui, tiek prieigai. IMHO, tai vienas iš svarbiausių klausimų renkantis įrangą, todėl į šią problemą reikia žiūrėti tinkamai.

1 pavyzdys. Persiuntimo lentelė TCAM.

Pažvelkime Palo Alto 7k ugniasienė
Matome, kad IPv4 persiuntimo lentelės dydis* = 32K
Be to, toks maršrutų skaičius yra bendras visoms VSYS.

Tarkime, kad pagal savo dizainą nuspręsite naudoti 4 VSYS.
Kiekvienas iš šių VSYS yra prijungtas per BGP su dviem MPLS PE debesyje, kurį naudojate kaip BB. Taigi, 4 VSYS keičiasi visais konkrečiais maršrutais tarpusavyje ir turi persiuntimo lentelę su maždaug tais pačiais maršrutų rinkiniais (bet skirtingais NH). Nes kiekvienas VSYS turi 2 BGP seansus (su tais pačiais nustatymais), tada kiekvienas per MPLS gautas maršrutas turi 2 NH ir atitinkamai 2 FIB įrašus persiuntimo lentelėje. Jei darysime prielaidą, kad tai yra vienintelė užkarda duomenų centre ir ji turi žinoti apie visus maršrutus, tai reikš, kad bendras maršrutų skaičius mūsų duomenų centre negali būti didesnis nei 32K/(4 * 2) = 4K.

Dabar, jei darysime prielaidą, kad turime 2 duomenų centrus (to paties dizaino) ir norime naudoti VLAN, „ištemptus“ tarp duomenų centrų (pavyzdžiui, „vMotion“), tada norėdami išspręsti maršruto parinkimo problemą, turime naudoti pagrindinio kompiuterio maršrutus. . Bet tai reiškia, kad 2 duomenų centrams turėsime ne daugiau kaip 4096 galimus pagrindinius kompiuterius ir, žinoma, to gali nepakakti.

2 pavyzdys. ACL TCAM.

Jei planuojate filtruoti srautą per L3 jungiklius (ar kitus sprendimus, kuriuose naudojami L3 jungikliai, pavyzdžiui, Cisco ACI), renkantis įrangą turėtumėte atkreipti dėmesį į TCAM ACL.

Tarkime, kad norite valdyti prieigą prie Cisco Catalyst 4500 SVI sąsajų. Tada, kaip matyti iš šis straipsnis, norėdami valdyti išeinantį (taip pat ir įeinantį) srautą sąsajose, galite naudoti tik 4096 TCAM eilutes. Kuris naudojant TCAM3 duos apie 4000 tūkstančių ACE (ACL eilučių).

Jei susiduriate su nepakankamo TCAM problema, pirmiausia, žinoma, turite apsvarstyti optimizavimo galimybę. Taigi, iškilus problemai dėl persiuntimo lentelės dydžio, turite apsvarstyti galimybę sujungti maršrutus. Iškilus problemai dėl prieigų TCAM dydžio, patikrinkite prieigas, pašalinkite pasenusius ir persidengiančius įrašus ir galbūt peržiūrėkite prieigų atidarymo tvarką (išsamiau bus aptarta skyriuje apie prieigų auditą).

Didelis prieinamumas

Kyla klausimas: ar turėčiau naudoti HA užkardoms, ar „lygiagrečiai“ įdiegti dvi nepriklausomas dėžes ir, jei viena iš jų sugenda, nukreipti srautą per antrą?

Atrodytų, atsakymas akivaizdus – naudokite HA. Priežastis, kodėl šis klausimas vis dar kyla, yra ta, kad, deja, teorinis ir reklaminis 99 prieinamumas bei keli dešimtainiai procentai praktiškai nėra tokie rožiniai. HA logiškai yra gana sudėtingas dalykas, ir ant skirtingos įrangos, ir su skirtingais tiekėjais (nebuvo jokių išimčių) mes užfiksavome problemas ir klaidas bei aptarnavimo stabdžius.

Jei naudosite HA, turėsite galimybę išjungti atskirus mazgus, persijungti tarp jų nestabdydami paslaugos, o tai svarbu, pavyzdžiui, atliekant atnaujinimus, tačiau tuo pačiu turite toli nuo nulio tikimybę, kad abu mazgai suges tuo pačiu metu, o taip pat, kad kitą kartą atnaujinimas vyks ne taip sklandžiai, kaip žada pardavėjas (šios problemos galima išvengti, jei turite galimybę išbandyti atnaujinimą ant laboratorinės įrangos).

Jei nenaudojate HA, tai dvigubo gedimo požiūriu jūsų rizika yra daug mažesnė (kadangi turite 2 nepriklausomas ugniasienes), bet kadangi... seansai nėra sinchronizuojami, tada kiekvieną kartą perjungę šias užkardas prarasite srautą. Žinoma, galite naudoti užkardą be būsenos, tačiau tada ugniasienės naudojimo prasmė iš esmės prarandama.

Todėl, jei atlikę auditą aptikote vienišų ugniasienių ir galvojate apie savo tinklo patikimumo didinimą, HA, žinoma, yra vienas iš rekomenduojamų sprendimų, tačiau turėtumėte atsižvelgti ir į su tuo susijusius trūkumus. taikant šį metodą ir, galbūt, konkrečiai jūsų tinklui, labiau tiktų kitas sprendimas.

Valdomumas

Iš esmės HA taip pat yra valdomumas. Užuot konfigūruodami 2 langelius atskirai ir spręsdami konfigūracijų sinchronizavimo problemą, tvarkote jas taip, lyg turėtumėte vieną įrenginį.

Bet galbūt jūs turite daug duomenų centrų ir daug ugniasienės, tada šis klausimas iškyla naujame lygmenyje. Ir klausimas ne tik apie konfigūraciją, bet ir apie

• atsarginės konfigūracijos
• atnaujinimus
• atnaujinimai
• stebėjimas
• medienos ruoša

Ir visa tai gali išspręsti centralizuotos valdymo sistemos.

Taigi, pavyzdžiui, jei naudojate Palo Alto ugniasienes, tada Peržiūrėti yra toks sprendimas.

Bus tęsiama.

Šaltinis: www.habr.com