Área de administração do SaaS atrás da VPN: em que endereço confiar?

As páginas públicas do SaaS podem permanecer abertas a todos enquanto as operações administrativas por trás delas recusam qualquer pessoa fora da VPN. O mecanismo que torna isso possível não é um menu oculto nem uma página de login separada; é uma verificação do caminho de rede que entregou o pedido. Se a evidência do endereço estiver errada, a verificação ou bloqueia administradores reais ou admite qualquer pessoa que saiba escrever um cabeçalho. Comece pelo que a origem recebe realmente.

O que a origem recebe realmente depois do túnel

Quando um navegador chega ao site público através de uma VPN que também transporta tráfego de internet, o gateway traduz a ligação antes de ela sair. O SaaS vê o endereço de saída público do gateway, normalmente um endereço ou um intervalo pequeno, e nunca vê o endereço do túnel do portátil. É por isso que adicionar 10.90.0.42 à lista de permitidos falha, e por isso que adicionar todo o RFC 1918 falha ainda mais alto: o segundo admite todas as redes privadas que te possam alcançar. O único endereço que merece uma condição é o que a tua organização possui realmente na saída.

curl -s https://ifconfig.me
dig +short admin.example.com

O túnel dividido quebra essa suposição em silêncio. Se a VPN só transporta rotas privadas do escritório, o pedido ao nome de anfitrião administrativo público sai pelo fornecedor local e a origem vê um endereço residencial. Um ícone de VPN ligada não prova nada sobre este destino concreto, por isso testa o destino e não o túnel.

Para e corrige o encaminhamento antes de escrever qualquer política se o endereço de saída varia por utilizador. Uma condição que só corresponde a alguns administradores é pior do que nenhuma condição, porque esconde o problema até um incidente.

Confie apenas no proxy que reescreve o endereço

A maioria dos sites públicos está atrás de uma CDN ou de um proxy inverso, por isso o endereço de socket da origem pertence a essa interface e não ao visitante. A interface normalmente reencaminha o endereço original num cabeçalho, e esse cabeçalho é controlado por um atacante a menos que a origem só o aceite de proxies conhecidos. Configura explicitamente a lista de fontes de confiança e torna a origem inalcançável de qualquer outro lugar. Sem essa segunda metade, um atacante contorna o proxy e envia o cabeçalho diretamente.

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

O mesmo raciocínio aplica-se ao protocolo PROXY: só é fiável quando o ouvinte está ligado a uma interface que o proxy consegue alcançar e mais nada consegue. Um contexto de endereço em falta deve fazer falhar a verificação protegida em vez de cair numa permissão predefinida. Um cabeçalho ausente não é prova de um caminho de confiança.

Liga a condição a cada operação protegida

Coloca a verificação na fronteira de autorização por onde passa cada operação protegida, não na página que renderiza o menu. Grupos de rotas, middleware ou uma camada de políticas funcionam todos; uma cópia por handler não, porque o handler que alguém acrescentar no próximo trimestre não a terá.

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

A mesma fronteira tem de cobrir a API JSON, as exportações, os URL de descarregamento assinados e o aperto de mão do WebSocket, porque nenhum deles precisa que a página HTML seja pedida primeiro. Uma ligação de descarregamento criada enquanto a VPN estava ativa continua válida depois, a menos que o endpoint de descarregamento verifique novamente. As sessões de longa duração também precisam de uma regra de reavaliação, senão um pedido autenticado torna-se uma isenção permanente. A negação predefinida é a única definição que sobrevive à rotação de pessoal.

As caches partilhadas são a outra forma de contornar a verificação. Uma cache que já contém uma resposta protegida pode servi-la sem contactar a origem, por isso marca as respostas administrativas como privadas e mantém-nas fora do armazenamento partilhado. Se uma cache tiver de as servir, a verificação de acesso tem de correr antes do serviço, o que normalmente significa que não pode ser de todo uma cache partilhada.

Testa os desvios que acabaste de fechar

Exercita a matriz em vez do caminho feliz: um administrador pela VPN, o mesmo administrador sem ela, um não administrador por ela e um cabeçalho de endereço falsificado. Acrescenta um pedido direto à origem e um pedido com resposta em cache, porque esses dois são os que saltam a interface por completo.

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

Cada pedido deve devolver o estado que a política promete, e o registo deve anotar que evidência de endereço foi usada. Cobre IPv6 em separado, porque uma origem de dupla pilha pode ver uma família de origem diferente da que testaste. Mantém as operações normais dos clientes a funcionar fora da VPN, ou a alteração será revertida na primeira vez que um cliente se queixar. Escreve o resultado esperado de cada linha antes de a executar, para que uma aprovação surpreendente seja visível.

O endereço de saída prova um caminho de rede permitido, não uma pessoa e não um dispositivo gerido. Mantém-no como uma condição ao lado da autenticação e da permissão, e a área administrativa continua estreita sem transformar todo o produto num serviço só para VPN. Essa separação é o desenho, não uma limitação dele.