Área de administración de SaaS tras a VPN: en que enderezo confiar?

As páxinas públicas de SaaS poden seguir abertas para todos mentres as operacións de administración que hai detrás rexeitan a calquera que estea fóra da VPN. O mecanismo que o fai posible non é un menú oculto nin unha páxina de inicio de sesión á parte; é unha comprobación da ruta de rede que entregou a solicitude. Se te equivocas coa evidencia do enderezo, a comprobación ou ben deixa fóra a administradores reais ou ben admite a calquera que saiba escribir unha cabeceira. Comeza polo que a orixe recibe realmente.

O que a orixe recibe realmente tras o túnel

Cando un navegador chega ao sitio público a través dunha VPN que tamén transporta tráfico de internet, a pasarela traduce a conexión antes de que saia. O SaaS ve o enderezo de saída público da pasarela, normalmente un enderezo ou un rango pequeno, e nunca ve o enderezo do túnel do portátil. Por iso falla engadir 10.90.0.42 á lista de permitidos, e por iso falla aínda máis forte engadir todo o RFC 1918: o segundo admite todas as redes privadas que poidan chegar a ti. O único enderezo que merece unha condición é o que a túa organización posúe realmente na saída.

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

O túnel dividido rompe esa suposición en silencio. Se a VPN só transporta rutas privadas da oficina, a solicitude ao nome de host administrativo público sae polo provedor local e a orixe ve un enderezo residencial. Unha icona de VPN conectada non demostra nada sobre este destino concreto, así que proba o destino e non o túnel.

Detente e corrige o encamiñamento antes de escribir calquera política se o enderezo de saída varía por usuario. Unha condición que só coincide con algúns administradores é peor que ningunha condición, porque agocha o problema ata un incidente.

Confía só no proxy que reescribe o enderezo

A maioría dos sitios públicos están detrás dunha CDN ou dun proxy inverso, así que o enderezo de socket da orixe pertence a esa interface e non ao visitante. A interface adoita reenviar o enderezo orixinal nunha cabeceira, e esa cabeceira contrólaa un atacante a menos que a orixe só a acepte de proxys coñecidos. Configura explicitamente a lista de fontes de confianza e fai que a orixe sexa inalcanzable desde calquera outro lugar. Sen esa segunda metade, un atacante salta o proxy e envía a cabeceira directamente.

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 razoamento aplícase ao protocolo PROXY: só é fiable cando o oínte está ligado a unha interface que o proxy pode alcanzar e nada máis pode. Un contexto de enderezo ausente debe facer fallar a comprobación protexida en lugar de caer nun permiso por defecto. Unha cabeceira ausente non é evidencia dunha ruta de confianza.

Ata a condición a cada operación protexida

Pon a comprobación na fronteira de autorización pola que pasa cada operación protexida, non na páxina que renderiza o menú. Os grupos de rutas, o middleware ou unha capa de políticas funcionan todos; unha copia por controlador non, porque o controlador que alguén engada o próximo trimestre non a terá.

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

A mesma fronteira ten que cubrir a API JSON, as exportacións, as URL de descarga asinadas e o aperto de mans de WebSocket, xa que ningún deles necesita que se solicite primeiro a páxina HTML. Unha ligazón de descarga creada mentres a VPN estaba activa segue sendo válida despois a menos que o punto de descarga volva comprobar. As sesións de longa duración tamén necesitan unha regra de reavaliación, ou unha solicitude autenticada convértese nunha exención permanente. A denegación por defecto é o único axuste que sobrevive á rotación de persoal.

As cachés compartidas son a outra forma de rodear a comprobación. Unha caché que xa contén unha resposta protexida pode servila sen contactar coa orixe, así que marca as respostas de administración como privadas e mantenas fóra do almacenamento compartido. Se unha caché ten que servilas, a comprobación de acceso ten que executarse antes do servizo, o que normalmente significa que non pode ser unha caché compartida en absoluto.

Proba os bypass que acabas de pechar

Exercita a matriz en lugar do camiño feliz: un administrador pola VPN, o mesmo administrador sen ela, un non administrador por ela e unha cabeceira de enderezo falsificada. Engade unha solicitude directa á orixe e unha solicitude con resposta en caché, porque esas dúas son as que saltan 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 solicitude debería devolver o estado que promete a política, e o rexistro debería anotar que evidencia de enderezo se usou. Cobre IPv6 por separado, porque unha orixe de dobre pila pode ver unha familia de orixe distinta da que probaches. Mantén as operacións habituais dos clientes funcionando fóra da VPN, ou o cambio reverterase a primeira vez que un cliente se queixe. Escribe o resultado esperado de cada fila antes de executala, para que un aprobado sorprendente sexa visible.

O enderezo de saída demostra unha ruta de rede permitida, non unha persoa nin un dispositivo xestionado. Manteno como unha condición xunto á autenticación e o permiso, e a área de administración segue sendo estreita sen converter todo o produto nun servizo só para VPN. Esa separación é o deseño, non unha limitación súa.