Àrea d’administració de SaaS darrere de la VPN: en quina adreça confies?
L’origen veu l’adreça de sortida de la teva passarel·la VPN, no l’adreça del túnel de l’ordinador. Confia només en una capçalera de proxy configurada i, després, tanca cada operació d’administració.
Les pàgines públiques de SaaS poden romandre obertes per a tothom mentre les operacions d’administració que hi ha al darrere rebutgen qualsevol persona fora de la VPN. El mecanisme que ho fa possible no és un menú amagat ni una pàgina d’inici de sessió separada; és una comprovació del camí de xarxa que ha lliurat la petició. Si t’equivoques amb l’evidència de l’adreça, la comprovació o bé deixa fora els administradors reals o bé admet qualsevol que sàpiga escriure una capçalera. Comença per allò que l’origen rep realment.
Què rep realment l’origen després del túnel
Quan un navegador arriba al lloc públic a través d’una VPN que també transporta trànsit d’internet, la passarel·la tradueix la connexió abans que surti. El SaaS veu l’adreça de sortida pública de la passarel·la, normalment una adreça o un rang petit, i no veu mai l’adreça del túnel de l’ordinador. És per això que afegir 10.90.0.42 a la llista de permisos falla, i per això afegir tot el RFC 1918 falla encara més fort: el segon admet totes les xarxes privades que et puguin arribar. L’única adreça que val la pena condicionar és la que la teva organització posseeix realment a la sortida.
curl -s https://ifconfig.me
dig +short admin.example.com
El túnel dividit trenca aquesta suposició en silenci. Si la VPN només transporta rutes privades de l’oficina, la petició al nom d’amfitrió administratiu públic surt pel proveïdor local i l’origen veu una adreça residencial. Una icona de VPN connectada no demostra res sobre aquesta destinació concreta, així que prova la destinació i no el túnel.
Atura’t i corregeix l’encaminament abans d’escriure cap política si l’adreça de sortida varia per usuari. Una condició que només coincideix amb alguns administradors és pitjor que cap condició, perquè amaga el problema fins a un incident.
Confia només en el proxy que reescriu l’adreça
La majoria de llocs públics són darrere d’una CDN o d’un proxy invers, així que l’adreça de sòcol de l’origen pertany a aquesta interfície i no al visitant. La interfície normalment reenvia l’adreça original en una capçalera, i aquesta capçalera la controla un atacant tret que l’origen només l’accepti de proxys coneguts. Configura explícitament la llista de fonts de confiança i fes que l’origen no sigui abastable des de cap altre lloc. Sense aquesta segona part, un atacant s’estalvia el proxy i envia la capçalera directament.
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
El mateix raonament s’aplica al protocol PROXY: només és fiable quan l’oient està lligat a una interfície que el proxy pot assolir i cap altra cosa no. Un context d’adreça absent ha de fer fallar la comprovació protegida en lloc de caure en un permís per defecte. Una capçalera absent no és evidència d’un camí de confiança.
Adjunta la condició a cada operació protegida
Posa la comprovació a la frontera d’autorització per la qual passa cada operació protegida, no a la pàgina que renderitza el menú. Els grups de rutes, el middleware o una capa de polítiques funcionen tots; una còpia per controlador no, perquè el controlador que algú afegeixi el proper trimestre no la tindrà.
user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)
La mateixa frontera ha de cobrir l’API JSON, les exportacions, els URL de descàrrega signats i l’encaixada de mans de WebSocket, ja que cap d’ells no necessita que la pàgina HTML es demani primer. Un enllaç de descàrrega creat mentre la VPN era activa continua sent vàlid després tret que el punt de descàrrega torni a comprovar. Les sessions de llarga durada també necessiten una regla de reavaluació, o una petició autenticada es converteix en una exempció permanent. La denegació per defecte és l’únic paràmetre que sobreviu a la rotació de personal.
Les memòries cau compartides són l’altra manera de saltar-se la comprovació. Una memòria cau que ja té una resposta protegida la pot servir sense contactar l’origen, així que marca les respostes d’administració com a privades i mantén-les fora de l’emmagatzematge compartit. Si una memòria cau les ha de servir, la comprovació d’accés s’ha d’executar abans del servei, cosa que normalment significa que no pot ser una memòria cau compartida de cap manera.
Prova les excepcions que acabes de tancar
Exercita la matriu en lloc del camí feliç: un administrador per la VPN, el mateix administrador sense ella, un no administrador per ella i una capçalera d’adreça falsificada. Afegeix una petició directa a l’origen i una petició amb resposta en memòria cau, perquè aquestes dues són les que s’alten la interfície del tot.
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 petició ha de retornar l’estat que la política promet, i el registre ha de recollir quina evidència d’adreça s’ha utilitzat. Cobreix IPv6 per separat, perquè un origen de doble pila pot veure una família d’origen diferent de la que has provat. Mantén les operacions habituals dels clients funcionant fora de la VPN, o el canvi es revertirà la primera vegada que un client es queixi. Escriu el resultat esperat de cada fila abans d’executar-la, perquè un èxit sorprenent sigui visible.
L’adreça de sortida demostra un camí de xarxa permès, no una persona ni un dispositiu gestionat. Mantén-la com una condició al costat de l’autenticació i el permís, i l’àrea d’administració es manté estreta sense convertir tot el producte en un servei només per a la VPN. Aquesta separació és el disseny, no una limitació seva.