В офисном Wi-Fi, но всё равно просят VPN? Вот почему

Ноутбук в корпоративном SSID, запрос сертификата принят, а веб-приложение всё равно требует VPN. Это выглядит как двойная работа, и иногда так и есть. Два входа обычно применяют разные решения, и единственный способ узнать, заслуживает ли второй своё место, — спросить, что он меняет.

Подключение к сети — это решение о допуске

Развёртывание 802.1X отвечает на один вопрос: может ли это устройство или пользователь подключиться к этой сети? Точка доступа передаёт учётные данные серверу RADIUS, а ответ может нести атрибуты, которые помещают сеанс в определённый VLAN или применяют фильтр. Это допуск и сегментация, а не авторизация для конкретного приложения.

После допуска сеанса беспроводной канал шифруется между клиентом и точкой доступа. Защита заканчивается там, на краю проводной сети.

Всё за этой точкой — обычная маршрутизация внутри здания, с той внутренней доступностью, которую разрешает сегмент.

Что на самом деле защищает EAP-TTLS

EAP-TTLS строит туннель TLS во время аутентификации и запускает внутри него внутренний метод. Внутренним методом часто бывает PAP, и его появление в проекте не означает, что пароль идёт по воздуху открытым текстом, потому что его несёт именно туннель TLS. Клиент всё равно должен проверить подлинность сервера и доверять правильному CA, а знакомый SSID — это не такая проверка. Читайте выбор внутреннего метода как формат учётных данных, а не как утверждение о внешнем шифровании.

Это обмен аутентификации, а не туннель данных для последующего трафика ноутбука.

Когда аутентификация заканчивается, туннель TLS исчезает, и пакеты клиента идут по допущенному сегменту. Смешение этих двух вещей — корень убеждения, что шифрование Wi-Fi уже выполняет работу VPN.

VPN — это второе, более узкое решение

VPN отвечает на другой вопрос: к каким частным ресурсам может получить доступ эта личность и на каких условиях? Он завершается на шлюзе с собственной политикой, собственными проверками личности и часто собственными требованиями к состоянию устройства. Доступное множество после подъёма туннеля обычно меньше внутренней сети здания и зависит от роли.

Поэтому роль обслуживания могут допустить в Wi-Fi, как всех остальных, и ей всё равно нужен туннель, чтобы добраться до административной подсети. Решение по Wi-Fi принято на точке доступа; это решение принимается на шлюзе.

Оба этапа могут быть зашифрованы и всё равно применять несвязанные политики.

Где ломается доверие, основанное на местоположении

Отношение к офисной сети как к неявно доверенной терпит неудачу по простой причине: местоположение в сети — свойство соединения, а не человека. Рекомендации NIST по нулевому доверию говорят об этом прямо, и поэтому доступ к ресурсам решается на каждый запрос, а не на каждое здание. Кто подключается к тому же SSID, наследует то же местоположение. Поэтому скомпрометированный ноутбук в сети сотрудников заслуживает того же скепсиса, что и в гостевой сети.

Практическое следствие в том, что авторизация приложений всё ещё должна существовать. VPN, который выдаёт целую подсеть, плюс приложение, доверяющее любому запросу из этой подсети, — это одна учётная запись до плохого дня.

Ни один из слоёв не заменяет другой, потому что они отвечают на вопросы в разных масштабах.

Как понять, заслуживает ли второй вход своего места

Спросите владельца сети о двух вещах: что становится доступным после подключения VPN и какие условия личности или устройства проверяются, чтобы это разрешить? Затем проверьте ответы, тестируя то, что реально отвечает. Если туннель не меняет ни доступность, ни гарантию, это может быть операционная привычка, а не контроль, и это решение владельца, а не то, что пользователь должен обходить.

Ищите также непреднамеренные прямые пути, потому что ресурс, доступный без туннеля, делает туннель декоративным.

Документируйте каждую границу и её цель, и следующему человеку не придётся гадать, почему входов два.