Ĉi tiu artikolo estas la tria en serio de artikoloj "Kiel Preni Kontrolon de Via Reta Infrastrukturo." La enhavo de ĉiuj artikoloj en la serio kaj ligiloj troveblas tie.

Ne utilas paroli pri tute forigo de sekurecaj riskoj. Principe, ni ne povas redukti ilin al nulo. Ni ankaŭ devas kompreni, ke dum ni klopodas por fari la reton pli kaj pli sekura, niaj solvoj fariĝas pli kaj pli multekostaj. Vi devas trovi interŝanĝon inter kosto, komplekseco kaj sekureco, kiu havas sencon por via reto.

Kompreneble, sekurecdezajno estas organike integrita en la ĝeneralan arkitekturon kaj la sekurecaj solvoj uzataj influas la skaleblon, fidindecon, administreblecon, ... de la reto-infrastrukturo, kiuj ankaŭ devas esti konsiderataj.

Sed mi memorigu vin, ke nun ni ne parolas pri kreado de reto. Laŭ nia komencaj kondiĉoj ni jam elektis la dezajnon, elektis la ekipaĵon kaj kreis la infrastrukturon, kaj en ĉi tiu etapo, se eble, ni devus "vivi" kaj trovi solvojn en la kunteksto de la antaŭe elektita aliro.

Nia tasko nun estas identigi la riskojn asociitajn kun sekureco ĉe la reto-nivelo kaj redukti ilin al racia nivelo.

Revizo pri sekureca reto

Se via organizo efektivigis ISO 27k-procezojn, tiam sekurecaj revizioj kaj retaj ŝanĝoj devus perfekte konveni en la ĝeneralajn procezojn ene de ĉi tiu aliro. Sed ĉi tiuj normoj ankoraŭ ne temas pri specifaj solvoj, ne pri agordo, ne pri dezajno... Ne ekzistas klaraj konsiloj, neniuj normoj detale diktantaj kiel via reto devus esti, jen la komplekseco kaj beleco de ĉi tiu tasko.

Mi reliefigus plurajn eblajn retajn sekurecajn reviziojn:

• revizio de agordo de ekipaĵo (malmoliĝo)
• revizio pri sekureca dezajno
• auditorio de aliro
• proceza revizio

Revizio de agordo de ekipaĵo (malmoliĝo)

Ŝajnas, ke en la plej multaj kazoj ĉi tio estas la plej bona deirpunkto por revizii kaj plibonigi la sekurecon de via reto. MIHO, ĉi tio estas bona pruvo de la leĝo de Pareto (20% de penado produktas 80% de la rezulto, kaj la ceteraj 80% de penado produktas nur 20% de la rezulto).

La fundo estas, ke ni kutime havas rekomendojn de vendistoj pri "plej bonaj praktikoj" por sekureco dum agordado de ekipaĵo. Ĉi tio nomiĝas "malmoliĝo".

Vi ankaŭ povas ofte trovi demandaron (aŭ krei vi mem) surbaze de ĉi tiuj rekomendoj, kiuj helpos vin determini kiom bone la agordo de via ekipaĵo konformas al ĉi tiuj "plej bonaj praktikoj" kaj, laŭ la rezulto, fari ŝanĝojn en via reto. . Ĉi tio permesos al vi sufiĉe facile redukti sekurecajn riskojn, preskaŭ senkoste.

Pluraj ekzemploj por iuj operaciumoj de Cisco.

Malmoliĝo de la agordo de Cisco IOS
Cisco IOS-XR Agordo de Agordo
Malmoliĝo de la agordo de Cisco NX-OS
Cisco Bazlinia Sekureca Kontrollisto

Surbaze de ĉi tiuj dokumentoj, listo de agordaj postuloj por ĉiu speco de ekipaĵo povas esti kreita. Ekzemple, por Cisco N7K VDC ĉi tiuj postuloj povus aspekti tiel.

Tiamaniere, agordaj dosieroj povas esti kreitaj por malsamaj specoj de aktivaj ekipaĵoj en via reto-infrastrukturo. Poste, permane aŭ uzante aŭtomatigon, vi povas "alŝuti" ĉi tiujn agordajn dosierojn. Kiel aŭtomatigi ĉi tiun procezon estos detale diskutita en alia serio de artikoloj pri orkestrado kaj aŭtomatigo.

Sekureca dezajna revizio

Tipe, entreprena reto enhavas la sekvajn segmentojn en unu formo aŭ alia:

• DC (Publikaj servoj DMZ kaj Intranet datencentro)
• interreta atingo
• Fora aliro VPN
• WAN-rando
• branĉo
• Kampuso (oficejo)
• kerna

Titoloj prenitaj de Cisco SAFE modelo, sed ne necesas, kompreneble, esti alkroĉita ĝuste al ĉi tiuj nomoj kaj al ĉi tiu modelo. Tamen, mi volas paroli pri la esenco kaj ne enligiĝi en formalaĵoj.

Por ĉiu el ĉi tiuj segmentoj, sekurecaj postuloj, riskoj kaj, sekve, solvoj estos malsamaj.

Ni rigardu ĉiun el ili aparte por la problemoj, kiujn vi povas renkonti el vidpunkto pri sekureca dezajno. Kompreneble mi denove ripetas, ke neniel ĉi tiu artikolo ŝajnigas esti kompleta, kio ne estas facile (se ne neebla) atingi en tiu ĉi vere profunda kaj multfaceta temo, sed ĝi spegulas mian personan sperton.

Ne ekzistas perfekta solvo (almenaŭ ankoraŭ ne). Ĉiam estas kompromiso. Sed gravas, ke la decido uzi unu aŭ alian aliron estas farita konscie, kun kompreno de ambaŭ ĝiaj avantaĝoj kaj malavantaĝoj.

Datuma Centro

La plej kritika segmento de sekureca vidpunkto.
Kaj, kiel kutime, ankaŭ ĉi tie ne ekzistas universala solvo. Ĉio dependas multe de la retaj postuloj.

Ĉu fajroŝirmilo necesas aŭ ne?

Ŝajnus, ke la respondo estas evidenta, sed ĉio ne estas tiel klara kiel ĝi povus ŝajni. Kaj via elekto povas esti influita ne nur la prezo.

Ekzemplo 1. Malfruoj.

Se malalta latencia estas esenca postulo inter iuj retsegmentoj, kio estas, ekzemple, vera en la kazo de interŝanĝo, tiam ni ne povos uzi fajroŝirmilojn inter ĉi tiuj segmentoj. Estas malfacile trovi studojn pri latencia en fajroŝirmiloj, sed malmultaj ŝaltilmodeloj povas provizi latentecon de malpli ol aŭ je la ordo de 1 mksec, do mi pensas, se mikrosekundoj estas gravaj por vi, tiam fajroŝirmiloj ne estas por vi.

Ekzemplo 2. Rendimento.

La trairo de supraj L3-ŝaltiloj estas kutime grandordo pli alta ol la trairo de la plej potencaj fajromuroj. Tial, en la kazo de altintensa trafiko, vi ankaŭ plej verŝajne devos permesi al ĉi tiu trafiko preteriri fajroŝirmilojn.

Ekzemplo 3. Fidindeco

Fajromuroj, precipe moderna NGFW (Next-Generation FW) estas kompleksaj aparatoj. Ili estas multe pli kompleksaj ol L3/L2-ŝaltiloj. Ili provizas grandan nombron da servoj kaj agordaj elektoj, do ne estas mirinde, ke ilia fidindeco estas multe pli malalta. Se kontinueco de servo estas kritika por la reto, tiam vi eble devos elekti kio kondukos al pli bona havebleco - sekureco kun fajroŝirmilo aŭ la simpleco de reto konstruita sur ŝaltiloj (aŭ diversaj specoj de ŝtofoj) uzante regulajn ACLs.

En la kazo de la supraj ekzemploj, vi plej verŝajne (kiel kutime) devos trovi kompromison. Rigardu la sekvajn solvojn:

• se vi decidas ne uzi fajroŝirmilojn ene de la datumcentro, tiam vi devas pensi pri kiel limigi aliron ĉirkaŭ la perimetro kiel eble plej multe. Ekzemple, vi povas malfermi nur la necesajn havenojn de la Interreto (por klienta trafiko) kaj administran aliron al la datumcentro nur de saltaj gastigantoj. Sur saltaj gastigantoj, faru ĉiujn necesajn kontrolojn (aŭtentikigo/rajtigo, antiviruso, protokolo, ...)
• vi povas uzi logikan sekcion de la datumcentra reto en segmentojn, simile al la skemo priskribita en PSEFABRIC ekzemplo p002. En ĉi tiu kazo, vojigo devas esti agordita tiel, ke malfrusentema aŭ altintensa trafiko iras "ene de" unu segmento (en la kazo de p002, VRF) kaj ne trapasas la fajroŝirmilon. Trafiko inter malsamaj segmentoj daŭros trapasi la fajroŝirmilon. Vi ankaŭ povas uzi itineron likan inter VRF-oj por eviti redirekti trafikon tra la fajroŝirmilo
• Vi ankaŭ povas uzi fajroŝirmilon en travidebla reĝimo kaj nur por tiuj VLANoj kie ĉi tiuj faktoroj (latenteco/efikeco) ne estas signifaj. Sed vi devas zorge studi la limigojn asociitajn kun la uzo de ĉi tiu modo por ĉiu vendisto
• vi eble volas konsideri uzi arkitekturon de servoĉeno. Ĉi tio permesos nur necesan trafikon trapasi la fajroŝirmilon. Aspektas bele en teorio, sed mi neniam vidis ĉi tiun solvon en produktado. Ni testis la servoĉenon por Cisco ACI / Juniper SRX / F5 LTM antaŭ ĉirkaŭ 3 jaroj, sed tiutempe ĉi tiu solvo ŝajnis "kruda" al ni.

Protekta nivelo

Nun vi devas respondi la demandon pri kiaj iloj vi volas uzi por filtri trafikon. Jen kelkaj el la funkcioj, kiuj kutime ĉeestas en NGFW (ekzemple, tie):

• laŭŝtata fajroŝirmilo (defaŭlte)
• aplikaĵa fajroŝirmilo
• minaco-preventado (antiviruso, kontraŭ-spiono kaj vundebleco)
• URL-filtrado
• filtrado de datumoj (filtrado de enhavo)
• dosierblokado (dosiertipoj blokado)
• dos protekto

Kaj ankaŭ ne ĉio estas klara. Ŝajnus, ke ju pli alta estas la nivelo de protekto, des pli bone. Sed vi ankaŭ devas konsideri tion

• Ju pli el la supraj fajroŝirmilaj funkcioj vi uzas, des pli multekosta ĝi estos nature (licencoj, pliaj moduloj)
• la uzo de iuj algoritmoj povas signife redukti fajroŝirmilon kaj ankaŭ pliigi prokrastojn, vidu ekzemple tie
• kiel ajna kompleksa solvo, la uzo de kompleksaj protektaj metodoj povas redukti la fidindecon de via solvo, ekzemple, kiam vi uzas aplikaĵan fajroŝirmilon, mi renkontis blokadon de iuj sufiĉe normaj funkciaj aplikaĵoj (dns, smb)

Kiel ĉiam, vi devas trovi la plej bonan solvon por via reto.

Ne eblas definitive respondi la demandon, kiaj protektofunkcioj povas esti postulataj. Unue, ĉar ĝi kompreneble dependas de la datumoj, kiujn vi transdonas aŭ konservas kaj provas protekti. Due, fakte, ofte la elekto de sekurecaj iloj estas afero de fido kaj fido al la vendisto. Vi ne konas la algoritmojn, vi ne scias kiom efikaj ili estas, kaj vi ne povas plene testi ilin.

Tial, en kritikaj segmentoj, bona solvo povas esti uzi ofertojn de malsamaj kompanioj. Ekzemple, vi povas ebligi antiviruson sur la fajroŝirmilo, sed ankaŭ uzi kontraŭvirusan protekton (de alia fabrikanto) loke sur la gastigantoj.

Segmentado

Ni parolas pri la logika segmentado de la datumcentra reto. Ekzemple, dispartigo en VLAN-ojn kaj subretojn ankaŭ estas logika segmentigo, sed ni ne konsideros ĝin pro ĝia evidenteco. Interesa segmentado konsiderante tiajn entojn kiel FW-sekureczonojn, VRF-ojn (kaj iliaj analogoj rilate al diversaj vendistoj), logikaj aparatoj (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Ekzemplo de tia logika segmentado kaj la nuntempe postulata datumcentro-dezajno ricevas p002 de la projekto PSEFABRIC.

Difininte la logikajn partojn de via reto, vi povas tiam priskribi kiel trafiko moviĝas inter malsamaj segmentoj, sur kiuj aparatoj filtrado estos farita kaj per kiaj rimedoj.

Se via reto ne havas klaran logikan sekcion kaj la reguloj por apliki sekurecpolitikojn por malsamaj datumfluoj ne estas formaligitaj, tio signifas, ke kiam vi malfermas tian aŭ alian aliron, vi estas devigita solvi ĉi tiun problemon, kaj kun alta probableco vi solvos ĝin ĉiufoje alimaniere.

Ofte segmentado baziĝas nur sur FW-sekurecaj zonoj. Tiam vi devas respondi la jenajn demandojn:

• kiajn sekurecajn zonojn vi bezonas
• kian protekton vi volas apliki al ĉiu el ĉi tiuj zonoj
• ĉu en-zona trafiko estos permesata defaŭlte?
• se ne, kiaj trafikaj filtraj politikoj estos aplikitaj ene de ĉiu zono
• kiaj trafikaj filtraj politikoj estos aplikitaj por ĉiu paro da zonoj (fonto/celloko)

TCAM

Ofta problemo estas nesufiĉa TCAM (Ternary Content Addressable Memory), kaj por vojigo kaj por aliroj. MIHO, ĉi tio estas unu el la plej gravaj aferoj kiam vi elektas ekipaĵon, do vi devas trakti ĉi tiun problemon kun la taŭga grado de zorgo.

Ekzemplo 1. Transdonanta Tabelo TCAM.

Ni rigardu Palo Alto 7k fajroŝirmilo
Ni vidas, ke IPv4 plusenda tabelgrandeco* = 32K
Krome, ĉi tiu nombro da itineroj estas ofta por ĉiuj VSYS-oj.

Ni supozu, ke laŭ via dezajno vi decidas uzi 4 VSYS.
Ĉiu el ĉi tiuj VSYS estas konektita per BGP al du MPLS PE-oj de la nubo, kiun vi uzas kiel BB. Tiel, 4 VSYS interŝanĝas ĉiujn specifajn itinerojn unu kun la alia kaj havas plusendan tablon kun proksimume la samaj aroj de itineroj (sed malsamaj NHoj). Ĉar ĉiu VSYS havas 2 BGP-sesiojn (kun la samaj agordoj), tiam ĉiu itinero ricevita per MPLS havas 2 NH kaj, sekve, 2 FIB-enskribojn en la Plusenda Tabelo. Se ni supozas, ke ĉi tiu estas la sola fajroŝirmilo en la datumcentro kaj ĝi devas scii pri ĉiuj itineroj, tiam ĉi tio signifos, ke la tuta nombro da itineroj en nia datumcentro ne povas esti pli ol 32K/(4 * 2) = 4K.

Nun, se ni supozas, ke ni havas 2 datumcentrojn (kun la sama dezajno), kaj ni volas uzi VLAN-ojn "streĉitajn" inter datumcentroj (ekzemple, por vMotion), tiam por solvi la enrutigan problemon, ni devas uzi gastigantajn itinerojn. . Sed ĉi tio signifas, ke por 2 datumcentroj ni havos ne pli ol 4096 eblajn gastigantojn kaj, kompreneble, tio eble ne sufiĉas.

Ekzemplo 2. ACL TCAM.

Se vi planas filtri trafikon per L3-ŝaltiloj (aŭ aliaj solvoj, kiuj uzas L3-ŝaltilojn, ekzemple, Cisco ACI), tiam elektante ekipaĵon vi devas atenti la TCAM ACL.

Supozu, ke vi volas kontroli aliron sur la SVI-interfacoj de la Cisco Catalyst 4500. Tiam, kiel videblas de ĉi tiu artikolo, por kontroli elirantan (same kiel envenantan) trafikon sur interfacoj, vi povas uzi nur 4096 TCAM-liniojn. Kiu kiam vi uzas TCAM3, donos al vi ĉirkaŭ 4000 mil ACE-ojn (ACL-linioj).

Se vi alfrontas la problemon de nesufiĉa TCAM, tiam antaŭ ĉio, kompreneble, vi devas konsideri la eblecon de optimumigo. Do, en kazo de problemo kun la grandeco de la Transdona Tablo, vi devas konsideri la eblecon aldoni itinerojn. En kazo de problemo kun la grandeco de TCAM por aliroj, revizii alirojn, forigi malmodernajn kaj interkovrantajn rekordojn, kaj eventuale revizii la proceduron por malfermi alirojn (estos detale diskutita en la ĉapitro pri revizio de aliroj).

Alta disponibilidad

La demando estas: ĉu mi uzu HA por fajroŝirmiloj aŭ instali du sendependajn skatolojn "paralele" kaj, se unu el ili malsukcesas, direkti trafikon tra la dua?

Ŝajnus, ke la respondo estas evidenta - uzu HA. La kialo, kial ĉi tiu demando ankoraŭ stariĝas, estas ke, bedaŭrinde, la teoriaj kaj reklamaj 99 kaj pluraj decimalaj procentoj de alirebleco en la praktiko montriĝas malproksime de tiom rozaj. HA estas logike sufiĉe kompleksa afero, kaj sur malsamaj ekipaĵoj, kaj kun malsamaj vendistoj (ne estis esceptoj), ni kaptis problemojn kaj cimojn kaj servajn haltojn.

Se vi uzas HA, vi havos la ŝancon malŝalti individuajn nodojn, ŝanĝi inter ili sen ĉesigi la servon, kio gravas, ekzemple, kiam vi faras ĝisdatigojn, sed samtempe vi havas tre nulan probablecon, ke ambaŭ nodoj. rompiĝos samtempe, kaj ankaŭ ke la venonta la ĝisdatigo ne iros tiel glate kiel la vendisto promesas (ĉi tiu problemo povas esti evitita se vi havas la ŝancon testi la ĝisdatigon sur laboratoria ekipaĵo).

Se vi ne uzas HA, tiam el la vidpunkto de duobla fiasko viaj riskoj estas multe pli malaltaj (ĉar vi havas 2 sendependajn fajroŝirmilojn), sed ĉar... sesioj ne estas sinkronigitaj, tiam ĉiufoje kiam vi ŝanĝas inter ĉi tiuj fajroŝirmiloj vi perdos trafikon. Vi povas, kompreneble, uzi sennacian fajroŝirmilon, sed tiam la punkto uzi fajroŝirmilon estas plejparte perdita.

Sekve, se kiel rezulto de la revizio vi malkovris solecajn fajroŝirmilojn, kaj vi pensas pliigi la fidindecon de via reto, tiam HA, kompreneble, estas unu el la rekomenditaj solvoj, sed vi ankaŭ devus konsideri la malavantaĝojn asociitajn. kun ĉi tiu aliro kaj, eble, specife por via reto, alia solvo estus pli taŭga.

Maneblo

Principe, HA temas ankaŭ pri direktebleco. Anstataŭ agordi 2 skatolojn aparte kaj trakti la problemon sinkronigi la agordojn, vi administras ilin kvazaŭ vi havus unu aparaton.

Sed eble vi havas multajn datumcentrojn kaj multajn fajroŝirmilojn, tiam ĉi tiu demando ŝprucas je nova nivelo. Kaj la demando estas ne nur pri agordo, sed ankaŭ pri

• rezervaj agordoj
• ĝisdatigoj
• ĝisdatigoj
• monitorado
• arbohakado

Kaj ĉio ĉi povas esti solvita per centralizitaj administradsistemoj.

Do, ekzemple, se vi uzas fajroŝirmilojn de Palo Alto, tiam panoramo estas tia solvo.

Daŭrigota.

fonto: www.habr.com