Kryptert transitt gir ikke tilgang til operatøren

To godkjente gateways bærer trafikken fra et nettverk med lavere tillit over et begrenset transportnettverk. Kryptering av nyttelasten holder den uleselig for vanlige transittobservatører, og det er den delen folk designer først og deretter slutter å tenke på. Det kryptering ikke gjør, er å definere hvilke ressurser siden med lavere tillit kan nå. Designet trenger to grenser: én rundt samtalen som bæres, og én rundt tilgangen til operatøren selv.

Utfør trinnene nedenfor i rekkefølge, og behandle en feil på et hvilket som helst trinn som en designendring, ikke en konfigurasjonsjustering.

Definer begge grensene før du rører en konfigurasjon

Den første grensen er samtalen: hvilke par av gateways som kan etablere en tunnel, og hvilken indre trafikk som får passere gjennom den. Den andre er operatøren: hvilke adresser og tjenester vertene med lavere tillit kan nå utenfor tunnelen. Team bygger vanligvis den første og arver den andre fra hvilken som helst ruting som allerede fantes, og det er slik et begrenset design stille blir et bredt. Den arven er den vanlige grunnårsaken når en gjennomgang finner en vert med lavere tillit som snakker med noe ingen godkjente.

Skriv begge ned som lister over adresser, porter og retninger. Hvis en liste ikke kan skrives, er grensen ikke definert ennå.

Trinn 1: begrens den ytre tunnelen

På grensesnittet som vender mot operatøren, tillat bare det tunnelen trenger: IKE på UDP 500 og 4500 mellom de to gateway-adressene, og ESP der NAT-gjennomtrenging ikke brukes. Avvis alt annet som ankommer dette grensesnittet, inkludert administrasjonsprotokoller. ESP-spesifikasjonen dekker beskyttelsestjenestene; den sier ingenting om hvilke av operatørens egne tjenester gatewayene kan bruke. Uttrykk det som en eksplisitt tillatelsesliste, slik at en nylig publisert operatørtjeneste ikke blir tilgjengelig som standard.

Dette er regelverket som gjør designet til et transittdesign og ikke en peering-avtale.

Kontroller det fra siden med lavere tillit, ikke fra gateway-konsollen. En vert der bør ikke kunne nå en DNS-server hos operatøren selv før tunnelen er oppe.

Trinn 2: bestem hva den fjerne gatewayen leverer

I den fjerne enden må gjenopprettet trafikk gå et bestemt sted. Definer hvilke indre tjenester som er tillatt, fra hvilke kildeområder, og om svarene forventes å være symmetriske. Gå gjennom administrasjonstilgang separat, fordi den samme gatewayen ofte eksponerer et administrativt grensesnitt som aldri var en del av transittplanen.

Et diagram som stopper ved vellykket dekryptering, har hoppet over beslutningen som betyr mest.

Trinn 3: behold eierskap per lag

Transittutstyr mottar og videresender fortsatt ytre pakker, så det trenger oppdateringer og kapasitetsplanlegging. Tunnelendepunkter behandler den beskyttede protokollen og eksponerer indre trafikk for videresendingsveien sin, så de trenger egne regler og egen overvåking. Endelige applikasjoner behandler nyttelasten, og en ugjennomsiktig nyttelast er ikke bevis for at en dekryptert nedlasting er ufarlig.

Tildel en eier til hvert lag. Lagene uten eier er de som driver.

Trinn 4: verifiser, og overlat det deretter til myndigheten

Verifiser den ytre veien med tunnelen oppe og operatørreglene på plass. Prøv deretter hver ressurs som siden med lavere tillit ikke skal nå, og bekreft at feilen er en avvisning og ikke en tidsavbrudd som skjuler en rute. Kontroller også tilgjengelighet og ressursgrenser, fordi en kryptert lenke fortsatt kan mettes.

For regulerte eller klassifiserte miljøer, ta designet til den ansvarlige sikkerhetsmyndigheten og bruk dens godkjente separasjonsarkitektur. En VPN-konfigurasjon og en konseptuell forklaring etablerer ikke akkreditering. Det trinnet er ikke papirarbeid; det avgjør om designet i det hele tatt får eksistere.