Ky artikull është i treti në ciklin e artikujve "Si të merrni kontrollin mbi infrastrukturën tuaj rrjetë". Përmbajtja e të gjitha artikujve të ciklit dhe lidhjet mund të gjenden .
Nuk ka asnjĂ« kuptim tĂ« flasim pĂ«r eliminimin e plotĂ« tĂ« riskut tĂ« sigurisĂ«. Ne nĂ« parim nuk mund ta zvogĂ«lojmĂ« atĂ« nĂ« zero. Po ashtu, duhet tĂ« kuptohet se, teksa pĂ«rpiqemi tĂ« bĂ«jmĂ« rrjetin mĂ« tĂ« sigurt, zgjidhjet tona bĂ«hen gjithnjĂ« e mĂ« tĂ« shtrenjta. ĂshtĂ« e nevojshme tĂ« gjejmĂ« njĂ« kompromis tĂ« arsyeshĂ«m pĂ«r rrjetin tuaj mes çmimit, kompleksitetit dhe sigurisĂ«.
Sigurisht, dizajni i sigurisë është organikisht i integruar në arkitekturën e përgjithshme dhe zgjidhjet e sigurisë që përdoren ndikojnë në shkallëzueshmëri, besueshmëri, menaxhueshmëri, ⊠të infrastrukturës rrjetë, të cilat gjithashtu duhet të merren parasysh.
Por, le t'i kujtojmë se tani nuk po flasim për krijimin e rrjetit. Në përputhje me ne tashmë kemi zgjedhur dizajnin, pajisjet e zgjedhura dhe kemi ndërtuar infrastrukturën, dhe në këtë fazë duhet të "jetojmë" sa më shumë të jetë e mundur dhe të gjejmë zgjidhje në kontekstin e qasjes të zgjedhur më parë.
Detyra jonë tani është të identifikojmë rreziqet lidhur me mbrojtjen në nivelin e rrjetit dhe t'i zvogëlojmë ato në një nivel të arsyeshëm.
Auditimi i sigurisë në rrjet
Nëse në organizatën tuaj janë implementuar proceset ISO 27k, auditimi i sigurisë dhe ndryshimet e rrjetit duhet të jenë integruar natyrshëm në proceset e përgjithshme në kuadër të këtij qasje. Por këto standarde nuk flasin konkretisht për zgjidhje, konfigurim, ose dizajn... Nuk ka këshilla të qarta, nuk ka standarde që të diktojnë detajisht se si duhet të jetë rrjeti juaj; këtu qëndron kompleksiteti dhe bukuria e kësaj detyre.
Do të veçoja disa auditime të mundshme të sigurisë në rrjet:
- auditimi i konfiguracionit të pajisjeve (hardening)
- auditimi i dizajnit të sigurisë
- auditimi i aksesit
- auditimi i proceseve
Auditimi i konfiguracionit të pajisjeve (hardening)
Duket se në shumicën e rasteve, kjo është pika më e mirë e nisjes 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).
Mundore është që zakonisht kemi rekomandime nga shitësit për "praktikat më të mira" për sigurinë gjatë konfigurimit të pajisjeve. Kjo quhet "hardening".
Gjithashtu, shpesh mund të gjeni një anketë (ose ta krijoni vetë) që bazohet në këto rekomandime, që do t'ju ndihmojë të përcaktoni se sa mirë konfigurimi i pajisjeve tuaja përputhet me këto "praktikat më të mira" dhe të bëni ndryshimet e nevojshme në rrjetin tuaj bazuar në rezultatet. Kjo do t'ju lejojë të reduktoni ndjeshëm rreziqet e sigurisë, në fakt pa asnjë kosto.
Disa shembuj për disa sisteme operative Cisco.
Në bazë të këtyre dokumenteve mund të krijohet një listë kërkesash për konfigurimin e çdo lloj pajisje. 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 pajisjesh aktive në infrastrukturën tuaj rrjetë. Më pas, manualisht ose duke përdorur automatizimin, mund t'i «ngarkoni» këto skedarë konfigurimi. Si të automatizoni këtë proces do të shqyrtohet në një seri artikujsh, të kushtuar orkestrimit dhe automatizimit.
Auditimi i dizajnit të sigurisë
Zakonisht në rrjetin e ndërmarrjes (enterprise network) ndodhen këto segmente në një farë forme:
- DC (Shërbimet publike DMZ dhe qendra e të dhënave Intranet)
- Qasja në Internet
- VPN për qasjen e largët
- WAN edge
- Degë
- Kampusi (Zyra)
- BĂ«rthama
Emrat janë marrë nga modeli, por nuk është e nevojshme, natyrisht, të lidhemi vetëm me këta emra dhe me këtë model. Megjithatë, dëshirojmë të flasim për thelbin dhe të mos jetë një ngatërrim me formalitetet.
Për secilin prej këtyre segmenteve, kërkesat për nivelin e sigurisë, rreziqet dhe, përkatësisht, zgjidhjet do të ndryshojnë.
Të shqyrtojmë secilin prej tyre veç e veç për problemet që mund të hasni nga pikëpamja e dizajnit të sigurisë. Sigurisht, do të përsëris se kjo artikull nuk pretendon për përmbajtje të plotë, një arritje që është e vështirë në këtë temë të thellë dhe shumë dimensional, por pasqyron përvojën time personale.
Nuk ekziston një zgjidhje ideale (në çdo rast tani). Ky është gjithmonë një kompromis. Por është e rëndësishme që vendimi për të përdorur një qasje të caktuar të jetë bërë me vetëdije, duke kuptuar si përavantazhet, ashtu edhe disavantazhet e saj.
Data Center
Segmenti më kritik nga pikëpamja e sigurisë.
Dhe, si zakonisht, këtu nuk ka një zgjidhje universale. Të gjitha varen shumë nga kërkesat për rrjet.
A është i nevojshëm një firewall?
Duket se përgjigjja është e qartë, por gjërat nuk janë aq të thjeshta sa mund të duken. Zgjedhja juaj mund të ndikohet jo vetëm nga çmimi.
Shembulli 1. Vonesa.
NĂ«se njĂ« vonesĂ« e ulĂ«t Ă«shtĂ« njĂ« kĂ«rkesĂ« kritike ndĂ«rmjet disa segmenteve tĂ« rrjetit, siç ndodh nĂ« rastin e tregjeve, nuk do tĂ« mund tĂ« pĂ«rdorim firewall ndĂ«rmjet kĂ«tyre segmenteve. ĂshtĂ« e vĂ«shtirĂ« tĂ« gjejmĂ« studime mbi vonesat nĂ« firewall, por vetĂ«m disa modele switchesh mund tĂ« ofrojnĂ« vonesa mĂ« tĂ« ulĂ«ta se 1 mksec, kĂ«shtu qĂ« mendoj se nĂ«se mikrosekundat janĂ« tĂ« rĂ«ndĂ«sishme pĂ«r ju, firewall-et nuk janĂ« pĂ«r ju.
Shembulli 2. Performanca.
Kapaciteti i broadband-it të switch-ëve L3 të nivelit të lartë është zakonisht shumë më i lartë se kapaciteti i firewall-eve më të fuqishme. Prandaj, në rastin e trafik të lartë, për ju gjithashtu me siguri do të duhet ta dërgoni këtë trafik përmes një rruge anashkalimi të firewall-eve.
Shembulli 3. Besueshmëria.
Firewall-at, veçanërisht NGFW (Firewall-e të Gjeneratës së Re) janë pajisje të ndërlikuara. Ato janë ndjeshëm më të ndërlikuara se switch-at L3/L2. Ato ofrojnë një numër të madh shërbimesh dhe mundësish konfigurimi, prandaj nuk është e çuditshme që besueshmë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ë një disponibilitet më të mirë - mbrojtja me firewall ose thjeshtësia e rrjetit të ndërtuar mbi switch-a (ose lloje të ndryshme fabrikash) duke përdorur ACL të zakonshme.
Në rastet e mësipërme, për siguri do t'ju duhet të bëni një kompromis. Shikoni drejt zgjidhjeve të mëposhtme:
- nĂ«se vendosni tĂ« mos pĂ«rdorni firewall-at brenda qendrĂ«s sĂ« tĂ« dhĂ«nave, duhet tĂ« mendoni se si tĂ« kufizoni sa mĂ« shumĂ« akseset nĂ« periferinĂ«. PĂ«r shembull, mund tĂ« hapni vetĂ«m portet e nevojshme nga Interneti (pĂ«r trafikun e klientĂ«ve) dhe akseset administrative nĂ« qendrĂ«n e tĂ« dhĂ«nave vetĂ«m nga hostat e skakhtarĂ«ve. NĂ« hostat e skakhtarĂ«ve, kryeni tĂ« gjitha kontrollat e nevojshme (autentikimin/autorizimin, antivirusin, regjistrimin, âŠ)
- mund të përdorni ndarjen logjike të rrjetit të qendrës së të dhënave në segmente, siç është përshkruar në PSEFABRIC . Në këtë rast, rrugëzimi duhet të konfigurohet kështu që trafiku i ndjeshëm ndaj vonesave ose trafiku me intensitet të lartë të kalojë "brenda" një segmenti (në rastin e p002, VRF) dhe të mos shkojë përmes firewall-it. Trafiku ndërmjet segmenteve të ndryshme do të vazhdojë të kalojë përmes firewall-it. Gjithashtu, mund të përdoren route leaking midis VRF-ve për të shmangur ridrejtimin e trafikut përmes firewall-it.
- mund të përdorni gjithashtu firewall-in në modalitetin transparent dhe vetëm për ato VLAN-e ku këta faktorë (vonesa / performanca) nuk janë thelbësorë. Por duhet të studioni me kujdes kufizimet që lidhen me përdorimin e kësaj metode për çdo ofrues.
- mund të mendoni për implementimin e arkitekturës së service chain. Kjo do të mundësonte rrugëzimin e vetëm trafikut të nevojshëm përmes firewall-it. Teoretikisht duket bukur, por nuk kam parë kurrë këtë zgjidhje në prodhim. Ne testuam service chain për Cisco ACI / Juniper SRX / F5 LTM rreth 3 vjet më parë, por atëherë kjo zgjidhje na dukej "e papërfunduar".
Niveli i mbrojtjes
Tani është pyetja 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 i gjendjes (me default)
- firewall për aplikacione
- parandalimi i kërcënimeve (antivirus, anti-spyware dhe vulnerabilitet)
- 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
Edhe kjo nuk është gjithmonë e qartë. Duke u dukur, sa më i lartë të jetë niveli i mbrojtjes, aq më mirë. Por gjithashtu duhet të merrni parasysh se
- sa më shumë nga funksionet e mësipërme të firewall-it të përdorni, aq natyrshëm do të jetë më e shtrenjtë (licencat, modulet shtesë)
- përdorimi i disa algoritmeve mund të zvogëlojë ndjeshëm kapacitetin e kalimit të firewall-it, si dhe të rrisë vonesat, shih për shembull
- ashtu si çdo zgjidhje komplekse, përdorimi i metodave komplekse të mbrojtjes mund të ulë besueshmërinë e zgjidhjes suaj, për shembull, duke përdorur firewall për aplikacione kam hasur në bllokimin e disa aplikacioneve që funksionojnë normale (dns, smb)
Si zakonisht, ju nevojitet të gjeni zgjidhjen optimale për rrjetin tuaj.
Nuk është e mundur të jepet një përgjigje e qartë për se cilat funksione mbrojtjeje mund të nevojiten. Së pari, sepse kjo natyrisht varet nga të dhënat që jeni duke transmetuar ose ruajtur dhe përpiqeni të mbrojni. Së dyti, në të vërtetë, shpesh zgjedhja e mjeteve të mbrojtjes është një çështje besimi dhe besueshmërie ndaj ofruesit. Ju nuk i dini algoritmet, nuk keni një ide se sa efikasë janë dhe nuk mund t'i testoni ato plotësisht.
Prandaj, në segmente kritike, një zgjidhje e mirë mund të jetë përdorimi i ofertave nga kompani të ndryshme. Për shembull, ju mund të përfshini antivirusin në firewall, por gjithashtu të përdorni mbrojtjen antivirus (nga një prodhues tjetër) lokalish në hostet.
Segmentimi
BĂ«het fjalĂ« pĂ«r segmentimin logjik tĂ« rrjetit tĂ« qendrĂ«s sĂ« tĂ« dhĂ«nave. PĂ«r shembull, ndarja nĂ« VLAN dhe subnet Ă«shtĂ« gjithashtu segmentim logjik, por nuk do ta trajtojmĂ« atĂ« pĂ«r shkak tĂ« qartĂ«sisĂ« sĂ« saj. Interesante Ă«shtĂ« segmentimi duke marrĂ« parasysh entitete si zonat e sigurisĂ« tĂ« FW, VRF (dhe ekuivalentĂ«t e tyre pĂ«r ofrues tĂ« ndryshĂ«m), pajisjet logjike (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, âŠ), âŠ
Një shembull i tillë i segmentimit logjik dhe dizajnit të kërkuar të qendrës së të dhënave është paraqitur në .
Duke përcaktuar pjesët logjike të rrjetit tuaj, ju më pas mund të përshkruani si lëviz trafiku midis segmenteve të ndryshme, mbi cilat pajisje do të kryhet filtrimi dhe me çfarë mjetesh.
Nëse rrjeti juaj nuk ka një ndarje logjike të qartë dhe rregullat e zbatimit të politikave të sigurisë për rrjedhat e ndryshme të të dhënave (flow) nuk janë formalizuar, atëherë kjo do të thotë se kur hapni një qasje të tillë, ju detyroheni të merrni këtë vendim, dhe me shumë probabilitet do ta bëni këtë në mënyra të ndryshme çdo herë.
Shpesh segmentimi bazohet vetëm në zonat e sigurisë FW. Atëherë duhet t'i përgjigjeni këtyre pyetjeve:
- cilat zona sigurie ju nevojiten
- çfarë niveli mbrojtjeje dëshironi të aplikoni për secilën nga këto zona
- a do të lejohet si parazgjedhje trafiku intra-zone
- nëse jo, cilat politika filtrimi do të zbatohen brenda secilës nga zonat
- cilat politika filtrimi do të zbatohen për çdo çift zonash (burimi/destinacion)
TCAM
Problemi i mungesës së TCAM (Ternary Content Addressable Memory) është shpesh i pranishëm, si për routing ashtu edhe për akses. Në mendimin tim, kjo është një nga çështjet më të rëndësishme kur zgjidhni pajisjet, prandaj duhet t'i kushtohet kësaj çështjeje një kujdes i duhur.
Shembulli 1. Tabela e Forwarding TCAM.
Le të shqyrtojmë firewall.
Vërejmë se madhësia e tabelës së forwarding IPv4* = 32K
Kjo sasi rrugash është gjithsej për të gjitha VSYS-ët.Le të supozojmë se sipas dizajnit tuaj keni vendosur të përdorni 4 VSYS.
Ădo njĂ«ri nga kĂ«to VSYS Ă«shtĂ« lidhur pĂ«rmes BGP nĂ« dy PE tĂ« clouds MPLS, qĂ« po e pĂ«rdorni si BB. NĂ« kĂ«tĂ« mĂ«nyrĂ«, 4 VSYS ndajnĂ« tĂ« gjitha rrugĂ«t specifike me njĂ«ri-tjetrin dhe kanĂ« njĂ« tabelĂ« forwarding me grupe rruge pothuajse tĂ« njĂ«jta (por me NH tĂ« ndryshĂ«m). Duke qenĂ« se çdo VSYS ka 2 sesi BGP (me konfigurime tĂ« njĂ«jta), çdo rrugĂ« e marrĂ« pĂ«rmes MPLS ka 2 NH dhe, pĂ«r rrjedhojĂ«, 2 regjistrime FIB nĂ« TabelĂ«n e Forwarding. NĂ«se supozojmĂ« se ky Ă«shtĂ« firewall-i i vetĂ«m nĂ« data-qendrĂ«n dhe ai duhet tĂ« dijĂ« pĂ«r tĂ« gjitha rrugĂ«t, atĂ«herĂ« kjo do tĂ« thotĂ« se numri total i rrugĂ«ve nĂ« data-qendrĂ«n tonĂ« nuk mund tĂ« jetĂ« mĂ« shumĂ« se 32K/(4 * 2) = 4K.Tani, nĂ«se supozojmĂ« se kemi 2 qendra tĂ« tĂ« dhĂ«nash (me dizajn tĂ« njĂ«jtĂ«), dhe duam tĂ« pĂ«rdorim VLAN-tĂ« e âshtriraâ midis qendrave tĂ« tĂ« dhĂ«nave (pĂ«r shembull, pĂ«r vMotion), pĂ«r tĂ« zgjidhur problemin e ruterimit, duhet tĂ« pĂ«rdorim ruterat e hostit. Por kjo do tĂ« thotĂ« se pĂ«r 2 qendra tĂ« tĂ« dhĂ«nash do tĂ« kemi jo mĂ« shumĂ« se 4096 hoste tĂ« mundshĂ«m, dhe sigurisht, kjo mund tĂ« mos mjaftojĂ«.
Shembulli 2. ACL TCAM.
NĂ«se planifikoni tĂ« filtroni trafikun nĂ« switch-e L3 (ose zgjidhje tĂ« tjera qĂ« pĂ«rdorin switch-e L3, si pĂ«r shembull Cisco ACI), kur zgjidhni pajisjet duhet tâi kushtoni vĂ«mendje ACL TCAM.
Supozoni se dĂ«shironi tĂ« kontrolloni aksesin nĂ« ndĂ«rfaqet SVI tĂ« Cisco Catalyst 4500. Pastaj, siç tregohet nĂ« , pĂ«r tĂ« kontrolluar trafikun e daljes (ashtu si dhe atĂ« tĂ« ardhjes) nĂ« ndĂ«rfaqet, mund tĂ« pĂ«rdorni vetĂ«m 4096 rreshta TCAM. Kjo, duke pĂ«rdorur TCAM3, do tâju japĂ« rreth 4000 ACE (rreshta ACL).
NĂ« rast se pĂ«rballeni me njĂ« problem tĂ« TCAM-it tĂ« pamjaftueshĂ«m, e para qĂ« duhet tĂ« shqyrtoni Ă«shtĂ« optimizimi. Pra, nĂ« rastin e njĂ« problemi me madhĂ«sinĂ« e TabelĂ«s sĂ« DĂ«rgimit, konsideroni konsolidimin e rrugĂ«ve. NĂ«se keni njĂ« problem me madhĂ«sinĂ« e TCAM-it pĂ«r akseset â duhet tĂ« bĂ«ni njĂ« auditim tĂ« aksesit, tĂ« fshini regjistrimet e vjetra dhe tĂ« mbivendosura, si dhe ndoshta tĂ« rishikoni procedurĂ«n e hapjes sĂ« aksesit (do tĂ« diskutohet nĂ« detaje nĂ« kapitullin e dedikuar auditimit tĂ« aksesit).
Disponibilitet i Lartë
Pyetja është, a duhet të përdorim HA për firewalls apo të vendosim dy kutia të pavarura "paralel" dhe në rast se njëra bie, të drejtojmë trafikun përmes tjetrës?
Duket e qartë, duhet të përdorim HA. Arsyetimi pse kjo pyetje ngrihet megjithatë është se, për fat të keq, teorikisht dhe në reklama 99 e disa nëntësh prapa presjes për disponueshmërinë shpesh rezultojnë të jenë shumë më pak rozë në praktikë. HA është një mekanizëm mjaft kompleks nga pikëpamja logjike, dhe me pajisje të ndryshme e me prodhues të ndryshëm (nuk ka përjashtime) kemi hasur në probleme, defekte dhe ndalime shërbimi.
Me përdorimin e HA, do të keni mundësinë të fikni nodet e veçanta dhe të kaloni midis tyre pa ndalur shërbimin, që është e rëndësishme, për shembull, gjatë përditësimeve. Megjithatë, ka një probabilitet jo të vogël që të dështojnë të dy nodet njëkohësisht, si dhe që përditësimi i ardhshëm të mos shkojë aq mirë sa premton shitësi (këtë problem mund ta evitoni nëse keni mundësinë të testoni përditësimin në pajisje laboratorike).
Nëse nuk përdorni HA, rreziku juaj për dështim të dyfishtë është ndjeshëm më i ulët (pasi keni 2Firewall të pavarur), por për shkak se sesionet nuk janë të sinkronizuara, çdo herë që ndodh kalimi midis këtyre firewalleve, do të humbni trafik. Natyrisht, mund të përdorni firewall të paqëndrueshëm, por kështu qëllimi i përdorimit të firewalit në shumë aspekte humbet.
Pra anda, nëse gjatë auditimit keni gjetur firewalls të veçanta dhe po mendoni për rritjen e besueshmërisë së rrjetit tuaj, atëherë HA është sigurisht një nga zgjidhjet e rekomanduara, por duhet të merrni parasysh edhe disavantazhet që lidhen me këtë qasje, dhe ndoshta një zgjidhje tjetër do të ishte më e përshtatshme për rrjetin tuaj.
Lehtësia e menaxhimit
Përgjithësisht, HA përfshin gjithashtu menaxhueshmërinë. Në vend të konfigurimit të dy kutive ndaras dhe zgjidhjes së problemit të sinkronizimit të konfigurimeve, ju i menaxhoni ato në një masë të tillë siç do të kishit një pajisje të vetme.
Por ndoshta keni shumë qendra të të dhënave dhe shumë firewalls, atëherë kjo çështje del në një nivel të ri. Dhe çështja nuk është vetëm për konfigurimin, por gjithashtu për
- backup-i i konfigurimeve
- dokumentimet
- përmirësimet
- monitorimin
- logimin
Dhe të gjitha këto mund të zgjidhen nga sistemet e menaxhimit qendror.
Kështu, për shembull, nëse përdorni firewalls Palo Alto, atëherë është një zgjidhje e tillë.
Vazhdon.
Burimi: habr.com
