Дайте користувачам VPN доступ до однієї служби, а не до підмережі

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

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

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

Підмережа — деталь реалізації мережевої команди, а служба — те, що попросив бізнес, і одиниця, яку можна переглянути й вивести з експлуатації.

Якщо список залежностей перевищує три пункти, застосунку, ймовірно, потрібна власна розмова про дизайн.

Маршрутизуйте вузько, але застосовуйте контроль в іншому місці

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

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

Явно задокументуйте точку контролю, інакше наступна зміна випадково її перемістить.

Перевірте джерело, яке служба справді бачить

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

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

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

Авторизація застосунку не є необов'язковою

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

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

Тримайте мережеве правило й роль застосунку в різних системах і виводьте їх з експлуатації окремо.

Доведіть і дозволений, і заборонений шлях

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

Не вимикайте фільтри пересилання, щоб приймальний тест пройшов, бо це змінює те, що тестується.

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