Yr erthygl hon yw'r drydedd mewn cyfres o erthyglau “Sut i Reoli Eich Seilwaith Rhwydwaith.” Gellir dod o hyd i gynnwys pob erthygl yn y gyfres a dolenni .
Nid oes diben siarad am ddileu risgiau diogelwch yn llwyr. Mewn egwyddor, ni allwn eu lleihau i sero. Mae angen i ni ddeall hefyd, wrth i ni ymdrechu i wneud y rhwydwaith yn fwyfwy diogel, fod ein hatebion yn dod yn fwyfwy drud. Mae angen ichi ddod o hyd i gyfaddawd rhwng cost, cymhlethdod a diogelwch sy'n gwneud synnwyr i'ch rhwydwaith.
Wrth gwrs, mae dyluniad diogelwch wedi'i integreiddio'n organig i'r bensaernïaeth gyffredinol ac mae'r atebion diogelwch a ddefnyddir yn effeithio ar scalability, dibynadwyedd, hylaw, ... y seilwaith rhwydwaith, y mae'n rhaid ei ystyried hefyd.
Ond gadewch imi eich atgoffa nad ydym nawr yn sôn am greu rhwydwaith. Yn ôl ein rydym eisoes wedi dewis y dyluniad, wedi dewis yr offer, ac wedi creu’r seilwaith, ac ar yr adeg hon, os yn bosibl, dylem “fyw” a dod o hyd i atebion yng nghyd-destun y dull a ddewiswyd yn flaenorol.
Ein tasg nawr yw nodi'r risgiau sy'n gysylltiedig â diogelwch ar lefel rhwydwaith a'u lleihau i lefel resymol.
Archwiliad diogelwch rhwydwaith
Os yw eich sefydliad wedi rhoi prosesau ISO 27k ar waith, yna dylai archwiliadau diogelwch a newidiadau rhwydwaith ffitio'n ddi-dor i'r prosesau cyffredinol o fewn y dull hwn. Ond nid yw'r safonau hyn yn ymwneud ag atebion penodol o hyd, nid yn ymwneud â chyfluniad, nid yn ymwneud â dylunio... Nid oes unrhyw gyngor clir, dim safonau sy'n pennu'n fanwl sut le ddylai eich rhwydwaith fod, dyma gymhlethdod a harddwch y dasg hon.
Hoffwn dynnu sylw at nifer o archwiliadau diogelwch rhwydwaith posibl:
- archwiliad cyfluniad offer (caledu)
- archwiliad dylunio diogelwch
- archwiliad mynediad
- archwiliad proses
Archwiliad cyfluniad offer (caledu)
Mae'n ymddangos yn y rhan fwyaf o achosion mai dyma'r man cychwyn gorau ar gyfer archwilio a gwella diogelwch eich rhwydwaith. IMHO, mae hwn yn arddangosiad da o gyfraith Pareto (mae 20% o ymdrech yn cynhyrchu 80% o'r canlyniad, ac mae'r 80% o ymdrech sy'n weddill yn cynhyrchu dim ond 20% o'r canlyniad).
Y gwir amdani yw bod gennym fel arfer argymhellion gan werthwyr ynghylch “arferion gorau” ar gyfer diogelwch wrth ffurfweddu offer. Gelwir hyn yn “galedu”.
Yn aml, gallwch hefyd ddod o hyd i holiadur (neu greu un eich hun) yn seiliedig ar yr argymhellion hyn, a fydd yn eich helpu i benderfynu pa mor dda y mae cyfluniad eich offer yn cydymffurfio â'r “arferion gorau” hyn ac, yn unol â'r canlyniad, gwneud newidiadau yn eich rhwydwaith . Bydd hyn yn eich galluogi i leihau risgiau diogelwch yn sylweddol yn eithaf hawdd, heb fawr ddim cost.
Sawl enghraifft ar gyfer rhai systemau gweithredu Cisco.
Yn seiliedig ar y dogfennau hyn, gellir creu rhestr o ofynion cyfluniad ar gyfer pob math o offer. Er enghraifft, ar gyfer Cisco N7K VDC efallai y bydd y gofynion hyn yn edrych .
Yn y modd hwn, gellir creu ffeiliau cyfluniad ar gyfer gwahanol fathau o offer gweithredol yn eich seilwaith rhwydwaith. Nesaf, â llaw neu gan ddefnyddio awtomeiddio, gallwch “lanlwytho” y ffeiliau cyfluniad hyn. Bydd sut i awtomeiddio'r broses hon yn cael ei drafod yn fanwl mewn cyfres arall o erthyglau ar offeryniaeth ac awtomeiddio.
Archwiliad dylunio diogelwch
Yn nodweddiadol, mae rhwydwaith menter yn cynnwys y segmentau canlynol mewn rhyw ffurf neu'i gilydd:
- DC (Canolfan ddata gwasanaethau cyhoeddus DMZ a Mewnrwyd)
- Mynediad i'r rhyngrwyd
- VPN mynediad o bell
- ymyl WAN
- Cangen
- Campws (Swyddfa)
- Craidd
Teitlau a gymerwyd o model, ond nid oes angen, wrth gwrs, ei gysylltu'n union â'r enwau hyn ac â'r model hwn. Eto i gyd, rwyf am siarad am yr hanfod a pheidio â chael fy llethu gan ffurfioldebau.
Ar gyfer pob un o'r segmentau hyn, bydd gofynion diogelwch, risgiau ac, yn unol â hynny, atebion yn wahanol.
Gadewch i ni edrych ar bob un ohonynt ar wahân ar gyfer y problemau y gallech ddod ar eu traws o safbwynt dylunio diogelwch. Wrth gwrs, ailadroddaf eto nad yw'r erthygl hon mewn unrhyw ffordd yn esgus ei bod yn gyflawn, nad yw'n hawdd (os nad yn amhosibl) ei chyflawni yn y pwnc gwirioneddol ddwfn ac amlochrog hwn, ond mae'n adlewyrchu fy mhrofiad personol.
Nid oes ateb perffaith (o leiaf ddim eto). Mae bob amser yn gyfaddawd. Ond mae'n bwysig bod y penderfyniad i ddefnyddio un dull neu'r llall yn cael ei wneud yn ymwybodol, gyda dealltwriaeth o'r manteision a'r anfanteision.
Canolfan Ddata
Y segment mwyaf hanfodol o safbwynt diogelwch.
Ac, yn ôl yr arfer, nid oes ateb cyffredinol yma ychwaith. Mae'r cyfan yn dibynnu'n fawr ar ofynion y rhwydwaith.
A yw wal dân yn angenrheidiol ai peidio?
Mae'n ymddangos bod yr ateb yn amlwg, ond nid yw popeth mor glir ag y gallai ymddangos. A gall eich dewis gael ei ddylanwadu nid yn unig pris.
Enghraifft 1. Oedi.
Os yw hwyrni isel yn ofyniad hanfodol rhwng rhai segmentau rhwydwaith, sydd, er enghraifft, yn wir yn achos cyfnewid, yna ni fyddwn yn gallu defnyddio waliau tân rhwng y segmentau hyn. Mae'n anodd dod o hyd i astudiaethau ar hwyrni mewn waliau tân, ond ychydig o fodelau switsh sy'n gallu darparu hwyrni o lai na neu ar orchymyn 1 mksec, felly rwy'n meddwl os yw microseconds yn bwysig i chi, yna nid yw waliau tân yn addas i chi.
Enghraifft 2. Perfformiad.
Mae trwygyrch switshis L3 uchaf fel arfer yn orchymyn maint uwch na thrwygyrch y waliau tân mwyaf pwerus. Felly, yn achos traffig dwysedd uchel, mae'n debygol y bydd yn rhaid i chi hefyd ganiatáu i'r traffig hwn osgoi waliau tân.
Enghraifft 3. Dibynadwyedd
Mae waliau tân, yn enwedig NGFW modern (FW Cenhedlaeth Nesaf) yn ddyfeisiadau cymhleth. Maent yn llawer mwy cymhleth na switshis L3/L2. Maent yn darparu nifer fawr o wasanaethau ac opsiynau cyfluniad, felly nid yw'n syndod bod eu dibynadwyedd yn llawer is. Os yw parhad gwasanaeth yn hanfodol i'r rhwydwaith, yna efallai y bydd yn rhaid i chi ddewis beth fydd yn arwain at well argaeledd - diogelwch gyda wal dân neu symlrwydd rhwydwaith wedi'i adeiladu ar switshis (neu wahanol fathau o ffabrigau) gan ddefnyddio ACLs rheolaidd.
Yn achos yr enghreifftiau uchod, mae'n debygol y bydd yn rhaid i chi (fel arfer) ddod o hyd i gyfaddawd. Edrych tuag at yr atebion canlynol:
- os penderfynwch beidio â defnyddio waliau tân y tu mewn i'r ganolfan ddata, yna mae angen i chi feddwl sut i gyfyngu mynediad o amgylch y perimedr cymaint â phosib. Er enghraifft, dim ond y porthladdoedd angenrheidiol y gallwch chi eu hagor o'r Rhyngrwyd (ar gyfer traffig cleientiaid) a mynediad gweinyddol i'r ganolfan ddata yn unig gan westeion naid. Ar westeiwyr naid, gwnewch yr holl wiriadau angenrheidiol (dilysu / awdurdodi, gwrthfeirws, logio, ...)
- gallwch ddefnyddio rhaniad rhesymegol o rwydwaith y ganolfan ddata yn segmentau, yn debyg i'r cynllun a ddisgrifir yn PSEFABRIC . Yn yr achos hwn, rhaid ffurfweddu'r llwybro yn y fath fodd fel bod traffig sy'n sensitif i oedi neu draffig dwysedd uchel yn mynd “o fewn” un segment (yn achos p002, VRF) ac nad yw'n mynd trwy'r wal dân. Bydd traffig rhwng gwahanol segmentau yn parhau i fynd drwy'r wal dân. Gallwch hefyd ddefnyddio llwybrau sy'n gollwng rhwng VRFs i osgoi ailgyfeirio traffig drwy'r wal dân
- Gallwch hefyd ddefnyddio wal dân mewn modd tryloyw a dim ond ar gyfer y VLANs hynny lle nad yw'r ffactorau hyn (latency/perfformiad) yn arwyddocaol. Ond mae angen i chi astudio'n ofalus y cyfyngiadau sy'n gysylltiedig â defnyddio'r mod hwn ar gyfer pob gwerthwr
- efallai y byddwch am ystyried defnyddio saernïaeth cadwyn gwasanaeth. Bydd hyn yn caniatáu dim ond traffig angenrheidiol i basio drwy'r wal dân. Yn edrych yn neis mewn theori, ond dydw i erioed wedi gweld yr ateb hwn wrth gynhyrchu. Fe wnaethon ni brofi'r gadwyn gwasanaeth ar gyfer Cisco ACI / Juniper SRX / F5 LTM tua 3 blynedd yn ôl, ond bryd hynny roedd yr ateb hwn yn ymddangos yn “crai” i ni.
Lefel amddiffyn
Nawr mae angen i chi ateb y cwestiwn pa offer rydych chi am eu defnyddio i hidlo traffig. Dyma rai o'r nodweddion sydd fel arfer yn bresennol yn NGFW (er enghraifft, ):
- waliau tân urddasol (diofyn)
- wal tân cais
- atal bygythiadau (antifeirws, gwrth-ysbïwedd, a bregusrwydd)
- Hidlo URL
- hidlo data (hidlo cynnwys)
- blocio ffeiliau (blocio mathau o ffeiliau)
- amddiffyn dos
Ac nid yw popeth yn glir ychwaith. Mae'n ymddangos mai po uchaf yw lefel yr amddiffyniad, y gorau. Ond mae angen ichi ystyried hynny hefyd
- Po fwyaf o'r swyddogaethau wal dân uchod y byddwch chi'n eu defnyddio, y mwyaf costus fydd hi'n naturiol (trwyddedau, modiwlau ychwanegol)
- gall y defnydd o rai algorithmau leihau trwybwn waliau tân yn sylweddol a hefyd gynyddu oedi, gweler er enghraifft
- fel unrhyw ateb cymhleth, gall defnyddio dulliau amddiffyn cymhleth leihau dibynadwyedd eich datrysiad, er enghraifft, wrth ddefnyddio waliau tân cymwysiadau, deuthum ar draws rhai cymwysiadau gweithio eithaf safonol (dns, smb) wedi'u blocio.
Fel bob amser, mae angen ichi ddod o hyd i'r ateb gorau ar gyfer eich rhwydwaith.
Mae'n amhosib ateb y cwestiwn yn bendant pa swyddogaethau amddiffyn y gall fod eu hangen. Yn gyntaf, oherwydd ei fod wrth gwrs yn dibynnu ar y data rydych chi'n ei drosglwyddo neu'n ei storio ac yn ceisio ei ddiogelu. Yn ail, mewn gwirionedd, yn aml mae'r dewis o offer diogelwch yn fater o ffydd ac ymddiriedaeth yn y gwerthwr. Nid ydych chi'n gwybod yr algorithmau, nid ydych chi'n gwybod pa mor effeithiol ydyn nhw, ac ni allwch eu profi'n llawn.
Felly, mewn segmentau hollbwysig, efallai mai ateb da fyddai defnyddio cynigion gan wahanol gwmnïau. Er enghraifft, gallwch chi alluogi gwrthfeirws ar y wal dân, ond hefyd defnyddio amddiffyniad gwrthfeirws (gan wneuthurwr arall) yn lleol ar y gwesteiwyr.
Segmentu
Rydym yn sôn am segmentiad rhesymegol rhwydwaith y ganolfan ddata. Er enghraifft, mae rhannu'n VLANs ac is-rwydweithiau hefyd yn segmentiad rhesymegol, ond ni fyddwn yn ei ystyried oherwydd ei amlygrwydd. Segmentu diddorol gan ystyried endidau fel parthau diogelwch FW, VRFs (a'u analogau mewn perthynas ag amrywiol werthwyr), dyfeisiau rhesymegol (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...
Rhoddir enghraifft o segmentiad rhesymegol o'r fath a chynllun y ganolfan ddata y mae galw amdano ar hyn o bryd yn .
Ar ôl diffinio rhannau rhesymegol eich rhwydwaith, gallwch wedyn ddisgrifio sut mae traffig yn symud rhwng gwahanol segmentau, ar ba ddyfeisiau y bydd hidlo'n cael ei berfformio a sut.
Os nad oes gan eich rhwydwaith raniad rhesymegol clir ac nad yw'r rheolau ar gyfer cymhwyso polisïau diogelwch ar gyfer gwahanol lifoedd data yn cael eu ffurfioli, mae hyn yn golygu pan fyddwch chi'n agor hwn neu'r mynediad hwnnw, fe'ch gorfodir i ddatrys y broblem hon, a chyda thebygolrwydd uchel y byddwch yn ei ddatrys bob tro yn wahanol.
Yn aml mae segmentu yn seiliedig ar barthau diogelwch FW yn unig. Yna mae angen i chi ateb y cwestiynau canlynol:
- pa barthau diogelwch sydd eu hangen arnoch chi
- pa lefel o amddiffyniad ydych chi am ei gymhwyso i bob un o'r parthau hyn
- a fydd traffig o fewn y parth yn cael ei ganiatáu yn ddiofyn?
- os na, pa bolisïau hidlo traffig fydd yn cael eu defnyddio ym mhob parth
- pa bolisïau hidlo traffig a ddefnyddir ar gyfer pob pâr o barthau (ffynhonnell/cyrchfan)
TCAM
Problem gyffredin yw TCAM annigonol (Ternary Content Addressable Memory), ar gyfer llwybro ac ar gyfer mynediad. IMHO, dyma un o'r materion pwysicaf wrth ddewis offer, felly mae angen i chi drin y mater hwn gyda'r lefel briodol o ofal.
Enghraifft 1. Tabl Anfon TCAM.
gadewch i ni ystyried wal dân
Gwelwn fod maint tabl anfon IPv4 * = 32K
At hynny, mae'r nifer hwn o lwybrau yn gyffredin i bob VSYS.Gadewch i ni dybio eich bod yn penderfynu defnyddio 4 VSYS yn ôl eich dyluniad.
Mae pob un o'r VSYSs hyn wedi'i gysylltu trwy BGP â dau MPLS PE o'r cwmwl rydych chi'n eu defnyddio fel BB. Felly, mae 4 VSYS yn cyfnewid pob llwybr penodol â'i gilydd ac mae ganddynt fwrdd anfon ymlaen gyda thua'r un setiau o lwybrau (ond gwahanol NH). Achos mae gan bob VSYS 2 sesiwn BGP (gyda'r un gosodiadau), yna mae gan bob llwybr a dderbynnir trwy MPLS 2 NH ac, yn unol â hynny, 2 gofnod FIB yn y Tabl Anfon. Os tybiwn mai dyma'r unig wal dân yn y ganolfan ddata a bod yn rhaid iddo wybod am yr holl lwybrau, yna bydd hyn yn golygu na all cyfanswm nifer y llwybrau yn ein canolfan ddata fod yn fwy na 32K/(4 * 2) = 4K.Nawr, os ydym yn tybio bod gennym 2 ganolfan ddata (gyda'r un dyluniad), ac rydym am ddefnyddio VLANs "ymestyn" rhwng canolfannau data (er enghraifft, ar gyfer vMotion), yna i ddatrys y broblem llwybro, rhaid inni ddefnyddio llwybrau gwesteiwr . Ond mae hyn yn golygu na fydd gennym ni fwy na 2 o westeion posibl ar gyfer 4096 ganolfan ddata ac, wrth gwrs, efallai na fydd hyn yn ddigon.
Enghraifft 2. ACL TCAM.
Os ydych chi'n bwriadu hidlo traffig ar switshis L3 (neu atebion eraill sy'n defnyddio switshis L3, er enghraifft, Cisco ACI), yna wrth ddewis offer dylech dalu sylw i'r TCAM ACL.
Tybiwch eich bod am reoli mynediad ar ryngwynebau SVI y Cisco Catalyst 4500. Yna, fel y gwelir o , i reoli traffig sy'n mynd allan (yn ogystal â dod i mewn) ar ryngwynebau, gallwch ddefnyddio dim ond 4096 o linellau TCAM. A fydd wrth ddefnyddio TCAM3 yn rhoi tua 4000 mil ACE (llinellau ACL) i chi.
Os ydych chi'n wynebu'r broblem o TCAM annigonol, yna, yn gyntaf oll, wrth gwrs, mae angen i chi ystyried y posibilrwydd o optimeiddio. Felly, rhag ofn y bydd problem gyda maint y Tabl Anfon Ymlaen, mae angen ichi ystyried y posibilrwydd o agregu llwybrau. Mewn achos o broblem gyda maint TCAM ar gyfer mynediadau, archwilio mynediadau, cael gwared ar gofnodion sydd wedi dyddio ac sy'n gorgyffwrdd, ac o bosibl adolygu'r weithdrefn ar gyfer agor mynedfeydd (trafodir hyn yn fanwl yn y bennod ar archwilio mynediad).
Argaeledd Uchel
Y cwestiwn yw: a ddylwn ddefnyddio HA ar gyfer waliau tân neu osod dau flwch annibynnol “yn gyfochrog” ac, os bydd un ohonynt yn methu, llwybr traffig drwy'r ail?
Mae'n ymddangos bod yr ateb yn amlwg - defnyddiwch HA. Y rheswm pam mae'r cwestiwn hwn yn dal i godi yw, yn anffodus, bod y canrannau damcaniaethol a hysbysebu 99 a sawl canran degol o hygyrchedd yn ymarferol yn troi allan i fod ymhell o fod mor rosy. Mae HA yn rhesymegol yn beth eithaf cymhleth, ac ar wahanol offer, a chyda gwahanol werthwyr (nid oedd unrhyw eithriadau), fe wnaethom ddal problemau a chwilod ac arosfannau gwasanaeth.
Os ydych yn defnyddio HA, byddwch yn cael y cyfle i ddiffodd nodau unigol, newid rhyngddynt heb atal y gwasanaeth, sy'n bwysig, er enghraifft, wrth wneud uwchraddio, ond ar yr un pryd mae gennych ymhell o fod yn sero tebygolrwydd y bydd y ddau nod yn torri ar yr un pryd, a hefyd y nesaf ni fydd yr uwchraddio yn mynd mor esmwyth ag y mae'r gwerthwr yn ei addo (gellir osgoi'r broblem hon os cewch gyfle i brofi'r uwchraddio ar offer labordy).
Os nad ydych yn defnyddio HA, yna o safbwynt methiant dwbl mae eich risgiau yn llawer is (gan fod gennych 2 wal dân annibynnol), ond ers ... nid yw sesiynau'n cael eu cysoni, yna bob tro y byddwch chi'n newid rhwng y waliau tân hyn byddwch chi'n colli traffig. Gallwch, wrth gwrs, ddefnyddio waliau tân heb wladwriaeth, ond yna mae pwynt defnyddio wal dân yn cael ei golli i raddau helaeth.
Felly, os ydych wedi darganfod waliau tân unig o ganlyniad i'r archwiliad, a'ch bod yn ystyried cynyddu dibynadwyedd eich rhwydwaith, yna HA, wrth gwrs, yw un o'r atebion a argymhellir, ond dylech hefyd ystyried yr anfanteision cysylltiedig gyda'r dull hwn ac, efallai, yn benodol ar gyfer eich rhwydwaith, byddai ateb arall yn fwy addas.
hylaw
Mewn egwyddor, mae HA hefyd yn ymwneud â'r gallu i reoli. Yn hytrach na ffurfweddu 2 flwch ar wahân a delio â'r broblem o gadw'r ffurfweddiadau mewn cydamseriad, rydych chi'n eu rheoli cymaint fel pe bai gennych un ddyfais.
Ond efallai bod gennych chi lawer o ganolfannau data a llawer o waliau tân, yna mae'r cwestiwn hwn yn codi ar lefel newydd. Ac mae'r cwestiwn nid yn unig yn ymwneud â chyfluniad, ond hefyd yn ymwneud â
- ffurfweddau wrth gefn
- diweddariadau
- uwchraddio
- monitro
- logio
A gellir datrys hyn i gyd trwy systemau rheoli canolog.
Felly, er enghraifft, os ydych chi'n defnyddio waliau tân Palo Alto, yna yn ateb o'r fath.
I'w barhau.
Ffynhonnell: hab.com