В офісному 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 і які умови особистості або пристрою перевіряються, щоб це дозволити? Потім перевірте відповіді, тестуючи, що насправді відповідає. Якщо тунель не змінює ні доступності, ні гарантії, це може бути операційна звичка, а не контроль, і це рішення власника, а не те, що користувач має обходити.

Шукайте також ненавмисні прямі шляхи, бо ресурс, доступний без тунелю, робить тунель декоративним.

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