Чи потрібен вам ще VPN, якщо ви використовуєте Identity-Aware Proxy?

Припущення таке: щойно перед внутрішніми застосунками стане проксі, який знає ідентичність, VPN — лише прикраса, і клієнт може піти. Це правда для одного вузького випадку, інтерактивного HTTPS-застосунку, який людина використовує в браузері, і тихо ламається всюди інде. Проксі авторизує запит до ресурсу; VPN допускає клієнта в область мережі, і ці дві межі рідко збігаються. Перш ніж вивести тунель з експлуатації, порівняйте операції, які ваші люди насправді виконують, а не назви продуктів на схемі.

Двоє воріт авторизують різні речі

Ворота застосунку вирішують, чи може цей запит від цієї ідентичності дістатися цього захищеного ресурсу. Огляд Identity-Aware Proxy від Google описує саме цю форму: центральний шар авторизації перед HTTPS-застосунками, яким керує роль IAM. Межа — це ресурс, а одиниця доступу — запит. Маршрутизований VPN робить щось грубіше й ширше: допускає клієнта в визначену область мережі, після чого застосунок усе ще вирішує, що може робити цей клієнт.

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

Що проксі не охоплює, а VPN охоплює

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

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

Робочий процес клієнта вирішує більше, ніж схема архітектури

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

Спершу порахуйте клієнтів, а вже потім застосунки. Один дашборд може обслуговувати сто людей; один порт бази даних може заблокувати цілу команду.

Стан пристрою — не властивість жодних з воріт

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

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

Знайдіть альтернативні шляхи, перш ніж щось вимкнути

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

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

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