Ky artikull është i treti në serinë e artikujve "Si të merrni kontrollin e infrastrukturës së rrjetit tuaj". Përmbajtja e të gjithë artikujve në seri dhe lidhjet mund të gjenden .
Nuk ka kuptim të flasim për eliminimin e plotë të rreziqeve të sigurisë. Në parim, ne nuk mund t'i zvogëlojmë ato në zero. Ne gjithashtu duhet të kuptojmë se ndërsa përpiqemi ta bëjmë rrjetin gjithnjë e më të sigurt, zgjidhjet tona po bëhen gjithnjë e më të shtrenjta. Ju duhet të gjeni një shkëmbim ndërmjet kostos, kompleksitetit dhe sigurisë që ka kuptim për rrjetin tuaj.
Sigurisht, dizajni i sigurisë është i integruar organikisht në arkitekturën e përgjithshme dhe zgjidhjet e sigurisë të përdorura ndikojnë në shkallëzueshmërinë, besueshmërinë, menaxhueshmërinë, ... të infrastrukturës së rrjetit, të cilat gjithashtu duhet të merren parasysh.
Por më lejoni t'ju kujtoj se tani nuk po flasim për krijimin e një rrjeti. Sipas tonë ne kemi zgjedhur tashmë dizajnin, kemi zgjedhur pajisjet dhe kemi krijuar infrastrukturën dhe në këtë fazë, nëse është e mundur, duhet të “jetojmë” dhe të gjejmë zgjidhje në kontekstin e qasjes së zgjedhur më parë.
Detyra jonë tani është të identifikojmë rreziqet që lidhen me sigurinë në nivel rrjeti dhe t'i reduktojmë ato në një nivel të arsyeshëm.
Auditimi i sigurisë së rrjetit
Nëse organizata juaj ka zbatuar procese ISO 27k, atëherë auditimet e sigurisë dhe ndryshimet e rrjetit duhet të përshtaten pa probleme në proceset e përgjithshme brenda kësaj qasjeje. Por këto standarde nuk kanë të bëjnë ende me zgjidhje specifike, as me konfigurim, as me dizajn... Nuk ka këshilla të qarta, nuk ka standarde që diktojnë në detaje se si duhet të jetë rrjeti juaj, ky është kompleksiteti dhe bukuria e kësaj detyre.
Do të nënvizoja disa auditime të mundshme të sigurisë së rrjetit:
- auditimi i konfigurimit të pajisjeve (forcim)
- auditimi i dizajnit të sigurisë
- auditimi i aksesit
- auditimi i procesit
Auditimi i konfigurimit të pajisjeve (forcim)
Duket se në shumicën e rasteve kjo është pikënisja më e mirë për auditimin dhe përmirësimin e sigurisë së rrjetit tuaj. IMHO, ky është një demonstrim i mirë i ligjit të Paretos (20% e përpjekjes prodhon 80% të rezultatit, dhe 80% e mbetur e përpjekjes prodhon vetëm 20% të rezultatit).
Në fund të fundit, ne zakonisht kemi rekomandime nga shitësit në lidhje me "praktikat më të mira" për sigurinë gjatë konfigurimit të pajisjeve. Kjo quhet "ngurtësim".
Ju gjithashtu mund të gjeni shpesh një pyetësor (ose ta krijoni vetë) bazuar në këto rekomandime, i cili do t'ju ndihmojë të përcaktoni se sa mirë përputhet konfigurimi i pajisjeve tuaja me këto "praktika më të mira" dhe, në përputhje me rezultatin, të bëni ndryshime në rrjetin tuaj. . Kjo do t'ju lejojë të reduktoni ndjeshëm rreziqet e sigurisë mjaft lehtë, praktikisht pa kosto.
Disa shembuj për disa sisteme operative Cisco.
Bazuar në këto dokumente, mund të krijohet një listë e kërkesave të konfigurimit për çdo lloj pajisjeje. Për shembull, për një Cisco N7K VDC këto kërkesa mund të duken .
Në këtë mënyrë, skedarët e konfigurimit mund të krijohen për lloje të ndryshme të pajisjeve aktive në infrastrukturën e rrjetit tuaj. Më pas, manualisht ose duke përdorur automatizimin, mund t'i "ngarkoni" këta skedarë konfigurimi. Si të automatizoni këtë proces do të diskutohet në detaje në një seri tjetër artikujsh mbi orkestrimin dhe automatizimin.
Auditimi i dizajnit të sigurisë
Në mënyrë tipike, një rrjet ndërmarrjesh përmban segmentet e mëposhtme në një formë ose në një tjetër:
- DC (Shërbimet publike DMZ dhe qendra e të dhënave Intranet)
- Hyrje në internet
- VPN me qasje në distancë
- buzë WAN
- Degë
- Kampusi (Zyra)
- Bërthamë
Titujt e marrë nga model, por nuk është e nevojshme, natyrisht, t'i bashkëngjitet pikërisht këtyre emrave dhe këtij modeli. Megjithatë, dua të flas për thelbin dhe të mos zhytem në formalitete.
Për secilin prej këtyre segmenteve, kërkesat e sigurisë, rreziqet dhe, në përputhje me rrethanat, zgjidhjet do të jenë të ndryshme.
Le të shohim secilën prej tyre veç e veç për problemet që mund të hasni nga pikëpamja e dizajnit të sigurisë. Natyrisht, e përsëris sërish se në asnjë mënyrë ky artikull nuk pretendon të jetë i plotë, gjë që nuk është e lehtë (nëse jo e pamundur) të arrihet në këtë temë vërtet të thellë dhe të shumëanshme, por pasqyron përvojën time personale.
Nuk ka zgjidhje perfekte (të paktën jo ende). Është gjithmonë një kompromis. Por është e rëndësishme që vendimi për të përdorur një qasje ose një tjetër të merret me vetëdije, duke kuptuar të mirat dhe të këqijat e saj.
Qendra e të dhënave
Segmenti më kritik nga pikëpamja e sigurisë.
Dhe, si zakonisht, as këtu nuk ka zgjidhje universale. E gjitha varet shumë nga kërkesat e rrjetit.
A është i nevojshëm një mur zjarri apo jo?
Duket se përgjigjja është e qartë, por gjithçka nuk është aq e qartë sa mund të duket. Dhe zgjedhja juaj mund të ndikohet jo vetëm çmim.
Shembull 1. Vonesat.
Nëse vonesa e ulët është një kërkesë thelbësore midis disa segmenteve të rrjetit, e cila është, për shembull, e vërtetë në rastin e një shkëmbimi, atëherë ne nuk do të jemi në gjendje të përdorim muret e zjarrit midis këtyre segmenteve. Është e vështirë të gjesh studime mbi vonesën në muret e zjarrit, por pak modele switch mund të ofrojnë vonesë më të vogël se ose në rendin e 1 mksec, kështu që mendoj se nëse mikrosekonda janë të rëndësishme për ju, atëherë muret e zjarrit nuk janë për ju.
Shembull 2. Performanca.
Produktiviteti i ndërprerësve të lartë L3 është zakonisht një rend i madhësisë më i lartë se xhiroja e mureve më të fuqishme të zjarrit. Prandaj, në rastin e trafikut me intensitet të lartë, me shumë gjasa do t'ju duhet të lejoni që ky trafik të anashkalojë muret e zjarrit.
Shembull 3. Besueshmëria.
Firewall-et, veçanërisht NGFW moderne (Next-Generation FW) janë pajisje komplekse. Ata janë shumë më kompleks se çelsin L3/L2. Ato ofrojnë një numër të madh shërbimesh dhe opsionesh konfigurimi, kështu që nuk është për t'u habitur që besueshmëria e tyre është shumë më e ulët. Nëse vazhdimësia e shërbimit është kritike për rrjetin, atëherë mund t'ju duhet të zgjidhni atë që do të çojë në disponueshmëri më të mirë - sigurinë me një mur zjarri ose thjeshtësinë e një rrjeti të ndërtuar mbi ndërprerës (ose lloje të ndryshme të pëlhurave) duke përdorur ACL të rregullta.
Në rastin e shembujve të mësipërm, me shumë mundësi (si zakonisht) do t'ju duhet të gjeni një kompromis. Shikoni drejt zgjidhjeve të mëposhtme:
- nëse vendosni të mos përdorni mure zjarri brenda qendrës së të dhënave, atëherë duhet të mendoni se si të kufizoni sa më shumë aksesin rreth perimetrit. Për shembull, mund të hapni vetëm portat e nevojshme nga Interneti (për trafikun e klientit) dhe aksesin administrativ në qendrën e të dhënave vetëm nga hostet e kërcimit. Në hostet e kërcimit, kryeni të gjitha kontrollet e nevojshme (autentifikimi/autorizimi, antivirus, regjistrimi, ...)
- ju mund të përdorni një ndarje logjike të rrjetit të qendrës së të dhënave në segmente, të ngjashme me skemën e përshkruar në PSEFABRIC . Në këtë rast, rutimi duhet të konfigurohet në atë mënyrë që trafiku i ndjeshëm ndaj vonesave ose me intensitet të lartë të shkojë "brenda" një segmenti (në rastin e p002, VRF) dhe të mos kalojë përmes murit të zjarrit. Trafiku ndërmjet segmenteve të ndryshme do të vazhdojë të kalojë përmes murit të zjarrit. Ju gjithashtu mund të përdorni rrjedhjen e rrugës midis VRF-ve për të shmangur ridrejtimin e trafikut përmes murit të zjarrit
- Ju gjithashtu mund të përdorni një mur zjarri në modalitetin transparent dhe vetëm për ato VLAN ku këta faktorë (latenca/performanca) nuk janë të rëndësishme. Por ju duhet të studioni me kujdes kufizimet që lidhen me përdorimin e këtij mod për secilin shitës
- ju mund të dëshironi të konsideroni përdorimin e një arkitekture zinxhiri shërbimi. Kjo do të lejojë që vetëm trafiku i nevojshëm të kalojë përmes murit të zjarrit. Duket bukur në teori, por nuk e kam parë kurrë këtë zgjidhje në prodhim. Ne testuam zinxhirin e shërbimit për Cisco ACI/Juniper SRX/F5 LTM rreth 3 vjet më parë, por në atë kohë kjo zgjidhje na dukej "e papërpunuar".
Niveli i mbrojtjes
Tani ju duhet t'i përgjigjeni pyetjes se cilat mjete dëshironi të përdorni për të filtruar trafikun. Këtu janë disa nga veçoritë që janë zakonisht të pranishme në NGFW (për shembull, ):
- muri i zjarrit shtetëror (i parazgjedhur)
- muri i zjarrit i aplikacionit
- parandalimi i kërcënimeve (antivirus, anti-spyware dhe cenueshmëria)
- Filtrimi i URL-ve
- filtrimi i të dhënave (filtrimi i përmbajtjes)
- bllokimi i skedarëve (bllokimi i llojeve të skedarëve)
- mbrojtje dos
Dhe jo gjithçka është gjithashtu e qartë. Duket se sa më i lartë të jetë niveli i mbrojtjes, aq më mirë. Por ju gjithashtu duhet ta konsideroni atë
- Sa më shumë nga funksionet e mësipërme të firewall-it të përdorni, aq më i shtrenjtë do të jetë natyrisht (licenca, module shtesë)
- përdorimi i disa algoritmeve mund të zvogëlojë ndjeshëm kapacitetin e firewall-it dhe gjithashtu të rrisë vonesat, shih për shembull
- si çdo zgjidhje komplekse, përdorimi i metodave komplekse të mbrojtjes mund të zvogëlojë besueshmërinë e zgjidhjes suaj, për shembull, kur përdorni murin e zjarrit të aplikacionit, kam hasur në bllokimin e disa aplikacioneve të punës mjaft standarde (dns, smb)
Si gjithmonë, ju duhet të gjeni zgjidhjen më të mirë për rrjetin tuaj.
Është e pamundur t'i përgjigjemi pa mëdyshje pyetjes se cilat funksione mbrojtëse mund të kërkohen. Së pari, sepse sigurisht që varet nga të dhënat që po transmetoni ose ruani dhe po përpiqeni t'i mbroni. Së dyti, në realitet, shpesh zgjedhja e mjeteve të sigurisë është çështje besimi dhe besimi te shitësi. Ju nuk i njihni algoritmet, nuk e dini sa efektive 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ë murin e zjarrit, por gjithashtu të përdorni mbrojtjen antivirus (nga një prodhues tjetër) në nivel lokal në hostet.
Segmentimi
Po flasim për segmentimin logjik të rrjetit të qendrës së të dhënave. Për shembull, ndarja në VLAN dhe nënrrjeta është gjithashtu një segmentim logjik, por ne nuk do ta konsiderojmë atë për shkak të qartësisë së tij. Segmentim interesant duke marrë parasysh entitete të tilla si zonat e sigurisë FW, VRF (dhe analogët e tyre në lidhje me shitës të ndryshëm), pajisjet logjike (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...
Një shembull i një segmentimi të tillë logjik dhe dizajni aktualisht i kërkuar i qendrës së të dhënave është dhënë në .
Pasi të keni përcaktuar pjesët logjike të rrjetit tuaj, më pas mund të përshkruani se si lëviz trafiku midis segmenteve të ndryshme, në cilat pajisje do të kryhet filtrimi dhe me çfarë mjetesh.
Nëse rrjeti juaj nuk ka një ndarje të qartë logjike dhe rregullat për aplikimin e politikave të sigurisë për rrjedhat e ndryshme të të dhënave nuk janë të zyrtarizuara, kjo do të thotë që kur hapni këtë apo atë akses, jeni të detyruar ta zgjidhni këtë problem, dhe me një probabilitet të lartë ju do ta zgjidhë çdo herë ndryshe.
Shpesh segmentimi bazohet vetëm në zonat e sigurisë FW. Atëherë duhet t'u përgjigjeni pyetjeve të mëposhtme:
- 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 brenda zonës si parazgjedhje?
- nëse jo, cilat politika të filtrimit të trafikut do të zbatohen brenda secilës zonë
- cilat politika të filtrimit të trafikut do të zbatohen për secilën palë zona (burimi/destinacioni)
TCAM
Një problem i zakonshëm është pamjaftueshmëria e TCAM (Ternary Content Addressable Memory), si për rrugëtimin ashtu edhe për akseset. IMHO, kjo është një nga çështjet më të rëndësishme kur zgjidhni pajisje, kështu që ju duhet ta trajtoni këtë çështje me shkallën e duhur të kujdesit.
Shembull 1. Tabela e përcjelljes TCAM.
Le të hedhim një vështrim muri i zjarrit
Ne shohim se madhësia e tabelës së përcjelljes IPv4* = 32K
Për më tepër, ky numër rrugësh është i zakonshëm për të gjitha VSYS-të.Le të supozojmë se sipas dizajnit tuaj ju vendosni të përdorni 4 VSYS.
Secila prej këtyre VSYS-ve është e lidhur nëpërmjet BGP me dy MPLS PE të cloud që përdorni si BB. Kështu, 4 VSYS shkëmbejnë të gjitha rrugët specifike me njëra-tjetrën dhe kanë një tabelë përcjellëse me grupe afërsisht të njëjta rrugësh (por NH të ndryshme). Sepse çdo VSYS ka 2 seanca BGP (me të njëjtat cilësime), pastaj çdo rrugë e marrë nëpërmjet MPLS ka 2 NH dhe, në përputhje me rrethanat, 2 hyrje FIB në Tabelën e Përcjelljes. Nëse supozojmë se ky është i vetmi firewall në qendrën e të dhënave dhe duhet të dijë për të gjitha rrugët, atëherë kjo do të thotë që numri i përgjithshëm 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ë dhënash (me të njëjtin dizajn) dhe duam të përdorim VLAN të "shtrirë" midis qendrave të të dhënave (për shembull, për vMotion), atëherë për të zgjidhur problemin e rrugëzimit, duhet të përdorim rrugët e hostit. . Por kjo do të thotë që për 2 qendra të dhënash nuk do të kemi më shumë se 4096 hoste të mundshëm dhe, natyrisht, kjo mund të mos jetë e mjaftueshme.
Shembull 2. ACL TCAM.
Nëse planifikoni të filtroni trafikun në çelsat L3 (ose zgjidhje të tjera që përdorin çelsat L3, për shembull, Cisco ACI), atëherë kur zgjidhni pajisje duhet t'i kushtoni vëmendje TCAM ACL.
Supozoni se doni të kontrolloni aksesin në ndërfaqet SVI të Cisco Catalyst 4500. Më pas, siç mund të shihet nga , për të kontrolluar trafikun dalës (si dhe në hyrje) në ndërfaqet, mund të përdorni vetëm 4096 linja TCAM. E cila kur përdorni TCAM3 do t'ju japë rreth 4000 mijë ACE (linja ACL).
Nëse jeni përballur me problemin e TCAM të pamjaftueshme, atëherë, para së gjithash, natyrisht, duhet të merrni parasysh mundësinë e optimizimit. Pra, në rast të një problemi me madhësinë e Tabelës së Përcjelljes, duhet të keni parasysh mundësinë e grumbullimit të rrugëve. Në rast problemi me madhësinë e TCAM-së për akseset, akseset e auditimit, hiqni të dhënat e vjetruara dhe të mbivendosura dhe mundësisht rishikoni procedurën për hapjen e akseseve (do të diskutohet në detaje në kapitullin mbi akseset e auditimit).
Disponueshmëri e lartë
Pyetja është: a duhet të përdor HA për muret e zjarrit apo të instaloj dy kuti të pavarura "paralelisht" dhe, nëse njëra prej tyre dështon, të drejtoj trafikun përmes të dytës?
Duket se përgjigjja është e qartë - përdorni HA. Arsyeja pse kjo pyetje lind ende është se, për fat të keq, përqindjet teorike dhe reklamuese 99 dhe disa dhjetore të aksesueshmërisë në praktikë rezultojnë të jenë aspak rozë. HA është logjikisht një gjë mjaft komplekse, dhe në pajisje të ndryshme, dhe me shitës të ndryshëm (nuk kishte përjashtime), ne kapëm probleme dhe defekte dhe ndalesa të shërbimit.
Nëse përdorni HA, do të keni mundësinë të fikni nyjet individuale, të kaloni midis tyre pa ndërprerë shërbimin, gjë që është e rëndësishme, për shembull, kur bëni përmirësime, por në të njëjtën kohë keni një probabilitet larg zero që të dy nyjet do të prishet në të njëjtën kohë, dhe gjithashtu që përmirësimi i ardhshëm nuk do të shkojë aq mirë sa premton shitësi (ky problem mund të shmanget nëse keni mundësinë të provoni përmirësimin në pajisjet laboratorike).
Nëse nuk përdorni HA, atëherë nga pikëpamja e dështimit të dyfishtë, rreziqet tuaja janë shumë më të ulëta (pasi keni 2 mure zjarri të pavarur), por meqë... seancat nuk sinkronizohen, atëherë sa herë që kaloni midis këtyre mureve të zjarrit do të humbni trafikun. Sigurisht, ju mund të përdorni murin e zjarrit pa shtetësi, por atëherë kuptimi i përdorimit të një muri zjarri humbet kryesisht.
Prandaj, nëse si rezultat i auditimit keni zbuluar mure zjarri të vetmuar dhe po mendoni të rrisni besueshmërinë e rrjetit tuaj, atëherë HA, natyrisht, është një nga zgjidhjet e rekomanduara, por duhet të keni parasysh edhe disavantazhet që lidhen me të. me këtë qasje dhe, ndoshta, veçanërisht për rrjetin tuaj, një zgjidhje tjetër do të ishte më e përshtatshme.
Menaxhimi
Në parim, HA ka të bëjë gjithashtu me kontrollueshmërinë. Në vend që të konfiguroni 2 kuti veç e veç dhe të merreni me problemin e mbajtjes së konfigurimeve në sinkron, ju i menaxhoni ato njësoj sikur të kishit një pajisje.
Por ndoshta keni shumë qendra të dhënash dhe shumë mure zjarri, atëherë kjo pyetje lind në një nivel të ri. Dhe pyetja nuk është vetëm për konfigurimin, por edhe për
- konfigurimet rezervë
- përditësimet
- përmirësimet
- monitorimi
- prerjet
Dhe e gjithë kjo mund të zgjidhet nga sistemet e centralizuara të menaxhimit.
Kështu, për shembull, nëse përdorni muret e zjarrit Palo Alto, atëherë është një zgjidhje e tillë.
Të vazhdohet.
Burimi: www.habr.com