Testimine näitab: kuidas valmistuda Cisco ISE juurutamiseks ja mõista, milliseid süsteemi funktsioone teil on vaja.

Kui tihti ostate midagi spontaanselt, alludes ägedale reklaamile, ja siis see algselt ihaldatud ese seisab kapis, panipaigas või garaažis kuni järgmise suure koristuseni või üleviimise hetkeni? Tulemuseks on pettumus põhjendamatute ootuste ja raisatud raha tõttu. Veel hullem on, kui selline olukord juhtub ettevõttega. Tihti on turundustrikid nii hea kvaliteediga, et ettevõtted soetavad endale kallis lahenduse, teadmata kogu selle rakendamise konteksti. Samas aitab süsteemi prooviversioon mõista, kuidas kohandada infrastruktuuri integreerimiseks, millist funktsionaalsust ja kui ulatuslikult tuleks rakendada. Nii saab vältida tohututes kogustes probleeme „pime” toote valimise tõttu. Lisaks toob arvestatava „pilotprojekti” järel rakendamine inseneridele palju vähem purustatud närvirakke ja halli juuksekarva. Vaatame, miks on pilot-testing nii oluline eduka projekti jaoks, kasutades näitena populaarselt tööriista, mis kontrollib juurdepääsu ettevõtte siseringile — Cisco ISE. Uurime nii tüüpilisi kui ka täiesti ebastandardsed rakenduste variante, mis on meie praktikas esinenud.

Cisco ISE — „Radius-server steroidide peal“

Cisco Identity Services Engine (ISE) on platvorm, mille abil luuakse organisatsiooni kohaliku arvutiliini ligipääsukontrolli süsteem. Ekspertide seas on toote omaduste tõttu nimetatud seda „sterroidide peal oleva Radius-serverina“. Miks nii? Sisuliselt on lahendus Radius-server, millele on lisatud tohutul hulgal lisateenuseid ja „vidinaid“, mis võimaldavad saada palju kontekstuaalset teavet ja rakendada saadud andmekogumit juurdepääsupoliitikates.

Nagu iga teine Radius-server, suhtleb Cisco ISE juurdepääsuvõrgu seadmetega, kogub teavet kõigi ettevõtte võrguga ühenduse loomise katsete kohta ning lubab või keelab kasutajatel pääseda lokaalsetesse võrkudesse autentimise ja autoriseerimise poliitikate alusel. Kuid profileerimise, jälgimise ning teiste infoturvelahendustega integreerimise võimalused võimaldavad oluliselt keerulisemaks muuta autoriseerimispoliitika loogikat ning seeläbi lahendada päris keerulisi ja huvitavaid ülesandeid.

Rakendada ei saa proovida: miks on testimine vajalik?

Pilootestimise väärtus seisneb süsteemi kõigi võimaluste demonstreerimises konkreetse organisatsiooni infrastruktuuris. Olen kindel, et Cisco ISE pilootimine enne rakendamist toob kasu kõigile projekti osalistele, ja sellega seoses on mul mõned põhjendused.

Integraatoritele annab see selge ettekujutuse kliendi ootustest ja aitab moodustada korrektse tehnilise ülesande, mis sisaldab märksa rohkem detaile, kui tavaline fraas „tehke nii, et kõik oleks hea”. „Piloot” võimaldab meil tunnetada kogu kliendi valu, mõista, millised ülesanded on tema jaoks prioriteetsed ja millised teisejärgulised. Meie jaoks on see suurepärane võimalus enne välja selgitada, millist varustust organisatsioonis kasutatakse, kuidas rakendamine toimub, millistel paikadel ja kus need asuvad jne.

Kliendid näevad piloottestimise ajal reaalset süsteemi tegutsenud, tutvuvad selle liidese ja omadustega, saavad kontrollida, kas see on kooskõlas nende olemasoleva varustusega, ja saavad tervikliku ettekujutuse sellest, kuidas lahendus pärast täielikku rakendamist töötab. „Piloot“ on see hetk, mil on võimalik näha kõiki „peidetud probleeme”, millega tõenäoliselt silmitsi seisame integreerimise käigus, ja otsustada, kui palju litsentse on vaja osta.
Mis võib „pilootimise” ajal pinnale tulla

Kuidas siis õigesti valmistuda Cisco ISE rakendamiseks? Meie kogemuste põhjal on neli peamist punkti, mida on oluline arvesse võtta süsteemi piloottestimise protsessis.

Form factor

Esiteks, tuleb otsustada, millises vormifaktoris süsteem rakendatakse: füüsilises või virtuaalses seadmes. Igal variandil on oma eelised ja puudused. Näiteks on füüsilise seadme tugevus ennustatav jõudlus, kuid ärgem unustagem, et sellised seadmed muutuvad aja jooksul vananenuks. Virtuaalsed seadmed on vähem ennustatavad, kuna need sõltuvad riistvarast, mille peal virtuaalomand on loodud, kuid nende tõsine pluss on see, et kui olemas on tugi, saab neid alati uuendada uusimale versioonile.

Kas teie võrguvarustus on Cisco ISE-ga ühilduv?

Muidugi, ideaalne stsenaarium oleks süsteemi koheselt ühendada kogu varustus. Siiski ei ole see alati võimalik, kuna paljud organisatsioonid kasutavad endiselt haldamata lüliteid või lüliteid, mis ei toeta teatud tehnoloogiaid, millel Cisco ISE töötab. Pealegi ei räägi me ainult lülititest, see võib hõlmata ka traadita võrgu kontrollerit. VPN-keskused ja kõik muu varustus, millega kasutajad on ühendatud. Minu praktikas on olnud juhtumeid, kus pärast süsteemi demonstreerimist täielikuks rakendamiseks uuendavad kliendid praktiliselt kogu juurdepääsulülitite parki kaasaegse Cisco varustuse vastu. Ebameeldivate üllatuste vältimiseks tasub eelnevalt välja selgitada, kui suur on toetamata varustuse osakaal.

Kas kõik teie seadmed on tüüpilised?

Igas võrgus on tüüpilised seadmed, mille ühendamine ei tohiks olla probleem: automatiseeritud töökohad, IP-telefonid, WiFi juurdepääsupunktid, videokaamerad ja nii edasi. Kuid on ka juhtumeid, kus tuleb LAN-i ühendada ebatüüpilisi seadmeid, näiteks RS232/Ethernet signaalikonverterid, katkestusteta toiteallikate liidesed, erinevad tehnoloogilised seadmed jne. Selliste seadmete loetelu on oluline eelnevalt kindlaks teha, et rakendamise etapis oleks teil juba aimu, kuidas need tehniliselt Cisco ISE-ga töötavad.

Konstruktiivne dialoog IT-inimestega

Tihti on Cisco ISE tellijateks turbeosakonnad, samas vastutavad juurdepääsulülitite seadistamise ja Active Directory eest tavaliselt IT-osakonnad. Seetõttu on turbe- ja IT-inimeste produktiivne koostöö üks olulisemaid tingimusi süsteemi valutuks integreerimiseks. Kui viimasena suhtuvad integreerimisse negatiivselt, tasub neile selgitada, kuidas lahendus saab IT-osakonnale kasulik olla.

Top-5 Cisco ISE kasutusjuhtu

Meie kogemuse põhjal selgub vajalik süsteemi funktsionaalsus sageli katseperioodi jooksul. Allpool on toodud mõned kõige populaarsemad ja vähem levinud lahenduse kasutusjuhtumid.

Turvaline juurdepääs LAN-ile EAP-TLS kaudu

Uuringute tulemuste kohaselt kasutavad küberkurjategijad tihti ettevõtte võrgus sissetungimiseks tavalisi pistikupesasid, mille küljes on printerid, telefonid, IP-kaamerad, Wi-Fi-sülearvutid ja muud mitteisiklikud võrguseadmed. Seetõttu, isegi kui võrku pääsemine toimub dot1x-tehnoloogia põhjal, kuid kasutatakse alternatiivseid protokolle ilma kasutajate autentimissertifikaatide rakendamiseta, on suur tõenäosus, et rünnak toimub seansi ülevõtmise ja paroolide brute force'i teel. Cisco ISE korral on sertifikaadi ründamine märgatavalt keerulisem — häkkerid vajavad selleks palju suuremat arvutusvõimet, seega on see juhtum väga efektiivne.

Duaalse SSID traadita juurdepääs

Selle stsenaariumi olemus seisneb kahe võrgu identifikaatori (SSID) kasutamises. Ühte neist võib tinglikult nimetada 'külaliseks'. Selle kaudu saavad traadita võrku pääseda nii külalised kui ka ettevõtte töötajad. Viimased suunatakse ühenduse loomisel spetsiaalsele portaali, kus toimub provisioneerimine. See tähendab, et kasutajale väljastatakse sertifikaat ja seadme seadistamine, et see automaatselt reconnectiks teise SSID, kus juba kasutatakse EAP-TLS-i kõikide eelneva juhtumi eelistustega.

MAC autentimise ümberhindamine ja profileerimine

Veel üks populaarne juhtum seisneb ühendatavate seadmete tüübi automaatse määramise ja nendele õige piirangute rakendamises. Miks see huvitav on? Selles osas ei toeta endiselt suur hulk seadmeid 802.1X protokolli autentimist. Seetõttu peab selliseid seadmeid võrku lubama MAC-aadressi kaudu, mida on suhteliselt lihtne valeandmete esitamise teel manipuleerida. Cisco ISE abiga võib näha, kuidas seade võrgus käitub, koostada selle profiili ja siduda see teiste seadmete rühmaga, näiteks IP-telefoniga ja tööjaamaga. Kui küberkurjategija püüab MAC-aadressi jäljendada ja võrku pääseda, märkab süsteem, et seadme profiil on muutunud, annab teada kahtlasest käitumisest ja ei lase kahtlase kasutaja võrku.

EAP-ahel

EAP-Chaining tehnoloogia tähendab tööarvuti ja kasutajatunnuse järjestikust autentimist. See lahendus on laialdaselt levinud, kuna paljudes ettevõtetes ei soovitata töötajate isiklike seadmete ühendamist ettevõtte LAN-iga. Sellise autentimisviisi kasutamine võimaldab kontrollida, kas konkreetne tööjaam kuulub domeeni, ja negatiivse tulemuse korral jääb kasutaja kas võrgust välja või siseneb, kuid teatud piirangutega.

Posturing

Sellisel juhul räägitakse tarkvara koosseisu vastavuse hindamisest tööjaama infotehnoloogia nõuetele. Selle tehnoloogia abil saab kontrollida, kas tööjaamal on tarkvara ajakohane, kas on installitud kaitsevahendid, kas hosti tulemüür on seadistatud jne. Huvi pakub, et see tehnoloogia võimaldab lahendada ka muid mittejulgeolekuga seotud ülesandeid, näiteks kontrollida vajalike failide olemasolu või installitud üldise süsteemi tarkvara.

Harvemini esinevad ka sellised Cisco ISE kasutusstsenaariumid nagu juhuslik autentimine (Passive ID), SGT-põhine mikrosegmentatsioon ja filtreerimine, samuti integratsioon mobiilsete seadmete haldamise süsteemide (MDM) ja haavatavuse skanneritega (Vulnerability Scanner).

Ebatavalised projektid: miks võib Cisco ISE veel vaja minna, või 3 haruldast juhtumit meie praktikast

Ligipääsu kontroll Linuxi serveritele

Kordagi kordal lahendasime üsna mitte trivialset juhtumit ühe kliendi jaoks, kellel oli juba rakendatud Cisco ISE süsteem: me pidime leidma viisi kasutajate tegevuste jälgimiseks (peamiselt administraatorite) Linuxiga serverites. Vastuse otsimisel tuli meile idee kasutada avatud lähtekoodiga PAM Radius Module, mis võimaldab siseneda Linuxi serveritesse autentimisega välise RADIUS-serveri kaudu. Kõik oleks väga hästi, kui mitte üks 'aga': RADIUS-server, saates vastuse autentimisnõudele, edastab ainult kasutajanime ja tulemuse — assess accepted või assess rejected. Samas, Linuxis autentimiseks peab määrama vähemalt ühe täiendava parameetri — home directory, et kasutaja vähemalt kuhugi pääseks. Me ei leidnud võimalust edastada seda RADIUS-attribuudina, seega kirjutasime spetsiaalse skripti, et kaugjuhtimise teel luua kontosid hostides poolautomaatsetes tingimustes. See ülesanne oli täiesti teostatav, kuna meiega oli tegemist administraatorite kontodega, mille arv polnud eriti suur. Edasi pääsesid kasutajad vajalikule seadmele, mille järel määrati neile vajalik juurdepääs. Tõstatub mõistlik küsimus: kas sellistes juhtumites on tingimata vajalik kasutada just Cisco ISE-d? Tegelikult ei — sobib igasugune RADIUS-server, kuid kuna kliendil oli juba see süsteem olemas, siis lisasime sellele lihtsalt uue funktsiooni.

Riistvara ja tarkvara inventeerimine lokaalsetes võrkudes

Ühel päeval töötasime projekti kallal, et toimetada Cisco ISE ühele kliendile ilma eelneva „piloodita“. Lahendusele ei olnud selgeid nõudmisi ja lisaks tegelesime lame, segmenteerimata võrguga, mis muudab ülesande keeruliseks. Projekti käigus seadistati kõikvõimalikud profileerimismeetodid, mida võrk toetas: NetFlow, DHCP, SNMP, AD-ga integreerimine jne. Lõpptulemusena seadistati juurdepääs MAR-i kaudu, võimaldades siseneda võrgusse ka juhul, kui autentimine nurjus. See tähendab, et isegi kui autentimine ei olnud edukas, lubas süsteem kasutaja siiski võrku, kogus temast teavet ja salvestas selle ISE andmebaasi. Selline võrgu jälgimine mõne nädala jooksul aitas meil tuvastada ühendatud süsteeme ja mittepersoonaliseeritud seadmeid ning töötada välja lähenemisviisi nende segmenteerimiseks. Pärast seda seadistasime täiendavalt postitusprotsessi agentide installimiseks tööjaamadesse, et koguda teavet nendele installitud tarkvara kohta. Mis lõpuks juhtus? Õnnestus meil segmenteerida võrk ja koostada nimekiri tarkvarast, mis tuli tööjaamadelt eemaldada. Tahan eitada, et edasised ülesanded kasutajate jagamiseks domeeningruppidesse ja juurdepääsuõiguste eristamiseks võtsid meilt üsna palju aega, kuid nii saime me täieliku ülevaate sellest, milline „riistvara“ oli kliendi võrgus. Ütleme nii, et see polnud keeruline tänu korralikule profileerimise tööle „karbist välja“. Ja seal, kus profileerimine ei aidanud, otsisime ise, eraldades lüliti porti, mille külge oli seadmed ühendatud.

Kauginstallatsioon tarkvarast tööjaamadesse

See kaast on minu praktikas üks kummalisemaid. Ühel päeval pöördus meie poole klient hädakaluga — Cisco ISE rakendamisel läks midagi valesti, kõik katkes ja keegi ei saanud enam võrgule ligi. Alustasime uurimist ja saime teada järgmist. Ettevõttes oli 2000 arvutit, mida haldati domeeni kontrolleri puudumise tõttu administraatori konto alt. Ettevõtte X juhtimisel rakendati Cisco ISE. Oli vajalik kuidagi mõista, kas olemasolevates arvutites on viirusetõrje, kas tarkvarakeskkond on ajakohane jne. Kuna võrguseadmed integreerisid süsteemi IT-administraatorid, oli loogiline, et neil oli sellele juurdepääs. Vaadates, kuidas süsteem töötab, ja tehes oma arvutite skaneerimise, mõtlesid adminnid välja, et installida tarkvara töötajate tööjaamadesse eemalt, ilma isikliku kohaloluta. Kujutage ette, kui palju samme on võimalik päeva jooksul säästa! Adminnid tegid mitu APM-i kontrollimist, et leida kindlat faili kaustast C:Program Files, ja kui see puudus, algatas automaatne remediaatsioon, mis viis lingi kaudu installifaili .exe. See lubas tavakasutajatel pääseda failiserverisse ja sealt vajalikku tarkvara alla laadida. Kahjuks ei tundnud admin hästi ISE süsteemi ja rikkus skaneerimise mehhanisme — kirjutas poliitika valesti, mis viis probleemini, mille lahendamiseks meid kaasati. Isiklikult olen ma siiralt üllatunud sellisest loomingulisest lähenemisest, sest domeeni kontrolleri loomine oleks olnud palju odavam ja vähem töömahukas. Kuid kontseptsiooni tõendina töötas see.

Rohkem tehnilisi nüansse, mis võivad ilmneda Cisco ISE rakendamisel, loe minu kolleegi artiklist „Cisco ISE rakendamise praktika. Inseneri vaatenurk“.

Artem Bobrikov, projektiinsener «Infossüsteemide Jet» infosecurity keskuses

Eessõna:
Kuigi see postitus räägib Cisco ISE süsteemist, on kirjeldatud probleemid aktuaalsed kõikide NAC lahenduste klasside puhul. Pole tähtis, millise tootja lahendust plaanitakse rakendada — suur osa eeltoodust jääb kehtima.

Allikas: habr.com