Encara necessiteu una VPN de lloc si l’aplicació fa servir mTLS i SSO?
Recorreu els canals que l’inici de sessió de l’aplicació mai no cobreix i decidiu si l’accés a la xarxa privada és redundant o continua sent l’únic camí fins a l’amfitrió.
Inicieu sessió amb mTLS, el tauler es carrega, i l’afirmació que la VPN de lloc ara és redundant sona raonable aproximadament tant de temps com triga a caldre-us una restauració de base de dades a les dues de la matinada. La frontera TLS de l’aplicació descriu un sol canal. L’amfitrió, la base de dades, la destinació de les còpies de seguretat i el compte al núvol porten cadascun el seu propi camí d’entrada, la seva pròpia identitat i el seu propi aprovador, i cap d’ells no es posa a prova amb un inici de sessió correcte.
Camineu cap enfora des de la pantalla d’inici de sessió
Inicieu sessió com ho faria un usuari corrent i anoteu cada salt que toca la petició: navegador, perifèria, oient de l’aplicació, magatzem de sessions, API de backend. Cada salt té un propietari i una decisió d’autenticació. Ara repetiu el recorregut per a la persona que aplica pedaços a l’amfitrió i per al treball que escriu la còpia de seguretat nocturna. Aquests recorreguts solen divergir ja en el primer salt.
Aquesta divergència és la pregunta que val la pena respondre. Una VPN de lloc només és redundant quan cada canal d’aquest segon recorregut té una política d’entrada i autorització que es manté per si sola.
Cinc canals que l’inici de sessió de l’aplicació mai no cobreix
La taula següent és una plantilla d’inventari, no una llista de comprovació de desplegament. Ompliu la segona columna amb el que el vostre entorn aplica realment avui.
| 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 proveïdor d’identitat no fusiona aquestes autoritzacions. Un usuari que pot enviar una petició d’API no queda per això autoritzat a substituir un disc de màquina virtual ni a restaurar una base de dades amb les credencials de l’aplicació. El resum d’arquitectura de zero confiança del NIST manté l’autenticació i l’autorització dels recursos separades de la ubicació de xarxa exactament per aquest motiu.
Un enginyer de suport que pot llegir un tiquet no queda per això autoritzat a obrir una consola a l’amfitrió que hi ha darrere.
Un camí només és real si l’alternativa roman tancada
Limitar l’abast dels oients administratius privats és una substitució legítima d’una VPN de lloc, sempre que la restricció s’apliqui i no només es dibuixi. La fallada habitual és un oient alternatiu que ningú no va recordar: un servei encara lligat a totes les interfícies, una regla de grup de seguretat oberta per a un contractista, un port de gestió abastable des d’internet.
Comproveu oients, no diagrames. A l’amfitrió, llisteu què està realment lligat amb ss -ltnp i confirmeu que els ports administratius seuen en una adreça privada. A la consola del núvol, llegiu les regles d’entrada de la subxarxa de càrrega de treball i busqueu 0.0.0.0/0 en qualsevol cosa administrativa. Després proveu la connexió des de fora del camí privat, perquè aquesta prova és la que respon la pregunta.
Una sola regla oberta al món a SSH desfà tots els arguments que va fer el disseny del túnel.
Escriviu el mapa abans de comparar dissenys
Per a cada fila de l’inventari, anoteu qui aprova les identitats, qui actualitza les regles d’accés, qui elimina les credencials quan algú marxa i qui s’encarrega de la recuperació quan el camí mateix es trenca. Quatre noms per fila n’hi ha prou per exposar les files on la resposta és un compte compartit i una pàgina de wiki de fa tres anys.
Després valideu una autorització i una denegació per canal. Una autorització demostra que la identitat prevista pot arribar al recurs pel camí previst. Una denegació demostra que una identitat similar no pot, i és la prova que la gent s’estalvia, i per això els oients alternatius sobreviuen a les auditories. Compareu el disseny proposat amb aquests resultats, no amb la configuració TLS de l’aplicació, que mai no va posar a prova cap d’ells.
On una VPN de lloc encara guanya el seu lloc
Un túnel o una passarel·la estreta és la resposta correcta quan un recurs no té autenticació pròpia per petició: ports de manteniment de base de dades, destinacions de còpies de seguretat, consoles d’hipervisor, gestió fora de banda. Aquests oients confien en la xarxa, així que la xarxa ha de ser allò que autentica el cridaner.
No és l’única resposta. Una passarel·la que acaba l’autorització per recurs pot ser més estreta que un túnel d’àmbit de subxarxa i deixa un rastre d’auditoria millor que un amfitrió de salt compartit.
Ordre de treball: completeu l’inventari, tanqueu les alternatives, valideu una denegació per fila i només després retireu el túnel. Si una fila no pot produir una denegació, manteniu el camí privat fins que en pugui.