Перенесення корпоративного веб-застосунку за VPN: посібник із переходу

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

Крок 1: запишіть, що користувачі роблять сьогодні

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

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

Крок 2: відокремте тунель від входу

Коли користувач потрапляє до застосунку через VPN, браузер усе ще відкриває TLS-з'єднання з власною кінцевою точкою застосунку. Сертифікат має відповідати цьому імені, а застосунок усе ще автентифікує обліковий запис. Ніщо в тунелі не замінює жодного з них.

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

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

Крок 3: знайдіть викликачів, які не є співробітниками

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

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

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

Крок 4: виведіть з експлуатації публічний маршрут, а не лише запис DNS

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

Паралельно підтвердьте, що приватне ім'я розв'язується всередині тунелю й що сертифікат покриває ім'я, яке вводитимуть користувачі. Користувач, якому доводиться вставляти числову адресу, знайшов симптом, а не рішення.

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

Крок 5: пройдіть приймання самі

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

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

Крок 6: відрепетируйте поганий день

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

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

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