See artikkel on viies osa artiklite seeriast "Kuidas võtta oma võrguinfrastruktuur kontrolli alla". Kogu seeria sisu ja lingid on saadaval .
See osa keskendub Campus (Office) ja Remote access VPN segmentidele.
Tundub, et kontorivõrgu kujundamine on lihtne.
Tõepoolest, võtame L2/L3 lülitid, ühendame need omavahel. Seejärel teeme elementaarse soovitud seadistuse, vaikimisi väravate seadistamise, loome põhivoogud, ühendame WiFi kontrollerid, pääsupunktid, installime ja seadistame ASA kaugjuurdepääsuks ning rõõmustame, et kõik töötab. Üldiselt, nagu ma juba mainisin ühes varasemas selles seerias, võib kontorivõrgu kavandada ja seadistada nii, et "muidugi töötab," peaaegu iga tudeng, kes on läbinud (ja omandanud) kaks semestrit telekommunikatsiooni kursust.
Aga mida rohkem teate, seda keerulisemaks tundub see ülesanne. Minu jaoks ei tundu kontorivõrgu kujundamise teema üldse lihtne, ja selles artiklis püüan selgitada, miks.
Lühidalt öeldes on arvesse võetavaid tegureid üsna palju. Tihti on need tegurid omavahel vastuolus ja tuleb leida mõistlik kompromiss.
Just see ebamugavustunne on peamine keerukus. Rääkides turvalisusest, oleme silmitsi kolmnurgaga, mille kolm tippu on: turvalisus, kasutusmugavus ja lahenduse hind.
Ja iga kord tuleb leida kompromiss nende kolme vahel.
Arhitektuur
Nende kahe sektori arhitektuuri näitena soovitan, nagu ka eelnevalt artiklites, mudelit: , .
Need on mõnevõrra vananenud dokumendid. Toon nad siin välja, kuna põhimõtteliselt ei ole skeemid ja lähenemine muutunud, kuid esitlus meeldib mulle rohkem kui .
Kuigi ma ei kutsu teid üles kasutama just Cisco lahendusi, pean siiski tõeliseks kasulikuks põhjalikult uurida seda disaini.
Käesolev artikkel, nagu tavaliselt, ei pretendeeri täielikkusele ja on pigem täienduseks sellele teabele.
Artikli lõpus analüüsime Cisco SAFE disaini kontoris nende konseptsioonide valguses, mida siin esitatakse.
Üldised printsiibid
Kontorivõrgu kujundus peab kindlasti vastama üldistele nõudmistele, mida on arutatud peatükis „Kvaliteedi hindamise kriteeriumid“. Lisaks hinnale ja turvalisusele, mida kavatseme käesolevas artiklis arutada, on veel kolm kriteeriumi, mida peame arvesse võtma projekteerimisel (või muudatuste tegemisel):
- mõõdetavus (scalability)
- haldamise mugavus (managability)
- saadavus (availability)
Paljusid teemasid, mida on käsitletud katab ka kontorit.
Kuid kontorisegment on siiski oma eripäraga, mis on turvalisuse seisukohalt kriitiline. Selle eripära olemus seisneb selles, et see segment on loodud pakkuma võrgu teenuseid ettevõtte töötajatele (ja samuti partneritele ja külalistele) ning seetõttu seisneb kõige kõrgel tasemel probleemide arutamisel kahes ülesandes:
- kaitsta ettevõtte ressursse pahatahtlike tegevuste eest, mis võivad tulla töötajatelt (külalistelt, partneritelt) ja kasutatavatelt tarkvaradelt. Siia kuulub ka kaitse volitamata ühenduste eest võrguga.
- kaitsta kasutajate süsteeme ja andmeid
Ja see on vaid probleemi üks külg (täpsemalt öeldes üks kolmnurga tipp). Teisel pool on kasutajamugavus ja rakendatavate lahenduste hind.
Alustame sellest, mida kasutaja tänapäevaselt kontvervõrgult ootab.
Mugavused
Nii näevad mu arvates „võrgumugavused“ kontoritöötaja jaoks:
- Liikuvus
- Võime kasutada kogu tunnete seadmete ja operatsioonisüsteemide spektrit
- Lihtne ligipääs kõikidele ettevõtte vajalikutele ressurssidele
- Internetiressursside kergesti kättesaadavus, sealhulgas erinevad pilveteenused
- Võrgu "kiire töö"
See kehtib nii töötajate kui ka külaliste (või partnerite) kohta, ja see on juba inseneride ülesanne, et autoriseerimise põhjal eristada juurdepääsu erinevatele kasutajagruppidele.
Vaadakem iga selle aspekti veidi põhjalikumalt.
Liikuvus
Jutt käib võimalusest töötada ja kasutada kõiki ettevõtte vajalikke ressursse igast maailma punktist (loomulikult seal, kus on internetiühendus).
See, et kehtib täielikult ka kontori kohta. See on mugav, kui teil on võimalus igast kontori nurgast edasi töötada, näiteks e-kirju lugeda, suhelda ettevõttevestluses, olla kergesti kättesaadav videokõnede jaoks jne. Nii et see võimaldab teil ühtaegu tegeleda mõned küsimused „otse” suhtlemise kaudu (näiteks osaleda koosolekutel) ja olla pidevalt online, käia asjadega kursis ja kiiresti lahendada mõned kiireloomulised ja kõrge prioriteediga ülesanded. See on väga mugav ja tõepoolest parandab suhtluse kvaliteeti.
Seda saavutatakse WiFi võrgu õige disainiga.
Märkus
Siin tekib tavaliselt küsimus, kas piisab ainult WiFi kasutamisest? Kas see tähendab, et võib loobuda Etherneti portide kasutamisest kontoris? Kui rääkida ainult kasutajatest ja mitte serveritest, mida on siiski mõistlik ühendada tavalise Etherneti portiga, siis üldiselt on vastus: jah, saab piirduda vaid WiFi kasutamisega. Kuid on nüansse.
On olemas olulised kasutajagruppid, kellele tuleb läheneda eraldi. Need on muidugi administraatorid. Üldiselt on WiFi ühendus vähem usaldusväärne (traffici kadumise osas) ja aeglasem kui tavaline Etherneti port. See võib olla administreerijate jaoks oluline. Lisaks võivad näiteks võrguadministraatoritel olla oma eraldi Etherneti võrgud out-of-band-ühenduseks.
Võimalik, et teie ettevõttes on ka teisi gruppe/osakondi, kelle jaoks need tegurid on samuti olulised.
On veel üks oluline punkt – telefoniteenus. Võimalik, et mingil põhjusel ei soovi te kasutada Wireless VoIP teavet ja eelistate kasutada IP telefone tavalise Etherneti ühenduse kaudu.
Üldiselt, nendes ettevõtetes, kus olen töötanud, oli tavaliselt võimalus kasutada nii WiFi-ühendust kui ka Etherneti porti.
Sooviksin, et mobiilsus ei piirduks ainult kontoriga.
Kodus (või mõnest muust kohast, kus on internetiühendus) töötamiseks kasutatakse VPN-ühendust. Samas on soovitatav, et töötajad ei tunneks vahet kodus töötamise ja kaugtegevuse vahel, mis eeldab samu juurdepääse. Kuidas seda korraldada, arutame veidi hiljem peatükis „Ühtne tsentraliseeritud autentimise ja autoriseerimise süsteem“.
Märkus
Tõenäoliselt ei õnnestu teil pakkuda kaugtegevuseks sama teenuste kvaliteeti nagu kontoris. Oletame, et VPN-väravana kasutate Cisco ASA 5520. Vastavalt seeadevice suudab „seedida“ vaid 225 Mbit VPN liiklust. See tähendab, et VPN-i ühenduse läbilaskevõime on tugevalt erinev kontorist töötades. Kui aga miski põhjustab viivitusi, andmekadu või jitters (näiteks kui soovite kasutada kontori IP telefoniteenuseid), siis ei saa te samuti seda kvaliteeti, nagu kontoris viibides. Seetõttu, kui räägime liikuvusest, peame meeles pidama võimalikke piiranguid.
Lihtne juurdepääs kõikidele ettevõtte ressurssidele
See probleem tuleks lahendada koostöös teiste tehniliste osakondadega.
Ideaalne olukord on see, kui kasutaja peab autentima ennast ainult üks kord ja seejärel pääseb ligi kõikidele vajalikele ressurssidele.
Lihtsa juurdepääsu tagamine ilma turvalisuse kahjustamiseta võib märkimisväärselt suurendada töö efektiivsust ja vähendada teie kolleegide stressi taset.
Märkus 1
Ligipääs ei seisne ainult selles, kui tihti peate parooli sisestama. Näiteks, kui teie turvapoliitika kohaselt peate kontorist andmekeskusesse ühendama minnes esmalt sisse logima VPN-i väravasse ja seetõttu kaotate juurdepääsu kontori ressurssidele, on see samuti väga ebamugav.
Märkus 2
On teenuseid (näiteks juurdepääs võrgu seadmetele), kus me tavaliselt kasutame oma eraldiseisvaid AAA-servereid, ning sellistes olukordades on normaalne, et tuleb mitmeid kordi autentida.
Internetis esinevaressursside kättesaadavus
Internet ei ole ainult meelelahutus, vaid ka teenuste kogum, mis võib olla väga kasulik tööks. On ka puhtalt psühholoogilisi aspekte. Kaasaegne inimene on interneti kaudu paljude virtuaalsete sidemetega seotud teiste inimestega ning minu arvates pole midagi halba selles, kui ta jätkab selle sideme tundmist ka töötamise ajal.
Aja kaotuse seisukohalt pole midagi traagilist, kui töötajal on näiteks Skype avatud ja ta kulutab 5 minutit lähedasega suhtlemiseks, kui see on vajalik.
Kas see tähendab, et internet peab alati olema kergesti ligipääsetav, ning et töötajatele võib anda juurdepääsu kõigile ressurssidele ilma igasuguse kontrollita?
Ei, see ei tähenda, loomulikult. Interneti avatus võib olla erinev erinevates ettevõtetes – täielikust suletusest täieliku avatuseni. Liikluskontrolli meetodeid arutame hiljem jaotistes, mis on pühendatud kaitsevahenditele.
Võimalus kasutada kogu tuttavat seadmevalikut
On mugav, kui teil on näiteks võimalus jätkata oma tuttavate kommunikatsioonivahendite kasutamist ka tööl. See ei ole tehniliselt keeruline. Selleks on vajalik WiFi ja külalis-VLAN.
Samuti on hea, kui on võimalus kasutada seda operatsioonisüsteemi, millele olete harjunud. Kuid minu tähelepanekute kohaselt lubatakse seda tavaliselt ainult juhtidele, administraatoritele ja arendajatele.
Näide
Jah, võib muidugi valida keelduvate meetmete tee, keelata kaugjuurdepääs, keelata ühendamine mobiilseadmetega, piirata kõik statiliste Ethernet-ühendustega, piirata juurdepääsu internetile, kohustuslikult konfiskeerida mobiiltelefonid ja seadmed kontrollpunktis … ja mõnel organisatsioonil, millel on kõrgendatud turvanõuded, on tõepoolest sellel teel minek, ja ilmselt on mõnes olukorras see ka õigustatud, kuid … nõustuge, et see näeb välja nagu katse peatada progress üksikute organisatsioonide sees. Loomulikult tahaksin siduda kaasaegsete tehnoloogiate võimalused piisava turvatasemega.
Võrgu "kiire töö"
Andmeside kiirus kujuneb tehniliselt paljusid tegureid. Ja teie ühenduse portide kiirus ei ole tavaliselt neist kõige olulisem. Rakenduste aeglustumise põhjused ei ole alati seotud võrguprobleemidega, kuid praegu keskendume ainult võrgutasandile. Kõige levinum probleem, mis põhjustab kohalikus võrgus „aeglustumist”, on andmepakettide kaotus. See juhtub tavaliselt pudelikaela efekti või L1 (OSI) probleemide tõttu. Harvem, teatud disainide korral (nt, kui teie allvõrkudes on vaikimisi väravid tulemüürid ja seega läheb kogu liiklus nende kaudu) võib seadmete jõudlusest puududa.
Seetõttu peate varustuse ja arhitektuuri valimisel arvestama lõpp-pordide, trunkide kiiruste ja seadmete jõudlusega.
Näide
Oletame, et kasutate lülititena 1 gigabiti porte. Need on omavahel ühendatud Etherchanneli kaudu 2 x 10 gigabitti. Vaikimisi väravana kasutate tulekahju seina, millel on gigabiti pordiühendused; selle liitmiseks kontori L2-võrguga kasutate 2 gigabiti porti, mis on ühendatud Etherchanneliga.
See arhitektuur on funktsionaalsuse mõttes üsna mugav, kuna kogu liiklus läbib tulekahju seina, ning saate mugavalt hallata juurdepääsupoliitikaid ja rakendada keerulisi liikluskontrolli algoritme ja ennetada võimalikke rünnakuid (vt edasi). Siiski, läbilaskevõime ja jõudluse mõttes võib selle disainil olla potentsiaalseid probleeme. Näiteks võivad 2 hosti, mis laadivad andmeid (1 gigabiti portaadi kiirusel), täielikult koormata 2 gigabiti ühenduse tulekahju seinaga, põhjustades seeläbi teenuse halvenemist kogu kontorisegmendile.
Oleme uurinud ühe kolmnurga tipu; nüüd vaatame, kuidas saame tagada turvalisuse.
Kaitsemeetmed
Nii et, loomulikult on meie soov (või täpsemalt öeldes meie juhtkonna soov) saavutada võimatut, nimelt tagada maksimaalne mugavus maksimaalse kaitse ja minimaalse hinnaga.
Vaatame, millised meetodid meil kaitse tagamiseks on.
Kontori jaoks tooksin esile järgmised:
- zero trust lähenemine kujunduses
- kõrge kaitsetase
- võrgu nähtavus
- ühtne tsentraliseeritud autentimise ja autoriseerimise süsteem
- host'i kontrollimine (host checking)
Arutame igaühe kohta veidi põhjalikumalt.
Zero Trust
IT maailm muutub väga kiiresti. Viimase 10 aasta jooksul on uute tehnoloogiate ja toodete tulek viinud turvakonseptsioonide tõsise ümbervaatamiseni. Veel kümme aastat tagasi, turvasaamisest rääkides, jagasime võrku usaldusväärseteks, DMZ- ja usaldusväärseteks tsoonideks ning kasutati nn "äärmuslikku kaitset", kus oli kaks kaitseliini: usaldusväärne -> DMZ ja DMZ -> usaldusväärne. Samuti piirdus kaitse tavaliselt L3/L4 (OSI) pealkirjade (IP, TCP/UDP portid, TCP lipud) põhiste juurdepääsu loeteludega. Kõik, mis puudutas kõrgemaid tasandeid, sealhulgas L7, jäi operatsioonisüsteemide ja lõpp-hostide kaitsetoodete hooleks.
Praegune olukord on kardinaalselt muutunud. Kaasaegne kontseptsioon lähtub sellest, et ei saa enam pidada sisemisi, st perimeetri sees asuvaid süsteeme usaldusväärseteks, ning perimeetri kontseptsioon on ise muutunud ähmaseks.
Lisaks internetiühendusele on meil ka
- remote access VPN kasutajad
- erinevad isiklikud seadmed, toimetatud sülearvutid, mis on ühendatud kontori WiFi-ga
- teised (filiaal) bürood
- integratsioon pilvealustesse
Kuidas näeb Zero Trust lähenemine välja praktikas?
Ideaalis tuleks lubada ainult see liiklus, mis on vajalik ja kui me räägime ideaalist, siis peaks kontroll toimuma mitte ainult L3/L4 tasandil, vaid ka rakendustasandil.
Kui teil on näiteks võimalus suunata kogu liiklus tulemüürist läbi, siis võite püüda saavutada ideaalset olukorda. Kuid selline lähenemine võib oluliselt vähendada teie võrgu kogusidekiirus, ja lisaks ei pruugi rakendustasandi filtreerimine alati hästi töötada.
Kui te kontrollite liiklust ruuteris või L3 lülitites (kasutades standardseid ACL-e), seisate silmitsi teiste probleemidega:
- see on ainult L3/L4 filtreerimine. Miski ei takista kurjategijal kasutamast lubatud porte (näiteks TCP 80) oma rakenduse jaoks (mitte http)
- keeruline ACL-i haldamine (raske analüüsida ACL-e)
- see ei ole statefull tulemüür, see tähendab, et peate selgelt lubama tagasiviivat liiklust
- lülitite puhul olete tavaliselt üsna range TCAM-i suuruse piirdumisega, mis võib lähenemise "lubada ainult vajalik" korral kiiresti probleemiks muutuda
Märkus
Rääkides tagasiviivast liiklusest, peame meeles pidama, et meil on järgmine võimalus (Cisco)
luba tcp any any established
Aga tuleb mõista, et see rida on samaväärne kahe reale:
luba tcp any any ack
luba tcp any any rstSee tähendab, et isegi kui algset TCP segmenti SYN lipuga (st TCP seanss ei alustanud isegi loomist) ei olnud, lastakse see ACL pakett läbi ACK lipuga, mida ründaja võib kasutada andmete edastamiseks.
Seega ei muuda see rida mingil juhul teie ruuterit või L3 lülitit statefull tulemüüriks.
Korke tase kaitse.
V Andmekeskustele pühendatud jaotises vaatasime järgmisi kaitsemeetodeid.
- stateful firewalling (vaikimisi)
- ddos/dos kaitse
- rakenduse tulemüür
- ohtude ennetamine (viirusevastane, nuhkvara ja haavatavus)
- URL-i filtreerimine
- andmete filtreerimine (sisu filtreerimine)
- failide blokeerimine (failitüüpide blokeerimine)
Kontori puhul on olukord sarnane, kuid prioriteedid on veidi teised. Kontori kättesaadavus (availability) ei ole tavaliselt nii kriitiline kui andmekeskuses, samas kui „sisemise“ kahjuliku liikluse tõenäosus on järsult suurem.
Seetõttu muutuvad järgmised kaitsemeetodid selle segmendi jaoks kriitiliseks:
- rakenduse tulemüür
- ohtude ennetamine (antivirus, anti-spyware ja haavatavuste haldamine)
- URL-i 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õppjaamade (nt viirusetõrjeprogrammide installimisega) ja prokside kaudu, pakuvad tänapäeva NGFW ka neid teenuseid.
Turvatehnika tarnijad püüavad luua terviklikku kaitset, seetõttu pakutakse kohaliku seadme kaitse kõrval erinevaid pilvetehnoloogiaid ja klienditarkvara (lõpp-punkti kaitse / EPP). Näiteks, näeme, et Palo Alto ja Cisco omavad oma EPP-d (PA: Traps, Cisco: AMP), kuid ei asu kaugel liidrite kohal.
Nende kaitsete (tavaliselt litsentside ostmise kaudu) aktiveerimine tulemüüri peal pole muidugi kohustuslik (võite minna traditsioonilist teed), kuid see annab teatud eeliseid:
- sel juhul tekib ühtne punkt kaitsemeetodite rakendamiseks, mis parandab nähtavust (vaata järgmist teemat).
- kui teie võrgus on kaitsmata seade, siis kuulub see siiski tulemüüri kaitse „päikese varju“.
- kasutades tulemüüri kaitset koos lõpp-punktide kaitsega, suurendame kahjuliku liikluse tuvastamise tõenäosust. Näiteks kohalike lõpp-punktide kaitse ja tulemüüri threat prevention'i kasutamine suurendab tuvastamise tõenäosust (loomulikult, eeldusel, et nende lahenduste aluseks on erinevad tarkvaratooted)
Märkus
Kui näiteks kasutate nii tulemüüri kui ka lõpp-punktide jaoks viirusetõrjena Kaspersky't, siis see ei suurenda oluliselt teie võimalusi viirusrünnaku ennetamiseks teie võrgus.
Võrgu nähtavus
lihtsalt – "näha", mis teie võrgus toimub, nii reaalajas kui ka ajaloolised andmed.
Jagaksin seda "nägemist" kaheks rühmaks:
Esimene rühm: see, mida teie jälgimisseade tavaliselt pakub.
- seadmete koormus
- kanalite koormus
- mälu kasutamine
- ketta kasutamine
- marsruudimistabeli muutmine
- linkide olek
- seadmete (või lõpp-punktide) kättesaadavus
- …
Teine rühm: turvalisusega seotud teave.
- erinevat statistika tüübid (nt rakenduste kohta, URL-i liikluse kohta, milliseid andmeid allitati, kasutajate andmed)
- mida on blokeeritud turvapoliitikate tõttu ja millistel põhjustel, nimelt
- keelatud rakendus
- keelatud IP/protokolli/port/flaagi/piirkonna alusel
- ohtude ennetamine
- URL-i filtreerimine
- andmete filtreerimine
- failide blokeerimine
- …
- statistika DOS/DDoS rünnakute kohta
- ebamugavad tuvastamise ja autentimise katsed
- statistika kõigi eelpool nimetatud turvapoliitikate rikkumiste sündmuste kohta
- …
Käesolevas peatükis, mis käsitleb turvalisust, huvitab meid just teine osa.
Mõned kaasaegsed tulemüürid (näiteks minu kogemustest Palo Alto) pakuvad head nähtavuse taset. Kuid muidugi peab teid huvitav liiklus läbima selle tulemüüri (sellisel juhul on teil võimalus liiklust blokeerida) või olema sellele suunatud (kasutatakse ainult jälgimiseks ja analüüsiks), ning teil peavad olema litsentsid, mis võimaldavad neid teenuseid aktiveerida.
On loomulikult ka alternatiivne tee, ehk täpsemalt traditsiooniline tee, näiteks,
- Seansside statistikat saab koguda NetFlow'i kaudu ja seejärel kasutada spetsiaalseid tööriistu teabe analüüsimiseks ja andmete visualiseerimiseks.
- ohuhindamine – spetsiaalsed programmid (antiviirus, antispioon, tulemüür) lõpp-seadmetes.
- URL-i filtreerimine, andmete filtreerimine, failide blokeerimine – proxy kaudu.
- Lisaks saab analüüsida tcpdump'i, kasutades näiteks.
Nende kahe lähenemise kombinatsioon on võimalik, täiustades puuduvaid funktsioone või dubleerides neid rünnaku avastamise tõenäosuse suurendamiseks.
Millist lähenemist valida?
See sõltub tugevalt teie meeskonna kvalifikatsioonist ja eelistustest.
Mõlemal lähenemisel on nii plusse kui miinuseid.
Ühtne kesksüsteem autentimiseks ja volitamiseks.
Hea disaini korral peaks teie arutatud mobiilsus tähendama, et teil on ühtlased õigused tööl või kodus, lennujaamas, kohvikus või igas muus kohas (koos piirangutega, millest oleme eespool rääkinud). Miks see probleem on?
Selle ülesande keerukust paremini mõista, vaatame tüüpilist disaini.
Näide
- Olete jaganud kõik töötajad rühmadesse. Olete otsustanud anda juurdepääsu rühmade kaupa.
- Kontrollite kontorist juurdepääse kontori tulemüüril
- Kontrollite liiklust kontorist andmekeskusesse andmekeskuse tulemüüril
- VPN-lüüsina kasutate Cisco ASA-d ning liikluse kontrollimiseks, mis teie võrgusse siseneb määratud klientidelt, rakendate kohalikke (ASA-l) ACL-e
Nüüd oletame, et teilt palutakse lisada kindlale töötajale täiendav juurdepääs. Samuti palutakse teil lisada juurdepääs ainult temale ja mitte kellelegi tema grupist.
Selleks peame looma selle töötaja jaoks eraldi grupi, st
- luua ASA-l eraldi IP-aadresside bassein selle töötaja jaoks
- lisada uus ACL ASA-le ja siduda see selle kaugkliendiga
- luua uued turvapoliitikad kontori ja andmekeskuse tulemüürides
See on hea, kui see sündmus on haruldane. Kuid minu praktikas on olnud olukordi, kus töötajad osalesid erinevates projektides ja see projektide kogum muutus mõnede jaoks üsna sageli, ja see ei olnud 1-2 inimest, vaid kümneid. Loomulikult oli siin midagi muuta.
See lahendati järgmisel viisil.
Oleme otsustanud, et ainsaks tõeallikaks, mis määratleb kõik töötaja võimalikud ligipääsud, on LDAP. Oleme loonud kõikvõimalikud rühmad, mis määravad ligipääsude kogumid, ja iga kasutaja seondus ühe või mitme rühmaga.
Näiteks oletame, et olid rühmad
- guest (Internet’i ligipääs)
- common access (ligipääs ühistele ressurssidele: postkast, teadmebaas, …)
- accounting
- project 1
- project 2
- data base administrator
- linux administrator
- …
Ja kui mõni töötaja oli seotud nii projektis 1 kui ka projektis 2 ning tal olid vajalikud ligipääsud nende projektide jaoks, siis seondus see töötaja vastavalt rühmadega:
- guest
- common access
- project 1
- project 2
Kuidas nüüd see info muuta ligipääsudeks võrgu seadmetes?
Cisco ASA Dynamic Access Policy (DAP) (vt. ) lahendus sobibki selle ülesande jaoks.
Lühidalt öeldes saab ASA LDAP-ist kogumi rühmi, mis vastavad kasutajale, ja koostab mitmest kohalikust ACL-ist (igaühe puhul, mis vastab rühmale) dünaamilise ACL-i, mis sisaldab kõiki vajalikke ligipääse, mis vastab täielikult meie soovidele.
Kuid see kehtib ainult VPN-ühenduste puhul. Et muuta olukord sama kaugtöötajatele ja kontoris viibivatele töötajatele, tehti järgmine samm.
Kontorist ühendamisel pääsevad kasutajad 802.1x protokolli kaudu kas külaliste VLAN-i (külaliste jaoks) või ettevõtte töötajate ühise ligipääsu VLAN-i. Edasi, et saada spetsiifilisi ligipääse (näiteks andmekeskuse projektidele), pidid töötajad ühenduma VPN-iga.
Kontorist ja kodust ühendamiseks kasutati erinevaid tunneligruppe ASA-s. See on vajalik, et kontoris ühenduse loonud kasutajad saaksid liikuda ühiste ressursside (mille kasutavad kõik töötajad, nagu e-post, failiserverid, piletisüsteem, DNS jne) kaudu mitte ASA, vaid kohaliku võrgu kaudu. Nii ei koormata me ASA-d liigse liiklusega, sealhulgas kõrge intensiivsusega.
Nii et probleem lahendati.
Saime
- ühtse juurdepääsu komplekti nii kontoris ühendustes kui ka kaugühendustes.
- teenuse mittehalvenemine kontoris töötades, mis on seotud kõrge intensiivsusega liikluse edastamisega ASA kaudu.
Millised on veel selle lähenemise eelised?
Ligipääsude haldamises. Ligipääse on lihtne muuta, ühes kohas.
Näiteks, kui töötaja lahkub ettevõttest, siis lihtsalt kustutate ta LDAP-st ja ta kaotab automaatselt kõik juurdepääsud.
Hosti kontrollimine (host checking)
Kaugühenduse korral on meil oht lubada võrku mitte ainult ettevõtte töötaja, vaid ka kogu pahavara, mis tõenäoliselt on tema arvutis (näiteks koduomas), ning veelgi enam, selle tarkvara kaudu avame me võib-olla juurdepääsu meie võrku kurjategijale, kes kasutab seda hostit nagu proksit.
On mõistlik rakendada kaugühenduses olevale hostile samu turvanõudeid, nagu kontoris olevatele hostidele.
See hõlmab ka „õige“ operatsioonisüsteemi versiooni, viirusetõrjet, nuhkvara kaitset ja tulemüüritarkvara ning uuendusi. Tavaliselt on see võimalus VPN-i väravas (näiteks ASA puhul vaata) ).
Samuti on mõistlik rakendada samu analüüsi ja liiklusblokeerimise meetodeid (vt „Kõrge kaitse tase“), nagu teie turvapoliitika kohaselt rakendatakse kontoriliiklusele.
On mõistlik eeldada, et nüüd ei piirdu teie kontori võrk enam kontoriruumiga ja sealsetega hostidega.
Näide
Hea lähenemine on varustada iga töötaja, kellel on kaugjuurdepääsu vajadus, hea ja mugava sülearvutiga ning nõuda, et nad töötaksid nii kontoris kui ka kodus ainult sellega.
See mitte ainult ei tõsta teie võrgus turvalisuse taset, vaid on ka tõeliselt mugav ja töötajad võtavad seda tavaliselt positiivselt (kui see tõepoolest on hea ja mugav sülearvuti).
Mõõdukuse ja tasakaalu tunnetamine
Põhimõtteliselt räägime kolmandast tipus meie kolmnurgas – hinnast.
Vaatame hüpoteetilist näidet.
Näide
Teie büroo mahutab 200 inimest. Otsustasite muuta selle võimalikult mugavaks ja võimalikult turvaliseks.
Seetõttu otsustasite kogu liikluse suunata tulemüürist läbi ja seeläbi on tulemüür kõigi büroo alamvõrkude vaikimisi värav. Lisaks igas lõpp-punktis installitud turvatarkvarale (viirusetõrje, nuhkvaratõrje ja tulemüüritarkvara) otsustasite rakendada tulemüüris kõiki võimalikke kaitsemeetmeid.
Kõrge ühenduse kiirusest (kõik mugavuse huvides) lähtudes olete valinud juurdepääsu ümberlülititena 10 gigabitti juurdepääsuportidega lülitid ning tulemüüridena kõrgetasemelised NGFW tulemüürid, näiteks Palo Alto seeria 7K (40 gigabitti portidega), loomulikult kõigi vajalike litsentsidega ja loomulikult High Availability paari.
Samuti vajame selle seadme seeria jaoks vähemalt paari kõrge kvalifikatsiooniga turbeinseneri.
Edasi otsustasite iga töötaja jaoks anda korraliku sülearvuti.
Kokku on rakendamiseks umbes 10 miljonit dollarit, sadade tuhandete dollarite (arvan, et lähemal miljonile) väärtuses igaaastaseks toeks ja inseneride palkadeks.
Kontor, 200 inimest…
Mugav? Võib-olla, jah.Tulete selle ettepanekuga oma juhtkonna juurde...
Võib-olla on maailmas olemas mõni ettevõte, kelle jaoks on see vastuvõetav ja õige lahendus. Kui olete selle ettevõtte töötaja — õnnitlused, kuid enamiku juhtumite puhul, olen kindel, et teie teadmisi ei osata juhtkonna poolt hinnata.
Kas see näide on liiga liialdatud? Järgmine peatükk annab sellele küsimusele vastuse.
Kui teie võrgus ei näe te midagi eespool loetletud, siis see on normaalne.
Iga konkreetse juhtumi puhul peate leidma mõistliku tasakaalu mugavuse, hinna ja turvalisuse vahel. Sageli pole teie kontoris isegi NGFW-d vaja, samuti ei ole L7 kaitse tulemüüri peal vajalik. Piisab, kui tagada hea visibility ja teavitused, ja seda saab saavutada näiteks open source toodete abil. Jah, teie reageering rünnakule ei ole kohene, kuid oluline on, et te märkate seda, ja kui teie osakonnas on õiged protsessid, suudate selle kiiresti neutraliseerida.
Ja meenutan, et nende artiklite tsükli mõte ei ole teie võrgu projekteerimine, vaid selle parandamine, mis teil on.
SAFE arhitektuuri analüüs kontoris
Pöörake tähelepanu sellele punasele kvadratile, millega olen esile tõstnud koha schemas , mida sooviksin siin arutada.
See on üks arhitektuuri võtmealasid ja üks olulisemaid määramatuseid.
Märkus
Ma ei ole kunagi seadistanud ega töötanud FirePoweriga (Cisco tulemüüride seeriast - ainult ASA-ga), seega käsitlen seda nagu mõnda muud tulemüüri, näiteks Juniper SRX või Palo Alto, eeldades, et sellel on samad funktsioonid.
Tavapäraste lahendustega näen ma vaid 4 võimalikku tulemüüri kasutamise varianti sellise ühenduse puhul:
- iga alamsüsteemi vaikevahetus on lüliti, samal ajal kui tulemüür töötab läbipaistvas režiimis (st kogu liiklus läbib selle, kuid ei loo L3 hüpet)
- iga alamsüsteemi vaikevahetus on tulemüüri alamliidesed (või SVI liidesed), lüliti täidab L2 rolli
- lülitil kasutatakse erinevaid VRF-e, ja liiklus VRF-ide vahel läbib tulemüüri, liiklust ühe VRF-i sees kontrollivad ACL-id lülitil
- kogu liiklus peegeldatakse tulemüüril analüüsiks ja jälgimiseks, liiklus ei lähe selle kaudu
Märkus 1
Nende variantide kombinatsioonid on võimalikud, kuid lihtsuse huvides ei käsitle me neid.
Märkus2
Samuti on olemas võimalus kasutada PBR-i (teenuse ahela arhitektuur), kuid siiani on see, kuigi minu arvates ilus lahendus, pigem eksootiline, seega ma ei arva seda siin.
Dokumendi voogude kirjeldusest näeme, et liiklus siiski läheb läbi tulemüüri, seega vastavalt Cisco kujundusele neljas variant langeb välja.
Vaatame esmalt kaht esimest varianti.
Nende variantide puhul läheb kogu liiklus läbi tulemüüri.
Nüüd vaatame , vaatame ja näeme, et kui me tahame meie kontorile vähemalt 10–20 gigabitti kogulaiust, peame ostma 4K versiooni.
Märkus
Kui ma räägin kogulaiusest, siis mõtlen ma liiklust alamvõrkude vahel (mitte ühe VLAN-i sees).
GPL-ist näeme, et HA Bundle'i hind koos Threat Defense'iga sõltub mudelist (4110 – 4150) ja varieerub umbes 0,5 – 2,5 miljoni dollari vahel.
Seega hakkab meie disain meenutama eelmist näidet.
Kas see tähendab, et see disain on vale?
Ei, ei tähenda. Cisco pakub teile maksimaalset kaitset oma tooteportfelli põhjal. Kuid see ei tähenda, et see on teie jaoks "pea meelest välja".
Põhimõtteliselt on see tavaline küsimus, mis tekib kontori või andmekeskuse projekteerimisel, ja see tähendab ainult seda, et tuleks otsida kompromissi.
Näiteks mitte kogu liiklust läbi tulemüüri suunata, ja sel juhul tundub kolmas variant üsna atraktiivne, või (vt eelmist jaotust) võib-olla ei vaja te "Threat Defense" või üldse tulemüüri selles võrgu segmendis, ja piisab passiivsest jälgimisest, kasutades tasulisi (mitte kallid) või avatud lähtekoodiga lahendusi, või on tulemüür vajalik, aga teise tootja oma.
Tavaliselt on alati olemas see ebamugavustunne ja ei ole ühte kindlat vastust, milline lahendus on teie jaoks parim.
Selles peituvadki ülesande keerukus ja ilu.
Allikas: habr.com
