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

Представьте изменение со стороны пользователя. Кто-то нажимает закладку, ожидает знакомую страницу входа и вместо этого получает ошибку соединения, потому что имя хоста теперь отвечает только внутри туннеля. В этом единственном моменте заключено всё, что план миграции должен сделать правильно: имя, путь, сертификат, учётная запись и операция за ними. Пройдите шаги ниже в этом порядке, и переход перестанет быть прыжком.

Шаг 1: запишите, что пользователи делают сегодня

Начните с имени хоста в адресной строке, порта, операций, которые выполняют люди, и учётных записей, которыми они пользуются. Если вы не можете назвать три главные операции, вы не готовы закрыть публичный вход, потому что при приёмке не узнаете сломанную.

Затем решите, кто является частной аудиторией. Сотрудники в корпоративном VPN — это начало, а не ответ. Подрядчикам, службе поддержки и финансовой команде приложение может понадобиться всем, и не все они могут сидеть за одним и тем же шлюзом.

Шаг 2: отделите туннель от входа

Когда пользователь попадает в приложение через VPN, браузер по-прежнему открывает TLS-соединение с собственным конечным пунктом приложения. Сертификат должен соответствовать этому имени, а приложение по-прежнему проверяет подлинность учётной записи. Ничто в туннеле не заменяет ни то, ни другое.

Именно здесь миграции тихо идут не так. Кто-то решает, что частному адресу больше не нужен действительный сертификат, пользователи учатся проходить через предупреждение, и организация обменяла публичную экспозицию на обучение игнорированию предупреждений безопасности. Если приложению действительно нужен внутренний сертификат, выпустите его во внутреннем центре и правильно распространите доверие. Это контролируемое изменение; страница предупреждения — нет.

Оставьте авторизацию там, где она уже есть. Обзор архитектуры нулевого доверия NIST говорит об этом прямо: сетевое расположение не является основанием для предоставления чувствительной операции. Нахождение внутри туннеля не должно превращать учётную запись только для чтения в администратора.

Шаг 3: найдите вызывающих, которые не являются сотрудниками

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

Определите поддерживаемый путь для каждого, что должен остаться. Поставщик вебхука не может присоединиться к вашему VPN для сотрудников, поэтому либо откройте узко ограниченную конечную точку интеграции с собственной аутентификацией, либо измените модель интеграции. Оставлять всё приложение публичным из-за одного обратного вызова — это выбор, и обычно неправильный.

Запишите каждое исключение с пунктом назначения, разрешённой операцией, аутентификацией и владельцем. Общая учётная запись VPN, выданная интеграции, — это способ, которым исключение становится постоянным. Просмотрите список на следующем обзоре доступа, потому что интеграции живут дольше проектов, добавивших их. Исключение без даты истечения — это постоянное проектное решение, которого никто не принимал.

Шаг 4: выведите из эксплуатации публичный маршрут, а не только запись DNS

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

Параллельно убедитесь, что частное имя разрешается внутри туннеля и что сертификат покрывает имя, которое пользователи будут вводить. Пользователь, которому приходится вставлять числовой адрес, обнаружил симптом, а не решение.

Ограничьте аудиторию VPN путём приложения. Широкий доступ к офисной сети меняет одно решение об экспозиции на более крупное, а административным интерфейсам нужны собственные разрешённые источники вместо наследования пользовательского правила.

Шаг 5: пройдите приёмку сами

Подключитесь как одобренный пользователь, откройте закладку, проверьте сертификат, войдите и выполните одну реальную операцию. Затем попробуйте учётную запись, у которой не должно быть этой операции, и убедитесь, что ей отказано. Затем попробуйте с устройства вне VPN и убедитесь, что приложение недоступно.

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

Шаг 6: отрепетируйте плохой день

Решите, что происходит при сбое туннеля: работа останавливается или её берёт на себя другой одобренный способ доступа. Что бы вы ни выбрали, запишите это и проверьте один раз, потому что аварийное публичное открытие как недокументированный механизм восстановления в конце концов будет выполнено кем-то под давлением.

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

После перехода установка обновлений, жизненный цикл учётных записей, авторизация приложений и аудит по-прежнему ваши. Туннель сузил вход; он не взял на себя ни одну из этих задач.