Чи потрібен ще VPN сайту, якщо застосунок використовує mTLS і SSO?
Пройдіть канали, які вхід до застосунку ніколи не покриває, і вирішіть, чи доступ до приватної мережі є зайвим, чи досі єдиним шляхом до хоста.
Ви входите через mTLS, панель завантажується, і твердження, що VPN сайту тепер зайвий, звучить розумно приблизно доти, доки о другій годині ночі не знадобиться відновити базу даних. Межа TLS застосунку описує лише один канал. Хост, база даних, ціль резервних копій і хмарний обліковий запис мають кожен свій шлях входу, свою ідентичність і свого затверджувача, і жоден із них не перевіряється успішним входом.
Ідіть назовні від екрана входу
Увійдіть як звичайний користувач і запишіть кожен крок, якого торкається запит: браузер, край, слухач застосунку, сховище сесій, backend API. Кожен крок має власника й рішення про автентифікацію. Тепер повторіть шлях для людини, яка встановлює виправлення на хост, і для завдання, яке пише нічну резервну копію. Ці шляхи зазвичай розходяться вже на першому кроці.
Саме це розходження і є питанням, на яке варто відповісти. VPN сайту є зайвим лише тоді, коли кожен канал цього другого шляху має самостійну політику входу й авторизації.
П'ять каналів, які вхід до застосунку ніколи не покриває
Таблиця нижче — шаблон інвентаризації, а не контрольний список розгортання. Заповніть другий стовпець тим, що ваше середовище справді застосовує сьогодні.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
Спільний постачальник ідентичності не об'єднує ці авторизації. Користувач, якому дозволено надіслати запит до API, не отримує тим самим права замінити диск віртуальної машини чи відновити базу даних з обліковими даними застосунку. NIST в огляді архітектури нульової довіри саме з цієї причини тримає автентифікацію й авторизацію ресурсів окремо від мережевого розташування.
Інженер підтримки, який може прочитати заявку, не отримує тим самим права відкрити консоль на хості за нею.
Шлях реальний лише тоді, коли альтернатива залишається закритою
Обмеження доступності приватними адміністративними слухачами — законна заміна VPN сайту за умови, що обмеження виконується, а не просто намальоване. Звичайна невдача — альтернативний слухач, про який ніхто не згадав: служба, досі прив'язана до всіх інтерфейсів, правило групи безпеки, відкрите для підрядника, порт керування, доступний з інтернету.
Перевіряйте слухачі, а не схеми. На хості перелічіть, що справді прив'язане, за допомогою ss -ltnp і підтвердьте, що адміністративні порти розташовані на приватній адресі. У хмарній консолі прочитайте правила вхідного трафіку для підмережі робочого навантаження і пошукайте 0.0.0.0/0 на чомусь адміністративному. Потім спробуйте з'єднання ззовні приватного шляху, бо саме цей тест відповідає на питання.
Одне-єдине відкрите всьому світу правило на SSH зводить нанівець усі аргументи проєкту тунелю.
Напишіть карту, перш ніж порівнювати проєкти
Для кожного рядка інвентаризації запишіть, хто затверджує ідентичності, хто оновлює правила доступу, хто видаляє облікові дані, коли хтось іде, і хто займається відновленням, коли ламається сам шлях. Чотирьох імен на рядок достатньо, щоб викрити рядки, де відповідь — спільний обліковий запис і вікі-сторінка трирічної давності.
Потім перевірте один дозвіл і одну відмову на кожен канал. Дозвіл доводить, що передбачувана ідентичність може досягти ресурсу передбачуваним шляхом. Відмова доводить, що схожа ідентичність не може, і саме цей тест люди пропускають, тому альтернативні слухачі й переживають аудити. Порівняйте запропонований проєкт із цими результатами, а не з конфігурацією TLS застосунку, яка ніколи не перевіряла жодного з них.
Де VPN сайту ще заслуговує на своє місце
Тунель або вузький шлюз — правильна відповідь, коли ресурс не має власної автентифікації на кожен запит: порти обслуговування баз даних, цілі резервних копій, консолі гіпервізора, керування поза смугою. Ці слухачі довіряють мережі, тому саме мережа повинна автентифікувати того, хто звертається.
Це не єдина відповідь. Шлюз, який завершує авторизацію для кожного ресурсу, може бути вужчим за тунель на всю підмережу і залишає кращий слід аудиту, ніж спільний проміжний хост.
Порядок роботи: завершіть інвентаризацію, закрийте альтернативи, перевірте одну відмову на рядок і лише потім відмовтеся від тунелю. Якщо рядок не може дати відмову, тримайте приватний шлях, доки не зможе.