Krypterad transit ger inte åtkomst till operatören

Två godkända gateways bär trafiken från ett nätverk med lägre förtroende över ett begränsat transportnätverk. Kryptering av nyttolasten håller den oläslig för vanliga transitobservatörer, och det är den del som folk designar först och sedan slutar tänka på. Vad kryptering inte gör är att definiera vilka resurser sidan med lägre förtroende får nå. Designen behöver två gränser: en kring samtalet som bärs, och en kring åtkomsten till operatören själv.

Utför stegen nedan i ordning och behandla ett fel i vilket steg som helst som en designändring, inte som en konfigurationsjustering.

Definiera båda gränserna innan du rör en konfiguration

Den första gränsen är samtalet: vilka par av gateways som får upprätta en tunnel och vilken inre trafik som får passera genom den. Den andra är operatören: vilka adresser och tjänster värdarna med lägre förtroende får nå utanför tunneln. Team bygger vanligtvis den första och ärver den andra från vilken routning som helst som redan fanns, och så blir en begränsad design tyst en bred. Det arvet är den vanliga grundorsaken när en granskning hittar en värd med lägre förtroende som talar med något som ingen godkände.

Skriv ned båda som listor över adresser, portar och riktningar. Om en lista inte kan skrivas är gränsen ännu inte definierad.

Steg 1: begränsa den yttre tunneln

På gränssnittet som vetter mot operatören får du bara tillåta det tunneln behöver: IKE på UDP 500 och 4500 mellan de två gateway-adresserna, och ESP där NAT-genomträngning inte används. Neka allt annat som anländer på det gränssnittet, inklusive hanteringsprotokoll. ESP-specifikationen täcker skyddstjänsterna; den säger ingenting om vilka av operatörens egna tjänster som gateways får använda. Uttryck det som en explicit tillåtelselista, så att en nyligen publicerad operatörtjänst inte blir nåbar som standard.

Det är regelverket som gör designen till en transitdesign och inte en peering-överenskommelse.

Kontrollera det från sidan med lägre förtroende, inte från gateway-konsolen. En värd där bör inte kunna nå en DNS-server hos operatören ens innan tunneln är uppe.

Steg 2: bestäm vad den avlägsna gatewayen levererar

I den avlägsna änden måste återställd trafik gå någonstans bestämt. Definiera vilka inre tjänster som är tillåtna, från vilka källområden, och om svar förväntas vara symmetriska. Granska administrationsåtkomst separat, eftersom samma gateway ofta exponerar ett administrativt gränssnitt som aldrig var en del av transitplanen.

Ett diagram som stannar vid lyckad dekryptering har hoppat över det beslut som betyder mest.

Steg 3: behåll ägarskap per lager

Transitutrustning tar fortfarande emot och vidarebefordrar yttre paket, så den behöver patchning och kapacitetsplanering. Tunnelns ändpunkter bearbetar det skyddade protokollet och exponerar inre trafik för sin vidarebefordringsväg, så de behöver egna regler och egen övervakning. Slutapplikationerna bearbetar nyttolasten, och en ogenomskinlig nyttolast är inte bevis för att en dekrypterad nedladdning är ofarlig.

Tilldela en ägare till varje lager. Lagren utan ägare är de som driver.

Steg 4: verifiera och överlämna det sedan till myndigheten

Verifiera den yttre vägen med tunneln uppe och operatörens regler på plats. Försök sedan nå varje resurs som sidan med lägre förtroende inte bör nå och bekräfta att felet är en nekning och inte en timeout som döljer en rutt. Kontrollera också tillgänglighet och resursgränser, eftersom en krypterad länk fortfarande kan mättas.

För reglerade eller klassificerade miljöer, ta designen till den ansvariga säkerhetsmyndigheten och använd dess godkända separationsarkitektur. En VPN-konfiguration och en konceptuell förklaring etablerar inte ackreditering. Det steget är inte pappersarbete; det avgör om designen överhuvudtaget får existera.