See artikkel on viies osa artiklite tsüklis „Kuidas võtta võrguinfrastruktuur oma kontrolli alla”. Kõigi tsükli artiklite sisu ja lingid leiate siit .
See osa käsitleb Campus (Office) ja Remote access VPN segmente.
Võib tunduda, et kontorivõrgu kujundamine on lihtne.
Tõepoolest, võtame L2/L3 switchid, ühendame need omavahel. Edasi, teeme elementaarse konfiguratsiooni vlanide, vaikeväravate seadistamiseks, korraldame lihtsa marsruutimise, ühendame WiFi kontrollerid, pääsupunktid, seadistame ja installime ASA kaugjuurdepääsu jaoks ning rõõmustame, et kõik töötab. Põhimõtteliselt, nagu ma juba varem olen kirjutanud selles tsüklis, on kontorivõrgu projekteerimine ja konfigureerimine nii, et „kuidagi töötaks”, peaaegu iga üliõpilane, kes on kuulnud (ja omandanud) kaks semestrit telekommunikatsiooni kursusest, võimeline.
Kuid mida rohkem te õpite, seda vähem lihtne tundub see ülesanne. Isiklikult ei tundu kontorivõrgu kujundamise teema minu jaoks sugugi lihtne ning selles artiklis püüan selgitada, miks.
Lühidalt öeldes, tuleb arvesse võtta üsna palju tegureid. Sageli on need tegurid omavahel vastuolus ja tuleb leida mõistlik kompromiss.
See ebakindlus on peamine keerukus. Kui rääkida turvalisusest, siis meil on kolmveerandne kolmnurk: turvalisus, töötajate mugavus, lahenduse hind.
Ja iga kord tuleb otsida kompromissi nende kolme vahel.
Arhitektuur
Nende kahe segmenti arhitektuuri näitena soovitan, nagu eelnevates artiklites, mudelit: , .
Need on veidi vananenud dokumendid. Toon need siin välja, sest põhimõtteliselt skeemid ja lähenemine ei ole muutunud, kuid mulle meeldib see esitlus rohkem kui .
Kuigi ma ei kutsu teid üles kasutama just Cisco lahendusi, pean siiski kasulikuks hoolikalt uurida seda kujundust.
See artikkel, nagu tavaliselt, ei pretendeeri täielikkusele, vaid on pigem täienduseks antud teabele.
Artikli lõpus analüüsime Cisco SAFE kujundust kontori jaoks nende kontseptsioonide valgustuses, mis siin on esitatud.
Üldpõhimõtted
Kontorivõrgu kujundus peab kindlasti vastama üldistele nõudmistele, mida käsitleti. peatükkis "Disaini kvaliteedi hindamise kriteeriumid". Peale hinna ja turvalisuse, millest me käesolevas artiklis arutame, on veel kolm kriteeriumi, mida tuleb arvestada disainimisel (või muudatuste tegemisel):
- skaalautuvus (scalability)
- haldusmugavus (manageability)
- saadavus (availability)
Paljud, mida on arutatud kui ka kontorite puhul on see õigustatud.
Kuid kontorisegment on siiski oma eripäradega, mis turvalisuse seisukohalt on kriitilise tähtsusega. Selle eripära olemus on see, et see segment on loodud pakkuma võrguteenuseid ettevõtte töötajatele (ka partneritele ja külalistele), ja seetõttu seisame me probleemi kõrgemal tasemel silmitsi kahe ülesandega:
- kaitsta ettevõtte ressursse kahjulike tegevuste eest, mis võivad tulla töötajatelt (külalistelt, partneritelt) ja nende kasutatavatelt tarkvaradelt. Siia kuulub ka kaitse volitamata võrku sisenemise eest.
- kaitsta ise kasutajate süsteeme ja andmeid
Ja see on ainult probleemi üks külg (täpsemalt üks kolmnurga tipp). Teisel poolel on kasutaja mugavus ja rakendatavate lahenduste hind.
Alustame sellest, mida kasutaja ootab tänapäeva kontori võrgust.
Mugavused
Nii näevad minu arvates "võrgumugavused" kontori kasutaja jaoks välja järgmiselt:
- Mobiilsus
- Võimalus kasutada kõiki tuttavaid seadmeid ja operatsioonisüsteeme
- Lihtne juurdepääs kõikidele ettevõtte vajalikele ressurssidele
- Internetiressurside kättesaadavus sealhulgas erinevad pilveteenused
- "Kiire võrgu töö"
See kehtib nii töötajate kui ka külaliste (või partnerite) puhul, ja see on juba inseneride ülesanne eristada ligipääse erinevate kasutajari gruppide põhjal.
Vaatame iga aspekti natuke põhjalikumalt.
Mobiilsus
Räägime võimalusest töötada ja kasutada kõiki ettevõtte vajalikke ressursse igast maailma punktist (muidugi seal, kus internet on saadaval).
See this in full effect in the office. It’s convenient when you can continue working from anywhere in the office, for example, checking emails, communicating in corporate messengers, or being available for video calls. This allows you, on one hand, to address some issues through face-to-face communication (for instance, participating in meetings), while on the other hand, to remain online at all times, keeping a finger on the pulse and swiftly resolving urgent high-priority tasks. This is very convenient and truly enhances the quality of communications.
This is achieved through the proper design of the WiFi network.
Note
Here the question usually arises, is it enough to use only WiFi? Does this mean you can abandon Ethernet ports in the office? If we’re discussing users rather than servers, which are sensible to connect with standard Ethernet ports, the general answer is: yes, you can be limited to WiFi. But there are nuances.
There are important user groups that require a different approach. These are of course administrators. In principle, WiFi connections are less reliable (regarding traffic loss) and slower than standard Ethernet ports. This can be significant for administrators. Moreover, network administrators may have their own dedicated Ethernet network for out-of-band connections.
There may be other groups/departments in your company for whom these factors are also important.
Another important point is telephony. For some reason, you may not want to use Wireless VoIP and prefer to utilize IP phones with regular Ethernet connections.
In general, in the companies I have worked for, there has usually been the option of both WiFi connections and Ethernet ports.
I would like mobility to not be limited to just the office.
To enable remote work from home (or any other location with internet access), a VPN connection is used. Ideally, employees should not feel the difference between working from home and remote work, which implies the need for the same accesses. We will discuss how to organize this later in the chapter 'Unified Centralized Authentication and Authorization System'.
Note
Tõenäoliselt ei õnnestu teil pakkuda sama kvaliteedi kaugtöös kui kontoris. Oletame, et teie VPN-gate'i seadmena on Cisco ASA 5520. Vastavalt suudab see seade „seedida“ vaid 225 Mbit VPN-traafikut. See tähendab, et loomulikult on VPN-i kaudu ühendamise puhul läbilaskevõime oluliselt erinev kontoris töötamisest. Samuti, kui latentsus, kaod või jitter (näiteks kui soovite kasutada kontori IP-telefoniteenuseid) on teie võrgu teenuste jaoks olulised, ei saa te samuti sama kvaliteeti, nagu oleksite kontoris. Seega, rääkides liikuvusest, peame meeles pidama võimalikke piiranguid.
Lihtne juurdepääs kõigile ettevõtte ressurssidele
See ülesanne peaks olema lahendatud koostöös teiste tehniliste osakondadega.
Ideaalne olukord on see, kui kasutajal on vajalik autentida end ainult kord, ja pärast seda ta saab juurdepääsu kõikidele vajalikele ressurssidele.
Lihtsa juurdepääsu pakkumine ohutust kahjustamata võib oluliselt tõsta töö efektiivsust ja vähendada teie kolleegide stressi.
Märkus 1
Mugav juurdepääs ei tähenda ainult seda, kui mitu korda peate parooli sisestama. Kui näiteks teie turvapoliitika järgi peate andmekeskusega ühenduse loomiseks kõigepealt ühendama VPN-gate'i ja kaotate seejärel juurdepääsu kontori ressurssidele, siis on see samuti väga ja väga ebamugav.
Märkus 2
On teenuseid (näiteks juurdepääs võrgu seadmetele), kus meil on sageli oma pühendatud AAA-serverid ja on normaalne, et sel juhul tuleb autentida end mitu korda.
Interneti ressurside kättesaadavus
Internet ei ole ainult meelelahutus, vaid ka teenuste kogum, mis võib olla töö jaoks väga kasulik. On veel puhtalt psühholoogilised tegurid. Kaasaegne inimene on interneti kaudu paljude virtuaalsete sidemete kaudu seotud teistega ja minu arvates ei ole midagi halba, kui ta jätkab selle sideme tundmist isegi tööl.
Aja kaotamise seisukohalt pole midagi kohutavat, kui töötajal on näiteks avatud Skype ja ta kulutab 5 minutit lähedasega suhtlemiseks vajadusel.
Kas see tähendab, et internet peab alati olema kergesti ligipääsetav, ja kas see tähendab, et töötajatele võib anda ligipääsu kõikidele ressurssidele ilma igasuguse kontrollita?
Ei, see ei tähenda, loomulikult. Interneti avatus võib olla erinev eri ettevõtetes – täielikust suletusest täieliku avatuseni. Liiklust kontrollimise meetodeid arutame hiljem osades, mis on pühendatud kaitsevahenditele.
Võimalus kasutada kogu tuttavat seadmete spektrit
On mugav, kui teil on näiteks võimalus jätkata suhtlemiseks tuttavate vahendite kasutamist ka tööl. Seda on tehniliselt lihtne ellu viia. Selleks on vajalik WiFi ja külalis-VLAN.
On ka hea, kui on võimalus kasutada seda operatsioonisüsteemi, millele oled harjunud. Kuid minu kogemuse kohaselt lubatakse seda tavaliselt vaid juhtidele, administraatoritele ja arendajatele.
Näide
Muidugi võib minna keelustamise teed, keelata kaugjuurdepääs, keelata juurdepääs mobiilseadmetest, piirata kõik ainult staatiliste Etherneti ühendustega, piirata interneti juurdepääsu, kohustuslikult konfiskeerida mobiiltelefonid ja seadmed sissepääsul... ja mõned organisatsioonid, mis vajavad kõrgeid turvanõudeid, tõepoolest järgivad seda teed, ja võib-olla mõnes olukorras võib see olla mõistlik, kuid... nõustuge, et see näeb välja nagu katse peatada edusammud teatud organisatsioonis. Kindlasti tahaksin ühendada kaasaegsete tehnoloogiate pakutavad võimalused piisava turvalisustasemega.
"Kiire võrgu töö"
Andmeedastuskiirus on tehniliselt paljuski tingitud paljusid tegureid. Ja teie ühendusporta kiirus ei ole tavaliselt neist kõige olulisem. Rakenduse aeglane töö ei ole alati seotud võrguprobleemidega, kuid meid huvitab praegu ainult võrgupool. Kohalikku võrgukiirusprobleemi kõige levinum põhjus on pakettide kadumine. See juhtub tavaliselt pudelikaela efekti olemasolu tõttu või L1 (OSI) probleemide tõttu. Harvemini, mõnede disainide puhul (näiteks kui teie alamskeemides on vaikimisi väravatena tulemüür ja seega läbib kogu liiklus seda), võib seadmete jõudlusest puududa.
Seetõttu peate seadmete ja arhitektuuri valimisel arvesse võtma lõppportide, trunkide ja seadmete jõudlust.
Näide
Oletame, et kasutate juurdepääsu lülititena 1 gigabitise pordiga lüliteid. Need on omavahel ühendatud Etherchanneli kaudu 2 x 10 gigabitti. Vaikimisi väravana kasutate giigabitiste portidega tulemüüri, mille ühendamiseks L2 võrku kasutate 2 gigabitist porti, mis on ühendatud Etherchanneli kaudu.
See arhitektuur on funktsionaalsuse seisukohalt üsna mugav, kuna kogu liiklus läbib tulemüüri, ja teil on mugav hallata juurdepääsupoliitikaid ning rakendada keerulisi liikluse kontrollimise ja võimalike rünnakute vältimise algoritme (vt allpool). Kuid läbilaskevõime ja jõudluse seisukohalt on sellel kujundusel muidugi potentsiaalsed probleemid. Näiteks võivad 2 hosti, kes laadivad andmeid (1 gigabitise pordi kiirusel), täielikult koormata 2 gigabitise ühenduse tulemüüriga, mis põhjustab teenuse halvenemist kogu kontori segmendis.
Oleme vaadanud kolmnurga ühte tippu, nüüd uurime, milliste vahenditega saame tagada turvalisuse.
Kaitsevahendid
Nii et muidugi, tavaliselt on meie soov (täpsemalt meie juhtkonna soov) saavutada võimatu, nimelt pakkuda maksimaalset mugavust maksimaalse turvalisuse ja minimaalsete kuludega.
Vaadakem, millised meetodid meil on kaitse pakkumiseks.
Kontori jaoks tooksin esile järgmised:
- zero trust lähenemine disainis
- kõrge turvataseme tagamine
- võrgu nähtavus
- ühtne tsentraliseeritud autentimist ja autoriseerimist süsteem
- host'i kontrollimine
Jätkame igaühe aspekti lähemalt käsitlemist.
Zero Trust
IT maailm muutub väga kiiresti. Viimase 10 aasta jooksul on uute tehnoloogiate ja toodete ilmumine viinud tõsise muutuseni turvakontseptsioonides. Veel kümme aastat tagasi jagasime me võrku usaldusväärseteks, DMZ-ks ja mitteusaldusväärseteks tsoonideks ning kasutati nn "perimeetri kaitset", kus oli kaks kaitseliini: mitteusaldusväärne -> DMZ ja DMZ -> usaldusväärne. Ka kaitse piirdus enamasti L3/L4 (OSI) pealkirjade (IP, TCP/UDP portide, TCP lipud) põhiste juurdepääsuliste loenditega. Kõik, mis puudutas kõrgemaid tasandeid, sealhulgas L7, usaldati operatsioonisüsteemile ja lõpp-punkti kaitsetoodetele.
Praegu on olukord radikaalselt muutunud. Kaasaegne kontseptsioon tuleb sellest, et sisemisi, st perimeetri sees asuvaid, süsteeme ei saa enam usaldusväärseteks pidada ja perimeetri kontseptsioon on muutunud uduseks.
Lisaks internetiühendusele on meil samuti
- kasutajate kaugjuhtimise VPN
- erinevad isiklikud seadmed, toodud sülearvutid, mis on ühendatud läbi büroo WiFi
- teised (filiaal) kontorid
- integreerimine pilvi infrastruktuuriga
Kuidas näeb Zero Trust lähenemine praktikas välja?
Ideaalis peaks lubatud olema ainult see liiklus, mis on vajalik, ja kui me räägime ideest, peaks kontroll olema mitte ainult L3/L4 tasandil, vaid ka rakenduse tasandil.
Kui näiteks teil on võimalus suunata kogu liiklus läbi tulemüüri, siis saate püüda läheneda ideaalile. Kuid selline lähenemine võib oluliselt vähendada teie võrgu kogumahutavust ning rakenduse filter ei pruugi alati hästi töötada.
Liiklust marsruuteris või L3 lülitajas (standardsed ACL-id) kontrollides seisate silmitsi teiste probleemidega:
- see on ainult L3/L4 filter. Pole midagi, mis takistaks rünnakut kasutamast lubatud porte (nt TCP 80) oma rakenduse (mitte http) jaoks.
- keeruline ACL-i haldamine (ACL-i analüüsimine on keeruline)
- see ei ole stateful tulemüür, seega peate selgelt lubama pöördliiklust
- lülitite puhul olete tavaliselt üsna rangelt piiratud TCAM-i suurusega, mis lähenemise "luba ainult see, mis on vajalik" korral võib kiiresti probleemiks saada.
Note
Rääkides pöördliiklusest, peame meeles pidama, et meil on järgmine võimalus (Cisco)
luba tcp igal asukohal igas asukohas kehtestatud
Kuid tuleb mõista, et see rida on samaväärne kahe reaga:
luba tcp mis tahes mis tahes ack
luba tcp mis tahes mis tahes rstSee tähendab, et isegi kui algset TCP segmendi SYN lippu ei olnud (st TCP sessioon ei hakanud isegi seadma), lubab see ACL paketti ACK lipuga, mida ründaja võib kasutada andmete edastamiseks.
Teisisõnu, see rida ei muuda teie ruutrit või L3 lülitit statefull tulemüüriks.
Kõrge kaitsetase
Uues Andmekeskustele pühendatud jaos vaatasime järgmisi kaitsemeetodeid.
- stateful firewalling (vaikimisi)
- ddos/dos kaitse
- rakenduse tulemüüri (application firewalling)
- ohtude ennetamine (antivirus, antiviirus ja haavatavuse tõrje)
- URL filtreerimine
- andmete filtreerimine (sisu filtreerimine)
- failide blokeerimine (failitüüpide blokeerimine)
Kohapealse büroo olukord on sarnane, kuid prioriteedid on pisut erinevad. Büroo kättesaadavus (availability) ei ole tavaliselt nii kriitiline kui andmekeskuses, samas kui tõenäosus, et 'sise' pahatahtlik liiklus on palju kõrgem.
Seetõttu muutuvad järgmised kaitsemeetodid selles segmendis kriitiliseks:
- rakenduse tulemüüri (application firewalling)
- ohtude ennetamine (antiviirus, nuhkvarade eemaldamine ja haavatavuste haldamine)
- URL filtreerimine
- andmete filtreerimine (sisu filtreerimine)
- failide blokeerimine (failitüüpide blokeerimine)
Kuigi kõik need kaitsemeetodid, välja arvatud rakenduste tulemüür, on traditsiooniliselt lahendatud ja jätkuvalt lahendatakse lõpp-hostides (näiteks viirusetõrje tarkvara installimise kaudu) ja proxy kaudu, pakuvad kaasaegsed NGFW ka neid teenuseid.
Turbevarustuse tarnijad püüavad luua integreeritud kaitset, seega pakutakse koos kohapealse kaitsega ka erinevaid pilvetehnoloogiaid ja klienditarkvara hostide jaoks (end point protection/EPP). Näiteks, näeme, et Palo Alto ja Cisco omavad oma EPP-d (PA: Traps, Cisco: AMP), kuid ei ole kindlasti liidrite seas.
Nende kaitsete (tavaliselt litsentside ostmise kaudu) lubamine tulemüüri peal ei ole kindlasti kohustuslik (võite minna traditsioonilist teed), kuid see annab teatud eelised:
- Käesoleval juhul tekib ühtne kaitsemeetodite rakendamise punkt, mis parandab nähtavust (vt järgmist teemat).
- Kui teie võrgus on kaitsmata seade, siis see kuulub ikkagi tulemüüri kaitse 'varju'
- Kasutades kaitseid tulemüüri peal koos lõpp-hostide kaitsega, suurendame pahatahtliku liikluse tuvastamise tõenäosust. Näiteks, ohtude ennetamise kasutamine kohalikest hostidest ja tulemüürist suurendab tuvastamise tõenäosust (muidugi, tingimusel et nende lahenduste aluseks on erinevad tarkvaratooted).
Note
Näiteks, kui kasutate Kaspersky viirusetõrjet nii tulemüüris kui ka lõpp-punktides, ei suurenda see teie võimalusi oma võrku viirusrünnaku eest kaitsta.
Võrgu nähtavus
lihtsalt - „näha”, mis teie võrgus toimub, nii reaalajas kui ka ajaloolised andmed.
Jagaksin selle „nägemise” kaheks rühmaks:
Esimene rühm: see, mida tavaliselt pakub teie jälgimisüsteem.
- seadmete koormus
- kanalite koormus
- mälukasutus
- ketta kasutus
- suurendame marsruutimistabelit
- linkide seisund
- seadmete (või hostide) kättesaadavus
- …
Teine rühm: turvalisusega seotud teave.
- erinevat tüüpi statistika (nt rakenduste, URL-ide külastatavuse kohta, milliseid andmeid alla laaditi, kasutajate andmed)
- mis on turvapoliitikate poolt blokeeritud ja millistel põhjustel, nimelt
- keelatud rakendus
- blokeeritud ip/protokolli/port/flags/zonide alusel
- ründe tõkestamine
- URL-i filtreerimine
- andmete filtreerimine
- failide blokeerimine
- …
- DOS/DDOS rünnakute statistika
- ebaõnnestunud identifitseerimise ja autoriseerimise katsed
- statistika kõigi ülalnimetatud turvapoliitikate rikkumise sündmuste kohta
- …
Käesolevas turvalisusele pühendatud peatükis on meid huvitav just teine osa.
Mõned kaasaegsed tulemüürid (minu kogemuse järgi Palo Alto) pakuvad head nähtavuse taset. Kuid loomulikult peab teid huvitav liiklus minema läbi selle tulemüüri (sel juhul on teil võimalus liiklust blokeerida) või peegelduma tulemüüri (kasutatakse ainult jälgimiseks ja analüüsiks), ja teil peavad olema load, mis võimaldavad kõik need teenused sisse lülitada.
On muidugi ka alternatiivne tee, täpsemalt traditsiooniline tee, näiteks
- seansside statistikat saab koguda netflow kaudu ja seejärel kasutada spetsiaalseid tööriistu teabe analüüsimiseks ja andmete visualiseerimiseks
- ründe tõkestamine – spetsiaalsed programmid (viirusetõrje, nuhkvara kaitse, tulemüür) lõpp-punktides
- URL-i filtreerimine, andmete filtreerimine, failide blokeerimine – proxy kaudu
- ka saab analüüsida tcpdumpi näiteks
Saate need kaks lähenemist liita, täiustades puuduvate funktsioonide osas või nende dubleerimisega ründe tuvastamise tõenäosuse suurendamiseks.
Millist lähenemist valida?
Sõltub palju teie meeskonna kvalifikatsioonist ja eelistustest.
Mõlemal pool on nii plusse kui miinuseid.
Üksne tsentraliseeritud autentimise ja autoriseerimise süsteem
Hea disaini korral tähendab arutatud mobiilsus, et teil on võrdsed juurdepääsud, töötades kontoris, kodus, lennujaamas, kohvikus või mis tahes muus kohas (kitsendustega, millest me eespool rääkisime). Tundub ju, et mis probleem see on?
Kuna me tahame paremini mõista selle ülesande keerukust, vaatame üht tüüpilist disaini.
Näide
- Olete jaganud kõik töötajad gruppidesse. Olete otsustanud anda juurdepääsud gruppide kaupa
- Kontori sees kontrollite juurdepääse kontori tulemüüris
- Kontrollite kontorist andmekeskusesse suunatud liiklust andmekeskuse tulemüüris
- VPN-silla jaoks kasutate Cisco ASA-d ning liikluse kontrollimisel, mis siseneb teie võrgusse pühendatud klientidelt, kasutate kohalikke (ASA-s) ACL-e
Nüüd, eeldame, et teilt palutakse lisada täiendav juurdepääs teatud töötajale. Samuti palutakse lisada juurdepääs ainult temale ja mitte kellelegi tema grupist.
Selleks peame looma selle töötaja jaoks eraldi grupi, st
- ASA-s looma eraldi IP-aadresside ülesande selle töötaja jaoks
- lisama uue ACL-i ASA-s ja siduma selle selle eemaloleva kliendiga
- loomiseks uusi turvapoliitika kontori ja andmekeskuse tulemüürides
See on korras, kui see sündmus on haruldane. Kuid minu praktikas oli olukord, kus töötajad osalesid erinevates projektides ja see projektide kogum muutus mõne jaoks üsna sageli, ja see ei olnud 1-2 inimest, vaid kümneid. Loomulikult pidi siin midagi muutuma.
See lahendati järgmisel viisil.
Otsustasime, et ainsaks tõe allikaks, mis määratleb kõik võimalike töötajate juurdepääsud, on LDAP. Loodime igasuguseid gruppe, mis määratlevad juurdepääsu kogumeid ja iga kasutaja seoti ühe või mitme grupiga.
Nii näiteks, eeldame, et olid grupid
- külaline (juurdepääs internetile)
- ühised juurdepääsud (juurdepääs ühistele ressurssidele: e-post, teadmusbaas, …)
- rahandus
- projekt 1
- projekt 2
- andmebaasi administraator
- linuxi administraator
- …
Ja kui keegi töötajatest oli kaasatud nii projektis 1 kui ka projektis 2, ja tal olid vajalikud juurdepääsud nende projektide jaoks, siis see töötaja seoti vastavalt gruppidega:
- guest
- ühised juurdepääsud
- projekt 1
- projekt 2
Kuidas nüüd seda teavet muutuda juurdepääsudeks võrguseadmetes?
Cisco ASA dünaamiline pääsupoliitika (DAP) (vt. ) lahendus sobib just selliseks ülesandeks.
Lühidalt meie lahenduse kohta: tuvastamise/autentimise käigus saab ASA LDAPilt gruppide kogumi, mis vastab sellele kasutajale, ja "koondab" mitmest kohalikust ACL-ist (igaüks neist vastab grupile) dünaamilise ACL-i kõigi vajalike ligipääsudega, mis vastab täielikult meie soovidele.
Aga see kehtib ainult VPN-ühenduste jaoks. Et olukord oleks sama nii töötajatele, kes on ühendatud VPN-i kaudu, kui ka neil, kes on kontoris, tehti järgmine samm.
Kontoris ühendudes läksid kasutajad protokolli 802.1x kaudu kas külalisvilanisse (külalistele) või vilanisse koos ühiste ligipääsudega (firma töötajatele). Edasi, spetsiifiliste ligipääsude saamiseks (näiteks andmekeskuse projektidele) pidid töötajad ühenduma VPN-iga.
Kontorist ja kodust ühendamiseks kasutati ASA-l erinevaid tunneli gruppe. See on vajalik selleks, et kontorist ühendunud kasutajate liiklus ühistele ressurssidele (mida kasutavad kõik töötajad, nagu e-post, failiserverid, ticketite süsteem, dns, jne) ei läheks läbi ASA, vaid kohalikku võrku. Nii ei koormanud me ASA-d liigsete, sealhulgas kõrge intensiivsusega, liiklust.
Nii lahendati ülesanne.
Saime
- ühtse ligipääsuhulga nii kontorist ühendustest kui ka eemaloleku kaudu
- teenuse degradesiooni puudumine kontoris töötamisel, mis on seotud kõrge intensiivsusega liikluse edastamisega läbi ASA
Mis on veel selle lähenemise eelis?
Ligipääsude haldamises. Ligipääse on lihtne muuta, ühes kohas.
Näiteks, kui töötaja lahkub ettevõttest, siis kustutate ta lihtsalt LDAP-ist ja ta kaotab automaatselt kõik ligipääsud.
Hosti kontrollimine (host checking)
Kaugühenduse võimaldamisel saame riski, et võrku võivad siseneda mitte ainult ettevõtte töötajad, vaid ka kogu pahavara, mis tõenäoliselt on tema arvutis (näiteks kodus), ja veelgi enam, selle kaudu avame võib-olla juurdepääsu meie võrku ründajale, kes kasutab seda hosti proksina.
Mõistlik on kaugtöölise hosti jaoks rakendada samu turvanõudeid, mis kohaldatakse kontoris asuva hosti suhtes.
See hõlmab ka "õige" operatsioonisüsteemi, viirusetõrje, nuhkvaratõrje, tulemüüritarkvara ja värskendusi. Tavaliselt on see võimalus olemas VPN-i väravas (nt ASA jaoks vaata, ).
Samuti on mõistlik rakendada samu liikluse analüüsi ja blokeerimise meetodeid (vt "Kõrge kaitse tase"), mis vastavalt teie turvapoliitikale rakendatakse kontori liiklusele.
Mõistlik on eeldada, et teie kontver võrk ei piirdu enam vaid kontorihoone ja sealsete hostidega.
Näide
Hea lähenemine on varustada iga töötaja, kellel on vaja kaugjuurdepääsu, hea ja mugava sülearvutiga ning nõuda, et nad töötaksid nii kontoris kui ka kodus ainult sellest.
See mitte ainult ei suurenda teie võrgu turvalisust, vaid on ka tõeliselt mugav ja töötajad tavaliselt tajuvad seda positiivselt (kui tegemist on hea ja mugava sülearvutiga).
Mõõdukuse ja tasakaalu tunne
Põhimõtteliselt räägime meie kolmanda tipu — kulude — üle.
Vaadakem hüpoteetilist näidet.
Näide
Teie kontoris on 200 inimest. Olete otsustanud muuta selle võimalikult mugavaks ja ohutuks.
Seetõttu otsustasite parandada kogu liiklus läbi tulemüüri ja seega ühesugune kõikide kontori alamvõrkude jaoks on tulemüüri kehtestatud vaikimisi värav. Lisaks iga lõppseadmestikule paigaldatud turvatarkvarale (viirusetõrje, nuhkvaratõrje ja tulemüüritarkvara) otsustasite rakendada kõik võimalikud kaitsemeetodid tulemüüris.
Suurte ühenduskiirusse tagamiseks (kõik mugavuse nimel) valisite juurdepääsu lülititeks 10-gigabitised juurdepääsulülitid, tulemüürideks kõrge jõudlusega NGFW tulemüüri, näiteks Palo Alto seeria 7K (40-gigabitiste portidega), loomulikult kõigi litsentside aktiveerituna ja samuti kõrge kättesaadavuse paarina.
Samuti on tõepoolest selle seadmesarja tööks vaja vähemalt paari kõrgelt kvalifitseeritud turbeinseneri.
Seejärel otsustasite igale töötajale anda hea sülearvuti.
Kokku on see umbes 10 miljonit dollarit rakendamiseks, sadu tuhandeid dollareid (arvan, et lähemal miljonile) aastaseks toetuseks ja inseneride palkadeks.
Kontor, 200 inimest...
Mugav? Ilmselt jah.Te tulete oma ettepanekuga oma juhtide juurde ...
Võib-olla on maailmas mõni ettevõte, kus see on vastuvõetav ja õige lahendus. Kui olete selle ettevõtte töötaja - õnnitlen teid, aga enamikul juhtudel, olen kindel, et teie teadmisi ei hinnata juhit.
Kas see näide on liialdatud? Järgmine peatükk annab sellele küsimusele vastuse.
Kui teie võrgus ei näe te midagi ülaltoodust, siis see on normaalne.
Iga konkreetse juhtumi jaoks peate leidma mõistliku tasakaalu mugavuse, hinna ja turvalisuse vahel. Sageli pole teie kontoris isegi NGFW-d vaja, ega L7 kaitset tulemüüril. Piisab heast nähtavuse ja teavituste tasemest, ja seda saab teha näiteks avatud lähtekoodiga toodete abil. Jah, teie reageerimine rünnakule ei ole kohene, aga oluline on see, et te seda näete, ja õigete protsesside olemasolul teie osakonnas suudate selle kiiresti neutraliseerida.
Ja tuletan meelde, et nende artiklite tsükli eesmärk ei ole võrgu projekteerimine, vaid proovite parandada seda, mis teil olemas on.
SAFE arhitektuuri analüüs kontoris
Pöörake tähelepanu sellele punasele ruudule, millega ma esitlemise kaardil ära märkisin koha , mida soovin siin arutada.
See on üks arhitektuuri võtmealasid ja üks olulisemaid ebakindlusi.
Note
Ma ei ole kunagi seadistanud ega töötanud FirePoweriga (Cisco tulemüüride seeriast - ainult ASA-ga), seega vaatan seda nagu iga muud tulemüüri, näiteks Juniper SRX või Palo Alto, eeldades, et tal on samad võimalused.
Tavaliste konstruktsioonide puhul näen ainult 4 võimalikku tulemüüri kasutamise varianti antud ühenduse korral:
- igas alamvõrgus on vaikimisi lüüsiks lüliti, kusjuures tulemüür on läbipaistvas režiimis (st kogu liiklus läheb läbi selle, kuid see ei loo L3 hüpet)
- iga alamvõrgu vaikimisi lüüs on tulemüüri all-alamliidesed (või SVI liidesed), kus lüliti täidab L2 rolli
- lülitis on kasutusel erinevad VRF-id, ja liiklus VRF-ide vahel läheb läbi tulemüüri, samas kui ühes VRF-is toimub liikluse juhtimine lüliti ACL-i kaudu
- kogu liiklus peegeldatakse tulemüüri jaoks analüüsi ja jälgimise eesmärgil, kuid liiklus selle kaudu ei lähe
Märkus 1
Need combinations of these options are possible, but for simplicity, we will not consider them.
Заметка2
There is also the possibility of using PBR (service chain architecture), but for now, although I find this solution beautiful, it is rather exotic, so I will not consider it here.
From the description of the streams in the document, we see that traffic is indeed going through the firewall, which means that according to Cisco's design, the fourth option is eliminated.
Let's first look at the first two options.
In these options, all traffic goes through the firewall.
Now let's look , look and we see that if we want to have a total bandwidth for our office of at least around 10 - 20 gigabits, we need to buy the 4K version.
Note
When I talk about total bandwidth, I mean traffic between subnets (not within a single VLAN).
From the GPL, we see that for the HA Bundle with Threat Defense, the price varies depending on the model (4110 - 4150) from approximately 0.5 - 2.5 million dollars.
This means our design begins to resemble the previous example.
Does this mean that this design is incorrect?
No, it does not. Cisco provides you with the maximum possible protection based on the product line it has. But that doesn't mean this is a must-do for you.
In principle, this is a common question that arises when designing an office or data center, and it only means that a compromise must be sought.
For example, not all traffic needs to go through the firewall, and in this case, the third option seems quite appealing to me, or (see the previous section), maybe you don't need 'Threat Defense' or even a firewall in this segment of the network, and you can settle for passive monitoring using paid (not expensive) or open-source solutions, or a firewall is needed, but from a different vendor.
There is usually always this uncertainty, and there is no definitive answer as to what solution is best for you.
This is the complexity and beauty of this task.
Allikas: habr.com
