Преместване на корпоративно уеб приложение зад VPN: ръководство за прехода

Представете си промяната от страната на потребителя. Някой щраква върху отметка, очаква познатата страница за вход и вместо това получава грешка при свързване, защото името на хоста вече отговаря само вътре в тунела. Този единствен момент съдържа всичко, което планът за миграция трябва да направи правилно: името, пътя, сертификата, профила и операцията зад тях. Преминете през стъпките по-долу в този ред и преходът престава да бъде скок.

Стъпка 1: запишете какво правят потребителите днес

Започнете с името на хоста в адресната лента, порта, операциите, които хората извършват, и профилите, които използват. Ако не можете да назовете трите най-важни операции, не сте готови да затворите публичния вход, защото няма да разпознаете счупена по време на приемането.

След това решете коя е частната аудитория. Служителите в корпоративния VPN са начало, а не отговор. Изпълнителите, екипът за поддръжка и финансовият екип може всички да се нуждаят от приложението и може да не стоят зад един и същ шлюз.

Стъпка 2: отделете тунела от входа

Когато потребителят достигне приложението през VPN, браузърът все още отваря TLS връзка към собствения край на приложението. Сертификатът трябва да съвпада с това име и приложението все още удостоверява профила. Нищо в тунела не замества нито едно от двете.

Тук миграциите тихо се объркват. Някой решава, че частният адрес вече не се нуждае от валиден сертификат, потребителите се научават да преминават през предупреждение и организацията е разменила публично излагане срещу обучение по игнориране на предупрежденията за сигурност. Ако приложението наистина се нуждае от вътрешен сертификат, издайте такъв от вътрешния орган и разпределете доверието правилно. Това е контролирана промяна; страница с предупреждение не е.

Запазете авторизацията там, където вече живее. Резюмето на архитектурата с нулево доверие на NIST посочва въпроса директно: мрежовото местоположение не е причина да се предостави чувствителна операция. Намирането вътре в тунела не бива да превръща профил само за четене в администратор.

Стъпка 3: намерете извикващите, които не са служители

Отворете конфигурацията на приложението и изброете всичко, което говори с него: URL за обратно извикване на доставчика на идентичност, уебхук на доставчик на плащания, планиран импорт, сонда за мониторинг, API клиент на партньор. Всяко е зависимост със собственик и всяко ще се счупи в различен момент.

Определете поддържан път за всяко, което трябва да остане. Доставчик на уебхук не може да се присъедини към служебния ви VPN, така че или изложете тясно ограничен край за интеграция със собствена автентикация, или променете модела на интеграция. Оставянето на цялото приложение публично заради едно обратно извикване е избор и обикновено грешният.

Запишете всяко изключение с дестинация, разрешена операция, автентикация и собственик. Общ VPN профил, даден на интеграция, е начинът изключението да стане постоянно. Прегледайте списъка при следващия преглед на достъпа, защото интеграциите надживяват проектите, които са ги добавили. Изключение без дата на изтичане е постоянно дизайнерско решение, което никой не е взел.

Стъпка 4: изтеглете публичния маршрут, а не само DNS записа

Преминете по веригата за публикуване: DNS, слушатели на балансьора на натоварването, правила на обратния прокси, хост защитната стена и всяко алтернативно име, което все още сочи към стария адрес. Проверете и двете семейства адреси. Промяната на основния A запис не доказва почти нищо, ако по-стар CNAME или IPv6 слушател все още обслужва приложението.

Паралелно потвърдете, че частното име се разрешава вътре в тунела и че сертификатът покрива името, което потребителите ще въведат. Потребител, който трябва да постави цифров адрес, е намерил симптом, а не заобиколно решение.

Ограничете аудиторията на VPN до пътя на приложението. Широкият достъп до офис мрежата разменя едно решение за излагане срещу по-голямо и административните интерфейси се нуждаят от собствени разрешени източници, вместо да наследяват правилото за потребителите.

Стъпка 5: преминете приемането сами

Свържете се като одобрен потребител, отворете отметката, проверете сертификата, влезте и извършете една реална операция. След това опитайте с профил, който не би трябвало да има тази операция, и потвърдете, че му е отказано. След това опитайте от устройство извън VPN и потвърдете, че приложението е недостъпно.

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

Стъпка 6: репетирайте лошия ден

Решете какво се случва при прекъсване на тунела: работата спира или друг одобрен метод за достъп поема. Каквото и да изберете, запишете го и го тествайте веднъж, защото аварийното публично отваряне като недокументиран механизъм за възстановяване в крайна сметка ще бъде извършено от някого под натиск.

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

След прехода кръпките, жизненият цикъл на профилите, авторизацията в приложението и одитът все още са ваши. Тунелът стесни входа; той не пое нито една от тези задачи.