Två VPN-portar i rad: vad var och en faktiskt avgör
Två VPN-steg i rad borde betyda två separata tillståndsbeslut. Namnge vad varje port kontrollerar och testa sedan vad den inre nekar.
Kedjning av två VPN:er säljs vanligtvis som extra kryptering, vilket är det minst intressanta den gör. Den verkliga produkten är ett andra auktoriseringsbeslut, fattat av en annan ägare mot en annan uppsättning resurser. Om båda stegen accepterar samma autentiseringsuppgift och når samma destinationer är den inre porten dekoration med extra latens. Att avgöra om det andra beslutet är värt sin driftskostnad börjar med att namnge vad varje port faktiskt verifierar.
En tunnel, sedan ett andra beslut
Den yttre porten svarar på en bred fråga: är detta en godkänd medarbetarenhet och får den nå det allmänna interna nätet. Den inre porten svarar på en snävare: bär denna identitet underhållsbehörigheten och får den nå dessa specifika hanteringsslutpunkter. Det är olika frågor med olika ägare, och ingen av dem förutsätter den andra. Att en väg finns genom båda stegen är inte befogenhet att använda det som ligger bakom den andra. Att nå den avlägsna ingången bevisar att en rutt fungerar, och inget mer.
Principen är gammal och ignoreras fortfarande: nätverksplacering talar inte för något i sig själv. NIST:s sammanfattning av nolltillitsarkitektur säger det tydligt och avvisar implicit tillit som följer av varifrån en anslutning kom eller vem som äger nätverket. Tillämpat här är ankomst till den inre ingången en förutsättning för dess resurser, aldrig tillståndet att använda dem.
Skriv ner vad varje port verifierar
För varje steg, registrera identiteten den kontrollerar, destinationerna den tillåter och villkoren under vilka den kan hoppas över. Den yttre porten får legitimt tillåta vanliga interna tjänster plus den inre portens lyssnare, och inget annat. Den inre porten kan kräva ett rollanspråk och bara tillåta hanteringsadresserna som namnges i ändringsprotokollet. Applikationen i den avlägsna änden behåller det sista ordet om vilka operationer rollen får utföra, så kedjan lägger till en port utan att ersätta applikationens auktorisering.
| Gate | Identity it checks | Destinations it permits | How it could be skipped | When it is removed |
|---|---|---|---|---|
| Outer gateway | Employee account plus a managed device posture | General internal services and the inner gateway's listener | Any alternate path to the same destinations, including a public listener | Ordinary work stops and the inner stage becomes unreachable |
| Inner gateway | A maintenance entitlement or role claim on that identity | The named management addresses in the change record | Direct routes from the outer domain to those addresses | Maintenance access ends while general access stays as it was |
Två utelämnanden bryter designen tyst. Om den yttre domänen redan når varje känslig destination direkt är den inre porten valfri snarare än obligatorisk. Om en offentlig lyssnare eller en andra privat rutt erbjuder samma åtkomst är den avsedda vägen ett alternativ bland flera. Tilldela också en ägare till varje regeluppsättning, och låt deras kontrakt namnge destinations-tjänster, tillåtna källidentiteter, privat DNS, adressöversättning och vem som svarar när överlämningen misslyckas. En adress som är betrodd på det yttre nätverket får aldrig ersätta auktoriseringen för den inre domänen.
Testa nekandefallen, inte den glada vägen
En lyckad anslutning genom båda portarna bevisar mycket lite, eftersom det är fallet alla testade under utrullningen. De intressanta fallen är de där ett steg passerar och det andra nekar. Tre av dem täcker det mesta av risken, och var och en har ett förväntat resultat som kan kontrolleras i stället för diskuteras.
Med allmän åtkomst godkänd och den känsliga rollen frånvarande måste vanligt arbete fortsätta medan den känsliga destinationen nekas. Godkänn båda stegen och den nåbara mängden bör vara underhållsslutpunkterna som namnges i ändringsprotokollet, inget bredare. Om rättigheten återkallas mitt i en session måste den överenskomna sessionspolicyn träda i kraft utan att riva ner orelaterad allmän åtkomst. Om återkallandet avslutar en befintlig session omedelbart eller vid nästa omauktorisering är ett policybeslut som kontraktet redan borde innehålla. Den som skrev acceptansfallen är inte den person som borde tolka dem under en incident.
curl --fail --silent --max-time 5 https://maint.corp.internal/health || echo "denied as expected"Räkna de beroenden du lade till
Varje extra steg lägger till en komponent som kan misslyckas och en rutt som måste bäddas in korrekt i den yttre tunneln. Under ett partiellt fel står den yttre vägen kvar medan den inre är onåbar, så användaren ser en frisk VPN-ikon bredvid en tjänst som aldrig svarar.
Kontrollera rutterna och blockeringsreglerna vid fel, inte bara i det normala fallet. En standardrutt som skjuts av den yttre tunneln kan fånga den inre portens egen adress, vilket gör det andra steget till en anslutning som upprättas och sedan faller. Registrera vad som ska förbli blockerat medan den inre tunneln saknas, eftersom ett oavsiktligt återfall runt den är värre än ett rent avbrott. Använd samma sondform på båda hoppen, så att varje mäts i stället för antas. Två anslutna statusindikatorer etablerar varken inbäddning eller isolering.
Vad den andra porten inte kan köpa åt dig
Fråga om de två portarna delar en autentiseringsuppgift, en certifikatmyndighet eller ett hanteringsplan. Där de gör det delar de också sina viktigaste fellägen, och det andra steget kostar mer än den oberoende det verkar lägga till. Separata kryptografiska sessioner skapar inte separata administrativa kontroller.
Behåll den inre porten så länge den upprätthåller ett krav du kan formulera och testa, till exempel en roll som den yttre domänen aldrig kontrollerar. Ta bort den när dess enda uppgift är att omauktorisera samma identitet mot samma destinationer. Hur som helst, registrera kravet, ägaren och felbeteendet tillsammans, så att nästa granskning diskuterar kravet och inte diagrammet.