Hebt u nog een site-VPN nodig als de app mTLS en SSO gebruikt?
Loop de kanalen door die uw app-login nooit dekt, en beslis dan of toegang tot het privénetwerk overbodig is of nog steeds de enige route naar de host.
U meldt zich aan via mTLS, het dashboard laadt, en de bewering dat de site-VPN nu overbodig is klinkt redelijk ongeveer zolang als het duurt voordat u om twee uur 's nachts een database moet herstellen. De TLS-grens van de applicatie beschrijft één kanaal. De host, de database, het back-updoel en het cloudaccount dragen elk hun eigen intredepad, hun eigen identiteit en hun eigen goedkeurder, en geen ervan wordt geoefend door een geslaagde aanmelding.
Loop naar buiten vanaf het inlogscherm
Meld u aan zoals een gewone gebruiker dat doet en schrijf elke sprong op die het verzoek raakt: browser, rand, applicatielistener, sessieopslag, backend-API. Elke sprong heeft een eigenaar en een authenticatiebeslissing. Herhaal nu de wandeling voor de persoon die de host patcht, en voor de taak die de nachtelijke back-up schrijft. Die wandelingen divergeren meestal al bij de eerste sprong.
Die divergentie is de vraag die het antwoord waard is. Een site-VPN is alleen overbodig als elk kanaal in die tweede wandeling een intrede- en autorisatiebeleid heeft dat op zichzelf staat.
Vijf kanalen die de app-login nooit dekt
De tabel hieronder is een inventarisatiesjabloon, geen implementatiechecklist. Vul de tweede kolom met wat uw eigen omgeving vandaag werkelijk afdwingt.
| 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 |
Het delen van één identiteitsprovider voegt deze autorisaties niet samen. Een gebruiker die een API-verzoek mag indienen, mag daarmee nog geen VM-schijf vervangen of een database herstellen met de inloggegevens van de applicatie. NIST houdt in de samenvatting van de zero-trustarchitectuur juist om deze reden authenticatie en autorisatie van resources gescheiden van netwerklocatie.
Een supportengineer die een ticket kan lezen, mag daarmee nog geen console op de host erachter openen.
Een pad is alleen echt als het alternatief gesloten blijft
De bereikbaarheid beperken tot private administratieve listeners is een legitieme vervanging van een site-VPN, mits de beperking wordt afgedwongen en niet alleen getekend. De gebruikelijke fout is een alternatieve listener waar niemand aan dacht: een dienst die nog aan alle interfaces is gebonden, een beveiligingsgroepregel die voor een aannemer is geopend, een beheerpoort die vanaf het internet bereikbaar is.
Controleer listeners in plaats van diagrammen. List op de host op wat werkelijk is gebonden met ss -ltnp en bevestig dat de administratieve poorten op een privéadres staan. Lees in de cloudconsole de inkomende regels voor het workload-subnet en zoek naar 0.0.0.0/0 op alles wat administratief is. Probeer daarna de verbinding van buiten het private pad, want die test is degene die de vraag beantwoordt.
Eén enkele wereldwijd open regel op SSH maakt elk argument van het tunnelontwerp teniet.
Schrijf de kaart voordat u ontwerpen vergelijkt
Noteer voor elke rij van de inventaris wie identiteiten goedkeurt, wie de toegangsregels bijwerkt, wie inloggegevens verwijdert wanneer iemand vertrekt, en wie het herstel afhandelt wanneer het pad zelf breekt. Vier namen per rij is genoeg om de rijen bloot te leggen waar het antwoord een gedeeld account en een wikipagina van drie jaar oud is.
Valideer vervolgens één toestemming en één weigering per kanaal. Een toestemming bewijst dat de bedoelde identiteit de resource via het bedoelde pad kan bereiken. Een weigering bewijst dat een vergelijkbare identiteit dat niet kan, en dat is de test die mensen overslaan, waardoor alternatieve listeners audits overleven. Vergelijk het voorgestelde ontwerp met deze resultaten, niet met de TLS-configuratie van de applicatie, die er nooit een heeft geoefend.
Waar een site-VPN nog zijn plek verdient
Een tunnel of een smalle gateway is het juiste antwoord wanneer een resource geen eigen authenticatie per verzoek heeft: onderhoudspoorten van databases, back-updoelen, hypervisorconsoles, beheer buiten de band. Die listeners vertrouwen op het netwerk, dus het netwerk moet zijn wat de beller authenticeert.
Het is niet het enige antwoord. Een gateway die de autorisatie per resource beëindigt kan smaller zijn dan een tunnel over het hele subnet en laat een betere audittrail achter dan een gedeelde spronghost.
Werkvolgorde: voltooi de inventaris, sluit de alternatieven, valideer één weigering per rij, en pas dan trekt u de tunnel terug. Kan een rij geen weigering opleveren, houd dan het private pad aan totdat het kan.