TLS VPN проти IPsec: п'ять полів, які варто переглянути

Упорядкування TLS VPN проти IPsec VPN за родиною протоколів відповідає на питання, яке ніхто не ставив, і зазвичай посилається на конструкцію, від якої обидві родини відмовилися роки тому. Те, що рецензент справді може оцінити, — це узгоджений захист, ідентичність партнера, модель клієнта та відкритий сервіс. Ці чотири речі видно під час розгортання, і жодна з них не випливає з етикетки продукту. Попросіть п'ять полів, і розмова стане конкретною.

П'ять полів, і етикетки серед них немає

Перше поле — підтриманий випуск програмного забезпечення, бо опис протоколу без версії є брошурою. Друге — узгоджена версія протоколу, яка вирішує, які конструкції взагалі доступні. Третє — набір захисту, четверте — метод автентифікації як партнера, так і користувача, а п'яте — обсяг доступу, який продукт надає після допуску.

Етикетка SSL VPN охоплює щонайменше три різні продукти: повноцінний мережевий клієнт, проксі застосунків і застарілий портал на основі браузера. Вони відкривають різні сервіси та відмовляють по-різному, тож етикетка не може замінити поле обсягу.

Що насправді змінює автентифіковане шифрування

TLS 1.3 вимагає автентифікованого шифрування, що прибирає з протоколу старішу конструкцію MAC-then-encrypt, а не робить її необов'язковою. IPsec ESP має набори автентифікованого шифрування так само давно, причому AES-GCM визначено в окремому RFC. В обох родинах гарантія походить із узгодженого набору, а не з назви родини, тому список полів починається з версії. Рецензентові, який не може назвати набір, нема чого оцінювати.

Тому історичне порівняння вводить в оману. Розгортання, закріплене на старій версії TLS з набором CBC, і інше, де працює TLS 1.3 з набором AEAD, — це не однакова позиція безпеки, хоча обидва є TLS VPN. Той самий розкол є на боці IPsec між сучасним набором ESP і застарілою комбінацією.

Читайте узгоджені значення, а не конфігурацію, яку ви задумали. Команди нижче показують, про що насправді домовилися робоча кінцева точка та робочий тунель.

openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas

Якщо кінцева точка не хоче узгоджувати TLS 1.3, це знахідка, а не вподобання. Якщо тунель перелічує набір, якого ви не очікували, важливою є та конфігурація, яку обрали партнери, а не та, що в шаблоні.

Ідентичність партнера — окреме питання

Шифрування без перевіреного партнера захищає трафік від спостерігачів і передає його тому, хто відповів на з'єднання. Автентифікація партнера запитує, яка ідентичність очікується, який матеріал довіри її підтверджує і як клієнт поводиться, коли відповідь не збігається. Ланцюжок сертифікатів, закріплений ключ і заздалегідь розділений секрет — це три різні відповіді з трьома різними експлуатаційними витратами.

Потім поставте ті самі питання про користувача або пристрій. Шлюз, який автентифікує машину й допускає будь-якого користувача, або навпаки, має конкретну позицію, яку слід записати, а не припускати. Дозволи на ресурси, застосовані після допуску, належать до того самого поля, бо автентифікація — це не авторизація.

Збереження перевірок імені хоста й сертифіката важливіше за звичність вікна входу. Клієнт, налаштований ігнорувати перевірку, усунув єдиний крок, який відрізняє ваш шлюз від переконливої імітації.

Межа, яку відкриває продукт

Портал без клієнта проксіює вибрані операції застосунків через шлюз, тож користувач потрапляє в інтерфейс, а не в мережу. Клієнт повного тунелю несе те, що обирають його маршрути й політика фільтрації, а це значно більша поверхня. Порівняння двох за стійкістю протоколу оминає різницю в тому, до чого зловмисник може дістатися через них. Одне відкриває інтерфейс застосунку, інше — маршрутизовану мережу, і обидва потребують різних перевірок.

Запитайте, який сервіс відкрито, які операції дозволено і на чому слухає сам шлюз. Інтерфейс керування, доступний із тієї ж адреси, що й користувацький портал, — це знахідка розгортання, і жоден вибір протоколу її не компенсує.

Обсяг на рівні застосунку ще звужує поверхню й змінює поведінку під час відмови, коли тунель падає. Проєкт, що припускає повний обсяг тунелю, ламається так, як проєкт на рівні застосунку не ламається, і навантаження на підтримку зростає.

Вирішіть результат відмови та життєвий цикл

Те, що відбувається, коли автентифікація або захист недоступні, — це рішення політики, яке належить до перегляду. Заблокований результат і неоголошений прямий відкат мають різні наслідки, і різниця невидима у списку функцій. Зазначте передбачувану поведінку поруч із ресурсом, який вона захищає.

Включіть життєвий цикл виправлень і підтримки шлюзу, його увімкнені зовнішні функції та шлях оновлення клієнтів. Правильний вибір протоколу не робить безпечним погано розгорнутий сервіс, і більшість інцидентів живуть саме в цій прогалині, а не в наборі.

Запишіть п'ять полів, політику відмови та власника життєвого циклу на одну сторінку. Ця сторінка — перегляд; порівняння родин протоколів — думка.