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

Kui tihti ostate midagi impulsi ajel, nähes suurepärast reklaami, ja siis see algselt soovitud ese tolmuteeb kapis, panipaigas või garaažis kuni järgmise suure koristamise või kolimiseni? Tulemuseks on pettumus põhjendamatute ootuste ja asjatult kulutatud raha tõttu. Veel hullem on, kui see juhtub äris. Tihti on turundustrikid nii head, et ettevõtted ostavad kalli lahenduse, nägemata kogu selle rakendamise pilti. Samas aitab süsteemi prooviversioon mõista, kuidas valmistada infrastruktuur ette integreerimiseks, millist funktsionaalsust ja kui suures mahus on mõistlik rakendada. Nii saab vältida tohutult palju probleeme, mille põhjuseks on toote „pimedat” valimist. Lisaks toob nõuetekohase „piloodi” järel rakendamine inseneridele palju vähem purustatud närvirakke ja halli juukseid. Räägime, miks piloottestimine on eduka projekti jaoks nii oluline, kasutades näiteks populaarset tööriista ettevõtte sisevõrgu juurdepääsu kontrollimiseks — Cisco ISE. Arutame nii tüüpilisi kui ka täiesti ebatavalisi lahenduse rakendamise variante, millega oleme oma praktikates kokku puutunud.

Cisco ISE — «Radius-server steroididega»

Cisco Identity Services Engine (ISE) on platvorm, mis võimaldab luua organisatsiooni lokaalse arvutivõrgu ligipääsukontrolli süsteemi. Ekspertide seas on toode tuntud kui „Radius-server steroididega“. Miks nii? Eessõna on basically lahendus, mis on Radius-server, millele on lisatud hulk lisateenuseid ja funktsioone, võimaldades koguda suurt hulka kontekstitabeleid ja rakendada saadud andmeid ligipääsupoliitikates.

Nagu iga teine Radius-server, suhtleb Cisco ISE juurdepääsu võrguseadmetega, kogub teavet kõigi katsete kohta ühendada ettevõtte võrku ja põhinedes autentimise ja volitamise poliitikatele, lubab või keelab kasutajatel siseneda lokaalsesse arvutivõrku. Siiski võimaldab profileerimine, portitsioneerimine ja integreerimine teiste küberturbe lahendustega oluliselt keerukamaks muuta volituspoliitika loogikat ja seeläbi lahendada üsna keerulisi ja huvitavaid ülesandeid.

Rakendada ei tohi katsetada: miks on vajalik testimine?

Pilootkatsetamise väärtus seisneb süsteemi kõigi võimaluste demonstreerimises konkreetse organisatsiooni infrastruktuuris. Olen veendunud, et Cisco ISE pilootimine enne rakendamist on kõigile projekti osalejatele kasulik, ja siin on põhjused.

Integratooride jaoks annab see selge arusaama kliendi ootustest ja aitab koostada õige tehnilise ülesande, mis sisaldab palju rohkem detaile kui lihtsalt lause „tehke nii, et kõik oleks hästi”. „Piloot” võimaldab meil tunneneda kliendi muresid, mõista, millised ülesanded on talle prioriteetsed ja millised teisejärgulised. See on suurepärane võimalus eelnevalt selgeks teha, millist varustust organisatsioonis kasutatakse, kuidas rakendamine toimub, millistel platvormidel, kus need asuvad ja nii edasi.

Kliendid saavad piloottestimise käigus näha süsteemi reaalses töös, tutvuda selle liidese ja võimalustega, kontrollida, kas see on kooskõlas nende olemasoleva riistvaraga, ja saada terviklik ülevaade sellest, kuidas lahendus pärast täieõiguslikku juurutamist töötab. „Piloot“ on see hetk, mil saab näha kõiki võimalikke „karisid“, millega kindlasti tuleb silmitsi seista integreerimise käigus, ning otsustada, kui palju litsentse on vaja soetada.
Mis võib „pilooti“ ajal „välja ujuda“

Nii et kuidas valmistuda nõuetekohaselt Cisco ISE rakendamiseks? Meie kogemuste põhjal oleme välja toonud neli peamist punkti, mida on oluline arvestada süsteemi piloottestimise protsessis.

Formaadi tüüp

Esmaltamiseks peab esmalt otsustama, millises vormis süsteem rakendatakse: füüsilises või virtuaalses apolaisis. Igal variandil on oma eelised ja puudused. Näiteks on füüsilise apolai tugevus prognoositav jõudlus, kuid ei tohi unustada, et sellised seadmed vananevad aja jooksul. Virtuaalsed apolaid on vähem ennustatavad, kuna need sõltuvad riistvarast, mille peal virtualiseerimiskeskkond on loodud, kuid see-eest on neil suurepärane pluss: toetuse olemasolul on neid alati võimalik uuendada viimasele versioonile.

Kas teie võrguseadmed on ühilduvad Cisco ISE-ga?

Muidugi oleks ideaalne stsenaarium, kui ühendada kõik seadmed süsteemiga korraga. Kuid see ei pruugi alati võimalik olla, kuna paljud organisatsioonid kasutavad endiselt haldamata lüliteid või lüliteid, mis ei toeta osasid tehnoloogiaid, millega Cisco ISE töötab. Peale selle ei räägi me ainult lülititest, vaid see võivad olla ka traadita võrgu kontrollerid. VPN-keskendajaid ja muud seadmed, millega kasutajad ühenduvad. Minu praktikas on olnud juhtumeid, kui süsteemi demonstreerimise järel täieõiguslikuks juurutamiseks uuendas klient praktiliselt kogu juurdepääsu lülitite parki uuenduslikule Cisco seadmetele. Et vältida ebameeldivaid üllatusi, tuleks ette uurida mittetoetatud seadmete osakaal.

Kas kõik teie seadmed on standardiseeritud?

Igas võrgus on olemas standardseadmed, mille ühendamisega ei tohiks probleeme tekkida: automatiseeritud töökohtade, IP-telefonide, Wi-Fi juurdepääsupunktide, videokaamerate jne. Kuid juhtub ka, et kohaliku võrgu (LAN) tuleb ühendada mittestandardseid seadmeid, näiteks RS232/Ethernet signaalikonvertoreid, katkematute toiteallikate liidesi, erinevaid tehnoloogilisi seadmeid jne. Selliste seadmete loetelu on oluline eelnevalt määratleda, et juurutamisetapil oleks teil arusaam, kuidas need tehniliselt Cisco ISE-ga töötavad.

Konstruktiivne dialoog IT-professionaalidega

Cisco ISE kasutavad sageli turbosakonnad, samal ajal kui juurdepääsu lülitite ja Active Directory seadistamise eest vastutavad tavaliselt IT-osakonnad. Seetõttu on turva- ja IT-professionaalide tihe koostöö üks tähtsamaid tingimusi süsteemi sujuvaks juurutamiseks. Kui viimased suhtuvad integratsiooni negatiivselt, tuleks neile selgitada, kuidas lahendus IT-osakonnale kasulik on.

Cisco ISE viis peamist kasutusjuhtu

Meie kogemuse põhjal tuvastatakse vajalikke funktsioone süsteemi pilootkatsete käigus. Allpool on toodud mõned kõige populaarsemad ja vähem levinud kasutusjuhtumid.

Turvaline juurdepääs kohaliku ala võrku juhtmega EAP-TLS abil

Uuringute tulemused meie pentesterite poolt näitavad, et pahatahtlikud isikud kasutavad sageli ettevõtte võrku sisenemiseks tavalisi pistikupesi, mille külge on ühendatud printerid, telefonid, IP-kaamerad, Wi-Fi punktid ja muud isiklikud võrgu seadmed. Seetõttu, isegi kui võrku pääsemine toimub dot1x tehnoloogial, ent kasutatakse alternatiivseid protokolle ilma autentimissertifikaatide kasutamiseta, on suur tõenäosus edukaks rünnakuks, sealhulgas sessioonide ülevõtmine ja paroolide bruteforce. Cisco ISE puhul on sertifikaadi häkkimine tunduvalt keerulisem – selleks vajavad häkkerid palju suuremat arvutusvõimet, mistõttu on see juhtum väga efektiivne.

Kahe võrgu SSID

Selle stsenaariumi põhisisu on kahe võrgu identifikaatori (SSID) kasutamine. Ühte neist võib tinglikult nimetada "külalis-SSIDiks". Selle kaudu saavad traadita võrku siseneda nii külalised kui ka ettevõtte töötajad. Viimased suunatakse ühenduse loomise katse korral spetsiaalsele portaali, kus toimub provisioneerimine. See tähendab, et kasutajale väljastatakse sertifikaat ja tema isiklik seade seadistatakse automaatseks üleviimiseks teise SSID-le, kus juba kasutatakse EAP-TLS-i koos kõigi eelistega, mida pakub esimene juhtum.

MAC autentimise ümbersuunamine ja profiilimine

Teine populaarne juhtum on ühendatud seadme tüübi automaatne tuvastamine ja õigete piirangute rakendamine. Miks see on huvitav? Asi on selles, et siiani on palju seadmeid, mis ei toeta autentimist protokolli 802.1X kaudu. Seetõttu tuleb neid seadmeid võrku lubada MAC-aadressi kaudu, mida on suhteliselt lihtne võltsida. Siin tuleb appi Cisco ISE: süsteemi abil saab näha, kuidas seade võrku käitub, koostada selle profiili ja viia see vastavusse teiste seadmete grupiga, näiteks IP-telefon ja tööjaam. Kui ründaja üritab MAC-aadressi petta ja võrku ühenduda, näeb süsteem, et seadme profiil on muutunud, annab märku kahtlasest käitumisest ja ei luba kahtlast kasutajat võrku.

EAP-Chaining

EAP-Chaining tehnoloogia võimaldab järjestikust autentimist töö arvuti ja kasutajakonto vahel. See lähenemine on laialdaselt levinud, kuna paljudes ettevõtetes ei ole endiselt soovitatav töötajate isiklike seadmete ühendamine ettevõtte LAN-iga. Selle autentimismeetodi abil on võimalik kontrollida, kas konkreetne tööjaam on domeeni liige, ja negatiivse tulemuse korral kas kasutaja ei pääse võrku või pääseb, kuid teatud piirangutega.

Posturing

Selles kontekstis räägitakse tööjaama tarkvara koostise vastavuse hindamisest teabe turbe nõuetele. Selle tehnoloogia abil on võimalik kontrollida, kas tööjaama tarkvara on ajakohane, kas seal on kaitsevahendid, kas hosti tulemüür on seadistatud jne. Huvi pakub, et see tehnoloogia võimaldab lahendada ka muid ülesandeid, mis ei ole otseselt seotud turvalisusega, näiteks vajalike failide või üldkasutatava tarkvara olemasolu kontrollimist.

Harvemini esinevad ka sellised Cisco ISE kasutuse сценарид, nagu juurdepääsu kontrolle läbi domeeni autentimise (Passive ID), SGT-põhine mikrosegmentatsioon ja filtreerimine, samuti integreerimine mobiilseadmete haldamise süsteemide (MDM) ja haavatavuste skanneritega (Vulnerability Scanner).

Ebatavalised projektid: miks veel võib Cisco ISEt vajada, või 3 haruldast juhtumit meie praktikas

Juhtimise kontroll Linuxi serveritele

Kord üks kord lahendasime üsna keerulise juhtumi ühe kliendi jaoks, kellel oli juba rakendatud Cisco ISE süsteem: meil oli vaja leida viis, kuidas hallata kasutajate tegevust (peamiselt administreerijad) Linuxiga serverites. Vastuse otsimisel tuli meelde kasutada avatud lähtekoodiga PAM Radius Module, mis võimaldab siseneda Linuxi serveritesse autentimisega välise radius-serveri kaudu. Kõik oleks olnud hästi, kui mitte üks „aga”: radius-server vastates autentimise päringule annab tagasi ainult kasutajanime ja tulemuse — assess accepted või assess rejected. Samas on Linuxis autoriseerimiseks vaja määrata vähemalt üks parameeter — home directory, et kasutaja saaks kuhugi siseneda. Me ei leidnud võimalust, kuidas seda radius-atribuutina edastada, seetõttu kirjutasime spetsiaalse skripti, et kaugelt luua kontosid hostides poolautomaatse režiimi korral. See ülesanne oli täiesti teostatav, kuna olime tegelemises administreerijate kontodega, mille hulk ei olnud nii suur. Edasi pääsesid kasutajad vajalikule seadmele, mille järel neile määrati vajalik juurdepääs. Tekib õigustatud küsimus: kas Cisco ISE kasutamine on sellistes juhtumites tingimata vajalik? Tegelikult ei ole — sobib mistahes radius-server, kuid kuna kliendil oli juba antud süsteem, siis lisasime sellele lihtsalt uue funktsiooni.

Riistvara ja tarkvara inventuur lokaalses võrku

Kordagi projekti käigus töötasime Cisco ISE tarnimise kallal ühele kliendile, ilma eelneva prooviversioonita. Lahenduse jaoks ei olnud selgeid nõudeid, ning lisaks tegelesime tasase, segmenteerimata võrguga, mis keeruliseks meie ülesande. Projekti käigus seadistasime kõik võimalikud profiilimismeetodid, mida võrk toetas: NetFlow, DHCP, SNMP, AD-ga integreerimine jne. Lõppkokkuvõttes seadistik tähtsustamise juurdepääsu MAR-i kaudu, võimaldades pääseda võrku ka tõrkuva autentimise korral. 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 mitme nädala jooksul aitas meil välja tuua ühendatud süsteemid ja isikupäratuid seadmeid ning välja töötada segmenteerimise lähenemise. Pärast seda seadistasime lisaks jagamise tööjaamadele agendi installimiseks, et koguda teavet nendele installitud tarkvara kohta. Mis lõpuks? Meil õnnestus võrku segmenteerida ja määrata loetelu tarkvarast, mille töötajatelt tuleb eemaldada. Ei saa salata, edasi liikuvad ülesanded kasutajate jagamisel domeenigruppidesse ja juurdepääsu õiguste eraldamises võtsid meilt üsna palju aega, kuid saime täieliku pildi sellest, milline „hardware” kliendi võrgus oli. Ütleme nii, et see ei olnud keeruline hea profiilimise „kastist välja” töö tõttu. Ja seal, kus profiilimist ei aidanud, vaatlesime ise, määrates välja lüliti porti, kuhu seade oli ühendatud.

Kauginstallatsioon tööjaamadele

See juhtum on üks kummalisemaid minu praktikas. Ükskord pöördus meie poole klient hädaldades — Cisco ISE rakendamisel läks midagi valesti, kõik kukkus kokku ja keegi ei saanud enam võrku juurde. Hakkasime asja uurima ja selgus järgmist. Ettevõttes oli 2000 arvutit, mille haldamine toimus administraatori kontolt, kuna domeenikontrollerit ei olnud. Organisatsioonis viidi ellu Cisco ISE, et kuidagi aru saada, kas olemasolevates arvutites on viirusetõrje, kas tarkvarakeskkond on ajakohane jne. Kuna võrgu varustust haldasid IT-administraatorid, oli loogiline, et neil oli sellele ligipääs. Vaadates, kuidas süsteem töötab ja tehes oma arvutites sarnaseid kontrollimisi, kandsid adminnid välja idee installida tarkvara töötajate tööjaamadesse kaugjuhtimise teel ilma isiklikke külastusi tegemata. Kujutage vaid ette, kui palju samme nii saab päevast säästa! Adminnid viisid läbi mitmeid ARM-i kontrollimisi teatud faili olemasolu kohta kaustas C:Program Files, ja selle puudumisel käivitati automaatne remediaatsioon lingi kaudu, mis viis failihoidlasse installifailile .exe. See võimaldas tavalistel kasutajatel pääseda faili jagamisele ja sealt vajalikku tarkvara alla laadida. Kahjuks ei tundnud admin süsteemi ISE hästi ja rikkus ressursside haldamise mehhanisme — ta kirjutas poliitika valesti, mis viis probleemini, mille lahendamiseks meid kaasati. Isiklikult olen ma siiralt üllatunud sellisest loomingulisest lähenemisest, sest oluliselt odavam ja vähem töömahukas oleks olnud domeenikontrolleri loomine. Aga Proof of concept'ina toimis see.

Lisainfot tehnilistest nüanssidest, mis tekivad Cisco ISE juurutamisel, leiate minu kolleegi artiklist „Cisco ISE juurutamise praktika. Inseneri vaade“.

Artem Bobrikov, Infotehnoloogia keskuse projekteerimisinsener ettevõttes „Infosüsteemid Jet“

Järelsõna:
Kuigi see postitus räägib süsteemist Cisco ISE, on kirjeldatud probleemid asjakohased kogu NAC lahenduste klassi jaoks. Ei ole oluline, millise tootja lahendust kavatsetakse juurutada — suurem osa eelöeldud jääb kehtima.

Allikas: habr.com