To VPN-porter i rekkefølge: hva hver av dem faktisk avgjør
To VPN-trinn i rekkefølge bør bety to separate tillatelsesbeslutninger. Navngi hva hver port kontrollerer, og test deretter hva den indre nekter.
Kjeding av to VPN-er selges vanligvis som ekstra kryptering, som er det minst interessante den gjør. Det egentlige produktet er en annen autorisasjonsbeslutning, tatt av en annen eier mot et annet sett ressurser. Hvis begge trinnene godtar samme legitimasjon og når de samme destinasjonene, er den indre porten dekorasjon med ekstra ventetid. Å avgjøre om den andre beslutningen er verdt driftskostnaden begynner med å navngi hva hver port faktisk verifiserer.
Én tunnel, deretter en annen beslutning
Den ytre porten svarer på et bredt spørsmål: er dette en godkjent ansattenhet, og kan den nå det generelle interne nettverket. Den indre porten svarer på et smalere: bærer denne identiteten vedlikeholdsrettigheten, og kan den nå disse spesifikke administrasjonsendepunktene. Dette er forskjellige spørsmål med forskjellige eiere, og ingen av dem forutsetter den andre. At en vei finnes gjennom begge trinnene er ikke myndighet til å bruke det som ligger bak den andre. Å nå den fjerne inngangen beviser at en rute virker, og ikke noe mer.
Prinsippet er gammelt og ignoreres fortsatt: nettverksplassering taler ikke for noe i seg selv. NISTs sammendrag av nulltillitsarkitektur sier det klart, og avviser implisitt tillit som følger av hvor en tilkobling kom fra eller hvem som eier nettverket. Anvendt her er ankomst til den indre inngangen en forutsetning for ressursene, aldri tillatelsen til å bruke dem.
Skriv ned hva hver port verifiserer
For hvert trinn, registrer identiteten det kontrollerer, destinasjonene det tillater og betingelsene det kan hoppes over under. Den ytre porten kan legitimt tillate vanlige interne tjenester pluss den indre portens lytter, og ingenting annet. Den indre porten kan kreve et rollekrav og bare tillate administrasjonsadressene som er navngitt i endringsprotokollen. Applikasjonen i den fjerne enden beholder det siste ordet om hvilke operasjoner rollen kan utføre, så kjeden legger til en port uten å erstatte applikasjonsautorisasjonen.
| 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 |
To utelatelser bryter designet stille. Hvis det ytre domenet allerede når hver sensitiv destinasjon direkte, er den indre porten valgfri snarere enn obligatorisk. Hvis en offentlig lytter eller en andre privat rute tilbyr samme tilgang, er den tiltenkte veien ett alternativ blant flere. Tildel også en eier til hvert regelsett, og la kontrakten deres navngi destinasjonstjenester, tillatte kildeidentiteter, privat DNS, adresseoversettelse og hvem som svarer når overleveringen feiler. En adresse som er betrodd på det ytre nettverket må aldri erstatte autorisasjonen til det indre domenet.
Test avvisningssakene, ikke den glade veien
En vellykket tilkobling gjennom begge portene beviser svært lite, fordi det er saken alle testet under utrullingen. De interessante sakene er der ett trinn slipper gjennom og det andre avviser. Tre av dem dekker det meste av risikoen, og hver har et forventet resultat som kan kontrolleres i stedet for diskuteres.
Med generell tilgang godkjent og den sensitive rollen fraværende, må vanlig arbeid fortsette mens den sensitive destinasjonen avvises. Godkjenn begge trinnene, og det nåbare settet bør være vedlikeholdsendepunktene som er navngitt i endringsprotokollen, ikke noe bredere. Med rettigheten tilbakekalt midt i en økt, må den avtalte øktpolitikken tre i kraft uten å rive ned urelatert generell tilgang. Om tilbakekallingen avslutter en eksisterende økt med en gang eller ved neste reautentisering, er en politikkbeslutning kontrakten allerede bør inneholde. Den som skrev akseptsakene er ikke den som bør tolke dem under en hendelse.
curl --fail --silent --max-time 5 https://maint.corp.internal/health || echo "denied as expected"Tell avhengighetene du la til
Hvert ekstra trinn legger til en komponent som kan feile og en rute som må ligge riktig inne i den ytre tunnelen. Under en delvis feil forblir den ytre veien oppe mens den indre er utilgjengelig, så brukeren ser et friskt VPN-ikon ved siden av en tjeneste som aldri svarer.
Kontroller rutene og blokkeringsreglene under feil, ikke bare i det normale tilfellet. En standardrute som skyves av den ytre tunnelen kan fange den indre portens egen adresse, noe som gjør det andre trinnet til en tilkobling som etableres og deretter faller. Registrer hva som skal forbli blokkert mens den indre tunnelen er borte, fordi en utilsiktet tilbakefall rundt den er verre enn en ren avbrudd. Bruk samme sonderingsform på begge hoppene, slik at hvert måles i stedet for antas. To tilkoblede statusindikatorer etablerer verken innbygging eller isolasjon.
Hva den andre porten ikke kan kjøpe for deg
Spør om de to portene deler en legitimasjon, en sertifikatmyndighet eller et administrasjonsplan. Der de gjør det, deler de også sine viktigste feilmoduser, og det andre trinnet koster mer enn uavhengigheten det ser ut til å legge til. Separate kryptografiske økter skaper ikke separate administrative kontroller.
Behold den indre porten så lenge den håndhever et krav du kan formulere og teste, for eksempel en rolle det ytre domenet aldri kontrollerer. Fjern den når dens eneste jobb er å reautentisere samme identitet mot de samme destinasjonene. Uansett, registrer kravet, eieren og feiloppførselen sammen, slik at neste gjennomgang diskuterer kravet og ikke diagrammet.