Aínda precisa unha VPN de sitio se a aplicación usa mTLS e SSO?
Percorra as canles que o inicio de sesión da súa aplicación nunca cobre e decida despois se o acceso á rede privada é redundante ou segue a ser a única vía ata o host.
Inicia sesión mediante mTLS, o panel cárgase e a afirmación de que a VPN de sitio xa é redundante soa razoable máis ou menos o tempo que tarda en facerlle falta restaurar unha base de datos ás dúas da madrugada. A fronteira TLS da aplicación describe unha soa canle. O host, a base de datos, o destino das copias de seguridade e a conta de nube levan cada unha a súa propia ruta de entrada, a súa propia identidade e o seu propio aprobador, e ningunha delas se exercita cun inicio de sesión correcto.
Camiñe cara a fóra desde a pantalla de inicio de sesión
Inicie sesión como o faría un usuario corrente e anote cada salto que toca a petición: navegador, borde, escoita da aplicación, almacén de sesións, API de backend. Cada salto ten un propietario e unha decisión de autenticación. Agora repita o percorrido para a persoa que aplica parches ao host e para o traballo que escribe a copia de seguridade nocturna. Eses percorridos adoitan diverxer xa no primeiro salto.
Esa diverxencia é a pregunta que merece resposta. Unha VPN de sitio só é redundante cando cada canle dese segundo percorrido ten unha política de entrada e autorización que se sostén por si soa.
Cinco canles que o inicio de sesión da aplicación nunca cobre
A táboa seguinte é un modelo de inventario, non unha lista de comprobación de despregue. Encha a segunda columna co que o seu propio contorno aplica realmente hoxe.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
Compartir un provedor de identidade non fusiona estas autorizacións. Un usuario que pode enviar unha petición de API non queda por iso autorizado a substituír un disco de máquina virtual nin a restaurar unha base de datos coas credenciais da aplicación. O resumo de arquitectura de confianza cero de NIST mantén a autenticación e a autorización de recursos separadas da localización de rede exactamente por este motivo.
Un enxeñeiro de soporte que pode ler un tícket non queda por iso autorizado a abrir unha consola no host que hai detrás.
Unha ruta só é real se a alternativa permanece pechada
Restrinxir a accesibilidade a escoitas administrativas privadas é unha substitución lexítima dunha VPN de sitio, sempre que a restrición se aplique e non só se debuxe. O fallo habitual é unha escoita alternativa que ninguén lembraba: un servizo aínda ligado a todas as interfaces, unha regra de grupo de seguridade aberta para un contratista, un porto de administración accesible desde internet.
Comprobe escoitas, non diagramas. No host, enumere o que está realmente ligado con ss -ltnp e confirme que os portos administrativos están nun enderezo privado. Na consola da nube, lea as regras de entrada da subrede de carga de traballo e busque 0.0.0.0/0 en calquera cousa administrativa. Despois probe a conexión desde fóra da ruta privada, porque esa proba é a que responde a pregunta.
Unha soa regra aberta ao mundo en SSH desfai todos os argumentos que fixo o deseño do túnel.
Escriba o mapa antes de comparar deseños
Para cada fila do inventario, anote quen aproba as identidades, quen actualiza as regras de acceso, quen retira as credenciais cando alguén marcha e quen se ocupa da recuperación cando a propia ruta se rompe. Catro nomes por fila abondan para deixar ao descuberto as filas onde a resposta é unha conta compartida e unha páxina de wiki de hai tres anos.
Despois valide un permiso e unha denegación por canle. Un permiso demostra que a identidade prevista pode chegar ao recurso pola ruta prevista. Unha denegación demostra que unha identidade similar non pode, e é a proba que a xente salta, e por iso as escoitas alternativas sobreviven ás auditorías. Compare o deseño proposto con estes resultados, non coa configuración TLS da aplicación, que nunca exercitou ningún deles.
Onde unha VPN de sitio aínda gaña o seu lugar
Un túnel ou unha porta estreita é a resposta correcta cando un recurso non ten autenticación propia por petición: portos de mantemento de bases de datos, destinos de copias de seguridade, consolas de hipervisor, xestión fóra de banda. Eses escoitas confían na rede, así que a rede ten que ser o que autentica o chamante.
Non é a única resposta. Unha porta que remata a autorización por recurso pode ser máis estreita que un túnel de toda a subrede e deixa un rastro de auditoría mellor que un host de salto compartido.
Orde de traballo: complete o inventario, peche as alternativas, valide unha denegación por fila e só entón retire o túnel. Se unha fila non pode producir unha denegación, manteña a ruta privada ata que poida.