Artikulu hau "Nola hartu zure sareko azpiegituraren kontrola" artikulu sorta bateko hirugarrena da. Serieko artikulu guztien edukia eta estekak aurki daitezke Hemen.

Ez du balio segurtasun arriskuak guztiz ezabatzeaz hitz egiteak. Printzipioz, ezin ditugu zerora murriztu. Gainera, ulertu behar dugu sarea gero eta seguruagoa izaten ahalegintzen garen heinean, gure irtenbideak gero eta garestiagoak direla. Zure sarerako zentzuzkoa den kostuaren, konplexutasunaren eta segurtasunaren arteko truke-off bat aurkitu behar duzu.

Jakina, segurtasun-diseinua arkitektura orokorrean organikoki integratuta dago eta erabiltzen diren segurtasun-soluzioek sare-azpiegituren eskalagarritasunari, fidagarritasunari, kudeagarritasunari... eragiten diote, eta hori ere kontuan hartu behar da.

Baina gogorarazten dizut orain ez garela sare bat sortzeaz ari. Gure arabera hasierako baldintzak dagoeneko aukeratu dugu diseinua, ekipoak hautatu eta azpiegiturak sortu, eta fase honetan, ahal bada, aurretik aukeratutako ikuspegiaren testuinguruan “bizi” eta irtenbideak bilatu beharko genituzke.

Gure zeregina orain sare mailan segurtasunarekin lotutako arriskuak identifikatzea eta arrazoizko maila batera murriztea da.

Sareko segurtasun auditoria

Zure erakundeak ISO 27k prozesuak inplementatu baditu, segurtasun-ikuskaritzak eta sare-aldaketak modu egokian sartu beharko lirateke ikuspegi honen prozesu orokorretan. Baina estandar hauek oraindik ez dira irtenbide zehatzei buruzkoak, ez konfigurazioari buruzkoak, ez diseinuari buruzkoak... Ez dago aholku argirik, ez dago zure sarea nolakoa izan behar duen zehatz-mehatz zehazten duen estandarrik, hau da zeregin honen konplexutasuna eta edertasuna.

Sareko segurtasun auditoria posible batzuk nabarmenduko nituzke:

• ekipoen konfigurazio auditoria (gogortzea)
• segurtasun diseinuaren auditoria
• sarbide auditoria
• prozesuen auditoria

Ekipoen konfigurazio auditoria (gogortzea)

Badirudi kasu gehienetan hori dela zure sarearen segurtasuna ikuskatzeko eta hobetzeko abiapuntu onena. Nire ustez, hau Paretoren legearen erakusgarri ona da (esfortzuaren % 20k emaitzaren % 80 sortzen du, eta esfortzuaren gainerako % 80ak emaitzaren % 20 baino ez du).

Ondorioz, ekipamenduak konfiguratzean segurtasunerako "jardunbide onenei" buruzko saltzaileen gomendioak ditugu normalean. Horri "gogortzea" deitzen zaio.

Gomendio hauetan oinarritutako galdetegi bat ere aurki dezakezu (edo zuk zeuk sortu), eta horrek zure ekipoaren konfigurazioak "praktika onen" hauekin zenbateraino betetzen dituen zehazten lagunduko dizu eta, emaitzaren arabera, zure sarean aldaketak egiten lagunduko dizu. . Horrek segurtasun-arriskuak nabarmen murrizteko aukera emango dizu nahiko erraz, ia kosturik gabe.

Cisco sistema eragile batzuen zenbait adibide.

Cisco IOS konfigurazioa gogortzea
Cisco IOS-XR konfigurazioa gogortzea
Cisco NX-OS konfigurazioa gogortzea
Cisco Baseline Security Check Zerrenda

Dokumentu horietan oinarrituta, ekipo mota bakoitzerako konfigurazio-eskakizunen zerrenda sor daiteke. Esate baterako, Cisco N7K VDC batentzat eskakizun hauek izan daitezke beraz,.

Modu honetan, zure sare-azpiegiturako ekipamendu aktibo mota desberdinetarako konfigurazio-fitxategiak sor daitezke. Ondoren, eskuz edo automatizazioa erabiliz, konfigurazio fitxategi hauek "kargatu" ditzakezu. Prozesu hau nola automatizatu xehetasunez eztabaidatuko da orkestrazioari eta automatizazioari buruzko beste artikulu sorta batean.

Segurtasun diseinuaren auditoria

Normalean, enpresa-sare batek segmentu hauek ditu forma batean edo bestean:

• DC (Zerbitzu publikoen DMZ eta Intranet datu-zentroa)
• Internet sarbidea
• Urruneko sarbidea VPN
• WAN ertza
• Adarra
• Campusa (bulegoa)
• Core

Hemendik hartutako tituluak Cisco SEGURUA eredua, baina ez da beharrezkoa, noski, izen horiei eta eredu honi zehazki lotzea. Hala ere, esentziari buruz hitz egin nahi dut eta ez izapideetan nahastu.

Segmentu horietako bakoitzerako, segurtasun-eskakizunak, arriskuak eta, horren arabera, irtenbideak desberdinak izango dira.

Ikus ditzagun horietako bakoitza bereizita segurtasunaren diseinuaren ikuspuntutik aurki ditzakezun arazoei buruz. Noski, berriro errepikatzen dut artikulu honek ez duela inola ere osatua denik, gai benetan sakon eta polifazetiko honetan lortzea ez dena erraza (ez bada ezinezkoa), baina nire esperientzia pertsonala islatzen du.

Ez dago irtenbide perfekturik (oraindik ez behintzat). Konpromiso bat da beti. Baina garrantzitsua da ikuspegi bat edo beste erabiltzeko erabakia kontzienteki hartzea, alde onak eta txarrak ulertuta.

Datu zentroa

Segmenturik kritikoena segurtasunaren ikuspuntutik.
Eta, ohi bezala, hemen ere ez dago irtenbide unibertsala. Sarearen eskakizunen araberakoa da guztia.

Suebaki bat beharrezkoa da ala ez?

Erantzuna begi-bistakoa dela dirudi, baina dena ez dago dirudien bezain argi. Eta zure aukeran eragina izan daiteke ez bakarrik prezioa.

Adibidea 1. Atzerapenak.

Sareko segmentu batzuen artean latentzia baxua ezinbesteko baldintza bada, truke baten kasuan adibidez, egia dena, orduan ezingo dugu segmentu horien arteko suebakirik erabili. Zaila da suebakietan latentziari buruzko azterketak aurkitzea, baina switch-eredu gutxik 1 mkseg baino gutxiagoko latentzia eman dezakete, beraz, uste dut mikrosegundoak zuretzako garrantzitsuak badira, orduan suebakiak ez direla zuretzat.

Adibidea 2. Emanaldia.

Goiko L3 etengailuen errendimendua suebaki indartsuenen errendimendua baino magnitude ordena handiagoa izan ohi da. Hori dela eta, intentsitate handiko trafikoaren kasuan, ziurrenik trafiko horri suebakiak saihesteko baimena eman beharko diozu ere.

Adibidea 3. Fidagarritasuna.

Suebakiak, batez ere NGFW modernoa (Next-Generation FW) gailu konplexuak dira. L3/L2 etengailuak baino askoz konplexuagoak dira. Zerbitzu eta konfigurazio aukera ugari eskaintzen dituzte, beraz, ez da harritzekoa haien fidagarritasuna askoz txikiagoa izatea. Zerbitzuaren jarraitasuna sarerako funtsezkoa bada, baliteke erabilgarritasun hobea ekarriko duena aukeratu behar izatea: suebaki batekin segurtasuna edo ACL arruntak erabiliz etengailuetan (edo hainbat ehun motatan) eraikitako sare baten sinpletasuna.

Goiko adibideen kasuan, ziurrenik (ohi bezala) konpromiso bat aurkitu beharko duzu. Begiratu irtenbide hauei:

• Datu-zentroaren barruan suebakirik ez erabiltzea erabakitzen baduzu, perimetroaren inguruan sarbidea ahalik eta gehien mugatu pentsatu behar duzu. Adibidez, Internetetik (bezeroen trafikorako) beharrezkoak diren atakak soilik ireki ditzakezu eta datu-zentrorako administrazio-sarbidea jump ostalarietatik soilik. Jump ostalarietan, egin beharrezko egiaztapen guztiak (autentifikazioa/baimena, birusen aurkakoa, erregistroa, ...)
• datu-zentroaren sarearen partizio logiko bat segmentuetan erabil dezakezu, PSEFABRIC-en deskribatutako eskemaren antzera p002 adibidea. Kasu honetan, bideratzea modu horretan konfiguratu behar da atzerapenarekiko sentikorra den edo intentsitate handiko trafikoa "segmentu baten barruan" joan dadin (p002, VRF kasuan) eta suebakitik igaro ez dadin. Segmentu ezberdinen arteko trafikoak suebakitik jarraituko du. VRFen arteko ibilbide-filtrazioa ere erabil dezakezu trafikoa suebakitik birbideratzeko
• Suebaki bat ere erabil dezakezu modu gardenean eta faktore hauek (latentzia/errendimendua) esanguratsuak ez diren VLANetarako soilik. Baina arretaz aztertu behar dituzu mod honen erabilerarekin lotutako murrizketak saltzaile bakoitzarentzat
• baliteke zerbitzu-katearen arkitektura erabiltzea kontuan hartzea. Horri esker, beharrezkoa den trafikoa soilik igaroko da suebakitik. Teorian polita dirudi, baina produkzioan ez dut inoiz irtenbide hau ikusi. Duela 5 urte inguru probatu genuen Cisco ACI/Juniper SRX/F3 LTM-ren zerbitzu-katea, baina garai hartan irtenbide hau "gordina" iruditu zitzaigun.

Babes maila

Orain trafikoa iragazteko zer tresna erabili nahi dituzun galderari erantzun behar diozu. Hona hemen NGFW-n egon ohi diren ezaugarri batzuk (adibidez, Hemen):

• egoera-suebakia (lehenetsia)
• aplikazioen suebakia
• mehatxuen prebentzioa (birusen aurkakoa, espioiaren aurkakoa eta ahultasuna)
• URL iragaztea
• datuen iragazketa (edukiaren iragazketa)
• fitxategiak blokeatzea (fitxategi motak blokeatzea)
• dos babesa

Eta dena ere ez dago argi. Badirudi zenbat eta babes maila handiagoa izan, orduan eta hobeto. Baina hori ere kontuan hartu behar duzu

• Zenbat eta goiko suebaki-funtzio gehiago erabili, orduan eta garestiagoa izango da (lizentzia, modulu osagarriak)
• algoritmo batzuen erabilerak suebakiaren transmisioa nabarmen murrizten du eta, gainera, atzerapenak areagotu ditzake, ikus adibidez Hemen
• edozein irtenbide konplexu bezala, babes-metodo konplexuak erabiltzeak zure soluzioaren fidagarritasuna murrizten du, adibidez, aplikazioen suebakia erabiltzean, nahiko estandarizatutako laneko aplikazio batzuen blokeoa aurkitu dut (dns, smb).

Beti bezala, zure sarerako irtenbiderik onena bilatu behar duzu.

Ezinezkoa da behin betiko erantzun zein babes-funtzio eska daitezkeen galderari. Lehenik eta behin, noski transmititzen edo gordetzen eta babesten saiatzen ari zaren datuen araberakoa delako. Bigarrenik, errealitatean, askotan segurtasun-tresnak aukeratzea saltzailearekiko fedea eta konfiantza kontua da. Ez dakizu algoritmoak, ez dakizu zein eraginkorrak diren eta ezin dituzu guztiz probatu.

Horregatik, segmentu kritikoetan, irtenbide ona izan daiteke enpresa ezberdinen eskaintzak erabiltzea. Adibidez, suebakian birusen aurkakoa gaitu dezakezu, baina birusen aurkako babesa ere erabil dezakezu (beste fabrikatzaile batena) lokalean ostalarietan.

Segmentazioa

Datu zentroen sarearen segmentazio logikoaz ari gara. Adibidez, VLAN eta azpisareetan partitzea ere segmentazio logikoa da, baina ez dugu kontuan hartuko bere agerikotasuna dela eta. Segmentazio interesgarria FW segurtasun-eremuak, VRFak (eta haien analogoak hainbat saltzailerekin lotuta), gailu logikoak (PA VSYS, Cisco N7K VDC, Cisco ACI maizterrak, ...), ...

Segmentazio logikoaren eta gaur egun eskatzen den datu-zentroaren diseinuaren adibide bat ematen da PSEFABRIC proiektuaren p002.

Zure sarearen atal logikoak definitu ondoren, trafikoa segmentu ezberdinen artean nola mugitzen den deskriba dezakezu, zein gailutan egingo den iragazketa eta zein bidetan.

Zure sareak ez badu partizio logiko argirik eta datu-fluxu ezberdinetarako segurtasun-politikak aplikatzeko arauak formalizatuta ez badaude, horrek esan nahi du sarbide hau edo beste irekitzen duzunean arazo hau konpontzera behartuta zaudela, eta probabilitate handiarekin aldi bakoitzean modu ezberdinean konponduko du.

Askotan segmentazioa FW segurtasun guneetan soilik oinarritzen da. Ondoren, galdera hauei erantzun behar diezu:

• zer segurtasun gune behar dituzu
• zer babes-maila aplikatu nahi diozu gune horietako bakoitzean
• eremu barruko trafikoa lehenespenez onartuko al da?
• hala ez bada, zer trafikoa iragazteko politika aplikatuko den zona bakoitzaren barruan
• zer trafikoa iragazteko politikak aplikatuko diren zona bikote bakoitzean (iturria/helmuga)

TCAM

Ohiko arazo bat TCAM (Ternary Content Addressable Memory) nahikoa ez da, bai bideratzerako bai sarbideetarako. IMHO, hau da ekipamendua aukeratzerakoan arazo garrantzitsuenetako bat, beraz, arazo hau arreta-maila egokiarekin tratatu behar duzu.

1. adibidea. Birbidaltze-taula TCAM.

Ikus dezagun Palo Alto 7k suebakia
IPv4 birbidaltze-taularen tamaina* = 32K ikusten dugu
Gainera, ibilbide kopuru hori ohikoa da VSYS guztientzat.

Demagun zure diseinuaren arabera 4 VSYS erabiltzea erabakitzen duzula.
VSYS horietako bakoitza BGP bidez konektatzen da BB gisa erabiltzen dituzun hodeiko bi MPLS PErekin. Horrela, 4 VSYS-k ibilbide zehatz guztiak elkar trukatzen dituzte eta birbidaltze-taula bat dute, gutxi gorabehera, ibilbide multzo berdinekin (baina NH desberdinak). Zeren VSYS bakoitzak 2 BGP saio ditu (ezarpen berberekin), ondoren MPLS bidez jasotako ibilbide bakoitzak 2 NH ditu eta, horren arabera, 2 FIB sarrera Bidalketa Taulan. Suposatzen badugu datu-zentroko suebaki bakarra dela eta ibilbide guztiak ezagutu behar baditu, horrek esan nahi du gure datu-zentroko ibilbideen guztizko kopurua ezin dela 32K/(4 * 2) = 4K baino gehiago izan.

Orain, suposatzen badugu 2 datu-zentro ditugula (diseinu berdinarekin), eta datu-zentroen artean "hedatuta" VLANak erabili nahi baditugu (adibidez, vMotion-erako), bideratze-arazoa konpontzeko, ostalariaren ibilbideak erabili behar ditugu. . Baina horrek esan nahi du 2 datu-zentrotarako ez ditugula 4096 ostalari posible baino gehiago izango eta, noski, baliteke hori nahikoa ez izatea.

2. adibidea. ACL TCAM.

L3 etengailuetan trafikoa iragazteko asmoa baduzu (edo L3 etengailuak erabiltzen dituzten beste soluzio batzuk, adibidez, Cisco ACI), orduan ekipoak aukeratzerakoan arreta jarri beharko diozu TCAM ACLari.

Demagun Cisco Catalyst 4500-ren SVI interfazeetan sarbidea kontrolatu nahi duzula. Orduan, ikus daitekeen moduan. Artikulu hau, irteerako (baita sarrerako) trafikoa interfazeetan kontrolatzeko, 4096 TCAM linea soilik erabil ditzakezu. TCAM3 erabiltzean 4000 mila ACE inguru emango dizkizu (ACL lerro).

TCAM nahikoa ezaren arazoaren aurrean bazaude, lehenik eta behin, noski, optimizatzeko aukera kontuan hartu behar duzu. Beraz, Bidalketa Taularen tamainaren arazoren bat izanez gero, ibilbideak batzeko aukera kontuan hartu behar duzu. Sarbideetarako TCAM tamainarekin arazoren bat izanez gero, ikuskatu sarbideak, kendu erregistro zaharkituak eta gainjarritakoak, eta, agian, sarbideak irekitzeko prozedura berrikusi (sarrerak ikuskatzeko kapituluan zehatz-mehatz eztabaidatuko da).

Erabilgarritasun altua

Galdera hauxe da: HA erabili behar al dut suebakietarako edo bi kutxa independente instalatu "paraleloan" eta, horietako batek huts egiten badu, trafikoa bigarrenetik bideratu?

Erantzuna begi-bistakoa dela dirudi - erabili HA. Galdera hau oraindik sortzen den arrazoia da, zoritxarrez, 99 teoriko eta publizitateak eta praktikan irisgarritasun portzentaje hamartar batzuk hain arrosa izatetik urrun geratzen direla. HA logikoki gauza nahiko konplexua da, eta ekipamendu ezberdinetan eta saltzaile ezberdinekin (ez zegoen salbuespenik), arazoak eta akatsak eta zerbitzu geldialdiak harrapatu genituen.

HA erabiltzen baduzu, aukera izango duzu nodo indibidualak desaktibatzeko, haien artean aldatzeko zerbitzua eten gabe, eta hori garrantzitsua da, adibidez, bertsio berritzaileak egiterakoan, baina, aldi berean, bi nodoak izateko probabilitatea oso urrun dago. aldi berean hautsi egingo da, eta, gainera, hurrengoan bertsio berritzea ez da saltzaileak agintzen duen bezain ondo joango (arazo hau ekidin daiteke laborategiko ekipoetan bertsio berritzea probatzeko aukera izanez gero).

HA erabiltzen ez baduzu, porrot bikoitzaren ikuspuntutik zure arriskuak askoz txikiagoak dira (2 suebaki independente dituzunez), baina... saioak ez daude sinkronizatuta, orduan suebaki batetik bestera aldatzen zaren bakoitzean trafikoa galduko duzu. Noski, estaturik gabeko suebakia erabil dezakezu, baina gero suebaki bat erabiltzeko puntua galdu egiten da neurri handi batean.

Hori dela eta, auditoretzaren ondorioz suebaki bakartiak aurkitu badituzu eta zure sarearen fidagarritasuna areagotzea pentsatzen ari bazara, orduan HA da, noski, gomendatutako irtenbideetako bat, baina erlazionatutako desabantailak ere kontuan hartu beharko dituzu. ikuspegi honekin eta, agian, zure sarerako bereziki, beste irtenbide bat litzateke egokiagoa.

Kudeagarritasuna

Printzipioz, HA ere kontrolagarritasunari buruzkoa da. 2 koadro bereizi konfiguratu eta konfigurazioak sinkronizatuta mantentzeko arazoari aurre egin beharrean, gailu bat izango bazenu bezala kudeatzen dituzu.

Baina agian datu-zentro asko eta suebaki asko dituzu, orduan galdera hau maila berri batean sortzen da. Eta galdera ez da soilik konfigurazioari buruzkoa, baita ere

• babeskopia konfigurazioak
• eguneraketak
• berritzeak
• jarraipena
• erregistroa

Eta hori guztia kudeaketa sistema zentralizatuen bidez konpondu daiteke.

Beraz, adibidez, Palo Alto suebakiak erabiltzen ari bazara, orduan Ikusi halako irtenbide bat da.

Jarraitu behar da.

Iturria: www.habr.com