Ky ky artikulli është e treta në ciklin e artikujve "Si të kontrolloni infrastrukturën e rrjetit tuaj". Përmbajtja e të gjitha artikujve në cikël dhe lidhjet mund të gjenden .
Nuk ka kuptim të flasim për eliminimin e plotë të rreziqeve të sigurisë. Ne, në thelb, nuk mund t'i ulim ato në zero. Për më tepër, duhet të kuptohet se, ndërsa përpiqemi ta bëjmë rrjetin më të sigurt, zgjidhjet tona bëhen gjithnjë e më të shtrenjta. Duhet të gjejmë një kompromis të arsyeshëm për rrjetin tuaj midis çmimit, kompleksitetit dhe sigurisë.
Sigurisht, dizajni i sigurisë është organikisht e inkorporuar në arkitekturën e përgjithshme dhe zgjidhjet e sigurisë të përdorura ndikojnë në shkallëzueshmërinë, besueshmërinë, menaxhueshmërinë, ⊠e infrastrukturës së rrjetit, e cila gjithashtu duhet të merret parasysh.
Por, le të rikujtojmë se tani nuk po flasim për krijimin e rrjetit. Në përputhje me kushtet tona ne tashmë kemi ndarë dizajnin, kemi përzgjedhur pajisjet dhe kemi krijuar infrastrukturën, dhe në këtë fazë ne, sa më shumë të jetë e mundur, duhet të "jetojmë" dhe të gjejmë zgjidhje në kontekstin e qasjes së mëparshme.
Detyra jonĂ« tani Ă«shtĂ« tĂ« identifikojmĂ« rreziqet qĂ« lidhen me sigurinĂ« nĂ« nivelin e rrjetit dhe tâi ulim ato nĂ« njĂ« nivel tĂ« arsyeshĂ«m.
Auditimi i sigurisë së rrjetit
Nëse në organizatën tuaj janë implementuar proceset ISO 27k, atëherë auditimi i sigurisë dhe ndryshimet në rrjet duhet të jenë organikisht të inkorporuara në proceset e përgjithshme brenda kësaj qasjeje. Por këto standarde nuk flasin për zgjidhje specifike, për konfigurimin, për dizajnin⊠Nuk ka këshilla të qarta, nuk ka standa që e diktojnë me detaje se si duhet të jetë rrjeti juaj, kjo është kompleksi dhe bukuria e kësaj detyre.
Do të veçoja disa audite të mundshme të sigurisë së rrjetit:
- auditimi i konfigurimit të pajisjeve (hardening)
- auditimi i dizajnit të sigurisë
- auditimi i qasjeve
- auditimi i proceseve
Auditimi i konfiguracionit të pajisjeve (hardening)
Duket se, në shumicën e rasteve, kjo është pika më e mirë fillestare për auditimin dhe përmirësimin e sigurisë së rrjetit tuaj. IMHO, kjo është një demonstrim e mirë e ligjit të Pareto (20% e përpjekjeve japin 80% të rezultateve, ndërsa 80% e përpjekjeve japin vetëm 20% të rezultateve).
ĂĂ«shtja Ă«shtĂ« se zakonisht kemi rekomandime nga furnizuesit nĂ« lidhje me "praktikat mĂ« tĂ« mira" pĂ«r sigurinĂ« gjatĂ« konfigurimit tĂ« pajisjeve. Kjo quhet âhardeningâ.
Një anketë (ose mund ta krijoni vetë) mund të përfshihet në bazë të këtyre rekomandimeve, e cila do t'ju ndihmojë të përcaktoni se sa përputhet konfigurimi i pajisjeve tuaja me këto "praktikat më të mira" dhe në përputhje me rezultatet të bëni ndryshime në rrjetin tuaj. Kjo do t'ju lejojë të ulni ndjeshëm rreziqet e sigurisë pa ndonjë kostot të konsiderueshme.
Disa shembuj për disa sisteme operative Cisco.
Bazuar në këto dokumente, mund të krijohet një listë kërkesash për konfigurimin e çdo lloji pajisjeje. Për shembull, për Cisco N7K VDC, këto kërkesa mund të duken .
Kështu, mund të krijohen skedarë konfigurimi për lloje të ndryshme të pajisjeve aktive në infrastrukturën tuaj rrjetërore. Më pas, manualisht ose me ndihmën e automatizimit, mund të "ngarkoni" këto skedarë konfigurimi. Si të automatizoni këtë proces do të shqyrtohet në një seri tjetër artikujsh që janë përkushtuar orkestrimit dhe automatizimit.
Auditimi i dizajnit të sigurisë
Zakoniisht në skema e një ndërmarrjeje (enterprise network) në një formë ose tjetër janë të pranishme segmentet e mëposhtme:
- DC (Shërbimet publike DMZ dhe qendra të dhënash Intranet)
- Qasja në Internet
- VPN me qasje të largët
- WAN edge
- Degë
- Kampusi (Zyra)
- Core
Emrat janë marrë nga modeli, por nuk është e nevojshme, natyrisht, të lidhen saktësisht me këto emra dhe këtë model. Megjithatë, dëshirojmë të flasim për thelbin dhe të mos bllokohemi në formalisma.
Për secilin nga këto segmente, kërkesat për nivelin e sigurisë, rreziqet dhe, për rrjedhojë, zgjidhjet do të ndryshojnë.
Le të shqyrtojmë secilin prej tyre një për një në lidhje me problemet me të cilat mund të përballeni nga këndvështrimi i dizajnit të sigurisë. Sigurisht, përsëris se ky artikull nuk pretendojnë për përmbushjen e plotë, e cila është e vështirë të arrihet në këtë temë të thellë dhe të shumëanshme (nëse ndonjëherë është e mundur), por pasqyron eksperiencën time personale.
Nuk ka zgjidhje perfekte ( të paktën jo tani). Kjo është gjithmonë një kompromis. Por është e rëndësishme që zgjidhja për të përdorur një qasje të caktuar të bëhet e vetëdijshme, me kuptim të avantazheve dhe disavantazheve të saj.
Qendra e të Dhënave
Segmenti më kritik nga këndvështrimi i sigurisë.
Dhe, si zakonisht, këtu gjithashtu nuk ka një zgjidhje universale. Gjithçka varet shumë nga kërkesat për rrjetin.
A nevojitet një firewall?
Duket sikur përgjigjja është e qartë, por gjithçka nuk është aq e thjeshtë sa duket. Dhe zgjedhja juaj mund të ndikojë jo vetëm çmimi.
Shembulli 1. Vonesa.
NĂ«se midis ndonjĂ« segmenti tĂ« rrjetit, vonesa e ulĂ«t Ă«shtĂ« njĂ« kĂ«rkesĂ« thelbĂ«sore, gjĂ« qĂ«, pĂ«r shembull, Ă«shtĂ« e vĂ«rtetĂ« nĂ« rastin e tregjeve, atĂ«herĂ« midis kĂ«tyre segmenteve ne nuk do tĂ« mund tĂ« pĂ«rdorim firewall. ĂshtĂ« e vĂ«shtirĂ« tĂ« gjejmĂ« studime mbi vonesat nĂ« firewall, por vetĂ«m disa modele switch-e mund tĂ« ofrojnĂ« vonesa mĂ« pak se ose rreth 1 mksec, prandaj, mendoj se nĂ«se mikrosekuadat janĂ« tĂ« rĂ«ndĂ«sishme pĂ«r ju, atĂ«herĂ« firewall-t nuk janĂ« pĂ«r ju.
Shembulli 2. Performanca.
Kapaciteti i switches L3 më të mirë zakonisht është shumë më i lartë se kapaciteti i firewall-ve më produktivë. Prandaj, në rastin e trafikut me intensitet të lartë, ju gjithashtu ndoshta do të duhet ta kaloni këtë trafik përtej firewall-ve.
Shembulli 3. Qëndrueshmëria.
Firewall-t, veçanĂ«risht moderne NGFW (Firewall-i i GjeneratĂ«s sĂ« Re) â janĂ« pajisje komplekse. Ato janĂ« ndjeshĂ«m mĂ« tĂ« komplikuara se switch-e L3/L2. Ato ofrojnĂ« njĂ« mori shĂ«rbimesh dhe mundĂ«sish pĂ«r konfigurim, prandaj nuk Ă«shtĂ« e çuditshme qĂ« qĂ«ndrueshmĂ«ria e tyre Ă«shtĂ« ndjeshĂ«m mĂ« e ulĂ«t. NĂ«se vazhdimĂ«sia e shĂ«rbimit Ă«shtĂ« kritike pĂ«r rrjetin, ndoshta do t'ju duhet tĂ« zgjidhni se çfarĂ« do tĂ« çojĂ« nĂ« disponueshmĂ«rinĂ« mĂ« tĂ« mirĂ« - mbrojtja me anĂ« tĂ« firewall-it ose thjeshtĂ«sia e rrjetit tĂ« ndĂ«rtuar mbi switch-e (ose lloje tĂ« ndryshme fabrikash) duke pĂ«rdorur ACL-tĂ« e zakonshme.
Në rastin e shembujve të përmendur më sipër, ju ndoshta (si zakonisht) do të duhet të kërkoni një kompromis. Shikoni drejt zgjidhjeve të mëposhtme:
- nëse keni vendosur të mos përdorni firewall brenda qendrës së të dhënave, atëherë duhet të mendoni se si të kufizoni sa më shumë qasjet në periferinë. Për shembull, mund të hapni vetëm portet e nevojshme nga Interneti (për trafikun e klientëve) dhe qasjet administrative në qendrën e të dhënave vetëm nga hoste të skakierëve. Në hostet e skakierëve kryeni të gjitha verifikimet e nevojshme (autentikim/autorizim, antivirus, logimin, ...)
- mund të përdorni ndarjen logjike të rrjetit të qendrës së të dhënave në segmente, siç është skema e përshkruar në PSEFABRIC Në të njëjtën kohë, drejtimi duhet të konfigurohet në një mënyrë që trafiku, i ndjeshëm ndaj vonesave ose trafiku me intensitet të lartë të kalojë "brenda" një segmenti (në rastin e p002, VRF-it) dhe të mos kalojë përmes firewall-it. Trafiku ndërmjet segmenteve të ndryshme do të vazhdojë të kalojë përmes firewall-it. Po ashtu, mund të përdoret route leaking midis VRF-ve për të shmangur ridrejtimin e trafikut përmes firewall-it.
- Gjithashtu, mund të përdoret firewall në modalitetin transparent dhe vetëm për VLAN-et për të cilat këta faktorë (vonesa/përformanca) nuk janë thelbësorë. Por duhet të studiohen me kujdes kufizimet që lidhen me përdorimin e kësaj mode për çdo furnizues.
- Mund të mendoni për zbatimin e arkitekturës së zinxhirit të shërbimeve. Kjo do të lejojë kalimin përmes firewall-it vetëm të trafikut të nevojshëm. Teorikisht duket bukur, por unë kurrë nuk e kam parë këtë zgjidhje në prodhim. Ne e testuam zinxhirin e shërbimeve për Cisco ACI/Juniper SRX/F5 LTM rreth 3 vjet më parë, por në atë kohë kjo zgjidhje na dukej "e papjekur".
Niveli i mbrojtjes
Tani duhet të përgjigjeni në pyetjen se cilat mjete dëshironi të përdorni për filtrimin e trafikut. Ja disa nga mundësitë që zakonisht janë të pranishme në NGFW (p.sh., ):
- firewall stateful (në mënyrë të paracaktuar)
- firewall aplikacioni
- parandalimi i kërcënimeve (antivirus, anti-spyware dhe dobësi)
- filtrimi i URL-ve
- filtrimi i të dhënave (filtrimi i përmbajtjes)
- bllokimi i skedarëve (bllokimi i llojeve të skedarëve)
- mbrojtja nga dos
Dhe gjithashtu nuk është gjithçka e qartë. Duket se sa më i lartë të jetë niveli i mbrojtjes, aq më i mirë është. Por ju gjithashtu duhet të merrni parasysh se
- sa më shumë nga funksionet e mësipërme të firewall-it të përdorni, aq natyrisht do të jetë më e shtrenjtë (licencat, module të tjera)
- përdorimi i disa algoritmeve mund të ulë ndjeshëm kapacitetin e firewall-it, si dhe të rrisë vonesat, shihni për shembull
- siç është çdo zgjidhje e komplikuar, përdorimi i metodave të ndërlikuara të mbrojtjes mund të ulë besueshmërinë e zgjidhjes suaj, për shembull, kur përdor aplikacionin e mbrojtjes unë kam hasur në bllokimin e disa aplikacioneve mjaft standarde (dns, smb)
Si zakonisht, duhet të gjeni zgjidhjen optimale për rrjetin tuaj.
Nuk është e mundur të përgjigjeni në mënyrë të qartë se cilat funksione mbrojtjeje mund të nevojiten. Së pari, sepse kjo natyrisht varet nga të dhënat që po përcillni ose ruani dhe përpiqeni t'i mbrojtni. Së dyti, në të vërtetë, shpesh zgjedhja e mjeteve të mbrojtjes është një çështje besimi dhe besimi në furnizuesin. Ju nuk e dini algoritmet, nuk e dini sa efektivë janë dhe nuk mund t'i testoni plotësisht.
Prandaj, në segmentet kritike, një zgjidhje e mirë mund të jetë përdorimi i ofertave nga kompani të ndryshme. Për shembull, mund të aktivizoni antivirusin në firewall, por gjithashtu të përdorni mbrojtjen antivirale (nga një prodhues tjetër) lokalisht në hostet.
Segmentimi
Bëhet fjalë për segmentimin logjik të rrjetit të qendrës të të dhënave. Për shembull, ndarja në VLAN dhe nënrrjete është gjithashtu segmentim logjik, por ne nuk do ta shqyrtojmë atë për shkak të evidencës së saj. E rëndësishme është segmentimi duke marrë parasysh njësi të tilla si zonat e sigurisë FW, VRF (dhe ekuivalentët e tyre për furnizues të ndryshëm), pajisjet logjike (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...
Një shembuj i tillë i segmentimit logjik dhe dizajnit të kërkuar në këtë moment të qendrës të të dhënave është paraqitur në .
Pasi të keni përcaktuar pjesët logjike të rrjetit tuaj, mund të përshkruani se si kalon trafiku midis segmenteve të ndryshme, në cilat pajisje do të kryhet filtrimi dhe me çfarë mjete.
Nëse rrjeti juaj nuk ka një ndarje logjike të qartë dhe nuk janë formalizuar rregullat për aplikimin e politikave të sigurisë për rrjedhat e ndryshme të të dhënave, atëherë kjo do të thotë se, kur hapni një qasje të caktuar, duhet të zgjidhni këtë çështje, dhe ka një probabilitet të madh që çdo herë do ta zgjidhni ndryshe.
Shpesh, segmentimi bazohet vetëm në zonat e sigurisë FW. Atëherë, ju duhet të përgjigjeni në këto pyetje:
- cilat zona sigurie ju nevojiten
- çfarë niveli mbrojtjeje dëshironi të aplikoni për secilën nga këto zona
- a do të lejohet trafiku intra-zone me default
- nëse jo, çfarë politikash të filtrimit të trafikut do të aplikohen brenda secilës zonë
- çfarë politikash të filtrimit të trafikut do të aplikohen për secilën çift zonash (source/destination)
TCAM
Problemi i insuficientit TCAM (Ternary Content Addressable Memory) është shpesh i pranishëm, si për rrugëzimin ashtu edhe për akseset. IMHO, ky është një nga pyetjet më të rëndësishme kur zgjidhni pajisje, prandaj duhet t'i kushtoni këtij problemi një nivel adekuat kujdesi.
Shembulli 1. Forwarding Table TCAM.
Le të shqyrtojmë firewall.
Vërejmë se madhësia e IPv4 forwarding table* = 32K
Në të njëjtën kohë, ky numër rrugësh është gjithsej për të gjitha VSYS-të.Le të supozojmë që, në përputhje me dizajnin tuaj, keni vendosur të përdorni 4 VSYS.
Ădo njĂ«ri nga kĂ«to VSYS Ă«shtĂ« i lidhur me dy PE MPLS nĂ« cloud, tĂ« cilin e pĂ«rdorni si BB. KĂ«shtu, 4 VSYS shkĂ«mbejnĂ« tĂ« gjitha rrugĂ«t specifike me njĂ«ra-tjetrĂ«n dhe kanĂ« njĂ« tabelĂ« forwarding me grupe afĂ«rsisht tĂ« njĂ«jtĂ« rrugĂ«sh (por me NH tĂ« ndryshme). Pasi secili VSYS ka 2 seanca BGP (me konfigurime tĂ« njĂ«jta), çdo rrugĂ« e marrĂ« pĂ«rmes MPLS ka 2 NH dhe, pĂ«r rrjedhojĂ«, 2 FIB tĂ« regjistruara nĂ« TabelĂ«n e Forwarding. NĂ«se supozojmĂ« se ky Ă«shtĂ« firewall-i i vetĂ«m nĂ« qendrĂ«n e tĂ« dhĂ«nave dhe ai duhet tĂ« dijĂ« pĂ«r tĂ« gjitha rrugĂ«t, kjo do tĂ« thotĂ« se numri total i rrugĂ«ve nĂ« qendrĂ«n tonĂ« tĂ« tĂ« dhĂ«nave nuk mund tĂ« jetĂ« mĂ« shumĂ« se 32K/(4 * 2) = 4K.Tani, nĂ«se supozojmĂ« se kemi 2 qendra tĂ« tĂ« dhĂ«nave (me dizajn tĂ« njĂ«jtĂ«), dhe ne duam tĂ« pĂ«rdorim VLAN-et, "tĂ« shtrira" ndĂ«rmjet qendrave tĂ« tĂ« dhĂ«nave (pĂ«r shembull, pĂ«r vMotion), atĂ«herĂ«, pĂ«r tĂ« zgjidhur problemin e routing-ut, ne duhet tĂ« pĂ«rdorim rrugĂ«t host. Por kjo do tĂ« thotĂ« se pĂ«r 2 qendra tĂ« tĂ« dhĂ«nave do tĂ« kemi jo mĂ« shumĂ« se 4096 hoste tĂ« mundshĂ«m dhe, sigurisht, kjo mund tĂ« jetĂ« e pamjaftueshme.
Shembulli 2. ACL TCAM.
Nëse planifikoni të filtroni trafikun në switch-e L3 (ose zgjidhje të tjera që përdorin switch-e L3, për shembull, Cisco ACI), atëherë, kur të zgjidhni pajisjet, duhet të kushtoni vëmendje në ACL TCAM.
Supozoni se dĂ«shironi tĂ« kontrolloni aksesin nĂ« ndĂ«rfaqet SVI tĂ« Cisco Catalyst 4500. Pastaj, siç shihet nga , pĂ«r tĂ« kontrolluar trafikun e dalĂ«s (po ashtu si edhe atĂ« tĂ« ardhĂ«s) nĂ« ndĂ«rfaqet, mund tĂ« pĂ«rdorni vetĂ«m 4096 rreshta TCAM. Ăka me pĂ«rdorimin e TCAM3 do t'ju japĂ« rreth 4000 ACE (rreshta ACL).
NĂ« rast se hasni njĂ« problem me TCAM tĂ« pamjaftueshĂ«m, atĂ«herĂ«, sĂ« pari, sigurisht, duhet tĂ« shqyrtoni mundĂ«sinĂ« e optimizimit. Pra, nĂ« rast tĂ« njĂ« problemi me madhĂ«sinĂ« e TabelĂ«s sĂ« Forwarding, duhet tĂ« shqyrtoni mundĂ«sinĂ« e agregimit tĂ« rrugĂ«ve. NĂ« rast tĂ« njĂ« problemi me madhĂ«sinĂ« e TCAM pĂ«r akseset â auditimi i aksesit, fshirja e regjistrimeve tĂ« vjetra dhe ndĂ«rprera, si dhe, ndoshta, shqyrtimi i procedurĂ«s sĂ« hapjes sĂ« aksesit (do tĂ« shqyrtohet nĂ« detaje nĂ« kapitullin e dedikuar auditimit tĂ« aksesit).
Disponueshmëri e Lartë
ĂĂ«shtja Ă«shtĂ« nĂ«se tĂ« pĂ«rdorni HA pĂ«r firewall-et ose tĂ« vendosni "paralel" dy kuti tĂ« pavarura dhe nĂ« rast se njĂ«ra dĂ«shtan, tĂ« ruteroni trafikun pĂ«rmes tjetrĂ«s?
PĂ«r aq sa duket, pĂ«rgjigjja Ă«shtĂ« e qartĂ« â tĂ« pĂ«rdorim HA. Arsyeja pse ky pyetje vazhdon tĂ« ngrihet Ă«shtĂ« se, fatkeqĂ«sisht, teorikisht dhe reklamueshĂ«m, 99 dhe disa nĂ«ntĂ«ra pas presjes sĂ« pikĂ«s sĂ« disponueshmĂ«risĂ« nĂ« praktikĂ« duken shumĂ« mĂ« pak premtuese. HA Ă«shtĂ« njĂ« gjĂ« logjikisht mjaft e mirĂ«, dhe nĂ« pajisje tĂ« ndryshme, dhe me ofrues tĂ« ndryshĂ«m (pa pĂ«rjashtime), kemi zbuluar probleme dhe ndalesa tĂ« shĂ«rbimeve.
Në rastin e përdorimit të HA, do të keni mundësinë të fikni node të veçanta, të kaloni midis tyre pa ndaluar shërbimin, gjë që është e rëndësishme, për shembull, gjatë përmirësimeve, por gjithashtu keni një probabilitet të konsiderueshëm që të dy node-t tuaj të prishen në të njëjtën kohë, si dhe se përmirësimi i ardhshëm nuk do të kalojë aq mirë sa premton ofruesi (kjo mund të shmanget, nëse keni mundësinë të testoni përmirësimin në pajisje laboratorike).
Nëse nuk përdorni HA, atëherë nga këndvështrimi i dështimit të dyfishtë, rreziqet tuaja janë ndjeshëm më të ulta (për shkak se keni 2 firewall të pavarur), por pasi sesionet nuk janë të sinkronizuara, çdo herë që ndodhi kalimi midis këtyre firewall-ave do të humbni trafik. Natyrisht, mund të përdorni firewall të paqëndrueshëm, por pastaj kuptimi i përdorimit të firewall-it në shumicën e rasteve humbet.
Prandaj, nëse si rezultat i auditimit keni zbuluar firewall të vetmuar, dhe po mendoni për rritjen e besueshmërisë së rrjetit tuaj, atëherë HA, sigurisht, është një nga zgjidhjet e rekomanduara, por duhet të merrni parasysh dhe disavantazhet që lidhen me këtë qasje dhe, ndoshta, për rrjetin tuaj një zgjidhje tjetër do të ishte më e përshtatshme.
Lehtësia në menaxhim
Në principe, HA është gjithashtu për menaxhueshmërinë. Në vend që të konfiguroni 2 kutia veç e veç dhe të zgjidhni problemin e sinkronizimit të konfigurimeve, ju i menaxhoni ato në një farë mënyre siç kishit një pajisje.
Por, ndoshta, keni shumë qendra të të dhënave dhe shumë firewall, atëherë ky çështje dolin në një nivel të ri. Dhe problemi nuk është vetëm për konfigurimin, por gjithashtu për
- backup-in e konfigurimeve
- përditësimet
- përmirësimet
- monitorimin
- logimin
Dhe të gjitha këto mund të zgjidhen nga sisteme të menaxhimit të centralizuar.
Për shembull, nëse përdorni firewall-ë Palo Alto, atëherë është një zgjidhje e tillë.
Vazhdon...
Burimi: habr.com
