Ez a cikk az ötödik a "Hogyan vegyük kezünkbe a hálózati infrastruktúrát" című cikksorozatban. Az összes cikk tartalmát és linkeket itt találhat. .
Ez a rész a Campus (Iroda) & Távoli hozzáférés VPN szegmensekre összpontosít.
Elsőre úgy tűnhet, hogy az iroda hálózatának tervezése egyszerű.
Valójában L2/L3 switcheket használva, összekötjük őket. Ezután elvégezzük az alap VLAN, az alapértelmezett átjárók beállítását, elindítjuk az egyszerű routerezést, csatlakoztatjuk a WiFi kontrollerünket, hozzáférési pontokat telepítünk és konfigurálunk, valamint beállítjuk az ASA-t távoli hozzáféréshez, és örvendünk, hogy minden működik. Alapvetően, mint már említettem egy korábbi cikkemben, ennek a ciklusnak az összefüggésében, a legtöbb diák, aki részt vett (és elsajátította) két féléven át telekommunikációs kurzust, képes tervezni és konfigurálni egy iroda hálózatot, hogy "valahogyan működjön".
De minél többet megtud, annál bonyolultabbnak tűnik ez a feladat. Számomra ez a téma, az iroda hálózatának tervezése, egyáltalán nem tűnik egyszerűnek, és ebben a cikkben megpróbálom elmagyarázni, miért.
Röviden, számos tényezőt figyelembe kell venni. Gyakran ezek a tényezők ellentmondásban állnak egymással, így ésszerű kompromisszumokat kell keresni.
Ez a bizonytalanság a fő nehézség. Tehát, ha a biztonságról beszélünk, három csúccsal rendelkező háromszögünk van: biztonság, a munkavállalók kényelme és a megoldás költsége.
És minden alkalommal kompromisszumot kell kötni ezen három dolog között.
Architektúra
Ezekre a két szegmensre vonatkozó architektúrákra példaként, mint ahogy a korábbi cikkekben, javaslom a modellt: , .
Ezek néhány elavult dokumentum. Itt bemutatom őket, mert az alapvető sémák és megközelítések nem változtak, de az előadásmódot jobban kedvelem, mint a .
Anélkül, hogy arra biztatnám önöket, hogy kizárólag Cisco megoldásokra támaszkodjanak, hasznosnak tartom alaposan megvizsgálni ezt a tervezést.
Ez a cikk, mint mindig, nem törekszik a teljességre, inkább kiegészíti ezt az információt.
A cikk végén elemezzük a Cisco SAFE terveit az iroda szempontjából, figyelembe véve az itt ismertetett koncepciókat.
Általános elvek
Az iroda hálózatának tervezése természetesen meg kell, hogy feleljen a korábban tárgyalt általános követelményeknek. A „Tervezési minőség értékelési kritériumai” fejezetében. Az ár és a biztonság mellett, amelyeket ebben a cikkben meg szándékozunk vitatni, még három kritériumot is figyelembe kell vennünk a tervezés során (vagy a módosítások során):
- skálázhatóság (scalability)
- kezelhetőség
- elérhetőség
Sok minden, ami már szóba került, szintén igaz az irodára is.
Mégis, az irodai szegmensnek vannak sajátosságai, amelyek a biztonság szempontjából kritikusak. Ennek a sajátosságnak a lényege, hogy ez a szegmens a vállalat munkatársainak (valamint partnereknek és vendégeknek) hálózati szolgáltatásokat nyújt, és következésképpen a probléma legmagasabb szintű vizsgálatakor két feladatot kell megoldanunk:
- védelmet nyújtani a vállalat erőforrásai számára a munkavállalók (vendégek, partnerek) és az általuk használt szoftverek által jelentett káros cselekedetek ellen. Ez magában foglalja a hálózatra való jogosulatlan csatlakozás elleni védelmet is.
- védeni a felhasználók rendszereit és adatait
És ez csak a probléma egyik oldala (pontosabban a háromszög egyik csúcsa). A másik oldalon a felhasználói kényelem és a alkalmazott megoldások ára áll.
Kezdjük azzal, hogy áttekintjük, mit vár el a felhasználó a modern irodai hálózattól.
Kényelem
Szerintem így néznek ki az „irodai hálózati kényelmek” a felhasználó számára:
- Mobilitás
- A megszokott eszközök és operációs rendszerek teljes spektrumának használatának lehetősége
- Könnyű hozzáférés a vállalat összes szükséges erőforrásához
- Internetforrások elérhetősége, beleértve a különböző felhőszolgáltatásokat is
- A hálózat „gyors működése”
Mindez vonatkozik mind a munkavállalókra, mind a vendégekre (vagy partnerekre), és ez már a vállalat mérnökeinek feladata az azonosítás alapján a különböző felhasználói csoportok hozzáférésének elkülönítése.
Nézzük meg egy kicsit részletesebben mindezen szempontokat.
Mobilitás
Arról van szó, hogy a vállalat összes szükséges erőforrását bárhonnan elérjük és használhassuk a világ bármely pontjáról (természetesen ahol internet elérhető).
Ez teljes mértékben vonatkozik az irodára is. Kényelmes, amikor az iroda bármely pontjáról folytathatja a munkát, például e-maileket kaphat, kommunikálhat a vállalati messengerben, elérhető lehet videohívásra, ... Így egyrészt lehetősége van élő kommunikációval megoldani bizonyos kérdéseket (például részt venni értekezleteken), másrészt mindig online maradhat, kézben tarthatja a fontos ügyeket és gyorsan megoldhatja a sürgős, nagy prioritású feladatokat. Ez nagyon kényelmes, és valóban javítja a kommunikáció minőségét.
Ezt a WiFi hálózat megfelelő tervezésével lehet elérni.
Megjegyzés
Itt általában felmerül a kérdés, hogy elegendő-e kizárólag WiFi-t használni? Jelenti ez, hogy lemondhatunk az Ethernet portok használatáról az irodában? Ha csak a felhasználókról van szó, nem pedig a kiszolgálókról, amelyek viszont ésszerűen normál Ethernet porttal legyenek csatlakoztatva, akkor az általános válasz: igen, elegendő lehet kizárólag WiFi-re korlátozódni. De vannak árnyalatok.
Fontos felhasználói csoportok vannak, amelyek külön megközelítést igényelnek. Ezek természetesen az adminisztrátorok. Alapvetően a WiFi kapcsolat megbízhatatlanabb (a forgalom elvesztése szempontjából) és lassabb, mint a normál Ethernet port. Ez lényeges lehet az adminisztrátorok számára. Ezenkívül a hálózati adminisztrátoroknak például lehetséges, hogy van egy különdedikált Ethernet hálózatuk az out-of-band kapcsolathoz.
Lehetséges, hogy a cégen belül más csoportok/osztályok is vannak, ahol ezek a tényezők szintén fontosak.
Van még egy fontos szempont – a telefonálás. Lehetséges, hogy valamilyen okból nem szeretné használni a Wireless VoIP-t, és hagyományos Ethernet csatlakozással szeretné használni az IP telefonokat.
Általában az olyan cégeknél, ahol dolgoztam, általában mind WiFi csatlakozás, mind Ethernet port lehetőség volt.
Szeretném, ha a mobilitás nem korlátozódna kizárólag az irodára.
A munka lehetőségének biztosítására otthonról (vagy bármilyen más helyről, ahol elérhető az internet) VPN kapcsolódást használnak. Ilyenkor kívánatos, hogy az alkalmazottak ne érezzék a különbséget az otthoni munka és a távoli munka között, ami azt jelenti, hogy ugyanazokkal a hozzáférésekkel kell rendelkezniük. Hogyan lehet ezt megszervezni, arról később a "Egységes központosított hitelesítési és jogosultsági rendszer" fejezetben fogunk beszélni.
Megjegyzés
Valószínűleg nem tudja ugyanazt a minőségű távoli munkát biztosítani, mint amit az irodában kínál. Tegyük fel, hogy a VPN átjáróként Cisco ASA 5520-at használ. Ennek megfelelően ez az eszköz csak 225 Mbps VPN forgalmat tud kezelni. Tehát természetesen a VPN-kapcsolat sávszélessége erősen eltér az irodai munkától. Ha emiatt a késleltetés, a csomagvesztés, a jitter (például ha irodai IP telefóniát szeretne használni) lényeges az Ön hálózati szolgáltatásaiban, akkor szintén nem kapja meg ugyanazt a minőséget, mint ha az irodában lenne. Ezért, amikor a mobilitásról beszélünk, figyelembe kell vennünk a lehetséges korlátozásokat.
Könnyű hozzáférés minden vállalati erőforráshoz
Ezt a feladatot más technikai részlegekkel együtt kell kezelni.
Ideális esetben a felhasználónak csak egyszer kell hitelesítenie magát, és utána hozzáfér a szükséges erőforrásokhoz.
A biztonság feláldozása nélküli könnyű hozzáférés jelentősen növelheti a munkavégzés hatékonyságát és csökkentheti kollégái stresszszintjét.
Megjegyzés 1
A hozzáférés kényelme nem csupán abban rejlik, hogy hányszor kell beírnia a jelszót. Például ha a biztonsági politikája értelmében az irodából a datacentrumhoz való csatlakozáshoz először a VPN átjárón keresztül kell csatlakozni, és ezáltal elveszíti az irodai erőforrásokhoz való hozzáférést, az is nagyon kényelmetlen.
Megjegyzés 2
Vannak szolgáltatások (például a hálózati berendezésekhez való hozzáférés), ahol általában külön AAA szerverekkel rendelkezünk, és normális, hogy ilyen esetekben többször kell hitelesíteni.
Internetes erőforrások elérhetősége
Az internet nem csupán szórakozás, hanem olyan szolgáltatások halmaza is, amelyek rendkívül hasznosak lehetnek a munkához. Vannak pszichológiai tényezők is. A modern ember az interneten sok virtuális szállal kapcsolódik másokhoz, és véleményem szerint nincs semmi rossz abban, ha ezt a kapcsolatot továbbra is érzékeli munka közben is.
Időveszteség szempontjából nem nagy ügy, ha a munkavállalónak például bekapcsolva van a Skype-ja, és szükség esetén 5 percet beszélget egy közeli személlyel.
Jelenti ez, hogy az internet mindig elérhetőnek kell lennie, és ezt jelenti, hogy a munkavállalóknak szabad hozzáférést adhatunk minden forráshoz anélkül, hogy bármilyen ellenőrzést végeznénk?
Nem, ez nem így van. Az internet nyitottságának szintje különböző cégeknél eltérő lehet – a teljes zárttól a teljes nyitottságig. A forgalom ellenőrzésének módjait később tárgyaljuk az védelmi eszközökről szóló fejezetben.
Lehetőség az összes megszokott eszköz használatára
Hasznos, amikor például továbbra is használhatja az összes megszokott kommunikációs eszközét a munkahelyén. Technikai szempontból nem nehéz ezt megvalósítani. Ehhez WiFi és vendég VLAN szükséges.
Az is jó, ha van lehetősége használni azt az operációs rendszert, amelyhez már hozzászokott. De tapasztalataim szerint általában ezt csak a menedzserek, rendszergazdák és fejlesztők számára engedik meg.
támadásra
Természetesen el lehet menni a tiltások útján, megtiltani a távoli hozzáférést, megtiltani a mobil eszközök csatlakozását, mindent statikus Ethernet kapcsolatokra korlátozni, korlátozni az internet hozzáférést, kötelezően elvenni a mobiltelefonokat és kütyüket a bejáratnál... és egyes szervezetek, amelyeknek fokozott biztonsági követelményeik vannak, valóban ezt az utat követik, és talán bizonyos esetekben ez indokolt lehet, de... egyetérthetünk, hogy ez úgy néz ki, mint a fejlődés megállítása egy adott szervezetben. Természetesen szeretnénk összeegyeztetni a modern technológiák által nyújtott lehetőségeket a megfelelő biztonsági szinttel.
A hálózat „gyors működése”
Az adatátviteli sebesség technikailag sok tényezőből áll össze. És a csatlakozási port sebessége általában nem a legfontosabb ezek közül. Nem mindig a lassú alkalmazásműködés áll kapcsolatban hálózati problémákkal, de most csak a hálózati rész érdekel minket. A helyi hálózat „lassulásának” leggyakoribb problémája a csomagvesztés. Ez általában akkor fordul elő, ha palacknyak-hatás van, vagy L1 (OSI) problémák lépnek fel. Ritkábban, bizonyos terveknél (például amikor a helyi alhálózatainkban a tűzfal a default gateway) a teljes forgalom rajta megy keresztül, előfordulhat, hogy a berendezés teljesítménye nem elegendő.
Ezért, amikor az eszközök és az architektúra kiválasztásáról van szó, figyelembe kell venni a végponti portok, a trunkok és az eszközök teljesítményének sebességét.
támadásra
Tegyük fel, hogy 1 gigabites portokkal rendelkező elosztó switch-eket használsz. Ezek egymással 2 x 10 gigabites Etherchannel-en keresztül vannak összekapcsolva. Mint alapértelmezett átjárót egy gigabites portokkal rendelkező tűzfalat használsz, amelyet 2 gigabites porton keresztül csatlakoztatsz az iroda L2 hálózatához, szintén Etherchannel révén.
Ez az architektúra funkció szempontjából elég kényelmes, mivel minden forgalom átmegy a tűzfalon, és kényelmesen kezelheted a hozzáférési politikákat, valamint bonyolult forgalomellenőrzési algoritmusokat és lehetséges támadások megelőzését alkalmazhatod (erről később), de a sávszélesség és a teljesítmény szempontjából ennek a tervezésnek nyilvánvalóan potenciális problémái vannak. Például 2 olyan gazda, akik adatokat töltenek le (1 gigabites port sebességgel), teljesen leterhelhetik a tűzfalhoz vezető 2 gigabites kapcsolatot, ami a szolgáltatás romlásához vezethet az irodai szegmens számára.
Már megbeszéltük a háromszög egyik csúcsát, most nézzük meg, milyen eszközöket használhatunk a biztonság garantálására.
Védelmi eszközök
Nos, nyilvánvalóan a vágyunk (pontosabban a vezetésünk kívánsága), hogy elérjük a lehetetlent, nevezetesen, a maximális kényelmet a maximális biztonság és minimum ár mellett.
Nézzük meg, milyen módszereink vannak a védelem biztosítására.
Az irodai környezethez a következőket emelném ki:
- zero trust megközelítés a tervezésben
- magas szintű védelem
- hálózati láthatóság
- egységes, centralizált autentikációs és autorizációs rendszer
- gazda ellenőrzés (host checking)
Most részletesebben ismerjük meg ezeket az aspektusokat.
Zero Trust
Az IT világ nagyon gyorsan változik. Az elmúlt 10 év során az új technológiák és termékek megjelenése komolyan átalakította a biztonsági koncepciókat. Még tíz évvel ezelőtt a biztonság szempontjából a hálózatot trust, dmz és untrust zónákra szegmentáltuk, és a „peremvédelem” volt érvényben, amelyben 2 védelmi vonal volt: untrust -> dmz és dmz -> trust. A védelem általában a L3/L4 (OSI) fejlécek (IP, TCP/UDP portok, TCP zászlók) alapú hozzáférési listákra korlátozódott. Minden, ami a magasabb szintekkel, beleértve az L7-et is, kapcsolatos volt, az operációs rendszerekre és a végső hosztokon telepített védelmi termékekre lett bízva.
Most a helyzet alapjaiban megváltozott. A modern koncepció abból indul ki, hogy már lehetetlen a perimen belüli, azaz a belső rendszereket megbízhatónak tekinteni, és magának a perem fogalma is elmosódottá vált.
A 인터넷hez való csatlakozás mellett rendelkezünk
- a felhasználók távoli hozzáférésű VPN-jeivel
- különböző személyes eszközökkel, irodai WiFi-n keresztül csatlakoztatott laptopokkal
- más (branch) irodákkal
- a felhőinfrastruktúrával való integrációval
Milyen a Zero Trust megközelítés a gyakorlatban?
Ideálisan csak azok a forgalmak engedélyezettek, amelyek szükségesek, és ha már a tökéletességről beszélünk, a kontrollnak nemcsak L3/L4 szinten, hanem alkalmazásszinten is meg kell valósulnia.
Ha például van lehetősége az összes forgalmat tűzfalon átengedni, akkor megpróbálhat közelíteni a tökéletességhez. De ez a megközelítés jelentősen csökkentheti a hálózata összesített sávszélességét, ráadásul az alkalmazásalapú szűrés nem mindig működik jól.
Ha viszont a forgalom ellenőrzése a routeren vagy L3 switch-en történik (szabványos ACL használatával), más problémákkal szembesül:
- ez csak L3/L4 szűrés. Semmi sem akadályozza meg a támadót abban, hogy a megengedett portokat (például TCP 80) saját alkalmazásához (nem http) használja.
- bonyolult ACL menedzsment (nehéz az ACL elemzése)
- ez nem statefull tűzfal, tehát egyértelműen engedélyeznie kell a visszafelé irányuló forgalmat
- switch-ek esetén általában elég szigorúan korlátozottak a TCAM mérete, ami a „csak azt engedélyezd, ami szükséges” megközelítésekor hamar problémává válhat.
Megjegyzés
A visszafelé irányuló forgalom kapcsán nem szabad elfelejtenünk, hogy van egy lehetőségünk (Cisco)
permit tcp any any established
De meg kell érteni, hogy ez a sor egyenértékű két sorral:
engedélyezni tcp bárhol bárhová ack
engedélyezni tcp bárhol bárhová rstEz azt jelenti, hogy még ha nem is volt eredeti TCP szegmens SYN jelzéssel (tehát a TCP kapcsolat még nem is kezdődött el), ez az ACL átengedi az ACK jelzésű csomagot, amit a támadó ki tud használni az adatok továbbítására.
Tehát ez a sor egyáltalán nem alakítja a routeredet vagy az L3 kapcsolót stateful tűzfallá.
. Egyetlen cselekedet sem történhet az Ön "felügyelete" nélkül.
A A data center-ekkel foglalkozó részben a következő védelmi módokat vizsgáltuk.
- stateful firewalling (by default)
- ddos/dos védelem
- application firewalling
- threat prevention (antivirus, anti-spyware, and vulnerability)
- URL filtering
- data filtering (content filtering)
- file blocking (file types blocking)
Iroda esetében a helyzet hasonló, de a prioritások kicsit mások. Az iroda elérhetősége (availability) általában nem olyan kritikus, mint a data center esetében, míg a "belső" kártékony forgalom valószínűsége nagyságrendekkel magasabb.
Ezért a következő védelmi módszerek kulcsszerepet játszanak ebben a szegmensben:
- application firewalling
- fenyegetésmegelőzés (anti-virus, anti-spyware és sebezhetőség)
- URL filtering
- data filtering (content filtering)
- file blocking (file types blocking)
Bár ezek a védelmi módszerek, az alkalmazás tűzfalat kivéve, hagyományosan az végső hosztokon (például antivírus programok telepítésével) és proxy segítségével kerültek megoldásra, a modern NGFW-k ezek szervizt is nyújtanak.
A biztonsági berendezések gyártói arra törekednek, hogy átfogó védelmet nyújtsanak, ezért a helyi védelem mellett különféle felhőalapú technológiákat és kliens szoftvereket ajánlanak a hosztokhoz (end point protection/EPP). Például a látjuk, hogy a Palo Alto és a Cisco rendelkezik saját EPP-jével (PA: Traps, Cisco: AMP), de nem tartoznak a vezetők közé.
Ezeknek a védelemnek a bekapcsolása (általában licenc vásárlásával) a tűzfalon természetesen nem kötelező (mehetünk a hagyományos úton is), de bizonyos előnyöket nyújt:
- ebben az esetben egyetlen ponton alkalmazhatók a védelmi módszerek, ami javítja a láthatóságot (további téma).
- ha a hálózatodban van egy védtelen eszköz, akkor az is a tűzfal védelmi "ernyője" alá kerül
- a tűzfalon a védelem és az végső hosztok védelme együttes használata növeli a kártékony forgalom észlelésének valószínűségét. Például a fenyegetésmegelőzés helyi hosztokon és a tűzfalon való alkalmazása növeli az észlelés valószínűségét (feltéve, hogy ezek a megoldások különböző szoftvertermékekre épülnek).
Megjegyzés
Ha például a Kaspersky-t használja vírusirtóként mind a tűzfalon, mind a végpontokon, nyilvánvaló, hogy ez nem növeli jelentősen az esélyeit, hogy megakadályozza a vírusos támadást a hálózatában.
Hálózati láthatóság
egyszerűen szólva – látni, mi történik a hálózatában, valós időben és történeti adatok alapján.
Ezt a "látást" két csoportra osztanám:
Első csoport: amit általában a monitorozó rendszered kínál.
- berendezések terheltsége
- csatornák terheltsége
- memóriahasználat
- lemezhasználat
- útvonalváltoztatások
- linkek állapota
- berendezések (vagy hostok) rendelkezésre állása
- …
Második csoport: biztonsággal kapcsolatos információk.
- különféle statisztikák (például az alkalmazásokról, weboldal-látogatásokról, letöltött adatok típusairól, felhasználói adatok)
- mi volt blokkolva a biztonsági politikák által és miért, nevezetesen
- tiltott alkalmazás
- tiltva IP/protokoll/port/jelvények/zónák alapján
- fenyegetésmegelőzés
- URL szűrés
- adat szűrés
- fájlblokkolás
- …
- statisztikák DOS/DDOS támadásokra
- sikertelen azonosítási és hitelesítési kísérletek
- statisztikák az összes fent említett biztonsági politikákat sértő eseményről
- …
A biztonságnak szentelt jelen fejezetben számunkra a második rész a legfontosabb.
Néhány modern tűzfal (a saját tapasztalataim szerint, például a Palo Alto) jó láthatósági szintet biztosít. De természetesen, a forgalomnak, ami érdekel, át kell haladnia ezen a tűzfalon (ebben az esetben lehetőség van a forgalom letiltására) vagy tükrözni kell a tűzfalra (csak figyelés és elemzés céljából), és engedélyekkel kell rendelkeznie, amelyek lehetővé teszik ezen szolgáltatások aktiválását.
Van természetesen alternatív út is, pontosabban egy hagyományos módszer, például
- a munkamenet statisztikákat a netflow segítségével is gyűjtheti, majd speciális eszközöket használhat az információk elemzésére és az adatok vizualizálására.
- fenyegetésmegelőzés – speciális programok (vírusirtó, kémprogram-irtó, tűzfal) a végpontokon.
- URL szűrés, adat szűrés, fájlblokkolás – proxy szinten
- továbbá a tcpdump-ot is elemezheti például
Ezeket a megközelítéseket összekapcsolhatja, kiegészítve a hiányzó funkciókat vagy megismételve őket a támadás észlelésének valószínűségének növelése érdekében.
Melyik megközelítést válassza?
Nagyon függ a csapata képesítésétől és preferenciáitól.
Mindkét esetben vannak előnyök és hátrányok.
Központosított hitelesítési és engedélyezési rendszer
Jó tervezés esetén, a cikkben tárgyalt mobilitás azt jelenti, hogy ugyanazokkal a hozzáférésekkel rendelkezik, függetlenül attól, hogy az irodából, otthonról, a repülőtérről, egy kávézóban vagy bármely más helyszínen dolgozik (a fent említett korlátozások figyelembevételével). Mi tehát a probléma?
A feladat összetettségének jobb megértése érdekében nézzük meg egy tipikus dizájnt.
támadásra
- Csoportokba osztotta az összes alkalmazottat. Elhatározta, hogy csoportonként biztosítja a hozzáféréseket.
- Az irodán belül az irodai tűzfalon ellenőrzi a hozzáféréseket.
- Az iroda és az adatközpont közötti forgalmat az adatközpont tűzfalán ellenőrzi.
- VPN kapuként Cisco ASA-t használ, és a hálózatába belépő ügyfelek által generált forgalom ellenőrzésére helyi (ASA-n lévő) ACL-t alkalmaz.
Most feltételezzük, hogy megkérik, hogy adjon hozzá egy további hozzáférést egy bizonyos alkalmazottnak. Ehhez csak az ő hozzáférését kellene megadni, és senki másnak a csoportból.
Ehhez külön csoportot kell létrehoznunk e munkatárs számára, tehát
- az ASA-n külön IP-poolt létrehozni ennek a munkatársnak
- új ACL-t hozzáadni az ASA-hoz, és azt hozzárendelni ehhez a távoli ügyfélhez
- új biztonsági politikákat létrehozni az irodai és az adatközponti tűzfalakon.
Jó, ha ez az esemény ritka. De tapasztalataim alapján volt olyan helyzet, amikor az alkalmazottak különböző projektekben vettek részt, és ezek a projektek néhányuk számára elég gyakran változtak, nem 1-2 emberről volt szó, hanem tucatnyi. Természetesen itt valamit változtatni kellett.
A következő módon döntöttünk.
Úgy döntöttünk, hogy a munkatársak összes lehetséges hozzáférését a LDAP határozza meg, ami az igazság egyetlen forrása. Különböző csoportokat hoztunk létre, amelyek a hozzáférési szetteket definiálták, és minden felhasználót egy vagy több csoporthoz rendeltünk.
Például vegyük észre, hogy voltak csoportok.
- vendég (hozzáférés az internethez)
- általános hozzáférés (hozzáférés közös erőforrásokhoz: e-mail, tudásbázis, …)
- könyvelés
- projekt 1
- projekt 2
- adatbázis-adminisztrátor
- linux adminisztrátor
- …
És ha valaki az adott projektekben részt vett, és szüksége volt a munkához szükséges hozzáférésekre, akkor ezt az illetőt a megfelelő csoportokhoz rendeltük:
- guest
- általános hozzáférés
- projekt 1
- projekt 2
Hogyan alakítható most ez az információ a hálózati berendezéseken elérhetővé?
A Cisco ASA Dynamic Access Policy (DAP) (see ) solution is just right for this task.
In short, regarding our implementation, during the identification/authorization process, the ASA receives a set of groups from LDAP corresponding to the user and 'assembles' a dynamic ACL from several local ACLs (each of which corresponds to a group) with all necessary accesses, which fully meets our requirements.
But this is only for VPN connections. To make the situation the same for employees connecting via VPN and those in the office, the following step was taken.
When connecting from the office, users would use the 802.1x protocol to access either a guest VLAN (for guests) or a general access VLAN (for company employees). Furthermore, to gain specific accesses (such as to projects in the data center), employees had to connect via VPN.
Different tunnel groups on the ASA were used for connections from the office and from home. This was necessary so that for users connecting from the office, traffic to shared resources (used by all employees, such as email, file servers, ticket systems, DNS, ...) would not go through the ASA, but through the local network. This way, we did not overload the ASA with unnecessary traffic, including high-intensity traffic.
Thus, the task was solved.
We achieved
- the same set of accesses for both office connections and remote connections
- no service degradation when working from the office related to the transfer of high-intensity traffic through the ASA
What other advantages does this approach have?
In access administration. Accesses are easily modified in one place.
For example, if an employee leaves the company, you simply remove them from LDAP, and they automatically lose all accesses.
Host checking
With the possibility of remote connections, we expose ourselves to the risk of allowing not only company employees into the network but also all malicious software that is likely present on their computers (e.g., home computers), and moreover, through this software, we may potentially open access to our network for attackers using this host as a proxy.
Ésszerű, hogy a távolról csatlakozó hostok számára ugyanazokat a biztonsági követelményeket alkalmazzák, mint az irodában lévő hostok esetében.
Ez magában foglalja a „helyes” operációs rendszer, vírusirtó, kémprogram-eltávolító és tűzfal szoftverek és frissítések használatát is. Általában ez a lehetőség elérhető a VPN átjárón (pl. ASA esetén, nézd meg a példát, ).
Ésszerű, hogy ugyanezeket az elemzési és forgalomblokkolási módszereket alkalmazzuk (lásd „Magas szintű védelem”), amelyeket a biztonsági politikájának megfelelően alkalmaz a irodai forgalomra.
Ésszerű azt feltételezni, hogy mostantól az irodai hálózatod nem korlátozódik az irodai épületre és az ott lévő hostokra.
támadásra
Jó fogás, hogy minden alkalmazott számára, akinek távoli hozzáférésre van szüksége, jó, kényelmes laptopot biztosítanak, és megkövetelik, hogy csak erről dolgozzon, akár az irodában, akár otthon.
Ez nemcsak növeli a hálózatod biztonsági szintjét, hanem valóban kényelmes is, és általában pozitívan fogadják az alkalmazottak (ha tényleg jó és kényelmes laptopról van szó).
Az arányérzékről és az egyensúlyról
Alapvetően ez a harmadik csúcsról beszél a háromszögünkben — az ár.
Nézzük meg egy hipotetikus példát.
támadásra
Van egy 200 fős irodád. Azt döntötted, hogy maximálisan kényelmessé és maximálisan biztonsossá teszed.
Ezért úgy döntöttél, hogy az összes forgalmat a tűzfalon keresztül engeded át, és így az iroda minden alhálózata esetében a tűzfal a default átjáró. A végpontokon telepített security szoftver (vírusirtó, kémprogram-eltávolító és tűzfal szoftver) mellett úgy döntöttél, hogy minden lehetséges védelmi módszert alkalmazol a tűzfalon.
A magas sebességű csatlakozás biztosítása érdekében (minden a kényelem érdekében) 10 gigabites portokkal rendelkező hozzáférési switcheket választottál, míg a tűzfalak esetében nagy teljesítményű NGFW tűzfalakat, például a Palo Alto 7K sorozatát (40 gigabites portokkal), természetesen minden licenccel és természetesen high availability párral.
Emellett persze a berendezés használatához legalább néhány magasan képzett biztonsági mérnökre is szükség van.
Ezen kívül minden alkalmazottnak adtál egy jó laptopot.
Összességében körülbelül 10 millió dollár az implementációhoz, számos ezer dollár (szerintem közelebb a millióhoz) az éves támogatásra és a mérnökök bérére.
Iroda, 200 ember…
Kényelmes? Valószínűleg, igen.Ezzel az ajánlattal a vezetőségedhez fordulsz...
Lehet, hogy a világban van néhány vállalat, ahol ez elfogadható és helyes döntés. Ha te ennek a vállalatnak az alkalmazottja vagy, gratulálok, de a többségi esetekben biztos vagyok benne, hogy a tudásodat a vezetőség nem fogja értékelni.
Túlozzon ez a példa? A következő fejezet meg fogja adni a választ erre a kérdésre.
Ha a hálózatodban nem látsz valamit az előbb említett dolgok közül, akkor ez normális.
Minden konkrét esetben meg kell találnod a megfelelő kompromisszumot a kényelem, az ár és a biztonság között. Gyakran még csak nem is szükséges NGFW az irodádban, az L7 védelem a tűzfalon sem kötelező. Elég egy jó láthatóság és riasztási szint biztosítása, és ez megoldható például nyílt forráskódú termékek használatával. Igen, a támadásra adott reakciód nem lesz azonnali, de a legfontosabb, hogy észre fogod venni, és a megfelelő folyamatok meglétével a részlegeden gyorsan semlegesíteni tudod.
És emlékeztetlek, hogy a ciklus e cikkek szándéka szerint nem a hálózat tervezésével foglalkozol, csupán próbálod javítani azt, ami a rendelkezésedre áll.
A SAFE irodai architektúra elemzése
Figyelj erre a piros négyzetre, amit a térképen kiemeltem, , amelyet itt szeretnék megbeszélni.
Ez az architektúra egyik kulcspontja és az egyik legfontosabb bizonytalanság.
Megjegyzés
Soha nem állítottam be és nem dolgoztam a FirePower-rel (a Cisco tűzfalai közül – csak az ASA-val), így úgy fogom kezelni, mint bármilyen más tűzfalat, például a Juniper SRX-et vagy a Palo Alto-t, feltételezve, hogy azoknak megvannak a hasonló képességeik.
A megszokott konfigurációkból csak 4 lehetséges tűzfalhasználati variációt látok egy ilyen csatlakozással:
- minden alhálózatnál az alapértelmezett átjáró egy switch, miközben a tűzfal átlátszó módban működik (azaz az összes forgalom rajta halad át, de nem képez L3 ugrást)
- minden alhálózatnál a tűzfal al-interfészei (vagy SVI interfészek) az alapértelmezett átjárók, a switch L2 szerepet játszik
- a switchen különböző VRF-ek vannak, és a forgalom a VRF-ek között a tűzfalon megy át, a forgalom egy VRF-en belül az ACL-ek által van szabályozva a switchen
- minden forgalom tükrözése a tűzfalra analízis és monitorozás céljából, a forgalom rajta nem halad át
Megjegyzés 1
Ezeket a lehetőségeket kombinálni lehet, de egyszerűség kedvéért most nem foglalkozunk velük.
Megjegyzés2
Van lehetőség a PBR (szolgáltatáslánc architektúra) használatára is, de ez egyelőre, véleményem szerint, inkább egzotikus megoldás, ezért itt nem tárgyalom.
A dokumentumban található forgalmi leírások alapján látjuk, hogy a forgalom mégis a tűzfalon keresztül halad, tehát a Cisco tervezése szerint a negyedik lehetőség kizárható.
Először vizsgáljuk meg az első két lehetőséget.
Ezekkel a lehetőségekkel az összes forgalom a tűzfalon keresztül halad.
Most nézzük meg , nézzük és látjuk, hogy ha legalább 10 – 20 gigabites összes sávszélességet szeretnénk az irodánk számára, akkor 4K verziót kell vásárolnunk.
Megjegyzés
Amikor az összes sávszélességről beszélek, akkor a különböző alhálózatok közötti forgalmat értem (nem egy vLAN-on belül).
A GPL-ből látjuk, hogy a HA Bundle Threat Defense árai a modelltől függően (4110 – 4150) ~0,5 – 2,5 millió dollár között változnak.
Tehát a designunk kezd hasonlítani az előző példához.
Jelenti ez, hogy a design hibás?
Nem, nem jelenti. A Cisco a rendelkezésre álló termékportfóliója alapján a lehető legnagyobb védelmet nyújtja. De ez nem jelenti azt, hogy ez minden esetben „muszáj” lenne az Ön számára.
Alapvetően ez egy szokásos kérdés, amely az iroda vagy adatközpont tervezésekor merül fel, és csak annyit jelent, hogy kompromisszumot kell keresni.
Például nem minden forgalmat a tűzfalon keresztül engedni, és ebben az esetben a harmadik lehetőség nekem elég vonzónak tűnik, vagy (lásd az előző fejezetet), lehet, hogy Önnek nincs szüksége a „Threat Defense”-re, vagy egyáltalán nem szükséges tűzfal ezen a hálózati szegmensen, és elegendő a passzív monitorozás, amit olcsó (nem drága) vagy nyílt forráskódú megoldásokkal végezhet, vagy szüksége van tűzfalra, de más gyártótól.
Általában mindig ott van ez a bizonytalanság, és nincs egyértelmű válasz, hogy melyik megoldás a legjobb az Ön számára.
Ez a feladat bonyolultsága és szépsége.
Forrás: habr.com
