Mover uma aplicação web empresarial para trás da VPN: guia da transição

Imagine a mudança do lado do utilizador. Alguém clica num marcador, espera a página de início de sessão habitual e, em vez disso, recebe um erro de ligação porque o nome do anfitrião agora só responde dentro do túnel. Esse único momento contém tudo o que o plano de migração tem de acertar: o nome, o caminho, o certificado, a conta e a operação por detrás. Percorra os passos abaixo nessa ordem e a transição deixa de ser um salto.

Passo 1: anote o que os utilizadores fazem hoje

Comece pelo nome do anfitrião na barra de endereços, pela porta, pelas operações que as pessoas executam e pelas contas que utilizam. Se não conseguir nomear as três operações principais, não está pronto para fechar a entrada pública, porque não reconhecerá uma avariada durante a aceitação.

Depois decida quem é o público privado. Os empregados na VPN empresarial são um começo, não uma resposta. Os contratados, o pessoal de suporte e a equipa financeira podem todos precisar da aplicação e pode não estar toda atrás da mesma porta de entrada.

Passo 2: separe o túnel do início de sessão

Quando o utilizador chega à aplicação através da VPN, o navegador continua a abrir uma ligação TLS ao ponto final da própria aplicação. O certificado tem de corresponder a esse nome, e a aplicação continua a autenticar a conta. Nada no túnel substitui qualquer um deles.

É aqui que as migrações falham em silêncio. Alguém decide que o endereço privado já não precisa de um certificado válido, os utilizadores aprendem a clicar através de um aviso, e a organização trocou uma exposição pública por uma formação em ignorar avisos de segurança. Se a aplicação precisa mesmo de um certificado interno, emita um a partir da autoridade interna e distribua a confiança corretamente. Isso é uma mudança controlada; uma página de aviso não é.

Mantenha a autorização onde já está. O resumo da arquitetura de confiança zero do NIST diz isso diretamente: a localização na rede não é motivo para conceder uma operação sensível. Estar dentro do túnel não deve transformar uma conta só de leitura num administrador.

Passo 3: encontre os chamadores que não são empregados

Abra a configuração da aplicação e liste tudo o que fala com ela: o URL de retorno do fornecedor de identidade, o webhook de um fornecedor de pagamentos, uma importação agendada, uma sonda de monitorização, o cliente API de um parceiro. Cada um é uma dependência com um proprietário, e cada um vai falhar num momento diferente.

Decida um caminho suportado para cada um que tem de permanecer. Um fornecedor de webhook não se pode juntar à sua VPN de empregados, por isso ou expõe um ponto final de integração de âmbito estreito com a sua própria autenticação, ou altera o modelo de integração. Deixar toda a aplicação pública porque existe um retorno de chamada é uma escolha, e normalmente a errada.

Anote cada exceção com destino, operação permitida, autenticação e proprietário. Uma conta VPN genérica entregue a uma integração é a forma como uma exceção se torna permanente. Reveja a lista na próxima revisão de acessos, porque as integrações sobrevivem aos projetos que as adicionaram. Uma exceção sem data de expiração é uma decisão de design permanente que ninguém tomou.

Passo 4: retire a rota pública, não apenas o registo DNS

Percorra a cadeia de publicação: DNS, recetores do balanceador de carga, regras do proxy inverso, firewall do anfitrião e qualquer nome alternativo que ainda aponte para o endereço antigo. Verifique as duas famílias de endereços. Alterar o registo A principal não prova quase nada se um CNAME mais antigo ou um recetor IPv6 ainda servir a aplicação.

Em paralelo, confirme que o nome privado é resolvido dentro do túnel e que o certificado abrange o nome que os utilizadores vão escrever. Um utilizador que tem de colar um endereço numérico encontrou um sintoma, não uma solução.

Limite o público da VPN ao caminho da aplicação. O acesso amplo à rede do escritório troca uma decisão de exposição por uma maior, e as interfaces administrativas precisam das suas próprias fontes permitidas em vez de herdarem a regra de utilizador.

Passo 5: faça a aceitação você mesmo

Ligue-se como utilizador aprovado, abra o marcador, verifique o certificado, inicie sessão e execute uma operação real. Depois experimente uma conta que não devia ter essa operação e confirme que é recusada. Depois experimente a partir de um dispositivo fora da VPN e confirme que a aplicação é inalcançável.

Repita para cada integração mantida, e leia o registo de entrega do fornecedor em vez de assumir que um 200 da sua própria ferramenta de teste é a mesma coisa. Um início de sessão VPN bem-sucedido não é prova de nenhum destes resultados.

Passo 6: ensaie o dia mau

Decida o que acontece durante uma falha do túnel: o trabalho para, ou outro método de acesso aprovado assume o controlo. Escolha o que escolher, anote-o e teste-o uma vez, porque a reabertura pública de emergência como mecanismo de recuperação não documentado acabará por ser executada por alguém sob pressão.

Mantenha o acesso de recuperação para os administradores que mantêm a porta de entrada e a aplicação, com um proprietário e uma data de remoção. Registe a mudança e as suas condições de reversão no mesmo local, para que uma migração falhada não deixe de fora as pessoas que a reparariam.

Depois da transição, a aplicação de correções, o ciclo de vida das contas, a autorização da aplicação e a auditoria continuam a ser seus. O túnel estreitou a entrada; não assumiu nenhuma dessas tarefas.