Twee VPN-poorten in serie: wat elk ervan werkelijk beslist

Twee VPN's aan elkaar koppelen wordt meestal verkocht als extra versleuteling, wat het minst interessante is dat het doet. Het echte product is een tweede autorisatiebeslissing, genomen door een andere eigenaar over een andere set resources. Als beide fasen dezelfde inloggegevens accepteren en dezelfde bestemmingen bereiken, is de binnenste poort versiering met extra latentie. Beslissen of die tweede beslissing de operationele kosten waard is, begint met benoemen wat elke poort werkelijk verifieert.

Eén tunnel, dan een tweede beslissing

De buitenste poort beantwoordt een brede vraag: is dit een goedgekeurd apparaat van een medewerker, en mag het het algemene interne netwerk bereiken. De binnenste poort beantwoordt een smallere: draagt deze identiteit het onderhoudsrecht, en mag het deze specifieke beheer-eindpunten bereiken. Dat zijn verschillende vragen met verschillende eigenaren, en geen van beide impliceert de andere. Dat er een pad door beide fasen bestaat, is geen bevoegdheid om te gebruiken wat achter de tweede ligt. De verre ingang bereiken bewijst dat een route werkt, en niets meer.

Het principe is oud en wordt nog steeds genegeerd: netwerklocatie pleit op zichzelf nergens voor. NIST-samenvatting van zero-trustarchitectuur zegt het duidelijk, en verwerpt impliciet vertrouwen dat volgt uit waar een verbinding vandaan kwam of wie het netwerk bezit. Hier toegepast is aankomst bij de binnenste ingang een voorwaarde voor de resources, nooit de toestemming om ze te gebruiken.

Schrijf op wat elke poort verifieert

Leg voor elke fase de identiteit vast die het controleert, de bestemmingen die het toestaat en de voorwaarden waaronder het overgeslagen kan worden. De buitenste poort mag legitiem gewone interne diensten plus de listener van de binnenste poort toestaan, en niets anders. De binnenste poort kan een rolclaim vereisen en alleen de beheeradressen toestaan die in het wijzigingsrecord staan. De applicatie aan de verre kant houdt het laatste woord over welke bewerkingen die rol mag uitvoeren, dus de keten voegt een poort toe zonder de applicatieautorisatie te vervangen.

Twee weglatingen breken het ontwerp stil. Als het buitenste domein al elke gevoelige bestemming rechtstreeks bereikt, is de binnenste poort optioneel in plaats van verplicht. Als een openbare listener of een tweede privéroute dezelfde toegang biedt, is het beoogde pad één optie uit meerdere. Wijs ook een eigenaar toe aan elke regelset, en laat hun contract de bestemmingsdiensten, toegestane bronidentiteiten, privé-DNS, adresvertaling en wie antwoordt bij een mislukte overdracht benoemen. Een adres dat op het buitenste netwerk vertrouwd wordt, mag nooit de autorisatie van het binnenste domein vervangen.

Test de weigeringsgevallen, niet het gelukkige pad

Een geslaagde verbinding door beide poorten bewijst heel weinig, want dat is het geval dat iedereen tijdens de uitrol testte. De interessante gevallen zijn die waarin de ene fase doorgaat en de andere weigert. Drie ervan dekken het grootste deel van het risico, en elk heeft een verwachte uitkomst die gecontroleerd kan worden in plaats van bediscussieerd.

Met algemene toegang goedgekeurd en de gevoelige rol afwezig, moet gewoon werk doorgaan terwijl de gevoelige bestemming geweigerd wordt. Keur beide fasen goed en de bereikbare set zou de onderhoudseindpunten moeten zijn die in het wijzigingsrecord staan, niets breder. Wordt het recht midden in een sessie ingetrokken, dan moet het afgesproken sessiebeleid van kracht worden zonder niet-gerelateerde algemene toegang af te breken. Of die intrekking een bestaande sessie onmiddellijk of bij de volgende herauthenticatie beëindigt, is een beleidsbeslissing die het contract al zou moeten bevatten. Wie de acceptatiegevallen schreef, is niet de persoon die ze tijdens een incident zou moeten interpreteren.

curl --fail --silent --max-time 5 https://maint.corp.internal/health || echo "denied as expected"

Tel de toegevoegde afhankelijkheden

Elke extra fase voegt een component toe die kan falen en een route die correct in de buitenste tunnel genest moet worden. Bij een gedeeltelijke storing blijft het buitenste pad overeind terwijl het binnenste onbereikbaar is, dus de gebruiker ziet een gezond VPN-pictogram naast een dienst die nooit antwoordt.

Controleer de routes en de blokkeerregels bij storing, niet alleen in het normale geval. Een standaardroute die door de buitenste tunnel wordt geduwd kan het adres van de binnenste poort zelf vangen, wat de tweede fase verandert in een verbinding die tot stand komt en dan wegvalt. Leg vast wat geblokkeerd moet blijven terwijl de binnenste tunnel ontbreekt, want een toevallige terugval eromheen is erger dan een schone onderbreking. Gebruik dezelfde sondeworm op beide hops, zodat elk gemeten wordt in plaats van aangenomen. Twee verbonden statusindicatoren bewijzen noch nesting noch isolatie.

Wat de tweede poort je niet kan kopen

Vraag of de twee poorten een inloggegeven, een certificaatautoriteit of een beheervlak delen. Waar ze dat doen, delen ze ook hun belangrijkste storingsmodi, en de tweede fase kost meer dan de onafhankelijkheid die het lijkt toe te voegen. Afzonderlijke cryptografische sessies creëren geen afzonderlijke administratieve controles.

Houd de binnenste poort zolang die een eis handhaaft die je kunt benoemen en testen, zoals een rol die het buitenste domein nooit controleert. Verwijder hem wanneer zijn enige taak is dezelfde identiteit tegen dezelfde bestemmingen opnieuw te authenticeren. Hoe dan ook, leg de eis, de eigenaar en het storingsgedrag samen vast, zodat de volgende beoordeling over de eis discussieert en niet over het diagram.