AWS Client VPN-regler hører til ressourcen, ikke subnetet

Medarbejderne skal kunne nå én applikation i VPC'en og må ikke kunne nå databaseslytteren på samme instans, så nogen tilføjer et ekstra offentligt subnet til VPN-endpointet og kalder kravet opfyldt. Subnetplacering ændrer routing og tilgængelighed. Det giver eller fratager ikke en enkelt port. Den tilladelse, der udtrykker kravet, bor ved destinationen, i ressourcens sikkerhedsgruppe, og VPN-grænsen leverer det håndtag, som reglen henviser til.

Subnetplacering er routing, ikke autorisation

Hvor endpointets netværkstilknytning ligger, afgør hvilken rutetabel der bærer klienttrafikken, og hvilke tilgængelighedszoner der overlever en fejl. Det siger intet om, hvilken port på hvilken instans trafikken må nå. To klienter tilknyttet samme subnet ankommer stadig med samme kildeidentitet, og ressourcen kan ikke skelne dem efter subnetnavn.

Start i stedet fra kravet: hvem kalder, hvilken ressource, hvilken serviceport og hvilken retning. Vælg derefter den regnmodel, der kan udtrykke de fire ting ved destinationen. Den ramme fjerner som regel det ekstra subnet helt fra designet.

Client VPN-tilknytningsgruppen er håndtaget

For et subnet-tilknyttet AWS Client VPN-endpoint er den dokumenterede ordning konkret. Anvend den tilsigtede sikkerhedsgruppe på endpointets mål-netværkstilknytninger, og tillad derefter den nødvendige trafik i ressourcens sikkerhedsgruppe med den Client VPN-gruppe som kilde.

Konkret tillader applikationsinstansens gruppe applikationsporten fra tilknytningsgruppen og intet andet. AWS' procedure for ressourceadgang beskriver det forhold, og det er værd at holde samme gruppepolitik på tværs af hvert subnet, endpointet tilknyttes, fordi en forældet tilknytning med en anden gruppe stille udvider grænsen.

Den regel godkender ikke nogen. Login er en separat kontrol, og ruten til ressourcen er en tredje. Alle tre skal holde, før en anmodning ankommer. Den, der fejler, afgør, hvilken rettelse der er rigtig, og en regelændring er kun det rigtige svar for den første.

Hvad én tilknytningsgruppe ikke kan skelne

Hver klient bag samme tilknytningsgruppe når ressourcen som samme sikkerhedsgruppekilde. To brugere med forskellige roller er ikke til at skelne på det lag, uanset hvordan gruppen navngives eller tagges. Client VPN's eksterne gruppeautorisation afgrænser adgang efter destinationspræfiks for en mappe- eller SAML-gruppe, hvilket er grovere end en ressourcerolle og bør behandles som en netværksgrænse snarere end et identitetssystem.

Finere forskelle hører til applikationen. En databaseslytter, der skal forblive lukket for de fleste medarbejdere, beskyttes bedre ved slet ikke at være tilgængelig på det tilladte præfiks end ved at håbe på, at gruppemedlemskabet forbliver pænt.

At omdøbe gruppen skaber ikke en identitet, og at duplikere den pr. team formerer blot de tilknytninger, der skal revideres.

Kopier ikke den regel til alle VPN-designs

En selvadministreret EC2 VPN-gateway, et routet inspektionsapparat og managed Client VPN er tre forskellige pakkestier. Fastlæg, hvilken kildeadresse der faktisk når ressourcen, om der sker oversættelse undervejs, og hvilke referencemekanismer tjenesten understøtter på den sti.

Videresendelse af trafik gennem en mellemboks bevarer ikke en kilde-sikkerhedsgruppereference, som direkte instans-til-instans-trafik gør. AWS dokumenterer, at sådanne designs kan have brug for de passende private kildeaddresser eller CIDR'er i stedet for en gruppereference. Proceduren for managed Client VPN er ikke bevis for, at hver gateways tilknyttede gruppe virker som et universelt identitetstoken for videresendte pakker.

Et enkelt NAT-hop på stien er nok til at bryde antagelsen, og fejlen ser ud som en regel, der findes, men aldrig matcher.

Gennemgå den effektive grænse

Læs hver sikkerhedsgruppe, der er knyttet til ressourcen, fordi tilladelsesregler kombineres, og en snæver regel ophæver ikke en bredere på en anden gruppe. Tjek derefter netværks-ACL'en, værtens firewall og applikationens egen autorisation, som er adskilte lag med adskilte fejl.

Afslut med én tilladt og én bevidst udelukket anmodning mod samme ressource. Parret beviser grænsen, mens en enkelt vellykket forbindelse kun beviser, at noget er åbent. Bekræft ruten, den effektive kilde og den tilsigtede serviceport frem for det subnet, der indeholder endpointet.

Arbejdsrækkefølge: skriv det firedelte krav, knyt gruppen til tilknytningerne, afgræns ressourcereglen til porten, verificer én tilladelse og én afvisning, og overvej først derefter at dele subnetter af routinggrunde.