AWS Client VPN-regels horen bij de resource, niet bij het subnet

Medewerkers moeten één applicatie in de VPC bereiken en mogen de databaseluisteraar op dezelfde instantie niet bereiken, dus iemand voegt een tweede openbaar subnet toe voor het VPN-endpoint en noemt de eis vervuld. De subnetplaatsing verandert routing en beschikbaarheid. Ze verleent of weigert geen enkele poort. De toestemming die de eis uitdrukt, woont op de bestemming, in de beveiligingsgroep van de resource, en de VPN-grens levert het handvat waar die regel naar verwijst.

Subnetplaatsing is routing, geen autorisatie

Waar de netwerkkoppeling van het endpoint zit, bepaalt welke routetabel het clientverkeer draagt en welke beschikbaarheidszones een storing overleven. Het zegt niets over welke poort op welke instantie dat verkeer mag bereiken. Twee clients die aan hetzelfde subnet zijn gekoppeld, komen nog steeds met dezelfde bronidentiteit aan, en de resource kan ze niet op subnetnaam onderscheiden.

Begin in plaats daarvan bij de eis: wie belt, welke resource, welke servicepoort en welke richting. Kies dan het regelmodel dat die vier dingen op de bestemming kan uitdrukken. Die insteek haalt het extra subnet meestal volledig uit het ontwerp.

De koppelingsgroep van Client VPN is het handvat

Voor een aan een subnet gekoppeld AWS Client VPN-endpoint is de gedocumenteerde opzet concreet. Pas de bedoelde beveiligingsgroep toe op de doelnetwerkkoppelingen van het endpoint en sta vervolgens het vereiste verkeer toe in de beveiligingsgroep van de resource, met die Client VPN-groep als bron.

Concreet staat de groep van de applicatie-instantie de applicatiepoort vanaf de koppelingsgroep toe, en niets anders. De procedure voor resourcetoegang van AWS beschrijft die relatie, en het loont om hetzelfde groepsbeleid te houden op elk subnet waaraan het endpoint zich koppelt, want een verouderde koppeling met een andere groep verbreedt de grens stil.

Die regel authenticeert niemand. Inloggen is een aparte controle, en de route naar de resource is een derde. Alle drie moeten gelden voordat een verzoek aankomt. Welke faalt bepaalt welke correctie juist is, en een regelwijziging is alleen voor de eerste het juiste antwoord.

Wat één koppelingsgroep niet kan onderscheiden

Elke client achter dezelfde koppelingsgroep bereikt de resource als dezelfde bron van de beveiligingsgroep. Twee gebruikers met verschillende rollen zijn op die laag niet te onderscheiden, hoe de groep ook heet of getagd is. De autorisatie van externe groepen bij Client VPN beperkt toegang per bestemmingsprefix voor een directory- of SAML-groep, wat grover is dan een resourcerol en als netwerkgrens moet worden behandeld, niet als identiteitssysteem.

Fijnere verschillen horen bij de applicatie. Een databaseluisteraar die voor de meeste medewerkers gesloten moet blijven, is beter beschermd door helemaal niet bereikbaar te zijn op de toegestane prefix dan door te hopen dat het groeplidmaatschap netjes blijft.

De groep een andere naam geven schept geen identiteit, en hem per team dupliceren vermenigvuldigt alleen de koppelingen die moeten worden geaudit.

Kopieer die regel niet naar elk VPN-ontwerp

Een zelfbeheerde EC2 VPN-gateway, een gerouteerd inspectieapparaat en beheerde Client VPN zijn drie verschillende pakketpaden. Stel vast welk bronadres de resource werkelijk bereikt, of er onderweg vertaling plaatsvindt en welke referentiemechanismen de dienst op dat pad ondersteunt.

Verkeer door een tussenapparaat sturen behoudt geen verwijzing naar de bronbeveiligingsgroep zoals direct verkeer tussen instanties dat doet. AWS documenteert dat zulke ontwerpen de juiste privé-bronadressen of CIDR's nodig kunnen hebben in plaats van een groepsverwijzing. De procedure voor beheerde Client VPN is geen bewijs dat de aangehechte groep van elke gateway als universeel identiteitstoken voor doorgestuurde pakketten werkt.

Eén NAT-hop op het pad is genoeg om de aanname te breken, en de storing ziet eruit als een regel die aanwezig is maar nooit overeenkomt.

Beoordeel de effectieve grens

Lees elke beveiligingsgroep die aan de resource hangt, want toestaandregels tellen op en een smalle regel heft een bredere op een andere groep niet op. Controleer daarna de netwerk-ACL, de hostfirewall en de eigen autorisatie van de applicatie, die aparte lagen met aparte fouten zijn.

Sluit af met één toegestaan en één bewust uitgesloten verzoek tegen dezelfde resource. Het paar bewijst de grens, terwijl één geslaagde verbinding alleen bewijst dat er iets open is. Bevestig de route, de effectieve bron en de bedoelde servicepoort in plaats van het subnet dat het endpoint bevat.

Werkvolgorde: schrijf de vierdelige eis, koppel de groep aan de koppelingen, beperk de resource-regel tot de poort, verifieer één toestemming en één weigering, en overweeg pas daarna subnetten te splitsen om routingredenen.