Kui sageli ostate midagi spontaanselt lahedale kuulutusele alistudes ja siis kogub see esialgu ihaldatud ese kuni järgmise kevadise suurpuhastuse või kolimiseni kapis, sahvris või garaažis tolmu? Tulemuseks on pettumus põhjendamatute ootuste ja raisatud raha tõttu. See on palju hullem, kui see juhtub ettevõttega. Väga sageli on turundustrikid nii head, et ettevõtted ostavad kalli lahenduse, nägemata selle rakendusest täit pilti. Samas aitab süsteemi proovitestimine mõista, kuidas taristut integreerimiseks ette valmistada, millist funktsionaalsust ja millises mahus tuleks rakendada. Nii saate vältida tohutul hulgal probleeme, mis tulenevad toote "pimesi" valimisest. Lisaks toob rakendamine pärast pädevat "piloodit" inseneridele palju vähem hävitatud närvirakke ja halle juukseid. Mõelgem välja, miks on piloottestimine eduka projekti jaoks nii oluline, kasutades populaarse ettevõtte võrgule juurdepääsu kontrollimise tööriista - Cisco ISE - näidet. Vaatleme nii standardseid kui ka täiesti mittestandardseid võimalusi lahenduse kasutamiseks, millega meie praktikas kokku puutusime.
Cisco ISE – "Radiuse server steroididel"
Cisco Identity Services Engine (ISE) on platvorm organisatsiooni kohtvõrgu juurdepääsukontrollisüsteemi loomiseks. Ekspertkogukonnas kandis toode selle omaduste tõttu hüüdnime "Radius server on steroids". Miks nii? Sisuliselt on lahenduseks Radius server, millele on lisatud tohutul hulgal lisateenuseid ja “nippe”, mis võimaldavad saada suurel hulgal kontekstuaalset infot ning rakendada sellest tulenevat andmekomplekti juurdepääsupoliitikates.
Nagu iga teine Radiuse server, suhtleb Cisco ISE juurdepääsutasemega võrguseadmetega, kogub teavet kõigi ettevõtte võrguga ühenduse loomise katsete kohta ning lubab või keelab kasutajatel LAN-i autentimis- ja autoriseerimispoliitikate alusel. Profiilide koostamise, postitamise ja teiste infoturbelahendustega integreerimise võimalus võimaldab aga autoriseerimispoliitika loogikat oluliselt keerulisemaks muuta ning seeläbi lahendada üsna keerulisi ja huvitavaid probleeme.
Rakendamist ei saa piloteerida: miks on vaja testimist?
Piloottestimise väärtus seisneb süsteemi kõigi võimaluste demonstreerimises konkreetse organisatsiooni konkreetses infrastruktuuris. Usun, et Cisco ISE katsetamine enne juurutamist on kasulik kõigile projektiga seotud osalejatele ja siin on põhjus.
See annab integraatoritele selge ettekujutuse kliendi ootustest ja aitab luua õige tehnilise spetsifikatsiooni, mis sisaldab palju rohkem üksikasju kui levinud fraas "veendu, et kõik on korras". “Piloot” võimaldab meil tunda kogu kliendi valu, mõista, millised ülesanded on tema jaoks prioriteetsed ja millised teisejärgulised. Meie jaoks on see suurepärane võimalus eelnevalt selgeks teha, milliseid seadmeid organisatsioonis kasutatakse, kuidas juurutamine toimub, millistel objektidel, kus need asuvad jne.
Piloottestimise käigus näevad kliendid reaalset süsteemi töös, tutvuvad selle liidesega, saavad kontrollida selle ühilduvust olemasoleva riistvaraga ning saavad tervikliku arusaama sellest, kuidas lahendus pärast täielikku juurutamist töötab. Piloot on just see hetk, mil näete kõiki integreerimisel tõenäoliselt ettetulevaid lõkse ja saate otsustada, kui palju litsentse peate ostma.
Mis võib "piloodi ajal" hüpata
Niisiis, kuidas valmistuda Cisco ISE juurutamiseks korralikult? Oma kogemuse põhjal oleme kokku lugenud 4 peamist punkti, mida on oluline süsteemi piloottestimisel arvestada.
Vormitegur
Esiteks peate otsustama, millises vormis süsteemi rakendatakse: füüsilises või virtuaalses ülaliinis. Igal valikul on eelised ja puudused. Näiteks füüsilise ülemise liini tugevuseks on selle ennustatav jõudlus, kuid me ei tohi unustada, et sellised seadmed vananevad aja jooksul. Virtuaalsed ülemised liinid on vähem etteaimatavad, kuna... sõltuvad riistvarast, millele virtualiseerimiskeskkond juurutatakse, kuid neil on tõsine eelis: kui tugi on saadaval, saab neid alati uusimale versioonile värskendada.
Kas teie võrguseade ühildub Cisco ISE-ga?
Loomulikult oleks ideaalne stsenaarium ühendada kõik seadmed süsteemiga korraga. See ei ole aga alati võimalik, kuna paljud organisatsioonid kasutavad endiselt haldamata lüliteid või lüliteid, mis ei toeta mõnda Cisco ISE-d kasutavat tehnoloogiat. Muide, me ei räägi ainult lülititest, need võivad olla ka traadita võrgu kontrollerid, VPN-i kontsentraatorid ja mis tahes muud seadmed, millega kasutajad ühenduvad. Minu praktikas on ette tulnud juhtumeid, kus klient uuendas pärast süsteemi täielikuks juurutamiseks demonstreerimist peaaegu kogu juurdepääsutaseme lülitite pargi kaasaegsetele Cisco seadmetele. Ebameeldivate üllatuste vältimiseks tasub eelnevalt välja selgitada toetamata varustuse osakaal.
Kas kõik teie seadmed on standardsed?
Igas võrgus on tüüpilised seadmed, millega ühenduse loomine ei tohiks olla keeruline: tööjaamad, IP-telefonid, Wi-Fi pääsupunktid, videokaamerad jne. Kuid juhtub ka seda, et kohtvõrku tuleb ühendada mittestandardsed seadmed, näiteks RS232/Etherneti siini signaalimuundurid, katkematu toiteallika liidesed, erinevad tehnoloogilised seadmed jne. Oluline on eelnevalt kindlaks määrata selliste seadmete nimekiri. , nii et teil on juba juurutamisetapis arusaam, kuidas need tehniliselt Cisco ISE-ga töötavad.
Konstruktiivne dialoog IT-spetsialistidega
Cisco ISE kliendid on sageli turvaosakonnad, samas kui IT-osakonnad vastutavad tavaliselt juurdepääsukihi lülitite ja Active Directory konfigureerimise eest. Seetõttu on turvaspetsialistide ja IT-spetsialistide produktiivne suhtlus üks olulisi tingimusi süsteemi valutuks rakendamiseks. Kui viimased tajuvad lõimumist vaenulikkusega, tasub neile selgitada, kuidas lahendus IT-osakonnale kasulik on.
5 parimat Cisco ISE kasutusjuhtu
Meie kogemuse kohaselt selgitatakse välja ka süsteemi vajalik funktsionaalsus piloottestimise etapis. Allpool on mõned lahenduse kõige populaarsemad ja vähem levinud kasutusjuhud.
Turvaline LAN-juurdepääs juhtme kaudu EAP-TLS-iga
Nagu näitavad meie pentestijate uuringutulemused, kasutavad ründajad üsna sageli ettevõtte võrku tungimiseks tavalisi pistikupesasid, kuhu on ühendatud printerid, telefonid, IP-kaamerad, WiFi-punktid ja muud mittepersonaalsed võrguseadmed. Seega, isegi kui võrgujuurdepääs põhineb dot1x tehnoloogial, kuid kasutatakse alternatiivseid protokolle ilma kasutaja autentimissertifikaate kasutamata, on suur tõenäosus edukaks ründeks seansi pealtkuulamise ja jõhkra jõuga paroolidega. Cisco ISE puhul on sertifikaati palju keerulisem varastada - selleks vajavad häkkerid palju rohkem arvutusvõimsust, seega on see juhtum väga tõhus.
Kahe SSID traadita juurdepääs
Selle stsenaariumi põhiolemus on 2 võrguidentifikaatori (SSID) kasutamine. Ühte neist võib tinglikult nimetada "külaliseks". Selle kaudu pääsevad juhtmeta võrku nii külalised kui ka ettevõtte töötajad. Kui nad üritavad ühendust luua, suunatakse viimased spetsiaalsesse portaali, kus toimub varustamine. See tähendab, et kasutajale väljastatakse sertifikaat ja tema isiklik seade on konfigureeritud automaatselt uuesti ühenduma teise SSID-ga, mis juba kasutab EAP-TLS-i koos kõigi esimese juhtumi eelistega.
MAC-i autentimise ümbersõit ja profileerimine
Teine populaarne kasutusjuht on ühendatud seadme tüübi automaatne tuvastamine ja sellele õigete piirangute rakendamine. Miks ta on huvitav? Fakt on see, et endiselt on üsna palju seadmeid, mis ei toeta 802.1X protokolli abil autentimist. Seetõttu tuleb sellised seadmed võrku lubada MAC-aadressi abil, mida on üsna lihtne võltsida. Siin tulebki appi Cisco ISE: süsteemi abil saad vaadata, kuidas seade võrgus käitub, luua oma profiili ja määrata selle grupile teistele seadmetele, näiteks IP-telefonile ja tööjaamale. . Kui ründaja üritab MAC-aadressi võltsida ja võrguga ühendust luua, näeb süsteem, et seadme profiil on muutunud, annab märku kahtlasest käitumisest ega luba kahtlast kasutajat võrku.
EAP-aheldamine
EAP-ahela tehnoloogia hõlmab töötava arvuti ja kasutajakonto järjestikust autentimist. See juhtum on muutunud laialt levinud, sest... Paljud ettevõtted ei soovita endiselt töötajate isiklike vidinate ühendamist ettevõtte kohtvõrguga. Seda autentimise lähenemisviisi kasutades on võimalik kontrollida, kas konkreetne tööjaam on domeeni liige ja negatiivse tulemuse korral kasutajat kas ei lubata võrku või saab ta siseneda, kuid teatud kindla piiranguid.
Posting
See juhtum käsitleb tööjaama tarkvara infoturbenõuetele vastavuse hindamist. Seda tehnoloogiat kasutades saate kontrollida, kas tööjaama tarkvara on uuendatud, kas sellele on installitud turvameetmed, kas hosti tulemüür on konfigureeritud jne. Huvitaval kombel võimaldab see tehnoloogia lahendada ka muid turvalisusega mitteseotud ülesandeid, näiteks kontrollida vajalike failide olemasolu või installida kogu süsteemi hõlmavat tarkvara.
Cisco ISE vähem levinud kasutusjuhtumid hõlmavad juurdepääsu juhtimist otspunktidevahelise domeeni autentimisega (passiivne ID), SGT-põhist mikrosegmenteerimist ja filtreerimist, samuti integreerimist mobiilseadmete haldussüsteemide (MDM) ja haavatavuse skanneritega.
Mittestandardsed projektid: miks muidu võiks vaja minna Cisco ISE või 3 haruldast juhtumit meie praktikast
Juurdepääsu kontroll Linuxi-põhistele serveritele
Kunagi lahendasime ühe kliendi jaoks, kellel oli juba Cisco ISE süsteem juurutatud, üsna mittetriviaalset juhtumit: pidime leidma võimaluse kontrollida kasutajate (peamiselt administraatorite) toiminguid serverites, kuhu on installitud Linux. Vastust otsides tulime ideele kasutada tasuta tarkvara PAM Radius Module, mis võimaldab teil sisse logida Linuxi töötavatesse serveritesse välise raadiusserveri autentimisega. Kõik selles osas oleks hea, kui mitte ühe "aga" jaoks: raadiuse server, saates autentimispäringule vastuse, annab ainult konto nime ja tulemuse - hinda vastuvõetud või tagasilükatud. Samal ajal peate Linuxis autoriseerimiseks määrama veel vähemalt ühe parameetri - kodukataloogi, et kasutaja vähemalt kuhugi jõuaks. Me ei leidnud viisi, kuidas seda raadiuse atribuudiks anda, seetõttu kirjutasime poolautomaatses režiimis hostides kaugjuhtimisega kontode loomiseks spetsiaalse skripti. See ülesanne oli üsna teostatav, kuna tegemist oli administraatorikontodega, mille arv ei olnud nii suur. Järgmisena logisid kasutajad sisse vajalikku seadmesse, misjärel määrati neile vajalik juurdepääs. Tekib mõistlik küsimus: kas sellistel juhtudel on vaja kasutada Cisco ISE? Tegelikult ei – sobib suvaline raadiusega server, aga kuna kliendil see süsteem juba oli, siis lisasime sellesse lihtsalt uue funktsiooni.
LAN-i riist- ja tarkvara loend
Töötasime kunagi projekti kallal, et tarnida Cisco ISE ühele kliendile ilma esialgse "piloodita". Lahendusele puudusid selged nõuded, lisaks oli tegemist tasase, segmenteerimata võrguga, mis raskendas meie ülesannet. Projekti käigus konfigureerisime kõik võimalikud profileerimismeetodid, mida võrk toetas: NetFlow, DHCP, SNMP, AD integratsioon jne. Selle tulemusena konfigureeriti MAR-juurdepääs võimalusega võrku sisse logida, kui autentimine ebaõnnestus. See tähendab, et isegi kui autentimine ei õnnestunud, lubab süsteem kasutaja ikkagi võrku, kogub tema kohta teavet ja salvestab selle ISE andmebaasi. See mitmenädalane võrguseire aitas meil tuvastada ühendatud süsteemid ja mitteisiklikud seadmed ning töötada välja lähenemisviisi nende segmenteerimiseks. Pärast seda konfigureerisime postitamise täiendavalt agenti tööjaamadesse installimiseks, et koguda teavet nendesse installitud tarkvara kohta. Mis on tulemus? Suutsime võrgu segmentida ja määrata tarkvara loendi, mis tuli tööjaamadest eemaldada. Ma ei varja, et edasised ülesanded kasutajate domeenigruppidesse jaotamisel ja juurdepääsuõiguste piiritlemisel võtsid meil päris palju aega, kuid nii saime täieliku pildi kliendi võrgus olevast riistvarast. Muide, see ei olnud keeruline tänu heale karbist välja profileerimise tööle. Noh, seal, kus profileerimine ei aidanud, vaatasime ise, tõstes esile lüliti pordi, kuhu seadmed olid ühendatud.
Tarkvara kauginstallimine tööjaamadesse
See juhtum on minu praktikas üks kummalisemaid. Ühel päeval tuli meie juurde klient appihüüdega – Cisco ISE juurutamisel läks midagi valesti, kõik läks katki ja keegi teine ei pääsenud võrku. Hakkasime seda uurima ja saime teada järgmist. Ettevõttel oli 2000 arvutit, mida domeenikontrolleri puudumisel hallati administraatori konto all. Peeringu eesmärgil juurutas organisatsioon Cisco ISE. Tuli kuidagi aru saada, kas olemasolevatesse arvutitesse on installitud viirusetõrje, kas tarkvarakeskkonda uuendati jne. Ja kuna IT-administraatorid paigaldasid süsteemi võrguseadmed, on loogiline, et neil oli sellele juurdepääs. Olles näinud, kuidas see töötab, ja oma arvutite viimistlemist, tulid administraatoritele ideele installida tarkvara töötajate tööjaamadesse eemalt ilma isiklike külastusteta. Kujutage vaid ette, kui palju samme saate sel viisil päevas säästa! Administraatorid kontrollisid tööjaamas mitu korda konkreetse faili olemasolu kataloogis C:Program Files ja kui see puudus, käivitati automaatne parandus, järgides failimälule viivat linki installi .exe-faili. See võimaldas tavakasutajatel minna failijagamiskohta ja sealt alla laadida vajalik tarkvara. Kahjuks ei tundnud admin ISE süsteemi hästi ja rikkus postitamismehhanisme - kirjutas poliitika valesti, mistõttu tekkis probleem, mille lahendamisega tegelesime. Mina isiklikult olen siiralt üllatunud sellisest loomingulisest lähenemisest, sest domeenikontrolleri loomine oleks palju odavam ja vähem töömahukas. Kuid kontseptsiooni tõestuseks see töötas.
Lisateavet tehniliste nüansside kohta, mis tekivad Cisco ISE juurutamisel, loe minu kolleegi artiklist .
Artem Bobrikov, Jet Infosystemsi infoturbekeskuse projekteerimisinsener
järelsõna:
Vaatamata asjaolule, et see postitus räägib Cisco ISE süsteemist, on kirjeldatud probleemid olulised kogu NAC-lahenduste klassi jaoks. Pole nii oluline, millise müüja lahendust plaanitakse kasutusele võtta – enamik ülaltoodust jääb kehtima.
Allikas: www.habr.com