Jeden zaměstnanec, dva notebooky a přístup musí ztratit jen jeden z nich. Deaktivace účtu je zřejmá páka, ale trestá špatný rozsah, zatímco smazání uloženého profilu na koncovém bodě je návrh, nikoli kontrola. Rozhodnutí se redukuje na tři podmínky: zda existuje identita zařízení, kterou VPN umí ověřit, zda ji toto konkrétní připojení skutečně vyhodnocuje a co chcete, aby se stalo se zařízením místo s osobou. Odpovězte v tomto pořadí a vynucení si obvykle vybere samo.

První podmínka: existují důkazy o zařízení, které VPN umí ověřit?

Zdrojová adresa je sdílená za kancelářským NAT a v mobilních sítích se mění. Název hostitele je to, co zařízení tvrdí, MAC adresa se triviálně podvrhne a hodnotu v registru může zapsat cokoli s místními právy. Nic z toho není identita, dokud to něco neověří. Samostatně zapsaný pověřený údaj zařízení, například certifikát vydaný tomuto koncovému bodu, je jediná možnost, která dává odvolání cíl užší než uživatelský účet.

Pověřený údaj se počítá jen tehdy, když se jím připojení autentizuje a při každém pokusu ověří řetěz. Soubor ležící v úložišti stroje nic nedokazuje.

Druhá podmínka: vyhodnocuje toto připojení ten údaj?

Atributy koncového bodu nejsou univerzální. Na ASA průvodce ASDM DAP od Cisco odděluje uživatelské informace AAA od atributů hodnocení koncového bodu a dostupnost atributů závisí na použitém protokolu vzdáleného přístupu, nasazených nástrojích posture a licenci. Kontrola registru potřebuje podporovanou cestu sběru, a i pak hlásí, co viděl nástroj koncového bodu, ne že stroj je ten, kterému věříte.

Praktická otázka je tedy úzká: na tomto tunelu, s tímto klientem a tímto posture agentem, který atribut dorazí vyplněný a důvěryhodný? Pokud odpověď zní žádný, politika proti němu napsaná bude odpovídat ničemu nebo všemu a oba výsledky jsou horší než zámek účtu, kterému jste se vyhýbali.

Třetí podmínka: odmítnutí, náprava, nebo užší přístup?

K dispozici jsou tři výsledky a nejsou zaměnitelné. Můžete ukončit relaci, což přístup zcela odstraní; můžete zařízení umístit do karantény do stavu, kdy dosáhne jen na prostředky nápravy; nebo můžete relaci ponechat a seříznout její ACL prostředků na několik věcí, které zařízení ještě potřebuje. Akce relace DAP a ACL prostředků odpovídají na různé otázky, takže volba je o tom, kolik vedlejší škody má osoba snést.

U ztraceného nebo ukradeného notebooku je odpovědí obvykle ukončení. U stroje, který neprošel kontrolou posture, je náprava laskavější a stejně účinná.

Rozhodněte, co se stane, když důkazy chybí

Výchozí cesta je důležitější než pravidlo, které jste napsali pro dobrý případ. Pokud očekávaný atribut nikdy nedorazí, protože posture agent je rozbitý, politika, která ho vyžaduje, může propadnout na výchozí hodnotu, která relaci pustí. Přečtěte si výchozí výsledek a případ chybějících důkazů záměrně otestujte, protože to je stav, který předvede útočník, jenž agenta odstraní.

Více odpovídajících záznamů DAP se agreguje, nikoli řeší prostým pořadím prvního zásahu, a jejich priorita ACL je samostatný mechanismus od výběru záznamu. Přečtěte si popis agregace v průvodci, než budete předpokládat, že vyhraje přísnější záznam.

Vyřešte relace, které už existují, a pak otestujte oba stroje

Změna pravidla přijetí nebo odvolání pověřeného údaje nepopisuje, co se stane s relací, která už je navázaná a přenáší provoz. Pokud je požadavkem okamžité odstranění, postupujte podle implementací podporovaného postupu ukončení a přehodnocení relace, místo abyste čekali na další opětovné připojení. To je krok, který se při incidentu nejčastěji přeskakuje, a je to rozdíl mezi politikou a výsledkem.

Testujte se stejným povoleným uživatelem na obou strojích v rámci schválené kontroly. Blokované zařízení má dostat přesně zamýšlené odmítnutí nebo výsledek nápravy a druhé má zachovat jen své autorizované prostředky. Tím se ověří hranice zařízení, aniž by se odvolal jiný schválený přístup osoby.

Pokud nedokážete tyto dva výsledky odlišit, problém je v důkazech, ne v politice, a žádné ladění pravidel to nespraví.

Související články