Блокиране на едно устройство от VPN, без да деактивирате целия акаунт

Един служител, два лаптопа и само единият от тях трябва да загуби достъп. Деактивирането на акаунта е очевидният лост, но наказва грешния обхват, докато изтриването на запазен профил на крайната точка е предложение, а не контрол. Решението се свежда до три условия: дали съществува идентичност на устройството, която VPN може да провери, дали тази конкретна връзка действително я оценява и какво искате да се случи с устройството, а не с човека. Отговорете им в този ред и прилагането обикновено се избира само.

Първо условие: има ли доказателства за устройството, които VPN може да провери?

Изходният адрес е споделен зад офисния NAT и се променя в мобилните мрежи. Името на хоста е това, което устройството твърди, MAC адресът се подправя тривиално, а стойност в регистъра може да запише всичко с локални права. Никое от тях не е идентичност, докато нещо не го провери. Отделно регистрирани идентификационни данни за устройство, като сертификат, издаден на тази крайна точка, е единствената опция, която дава на отнемането цел, по-тясна от потребителския акаунт.

Идентификационните данни се броят само ако връзката се удостоверява с тях и проверява веригата при всеки опит. Файл, който стои в хранилището на машината, не доказва нищо.

Второ условие: тази връзка оценява ли го?

Атрибутите на крайната точка не са универсални. На ASA ръководството ASDM DAP на Cisco разделя информацията за AAA на потребителя от атрибутите за оценка на крайната точка, а кои атрибути са налични зависи от използвания протокол за отдалечен достъп, внедрените инструменти за posture и лиценза. Проверката на регистъра изисква поддържан път за събиране и дори тогава съобщава какво е видял инструментът на крайната точка, а не че машината е тази, на която вярвате.

Затова практичният въпрос е тесен: в този тунел, с този клиент и този posture агент, кой атрибут пристига попълнен и надежден? Ако отговорът е никой, политика, написана срещу него, ще съвпада с нищо или с всичко и двата резултата са по-лоши от заключването на акаунта, което избягвахте.

Трето условие: отказ, поправяне или по-тесен достъп?

Налични са три резултата и те не са взаимозаменяеми. Можете да прекратите сесията, което премахва достъпа напълно; можете да поставите устройството под карантина в състояние, в което достига само до ресурси за поправяне; или можете да оставите сесията и да отрежете ACL за ресурси до малкото неща, които устройството все още има нужда да достига. DAP действията на сесията и ACL за ресурси отговарят на различни въпроси, така че изборът е за това колко съпътстващи щети трябва да понесе човекът.

За изгубен или откраднат лаптоп отговорът обикновено е прекратяване. За машина, която не е преминала проверка на posture, поправянето е по-меко и също толкова ефективно.

Решете какво се случва, когато доказателствата липсват

Пътят по подразбиране е по-важен от правилото, което написахте за добрия случай. Ако очакваният атрибут никога не пристигне, защото posture агентът е повреден, политика, която го изисква, може да пропадне към подразбиране, което допуска сесията. Прочетете резултата по подразбиране и тествайте умишлено случая с липсващи доказателства, защото това е състоянието, което нападател, който премахне агента, ще представи.

Множество съвпадащи DAP записи се агрегират, а не се решават чрез прост ред на първо съвпадение, и техният ACL приоритет е отделен механизъм от избора на запис. Прочетете описанието на агрегирането в ръководството, преди да приемете, че по-стриктният запис печели.

Работете със сесии, които вече съществуват, след това тествайте двете устройства

Промяната на правило за допускане или отнемането на идентификационни данни не описва какво се случва със сесия, която вече е установена и пропуска трафик. Ако незабавното премахване е изискването, следвайте поддържаната от реализацията процедура за прекратяване и преоценка на сесията, вместо да чакате следващото повторно свързване. Това е стъпката, която най-често се пропуска по време на инцидент, и това е разликата между политика и резултат.

Тествайте със същия разрешен потребител на двете машини под одобрена проверка. Блокираното устройство трябва да получи точно предвидения отказ или резултат от поправяне, а другото да запази само разрешените си ресурси. Това проверява границата на устройството, без да отнема другия одобрен достъп на човека.

Ако не можете да направите тези два резултата различни, проблемът е в доказателствата, а не в политиката, и никакво настройване на правила няма да го поправи.