AWS Client VPN-regler hører til ressursen, ikke subnettet

Ansatte må nå én applikasjon i VPC-en og må ikke nå databaseslytteren på samme instans, så noen legger til et ekstra offentlig subnett for VPN-endepunktet og erklærer kravet oppfylt. Subnettplasseringen endrer ruting og tilgjengelighet. Den gir eller fratar ikke en eneste port. Tillatelsen som uttrykker kravet, bor ved målet, i sikkerhetsgruppen til ressursen, og VPN-grensen leverer håndtaket som regelen viser til.

Subnettplassering er ruting, ikke autorisasjon

Hvor endepunktets nettverkstilknytning ligger, avgjør hvilken rutetabell som bærer klienttrafikken og hvilke tilgjengelighetssoner som overlever en feil. Det sier ingenting om hvilken port på hvilken instans trafikken kan nå. To klienter tilknyttet samme subnett ankommer fortsatt med samme kildeidentitet, og ressursen kan ikke skille dem etter subnettnavn.

Start i stedet fra kravet: hvem kaller, hvilken ressurs, hvilken tjenesteport og hvilken retning. Velg deretter regnmodellen som kan uttrykke de fire tingene ved målet. Den rammen fjerner som regel det ekstra subnettet helt fra designet.

Client VPN-tilknytningsgruppen er håndtaket

For et subnett-tilknyttet AWS Client VPN-endepunkt er den dokumenterte ordningen konkret. Bruk den tiltenkte sikkerhetsgruppen på endepunktets målnettverkstilknytninger, og tillat deretter den nødvendige trafikken i sikkerhetsgruppen til ressursen med den Client VPN-gruppen som kilde.

Konkret tillater applikasjonsinstansens gruppe applikasjonsporten fra tilknytningsgruppen, og ingenting annet. AWS' prosedyre for ressurstilgang beskriver dette forholdet, og det er verdt å holde samme gruppepolicy på hvert subnett endepunktet tilknyttes, fordi en foreldet tilknytning med en annen gruppe stille utvider grensen.

Den regelen autentiserer ingen. Innlogging er en egen kontroll, og ruten til ressursen er en tredje. Alle tre må holde før en forespørsel ankommer. Den som svikter avgjør hvilken rettelse som er riktig, og en regelendring er bare det riktige svaret for den første.

Hva én tilknytningsgruppe ikke kan skille

Hver klient bak samme tilknytningsgruppe når ressursen som samme sikkerhetsgruppekilde. To brukere med ulike roller er ikke til å skille på det laget, uansett hvordan gruppen er navngitt eller tagget. Client VPNs autorisasjon av eksterne grupper begrenser tilgang etter målprefiks for en katalog- eller SAML-gruppe, noe som er grovere enn en ressursrolle og bør behandles som en nettverksgrense, ikke et identitetssystem.

Finere forskjeller hører til applikasjonen. En databaseslytter som må holdes lukket for de fleste ansatte, er bedre beskyttet ved ikke å være tilgjengelig i det hele tatt på det tillatte prefikset enn ved å håpe at gruppemedlemskapet holder seg ryddig.

Å gi gruppen nytt navn skaper ikke en identitet, og å duplisere den per team multipliserer bare tilknytningene som må revideres.

Ikke kopier den regelen til alle VPN-design

En selvadministrert EC2 VPN-gateway, et rutet inspeksjonsapparat og administrert Client VPN er tre ulike pakkestier. Fastslå hvilken kildeadresse som faktisk når ressursen, om det skjer oversettelse underveis, og hvilke referansemekanismer tjenesten støtter på den stien.

Videresending av trafikk gjennom en mellomledd bevarer ikke en kilde-sikkerhetsgruppereferanse slik direkte instans-til-instans-trafikk gjør. AWS dokumenterer at slike design kan trenge de riktige private kildeadressene eller CIDR-er i stedet for en gruppereferanse. Prosedyren for administrert Client VPN er ikke bevis for at hver gateways tilknyttede gruppe fungerer som et universelt identitetstoken for videresendte pakker.

Ett NAT-hopp på stien er nok til å bryte antakelsen, og feilen ser ut som en regel som finnes, men aldri stemmer.

Gå gjennom den effektive grensen

Les hver sikkerhetsgruppe som er knyttet til ressursen, fordi tillatelsesregler kombineres og en smal regel ikke opphever en bredere på en annen gruppe. Sjekk deretter nettverks-ACL-en, vertens brannmur og applikasjonens egen autorisasjon, som er atskilte lag med atskilte feil.

Avslutt med én tillatt og én bevisst utelatt forespørsel mot samme ressurs. Paret beviser grensen, mens én vellykket tilkobling bare beviser at noe er åpent. Bekreft ruten, den effektive kilden og den tiltenkte tjenesteporten fremfor subnettet som inneholder endepunktet.

Arbeidsrekkefølge: skriv det firedelte kravet, knytt gruppen til tilknytningene, avgrens ressursregelen til porten, verifiser én tillatelse og én avvisning, og vurder først deretter å dele subnett av rutingsgrunner.